Re: netstat -ni - A lot of collisions...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Well, the card is connected to a switch that is manageble and the port is set to 10Mbit Full duplex on purpose. I'm not setting the port speed manual - is that a problem when the port is not 100mbit/fd? This is the ifconfig output: fxp0: flags=18843 mtu 1500 options=48 inet 112.15.128.88 netmask 0xff00 broadcast 112.15.128.255 inet6 fe80::208:c7ff:fe5b:54f2%fxp0 prefixlen 64 scopeid 0x2 ether 00:08:c7:5b:54:a5 media: Ethernet autoselect (10baseT/UTP) status: active -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFTwENzpU6eaWiiWgRAjwgAJ4rfWbA5xDWmHE1MxWn36j2Njs/swCbBzJM Hg+zdfQGMra50Rh7k290Ofw= =DtBT -END PGP SIGNATURE- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Watchdog Timeout - bge device - 6.2-PRERELEASE
John Marshall wrote: I don't see this at all on 6.1 unless I use SCHED_ULE. (Although, I haven't compiled all those additional drivers into a 6.1 system, so that might not be a fair comparison.) Wrong! I saw this last night for the first time on a production hp ProLiant ML110 (6.1-RELEASE-p10). UP + SCHED_4BSD. So, 6.2 is no worse for me :-) By the way, I'm only running these BGE interfaces at 100 Full. rwsrv04> grep bge /var/log/messages Nov 6 01:02:09 rwsrv04 kernel: bge0: watchdog timeout -- resetting Nov 6 01:02:09 rwsrv04 kernel: bge0: link state changed to DOWN Nov 6 01:02:09 rwsrv04 kernel: bge0: link state changed to UP Nov 6 01:05:36 rwsrv04 kernel: bge0: watchdog timeout -- resetting Nov 6 01:05:36 rwsrv04 kernel: bge0: link state changed to DOWN Nov 6 01:05:36 rwsrv04 kernel: bge0: link state changed to UP rwsrv04> sysctl kern.version kern.sched kern.smp hw.machine hw.model dev.bgekern.version: FreeBSD 6.1-RELEASE-p10 #0: Tue Oct 31 00:06:13 AEDT 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/RWSRV04 kern.sched.name: 4BSD kern.sched.quantum: 10 kern.sched.followon: 0 kern.sched.pfollowons: 0 kern.sched.kgfollowons: 0 kern.sched.preemption: 1 kern.smp.maxcpus: 1 kern.smp.active: 0 kern.smp.disabled: 0 kern.smp.cpus: 1 hw.machine: i386 hw.model: Intel(R) Pentium(R) 4 CPU 2.80GHz dev.bge.0.%desc: Broadcom BCM5705K Gigabit Ethernet, ASIC rev. 0x3003 dev.bge.0.%driver: bge dev.bge.0.%location: slot=4 function=0 dev.bge.0.%pnpinfo: vendor=0x14e4 device=0x1654 subvendor=0x103c subdevice=0x1654 class=0x02 dev.bge.0.%parent: pci4 John Marshall. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: netstat -ni - A lot of collisions...
Anton - Valqk <[EMAIL PROTECTED]> wrote: > the card is connected to a switch that is manageble and the port is set > to 10Mbit Full duplex on purpose. > > I'm not setting the port speed manual - is that a problem when the port > is not 100mbit/fd? If you select the port parameters manually (i.e. disable autoselect), then you must do that on _both_ sides. Auto-negotiation only works correctly if both sides are using it. > This is the ifconfig output: > > fxp0: flags=18843 mtu 1500 > options=48 > inet 112.15.128.88 netmask 0xff00 broadcast 112.15.128.255 > inet6 fe80::208:c7ff:fe5b:54f2%fxp0 prefixlen 64 scopeid 0x2 > ether 00:08:c7:5b:54:a5 > media: Ethernet autoselect (10baseT/UTP) > status: active That means autoselect is enabled, so you have to enable it on your switch, too. Otherwise disable it on the computer and select the port parameters (speed and duplex mode) manually there, too. By the way, the above output indicates that your NIC's auto-negotiation has selected half-duplex. You said that your switch is set to full-duplex. So there is a mismatch which explains why you are getting collisions. Fix your port settings, then the collisions will go away. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "What is this talk of 'release'? We do not make software 'releases'. Our software 'escapes', leaving a bloody trail of designers and quality assurance people in its wake." ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: netstat -ni - A lot of collisions...
On Mon, Nov 06, 2006 at 11:31:57AM +0200, Anton - Valqk wrote: > Well, > the card is connected to a switch that is manageble and the port is set to > 10Mbit Full duplex on purpose. > > I'm not setting the port speed manual - is that a problem when the port is > not 100mbit/fd? > This is the ifconfig output: > > fxp0: flags=18843 mtu 1500 > options=48 > inet 112.15.128.88 netmask 0xff00 broadcast 112.15.128.255 > inet6 fe80::208:c7ff:fe5b:54f2%fxp0 prefixlen 64 scopeid 0x2 > ether 00:08:c7:5b:54:a5 > media: Ethernet autoselect (10baseT/UTP) > status: active I've never paid much attention to what ifconfig says, or what managed switches say, as far as speed or duplex negotiation go. Most vendors do not play well together. I'll repeat that because it needs repeating: most vendors do not play well together. Example: anyone familiar with Cisco Catalysts knows of the long-standing problem with auto-neg which ultimately requires both ends of the connection be set to 100/full. Try the following configurations: 1. FreeBSD rc.conf -- media 10baseT/UTP media-opt full-duplex Switch -- forced 10/full Reboot FreeBSD box 2. FreeBSD rc.conf -- media 10baseT/UTP media-opt full-duplex Switch -- auto-neg Reboot FreeBSD box 3. FreeBSD rc.conf -- media 10baseT/UTP media-opt full-duplex Switch -- auto-neg Reboot FreeBSD box Regarding the reboots: changing duplex/speed via ifconfig once the driver has already done its initial auto-negotiation appears to behave differently with some switches than on an actual boot-up. I have no present-day evidence to back this claim up, but it's something I've seen historically with xl and fxp. Now, the transfer test I've used in the past: * Make a "small" file (dd if=/dev/urandom of=test.bin bs=64k count=256) on the FreeBSD box * Make a similar file (identical or otherwise) on another box, one that runs an FTP server * From the FreeBSD box, FTP to the FTP server * Do an FTP "PUT" of test.bin * Make note if the transfer was slow, or quick (1MByte/sec) * Now do an FTP "GET" of the file you made on the FTP server * Make note if the transfer was slow, or quick (1MByte/sec) My guess is that one of the above tests will show very fast throughput in one direction (ex. PUT), while the other direction (ex. GET) will be incredibly slow (something like 100 bytes a second, maybe less). This is what I've seen in the past in environments where a switch is set to auto-neg and the FreeBSD box claims to auto-neg to 100/full correctly... but obviously doesn't (re: see above: Cisco). You can make note of collision counts if you want, too. Any slow transfers you see will probably show up as collisions, since somewhere along the lines things got confused and chose half-duplex (even if ifconfig or the switch doesn't show it). If all of the above tests seem OK (good speed, etc. -- yet the collisions continue to increase), I recommend checking the obvious: Ethernet cable wiring. You're going to have to get a RJ45/EIA-568 cable tester and verify that all 8 wires are connected and have good continuity. You're not going to get 10/full with a Ethernet cable that's wired with only 4 wires, AFAIK. Finally: why exactly are you using 10/full? What's the purpose? Are you trying to limit the actual maximum network throughput while ensuring you have full-duplex capability? If so: look into using pf with queueing (see pf.conf man page, section QUEUEING/ALTQ), or if that's not an option, use ipfw with dummynet. Make that box use 100/full, then simply limit the actual network I/O to 10mbit. For what it's worth: I've never seen a 10/full network that worked. It was either 100/full (switches), 100/half (hubs), or 10/half (hubs). There's some discussions (use Google) about why 10/full is essentially a bastard child and should be avoided. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://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 "[EMAIL PROTECTED]"
Re: dhclient taking up all CPU
Hi all,
Rebuilt dhclient with the bpf.c from RELENG_6 ( line 285 == -> >=)
According to the cvs commit log this fixes my problem.
Still leaves me wondering why this was not applied to RELENG_6_1
Kind regards,
Spil.
On 05/11/06, Brooks Davis <[EMAIL PROTECTED]> wrote:
It should be fixed in STABLE. The particular fixes were to bpf.c so I
belive (but have not verified) that if you grab the latest version of
that file, put it in src/sbin/dhclient/ and rebuild dhclient the
problems will go away.
-- Brooks
On Sun, Nov 05, 2006 at 09:12:25PM +0100, Spil Oss wrote:
> Hi all,
>
> Been experiencing this same behaviour every now-and-then.
>
> FreeBSD/i386 6.1-RELEASE-p10
>
> Any solutions to this?
>
> Kind regards,
>
> Spil.
>
> On 06/05/06, Lodewijk V??ge <[EMAIL PROTECTED]> wrote:
> >hello,
> >
> >a while ago someone reported the same problem I had been seeing, that
> >dhclient starts taking up 100% CPU. it's probably something comcast
> >is doing.
> >
> >I couldn't get the requested coredump then, if I set kern.corefile
> >to /tmp/%N.core and kill -QUIT it, it doesn't seem to produce a
> >coredump. but it happened again just now, and I was able to attach
> >gdb. this is where it's spinning, in receive_packet() in bpf.c:
> >
> >(gdb)
> >285 if (interface->rbuf_offset == interface-
> > >rbuf_len) {
> >(gdb)
> >299 if (interface->rbuf_len - interface-
> > >rbuf_offset <
> >(gdb)
> >306 memcpy(&hdr, &interface->rbuf[interface-
> > >rbuf_offset],
> >(gdb)
> >313 if (interface->rbuf_offset + hdr.bh_hdrlen +
> >hdr.bh_caplen >
> >(gdb)
> >320 interface->rbuf_offset += hdr.bh_hdrlen;
> >(gdb)
> >327 if (hdr.bh_caplen != hdr.bh_datalen) {
> >(gdb)
> >328 interface->rbuf_offset =
> >(gdb)
> >331 continue;
> >(gdb)
> >385 } while (!length);
> >
> >and then it goes back to line 285. interesting variables are:
> >
> >(gdb) p *interface
> >$1 = {next = 0x0, hw_address = {htype = 1 '\001', hlen = 6 '\006',
> >haddr = "\000\021??\223?\000\000\000\000\000\000\000\000\000"},
> >primary_address = {s_addr = 0},
> > name = "vr0", '\0' , rfdesc = 7, wfdesc = 7,
> >rbuf = 0x807d000 "\022?\\Dk\214", rbuf_max = 4096,
> > rbuf_offset = 416, rbuf_len = 415, ifp = 0x806f160, client =
> >0x8075000, noifmedia = 0, errors = 0, dead = 0, index = 2}
> >(gdb) p length
> >$2 = 0
> >(gdb) p hdr
> >$3 = {bh_tstamp = {tv_sec = 0, tv_usec = 0}, bh_caplen = 4294901760,
> >bh_datalen = 4294901778, bh_hdrlen = 65535}
> >
> >this is FreeBSD/i386 6.1-RC as of about two weeks ago.
> >
> >Lodewijk
> >
> >___
> >freebsd-stable@freebsd.org mailing list
> >http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> >To unsubscribe, send any mail to "[EMAIL PROTECTED]"
> >
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Mustek BearPaw 2448 TA Pro
Yes, no reply yet. But still I would like to ask: Does anyone have *ANY* experience with "Mustek BearPaw 2448 TA Pro" on FreeBSD ? This scanner was released in 2003. It is hard problem to find USB scanner on the market supported by sane. "Mustek ScanExpress 1248 UB" works well but is too slow. Regards, Vladimir Botka, Czech On Sun, 5 Nov 2006, Torfinn Ingolfsen wrote: On Sat, 04 Nov 2006 18:01:24 +0100 (CET) Vladimir Botka <[EMAIL PROTECTED]> wrote: This scanner is claimed to be supported but I can not get it configured. According to the man page and the web page: http://www.meier-geinitz.de/sane/mustek_usb2-backend/ the driver for this scanner is of beta quality. Have you tried to contact the SANE people about it? HTH -- Regards, Torfinn Ingolfsen, Norway ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD doesn't boot at Supermicro H8SSL-i2
Hello, I got a brand new Supermicro H8SSL-i2 http://www.supermicro.com/Aplus/motherboard/Opteron1000/HT1000/H8SSL-i2.cfm but FreeBSD i386 6.2 Beta3 doesn't boot, whether if acpi is enabled or not. The latest BIOS is installed. Here is a picture of the boot process with verbose logging: http://moldau.webmatic.de/h8-boot.jpg Any ideas? Regards, Thomas. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: netstat -ni - A lot of collisions...
On Mon, Nov 06, 2006 at 11:31:57AM +0200, Anton - Valqk wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Well, > the card is connected to a switch that is manageble and the port is set to > 10Mbit Full duplex on purpose. Your ifconfig output below shows halfduplex! > I'm not setting the port speed manual - is that a problem when the port is > not 100mbit/fd? > This is the ifconfig output: > > fxp0: flags=18843 mtu 1500 > options=48 > inet 112.15.128.88 netmask 0xff00 broadcast 112.15.128.255 > inet6 fe80::208:c7ff:fe5b:54f2%fxp0 prefixlen 64 scopeid 0x2 > ether 00:08:c7:5b:54:a5 > media: Ethernet autoselect (10baseT/UTP) ^^^ like here. Wilko ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD doesn't boot at Supermicro H8SSL-i2
On Mon, Nov 06, 2006 at 02:45:14PM +0100, Thomas Krause wrote: > Hello, > I got a brand new Supermicro H8SSL-i2 > http://www.supermicro.com/Aplus/motherboard/Opteron1000/HT1000/H8SSL-i2.cfm > but FreeBSD i386 6.2 Beta3 doesn't boot, whether if acpi is enabled or not. > The latest BIOS is installed. Here is a picture of the boot process with > verbose logging: > http://moldau.webmatic.de/h8-boot.jpg > Check that the USB speed setting in the BIOS is set to its defaults, either HiSpeed or FullSpeed, I don't remember exactly. If I change it, it similarly hangs on boot, but I'm using FreeBSD/amd64 on it. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpkVGeuzJlY5.pgp Description: PGP signature
Re: FreeBSD doesn't boot at Supermicro H8SSL-i2
>> > Check that the USB speed setting in the BIOS is set to its defaults, > either HiSpeed or FullSpeed, I don't remember exactly. If I change > it, it similarly hangs on boot, but I'm using FreeBSD/amd64 on it. Thanks very much for your hint! FreeBSD boots with USB 2.0 Controller Mode: Fullspeed *and* BIOS EHCI Hand-off: Enable BTW: There is no way to disable USB completely? Regards, Thomas. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dhclient taking up all CPU
It doesn't effect nearly enough people to warrent a commit to the eratta
branch. It's also not serious enough; the bar has typically been set at
the level of data corruption bugs.
-- Brooks
On Mon, Nov 06, 2006 at 02:20:42PM +0100, Spil Oss wrote:
> Hi all,
>
> Rebuilt dhclient with the bpf.c from RELENG_6 ( line 285 == -> >=)
> According to the cvs commit log this fixes my problem.
>
> Still leaves me wondering why this was not applied to RELENG_6_1
>
> Kind regards,
>
> Spil.
>
>
> On 05/11/06, Brooks Davis <[EMAIL PROTECTED]> wrote:
> >It should be fixed in STABLE. The particular fixes were to bpf.c so I
> >belive (but have not verified) that if you grab the latest version of
> >that file, put it in src/sbin/dhclient/ and rebuild dhclient the
> >problems will go away.
> >
> >-- Brooks
> >
> >On Sun, Nov 05, 2006 at 09:12:25PM +0100, Spil Oss wrote:
> >> Hi all,
> >>
> >> Been experiencing this same behaviour every now-and-then.
> >>
> >> FreeBSD/i386 6.1-RELEASE-p10
> >>
> >> Any solutions to this?
> >>
> >> Kind regards,
> >>
> >> Spil.
> >>
> >> On 06/05/06, Lodewijk V??ge <[EMAIL PROTECTED]> wrote:
> >> >hello,
> >> >
> >> >a while ago someone reported the same problem I had been seeing, that
> >> >dhclient starts taking up 100% CPU. it's probably something comcast
> >> >is doing.
> >> >
> >> >I couldn't get the requested coredump then, if I set kern.corefile
> >> >to /tmp/%N.core and kill -QUIT it, it doesn't seem to produce a
> >> >coredump. but it happened again just now, and I was able to attach
> >> >gdb. this is where it's spinning, in receive_packet() in bpf.c:
> >> >
> >> >(gdb)
> >> >285 if (interface->rbuf_offset == interface-
> >> > >rbuf_len) {
> >> >(gdb)
> >> >299 if (interface->rbuf_len - interface-
> >> > >rbuf_offset <
> >> >(gdb)
> >> >306 memcpy(&hdr, &interface->rbuf[interface-
> >> > >rbuf_offset],
> >> >(gdb)
> >> >313 if (interface->rbuf_offset + hdr.bh_hdrlen +
> >> >hdr.bh_caplen >
> >> >(gdb)
> >> >320 interface->rbuf_offset += hdr.bh_hdrlen;
> >> >(gdb)
> >> >327 if (hdr.bh_caplen != hdr.bh_datalen) {
> >> >(gdb)
> >> >328 interface->rbuf_offset =
> >> >(gdb)
> >> >331 continue;
> >> >(gdb)
> >> >385 } while (!length);
> >> >
> >> >and then it goes back to line 285. interesting variables are:
> >> >
> >> >(gdb) p *interface
> >> >$1 = {next = 0x0, hw_address = {htype = 1 '\001', hlen = 6 '\006',
> >> >haddr = "\000\021??\223?\000\000\000\000\000\000\000\000\000"},
> >> >primary_address = {s_addr = 0},
> >> > name = "vr0", '\0' , rfdesc = 7, wfdesc = 7,
> >> >rbuf = 0x807d000 "\022?\\Dk\214", rbuf_max = 4096,
> >> > rbuf_offset = 416, rbuf_len = 415, ifp = 0x806f160, client =
> >> >0x8075000, noifmedia = 0, errors = 0, dead = 0, index = 2}
> >> >(gdb) p length
> >> >$2 = 0
> >> >(gdb) p hdr
> >> >$3 = {bh_tstamp = {tv_sec = 0, tv_usec = 0}, bh_caplen = 4294901760,
> >> >bh_datalen = 4294901778, bh_hdrlen = 65535}
> >> >
> >> >this is FreeBSD/i386 6.1-RC as of about two weeks ago.
> >> >
> >> >Lodewijk
> >> >
> >> >___
> >> >freebsd-stable@freebsd.org mailing list
> >> >http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> >> >To unsubscribe, send any mail to
> >"[EMAIL PROTECTED]"
> >> >
> >
> >> ___
> >> freebsd-stable@freebsd.org mailing list
> >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> >> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
> >
> >
> >
> >
>
pgps9YbfWTZ5I.pgp
Description: PGP signature
em driver testing
According to the 6.2-beta3 announcemetn, there are improvements to the em driver. "The most important of the things that have been worked on is the driver for em(4). " I have a Sun X4100 which uses Intel ethernet. I would like to install amd64 6.2beta3 on this server and put it through some tests. But I have no idea what tests to run or how to run them. Can someone provide some pointers? I am happy to post my findings. thanks, ke han ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: netstat -ni - A lot of collisions...
> I've never paid much attention to what ifconfig says, or what > managed switches say, as far as speed or duplex negotiation go. > Most vendors do not play well together. I'll repeat that because > it needs repeating: most vendors do not play well together. > Example: anyone familiar with Cisco Catalysts knows of the > long-standing problem with auto-neg which ultimately requires > both ends of the connection be set to 100/full. I disagree. Autonegotiation used to be a problem, and we used to force all links to 100/full. But that was 3-4 years ago. These days, the situation is much improved - and in most cases autonegotiation "just works". That includes *lots* of Cisco Catalyst switches. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em driver testing
If memory serves me right, ke han wrote: > According to the 6.2-beta3 announcemetn, there are improvements to > the em driver. > > "The most important of the things that have been worked on is the > driver for em(4). " > > I have a Sun X4100 which uses Intel ethernet. I would like to > install amd64 6.2beta3 on this server and put it through some tests. > But I have no idea what tests to run or how to run them. > Can someone provide some pointers? I am happy to post my findings. There were a number of problems in em(4) that appeared post-6.1. A new version of the em(4) driver was merged to the RELENG_6 branch just prior to 6.2-BETA3. That version is better, but still has some unresolved issues (problems have been reported with jumbo frames and with watchdog timeouts). There's a new patch by jfv@ in an email a few days ago (with subject "New em patch for 6.2 BETA 3") that might fix these problems. It might be worthwhile to try this out. Basically, just look around the archives of stable@ to see discussions of the em driver over the past month or so. I believe that a number of prior problems were uncovered when people just tried to push a lot of traffic through the interface. Bruce. signature.asc Description: OpenPGP digital signature
Re: netstat -ni - A lot of collisions...
[EMAIL PROTECTED] wrote: >> I've never paid much attention to what ifconfig says, or what >> managed switches say, as far as speed or duplex negotiation go. >> Most vendors do not play well together. I'll repeat that because >> it needs repeating: most vendors do not play well together. >> Example: anyone familiar with Cisco Catalysts knows of the >> long-standing problem with auto-neg which ultimately requires >> both ends of the connection be set to 100/full. > > I disagree. Autonegotiation used to be a problem, and we used to force > all links to 100/full. But that was 3-4 years ago. These days, the > situation is much improved - and in most cases autonegotiation "just > works". That includes *lots* of Cisco Catalyst switches. Actually, we used to do the same. But nowadays it's gone completely the other way. Modern GigE capable ethernet interfaces seem to work better if you let them autonegotiate. That's even if they aren't running at Gig speed where autoneg is required by design. We've had a series of Broadcomm bge(4) network interfaces that would arbitrarily stop working if hardwired to 100-full, but that are doing just fine when allowed to autoneg. Switches are mostly HP Procurve if that makes any difference. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: netstat -ni - A lot of collisions...
On Mon, Nov 06, 2006 at 09:37:26PM +, Matthew Seaman wrote: > We've had a series of Broadcomm bge(4) network interfaces that would > arbitrarily stop working if hardwired to 100-full, but that are doing > just fine when allowed to autoneg. Switches are mostly HP Procurve if > that makes any difference. Interesting. I've got a ProCurve 2524 in our co-lo with tons of FreeBSD boxes hooked to it, all of which behave correctly via auto-neg. The FreeBSD boxes use a slew of NICs; em, fxp, and xl. The uplink port on our 2524 to our ISP, however, has to be set to 100/full on both ends (theirs and ours; theirs = Cisco, ours = HP) or else we end up with framing errors and other nonsense. For sake of comparison, I have sitting in my workroom a bge-based box hooked up to a ProCurve 2626 which behaves properly via auto-neg on both the 100mbit and the gigabit ports (I've tried both). I have not tried hard-setting them, since auto-neg seems to work. However, the instant I hook that box up to my Hawking non-managed gigabit switch (which is a switch where auto-neg has worked with every NIC I've tried until now), the switch and NIC auto-neg correctly to 1gb/full... except packets appear busted in some way: packets make it to the switch (one can see the LEDs blinking), yet the IP stack doesn't see anything in return. ARP also does not show anything. The fact that auto-neg is working, and that the switch indicates correct speed and duplex, makes me think this is some weird bge driver problem. Wiring is all CAT6, and obviously works fine with another switch. If I set `media 100baseTX mediaopt full-duplex` and reboot, everything works (at 100mbit of course) with that box. I'd love to give a kernel developer access to that box via serial console so they could debug what the heck is going on with auto-neg in that particular case. :-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://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 "[EMAIL PROTECTED]"
Re: em driver testing
Hello! On Tue, Nov 07, 2006 at 04:55:50AM +0800, ke han wrote: > I have a Sun X4100 which uses Intel ethernet. I would like to > install amd64 6.2beta3 on this server and put it through some tests. > But I have no idea what tests to run or how to run them. > Can someone provide some pointers? I am happy to post my findings. Put some CPU load on the machine, e.g. by running cd /usr/src sh while true do make -j4 buildworld done >mk.log on one terminal and then transfer some data to the system, e.g. by fetch(1)ing via FTP from another box connected to the same LAN. On all systems I have, there is no need to saturate the Gbit-Link. 100 Mbit/s local connection will trigger the problem, too. If the problem exists on your system, you will see emN - watchdog timeout messages on the console and in /var/log/messages, followed by a reset of the interface and a short and recoverable, but complete, loss of connectivity. A couple of seconds, maybe. This is enough to frustrate people, who e.g. run large backup jobs over a single TCP connection that takes a couple of hours to complete - the interface reset aborts the backup :-/ I must say that it seems to me, these guys are putting a hell of a lot of effort into this problem and "we" are making progress. Things look quite good to me for 6.2-RELEASE. HTH, Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Vorholzstr. 25Tel. 0721 9109 -0 Fax: -100 76137 Karlsruhe http://punkt.de ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Still have BCE driver issues (dell pe 1950) and NFS
NFS Server: dell poweredge 1950, with the 1.2.2.6 version of if_bce.c: bce0: mem 0xf400-0xf5ff irq 16 at device 0.0 on pci9 bce0: ASIC ID 0x57081010; Revision (B1); PCI-X 64-bit 133MHz miibus0: on bce0 bce0: Ethernet address: 00:13:72:f8:6f:8c bce0: link state changed to UP NFS Client: dell poweredge 1750, with : bge0: Both running an up-to-date setup of FreeBSD 6.1. Situation: - Copying GB of data via rsync or ftp: no problem - Mounting a test directory from the 1950 via NFS on the 1750 server and creating some files/directories: ok - Mounting a dir with many files via NFS (/var/tmp, 14000 php_sess): ok - Start a directory listing on it: immediate (network) crash of the NFS server. (reproduced 3 times) I don't have remote console display anymore (only power on/off), so I can only see the server going away from the network (not pingable anymore) at the moment, but it is most probably still working then. Only thing I found in /var/log/messages: Nov 6 23:09:44 gemini kernel: bce0: /usr/src/sys/dev/bce/if_bce.c(5000): Watchdog timeout occurred, resetting! Nov 6 23:09:44 gemini kernel: bce0: link state changed to DOWN Nov 6 23:09:46 gemini kernel: bce0: link state changed to UP Nov 6 23:10:49 gemini kernel: bce0: /usr/src/sys/dev/bce/if_bce.c(5000): Watchdog timeout occurred, resetting! Nov 6 23:10:49 gemini kernel: bce0: link state changed to DOWN Nov 6 23:10:51 gemini kernel: bce0: link state changed to UP What could/should I try next? The 1.18 version of if_bce.c ? (if the dell PE1950 is using the same NIC as the PE1955: cf. http://www.mail-archive.com/freebsd-stable@freebsd.org/msg83981.html ) Are there people around using a 1950 without any NIC problems? (tcp && udp). If yes, please tell me which cvs version of the driver you are using. Thanks & regards, Olivier ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em driver testing
Hi there I am having similar issues. Running 6.1-RELEASE. I'm using the box as a samba server with pure-ftpd on it too with 2.5T of raid storage in it. the box is running the generic MP kernel on a Tyan Thunder K7 with the latest bios v2.14 and dual AthlonMP's. ECC Reg ram that passed all tests with memtest. When I pull a few concurrent files over samba or if i pull a big file (say 2-3G) over ftp to my laptop it runs at 30MB/sec but usually locks up the box with watchdog timeout on the em interface. Usually it pops up with timeouts on the xl interface at the same time and after a few seconds on the ahc (onboard adaptec scsi) interfce and I have to hard boot the box to get it back to life. I''ve tried the same box with a 3com 3C996B-T NIC which has a Broadcom BCM5701TKHB chipset on it. It crashes within minutes with no traffic on the interface. In fact the interface will accept an IP address but times out pinging anything on the LAN. If a kernel developer would like access to the box to chek it out please mail me. Regards Clay Hello! On Tue, Nov 07, 2006 at 04:55:50AM +0800, ke han wrote: I have a Sun X4100 which uses Intel ethernet. I would like to install amd64 6.2beta3 on this server and put it through some tests. But I have no idea what tests to run or how to run them. Can someone provide some pointers? I am happy to post my findings. Put some CPU load on the machine, e.g. by running cd /usr/src sh while true do make -j4 buildworld done >mk.log on one terminal and then transfer some data to the system, e.g. by fetch(1)ing via FTP from another box connected to the same LAN. On all systems I have, there is no need to saturate the Gbit-Link. 100 Mbit/s local connection will trigger the problem, too. If the problem exists on your system, you will see emN - watchdog timeout messages on the console and in /var/log/messages, followed by a reset of the interface and a short and recoverable, but complete, loss of connectivity. A couple of seconds, maybe. This is enough to frustrate people, who e.g. run large backup jobs over a single TCP connection that takes a couple of hours to complete - the interface reset aborts the backup :-/ I must say that it seems to me, these guys are putting a hell of a lot of effort into this problem and "we" are making progress. Things look quite good to me for 6.2-RELEASE. HTH, Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Vorholzstr. 25Tel. 0721 9109 -0 Fax: -100 76137 Karlsruhe http://punkt.de ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em driver testing
Well, so run 6.2 BETA3 plus the patch I posted as Patrick mentioned and then report on that. You've got a lot of potential problem areas here, I have no experience with samba on FreeBSD. And that motherboard only has PCI as I recall, yes? Still, it should get rid of the watchdogs unless you have real hardware issues. Good luck, Jack On 11/6/06, Clayton Milos <[EMAIL PROTECTED]> wrote: Hi there I am having similar issues. Running 6.1-RELEASE. I'm using the box as a samba server with pure-ftpd on it too with 2.5T of raid storage in it. the box is running the generic MP kernel on a Tyan Thunder K7 with the latest bios v2.14 and dual AthlonMP's. ECC Reg ram that passed all tests with memtest. When I pull a few concurrent files over samba or if i pull a big file (say 2-3G) over ftp to my laptop it runs at 30MB/sec but usually locks up the box with watchdog timeout on the em interface. Usually it pops up with timeouts on the xl interface at the same time and after a few seconds on the ahc (onboard adaptec scsi) interfce and I have to hard boot the box to get it back to life. I''ve tried the same box with a 3com 3C996B-T NIC which has a Broadcom BCM5701TKHB chipset on it. It crashes within minutes with no traffic on the interface. In fact the interface will accept an IP address but times out pinging anything on the LAN. If a kernel developer would like access to the box to chek it out please mail me. Regards Clay > Hello! > > On Tue, Nov 07, 2006 at 04:55:50AM +0800, ke han wrote: > >> I have a Sun X4100 which uses Intel ethernet. I would like to >> install amd64 6.2beta3 on this server and put it through some tests. >> But I have no idea what tests to run or how to run them. >> Can someone provide some pointers? I am happy to post my findings. > > Put some CPU load on the machine, e.g. by running > > cd /usr/src > sh > while true > do > make -j4 buildworld > done >mk.log > > on one terminal and then transfer some data to the system, e.g. > by fetch(1)ing via FTP from another box connected to the same > LAN. On all systems I have, there is no need to saturate the > Gbit-Link. 100 Mbit/s local connection will trigger the problem, too. > > If the problem exists on your system, you will see emN - watchdog timeout > messages on the console and in /var/log/messages, followed by a > reset of the interface and a short and recoverable, but complete, > loss of connectivity. A couple of seconds, maybe. This is enough > to frustrate people, who e.g. run large backup jobs over a single > TCP connection that takes a couple of hours to complete - the interface > reset aborts the backup :-/ > > I must say that it seems to me, these guys are putting a hell of > a lot of effort into this problem and "we" are making progress. > Things look quite good to me for 6.2-RELEASE. > > HTH, > Patrick > -- > punkt.de GmbH Internet - Dienstleistungen - Beratung > Vorholzstr. 25Tel. 0721 9109 -0 Fax: -100 > 76137 Karlsruhe http://punkt.de > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Still have BCE driver issues (dell pe 1950) and NFS
Olivier Mueller wrote: NFS Server: dell poweredge 1950, with the 1.2.2.6 version of if_bce.c: bce0: mem 0xf400-0xf5ff irq 16 at device 0.0 on pci9 bce0: ASIC ID 0x57081010; Revision (B1); PCI-X 64-bit 133MHz miibus0: on bce0 bce0: Ethernet address: 00:13:72:f8:6f:8c bce0: link state changed to UP NFS Client: dell poweredge 1750, with : bge0: Both running an up-to-date setup of FreeBSD 6.1. Situation: - Copying GB of data via rsync or ftp: no problem - Mounting a test directory from the 1950 via NFS on the 1750 server and creating some files/directories: ok - Mounting a dir with many files via NFS (/var/tmp, 14000 php_sess): ok - Start a directory listing on it: immediate (network) crash of the NFS server. (reproduced 3 times) I don't have remote console display anymore (only power on/off), so I can only see the server going away from the network (not pingable anymore) at the moment, but it is most probably still working then. Only thing I found in /var/log/messages: Nov 6 23:09:44 gemini kernel: bce0: /usr/src/sys/dev/bce/if_bce.c(5000): Watchdog timeout occurred, resetting! Nov 6 23:09:44 gemini kernel: bce0: link state changed to DOWN Nov 6 23:09:46 gemini kernel: bce0: link state changed to UP Nov 6 23:10:49 gemini kernel: bce0: /usr/src/sys/dev/bce/if_bce.c(5000): Watchdog timeout occurred, resetting! Nov 6 23:10:49 gemini kernel: bce0: link state changed to DOWN Nov 6 23:10:51 gemini kernel: bce0: link state changed to UP What could/should I try next? The 1.18 version of if_bce.c ? (if the dell PE1950 is using the same NIC as the PE1955: cf. http://www.mail-archive.com/freebsd-stable@freebsd.org/msg83981.html ) Are there people around using a 1950 without any NIC problems? (tcp && udp). If yes, please tell me which cvs version of the driver you are using. Thanks & regards, Olivier Do the following, then retry your test: ifconfig bce0 -txcsum Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
page fault on RELENG_6_1
I'm experiencing kernel panics , and trying to understand something
(not a real kernel hacker... I'm more near 'Hello World' programmer:)
I think there is something like a null-pointer each time, in nd6_output
(crashes 2 and 3)
I'm not sure crash 4 is the same (look like
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/96413 )
Here are my dmesg, and some kgdb logs, hope I didn't forgot anything
important...
The machine (via C7) is hosting some websites, some mails, is
ipv6-enabled via gif tunnel, and use 2 openvpn instances.
Please cc my mail address.
--
___
/ Geoffroy DESVERNAY |\
/\`Service info`| Tel: (+33|0)4 91 05 45 24 /\
\/ Ecole Centrale de Marseille | Fax: (+33|0)4 91 05 45 98 \/
\ (ex-EGIM)| Mail: [EMAIL PROTECTED] /
---
Dump header from device /dev/ad4s1b
Architecture: i386
Architecture Version: 2
Dump Length: 1056505856B (1007 MB)
Blocksize: 512
Dumptime: Sun Oct 8 01:03:32 2006
Hostname: box.dgeos.net
Magic: FreeBSD Kernel Dump
Version String: FreeBSD 6.1-RELEASE-p10 #0: Wed Oct 4 09:30:30 CEST 2006
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/BOX
Panic String: page fault
Dump Parity: 103186717
Bounds: 2
Dump Status: good
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd".
Unread portion of the kernel message buffer:
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x24
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc0515778
stack pointer = 0x28:0xe338d828
frame pointer = 0x28:0xe338d848
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 12 (swi1: net)
trap number = 12
panic: page fault
Uptime: 2d22h25m31s
Dumping 1007 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 1007MB (257776 pages) 991 975 959 943 927 911 895 879 863 847 831
815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527 511
495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191
175 159 143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:165
165 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) list *0xc0515778
0xc0515778 is in propagate_priority (/usr/src/sys/kern/subr_turnstile.c:241).
236 /*
237 * Pick up the lock that td is blocked on.
238 */
239 ts = td->td_blocked;
240 MPASS(ts != NULL);
241 tc = TC_LOOKUP(ts->ts_lockobj);
242 mtx_lock_spin(&tc->tc_lock);
243
244 /* Resort td on the list if needed. */
245 if (!turnstile_adjust_thread(ts, td)) {
(kgdb) bt
#0 doadump () at pcpu.h:165
#1 0xc04edbb7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:402
#2 0xc04edef9 in panic (fmt=0xc06c92d8 "%s") at
/usr/src/sys/kern/kern_shutdown.c:558
#3 0xc06ac32c in trap_fatal (frame=0xe338d7e8, eva=0) at
/usr/src/sys/i386/i386/trap.c:836
#4 0xc06ab9c4 in trap (frame=
{tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -995882752, tf_esi =
-995882368, tf_ebp = -482813880, tf_isp = -482813932, tf_ebx = -995882752,
tf_edx = -995882368, tf_ecx = -992324084, tf_eax = 0, tf_trapno = 12, tf_err =
0, tf_eip = -1068411016, tf_cs = 32, tf_eflags = 589954, tf_esp = -995882368,
tf_ss = 40})
at /usr/src/sys/i386/i386/trap.c:269
#5 0xc0698a7a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#6 0xc0515778 in propagate_priority (td=0xc4a40a80) at
/usr/src/sys/kern/subr_turnstile.c:239
#7 0xc0515ff3 in turnstile_wait (lock=0xc4da560c, owner=0x0) at
/usr/src/sys/kern/subr_turnstile.c:634
#8 0xc04e2ba4 in _mtx_lock_sleep (m=0xc4da560c, tid=3299084544, opts=0,
file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:565
#9 0xc05cc183 in nd6_output (ifp=0xc4b1d000, origifp=0x0, m0=0xc4f1f700,
dst=0xc5185e1c, rt0=0xc4da59cc) at /usr/src/sys/netinet6/nd6.c:2004
#10 0xc05c505b in ip6_output (m0=0xe338da44, opt=0x0, ro=0xe338da44, flags=0,
im6o=0x0, ifpp=0x0, inp=0xc4f81870) at /usr/src/sys/netinet6/ip6_output.c:994
#11 0xc05a7c77 in syncache_respond (sc=0xc8f8baf0, m=0xc4f1f
Re: Still have BCE driver issues (dell pe 1950) and NFS
Le 7 nov. 06 à 01:15, Scott Long a écrit : Olivier Mueller wrote: NFS Server: dell poweredge 1950, with the 1.2.2.6 version of if_bce.c: bce0: mem - Start a directory listing on it: immediate (network) crash of the NFS server. (reproduced 3 times) Do the following, then retry your test: ifconfig bce0 -txcsum Oh, this way it looks much better, thanks. Directory listing was fine, and copying files during 2-3 minutes over NFS worked as well. More tests will follow tomorrow. Next step? :-) Should I put that command somewhere in my init scripts, or even directly in rc.conf, or wait for a new if_bce0.c version? I am available for any other PE1950-related tests if this may help. Regards, Olivier___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Still have BCE driver issues (dell pe 1950) and NFS
Olivier Mueller wrote: Le 7 nov. 06 à 01:15, Scott Long a écrit : Olivier Mueller wrote: NFS Server: dell poweredge 1950, with the 1.2.2.6 version of if_bce.c: bce0: mem - Start a directory listing on it: immediate (network) crash of the NFS server. (reproduced 3 times) Do the following, then retry your test: ifconfig bce0 -txcsum Oh, this way it looks much better, thanks. Directory listing was fine, and copying files during 2-3 minutes over NFS worked as well. More tests will follow tomorrow. Next step? :-) Should I put that command somewhere in my init scripts, or even directly in rc.conf, or wait for a new if_bce0.c version? I am available for any other PE1950-related tests if this may help. Regards, Olivier Change /sys/dev/bce/if_bcereg.h so that BCE_IF_HWASSIST is defined to 0. Then recompile. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em driver testing
Just out of curiousity - why wasn't the offending MPSAFE related changes to em just reverted after discovering the em instability? The driver -was- stable a couple of months ago, no? Adrian -- Adrian Chadd - [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Regarding Jumbo frame implementation in bge
Hi, In bge driver, we have BGE_JUMBO_FRAMELEN defined to 9018. if_bgereg.h:#define BGE_JUMBO_FRAMELEN 9018 This macro is used to allocate the memory for jumbo buffer. If I have a MTU size of 2000, still bge will allocate the jumbo buffer of size BGE_JUMBO_FRAMELEN. Instead can we make the size to be depend on the MTU. I mean instead of using BGE_JUMBO_FRAMELEN macro we can use MTU + IP header + CRC for Jumbo buffer size. Any reason for allocating a hard coded 9018 size all Jumbo MTU frame (whether it is 9000 / 2000)? Thanks, ~Siva The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em driver testing
On 11/6/06, Adrian Chadd <[EMAIL PROTECTED]> wrote: Just out of curiousity - why wasn't the offending MPSAFE related changes to em just reverted after discovering the em instability? The driver -was- stable a couple of months ago, no? Actually it was not. Some reports have cited problems back to 6.0 or before. The watchdog design was fundamentally flawed from an SMP point of view and needed to be changed. We also didnt want to go backwards if possible. My Intel driver had support for new hardware that was good to pick up. There's lots of new stuff coming too, so stay tuned :) Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
