As a side note, i previously posted about this problem on current@ during the release cycle of 5.3-RELEASE, but focusing on using a USB thumbdrive at this time. I realize later that it seems to be a general USB support problem, not just a relative one to the pendrive i use at this time. http://lists.freebsd.org/mailman/htdig/freebsd-current/2004-October/039444.html After trying the BETAs ans RCs just before the release of FreeBSD 5.3-RELEASE, i discovered that i can't use any USB ports on one of my systems (i did not encountered this problem on my notebook for example). Before that, i had use USB on this machine without problem running RELENG_5_2 (5.2.1-RELEASE-p11 at this time): i can use, without any problem, a 64MB USB thumbdrive, a USB mini notebook mouse and my Palm m500. But since this host follow the RELENG_5 branch for now, it seems impossible to have the USB subsystem working properly. So this *new* problem appears only on one of my machine and seems to be related to the motherboard i use: the K7T266 Pro2. As a side note, i previously posted about this problem on current@ during the release cycle of 5.3-RELEASE, but focusing on using a USB thumbdrive at this time. I realize later that it seems to be a general USB support problem, not just a relative one to the pendrive i use at this time. http://lists.freebsd.org/mailman/htdig/freebsd-current/2004-October/039444.html * Please, find the following files attached to this PR: - the output of 'pciconf -lv'; - the content of /var/run/dmesg.boot. -- -jpeg.
> * Please, find the following files attached to this PR: > - the output of 'pciconf -lv'; > - the content of /var/run/dmesg.boot. I re-attached the proposed files as it seems i encountered a problem using 'send-pr -a file'. To answer to Anish who asked me "What happens when you boot w/ without ACPI enabled?": i can say that i already try this without much success. I also try to _play_ with my BIOS settings... no luck here too. -- -jpeg.
> To answer to Anish who asked me "What happens when you boot w/ without > ACPI enabled?": i can say that i already try this without much success. > I also try to _play_ with my BIOS settings... no luck here too. Ok. After playing with my BIOS settings, i decided to reset them all. And here, i can say that i previously made a mistake: *disable* ACPI at boot time _do_ the trick! So, i ended with these two systems: - notebook: FreeBSD 5.2.1 + ACPI enable => USB ok - notebook: FreeBSD 5.3 + ACPI disable => USB ok - desktop: FreeBSD 5.2.1 + ACPI enable => USB ko :( - desktop: FreeBSD 5.3 + ACPI disable => USB ok The desktop is the machine equipped with the MSI K7T266 Pro2 motherboard. Note: the BIOS firmware is up to date with the last revision available. The update during the RELENG_5 branch seems to be at the origin of the USB support problem on this motherboard. -- -jpeg. PS: Sorry Anish for the mistake in the first place.
>> To answer to Anish who asked me "What happens when you boot w/ without >> ACPI enabled?": i can say that i already try this without much success. >> I also try to _play_ with my BIOS settings... no luck here too. > Ok. After playing with my BIOS settings, i decided to reset them all. > And here, i can say that i previously made a mistake: *disable* ACPI at > boot time _do_ the trick! > > So, i ended with these two systems: > - notebook: FreeBSD 5.2.1 + ACPI enable => USB ok > - notebook: FreeBSD 5.3 + ACPI disable => USB ok > > - desktop: FreeBSD 5.2.1 + ACPI enable => USB ko :( > - desktop: FreeBSD 5.3 + ACPI disable => USB ok I correct myself one more time: - notebook: FreeBSD 5.2.1 + ACPI enable => USB ok - notebook: FreeBSD 5.3 + ACPI enable => USB ok - notebook: FreeBSD 5.3 + ACPI disable => USB ok - desktop: FreeBSD 5.2.1 + ACPI enable => USB ok - desktop: FreeBSD 5.3 + ACPI enable => USB ko :( - desktop: FreeBSD 5.3 + ACPI disable => USB ok > The desktop is the machine equipped with the MSI K7T266 Pro2 motherboard. > Note: the BIOS firmware is up to date with the last revision available. > > The update during the RELENG_5 branch seems to be at the origin of the > USB support problem on this motherboard. -- -jpeg.
On Monday 13 December 2004 06:19 pm, Julien Gabel wrote: > > To answer to Anish who asked me "What happens when you boot w/ without > > ACPI enabled?": i can say that i already try this without much > > success. I also try to _play_ with my BIOS settings... no luck here > > too. > > Ok. After playing with my BIOS settings, i decided to reset them all. > And here, i can say that i previously made a mistake: *disable* ACPI at > boot time _do_ the trick! > > So, i ended with these two systems: > - notebook: FreeBSD 5.2.1 + ACPI enable => USB ok > - notebook: FreeBSD 5.3 + ACPI disable => USB ok > > - desktop: FreeBSD 5.2.1 + ACPI enable => USB ko :( > - desktop: FreeBSD 5.3 + ACPI disable => USB ok > > The desktop is the machine equipped with the MSI K7T266 Pro2 > motherboard. Note: the BIOS firmware is up to date with the last > revision available. > > The update during the RELENG_5 branch seems to be at the origin of the > USB support problem on this motherboard. Ok, so you should now checkout the ACPI debugging FAQ and post to the acpi list. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.html -- Anish Mistry amistry@am-productions.biz AM Productions http://am-productions.biz/
Julien Gabel wrote: >>To answer to Anish who asked me "What happens when you boot w/ without >>ACPI enabled?": i can say that i already try this without much success. >>I also try to _play_ with my BIOS settings... no luck here too. >> >> > >Ok. After playing with my BIOS settings, i decided to reset them all. >And here, i can say that i previously made a mistake: *disable* ACPI at >boot time _do_ the trick! > >So, i ended with these two systems: > - notebook: FreeBSD 5.2.1 + ACPI enable => USB ok > - notebook: FreeBSD 5.3 + ACPI disable => USB ok > > - desktop: FreeBSD 5.2.1 + ACPI enable => USB ko :( > - desktop: FreeBSD 5.3 + ACPI disable => USB ok > >The desktop is the machine equipped with the MSI K7T266 Pro2 motherboard. >Note: the BIOS firmware is up to date with the last revision available. > >The update during the RELENG_5 branch seems to be at the origin of the >USB support problem on this motherboard. > have you also disabled "legacy USB support"? so, in your estimation is the problem in the ACPI code or the USB code? > > >
>> Ok. After playing with my BIOS settings, i decided to reset them all. >> And here, i can say that i previously made a mistake: *disable* ACPI at >> boot time _do_ the trick! >> >> The desktop is the machine equipped with the MSI K7T266 Pro2 motherboard. >> Note: the BIOS firmware is up to date with the last revision available. >> >> The update during the RELENG_5 branch seems to be at the origin of the >> USB support problem on this motherboard. > have you also disabled "legacy USB support"? I try this parameter as well. Here is what i get: -------------------------------------------------------- USB Legacy Support | ACPI enable | ACPI disable -------------------------------------------------------- "disable" | USB ko :( | USB ko :( "all device" | USB ko :( | USB ok -------------------------------------------------------- > so, in your estimation is the problem in the ACPI code or the USB code? Sorry, i don't really know. I said it must be ACPI since it worked in a past release with ACPI enable, however it may be a problem in the USB code. I will try to submit debugging information on ACPI as pointed out by Anish. Are they any other tests i can do in order to know what this problem might be? -- -jpeg.
Hello, After trying the BETAs ans RCs just before the release of FreeBSD 5.3 release, i discovered that i can't use any USB ports on one of my systems (i did not encountered this problem on my notebook for example). As a side note, i previously posted about this problem on current@ during the release cycle of 5.3-RELEASE, but focusing on using a USB thumbdrive at this time. I realize later that it seems to be a general USB support problem, not just a relative one to the pendrive i use at this time. http://lists.freebsd.org/mailman/htdig/freebsd-current/2004-October/\ 039444.html After playing with my BIOS settings, i decided to reset them all. And here, i can say that *disable* ACPI at boot time _do_ the trick. I try these parameters as well. Here is what i get: -------------------------------------------------------- BIOS | FreeBSD 5.3 -------------------------------------------------------- USB Legacy Support | ACPI enable | ACPI disable -------------------------------------------------------- "disable" | USB ko :( | USB ko :( "all device" | USB ko :( | USB ok -------------------------------------------------------- So, i ended with these two systems: - notebook: FreeBSD 5.2.1 + ACPI enable => USB ok - notebook: FreeBSD 5.3 + ACPI enable => USB ok - notebook: FreeBSD 5.3 + ACPI disable => USB ok - desktop: FreeBSD 5.2.1 + ACPI enable => USB ok - desktop: FreeBSD 5.3 + ACPI enable => USB ko :( - desktop: FreeBSD 5.3 + ACPI disable => USB ok The desktop is the machine equipped with the MSI K7T266 Pro2 motherboard. The BIOS firmware (v3.7) is up to date with the last revision available. According to "Using and Debugging FreeBSD ACPI", here is the corresponding information: => Please find the ACPI Source Language for this motherboard at: http://www.thilelli.net/~jgabel/pub/PR/74989/MSI.Via.K7T266Pro2.asl => With ACPI enable: 1/ Boot FreeBSD using 'boot -v' Content of /boot/loader.conf: hw.acpi.verbose="1" (just in case) 2/ Content of /var/run/dmesg.boot available at: http://www.thilelli.net/~jgabel/pub/PR/74989/acpi-enable/dmesg.boot 3/ Output of 'sysctl hw.acpi': http://www.thilelli.net/~jgabel/pub/PR/74989/acpi-enable/sysctl_hw.acpi 4/ If i try to use some USB devices (a thumbdrive for example), i get the following in /var/log/messages and the output of 'usbdevs -v': http://www.thilelli.net/~jgabel/pub/PR/74989/acpi-enable/\ usb_thumbdrive.dmesg http://www.thilelli.net/~jgabel/pub/PR/74989/acpi-enable/usbdevs-v => With ACPI disable: 1/ Boot FreeBSD using 'boot -v' Content of /boot/loader.conf: hint.acpi.0.disabled="1" 2/ Content of /var/run/dmesg.boot available at: http://www.thilelli.net/~jgabel/pub/PR/74989/acpi-disable/dmesg.boot 3/ If i try to use some USB devices (a thumbdrive for example), i get the following in /var/log/messages and the output of 'usbdevs -v': http://www.thilelli.net/~jgabel/pub/PR/74989/acpi-disable/\ usb_thumbdrive.dmesg http://www.thilelli.net/~jgabel/pub/PR/74989/acpi-disable/usbdevs-v I don't know if the problem comes from the USB code or from the ACPI code: a conflict between the two exists. I am ready to try all patches and to test all suggestions if any. Thanks for your help, -- -jpeg.
Just a side note, the desktop on which the problem (still) occurs follow the RELENG_5 branch and the build used at this time is as follow: FreeBSD 5.3-STABLE #0: Fri Feb 4 05:38:57 CET 2005 But since mid/end-december 2004 (for ~2 months now _approximatively_) i encountered systematically an interrupt storm from the USB host controller which prevent me inevitably to be able to use all of ly USB devices: Interrupt storm detected on "irq10: uhci0 uhci1+"; throttling interrupt source In this context, if i reenable ACPI support on boot, i didn't see any interrupt storm problem anymore... but i still can't use USB on this system. So, i now had an unusable USB system: - ACPI disable / uhci interrupt storm (doesn't even get the device created on the fly) => unusable USB devices - ACPI enable / "conflict" with USB stack (doesn't even get the device created on the fly) => unusable USB devices Any advice? -- -jpeg. PS: Please CC me, since i am not a suscriber of freebsd-acpi@ nor freebsd-usb@.
Responsible Changed From-To: freebsd-bugs->freebsd-usb Reassign to appropriate mailing list.
Hello, I made some progress here. After playing with BIOS settings, i am now able to: - Boot with ACPI enable (shutdown -p works as expected now); - Use USB devices. In order to do that, i had to totally disable "APIC Function" in the BIOS. With "APIC Function" enabled, neither version 1.4 nor 1.1 of the "MPS Table Version" settings solved my problem. So, although i meed to disable "APIC Function", all seems to works correctly together: ACPI support and USB support. As a side note, i did not encountered anymore the interrupt storm on the uhci USB host controller driver. Maybe can someone explain me what may be wrong with "APIC Function", and if there is some drawbacks to disable it (or what is the purpose of this setting)? -- -jpeg.
On Thursday 14 April 2005 06:41 am, Julien Gabel wrote: > Hello, > > I made some progress here. After playing with BIOS settings, i am now > able to: > - Boot with ACPI enable (shutdown -p works as expected now); > - Use USB devices. > > In order to do that, i had to totally disable "APIC Function" in the > BIOS. With "APIC Function" enabled, neither version 1.4 nor 1.1 of the > "MPS Table Version" settings solved my problem. > > So, although i meed to disable "APIC Function", all seems to works > correctly together: ACPI support and USB support. As a side note, i > did not encountered anymore the interrupt storm on the uhci USB host > controller driver. > > Maybe can someone explain me what may be wrong with "APIC Function", > and if there is some drawbacks to disable it (or what is the purpose > of this setting)? APIC is used to route interrupts differently. You can also disable it from the loader with 'hint.apic.0.disabled=1'. I've looked at your dmesg's, and the problem is that in the ACPI case the IRQ 10 that your USB controllers are using is configured as an ISA IRQ (edge/high). For now you can either disable APIC or ACPI as a workaround until I figure out a better solution. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
>> I made some progress here. After playing with BIOS settings, i am now >> able to: >> - Boot with ACPI enable (shutdown -p works as expected now); >> - Use USB devices. >> >> In order to do that, i had to totally disable "APIC Function" in the >> BIOS. With "APIC Function" enabled, neither version 1.4 nor 1.1 of the >> "MPS Table Version" settings solved my problem. >> >> So, although i need to disable "APIC Function", all seems to works >> correctly together: ACPI support and USB support. As a side note, i >> did not encountered anymore the interrupt storm on the uhci USB host >> controller driver. >> >> Maybe can someone explain me what may be wrong with "APIC Function", >> and if there is some drawbacks to disable it (or what is the purpose >> of this setting)? > APIC is used to route interrupts differently. You can also disable it > from the loader with 'hint.apic.0.disabled=1'. I've looked at your > dmesg's, and the problem is that in the ACPI case the IRQ 10 that your > USB controllers are using is configured as an ISA IRQ (edge/high). For > now you can either disable APIC or ACPI as a workaround until I figure > out a better solution. Thanks. I effectively prefer turn APIC off via the loader configuration than from the BIOS settings, i think it is far more easily to remember what i have done from this place. I can try patch(es) or make test(s) without problem on this machine, if any. Thanks a lot. -- -jpeg.
A little update to report that the same problem (and same workaround) can be noted on RELENG_6, e.g. using a kernel and a world from: FreeBSD titeuf.thilelli.net 6.0-BETA4 FreeBSD 6.0-BETA4 #0: Tue Sep 13 21:44:35 CEST 2005 root@titeuf.thilelli.net:/usr/obj/usr/src/sys/TITEUF i386 -- -jpeg.
On Friday 15 April 2005 09:31 am, Julien Gabel wrote: > >> I made some progress here. After playing with BIOS settings, i am now > >> able to: > >> - Boot with ACPI enable (shutdown -p works as expected now); > >> - Use USB devices. > >> > >> In order to do that, i had to totally disable "APIC Function" in the > >> BIOS. With "APIC Function" enabled, neither version 1.4 nor 1.1 of the > >> "MPS Table Version" settings solved my problem. > >> > >> So, although i need to disable "APIC Function", all seems to works > >> correctly together: ACPI support and USB support. As a side note, i > >> did not encountered anymore the interrupt storm on the uhci USB host > >> controller driver. > >> > >> Maybe can someone explain me what may be wrong with "APIC Function", > >> and if there is some drawbacks to disable it (or what is the purpose > >> of this setting)? > > > > APIC is used to route interrupts differently. You can also disable it > > from the loader with 'hint.apic.0.disabled=1'. I've looked at your > > dmesg's, and the problem is that in the ACPI case the IRQ 10 that your > > USB controllers are using is configured as an ISA IRQ (edge/high). For > > now you can either disable APIC or ACPI as a workaround until I figure > > out a better solution. > > Thanks. I effectively prefer turn APIC off via the loader configuration > than from the BIOS settings, i think it is far more easily to remember > what i have done from this place. > > I can try patch(es) or make test(s) without problem on this machine, if > any. Thanks a lot. Actually, can you try this patch: Index: acpi_pci_link.c =================================================================== RCS file: /host/cvs/usr/cvs/src/sys/dev/acpica/acpi_pci_link.c,v retrieving revision 1.48 diff -u -r1.48 acpi_pci_link.c --- acpi_pci_link.c 1 Nov 2005 22:44:07 -0000 1.48 +++ acpi_pci_link.c 28 Nov 2005 13:03:29 -0000 @@ -859,7 +859,18 @@ if (!link->l_routed && PCI_INTERRUPT_VALID(link->l_irq)) { link->l_routed = TRUE; + /* + * Some BIOSen are broken and actually set + * some interrupts to active-high with level + * trigger. Workaround this by hard-coding + * active-low and level-trigger. + */ +#if 0 acpi_config_intr(dev, resource); +#else + BUS_CONFIG_INTR(dev, link->l_irq, + INTR_TRIGGER_LEVEL, INTR_POLARITY_LOW); +#endif pci_link_interrupt_weights[link->l_irq] += link->l_references; } -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
>>>> I made some progress here. After playing with BIOS settings, i am now >>>> able to: >>>> - Boot with ACPI enable (shutdown -p works as expected now); >>>> - Use USB devices. >>>> >>>> In order to do that, i had to totally disable "APIC Function" in the >>>> BIOS. With "APIC Function" enabled, neither version 1.4 nor 1.1 of >>>> the "MPS Table Version" settings solved my problem. >>>> >>>> So, although i need to disable "APIC Function", all seems to works >>>> correctly together: ACPI support and USB support. As a side note, i >>>> did not encountered anymore the interrupt storm on the uhci USB host >>>> controller driver. >>>> >>>> Maybe can someone explain me what may be wrong with "APIC Function", >>>> and if there is some drawbacks to disable it (or what is the purpose >>>> of this setting)? >>> APIC is used to route interrupts differently. You can also disable it >>> from the loader with 'hint.apic.0.disabled=1'. I've looked at your >>> dmesg's, and the problem is that in the ACPI case the IRQ 10 that your >>> USB controllers are using is configured as an ISA IRQ (edge/high). >>> For now you can either disable APIC or ACPI as a workaround until I >>> figure out a better solution. >> Thanks. I effectively prefer turn APIC off via the loader configuration >> than from the BIOS settings, i think it is far more easily to remember >> what i have done from this place. >> I can try patch(es) or make test(s) without problem on this machine, if >> any. Thanks a lot. > Actually, can you try this patch: > > Index: acpi_pci_link.c > =================================================================== > RCS file: /host/cvs/usr/cvs/src/sys/dev/acpica/acpi_pci_link.c,v > retrieving revision 1.48 > diff -u -r1.48 acpi_pci_link.c > --- acpi_pci_link.c 1 Nov 2005 22:44:07 -0000 1.48 > +++ acpi_pci_link.c 28 Nov 2005 13:03:29 -0000 > @@ -859,7 +859,18 @@ > if (!link->l_routed && > PCI_INTERRUPT_VALID(link->l_irq)) { > link->l_routed = TRUE; > + /* > + * Some BIOSen are broken and actually set > + * some interrupts to active-high with level > + * trigger. Workaround this by hard-coding > + * active-low and level-trigger. > + */ > +#if 0 > acpi_config_intr(dev, resource); > +#else > + BUS_CONFIG_INTR(dev, link->l_irq, > + INTR_TRIGGER_LEVEL, INTR_POLARITY_LOW); > +#endif > pci_link_interrupt_weights[link->l_irq] += > link->l_references; > } I applied this patch, rebuild and installed the kernel, set the loader.conf directive `hint.apic.0.disabled' to "0" and reboot on the system. Sadly, the same behaviour happened (as before), i.e. USB mouse simply hang, USB thumbdrive doesn't work, etc. The patch was applied on src/sys/dev/acpica/acpi_pci_link.c before your last commit on RELENG_6 (version 1.44.2.4, 2005/11/30 16:03:55). Don't know if this may change something or not in this case. -- -jpeg.
On Wednesday 30 November 2005 02:49 pm, Julien Gabel wrote: > >>>> I made some progress here. After playing with BIOS settings, i am now > >>>> able to: > >>>> - Boot with ACPI enable (shutdown -p works as expected now); > >>>> - Use USB devices. > >>>> > >>>> In order to do that, i had to totally disable "APIC Function" in the > >>>> BIOS. With "APIC Function" enabled, neither version 1.4 nor 1.1 of > >>>> the "MPS Table Version" settings solved my problem. > >>>> > >>>> So, although i need to disable "APIC Function", all seems to works > >>>> correctly together: ACPI support and USB support. As a side note, i > >>>> did not encountered anymore the interrupt storm on the uhci USB host > >>>> controller driver. > >>>> > >>>> Maybe can someone explain me what may be wrong with "APIC Function", > >>>> and if there is some drawbacks to disable it (or what is the purpose > >>>> of this setting)? > >>> > >>> APIC is used to route interrupts differently. You can also disable it > >>> from the loader with 'hint.apic.0.disabled=1'. I've looked at your > >>> dmesg's, and the problem is that in the ACPI case the IRQ 10 that your > >>> USB controllers are using is configured as an ISA IRQ (edge/high). > >>> For now you can either disable APIC or ACPI as a workaround until I > >>> figure out a better solution. > >> > >> Thanks. I effectively prefer turn APIC off via the loader configuration > >> than from the BIOS settings, i think it is far more easily to remember > >> what i have done from this place. > >> > >> I can try patch(es) or make test(s) without problem on this machine, if > >> any. Thanks a lot. > > > > Actually, can you try this patch: > > > > Index: acpi_pci_link.c > > =================================================================== > > RCS file: /host/cvs/usr/cvs/src/sys/dev/acpica/acpi_pci_link.c,v > > retrieving revision 1.48 > > diff -u -r1.48 acpi_pci_link.c > > --- acpi_pci_link.c 1 Nov 2005 22:44:07 -0000 1.48 > > +++ acpi_pci_link.c 28 Nov 2005 13:03:29 -0000 > > @@ -859,7 +859,18 @@ > > if (!link->l_routed && > > PCI_INTERRUPT_VALID(link->l_irq)) { > > link->l_routed = TRUE; > > + /* > > + * Some BIOSen are broken and actually set > > + * some interrupts to active-high with level > > + * trigger. Workaround this by hard-coding > > + * active-low and level-trigger. > > + */ > > +#if 0 > > acpi_config_intr(dev, resource); > > +#else > > + BUS_CONFIG_INTR(dev, link->l_irq, > > + INTR_TRIGGER_LEVEL, INTR_POLARITY_LOW); > > +#endif > > pci_link_interrupt_weights[link->l_irq] += > > link->l_references; > > } > > I applied this patch, rebuild and installed the kernel, set the loader.conf > directive `hint.apic.0.disabled' to "0" and reboot on the system. Sadly, > the same behaviour happened (as before), i.e. USB mouse simply hang, USB > thumbdrive doesn't work, etc. > > The patch was applied on src/sys/dev/acpica/acpi_pci_link.c before your > last commit on RELENG_6 (version 1.44.2.4, 2005/11/30 16:03:55). Don't > know if this may change something or not in this case. Well, I can't get to your dmesg's anymore. If I understand correctly, USB works for you so long as you have APIC disabled, both with ACPI enabled and disabled correct? And USB is broken if you have both ACPI and APIC enabled. Have you tried booting with ACPI disabled (hint.acpi.0.disabled=1) but with APIC enabled? Does it work then or break? -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
>> I applied this patch, rebuild and installed the kernel, set the >> loader.conf directive `hint.apic.0.disabled' to "0" and reboot on the >> system. Sadly, the same behaviour happened (as before), i.e. USB mouse >> simply hang, USB thumbdrive doesn't work, etc. >> >> The patch was applied on src/sys/dev/acpica/acpi_pci_link.c before your >> last commit on RELENG_6 (version 1.44.2.4, 2005/11/30 16:03:55). Don't >> know if this may change something or not in this case. > Well, I can't get to your dmesg's anymore. If I understand correctly, Yes, sorry: the layout of the website was changed recently. Here are the corresponding files (using RELENG_5 at this time): http://www.thilelli.net/~jgabel/store/pub/PR/74989/ > USB works for you so long as you have APIC disabled, both with ACPI > enabled and disabled correct? And USB is broken if you have both ACPI > and APIC enabled. Have you tried booting with ACPI disabled > (hint.acpi.0.disabled=1) but with APIC enabled? Does it work then or > break? More precisely, here is a little tab... to be more accurate (i hope): --------------------------------------- USB support | ACPI | APIC | ------------------------ | on | off | on | off | --------------------------------------- KO! | XX | | XX | | --------------------------------------- ok | XX | | | XX | --------------------------------------- ok | | XX | XX | | --------------------------------------- Did not boot(*)| | XX | | XX | --------------------------------------- (*) The boot disk seems not be able to be used for the root mount, i.e. ufs:/dev/ad0s1a in my case. Note: this box currently run the RELENG_6 branch, build at Wed Nov 30 07:12:41 CET 2005. -- -jpeg.
On Thursday 01 December 2005 04:34 pm, Julien Gabel wrote: > >> I applied this patch, rebuild and installed the kernel, set the > >> loader.conf directive `hint.apic.0.disabled' to "0" and reboot on the > >> system. Sadly, the same behaviour happened (as before), i.e. USB mouse > >> simply hang, USB thumbdrive doesn't work, etc. > >> > >> The patch was applied on src/sys/dev/acpica/acpi_pci_link.c before your > >> last commit on RELENG_6 (version 1.44.2.4, 2005/11/30 16:03:55). Don't > >> know if this may change something or not in this case. > > > > Well, I can't get to your dmesg's anymore. If I understand correctly, > > Yes, sorry: the layout of the website was changed recently. Here are > the corresponding files (using RELENG_5 at this time): > http://www.thilelli.net/~jgabel/store/pub/PR/74989/ Ok, yours is a more odd case. :) This is debatably a bug in your ASL, but = I=20 think we can work around it. It is routing your USB interrupts to IRQ 10 b= ut=20 is not using a link device to do it, and it is not including an INTR_OVERRI= DE=20 entry in the MADT to change IRQ 10 from the default of edge/trigger to=20 level/low. The patch below forces all hard-wired PCI interrupts routed via= =20 ACPI to be level/low. This patch should apply both to HEAD and 6.x and may= be=20 5.x. Index: acpi_pcib.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /host/cvs/usr/cvs/src/sys/dev/acpica/acpi_pcib.c,v retrieving revision 1.58 diff -u -r1.58 acpi_pcib.c =2D-- acpi_pcib.c 7 Nov 2005 21:48:45 -0000 1.58 +++ acpi_pcib.c 2 Dec 2005 13:08:16 -0000 @@ -252,9 +252,11 @@ if (bootverbose) device_printf(pcib, "slot %d INT%c hardwired to IRQ %d\n", pci_get_slot(dev), 'A' + pin, prt->SourceIndex); =2D if (prt->SourceIndex) + if (prt->SourceIndex) { interrupt =3D prt->SourceIndex; =2D else + BUS_CONFIG_INTR(dev, interrupt, INTR_TRIGGER_LEVEL, + INTR_POLARITY_LOW); + } else device_printf(pcib, "error: invalid hard-wired IRQ of 0\n"); goto out; } > More precisely, here is a little tab... to be more accurate (i hope): > > --------------------------------------- > USB support | ACPI | APIC | > ------------------------ > > | on | off | on | off | > > --------------------------------------- > Did not boot(*)| | XX | | XX | > --------------------------------------- > (*) The boot disk seems not be able to be used for the root mount, i.e. > ufs:/dev/ad0s1a in my case. If you could get a verbose dmesg for this case using a serial console I'd b= e=20 interested in looking at that too. =2D-=20 John Baldwin <jhb@FreeBSD.org> =A0<>< =A0http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" =A0=3D =A0http://www.FreeBSD.org
> Ok, yours is a more odd case. :) This is debatably a bug in your ASL, > but I think we can work around it. It is routing your USB interrupts > to IRQ 10 but is not using a link device to do it, and it is not > including an INTR_OVERRIDE entry in the MADT to change IRQ 10 from the > default of edge/trigger to level/low. The patch below forces all > hard-wired PCI interrupts routed via ACPI to be level/low. This patch > should apply both to HEAD and 6.x and maybe 5.x. > > Index: acpi_pcib.c > [...] Ok. I think you finally got it this time. Applied this patch against RELENG_6 and it seems to work fine now. I build and installed the kernel, set the loader.conf directives hint.acpi.0.disabled to 0 hint.apic.0.disabled to 0 and reboot on the system... it works well now, thank you ;) >> More precisely, here is a little tab... to be more accurate (i hope): >> >> --------------------------------------- >> USB support | ACPI | APIC | >> ------------------------ >> | on | off | on | off | >> --------------------------------------- >> Did not boot(*)| | XX | | XX | >> --------------------------------------- >> (*) The boot disk seems not be able to be used for the root mount, i.e. >> ufs:/dev/ad0s1a in my case. > If you could get a verbose dmesg for this case using a serial console I'd > be interested in looking at that too. Certainly! The output can be found at: http://www.thilelli.net/~jgabel/store/pub/PR/74989/serial.dmesg.boot-v Note: the kernel used for this boot was the just-previously-patched one. -- -jpeg.
On Friday 02 December 2005 05:37 pm, Julien Gabel wrote: > > Ok, yours is a more odd case. :) This is debatably a bug in your ASL, > > but I think we can work around it. It is routing your USB interrupts > > to IRQ 10 but is not using a link device to do it, and it is not > > including an INTR_OVERRIDE entry in the MADT to change IRQ 10 from the > > default of edge/trigger to level/low. The patch below forces all > > hard-wired PCI interrupts routed via ACPI to be level/low. This patch > > should apply both to HEAD and 6.x and maybe 5.x. > > > > Index: acpi_pcib.c > > [...] > > Ok. I think you finally got it this time. Applied this patch against > RELENG_6 and it seems to work fine now. I build and installed the kernel, > set the loader.conf directives > hint.acpi.0.disabled to 0 > hint.apic.0.disabled to 0 > and reboot on the system... it works well now, thank you ;) Ok, fix committed. It will be in 6.1 as well. > >> More precisely, here is a little tab... to be more accurate (i hope): > >> > >> --------------------------------------- > >> USB support | ACPI | APIC | > >> ------------------------ > >> > >> | on | off | on | off | > >> > >> --------------------------------------- > >> Did not boot(*)| | XX | | XX | > >> --------------------------------------- > >> (*) The boot disk seems not be able to be used for the root mount, i.e. > >> ufs:/dev/ad0s1a in my case. > > > > If you could get a verbose dmesg for this case using a serial console I= 'd > > be interested in looking at that too. > > Certainly! The output can be found at: > http://www.thilelli.net/~jgabel/store/pub/PR/74989/serial.dmesg.boot-v > > Note: the kernel used for this boot was the just-previously-patched one. Ok, what happens here is that the $PIR code ends up using IRQ 14 for a=20 virgin-routed link. You can just use a tunable to override this like so: hw.pci.link.0x1.irq=3D12 That should make the vga adapter use irq 12 rather than irq 14. If you hav= e a=20 BIOS setting that says 'enable VGA irq' you could also try turning that on.= =20 However, you'd probably much rather be running with ACPI + APIC enabled=20 anyway. =2D-=20 John Baldwin <jhb@FreeBSD.org> =A0<>< =A0http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" =A0=3D =A0http://www.FreeBSD.org
State Changed From-To: open->patched Fix committed to HEAD, will MFC in a week or so.
Responsible Changed From-To: freebsd-usb->jhb Fix committed to HEAD, will MFC in a week or so.
>> Ok. I think you finally got it this time. Applied this patch against >> RELENG_6 and it seems to work fine now. I build and installed the >> kernel, set the loader.conf directives >> hint.acpi.0.disabled to 0 >> hint.apic.0.disabled to 0 >> and reboot on the system... it works well now, thank you ;) > Ok, fix committed. It will be in 6.1 as well. Good news, thanks! >>>> (*) The boot disk seems not be able to be used for the root mount, >>>> i.e. ufs:/dev/ad0s1a in my case. >>> If you could get a verbose dmesg for this case using a serial console >>> I'd be interested in looking at that too. >> Certainly! The output can be found at: >> http://www.thilelli.net/~jgabel/store/pub/PR/74989/serial.dmesg.boot-v >> >> Note: the kernel used for this boot was the just-previously-patched one. > Ok, what happens here is that the $PIR code ends up using IRQ 14 for a > virgin-routed link. You can just use a tunable to override this like so: > > hw.pci.link.0x1.irq=12 Yes, this setting solved the problem with both ACPI and APIC support disabled. > That should make the vga adapter use irq 12 rather than irq 14. If you > have a BIOS setting that says 'enable VGA irq' you could also try > turning that on. However, you'd probably much rather be running with > ACPI + APIC enabled anyway. Sure... ;) Just a little question though: what can i "expect", from now on, to have ACPI and APIC enabled in the same time, rather than ACPI support alone (without APIC)? -- -jpeg.
On Dec 4, 2005, at 4:05 PM, Julien Gabel wrote: >> Ok, what happens here is that the $PIR code ends up using IRQ 14 >> for a >> virgin-routed link. You can just use a tunable to override this >> like so: >> >> hw.pci.link.0x1.irq=12 > > Yes, this setting solved the problem with both ACPI and APIC support > disabled. Ok. >> That should make the vga adapter use irq 12 rather than irq 14. >> If you >> have a BIOS setting that says 'enable VGA irq' you could also try >> turning that on. However, you'd probably much rather be running with >> ACPI + APIC enabled anyway. > > Sure... ;) > > Just a little question though: what can i "expect", from now on, to > have > ACPI and APIC enabled in the same time, rather than ACPI support alone > (without APIC)? Well, out of the box we default to ACPI + APIC, so I'd just stick to using that with the patch I just committed. 6.1 and later should just work out of the box on your system now. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
State Changed From-To: patched->closed Fix merged to RELENG_6 and will be in 6.1.