Kernel panic in FreeBSD-8.3 from UFS

[Alexander Motin]

On 06/25/12 18:53, Kenneth D. Merry wrote:
> On Mon, Jun 25, 2012 at 15:55:43 +0200, Holm Tiffe wrote:
>> Kenneth D. Merry wrote:
>>
>>> On Tue, Jun 05, 2012 at 17:49:05 +0530, Desai, Kashyap wrote:
>>>> Hi All,
>>>>
>>>> We found some potential area of memory leak in CAM layer.
>>>> CAM XPT Memory leak is due to following  function in scsi/scsi_all.c
>>>>
>>>> int
>>>> scsi_command_string(struct ccb_scsiio *csio, struct sbuf *sb)
>>>>
>>>>
>>>> In above function, CAM layer allocate memory for ccb  device as below
>>>>    if ((cgd = (struct ccb_getdev*)xpt_alloc_ccb_nowait()) == NULL)
>>>>
>>>>
>>>> _But_, unfortunately we never free the allocated memory and we see memory leak of 2K every time when someone is calling
>>>> Scsi_command_string from kernel mode.
>>>>
>>>>
>>>> Attached is a proposed patch for this issue.
>>>
>>> The patch looks good, I just committed it.
>>>
>>> Thanks!
>>>
>>> Ken
>>> --
>>> Kenneth Merry
>>> ken at FreeBSD.ORG
>>> _______________________________________________
>>> freebsd-scsi at freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
>>> To unsubscribe, send any mail to "freebsd-scsi-unsubscribe at freebsd.org"
>>
>>
>> It looks that this patch or something related to it broke my tape backups.
>> I do have two SCSI Tapes connected to my system:
>>
>> # camcontrol devlist
>> <IBM-SSG S53D073 C61E>             at scbus0 target 0 lun 0 (pass0,da0)
>> <IBM-SSG S53D073 C61E>             at scbus0 target 1 lun 0 (pass1,da1)
>> <IBM-SSG S53D073 C61A>             at scbus0 target 2 lun 0 (pass2,da2)
>> <IBM-SSG S53D073 C61A>             at scbus0 target 3 lun 0 (pass3,da3)
>> <TANDBERG SLR5 4/8GB =09:>         at scbus1 target 5 lun 0 (pass4,sa0)
>> <COMPAQ DLT4000 D887>              at scbus1 target 6 lun 0 (pass5,sa1)
>>
>> an with an 8.3 stable from Jun 14 both of them arent able anymore to do
>> blocksizes over 8k and 8k are only working sometimes (huh?!).
>
> The change in the above email didn't get merged back to stable/8 until June
> 20th.  So it isn't that.
>
> There were no changes to the sa(4) driver in stable/8 from March 15th to
> June 14th, but there were lots of other CAM changes.
>
>> # mt -f /dev/sa1 status
>> Mode      Density              Blocksize      bpi      Compression
>> Current:  0x1a:DLTapeIV(20GB)    variable       81633    IDRC
>> ---------available modes---------
>> 0:        0x1a:DLTapeIV(20GB)    variable       81633    IDRC
>> 1:        0x1a:DLTapeIV(20GB)    variable       81633    IDRC
>> 2:        0x1a:DLTapeIV(20GB)    variable       81633    IDRC
>> 3:        0x1a:DLTapeIV(20GB)    variable       81633    IDRC
>> ---------------------------------
>> Current Driver State: at rest.
>> ---------------------------------
>> File Number: 0  Record Number: 0        Residual Count 0
>>
>> # dd if=/dev/zero of=/dev/sa1 bs=1k count=1000
>> 1000+0 records in
>> 1000+0 records out
>> 1024000 bytes transferred in 4.330778 secs (236447 bytes/sec)
>> # dd if=/dev/zero of=/dev/sa1 bs=2k count=1000
>> 1000+0 records in
>> 1000+0 records out
>> 2048000 bytes transferred in 3.252421 secs (629685 bytes/sec)
>> # dd if=/dev/zero of=/dev/sa1 bs=4k count=1000
>> 1000+0 records in
>> 1000+0 records out
>> 4096000 bytes transferred in 2.933208 secs (1396423 bytes/sec)
>> # dd if=/dev/zero of=/dev/sa1 bs=8k count=1000
>> 1000+0 records in
>> 1000+0 records out
>> 8192000 bytes transferred in 3.567864 secs (2296052 bytes/sec)
>> # dd if=/dev/zero of=/dev/sa1 bs=16k count=1000
>> dd: /dev/sa1: Input/output error
>> 1+0 records in
>> 0+0 records out
>> 0 bytes transferred in 0.000253 secs (0 bytes/sec)
>>
>> There is no error message from the kernel related to that.

You may try to boot with verbose kernel messages and enable some CAM 
debug with `camcontrol debug -I all` and then repeat your tests. It 
should probably make kernel to tell more about errors.

>> If I try to read an older backup tape (used 64k Tape Blocks for that):
>> # dd if=/dev/sa1 of=/dev/null bs=64k count=10
>> dd: /dev/sa1: Input/output error
>> 0+0 records in
>> 0+0 records out
>> 0 bytes transferred in 0.000824 secs (0 bytes/sec)
>> #
>> ... I get in /var/log/messages:
>>
>> Jun 25 14:56:05 unicorn kernel: (sa1:sym0:0:6:0): 65536-byte tape record
>> bigger than supplied buffer
>>
>> Nice ehy?
>>
>> I've now booted kernel.old from Mar 15 and the problems are gone on both
>> drives.
>
> It isn't obvious where the problem was introduced, unfortunately.
>
> Could you do a binary search to figure out which revision broke things for
> you?

-- 
Alexander Motin