Re: newer GENERIC (4.2) don't support mcd0
On Mon, Dec 25, 2000 at 04:55:08PM -0800, Mike Smith wrote: Trying to upgrade an existing 3.4 system to 4.2 failed due to kernel.GENERIC not having mcd0 built in anymore (MITSUMI CDROM) :-( Please add that back again. No. The Matsushita/Mitsumi/Sony CDROM interfaces have gone the way of the 3c501. The drivers are there, and if you're really desperate, you're welcome to try them, but they're not supported install devices anymore. Note that it's trivial to build a custom installation kernel these days, and in your case, it would be the simplest answer. Well, although I may have the tools and host machines around normally, in this particular case, where I'm upgrading an ISDN gateway machine I'm really on my own and have no 4.2 kernel build environment at hand. When the drivers are there, what would be the price for adding them into the GENERIC installation kernel? Couldn't the drivers be loaded as modules and test against presence of the hardware similar like Linux or NT do it? We have a two floppy installation kit anyway, so it should not be a disk space problem only. -- Chris Christoph P. U. Kukulies [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: newer GENERIC (4.2) don't support mcd0
Please add that back again. No. The Matsushita/Mitsumi/Sony CDROM interfaces have gone the way of the 3c501. The drivers are there, and if you're really desperate, you're welcome to try them, but they're not supported install devices anymore. Note that it's trivial to build a custom installation kernel these days, and in your case, it would be the simplest answer. Well, although I may have the tools and host machines around normally, in this particular case, where I'm upgrading an ISDN gateway machine I'm really on my own and have no 4.2 kernel build environment at hand. Then you are in an unfortunate situation, and we're terribly sorry, but your hardware simply isn't supported by the installation environment. When the drivers are there, what would be the price for adding them into the GENERIC installation kernel? Space. Couldn't the drivers be loaded as modules and test against presence of the hardware similar like Linux or NT do it? We have a two floppy installation kit anyway, so it should not be a disk space problem only. It is a space problem. You can trivially put modules on a third floppy, but you would first need to turn the matcd driver into a module, which you are encouraged to do as you appear to be one of the three people left in the world with a functioning Matsushita drive - a necessary prerequisite for this activity. 8) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
NFS/VM panic in current with INVARIANTS
Hi Matt I'm getting a reliable panic on CURRENT (2000/12/26) with INVARIANTS set. I suppose I could "fix" this by taking out INVARIANTS, but it seems to make more sense to try to get it fixed. The panic() is "freeing free entry", and the traceback (minus most of the numbers) is: panic zerror zfreei NDFREE nfsrv_lookup nfs_nfsd nfssvc syscall(2f, 2f, 2f, 1, 0) xint0x80 NFS activity (not mounting) triggers it. The panic happens on the server box, which is a dual-cpu i386 class running an SMP kernel. What else do you need? M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI says: too many dependant configs(?)
Since we are on the subject of ACPI, it is working great except for one thing, it can't attach my sound card to the pcm device (does that sound correct?). It definitely sees it: unknown: YMH0021 can't assign resources This would suggest that something else is taking one or more of the resources that the device needs; on top of that, you may not have the driver necessary for this device in your kernel (you need 'isa' and 'pcm'). Looks like the yamaha chipset to me. If I could get sound working, I'd definitely be using acpica all the time. The PnP BIOS code should pick this up as well, as long as your PnP BIOS works. I think the thermal management has been improved since the last time I tried it -- it kept the temp 356K. Is there any way to set a temperature to be maintained? Or some way to actually query the current temperature? (lmmon doesnt work) The ACPI thermal management code doesn't actually work yet (it's being worked on). You don't set a temperature; the platform tells the OS what temperature(s) to maintain based on power profile, etc. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ffs_valloc: dup alloc panics with stable/current
We got old Mylex DAC960PD-Ultra-raid-adapter and have tried to use it with FreeBSD 4.2-stable and 5.0-current. Adapter is configured with three luns 5+5*9G, 8+8*9G (raid5) and 1+1*2G (mirrored boot disk). All 9G disks are quite old Seagate Barracuda 9 disks ST19171W. System is working quite well but under heavier load we start to get scsi errors from luns. This is not so bad but 5-30 minutes after this command system will always panic. cd /uu ; dump 0buf 126 - /w | restore xbf 126 - mode = 0100644, inum = 720391, fs = /uu panic: ffs_valloc: dup alloc Hi, I wrote about these problems two weeks ago. After this we had done lot of testing with this system and last 4 days system has been up and running. We still get scsi errors but it doesn't seem to harm system drives. Panic problem hasn't appeared since we changed mylex config. Now we are running only 8 disks on two channels and one raid5 system drive on both. Any thoughts why this works better than the old configuration? I don't have any bright ideas about why this would be more reliable, sorry. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: newer GENERIC (4.2) don't support mcd0
Mike Smith wrote: Please add that back again. No. The Matsushita/Mitsumi/Sony CDROM interfaces have gone the way of the 3c501. The drivers are there, and if you're really desperate, you're welcome to try them, but they're not supported install devices anymore. eed to turn the matcd driver into a module, which you are encouraged to do as you appear to be one of the three people left in the world with a functioning Matsushita drive - a necessary prerequisite for this activity. 8) Just a note, the mcd driver still works fine in current, but needs the options COMPAT_OLDISA. I ended up using an old Mitsumi 2x for awhile when a faster cdrom drive bit the dust. Cheers Kelvin [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Fixing a.out compatibility
I'll try to summarise the position so far: 1) Legacy a.out executable support is broken for a subset (size unknown) of such executables. 2) We can ignore this or repair this. 3) We can build a new binary or just look around on old 3.x CDs until we find one that works. 4) We can generate a working binary on 4.x or on 2.2.8-stable (after some fixing). 5) We can generate ld.so anew each release, or generate it (or find it) once and commit a binary. I don't think there's any doubt about point 1. All a.out executables that use libc.so.2.2 and another recompiled library will fail because of a missing routine (__error) required by the recompiled library and not supplied by libc or by executable or by the existing ld.so. All these executables come from the 2.2.x era or earlier. Those built in the 3.x era use libc 3.1 and don't have this problem. Urk... Actually, it's slightly more complicated than that since the libc.so.3.1 built on 2.2.6 (for example) didn't contain __error() but the one built on 2.2.7 did. (At least according to the cvs logs). I'm most annoyed that I can't find my 2.2.6 CDs. 2.2.5 had libc 3.0 (without __error) and 2.2.7 had libc 3.1 (with __error) but the cvs logs say that 2.2.6 should have had a different libc 3.1 (without __error). So, the exact "version" of version 3.1 of libc could be important. Yuck. We don't normally ignore things we can fix, so point 2 is resolved in favour of fixing this, right? We need to build a new binary since we (collectively) have forgotten where the working 3.0 through 3.2 binaries came from. :-( Can we, for example, prove that revision 1.57 made in into any release? It seems feasable to generate a new binary on a recent or an old patched FreeBSD version. The question is which is better. I think the newer the better. Otherwise, who is going to build the 2.2.8-stable box to make this one binary? I've already built a binary on 4.2-release that works. We disagree a bit over point 5. I think it is feasable and desirable to build ld.so at each release. If we don't build it for each release, how will fixes to rtld-aout and required libraries (eg libc) be incorporated? I say keep building it fresh until a.out builds are impossible. Or are you suggesting that each advance in 4.x and beyond be backported to 2.2.8-stable so that we can build one binary? So, where to from here? Despite all my arguments, I could just commit the binary I have to the lib/compat2* areas and leave it at that. Stephen. PS Thanks for all the "old_RELENG_2_2" etc tags now available in rtld-aout. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS/VM panic in current with INVARIANTS
:Hi Matt
:
:I'm getting a reliable panic on CURRENT (2000/12/26) with INVARIANTS
:set. I suppose I could "fix" this by taking out INVARIANTS, but it
:seems to make more sense to try to get it fixed.
:
:The panic() is "freeing free entry", and the traceback (minus most
:of the numbers) is:
:
:panic
:zerror
:zfreei
:NDFREE
:nfsrv_lookup
:nfs_nfsd
:nfssvc
:syscall(2f, 2f, 2f, 1, 0)
:xint0x80
:
:NFS activity (not mounting) triggers it. The panic happens on the
:server box, which is a dual-cpu i386 class running an SMP kernel.
:
:What else do you need?
:
:M
:--
:Mark Murray
:Warning: this .sig is umop ap!sdn
It could be real, but it's impossible for me to tell because
whoever wrote the INVARIANTS code for _zfree() wrote completely
and utterly illegal code.
static __inline__ void
_zfree(vm_zone_t z, void *item)
{
((void **) item)[0] = z-zitems;
#ifdef INVARIANTS
if (((void **) item)[1] == (void *) ZENTRY_FREE)
zerror(ZONE_ERROR_ALREADYFREE);
((void **) item)[1] = (void *) ZENTRY_FREE;
#endif
z-zitems = item;
z-zfreecnt++;
}
For all we know, item[1] might contain ZENTRY_FREE normally! This
type of invariant code check is just asking for it.
I don't see anything specifically wrong with nfs's use of NDFREE. It's
sophisticated enough that there certainly could be an issue there.
In order to tell for sure, the _zfree() code needs to have a little more
sophistication. When it finds a ZENTRY_FREE, that's only a hint... it
really needs to also iterate through the items list to see if the
structure is in fact already on the freelist. Please try the below
(completely untested!!) patch and see if you still get the panic.
-Matt
Index: vm_zone.h
===
RCS file: /home/ncvs/src/sys/vm/vm_zone.h,v
retrieving revision 1.13
diff -u -r1.13 vm_zone.h
--- vm_zone.h 1999/08/28 00:52:44 1.13
+++ vm_zone.h 2000/12/26 18:39:07
@@ -102,8 +102,14 @@
{
((void **) item)[0] = z-zitems;
#ifdef INVARIANTS
- if (((void **) item)[1] == (void *) ZENTRY_FREE)
- zerror(ZONE_ERROR_ALREADYFREE);
+ if (((void **) item)[1] == (void *) ZENTRY_FREE) {
+ void *scan;
+
+ for (scan = z-zitems; scan; scan = ((void **)scan)[0]) {
+ if (scan == item)
+ zerror(ZONE_ERROR_ALREADYFREE);
+ }
+ }
((void **) item)[1] = (void *) ZENTRY_FREE;
#endif
z-zitems = item;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: newer GENERIC (4.2) don't support mcd0
From the keyboard of Mike Smith: It is a space problem. You can trivially put modules on a third floppy, but you would first need to turn the matcd driver into a module, which you are encouraged to do as you appear to be one of the three people left in the world with a functioning Matsushita drive - a necessary prerequisite for this activity. 8) At least four people. I have two Mitsumi drives/controllers supported by the mcd driver and i offer shipping them to anyone who want to take over maintaining and enhancing the driver :-) hellmuth -- Hellmuth MichaelisTel +49 40 55 97 47-70 HCS Hanseatischer Computerservice GmbHFax +49 40 55 97 47-77 Oldesloer Strasse 97-99 Mail hm [at] hcs.de D-22457 Hamburg WWW http://www.hcs.de To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: src/etc/netstart
Akinori MUSHA wrote: Seems you broke an error message of src/etc/netstart when committing a series of quoting style fixes. So I did, thanks for pointing it out. :) It's fixed now. Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS/VM panic in current with INVARIANTS
On Tue, Dec 26, 2000 at 02:00:54PM +0200, Mark Murray wrote: I'm getting a reliable panic on CURRENT (2000/12/26) with INVARIANTS set. I suppose I could "fix" this by taking out INVARIANTS, but it seems to make more sense to try to get it fixed. Do you have NFS compiled in to the kernel? I've had trouble using INVARIANTS in the kernel and NFS as a module many times - it always panics in the zone allocation stuff. (Either you always need to compile modules with the same INVARIENTS options as the kernel, or we need to fix INVARIENTS so it doesn't change the expected behaviour of anything in the kernel) David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS/VM panic in current with INVARIANTS
:Do you have NFS compiled in to the kernel? I've had trouble using :INVARIANTS in the kernel and NFS as a module many times - it always :panics in the zone allocation stuff. : :(Either you always need to compile modules with the same INVARIENTS :options as the kernel, or we need to fix INVARIENTS so it doesn't :change the expected behaviour of anything in the kernel) : : David. zalloc/zfree have inlined components. Mixing INVARIENTS is virtually guarenteed to crash the NDFREE code because the expected magic numbers will not be there. I sure hope this turns out to be Mark's problem. I have a feeling that the issue may go deeper. There is conditional code in the zalloc/zfree inlines for SMP vs non-SMP. This will break modules in an SMP system worse then the INVARIENTS will. I mean *seriously* break... massive corruption and the like can occur. I think the only real solution is to rip out the externally visible zalloc/zfree inlines and replace them with real routines. I will happily do this, those inlines have always been an eyesore to me and the performance benefit is minimal at best. That will solve the SMP and INVARIENTS mixing problem (at least for zalloc/zfree). -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS/VM panic in current with INVARIANTS
Matt Dillon [EMAIL PROTECTED] writes: I think the only real solution is to rip out the externally visible zalloc/zfree inlines and replace them with real routines. I will happily do this, those inlines have always been an eyesore to me and the performance benefit is minimal at best. That will solve the SMP and INVARIENTS mixing problem (at least for zalloc/zfree). Just make them always call zalloci() and zfreei(). /assar To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS/VM panic in current with INVARIANTS
: :Matt Dillon [EMAIL PROTECTED] writes: : I think the only real solution is to rip out the externally visible : zalloc/zfree inlines and replace them with real routines. I will happily : do this, those inlines have always been an eyesore to me and the : performance benefit is minimal at best. That will solve the SMP and : INVARIENTS mixing problem (at least for zalloc/zfree). : :Just make them always call zalloci() and zfreei(). : :/assar I don't think that's good enough. At the moment the API for non-interrupt operation is zalloc() and zfree(), and zalloci() and zfreei() are supposed to be called from interrupts.If we intend to keep both families (zalloc() and zalloci()), then both families have to work properly. If we intend to remove one family (i.e. remove the zalloc() family), then we have to physically remove the calls from the codebase to prevent anyone from accidently calling them from an SMP build. We can't just go do an end-run around the established API as a hack around the problem. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS/VM panic in current with INVARIANTS
Matt Dillon [EMAIL PROTECTED] writes:
We can't just go do an end-run around the established API as a
hack around the problem.
I fail too se how my suggestion would change the API at all, but in
case I was unclear, diffs are below.
/assar
Index: vm_zone.c
===
RCS file: /home/ncvs/src/sys/vm/vm_zone.c,v
retrieving revision 1.35
diff -u -w -r1.35 vm_zone.c
--- vm_zone.c 2000/12/13 10:01:00 1.35
+++ vm_zone.c 2000/12/27 00:13:44
@@ -32,6 +32,81 @@
static MALLOC_DEFINE(M_ZONE, "ZONE", "Zone header");
+#include machine/lock.h
+
+struct vm_zone {
+ struct simplelock zlock;/* lock for data structure */
+ void*zitems;/* linked list of items */
+ int zfreecnt; /* free entries */
+ int zfreemin; /* minimum number of free entries */
+ int znalloc;/* number of allocations */
+ vm_offset_t zkva; /* Base kva of zone */
+ int zpagecount; /* Total # of allocated pages */
+ int zpagemax; /* Max address space */
+ int zmax; /* Max number of entries allocated */
+ int ztotal; /* Total entries allocated now */
+ int zsize; /* size of each entry */
+ int zalloc; /* hint for # of pages to alloc */
+ int zflags; /* flags for zone */
+ int zallocflag; /* flag for allocation */
+ struct vm_object *zobj; /* object to hold zone */
+ char*zname; /* name for diags */
+ struct vm_zone *znext; /* list of zones for sysctl */
+};
+
+#define ZONE_ERROR_INVALID 0
+#define ZONE_ERROR_NOTFREE 1
+#define ZONE_ERROR_ALREADYFREE 2
+
+#define ZONE_ROUNDING 32
+
+#define ZENTRY_FREE0x12342378
+/*
+ * void *zalloc(vm_zone_t zone) --
+ * Returns an item from a specified zone.
+ *
+ * void zfree(vm_zone_t zone, void *item) --
+ * Frees an item back to a specified zone.
+ */
+static __inline__ void *
+_zalloc(vm_zone_t z)
+{
+ void *item;
+
+#ifdef INVARIANTS
+ if (z == 0)
+ zerror(ZONE_ERROR_INVALID);
+#endif
+
+ if (z-zfreecnt = z-zfreemin)
+ return _zget(z);
+
+ item = z-zitems;
+ z-zitems = ((void **) item)[0];
+#ifdef INVARIANTS
+ if (((void **) item)[1] != (void *) ZENTRY_FREE)
+ zerror(ZONE_ERROR_NOTFREE);
+ ((void **) item)[1] = 0;
+#endif
+
+ z-zfreecnt--;
+ z-znalloc++;
+ return item;
+}
+
+static __inline__ void
+_zfree(vm_zone_t z, void *item)
+{
+ ((void **) item)[0] = z-zitems;
+#ifdef INVARIANTS
+ if (((void **) item)[1] == (void *) ZENTRY_FREE)
+ zerror(ZONE_ERROR_ALREADYFREE);
+ ((void **) item)[1] = (void *) ZENTRY_FREE;
+#endif
+ z-zitems = item;
+ z-zfreecnt++;
+}
+
/*
* This file comprises a very simple zone allocator. This is used
* in lieu of the malloc allocator, where needed or more optimal.
Index: vm_zone.h
===
RCS file: /home/ncvs/src/sys/vm/vm_zone.h,v
retrieving revision 1.13
diff -u -w -r1.13 vm_zone.h
--- vm_zone.h 1999/08/28 00:52:44 1.13
+++ vm_zone.h 2000/12/27 00:13:44
@@ -21,29 +21,9 @@
#define ZONE_INTERRUPT 1 /* Use this if you need to allocate at int time */
#define ZONE_BOOT 16/* This is an internal flag used by zbootinit */
-#include machine/lock.h
+struct vm_zone;
+typedef struct vm_zone *vm_zone_t;
-typedef struct vm_zone {
- struct simplelock zlock;/* lock for data structure */
- void*zitems;/* linked list of items */
- int zfreecnt; /* free entries */
- int zfreemin; /* minimum number of free entries */
- int znalloc;/* number of allocations */
- vm_offset_t zkva; /* Base kva of zone */
- int zpagecount; /* Total # of allocated pages */
- int zpagemax; /* Max address space */
- int zmax; /* Max number of entries allocated */
- int ztotal; /* Total entries allocated now */
- int zsize; /* size of each entry */
- int zalloc; /* hint for # of pages to alloc */
- int zflags; /* flags for zone */
- int zallocflag; /* flag for allocation */
- struct vm_object *zobj; /* object to hold zone */
- char*zname; /* name for diags */
- struct vm_zone *znext; /* list of zones for sysctl */
-} *vm_zone_t;
-
-
void zerror __P((int)) __dead2;
vm_zone_t zinit __P((char *name, int size, int nentries,
Re: NFS/VM panic in current with INVARIANTS
:Matt Dillon [EMAIL PROTECTED] writes: : We can't just go do an end-run around the established API as a : hack around the problem. : :I fail too se how my suggestion would change the API at all, but in :case I was unclear, diffs are below. : :/assar : Well, yes... that's essentially what I suggested. You didn't say anything about removing the externalized inlines, which is what you do in your patch. Looks like a fine patch to me. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS/VM panic in current with INVARIANTS
Matt Dillon [EMAIL PROTECTED] writes:
Well, yes... that's essentially what I suggested. You didn't say
anything about removing the externalized inlines, which is what you
do in your patch. Looks like a fine patch to me.
Except it didn't work. Now here's a patch that survived building a
kernel and modules. ok?
/assar
Index: vm_zone.c
===
RCS file: /home/ncvs/src/sys/vm/vm_zone.c,v
retrieving revision 1.35
diff -u -w -r1.35 vm_zone.c
--- vm_zone.c 2000/12/13 10:01:00 1.35
+++ vm_zone.c 2000/12/27 00:59:14
@@ -32,6 +32,59 @@
static MALLOC_DEFINE(M_ZONE, "ZONE", "Zone header");
+#define ZONE_ERROR_INVALID 0
+#define ZONE_ERROR_NOTFREE 1
+#define ZONE_ERROR_ALREADYFREE 2
+
+#define ZONE_ROUNDING 32
+
+#define ZENTRY_FREE0x12342378
+/*
+ * void *zalloc(vm_zone_t zone) --
+ * Returns an item from a specified zone.
+ *
+ * void zfree(vm_zone_t zone, void *item) --
+ * Frees an item back to a specified zone.
+ */
+static __inline__ void *
+_zalloc(vm_zone_t z)
+{
+ void *item;
+
+#ifdef INVARIANTS
+ if (z == 0)
+ zerror(ZONE_ERROR_INVALID);
+#endif
+
+ if (z-zfreecnt = z-zfreemin)
+ return _zget(z);
+
+ item = z-zitems;
+ z-zitems = ((void **) item)[0];
+#ifdef INVARIANTS
+ if (((void **) item)[1] != (void *) ZENTRY_FREE)
+ zerror(ZONE_ERROR_NOTFREE);
+ ((void **) item)[1] = 0;
+#endif
+
+ z-zfreecnt--;
+ z-znalloc++;
+ return item;
+}
+
+static __inline__ void
+_zfree(vm_zone_t z, void *item)
+{
+ ((void **) item)[0] = z-zitems;
+#ifdef INVARIANTS
+ if (((void **) item)[1] == (void *) ZENTRY_FREE)
+ zerror(ZONE_ERROR_ALREADYFREE);
+ ((void **) item)[1] = (void *) ZENTRY_FREE;
+#endif
+ z-zitems = item;
+ z-zfreecnt++;
+}
+
/*
* This file comprises a very simple zone allocator. This is used
* in lieu of the malloc allocator, where needed or more optimal.
Index: vm_zone.h
===
RCS file: /home/ncvs/src/sys/vm/vm_zone.h,v
retrieving revision 1.13
diff -u -w -r1.13 vm_zone.h
--- vm_zone.h 1999/08/28 00:52:44 1.13
+++ vm_zone.h 2000/12/27 00:59:14
@@ -43,7 +43,6 @@
struct vm_zone *znext; /* list of zones for sysctl */
} *vm_zone_t;
-
void zerror __P((int)) __dead2;
vm_zone_t zinit __P((char *name, int size, int nentries, int flags,
int zalloc));
@@ -57,77 +56,16 @@
int nitems));
void * _zget __P((vm_zone_t z));
-#define ZONE_ERROR_INVALID 0
-#define ZONE_ERROR_NOTFREE 1
-#define ZONE_ERROR_ALREADYFREE 2
-
-#define ZONE_ROUNDING 32
-
-#define ZENTRY_FREE0x12342378
-/*
- * void *zalloc(vm_zone_t zone) --
- * Returns an item from a specified zone.
- *
- * void zfree(vm_zone_t zone, void *item) --
- * Frees an item back to a specified zone.
- */
-static __inline__ void *
-_zalloc(vm_zone_t z)
-{
- void *item;
-
-#ifdef INVARIANTS
- if (z == 0)
- zerror(ZONE_ERROR_INVALID);
-#endif
-
- if (z-zfreecnt = z-zfreemin)
- return _zget(z);
-
- item = z-zitems;
- z-zitems = ((void **) item)[0];
-#ifdef INVARIANTS
- if (((void **) item)[1] != (void *) ZENTRY_FREE)
- zerror(ZONE_ERROR_NOTFREE);
- ((void **) item)[1] = 0;
-#endif
-
- z-zfreecnt--;
- z-znalloc++;
- return item;
-}
-
-static __inline__ void
-_zfree(vm_zone_t z, void *item)
-{
- ((void **) item)[0] = z-zitems;
-#ifdef INVARIANTS
- if (((void **) item)[1] == (void *) ZENTRY_FREE)
- zerror(ZONE_ERROR_ALREADYFREE);
- ((void **) item)[1] = (void *) ZENTRY_FREE;
-#endif
- z-zitems = item;
- z-zfreecnt++;
-}
-
static __inline__ void *
zalloc(vm_zone_t z)
{
-#if defined(SMP)
return zalloci(z);
-#else
- return _zalloc(z);
-#endif
}
static __inline__ void
zfree(vm_zone_t z, void *item)
{
-#ifdef SMP
zfreei(z, item);
-#else
- _zfree(z, item);
-#endif
}
-#endif
+#endif /* _SYS_ZONE_H */
Re: NFS/VM panic in current with INVARIANTS
:--=-=-=
:
:Matt Dillon [EMAIL PROTECTED] writes:
: Well, yes... that's essentially what I suggested. You didn't say
: anything about removing the externalized inlines, which is what you
: do in your patch. Looks like a fine patch to me.
:
:Except it didn't work. Now here's a patch that survived building a
:kernel and modules. ok?
:
:/assar
lets see.. ok, I'm going to read the patch carefully this time..
This isn't quite what I had in mind. You are still making an API
change... you are now calling zalloci() from zalloc() for non-SMP boxes.
There is no need to do that.
Instead what I would recommend is making zalloc() and zfree() real
procedures, putting them in vm_zone.c, and removing their inlines from
vm_zone.h. i.e. not have *ANY* inlines at all in vm_zone.h
Then as real procedures in vm_zone.c these functions can have the
#ifdef SMP / related code left intact.
-Matt
:
:--=-=-=
:Content-Disposition: attachment; filename=zalloc-diff
:
:Index: vm_zone.c
:===
:RCS file: /home/ncvs/src/sys/vm/vm_zone.c,v
:retrieving revision 1.35
:diff -u -w -r1.35 vm_zone.c
:--- vm_zone.c 2000/12/13 10:01:00 1.35
:+++ vm_zone.c 2000/12/27 00:59:14
:@@ -32,6 +32,59 @@
:
: static MALLOC_DEFINE(M_ZONE, "ZONE", "Zone header");
:
:+#define ZONE_ERROR_INVALID 0
:+#define ZONE_ERROR_NOTFREE 1
:+#define ZONE_ERROR_ALREADYFREE 2
:+
:+#define ZONE_ROUNDING 32
:+
:+#define ZENTRY_FREE 0x12342378
:+/*
:+ * void *zalloc(vm_zone_t zone) --
:+ *Returns an item from a specified zone.
:+ *
:+ * void zfree(vm_zone_t zone, void *item) --
:+ * Frees an item back to a specified zone.
:+ */
:+static __inline__ void *
:+_zalloc(vm_zone_t z)
:+{
:+ void *item;
:+
:+#ifdef INVARIANTS
:+ if (z == 0)
:+ zerror(ZONE_ERROR_INVALID);
:+#endif
:+
:+ if (z-zfreecnt = z-zfreemin)
:+ return _zget(z);
:+
:+ item = z-zitems;
:+ z-zitems = ((void **) item)[0];
:+#ifdef INVARIANTS
:+ if (((void **) item)[1] != (void *) ZENTRY_FREE)
:+ zerror(ZONE_ERROR_NOTFREE);
:+ ((void **) item)[1] = 0;
:+#endif
:+
:+ z-zfreecnt--;
:+ z-znalloc++;
:+ return item;
:+}
:+
:+static __inline__ void
:+_zfree(vm_zone_t z, void *item)
:+{
:+ ((void **) item)[0] = z-zitems;
:+#ifdef INVARIANTS
:+ if (((void **) item)[1] == (void *) ZENTRY_FREE)
:+ zerror(ZONE_ERROR_ALREADYFREE);
:+ ((void **) item)[1] = (void *) ZENTRY_FREE;
:+#endif
:+ z-zitems = item;
:+ z-zfreecnt++;
:+}
:+
: /*
: * This file comprises a very simple zone allocator. This is used
: * in lieu of the malloc allocator, where needed or more optimal.
:Index: vm_zone.h
:===
:RCS file: /home/ncvs/src/sys/vm/vm_zone.h,v
:retrieving revision 1.13
:diff -u -w -r1.13 vm_zone.h
:--- vm_zone.h 1999/08/28 00:52:44 1.13
:+++ vm_zone.h 2000/12/27 00:59:14
:@@ -43,7 +43,6 @@
: struct vm_zone *znext; /* list of zones for sysctl */
: } *vm_zone_t;
:
:-
: void zerror __P((int)) __dead2;
: vm_zone_t zinit __P((char *name, int size, int nentries, int flags,
: int zalloc));
:@@ -57,77 +56,16 @@
: int nitems));
: void *_zget __P((vm_zone_t z));
:
:-#define ZONE_ERROR_INVALID 0
:-#define ZONE_ERROR_NOTFREE 1
:-#define ZONE_ERROR_ALREADYFREE 2
:-
:-#define ZONE_ROUNDING 32
:-
:-#define ZENTRY_FREE 0x12342378
:-/*
:- * void *zalloc(vm_zone_t zone) --
:- *Returns an item from a specified zone.
:- *
:- * void zfree(vm_zone_t zone, void *item) --
:- * Frees an item back to a specified zone.
:- */
:-static __inline__ void *
:-_zalloc(vm_zone_t z)
:-{
:- void *item;
:-
:-#ifdef INVARIANTS
:- if (z == 0)
:- zerror(ZONE_ERROR_INVALID);
:-#endif
:-
:- if (z-zfreecnt = z-zfreemin)
:- return _zget(z);
:-
:- item = z-zitems;
:- z-zitems = ((void **) item)[0];
:-#ifdef INVARIANTS
:- if (((void **) item)[1] != (void *) ZENTRY_FREE)
:- zerror(ZONE_ERROR_NOTFREE);
:- ((void **) item)[1] = 0;
:-#endif
:-
:- z-zfreecnt--;
:- z-znalloc++;
:- return item;
:-}
:-
:-static __inline__ void
:-_zfree(vm_zone_t z, void *item)
:-{
:- ((void **) item)[0] = z-zitems;
:-#ifdef INVARIANTS
:- if (((void **) item)[1] == (void *) ZENTRY_FREE)
:- zerror(ZONE_ERROR_ALREADYFREE);
:- ((void **) item)[1] = (void *) ZENTRY_FREE;
:-#endif
:- z-zitems = item;
:- z-zfreecnt++;
:-}
:-
: static __inline__ void *
: zalloc(vm_zone_t z)
: {
:-#if defined(SMP)
: return zalloci(z);
:-#else
:- return _zalloc(z);
:-#endif
: }
:
: static __inline__ void
: zfree(vm_zone_t z, void *item)
: {
:-#ifdef SMP
: zfreei(z, item);
:-#else
:- _zfree(z, item);
:-#endif
:
happy!!
[NX}XI ¢ë`ñÈíÞÌGb`ªWª¯³êÄA ³¿Å©êéæB http://216.101.214.74/omankoheaven/ ·²[¢¾©çÉÈÉÅà©ÄÝÄËB ½Ü± To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fixing a.out compatibility
[Noted that you don't like being cc:'d, David. On the other hand,
I like to be kept in the cc: list.]
On Tuesday, 26th December 2000, "David O'Brien" wrote:
On Wed, Dec 27, 2000 at 02:01:24AM +1000, Stephen McKay wrote:
I'll try to summarise the position so far:
1) Legacy a.out executable support is broken for a subset (size unknown)
of such executables.
Define "legacy". I have been speaking specifically about FreeBSD 2.2
support. That just happens to a.out based.
You seem to mean it to be any a.out binary.
Not really. If I generate an a.out binary right now, it can't suffer
from this problem, even though it uses ld.so when it runs. Only a
certain set of old a.out binaries are affected.
From my standpoint only bits generated on a 2.2.x host can go into the
compat22 distribution. When compat1x was created (being the first it
gets to imply the intention of the compat dists) it gave the ability to
run FreeBSD 1.x binaries; not 2.0 a.out ones, not any binary after the
last 1.x release. Thus why I claim compat22 is *not* about being an
a.out compat dist, but one to properly run 2.2.x binaries on a later
version of FreeBSD. If 3.0 had been a.out based, there still would be a
compat22 dist.
We almost completely agree, but...
The only a.out binaries with problems come from that 2.2/2.1 era. To
support them we need an ld.so from *after* that era. I can't see how you
get around this. That working ld.so was in 3.0 and was certainly no
generated on a 2.2.x host. I think your restriction on compat contents
is a useful guideline, but to be broken when necessary.
Thus someone that still has access to a 2.2.8-stable box needs to merge
the changes in src/libexec/rtld-aout (in -current) to
src/gnu/usr.bin/ld{,/rtld} and build a new binary for inclusion in the
compat22 dist.
I'll build one if I have to. I'm trying to avoid unnecessary work, since
I expect there are few others bothered enough to fix this problem.
Note, when the bits were CVS repo copied into rtld-aout, all the tags
were stripped. I spent the time to add them all back to make the merge
easier for someone. Whoever does this should please CVSup before
starting.
Could very well be me. But I would be patching the old location, surely?
I don't think there's any doubt about point 1. All a.out executables that
use libc.so.2.2 and another recompiled library will fail because of a
missing routine (__error) required by the recompiled library and not
supplied by libc or by executable or by the existing ld.so.
Agreed, but "and another recompiled library", means this a.out
executable was not built on a 2.2.x host. Otherwise there would be no
way to have this inconsistency.
This is the fundamental point of this problem. The executable was built
on a 2.2.x or 2.1.x box and originally used libraries compiled then or
earlier. The whole problem is the fact that libraries were recompiled
later and did not change version numbers. There was no way to force
external parties to update version numbers, and folks round here didn't
feel like bumping all the FreeBSD library version numbers.
This is why I keep the words "executable" and "library" separate. The
library is newer than the executable, and this causes the executable
to fail. This is the fact that I'm not at all sure that you understand.
Actually one problem is I put the 2.2.8 ld.so in the compat2[01] dist.
That was wrong of me. I can correct that. SimCity (the binary used as
an example) required me to install the comapt20 and compat21 dists. The
other problem is we don't have a compat2[01] XFree86 libs dist. We only
have an a.out one that is intended to cover all a.out binaries, and it
doesn't correctly.
We can only install one ld.so. It has to cover all bases. Are you
suggesting that each compat2x dist install a different ld.so? This
is consistent with your claim that "compat2x bits come from 2.x", but
not very useful in practice. Should I assume you meant to delete
ld.so from all but one compatxx dist?
2.2.5 had libc 3.0 (without __error) and 2.2.7 had libc 3.1 (with
__error) but the cvs logs say that 2.2.6 should have had a different
libc 3.1 (without __error). So, the exact "version" of version 3.1 of
libc could be important. Yuck.
The compat22 dist used the 2.2.8 bits, so I don't see how it wasn't the
``exact "version" of version 3.1 of libc''.
What I was going on about here is that important changes occurred to
libraries without a version bump, and one such library was libc. It
is making my attempt to describe the boundary of the problem very
difficult. I can't predict what happens when you run an old a.out
binary linked against the "version" of version 3.1 of libc that didn't
have __error in it. This sort of confusion is what the versioning
system was supposed to prevent.
We need to build a new binary since we (collectively) have forgotten
where the working 3.0 through 3.2 binaries came from. :-(
It haven't forgotten, I told you. They came
Re: NFS/VM panic in current with INVARIANTS
On Tue, Dec 26, 2000 at 02:00:54PM +0200, Mark Murray wrote: I'm getting a reliable panic on CURRENT (2000/12/26) with INVARIANTS set. I suppose I could "fix" this by taking out INVARIANTS, but it seems to make more sense to try to get it fixed. Do you have NFS compiled in to the kernel? I've had trouble using INVARIANTS in the kernel and NFS as a module many times - it always panics in the zone allocation stuff. No I don't. Hmmm... (Either you always need to compile modules with the same INVARIENTS options as the kernel, or we need to fix INVARIENTS so it doesn't change the expected behaviour of anything in the kernel) OK. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
