Re: ATA errors and AUTO_EOI
Today Oliver Fromme wrote: > The comment in LINT about AUTO_EOI_2 sounds pretty suspicous, > so I never even tried it: "it works for some clones and some > integrated versions." That sounds to me like "it works on a > very limited set of hardware (and if you're lucky)." I've only got one out of over a dozen boxes where AUTO_EOI_2 will not work. Micronics, Tyan, Intel, and Brand X boards. It's one of the three Tyans that doesn't work. Only one box is running current and it works there with ata and antique drives. ata-pci0: at device 7.1 on pci0 ata-pci0: Busmastering DMA supported ata0 at 0x01f0 irq 14 on ata-pci0 ata1 at 0x0170 irq 15 on ata-pci0 ad0: ATA-0 disk at ata0 as master ad0: 515MB (1056384 sectors), 1048 cyls, 16 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 1 depth queue, PIO ad1: ATA-0 disk at ata0 as slave ad1: 1222MB (2503872 sectors), 2484 cyls, 16 heads, 63 S/T, 512 B/S ad1: 16 secs/int, 1 depth queue, PIO acd0: CDROM drive at ata1 as master acd0: read 344KB/s (689KB/s), 128KB buffer, PIO acd0: Reads: CD-DA stream acd0: Audio: play, 64 volume levels acd0: Mechanism: ejectable tray acd0: Medium: no/blank disc inside, unlocked ata_command: timeout waiting for interrupt ------ Jack O'NeillSystems Administrator / Systems Analyst [EMAIL PROTECTED] Crystal Wind Communications, Inc. Finger [EMAIL PROTECTED] for my PGP key. PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD enriched, vcard, HTML messages > /dev/null -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Feature test for OpenSSL + RSA
On Jan 17 Kris Kennaway wrote:
> > + rm -f /etc/ssl/openssl_hasrsa
>
> Doh, I meant /bin/rm
No, you meant ${RM}
------
Jack O'NeillSystems Administrator / Systems Analyst
[EMAIL PROTECTED] Crystal Wind Communications, Inc.
Finger [EMAIL PROTECTED] for my PGP key.
PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD
enriched, vcard, HTML messages > /dev/null
--
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Feature test for OpenSSL + RSA
On Jan 17 Kris Kennaway wrote:
> On Tue, 18 Jan 2000, jack wrote:
>
> > On Jan 17 Kris Kennaway wrote:
> >
> > > > + rm -f /etc/ssl/openssl_hasrsa
> > >
> > > Doh, I meant /bin/rm
> >
> > No, you meant ${RM}
>
> I couldn't find this defined in /usr/share/mk/* - it's only in
> bsd.port.mk, AFAICT.
Ummm, yeah. Sorry, I had ports on the brain since that's where
I keep getting bit by all this lately.
--
Jack O'NeillSystems Administrator / Systems Analyst
[EMAIL PROTECTED] Crystal Wind Communications, Inc.
Finger [EMAIL PROTECTED] for my PGP key.
PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD
enriched, vcard, HTML messages > /dev/null
--
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: make release weirdness?
Today Bill Swingle wrote:
> !!
> >>> You must define the value of USA_RESIDENT as 'YES' or
> >>> 'NO' as appropriate, in the environment or /etc/make.conf
> >>> before building can proceed.
> !!
> *** Error code 1
>
> Stop in /usr/src/release.
> root@deimos:/usr/src/release$ cat /etc/make.conf
> USA_RESIDENT=YES
> root@deimos:/usr/src/release$
>
>
> Shouldn;t it be pulling the USA_RESIDENT value out of /etc/make.conf?
> Am I missing something here?
It's probably looking in ${CHROOTDIR}/etc/make.conf and finding
the freshly cvs co'ed copy with that commented out. :(
--
Jack O'NeillSystems Administrator / Systems Analyst
[EMAIL PROTECTED] Crystal Wind Communications, Inc.
Finger [EMAIL PROTECTED] for my PGP key.
PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD
enriched, vcard, HTML messages > /dev/null
--
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Folks, please try to spread out your cvsups a bit better....
Today Garrett Wollman wrote: > I suspect I'm not the only mirror operator who sees a huge load spike > early in the morning: I plead guilty, your honor. When are the low load times. -- Jack O'NeillSystems Administrator / Systems Analyst [EMAIL PROTECTED] Crystal Wind Communications, Inc. Finger [EMAIL PROTECTED] for my PGP key. PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD enriched, vcard, HTML messages > /dev/null -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0RC missing libXThrStub.so.6?
Today The Hermit Hacker wrote: > Up until this afternoon, when I lost an IDE drive, I've been using CVSup'd > sources and ports, so haven't fllowed the threads too closely dealing with > 4.0RC, so this is probably already known, but ... > > I just installed two 4.0RC systems this afternoon, and both were missing > the below files: > > atelier# ls libXT* > libXThrStub.so libXThrStub.so.6 The original Xbin.tgz, dated Jan 8, did not include that file. The Xbin.tgz currently on xfree86.org, dated Jan 10, does. -- Jack O'NeillSystems Administrator / Systems Analyst [EMAIL PROTECTED] Crystal Wind Communications, Inc. Finger [EMAIL PROTECTED] for my PGP key. PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD enriched, vcard, HTML messages > /dev/null -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 will ship with NODOC=YES
On Feb 12 Jun Kuriyama wrote: > From: "Jordan K. Hubbard" <[EMAIL PROTECTED]> > ===> Generating temporary packing list > > strip /usr/local/bin/jade > > strip /usr/local/bin/nsgmls > > /usr/libexec/elf/strip: /usr/local/bin/nsgmls: No such file or directory > > *** Error code 1 > > > Stop in /usr/ports/textproc/jade. > > *** Error code 1 This isn't limited to -current. I just had something similar happen with -stable. ===> Generating temporary packing list strip /usr/local/bin/jade /usr/libexec/elf/strip: /usr/local/bin/jade: No such file or directory *** Error code 1 ------ Jack O'NeillSystems Administrator / Systems Analyst [EMAIL PROTECTED] Crystal Wind Communications, Inc. Finger [EMAIL PROTECTED] for my PGP key. PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD enriched, vcard, HTML messages > /dev/null -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 will ship with NODOC=YES
The build environment is a definite factor here. I built jade on FreeBSD 4.0-2209-CURRENT (GENERIC) with no problems. Same on a -stable box. But a -stable release, on a -stable box that build docproj-1.1 just fine in the ports tree, fell over building jade. Kuriyama's USE_GMAKE commit fixed the release build of -stable, for me. Today Jeroen Ruigrok/Asmodai wrote: > -On [2211 20:00], Jordan K. Hubbard ([EMAIL PROTECTED]) wrote: > >Unless the docs people can actually make the doc tools build > >again and successfully format the docs under -current. :) > > > >Sorry for what sounds like a threat of sorts, but I've been building > >the -current snapshots with NODOC=YES for months now because that > >aspect of release building just hasn't worked for ages, and if it's > >not fixed then I'll have little choice but to continue doing so. This > >will mean that no handbook/FAQ/etc get distributed as part of the doc > >distribution and I certainly don't see that as a good thing. JFYI! > > > >Tail end of last failure (as of this morning): > > > >===> Generating temporary packing list > >strip /usr/local/bin/jade > >strip /usr/local/bin/nsgmls > >/usr/libexec/elf/strip: /usr/local/bin/nsgmls: No such file or directory > >*** Error code 1 > > > >Stop in /usr/ports/textproc/jade. > >*** Error code 1 > > Weird, since I made sure our sp port got upgraded to the last version so > that it works with CURRENT. I am still not happy with some of the sp > patches, but what Chuck Robey committed did what my patches also did > (albeit mine were a bit cleaner ;) ). > > And anyways Jordan, I cannot remember you having notified -doc of your > problems. So you get to get a piece of the blame yourself as well. =) > > -- Jack O'NeillSystems Administrator / Systems Analyst [EMAIL PROTECTED] Crystal Wind Communications, Inc. Finger [EMAIL PROTECTED] for my PGP key. PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD enriched, vcard, HTML messages > /dev/null -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: openssl in -current
Today Kris Kennaway wrote: > > I'm also assuming that if I have openssl installed via the base system > > and USA_RESIDENT=YES in /etc/make.conf, going off to make openssh will > > cause it to build rsaref on my behalf just like it used to? I'd hate > > to have something become manual which was formerly automated. > > No, because openssl is compiled differently if rsaref is present or not - > it's not just a matter of dropping in librsaref.so (we can't always just > build the version with RSAref stubs because it references symbols in > librsaref and so binaries don't link). What will happen is that you'll get > a message pointing you to the handbook which explains how to add the > relevant openssl package. When is this message you keep talking about supposed to happen? All I got was: [snip] ===> Registering installation for rsaref-2.0 ===> Returning to build of OpenSSH-1.2.2 [snip] In file included from /usr/ports/security/openssh/work/ssh/lib/../ssh.h:21, from /usr/ports/security/openssh/work/ssh/lib/../authfd.c:19: /usr/ports/security/openssh/work/ssh/lib/../rsa.h:22: openssl/rsa.h: No such file or directory /usr/ports/security/openssh/work/ssh/lib/../authfd.c:27: openssl/rsa.h: No such file or directory >When you do this (once) you'll be able to build openssh. Is this clear now? After a make world after rsaref was installed openssh did build (and work :). -- Jack O'NeillSystems Administrator / Systems Analyst [EMAIL PROTECTED] Crystal Wind Communications, Inc. Finger [EMAIL PROTECTED] for my PGP key. PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD enriched, vcard, HTML messages > /dev/null -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patches for tosha?
Today Amancio Hasty wrote: > I think is that tosha does not know how to read audio tracks with > my Yamaha cd recorder. The Yamaha have a slightly weird > way of reading the audio tracks . I have cdda2wav as > an example on how to read audio tracks on Yamaha CDs. > The only gotcha is that is for linux so I will have to > translate the linux scsi commands to CAM. cdrecord-1.8a22 includes cdda2wav, no translation necessary. :) -- Jack O'NeillSystems Administrator / Systems Analyst [EMAIL PROTECTED] Crystal Wind Communications, Inc. Finger [EMAIL PROTECTED] for my PGP key. PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD enriched, vcard, HTML messages > /dev/null -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: QIC ft0 driver support in 4.0-CURRENT gone?
Today Mike Smith wrote: > > > > Sorry if I ask a FAQ, > > Don't be sorry, don't do it. Search the mailing list archives. It might help if HARDWARE.TXT (both -current and -stable) didn't list floppy tapes. It refers to the driver as "stale" rather than gone. -- Jack O'NeillSystems Administrator / Systems Analyst [EMAIL PROTECTED] Crystal Wind Communications, Inc. Finger [EMAIL PROTECTED] for my PGP key. PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD enriched, vcard, HTML messages > /dev/null -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: QIC ft0 driver support in 4.0-CURRENT gone?
Today Julian Elischer wrote: > hey If someone did adopt it then it wouldn't be a problem.. > if no-on edoes then it can remain 'unsupported' unsupported != tucked away in the attic, out of reach of many/most users. -- Jack O'NeillSystems Administrator / Systems Analyst [EMAIL PROTECTED] Crystal Wind Communications, Inc. Finger [EMAIL PROTECTED] for my PGP key. PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD enriched, vcard, HTML messages > /dev/null -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: QIC ft0 driver support in 4.0-CURRENT gone?
Today Jeroen Ruigrok/Asmodai wrote: > On [19991016 04:00], jack ([EMAIL PROTECTED]) wrote: > >Today Julian Elischer wrote: > > > >> hey If someone did adopt it then it wouldn't be a problem.. > >> if no-on edoes then it can remain 'unsupported' > > > >unsupported != tucked away in the attic, out of reach of > >many/most users. > > Current != platform for users. > > Anyone tracking CURRENT should know how to use Attic. Agreed, but my original statement was: It might help if HARDWARE.TXT (both -current and -stable) didn't list floppy tapes. It refers to the driver as "stale" rather than gone. The driver has been listed that way through all of the 3.x releases, which is the platform for users, and will probably still be listed the same way when 4.0 is released. -- Jack O'NeillSystems Administrator / Systems Analyst [EMAIL PROTECTED] Crystal Wind Communications, Inc. Finger [EMAIL PROTECTED] for my PGP key. PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD enriched, vcard, HTML messages > /dev/null -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ata driver and mounting CDROMs, missing tape drives
Today Bryan Liesner wrote: > I've been having trouble mounting my ATAPI CDROM using the new ATA drivers > And here are my /dev entries: > > brw-r- 1 root operator 19, 0 Oct 22 01:34 /dev/acd0a > brw-r- 1 root operator 19, 2 Oct 22 01:34 /dev/acd0c > brw-r- 1 root operator 19, 8 Oct 22 01:34 /dev/acd1a > brw-r- 1 root operator 19, 10 Oct 22 01:34 /dev/acd1c > > They look like block devices to me! They sure are but the major number has changed, it should be 31. Make sure you've got an up to date MAKEDEV and remake the devices. -- Jack O'NeillSystems Administrator / Systems Analyst [EMAIL PROTECTED] Crystal Wind Communications, Inc. Finger [EMAIL PROTECTED] for my PGP key. PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD enriched, vcard, HTML messages > /dev/null -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linksys conflicts with NE2000
Today Jonathan M. Bresler wrote: > okay i have changed the order in which we test for NE1000, NE2000, and > the Linksys (dl10016c ? ethernet controller). > > pleazse test and let me know how this patch does. > hopefully the problem will be solved. Works with my NE2000 clone. Thanks Jonathan. -- Jack O'NeillSystems Administrator / Systems Analyst [EMAIL PROTECTED] Crystal Wind Communications, Inc. Finger [EMAIL PROTECTED] for my PGP key. PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD enriched, vcard, HTML messages > /dev/null -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: syscons extension: "propellers"
Today Oliver Fromme wrote:
> I'm afraid that wouldn't work. In order to run non-trivial X11
> apps, you _will_ need a full-blown X server, including X libs.
> You'll also need at least a very simple window manager (while
> xclock would probably work without, Netscape would certainly be
> pretty unusable).
I just tried only netscape in my .xinitrc and it worked fine. As
well as "ddd ${WINDOW_MANAGER}" or "xterm" run from .xinitrc has
for me in the past.
--
Jack O'NeillSystems Administrator / Systems Analyst
[EMAIL PROTECTED] Crystal Wind Communications, Inc.
Finger [EMAIL PROTECTED] for my PGP key.
PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD
enriched, vcard, HTML messages > /dev/null
--
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall: is it really at the end of its lifecycle?
Today Mike Smith wrote: > > Given the primary mission of sysinstall is to load FreeBSD, I'd > > go so far as to say that developing an X version would be wasting > > valuable developer resources (IMHO, of course). > > It's a painful tradeoff between functionality and flash. The latter is > an unfortunate necessity if we are to avoid looking hopelessly outdated. Not arguing the point in reguard to the "unwashed masses", but when an NT[hates it]/Novell admin watched me install FreeBSD last week his opinion of sysinstall was that it was about the cleanest and most straight forward install program he's seen. Guess he, like I, is more concerned with functionality than flash. :) ------ Jack O'NeillSystems Administrator / Systems Analyst [EMAIL PROTECTED] Crystal Wind Communications, Inc. Finger [EMAIL PROTECTED] for my PGP key. PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD enriched, vcard, HTML messages > /dev/null -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: trivial rc/rc.local observation
On Sat, 16 Jan 1999, Mike Zanker wrote: > Just noticed that both rc and rc.local print "starting local daemons" and > the terminating ".". Would it not be more aesthetically pleasing if only > rc.local did so? rc.local was removed from the tree on Dec. 12th. If you're still using it you're on your own, edit it as you wish. :) -- Jack O'NeillSystems Administrator / Systems Analyst j...@germanium.xtalwind.net Crystal Wind Communications, Inc. Finger j...@germanium.xtalwind.net for my PGP key. PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD enriched, vcard, HTML messages > /dev/null -- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Annoying messages on startup..
On Sat, 16 Jan 1999, Jordan K. Hubbard wrote: > j...@zippy-> dmesg|grep Freeing > Freeing (NOT implemented) redirected ISA irq 11. > Freeing (NOT implemented) redirected ISA irq 10. Nowhere near as annoying as "tagged openings now xx". Perhaps `|| 1' could be changed to `|| crs->openings < some critical number' in cam_xpt.c. As it is now a boy and a wolf come to mind. Also, I suspect having acd in the kernel and wcd in MAKEDEV may lead to confusion for some people. -- Jack O'NeillSystems Administrator / Systems Analyst j...@germanium.xtalwind.net Crystal Wind Communications, Inc. Finger j...@germanium.xtalwind.net for my PGP key. PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD enriched, vcard, HTML messages > /dev/null -- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Annoying messages on startup..
On Sun, 17 Jan 1999, Jordan K. Hubbard wrote:
> > Nowhere near as annoying as "tagged openings now xx".
>
> I don't like this error much either (especially since it generates
> tech support questions on USENET and other places from users going
> "Aieee! What does this mean?!") but I was overruled on the issue by
> arguments that it was still providing useful information about drives
> that didn't really handle multiple tags as well as their spec sheets
> claimed.
I never saw less than 62 with Seagates and IBMs on three
different boxes. Now I just change
if (bootverbose || 1) {
to
if (bootverbose || crs->openings < 50) {
everytime cam_xpt.c gets updated and I don't see it at all. If I
do I know Something Bad is happening.
Since bootverbose will turn it on for those folks who need it
what's the point in spamming everyone's consoles? Just 'cause
it's flu season is no reason for _everyone_ to constantly use a
rectal thermometer.
--
Jack O'NeillSystems Administrator / Systems Analyst
j...@germanium.xtalwind.net Crystal Wind Communications, Inc.
Finger j...@germanium.xtalwind.net for my PGP key.
PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD
enriched, vcard, HTML messages > /dev/null
--
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: Heavy on the Verbosity (was) Re: Annoying messages on startup..
On Sun, 17 Jan 1999, Chris Tubutis wrote: > > Coming from someone who's spent the best part of last week trying to > > diagnose > > various hardware & software problems on NT & Win'95 machines (to almost no > > avail), I'd appreciate as much verbosity being left _in_ the kernel & > > FreeBSD > > as possible... I'm fed up with seeing "Unknown error", or "Unknown errors > > occured" or "Service Failed" and the like on competitor / other products... > > Make them only 'if verbose' if you need to - just don't lose them > > alltogether!... :) > > This is a very good point, something that I strongly agree with. As hard > as I try not to, I find myself having to deal with products from Redmond > while at work. Yeah, stuff like "Error connecting to database" tells me > absolutely nothing and is frustrating as all Hell. I think most of us have been there as some point and I totally agree. It's just that in this case we're getting more than we want at those times when we don't need it. > Maybe a way to toggle the verbosity to suit individual > preferences would be a good way to go? It is keyed to bootverbose, but `or'ed with 1. Perhaps a sysctl(8) knob, kern.verbosity, is worth thinking about. -- Jack O'NeillSystems Administrator / Systems Analyst j...@germanium.xtalwind.net Crystal Wind Communications, Inc. Finger j...@germanium.xtalwind.net for my PGP key. PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD enriched, vcard, HTML messages > /dev/null -- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
On Tue, 9 Feb 1999, Matthew Dillon wrote: > I think it's a *BAD* idea to change rc.conf operation for the 3.1 > distribution. Bad Bad Bad. I have to agree. Let's not forget that there are over 30 man pages with references to /etc/rc.conf. There is already enough confusion over wcd in /dev with everything else refering to it as acd, and no documentation about when to just ignore "tagged openings now ". Both of these issues are already popping up in questions and the news groups. -- Jack O'NeillSystems Administrator / Systems Analyst j...@germanium.xtalwind.net Crystal Wind Communications, Inc. Finger j...@germanium.xtalwind.net for my PGP key. PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD enriched, vcard, HTML messages > /dev/null -- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
On Tue, 9 Feb 1999, John Fieber wrote: > Lets not forget that with the latest round of changes, the > rc.conf in 3.1 will behave exactly as it has in the past. Think > about it. rc.conf was a "touchees" file in the past and it is a > "touchees" file now. The only difference is the addition of a > "no touchees" reference copy in /etc/defaults that gets sourced > before rc.conf so any essential variables introduced in an > upgrade will have a safety fallaback in case you don't properly > upgrade your rc.conf. If /etc/rc.conf only contains changes from the defaults when man something_or_other tells the user to find and edit something_or_other_flags in /etc/rc.conf the entry won't be there to edit. ------ Jack O'NeillSystems Administrator / Systems Analyst j...@germanium.xtalwind.net Crystal Wind Communications, Inc. Finger j...@germanium.xtalwind.net for my PGP key. PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD enriched, vcard, HTML messages > /dev/null -- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
On Wed, 10 Feb 1999, Sheldon Hearn wrote: > On Tue, 09 Feb 1999 20:42:40 CST, Richard Wackerbarth wrote: > > > But, I would not expect/allow "defaults" to be the mechanism > > which includes the "real" values. > > Neither would I, but only because this hasn't been made clear in such > a way that guys like you and me "get it". I reckon that a comment in > /etc/rc.conf explaining that it's a set of values used to _override_ > those in /etc/defaults/rc.conf ought to do the trick, eh? That would probably work. I'm not really oppposed to this concept I'd just like to see it documented in the distribution so that the lists aren't over run with questions when it hits the street and those who haven't been `heads uped' by the lists are in a state of confusion. -- Jack O'NeillSystems Administrator / Systems Analyst j...@germanium.xtalwind.net Crystal Wind Communications, Inc. Finger j...@germanium.xtalwind.net for my PGP key. PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD enriched, vcard, HTML messages > /dev/null -- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall & rc.conf
Today Matthew D. Fuller wrote: > I just installed a 4.0-SNAP on my laptop (replacing the old 2.2.7 > installation), and I must say once I stopped doing stupid things the > install went nicely. But I noticed after I rebooted that > 'myname.my.domain' didn't write out any of the config information to > rc.conf (which, of course, doesn't exist). Is this > known/planned/expected? This is the 02/12 SNAP. I think it's a feature. RELENG_3, as of this morning, does the same thing for a new install, except that the file exists but is empty except for the "...just the overrides..." header. For an `upgrade' install it copies _all_ of the old rc.conf values into the new one, advertising them as just the overrides. -- Jack O'NeillSystems Administrator / Systems Analyst j...@germanium.xtalwind.net Crystal Wind Communications, Inc. Finger j...@germanium.xtalwind.net for my PGP key. PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD enriched, vcard, HTML messages > /dev/null -- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall & rc.conf
Today Jordan K. Hubbard wrote: > Erm. Neither of these behaviors are intended, if that's what's going > on. Like I said, I'm waiting for my own release build to finish right > now and will happily fix this if I can reproduce it. It should write > only the customized variables in either the install or upgrade case. I'll watch for commit messages. I've got 3 pre-/etc/default 3.x boxen I can upgrade and two junk drives where I can test fresh installs. -- Jack O'NeillSystems Administrator / Systems Analyst j...@germanium.xtalwind.net Crystal Wind Communications, Inc. Finger j...@germanium.xtalwind.net for my PGP key. PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD enriched, vcard, HTML messages > /dev/null -- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Is ppb a device or controller?
$Id: LINT,v 1.555 1999/02/14 12:00:00 nsouch Exp $ controller ppc0at isa? port? tty irq 7 $Id: GENERIC,v 1.149 1999/02/14 12:00:00 nsouch Exp $ device ppc0at isa? port? tty irq 7 Are the lables device and controller interchangeable? -- Jack O'NeillSystems Administrator / Systems Analyst j...@germanium.xtalwind.net Crystal Wind Communications, Inc. Finger j...@germanium.xtalwind.net for my PGP key. PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD enriched, vcard, HTML messages > /dev/null -- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: 4.0-RELEASE boot.flp fails to boot on K6/2
Today Warner Losh wrote: > boot.flp288 The M$ weenies would probably choke on that since they do filenames other than 8.3 with smoke and mirrors. -- Jack O'NeillSystems Administrator / Systems Analyst [EMAIL PROTECTED] Crystal Wind Communications, Inc. Finger [EMAIL PROTECTED] for my PGP key. PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD enriched, vcard, HTML messages > /dev/null -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make installworld runs out of space on / ...
On May 12 The Hermit Hacker wrote: > My / directory, right now, has 12Meg free on it ... if I do a make > installworld, it will fail due to no space left on device ... > > Filesystem 1K-blocks UsedAvail Capacity iused ifree %iused Mounted on > /dev/da1s1a 63503460151240879%1858 1401212% / > > Has anyone run into this one? Yes, with softupdates enabled on / > Is there a way of fixing it? tunefs -n disable / worked for me. ------ Jack O'NeillSystems Administrator / Systems Analyst [EMAIL PROTECTED] Crystal Wind Communications, Inc. Finger [EMAIL PROTECTED] for my PGP key. PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD enriched, vcard, HTML messages > /dev/null -- A Microsoft Certified Systems Engineer is to computing what a McDonalds Certified Food Specialist is to fine cuisine. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RFC: use EM_LEGACY_IRQ in if_lem.c ?
Interesting, lem is all the non-pcie hardware, and if you see better
performance
out of the LEGACY path then I'm OK with changing the default.
Jack
On Tue, Jul 24, 2012 at 1:20 PM, Luigi Rizzo wrote:
> if_lem.c ("lem", one of the e1000 drivers) has 2 possible interrupt modes:
> EM_LEGACY_IRQ uses the standard dispatch mechanism, whereas
> FAST_INTR has a custom handler that signals a taskqueue to do the job.
>
> I have no idea which actual hardware uses it (all of my Intel 1G
> cards use either "em" or "igb"), but "lem" is the driver used in
> qemu, and there the EM_LEGACY_IRQ gives approx 10% higher packet
> rates than the other.
>
> Any objections if i change the default to EM_LEGACY_IRQ ?
>
> cheers
> luigi
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [net] protecting interfaces from races between control and data ?
Sigh, this ends up being ugly I'm afraid. I need some time to look at code and think about it. Jack On Mon, Aug 5, 2013 at 10:36 AM, Luigi Rizzo wrote: > On Mon, Aug 5, 2013 at 7:17 PM, Adrian Chadd wrote: > > > I'm travelling back to San Jose today; poke me tomorrow and I'll brain > > dump what I did in ath(4) and the lessons learnt. > > > > The TL;DR version - you don't want to grab an extra lock in the > > read/write paths as that slows things down. Reuse the same per-queue > > TX/RX lock and have: > > > > * a reset flag that is set when something is resetting; that says to > > the queue "don't bother processing anything, just dive out"; > > * 'i am doing Tx / Rx' flags per queue that is set at the start of > > TX/RX servicing and finishes at the end; that way the reset code knows > > if there's something pending; > > * have the reset path grab each lock, set the 'reset' flag on each, > > then walk each queue again and make sure they're all marked as 'not > > doing TX/RX'. At that point the reset can occur, then the flag cna be > > cleared, then TX/RX can resume. > > > > so this is slightly different from what Bryan suggested (and you endorsed) > before, as in that case there was a single 'reset' flag IFF_DRV_RUNNING > protected by the 'core' lock, then a nested round on all tx and rx locks > to make sure that all customers have seen it. > In both cases the tx and rx paths only need the per-queue lock. > > As i see it, having a per-queue reset flag removes the need for nesting > core + queue locks, but since this is only in the control path perhaps > it is not a big deal (and is better to have a single place to look at to > tell whether or not we should bail out). > > cheers > luigi > ___ > freebsd-...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [net] protecting interfaces from races between control and data ?
What do you think about this change? Cheers, Jack On Mon, Aug 5, 2013 at 10:58 AM, Luigi Rizzo wrote: > On Mon, Aug 5, 2013 at 7:49 PM, Jack Vogel wrote: > >> Sigh, this ends up being ugly I'm afraid. I need some time to look at >> code and think about it. >> >> > actually the intel drivers seem in decent shape, > especially if we reuse IFF_DRV_RUNNING as the reset flag > and the core+queue lock in the control path. > > cheers > luigi > > > >> Jack >> >> >> >> On Mon, Aug 5, 2013 at 10:36 AM, Luigi Rizzo wrote: >> >>> On Mon, Aug 5, 2013 at 7:17 PM, Adrian Chadd wrote: >>> >>> > I'm travelling back to San Jose today; poke me tomorrow and I'll brain >>> > dump what I did in ath(4) and the lessons learnt. >>> > >>> > The TL;DR version - you don't want to grab an extra lock in the >>> > read/write paths as that slows things down. Reuse the same per-queue >>> > TX/RX lock and have: >>> > >>> > * a reset flag that is set when something is resetting; that says to >>> > the queue "don't bother processing anything, just dive out"; >>> > * 'i am doing Tx / Rx' flags per queue that is set at the start of >>> > TX/RX servicing and finishes at the end; that way the reset code knows >>> > if there's something pending; >>> > * have the reset path grab each lock, set the 'reset' flag on each, >>> > then walk each queue again and make sure they're all marked as 'not >>> > doing TX/RX'. At that point the reset can occur, then the flag cna be >>> > cleared, then TX/RX can resume. >>> > >>> >>> so this is slightly different from what Bryan suggested (and you >>> endorsed) >>> before, as in that case there was a single 'reset' flag IFF_DRV_RUNNING >>> protected by the 'core' lock, then a nested round on all tx and rx locks >>> to make sure that all customers have seen it. >>> In both cases the tx and rx paths only need the per-queue lock. >>> >>> As i see it, having a per-queue reset flag removes the need for nesting >>> core + queue locks, but since this is only in the control path perhaps >>> it is not a big deal (and is better to have a single place to look at to >>> tell whether or not we should bail out). >>> >>> cheers >>> luigi >>> >>> ___ >>> freebsd-...@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" >>> >> >> > > > -- > -+--- > Prof. Luigi RIZZO, ri...@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/. Universita` di Pisa > TEL +39-050-2211611 . via Diotisalvi 2 > Mobile +39-338-6809875 . 56122 PISA (Italy) > -+--- > quiesce.diff Description: Binary data ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ixgbe(4) and SFP+ (un)supported module
Look again closely, AFBR-703SDZ-IN2 and AFBR-703SDDZ-IN1 are supported,
AFBR-703SDZ-IN is not.
Jack
On Tue, Dec 4, 2012 at 3:47 AM, Ian FREISLICH wrote:
> Hi
>
> I've just had this card installed in our servers:
>
> ix0@pci0:12:0:0:class=0x02 card=0x7a118086 chip=0x10fb8086
> rev=0x01
> hdr=0x00
> vendor = 'Intel Corporation'
> device = '82599EB 10-Gigabit SFI/SFP+ Network Connection'
> class = network
> subclass = ethernet
> cap 01[40] = powerspec 3 supports D0 D3 current D0
> cap 05[50] = MSI supports 1 message, 64 bit, vector masks
> cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled
> cap 10[a0] = PCI-Express 2 endpoint max data 512(512) FLR link x8(x8)
> speed 2.5(5.0)
> cap 03[e0] = VPD
> ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected
> ecap 0003[140] = Serial 1 90e2ba2b92e8
> ecap 000e[150] = ARI 1
> ecap 0010[160] = SRIOV 1
>
> Which yielded the following error initializing the driver:
>
> ix0: port
> 0xbcc
> ix0: Using MSIX interrupts with 9 vectors
> ix0: Unsupported SFP+ Module
> device_attach: ix0 attach returned 5
> ix0: port
> 0xbce
> ix0: Using MSIX interrupts with 9 vectors
> ix0: Unsupported SFP+ Module
> device_attach: ix0 attach returned 5
> ix0: port
> 0xbcc
> ix0: Using MSIX interrupts with 9 vectors
> ix0: Unsupported SFP+ Module
> device_attach: ix0 attach returned 5
> ix0: port
> 0xbce
> ix0: Using MSIX interrupts with 9 vectors
> ix0: Unsupported SFP+ Module
> device_attach: ix0 attach returned 5
>
> The README in /usr/src/sys/dev/ixgbe claims that the module we have,
> AFBR-703SDZ-IN is supported. I had to make the following change
> to get the driver to attach. I get the feeling it's not the
> correct fix however:
>
> [firewall2.jnb1] /usr/src/sys/dev/ixgbe # svn diff
> Index: ixgbe_phy.c
> ===
> --- ixgbe_phy.c (revision 243808)
> +++ ixgbe_phy.c (working copy)
> @@ -955,7 +955,7 @@
> u8 oui_bytes[3] = {0, 0, 0};
> u8 cable_tech = 0;
> u8 cable_spec = 0;
> - u16 enforce_sfp = 0;
> + u16 enforce_sfp = 1;
>
> DEBUGFUNC("ixgbe_identify_sfp_module_generic");
>
> Ian
>
> --
> Ian Freislich
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] proposed 'lem' patch to improve behaviour under emulation
LOL, it's ironic, my intention in creating lem was to isolate the old pre-PCIE driver from active changes so as to assure it's stability... but virtualization comes around to bit me in the butt :) I guess I'm agreeable in principle with what you're doing Luigi, but can you do me a favor and hold off until I'm technically back from vacation (after the new year) and let me review the code then? Thanks, Jack On Thu, Dec 27, 2012 at 1:46 AM, Luigi Rizzo wrote: > This patch implements two features for the 'lem' driver that > greatly improve the throughput under proper hypervisor. > This is joint work with Vincenzo Maffione and Giuseppe Lettieri, > I am posting it here for review, will then commit it > if there are no objections. > > The first change is to implement a sysctl to access the 'itr' > interrupt moderation register for the devices supported by this > driver. It is little more than adding a struct into the device > descriptor, and one line to create the dynamic sysctl entry, same > as it is done for the other mitigation registers. > > The second change is more interesting and has huge benefits on througput. > > Under virtualization, "VM exits" (which happen every time there is > an access to a register of the emulated peripheral) are extremely > expensive. In the tx path of the 'lem' driver, there is a write > to the TDT register on every packet sent. > > The patch we propose, if enabled through a sysctl (defaults off, > so no change from current behaviour) defers writes to the TDT > register when there is a pending transmit interrupt. > This means that, together with proper emulation of interrupt > mitigation on the hypervisor side, the number of VM exits > is dramatically reduced. To give you an idea, on a modern > system with qemu-kvm and companion patches, UDP throughput is > > KVM QEMU > standard KVM, standard driver20 Kpps 6.3 Kpps > modified KVM, standard driver37 Kpps28 Kpps > modified KVM, modified driver 200 Kpps34 Kpps > > As you can see, on kvm this change gives a 5x speedup to the tx path, > which combines nicely with the 2x speedup that comes from supporting > interrupt mitigation alone in the hypervisor. Without kvm (or kqemu ?) > the benefits are much lower, as the guest becomes too slow. > > Patch follows. It would be good if people with real hardware > using the 'lem' driver could test it to make sure it does no > harm on their devices (in any case the sysctl variable > dev.em.0.mit_enable must be set to explicitly enable it > at runtime). > > (for those curious to test it under kvm, i am also attaching a > patch that you need to apply to qemu in order to exploit the > effect of interrupt mitigation; it is a followup of a similar > patch i posted in july to the qemu mailing list, and i will > post it the update there as well, shortly. Unfortunately > we do not have kvm on freebsd..) > > cheers > luigi > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] proposed 'lem' patch to improve behaviour under emulation
I don't know, in some ways it might be more interesting to make something just for a virtualized device, however reality is that I have way too many higher priority items to worry about after the new year gets underway than that, even so, we can see... Jack On Thu, Dec 27, 2012 at 6:52 PM, Luigi Rizzo wrote: > On Thu, Dec 27, 2012 at 10:46 AM, Jack Vogel wrote: > >> LOL, it's ironic, my intention in creating lem was to isolate the old >> pre-PCIE driver from active changes so as to assure it's stability... >> but virtualization comes around to bit me in the butt :) >> >> I guess I'm agreeable in principle with what you're doing Luigi, but >> can you do me a favor and hold off until I'm technically back from >> vacation (after the new year) and let me review the code then? >> >> > sure, no rush -- i just wanted to have it out for review as it has been > ready for a few weeks now. > > Regarding lem vs em i actually wonder if it wouldn't be better to > consolidate the two drivers given the amount of common code. > While i understand the desire for stability, i actually wonder if there > is much if any leftover hw which uses 'lem' ... outside virtualization! > > cheers > luigi > > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Intel 82574 issue reported on Slashdot
For those that may have run across the story on Slashdot about this NIC, here is our statement: Recently there were a few stories published, based on a blog post by an end-user, suggesting specific network packets may cause the Intel® 82574L Gigabit Ethernet Controller to become unresponsive until corrected by a full platform power cycle. Intel was made aware of this issue in September 2012 by the blogs author. Intel worked with the author as well as the original motherboard manufacturer to investigate and determine root cause. Intel root caused the issue to the specific vendor’s mother board design where an incorrect EEPROM image was programmed during manufacturing. We communicated the findings and recommended corrections to the motherboard manufacturer. It is Intel’s belief that this is an implementation issue isolated to a specific manufacturer, not a design problem with the Intel 82574L Gigabit Ethernet controller. Intel has not observed this issue with any implementations which follow Intel’s published design guidelines. Intel recommends contacting your motherboard manufacturer if you have continued concerns or questions whether your products are impacted. Here is the link: http://communities.intel.com/community/wired/blog/2013/02/07/intel-82574l-gigabit-ethernet-controller-statement Any questions or concerns may be sent to me. Cheers, Jack ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD & Intel AMT
I need to know the details on the hardware this is on, and was it working on some previous version of FreeBSD and broke in STABLE or what? Jack On Mon, May 13, 2013 at 2:44 PM, Kamil Czekirda wrote: > Jack, do you have any ideas to resolve problem, on new Debian 7 and Ubuntu > 13.10 AMT working fine. > > > 2013/5/9 John Baldwin > >> On Thursday, May 09, 2013 4:34:16 am Kamil Czekirda wrote: >> > Do you have any ideas to resolve the problem? >> >> I have no idea what part of e1000 common code deals with AMT/IPMI and >> what you >> might need to do to make this work. I was hoping Jack would be be able to >> respond here. >> >> > 2013/4/29 John Baldwin >> > >> > > On Friday, April 26, 2013 5:17:34 pm Kamil Czekirda wrote: >> > > > We have a problem with Intel AMT and FreeBSD. We have AMT version: >> > > > 8.1.20-build 1336. AMT stop responding about five minutes after >> booting >> > > > FreeBSD, it's FreeBSD 9.1-STABLE, 64 bit. >> > > > On Linux AMT works fine. We suspect driver, but it's similar like on >> > > Linux. >> > > > Can you show us the way to resolve this problem? >> > > >> > > While the e1000 drivers share the same common code, there are some >> > > differences >> > > in the OS-dependent bits (e.g. if_igb.c, etc.). I've cc'd Jack Vogel >> who >> > > maintains the e1000 drivers in FreeBSD. >> > > >> > > -- >> > > John Baldwin >> > > >> > >> >> -- >> John Baldwin >> > > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Typo in PCI-E Bus Speed measure unit
No, you do not need to commit this, the next drop of my internal code already has this in it, and should be coming shortly, but thanks anyway. Jack On Sat, May 25, 2013 at 4:44 AM, Sergey Kandaurov wrote: > Hi. > > I'd like to commit this patch. > PCI-E Bus Speed is measured in GT/s (transfers per sec). > > Index: sys/dev/ixgbe/ixgbe.c > === > --- sys/dev/ixgbe/ixgbe.c (revision 250717) > +++ sys/dev/ixgbe/ixgbe.c (working copy) > @@ -579,8 +579,8 @@ > /* Print PCIE bus type/speed/width info */ > ixgbe_get_bus_info(hw); > device_printf(dev,"PCI Express Bus: Speed %s %s\n", > - ((hw->bus.speed == ixgbe_bus_speed_5000) ? "5.0Gb/s": > - (hw->bus.speed == ixgbe_bus_speed_2500) ? "2.5Gb/s":"Unknown"), > + ((hw->bus.speed == ixgbe_bus_speed_5000) ? "5.0GT/s": > + (hw->bus.speed == ixgbe_bus_speed_2500) ? "2.5GT/s":"Unknown"), > (hw->bus.width == ixgbe_bus_width_pcie_x8) ? "Width x8" : > (hw->bus.width == ixgbe_bus_width_pcie_x4) ? "Width x4" : > (hw->bus.width == ixgbe_bus_width_pcie_x1) ? "Width x1" : > > -- > wbr, > pluknet > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: problems with em(4) since update to driver 7.2.2
This problem happens for only one reason, you have insufficient mbufs to fill your rx ring. Its odd that it would differ when its static versus a loadable module though! With the 7.2.2 driver you also will use different mbuf pools depending on the MTU you are using. If you use jumbo frames it will use 4K clusters, if you go to 9K jumbos it will use 9K mbuf clusters. The number of these allocated by default is small (like 6400 small :). I would use 'netstat -m' to see what the pools look like. Now that I think about it, the reason it might fail as loaded while not as built in is you get allocation of the mbufs first when static, and something else is taking them before you can load when loadable?? I suspect all will be fine if you increase the pool size that you are using. Jack On Thu, Mar 31, 2011 at 8:52 AM, Mike Tancsa wrote: > On 3/31/2011 11:20 AM, Olivier Smedts wrote: > > Hello, > > > > I've got a problem under FreeBSD 9.0-CURRENT amd64 with the em driver. > > It's loaded as a module. I was previously using r219710 (2011-03-17) > > without any problem, but with latest HEAD I can't even send a ping. > > Here's what appears in dmesg. I tried unloading / loading the module, > > did not help. At the end I loaded my old if_em.ko and it worked : > > I ran into a similar problem with specific types of em NICs. For some > reason, if it was compiled into the kernel it worked. As a module doing > a netboot, it would fail. Does it work for you if the driver is > statically compiled into the kernel by chance ? > >---Mike > > -- > --- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, m...@sentex.net > Providing Internet services since 1994 www.sentex.net > Cambridge, Ontario Canada http://www.tancsa.com/ > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: problems with em(4) since update to driver 7.2.2
If you get "cannot setup receive structures" you cannot go on and try to use the thing :) It means you have inadequate mbuf clusters to setup your receive side, you simply have to increase it and reload the driver. Jack On Wed, Apr 27, 2011 at 5:39 AM, Olivier Smedts wrote: > 2011/3/31 Jack Vogel : > > This problem happens for only one reason, you have insufficient mbufs to > > fill your rx ring. Its odd that it would differ when its static versus a > > loadable > > module though! > > > > With the 7.2.2 driver you also will use different mbuf pools depending on > > the MTU you are using. If you use jumbo frames it will use 4K clusters, > > if you go to 9K jumbos it will use 9K mbuf clusters. The number of these > > allocated by default is small (like 6400 small :). > > > > I would use 'netstat -m' to see what the pools look like. Now that I > think > > about it, the reason it might fail as loaded while not as built in is you > > get > > allocation of the mbufs first when static, and something else is taking > them > > before you can load when loadable?? > > Sorry to be quite late on this, > > Here is what gives me netstat -m with my new 9-CURRENT kernel but with > old (working, after some time of computer use) if_em.ko : > 1027/3458/4485 mbufs in use (current/cache/total) > 1024/2066/3090/25600 mbuf clusters in use (current/cache/total/max) > 1024/1792 mbuf+clusters out of packet secondary zone in use (current/cache) > 0/367/367/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) > 2304K/6464K/8769K 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 > > And here is the output with the new (non-working) if_em.ko : > 1029/3456/4485 mbufs in use (current/cache/total) > 1023/2067/3090/25600 mbuf clusters in use (current/cache/total/max) > 1023/1793 mbuf+clusters out of packet secondary zone in use (current/cache) > 0/367/367/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) > 2303K/6466K/8769K 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 > > I've got the "em0: Could not setup receive structures" messages with > the new if_em.ko even in single user mode. No network connectivity. I > tried removing all other network-related modules (vboxnet, ipfw...) > and still have this problem (again, even when booting in single-user > mode). > My network card is "em0@pci0:0:25:0:class=0x02 > card=0x304b103c chip=0x10ef8086 rev=0x05 hdr=0x00". I'm using a > stripped-down GENERIC amd64 kernel (no network, no scsi, no raid...), > a nearly empty sysctl.conf and loader.conf (except module loading). > > I saw at the time of the commit that an MFC to 8-STABLE was planned, > but I don't think it should happen so soon. Given that my network > adapter was previously working well before the em driver update, can't > this be considerd a serious regression ? > > Thanks, > Olivier > > -- > Olivier Smedts _ > ASCII ribbon campaign ( ) > e-mail: oliv...@gid0.org- against HTML email & vCards X > www: http://www.gid0.org- against proprietary attachments / \ > > "Il y a seulement 10 sortes de gens dans le monde : > ceux qui comprennent le binaire, > et ceux qui ne le comprennent pas." > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: problems with em(4) since update to driver 7.2.2
Yes Mike, already have had a couple others bug me to get the MFC, I'm hoping to get it in this week :) Jack On Wed, Apr 27, 2011 at 12:04 PM, Mike Tancsa wrote: > On 4/27/2011 2:45 PM, Olivier Smedts wrote: > >> Are you testing with what is in HEAD ? ie. 7.2.3 or something else ? > >> Your subject line implies something else. > > > > I'm using what's in HEAD since r219753, the commit which updated the > > em driver from version 7.1.9 to 7.2.2 and broke it at least for me. > > Oh, ok. Thats from back in March. There is a newer one 7.2.3 in April. > I would test with that perhaps. I am using a back ported version on > RELENG8 and it works quite well for me. > > http://lists.freebsd.org/pipermail/svn-src-head/2011-April/026202.html > > > Hopefully MFC'd soon ? > > >---Mike > > > > -- > --- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, m...@sentex.net > Providing Internet services since 1994 www.sentex.net > Cambridge, Ontario Canada http://www.tancsa.com/ > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: problems with em(4) since update to driver 7.2.2
If you get the setup receive structures fail, then increase the nmbclusters. If you use standard MTU then what you need are mbufs, and standard size clusters (2K). Only when you use jumbo frames will you need larger. You must configure enough, its that simple. Jack On Tue, May 3, 2011 at 2:13 PM, Michael Schmiedgen wrote: > Hi, > > I have the very same problem. > > - GENERIC 9.0-CURRENT (April 28) > - em0 PRO/1000 7.2.3 > > - "em0: Could not setup receive structures" > > On 03.05.2011 10:58, Olivier Smedts wrote: > >> I tried increasing kern.ipc.nmbjumbo* (is it what you suggested ?). >> Values doubled : >> kern.ipc.nmbjumbo16: 6400 >> kern.ipc.nmbjumbo9: 12800 >> kern.ipc.nmbjumbop: 25600 >> >> And unloaded / reloaded the kernel module. Still no luck, same >> problem, on latest 9-CURRENT (r221363). >> > > Same here. > > If I should provide some more configuration settings, > please let me know. > > Michael > > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: problems with em(4) since update to driver 7.2.2
It has nothing to do with load, it has to do with the prerequisites to init your interfaces. The amount you need is fixed, it doesn't vary with load. Every RX descriptor needs one, so its simple math, number-of-interfaces X number-of-queues X size of the ring. If you have other network interfaces beside Intel they also consume mbufs remember. Jack On Tue, May 3, 2011 at 2:50 PM, Michael Schmiedgen wrote: > On 03.05.2011 23:24, Jack Vogel wrote: > >> If you get the setup receive structures fail, then increase the >> nmbclusters. >> >> If you use standard MTU then what you need are mbufs, and standard size >> clusters (2K). >> Only when you use jumbo frames will you need larger. >> >> You must configure enough, its that simple. >> > > I doubled the nmbclusters as well. But nothing happened. > > I have no load on this machine and nothing special > configured. > > Thanks, > Michael > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: problems with em(4) since update to driver 7.2.2
No, I do not Arnaud. But I refuse to rise to rude and uncivil behavior. Its your behavior again and again which causes you to not get responses, not my willingness to help and respond to those that behave like respectful customers and adults. Jack On Wed, May 4, 2011 at 10:20 AM, Arnaud Lacombe wrote: > Hi, > > On Tue, May 3, 2011 at 7:25 PM, Olivier Smedts wrote: > > 2011/5/4 Arnaud Lacombe : > >> A more rude version might be "Why the frak my network adapter stopped > >> working with the default setting ?" :) > > > > ...on a -STABLE branch > > > Maybe you should not have picked the rude version, Jack has a > relatively low cut-off frequency :-) > > - Arnaud > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Interrupt storm with MSI in combination with em1
Who makes your motherboard? The problem you are having is that MSIX AND MSI are both failing as em0 comes up, so it falls back to Legacy interrupt mode, and must be having some issue with sharing the line, causing the storm. This is the second report in a matter of a week perhaps about a problematic motherboard, I would like to know who makes them. Thanks, Jack On Wed, May 4, 2011 at 8:34 AM, Daan Vreeken wrote: > Hi All, > > I've just updated a machine to -current (r221321) and since then I'm seeing > an > interrupt storm on irq 16. The storm goes away when I disable MSI/MSIX with > the following lines in "loader.conf" : > >hw.pci.enable_msix="0" >hw.pci.enable_msi="0" > > According to "dmesg" the following devices share IRQ 16 : > >pcib1: irq 16 at device 1.0 on pci0 >em0: port 0xcc00-0xcc1f > mem > 0xf7de-0xf7df,0xf7d0-0xf7d7,0xf7ddc000-0xf7dd > irq 16 at device 0.0 on pci1 >vgapci0: port 0xbc00-0xbc07 > mem 0xf780-0xf7bf,0xe000-0xefff irq 16 at device > 2.0 on > pci0 >ehci0: mem > 0xf7cfa000-0xf7cfa3ff > irq 16 at device 26.0 on pci0 >em1: port 0xec00-0xec1f > mem > 0xf7fe-0xf7ff,0xf7f0-0xf7f7,0xf7fdc000-0xf7fd > irq 16 at device 0.0 on pci4 >pcib4: irq 16 at device 28.5 on pci0 > > During a storm "vmstat -i" shows a rate of about 220.000 interrupts/sec. > MSI > interrupt delivery to both 'em0' and 'em1' seems to work correctly during a > storm, as I see their counters increase normally in the "vmstat -i" output. > > As only 'em0' and 'em1' seem to be using MSI interrupts, my guess is that > the > e1000 driver is causing this problem. Could it be that the driver forgets > to > clear/mask legacy interrupts when attaching the MSI interrupts perhaps? > > Any tips on how to debug and/or fix this? > > > The full output of "dmesg" can be found here : >http://vehosting.nl/pub_diffs/dmesg_plantje2_2011_05_04.txt > > And the full output of "pciconf -lv" is here : >http://vehosting.nl/pub_diffs/pciconf_plantje2_2011_05_04.txt > > > Regards, > -- > Daan Vreeken > VEHosting > http://VEHosting.nl > tel: +31-(0)40-7113050 / +31-(0)6-46210825 > KvK nr: 17174380 > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Interrupt storm with MSI in combination with em1
Will you please set it back to a default and then boot and capture the message for me? Thank you, Jack On Wed, May 4, 2011 at 11:19 AM, Daan Vreeken wrote: > Hi Jack, > > Wednesday 04 May 2011 19:46:05 Jack Vogel wrote: > > Who makes your motherboard? The problem you are having is that MSIX AND > > MSI are both failing as em0 comes up, so it falls back to Legacy > interrupt > > mode, > > and must be having some issue with sharing the line, causing the storm. > > The motherboard is an Asus "P7H55-M". > Sorry, I should have mentioned that the dmesg output is from booting with : > > > >hw.pci.enable_msix="0" > > >hw.pci.enable_msi="0" > > .. in "loader.conf". > > With those lines in "loader.conf", MSI and MSIX is disabled, both cards > work > like they should and there is no interrupt storm. > > With MSI/MSIX enabled, both cards work like they should and I see the > counters > of the MSI interrupts increase (in small amounts, like they should), but at > boot-time an interrupt storm starts on 'legacy' IRQ 16. > > Because the only difference between disabling/enabling MSI/MSIX seems to be > in > the way em0/em1 are used, and because 'em1' shares IRQ 16 according to the > dmesg, I'm suspecting 'em1' is causing the storm. > (But please correct me if I'm wrong :) > > What can I do to help track this problem down? > > > > > > > According to "dmesg" the following devices share IRQ 16 : > > > > > >pcib1: irq 16 at device 1.0 on pci0 > > >em0: port > > > 0xcc00-0xcc1f mem > > > 0xf7de-0xf7df,0xf7d0-0xf7d7,0xf7ddc000-0xf7dd > > > irq 16 at device 0.0 on pci1 > > >vgapci0: port 0xbc00-0xbc07 > > > mem 0xf780-0xf7bf,0xe000-0xefff irq 16 at > > > device 2.0 on > > > pci0 > > >ehci0: mem > > > 0xf7cfa000-0xf7cfa3ff > > > irq 16 at device 26.0 on pci0 > > >em1: port > > > 0xec00-0xec1f mem > > > 0xf7fe-0xf7ff,0xf7f0-0xf7f7,0xf7fdc000-0xf7fd > > > irq 16 at device 0.0 on pci4 > > >pcib4: irq 16 at device 28.5 on pci0 > > > > > > During a storm "vmstat -i" shows a rate of about 220.000 > interrupts/sec. > > > MSI > > > interrupt delivery to both 'em0' and 'em1' seems to work correctly > during > > > a storm, as I see their counters increase normally in the "vmstat -i" > > > output. > > > > > > As only 'em0' and 'em1' seem to be using MSI interrupts, my guess is > that > > > the > > > e1000 driver is causing this problem. Could it be that the driver > forgets > > > to > > > clear/mask legacy interrupts when attaching the MSI interrupts perhaps? > > > > > > Any tips on how to debug and/or fix this? > > > > > > > > > The full output of "dmesg" can be found here : > > >http://vehosting.nl/pub_diffs/dmesg_plantje2_2011_05_04.txt > > > > > > And the full output of "pciconf -lv" is here : > > >http://vehosting.nl/pub_diffs/pciconf_plantje2_2011_05_04.txt > > > > > > Regards, > -- > Daan Vreeken > VEHosting > http://VEHosting.nl > tel: +31-(0)40-7113050 / +31-(0)6-46210825 > KvK nr: 17174380 > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: problems with em(4) since update to driver 7.2.2
I have had my validation engineer busy all day, we have tried both a 9 kernel as well as 8.2, using the code from HEAD, and we cannot reproduce this problem. The data your netstat -m shows suggests to me that what's happening is somehow setup of the receive ring is running more than once maybe?? You asked at one point how this could go into STABLE, well, because not only here at Intel, but at lots of external customers this code has been used and tested thoroughly. I am not calling into question your problem, but until I understand what it is I cannot "fix" it :) The thing I am guessing right now is the culprit is the setup code, the reason is that when I ported to the igb driver I found that it did not work on our newer hardware, and so I went back to the older version of setup for igb. Now, even though I have not seen hardware fail with em, maybe there is some. To help me give me a complete pciconf -lv, and if its a namebrand system tell me that, including all hardware in it. If you like Olivier I can make a version of em for you that also reverts the setup code the way I did for igb, see if that fixes it for you? Thanks for your patience, Jack ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Interrupt storm with MSI in combination with em1
This all looks completely kosher, what IRQ is the storm on?? Jack On Wed, May 4, 2011 at 3:04 PM, Daan Vreeken wrote: > Hi, > > On Wednesday 04 May 2011 20:47:32 Jack Vogel wrote: > > Will you please set it back to a default and then boot and capture the > > message for me? > > No problem. Here's the output with MSI/MSIX enabled : > > http://vehosting.nl/pub_diffs/dmesg_plantje2_with_msix_2011_05_04.txt > > I've also added the output of "vmstat -i" a couple of minutes after a > reboot > with MSI enabled : >http://vehosting.nl/pub_diffs/vmstat_i_2011_05_04.txt > > Note that in the above "vmstat -i" dump the interrupt storm hasn't started > yet. For some reason the storm doesn't always start directly at boot. I > haven't been able (yet) to pinpoint what's triggering it to start. > > > > On Wed, May 4, 2011 at 11:19 AM, Daan Vreeken wrote: > > > Hi Jack, > > > > > > Wednesday 04 May 2011 19:46:05 Jack Vogel wrote: > > > > Who makes your motherboard? The problem you are having is that MSIX > AND > > > > MSI are both failing as em0 comes up, so it falls back to Legacy > > > > > > interrupt > > > > > > > mode, > > > > and must be having some issue with sharing the line, causing the > storm. > > > > > > The motherboard is an Asus "P7H55-M". > > > > > > Sorry, I should have mentioned that the dmesg output is from booting > with : > > > > >hw.pci.enable_msix="0" > > > > >hw.pci.enable_msi="0" > > > > > > .. in "loader.conf". > > > > > > With those lines in "loader.conf", MSI and MSIX is disabled, both cards > > > work > > > like they should and there is no interrupt storm. > > > > > > With MSI/MSIX enabled, both cards work like they should and I see the > > > counters > > > of the MSI interrupts increase (in small amounts, like they should), > but > > > at boot-time an interrupt storm starts on 'legacy' IRQ 16. > > > > > > Because the only difference between disabling/enabling MSI/MSIX seems > to > > > be in > > > the way em0/em1 are used, and because 'em1' shares IRQ 16 according to > > > the dmesg, I'm suspecting 'em1' is causing the storm. > > > (But please correct me if I'm wrong :) > > > > > > What can I do to help track this problem down? > > > > > > > > According to "dmesg" the following devices share IRQ 16 : > > > > > > > > > >pcib1: irq 16 at device 1.0 on pci0 > > > > >em0: port > > > > > 0xcc00-0xcc1f mem > > > > > 0xf7de-0xf7df,0xf7d0-0xf7d7,0xf7ddc000-0xf7dd > > > > > irq 16 at device 0.0 on pci1 > > > > >vgapci0: port 0xbc00-0xbc07 > > > > > mem 0xf780-0xf7bf,0xe000-0xefff irq 16 at > > > > > device 2.0 on > > > > > pci0 > > > > >ehci0: mem > > > > > 0xf7cfa000-0xf7cfa3ff > > > > > irq 16 at device 26.0 on pci0 > > > > >em1: port > > > > > 0xec00-0xec1f mem > > > > > 0xf7fe-0xf7ff,0xf7f0-0xf7f7,0xf7fdc000-0xf7fd > > > > > irq 16 at device 0.0 on pci4 > > > > >pcib4: irq 16 at device 28.5 on pci0 > > > > > > > > > > During a storm "vmstat -i" shows a rate of about 220.000 > > > > > > interrupts/sec. > > > > > > > > MSI > > > > > interrupt delivery to both 'em0' and 'em1' seems to work correctly > > > > > > during > > > > > > > > a storm, as I see their counters increase normally in the "vmstat > -i" > > > > > output. > > > > > > > > > > As only 'em0' and 'em1' seem to be using MSI interrupts, my guess > is > > > > > > that > > > > > > > > the > > > > > e1000 driver is causing this problem. Could it be that the driver > > > > > > forgets > > > > > > > > to > > > > > clear/mask legacy interrupts when attaching the MSI interrupts > > > > > perhaps? > > > > > > > > > > Any tips on how to debug and/or fix this? > > > > > > > > > > > > > > > The full output of "dmesg" can be found here : > > > > >http://vehosting.nl/pub_diffs/dmesg_plantje2_2011_05_04.txt > > > > > > > > > > And the full output of "pciconf -lv" is here : > > > > > > http://vehosting.nl/pub_diffs/pciconf_plantje2_2011_05_04.txt > > > > > > Regards, > > > -- > > > Daan Vreeken > > > VEHosting > > > http://VEHosting.nl > > > tel: +31-(0)40-7113050 / +31-(0)6-46210825 > > > KvK nr: 17174380 > > > Regards, > -- > Daan Vreeken > VEHosting > http://VEHosting.nl > tel: +31-(0)40-7113050 / +31-(0)6-46210825 > KvK nr: 17174380 > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Interrupt storm with MSI in combination with em1
Right, it was you Wiktor :) Oh, so yours is sort of a special case. Thanks, Jack On Wed, May 4, 2011 at 3:27 PM, Wiktor Niesiobedzki wrote: > 2011/5/4 Jack Vogel : > > This is the second report in a matter of a week perhaps about a > problematic > > motherboard, I would like to know who makes them. > > Just for the record, the motherboard with which I had problems (I > guess my problem is here referred) is VIA EPIA SN1. It's nothing > new, and probably rarely used with additional PCIe cards, as this is > embedded-like creature. > > Cheers, > > Wiktor Niesiobedzki > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Interrupt storm with MSI in combination with em1
OK, but the reason you see the multiple cases of irq 16 is that's the bridge, once you are using MSIX, as vmstat shows, its using other vectors. Can you capture the messages file with the actual storm happening? I noticed some complaints about checksums in the dmesg, have you checked on BIOS upgrades or something like that on your motherboard? Regards, Jack On Wed, May 4, 2011 at 4:27 PM, Daan Vreeken wrote: > On Thursday 05 May 2011 00:15:43 you wrote: > > This all looks completely kosher, what IRQ is the storm on?? > > IRQ 16. Further down this email there is a list of devices that share the > IRQ > according to 'dmesg'. > > > > On Wed, May 4, 2011 at 3:04 PM, Daan Vreeken wrote: > > > Hi, > > > > > > On Wednesday 04 May 2011 20:47:32 Jack Vogel wrote: > > > > Will you please set it back to a default and then boot and capture > the > > > > message for me? > > > > > > No problem. Here's the output with MSI/MSIX enabled : > > > > > > http://vehosting.nl/pub_diffs/dmesg_plantje2_with_msix_2011_05_04.txt > > > > > > I've also added the output of "vmstat -i" a couple of minutes after a > > > reboot > > > with MSI enabled : > > >http://vehosting.nl/pub_diffs/vmstat_i_2011_05_04.txt > > > > > > Note that in the above "vmstat -i" dump the interrupt storm hasn't > > > started yet. For some reason the storm doesn't always start directly at > > > boot. I haven't been able (yet) to pinpoint what's triggering it to > > > start. > > > > > > > On Wed, May 4, 2011 at 11:19 AM, Daan Vreeken > wrote: > > > > > Hi Jack, > > > > > > > > > > Wednesday 04 May 2011 19:46:05 Jack Vogel wrote: > > > > > > Who makes your motherboard? The problem you are having is that > MSIX > > > > > > AND MSI are both failing as em0 comes up, so it falls back to > Legacy > > > > > > interrupt mode, > > > > > > and must be having some issue with sharing the line, causing the > > > > > > storm. > > > > > The motherboard is an Asus "P7H55-M". > > > > > > > > > > Sorry, I should have mentioned that the dmesg output is from > booting > > > > > with : > > > > > > >hw.pci.enable_msix="0" > > > > > > >hw.pci.enable_msi="0" > > > > > .. in "loader.conf". > > > > > > > > > > With those lines in "loader.conf", MSI and MSIX is disabled, both > > > > > cards work > > > > > like they should and there is no interrupt storm. > > > > > > > > > > With MSI/MSIX enabled, both cards work like they should and I see > the > > > > > counters > > > > > of the MSI interrupts increase (in small amounts, like they > should), > > > > > but at boot-time an interrupt storm starts on 'legacy' IRQ 16. > > > > > > > > > > Because the only difference between disabling/enabling MSI/MSIX > seems > > > > > to be in > > > > > the way em0/em1 are used, and because 'em1' shares IRQ 16 according > > > > > to the dmesg, I'm suspecting 'em1' is causing the storm. > > > > > (But please correct me if I'm wrong :) > > > > > > > > > > What can I do to help track this problem down? > > > > > > > > > > > > According to "dmesg" the following devices share IRQ 16 : > > > > > > > > > > > > > >pcib1: irq 16 at device 1.0 on > pci0 > > > > > > >em0: port > > > > > > > 0xcc00-0xcc1f mem > > > > > > > > 0xf7de-0xf7df,0xf7d0-0xf7d7,0xf7ddc000-0xf7dd > > > > > > > irq 16 at device 0.0 on pci1 > > > > > > >vgapci0: port 0xbc00-0xbc07 > > > > > > > mem 0xf780-0xf7bf,0xe000-0xefff irq > 16 > > > > > > > at device 2.0 on > > > > > > > pci0 > > > > > > >ehci0: mem > > > > > > > 0xf7cfa000-0xf7cfa3ff > > > > > > > irq 16 at device 26.0 on pci0 > > > > > > >em1: port > > > > > > > 0xec00
Re: problems with em(4) since update to driver 7.2.2
OK, but what this does not explain is why I do not see this if its so easily reproduced, what causes the failure case, any idea? As I said, given the code was not feasible for igb anyway I would not be unhappy about returning to the old way of doing things. Jack On Wed, May 4, 2011 at 11:03 PM, Arnaud Lacombe wrote: > Hi, > > On Thu, May 5, 2011 at 1:20 AM, Arnaud Lacombe wrote: > > Hi, > > > > On Wed, May 4, 2011 at 5:38 PM, Jack Vogel wrote: > >> I have had my validation engineer busy all day, we have tried both > >> a 9 kernel as well as 8.2, using the code from HEAD, and we > >> cannot reproduce this problem. > >> > > Actually, it can be trivially reproduced by tainting `error'. As it is > > uninitialized in HEAD, it's value can be _anything_, so let's mark it > > as explicitly invalid. > > > > diff -u ./if_em.c /data/src/freebsd/em-7.2.2/src/if_em.c > > --- ./if_em.c 2011-02-18 01:18:23.0 -0500 > > +++ /data/src/freebsd/em-7.2.2/src/if_em.c 2011-05-05 > > 01:12:01.0 -0400 > > @@ -3912,7 +3912,7 @@ > >struct adapter *adapter = rxr->adapter; > >struct em_buffer*rxbuf; > >bus_dma_segment_t seg[1]; > > - int i, j, nsegs, error; > > + int i, j, nsegs, error = -1; > > > > The error pointed out in this thread pops up in the next boot. > > > I put a call to kdb_enter() at the beginning of the function, helped > with some textdump I got all the backtrace [0] for all the time > em_setup_receive_ring() is called. All are exactly the same: > > kdb_enter_why(0,c09f6511,f391aaa8,c09be1e2,c09f6511,...) at > kdb_enter_why+0x3b > kdb_enter(c09f6511,0,3810,,5dc,...) at kdb_enter+0x19 > em_setup_receive_ring(c3c8d600,c3c8d7a4,c3c96004,31fa,c3c8d600,...) > at em_setup_receive_ring+0x22 > em_setup_receive_structures(c3c96000,f15f2000,38,8100,3,...) at > em_setup_receive_structures+0x26 > em_init_locked(c3c96000,0,c09f5de5,414,1,...) at em_init_locked+0x2f2 > em_ioctl(c3c7d000,80206934,c3ce9d00,c07b7a0b,c3f2a230,...) at > em_ioctl+0x1c3 > ifhwioctl(c3f2a230,f391ac34,c07b7a0b,c3f3e3d0,c08df1c0,...) at > ifhwioctl+0x4b8 > ifioctl(c3f3e3d0,80206934,c3ce9d00,c3f2a230,c3f2a230,...) at ifioctl+0x82 > kern_ioctl(c3f2a230,3,80206934,c3ce9d00,c3ce9d00,...) at kern_ioctl+0xa8 > ioctl(c3f2a230,f391acf8,c,c,f391ad2c,...) at ioctl+0xc5 > syscall(f391ad38) at syscall+0x17d > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x4816ee23, esp = > 0xbfbfe67c, ebp = 0xbfbfe698 --- > > This fully explain why the main loop in em_setup_receive_ring() is > never entered, as we always verify `j == rxr->next_to_check' (provided > that mbuf have been refreshed if some packet were transfered) and > return the value on the stack. As of now, beside changing the > call-site of em_setup_receive_ring() to ensure it is never re-entered, > I'd guess that the patch I sent earlier today, is the only way to > ensure that no junk is returned. > > I'd guess that the driver _is_ able to transmit, if the code was not > explicitly calling em_stop() upon em_setup_receive_structures() > failure. > > - Arnaud > > [0]: I wish that would have been as easy as in Linux, where a WARN() > call do all the job automatically, but still, I should not hope for > that much unless I am the one implementing it ... yes, free whining, > it's 2a.m. ... > > > - Arnaud > > > >> The data your netstat -m shows suggests to me that what's happening > >> is somehow setup of the receive ring is running more than once maybe?? > >> > >> You asked at one point how this could go into STABLE, well, because > >> not only here at Intel, but at lots of external customers this code has > been > >> used and tested thoroughly. > >> > >> I am not calling into question your problem, but until I understand what > it > >> is I cannot "fix" it :) > >> > >> The thing I am guessing right now is the culprit is the setup code, the > >> reason > >> is that when I ported to the igb driver I found that it did not work on > our > >> newer > >> hardware, and so I went back to the older version of setup for igb. Now, > >> even > >> though I have not seen hardware fail with em, maybe there is some. > >> > >> To help me give me a complete pciconf -lv, and if its a namebrand system > >> tell me that, including all hardware in it. > >> > >> If you like Olivier I can make a
Re: problems with em(4) since update to driver 7.2.2
On Thu, May 5, 2011 at 7:21 AM, Arnaud Lacombe wrote: > Hi, > > On Thu, May 5, 2011 at 2:59 AM, Jack Vogel wrote: > > OK, but what this does not explain is why I do not see this if > > its so easily reproduced, what causes the failure case, any idea? > > > It is completely random as it depends on the content of the stack. I > spent 3 or 4 hours trying to reproduce it using different approach on > different platform, with different version of the code and failed. And > once `error' was explicitly colored, it popped up. That's the beauty > of error related with uninitialized variable. > > - Arnaud > > > As I said, given the code was not feasible for igb anyway I would not > > be unhappy about returning to the old way of doing things. > > > I am not sure what you mean by "old way of doing thing", but I'd guess > that the ring only need to be setup on a few occasion, like > initialization and MTU transition. I'm not sure either how other > driver manage their ring. > > The old way was as the code is in igb now, on each entry to this setup it would completely wipe the descriptor memory, then release all mbufs, and initialize from scratch. Its only because of this "lazy" reinit, meaning only the range from next_to_refresh to next_to_check is reset, that this problem can happen. For igb the reason this will not work, is it requires you to set E1000_RDH(i) to next_to_check, and in fact, the hardware prohibits the write, its ALWAYS 0 after a reset. The reason for this is that the hardware wishes to manage the head index and not software. Anyway, I see the problematic code path, its only when you skip the while loop altogether. I'm surprised the compiler did not complain about this, its usually so anal. Jack ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: problems with em(4) since update to driver 7.2.2
Not sure, I wondered if those seeing this had some special sequence of actions they took for granted that is different than what we do in house... In any case, the init really is ultimately a correctness thing, so let's just call it good :) Jack On Thu, May 5, 2011 at 11:16 AM, Olivier Smedts wrote: > 2011/5/5 Jack Vogel : > > Anyway, I see the problematic code path, its only when > > you skip the while loop altogether. I'm surprised the compiler > > did not complain about this, its usually so anal. > > Could it be related to the compiler (clang) or some optimization flags ? > > -- > Olivier Smedts _ > ASCII ribbon campaign ( ) > e-mail: oliv...@gid0.org- against HTML email & vCards X > www: http://www.gid0.org- against proprietary attachments / \ > > "Il y a seulement 10 sortes de gens dans le monde : > ceux qui comprennent le binaire, > et ceux qui ne le comprennent pas." > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Interrupt storm with MSI in combination with em1
Cool, thanks for the update! Good luck. Jack On Thu, May 5, 2011 at 1:17 PM, Daan Vreeken wrote: > Hi Peter, > > On Thursday 05 May 2011 21:28:02 Peter Jeremy wrote: > > On 2011-May-05 13:22:59 +0200, Daan Vreeken wrote: > > >Not yet. I'll reboot the machine later today when I have physical access > > > to it to check the BIOS version. I'll keep you informed as soon as I > get > > > another storm going. > > > > Depending on the quality of your BIOS (competence of the vendor), you > > might find that kenv(8) reports the BIOS version without needing a > reboot. > > (Look at smbios.bios.* in the output). > > Great! I didn't know that :) > > # kenv > ... > smbios.bios.reldate="07/15/2010" > ... > smbios.bios.version="0303 " > ... > smbios.planar.maker="ASUSTeK Computer INC." > smbios.planar.product="P7H55-M LX" > > > Version "0402" is the latest and greatest, so it's time to upgrade. > According > to Asus it "Improves system stability", so let's see if this 'cures' IRQ > 16. > > > Thanks, > -- > Daan Vreeken > VEHosting > http://VEHosting.nl > tel: +31-(0)40-7113050 / +31-(0)6-46210825 > KvK nr: 17174380 > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Interrupt storm with MSI in combination with em1
I don't see why you are blaming em, you can see its on MSIX vectors that are NOT storming, its something with USB as noted. Trying to disable em from using MSIX is in exactly the wrong direction IMHO. Jack On Fri, May 6, 2011 at 8:32 AM, Daan Vreeken wrote: > Hi Steven, > > On Friday 06 May 2011 17:20:15 Steven Hartland wrote: > > From: "Daan Vreeken" > > > > > # vmstat -i > > > interrupt total rate > > > irq3: uart1 917384 63 > > > --> irq16: ehci0 809547235 55608 > > > > Have you tried removing USB from the kernel? > > > > USB seems to be a common course of this behaviour and here at least > > removing it from the kernel fixes in all cases assuming you don't > > need it for something? > > No, I haven't tried that yet. I could disable USB to run some tests, but > I'll > eventually need it enabled again. > I'll wait for a couple of hours to see if anyone can come up with a test to > run on the machine while the interrupt is still storming. After that I'll > reboot it with USB disabled. > > > Thanks, > -- > Daan Vreeken > VEHosting > http://VEHosting.nl > tel: +31-(0)40-7113050 / +31-(0)6-46210825 > KvK nr: 17174380 > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] Add the infrastructure for supporting an infinite number of CPUs
Awesome, glad to see this happening :) Jack On Wed, Jun 1, 2011 at 11:21 AM, Attilio Rao wrote: > Current maximum number of CPUs supported by the FreeBSD kernel is 32. > That number cames from indirectly by the fact that we have a cpumask_t > type, representing a mask of CPUs, which is an unsigned int right now. > I then made a patch that removes the cpumask_t type and uses cpuset_t > type for characterizing a generic mask of CPUs: > http://www.freebsd.org/~attilio/largeSMP/largeSMP-patchset-beta-0.diff > > This is part of a bigger effort which brought to serveral smaller > commits along the way, in order to fix some edge cases. > > Things to pay attention at: > - Userland and kerneland cpuset_t size can be different, thus when > accessing to a kernel cpuset_t object from userland (via kvm_read() > for example) a pattern similar to what pmccontrol does, in this patch, > should be followed > - There are some cpuset_t object in pcpu representing curcpu mask and > !curcpu mask. With transition from cpumask_t to cpuset_t they become > inefficient and not really useful. The next weeks I'll focus on > removing them and make a smarter usage of the cpuset_t interface. > Additively, please note that right now I clobbered pcpu accesses > under scheduler pinnings, because it is possible more than a single > atomic operation is needed for accessing a cpuset_t. When the cleanup > happens those pinnings will go away. > - I had to introduce, among the other things, functions for > representing cpuset_t object in "visual" way, thus > cpusetobj_strprint() and cpusetobj_strscan(). I got the desired format > from what Linux already does, so that someone may be already used to > it. Anyway strings will be represented as a serie of long, hexadecimal > long words, all separated by ", ". The left-most represents the higher > word, following natural bits representation. > - I used cpusetobj_strscan() for implementing KTR_CPUMASK in a way it > supports cpuset_t. Change the kernel config appropriately. > - No MAXCPU has been bumped in the patch, but I encourage you to do so > with your own kernel configurations. > > I really need to commit this patch before code slush happens, thus I > plan to commit it on June 7th, if no one reports bugs or can make good > point on his reviews. Please note that the patch has been greatly > tested and reviewed on all FreeBSD tier-1 and tier-2 architectures. > Anyway more testing and reviews are welcome to happen. > > Thanks, > Attilio > > > -- > Peace can only be achieved by understanding - A. Einstein > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.0-CURRENT-201105-amd64 install kernel panic
Interrupts are not enabled til after that is set, so I don't think this theory works, sorry. Jack On Fri, Jun 10, 2011 at 12:48 PM, K. Macy wrote: > This recent commit changed the way that the value for size being > passed to m_getjcl is initialized. Not seeing any obvious bugs, and > not having any additional context I would guess that that you're > receiving an interrupt before adapter->rx_mbuf_sz is set. I trust jfv@ > to look in to this shortly. > > > http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_em.c?r1=214362&r2=214363&; > > Thanks > > > On Fri, Jun 10, 2011 at 9:19 PM, Kim Culhan wrote: > > On Fri, June 10, 2011 11:22 am, Kim Culhan wrote: > >> Booting from FreeBSD-9.0-CURRENT-201105-amd64-memstick > >> the kernel panics: > >> > >> panic: m_getzone: m_getjcl: invalid cluster type > > > > Found a ps2 keyboard works in the debugger (not usb) and backtrace is > here: > > > > http://www.flickr.com/photos/opensolaris/<http://www.flickr.com/photos/opensolaris/5819107302/in/photostream> > 5819107302/in/photostream > > -kim > > ___ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscr...@freebsd.org" > > > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Watchdog resets on 82575
If you have this adapter and have been getting watchdogs you need to pick up the small update I checked into HEAD today. When I added the SR-IOV support for the 82576 adapter I removed a call to set the MAC type in an early routine, thinking it was unnecessary, since a slightly later shared code init does the same thing. I also saw no problem when I did this on the 82576 well, it did have a bad effect that I did not notice, the slightly later call, igb_setup_msix() did not have the mac set and this resulted in the 82575 creating more queues than it is really able to handle. So, bottom line, this is a critical fix for 82575: SVN rev 210968 Cheers, Jack ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: regarding pciids
On Tue, Sep 14, 2010 at 4:29 AM, Jakub Lach wrote: > > > Alexander Best-4 wrote: > > > > any thoughts on using http://pciids.sourceforge.net/ for pciids instead > of > > the > > Hart and Boemler lists. the SF site seems to be updated more regularly > and > > would get rid of the need to decide for each entry, whether to take the > > Hart or > > Boemler one. > > > > right now tools/tools/pciid/mk_pci_vendors.pl favours long descriptions > > over > > short ones which means that something like: > > > > 'Intel(R) ICH9 Family SMBus Controller (8086)' > > > > will get discarded in favor of > > > > 'Intel(R) ICH9 Family SMBus Controller working fine with > > http://download.cnet.com/Chipset-Driver-Inte (8086)' > > > > +1, since I'm the one[1] with (well, not the only one, ICH9 should be quite > popular) > "http://download.cnet.com/Chipset-Driver-Inte"; device. > > best regards, > - Jakub Lach > JFYI, the sourceforge site is where Intel updates its data, and until this post I was already under the impression we pulled from there. I would say that it would be the better source. Jack ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Regarding pciids
On Mon, Oct 18, 2010 at 12:13 PM, Garrett Cooper wrote: > On Mon, Oct 18, 2010 at 11:36 AM, Alexander Best > wrote: > > On Mon Oct 18 10, Garrett Cooper wrote: > >> On Mon, Oct 18, 2010 at 8:28 AM, Alexander Best > wrote: > >> > On Mon Oct 18 10, Alexander Best wrote: > >> >> On Fri Sep 17 10, Alex Dupre wrote: > >> >> > I created hackish scripts to generate pci_vendors file from Boemler > and > >> >> > Mares (pciids.sf.net) lists. I haven't found the Hart list. > >> >> > > >> >> > The results of the scripts are here: > >> >> > >> >> sorry it seems i missed your post back then. > >> >> > >> >> i found two more lists: > >> >> > >> >> http://rh-software.com/downloads/pcidevs.txt > >> >> and > >> >> http://hobbes.nmsu.edu/h-browse.php?dir=/pub/incoming (seems to be > based on the > >> >> Hart list) > >> >> > >> >> the actual Hart list seems to have vanished and the web location is > no longer > >> >> accessible. > >> >> > >> >> personally i don't think it's necessary to combine the data of two > files. the > >> >> mares database seems extremely elaborate. all my pci devices get > described > >> >> properly. also making use of only one databse would make it more easy > to submit > >> >> additional info back to the vendor. > >> >> > >> >> so any objections to switching to the mares list? > >> >> > >> >> cheers. > >> >> alex > >> >> > >> >> > > >> >> > http://www.alexdupre.com/pci_vendors/mares.txt > >> >> > http://www.alexdupre.com/pci_vendors/boemler.txt > >> >> > http://www.alexdupre.com/pci_vendors/mares-boemler.txt > >> >> > http://www.alexdupre.com/pci_vendors/boemler-mares.txt > >> >> > > >> >> > The first two are generated from single lists, the last two are > >> >> > combined, with different preference order. > >> > > >> > oh...and i think it would be a good idea to move from ";" as comment > character > >> > to "#". that way we wouldn't need to run a script, but could include > the vendor > >> > file directly into the src tree. > >> > >> I noted this a while back to Warner and Brooke as I came up with a > >> short script to do this, and they suggested that it be supplemented to > >> the existing list, not replace it. > > > > why? the mares list is obviosly superior, because linux contributes to it > and > > thus has far more people submitting changes than any other list. > > > > is there a case where the old list has an entry the mares list is > missing? > >Most of the values (above 99%) were the same actually between the > 2 lists. I think the point was to avoid churn in the description > fields because a lot of the description fields were different, the > Linux list was produced by questionable sources (IIRC the other list > was produced by vendors, but I could be wrong). Rather than guessing I > would just ask Brookes and Warner directly though, offlist... > Cheers, > -Garrett > Questionable, you mean like Intel? :) I brought this up in the first place asking because our new ID's go direct into the sf list. I understand the desire to avoid churn, but I suspect this would be a change for the longer term good. Just my .02 Jack ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
IPV6 Checksum offload and TSO6
I had occasion to think about this, and I was wondering if someone is working to add either or both of these features, Intel's hardware supports it, it does not seem that hard to add, or am I missing something? Cheers, Jack ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: IPV6 Checksum offload and TSO6
Looked to me like Michael already has the SCTP stuff in the inet6 code. Not sure if it needs further enabling or what?? I'm not positive about what cards are in the netperf cluster. Any card that em, igb, and ixgbe supports can do the TCP/UDP checksum offloads whether in IPv4 or 6 if handed to it. TSO is a TCP segmentation so it also is a matter of IPv6 allowing it to do so, at least that is my present understanding. SCTP offload can only be handled in the igb and ixgbe drivers, none of the em hardware can do it (at least not as of today). Personally its TSO that I care most about, but the protocol checksums might as well be available too. Jack On Wed, Oct 20, 2010 at 3:20 PM, Bjoern A. Zeeb wrote: > On Wed, 20 Oct 2010, Jack Vogel wrote: > > Hi, > > > I had occasion to think about this, and I was wondering if someone is >> working to add >> either or both of these features, Intel's hardware supports it, it does >> not >> seem that >> hard to add, or am I missing something? >> > > Strange that I had been thinking of that last night and talking to > poeple today. It's kind of on the roadmap here for mid-November. > > It's mostly freebsd infrastructure that's missing for it (along with > some cleanup on the flags in a couple of places). tuexen@ wanted to > get the CSUM_* stuff done for SCTP as well but I haven't re-pinged > him on that one yet. > > Do you know if we have Intel cards in the netperf cluster that can > actually do it for testing? What's the matrix for the various cards > for v6 offloads? >TCP/UDP/SCTP? >IP? >TSO? >TOE? > > Imho noone does TOE6 yet (correct me if wrong) but I'd like to get > the others all sorted then. > > /bz > > -- > Bjoern A. Zeeb Welcome a new stage of life. > Going to jail sucks -- All my daemons like it! > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: something missing from r215781? (if_igb)
Oh crap, sorry, fix coming shortly. Jack On Tue, Nov 23, 2010 at 4:17 PM, Michael Butler wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Seems there are a couple of defines missing from an e1000_hw.h > > ===> igb (all) > > [ .. snip .. ] > > /usr/home/imb/svn/head/sys/modules/igb/../../dev/e1000/if_igb.c:142: > error: 'E1000_DEV_ID_DH89XXCC_SERDES' undeclared here (not in a function) > /usr/home/imb/svn/head/sys/modules/igb/../../dev/e1000/if_igb.c:143: > error: 'E1000_DEV_ID_DH89XXCC_SGMII' undeclared here (not in a function) > *** Error code 1 > 1 error > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (FreeBSD) > > iEYEARECAAYFAkzsWX4ACgkQQv9rrgRC1JLk8ACbB6TesvKtbbHL55qyFTBIEYYf > 3zUAoKEx2CJSWoYh/gp+XAvA+9uWaGZL > =DHTC > -END PGP SIGNATURE- > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 10-RC4: Got crash in igb driver
The changes to igb were to add IPV6 support which previously was only in ixgbe, the transmit path code came from that code base, we did not see this issue in testing. Its not a simple matter of a few lines of code, I think we need to go forward not back... I'll look at the code. Jack On Fri, Jan 10, 2014 at 2:35 AM, Gleb Smirnoff wrote: > Yonghyeon, > > On Fri, Jan 10, 2014 at 10:21:14AM +0900, Yonghyeon PYUN wrote: > Y> > I experience some troubles with the igb device driver on FreeBSD > 10-RC4. > Y> > > Y> > The kernel make a pagefault in the igb_tx_ctx_setup function when > accessing to > Y> > a IPv6 header. > Y> > > Y> > The network configuration is the following: > Y> > - box acting as an IPv6 router > Y> > - one interface with an IPv6 (igb0) > Y> > - another interface with a vlan, and IPv6 on it (vlan0 on igb1) > Y> > > Y> > Vlan Hardware tagging is set on both interfaces. > Y> > > Y> > The packet that cause the crash come from igb0 and go to vlan0. > Y> > > Y> > After investigation, i see that the mbuf is split in two. The first > one carry > Y> > the ethernet header, the second, the IPv6 header and data payload. > Y> > > Y> > The split is due to the "m_copy" done in ip6_forward, that make the > mbuf not > Y> > writable and the "M_PREPEND" in ether_output that insert the new mbuf > before > Y> > the original one. > Y> > > Y> > The kernel crashes only if the newly allocated mbuf is at the end of > a memory > Y> > page, and no page is available after this one. So, it's extremly rare. > Y> > > Y> > I inserted a "KASSERT" into the function (see attached patch) to > check this > Y> > behavior, and it raises on every IPv6 forwarded packet to the vlan. > The > Y> > problem disapear if i remove hardware tagging. > Y> > > Y> > In the commit 256200, i see that pullups has been removed. May it be > related ? > Y> > Y> I think I introduced the header parsing code to meet controller > Y> requirement in em(4) and Jack borrowed that code in the past but it > Y> seems it was removed in r256200. It seems igb_tx_ctx_setup() > Y> assumes it can access ethernet/IP/TCP/UDP headers in the first mbuf > Y> of the chain. > Y> This looks wrong to me. > > Can you please restore the important code in head ASAP? Although crashes > happen > only when the mbuf is last in a page and page isn't mapped, we read thrash > from > next allocation on almost every packet. > > -- > Totus tuus, Glebius. > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: igb broken? Unexplained weirdness with intel 82576 nics on a supermicro board.
Looks like something to do with system C, you might isolate it, and try a back to back connection with its NICs, change cables, look at BIOS settings, change the slot the nic is in... All just off the top of my head. Jack On Sat, May 8, 2010 at 9:41 AM, joe wrote: > On 05/08/2010 11:17 AM, Ian FREISLICH wrote: > >> joe wrote: >> >>> On 05/08/2010 06:55 AM, Ian FREISLICH wrote: >>> >>>> joe wrote: >>>> >>>>> I have just tried your suggeston and it has no effect for me ;( >>>>> >>>> >>>> Do you have another brand of NIC that you can try? At least that >>>> will isolate whether it's igb(4) or something else. >>>> >>> >>> I will grab a new nic today and try...my options are limited though. >>> Here are the nics i can get my hands on >>> >>> TP-LINK TL-TG3468, 10/100/1000Mbps PCIe Adapter (supported by fbsd?) >>> >> >> Based on the RTL8168B chip. Should be supported by the re(4) driver. >> >> Intel (EXPI9301CT) Gigabit CT Desktop Adapter (yet another intel nic) >>> >> >> i82574L chip. Should be supported by the em(4) driver. I have had >> good performance in the past with this driver and less than >> satisfactory performance with the igb(4) driver. >> >> That may not be your problem though. Before you go out and buy, >> have a look at the amount of interrupt time your slow machine spends >> in 'top' or 'systat -vm'. systat will also show the interrupt rate >> for each driver, perhaps it's not doing interrupt moderation properly. >> This will manifest as more than about a 1000 per second. There are >> loader tunables for the driver to increase the number of transfer >> descriptors and to tune interrupt moderation. >> >> You could try running trafshow (port) on the interface while >> performing the transfer. Perhaps promiscuous mode will turn off >> some hardware feature that will improve things. It may however >> break hardware vlanning as it does on my 82575GB 4 port igb card. >> >> Ian >> >> -- >> Ian Freislich >> > > I bought those two cards anyways, im in a rush to figure out this problem. > That being said i am still encountering the exact same problem regardless on > which network card i am running. I am at a complete loss. I am about to try > a raid card to see if the problem might lay within the onboard sata ports. I > did pull the server and brought it home so that i can test more things > quicker. > > I am going to try using a raid card instead of the onboard sata ports and > see if i still encounter the same problem. I would love any suggestions you > may have on where to go from here to figure out where the problem might be. > > joe > > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: igb broken? Unexplained weirdness with intel 82576 nics on a supermicro board.
I still am not clear on this system, how many ports are on it, and its an 82576? Sounds to me like you've proven its not on the box if you can do fine when its on its own. So change ports in the switch, as I said, change cables, must be something in that environment. Jack On Sat, May 8, 2010 at 10:04 AM, joe wrote: > On 05/08/2010 01:31 PM, Jack Vogel wrote: > >> Looks like something to do with system C, you might isolate it, and try >> a back >> to back connection with its NICs, change cables, look at BIOS settings, >> change >> the slot the nic is in... All just off the top of my head. >> >> Jack >> >> >> On Sat, May 8, 2010 at 9:41 AM, joe > <mailto:j...@hostedcontent.com>> wrote: >> >>On 05/08/2010 11:17 AM, Ian FREISLICH wrote: >> >>joe wrote: >> >>On 05/08/2010 06:55 AM, Ian FREISLICH wrote: >> >>joe wrote: >> >> I have just tried your suggeston and it has >>no effect for me ;( >> >> >>Do you have another brand of NIC that you can try? At >>least that >>will isolate whether it's igb(4) or something else. >> >> >>I will grab a new nic today and try...my options are limited >>though. >>Here are the nics i can get my hands on >> >>TP-LINK TL-TG3468, 10/100/1000Mbps PCIe Adapter (supported >>by fbsd?) >> >> >>Based on the RTL8168B chip. Should be supported by the re(4) >>driver. >> >>Intel (EXPI9301CT) Gigabit CT Desktop Adapter (yet another >>intel nic) >> >> >>i82574L chip. Should be supported by the em(4) driver. I have had >>good performance in the past with this driver and less than >>satisfactory performance with the igb(4) driver. >> >>That may not be your problem though. Before you go out and buy, >>have a look at the amount of interrupt time your slow machine >> spends >>in 'top' or 'systat -vm'. systat will also show the interrupt rate >>for each driver, perhaps it's not doing interrupt moderation >>properly. >>This will manifest as more than about a 1000 per second. There are >>loader tunables for the driver to increase the number of transfer >>descriptors and to tune interrupt moderation. >> >>You could try running trafshow (port) on the interface while >>performing the transfer. Perhaps promiscuous mode will turn off >>some hardware feature that will improve things. It may however >>break hardware vlanning as it does on my 82575GB 4 port igb card. >> >>Ian >> >>-- >>Ian Freislich >> >> >>I bought those two cards anyways, im in a rush to figure out this >>problem. That being said i am still encountering the exact same >>problem regardless on which network card i am running. I am at a >>complete loss. I am about to try a raid card to see if the problem >>might lay within the onboard sata ports. I did pull the server and >>brought it home so that i can test more things quicker. >> >>I am going to try using a raid card instead of the onboard sata >>ports and see if i still encounter the same problem. I would love >>any suggestions you may have on where to go from here to figure out >>where the problem might be. >> >>joe >> >>___ >>freebsd-current@freebsd.org <mailto:freebsd-current@freebsd.org> >> >>mailing list >>http://lists.freebsd.org/mailman/listinfo/freebsd-current >>To unsubscribe, send any mail to >>"freebsd-current-unsubscr...@freebsd.org >><mailto:freebsd-current-unsubscr...@freebsd.org>" >> >> >> > I think it might have something to so with the nics / switch, and their > features. I brought the box home, plugged into my gb switch, and i am able > to FTP data to the server at around 35MB/sec. > > I dont know what would cause this other than some sort of issue with the > the 3 different types of nics and the switch i am using. > > Any suggestions? > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: igb broken? Unexplained weirdness with intel 82576 nics on a supermicro board.
The cable, its a simple thing but make SURE you try that, a slightly damaged one can do weird things and its quick to check, don't overlook it. Jack On Sat, May 8, 2010 at 10:22 AM, joe wrote: > On 05/08/2010 01:53 PM, Jack Vogel wrote: > >> I still am not clear on this system, how many ports are on it, and its >> an 82576? >> Sounds to me like you've proven its not on the box if you can do fine >> when its >> on its own. So change ports in the switch, as I said, change cables, must >> be >> something in that environment. >> >> Jack >> >> >> On Sat, May 8, 2010 at 10:04 AM, joe > <mailto:j...@hostedcontent.com>> wrote: >> >>On 05/08/2010 01:31 PM, Jack Vogel wrote: >> >>Looks like something to do with system C, you might isolate it, >>and try >>a back >>to back connection with its NICs, change cables, look at BIOS >>settings, >>change >>the slot the nic is in... All just off the top of my head. >> >>Jack >> >> >>On Sat, May 8, 2010 at 9:41 AM, joe ><mailto:j...@hostedcontent.com> >><mailto:j...@hostedcontent.com <mailto:j...@hostedcontent.com>>> >> >>wrote: >> >>On 05/08/2010 11:17 AM, Ian FREISLICH wrote: >> >>joe wrote: >> >>On 05/08/2010 06:55 AM, Ian FREISLICH wrote: >> >>joe wrote: >> >> I have just tried your suggeston and >>it has >>no effect for me ;( >> >> >>Do you have another brand of NIC that you can >>try? At >>least that >>will isolate whether it's igb(4) or something else. >> >> >>I will grab a new nic today and try...my options are >>limited >>though. >>Here are the nics i can get my hands on >> >>TP-LINK TL-TG3468, 10/100/1000Mbps PCIe Adapter >>(supported >>by fbsd?) >> >> >>Based on the RTL8168B chip. Should be supported by the >>re(4) >>driver. >> >>Intel (EXPI9301CT) Gigabit CT Desktop Adapter (yet >>another >>intel nic) >> >> >>i82574L chip. Should be supported by the em(4) driver. >> I have had >>good performance in the past with this driver and less than >>satisfactory performance with the igb(4) driver. >> >>That may not be your problem though. Before you go out >>and buy, >>have a look at the amount of interrupt time your slow >>machine spends >>in 'top' or 'systat -vm'. systat will also show the >>interrupt rate >>for each driver, perhaps it's not doing interrupt >> moderation >>properly. >>This will manifest as more than about a 1000 per second. >> There are >>loader tunables for the driver to increase the number of >>transfer >>descriptors and to tune interrupt moderation. >> >>You could try running trafshow (port) on the interface >> while >>performing the transfer. Perhaps promiscuous mode will >>turn off >>some hardware feature that will improve things. It may >>however >>break hardware vlanning as it does on my 82575GB 4 port >>igb card. >> >>Ian >> >>-- >>Ian Freislich >> >> >>I bought those two cards anyways, im in a rush to figure out >>this >>problem. That being said i am still encountering the exact same >>problem regardless on which network card i am running. I am at >> a >>complete loss. I am about to try a raid card to see if the >>problem >>might lay within the onboard sata ports. I did pull the >>server and >>brought it home so that i can test more things quicker. >> >>I am going to try
Re: igb broken? Unexplained weirdness with intel 82576 nics on a supermicro board.
On Sun, May 9, 2010 at 2:54 AM, joe wrote: > On 05/08/2010 02:21 PM, Jack Vogel wrote: > >> The cable, its a simple thing but make SURE you try that, a slightly >> damaged one can do weird things and its quick to check, don't overlook >> it. >> >> Jack >> >> >> On Sat, May 8, 2010 at 10:22 AM, joe > <mailto:j...@hostedcontent.com>> wrote: >> >>On 05/08/2010 01:53 PM, Jack Vogel wrote: >> >>I still am not clear on this system, how many ports are on it, >>and its >>an 82576? >>Sounds to me like you've proven its not on the box if you can do >>fine >>when its >>on its own. So change ports in the switch, as I said, change >>cables, must be >>something in that environment. >> >>Jack >> >> >>On Sat, May 8, 2010 at 10:04 AM, joe ><mailto:j...@hostedcontent.com> >><mailto:j...@hostedcontent.com <mailto:j...@hostedcontent.com>>> >>wrote: >> >>On 05/08/2010 01:31 PM, Jack Vogel wrote: >> >>Looks like something to do with system C, you might >>isolate it, >>and try >>a back >>to back connection with its NICs, change cables, look at >>BIOS >>settings, >>change >>the slot the nic is in... All just off the top of my head. >> >>Jack >> >> >>On Sat, May 8, 2010 at 9:41 AM, joe >>mailto:j...@hostedcontent.com> >><mailto:j...@hostedcontent.com <mailto:j...@hostedcontent.com>> >><mailto:j...@hostedcontent.com <mailto:j...@hostedcontent.com> >><mailto:j...@hostedcontent.com <mailto:j...@hostedcontent.com>>>> >> >>wrote: >> >>On 05/08/2010 11:17 AM, Ian FREISLICH wrote: >> >>joe wrote: >> >>On 05/08/2010 06:55 AM, Ian FREISLICH wrote: >> >>joe wrote: >> >> I have just tried your >>suggeston and >>it has >>no effect for me ;( >> >> >>Do you have another brand of NIC that >>you can >>try? At >>least that >>will isolate whether it's igb(4) or >>something else. >> >> >>I will grab a new nic today and try...my >>options are >>limited >>though. >>Here are the nics i can get my hands on >> >>TP-LINK TL-TG3468, 10/100/1000Mbps PCIe Adapter >>(supported >>by fbsd?) >> >> >>Based on the RTL8168B chip. Should be supported >>by the >>re(4) >>driver. >> >>Intel (EXPI9301CT) Gigabit CT Desktop >>Adapter (yet >>another >>intel nic) >> >> >>i82574L chip. Should be supported by the em(4) >>driver. >> I have had >>good performance in the past with this driver >>and less than >>satisfactory performance with the igb(4) driver. >> >>That may not be your problem though. Before you >>go out >>and buy, >>have a look at the amount of interrupt time your >>slow >>machine spends >>in 'top' or 'systat -vm'. systat will also show >> the >>interrupt rate >>for each driver, perhaps it's not doing >>interrupt moderation >>properly. >>This will manifest as more than about a 1000 per >>second. >> There are >>loader tunables for the driver to increase the >>number of >
Re: HEAD can't bring up APs on Intel LC5528(Jasper Forest)
What if you use amd64, have you tried that? Low level code is different. Interesting however, maybe I can get access to one around here, will see. Jack On Tue, May 18, 2010 at 2:32 PM, Ryan Stone wrote: > I'm trying to bring up a new board based on Intel's Jasper Forest x86 > processor. I can boot a kernel without SMP without any problems, but > FreeBSD is not able to start up the Application Processors if I enable > SMP. The error message that I get is: > > AP #2 (PHY# 2) failed! > panic y/n? [y] > > This was a i386 kernel built from HEAD as May 2nd or so. It's not > always PHY#2. Some number of APs manage to start up correctly, but > one usually fails. I have observed one instance where all of the APs > came up properly, so it seems as though there's some kind of race that > I stand a very good chance of losing at least one time in seven tries. > If I disable all but one AP through device.hints I stand a pretty > good chance of successfully starting that AP and booting correctly. > > I've been banging my head against the wall for a while now and all > indications are that the AP never starts at all. I enabled the > CHECK_POINTS compile-time option and and nothing ever gets written to > the CMOS for the AP that fails to start. Writing to the CMOS is the > second thing that the AP does after doing a cli so it's a good bet > that the AP never hits that code. > > Linux (version 2.6.28-11) is able to boot and start the APs just fine. > My suspicion is that Linux is explicitly configuring something that > FreeBSD is trusting the BIOS to do. > > We do have the reference board around, but we're having trouble > getting the original Intel BIOS programmed into it. If we can get > that working again I'll let you know whether FreeBSD can boot on it. > > If anybody can offer any hints or ideas for debugging this it'd be > greatly appreciated, as right now I'm reduced to grasping at straws. > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEAD can't bring up APs on Intel LC5528(Jasper Forest)
LOL, ok, I'm beating the bushes here Ryan, and I think I can get a system although it may be a day or two. Will let you know. Jack On Tue, May 18, 2010 at 4:40 PM, Ryan Stone wrote: > amd64 exhibits the same problem, except that it's not even polite and > panics without even asking. > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEAD can't bring up APs on Intel LC5528(Jasper Forest)
I have gotten access to a system this morning, I booted and installed 8.0 RELEASE on it, it had no problems installing or afterwords booting the SMP kernel. So, is it possible there's a regression/issue in HEAD, or perhaps you have something in the PCIE expansion slots that cause it, the system I'm using has nothing. Otherwise its possible there is a hardware revision difference. Have you tried 8 REL ? I'm up and rebuilding a kernel on it right now. Jack On Tue, May 18, 2010 at 4:40 PM, Ryan Stone wrote: > amd64 exhibits the same problem, except that it's not even polite and > panics without even asking. > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEAD can't bring up APs on Intel LC5528(Jasper Forest)
Cool, glad its resolved. Jack On Fri, May 21, 2010 at 10:43 AM, Ryan Stone wrote: > Just wanted to give everybody some closure on this issue: Through the > magic of a JTAG debugger, I was able to identify that the problem was > an infinite loop in the BIOS's SMI handler. I'm not sure why this > didn't effect Linux -- perhaps it brought up the APs before the SMI > came in. In any case, this clearly isn't a FreeBSD problem and I've > punted the problem back to the BIOS vendor. Thanks to everyone who > offered help and advice. > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: PCI SR-IOV infrastructure has been committed to head
Awesome news my friend. I got distracted with some fire drills this week, but I'll make it a priority to get the ixl changes committed next week. Thanks to you and everyone involved for getting this done. Jack On Sat, Feb 28, 2015 at 6:01 PM, Ryan Stone wrote: > I've just finished committing support for PCI Single Root I/O > Virtualization in the pci subsystem to head. This should be a no-op > for everyone right now, but there were some minor refactorings in the > pci code that could have a lingering bug. I did make sure to test > that it boots on a variety of systems (but only i386/amd64, as that's > all that I have access to). > > What's been committed to head is only the pci subsystem side of > things, along with the userland tools to configure SR-IOV (along with, > I'm happy to say, a full set of man pages). What's not in head yet > are any drivers making use of the infrastructure. Full support for > ixl(4) is complete and I've sent the patch to jfv@; I hope to see the > driver support committed soon. I don't have any word on timelines for > getting support in other drivers. Unfortunately adding SR-IOV support > to a driver is not trivial as the standard leaves a lot of the details > up to particular implementations (in the same way the the PCIe > standard does not define how to send a packet from a NIC; instead > defining how the PCIe device will expose its registers and whatnot, > and its up to the PCIe device and driver to understand how to poke at > the registers to send a packet). I have heard anecdotally that a > number of driver maintainers have been very interested in this work so > I hope that to see more drivers supported SR-IOV in the near future. > I encourage all driver maintainers to read over the new manpages and > contact me if they have any questions about the new infrastructure. > > Anybody interested in using SR-IOV should try to attend BSDCan 2015, > as I will be giving a talk on the subject. I intend to focus more on > the system administration side of configuring and using SR-IOV rather > than the details of implementing an SR-IOV driver. > > If anybody did an "svn up" half-way through my muddled series of > commits, sorry about the temporary breakage. My > buildworld/buildkernel on r279466 just completed successfully so > please make sure that you have at least that revision. If you still > have problems, please let me know. > > I do want to thank John Baldwin for advice about the PCI Subsystem and > newbus and Jack Vogel for his help with the Fortville NIC, including > getting me early access to the VF driver for testing purposes. Thanks > to everybody who reviewed the changes. Specially thanks to Mark > Johnston and Sean Mahood, who literally spent hours with me in a > meeting room reviewing the entire patch series last summer > (thankfully, those hours at least weren't consecutive). > > Above all, thanks to Sandvine Inc. for sponsoring this work. This is > definitely the biggest contribution we've ever made to FreeBSD and I > hope to see this kind of thing continue. > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: datapoints on 10G throughput with TCP ?
You can't get line rate with ixgbe, in what configuration/hardware? We surely do get line rate in validation here, but its sensitive to your hardware and config. Jack On Mon, Dec 5, 2011 at 2:28 PM, Luigi Rizzo wrote: > On Mon, Dec 05, 2011 at 11:15:09PM +0200, Daniel Kalchev wrote: > > > > On Dec 5, 2011, at 9:27 PM, Luigi Rizzo wrote: > > > > > - have two machines connected by a 10G link > > > - on one run "nuttcp -S" > > > - on the other one run "nuttcp -t -T 5 -w 128 -v the.other.ip" > > > > > > > Any particular tuning of FreeBSD? > > actually my point is first to see how good or bad are the defaults. > > I have noticed that setting hw.ixgbe.max_interrupt_rate=0 > (it is a tunable, you need to do it before loading the module) > improves the throughput by a fair amount (but still way below > line rate with 1500 byte packets). > > other things (larger windows) don't seem to help much. > > cheers > luigi > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: datapoints on 10G throughput with TCP ?
Set the storm threshold to 0, that will disable it, its going to throttle your performance when it happens. Jack On Tue, Dec 6, 2011 at 6:24 AM, Daniel Kalchev wrote: > Some tests with updated FreeBSD to 8-stable as of today, compared with the > previous run > > > > On 06.12.11 13:18, Daniel Kalchev wrote: > >> >> FreeBSD 8.2-STABLE #0: Wed Sep 28 11:23:59 EEST 2011 >> CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz (2403.58-MHz >> K8-class CPU) >> real memory = 51539607552 (49152 MB) >> blade 1: >> >> # nuttcp -S >> # nuttcp -t -T 5 -w 128 -v localhost >> nuttcp-t: v6.1.2: socket >> nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> localhost >> nuttcp-t: time limit = 5.00 seconds >> nuttcp-t: connect to 127.0.0.1 with mss=14336, RTT=0.044 ms >> nuttcp-t: send window size = 143360, receive window size = 71680 >> nuttcp-t: 8959.8750 MB in 5.02 real seconds = 1827635.67 KB/sec = >> 14971.9914 Mbps >> nuttcp-t: host-retrans = 0 >> nuttcp-t: 143358 I/O calls, msec/call = 0.04, calls/sec = 28556.81 >> nuttcp-t: 0.0user 4.9sys 0:05real 99% 106i+1428d 602maxrss 0+5pf 16+46csw >> >> nuttcp-r: v6.1.2: socket >> nuttcp-r: buflen=65536, nstream=1, port=5001 tcp >> nuttcp-r: accept from 127.0.0.1 >> nuttcp-r: send window size = 43008, receive window size = 143360 >> nuttcp-r: 8959.8750 MB in 5.17 real seconds = 1773171.07 KB/sec = >> 14525.8174 Mbps >> nuttcp-r: 219708 I/O calls, msec/call = 0.02, calls/sec = 42461.43 >> nuttcp-r: 0.0user 3.8sys 0:05real 76% 105i+1407d 614maxrss 1+17pf >> 95059+22csw >> > > New results: > > FreeBSD 8.2-STABLE #1: Tue Dec 6 13:51:01 EET 2011 > > > > # nuttcp -t -T 5 -w 128 -v localhost > nuttcp-t: v6.1.2: socket > nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> localhost > nuttcp-t: time limit = 5.00 seconds > nuttcp-t: connect to 127.0.0.1 with mss=14336, RTT=0.030 ms > > nuttcp-t: send window size = 143360, receive window size = 71680 > nuttcp-t: 12748.0625 MB in 5.02 real seconds = 2599947.38 KB/sec = > 21298.7689 Mbps > nuttcp-t: host-retrans = 0 > nuttcp-t: 203969 I/O calls, msec/call = 0.03, calls/sec = 40624.18 > nuttcp-t: 0.0user 4.9sys 0:05real 99% 106i+1428d 620maxrss 0+2pf 1+82csw > > > nuttcp-r: v6.1.2: socket > nuttcp-r: buflen=65536, nstream=1, port=5001 tcp > nuttcp-r: accept from 127.0.0.1 > nuttcp-r: send window size = 43008, receive window size = 143360 > nuttcp-r: 12748.0625 MB in 5.15 real seconds = 2536511.81 KB/sec = > 20779.1048 Mbps > nuttcp-r: 297000 I/O calls, msec/call = 0.02, calls/sec = 57709.75 > nuttcp-r: 0.1user 4.0sys 0:05real 81% 109i+1469d 626maxrss 0+15pf > 121136+34csw > > Noticeable improvement. > > > > >> blade 2: >> >> # nuttcp -t -T 5 -w 128 -v 10.2.101.12 >> nuttcp-t: v6.1.2: socket >> nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> 10.2.101.12 >> nuttcp-t: time limit = 5.00 seconds >> nuttcp-t: connect to 10.2.101.12 with mss=1448, RTT=0.059 ms >> nuttcp-t: send window size = 131768, receive window size = 66608 >> nuttcp-t: 1340.6469 MB in 5.02 real seconds = 273449.90 KB/sec = >> 2240.1016 Mbps >> nuttcp-t: host-retrans = 171 >> nuttcp-t: 21451 I/O calls, msec/call = 0.24, calls/sec = 4272.78 >> nuttcp-t: 0.0user 1.9sys 0:05real 39% 120i+1610d 600maxrss 2+3pf >> 75658+0csw >> >> nuttcp-r: v6.1.2: socket >> nuttcp-r: buflen=65536, nstream=1, port=5001 tcp >> nuttcp-r: accept from 10.2.101.11 >> nuttcp-r: send window size = 33304, receive window size = 131768 >> nuttcp-r: 1340.6469 MB in 5.17 real seconds = 265292.92 KB/sec = >> 2173.2796 Mbps >> nuttcp-r: 408764 I/O calls, msec/call = 0.01, calls/sec = 78992.15 >> nuttcp-r: 0.0user 3.3sys 0:05real 64% 105i+1413d 620maxrss 0+15pf >> 105104+102csw >> > > # nuttcp -t -T 5 -w 128 -v 10.2.101.11 > nuttcp-t: v6.1.2: socket > nuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> 10.2.101.11 > > nuttcp-t: time limit = 5.00 seconds > nuttcp-t: connect to 10.2.101.11 with mss=1448, RTT=0.055 ms > > nuttcp-t: send window size = 131768, receive window size = 66608 > nuttcp-t: 1964.8640 MB in 5.02 real seconds = 400757.59 KB/sec = 3283.0062 > Mbps > nuttcp-t: host-retrans = 0 > nuttcp-t: 31438 I/O calls, msec/call = 0.16, calls/sec = 6261.87 > nuttcp-t: 0.0user 2.7sys 0:05real 55% 112i+1501d 1124maxrss 1+2pf > 65+112csw > > > nuttcp-r: v6.1.2: socket > nuttcp-r: buflen=65536, nstream=1, port=5001 tcp > nuttcp-r: accept from 10.2.101.12 > > nuttcp-r: send window size = 33304, receive window size = 131768 > nuttcp-r: 1964.8640 MB in 5.15 real seconds =
Re: [head tinderbox] failure on sparc64/sparc64
Someone with sparc build experience want to look at this and maybe see something I'm missing, this error makes no sense to me, these are defined in ixgbe_type.h and I see nothing architecture sensitive?? Jack On Mon, Jan 30, 2012 at 10:51 AM, FreeBSD Tinderbox wrote: > TB --- 2012-01-30 17:49:37 - tinderbox 2.8 running on > freebsd-current.sentex.ca > TB --- 2012-01-30 17:49:37 - starting HEAD tinderbox run for > sparc64/sparc64 > TB --- 2012-01-30 17:49:37 - cleaning the object tree > TB --- 2012-01-30 17:49:45 - cvsupping the source tree > TB --- 2012-01-30 17:49:45 - /usr/bin/csup -z -r 3 -g -L 1 -h > cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile > TB --- 2012-01-30 17:50:20 - building world > TB --- 2012-01-30 17:50:20 - CROSS_BUILD_TESTING=YES > TB --- 2012-01-30 17:50:20 - MAKEOBJDIRPREFIX=/obj > TB --- 2012-01-30 17:50:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2012-01-30 17:50:20 - SRCCONF=/dev/null > TB --- 2012-01-30 17:50:20 - TARGET=sparc64 > TB --- 2012-01-30 17:50:20 - TARGET_ARCH=sparc64 > TB --- 2012-01-30 17:50:20 - TZ=UTC > TB --- 2012-01-30 17:50:20 - __MAKE_CONF=/dev/null > TB --- 2012-01-30 17:50:20 - cd /src > TB --- 2012-01-30 17:50:20 - /usr/bin/make -B buildworld > >>> World build started on Mon Jan 30 17:50:21 UTC 2012 > >>> Rebuilding the temporary build tree > >>> stage 1.1: legacy release compatibility shims > >>> stage 1.2: bootstrap tools > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3: cross tools > >>> stage 4.1: building includes > >>> stage 4.2: building libraries > >>> stage 4.3: make dependencies > >>> stage 4.4: building everything > >>> World build completed on Mon Jan 30 18:46:15 UTC 2012 > TB --- 2012-01-30 18:46:15 - generating LINT kernel config > TB --- 2012-01-30 18:46:15 - cd /src/sys/sparc64/conf > TB --- 2012-01-30 18:46:15 - /usr/bin/make -B LINT > TB --- 2012-01-30 18:46:15 - cd /src/sys/sparc64/conf > TB --- 2012-01-30 18:46:15 - /usr/sbin/config -m LINT > TB --- 2012-01-30 18:46:15 - building LINT kernel > TB --- 2012-01-30 18:46:15 - CROSS_BUILD_TESTING=YES > TB --- 2012-01-30 18:46:15 - MAKEOBJDIRPREFIX=/obj > TB --- 2012-01-30 18:46:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2012-01-30 18:46:15 - SRCCONF=/dev/null > TB --- 2012-01-30 18:46:15 - TARGET=sparc64 > TB --- 2012-01-30 18:46:15 - TARGET_ARCH=sparc64 > TB --- 2012-01-30 18:46:15 - TZ=UTC > TB --- 2012-01-30 18:46:15 - __MAKE_CONF=/dev/null > TB --- 2012-01-30 18:46:15 - cd /src > TB --- 2012-01-30 18:46:15 - /usr/bin/make -B buildkernel KERNCONF=LINT > >>> Kernel build for LINT started on Mon Jan 30 18:46:15 UTC 2012 > >>> stage 1: configuring the kernel > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3.1: making dependencies > >>> stage 3.2: building everything > [...] > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions > -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. > -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > -include opt_global.h -fno-common -finline-limit=15000 --param > inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin > -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror > /src/sys/dev/ixgbe/ixgbe_mbx.c -I/src/sys/dev/ixgbe > cc1: warnings being treated as errors > /src/sys/dev/ixgbe/ixgbe_mbx.c: In function 'ixgbe_obtain_mbx_lock_pf': > /src/sys/dev/ixgbe/ixgbe_mbx.c:629: warning: implicit declaration of > function 'IXGBE_PFMAILBOX' > /src/sys/dev/ixgbe/ixgbe_mbx.c:629: warning: nested extern declaration of > 'IXGBE_PFMAILBOX' [-Wnested-externs] > /src/sys/dev/ixgbe/ixgbe_mbx.c: In function 'ixgbe_write_mbx_pf': > /src/sys/dev/ixgbe/ixgbe_mbx.c:667: warning: implicit declaration of > function 'IXGBE_PFMBMEM' > /src/sys/dev/ixgbe/ixgbe_mbx.c:667: warning: nested extern declaration of > 'IXGBE_PFMBMEM' [-Wnested-externs] > *** Error code 1 > > Stop in /obj/sparc64.sparc64/src/sys/LINT. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2012-01-30 18:51:42 - WARNING: /usr/bin/make returned exit code 1 > TB --- 2012-01-30 18:51:42 - ERROR: failed to build LINT kernel > TB --- 2012-01-30 18:51:42 - 3062.26 us
Re: FreeBSD 10-CURRENT/amd64: revision 230789: [...]
Yes, it was. Now if I can just figure out what's going on with sparc....
Jack
On Mon, Jan 30, 2012 at 3:11 PM, Glen Barber wrote:
> On Mon, Jan 30, 2012 at 11:55:48PM +0100, O. Hartmann wrote:
> > The follwoing error occurs hwen trying to compile a kernel (make
> > buildworld works fine):
> >
> > objcopy --strip-debug if_ixgb.ko
> > ===> ixgbe (all)
> > clang -O2 -pipe -O2 -fno-strict-aliasing -pipe -pipe -O3
> > -fno-strict-aliasing -march=native -DSMP -DIXGBE_FDIR -D_KERNEL
> > -DKLD_MODULE -nostdinc -I/usr/src/sys/modules/ixgbe/../../dev/ixgbe
> > -DHAVE_KERNEL_OPTION_HEADERS -include
> > /usr/obj/usr/src/sys/THOR/opt_global.h -I. -I@ -I@/contrib/altq
> > -fno-common -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/THOR
> > -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float
> > -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector
> > -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls
> > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
> > -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign
> > -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option
> > -Wno-error-tautological-compare -Wno-error-empty-body
> > -Wno-error-parentheses-equality -c
> > /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe.c
> > In file included from
> /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe.c:40:
> > In file included from
> /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe.h:96:
> > In file included from
> > /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe_api.h:38:
> > In file included from
> > /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe_type.h:38:
> > /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe_osdep.h:109:19: error:
> > typedef redefinition with different types ('boolean_t' (aka 'int') vs
> > '_Bool')
> > typedef boolean_t bool;
> > ^
> > @/sys/types.h:271:15: note: previous definition is here
> > typedef _Bool bool;
> > ^
> > 1 error generated.
> > *** Error code 1
> >
> > Stop in /usr/src/sys/modules/ixgbe.
> > *** Error code 1
> >
> > Stop in /usr/src/sys/modules.
> > *** Error code 1
> >
> > Stop in /usr/obj/usr/src/sys/THOR.
> > *** Error code 1
> >
> > Stop in /usr/src.
> > *** Error code 1
> >
> > Stop in /usr/src.
> >
>
> I believe this was just fixed:
>
> http://svn.freebsd.org/changeset/base/230790
>
> Glen
>
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: make installworld broke / how to recover
maybe try a clean buildworld, update /usr/src to the latest version, rm -rf /usr/obj, then make buildworld && make installworld && make kernel and see if that fixes the issue? On Thu, Feb 22, 2018 at 2:57 AM, John wrote: > Hello, > > When trying to upgrade from 11-stable to 12-current, make installworld > broke. The OS is mainly on a ssd, there is zfs installed (usr/src is on > zfs). Is there a guide somewhere that shows how to recover from this > situation? both 11.1 and 12-current kernels are bootable. I can just blat > the system and install from scratch but that would mean i've not learned > how to fix it. I have subsequently tried make buildworld again but it bais > out with this error: > > # > > objcopy --only-keep-debug xinstall.full install.debug > objcopy --strip-debug --add-gnu-debuglink=install.debug xinstall.full > xinstall > sh /storage/usr/src/tools/install.sh -s -o root -g wheel -m 555 > xinstall /obj/storage/usr/src/amd64.amd64/tmp/legacy/usr/bin/install > sh /storage/usr/src/tools/install.sh -o root -g wheel -m 444 > install.debug /obj/storage/usr/src/amd64.amd64/tmp/legacy/usr/lib/ > debug/usr/bin/install.debug > install: install.debug: Inappropriate file type or format > *** Error code 71 > > Stop. > make[3]: stopped in /storage/usr/src/usr.bin/xinstall > *** Error code 1 > > Stop. > make[2]: stopped in /storage/usr/src > *** Error code 1 > > Stop. > make[1]: stopped in /storage/usr/src > *** Error code 1 > > Stop. > make: stopped in /storage/usr/src > > # > > thanks, > > -- > John > tech-li...@zyxst.net > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X
I also have the exact same panic on a Dell motherboard with a Haswell processor. On Sat, Sep 19, 2020 at 11:05 PM monochrome wrote: > > I have confirmed that r365487 is the last kernel that will boot on my > 2400G. These are the files changed between r365487 and r365488: > > Usys/vm/phys_pager.c > Usys/vm/vm_object.c > Usys/vm/vm_object.h > Usys/vm/vm_pager.h > > > > On 9/18/20 8:57 AM, Rainer Hurling wrote: > > Hi, > > I am AFK until Sunday, so can't investigate ATM. > > And no, I haven't solved it until now. Thanks for your report. > > Rainer > > > > Am 18. September 2020 00:38:31 MESZ schrieb monochrome > > : > >> > >> forgot you > >> > >> Forwarded Message > >> Subject: Re: r365488 page faults on AMD Ryzen 9 3950X > >> Date: Thu, 17 Sep 2020 17:03:49 -0400 > >> From: monochrome > >> To: freebsd-current@freebsd.org > >> > >> I am also having this problem. Have you resolved it? Mine is a Ryzen 5 > >> 2400G > >> > >> On 9/12/20 5:22 AM, Rainer Hurling wrote: > >>> Since r365488 (and above until recent) my box breaks with the following > >>> error when starting: > >>> > >>> Fatal trap 12: page fault while in kernel mode > >>> cpuid = 31; apic id = 1f > >>> fault virtual address = 0x0 > >>> fault code = supervisor read data, page not present > >>> instruction pointer = 0x20:0x808f452b > >>> stack pointer = 0x28:0x81711800 > >>> frame pointer = 0x28:0x81711800 > >>> code segment= base 0x0, limit 0xf, type 0x1b > >>> = DPL 0, pres 1, long 1, def32 0, gran 1 > >>> processor eflags= interrupt enabled, resume, IOPL = 0 > >>> current process = 0 (swapper) > >>> trap number = 12 > >>> panic: page fault > >>> cpuid = 31 > >>> time = 1 > >>> > >>> > >>> > >>> Some infos about the system, the page fault occurs: > >>> > >>> CPU: AMD Ryzen 9 3950X 16-Core Processor (3493.50-MHz > >>> K8-class CPU) > >>> Origin="AuthenticAMD" Id=0x870f10 Family=0x17 Model=0x71 > >>> Stepping=0 > >>> Features=0x178bfbff > >>> Features2=0x7ed8320b > >>> AMD Features=0x2e500800 > >>> AMD > >>> Features2=0x75c237ff > >>> Structured Extended > >>> Features=0x219c91a9 > >>> Structured Extended Features2=0x44 > >>> XSAVE Features=0xf > >>> AMD Extended Feature Extensions ID > >>> EBX=0x108b657 > >>> SVM: (disabled in BIOS) NP,NRIP,VClean,AFlush,DAssist,NAsids=32768 > >>> TSC: P-state invariant, performance statistics > >>> real memory = 68717379584 (65534 MB) > >>> avail memory = 66756149248 (63663 MB) > >>> Event timer "LAPIC" quality 600 > >>> > >>> > >>> #cat /etc/sysctl.conf > >>> security.bsd.map_at_zero=1 > >>> kern.module_path=/boot/kernel;/boot/modules;/usr/local/modules > >>> kern.evdev.rcpt_mask=6 > >>> kern.maxfiles=49312 > >>> kern.ipc.shm_allow_removed=1 > >>> kern.ipc.maxsockbuf=16777216 > >>> vfs.usermount=1 > >>> net.inet.tcp.rfc1323=1 > >>> net.inet.tcp.sack.enable=1 > >>> net.inet.tcp.sendbuf_auto=1 > >>> net.inet.tcp.recvbuf_auto=1 > >>> net.inet.tcp.sendbuf_max=16777216 > >>> net.inet.tcp.recvbuf_max=16777216 > >>> net.inet6.ip6.use_tempaddr=1 > >>> net.inet6.ip6.prefer_tempaddr=1 > >>> net.local.stream.recvspace=65536 > >>> net.local.stream.sendspace=65536 > >>> > >>> > >>> Please let me know, if I should provide more info or test something. > >>> Thanks in advance, > >>> Rainer > >>> ___ > >>> freebsd-current@freebsd.org mailing list > >>> https://lists.freebsd.org/mailman/listinfo/freebsd-current > >>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > >>> > >> ___ > >> freebsd-current@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: How should a driver shutdown a taskqueue on detach?
But if you've disabled interrupts why would an "interrupt-handling task" even run?? Jack On Wed, Jul 1, 2015 at 12:44 PM, Ryan Stone wrote: > I'm trying to figure out how a driver is supposed to shut down its > interrupt-handling taskqueue when it detaches. taskqueue(9) recommends > disabling interrupts, draining each task and then freeing the taskqueue. > The problem that I have is the interrupt-handling tasks will sometimes > re-enable interrupts on the device. Is there a better way than using some > kind of flag internally in the driver to note that a detach is in progress > that the interrupt handlers will have to check before enabling interrupts? > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: How should a driver shutdown a taskqueue on detach?
Ya, that seems elegant. Jack On Wed, Jul 1, 2015 at 3:28 PM, Ryan Stone wrote: > On Wed, Jul 1, 2015 at 5:32 PM, Konstantin Belousov > wrote: > >> Do you mean, you want some KPI like >> boolean taskqueue_is_draining(struct taskqueue *p); >> so that e.g. executed task could see if it is executing in the >> shutdown state ? > > > I'd prefer a KPI that stops a taskqueue from accepting new tasks (and > drops attempts to enqueue on the floor). Then I could do something like: > > taskqueue_stop() > disable_interrupts() > taskqueue_drain_all() > taskqueue_free() > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Build error on current@r296308: 'yacc.h' file not found
I have the same compilation error when I tried to build current today as well. On Wed, Mar 2, 2016 at 11:48 AM, Kurt Jaeger wrote: > Hi! > >> Today, I upgraded to r296308 and had this failure during buildworld: >> >> ===> usr.bin/mkesdb_static (obj,build-tools) >> cc -O2 -pipe -I/usr/src/usr.bin/mkesdb_static >> -I/usr/src/usr.bin/mkesdb_static/../mkesdb >> -I/usr/src/usr.bin/mkesdb_static/../../lib/libc/iconv -g -std=gnu99 >> -Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include -c lex.c -o >> lex.o >> /usr/src/usr.bin/mkesdb_static/../mkesdb/lex.l:44:10: fatal error: 'yacc.h' >> file not found >> #include "yacc.h" >> 1 error generated. >> *** Error code 1 >> >> A 'script' output is available at http://people.freebsd.org/~pi/logs/src-up-2 >> >> Is it just me or ... ? > > If I change the sequence in > > /usr/src/usr.bin/mkesdb/Makefile.inc > > for line > > SRCS+= lex.l yacc.y > > to > > SRCS+= yacc.y lex.l > > it builds ? That file was last touched 4 years ago ? > > -- > p...@opsec.eu+49 171 3101372 4 years to > go ! > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Opteron 6100-series "Magny-Cours"
I have a few still sitting in a corner with FreeBSD 7 or 8 on them. Someday i might put them back on with FreeBSD but not anytime soon Sent from far away... > On Mar 25, 2017, at 11:02 AM, Andriy Gapon wrote: > > > Does anyone [still] use Opteron 6100-series / "Magny-Cours" processors with > FreeBSD? > > > -- > Andriy Gapon > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: em0 on S3420 chipset (was Re: em0 on H55 chipset problems)
Yes, I need to get the code MFC'd anyway, sorry, I just am constantly fighting fires lately it seems :( I'll try to get on it. Jack On Mon, Feb 22, 2010 at 11:46 AM, Mike Tancsa wrote: > > Hi Jack, >Any chance on MFC'ing this version of the em driver ? I have another > MB that does not work with RELENG_8, only HEAD. Its an Intel branded server > motherboard with two onboard NICs. S3420GPC. One of the em nics shows up on > RELENG_8, but not both. > > em1 shows up on RELENG_8, but em0 does not attach on RELENG_8. dmesg below > from a snapshot of HEAD from this morning. I guess the onboard NICs are two > different types of em nics? BTW, Is one "better" than the other ? > > e...@pci0:0:25:0:class=0x02 card=0x34ec8086 chip=0x10ef8086 > rev=0x05 hdr=0x00 >vendor = 'Intel Corporation' >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 13[e0] = PCI Advanced Features: FLR TP > > e...@pci0:3:0:0: class=0x02 card=0x34ec8086 chip=0x10d38086 rev=0x00 > hdr=0x00 >vendor = 'Intel Corporation' >class = network >subclass = ethernet >cap 01[c8] = powerspec 2 supports D0 D3 current D0 >cap 05[d0] = MSI supports 1 message, 64 bit >cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) >cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled > > > FreeBSD 9.0-CURRENT #3: Fri Feb 5 11:43:38 EST 2010 >mdtan...@ich10.sentex.ca:/usr/HEAD/obj/usr/HEAD/src/sys/alix i386 > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz (2666.65-MHz 686-class > CPU) > Origin = "GenuineIntel" Id = 0x106e5 Stepping = 5 > > > Features=0xbfebfbff > > > Features2=0x98e3fd > AMD Features=0x2810 > AMD Features2=0x1 > TSC: P-state invariant > real memory = 4294967296 (4096 MB) > avail memory = 2582040576 (2462 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > FreeBSD/SMP: 1 package(s) x 4 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 2 > cpu2 (AP): APIC ID: 4 > cpu3 (AP): APIC ID: 6 > ioapic0 irqs 0-23 on motherboard > lapic0: Forcing LINT1 to edge trigger > kbd1 at kbdmux0 > cryptosoft0: on motherboard > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 > acpi_hpet0: iomem 0xfed0-0xfed003ff on > acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 900 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: irq 16 at device 5.0 on pci0 > pci1: on pcib1 > vgapci0: port 0x2000-0x20ff mem > 0xb000-0xbfff,0xc1a0-0xc1a0 irq 16 at device 0.0 on pci1 > pci1: at device 0.1 (no driver attached) > pci0: at device 8.0 (no driver attached) > pci0: at device 8.1 (no driver attached) > pci0: at device 8.2 (no driver attached) > pci0: at device 8.3 (no driver attached) > pci0: at device 16.0 (no driver attached) > pci0: at device 16.1 (no driver attached) > em0: port 0x3040-0x305f mem > 0xc1b0-0xc1b1,0xc1b25000-0xc1b25fff irq 20 at device 25.0 on pci0 > em0: Using MSI interrupt > em0: [FILTER] > em0: Ethernet address: 00:15:17:c8:4b:99 > ehci0: mem 0xc1b22000-0xc1b223ff irq > 21 at device 26.0 on pci0 > ehci0: [ITHREAD] > usbus0: EHCI version 1.0 > usbus0: on ehci0 > pcib2: irq 16 at device 28.0 on pci0 > pci2: on pcib2 > pcib3: irq 16 at device 28.4 on pci0 > pci3: on pcib3 > em1: port 0x1000-0x101f mem > 0xc190-0xc191,0xc192-0xc1923fff irq 16 at device 0.0 on pci3 > em1: Using MSIX interrupts > em1: [ITHREAD] > em1: [ITHREAD] > em1: [ITHREAD] > em1: Ethernet address: 00:15:17:c8:4b:98 > pcib4: irq 18 at device 28.6 on pci0 > pci4: on pcib4 > pcib5: irq 19 at device 28.7 on pci0 > pci5: on pcib5 > ehci1: mem 0xc1b21000-0xc1b213ff irq > 23 at device 29.0 on pci0 > ehci1: [ITHREAD] > usbus1: EHCI version 1.0 > usbus1: on ehci1 > pcib6: at device 30.0 on pci0 > pci6: on pcib6 > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port > 0x3068-0x306f,0x3074-0x3077,0x3060-0x3067,0x3070-0x3073,0x3020-0x303f mem > 0xc1b2-0xc1b207ff irq 18 at device 31.2 on pci0 > atapci0: [ITHREAD] > atapci0: AHCI v1.30 controller with 6 3Gbps ports, PM not supported > ata2: on atapci0 > ata2: [ITHREAD] > ata3: on atapci0 > ata3: [ITHREAD] > a
Re: Intel H55 and em0
The device subfamily on those motherboards is called PCH, and its only in the em driver as of last December, The CVS delta of if_em is 1.27. You can either update to STABLE/8 or CURRENT. If you wish to just pull the e1000 driver directory it should work fine in 8.0 RELEASE also. Cheers, Jack On Wed, Mar 31, 2010 at 11:29 PM, David Ehrmann wrote: > I recently picked up a H55-based motherboard, and the ethernet interface > isn't autodetected. dmesg lists it as the following: > > pci0: at device 25.0 (no driver attached) > > And pciconf lists this: > > no...@pci0:0:25:0: class=0x02 card=0x8086 chip=0x10ef8086 > rev=0x06 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > > > I'm actually not sure it's an em device, but it's definitely gigabit, and > googling suggests that others have recently run into the same issue. > > Since I'll probably have to recompile, is this currently working in recent > builds of 8.0? This was just a vanilla 8.0 release image. Would some > simple change tell the driver to recognize this card? > > Thanks in advance. > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Intel H55 and em0
OH, as to my last statement, the code in CURRENT will NOT work on 8.0 RELEASE, it would require a change to sys/conf/files, and it also has a fix in the stack that is not in RELEASE. SO taking the latest would require you take the whole tree. Jack On Wed, Mar 31, 2010 at 11:39 PM, Jack Vogel wrote: > The device subfamily on those motherboards is called PCH, and its only in > the em driver as of > last December, The CVS delta of if_em is 1.27. You can either update to > STABLE/8 or CURRENT. > If you wish to just pull the e1000 driver directory it should work fine in > 8.0 RELEASE also. > > Cheers, > > Jack > > > > On Wed, Mar 31, 2010 at 11:29 PM, David Ehrmann wrote: > >> I recently picked up a H55-based motherboard, and the ethernet interface >> isn't autodetected. dmesg lists it as the following: >> >> pci0: at device 25.0 (no driver attached) >> >> And pciconf lists this: >> >> no...@pci0:0:25:0: class=0x02 card=0x8086 chip=0x10ef8086 >> rev=0x06 hdr=0x00 >> vendor = 'Intel Corporation' >> class = network >> subclass = ethernet >> >> >> I'm actually not sure it's an em device, but it's definitely gigabit, and >> googling suggests that others have recently run into the same issue. >> >> Since I'll probably have to recompile, is this currently working in recent >> builds of 8.0? This was just a vanilla 8.0 release image. Would some >> simple change tell the driver to recognize this card? >> >> Thanks in advance. >> ___ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org >> " >> > > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Re: Intel H55 and em0
Yup, gonna MFC the code from CURRENT to STABLE/8 first thing next week, at least that's my plan. Sorry, I thought STABLE/8 already had PCH in it, my bad. I checked and the ALTQ fix is in the tree, so pulling the directory from HEAD and adding it to STABLE/8 should work fine. MFC will be coming first thing Monday. Jack On Thu, Apr 1, 2010 at 9:11 AM, Jan Henrik Sylvester wrote: > On 01/-10/-28163 20:59, Jack Vogel wrote: > >> OH, as to my last statement, the code in CURRENT will NOT work on 8.0 >> RELEASE, >> it would require a change to sys/conf/files, and it also has a fix in the >> stack that is not >> in RELEASE. SO taking the latest would require you take the whole tree. >> >> Jack >> >> >> On Wed, Mar 31, 2010 at 11:39 PM, Jack Vogel wrote: >> >> The device subfamily on those motherboards is called PCH, and its only in >>> the em driver as of >>> last December, The CVS delta of if_em is 1.27. You can either update to >>> STABLE/8 or CURRENT. >>> If you wish to just pull the e1000 driver directory it should work fine >>> in >>> 8.0 RELEASE also. >>> >>> Cheers, >>> >>> Jack >>> >> > In your correction, you did not really mention 8-STABLE, you only warn > about putting e1000 from CURRENT to 8.0-RELEASE. > > I got the same problem: > http://lists.freebsd.org/pipermail/freebsd-mobile/2010-March/011952.html > > Since I did not get a reply, I put the whole e1000 directory from CURRENT > into 8-STABLE. > > Is there any problem with that? (It _seems_ to work so far.) > > Are you going to MFC the PCH devices to 8-STABLE any time soon? > > Thanks, > Jan Henrik > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: LOR on em in HEAD ( was Re: em driver regression
Someone else also pointed this out. I'm dubious about its claim. This happens because there is an RX lock taken in rxeof, its held thru the call into the stack, it then encounters another lock there and hence this complaint. I've had the RX hold as it is for a long while and would rather not have to give it up, can someone look at it and advise? Cheers, Jack On Fri, Apr 9, 2010 at 12:00 PM, Mike Tancsa wrote: > While testing an i5 box with HEAD checked out from this morning, bringing > up the second NIC generated this LOR on the console > > em1: link state changed to UP > lock order reversal: > 1st 0xc5dc7c10 em1:rx(1) (em1:rx(1)) @ > /usr/HEAD/src/sys/modules/em/../../dev/e1000/if_em.c:4089 > 2nd 0xc0f7e88c udp (udp) @ /usr/HEAD/src/sys/netinet/udp_usrreq.c:454 > KDB: stack backtrace: > db_trace_self_wrapper(c0cb4d33,c5b72a70,c08e4d65,c08d50db,c0cb7d58,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(c08d50db,c0cb7d58,c5d31a98,c5d2cb60,c5b72acc,...) at > kdb_backtrace+0x29 > _witness_debugger(c0cb7d58,c0f7e88c,c0c9cf0b,c5d2cb60,c0cd04ca,...) at > _witness_debugger+0x25 > witness_checkorder(c0f7e88c,1,c0cd04ca,1c6,0,...) at > witness_checkorder+0x839 > _rw_rlock(c0f7e88c,c0cd04ca,1c6,c5d33088,c5e8be24,...) at _rw_rlock+0x9c > udp_input(c67faa00,14,0,c5e8bd80,c0dfa860,...) at udp_input+0x246 > ip_input(c67faa00,c5f2f380,c5b72be8,c07463b6,c0dfa860,...) at > ip_input+0x606 > netisr_dispatch_src(1,0,c67faa00,c5b72c20,c0954bc1,...) at > netisr_dispatch_src+0xcd > netisr_dispatch(1,c67faa00,c6018c00,c6018c00,c6852800,...) at > netisr_dispatch+0x20 > ether_demux(c6018c00,c67faa00,3,0,3,...) at ether_demux+0x1a1 > ether_input(c6018c00,c67faa00,c11a0e17,ff9,64,...) at ether_input+0x365 > em_rxeof(c5e8bd80,109,c6016180,0,c5b72cc8,...) at em_rxeof+0x13c > em_msix_rx(c5dc7c00,c5b72cc8,c088eb14,c0e133c0,c60342b8,...) at > em_msix_rx+0x25 > intr_event_execute_handlers(c5d807f8,c6034280,c0cacd7e,533,c60342f0,...) at > intr_event_execute_handlers+0x125 > ithread_loop(c603b4a0,c5b72d38,c0cacaed,343,c5d807f8,...) at > ithread_loop+0x9f > fork_exit(c0877800,c603b4a0,c5b72d38) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xc5b72d70, ebp = 0 --- > > 0(i5b)# uname -a > FreeBSD i5b.sentex.ca 9.0-CURRENT FreeBSD 9.0-CURRENT #2: Fri Apr 9 > 11:56:25 EDT 2010 > mdtan...@ich10.sentex.ca:/usr/HEAD/obj/usr/HEAD/src/sys/GENERIC > i386 > 0(i5b)# > > e...@pci0:0:25:0:class=0x02 card=0x34ec8086 chip=0x10ef8086 > rev=0x05 hdr=0x00 >vendor = 'Intel Corporation' >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 13[e0] = PCI Advanced Features: FLR TP > e...@pci0:3:0:0: class=0x02 card=0x34ec8086 chip=0x10d38086 rev=0x00 > hdr=0x00 >vendor = 'Intel Corporation' >device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' >class = network >subclass = ethernet >cap 01[c8] = powerspec 2 supports D0 D3 current D0 >cap 05[d0] = MSI supports 1 message, 64 bit >cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) >cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled > > > 0(i5b)# vmstat -i > interrupt total rate > irq4: uart0 6156 3 > irq8: rtc 224879127 > irq21: ehci02662 1 > irq23: ehci13674 2 > cpu0: timer 1754210998 > irq256: em010778 6 > irq257: em1 331 0 > irq258: em14 0 > irq260: em14 0 > irq261: em18 0 > irq262: ahci0 69 0 > cpu3: timer 1753938998 > cpu2: timer 1753932998 > cpu1: timer 1753886998 > Total7264531 4134 > 0(i5b)# > > CPU: Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz (2666.65-MHz 686-class > CPU) > Origin = "GenuineIntel" Id = 0x106e5 Family = 6 Model = 1e Stepping = > 5 > > > Features=0xbfebfbff > > > Features2=0x98e3fd > AMD Features=0x2810 > AMD Features2=0x1 > TSC: P-state invariant > real memory = 4294967296 (4096 MB) > avail memory = 2577711104 (2458 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs >
Re: LOR on em in HEAD ( was Re: em driver regression
On Fri, Apr 9, 2010 at 1:13 PM, Pyun YongHyeon wrote: > On Fri, Apr 09, 2010 at 12:09:24PM -0700, Jack Vogel wrote: > > Someone else also pointed this out. I'm dubious about its claim. > > I can't reproduce the LOR with latest em(4)(r206429). > > Hmmm, wonder what changed that effected that, oh well that's good :) Jack ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: LOR on em in HEAD ( was Re: em driver regression
Don't know, but I would just ignore it, I think its a false warning anyway. Jack On Fri, Apr 9, 2010 at 2:05 PM, Mike Tancsa wrote: > At 04:13 PM 4/9/2010, Pyun YongHyeon wrote: > >> On Fri, Apr 09, 2010 at 12:09:24PM -0700, Jack Vogel wrote: >> > Someone else also pointed this out. I'm dubious about its claim. >> >> I can't reproduce the LOR with latest em(4)(r206429). >> > > > I still get it for some reason > > 1st 0xc5dc7610 em1:rx(1) (em1:rx(1)) @ > /usr/HEAD/src/sys/modules/em/../../dev/e1000/if_em.c:4087 > 2nd 0xc0f7df0c udp (udp) @ /usr/HEAD/src/sys/netinet/udp_usrreq.c:454 > KDB: stack backtrace: > db_trace_self_wrapper(c0cb4313,c5b72a64,c08e4305,c08d467b,c0cb7338,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(c08d467b,c0cb7338,c5d31a98,c5d2cb60,c5b72ac0,...) at > kdb_backtrace+0x29 > _witness_debugger(c0cb7338,c0f7df0c,c0c9c4eb,c5d2cb60,c0ccfaf7,...) at > _witness_debugger+0x25 > witness_checkorder(c0f7df0c,1,c0ccfaf7,1c6,0,...) at > witness_checkorder+0x839 > _rw_rlock(c0f7df0c,c0ccfaf7,1c6,c5d33088,c5e8be24,...) at _rw_rlock+0x9c > udp_input(c6905900,14,0,c5e8bd80,c0df9ee0,...) at udp_input+0x246 > ip_input(c6905900,c5f39240,c5b72bdc,c0745956,c0df9ee0,...) at > ip_input+0x606 > netisr_dispatch_src(1,0,c6905900,c5b72c14,c0954161,...) at > netisr_dispatch_src+0xcd > netisr_dispatch(1,c6905900,c6018c00,c6018c00,c6925800,...) at > netisr_dispatch+0x20 > ether_demux(c6018c00,c6905900,3,0,3,...) at ether_demux+0x1a1 > ether_input(c6018c00,c6905900,c119f2d7,ff7,63,...) at ether_input+0x365 > em_rxeof(c5e8bd80,109,c6016180,0,c5b72cc8,...) at em_rxeof+0x133 > em_msix_rx(c5dc7600,c5b72cc8,c088e0b4,c0e13740,c60342b8,...) at > em_msix_rx+0x25 > intr_event_execute_handlers(c5d807f8,c6034280,c0cac35e,533,c60342f0,...) at > intr_event_execute_handlers+0x125 > ithread_loop(c603b4a0,c5b72d38,c0cac0cd,343,c5d807f8,...) at > ithread_loop+0x9f > fork_exit(c0876da0,c603b4a0,c5b72d38) at fork_exit+0xb8 > > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xc5b72d70, ebp = 0 --- > > Perhaps because multi-queue is still enabled ? > > > 0(i5b)% vmstat -i > interrupt total rate > irq4: uart0 6637 28 > irq21: ehci0 382 1 > irq23: ehci1 615 2 > cpu0: timer 462573 1993 > irq256: em0 7640 32 > irq257: em15 0 > irq258: em16 0 > > irq261: em12 0 > irq262: ahci0 69 0 > cpu3: timer 461507 1989 > cpu2: timer 460985 1987 > cpu1: timer 461545 1989 > Total1861966 8025 > 0(i5b)% > > > em0: port 0x3040-0x305f mem > 0xc1b0-0xc1b1,0xc1b25000-0xc1b25fff irq 20 at device 25.0 on pci0 > em0: Using MSI interrupt > em0: [FILTER] > em0: Ethernet address: 00:15:17:c8:4b:99 > ehci0: mem 0xc1b22000-0xc1b223ff irq > 21 at device 26.0 on pci0 > ehci0: [ITHREAD] > usbus0: EHCI version 1.0 > usbus0: on ehci0 > pcib2: irq 16 at device 28.0 on pci0 > pci2: on pcib2 > pcib3: irq 16 at device 28.4 on pci0 > pci3: on pcib3 > em1: port 0x1000-0x101f mem > 0xc190-0xc191,0xc192-0xc1923fff irq 16 at device 0.0 on pci3 > em1: Using MSIX interrupts with 5 vectors > em1: [ITHREAD] > em1: [ITHREAD] > em1: [ITHREAD] > em1: [ITHREAD] > em1: [ITHREAD] > em1: Ethernet address: 00:15:17:c8:4b:98 > > > > > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications,m...@sentex.net > Providing Internet since 1994www.sentex.net > Cambridge, Ontario Canada www.sentex.net/mike > > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: LOR on em in HEAD ( was Re: em driver regression
Added the missing locks around calls to rxeof and checked it in a minute ago. Sorry guys! Jack On Sat, Apr 10, 2010 at 9:05 AM, Bjoern A. Zeeb < bzeeb-li...@lists.zabbadoz.net> wrote: > On Sat, 10 Apr 2010, Mike Tancsa wrote: > > Hi Mike, > > > At 05:11 PM 4/9/2010, Jack Vogel wrote: >> >>> Don't know, but I would just ignore it, I think its a false warning >>> anyway. >>> >> >> OK. I updated to HEAD as of this AM, but now I get a panic at bootup >> >> ... > > Trying to mount root from nfs: >> NFS ROOT: 10.255.255.1:/usr/home/pxe9/ >> panic: mutex em0:rx(0) not owned at >> /usr/HEAD/src/sys/modules/em/../../dev/e1000/if_em.c:4093 >> cpuid = 3 >> KDB: enter: panic >> [ thread pid 0 tid 100032 ] >> Stopped at kdb_enter+0x3a: movl$0,kdb_why >> db> bt >> Tracing pid 0 tid 100032 td 0xc5f5bb40 >> kdb_enter(c0cb0e9d,c0cb0e9d,c0caf56e,c5b2ac28,3,...) at kdb_enter+0x3a >> panic(c0caf56e,c6002024,c11a0357,ffd,c5b2ac7c,...) at panic+0x136 >> _mtx_assert(c6002010,4,c11a0357,ffd,64,...) at _mtx_assert+0x87 >> em_rxeof(246,c5ff7d98,c5b2aca8,c088e194,c5ff7d98,...) at em_rxeof+0x3b >> em_handle_que(c6006000,1,c0cb5c9c,4f,c5ff7d98,...) at em_handle_que+0x38 >> taskqueue_run(c5ff7d80,c5ff7d98,c0ca6410,0,c0caf5f6,...) at >> taskqueue_run+0x103 >> taskqueue_thread_loop(c600a520,c5b2ad38,c0cac192,343,c0e0ce20,...) at >> taskqueue_thread_loop+0x68 >> fork_exit(c08dcde0,c600a520,c5b2ad38) at fork_exit+0xb8 >> fork_trampoline() at fork_trampoline+0x8 >> --- trap 0, eip = 0, esp = 0xc5b2ad70, ebp = 0 --- >> db> >> > > > This is a bug that seems to only happen in the Kitchener area as I hit > it with a machine there just a few minutes ago as well. > > This one has fixed it for me: > http://lists.freebsd.org/pipermail/svn-src-head/2010-April/016249.html > > /bz > > -- > Bjoern A. Zeeb It will not break if you know what you are doing. > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: LOR on em in HEAD ( was Re: em driver regression
What's disabled is the drbr stuff in the stack, that will not keep the 82574 from initializing MSIX and multiple internal queues, if you have that adapter I would suggest you #define EM_MULTIQUEUE somewhere (Makefile, if_em.h or if_em.c) since I believe its the one place where you will benefit. At least try it and see. Jack On Sat, Apr 10, 2010 at 3:07 PM, Mike Tancsa wrote: > At 03:29 PM 4/10/2010, Jack Vogel wrote: > >> Added the missing locks around calls to rxeof and checked it in a minute >> ago. >> >> Sorry guys! >> > > Looks good for me now. BTW, I thought the multi-queue was supposed to be > disabled on the em nic ? > > > > em0: port 0x3040-0x305f mem > 0xc1b0-0xc1b1,0xc1b25000-0xc1b25fff irq 20 at device 25.0 on pci0 > em0: Using MSI interrupt > em0: [FILTER] > em0: Ethernet address: 00:15:17:c8:4b:99 > em1: port 0x1000-0x101f mem > 0xc190-0xc191,0xc192-0xc1923fff irq 16 at device 0.0 on pci3 > em1: Using MSIX interrupts with 5 vectors > em1: [ITHREAD] > em1: [ITHREAD] > em1: [ITHREAD] > em1: [ITHREAD] > em1: [ITHREAD] > em1: Ethernet address: 00:15:17:c8:4b:98 > > 0(i5b)% vmstat -i > interrupt total rate > irq4: uart0 6285 13 > irq21: ehci0 728 1 > irq23: ehci11078 2 > cpu0: timer 924321 1992 > irq256: em0 9375 20 > irq257: em1 127 0 > > irq258: em17 0 > irq261: em12 0 > irq262: ahci0 69 0 > cpu3: timer 923686 1990 > cpu1: timer 923651 1990 > cpu2: timer 923597 1990 > Total3712926 8001 > > 0(i5b)% > > e...@pci0:0:25:0:class=0x02 card=0x34ec8086 chip=0x10ef8086 > rev=0x05 hdr=0x00 >vendor = 'Intel Corporation' >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 13[e0] = PCI Advanced Features: FLR TP > > e...@pci0:3:0:0: class=0x02 card=0x34ec8086 chip=0x10d38086 rev=0x00 > hdr=0x00 >vendor = 'Intel Corporation' >device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' >class = network >subclass = ethernet >cap 01[c8] = powerspec 2 supports D0 D3 current D0 >cap 05[d0] = MSI supports 1 message, 64 bit >cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) >cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled > > Jack >> >> >> >> On Sat, Apr 10, 2010 at 9:05 AM, Bjoern A. Zeeb <> bzeeb-li...@lists.zabbadoz.net>bzeeb-li...@lists.zabbadoz.net> wrote: >> On Sat, 10 Apr 2010, Mike Tancsa wrote: >> >> Hi Mike, >> >> >> At 05:11 PM 4/9/2010, Jack Vogel wrote: >> Don't know, but I would just ignore it, I think its a false warning >> anyway. >> >> >> OK. I updated to HEAD as of this AM, but now I get a panic at bootup >> >> ... >> >> Trying to mount root from nfs: >> NFS ROOT: 10.255.255.1:/usr/home/pxe9/ >> panic: mutex em0:rx(0) not owned at >> /usr/HEAD/src/sys/modules/em/../../dev/e1000/if_em.c:4093 >> cpuid = 3 >> KDB: enter: panic >> [ thread pid 0 tid 100032 ] >> Stopped at kdb_enter+0x3a: movl$0,kdb_why >> db> bt >> Tracing pid 0 tid 100032 td 0xc5f5bb40 >> kdb_enter(c0cb0e9d,c0cb0e9d,c0caf56e,c5b2ac28,3,...) at kdb_enter+0x3a >> panic(c0caf56e,c6002024,c11a0357,ffd,c5b2ac7c,...) at panic+0x136 >> _mtx_assert(c6002010,4,c11a0357,ffd,64,...) at _mtx_assert+0x87 >> em_rxeof(246,c5ff7d98,c5b2aca8,c088e194,c5ff7d98,...) at em_rxeof+0x3b >> em_handle_que(c6006000,1,c0cb5c9c,4f,c5ff7d98,...) at em_handle_que+0x38 >> taskqueue_run(c5ff7d80,c5ff7d98,c0ca6410,0,c0caf5f6,...) at >> taskqueue_run+0x103 >> taskqueue_thread_loop(c600a520,c5b2ad38,c0cac192,343,c0e0ce20,...) at >> taskqueue_thread_loop+0x68 >> fork_exit(c08dcde0,c600a520,c5b2ad38) at fork_exit+0xb8 >> fork_trampoline() at fork_trampoline+0x8 >> --- trap 0, eip = 0, esp = 0xc5b2ad70, ebp = 0 --- >> db> >> >> >> >> This is a bug that seems to only happen in the Kitchener area as I hit >> it with a machine there just a few minutes ago as well. >> >> This one has fixed it f
Re: LOR on em in HEAD ( was Re: em driver regression
On Mon, Apr 12, 2010 at 7:52 AM, John Baldwin wrote: > On Friday 09 April 2010 3:09:24 pm Jack Vogel wrote: > > Someone else also pointed this out. I'm dubious about its claim. > > This happens because there is an RX lock taken in rxeof, its held > > thru the call into the stack, it then encounters another lock there > > and hence this complaint. I've had the RX hold as it is for a long > > while and would rather not have to give it up, can someone look > > at it and advise? > > I've seen it happen with igb. I suspect it is a transitive lock order. > That > is, you probably never have the UDP lock acquired before an em/igb RX lock. > However, if you have an em/igb adapter TX lock held when you acquire an > em/igb > RX lock in one place, and in if_start() you acquire the TX lock while the > UDP > lock is held, that can trigger the LOR. Specifically, those two paths > would > give you these two orders: > > TX -> RX > UDP -> TX > > which implies the order > > UDP -> RX > > (lock order relationsips are transitive, just like a > b and b > c implies > a > c). > > However, I haven't been able to track down what the raw orders are that > might > lead to this transitive order. Attilio added some sysctls to dump all the > raw > lock orders in one of the debug.witness sysctls. You can also try > hardcoding > the 'RX -> UDP' order using WITNESS_DEFINEORDER() before any of the em/igb > RX/TX locks are acquired to see what different LOR is triggered. If that > LOR > looks valid then you can keep hardcoding valid orders until you find the > invalid one. > > Do you think releasing the RX lock before the stack entry would get rid of the problem? Other ideas? Jack ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: kern/53566: IBM Eserver (245 || 345) + ServeRaid 5i ips driverpanic
In this mail: http://www.freebsd.org/cgi/getmsg.cgi? fetch=29403+32287+/usr/local/www/db/text/2003/freebsd-scsi/20030615.freebsd- scsi It was suggested to do a backtrace on it. I didn't have the option in 5.1- RELEASE, but I grabbed the 20030624 snapshot and was able to get the following information. First of all the error seems slightly different, but the end result is the same, unable to boot fully. First I get (the relevant parts IMO): .. pcib5: at pcibus 5 on motherboard pci5: on pcib5 ips0: mem 0xf400--xf7ff irq 9 at device 3.0 on pci5 ips0: failed to get configuration from device device_probe_and_attach: ips0 attach returned 6 .. pci9: in pcib9 Memory modified after free 0xc18cd700(252) panic: Most recently used by devbuf Here's the trace: Debugger(c0502455,c05c50e0,c05193ad,c0b35ca4,100) at Debugger+0x54 panic(c05193ad,c0500cf7,fc,c0c3aea0) at panic+0xcc mtrash_ctor(c18cd700,100,0,553,0) at mtrash_ctor+0x5d uma_zalloc_arg(c0c3aea0,0,101,c0327620,c0599b48) at uma_zalloc_arg+0x17f malloc(a8,c0556960,101,c052254c,c0b35d6c) at malloc+0xd4 device_get_children(c433a380,c0b35d58,c0b35d5c,c0325c62,c18dd700) at device_get_children+0x47 isa_probe_children(c433a380,c051c4db,0,c0b35d98,c02e9925) at isa_probe_children+0x2d configure(0,b32000,b32c00,b32000,0) at configure+0x4b mi_startup() at mi_startup+0xb5 begin() at begin+0x2c This machine is the 235, as we had to install linux on the 345 to get it into production. I'm not sure how long I can do testing with this machine. Also, if someone knows how to report these backtraces without having to type them in I would be appriciate a heads up on it. Thanks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/53566: IBM Eserver (245 || 345) + ServeRaid 5i ips driverpanic
In this mail: http://www.freebsd.org/cgi/getmsg.cgi? fetch=29403+32287+/usr/local/www/db/text/2003/freebsd-scsi/20030615.freebsd- scsi It was suggested to do a backtrace on it. I didn't have the option in 5.1- RELEASE, but I grabbed the 20030624 snapshot and was able to get the following information. First of all the error seems slightly different, but the end result is the same, unable to boot fully. First I get (the relevant parts IMO): .. pcib5: at pcibus 5 on motherboard pci5: on pcib5 ips0: mem 0xf400--xf7ff irq 9 at device 3.0 on pci5 ips0: failed to get configuration from device device_probe_and_attach: ips0 attach returned 6 .. pci9: in pcib9 Memory modified after free 0xc18cd700(252) panic: Most recently used by devbuf Here's the trace: Debugger(c0502455,c05c50e0,c05193ad,c0b35ca4,100) at Debugger+0x54 panic(c05193ad,c0500cf7,fc,c0c3aea0) at panic+0xcc mtrash_ctor(c18cd700,100,0,553,0) at mtrash_ctor+0x5d uma_zalloc_arg(c0c3aea0,0,101,c0327620,c0599b48) at uma_zalloc_arg+0x17f malloc(a8,c0556960,101,c052254c,c0b35d6c) at malloc+0xd4 device_get_children(c433a380,c0b35d58,c0b35d5c,c0325c62,c18dd700) at device_get_children+0x47 isa_probe_children(c433a380,c051c4db,0,c0b35d98,c02e9925) at isa_probe_children+0x2d configure(0,b32000,b32c00,b32000,0) at configure+0x4b mi_startup() at mi_startup+0xb5 begin() at begin+0x2c This machine is the 235, as we had to install linux on the 345 to get it into production. I'm not sure how long I can do testing with this machine. Also, if someone knows how to report these backtraces without having to type them in I would be appriciate a heads up on it. Thanks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
strange netstat output on Intel pro/1000 netperf testing
Hi, When I using netperf to test Intel Pro/1000 performance, I got strange netstat output: #./netperf -H 10.0.0.2 TCP STREAM TEST to 10.0.0.2 on 10.0.0.2, I start netstat -w 1 , but got strange output: it seems the link is dowm and up ceaselessly. input(Total) output packets errs bytespackets errs bytes colls 1 01212460 1 0 9462 0 553 01206100277 0 10458 0 1 01203800 1 0 9291 0 554 01214652278 0 10461 0 1 01203816 1 0 9291 0 553 01214636277 0 10461 0 1 01203888 1 0 9291 0 553 01214636277 0 10461 0 4 01203784 2 0 9291 0 555 01214692277 0 10465 0 1 01195140 1 0 9225 0 551 01214596276 0 10457 0 1 01203768 1 0 9291 0 553 01214652277 0 10461 0 I am using 4.6 -stable and 5.0 -current Can anyone help me? Best regards=3D20 Jack Zhang _ Ãâ·ÑÏÂÔØ MSN Explorer: http://explorer.msn.com/lccn/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
wscale issue on netperf testing
Hi, I am testing giga bits NICs with netperf,two machine have the same install, but when I start netperf,using tcpdump to listen,the wscale is different. giga# tcpdump -vv -n -i em0 -c 100 tcpdump: listening on em0 19:28:35.946808 10.0.0.1.49187 > 10.0.0.2.12865: S [tcp sum ok] 3414289560:3414289560(0) win 65535 (ttl 64, id 12226, len 60) 19:28:35.946877 10.0.0.2.12865 > 10.0.0.1.49187: S [bad tcp cksum 751c!] 2862099494:2862099494(0) ack 3414289561 win 57344 (ttl 64, id 27150, len 60) can anyone help me? Jack _ ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: http://messenger.microsoft.com/cn/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
