Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]

Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]

[Johny]

Firstly, apologies for a) the massive x-post and b) the time taken to 
get back to people... Please let me know where this is most 
appropriately dealt with and I'll keep it off other lists, considering 
the latest information;

Andrew - please note - this is not a problem exclusive to the -mm 
series, on testing various combos I found it in the stock series too.

Stock kernels break for me starting with 2.6.17-rc4 (I tested all rcs 
and also .17 itself), rc3 works a treat for using USB. I suspect the 
following line missing in dmesg for rc4 is the reason;

-PCI: Via IRQ fixup for 0000:00:11.1, from 255 to 11

See the following dmesg files for details;

http://www.agotnes.com/kernelStuff/dmesg-2.6.17-rc3-working
http://www.agotnes.com/kernelStuff/dmesg-2.6.17-rc4-not-working

And the diff, for convenience;

http://www.agotnes.com/kernelStuff/diff-rc3_rc4

I have a Via chipset motherboard (for my sins), further details 
available on request, again, for convenience, the lspci;

http://www.agotnes.com/kernelStuff/lspci

A couple of possible suspect patches introduced in the changelog for rc4 
were (with the first one looking particularly interesting, the others 
less interesting as I go down the list);

[PATCH] PCI quirk: VIA IRQ fixup should only run for VIA southbridges
[PATCH] x86_64: avoid IRQ0 ioapic pin collision
[PATCH] PCI: fix via irq SATA patch
[ALSA] via82xx - Use DXS_SRC as default for VIA8235/8237/8251 chips
[ALSA] via82xx: tweak VT8251 workaround
[ALSA] via82xx: add support for VIA VT8251 (AC'97)

I'm no kernel hacker, so I'm not sure how I'd isolate this one patch and 
reverse / modify it. Please let me know how I can progress testing this 
as I'm currently prevented from using USB with the latest set of kernels 
on my test server...

I've got all kernels in the 2.6.17-rc1 through to .17 itself there, plus 
a variety of mm ones too, so patches against any of those I can very 
easily test.

Please keep me cc'd as I'm not on all these lists, thanks :)

:)Johny

Johny Ågotnes wrote:
> didn't go through due to missing vger. ...
> 
> ------------------------------------------------------------------------
> 
> Subject:
> Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues
> From:
> Johny <kernel@agotnes.com>
> Date:
> Sun, 18 Jun 2006 21:37:00 +1000
> To:
> Alan Stern <stern@rowland.harvard.edu>
> 
> To:
> Alan Stern <stern@rowland.harvard.edu>
> CC:
> Johny <kernel@agotnes.com>, USB development list 
> <linux-usb-devel@lists.sourceforge.net>, kernel list 
> <linux-kernel@vger.kernel.org>, linux-acpi@kernel.org, akpm@osdl.org
> 
> 
> All,
> 
> I've now tested the following;
> 
> 2.6.17-rc6-mm2 with the following patch applied;
> ---
> git-acpi.patch from 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc6/2.6.17-rc6-mm2/broken-out/ 
> 
> ---
> 
> With no difference to the end-result.
> 
> Next I stripped out 802.11 generic support and acx111 drivers from the 
> kernel (including the acpi patches) to check if it clashes, but the same 
> errors occur....
> 
> Thirdly, I booted with acpi=off on the command line with two kernels, 
> the stock 2.6.17-rc6-mm2 (no acpi patch and including acx111) and the 
> one including the acpi patch and no acx111, the results were;
> 
> acpi_patch;
> works a treat, picks up USB devices as expected.
> 
> stock;
> works a treat, picks up USB devices as expected, and my acx111 card 
> works too :)
> 
> 
> Now I'm looking for good suggestions again, this definitely looks like 
> it is related to ACPI, hence the cc' to that list too, as requested by 
> Andrew M.
> 
> I'm happy to apply patches / config changes as appropriate and for those 
> who may ask for my .config files, please see;
> 
> http://www.agotnes.com/kernelStuff/config-2.6.17-rc6-mm2
> 
> http://www.agotnes.com/kernelStuff/config-2.6.17-rc6-mm2git-acpi_patch
> 
> Also, I left the output of lspci there for reference;
> 
> http://www.agotnes.com/kernelStuff/lspci
> 
> Cheers,
> 
> :)Johny
> 
> Alan Stern wrote:
>> [Moved to linux-usb-devel in the hope of getting additional help]
>>
>> On Thu, 15 Jun 2006, Johny wrote:
>>
>>> Alan,
>>>
>>> See comments interspersed, thanks for your assistance :)
>>>
>>> Alan Stern wrote:
>>>> On Tue, 13 Jun 2006, Johny wrote:
>>>>
>>>>> Is this best suited to this mailing list?
>>>> It's appropriate.
>>>>
>>>>> I tried the kernel list with zero responses (so far ;), let me know 
>>>>> if there is
>>>>> anywhere else this should go.
>>>> ...
>>>>
>>>>> Johny Ågotnes wrote:
>>>>>> All,
>>>>>>
>>>>>> My USB hub isn't recognised with the latest -mm series, whereas with
>>>>>> 2.6.16 vanilla it is picked up & used immediately.
>>>>>>
>>>>>> The error I get in dmesg is;
>>>>>>
>>>>>> hub 4-0:1.0: USB hub found
>>>>>> hub 4-0:1.0: 2 ports detected
>>>>>> usb 1-4: new high speed USB device using ehci_hcd and address 3
>>>>>> ehci_hcd 0000:00:10.3: Unlink after no-IRQ?  Controller is probably
>>>>>> using the wrong IRQ.
>>>> That last line is a clue.  What interrupt numbers are assigned under
>>>> 2.6.16?  If you unplug the SonyEricsson DCU-11 Cable before booting 
>>>> (and
>>>> leave it unplugged), what shows up in /proc/interrupts for both 
>>>> versions
>>>> of the kernel?
>>> See attached, both with the DCU-11 cable disconnected.
>>
>> From 2.6.16:
>>            CPU0         0:      16101          XT-PIC  timer
>>   1:        148          XT-PIC  i8042
>>   2:          0          XT-PIC  cascade
>>   7:          0          XT-PIC  parport0
>>   9:          0          XT-PIC  acpi
>>  10:        151          XT-PIC  ehci_hcd:usb1, uhci_hcd:usb4
>>  11:          0          XT-PIC  uhci_hcd:usb2, uhci_hcd:usb3
>>  12:        138          XT-PIC  i8042
>>  14:        172          XT-PIC  ide0
>>  15:       2458          XT-PIC  ide1
>> NMI:          0 ERR:          0
>>
>> From 2.6.17:
>>            CPU0         0:      35651    XT-PIC-level    timer
>>   1:        129    XT-PIC-level    i8042
>>   2:          0    XT-PIC-level    cascade
>>   6:          3    XT-PIC-level    floppy
>>   7:          0    XT-PIC-level    parport0
>>   9:          0    XT-PIC-level    acpi
>>  10:          0    XT-PIC-level    ehci_hcd:usb1, uhci_hcd:usb4
>>  11:       1940    XT-PIC-level    uhci_hcd:usb2, uhci_hcd:usb3, wlan0
>>  12:        162    XT-PIC-level    i8042
>>  14:        171    XT-PIC-level    ide0
>>  15:       4251    XT-PIC-level    ide1
>> NMI:          0 ERR:          0
>>
>> There's nothing obviously wrong.
>>
>>>> Most likely this is a problem with the ACPI subsystem, not a USB 
>>>> problem.
>>>>
>>> I guessed USB due to the number of USB changes in the -mm series and, 
>>> obviously, my USB devices stopped registering, however, I'd not know 
>>> one from the other ;)
>>
>> What happens if you boot with "acpi=off" on the boot command line?
>>
>> Alan Stern
>>

Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]

[Andrew Morton]

On Tue, 20 Jun 2006 21:21:35 +1000
Johny <kernel@agotnes.com> wrote:

> Firstly, apologies for a) the massive x-post and b) the time taken to 
> get back to people... Please let me know where this is most 
> appropriately dealt with and I'll keep it off other lists, considering 
> the latest information;
> 
> Andrew - please note - this is not a problem exclusive to the -mm 
> series, on testing various combos I found it in the stock series too.

Thanks for persisting with this.

