From: Philip Armstrong <phil@kantaka.co.uk>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Christian.Engstler@gmx.net, evaner@bigfoot.com,
jgarzik@mandrakesoft.com, linux-kernel@vger.kernel.org
Subject: Re: Related VIA PCI crazyness?
Date: Mon, 8 Jan 2001 09:08:03 +0000 [thread overview]
Message-ID: <20010108090803.A452@kantaka.co.uk> (raw)
In-Reply-To: <20010107122800.A636@kantaka.co.uk> <200101072352.PAA28348@penguin.transmeta.com>
In-Reply-To: <200101072352.PAA28348@penguin.transmeta.com>; from torvalds@transmeta.com on Sun, Jan 07, 2001 at 03:52:41PM -0800
On Sun, Jan 07, 2001 at 03:52:41PM -0800, Linus Torvalds wrote:
> In article <20010107122800.A636@kantaka.co.uk>,
> Philip Armstrong <phil@kantaka.co.uk> wrote:
> >In supplement to Evan Thompson's emails with the subject "Additional
> >info. for PCI VIA IDE crazyness. Please read." I've noticed the
> >following message with recent 2.4.0 test + release kernels:
> >
> >IRQ routing conflict in pirq table! Try 'pci=autoirq'
>
> But the machine still works fine, ie the SCSI driver and the network
> driver still seem happy?
Just plugged the laptop back in. Yup. Everything seems happy; SCSI,
network etc,etc all doing their thing.
> If so, it sounds like maybe the VIA pirq router functions are buggy (it
> looks like the sense of pirq 01 and pirq 03 are reversed).
[snip]
> looks like Christian, too, has a working machine, and that the only bad
> result of this all is an annoying printk message. Can you confirm that
> things actually work for you too, and you'd just like to get rid of the
> unnerving message?
So long as there's no underlying problem then I don't particularly
care! Though removing the Try 'pci=autoirq' bit (which doesn't do
anything any more as far as I can see) might be sensible...
> If the VIA logic for getting/setting the irq is wrong, it should only be
> a problem if there are devices that _haven't_ been routed by the BIOS.
> Usually these devices are limited to things like USB, ACPI and CardBus
> controllers, and getting the irq routing wrong in that case can be
> deadly (infinite irq streams on the wrong irq line).
I've turned USB off in the BIOS setup altogether. However, in the
recent past I've used a USB webcam which appeared to work (this was in
2.4.0test4 days or thereabouts.)
> The case where you get an annoying message are the cases where Linux
> knows something is wrong, but decides to take the safe approach - it
> seems to be working for you, as far as I can tell, but that message
> _does_ mean that we may have problems on other machines with the VIA
> chipset.
>
> I _think_ the VIA routing functions were done by Jeff Garzik, Cc'd.
>
> Looking at the VIA irq routing, it looks a bit strange. We have pirqa in
> the high nybble of config sparce port 55h, then we have pirqb and c in
> 56h (low and high nybbles respectively), and then we have pirqd in the
> high nybble of 57h.
>
> The reason this is strange is that it's not consecutive nybbles. I'd
> have expected pirqd to show up in the _low_ nybble of 57h. But as the
> pirq routing fields are pure software convention, it's hard to know
> whether this is already taken into account in the pirq routing table or
> what the magic is.
>
> Could anybody with a VIA chip who has the energy please do something for
> me:
> - enable DEBUG in arch/i386/kernel/pci-i386.h
done
> - do a "/sbin/lspci -xxvvv" on the interrupt routing chip (it's the
> "ISA bridge" chip - the VIA numbers are 82c586, 82c596, the PCI
> numbers for them are 1106:0586 and 1106:0596, I think)
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586/A/B PCI-to-ISA [Apollo VP] (rev 41)
Subsystem: VIA Technologies, Inc. MVP3 ISA Bridge
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort - <MAbort- >SERR- <PERR-
Latency: 0
00: 06 11 86 05 8f 00 00 02 41 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 06 11 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> - do a cat /proc/pci
PCI devices found:
Bus 0, device 0, function 0:
Host bridge: VIA Technologies, Inc. VT82C597 [Apollo VP3] (rev 3).
Master Capable. Latency=16.
Prefetchable 32 bit memory at 0xe0000000 [0xe7ffffff].
Bus 0, device 1, function 0:
PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP] (rev 0).
Master Capable. No bursts. Min Gnt=12.
Bus 0, device 7, function 0:
ISA bridge: VIA Technologies, Inc. VT82C586/A/B PCI-to-ISA [Apollo VP] (rev 65).
Bus 0, device 7, function 1:
IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 6).
Master Capable. Latency=64.
I/O at 0xe000 [0xe00f].
Bus 0, device 7, function 2:
USB Controller: VIA Technologies, Inc. UHCI USB (rev 2).
IRQ 10.
Master Capable. Latency=64.
I/O at 0xe400 [0xe41f].
Bus 0, device 7, function 3:
Bridge: VIA Technologies, Inc. VT82C586B ACPI (rev 16).
Bus 0, device 8, function 0:
SCSI storage controller: Advanced System Products, Inc ABP940-U / ABP960-U (rev 3).
IRQ 11.
Master Capable. Latency=64. Min Gnt=4.Max Lat=4.
I/O at 0xe800 [0xe8ff].
Non-prefetchable 32 bit memory at 0xef100000 [0xef1000ff].
Bus 0, device 10, function 0:
Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 16).
IRQ 9.
Master Capable. Latency=64. Min Gnt=32.Max Lat=64.
I/O at 0xec00 [0xecff].
Non-prefetchable 32 bit memory at 0xef101000 [0xef1010ff].
Bus 0, device 11, function 0:
Multimedia controller: Sigma Designs, Inc. REALmagic Hollywood Plus DVD Decoder (rev 1).
IRQ 9.
Master Capable. Latency=64.
Non-prefetchable 32 bit memory at 0xef000000 [0xef0fffff].
Bus 0, device 12, function 0:
Multimedia video controller: 3Dfx Interactive, Inc. Voodoo 2 (rev 2).
Prefetchable 32 bit memory at 0xee000000 [0xeeffffff].
Bus 1, device 0, function 0:
VGA compatible controller: Matrox Graphics, Inc. MGA 2164W [Millennium II] AGP (rev 0).
IRQ 11.
Master Capable. Latency=64.
Prefetchable 32 bit memory at 0xec000000 [0xecffffff].
Non-prefetchable 32 bit memory at 0xe8000000 [0xe8003fff].
Non-prefetchable 32 bit memory at 0xe9000000 [0xe97fffff].
> With that, I and Jeff can probably match up the interrupt routing table
> entries with the devices, and check what the routing information in the
> config space of the actual router chip is, to verify what the pirq
> translation really should be.
Hope the above is of some use.
cheers,
Phil
--
http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2001-01-08 9:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-01-07 12:28 Related VIA PCI crazyness? Philip Armstrong
2001-01-07 14:33 ` Adrian Bunk
2001-01-07 23:52 ` Linus Torvalds
2001-01-07 21:02 ` Albert Cranford
2001-01-08 3:18 ` Linus Torvalds
2001-01-09 6:06 ` Eric W. Biederman
2001-01-08 2:31 ` Adrian Bunk
2001-01-09 0:53 ` Evan Thompson
2001-01-09 17:19 ` Pete Toscano
[not found] ` <200101072352.PAA28348@penguin.transmeta.com>
2001-01-08 1:44 ` Evan Thompson
2001-01-08 9:08 ` Philip Armstrong [this message]
2001-01-10 21:55 ` Philip Armstrong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20010108090803.A452@kantaka.co.uk \
--to=phil@kantaka.co.uk \
--cc=Christian.Engstler@gmx.net \
--cc=evaner@bigfoot.com \
--cc=jgarzik@mandrakesoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.