Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 2 Dec 2005 23:37:06 +0100 (CET)
From:      "Julien Gabel" <jpeg@thilelli.net>
To:        "John Baldwin" <jhb@freebsd.org>
Cc:        freebsd-acpi@freebsd.org, freebsd-usb@freebsd.org, bug-followup@freebsd.org
Subject:   Re: usb/74989: (regression) Lost USB support between 5.2.1-RELEASE  and 5.3-RELEASE on K7T266 Pro2.
Message-ID:  <62227.192.168.1.20.1133563026.squirrel@webmail.thilelli.net>
In-Reply-To: <200512020811.33720.jhb@freebsd.org>
References:  <49704.192.168.1.18.1113475314.squirrel@webmail.thilelli.net> <200512011203.17304.jhb@freebsd.org> <49547.192.168.1.20.1133472864.squirrel@webmail.thilelli.net> <200512020811.33720.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
> 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.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?62227.192.168.1.20.1133563026.squirrel>