> Stock kernels break for me starting with 2.6.17-rc4 (I tested all rcs 
> and also .17 itself), rc3 works a treat for using USB. I suspect the 
> following line missing in dmesg for rc4 is the reason;
> 
> -PCI: Via IRQ fixup for 0000:00:11.1, from 255 to 11

yes, that looks suspicious.

> See the following dmesg files for details;
> 
> http://www.agotnes.com/kernelStuff/dmesg-2.6.17-rc3-working
> http://www.agotnes.com/kernelStuff/dmesg-2.6.17-rc4-not-working
> 
> And the diff, for convenience;
> 
> http://www.agotnes.com/kernelStuff/diff-rc3_rc4
> 
> I have a Via chipset motherboard (for my sins), further details 
> available on request, again, for convenience, the lspci;
> 
> http://www.agotnes.com/kernelStuff/lspci
> 
> A couple of possible suspect patches introduced in the changelog for rc4 
> were (with the first one looking particularly interesting, the others 
> less interesting as I go down the list);
> 
> [PATCH] PCI quirk: VIA IRQ fixup should only run for VIA southbridges

This one, I'd expect.

> [PATCH] x86_64: avoid IRQ0 ioapic pin collision
> [PATCH] PCI: fix via irq SATA patch
> [ALSA] via82xx - Use DXS_SRC as default for VIA8235/8237/8251 chips
> [ALSA] via82xx: tweak VT8251 workaround
> [ALSA] via82xx: add support for VIA VT8251 (AC'97)
> 

You could try a `patch -R' of the below.

commit 75cf7456dd87335f574dcd53c4ae616a2ad71a11
Author: Chris Wedgwood <cw@f00f.org>
Date:   Tue Apr 18 23:57:09 2006 -0700

    [PATCH] PCI quirk: VIA IRQ fixup should only run for VIA southbridges
    
    Alan Cox pointed out that the VIA 'IRQ fixup' was erroneously running
    on my system which has no VIA southbridge (but I do have a VIA IEEE
    1394 device).
    
    This should address that.  I also changed "Via IRQ" to "VIA IRQ"
    (initially I read Via as a capitalized via (by way/means of).
    
    Signed-off-by: Chris Wedgwood <cw@f00f.org>
    Acked-by: Jeff Garzik <jeff@garzik.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index c42ae2c..19e2b17 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -642,13 +642,15 @@ static void quirk_via_irq(struct pci_dev
 	new_irq = dev->irq & 0xf;
 	pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq);
 	if (new_irq != irq) {
-		printk(KERN_INFO "PCI: Via IRQ fixup for %s, from %d to %d\n",
+		printk(KERN_INFO "PCI: VIA IRQ fixup for %s, from %d to %d\n",
 			pci_name(dev), irq, new_irq);
 		udelay(15);	/* unknown if delay really needed */
 		pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
 	}
 }
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686, quirk_via_irq);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_4, quirk_via_irq);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5, quirk_via_irq);
 
 /*
  * VIA VT82C598 has its device ID settable and many BIOSes


If you have trouble getting it to apply, just manually replace all the
DECLARE_PCI_FIXUP_ENABLE lines at the end of quirk_via_irq() with the
single line

DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);

Re: [linux-usb-devel] [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 7762 bytes --]

On Tue, Jun 20, 2006 at 09:21:35PM +1000, Johny wrote:
[...]
> Stock kernels break for me starting with 2.6.17-rc4 (I tested all rcs 
> and also .17 itself), rc3 works a treat for using USB. I suspect the 
> following line missing in dmesg for rc4 is the reason;
> 
> -PCI: Via IRQ fixup for 0000:00:11.1, from 255 to 11

Well, not exactly this line (0000:00:11.1 is the IDE controller, which is
in legacy mode and therefore does not use its PCI interrupt), but the next
similar line is for the USB 2.0 (EHCI) controller:

-PCI: Via IRQ fixup for 0000:00:10.3, from 5 to 10

> See the following dmesg files for details;
> 
> http://www.agotnes.com/kernelStuff/dmesg-2.6.17-rc3-working
> http://www.agotnes.com/kernelStuff/dmesg-2.6.17-rc4-not-working
> 
> And the diff, for convenience;
> 
> http://www.agotnes.com/kernelStuff/diff-rc3_rc4

Try as root:

	setpci -s 00:10.3 INTERRUPT_LINE=0a

(this matches "ehci_hcd 0000:00:10.3: irq 10, ..." in dmesg).

If after doing this USB works again (you will need to replug USB devices),
the missing VIA IRQ quirk is definitely the problem.

> I have a Via chipset motherboard (for my sins), further details 
> available on request, again, for convenience, the lspci;
> 
> http://www.agotnes.com/kernelStuff/lspci

You seem to have also the builtin audio and Ethernet on this board - these
devices may have the same problem, if you tried to use them.

> A couple of possible suspect patches introduced in the changelog for rc4 
> were (with the first one looking particularly interesting, the others 
> less interesting as I go down the list);
> 
> [PATCH] PCI quirk: VIA IRQ fixup should only run for VIA southbridges
> [PATCH] x86_64: avoid IRQ0 ioapic pin collision
> [PATCH] PCI: fix via irq SATA patch
> [ALSA] via82xx - Use DXS_SRC as default for VIA8235/8237/8251 chips
> [ALSA] via82xx: tweak VT8251 workaround
> [ALSA] via82xx: add support for VIA VT8251 (AC'97)
> 
> I'm no kernel hacker, so I'm not sure how I'd isolate this one patch and 
> reverse / modify it. Please let me know how I can progress testing this 
> as I'm currently prevented from using USB with the latest set of kernels 
> on my test server...
> 
> I've got all kernels in the 2.6.17-rc1 through to .17 itself there, plus 
> a variety of mm ones too, so patches against any of those I can very 
> easily test.
> 
> Please keep me cc'd as I'm not on all these lists, thanks :)
> 
> :)Johny
> 
> Johny ?gotnes wrote:
> > didn't go through due to missing vger. ...
> > 
> > ------------------------------------------------------------------------
> > 
> > Subject:
> > Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues
> > From:
> > Johny <kernel@agotnes.com>
> > Date:
> > Sun, 18 Jun 2006 21:37:00 +1000
> > To:
> > Alan Stern <stern@rowland.harvard.edu>
> > 
> > To:
> > Alan Stern <stern@rowland.harvard.edu>
> > CC:
> > Johny <kernel@agotnes.com>, USB development list 
> > <linux-usb-devel@lists.sourceforge.net>, kernel list 
> > <linux-kernel@vger.kernel.org>, linux-acpi@kernel.org, akpm@osdl.org
> > 
> > 
> > All,
> > 
> > I've now tested the following;
> > 
> > 2.6.17-rc6-mm2 with the following patch applied;
> > ---
> > git-acpi.patch from 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc6/2.6.17-rc6-mm2/broken-out/ 
> > 
> > ---
> > 
> > With no difference to the end-result.
> > 
> > Next I stripped out 802.11 generic support and acx111 drivers from the 
> > kernel (including the acpi patches) to check if it clashes, but the same 
> > errors occur....
> > 
> > Thirdly, I booted with acpi=off on the command line with two kernels, 
> > the stock 2.6.17-rc6-mm2 (no acpi patch and including acx111) and the 
> > one including the acpi patch and no acx111, the results were;
> > 
> > acpi_patch;
> > works a treat, picks up USB devices as expected.
> > 
> > stock;
> > works a treat, picks up USB devices as expected, and my acx111 card 
> > works too :)
> > 
> > 
> > Now I'm looking for good suggestions again, this definitely looks like 
> > it is related to ACPI, hence the cc' to that list too, as requested by 
> > Andrew M.
> > 
> > I'm happy to apply patches / config changes as appropriate and for those 
> > who may ask for my .config files, please see;
> > 
> > http://www.agotnes.com/kernelStuff/config-2.6.17-rc6-mm2
> > 
> > http://www.agotnes.com/kernelStuff/config-2.6.17-rc6-mm2git-acpi_patch
> > 
> > Also, I left the output of lspci there for reference;
> > 
> > http://www.agotnes.com/kernelStuff/lspci
> > 
> > Cheers,
> > 
> > :)Johny
> > 
> > Alan Stern wrote:
> >> [Moved to linux-usb-devel in the hope of getting additional help]
> >>
> >> On Thu, 15 Jun 2006, Johny wrote:
> >>
> >>> Alan,
> >>>
> >>> See comments interspersed, thanks for your assistance :)
> >>>
> >>> Alan Stern wrote:
> >>>> On Tue, 13 Jun 2006, Johny wrote:
> >>>>
> >>>>> Is this best suited to this mailing list?
> >>>> It's appropriate.
> >>>>
> >>>>> I tried the kernel list with zero responses (so far ;), let me know 
> >>>>> if there is
> >>>>> anywhere else this should go.
> >>>> ...
> >>>>
> >>>>> Johny ?gotnes wrote:
> >>>>>> All,
> >>>>>>
> >>>>>> My USB hub isn't recognised with the latest -mm series, whereas with
> >>>>>> 2.6.16 vanilla it is picked up & used immediately.
> >>>>>>
> >>>>>> The error I get in dmesg is;
> >>>>>>
> >>>>>> hub 4-0:1.0: USB hub found
> >>>>>> hub 4-0:1.0: 2 ports detected
> >>>>>> usb 1-4: new high speed USB device using ehci_hcd and address 3
> >>>>>> ehci_hcd 0000:00:10.3: Unlink after no-IRQ?  Controller is probably
> >>>>>> using the wrong IRQ.
> >>>> That last line is a clue.  What interrupt numbers are assigned under
> >>>> 2.6.16?  If you unplug the SonyEricsson DCU-11 Cable before booting 
> >>>> (and
> >>>> leave it unplugged), what shows up in /proc/interrupts for both 
> >>>> versions
> >>>> of the kernel?
> >>> See attached, both with the DCU-11 cable disconnected.
> >>
> >> From 2.6.16:
> >>            CPU0         0:      16101          XT-PIC  timer
> >>   1:        148          XT-PIC  i8042
> >>   2:          0          XT-PIC  cascade
> >>   7:          0          XT-PIC  parport0
> >>   9:          0          XT-PIC  acpi
> >>  10:        151          XT-PIC  ehci_hcd:usb1, uhci_hcd:usb4
> >>  11:          0          XT-PIC  uhci_hcd:usb2, uhci_hcd:usb3
> >>  12:        138          XT-PIC  i8042
> >>  14:        172          XT-PIC  ide0
> >>  15:       2458          XT-PIC  ide1
> >> NMI:          0 ERR:          0
> >>
> >> From 2.6.17:
> >>            CPU0         0:      35651    XT-PIC-level    timer
> >>   1:        129    XT-PIC-level    i8042
> >>   2:          0    XT-PIC-level    cascade
> >>   6:          3    XT-PIC-level    floppy
> >>   7:          0    XT-PIC-level    parport0
> >>   9:          0    XT-PIC-level    acpi
> >>  10:          0    XT-PIC-level    ehci_hcd:usb1, uhci_hcd:usb4
> >>  11:       1940    XT-PIC-level    uhci_hcd:usb2, uhci_hcd:usb3, wlan0
> >>  12:        162    XT-PIC-level    i8042
> >>  14:        171    XT-PIC-level    ide0
> >>  15:       4251    XT-PIC-level    ide1
> >> NMI:          0 ERR:          0
> >>
> >> There's nothing obviously wrong.
> >>
> >>>> Most likely this is a problem with the ACPI subsystem, not a USB 
> >>>> problem.
> >>>>
> >>> I guessed USB due to the number of USB changes in the -mm series and, 
> >>> obviously, my USB devices stopped registering, however, I'd not know 
> >>> one from the other ;)
> >>
> >> What happens if you boot with "acpi=off" on the boot command line?
> >>
> >> Alan Stern

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]

[Sergio Monteiro Basto]

Hi, 

In first thread of this issue in LKML, some months ago, (right now, I
don't have the link). 
After some discussion, someone arrive the conclusion of that: 
You only need this quirks, if interrupts are in XT-PIC mode and is
harmless if don't (and "should only run for VIA southbridges"). So if
you are in XT-PIC mode, it is more probability that patch -R in
question, have some affect.
cat /proc/interrupts 
give you: IO-APIC-... or XT-PIC ?

and what PCI_IDs do you have ? (lspci -n)

Other issue, you can't revert this patch cleanly because after that we
have other patch that adds some more IDs. So just delete any declare of
PCI_DEVICE_ID_VIA_82C... and add one declare with PCI_ANY_ID

Thanks,
Sérgio M. B.

On Tue, 2006-06-20 at 04:40 -0700, Andrew Morton wrote:
> You could try a `patch -R' of the below.
> 
> commit 75cf7456dd87335f574dcd53c4ae616a2ad71a11
> Author: Chris Wedgwood <cw@f00f.org>
> Date:   Tue Apr 18 23:57:09 2006 -0700 

Re: [linux-usb-devel] [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]

[Sergio Monteiro Basto]

someone has it has a case similar and said that won't work without
acpi=noirq

http://bugzilla.kernel.org/show_bug.cgi?id=6654



On Tue, 2006-06-20 at 16:09 +0400, Sergey Vlasov wrote:
> On Tue, Jun 20, 2006 at 09:21:35PM +1000, Johny wrote:
> [...]
> > Stock kernels break for me starting with 2.6.17-rc4 (I tested all rcs 
> > and also .17 itself), rc3 works a treat for using USB. I suspect the 
> > following line missing in dmesg for rc4 is the reason;
> > 
> > -PCI: Via IRQ fixup for 0000:00:11.1, from 255 to 11
> 
> Well, not exactly this line (0000:00:11.1 is the IDE controller, which is
> in legacy mode and therefore does not use its PCI interrupt), but the next
> similar line is for the USB 2.0 (EHCI) controller:
> 
> -PCI: Via IRQ fixup for 0000:00:10.3, from 5 to 10
> 
> > See the following dmesg files for details;
> > 
> > http://www.agotnes.com/kernelStuff/dmesg-2.6.17-rc3-working
> > http://www.agotnes.com/kernelStuff/dmesg-2.6.17-rc4-not-working
> > 
> > And the diff, for convenience;
> > 
> > http://www.agotnes.com/kernelStuff/diff-rc3_rc4
> 
> Try as root:
> 
> 	setpci -s 00:10.3 INTERRUPT_LINE=0a
> 
> (this matches "ehci_hcd 0000:00:10.3: irq 10, ..." in dmesg).
> 
> If after doing this USB works again (you will need to replug USB devices),
> the missing VIA IRQ quirk is definitely the problem.
> 
> > I have a Via chipset motherboard (for my sins), further details 
> > available on request, again, for convenience, the lspci;
> > 
> > http://www.agotnes.com/kernelStuff/lspci
> 
> You seem to have also the builtin audio and Ethernet on this board - these
> devices may have the same problem, if you tried to use them.
> 
> > A couple of possible suspect patches introduced in the changelog for rc4 
> > were (with the first one looking particularly interesting, the others 
> > less interesting as I go down the list);
> > 
> > [PATCH] PCI quirk: VIA IRQ fixup should only run for VIA southbridges
> > [PATCH] x86_64: avoid IRQ0 ioapic pin collision
> > [PATCH] PCI: fix via irq SATA patch
> > [ALSA] via82xx - Use DXS_SRC as default for VIA8235/8237/8251 chips
> > [ALSA] via82xx: tweak VT8251 workaround
> > [ALSA] via82xx: add support for VIA VT8251 (AC'97)
> > 
> > I'm no kernel hacker, so I'm not sure how I'd isolate this one patch and 
> > reverse / modify it. Please let me know how I can progress testing this 
> > as I'm currently prevented from using USB with the latest set of kernels 
> > on my test server...
> > 
> > I've got all kernels in the 2.6.17-rc1 through to .17 itself there, plus 
> > a variety of mm ones too, so patches against any of those I can very 
> > easily test.
> > 
> > Please keep me cc'd as I'm not on all these lists, thanks :)
> > 
> > :)Johny
> > 
> > Johny ?gotnes wrote:
> > > didn't go through due to missing vger. ...
> > > 
> > > ------------------------------------------------------------------------
> > > 
> > > Subject:
> > > Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues
> > > From:
> > > Johny <kernel@agotnes.com>
> > > Date:
> > > Sun, 18 Jun 2006 21:37:00 +1000
> > > To:
> > > Alan Stern <stern@rowland.harvard.edu>
> > > 
> > > To:
> > > Alan Stern <stern@rowland.harvard.edu>
> > > CC:
> > > Johny <kernel@agotnes.com>, USB development list 
> > > <linux-usb-devel@lists.sourceforge.net>, kernel list 
> > > <linux-kernel@vger.kernel.org>, linux-acpi@kernel.org, akpm@osdl.org
> > > 
> > > 
> > > All,
> > > 
> > > I've now tested the following;
> > > 
> > > 2.6.17-rc6-mm2 with the following patch applied;
> > > ---
> > > git-acpi.patch from 
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc6/2.6.17-rc6-mm2/broken-out/ 
> > > 
> > > ---
> > > 
> > > With no difference to the end-result.
> > > 
> > > Next I stripped out 802.11 generic support and acx111 drivers from the 
> > > kernel (including the acpi patches) to check if it clashes, but the same 
> > > errors occur....
> > > 
> > > Thirdly, I booted with acpi=off on the command line with two kernels, 
> > > the stock 2.6.17-rc6-mm2 (no acpi patch and including acx111) and the 
> > > one including the acpi patch and no acx111, the results were;
> > > 
> > > acpi_patch;
> > > works a treat, picks up USB devices as expected.
> > > 
> > > stock;
> > > works a treat, picks up USB devices as expected, and my acx111 card 
> > > works too :)
> > > 
> > > 
> > > Now I'm looking for good suggestions again, this definitely looks like 
> > > it is related to ACPI, hence the cc' to that list too, as requested by 
> > > Andrew M.
> > > 
> > > I'm happy to apply patches / config changes as appropriate and for those 
> > > who may ask for my .config files, please see;
> > > 
> > > http://www.agotnes.com/kernelStuff/config-2.6.17-rc6-mm2
> > > 
> > > http://www.agotnes.com/kernelStuff/config-2.6.17-rc6-mm2git-acpi_patch
> > > 
> > > Also, I left the output of lspci there for reference;
> > > 
> > > http://www.agotnes.com/kernelStuff/lspci
> > > 
> > > Cheers,
> > > 
> > > :)Johny
> > > 
> > > Alan Stern wrote:
> > >> [Moved to linux-usb-devel in the hope of getting additional help]
> > >>
> > >> On Thu, 15 Jun 2006, Johny wrote:
> > >>
> > >>> Alan,
> > >>>
> > >>> See comments interspersed, thanks for your assistance :)
> > >>>
> > >>> Alan Stern wrote:
> > >>>> On Tue, 13 Jun 2006, Johny wrote:
> > >>>>
> > >>>>> Is this best suited to this mailing list?
> > >>>> It's appropriate.
> > >>>>
> > >>>>> I tried the kernel list with zero responses (so far ;), let me know 
> > >>>>> if there is
> > >>>>> anywhere else this should go.
> > >>>> ...
> > >>>>
> > >>>>> Johny ?gotnes wrote:
> > >>>>>> All,
> > >>>>>>
> > >>>>>> My USB hub isn't recognised with the latest -mm series, whereas with
> > >>>>>> 2.6.16 vanilla it is picked up & used immediately.
> > >>>>>>
> > >>>>>> The error I get in dmesg is;
> > >>>>>>
> > >>>>>> hub 4-0:1.0: USB hub found
> > >>>>>> hub 4-0:1.0: 2 ports detected
> > >>>>>> usb 1-4: new high speed USB device using ehci_hcd and address 3
> > >>>>>> ehci_hcd 0000:00:10.3: Unlink after no-IRQ?  Controller is probably
> > >>>>>> using the wrong IRQ.
> > >>>> That last line is a clue.  What interrupt numbers are assigned under
> > >>>> 2.6.16?  If you unplug the SonyEricsson DCU-11 Cable before booting 
> > >>>> (and
> > >>>> leave it unplugged), what shows up in /proc/interrupts for both 
> > >>>> versions
> > >>>> of the kernel?
> > >>> See attached, both with the DCU-11 cable disconnected.
> > >>
> > >> From 2.6.16:
> > >>            CPU0         0:      16101          XT-PIC  timer
> > >>   1:        148          XT-PIC  i8042
> > >>   2:          0          XT-PIC  cascade
> > >>   7:          0          XT-PIC  parport0
> > >>   9:          0          XT-PIC  acpi
> > >>  10:        151          XT-PIC  ehci_hcd:usb1, uhci_hcd:usb4
> > >>  11:          0          XT-PIC  uhci_hcd:usb2, uhci_hcd:usb3
> > >>  12:        138          XT-PIC  i8042
> > >>  14:        172          XT-PIC  ide0
> > >>  15:       2458          XT-PIC  ide1
> > >> NMI:          0 ERR:          0
> > >>
> > >> From 2.6.17:
> > >>            CPU0         0:      35651    XT-PIC-level    timer
> > >>   1:        129    XT-PIC-level    i8042
> > >>   2:          0    XT-PIC-level    cascade
> > >>   6:          3    XT-PIC-level    floppy
> > >>   7:          0    XT-PIC-level    parport0
> > >>   9:          0    XT-PIC-level    acpi
> > >>  10:          0    XT-PIC-level    ehci_hcd:usb1, uhci_hcd:usb4
> > >>  11:       1940    XT-PIC-level    uhci_hcd:usb2, uhci_hcd:usb3, wlan0
> > >>  12:        162    XT-PIC-level    i8042
> > >>  14:        171    XT-PIC-level    ide0
> > >>  15:       4251    XT-PIC-level    ide1
> > >> NMI:          0 ERR:          0
> > >>
> > >> There's nothing obviously wrong.
> > >>
> > >>>> Most likely this is a problem with the ACPI subsystem, not a USB 
> > >>>> problem.
> > >>>>
> > >>> I guessed USB due to the number of USB changes in the -mm series and, 
> > >>> obviously, my USB devices stopped registering, however, I'd not know 
> > >>> one from the other ;)
> > >>
> > >> What happens if you boot with "acpi=off" on the boot command line?
> > >>
> > >> Alan Stern

