From: Steven Rostedt <rostedt@goodmis.org> Date: 2011-02-22 13:12:54
Recently, someone complained that they see the PCI address of a device
in the interrupts file instead of the device name.
19: 73474106 0 IO-APIC-fasteoi ata_piix, uhci_hcd:usb6, 0000:05:01.0
From lspci:
05:01.0 Network controller: RaLink RT2561/RT61 rev B 802.11g
Subsystem: D-Link System Inc AirPlus G DWL-G510 Wireless Network Adapter (Rev.C)
Flags: bus master, slow devsel, latency 32,
IRQ 19 Memory at f9100000 (32-bit, non-prefetchable) [size=32K]
Capabilities: <access denied>
Kernel driver in use: rt61pci
Kernel modules: rt61pci
Investigating this, it seems to be the result of the pci_name() used in
rt2x00pci_probe().
Since the struct rt2x00_ops records the module name for the device as
well as the ops, it would make more sense to show that in the interrupt
output instead.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
From: Ben Hutchings <hidden> Date: 2011-02-22 13:35:00
On Tue, 2011-02-22 at 08:12 -0500, Steven Rostedt wrote:
Recently, someone complained that they see the PCI address of a device
in the interrupts file instead of the device name.
19: 73474106 0 IO-APIC-fasteoi ata_piix, uhci_hcd:usb6, 0000:05:01.0
But then how can users distinguish the IRQs for multiple devices handled
by the same driver? (Probably unusual for WLAN devices, but still
possible.)
I assume you can't use a net device name as there may be multiple net
devices per bus device?
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
But then how can users distinguish the IRQs for multiple devices handled
by the same driver? (Probably unusual for WLAN devices, but still
possible.)
I assume you can't use a net device name as there may be multiple net
devices per bus device?
Honestly, I do not know this code well enough, but this patch seemed to
solve the problem at hand. Hence I sent it out to the experts hoping
they either take this patch or come up with a proper solution ;)
In any case, just posting the pci address is not a pretty answer.
-- Steve
But then how can users distinguish the IRQs for multiple devices handled
by the same driver? (Probably unusual for WLAN devices, but still
possible.)
I assume you can't use a net device name as there may be multiple net
devices per bus device?
Honestly, I do not know this code well enough, but this patch seemed to
solve the problem at hand. Hence I sent it out to the experts hoping
they either take this patch or come up with a proper solution ;)
In any case, just posting the pci address is not a pretty answer.
I just checked the other wireless drivers, and they all seem to use
the modulename. So I guess your patch is correct. You can add my:
Acked-by: Ivo van Doorn <redacted>
But then how can users distinguish the IRQs for multiple devices handled
by the same driver? (Probably unusual for WLAN devices, but still
possible.)
I assume you can't use a net device name as there may be multiple net
devices per bus device?
Honestly, I do not know this code well enough, but this patch seemed to
solve the problem at hand. Hence I sent it out to the experts hoping
they either take this patch or come up with a proper solution ;)
In any case, just posting the pci address is not a pretty answer.
I just checked the other wireless drivers, and they all seem to use
the modulename. So I guess your patch is correct. You can add my:
Acked-by: Ivo van Doorn <redacted>
Thanks!
Actually, to answer Ben's question. lspci should give you what you want.
On my local box (not the one mentioned above):
$ lspci -vv
[...]
00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
Subsystem: Tyan Computer Tomcat K8E (S2865)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx+
Latency: 0 (250ns min, 5000ns max)
Interrupt: pin A routed to IRQ 23
Region 0: Memory at febf9000 (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at b400 [size=8]
Capabilities: <access denied>
Kernel driver in use: forcedeth
(spaces added by me)
$ cat /proc/interrupts
[...]
23: 547 648564 IO-APIC-fasteoi ohci_hcd:usb2, eth0
-- Steve
But then how can users distinguish the IRQs for multiple devices handled
by the same driver? (Probably unusual for WLAN devices, but still
possible.)
I assume you can't use a net device name as there may be multiple net
devices per bus device?
Honestly, I do not know this code well enough, but this patch seemed to
solve the problem at hand. Hence I sent it out to the experts hoping
they either take this patch or come up with a proper solution ;)
In any case, just posting the pci address is not a pretty answer.
I just checked the other wireless drivers, and they all seem to use
the modulename. So I guess your patch is correct. You can add my:
Acked-by: Ivo van Doorn <redacted>
I completely missed this series -- please be sure to Cc:
linux-wireless@vger.kernel.org if you resend, and/or resend the series
directly to me?
Thanks!
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
From: Steven Rostedt <rostedt@goodmis.org> Date: 2011-02-22 21:08:08
On Tue, 2011-02-22 at 14:47 -0500, John W. Linville wrote:
I completely missed this series -- please be sure to Cc:
linux-wireless@vger.kernel.org if you resend, and/or resend the series
directly to me?
Hi John,
Not sure which series you were talking about. I sent out a single patch
and Cc'd you on it. But I should have sent it to linux-wireless, instead
of the net-dev list.
I don't plan on sending out any new patches. This should fix the issue.
Thanks,
-- Steve