Re: Meaning of net.inet.tcp.inflight_debug output?
On Fri, 4 Oct 2002 11:34:46 -0700 (PDT) Matthew Dillon [EMAIL PROTECTED] wrote: When you turn the debugging on it will print out various parameters used to calculate the bandwidth window. The higher the debug value, the more often it prints out the stats (assuming a TCP is under load). Since the stats may reflect any tcp connection you typically only do this while running a single TCP connection under heavy load. So shouldn't it be off by default? rttbest and srtt are scaled to hz * 32, I believe (I'm not positive). So with the default 100 hz it would be scaled to 3200, so an rttbest of 680 would translate to 212mS. Sounds like a connection over a modem. On my side there's a DSL line (768k up / 128k down), I don't know what was on the other side for this particular example. Bye, Alexander. -- The best things in life are free, but the expensive ones are still worth a look. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADSUP! GEOM as default in 5 days... GEOM does not find da0a; goes to rootmount
In message [EMAIL PROTECTED], Daniel Flickinger writes: I will note that my loader is dated 27 Sep since there has not been an even close to complete buildworld since then; Something in your tree is not OK then, because I have compiled buildworld many times since the 27th, last time just a few hours ago: cd /bang/src make buildworld TARGET_ARCH=i386 __MAKE_CONF=/dev/null \ _.i386.buildworld 21 i386 buildworld ended on Sat Oct 5 07:31:09 GMT 2002 The problem with the floppy drive is interesting, I guess it means that the SCSI da driver return EBUSY to mean no media rather than ENXIO as it should. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: signal 6 to XFree86 (Re: cvs commit: src/tools/tools...)
On Fri, 4 Oct 2002 19:35:59 -0700 Kris Kennaway [EMAIL PROTECTED] wrote: I had one today, they have decreased significantly since removing the Type1 module from my server configuration. I've also found that disabling xscreensaver/xlockmore helps - or just set it to blank screen only. (Some of those graphical modules use beziers.) My XFree86 crashes pretty much every time I turn my back on my PC for a few minutes and let xscreensaver kick in. I don't have a fancy screensaver (blank screen + DPMS), and it even crashes when I do nothing... I've played some mp3s in a xterm and worked in the room *boom* signal 6. At the moment I'm running with http://people.freebsd.org/~deischen/sys.diffs, no signal 6 so far but the system is up only for 50 minutes... as already said in another mail, sometimes I'm able to work for 1-2 hours without a signal 6, sometimes I just have to start up my MUA. Bye, Alexander. -- Speak softly and carry a cellular phone. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
alpha tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sat Oct 5 03:29:30 PDT 2002 -- Kernel build for GENERIC completed on Sat Oct 5 03:56:12 PDT 2002 -- Kernel build for LINT started on Sat Oct 5 03:56:12 PDT 2002 -- === vinum cc1: warnings being treated as errors /h/des/src/sys/dev/advansys/adv_pci.c: In function `adv_pci_attach': /h/des/src/sys/dev/advansys/adv_pci.c:197: warning: overflow in implicit constant conversion *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sym disabling controller LED?
Christian Weisgerber wrote: Actually, that's a case of sym(4) failing to actuate the LED rather than shutting it off. Later sym chips control the LED in hardware, but the '875 doesn't and the driver has to blink the LED. Oh shucks, and I thought this was decent hardware. :) I'll still have the acoustic feedback from the harddisk anyway. Regards, -- Michael Nottebrock And the reasons? There are no reasons. msg44011/pgp0.pgp Description: PGP signature
Re: [ GEOM tests ] vinum drives lost
On Fri, 4 Oct 2002, Poul-Henning Kamp wrote: Worst case you will have the option to use: options NOGEOM options vinum A NOGEOM option would be as acceptable as a NOFFS option for turning off forcing of the one true file system down everyone's throats. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
make buildworld fails during stage 4, libpcap
Hi, I'm trying to make buildworld a recently checked-out copy of -current under 4.6-RELEASE (is that a bad move?). During the process, it gets to: -- stage 4: building libraries -- [snip] === lib/libpcap [snip] cc -O -pipe -DHAVE_CONFIG_H -Dyylval=pcap_lval -I/usr/src-current/lib/libpcap -I. -DINET6 -I/usr/src-current/lib/libpcap/../../contrib/libpcap -c /usr/src-current/contrib/libpcap/gencode.c -o gencode.o /usr/src-current/contrib/libpcap/gencode.c: In function `init_linktype': /usr/src-current/contrib/libpcap/gencode.c:604: `DLT_PPP_ETHER' undeclared (first use in this function) /usr/src-current/contrib/libpcap/gencode.c:604: (Each undeclared identifier is reported only once /usr/src-current/contrib/libpcap/gencode.c:604: for each function it appears in.) /usr/src-current/contrib/libpcap/gencode.c:682: `DLT_PRISM_HEADER' undeclared (first use in this function) /usr/src-current/contrib/libpcap/gencode.c:721: `DLT_LTALK' undeclared (first use in this function) /usr/src-current/contrib/libpcap/gencode.c: In function `gen_linktype': /usr/src-current/contrib/libpcap/gencode.c:955: `DLT_PRISM_HEADER' undeclared (first use in this function) /usr/src-current/contrib/libpcap/gencode.c:1215: `DLT_PPP_ETHER' undeclared (first use in this function) /usr/src-current/contrib/libpcap/gencode.c:1412: `DLT_LTALK' undeclared (first use in this function) *** Error code 1 Stop in /usr/src-current/lib/libpcap. ...etc. I'm following the instructions in the handbook for checking out -current, so there's a good chance I'm making a newbie mistake. Apologies in advance if this is the case, and I promise I have R every F M that I can think of. cheers, Will To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] vinum drives lost
On Fri, Oct 04, 2002 at 12:45:59PM -0700, Lars Eggert [EMAIL PROTECTED] wrote: Well, the showstopper is in vinum. The fact that ccd(4) works seamlessly with GEOM is testament to this. For some reason I was under the (mis?)impression that ccd was no longer being maintained... If it works with geom, we can probably move our machines over to ccd. They're all no-frills stripes, so ccd functionality is good enough. Some time ago Scott Long pointed out to me that ccd has less overhead than vinum and is better suited for bare striping. The actual case involved two fake disks using asr(4) and 2400A. I had no choice because hardware doesn't support spanning. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Kernel Hacker page updated...
On Fri, Oct 04, 2002 at 04:33:17PM -0400, John Baldwin wrote:
I wrote:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id =
fault virtual address = 0x8
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01a1212
stack pointer = 0x10:0xe5226c14
frame pointer = 0x10:0xe5226ca0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 56525 (make)
kernel: type 12 trap, code = 0
Stopped atkqueue_scan+0x242: cmpl $0,0x8(%ebx)
db trace
kqueue_scan(c6472bf4,4,bfbfebc0,0,c70ecea0) at kqueue_scan+0x242
kevent(c70ecea0,e5226d10,c0351d80,418,6) at kevent+0x1e1
syscall(2f,2f,2f,818d780,818d960) at syscall+0x2be
%%%
Even better, pop up gdb on kernel.debug and do
'l *kqueue_scan+0x242' to look at the offending line of code.
addr2line can also be useful here similarly.
(kgdb) l *kqueue_scan+0x242
0xc01a1212 is in kqueue_scan
(/freebsd/current/src/sys/kern/kern_event.c:716).
711 }
712
713 TAILQ_INSERT_TAIL(kq-kq_head, marker, kn_tqe);
714 while (count) {
715 kn = TAILQ_FIRST(kq-kq_head);
translates to: mov(%edi),%ebx
716 TAILQ_REMOVE(kq-kq_head, kn, kn_tqe);
translates to: cmpl $0x0,0x8(%ebx)
This line causes the page fault because %ebx is 0.
je fe3 kqueue_scan+0x253
mov0x8(%ebx),%edx
[...]
717 if (kn == marker) {
718 splx(s);
719 if (count == maxevents)
720 goto retry;
I've added this after line 715:
716 if (kn == NULL) {
717 Debugger(TAILQ_FIRST returns NULL);
718 }
and after 4 freezes, I really came into ddb in line 717. However, when
trying to produce a dump, this occured:
db panic
panic: from debugger
cpuid = 1; lapic.id = 0100
boot() called on cpu#1
syncing disks... panic: bremfree: bp 0xd2a42990 not locked
boot() called on cpu#1
Uptime: 10m13s
pfs_vncache_unload(): 1 entries remaining
Dumping 1023 MB
ata0: resetting devices
ata0: mask=03 ostat0=50 ostat2=00
ad0: ATAPI 00 00
ata0-slave: ATAPI 00 00
ata0: mask=03 stat0=50 stat1=00
ad0: ATA 01 a5
ata0: devices=01
and I had to reboot without a dump :-(
Regards,
Stefan Farfeleder
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] vinum drives lost
Bruce Evans wrote: On Fri, 4 Oct 2002, Poul-Henning Kamp wrote: Worst case you will have the option to use: options NOGEOM options vinum A NOGEOM option would be as acceptable as a NOFFS option for turning off forcing of the one true file system down everyone's throats. Part of the problem there is a weakness in config that I've threatened to fix on more than one occasion. We do not have a way to have options default to on and let people turn the option off. Negative options (options NOFOO) are a poor substitute. In the past, a couple of things were unifdefed that might have been better served as being 'default to on' options or drivers. This of course is ignoring the issue of geom vs the disklabel code. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic from _mutex_assert in kern_lock.c
The source tree was retrieved by cvsup
at 21:47 (PST) on Oct 4.
This is a non-GEOM and non-acpi kernel.
I have the core and kernel.debug, so any
further postmortem is possible.
--
Steve
http://troutmask.apl.washington.edu/~kargl/
panic: from debugger
panic messages:
---
panic: mutex vnode interlock not owned at /usr/src/sys/kern/kern_lock.c:229
panic: from debugger
Uptime: 1m57s
pfs_vncache_unload(): 2 entries remaining
Dumping 128 MB
16 32 48 64 80 96 112
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:223
223 dumping++;
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:223
#1 0xc01ab96a in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:355
#2 0xc01abbb3 in panic () at /usr/src/sys/kern/kern_shutdown.c:508
#3 0xc013c3c2 in db_panic () at /usr/src/sys/ddb/db_command.c:450
#4 0xc013c342 in db_command (last_cmdp=0xc02e7d80, cmd_table=0xc02e7ba0,
aux_cmd_tablep=0xc02e04d0, aux_cmd_tablep_end=0xc02e04d4)
at /usr/src/sys/ddb/db_command.c:346
#5 0xc013c456 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6 0xc013f0ba in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:72
#7 0xc028c1a2 in kdb_trap (type=3, code=0, regs=0xc8e6d7b4)
at /usr/src/sys/i386/i386/db_interface.c:166
#8 0xc029c8f7 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1048044496, tf_esi = 256, tf_ebp
= -924395520, tf_isp = -924395552, tf_ebx = 0, tf_edx = 0, tf_ecx = 126, tf_eax = 18,
tf_trapno = 3, tf_err = 0, tf_eip = -1071070140, tf_cs = 8, tf_eflags = 658, tf_esp =
-1070749825, tf_ss = -1070840167}) at /usr/src/sys/i386/i386/trap.c:605
#9 0xc028d958 in calltrap () at {standard input}:98
#10 0xc01abb9b in panic (fmt=0xc02c39f4 mutex %s not owned at %s:%d)
at /usr/src/sys/kern/kern_shutdown.c:494
#11 0xc01a226c in _mtx_assert (m=0xc18c0de0, what=9,
file=0xc02c28a0 /usr/src/sys/kern/kern_lock.c, line=229)
at /usr/src/sys/kern/kern_mutex.c:835
#12 0xc019e88b in lockmgr (lkp=0xc18c0ea4, flags=16842754, interlkp=0xc18c0de0,
td=0xc1881c30) at /usr/src/sys/kern/kern_lock.c:229
#13 0xc01f53cc in vop_stdlock (ap=0xc8e6d8c0)
at /usr/src/sys/kern/vfs_default.c:279
#14 0xc0257118 in ufs_vnoperate (ap=0xc8e6d8c0)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:2715
#15 0xc020965b in vn_lock (vp=0xc18c0de0, flags=65538, td=0xc1881c30)
at vnode_if.h:990
#16 0xc023a555 in ffs_snapshot (mp=0xc1921600, snapfile=---Can't read userspace from
dump, or kernel process---
)
at /usr/src/sys/ufs/ffs/ffs_snapshot.c:409
#17 0xc0247cf8 in ffs_mount (mp=0xc1921600, path=0xc1b31000 /var, data=---Can't read
userspace from dump, or kernel process---
)
at /usr/src/sys/ufs/ffs/ffs_vfsops.c:291
#18 0xc01f97d4 in vfs_mount (td=0xc1881c30, fstype=0xc1929c20 ffs,
fspath=0xc1b31000 /var, fsflags=18944000, fsdata=0xbfbffcc0)
at /usr/src/sys/kern/vfs_mount.c:1062
#19 0xc01f8f98 in mount (td=0xc1881c30, uap=0xc8e6dd10)
at /usr/src/sys/kern/vfs_mount.c:818
#20 0xc029d20e in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = -1077936672, tf_ebp =
-1077936824, tf_isp = -924394124, tf_ebx = 135000998, tf_edx = 19, tf_ecx = 135000832,
tf_eax = 21, tf_trapno = 12, tf_err = 2, tf_eip = 134568967, tf_cs = 31, tf_---Type
return to continue, or q return to quit---
eflags = 518, tf_esp = -1077937140, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1050
#21 0xc028d9ad in Xint0x80_syscall () at {standard input}:140
---Can't read userspace from dump, or kernel process---
(kgdb) quit
Script done on Sat Oct 5 08:28:03 2002
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
SSE
Hi. I can panic my current system compiled from sources of yesterday by just starting mozilla or ogg123 ogg-file if I don't include options CPU_DISABLE_SSE in my kernel configuration file. Is anyone else seeing any SSE code related problems ? (P III based SMP system here) best regards --gt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make buildworld fails during stage 4, libpcap
On Sat, Oct 05, 2002 at 10:37:38PM +1000, William Rose wrote: Hi, I'm trying to make buildworld a recently checked-out copy of -current under 4.6-RELEASE (is that a bad move?). During the process, it gets to: -- stage 4: building libraries -- [snip] === lib/libpcap [snip] cc -O -pipe -DHAVE_CONFIG_H -Dyylval=pcap_lval -I/usr/src-current/lib/libpcap -I. -DINET6 -I/usr/src-current/lib/libpcap/../../contrib/libpcap -c /usr/src-current/contrib/libpcap/gencode.c -o gencode.o /usr/src-current/contrib/libpcap/gencode.c: In function `init_linktype': /usr/src-current/contrib/libpcap/gencode.c:604: `DLT_PPP_ETHER' undeclared (first use in this function) /usr/src-current/contrib/libpcap/gencode.c:604: (Each undeclared identifier is reported only once /usr/src-current/contrib/libpcap/gencode.c:604: for each function it appears in.) /usr/src-current/contrib/libpcap/gencode.c:682: `DLT_PRISM_HEADER' undeclared (first use in this function) /usr/src-current/contrib/libpcap/gencode.c:721: `DLT_LTALK' undeclared (first use in this function) /usr/src-current/contrib/libpcap/gencode.c: In function `gen_linktype': /usr/src-current/contrib/libpcap/gencode.c:955: `DLT_PRISM_HEADER' undeclared (first use in this function) /usr/src-current/contrib/libpcap/gencode.c:1215: `DLT_PPP_ETHER' undeclared (first use in this function) /usr/src-current/contrib/libpcap/gencode.c:1412: `DLT_LTALK' undeclared (first use in this function) *** Error code 1 Stop in /usr/src-current/lib/libpcap. ...etc. I'm following the instructions in the handbook for checking out -current, so there's a good chance I'm making a newbie mistake. Apologies in advance if this is the case, and I promise I have R every F M that I can think of. Should work. Check that you have the latest $FreeBSD: src/sys/net/bpf.h,v 1.26 2002/06/21 05:29:40 fenner Exp $ Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg44019/pgp0.pgp Description: PGP signature
Re: [ GEOM tests ] vinum drives lost
On Sat, 5 Oct 2002, Peter Wemm wrote: Bruce Evans wrote: On Fri, 4 Oct 2002, Poul-Henning Kamp wrote: Worst case you will have the option to use: options NOGEOM options vinum A NOGEOM option would be as acceptable as a NOFFS option for turning off forcing of the one true file system down everyone's throats. Part of the problem there is a weakness in config that I've threatened to fix on more than one occasion. We do not have a way to have options default to on and let people turn the option off. Negative options (options NOFOO) are a poor substitute. In the past, a couple of things were unifdefed that might have been better served as being 'default to on' options or drivers. Hmm. Negative options implemented as negoptions FOO would work OK for this. Options could be defaulted to on by putting them in an included config file, and then turned off using negoptions. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SSE
German Tischler [EMAIL PROTECTED] wrote: Hi. I can panic my current system compiled from sources of yesterday by just starting mozilla or ogg123 ogg-file if I don't include options CPU_DISABLE_SSE in my kernel configuration file. Is anyone else seeing any SSE code related problems ? (P III based SMP system here) I seem to have the same problem on my currently-UP Athlon system, whether or not SSE is enabled; I'm trying to track it down... -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic from _mutex_assert in kern_lock.c
Steven G. Kargl [EMAIL PROTECTED] wrote: The source tree was retrieved by cvsup at 21:47 (PST) on Oct 4. This is a non-GEOM and non-acpi kernel. I have the core and kernel.debug, so any further postmortem is possible. I think the problem is that in src/sys/ufs/ffs/ ffs_snapshot.c:ffs_snapshot(), as the mnt vnode list is traversed none of the vnodes (xvp) would actually GET VI_LOCK()ed in the first place, and so the LK_INTERLOCK is bogus in the vn_lock() call. Kirk would know for sure what to do about this... -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic from _mutex_assert in kern_lock.c
Brian F. Feldman said: Steven G. Kargl [EMAIL PROTECTED] wrote: The source tree was retrieved by cvsup at 21:47 (PST) on Oct 4. This is a non-GEOM and non-acpi kernel. I have the core and kernel.debug, so any further postmortem is possible. I think the problem is that in src/sys/ufs/ffs/ ffs_snapshot.c:ffs_snapshot(), as the mnt vnode list is traversed none of the vnodes (xvp) would actually GET VI_LOCK()ed in the first place, and so the LK_INTERLOCK is bogus in the vn_lock() call. Kirk would know for sure what to do about this... I came to the same conclusion after I sent the original email. What I don't understand is how I ended up in ffs_snapshot(), because I don't have a snapshot of /var. I tried snapshots when Kirk first introduced the feature, but I removed all of the snapshots a long time ago. Is there a flag in the superblock that I need to clear? One other point, the machine was doing a background fsck on /var. Does a background fsck go through ffs_snapshot()? -- Steve http://troutmask.apl.washington.edu/~kargl/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic from _mutex_assert in kern_lock.c
Steven G. Kargl [EMAIL PROTECTED] wrote: Brian F. Feldman said: Steven G. Kargl [EMAIL PROTECTED] wrote: The source tree was retrieved by cvsup at 21:47 (PST) on Oct 4. This is a non-GEOM and non-acpi kernel. I have the core and kernel.debug, so any further postmortem is possible. I think the problem is that in src/sys/ufs/ffs/ ffs_snapshot.c:ffs_snapshot(), as the mnt vnode list is traversed none of the vnodes (xvp) would actually GET VI_LOCK()ed in the first place, and so the LK_INTERLOCK is bogus in the vn_lock() call. Kirk would know for sure what to do about this... I came to the same conclusion after I sent the original email. What I don't understand is how I ended up in ffs_snapshot(), because I don't have a snapshot of /var. I tried snapshots when Kirk first introduced the feature, but I removed all of the snapshots a long time ago. Is there a flag in the superblock that I need to clear? One other point, the machine was doing a background fsck on /var. Does a background fsck go through ffs_snapshot()? Exactly: background fsck takes a snapshot to work on. I think background_fsck=NO is a good workaround at the moment for this. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic from _mutex_assert in kern_lock.c
On Sat, 5 Oct 2002, Steven G. Kargl wrote: I came to the same conclusion after I sent the original email. What I don't understand is how I ended up in ffs_snapshot(), because I don't have a snapshot of /var. I tried snapshots when Kirk first introduced the feature, but I removed all of the snapshots a long time ago. Is there a flag in the superblock that I need to clear? One other point, the machine was doing a background fsck on /var. Does a background fsck go through ffs_snapshot()? Yes -- the background file system checker creates a snapshot of the file system in the un-checked state, then performs the check against the snapshot. It trickles the changes generated against the snapshot into the live file system. Because of the conservative nature of failures with soft updates, the only theoretical inconsistencies relate either to marked as non-free yet unreferenced resources, and referenece counts that are high. The snapshot allows fsck a consistent view of the file system as it was so that it doesn't get confused by the live file system. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SSE
Brian F. Feldman [EMAIL PROTECTED] wrote: German Tischler [EMAIL PROTECTED] wrote: Hi. I can panic my current system compiled from sources of yesterday by just starting mozilla or ogg123 ogg-file if I don't include options CPU_DISABLE_SSE in my kernel configuration file. Is anyone else seeing any SSE code related problems ? (P III based SMP system here) I seem to have the same problem on my currently-UP Athlon system, whether or not SSE is enabled; I'm trying to track it down... On further reflection, this DEFINITELY has to do with the work done on npx(4)/signals/etc. in the past week. I _must_ be getting a GPF because the fpu state that it's attempting to restore is corrupt (i.e.: the control word is incorrect), so something is not being initialized somewhere that it used to be, or is being initialized incorrectly. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HEADS UP: options GEOM/NO_GEOM
In case you are foolishly tracking -current without reading the CVS logs, you might want to be aware that the default just changed such that you get GEOM unless you explicitly specify NO_GEOM in your kernel configuration file. The pre-defined kernel configs in the base tree all specify NO_GEOM, so if you're just tracking GENERIC, you'll get the same non-GEOM behavior you had before. If you're using a custom kernel config and don't want GEOM, you'll need to add NO_GEOM. Since GEOM will be the default for 5.0-RELEASE, it's advisable to run with GEOM now so you find the problems sooner rather than later. :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic from _mutex_assert in kern_lock.c
Robert Watson said: On Sat, 5 Oct 2002, Steven G. Kargl wrote: One other point, the machine was doing a background fsck on /var. Does a background fsck go through ffs_snapshot()? Yes -- the background file system checker creates a snapshot of the file system in the un-checked state, then performs the check against the snapshot. It trickles the changes generated against the snapshot into the live file system. Because of the conservative nature of failures with soft updates, the only theoretical inconsistencies relate either to marked as non-free yet unreferenced resources, and referenece counts that are high. The snapshot allows fsck a consistent view of the file system as it was so that it doesn't get confused by the live file system. Thanks, Brian and Robert. Of course, the above makes sense when someone explains it to you. -- Steve http://troutmask.apl.washington.edu/~kargl/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] vinum drives lost
In message [EMAIL PROTECTED], Bruce Evans writes: On Sat, 5 Oct 2002, Peter Wemm wrote: Bruce Evans wrote: On Fri, 4 Oct 2002, Poul-Henning Kamp wrote: Worst case you will have the option to use: options NOGEOM options vinum A NOGEOM option would be as acceptable as a NOFFS option for turning off forcing of the one true file system down everyone's throats. Part of the problem there is a weakness in config that I've threatened to fix on more than one occasion. We do not have a way to have options default to on and let people turn the option off. Negative options (options NOFOO) are a poor substitute. In the past, a couple of things were unifdefed that might have been better served as being 'default to on' options or drivers. Hmm. Negative options implemented as negoptions FOO would work OK for this. Options could be defaulted to on by putting them in an included config file, and then turned off using negoptions. This could actually decrease the size and complexity of our kernel config files considerably, just think of all the theoretically-but-not-in-practice options like INET. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SSE
Brian F. Feldman wrote: Brian F. Feldman [EMAIL PROTECTED] wrote: German Tischler [EMAIL PROTECTED] wrote: Hi. I can panic my current system compiled from sources of yesterday by just starting mozilla or ogg123 ogg-file if I don't include options CPU_DISABLE_SSE in my kernel configuration file. Is anyone else seeing any SSE code related problems ? (P III based SMP system here) I seem to have the same problem on my currently-UP Athlon system, whether o r not SSE is enabled; I'm trying to track it down... On further reflection, this DEFINITELY has to do with the work done on npx(4)/signals/etc. in the past week. I _must_ be getting a GPF because the fpu state that it's attempting to restore is corrupt (i.e.: the control word is incorrect), so something is not being initialized somewhere that it used to be, or is being initialized incorrectly. The last few commits to machdep.c bother me, rev 1.539 in particular. If you are in a position to be able to quickly test it, it would be great to know if backing out the last few changes fixes this, and which change in particular. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Meaning of net.inet.tcp.inflight_debug output?
: :On Fri, 4 Oct 2002 11:34:46 -0700 (PDT) :Matthew Dillon [EMAIL PROTECTED] wrote: : : When you turn the debugging on it will print out various : parameters used to calculate the bandwidth window. The higher the : debug value, the more often it prints out the stats (assuming a : TCP is under load). Since the stats may reflect any tcp connection : you typically only do this while running a single TCP connection : under heavy load. : :So shouldn't it be off by default? : : rttbest and srtt are scaled to hz * 32, I believe (I'm not : positive). So with the default 100 hz it would be scaled to 3200, : so an rttbest of 680 would translate to 212mS. Sounds like a : connection over a modem. : :On my side there's a DSL line (768k up / 128k down), I don't know what :was on the other side for this particular example. : :Bye, :Alexander. Well, it's an experimental feature. The whole feature is turned off by default but in -current debugging is turned on by default if you turn the feature on. In -stable debugging is turned off by default to avoid confusion. In anycase, I could change the debugging default to off in -current but I can't do it right this moment. I'll try to remember to do it tonight. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 tinderbox failure
Matt, something in your mcd commits (staticizing probe/attach) may have broken LINT. On Sat, 5 Oct 2002, Dag-Erling Smorgrav wrote: -- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sat Oct 5 09:40:51 PDT 2002 -- Kernel build for GENERIC completed on Sat Oct 5 10:24:03 PDT 2002 -- Kernel build for LINT started on Sat Oct 5 10:24:04 PDT 2002 -- [...] linking kernel mcd_isa.o: In function `mcd_isa_probe': mcd_isa.o(.text+0xde): undefined reference to `mcd_probe' mcd_isa.o: In function `mcd_isa_attach': mcd_isa.o(.text+0x191): undefined reference to `mcd_probe' mcd_isa.o(.text+0x1ac): undefined reference to `mcd_attach' *** Error code 1 Stop in /local0/scratch/des/obj/local0/scratch/des/src/sys/LINT. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 tinderbox failure
Nate Lawson [EMAIL PROTECTED] writes: Matt, something in your mcd commits (staticizing probe/attach) may have broken LINT. mcd.c intentionally creates an empty object file in the GEOM-defined (ie. LINT) case. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 tinderbox failure
On Sat, 5 Oct 2002, Mike Barcroft wrote: Nate Lawson [EMAIL PROTECTED] writes: Matt, something in your mcd commits (staticizing probe/attach) may have broken LINT. mcd.c intentionally creates an empty object file in the GEOM-defined (ie. LINT) case. Ah, sorry. That means phk's big ifndef. How about creating a NULL probe/attach for GEOM that returns ENXIO so at least it links? I'll do it if no objections. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 tinderbox failure
In message [EMAIL PROTECTED], Nate Lawson writ es: On Sat, 5 Oct 2002, Mike Barcroft wrote: Nate Lawson [EMAIL PROTECTED] writes: Matt, something in your mcd commits (staticizing probe/attach) may have broken LINT. mcd.c intentionally creates an empty object file in the GEOM-defined (ie. LINT) case. Ah, sorry. That means phk's big ifndef. How about creating a NULL probe/attach for GEOM that returns ENXIO so at least it links? I'll do it if no objections. It was my impression that people were trying to solve this issue so that mcd can coexist with GEOM properly. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SSE
On Sat, 5 Oct 2002, Peter Wemm wrote: Brian F. Feldman wrote: Brian F. Feldman [EMAIL PROTECTED] wrote: German Tischler [EMAIL PROTECTED] wrote: Hi. I can panic my current system compiled from sources of yesterday by just starting mozilla or ogg123 ogg-file if I don't include options CPU_DISABLE_SSE in my kernel configuration file. Is anyone else seeing any SSE code related problems ? (P III based SMP system here) I seem to have the same problem on my currently-UP Athlon system, whether o r not SSE is enabled; I'm trying to track it down... On further reflection, this DEFINITELY has to do with the work done on npx(4)/signals/etc. in the past week. I _must_ be getting a GPF because the fpu state that it's attempting to restore is corrupt (i.e.: the control word is incorrect), so something is not being initialized somewhere that it used to be, or is being initialized incorrectly. The last few commits to machdep.c bother me, rev 1.539 in particular. If you are in a position to be able to quickly test it, it would be great to know if backing out the last few changes fixes this, and which change in particular. There have been two commits since 1.539; what version of machdep.c is being used? -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[PATCH] Re: Junior Kernel Hacker page updated...
Stefan Farfeleder wrote:
(kgdb) l *kqueue_scan+0x242
0xc01a1212 is in kqueue_scan
(/freebsd/current/src/sys/kern/kern_event.c:716).
713 TAILQ_INSERT_TAIL(kq-kq_head, marker, kn_tqe);
714 while (count) {
715 kn = TAILQ_FIRST(kq-kq_head);
translates to: mov(%edi),%ebx
716 TAILQ_REMOVE(kq-kq_head, kn, kn_tqe);
translates to: cmpl $0x0,0x8(%ebx)
This line causes the page fault because %ebx is 0.
This can't happen, at least from an empty list perspective,
even if kqueue_scan() is reentered, since the marker is an
auto allocation on the stack, and a different stack means a
different marker gets inserted (marker isn't static, so having
more than one insert of the marker won't result in only a
single insertion).
I suspect that what is hapening is that the code is being
reentered, and one marker is being treated as an event, because
of whatever garbage happens to be on the stack in the allocated
marker.
The marker is removed, and then it is not found before you hit
the end of the list.
Please try the attached patch.
-- Terry
Index: sys/event.h
===
RCS file: /cvs/src/sys/sys/event.h,v
retrieving revision 1.21
diff -c -r1.21 event.h
*** sys/event.h 29 Jun 2002 19:14:52 - 1.21
--- sys/event.h 5 Oct 2002 15:12:24 -
***
*** 160,165
--- 160,166
#define KN_QUEUED 0x02/* event is on queue */
#define KN_DISABLED 0x04/* event is disabled */
#define KN_DETACHED 0x08/* knote is detached */
+ #define KN_MARKER 0x10/* knote is a scan marker */
#define kn_id kn_kevent.ident
#define kn_filter kn_kevent.filter
Index: kern/kern_event.c
===
RCS file: /cvs/src/sys/kern/kern_event.c,v
retrieving revision 1.45
diff -c -r1.45 kern_event.c
*** kern/kern_event.c 17 Aug 2002 02:36:16 - 1.45
--- kern/kern_event.c 5 Oct 2002 15:13:26 -
***
*** 653,658
--- 653,659
FILE_LOCK_ASSERT(fp, MA_NOTOWNED);
+ marker.kn_status = KN_MARKER;
kq = (struct kqueue *)fp-f_data;
count = maxevents;
if (count == 0)
***
*** 713,718
--- 714,727
TAILQ_INSERT_TAIL(kq-kq_head, marker, kn_tqe);
while (count) {
kn = TAILQ_FIRST(kq-kq_head);
+ /*
+* Skip over all markers which are not ours. This looks
+* unsafe, but we can't hit the end of the list without
+* hitting our own marker.
+*/
+ while ((kn-kn_status KN_MARKER) (kn != marker)) {
+ kn = TAILQ_NEXT(kn, kn_tqe);
+ }
TAILQ_REMOVE(kq-kq_head, kn, kn_tqe);
if (kn == marker) {
splx(s);
Re: [ GEOM tests ] disklabel warnings and vinum drives lost
In message [EMAIL PROTECTED], Poul-Henning Kamp writes:
Make that _three_ bugs: vinum opens devices directly at the cdevsw
level, bypassing in the process the vnodes and specfs.
Here is a patch that makes it use vn_open/vn_close/VOP_IOCTL,
bringing it much closer to the way ccd(4) does things. I have only
lightly tested this so far - I saw one problem where a md(4)
vnode-backed device got stuck in mddestroy(), but I haven't tracked
down if that is related (the md vnode was just a file on a vinum-backed
filesystem).
Ian
Index: vinumio.c
===
RCS file: /dump/FreeBSD-CVS/src/sys/dev/vinum/vinumio.c,v
retrieving revision 1.76
diff -u -r1.76 vinumio.c
--- vinumio.c 5 Oct 2002 03:44:00 - 1.76
+++ vinumio.c 5 Oct 2002 14:12:56 -
@@ -51,33 +51,26 @@
open_drive(struct drive *drive, struct thread *td, int verbose)
{
struct nameidata nd;
-struct cdevsw *dsw;/* pointer to
cdevsw entry */
-int error;
+int flags;
if (drive-flags VF_OPEN)/* open already, */
return EBUSY; /* don't do it again */
-NDINIT(nd, LOOKUP, FOLLOW | LOCKLEAF, UIO_SYSSPACE, drive-devicename,
-curthread);
-error = namei(nd);
-if (error)
- return (error);
-if (!vn_isdisk(nd.ni_vp, error)) {
- NDFREE(nd, 0);
- return (error);
-}
-drive-dev = udev2dev(nd.ni_vp-v_rdev-si_udev, 0);
-NDFREE(nd, 0);
-
-if (drive-dev == NULL)/* didn't find anything */
- return ENODEV;
-
-drive-dev-si_iosize_max = DFLTPHYS;
-dsw = devsw(drive-dev);
-if (dsw == NULL)
- drive-lasterror = ENOENT;
-else
- drive-lasterror = (dsw-d_open) (drive-dev, FWRITE | FREAD, 0, NULL);
+drive-devvp = NULL;
+NDINIT(nd, LOOKUP, FOLLOW, UIO_SYSSPACE, drive-devicename, td);
+flags = FREAD | FWRITE;
+drive-lasterror = vn_open(nd, flags, 0);
+if (drive-lasterror == 0) {
+ (void) vn_isdisk(nd.ni_vp, drive-lasterror);
+ if (drive-lasterror != 0 vrefcnt(nd.ni_vp) 1)
+ drive-lasterror = EBUSY;
+ VOP_UNLOCK(nd.ni_vp, 0, td);
+ NDFREE(nd, NDF_ONLY_PNBUF);
+ if (drive-lasterror == 0)
+ drive-devvp = nd.ni_vp;
+ else
+ (void) vn_close(nd.ni_vp, flags, td-td_ucred, td);
+}
if (drive-lasterror != 0) { /* failed */
drive-state = drive_down; /* just force it down */
@@ -85,8 +78,11 @@
log(LOG_WARNING,
vinum open_drive %s: failed with error %d\n,
drive-devicename, drive-lasterror);
-} else
+} else {
+ drive-dev = vn_todev(drive-devvp);
+ drive-dev-si_iosize_max = DFLTPHYS;
drive-flags |= VF_OPEN;/* we're open now */
+}
return drive-lasterror;
}
@@ -145,6 +141,9 @@
int
init_drive(struct drive *drive, int verbose)
{
+struct thread *td;
+
+td = curthread;
if (drive-devicename[0] != '/') {
drive-lasterror = EINVAL;
log(LOG_ERR, vinum: Can't open drive without drive name\n);
@@ -154,17 +153,17 @@
if (drive-lasterror)
return drive-lasterror;
-drive-lasterror = (*devsw(drive-dev)-d_ioctl) (drive-dev,
+drive-lasterror = VOP_IOCTL(drive-devvp,
DIOCGSECTORSIZE,
(caddr_t) drive-sectorsize,
FREAD,
- curthread);
+ td-td_ucred, td);
if (drive-lasterror == 0)
- drive-lasterror = (*devsw(drive-dev)-d_ioctl) (drive-dev,
+ drive-lasterror = VOP_IOCTL(drive-devvp,
DIOCGMEDIASIZE,
(caddr_t) drive-mediasize,
FREAD,
- curthread);
+ td-td_ucred, td);
if (drive-lasterror) {
if (verbose)
log(LOG_WARNING,
@@ -211,14 +210,16 @@
void
close_locked_drive(struct drive *drive)
{
+struct thread *td;
int error;
+td = curthread;
/*
* If we can't access the drive, we can't flush
* the queues, which spec_close() will try to
* do. Get rid of them here first.
*/
-error = (*devsw(drive-dev)-d_close) (drive-dev, 0, 0, NULL);
+error = vn_close(drive-devvp, FREAD | FWRITE, td-td_ucred, td);
drive-flags = ~VF_OPEN; /* no longer open */
if (drive-lasterror == 0)
drive-lasterror = error;
@@ -561,11 +562,13 @@
int error;
int written_config;/* set when we
first write the config to disk */
int driveno;
+struct thread *td;
struct drive *drive; /* point to current drive
info */
struct vinum_hdr *vhdr;/* and as header */
char *config; /*
Re: HEADSUP! GEOM as default in 5 days... GEOM does not find da0a;goes to rootmount
On Sat, 5 Oct 2002, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Daniel Flickinger writes:
I will note that my loader is dated 27 Sep since there
has not been an even close to complete buildworld since
then;
Something in your tree is not OK then, because I have compiled
buildworld many times since the 27th, last time just a few
hours ago:
cd /bang/src make buildworld TARGET_ARCH=i386 __MAKE_CONF=/dev/null \
_.i386.buildworld 21
i386 buildworld ended on Sat Oct 5 07:31:09 GMT 2002
The problem with the floppy drive is interesting, I guess it means
that the SCSI da driver return EBUSY to mean no media rather
than ENXIO as it should.
No, it returns ENXIO. For a details, see sys/cam/scsi/scsi_all.c:
/* DTL WRSOM*/{SST(0x3A, 0x00, SS_FATAL|ENXIO,
Medium not present) },
/* DT WR OM*/{SST(0x3A, 0x01, SS_FATAL|ENXIO,
Medium not present - tray closed) },
/* DT WR OM*/{SST(0x3A, 0x02, SS_FATAL|ENXIO,
Medium not present - tray open) },
Does your system work without the Zip drive plugged in?
-Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: i386 tinderbox failure
On Sat, 5 Oct 2002, Poul-Henning Kamp wrote: It was my impression that people were trying to solve this issue so that mcd can coexist with GEOM properly. Indeed. I'm still working on removing the disklabel bits from mcd(4). I'll bandaid mcd_isa.c in the meantime. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
The official GEOM is in the tree speech.
Ok, we've reached a milestone which have been on the radar for 8½ years, at least for some of us: GEOM is far from done yet, but unless I have overlooked something, it now meets and in may areas exceeds the capabilities of the previous code, and therefore the time is ripe for the change. Throughout history, there has always been a tradition for rallying the forces with a bit of pep-talk on the eve of a battle, so bear with me if this email gets to be a bit philosphical, but I have some things I want to say to you guys. Times are changing, and the world around us as well. We are no longer a tiny volunteer hobby project, we are now a player in one of the most cut-throat businesses on the planet, next only to narcotics (legal and medical) and weapons. Remember that. Just as well as the rest of the old-timers, I remember how UNIX used to run on 16 bit computers, the simplicity, the elegance and all that which we fell in love with. And I still admire the people who made that possible. Our job, and our challenge, is to continue the tradition they started, standing on their shoulders, reaching forever higher. Freezing time, sticking to traditions, or sticking to standards which try reduce diversity and thereby inovation, is not what the way to do that, neither is sailing out across the wide blue ocean without map and compas. Operating systems, just as people, are a product of their time, and if they stop innovating, fail to develop with the world around then, they will stagnate, and die. Our task is to stay alive and kicking, our challenge is to be ahead of our time and the rest of the pack. And that is the first point I would like to make: If it wasn't for the bikeshed it would produce, I would like to propose that starting right after then 5.0 branch, we rename our HEAD revision from -current to -future. What goes in in current is by nature, and our release cycle, one to two years ahead of our main userbase. We should have in -current what they will be asking for 12 months down the road. Remember that. GEOM is not ahead of the curve like that, infact is is way behind. GEOM should have been put in the tree before ccd(4), before PC98, alpha and in particular before vinum(4). Just like the VFS/Vnode concept or the protocol stack, GEOM is a frame-work, or if you prefer: infrastructure component, meant to make FreeBSD much more able and flexible than it ever were before. Now that GEOM is in the tree, we can clean up the various hacks which were made due to the lack of infrastructure between VNODEs and diskdevices: ccd, vinum, disklabel, diskslice and all that. And we can start to add new functionality using the flexibility and clean architecture it offers us. And that brings me to the next point I want to make: The reason it has taken me 8 years to do it, is mostly that I wanted it done right, not just another quick hack to get it working, and that meant taking the long way rather than a short cut, and it meant paving a couple of new roads because the old ones would not be able to carry the load. Road-construction is never a nice thing, at least not until it is done and over with, but it is a necessary part of the lifecycle. GEOM has been a long journey for me, its been a long journey for you and for all the users as well. There have been fights, there have been disagreement and there have been a lot of hard work. Most of this could probably have been avoided, one way or another, but likely as not, we will never entirely avoid it in a volounteer project spanning the globe. It worries me however, to realize how tough an ass-hole I have had to be, in order to get to stick to the principle of doing things right, rather than just hack it in. The best way to destroy FreeBSD in the long term, is to let our infrastructure rot. Nailing a thing on it here, sticking a cute feature there, making an assumption in this place, it all slowly but surely erodes the strength of the infrastructure. We have a number of features in the kernel which have their merits but which carries a heavy cost on our infrastructure. I have probably better give you a random example here to make sure I don't get misunderstood: UFS snapshots are a cool thing, and I love background fsck as much as the next guy. But in order to be able to implement it, Kirk either had to redo the entire buffer cache/VM system to support the primitives he needed, or he could reach down and stick a wedge in between SPECFS and the disk drivers. If modernizing buf/VM wasn't easy before, this certainly wont make it any easier now. But I don't blame Kirk, he was not out to fix our infrastructure, he was out to add snapshots to UFS. But it is a good example of the price we pay for not having our infrastructure in shape: It gets circumvented, and the price for straigthening it out just increased as a result of that. Circumvent, hack around and disregard the infrastructure, if you need to, but do realize, that is what kills software.
Re: SSE
Daniel Eischen writes: On further reflection, this DEFINITELY has to do with the work done on npx(4)/signals/etc. in the past week. I _must_ be getting a GPF because the fpu state that it's attempting to restore is corrupt (i.e.: the control word is incorrect), so something is not being initialized somewhere that it used to be, or is being initialized incorrectly. The last few commits to machdep.c bother me, rev 1.539 in particular. If you are in a position to be able to quickly test it, it would be great to know if backing out the last few changes fixes this, and which change in particular. There have been two commits since 1.539; what version of machdep.c is being used? 1.539 works. 1.540 crashes. The failure mode is: login: kernel trap 9 with interrupts disabled Fatal trap 9: general protection fault while in kernel mode instruction pointer = 0x8:0xc0348eb9 stack pointer = 0x10:0xdbb9d9c8 frame pointer = 0x10:0xdbb9d9c8 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 607 (nautilus) kernel: type 9 trap, code=0 Stopped at fpurstor+0xf: db Context switches not allowed in the debugger. db t fpurstor(dbb9da90,2f,280e002f,dbb9da90,dbb9d9fc) at fpurstor+0xf npxsetregs(c421a9c0,dbb9da90,200,212,c421a9c0) at npxsetregs+0x34 set_fpcontext(c421a9c0,dbb9da28,2b4,1f,c45a7c08) at set_fpcontext+0xa9 sigreturn(c421a9c0,dbb9dd14,c03a1b89,418,1) at sigreturn+0x1be syscall(2f,2f,2f,2899e100,0) at syscall+0x294 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (344, FreeBSD ELF32, sigreturn), eip = 0x28c8ca07, esp = 0xbfbfeef0, ebp = 0xbfbfef0c --- db Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
kernel panic from vinum during 'restore'
got panic from vinum on a small striped drive with small dump/restores -- dump of usr fs to file and restore to vinum volume. dump file is about 120m. kernel built from about -0230 sources but i've been seeing them since first switched current on about 2 weeks ago. don't currently have the kernel trace for this (i'm rebuilding to get one) and the dump's not making it to disk. perhaps someone else could try and verify in the mean time. +++ kernel panic message +++ panic: kmem_malloc(4096): kmem_map to small: 23179264 total allocated syncing disks... panic: allocbuf: buffer not busy Uptime: 18m12s Dumping 48 MB ata1: resetting devices .. panic: free locked buf Uptime: 18m12s Automatice Reboot in 15 seconds - press a key on the console to abort --- kernel panic message --- +++ vinum config +++ # Vinum configuration of eyore.blahdeblah.demon.co.uk, saved at Sat Oct 5 22:02:24 2002 drive snub device /dev/ad0s1h drive junk device /dev/ad2s1h volume var volume usr volume home volume software plex name var.plex0 org striped 534s vol var plex name usr.plex0 org striped 534s vol usr plex name home.plex0 org striped 534s vol home plex name software.plex0 org striped 534s vol software sd name snub.s0 drive snub plex var.plex0 len 163404s driveoffset 265s plexoffset 0s sd name junk.s0 drive junk plex var.plex0 len 163404s driveoffset 265s plexoffset 534s sd name snub.s1 drive snub plex usr.plex0 len 614100s driveoffset 164105s plexoffset 0s sd name junk.s1 drive junk plex usr.plex0 len 614100s driveoffset 164105s plexoffset 534s sd name snub.s2 drive snub plex home.plex0 len 409578s driveoffset 778505s plexoffset 0s sd name junk.s2 drive junk plex home.plex0 len 409578s driveoffset 778505s plexoffset 534s sd name snub.s3 drive snub plex software.plex0 len 1638312s driveoffset 1188083s plexoffset 0s sd name junk.s3 drive junk plex software.plex0 len 1638312s driveoffset 1188083s plexoffset 534s --- vinum config --- -- t t z msg44044/pgp0.pgp Description: PGP signature
alpha tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- === bin/ln mkdep:Permission denied *** Error code 1 Stop in /h/des/src/bin/ln. *** Error code 1 Stop in /h/des/src/bin. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] vinum drives lost
On Fri, Oct 04, 2002 at 12:44:30PM -0700, Julian Elischer wrote: No, it is established principal tha the importer of new features has the responsibility to make older subsystems work. So when is a KSE person going to fix the libc_r and releng4 binaries problem?? That certainly is old functionality that is broken. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SSE
On Sat, 5 Oct 2002, Andrew Gallatin wrote:
Daniel Eischen writes:
On further reflection, this DEFINITELY has to do with the work done on
npx(4)/signals/etc. in the past week. I _must_ be getting a GPF because the
fpu state that it's attempting to restore is corrupt (i.e.: the control word
is incorrect), so something is not being initialized somewhere that it used
to be, or is being initialized incorrectly.
The last few commits to machdep.c bother me, rev 1.539 in particular.
If you are in a position to be able to quickly test it, it would be great
to know if backing out the last few changes fixes this, and which change in
particular.
There have been two commits since 1.539; what version of machdep.c
is being used?
1.539 works. 1.540 crashes. The failure mode is:
Bruce and I had a miscommunication over the setting of a flag.
It turns out that we can't easily restore the FPU state from
the PCB if the one in the ucontext is bad, anyways. Try the
following patch:
Index: i386/i386/machdep.c
===
RCS file: /opt/d/CVS/src/sys/i386/i386/machdep.c,v
retrieving revision 1.541
diff -u -r1.541 machdep.c
--- i386/i386/machdep.c 5 Oct 2002 14:36:14 - 1.541
+++ i386/i386/machdep.c 5 Oct 2002 20:10:53 -
@@ -,12 +,17 @@
} else {
/*
* There is no valid FPU state in *mcp, so use the saved
-* state in the PCB if there is one. XXX the test for
-* whether there is one seems to be quite broken. We
-* forcibly drop the state in sendsig().
+* state in the PCB if there is one. XXX We can't easily
+* check to see if the state in the PCB is valid or not;
+* there could have been nested signals, and for other
+* reasons. For now, we'll just leave the FPU state
unchanged.
*/
- if ((td-td_pcb-pcb_flags PCB_NPXINITDONE) != 0)
+#if 0
+ if ((td-td_pcb-pcb_flags PCB_NPXINITDONE) == 0)
npxsetregs(td, td-td_pcb-pcb_save);
+#else
+ ; /* in case no compat is defined. */
+#endif
#endif
#if !defined(COMPAT_FREEBSD4) !defined(COMPAT_43)
return (EINVAL);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] vinum drives lost
On Saturday, 5 October 2002 at 15:55:05 +0300, Vallo Kallaste wrote: On Fri, Oct 04, 2002 at 12:45:59PM -0700, Lars Eggert [EMAIL PROTECTED] wrote: Well, the showstopper is in vinum. The fact that ccd(4) works seamlessly with GEOM is testament to this. For some reason I was under the (mis?)impression that ccd was no longer being maintained... If it works with geom, we can probably move our machines over to ccd. They're all no-frills stripes, so ccd functionality is good enough. Some time ago Scott Long pointed out to me that ccd has less overhead than vinum It does? and is better suited for bare striping. It is? I'd be interested in details. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
devfs oddity?
root[208] cdcontrol play cdcontrol: no CD device name specified, defaulting to /dev/cd0c cdcontrol: /dev/cd0cc: No such file or directory Why is an extra c appended to cd0c? -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs oddity?
In message [EMAIL PROTECTED], Steve Kargl w rites: root[208] cdcontrol play cdcontrol: no CD device name specified, defaulting to /dev/cd0c cdcontrol: /dev/cd0cc: No such file or directory Why is an extra c appended to cd0c? That's not devfs, that's cdcontrol. It should be fixed to use /dev/cd0 and not try to append 'c', there are not, and have probably never been BSD disklabels on enough disks to warrant this hack. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel panic from vinum during 'restore'
On Saturday, 5 October 2002 at 22:16:10 +0100, n0g0013 wrote: got panic from vinum on a small striped drive with small dump/restores -- dump of usr fs to file and restore to vinum volume. dump file is about 120m. kernel built from about -0230 sources but i've been seeing them since first switched current on about 2 weeks ago. don't currently have the kernel trace for this (i'm rebuilding to get one) and the dump's not making it to disk. perhaps someone else could try and verify in the mean time. This looks like a resource error, possibly a memory leak. Do you have a message like this in the log files? vinum: can't allocate table space to trace memory allocation In any case, it would be interesting to see Vinum's memory statistics after the crash, if you get another one. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs oddity?
On Sun, Oct 06, 2002 at 12:19:46AM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Steve Kargl w rites: root[208] cdcontrol play cdcontrol: no CD device name specified, defaulting to /dev/cd0c cdcontrol: /dev/cd0cc: No such file or directory Why is an extra c appended to cd0c? That's not devfs, that's cdcontrol. It should be fixed to use /dev/cd0 and not try to append 'c', there are not, and have probably never been BSD disklabels on enough disks to warrant this hack. Okay. This just started with a kernel built from sources of Friday vintage (without GEOM). My previous kernel from Sun Sep 8 08:53:47 PDT 2002 does not have this problem. Building and running a kernel in the the time between and Sep 8 and new has been an adventure. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SSE
Daniel Eischen writes: 1.539 works. 1.540 crashes. The failure mode is: Bruce and I had a miscommunication over the setting of a flag. It turns out that we can't easily restore the FPU state from the PCB if the one in the ucontext is bad, anyways. Try the following patch: Still crashes. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: The official GEOM is in the tree speech.
For those of us who scan the -current mailing list from time to time but don't actually run current, is there a description somewhere of what GEOM *is*? -- Richard To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: The official GEOM is in the tree speech.
On Sat, Oct 05, 2002 at 11:49:58PM +0100, Richard Tobin wrote: For those of us who scan the -current mailing list from time to time but don't actually run current, is there a description somewhere of what GEOM *is*? The manpage is online: http://www.freebsd.org/cgi/man.cgi?query=geomapropos=0sektion=0manpath=FreeBSD+5.0-currentformat=html -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg44055/pgp0.pgp Description: PGP signature
Re: devfs oddity?
On Sat, Oct 05, 2002 at 03:39:47PM -0700, Steve Kargl wrote:
On Sun, Oct 06, 2002 at 12:19:46AM +0200, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Steve Kargl w
rites:
root[208] cdcontrol play
cdcontrol: no CD device name specified, defaulting to /dev/cd0c
cdcontrol: /dev/cd0cc: No such file or directory
Why is an extra c appended to cd0c?
That's not devfs, that's cdcontrol.
It should be fixed to use /dev/cd0 and not try to append 'c',
there are not, and have probably never been BSD disklabels
on enough disks to warrant this hack.
Okay. This just started with a kernel built from
sources of Friday vintage (without GEOM). My previous
kernel from Sun Sep 8 08:53:47 PDT 2002 does not have
this problem. Building and running a kernel in the
the time between and Sep 8 and new has been an adventure.
This appears to fix the problem.
--
Steve
--- cdcontrol.c.origSat Oct 5 16:05:23 2002
+++ cdcontrol.c Sat Oct 5 16:07:36 2002
@@ -51,11 +51,7 @@
#define ASTS_VOID 0x15 /* No current audio status to return */
#ifndef DEFAULT_CD_DRIVE
-# define DEFAULT_CD_DRIVE /dev/cd0c
-#endif
-
-#ifndef DEFAULT_CD_PARTITION
-# define DEFAULT_CD_PARTITION c
+# define DEFAULT_CD_DRIVE /dev/cd0
#endif
#define CMD_DEBUG 1
@@ -1249,11 +1245,6 @@
}
fd = open (devbuf, O_RDONLY);
-
- if (fd 0 errno == ENOENT) {
- strcat (devbuf, DEFAULT_CD_PARTITION);
- fd = open (devbuf, O_RDONLY);
- }
if (fd 0) {
if (errno == ENXIO) {
--- cdcontrol.1.origSat Oct 5 16:07:57 2002
+++ cdcontrol.1 Sat Oct 5 16:08:53 2002
@@ -37,15 +37,13 @@
Print as much information as possible.
.It Fl f Ar device
Specify a device, such as
-.Pa /dev/cd0c
+.Pa /dev/cd0
or
.Pa mcd0 .
Both absolute path and relative to
.Pa /dev
filename are possible.
Suffix
-.Pa c
-is added to the device name if needed.
.El
.Pp
The available commands are listed below.
@@ -183,10 +181,10 @@
.Ev CDROM .
.El
.Sh FILES
-.Bl -tag -width .Pa /dev/mcd0c -compact
-.It Pa /dev/cd0c
-.It Pa /dev/mcd0c
-.It Pa /dev/acd0c
+.Bl -tag -width .Pa /dev/mcd0 -compact
+.It Pa /dev/cd0
+.It Pa /dev/mcd0
+.It Pa /dev/acd0
.El
.Sh AUTHORS
.An Jean-Marc Zucconi
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: make buildworld fails during stage 4, libpcap
On Sun, 2002-10-06 at 02:21, Ruslan Ermilov wrote: Should work. Check that you have the latest $FreeBSD: src/sys/net/bpf.h,v 1.26 2002/06/21 05:29:40 fenner Exp $ No. I don't. And it's possibly because I am updating from a mirror? (cvsup.au.freebsd.org). Sorry. Should have checked that. cheers, Will To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: The official GEOM is in the tree speech.
On 05.10-23:49, Richard Tobin wrote: For those of us who scan the -current mailing list from time to time but don't actually run current, is there a description somewhere of what GEOM *is*? http://docs.FreeBSD.org/44doc/papers/bufbio/bio.html it's involved in the implementation above the implications but the diagrams are illustrative, although i'm not sure if they are in the html version -- postscript is also in the above location though. -- t t z msg44058/pgp0.pgp Description: PGP signature
Re: The official GEOM is in the tree speech.
PHK, I salute you! -- Hiten --- Poul-Henning Kamp [EMAIL PROTECTED] wrote: Ok, we've reached a milestone which have been on the radar for 8½ years, at least for some of us: GEOM is far from done yet, but unless I have overlooked something, it now meets and in may areas exceeds the capabilities of the previous code, and therefore the time is ripe for the change. Throughout history, there has always been a tradition for rallying the forces with a bit of pep-talk on the eve of a battle, so bear with me if this email gets to be a bit philosphical, but I have some things I want to say to you guys. Times are changing, and the world around us as well. We are no longer a tiny volunteer hobby project, we are now a player in one of the most cut-throat businesses on the planet, next only to narcotics (legal and medical) and weapons. Remember that. Just as well as the rest of the old-timers, I remember how UNIX used to run on 16 bit computers, the simplicity, the elegance and all that which we fell in love with. And I still admire the people who made that possible. Our job, and our challenge, is to continue the tradition they started, standing on their shoulders, reaching forever higher. Freezing time, sticking to traditions, or sticking to standards which try reduce diversity and thereby inovation, is not what the way to do that, neither is sailing out across the wide blue ocean without map and compas. Operating systems, just as people, are a product of their time, and if they stop innovating, fail to develop with the world around then, they will stagnate, and die. Our task is to stay alive and kicking, our challenge is to be ahead of our time and the rest of the pack. And that is the first point I would like to make: If it wasn't for the bikeshed it would produce, I would like to propose that starting right after then 5.0 branch, we rename our HEAD revision from -current to -future. What goes in in current is by nature, and our release cycle, one to two years ahead of our main userbase. We should have in -current what they will be asking for 12 months down the road. Remember that. GEOM is not ahead of the curve like that, infact is is way behind. GEOM should have been put in the tree before ccd(4), before PC98, alpha and in particular before vinum(4). Just like the VFS/Vnode concept or the protocol stack, GEOM is a frame-work, or if you prefer: infrastructure component, meant to make FreeBSD much more able and flexible than it ever were before. Now that GEOM is in the tree, we can clean up the various hacks which were made due to the lack of infrastructure between VNODEs and diskdevices: ccd, vinum, disklabel, diskslice and all that. And we can start to add new functionality using the flexibility and clean architecture it offers us. And that brings me to the next point I want to make: The reason it has taken me 8 years to do it, is mostly that I wanted it done right, not just another quick hack to get it working, and that meant taking the long way rather than a short cut, and it meant paving a couple of new roads because the old ones would not be able to carry the load. Road-construction is never a nice thing, at least not until it is done and over with, but it is a necessary part of the lifecycle. GEOM has been a long journey for me, its been a long journey for you and for all the users as well. There have been fights, there have been disagreement and there have been a lot of hard work. Most of this could probably have been avoided, one way or another, but likely as not, we will never entirely avoid it in a volounteer project spanning the globe. It worries me however, to realize how tough an ass-hole I have had to be, in order to get to stick to the principle of doing things right, rather than just hack it in. The best way to destroy FreeBSD in the long term, is to let our infrastructure rot. Nailing a thing on it here, sticking a cute feature there, making an assumption in this place, it all slowly but surely erodes the strength of the infrastructure. We have a number of features in the kernel which have their merits but which carries a heavy cost on our infrastructure. I have probably better give you a random example here to make sure I don't get misunderstood: UFS snapshots are a cool thing, and I love background fsck as much as the next guy. But in order to be able to implement it, Kirk either had to redo the entire buffer cache/VM system to support the primitives he needed, or he could reach down and stick a wedge in between SPECFS and the disk drivers. If modernizing buf/VM wasn't easy before, this certainly wont make it any easier now. But I don't blame Kirk, he was not out to fix our infrastructure, he was out to add snapshots to UFS. But it is a good example of the price we pay for not having our infrastructure in shape: It gets circumvented, and
Re: The official GEOM is in the tree speech.
On Sat, 5 Oct 2002, Poul-Henning Kamp wrote: Ok, we've reached a milestone which have been on the radar for 8½ years, at least for some of us: Wow! Thats determination :) Our task is to stay alive and kicking, our challenge is to be ahead of our time and the rest of the pack. And that is the first point I would like to make: If it wasn't for the bikeshed it would produce, I would like to propose that starting right after then 5.0 branch, we rename our HEAD revision from -current to -future. What goes in in current is by nature, and our release cycle, one to two years ahead of our main userbase. We should have in -current what they will be asking for 12 months down the road. As a simple user and already busy sysadmin this is good to hear. It really is nice to know that there are really smart folks out there expending lots of their own making FreeBSD an even better OS than it already is. And that brings me to the next point I want to make: It worries me however, to realize how tough an ass-hole I have had to be, in order to get to stick to the principle of doing things right, rather than just hack it in. The best way to destroy FreeBSD in the long term, is to let our infrastructure rot. I certainly agree with the above point. I'm mainly just a lurker here, but I've been watching the little battles being fought here and there, each of us trying to steer FreeBSD towards our own ideals. However GEOM seems to be regarded generally as right thing to do. For all of Poul-Hennings hard work I personally would like to congratulate him. He certainly is braver than me asking smart hackers world wide to modify their code to suit. However I have the following thing to say in this regard. The thing that first struck me about FreeBSD and the thing that has kept me using FreeBSD is the generally complete thinking about pieces of code. FreeBSD seems to me to be more well-balanced, cleaner and faster than other OSs other there. And it must be due to core infrustructure like this that helps keep it that way. Hence all I can really do is to implore the rest of the developers out there to consider the above and to help keep FreeBSD, mean, lean and rot free? :) Finally, on a personal note Peters commitstats say I have been committing to the kernel on average every 16 hours for the last year. It feels that way too. Once again, my thanks to phk and the rest of the FreeBSD hackers out there for all their hard work. And now is the time for me to shut up, and for time and practical experience will have to judge if I delivered on the promises I made along the way. Thanks for listening, Always, it's always amazing what you can learn. Like who is Zilog Zeus? :) - byron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: The official GEOM is in the tree speech.
So I guess you want to change the behavior of sort to be POSIX... :P On Sat, 5 Oct 2002, Poul-Henning Kamp wrote: Ok, we've reached a milestone which have been on the radar for 8½ years, at least for some of us: GEOM is far from done yet, but unless I have overlooked something, it now meets and in may areas exceeds the capabilities of the previous code, and therefore the time is ripe for the change. Throughout history, there has always been a tradition for rallying the forces with a bit of pep-talk on the eve of a battle, so bear with me if this email gets to be a bit philosphical, but I have some things I want to say to you guys. get misunderstood: -- _ __ ___ ___ ___ ___ Wesley N Morgan _ __ ___ | _ ) __| \ [EMAIL PROTECTED] _ __ | _ \._ \ |) | FreeBSD: The Power To Serve _ |___/___/___/ Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: snapshots.jp.freebsd.org -- 15 days of problems
attila If it reaches this far, both the 'livetree' and 'obj' attila trees would be available. Good idea, I'll try it later. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] vinum drives lost
On Sat, 5 Oct 2002, David O'Brien wrote: On Fri, Oct 04, 2002 at 12:44:30PM -0700, Julian Elischer wrote: No, it is established principal tha the importer of new features has the responsibility to make older subsystems work. So when is a KSE person going to fix the libc_r and releng4 binaries problem?? That certainly is old functionality that is broken. Firstly, I'm not sure, as it's I can only take Dan's eworkd on it, but releng-4 binaries should be working again now. Secondly The person who broke it (not me BTW) has been chastised severely and has had a life-long learning experience. He is working hard on fixing it properly (But is not being helped by the fact hat his job changed and he has to move towns). Dan, (Mr libc_r) is working in it too, and AS THE MAIN MAINTAINER of libc_r he is not someone that I can beat on when it comes to libc_r. If he says it's fixed I have to believe him. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
GEOM problems?
Just finished making world and kernel at about 01:00 GMT Oct 6. dmesg includes this printout: Initializing GEOMetry subsystem ad0: 76319MB ST380021A [155061/16/63] at ata0-master UDMA100 ad2: 42934MB WDC WD450AA-00BAA0 [87233/16/63] at ata1-master UDMA66 acd0: CD-RW R/RW 4x4x24 at ata1-slave PIO4 Mounting root from ufs:/dev/ad2s2a 00 01 c1 ff 83 fe ff ff 3f 00 00 00 06 5b 5f 00 |?[_.| [0] f:00 typ:131 s(CHS):255/1/193 e(CHS):255/254/255 s:63 l:6249222 00 00 c1 ff 05 fe ff ff 45 5b 5f 00 b3 f1 5a 00 |E[_...Z.| [1] f:00 typ:5 s(CHS):255/0/193 e(CHS):255/254/255 s:6249285 l:5960115 00 01 c1 ff 07 fe ff ff 3f 00 00 00 74 f1 5a 00 |?...t.Z.| [0] f:00 typ:7 s(CHS):255/1/193 e(CHS):255/254/255 s:63 l:5960052 00 00 c1 ff 05 fe ff ff f8 4c ba 00 e2 05 18 00 |.L..| [1] f:00 typ:5 s(CHS):255/0/193 e(CHS):255/254/255 s:12209400 l:1574370 many more lines snipped Is this normal output now? And there's this: #disklabel ad0 disklabel: ioctl DIOCGDINFO: Operation not supported by device #disklabel -r ad0 disklabel: bad pack magic number (label is damaged, or pack is unlabeled) Same errors with ad2. All the partitions do mount and seem to work OK, so I'm not sure how much of this is expected behavior. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
make linux_base error during rpm
hi,all: getting the following error messages during rpm. thanks any info. === Building for rpm-3.0.6_6 gmake all-recursive gmake[1]: Entering directory `/usr/ports/archivers/rpm/work/rpm-3.0.6' Making all in intl gmake[2]: Entering directory `/usr/ports/archivers/rpm/work/rpm-3.0.6/intl' gmake[2]: Nothing to be done for `all'. gmake[2]: Leaving directory `/usr/ports/archivers/rpm/work/rpm-3.0.6/intl' Making all in po gmake[2]: Entering directory `/usr/ports/archivers/rpm/work/rpm-3.0.6/po' gmake[2]: Leaving directory `/usr/ports/archivers/rpm/work/rpm-3.0.6/po' Making all in lib gmake[2]: Entering directory `/usr/ports/archivers/rpm/work/rpm-3.0.6/lib' /bin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../build -I../misc -I/usr/local/include -I/usr/local/include -O -pipe -mcpu=pentiumpro -D_GNU_SOURCE -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wno-char-subscripts -c rpmio.c rm -f .libs/rpmio.lo cc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../build -I../misc -I/usr/local/include -I/usr/local/include -O -pipe -mcpu=pentiumpro -D_GNU_SOURCE -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wno-char-subscripts -c rpmio.c -fPIC -DPIC -o .libs/rpmio.lo In file included from ../system.h:184, from rpmio.c:1: /usr/local/include/getopt.h:115: warning: function declaration isn't a prototypeIn file included from rpmio.c:17: /usr/include/machine/types.h:50: redefinition of `vm_offset_t' /usr/include/sys/types.h:160: `vm_offset_t' previously declared here /usr/include/machine/types.h:51: redefinition of `vm_ooffset_t' /usr/include/sys/types.h:161: `vm_ooffset_t' previously declared here /usr/include/machine/types.h:52: conflicting types for `vm_pindex_t' /usr/include/sys/types.h:162: previous declaration of `vm_pindex_t' /usr/include/machine/types.h:53: redefinition of `vm_size_t' /usr/include/sys/types.h:163: `vm_size_t' previously declared here /usr/include/machine/types.h:55: redefinition of `register_t' /usr/include/sys/types.h:150: `register_t' previously declared here /usr/include/machine/types.h:56: redefinition of `u_register_t' /usr/include/sys/types.h:153: `u_register_t' previously declared here rpmio.c: In function `fdSeek': rpmio.c:589: warning: long int format, different type arg (arg 4) rpmio.c: In function `gzdSeek': rpmio.c:2279: warning: long int format, different type arg (arg 4) rpmio.c: In function `vfs_parse_ls_lga': rpmio.c:3481: warning: comparison is always false due to limited range of data type gmake[2]: *** [rpmio.lo] Error 1 gmake[2]: Leaving directory `/usr/ports/archivers/rpm/work/rpm-3.0.6/lib' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/archivers/rpm/work/rpm-3.0.6' gmake: *** [all-recursive-am] Error 2 *** Error code 2 Stop in /usr/ports/archivers/rpm. *** Error code 1 Stop in /usr/ports/emulators/linux_base. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
how to change root passwd under current
as title
èR{.nÇ+·¬zwfj)m¢f£¢·hkyàRàÂ+aº{.nÇ+·ç±×.®·§¶)í
æèw* ¶¦zË
Re: SSE
Andrew Gallatin wrote: Daniel Eischen writes: On further reflection, this DEFINITELY has to do with the work done on npx(4)/signals/etc. in the past week. I _must_ be getting a GPF becau se the fpu state that it's attempting to restore is corrupt (i.e.: the contro l word is incorrect), so something is not being initialized somewhere that it used to be, or is being initialized incorrectly. The last few commits to machdep.c bother me, rev 1.539 in particular. If you are in a position to be able to quickly test it, it would be grea t to know if backing out the last few changes fixes this, and which change in particular. There have been two commits since 1.539; what version of machdep.c is being used? 1.539 works. 1.540 crashes. The failure mode is: My apologies, I meant 1.540 (really :-). I suspect it might be time to give up and do the alternative sigtrap and sigreturn. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
buildworld failure at /usr/src/sbin/atm/ilmid
I didnt see a recent commit to atm havent been able to buildworld all day. (Oct 05) -M /usr/src/sbin/atm/ilmid/ilmid.c:1833: warning: passing arg 0 of `get_local_ip' from incompatible pointer type In file included from /usr/src/sbin/atm/ilmid/ilmid.c:2328: /usr/src/sbin/atm/ilmid/ilmid.c: In function `ilmi_do_state': /usr/src/sbin/atm/ilmid/ilmid.c:1074: warning: passing arg 0 of `oid_ncmp' from incompatible pointer type /usr/src/sbin/atm/ilmid/ilmid.c:1074: warning: passing arg 0 of `oid_ncmp' from incompatible pointer type In file included from /usr/src/sbin/atm/ilmid/ilmid.c:2384: /usr/src/sbin/atm/ilmid/ilmid.c:1074: warning: passing arg 0 of `oid_ncmp' from incompatible pointer type /usr/src/sbin/atm/ilmid/ilmid.c:1074: warning: passing arg 0 of `oid_ncmp' from incompatible pointer type In file included from /usr/src/sbin/atm/ilmid/ilmid.c:2425: /usr/src/sbin/atm/ilmid/ilmid.c:1074: warning: passing arg 0 of `oid_ncmp' from incompatible pointer type /usr/src/sbin/atm/ilmid/ilmid.c:1074: warning: passing arg 0 of `oid_ncmp' from incompatible pointer type *** Error code 1 Stop in /usr/src/sbin/atm/ilmid. *** Error code 1 Stop in /usr/src/sbin/atm. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make linux_base error during rpm
On Sun, Oct 06, 2002 at 09:37:17AM +0800, suken woo wrote: hi,all: getting the following error messages during rpm. thanks any info. There was a patch posted here a few months ago for this. I have no idea why no-one has committed it yet. kris msg44069/pgp0.pgp Description: PGP signature
Re: how to change root passwd under current
On Sun, Oct 06, 2002 at 09:38:19AM +0800, wsk wrote: as title as in 4.x msg44070/pgp0.pgp Description: PGP signature
Re: how to change root passwd under current
* De: wsk [EMAIL PROTECTED] [ Data: 2002-10-05 ] [ Subjecte: how to change root passwd under current ] as title If you're having trouble doing it the normal way (passwd(1)), and are doing it via sysinstall(8), it may have to do with a previous issue about which FD the prompt for a password went to, but that has been corrected in recent -current. -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
gnome2 make install failure help
get the following errmsg . help , please cc -O -pipe -mcpu=pentiumpro -g -Wall -Wpointer-arith -Wmissing-prototypes -Wmissing-declarations -o gdmaskpass gdmaskpass.o -lintl -liconv -lpam -L/usr/local/lib -liconv /usr/libexec/elf/ld: Dwarf Error: Invalid or unhandled FORM value: 14. gdmaskpass.o:/usr/ports/x11/gdm2/work/gdm-2.4.0.11/utils/gdmaskpass.c:18: undefined reference to `misc_conv' gmake[2]: *** [gdmaskpass] Error 1 gmake[2]: Leaving directory `/usr/ports/x11/gdm2/work/gdm-2.4.0.11/utils' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/x11/gdm2/work/gdm-2.4.0.11' gmake: *** [all-recursive-am] Error 2 *** Error code 2 Stop in /usr/ports/x11/gdm2. *** Error code 1 Stop in /usr/ports/x11/gnome2. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make linux_base error during rpm
On Sat, 5 Oct 2002 20:12:51 -0700 Kris Kennaway [EMAIL PROTECTED] wrote: On Sun, Oct 06, 2002 at 09:37:17AM +0800, suken woo wrote: hi,all: getting the following error messages during rpm. thanks any info. There was a patch posted here a few months ago for this. I have no idea why no-one has committed it yet. kris It has been committed, and makes it build just fine for me... (FreeBSD cheshire.blacktabby.org 5.0-CURRENT FreeBSD 5.0-CURRENT #5: Sun Sep 8 18:42:41 PDT 2002) See: http://www.freebsd.org/cgi/cvsweb.cgi/ports/archivers/rpm/files/patch-misc%3a%3aglob.h -Adam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gnome2 make install failure help
On Sat, 2002-10-05 at 23:42, suken woo wrote: get the following errmsg . help , please cc -O -pipe -mcpu=pentiumpro -g -Wall -Wpointer-arith -Wmissing-prototypes -Wmissing-declarations -o gdmaskpass gdmaskpass.o -lintl -liconv -lpam -L/usr/local/lib -liconv /usr/libexec/elf/ld: Dwarf Error: Invalid or unhandled FORM value: 14. gdmaskpass.o:/usr/ports/x11/gdm2/work/gdm-2.4.0.11/utils/gdmaskpass.c:18: undefined reference to `misc_conv' gmake[2]: *** [gdmaskpass] Error 1 gmake[2]: Leaving directory `/usr/ports/x11/gdm2/work/gdm-2.4.0.11/utils' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/x11/gdm2/work/gdm-2.4.0.11' gmake: *** [all-recursive-am] Error 2 *** Error code 2 Stop in /usr/ports/x11/gdm2. *** Error code 1 Stop in /usr/ports/x11/gnome2. Delete /usr/include, then do a make installworld from /usr/src. Afterwards, you'll be able to build gdm2 without problem. Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- PGP Key : http://www.marcuscom.com/pgp.asc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SSE
[ CC list trimmed ] On Sat, 5 Oct 2002, Andrew Gallatin wrote: Daniel Eischen writes: 1.539 works. 1.540 crashes. The failure mode is: Bruce and I had a miscommunication over the setting of a flag. It turns out that we can't easily restore the FPU state from the PCB if the one in the ucontext is bad, anyways. Try the following patch: Still crashes. Do you have COMPAT_FREEBSD4 or COMPAT_43? -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make linux_base error during rpm
At 9:37 AM +0800 10/6/02, suken woo wrote: hi,all: getting the following error messages during rpm. thanks any info. === Building for rpm-3.0.6_6 gmake[1]: Leaving directory `/usr/ports/archivers/rpm/work/rpm-3.0.6' gmake: *** [all-recursive-am] Error 2 *** Error code 2 Stop in /usr/ports/archivers/rpm. *** Error code 1 Stop in /usr/ports/emulators/linux_base. How recent is your snapshot of freebsd-current? How recent is your ports-tree? I rebuilt both rpm and linux_base on Oct 2nd, and they both built fine at that time. That would have been with a freebsd-current which was built on Sept 29th. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make linux_base error during rpm
On Sat, Oct 05, 2002 at 08:36:48PM -0700, Adam Kranzel wrote: It has been committed, and makes it build just fine for me... OK, ignore my previous mail then. Kris msg44077/pgp0.pgp Description: PGP signature
Re: make linux_base error during rpm
On Sat, 5 Oct 2002 21:27:07 -0700 Kris Kennaway [EMAIL PROTECTED] wrote: On Sat, Oct 05, 2002 at 08:36:48PM -0700, Adam Kranzel wrote: It has been committed, and makes it build just fine for me... OK, ignore my previous mail then. Kris I'm doing some testing, and will report back in a bit. It's possible I have something weird going on that's making it work. -Adam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs oddity?
On Sat, 5 Oct 2002, Steve Kargl wrote: In message [EMAIL PROTECTED], Steve Kargl w rites: root[208] cdcontrol play cdcontrol: no CD device name specified, defaulting to /dev/cd0c cdcontrol: /dev/cd0cc: No such file or directory Why is an extra c appended to cd0c? The first c is part of the standard name for the whole of a (labelled) disk device. phk is busily breaking this standard. The second c is because cdcontrol tries tacking on a c in case the user forgot it. Here the user didn't specify a device name, so the default of cd0c was tried, and since that was broken recently, it doesn't work, and a c is tacked on to it. The user can work around this easily enough by specifying the device, except in the !DEVFS case when the device doesn't exist. Okay. This just started with a kernel built from sources of Friday vintage (without GEOM). My previous kernel from Sun Sep 8 08:53:47 PDT 2002 does not have this problem. Building and running a kernel in the the time between and Sep 8 and new has been an adventure. This is because rev.1.62 of scsi_cd.c axed labelling support. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PCI problems with today's current
On Sat, Oct 05, 2002 at 12:09:47 +0900, Mitsuru IWASAKI wrote: Hi, Will the patches you just checked in possibly fix the problem? If so, I'll cvsup and try them out. 99.999%, Yes. Cool! I'll cvsup and try it out. If still NG, please try the attached patch against SupermicroP3TDE6.asl. # _BBN is bridge bus number, my guess is 0x3. You can try to change it # if failed. Then please generate DSDT file and orverride DSDT at kernel boot. You can find detail procedures in acpi(4) 'OVERRIDING YOUR BIOS BYTECODE'. I tried the patches you checked in, and PCI bus 2 on my machine still isn't probed. See the attached dmesg. I'm a bit confused about just what sort of file the ACPI code expects to load on boot. I installed the acpicatools port, so I've got iasl(1), but it appears to have 4 output modes (C or assembly source, C or assembly hex table), at least for AML output (which acpi(4) says is what you need to load), and no output modes for DSDT files. acpidump doesn't appear to have a way to turn ASL files into DSDT files, either. In any case, when I run iasl (with the C source option) on the .asl file with your patch, I get a number of errors, although I still get an output file. Can you shed some light on this? Ken -- Kenneth Merry [EMAIL PROTECTED] Copyright (c) 1992-2002 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 #0: Sat Oct 5 22:07:54 MDT 2002 [EMAIL PROTECTED]:/usr/home/ken/perforce/FreeBSD-ken/src/sys/i386/compile/gondolin Preloaded elf kernel /boot/kernel/kernel at 0xc056a000. Preloaded elf module /boot/kernel/acpi.ko at 0xc056a0a8. Timecounter i8254 frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (1266.06-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6b1 Stepping = 1 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 2684289024 (2621376K bytes) avail memory = 2602590208 (2541592K bytes) Programming 16 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 Programming 16 pins in IOAPIC #1 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 4, version: 0x000f0011, at 0xfec0 io1 (APIC): apic id: 5, version: 0x000f0011, at 0xfec01000 Pentium Pro MTRR support enabled ACPI-0623: *** Warning: Type override - [DEB_] had invalid type (Integer) for Scope operator, changed to (Scope) ACPI-0623: *** Warning: Type override - [MLIB] had invalid type (Integer) for Scope operator, changed to (Scope) ACPI-0623: *** Warning: Type override - [IO__] had invalid type (Integer) for Scope operator, changed to (Scope) ACPI-0623: *** Warning: Type override - [DATA] had invalid type (String) for Scope operator, changed to (Scope) ACPI-0623: *** Warning: Type override - [SIO_] had invalid type (String) for Scope operator, changed to (Scope) ACPI-0623: *** Warning: Type override - [SB__] had invalid type (String) for Scope operator, changed to (Scope) ACPI-0623: *** Warning: Type override - [PM__] had invalid type (String) for Scope operator, changed to (Scope) ACPI-0623: *** Warning: Type override - [ICNT] had invalid type (String) for Scope operator, changed to (Scope) ACPI-0623: *** Warning: Type override - [ACPI] had invalid type (String) for Scope operator, changed to (Scope) ACPI-0623: *** Warning: Type override - [OSB4] had invalid type (String) for Scope operator, changed to (Scope) ACPI-0623: *** Warning: Type override - [PM__] had invalid type (String) for Scope operator, changed to (Scope) ACPI-0623: *** Warning: Type override - [BIOS] had invalid type (Integer) for Scope operator, changed to (Scope) ACPI-0623: *** Warning: Type override - [CMOS] had invalid type (Integer) for Scope operator, changed to (Scope) npx0: math processor on motherboard npx0: INT 16 interface acpi0: RCCRCCNILE on motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-safe frequency 3579545 Hz Using $PIR table, 10 entries at 0xc00f52e0 acpi_timer0: 32-bit timer at 3.579545MHz port 0x508-0x50b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu1: CPU on acpi0 acpi_cpu2: CPU on acpi0 acpi_cpu3: CPU on acpi0 acpi_button0: Sleep Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 initial configuration before setting priority for links before fixup boot-disabled links - after fixup boot-disabled links -- arbitrated configuration - pci0: ACPI PCI bus on pcib0 IOAPIC #1 intpin 10 - irq 2 IOAPIC #1 intpin 11 - irq 5 IOAPIC #1 intpin 15 - irq 9 pcib1: ACPI PCI-PCI bridge at device 0.1 on pci0 initial
Re: GEOM problems?
walt [EMAIL PROTECTED] wrote:
Just finished making world and kernel at about 01:00 GMT Oct 6.
dmesg includes this printout:
Initializing GEOMetry subsystem
ad0: 76319MB ST380021A [155061/16/63] at ata0-master UDMA100
ad2: 42934MB WDC WD450AA-00BAA0 [87233/16/63] at ata1-master UDMA66
acd0: CD-RW R/RW 4x4x24 at ata1-slave PIO4
Mounting root from ufs:/dev/ad2s2a
00 01 c1 ff 83 fe ff ff 3f 00 00 00 06 5b 5f 00 |?[_.|
[0] f:00 typ:131 s(CHS):255/1/193 e(CHS):255/254/255 s:63 l:6249222
00 00 c1 ff 05 fe ff ff 45 5b 5f 00 b3 f1 5a 00 |E[_...Z.|
[1] f:00 typ:5 s(CHS):255/0/193 e(CHS):255/254/255 s:6249285 l:5960115
00 01 c1 ff 07 fe ff ff 3f 00 00 00 74 f1 5a 00 |?...t.Z.|
[0] f:00 typ:7 s(CHS):255/1/193 e(CHS):255/254/255 s:63 l:5960052
00 00 c1 ff 05 fe ff ff f8 4c ba 00 e2 05 18 00 |.L..|
[1] f:00 typ:5 s(CHS):255/0/193 e(CHS):255/254/255 s:12209400 l:1574370
many more lines snipped
Is this normal output now?
Sounds like debugging prints that should probably not be enabled by
default...
And there's this:
#disklabel ad0
disklabel: ioctl DIOCGDINFO: Operation not supported by device
#disklabel -r ad0
disklabel: bad pack magic number (label is damaged, or pack is unlabeled)
Same errors with ad2.
All the partitions do mount and seem to work OK, so I'm not sure how
much of this is expected behavior.
Are you using dangerously-dedicated disks? That is, no fdisk-style
partition table? If so, disklabel on ad0 or ad2 itself would be valid. It
doesn't appear you are, in which case a disklabel operation should be
performed on the slice, e.g. disklabel ad2s2.
--
Brian Fundakowski Feldman \'[ FreeBSD ]''\
[EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \
Opinions expressed are my own. \,,\
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
can recover /usr/src/include diretories
delete the /usr/src/include dir falsely , can it recover. buildworld again ,but allways get *.h not found. faint. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PCI problems with today's current
Hi,
I tried the patches you checked in, and PCI bus 2 on my machine still isn't
probed. See the attached dmesg.
I'm a bit confused about just what sort of file the ACPI code expects to
load on boot.
I installed the acpicatools port, so I've got iasl(1), but it appears to
have 4 output modes (C or assembly source, C or assembly hex table), at
least for AML output (which acpi(4) says is what you need to load), and
no output modes for DSDT files.
Ok, you got errors from iasl, like;
SupermicroP3TDE6.new.asl56: Scope(DEB_) {
Error1077 - ^ Existing object has invalid type for Scope
operator (DEB_, Integer)
This is invalid, so ACPI CA interpreter in our kernel complains;
ACPI-0623: *** Warning: Type override - [DEB_] had invalid type (Integer) for
Scope operator, changed to (Scope)
But never mind, you can force to compile the ASL and generate DSDT;
# iasl -i SupermicroP3TDE6.new.asl
then copy generated acpi_dsdt.aml to /boot/.
# cp acpi_dsdt.aml /boot/
I'll think about other possibilities to solve this...
Thanks
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: GEOM problems?
In message [EMAIL PROTECTED], walt writes: Just finished making world and kernel at about 01:00 GMT Oct 6. dmesg includes this printout: Initializing GEOMetry subsystem ad0: 76319MB ST380021A [155061/16/63] at ata0-master UDMA100 ad2: 42934MB WDC WD450AA-00BAA0 [87233/16/63] at ata1-master UDMA66 acd0: CD-RW R/RW 4x4x24 at ata1-slave PIO4 Mounting root from ufs:/dev/ad2s2a 00 01 c1 ff 83 fe ff ff 3f 00 00 00 06 5b 5f 00 |?[_.| [0] f:00 typ:131 s(CHS):255/1/193 e(CHS):255/254/255 s:63 l:6249222 00 00 c1 ff 05 fe ff ff 45 5b 5f 00 b3 f1 5a 00 |E[_...Z.| [1] f:00 typ:5 s(CHS):255/0/193 e(CHS):255/254/255 s:6249285 l:5960115 00 01 c1 ff 07 fe ff ff 3f 00 00 00 74 f1 5a 00 |?...t.Z.| [0] f:00 typ:7 s(CHS):255/1/193 e(CHS):255/254/255 s:63 l:5960052 00 00 c1 ff 05 fe ff ff f8 4c ba 00 e2 05 18 00 |.L..| [1] f:00 typ:5 s(CHS):255/0/193 e(CHS):255/254/255 s:12209400 l:1574370 many more lines snipped Is this normal output now? Yes, but not for long, its a debug printf that has slipped through. And there's this: #disklabel ad0 disklabel: ioctl DIOCGDINFO: Operation not supported by device ad0 does not have a disklabel. Same errors with ad2. Same diagnosis. Typically you will find that devices with disklabels are named ad%ds%d All the partitions do mount and seem to work OK, so I'm not sure how much of this is expected behavior. All of it :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: The official GEOM is in the tree speech.
good speech!, i hope that GEOM is as good! (or maybe I should have sayed that in reverse order?) danny To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
