Re: Any ideas why we can't even boot a i386 ?
In message [EMAIL PROTECTED], Geoffrey writes: On Thu, 27 Feb 2003, Juli Mallett wrote: * De: Poul-Henning Kamp [EMAIL PROTECTED] [ Data: 2003-02-27 ] [ Subjecte: Any ideas why we can't even boot a i386 ? ] Yup. 386dx - 33Mhz. Results below: Loaded kern.flp, mfsroot.flp, prompted for boot, then core dumped as follows: Was this normal release? I thought I recalled a convo resulting in the decision that 386 would require special release bits? Yes, it was from release floppies written a couple of weeks ago. In fairness, it might not like my scsi host adapter (Adaptec 1542CF). Or there may be an issue with the size of the drive (HP C2490 - 2 GB). The bios only supports one controller so fitting enough IDE drives for src, obj, usr and swap wasn't an option. You need to recompile a kernel where you explicitly add support for the i386 cpu. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
In message [EMAIL PROTECTED], David Schultz writes: Just out of curiosity, is your agenda to convince everyone to nix 386 support altogether or to fix 386 support? I'm not against either, although I consider the latter goal to be a bit silly. My agenda is to find some data either in support of or disproving a theory I have about a timing related issue. I realize that we may instead end up with some entirely different data which proves that we should not carry 386[sd]x support forward in RELENG_5. If so I can live with that, I'll have to find another way to find my datapoints then. I also don't think we should even think about redecorating this particular bikeshed at this time. If two weeks from now nobody has managed to get -current on a genuine 386[sd]x CPU, then we have a new data point which might merit discussion. Right we would just have the usual arm-chair generals and pundits pounding their pulpits. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Volunteer with genuine i386 cpu lots of time wanted.
In message [EMAIL PROTECTED], Bill Blum writes: Date: Wed, 26 Feb 2003 23:13:18 +0100 From: Poul-Henning Kamp [EMAIL PROTECTED] Subject: Volunteer with genuine i386 cpu lots of time wanted. Is there anybody out there who can try to run a straight -current on a _real_ i386 class CPU ? ... the install of 5.0-RELEASE dies horribly on the 386 box I have... will swap out with another 386 on Friday. You need to compile a kernel with this cpu I386_CPU in your config file. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: No more new majors, and help loose the old ones...
In message [EMAIL PROTECTED], Daniel C. Sobral writes: What is a good driver to crib this from? I'll do /dev/(null|zero|random). Heh. null and zero are two drivers phk is considering keeping fixed majors for. :-) I'd suggest that we put the following drivers on the not quite list for now: null mem kmem zero random [geom] floppy CD's. pty console sio -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/i386/i386 elan-mmcr.c
In message [EMAIL PROTECTED], Poul-Henning Kamp
writes:
phk 2003/02/27 13:13:08 PST
Modified files:
sys/i386/i386elan-mmcr.c
Log:
Add support for the Elan CPU hardware watchdog used in active mode.
Now we can get the watchdog to kill the machine if it goes unresponsive.
(And no, I don't have an MFC plan, I don't have any Soekris' runing
-stable)
This is a small program which shows how to use the api. See also
the comments in sys/watchdog.h (also new file).
#include stdio.h
#include fcntl.h
#include errno.h
#include sys/types.h
#include sys/watchdog.h
int
main(int argc, char **argv)
{
int fd;
int i, j;
unsigned u;
fd = open(/dev/elan-mmcr, O_RDWR);
if (fd 0)
err(1, /dev/elan-mmcr);
/*
* Set a two second timeout, but reset it after one second.
* Do this five times to see that it works as advertised.
*/
for (j = 0; j 5; j++) {
u = WD_ACTIVE | WD_TO_2SEC;
i = ioctl(fd, WDIOCPATPAT, u);
printf(2SEC %d %d\n, i, errno);
sleep (1);
}
/*
* Turn the watchdog off.
* Wait twice the previous timeout, we should survive.
*/
u = 0;
i = ioctl(fd, WDIOCPATPAT, u);
printf(OFF %d %d\n, i, errno);
sleep (5);
/*
* Set a two second timeout, and let it, and us, expire.
*/
u = WD_ACTIVE | WD_TO_2SEC;
i = ioctl(fd, WDIOCPATPAT, u);
printf(2SEC %d %d\n, i, errno);
sleep (5);
/*
* We shouldn't get here alive.
*/
printf(Where's the kaboom ?\n);
exit (0);
}
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Mounting Root fails with error 22 (EINVAL)
Can somebody please use cvs update -D date to do a binary search and identify which exact commit caused the problem ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: machdep.guessed_bootdev sysctl on i386
In message [EMAIL PROTECTED], Hiten Pandya writes: --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello gang. Nothing big, but important... Can someone tell me if the machdep.guessed_bootdev sysctl is helpful at all? I think it's a waste, and it's pretty limited and only available on the i386. It isn't and it should be deleted I think. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Mounting Root fails with error 22 (EINVAL)
In message [EMAIL PROTECTED], Michael Class writes: Hello, just as a data-point. I am seeing the same behaviour. It started with a kernel from Feb 21th. The kernel from Feb. 20th works o.k. Enclosed is the dmesg out, if that helps. Please try boot -v and send dmesg. Also, please try entering ? to root device prompt to see what devices are available. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Mounting Root fails with error 22 (EINVAL)
In message [EMAIL PROTECTED], Michael Class writes: Please try boot -v and send dmesg. Also, please try entering ? to root device prompt to see what devices are available. Hello, enclosed is the boot -v output that you were asking for. Mounting root from ufs:/dev/ad0s4a Root mount failed: 22 If you say int broke in the 20feb timeframe I think sos' ATA megacommit is the main suspect... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: The cbus driver for pc98
In message [EMAIL PROTECTED], Takahashi Yoshihiro writes: In article [EMAIL PROTECTED] M. Warner Losh [EMAIL PROTECTED] writes: Cbus is to ISA as CardBus is to PCI in many ways. Cbus is very much like ISA in all but a few details. CardBus is pci with a few twists and turns that differ. If you look at how we've implemented cardbus, you'll see that we've tried to do it as a 'subclass' of the pci bus. We implement the PCI interfaces in the cardbus bus code, even though it is not really a pci bus. I'd propose that cbus implements the ISA interfaces in a similar manner. If my understanding is not a mistake, the CardBus specifications is derived from the PCI. Therefore, I can understand that the cardbus driver depend on the pci driver. But, the Cbus is NOT derived from the ISA. So, I think that the cbus driver should not depend on the isa driver. This increasingly sounds like an emotional thing rather than a technical thing :-( -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Optimizing universe somewhat
In message [EMAIL PROTECTED], Ruslan Ermilov writes:
--/9DWx/yDrRhgMJTb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Feb 19, 2003 at 07:40:19AM -0800, Ruslan Ermilov wrote:
ru 2003/02/19 07:40:19 PST
=20
Modified files:
.Makefile=20
Log:
Fixed universe.
=20
Folded pc98 into the common case.
Retired ${JFLAG} (``make -jX universe'' should work).
=20
Revision ChangesPath
1.276 +30 -34src/Makefile
=20
Would it be too bad (in anyone's opinion) if we optimize this
a bit to build modules only once for each architecture, with
buildworld (-DMODULES_WITH_WORLD)? That would speed-up the
creation of universe somewhat, but has one bad side effect of
polluting userland build with kernel stuff, but is easiest
to implement.
I think we should build the modules as specified by the kernels.
Nothing prevents you from adding
makeoptions MODULES_OVERRIDE=acpi linux
or similar to your kernels.
Universe just takes time, and that's it. Don't try to optimize it
if the result is less coverage.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/alpha/alpha busdma_machdep.c src/sys/alpha/osf1 imgact_osf1.c osf1_misc.c src/sys/cam cam_periph.c cam_sim.c cam_xpt.c src/sys/cam/scsi scsi_cd.c scsi_ch.c scsi_da.c scsi_low.c scsi_sa.c scsi_target.c src/sys/coda cnode.h ...
In message [EMAIL PROTECTED], Warner Losh write
s:
imp 2003/02/18 21:47:47 PST
Modified files:
[... everything ...]
uma_core.c vm_map.c vm_object.c
Log:
Back out M_* changes, per decision of the TRB.
Approved by: trb
The attached patch will print a backtrace if any calls to malloc
fail to have either M_WAITOK or M_NOWAIT.
Please put this patch in your tree and help fix any issues.
So far (10 minutes) my disk-less testbox has found no issues.
Poul-Henning
Index: kern/kern_malloc.c
===
RCS file: /home/ncvs/src/sys/kern/kern_malloc.c,v
retrieving revision 1.116
diff -u -r1.116 kern_malloc.c
--- kern/kern_malloc.c 19 Feb 2003 05:47:25 - 1.116
+++ kern/kern_malloc.c 19 Feb 2003 07:55:19 -
@@ -167,11 +167,21 @@
#endif
register struct malloc_type *ksp = type;
+ indx = flags (M_WAITOK | M_NOWAIT);
+ if (indx == M_NOWAIT) {
+ /* OK */
+ } else if (indx == M_WAITOK) {
+ /* OK */
+ } else {
+ printf(Missing M_WAITOK flag\n);
+ backtrace();
+ flags |= M_WAITOK;
+ }
#if 0
if (size == 0)
Debugger(zero size malloc);
#endif
- if (!(flags M_NOWAIT))
+ if (flags M_WAITOK)
KASSERT(curthread-td_intr_nesting_level == 0,
(malloc(M_WAITOK) in interrupt context));
if (size = KMEM_ZMAX) {
Index: sys/malloc.h
===
RCS file: /home/ncvs/src/sys/sys/malloc.h,v
retrieving revision 1.70
diff -u -r1.70 malloc.h
--- sys/malloc.h19 Feb 2003 05:47:45 - 1.70
+++ sys/malloc.h19 Feb 2003 07:58:41 -
@@ -46,11 +46,11 @@
/*
* flags to malloc.
*/
-#defineM_WAITOK0x
#defineM_NOWAIT0x0001 /* do not block */
-#defineM_USE_RESERVE 0x0002 /* can alloc out of reserve memory */
-#defineM_ZERO 0x0004 /* bzero the allocation */
-#defineM_NOVM 0x0008 /* don't ask VM for pages */
+#defineM_WAITOK0x0002 /* do not block */
+#defineM_ZERO 0x0100 /* bzero the allocation */
+#defineM_NOVM 0x0200 /* don't ask VM for pages */
+#defineM_USE_RESERVE 0x0400 /* can alloc out of reserve memory */
#defineM_MAGIC 877983977 /* time when first defined :-) */
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/alpha/alpha busdma_machdep.c src/sys/alpha/osf1 imgact_osf1.c osf1_misc.c src/sys/cam cam_periph.c cam_sim.c cam_xpt.c src/sys/cam/scsi scsi_cd.c scsi_ch.c scsi_da.c scsi_low.c scsi_sa.c scsi_target.c src/sys/coda cnode.h ...
In message [EMAIL PROTECTED], Peter Wemm writes: [EMAIL PROTECTED] wrote: The attached patch will print a backtrace if any calls to malloc fail to have either M_WAITOK or M_NOWAIT. Please do not commit this as-is.. There is a DoS here if a user figures out how to provoke this. This is exactly the situation that Alfred was worried about. I have no intention of committing this. The email from the TRB@ indicated that a plan exists, this patch was merely meant as an aid to people to find any issues up front. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0R - panic: bwrite: buffer is not busy
In message [EMAIL PROTECTED], Patric Mrawek writes: I am seeing a reproducible panic with FreeBSD talisker 5.0-RELEASE FreeBSD 5.0-RELEASE #5: Wed Jan 29 10:49:32 CET 2003 root@talisker:/usr/src/sys/i386/compile/TALISKER i386 What I've done is: - kldload uvisor.ko - running »/usr/sbin/usbd -d -v« - running »jpilot-sync -d -l -p /dev/ucom0« - hitting the sync-button from my visor several times After hitting the sync-button 5 to 10 times my box panics. it looks like a device disappeared while you had it open. I'll commit a workaround for this later today. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Simply impossible to format disk under current.
In message [EMAIL PROTECTED], David Gilbert writes: I ran into an interesting problem last night ... that was very frustrating. I was recycling SCSI drives from some NetBSD machines (that were client boxes) to add to a RAID server running FreeBSD-5.0-RELEASE. It's simply impossible to format NetBSD drives under current. Let me expand on that. /dev/da2 exists, but you can't say 'fdisk -I da2' ... fdisk says that /dev/da2 doesn't exist. /dev/da2 (and /dev/da2c) isn't writable, so I can't blank the first few sectors. I even tried this in single user mode. /dev/da2 is always writable unless you have any of the partitions open. I guess you have whacked the disk now, so I won't be able to get any debugging information. In case of disk/GEOM related problems, I need the output from dmesg sysctl -b kern.geom.confxml or I won't really be able to do debugging... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: New ad*s* devices not automatically appearing in devfs
In message [EMAIL PROTECTED], Darren Pilgrim writes: When I add a new slice or partition to a disk, the device files don't automatically appear in /dev. If I reboot, it shows up, but having to reboot twice just to add a filesystem to a running disk is absurd. How do I make /dev automatically add these devices upon creation? Failing that, how do I force the system to notice the new device(s) and add them to /dev? Which exact commands do you use to create them ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: New ad*s* devices not automatically appearing in devfs
In message [EMAIL PROTECTED], Darren Pilgrim writes: [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Darren Pilgrim writes: When I add a new slice or partition to a disk, the device files don't automatically appear in /dev. If I reboot, it shows up, but having to reboot twice just to add a filesystem to a running disk is absurd. How do I make /dev automatically add these devices upon creation? Failing that, how do I force the system to notice the new device(s) and add them to /dev? Which exact commands do you use to create them ? I used sysinstall, Configure-Fdisk to (in order) delete s3, create a 5120m s2, then Write the changes to disk. After exiting sysinstall: But the changes do appear after you reboot ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI timer bug
In message [EMAIL PROTECTED], Dag-Erling Smorgrav writes: The clock on my ASUS P5A still runs at double speed unless I have debug.acpi.disable=timer in loader.conf (as it has for as long as we've had ACPI support). Do any ACPI wizards have any suggestions as to how I could track down the cause of this bug, and hopefully fix it? I don't have any P5A boards, so I'm really at a loss with this one. Basically, something about about ACPI timer does not match spec and I have no idea what it is, or for that matter how to reliably detect it. The best I can suggest is hunting down any errata for the chipset or experimenting.. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: disklabel is broken (GEOM related)
In message [EMAIL PROTECTED], Maxim Sobolev writes: Hi, It seems that disklabel is currently broken on -current. In `read' mode it reports incorrect information about disk layout: Don't use the -r option and you will be ok. Poul-Henning root@notebook# disklabel -r ad0s1 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: disklabel is broken (GEOM related)
In message [EMAIL PROTECTED], Dag-Erling Smorgrav writes: [EMAIL PROTECTED] writes: In message [EMAIL PROTECTED], Maxim Sobolev writes: It seems that disklabel is currently broken on -current. In `read' mode it reports incorrect information about disk layout: Don't use the -r option and you will be ok. Then how are we supposed to initialize devices which don't already have a label? That is the only valid use of -r, and it should be implicit in that case. I'm working on getting disklabel to make sense, have patience please. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Problems creating and writing to disk slices
In message [EMAIL PROTECTED], Joerg Wunsch writes: Darren Pilgrim [EMAIL PROTECTED] wrote: The above practices have worked fine for a long time in 4.x and still do even in 4.7p4, which is on this same machine. Get Matthew N. Dodd's patch at: ftp://ftp.jurai.net/users/winter/patches/geom-foot.patch (Hint: sysctl kern.geom.allow_foot_shooting=1) Then help me convincing phk that there might be legitimate needs for such an option. :-/ You're out of date, one such has been committed to current. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: The cbus driver for pc98
In message [EMAIL PROTECTED], M. Warner Losh writes: In message: [EMAIL PROTECTED] Dag-Erling Smorgrav [EMAIL PROTECTED] writes: : Takahashi Yoshihiro [EMAIL PROTECTED] writes: : I have had some questions like Does PC98 have ISA bus? or Why PC98 : uses ISA driver?. To clear these questions and problems, I think : that adding separated cbus driver is better way. : : So you're duplicating a large amount of existing, working code just so : you can avoid answering questions from confused users? Or are there : any actual technical advantages to having a separate cbus driver? That's a little too harsh. I actually think that it would be an improvement over the current copy-the-isa-file-and-add-#ifdef-PC98-making-diffs-hard-to-read approach. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: The cbus driver for pc98
In message [EMAIL PROTECTED], M. Warner Losh writes: In message: [EMAIL PROTECTED] [EMAIL PROTECTED] writes: : In message [EMAIL PROTECTED], M. Warner Losh writes: : In message: [EMAIL PROTECTED] : Dag-Erling Smorgrav [EMAIL PROTECTED] writes: : : Takahashi Yoshihiro [EMAIL PROTECTED] writes: : : I have had some questions like Does PC98 have ISA bus? or Why PC98 : : uses ISA driver?. To clear these questions and problems, I think : : that adding separated cbus driver is better way. : : : : So you're duplicating a large amount of existing, working code just so : : you can avoid answering questions from confused users? Or are there : : any actual technical advantages to having a separate cbus driver? : : That's a little too harsh. : : I actually think that it would be an improvement over the current : copy-the-isa-file-and-add-#ifdef-PC98-making-diffs-hard-to-read : approach. Have you looked at the actual patch? That's exactly what this patch does more of. Then I misunderstood the quoted bits of the patch, sorry. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Problems creating and writing to disk slices
In message [EMAIL PROTECTED], Darren Pilgrim writes: I can understand the usefulness of preventing modifications applying to mounted partitions, and I can see the logic in unliaterally preventing them, but preventing modifying slice table and disk label entries for unmounted portions of the disk gets more in the way than helps. You should be able to modify any non-open partition/slice provided you don't try to make them overlap an open one. You have to use the right options to the right programs on the right devices though. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD/alpha make-release on FreeBSD/i386: dislabel problem
In message [EMAIL PROTECTED], Makoto Matsushita writes: phk Not yet. I think adding a -m architecture flag to disklabel is the phk way around this problem, but have not had time to do so. Thanks, I'm waiting until you have enough time to do since I have little knowledge about this issue:) BTW, what's changes do you imagine? Make a table which holds architecture name, label size, offset, etc and use it in disklabel.c:makebootarea()? Something like that. Maybe it requires some changes in sys/disklabel.h since LABELOFFSET and other macros are defined inside of architecture-dependent #ifdefs... Doing this would actually make LABELOFFSET obsolete. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OPIE breakage: backout patch for review
In message [EMAIL PROTECTED], Andrey A. Chernov writes: On Sun, Feb 16, 2003 at 13:27:38 +0300, Andrey A. Chernov wrote: Unless you specify exact details of what I ignore, I'll be forced to treat your reply as NO REVIEW and commit this changes. Well, after numerous exchanges of nonsense messages [...] That is probably the most precise summary so far (NB: exchanges implies that the non-sense goes both ways). Please take this to private email. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OPIE breakage: backout patch for review
In message [EMAIL PROTECTED], Andrey A. Chernov writes: Please take this to private email. I not see enough good will from des side for it. Then please just stop. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Clock disabled during DDB
In message [EMAIL PROTECTED], Bruce Evans writes: The piix timecounter has a lower frequency than the TSC, but for some reason we mask it to 24 bits (16M cycles @ 3.5+ MHz = 4+ seconds). We do this because the spec defines it as either 32 or 24 bit and some 24 bit implementations claim to have 32 bits. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Console API related patch.
In message [EMAIL PROTECTED], Marcel Moolenaar writes: This patch changes the API so that rather than pass a dev_t to the console functions, the struct consdev * is passed: -typedefvoidcn_putc_t(dev_t, int); +typedefvoidcn_putc_t(struct consdev *, int); I like this. On the ia64 branch I completely ignore the dev argument and instead use a static softc. The dev_t is unknown until after bus enumeration in principle anyway. Yeah, I saw that. Actually I think more or less any console driver which uses the dev_t arg is wrong about doing that, but we can fix that subsequently. I'll test ia64, both CVS an P4. Let me know when you like to commit this so that I can schedule around that... I'm no no particular hurry, so whenever I have sufficient feedback to convince me that its safe. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD/alpha make-release on FreeBSD/i386: dislabel problem
In message [EMAIL PROTECTED], Makoto Matsushita writes: I've tried to do make release of FreeBSD/alpha on FreeBSD/i386 box last night, and found that follow error while generating drivers.flp: If my understandings are correct, this is because disklabel(8) kicked is FreeBSD/i386 native binary which doesn't know about FreeBSD/alpha disklabel structure or whatever. Are there any workaround/fix? Not yet. I think adding a -m architecture flag to disklabel is the way around this problem, but have not had time to do so. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make depend broken in cpp0
In message [EMAIL PROTECTED], Kris Kennaway writes: --mJm6k4Vb/yFcL9ZU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 15, 2003 at 07:28:45PM +0100, Poul-Henning Kamp wrote: =20 I installed 5.0-R on my new alpha (Thanks Wilko!) and tried to run a buildworld. It explodes in make depend in cpp0: =20 #cd /usr/src/gnu/usr.bin/cc/cpp0 #make obj #make depend This looks like a symptom of an unclean objdir..notice how 'make obj' doesn't report anything, indicating the objdir is already present (and probably populated with old stuff). Try removing it with 'cleandir' (twice), and retry. That's because I reran the command to catch the error output. /usr/obj was on a freshly newfs'ed disk when I started. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make depend broken in cpp0
In message [EMAIL PROTECTED], Kris Kennaway writes: --5UGlQXeG3ziZS81+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 15, 2003 at 11:01:52PM +0100, [EMAIL PROTECTED] wrote: #cd /usr/src/gnu/usr.bin/cc/cpp0 #make obj #make depend This looks like a symptom of an unclean objdir..notice how 'make obj' doesn't report anything, indicating the objdir is already present (and probably populated with old stuff). Try removing it with 'cleandir' (twice), and retry. =20 That's because I reran the command to catch the error output. =20 /usr/obj was on a freshly newfs'ed disk when I started. OK, does buildworld fail in the same way? Yes. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: fix: lock order reversal proc/filedesc.
In message [EMAIL PROTECTED], Dag-Erling Smorgrav writes:
Makes me want to get my Norwegian Sword [tm] and make a short trip to
Denmark.
I my be reading my email out of order here, but I guess you changed
your mind and tried to bury use with boatloads of useless asterix
('*') instead ? :-)
It is becoming increasingly clear to me that the majority of FreeBSD
developers don't really care if their code works, as long as they get
the credit (and / or paycheck) for committing it.
I realize that you live in Norway and therefore have a bigger supply
or rocks than most of us. You should still be aware that you live
in a glass house yourself.
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Problems with timekeeping
In message [EMAIL PROTECTED], tony writes: My time clock seems to do two ticks for every one that it should do. I'm not sure where to start on fixing this. I had 4.7 installed and did a clean install of 5.0 release thats when I noticed the time keeping weirdness.. it always kept time perfectly before. I cvsuped to tag=RELENG_5_0 and built installed built kernel installed. but no change... Any ideas? Please try: sysctl kern.timecounter.hardware=i8254 Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sio issue
In message [EMAIL PROTECTED], Lars Eggert writes: This is a cryptographically signed message in MIME format. --ms000403080001090805030804 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, lately, I end up in ddb when I connect my (unconnected) serial console cable to another machine. It's not critical, since c will continue fine, but it's annoying. Here's a trace: Could this commit be related at all? No, not a chance. phk 2003/02/02 13:25:22 PST Modified files: sys/dev/sio sio.c Log: Set si_drv1 to our softc for all the six dev_t's we create for a serial port. Revision ChangesPath 1.383 +2 -0 src/sys/dev/sio/sio.c Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gbde
In message [EMAIL PROTECTED], [EMAIL PROTECTED] write s: I keep ketting errors when trying to make my root filesystem encrypted: bash-2.05b# gbde init /dev/ad0s2a gbde: /dev/ad0s2a: No such file or directory bash-2.05b# If you have ad0s2a mounted as a filesystem, doing the above doesn't make sense. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic with heavy io
In message [EMAIL PROTECTED], Mark Santcroos writes:
While doing heavy IO (updating my p4 repo) on my laptop I got the following
panic. (I was running in X so both backtrace and dmesg are from the core
dump after reboot)
I'm wondering whether the ENOMEM's reported by GEOM point out that GEOM
has a problem or just tell us that the machine was out of memory and some
other subsystem failed.
ENOMEM 0xc3724300 on 0xc2412c80(ad0s1)
The ENOMEM from GEOM is just a notification that an I/O request failed
due to lack of memory.
GEOM reacts to this by rescheduling the I/O request and entering a
rudimentary back-off mode where further I/O requests are paced so
that some of the outstanding ones get a chance to complete. The
current pacing is inspired a little bit by tcp slowstart btw.
By looking at the stack it seems that the NULL-pointer dereference is
going down pretty far.
The arguments in the lstat(frame #28) already seem bogus.
#10 0xc0381d12 in trap_fatal (frame=0xce5c1700, eva=0) at
../../../i386/i386/trap.c:844
This is the interesting trap I think, all the stuff above is noise.
#11 0xc03819f2 in trap_pfault (frame=0xce5c1700, usermode=0, eva=20) at
../../../i386/i386/trap.c:758
#12 0xc03814e0 in trap (frame=
{tf_fs = -832831464, tf_es = -1071710192, tf_ds = -951058416, tf_edi =
-1037023552, tf_esi = -951046744, tf_ebp = -832825484, tf_isp = -832825556, tf_ebx =
0, tf_edx = 5, tf_ecx = 0, tf_eax = -1740064768, tf_trapno = 12, tf_err = 2, tf_eip =
-1071712263, tf_cs = 8, tf_eflags = 66183, tf_esp
= -951046744, tf_ss = -951046572})
at ../../../i386/i386/trap.c:445
#13 0xc0371bf8 in calltrap () at {standard input}:96
#14 0xc01edc00 in spec_xstrategy (vp=0xc23046c0, bp=0xc7502da8) at
../../../fs/specfs/spec_vnops.c:596
This doesn't correspond to my sourcefile, but you should examine this one.
#15 0xc01edc7b in spec_specstrategy (ap=0x0) at ../../../fs/specfs/spec_vnops.c:633
This, I think is impossible, so I think we should assume that something
overwrite some memory and cleared out some bits which should have
survived.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: panic with heavy io
In message [EMAIL PROTECTED], Mark Santcroos writes: 596: DEV_STRATEGY(bp); I don't understand what you want me to examine there as the arguments are not usefull anymore (or are they?). Well that line in my copy was not code, so I just wanted to see what your sources said. #15 0xc01edc7b in spec_specstrategy (ap=0x0) at ../../../fs/specfs/spec_vnops.c:633 This, I think is impossible, so I think we should assume that something overwrite some memory and cleared out some bits which should have survived. That was my feeling too, it wouldn't have gotten so deep with NULL arguments. Haven't checked the code so it is only an assumption. Any idea's what to do now or what to do when I am able to reproduce it? No idea at the moment. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 tinderbox failure
/local0/scratch/des/src/sys/geom/bde/g_bde.c: In function `g_bde_config': /local0/scratch/des/src/sys/geom/bde/g_bde.c:251: structure has no member named `slicesize' /local0/scratch/des/src/sys/geom/bde/g_bde.c:252: structure has no member named `sliceoffset' My fault, already fixed. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still have a FIFO / named pipe problem?
Yes, we do have FIFO/named pipe problems in -current. I committed a workaround to prevent one particular condition under which my diskless box would hang forever in sendmail processing in /etc/rc by setting a 1 sec timeout on the sleep it hung in. This is nowhere near correct as pointed out by Bruce, but at least my machine boots. I don't know what the bug is, Alfred looked at it some, but the patch he came up with did not work on my machine. I belive the issue rests there. Poul-Henning In message [EMAIL PROTECTED], Fred Souza writes: --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, =20 ports/mail/gensig has a problem. It is supposed to create a named pipe (~/.signature) and wait for an application to read from the pipe. It allows to have a random signature on every mail. On 4.x and on 5-current from last year it works as expected. But since the end of the last year or the begin of this year it doesn't anymore. gensig daemonizes itself fills the named pipe and then terminates. The content of the named pipe stays the same for every mail (no wonder, gensig is gone). I had the same problem with signify (which is not on ports). My fix for it was to force open() to open the file for both read and write (signify is a Perl script). I can send the patch if you need to see what I actually did. Fred --=20 Death is only a state of mind. Only it doesn't leave you much time to think about anything else. --GvXjxJ+pjyke8COw Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+RoC4KbRS1GgW4fYRAp3xAJ4lA9doM8Dty7aVgvZMePJBgGMT1ACgga17 6lX0Oy0b4KW8MheO7wZzopI= =3Ya0 -END PGP SIGNATURE- --GvXjxJ+pjyke8COw-- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Does bg fsck have problems with large filesystems?
In message [EMAIL PROTECTED], Gerrit =?iso-8859-1?Q? K=FChn?= writes: On Tue, Jan 28, 2003 at 06:31:42PM +0100, Gerrit Kühn wrote: I've been trying to reproduce this bug on my desktop. This machine has 2 80gb disks, one of which is dedicated with one slice. So far, after 8 hard resets, I haven't had any problem with either the machine or bgfsck hanging. I'll try to reproduce the thing on my machine as soon as possible. Perhaps it was just because it was Monday, who knows... Meanwhile I found out that my problem is 100% reproducible. Sounds like bgfsck gets stuck in the snapshot creation. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Preview: GEOMs statistics code.
In message [EMAIL PROTECTED], Mattias Pantzare writes: [EMAIL PROTECTED] wrote: I have played with the statistics collection in GEOM a bit, and need more feedback, but first: try to play with it a bit. Assuming you're running -current as of today, otherwise install include files and libgeom by hand first. Apply this patch in src/sys/geom and make a new kernel. http://phk.freebsd.dk/patch/geom_io.patch I get a Not Found from that URL. I've worked more on it since yesterday: Grab -current, update kernel, #includes and libgeom, then fetch this file: http://phk.freebsd.dk/patch/gstat.c and compile it with -lgeom -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Wrong date for DEVFS entries
In message [EMAIL PROTECTED], Andrey A. Chernov writes: On Sat, Feb 08, 2003 at 00:16:24 +0100, [EMAIL PROTECTED] wrote: Can we stop considering workarounds, and instead work on solving the problem please ? I see no solving way until kernel will understand fully and can handle timezone database format. It means timezone code should be integrated into kernel. And for which reason? Only to heal DEVFS timestamps? Mount workaround looks more light-weighted. Please re-read my earlier email on the topic. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Preview: GEOMs statistics code.
I have played with the statistics collection in GEOM a bit, and need more feedback, but first: try to play with it a bit. Assuming you're running -current as of today, otherwise install include files and libgeom by hand first. Apply this patch in src/sys/geom and make a new kernel. http://phk.freebsd.dk/patch/geom_io.patch Stick these two in a directory and run make. http://phk.freebsd.dk/patch/Makefile http://phk.freebsd.dk/patch/gstat.c Then run sysctl kern.geom.collectstats=1 to enable collection of statistics in the kernel (reports of the performance impact of doing so welcome!) and then run the gstat program in an xterm. Notice that the program uses two ANSI escape sequences directly (ESC [ 2 J and ESC [ H) I didn't want to mess with curses right now. You will get a display like this: dT L(q) ops/sr/s ms/rw/s ms/wd/s mw/d %busy Id 1.0100 0 0 . 0 . 0 .0.0 0xc412a580 1.0100 0 0 . 0 . 0 .0.0 0xc3fe2b40 1.0100 44 0 . 211.0 230.0 1.9 0xc412a400 1.0100 0 0 . 0 . 0 .0.0 0xc3fe2680 1.0100 44 0 . 211.0 230.0 1.9 0xc3fe2600 1.0100 44 0 . 211.0 230.1 2.0 0xc4108e80 1.0100 44 0 . 211.0 230.1 101.0 0xc3fe2500 1.0100 44 0 . 211.1 230.6 3.1 0xc4108d00 1.0100 0 0 . 0 . 0 .0.0 0xc3fe24c0 1.0100 44 0 . 211.1 230.6 3.1 0xc3fe2bc0 1.0100 0 0 . 0 . 0 .0.0 0xc418c180 1.0100 0 0 . 0 . 0 .0.0 0xc4312140 The columns are: dT Seconds in this measurement interval (change the sleep at the bottom of gstat.c to modify). L(q) Number of transactions in queue at this moment in time ops/s Operations per second in this interval. r/s, w/s, d/s Reads, Writes and Deletes per second in this interval ms/r, ms/w, ms/d Milliseconds per read, write and delete (average for interval). %busy Attempted calculation of %busy according to the discussion here. Id A not very random number which can be translated to something meaningfull with the output of sysctl -b kern.geom.confxml Another easy way is to use dd if=/dev/ad0 of=/dev/null dd if=/dev/ad0s1 of=/dev/null ... to identify the various devices if this is important. And as you will probably discover, the %busy is not very calm and the other columns will take a hit every so often too. I can of course make these statistics a perfect snapshot by employing locks around all the updates (that will be cheaper than atomics because there are several fields updated at the same time), and grabbing the lock when I get a snapshot. But doing so will cost us in performance: The actual lock operations, even if uncontested costs something, while it may not affect I/O throughput, it will affect the entire systems throughput. Then there is the lock contention, that is probably not too bad, it's cheap operations and they are not _that_ frequent. I will need to use read(2) or ioctl(2) to pull the data out of the kernel instead of the mmap(2) I use now, since I need a place to grab the lock. That means userland/kernel transitions. A number of intermediate solutions exist, such as flagging the structures while they are being updated (possibly with memory barriers). All it comes down to in the end is: How much of a performance hit do we want to take to collect disk statistics ? Input still very much appreciated... Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GEOM and Extended Slices
In message [EMAIL PROTECTED], Hiten Pandya writes: Hi gang. Recently removing the NO_GEOM option from my kernel; I noticed that my dos extended slices dev entries disappeared under a GEOM kernel. This is sorta bad, but I can bare for now. Also, I tried searching the sys/geom/ tree if there was anything relating to this, but could not find anything for `grep -i extend`. So, is it just me, or is this is a problem? Please send me dmesg from a verbose boot in private email. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Wrong date for DEVFS entries
In message [EMAIL PROTECTED], Andrey A. Chernov writes: On Thu, Feb 06, 2003 at 22:10:43 +1100, Bruce Evans wrote: More precisely: some are mounted, but they are mounted read-only (modulo the bug that adjkerntz is run a little after mounting filesystems read-write). Obvious workaround: could DEVFS be mounted read-only initially and then re-mounted as read-write after adjkerntz started, in the same manner as / remounted read-write, i.e. with mount -u ? Can we stop considering workarounds, and instead work on solving the problem please ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Wrong date for DEVFS entries
In message [EMAIL PROTECTED], Bruce Evans writes: On Thu, 6 Feb 2003, Andrey A. Chernov wrote: On Wed, Feb 05, 2003 at 23:44:08 +0100, [EMAIL PROTECTED] wrote: 2) Feb 6 01:36 (boot time) 3) Feb 6 04:36 (+3 TZ future jump) These timestamps have been touched, and the clock has made a 3 hour jump either forward or backward at some point. The problem is the clock jump, not DEVFS. Clock jump happens as it supposed when adjkerntz(8) corrects machine clock back to GMT via various CPU_* sysctl's. Could touched DEVFS stamps be fixed back to something useful in the same sysctl code too? This should be well known to devfs users. devfs sets at least some of the times before adjkerntz can run, and nothing fixes them, so these times are wrong by the timezone difference. This is not any different from any other filesystem. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Wrong date for DEVFS entries
In message [EMAIL PROTECTED], Andrey A. Chernov writes: This is not any different from any other filesystem. No, it IS different - no real filesystems mounted at this point yet, so no real timestamps damaged. Think diskless NFS, think MD(4) based root, think... The only problem is that we set the kernel time wrong from the RTC. We should stop doing that, rather than invent bandaids and hacks to restore the damage it does. I avoid it entirely by using UTC time in my RTC, but this is not an option for machines which have to boot broken-as-designed OSs. The most practical way to do it right would be to have adjkerntz update a file under /boot/ (/boot/timezone.hint) which the loader reads in and passes to the kernel, so that the kernel can set the time right from the RTC based on that. This doesn't work well for machines which are turned off for long periods of time unless the file contains predicted DST transitions for the next year or so. The most correct solution would be for the loader (preferably) or the kernel to know about timezones, including DST, so that it would also work correct for a machine which has been powered off for half a year. (I'd prefer the loader because we don't need this code once userland can take over.) I don't know if modern bios's know about timezones and DST, I've seen some that has setup functions for it, but I don't know if there is any way to find the information they store and I don't think such features are widespread. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Preview: GEOMs statistics code.
In message a05200f02ba66778c5b08@[10.0.1.2], Brad Knowles writes: At 8:26 AM +0100 2003/02/05, [EMAIL PROTECTED] wrote: My understanding was that a disk is 100% busy, if the heads are constantly moving to and fro, and there is no period of time when they aren't being yanked around. In other words, it would be 100% if there is always at least one outstanding request. Works for me, I'll try if I can instrument that cheaply. What is your time resolution on this sort of thing? Iostat can only report in periods as small as one update per second, so I would hope that you could measure these quantities on a much more frequent basis, thus being able to make a useful calculation of average values over that period of time. I currently use binuptime() which means that the resolution is whatever the system provides, which means better than 1 microsecond on all current platforms. The counters are updated in real time, so it's up to you how often you read them. For truly trying to understand our disk-I/O load, tracelogs will be needed (And I fear they will show a lot of interesting phenomena). Hmm. I'd like to learn more about this tracelog concept. Can you provide any pointers? Well, tracelog is simply my word for the concept of recording each and every transaction and run it through some kind of analysis afterwards. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Wrong date for DEVFS entries
In message [EMAIL PROTECTED], Andrey A. Chernov writes: Look at the snapshot below, taken right after boot time. Most entries are at Feb 5 22:34 which is boot time, but some other are Feb 6 01:34 which is in the future! It looks like TZ offset added for them by mistake. Please fix this bug. My guess: Your RTC has the wrong time and ntpdate or similar stepped your clock to be correct. There is nothing in DEVFS which knows about timezones, but there is code to set the initial time to the estimated boottime. If your system comes up, takes wrong time from RTC, the dev entries will get this wrong time before the system gets a chance to set it right across the network. Originally, the timestamps in DEVFS started out as zero, ie: 1970010100 (moduls timezone) but people didn't like that and the abovementioned code was introduced. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0 issues
In message [EMAIL PROTECTED], Oliver Fromme writes : 1. I have some shell scripts that make use of redirections with file descriptors (31 and /dev/fd/3 etc.). Those worked under 4.x out of the box, but didn't work in 5.0, because there is no /dev/fd/3 in DEVFS. I solved this by manually mounting FDESCFS over /dev/fd -- is that the right solution, or is there a better way? There is a bug in the /bin/sh which I belive may be present in 5.0-R where the shell uses fd=3 internally. For the other part of the question: yes, that is the right way if you want to use filedescriptors 2. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Wrong date for DEVFS entries
In message [EMAIL PROTECTED], Andrey A. Chernov writes:
On Wed, Feb 05, 2003 at 20:52:54 +0100, [EMAIL PROTECTED] wrote:
My guess: Your RTC has the wrong time and ntpdate or similar stepped
your clock to be correct.
It is each boot repeated effect, not one time.
I run local clock in BIOS and use adjkerntz(8) to correct kernel time to
GMT, via standard /etc/wall_cmos_clock knob. It there any chance that
DEVFS comes up in the middle? If yes, is there any ideas for workaround?
You can try this patch instead. It has a different side effect:
if you reset your clock the (untouched) timestamps will change.
Index: devfs_vnops.c
===
RCS file: /home/ncvs/src/sys/fs/devfs/devfs_vnops.c,v
retrieving revision 1.60
diff -u -r1.60 devfs_vnops.c
--- devfs_vnops.c 29 Jan 2003 22:36:45 - 1.60
+++ devfs_vnops.c 5 Feb 2003 19:58:52 -
@@ -243,22 +243,19 @@
} while (0)
if (vp-v_type != VCHR) {
- fix(de-de_atime);
vap-va_atime = de-de_atime;
- fix(de-de_mtime);
vap-va_mtime = de-de_mtime;
- fix(de-de_ctime);
vap-va_ctime = de-de_ctime;
} else {
dev = vp-v_rdev;
- fix(dev-si_atime);
vap-va_atime = dev-si_atime;
- fix(dev-si_mtime);
vap-va_mtime = dev-si_mtime;
- fix(dev-si_ctime);
vap-va_ctime = dev-si_ctime;
vap-va_rdev = dev-si_udev;
}
+ fix(vap-va_atime);
+ fix(vap-va_mtime);
+ fix(vap-va_ctime);
vap-va_gen = 0;
vap-va_flags = 0;
vap-va_nlink = de-de_links;
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Wrong date for DEVFS entries
In message [EMAIL PROTECTED], Andrey A. Chernov writes: On Wed, Feb 05, 2003 at 22:10:41 +0100, [EMAIL PROTECTED] wrote: You can try this patch instead. It has a different side effect: if you reset your clock the (untouched) timestamps will change. It not helps, see 00:48 - 03:48 future jump for some entries (00:48 is boot time): Try to remove the three fix lines, and see what you get then. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Wrong date for DEVFS entries
In message [EMAIL PROTECTED], Andrey A. Chernov writes: On Wed, Feb 05, 2003 at 23:23:26 +0100, [EMAIL PROTECTED] wrote: Try to remove the three fix lines, and see what you get then. Very strange effect: 3 kinds of entries appearse: 1) Jan 1 1970 These are the intact untouched timestamps. 2) Feb 6 01:36 (boot time) 3) Feb 6 04:36 (+3 TZ future jump) These timestamps have been touched, and the clock has made a 3 hour jump either forward or backward at some point. The problem is the clock jump, not DEVFS. Poul-Henning To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Wrong date for DEVFS entries
In message [EMAIL PROTECTED], Andrey A. Chernov writes: On Wed, Feb 05, 2003 at 23:44:08 +0100, [EMAIL PROTECTED] wrote: 2) Feb 6 01:36 (boot time) 3) Feb 6 04:36 (+3 TZ future jump) These timestamps have been touched, and the clock has made a 3 hour jump either forward or backward at some point. The problem is the clock jump, not DEVFS. Clock jump happens as it supposed when adjkerntz(8) corrects machine clock back to GMT via various CPU_* sysctl's. Could touched DEVFS stamps be fixed back to something useful in the same sysctl code too? No. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Minor oddity with sysinstall/disklabel on -current
In message p05200f51ba651eaf1dd8@[128.113.24.47], Garance A Drosihn writes: So, I'm trying something on -current. I boot up, log into root. I have two hard disks on the system. All of my mounted partitions are on ad0, except for one partition on ad2. I 'umount' that partition. I run the Disklabel Editor via sysinstall. I delete that partition, and then re-create it as a UFS2 partition. I do the 'w'rite, and everything looks fine. I drop out of sysinstall, do some things with that partition, and then decide to redo the above sequence. Everything has been working fine, but I'm just testing some things and I end up in a position where it's quicker to newfs the partition than it is to 'rm' the files on it. So, I do the same exact sequence (starting with the 'umount' before running sysinstall), and this time when I do the 'w'rite, I am told: ERROR: Unable to write data to disk ad2! My guess is that sysinstall (bogusly) did a swapon for the 'b' parititon on your ad2 disk. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Preview: GEOMs statistics code.
In message a05200f08ba65f714a4e9@[146.106.12.76], Brad Knowles writes: At 10:44 PM +0100 2003/02/04, Poul-Henning Kamp wrote: In difference from the devstat framework which measures how big a percentage of the time a drive has one or more outstanding requests, I think that measuring the responstime is a much more useful metric. (comments, input, references welcome) This is queue depth versus latency, right? I don't suppose a request to provide both would hold any weight with you, would it? I'm 100% wide open to suggestions. Anything I can trivally account for is fair game. I don't have a queue-depth as such, but I have number of transactions in transit. Will a snapshot of that at the time of the read do what you want ? I am too sleepy to know if that will allow you to calculate the average number of outstanding requests precisely. Ohh, another thing I should add: I won't be locking the stats counters, so reads may get inconsistent results. There is no risk for the updates, because all the updating happens in the g_up thread, so there is no contention for changing the kernel fields. The risk is that the copy passed to userland may happen in the middle of an update and therefore have a field with a weird value which will look OK at the next reading. The risk is quite small because the g_up thread has higher priority than anything coming in from userland will ever have. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Preview: GEOMs statistics code.
In message [EMAIL PROTECTED], Greg 'groggy' Lehey writes: 2. %busy. I personally think this is the most important one, but as you say, there's no reason not to do the others as well. The problem with this one is that we can't measure it in a way which tells us the truth, and we may not even be able to find a meaningful definition of the truth: Is a scsi disk busy if it has received one request but has 64 tagged-queing openings ? Is it idle ? is it 1/64 busy ? Is a disk 100% busy if it has requests outstanding at all times, but could handle five times as many requests because they could be sorted into the current stream of requests free of cost ? Or is it only 20% busy ? How do you measure it ? Responsetime on the other hand is a very reliable estimator of how long time you next request is going to take to handle. 3. Average number of requests waiting. I don't have a queue-depth as such, but I have number of transactions in transit. Will a snapshot of that at the time of the read do what you want ? What's the difference? I would have thought that's the same thing. 1.000 read statistics, find 1 item in queue 1.001 1000 requests arrive 1.999 999 of them + the first one finish 2.000 read statistics, find 1 item in queue The correct average queue length is close to a thousand, but the sampled number will be just one. It's random sampling. Without some comparatively expensive math in the kernel I don't think I can see a way to return the correct number. Of course the transaction rate for the above example will be 1000/sec but it will not say if those were handled one at a time or if they arrived in one large pile like above. For truly trying to understand our disk-I/O load, tracelogs will be needed (And I fear they will show a lot of interesting phenomena). Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: extended slices on 5.0-RELEASE?
In message [EMAIL PROTECTED], Mike Meyer writes: [I asked this on -questions, and got no response, so...] Is it just me, or has disklabel lost the ability to read/write from extended slices in 5.0-RELEASE? I hope not. Please send me the output of sysctl -b kern.geom.confxml in private email. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
In message [EMAIL PROTECTED], Andrey A. Chernov writes: --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 02, 2003 at 01:11:06 -0800, Kris Kennaway wrote: =20 Another problem (noticed by tjr) is that once the sequence hits '0' it jumps to INT_MAX and stays there forever. For example, seeding with srand(0) produces nothing but INT_MAX from rand(). =20 It looks like a lot more validation of this PRNG is needed. Don't have an idea about this thing yet, maybe some sign or variable size= =20 change fix required. BTW, note that new formulae also used in the kernel (by BSD developers) and taken from there - libkern/random.c - so all you say is true there too. It should be nuked from the kernel, and arc4random() used instead. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
In message [EMAIL PROTECTED], Andrey A. Chernov writes: On Sun, Feb 02, 2003 at 17:30:48 +, Mark Murray wrote: Why not? Arc4 is a) deterministic and b) good for all bits. If you mean arc4random() function - not, because it use true randomness, if you mean RC4 algorithm, probably yes, but we should compare its distribution with our current variant and be sure that speed is acceptable. What form RC4 distribution have? RC4 can be implemented in about 4 lines of C. Anyway, last time we discussed this, I think we stuck with the rand() we had because we feared that people were using it's repeatable well documented sequence of random numbers in regression testing. This is still a valid concern, but I don't know how significant a concern it is. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
In message [EMAIL PROTECTED], Andrey A. Chernov writes: On Sun, Feb 02, 2003 at 19:32:50 +0100, [EMAIL PROTECTED] wrote: Anyway, last time we discussed this, I think we stuck with the rand() we had because we feared that people were using it's repeatable well documented sequence of random numbers in regression testing. As documented, it must be repeatable across the calls for same seed, that is all. It not means repeatable accross platforms or across different OS versions. In fact it is already not repeatable across different OS'es, so regression is limited. Also, regression must not stop bugs fixing progress in anycase. Our manual pages do not comprehensively list all compatibility concerns or concessions, waving our manpage about does not address the concern. As I said, I don't know how big a concern this is. But last time it was enough of a concern to make us keep rand() as it was. Please surf the mail-archives to find the discussion, it contained a lot of good arguments from both sides, arguments which should be thought about before changing rand(). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
In message [EMAIL PROTECTED], Mark Murray wr ites: We have most of this, and RC4 can deliver. RC4's licence is fine. Call it ArCFour and there is no problem. The code is small, fast and repeatable, and meets conditions 1-4 above. There are some concerns about RC4's strength and predictability. In cases were we just want trivial randomness, this doesn't matter, but when we start to seed it with /dev/random to get good randomness we to be more careful. Maybe we should spend an AES on it, just in case ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gbde vnode md devices?
In message [EMAIL PROTECTED], Darryl Okahata writes : su-2.05b# gbde init /dev/md0 -L /tmp/foo.lock Don't use the -L and -l arguments unless you have to. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gbde vnode md devices?
In message [EMAIL PROTECTED], Darryl Okahata writes : [EMAIL PROTECTED] wrote: su-2.05b# gbde init /dev/md0 -L /tmp/foo.lock Don't use the -L and -l arguments unless you have to. Thanks, but that was what I originally tried, and I still got the gbde: ioctl(GEOMCONFIGGEOM): Invalid argument error. In other words, I get the same error regardless of whether or not I use the -L/-l options. Can you please try this: mdconfig -a -t malloc -s 4m -u 75 gbde init /dev/md75 gbde attach md75 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gbde vnode md devices?
In message [EMAIL PROTECTED], Darryl Okahata writes : [EMAIL PROTECTED] wrote: Can you please try this: mdconfig -a -t malloc -s 4m -u 75 gbde init /dev/md75 gbde attach md75 Nope, exact same error. That is weird, it works like a charm here. syv# mdconfig -a -t malloc -s 4m -u 75 syv# gbde init /dev/md75 Enter new passphrase: Reenter new passphrase: Wrote key 0 at 814080 syv# gbde attach md75 Enter passphrase: syv# gbde detach md75 Say, do you actually have the GEOM_BDE option in your kernel ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gbde vnode md devices?
In message [EMAIL PROTECTED], Darryl Okahata writes : [EMAIL PROTECTED] wrote: Say, do you actually have the GEOM_BDE option in your kernel ? Sigh, no. I missed it in gbde(4). You might want to further idiot-proof gbde(8) with code like: err(1, ioctl(GEOMCONFIGGEOM) (is \options GEOM_BDE\ in the kernel?)); Yeah, this will happen. GBDE is the first user of what can only be described as a very green config-API for GEOM classes. One idea I have almost convinced myself to implement, despite its unUNIX like nature is to include a char erortext[256] in the request package because the idea that all errors have integer numbers gets old really really fast with the rather complex conditions some of the GEOM modules test for: return (EYOUARESHRINKINGAPARTITIONWHICHISOPEN) I think not :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ata0: resetting device - ASUS P4S8X
In message [EMAIL PROTECTED], Christoph Kuk ulies writes: I bought new hardware for a server today, an ASUS P4S8X with an 1.8 GHZ P4 CPU, nothing fancy I would say, which has an onboard RAID controller (Promise) but I'm not using it for the moment. I attached an IBM 60GB Deskstar ATA/IDE disk to the IDE 1 port. FreeBSD 5.0R boots until the point where it says: ad0: READ command timeout tag=0 serv=0 - resetting ata0: resetting device and there it hangs forever. set hw.ata.ata_dma=0 in the bootloader. Sos@ is working the issue and will love to have a tester :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: split out patch
In message [EMAIL PROTECTED], Ju lian Elischer writes: still no comments? Julian, you sent this out a few hours ago, after people had spent a lot of time and getting quite frustrated trying to get you to DTRT with your mentee's inappropriate commit. If people are sick and tired of you right now, you can't blame them. Expecting any kind of response to this until people have gotten their trees working again is premature, and if you end up at the bottom of their TODO pile because of what came before this, there is nothing for you to do, except to wait patiently. Rushing an untested patch (Yes, I know you you havn't. I know how long time it takes, and you don't even have an SMP box to test it on.) at this point it time would be downright stupid. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: split out patch
In message [EMAIL PROTECTED], Ju lian Elischer writes: Oh shut up Poul-Henning. Try to remain civil here Julian :-) I tried to explain the situation to you, to make sure you would not be tempted to do rush something which needs to take the time things take. I know I'm on your shit list, and have been for years but don't consider youself as spokesman for anyone but yourself. I consider myself spokesman for nobody but myself, and to that end I am very happy to not be on core anymore :-) Go invade Ireland or something. No way, it might disrupt their breweries or something. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VOP_STRATEGY on VCHR
In message [EMAIL PROTECTED], Enache Adrian writes: I get this when I try to access for the first time a file on an ext2fs filesystem. VOP_STRATEGY on VCHR Please try this patch and let me know if it helps ? Index: ext2_vnops.c === RCS file: /home/ncvs/src/sys/gnu/ext2fs/ext2_vnops.c,v retrieving revision 1.75 diff -u -r1.75 ext2_vnops.c --- ext2_vnops.c4 Jan 2003 08:47:19 - 1.75 +++ ext2_vnops.c28 Jan 2003 08:37:50 - @@ -1528,7 +1528,7 @@ } vp = ip-i_devvp; bp-b_dev = vp-v_rdev; - VOP_STRATEGY(vp, bp); + VOP_SPECSTRATEGY(vp, bp); return (0); } -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: last KSE changes
In message [EMAIL PROTECTED], Jul ian Elischer writes: The rumour mill has been running wild on this but **AS FAR AS I KNOW** the breakages have been fixed, since no-one has told me directl of any current breakages. If you have any breakage from this commit, PLEASE TELL ME! I think you should read your mailbox carefully, I remember a number of objections being raised against other parts of this patch. As for cross-arch breakage I suggest you run make universe before committing in the future. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mdconfig -l broken after /sys/dev/md/md.c rev 1.77
In message [EMAIL PROTECTED], Giorgos Keramidas writes: mdconfig -l stopped working in -current after revision 1.76 of md.c. I just reverted src/sys/dev/md/md.c to revision 1.76 and removed M_WAITOK to let me build a kernel with that version of md.c. Now mdconfig correctly lists the open md devices. This is fixed now. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Am I blind? (devfs issue)
In message [EMAIL PROTECTED], Thomas E. Zander write s: Sorry, this is probably a stupid question, but: [riggs] ~ ll /dev/ds* crw-rw-rw- 1 root wheel 30, 3 27 Jan 14:46 /dev/dsp0.0 crw-rw-rw- 1 root wheel 30, 0x00010003 27 Jan 10:59 /dev/dsp0.1 crw-rw-rw- 1 root wheel 30, 5 27 Jan 10:59 /dev/dspW0.0 crw-rw-rw- 1 root wheel 30, 0x00010005 27 Jan 10:59 /dev/dspW0.1 crw-rw-rw- 1 root wheel 30, 11 27 Jan 10:59 /dev/dspr0.0 [riggs] ~ ll /dev/dsp crw-rw-rw- 1 root wheel 30, 3 27 Jan 14:46 /dev/dsp Could somebody explain to me why the device isn't listed in the first ls -l call? Hehe: welcome to clonable devices :-) Notice that the major/minor is 3/27 which maps to /dev/dsp0.0. /dev/dsp is a cloned device which gives you the first free /dev/dsp* device. cloned devices do not appear in readdir requests, that's why you don't see it with ls -l /dev/dsp* -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Opening /dev/tty in session leader after controlling terminal is revoked causes panic.
In message [EMAIL PROTECTED], Peter Edwards writes: The problem is in kern/tty_tty.c:ctty_clone. It's assuming that if the process has its P_CONTROLT flag set, then it's session has a valid vnode for it's controlling terminal. This doesn't hold if the terminal was revoked. Yes, this patch also fixes the problem. OK, committed! -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sbin/disklabel disklabel.8 disklabel.c
In message [EMAIL PROTECTED], Ruslan Ermilov writes: and installed the new kernel (without any problems) on it. Next reboot refused to boot FreeBSD by mentioning that No operating system was found. I wondered how I managed to screw my disk up. Welcome to the club if people who was bitten by the poor design choices in the BSD disklabel. Now the question. Where is the code in the kernel that prevents swapping and/or writing to a disklabel portion of a physically first partition on the disk? In GEOM it works the following way: Assume we have a disk: ad0. The disk has an MBR with two slices: ad0s1 ad0s2. Assume that ad0s1 has a BSD disklabel with three partitions: ad0s1a ad0s1b and ad0s1c. When nothing is opened yet, you can open any of those devices anyway you want, and (almost, see below) write anything you want to any of them. No, lets say you open ad0s1a for writing. Since the location of ad0s1a is determined by the on-disk BSD disklabel, we cannot allow you to trash that label now. The BSD module will therefore open ad0s1 with an Exclusive bit, which means don't write under my feet. If you try to open ad0s1 for writing now, you will get EPERM. You can open ad0s2 for writing because the MBR module will reaslize that they don't overlap so there is no danger. When The BSD label opens ad0s1, the same thing repeats: The MBR module wants to protect the MBR, so it also opens /dev/ad0 with the exclusive bit and therefore you cannot open /dev/ad0 for writing. So far so good. You cannot trash the MBR by writing to ad0s1 or ad0s2 because despite all its failings, the MBR does not have it's controlling meta-data in-band. Basically the disklayout is: [MBR sector][slice 1][slice 2] The BSD disklabel on the other hand, puts the label into harms way by allowing partitions to overlap the disklabel and bootblock area: [LABEL-area] [partition A ] [partition B] So special magic is implemented to check if the writes you do to one of the ad0s1? partitions would modify the label-area, and intercept the write, validate that it contains a disklabel compatible which do not modify the currently open partitions and generally DTRT. This protection does not extend down in the stack: If you didn't open any of the ad0s1? paritions, nothing prevents you from opening ad0s1 for writing and trashing the BSD label that way. The final wrinkle is that the 'c' partition overlaps the 'a' and 'b' partitions, so once you have opened ad0s1a for writing you are no longer allowed to open ad0s1c for writing since that would allow you to royally screw up the filesystem on 'a' under its feet. Do I hate the fact that the disklabel and boot code is in-band in BSD labels ? Yes you bet. If it wasn't because the BSD label has so many other restrictions, I would simply change our policy to not allow the overlap: no partitions in the first 16k, end of story. Sure it would take some time to migrate etc etc. But (fortunately) the BSD label has some stupid limitations and I have decided that we should migrate to a more powerful format, and that the GPT format looks like the thing, so I'm just going to leave the BSD label with it's broken semantics as it is. Thanks for asking the question, it prompted me to explain this stuff, and I've cc'ed the doc crew because this answer should probably go into a FAQ/DOC of some kind. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADSUP: disklabel(8): men at work.
In message [EMAIL PROTECTED], Wilko Bulte writes: On Sun, Jan 26, 2003 at 03:47:11PM +0100, Poul-Henning Kamp wrote: I'm still not done with disklabel(8), and I have not run it through all the tests I want (I'm waiting for my glacial 233MHz EV45 alpha to compile a world) so be careful what you do with disklabel and in particular the -B option. Time to put a DS10 on wantlist.sgml I suppose? ;) Well, not really :-) I don't use the alpha very often and I suspect it will mainly be for exactly fiddling BSD labels, so I think that a DS10 would be put to better use many other places than in my lab. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha/GENERIC børked
In message [EMAIL PROTECTED], Poul-Henning Kamp writes: # make cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror ../../../alpha/alpha/interrupt.c cc1: warnings being treated as errors ../../../alpha/alpha/interrupt.c: In function `alpha_clock_interrupt': ../../../alpha/alpha/interrupt.c:483: warning: passing arg 1 of `statclock_process' from incompatible pointer type *** Error code 1 Sorry for replying to myself, but it seems to me that the KSE-intelligensia needs to test on more than i386-UP. Considering that we can cross-build kernels, I think there is no valid excuse for such blatant: it works for me! testing: bang# sh gsys statclock_process ./alpha/alpha/interrupt.c: statclock_process(curkse, TRAPF_PC(framep), ./i386/i386/critical.c: statclock_process(curthread, ./i386/i386/mp_machdep.c: * WARNING! unpend() will call statclock_process() directly and skip this ./i386/i386/mp_machdep.c: statclock_process(curthread-td_kse, TRAPF_PC(frame), ./ia64/ia64/interrupt.c:statclock_process(curkse, TRAPF_PC(framep), ./kern/kern_clock.c:statclock_process(struct thread *td, register_t pc, int user) ./kern/kern_clock.c:statclock_process(curthread, CLKF_PC(frame), CLKF_USERMODE(frame)); ./sparc64/sparc64/tick.c: statclock_process(curthread-td_kse, CLKF_PC(cf), ./sys/systm.h:void statclock_process(struct thread *td, register_t pc, int user); -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GEOM disklabel
In message [EMAIL PROTECTED], Michael Reifenberger writes: On Fri, 24 Jan 2003 [EMAIL PROTECTED] wrote: ... Don't use the '-r' option, it gets confused because geom::BSD does not lie to it. Yes, that seems to work... Time to say good bye for '-r' ? Well, we still need it for writing the first disklabel on an otherwise empty disk, but I think it could be implied in that case. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Opening /dev/tty in session leader after controlling terminal is revoked causes panic.
In message [EMAIL PROTECTED], Peter Edwards writes: The problem is in kern/tty_tty.c:ctty_clone. It's assuming that if the process has its P_CONTROLT flag set, then it's session has a valid vnode for it's controlling terminal. This doesn't hold if the terminal was revoked. Can you try this patch ? Index: tty_tty.c === RCS file: /home/ncvs/src/sys/kern/tty_tty.c,v retrieving revision 1.46 diff -u -r1.46 tty_tty.c --- tty_tty.c 19 Jan 2003 11:03:07 - 1.46 +++ tty_tty.c 25 Jan 2003 19:39:15 - @@ -70,10 +70,12 @@ return; if (strcmp(name, tty)) return; - if (curthread-td_proc-p_flag P_CONTROLT) - *dev = curthread-td_proc-p_session-s_ttyvp-v_rdev; - else + if (!(curthread-td_proc-p_flag P_CONTROLT)) + *dev = ctty; + else if (curthread-td_proc-p_session-s_ttyvp == NULL) *dev = ctty; + else + *dev = curthread-td_proc-p_session-s_ttyvp-v_rdev; } static void -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GEOM disklabel
In message [EMAIL PROTECTED], Michael Reifenberger w rites: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to [EMAIL PROTECTED] for more info. --0-240786022-1043432225=:647 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, trying to disklabel new disks I get: (nihil)(root) # disklabel -w -B da0s1 auto (nihil)(root) # disklabel -r da0s1 Don't use the '-r' option, it gets confused because geom::BSD does not lie to it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current error in kernel build with NO_GEOM
In message [EMAIL PROTECTED], Gary Jennejohn w rites: Am I the only person using NO_GEOM in -current? Probably. NO_GEOM is scheduled to be removed as an option in some weeks, so if there is a bug or other issue which prevents you from running GEOM this would be a really good time to tell me. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: I want a sysctl kern.allow_shooting_into_my_foot!
In message [EMAIL PROTECTED], Bernd Walter writes: On Tue, Jan 21, 2003 at 11:06:05PM +0100, [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Joerg Wunsch writes: As [EMAIL PROTECTED] wrote: Hang on. If no disk partitions of any kind are open, there is nothing which prevents you from doing a dd if=/dev/zero of=/dev/da0 bs=64k. My guess is that vinum scanned the disks when starting, but found nothing on it. And forgot to close them again ? Well, you know where to look for that bug then :-) (If you look in the sysctl -b kern.geom.confxml output, you will be able to see the read/write/exclusive open counts, look for r%dw%de%d strings.) Interesting sysctl. Yes, one of the more informative :-) provider id=0xc2c4c800 geom ref=0xc2c4d300/ moder1w1e0/mode nameda13e/name mediasize652329984/mediasize sectorsize1024/sectorsize config index4/index length652329984/length seclength1274082/seclength offset0/offset secoffset0/secoffset /config /provider /geom If I got it right it tells me, that da13e is opened for read/write. You can also try this, it's more easily informative: sysctl -n kern.geom.confdot | dot -Tps _.ps ; gv _.ps You need the graphviz and ghostscript ports for this. I never complained about this, because the system is rather old (2002-11-15) and I believed it was already fixed. But it sounds like Joergs situation may be triggered by the same bug. Mmmm - I'm using vinum too. Is there any way to find out which ones open it was? Hmm, since this happens during boot, you cannot set the debug flag with sysctl in time, so you have to compile a custom kernel for it: in sys/geom/geom_kern.c change: int g_debugflags; to int g_debugflags = G_T_ACCESS; and recompile + reboot. This will make GEOM printf all access (ie: open/close) changes and you should hopefully be able to deduce where the open of your MO comes from. If this is not enough, you can try to set int g_debugflags = G_T_ACCESS | G_T_TOPOLOGY; But that will result in much more debugging output. You can turn this debugging off from userland with: sysctl kern.geom.debugflags=0 Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: I want a sysctl kern.allow_shooting_into_my_foot!
In message [EMAIL PROTECTED], Joerg Wunsch writes: Here's the result. What does it mean to me? (debug flag set from DDB, and turned off in single-user again.) Here's the bug: g_dev_open(da1a, 3, 0, 0) da1a opened (FREAD|FWRITE) g_access_rel(0xc1178a40(da1a), 1, 1, 0) open delta:[r1w1e0] old:[r0w0e0] provider:[r0w0e0] 0xc11d4f00(da1a) g_post_event(2, 0, 0, 0xc11d4f00, 0xc1178a40) g_access_rel(0xc1178f40(da1), 1, 1, 1) open delta:[r1w1e1] old:[r0w0e0] provider:[r0w0e0] 0xc1194d00(da1) g_post_event(2, 0, 0, 0xc1194d00, 0xc1178f40) g_disk_access(da1, 1, 1, 1) g_do_event(0xc1178780) 2 m:0 g:0 p:0xc11d4f00 c:0xc1178a40 - EV_SPOILED(0xc11d4f00(da1a),0xc1178a40) g_do_event(0xc1178740) 2 m:0 g:0 p:0xc1194d00 c:0xc1178f40 - EV_SPOILED(0xc1194d00(da1),0xc1178f40) spoiling 0xc1178e40 (da1) (0) g_dev_close(da1a, 0, 0, 0) da1a closed but without FREAD|FWRITE, which turns the close into a no-op. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: I want a sysctl kern.allow_shooting_into_my_foot!
In message [EMAIL PROTECTED], Bernd Walter writes: da1a closed but without FREAD|FWRITE, which turns the close into a no-op. [125]cicely5# grep d_open * grep: CVS: Operation not permitted vinumext.h:d_open_t vinumopen; vinumio.c: drive-lasterror = (dsw-d_open) (drive-dev, FWRITE | FREAD, 0, NULL); Exit 2 [126]cicely5# grep d_close * grep: CVS: Operation not permitted vinumext.h:d_close_t vinumclose; vinumio.c:error = (*devsw(drive-dev)-d_close) (drive-dev, 0, 0, NULL); Exit 2 You are saying that the close should read? error = (*devsw(drive-dev)-d_close) (drive-dev, FWRITE | FREAD, 0, NULL); Yes, d_close should match whatever the corresponding d_open is called with. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADSUP: CCD(4) hackery...
In message [EMAIL PROTECTED], Lars Eggert writes: I just booted today's -current kernel in single-user mode to do an installworld, and when I do the usual ccdconfig -C (since my /usr is striped), I now get: # ccdconfig -C ccdconfig: open: /dev/ccd0c: No such file or directory My /etc/ccd.conf has: ccd0127 0 /dev/da0s1e /dev/da1s1e Is there any way to revive my stripes, or are they toast? Your stripes should be unhurt. All you need is a new ccdconfig binary. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: I want a sysctl kern.allow_shooting_into_my_foot!
In message [EMAIL PROTECTED], Joerg Wunsch writes: Included an old disk into a running system. Want to install a new label onto it: uncle# disklabel -Brw da0 auto disklabel: ioctl DIOCSDINFO: open partition would move or shrink Needless to say, there is nothing open at all on it. As i said, an old disk that incidentally has a BSD label on it. It could have had a Sun label, a stale fdisk table, or whatever on it. Needless to say, it doesn't allow me to dd /dev/zero over it, as i could do in any FreeBSD version until now. Hang on. If no disk partitions of any kind are open, there is nothing which prevents you from doing a dd if=/dev/zero of=/dev/da0 bs=64k. Now, if you tell me you tried dd if=/dev/zero of=/dev/da0c bs=64k it would stop you (notice ^) If you still cannot erase the disk with dd(1), please send me the output of sysctl -b kern.geom.confxml -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: I want a sysctl kern.allow_shooting_into_my_foot!
In message [EMAIL PROTECTED], Joerg Wunsch writes: As [EMAIL PROTECTED] wrote: Hang on. If no disk partitions of any kind are open, there is nothing which prevents you from doing a dd if=/dev/zero of=/dev/da0 bs=64k. My guess is that vinum scanned the disks when starting, but found nothing on it. And forgot to close them again ? Well, you know where to look for that bug then :-) (If you look in the sysctl -b kern.geom.confxml output, you will be able to see the read/write/exclusive open counts, look for r%dw%de%d strings.) However, my really concern is what i wrote in the subject: i do want something like an option -f for all of this. GEOM will not allow you to do things which will panic your kernel, and I'm not going to add that facility, we already have enough panic(8) implementations if you want one. Now, if you tell me you tried dd if=/dev/zero of=/dev/da0c bs=64k it would stop you (notice ^) Sorry, this was too unexpected to me, and meanwhile i've found a way to trash and relabel that disk, so i cannot reproduce it anymore. Why the sudden `c' partition for it? I thought this is rather considered obsolete, and was merely a historical feature used in a time when there was no such method like accessing /dev/da0 directly? This sounds like a step 5 years backwards to me. I tried to say that if you tried da0c it should stop you, not that it should work. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: I want a sysctl kern.allow_shooting_into_my_foot!
In message [EMAIL PROTECTED], Joerg Wunsch writes: It wouldn't have paniced it at all, since i /knew/ nothing was open on it. Well, the only reason why GEOM didn't let you was that it knew that something was open. As I said, the XML output contains the truth in this matter... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: malloc(M_WAITOK) returned NULL
In message [EMAIL PROTECTED], Kris Kennaway writes:
I just got the following on axp1:
panic: malloc(M_WAITOK) returned NULL
db_print_backtrace() at db_print_backtrace+0x18
panic() at panic+0x104
malloc() at malloc+0x1a8
initiate_write_inodeblock_ufs1() at initiate_write_inodeblock_ufs1+0xc4
softdep_disk_io_initiation() at softdep_disk_io_initiation+0xa4
spec_strategy() at spec_strategy+0x158
spec_vnoperate() at spec_vnoperate+0x2c
This is a bug in the kernel memory allocator, since it should not be
able to return NULL when M_WAITOK is specified. The potential bugs
are more likely because M_WAITOK is defined as zero.
M_WAITOK
Indicates that it is Ok to wait for resources. It is unconve-
niently defined as 0 so care should be taken never to compare
against this value directly or try to AND it as a flag. The
default operation is to block until the memory allocation suc-
ceeds. malloc(), realloc(), and reallocf() can only return NULL
if M_NOWAIT is specified.
void *
malloc(size, type, flags)
unsigned long size;
struct malloc_type *type;
int flags;
{
[...]
if (!(flags M_NOWAIT))
KASSERT(va != NULL, (malloc(M_WAITOK) returned NULL));
[...]
}
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: SMP hang at boot on Compaq Proliant ML370
In message [EMAIL PROTECTED], Nicolas Kowalski writes: Fritz Heinrichmeyer [EMAIL PROTECTED] writes: On Wed, Jan 15, 2003 at 11:09:09AM +0100, Nicolas Kowalski wrote: The server is configured for Unixware7, as told in the archives. our Compaq worked when configured for linux Nope :-(. I just tried this option, and the server still hangs at the same point. I had a Compaq visit my lab recently. Unless the aic driver were removed from the kernel (disabling it might have worked too) it would screw up the floppy driver. This sounds like black magic, but the explanation is that the aic driver has a very intrusive probe routine which sticks random bytes into whatever I/O locations it feels like and this appearantly is not liked by certain machines. Compaqs with all their bells and whistles could be particular sensitive to this, so try to disable the aic driver and see if it helps. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Somebody: port this: http://www.theinquirer.net/?article=7231
In message [EMAIL PROTECTED], Kris Kennaway writes: --ALfTUftag+2gvp1h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The tool costs $699 and Intel said it will be available in February. That would make it somewhat difficult, no? I don't think so. VTUNE is plenty worth it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 5.0 RC3 now available
In message [EMAIL PROTECTED] .com, local.freebsd.current writes: On Mon, 13 Jan 2003 11:46:43 -, [EMAIL PROTECTED] wrote: In the meantime we _really_ have to ship 5.0-RELEASE, we keep slipping it. That sounds like it's time to ship so we're going to ship. That's it. I'm not trying to get up anyone's nose here, but aren't there objective release criteria? yes: No more delays :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 5.0 RC3 now available
In message [EMAIL PROTECTED], Roderick van Domburg writes: I would like to point to a currently unresolved issue that Thomas Moestl is helping me solve on freebsd-sparc@. It isn't listed on the Open Issues page, but I'd say it's something that needs to be resolved before the release is rolled. The thread is titled panic: trap: fast data access mmu miss and is about an error causing the sym SCSI controller to fail to mount root at best, and panic at worst. Well, we all want our pet bug fixed before the release rolls, but at some point we simply have to call it quits and ship the release. I personally know this particular bug very well, I have rebooted the AC/DC200 netra I had borrowed about 10 times more than I needed to to get past this bug :-) The sym controller is listed as supported hardware, and used in several Sun boxes, so IMHO I'd say it warrants the attention. All bugs warrent attention. Some of them get it. Don't worry, that bug, like all the others will get fixed and you will be able to get an update for it in due time. In the meantime we _really_ have to ship 5.0-RELEASE, we keep slipping it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Geom disklabel/fdisk issues?
In message [EMAIL PROTECTED], Ju lian Elischer writes: I think that one of the things we need to do is declare a new flag in disklabel that declares that the disklabel has been converted to use relative offsets. if the flag is not set then absolute offsets are expected.. That would give a way for us to move forward while still allowing partitions to co-exist with 4.x systems. in -current, geom just has to 'work with it' if the bit is not set. New systems would automatically set the bit. Better plan: Abandon BSD labels before disks outgrow them. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Geom disklabel/fdisk issues?
In message [EMAIL PROTECTED], walt writes: [EMAIL PROTECTED] wrote: Julian Elischer writes: I think that one of the things we need to do is declare a new flag in disklabel that declares that the disklabel has been converted to use relative offsets... Better plan: Abandon BSD labels before disks outgrow them. To be replaced bywhat? Probably EFI/GPT labels -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VOP_SPECSTRATEGY on non-VCHR
In message [EMAIL PROTECTED], Lars Eggert writes: just got this on today's -current, when accessing a mounted NTFS partition: VOP_SPECSTRATEGY on non-VCHR : 0xc6d73c34: tag ntfs, type VREG, usecount 3, writecount 0, refcount 0, flags (VV_OBJBUF), lock type ntfs: SHARED (count 1) Can you try this patch ? Index: vnode_pager.c === RCS file: /home/ncvs/src/sys/vm/vnode_pager.c,v retrieving revision 1.167 diff -u -r1.167 vnode_pager.c --- vnode_pager.c 5 Jan 2003 20:32:03 - 1.167 +++ vnode_pager.c 12 Jan 2003 10:21:08 - @@ -823,7 +823,10 @@ cnt.v_vnodepgsin += count; /* do the input */ - VOP_SPECSTRATEGY(bp-b_vp, bp); + if (dp-v_type == VCHR) + VOP_SPECSTRATEGY(bp-b_vp, bp); + else + VOP_STRATEGY(bp-b_vp, bp); s = splvm(); /* we definitely need to be at splvm here */ -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0 without swap
In message [EMAIL PROTECTED], Geof frey T. Falk writes: Further to my previous message on encrypting swap: In order for it to work, apparently, one must change the fstype within the disklabel, so that the swap partition (e.g. /dev/ad0s1b) is fstype 4.2BSD, not swap. This shouldn't be necessary and any code which requires this is should be fixed. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GEOM prevents bootblocks writing
In message [EMAIL PROTECTED], Sean Kelly writes: Since I haven't seen any response to this, I'll me too it in hopes that it will get some attention drawn to it. boot0cfg and fdisk should work as advertised. There is an erratum on disklabel -B for 5.0-RELEASE. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: strange dump/restore behaviour
I've seen this when dumping live filesystems. I belive it means that dump couldn't find the file it had already dumped in the directory once it got to dump the contents. In message [EMAIL PROTECTED], Dag-Erling Smorgrav writes: This happened while copying data over to a new disk (mounted on /mnt and /mnt/usr; the original disk has only one partition). The machine was in single-user mode, but / was mounted read-write due to restore's insistance on placing temporary files in /tmp (I found out later that it respects TMPDIR, though the man page doesn't mention it). root@dsa /mnt# dump -0Laf- / | restore -rf- DUMP: Date of this level 0 dump: Thu Jan 9 16:11:42 2003 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping snapshot of /dev/da0a (/) to standard output DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 1838856 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] warning: ./usr: File exists expected next file 4, got 3 [...] I can imagine that the file that caused the warning message was one of restore's temporary files, but a) I've never seen this before, and b) isn't -L supposed to prevent just that? DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
