On Wed, 1 Aug 2007, David Engraf wrote:
> At the moment I have a Jetway/VIA Mainboard which seems to have a problem
> with the handoff. Even
> when I wait about 20 seconds the EHCI_USBLEGSUP_BIOS flag is not cleared.
> I think this is a BIOS
> bug and I will have to talk to Jetway/VIA.
I have the same problem on my Intel motherboard. Which is surprising,
considering that Intel invented the BIOS-handoff technique.
> On the other hand, I don't need the EHCI controller in my kernel, so I
> think the kernel shouldn't take the
> handover for the EHCI controller like other OS which do not have an usb
> driver and so don't know that
> there is a EHCI_USBLEGSUP_BIOS flag which should be cleared.
There ought to be a solution to satisfy everybody. For instance, you
could add a Kconfig flag for enabling USB handoff, and make it be
selected automatically if any of the PCI USB drivers are configured.
Alan Stern
Alan Stern schrieb:
> On Wed, 1 Aug 2007, David Engraf wrote:
>
>
>> At the moment I have a Jetway/VIA Mainboard which seems to have a problem
>> with the handoff. Even
>> when I wait about 20 seconds the EHCI_USBLEGSUP_BIOS flag is not cleared.
>> I think this is a BIOS
>> bug and I will have to talk to Jetway/VIA.
>>
>
> I have the same problem on my Intel motherboard. Which is surprising,
> considering that Intel invented the BIOS-handoff technique.
>
>
Ok, so even Intel has problems with the handoff.
>> On the other hand, I don't need the EHCI controller in my kernel, so I
>> think the kernel shouldn't take the
>> handover for the EHCI controller like other OS which do not have an usb
>> driver and so don't know that
>> there is a EHCI_USBLEGSUP_BIOS flag which should be cleared.
>>
>
> There ought to be a solution to satisfy everybody. For instance, you
> could add a Kconfig flag for enabling USB handoff, and make it be
> selected automatically if any of the PCI USB drivers are configured.
>
> Alan Stern
>
>
This would be solution too, but what if someone uses the uhci controller
and don't want the
ehci. So a single Kconfig flag wouldn't be enough, we have to add 3
flags for uchi, ohci and
ehci. I think this maybe a little bit difficult when configuring the kernel.
The best solution would be when we could use the CONFIG_USB_xxxx_HCD
flag, but it
seems that some hardware has problems when we disable the handoff and
let the BIOS
control the usb controller. Do you know any of this hardware?
Thanks
David Engraf
Netcom Sicherheitstechnik GmbH
Rheinallee 189
55120 Mainz
Tel: +49 6131 6305 0
Fax: +49 6131 6305 40
Email: [email protected]
Sitz der Gesellschaft: Mainz
Registergericht: Amtsgericht Mainz, 14HRB3411
Gesch?ftsf?hrer: Peter Otto
On Thu, 2 Aug 2007, David Engraf wrote:
> This would be solution too, but what if someone uses the uhci controller
> and don't want the
> ehci. So a single Kconfig flag wouldn't be enough, we have to add 3
> flags for uchi, ohci and
> ehci. I think this maybe a little bit difficult when configuring the kernel.
> The best solution would be when we could use the CONFIG_USB_xxxx_HCD
> flag, but it
> seems that some hardware has problems when we disable the handoff and
> let the BIOS
> control the usb controller. Do you know any of this hardware?
The email messages are hidden in the depths of the linux-usb-devel
archives. Maybe you can find them by checking the Git history for
drivers/usb/host/pci-quirks.c, finding the dates for patches that
affected the handoff code, and then searching through the archives near
those dates.
IIRC the problems arose on some MIPS machines. And I don't think the
problem involved letting the firmware manage the USB controller; I
think the problem came when the controller driver tried to do the
handoff later on.
Alan Stern
On Thu, Aug 02, 2007 at 10:32:21AM -0400, Alan Stern wrote:
> On Thu, 2 Aug 2007, David Engraf wrote:
>
> > This would be solution too, but what if someone uses the uhci controller
> > and don't want the
> > ehci. So a single Kconfig flag wouldn't be enough, we have to add 3
> > flags for uchi, ohci and
> > ehci. I think this maybe a little bit difficult when configuring the kernel.
> > The best solution would be when we could use the CONFIG_USB_xxxx_HCD
> > flag, but it
> > seems that some hardware has problems when we disable the handoff and
> > let the BIOS
> > control the usb controller. Do you know any of this hardware?
>
> The email messages are hidden in the depths of the linux-usb-devel
> archives. Maybe you can find them by checking the Git history for
> drivers/usb/host/pci-quirks.c, finding the dates for patches that
> affected the handoff code, and then searching through the archives near
> those dates.
>
> IIRC the problems arose on some MIPS machines. And I don't think the
> problem involved letting the firmware manage the USB controller; I
> think the problem came when the controller driver tried to do the
> handoff later on.
It wasn't just MIPS. IBM has a very popular blade system that has huge
issues with this, and I think there are some other IBM systems based on
the same BIOS that also do bad things if we don't grab the USB
controller away from the BIOS as soon as possible (nasty interrupt and
other messes happen...)
thanks,
greg k-h
Greg KH schrieb:
> On Thu, Aug 02, 2007 at 10:32:21AM -0400, Alan Stern wrote:
>
>> On Thu, 2 Aug 2007, David Engraf wrote:
>>
>>
>>> This would be solution too, but what if someone uses the uhci controller
>>> and don't want the
>>> ehci. So a single Kconfig flag wouldn't be enough, we have to add 3
>>> flags for uchi, ohci and
>>> ehci. I think this maybe a little bit difficult when configuring the kernel.
>>> The best solution would be when we could use the CONFIG_USB_xxxx_HCD
>>> flag, but it
>>> seems that some hardware has problems when we disable the handoff and
>>> let the BIOS
>>> control the usb controller. Do you know any of this hardware?
>>>
>> The email messages are hidden in the depths of the linux-usb-devel
>> archives. Maybe you can find them by checking the Git history for
>> drivers/usb/host/pci-quirks.c, finding the dates for patches that
>> affected the handoff code, and then searching through the archives near
>> those dates.
>>
>> IIRC the problems arose on some MIPS machines. And I don't think the
>> problem involved letting the firmware manage the USB controller; I
>> think the problem came when the controller driver tried to do the
>> handoff later on.
>>
>
> It wasn't just MIPS. IBM has a very popular blade system that has huge
> issues with this, and I think there are some other IBM systems based on
> the same BIOS that also do bad things if we don't grab the USB
> controller away from the BIOS as soon as possible (nasty interrupt and
> other messes happen...)
>
> thanks,
>
> greg k-h
>
So we have hardware which has problems when we are not doing the
handoff, and hardware which has
problems when we are doing the handoff...
What is the best way to solve the problem? Maybe a kernel parameter, a
config flag or an automatic
hardware dependent check of the system?
In fact it is hard to find a solution which works for both as long as
the hardware has this bugs.
Thanks
David Engraf
Netcom Sicherheitstechnik GmbH
Rheinallee 189
55120 Mainz
Tel: +49 6131 6305 0
Fax: +49 6131 6305 40
Email: [email protected]
Sitz der Gesellschaft: Mainz
Registergericht: Amtsgericht Mainz, 14HRB3411
Gesch?ftsf?hrer: Peter Otto
On Fri, 3 Aug 2007, David Engraf wrote:
> So we have hardware which has problems when we are not doing the
> handoff, and hardware which has
> problems when we are doing the handoff...
What hardware has problems when we do the handoff? Your system and
mine experience a delay, but it doesn't break anything.
> What is the best way to solve the problem? Maybe a kernel parameter, a
> config flag or an automatic
> hardware dependent check of the system?
> In fact it is hard to find a solution which works for both as long as
> the hardware has this bugs.
If we really need it, I say we should use a Kconfig flag.
Alan Stern
On Thu, Aug 02, 2007 at 09:43:29AM -0700, Greg KH wrote:
...
> It wasn't just MIPS. IBM has a very popular blade system that has huge
> issues with this, and I think there are some other IBM systems based on
> the same BIOS that also do bad things if we don't grab the USB
> controller away from the BIOS as soon as possible (nasty interrupt and
> other messes happen...)
PA-RISC has the same problem with USB. We can't reprogram the IOMMU
windows at boot time unless the USB controller is forcefully stopped
from doing DMA. "BIOS" leaves the USB DMA enabled to avoid loosing
activity between polls for input.
PA-RISC solves this by calling back into the "BIOS" (aka PDC) to cleanly stop
all possible DMA devices. Other arches probably don't have this luxury.
grant
You said your Intel board has also problems with the handoff.
Could you try the follwing patch, because the EHCI documentation
says that the OS must set the EHCI_USBLEGSUP_OS bit and then
wait until EHCI_USBLEGSUP_BIOS is cleared. The kernel never
uses the EHCI_USBLEGSUP_OS flag at the moment.
On my system there is no change, but maybe this patch works on
your system.
Thanks
David Engraf
linux-2.6.22.1
diff -puN drivers/usb/host/pci-quirks_orig.c drivers/usb/host/pci-quirks.c
--- drivers/usb/host/pci-quirks_orig.c 2007-07-10 20:56:30.000000000
+0200
+++ drivers/usb/host/pci-quirks.c 2007-08-07 10:38:33.000000000 +0200
@@ -268,6 +268,8 @@ static void __devinit quirk_usb_disable_
* handoff..
*/
pci_write_config_byte(pdev, offset + 3, 1);
+
+ pci_write_config_byte(pdev, offset, cap |
EHCI_USBLEGSUP_OS);
}
/* if boot firmware now owns EHCI, spin till
Alan Stern schrieb:
> On Fri, 3 Aug 2007, David Engraf wrote:
>
>
>> So we have hardware which has problems when we are not doing the
>> handoff, and hardware which has
>> problems when we are doing the handoff...
>>
>
> What hardware has problems when we do the handoff? Your system and
> mine experience a delay, but it doesn't break anything.
>
>
>> What is the best way to solve the problem? Maybe a kernel parameter, a
>> config flag or an automatic
>> hardware dependent check of the system?
>> In fact it is hard to find a solution which works for both as long as
>> the hardware has this bugs.
>>
>
> If we really need it, I say we should use a Kconfig flag.
>
> Alan Stern
>
>
On Tue, 7 Aug 2007, David Engraf wrote:
> You said your Intel board has also problems with the handoff.
> Could you try the follwing patch, because the EHCI documentation
> says that the OS must set the EHCI_USBLEGSUP_OS bit and then
> wait until EHCI_USBLEGSUP_BIOS is cleared. The kernel never
> uses the EHCI_USBLEGSUP_OS flag at the moment.
Yes it does. Maybe not by that name, but it does set the bit.
> On my system there is no change, but maybe this patch works on
> your system.
>
> Thanks
> David Engraf
>
> linux-2.6.22.1
>
> diff -puN drivers/usb/host/pci-quirks_orig.c drivers/usb/host/pci-quirks.c
>
> --- drivers/usb/host/pci-quirks_orig.c 2007-07-10 20:56:30.000000000
> +0200
> +++ drivers/usb/host/pci-quirks.c 2007-08-07 10:38:33.000000000 +0200
> @@ -268,6 +268,8 @@ static void __devinit quirk_usb_disable_
> * handoff..
> */
> pci_write_config_byte(pdev, offset + 3, 1);
> +
> + pci_write_config_byte(pdev, offset, cap |
> EHCI_USBLEGSUP_OS);
This patch is definitely wrong (besides being line-wrapped). Note that
EHCI_USBLEGSUP_OS is equal to (1 << 24) -- it makes no sense to use it
as an argument for a byte-sized write. Also note that the two
low-order bytes in the USBLEGSUP register are read-only; you shouldn't
try to write them at all.
It looks like you are simply attempting to do what the previous line of
code already does.
Alan Stern