Why is the irq changed from 24 to 0, and why does uhci use irq 24
anyway? I dont have the /proc/interrupts output from this box, maybe no
interrupt is handled for the controller? None of the attached usb
devices is recognized with 2.6.13.
0000:00:0e.0 USB Controller: VIA Technologies, Inc. VT82xxxx UHCI USB 1.1 Controller (rev 04) (prog-if 00 [UHCI])
Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller
Flags: bus master, stepping, medium devsel, latency 32, IRQ 24
I/O ports at f2010040 [size=32]
The Mac has a Bandit PCI host bridge and a Grand Central I/O controller.
Here is the boot.msg stuff about the card:
<6>USB Universal Host Controller Interface driver v2.3
<4>PCI: Enabling device 0000:00:0e.0 (0094 ->0095)
<6>PCI:Via IRQ fixup for 0000:00:0e.0, from 24 to 0
<6>uhci_hcd 0000:00:0e.0: UHCI Controller
<6>uhci_hcd 0000:00:0e.0: new USB bus registered, assigned bus number 1
<6>uhci_hcd 0000:00:0e.0: irq 24, io base 0x00010040
<6>hub 1-0:1.0: USB hub found
<6>hun 1-0:1.0: 2 ports detected
<6>Initializing USB Mass Storage driver...
<6>usbcore:registered new driver usb-storage
<6>USB Mass Storage support registered
--
short story of a lazy sysadmin:
alias appserv=wotan
On Mon, 26 Sep 2005, Olaf Hering wrote:
>
> Why is the irq changed from 24 to 0, and why does uhci use irq 24
> anyway? I dont have the /proc/interrupts output from this box, maybe no
> interrupt is handled for the controller? None of the attached usb
> devices is recognized with 2.6.13.
Did that USB controller use to work in older kernels?
> <6>USB Universal Host Controller Interface driver v2.3
> <4>PCI: Enabling device 0000:00:0e.0 (0094 ->0095)
> <6>PCI:Via IRQ fixup for 0000:00:0e.0, from 24 to 0
That does seem to be seriously broken.
The old code wouldn't do that IRQ fixup for IO-APIC users, and I think
that's correct.
The commit (93cffffa19960464a52f9c78d9a6150270d23785) says:
[PATCH] PCI: do VIA IRQ fixup always, not just in PIC mode
At least some VIA chipsets require the fixup even in IO-APIC mode.
This was found and debugged with the patient assistance of Stian
Jordet <[email protected]> on an Asus CUV266-DLS motherboard.
and I've cc'd the guilty parties.
Bjorn: there's no way that "& 15" can be correct. There is no reason to
believe that the APIC interrupt number bears any relation to the legacy
number or the low four bits.
Others (Mathieu Berard) have reported problems with that patch too, I
think we should revert it.
What are the numbers for Stian Jordet? It might make more sense to instead
of comparing for ACPI/IO-APIC, just compare the irq against 16. Ie just do
if (dev->irq > 15)
return;
in quirk_via_irq(), since if it's not a legacy mode interrupt, we simply
don't know what to do. That "&15" is just a total guess, and makes little
or no sense at all.
Linus
On Mon, Sep 26, Linus Torvalds wrote:
>
>
> On Mon, 26 Sep 2005, Olaf Hering wrote:
> >
> > Why is the irq changed from 24 to 0, and why does uhci use irq 24
> > anyway? I dont have the /proc/interrupts output from this box, maybe no
> > interrupt is handled for the controller? None of the attached usb
> > devices is recognized with 2.6.13.
>
> Did that USB controller use to work in older kernels?
quirk_via_irqpic worked the same, so I guess no.
I will let him try older kernels, and your suggested change.
--
short story of a lazy sysadmin:
alias appserv=wotan
On Mon, Sep 26, Linus Torvalds wrote:
> > <6>USB Universal Host Controller Interface driver v2.3
> > <4>PCI: Enabling device 0000:00:0e.0 (0094 ->0095)
> > <6>PCI:Via IRQ fixup for 0000:00:0e.0, from 24 to 0
>
> That does seem to be seriously broken.
On a side note:
echo $((24 & 15))
8
Thats what I get on my Mac, and the card works there. Also forcing the
irq to 0 doesnt break it.
--
short story of a lazy sysadmin:
alias appserv=wotan
Sitat Linus Torvalds <[email protected]>:
>
>
> On Mon, 26 Sep 2005, Olaf Hering wrote:
> >
> > Why is the irq changed from 24 to 0, and why does uhci use irq 24
> > anyway? I dont have the /proc/interrupts output from this box, maybe no
> > interrupt is handled for the controller? None of the attached usb
> > devices is recognized with 2.6.13.
>
> Did that USB controller use to work in older kernels?
>
> > <6>USB Universal Host Controller Interface driver v2.3
> > <4>PCI: Enabling device 0000:00:0e.0 (0094 ->0095)
> > <6>PCI:Via IRQ fixup for 0000:00:0e.0, from 24 to 0
>
> That does seem to be seriously broken.
>
> The old code wouldn't do that IRQ fixup for IO-APIC users, and I think
> that's correct.
>
> The commit (93cffffa19960464a52f9c78d9a6150270d23785) says:
>
> [PATCH] PCI: do VIA IRQ fixup always, not just in PIC mode
>
> At least some VIA chipsets require the fixup even in IO-APIC mode.
>
> This was found and debugged with the patient assistance of Stian
> Jordet <[email protected]> on an Asus CUV266-DLS motherboard.
>
> and I've cc'd the guilty parties.
First, I've no idea of the reasons behind Bjorn's patch. I've had a
longstanding bug which makes network traffic generate interrupts on irq
11 (which is for usb), after 100 000 interrupts, irq 11 is disabled.
Which is boring. So after seeing Bjorn using some time fixing
VIA-related bugs on LKML, I thought I'd mail him and ask for help.
He wanted me to test 2.6.12-rc2-mm3, which actually disabled irq9 as
well at boottime. After some debugging, he made this patch, which made
irq 9 work as normal again for me. Please don't back this patch out,
without at least re-looking at my system.
That other bug, noone have been able to fix, yet.
Attached is dmesg of 2.6.14-rc2-git3.
Best regards,
Stian
On Tue, 27 Sep 2005, Stian Jordet wrote:
>
> He wanted me to test 2.6.12-rc2-mm3, which actually disabled irq9 as
> well at boottime. After some debugging, he made this patch, which made
> irq 9 work as normal again for me. Please don't back this patch out,
> without at least re-looking at my system.
Well, looking at your messages, I bet that the appended patch works for
you, since your irq's are all in the legacy range.
It is also conceptually closer to what the code _used_ to be (it used to
say "if we have an IO-APIC, don't do this", now it says "if this irq is
bound to an IO-APIC, don't do this")
Whether this will matter to Olaf, I don't know, but the old code was
definitely just writing random bits for the IO-APIC case afaik.
Linus
---
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -546,7 +546,10 @@ static void quirk_via_irq(struct pci_dev
{
u8 irq, new_irq;
- new_irq = dev->irq & 0xf;
+ new_irq = dev->irq;
+ if (!new_irq || new_irq >= 15)
+ return;
+
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",
Sitat Linus Torvalds <[email protected]>:
> Well, looking at your messages, I bet that the appended patch works for
> you, since your irq's are all in the legacy range.
>
> It is also conceptually closer to what the code _used_ to be (it used to
> say "if we have an IO-APIC, don't do this", now it says "if this irq is
> bound to an IO-APIC, don't do this")
No dice. My irq's beyond 15 are changed. What used to be 19 became 17, 18 became
16, 17 became 18 and 16 became 19. The others are normal, and while looking at
dmesg, the fixup is still happening. While it boots, and at first glance seems
to work, it hangs hard when I try to use usb. At least the bluetooth dongle,
haven't tried with anything else, but I suppose that'd do the same.
Sorry.
Best regards,
Stian
On Tue, 27 Sep 2005, Stian Jordet wrote:
>
> No dice. My irq's beyond 15 are changed. What used to be 19 became 17, 18 became
> 16, 17 became 18 and 16 became 19. The others are normal, and while looking at
> dmesg, the fixup is still happening. While it boots, and at first glance seems
> to work, it hangs hard when I try to use usb. At least the bluetooth dongle,
> haven't tried with anything else, but I suppose that'd do the same.
Your dmesg you sent only had
PCI: Via IRQ fixup for 0000:00:11.2, from 9 to 11
PCI: Via IRQ fixup for 0000:00:11.3, from 9 to 11
PCI: Via IRQ fixup for 0000:00:11.4, from 9 to 11
for the Via IRQ fixup, so I assumed that you only had regular ones.
No irq's over 15 according to that (and no, it's not because of the
masking: you also had
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:11.2[D] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11
ACPI: PCI Interrupt 0000:00:11.3[D] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11
ACPI: PCI Interrupt 0000:00:11.4[D] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11
in there.
So the patch I sent should in fact have made zero difference at all for
you. What's up?
Linus
Sitat Linus Torvalds <[email protected]>:
> Your dmesg you sent only had
>
> PCI: Via IRQ fixup for 0000:00:11.2, from 9 to 11
> PCI: Via IRQ fixup for 0000:00:11.3, from 9 to 11
> PCI: Via IRQ fixup for 0000:00:11.4, from 9 to 11
>
> for the Via IRQ fixup, so I assumed that you only had regular ones.
>
> No irq's over 15 according to that (and no, it's not because of the
> masking: you also had
>
> ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11
> ACPI: PCI Interrupt 0000:00:11.2[D] -> Link [LNKD] -> GSI 11 (level, low) ->
> IRQ 11
> ACPI: PCI Interrupt 0000:00:11.3[D] -> Link [LNKD] -> GSI 11 (level, low) ->
> IRQ 11
> ACPI: PCI Interrupt 0000:00:11.4[D] -> Link [LNKD] -> GSI 11 (level, low) ->
> IRQ 11
>
> in there.
>
> So the patch I sent should in fact have made zero difference at all for
> you. What's up?
I have no idea. But I'll attach dmesg from the same kernel with your patch, so
you'll see the differences yourself. I also see that initialization of
everything have changed. Now scsi is almost the last thing in the dmesg, it
used to be about the first. Weird.
-Stian
Sitat Linus Torvalds <[email protected]>:
>
>
> On Tue, 27 Sep 2005, Stian Jordet wrote:
> >
> > No dice. My irq's beyond 15 are changed. What used to be 19 became 17, 18
> became
> > 16, 17 became 18 and 16 became 19. The others are normal, and while looking
> at
> > dmesg, the fixup is still happening. While it boots, and at first glance
> seems
> > to work, it hangs hard when I try to use usb. At least the bluetooth
> dongle,
> > haven't tried with anything else, but I suppose that'd do the same.
>
Sorry! I was looking at the wrong dmesg. *stupid*. Really sorry about that. It
still hangs hard when I try to use usb, but I'll double check that it worked
before the patch before I complain more :P
Once again, sorry. And thank you :)
-Stian
On Tue, 27 Sep 2005, Stian Jordet wrote:
>
> I have no idea. But I'll attach dmesg from the same kernel with your patch, so
> you'll see the differences yourself. I also see that initialization of
> everything have changed. Now scsi is almost the last thing in the dmesg, it
> used to be about the first. Weird.
That's not my patch. Something else has changed.
Anyway, this dmesg you posted still says
...
USB Universal Host Controller Interface driver v2.3
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:11.2[D] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11
** PCI: Via IRQ fixup for 0000:00:11.2, from 9 to 11
uhci_hcd 0000:00:11.2: UHCI Host Controller
uhci_hcd 0000:00:11.2: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:11.2: irq 11, io base 0x00009800
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:11.3[D] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11
** PCI: Via IRQ fixup for 0000:00:11.3, from 9 to 11
uhci_hcd 0000:00:11.3: UHCI Host Controller
uhci_hcd 0000:00:11.3: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:11.3: irq 11, io base 0x00009400
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:11.4[D] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11
** PCI: Via IRQ fixup for 0000:00:11.4, from 9 to 11
...
so my patch didn't change anything at all for you (which is correct - it
was designed not to ;)
So if you have trouble with it, it's something else.
Linus
Hi Linus,
Le Tue, 27 Sep 2005 15:58:33 -0700, Linus Torvalds a ?crit?:
>
>
> so my patch didn't change anything at all for you (which is correct - it
> was designed not to ;)
>
It will for me as I have [1].
But since the irq for ide are probe after, I think it won't change
anything.
I will try your patch when I'll have some free time.
Matthieu
PS : The Via fix are quite strange, as if I understand the message it try
to map usb to irq 1...
[1]
$dmesg | grep -B2 -A2 "Via IRQ"
VP_IDE: IDE controller at PCI slot 0000:00:11.1
ACPI: PCI Interrupt 0000:00:11.1[A]: no GSI
PCI: Via IRQ fixup for 0000:00:11.1, from 255 to 15
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt8235 (rev 00) IDE UDMA133 controller on pci0000:00:11.1
ide0: BM-DMA at 0xfc00-0xfc07, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xfc08-0xfc0f, BIOS settings: hdc:DMA, hdd:DMA
Probing IDE interface ide0...
hda: SAMSUNG SP0802N, ATA DISK drive
hdb: IC35L040AVVA07-0, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: TOSHIBA DVD-ROM SD-M1612, ATAPI CD/DVD-ROM drive
hdd: CD-RW CDR-6S48, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
--
usbmon: debugfs is not available
ACPI: PCI Interrupt 0000:00:10.3[D] -> GSI 21 (level, low) -> IRQ 17
PCI: Via IRQ fixup for 0000:00:10.3, from 10 to 1
ehci_hcd 0000:00:10.3: VIA Technologies, Inc. USB 2.0
ehci_hcd 0000:00:10.3: new USB bus registered, assigned bus number 1
--
USB Universal Host Controller Interface driver v2.3
ACPI: PCI Interrupt 0000:00:10.0[A] -> GSI 21 (level, low) -> IRQ 17
PCI: Via IRQ fixup for 0000:00:10.0, from 11 to 1
uhci_hcd 0000:00:10.0: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
uhci_hcd 0000:00:10.0: new USB bus registered, assigned bus number 2
--
hub 2-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:10.1[B] -> GSI 21 (level, low) -> IRQ 17
PCI: Via IRQ fixup for 0000:00:10.1, from 11 to 1
uhci_hcd 0000:00:10.1: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (#2)
uhci_hcd 0000:00:10.1: new USB bus registered, assigned bus number 3
--
hub 3-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:10.2[C] -> GSI 21 (level, low) -> IRQ 17
PCI: Via IRQ fixup for 0000:00:10.2, from 10 to 1
uhci_hcd 0000:00:10.2: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (#3)
uhci_hcd 0000:00:10.2: new USB bus registered, assigned bus number 4
--
For more details, read ALSA-Configuration.txt.
ACPI: PCI Interrupt 0000:00:11.5[C] -> GSI 22 (level, low) -> IRQ 21
PCI: Via IRQ fixup for 0000:00:11.5, from 10 to 5
PCI: Setting latency timer of device 0000:00:11.5 to 64
Floppy drive(s): fd0 is 1.44M
Le Wed, 28 Sep 2005 09:28:56 +0200, Matthieu CASTET a ?crit?:
> Hi Linus,
>
> Le Tue, 27 Sep 2005 15:58:33 -0700, Linus Torvalds a ?crit?:
>
>>
>>
>
>> so my patch didn't change anything at all for you (which is correct - it
>> was designed not to ;)
>>
>
> It will for me as I have [1].
>
> But since the irq for ide are probe after, I think it won't change
> anything.
> I will try your patch when I'll have some free time.
>
Seem to work fine here (disable all fix).