Bug 74989

Summary: (regression) Lost USB support between 5.2.1-RELEASE and 5.3-RELEASE on K7T266 Pro2.
Product: Base System Reporter: Julien Gabel <jpeg>
Component: usbAssignee: John Baldwin <jhb>
Status: Closed FIXED    
Severity: Affects Only Me CC: usb
Priority: Normal    
Version: 5.3-STABLE   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
dmesg.boot
none
pciconf_lv.out none

Description Julien Gabel 2004-12-12 16:10:09 UTC
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.
Comment 1 Julien Gabel 2004-12-12 16:27:00 UTC
> * 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.
Comment 2 Julien Gabel 2004-12-13 23:19:35 UTC
> 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.
Comment 3 Julien Gabel 2004-12-13 23:25:16 UTC
>> 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.
Comment 4 amistry 2004-12-13 23:33:16 UTC
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/
Comment 5 Julian Elischer 2004-12-13 23:34:54 UTC
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?

>
>  
>
Comment 6 Julien Gabel 2004-12-14 00:05:36 UTC
>> 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.
Comment 7 Julien Gabel 2004-12-17 19:07:27 UTC
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.
Comment 8 Julien Gabel 2005-02-08 07:19:44 UTC
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@.
Comment 9 Mark Linimon freebsd_committer freebsd_triage 2005-04-03 10:00:48 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-usb

Reassign to appropriate mailing list.
Comment 10 Julien Gabel 2005-04-14 11:41:54 UTC
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.
Comment 11 John Baldwin freebsd_committer freebsd_triage 2005-04-15 07:17:36 UTC
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
Comment 12 Julien Gabel 2005-04-15 14:31:18 UTC
>> 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.
Comment 13 Julien Gabel 2005-09-15 20:50:37 UTC
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.
Comment 14 John Baldwin freebsd_committer freebsd_triage 2005-11-29 21:50:06 UTC
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
Comment 15 Julien Gabel 2005-11-30 19:49:36 UTC
>>>> 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.
Comment 16 John Baldwin freebsd_committer freebsd_triage 2005-12-01 17:03:15 UTC
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
Comment 17 Julien Gabel 2005-12-01 21:34:24 UTC
>> 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.
Comment 18 John Baldwin freebsd_committer freebsd_triage 2005-12-02 13:11:30 UTC
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
Comment 19 Julien Gabel 2005-12-02 22:37:06 UTC
> 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.
Comment 20 John Baldwin freebsd_committer freebsd_triage 2005-12-03 21:26:57 UTC
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
Comment 21 John Baldwin freebsd_committer freebsd_triage 2005-12-03 21:27:44 UTC
State Changed
From-To: open->patched

Fix committed to HEAD, will MFC in a week or so. 


Comment 22 John Baldwin freebsd_committer freebsd_triage 2005-12-03 21:27:44 UTC
Responsible Changed
From-To: freebsd-usb->jhb

Fix committed to HEAD, will MFC in a week or so.
Comment 23 Julien Gabel 2005-12-04 21:05:59 UTC
>> 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.
Comment 24 John Baldwin freebsd_committer freebsd_triage 2005-12-05 05:11:27 UTC
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
Comment 25 John Baldwin freebsd_committer freebsd_triage 2005-12-12 19:33:43 UTC
State Changed
From-To: patched->closed

Fix merged to RELENG_6 and will be in 6.1.