linux-apus-devel

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.

Re: More cache_push/SCSI/virgefb

[Roman Z. <zi...@li...>]

Hi,

Ken Tyler wrote:

> 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),

No, the length should only be rounded up to push the correct number of
cache lines.

> and why does virge DEBUG make __get_free_pages return blocks at
> such a very different physical address ?

Usually the kernel starts allocating from the top, but you just get the
last freed page back. During boot several memory areas are freed and
depending on memory allocation scheme or kernel code/data size, you can
get a different page.

bye, Roman

Re: More cache_push/SCSI/virgefb

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

Hello, on Wed, 10 Oct 2001 you Roman Zippel wrote:

> No, the length should only be rounded up to push the correct number of
> cache lines.

There's still something not quite right.  I applied your patch and it
fixed the booting problem but an attempt to mount a scsi drive locked up
the kernel good and proper, no heartbeat, no caps lock led.

I've added some printks to the scsi driver around the cache_push/clear and
(__)get_free_pages calls,  now I can mount and access the drive - at
least on two boots - odd.

(note the 53c7xx.c/A4091/CVPPC never worked really well, OK on slow CDs
and ZIP drives but work it hard on a pair of hard drives and it would hang
up sooner or later).

I'll keep poking around.

Ken.

Re: More cache_push/SCSI/virgefb

[Rene B. <re...@we...>]

Ken Tyler wrote:

> I've added some printks to the scsi driver around the cache_push/clear =
and
> (__)get_free_pages calls, now I can mount and access the drive - at
> least on two boots - odd.


Hi!

I guess the printk`s need so much CPU time, that a cache-flush is forced=20
sometimes and sometimes not. I noticed the same as I used printk`s on my=20
cache problem.

Ciao, Ren=E8

Re: More cache_push/SCSI/virgefb

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

> Hi!
> 
> I guess the printk`s need so much CPU time, that a cache-flush is forced 
> sometimes and sometimes not. I noticed the same as I used printk`s on my 
> cache problem.

I added the missing "sync" to cache_push and now running again with the
printks commented - not convinced that was the problem though.

Ken.