After last update (18-08) vtltape segfaults

[ap2010]

Hi Mark,

I defined an LTO1 drive for /dev/st0 and use bacula for backup. This has worked for over a year now.

However, I did an update of mhvtl yesterday (19-8) and now it segfaults the moment I start writing to the tape device.
I have confirmed that this happens also when using a "tar cvzf /dev/nst0 /dir" so it isn't bacula related.

Here is the relevant bit from /var/log/messages, when I give the tar command:

ug 20 12:17:30 orange vtltape[5330]: CDB (506) 00 00 00 00 00 00
Aug 20 12:17:30 orange vtltape[5330]: ssc_tur: Test Unit Ready (506) ** : Yes
Aug 20 12:17:30 orange vtltape[5330]: completeSCSICommand: OP s/n: (506), sz: 0, sam_status: 0
Aug 20 12:17:30 orange vtltape[5330]: CDB (507) 05 00 00 00 00 00
Aug 20 12:17:30 orange vtltape[5330]: ssc_read_block_limits: Read block limits (507) **
Aug 20 12:17:30 orange vtltape[5330]: completeSCSICommand: OP s/n: (507), sz: 6, sam_status: 0
Aug 20 12:17:30 orange vtltape[5330]: CDB (508) 1a 00 00 00 0c 00
Aug 20 12:17:30 orange vtltape[5330]: spc_mode_sense: MODE SENSE (508) **
Aug 20 12:17:30 orange vtltape[5330]: spc_mode_sense:  Mode Sense 6 byte version
Aug 20 12:17:30 orange vtltape[5330]: spc_mode_sense:  Page Control  : Current configuration(0x0)
Aug 20 12:17:30 orange vtltape[5330]: spc_mode_sense:  Page Code     : 0x0
Aug 20 12:17:30 orange vtltape[5330]: spc_mode_sense:  Disable Block Descriptor => No
Aug 20 12:17:30 orange vtltape[5330]: spc_mode_sense:  Allocation len: 12
Aug 20 12:17:30 orange vtltape[5330]: spc_mode_sense: pcode: 0x00, subpcode: 0x00
Aug 20 12:17:30 orange vtltape[5330]: completeSCSICommand: OP s/n: (508), sz: 12, sam_status: 0
Aug 20 12:17:30 orange vtltape[5330]: CDB (509) 0a 00 00 28 00 00
Aug 20 12:17:30 orange vtltape[5330]: ssc_write_6: WRITE_6: 10240 bytes (509) **
Aug 20 12:17:30 orange vtltape[5330]: retrieve_CDB_data: retrieving 10240 bytes from kernel
Aug 20 12:17:30 orange vtltape[5330]: check_restrictions: returning Writable
Aug 20 12:17:30 orange vtltape[5330]: writeBlock: Compression: Orig 10240, after comp: 10171, Compression factor: 1
Aug 20 12:17:30 orange vtltape[5330]: write_tape_block: Successfully wrote block: 0
Aug 20 12:17:30 orange vtltape[5330]: completeSCSICommand: OP s/n: (509), sz: 10240, sam_status: 0
Aug 20 12:17:30 orange vtltape[5330]: CDB (510) 0a 00 00 28 00 00
Aug 20 12:17:30 orange vtltape[5330]: ssc_write_6: WRITE_6: 10240 bytes (510) **
Aug 20 12:17:30 orange vtltape[5330]: retrieve_CDB_data: retrieving 10240 bytes from kernel
Aug 20 12:17:30 orange vtltape[5330]: check_restrictions: returning Writable
Aug 20 12:17:30 orange vtltape[5330]: writeBlock: Compression: Orig 10240, after comp: 10251, Compression factor: 1
Aug 20 12:17:30 orange vtltape[5330]: write_tape_block: Successfully wrote block: 1
Aug 20 12:17:30 orange kernel: vtltape[5330]: segfault at bfb23e54 ip 08050496 sp bfb4bc50 error 4 in vtltape[8048000+1b000]

Here is the relevant bit from my device configuration:

Library: 10 CHANNEL: 00 TARGET: 00 LUN: 00
 Vendor identification: STK
 Product identification: L700
 Product revision level: 0001
 Unit serial number: 000:000:000:001
 NAA: 10:22:33:44:ab:00:00:00

