startx -listen_tcp = core dump
Works fine when I don't specify -listen_tcp. Has anyone seen this ? -Arun To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sbin/sysctl sysctl.8 src/sys/kern init_main.c
Sorry, this is a subscription-only feature. M Was the following just swallowed up into the bowels of the CVS beast or something? :-) I've tried updating my sources several times, and still not retrieving it. On 12-Nov-2002 Dag-Erling Smorgrav wrote: des 2002/11/12 02:69:42 PST Modified files: sbin/sysctl sysctl.8 sys/kern init_main.c Log: Add the kern.turbo sysctl, which makes the system run twice as fast. Default to 0 (off) for backward compatibility. Revision ChangesPath 1.48 +1 -0 src/sbin/sysctl/sysctl.8 1.215 +3 -0 src/sys/kern/init_main.c -- Conrad Sabatier [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Mark Murray Beware! I'm umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
more info from panic from running dnet on SMP kernel ( lockorder reversal, recursed on non-recursive lock )
running dnet on a SMP kernel causes the kernel to panic.
lock order reversal
1st 0xc2c803e8 process lock (process lock) @
../../../kern/kern_fork.c:571
2nd 0xc03cfce0 proctree (proctree) @ ../../../kern/kern_fork.c:596
recursed on non-recursive lock (sleep mutex) process lock @
../../../kern/kern_fork.c:599
first acquired @ ../../../kern/kern_fork.c:571
panic: recurse
cpuid = 1; lapic.id = 0100
Debugger(panic)
Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0
db t
Debugger(c03926fa,100,c0395ada,d26f5c08,1) at Debugger+0x55
panic(c0395ada,c038feab,23b,c038feab,257) at panic+0x11f
witness_lock(c2c803e8,8,c038feab,257,0) at witness_lock+0x3e6
_mtx_lock_flags(c2c803e8,0,c038feab,257,d26f5cb8) at
_mtx_lock_flags+0xb2
fork1(c2773d00,6050,0,d26f5cd4,c2c803e8) at fork1+0xbfc
rfork(c2773d00,d26f5d10,c03b07a2,407,1) at rfork+0x65
syscall(2f,2f,2f,0,80ddf10) at syscall+0x28e
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (251, FreeBSD ELF32, rfork), eip = 0x8087d14, esp =
0xbfbff4a8, ebp = 0xbfbff524 ---
db ps
pid proc addruid ppid pgrp flag stat wmesgwchan
cmd
6217 c2b98e00 d28a70000 6215 6216 000 newpanic: unknown
thread state
cpuid = 1; lapic.id = 0100
boot() called on cpu#1
Uptime: 1h43m39s
pfs_vncache_unload(): 1 entries remaining
Dumping 255 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
Dump complete
Automatic reboot in 15 seconds - press a key on the console to abort
Rebooting...
cpu_reset called on cpu#1
cpu_reset: Restarting BSP
cpu_reset_proxy: Stopped CPU 1
And then when the system came back up and I took a closer
look at the core dump.
(kgdb) where
#0 doadump () at ../../../kern/kern_shutdown.c:232
#1 0xc02114ad in boot (howto=260) at ../../../kern/kern_shutdown.c:364
#2 0xc0211767 in panic () at ../../../kern/kern_shutdown.c:517
#3 0xc014f2bc in db_ps (dummy1=-1070342907, dummy2=0, dummy3=-1,
dummy4=0xd26f5a24 )
at ../../../ddb/db_ps.c:169
#4 0xc014d142 in db_command (last_cmdp=0xc03be920, cmd_table=0x0,
aux_cmd_tablep=0xc03b5540,
aux_cmd_tablep_end=0xc03b5558) at ../../../ddb/db_command.c:346
#5 0xc014d256 in db_command_loop () at ../../../ddb/db_command.c:472
#6 0xc014feea in db_trap (type=3, code=0) at ../../../ddb/db_trap.c:72
#7 0xc033da10 in kdb_trap (type=3, code=0, regs=0xd26f5b80)
at ../../../i386/i386/db_interface.c:166
#8 0xc0356a3f in trap (frame=
{tf_fs = -1069481960, tf_es = 16, tf_ds = 16, tf_edi =
-1032372992, tf_esi = 256, tf_ebp = -764453940, tf_isp = -764453972,
tf_ebx = 0, tf_edx = 0, tf_ecx = 1, tf_eax = 18, tf_trapno = 3, tf_err
= 0, tf_eip = -1070342907, tf_cs = 8, tf_eflags = 662, tf_esp =
-1069883258, tf_ss = -1069996294}) at ../../../i386/i386/trap.c:603
#9 0xc033f238 in calltrap () at {standard input}:99
#10 0xc021174f in panic (fmt=0x0) at ../../../kern/kern_shutdown.c:503
#11 0xc02333d6 in witness_lock (lock=0xc2c803e8, flags=8,
file=0xc038feab ../../../kern/kern_fork.c, line=599) at
../../../kern/subr_witness.c:609
#12 0xc02079c2 in _mtx_lock_flags (m=0xc03cf4c0, opts=0,
file=0xc042cfd4 è\003È«þ8À;\002,
line=-1027079192) at ../../../kern/kern_mutex.c:328
#13 0xc01fd3ec in fork1 (td=0xc2773d00, flags=24656, pages=0,
procp=0xd26f5cd4)
at ../../../kern/kern_fork.c:599
#14 0xc01fc6c5 in rfork (td=0xc2773d00, uap=0xd26f5d10) at
../../../kern/kern_fork.c:168
#15 0xc035739e in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi =
135126800, tf_ebp = -1077938908, tf_isp = -764453516, tf_ebx = 2,
tf_edx = 135381248, tf_ecx = 135381248, tf_eax = 251, tf_trapno = 0,
tf_err = 2, tf_eip = 134774036, tf_cs = 31, tf_eflags = 659, tf_esp =
-1077939032, tf_ss = 47})
at ../../../i386/i386/trap.c:1033
#16 0xc033f28d in Xint0x80_syscall () at {standard input}:141
---Can't read userspace from dump, or kernel process---
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Processes hanging in thrd_sleep
Since upgrading my kernel to today's current (from a couple of weeks ago) I have had a number of hangs where processes block in the kernel, usually in the thrd_sleep state (but once one hung in the ufs state). e.g: load: 0.01 cmd: cc 708 [ufs] 0.00u 0.00s 0% 56k load: 0.01 cmd: tcsh 709 [thrd_sleep] 0.00u 0.00s 0% 1220k I've seen this on my sparc64 box as well as an i386 box. Any bright ideas? Anyone feeling guilty? :) Kris msg46805/pgp0.pgp Description: PGP signature
sparc64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- === lib/libc /tinderbox/sparc64/src/lib/libc/gen/getcap.c: In function `getent': /tinderbox/sparc64/src/lib/libc/gen/getcap.c:251: warning: passing arg 3 of `cdbget' discards qualifiers from pointer target type /tinderbox/sparc64/src/lib/libc/gen/getcap.c: In function `cgetmatch': /tinderbox/sparc64/src/lib/libc/gen/getcap.c:576: warning: assignment discards qualifiers from pointer target type /tinderbox/sparc64/src/lib/libc/gen/getcap.c:581: warning: assignment discards qualifiers from pointer target type /tinderbox/sparc64/src/lib/libc/gen/sysconf.c: In function `sysconf': /tinderbox/sparc64/src/lib/libc/gen/sysconf.c:259: syntax error before break /tinderbox/sparc64/src/lib/libc/gen/sysconf.c:263: syntax error before break /tinderbox/sparc64/src/lib/libc/gen/sysconf.c:267: syntax error before break *** Error code 1 Stop in /tinderbox/sparc64/src/lib/libc. *** Error code 1 Stop in /tinderbox/sparc64/src/lib. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Is RAIDframe currently usable?
Hi, Yesterday I installed a jpsnap (FreeBSD christine.energyhq.tk 5.0-CURRENT-20021115-JPSNAP i386), and tried to setup a RAID0 config with two disks. raidctl -C goes fine, so does -I and -iv. Then fdisk'ed and disklabelled. But when I tried to newfs the newly created partition I started getting a bunch of errors like this: RAIDframe should be considered highly experimental. While it was tested extensively under SMP in FreeBSD 4.x, it received very little testing under SMP in -current. If you have more details on this failure, I'd appreciate it. Scott --- Nov 16 00:04:59 christine kernel: raid0: node (R ) returned fail, rolling backward Nov 16 00:04:59 christine kernel: raid0: DAG failure: r addr 0x40 (64) nblk 0x20 (32) buf 0xcdd50ea0 Nov 16 00:04:59 christine kernel: raid0: node (R ) returned fail, rolling backw byte 76893 --- and so on. Anyway, the newfs process finishes, then a simple piped tar to move the old /usr to the RAID partition creates a myriad of those messages, to a point where the system spends all the time logging those errors and tar no longer continues. The system is a dual P3 box, running a slightly modified GENERIC (added SMP, raidframe and pcm), with INVARIANTS and WITNESS enabled (tried without them too, no success). So, any known issues with RAIDframe? I can supply more detailed info if needed. Cheers, -- Miguel Mendez - [EMAIL PROTECTED] GPG Public Key :: http://energyhq.homeip.net/files/pubkey.txt EnergyHQ :: http://www.energyhq.tk Of course it runs NetBSD! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Processes hanging in thrd_sleep
On Sun, Nov 17, 2002 at 02:59:19AM -0800, Kris Kennaway wrote: Since upgrading my kernel to today's current (from a couple of weeks ago) I have had a number of hangs where processes block in the kernel, usually in the thrd_sleep state (but once one hung in the ufs state). e.g: load: 0.01 cmd: cc 708 [ufs] 0.00u 0.00s 0% 56k load: 0.01 cmd: tcsh 709 [thrd_sleep] 0.00u 0.00s 0% 1220k I've seen this on my sparc64 box as well as an i386 box. Any bright ideas? Anyone feeling guilty? :) It looks like this broke some time between Nov 1 and Nov 5 (I was able to lock up the kernel from the Nov 5 current.freebsd.org snapshot instantly by running a make -j4). The Nov 1 kernel is happily building. Kris msg46808/pgp0.pgp Description: PGP signature
Re: Asking for tester (small patch to chown(8)/chgrp(1))
On Sat, 16 Nov 2002 12:29:20 +0100 (CET) Oliver Fromme [EMAIL PROTECTED] wrote: The patch adds an option -r to chown(8) and chgrp(1), which does pretty much the same as the -r option of touch(1) and truncate(1). Basically, it let's you copy ownerships and group memberships from one file to another, which is useful in scripts. I'm concerned about the used character: -r is similiar to -R Bye, Alexander. -- One world, one web, one program -- Microsoft promotional ad Ein Volk, ein Reich, ein Fuehrer -- Adolf Hitler http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
SMP stability ? [was Re: more info from panic from running dnet on SMP kernel]
Le Sunday 17 November 2002 10:50, Joel M. Baldwin a écrit : running dnet on a SMP kernel causes the kernel to panic. [Hijacking another thread ?] I haven't been able to complete a full buildworld with an SMP on a Abit BP6 (bi-celeron) board for two weeks (the kernel config is just a full GENERIC with SMP and APICIO options enabled). The same machine runs happily strings of make -j48 buildworld's when running with the straight GENERIC UP kernel, so I think the hardware seems to be working OK. Even make -j1 buildworld with the SMP kernel ends with a complete freeze of the machine (the kernel does not go to a panic where I could try a backtrace) The hardware config of the machine is pretty dull (see dmesg later). One point that could be better is that the sources are NFS mounted from a 4.7-Stable server, over an rl(4) board, which may be unstable (/usr/obj is local, on the Maxtor drive) TfH PS : the machine was re-installed anew from the 5.0-20021027-CURRENT snapshot, then upgraded via make buildworld/buildkernel and mergemaster PS2 : full dmesg (when running the stable, UP, GENERIC) Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #17: Sat Nov 16 19:16:25 CET 2002 XXX@YYY:/usr/obj/files2/src-free/src/sys/GENERIC Preloaded elf kernel /boot/kernel/kernel at 0xc0662000. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 334092192 Hz CPU: Pentium II/Pentium II Xeon/Celeron (334.09-MHz 686-class CPU) Origin = GenuineIntel Id = 0x665 Stepping = 5 Features=0x183fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 536870912 (512 MB) avail memory = 514818048 (490 MB) Initializing GEOMetry subsystem Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface Using $PIR table, 8 entries at 0xc00fdef0 pcib0: Intel 82443BX (440 BX) host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 agp0: Intel 82443BX (440 BX) host to PCI bridge mem 0xe000-0xe3ff at device 0.0 on pci0 pcib1: PCIBIOS PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xd000-0xd01f irq 10 at device 7.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: bridge, PCI-unknown at device 7.3 (no driver attached) rl0: RealTek 8139 10/100BaseTX port 0xd400-0xd4ff mem 0xe500-0xe5ff irq 10 at device 17.0 on pci0 rl0: Realtek 8139B detected. Warning, this may be unstable in autoselect mode rl0: Ethernet address: 00:40:95:30:38:36 miibus0: MII bus on rl0 rlphy0: RealTek internal media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto atapci1: HighPoint HPT366 ATA66 controller port 0xe000-0xe0ff,0xdc00-0xdc03,0xd800-0xd807 irq 11 at device 19.0 on pci0 ata2: at 0xd800 on atapci1 atapci2: HighPoint HPT366 ATA66 controller port 0xec00-0xecff,0xe800-0xe803,0xe400-0xe407 irq 11 at device 19.1 on pci0 ata3: at 0xe400 on atapci2 orm0: Option ROMs at iomem 0xc6800-0xc7fff,0xc-0xc5fff on isa0 pmtimer0 on isa0 atkbdc0: Keyboard controller (i8042) at port 0x64,0x60 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 fdc0: Enhanced floppy controller (i82077, NE72065 or clone) at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x100 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A, console sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: PNP0303 can't assign resources (port) unknown: PNP0a03 can't assign resources (port) unknown: PNP0501 can't assign resources (port) unknown: PNP0700 can't assign resources (port) unknown: PNP0400 can't assign resources (port) unknown: PNP0501 can't assign resources (port) Timecounters tick every 10.000 msec ad0: 6149MB Maxtor 86480D6 [13328/15/63] at ata0-master UDMA33 acd0: CDROM NEC CD-ROM DRIVE:28B at ata1-master PIO4 Mounting root from ufs:/dev/ad0s2a To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SMP stability ? [was Re: more info from panic from runningdnet on SMP kernel]
--On Sunday, November 17, 2002 11:36 AM +0100 Thierry Herbelot [EMAIL PROTECTED] wrote: Le Sunday 17 November 2002 10:50, Joel M. Baldwin a écrit : running dnet on a SMP kernel causes the kernel to panic. [Hijacking another thread ?] No problem, lets compare notes. I haven't been able to complete a full buildworld with an SMP on a Abit BP6 (bi-celeron) board for two weeks (the kernel config is just a full GENERIC with SMP and APICIO options enabled). I also am running a BP6. IS ANYONE successfully running an ABIT BP6 motherboard on a SMP kernel with -current? What BIOS version are running? I'm one version behind I think, so I'm going to upgrade and see if that makes any difference. The same machine runs happily strings of make -j48 buildworld's when running with the straight GENERIC UP kernel, so I think the hardware seems to be working OK. I haven't tried anything that drastic, but I have had NO crashes or lockups that I couldn't explain in a NON SMP kernel. The SMP kernel on the other hand will Hard Lock anywhere in anywhere from seconds to days. It seems to be more likely the harder I push it. I don't think its the hardware. I've pulled my hair out and tried everything I can think of to eliminate the possability of it being hardware. I'm hoping that dnet causing a panic is somehow related. Even make -j1 buildworld with the SMP kernel ends with a complete freeze of the machine (the kernel does not go to a panic where I could try a backtrace) Exactly! Hard Lock, no panic, no keyboard, no choices other than reset. The hardware config of the machine is pretty dull (see dmesg later). One point that could be better is that the sources are NFS mounted from a 4.7-Stable server, over an rl(4) board, which may be unstable (/usr/obj is local, on the Maxtor drive) All my harddrives are local, 3 SCSI and 3 IDE. . . . snip . . . To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Weird error during make installworld [executable becomes data]
Date: Tue, 12 Nov 2002 10:18:03 -0800 (PST) From: David Wolfskill [EMAIL PROTECTED] [Yes, replying to my own message, if not myself dhw] Here's an excerpt of the typescript from the make installworld: ---%- snip! -- Installing everything.. ... /tmp/install.O6fzOZh4/mtree: 62: Syntax error: ( unexpected *** Error code 2 ---%- snip! -- Now, watch this: g1-9(5.0-C)[4] file /tmp/install.O6fzOZh4/* |grep data /tmp/install.O6fzOZh4/mtree:data g1-9(5.0-C)[5] Huh??!? I think I can top that: g1-9(5.0-C)[2] file /tmp/install.*|* | grep data COPYRIGHT: Command not found. while from a different xterm on the same machine: g1-9(5.0-C)[2] file /tmp/install.*|* | grep data #SC.SAVE~: Command not found. As before, this is running with /tmp mounted on a md device that is swap-backed. Clues? Thanks, david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill [EMAIL PROTECTED] I have no confidence in results obtained through the use of Microsoft products. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Weird error during make installworld [executable becomes data]
Date: Sun, 17 Nov 2002 19:06:40 +0100 From: Stefan Farfeleder [EMAIL PROTECTED] g1-9(5.0-C)[2] file /tmp/install.*|* | grep data ^ #SC.SAVE~: Command not found. Are these just typoes in the mail or did you really type this? :-) I cut pasted it. Color me embarrassed :-( Sorry, gang, david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill [EMAIL PROTECTED] I have no confidence in results obtained through the use of Microsoft products. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
Brian Fundakowski Feldman [EMAIL PROTECTED] wrote: I can't get more info because crash dumps don't work when this happens, but for what it's worth, here's a traceback which shows what happens when I attempt to use my da0: SanDisk ImageMate II 1.30 Removable Direct Access SCSI-2 device on an OHCI-based controller. This was working just a few days ago with a UHCI controller, so ... The crash is from an invalid read at 0xbff3e000, which is PTmap plus some offset. The trace as far as I can get it, from a kernel with USB but no options enabled, would be: ohci_alloc_std_chain+0xf5 (calling a DMAADDR() function, I believe) ohci_device_bulk_start+0x0d ohci_device_bulk_transfer+0x27 usbd_transfer+0xc0 umass_setup_transfer+0x4f umass_bbb_state usb_transfer_complete ohci_softintr Can anyone confirm if this is normal or I have an exceptional system? I have two completely unrelated OHCI-based controllers in my system and neither works. Anyone? I kinda want to use my CF reader. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
On Sun, Nov 17, 2002 at 01:18:00PM -0500, Brian F. Feldman wrote: ohci_alloc_std_chain+0xf5 (calling a DMAADDR() function, I believe) ohci_device_bulk_start+0x0d ohci_device_bulk_transfer+0x27 usbd_transfer+0xc0 umass_setup_transfer+0x4f umass_bbb_state usb_transfer_complete ohci_softintr Can anyone confirm if this is normal or I have an exceptional system? I have two completely unrelated OHCI-based controllers in my system and neither works. Anyone? I kinda want to use my CF reader. There are rumours that OHCI is borked in NetBSD too and this is a bug that we've inherited. Me, I've not got an OHCI system to test just UHCI. Did it used to work, and got broken, or has it never worked? 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. = msg46816/pgp0.pgp Description: PGP signature
Re: SMP stability ? [was Re: more info from panic from running dnet on SMP kernel]
On Sun, 17 Nov 2002, Thierry Herbelot wrote: Even make -j1 buildworld with the SMP kernel ends with a complete freeze of the machine (the kernel does not go to a panic where I could try a backtrace) I've seen several reports that using a serial break to get into ddb is now quite a bit more reliable than a keyboard break. If you're not already using a serial console, you might want to give it a try (make sure to turn on BREAK_TO_DEBUGGER and/or ALT_BREAK_TO_DEBUGGER). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Processes hanging in thrd_sleep
I ran into that during heavy builds on one of my boxes a few months ago -- I never really got around to properly debugging it because the UFS file systems promptly ate themselves. Oddly, I had two boxes in particular that this happened on, and none of my others, and it wasn't clear to me if there was a useful pattern. I will try reproducing it sometime this weekend. Basically, the system seemed fairly live, but any attempt to execve() would hang the process in that sleep state. It looked a bit like a VM lock leak followed by piling up on locks into a deadlock staet. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories On Sun, 17 Nov 2002, Kris Kennaway wrote: Since upgrading my kernel to today's current (from a couple of weeks ago) I have had a number of hangs where processes block in the kernel, usually in the thrd_sleep state (but once one hung in the ufs state). e.g: load: 0.01 cmd: cc 708 [ufs] 0.00u 0.00s 0% 56k load: 0.01 cmd: tcsh 709 [thrd_sleep] 0.00u 0.00s 0% 1220k I've seen this on my sparc64 box as well as an i386 box. Any bright ideas? Anyone feeling guilty? :) Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: more info from panic from running dnet on SMP kernel ( lock order reversal, recursed on non-recursive lock )
Hmm. It looks like there is indeed a lock leak in the RFTHREAD code.
Maybe a change like the following might help:
PROC_LOCK(p2);
psignal(p2, SIGKILL);
PROC_UNLOCK(p2);
}
Change the } to:
} else
PROC_UNLOCK(p1-p_leader);
And see if that gets rid of the problem. Any chance this is highly
reproduceable, btw? :-) And what app are you running that's using
RFTHREAD -- linux thread stuff?
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
On Sun, 17 Nov 2002, Joel M. Baldwin wrote:
running dnet on a SMP kernel causes the kernel to panic.
lock order reversal
1st 0xc2c803e8 process lock (process lock) @
../../../kern/kern_fork.c:571
2nd 0xc03cfce0 proctree (proctree) @ ../../../kern/kern_fork.c:596
recursed on non-recursive lock (sleep mutex) process lock @
../../../kern/kern_fork.c:599
first acquired @ ../../../kern/kern_fork.c:571
panic: recurse
cpuid = 1; lapic.id = 0100
Debugger(panic)
Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0
db t
Debugger(c03926fa,100,c0395ada,d26f5c08,1) at Debugger+0x55
panic(c0395ada,c038feab,23b,c038feab,257) at panic+0x11f
witness_lock(c2c803e8,8,c038feab,257,0) at witness_lock+0x3e6
_mtx_lock_flags(c2c803e8,0,c038feab,257,d26f5cb8) at
_mtx_lock_flags+0xb2
fork1(c2773d00,6050,0,d26f5cd4,c2c803e8) at fork1+0xbfc
rfork(c2773d00,d26f5d10,c03b07a2,407,1) at rfork+0x65
syscall(2f,2f,2f,0,80ddf10) at syscall+0x28e
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (251, FreeBSD ELF32, rfork), eip = 0x8087d14, esp =
0xbfbff4a8, ebp = 0xbfbff524 ---
db ps
pid proc addruid ppid pgrp flag stat wmesgwchan
cmd
6217 c2b98e00 d28a70000 6215 6216 000 newpanic: unknown
thread state
cpuid = 1; lapic.id = 0100
boot() called on cpu#1
Uptime: 1h43m39s
pfs_vncache_unload(): 1 entries remaining
Dumping 255 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
Dump complete
Automatic reboot in 15 seconds - press a key on the console to abort
Rebooting...
cpu_reset called on cpu#1
cpu_reset: Restarting BSP
cpu_reset_proxy: Stopped CPU 1
And then when the system came back up and I took a closer
look at the core dump.
(kgdb) where
#0 doadump () at ../../../kern/kern_shutdown.c:232
#1 0xc02114ad in boot (howto=260) at ../../../kern/kern_shutdown.c:364
#2 0xc0211767 in panic () at ../../../kern/kern_shutdown.c:517
#3 0xc014f2bc in db_ps (dummy1=-1070342907, dummy2=0, dummy3=-1,
dummy4=0xd26f5a24 )
at ../../../ddb/db_ps.c:169
#4 0xc014d142 in db_command (last_cmdp=0xc03be920, cmd_table=0x0,
aux_cmd_tablep=0xc03b5540,
aux_cmd_tablep_end=0xc03b5558) at ../../../ddb/db_command.c:346
#5 0xc014d256 in db_command_loop () at ../../../ddb/db_command.c:472
#6 0xc014feea in db_trap (type=3, code=0) at ../../../ddb/db_trap.c:72
#7 0xc033da10 in kdb_trap (type=3, code=0, regs=0xd26f5b80)
at ../../../i386/i386/db_interface.c:166
#8 0xc0356a3f in trap (frame=
{tf_fs = -1069481960, tf_es = 16, tf_ds = 16, tf_edi =
-1032372992, tf_esi = 256, tf_ebp = -764453940, tf_isp = -764453972,
tf_ebx = 0, tf_edx = 0, tf_ecx = 1, tf_eax = 18, tf_trapno = 3, tf_err
= 0, tf_eip = -1070342907, tf_cs = 8, tf_eflags = 662, tf_esp =
-1069883258, tf_ss = -1069996294}) at ../../../i386/i386/trap.c:603
#9 0xc033f238 in calltrap () at {standard input}:99
#10 0xc021174f in panic (fmt=0x0) at ../../../kern/kern_shutdown.c:503
#11 0xc02333d6 in witness_lock (lock=0xc2c803e8, flags=8,
file=0xc038feab ../../../kern/kern_fork.c, line=599) at
../../../kern/subr_witness.c:609
#12 0xc02079c2 in _mtx_lock_flags (m=0xc03cf4c0, opts=0,
file=0xc042cfd4 è\003È«þ8À;\002,
line=-1027079192) at ../../../kern/kern_mutex.c:328
#13 0xc01fd3ec in fork1 (td=0xc2773d00, flags=24656, pages=0,
procp=0xd26f5cd4)
at ../../../kern/kern_fork.c:599
#14 0xc01fc6c5 in rfork (td=0xc2773d00, uap=0xd26f5d10) at
../../../kern/kern_fork.c:168
#15 0xc035739e in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi =
135126800, tf_ebp = -1077938908, tf_isp = -764453516, tf_ebx = 2,
tf_edx = 135381248, tf_ecx = 135381248, tf_eax = 251, tf_trapno = 0,
tf_err = 2, tf_eip = 134774036, tf_cs = 31, tf_eflags = 659, tf_esp =
-1077939032, tf_ss = 47})
at ../../../i386/i386/trap.c:1033
#16 0xc033f28d in Xint0x80_syscall () at {standard input}:141
---Can't read userspace from dump, or kernel process---
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: SMP stability ? [was Re: more info from panic from running dnet on SMP kernel]
Le Sunday 17 November 2002 20:46, Robert Watson a écrit : I've seen several reports that using a serial break to get into ddb is now quite a bit more reliable than a keyboard break. If you're not already using a serial console, you might want to give it a try (make sure to turn on BREAK_TO_DEBUGGER and/or ALT_BREAK_TO_DEBUGGER). OK, I'll do so TfH PS : I think one other BP6 user is Grog To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Asking for tester (small patch to chown(8)/chgrp(1))
Alexander Leidinger [EMAIL PROTECTED] wrote: Oliver Fromme [EMAIL PROTECTED] wrote: The patch adds an option -r to chown(8) and chgrp(1), which does pretty much the same as the -r option of touch(1) and truncate(1). Basically, it let's you copy ownerships and group memberships from one file to another, which is useful in scripts. I'm concerned about the used character: -r is similiar to -R Why exactly is that cause for concern? What character would you suggest instead? touch(1) and truncate(1) also use -r. Regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. All that we see or seem is just a dream within a dream (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sparc64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sun Nov 17 20:01:33 GMT 2002 -- === ipfilter /tinderbox/sparc64/src/sys/kern/kern_thread.c: In function `kse_create': /tinderbox/sparc64/src/sys/kern/kern_thread.c:498: `mp_ncpus' undeclared (first use in this function) /tinderbox/sparc64/src/sys/kern/kern_thread.c:498: (Each undeclared identifier is reported only once /tinderbox/sparc64/src/sys/kern/kern_thread.c:498: for each function it appears in.) *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
On Sun, 17 Nov 2002, Mike Barcroft wrote: -- Kernel build for GENERIC started on Sun Nov 17 20:01:33 GMT 2002 -- === ipfilter /tinderbox/sparc64/src/sys/kern/kern_thread.c: In function `kse_create': /tinderbox/sparc64/src/sys/kern/kern_thread.c:498: `mp_ncpus' undeclared (first use in this function) /tinderbox/sparc64/src/sys/kern/kern_thread.c:498: (Each undeclared identifier is reported only once /tinderbox/sparc64/src/sys/kern/kern_thread.c:498: for each function it appears in.) ok mea culpa.. what is there in SPARC that should be used instead..? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rpc.lockd problems
Andrew P. Lentvorski wrote: Can you produce a packet trace for Kris? This would give him a known good trace so that he can point out the differences from his particular configuration, or, alternatively, he could file a bug report with the Linux folks. Ok, here is a but of output from tcpudmp, first is the locking of the file, later the unlocking of the file. (Beware, long lines ahead...) [This is when the locking begins-- I'm not sure if the RPC packets should be included...] 21:05:36.681339 dhcp157.in-10.sillywalks.org.49445 pluto.in-10.sillywalks.org.lockd: udp 196 (ttl 64, id 14737, len 224) 0x 4500 00e0 3991 4011 aa4c c0a8 0a9dE...9...@..L 0x0010 c0a8 0a42 c125 0fcd 00cc e277 3ddd 99f0...B.%.w=... 0x0020 0002 0001 86b5 0004 0x0030 0007 0001 0028 3dd7 f690...(=... 0x0040 0006 626f 656b 6a65 03e8boekje.. 0x0050 .. 21:05:36.684128 pluto.in-10.sillywalks.org.826 dhcp157.in-10.sillywalks.org.sunrpc: udp 84 (DF) (ttl 255, id 23949, len 112) 0x 4500 0070 5d8d 4000 ff11 87bf c0a8 0a42E..p].@B 0x0010 c0a8 0a9d 033a 006f 005c c339 b296 4aab.:.o.\.9..J. 0x0020 0002 0001 86a0 0002 0x0030 0003 0001 001c 3dd8 0492=... 0x0040 0005 706c 7574 6f00 pluto... 0x0050 21:05:36.685941 dhcp157.in-10.sillywalks.org.sunrpc pluto.in-10.sillywalks.org.826: [udp sum ok] udp 28 (ttl 64, id 14738, len 56) 0x 4500 0038 3992 4011 aaf3 c0a8 0a9dE..89...@... 0x0010 c0a8 0a42 006f 033a 0024 64b9 b296 4aab...B.o.:.$d...J. 0x0020 0001 0x0030 03d1 21:05:36.688612 pluto.in-10.sillywalks.org.825 dhcp157.in-10.sillywalks.org.977: udp 92 (DF) (ttl 255, id 23950, len 120) 0x 4500 0078 5d8e 4000 ff11 87b6 c0a8 0a42E..x].@B 0x0010 c0a8 0a9d 0339 03d1 0064 012b b296 4aac.9...d.+..J. 0x0020 0002 0001 86b5 0004 0x0030 000c 0001 001c 3dd8 0492=... 0x0040 0005 706c 7574 6f00 pluto... 0x0050 -- [The next part is when I close the file] -- 21:05:39.077292 dhcp157.in-10.sillywalks.org.49445 pluto.in-10.sillywalks.org.lockd: udp 180 (ttl 64, id 14742, len 208) 0x 4500 00d0 3996 4011 aa57 c0a8 0a9dE...9...@..W 0x0010 c0a8 0a42 c125 0fcd 00bc e1bd 3ddd 99f1...B.%..=... 0x0020 0002 0001 86b5 0004 0x0030 0009 0001 0028 3dd7 f693...(=... 0x0040 0006 626f 656b 6a65 03e8boekje.. 0x0050 .. 21:05:39.078515 pluto.in-10.sillywalks.org.825 dhcp157.in-10.sillywalks.org.977: udp 92 (DF) (ttl 255, id 12356, len 120) 0x 4500 0078 3044 4000 ff11 b500 c0a8 0a42E..x0D@B 0x0010 c0a8 0a9d 0339 03d1 0064 0026 b296 4aad.9...d...J. 0x0020 0002 0001 86b5 0004 0x0030 000e 0001 001c 3dd8 0494=... 0x0040 0005 706c 7574 6f00 pluto... 0x0050 - I hope this is enough info for you, if you need a real dump to look at yourself, just let me know, I'll put it online then. HTH, Martijn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
Apparently, On Sun, Nov 17, 2002 at 12:23:20PM -0800, Julian Elischer said words to the effect of; On Sun, 17 Nov 2002, Mike Barcroft wrote: -- Kernel build for GENERIC started on Sun Nov 17 20:01:33 GMT 2002 -- === ipfilter /tinderbox/sparc64/src/sys/kern/kern_thread.c: In function `kse_create': /tinderbox/sparc64/src/sys/kern/kern_thread.c:498: `mp_ncpus' undeclared (first use in this function) /tinderbox/sparc64/src/sys/kern/kern_thread.c:498: (Each undeclared identifier is reported only once /tinderbox/sparc64/src/sys/kern/kern_thread.c:498: for each function it appears in.) ok mea culpa.. what is there in SPARC that should be used instead..? mp_ncpus is defined in sys/smp.h which is not included kern_thread.c I don't see why this builds on any platform. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Processes hanging in thrd_sleep
This late-night commit might help: jeff2002/11/17 01:33:00 PST Modified files: sys/kern kern_exec.c Log: - Release the imgp vnode prior to freeing exec_map resources to avoid deadlock. Revision ChangesPath 1.200 +4 -4 src/sys/kern/kern_exec.c To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rpc.lockd problems
On Sun, Nov 17, 2002 at 09:31:40PM +0100, Martijn Pronk wrote: I hope this is enough info for you, if you need a real dump to look at yourself, just let me know, I'll put it online then. Thanks, but the binary dump would be more useful so I can read it into ethereal. ethereal does a really good job of decoding RPC requests, so I can see exactly what is going on and what is different from my linux case. Kris msg46829/pgp0.pgp Description: PGP signature
ccd disklabel (what should work?)
In trying to setup a ccd on a -current system I
seem to have run into a few issues:
/etc/ccd.conf:
# ccd ileave flags component devices
ccd0 64 none/dev/ad1s1a /dev/ad2s1a
# ccdconfig -g
ccd064 0 /dev/ad1s1a /dev/ad2s1a
# ls -al /dev/ccd*
crw-r- 1 root operator 74, 2 Nov 17 22:09 /dev/ccd0c
So far, so good...
# disklabel -rw ccd0c auto
disklabel: auto: unknown disk type
# disklabel -rw ccd0 auto
disklabel: cannot open /dev/ccd0: No such file or directory
disklabel: auto: unknown disk type
#disklabel -e ccd0c
disklabel: ioctl DIOCWDINFO: no disk label on disk;
add -r to install initial label
re-edit the label? [y]:
Ok, let's just newfs the 'c' partition
# newfs -U /dev/ccd0c
/dev/ccd0c: 76345.1MB (156354688 sectors) block size 16384, fragment size 2048
using 416 cylinder groups of 183.69MB, 11756 blks, 23552 inodes.
with soft updates
super-block backups (for fsck -b #) at:
...
154614944, 154991136, 155367328, 155743520, 156119712
newfs: ioctl (WDINFO): /dev/ccd0c: can't rewrite disk label: No such process
Should we be able to disklabel 'auto' a ccd?
Should we be able to create multiple partitions? ('a','c','d', etc)
If not, the ccdconfig man page and handbook probably need
a bit of updating. They seem to indicate that the above should work.
Comments?
Thanks,
John
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
On Sun, Nov 17, 2002 at 03:46:55PM -0500, Jake Burkholder wrote: Apparently, On Sun, Nov 17, 2002 at 12:23:20PM -0800, Julian Elischer said words to the effect of; On Sun, 17 Nov 2002, Mike Barcroft wrote: -- Kernel build for GENERIC started on Sun Nov 17 20:01:33 GMT 2002 -- === ipfilter /tinderbox/sparc64/src/sys/kern/kern_thread.c: In function `kse_create': /tinderbox/sparc64/src/sys/kern/kern_thread.c:498: `mp_ncpus' undeclared (first use in this function) /tinderbox/sparc64/src/sys/kern/kern_thread.c:498: (Each undeclared identifier is reported only once /tinderbox/sparc64/src/sys/kern/kern_thread.c:498: for each function it appears in.) ok mea culpa.. what is there in SPARC that should be used instead..? mp_ncpus is defined in sys/smp.h which is not included kern_thread.c I don't see why this builds on any platform. Jake This does not compile on i386 with options SMP, either. It looks like a '#if 0' was removed in kern_thread.c rev 1.61, which exposes bug in SMP case. Something like this should fix kernel building. (I have no idea where to place the #include, though) Index: kern_thread.c === RCS file: /home/ncvs/src/sys/kern/kern_thread.c,v retrieving revision 1.61 diff -u -r1.61 kern_thread.c --- kern_thread.c 17 Nov 2002 11:47:03 - 1.61 +++ kern_thread.c 17 Nov 2002 22:22:35 - @@ -47,6 +47,10 @@ #include sys/ktr.h #include sys/ucontext.h +#ifdef SMP +#include sys/smp.h +#endif + #include vm/vm.h #include vm/vm_object.h #include vm/pmap.h To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
On Sun, 17 Nov 2002, Jake Burkholder wrote: Apparently, On Sun, Nov 17, 2002 at 12:23:20PM -0800, Julian Elischer said words to the effect of; On Sun, 17 Nov 2002, Mike Barcroft wrote: -- Kernel build for GENERIC started on Sun Nov 17 20:01:33 GMT 2002 -- === ipfilter /tinderbox/sparc64/src/sys/kern/kern_thread.c: In function `kse_create': /tinderbox/sparc64/src/sys/kern/kern_thread.c:498: `mp_ncpus' undeclared (first use in this function) /tinderbox/sparc64/src/sys/kern/kern_thread.c:498: (Each undeclared identifier is reported only once /tinderbox/sparc64/src/sys/kern/kern_thread.c:498: for each function it appears in.) ok mea culpa.. what is there in SPARC that should be used instead..? mp_ncpus is defined in sys/smp.h which is not included kern_thread.c I don't see why this builds on any platform. #if 0 /* while debugging */ #ifdef SMP if (kg-kg_kses mp_ncpus) #endif return (EPROCLIM); #endif (last night) seems to have changed in the last 12 hours to: #ifdef SMP if (kg-kg_kses mp_ncpus) #endif return (EPROCLIM); i.e. the #if 0 seems to have disappeared... I guess that David Xu forgot to include smp.h in his patch. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
alpha tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sun Nov 17 15:07:23 PST 2002 -- === vinum /h/des/src/sys/kern/kern_thread.c: In function `kse_create': /h/des/src/sys/kern/kern_thread.c:498: `mp_ncpus' undeclared (first use in this function) /h/des/src/sys/kern/kern_thread.c:498: (Each undeclared identifier is reported only once /h/des/src/sys/kern/kern_thread.c:498: for each function it appears in.) *** Error code 1 Stop in /h/des/obj/h/des/src/sys/GENERIC. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
X problems
if set the locale with zh_CN.EUC ,error occured
--xconsole:
pid 492 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped)
pid 494 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped)
pid 496 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped)
pid 498 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped)
pid 500 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped)
pid 502 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped)
pid 504 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped)
--.xsessesion-errors
_IceTransmkdir: Owner of /tmp/.ICE-unix should be set to root
SESSION_MANAGER=local/wsk.gddsn.org.cn:/tmp/.ICE-unix/485
Loaded background '0x809d840
Gnome-Message: gnome_execute_async_with_env_fds: returning -1
ICE default IO error handler doing an exit(), pid = 514, errno = 0
ICE default IO error handler doing an exit(), pid = 516, errno = 0
N
'²æìr¸zǧvf¢Új:+v¨· è® ¶§²æìr¸yúÞy» rêëz{bØ^nr¡ûazg¬±¨
X problems
hi,all: sorry the send before if set the locale with zh_CN.EUC ,error occured --xconsole: pid 492 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped) pid 494 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped) pid 496 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped) pid 498 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped) pid 500 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped) pid 502 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped) pid 504 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped) --.xsessesion-errors _IceTransmkdir: Owner of /tmp/.ICE-unix should be set to root SESSION_MANAGER=local/wsk.gddsn.org.cn:/tmp/.ICE-unix/485 Loaded background '0x809d840 Gnome-Message: gnome_execute_async_with_env_fds: returning -1 ICE default IO error handler doing an exit(), pid = 514, errno = 0 ICE default IO error handler doing an exit(), pid = 516, errno = 0 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Run two copies of named from rc.conf?
It would be nice if rc.conf could start a 2nd copy
of named (split dns). Comments on the following simplistic
patch?
-John
cvs diff: Diffing src/etc
Index: src/etc/rc.network
===
RCS file: /home/ncvs/src/etc/rc.network,v
retrieving revision 1.138
diff -u -r1.138 rc.network
--- src/etc/rc.network 2 Nov 2002 08:21:26 - 1.138
+++ src/etc/rc.network 18 Nov 2002 04:22:00 -
@@ -24,7 +24,7 @@
# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
# SUCH DAMAGE.
#
-# $FreeBSD$
+# $FreeBSD: src/etc/rc.network,v 1.138 2002/11/02 08:21:26 ume Exp $
# From: @(#)netstart 5.9 (Berkeley) 3/30/91
#
@@ -561,6 +561,11 @@
case ${named_enable} in
[Yy][Ee][Ss])
echo -n ' named'; ${named_program:-named} ${named_flags}
+ ;;
+ esac
+ case ${named_enable2} in
+ [Yy][Ee][Ss])
+ echo -n ' named'; ${named_program2:-named}
${named_flags2}
;;
esac
cvs diff: Diffing src/etc/defaults
Index: src/etc/defaults/rc.conf
===
RCS file: /home/ncvs/src/etc/defaults/rc.conf,v
retrieving revision 1.163
diff -u -r1.163 rc.conf
--- src/etc/defaults/rc.conf15 Nov 2002 08:26:36 - 1.163
+++ src/etc/defaults/rc.conf18 Nov 2002 04:25:01 -
@@ -13,7 +13,7 @@
#
# All arguments must be in double or single quotes.
#
-# $FreeBSD$
+# $FreeBSD: src/etc/defaults/rc.conf,v 1.163 2002/11/15 08:26:36 ru Exp $
##
### Important initial Boot-time options
@@ -140,6 +140,10 @@
# components of named. See /etc/rc.d/named.
named_symlink_enable=YES # Symlink /var/run/named.pid and /var/run/ndc
# to their chrooted counterparts.
+
+named_enable2=NO # Run a 2nd copy of named?
+named_program2=/usr/sbin/named
+named_flags2=-u bind -g bind
#
# kerberos. Do not run the admin daemons on slave servers
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Run two copies of named from rc.conf?
John De Boskey wrote: It would be nice if rc.conf could start a 2nd copy of named (split dns). IMO, running two named's on the same box is an edge case, and not likely to be attractive to the majority of our userbase. I think you might be better off with something in /usr/local/etc/rc.d. Doug -- We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory. - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Run two copies of named from rc.conf?
* De: Doug Barton [EMAIL PROTECTED] [ Data: 2002-11-17 ] [ Subjecte: Re: Run two copies of named from rc.conf? ] John De Boskey wrote: It would be nice if rc.conf could start a 2nd copy of named (split dns). IMO, running two named's on the same box is an edge case, and not likely to be attractive to the majority of our userbase. I think you might be better off with something in /usr/local/etc/rc.d. Or at least abstracting it in such a way that it doesn't get in anyone's way, and so it won't trigger the what if I need N where N2 case, and in some meaningful way... Like maybe using a named_configs lists, and start one named for each config, or something. -- Juli Mallett [EMAIL PROTECTED] OpenDarwin, Mono, FreeBSD Developer. ircd-hybrid Developer, EFnet addict. FreeBSD on MIPS-Anything on FreeBSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SMP stability ? [was Re: more info from panic from running dneton SMP kernel]
On Sun, 17 Nov 2002, Robert Watson wrote: I've seen several reports that using a serial break to get into ddb is now quite a bit more reliable than a keyboard break. If you're not already This is a fact. In RELENG_4, the keyboard interrupt handler is a normal tty interrupt handler so it can't interrupt things blocked by spltty(), while the sio interrupt handler is a fast interrupt handler so it can interrupt almost anything (anything not blocked by disable_intr(), which should be everything except fast interrupt handlers and the entry code for normal interrupt handlers). Things are much more broken in -current: the keyboard interrupt handler is non-MPSAFE so it can't interrupt things blocked by Giant (which is most syscalls), and the sio interrupt handler is a fast interrupt handler so it can't interrupt things blocked by critical_enter() (which is too many things for too long, so fast interrupt handlers aren't actually fast). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Run two copies of named from rc.conf?
John De Boskey wrote: It would be nice if rc.conf could start a 2nd copy of named (split dns). Comments on the following simplistic patch? Interior and exterior DNS is a useful case; however, there are multiple ways to set it up; in general, it's not possible to have interior authoritative DNS at the same time you have exterior authoritative DNS (this was a mistake we made on the InterJet, for a long time), without modifying the DNS server to forward requests for which it has incomplete information (e.g. the PNS draft RFC I wrote). See the files in: ftp://ftp.whistle.com/pub/terry/drafts/ for details. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
New NVidia drivers on -current
Has anyone tried them yet? After removing the #error triggered by __FreeBSD_version being over 50, I got the thing nvidia.ko to build, but: 00:50:30 aldan shutdown: reboot by root: New world, kernel. Nvidia drivers 00:56:12 aldan kernel: Preloaded elf module /boot/kernel/nvidia.ko at 0xc06470b0. 00:56:12 aldan kernel: VESA: NVidia 00:56:12 aldan kernel: VESA: NVidia Corporation NV15 Reference Board Chip Rev A0 00:56:14 aldan kernel: nvidia0: GeForce2 GTS mem 0xf000-0xf7ff,0xe900-0xe9ff irq 11 at device 0.0 on pci1 00:56:14 aldan kernel: pcib1: device nvidia0 requested decoded memory range 0xe900-0xe9ff 00:56:14 aldan kernel: pcib1: device nvidia0 requested unsupported memory range 0x0-0xe9ff (decoding 0xe900-0xe9ff, 0xf000-0xf7ff) 00:56:14 aldan kernel: nvidia0: Unable to allocate NVIDIA memory resource. 00:56:14 aldan kernel: device_probe_and_attach: nvidia0 attach returned 6 Any clues, or is, indeed, a major porting effort required to get it to work on -current? Thanks! -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
boot0cfg -B
Howdy crew, Any reason why this doesn't work ? sheelsudo boot0cfg -B ad0 boot0cfg: /dev/ad0: Operation not permitted running: FreeBSD 5.0-CURRENT #0: Fri Nov 8 15:07:18 CST 2002 Thanks - aW To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: New NVidia drivers on -current
On 2002-11-18 01:29 +, Mikhail Teterin wrote: Has anyone tried them yet? After removing the #error triggered by __FreeBSD_version being over 50, I got the thing nvidia.ko to build, but: 00:50:30 aldan shutdown: reboot by root: New world, kernel. Nvidia drivers 00:56:12 aldan kernel: Preloaded elf module /boot/kernel/nvidia.ko at 0xc06470b0. 00:56:12 aldan kernel: VESA: NVidia 00:56:12 aldan kernel: VESA: NVidia Corporation NV15 Reference Board Chip Rev A0 00:56:14 aldan kernel: nvidia0: GeForce2 GTS mem 0xf000-0xf7ff,0xe900-0xe9ff irq 11 at device 0.0 on pci1 00:56:14 aldan kernel: pcib1: device nvidia0 requested decoded memory range 0xe900-0xe9ff 00:56:14 aldan kernel: pcib1: device nvidia0 requested unsupported memory range 0x0-0xe9ff (decoding 0xe900-0xe9ff, 0xf000-0xf7ff) 00:56:14 aldan kernel: nvidia0: Unable to allocate NVIDIA memory resource. 00:56:14 aldan kernel: device_probe_and_attach: nvidia0 attach returned 6 Any clues, or is, indeed, a major porting effort required to get it to work on -current? Thanks! -mi http://www.thirteenandtwo.org/nvidia/faq.html The box is currently down, since somone decided to upgrade it to -CURRENT and messed up, but Marc Fonvieille was nice enough to put it up here until tomorrow or so: http://people.freebsd.org/~blackend/nvidia/faq.html (missing style sheet, but oh well). Basically it works fine on -CURRENT, what you are seeing could be because you have something interfering (anything from ACPI to some old ISA device), but most likely you are missing SYSVSHM or don't have sufficiently new X binaries (you need 4.2.1 -Servers, -clients and -libraries). If none of the above works, mdodd@ can most likely give you a better answer. -- Munish Chopra To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: X problems
On Sun, 2002-11-17 at 22:39, wsk wrote: if set the locale with zh_CN.EUC ,error occured --xconsole: pid 492 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped) pid 494 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped) pid 496 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped) pid 498 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped) pid 500 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped) pid 502 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped) pid 504 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped) The problem looks to be a corrupt msgstr in zh_CN.po. The string in question is: # SUN CHANGED MESSAGE #: server/object-directory-load.c:111 #, c-format msgid invalid character '%c' in iid '%s' I'm leaving for a business trip tomorrow, so I can't pursue this right now. However, I have collected a backtrace with full symbols, and if anyone wants to pursue this with the bonobo-activation developers. Note, backing down to rev 1.14 of zh_CN.po fixes the problem. A gzip'd patch is attached. Joe -- PGP Key : http://www.marcuscom.com/pgp.asc patch-po_zh_CN.po.gz Description: GNU Zip compressed data signature.asc Description: This is a digitally signed message part
Re: boot0cfg -B
On Mon, Nov 18, 2002 at 05:07:08PM +1030, Wilkinson,Alex wrote: Howdy crew, Any reason why this doesn't work ? sheelsudo boot0cfg -B ad0 boot0cfg: /dev/ad0: Operation not permitted running: FreeBSD 5.0-CURRENT #0: Fri Nov 8 15:07:18 CST 2002 GEOM, I presume? When file systems are mounted, GEOM does not allow processes to open the device special files for writing. This needs to be resolved. It is a known limitation and there's no work-around as far as I know. HTH, -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: New NVidia drivers on -current
On Mon, Nov 18, 2002 at 01:29:12AM -0500, Mikhail Teterin wrote: Has anyone tried them yet? After removing the #error triggered by __FreeBSD_version being over 50, I got the thing nvidia.ko to build, but: 00:50:30 aldan shutdown: reboot by root: New world, kernel. Nvidia drivers 00:56:12 aldan kernel: Preloaded elf module /boot/kernel/nvidia.ko at 0xc06470b0. 00:56:12 aldan kernel: VESA: NVidia 00:56:12 aldan kernel: VESA: NVidia Corporation NV15 Reference Board Chip Rev A0 00:56:14 aldan kernel: nvidia0: GeForce2 GTS mem 0xf000-0xf7ff,0xe900-0xe9ff irq 11 at device 0.0 on pci1 00:56:14 aldan kernel: pcib1: device nvidia0 requested decoded memory range 0xe900-0xe9ff 00:56:14 aldan kernel: pcib1: device nvidia0 requested unsupported memory range 0x0-0xe9ff (decoding 0xe900-0xe9ff, 0xf000-0xf7ff) 00:56:14 aldan kernel: nvidia0: Unable to allocate NVIDIA memory resource. 00:56:14 aldan kernel: device_probe_and_attach: nvidia0 attach returned 6 Any clues, or is, indeed, a major porting effort required to get it to work on -current? Thanks! Try putting this in your loader.conf: hw.pci.allow_unsupported_io_range=1 This allowed the device to probe for me, but the system locks up when I try and start X. Kris msg46846/pgp0.pgp Description: PGP signature
