Re: RELENG_8 em(4) -- input errors ("Missed Packets")
I do not believe this is a problem, a bit hard to parse the numbers on that netstat, but missed packets will happen when an interface gets lots of traffic. Keep an eye on things though. Thanks, Jack On Sat, Jun 19, 2010 at 12:23 PM, Jeremy Chadwick wrote: > Something I came across today on a RELENG_8 (8.1-PRERELEASE, amd64, > built Jun 8th) system we have: > > $ netstat -i -n -d -I em1 > NameMtu Network Address Ipkts Ierrs IdropOpkts > Oerrs Coll Drop > em11500 xx:xx:xx:xx:xx:xx 1611737117 0 11011087 > 0 00 > em11500 x/xx xxx 16108452 - - 11024972 > - -- > > The input errors are what concerned me. I poked dev.em.1.stats and got > the following: > > em1: Excessive collisions = 0 > em1: Sequence errors = 0 > em1: Defer count = 0 > em1: Missed Packets = 17 > em1: Receive No Buffers = 0 > em1: Receive Length Errors = 0 > em1: Receive errors = 0 > em1: Crc errors = 0 > em1: Alignment errors = 0 > em1: Collision/Carrier extension errors = 0 > em1: watchdog timeouts = 0 > em1: XON Rcvd = 0 > em1: XON Xmtd = 0 > em1: XOFF Rcvd = 0 > em1: XOFF Xmtd = 0 > em1: Good Packets Rcvd = 16117349 > em1: Good Packets Xmtd = 11046837 > em1: TSO Contexts Xmtd = 17609 > em1: TSO Contexts Failed = 0 > > What exactly does "Missed Packets" mean here? How is a packet "missed"? > Said port on our switch doesn't any sign of problems: > > hp2510g# show interfaces 2 > > Status and Counters - Port Counters for port 2 > > Name : port2 > Link Status : Up > Totals (Since boot or last clear) : > Bytes Rx: 3,548,949,136 Bytes Tx: 2,613,086,119 > Unicast Rx : 182,088,023Unicast Tx : 255,981,685 > Bcast/Mcast Rx : 14,674 Bcast/Mcast Tx : 81,852 > Errors (Since boot or last clear) : > FCS Rx : 0 Drops Rx: 0 > Alignment Rx: 0 Collisions Tx : 0 > Runts Rx: 0 Late Colln Tx : 0 > Giants Rx : 0 Excessive Colln : 0 > Total Rx Errors : 0 Deferred Tx : 0 > Rates (5 minute weighted average) : > Total Rx (bps) : 1457984Total Tx (bps) : 1494568 > Unicast Rx (Pkts/sec) : 0Unicast Tx (Pkts/sec) : 0 > B/Mcast Rx (Pkts/sec) : 0B/Mcast Tx (Pkts/sec) : 0 > Utilization Rx : 00.04 %Utilization Tx : 00.04 % > > Relevant userland and kernel stuff: > > $ ifconfig em1 > em1: flags=8843 metric 0 mtu 1500 > > > options=219b >ether xx:xx:xx:xx:xx:xx >inet xxx netmask xx broadcast xxx >media: Ethernet autoselect (1000baseT ) >status: active > > $ netstat -m > 2162/1678/3840 mbufs in use (current/cache/total) > 2048/1030/3078/25600 mbuf clusters in use (current/cache/total/max) > 2048/896 mbuf+clusters out of packet secondary zone in use (current/cache) > 0/104/104/12800 4k (page size) jumbo clusters in use > (current/cache/total/max) > 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) > 4636K/2895K/7532K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0/0/0 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 0 calls to protocol drain routines > > $ vmstat -i > interrupt total rate > irq4: uart0 868 0 > irq6: fdc0 1 0 > irq23: uhci3 ehci1+ 332 0 > cpu0: timer 1818467717 2000 > irq256: em0 375532 0 > irq257: em1 5004095 5 > irq258: ahci05879898 6 > cpu1: timer 1818466783 2000 > cpu3: timer 1818466831 2000 > cpu2: timer 1818466828 2000 > Total 7285128885 8012 > > $ dmesg | grep em1 > em1: port 0x3000-0x301f mem > 0xd030-0xd031 irq 17 at device 0.0 on pci15 > em1: Using MSI interrupt > em1: [FILTER] > > $ pciconf -lvc > e...@pci0:15:0:0:class=0x02 card=0x109a15d9 chip=0x109a8086 > rev=0x00 hdr=0x00 >vendor = 'Intel Corporation' >device = 'Intel PRO/1000 PL Network Adaptor (82573L)' >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 max data 128(256) link x1(x1) > > -- > | Jeremy Chadwick j...@parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX S
Re: if_em problems, both 7 and 8-stable
On Sat, Jun 19, 2010 at 5:28 PM, Pete Carah wrote: > I cannot successfully create a vlan on if_em on either releng 7 or releng 8; > I have seen a patch for part of > the problem (checksum offsets end up incorrect) but not all. Even turning > off ALL hw_xxx flags leaves one > unacceptable bug - the interface gets hard-reset any time you add or delete > a vlan. I *know* that cisco > uses these interfaces without these problems, so it has to be possible. I > have used vlans in linux without > appearing to get the same problems, though I'm not sure the rest of the > configuration matches. > > What gives, especially since the patch for one of the problems (wrong > checksum offsets) was generated > about 6 months ago... > > We are trying to use an intel platform as a router; this is a show-stopper. > I could try linux though I prefer not to... Would it be possible for you to provide more details about the hardware and software setup? The Intel chip and the revision (or relevant CVS info) about the builds of 7-RELENG and 8-RELENG would be useful, perhaps the dmesg of the machine and output of `pciconf -lv`? For what it's worth, I'm using vlans on an "Intel 82566DM Gigabit Ethernet Adapter (82566DM)", on-board in my Dell Optiplex 755, all hardware options on... $ ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=219b ether 00:1e:4f:d5:84:b7 inet 10.7.0.7 netmask 0xff00 broadcast 10.255.255.255 media: Ethernet autoselect (1000baseT ) status: active -Brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
if_em problems, both 7 and 8-stable
I cannot successfully create a vlan on if_em on either releng 7 or releng 8; I have seen a patch for part of the problem (checksum offsets end up incorrect) but not all. Even turning off ALL hw_xxx flags leaves one unacceptable bug - the interface gets hard-reset any time you add or delete a vlan. I *know* that cisco uses these interfaces without these problems, so it has to be possible. I have used vlans in linux without appearing to get the same problems, though I'm not sure the rest of the configuration matches. What gives, especially since the patch for one of the problems (wrong checksum offsets) was generated about 6 months ago... We are trying to use an intel platform as a router; this is a show-stopper. I could try linux though I prefer not to... -- Pete ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: RELENG_8 em(4) -- input errors ("Missed Packets")
On Sat, Jun 19, 2010 at 12:23:44PM -0700, Jeremy Chadwick wrote: > Something I came across today on a RELENG_8 (8.1-PRERELEASE, amd64, > built Jun 8th) system we have: > > $ netstat -i -n -d -I em1 > NameMtu Network Address Ipkts Ierrs IdropOpkts > Oerrs Coll Drop > em11500 xx:xx:xx:xx:xx:xx 1611737117 0 11011087 > 0 00 > em11500 x/xx xxx 16108452 - - 11024972 > - -- > > The input errors are what concerned me. I poked dev.em.1.stats and got > the following: > > em1: Excessive collisions = 0 > em1: Sequence errors = 0 > em1: Defer count = 0 > em1: Missed Packets = 17 > em1: Receive No Buffers = 0 > em1: Receive Length Errors = 0 > em1: Receive errors = 0 > em1: Crc errors = 0 > em1: Alignment errors = 0 > em1: Collision/Carrier extension errors = 0 > em1: watchdog timeouts = 0 > em1: XON Rcvd = 0 > em1: XON Xmtd = 0 > em1: XOFF Rcvd = 0 > em1: XOFF Xmtd = 0 > em1: Good Packets Rcvd = 16117349 > em1: Good Packets Xmtd = 11046837 > em1: TSO Contexts Xmtd = 17609 > em1: TSO Contexts Failed = 0 > > What exactly does "Missed Packets" mean here? How is a packet "missed"? >From Intel's data sheet: MPC (04010h; RC) Counts the number of missed packets. Packets are missed when the receive FIFO has insufficient space to store the incoming packet. This can be caused because of too few buffers allocated, or because there is insufficient bandwidth on the PCI bus. Events setting this counter cause RXO, the Receiver Overrun Interrupt, to be set. This register does not increment if receives are not enabled. These packets are also counted in the Total Packets Received register as well as in Total Octets Received. Driver in HEAD supports detailed hardware MAC counters so that may give you more better idea what's happening here. I vaguely remember I saw this when I perform 64bytes UDP torture test. > Said port on our switch doesn't any sign of problems: > > hp2510g# show interfaces 2 > > Status and Counters - Port Counters for port 2 > > Name : port2 > Link Status : Up > Totals (Since boot or last clear) : >Bytes Rx: 3,548,949,136 Bytes Tx: 2,613,086,119 >Unicast Rx : 182,088,023Unicast Tx : 255,981,685 >Bcast/Mcast Rx : 14,674 Bcast/Mcast Tx : 81,852 > Errors (Since boot or last clear) : >FCS Rx : 0 Drops Rx: 0 >Alignment Rx: 0 Collisions Tx : 0 >Runts Rx: 0 Late Colln Tx : 0 >Giants Rx : 0 Excessive Colln : 0 >Total Rx Errors : 0 Deferred Tx : 0 > Rates (5 minute weighted average) : >Total Rx (bps) : 1457984Total Tx (bps) : 1494568 >Unicast Rx (Pkts/sec) : 0Unicast Tx (Pkts/sec) : 0 >B/Mcast Rx (Pkts/sec) : 0B/Mcast Tx (Pkts/sec) : 0 >Utilization Rx : 00.04 %Utilization Tx : 00.04 % > > Relevant userland and kernel stuff: > > $ ifconfig em1 > em1: flags=8843 metric 0 mtu 1500 > > options=219b > ether xx:xx:xx:xx:xx:xx > inet xxx netmask xx broadcast xxx > media: Ethernet autoselect (1000baseT ) > status: active > > $ netstat -m > 2162/1678/3840 mbufs in use (current/cache/total) > 2048/1030/3078/25600 mbuf clusters in use (current/cache/total/max) > 2048/896 mbuf+clusters out of packet secondary zone in use (current/cache) > 0/104/104/12800 4k (page size) jumbo clusters in use (current/cache/total/max) > 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) > 4636K/2895K/7532K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0/0/0 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 0 calls to protocol drain routines > > $ vmstat -i > interrupt total rate > irq4: uart0 868 0 > irq6: fdc0 1 0 > irq23: uhci3 ehci1+ 332 0 > cpu0: timer 1818467717 2000 > irq256: em0 375532 0 > irq257: em1 5004095 5 > irq258: ahci05879898 6 > cpu1: timer 1818466783 2000 > cpu3: timer 1818466831 2000 > cpu2: timer 1818466828 2000 > Total 7285128885 8012 > > $ dmesg | grep em1 > em1: port 0x3000-0x301f mem > 0xd030-0xd031 irq 17 at device 0.0 on pci15 > em1: Using MSI interrupt > em1: [FILTER] > > $ pciconf -lvc > e...@pci0:15:0:0:
[patch] Unbreak libgssapi and upgrade for heimdal-1.1
Hello, The following patch unbreaks libgssapi and upgrades it to be consistent with the previous heimdal-1.1 merge: http://www.b1c1l1.com/media/patches/libgssapi-9.0-CURRENT.diff.bz2 http://www.b1c1l1.com/media/patches/libgssapi-8.1-STABLE.diff.bz2 Currently, libgssapi is out of date because it was not upgraded when the rest of heimdal was upgraded to heimdal-1.1. Also, 3 new libraries (libgssapi_krb5, libgssapi_ntlm, libgssapi_spnego) were unnecessarily introduced -- MIT Kerberos separates these libraries, but Heimdal does not. This broke some libgssapi-dependent applications (e.g. www/mod_auth_kerb2, PR #147282). SHLIB_MAJOR is bumped from 10 to 11, so libgssapi-dependent applications must be rebuilt after applying this patch. I renamed some of upstream's files due to filename collisions. If buildworld can create corresponding subdirectories in obj/ to match src/, then the renames are not necessary. Feedback is appreciated. Thanks, -- Benjamin Lee http://www.b1c1l1.com/ signature.asc Description: OpenPGP digital signature
RELENG_8 em(4) -- input errors ("Missed Packets")
Something I came across today on a RELENG_8 (8.1-PRERELEASE, amd64, built Jun 8th) system we have: $ netstat -i -n -d -I em1 NameMtu Network Address Ipkts Ierrs IdropOpkts Oerrs Coll Drop em11500 xx:xx:xx:xx:xx:xx 1611737117 0 11011087 0 00 em11500 x/xx xxx 16108452 - - 11024972 - -- The input errors are what concerned me. I poked dev.em.1.stats and got the following: em1: Excessive collisions = 0 em1: Sequence errors = 0 em1: Defer count = 0 em1: Missed Packets = 17 em1: Receive No Buffers = 0 em1: Receive Length Errors = 0 em1: Receive errors = 0 em1: Crc errors = 0 em1: Alignment errors = 0 em1: Collision/Carrier extension errors = 0 em1: watchdog timeouts = 0 em1: XON Rcvd = 0 em1: XON Xmtd = 0 em1: XOFF Rcvd = 0 em1: XOFF Xmtd = 0 em1: Good Packets Rcvd = 16117349 em1: Good Packets Xmtd = 11046837 em1: TSO Contexts Xmtd = 17609 em1: TSO Contexts Failed = 0 What exactly does "Missed Packets" mean here? How is a packet "missed"? Said port on our switch doesn't any sign of problems: hp2510g# show interfaces 2 Status and Counters - Port Counters for port 2 Name : port2 Link Status : Up Totals (Since boot or last clear) : Bytes Rx: 3,548,949,136 Bytes Tx: 2,613,086,119 Unicast Rx : 182,088,023Unicast Tx : 255,981,685 Bcast/Mcast Rx : 14,674 Bcast/Mcast Tx : 81,852 Errors (Since boot or last clear) : FCS Rx : 0 Drops Rx: 0 Alignment Rx: 0 Collisions Tx : 0 Runts Rx: 0 Late Colln Tx : 0 Giants Rx : 0 Excessive Colln : 0 Total Rx Errors : 0 Deferred Tx : 0 Rates (5 minute weighted average) : Total Rx (bps) : 1457984Total Tx (bps) : 1494568 Unicast Rx (Pkts/sec) : 0Unicast Tx (Pkts/sec) : 0 B/Mcast Rx (Pkts/sec) : 0B/Mcast Tx (Pkts/sec) : 0 Utilization Rx : 00.04 %Utilization Tx : 00.04 % Relevant userland and kernel stuff: $ ifconfig em1 em1: flags=8843 metric 0 mtu 1500 options=219b ether xx:xx:xx:xx:xx:xx inet xxx netmask xx broadcast xxx media: Ethernet autoselect (1000baseT ) status: active $ netstat -m 2162/1678/3840 mbufs in use (current/cache/total) 2048/1030/3078/25600 mbuf clusters in use (current/cache/total/max) 2048/896 mbuf+clusters out of packet secondary zone in use (current/cache) 0/104/104/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 4636K/2895K/7532K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines $ vmstat -i interrupt total rate irq4: uart0 868 0 irq6: fdc0 1 0 irq23: uhci3 ehci1+ 332 0 cpu0: timer 1818467717 2000 irq256: em0 375532 0 irq257: em1 5004095 5 irq258: ahci05879898 6 cpu1: timer 1818466783 2000 cpu3: timer 1818466831 2000 cpu2: timer 1818466828 2000 Total 7285128885 8012 $ dmesg | grep em1 em1: port 0x3000-0x301f mem 0xd030-0xd031 irq 17 at device 0.0 on pci15 em1: Using MSI interrupt em1: [FILTER] $ pciconf -lvc e...@pci0:15:0:0:class=0x02 card=0x109a15d9 chip=0x109a8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel PRO/1000 PL Network Adaptor (82573L)' 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 max data 128(256) link x1(x1) -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Strange video mode output with VESA
>On Wednesday 02 June 2010 04:25 pm, David DEMELIER wrote: >> Hi there, >> >> I was so happy to see that VESA is available for amd64, but >> unfortunately it does not work really well for me. Take a look at >> this picture : >> >> http://img717.imageshack.us/img717/7311/dsc00399h.jpg >> >> My laptop is a 15,6" so the best resolution is 1366x768, I tried >> this >> >> : vidcontrol MODE_496. As you can see on the picture all the lines >> : are >> >> completely everywhere, if I mouse the cursor they move away (I'm >> not drunk!). >> >> I have SC_PIXEL_MODE in my kernel config. >> >> The console terminal is okay until I don't excess 1280x960x32 video >> mode. >> >> Do you have any idea to fix this ? > >It is kinda known problem. If the mode has larger bytes per scan line >than the minimum, few characters per line are lost when the screen is >scrolled up or down, i.e., framebuffer copies of whole screen. When >you move the mouse onto the line, entire line is redrawn and >restored. That's what you are seeing. Ed might have a better idea >how to fix it (CC'ed). > >Jung-uk Kim this is incorrent calculate the scan lines in the vesa driver Jung-uk Kim should to fix it ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: network deamons starting before network!
On 06/18/10 12:20, Alfred Bartsch wrote: > Mark Stapper schrieb: > >> Hello, >> >> Since updating to 8.X I noticed that network services were started >> before the network was up! >> I use lagg failover configuration on both my FreeBSD boxes. >> First, boot fails on mounting my nfs-shares. >> After entering and exiting the "rescue" shell, the system boots as normal. >> > Hello, > > adding: > synchronous_dhclient="YES" > to /etc/rc.conf solved some similar issues for me. > The default behaviour of getting an IP via dhcp has changed. > I'll try that too. That would explain why I didn't have this problem on 7.2 I DO like the whole netwait idea though. But for me, the synchronous_dhclient flag should be sufficient I think. signature.asc Description: OpenPGP digital signature
Re: 7.2-RELEASE-p4, IO errors & RAID1 failure
on 18/06/2010 20:42 Jeremy Chadwick said the following: > http://wiki.freebsd.org/JeremyChadwick/ATA_issues_and_troubleshooting > > I've always read IDNF to mean "OS requested access (read or write) to an > LBA which is out of bounds", where "out of bounds" means "not between 0 > and ". How exactly is that possible? Alexander, do you have > any familiarity with this error code per ATA spec? I think that there is another possibility. I think that sector IDs could be written somewhere on media, in some sector service information block. And if that information can not be read, then the sector can not be found. But I am not sure, just trying to come up with an explanation. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: qbittorrent 2.2.9 8.0-STABLE Amd64
on 19/06/2010 09:50 Doug Barton said the following: > On 06/18/10 10:26, Andriy Gapon wrote: >> on 18/06/2010 18:51 Жиндарев Алексей said the following: >>> Jun 18 19:33:54 last message repeated 371 times >>> Jun 18 19:41:31 last message repeated 1359 times >>> Jun 18 19:43:29 kernel: WARNING pid 31369 (qbittorrent): ioctl >>> sign-extension ioctl 8004667e >>> Jun 18 19:44:00 last message repeated 545 times >>> Jun 18 19:45:45 last message repeated 1751 times >>> Jun 18 19:45:46 kernel: WARNING pid 31369 (qbittorrent): ioctl >>> sign-extension ioctl 8004667e >>> Jun 18 19:46:17 last message repeated 481 times >>> >>> Manifested after the new port, possibly after updating QT >> >> This is FIONBIO ioctl. Look through the code where this is passed via >> a variable >> of incorrect type. Correct type for ioctl request should be unsigned >> long. > > I can't find any references to FIONBIO at all, or even the word ioctl. > The software in question is a bittorrent client, I can't see any reason > it would even use ioctl's directly. I also checked the > libtorrent-rasterbar sources (which qbittorrent uses) and there is no > FIONBIO there either. You should have made one step further, to qt4-network :-) See: qt-everywhere-opensource-src-4.6.3/src/network/socket/qnet_unix_p.h static inline int qt_safe_ioctl(int sockfd, int request, T arg) "int request" should be "unsigned long request" on BSD. I think that this should be reported to Qt team, I am CC-ing our KDE team. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
