slab corruption of hpsb_packet from ohci1394 + sbp2 on 2.6.0-test7

slab corruption of hpsb_packet from ohci1394 + sbp2 on 2.6.0-test7

[John Mock]

I've also reproduced a problem noted by Alastair Tse in 2.6.0-test5-mm3
on a Sony R505EL laptop with 2.6.0-test7, as documented in Bugzilla at:

    http://bugzilla.kernel.org/show_bug.cgi?id=1258

For me, this has been a longstanding problem, with 2.4.19 being the only 
kernel that i've found which with i can write data CD's.  I can make this
happen by logging in as 'root' immediately after booting and request the
loading of 'ohci1394'.  About 3-10 seconds later, it fails as shown below:

    tvr-vaio:~# modprobe ohci1394
    ohci1394: $Rev: 1045 $ Ben Collins <bcollins@debian.org>
    ohci1394_0: OHCI-1394 1.1 (PCI): IRQ=[9]  MMIO=[e0205000-e02057ff]  Max
Packet=[2048]
    tvr-vaio:~# sbp2: $Rev: 1034 $ Ben Collins <bcollins@debian.org>
    scsi1 : SCSI emulation for IEEE-1394 SBP-2 Devices
    ieee1394: sbp2: Logged into SBP-2 device
    Slab corruption: start=cd594718, expend=cd594777, problemat=cd594748
    Last user: [<d0b7314c>](free_hpsb_packet+0x2c/0x40 [ieee1394])
    Data: ************************************************D5 D6 D6 D6 01 00 00
00 ***************************************A5
    Next: 71 F0 2C .4C 31 B7 D0 71 F0 2C .....................
    slab error in check_poison_obj(): cache `hpsb_packet': object was modified
after freeing
    Call Trace:
     [<c013abfb>] check_poison_obj+0x10b/0x1a0
     [<c013ae3d>] slab_destroy+0x1ad/0x1c0
     [<c013d498>] reap_timer_fnc+0x148/0x220
     [<c013d350>] reap_timer_fnc+0x0/0x220
     [<c01225c0>] run_timer_softirq+0xb0/0x170
     [<c011e465>] do_softirq+0xa5/0xb0
     [<c010bd45>] do_IRQ+0xe5/0x120
     [<c010a35c>] common_interrupt+0x18/0x20
     [<c01bc0f6>] acpi_processor_idle+0xe8/0x1e3
     [<c0105000>] _stext+0x0/0x30
     [<c01080f4>] cpu_idle+0x34/0x40
     [<c0312765>] start_kernel+0x145/0x150
     [<c03124e0>] unknown_bootoption+0x0/0x110


    tvr-vaio:~# cat > /tmp/console.log

Details are also available via bugzilla, as noted above.  Here are quick 
links to my attachments therein:

    dmsg:	http://bugzilla.kernel.org/attachment.cgi?id=1023
    .config:	http://bugzilla.kernel.org/attachment.cgi?id=1024

(And yes, if you look carefully, you'll see i'm still trying to sort out
the forking of suspend to disk. *sigh*)

Any clues on how to track this problem down would be greatly appreciated!
(Please CC: such replies, as i'm reading via WWW rather than subscribing.)

			         -- JM

Re: slab corruption of hpsb_packet from ohci1394 + sbp2 on 2.6.0-test7

[Zwane Mwaikambo]

On Fri, 10 Oct 2003, John Mock wrote:

> I've also reproduced a problem noted by Alastair Tse in 2.6.0-test5-mm3
> on a Sony R505EL laptop with 2.6.0-test7, as documented in Bugzilla at:
> 
>     http://bugzilla.kernel.org/show_bug.cgi?id=1258
> 
> For me, this has been a longstanding problem, with 2.4.19 being the only 
> kernel that i've found which with i can write data CD's.  I can make this
> happen by logging in as 'root' immediately after booting and request the
> loading of 'ohci1394'.  About 3-10 seconds later, it fails as shown below:
> 
>     tvr-vaio:~# modprobe ohci1394
>     ohci1394: $Rev: 1045 $ Ben Collins <bcollins@debian.org>
>     ohci1394_0: OHCI-1394 1.1 (PCI): IRQ=[9]  MMIO=[e0205000-e02057ff]  Max
> Packet=[2048]
>     tvr-vaio:~# sbp2: $Rev: 1034 $ Ben Collins <bcollins@debian.org>
>     scsi1 : SCSI emulation for IEEE-1394 SBP-2 Devices
>     ieee1394: sbp2: Logged into SBP-2 device
>     Slab corruption: start=cd594718, expend=cd594777, problemat=cd594748
>     Last user: [<d0b7314c>](free_hpsb_packet+0x2c/0x40 [ieee1394])
>     Data: ************************************************D5 D6 D6 D6 01 00 00
> 00 ***************************************A5
>     Next: 71 F0 2C .4C 31 B7 D0 71 F0 2C .....................
>     slab error in check_poison_obj(): cache `hpsb_packet': object was modified
> after freeing

