On Sun, Oct 17, 2004 at 04:34:35PM -0300, Alexandre Oliva wrote:
>
> Here's Vojtech's patch, updated to 2.6.9-rc4-bk2-ish (Fedora Core
> kernel-2.6.8-1.624). Is there a good reason to keep it out of the
> base kernel?
It's already in the -mm kernels, and will be sent to Linus after 2.6.9
is out. If you could test that kernel and verify that it works for this
situation, I would appreciate it.
thanks,
greg k-h
On Sunday 17 October 2004 02:34 pm, Alexandre Oliva wrote:
> To get the touchpad to work on my Compaq Presario r3004 notebook, in
> addition to ALPS Touchpad patches by Dmitry Torokhov, I needed a patch
> by Vojtech Pavlik that disabled PS/2 USB emulation early in the boot.
> The BIOS didn't have an option to disable it, and, without it, PS/2
> mouse detection wouldn't find anything and, if psmouse is built into
> the kernel, as it happens to be the case for Fedora Core kernels,
> there's no way to re-probe.
Actually, now there is. Starting with 2.6.9 it is possible to force
either rescan or reconnect for devices connected to serio ports:
echo -n "reconnect" > /sys/bus/serio/devices/serio1/driver
should cause re-probe. Just FYI. As Greg said the USB handoff patch
is in -mm three and should take care of most of the issues.
BTW, I think that handoff should be activated by default. I am lurking
in Gentoo forums and there are coultless people having problems with
their mice/touchpads detected properly unless they load their USB drivers
first.
--
Dmitry
On Sun, Oct 17, 2004 at 10:48:16PM -0500, Dmitry Torokhov wrote:
>
> BTW, I think that handoff should be activated by default. I am lurking
> in Gentoo forums and there are coultless people having problems with
> their mice/touchpads detected properly unless they load their USB drivers
> first.
I'm a little leary of changing the way the kernel grabs the USB hardware
from the way we have been doing it for the past 6 years. So by
providing the option for people who have broken machines like these, we
will let them work properly, and it should not affect any of the zillion
other people out there with working hardware.
Or, if we can determine a specific model of hardware that really needs
this option enabled, we can do that automatically. If you look at the
patch, we do that for some specific IBM machines for this very reason.
Is there any consistancy with the type of hardware that you see being
reported for this issue?
thanks,
greg k-h
On Oct 17, 2004, Greg KH <[email protected]> wrote:
> On Sun, Oct 17, 2004 at 04:34:35PM -0300, Alexandre Oliva wrote:
>>
>> Here's Vojtech's patch, updated to 2.6.9-rc4-bk2-ish (Fedora Core
>> kernel-2.6.8-1.624). Is there a good reason to keep it out of the
>> base kernel?
> It's already in the -mm kernels, and will be sent to Linus after 2.6.9
> is out. If you could test that kernel and verify that it works for this
> situation, I would appreciate it.
Cool! It works, as far as enabling the kernel to see there's a mouse
there. Unfortunately, it doesn't recognize it as an ALPS touchpad,
just as a regular PS/2 mouse. I haven't tried to figure out why yet.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
On Oct 18, 2004, Greg KH <[email protected]> wrote:
> Is there any consistancy with the type of hardware that you see being
> reported for this issue?
I've googled around and found a lot of reports of such issues on the
HP Presario 3000Z series, as well as some other HP notebook series
(nx5000?) that (kind of :-) supports Athlon64 processors.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
On Mon, Oct 18, 2004 at 09:45:39AM -0700, Greg KH wrote:
> I'm a little leary of changing the way the kernel grabs the USB hardware
> from the way we have been doing it for the past 6 years. So by
> providing the option for people who have broken machines like these, we
> will let them work properly, and it should not affect any of the zillion
> other people out there with working hardware.
>
> Or, if we can determine a specific model of hardware that really needs
> this option enabled, we can do that automatically. If you look at the
> patch, we do that for some specific IBM machines for this very reason.
>
> Is there any consistancy with the type of hardware that you see being
> reported for this issue?
Like 30% of all notebooks? ;) They do boot without the USB handoff, the
PS/2 mouse works, but only as a PS/2 mouse, no extended capabilities
detection is possible due to the BIOS interference.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Tuesday 19 October 2004 01:30 am, Vojtech Pavlik wrote:
> On Mon, Oct 18, 2004 at 09:45:39AM -0700, Greg KH wrote:
>
> > I'm a little leary of changing the way the kernel grabs the USB hardware
> > from the way we have been doing it for the past 6 years. So by
> > providing the option for people who have broken machines like these, we
> > will let them work properly, and it should not affect any of the zillion
> > other people out there with working hardware.
> >
> > Or, if we can determine a specific model of hardware that really needs
> > this option enabled, we can do that automatically. If you look at the
> > patch, we do that for some specific IBM machines for this very reason.
> >
> > Is there any consistancy with the type of hardware that you see being
> > reported for this issue?
>
> Like 30% of all notebooks? ;) They do boot without the USB handoff, the
> PS/2 mouse works, but only as a PS/2 mouse, no extended capabilities
> detection is possible due to the BIOS interference.
>
I will send a list of examples tomorrow but so far it includes IBM
Thinkpads, Dells, Sonys, Compaqs, Fujitsus, Toshibas, Supermicro-based
boards and nonames.
We risk growing that DMI list pretty big ;)
--
Dmitry
On Tuesday 19 October 2004 01:48 am, Dmitry Torokhov wrote:
> On Tuesday 19 October 2004 01:30 am, Vojtech Pavlik wrote:
> > On Mon, Oct 18, 2004 at 09:45:39AM -0700, Greg KH wrote:
> >
> > > I'm a little leary of changing the way the kernel grabs the USB hardware
> > > from the way we have been doing it for the past 6 years. So by
> > > providing the option for people who have broken machines like these, we
> > > will let them work properly, and it should not affect any of the zillion
> > > other people out there with working hardware.
> > >
> > > Or, if we can determine a specific model of hardware that really needs
> > > this option enabled, we can do that automatically. If you look at the
> > > patch, we do that for some specific IBM machines for this very reason.
> > >
> > > Is there any consistancy with the type of hardware that you see being
> > > reported for this issue?
> >
> > Like 30% of all notebooks? ;) They do boot without the USB handoff, the
> > PS/2 mouse works, but only as a PS/2 mouse, no extended capabilities
> > detection is possible due to the BIOS interference.
> >
>
> I will send a list of examples tomorrow but so far it includes IBM
> Thinkpads, Dells, Sonys, Compaqs, Fujitsus, Toshibas, Supermicro-based
> boards and nonames.
>
> We risk growing that DMI list pretty big ;)
>
OK, here are the different cases that I was able to find:
http://www.ussg.iu.edu/hypermail/linux/kernel/0401.3/0484.html
Sony Vaio GR7/K - PhoenixBIOS 4.0 Release 6.0 - R0208C0.
... Anyway I solved this problem loading uhci_hcd + hid before
psmouse in /etc/modules
http://mike2k.de/cgi-bin/t40.cgi
Thinkpad T40p
... When booting a 2.6.2 kernel with apm enabled, the synaptics
touchpad is not recognized by the Kernel if a USB Mouse is plugged
in at boottime and thus only the usb mouse is usable.
http://lkml.org/lkml/2004/7/6/32
Unknown
> > input: SynPS/2 Synaptics TouchPad on isa0060/serio1
>
> Try making psmouse modular as well and load it _after_ all USB stuff is
> loaded - you may be having issues with USB Legacy emulation.
Ok, this has fixed it. At least the other way round: compiling in the
basic usb stuff and psmouse did the trick in -mm6, too.
http://www.redhat.com/archives/fedora-test-list/2004-June/msg00168.html
Supermicro boards seem to have problems
... As far as people can currently tell that is down to supermicro bios bugs.
Compiling the HCD in hides this by turning off USB legacy emulation before
the bios can get involved - so the kernel ends up talking to the real
PS/2 hardware.
http://seclists.org/lists/linux-kernel/2004/Mar/0348.html
Model: unknown
> On Tuesday 02 March 2004 05:03 am, Emiliano 'AlberT' Gabrielli wrote:
> > Hi all,
> > I have a strange behaviour on my laptop: touchpad is not probed by the
> > kernel (2.6.3) *if* and only if at boot time the USB mouse is plugged in
> > ...
>
> It is usually caused by USB Legacy emulation - BIOS makes a USB mouse look
> like a PS/2 mouse. Look in your BIOS setup if there is an option to turn it
> off. Otherwise you will have to load ehci/uhci_hcd and hid modules before
> loading psmouse module as loading full-blown USB support disables that
> emulation.
perfect, now all works fine
thank you so much
http://forums.gentoo.org/viewtopic.php?t=169145
sony vaio PCG-R600HFPD
(handoff did not seem to help in this case though)
http://forums.gentoo.org/viewtopic.php?t=178056&highlight=
Vaio PCG-GRX650.
Result unknown
http://forums.gentoo.org/viewtopic.php?t=215876&highlight=
Model: unknown
... it works like a charm when compiled psmouse as a module.
http://forums.gentoo.org/viewtopic.php?t=223819&highlight=
Premio 6010N (czech made in ATComputers)
http://www.ussg.iu.edu/hypermail/linux/kernel/0409.0/1930.html
Fujitsu S7010
May help.
http://www.fedoraforum.org/forum/archive/index.php/t-21097.html
... I have a Toshiba A70, and needed to disable 'legacy USB support'
in the bios. As soon as I did that, the touchpad (minus wheel
functionality) began working.
http://forums.gentoo.org/viewtopic.php?p=1665865#1665865
Keyboard does not work unless usb-handoff is used.
http://bugme.osdl.org/show_bug.cgi?id=1882
IBM T40
There is also issue of IBMs reporting presence of an active multiplexing
controller unless USB is activated before i8042.
J.A. Magallon has complained that his mouse is jerky unless legacy
emulation is disabled.
Note that only staring with 2.6 PS/2 initialization happens before
USB because before GPM/X was doing it way after USB has been activated
event if USB was compiled as modules.
--
Dmitry
On Llu, 2004-10-18 at 19:31, Alexandre Oliva wrote:
> > Is there any consistancy with the type of hardware that you see being
> > reported for this issue?
>
> I've googled around and found a lot of reports of such issues on the
> HP Presario 3000Z series, as well as some other HP notebook series
> (nx5000?) that (kind of :-) supports Athlon64 processors.
The main problem ones in Red Hat bugzilla are anythign E7xxx based (this
seems to be the department of lost causes), but which has a "fix" akin
to Greg's for UHCI only and the HP (and other eMachines identical)
laptops which is fixed by BIOS updating to the newer model (warranty and
risk your own...)
Alan
On Maw, 2004-10-19 at 07:30, Vojtech Pavlik wrote:
> Like 30% of all notebooks? ;) They do boot without the USB handoff, the
> PS/2 mouse works, but only as a PS/2 mouse, no extended capabilities
> detection is possible due to the BIOS interference.
I started in favour of avoiding always doing the handoff, but now I'm
convinced handoff should be the default.
Alan
On Sul, 2004-10-17 at 23:57, Greg KH wrote:
> It's already in the -mm kernels, and will be sent to Linus after 2.6.9
> is out. If you could test that kernel and verify that it works for this
> situation, I would appreciate it.
It would be ok if someone bothered to copy the USB core code (or better
yet call into it) but the patch in the -mm tree doesn't know about the
zillion OHCI controller bugs, and doesn't know about the suprise
interrupt on switch from BIOS->host you sometimes see.
The real fix is to link the USB code early enough to run before the PC
keyboard code. I've had this confirmed by BIOS folks as well.
But *please* if you are going to copy USB mode switching code copy
working code including all the nasty gungy details!
>-----Original Message-----
>From: Alan Cox [mailto:[email protected]]
>Sent: Wednesday, October 20, 2004 12:54 PM
>To: Greg KH
>Cc: Alexandre Oliva; Linux Kernel Mailing List; Vojtech
>Pavlik; Dmitry Torokhov
>Subject: Re: forcing PS/2 USB emulation off
>
>On Sul, 2004-10-17 at 23:57, Greg KH wrote:
>> It's already in the -mm kernels, and will be sent to Linus
>after 2.6.9
>> is out. If you could test that kernel and verify that it
>works for this
>> situation, I would appreciate it.
>
>It would be ok if someone bothered to copy the USB core code (or better
>yet call into it) but the patch in the -mm tree doesn't know about the
>zillion OHCI controller bugs, and doesn't know about the suprise
>interrupt on switch from BIOS->host you sometimes see.
Isn't this interrupt disabled at that point, and status are cleared
right
after handoff ? Have you actually been able to see a problem with such
an interrupt with this patch applied ?
>
>The real fix is to link the USB code early enough to run before the PC
>keyboard code. I've had this confirmed by BIOS folks as well.
That would be nice, but -mm patch covers not only keyboard/mouse issues,
but lockups as well. Unfortunately, to work around this, handoff should
happen not only pretty early, but before you start enabling shared (with
USB)
interrupts for your cards.
Aleks.
On 17 Oct 2004 16:34:35 -0300, Alexandre Oliva <[email protected]> wrote:
> Here's Vojtech's patch, updated to 2.6.9-rc4-bk2-ish (Fedora Core
> kernel-2.6.8-1.624). Is there a good reason to keep it out of the
> base kernel?
Looks like something pre-historic. But I cannot blame you for not paying
attention to little elves working on patches, because there was no way
to do it. If hackers always sent their patches to mailing lists instead
of maintainers directly, it might have saved hacking on obsolete patches
and made world a better place, I reckon. Attached is the latest I have,
but with all the activity under the carpet I cannot be sure that one is
the head of the development either.
Anyone having a newer version please speak up.
-- Pete
Subject: [PATCH] early usb handoff for 2.6
From: john stultz <[email protected]>
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Message-Id: <[email protected]>
Date: Thu, 09 Sep 2004 18:12:02 -0700
Greg,
Apparently there is an issue w/ the IBM x440/x445's BIOS's USB
Legacy support. Due to the delay in issuing SMI's across the IOAPICs,
its possible for I/O to ports 60/64 to cause register corruption.
The solution is to disable the BIOS's USB Legacy support early in
boot(via PCI quirks) for x440/x445 systems.
Originally written by Vojtech against SuSE's tree, this patch was then
updated to disable EHCI by Aleksey Gorelov, cleaned up by Pete Zaitcev
for 2.4 and finally tweaked and updated against 2.6 by me.
I've lightly tested this version of the patch, but it differs little
from what Aleksey, Pete and I have been testing for 2.4.
Please consider for inclusion into your tree for further testing?
thanks
-john
linux-2.6.9-rc1_usb-handoff_A3.patch
====================================
diff -Nru a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
--- a/Documentation/kernel-parameters.txt 2004-09-09 17:59:01 -07:00
+++ b/Documentation/kernel-parameters.txt 2004-09-09 17:59:01 -07:00
@@ -1270,6 +1270,8 @@
uart6850= [HW,OSS]
Format: <io>,<irq>
+
+ usb-handoff [HW] Enable early USB BIOS -> OS handoff
video= [FB] Frame buffer configuration
See Documentation/fb/modedb.txt.
diff -Nru a/drivers/pci/quirks.c b/drivers/pci/quirks.c
--- a/drivers/pci/quirks.c 2004-09-09 17:59:01 -07:00
+++ b/drivers/pci/quirks.c 2004-09-09 17:59:01 -07:00
@@ -826,6 +826,236 @@
pci_read_config_byte(dev, 0x77, &val);
}
+
+#define UHCI_USBLEGSUP 0xc0 /* legacy support */
+#define UHCI_USBCMD 0 /* command register */
+#define UHCI_USBSTS 2 /* status register */
+#define UHCI_USBINTR 4 /* interrupt register */
+#define UHCI_USBLEGSUP_DEFAULT 0x2000 /* only PIRQ enable set */
+#define UHCI_USBCMD_RUN (1 << 0) /* RUN/STOP bit */
+#define UHCI_USBCMD_GRESET (1 << 2) /* Global reset */
+#define UHCI_USBCMD_CONFIGURE (1 << 6) /* config semaphore */
+#define UHCI_USBSTS_HALTED (1 << 5) /* HCHalted bit */
+
+#define OHCI_CONTROL 0x04
+#define OHCI_CMDSTATUS 0x08
+#define OHCI_INTRSTATUS 0x0c
+#define OHCI_INTRENABLE 0x10
+#define OHCI_INTRDISABLE 0x14
+#define OHCI_OCR (1 << 3) /* ownership change request */
+#define OHCI_CTRL_IR (1 << 8) /* interrupt routing */
+#define OHCI_INTR_OC (1 << 30) /* ownership change */
+
+#define EHCI_HCC_PARAMS 0x08 /* extended capabilities */
+#define EHCI_USBCMD 0 /* command register */
+#define EHCI_USBCMD_RUN (1 << 0) /* RUN/STOP bit */
+#define EHCI_USBSTS 4 /* status register */
+#define EHCI_USBSTS_HALTED (1 << 12) /* HCHalted bit */
+#define EHCI_USBINTR 8 /* interrupt register */
+#define EHCI_USBLEGSUP 0 /* legacy support register */
+#define EHCI_USBLEGSUP_BIOS (1 << 16) /* BIOS semaphore */
+#define EHCI_USBLEGSUP_OS (1 << 24) /* OS semaphore */
+#define EHCI_USBLEGCTLSTS 4 /* legacy control/status */
+#define EHCI_USBLEGCTLSTS_SOOE (1 << 13) /* SMI on ownership change */
+
+int usb_early_handoff __initdata = 0;
+static int __init usb_handoff_early(char *str)
+{
+ usb_early_handoff = 1;
+ return 0;
+}
+__setup("usb-handoff", usb_handoff_early);
+
+static void __init quirk_usb_handoff_uhci(struct pci_dev *pdev)
+{
+ unsigned long base = 0;
+ int wait_time, delta;
+ u16 val, sts;
+ int i;
+
+ for (i = 0; i < PCI_ROM_RESOURCE; i++)
+ if ((pci_resource_flags(pdev, i) & IORESOURCE_IO)) {
+ base = pci_resource_start(pdev, i);
+ break;
+ }
+
+ if (!base)
+ return;
+
+ /*
+ * stop controller
+ */
+ sts = inw(base + UHCI_USBSTS);
+ val = inw(base + UHCI_USBCMD);
+ val &= ~(u16)(UHCI_USBCMD_RUN | UHCI_USBCMD_CONFIGURE);
+ outw(val, base + UHCI_USBCMD);
+
+ /*
+ * wait while it stops if it was running
+ */
+ if ((sts & UHCI_USBSTS_HALTED) == 0)
+ {
+ wait_time = 1000;
+ delta = 100;
+
+ do {
+ outw(0x1f, base + UHCI_USBSTS);
+ udelay(delta);
+ wait_time -= delta;
+ val = inw(base + UHCI_USBSTS);
+ if (val & UHCI_USBSTS_HALTED)
+ break;
+ } while (wait_time > 0);
+ }
+
+ /*
+ * disable interrupts & legacy support
+ */
+ outw(0, base + UHCI_USBINTR);
+ outw(0x1f, base + UHCI_USBSTS);
+ pci_read_config_word(pdev, UHCI_USBLEGSUP, &val);
+ if (val & 0xbf)
+ pci_write_config_word(pdev, UHCI_USBLEGSUP, UHCI_USBLEGSUP_DEFAULT);
+
+}
+
+static void __init quirk_usb_handoff_ohci(struct pci_dev *pdev)
+{
+ char *base;
+ int wait_time;
+
+ base = ioremap_nocache(pci_resource_start(pdev, 0),
+ pci_resource_len(pdev, 0));
+ if (base == NULL) return;
+
+ if (readl(base + OHCI_CONTROL) & OHCI_CTRL_IR) {
+ wait_time = 500; /* 0.5 seconds */
+ writel(OHCI_INTR_OC, base + OHCI_INTRENABLE);
+ writel(OHCI_OCR, base + OHCI_CMDSTATUS);
+ while (wait_time > 0 &&
+ readl(base + OHCI_CONTROL) & OHCI_CTRL_IR) {
+ wait_time -= 10;
+ set_current_state(TASK_UNINTERRUPTIBLE);
+ schedule_timeout((HZ*10 + 999) / 1000);
+ }
+ }
+
+ /*
+ * disable interrupts
+ */
+ writel(~(u32)0, base + OHCI_INTRDISABLE);
+ writel(~(u32)0, base + OHCI_INTRSTATUS);
+
+ iounmap(base);
+}
+
+static void __init quirk_usb_disable_ehci(struct pci_dev *pdev)
+{
+ int wait_time, delta;
+ char *base, *op_reg_base;
+ u32 hcc_params, val, temp;
+ u8 cap_length;
+
+ base = ioremap_nocache(pci_resource_start(pdev, 0),
+ pci_resource_len(pdev, 0));
+ if (base == NULL) return;
+
+ cap_length = readb(base);
+ op_reg_base = base + cap_length;
+ hcc_params = readl(base + EHCI_HCC_PARAMS);
+ hcc_params = (hcc_params >> 8) & 0xff;
+ if (hcc_params) {
+ pci_read_config_dword(pdev,
+ hcc_params + EHCI_USBLEGSUP,
+ &val);
+ if (((val & 0xff) == 1) && (val & EHCI_USBLEGSUP_BIOS)) {
+ /*
+ * Ok, BIOS is in smm mode, try to hand off...
+ */
+ pci_read_config_dword(pdev,
+ hcc_params + EHCI_USBLEGCTLSTS,
+ &temp);
+ pci_write_config_dword(pdev,
+ hcc_params + EHCI_USBLEGCTLSTS,
+ temp | EHCI_USBLEGCTLSTS_SOOE);
+ val |= EHCI_USBLEGSUP_OS;
+ pci_write_config_dword(pdev,
+ hcc_params + EHCI_USBLEGSUP,
+ val);
+
+ wait_time = 500;
+ do {
+ set_current_state(TASK_UNINTERRUPTIBLE);
+ schedule_timeout((HZ*10+999)/1000);
+ wait_time -= 10;
+ pci_read_config_dword(pdev,
+ hcc_params + EHCI_USBLEGSUP,
+ &val);
+ } while (wait_time && (val & EHCI_USBLEGSUP_BIOS));
+ if (!wait_time) {
+ /*
+ * well, possibly buggy BIOS...
+ */
+ printk(KERN_WARNING "EHCI early BIOS handoff "
+ "failed (BIOS bug ?)\n");
+ pci_write_config_dword(pdev,
+ hcc_params + EHCI_USBLEGSUP,
+ EHCI_USBLEGSUP_OS);
+ pci_write_config_dword(pdev,
+ hcc_params + EHCI_USBLEGCTLSTS,
+ 0);
+ }
+ }
+ }
+
+ /*
+ * halt EHCI & disable its interrupts in any case
+ */
+ val = readl(op_reg_base + EHCI_USBSTS);
+ if ((val & EHCI_USBSTS_HALTED) == 0) {
+ val = readl(op_reg_base + EHCI_USBCMD);
+ val &= ~EHCI_USBCMD_RUN;
+ writel(val, op_reg_base + EHCI_USBCMD);
+
+ wait_time = 2000;
+ delta = 100;
+ do {
+ writel(0x3f, op_reg_base + EHCI_USBSTS);
+ udelay(delta);
+ wait_time -= delta;
+ val = readl(op_reg_base + EHCI_USBSTS);
+ if ((val == ~(u32)0) || (val & EHCI_USBSTS_HALTED)) {
+ break;
+ }
+ } while (wait_time > 0);
+ }
+ writel(0, op_reg_base + EHCI_USBINTR);
+ writel(0x3f, op_reg_base + EHCI_USBSTS);
+
+ iounmap(base);
+
+ return;
+}
+
+
+
+static void __init quirk_usb_early_handoff(struct pci_dev *pdev)
+{
+ if (!usb_early_handoff)
+ return;
+
+ if (pdev->class == ((PCI_CLASS_SERIAL_USB << 8) | 0x00)) { /* UHCI */
+ quirk_usb_handoff_uhci(pdev);
+ } else if (pdev->class == ((PCI_CLASS_SERIAL_USB << 8) | 0x10)) { /* OHCI */
+ quirk_usb_handoff_ohci(pdev);
+ } else if (pdev->class == ((PCI_CLASS_SERIAL_USB << 8) | 0x20)) { /* EHCI */
+ quirk_usb_disable_ehci(pdev);
+ }
+
+ return;
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, quirk_usb_early_handoff);
+
/*
* ... This is further complicated by the fact that some SiS96x south
* bridges pretend to be 85C503/5513 instead. In that case see if we
diff -Nru a/include/asm-i386/mach-summit/mach_mpparse.h b/include/asm-i386/mach-summit/mach_mpparse.h
--- a/include/asm-i386/mach-summit/mach_mpparse.h 2004-09-09 17:59:01 -07:00
+++ b/include/asm-i386/mach-summit/mach_mpparse.h 2004-09-09 17:59:01 -07:00
@@ -22,6 +22,7 @@
{
}
+extern int usb_early_handoff;
static inline int mps_oem_check(struct mp_config_table *mpc, char *oem,
char *productid)
{
@@ -31,6 +32,7 @@
|| !strncmp(productid, "RUTHLESS SMP", 12))){
use_cyclone = 1; /*enable cyclone-timer*/
setup_summit();
+ usb_early_handoff = 1;
return 1;
}
return 0;
@@ -44,6 +46,7 @@
|| !strncmp(oem_table_id, "EXA", 3))){
use_cyclone = 1; /*enable cyclone-timer*/
setup_summit();
+ usb_early_handoff = 1;
return 1;
}
return 0;
On Wed, Oct 20, 2004 at 08:56:43PM +0100, Alan Cox wrote:
> On Maw, 2004-10-19 at 07:30, Vojtech Pavlik wrote:
> > Like 30% of all notebooks? ;) They do boot without the USB handoff, the
> > PS/2 mouse works, but only as a PS/2 mouse, no extended capabilities
> > detection is possible due to the BIOS interference.
>
> I started in favour of avoiding always doing the handoff, but now I'm
> convinced handoff should be the default.
And I would be fine to move the atkbd/psmouse initialization down in the
Makefiles so that USB gets initialized first - but what do we do about
the modular case?
I do agree that we should have only one copy of the handoff code,
regardless of where it's living.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Iau, 2004-10-21 at 00:22, Aleksey Gorelov wrote:
> Isn't this interrupt disabled at that point, and status are cleared
> right
> after handoff ? Have you actually been able to see a problem with such
> an interrupt with this patch applied ?
I've seen one Nvidia case where flipping the USB over caused an
immediate IRQ on that line.
On Oct 20, 2004, Alan Cox <[email protected]> wrote:
> On Llu, 2004-10-18 at 19:31, Alexandre Oliva wrote:
>> > Is there any consistancy with the type of hardware that you see being
>> > reported for this issue?
>>
>> I've googled around and found a lot of reports of such issues on the
>> HP Presario 3000Z series, as well as some other HP notebook series
>> (nx5000?) that (kind of :-) supports Athlon64 processors.
> The main problem ones in Red Hat bugzilla are anythign E7xxx based (this
> seems to be the department of lost causes), but which has a "fix" akin
> to Greg's for UHCI only and the HP (and other eMachines identical)
> laptops which is fixed by BIOS updating to the newer model (warranty and
> risk your own...)
Updating the BIOS doesn't actually fix my (Presario r3004). The
Errata #93 message become less common, but aren't completely gone, and
the touchpad isn't recognized either way. FWIW, a BIOS upgrade to my
wife's box (a supposed-to-be-identical notebook) makes the clock 3x
too fast. So upgrading the BIOS, even if it fixed the USB hand-off
problem, would make the box unusable for this other problem.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
On Oct 20, 2004, "Aleksey Gorelov" <[email protected]> wrote:
>> It would be ok if someone bothered to copy the USB core code (or better
>> yet call into it) but the patch in the -mm tree doesn't know about the
>> zillion OHCI controller bugs, and doesn't know about the suprise
>> interrupt on switch from BIOS->host you sometimes see.
> Isn't this interrupt disabled at that point, and status are cleared
> right after handoff?
I've no idea, but as soon as I started using the USB handoff patch,
I've consistently got the K8 Errata #93 message as the first message
(or maybe one of the first few) I get on boot.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
On Thu, Oct 21, 2004 at 08:21:03AM +0200, Vojtech Pavlik wrote:
> And I would be fine to move the atkbd/psmouse initialization down in the
> Makefiles so that USB gets initialized first - but what do we do about
> the modular case?
>
> I do agree that we should have only one copy of the handoff code,
> regardless of where it's living.
I just wanted to pipe up and say that I'm being hit by this same bug this
week. Except in my case, the system sometimes blows up and reboots during
kb probing (2.4.x kernel). I've not tried 2.6 on this box yet.
I don't know what the right answer is yet, but it sure is frustrating.
>-----Original Message-----
>From: Alan Cox [mailto:[email protected]]
>Sent: Thursday, October 21, 2004 2:35 AM
>To: Aleksey Gorelov
>Cc: Greg KH; Alexandre Oliva; Linux Kernel Mailing List;
>Vojtech Pavlik; Dmitry Torokhov
>Subject: RE: forcing PS/2 USB emulation off
>
>On Iau, 2004-10-21 at 00:22, Aleksey Gorelov wrote:
>> Isn't this interrupt disabled at that point, and status are cleared
>> right
>> after handoff ? Have you actually been able to see a problem
>with such
>> an interrupt with this patch applied ?
>
>I've seen one Nvidia case where flipping the USB over caused an
>immediate IRQ on that line.
>
I expect it to be disabled at controller level at the time patch works.
Probably, something enabled it before quirk in Nvidia case...
Aleks.