Re: make installworld from r238247 - r238610 break
As Konstantin Belousov wrote: Yes, I think that r238603 missed an update to etc/mtree/BSD.usr.dist. Oops, thanks, fixed! -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) pgp7La7CPWBqu.pgp Description: PGP signature
Re: ACPI thermal panics ThinkPad 600X
As Kevin Oberman wrote: Can you suspend from within graphics mode? Have you tried using APMD to put the display into text mode when suspending? Tried it, but didn't get that to work. I. e., it seems apmd never calls /etc/rc.suspend (i can't see any syslog entry from that logger call either). -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI thermal panics ThinkPad 600X
Matthew N. Dodd [EMAIL PROTECTED] wrote: My only outstanding issue is that I can't suspend if an application is holding /dev/dsp or /dev/audio open. Can you suspend from within graphics mode? I can't seem to do that, neither with APM nor with ACPI. In some case, i've seen four horizontal lines upon wakeup, in other cases, the graphics display gets restored correctly, but the machine still locks up (probably in APM BIOS, not even the lock key LEDs react, but Fn works). Suspending from within text mode always works. The graphics mode problem is particularly annoying if the system enters auto-suspend on a low battery condition... -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) 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
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. :-/ -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: vinum start -current doesn't work as expected
As Greg 'groggy' Lehey wrote: I guess it's time to dump the old vinum start code from vinum(8) completely, and use the in-kernel scan now. This sounds like a good idea. Not after looking a bit closer. ;-) The only difference ist that the userland vinum start uses devstat, while the in-kernel autoscan if vinum.autostart is set uses sysctl kern.disks (devstat is not available in the kernel). Both use the same backend function. So yes, the userland should probably be changed to use the sysctl as well, but that's certainly not the root of Michael's problems. Something else must be the problem there. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: vinum start -current doesn't work as expected
Michael Reifenberger [EMAIL PROTECTED] wrote: After reboot, a `vinum start` gives me: ** no drives found: No such file or directory Do you perchance have a kernel without GEOM? vinum start has now been changed to use sysctl kern.disks as the list of devices to scan. Hmm. No, maybe not... I'm afraid i should change the userland to perform the same as the early startup in the kernel now does. What does your sysctl kern.disks say? As a workaround, you can try setting vinum_load=YES vinum.autostart=YES in your /boot/loader.conf, /and/ remove the start_vinum line from rc.conf. Please tell me whether this gives different results. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Question about devd concept
M. Warner Losh [EMAIL PROTECTED] wrote: devd works for me when I have devices in my machine at boot. It does run the start script for me. I've got a related problem. My kernel is a bit modularized, and with devd, when i insert the card into the running machine, the script framework properly kldloads the respective driver (using /usr/local/bin/smart-loader as suggested in the devd.conf template). However, this doesn't work when the card is already present at boot time. Is this likely to be the same problem? (I'm currently working around it by pre-loading all potential NIC modules from the loader.) -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: vinum start -current doesn't work as expected
As Michael Reifenberger wrote: What does your sysctl kern.disks say? (nihil)(root) # sysctl -a kern.disks kern.disks: da1 da0 ad1 ad0 That's OK. I guess it's time to dump the old vinum start code from vinum(8) completely, and use the in-kernel scan now. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) 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!
As Matthew N. Dodd wrote: On Tue, 21 Jan 2003, Joerg Wunsch wrote: It already stopped me when accessing /dev/da0, so why try something more obscure? Sorry, you've lost me. ftp://ftp.jurai.net/users/winter/patches/geom-foot.patch Just apply it to your local source tree and get on with life. That just saved my day! I've got a disk with some flakey blocks on it that i neede to rewrite. Impossible with GEOM, possible with kern.geom.allow_foot_shooting=1. I really think something like that should be provided by default. It should be the sysadmin who decides what to do, not the kernel. (Note, i don't vote for having the above /enabled by default/, and security paranoid people will bump their securelevel anyway, thus preventing any and all raw disk access.) -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) 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!
As [EMAIL PROTECTED] wrote: 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. Here's the result. What does it mean to me? (debug flag set from DDB, and turned off in single-user again.) -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #11: Tue Jan 14 15:44:49 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/UNCLE Preloaded elf kernel /boot/kernel/kernel at 0xc0463000. Preloaded elf module /boot/kernel/vinum.ko at 0xc04630b4. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 166194348 Hz CPU: Pentium/P54C (166.19-MHz 586-class CPU) Origin = GenuineIntel Id = 0x52c Stepping = 12 Features=0x1bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8 real memory = 33554432 (32 MB) avail memory = 28098560 (26 MB) Initializing GEOMetry subsystem g_add_class(DEV) g_add_class(BSD) g_add_class(MBR) g_add_class(MBREXT) g_add_class(DISK) g_add_class(GEOMCTL) g_call_me(0xc01798e4, 0 npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 pci0: mass storage, ATA at device 7.1 (no driver attached) ahc0: Adaptec 2940A Ultra SCSI adapter port 0xe000-0xe0ff mem 0xfb00-0xfb000fff irq 10 at device 9.0 on pci0 aic7860: Ultra Single Channel A, SCSI Id=7, 3/253 SCBs xl0: 3Com 3c900-COMBO Etherlink XL port 0xd800-0xd83f irq 11 at device 10.0 on pci0 xl0: Ethernet address: 00:60:97:52:77:3a xl0: selecting 10baseT transceiver, half duplex orm0: Option ROM at iomem 0xc8000-0xcc7ff on isa0 atkbdc0: Keyboard controller (i8042) at port 0x64,0x60 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 fdc0: Enhanced floppy controller (i82077, NE72065 or clone) at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 fd1: 1200-KB 5.25 drive on fdc0 drive 1 sc0: System console at flags 0x100 on isa0 sc0: MDA 16 virtual consoles, flags=0x100 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A, console sio1: reserved for low-level i/o vga0: Generic ISA VGA at port 0x3b0-0x3bb iomem 0xb-0xb7fff on isa0 unknown: PNP0501 can't assign resources (port) sio2: 16550A-compatible COM port at port 0x2f8-0x2ff irq 3 on isa0 sio2: type 16550A unknown: PNP0700 can't assign resources (port) unknown: PNP0303 can't assign resources (port) Timecounters tick every 10.000 msec g_do_event(0xc10c0100) 3 m:0 g:0 p:0 c:0 - g_post_event(1, 0, 0, 0xc11ac000, 0) g_do_event(0xc11cd480) 1 m:0 g:0 p:0xc11ac000 c:0 - EV_NEW_PROVIDER(geom.ctl) dev_taste(DEV,geom.ctl) g_call_me(0xc017ad24, 0xc11a5900 g_call_me(0xc017ad24, 0xc110f400 g_do_event(0xc11cd380) 3 m:0 g:0 p:0 c:0 - g_post_event(1, 0, 0, 0xc11ac280, 0) g_do_event(0xc11cd340) 3 m:0 g:0 p:0 c:0 - g_post_event(1, 0, 0, 0xc1194d00, 0) g_do_event(0xc11cd300) 1 m:0 g:0 p:0xc11ac280 c:0 - EV_NEW_PROVIDER(da0) g_mbrext_taste(MBREXT,da0) mbr_taste(MBR,da0) g_access_rel(0xc11cd240(da0), 1, 0, 0) open delta:[r1w0e0] old:[r0w0e0] provider:[r0w0e0] 0xc11ac280(da0) g_disk_access(da0, 1, 0, 0) g_call_me(0xc017ae84, 0xc090d600 cd0 at ahc0 bus 0 target 2 lun 0 cd0: PLEXTOR CD-ROM PX-4XCS 1.01 Removable CD-ROM SCSI-2 device cd0: 4.032MB/s transfers (4.032MHz, offset 15) cd0: Attempt to query device size failed: NOT READY, Medium not present da1 at ahc0 bus 0 target 3 lun 0 da1: SEAGATE ST52160N 0285 Fixed Direct Access SCSI-2 device da1: 20.000MB/s transfers (20.000MHz, offset 15) da1: 2069MB (4238282 512 byte sectors: 255H 63S/T 263C) da0 at ahc0 bus 0 target 1 lun 0 da0: IBM DDRS-34560W S97B Fixed Direct Access SCSI-2 device da0: 20.000MB/s transfers (20.000MHz, offset 15), Tagged Queueing Enabled da0: 4357MB (8925000 512 byte sectors: 255H 63S/T 555C) g_access_rel(0xc11cd240(da0), -1, 0, 0) open delta:[r-1w0e0] old:[r1w0e0] provider:[r1w0e0] 0xc11ac280(da0) g_disk_access(da0, -1, 0, 0) g_std_spoiled(0xc11cd240) g_detach(0xc11cd240) g_destroy_consumer(0xc11cd240) g_destroy_geom(0xc1194c80(da0)) bsd_taste(BSD,da0) g_access_rel(0xc11cd180(da0), 1, 0, 0) open delta:[r1w0e0] old:[r0w0e0] provider:[r0w0e0] 0xc11ac280(da0) g_disk_access(da0, 1, 0, 0) g_slice_conf_hot() g_slice_config(da0, 0, 0) g_slice_config(da0, 1, 0) g_slice_config(da0, 2, 0) g_slice_config(da0, 3, 0) g_slice_config(da0, 4, 0) g_slice_config(da0, 5, 0) g_slice_config(da0, 6, 0) g_slice_config(da0, 7, 0) g_slice_config(da0, 0, 1) g_slice_config(da0, 1, 1) g_slice_config(da0, 2, 1) g_post_event(1, 0, 0, 0xc1194c80, 0) g_slice_config(da0, 3, 1)
Re: I want a sysctl kern.allow_shooting_into_my_foot!
As Bernd Walter wrote: Now that you say it - vinum isn't loaded before going multiuser. Oh, i should add: in my case, it's loaded before mounting the root (root is on vinum). -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) 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!
As [EMAIL PROTECTED] wrote: 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. Thanks for pointing this out, this indeed seems to fix this case, fix already committed. ;-) -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: vinum root [Was: I want a sysctl kern.allow_shooting_into_my_foot!]
Ollivier Robert [EMAIL PROTECTED] wrote: Oh, i should add: in my case, it's loaded before mounting the root (root is on vinum). And how did you achieved this ? I thought vinum isn't able to do that... Well, the patch for -current is currently only sitting here on my machine(s). Greg wanted to review it before i commit it, but i'll append it in case someone else wants to have a look at it. Under -current, the generic part of the kernel (namely mountroot() and its related functions) is already clean enough so no changes are needed there, only vinum needs a patch. Under -stable, the patch is already in the tree. Since mountroot() employs a very simple scheme to derive the dev_t of the root device from the given device name there, a patch to it was required, and all this is not very clean, but it works (see below). The basic concept is that you need to have the loader load the vinum module for you, and vinum needs to be told to configure itself early. Under -current (with the patch), put the following into /boot/loader.conf: vinum_load=YES vinum.autostart=YES Your /etc/fstab needs to have /dev/vinum/root (or whatever you name it) for the / filesystem; the loader will read this file, and pass the device name as the default root device to mountroot(). mountroot() then asks the drivers (by the trick of calling the undocumented event handler for disk_clone) to get a dev_t for the given name. Alternatively, any name entered after boot -a will be resolved the same way. So what the patch does is: . implement the logic to start vinum early . implement an event handler for dev_clone so vinum will get asked, too Under 4.x, put the following into loader.conf: vinum_load=YES vinum.drives=/dev/da0 /dev/da1 /dev/da2 vinum.root=root The logic to have vinum auto-scan the available disks is not yet there, so you explicitly need to name the devices to scan. (This part of the patch has been implemented first here under -current, but can perhaps be MFC'ed, too. The vinum.drives approach will also still work with the -current patch but is less convenient.) Also, since mountroot() has no way to ask the drivers to translate the given name into the corresponding dev_t, the trick with vinum.root is used; if this environment variable is set, vinum will pre-allocate the variable rootdev with the appropriate dev_t if the volume named by this has been found. The generic code will trust this value if the major # of the driver as figured out from the root device name matches the major # of the pre-allocated rootdev. I. e., it still gets /dev/vinum/root from the loader, strips the /dev/ (not needed at all inside the kernel), then scans until the first digit or slash, yielding vinum in that case. Now, if the major number of the preset rootdev matches the major # of vinum, the value will be taken. If rootdev has not been set, the traditional approach by deriving the minor # from the unit #, slice #, and partition name will be taken (using a hardcoded algorithm for this which is independent of the actual driver). All this gives the illusion that mountroot() would know how to handle /dev/vinum/root. ;-) Of course, what you cannot do is to boot -a, then enter an invalid name (so you'll get asked again), and then enter ufs:/dev/vinum/root: the previous invalid name has destroyed the preset rootdev value. At that point, you either need to abort or to enter a valid slice/partition. The biggest problem of all this is, of course, the bootstrapping step. The bootstrap still needs an `a' partition in order to read at least /boot/loader etc. from. The solution is to produce a faked overlay `a' partition that sits at exactly the point where the corresponding vinum subdisk of the root device is located. Another solution would be to setup a mini-root that only contains a boot/ directory in it, and use that one for partition `a', but that'll only cause other trouble (like make install not doing the right thing). While /boot/loader could perhaps be taught how to read something from a vinum volume, there's always the problem how to get at /boot/loader itself, so i have no other idea for this. A script could be provided that creates the faked `a' entry. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) Index: vinum.c === RCS file: /home/ncvs/src/sys/dev/vinum/vinum.c,v retrieving revision 1.49 diff -u -u -r1.49 vinum.c --- vinum.c 1 Apr 2002 21:30:36 - 1.49 +++ vinum.c 13 Jan 2003 21:13:33 - @@ -66,6 +66,8 @@ STATIC int vinum_modevent(module_t mod, modeventtype_t type, void *unused); +STATIC void vinum_clone(void *arg, char *name, int namelen, dev_t *dev); + struct _vinum_conf vinum_conf; /* configuration information */ dev_t vinum_daemon_dev; @@ -79,6
Re: vinum growfs
Alex Deiter [EMAIL PROTECTED] wrote: Say me please, sometime growfs will learn to work with vinum volumes? The growfs maintainers know about the problem, and are working on a solution. We learned about that problem too late before 5.0R was due, so since a quick fix couldn't be produced in time, i think they are now looking for an overall better integration of growfs and newfs (which are very similar in nature). -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) 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!
Daniel C. Sobral [EMAIL PROTECTED] wrote: You can turn this debugging off from userland with: sysctl kern.geom.debugflags=0 Why not make it a loader tunable? Why should it? It's a debugging flag, so it's IMHO sufficient that it can be set from DDB (that's what i did). -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: vinum root [Was: I want a sysctl kern.allow_shooting_into_my_foot!]
[EMAIL PROTECTED] (Joerg Wunsch) wrote:
The biggest problem of all this is, of course, the bootstrapping
step. The bootstrap still needs an `a' partition in order to read
at least /boot/loader etc. from. The solution is to produce a faked
overlay `a' partition that sits at exactly the point where the
corresponding vinum subdisk of the root device is located.
Here's the first cut of a script that would set this up.
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
#!/usr/bin/perl -w
#
# Copyright (c) 2003 Joerg Wunsch
#
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
# 1. Redistributions of source code must retain the above copyright
#notice, this list of conditions and the following disclaimer.
# 2. Redistributions in binary form must reproduce the above copyright
#notice, this list of conditions and the following disclaimer in the
#documentation and/or other materials provided with the distribution.
#
# THIS SOFTWARE IS PROVIDED BY THE DEVELOPERS ``AS IS'' AND ANY EXPRESS OR
# IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
# OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
# IN NO EVENT SHALL THE DEVELOPERS BE LIABLE FOR ANY DIRECT, INDIRECT,
# INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
# NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
# THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#
# $FreeBSD$
#
# Create overlay partition `a' for all devices that are part of the
# named vinum root volume.
$ENV{PATH} = /sbin:/bin:/usr/sbin:/usr/bin;
if (defined($ENV{TMPDIR})) {
$tmpdir = $ENV{TMPDIR};
} else {
$tmpdir = /tmp;
}
$tempname = ${tmpdir}/vinum-a-part.$$;
die usage: $0 rootvolname\n unless $#ARGV == 0;
$rootvol = $ARGV[0];
$nsds = $nlines = 0;
# First, find out the components of our ${rootvol}. Make sure all our
# plexes have only one subdisks, and are of type concat. Remember
# the subdisks found for step #2.
open(V, vinum l -r $rootvol|) || die Cannot start vinum(8)\n;
while (V) {
chomp;
if (/^P/) {
/^P\s+(\S+)\s+([CSR5]+)\s+.*Subdisks:\s+(\d+)/;
$pname = $1;
$org = $2;
$nsd = $3;
$nsd 1 die Plex $pname has more than one subdisk.\n;
$org ne C die Plex $pname is not a concat plex.\n;
} elsif (/^S/) {
/^S\s+(\S+)\s/;
$sdnames[$nsds++] = $1;
}
$nlines++;
}
close(V);
die Volume $rootvol not found.\n unless $nlines 0;
die Volume $rootvol has no subdisks.\n unless $nsds 0;
# Now, for each of the subdisks found, determine size and offset
# inside the vinum drive. Then figure out the disk device (and
# perhaps slice) it belongs to. Analyze the label of that device, to
# see whether the vinum partition is really there.
# If there is already an `a' partition, analyze it. If it already
# matches our expectations, just proceed. If it is inside the vinum
# partition but has wrong parameters, leave it to the operator for a
# manual fix, and proceed. If it is outside vinum, try moving it into
# one of the partition slots `d' through `h'. Failing this, proceed
# to the next subdisk.
# If successful, create a new label with our new `a' partition.
foreach $sd (@sdnames) {
open(V, vinum l -v $sd 2/dev/null |) || die Cannot start vinum(8)\n;
$size = $offset = 0;
$devname = $dev = $part = ;
while (V) {
if (/Size:\s+(\d+)\s+bytes/) {
$size = $1;
} elsif (/Drive\s+\S+\s+[(](\S+)[)].*offset\s+(\d+)/) {
$devname = $1;
$offset = $2;
}
}
close(V);
die Cannot find parameters for sd $sd.\n unless
$size 0 $offset 0 $devname ne ;
$devname =~ s,^/dev/,,;
$devname =~ m|^([a-z]+\d+(s\d+)?)([a-h])$|;
$dev = $1;
$part = $3;
die Cannot figure out device and partition from $devname.\n
unless $dev ne $part ne ;
$size /= 512;
$offset /= 512;
system(disklabel $dev $tempname)
die Cannot run disklabel(8)\n;
%parts = ();
$blurb = ;
open(L, $tempname) || die Cannot read temp file $tempname\n;
while (L) {
if (/^\s+([a-h]):/) {
chomp;
$parts{$1} = $_;
} else {
$blurb .= $_;
}
}
close(L);
unlink $tempname;
die Vinum partition ${part} not found on ${dev}\n
unless defined($parts{$part});
$parts{$part} =~ /:\s+(\d+)\s+(\d+)\s+(\S+)/;
$vinsize = $1;
$vinoff
I want a sysctl kern.allow_shooting_into_my_foot!
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. Of course, i could now camcontrol format it, but i really wish there was a method to get this Windowis^H^H^H^H^H^Hannoying behaviour turned off for a while. I /am/ the sysadmin here, i want to get control over my devices, and i don't want someone to tell me what i am allowed to do with them. I want to shoot into my foot, d*mnit. At least, there should be an environment variable that turns all these nitpicky checks off. (My uneducated guess is it's GEOM firing at me here, is it?) -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) 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!
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. However, my really concern is what i wrote in the subject: i do want something like an option -f for all of this. I'd like to say: hey, i am the admin here. I don't care whether there's anything still active on this disk. If it is, it is OK for me if the kernel panicked if there was something actually still going on. We have umount -f, it was a long way to it. Now i also want disklabel -f, dd -f, and so on. I don't want this to be the default. Of course. 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. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) 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!
As [EMAIL PROTECTED] wrote: My guess is that vinum scanned the disks when starting, but found nothing on it. And forgot to close them again ? At least from a cursory review of the code, no. It closes them again unless a valid vinum configuration has been found. OK, i'll look once again. 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. It wouldn't have paniced it at all, since i /knew/ nothing was open on it. As i wrote, i want to shoot into my foot. There are more ways to do it, like low-level formatting the drive (which is fortunately out of the control of GEOM). ``will not allow you'' -- well, this now sounds like the best reasoning for me to drop GEOM from my kernels, sorry. As long as you can't guarantee GEOM is 100 % bug free, the backdoor is IMHO always required. See the disklabel it would not allow to overwrite me that wasn't even a valid label at all since it was at the beginning of a partition, not of a drive (you never responded to that mail). I tried to say that if you tried da0c it should stop you, not that it should work. It already stopped me when accessing /dev/da0, so why try something more obscure? Sorry, you've lost me. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) 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!
As Matthew N. Dodd wrote: It already stopped me when accessing /dev/da0, so why try something more obscure? Sorry, you've lost me. ftp://ftp.jurai.net/users/winter/patches/geom-foot.patch Oh, nice! Thanks! -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
CPUTYPE cr*p (Was: [kris@FreeBSD.org: 5.0-CURRENT build failure of ports you maintain])
- Forwarded message from Kris Kennaway [EMAIL PROTECTED] - One or more ports that you maintain are currently unbuildable under FreeBSD 5.0-CURRENT/i386 on the FreeBSD package-building cluster. [...] - End forwarded message - ... gmake[2]: Entering directory `/tmp/a/ports/devel/avr-libc/work/avr-libc-2002.10.02/avr3/build/crt1' avr-gcc -I../../../include -I../../../common-O -pipe -mcpu=pentiumpro -mmcu=avr3 -x assembler-with-cpp -Wa,-gstabs -mmcu=atmega103 -c ../../../crt1/gcrt1.S -o crtm103.o cc1: error: invalid option `cpu=pentiumpro' I really /hate/ this CPU feature crap. What am i supposed to do in order to get cross-compilation working properly? I've already tried a number of things, and my -current from August at least gave in when setting MACHINE_ARCH=avr for the cross-coimpilation. Previously, i tried to set CPUTYPE=foo. Now, with the latest -current, it seems this doesn't work anymore. Still, i wish no such CPU type flag would auto-inherit, and a simple ./domake MAKE=gmake would be sufficient. Why can't people who want to pessimize for their current CPU just add this to their /etc/make.conf, instead of poisoning an entire operating system by default with it? I doubt the benefit of a CPU-specific compilation will outweigh all the hassles of bsd.cpu.mk in any way. I really doubt. *grumbling yours*, Joerg -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CPUTYPE cr*p (Was: [kris@FreeBSD.org: 5.0-CURRENT build failure of ports you maintain])
As Matthew N. Dodd wrote: I really /hate/ this CPU feature crap. So do I. I've also found that the only way to reliablly disable it is to comment it out from sys.mk. Maybe i should do this using a preconfigure script in my port... :-) -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CPUTYPE cr*p (Was: [kris@FreeBSD.org: 5.0-CURRENT build failure of ports you maintain])
As Kris Kennaway wrote: What am i supposed to do in order to get cross-compilation working properly? NO_CPU_CFLAGS=yes This is documented in make.conf. At least not in my version of make.conf's man page. Just checked, neither in the current version. I (and obviously not only I) wish that'd be the default though. Oh, it would obviate a flaw with the naming choice (the same as with NO_KERNELCLEAN, NO_KERNELDEPEND, NO_MODULES, ...): negative options are evil. You cannot set ?= them in your make.conf, and override the actual value from the command line. But some people seem to be proud about all this these days. I still don't buy bsd.cpu.mk is worth all these hassles. If the compiler should now default to say pentium code, why not change the compiler's default but invent such a complicated structure, and leave it to the people who want to pessimize their own code by adding it manually to CFLAGS in make.conf? Guess time to look for a cleaner OS. How's jkhBSD going now? :-) -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: acpi prevents fdc to detect correctly
As Simon 'corecode' Schubert wrote: my kernel can't detect fdc anymore when loading acpi. does anybody else have such issues? Hmm, not here. However, my fdc driver is modloaded, too (from the bootloader). I just tried to unload it, then load acpi (which yields module_register_init: MOD_LOAD (nexus/acpi, 0xc02109c0, 0xc3a83824) error 1 but the module appears in kldstat anyway), and then fdc, but that works. Unfortunately, my scratch machine which is available for testing doesn't speak ACPI at all. i know that it worked with a Aug 6 or a Aug 3 kernel, this was the last time i accessed my fd0. I haven't been changing much in the fdc(4) code lately. However, the driver gets its resource allocations from elsewhere, and if ACPI is present, wasn't it responsible for assigning resources? I don't know enough about ACPI, sorry. fdc0: output ready timeout fdc0: cmd 3 failed at out byte 1 of 3 fdc0: output ready timeout fdc0: cmd 3 failed at out byte 1 of 3 All this smells a bit similar to the behaviour of the problem in kern/21397, although it happens on those Compaqs even without ACPI. What's mysterious there is that the boot-time probe works but any later access fails with an FDC that's no longer responding at all to ISA bus selections (pattern 0xff on the bus). fdc0: cannot reserve I/O port range (6 ports) fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 Hmm. This means that the resources are told to be unavailable by whoever has to decide about this. If i read this right, with the acpi module loaded, resource allocation is perhaps handled by ACPI, while otherwise it's handled by the PnP BIOS? -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: fd0 sometime not configured....
[EMAIL PROTECTED] (Jan Stocker) wrote: I cant mount my floppy from time to time. twoflower# mount -t msdosfs /dev/fd0 /home/jstocker/floppy/ msdosfs: /dev/fd0: Device not configured ENXIO is something of a `catch-all' error code in the kernel. It could mean that there's no such driver in the kernel (which is apparently not the problem in your case), but it could happen for quite many other problems, like a missing medium etc. The Unix fathers didn't waste too many error codes, did they? :-) Are there any kernel error messages logged? Ah, i see that msdosfs is complaining (not the fdc(4) driver), so this will even extend the possible range of problems to those where the FAT filesystem structure doesn't match msdosfs' expectations. So it would at least be worth giving mtools a try as well to read that floppy. Failing all this, make sure that you can access the medium at all (my usual test is to run hd on it). -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: what does it take to rsh as root now days?
David O'Brien [EMAIL PROTECTED] wrote: I can rlogin to a -CURRENT box as root. However `rsh box id' comes back with: Jul 3 00:11:33 box rshd[4916]: root@dragon as rootk: permission denied (authentication error). cmd='id' man pam_rhosts should explain that. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Please install and test the GDB 5.2 port
As Mark Peek wrote: Can you verify that there are patches in the devel/gdb52/files? # ls /usr/ports/devel/gdb52/files CVS patch-gdb_kvm-fbsd.c patch-gdb_config_alpha_fbsd.mh patch-gdb_symfile.c patch-gdb_config_i386_fbsd.mh patch-gdb_target.c patch-gdb_config_i386_nm-fbsd.h patch-gdb_target.h patch-gdb_config_i386_tm-fbsd.h patch-gdb_version.in patch-gdb_freebsd-uthread.c Nice tip, thanks. :-) I forgot to use -Pd when cvs updating that port. Did the make create this file? # ls -l /usr/ports/devel/gdb52/work/gdb-5.2/gdb/kvm-fbsd.c -rw-r--r-- 1 root wheel 26480 Jun 27 06:48 /usr/ports/devel/gdb52/work/gdb-5.2/gdb/kvm-fbsd.c Now yes. ;-) Check sysctl -a kern.osreldate and see if your system is = 500032. Hmm, that's the problem. My version is a bit dated already... OK, thanks for the insight! -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Please install and test the GDB 5.2 port
David O'Brien [EMAIL PROTECTED] wrote: Mark Peek and DFR have made patches against GDB 5.2 such that it should do everything we need it to. It would be most helpful for people to test this before it goes into /usr/src. j@uriah 133% gdb52 kernel.debug /cdrom/vmcore.1 GNU gdb 5.2 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-portbld-freebsd5.0... /cdrom/vmcore.1 is not a core dump: File format not recognized (gdb) quit j@uriah 134% gdb52 -k kernel.debug /cdrom/vmcore.1 gdb52: unrecognized option `-k' Use `gdb52 --help' for a complete list of options. Hmm, so how to debug a kernel coredump? -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Please install and test the GDB 5.2 port
As Mark Peek wrote: Hmm, so how to debug a kernel coredump? You need to update your gdb52 port. I can't find a newer one in CVS: j@uriah 85% pkg_info -I gdb-\* gdb-5.2_2 GNU GDB 5.2 developmental snapshot -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Perl script rewrites - progress (2)
Ruslan Ermilov [EMAIL PROTECTED] wrote: I'm in the middle of rewriting release/scripts/*.pl scripts. Is this even necessary? A make release has so many prerequisites (among them, a locally available CVS tree) that Perl as a prerequisite would do no harm. Even more, a normal make release (without any NO_THIS and NO_THAT hacks) would even install half of the ports world plus their respective distfiles into the chroot tree... -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Vinum problem
yuri khotyaintsev [EMAIL PROTECTED] wrote: so now I have usr.p0 - 1 subdisk (usr.p0.s0) usr.p1 - 0 subdisk I have no possibility to get new large disk now. Should I try to remove plex usr.p1 ? Yes, I think so. Perhaps you need to detach it before (most likely). -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: disklabel(8) floppy panic
As Bruce Evans wrote: On Wed, 3 Apr 2002, I wrote: ... This seems to be a bug in the fd driver. ls -F works the first time exist. fd0a and fd0c may need to exist for compatibility, but shouldn't. fd0b and fd0[d-h] just shouldn't exist. Bruce As Bruce Evans wrote: This seems to be a bug in the fd driver. ls -F works the first time on nonexistent partitions. But it should only work on devices that oops:^ on devices that go through the disk layer exist. I have not much clues about how make_dev_alias(9) and NAMI lookups are stacked here. I've simply taken phk's code (for the aliases, it should be functionally identical to phk's version, i only had to rewrite the non-alias device creation). fd0a and fd0c may need to exist for compatibility, but shouldn't. fd0b and fd0[d-h] just shouldn't exist. Hmm, they all used to be in /dev/MAKEDEV. IMHO, all of them can go away, but i didn't want to force too much of my opinion onto others here. :) -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: disklabel(8) floppy panic
Brandon S. Allbery KF8NH [EMAIL PROTECTED] wrote: lrwxr-xr-x 1 root wheel4 Apr 2 20:34 /dev/fd1c@ - fd0 Uh? Interesting that you spooted /that/. :-) OK, gonna fix it... -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: login looping
Peter Jeremy [EMAIL PROTECTED] wrote: I've just finished updating a system to -CURRENT from mid-April (just before the DP1 branch). When I try to login, login(8) goes into a loop. I've seen this occasionally for accounts that have either S/Key or opie (forgot which one it was) enabled. Killing the login process, and trying a new login mysteriously worked then. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: disklabel(8) floppy panic
As Bruce Evans wrote: BTW, device cloning seems to work wrong for fd: %%% Script started on Wed Apr 3 02:16:43 2002 ttyp1:bde@besplex:/tmp ls /dev/fd0c ls: /dev/fd0c: No such file or directory ttyp1:bde@besplex:/tmp ls /dev/fd0c /dev/fd0c@ ttyp1:bde@besplex:/tmp exit I can also see this. IMHO, that's an artifact of how device on-demand alias creation is working. Cc to Poul-Henning, maybe he can shed some light on this. Ah, hmm, i think that's a problem of ls -F, actually. Look here. j@uriah 90% ls -l /dev/fd1* crw-r- 1 root operator9, 64 Apr 1 22:37 /dev/fd1 j@uriah 91% /bin/ls /dev/fd1c /dev/fd1c j@uriah 92% ls -l /dev/fd1* crw-r- 1 root operator9, 64 Apr 1 22:37 /dev/fd1 lrwxr-xr-x 1 root wheel4 Apr 2 20:34 /dev/fd1c@ - fd0 Plain /bin/ls (without any options) works as expected. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: disklabel(8) floppy panic
Crist J. Clark [EMAIL PROTECTED] wrote: Have a crash box handy? $ disklabel fd0.1440 The patch below should fix that, thanks for the bug report. fdioctl() historically attempted to determine the raw partition (`c') of the device in order to read the label. However, the floppy driver never really supported UFS-style partitions anyway. This ended up in selecting the wrong device for reading the label, which was a not-so-fatal error before the last floppy driver rewrite (it actually selected the fdX.1480 device then, which was obviously benign for 3.5 drives). However, now it hits an unitialized device which becomes fatal in readdisklabel() by attempting an indirect call to the strategy routine that hasn't been entered in the struct dev passed down. The call to dkmodpart() entered in rev. 1.64 of fd.c, so i'm Cc'ing Bruce for a comment whether the fix below is indeed TRT. Index: sys/isa/fd.c === RCS file: /home/ncvs/src/sys/isa/fd.c,v retrieving revision 1.224 diff -u -r1.224 fd.c --- isa/fd.c18 Dec 2001 22:16:33 - 1.224 +++ isa/fd.c1 Apr 2002 20:56:22 - @@ -2704,7 +2704,7 @@ fdt = fd-ft; lp-d_secpercyl = fdt-size / fdt-tracks; lp-d_type = DTYPE_FLOPPY; - if (readdisklabel(dkmodpart(dev, RAW_PART), lp) != NULL) + if (readdisklabel(dev, lp) != NULL) error = EINVAL; else *(struct disklabel *)addr = *lp; -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: web Browsers (Re: gcc -O broken in CURRENT)
David O'Brien [EMAIL PROTECTED] wrote: Slow. Eats memory. Crashes all the time. Does not save state between sessions. Does not render HTML 4 properly. Does not support CSS properly. Does not zoom. Does not display PNG properly. Incorrectly ignores cache-control headers on images. The list goes What brower available on FreeBSD does do all these things? Galeon. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Serial break into debugger broken from 'cu' on -CURRENT?
Bruce Evans [EMAIL PROTECTED] wrote: The -current cu is a crock of tip. It has more missing features, compared to the Taylor version, like the unability to run an external program with stdin and stdout piped to the remote end simultaneously (like a local sz Z-modem program), plus it has this annoying startup message can't open log file /var/log/aculog (why should it be able to open it at all?). I wish the Taylor version hadn't been thrown overboard at all. We used to have two alternatives, cu and tip. Now we only have tip and tip. :( (I doubt tip has actually less security bugs than Taylor cu. If we threw out all the BSD-originating programs that once experienced a security problem, we would rather quickly end up with a skeleton that could hardly be named `Unix' anymore...) This is bug for bug compatible with the V7 cu except for the unusably slow speed of 9600. For perfect brokenness, the default speed should be 300. *ROTFL* -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD unfinished NIS+ implementation in Linux ?
Martin Blapp [EMAIL PROTECTED] wrote: Suse's Copyright: /* Copyright (c) 1999 Thorsten Kukuk Author: Thorsten Kukuk [EMAIL PROTECTED] That would at least be a copyright violation. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Don't remove sc.0 from hints...
Riccardo Torrini [EMAIL PROTECTED] wrote: May be. Or not. Even with _all_ this lines commented I get the floppy controller detected (but no floppy drive). That's strange, because on IA32 architectures, the first two drives are supposed to be configured from what is recorded in the CMOS configuration memory, not from the device hints. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Current Etherboot
Robert Watson [EMAIL PROTECTED] wrote: Most people I know of that netboot boxes on Intel platforms now use PXE. But well, there are only two NICs that support PXE, aren't there? In particular, there's nothing cheap (i. e. = USD 10) you could use in conjunction with an old junk ISA NIC people often have in their bit-bucket (i. e. with an NE2k clone or 3C509). -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: boot floppy problems...
Mike Brancato [EMAIL PROTECTED] wrote: oh, well. They say something along the lines of Disk error: lba is 0x9 (should be 0x10) or similar. then it trys to boot the kernel twice using the loader, but fails with the path 0:fd(0,a)/kernel I have to confirm this, for a self-made make release of yesterday. Using the primary bootstrap of the harddisk, and loading fd(0,a)/boot/loader gets it running, so /boot/loader itself is OK. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: size of /usr/src
Bakul Shah [EMAIL PROTECTED] wrote: On a -CURRENT: $ du -s /usr/src 389637/usr/src FFS likes to have about 10% free space + add a few more (may be 4%) for the inodes space. So you need a partition of at least 450MB. j@uriah 57% df -k /usr/src Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/vinum/src 595455 434778 11304179%/usr/src That is -current as of around christmas. There's a stale /sys/i386/compile directory in it, but that doesn't contribute much to the above since there are no .o files in it. The file system is a 1 KB fsize/8 KB bsize one; if you use larger block sizes, waste of space might be more. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: size of /usr/src
[EMAIL PROTECTED] (Joerg Wunsch) wrote: j@uriah 57% df -k /usr/src Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/vinum/src 595455 434778 11304179%/usr/src That is -current as of around christmas. Bakul got back to me and questioned that number -- he was right. :) The above filesystem doesn't only contain a checked out copy of the src/ stuff but also of doc/, which adds another 60+ MB to it. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] if_ar and if_sr compile problem
Maksim Yevmenkin [EMAIL PROTECTED] wrote: it looks like if_ar and if_sr modules will not compile unless you have enabled NETGRAPH. patches are simple and attached. Sorry for the breakage, yes. #include sys/syslog.h #include dev/ar/if_ar.h #else /* NETGRAPH */ +#include netinet/in.h +#include netinet/in_systm.h +#include netinet/ip.h +#include net/slcompress.h I'll probably solve it differently so no low-level driver needs to include all those header files. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Recent fdc(4) commit broke Alpha kernels
Ruslan Ermilov [EMAIL PROTECTED] wrote: Oops sorry, that was Joerg. It's fixed now, although i'm still not convinces that using __i386__ is the right thing. If our machine/param.h defines several constants for _MACHINE_ARCH, they should all be distint for the various machines. As it seems now, all of them probably define the same or whatever, so we end up in _MACHINE_ARCH@i386 == _MACHINE_ARCH@alpha == _MACHINE_ARCH@IA64 etc. We could as well delete those lines from machine/param.h then since they are pretty useless in that case. And no, MACHINE_ARCH (without the leading underscore) cannot be used either since it defines a string constant that can't be used in a cpp conditional. Cc goes to [EMAIL PROTECTED]: what is the politically correct way to distinguish a PC-type architecture (in that case one that uses a PC-style RTC memory to store configuration information) from another architecture that uses IA32 CPUs (like PC98, although they aren't using /sys/isa/fd.c right now)? -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: How to get OPIE to work??
David O'Brien [EMAIL PROTECTED] wrote: Anyone know how to get this on -CURRENT now days? No problem for me. .. enable it in /etc/pam.conf: login authsufficient pam_opie.so no_warn .. initialize the key with opiepasswd .. use telnet -K to prevent automatic (SRA) login (Well, my system is probably one month old. If something has been broken afterwards, forget the above.) -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HEADS UP: floppy driver enhancements
Well, everybody can read the commit message, it basically contains all that is to say. I've offered the patch for review quite some time ago, but nobody seemed to be interested (or at least nobody had some feedback to me). So i've been running the patched system here for too long now, it's time to get it to a wider audience. Let me quote the BUGS and TODOs seection from the commit message again, and comment each of it. . All documentation update still needs to be done. This means all manpage updates are still not done. Will do this anytime soon, probably during the upcoming holiday season. For the time being, for people who need to configure a device using a non-standard density, here's a short guide on how to do it: There are now basically two options how to specify a floppy density to either fdcontrol or fdformat. The simplified method simply uses -f fmt, where fmt is the number of kilobytes the desired density should have. All the table entries that previously used to live in the kernel driver have now been imported to fdcontrol, so you can specify them in that simplified form. So if you've been using 1720 KB floppies, you can create a device entry for them (e. g. in /etc/rc.local) using: fdcontrol -f 1722 /dev/fd0.1720 (As you can see, fdcontrol cares about the exact number of kilobytes, since that's what can be derived from the configuration table.) The verbose form specifies each density detail of the mode explicitly, using -s fmtstr. fmtstr describes each of the fields in struct fd_type (see sys/fdcio.h) except size (this one is instead derived from the other values), and with flags being specified as a sequence of +flag or -flag at the end of the string. The current fmtstr can be queried using fdcontrol -F. . Formatting not-so-standard formats yields unpredictable results; i have yet to figure out why this happens. Standard formats like 720 and 1440 KB do work, however. I currently have no idea why that happens. It seems some error handling in fdformat is wrong, so each time an error occurs, it starts to overwrite wrong tracks. Under normal circumstances, this doesn't matter since you throw away bad floppies anyway... I don't know why it's in particular impossible to format an FM floppy, it only records garbage ID fields on the tracks. I've debugged it down to the point where i'm convinced the isa_dma_foo() functions are being passed the correct values for the DMA transfers to the FDC. . rc scripts are needed to setup device nodes with nonstandard densities (like the old /dev/fdN.MMM we used to have). The idea here is to provide some rc script that creates the drives we used to have in the past. Some support has already been added to fdcontrol to aid in this: just calling fdcontrol on a floppy disk device returns a text string describing the drive type (1.2M or 1.44M, basically). This can be used inside the rc script to know which densities to configure for that particular drive. . Obtaining device flags from the kernel environment doesn't work yet, thus currently only drives that are present in (IA32) CMOS are really detected. Someone who knows the odds and ends about device flags is needed here, i can't figure out what i'm doing wrong. This is the biggest problem so far. In particular, i'm sure the driver won't recognize any floppy device on tha Alpha architecture until this has been resolved. :-( The idea is that you have something like hint.fd.0.flags=0x4 to specify a 1.44 MB floppy. The value itself (actually, the lower 4 bits of the flags) specify drive types as they are usually stored in the CMOS memory on IA32, but shifted right by 4 bits (CMOS stores drive 0 in the upper and drive 1 in the lower bits, so the #defines in /sys/isa/rtc.h specify the values for drive 0). I /really/ need someone who understands device hints enough to tell me what i'm doing wrong here. All my attempts to figure it out myself were in vain. . 2.88 MB still needs to be done. OK, i've got a drive now, but still didn't get it to work. I didn't want to defer this patch set any longer for this, however. We've been living without 2.88 support for too many years already anyway, now up to the point where they are already basically no longer used. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [SUGGESTION] - JFS for FreeBSD
Hiten Pandya [EMAIL PROTECTED] wrote: i wanted to ask if there were any _plans_ to port JFS (Journaled File System) to FreeBSD... As long as nobody gets the idea to import VxFS... It's dog slow compared to UFS+softupdates. :-) Dog slow even compared to Solaris 8 UFS+logging. Of course, i know it has other advantages, but the journalling feature doesn't seem to be the best. Even my notebook with its slooow (low-power) IDE drive is faster than Solaris 8 fibre-channel disks running with VxFS. ;-) (faster means in terms of filesystem metadata operation, like file creations and deletions, since that's the area you normally want to employ journalling or softupdates for.) -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
As Peter Wemm wrote: No, it isn't ignored, BIOS'es know that fdisk partitions end on cylinder boundaries, and therefore can intuit what the expected geometry is for the disk in question. And you call that a design? I call it a poor hack, nothing else. The restriction to whatever the BIOS believes to be a cylinder boundary is one of my gripes with fdisk tables; you obviously missed that (or you don't argue about it -- can i take this as silent agreement?). It imposes a geometry that is not even remotely there, with the drawbacks that a number of sectors can never be assigned (OK, no big deal these days), but even worse, disks are non-portable between different BIOSes that perform different intuition about how to obtain the geometry from those poorly chosen values that are included in fdisk tables. /The/ major advantage of DD mode was that all BIOSes (so far :) at least agree on how to access block 0 and the adjacent blocks, so starting our own system there makes those disks portable. [...] The problem is that the int13 code only allowed for 255 heads, and the fake end of disk entry that is unconditionally in /boot/boot1 specified an ending head number 255 (ie: 256 heads). When this gets put into a byte register it is truncated to zero and we get divide by zero errors. I've read this, and yes, i never argued about fixing /that/. Since those values chosen by our grandfather Bill Jolitz have been just `magic' numbers only, it's unfortunate they eventually turned out to be such bad magic about a decade later. We can just as easily have bootable-DD mode with a real MBR and have freebsd start on sector #2 instead of overlapping boot1 and mbr. Probably, i think i could live with that. I'd rather that we be specific about this. If somebody wants ad2e or da2e then they should not be using *any* fdisk tables at all. Ie: block 0 should be empty. That disk wouldn't boot at all, you know that. Yes, i prefer my disks to be called da0a...daNP. But to be honest, see my other article: i never argued to make this the default or a recommended strategy in any form. It should only remain intact at all. Back to the subject, the current warning however, is pointless, and has the major drawback to potentially hide important console messages. The console buffer is 32K these days. You'd have to have around 300 disks to have any real effect on the kernel. You're narrow minded here, Peter, this time about in the same way as Windoze is narrow minded: All the world's a graphical console produced by XXX. No, all the world's not like that. You might consider my pcvt console obsolete, OK, but did you ever think about a plain VT220 on a serial console? They don't have /any/ scrollback buffer. (And you can't even stop the output with ^S while FreeBSD is booting.) Also, i think that: uriah /boot/kernel/kernel: da0: invalid primary partition table: Dangerously Dedicated (ignored) uriah last message repeated 5 times uriah /boot/kernel/kernel: da1: invalid primary partition table: Dangerously Dedicated (ignored) uriah last message repeated 34 times uriah /boot/kernel/kernel: da2: invalid primary partition table: Dangerously Dedicated (ignored) uriah last message repeated 34 times ...73 of those silly messages are just beyond any form of usefulness. Either we hide this completely behind bootverbose (back to the root of this thread) since it bears no information at all (i already knew what is written there, since it was my deliberate decision, and it could not have happened unless being my deliberate decision), or we at least ensure any of those messages is emitted at most once per drive. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
As Peter Wemm wrote: Can you please clarify for me what specifically you do not like.. Is it: - the cost of 32K of disk space on an average disk these days? (and if so, is reducing that to one sector instead of 62 sufficient?) The idea of a geometry that does not even remotely resembles the actual geometry and only causes additional hassles, like disks being not portable between controllers that have a different idea of that geometry (since the design of this table is missing an actual field to specify the geometry). Incidentally, it's only what you call intuition that finally stumpled across the 10-years old Jolitz fake fdisk values. So IOW, it took the BIOS vendors ten years to produce a BIOS that would break on it :), and the breakage (division by 0) was only since they needed black magic in order to infer a geometry value that was short-sightedly never specified in the table itself. - you don't like typing s1 in the device name? Aesthetically, yes, this one too. :) disklabel -rw ad2 auto is one form. That should not use fdisk at all. This is quite fine, and nobody wants that to go away. Good to hear. Well, actually i always use disklabel -Brw daN auto, partly because this sequence is wired into my fingers, and since i mentally DAbelieve that having more bootstrappable disks couldn't harm. ;-) As laid out in another message, i eventually got the habit of even including a root partition mirror on each disk as well. So each of my disks should be able to boot a single-user FreeBSD. I advocate that the bootable form (where boot1.s is expected to do the job of both the mbr *and* the partition boot) is evil and should at the very least be fixed. Fixing is OK to me. I think to recognize the dummy fdisk table of DD mode, it would be totally sufficient to verify slice 4 being labelled with 5 blocks, and the other slices being labelled 0. We do not support any physical disk anymore that is only 25 MB in size :). So all the remaining (INT 0x13 bootstrap) values could be anything -- even something that most BIOSes would recognize as a valid fdisk table. It should be something that is explicitly activated, and not something that you get whether you want it or not. I don't fully understand that. DD mode has always been an explicit decision. Even in the above, the specification of -B explicitly tells to install that bootstrap. As David O'Brien wrote: Its design is antique. Or rather: it's missing a design. Jorg, why not just buy an Alpha or Sun Blade and run FreeBSD on it?? I don't see much value in an Alpha. Maybe a Sun some day, who knows? As i understand it now, the UltraSparc port is not quite at that stage, but i'm willing to experiment with it when i find a bit of time and documentation how to get started. I've got access to a good number of Suns here at work, and i think there are even a number of colleagues who would prefer FreeBSD over Solaris on them. If FreeBSD would had been ready for it, i could have tested it on the new V880 machine that was just announced recently. :) (We were the first one worldwide to show it on a fair trade here, about 24 hours after the official announcment...) -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
As Terry Lambert wrote: Joerg Wunsch wrote: /The/ major advantage of DD mode was that all BIOSes (so far :) at least agree on how to access block 0 and the adjacent blocks, so starting our own system there makes those disks portable. I guarantee you that there are a number of controllers which have different ideas of how to do soft sector sparing _at the controller level_ rather than at the drive level. We have dropped support for ESDI controllers long since. :-) Seriously, all the disks we are supporting these days do bad block replacement at the drive level. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
As Peter Wemm wrote: Yes, that is much safer, however there are certain bioses that have interesting quirks that the MBR has to work around. The problem when overlapping mbr and boot1 into the same block is that we no longer have the space to do that. boot1.s has got *3* bytes free. Too bad. Peter, do you care to update the section about DD mode (and its dangers) in the FAQ after all this discussion? I could probably do it, too (the original entry is mine), but i had to quote your arguments only anyway. Also (and I think this is more likely to be the problem you ran into) many newer PC's are looking at the partition tables for a suspend-to-disk partition or a FAT filesystem with a suspend-to-disk dump file. Seems i really love my Toshiba (Libretto) that simply hibernates to the last nnn MB of the physical disk. ;-) (I have reserved a FreeBSD partition as a placeholder for the hibernation data.) However, there is light at the end of the tunnel. EFI GPT is pretty clean. Good to hear. While this sounds like dedicated disks will be gone then :), at least the format looks rationale enough. It supports up to something like 16384 partitions ... It would be interesting to see how Windoze will arrange for 16K drive letters. :-)) The day vinum is up and ready to also cover the root FS, i won't need /any/ partition at all anymore. ;-) As Greg Lehey wrote: ...73 of those silly messages are just beyond any form of usefulness. Hadn't we agreed to do this? I'm certainly in favour of the bootverbose approach. I can't remember any agreement so far. But thinking a bit more about it, it sounds like the best solution to me, too. The only other useful option would be to restrict the message to once per drive, but that'll cost an additional per-drive flag, which is probably too much effort just for that message. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
As Peter Wemm wrote: There shouldn't *be* bootblocks on non-boot disks. dd if=/dev/zero of=/dev/da$n count=1 Dont use disklabel -B -rw da$n auto. Use disklabel -rw da$n auto. All my disks have bootblocks and (spare) boot partitions. All the bootblocks are DD mode. I don't see any point in using obsolete fdisk tables. (There's IMHO only one purpose obsolete fdisk tables are good for, co-operation with other operating systems in the same machine. None of my machines uses anything else than FreeBSD.) -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
As Daniel O'Connor wrote: I don't understand the need some people have for using something that is labelled as DANGEROUS. Historically, it hasn't been labelled that, it only later became common terminology for it -- in the typical half-joking manner. No, it won't hurt your cats but you may lose hair from using it, and for what benefit? NONE! See my other reply about fdisk tables: they are a misdesign from the beginning. The single most wanted feature it buys you is the ability to completely forget the term `geometry' with your disks: the very first sectors of a disk always have the same BIOS int 0x13 representation, regardless of what your BIOS/controller thinks the `geometry' might be. Thus, those disks are basically portable between controller BIOSes. (Modulo those newer broken BIOSes that believe eggs must be smarter than hens -- see my other article for an opinion.) -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
As [EMAIL PROTECTED] wrote: There are very good reasons NOT to use DD mode if you use certain types of Adaptec SCSI controllers - they simply won't boot from DD. Never seen. All my SCSI controllers so far booted from my disks (obviously :). I figure from Peter's comment in that piece of code that the original (386BSD 0.0 inherited) DD mode fake fdisk table apparently had some poor (faked) values inside that could upset some BIOSes. That's bad, and IMHO we should fix what could be fixed, but without dropping that feature entirely (see below). personal opinion Still, it's my opinion that these BIOSes are simply broken: interpretation of the fdisk table has always been in the realm of the boot block itself. The BIOS should decide whether a disk is bootable or not by looking at the 0x55aa signature at the end, nothing else. Think of the old OnTrack Disk Manager that extended the fdisk table to 16 slots -- nothing the BIOS could ever even handle. It was in the realm of the boot block to interpret it. /personal opinion Aside from that, FreeBSD needs to have *one* recommendation for disks, anything else creates too much confusion. DD mode has never been a recommendation. It is for those who know what it means. I'm only against the idea to silently drop support for it... fdisk tables are something that has been designed in the previous millenium, and i think nobody is going to argue about it that they are rather a mis-design from the beginning (or even no design at all, but an ad-hoc implementation). Two different values for the same (which could become conflicting, thus making disks unportable between different controllers), not enough value space to even remotely cover the disks of our millenium, enforcement of something they call `geometry' which isn't even remotely related to the disks' geometry anymore at all, far too few possible entries anyway, ... FreeBSD is in a position where it doesn't strictly require the existence of such an obsoleted implementation detail, so we should users leave the freedom of decision. Again, it has never been the recommendation (well, at least not after 386BSD 0.0 :), and i normally wouldn't recommend it to the innocent user. But we should not break it either. (The other day a coworker of mine wanted to use DD for some IBM DTLA disks, because he'd heard that the disks performed better that way - something to do with scatter-gather not working right unless you used DD. [...]) As much as i personally prefer DD mode: that's an urban legend. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
Mike Smith [EMAIL PROTECTED] wrote: - The MBR partition table is not obsolete, it's a part of the PC architecture specification. Its design is antique. Or rather: it's missing a design. See other mail for the reasons. For FreeBSD, it's obsolete since we don't need to rely on fdisk slices. (Or rather: it's optional. We can make good use of it when it's there, but we don't need to insist on it being there.) You do realise that DD mode does include a (invalid) MBR partition table (now valid, courtesy of a long-needed fix), right? Yes, of course, one that is basically ignored by everything. It has always been there, back since 386BSD 0.1. 386BSD 0.0 didn't recognize fdisk tables at all, but could only live on a disk by its own (as any other BSD before used to). I'd love to never hear those invalid, unuseful, misleading opinions from you again. ETOOMANYATTRIBUTES? :-) As long as you keep the feature of DD mode intact, i won't argue. If people feel like creating disks that aren't portable to another controller, they should do. I don't like this idea. But to be honest, see my other article: i never argued to make this the default or a recommended strategy in any form. It should only remain intact at all. Back to the subject, the current warning however, is pointless, and has the major drawback to potentially hide important console messages. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rev 1.61 of /sys/netinet/in.c breaks ISDN
As Ruslan Ermilov wrote: You need to configure /some/ interface address for the remote end anyway, and it must not clash with any other routing table entry, since ifconfig ... up always adds an entry for the remote IP address for p2p interfaces. Only if you have INET address configured on an interface. That's the purpose of an sppp interface. You can't do anything with it unless an INET address has been configured to it. (In the case of an automatic dialer -- which is what many ISDN users are using -- you need the IP traffic generated by normal routing in order to trigger the ISDN dialout.) Why not just bring the interface up first, then negotiate an address, then add it to interface? Because it'll become a chicken-and-egg problem: the interface would never start negotiating PPP in that case. There are other PPP implementations available for people who want a full-blown one; sppp is meant to be the simplest (and smallest) PPP implementation that is useful for synchronous data carriers. [Please DO NOT exclude my personal address when replying -- I didn't ask for it (as many do) through the Mail-Followup-To: header.] You got it. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
Bernd Walter [EMAIL PROTECTED] wrote: 32 times for each disk on booting with most of 30 disks. Possibly it's triggered by vinums drive scanning. Yep, same here (and it is triggered by vinum). What can I do about these messages? Remove it. It should not have been there in the first place, at least not without an if (bootverbose) ... in front of it. It isn't telling any news anyway, because you certainly already knew that your disks are using DD mode, and the last word is telling (ignored) which is the intented and expected action to happen anyway. I do understand Peters gripe about broken BIOSes that try to interpret fdisk tables (where the fdisk table is actually in the domain of the boot block itself). The comments tell a bit more about it. But adding pointless messages that flush the boot log and possibly hide important boot messages can't be goo. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rev 1.61 of /sys/netinet/in.c breaks ISDN
As Ruslan Ermilov wrote: phk has chosen 0.0.0.1 since it obviously cannot be a meaningful statically configured address. OK, but is it really necessary? It's much simpler to add routes over P2P interfaces using the interface name ... You need to configure /some/ interface address for the remote end anyway, and it must not clash with any other routing table entry, since ifconfig ... up always adds an entry for the remote IP address for p2p interfaces. (Actually, it even tries to enter it twice, so you get a meaningless Address already exists. message when bringing a p2p interface up with ifconfig.) The politically correct solution to negotiate the remote PPP address would have been to change the routing table entry after negotiating the address, of course. However, this seemed to be too much hassle for the smallsimple intent of sppp(4), in particular considering that the only added value compared to the 0.0.0.1 hack would be that you can reach the IP address of your peer directly. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rev 1.61 of /sys/netinet/in.c breaks ISDN
Ruslan Ermilov [EMAIL PROTECTED] wrote: ISTR that I4B uses some special magical destination address for some purpose (0.0.0.0 or something). The magical destination address is 0.0.0.1. It is used as a `placeholder' address for the remote side, so you can add a route to it. Should probably be extended to 0.0.0.*, so you can add more than one interface that way. (The actual PPP negotiation for the remote side is simply told to acceppt any suggested address, but this address is then ignored, and the local end still uses 0.0.0.1 for routing purposes. This is a big hack, but the only feature you lose is to directly access your remote router. Any other packets have a destination address different from the remote router anyway.) phk has chosen 0.0.0.1 since it obviously cannot be a meaningful statically configured address. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Non-network Fatal Trap 12
Galen Sampson [EMAIL PROTECTED] wrote: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x1 fault code= supervisor read, page not present instruction pointer = 0x8:0xc02b5baf stack pointer = 0x10:0xcadc3d48 frame pointer = 0x10:0xbfbfadb4 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def 321, gran 1 current proccess = 56 (sysctl) trap number = 12 Well, if it's sysctl, perhaps you get closer to the reason by analyzing which sysctl this might be? Also, my guess is that you should at least be able to boot single-user (since IMHO no sysctl is issued before starting the single-user shell). This might then help you to isolate the problem and/or edit some startup script to work around it. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: df -l broken
As Maxime Henrion wrote: Seems to work. mount(8) has still the problem though: Great, I'll file a PR for it. Thanks for the feedback ! I can commit it if you want. I fail to see why should ``mount -t local'' work. ISTR that it used to work, at least in the context of mount -a -t local. I can't seem to find any old system to verify this claim, however. So maybe it's merely wishful thinking instead of something that has actually once been there... -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: df -l broken
Maxime Henrion [EMAIL PROTECTED] wrote: I looked at the code a bit more closely and you're entirely right. I think I figured out why my patch caused a core dump. Here is a more correct patch that should fix the problem without causing core dumps. Seems to work. mount(8) has still the problem though: uriah # mount -t local uriah # kldload nfs uriah # mount -t local uriah # mount -t nonfs /dev/da0a on / (ufs, local, soft-updates) devfs on /dev (devfs, local) /dev/vinum/var on /var (ufs, local, soft-updates) /dev/vinum/usr on /usr (ufs, local, soft-updates) /dev/vinum/home on /home (ufs, local, soft-updates) /dev/vinum/home_cvs on /home/cvs (ufs, NFS exported, local, soft-updates) /dev/vinum/src on /usr/src (ufs, local, soft-updates) /dev/vinum/othersrc on /usr/othersrc (ufs, local, soft-updates) /dev/vinum/obj on /usr/obj (ufs, local, soft-updates) /dev/vinum/ports on /usr/ports (ufs, local, soft-updates) /dev/vinum/distfiles on /usr/ports/distfiles (ufs, NFS exported, local, soft-updates) /dev/vinum/news on /var/spool/news (ufs, local, soft-updates) /dev/vinum/tmp on /tmp (ufs, NFS exported, local, soft-updates) /dev/vinum/release on /usr/release (ufs, NFS exported, local, soft-updates) /dev/vinum/junk on /junk (ufs, local, soft-updates) procfs on /proc (procfs, local, read-only) -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cdrecord produces broken CDs on -CURRENT
As Christoph Herrmann wrote: Maybe there are other problems. But I had no problems (burning CDs on -CURRENT) until the beginning of october. (I run make world about once a week). And with -STABLE everything is fine until now. It is the same box, I (try to) burn the same image, the only difference is the FreeBSD version. So it can't be only a hardware problem. I just tried it again, since i had to prepare a full FreeBSD 4.4-stable release CD anyway. It works for me. So it must be something that only appears on some hardware. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cdrecord produces broken CDs on -CURRENT
Kenneth D. Merry [EMAIL PROTECTED] wrote: Are there any areas with good data on the CD? i.e. can you see any pattern to the corruption? If you compare the same CD burned from -current and -stable you might begin to see a patern. I tried a test-burn with a FreeBSD-current from yesterday, on a YAMAHA CRW2100S 1.0H writer (writing a CD-RW), and can't see any failure. It's only a small directory tree, but MD5-comparing the tree on the CD-RW with the original on UFS only reveals the added TRANS.TBL files, no other differences. # cdrecord -version Cdrecord 1.9 (i386-unknown-freebsd5.0) Copyright (C) 1995-2000 Jörg Schilling # ls -l `which cdrecord` -r-xr-xr-x 1 root wheel - 163392 Apr 4 2001 /usr/local/bin/cdrecord* # ldd `which cdrecord` /usr/local/bin/cdrecord: libcam.so.2 = /usr/lib/libcam.so.2 (0x2808a000) libc.so.5 = /usr/lib/libc.so.5 (0x2809a000) libsbuf.so.2 = /usr/lib/libsbuf.so.2 (0x2814e000) (I haven't rebuilt the binary after upgrading -current, for months as you can see.) -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel panic
Bob Vaughan [EMAIL PROTECTED] wrote: sources from yesterday evening. rebuild with kernel sources from tonight. same results. vt0: unknown trident VGA, 80 columns, color, 8 screens, unknown keyboard Warning: Driver mistake: repeat make_dev (ttyv0) Does this only happen with a recent -current? I'm a long-time pcvt user, but have never seen the warning (that it used to be). The only test machine here cannot reproduce it either. make_dev(c03404c0,0,0,0,180,c02f9e0d,0,c0398420) at make_dev+0xfb pcvt_attach(c12a7b80,c12a7b80,c12b2000,18,1) at pcvt_attach+0x1fe Quick review shows that pcvt_attach() is the only pcvt function that ever would call make_dev(). It is not supposed to be called twice... Do you incidentally have both gfx console drivers (sc0 and vt0) in your configuration? That would perhaps explain it. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: shell coredumps with missing termcap entries ?
Luigi Rizzo [EMAIL PROTECTED] wrote: I have been experiencing this problem for sometimes on CURRENT-based picobsd images: the shell coredumps if it does not find an entry for its terminal type in /etc/termcap. Seems to be a »feature« of the new libedit. (gdb) run Starting program: /usr/obj/usr/src/bin/sh/sh # set -E Cannot read termcap database; using dumb terminal settings. Program received signal SIGABRT, Aborted. 0x8075380 in kill () (gdb) bt #0 0x8075380 in kill () #1 0x80a0592 in abort () #2 0x805c72d in el_beep () #3 0x805c760 in el_beep () #4 0x805c760 in el_beep () #5 0x805c4bf in el_beep () #6 0x8061558 in el_gets () #7 0x80618fc in el_gets () #8 0x805d0ec in el_beep () #9 0x805ce91 in el_beep () #10 0x805b3c7 in el_init () #11 0x804eeb7 in histedit () at /usr/src/bin/sh/histedit.c:114 #12 0x805304f in optschanged () at /usr/src/bin/sh/options.c:134 #13 0x80534fa in setcmd (argc=2, argv=0x80ec574) at /usr/src/bin/sh/options.c:358 #14 0x804b973 in evalcommand (cmd=0x80ec54c, flags=0, backcmd=0x0) at /usr/src/bin/sh/eval.c:867 #15 0x804a9ec in evaltree (n=0x80ec54c, flags=0) at /usr/src/bin/sh/eval.c:285 #16 0x8051c52 in cmdloop (top=1) at /usr/src/bin/sh/main.c:253 #17 0x8051bbe in main (argc=1, argv=0xbfbffc48) at /usr/src/bin/sh/main.c:202 #18 0x8048135 in _start () (gdb) up 11 #11 0x804eeb7 in histedit () at /usr/src/bin/sh/histedit.c:114 114 el = el_init(arg0, el_in, el_out, el_err); Here's the stack trace obtained when linking against a -g compiled libedit: (gdb) up #1 0x80a0592 in abort () (gdb) #2 0x805c72d in node__try (el=0x80f3000, ptr=0x80ef200, str=0x80c245a A, val=0x80f2098, ntype=-791621424) at /usr/src/lib/libedit/key.c:359 359 EL_ABORT((el-el_errfile, Bad XK_ type %d\n, ntype)); (gdb) #3 0x805c760 in node__try (el=0x80f3000, ptr=0x80ef1e0, str=0x80c2459 [A, val=0x80f2098, ntype=-791621424) at /usr/src/lib/libedit/key.c:366 366 (void) node__try(el, ptr-next, str, val, ntype); (gdb) #4 0x805c760 in node__try (el=0x80f3000, ptr=0x80ef1c0, str=0x80c2458 \e[A, val=0x80f2098, ntype=-791621424) at /usr/src/lib/libedit/key.c:366 366 (void) node__try(el, ptr-next, str, val, ntype); (gdb) #5 0x805c4bf in key_add (el=0x80f3000, key=0x80c2458 \e[A, val=0x80f2098, ntype=-791621424) at /usr/src/lib/libedit/key.c:210 210 (void) node__try(el, el-el_key.map, key, val, ntype); (gdb) #6 0x8061558 in term_reset_arrow (el=0x80f3000) at /usr/src/lib/libedit/term.c:1070 1070key_add(el, strA, arrow[A_K_UP].fun, arrow[A_K_UP].type); (gdb) #7 0x80618fc in term_bind_arrow (el=0x80f3000) at /usr/src/lib/libedit/term.c:1177 1177term_reset_arrow(el); (gdb) #8 0x805d0ec in map_init_vi (el=0x80f3000) at /usr/src/lib/libedit/map.c:1045 1045term_bind_arrow(el); (gdb) #9 0x805ce91 in map_init (el=0x80f3000) at /usr/src/lib/libedit/map.c:933 933 map_init_vi(el); (gdb) #10 0x805b3c7 in el_init (prog=0xbfbffcec /usr/obj/usr/src/bin/sh/sh, fin=0x80e8d40, fout=0x80e8df0, ferr=0x80e8d98) at /usr/src/lib/libedit/el.c:86 86 (void) map_init(el); -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: weird -current gdb/gcc(?) problem
Maksim Yevmenkin [EMAIL PROTECTED] wrote: i have some weird problem. Well, it would have been nice if you had told what you deemed to be the problem. ;-) I can't find any problem at all... Breakpoint 1, main () at prog1.c:8 8 return (foo(1, 2, '3', test)); (gdb) s foo (i=1, s=10244, c=-54 'Ê', str=0x804855b test) at prog1.c:13 If you mean it should look like: foo (i=1, s=2, c=51 '3', str=0x804855b test) at prog1.c:13 here, erm, no. Your breakpoint simply hit before the function stack frame initialization was complete, so gdb displays the wrong values at that point. Just type a single `s', followed by a `where', and you'll see it will eventually get the argument list right then. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: weird -current gdb/gcc(?) problem
As Maksim Yevmenkin wrote: first of all i want to apoligize. i sent the wrong output. yes, it does the right thing if you use -g switch, however it does not work for me if i use -ggdb switch. Indeed, the output generated with -ggdb looks weird. But then, it never occurred to me to use -ggdb at all. Why would one want to do this? If i get around, i'll try it on another OS and/or architecture. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: high-density floppies
Joel Wilsson [EMAIL PROTECTED] wrote: fd0: hard error reading fsbn 0 (ST0 40abnrml ST1 1no_am ST2 0 cyl 0 hd 0 sec 1) So, I thought I'd try using a raw device configured for higher density disks. That wouldn't help you. It's already failing at the very first sector, by not finding any address mark at all. Thus using one of the »over-formatted« (like fd0.1720) devices wouldn't help. The reason I think they might NOT be damaged is that they are all of the same type (different type from the floppies I could read), and they are all double density floppies. Well, if you really mean double density, it wouldn't require a higher density device but a /lower/ density one. The default device is using high density (200 bytes raw medium capacity), while DD media were 100 bytes raw. So you could try using /dev/fd0.720. My question is, how can I do the equivalent of opening, for example, /dev/fd0.1720 (in -stable) under -current? You just open it, and it will magically appear in /dev. :-) [I've got a huge patchset here that will autodetect DD vs. HD floppies, but before i'm going to commit it, i have to upgrade my box first to -current. This will also change the policy regarding additional /dev/fd* devices, and i'll eventually upgrade the man page as well.] -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: old BSD/OS binary coredumps
As Philipp Mergenthaler wrote: I saw something like this some time ago, too. In my case it was because in kern_sysctl:ogetkerninfo(), in case KINFO_BSDI_SYSINFO:, the variable size is not always given a value. Maybe the patch in http://www.FreeBSD.org/cgi/query-pr.cgi?pr=25476 fixes it for you, too? I'll have a look at that. As Peter Wemm wrote: That is certainly odd. Can you put a .tar.gz of whatever is needed to replicate it somewhere? eg: on http://freefall/~joerg/ ? http://people.freebsd.org/~joerg/netscape.bz That's just the binary itself, i verified in a chroot environment that's all you need to reproduce it (here at least). Ignore all the warnings about missing keysyms etc., the don't influence the coredump behaviour. What is the last -current kernel build date that it ran under? My old kernel was from 2001-06-07. Have you removed COMPAT_43 by any chance? No. (I think the kernel cannot even be linked when omitting this, i once tried it.) The only change to the config file was to remove the userconfig stuff now. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: old BSD/OS binary coredumps
As Philipp Mergenthaler wrote:
I saw something like this some time ago, too. In my case it was
because in kern_sysctl:ogetkerninfo(), in case KINFO_BSDI_SYSINFO:,
the variable size is not always given a value. Maybe the patch in
http://www.FreeBSD.org/cgi/query-pr.cgi?pr=25476
fixes it for you, too?
Yep.
(Hm, now I think my patch could need a comment: size will only be
returned if needed==0. There are two ways this can happen:
After taking a look at the BSD/OS source code (which we are now
allowed to do), i decided to slightly modify the patch. Here's the
result for review.
Index: kern_sysctl.c
===
RCS file: /home/ncvs/src/sys/kern/kern_sysctl.c,v
retrieving revision 1.112
diff -u -r1.112 kern_sysctl.c
--- kern_sysctl.c 25 Jul 2001 17:21:15 - 1.112
+++ kern_sysctl.c 30 Aug 2001 20:34:57 -
@@ -1237,6 +1237,7 @@
{
int error, name[6];
size_t size;
+ u_int needed = 0;
switch (uap-op 0xff00) {
@@ -1300,16 +1301,15 @@
* this is pretty crude, but it's just enough for uname()
* from BSDI's 1.x libc to work.
*
-* In particular, it doesn't return the same results when
-* the supplied buffer is too small. BSDI's version apparently
-* will return the amount copied, and set the *size to how
-* much was needed. The emulation framework here isn't capable
-* of that, so we just set both to the amount copied.
-* BSDI's 2.x product apparently fails with ENOMEM in this
-* scenario.
+* *size gives the size of the buffer before the call, and
+* the amount of data copied after a successful call.
+* If successful, the return value is the amount of data
+* available, which can be larger than *size.
+*
+* BSDI's 2.x product apparently fails with ENOMEM if *size
+* is too small.
*/
- u_int needed;
u_int left;
char *s;
@@ -1338,11 +1338,13 @@
error = 0;
break;
}
-
-
- /* if too much buffer supplied, trim it down */
- if (size needed)
- size = needed;
+ if ((error = copyin(uap-size, size, sizeof(size))) != 0)
+ break;
+ if (size needed) {
+ error = ENOMEM;
+ break;
+ }
+ size = needed;
/* how much of the buffer is remaining */
left = size;
@@ -1364,7 +1366,7 @@
}
if (error)
return (error);
- p-p_retval[0] = size;
+ p-p_retval[0] = needed ? needed : size;
if (uap-size)
error = copyout((caddr_t)size, (caddr_t)uap-size,
sizeof(size));
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
old BSD/OS binary coredumps
After upgrading to current-2001-08-28, my old BSD/OS Netscape 3 binary no longer works. It coredumps right away at startup, before opening any window. (Running it as netscape3 -help, where it only produces a usage message, isn't affected.) Now the interesting part: i wanted to get an idea why this happened, and ran it through ktrace. Voila, that still works! Likewise when running through truss. Does anybody have an idea what might have changed, and why's that odd behaviour with the syscall tracers? -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Large patchset for the floppy driver
Hello all, before leaving for vacation next week, i thought i'd put up the result of my work of the last couple of weeks for a review for those who are interested. The patch itself is available at http://people.freebsd.org/~joerg/fdpatch.txt.gz The following README file (see below) is also available at http://people.freebsd.org/~joerg/README.floppy Suggestions are welcome, but keep in mind that i won't have the opportunity to reply within ca. the next three weeks. == Many changes and improvements to the floppy driver. First of all, something i've meant to implement for years now, but never came around: automatic format (density) selection for the major medium formats. That is, you can stuff your 720 KB medium into your 1.44 MB drive, and simply access /dev/fd0. No questions asked, it will just handle it. :) (If you ever wondered why this didn't happen before, the answer is very simple: i needed the infrastructure to read a sector ID field before. That was one of the recent additions to the driver.) The driver can now handle FM floppies as well as MFM floppies. The NE765 commands in ne765.h have been redefined to no longer make implicit assumptions about MFM, SK, and MT; the driver adds those bits as required. The entire density handling subsystem with its bloated list of different possible media density and its twisted decisions about which drive can handle what has been completely moved out of the kernel, into fdcontrol(8) where it should have been all the time. It's very simple, the basic device (four low order bits equal 0) is the subdevice with automagic density selection, and subdevices 1 through 15 are available for fixed density assignments. By default, all of the latter are being initialized to the drive's maximum possible density. It's up to fdcontrol(8) to customize those subdevices. Subdevice naming has been liberalized; subdevices `a' through `h' are still implemented as pseudo-partitions which just cause a symlink to be created to the master device. Subdevices of the form . can be arbitrarily created, where . means between 1 and 4 digits. So you can now either create your subdevices like fd0.1 through fd0.15, or you can still name them by density (as it used to be now, but with a fixed set of allowable names), as in fd1.800 etc. Automagic density selection honors the unit attention bit (aka. changeline signal). It is checked in Fdopen(), and if it is set, the autoselection is started. If you re-open the same device without changing media, no new autoselection is initiated. Some old hacks have been made right, now that the infrastructure seems to be in place. There's no longer a configuration flag to fdc(4) that tells there should be a single 1.44 MB drive assumed without probing. On non-i386 architectures, there's no longer an assumption that all the world is an 1.44 MB drive; on i386 architectures there's no longer the assumption that you could only have two drives that need to be mentioned in the RTC (although you need more than one controller for more drives, and i haven't tested that yet). Drive configuration is now handled through device hints and a `flags' value per drive: the lower 4 bits define the drive type (like in i386 RTC, but shifted right by 4), bit 0x10 disables changeline support, bit 0x20 forces the device to probe successfully without making a seek test first. On i386 architectures, if the device type hasn't been set by the flags, and the fd unit number is 0 or 1, the CMOS RTS is still queried as it used to be (but you could now override this). (Detection of the i386 architecture has been changed to test for _MACHINE_ARCH instead of testing whether we are compiling on __i386__.) O_NONBLOCK handling has been added to support formatting on a device that is normally using density autoselection. Obviously, you cannot autoselect the density of an unformatted medium :), so O_NONBLOCK seemed to be the best way out. Only a limited subset of ioctls is possible in nonblocking mode, then you need to clear the flags with fcntl in order to perform actual IO. Some things in the density structure have been changed: there certainly won't be more than two steps between cylinder, so we can singly fold this feature into a flag bit, where the remaining bits can be used otherwise (currently for MFM vs. FM, and for perpendicular recording which is needed for 2.88 media). There's now a field that allows to specify an offset for the sector numbers on side 2; some very old media used to be formatted that way (and Bruce Evans still has some :). A number of further ioctls have been added to obtain driver and device information. Used in fdcontrol and fdformat. fdcontrol(8) has been heavily rewritten. Densities can be specified in kilobytes, and will then be selected from per-drive type tables, or they can be specified as a feature string (currently only explained in fdsupport.c). A
Re: buildworld problem.
David O'Brien [EMAIL PROTECTED] wrote: -cn: No such file or directory *** Error code 1 I would run ``type gzip'' or ``which gzip''. It seems either you've done something to your gzip binary, or there is a commit that broke it that I've missed. That's typical behaviour for the mini-gzip that is part of /stand/sysinstall. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cannot print to remote printer
Anton Berezin [EMAIL PROTECTED] wrote:
if (fork() == 0) {
- signal(SIGCHLD, SIG_IGN);
+ signal(SIGCHLD, SIG_DFL);
This is unportable.
If you want automatic zombie reaping, better don't use the simplified
signal(3) handling, but instead spell it out as sigaction(2) using the
SA_NOCLDWAIT flag. The above won't even give you a warning on systems
that don't implement automatic zombie reaping, while with sicaction,
you'll get a compile-time error for SA_NOCLDWAIT not being defined.
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: cannot print to remote printer
As Anton Berezin wrote: - signal(SIGCHLD, SIG_IGN); + signal(SIGCHLD, SIG_DFL); Umm, I don't understand. I do not want automatic zombie reaping, I want exactly the opposite, and my patch does just that. Ah sorry, i was confused. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: diskcheckd goes nuts on /dev/cd0
Bruce Evans [EMAIL PROTECTED] wrote: I think diskcheckd.conf should check no disks by default. My opinion, too. (After i suddenly noticed it checks anything by default...) Checking is bad for many types of disks. It's bad for all disks on laptops running off batteries. And for many other disks, it doesn't gain anything. Except for laptops, i generally don't buy ATA disks. For a good SCSI disk, disckcheck won't report anything. It has the only side effect of remapping a bad block, perhaps a bit earlier than it would have been remapped during normal operation. (If the disk really goes bad, it's very likely that diskcheckd will be too late to detect it anyway.) So for me, diskcheckd could only be useful if it would also read out the SCSI defect lists, and compare them on a daily basis so i get an early warning about remap activity. I'll add the knob to turn it off in sysinstall, which phk forgot to add when he added it to rc.conf. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: floppy driver unusable
Dag-Erling Smorgrav [EMAIL PROTECTED] wrote: After Joerg's late-June round of brea^H^H^H^Hcommits to the floppy driver, I can no longer use my floppy drive. Any attempt to access the drive (with a known-good writeable floppy in it) simply hangs in physst state until I eject the disk, at which point it fails with a hard read error with No status. Well, it works for me here, but you knew that, of course. :-) fdc0: NEC 72065B or clone at port 0x3f2-0x3f5,0x3f7 irq 6 drq 1 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 fd0: hard error reading fsbn 0 of 0-7 (No status) fd0: hard error writing fsbn 0 of 0-35 (No status) fd0: hard error reading fsbn 0 (No status) Do you have any further input? Does fdformat still work? Does fdread -I 1 return you a sector ID? There weren't any commit so far until yesterday that was supposed to affect the normal operation of floppies at all (only cosmetics and additions). Can you pin it down to which of the changes has broken it for you? Can you compile with options FDC_DEBUG, and then turn on debugging on the drive? In -current, you can do this with fdcontrol -d1 /dev/fd0, in older versions you need DDB for it. Debugging output is huge and unreadable, please send it to me privately, not to the list. p.s.: If you'd sent me a Cc of this message, i would have responded quicker. I can't afford it to scan this list on a daily basis. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: fd0c mount(8) Race
Crist J. Clark [EMAIL PROTECTED] wrote: mount: /dev/fd0c: No such file or directory It seems there is some type of race to get the fd0c symlink in place and I am not winning it. The symlink DEVFS nodes are going to be created first time they are referenced. Your mount attempt thus does create it, but has got reported it as ENOENT already by that time. I switched to /dev/fd0 and the boot went fine, but if this is real, it should be fixed. Maybe. Btw., there's no point in trying to mount /dev/fd0c anyway. There are no partitioned floppy device nodes (except perhaps in Bruce Evans' private tree :) anyway. Pseudo-partitions fd0a through fd0h have been aliases for just fd0 for years. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Vinum + DEVFS ?
Alfred Perlstein [EMAIL PROTECTED] wrote: ..., I saw a message saying that Vinum was not yet ready for use with DEVFS. Is that still the case? I fixed that. :) Let me and Grog know if you have problems. It basically works for me. Of course, vinum still has a dozen of bugs that get uncovered once you leave the path Greg has been testing :) (like you make a typo in your configuration...), but that's another matter. Anyway, since i just fell again across it: the vinum devfs volume entries get assigned to root:wheel mode 0600. This makes it impossible for a member of group `operator' to dump(8) them although operators can dump any other disk device. We should make it consistent (either way). Also, i have been surprised that the /dev/vinum/plex nodes of a mirrored volume don't show identical contents (and the second one even seems to have the wrong device size), but that's certainly not a problem of the DEVFS integration again, but a genuine vinum bug. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: hints code bugs [Was: orm driver itches...]
Peter Wemm [EMAIL PROTECTED] wrote:
Definately a bug. :-( The scanner is effectively concatenating
the device.hints and the config hints together when enumerating them.
Speaking about bugs in the hints processing:
Triggered by Michael Reifenberger [EMAIL PROTECTED], i started
experimenting to get fdc(4) working as a KLD. There are several
resource deallocation things still wrong in it, but i have fixed a
number of them in my private tree (and know about more of them...).
So far, i've encountered two serious problems. First, when trying to
load the KLD at run-time, it cannot allocate the IO ports for fdc0,
and then registers successfully as fdc1 (but of course without any
drive connected to it since there are none mentioned in the hints for
fdc1). Michael wrote that loading the KLD by the boot loader works
well, however. I gdb'ed a little around, and found that the resource
allocator will eventually divert int pci_alloc_resources() when called
on behalf of fdc0. Naturally, this function doesn't even know how to
handle IO port allocation, thus fails. When called next time on
behalf of fdc1, the device is however (mis?)detected as PnP, and all
works out well.
Does anybody have an idea why the code would believe fdc0 to be
connected to the PCI bus? (The hints do say it's located on the ISA
bus, of course.) Can anybody describe the rough picture how the
`default' IO port allocation (range 0 .. ~0UL) is supposed to work at
all? I'm a bit confused.
Is it possible to modify the hints at run-time (i. e. before
kldloading the module)?
Second, the driver doesn't deallocate completely. When calling
devinfo(1) after kldunloading it, i get a panic somewhere in the
depths of kprintf(), where it is trying to print the device
description of fdc1 (where the string dev-descr was pointing to has
been kldunloaded since). What needs to be done in order to destroy
the device structure completely, and which of those tasks is the
kernel linker supposed to perform?
In case anybody wants to give it a try, i'll append my private patches
collected so far.
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
Index: isa/fd.c
===
RCS file: /home/ncvs/src/sys/isa/fd.c,v
retrieving revision 1.204
diff -u -u -r1.204 fd.c
--- isa/fd.c2001/06/20 20:21:55 1.204
+++ isa/fd.c2001/06/24 17:28:58
@@ -170,6 +170,8 @@
struct callout_handle toffhandle;
struct callout_handle tohandle;
struct devstat device_stats;
+ eventhandler_tag clonetag;
+ dev_t masterdev;
device_t dev;
fdu_t fdu;
};
@@ -497,7 +499,7 @@
fdc_alloc_resources(struct fdc_data *fdc)
{
device_t dev;
- int ispnp, ispcmcia;
+ int ispnp, ispcmcia, nports;
dev = fdc-fdc_dev;
ispnp = (fdc-flags FDC_ISPNP) != 0;
@@ -516,12 +518,13 @@
* uses the register with offset 6 for pseudo-DMA, and the
* one with offset 7 as control register.
*/
+ nports = ispcmcia ? 8 : (ispnp ? 1 : 6);
fdc-res_ioport = bus_alloc_resource(dev, SYS_RES_IOPORT,
fdc-rid_ioport, 0ul, ~0ul,
-ispcmcia ? 8 : (ispnp ? 1 : 6),
-RF_ACTIVE);
+nports, RF_ACTIVE);
if (fdc-res_ioport == 0) {
- device_printf(dev, cannot reserve I/O port range\n);
+ device_printf(dev, cannot reserve I/O port range (%d ports)\n,
+ nports);
return ENXIO;
}
fdc-portt = rman_get_bustag(fdc-res_ioport);
@@ -569,7 +572,7 @@
0ul, ~0ul, 1, RF_ACTIVE);
if (fdc-res_ctl == 0) {
device_printf(dev,
- cannot reserve control I/O port range\n);
+ cannot reserve control I/O port range (control port)\n);
return ENXIO;
}
fdc-ctlt = rman_get_bustag(fdc-res_ctl);
@@ -760,8 +763,10 @@
return (error);
}
+#endif /* NCARD 0 */
+
static int
-fdc_pccard_detach(device_t dev)
+fdc_detach(device_t dev)
{
struct fdc_data *fdc;
int error;
@@ -772,6 +777,12 @@
if ((error = bus_generic_detach(dev)))
return (error);
+ /* reset controller, turn motor off */
+ fdout_wr(fdc, 0);
+
+ if ((fdc-flags FDC_NODMA) == 0)
+ isa_dma_release(fdc-dmachan);
+
if ((fdc-flags FDC_ATTACHED) == 0) {
device_printf(dev, already unloaded\n);
return (0);
@@ -785,8 +796,6 @@
return (0);
}
-#endif /* NCARD 0 */
-
/*
* Add a
Re: panic: ufs_extattr_uepm_destroy: not initialized
As Robert Watson wrote: Thomas Moestl recently committed some fixes to the EA code, and may have a couple more in the pipeline that address these problems. I've seen the commits, however, since my system was grossly unstable, i by now took out the EA options again. I'll see whether i can reproduce that with my test machine. Out of curiosity, does your /tmp actually have EA's started on it, or is it just the kernel option? I've got UFS_EXTATTR_AUTOSTART in the config. Are you using MFS or ext2fs at all? Neither of them. (I've only recently started recovering from moving, so I'm fairly behind on -CURRENT e-mail) I could think of it, after reading you're I'm moving, marrying, ... mail. ;-) -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: locale names reorganization
Maxim Sobolev [EMAIL PROTECTED] wrote: Please post a HEADS UP when you are done, so we all be notified that the world is in the safe state again. And, please also post a list of old vs. new names. Not all of us follow the i18n list. Anyway, nice to see that we're going to be compatible to the rest of the world! -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: ufs_extattr_uepm_destroy: not initialized
Joerg Wunsch [EMAIL PROTECTED] wrote: It /only/ happens after a mount -a, not after just mounting /tmp only. No idea why, the only `obscure' filesystems i've got are procfs and portalfs. portalfs indeed seems to be the culprit for leaving an unreferenced file in /tmp. However, the panic for forcibly umounting /tmp then clearly belongs to the extattr code. Removed the option from my config again (i just wanted to give ACLs a try only anyway), and now i'm living without that panic again. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic: ufs_extattr_uepm_destroy: not initialized
subject consistently happens for me when i try to umount /tmp. A normal umount doesn't work, not even in single-user mode (device busy), and a forcible umount causes the panic. fstat doesn't show any open descriptors on it though. It happens on a newfs'd /tmp, too. It /only/ happens after a mount -a, not after just mounting /tmp only. No idea why, the only `obscure' filesystems i've got are procfs and portalfs. The related kernel options have been cutpasted out of NOTES: # Extended attributes allow additional data to be associated with files, # and is used for ACLs, Capabilities, and MAC labels. # See src/sys/ufs/ufs/README.extattr for more information. options UFS_EXTATTR options UFS_EXTATTR_AUTOSTART # Access Control List support for UFS filesystems. The current ACL # implementation requires extended attribute support, UFS_EXTATTR, # for the underlying filesystem. # See src/sys/ufs/ufs/README.acls for more information. options UFS_ACL Here's the stack trace (taken after another panic command in DDB): (no debugging symbols found)... IdlePTD 4669440 initial pcb at 39de40 panicstr: from debugger panic messages: --- panic: ufs_extattr_uepm_destroy: not initialized panic: from debugger Uptime: 51s dumping to dev da0b, offset 75840 dump 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 --- #0 0xc01be0d2 in dumpsys () (kgdb) bt #0 0xc01be0d2 in dumpsys () #1 0xc01bdebf in boot () #2 0xc01be2d9 in panic () #3 0xc013bd75 in db_panic () #4 0xc013bd15 in db_command () #5 0xc013bdda in db_command_loop () #6 0xc013dfa3 in db_trap () #7 0xc02c00c6 in kdb_trap () #8 0xc02cc7c0 in trap () #9 0xc02c0334 in Debugger () #10 0xc01be2d0 in panic () #11 0xc029ba26 in ufs_extattr_uepm_destroy () #12 0xc0298869 in ffs_unmount () #13 0xc01fa2cf in dounmount () #14 0xc01fa159 in unmount () #15 0xc02cd3ad in syscall () #16 0xc02c0b9d in syscall_with_err_pushed () #17 0x8048af3 in ?? () #18 0x80484fe in ?? () #19 0x8048137 in ?? () (kgdb) quit -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current broken ?
Poul-Henning Kamp [EMAIL PROTECTED] wrote: === usr.bin/fetch /flat/src/usr.bin/fetch/fetch.c: In function `main': /flat/src/usr.bin/fetch/fetch.c:757: `vtty' undeclared (first use in this function) Noticed this in my `make release' attempt yesterday, too. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: worklist_remove panic
Peter Wemm [EMAIL PROTECTED] wrote: For some reason, sysinstall or the kernel decided to += 64k on the start address of the swap partition (to avoid swap clobbering the fdisk, bootblocks, etc at the start of the disk), but neglected to remove 64k from the size. This could be undone. Swapping has been fixed long ago to not clobber disklabels (i. e. it doesn't start at the beginning of the swap partition). -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
