Rel 7 works better (was: s/stable/broken/g)
Hi folks, hi Freddy, sorry, missed Your note last year this time. fjwc...@gmail.com aka Freddie Cash schrieb mit Datum Wed, 26 Mar 2008 14:04:00 -0700 in m2n.fbsd.stable: |On March 22, 2008 01:01 pm Peter Much wrote: | Both of them were running Release 5.5, and they were doing all that | is needed, and I was perfectly happy with this. | [...] | So I upgraded the first computer to Release 6.3. The outcome was | |A safer (recommended?) upgrade process when crossing major versions (ie |5.x to 6.x) is to upgrade to the latest release of the old version, |then to the .0 release of the new version, then to the latest release |of the new version. | |So from 5.x to 5.5, then from 5.5 to 6.0, then from 6.0 to 6.3. | |The devs take great pains to make the transition from latest X.x to Y.0 |simple and mostly fool-proof, and the transition from Y.x to Y.z simple |and mostly fool-proof. But there are no guarantees when going from X.x |to Y.z. Maybe its good idea to replay Your message just now, as it seems good advice. I'm just strolling by to tell that I went from 6.3 to 7.2 just now with my testmachine, and this time it was a really good experience so far. I have now only one strangeness, which I think not worth a bug report, but I would invite You to think about what that can be. I post a separate note with better subject for that. And yes, I did ignore the good advice again, but 7.2 isn't officially out for release yet, so there are no safety belts anyway. rgds, PMc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: s/stable/broken/g
On Thu, Mar 27, 2008 at 12:45:13AM +0100, Peter Much wrote:
On Wed, Mar 26, 2008 at 05:00:12PM -0400, John Baldwin wrote:
! Try this patch for de(4).
Thanks fpr the reply. I'll try this patch at next reboot.
! You need to supply the panic details for the devfs
! one (I've used devfs rules w/o issue on lots of machines
! via /etc/devfs.conf).
I have found, eh, not the solution but the problem. ;)
This one: kern/89784 describes the same symptom and nearly
the same backtrace. And it is still open, so this, well, just
seems to exist. And, things being this way, I don't think
there is need for me to do any more about it for now, as
this does not really hurt and workaround is easy.
Try the rev. 1.24 of the devfs_rule.c. In fact, it is fixed by somewhat
bigger patch that I inlined below. It is already in CURRENT and RELENG_7.
Index: fs/devfs/devfs_rule.c
===
RCS file: /usr/local/arch/ncvs/src/sys/fs/devfs/devfs_rule.c,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- fs/devfs/devfs_rule.c 6 Nov 2006 13:41:56 - 1.23
+++ fs/devfs/devfs_rule.c 20 Mar 2008 16:08:42 - 1.24
@@ -527,6 +527,7 @@
{
struct devfs_rule *dr = dk-dk_rule;
struct cdev *dev;
+ struct cdevsw *dsw;
dev = devfs_rule_getdev(de);
/*
@@ -540,13 +541,19 @@
* They're actually testing to see whether the condition does
* *not* match, since the default is to assume the rule should
* be run (such as if there are no conditions).
-*
-* XXX: lacks threadref on dev
*/
- if (dr-dr_icond DRC_DSWFLAGS)
- if (dev == NULL ||
- (dev-si_devsw-d_flags dr-dr_dswflags) == 0)
+ if (dr-dr_icond DRC_DSWFLAGS) {
+ if (dev == NULL)
+ return (0);
+ dsw = dev_refthread(dev);
+ if (dsw == NULL)
+ return (0);
+ if ((dsw-d_flags dr-dr_dswflags) == 0) {
+ dev_relthread(dev);
return (0);
+ }
+ dev_relthread(dev);
+ }
if (dr-dr_icond DRC_PATHPTRN)
if (!devfs_rule_matchpath(dk, de))
return (0);
Index: vm/vm_mmap.c
===
RCS file: /usr/local/arch/ncvs/src/sys/vm/vm_mmap.c,v
retrieving revision 1.217
retrieving revision 1.218
diff -u -r1.217 -r1.218
--- vm/vm_mmap.c16 Mar 2008 10:58:09 - 1.217
+++ vm/vm_mmap.c20 Mar 2008 16:08:42 - 1.218
@@ -1160,6 +1160,7 @@
void *handle;
vm_object_t obj;
struct mount *mp;
+ struct cdevsw *dsw;
int error, flags, type;
int vfslocked;
@@ -1190,13 +1191,19 @@
type = OBJT_DEVICE;
handle = vp-v_rdev;
- /* XXX: lack thredref on device */
- if(vp-v_rdev-si_devsw-d_flags D_MMAP_ANON) {
+ dsw = dev_refthread(handle);
+ if (dsw == NULL) {
+ error = ENXIO;
+ goto done;
+ }
+ if (dsw-d_flags D_MMAP_ANON) {
+ dev_relthread(handle);
*maxprotp = VM_PROT_ALL;
*flagsp |= MAP_ANON;
error = 0;
goto done;
}
+ dev_relthread(handle);
/*
* cdevs does not provide private mappings of any kind.
*/
@@ -1273,16 +1280,21 @@
struct cdev *cdev, vm_ooffset_t foff, vm_object_t *objp)
{
vm_object_t obj;
+ struct cdevsw *dsw;
int flags;
flags = *flagsp;
- /* XXX: lack thredref on device */
- if (cdev-si_devsw-d_flags D_MMAP_ANON) {
+ dsw = dev_refthread(cdev);
+ if (dsw == NULL)
+ return (ENXIO);
+ if (dsw-d_flags D_MMAP_ANON) {
+ dev_relthread(cdev);
*maxprotp = VM_PROT_ALL;
*flagsp |= MAP_ANON;
return (0);
}
+ dev_relthread(cdev);
/*
* cdevs does not provide private mappings of any kind.
*/
pgpAxLJ0F71nc.pgp
Description: PGP signature
Re: s/stable/broken/g
On Wed, Mar 26, 2008 at 10:06:04PM +0100, Kris Kennaway wrote: ! Software always has bugs, and it is a mistake to think that the stable ! designation does not mean has no bugs. It's unfortunate that you have ! hit a couple of them, but please continue to work through the process of ! documenting them. Oh, don't worry, sure I do! I was just wondering where we are heading. I did not perceive this kind of problems the earlier upgrades (since Release 2) - sure there were problems with the new stuff, but not with the established things. And I do not worry if support for something is not happening or is dropped (due to lack of interest or ressources or whatever), but if already existing functionality just silently goes away with apparently nobody noticing, then I perceive it as a loss of one of the core values of a *nix-on-pc: that you do not need to buy new and fast hardware to get things done (you only need *reliable* hardware - and the newer one often is reliable only if built for servers; the consumer stuff is just getting WORSE.) ! With regards to your ethernet problems, old cards like ed do not get ! much testing thesedays because few people use them. Combined with the ! fact that ethernet problems are often specific to certain hardware ! models or revisions, you may be the only person to have tried this ! particular case in many years. Well, there are two reasons why I am using them: 1) if you place twisted-pair under the carpet, it will break after some months. On BNC cables i can walk for years, it does no harm. :) 2) It's true, i get a lovely dual if_fxp 10/100 64bit card on ebay for 1 euro, and it actually runs on a pentium2 - but i need a router then; and there what i get -at the consumer end- is so incredibly full of bugs, I will not rely on these! And I cannot fix them. :( ! By the same token, these problems are ! difficult to fix without a developer having access to the same problem ! hardware. You might consider offering to ship it to an interested ! developer if one can be found. I definitely will! The question is if a problem comes from an extravagance in one specific model of hardware (then it is not worth to put work into ancient hardware), or if there was a logical coding mistake during development within an existing codepiece that is now seldom used. The latter I would like to have fixed. And the other point is: I do not currently know how well people in less developed countries are supplied with suitable hardware - but I see them picking up on *nix - and I like that. :) rgds, PMc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: s/stable/broken/g
! Try the rev. 1.24 of the devfs_rule.c. In fact, it is fixed by somewhat ! bigger patch that I inlined below. It is already in CURRENT and RELENG_7. Thanks, this is cool: it seems to work on Rel. 6.3. :) rgds, PMc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: s/stable/broken/g
And the party continues... When starting my usual environment, there is already the next pagefault kernel panic! Tracking it down... it's the type keyword in devfs rules. According to the manpage, support for this was _not_ withdrawn. But actually, entering something like devfs rule apply type tape WHATEVER crashes the system. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
s/stable/broken/g
Dear all, I have two computers. Both of them were running Release 5.5, and they were doing all that is needed, and I was perfectly happy with this. Now, as we know, security support for Release 5.5 will terminate during this spring, and as my computers are exposed to the Internet, this means that I MUST upgrade, even while I do not need or want anything from a higher release. So I upgraded the first computer to Release 6.3. The outcome was that on this computer, where Release 5 was running just fine for years, a Generic 6.3 kernel would just pagefault during boot. Nogo at all. I searched for the problem, and found it to be the network card - which is just a common standard de0 PCI card. Now, without network I cannot access the Internet, and if I do not access the Internet, then I do not need to upgrade! This is some kind of catch22. So I searched for the bug, I found something, I fixed it, and it helped. I published a description of the problem and the fix via sendbug (kern/120915) - but apparently nobody seems to be interested in a nonfunctional network on a so-called production release. Actually, I do not know what else I would have to do besides finding the bug, isolating the bug, creating a fix, using the fix and publishing the fix? So now I started to upgrade my second computer to Release 6.3. And when booting the Generic kernel, it does just pagefault quickly after booting is completed. I isolated the problem - it is the network card. This one is a well-known standard ed0 ISA card that has worked fine for 15 years now, and it pagefaults as soon as the first data is transferred. I replaced the card with one of a different brand (but also ed0), and the problem went away. So, the mere statistical evidence is this: when upgrading from release 5.5 to 6.3, 100% of the computers that did work fine with 5.5 do no longer run. I suppose the next thing I should do is some kind of reality check, to adjust my understanding of the words stable, production and upgrade. :-/ But the more severe aspect of the matter is, if this is a trend that will intensify with further upgrades, and if so, then what to do about it. never change a running system would be a good approach, if there were not the security issues. The other approach is to always buy new hardware. That is the Windows approach, and I do not like it. When a Pentium-II/350 is only 10% loaded, then why should one get a new computer for the job?? It just eats more power and creates ecohazard waste. :-( rgds, PMc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: s/stable/broken/g
On Sunday 23 March 2008 02:50:36 pm Peter Much wrote: And the party continues... When starting my usual environment, there is already the next pagefault kernel panic! Tracking it down... it's the type keyword in devfs rules. According to the manpage, support for this was _not_ withdrawn. But actually, entering something like devfs rule apply type tape WHATEVER crashes the system. Try this patch for de(4). You need to supply the panic details for the devfs one (I've used devfs rules w/o issue on lots of machines via /etc/devfs.conf). Index: if_de.c === RCS file: /usr/cvs/src/sys/dev/de/if_de.c,v retrieving revision 1.183 diff -u -r1.183 if_de.c --- if_de.c 7 Jun 2007 00:28:47 - 1.183 +++ if_de.c 26 Mar 2008 20:58:19 - @@ -4053,7 +4053,8 @@ /* * bounce a copy to the bpf listener, if any. */ -BPF_MTAP(sc-tulip_ifp, m); +if (!(sc-tulip_flags TULIP_DEVICEPROBE)) + BPF_MTAP(sc-tulip_ifp, m); /* * The descriptors have been filled in. Now get ready -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: s/stable/broken/g
Peter Much wrote: And the party continues... When starting my usual environment, there is already the next pagefault kernel panic! Tracking it down... it's the type keyword in devfs rules. According to the manpage, support for this was _not_ withdrawn. But actually, entering something like devfs rule apply type tape WHATEVER crashes the system. Software always has bugs, and it is a mistake to think that the stable designation does not mean has no bugs. It's unfortunate that you have hit a couple of them, but please continue to work through the process of documenting them. With regards to your ethernet problems, old cards like ed do not get much testing thesedays because few people use them. Combined with the fact that ethernet problems are often specific to certain hardware models or revisions, you may be the only person to have tried this particular case in many years. By the same token, these problems are difficult to fix without a developer having access to the same problem hardware. You might consider offering to ship it to an interested developer if one can be found. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: s/stable/broken/g
Kris Kennaway wrote: Peter Much wrote: And the party continues... When starting my usual environment, there is already the next pagefault kernel panic! Tracking it down... it's the type keyword in devfs rules. According to the manpage, support for this was _not_ withdrawn. But actually, entering something like devfs rule apply type tape WHATEVER crashes the system. Software always has bugs, and it is a mistake to think that the stable designation does not mean has no bugs. One too many negatives in that sentence. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: s/stable/broken/g
On March 22, 2008 01:01 pm Peter Much wrote: Both of them were running Release 5.5, and they were doing all that is needed, and I was perfectly happy with this. Now, as we know, security support for Release 5.5 will terminate during this spring, and as my computers are exposed to the Internet, this means that I MUST upgrade, even while I do not need or want anything from a higher release. So I upgraded the first computer to Release 6.3. The outcome was A safer (recommended?) upgrade process when crossing major versions (ie 5.x to 6.x) is to upgrade to the latest release of the old version, then to the .0 release of the new version, then to the latest release of the new version. So from 5.x to 5.5, then from 5.5 to 6.0, then from 6.0 to 6.3. The devs take great pains to make the transition from latest X.x to Y.0 simple and mostly fool-proof, and the transition from Y.x to Y.z simple and mostly fool-proof. But there are no guarantees when going from X.x to Y.z. -- Freddie Cash [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: s/stable/broken/g
On Wed, Mar 26, 2008 at 05:00:12PM -0400, John Baldwin wrote: ! Try this patch for de(4). Thanks fpr the reply. I'll try this patch at next reboot. ! You need to supply the panic details for the devfs ! one (I've used devfs rules w/o issue on lots of machines ! via /etc/devfs.conf). I have found, eh, not the solution but the problem. ;) This one: kern/89784 describes the same symptom and nearly the same backtrace. And it is still open, so this, well, just seems to exist. And, things being this way, I don't think there is need for me to do any more about it for now, as this does not really hurt and workaround is easy. Actually, the horror is not that something does not work - the horror is when, in an ambitiously complex setup which isn't fun to upgrade anyway, the next pagefault derisively grins at you, at the point when you would like to finish and go for a sleep, or a beer - and you know there are some good friends who have placed some web-stuff onto the machine, and you don't want to disappoint them... It's a situation where one enjoys reaching a good availability, but far from worth setting up an identical test environment (which would be the appropriate strategy to really avoid such surprizes). rgds, PMc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
