Re: [OT] Re: Bug-free software
On Sun, 10 Sep 2006 21:28:00 -0400, Lowell Gilbert <[EMAIL PROTECTED]> wrote: > It *is* in the Handbook's glossary. Geez. I can't believe all those times I've searched for the FreeBSD jargon, the glossary *never* appeared in my results, so I'm getting to know it right now, after your comment. As I own a copy of Greg's "The Complete FreeBSD", I rarely check the online handbook. Shame on me. Well, now I've bookmarked it (glossary). Thanks for the tip, and sorry for the noise. -- Ricardo Nabinger Sanchez <[EMAIL PROTECTED],wait4.org}> Powered by FreeBSD "Left to themselves, things tend to go from bad to worse." ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
Karl Denninger wrote: No, I would like -STABLE to be treated as what it is claimed to be - BETA code, not ALPHA code. There's a huge difference between the two, and MFCing something back to -STABLE without testing the functionality of the module you're working with first does not fit the BETA model (it DOES fit the Alpha model.) This is coming from someone who has run FreeBSD in a production environment for basically 10 years, and has even sometimes used -CURRENT during that time (with full knowledge that running THAT is, indeed, ALPHA code!) I guess part of the problem is not enough of us running -CURRENT, so bugs can slip through into -STABLE via MFC (I know I'm guilty here - 2 boxes running -STABLE, none on -CURRENT) Cheers Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
Volker wrote: This should be documented somewhere clearly then, as my understanding was that -STABLE meant that anything MFCd back to it *was* tested and deemed stable ... and yes, I do run stable, and yes, I do expect to hit the occasional 'oopses', but "blantant and obvious bugs due to insufficient testing", IMHO, doesn't classify as an 'oops' Guys, we're talking about software. Have you ever seen a piece of software which has been really bug-free? Not the hello-world, I'm talking about real software. Also, you should never go with -STABLE on a production server. I'm sure this has been made clear in the handbook. If it's really a that import server in production use, go with a RELEASE. -STABLE is not a technology playground as CURRENT but should be seen as a BETA testing system. If that's not the case, then why use RELEASE at all? Pardon me, but I do have to interject a very large laugh here. What's the first recommendation that's made _every_ time someone posts a problem with a -RELEASE installation? It's "Well, go update to -STABLE and then we will might be able to help you." Simply put, running a -RELEASE means that you _are_ running software with _known_ problems. I'm very thankful for all the work that people put into FreeBSD. However, that doesn't blind me to problems with the current setup. It may be the best that we have, it may be better than the Linux world, but that doesn't mean that it solves all our problems and that we can't improve it. John(FreeBSD since 2.0.x on an AMD K5-100 with 16MB of ram...) -- John T. Farmer Owner & CTO GoldSword Systems [EMAIL PROTECTED] 865-691-6498 Knoxville TN Consulting, Design, & Development of Networks & Software ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[OT] Re: Bug-free software (Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!)
On Mon, 11 Sep 2006 02:37:37 +0200, Volker <[EMAIL PROTECTED]> wrote: > MFC means "merge from current" (read as: merge from CURRENT [HEAD] > cvs tree into the current -STABLE tree). Way off-topic: I had a patch around my stuff to add this (and some others I don't remember now) to the wtf (1) base, or even a "FreeBSD Glossary" section in the handbook. It certainly wouldn't hurt to have one, and at least me would thank the brave fellow who did it :) -- Ricardo Nabinger Sanchez <[EMAIL PROTECTED],wait4.org}> Powered by FreeBSD "Left to themselves, things tend to go from bad to worse." ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bug-free software (Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!)
On 2006-09-11 02:25, Stephen Clark wrote: > Sorry to be dense but what does MFCing mean. I have googled for it but > can find > nothing that explains it. > > Thanks, > Steve > Steve, MFC means "merge from current" (read as: merge from CURRENT [HEAD] cvs tree into the current -STABLE tree). I'm seeing -CURRENT as a playground for new features, technologies and support for latest hardware. If something has worked out there, the changes are merged from the -CURRENT tree into the (non-release) -STABLE tree. -STABLE has a broader audience and mistakes will probably being detected there. At a time before RELEASE date the -STABLE tree is being frozen (no new features are allowed to be merged into -STABLE) and after a testing phase (BETA / PRE-RELEASE) the code will be released. Greetings, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bug-free software (Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!)
Volker wrote: On 2006-09-11 01:33, 'Anubhav A.' wrote: in message <[EMAIL PROTECTED]>, wrote Volker thusly... we're talking about software. Have you ever seen a piece of software which has been really bug-free? Not the hello-world, I'm talking Recently i read about which is more than "hello-world" ... They Write the Right Stuff http://www.fastcompany.com/online/06/writestuff.html ... but you did ask. - Parv Interesting article but I really do not believe even the shuttle software is 100% bug free. Just because there has been only one bug found in the last version, does not mean it's really guaranteed to be bug free. It's just: No one experienced one and no one discovered one more. On the other side they do not implement much new features every day and they do not have to care about hardware and market changes every other day. I suspect a lot of trouble even for NASA's mission does come from software bugs and who knows how many lifes can be accounted for software bugs. Remembering the first launch of a Ariane-5 rocket? It has been self destroyed because of nothing but a software bug. Or what about the first NAVY combat ship w/ steering controlled by Windows NT? Out of control by a blue screen... A developer can't always foresee the environment where his code will later work in and that is even causing trouble. And again, errors and mistakes are human. And those who shout out "why didn't you test enough" should ask themself, how much have THEY contributed to the community? The hackers are contributing enough (my view) and are really doing a good job. I do not care about HOW MANY bugs a beta quality piece of software does contain but what IMHO matters is the timeframe to FIX them and the FreeBSD project and other OS communities are good in that. Greetings, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" Sorry to be dense but what does MFCing mean. I have googled for it but can find nothing that explains it. Thanks, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
bge watchdog timeouts still happening
Hi, I've recently put into production 2 web servers with 6.0-STABLE from mid january and was bitten by the bge watchdog timeouts problems. I cvsupped the 2 boxes with the latest -stable (latest if_bge.c, rev 1.91.2.17) but the problem still persists :( Server hardware is Dell poweredge 2550 with SMP kernel. Relevant portion of dmesg : bge0: mem 0xfeb0-0xfeb0 irq 17 at device 8.0 on pci1 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge0: Ethernet address: 00:06:5b:1a:7f:4a On the first box, the load is quite light so the problem as not yet re-appaeared since the upgrade. On the 2d box, which usually outputs 10-15 Mbit/s, the timeouts came back very shortly after the ugprade. Extract of logs from the 2d box : (uptime < 1h) Sep 11 01:19:50 www1 kernel: bge0: watchdog timeout -- resetting Sep 11 01:19:50 www1 kernel: bge0: link state changed to DOWN Sep 11 01:19:54 www1 kernel: bge0: link state changed to UP Sep 11 01:26:10 www1 kernel: bge0: watchdog timeout -- resetting Sep 11 01:26:10 www1 kernel: bge0: link state changed to DOWN Sep 11 01:26:13 www1 kernel: bge0: link state changed to UP Sep 11 01:27:32 www1 kernel: bge0: watchdog timeout -- resetting Sep 11 01:27:32 www1 kernel: bge0: link state changed to DOWN Sep 11 01:27:35 www1 kernel: bge0: link state changed to UP Sep 11 01:28:52 www1 kernel: bge0: watchdog timeout -- resetting Sep 11 01:28:52 www1 kernel: bge0: link state changed to DOWN Sep 11 01:28:55 www1 kernel: bge0: link state changed to UP Sep 11 01:31:12 www1 kernel: bge0: watchdog timeout -- resetting Sep 11 01:31:12 www1 kernel: bge0: link state changed to DOWN Sep 11 01:31:15 www1 kernel: bge0: link state changed to UP Sep 11 01:33:57 www1 kernel: bge0: watchdog timeout -- resetting Sep 11 01:33:57 www1 kernel: bge0: link state changed to DOWN Sep 11 01:34:00 www1 kernel: bge0: link state changed to UP Sep 11 01:34:16 www1 kernel: bge0: watchdog timeout -- resetting Sep 11 01:34:16 www1 kernel: bge0: link state changed to DOWN Sep 11 01:34:19 www1 kernel: bge0: link state changed to UP Sep 11 01:34:41 www1 kernel: bge0: watchdog timeout -- resetting Sep 11 01:34:41 www1 kernel: bge0: link state changed to DOWN Sep 11 01:34:44 www1 kernel: bge0: link state changed to UP Sep 11 01:35:06 www1 kernel: bge0: watchdog timeout -- resetting Sep 11 01:35:06 www1 kernel: bge0: link state changed to DOWN Sep 11 01:35:09 www1 kernel: bge0: link state changed to UP Sep 11 01:36:17 www1 kernel: bge0: watchdog timeout -- resetting Sep 11 01:36:17 www1 kernel: bge0: link state changed to DOWN Sep 11 01:36:20 www1 kernel: bge0: link state changed to UP Sep 11 01:37:47 www1 kernel: bge0: watchdog timeout -- resetting Sep 11 01:37:47 www1 kernel: bge0: link state changed to DOWN Sep 11 01:37:50 www1 kernel: bge0: link state changed to UP Sep 11 01:38:53 www1 kernel: bge0: watchdog timeout -- resetting Sep 11 01:38:53 www1 kernel: bge0: link state changed to DOWN Sep 11 01:38:56 www1 kernel: bge0: link state changed to UP Sep 11 01:39:56 www1 kernel: bge0: watchdog timeout -- resetting Sep 11 01:39:56 www1 kernel: bge0: link state changed to DOWN Sep 11 01:39:59 www1 kernel: bge0: link state changed to UP I've removed 'options SMP' from the kernel config of the loaded box but the timeouts continue to happen. What can I do to help resolve this bug ? -- Herve Boulouis ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sun, Sep 10, 2006 at 08:11:22PM +, Michael Abbott wrote: > >>You can track changes to a particular release - say by using > >>RELENG_6_1 rather than RELENG_6. In which case, would you still > >>say you are tracking STABLE? > >If I track RELENG_6 (once 6.0-RELEASE has gone out) then I'm by definition > >tracking -STABLE. > > Damn, I'm confused now. Let me try and get this straight: > > CURRENT > This is, by definition, broken a good part of the time, and is > what it says, namely current, ie work in progress. > > STABLE > This is broken some of the time and .. uh .. isn't really all that > stable, actually. > > RELENG_n_m > This is completely stable and only tracks security fixes. Incorrect. This is "completely FIXED", which is not the same thing as STABLE. "Fixed in a broken state" is still broken, aka the serial I/O problems in 6.x that I've found (and for which there is apparently no current fix in any of the branches of 6.x.) > RELENG_n (RELENG_6 at the moment) > Has somebody just said that RELENG_6 = STABLE? I'm going to guess > then that RELENG_7 is CURRENT. > No, this doesn't make sense to me at all. > > >Indeed, the current tag on my CVS tree is TRELENG_6! > > Eh? T? As in "Tag", which is the syntax that acutally shows up in the "CVS" directory under the source tree. -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant & Kids Rights Activist http://www.denninger.netMy home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://genesis3.blogspot.comMusings Of A Sentient Mind ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sun, Sep 10, 2006 at 10:15:20PM +0300, Reko Turja wrote: > From: "Karl Denninger" <[EMAIL PROTECTED]> > To: > Sent: Sunday, September 10, 2006 9:39 PM > >Yes it is, in the general case; in any event if you track RELENG_6_1 > >you will > >get no bug fixes in general - security related items to filter back > >down but > >in general bug reports posted against a -RELEASE are, if addressed, > >put into > >-STABLE. > > You would like untested fixes to hit the release version first? By the > way, possible breakage of STABLE due MFC process was announced a good > while ago... No, I would like -STABLE to be treated as what it is claimed to be - BETA code, not ALPHA code. There's a huge difference between the two, and MFCing something back to -STABLE without testing the functionality of the module you're working with first does not fit the BETA model (it DOES fit the Alpha model.) This is coming from someone who has run FreeBSD in a production environment for basically 10 years, and has even sometimes used -CURRENT during that time (with full knowledge that running THAT is, indeed, ALPHA code!) -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant & Kids Rights Activist http://www.denninger.netMy home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://genesis3.blogspot.comMusings Of A Sentient Mind ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bug-free software (Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!)
On 2006-09-11 01:33, 'Anubhav A.' wrote: > in message <[EMAIL PROTECTED]>, wrote Volker thusly... >> we're talking about software. Have you ever seen a piece of software which >> has >> been really bug-free? Not the hello-world, I'm talking > > Recently i read about which is more than "hello-world" ... > > They Write the Right Stuff > http://www.fastcompany.com/online/06/writestuff.html > > > ... but you did ask. > > > - Parv > Interesting article but I really do not believe even the shuttle software is 100% bug free. Just because there has been only one bug found in the last version, does not mean it's really guaranteed to be bug free. It's just: No one experienced one and no one discovered one more. On the other side they do not implement much new features every day and they do not have to care about hardware and market changes every other day. I suspect a lot of trouble even for NASA's mission does come from software bugs and who knows how many lifes can be accounted for software bugs. Remembering the first launch of a Ariane-5 rocket? It has been self destroyed because of nothing but a software bug. Or what about the first NAVY combat ship w/ steering controlled by Windows NT? Out of control by a blue screen... A developer can't always foresee the environment where his code will later work in and that is even causing trouble. And again, errors and mistakes are human. And those who shout out "why didn't you test enough" should ask themself, how much have THEY contributed to the community? The hackers are contributing enough (my view) and are really doing a good job. I do not care about HOW MANY bugs a beta quality piece of software does contain but what IMHO matters is the timeframe to FIX them and the FreeBSD project and other OS communities are good in that. Greetings, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bug-free software (Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!)
On Sun, Sep 10, 2006 at 07:33:25PM -0400, 'Anubhav A.' wrote: > in message <[EMAIL PROTECTED]>, wrote Volker thusly... > > > > we're talking about software. Have you ever seen a piece of software which > > has > > been really bug-free? Not the hello-world, I'm talking > > Recently i read about which is more than "hello-world" ... > > They Write the Right Stuff > http://www.fastcompany.com/online/06/writestuff.html > > > ... but you did ask. -- This software is bug-free. It is perfect, as perfect as human beings have achieved. Consider these stats : the last three versions of the program -- each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors. -- But that just proves the point: despite all that careful engineering, "one error each" and "a total of 17 errors" != "bug-free". Kris pgp7MKkCGgGI8.pgp Description: PGP signature
Bug-free software (Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!)
in message <[EMAIL PROTECTED]>, wrote Volker thusly... > > we're talking about software. Have you ever seen a piece of software which has > been really bug-free? Not the hello-world, I'm talking Recently i read about which is more than "hello-world" ... They Write the Right Stuff http://www.fastcompany.com/online/06/writestuff.html ... but you did ask. - Parv -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Neat error ...
On Sun, 10 Sep 2006, Kris Kennaway wrote: On Sun, Sep 10, 2006 at 04:52:18PM -0300, Marc G. Fournier wrote: Not sure if there is anything thta I can do with this, no dump and it crashes, so no DDB ... but figured I'd post it ... Sep 10 16:49:34 jupiter kernel: g_vfs_done():da0s1g[READ(offset=-2048, length=16384)]error = 5 Sep 10 16:49:34 jupiter kernel: g_vfs_done():da0s1g[READ(offset=-2048, length=16384)]error = 5 Sep 10 16:49:34 jupiter kernel: g_vfs_done(): Sep 10 16:49:34 jupiter kernel: da0s1g[READ(offset=-2048 Sep 10 16:49:34 jupiter kernel: , length=1638o Sep 10 16:49:34 jupiter kernel: )]error = 5 What do you expect us to do about your failing hard disk? :) Just what you did ... confirm that that is what it is :) Thank you ... one way to get rid of the 'hanging file system with iir driver issue' ... hard way, but it does it :) Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
> This should be documented somewhere clearly then, as my understanding was > that -STABLE meant that anything MFCd back to it *was* tested and deemed > stable ... and yes, I do run stable, and yes, I do expect to hit the > occasional 'oopses', but "blantant and obvious bugs due to insufficient > testing", IMHO, doesn't classify as an 'oops' > Guys, we're talking about software. Have you ever seen a piece of software which has been really bug-free? Not the hello-world, I'm talking about real software. Also, you should never go with -STABLE on a production server. I'm sure this has been made clear in the handbook. If it's really a that import server in production use, go with a RELEASE. -STABLE is not a technology playground as CURRENT but should be seen as a BETA testing system. If that's not the case, then why use RELEASE at all? Sure you may blame a developer for not testing enough but you're on your own if you use beta quality software on your production systems. As a developer I've seen many bugs which haven't been found during testing and I know it's nearly impossible to find _all_ bugs while testing. I've seen applications failing just because the user typed the wrong key at the wrong time (or an unexpected key). As a user I'm thankful for bugs being fast fixed bugs but on the other side I really know what I'm doing when using -STABLE software on my system. I do see this as a give-back to the community to find bugs early before -RELEASE. Also keep in mind most kernel hackers do kernel hacking in their spare time. Everyone using FreeBSD (or any other OS system) is profiting from their spare time and it's unfair to be not that polite. And back to the issue: The gmirror bug has already been fixed and I posted a note to the ML hours before the first "who the f... did cause that bug" post. A short look into ML postings would have made this thread needless. If you blame developers, then please shut off your computer. my2ct Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Neat error ...
On Sun, 10 Sep 2006, Kris Kennaway wrote: On Sun, Sep 10, 2006 at 04:52:18PM -0300, Marc G. Fournier wrote: Not sure if there is anything thta I can do with this, no dump and it crashes, so no DDB ... but figured I'd post it ... Sep 10 16:49:34 jupiter kernel: g_vfs_done():da0s1g[READ(offset=-2048, length=16384)]error = 5 Sep 10 16:49:34 jupiter kernel: g_vfs_done():da0s1g[READ(offset=-2048, length=16384)]error = 5 Sep 10 16:49:34 jupiter kernel: g_vfs_done(): Sep 10 16:49:34 jupiter kernel: da0s1g[READ(offset=-2048 Sep 10 16:49:34 jupiter kernel: , length=1638o Sep 10 16:49:34 jupiter kernel: )]error = 5 What do you expect us to do about your failing hard disk? :) Kris Sight unseen, I'd concur on bad hardware. I earlier was bitten by the broken gmirror code and the only way I found out was that a failing disk froze the machine with just this sort of g_vfs_done() error. The disk was "Recertified" (thanks Western Digital for stellar warrantee behavior. Yeah), and was just waiting to do this to me. The reboot and mirror re-sync demonstrated the broken gmirror code, completely :) All in all, a very fun-filled Sunday. But it's rib roast tonight, and that will make it easier... r ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sun, Sep 10, 2006 at 08:11:22PM +, Michael Abbott wrote: > >Indeed, the current tag on my CVS tree is TRELENG_6! > > Eh? T? cd /usr/src cat CVS/Tag CVS places a "T" infront of the tag name in the Tag file. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: check if file system is clean ...
Marc G. Fournier wrote: I checked both fsck and fsck_ffs man page, and don't see anything in either ... is there some way I can check if a file system is actually 'clean', without running fsck? Google Groups revealed the following: http://lists.freebsd.org/pipermail/freebsd-questions/2003-June/008898.html [EMAIL PROTECTED]:~] $ dumpfs /usr | grep clean cgrotor 512 fmod0 ronly 0 clean 0 [EMAIL PROTECTED]:~] $ Using dumpfs(8) for this purpose is a little like using a jackhammer to drive a nail into drywall; it Gets The Job Done but there sure is a lot of noise and heavy lifting... :) -Jonathan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sun, Sep 10, 2006 at 08:11:22PM +, Michael Abbott wrote: > >>You can track changes to a particular release - say by using > >>RELENG_6_1 rather than RELENG_6. In which case, would you still > >>say you are tracking STABLE? > >If I track RELENG_6 (once 6.0-RELEASE has gone out) then I'm by definition > >tracking -STABLE. > > Damn, I'm confused now. Let me try and get this straight: Perhaps this might help? http://home.nyc.rr.com/computertaijutsu/release.html -- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 Buffy: Well, that works out great. You won't tell anyone that I'm the Slayer, and I won't tell anyone you're a moron. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
Michael Abbott wrote: > Damn, I'm confused now. Let me try and get this straight: > > CURRENT > This is, by definition, broken a good part of the time, and is what > it says, namely current, ie work in progress. Yes. > STABLE > This is broken some of the time and .. uh .. isn't really all that > stable, actually. "STABLE" means "you can update FreeBSD along this branch without needing to recompile applications or kernel modules". This means that companies can ship binary drivers for their hardware and say "this driver will work on FreeBSD 6.x" (which isn't possible on Linux). The fact that there are occasionally bugs introduced... well, that's an inevitable consequence of the stable branches being development branches. > RELENG_n_m > This is completely stable and only tracks security fixes. Security fixes and "critical errata". The requirements for something being committed to such a branch after the release are that: 1. It must be an important bugfix, and 2. I must be absolutely certain that nothing bad will ever happen as a result of someone updating a FreeBSD n.m system to the latest updates on RELENG_n_m. > RELENG_n (RELENG_6 at the moment) > Has somebody just said that RELENG_6 = STABLE? Yes. > I'm going to guess then that RELENG_7 is CURRENT. > No, this doesn't make sense to me at all. RELENG_7 doesn't exist yet. RELENG_7 will be 7-STABLE once it exists, some time in 2007. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
You can track changes to a particular release - say by using RELENG_6_1 rather than RELENG_6. In which case, would you still say you are tracking STABLE? If I track RELENG_6 (once 6.0-RELEASE has gone out) then I'm by definition tracking -STABLE. Damn, I'm confused now. Let me try and get this straight: CURRENT This is, by definition, broken a good part of the time, and is what it says, namely current, ie work in progress. STABLE This is broken some of the time and .. uh .. isn't really all that stable, actually. RELENG_n_m This is completely stable and only tracks security fixes. RELENG_n (RELENG_6 at the moment) Has somebody just said that RELENG_6 = STABLE? I'm going to guess then that RELENG_7 is CURRENT. No, this doesn't make sense to me at all. Indeed, the current tag on my CVS tree is TRELENG_6! Eh? T? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Neat error ...
On Sun, Sep 10, 2006 at 04:52:18PM -0300, Marc G. Fournier wrote: > > Not sure if there is anything thta I can do with this, no dump and it > crashes, so no DDB ... but figured I'd post it ... > > Sep 10 16:49:34 jupiter kernel: g_vfs_done():da0s1g[READ(offset=-2048, > length=16384)]error = 5 > Sep 10 16:49:34 jupiter kernel: g_vfs_done():da0s1g[READ(offset=-2048, > length=16384)]error = 5 > Sep 10 16:49:34 jupiter kernel: g_vfs_done(): > Sep 10 16:49:34 jupiter kernel: da0s1g[READ(offset=-2048 > Sep 10 16:49:34 jupiter kernel: , length=1638o > Sep 10 16:49:34 jupiter kernel: )]error = 5 What do you expect us to do about your failing hard disk? :) Kris pgpFAbiCEDcMS.pgp Description: PGP signature
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
From: "Karl Denninger" <[EMAIL PROTECTED]> To: Sent: Sunday, September 10, 2006 9:39 PM Yes it is, in the general case; in any event if you track RELENG_6_1 you will get no bug fixes in general - security related items to filter back down but in general bug reports posted against a -RELEASE are, if addressed, put into -STABLE. You would like untested fixes to hit the release version first? By the way, possible breakage of STABLE due MFC process was announced a good while ago... -Reko ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Neat error ...
Not sure if there is anything thta I can do with this, no dump and it crashes, so no DDB ... but figured I'd post it ... Sep 10 16:49:34 jupiter kernel: g_vfs_done():da0s1g[READ(offset=-2048, length=16384)]error = 5 Sep 10 16:49:34 jupiter kernel: g_vfs_done():da0s1g[READ(offset=-2048, length=16384)]error = 5 Sep 10 16:49:34 jupiter kernel: g_vfs_done(): Sep 10 16:49:34 jupiter kernel: da0s1g[READ(offset=-2048 Sep 10 16:49:34 jupiter kernel: , length=1638o Sep 10 16:49:34 jupiter kernel: )]error = 5 Sep 10 16:49:34 jupiter kernel: Sep 10 16:49:34 jupiter kernel: g_vfs_done():da0s1g[READ(offset=-2048, length=16384)]error = 5 Sep 10 16:49:34 jupiter kernel: Sep 10 16:49:34 jupiter kernel: g_vfs_done():da0s1g[READ(offset=-2048, length=16384)]error = 5 Sep 10 16:49:34 jupiter last message repeated 2 times Sep 10 16:49:34 jupiter kernel: g_vfs_done():da0s1g[READ(offset= Sep 10 16:49:34 jupiter kernel: -2048, length=163 Sep 10 16:49:34 jupiter kernel: 84)]error = 5 Sep 10 16:49:34 jupiter kernel: Sep 10 16:49:34 jupiter kernel: g_vfs_done():da0s1g[READ(offset=-2048, length=16384)]error = 5 Sep 10 16:49:34 jupiter kernel: g_vfs_done():d Sep 10 16:49:34 jupiter kernel: a0s1g[READ(o1 Sep 10 16:49:34 jupiter kernel: fset=-2048, l Sep 10 16:49:34 jupiter kernel: ength=16384)e Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
check if file system is clean ...
I checked both fsck and fsck_ffs man page, and don't see anything in either ... is there some way I can check if a file system is actually 'clean', without running fsck? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Still possible to directly boot without loader?
Am 10.09.2006 um 21:13 schrieb Kris Kennaway: On Sun, Sep 10, 2006 at 09:10:26PM +0200, Stefan Bethke wrote: I just tried to load my standard kernel from the boot blocks (instead of using loader(8)), but I either get a hang before the kernel prints anything, or a BTX halted. Is this still supposed to work in 6- stable, or has it finally disappeared? Without access to the device.hints (either from loader or compiled in) you won't have a working console (and possibly other devices), so the kernel may appear to hang while booting. Ah, thanks! I'll try building a self-contained kernel then... Cheers, Stefan -- Stefan Bethke <[EMAIL PROTECTED]> Fon +49 170 346 0140 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Still possible to directly boot without loader?
On Sun, Sep 10, 2006 at 09:10:26PM +0200, Stefan Bethke wrote: > I just tried to load my standard kernel from the boot blocks (instead > of using loader(8)), but I either get a hang before the kernel prints > anything, or a BTX halted. Is this still supposed to work in 6- > stable, or has it finally disappeared? Without access to the device.hints (either from loader or compiled in) you won't have a working console (and possibly other devices), so the kernel may appear to hang while booting. Kris pgpDCmQU9aFI1.pgp Description: PGP signature
Still possible to directly boot without loader?
I just tried to load my standard kernel from the boot blocks (instead of using loader(8)), but I either get a hang before the kernel prints anything, or a BTX halted. Is this still supposed to work in 6- stable, or has it finally disappeared? Thanks, Stefan -- Stefan Bethke <[EMAIL PROTECTED]> Fon +49 170 346 0140 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sun, Sep 10, 2006 at 02:36:31PM -0400, Kris Kennaway wrote: > On Sun, Sep 10, 2006 at 01:13:31PM -0500, Karl Denninger wrote: > > On Sun, Sep 10, 2006 at 03:21:33PM +, Patrick J Okui wrote: > > > On Sun, 10 Sep 2006, Karl Denninger wrote: > > > > > > > > > > >Once the -RELEASE branch is taken, code updates there . > > > > > > > > > > I take it you haven't read the text in the handbook that has been > > > linked to by a few posters. > > > > > > You can track changes to a particular release - say by using > > > RELENG_6_1 rather than RELENG_6. In which case, would you still > > > say you are tracking STABLE? > > > > Yes. > > > > If I track RELENG_6 (once 6.0-RELEASE has gone out) then I'm by definition > > tracking -STABLE. > > > > Indeed, the current tag on my CVS tree is TRELENG_6! > > Not the question he asked, please re-read. > > Kris Yes it is, in the general case; in any event if you track RELENG_6_1 you will get no bug fixes in general - security related items to filter back down but in general bug reports posted against a -RELEASE are, if addressed, put into -STABLE. -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant & Kids Rights Activist http://www.denninger.netMy home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://genesis3.blogspot.comMusings Of A Sentient Mind ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sun, Sep 10, 2006 at 01:13:31PM -0500, Karl Denninger wrote: > On Sun, Sep 10, 2006 at 03:21:33PM +, Patrick J Okui wrote: > > On Sun, 10 Sep 2006, Karl Denninger wrote: > > > > > > > >Once the -RELEASE branch is taken, code updates there . > > > > > > > I take it you haven't read the text in the handbook that has been > > linked to by a few posters. > > > > You can track changes to a particular release - say by using > > RELENG_6_1 rather than RELENG_6. In which case, would you still > > say you are tracking STABLE? > > Yes. > > If I track RELENG_6 (once 6.0-RELEASE has gone out) then I'm by definition > tracking -STABLE. > > Indeed, the current tag on my CVS tree is TRELENG_6! Not the question he asked, please re-read. Kris pgpnBuAGsmW2l.pgp Description: PGP signature
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sun, Sep 10, 2006 at 03:21:33PM +, Patrick J Okui wrote: > On Sun, 10 Sep 2006, Karl Denninger wrote: > > > > >Once the -RELEASE branch is taken, code updates there . > > > > I take it you haven't read the text in the handbook that has been > linked to by a few posters. > > You can track changes to a particular release - say by using > RELENG_6_1 rather than RELENG_6. In which case, would you still > say you are tracking STABLE? Yes. If I track RELENG_6 (once 6.0-RELEASE has gone out) then I'm by definition tracking -STABLE. Indeed, the current tag on my CVS tree is TRELENG_6! -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant & Kids Rights Activist http://www.denninger.netMy home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://genesis3.blogspot.comMusings Of A Sentient Mind ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: integer divide fault on 6.1
On 9/10/06, Sam Leffler <[EMAIL PROTECTED]> wrote: Joao Barros wrote: > On 9/9/06, Kris Kennaway <[EMAIL PROTECTED]> wrote: >> On Sat, Sep 09, 2006 at 09:02:35PM +0100, Joao Barros wrote: >> > On 9/9/06, Max Laier <[EMAIL PROTECTED]> wrote: >> > > >> > >Can you try to get a dump, trace, or at least figure out which >> function >> > >the IP is refering to? >> > > >> > >> > Well, the problem only occurs when I boot from the disk and the >> > installed kernel doesn't have debug support. >> > Does 'set dumpdev=' work from the boot loader? I tried some >> > combinations with no success. >> >> No. >> >> > I can try and install a 6-STABLE snapshot if there's no way of getting >> > the info needed. >> >> You can either try to install a new kernel with DDB support, or follow >> the "instruction pointer" method in the developers handbook chapter on >> kernel debugging. > > I copied a CURRENT kernel from a 200608 snapshot and the problem also > occurs thus I'm adding [EMAIL PROTECTED] > My current laptop doesn't have a serial port so I'm copying this by hand: > > Fatal trap 18: integer divide fault while in kernel mode > cpuid = 0; apic id = 00 > instruction pointer = 0x20:0xc08a1fb7 > stack pointer = 0x28:0xc0c20b14 > frame pointer = 0x28:0xc0c20b9c > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = 0 (swapper) > [thread pid 0 tid 0 ] > Stopped at__qdivrem+0x3b: divl%ecx,%eax > > db> bt > Tracing pid 0 tid0 td 0xc0a0c818 > __qdivrem(37fdfa0,0,0,0,0,...) at __qdivrem+0x3b > __udivdi3(37fdfa0,0,0,0) at __udivdi3+0x16 > ata_raid_promise_read_meta(c37a5000,c09f4a80,1,8086,c37a5000,...) at > ata_raid_promise_read_meta+0x9b > ata_raid_read_metadata(c37a5000,c37a5000,c0c20c70,c06b58a4,c37a5000,...) > at ata_raid_metadata+0x2be > ata_raid_subdisk_attach(c37a5000) at ata_raid_subdisk_attach+0x33 > device_attach(c37a5000,c37a5180,c37a5000,c36885c0,0,...) at > device_attach+0x58 > device_probe_and_attach(c37a5200,c37a5200,c08ec9a9,0,c37a5180,...) at > bus_generic_attach+0x16 > ad_attach(c37a5200) at ad_attach+0x2c8 > device_attach(c37a5200,c095f2d0,c37a5200,0,c368d800,...) at > device_attach+0x58 > device_probe_and_attach(c37a5200) at device_probe_and_atach+0xe0 > bus_generic_attach(c3659080,c3659080,,0,c37a5200,...) at > bus_generic_attach+0x16 > ata_identify(c3659080) at ata_identify+0x1c8 > ata_boot_attach(0xc0a11d80,0,c09212e7,47,...) at ata_boot_attach+0x3e > run_interrupt_drive_config_hooks(0,c1ec00,c1e000,0,c0451065,...) at > run_interrupt_drive_config_hooks+0x43 > mi_startup() at mi_startup+0x96 > begin() at begin+0x2c > > This board has a Promise SATA raid controller and it is disabled in > the BIOS. I even tried disabling it through a jumper but it still > stops. > In sys/dev/ata/ata-raid.h the PROMISE_LBA macro does an unchecked calculation that apparently can divide by zero. Soren would likely understand the root cause of this problem but until then you can patch the driver to workaround the problem. Sam Thanks for narrowing it down! -- Joao Barros ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Patrick J Okui > Sent: Sunday, September 10, 2006 10:22 AM > To: Karl Denninger > Cc: freebsd-stable@freebsd.org > Subject: Re: AGH! Guys, who's breaking -STABLE's GMIRROR code?! > > You can track changes to a particular release - say by using > RELENG_6_1 rather than RELENG_6. In which case, would you > still say you are tracking STABLE? Well, that depends. For security and "critical fixes" (as the handbook phrases it) you can track RELENG_6_1 (in the case of 6.1-RELEASE) and be happy. But what happens if the needed fix isn't security or "critical" in the minds of the FreeBSD developers? At that point you either need to wait for the next RELEASE, manually merge fixes into your production source (which depending on the fix(s) could be non-trivial) or cross your fingers and follow -STABLE. This problem isn't specific to FreeBSD (or unix in general) by Any means, of course. Sure, we could broaden the scope of RELENG_X_Y. Or introduce a new branch that's closer to -STABLE yet tuned for something like, "security, critical and major fixes" for production systems. I'm not sure either of those options are preferable, would be effective in alleviating the problem, or even workable in the first place. Personally, I've been served quite well for many years with the current configuration. Since I don't track -STABLE on anything important (or more accurately have yet NEEDED to do so), I've never been hit by any of these transient issues that crop up from time to time and can elicit loud complaints. --Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Where is the maximum of hw.ath.txbuf and rxbuf ? (former: atheros driver under high load, panics and even more freezes)
Daniel Dvořák wrote: > Hi Sam, > > thank you for your answer. I think it is connected to this problem somehow, but not fully. > > I increased txbuf and rxbuf twice to 200 and 80, I saw some > betterment in less of "no buffers space ...", but latency went up to 2000 ms. > > Now I ended at txbuf=800 and rxbuf=320 on both sides R1 and R2. > > But still, there is the same problem: > > It was tested after the rebooting R2 almost at once. > > --- R1 ping statistics --- > 1 packets transmitted, 8752 packets received, 12% packet loss > round-trip min/avg/max/stddev = 1.324/920.480/6323.454/766.399 ms > up to 6k ms > > R2# athstats -i ath0 > 11309 data frames received > 11384 data frames transmit > 12508 long on-chip tx retries > 769 tx failed 'cuz too many retries > 24M current transmit rate > 2 tx management frames > 6 tx frames discarded prior to association > 31 tx stopped 'cuz no xmit buffer > 38 tx frames with no ack marked > 3 rx failed 'cuz of bad CRC > 4464 rx failed 'cuz of PHY err > 4464 OFDM timing > 24 periodic calibrations > 27 rssi of last ack > 27 avg recv rssi > -96 rx noise floor > 1 switched default/rx antenna > Antenna profile: > [1] tx10614 rx11449 > > > Where is the maximum of txbuf and rxbuf ? The max is derived from available memory. The h/w has no upper bounds. > > I would like to test it. > > Thank you for your attention. > > Daniel > > >> -Original Message- >> From: Sam Leffler [mailto:[EMAIL PROTECTED] >> Sent: Friday, September 08, 2006 6:30 AM >> To: [EMAIL PROTECTED] >> Cc: freebsd-stable@freebsd.org >> Subject: Re: atheros driver under high load, panics and even >> more freezes >> >> Daniel Dvoøák wrote: >>> Hi Sam and all, >>> >>> I am not sure if I understand your answer, but I try it. >>> >>> When I use start my test, athstats shows this: >>> >>> athstats -i ath0 >>> >>> 19308912 data frames received >>> 15723536 data frames transmit >>> 6536 tx frames with an alternate rate >>> 2188280 long on-chip tx retries >>> 62583 tx failed 'cuz too many retries >>> 348 tx linearized to cluster >>> 24M current transmit rate >>> 6 tx management frames >>> 6 tx frames discarded prior to association >>> 27129 tx stopped 'cuz no xmit buffer >>> 23057 tx frames with no ack marked >>> 1182 rx failed 'cuz of bad CRC >>> 761604 rx failed 'cuz of PHY err >>> 761604 OFDM timing >>> 4829 periodic calibrations >>> 28 rssi of last ack >>> 27 avg recv rssi >>> -96 rx noise floor >>> 1 switched default/rx antenna >>> Antenna profile: >>> [1] tx 15660942 rx 19451935 >>> [2] tx2 rx0 >>> >>> ... >>> >>> >>> I use this ping command from R2: >>> ping -i .002 -c 1 -s 1472 opposite side R1 >>> >>> --- R1 ping statistics --- >>> 1 packets transmitted, 1 packets received, 0% packet loss >>> round-trip min/avg/max/stddev = 1.316/1.442/49.391/1.757 ms >>> >>> You can see nice average latency about 1,4 ms and no one >> packet was lost. >>> athstats almost wasn´t changed. >>> >>> 19309465 data frames received >>> 15724079 data frames transmit >>> 6536 tx frames with an alternate rate >>> 2188281 long on-chip tx retries >>> 62583 tx failed 'cuz too many retries >>> 348 tx linearized to cluster >>> 24M current transmit rate >>> 6 tx management frames >>> 6 tx frames discarded prior to association >>> 27129 tx stopped 'cuz no xmit buffer >>> 23075 tx frames with no ack marked >>> 1182 rx failed 'cuz of bad CRC >>> 761605 rx failed 'cuz of PHY err >>> 761605 OFDM timing >>> 4834 periodic calibrations >>> 29 rssi of last ack >>> 27 avg recv rssi >>> -96 rx noise floor >>> 1 switched default/rx antenna >>> Antenna profile: >>> [1] tx 15661485 rx 19452488 >>> [2] tx2 rx0 >>> >>> For compare with flood ping at once: >>> >>> --- R1 ping statistics --- >>> 1 packets transmitted, 1 packets received, 0% packet loss >>> round-trip min/avg/max/stddev = 1.319/1.516/5.594/0.120 ms >>> >>> Almost the same, yes max is even better. >>> >>> >> -- >>> -- >>> -- >>> >>> If I use interval 1/1000 s to send the echo request, the >> situation is >>> rapidly changed. >>> ping -i .001 -c 1 -s 1472 opposite side R1 >>> >>> --- R1 ping statistics --- >>> 1 packets transmitted, 9681 packets received, 3% packet loss >>> round-trip min/avg/max/stddev = 1.319/335.806/564.946/170.691 ms >>> >>> R2# ifconfig -v ath0 >>> ath0: >> flags=8c43 mtu >>> 1500 >>> -- ??? OACTIVE FLAG ? >>> inet6 fe80::20b:6bff:fe2a:c78e%ath0 prefixlen 64 scopeid 0x2 >>> inet 10.XX.YY.ZZ netmask 0xfffc broadcast 10.40.64.19 >>> ether >>> media: IEEE 802.11 Wireless Ethernet OFDM/24Mbps mode 11a >>> (OFDM/24Mbps) >>> status: associated >>> >>> 19350739 data frames received >>> 15765446 data frames transmit >>> 6536 tx frames with an alternate rate >>> 2194842 long on-chip tx retri
Re: panic: integer divide fault on 6.1
Joao Barros wrote: > On 9/9/06, Kris Kennaway <[EMAIL PROTECTED]> wrote: >> On Sat, Sep 09, 2006 at 09:02:35PM +0100, Joao Barros wrote: >> > On 9/9/06, Max Laier <[EMAIL PROTECTED]> wrote: >> > > >> > >Can you try to get a dump, trace, or at least figure out which >> function >> > >the IP is refering to? >> > > >> > >> > Well, the problem only occurs when I boot from the disk and the >> > installed kernel doesn't have debug support. >> > Does 'set dumpdev=' work from the boot loader? I tried some >> > combinations with no success. >> >> No. >> >> > I can try and install a 6-STABLE snapshot if there's no way of getting >> > the info needed. >> >> You can either try to install a new kernel with DDB support, or follow >> the "instruction pointer" method in the developers handbook chapter on >> kernel debugging. > > I copied a CURRENT kernel from a 200608 snapshot and the problem also > occurs thus I'm adding [EMAIL PROTECTED] > My current laptop doesn't have a serial port so I'm copying this by hand: > > Fatal trap 18: integer divide fault while in kernel mode > cpuid = 0; apic id = 00 > instruction pointer = 0x20:0xc08a1fb7 > stack pointer = 0x28:0xc0c20b14 > frame pointer = 0x28:0xc0c20b9c > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = 0 (swapper) > [thread pid 0 tid 0 ] > Stopped at__qdivrem+0x3b: divl%ecx,%eax > > db> bt > Tracing pid 0 tid0 td 0xc0a0c818 > __qdivrem(37fdfa0,0,0,0,0,...) at __qdivrem+0x3b > __udivdi3(37fdfa0,0,0,0) at __udivdi3+0x16 > ata_raid_promise_read_meta(c37a5000,c09f4a80,1,8086,c37a5000,...) at > ata_raid_promise_read_meta+0x9b > ata_raid_read_metadata(c37a5000,c37a5000,c0c20c70,c06b58a4,c37a5000,...) > at ata_raid_metadata+0x2be > ata_raid_subdisk_attach(c37a5000) at ata_raid_subdisk_attach+0x33 > device_attach(c37a5000,c37a5180,c37a5000,c36885c0,0,...) at > device_attach+0x58 > device_probe_and_attach(c37a5200,c37a5200,c08ec9a9,0,c37a5180,...) at > bus_generic_attach+0x16 > ad_attach(c37a5200) at ad_attach+0x2c8 > device_attach(c37a5200,c095f2d0,c37a5200,0,c368d800,...) at > device_attach+0x58 > device_probe_and_attach(c37a5200) at device_probe_and_atach+0xe0 > bus_generic_attach(c3659080,c3659080,,0,c37a5200,...) at > bus_generic_attach+0x16 > ata_identify(c3659080) at ata_identify+0x1c8 > ata_boot_attach(0xc0a11d80,0,c09212e7,47,...) at ata_boot_attach+0x3e > run_interrupt_drive_config_hooks(0,c1ec00,c1e000,0,c0451065,...) at > run_interrupt_drive_config_hooks+0x43 > mi_startup() at mi_startup+0x96 > begin() at begin+0x2c > > This board has a Promise SATA raid controller and it is disabled in > the BIOS. I even tried disabling it through a jumper but it still > stops. > In sys/dev/ata/ata-raid.h the PROMISE_LBA macro does an unchecked calculation that apparently can divide by zero. Soren would likely understand the root cause of this problem but until then you can patch the driver to workaround the problem. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: integer divide fault on 6.1
On 9/9/06, Kris Kennaway <[EMAIL PROTECTED]> wrote: On Sat, Sep 09, 2006 at 09:02:35PM +0100, Joao Barros wrote: > On 9/9/06, Max Laier <[EMAIL PROTECTED]> wrote: > > > >Can you try to get a dump, trace, or at least figure out which function > >the IP is refering to? > > > > Well, the problem only occurs when I boot from the disk and the > installed kernel doesn't have debug support. > Does 'set dumpdev=' work from the boot loader? I tried some > combinations with no success. No. > I can try and install a 6-STABLE snapshot if there's no way of getting > the info needed. You can either try to install a new kernel with DDB support, or follow the "instruction pointer" method in the developers handbook chapter on kernel debugging. I copied a CURRENT kernel from a 200608 snapshot and the problem also occurs thus I'm adding [EMAIL PROTECTED] My current laptop doesn't have a serial port so I'm copying this by hand: Fatal trap 18: integer divide fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0xc08a1fb7 stack pointer = 0x28:0xc0c20b14 frame pointer = 0x28:0xc0c20b9c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) [thread pid 0 tid 0 ] Stopped at __qdivrem+0x3b: divl%ecx,%eax db> bt Tracing pid 0 tid0 td 0xc0a0c818 __qdivrem(37fdfa0,0,0,0,0,...) at __qdivrem+0x3b __udivdi3(37fdfa0,0,0,0) at __udivdi3+0x16 ata_raid_promise_read_meta(c37a5000,c09f4a80,1,8086,c37a5000,...) at ata_raid_promise_read_meta+0x9b ata_raid_read_metadata(c37a5000,c37a5000,c0c20c70,c06b58a4,c37a5000,...) at ata_raid_metadata+0x2be ata_raid_subdisk_attach(c37a5000) at ata_raid_subdisk_attach+0x33 device_attach(c37a5000,c37a5180,c37a5000,c36885c0,0,...) at device_attach+0x58 device_probe_and_attach(c37a5200,c37a5200,c08ec9a9,0,c37a5180,...) at bus_generic_attach+0x16 ad_attach(c37a5200) at ad_attach+0x2c8 device_attach(c37a5200,c095f2d0,c37a5200,0,c368d800,...) at device_attach+0x58 device_probe_and_attach(c37a5200) at device_probe_and_atach+0xe0 bus_generic_attach(c3659080,c3659080,,0,c37a5200,...) at bus_generic_attach+0x16 ata_identify(c3659080) at ata_identify+0x1c8 ata_boot_attach(0xc0a11d80,0,c09212e7,47,...) at ata_boot_attach+0x3e run_interrupt_drive_config_hooks(0,c1ec00,c1e000,0,c0451065,...) at run_interrupt_drive_config_hooks+0x43 mi_startup() at mi_startup+0x96 begin() at begin+0x2c This board has a Promise SATA raid controller and it is disabled in the BIOS. I even tried disabling it through a jumper but it still stops. -- Joao Barros ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Broken loader in STABLE
Thanks very much Tony :-D I removed my CFLAGS and COPTFLAGS from make.conf and just left the CPUTYPE flag and rebuilt and installed kernel and world, all seems to work fine again now, if anything the system seems a bit faster :-D Thanks again. Adam. On Fri, 2006-09-08 at 10:16 +1000, Tony Maher wrote: > Adam Retter wrote: > > On Fri, 2006-09-08 at 08:48 +1000, Tony Maher wrote: > >>Do you have any compile options in /etc/make.conf? > >>These can affect loader. > > > > Yes, these are set in make.conf, but I have always had these set and > > there have been no problems in the past... > > > > > > # Compile for Pentium 4 CPU > > CPUTYPE=p4 > > > > # Compiler optimisation flags > > CFLAGS= -O2 -pipe -funroll-loops -ffast-math > > > > # Compiler optimisation flags for the Kernel > > COPTFLAGS= -O2 -pipe -funroll-loops -ffast-math > > >From private email from someone else with same problem (they had > -funroll-loops in make.conf), > > "optimizations are bad for the loader"... but it still works fine for me >using -O -pipe. > > -- > tonym > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sun, 10 Sep 2006, Karl Denninger wrote: Once the -RELEASE branch is taken, code updates there . I take it you haven't read the text in the handbook that has been linked to by a few posters. You can track changes to a particular release - say by using RELENG_6_1 rather than RELENG_6. In which case, would you still say you are tracking STABLE? -- patrick ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Sun, Sep 10, 2006 at 11:59:10AM +1000, Mark Andrews wrote: > > > Yeah, -STABLE is what you should run if you want stable code, right? > > No. STABLE means STABLE API. > > If you want stable code you run releases. Between releases > stable can become unstable. Think of stable as permanent > BETA code. Changes have passed the first level of testing > in current which is permanent ALPHA code. > > Most of the time beta code is perfectly fine to run but > occasionally things will go wrong. The point of BETA code > is to catch those errors that escape detection in the ALPHA > stage before they make it into a release. That is done by > having a wider diversity of clients run the BETA code. > > Occasionally you have bugs that make it through both the ALPHA > and BETA stages. Of course this assumes that -RELEASE is actually stable and fully suitable for production use. As soon as you find a bug that you can't live with in -RELEASE, you have darn few options other than to updade to -STABLE, especially if there's a commit in the tree that appears to fix the bug in -STABLE. Once the -RELEASE branch is taken, code updates there . Not even Microsoft expects people to live from release to release without bug fixes! In the 10 years I've been running FreeBSD in a production environment I've yet to find a -RELEASE branch that is actually suitable for production use for the duration between -RELEASEs; inevitably a bug that I can't live with requires that I update the source, and what does one update to in this instance? -STABLE. If the project wishes to have -RELEASE be "the stable point" then bug fixes (once FULLY tested) must be back-ported to -RELEASE - otherwise the appearance of a bug you can't live with gives you no other real option than to run the -STABLE track. -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant & Kids Rights Activist http://www.denninger.netMy home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://genesis3.blogspot.comMusings Of A Sentient Mind ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Patch for GBDE rc-script
On Sat, Sep 09, 2006 at 11:22:08PM +0200, Daniel Bond wrote: > On 14:13 Fri 08 Sep, Tobias Roth wrote: > > > > How is this better/different from just adding the gbde device to > > /etc/fstab and have it mounted along with all other filesystems? > > > It says in the handbook: > > "Since encrypted file systems cannot yet be listed in /etc/fstab for automatic > mounting, the file systems must be checked for errors by running fsck(8) > manually before mounting." Interesting. I have had this line in my /etc/fstab for almost a year now and it just works(tm): /dev/ad0s4d.bde /home ufs rw2 2 Since during startup, gbde is run before fsck, I don't see why there would be any problems with this. Thanks, Tobias ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Several issues on Dell 1950/2950 servers (6-STABLE and 7-CURRENT)
On 6-STABLE, those "Error 22" messages on boot, show up too slowly, one character at a time, at about one line every 30 seconds, which delays the boot process on almost 20 (twenty) minutes. After that huge delay, the disc information is shown and the file system is fsck'ed, as usually. However, disabling APIC, eliminates this delay. On 7-CURRENT, there is not such delay, even though APIC was enabled. Oh, okay. Not an mpt issue (I'm somewhat narrowly focussed). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
