Re: Yet another crash in FreeBSD 5.1
On Sunday, 3 August 2003 at 0:31:45 -0400, John Baldwin wrote: On 03-Aug-2003 Greg 'groggy' Lehey wrote: On Saturday, 2 August 2003 at 16:47:13 +0200, Eivind Olsen wrote: [EMAIL PROTECTED]:~/tmp/debug gdb -k kernel.debug (kgdb) list *(g_dev_strategy+29) This is almost certainly the wrong function. At the very list you should look at the arguments passed to it. Actually, this line can be very instructive. Since 'bp' is valid it is probably the bp2 from g_clone_bio() that is NULL. You might want to ask phk about that one. I think you'll find that there's a null dev pointer in there. As I say, I've seen this scenario before (without GEOM), and I'd be surprised if this were phk's problem. (kgdb) list *(launch_requests+448) No symbol launch_requests in current context. (kgdb) list *(vinumstart+2b2) No symbol vinumstart in current context. (kgdb) Read the links I just sent you. You haven't loaded the Vinum symbols. Bah, this isn't hard for you to do either: ... once you've loaded the symbols. That's why I pointed to the links. As I said to Terry, the real issue here is probably what was happening at the time, not the contents of the dump. Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Re: Yet another crash in FreeBSD 5.1
--On 3. august 2003 00:31 -0400 John Baldwin [EMAIL PROTECTED] wrote: But you knew that. Also, Eivind, you need to use hex, not decimal offsets from the functions. You might want to redo the g_dev_strategy() line with 0x29 instead of 29. I already though about that so I tested the commands both with and without 0x in front of those numbers and I get exactly the same output, so it looks like gdb interprets them as hex anyway: (kgdb) list *(g_dev_strategy+0x29) 0xc02e8139 is in g_dev_strategy (/usr/src/sys/geom/geom_dev.c:415). 410 KASSERT(cp-acr || cp-acw, 411 (Consumer with zero access count in g_dev_strategy)); 412 413 bp2 = g_clone_bio(bp); 414 KASSERT(bp2 != NULL, (XXX: ENOMEM in a bad place)); 415 bp2-bio_offset = (off_t)bp-bio_blkno DEV_BSHIFT; 416 KASSERT(bp2-bio_offset = 0, 417 (Negative bio_offset (%jd) on bio %p, 418 (intmax_t)bp2-bio_offset, bp)); 419 bp2-bio_length = (off_t)bp-bio_bcount; -- Regards / Hilsen Eivind Olsen [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Anyone use WINE at all anywhere?
On Fri, Aug 01, 2003 at 05:38:33PM -0700, Julian Elischer wrote: Is the re ANYONE that uses wine on -current...? for that matter, a -current user that uses wine on 4.x? I sometimes uses wine to run Kazaa, I had issues with -CURRENT and wine, so I just stick on 4.X for that purpose. Marc ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Yet another crash in FreeBSD 5.1
--On 3. august 2003 09:35 +0930 Greg 'groggy' Lehey [EMAIL PROTECTED] wrote: This is the real issue. Until you supply the information I ask for in the man page or at http://www.vinumvm.org/vinum/how-to-debug.html, only Terry can help you. Ok, I'll try to supply that information: Q: What problems are you having? A: FreeBSD RELENG_5_1 crashes with the following text shown on screen: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x14 fault code = supervisor write, page not present instruction pointer = 0x8:0xc02e8139 stack pointer = 0x10:0xcfb5284c frame pointer = 0x10:0xcfb52880 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 = 10785 (ctl_cyrusdb) kernel: type 12 trap, code=0 Stopped at g_dev_strategy+0x29:movl%eax,0x14(%ebx) Q: Which version of FreeBSD are you running? A: FreeBSD 5.1, tracking RELENG_5_1, cvsupped in the morning of the 27th of July if I'm not mistaken. Q: Have you made any changes to the system sources, including Vinum? A: No, it's all taken from the cvsup. I do have a custom kernel since I need to use ipfilter but that's really the only change. I've done the following changes: makeoptions DEBUG=-g options DDB options IPFILTER options IPFILTER_LOG options IPFILTER_DEFAULT_BLOCK Q: Supply the output of the vinum list command. If you can't start Vinum, supply the on-disk configuration, as described below. If you can't start Vinum, then (and only then) send a copy of the configuration file. A: Here it is: vimes# vinum vinum - list 2 drives: D WHITE State: up /dev/ad2s1e A: 0/113046 MB (0%) D BLACK State: up /dev/ad0s1d A: 0/113046 MB (0%) 6 volumes: V var State: up Plexes: 2 Size: 6144 MB V usrlocal State: up Plexes: 2 Size: 6144 MB V tmp State: up Plexes: 1 Size:255 MB V usr State: up Plexes: 2 Size: 6144 MB V home State: up Plexes: 2 Size: 8192 MB V storage State: up Plexes: 1 Size:168 GB 10 plexes: P var.p0 C State: up Subdisks: 1 Size: 6144 MB P var.p1 C State: up Subdisks: 1 Size: 6144 MB P usrlocal.p0 C State: up Subdisks: 1 Size: 6144 MB P usrlocal.p1 C State: up Subdisks: 1 Size: 6144 MB P tmp.p0 S State: up Subdisks: 2 Size:255 MB P usr.p0 C State: up Subdisks: 1 Size: 6144 MB P usr.p1 C State: up Subdisks: 1 Size: 6144 MB P home.p0 C State: up Subdisks: 1 Size: 8192 MB P home.p1 C State: up Subdisks: 1 Size: 8192 MB P storage.p0 S State: up Subdisks: 2 Size:168 GB 12 subdisks: S var.p0.s0 State: up D: BLACKSize: 6144 MB S var.p1.s0 State: up D: WHITESize: 6144 MB S usrlocal.p0.s0State: up D: BLACKSize: 6144 MB S usrlocal.p1.s0State: up D: WHITESize: 6144 MB S tmp.p0.s0 State: up D: BLACKSize:127 MB S tmp.p0.s1 State: up D: WHITESize:127 MB S usr.p0.s0 State: up D: BLACKSize: 6144 MB S usr.p1.s0 State: up D: WHITESize: 6144 MB S home.p0.s0State: up D: BLACKSize: 8192 MB S home.p1.s0State: up D: WHITESize: 8192 MB S storage.p0.s0 State: up D: BLACKSize: 84 GB S storage.p0.s1 State: up D: WHITESize: 84 GB vinum - Q: Supply an extract of the Vinum history file. Unless you have explicitly renamed it, it will be /var/log/vinum_history. This file can get very big; please limit it to the time around when you have the problems. Each line contains a timestamp at the beginning, so you will have no difficulty in establishing which data is of relevance. A: It's so small, I'll give the complete vinum_history log: vimes# cat vinum_history 26 Jul 2003 18:43:38.056211 *** vinum started *** 26 Jul 2003 18:43:39.456133 list 26 Jul 2003 18:43:41.631830 list 26 Jul 2003 18:43:42.598409 list 26 Jul 2003 18:43:46.885029 quit 26 Jul 2003 18:43:48.450706 *** vinum started *** 26 Jul 2003 18:43:51.745079 help 26 Jul 2003 18:47:54.213327 *** vinum started *** 26 Jul 2003 18:47:54.216030 create install-vinum.conf drive BLACK device /dev/ad0s1d drive WHITE device /dev/ad2s1e volume var setupstate plex org concat sd length
acpi - too hot, make world dies with various signals
Hello I attempted to do make buildworld on my N610c laptop but it kept dying with various signals *** Signal 4 *** Signal 11 The fan does go off and on in response to high CPU activity but I am guessing not enough and not soon enough. I rebooted with acpi disabled so that fan runs continuously (when there is AC power). Buildworld is now almost complete. It would be nice if acpiconf had option to switch cooling on (permanently) and off (well until acpi decided it was too hot). (Hmm maybe if I had of used 'acpiconf -d' I wouldn't have had to reboot and I could just disable thermal portion of acpi at boot. Wil that leave fan on when no ac power??? hmm.) Even better if acpi switched cooling on sooner. I'll try to look at it myself but that wont be till next weekend. But if anyone has patches or wants me to get debug info I'd be happy to try. thanks -- tonym ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Yet another crash in FreeBSD 5.1
--On 3. august 2003 09:37 +0930 Greg 'groggy' Lehey [EMAIL PROTECTED] wrote: Read the links I just sent you. You haven't loaded the Vinum symbols. I'm not sure exactly what to do here. I have absolutely no previous experience with kernel debugging, using gdb etc. so I'm lost without specific instructions on what to do, what to try etc. The vinum.ko file is not stripped: [EMAIL PROTECTED]:~/tmp/debug file /boot/kernel/vinum.ko /boot/kernel/vinum.ko: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped [EMAIL PROTECTED]:~/tmp/debug The web page mentions that I should either use the crash dump (which isn't created...) or use remote serial gdb to analyze the problem. I guess I'll have to find a nullmodem cable, install FreeBSD on another computer here (I couldn't find a Windows version of gdb) and try to figure out exactly how to do remote GDB debugging (I've looked around in the developers handbook, specifically http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerne ldebug-online-gdb.html) -- Regards / Hilsen Eivind Olsen [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Yet another crash in FreeBSD 5.1
On Sunday, 3 August 2003 at 11:17:49 +0200, Eivind Olsen wrote: --On 3. august 2003 09:37 +0930 Greg 'groggy' Lehey [EMAIL PROTECTED] wrote: Read the links I just sent you. You haven't loaded the Vinum symbols. I'm not sure exactly what to do here. I have absolutely no previous experience with kernel debugging, using gdb etc. so I'm lost without specific instructions on what to do, what to try etc. Don't worry too much about that at the moment. Let me analyze the info you've sent me, and I'll ask some more questions. Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
exclusive sleep mutex ifnet r = 0 (0xfffffc00006dca90) locked@sys/nfsclient/bootp_subr.c:1692
I'm getting the following when I try and netboot the alpha package machines (note also the missing space in the diagnostic message): malloc() of 4096 with the following non-sleepablelocks held: exclusive sleep mutex ifnet r = 0 (0xfc6dca90) locked @ /a/asami/portbuild/alpha/src-client/sys/nfsclient/bootp_subr.c:1692 witness_warn Stopped at Debugger+0x38: zapnot v0,#0xf,v0 v0=0x0 db trace Debugger() at Debugger+0x38 witness_warn() at witness_warn+0x284 uma_zalloc_arg() at uma_zalloc_arg+0xd0 malloc() at malloc+0x11c allocifctx() at allocifctx+0x30 bootpc_init() at bootpc_init+0x144 nfs_mountroot() at nfs_mountroot+0x30 nfs_mount() at nfs_mount+0x34 vfs_mountroot_try() at vfs_mountroot_try+0x250 vfs_mountroot() at vfs_mountroot+0xb4 start_init() at start_init+0x80 fork_exit() at fork_exit+0x100 exception_return() at exception_return --- root of call graph --- db pgp0.pgp Description: PGP signature
Re: 5.1 on an A31p
Jesse Guardiani wrote: Ben Laurie wrote: So, after a long pause, I'm trying to get 5.x working on my IBM A31p. I've made a boot CD from the 5.1 ISO images, vintage a week or so ago. When I boot (in any mode, ACPI on or off, or Safe), it dies immediately after discovering firewire: firewire0: IEEE1394(FireWire) bus on fwohci0 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x2c fault code = supervisor read, page not present instruction pointer= 0x8:0xc02e5a50 stack pointer = 0x10:0xc0ae39b0 frame pointer = 0x10:0xc0ae39b4 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= 0 (swapper) trap number= 12 panic: page fault Now what? I had the same problem on an IBM A30p with 5.1. Do this at the boot loader prompt: set hw.pci.allow_unsupported_io_range=1 That should take care of it. You'll need to place the part after 'set' in your /boot/device.hints file after you complete the install, otherwise your kernel will continue to fail at boot. That did the trick, thanks. Cheers, Ben. HTH. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Problems with bktr on -current
Hello, I've got some trouble with the bktr-driver on FreeBSD 5.x. With fxtv the video-output is distorted and choppy, it appears that only odd scanlines are redrawn regularly while even scanlines remain for like half a second as ghost images. When the fxtv window is overlapped by some other window the video is only updated about every 30 seconds. When using mplayer's bsdbt848-driver I get an undistorted image but also choppy video. I wasn't able to test it with xawtv since it's still broken on 5.x. This is a regression over 4.x, where everything works flawlessly. I can reproduce these Problems on FreeBSD 5.0, 5.1, -CURRENT and also on NetBSD 1.6.1. So my guess is that this is related to some more recent patches which have been applied to FreeBSD 5.x and NetBSD 1.6.1 but not FreeBSD 4.8. Does anybody have similar problems or does anybody know what changes might have caused this problem? Here's the relevant dmesg output: bktr0: BrookTree 878 mem 0xd700-0xd7000fff irq 9 at device 10.0 on pci0 bktr0: Hauppauge Model 44354 C242 bktr0: Detected a MSP3415G-B8 at 0x80 bktr0: Hauppauge WinCast/TV, Philips FR1216 PAL FM tuner, msp3400c stereo, remote control. Please CC me since I'm not subscribed to -current. -- Guido Berhoerster[EMAIL PROTECTED] http://www.guido-berhoerster.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: acpi - too hot, make world dies with various signals
Hi, Agree fully. I have the same problem on my ThinkPad T21 - as reported on this list earlier. Running without ACPI is no problem. Another problem when running with ACPI is that suspend mode doesn't turn the display off. Pretty annoying, and besides it will never come back from suspend either :) So for now I'm running without acpi all the time. Better that way. //Eirik On Sun, 3 Aug 2003 18:59:52 +1000 (EST) Tony Maher [EMAIL PROTECTED] wrote: Hello I attempted to do make buildworld on my N610c laptop but it kept dying with various signals *** Signal 4 *** Signal 11 The fan does go off and on in response to high CPU activity but I am guessing not enough and not soon enough. I rebooted with acpi disabled so that fan runs continuously (when there is AC power). Buildworld is now almost complete. It would be nice if acpiconf had option to switch cooling on (permanently) and off (well until acpi decided it was too hot). (Hmm maybe if I had of used 'acpiconf -d' I wouldn't have had to reboot and I could just disable thermal portion of acpi at boot. Wil that leave fan on when no ac power??? hmm.) Even better if acpi switched cooling on sooner. I'll try to look at it myself but that wont be till next weekend. But if anyone has patches or wants me to get debug info I'd be happy to try. thanks -- tonym ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
nvidia-driver not loading GLX.
Hello list, I'm having some problems getting 3D support on my Ti4800SE. I've built nvidia-driver-1.0.4365 with WITH_NVIDIA_HACKS and without. I've used and not used the FreeBSD agp module. but I keep getting the same error when I try to start X with the loading the glx module. Attached is my dmesg output, /var/log/XFree86.0.log and my X config. uname -a returns: FreeBSD nova 5.1-CURRENT FreeBSD 5.1-CURRENT #3: Fri Aug 1 01:16:29 EST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NOVA i386 X loads up fine when I comment out 'Load glx'. Also I get Bus error (core dumped) with some programs, mplayer for one. Anyways some help would be much appreciated -Al 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 #3: Fri Aug 1 01:16:29 EST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NOVA Preloaded elf kernel /boot/kernel/kernel at 0xc06da000. Preloaded elf module /boot/modules/vesa.ko at 0xc06da244. Preloaded elf module /boot/modules/cd9660.ko at 0xc06da2f0. Preloaded elf module /boot/modules/msdosfs.ko at 0xc06da39c. Preloaded elf module /boot/modules/procfs.ko at 0xc06da44c. Preloaded elf module /boot/modules/pseudofs.ko at 0xc06da4f8. Preloaded elf module /boot/modules/md.ko at 0xc06da5a8. Preloaded elf module /boot/modules/linux.ko at 0xc06da650. Preloaded elf module /boot/modules/sysvshm.ko at 0xc06da6fc. Preloaded elf module /boot/modules/sysvsem.ko at 0xc06da7ac. Preloaded elf module /boot/modules/sysvmsg.ko at 0xc06da85c. Preloaded elf module /boot/modules/if_ppp.ko at 0xc06da90c. Preloaded elf module /boot/modules/if_tun.ko at 0xc06da9b8. Preloaded elf module /boot/modules/miibus.ko at 0xc06daa64. Preloaded elf module /boot/modules/if_rl.ko at 0xc06dab10. Preloaded elf module /boot/modules/ng_bpf.ko at 0xc06dabbc. Preloaded elf module /boot/modules/netgraph.ko at 0xc06dac68. Preloaded elf module /boot/modules/ng_ether.ko at 0xc06dad18. Preloaded elf module /boot/modules/ng_ppp.ko at 0xc06dadc8. Preloaded elf module /boot/modules/snd_pcm.ko at 0xc06dae74. Preloaded elf module /boot/modules/snd_emu10k1.ko at 0xc06daf24. Preloaded elf module /boot/modules/usb.ko at 0xc06dafd8. Preloaded elf module /boot/modules/uhid.ko at 0xc06db084. Preloaded elf module /boot/modules/ukbd.ko at 0xc06db130. Preloaded elf module /boot/modules/ums.ko at 0xc06db1dc. Preloaded elf module /boot/modules/umass.ko at 0xc06db288. Preloaded elf module /boot/modules/random.ko at 0xc06db334. Preloaded elf module /boot/modules/linprocfs.ko at 0xc06db3e0. Preloaded elf module /boot/modules/firewire.ko at 0xc06db490. Preloaded elf module /boot/modules/fdc.ko at 0xc06db540. Preloaded elf module /boot/modules/acpi.ko at 0xc06db5ec. Preloaded elf module /boot/modules/nvidia.ko at 0xc06db698. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 2533056136 Hz CPU: Intel(R) Pentium(R) 4 CPU 2.53GHz (2533.06-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf27 Stepping = 7 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE real memory = 536854528 (511 MB) avail memory = 514031616 (490 MB) Pentium Pro MTRR support enabled VESA: v3.0, 131072k memory, flags:0x1, mode table:0xc0376c62 (122) VESA: NVIDIA npx0: math processor on motherboard npx0: INT 16 interface acpi0: ASUS P4S8Xon motherboard pcibios: BIOS version 2.10 Using $PIR table, 11 entries at 0xc00f1720 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu1: CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib0: slot 2 INTA is routed to irq 11 pcib0: slot 3 INTA is routed to irq 9 pcib0: slot 3 INTB is routed to irq 9 pcib0: slot 3 INTC is routed to irq 9 pcib0: slot 14 INTA is routed to irq 11 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib1: slot 0 INTA is routed to irq 11 nvidia0: GeForce4 Ti 4800 SE mem 0xf000-0xf7ff,0xdf00-0xdfff irq 11 at device 0.0 on pci1 isab0: PCI-ISA bridge at device 2.0 on pci0 isa0: ISA bus on isab0 fwohci0: vendor=1039, dev=7007 fwohci0: 1394 Open Host Controller Interface mem 0xde80-0xde800fff at device 2.3 on pci0 pcib0: slot 2 INTB is routed to irq 5 fwohci0: OHCI version 1.0 (ROM=1) fwohci0: No. of Isochronous channel is 4. fwohci0: EUI64 00:e0:18:00:00:0a:83:4c fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: IEEE1394(FireWire) bus on fwohci0 fwohci0: Initiate bus reset atapci0: SiS 963 UDMA133 controller port 0xb400-0xb40f,0xb800-0xb803,0xd000-0xd007,0xd400-0xd403,0xd800-0xd807 irq 11 at device 2.5 on pci0 ata0: at 0x1f0
INET6 in world
Hi David, I've seen that several world daemons (rpcbind, telnetd, ...) are build with INET6. In real life, I do not know anyone who owns some IPv6 addresses but many guys who disabled INET6 on their machines in kernel. Now the daemons prints out a (IMHO useless) warning, that they cannot bind to the INET6 socket on each start. Especially on workstation, which might to be started each day, this confuses the employee (each one once, but me as admin each time). Now the question: Would a patch be welcome which enables INET6 only if /etc/make.conf not contains 'NO_INET6=true'? Best regards and nice weekend, Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] jail NG schript patch for mounting devfs and procfsautomatically
On 02.08.2003 01:29, Mike Makonnen wrote: On Tue, Jul 29, 2003 at 08:27:07PM +0200, Jens Rehsack wrote: On 29.07.2003 19:21, Mike Makonnen wrote: On Tue, Jul 29, 2003 at 07:08:38PM +0200, Jens Rehsack wrote: Yeah, I'll take care of this. I had asked scott to mail me his final patch so I could commit it, but I never heard back from him. I'll dig out the revisions from my mail archives and combine the two. You can mail me the patch first, so that I can test it before you commit it, if you want. Hi Jens, Can you apply the attached patches and let me know how it goes? Cheers. Hi Mike, hi Scot, the patch works for me very well. I've checked what's been done and had only small recommendations: - Wouldn't it be better to configure the devfs rules by /etc/devfs.conf or is it impossible? - Even it would be a good thing, if I could specify a ruleset for each jail, and fallback to devfs_ruleset_jail if no jail_example_devfs_ruleset is specified? Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nvidia-driver not loading GLX.
Just a follow-up. This is what happens when I run on an generic kernel. nvidia0: GeForce4 Ti 4800 SE mem 0xf000-0xf7ff,0xdf00-0xdfff irq 11 at device 0.0 on pci1 malloc() of 32 with the following non-sleepablelocks held: exclusive sleep mutex dev.mtx_api r = 0 (0xc468718c) locked @ /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_subr.c:753 malloc() of 32 with the following non-sleepablelocks held: exclusive sleep mutex dev.mtx_api r = 0 (0xc468718c) locked @ /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_subr.c:753 malloc() of 4096 with the following non-sleepablelocks held: exclusive sleep mutex dev.mtx_api r = 0 (0xc468718c) locked @ /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_subr.c:753 malloc() of 32 with the following non-sleepablelocks held: exclusive sleep mutex dev.mtx_api r = 0 (0xc468718c) locked @ /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_subr.c:753 malloc() of 32 with the following non-sleepablelocks held: exclusive sleep mutex dev.mtx_api r = 0 (0xc468718c) locked @ /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_subr.c:753 malloc() of 4096 with the following non-sleepablelocks held: exclusive sleep mutex dev.mtx_api r = 0 (0xc468718c) locked @ /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_subr.c:753 malloc() of 32 with the following non-sleepablelocks held: exclusive sleep mutex dev.mtx_api r = 0 (0xc468718c) locked @ /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_subr.c:753 malloc() of 32 with the following non-sleepablelocks held: exclusive sleep mutex dev.mtx_api r = 0 (0xc468718c) locked @ /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_subr.c:753 malloc() of 4096 with the following non-sleepablelocks held: exclusive sleep mutex dev.mtx_api r = 0 (0xc468718c) locked @ /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_subr.c:753 malloc() of 32 with the following non-sleepablelocks held: exclusive sleep mutex dev.mtx_api r = 0 (0xc468718c) locked @ /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_subr.c:753 malloc() of 32 with the following non-sleepablelocks held: exclusive sleep mutex dev.mtx_api r = 0 (0xc468718c) locked @ /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_subr.c:753 malloc() of 32 with the following non-sleepablelocks held: exclusive sleep mutex dev.mtx_api r = 0 (0xc468718c) locked @ /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_subr.c:753 malloc() of VM OBJECT with the following non-sleepablelocks held: exclusive sleep mutex dev.mtx_api r = 0 (0xc468718c) locked @ /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_subr.c:753 malloc() of DP fakepg with the following non-sleepablelocks held: exclusive sleep mutex ctl.mtx_api r = 0 (0xc484a1ac) locked @ /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_subr.c:753 malloc() of 32 with the following non-sleepablelocks held: exclusive sleep mutex dev.mtx_api r = 0 (0xc468718c) locked @ /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_subr.c:753 malloc() of 32 with the following non-sleepablelocks held: exclusive sleep mutex dev.mtx_api r = 0 (0xc468718c) locked @ /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_subr.c:753 malloc() of 4096 with the following non-sleepablelocks held: exclusive sleep mutex dev.mtx_api r = 0 (0xc468718c) locked @ /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_subr.c:753 malloc() of 32 with the following non-sleepablelocks held: exclusive sleep mutex dev.mtx_api r = 0 (0xc468718c) locked @ /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_subr.c:753 malloc() of 32 with the following non-sleepablelocks held: exclusive sleep mutex dev.mtx_api r = 0 (0xc468718c) locked @ /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_subr.c:753 malloc() of 32768 with the following non-sleepablelocks held: exclusive sleep mutex dev.mtx_api r = 0 (0xc468718c) locked @ /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_subr.c:753 malloc() of DP fakepg with the following non-sleepablelocks held: exclusive sleep mutex ctl.mtx_api r = 0 (0xc484a1ac) locked @ /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_subr.c:753 pid 616 (XFree86), uid 0: exited on signal 6 (core dumped) lock order reversal ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] jail NG schript patch for mounting devfs and procfsautomatically
On 03.08.2003 16:11, Jens Rehsack wrote: On 02.08.2003 01:29, Mike Makonnen wrote: On Tue, Jul 29, 2003 at 08:27:07PM +0200, Jens Rehsack wrote: On 29.07.2003 19:21, Mike Makonnen wrote: On Tue, Jul 29, 2003 at 07:08:38PM +0200, Jens Rehsack wrote: Yeah, I'll take care of this. I had asked scott to mail me his final patch so I could commit it, but I never heard back from him. I'll dig out the revisions from my mail archives and combine the two. You can mail me the patch first, so that I can test it before you commit it, if you want. Hi Jens, Can you apply the attached patches and let me know how it goes? Cheers. Hi Mike, hi Scot, the patch works for me very well. Ahh - being able to read benefits clearly :-) Without having rc_debug=YES turned on the boot process shows an error: devfs_link: not found. It's called from within etc/rc.d/jails to link /var/log/log etc. Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ACPI, PS/2 Mouse vs Compaq 2105US (presario 2100)
All, Recently started trying to get freebsd 5.1+ to work on my laptop. With 5.1 and above, I've found that unless ACPI is disabled, I cant use any PS/2 mouse - external or the internal synaptics pad. Boot -v reveals that psm0 cannot grab an interrupt. Boot logs are available here: http://humphrey.dyndns.org/boot.acpi http://humphrey.dyndns.org/boot.noacpi I would just run without ACPI, but the machine is one of these pesky built for XP ACPI only machines, and I find that with no ACPI I cant use the built in nic...makes the machine kinda useless. The machine has the latest BIOS as of yesterday. Current was 1-2 days old. I could swear that this used to work with 5.0-current. I've tried the device.hints workaround I saw mentioned to another person reporting a similar problem - assigning atkbd to acpi rather than isa, but this did not solve the problem. Any suggestions? Willing to try patches/hacking as directed. Cheers, Brendon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on amd64/amd64
TB --- mkdir /home/des/tinderbox/CURRENT ___ [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 --- mkdir /home/des/tinderbox/CURRENT ___ [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 --- mkdir /home/des/tinderbox/CURRENT ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on ia64/ia64
TB --- mkdir /home/des/tinderbox/CURRENT ___ [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 --- mkdir /home/des/tinderbox/CURRENT ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on sparc64/sparc64
TB --- mkdir /home/des/tinderbox/CURRENT ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with bktr on -current
On Sun, 3 Aug 2003, Guido Berhoerster wrote: I've got some trouble with the bktr-driver on FreeBSD 5.x. With fxtv the video-output is distorted and choppy, it appears that only odd scanlines are redrawn regularly while even scanlines remain for like half a second as ghost images. When the fxtv window is overlapped by some other window the video is only updated about every 30 seconds. When using mplayer's bsdbt848-driver I get an undistorted image but also choppy video. I wasn't able to test it with xawtv since it's still broken on 5.x. Interesting. I've also seen some visual peculiarities with fxtv lately on my 5.1-CURRENT box under similar circumstances: if I move windows around, sometimes video garbage is left behind -- especially alternating scanlines. I haven't tried backing out to earlier versions, though, so I'll give that a try and see if the problem goes away. 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]
dma error
versions this happened on: 4.8-release, 5.1-release, 5.1-current with dma enabled, panics with anic errors occur left and right during intensive hdd i/o... examples are during a non-minimal sysinstall, and during a tar -xvf of the entire ports collection this is on an asus a7v-ve ( http://www.hp.com/cposupport/personal_computing/support_doc/bph07371.html ) -bash-2.05b$ dmesg|grep atapci atapci0: VIA 82C686B UDMA100 controller port 0xd800-0xd80f at device 7.1 on pci0 atapci0: Correcting VIA config for southbridge data corruption bug ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 atapci0: VIA 82C686B UDMA100 controller port 0xd800-0xd80f at device 7.1 on pci0 atapci0: Correcting VIA config for southbridge data corruption bug ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 disabling dma seemed to fix the problem ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dma error
It seems ryan chris wrote: versions this happened on: 4.8-release, 5.1-release, 5.1-current with dma enabled, panics with anic errors occur left and right during intensive hdd i/o... examples are during a non-minimal sysinstall, and during a tar -xvf of the entire ports collection this is on an asus a7v-ve ( http://www.hp.com/cposupport/personal_computing/support_doc/bph07371.html ) -bash-2.05b$ dmesg|grep atapci atapci0: VIA 82C686B UDMA100 controller port 0xd800-0xd80f at device 7.1 on pci0 atapci0: Correcting VIA config for southbridge data corruption bug ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 atapci0: VIA 82C686B UDMA100 controller port 0xd800-0xd80f at device 7.1 on pci0 atapci0: Correcting VIA config for southbridge data corruption bug ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 disabling dma seemed to fix the problem You have one of the bug ridden VIA 82c686B southbridges, and the normal procedure for fixing this problem is to get a new BIOS that programs the chipset correctly.. -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bge vlan stranges
On Sun, 2003-08-03 at 02:28, Terry Lambert wrote: The fact of the matter is, if you use 802.1q encapsulation, the total frame size can be 1504. That is the standard. This is truly evil. Actually, after a lot of discussions over this very topic during the IEEE ratification process, the 802.1Q standard allows for both varieties. The 1522 total frame size has become the de-facto standard though, for pretty obvious reasons. If I was down at the office now, I could have looked up the relevant sections of the standard and related notes, but since I'm not, this is taken from memory. You all probably this part, but the 802.1Q header is inserted directly behind the DA/SA header fields, i.e. before the EtherType field in Ethernet_II frames (the Length field in legacy 802.3 ethernet frames). This means legacy implementations who doesn't understand 802.1Q and looks for Length/EtherType at a given offset in the Ethernet header will instead find 8100, the Tag Protocol Identifier in 802.1Q. These legacy implementations will therefore typically discard the packet. With this in mind, it was anticipated that devices who knew how to handle 802.1Q header fields would also be designed to handle the added 4 bytes to the total frame length. This however was the topic for a lot of the discussion, since a lot of vendors could easily adapt their software to understand the required headers, but allowing for longer frame lengths quickly ran into hardware issues. So provisions were made in the standard to allow for devices to reduce the maximum payload size to 1496 if they can not handle frames exceeding 1518 bytes total length. This is however left as an implementation detail, and it is up to the vendors and/or end-users to make sure all devices connected to a given Ethernet only use 1496 bytes data segments if using this legacy compatibility provision in the standard. I would suggest, though, that L2 switches shouldn't be boundaries for this type of encapsulation, if this is the case. Worst case, though, an attempt at PMTU through a switch that did this anyway should end up with whatever MTU the host has setup. I expect that the 802.1q encapsulation of 1500 MTU packets (yielding 1504 MTU packets on the wire) was actually intended to operate in switch-to-switch trunking, not sitch-to-host trunking. Indeed, the primary point of the 802.1Q standard was to allow for fully transparent trunking in the bridge-to-bridge domain, typically by inserting the 802.1Q tag at the boundary of the VLAN domain and stripping it when the frame leaves the 802.1Q aware domain - usually at the switches where the end-stations are connected. Effectively, this means the machine that's doing it's own VLAN stuff is really a trunk endpoint, not a traditional ethernet endpoint. Yes, any machine that handles VLAN stuff is now effectively an extended part of the bridge domain and is no longer really an Ethernet end-station. I have no problem with this. I'm just pointing out that not all cards will be able to support the idea, and that if you depend on arbitrary cards supporting it, you are going to get shot in the foot. Again, this is stated in the standard. If wish to use 802.1Q trunking on legacy devices, then it is up to you to make sure all other devices participating in this given Ethernet adheres to using 1496 bytes as the maximum payload size, as there is obviously no way for the protocol to negotiate this, nor to return any form of error messages to any misbehaving hosts. Actually, I'd say that you probably should not be doing 802.1Q trunking at all on a NIC not capable of exceeding a max frame size of 1518 bytes, as you are almost certain to run into problems - with the possible exception of cases like e.g. a firewall hanging off a point-to-point connection with a router and handling multiple VLANs, where you can set the correct MTU on both sides. /leg ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
AP 3 failed
When using console redirection on SE7505VB2 Intel board I seem to get occasional failures on starting the second core of the second CPU. Also, on the same board, including device ichsmb on kernel config will result in hang on boot 100%. The sources are from yesterday. /boot/kernel/acpi.ko text=0x3c8bc data=0x16ec+0xec0 syms=[0x4+0x5b50+0x4+0x798e] 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 #5: Sun Aug 3 14:17:10 EEST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/ROMMON-SERVER Preloaded elf kernel /boot/kernel/kernel at 0xc05c7000. Preloaded elf module /boot/kernel/acpi.ko at 0xc05c72bc. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 2392039876 Hz CPU: Intel(R) Xeon(TM) CPU 2.40GHz (2392.04-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf27 Stepping = 7 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Hyperthreading: 2 logical CPUs real memory = 2146893824 (2047 MB) avail memory = 2083590144 (1987 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 Programming 24 pins in IOAPIC #1 Programming 24 pins in IOAPIC #2 AP #3 (PHY# 7) failed! Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: INET6 in world
On Sun, Aug 03, 2003 at 04:07:15PM +0200, Jens Rehsack wrote: Hi David, I've seen that several world daemons (rpcbind, telnetd, ...) are build with INET6. In real life, I do not know anyone who owns some IPv6 addresses but many guys who disabled INET6 on their machines in kernel. You don't know me? Not to speak that each IPv4 address owner automaticaly owns IPv6 space via 6to4 - see stf(4). It's already available for everyone - just enable and use it. Now the daemons prints out a (IMHO useless) warning, that they cannot bind to the INET6 socket on each start. Especially on workstation, which might to be started each day, this confuses the employee (each one once, but me as admin each time). No daemon explicitly binds to an inet6 socket unless configured to do so. Now the question: Would a patch be welcome which enables INET6 only if /etc/make.conf not contains 'NO_INET6=true'? I'm much more in favour of adding NO_INET, NO_INET4 support, which is what really is required some day. I find it very strange to setup new IPv4 only systems in these days. Don't lock out your future. -- B.Walter BWCThttp://www.bwct.de [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: Revised version (was Re: Serious 'tr' bug, patch for reviewincluded)
On Fri, Aug 01, 2003 at 06:37:03 +0400, Andrey Chernov wrote: On Fri, Aug 01, 2003 at 04:44:08 +0400, Andrey Chernov wrote: This patch address two problems. Revides patch version with accurate skipping. Surprisingly, the code is reduced. If you ever plan, don't try this patch, use variant recently commited into -current instead. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: INET6 in world
On Sun, 3 Aug 2003, Bernd Walter wrote:
On Sun, Aug 03, 2003 at 04:07:15PM +0200, Jens Rehsack wrote:
Hi David,
I've seen that several world daemons (rpcbind, telnetd, ...) are
build with INET6.
In real life, I do not know anyone who owns some IPv6 addresses
but many guys who disabled INET6 on their machines in kernel.
...
No daemon explicitly binds to an inet6 socket unless configured
to do so.
During bootup, I see this too:
Jul 13 18:09:42 console.info hummer kernel: Starting rpcbind.
Jul 13 18:09:42 console.info hummer kernel: Jul 13 18:09:42 daemon.err hummer
rpcbind: cannot create socket for udp6
Jul 13 18:09:42 console.info hummer kernel: Jul 13 18:09:42 daemon.err hummer
rpcbind: cannot create socket for tcp6
--
:{ [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]
Re: INET6 in world
On Mon, Aug 04, 2003 at 07:20:02AM +1000, Andy Farkas wrote: On Sun, 3 Aug 2003, Bernd Walter wrote: On Sun, Aug 03, 2003 at 04:07:15PM +0200, Jens Rehsack wrote: Hi David, I've seen that several world daemons (rpcbind, telnetd, ...) are build with INET6. In real life, I do not know anyone who owns some IPv6 addresses but many guys who disabled INET6 on their machines in kernel. ... No daemon explicitly binds to an inet6 socket unless configured to do so. During bootup, I see this too: Jul 13 18:09:42 console.info hummer kernel: Starting rpcbind. Jul 13 18:09:42 console.info hummer kernel: Jul 13 18:09:42 daemon.err hummer rpcbind: cannot create socket for udp6 Jul 13 18:09:42 console.info hummer kernel: Jul 13 18:09:42 daemon.err hummer rpcbind: cannot create socket for tcp6 Just guessing: what's in your /etc/hosts for localhost? -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ports/news/newscache gives sig11 on recent -CURRENT
The problem described in http://lists.freebsd.org/pipermail/freebsd-current/2003-August/007856.html is resolved. For details see: http://www.linuxhacker.org/cgi-bin/ezmlm-cgi?9:mss:56:gelgbcgckaailoplpncd http://www.linuxhacker.org/cgi-bin/ezmlm-cgi?9:mss:57:gelgbcgckaailoplpncd Herbert ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
NANO core dump on Current
Hi All, I don't know if I'm the only one with this problem, but here goes. I use Nano (/usr/ports/editors/nano) as my primary text editor, however Iv'e noticed that any time I use -CURRENT (on my notebook) it core dumps when saving a file. This only happens on -CURRENT of which I have tried several updates (cvsup, make world, make kernel, reboot cycle) without a change in this behaviour. I'm guessing that it's something to do with the C libraries installed under -CURRENT but I'm not sure how to go about finding the error. So far, it's the only thing that doesn't work under -CURRENT on my notebook, so keep up the good work. Regards Tim -- Tim Aslat [EMAIL PROTECTED] Spyderweb Consulting http://www.spyderweb.com.au P: 82243020M: 0401088479 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] jail NG schript patch for mounting devfs and procfsautomatically
On Sun, Aug 03, 2003 at 04:11:12PM +0200, Jens Rehsack wrote: the patch works for me very well. I've checked what's been done and had only small recommendations: - Wouldn't it be better to configure the devfs rules by /etc/devfs.conf or is it impossible? - Even it would be a good thing, if I could specify a ruleset for each jail, and fallback to devfs_ruleset_jail if no jail_example_devfs_ruleset is specified? Ok. Here's a retooled patch. It now includes a devfs rule specification format that we can even use in the general case (i.e. - for /dev). The default rules for a jail are included in it. It's in etc/defaults/devfs.rules and should be self-explanatory. I also put back Scott's code in rc.d/jail for handlind rulesets for individual jails. But I kept the default jail ruleset hard-coded. I don't see the poing of creating yet another knob for it. If a user doesn't want the default that's what the individual knobs for the jails are there for :) Let me know how it goes. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - Unleash the Daemon! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NANO core dump on Current
On Mon, Aug 04, 2003 at 08:28:49AM +0930, Tim Aslat wrote: Hi All, I don't know if I'm the only one with this problem, but here goes. I use Nano (/usr/ports/editors/nano) as my primary text editor, however Iv'e noticed that any time I use -CURRENT (on my notebook) it core dumps when saving a file. This only happens on -CURRENT of which I have tried several updates (cvsup, make world, make kernel, reboot cycle) without a change in this behaviour. I'm guessing that it's something to do with the C libraries installed under -CURRENT but I'm not sure how to go about finding the error. Compile the port with CFLAGS=-O -ggdb and obtain a gdb backtrace against the resulting nano binary. Kris pgp0.pgp Description: PGP signature
Re: INET6 in world
On 03.08.2003 23:39, Bernd Walter wrote: On Mon, Aug 04, 2003 at 07:20:02AM +1000, Andy Farkas wrote: On Sun, 3 Aug 2003, Bernd Walter wrote: On Sun, Aug 03, 2003 at 04:07:15PM +0200, Jens Rehsack wrote: Hi David, I've seen that several world daemons (rpcbind, telnetd, ...) are build with INET6. In real life, I do not know anyone who owns some IPv6 addresses but many guys who disabled INET6 on their machines in kernel. ... No daemon explicitly binds to an inet6 socket unless configured to do so. During bootup, I see this too: Jul 13 18:09:42 console.info hummer kernel: Starting rpcbind. Jul 13 18:09:42 console.info hummer kernel: Jul 13 18:09:42 daemon.err hummer rpcbind: cannot create socket for udp6 Jul 13 18:09:42 console.info hummer kernel: Jul 13 18:09:42 daemon.err hummer rpcbind: cannot create socket for tcp6 Just guessing: what's in your /etc/hosts for localhost? That's not the problem, because of # cat STATLER grep INET options INET#InterNETworking #optionsINET6 #IPv6 communications protocols :-) So no INET6 is available - /etc/hosts doesn't matter in that case Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nvidia-driver not loading GLX.
Another folloup: I've just re-cvsup today and built world an everythin appears ok so far uname -a: FreeBSD nova 5.1-CURRENT FreeBSD 5.1-CURRENT #4: Mon Aug 4 13:08:34 EST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NOVA i386 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Change in application of default ACLs in UFS
Just an FYI to users of ACLs on UFS -- I've modified the semantics of the application of the default ACL in combination with the umask. The result is that the application of default ACLs is now more conservative than previously, so you may want to keep an eye out and make sure all the ACLs still mean what you thought they meant. I'm still exploring what the best default ACL semantics to use are -- we're now implementing POSIX.1e as spec (bitwise and). It's worth observing this is not quite the same semantics as Solaris and Linux, in which the the ACL mask overrides the umask. I have an ACL development branch in Perforce where I'm experimenting with these semantics, and will probably merge support for that prior to 5.3, probably as an option. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories -- Forwarded message -- Date: Sun, 3 Aug 2003 20:29:13 -0700 (PDT) From: Robert Watson [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: cvs commit: src/sys/ufs/ufs acl.h ufs_acl.c ufs_vnops.c rwatson 2003/08/03 20:29:13 PDT FreeBSD src repository Modified files: sys/ufs/ufs acl.h ufs_acl.c ufs_vnops.c Log: Now that the central POSIX.1e ACL code implements functions to generate the inode mode from a default ACL and creation mask, implement ufs_sync_inode_from_acl() using acl_posix1e_newfilemode(). Since ACL_OVERRIDE_MASK/ACL_PRESERVE_MASK are defined, we no longer need to explicitly pass in a preserve_mask field: this is implicit in the use of POSIX.1e semantics. Note: this change contains a semantic bugfix for new file creation: we now intersect the ACL-generated mode and the cmode requested by the user process. This means permissions on newly created file objects will now be more conservative. In the future, we may want to provide alternative semantics (similar to Solaris and Linux) in which the ACL mask overrides the umask, permitting ACLs to broaden the rights beyond the requested umask. PR: 50148 Reported by:Ritz, Bruno [EMAIL PROTECTED] Obtained from: TrustedBSD Project Revision ChangesPath 1.5 +1 -2 src/sys/ufs/ufs/acl.h 1.18 +8 -78 src/sys/ufs/ufs/ufs_acl.c 1.232 +4 -8 src/sys/ufs/ufs/ufs_vnops.c ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on amd64/amd64
TB --- mkdir /home/des/tinderbox/CURRENT ___ [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 --- mkdir /home/des/tinderbox/CURRENT ___ [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 --- mkdir /home/des/tinderbox/CURRENT ___ [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 --- mkdir /home/des/tinderbox/CURRENT ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on sparc64/sparc64
TB --- mkdir /home/des/tinderbox/CURRENT ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on ia64/ia64
TB --- mkdir /home/des/tinderbox/CURRENT ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Lucent IBSS mode doesn't work in -CURRENT?
On Thursday, 31 July 2003 at 9:30:31 +0200, Eirik Oeverby wrote: Hey, I have a few Orinoco cards, and they 'work' in both ad-hoc and infrastructure mode. However with dhclient it gets tricky, because it will only work the first time dhclient assigns an address to the card. Whenever it tries to refresh it or whatever, I start getting those timeout and busy bit errors, and network connectivity drops. This usually happens within a few minutes or latest after 30 minutes or so - probably depending on your dhcpd/dhclient configuration. Configuring a static IP lets me use the card, and it seems stable. I am really glad someone else is seeing this, perhaps it can get fixed some day :) Oh and btw.. Get the *latest* firmware onto all your cards. That is essential for anything to work right at all.. That sounds wrong to me. If it worked before, and it doesn't now, that's not the fault of the firmware. Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Problems booting 5.1 RELEASE and CURRENT on Dell PowerEdge 600SC -workaround
Hi all, My company has recently purchased a Dell PowerEdge 600SC. I attempted to install both 5.1 RELEASE and a snapshot from 20030731 - both of which failed during booting. The error message was the same as described in the message CURRENT on Dell PE600SC panics on boot, from Josh Homan on 2003-04-08 19:36:33. Since the message is the same I won't duplicate it here. After a little bit of testing I managed to get the system to boot and install. The problem seems to be with the CD-ROM attached to the tertiary IDE channel (which is where Dell attach it by default). Shifting the CD-ROM onto the secondary channel allowed me to boot and install FreeBSD. Once installation was complete, I disconnected the CD-ROM altogether (I'm running 2 HDD's - one on each channel). Unfortunately my solution isn't a fix, it's merely a workaround - but at least it will help anyone else with the same system to install 5.x. Glen Gibb Ridley College ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
problem with nvidia graphics card and -current
I was setting up a system today with an nvidia Geforce4-MX 440 graphics card. I am not at the system at the moment but the -current sources were from about 2:00 PM CDT. I installed the nvidia-driver port (1.0.4365) trying various combinations of WITH_FREEBSD_AGP, FORCE_AGP_RATE, and WITH_NVIDIA_HACKS. I get the same result. The first time an X server is started, everything works fine, including glx loading. After exiting the X session and shutting down the server and then at some point later starting the X server again, the system will freeze. No messages, no panic, nothing. The only thing to do is hit the reset button. Any ideas? I saw some discussion about kernel changes made for wine and nvidia but I am not sure if that is relevant in my case. Thanks. -- Glenn Johnson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Lucent IBSS mode doesn't work in -CURRENT?
In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: : On Thursday, 31 July 2003 at 9:30:31 +0200, Eirik Oeverby wrote: : Hey, : : I have a few Orinoco cards, and they 'work' in both ad-hoc and : infrastructure mode. However with dhclient it gets tricky, because it : will only work the first time dhclient assigns an address to the card. : Whenever it tries to refresh it or whatever, I start getting those : timeout and busy bit errors, and network connectivity drops. This : usually happens within a few minutes or latest after 30 minutes or so - : probably depending on your dhcpd/dhclient configuration. Configuring a : static IP lets me use the card, and it seems stable. : : I am really glad someone else is seeing this, perhaps it can get fixed : some day :) : : Oh and btw.. Get the *latest* firmware onto all your cards. That is : essential for anything to work right at all.. : : That sounds wrong to me. If it worked before, and it doesn't now, : that's not the fault of the firmware. Quit harping on it, ok. We know there's a bug and carping like this makes me less willing to find and fix it. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
