pegasus + MediaGX: Oops in khubd, the continuing story?

pegasus + MediaGX: Oops in khubd, the continuing story?

[Frank de Lange]

Hi'all,

I'm experiencing loads of intermittent Oops'es when loading the pegasus driver
(for an SMC 2202) on my MediaGX-equipped (Webplayer) systems. A scan of the
lists turned up more problems with the MediaGX (which contains an OHCI
implementation in the 5530 companion chip) in combination with the pegasus
driver, so I'm not the only one it seems...

The Oops'es are mostly in the khubd process, but they sometimes appear in other
programs (insmod, ifconfig). They always lead to an immedate panic, and nothing
is ever written to any log. When I tried to copy the Oops by hand on a
notebook, the harddisk in that thing chose that specific moment to drop dead (I
was nearly finished typing in the last call trace address...). And there was no
rejoicing, and no call trace... Sorry...

Is this a known problem (MediaGX + pegasus == intermittent Oops on
load/reload), or am I telling something new? If I am, I'll create that call
trace and run it through ksymoops, if it is known I'd rather spare myself the
chore of typing in loads and loads of hex code. I've done enough of that in my
Commodore-64 days...

Cheers//Frank
-- 
  WWWWW      _______________________
 ## o o\    /     Frank de Lange     \
 }#   \|   /                          \
  ##---# _/     <Hacker for Hire>      \
   ####   \      +31-320-252965        /
           \    frank@unternet.org    /
            -------------------------
 [ "Omnis enim res, quae dando non deficit, dum habetur
    et non datur, nondum habetur, quomodo habenda est."  ]

Re: [linux-usb-devel] pegasus + MediaGX: Oops in khubd, the continuing story?

[Alan Cox]

> The Oops'es are mostly in the khubd process, but they sometimes appear in other
> programs (insmod, ifconfig). They always lead to an immedate panic, and nothing

I suspect the ohci driver currently. I've been reviewing it a little and it
is full of code written by someone who does not know about pci write posting.

Specifically

	writel(value, pciaddr)

is a queued operation. So 

	writel(value, foo)
	delay
	real(foo)

might not do the writel into the delay is over or during it. PCI makes 
guarantees that

-	writes will go out in order and will be merged only if prefetchable set
-	multiple writes to the same addr will remain multiple writes
-	reads will not complete until the writes do

This applies in both directions - bus mastering nasties abound notably


	writel(STOP, reg->dmactrl)
	kfree(buffer)

is dangerous 

	You have to do

	writel(STOP, reg->dmactrl);
			[posted]
	readl(reg->dmactrl)
			[read forces write, read reply will follow any DMA
			 pending the other way]

I've not attempted to fix it yet

Re: [linux-usb-devel] pegasus + MediaGX: Oops in khubd, the continuing story?

[David Brownell]

> I suspect the ohci driver currently. I've been reviewing it a little and it
> is full of code written by someone who does not know about pci write posting.

I think there's a lot of that going around ... I don't think any of what you
mentioned was in the Documentation/pci.txt writeup, or any other source
of kernel documentation I found when I started to look at at that code!

That diagnosis works as well with the known facts as any other; maybe
better, considering some of the info I've collected offline.  And it could
also explain some other intermittent failures.


> You have to do
> 
> writel(STOP, reg->dmactrl);
> [posted]
> readl(reg->dmactrl)
> [read forces write, read reply will follow any DMA
> pending the other way]

Good to know.  That'd apply for any register read, not just the
one that was written to, yes?

- Dave