Hello again,
i finally got my linuxbios running under my db800 development board.
I now have a problem with ethernet. When there is traffic over the ethernet device there come a lot of "r8169: eth0: link up" messages again and again. Also the datarate is very very slow (~100kbyte).
I tryed it with the normal bios and there it works perfectly. I also have checked the cable and such simple things, im really sure that it is a bios problem.
Here are all details:
Ethernet: RTL8110SB SuperIO - Winbond83627hG AMD Geode LX 700 / CS5536AD ROM - SST49LF004B (4mbit) Devel-env: debian gcc-4.1 (3.4 wont work at all with lxbios for me!) Linubios 2750 (made with buildrom).
Any tipps are very welcome :)
Cheers,
steffen
By the way:
dmesg: PCI: Guessed IRQ 11 for device 0000:00:0d.0 PCI: Sharing IRQ 11 with 0000:00:0f.3 eth0: RTL8169sb/8110sb at 0xd0000000, 00:08:ee:00:ee:1c, IRQ 11
lspci -v ........... 00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10) Subsystem: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 11 I/O ports at 1000 [size=256] Memory at fe019000 (32-bit, non-prefetchable) [size=256] Expansion ROM at ffec0000 [disabled] [size=128K] Capabilities: [dc] Power Management version 2
...........
On Monday 03 September 2007 15:34, Steffen D. wrote:
By the way:
dmesg: PCI: Guessed IRQ 11 for device 0000:00:0d.0 PCI: Sharing IRQ 11 with 0000:00:0f.3 eth0: RTL8169sb/8110sb at 0xd0000000, 00:08:ee:00:ee:1c, IRQ 11
lspci -v ........... 00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10) Subsystem: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 11 I/O ports at 1000 [size=256] Memory at fe019000 (32-bit, non-prefetchable) [size=256] Expansion ROM at ffec0000 [disabled] [size=128K] Capabilities: [dc] Power Management version 2
Can you also create such a text when you start your system with the regular BIOS?
And an "lspci -vvv" also. Might help to see the difference. Does the system behavior changes when you start your linux with the "irqpoll" kernel parameter?
Juergen
I compared the outputs from dmesg and lspci (-vvv) with linuxbios and normal bios - no difference!
Also the option irqpoll doesn't changed anyhing (i added it to the grub line of the linux which boots the final system..)
Steffen
Anybody a idea what to test?
On Tue, Sep 04, 2007 at 08:26:10AM +0200, Steffen D. wrote:
Anybody a idea what to test?
What's the problem?
Do you get interrupts?
cat /proc/interrupts
//Peter
Do you get interrupts?
cat /proc/interrupts
I show you whats happening :)
Lxbios-device:
meshnode:~# iperf -s ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ [ 6] local 192.168.2.52 port 5001 connected with 192.168.2.2 port 55300 r8169: eth0: link up r8169: eth0: link up r8169: eth0: link up ... and again... and again
this message comes two times a second.
The other side of iperf: # iperf -c 192.168.2.52 -t 100 -i 1 ------------------------------------------------------------ Client connecting to 192.168.2.52, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.2.2 port 55300 connected with 192.168.2.52 port 5001 [ 3] 0.0- 1.0 sec 24.0 KBytes 197 Kbits/sec [ 3] 1.0- 2.0 sec 16.0 KBytes 131 Kbits/sec [ 3] 2.0- 3.0 sec 0.00 Bytes 0.00 bits/sec [ 3] 0.0- 7.4 sec 64.0 KBytes 71.3 Kbits/sec .....
--------------
# cat /proc/interrupts CPU0 0: 1009599 XT-PIC-XT timer 2: 0 XT-PIC-XT cascade 4: 845 XT-PIC-XT serial 11: 354 XT-PIC-XT ohci_hcd:usb1, ehci_hcd:usb2, eth0 14: 336 XT-PIC-XT ide0 NMI: 0 LOC: 0 ERR: 6 MIS: 0
I dont know how to read this interrups or what they say to me, sorry. Any idea?
Steffen
*ping*
Anybody a idea how to get this bug done?
Steffen D. wrote:
*ping*
Anybody a idea how to get this bug done?
I don't have my setup in front of me to reference but have you tried a recent version of the driver? http://lkml.org/lkml/2007/8/5/129
Is the driver IDing the part correctly? rtl8110sb is the part number but your error says r8169: eth0:
Marc
Hi Marc,
like i wrote in a mail at the beginning of the topic:
# dmesg: PCI: Guessed IRQ 11 for device 0000:00:0d.0 PCI: Sharing IRQ 11 with 0000:00:0f.3 eth0: RTL8169sb/8110sb at 0xd0000000, 00:08:ee:00:ee:1c, IRQ 11
Like you see dmesg knows that it is sb.
I have tested the kernel driver and currently using the lastest rtl driver from there website... Same result. Im very very ve... sure that it is a BIOS problem because when chaning the bios and using the original one it works - it only will not work with the linuxbios!
Regards,
Steffen
Hello,
we really have a big problem with that ethernet bug - we currently developing a new product based on a geode-lx cpu and not comming forward. Because we are not a big firm we dont have the man power/knowlege to fix it - can anybody help us with this problem? We can send $you the hardware if you need it. Also remote connection to the system is no problem.
hopefully somebody got time.
Steffen D. schrieb:
Hi Marc,
like i wrote in a mail at the beginning of the topic:
# dmesg: PCI: Guessed IRQ 11 for device 0000:00:0d.0 PCI: Sharing IRQ 11 with 0000:00:0f.3 eth0: RTL8169sb/8110sb at 0xd0000000, 00:08:ee:00:ee:1c, IRQ 11
Like you see dmesg knows that it is sb.
I have tested the kernel driver and currently using the lastest rtl driver from there website... Same result. Im very very ve... sure that it is a BIOS problem because when chaning the bios and using the original one it works - it only will not work with the linuxbios!
Regards,
Steffen
On Wed, Sep 05, 2007 at 09:57:20AM +0200, Steffen D. wrote:
Do you get interrupts?
I show you whats happening :)
r8169: eth0: link up r8169: eth0: link up r8169: eth0: link up ... and again... and again
this message comes two times a second.
I think the best way to find the problem is to add huge amounts of trace printk to the r8169 driver. (Even though the problem indeed is in LB.)
Do you have access to the full data sheet (registers and all) for the NIC?
The other side of iperf: [ 3] 1.0- 2.0 sec 16.0 KBytes 131 Kbits/sec [ 3] 2.0- 3.0 sec 0.00 Bytes 0.00 bits/sec [ 3] 0.0- 7.4 sec 64.0 KBytes 71.3 Kbits/sec
Only traffic during the first 2 seconds. Hm.
# cat /proc/interrupts 11: 354 XT-PIC-XT ohci_hcd:usb1, ehci_hcd:usb2, eth0
I dont know how to read this interrups or what they say to me, sorry. Any idea?
The first column is the interrupt number, 11. The second is the interrupt count since Linux start. 354 interrupts. Third is the mode that the interrupt controller is running in. AMD, is XT-PIC-XT correct for the LX platform? Fourth is the list of drivers/interfaces that are sharing this interrupt.
Since it's shared between eth0 and USB we can't see reliably if you are getting interrupts from the NIC.
Start with disabling USB until this is solved. Then look at the interrupt count before and after trying to communicate with the system. When running iperf the number should increase fairly steadily.
Again, it's important to disable USB (unloading the driver is enough) so that you can be sure of the interrupt source.
On Thu, Sep 20, 2007 at 05:09:05AM +0200, Steffen D. wrote:
we really have a big problem with that ethernet bug - we currently developing a new product based on a geode-lx cpu and not comming forward. Because we are not a big firm we dont have the man power/knowlege to fix it - can anybody help us with this problem?
Maybe I can help.
We can send $you the hardware if you need it.
Depends.. I don't have access to a logic analyzer and only a 40MHz analog scope so it may be better to send $me to you if you have a good lab. (I'm in Malmö, Sweden.)
Also remote connection to the system is no problem.
Over serial then, I hope. :)
hopefully somebody got time.
Not a lot - but maybe enough?
//Peter
Peter Stuge schrieb:
The first column is the interrupt number, 11. The second is the interrupt count since Linux start. 354 interrupts. Third is the mode that the interrupt controller is running in. AMD, is XT-PIC-XT correct for the LX platform? Fourth is the list of drivers/interfaces that are sharing this interrupt.
Since it's shared between eth0 and USB we can't see reliably if you are getting interrupts from the NIC.
Start with disabling USB until this is solved. Then look at the interrupt count before and after trying to communicate with the system. When running iperf the number should increase fairly steadily.
Again, it's important to disable USB (unloading the driver is enough) so that you can be sure of the interrupt source.
I have unloaded the usb stuff. I have cated the interrupts before and after iperf...:
---------------------------------- # cat /proc/interrupts CPU0 0: 1268114 XT-PIC-XT timer 2: 0 XT-PIC-XT cascade 4: 934 XT-PIC-XT serial 11: 4330 XT-PIC-XT eth0 14: 907 XT-PIC-XT ide0 NMI: 0 LOC: 0 ERR: 6 MIS: 0
# iperf -s ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ [ 6] local 192.168.2.58 port 5001 connected with 192.168.2.2 port 32948 [ 6] 0.0-11.6 sec 1.66 MBytes 1.20 Mbits/sec
meshnode:~# cat /proc/interrupts CPU0 0: 1322253 XT-PIC-XT timer 2: 0 XT-PIC-XT cascade 4: 937 XT-PIC-XT serial 11: 6418 XT-PIC-XT eth0 14: 907 XT-PIC-XT ide0 NMI: 0 LOC: 0 ERR: 6 MIS: 0
----------------------------------
On Thu, Sep 20, 2007 at 02:53:00PM +0200, Steffen D. wrote:
I have unloaded the usb stuff. I have cated the interrupts before and after iperf...:
# cat /proc/interrupts 11: 4330 XT-PIC-XT eth0
# iperf -s
Server listening on TCP port 5001 TCP window size: 85.3 KByte (default)
[ 6] local 192.168.2.58 port 5001 connected with 192.168.2.2 port 32948 [ 6] 0.0-11.6 sec 1.66 MBytes 1.20 Mbits/sec
meshnode:~# cat /proc/interrupts 11: 6418 XT-PIC-XT eth0
So you are indeed getting interrupts. That's good.
I am not familiar with iperf and I don't know what you want. I suppose you want to see 100Mbps instead of 1.20Mbps.
I don't know what is realistic to expect from the hardware you are using. Also it would be more accurate to test throughput (if that is what you are doing) using UDP because it is fire and forget as opposed to TCP which needs handshaking.
What's the problem again? Your previous logs indicate that the link goes up and down, but that's not a lot of information..
Is this NIC also behind that PCI bridge?
//Peter
On Thu, Sep 20, 2007 at 02:53:00PM +0200, Steffen D. wrote:
I have unloaded the usb stuff. I have cated the interrupts before and after iperf...:
# cat /proc/interrupts 11: 4330 XT-PIC-XT eth0
# iperf -s
Server listening on TCP port 5001 TCP window size: 85.3 KByte (default)
[ 6] local 192.168.2.58 port 5001 connected with 192.168.2.2 port 32948 [ 6] 0.0-11.6 sec 1.66 MBytes 1.20 Mbits/sec
meshnode:~# cat /proc/interrupts 11: 6418 XT-PIC-XT eth0
So you are indeed getting interrupts. That's good.
I am not familiar with iperf and I don't know what you want. I suppose you want to see 100Mbps instead of 1.20Mbps.
I don't know what is realistic to expect from the hardware you are using. Also it would be more accurate to test throughput (if that is what you are doing) using UDP because it is fire and forget as opposed to TCP which needs handshaking.
What's the problem again? Your previous logs indicate that the link goes up and down, but that's not a lot of information..
Is this NIC also behind that PCI bridge?
The throughput is the probleme because it is to little - i allways can test it with the orig. bios and there it works like 1gbit should work. The problem is that it works with the normal bios and working very very badly with the linux bios. The ethernet is not behind a pci bridge.
On Thu, Sep 20, 2007 at 05:06:58PM +0200, Steffen D. wrote:
What's the problem again?
Is this NIC also behind that PCI bridge?
The throughput is the probleme because it is to little - i allways can test it with the orig. bios and there it works like 1gbit should work.
Ah, gig even. Ok.
The problem is that it works with the normal bios and working very very badly with the linux bios.
It's interesting that it works at all.
The ethernet is not behind a pci bridge.
Ok.
Either work from the driver, add copious amounts of debugging info to it so you can see how the driver works with the factory BIOS, then use same source with LB to see what goes different with LB and possibly get a hint from the NIC datasheet what the problem actually is.
Or you can work from PCI config space registers - investigate each bit that differs between factory BIOS and LB to rule them out one at a time until you find the one that is causing the problems.
//Peter
Steffen D. wrote:
Hello,
we really have a big problem with that ethernet bug - we currently developing a new product based on a geode-lx cpu and not comming forward. Because we are not a big firm we dont have the man power/knowlege to fix it - can anybody help us with this problem? We can send $you the hardware if you need it. Also remote connection to the system is no problem.
hopefully somebody got time.
Steffan, This does seem strange since we have been booting our db800 with etherboot. So, are you trying this on a db800 or on your own platform design?
One thing you could try is changing the IRQ mapping to isolate the IRQs. In the mainboard diirectory change irq_tables.c PIRQB to something else like 5 to isolate it.
Marc
Steffen D. wrote:
Hello,
we really have a big problem with that ethernet bug - we currently developing a new product based on a geode-lx cpu and not comming forward. Because we are not a big firm we dont have the man power/knowlege to fix it - can anybody help us with this problem? We can send $you the hardware if you need it. Also remote connection to the system is no problem.
hopefully somebody got time.
Steffan, This does seem strange since we have been booting our db800 with etherboot. So, are you trying this on a db800 or on your own platform design?
One thing you could try is changing the IRQ mapping to isolate the IRQs. In the mainboard diirectory change irq_tables.c PIRQB to something else like 5 to isolate it.
Marc
We are trying this on a db800 from logic. So it is a real db800 board (rev b). We have two boards and it is happening the same on each board.
Do you mean this line of code?:
#define M_PIRQB (1 << PIRQB) /* Bitmap of supported IRQs */
regards,
steffen
About the ethernet problem: ------- meshnode:~# modprobe r8169 r8169 Gigabit Ethernet driver 2.2LK loaded PCI: Guessed IRQ 11 for device 0000:00:0d.0 PCI: Sharing IRQ 11 with 0000:00:0f.3 eth0: RTL8169sb/8110sb at 0xd0016000, 00:08:ee:00:ee:1c, IRQ 11 ------- this also seems very strange "sharing irq11 with..." can the problem be right here?
Steffen D. wrote:
About the ethernet problem:
meshnode:~# modprobe r8169 r8169 Gigabit Ethernet driver 2.2LK loaded PCI: Guessed IRQ 11 for device 0000:00:0d.0 PCI: Sharing IRQ 11 with 0000:00:0f.3 eth0: RTL8169sb/8110sb at 0xd0016000, 00:08:ee:00:ee:1c, IRQ 11
this also seems very strange "sharing irq11 with..." can the problem be right here?
That shouldn't be the issue. I recall now that PIRQB is shared with the audio device. d.0 is the eth0 and f.3 is audio.
Marc
Marc Jones wrote:
Steffen D. wrote:
About the ethernet problem:
meshnode:~# modprobe r8169 r8169 Gigabit Ethernet driver 2.2LK loaded PCI: Guessed IRQ 11 for device 0000:00:0d.0 PCI: Sharing IRQ 11 with 0000:00:0f.3 eth0: RTL8169sb/8110sb at 0xd0016000, 00:08:ee:00:ee:1c, IRQ 11
this also seems very strange "sharing irq11 with..." can the problem be right here?
That shouldn't be the issue. I recall now that PIRQB is shared with the audio device. d.0 is the eth0 and f.3 is audio.
Marc
OK. I think is see the problem. Bus Master Enable and Memory Enable aren't enabled in the command register. I am not sure why the Memory Enable isn't set. LinuxBIOS should set that and this seems to be a problem in the LB generic pci init code (Anyone care to debug this?). I think that the driver should enable the Bus Master and LB shouldn't need to touch it (I would be interested in other opinions on this).
Try:
setpci 00:0d.0 COMMAND=7
Marc
Marc Jones schrieb
OK. I think is see the problem. Bus Master Enable and Memory Enable aren't enabled in the command register. I am not sure why the Memory Enable isn't set. LinuxBIOS should set that and this seems to be a problem in the LB generic pci init code (Anyone care to debug this?). I think that the driver should enable the Bus Master and LB shouldn't need to touch it (I would be interested in other opinions on this).
Try:
setpci 00:0d.0 COMMAND=7
Hmm syntax problem? i dont find out why the usage output comes out...
node:~# setpci 00:0d.0 COMMAND=7 Usage: setpci [<options>] (<device>+ <reg>[=<values>]*)* -f Don't complain if there's nothing to do -v Be verbose -D List changes, don't commit them -P <dir> Use specified directory instead of /proc/bus/pci -H <mode> Use direct hardware access (<mode> = 1 or 2) -F <file> Read configuration data from given file -G Enable PCI access debugging <device>: -s [[[<domain>]:][<bus>]:][<slot>][.[<func>]] | -d [<vendor>]:[<device>] <reg>: <number>[.(B|W|L)] | <name> <values>: <value>[,<value>...] <value>: <hex> | <hex>:<mask>
node:~#
regards,
Steffen
* Steffen D. ml@saxnet.de [070925 09:27]:
setpci 00:0d.0 COMMAND=7
Hmm syntax problem? i dont find out why the usage output comes out...
node:~# setpci 00:0d.0 COMMAND=7 Usage: setpci [<options>] (<device>+ <reg>[=<values>]*)*
<device>: -s [[[<domain>]:][<bus>]:][<slot>][.[<func>]] | -d [<vendor>]:[<device>]
<device> expects "-s 0:d.0"
Stefan Reinauer wrote:
- Steffen D. ml@saxnet.de [070925 09:27]:
setpci 00:0d.0 COMMAND=7
Hmm syntax problem? i dont find out why the usage output comes out...
node:~# setpci 00:0d.0 COMMAND=7 Usage: setpci [<options>] (<device>+ <reg>[=<values>]*)*
<device>: -s [[[<domain>]:][<bus>]:][<slot>][.[<func>]] | -d [<vendor>]:[<device>]
<device> expects "-s 0:d.0"
Sorry, it requires the -s option as Stefan has pointed out. setpci -s 00:0d.0 COMMAND=7
Marc
Marc Jones wrote:
Marc Jones wrote:
Steffen D. wrote:
About the ethernet problem:
OK. I think is see the problem. Bus Master Enable and Memory Enable aren't enabled in the command register. I am not sure why the Memory Enable isn't set. LinuxBIOS should set that and this seems to be a problem in the LB generic pci init code (Anyone care to debug this?). I think that the driver should enable the Bus Master and LB shouldn't need to touch it (I would be interested in other opinions on this).
Try:
setpci 00:0d.0 COMMAND=7
Marc
Sorry, False alarm. I was using a linux image that didn't have the network drivers so the memory and the busmaster enables were disabled (by the kernel I assume).
Marc
Marc Jones wrote:
Marc Jones wrote:
Marc Jones wrote:
Steffen D. wrote:
About the ethernet problem:
OK. I think is see the problem. Bus Master Enable and Memory Enable aren't enabled in the command register. I am not sure why the Memory Enable isn't set. LinuxBIOS should set that and this seems to be a problem in the LB generic pci init code (Anyone care to debug this?). I think that the driver should enable the Bus Master and LB shouldn't need to touch it (I would be interested in other opinions on this).
Try:
setpci 00:0d.0 COMMAND=7
Marc
Sorry, False alarm. I was using a linux image that didn't have the network drivers so the memory and the busmaster enables were disabled (by the kernel I assume).
Marc
Now I think that it is a problem with the command register. The PERR# is set and this is causing the "8169: eth0: link up". I don't have a way to test bandwidth here so that is up to you Steffen.
setpci -s 0d.0 COMMAND=17
I will start another thread on PERR# and SERR# to discuss how and when they should be enabled.
Marc
On 9/21/07, Marc Jones marc.jones@amd.com wrote:
OK. I think is see the problem. Bus Master Enable and Memory Enable aren't enabled in the command register. I am not sure why the Memory Enable isn't set. LinuxBIOS should set that and this seems to be a problem in the LB generic pci init code (Anyone care to debug this?).
Oh boy. memory enable only gets set if the part has memory resources. does it? I just jumped into the middle of this thread.
I think that the driver should enable the Bus Master and LB shouldn't need to touch it (I would be interested in other opinions on this).
You are right.
ron
Steffen D. wrote:
Steffen D. wrote:
Hello,
we really have a big problem with that ethernet bug - we currently developing a new product based on a geode-lx cpu and not comming forward. Because we are not a big firm we dont have the man power/knowlege to fix it - can anybody help us with this problem? We can send $you the hardware if you need it. Also remote connection to the system is no problem.
hopefully somebody got time.
Steffan, This does seem strange since we have been booting our db800 with etherboot. So, are you trying this on a db800 or on your own platform design?
One thing you could try is changing the IRQ mapping to isolate the IRQs. In the mainboard diirectory change irq_tables.c PIRQB to something else like 5 to isolate it.
Marc
We are trying this on a db800 from logic. So it is a real db800 board (rev b). We have two boards and it is happening the same on each board.
Do you mean this line of code?:
#define M_PIRQB (1 << PIRQB) /* Bitmap of supported IRQs */
regards,
steffen
#define PIRQB 11 to #define PIRQB 5
This will move audio and eth0 to 5 while USB will be on 10 and 11.
Marc
Marc Jones schrieb
#define PIRQB 11 to #define PIRQB 5
This will move audio and eth0 to 5 while USB will be on 10 and 11.
Marc
I changed this and nothing happens - i have put lspci ouput and irq source in the attachment...
00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10) Subsystem: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet 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: 64 (8000ns min, 16000ns max), Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 11 Region 0: I/O ports at 1000 [size=256] Region 1: Memory at fe019000 (32-bit, non-prefetchable) [size=256] Expansion ROM at ffec0000 [disabled] [size=128K] Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME-
... seems that it doenst change the IRQ?
regards,
steffen
00:01.0 Host bridge: Advanced Micro Devices [AMD] CS5536 [Geode companion] Host Bridge (rev 30) Subsystem: Advanced Micro Devices [AMD] CS5536 [Geode companion] Host 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: 64 Region 0: I/O ports at ac1c [size=4]
00:01.1 VGA compatible controller: Advanced Micro Devices [AMD] Geode LX Video (prog-if 00 [VGA]) Subsystem: Advanced Micro Devices [AMD] Geode LX Video 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- Interrupt: pin A routed to IRQ 10 Region 0: Memory at fd000000 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at fe000000 (32-bit, non-prefetchable) [size=16K] Region 2: Memory at fe004000 (32-bit, non-prefetchable) [size=16K] Region 3: Memory at fe008000 (32-bit, non-prefetchable) [size=16K] Region 4: Memory at fe00c000 (32-bit, non-prefetchable) [size=16K]
00:01.2 Entertainment encryption device: Advanced Micro Devices [AMD] Geode LX AES Security Block Subsystem: Advanced Micro Devices [AMD] Geode LX AES Security Block 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- Interrupt: pin A routed to IRQ 10 Region 0: Memory at fe010000 (32-bit, non-prefetchable) [size=16K]
00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10) Subsystem: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet 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: 64 (8000ns min, 16000ns max), Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 11 Region 0: I/O ports at 1000 [size=256] Region 1: Memory at fe019000 (32-bit, non-prefetchable) [size=256] Expansion ROM at ffec0000 [disabled] [size=128K] Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:0e.0 PCI bridge: Hint Corp HiNT HB4 PCI-PCI Bridge (PCI6150) (rev 04) (prog-if 00 [Normal decode]) 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: 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 0000f000-00000fff Memory behind bridge: fff00000-000fffff Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff Secondary status: 66MHz+ FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- <SERR- <PERR- BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B- Capabilities: [dc] Power Management version 1 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Bridge: PM- B3+ Capabilities: [e4] #06 [0094] Capabilities: [e8] Vital Product Data
00:0f.0 ISA bridge: Advanced Micro Devices [AMD] CS5536 [Geode companion] ISA (rev 03) Subsystem: Advanced Micro Devices [AMD] CS5536 [Geode companion] ISA 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- Region 0: I/O ports at 1cb0 [size=8] Region 1: I/O ports at 1400 [size=256] Region 2: I/O ports at 1c00 [size=64] Region 3: I/O ports at 1c80 [size=32] Region 4: I/O ports at 1800 [size=128] Region 5: I/O ports at 1c40 [size=64]
00:0f.2 IDE interface: Advanced Micro Devices [AMD] CS5536 [Geode companion] IDE (rev 01) (prog-if 80 [Master]) Subsystem: Advanced Micro Devices [AMD] CS5536 [Geode companion] IDE 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: 248 Region 0: [virtual] Memory at 000001f0 (32-bit, non-prefetchable) [disabled] [size=8] Region 1: [virtual] Memory at 000003f0 (type 3, non-prefetchable) [disabled] [size=1] Region 2: [virtual] Memory at 00000170 (32-bit, non-prefetchable) [disabled] [size=8] Region 3: [virtual] Memory at 00000370 (type 3, non-prefetchable) [disabled] [size=1] Region 4: I/O ports at 1ca0 [size=16]
00:0f.3 Multimedia audio controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] Audio (rev 01) Subsystem: Advanced Micro Devices [AMD] CS5536 [Geode companion] Audio 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- Interrupt: pin B routed to IRQ 11 Region 0: I/O ports at 1880 [size=128]
00:0f.4 USB Controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] OHC (rev 02) (prog-if 10 [OHCI]) Subsystem: Advanced Micro Devices [AMD] CS5536 [Geode companion] OHC 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 Interrupt: pin D routed to IRQ 11 Region 0: Memory at fe016000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:0f.5 USB Controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] EHC (rev 02) (prog-if 20 [EHCI]) Subsystem: Advanced Micro Devices [AMD] CS5536 [Geode companion] EHC 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, Cache Line Size: 32 bytes Interrupt: pin D routed to IRQ 11 Region 0: Memory at fe017000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME-
/* * This file is part of the LinuxBIOS project. * * Copyright (C) 2007 Advanced Micro Devices, Inc. * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as * published by the Free Software Foundation. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */
#include <arch/pirq_routing.h> #include <console/console.h> #include <arch/io.h> #include <arch/pirq_routing.h> #include "../../../southbridge/amd/cs5536/cs5536.h"
/* Platform IRQs */ #define PIRQA 10 #define PIRQB 5 #define PIRQC 10 #define PIRQD 11
/* Map */ #define M_PIRQA (1 << PIRQA) /* Bitmap of supported IRQs */ #define M_PIRQB (1 << PIRQB) /* Bitmap of supported IRQs */ #define M_PIRQC (1 << PIRQC) /* Bitmap of supported IRQs */ #define M_PIRQD (1 << PIRQD) /* Bitmap of supported IRQs */
/* Link */ #define L_PIRQA 1 /* Means Slot INTx# Connects To Chipset INTA# */ #define L_PIRQB 2 /* Means Slot INTx# Connects To Chipset INTB# */ #define L_PIRQC 3 /* Means Slot INTx# Connects To Chipset INTC# */ #define L_PIRQD 4 /* Means Slot INTx# Connects To Chipset INTD# */
const struct irq_routing_table intel_irq_routing_table = { PIRQ_SIGNATURE, /* u32 signature */ PIRQ_VERSION, /* u16 version */ 32 + 16 * IRQ_SLOT_COUNT, /* there can be total 6 devices on the bus */ 0x00, /* Where the interrupt router lies (bus) */ (0x0F << 3) | 0x0, /* Where the interrupt router lies (dev) */ 0x00, /* IRQs devoted exclusively to PCI usage */ 0x100B, /* Vendor */ 0x002B, /* Device */ 0, /* Crap (miniport) */ {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, /* u8 rfu[11] */ 0x00, /* u8 checksum , this has to set to some value that would give 0 after the sum of all bytes for this structure (including checksum) */ { /* If you change the number of entries, change the IRQ_SLOT_COUNT above! */ /* bus, dev|fn, {link, bitmap}, {link, bitmap}, {link, bitmap}, {link, bitmap}, slot, rfu */ {0x00, (0x01 << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0}, /* cpu */ {0x00, (0x0F << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x0, 0x0}, /* chipset */ {0x00, (0x0D << 3) | 0x0, {{L_PIRQB, M_PIRQB}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0}, /* ethernet */ {0x00, (0x0E << 3) | 0x0, {{L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}}, 0x1, 0x0}, /* slot1 */ } };
unsigned long write_pirq_routing_table(unsigned long addr) { int i, j, k, num_entries; unsigned char pirq[4]; uint16_t chipset_irq_map; uint32_t pciAddr, pirtable_end; struct irq_routing_table *pirq_tbl;
pirtable_end = copy_pirq_routing_table(addr);
/* Set up chipset IRQ steering. */ pciAddr = 0x80000000 | (CHIPSET_DEV_NUM << 11) | 0x5C; chipset_irq_map = (PIRQD << 12 | PIRQC << 8 | PIRQB << 4 | PIRQA); printk_debug("%s(%08X, %04X)\n", __FUNCTION__, pciAddr, chipset_irq_map); outl(pciAddr & ~3, 0xCF8); outl(chipset_irq_map, 0xCFC);
pirq_tbl = (struct irq_routing_table *)(addr); num_entries = (pirq_tbl->size - 32) / 16;
/* Set PCI IRQs. */ for (i = 0; i < num_entries; i++) { printk_debug("PIR Entry %d Dev/Fn: %X Slot: %d\n", i, pirq_tbl->slots[i].devfn, pirq_tbl->slots[i].slot); for (j = 0; j < 4; j++) { printk_debug("INT: %c bitmap: %x ", 'A' + j, pirq_tbl->slots[i].irq[j].bitmap); for (k = 0; (!((pirq_tbl->slots[i].irq[j].bitmap >> k) & 1)) && (pirq_tbl->slots[i].irq[j].bitmap != 0); k++) ; /* Finds lsb in bitmap to IRQ#. */ pirq[j] = k; printk_debug("PIRQ: %d\n", k); }
/* Bus, device, slots IRQs for {A,B,C,D}. */ pci_assign_irqs(pirq_tbl->slots[i].bus, pirq_tbl->slots[i].devfn >> 3, pirq); }
/* Put the PIR table in memory and checksum. */ return pirtable_end; }
Steffen D. wrote:
Marc Jones schrieb
#define PIRQB 11 to #define PIRQB 5
This will move audio and eth0 to 5 while USB will be on 10 and 11.
Marc
I changed this and nothing happens - i have put lspci ouput and irq source in the attachment...
00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10) Subsystem: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet 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: 64 (8000ns min, 16000ns max), Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 11 Region 0: I/O ports at 1000 [size=256] Region 1: Memory at fe019000 (32-bit, non-prefetchable) [size=256] Expansion ROM at ffec0000 [disabled] [size=128K] Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME-
... seems that it doenst change the IRQ?
regards,
steffen
Steffen, That change should work. Either is didn't rebuild or there ROM didn't flash or some other problem. You should try again with a clean make etc.
The change of PIRQB affect the following line of the IRQ routing table: {0x00, (0x0D << 3) | 0x0, {{L_PIRQB, M_PIRQB}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0}, /* ethernet */
Device 0d:0 only has 1 IRQ and it will be set to 5 if you follow the defines back.
Based on looking at your lspci output, I don't think this or the busmaster comment from the other email is the problem.
In the future lspci -xxx or lspci -xxxvvv is the most useful for making comparisons.
Marc
-
Juergen Beisert -
Marc Jones -
Marc Jones
-
Peter Stuge -
ron minnich -
Stefan Reinauer -
Steffen D.