re weird bug
Hi, yesterday I csup'ped my 8-current sources on my MSI Wind netbook (again) and tried to build new kernel. There is again a problem with re interface. It just does not work, with following re0: port 0xc000-0xc0ff mem 0xffd1-0xffd10fff,0xffd0-0xffd0 irq 16 at device 0.0 on pci1 re0: Chip rev. 0x3480 re0: MAC rev. 0x0020 re0: PHY write failed re0: PHY write failed re0: MII without any phy! device_attach: re0 attach returned 6 in dmesg. This happened already some time ago, but I did not investigate it, just reverted to older kernel and later it disappeared. Today I found there is some timing issue or racing condition - when I boot with verbose message logging, it works with expected re0: port 0xc000-0xc0ff mem 0xffd1-0xffd10fff,0xffd0-0xffd0 irq 16 at device 0.0 on pci1 re0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xffd1 re0: MSI count : 1 re0: Chip rev. 0x3480 re0: MAC rev. 0x0020 miibus0: on re0 rlphy0: PHY 1 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto re0: bpf attached re0: Ethernet address: 00:1d:92:59:f5:8b re0: [MPSAFE] re0: [FILTER] So I think some issue could be in miibus or rlphy code. I am using stripped down kernel with no interfaces, I kldload if_re (and miibus as dependency), if that matters. Has anybody an idea or patch to test? Something similar appeared recently on list, but I would like to get issue commented first (maybe with a pointer to patch). Regards, Milan ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: re weird bug
On Thu, Oct 30, 2008 at 08:29:35AM +0100, Milan Obuch wrote: > Hi, > yesterday I csup'ped my 8-current sources on my MSI Wind netbook (again) and > tried to build new kernel. There is again a problem with re interface. It > just does not work, with following > > re0: port 0xc000-0xc0ff mem > 0xffd1-0xffd10fff,0xffd0-0xffd0 irq 16 at device 0.0 on pci1 > re0: Chip rev. 0x3480 > re0: MAC rev. 0x0020 > re0: PHY write failed > re0: PHY write failed > re0: MII without any phy! > device_attach: re0 attach returned 6 > > in dmesg. This happened already some time ago, but I did not investigate it, > just reverted to older kernel and later it disappeared. Today I found there > is some timing issue or racing condition - when I boot with verbose message > logging, it works with expected > > re0: port 0xc000-0xc0ff mem > 0xffd1-0xffd10fff,0xffd0-0xffd0 irq 16 at device 0.0 on pci1 > re0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xffd1 > re0: MSI count : 1 > re0: Chip rev. 0x3480 > re0: MAC rev. 0x0020 > miibus0: on re0 > rlphy0: PHY 1 on miibus0 > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > re0: bpf attached > re0: Ethernet address: 00:1d:92:59:f5:8b > re0: [MPSAFE] > re0: [FILTER] > > So I think some issue could be in miibus or rlphy code. > I am using stripped down kernel with no interfaces, I kldload if_re (and > miibus as dependency), if that matters. > Has anybody an idea or patch to test? Something similar appeared recently on > list, but I would like to get issue commented first (maybe with a pointer to > patch). > That's known issue for newer RealTek PCIe controllers. Would you please try the patch at the following URL? http://people.freebsd.org/~yongari/re/re.ephy.patch.20081021 Since it's not easy to reproduce this issue please make sure to (cold and warm) reboot several times until you can put confidence in the patch. -- Regards, Pyun YongHyeon ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: two NIC on 2 core system (scheduling problem)
Wednesday 29 of October 2008 14:34:05 Alexander Motin napisał(a): > Bartosz Giza wrote: > > So now i am lost again. If packet filtering on bge card is counted to > > irq17: bge0 process so i think it should use more cpu. > > From what you wrote there should be no difference for me if card use > > tasq or irq. Those processes do exactly the same thing? If that is true > > so why there is so much difference in cpu usage: > > > > 20 root 1 -68- 0K 8K - 0 161:01 18.75% em0 > > taskq 21 root 1 -68- 0K 8K WAIT 1 100:10 5.47% > > irq17: bge0 23 root 1 -68- 0K 8K WAIT 0 75:31 > > 2.98% irq16: fxp1 > > > > If what you wrote is true that overhead of incomming packet on bge0 > > should be counted to irq17: bge0 > > So don't understand why there is so big cpu usage on em0. From what you > > are saying irq17 and em0 taskq should have similar usage. Even more > > bge0 passes about two times more traffic than em0. I simply don't > > understand this. > > > > So don't understand why there is so big cpu usage on em0. > > Have no idea, there are too much possibilities to answer without > profiling. Different incoming packet rates, different firewall match > patterns in opposite directions, different card's hardware at least. I > have noticed that even different types of em cards may have twice as > different CPU usage due to using different interrupt moderation > techniques. THanks for all hints that you gave me. I have found what cause this high cpu usage ipfw :) I have a lot of rules in ipfw and actually i have tune them up and after that em0 taskq process sterted to use less cpu(similar to bge0). It was bad firewall design Could you tell me which chipset from intel would you recommend or you know that is best from all that you tested. Once again thanks for answers :) ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: two NIC on 2 core system (scheduling problem)
Bartosz Giza wrote: > Could you tell me which chipset from intel would you recommend or you know > that is best from all that you tested. I haven't investigated that specially to recommend something as most of my cards are integrated, but now I have newer systems with: [EMAIL PROTECTED]:0:0: class=0x02 card=0x108c15d9 chip=0x108c8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82573E Intel Corporation 82573E Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint and older systems with: [EMAIL PROTECTED]:10:0: class=0x02 card=0x12138086 chip=0x10138086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82541EI Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet cap 01[dc] = powerspec 2 supports D0 D3 current D0 cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction I can't compare load directly now as load is different, but I have noticed benefits after replacing old systems with new ones. General recommendation is usual: newer is usually better. :) -- Alexander Motin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
LevelOne WPC-0301 11g Wireless CardBus
Hello, I bought a LevelOne WPC-0301 11g Wireless CardBus Adapter today. According to the box it is "v6". The ral(4) man- page mentions only v2, but that one is ancient and can't be bought anymore. So, enabling the debug sysctl gives this in dmesg: cardbus0: Expecting link target, got 0x0 cardbus0: at device 0.0 (no driver attached) cardbus0: CIS pointer is 0x102 cardbus0: CIS in BAR 0x14 cardbus0: Expecting link target, got 0x0 cardbus0: Warning: Bogus CIS ignored cardbus0: at device 0.0 (no driver attached) I tried the card in a different notebook, same thing. Anything I can do, except drop the new card in the dustbin? :-( Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd We're sysadmins. To us, data is a protocol-overhead. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: re weird bug
On Thursday 30 October 2008 11:26:56 Pyun YongHyeon wrote: > On Thu, Oct 30, 2008 at 08:29:35AM +0100, Milan Obuch wrote: > > Hi, > > yesterday I csup'ped my 8-current sources on my MSI Wind netbook (again) > > and tried to build new kernel. There is again a problem with re > > interface. It just does not work, with following > > > > re0: port 0xc000-0xc0ff > > mem 0xffd1-0xffd10fff,0xffd0-0xffd0 irq 16 at device 0.0 on > > pci1 re0: Chip rev. 0x3480 > > re0: MAC rev. 0x0020 > > re0: PHY write failed > > re0: PHY write failed > > re0: MII without any phy! > > device_attach: re0 attach returned 6 > > > > in dmesg. This happened already some time ago, but I did not investigate > > it, just reverted to older kernel and later it disappeared. Today I > > found there is some timing issue or racing condition - when I boot with > > verbose message logging, it works with expected > > > > re0: port 0xc000-0xc0ff > > mem 0xffd1-0xffd10fff,0xffd0-0xffd0 irq 16 at device 0.0 on > > pci1 re0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xffd1 > > re0: MSI count : 1 > > re0: Chip rev. 0x3480 > > re0: MAC rev. 0x0020 > > miibus0: on re0 > > rlphy0: PHY 1 on miibus0 > > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > re0: bpf attached > > re0: Ethernet address: 00:1d:92:59:f5:8b > > re0: [MPSAFE] > > re0: [FILTER] > > > > So I think some issue could be in miibus or rlphy code. > > I am using stripped down kernel with no interfaces, I kldload if_re (and > > miibus as dependency), if that matters. > > Has anybody an idea or patch to test? Something similar appeared > > recently on list, but I would like to get issue commented first (maybe > > with a pointer to patch). > > That's known issue for newer RealTek PCIe controllers. Would you > please try the patch at the following URL? > http://people.freebsd.org/~yongari/re/re.ephy.patch.20081021 > > Since it's not easy to reproduce this issue please make sure to > (cold and warm) reboot several times until you can put confidence > in the patch. I tried, but no change - with patch applied re still does not work unless I boot with verbose logging, no matter whether I boot cold or warm. Regards, Milan ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: re weird bug
On Thu, Oct 30, 2008 at 10:41:01PM +0100, Milan Obuch wrote: > On Thursday 30 October 2008 11:26:56 Pyun YongHyeon wrote: > > On Thu, Oct 30, 2008 at 08:29:35AM +0100, Milan Obuch wrote: > > > Hi, > > > yesterday I csup'ped my 8-current sources on my MSI Wind netbook (again) > > > and tried to build new kernel. There is again a problem with re > > > interface. It just does not work, with following > > > > > > re0: port 0xc000-0xc0ff > > > mem 0xffd1-0xffd10fff,0xffd0-0xffd0 irq 16 at device 0.0 on > > > pci1 re0: Chip rev. 0x3480 > > > re0: MAC rev. 0x0020 > > > re0: PHY write failed > > > re0: PHY write failed > > > re0: MII without any phy! > > > device_attach: re0 attach returned 6 > > > > > > in dmesg. This happened already some time ago, but I did not investigate > > > it, just reverted to older kernel and later it disappeared. Today I > > > found there is some timing issue or racing condition - when I boot with > > > verbose message logging, it works with expected > > > > > > re0: port 0xc000-0xc0ff > > > mem 0xffd1-0xffd10fff,0xffd0-0xffd0 irq 16 at device 0.0 on > > > pci1 re0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xffd1 > > > re0: MSI count : 1 > > > re0: Chip rev. 0x3480 > > > re0: MAC rev. 0x0020 > > > miibus0: on re0 > > > rlphy0: PHY 1 on miibus0 > > > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > > re0: bpf attached > > > re0: Ethernet address: 00:1d:92:59:f5:8b > > > re0: [MPSAFE] > > > re0: [FILTER] > > > > > > So I think some issue could be in miibus or rlphy code. > > > I am using stripped down kernel with no interfaces, I kldload if_re (and > > > miibus as dependency), if that matters. > > > Has anybody an idea or patch to test? Something similar appeared > > > recently on list, but I would like to get issue commented first (maybe > > > with a pointer to patch). > > > > That's known issue for newer RealTek PCIe controllers. Would you > > please try the patch at the following URL? > > http://people.freebsd.org/~yongari/re/re.ephy.patch.20081021 > > > > Since it's not easy to reproduce this issue please make sure to > > (cold and warm) reboot several times until you can put confidence > > in the patch. > > I tried, but no change - with patch applied re still does not work unless I > boot with verbose logging, no matter whether I boot cold or warm. > Thanks for testing. If you look into patched if_re.c you can see a "#if 1" in function re_ephy_config(). How about changing it to "#if 0" to enable more aggresive reprogramming for EPHY register? -- Regards, Pyun YongHyeon ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
rate limiting icmp behavior
Hi All, Pardon if this has been posted. What is really the behavior of the system when it rate limit icmp (e.g. ICMP response)? Does it drop the excess of the outbound ICMP responses? If so, is their a way to see dropped responses from logs or other mechanism? Can this be turned-on at the inbound? Rate limit incoming ICMP request? Did someone experienced system reboots/hangup from this? I've search gnats but I coudn't find bugs related to this. Thanks, sho ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: two NIC on 2 core system (scheduling problem)
On Tue, 28 Oct 2008 12:21:32 +0100 Ivan Voras <[EMAIL PROTECTED]> wrote: > Oleksandr Samoylyk wrote: > > Ivan Voras wrote: > >> Bartosz Giza wrote: > >> > >>> Another question is why em0 taskq is eating so much cpu ? BGE > >>> interface is actually one that pushes 2 times more packets than > >>> em0 and it uses about half cpu comparing to em0. Is that not > >>> strange ? Could someone tell my why is this happening ? BGE is > >>> faster ? or maybe i can tune some > >> > >> I have the same problem - em0 taskq eating incredible amounts of > >> CPU. If you find a solution, contact me! > >> > >> > > > > It could be not just a problem with em driver. > > Firstly, it's good to make profiling and find out what exactly eats > > CPU > > Can you give any pointers on how to profile the driver and/or the > network stack? > From what I remember from a couple of years ago you can use hwpmc in system mode to profile the kernel if you have a supported CPU - I certainly remember seeing the output of gprof tell me the UDP checksum function was taking most of the time in a test I ran. To get started you need options HWPMC_HOOKS and device hwpmc in your kernel config (hwpmc can also be a module) - then you run pmcstat to run the test. There's lots more information at http://wiki.freebsd.org/PmcTools -- Bruce Cran ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
