More cache_push/SCSI/virgefb

[Ken T. <ke...@we...>]

Hello,

For anyone following my exciting story about how turning on DEBUG in
virgefb causes my kernel to hang initializing 53c7xx.c scsi, here is my
latest episode.

From dmesg of a successful boot, no virge DEBUG :

SCSI subsystem driver Revision: 1.00
ioremap: 50000000 (01000000) -> c5018000
scsi-ncr53c7xx : NCR53c710 at memory 0xc5818000, io 0x0, irq 12
scsi : get_free_pages (virt) 0xc0340000
scsi : get_free_pages (phys) 0x08340000
scsi0: Revision 0x1

The physical address of the two pages returned by __get_free_pages is
somewhere low in my 64 Meg of PPC memory.

With virge DEBUG on :

SCSI subsystem driver Revision: 1.00
ioremap: 50000000 (01000000) -> c5018000
scsi-ncr53c7xx : NCR53c710 at memory 0xc5818000, io 0x0, irq 12
scsi : get_free_pages (virt) 0xc3f7e000
scsi : get_free_pages (phys) 0x0bf7e000
(cache_push here)
Oops: kernel access of bad area, sig: 11

The physical address of the two pages is now right at the very top of my
64 Meg.  The cache_push pushes two pages and always the "trailing block",
32 bytes more, this causes the oops.  Taking out the trailing block push
stops the oops.

Two questions, should the trailing block be pushed if it attempts to go
beyond physical memory (not that there should be anything in the cache to
push), and why does virge DEBUG make __get_free_pages return blocks at
such a very different physical address ?

Any suggestions ?

Ken.