Drive: 11 CHANNEL: 00 TARGET: 01 LUN: 00
 Library ID: 10 Slot: 01
 Vendor identification: IBM
 Product identification: ULTRIUM-TD1
 Product revision level: 05U0
 Unit serial number: 130032001
 NAA: 10:22:33:44:ab:00:01:00
 Compression: factor 1 enabled 1
 READ_WRITE: LTO1

Hope you can locate the problem, as said before it worked very well in the past.

Albert

[Mark Harvey]

Surprising..

Sorry about that & thanks for the bug report.

I've tested using NetBackup only at the moment. I'll re-test using tar / cpio as soon as possible (tomorrow or day after).

Cheers
Mark

[Mark Harvey]

Any chance for a backtrace of the core ?

# gdb /usr/bin/vtltape core
gdb> bt

Assuming a 'ulimit -c unlimited' before starting vtltape & the segfault

[ap2010]

On 08/20/2011 01:00 PM, Mark Harvey [via MHVTL - Linux Virtual Tape Library - Community Forums] wrote:

Any chance for a backtrace of the core ?

# gdb /usr/bin/vtltape core
gdb> bt

Assuming a 'ulimit -c unlimited' before starting vtltape & the segfault

---

If you reply to this email, your message will be added to the discussion below:

http://mhvtl-linux-virtual-tape-library-community-forums.966029.n3.nabble.com/After-last-update-18-08-vtltape-segfaults-tp3270311p3270376.html

To unsubscribe from After last update (18-08) vtltape segfaults, click here.

Any ideas where vtltape leaves its core file?

[Mark Harvey]

the core file location is O/S dependent.

Usually in / or the current dir (a bit hard to spot for daemons)..

Try 'find / -name core\* -print' ;)

No core file if 'ulimit -c 0'

[ap2010]

On 08/20/2011 01:36 PM, Mark Harvey [via MHVTL - Linux Virtual Tape
Library - Community Forums] wrote:
> find / -name core\* -print
I am sorry, it seems I am unable to get it to coredump.

Hopefully you can reproduce this.

Albert

[Mark Harvey]

I wonder why NetBackup didn't trigger this ?
A quick test using tar did..

Can you please try this patch ?
On top of the current github

0001-Fix-core-dump-due-to-incorrect-use-of-get-put_aligne.patch branch..


Cheers
Mark

[ap2010]

Hi Mark.
I'll try it tonight. Got to work first ;-)

Albert

On 23 Aug 2011 00:06, "Mark Harvey [via MHVTL - Linux Virtual Tape Library - Community Forums]" <[hidden email]> wrote:
>
>
> I wonder why NetBackup didn't trigger this ?
> A quick test using tar did..
>
> Can you please try this patch ?
> On top of the current github
>
> http://mhvtl-linux-virtual-tape-library-community-forums.966029.n3.nabble.com/file/n3276477/0001-Fix-core-dump-due-to-incorrect-use-of-get-put_aligne.patch
> 0001-Fix-core-dump-due-to-incorrect-use-of-get-put_aligne.patch branch..
>
>
> Cheers
> Mark
>
> _______________________________________________
> If you reply to this email, your message will be added to the discussion below:
> http://mhvtl-linux-virtual-tape-library-community-forums.966029.n3.nabble.com/After-last-update-18-08-vtltape-segfaults-tp3270311p3276477.html
>
> To unsubscribe from After last update (18-08) vtltape segfaults, visit

[ap2010]

On 08/23/2011 12:06 AM, Mark Harvey [via MHVTL - Linux Virtual Tape Library - Community Forums] wrote:

I wonder why NetBackup didn't trigger this ?
A quick test using tar did..

Can you please try this patch ?
On top of the current github

0001-Fix-core-dump-due-to-incorrect-use-of-get-put_aligne.patch branch..


Cheers
Mark

---

If you reply to this email, your message will be added to the discussion below:

http://mhvtl-linux-virtual-tape-library-community-forums.966029.n3.nabble.com/After-last-update-18-08-vtltape-segfaults-tp3270311p3276477.html

To unsubscribe from After last update (18-08) vtltape segfaults, click here.

Hi Mark,

I can confirm that this works now.
I have made a backup and a restore with bacula and that works fine now.

Thanks,

Albert

[Mark Harvey]

ap2010 wrote

Hi Mark,

I can confirm that this works now.
I have made a backup and a restore with bacula and that works fine now.

Thanks,

Albert

Many thanks,

I'll push the patch to github in a couple of hrs

[Mark Harvey]

The patch has been posted to git-hub.

For those of you reading this much later, this patch will be included with the 0.18-18 release.

Cheers
Mark