>> The bug was present in the 2.4-test2
>> backport I used for our new PowerMac 2.2 kernels.
>
>Hmm, could you share a brief update on PowerMac and 2.4?
>If I go by Paulus' page at
>
> http://linuxcare.com.au/paulus/kernels.html
>
>what I see is "2.3.99-pre6-pre3" (??) labeled as current.
>That dates from back in April -- not actually very current.
>But 'penguinppc.org' lists a BitKeeper CVS that's relatively
>current (mentions a 2.4.0-test5 pre-release).
The developement of the PowerMac kernel is a bit... weird ;)
Paul is the maintainer for the PowerMac port.
Cort is the maintainer for the PPC port as a whole (includes much more
than PowerMacs).
Paul maintains a couple of rsync trees with his own developements and
gets them regulary merged in Cort's bitkeeper tree (or he sends them
directly to linus and they end up in the bk tree this way, or I merge his
stuffs in bk, etc...)
So the bitkeeper tree is the main PPC tree (but paul rsync is sometimes
slightly more in advance on pmac fixes). Things would be simple if Paul
did only pmac stuffs, but he does other things too. Fortunately, the
bitkeeper tree appears to be regulary sync'ed.
I'm only a satellite hacker doing various PowerMac stuffs. Paul has been
away and very busy lately, that's probably why his rsync 2.4 is still at
2.3.99. I maintain my own a 2.2 kernel with various developements
(mostly support for new Apple HW, fixes, experiments like a new USB
backport) and I keep bk 2.4 updated regulary.
So basically, your best source of PowerMac 2.4 kernels currently is the
bitkeeper tree on hq.fsmlabs.com. (This site also provides rsync access I
think).
>As you know, I'm curious when I can rip out the PMAC_PBOOK
>stuff in the OHCI driver and just use the normal 2.4 PCI
>interfaces for that functionality (no platform-specific stuff).
The problem is that the powerbook sleep process is a bit sensitive to the
order in which things are done, and I don't think we have implemented PCI
power management yet on pmac. Also, I'm working on sleep for new Apple
machines, and this will require all sort of hacking of various Apple-
specific ASIC bits (clock control for example) which can not be done in
generic code. it may not prevent you from doing your changes (the low-
level ASIC hacking can eventually be done after the controller is put to
sleep by the motherboard-specific sleep code), it's just not "simple".
>> In the meantime, I implemented a hack that makes sohci_unlink_urb() safe
>> to call from interrupts,
>
>It should be safe already for async unlinking; synchronous
>unlinks are trouble, since they'd require the interrupt
>code to sleep (Oops!) or something almost as rude.
Yep, that's what I figured out. I made unlink safe at the expense of
spin-looping in the function (at interrupt) long enough for the OHCI to
process 2 frames. It's bad, but at least won't crash with my current USB
backport (SuSE latest backport comes from 2.4-test2 and still had hid.c
bugs calling synchronous unlink from interrupts).
I also added a few memory barriers here of there in the OHCI driver where
I fell they are necessary to ensure proper sync. with the chip. You can
look at my changes, they are in the 2.4 bk tree.
>> a the expense of several milliseconds spend in
>> the interrupt handler (which is bad, but at least won't crash). It's
>> purely a workaround for bad drivers, so I'm considering adding a ton of
>> printk's next to it in order to catch them.
>
>I'd actually rather just see sohci_unlink_urb() report EWOULDBLOCK,
>with a single err() to report that USB device driver bug. Then at
>least the failure report is in the hands of the driver that caused it,
>and it can maybe resolve it. (I've yet to send around such a patch,
>but it's in the queue while I track down a different bug.)
Did you see a lot of drivers test for the result of sohci_unlink_urb() ?
I would also add a printk...
Ben.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
