dc still reporting collisions
The dc(4) driver is still reporting collisions on 100 Mbit full-duplex
links:
> grep dc0 /var/run/dmesg.boot
dc0: port 0xd000-0xd0ff mem 0xfbfdf000-0xfbfdf0ff
irq 10 at device 6.0 on pci0
dc0: Ethernet address: 00:00:e8:89:b9:66
miibus0: on dc0
> ifconfig -a
dc0: flags=8843 mtu 1500
inet 172.22.2.12 netmask 0xfff0 broadcast 172.22.2.15
ether 00:00:e8:89:b9:66
media: Ethernet autoselect (100baseTX )
status: active
> netstat -i
NameMtu Network Address Ipkts IerrsOpkts Oerrs Coll
dc01500 00:00:e8:89:b9:6626463 026737 13253 225301
dc01500 172.22.2/28 team226044 -26636 - -
lo0 16384 73 0 73 0 0
lo0 16384 your-net localhost 73 - 73 - -
--
:{ [EMAIL PROTECTED]
Andy Farkas
System Administrator
Speednet Communications
http://www.speednet.com.au/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
console freezes
When messages are sent to console rapidly, console becomes unavailable :(
My previous email complains of messages being spewed to the console. These
messages stop after a few minutes and the console is dead.
On another box of mine, same thing happens. Different messages get spewed
to console and it locks up (I am preparing another email about it,
messages are ATA related)
--
:{ [EMAIL PROTECTED]
Andy Farkas
System Administrator
Speednet Communications
http://www.speednet.com.au/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
EISA AHA panic (ISRng related)
My EISA AHA2740's don't work no more :(
If I 'dd if=/dev/da0 of=/dev/null' with -CURRENT cvsup'd a few hours ago,
I get this panic:
...
kernel: type 12 trap, code=0
Stopped at intr_execute_handlers+0x23: lock addl%eax,0(%edx)
db> where
intr_execute_handlers(c06d3d04,d763ac9c,d763ace0,c065aafe,7) at
intr_execute_handlers+0x23
atpic_handle_intr(7) at apic_handle_intr+0x42
Xatpic_intr7() at Xatpic_intr7+0x1e
...
Verbose dmesg's at:
http://www.speednet.com.au/~andyf/hummer/hummer-dmesg.boot-current
http://www.speednet.com.au/~andyf/hummer/hummer-dmesg.boot-release
--
:{ [EMAIL PROTECTED]
Andy Farkas
System Administrator
Speednet Communications
http://www.speednet.com.au/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
checking stopevent 2!
Help!
These messages spew onto my console and into syslogd once every second:
...
Nov 15 16:05:44 hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:44 hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/kern_condvar.c:289
Nov 15 16:05:44 hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:44 hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
Nov 15 16:05:44 hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:45 hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
Nov 15 16:05:45 hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:45 hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4663aa8) locked @ /hummer/src-current/src/sys/kern/kern_synch.c:293
Nov 15 16:05:45 hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:45 hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4663aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
Nov 15 16:05:45 hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:45 hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4663aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
Nov 15 16:05:45 hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:45 hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/kern_condvar.c:289
Nov 15 16:05:45 hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:46 hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
Nov 15 16:05:46 hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:46 hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/kern_condvar.c:289
Nov 15 16:05:46 hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:46 hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
Nov 15 16:05:46 hummer kernel: checking stopevent 2 with the following
non-sleepable locks held:
Nov 15 16:05:46 hummer kernel: exclusive sleep mutex sigacts r = 0
(0xc4656aa8) locked @ /hummer/src-current/src/sys/kern/subr_trap.c:260
...
This is latest -current (cvsup'd a few hours ago)
--
:{ [EMAIL PROTECTED]
Andy Farkas
System Administrator
Speednet Communications
http://www.speednet.com.au/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ATAng 'mode PIO4' to 'mode ???' regression
-current (cvsup'd about 3 hours ago) doesn't like my ATA disk anymore :(
5.1-RELEASE says (during 'boot -v'):
ata0: pre reset mask=03 ostat0=50 ostat2=00
ata0-master: ATAPI 00 00
ata0-slave: ATAPI 00 00
ata0: after reset mask=03 stat0=50 stat1=00
ata0-master: ATA 01 a5
ata0: devices=01
ata0 at port 0x3f6,0x1f0-0x1f7 irq 14 on isa0
ata1 at port 0x376,0x170-0x177 irq 15 on isa0
ad0: ATA-0 disk at ata0-master
ad0: 1222MB (2503872 sectors), 2484 C, 16 H, 63 S, 512 B
ad0: 1 secs/int, 1 depth queue, PIO4
ad0: piomode=12 dmamode=34 udmamode=-1 cblid=0
But -CURRENT says (during 'boot -v'):
ata0: reset tp1 mask=03 ostat0=50 ostat1=00
ata0-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00
ata0-slave: stat=0x00 err=0x01 lsb=0x00 msb=0x00
ata0: reset tp2 mask=03 stat0=50 stat1=00 devices=0x1
ata0 at port 0x3f6,0x1f0-0x1f7 irq 14 on isa0
ata0: [MPSAFE]
ata1 at port 0x376,0x170-0x177 irq 15 on isa0
ata1: [MPSAFE]
ad0: ATA-0 disk at ata0-master
ad0: 1222MB (2503872 sectors), 2484 C, 16 H, 63 S, 512 B
ad0: 1 secs/int, 1 depth queue, ???
Notice the "???" ?
Verbose dmesg's at:
http://www.speednet.com.au/~andyf/hummer/hummer-dmesg.boot-current
http://www.speednet.com.au/~andyf/hummer/hummer-dmesg.boot-release
--
:{ [EMAIL PROTECTED]
Andy Farkas
System Administrator
Speednet Communications
http://www.speednet.com.au/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[current tinderbox] failure on alpha/alpha
TB --- 2003-11-15 05:00:01 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-15 05:00:01 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-11-15 05:00:01 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-15 05:04:36 - building world TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything.. [...] cc -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -o from from.o gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/usr.bin/from/from.1 > from.1.gz ===> usr.bin/fstat cc -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -c /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/usr.bin/fstat/cd9660.c cc -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -c /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/usr.bin/fstat/fstat.c In file included from /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/usr.bin/fstat/fstat.c:75: /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include/nfsclient/nfsnode.h:129: error: field `n_rfc' has incomplete type /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include/nfsclient/nfsnode.h:130: error: field `n_wfc' has incomplete type *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/usr.bin/fstat. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/usr.bin. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. TB --- 2003-11-15 06:02:10 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-11-15 06:02:10 - TB --- ERROR: failed to build world TB --- 2003-11-15 06:02:10 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: signal 12's everywhere on Current with update this morning.
Andy Farkas wrote: Richard Coleman wrote: 1. make buildworld 2. make buildkernel KERNCONF=NAME_OF_KERNEL_FILE 3. make installkernel KERNCONF=NAME_OF_KERNEL_FILE 4. shutdown -r now 5. boot into single user mode 6. fsck -p 7. mount -u / 8. mount -a -t ufs 9. swapon -a 9.5 adjkerntz -i Yep, forgot that part. I keep all my system clocks on UTC so I never do this step when building world. 10. make installworld 11. mergemaster 12. reboot Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NFSv4 Client code committed.
* Craig Rodrigues <[EMAIL PROTECTED]> [031114 20:00] wrote: > On Fri, Nov 14, 2003 at 05:32:31PM -0800, Alfred Perlstein wrote: > > NFSv4 shares some code with nfs2 and nfs3, and required some minor > > modifications of the v2 and v3 sources so let me know if you > > experience breakage. > > I'm getting this on buildworld: Working on it. > > > ===> usr.bin/fstat > cc -O -pipe -mcpu=pentiumpro -c /usr/src/usr.bin/fstat/cd9660.c > cc -O -pipe -mcpu=pentiumpro -c /usr/src/usr.bin/fstat/fstat.c > In file included from /usr/src/usr.bin/fstat/fstat.c:75: > /usr/obj/usr/src/i386/usr/include/nfsclient/nfsnode.h:129: error: field `n_rfc' has > incomplete type > /usr/obj/usr/src/i386/usr/include/nfsclient/nfsnode.h:130: error: field `n_wfc' has > incomplete type > *** Error code 1 > > Stop in /usr/src/usr.bin/fstat. > *** Error code 1 > > Stop in /usr/src/usr.bin. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > > Script done on Fri Nov 14 23:00:39 2003 > > -- > Craig Rodrigues > http://crodrigues.org > [EMAIL PROTECTED] -- - Alfred Perlstein - Research Engineering Development Inc. - email: [EMAIL PROTECTED] cell: 408-480-4684 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NFSv4 Client code committed.
On Fri, Nov 14, 2003 at 05:32:31PM -0800, Alfred Perlstein wrote: > NFSv4 shares some code with nfs2 and nfs3, and required some minor > modifications of the v2 and v3 sources so let me know if you > experience breakage. I'm getting this on buildworld: ===> usr.bin/fstat cc -O -pipe -mcpu=pentiumpro -c /usr/src/usr.bin/fstat/cd9660.c cc -O -pipe -mcpu=pentiumpro -c /usr/src/usr.bin/fstat/fstat.c In file included from /usr/src/usr.bin/fstat/fstat.c:75: /usr/obj/usr/src/i386/usr/include/nfsclient/nfsnode.h:129: error: field `n_rfc' has incomplete type /usr/obj/usr/src/i386/usr/include/nfsclient/nfsnode.h:130: error: field `n_wfc' has incomplete type *** Error code 1 Stop in /usr/src/usr.bin/fstat. *** Error code 1 Stop in /usr/src/usr.bin. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Script done on Fri Nov 14 23:00:39 2003 -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Two processes with PID == 0
Hi all, I have wierd problem with -current from Fri Nov 14 19:58:02 JST and with SCHED_4BSD scheduler. There are two processes that have the same PID as 0!! Here's snippest from 'ps axl' output: UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 0 0 0 -16 0 04 sched DLs ??0:00.35 (swapper) 123 0 560 0 -84 0 00 - ZWv00:00.00 (xbattbar) 0 560 554 17 98 0 5128 3292 select I v00:00.56 xterm -C -sb The xbattbar process was started with the following ~/.xinitrc script that I use to star X Window. ---8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-- if [ -f /usr/X11R6/bin/xbattbar ]; then nice -20 xbattbar -t 1 -p 20 top & fi if [ -f /usr/X11R6/bin/unclutter ]; then unclutter -jitter 5 & fi twm & # xclock -geometry 80x80+0-0 & xclock -d -geometry 160x18+900+1 -padding 3 -bg maroon -fg gray85 -update 3 & kterm -sb -rw -km euc -geometry 80x24+3+25 -sl 1000 & kterm -sb -rw -km euc -geometry 80x24+3+392 -sl 1000 & sleep 1 exec xterm -C -sb -rw -geometry 80x49+0+1 -name login -iconic \#+0+1 ---8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-- Anybody have any idea what has happend? Thanks, Haro =-- _ _Munehiro (haro) Matsuda -|- /_\ |_|_| Internet Solution Dept., Kubota Graphics Technologies Inc. /|\ |_| |_|_| 2-8-8 Shinjuku Shinjuku-ku Tokyo 160-0022, Japan Tel: +81-3-3225-0767 Fax: +81-3-3225-0740 Email: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
exclusive sleep mutex ... /usr/src/sys/kern/kern_synch.c:293
Hello,
I'm getting the following messages on my console with a compile from today's (Nov 14,
2003) sources:
Nov 14 19:38:26 syslogd: /var/log/debug.log: No such file or directory
Nov 14 19:38:26 cosmin syslogd: kernel boot file is /boot/kernel/kernel
checking stopevent 2 with the following non-sleepable locks held:
exclusive sleep mutex sigacts r = 0 (0xc1cb8aa8) locked @
/usr/src/sys/kern/kern_synch.c:293
Debugger("witness_warn")
Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0
db> trace
Debugger(c0675228,c93f4b88,1,c93f4b84,0) at Debugger+0x54
witness_warn(5,c1c0fcc8,c068d494,2,c06f37a0) at witness_warn+0x19f
issignal(c1bb8dc0,2,c068fc5b,bd,c1c0fcc8) at issignal+0x16b
cursig(c1bb8dc0,0,c0690152,125,1) at cursig+0xe8
msleep(c1c0fc5c,c1c0fcc8,15c,c068fb80,0) at msleep+0x631
wait1(c1bb8dc0,c93f4d10,0,c93f4d40,c065bca0) at wait1+0x990
wait4(c1bb8dc0,c93f4d10,c06a868e,3ee,4) at wait4+0x20
syscall(2f,2f,2f,bfbfeec0,bfbfeec0) at syscall+0x2e0
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (7, FreeBSD ELF32, wait4), eip = 0x280d0b1f, esp = 0xbfbfe84c, ebp =
0xbfbfe868 ---
db>
Also, if I don't have debug.witness_ddb=1, I get the following messages:
checking stopevent 2 with the following non-sleepable locks held:
exclusive sleep mutex sigacts r = 0 (0xc1cbdaa8) locked @
/usr/src/sys/kern/kern_synch.c:293
checking stopevent 2 with the following non-sleepable locks held:
exclusive sleep mutex sigacts r = 0 (0xc1cbdaa8) locked @
/usr/src/sys/kern/subr_trap.c:260
checking stopevent 2 with the following non-sleepable locks held:
exclusive sleep mutex sigacts r = 0 (0xc1cbdaa8) locked @
/usr/src/sys/kern/subr_trap.c:260
I will also try to buildworld and installworld using the same sources, maybe that will
fix it.
If you need more information please ask.
Here is the full dmesg:
Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.1-CURRENT #10: Fri Nov 14 18:35:12 CST 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GALAXY
Preloaded elf kernel "/boot/kernel/kernel" at 0xc07cf000.
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: AMD Athlon(tm) Processor (1100.05-MHz 686-class CPU)
Origin = "AuthenticAMD" Id = 0x671 Stepping = 1
Features=0x183f9ff
AMD Features=0xc048
real memory = 134217728 (128 MB)
avail memory = 125054976 (119 MB)
Pentium Pro MTRR support enabled
npx0: [FAST]
npx0: on motherboard
npx0: INT 16 interface
pcibios: BIOS version 2.10
Using $PIR table, 7 entries at 0xc00fdc90
pcib0: at pcibus 0 on motherboard
pci0: on pcib0
pci_cfgintr: 0:8 INTA BIOS irq 10
pci_cfgintr: 0:9 INTA BIOS irq 7
pci_cfgintr: 0:9 INTB BIOS irq 11
pci_cfgintr: 0:9 INTC BIOS irq 5
pci_cfgintr: 0:10 INTA BIOS irq 11
pcib1: at device 1.0 on pci0
pci1: on pcib1
pci_cfgintr: 0:1 INTA routed to irq 10
pcib1: slot 0 INTA is routed to irq 10
CPU: AMD Athlon(tm) Processor (1100.05-MHz 686-class CPU)
Origin = "AuthenticAMD" Id = 0x671 Stepping = 1
Features=0x183f9ff
AMD Features=0xc048
real memory = 134217728 (128 MB)
avail memory = 125054976 (119 MB)
Pentium Pro MTRR support enabled
npx0: [FAST]
npx0: on motherboard
npx0: INT 16 interface
pcibios: BIOS version 2.10
Using $PIR table, 7 entries at 0xc00fdc90
pcib0: at pcibus 0 on motherboard
pci0: on pcib0
pci_cfgintr: 0:8 INTA BIOS irq 10
pci_cfgintr: 0:9 INTA BIOS irq 7
pci_cfgintr: 0:9 INTB BIOS irq 11
pci_cfgintr: 0:9 INTC BIOS irq 5
pci_cfgintr: 0:10 INTA BIOS irq 11
pcib1: at device 1.0 on pci0
pci1: on pcib1
pci_cfgintr: 0:1 INTA routed to irq 10
pcib1: slot 0 INTA is routed to irq 10
pci1: at device 0.0 (no driver attached)
isab0: at device 7.0 on pci0
isa0: on isab0
atapci0: port 0xc000-0xc00f at device 7.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata0: [MPSAFE]
ata1: at 0x170 irq 15 on atapci0
ata1: [MPSAFE]
nge0: port 0xcc00-0xccff mem
0xdc005000-0xdc005fff irq 10 at device 8.0 on pci0
nge0: Ethernet address: 00:50:ba:39:06:d6
miibus0: on nge0
nsgphy0: on miibus0
nsgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX,
auto
uhci0: port 0xd000-0xd01f irq 7 at device 9.0 on pci0
usb0: on uhci0
usb0: USB revision 1.0
uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhub0: port error, restarting port 1
uhub0: port error, giving up port 1
uhub0: port error, restarting port 2
uhub0: port error, giving up port 2
uhci1: port 0xd400-0xd41f irq 11 at device 9.1 on pci0
usb1: on uhci1
usb1: USB revision 1.0
uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhub1: port error, restarting port 1
uhub1: port error, giving up port 1
uhub1: port error, restarting port 2
uhub1: port error, giving up port 2
pci0: at device 9.2 (no driver attached)
atapci1: port
0xe800-0xe80f,0xe400-0xe403,0xe000-0xe007,0xdc00-0xdc03,0xd800-0xd
Re: Using Geom to mirror root partitions?
On Sat, Nov 15, 2003 at 12:32:10AM +0100, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Josef Karthauser writes: > > >I've got a machine with two drives 120gb drives, which is going to a > >colo. If I configure it to use one drive, will I at some point be able > >to remotely reconfigure it to say use the second drive as a mirror as > >the physical layer, i.e. if the first drive goes bang then I can get the > >second drive to boot via the bios and still have the machine work - or > >am I dreaming? > > The main problem here (currently) is the bootblocks and /etc/fstab. > > We had some work on geom_mirror recently which I have not yet had > time to look at. If that is done right, it should be possible to > set it up like you say. > > In order to "fool" the bootblocks, geom_mirror would have to be able > to use a meta-data sector at the end of the partition rather than at > the beginning. With that in place it should "just work", since the > device in /etc/fstab would then be the geom_mirror device and GEOM > should be able to offer that for root mounting. > What's the best way to prepare for this? Should I leave some unallocated space at the beginning of the disk so that any magic geom bits can be inserted later? Joe -- Josef Karthauser ([EMAIL PROTECTED]) http://www.josef-k.net/ FreeBSD (cvs meister, admin and hacker) http://www.uk.FreeBSD.org/ Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ An eclectic mix of fact and theory. = pgp0.pgp Description: PGP signature
NFSv4 Client code committed.
The Citi project over at the University of Michegan has been nice enough to provide us with an initial implementation of a NFSv4 client. We still need locking, delegations and cypto. If anyone who's crypto friendly wants to help with the integration that would be really useful. Please email me. NFSv4 shares some code with nfs2 and nfs3, and required some minor modifications of the v2 and v3 sources so let me know if you experience breakage. Have a great weekend! -- - Alfred Perlstein - Research Engineering Development Inc. - email: [EMAIL PROTECTED] cell: 408-480-4684 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic on mount_cd9660
As of yesterday's sources, this panic is precisely the same. Actually, it
can be triggered by simply running "cdcontrol -f acdX info" with 2
different audio CDs in a row. And it doesn't happen with ATAPICAM devices
cdX. GDB session transcript attached.
On Mon, 10 Nov 2003, Pav Lucistnik wrote:
> FreeBSD hood.oook.cz 5.1-CURRENT FreeBSD 5.1-CURRENT #6: Mon Nov 10
> 20:26:12 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PAV i386
>
> What I did:
> 1) insert SVCD in the CD-ROM drive
> 2) play some tracks from it. note /dev/acd0t1 /dev/acd0t2 etc...
> 3) remove SVCD from the CD-ROM drive
> 4) put data CD in the CD-ROM drive
> 5) mount_cd9660 /dev/acd0 /mnt/cdrom
>
Regards,
Vladimirpanic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x1c
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc04f2da3
stack pointer = 0x10:0xcbc94c68
frame pointer = 0x10:0xcbc94c80
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 = 2 (g_event)
panic: from debugger
Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer = 0x8:0xc06112f4
stack pointer = 0x10:0xcbc949e0
frame pointer = 0x10:0xcbc949ec
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= IOPL = 0
current process = 2 (g_event)
---
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc04d6180 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc04d6568 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc045d3e2 in db_panic () at /usr/src/sys/ddb/db_command.c:450
#4 0xc045d342 in db_command (last_cmdp=0xc0693360, cmd_table=0x0,
aux_cmd_tablep=0xc0668ff4, aux_cmd_tablep_end=0xc0668ff8)
at /usr/src/sys/ddb/db_command.c:346
#5 0xc045d485 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6 0xc04604a5 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_trap.c:73
#7 0xc061103c in kdb_trap (type=12, code=0, regs=0xcbc94c28)
at /usr/src/sys/i386/i386/db_interface.c:171
#8 0xc0624fa6 in trap_fatal (frame=0xcbc94c28, eva=0)
at /usr/src/sys/i386/i386/trap.c:816
#9 0xc0624c72 in trap_pfault (frame=0xcbc94c28, usermode=0, eva=28)
at /usr/src/sys/i386/i386/trap.c:735
#10 0xc06247cd in trap (frame=
{tf_fs = -1060962280, tf_es = -1035993072, tf_ds = -1035993072, tf_edi = 0,
tf_esi = -1036926336, tf_ebp = -876000128, tf_isp = -876000172, tf_ebx = -1034088208,
tf_edx = 0, tf_ecx = -1066807068, tf_eax = 1, tf_trapno = 12, tf_err = 0, tf_eip =
-1068552797, tf_cs = 8, tf_eflags = 66051, tf_esp = -876000104, tf_ss = -1068903426})
at /usr/src/sys/i386/i386/trap.c:420
#11 0xc06129f8 in calltrap () at {standard input}:94
#12 0xc04a1d88 in g_destroy_provider (pp=0xc25d10f0)
at /usr/src/sys/geom/geom_subr.c:416
#13 0xc049ed65 in g_orphan_register (pp=0xc231c280)
at /usr/src/sys/geom/geom_event.c:143
#14 0xc049ee8c in one_event () at /usr/src/sys/geom/geom_event.c:169
#15 0xc049f0b5 in g_run_events () at /usr/src/sys/geom/geom_event.c:202
#16 0xc04a00e5 in g_event_procbody () at /usr/src/sys/geom/geom_kern.c:134
#17 0xc04bee10 in fork_exit (callout=0xc04a00c0 , arg=0x0,
frame=0x0) at /usr/src/sys/kern/kern_fork.c:793
(kgdb) frame 12
#12 0xc04a1d88 in g_destroy_provider (pp=0xc25d10f0)
at /usr/src/sys/geom/geom_subr.c:416
416 devstat_remove_entry(pp->stat);
(kgdb) list
411 KASSERT (pp->acw == 0, ("g_destroy_provider with acw"));
412 KASSERT (pp->acw == 0, ("g_destroy_provider with ace"));
413 g_cancel_event(pp);
414 LIST_REMOVE(pp, provider);
415 gp = pp->geom;
416 devstat_remove_entry(pp->stat);
417 g_free(pp);
418 if ((gp->flags & G_GEOM_WITHER))
419 g_wither_geom(gp, 0);
420 }
(kgdb) print pp
$1 = (struct g_provider *) 0xc25d10f0
(kgdb) print *pp
$2 = {name = 0x0, provider = {le_next = 0x0, le_prev = 0x0}, geom = 0x0,
consumers = {lh_first = 0x0}, acr = 0, acw = 0, ace = 0, error = 0,
orphan = {tqe_next = 0x0, tqe_prev = 0x0}, index = 0, mediasize = 0,
sectorsize = 0, stripesize = 0, stripeoffset = 0, stat = 0x0, nstart = 0,
nend = 0, flags = 0}
(kgdb) frame 13
#13 0xc049ed65 in g_orphan_register (pp=0xc231c280)
at /usr/src/sys/geom/geom_event.c:143
143 g_destroy_provider(pp);
(kgdb) print pp
$3 = (struct g_provider *) 0xc231c280
(kgdb) print *pp
$4 = {name = 0xc22b93b0 "acd0", provider = {le_next = 0xc0670f00,
le_prev = 0x0}, geom = 0xc231c808, consumers = {lh_first = 0x0},
acr = -1033931776, acw = -1036925696, ace = -1036924904, error = 1,
orphan = {tqe_next = 0xc0485260, tqe_prev = 0x0}, index = 0,
me
[current tinderbox] failure on sparc64/sparc64
TB --- 2003-11-14 23:17:16 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-14 23:17:16 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-11-14 23:17:16 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-14 23:20:16 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything.. [...] cc -O -pipe-o from from.o gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/usr.bin/from/from.1 > from.1.gz ===> usr.bin/fstat cc -O -pipe -c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/usr.bin/fstat/cd9660.c cc -O -pipe -c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/usr.bin/fstat/fstat.c In file included from /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/usr.bin/fstat/fstat.c:75: /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include/nfsclient/nfsnode.h:129: error: field `n_rfc' has incomplete type /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include/nfsclient/nfsnode.h:130: error: field `n_wfc' has incomplete type *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/usr.bin/fstat. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/usr.bin. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2003-11-15 00:09:44 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-11-15 00:09:44 - TB --- ERROR: failed to build world TB --- 2003-11-15 00:09:44 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure
On Sat, 15 Nov 2003 00:46:19 +0100, Sascha Holzleiter <[EMAIL PROTECTED]> wrote: On Fri, 2003-11-14 at 22:46, Bruce Cran wrote: Either the new statfs, or something in a recent change in -CURRENT (since last week), has broken the nvidia driver. I've been using it now for over half a year with no problems at all. I installed the new kernel and world, rebuilt x11/nvidia-driver and X11 hung before it had even switched to graphical mode. After a minute the system rebooted, and I got the same behavoir a few days ago BEFORE rebuilding the system, so i don't think it is due to the statfs change. The driver stopped working around the time the XFree86 ports were changed, I think that these are more likely the cause. But, all my apps are up to date so the Nvidia driver is still working. I haven't update -CURRENT yet, I am waiting for Gnome 2.5 to be out then I will update -CURRENT and stuff. # pkg_info | grep XFree86 XFree86-4.3.0,1 X11/XFree86 core distribution (complete, using mini/meta-po XFree86-FontServer-4.3.0_2 XFree86-4 font server XFree86-Server-4.3.0_12 XFree86-4 X server and related programs XFree86-clients-4.3.0_5 XFree86-4 client programs and related files XFree86-documents-4.3.0 XFree86-4 documentation XFree86-font100dpi-4.3.0 XFree86-4 bitmap 100 dpi fonts XFree86-font75dpi-4.3.0 XFree86-4 bitmap 75 dpi fonts XFree86-fontCyrillic-4.3.0 XFree86-4 Cyrillic fonts XFree86-fontDefaultBitmaps-4.3.0 XFree86-4 default bitmap fonts XFree86-fontEncodings-4.3.0 XFree86-4 font encoding files XFree86-fontScalable-4.3.0 XFree86-4 scalable fonts XFree86-libraries-4.3.0_6 XFree86-4 libraries and headers dri-4.3.0,1 OpenGL hardware acceleration drivers for XFree86 imake-4.3.0_1 Imake and other utilities from XFree86 wrapper-1.0_3 Wrapper for XFree86-4 server # pkg_info | grep nvidia nvidia-driver-1.0.4365 [...with non-offical patch...] Cheers, Mezz The odd thing is that this seems to be system dependent, on my P4 system at home the driver still works fine, on my Athlon system at work I have the same issues you describe here... I haven't done anything to debug or fix this because I need the failing system to work with rather then to play around with ;) But if anyone wants to look into that I'll provide every information needed. Greets, Sascha -- bsdforums.org 's moderator, mezz. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure
At 5:26 PM -0500 11/14/03, Robert Watson wrote: As soon as you recompile libc, applications expecting the old statfs() ABI get the new statfs(), and depending on where their smaller struct statfs is located, may stomp on memory they're using for something else (like critical data structures). But if they are re-compiled, won't they be re-compiled with the newer struct statfs? (and thus be the correct size) -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Who needs these silly statfs changes...
>On Fri, 14 Nov 2003, Peter Edwards wrote: > >> Bruce Evans wrote: >> >> > On Fri, 14 Nov 2003, Peter Edwards wrote: > >> >> The NFS protocols have unsigned fields where statfs has signed >> >> equivalents: NFS can't represent negative available disk space ( Without >> >> the knowledge of the underlying filesystem on the server, negative free >> >> space is a little nonsensical anyway, I suppose) >> >> >> >> The attached patch stops the NFS server assigning negative values to >> >> unsigned fields in the statfs response, and works against my local >> >> solaris box. Seem reasonable? >> > >> > The client attampts to fix this by pretending that the unsigned fields >> > are signed. -current tries to do more to support file system sizes larger >> > that 1TB, but the code for this is not even wrong except it may be wrong >> > enough to break the negative values. See my reply to one of the PRs >> > for more details. >> > >> > I just got around to testing the patch in that reply: >> > ... >> >> Your patch to nfs_vfsops won't apply to my Solaris kernel :-) >> The protocol says "abytes" is unsigned, so the server shouldn't be lying >> by sending a huge positive value for available space on a full >> filesystem. No? > >Possibly not, but the protocol is broken if it actually requires that. What makes you say that? I would think the utility of negative counts for disk sizes and available spaces is marginal. Solaris, POSIX, and NFS seem to get on fine without it. What am I (and they) missing? >The "free" fields are signed in struct statfs so that they can be negative. >However, this is broken in POSIX's struct statvfs (all count fields have >type fsblkcnt_t or fsfilcnt_t and these are specified to be unsigned). >Is Solaris bug for bug compatible with that? I'm away from any solaris boxes at the moment, but I know that "df" certainly reports huge free space when it sees the high bit set in the asize attribute of the NFS response. I'm not sure that this is directly relevant to NFS, though. Whatever the operating system's representation of FSSTATres is little to do with proper implementation of the protocol. I've no idea what Win32 represents this data in, but I'm sure it's very different from statv?fs. It'll provide and consume NFS services, though. > >Anyway, my patch is mainly supposed to fix the scaling. The main bug >in the initial scaling patch was that the huge positive values were >scaled before they were interpreted as negative values, so they became >not so huge but still preposterous values that could not be interpreted >as negative values. Ok, Understood. > >The type pun to negative values is in most versions of BSD: > [snip code snippets and bug] That's great for interacting with other BSDs, but it still abusing the protocol. As filesystems with approaching 2^64 bytes become possible it probably has more of an impact. I understand that this is proably not a big enough problem to break historic behaviour for, of course. >More changes are needed here to catch up with the recent changes to struct >statfs in FreeBSD. The casts to long are now just wrong since the block >count fields don't have type long. Sure. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: signal 12's everywhere on Current with update this morning.
Richard Coleman wrote: > 1. make buildworld > 2. make buildkernel KERNCONF=NAME_OF_KERNEL_FILE > 3. make installkernel KERNCONF=NAME_OF_KERNEL_FILE > 4. shutdown -r now > 5. boot into single user mode > 6. fsck -p > 7. mount -u / > 8. mount -a -t ufs > 9. swapon -a 9.5 adjkerntz -i > 10. make installworld > 11. mergemaster > 12. reboot ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure
On Fri, 2003-11-14 at 22:46, Bruce Cran wrote: > Either the new statfs, or something in a recent change in -CURRENT > (since last week), has broken the nvidia driver. > I've been using it now for > over half a year with no problems at all. I installed the new kernel > and world, rebuilt x11/nvidia-driver and X11 hung before it had even > switched to graphical mode. After a minute the system rebooted, and I got the same behavoir a few days ago BEFORE rebuilding the system, so i don't think it is due to the statfs change. The driver stopped working around the time the XFree86 ports were changed, I think that these are more likely the cause. The odd thing is that this seems to be system dependent, on my P4 system at home the driver still works fine, on my Athlon system at work I have the same issues you describe here... I haven't done anything to debug or fix this because I need the failing system to work with rather then to play around with ;) But if anyone wants to look into that I'll provide every information needed. Greets, Sascha ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Teach '-m' option of bsdlabel(8) to sunlabel(8)
brooks> I don't think you can because our UFS on disk format is byte brooks> order dependent. Someone probalby needs to import the NetBSD brooks> endien-independence stuff. My friends told me that I can do with a help of geom_sunlabel, and it's right. -- - Makoto `MAR' Matsushita ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Using Geom to mirror root partitions?
In message <[EMAIL PROTECTED]>, Josef Karthauser writes: >I've got a machine with two drives 120gb drives, which is going to a >colo. If I configure it to use one drive, will I at some point be able >to remotely reconfigure it to say use the second drive as a mirror as >the physical layer, i.e. if the first drive goes bang then I can get the >second drive to boot via the bios and still have the machine work - or >am I dreaming? The main problem here (currently) is the bootblocks and /etc/fstab. We had some work on geom_mirror recently which I have not yet had time to look at. If that is done right, it should be possible to set it up like you say. In order to "fool" the bootblocks, geom_mirror would have to be able to use a meta-data sector at the end of the partition rather than at the beginning. With that in place it should "just work", since the device in /etc/fstab would then be the geom_mirror device and GEOM should be able to offer that for root mounting. -- 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. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Using Geom to mirror root partitions?
On Sat, Nov 15, 2003 at 12:09:34AM +0100, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Josef Karthauser writes: > > >I've been a bit out of touch with developments recently. I was > >wondering whether it's possible to mirror root partitions across two > >drives yet? I seem to remember that this was something that geom could > >help with, but I've no idea as to whether it's a reality yet. > > > >Does anyone know? > > We're not there yet. > I've got a machine with two drives 120gb drives, which is going to a colo. If I configure it to use one drive, will I at some point be able to remotely reconfigure it to say use the second drive as a mirror as the physical layer, i.e. if the first drive goes bang then I can get the second drive to boot via the bios and still have the machine work - or am I dreaming? Joe -- Josef Karthauser ([EMAIL PROTECTED]) http://www.josef-k.net/ FreeBSD (cvs meister, admin and hacker) http://www.uk.FreeBSD.org/ Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ An eclectic mix of fact and theory. = pgp0.pgp Description: PGP signature
[current tinderbox] failure on ia64/ia64
TB --- 2003-11-14 22:16:37 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-14 22:16:37 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2003-11-14 22:16:37 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-14 22:19:50 - building world TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything.. [...] cc -O -pipe-o from from.o gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/usr.bin/from/from.1 > from.1.gz ===> usr.bin/fstat cc -O -pipe -c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/usr.bin/fstat/cd9660.c cc -O -pipe -c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/usr.bin/fstat/fstat.c In file included from /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/usr.bin/fstat/fstat.c:75: /home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include/nfsclient/nfsnode.h:129: error: field `n_rfc' has incomplete type /home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include/nfsclient/nfsnode.h:130: error: field `n_wfc' has incomplete type *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/usr.bin/fstat. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/usr.bin. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. TB --- 2003-11-14 23:17:15 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-11-14 23:17:15 - TB --- ERROR: failed to build world TB --- 2003-11-14 23:17:15 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Using Geom to mirror root partitions?
In message <[EMAIL PROTECTED]>, Josef Karthauser writes: >I've been a bit out of touch with developments recently. I was >wondering whether it's possible to mirror root partitions across two >drives yet? I seem to remember that this was something that geom could >help with, but I've no idea as to whether it's a reality yet. > >Does anyone know? We're not there yet. -- 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. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Using Geom to mirror root partitions?
I've been a bit out of touch with developments recently. I was wondering whether it's possible to mirror root partitions across two drives yet? I seem to remember that this was something that geom could help with, but I've no idea as to whether it's a reality yet. Does anyone know? Joe -- Josef Karthauser ([EMAIL PROTECTED]) http://www.josef-k.net/ FreeBSD (cvs meister, admin and hacker) http://www.uk.FreeBSD.org/ Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ An eclectic mix of fact and theory. = pgp0.pgp Description: PGP signature
upgraded to CURRENT = system is dead
Hi :) I just upgraded with cvsup to CURRENT. I read UPDATING to make sure I would have no problem, but maybe I misunerstood something. Here is what I did: $ cvsup blablabla... $ make buildkernel KERNCONF=MYKERNEL && make install kernel KERNCONF=MYKERNEL $ reboot (in single user mode) $ make buildworld $ make installworld .. --> error during the installworld: /libexec/ld-elf.so.1: Shared object "libedit.so.4" not found Now, any command I try to launch gives me this exact same error and my system is then totally useless... :( Anything I could do ? Please please, tell me my box isn't dead... By the way, I compiled CURRENT with dynamic root. Thanks in advance. -- Antoine Jacoutot [EMAIL PROTECTED] http://www.lphp.org PGP/GnuPG key: http://www.lphp.org/ressources/ajacoutot.asc ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure
On Fri, 14 Nov 2003, Munish Chopra wrote: > On 2003-11-14 21:50 +, Matt Smith wrote: > > > > The only thing I've found a problem with so far is postfix as I've > > mentioned. > > While attempting a portupgrade of postfix, I realized ruby core dumps > after the statfs stuff too (even after I rebuilt it). I'm a bit puzzled, > anyone else seeing this or is it a pilot error? What's going on is the following: while we have a compatibility system call in place, it only affects applications linked against non-current libc. As soon as you recompile libc, applications expecting the old statfs() ABI get the new statfs(), and depending on where their smaller struct statfs is located, may stomp on memory they're using for something else (like critical data structures). This means that any application using statfs() and linked against libc.so.5 may start having problems. Not only that, but as you begin to compile new programs, they start expecting the new statfs() API, so if you keep the old libc, they'll start expecting to see extended struct statfs information in a structure that's too small. This is almost certainly a less harmful failure mode than the former. However, it turns out statfs() is used in a fair number of applications (and libraries)... Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADSUP: if_xname changes incoming
On Fri, Nov 14, 2003 at 02:38:34PM -0700, Janet Sullivan wrote: > Brooks Davis wrote: > >On Fri, Oct 31, 2003 at 10:27:35AM -0800, Brooks Davis wrote: > > > >>I will be commiting the if_xname changes momentairly. If you experience > >>any problems with this commit, please let me know ASAP. I'll send an > >>all clear once I've sucessfully built a world/kernel from CVS. > > > >Ok, we're mostly clear. World builds, but I've had to disconnect > >ipfstat, ipnat, and ipftest from the build because they need > >modifications and are on vendor branch. > > Will this be fixed before 5.2-REL? Yes. I don't know if it will make the codefreeze. -- 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 pgp0.pgp Description: PGP signature
Re: Who needs these silly statfs changes...
On Fri, 14 Nov 2003, Peter Edwards wrote:
> Bruce Evans wrote:
>
> > On Fri, 14 Nov 2003, Peter Edwards wrote:
> >> The NFS protocols have unsigned fields where statfs has signed
> >> equivalents: NFS can't represent negative available disk space ( Without
> >> the knowledge of the underlying filesystem on the server, negative free
> >> space is a little nonsensical anyway, I suppose)
> >>
> >> The attached patch stops the NFS server assigning negative values to
> >> unsigned fields in the statfs response, and works against my local
> >> solaris box. Seem reasonable?
> >
> > The client attampts to fix this by pretending that the unsigned fields
> > are signed. -current tries to do more to support file system sizes larger
> > that 1TB, but the code for this is not even wrong except it may be wrong
> > enough to break the negative values. See my reply to one of the PRs
> > for more details.
> >
> > I just got around to testing the patch in that reply:
> > ...
>
> Your patch to nfs_vfsops won't apply to my Solaris kernel :-)
> The protocol says "abytes" is unsigned, so the server shouldn't be lying
> by sending a huge positive value for available space on a full
> filesystem. No?
Possibly not, but the protocol is broken if it actually requires that.
The "free" fields are signed in struct statfs so that they can be negative.
However, this is broken in POSIX's struct statvfs (all count fields have
type fsblkcnt_t or fsfilcnt_t and these are specified to be unsigned).
Is Solaris bug for bug compatible with that?
Anyway, my patch is mainly supposed to fix the scaling. The main bug
in the initial scaling patch was that the huge positive values were
scaled before they were interpreted as negative values, so they became
not so huge but still preposterous values that could not be interpreted
as negative values.
The type pun to negative values is in most versions of BSD:
RELENG_4:
u_quad_t tquad;
...
if (v3) {
sbp->f_bsize = NFS_FABLKSIZE;
tquad = fxdr_hyper(&sfp->sf_tbytes);
sbp->f_blocks = (long)(tquad / ((u_quad_t)NFS_FABLKSIZE));
tquad = fxdr_hyper(&sfp->sf_fbytes);
sbp->f_bfree = (long)(tquad / ((u_quad_t)NFS_FABLKSIZE));
tquad = fxdr_hyper(&sfp->sf_abytes);
sbp->f_bavail = (long)(tquad / ((u_quad_t)NFS_FABLKSIZE));
sbp->f_files = (fxdr_unsigned(int32_t,
sfp->sf_tfiles.nfsuquad[1]) & 0x7fff);
sbp->f_ffree = (fxdr_unsigned(int32_t,
sfp->sf_ffiles.nfsuquad[1]) & 0x7fff);
} else {
sbp->f_bsize = fxdr_unsigned(int32_t, sfp->sf_bsize);
sbp->f_blocks = fxdr_unsigned(int32_t, sfp->sf_blocks);
sbp->f_bfree = fxdr_unsigned(int32_t, sfp->sf_bfree);
sbp->f_bavail = fxdr_unsigned(int32_t, sfp->sf_bavail);
sbp->f_files = 0;
sbp->f_ffree = 0;
}
Oops, this has the cast to long perfectly misplaced so that negative
sizes are not converted like I want. It just prevents warnings.
Overflow has occurred long before, on the server when negative block
counts were converted to hug positive sizes.
NetBSD (nfs_vfsops.c 1.132):
u_quad_t tquad;
...
...
if (v3) {
sbp->f_bsize = NFS_FABLKSIZE;
tquad = fxdr_hyper(&sfp->sf_tbytes);
sbp->f_blocks = (long)((quad_t)tquad / (quad_t)NFS_FABLKSIZE);
tquad = fxdr_hyper(&sfp->sf_fbytes);
sbp->f_bfree = (long)((quad_t)tquad / (quad_t)NFS_FABLKSIZE);
tquad = fxdr_hyper(&sfp->sf_abytes);
sbp->f_bavail = (long)((quad_t)tquad / (quad_t)NFS_FABLKSIZE);
tquad = fxdr_hyper(&sfp->sf_tfiles);
sbp->f_files = (long)tquad;
tquad = fxdr_hyper(&sfp->sf_ffiles);
sbp->f_ffree = (long)tquad;
} else {
sbp->f_bsize = fxdr_unsigned(int32_t, sfp->sf_bsize);
sbp->f_blocks = fxdr_unsigned(int32_t, sfp->sf_blocks);
sbp->f_bfree = fxdr_unsigned(int32_t, sfp->sf_bfree);
sbp->f_bavail = fxdr_unsigned(int32_t, sfp->sf_bavail);
sbp->f_files = 0;
sbp->f_ffree = 0;
}
This converts tquad to quad_t so that the divisions work like I want. These
conversions were added in rev.1.82 in 1999.
More changes are needed here to catch up with the recent changes to struct
statfs in FreeBSD. The casts to long are now just wrong since the block
count fields don't have type long.
Bruce
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure
On 2003-11-14 21:50 +, Matt Smith wrote: > > The only thing I've found a problem with so far is postfix as I've > mentioned. > > Matt. > While attempting a portupgrade of postfix, I realized ruby core dumps after the statfs stuff too (even after I rebuilt it). I'm a bit puzzled, anyone else seeing this or is it a pilot error? -- Munish Chopra ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[current tinderbox] failure on i386/pc98
TB --- 2003-11-14 21:11:44 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-14 21:11:44 - starting CURRENT tinderbox run for i386/pc98 TB --- 2003-11-14 21:11:44 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/pc98 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-14 21:14:47 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything.. TB --- 2003-11-14 22:13:15 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Nov 14 22:13:16 GMT 2003 [...] cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/random/yarrow.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/random/hash.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/crypto/rijndael/rijndael-alg-fst.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/crypto/rijndael/rijndael-api-fst.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/c
Re: HEADS-UP new statfs structure
Daniel Eischen writes: > On Fri, 14 Nov 2003, Andrew Gallatin wrote: > > > > > Kirk McKusick writes: > > > > > > > > And mail/postfix and devel/gnomevfs2 (ones's i've found so far) > > > > <...> > > > > > This is why we make this change now so that it will be in place > > > for the masses when 5.2 is released :-) > > > > Can't we bump the libc version so that dynamically linked, non-system > > binaries can continue to work? Having things like postfix and gnome > > dumping core seems excessivly bumpy. Upgrading all ports is a pain. > > I don't think that's a good idea. I've also got changes in > mind that require a libc version bump, but they aren't ready > now. I was saving them for 6.0. Other folks may also have > similar changes in mind. Do we really want to have yet another > version bump? It costs ~1MB in disk space for each libc bump, yes that's expensive. But so is having many random, non-system applications bomb after you upgrade. Shooting all early adopters in the head is really bad for PR. I think that 1MB of disk space is worth it. > For 6.0, can we start off libc at libc.so.MMDD and move it Yes! Yes! Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: xscreensaver bug?
Terry Lambert wrote: "Eugene M. Kim" wrote: Terry Lambert wrote: I'm new in FreeBSD. I found that after I lock screen with xscreensaver, I can unlock it with the root's password as well as my normal user's password. I don't think it is a good thing. Is it a bug? It is intentional, although you can eliminate it with a recompile of the xscreensaver code, with the right options set. Wouldn't this lead to another security hazard, if a user compile his own hacked xscreensaver which captures and stashes the password into a file then runs it and leaves the terminal intentionally, `baiting' root? :o Not really. This type of thing would need to accept pretty much everything as a termination password, since there no password it can legitimately validate, since a user compiled trojan like this would not have access to the password database contents in order to perform validation. If the trojan is SUID, then they already have root, and don't need the trojan. Either way, there's no risk to just typing whatever crap you want to at it, including a message calling the user an idiot, the first time, to see if it's going to let you in without you giving it the real root password. Validating a root password is possible with other means in many cases, if not always. OpenSSH sshd is a good example. Even with PermitRootLogin set to no, the attacker can differentiate whether the password has been accepted or not. If attacker is able enough, he could also run a hacked version of Xnest on port 6000+N and the real xscreensaver on :N.0 for a suitable N. Attacker would feed the real xscreensaver with the captured password and see if the real xscreensaver releases the server grab. Eugene ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure
On Fri, 14 Nov 2003, Andrew Gallatin wrote: > > Kirk McKusick writes: > > > > > > And mail/postfix and devel/gnomevfs2 (ones's i've found so far) > > <...> > > > This is why we make this change now so that it will be in place > > for the masses when 5.2 is released :-) > > Can't we bump the libc version so that dynamically linked, non-system > binaries can continue to work? Having things like postfix and gnome > dumping core seems excessivly bumpy. Upgrading all ports is a pain. I don't think that's a good idea. I've also got changes in mind that require a libc version bump, but they aren't ready now. I was saving them for 6.0. Other folks may also have similar changes in mind. Do we really want to have yet another version bump? For 6.0, can we start off libc at libc.so.MMDD and move it back to libc.so.6 for the first release? That way we can bump it whenever we want to avoid the "bumpy" rides for -current folk. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure
Bruce Cran wrote: On Fri, Nov 14, 2003 at 08:33:06AM +, Matt Smith wrote: Marco Wertejuk wrote: Just for a short note: cfsd (ports/security/cfs) should be recompiled as well after those statfs changes. And mail/postfix and devel/gnomevfs2 (ones's i've found so far) postfix did this every time it received a mail until I recompiled it: pid 4049 (smtpd), uid 1003: exited on signal 11 And gnomevfs was something I saw in another headsup. There are bound to be others, I'm just keeping an eye on my /var/log/messages to see if anything else sig 11 or 12's! So far so good though. Either the new statfs, or something in a recent change in -CURRENT (since last week), has broken the nvidia driver. I've been using it now for over half a year with no problems at all. I installed the new kernel and world, rebuilt x11/nvidia-driver and X11 hung before it had even switched to graphical mode. After a minute the system rebooted, and unfortunately a couple of lost+found directories were populated by fsck - I must remember to turn off the ata write cache next time! I've now rebuilt *all* of the ports in the hope that it would solve it, but it still crashes. -- Bruce Cran I am using the nvidia driver fine with the latest current: nvidia0: mem 0xfc20-0xfc27,0xf800-0xfbff,0xfd00-0xfdff irq 5 at device 0.0 on pci1 FreeBSD fraggle.xtaz.co.uk 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Thu Nov 13 18:34:54 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FRAGGLE i386 The only thing I've found a problem with so far is postfix as I've mentioned. Matt. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ULE and very bad responsiveness
On Fri, 14 Nov 2003, Jonathan Fosburgh wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Friday 14 November 2003 01:52 pm, Jeff Roberson wrote: > > > > > This does not happen with SCHED_4BSD? How fast is your system? Can you > > give me an example including what applications you're running and what > > you're compiling? > > I haven't tried SCHED_4BSD lately. It will probably be next week before I > have a chance. Basically this is while running things such as konqueror, > kmail, konsole, sometimes Mozilla or Firebird, usually wine for Lotus Notes. > I think I see it more often on building the world, and again mostly with -j, > even set at 4 or 5. This is a 600mHz with ~380M RAM on an ATA drive at > UDMA-66. I suspect that you are experiencing some paging activity. Does top show that any of your swap is in use? You probably don't have enough memory to fit a parallelized buildworld, all the files that it touches, mozilla (60MB on my machine), Xwindows (Another 60mb on my machine), and your window manager, which if you're using kde, is probably at least another 60mb. > > - -- > Jonathan Fosburgh > AIX and Storage Administrator > UT MD Anderson Cancer Center > Houston, TX > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.2.3 (FreeBSD) > > iD8DBQE/tUF5qUvQmqp7omYRAsaSAJ0Y8fZBrNEQ8UcTtf1XfVUHnE3lPwCfcup4 > k4bw4D68b7Lrdf0ygWJ4zrE= > =ZXZ4 > -END PGP SIGNATURE- > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure
On Fri, Nov 14, 2003 at 08:33:06AM +, Matt Smith wrote: > Marco Wertejuk wrote: > >Just for a short note: cfsd (ports/security/cfs) should be > >recompiled as well after those statfs changes. > > > > And mail/postfix and devel/gnomevfs2 (ones's i've found so far) > > postfix did this every time it received a mail until I recompiled it: > > pid 4049 (smtpd), uid 1003: exited on signal 11 > > And gnomevfs was something I saw in another headsup. There are bound to > be others, I'm just keeping an eye on my /var/log/messages to see if > anything else sig 11 or 12's! So far so good though. > Either the new statfs, or something in a recent change in -CURRENT (since last week), has broken the nvidia driver. I've been using it now for over half a year with no problems at all. I installed the new kernel and world, rebuilt x11/nvidia-driver and X11 hung before it had even switched to graphical mode. After a minute the system rebooted, and unfortunately a couple of lost+found directories were populated by fsck - I must remember to turn off the ata write cache next time! I've now rebuilt *all* of the ports in the hope that it would solve it, but it still crashes. -- Bruce Cran ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure
Kirk McKusick writes: > > > > And mail/postfix and devel/gnomevfs2 (ones's i've found so far) <...> > This is why we make this change now so that it will be in place > for the masses when 5.2 is released :-) Can't we bump the libc version so that dynamically linked, non-system binaries can continue to work? Having things like postfix and gnome dumping core seems excessivly bumpy. Upgrading all ports is a pain. Yes, I realize that people upgrading from 4.x won't see this, but people upgrading from 5.1-R will. Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADSUP: if_xname changes incoming
Brooks Davis wrote: On Fri, Oct 31, 2003 at 10:27:35AM -0800, Brooks Davis wrote: I will be commiting the if_xname changes momentairly. If you experience any problems with this commit, please let me know ASAP. I'll send an all clear once I've sucessfully built a world/kernel from CVS. Ok, we're mostly clear. World builds, but I've had to disconnect ipfstat, ipnat, and ipftest from the build because they need modifications and are on vendor branch. Will this be fixed before 5.2-REL? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS-UP new statfs structure
> Date: Fri, 14 Nov 2003 08:33:06 + > From: Matt Smith <[EMAIL PROTECTED]> > To: Marco Wertejuk <[EMAIL PROTECTED]> > Cc: Kirk McKusick <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Subject: Re: HEADS-UP new statfs structure > X-ASK-Info: Whitelist match > > Marco Wertejuk wrote: > > Just for a short note: cfsd (ports/security/cfs) should be > > recompiled as well after those statfs changes. > > > > And mail/postfix and devel/gnomevfs2 (ones's i've found so far) > > postfix did this every time it received a mail until I recompiled it: > > pid 4049 (smtpd), uid 1003: exited on signal 11 > > And gnomevfs was something I saw in another headsup. There are bound to > be others, I'm just keeping an eye on my /var/log/messages to see if > anything else sig 11 or 12's! So far so good though. > > Matt. This is why we make this change now so that it will be in place for the masses when 5.2 is released :-) Kirk McKusick ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[current tinderbox] failure on i386/i386
TB --- 2003-11-14 19:41:58 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-14 19:41:58 - starting CURRENT tinderbox run for i386/i386 TB --- 2003-11-14 19:41:58 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/i386 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-14 19:44:00 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything.. TB --- 2003-11-14 20:42:19 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Nov 14 20:42:19 GMT 2003 >>> Kernel build for GENERIC completed on Fri Nov 14 20:57:10 GMT 2003 TB --- 2003-11-14 20:57:10 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src/sys/i386/conf TB --- /usr/bin/make -B LINT TB --- 2003-11-14 20:57:10 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Nov 14 20:57:10 GMT 2003 [...] cc -O -pipe -mcpu=pentiumpro -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -DKLD_MODULE -nostdinc -I- -include /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/LINT/opt_global.h -I. -I@ -I@/../include -finline-limit=15000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/fs/ntfs/ntfs_iconv.c ld -d -warn-common -r -d -o ntfs_iconv.kld ntfs_iconv.o touch /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/LINT/modules/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/modules/ntfs_iconv/export_syms awk -f /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/modules/ntfs_iconv/../../conf/kmod_syms.awk ntfs_iconv.kld /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/LINT/modules/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/modules/ntfs_iconv/export_syms | xargs -J% objcopy % ntfs_iconv.kld ld -Bshareable -d -warn-common -o ntfs_iconv.ko ntfs_iconv.kld ===> nullfs cc -O -pipe -mcpu=pentiumpro -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -DKLD_MODULE -nostdinc -I- -include /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/LINT/opt_global.h -I. -I@ -I@/../include -finline-limit=15000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/fs/nullfs/null_subr.c /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/fs/nullfs/null_subr.c:311:21: opt_ddb.h: No such file or directory *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/modules/nullfs. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/modules. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/LINT. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. TB --- 2003-11-14 21:11:43 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-11-14 21:11:43 - TB --- ERROR: failed to build lint kernel TB --- 2003-11-14 21:11:43 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ULE and very bad responsiveness
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 14 November 2003 01:52 pm, Jeff Roberson wrote: > > This does not happen with SCHED_4BSD? How fast is your system? Can you > give me an example including what applications you're running and what > you're compiling? I haven't tried SCHED_4BSD lately. It will probably be next week before I have a chance. Basically this is while running things such as konqueror, kmail, konsole, sometimes Mozilla or Firebird, usually wine for Lotus Notes. I think I see it more often on building the world, and again mostly with -j, even set at 4 or 5. This is a 600mHz with ~380M RAM on an ATA drive at UDMA-66. - -- Jonathan Fosburgh AIX and Storage Administrator UT MD Anderson Cancer Center Houston, TX -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/tUF5qUvQmqp7omYRAsaSAJ0Y8fZBrNEQ8UcTtf1XfVUHnE3lPwCfcup4 k4bw4D68b7Lrdf0ygWJ4zrE= =ZXZ4 -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Who needs these silly statfs changes...
Bruce Evans wrote: On Fri, 14 Nov 2003, Peter Edwards wrote: Bernd Walter wrote: On Thu, Nov 13, 2003 at 12:54:18AM -0800, Kris Kennaway wrote: On Thu, Nov 13, 2003 at 06:44:25PM +1100, Peter Jeremy wrote: On Wed, Nov 12, 2003 at 06:04:00PM -0800, Kris Kennaway wrote: ...my sparc machine reports that my i386 nfs server has 15 exabytes of free space! enigma# df -k Filesystem 1K-blocks Used Avail Capacity Mounted on rot13:/mnt2 56595176 54032286 18014398507517260 0% /rot13/mnt2 18014398507517260 = 2^54 - 1964724. and 2^54KB == 2^64 bytes. Is it possible that rot13:/mnt2 has negative free space? (ie it's into the 8-10% reserved area). Yes, that's precisely what it is..the bug is either in df or the kernel (I suspect the latter, i.e. something in the nfs code). And it's nothing new - I'm seeing this since several years now. The NFS protocols have unsigned fields where statfs has signed equivalents: NFS can't represent negative available disk space ( Without the knowledge of the underlying filesystem on the server, negative free space is a little nonsensical anyway, I suppose) The attached patch stops the NFS server assigning negative values to unsigned fields in the statfs response, and works against my local solaris box. Seem reasonable? The client attampts to fix this by pretending that the unsigned fields are signed. -current tries to do more to support file system sizes larger that 1TB, but the code for this is not even wrong except it may be wrong enough to break the negative values. See my reply to one of the PRs for more details. I just got around to testing the patch in that reply: %%% Index: nfs_vfsops.c === RCS file: /home/ncvs/src/sys/nfsclient/nfs_vfsops.c,v Your patch to nfs_vfsops won't apply to my Solaris kernel :-) The protocol says "abytes" is unsigned, so the server shouldn't be lying by sending a huge positive value for available space on a full filesystem. No? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unattended reboot was Re: signal 12's everywhere on Currentwith update this morning.
Eric Anderson wrote: I'm not having any luck - I'm started to feel like I'm missing something here :) I ended up at a very similar stage that you are in. I then did: cp /usr/obj/usr/src/usr.bin/xinstall/install /usr/bin/install chmod 555 /usr/bin/install cd /usr/src/bin/sh make install cd /usr/src make installworld I cvsup'd yesterday afternoon, and did my usual make buildworld, kernel, install kernel, single user mode, then make installworld - except it bombed on the installworld. I ignored the message moved on. So, this morning, I cvsup'ed again, and started over. Here's what I get when doing a make buildworld: -- >>> stage 1.1: legacy release compatibility shims -- ===> tools/build /usr/obj/usr/src/i386/usr/src/tools/build created for /usr/src/tools/build cd /usr/src/tools/build; make buildincludes; make installincludes rm -f .depend mkdep -f .depend -a-I/usr/obj/usr/src/i386/legacy/usr/include /usr/src/tools/build/dummy.c cc -O -pipe -I/usr/obj/usr/src/i386/legacy/usr/include -c /usr/src/tools/build/dummy.c building static egacy library ranlib libegacy.a sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libegacy.a /usr/obj/usr/src/i386/legacy/usr/lib *** Signal 11 Stop in /usr/src/tools/build. *** Error code 1 Stop in /usr/src. *** Error code 1 I've tried rm'ing the /usr/obj subdirs, and even moving /usr/src out of the way and re cvsuping the whole tree, still no luck.. How am I being stupid here? Eric -- Daniel C. Sobral Gerência de Operações Divisão de Comunicação de Dados Coordenação de Segurança VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ULE and very bad responsiveness
On Fri, 14 Nov 2003, Jonathan Fosburgh wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Thursday 13 November 2003 06:01 pm, Harald Schmalzbauer wrote: > > > I also could play quake(2) and have something compiling in the background > > but I see every new object file in form of a picture freeze. Also every > > other disk access seems to block the whole machine for a moment. > > I'll try again if somebody has an idea what's wrong. Then I can try running > > seti wtih nice 20 but that's not really a solution. It's working perfectly > > with nice 15 and the old scheduler. > > > > I see something similar, as a file is generated during a compile a get a > momentary hang in the mouse, but it is not every compile. I think I see it > mostly when running some invocation of make -j, but I've not been able to > lock down a particular set of circumstances where I do see it. My > sched_ule.c is at 1.80. I have a UP system. This behaviour, intermittant > though it is, persists across a normal UP kernel, and also one with SMP+APIC > (I was *supposed* to have two CPUs, but that is another issue ...) enabled. I > have a PS/2 mouse and use moused. I'm running KDE3.1.4. This does not happen with SCHED_4BSD? How fast is your system? Can you give me an example including what applications you're running and what you're compiling? > - -- > Jonathan Fosburgh > AIX and Storage Administrator > UT MD Anderson Cancer Center > Houston, TX > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.2.3 (FreeBSD) > > iD8DBQE/tNYwqUvQmqp7omYRAnzjAKCx8by6w77iT5G+7NiBOC8lVkxJ3QCcDgWP > J9I+Sgx4yuzqOOQ+Gu9Ge3s= > =GEi2 > -END PGP SIGNATURE- > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Who needs these silly statfs changes...
On Fri, 14 Nov 2003, Peter Edwards wrote:
> Bernd Walter wrote:
>
> >On Thu, Nov 13, 2003 at 12:54:18AM -0800, Kris Kennaway wrote:
> >
> >
> >>On Thu, Nov 13, 2003 at 06:44:25PM +1100, Peter Jeremy wrote:
> >>
> >>
> >>>On Wed, Nov 12, 2003 at 06:04:00PM -0800, Kris Kennaway wrote:
> >>>
> >>>
> ...my sparc machine reports that my i386 nfs server has 15 exabytes of
> free space!
>
> enigma# df -k
> Filesystem 1K-blocks Used Avail Capacity Mounted on
> rot13:/mnt2 56595176 54032286 18014398507517260 0%/rot13/mnt2
>
>
> >>>18014398507517260 = 2^54 - 1964724. and 2^54KB == 2^64 bytes. Is it
> >>>possible that rot13:/mnt2 has negative free space? (ie it's into the
> >>>8-10% reserved area).
> >>>
> >>>
> >>Yes, that's precisely what it is..the bug is either in df or the
> >>kernel (I suspect the latter, i.e. something in the nfs code).
> >>
> >>
> >
> >And it's nothing new - I'm seeing this since several years now.
> >
> >
>
> The NFS protocols have unsigned fields where statfs has signed
> equivalents: NFS can't represent negative available disk space ( Without
> the knowledge of the underlying filesystem on the server, negative free
> space is a little nonsensical anyway, I suppose)
>
> The attached patch stops the NFS server assigning negative values to
> unsigned fields in the statfs response, and works against my local
> solaris box. Seem reasonable?
The client attampts to fix this by pretending that the unsigned fields
are signed. -current tries to do more to support file system sizes larger
that 1TB, but the code for this is not even wrong except it may be wrong
enough to break the negative values. See my reply to one of the PRs
for more details.
I just got around to testing the patch in that reply:
%%%
Index: nfs_vfsops.c
===
RCS file: /home/ncvs/src/sys/nfsclient/nfs_vfsops.c,v
retrieving revision 1.143
diff -u -2 -r1.143 nfs_vfsops.c
--- nfs_vfsops.c12 Nov 2003 02:54:46 - 1.143
+++ nfs_vfsops.c12 Nov 2003 14:37:46 -
@@ -223,5 +223,5 @@
struct mbuf *mreq, *mrep, *md, *mb;
struct nfsnode *np;
- u_quad_t tquad;
+ quad_t tquad;
int bsize;
@@ -254,19 +254,19 @@
for (bsize = NFS_FABLKSIZE; ; bsize *= 2) {
sbp->f_bsize = bsize;
- tquad = fxdr_hyper(&sfp->sf_tbytes);
- if (((long)(tquad / bsize) > LONG_MAX) ||
- ((long)(tquad / bsize) < LONG_MIN))
+ tquad = (quad_t)fxdr_hyper(&sfp->sf_tbytes) / bsize;
+ if (bsize <= INT_MAX / 2 &&
+ (tquad > LONG_MAX || tquad < LONG_MIN))
continue;
- sbp->f_blocks = tquad / bsize;
- tquad = fxdr_hyper(&sfp->sf_fbytes);
- if (((long)(tquad / bsize) > LONG_MAX) ||
- ((long)(tquad / bsize) < LONG_MIN))
+ sbp->f_blocks = tquad;
+ tquad = (quad_t)fxdr_hyper(&sfp->sf_fbytes) / bsize;
+ if (bsize <= INT_MAX / 2 &&
+ (tquad > LONG_MAX || tquad < LONG_MIN))
continue;
- sbp->f_bfree = tquad / bsize;
- tquad = fxdr_hyper(&sfp->sf_abytes);
- if (((long)(tquad / bsize) > LONG_MAX) ||
- ((long)(tquad / bsize) < LONG_MIN))
+ sbp->f_bfree = tquad;
+ tquad = (quad_t)fxdr_hyper(&sfp->sf_abytes) / bsize;
+ if (bsize <= INT_MAX / 2 &&
+ (tquad > LONG_MAX || tquad < LONG_MIN))
continue;
- sbp->f_bavail = tquad / bsize;
+ sbp->f_bavail = tquad;
sbp->f_files = (fxdr_unsigned(int32_t,
sfp->sf_tfiles.nfsuquad[1]) & 0x7fff);
%%%
This seems to work. On a 2TB-epsilon ffs1 file system (*) on an md malloc
disk (**):
server:
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/md0 21474168960 1975624000 0%/b
client:
Filesystem 1024-blocks Used Avail Capacity Mounted on
besplex:/b 21474168960 1975624000 0%/b
These are 1K-blocks so their count fits in an int32_t, but the count in
512-blocks is too large for an int32_t so the scaling must be helping.
With newfs -m 100 (***) to get near negative free space:
server:
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/md0 21474168960 5696 0%/b
client:
Filesystem 1K-blocks Used Avail Capacity Mounted on
besplex:/b 21474168960 5696 0%/b
After using up all the free space by creating a 6MB file:
server:
Filesystem 1K-blocks Used Avail Capacity Mo
exclusive sleep mutex sigacts
John, I believe you've already seen the assertion fire, so this may be redundant info: kernel: checking stopevent 2 with the following non-sleepable \ locks held: kernel: exclusive sleep mutex sigacts r = 0 (0xc4a25aa8) locked \ locked @ /usr/src/sys/kern/subr_trap.c:260 Note the assertation also flags sys/kern/kern_synch.c:293 sys/kern/keren_condvar.c:289 -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unattended reboot was Re: signal 12's everywhere on Current with update this morning.
Dag-Erling Smørgrav wrote: > [EMAIL PROTECTED] writes: > >>I'm building new kernels as I write this. My next question is: >>One of the machines I'm building on is remote and was last rebuilt >>just before the change. What would be be better sequence for making >>the change after a fresh cvsup ? > > > RTFM. > > make buildworld > make buildkernel > make installkernel > reboot > make installworld > mergemaster > reboot > > DES I found that if I put /rescue in my PATH before all the normal stuff, things tend to work (like ls). For me I got caught doing the: make buildworld make buildkernel KERNCONF=FOO make installkernel mergemaster make installworld BAM! installworld fails, and the signal 12's start to manifest. I'm afraid to reboot at this point, and decided to backup my stuff before proceeding with anything (rebooting) that might result in my system becoming utterly useless. Should I manually copy the items in /usr/obj to their final destination, or take my chances with a reboot? Maybe wait for the jpsnap to catchup and boot a -current livecd to finish the makeinstall? I'm seeking the path of least resistance which involves anything other than flattening my -current install. Thanks in advance =) __ __ _ | \/ | __ _ ___| |_ __ _ | |\/| |/ _` / __| __/ _` | | | | | (_| \__ \ || (_| | |_| |_|\__,_|___/\__\__,_| unzip ; strip ; touch ; finger ; mount ; fsck ; more ; yes ; umount ; sleep [EMAIL PROTECTED] http://wifibsd.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
pcm audio problems
Hi! I'm running a very recent -current(13 november) and am having problems with audio. I;m running on a Gigabyte 7VM400M Mother board, the boot message about pcm is the following: pcm0: port 0xe400-0xe4ff irq 11 at device 17.5 on pci0 pcm0: This has worked on 5.1-RELEASE(but I did not test much, upgraded to -current after a few days) and started showing problems with a -current from 10 november, with that it played audio but I had a pair of audio related crashes and anyway the output was jerky. Now it's almost non working, catting to /dev/dsp gives no output, xmms hangs on play and mplayer slows down waiting for something on the audio device producing some really horrible sound on the speakers(while disabling audio the video goes real smooth as expected). I think something got broken in the last updates. Hope someone can have a look. Thanks in andance, I'm ready to give any info and try any patches needed. -- Guido Falsi <[EMAIL PROTECTED]> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fwd: propgagate_priority() crashes: recursive msleep() ??
John Baldwin wrote:
On 14-Nov-2003 Peter Edwards wrote:
(Aplogies if this message is a duplicate: The original is AWOL for quite
a while now)
Hi,
I'm getting a crash in propagate priority, as mentioned by a few people recently. Bug
reports and
comments about it seemed to have dropped off, so given that I can reliably reproduce
it, I was
trying to work out why it's going on.
One thing I found quite odd was the following stack trace. It appears that msleep() is
being
called recursively via cursig() calling stopevent. When msleep calls cursig(), it has
temporarily
dropped Giant. Surely this is bogus? (This is from a a kernel updated in the last few
hours)
#0 sched_switch (td=0xc4b30780) at /scratch/src/sys/kern/sched_4bsd.c:606
#1 0xc050d8db in mi_switch () at /scratch/src/sys/kern/kern_synch.c:514
#2 0xc050cf7f in msleep (ident=0xc4dc2bc8, mtx=0xc4dc2b04, priority=92, wmesg=0x0,
timo=0) at /scratch/src/sys/kern/kern_synch.c:255
#3 0xc0534255 in stopevent (p=0xc4dc2a98, event=2, val=2)
at /scratch/src/sys/kern/sys_process.c:740
#4 0xc0509362 in issignal (td=0xc4b30780) at /scratch/src/sys/kern/kern_sig.c:2082
#5 0xc0504eb8 in cursig (td=0xc4b30780) at /scratch/src/sys/sys/signalvar.h:227
#6 0xc050d0f2 in msleep (ident=0xc4dc2a98, mtx=0xc4dc2b04, priority=348, wmesg=0x0,
timo=0) at /scratch/src/sys/kern/kern_synch.c:294
#7 0xc04eb82f in wait1 (td=0xc4b30780, uap=0xddcd6d10, compat=0)
at /scratch/src/sys/kern/kern_exit.c:766
#8 0xc04eab90 in wait4 (td=0x0, uap=0x0) at /scratch/src/sys/kern/kern_exit.c:548
#9 0xc06241d0 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134899628, tf_esi = 134912305, tf_ebp =
-1077943784, tf_isp = -573739660, tf_ebx = 772, tf_edx = 135012352, tf_ecx = 13, tf_eax = 7,
tf_trapno = 12, tf_err = 2, tf_eip = 134525375, tf_cs = 31, tf_eflags = 646, tf_esp =
-1077943812, tf_ss = 47}) at /scratch/src/sys/i386/i386/trap.c:1010
Are you using gdb or something else that does ptrace? Jeff has pointed
out why pp panics here, because this thread owns the sigacts lock while
asleep. However, doing a double sleep like this is very bogus and bad.
G.
I was using "truss": the actual command I ran was
# truss mount unreachablehost:/mnt /mnt
(where "unreachablehost" was the IP address of a host I had no route to)
IIRC, the panicing thread was in softclock (possibly handling the
terminal ^C, not sure), the mount command was waiting on the mount_nfs
child to finish, and I assume the mount_nfs child was waiting in vain
for a response it was never going to get.
But, I suppose any traced process arriving in msleep (or cursig) is
problematic.
Silly question: Could the STOPEVENT stuff in issignal() just be delayed
until userret()? I thought that was done for some other similar
circumstances.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Teach '-m' option of bsdlabel(8) to sunlabel(8)
On Fri, Nov 14, 2003 at 06:07:17PM +0900, Makoto Matsushita wrote: > > Self followup... > > matusita> I'd like to try to bulid FreeBSD/sparc64 on i386 box, but > matusita> due to the lack of bsdlabel(8)'s '-m' option (set machine > matusita> archtecture) on sunlabel(8), newfs(8) cannot work. > > I'm confused something. The fact that newfs(8) on i386 cannot newfs a > filesystem which is sunlabel(8)ed is true, but it does NOT come with > sunlabel(8) itself. Obviously sunlabel(8) doesn't need -m option since > it is used on on sparc64 :-) > > Anyway how can I newfs a filesystem for sparc64 on i386 box? I don't think you can because our UFS on disk format is byte order dependent. Someone probalby needs to import the NetBSD endien-independence stuff. -- 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 pgp0.pgp Description: PGP signature
Re: signal 12's everywhere on Current with update this morning.
+---[ Edmund L. Wong ]-- | | I am able to get myself to a single-user prompt as | root, but not much else. Does anyone have any | suggestions as to how I can salvage this? Or will I | have to reinstall anew? Boot from a live/fixit CD/floppy, and mount your drives and rebuild and install the kernel? Having a bootable live cd around can be a lifesaver. -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | M:+61 416 022 411 | ACN: 082 081 472 ABN: 83 082 081 472 |[EMAIL PROTECTED]| Carpe Daemon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: signal 12's everywhere on Current with update this morning.
Thanks Richard. So unfortunately, I was an idiot and ran installworld without rebuilding and installing a new kernel (the one I have was built on Nov. 1). Now everything coredumps, including rm, ls, etc. I cannot make installworld, installkernel, buildworld or buildkernel. I am able to get myself to a single-user prompt as root, but not much else. Does anyone have any suggestions as to how I can salvage this? Or will I have to reinstall anew? (for those in freebsd-questions, I apologize in advance, I asked there earlier this morning as well) Thanks, Ed --- Richard Coleman <[EMAIL PROTECTED]> wrote: > Sure. I can do that. Some structures in statfs > changed size. So you > need to rebuild and install your kernel before you > update the world. > The instructions in the handbook should work just > fine. > > 1. make buildworld > 2. make buildkernel KERNCONF=NAME_OF_KERNEL_FILE > 3. make installkernel KERNCONF=NAME_OF_KERNEL_FILE > 4. shutdown -r now > 5. boot into single user mode > 6. fsck -p > 7. mount -u / > 8. mount -a -t ufs > 9. swapon -a > 10. make installworld > 11. mergemaster > 12. reboot > > There are a couple ports that also need rebuilt. > I've heard cfs and > postfix mentioned. There could be more. If you > don't have many ports, > just rebuild them all (that's what I'm doing). If > you are using > portupgrade, it's easy (portupgrade -afR). > Obviously this could take > awhile. > > Richard Coleman > [EMAIL PROTECTED] > > Edmund L. Wong wrote: > > > Could someone bring me up to speed on this thread? > I > > just joined current and I also updated this > morning > > and have all kinds of issues. > > > > THanks, > > Ed > > > > > > --- Richard Coleman > <[EMAIL PROTECTED]> > > wrote: > > > >>Someone just needs to bring the build(7) man page > up > >>to date with the > >>handbook. > >> > >>Also, I noticed that build(7) still lists the > >>"installmost" build > >>target. I believe that was removed. > >> > >>I would file a PR except that my man pages always > >>suck. > >> > >>Richard Coleman > >>[EMAIL PROTECTED] > >> > >>Brent Jones wrote: > >> > >> > >>>If this is true, perhaps the "build" man page > >> > >>should be updated. Here's > >> > >>>what the man page has to say on the topic: > >>> > >>> The ``approved'' method of updating your > >> > >>system from the latest > >> > >>>sources > >>> is: > >>> > >>> make buildworld > >>> make buildkernel KERNCONF=FOO > >>> make installkernel KERNCONF=FOO > >>> make installworld > >>> mergemaster > >>> > >>> After running these commands a system reboot > >> > >>is required... > >> > >>>This gives the impression that you're safe > running > >> > >>all the builds > >> > >>>without rebooting, especially as the word > >> > >>"approved" is used. > >> > >>>Brent > >>> > >>>On Nov 13, 2003, at 11:18 PM, M. Warner Losh > >> > >>wrote: > >> > In message: <[EMAIL PROTECTED]> > Uwe Laverenz > <[EMAIL PROTECTED]> > >> > >>writes: > >> > : [EMAIL PROTECTED] schrieb: > : > : > Uwe, do you have any remote machines? I'm > >> > >>wondering what the correct > >> > : > sequence would be to update and reboot them. > : > : I would suggest to do it this way: > : > : 1. make buildworld > : 2. make kernel KERNCONF= > : 3. *reboot* (with new kernel and old userland) > > Into single user... > > : 4. make installworld > : 5. mergemaster > : 6. *reboot* > > This is the order that's recommended in UPDATING > >> > >>since 3.something. > >> > Warner > >> > >> > >> > >>___ > >>[EMAIL PROTECTED] mailing list > >> > > > > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > > >>To unsubscribe, send any mail to > > > > "[EMAIL PROTECTED]" > > > > > > = > > edmund l wong > > assistant staff : mit lincoln lab > > cs/ece alumni : carnegie mellon > > > > [EMAIL PROTECTED] > > http://www.edmundlwong.com > > > = edmund l wong assistant staff : mit lincoln lab cs/ece alumni : carnegie mellon [EMAIL PROTECTED] http://www.edmundlwong.com __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ultra5 ATA issues
Doug White <[EMAIL PROTECTED]> writes: > I replaced the default seagate with a Maxtor, but I don't have to demote > to PIO on 5.1-REL. I'll try disabling DMA on it today. i'm also trying > to iterate ata-lowlevel.c to see if I can find a specific break point. 45 > minute kernel compiles don't help. :( You can easily cross-build kernels on a faster machine... DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: signal 12's everywhere on Current with update this morning.
Sure. I can do that. Some structures in statfs changed size. So you need to rebuild and install your kernel before you update the world. The instructions in the handbook should work just fine. 1. make buildworld 2. make buildkernel KERNCONF=NAME_OF_KERNEL_FILE 3. make installkernel KERNCONF=NAME_OF_KERNEL_FILE 4. shutdown -r now 5. boot into single user mode 6. fsck -p 7. mount -u / 8. mount -a -t ufs 9. swapon -a 10. make installworld 11. mergemaster 12. reboot There are a couple ports that also need rebuilt. I've heard cfs and postfix mentioned. There could be more. If you don't have many ports, just rebuild them all (that's what I'm doing). If you are using portupgrade, it's easy (portupgrade -afR). Obviously this could take awhile. Richard Coleman [EMAIL PROTECTED] Edmund L. Wong wrote: Could someone bring me up to speed on this thread? I just joined current and I also updated this morning and have all kinds of issues. THanks, Ed --- Richard Coleman <[EMAIL PROTECTED]> wrote: Someone just needs to bring the build(7) man page up to date with the handbook. Also, I noticed that build(7) still lists the "installmost" build target. I believe that was removed. I would file a PR except that my man pages always suck. Richard Coleman [EMAIL PROTECTED] Brent Jones wrote: If this is true, perhaps the "build" man page should be updated. Here's what the man page has to say on the topic: The ``approved'' method of updating your system from the latest sources is: make buildworld make buildkernel KERNCONF=FOO make installkernel KERNCONF=FOO make installworld mergemaster After running these commands a system reboot is required... This gives the impression that you're safe running all the builds without rebooting, especially as the word "approved" is used. Brent On Nov 13, 2003, at 11:18 PM, M. Warner Losh wrote: In message: <[EMAIL PROTECTED]> Uwe Laverenz <[EMAIL PROTECTED]> writes: : [EMAIL PROTECTED] schrieb: : : > Uwe, do you have any remote machines? I'm wondering what the correct : > sequence would be to update and reboot them. : : I would suggest to do it this way: : : 1. make buildworld : 2. make kernel KERNCONF= : 3. *reboot* (with new kernel and old userland) Into single user... : 4. make installworld : 5. mergemaster : 6. *reboot* This is the order that's recommended in UPDATING since 3.something. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]" = edmund l wong assistant staff : mit lincoln lab cs/ece alumni : carnegie mellon [EMAIL PROTECTED] http://www.edmundlwong.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Ultra5 ATA issues
Move to -current and drop wilko. On Fri, 14 Nov 2003, Dag-Erling [iso-8859-1] Smørgrav wrote: > Jesper Skriver <[EMAIL PROTECTED]> writes: > > On Fri, Nov 14, 2003 at 09:32:46AM +0100, Dag-Erling Smørgrav wrote: > > > Doug White <[EMAIL PROTECTED]> writes: > > > > Good! Maybe you can fix -current on them :) > > > Uh? -CURRENT runs just fine on my U5. > > Do you use the default ATA controller and drive ? > > On-board ATA controller, but a different drive (the original was only > two or three gig or so). Works fine in PIO4 if you disable DMA at > boot. ISTR 5.1-RELEASE tried to use DMA, failed, and fell back to > PIO4, while atang hangs when DMA fails, so I've disabled it in > loader.conf. I believe this has been discussed on the -sparc64 list; > see the archives for details. I replaced the default seagate with a Maxtor, but I don't have to demote to PIO on 5.1-REL. I'll try disabling DMA on it today. i'm also trying to iterate ata-lowlevel.c to see if I can find a specific break point. 45 minute kernel compiles don't help. :( -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: signal 12's everywhere on Current with update this morning.
Could someone bring me up to speed on this thread? I just joined current and I also updated this morning and have all kinds of issues. THanks, Ed --- Richard Coleman <[EMAIL PROTECTED]> wrote: > Someone just needs to bring the build(7) man page up > to date with the > handbook. > > Also, I noticed that build(7) still lists the > "installmost" build > target. I believe that was removed. > > I would file a PR except that my man pages always > suck. > > Richard Coleman > [EMAIL PROTECTED] > > Brent Jones wrote: > > > If this is true, perhaps the "build" man page > should be updated. Here's > > what the man page has to say on the topic: > > > > The ``approved'' method of updating your > system from the latest > > sources > > is: > > > >make buildworld > >make buildkernel KERNCONF=FOO > >make installkernel KERNCONF=FOO > >make installworld > >mergemaster > > > > After running these commands a system reboot > is required... > > > > This gives the impression that you're safe running > all the builds > > without rebooting, especially as the word > "approved" is used. > > > > Brent > > > > On Nov 13, 2003, at 11:18 PM, M. Warner Losh > wrote: > > > >> In message: <[EMAIL PROTECTED]> > >> Uwe Laverenz <[EMAIL PROTECTED]> > writes: > >> : [EMAIL PROTECTED] schrieb: > >> : > >> : > Uwe, do you have any remote machines? I'm > wondering what the correct > >> : > sequence would be to update and reboot them. > >> : > >> : I would suggest to do it this way: > >> : > >> : 1. make buildworld > >> : 2. make kernel KERNCONF= > >> : 3. *reboot* (with new kernel and old userland) > >> > >> Into single user... > >> > >> : 4. make installworld > >> : 5. mergemaster > >> : 6. *reboot* > >> > >> This is the order that's recommended in UPDATING > since 3.something. > >> > >> Warner > > > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" = edmund l wong assistant staff : mit lincoln lab cs/ece alumni : carnegie mellon [EMAIL PROTECTED] http://www.edmundlwong.com __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Fwd: propgagate_priority() crashes: recursive msleep() ??
On 14-Nov-2003 Peter Edwards wrote:
> (Aplogies if this message is a duplicate: The original is AWOL for quite
> a while now)
>
> Hi,
> I'm getting a crash in propagate priority, as mentioned by a few people recently.
> Bug reports and
> comments about it seemed to have dropped off, so given that I can reliably reproduce
> it, I was
> trying to work out why it's going on.
>
> One thing I found quite odd was the following stack trace. It appears that msleep()
> is being
> called recursively via cursig() calling stopevent. When msleep calls cursig(), it
> has temporarily
> dropped Giant. Surely this is bogus? (This is from a a kernel updated in the last
> few hours)
>
>#0 sched_switch (td=0xc4b30780) at /scratch/src/sys/kern/sched_4bsd.c:606
>#1 0xc050d8db in mi_switch () at /scratch/src/sys/kern/kern_synch.c:514
>#2 0xc050cf7f in msleep (ident=0xc4dc2bc8, mtx=0xc4dc2b04, priority=92, wmesg=0x0,
> timo=0) at /scratch/src/sys/kern/kern_synch.c:255
>#3 0xc0534255 in stopevent (p=0xc4dc2a98, event=2, val=2)
> at /scratch/src/sys/kern/sys_process.c:740
>#4 0xc0509362 in issignal (td=0xc4b30780) at /scratch/src/sys/kern/kern_sig.c:2082
>#5 0xc0504eb8 in cursig (td=0xc4b30780) at /scratch/src/sys/sys/signalvar.h:227
>#6 0xc050d0f2 in msleep (ident=0xc4dc2a98, mtx=0xc4dc2b04, priority=348, wmesg=0x0,
> timo=0) at /scratch/src/sys/kern/kern_synch.c:294
>#7 0xc04eb82f in wait1 (td=0xc4b30780, uap=0xddcd6d10, compat=0)
> at /scratch/src/sys/kern/kern_exit.c:766
>#8 0xc04eab90 in wait4 (td=0x0, uap=0x0) at /scratch/src/sys/kern/kern_exit.c:548
>#9 0xc06241d0 in syscall (frame=
> {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134899628, tf_esi = 134912305,
> tf_ebp =
> -1077943784, tf_isp = -573739660, tf_ebx = 772, tf_edx = 135012352, tf_ecx = 13,
> tf_eax = 7,
> tf_trapno = 12, tf_err = 2, tf_eip = 134525375, tf_cs = 31, tf_eflags = 646, tf_esp =
> -1077943812, tf_ss = 47}) at /scratch/src/sys/i386/i386/trap.c:1010
Are you using gdb or something else that does ptrace? Jeff has pointed
out why pp panics here, because this thread owns the sigacts lock while
asleep. However, doing a double sleep like this is very bogus and bad.
G.
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: signal 12's everywhere on Current with update this morning.
Someone just needs to bring the build(7) man page up to date with the handbook. Also, I noticed that build(7) still lists the "installmost" build target. I believe that was removed. I would file a PR except that my man pages always suck. Richard Coleman [EMAIL PROTECTED] Brent Jones wrote: If this is true, perhaps the "build" man page should be updated. Here's what the man page has to say on the topic: The ``approved'' method of updating your system from the latest sources is: make buildworld make buildkernel KERNCONF=FOO make installkernel KERNCONF=FOO make installworld mergemaster After running these commands a system reboot is required... This gives the impression that you're safe running all the builds without rebooting, especially as the word "approved" is used. Brent On Nov 13, 2003, at 11:18 PM, M. Warner Losh wrote: In message: <[EMAIL PROTECTED]> Uwe Laverenz <[EMAIL PROTECTED]> writes: : [EMAIL PROTECTED] schrieb: : : > Uwe, do you have any remote machines? I'm wondering what the correct : > sequence would be to update and reboot them. : : I would suggest to do it this way: : : 1. make buildworld : 2. make kernel KERNCONF= : 3. *reboot* (with new kernel and old userland) Into single user... : 4. make installworld : 5. mergemaster : 6. *reboot* This is the order that's recommended in UPDATING since 3.something. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: signal 12's everywhere on Current with update this morning.
In message: <[EMAIL PROTECTED]> Brent Jones <[EMAIL PROTECTED]> writes: : If this is true, perhaps the "build" man page should be updated. : Here's what the man page has to say on the topic: : : The ``approved'' method of updating your system from the latest : sources : is: Already done. : make buildworld : make buildkernel KERNCONF=FOO : make installkernel KERNCONF=FOO : make installworld : mergemaster : : After running these commands a system reboot is required... : : This gives the impression that you're safe running all the builds : without rebooting, especially as the word "approved" is used. Yes. I just added a 'reboot to single user here' line. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: signal 12's everywhere on Current with update this morning.
If this is true, perhaps the "build" man page should be updated. Here's what the man page has to say on the topic: The ``approved'' method of updating your system from the latest sources is: make buildworld make buildkernel KERNCONF=FOO make installkernel KERNCONF=FOO make installworld mergemaster After running these commands a system reboot is required... This gives the impression that you're safe running all the builds without rebooting, especially as the word "approved" is used. Brent On Nov 13, 2003, at 11:18 PM, M. Warner Losh wrote: In message: <[EMAIL PROTECTED]> Uwe Laverenz <[EMAIL PROTECTED]> writes: : [EMAIL PROTECTED] schrieb: : : > Uwe, do you have any remote machines? I'm wondering what the correct : > sequence would be to update and reboot them. : : I would suggest to do it this way: : : 1. make buildworld : 2. make kernel KERNCONF= : 3. *reboot* (with new kernel and old userland) Into single user... : 4. make installworld : 5. mergemaster : 6. *reboot* This is the order that's recommended in UPDATING since 3.something. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unattended reboot was Re: signal 12's everywhere on Currentwith update this morning.
Sheldon Hearn wrote: On (2003/11/13 14:02), Eric Anderson wrote: I'm not having any luck - I'm started to feel like I'm missing something here :) I cvsup'd yesterday afternoon, and did my usual make buildworld, kernel, install kernel, single user mode, then make installworld - except it bombed on the installworld. I ignored the message moved on. You missed a step. The HEADS UP sent to -current said you needed to reboot between kernel install and world install. This is the strictly safe way of upgrading always. However, many people skip the reboot (and even the drop to single-user mode) as a shortcut. Sometimes, the shortcut works. This time, it doesn't. :-) Unfortunately, I had unsubscribed myself from the list a few weeks ago when I went to a Usenix conference, and forgot to resubscribe! Woops. All fixed up now though. At least now I know what I did wrong - thanks! Eric -- -- Eric Anderson Systems Administrator Centaur Technology All generalizations are false, including this one. -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Who needs these silly statfs changes...
Bernd Walter wrote: On Thu, Nov 13, 2003 at 12:54:18AM -0800, Kris Kennaway wrote: On Thu, Nov 13, 2003 at 06:44:25PM +1100, Peter Jeremy wrote: On Wed, Nov 12, 2003 at 06:04:00PM -0800, Kris Kennaway wrote: ...my sparc machine reports that my i386 nfs server has 15 exabytes of free space! enigma# df -k Filesystem 1K-blocks Used Avail Capacity Mounted on rot13:/mnt2 56595176 54032286 18014398507517260 0%/rot13/mnt2 18014398507517260 = 2^54 - 1964724. and 2^54KB == 2^64 bytes. Is it possible that rot13:/mnt2 has negative free space? (ie it's into the 8-10% reserved area). Yes, that's precisely what it is..the bug is either in df or the kernel (I suspect the latter, i.e. something in the nfs code). And it's nothing new - I'm seeing this since several years now. The NFS protocols have unsigned fields where statfs has signed equivalents: NFS can't represent negative available disk space ( Without the knowledge of the underlying filesystem on the server, negative free space is a little nonsensical anyway, I suppose) The attached patch stops the NFS server assigning negative values to unsigned fields in the statfs response, and works against my local solaris box. Seem reasonable? Index: nfs_serv.c === RCS file: /pub/FreeBSD/development/FreeBSD-CVS/src/sys/nfsserver/nfs_serv.c,v retrieving revision 1.137 diff -u -r1.137 nfs_serv.c --- nfs_serv.c 24 Oct 2003 18:36:49 - 1.137 +++ nfs_serv.c 14 Nov 2003 13:27:42 - @@ -3812,7 +3812,7 @@ tval = (u_quad_t)sf->f_bfree; tval *= (u_quad_t)sf->f_bsize; txdr_hyper(tval, &sfp->sf_fbytes); - tval = (u_quad_t)sf->f_bavail; + tval = sf->f_bavail > 0 ? (u_quad_t)sf->f_bavail : 0; tval *= (u_quad_t)sf->f_bsize; txdr_hyper(tval, &sfp->sf_abytes); sfp->sf_tfiles.nfsuquad[0] = 0; @@ -3827,7 +3827,8 @@ sfp->sf_bsize = txdr_unsigned(sf->f_bsize); sfp->sf_blocks = txdr_unsigned(sf->f_blocks); sfp->sf_bfree = txdr_unsigned(sf->f_bfree); - sfp->sf_bavail = txdr_unsigned(sf->f_bavail); + sfp->sf_bavail = txdr_unsigned(sf->f_bavail > 0 ? + sf->f_bavail : 0); } nfsmout: if (vp) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ULE and very bad responsiveness
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 13 November 2003 06:01 pm, Harald Schmalzbauer wrote: > I also could play quake(2) and have something compiling in the background > but I see every new object file in form of a picture freeze. Also every > other disk access seems to block the whole machine for a moment. > I'll try again if somebody has an idea what's wrong. Then I can try running > seti wtih nice 20 but that's not really a solution. It's working perfectly > with nice 15 and the old scheduler. > I see something similar, as a file is generated during a compile a get a momentary hang in the mouse, but it is not every compile. I think I see it mostly when running some invocation of make -j, but I've not been able to lock down a particular set of circumstances where I do see it. My sched_ule.c is at 1.80. I have a UP system. This behaviour, intermittant though it is, persists across a normal UP kernel, and also one with SMP+APIC (I was *supposed* to have two CPUs, but that is another issue ...) enabled. I have a PS/2 mouse and use moused. I'm running KDE3.1.4. - -- Jonathan Fosburgh AIX and Storage Administrator UT MD Anderson Cancer Center Houston, TX -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/tNYwqUvQmqp7omYRAnzjAKCx8by6w77iT5G+7NiBOC8lVkxJ3QCcDgWP J9I+Sgx4yuzqOOQ+Gu9Ge3s= =GEi2 -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
using HEAD's /etc/rc.d/jail on RELENG_5_1
Hi, I'd like get the enhancements of version 1.6 of /etc/rc.d/jail in RELENG_5_1, but I need some help/clarification: 1.- Is there any know pitfall? 2.- What's the safest & easiest way to do it? assuming the answer to 2.- is "patch your source and upgrade" 3.- What's the one liner to create the patch needed (how much of etc/ do I need to get)? tks -- pica ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Fwd: propgagate_priority() crashes: recursive msleep() ??
(Aplogies if this message is a duplicate: The original is AWOL for quite
a while now)
Hi,
I'm getting a crash in propagate priority, as mentioned by a few people recently. Bug
reports and comments about it seemed to have dropped off, so given that I can reliably
reproduce it, I was trying to work out why it's going on.
One thing I found quite odd was the following stack trace. It appears that msleep() is being called recursively via cursig() calling stopevent. When msleep calls cursig(), it has temporarily dropped Giant. Surely this is bogus? (This is from a a kernel updated in the last few hours)
#0 sched_switch (td=0xc4b30780) at /scratch/src/sys/kern/sched_4bsd.c:606
#1 0xc050d8db in mi_switch () at /scratch/src/sys/kern/kern_synch.c:514
#2 0xc050cf7f in msleep (ident=0xc4dc2bc8, mtx=0xc4dc2b04, priority=92, wmesg=0x0,
timo=0) at /scratch/src/sys/kern/kern_synch.c:255
#3 0xc0534255 in stopevent (p=0xc4dc2a98, event=2, val=2)
at /scratch/src/sys/kern/sys_process.c:740
#4 0xc0509362 in issignal (td=0xc4b30780) at /scratch/src/sys/kern/kern_sig.c:2082
#5 0xc0504eb8 in cursig (td=0xc4b30780) at /scratch/src/sys/sys/signalvar.h:227
#6 0xc050d0f2 in msleep (ident=0xc4dc2a98, mtx=0xc4dc2b04, priority=348, wmesg=0x0,
timo=0) at /scratch/src/sys/kern/kern_synch.c:294
#7 0xc04eb82f in wait1 (td=0xc4b30780, uap=0xddcd6d10, compat=0)
at /scratch/src/sys/kern/kern_exit.c:766
#8 0xc04eab90 in wait4 (td=0x0, uap=0x0) at /scratch/src/sys/kern/kern_exit.c:548
#9 0xc06241d0 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134899628, tf_esi = 134912305, tf_ebp = -1077943784, tf_isp = -573739660, tf_ebx = 772, tf_edx = 135012352, tf_ecx = 13, tf_eax = 7, tf_trapno = 12, tf_err = 2, tf_eip = 134525375, tf_cs = 31, tf_eflags = 646, tf_esp = -1077943812, tf_ss = 47}) at /scratch/src/sys/i386/i386/trap.c:1010
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
interruptNG/ataNG breaks laptop boot.
Hi I have a rather old Dell laptop that I'd like to run current on. A few months back current booted, but the PCIC stuff was broken so I had to back out. I thought I'd give it another try this week. After it probes the disk and GEOM does some stuff it stops responding to keyboard with the harddisk light on solidly. The last output is the following (which can also be found at the end of the verbose boot output): GEOM: create disk ad0 dp=0xc1538170 ad0: ATA-3 disk at ata0-master ad0: 3102MB (6354432 sectors), 6304 C, 16 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, UDMA33 GEOM: new disk ad0 ad0: WARNING - READ_DMA recovered from missing interrupt ad0: WARNING - READ_DMA recovered from missing interrupt ad0: WARNING - READ_DMA recovered from missing interrupt Mounting root from ufs:/dev/ad0s1a setrootbyname failed ffs_mountroot: can't find rootvp Root mount failed: 6 Manual root filesystem specification: : Mount using filesystem eg. ufs:da0s1a ? List valid disk boot devices Abort manual input mountroot> The only thing that can be done at this point is to reboot. At least the loader works with the 4.9 kernel so I can compile new kernels on another machine and copy them accross. Any ideas? Ian OK boot -v SMAP type=01 base= len=000a SMAP type=01 base=0010 len=01f0 Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #1: Fri Nov 14 13:36:02 SAST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/LAPTOY-CURRENT Preloaded elf kernel "/boot/kernel/kernel" at 0xc06d2000. Calibrating clock(s) ... i8254 clock: 1193227 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 133637357 Hz CPU: Pentium/P54C (133.64-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping = 12 Features=0x1bf real memory = 33554432 (32 MB) Physical memory chunk(s): 0x1000 - 0x0009, 651264 bytes (159 pages) 0x0010 - 0x003f, 3145728 bytes (768 pages) 0x00826000 - 0x01f49fff, 24264704 bytes (5924 pages) avail memory = 27471872 (26 MB) bios32: Found BIOS32 Service Directory header at 0xc00ffe80 bios32: Entry = 0xffe90 (c00ffe90) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xbe4e pnpbios: Found PnP BIOS data at 0xc00fe2d0 pnpbios: Entry = f:e2f4 Rev = 1.0 pnpbios: Event flag at 4b4 Other BIOS signatures found: Intel Pentium detected, installing workaround for F00F bug random: null: mem: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface pci_open(1):mode 1 addr port (0x0cf8) is 0x pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=00011066) pcibios: BIOS version 2.10 pcib0: at pcibus 0 on motherboard pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x1066, dev=0x0001, revid=0x04 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0xa400, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1066, dev=0x8002, revid=0x00 bus=0, slot=6, func=0 class=06-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x000f, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 3, range 32, base 3000, size 21, enabled found-> vendor=0x10c8, dev=0x0001, revid=0x01 bus=0, slot=7, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 map[20]: type 4, range 32, base fe00, size 4, enabled pci_cfgintr: can't route an interrupt to 0:8 INTA found-> vendor=0x1095, dev=0x0643, revid=0x00 bus=0, slot=8, func=0 class=01-01-80, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x04 (1000 ns) intpin=a, irq=14 isab0: at device 6.0 on pci0 isa0: on isab0 pci0: at device 7.0 (no driver attached) atapci0: port 0xfe00-0xfe0f irq 14 at device 8.0 on pci 0 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata0-slave: stat=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 mask=03 stat0=50 stat1=00 devices=0x1 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 pnpbios: 16 device
Re: Radeon 7500 w/ DRI locking on restart of X
Eric, I updated my 5.1-RELEASE system to CURRENT dated today at approx. 9:10 CDT to give your changes a try. I had a bit of a fright at first with kernel panics right at the end of the boot sequence but it turned out I had forgotten to disable the ltmdm code -- the kernel module compiled under -RELEASE wasn't friendly to -CURRENT. I've got just a basic install with my custom kernel. I'm using the packages for X from the 5.1-RELEASE cd running twm. Hangs on restart are gone! I restarted about 10 times in a row and ran glxinfo and glxgears each time to verify DRI was still activated and working -- no issues. VT switches are fine (even while running glxgears). The one thing that does not work is resume from acpiconf -s 4 (disk) -- there is a failure to refresh in X and no ability *apparently* to switch to a VT; the keystrokes just generate beeps. Interestingly, the cursor still changed between the different modes when mousing over the xterm and onto the background. Also, Alt-Cntl-Del did work just fine. The only other thing I noticed is that there seems to be a syslog entry for every instance of running glxgears that reads: [MP SAFE] drm0 Is this expected behavior? I noticed that same message (in brackets) in front of each of my disks as they were probed during boot. Any further info you'd like or more testing I could do to help? Sean -Original Message- From: Eric Anholt <[EMAIL PROTECTED]> Sent: Oct 23, 2003 9:09 PM To: Glenn Johnson <[EMAIL PROTECTED]> Cc: Vulpes Velox <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Radeon 7500 w/ DRI locking on restart of X On Tue, 2003-08-26 at 20:37, Glenn Johnson wrote: > On Tue, Aug 26, 2003 at 01:27:11PM -0700, Eric Anholt wrote: > > > On Tue, 2003-08-26 at 18:05, Vulpes Velox wrote: > > > > > I had similar problem with a 7200 and OGL. I solved the problem by > > > turning off some of the options in the X config. > > > > > > On Tue, 26 Aug 2003 12:21:56 -0500 (GMT) Sean Welch > > > <[EMAIL PROTECTED]> wrote: > > > > > > > Is anyone else seeing this issue? I'm running into it on desktop > > > > boxes and a laptop running 4.8-RELEASE with up to date ports > > > > collections and various versions of DRI installed over a ports > > > > version of X. I'm also seeing this under 5.1-RELEASE on the > > > > laptop. > > > > > > > > Everything works perfectly unless/until I restart the X server. > > > > This appears to be initiated automatically when running GDM -- ie, > > > > GDM starts, you log in using that X session, you log out and the > > > > session stops, GDM starts X again and displays the login screen. > > > > Everyone that's experiencing this and is using the DRI, what version > > of the radeon DRM is loaded? (dmesg | grep drm) Is anyone experiencing > > this without the DRI loaded? The ForcePCIMode workaround is > > interesting, I'll take a look at what could be going on there. > > I did some googling tonight and found out this problem is supposedly > fixed in XFree86-4.3.99 although I do not see any specific mention of > this problem in the Changelog. See: > > http://www.knoppix.net/forum/viewtopic.php?t=2504&highlight= That patch has been in our XFree86 for quite a while. For those of you using -current, could you try with the latest DRM which I committed to FreeBSD CVS a few minutes ago? -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: xscreensaver bug?
"Eugene M. Kim" wrote: > Terry Lambert wrote: > >>I'm new in FreeBSD. I found that after I lock screen with xscreensaver, > >>I can unlock it with the root's password as well as my normal user's > >>password. I don't think it is a good thing. Is it a bug? > > > >It is intentional, although you can eliminate it with a recompile > >of the xscreensaver code, with the right options set. > > Wouldn't this lead to another security hazard, if a user compile his own > hacked xscreensaver which captures and stashes the password into a file > then runs it and leaves the terminal intentionally, `baiting' root? :o Not really. This type of thing would need to accept pretty much everything as a termination password, since there no password it can legitimately validate, since a user compiled trojan like this would not have access to the password database contents in order to perform validation. If the trojan is SUID, then they already have root, and don't need the trojan. Either way, there's no risk to just typing whatever crap you want to at it, including a message calling the user an idiot, the first time, to see if it's going to let you in without you giving it the real root password. > Although I can see the merit of this `feature', I think sysadmins should > stay away from using it in general. `su -m thatuser -c "killall > xscreensaver"' seems to be far safer. See other post. You can permanently lose focus this way, effectively locking up the machine. If you want to be that draconian, you might as well just reset the session, rather than screwing around with the vagaries of XGrabCursor, etc.. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unattended reboot was Re: signal 12's everywhere on Currentwith update this morning.
On (2003/11/13 14:02), Eric Anderson wrote: > I'm not having any luck - I'm started to feel like I'm missing something > here :) > > I cvsup'd yesterday afternoon, and did my usual make buildworld, kernel, > install kernel, single user mode, then make installworld - except it > bombed on the installworld. I ignored the message moved on. You missed a step. The HEADS UP sent to -current said you needed to reboot between kernel install and world install. This is the strictly safe way of upgrading always. However, many people skip the reboot (and even the drop to single-user mode) as a shortcut. Sometimes, the shortcut works. This time, it doesn't. :-) Ciao, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: xscreensaver bug?
Craig Boston wrote: > > Absolutely worst case, the root user could log in remotely, gdb > > your screen saver, type "foobar" as the password, and then hack > > the authentication function return value to say "yes, that's the > > correct password for "[EMAIL PROTECTED]", and get in without needing > > to have xscreensaver accept the root password. > > Or, even easier, log in remotely as root and simply "killall -9 xscreensaver". > I've had to do that a few times myself when I first tried out pam_krb5 and > learned the hard way that xscreensaver doesn't like it very much (and my user > account has * in the local password field). I've seen a kill of xscreensaver using a nontrappable signal leave the focus permanently hosed (until the X server is restarted); not very useful, if you want to poke around in the active session. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Teach '-m' option of bsdlabel(8) to sunlabel(8)
Self followup... matusita> I'd like to try to bulid FreeBSD/sparc64 on i386 box, but matusita> due to the lack of bsdlabel(8)'s '-m' option (set machine matusita> archtecture) on sunlabel(8), newfs(8) cannot work. I'm confused something. The fact that newfs(8) on i386 cannot newfs a filesystem which is sunlabel(8)ed is true, but it does NOT come with sunlabel(8) itself. Obviously sunlabel(8) doesn't need -m option since it is used on on sparc64 :-) Anyway how can I newfs a filesystem for sparc64 on i386 box? -- - Makoto `MAR' Matsushita ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Teach '-m' option of bsdlabel(8) to sunlabel(8)
I'd like to try to bulid FreeBSD/sparc64 on i386 box, but due to the lack of bsdlabel(8)'s '-m' option (set machine archtecture) on sunlabel(8), newfs(8) cannot work. Question: Anybody working on teaching '-m' option to sunlabel(8)? -- - Makoto `MAR' Matsushita ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: making a release
On Fri, Nov 14, 2003 at 07:18:05AM +1000, Andy Farkas wrote: > Scott Long wrote: > > > I use the following all of the time: > > > > cd /usr/src/release ; make release BUILDNAME=5.1-CURRENT > > CHROOTDIR=/usr/release CVSROOT=/usr/ncvs > > Quick question: is it ok to do make -j release ? > No, it's not. But world- and kernel-related parts of "make release" can be built in parallel, here's a relevant excerpt from release/Makefile: # If you want to pass flags to the world build such as -j X, use # WORLD_FLAGS. Similarly, you can specify make flags for kernel # builds via KERNEL_FLAGS. # Similarly, you can specify make flags for make readmes via PORTREADMES_FLAGS. #WORLD_FLAGS=-j4 #KERNEL_FLAGS=-j4 #PORTREADMES_FLAGS=-j4 The release(7) manpage mumbles something about that, but not too verbose. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: HEADS-UP new statfs structure
Marco Wertejuk wrote: Just for a short note: cfsd (ports/security/cfs) should be recompiled as well after those statfs changes. And mail/postfix and devel/gnomevfs2 (ones's i've found so far) postfix did this every time it received a mail until I recompiled it: pid 4049 (smtpd), uid 1003: exited on signal 11 And gnomevfs was something I saw in another headsup. There are bound to be others, I'm just keeping an eye on my /var/log/messages to see if anything else sig 11 or 12's! So far so good though. Matt. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Synaptics PS/2 TouchPad
On 2003-11-14 11:24:07 (+1030), Daniel O'Connor <[EMAIL PROTECTED]> wrote: > On Thursday 13 November 2003 22:54, Philip Paeps wrote: > > I've recently started work on getting psm to support Synaptics TouchPads > > more fully: virtual scrollbars, up/down buttons, multiple finger > > detection, etc. I have the basics working, but my brain has been too > > fried lately to deal with the maths of translating absolute coordinates to > > sensibly accelerated motions. > > Ooh nice :) > Can you put it up somewhere so I can have a look? The idea is nice, the code is a little less nice. I'll clean it up today, and find a webserver to dump it on. Watch this space :-) - Philip -- Philip Paeps Please don't CC me, I am subscribed to the list. BOFH Excuse #41: interrupt configuration error ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