Re: [linux-usb-devel] [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 581 bytes --]

On Tue, Jun 20, 2006 at 02:30:06PM +0100, Sergio Monteiro Basto wrote:
> someone has it has a case similar and said that won't work without
> acpi=noirq
> 
> http://bugzilla.kernel.org/show_bug.cgi?id=6654

Yes, acpi=noirq will work around this bug in many cases, because Linux
will not try to reassign IRQs set up by BIOS.

BTW, the problem may be considered as an ACPI BIOS bug, because
reconfiguring a PCI Interrupt Link should set up IRQ routing, but it
obviously does not.  Unfortunately, this problem seems to be widespread,
so a workaround in kernel is needed.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]

[Johny]

[-- Attachment #1: Type: text/plain, Size: 4718 bytes --]

Andrew,

Success :)

I've attached the patches used vs 2.6.17-rc4 (stock) and 2.6.17-rc6-mm2 
(as the VIA include lists were different). I simply made the change 
manually, based on your and others' inputs (it seemed the simpler option).

Both kernels now boot, and all USB devices are recognised correctly.

Sergio, you can find attached lspci -n output as requested, and indeed, 
I run in XT_PIC mode for interrupts.

I did NOT run the setpci command as requested by Sergey, let me know if 
that helps anyone considering the fix sorted this out.

