ifconfig -a blows up if /etc/mac.conf isn't installed
I've figured out that after some recent posix1e upgrades (mac stuff?), ifconfig -a will blow up if mac.conf isn't there: # mv /etc/mac.conf /etc/mac.conf.backup # ifconfig -a fxp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 10.0.0.6 netmask 0xff00 broadcast 10.0.0.255 ether 00:30:48:21:bb:74 media: Ethernet autoselect (100baseTX full-duplex) status: active Memory fault (core dumped) # mv /etc/mac.conf.backup /etc/mac.conf # ifconfig -a fxp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 10.0.0.6 netmask 0xff00 broadcast 10.0.0.255 ether 00:30:48:21:bb:74 media: Ethernet autoselect (100baseTX full-duplex) status: active ti0: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500 options=1bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING ether 00:02:e3:00:34:10 media: Ethernet autoselect status: no carrier lp0: flags=8810POINTOPOINT,SIMPLEX,MULTICAST mtu 1500 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 inet 127.0.0.1 netmask 0xff00 Ken -- Kenneth Merry [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Thinkpad R40 and ACPI problems on current
Please submit a PR and send me the PR number. Include full dmesg and a URL to the two files produced by: acpidump -t -d -o my.dsdt my.asl -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvsup failing with ASSERT failed
On Wednesday, August 27, 2003, at 12:48 PM, Peter Wemm wrote: Oh, that *is* interesting. I get this 100% of the time when trying to run the i386 binary on my amd64 boxes. Hmm. Maybe I dont have an emulation bug then? [EMAIL PROTECTED]:46am]~-99 ./cvsup -gL2 cvs-supfile Parsing supfile cvs-supfile Connecting to malaise Wow, now I don't get my /compat dir populated during my installworld/installkernel on my amd64 machines. How do I go about installing those bits so that I can run i386 binary's ? -DR ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvsup failing with ASSERT failed
On Fri, 29 Aug 2003, David Rhodus wrote: On Wednesday, August 27, 2003, at 12:48 PM, Peter Wemm wrote: Oh, that *is* interesting. I get this 100% of the time when trying to run the i386 binary on my amd64 boxes. Hmm. Maybe I dont have an emulation bug then? [EMAIL PROTECTED]:46am]~-99 ./cvsup -gL2 cvs-supfile Parsing supfile cvs-supfile Connecting to malaise Wow, now I don't get my /compat dir populated during my installworld/installkernel on my amd64 machines. How do I go about installing those bits so that I can run i386 binary's ? One way of installing all of the stuff that should be in /compat would be to run /stand/sysinstall, Post-Install Config then install the appropriate distributions. Make sure that you *only* select the distributions that you want to install (don't overwrite [s]bin and everything if you've upgraded to HEAD). Regards, Andre Guibert de Bruet | Enterprise Software Consultant Silicon Landmark, LLC. | http://siliconlandmark.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sysinstall spec_getpages panic (with VM overtones)
On Sun, 24 Aug 2003, Robert Watson wrote: Alan Cox just made a commit a couple of days ago that seems to resolve the problem for us. Here's the commit message so you can give it a try. [...] 1.208 +5 -2 src/sys/fs/specfs/spec_vnops.c I can confirm this fixes things for me too. Thanks all for the help, and sorry for the false alarm after the commit. Gavin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sysinstall spec_getpages panic (with VM overtones)
On Sat, 30 Aug 2003, Gavin Atkinson wrote: On Sun, 24 Aug 2003, Robert Watson wrote: Alan Cox just made a commit a couple of days ago that seems to resolve the problem for us. Here's the commit message so you can give it a try. [...] 1.208 +5 -2 src/sys/fs/specfs/spec_vnops.c I can confirm this fixes things for me too. Thanks all for the help, and sorry for the false alarm after the commit. Great, thanks for letting us know. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ifconfig -a blows up if /etc/mac.conf isn't installed
On Fri, 29 Aug 2003, Kenneth D. Merry wrote: I've figured out that after some recent posix1e upgrades (mac stuff?), ifconfig -a will blow up if mac.conf isn't there: # mv /etc/mac.conf /etc/mac.conf.backup # ifconfig -a fxp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 10.0.0.6 netmask 0xff00 broadcast 10.0.0.255 ether 00:30:48:21:bb:74 media: Ethernet autoselect (100baseTX full-duplex) status: active Memory fault (core dumped) Same here. I took a look, and found that line 62 of /usr/src/sbin/ifconfig/ifmac.c returns ENOENT, but the docs say this should return a -1. So this code looks correct. from ifmac.c: if (mac_prepare_ifnet_label(label) == -1) I think the correct fix is in /usr/src/lib/libc/posix1e/mac.c Try this patch, rebuild libc, then rebuild ifconfig. --- lib/libc/posix1e/mac.c.orig Fri Aug 29 22:42:44 2003 +++ lib/libc/posix1e/mac.c Fri Aug 29 22:43:19 2003 @@ -365,7 +365,7 @@ return (mac_prepare(mac, ld-ld_labels)); } - return (ENOENT);/* XXXMAC: ENOLABEL */ + return (-1);/* XXXMAC: ENOLABEL */ } int ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
aac related panics
Hi all, I've got a Dell Poweredge 2650 which I recently installed 5.1-R on. That worked fine, and so I did a cvsup to get to 5.1-C as of about noon today. When I rebooted with the new kernel my system paniced before even finishing the kernel boot with the following: command 0xca6df000 not in queue, flags = 0x20, bit = 0x80 panic: command not in queue cpuid = 0; 1apic.id = then it tried to shutdown the aac0 controller which failed. I've attached my kernel config below. I've also tried it with a non-SMP kernel and had the same results. I haven't tried using DISABLE_PSE or DISBALE_PG_G, but I will do so in a bit and report back if my condition improves. My company is working on a new hosting infrastructure, and I'd like to use FreeBSD if possible, so any help at all would be greatly appreciated as we plan to use these machines for some time. -wd -- chip norkus; renaissance hacker;[EMAIL PROTECTED] question = (to) ? be : !be; --Shakespeare http://telekinesis.org/ # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # #http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.387 2003/08/24 09:30:13 sos Exp $ machine i386 cpu I686_CPU ident dell2650 makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols makeoptions MODULES_OVERRIDE=acpi linux options SCHED_4BSD #4BSD scheduler options INET#InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support options UFS_ACL #Support for access control lists options UFS_DIRHASH #Improve performance on big directories options NFSCLIENT #Network Filesystem Client options NFSSERVER #Network Filesystem Server options NFS_ROOT#NFS usable as /, requires NFSCLIENT options CD9660 #ISO 9660 Filesystem #optionsPROCFS #Process filesystem (requires PSEUDOFS) #optionsPSEUDOFS#Pseudo-filesystem framework options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 #Compatible with FreeBSD4 options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions options KBD_INSTALL_CDEV# install a CDEV entry in /dev # Debugging for use in -current options DDB #Enable the kernel debugger options DDB_UNATTENDED # To make an SMP kernel, the next two are needed options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O device isa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atapicd # ATAPI CDROM drives options ATA_STATIC_ID #Static device numbering # RAID controllers interfaced to the SCSI subsystem device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID device ciss# Compaq Smart RAID 5* device dpt # DPT Smartcache III, IV - See NOTES for options! device iir # Intel Integrated RAID device mly # Mylex AcceleRAID/eXtremeRAID # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass# Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers device aac #
Re: 2 ports broken after gcc import
Bizarre. I use ACLs in my kernel daily, and I use nmap almost daily, and haven't seen this. If you re-add ACLs with a fresh kernel build, does the problem come back? Could you look at ktraces of nmap with and without ACLs and see what causes it? Do you have ACLs enabled on any file systems, or are you just running with the kernel option? I was running with just the kernel option, and nothing configured for it. I can't think of what else the problem could be, when I recompiled the kernel it just started working again, it might not have anything at all to do with ACL's and more to do with the fact that I just recompiled it. One of my other -CURRENT machines is working now as well after a recompile. I'll do more testing to see if I can pinpoint the problem and I'll probably have results by Tuesday (holiday weekend :-P ) Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 2 ports broken after gcc import
Might devfs propagate ACL characteristics via /dev nodes into applications? Otherwise, the symptom you described would have made me point to the IP firewall first. My machine that was showing the problem didn't have a firewall enabled. I'll still mess with it some more to see what I can come up with, maybe it was the firewall, but I don't remember having ipfilter or ipfirewall in the kernel but it'd been a while since I edited that config file or compiled that kernel so maybe I took out the firewall options and never compiled, and then compiled today. (It's been about a month since I did anything kernel related on that machine). Anyway, when I pinpoint the problem I'll mail the list. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! ATAng committed
On Fri, Aug 29, 2003 at 06:41:17PM +0200, Thomas Quinot wrote: Le 2003-08-29, Glenn Johnson écrivait : When I have atapicam enabled in my kernel config (-current, as of Aug 28, 2003; 11:00 PM CDT), my system locks up when trying to load nautilus. Nautilus loads fine after removing the atapicam option. Atapicam worked fine prior to ATAng. Strange. No messages on the system console? Well, I did a fresh cvsup, re-enabled the atapicam bits in my kernel config, rebuilt/reinstalled world and kernel. I rebooted and started a Gnome session and starting nautilus did *not* cause the system to hang. The problem just went away. I did see that there were some commits to some ATA files so maybe that was it. 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]
need some debugging help
I've been working on a set of patches to remove the sysctl variable creation from interrupt context in the cd(4) and da(4) drivers. To fix the problem, I've created a new taskqueue that runs in a thread context, instead of inside a software interrupt like the current task queues. (The eventual fix will involve moving the CAM probe inside a thread; this will provide a more temporary solution that will hopefully also work on -stable, until we can change the CAM probe code.) I think I have everything setup correctly, but I keep getting panics inside the GEOM code with these patches. (Memory modified after free.) I don't know whether I've just exposed some race condition, or whether I've done something wrong. I've seen several different panics, all with the same root cause (memory modified after free), and with two different previous memory pools -- geom and devbuf. == SMP: AP CPU #1 Launched! Memory modified after free 0xcbd4f800(124) panic: Most recently used by GEOM cpuid = 0; lapic.id = Debugger(panic) Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0 db trace Debugger(c03e974d,0,c03fb4d8,e5e45934,100) at Debugger+0x55 panic(c03fb4d8,c03e55db,7c,c083ac14,c083ac00) at panic+0x15f mtrash_ctor(cbd4f800,80,0,57a,cbd4f800) at mtrash_ctor+0x5d uma_zalloc_arg(c083ac00,0,102,e5e4599c,e5e4599c) at uma_zalloc_arg+0x1e4 malloc(5b,c042fae0,102,1,c02756e4) at malloc+0xd3 g_new_providerf(cbda62c0,cbd7b130,e5e45a3c,1,1) at g_new_providerf+0xa3 g_slice_config(cbda62c0,2,1,0,0) at g_slice_config+0x259 g_bsd_modify(cbda62c0,cbd7712c,e5e45c8c,10,cbd77000) at g_bsd_modify+0x382 g_bsd_taste(c0470480,cbda5780,0,159,cbda5700) at g_bsd_taste+0x2c4 g_new_provider_event(cbda5780,0,c03e52b7,b3,6667) at g_new_provider_event+0xad one_event(e5e45d0c,c021cd85,c0485fb4,0,4c) at one_event+0x218 g_run_events(c0485fb4,0,4c,c03d7a28,a) at g_run_events+0x15 g_event_procbody(0,e5e45d48,c03e738b,314,34df1a6d) at g_event_procbody+0x45 fork_exit(c021cd40,0,e5e45d48) at fork_exit+0xcf fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe5e45d7c, ebp = 0 --- db panic == SMP: AP CPU #1 Launched! Memory modified after free 0xcbd4f600(124) panic: Most recently used by devbuf cpuid = 0; lapic.id = Debugger(panic) Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0 db trace Debugger(c03e974d,0,c03fb4d8,e5e45af0,100) at Debugger+0x55 panic(c03fb4d8,c03e7f50,7c,c083ac14,c083ac00) at panic+0x15f mtrash_ctor(cbd4f600,80,0,57a,cbd4f600) at mtrash_ctor+0x5d uma_zalloc_arg(c083ac00,0,102,e5e45b58,e5e45b58) at uma_zalloc_arg+0x1e4 malloc(5a,c042fae0,102,1,c02756e4) at malloc+0xd3 g_new_providerf(cbda74c0,cb9b0d90,e5e45bf8,1,1) at g_new_providerf+0xa3 g_slice_config(cbda74c0,0,1,7e00,0) at g_slice_config+0x259 g_mbr_modify(cbda74c0,cb9d3800,cbd5b200,123,0) at g_mbr_modify+0x247 g_mbr_taste(c0470560,cbd4ee80,0,159,cbd4f580) at g_mbr_taste+0x1be g_new_provider_event(cbd4ee80,0,c03e52b7,b3,6667) at g_new_provider_event+0xad one_event(e5e45d0c,c021cd85,c0485fb4,0,4c) at one_event+0x218 g_run_events(c0485fb4,0,4c,c03d7a28,a) at g_run_events+0x15 g_event_procbody(0,e5e45d48,c03e738b,314,34df1a6d) at g_event_procbody+0x45 fork_exit(c021cd40,0,e5e45d48) at fork_exit+0xcf fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe5e45d7c, ebp = 0 --- db panic == Memory modified after free 0xcbd4f600(124) panic: Most recently used by devbuf cpuid = 0; lapic.id = Debugger(panic) Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0 db trace Debugger(c03e974d,0,c03fb4d8,e5e45bbc,100) at Debugger+0x55 panic(c03fb4d8,c03e7f50,7c,c083ac14,c083ac00) at panic+0x15f mtrash_ctor(cbd4f600,80,0,57a,cbd4f600) at mtrash_ctor+0x5d uma_zalloc_arg(c083ac00,0,102,fe,cbd6b800) at uma_zalloc_arg+0x1e4 malloc(60,c042fae0,102,cbd59240,c0470560) at malloc+0xd3 g_slice_alloc(4,214,cbd4f4d4,1c2,e5e45c9c) at g_slice_alloc+0x7e g_slice_new(c0470560,4,cbd4f480,e5e45c98,e5e45c9c) at g_slice_new+0x6f g_mbr_taste(c0470560,cbd4f480,0,159,cbd4f580) at g_mbr_taste+0x90 g_new_provider_event(cbd4f480,0,c03e52b7,b3,6667) at g_new_provider_event+0xad one_event(e5e45d0c,c021cd85,c0485fb4,0,4c) at one_event+0x218 g_run_events(c0485fb4,0,4c,c03d7a28,a) at g_run_events+0x15 g_event_procbody(0,e5e45d48,c03e738b,314,34df1a6d) at g_event_procbody+0x45 fork_exit(c021cd40,0,e5e45d48) at fork_exit+0xcf fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe5e45d7c, ebp = 0 --- db == SMP: AP CPU #1 Launched! Memory modified after free 0xcbd4f600(124) panic: Most recently used by devbuf cpuid = 0; lapic.id = Debugger(panic) Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0 db trace
Re: aac related panics
Hi, You're not the first to report this. Please try reverting /sys/dev/aac/aac.c to rev 1.73 and let me know if it helps. Scott Chip Norkus wrote: Hi all, I've got a Dell Poweredge 2650 which I recently installed 5.1-R on. That worked fine, and so I did a cvsup to get to 5.1-C as of about noon today. When I rebooted with the new kernel my system paniced before even finishing the kernel boot with the following: command 0xca6df000 not in queue, flags = 0x20, bit = 0x80 panic: command not in queue cpuid = 0; 1apic.id = then it tried to shutdown the aac0 controller which failed. I've attached my kernel config below. I've also tried it with a non-SMP kernel and had the same results. I haven't tried using DISABLE_PSE or DISBALE_PG_G, but I will do so in a bit and report back if my condition improves. My company is working on a new hosting infrastructure, and I'd like to use FreeBSD if possible, so any help at all would be greatly appreciated as we plan to use these machines for some time. -wd # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # #http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.387 2003/08/24 09:30:13 sos Exp $ machine i386 cpu I686_CPU ident dell2650 makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols makeoptions MODULES_OVERRIDE=acpi linux options SCHED_4BSD #4BSD scheduler options INET#InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support options UFS_ACL #Support for access control lists options UFS_DIRHASH #Improve performance on big directories options NFSCLIENT #Network Filesystem Client options NFSSERVER #Network Filesystem Server options NFS_ROOT#NFS usable as /, requires NFSCLIENT options CD9660 #ISO 9660 Filesystem #optionsPROCFS #Process filesystem (requires PSEUDOFS) #optionsPSEUDOFS#Pseudo-filesystem framework options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 #Compatible with FreeBSD4 options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions options KBD_INSTALL_CDEV# install a CDEV entry in /dev # Debugging for use in -current options DDB #Enable the kernel debugger options DDB_UNATTENDED # To make an SMP kernel, the next two are needed options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O device isa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atapicd # ATAPI CDROM drives options ATA_STATIC_ID #Static device numbering # RAID controllers interfaced to the SCSI subsystem device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID device ciss# Compaq Smart RAID 5* device dpt # DPT Smartcache III, IV - See NOTES for options! device iir # Intel Integrated RAID device mly # Mylex AcceleRAID/eXtremeRAID # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass# Passthrough device (direct SCSI access) device ses # SCSI Environmental
Re: HEADS UP! ATAng committed
On Fri, Aug 29, 2003 at 11:02:13PM -0500, wrote: On Fri, Aug 29, 2003 at 06:41:17PM +0200, Thomas Quinot wrote: Le 2003-08-29, Glenn Johnson écrivait : When I have atapicam enabled in my kernel config (-current, as of Aug 28, 2003; 11:00 PM CDT), my system locks up when trying to load nautilus. Nautilus loads fine after removing the atapicam option. Atapicam worked fine prior to ATAng. Strange. No messages on the system console? Well, I did a fresh cvsup, re-enabled the atapicam bits in my kernel config, rebuilt/reinstalled world and kernel. I rebooted and started a Gnome session and starting nautilus did *not* cause the system to hang. The problem just went away. I did see that there were some commits to some ATA files so maybe that was it. I guess I wrote that too soon, it just locked up again. This time though, the machine rebooted after about 10 seconds so I could not get to another machine to see if I could poke around. -- Glenn Johnson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
libthr: Blocked signal nesting level must be 1!
Hi I received the following message while running mplayer: Blocked signal nesting level must be 1! Abnormal termination, file: /mnt/cvs/FreeBSD/usr/src/libthr/thread/thr_kern.c, line: 88 I am running with SCHED_ULE, and have mapped libc_r to libthr in libmap.conf. The program runs fine when libc_r is not mapped to libthr. Note, kernel and world cvsup'ed and built about 24 hours ago. -- Regards Peter As always the organisation disavows knowledge of this email ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! ATAng committed
On Fri, Aug 29, 2003 at 11:56:57PM -0500, Glenn Johnson wrote: On Fri, Aug 29, 2003 at 11:02:13PM -0500, wrote: On Fri, Aug 29, 2003 at 06:41:17PM +0200, Thomas Quinot wrote: Le 2003-08-29, Glenn Johnson écrivait : When I have atapicam enabled in my kernel config (-current, as of Aug 28, 2003; 11:00 PM CDT), my system locks up when trying to load nautilus. Nautilus loads fine after removing the atapicam option. Atapicam worked fine prior to ATAng. Strange. No messages on the system console? Well, I did a fresh cvsup, re-enabled the atapicam bits in my kernel config, rebuilt/reinstalled world and kernel. I rebooted and started a Gnome session and starting nautilus did *not* cause the system to hang. The problem just went away. I did see that there were some commits to some ATA files so maybe that was it. I guess I wrote that too soon, it just locked up again. This time though, the machine rebooted after about 10 seconds so I could not get to another machine to see if I could poke around. Another data point: If I start a non-gnome session, and then launch nautilus, it does not crash the system. However, when I start a gnome session, the machine crashes when nautilus loads. If I take atapicam out of my kernel config, rebuild/reinstall the kernel, I do not get any crashes at all. Why it worked a couple of times earlier this evening I do not know. -- 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: aac related panics
On Friday 29 August 2003 11:37 pm, Scott Long wrote: Hi, You're not the first to report this. Please try reverting /sys/dev/aac/aac.c to rev 1.73 and let me know if it helps. It did help. I can now complete a 'make -j 4 world' (in 24 minutes no less :)). Thanks a lot for the help! Is there any ETA on when this will be re-examined and hopefully fixed in -CURRENT? Scott -wd -- chip norkus; renaissance hacker;[EMAIL PROTECTED] question = (to) ? be : !be; --Shakespeare http://telekinesis.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 2 ports broken after gcc import
On Fri, Aug 29, 2003 at 02:31:56PM -0400, Kenneth Culver wrote: Did the same thing, portupgrade -f nmap, and then ran it with the same flags, and I'm still getting the same problem. It's doing this on all 3 of my FreeBSD-CURRENT machines as well. Ken Are you running a packet filter of some sort? Jiawei -- Without the userland, the kernel is useless. --inspired by The Tao of Programming ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: need some debugging help
In message [EMAIL PROTECTED], Kenneth D. Merry writes: I think I have everything setup correctly, but I keep getting panics inside the GEOM code with these patches. (Memory modified after free.) I don't know whether I've just exposed some race condition, or whether I've done something wrong. Do you have any idea what goes on at/right before the panic ? Ie: has drives been created [disk_create()] or removed [disk_destroy()] right before ? My best shot, would be that disk_destroy() was called and something somehow fiddled the related structures subsequently. You may want to set kern.geom.debugflags=N and see if that offers any clues. N |= 1 topology events N |= 2 bio processing (ie: many lines for each I/O) N |= 4 access processing (open/close) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
pam_mkhomedir
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi ! I just set up a test server running FreeBSD-5.1 with pam_ldap and nss_ldap for authentication. It works really nice so far. I have a little question though: I wanted the user homedir to be created the first time a user logs in if it does not exist. I know I need pam_mkhomedir for this but I can't find it under 5.1. If I remember, pam_mkhomedir was in the contrib section under 4.x. Any idea why it is not part of FreeBSD anymore ? Or do you know any other way of auto-creating users homedir ? Thanks in advance, Regards. - -- Antoine Jacoutot [EMAIL PROTECTED] http://www.lphp.org PGP/GnuPG key: http://www.lphp.org/ressources/ajacoutot.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/UFuqY3Hnhkr+5cQRAoLpAJ9xFUoYKx6nre442AvA19+2kP8lyQCbBUIw q4sqpdjgOVwxUnhEqUkKdSY= =0zQy -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: snd_csa issues in -CURRENT
On Fri, 29 Aug 2003 12:36:56 +0200 Eirik Oeverby [EMAIL PROTECTED] wrote: I might also point out that there are two distinct kinds of distortion happening: The click/pop/crackle kind of distortion, and one where a sound buffer is repeated over and over 5-10 times - as if the hardware has some kind of hickup. Again - this *only* happens in -CURRENT, not in -STABLE or in any other OS (tested OS/2, BeOS, Linux, winXX). Anyone? :) /Eirik I get the same pops/crackling but using a SB Live! I think it started happening when I switched from 4.x to 5.x The strange thing is that sound works fine after a reboot but some hours after that I get the noises. It only happens with music (mp3,ogg). $ uname -a FreeBSD platypus.freebsd.home 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Sun Aug 24 21:53:30 EST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PLATY4 i386 dmesg attached dmesg Description: Binary data ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: buildworld failure
On Fri, 29 Aug 2003, Sheldon Hearn wrote: Okay, you philosophize while the rest of us follow the advice of the folks who have a good understanding of gcc's optimizer. :-) Not to be disagreeable, but the gcc developers seem to think that -O2 should always produce better code, and never produce errors. This is straight from the mouth of the husband of one of my co-workers, who works for redhat hacking gcc. If you have a reproducable case where correct C code produces bad objects, or fails to compile using -O2, the gcc folks want to hear about it. Doug -- This .signature sanitized for your protection ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/gnu/usr.bin Makefile src/lib Makefile src/sbinMakefile src/usr.bin Makefile src/usr.sbin Makefile
Poul-Henning, Please don't forget to update src/share/examples/etc/make.conf accordingly. All, As a sometime-contributor to the let's give people more options to leave stuff out cause, I fully support adding more knobs like this. There is no harm to adding more knobs that work the same way as the existing ones do, with or without a grand plan. If we decide to embark on something more complex, I'd like to see more discussion though. Doug On Fri, 29 Aug 2003, Poul-Henning Kamp wrote: phk 2003/08/29 03:35:01 PDT FreeBSD src repository Modified files: gnu/usr.bin Makefile lib Makefile sbin Makefile usr.bin Makefile usr.sbin Makefile Log: Introduce more knobs to slim down FreeBSD userland NO_TOOLCHAINskips Compilers and Binutils NO_USB skips USB stuff NO_VINUMskips Vinum stuff NO_ACPI skips ACPI stuff Revision ChangesPath 1.76 +6 -1 src/gnu/usr.bin/Makefile 1.171 +5 -1 src/lib/Makefile 1.127 +5 -2 src/sbin/Makefile 1.246 +17 -6 src/usr.bin/Makefile 1.270 +11 -4 src/usr.sbin/Makefile http://www.FreeBSD.org/cgi/cvsweb.cgi/src/gnu/usr.bin/Makefile.diff?r1=1.75r2=1.76f=h http://www.FreeBSD.org/cgi/cvsweb.cgi/src/lib/Makefile.diff?r1=1.170r2=1.171f=h http://www.FreeBSD.org/cgi/cvsweb.cgi/src/sbin/Makefile.diff?r1=1.126r2=1.127f=h http://www.FreeBSD.org/cgi/cvsweb.cgi/src/usr.bin/Makefile.diff?r1=1.245r2=1.246f=h http://www.FreeBSD.org/cgi/cvsweb.cgi/src/usr.sbin/Makefile.diff?r1=1.269r2=1.270f=h -- This .signature sanitized for your protection ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/gnu/usr.bin Makefile src/lib Makefile src/sbinMakefile src/usr.bin Makefile src/usr.sbin Makefile
In message [EMAIL PROTECTED], Doug Barton writes: Poul-Henning, Please don't forget to update src/share/examples/etc/make.conf accordingly. Hmm, so this stuff is documented both in make.conf(5) and an examples file ? Sounds like one place too many to me. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/gnu/usr.bin Makefile src/lib Makefile src/sbinMakefile src/usr.bin Makefile src/usr.sbin Makefile
On Saturday 30 August 2003 12:03, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Doug Barton writes: Poul-Henning, Please don't forget to update src/share/examples/etc/make.conf accordingly. Hmm, so this stuff is documented both in make.conf(5) and an examples file ? Sounds like one place too many to me. That may be true, but I find the example file to be extremely helpful when setting up a new system. I just have to remove a few comments to enable the 'make update' target or leave out parts of world that I don't want. So I guess they both have a purpose. Arjan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Fresh CVSUP, new ATAng problems and nvidia.ko compile issues
Hi, I have just cvsup'd this morning and built/installed a new world and kernel: FreeBSD neo.xtaz.co.uk 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Sat Aug 30 11:13:06 BST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NEO i386 I now have a new issue with ATAng that I didn't have last week when I tried ATAng. My CDRW is now not detected during probing. I get this message: Aug 30 11:21:00 neo kernel: ad0: 76319MB ST380020A [155061/16/63] at ata0-master UDMA100 Aug 30 11:21:00 neo kernel: ata1-slave: FAILURE - ATA_IDENTIFY status=41READY,ERROR error=4ABORTED Aug 30 11:21:00 neo kernel: acd0: DVDROM Compaq DVD-ROM SD-616T at ata1-master PIO4 From a kernel of august the 25th I get this: Aug 25 09:53:42 neo kernel: ad0: 76319MB ST380020A [155061/16/63] at ata0-master UDMA100 Aug 25 09:53:42 neo kernel: acd0: DVDROM Compaq DVD-ROM SD-616T at ata1-master PIO4 Aug 25 09:53:42 neo kernel: acd1: CDRW SAMSUNG CD-R/RW SW-240B at ata1-slave PIO4 I have tried a kernel with both atapicam commented out and also with it enabled and get the same result. The other problem I now have is on august the 25th I compiled x11/nvidia-driver with no issues and it's worked fine all this week. Trying to compile it today I get this: /tmp/usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_sysctl.c: In function `nvidia_find_bridge': /tmp/usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_sysctl.c:234: error: `PCIR_HEADERTYPE' undeclared (first use in this function) /tmp/usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_sysctl.c:234: error: (Each undeclared identifier is reported only once /tmp/usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_sysctl.c:234: error: for each function it appears in.) *** Error code 1 Stop in /tmp/usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-1.0-4365/module. *** Error code 1 Stop in /tmp/usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-1.0-4365. *** Error code 1 Stop in /usr/ports/x11/nvidia-driver. The port has not been updated since august the 20th and I succesfully compiled this on the 25th so I assume something has changed in the world this week that has broken this. Any ideas about both issues? Matt. -- email: [EMAIL PROTECTED] - web: http://xtaz.co.uk/ Hardware, n.: The parts of a computer system that can be kicked. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/gnu/usr.bin Makefile src/lib Makefile src/sbinMakefile src/usr.bin Makefile src/usr.sbin Makefile
On Sat, 30 Aug 2003, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Doug Barton writes: Poul-Henning, Please don't forget to update src/share/examples/etc/make.conf accordingly. Hmm, so this stuff is documented both in make.conf(5) and an examples file ? Sounds like one place too many to me. Well, there's always been an example make.conf file. In previous incarnations it's lived in /etc, then /etc/defaults. I also agree with the previous poster that it's useful to have such an example, and mergemaster uses it for the -p option. Doug -- This .signature sanitized for your protection ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IDE DVD playback on 5.1-CURRENT
On Fri, 29 Aug 2003, David O'Brien wrote: On Fri, Aug 29, 2003 at 10:10:46AM -0700, Terry Lambert wrote: David O'Brien wrote: On Thu, Aug 28, 2003 at 01:29:22AM -0700, Terry Lambert wrote: 1)dd if=/dev/acd0 count=1 of=/dev/null 2)dd if=/dev/acd0c count=1 of=/dev/null 3)dd if=/dev/acd0a count=1 of=/dev/null bs=2k Yes, sorry; I forgot that FreeBSD's dd does not stat its endpoints to see if they are devices, and gets the st_blksize and insists that it be used (at least internally) for S_IFBLK and S_IFCHR values of st_mode. Perhaps it should be unbroken by someone with a commit bit and/or the ability to have their send-pr's not rejected as relay SPAM. I doubt it, this wasn't necessary with SCSI cdrom's until GEOM -- PHK thought it a feature to have to require the user to remember the bs=2k, so I don't think anyone will ever be able to get this fixed in the tree. This is not only a feaure; it is Standard. From POSIX.1-2001-draft7.txt: %%% 11599 NAME 11600 dd - convert and copy a file ... 11650ibs=exprSpecify the input block size, in bytes, by expr (default is 512). 11651obs=exprSpecify the output block size, in bytes, by expr (default is 512). %%% GEOM has many faults, but this is not one of them. dd if=/dev/[a]cd0c [bs=512] hasn't worked since block devices were axed. With block devices, you had to use the raw device, e.g., /dev/racd0c, to attempt to read 512-blocks and fail on normal cdroms because their block size isn't 512. /dev/acd0c was the block device so it could be read with any size at some cost in efficiency.. E.g., requests to read it with a block size of 512 caused the following enblocking and deblocking: - dd block size of 512 converted to BLKDEV_IOSIZE = 2048 - i/o done with block size of 2048. This happens to be the same as the physical block size, so it happens to work and doesn't involve any more enblocking or deblocking - BLKDEV_IOSIZE converted to dd block size. BLKDEV_IOSIZE is now PAGE_SIZE and is only used for bogus things (since it is still used but there are no block devices to use it on). Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
vmware-guestd on vmware hosted Windows
Sorry, this is repot only. I'm upgrading from 2003/08/19 current to 2003/08/30 current on vmware 3.x(host OS is Windows), and I tried to run vmware-guestd, # ./vmware-guestd ELF binary type 0 not known. /usr/local/sbin/vmware-guestd: Exec format error. Wrong Architecture I suggested on IRC, try # brandelf -t FreeBSD ./vmware-guestd I tried this and succeceed to run vmware-guestd. Before brandelf -t, brandelf result is, % brandelf vmware-guestd File 'vmware-guestd' is of brand 'SVR4' (0). and after brandelf -t is, % brandelf vmware-guestd File 'vmware-guestd' is of brand 'FreeBSD' (9). Any comments? -- [EMAIL PROTECTED]/[EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
/lib symlinks problem? (was: Re: __fpclassifyd)
On Fri, 29 Aug 2003 09:19:07 -0700 Steve Kargl [EMAIL PROTECTED] wrote: Are you linking in libc? troutmask:kargl[207] nm -D /usr/lib/libc.so | grep fpcl 000b0040 T __fpclassifyd 000afff0 T __fpclassifyf 000b00a0 T __fpclassifyl I think the problem is, that some tools have a problem finding it...: ---snip--- (3) [EMAIL PROTECTED] % nm -D /usr/lib/libc.so | grep fpcl nm: /usr/lib/libc.so: No such file or directory (4) [EMAIL PROTECTED] % ll /usr/lib/libc.so lrwxr-xr-x 1 root wheel 19B 29 Aug 13:57 /usr/lib/libc.so@ - ../../lib/libc.so.5 (5) [EMAIL PROTECTED] % ll /usr lrwxr-xr-x 1 root wheel 7.0B 18 Aug 2001 /usr@ - big/usr (7) [EMAIL PROTECTED] % ll /lib/libc.so lrwxr-xr-x 1 root wheel 9.0B 29 Aug 13:57 /lib/libc.so@ - libc.so.5 ---snip--- I think a workaround would be to use absolute symlinks (at least as an option). David O'Brien wrote: Yes, your libs + binaries are out of sync with each other. You may also have stale .so symlinks in /usr/lib. One gets this if one runs a certain 4.x binary on 5.1. This was an update of an -current since ever system from Aug 2 src to Aug 28 src. I just tried to recompile cdrdao. Bye, Alexander. -- If Bill Gates had a dime for every time a Windows box crashed... ...Oh, wait a minute, he already does. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pam_mkhomedir
On Sat, Aug 30, 2003 at 10:09:14AM +0200, Antoine Jacoutot wrote: If I remember, pam_mkhomedir was in the contrib section under 4.x. Any idea why it is not part of FreeBSD anymore ? Or do you know any other way of auto-creating users homedir ? My virtual hosting setup does this through ProFTPD and doesn't use PAM. The problem with this is that you need to be running as root, or as a user or group which can create under /home, or have the sticky bit on /home. I see the source under RELENG_4 as: /src/contrib/libpam/modules/pam_mkhomedir I can't think of any major reasons why you couldn't just continue using this if it worked for you before. It would probably work from login. sshd might require you to enable UseLogin yes in sshd_config. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Build broken in sys/dev/pcic/i82365.c
With latest sources: cc -c -O -fno-ident -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/local/src/sys -I/usr/local/src/sys/contrib/dev/acpica -I/usr/local/src/sys/contrib/ipfilter -I/usr/local/src/sys/contrib/dev/ath -I/usr/local/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/local/src/sys/net/if.c cc -c -O -fno-ident -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/local/src/sys -I/usr/local/src/sys/contrib/dev/acpica -I/usr/local/src/sys/contrib/ipfilter -I/usr/local/src/sys/contrib/dev/ath -I/usr/local/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/local/src/sys/net/netisr.c cc -c -O -fno-ident -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/local/src/sys -I/usr/local/src/sys/contrib/dev/acpica -I/usr/local/src/sys/contrib/ipfilter -I/usr/local/src/sys/contrib/dev/ath -I/usr/local/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/local/src/sys/dev/fb/fb.c cc -c -O -fno-ident -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/local/src/sys -I/usr/local/src/sys/contrib/dev/acpica -I/usr/local/src/sys/contrib/ipfilter -I/usr/local/src/sys/contrib/dev/ath -I/usr/local/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/local/src/sys/dev/kbd/atkbd.c cc -c -O -fno-ident -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/local/src/sys -I/usr/local/src/sys/contrib/dev/acpica -I/usr/local/src/sys/contrib/ipfilter -I/usr/local/src/sys/contrib/dev/ath -I/usr/local/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/local/src/sys/dev/kbd/atkbdc.c cc -c -O -fno-ident -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/local/src/sys -I/usr/local/src/sys/contrib/dev/acpica -I/usr/local/src/sys/contrib/ipfilter -I/usr/local/src/sys/contrib/dev/ath -I/usr/local/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/local/src/sys/i386/i386/busdma_machdep.c cc -c -O -fno-ident -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/local/src/sys -I/usr/local/src/sys/contrib/dev/acpica -I/usr/local/src/sys/contrib/ipfilter -I/usr/local/src/sys/contrib/dev/ath -I/usr/local/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/local/src/sys/i386/i386/critical.c cc -c -O -fno-ident -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/local/src/sys -I/usr/local/src/sys/contrib/dev/acpica -I/usr/local/src/sys/contrib/ipfilter -I/usr/local/src/sys/contrib/dev/ath -I/usr/local/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/local/src/sys/i386/i386/identcpu.c cc -c -O -fno-ident -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline
Re: cvs commit: src/gnu/usr.bin Makefile src/lib Makefile src/sbinMakefile src/usr.bin Makefile src/usr.sbin Makefile
On Sat, Aug 30, 2003 at 03:46:53AM -0700, Doug Barton wrote: On Sat, 30 Aug 2003, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Doug Barton writes: Poul-Henning, Please don't forget to update src/share/examples/etc/make.conf accordingly. Hmm, so this stuff is documented both in make.conf(5) and an examples file ? Sounds like one place too many to me. Well, there's always been an example make.conf file. In previous incarnations it's lived in /etc, then /etc/defaults. I also agree with the previous poster that it's useful to have such an example, and mergemaster uses it for the -p option. In former times the make.conf file has been installed in /etc when doing a fresh FreeBSD installation. It contained useful commented out options. If memory serves me right, the file isn't installed anymore by default. Is there a reason ? I regarded this as useful tro have it around under /etc, so to say ready for use. Andreas /// -- Andreas Klemm - Powered by FreeBSD 4.8-STABLE Need a magic printfilter today ? - http://www.apsfilter.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
-current of today, kconsole and others crash with signal 6
JFYI: This hasn't been the case 1 month ago with kernel/os from July 30. machine i386 cpu I686_CPU ident TITAN options SCHED_4BSD #4BSD scheduler options INET#InterNETworking options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support options UFS_ACL #Support for access control lists options UFS_DIRHASH #Improve performance on big directories options MD_ROOT #MD is a potential root device options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS#Pseudo-filesystem framework options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 #Compatible with FreeBSD4 options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions options KBD_INSTALL_CDEV# install a CDEV entry in /dev device isa device pci device fdc device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives options ATA_STATIC_ID #Static device numbering device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device vga # VGA video card driver device splash # Splash screen and screen saver support device sc device agp # support several AGP chipsets device npx device sio # 8250, 16[45]50 based serial ports device miibus # MII bus support device fxp # Intel EtherExpress PRO/100B (82557, 82558) device random # Entropy device device loop# Network loopback device ether # Ethernet support device pty # Pseudo-ttys (telnet etc) device md # Memory disks device bpf # Berkeley packet filter device uhci# UHCI PCI-USB interface device ohci# OHCI PCI-USB interface device usb # USB Bus (required) device ugen# Generic device ulpt# Printer device uscanner# Scanners FreeBSD titan.klemm.apsfilter.org 5.1-CURRENT FreeBSD 5.1-CURRENT #2: Sat Aug 30 14:25:21 CEST 2003 [EMAIL PROTECTED]:/export/obj/usr/src/sys/TITAN i386 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 #2: Sat Aug 30 14:25:21 CEST 2003 [EMAIL PROTECTED]:/export/obj/usr/src/sys/TITAN Preloaded elf kernel /boot/kernel/kernel at 0xc042b000. Preloaded elf module /boot/kernel/acpi.ko at 0xc042b1f4. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel Pentium III (997.46-MHz 686-class CPU) Origin = GenuineIntel Id = 0x686 Stepping = 6 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 536854528 (511 MB) avail memory = 516841472 (492 MB) Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: ASUS MED_2001 on motherboard pcibios: BIOS version 2.10 Using $PIR table, 6 entries at 0xc00f0eb0 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0 acpi_cpu0: 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 4 INTD is routed to irq 10 pcib0: slot 4 INTD is routed to irq 10 pcib0: slot 9 INTA is routed to irq 3 pcib0: slot 10 INTA is routed to irq 10 agp0: VIA 82C691 (Apollo Pro) host to PCI bridge mem 0xfc00-0xfdff at device 0.0 on pci0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.AGP_ - AE_NOT_FOUND pci1: ACPI PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 4.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C686A UDMA66 controller port 0xd800-0xd80f at device 4.1 on pci0
Re: cvs commit: src/gnu/usr.bin Makefile src/lib Makefile src/sbinMakefile src/usr.bin Makefile src/usr.sbin Makefile
On Sat, Aug 30, 2003 at 02:55:32PM +0200, Andreas Klemm wrote: On Sat, Aug 30, 2003 at 03:46:53AM -0700, Doug Barton wrote: On Sat, 30 Aug 2003, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Doug Barton writes: Poul-Henning, Please don't forget to update src/share/examples/etc/make.conf accordingly. Hmm, so this stuff is documented both in make.conf(5) and an examples file ? Sounds like one place too many to me. Well, there's always been an example make.conf file. In previous incarnations it's lived in /etc, then /etc/defaults. I also agree with the previous poster that it's useful to have such an example, and mergemaster uses it for the -p option. In former times the make.conf file has been installed in /etc when doing a fresh FreeBSD installation. It contained useful commented out options. If memory serves me right, the file isn't installed anymore by default. Is there a reason ? I regarded this as useful tro have it around under /etc, so to say ready for use. See /etc/defaults/make.conf -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/gnu/usr.bin Makefile src/lib Makefile src/sbinMakefile src/usr.bin Makefile src/usr.sbin Makefile
On Sat, Aug 30, 2003 at 03:11:02PM +0200, Wilko Bulte wrote: On Sat, Aug 30, 2003 at 02:55:32PM +0200, Andreas Klemm wrote: On Sat, Aug 30, 2003 at 03:46:53AM -0700, Doug Barton wrote: On Sat, 30 Aug 2003, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Doug Barton writes: Poul-Henning, Please don't forget to update src/share/examples/etc/make.conf accordingly. Hmm, so this stuff is documented both in make.conf(5) and an examples file ? Sounds like one place too many to me. Well, there's always been an example make.conf file. In previous incarnations it's lived in /etc, then /etc/defaults. I also agree with the previous poster that it's useful to have such an example, and mergemaster uses it for the -p option. In former times the make.conf file has been installed in /etc when doing a fresh FreeBSD installation. It contained useful commented out options. If memory serves me right, the file isn't installed anymore by default. Is there a reason ? I regarded this as useful tro have it around under /etc, so to say ready for use. See /etc/defaults/make.conf Only in RELENG_4, last time I checked. Ceri -- User: DO YOU ACCEPT JESUS CHRIST AS YOUR PERSONAL LORD AND SAVIOR? Iniaes: Sure, I can accept all forms of payment. -- www.chatterboxchallenge.com pgp0.pgp Description: PGP signature
Re: cvs commit: src/gnu/usr.bin Makefile src/lib Makefile src/sbinMakefile src/usr.bin Makefile src/usr.sbin Makefile
* Ceri Davies [EMAIL PROTECTED] [030830 09:18]: On Sat, Aug 30, 2003 at 03:11:02PM +0200, Wilko Bulte wrote: See /etc/defaults/make.conf Only in RELENG_4, last time I checked. In 5.x, since make.conf was not a set of defaults but merely a list of available make flags, it was moved out of /etc/defaults: $ locate make.conf [...] /usr/share/examples/etc/make.conf [...] --Mike pgp0.pgp Description: PGP signature
re: Fresh CVSUP, new ATAng problems and nvidia.ko compile issues
All, A constant in one of the kernel header file seems to have been renamed. Change PCIR_HEADERTYPE to PCIR_HDRTYPE in the NVIDIA code and all will be well. I have tried this myself and all is well. Cheers, Brendon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 2 ports broken after gcc import
On Fri, 29 Aug 2003, Kenneth Culver wrote: Bizarre. I use ACLs in my kernel daily, and I use nmap almost daily, and haven't seen this. If you re-add ACLs with a fresh kernel build, does the problem come back? Could you look at ktraces of nmap with and without ACLs and see what causes it? Do you have ACLs enabled on any file systems, or are you just running with the kernel option? I was running with just the kernel option, and nothing configured for it. I can't think of what else the problem could be, when I recompiled the kernel it just started working again, it might not have anything at all to do with ACL's and more to do with the fact that I just recompiled it. One of my other -CURRENT machines is working now as well after a recompile. I'll do more testing to see if I can pinpoint the problem and I'll probably have results by Tuesday (holiday weekend :-P ) I just built a fresh nmap on my -current box and it appears to work fine for me, as did the older nmap. So I guess that leaves me firmly in the unable to reproduce camp. I have noticed that, on my wi0 boxes, I tend to get a fair number of ENOBUFS errors when nmaping, but that appears to be unrelated to the presence of UFS_ACL in the kernel. Are your different boxes using the same type of network interface? Do you rely on routed or use static routes? If you tcpdump the interface, do any nmap packets get out -- for example, the initial ping it performs before scanning a host, or none? Have a good holiday weekend :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 2 ports broken after gcc import
On Fri, 29 Aug 2003, Kenneth Culver wrote: Might devfs propagate ACL characteristics via /dev nodes into applications? Otherwise, the symptom you described would have made me point to the IP firewall first. My machine that was showing the problem didn't have a firewall enabled. I'll still mess with it some more to see what I can come up with, maybe it was the firewall, but I don't remember having ipfilter or ipfirewall in the kernel but it'd been a while since I edited that config file or compiled that kernel so maybe I took out the firewall options and never compiled, and then compiled today. (It's been about a month since I did anything kernel related on that machine). Anyway, when I pinpoint the problem I'll mail the list. I think I missed the message that this is a response to, but here's an answer to the question: UFS_ACL controls only the introduction of ACL code into UFS1 and UFS2 file systems, and enables conditional use of ACLs code if the ACLs flag is set on a file system. If the ACLs flag is not set on a file system, the UFS1/UFS2 code is intended to run along its original permissions-based code path. Devfs isn't based on UFS, and so it should be unaffected by the UFS_ACL flag. If there's a definite causal relationship between UFS_ACL and the nmap failure, I can't help but wonder if it's a result of a timing, code layout, or memory allocation change of some sort. I wouldn't rule out a bug in the ACL code, but it seems somewhat unlikely as, without the ACLs flag set, the code path in the UFS code should be minimally changed... The best path to track this down is to try to figure out for sure which system call is failing, compare expected vs. wire network transmissions, and see if we can reproduce this in a simpler test program. We've recently made some changes in how the permissions of new objects are calculated using ACLs; they were made somewhat before the gcc changes, I believe, but it might also be interesting to see test cases from before both changes, in between the changes, and after both, to confirm that it was definitely the gcc change that kicked off the problem, rather than the UFS change. Finally, I'd like to know what, if any, optimization flags you're using for the kernel compile... 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]
nvidia-driver still fails on -CURRENT
Hello, some people reported strange behavior of nvidia-driver: after starting X the screen flickers shortly and then displays gibberish in text-mode. The system is still responsive, as one can login via serial console. XFree86.0.log stops at: (II) NVIDIA(0): Setting mode 1024x768 I also experience this problem since I updated from 5.1-RELEASE to -CURRENT in order to try out ATAng (which works perfectly so far on my box). In contrast to other reports I am _unable_ to get a working nvidia-driver by changing AGP settings, even with NvAGP set to 0. My system is a Athlon XP 2400+ with SiS chipset. My graphics card is a GeForce FX 5200. -CURRENT is from yesterday (5.1-CURRENT #4: Fri Aug 29 22:41:20 CEST 2003). I hope someone can give me some hints on how to get nvidia-driver working again. Regards, Julian Stecklina -- A warped sense of humor is vastly better than no sense of humor at all. pgp0.pgp Description: PGP signature
Re: Someone help me understand this...?
On Thu, Aug 28, 2003 at 11:34:09AM -0400, Robert Watson wrote: Clearly, unbreaking applications like Diablo by default is desirable. At least OpenBSD has similar protections to these turned on by default, and possibly other systems as well. As 5.x sees more broad use, we may well bump into other cases where applications have similar behavior: they rely on no special protections once they've given up privilege. I wonder if Diablo can run unmodified on OpenBSD; it could be they don't include SIGALRM on the list of protect against signals, or it could be that they modify Diablo for their environment to use an alternative signaling mechanism. Another alternative to this patch would simply be to add SIGARLM to the list of acceptable signals to deliver in the privilege-change case. OpenBSD does not consider a process 'tainted' if it changes credentials while running. From the issetugid(2) manpage: The status of issetugid() is only affected by execve(). In most cases, fail-stop is a reasonable behavior for unexpected security behavior from the system, but ignore is likely to shoot you later. :-) I tend to wrap even kill() calls as uid 0 in an assertion check, just to be on the safe side. If nothing else, it helps detect the case where the other process has died, and you're using a stale pid. It's particular useful if the other process has died, the pid has been reused, and it's now owned by another user, which is a real-world case where kill() as a non-0 uid can fail even when you're sure it can't :-). This can be avoided by careful programming: do not use SA_NOCLDWAIT and don't pass pids to kill() when they have been returned by wait() or similar functions. If the process has terminated in between, it's a zombie. In that case, FreeBSD probably returns ESRCH but SUSv3 mandates returning success (but performing no action). Jilles Tjoelker ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 2 ports broken after gcc import
I just built a fresh nmap on my -current box and it appears to work fine for me, as did the older nmap. So I guess that leaves me firmly in the unable to reproduce camp. I have noticed that, on my wi0 boxes, I tend to get a fair number of ENOBUFS errors when nmaping, but that appears to be unrelated to the presence of UFS_ACL in the kernel. Are your different boxes using the same type of network interface? Do you rely on routed or use static routes? If you tcpdump the interface, do any nmap packets get out -- for example, the initial ping it performs before scanning a host, or none? Well, on one of my boxes, I have IPFILTER, but no ACL's and it works fine, on the one that was previously not working, I had IPFILTER (but with no rules set) and ACL's. I removed all references to ipfilter from rc.conf (my ipf.rules and ipnat.rules were blank), removed IPFILTER and ACL from the kernel, recompiled, and rebooted, and it started working. So now I just have to go back and figure out which knob I turned to fix things. I'm running late now though so I'll let you know as soon as I can get back to it (the computer that was really having the problems was at work, so I can't get to it until tuesday). Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: snd_csa issues in -CURRENT
On Sat, Aug 30, 2003 at 06:45:49PM +1000, matti k wrote: On Fri, 29 Aug 2003 12:36:56 +0200 Eirik Oeverby [EMAIL PROTECTED] wrote: I might also point out that there are two distinct kinds of distortion happening: The click/pop/crackle kind of distortion, and one where a sound buffer is repeated over and over 5-10 times - as if the hardware has some kind of hickup. Again - this *only* happens in -CURRENT, not in -STABLE or in any other OS (tested OS/2, BeOS, Linux, winXX). Anyone? :) /Eirik I get the same pops/crackling but using a SB Live! I think it started happening when I switched from 4.x to 5.x The strange thing is that sound works fine after a reboot but some hours after that I get the noises. It only happens with music (mp3,ogg). $ uname -a FreeBSD platypus.freebsd.home 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Sun Aug 24 21:53:30 EST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PLATY4 i386 dmesg attached I have seen (heard?) the same crackling problem on the onboard intel 815 sound on my laptop. I don't recall it happing in -STABLE, but I could be wrong. dmesg also attached -jre 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 #4: Tue Aug 26 17:17:17 EDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/OSIRIS Preloaded elf kernel /boot/kernel/kernel at 0xc057f000. Preloaded elf module /boot/kernel/if_ath.ko at 0xc057f2bc. Preloaded elf module /boot/kernel/wlan.ko at 0xc057f368. Preloaded elf module /boot/kernel/rc4.ko at 0xc057f414. Preloaded elf module /boot/kernel/ath_hal.ko at 0xc057f4bc. Preloaded elf module /boot/kernel/acpi.ko at 0xc057f568. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel Pentium III (794.93-MHz 686-class CPU) Origin = GenuineIntel Id = 0x68a Stepping = 10 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 266862592 (254 MB) avail memory = 253075456 (241 MB) netsmb_dev: loaded Pentium Pro MTRR support enabled VESA: v3.0, 1024k memory, flags:0x1, mode table:0xc0467240 (140) VESA: Intel815M(TM) Graphics Chip Accelerated VGA BIOS npx0: math processor on motherboard npx0: INT 16 interface acpi0: SONY U0 on motherboard pcibios: BIOS version 2.10 Using $PIR table, 9 entries at 0xc00fdf30 Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 acpi_cpu0: CPU on acpi0 acpi_tz0: thermal zone on acpi0 acpi_lid0: Control Method Lid Switch 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 9 pcib0: possible interrupts: 9 pcib0: slot 31 INTD routed to irq 9 via \\_SB_.LNKD pcib0: slot 31 INTB is routed to irq 9 pcib0: slot 31 INTC is routed to irq 9 pcib0: slot 31 INTB is routed to irq 9 pcib0: slot 31 INTB is routed to irq 9 agp0: Intel 82815 (i815 GMCH) SVGA controller mem 0xf400-0xf407,0xf800-0xfbff irq 9 at device 2.0 on pci0 pcib1: ACPI PCI-PCI bridge at device 30.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib1: slot 0 INTA is routed to irq 9 pcib1: slot 8 INTA is routed to irq 9 pci1: serial bus, FireWire at device 0.0 (no driver attached) cbb0: RF5C476 PCI-CardBus Bridge at device 2.0 on pci1 start (8800) sc-membase (f410) end () sc-memlimit (f41f) cardbus0: CardBus bus on cbb0 pccard0: 16-bit PCCard bus on cbb0 pcib1: possible interrupts: 9 pcib1: slot 2 INTA routed to irq 9 via \\_SB_.LNKC cbb1: RF5C476 PCI-CardBus Bridge at device 2.1 on pci1 start (8800) sc-membase (f410) end () sc-memlimit (f41f) cardbus1: CardBus bus on cbb1 pccard1: 16-bit PCCard bus on cbb1 pcib1: slot 2 INTB is routed to irq 9 fxp0: Intel 82801BA/CAM (ICH2/3) Pro/100 Ethernet port 0x3000-0x303f mem 0xf4104000-0xf4104fff irq 9 at device 8.0 on pci1 fxp0: Ethernet address xx:xx:xx:xx:xx:xx miibus0: MII bus on fxp0 inphy0: i82562ET 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH2 UDMA100 controller port 0x1800-0x180f at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: Intel 82801BA/BAM (ICH2) USB controller USB-A port 0x1820-0x183f irq 9 at device 31.2 on pci0 usb0: Intel 82801BA/BAM (ICH2) USB controller USB-A 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: serial bus, SMBus at device 31.3 (no driver attached) uhci1: Intel 82801BA/BAM (ICH2) USB controller USB-B port 0x1840-0x185f irq 9 at device 31.4 on pci0 usb1: Intel 82801BA/BAM (ICH2) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub1:
Re: 2 ports broken after gcc import
I think I missed the message that this is a response to, but here's an answer to the question: UFS_ACL controls only the introduction of ACL code into UFS1 and UFS2 file systems, and enables conditional use of ACLs code if the ACLs flag is set on a file system. If the ACLs flag is not set on a file system, the UFS1/UFS2 code is intended to run along its original permissions-based code path. Devfs isn't based on UFS, and so it should be unaffected by the UFS_ACL flag. If there's a definite causal relationship between UFS_ACL and the nmap failure, I can't help but wonder if it's a result of a timing, code layout, or memory allocation change of some sort. I wouldn't rule out a bug in the ACL code, but it seems somewhat unlikely as, without the ACLs flag set, the code path in the UFS code should be minimally changed... The best path to track this down is to try to figure out for sure which system call is failing, compare expected vs. wire network transmissions, and see if we can reproduce this in a simpler test program. We've recently made some changes in how the permissions of new objects are calculated using ACLs; they were made somewhat before the gcc changes, I believe, but it might also be interesting to see test cases from before both changes, in between the changes, and after both, to confirm that it was definitely the gcc change that kicked off the problem, rather than the UFS change. Finally, I'd like to know what, if any, optimization flags you're using for the kernel compile... Well, don't worry too much, I went back and checked the kernel config I used for the kernel that was having problems, and it did indeed have IPFILTER compiled in, BUT I had no rules loading. Both of the rules files were empty. (That's basically what I said in my previous message). I just took me the better part of a night to sort out what I had on that box and remember what I did. Anyway, like I said, I won't be back on that box until Tuesday so I'll have to let you know which knob I turned then... although if it WAS the firewall that's really wierd since I had no rules loaded, and my other box that never had the problem DID have rules loaded. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Someone help me understand this...?
On Sat, 30 Aug 2003, Jilles Tjoelker wrote: On Thu, Aug 28, 2003 at 11:34:09AM -0400, Robert Watson wrote: Clearly, unbreaking applications like Diablo by default is desirable. At least OpenBSD has similar protections to these turned on by default, and possibly other systems as well. As 5.x sees more broad use, we may well bump into other cases where applications have similar behavior: they rely on no special protections once they've given up privilege. I wonder if Diablo can run unmodified on OpenBSD; it could be they don't include SIGALRM on the list of protect against signals, or it could be that they modify Diablo for their environment to use an alternative signaling mechanism. Another alternative to this patch would simply be to add SIGARLM to the list of acceptable signals to deliver in the privilege-change case. OpenBSD does not consider a process 'tainted' if it changes credentials while running. From the issetugid(2) manpage: The status of issetugid() is only affected by execve(). In OpenBSD, two flags are used to represent the credential change notion: P_SUGIDEXEC, and P_SUGID. issetugid() checks the first of these, but signal delivery checks P_SUGID. P_SUGIDEXEC is set during execve(). In FreeBSD, we have a combined notion used by both, since the same protections generally apply. You can find a comment comparing our use of P_SUGID to the OpenBSD approach in our issetugid() implementation: /* * Note: OpenBSD sets a P_SUGIDEXEC flag set at execve() time, * we use P_SUGID because we consider changing the owners as * tainting as well. * This is significant for procs that start as root and become * a user without an exec - programs cannot know *everything* * that libc *might* have put in their data segment. */ Regarding specific signals: inspection of the OpenBSD implementation reveals that the following signals are permitted in the P_SUGID case, assuming a reasonable credential match: case 0: case SIGKILL: case SIGINT: case SIGTERM: case SIGALRM: case SIGSTOP: case SIGTTIN: case SIGTTOU: case SIGTSTP: case SIGHUP: case SIGUSR1: case SIGUSR2: In FreeBSD, we permit: case 0: case SIGKILL: case SIGINT: case SIGTERM: case SIGSTOP: case SIGTTIN: case SIGTTOU: case SIGTSTP: case SIGHUP: case SIGUSR1: case SIGUSR2: So they permit SIGALRM in addition to the signals we support. In light of this thread, I think it would be reasonable to add SIGALRM to our list as well. In most cases, fail-stop is a reasonable behavior for unexpected security behavior from the system, but ignore is likely to shoot you later. :-) I tend to wrap even kill() calls as uid 0 in an assertion check, just to be on the safe side. If nothing else, it helps detect the case where the other process has died, and you're using a stale pid. It's particular useful if the other process has died, the pid has been reused, and it's now owned by another user, which is a real-world case where kill() as a non-0 uid can fail even when you're sure it can't :-). This can be avoided by careful programming: do not use SA_NOCLDWAIT and don't pass pids to kill() when they have been returned by wait() or similar functions. If the process has terminated in between, it's a zombie. In that case, FreeBSD probably returns ESRCH but SUSv3 mandates returning success (but performing no action). There's still a race possible here, it just becomes more narrow with conservative programming. And in the classic use of pids for signalling (/var/run/foo.pid, or kill -9 pid), these approaches won't help. The only way to close this sort of race is to have a notion of a unique process identifier that lasts beyond the lifetime of the process itself -- i.e., the ability to return EMYSINCERESTREGRESTS if you try to signal a process after it has died, and have a guarantee that the handle won't be reused. 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]
su in free(): warning: chunk is already free
On my 5.1-current I logged in from outside and tried su getting: $ su su in free(): warning: chunk is already free su: pam_start: system error I'm not sure whether my system is absolutely in sync but I'd think with make buildworld, installworld, buildkernel, installkernel reboot it should be. -- Chris Christoph P. U. Kukulies kukulies (at) rwth-aachen.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/sys/vm swap_pager.c
In message [EMAIL PROTECTED], Poul-Henning Kamp writes: phk 2003/08/30 09:44:27 PDT FreeBSD src repository Modified files: sys/vm swap_pager.c Log: Add a close() method to a swapdev. Add a GEOM based backend. This is actually a quite significant step in our SMPng progress as this is the first code which migrates from vnode based access to raw disks to GEOM based access. But this is a rather symbolic thing, in practice nobody will be able to tell any difference. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
more hints
If I remove device pmtimer from my config, I get a consistent panic, or variation of: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0135b0a7 stack pointer = 0x10:0xd68f2c48 frame pointer = 0x10:0xd68f2c64 code segment = base 0x0 limit 0x, type 0x1b processor eflags= interrupt enabled, resume, IOPL=0 current process = 12 (swi7: tty:sio clock) trap number = 12 panic page fault ... This is with leaving my USB 2.0 drive turned on during boot time. If I use the same kernel (sans pmtimer) , but boot with my USB drive turned off, all is well. Or, I can put pmtimer back in the kernel and boot with the drive turned on, but sooner or later I'll get some type of panic. Some kind of timimg issue?. I think all of these panics have something to do with leaving the USB drive on at boot time. It seems like I don't have any issues if it stays turned off. That's probably why we're not seeing any reports, I doubt a lot of folks are using a USB 2.0 HD along with ehci... Again, all this started shortly after July 14th. The USB DMA changes may have something to do with this... -- = = Bryan D. LiesnerLeezSoft Communications, Inc. = = A subsidiary of LeezSoft Inc. = = [EMAIL PROTECTED] Home of the Gipper= = ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fresh CVSUP, new ATAng problems ...
On Sat, Aug 30, 2003 at 11:33:17AM +0100, Matt wrote: Hi, I now have a new issue with ATAng that I didn't have last week when I tried ATAng. My CDRW is now not detected during probing. I get this message: Aug 30 11:21:00 neo kernel: ad0: 76319MB ST380020A [155061/16/63] at ata0-master UDMA100 Aug 30 11:21:00 neo kernel: ata1-slave: FAILURE - ATA_IDENTIFY status=41READY,ERROR error=4ABORTED Aug 30 11:21:00 neo kernel: acd0: DVDROM Compaq DVD-ROM SD-616T at ata1-master PIO4 I have something roughly the same. It started right away with ATAng in my case: : atapci0: VIA 82C686A UDMA66 controller port 0xd000-0xd00f at device 7.1 on pci0 ata0: pre reset mask=03 ostat0=50 ostat2=00 ata0-master: ATAPI 00 00 ata0-slave: ATAPI 00 00 ata0: after reset mask=03 stat0=50 stat1=00 ata0-master: ATA 01 a5 ata0: devices=01 ata0: at 0x1f0 irq 14 on atapci0 ata1: pre reset mask=03 ostat0=50 ostat2=50 ata1-slave: ATAPI 14 eb ata1-master: ATAPI 00 00 ata1: after reset mask=03 stat0=00 stat1=00 ata1-master: ATA 01 a5 ata1: devices=09 ata1: at 0x170 irq 15 on atapci0 : ata0-master: pio=0x0c wdma=0x22 udma=0x44 cable=80pin ad0: setting UDMA66 on VIA 82C686A chip ad0: WDC WD205BA/16.13M16 ATA-4 disk at ata0-master ad0: 19574MB (40088160 sectors), 39770 C, 16 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, UDMA66 GEOM: new disk ad0 ata1-slave: pio=0x0c wdma=0x22 udma=0x cable=40pin ata1-master: FAILURE - ATA_IDENTIFY status=51READY,DSC,ERROR error=4ABORTED acd0: setting PIO4 on VIA 82C686A chip acd0: LG CD-RW CED-8083B/1.06 CDRW drive at ata1 as slave acd0: read 4134KB/s (5512KB/s) write 689KB/s (689KB/s), 2048KB buffer, PIO4 acd0: Reads: CDR, CDRW, CDDA stream, packet acd0: Writes: CDR, CDRW, test write acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc : Some roughly 90% of the time the CDRW is probed and the DVD is not, but it accassionally is the other way around. If I run atacontrol(8) often enough I get this: Aug 29 22:24:10 athlon sudo: marcel : TTY=ttyp0 ; PWD=/home/marcel ; USER=root ; COMMAND=/sbin/atacontrol reinit 1 Aug 29 22:24:10 athlon kernel: ata1: resetting devices .. Aug 29 22:24:10 athlon kernel: ata1-master: FAILURE - ATA_IDENTIFY status=51READY,DSC,ERROR error=4ABORTED Aug 29 22:24:10 athlon kernel: done : (10 minutes worth of atacontrol :-) : Aug 29 22:24:43 athlon sudo: marcel : TTY=ttyp0 ; PWD=/home/marcel ; USER=root ; COMMAND=/sbin/atacontrol reinit 1 Aug 29 22:24:43 athlon kernel: ata1: resetting devices .. Aug 29 22:24:43 athlon kernel: acd0: WARNING - removed from configuration Aug 29 22:24:43 athlon kernel: ata1-slave: FAILURE - ATA_IDENTIFY status=51READY,DSC,ERROR error=4ABORTED Aug 29 22:24:43 athlon kernel: acd0: DVDROM SAMSUNG DVD-ROM SD-608 at ata1-master PIO4 Aug 29 22:24:43 athlon kernel: done Both drives function without problems when they are probed. I wanted to collect more data before sending out mail, but seeing your mail, I might as well chime in now :-) FYI, -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fresh CVSUP, new ATAng problems and nvidia.ko compile issues
I filed one yesterday: ports/56157 -- Evan Dower Undergraduate, Computer Science University of Washington Public key: http://students.washington.edu/evantd/pgp-pub-key.txt Key fingerprint = D321 FA24 4BDA F82D 53A9 5B27 7D15 5A4F 033F 887D From: Arjan van Leeuwen [EMAIL PROTECTED] To: Brendon and Wendy [EMAIL PROTECTED],[EMAIL PROTECTED] Subject: Re: Fresh CVSUP, new ATAng problems and nvidia.ko compile issues Date: Sat, 30 Aug 2003 16:54:58 +0200 On Saturday 30 August 2003 16:20, Brendon and Wendy wrote: All, A constant in one of the kernel header file seems to have been renamed. Change PCIR_HEADERTYPE to PCIR_HDRTYPE in the NVIDIA code and all will be well. I have tried this myself and all is well. Cheers, Brendon Can you submit a PR for the x11/nvidia-driver port? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] _ Get MSN 8 and enjoy automatic e-mail virus protection. http://join.msn.com/?page=features/virus ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /lib symlinks problem?
On Sat, Aug 30, 2003 at 01:54:27PM +0200, Alexander Leidinger wrote:
[...]
I think the problem is, that some tools have a problem finding it...:
---snip---
(3) [EMAIL PROTECTED] % nm -D /usr/lib/libc.so | grep fpcl
nm: /usr/lib/libc.so: No such file or directory
(4) [EMAIL PROTECTED] % ll /usr/lib/libc.so
lrwxr-xr-x 1 root wheel 19B 29 Aug 13:57 /usr/lib/libc.so@ - ../../lib/libc.so.5
(5) [EMAIL PROTECTED] % ll /usr
lrwxr-xr-x 1 root wheel 7.0B 18 Aug 2001 /usr@ - big/usr
(7) [EMAIL PROTECTED] % ll /lib/libc.so
lrwxr-xr-x 1 root wheel 9.0B 29 Aug 13:57 /lib/libc.so@ - libc.so.5
---snip---
I think a workaround would be to use absolute symlinks (at least as an
option).
I might be missing an obvious, but I just don't see a reason
why we should use relative linking here: we should just link
to where we really install. With the attached patch, I get:
$ make -n install -DNOMAN DESTDIR=/foo
install -C -o root -g wheel -m 444 libalias.a /foo/usr/lib
install -s -o root -g wheel -m 444 libalias.so.4 /foo/lib
ln -fs libalias.so.4 /foo/lib/libalias.so
ln -fs /foo/lib/libalias.so.4 /foo/usr/lib/libalias.so
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software Ltd,
[EMAIL PROTECTED] FreeBSD committer
Index: bsd.lib.mk
===
RCS file: /home/ncvs/src/share/mk/bsd.lib.mk,v
retrieving revision 1.150
diff -u -r1.150 bsd.lib.mk
--- bsd.lib.mk 17 Aug 2003 23:56:29 - 1.150
+++ bsd.lib.mk 30 Aug 2003 18:48:17 -
@@ -207,8 +207,8 @@
${SHLIB_NAME} ${DESTDIR}${SHLIBDIR}
.if defined(SHLIB_LINK)
ln -fs ${SHLIB_NAME} ${DESTDIR}${SHLIBDIR}/${SHLIB_LINK}
-.if (${LIBDIR} != ${SHLIBDIR})
- ln -fs ${LIBDIR:C|/[^/]+|/..|g:S|^/||}${SHLIBDIR}/${SHLIB_NAME} \
+.if ${LIBDIR} != ${SHLIBDIR}
+ ln -fs ${DESTDIR}${SHLIBDIR}/${SHLIB_NAME} \
${DESTDIR}${LIBDIR}/${SHLIB_LINK}
.endif
.endif
pgp0.pgp
Description: PGP signature
Re: Someone help me understand this...?
On Sat, 30 Aug 2003 12:23:35 -0400 (EDT), Robert Watson [EMAIL PROTECTED] said: The only way to close this sort of race is to have a notion of a unique process identifier that lasts beyond the lifetime of the process itself -- i.e., the ability to return EMYSINCERESTREGRESTS if you try to signal a process after it has died, and have a guarantee that the handle won't be reused. This is traditionally done by holding an advisory lock on the pid file; if the file is no longer locked, then the process holding the lock must have exited. You could also do it with UUIDs and a more heavyweight signal API. -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Someone help me understand this...?
On Thu, 28 Aug 2003, Joe Greco wrote:
Could you confim this happens with 4.8? The access control checks there
are substantially different, and I wouldn't expect the behavior you're
seeing on 4.8...
Rather difficult. I'll see if the client will let me trash a production
system, but usually people don't like $40K servers handing out a few
hundred megabits of traffic going out of service. We were trying to fix
it on the scratch box (which happens to have 5.1R on it) and then were
going to see how it fared on the production systems.
I think it's safe to assume that if you're seeing a similar failure,
there's a different source given my reading of the code, but I'm willing
to be proven wrong. It's probably not worth the investment if you're
talking about large quantities of money, though.
It's more like large quantities of annoyance and work. Can you
describe the case you're envisioning? If I can easily poke at it, I can
at least get some clues.
I guess all I'm looking for is confirmation that your original statement
(happens in 4.8 and 5.1) is completely correct: the 5.1 behavior is
expected, but I'm surprised it happens with 4.8.
Correct. The USR signals control debug levels. If it was a signal that
was only used internally, it could be changed, of course, but changing a
signal used by humans (and one used in the same manner as other
programs) is probably a bad idea.
Try the patch attached, which introduces both the conservative_signals
sysctl, and adds SIGALRM to the list of acceptable signals for P_SUGID
processes.
Yeah, if anything, we probably don't want to do that, because the
resources set up as root are usually more attractive. I don't have a
problem with coding in some FreeBSD-isms, but I don't see it as buying
us anything, does it?
I'm not sure there are explicit benefits in this specific situation,
except that you can run Diablo with the resource limits of the user you
configure, and potentially those might be similar to (but perhaps not
identical to) those given to root. I.e., instead of hard-coding use the
resource limits of root, you're saying use the resource limits of the
user Diablo is run as, and set those to what you want. Given that
heavy-weight news servers are likely to be dedicated machines, it's a
subtle but perhaps useful semantic difference.
Updated patch below.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
Index: kern_prot.c
===
RCS file: /home/ncvs/src/sys/kern/kern_prot.c,v
retrieving revision 1.175
diff -u -r1.175 kern_prot.c
--- kern_prot.c 13 Jul 2003 01:22:20 - 1.175
+++ kern_prot.c 30 Aug 2003 19:45:50 -
@@ -1367,6 +1367,20 @@
return (cr_cansee(td-td_ucred, p-p_ucred));
}
+/*
+ * 'conservative_signals' prevents the delivery of a broad class of
+ * signals by unprivileged processes to processes that have changed their
+ * credentials since the last invocation of execve(). This can prevent
+ * the leakage of cached information or retained privileges as a result
+ * of a common class of signal-related vulnerabilities. However, this
+ * may interfere with some applications that expect to be able to
+ * deliver these signals to peer processes after having given up
+ * privilege.
+ */
+static int conservative_signals = 1;
+SYSCTL_INT(_security_bsd, OID_AUTO, conservative_signals, CTLFLAG_RW,
+conservative_signals, 0, Unprivileged processes prevented from
+sending certain signals to processes whose credentials have changed);
/*-
* Determine whether cred may deliver the specified signal to proc.
* Returns: 0 for permitted, an errno value otherwise.
@@ -1399,12 +1413,13 @@
* bit on the target process. If the bit is set, then additional
* restrictions are placed on the set of available signals.
*/
- if (proc-p_flag P_SUGID) {
+ if (conservative_signals (proc-p_flag P_SUGID)) {
switch (signum) {
case 0:
case SIGKILL:
case SIGINT:
case SIGTERM:
+ case SIGALRM:
case SIGSTOP:
case SIGTTIN:
case SIGTTOU:
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! ATAng committed
Le 2003-08-30, Glenn Johnson écrivait : I guess I wrote that too soon, it just locked up again. This time though, the machine rebooted after about 10 seconds so I could not get to another machine to see if I could poke around. If it rebooted, then maybe it panic'd. Do you have a kernel core dump? -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vmware-guestd on vmware hosted Windows
On Sat, 2003-08-30 at 04:32, Masahide -mac- NODA wrote: Sorry, this is repot only. I'm upgrading from 2003/08/19 current to 2003/08/30 current on vmware 3.x(host OS is Windows), and I tried to run vmware-guestd, # ./vmware-guestd ELF binary type 0 not known. /usr/local/sbin/vmware-guestd: Exec format error. Wrong Architecture I suggested on IRC, try # brandelf -t FreeBSD ./vmware-guestd I tried this and succeceed to run vmware-guestd. Before brandelf -t, brandelf result is, % brandelf vmware-guestd File 'vmware-guestd' is of brand 'SVR4' (0). and after brandelf -t is, % brandelf vmware-guestd File 'vmware-guestd' is of brand 'FreeBSD' (9). Any comments? If memory serves, you'll need COMPAT3x in order to use that. Unfortunatly VMWare really hasn't updated their drivers, since well FreeBSD 3.x I could be wrong, if i am tell me. But that's what I remember. signature.asc Description: This is a digitally signed message part ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: aac related panics
On Fri, Aug 29, 2003 at 10:54:10PM -0500, Chip Norkus wrote: My company is working on a new hosting infrastructure, and I'd like to use FreeBSD if possible, so any help at all would be greatly appreciated as we plan to use these machines for some time. Note that 5.x is not yet production quality. It is still primarily intended for early adopters to help shake out any bugs. Unless you specifically need 5.x features, you might find it less painful to start with 4.x as your main platform and just experiment with 5.x on some non-critical boxes. Peter ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
pcic device causes kernel build failure
I found my problem, when I got this new laptop two weeks ago I UN-commented the pcic cardbus bridge just in case. This worked fine up till 8/27, my last build on that machine. Starting last night, with that device in my kernel config, kernel build fails with the error below. Commenting it again allows the kernel to build. FYI, Doug cc -c -O -fno-ident -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/local/src/sys -I/usr/local/src/sys/contrib/dev/acpica -I/usr/local/src/sys/contrib/ipfilter -I/usr/local/src/sys/contrib/dev/ath -I/usr/local/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/local/src/sys/net/if.c cc -c -O -fno-ident -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/local/src/sys -I/usr/local/src/sys/contrib/dev/acpica -I/usr/local/src/sys/contrib/ipfilter -I/usr/local/src/sys/contrib/dev/ath -I/usr/local/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/local/src/sys/net/netisr.c cc -c -O -fno-ident -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/local/src/sys -I/usr/local/src/sys/contrib/dev/acpica -I/usr/local/src/sys/contrib/ipfilter -I/usr/local/src/sys/contrib/dev/ath -I/usr/local/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/local/src/sys/dev/fb/fb.c cc -c -O -fno-ident -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/local/src/sys -I/usr/local/src/sys/contrib/dev/acpica -I/usr/local/src/sys/contrib/ipfilter -I/usr/local/src/sys/contrib/dev/ath -I/usr/local/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/local/src/sys/dev/kbd/atkbd.c cc -c -O -fno-ident -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/local/src/sys -I/usr/local/src/sys/contrib/dev/acpica -I/usr/local/src/sys/contrib/ipfilter -I/usr/local/src/sys/contrib/dev/ath -I/usr/local/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/local/src/sys/dev/kbd/atkbdc.c cc -c -O -fno-ident -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/local/src/sys -I/usr/local/src/sys/contrib/dev/acpica -I/usr/local/src/sys/contrib/ipfilter -I/usr/local/src/sys/contrib/dev/ath -I/usr/local/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/local/src/sys/i386/i386/busdma_machdep.c cc -c -O -fno-ident -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/local/src/sys -I/usr/local/src/sys/contrib/dev/acpica -I/usr/local/src/sys/contrib/ipfilter -I/usr/local/src/sys/contrib/dev/ath -I/usr/local/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/local/src/sys/i386/i386/critical.c cc -c -O -fno-ident -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/local/src/sys -I/usr/local/src/sys/contrib/dev/acpica -I/usr/local/src/sys/contrib/ipfilter -I/usr/local/src/sys/contrib/dev/ath -I/usr/local/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h
Re: cdrdao-1.1.7 now available for ATAng
Did anybody try it? I've no success with this variant at all, cdrdao stubbornly reports Cannot setup device cd0 no matter what :-( What device/driver should I use for ATAPI burner (_NEC CD-RW NR-9100A) to make use of ATAng backend? On Wed, 27 Aug 2003, Soren Schmidt wrote: I've put up cdrdao with ATAng backend support on: ftp://ftp.deepcore.dk/pub/ATA Enjoy! -S?ren Oh, incidentally, does nobody use cdrecord under -CURRENT? Since about 12-14 Aug it consistently crashes box with vm_fault_copy_wired: page missing. 100% reproducible. Everything else (cdrdao, burncd, burners under win2k and linux) on the same computer with the same CD-RW works perfectly all right so this isn't HW problem Regards, Vladimir ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
