The sym53c8xx driver is involved in the disaster, it seems. In fact, this
driver only allocates memory directly from the page pool and will free
this memory as whole pages only in the situation it is unloaded as a
module. This just makes it immune of the SLAB poisonning trap, by the way.
;-)
Gérard.
On Thu, 15 Jul 1999, Bert Lindner wrote:
...
> linux 2.2.10-ac10
> cdrecord release 1.8a23
>
> scsi adapter info (from /proc/scsi/sym53c8xx/0):
> --
> General information:
> Chip sym53c860, device id 0x6, revision id 0x2
> IO port address 0xec00, IRQ number 11
> Using memory mapped IO at virtual address 0xc4827f00
> Synchronous period factor 12, max commands per lun 32
> --
> As you can see the driver used is sym53c8xx (in module form).
...
> current -> tss.cr3 = 00101000, %cr3 = 00101000
> *pde = 00000000
> Oops: 0000
> CPU: 0
> EIP: 0010:[<c0110338>]
> EFLAGS: 00010887
> eax: c0347808 ebx: 5a5a5a5a ecx: 00000001 edx: 00000001
> esi: c0347804 edi: 00000001 ebp: c01cdeb4 esp: c01cdeb0
> ds: 0018 es: 0018 ss: 0018
> Process swapper (pid: 0, process nr: 0, stackpage = c01cd000)
> stack: c3818c00 c18fa158 c485f178 c3fd4420 c485ef5c 00000eea c01cdefc 00000001
> c48107d3 c3818c00 00000000 00000286 c3818c00 00000246 00000000 c01dcf68
> 00000000 00000000 c3fd4400 c01cdf68 c4820d6d c3818c00 c3ff9f60 04000001
> Call Trace: [<c485f178>] [<c485ef5c>] [<c48107d3>] [<c4820d6d>] [<c0109f69>] \
> [<c0109cbf>] [<c01175d5>]
> [<c010a08c>] [<c0109d08>] [<c01077ad>] [<c0106000>] [<c01077d0>] \
> [<c0108ec8>] [<c0106000>] [<c010607b>]
> [<c0106000>] [<c0100177>]
> Code: 8b 13 8b 5b 04 8b 02 85 c7 74 f1 39 f3 74 09 89 d0 e8 3e f9
> Aiee, killing interrupt handler
> Kernel panic: Attemted to kill the idle task!
> In swapper task - not syncing.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/