Where to from here I'll leave with you guys, an entry in the quirks.c 
file certainly is warranted for my motherboard...

I'm happy to test further patches if required on this, for now I'm on 
rc6-mm2 with my attached patch to have both ACX111 networking and USB 
working good :)

Cheers!

:)Johny

Andrew Morton wrote:
> On Tue, 20 Jun 2006 21:21:35 +1000
> Johny <kernel@agotnes.com> wrote:
> 
>> Firstly, apologies for a) the massive x-post and b) the time taken to 
>> get back to people... Please let me know where this is most 
>> appropriately dealt with and I'll keep it off other lists, considering 
>> the latest information;
>>
>> Andrew - please note - this is not a problem exclusive to the -mm 
>> series, on testing various combos I found it in the stock series too.
> 
> Thanks for persisting with this.
> 
>> Stock kernels break for me starting with 2.6.17-rc4 (I tested all rcs 
>> and also .17 itself), rc3 works a treat for using USB. I suspect the 
>> following line missing in dmesg for rc4 is the reason;
>>
>> -PCI: Via IRQ fixup for 0000:00:11.1, from 255 to 11
> 
> yes, that looks suspicious.
> 
>> See the following dmesg files for details;
>>
>> http://www.agotnes.com/kernelStuff/dmesg-2.6.17-rc3-working
>> http://www.agotnes.com/kernelStuff/dmesg-2.6.17-rc4-not-working
>>
>> And the diff, for convenience;
>>
>> http://www.agotnes.com/kernelStuff/diff-rc3_rc4
>>
>> I have a Via chipset motherboard (for my sins), further details 
>> available on request, again, for convenience, the lspci;
>>
>> http://www.agotnes.com/kernelStuff/lspci
>>
>> A couple of possible suspect patches introduced in the changelog for rc4 
>> were (with the first one looking particularly interesting, the others 
>> less interesting as I go down the list);
>>
>> [PATCH] PCI quirk: VIA IRQ fixup should only run for VIA southbridges
> 
> This one, I'd expect.
> 
>> [PATCH] x86_64: avoid IRQ0 ioapic pin collision
>> [PATCH] PCI: fix via irq SATA patch
>> [ALSA] via82xx - Use DXS_SRC as default for VIA8235/8237/8251 chips
>> [ALSA] via82xx: tweak VT8251 workaround
>> [ALSA] via82xx: add support for VIA VT8251 (AC'97)
>>
> 
> You could try a `patch -R' of the below.
> 
> commit 75cf7456dd87335f574dcd53c4ae616a2ad71a11
> Author: Chris Wedgwood <cw@f00f.org>
> Date:   Tue Apr 18 23:57:09 2006 -0700
> 
>     [PATCH] PCI quirk: VIA IRQ fixup should only run for VIA southbridges
>     
>     Alan Cox pointed out that the VIA 'IRQ fixup' was erroneously running
>     on my system which has no VIA southbridge (but I do have a VIA IEEE
>     1394 device).
>     
>     This should address that.  I also changed "Via IRQ" to "VIA IRQ"
>     (initially I read Via as a capitalized via (by way/means of).
>     
>     Signed-off-by: Chris Wedgwood <cw@f00f.org>
>     Acked-by: Jeff Garzik <jeff@garzik.org>
>     Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> 
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index c42ae2c..19e2b17 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -642,13 +642,15 @@ static void quirk_via_irq(struct pci_dev
>  	new_irq = dev->irq & 0xf;
>  	pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq);
>  	if (new_irq != irq) {
> -		printk(KERN_INFO "PCI: Via IRQ fixup for %s, from %d to %d\n",
> +		printk(KERN_INFO "PCI: VIA IRQ fixup for %s, from %d to %d\n",
>  			pci_name(dev), irq, new_irq);
>  		udelay(15);	/* unknown if delay really needed */
>  		pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
>  	}
>  }
> -DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);
> +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686, quirk_via_irq);
> +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_4, quirk_via_irq);
> +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5, quirk_via_irq);
>  
>  /*
>   * VIA VT82C598 has its device ID settable and many BIOSes
> 
> 
> If you have trouble getting it to apply, just manually replace all the
> DECLARE_PCI_FIXUP_ENABLE lines at the end of quirk_via_irq() with the
> single line
> 
> DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);
> 

[-- Attachment #2: via.patch-rc4stock --]
[-- Type: text/plain, Size: 634 bytes --]

--- usb/drivers/pci/quirks.c	2006-06-21 20:18:56.000000000 +1000
+++ linux-2.6.17-rc4/drivers/pci/quirks.c	2006-06-21 20:13:15.000000000 +1000
@@ -648,9 +648,7 @@
 		pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
 	}
 }
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_4, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5, quirk_via_irq);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);
 
 /*
  * VIA VT82C598 has its device ID settable and many BIOSes

[-- Attachment #3: via.patch-rc6-mm2 --]
[-- Type: text/plain, Size: 995 bytes --]

--- usb/drivers/pci/quirks.c	2006-06-21 20:25:41.000000000 +1000
+++ linux-2.6.17-rc6-mm2/drivers/pci/quirks.c	2006-06-21 20:25:08.000000000 +1000
@@ -662,13 +662,7 @@
 		pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
 	}
 }
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_0, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_1, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_3, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_4, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5, quirk_via_irq);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);
 
 /*
  * VIA VT82C598 has its device ID settable and many BIOSes

[-- Attachment #4: lspci-n --]
[-- Type: text/plain, Size: 360 bytes --]

00:00.0 0600: 1106:3205
00:01.0 0604: 1106:b198
00:08.0 0280: 104c:9066
00:10.0 0c03: 1106:3038 (rev 80)
00:10.1 0c03: 1106:3038 (rev 80)
00:10.2 0c03: 1106:3038 (rev 80)
00:10.3 0c03: 1106:3104 (rev 82)
00:11.0 0601: 1106:3177
00:11.1 0101: 1106:0571 (rev 06)
00:11.5 0401: 1106:3059 (rev 50)
00:12.0 0200: 1106:3065 (rev 74)
01:00.0 0300: 1106:7205 (rev 01)

who I do know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]

[Sergio Monteiro Basto]

[-- Attachment #1: Type: text/plain, Size: 915 bytes --]

who I do know if a interrupt is ioapic_edge_type or ioapic_edge_type ? 

On Wed, 2006-06-21 at 20:50 +1000, Johny wrote:
> Success :)
> 
> I simply made the change 
> manually, based on your and others' inputs (it seemed the simpler
> option).
> 
> Both kernels now boot, and all USB devices are recognised correctly.
> 

> I run in XT_PIC mode for interrupts.
> 

Hi, thanks for your positive test on "my" theory.

Here it goes the link that I talked about on last email 
http://lkml.org/lkml/2005/8/18/92 (you can read the previous messages on
this thread) 

The patch of this link doesn't compile (at least for me), but have a
simple idea, which is just quirk the VIA_PCIs if they are in XT_PIC mode
and I think that is the way of this quirks should go.

So someone help me out and do a patch that recognize if the interrupt is
in XT-PIC mode or not ? 

Thanks,  
-- 
Sérgio M. B.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2166 bytes --]

Re: who I do know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]

[Randy.Dunlap]

On Thu, 22 Jun 2006 01:36:46 +0100 Sergio Monteiro Basto wrote:

> who I do know if a interrupt is ioapic_edge_type or ioapic_edge_type ? 

Do you mean how they are configured in a running kernel?

cat /proc/interrupts ::

           CPU0       CPU1       
  0:   12412944   12407808    IO-APIC-edge  timer
  1:     122673     124208    IO-APIC-edge  i8042
  7:          0          0    IO-APIC-edge  parport0
  9:          0          0   IO-APIC-level  acpi
 12:    1141950    1138138    IO-APIC-edge  i8042
 14:    1107749    1109102    IO-APIC-edge  ide0
 58:     451498          0         PCI-MSI  eth0
 66:     530689     495356         PCI-MSI  libata
 74:          0          0   IO-APIC-level  ehci_hcd:usb1, uhci_hcd:usb6
 82:         31          3   IO-APIC-level  ohci_hcd:usb2, ohci_hcd:usb3, ohci_hcd:usb4, ohci_hcd:usb5
 90:        561        492   IO-APIC-level  HDA Intel
169:          3          0   IO-APIC-level  ohci1394
177:          0          0   IO-APIC-level  uhci_hcd:usb8
185:          0          0   IO-APIC-level  uhci_hcd:usb7
193:          0          0   IO-APIC-level  uhci_hcd:usb9


or how they should be configured in case you are not sure?
See a hardware spec. for that.


> On Wed, 2006-06-21 at 20:50 +1000, Johny wrote:
> > Success :)
> > 
> > I simply made the change 
> > manually, based on your and others' inputs (it seemed the simpler
> > option).
> > 
> > Both kernels now boot, and all USB devices are recognised correctly.
> > 
> 
> > I run in XT_PIC mode for interrupts.
> > 
> 
> Hi, thanks for your positive test on "my" theory.
> 
> Here it goes the link that I talked about on last email 
> http://lkml.org/lkml/2005/8/18/92 (you can read the previous messages on
> this thread) 
> 
> The patch of this link doesn't compile (at least for me), but have a
> simple idea, which is just quirk the VIA_PCIs if they are in XT_PIC mode
> and I think that is the way of this quirks should go.
> 
> So someone help me out and do a patch that recognize if the interrupt is
> in XT-PIC mode or not ? 
> 
> Thanks,  
> -- 
> Sérgio M. B.
> 


---
~Randy

Re: how I know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]

[Sergio Monteiro Basto]

[-- Attachment #1: Type: text/plain, Size: 2591 bytes --]

who no, how sorry! I am a little tired 

On Wed, 2006-06-21 at 17:47 -0700, Randy.Dunlap wrote: 
> On Thu, 22 Jun 2006 01:36:46 +0100 Sergio Monteiro Basto wrote:
> 
> > who I do know if a interrupt is ioapic_edge_type or ioapic_edge_type ? 
> 
> Do you mean how they are configured in a running kernel?

yes, I want to know in 
linux-2.6.13/drivers/pci/quirks.c
when I am going quirk the PCI_VIA irq, if this irq is in
IO-APIC-something or is in XT-PIC , to decide if I quirk the interrupt
or not 


> 
> cat /proc/interrupts ::
> 
>            CPU0       CPU1       
>   0:   12412944   12407808    IO-APIC-edge  timer
>   1:     122673     124208    IO-APIC-edge  i8042
>   7:          0          0    IO-APIC-edge  parport0
>   9:          0          0   IO-APIC-level  acpi
>  12:    1141950    1138138    IO-APIC-edge  i8042
>  14:    1107749    1109102    IO-APIC-edge  ide0
>  58:     451498          0         PCI-MSI  eth0
>  66:     530689     495356         PCI-MSI  libata
>  74:          0          0   IO-APIC-level  ehci_hcd:usb1, uhci_hcd:usb6
>  82:         31          3   IO-APIC-level  ohci_hcd:usb2, ohci_hcd:usb3, ohci_hcd:usb4, ohci_hcd:usb5
>  90:        561        492   IO-APIC-level  HDA Intel
> 169:          3          0   IO-APIC-level  ohci1394
> 177:          0          0   IO-APIC-level  uhci_hcd:usb8
> 185:          0          0   IO-APIC-level  uhci_hcd:usb7
> 193:          0          0   IO-APIC-level  uhci_hcd:usb9
> 
> 
> or how they should be configured in case you are not sure?
> See a hardware spec. for that.
> 
> 
> > On Wed, 2006-06-21 at 20:50 +1000, Johny wrote:
> > > Success :)
> > > 
> > > I simply made the change 
> > > manually, based on your and others' inputs (it seemed the simpler
> > > option).
> > > 
> > > Both kernels now boot, and all USB devices are recognised correctly.
> > > 
> > 
> > > I run in XT_PIC mode for interrupts.
> > > 
> > 
> > Hi, thanks for your positive test on "my" theory.
> > 
> > Here it goes the link that I talked about on last email 
> > http://lkml.org/lkml/2005/8/18/92 (you can read the previous messages on
> > this thread) 
> > 
> > The patch of this link doesn't compile (at least for me), but have a
> > simple idea, which is just quirk the VIA_PCIs if they are in XT_PIC mode
> > and I think that is the way of this quirks should go.
> > 
> > So someone help me out and do a patch that recognize if the interrupt is
> > in XT-PIC mode or not ? 
> > 
> > Thanks,  
> > -- 
> > Sérgio M. B.
> > 
> 
> 
> ---
> ~Randy

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2166 bytes --]

Re: how I know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]

[Randy.Dunlap]

On Thu, 22 Jun 2006 02:04:48 +0100 Sergio Monteiro Basto wrote:

> who no, how sorry! I am a little tired 
> 

> On Wed, 2006-06-21 at 17:47 -0700, Randy.Dunlap wrote: 
> > On Thu, 22 Jun 2006 01:36:46 +0100 Sergio Monteiro Basto wrote:
> > 
> > > who I do know if a interrupt is ioapic_edge_type or ioapic_edge_type ? 
> > 
> > Do you mean how they are configured in a running kernel?
> 
> yes, I want to know in 
> linux-2.6.13/drivers/pci/quirks.c
> when I am going quirk the PCI_VIA irq, if this irq is in
> IO-APIC-something or is in XT-PIC , to decide if I quirk the interrupt
> or not

You have to look all over the place. :(
And I've probably missed some of them.

But if the system if using PICs, they will be XT-PIC.
Edge or level triggered is then determined by the bus type:
ISA is mostly edge-triggered (OK, I can't remember that far back)
and PCI is defined as level-triggered.  However, there are
exceptions.  IIRC, legacy IDE is edge-triggered even if it is
on a PCI bus (see listing below for ide0).  And some legacy
devices are edge-triggered (timer, keyboard controller/8042,
parallel port).

You can find info about specifics in places like Intel
chipset specs (ICH5, ICH6, ICH7, etc.), the (large) ACPI
spec from www.acpi.info, the Multiprocessor (MP) spec.
from developer.intel.com, probably some AMD chipset specs,
some PCI bus specs, and in some Linux kernel source code.
Like I said, I probably missed a few places.

If you have a specific issue/problem, it would probably be
better just to focus on that.


> > cat /proc/interrupts ::
> > 
> >            CPU0       CPU1       
> >   0:   12412944   12407808    IO-APIC-edge  timer
> >   1:     122673     124208    IO-APIC-edge  i8042
> >   7:          0          0    IO-APIC-edge  parport0
> >   9:          0          0   IO-APIC-level  acpi
> >  12:    1141950    1138138    IO-APIC-edge  i8042
> >  14:    1107749    1109102    IO-APIC-edge  ide0
> >  58:     451498          0         PCI-MSI  eth0
> >  66:     530689     495356         PCI-MSI  libata
> >  74:          0          0   IO-APIC-level  ehci_hcd:usb1, uhci_hcd:usb6
> >  82:         31          3   IO-APIC-level  ohci_hcd:usb2, ohci_hcd:usb3, ohci_hcd:usb4, ohci_hcd:usb5
> >  90:        561        492   IO-APIC-level  HDA Intel
> > 169:          3          0   IO-APIC-level  ohci1394
> > 177:          0          0   IO-APIC-level  uhci_hcd:usb8
> > 185:          0          0   IO-APIC-level  uhci_hcd:usb7
> > 193:          0          0   IO-APIC-level  uhci_hcd:usb9
> > 
> > 
> > or how they should be configured in case you are not sure?
> > See a hardware spec. for that.
> > 
> > 
> > > On Wed, 2006-06-21 at 20:50 +1000, Johny wrote:
> > > > Success :)
> > > > 
> > > > I simply made the change 
> > > > manually, based on your and others' inputs (it seemed the simpler
> > > > option).
> > > > 
> > > > Both kernels now boot, and all USB devices are recognised correctly.
> > > > 
> > > 
> > > > I run in XT_PIC mode for interrupts.
> > > > 
> > > 
> > > Hi, thanks for your positive test on "my" theory.
> > > 
> > > Here it goes the link that I talked about on last email 
> > > http://lkml.org/lkml/2005/8/18/92 (you can read the previous messages on
> > > this thread) 
> > > 
> > > The patch of this link doesn't compile (at least for me), but have a
> > > simple idea, which is just quirk the VIA_PCIs if they are in XT_PIC mode
> > > and I think that is the way of this quirks should go.
> > > 
> > > So someone help me out and do a patch that recognize if the interrupt is
> > > in XT-PIC mode or not ? 
> > > 
> > > Thanks,  
> > > -- 
> > > Sérgio M. B.

---
~Randy

Re: how I know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]

[Sergio Monteiro Basto]

On Wed, 2006-06-21 at 21:08 -0700, Randy.Dunlap wrote:
> 
> If you have a specific issue/problem, it would probably be
> better just to focus on that. 

on linux-2.6.17/drivers/pci/quirks.c	

  * we must mask the PCI_INTERRUPT_LINE value versus 0xf to get
  * interrupts delivered properly.
  */

 static void quirk_via_irq(struct pci_dev *dev)
 {
 	u8 irq, new_irq;

I want here put something like:  if ( dev->irq != XT-PIC) return and don't quirk this dev.
 	else 

	new_irq = dev->irq & 0xf;
 	pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq);
 

--
Sérgio M. B.

Re: how I know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]

[Randy.Dunlap]

On Thu, 22 Jun 2006 12:56:25 +0100 Sergio Monteiro Basto wrote:

> On Wed, 2006-06-21 at 21:08 -0700, Randy.Dunlap wrote:
> > 
> > If you have a specific issue/problem, it would probably be
> > better just to focus on that. 
> 
> on linux-2.6.17/drivers/pci/quirks.c	
> 
>   * we must mask the PCI_INTERRUPT_LINE value versus 0xf to get
>   * interrupts delivered properly.
>   */
> 
>  static void quirk_via_irq(struct pci_dev *dev)
>  {
>  	u8 irq, new_irq;
> 
> I want here put something like:  if ( dev->irq != XT-PIC) return and don't quirk this dev.
>  	else 

I don't think the interrupt device mode is known by this code (AFAICT
with a quick look).  The function is only called for certain VIA chipsets.

Do you want the quirk for any particular hardware device?
You might be able to look at the function's <dev> parameter
to decide on using the quirk or not.


> 	new_irq = dev->irq & 0xf;
>  	pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq);


---
~Randy

Re: how I know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]

[Sergio Monteiro Basto]

[-- Attachment #1: Type: text/plain, Size: 2258 bytes --]

On Thu, 2006-06-22 at 14:29 -0700, Randy.Dunlap wrote:
> On Thu, 22 Jun 2006 12:56:25 +0100 Sergio Monteiro Basto wrote:
> 
> > On Wed, 2006-06-21 at 21:08 -0700, Randy.Dunlap wrote:
> > > 
> > > If you have a specific issue/problem, it would probably be
> > > better just to focus on that. 
> > 
> > on linux-2.6.17/drivers/pci/quirks.c	
> > 
> >   * we must mask the PCI_INTERRUPT_LINE value versus 0xf to get
> >   * interrupts delivered properly.
> >   */
> > 
> >  static void quirk_via_irq(struct pci_dev *dev)
> >  {
> >  	u8 irq, new_irq;
> > 
> > I want here put something like:  if ( dev->irq != XT-PIC) return and don't quirk this dev.
> >  	else 
> 
> I don't think the interrupt device mode is known by this code (AFAICT
> with a quick look).  The function is only called for certain VIA chipsets.
> 
> Do you want the quirk for any particular hardware device?
> You might be able to look at the function's <dev> parameter
> to decide on using the quirk or not.
> 
> 
> > 	new_irq = dev->irq & 0xf;
> >  	pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq);

yap, in my opinion this function should back to 

--- orig/drivers/pci/quirks.c	2006-06-21 20:25:41.000000000 +1000
+++ linux-2.6.17-rc6-mm2/drivers/pci/quirks.c	2006-06-21 20:25:08.000000000 +1000
@@ -662,13 +662,7 @@
 		pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
 	}
 }
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_0, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_1, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_3, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_4, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5, quirk_via_irq);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);
 
 /*
  * VIA VT82C598 has its device ID settable and many BIOSes


But do you know or not ? how I know if dev->irq is XT-pic ? 


-- 
Sérgio M. B.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2166 bytes --]

Re: how I know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]

[Chris Wedgwood]

On Thu, Jun 22, 2006 at 11:46:38PM +0100, Sergio Monteiro Basto wrote:

> yap, in my opinion this function should back to

> +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);


this is *obviousyl* wrong, it should never have been merged like that
and there are reports and complaints this causes problems for some
people

we should first attempt to get all the IDs (some are clearly missing
still, patch coming up to address that) and where that fails perhaps
have a kernel command-line parameter to be overly aggressive as a
stop-gap until we van figure out the proper solution

i'd also like to figure out why the quirk is needed/fails when people
are using ACPI for interrupt routing as presumbly that must work as
windows relies on it

Re: how I know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]

[Randy.Dunlap]

On Thu, 22 Jun 2006 23:46:38 +0100 Sergio Monteiro Basto wrote:

> On Thu, 2006-06-22 at 14:29 -0700, Randy.Dunlap wrote:
> > On Thu, 22 Jun 2006 12:56:25 +0100 Sergio Monteiro Basto wrote:
> > 
> > > On Wed, 2006-06-21 at 21:08 -0700, Randy.Dunlap wrote:
> > > > 
> > > > If you have a specific issue/problem, it would probably be
> > > > better just to focus on that. 
> > > 
> > > on linux-2.6.17/drivers/pci/quirks.c	
> > > 
> > >   * we must mask the PCI_INTERRUPT_LINE value versus 0xf to get
> > >   * interrupts delivered properly.
> > >   */
> > > 
> > >  static void quirk_via_irq(struct pci_dev *dev)
> > >  {
> > >  	u8 irq, new_irq;
> > > 
> > > I want here put something like:  if ( dev->irq != XT-PIC) return and don't quirk this dev.
> > >  	else 
> > 
> > I don't think the interrupt device mode is known by this code (AFAICT
> > with a quick look).  The function is only called for certain VIA chipsets.
> > 
> > Do you want the quirk for any particular hardware device?
> > You might be able to look at the function's <dev> parameter
> > to decide on using the quirk or not.
> > 
> > 
> > > 	new_irq = dev->irq & 0xf;
> > >  	pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq);
> 
> yap, in my opinion this function should back to 

No idea about that.
I think that you still didn't answer my question, or maybe I
didn't ask it well enough.  What device are you having problems
with? I don't mean what chipset, I mean what device that you
touch...


> --- orig/drivers/pci/quirks.c	2006-06-21 20:25:41.000000000 +1000
> +++ linux-2.6.17-rc6-mm2/drivers/pci/quirks.c	2006-06-21 20:25:08.000000000 +1000
> @@ -662,13 +662,7 @@
>  		pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
>  	}
>  }
> -DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_0, quirk_via_irq);
> -DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_1, quirk_via_irq);
> -DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2, quirk_via_irq);
> -DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_3, quirk_via_irq);
> -DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686, quirk_via_irq);
> -DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_4, quirk_via_irq);
> -DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5, quirk_via_irq);
> +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);
>  
>  /*
>   * VIA VT82C598 has its device ID settable and many BIOSes
> 
> 
> But do you know or not ? how I know if dev->irq is XT-pic ? 

I don't see a way to know that currently.  It could be added
somehow if it's really required.  So far I haven't seen a full
problem description or requirement for this.

---
~Randy

Re: how I know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]

[Sergio Monteiro Basto]

[-- Attachment #1: Type: text/plain, Size: 1221 bytes --]

On Thu, 2006-06-22 at 15:54 -0700, Chris Wedgwood wrote:
> On Thu, Jun 22, 2006 at 11:46:38PM +0100, Sergio Monteiro Basto wrote:
> 
> > yap, in my opinion this function should back to
> 
> > +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);
> 
> 
> this is *obviousyl* wrong, it should never have been merged like that
> and there are reports and complaints this causes problems for some
> people
>

It was like that in kernel 2.6.16 and previous since, I don't know,
2.6.9 or 2.6.13 ....

> 
> we should first attempt to get all the IDs (some are clearly missing
> still, patch coming up to address that) and where that fails perhaps
> have a kernel command-line parameter to be overly aggressive as a
> stop-gap until we van figure out the proper solution

I believe this quirks is just for VIA system with interrupts in XT-PIC
mode (like my old laptop).
> 
> i'd also like to figure out why the quirk is needed/fails when people
> are using ACPI for interrupt routing as presumbly that must work as
> windows relies on it

yes, this is other mysterious, why boot with acpi=noirq could be one
workaround. But could be other problem more related with usb drives.


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2166 bytes --]

Re: how I know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]

[Sergio Monteiro Basto]

[-- Attachment #1: Type: text/plain, Size: 2623 bytes --]

On Thu, 2006-06-22 at 16:25 -0700, Randy.Dunlap wrote:
> No idea about that.
> I think that you still didn't answer my question, or maybe I
> didn't ask it well enough.  What device are you having problems
> with? I don't mean what chipset, I mean what device that you
> touch...
> 

I'd like to give you one answer , but  I don't have one problem with one
device, I bought (accidentally) one VIA with a Pentium dual-core, which
have a bunch of problems. 

> 
> > --- orig/drivers/pci/quirks.c 2006-06-21 20:25:41.000000000 +1000
> > +++ linux-2.6.17-rc6-mm2/drivers/pci/quirks.c 2006-06-21
> 20:25:08.000000000 +1000
> > @@ -662,13 +662,7 @@
> >               pci_write_config_byte(dev, PCI_INTERRUPT_LINE,
> new_irq);
> >       }
> >  }
> > -DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA,
> PCI_DEVICE_ID_VIA_82C586_0, quirk_via_irq);
> > -DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA,
> PCI_DEVICE_ID_VIA_82C586_1, quirk_via_irq);
> > -DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA,
> PCI_DEVICE_ID_VIA_82C586_2, quirk_via_irq);
> > -DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA,
> PCI_DEVICE_ID_VIA_82C586_3, quirk_via_irq);
> > -DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA,
> PCI_DEVICE_ID_VIA_82C686, quirk_via_irq);
> > -DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA,
> PCI_DEVICE_ID_VIA_82C686_4, quirk_via_irq);
> > -DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA,
> PCI_DEVICE_ID_VIA_82C686_5, quirk_via_irq);
> > +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID,
> quirk_via_irq);
> >  
> >  /*
> >   * VIA VT82C598 has its device ID settable and many BIOSes
> > 
> > 
> > But do you know or not ? how I know if dev->irq is XT-pic ? 
> 
> I don't see a way to know that currently.  It could be added
> somehow if it's really required.  So far I haven't seen a full
> problem description or requirement for this. 

Well, this is based in tests along this 4 years, with my two computers.
Like Bjorn said, we don't have any specification of VIA chipsets. But I
like to try, use this quirks only if system don't have IO-APICs enabled.
Many VIA systems work like that, for example my old laptop.

For me, I know that my old laptop needs the quirks and run with
interrupts in XT-PIC, and with my new desktop, I quit sure that don't
need the quirks and system runs with interrupts in IO-APIC-edge and
IO-APIC-level. 

Based in, what I read in this original thread
http://lkml.org/lkml/2005/8/18/92 , seems to me, that we could try this
solution, if we have a easy way to know what kind of interrupts have the
device. 

Thanks Randy for your time,
-- 
Sérgio M. B.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2166 bytes --]

Re: how I know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]

[Randy.Dunlap]

On Fri, 23 Jun 2006 02:00:44 +0100 Sergio Monteiro Basto wrote:

> On Thu, 2006-06-22 at 15:54 -0700, Chris Wedgwood wrote:
> > On Thu, Jun 22, 2006 at 11:46:38PM +0100, Sergio Monteiro Basto wrote:
> > 
> > > yap, in my opinion this function should back to
> > 
> > > +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);
> > 
> > 
> > this is *obviousyl* wrong, it should never have been merged like that
> > and there are reports and complaints this causes problems for some
> > people
> >
> 
> It was like that in kernel 2.6.16 and previous since, I don't know,
> 2.6.9 or 2.6.13 ....
> 
> > 
> > we should first attempt to get all the IDs (some are clearly missing
> > still, patch coming up to address that) and where that fails perhaps
> > have a kernel command-line parameter to be overly aggressive as a
> > stop-gap until we van figure out the proper solution
> 
> I believe this quirks is just for VIA system with interrupts in XT-PIC
> mode (like my old laptop).

This sounds like just running with CONFIG_IO_APIC=n or using
"noapic" on the kernel boot command line.  If that's what is
needed, we can know that.  I just haven't seen info to know
what the real problem is.

> > i'd also like to figure out why the quirk is needed/fails when people
> > are using ACPI for interrupt routing as presumbly that must work as
> > windows relies on it
> 
> yes, this is other mysterious, why boot with acpi=noirq could be one
> workaround. But could be other problem more related with usb drives.


---
~Randy

Re: how I know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]

[Johny]

Chris,

If you keep me posted on the patch when released (I'm not on the kernel 
list, too high volume for me) I'll be happy to give your patch a whirl 
on my test box against whichever kernel you patch.

Your last point is real good, how DOES Windows figure it out? In saying 
that, without the VIA drivers I only have USB1.1 support on this 
motherboard... Again, happy to test some theories if you have some tests 
you'd like ran...

Cheers,

:)Johny

Chris Wedgwood wrote:
> On Thu, Jun 22, 2006 at 11:46:38PM +0100, Sergio Monteiro Basto wrote:
> 
>> yap, in my opinion this function should back to
> 
>> +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);
> 
> 
> this is *obviousyl* wrong, it should never have been merged like that
> and there are reports and complaints this causes problems for some
> people
> 
> we should first attempt to get all the IDs (some are clearly missing
> still, patch coming up to address that) and where that fails perhaps
> have a kernel command-line parameter to be overly aggressive as a
> stop-gap until we van figure out the proper solution
> 
> i'd also like to figure out why the quirk is needed/fails when people
> are using ACPI for interrupt routing as presumbly that must work as
> windows relies on it

Re: how I know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]

[Sergio Monteiro Basto]

[-- Attachment #1: Type: text/plain, Size: 389 bytes --]

On Thu, 2006-06-22 at 18:39 -0700, Randy.Dunlap wrote:
> This sounds like just running with CONFIG_IO_APIC=n or using
> "noapic" on the kernel boot command line.  If that's what is
> needed, we can know that.  I just haven't seen info to know
> what the real problem is. 

yes, could be a way, if we know if IO_APIC or LOCAL_APIC is enabled or
not ?

thanks, 
-- 
Sérgio M. B.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2166 bytes --]

Re: how I know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]

[Randy.Dunlap]

On Fri, 23 Jun 2006 02:50:15 +0100 Sergio Monteiro Basto wrote:

> On Thu, 2006-06-22 at 18:39 -0700, Randy.Dunlap wrote:
> > This sounds like just running with CONFIG_IO_APIC=n or using
> > "noapic" on the kernel boot command line.  If that's what is
> > needed, we can know that.  I just haven't seen info to know
> > what the real problem is. 
> 
> yes, could be a way, if we know if IO_APIC or LOCAL_APIC is enabled or
> not ?

I don't know of a current flag or state that tells us that,
but it could be added.

---
~Randy

Re: [linux-usb-devel] who I do know if a interrupt is ioapic_edge_type or ioapic_level_type? [Was Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]]

[David Brownell]

This isn't quite the same as "how to handle the VIA quirks correctly",
but it does seem like the IRQ API should probably have a call to get
the IRQ trigger mode, just like it has ways to set it.  I've seen
drivers that need to try multiple trigger modes before they find one
that will work on the target platform.

The actual details of _how_ that trigger mode is set -- APIC, PIC and
so on for x86; or other IRQ controllers on other hardware -- should
not matter to drivers, since they're platform-specific.  The quirk
handling code is platform-specific though, and might care.

- Dave

Re: [Fwd: Re: [Linux-usb-users] Fwd: Re: 2.6.17-rc6-mm2 - USB issues]

[Sergio Monteiro Basto]

[-- Attachment #1: Type: text/plain, Size: 878 bytes --]

On Fri, 2006-06-23 at 02:00 +0100, Sergio Monteiro Basto wrote:
> On Thu, 2006-06-22 at 15:54 -0700, Chris Wedgwood wrote:
> > On Thu, Jun 22, 2006 at 11:46:38PM +0100, Sergio Monteiro Basto
> wrote:
> > 
> > > yap, in my opinion this function should back to
> > 
> > > +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID,
> quirk_via_irq);
> > 
> > 
> > this is *obviousyl* wrong, it should never have been merged like
> that
> > and there are reports and complaints this causes problems for some
> > people
> >
> 
> It was like that in kernel 2.6.16 and previous since, I don't know,
> 2.6.9 or 2.6.13 .... 

Hi, Chris Wedgwood 
I found the bugzilla report where the initial version of this function
quirk_via_irq (drivers/pci/quirks.c) has been made:
http://bugzilla.kernel.org/show_bug.cgi?id=3319#c28
might be interesting  !
-- 
Sérgio M. B.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2166 bytes --]