0xcd594748 - 0xcd594718 = 0x30

gdb) p ((struct hpsb_packet *)0)->state_change
Cannot access memory at address 0x30

So someone is doing a down/up on the state_change semaphore after it's 
freed...

> Details are also available via bugzilla, as noted above.  Here are quick 
> links to my attachments therein:
> 
>     dmsg:	http://bugzilla.kernel.org/attachment.cgi?id=1023
>     .config:	http://bugzilla.kernel.org/attachment.cgi?id=1024
> 
> (And yes, if you look carefully, you'll see i'm still trying to sort out
> the forking of suspend to disk. *sigh*)
> 
> Any clues on how to track this problem down would be greatly appreciated!
> (Please CC: such replies, as i'm reading via WWW rather than subscribing.)

The state change synchronization is rather weird in that driver, then 
there is the whole double semaphore acquisition business which i'm not 
quite sure of. It looks better suited to a struct completion, but that is 
the source of your problem. This would be better handled by the 
maintainer.

Re: slab corruption of hpsb_packet from ohci1394 + sbp2 on 2.6.0-test7

[Ben Collins]

> > Any clues on how to track this problem down would be greatly appreciated!
> > (Please CC: such replies, as i'm reading via WWW rather than subscribing.)
> 
> The state change synchronization is rather weird in that driver, then 
> there is the whole double semaphore acquisition business which i'm not 
> quite sure of. It looks better suited to a struct completion, but that is 
> the source of your problem. This would be better handled by the 
> maintainer.

FYI, the semaphore is being removed and things are better handled now.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/

Re: slab corruption of hpsb_packet from ohci1394 + sbp2 on 2.6.0-test7

[John Mock]

[Resending again due to broken DNS apparently causing messages to be rejected.]

Thank you very much, Ben, for a most helpful response.  Getting the 'tarball' 
from:
	http://www.linux1394.org/viewcvs/

and using its directory 'ieee1394/trunk/' in place of '.../drivers/ieee394'
indeed allows 'modprobe ohci1394' to succeed and CD/RW operations to occur.
There are still glitches, though, as 'rmmod sbp2' or 'rmmod ohci1394' give 
me backtrace(s), bug reports of which have been sent privately (and will 
be cheerfully provided upon request).  Software suspend also does not work
properly with the associated device, but i have no idea whether that ever
worked and does not appear to affect other non-CD/RW operations.

I will provide a summary of other VAIO R505EL issues with 2.6.0-test* in a
separate post after i've gotten further with debugging an 'ide-cs' problem.

Thanks again for the bug fix, as now i should be able to run a more modern
kernel to write data CDs.
				-- JM


P.S. Reading via WWW archive rather than subscribing; please reply directly
if you want something to be seen quickly.