Those register values don't seem to matter much to the NEC controller.
None of the sane configurations I tried (in addition to the two mentioned)
affected the UE failure mode in any way I could detect:
* assigning NEC register values to have the same values as the ALI
chip had (yes, POTPGT is writable)
* leaving the chip in power switching mode, if that's how it was
left after boot (warm or cold).
* removing a repeated assignment to the controller functional
state, which I noticed from Greg's walkthrough comparison.
Although there are a few more register-assignment style changes I've
thought to try, I'm beginning to feel that this particular path is not
going to be very productive, and perhaps the problem on the NEC chip is
caused by the same list corruption problems Benjamin Herrenschmidt
has reported for OHCI in his configuration.
That is, I could easily see a corrupt list structure causing in one case
the OHCI chip to give a UE (access to bad address, x86 endiannes) and in
the other case giving the HCD kernel memory access error (access to bad
address, PPC endianness).
Roman, Greg -- both of you have looked a lot more at OHCI far more than
I have. Got any suggestions? Patches for other bugs which might be the
cause of the UE I'm seeing with the NEC chip? ;-)
- Dave
p.s. Reminder, this setup previously worked (ohci) doesn't now (usb-ohci)
and works fine on win98 (openhci.sys). It's clearly some kind of
driver problem; the hardware is known to work.
----- Original Message -----
From: David Brownell <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, March 18, 2000 11:23 AM
Subject: Re: [linux-usb] More on OHCI/NEC Failures
> > When I bring up OHCI with an empty USB, the root hub registers were
> > the only ones that looked interesting:
> >
> > ALI -- POTPGT=1
> >
> > NEC -- POTPGT=255, OCPM, PPCM=fffe
> >
> > Hard to say if that's related to the problem later. (Clearing OCPM
> > didn't change the failure.) The settings all seem to relate to power
> > management.
>
> Just in case it's unclear -- those are the chip register fields that
> were _different_ not the entire set of fields! Both had NPS and so on;
> I didn't show other values since, being the same, they weren't obvious
> candidates for having caused strangeness.
>
> FWIW, applying the recent patches from Roman and Alan didn't change
> anything -- the UE still shows up and prevents anything from working.
>
> - Dave
>
> p.s. Shouldn't the OHCI driver notice a UE and do something useful?
> Like reject all subsequent operations with some errno? When
> a UE shows up, no further USB operations can ever succeed. A
> reset can be done, though it should be done after the problem
> is corrected -- in this case I'd predict the problem would come
> right back again.
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
