Re: wpi driver freeze on boot
On 9/30/08, Henrik Hudson [EMAIL PROTECTED] wrote: I've got a HP dv8000 laptop. Setting up the wpi driver for wireless freezes the system on boot with the following error: wpi0 requested unsupported memory range wpi0: could not allocate memory resource It lists a pcbi device (pcbi4 i think) and an actual memory range, but since I have to reboot using kernel.old the /var/run/dmesg.boot is wiped with the info. Is there anyway to grab the info when it freezes when it reboots? Perhaps, entering single-user mode. Add this lines to your kernel to help debug problem. makeoptions DEBUG=-g options KDB options DDB options GDB options INVARIANTS options INVARIANT_SUPPORT options WITNESS options WITNESS_SKIPSPIN ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
jails and mac_seeotheruids problems in 6-STABLE
Hallo everyone, I have 3 servers in my lab. 2 of them are running 6-STABLE and one of them is running 7-STABLE. All three have services running in jails. I noticed a very peculiar behavior in 6-STABLE when I set the sysctl security.mac.seeotheruids.enabled=1. The root user in my jails was not able to see processes and sockets owned by other users of the same jail, whereas the root user of the host system could see every process (thank the Almighty). The same behavior does not apply on the server running 7-STABLE. In one sense it is more secure, since the root user in a jail is not as strong as the root user should be in a UNIX system. On the other hand, the root user looses its purpose of existence, which I suppose is a bug. Below are the security.mac sysctl settings of both 6 and 7-STABLE: 6-STABLE: security.mac.max_slots: 4 security.mac.enforce_network: 1 security.mac.enforce_pipe: 1 security.mac.enforce_posix_sem: 1 security.mac.enforce_suid: 1 security.mac.mmap_revocation_via_cow: 0 security.mac.mmap_revocation: 1 security.mac.enforce_vm: 1 security.mac.enforce_process: 1 security.mac.enforce_socket: 1 security.mac.enforce_system: 1 security.mac.enforce_kld: 1 security.mac.enforce_sysv_msg: 1 security.mac.enforce_sysv_sem: 1 security.mac.enforce_sysv_shm: 1 security.mac.enforce_fs: 1 security.mac.seeotheruids.specificgid: 0 security.mac.seeotheruids.specificgid_enabled: 0 security.mac.seeotheruids.primarygroup_enabled: 0 security.mac.seeotheruids.enabled: 1 security.mac.portacl.rules: uid:80:tcp:80,uid:80:tcp:443 security.mac.portacl.port_high: 1023 security.mac.portacl.autoport_exempt: 1 security.mac.portacl.suser_exempt: 1 security.mac.portacl.enabled: 1 7-STABLE: security.mac.max_slots: 4 security.mac.version: 3 security.mac.mmap_revocation_via_cow: 0 security.mac.mmap_revocation: 1 security.mac.seeotheruids.specificgid: 0 security.mac.seeotheruids.specificgid_enabled: 0 security.mac.seeotheruids.suser_privileged: 1 security.mac.seeotheruids.primarygroup_enabled: 0 security.mac.seeotheruids.enabled: 1 I would be very glad if someone could inform me whether I am doing something wrong; if not I think I should inform FreeBSD about this bug. Thank you guys in advance, -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Request for testing - top 3.8b1 in the base system
On Mon, Sep 29, 2008 at 01:04:41PM +0100, Thomas Hurst wrote: * Edwin Groothuis ([EMAIL PROTECTED]) wrote: I have made an update for the top(1) utility in the FreeBSD base system to get it from the 3.5b12 version to the 3.8b1 version. Looks good, thanks! IO mode seems to have changed a bit, giving different values to 3.5, it seems while 3.5 gives you the count for the sample period, 3.8 always gives you a per-second rate, e.g. top -mio -s 20: 3.8: 44181 freaky 240 0240 0 0240 99.74% cat 3.5: 44181 freaky 4664 5 4667 0 0 4667 100.00% cat This might be confusing, since it means values from two different top -mio's are no longer directly comparable. I will make it back to per-period because that is the one which actually makes sense (IMHO). 3.8 also seems to be lacking IO sorting options; o vcsw etc are missing. Will they be returning? They will be back. Also, the [number] argument given to -m io has no effect: top -m io 10 Setting it after loading with n 10enter causes top to exit. That's a good one to catch, thanks! Edwin -- Edwin Groothuis |Personal website: http://www.mavetju.org [EMAIL PROTECTED]| Weblog: http://www.mavetju.org/weblog/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: jails and mac_seeotheruids problems in 6-STABLE
On Tue, 30 Sep 2008, George Mamalakis wrote: I have 3 servers in my lab. 2 of them are running 6-STABLE and one of them is running 7-STABLE. All three have services running in jails. I noticed a very peculiar behavior in 6-STABLE when I set the sysctl security.mac.seeotheruids.enabled=1. The root user in my jails was not able to see processes and sockets owned by other users of the same jail, whereas the root user of the host system could see every process (thank the Almighty). The same behavior does not apply on the server running 7-STABLE. In one sense it is more secure, since the root user in a jail is not as strong as the root user should be in a UNIX system. On the other hand, the root user looses its purpose of existence, which I suppose is a bug. Below are the security.mac sysctl settings of both 6 and 7-STABLE: Could you try modifying src/sys/security/mac_seeotheruids/mac_seeotheruids.c in a 6.x tree so that the call to suser_cred() in mac_seeotheruids_check() passes the SUSER_ALLOWJAIL flag rather than 0? This may correct the problem you're experiencing. Let me know and I can merge that change to 6.x. Robert N M Watson Computer Laboratory University of Cambridge 6-STABLE: security.mac.max_slots: 4 security.mac.enforce_network: 1 security.mac.enforce_pipe: 1 security.mac.enforce_posix_sem: 1 security.mac.enforce_suid: 1 security.mac.mmap_revocation_via_cow: 0 security.mac.mmap_revocation: 1 security.mac.enforce_vm: 1 security.mac.enforce_process: 1 security.mac.enforce_socket: 1 security.mac.enforce_system: 1 security.mac.enforce_kld: 1 security.mac.enforce_sysv_msg: 1 security.mac.enforce_sysv_sem: 1 security.mac.enforce_sysv_shm: 1 security.mac.enforce_fs: 1 security.mac.seeotheruids.specificgid: 0 security.mac.seeotheruids.specificgid_enabled: 0 security.mac.seeotheruids.primarygroup_enabled: 0 security.mac.seeotheruids.enabled: 1 security.mac.portacl.rules: uid:80:tcp:80,uid:80:tcp:443 security.mac.portacl.port_high: 1023 security.mac.portacl.autoport_exempt: 1 security.mac.portacl.suser_exempt: 1 security.mac.portacl.enabled: 1 7-STABLE: security.mac.max_slots: 4 security.mac.version: 3 security.mac.mmap_revocation_via_cow: 0 security.mac.mmap_revocation: 1 security.mac.seeotheruids.specificgid: 0 security.mac.seeotheruids.specificgid_enabled: 0 security.mac.seeotheruids.suser_privileged: 1 security.mac.seeotheruids.primarygroup_enabled: 0 security.mac.seeotheruids.enabled: 1 I would be very glad if someone could inform me whether I am doing something wrong; if not I think I should inform FreeBSD about this bug. Thank you guys in advance, -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
recommended setup for amd64 7-STABLE with ZFS, Samba 3.2 and possibly ACLs?
Hi, could anyone give recommendations (or share experience) regarding using ZFS: - FreeBSD 7-Stable (amd64 with 8GB RAM) + special tuning necessary (apart from increasing kernel memory to 1 or more GB for ZFS) - Samba 3.2 + ACLs possible directly under ZFS? + recommended compile options? - NFS - email (imap) - jails (I have seen some problems exist with using snaphots within jails) This is on amd64 with 8GB RAM and external disk array (via FC). Many thanks and best regards, Holger -- Sorry - lost my signature somewhere. Need to buy a new one. Ofers? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
DTrace MFC broke kldstat(2) on RELENG_7
Hi, I recently noticed that kldstat(8) started to dump core for me on RELENG_7. I traced the problem down to kldstat(2). r182231 (DTrace MFC) introduced a new version of kld_file_stat struct and added some code to support the old version of the structure in kldstat(). In the new code the old structure is known as kld_file_stat_1. Unfortunately there's a bug in this code: kldstat() copies always sizeof(struct kld_file_stat) of data to user space while it should copy sizeof(struct kld_file_stat_1) when the old struct is used. This guy is probably suffering from this problem too: http://lists.freebsd.org/pipermail/freebsd-questions/2008-September/182896.html I used this patch to fix the problem: %%% Index: sys/kern/kern_linker.c === --- sys/kern/kern_linker.c (revision 183486) +++ sys/kern/kern_linker.c (working copy) @@ -1199,7 +1199,12 @@ kldstat(struct thread *td, struct kldsta td-td_retval[0] = 0; - return (copyout(stat, uap-stat, sizeof(struct kld_file_stat))); + if (version_num == 1) + return (copyout(stat, uap-stat, + sizeof(struct kld_file_stat_1))); + else + return (copyout(stat, uap-stat, + sizeof(struct kld_file_stat))); } int %%% -- Jaakko ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: system hangup - I'm lost
On Mon, 2008-09-29 at 22:14 +0200, Oliver Lehmann wrote: Any idea what I could do to shed some more light on this behaviour? Why it is happening and what really is causing it? Would enabling the kernel debugger really help here? I mean the system is really hanging up - except ping response it is not responding to anything except the reset switch ;) If it's responding to ping, you should be able to get into the debugger. Compile it in, along with options WITNESS and options WITNESS_SKIPSPIN, and press ctrl-alt-escape when the machine next hangs. From there, it should hopefully be possible to get more info. It's been a long time since I've used the debugger under 6.x so some of the more useful commands may not exist, but the output of at least sh locks, sh alllocks and bt on any processes that seem to be holding locks. Also sh pcpu and ps will help to determine exactly what was running at the time. Gavin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: system hangup - I'm lost
Oliver Lehmann wrote: Hi, My fileserver has sporadical hangups running 6.3: FreeBSD 6.3-STABLE #0: Thu Jun 19 00:21:00 CEST 2008 [EMAIL PROTECTED]:/usr/obj/i386-pentium3-6.3/usr/src/sys/NUDEL The exact release doesn't matter since it happened before. It always happens afer some time of having some load on the system (I'm building ports with tinderbox and during the build process it just hangs up). The system does nothing write out on the console, neither the CRT, nor the serial console. The system itself is: CPU: Intel Pentium III (845.64-MHz 686-class CPU) Origin = GenuineIntel Id = 0x683 Stepping = 3 Features=0x387fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,PN,MMX,FXSR,SSE real memory = 805240832 (767 MB) avail memory = 778481664 (742 MB) ACPI APIC Table: Intel N440BX FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 1 cpu1 (AP): APIC ID: 0 ioapic0 Version 1.1 irqs 0-23 on motherboard while the diskspace is provided by an 3ware RAID: twa0: 3ware 9000 series Storage Controller port 0x2400-0x24ff mem 0xf4101000-0xf41010ff,0xf480-0xf4ff irq 18 at device 11.0 on pci0 twa0: INFO: (0x04: 0x0053): Battery capacity test is overdue: twa0: INFO: (0x15: 0x1300): Controller details:: Model 9500S-4LP, 4 ports, Firmware FE9X 2.08.00.009, BIOS BE9X 2.03.01.052 da0 at twa0 bus 0 target 0 lun 0 da0: AMCC 9500S-4LP DISK 2.08 Fixed Direct Access SCSI-3 device da0: 100.000MB/s transfers da0: 715224MB (1464778752 512 byte sectors: 255H 63S/T 91178C) I had - in the past - sometimes messages left which where indicating, that the system was not able to allocate swap space fast enough if I recall it correctly (_not_ out of swap space!) but the RAID is kinda fast imho. Any idea what I could do to shed some more light on this behaviour? Why it is happening and what really is causing it? Would enabling the kernel debugger really help here? I mean the system is really hanging up - except ping response it is not responding to anything except the reset switch ;) Greetings, Oliver Personally I'd rather bet on some hardware problem (overheating?) Try to install mbmon from ports. I had also similiar problems with old motherboards with swelled capacitors. -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: system hangup - I'm lost
On Tue, 30 Sep 2008, Gavin Atkinson wrote: On Mon, 2008-09-29 at 22:14 +0200, Oliver Lehmann wrote: Any idea what I could do to shed some more light on this behaviour? Why it is happening and what really is causing it? Would enabling the kernel debugger really help here? I mean the system is really hanging up - except ping response it is not responding to anything except the reset switch ;) If it's responding to ping, you should be able to get into the debugger. Compile it in, along with options WITNESS and options WITNESS_SKIPSPIN, and press ctrl-alt-escape when the machine next hangs. From there, it should hopefully be possible to get more info. It's been a long time since I've used the debugger under 6.x so some of the more useful commands may not exist, but the output of at least sh locks, sh alllocks and bt on any processes that seem to be holding locks. Also sh pcpu and ps will help to determine exactly what was running at the time. show lockedvnods is also quite useful if the problem originates in the file system, as it lists vnodes that have been locked, and by which threads. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: recommended setup for amd64 7-STABLE with ZFS, Samba 3.2 and possibly ACLs?
On Tue, Sep 30, 2008 at 12:08:48PM +0200, Holger Kipp wrote: could anyone give recommendations (or share experience) regarding using ZFS: - FreeBSD 7-Stable (amd64 with 8GB RAM) + special tuning necessary (apart from increasing kernel memory to 1 or more GB for ZFS) Applicable loader.conf variables which should suffice: vm.kmem_size=1536M vm.kmem_size_max=1536M vfs.zfs.arc_min=16M vfs.zfs.arc_max=64M vfs.zfs.prefetch_disable=1 You can increase arc_max gradually, and performance should increase as you do so. Just be aware that too large of a value could result in kmem exhaustion on RELENG_7. There is a 2GB limit on kmem on RELENG_7 (yes, both i386 AND amd64), so do not try to increase vm.kmem_size or kmem_size_max above what I've shown there (others may have chosen something slightly higher, but picking 2048M will cause the system not to boot). If the limit is a problem, consider running CURRENT which increases this to 512GB. The prefetch setting should improve overall system performance during heavy ZFS load; many of us (including core members) have found this to be true. - email (imap) I've had good experience with dovecot; I tend to stay away from Cyrus products (disgusting code with a history of security issues), and Courier (no interest). -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: system hangup - I'm lost
On Tue, Sep 30, 2008 at 12:39:27PM +0200, Bartosz Stec wrote: Oliver Lehmann wrote: Hi, My fileserver has sporadical hangups running 6.3: FreeBSD 6.3-STABLE #0: Thu Jun 19 00:21:00 CEST 2008 [EMAIL PROTECTED]:/usr/obj/i386-pentium3-6.3/usr/src/sys/NUDEL The exact release doesn't matter since it happened before. It always happens afer some time of having some load on the system (I'm building ports with tinderbox and during the build process it just hangs up). The system does nothing write out on the console, neither the CRT, nor the serial console. The system itself is: CPU: Intel Pentium III (845.64-MHz 686-class CPU) Origin = GenuineIntel Id = 0x683 Stepping = 3 Features=0x387fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,PN,MMX,FXSR,SSE real memory = 805240832 (767 MB) avail memory = 778481664 (742 MB) ACPI APIC Table: Intel N440BX FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 1 cpu1 (AP): APIC ID: 0 ioapic0 Version 1.1 irqs 0-23 on motherboard while the diskspace is provided by an 3ware RAID: twa0: 3ware 9000 series Storage Controller port 0x2400-0x24ff mem 0xf4101000-0xf41010ff,0xf480-0xf4ff irq 18 at device 11.0 on pci0 twa0: INFO: (0x04: 0x0053): Battery capacity test is overdue: twa0: INFO: (0x15: 0x1300): Controller details:: Model 9500S-4LP, 4 ports, Firmware FE9X 2.08.00.009, BIOS BE9X 2.03.01.052 da0 at twa0 bus 0 target 0 lun 0 da0: AMCC 9500S-4LP DISK 2.08 Fixed Direct Access SCSI-3 device da0: 100.000MB/s transfers da0: 715224MB (1464778752 512 byte sectors: 255H 63S/T 91178C) I had - in the past - sometimes messages left which where indicating, that the system was not able to allocate swap space fast enough if I recall it correctly (_not_ out of swap space!) but the RAID is kinda fast imho. Any idea what I could do to shed some more light on this behaviour? Why it is happening and what really is causing it? Would enabling the kernel debugger really help here? I mean the system is really hanging up - except ping response it is not responding to anything except the reset switch ;) Greetings, Oliver Personally I'd rather bet on some hardware problem (overheating?) Try to install mbmon from ports. I had also similiar problems with old motherboards with swelled capacitors. Be careful with mbmon and healthd -- just because they compile and run does not mean they're working properly (the values shown may be completely unreliable/incorrect). It's best to check such things in the system BIOS, unless you have absolute certainty that your motherboard is supported by mbmon/healthd. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
GELI partition mount on boot fails after 7.0 - 7.1-PRERELEASE upgrade
I was using a GELI partition for /usr/home on 7.0, so it attaches and mounts on boot. The problem is it stopped working after the system was upgraded to RELENG_7/7.1-PRERELEASE. Here's how it goes: I have the following /etc/fstab: /dev/ad0s1b noneswapsw 0 0 /dev/ad0s1a / ufs rw 1 1 /dev/ad0s1d /tmpufs rw 2 2 /dev/ad0s1e /varufs rw 2 2 /dev/ad0s1f.eli /usr/home ufs rw 2 2 After upgrading to 7.1 and rebooting: ... Configuring Disk Encryption for ad0s1f. Enter passphrase: geli: Cannot access ad0s1f (error=1). Attach failed; attempt 1 of 3. Enter passphrase: geli: Wrong key for ad0s1f. Attach failed; attempt 2 of 3. Enter passphrase: geli: Wrong key for ad0s1f. ... (the key entered is actually valid and attaching succeeds on 7.0 at this point). As far as mounting failed i'm entering the single-user mode, where geli attach /dev/ad0s1f works perfectly: GEOM_ELI: Device ad0s1f.eli created. GEOM_ELI: Encryption: AES-CBC 128 GEOM_ELI: Crypto: software After that exiting back to multi-user mounts the missing /usr/home, so loading completes. -- Regards, Mirya ICQ #313898202 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: jails and mac_seeotheruids problems in 6-STABLE
It works like a charm! Thank you very much for your time and help, regards, Robert Watson wrote: On Tue, 30 Sep 2008, George Mamalakis wrote: I have 3 servers in my lab. 2 of them are running 6-STABLE and one of them is running 7-STABLE. All three have services running in jails. I noticed a very peculiar behavior in 6-STABLE when I set the sysctl security.mac.seeotheruids.enabled=1. The root user in my jails was not able to see processes and sockets owned by other users of the same jail, whereas the root user of the host system could see every process (thank the Almighty). The same behavior does not apply on the server running 7-STABLE. In one sense it is more secure, since the root user in a jail is not as strong as the root user should be in a UNIX system. On the other hand, the root user looses its purpose of existence, which I suppose is a bug. Below are the security.mac sysctl settings of both 6 and 7-STABLE: Could you try modifying src/sys/security/mac_seeotheruids/mac_seeotheruids.c in a 6.x tree so that the call to suser_cred() in mac_seeotheruids_check() passes the SUSER_ALLOWJAIL flag rather than 0? This may correct the problem you're experiencing. Let me know and I can merge that change to 6.x. Robert N M Watson Computer Laboratory University of Cambridge 6-STABLE: security.mac.max_slots: 4 security.mac.enforce_network: 1 security.mac.enforce_pipe: 1 security.mac.enforce_posix_sem: 1 security.mac.enforce_suid: 1 security.mac.mmap_revocation_via_cow: 0 security.mac.mmap_revocation: 1 security.mac.enforce_vm: 1 security.mac.enforce_process: 1 security.mac.enforce_socket: 1 security.mac.enforce_system: 1 security.mac.enforce_kld: 1 security.mac.enforce_sysv_msg: 1 security.mac.enforce_sysv_sem: 1 security.mac.enforce_sysv_shm: 1 security.mac.enforce_fs: 1 security.mac.seeotheruids.specificgid: 0 security.mac.seeotheruids.specificgid_enabled: 0 security.mac.seeotheruids.primarygroup_enabled: 0 security.mac.seeotheruids.enabled: 1 security.mac.portacl.rules: uid:80:tcp:80,uid:80:tcp:443 security.mac.portacl.port_high: 1023 security.mac.portacl.autoport_exempt: 1 security.mac.portacl.suser_exempt: 1 security.mac.portacl.enabled: 1 7-STABLE: security.mac.max_slots: 4 security.mac.version: 3 security.mac.mmap_revocation_via_cow: 0 security.mac.mmap_revocation: 1 security.mac.seeotheruids.specificgid: 0 security.mac.seeotheruids.specificgid_enabled: 0 security.mac.seeotheruids.suser_privileged: 1 security.mac.seeotheruids.primarygroup_enabled: 0 security.mac.seeotheruids.enabled: 1 I would be very glad if someone could inform me whether I am doing something wrong; if not I think I should inform FreeBSD about this bug. Thank you guys in advance, -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: recommended setup for amd64 7-STABLE with ZFS, Samba 3.2 and possibly ACLs?
Holger Kipp wrote: - FreeBSD 7-Stable (amd64 with 8GB RAM) + special tuning necessary (apart from increasing kernel memory to 1 or more GB for ZFS) I haven't had much luck running ZFS under heavy load on 7-stable, I was forced to install 8-current and use the latest patch set posted by pjd. Don't jump in until you've tested it with a realistic production load. The nice thing was that 8-current didn't require any special kernel or memory tuning at all (except for disabling ZIL, but not everyone seems to have to do this). - Samba 3.2 + ACLs possible directly under ZFS? As far as I know ZFS does not support ACLs under FreeBSD at this time, and implementing it is non-trivial. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.1-PRERELEASE : bad network performance (nfe0)
Robert Watson [EMAIL PROTECTED] writes: On Mon, 29 Sep 2008, Arno J. Klaassen wrote: However, the request/respones tests are awfull for my notebook (test repeated on the notebook for the sake of conviction) : Is it possible to rerun these tests with a 7.0 kernel of the same general configuration? That would help us determine if it's a regression between 7.0 and 7.1, 7.0-RELEASE-p4 kernel (and 7.1 world) as well as 7.0-RELEASE life-cd give same results : great streaming, very poor request/response or perhaps a more general issue between 6.x and 7.x. nve(4) does not recognise this chip. If someone does have a bootable 6-stable .iso with a backported nfe(4) ... or email if_nfe.ko to me and I will tes under 6-stable For now I will test the patches Pyun and Luigi sent me and let you know. Best, arno ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.1-PRERELEASE : bad network performance (nfe0)
On Tue, 30 Sep 2008, Arno J. Klaassen wrote: However, the request/respones tests are awfull for my notebook (test repeated on the notebook for the sake of conviction) : Is it possible to rerun these tests with a 7.0 kernel of the same general configuration? That would help us determine if it's a regression between 7.0 and 7.1, 7.0-RELEASE-p4 kernel (and 7.1 world) as well as 7.0-RELEASE life-cd give same results : great streaming, very poor request/response Thanks for testing this -- it rules out a host of potential issues that could have been from changes in flight between 7.0 and 7.1, which is very helpful. At least for me, since I made many of those changes :-). or perhaps a more general issue between 6.x and 7.x. nve(4) does not recognise this chip. If someone does have a bootable 6-stable .iso with a backported nfe(4) ... or email if_nfe.ko to me and I will tes under 6-stable For now I will test the patches Pyun and Luigi sent me and let you know. OK. I'll drop out of the loop on this one unless it's determined that the network stack itself is implicated rather than the drivers. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DTrace MFC broke kldstat(2) on RELENG_7
On Tuesday 30 September 2008 06:15:59 am Jaakko Heinonen wrote: Hi, I recently noticed that kldstat(8) started to dump core for me on RELENG_7. I traced the problem down to kldstat(2). r182231 (DTrace MFC) introduced a new version of kld_file_stat struct and added some code to support the old version of the structure in kldstat(). In the new code the old structure is known as kld_file_stat_1. Unfortunately there's a bug in this code: kldstat() copies always sizeof(struct kld_file_stat) of data to user space while it should copy sizeof(struct kld_file_stat_1) when the old struct is used. This guy is probably suffering from this problem too: http://lists.freebsd.org/pipermail/freebsd-questions/2008-September/182896.html I used this patch to fix the problem: %%% Index: sys/kern/kern_linker.c === --- sys/kern/kern_linker.c(revision 183486) +++ sys/kern/kern_linker.c(working copy) @@ -1199,7 +1199,12 @@ kldstat(struct thread *td, struct kldsta td-td_retval[0] = 0; - return (copyout(stat, uap-stat, sizeof(struct kld_file_stat))); + if (version_num == 1) + return (copyout(stat, uap-stat, + sizeof(struct kld_file_stat_1))); + else + return (copyout(stat, uap-stat, + sizeof(struct kld_file_stat))); } int %%% This is what is in HEAD and should fix it: Index: kern_linker.c === --- kern_linker.c (revision 183497) +++ kern_linker.c (working copy) @@ -1199,7 +1199,7 @@ td-td_retval[0] = 0; - return (copyout(stat, uap-stat, sizeof(struct kld_file_stat))); + return (copyout(stat, uap-stat, version)); } I will send in a request to MFC it in a second. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: system hangup - I'm lost
On Monday 29 September 2008 04:14:08 pm Oliver Lehmann wrote: Hi, My fileserver has sporadical hangups running 6.3: FreeBSD 6.3-STABLE #0: Thu Jun 19 00:21:00 CEST 2008 [EMAIL PROTECTED]:/usr/obj/i386-pentium3-6.3/usr/src/sys/NUDEL The exact release doesn't matter since it happened before. It always happens afer some time of having some load on the system (I'm building ports with tinderbox and during the build process it just hangs up). The system does nothing write out on the console, neither the CRT, nor the serial console. 1) Setup support for crashdumps. 2) Add 'DDB' and 'KDB' to your kernel. When it hangs, break into the debugger (CTRL+ALT+ESC) and run 'panic' to generate a crash dump. 3) ps -axl -M /var/crash/vmcore.X -N /boot/kernel/kernel (where vmcore.X is the core file generated, probably vmcore.0). That's the first place to start. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: system hangup - I'm lost
Hi, Jeremy Chadwick wrote: On Tue, Sep 30, 2008 at 12:39:27PM +0200, Bartosz Stec wrote: Personally I'd rather bet on some hardware problem (overheating?) Try to install mbmon from ports. I had also similiar problems with old motherboards with swelled capacitors. Be careful with mbmon and healthd -- just because they compile and run does not mean they're working properly (the values shown may be completely unreliable/incorrect). It's best to check such things in the system BIOS, unless you have absolute certainty that your motherboard is supported by mbmon/healthd. The systems chipset (440GX - board is http://www.intel.com/support/motherboards/server/l440gx/) is not supported by mbmon. All I can check is the temperature of the harddrives and they are between 30 - 45 °C. Which just means nothing for the CPUs ;) make world for example does not break the system down - I only encounter this during my tinderbox runs - who knows what stresses it then that much. I'll now make a kernel with all the debugging stuff in it... -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: system hangup - I'm lost
John Baldwin wrote: (CTRL+ALT+ESC) and run 'panic' to generate a crash dump. problem here is, that after some memory upgrade my swapspace is no longer bigh enough to cover the memory size. I'll try this as a last resort if the interactive work with kdb does not provide any help and will remove some memory before it then... -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GELI partition mount on boot fails after 7.0 - 7.1-PRERELEASE upgrade
On Tue, Sep 30, 2008 at 02:54:45PM +0300, Kyryll A Mirnenko aka Mirya wrote: I was using a GELI partition for /usr/home on 7.0, so it attaches and mounts on boot. The problem is it stopped working after the system was upgraded to RELENG_7/7.1-PRERELEASE. Here's how it goes: I have the following /etc/fstab: /dev/ad0s1b noneswapsw 0 0 /dev/ad0s1a / ufs rw 1 1 /dev/ad0s1d /tmpufs rw 2 2 /dev/ad0s1e /varufs rw 2 2 /dev/ad0s1f.eli /usr/home ufs rw 2 2 After upgrading to 7.1 and rebooting: ... Configuring Disk Encryption for ad0s1f. Enter passphrase: geli: Cannot access ad0s1f (error=1). Something keeps ad0s1f open, so geli cannot access it. Could you add somewhere 'sysctl -b kern.geom.confxml' (maybe to /etc/rc.d/geli script), so we can see how keeps ad0s1f open. -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgp58zrIJ0xQZ.pgp Description: PGP signature
Re: system hangup - I'm lost
On Tuesday 30 September 2008 10:57:19 am Oliver Lehmann wrote: John Baldwin wrote: (CTRL+ALT+ESC) and run 'panic' to generate a crash dump. problem here is, that after some memory upgrade my swapspace is no longer bigh enough to cover the memory size. I'll try this as a last resort if the interactive work with kdb does not provide any help and will remove some memory before it then... Turn on minidumps. minidumps don't dump all of memory (generally a lot, lot less). -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GELI partition mount on boot fails after 7.0 - 7.1-PRERELEASE upgrade
On Tuesday 30 September 2008 18:43, Artis Caune wrote: Try with hint.kbdmux.0.disabled=1 in loader.conf I've already tried that, but the passphrase is correct (and as from original email: the error message would be different if i simply mistiped it), looks like it's all about some bad combination of GEOM_ options in the kernel, i'm currently tring to guess what actually breaks the stuff. -- Regards, Mirya ICQ #313898202 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GELI partition mount on boot fails after 7.0 - 7.1-PRERELEASE upgrade
On Tue, Sep 30, 2008 at 2:54 PM, Kyryll A Mirnenko aka Mirya [EMAIL PROTECTED] wrote: I was using a GELI partition for /usr/home on 7.0, so it attaches and mounts on boot. The problem is it stopped working after the system was upgraded to RELENG_7/7.1-PRERELEASE. Here's how it goes: Try with hint.kbdmux.0.disabled=1 in loader.conf I have same problem with laptop and also with 6.x whaen it's happened randomly. Try with 'set kern.geom.eli.visible_passphrase=1' and you will see some characters are repeated twice when you press it only once, some are lost. There was some locking issue, and I think it's fixed in current. -- regards, Artis Caune . CCNA | ' didii FreeBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: jails and mac_seeotheruids problems in 6-STABLE
On Tue, 30 Sep 2008, George Mamalakis wrote: It works like a charm! Thank you very much for your time and help, No problem -- I've gone ahead and committed that change to stable/6. If you're able to test 6.4RC1 when it comes out to confirm that the fix works there as desired, that would be most helpful. Thanks, Robert N M Watson Computer Laboratory University of Cambridge regards, Robert Watson wrote: On Tue, 30 Sep 2008, George Mamalakis wrote: I have 3 servers in my lab. 2 of them are running 6-STABLE and one of them is running 7-STABLE. All three have services running in jails. I noticed a very peculiar behavior in 6-STABLE when I set the sysctl security.mac.seeotheruids.enabled=1. The root user in my jails was not able to see processes and sockets owned by other users of the same jail, whereas the root user of the host system could see every process (thank the Almighty). The same behavior does not apply on the server running 7-STABLE. In one sense it is more secure, since the root user in a jail is not as strong as the root user should be in a UNIX system. On the other hand, the root user looses its purpose of existence, which I suppose is a bug. Below are the security.mac sysctl settings of both 6 and 7-STABLE: Could you try modifying src/sys/security/mac_seeotheruids/mac_seeotheruids.c in a 6.x tree so that the call to suser_cred() in mac_seeotheruids_check() passes the SUSER_ALLOWJAIL flag rather than 0? This may correct the problem you're experiencing. Let me know and I can merge that change to 6.x. Robert N M Watson Computer Laboratory University of Cambridge 6-STABLE: security.mac.max_slots: 4 security.mac.enforce_network: 1 security.mac.enforce_pipe: 1 security.mac.enforce_posix_sem: 1 security.mac.enforce_suid: 1 security.mac.mmap_revocation_via_cow: 0 security.mac.mmap_revocation: 1 security.mac.enforce_vm: 1 security.mac.enforce_process: 1 security.mac.enforce_socket: 1 security.mac.enforce_system: 1 security.mac.enforce_kld: 1 security.mac.enforce_sysv_msg: 1 security.mac.enforce_sysv_sem: 1 security.mac.enforce_sysv_shm: 1 security.mac.enforce_fs: 1 security.mac.seeotheruids.specificgid: 0 security.mac.seeotheruids.specificgid_enabled: 0 security.mac.seeotheruids.primarygroup_enabled: 0 security.mac.seeotheruids.enabled: 1 security.mac.portacl.rules: uid:80:tcp:80,uid:80:tcp:443 security.mac.portacl.port_high: 1023 security.mac.portacl.autoport_exempt: 1 security.mac.portacl.suser_exempt: 1 security.mac.portacl.enabled: 1 7-STABLE: security.mac.max_slots: 4 security.mac.version: 3 security.mac.mmap_revocation_via_cow: 0 security.mac.mmap_revocation: 1 security.mac.seeotheruids.specificgid: 0 security.mac.seeotheruids.specificgid_enabled: 0 security.mac.seeotheruids.suser_privileged: 1 security.mac.seeotheruids.primarygroup_enabled: 0 security.mac.seeotheruids.enabled: 1 I would be very glad if someone could inform me whether I am doing something wrong; if not I think I should inform FreeBSD about this bug. Thank you guys in advance, -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: recommended setup for amd64 7-STABLE with ZFS, Samba 3.2 and possibly ACLs?
On Tue, Sep 30, 2008 at 03:46:05AM -0700, Jeremy Chadwick wrote: - email (imap) I've had good experience with dovecot; I tend to stay away from Cyrus products (disgusting code with a history of security issues), and Courier (no interest). Also avoid /usr/ports/mail/imap-uw. I'm not sure if it can be configured to do otherwise, but by default it turns every file in the users home directory into an IMAP folder which can be opened and read. It might sound fine, but if you ever want to migrate off onto something else it becomes an issue. Regards, Gary ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GELI partition mount on boot fails after 7.0 - 7.1-PRERELEASE upgrade
On Tue, Sep 30, 2008 at 02:54:45PM +0300, Kyryll A Mirnenko aka Mirya wrote: I was using a GELI partition for /usr/home on 7.0, so it attaches and mounts on boot. The problem is it stopped working after the system was upgraded to RELENG_7/7.1-PRERELEASE. My GELI encrypted home partition works fine on amd64 7.1-PRERELEASE (updated september 25th). I've been tracking stable since 7.0-RELEASE without problems. My custom kernel includes GEOM_ELI, GEOM_LABEL, GEOM_MIRROR and GEOM_PART_GPT and uses SCHED_ULE. Filesystem options are FFS, SOFTUPDATES, UFS_ACL and UFS_DIRHASH. The ADAPTIVE_GIANT and VFS_AIO options are also part of the kernel. As far as I can see, the geli scripts in /etc/rc.d haven't changed in over a year. HTH, Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgp0Y0NMpYN0Y.pgp Description: PGP signature
Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY
:The topic of BIO_FLUSH is something I got to thinking about last night :at work; the only condition where a disk with write caching enabled :*would not* fully write the data to the platter would in fact be power :loss. All other conditions (specifically soft reset and panic) should :not require explicit flushing. : :I wonder why this is being done, especially on shutdown of FreeBSD. :Assuming I understand it correctly, I'm talking about this: : :Waiting (max 60 seconds) for system process `bufdaemon' to stop...done :Waiting (max 60 seconds) for system process `syncer' to stop... :Syncing disks, vnodes remaining...3 3 3 2 2 0 0 done :All buffers synced. : :-- :| Jeremy Chadwickjdc at parodius.com | BIO_FLUSH and Syncing disks, vnodes ... are two different things, so I'm not sure of the context but I will describe issues with both. -- BIO_FLUSH commands the disk firmware to flush out any dirty buffers in its drive cache. That is, writes that you have *already* issued to the drive and which returned completion, but which have not actually made it to the physical media yet. This is different from dirty buffers still being maintained by the kernel which have not yet been sent to the drive. (Just repeating this so the definition is clear to all the readers). So, yes, you would want to do a BIO_FLUSH before powering down a machine (halt -p) to ensure that all the dirty data you sent to the disk actually gets to the platter. I think you also want to issue it for a soft reset. It would not effect a SATA drive but it certainly would effect a USB drive powered from the computer. USB ports will be powered down during a soft reset. BIO_FLUSH isn't likely to cause problems during a crash, unlike flushing the buffer cache. Some people may remember earlier versions of Windows XP often powered the machine down before the hard drive managed to write all of its data to the platter. Sometime that would even destroy sectors on the drive. We know bad things happen if we don't issue the command, so best not to take chances by making assumptions. -- The Syncing disks, vnodes ... is the kernel flushing out any dirty data in the buffer cache which has not yet been sent to the disk driver. This is more problematic. Filesystems such as HAMMER (and presumably ZFS) absolutely do NOT want the system to flush dirty buffers unless they explicitly give permission to do so, because the dirty buffers might represent data for which the recovery information has not yet been written out, and thus can corrupt the filesystem on-media if a crash were to occur right then. In HAMMER's case I enchanced the bioops a bit to allow HAMMER to veto write-outs initiated by the system. sync_on_panic is irrelevant, the buffers will not be synced without HAMMER's permission and it won't give it. There is also the very real general case where a traditional filesystem such as UFS must peform multiple buffer cache ops, dirtying multiple buffer cache buffers, in order to complete an operation. If a crash were to occur right in the middle of such a sequence the kernel would wind up writing dirty buffers related to incomplete operations to the media, resulting in corruption. In the case of softupdates one is presented with a conundrum. If you don't write out the buffer cache during a crash you stand to lose a lot more then 60 seconds worth of changes due to deep dependancy chains. One 'sync' doesn't do the job and even though it is supposed to get all the primary data and meta-data onto the disk and just leave the bitmap updates for background operations it doesn't always seem to do that. The softupdates code is very fragile. On the other hand, if you *DO* try to write out the buffer cache during a crash you have a good chance of deadlocking the system or double-panicing, resulting in inconsistencies on the media, and you risk doing a partial write out also resulting in inconsistencies on the media. Here is example: How does the crash code deal with dirty but locked buffer cache buffers? Say you have a softupdates filesystem and through the course of operations you dirty a dozen buffers, then a crash occurs while you are in the middle of ANOTHER softupdates operation which is holding several buffers already dirtied by previous operations locked. What happens now if the crash code tries to sync the buffer cache? Will it sync the previously dirtied buffers that are currently locked? Will it sync the ones that haven't been locked but skip the ones that are locked? You lose both ways. There is no way to safely sync ANYTHING, whether locked or not, without risking unexpected softupdates inconsistencies on-media. This alone makes
Re: wpi driver freeze on boot
On Tuesday 30 September 2008, Paul B. Mahol [EMAIL PROTECTED] sent a missive stating: On 9/30/08, Henrik Hudson [EMAIL PROTECTED] wrote: I've got a HP dv8000 laptop. Setting up the wpi driver for wireless freezes the system on boot with the following error: wpi0 requested unsupported memory range wpi0: could not allocate memory resource It lists a pcbi device (pcbi4 i think) and an actual memory range, but since I have to reboot using kernel.old the /var/run/dmesg.boot is wiped with the info. Is there anyway to grab the info when it freezes when it reboots? Perhaps, entering single-user mode. Nope. Disable ACPI, safe-mode and single user don't help at all. Add this lines to your kernel to help debug problem. makeoptions DEBUG=-g options KDB options DDB options GDB options INVARIANTS options INVARIANT_SUPPORT options WITNESS options WITNESS_SKIPSPIN This doesn't really add anything to the output near the wpi freeze and I still can't get to the actual message, since when I reboot it wipes it out. Any other isolation steps or ways to get detailed info to at least a cut and pastable state? Henrik -- Henrik Hudson [EMAIL PROTECTED] -- God, root, what is difference? Pitr; UF (http://www.userfriendly.org/) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: wpi driver freeze on boot
On 9/30/08, Henrik Hudson [EMAIL PROTECTED] wrote: On Tuesday 30 September 2008, Paul B. Mahol [EMAIL PROTECTED] sent a missive stating: On 9/30/08, Henrik Hudson [EMAIL PROTECTED] wrote: I've got a HP dv8000 laptop. Setting up the wpi driver for wireless freezes the system on boot with the following error: wpi0 requested unsupported memory range wpi0: could not allocate memory resource It lists a pcbi device (pcbi4 i think) and an actual memory range, but since I have to reboot using kernel.old the /var/run/dmesg.boot is wiped with the info. Is there anyway to grab the info when it freezes when it reboots? Perhaps, entering single-user mode. Nope. Disable ACPI, safe-mode and single user don't help at all. Ah, I see it, there is no way to look dmesg output in that way because it was never actually saved. Add this lines to your kernel to help debug problem. makeoptions DEBUG=-g options KDB options DDB options GDB options INVARIANTS options INVARIANT_SUPPORT options WITNESS options WITNESS_SKIPSPIN This doesn't really add anything to the output near the wpi freeze and I still This one should put you into kdb when system panics, from where you could post output of bt. can't get to the actual message, since when I reboot it wipes it out. Any other isolation steps or ways to get detailed info to at least a cut and pastable state? In that case you need to enter to kdb as soon as possible during boot, and sidestep each boot instruction until something bad happens, well it is not trivial task at all. For more info you may read developers-hanbook. (Located in /usr/share/doc/en/books/) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: system hangup - I'm lost
On Tue, Sep 30, 2008 at 04:55:34PM +0200, Oliver Lehmann wrote: Hi, Jeremy Chadwick wrote: On Tue, Sep 30, 2008 at 12:39:27PM +0200, Bartosz Stec wrote: Personally I'd rather bet on some hardware problem (overheating?) Try to install mbmon from ports. I had also similiar problems with old motherboards with swelled capacitors. Be careful with mbmon and healthd -- just because they compile and run does not mean they're working properly (the values shown may be completely unreliable/incorrect). It's best to check such things in the system BIOS, unless you have absolute certainty that your motherboard is supported by mbmon/healthd. The systems chipset (440GX - board is http://www.intel.com/support/motherboards/server/l440gx/) is not supported by mbmon. All I can check is the temperature of the harddrives and they are between 30 - 45 °C. Which just means nothing for the CPUs ;) The chipset rarely matters (I've yet to encounter any PC chipset that natively handles full fan, voltage, and temperature monitoring), but the motherboard model can tell me a lot. :-) Boards have to include an external H/W monitoring IC (such as one from National Semiconductor (LMxx), AMD, or Winbond), have thermistors placed around the board, and have the H/W IC tied into the ISA or SMBus. Sometimes the H/W monitoring IC also acts as a super I/O chip (which means it handles serial, parallel, keyboard, mouse, and floppy disks -- and sometimes IDE). I can't find anything on Intel's site that clues me in; all the PDFs are vague as far as what chips are on the board. I tried searching for a high-resolution photo of the L440GX on Google Images, but I find none which are sharp/clear enough. The best I could find was this: http://bbs.yjfy.com/UploadFile/2008-2/20082818545062073.jpg I see Intel northbridge and southbridges, a Cirrus Logic (VGA?) chip, an Intel flash chip (probably for CMOS), and an Intel NIC. Four chips I don't recognise are an Intel chip on the far right, a mystery chip at the bottom of the board (can't make out company logo), and two chips with E in their company logo (right of PCI slots). Possibly one of these handles H/W monitoring. If you can reboot the system and go into the BIOS, see if you can find anything that looks remotely like CPU and system temperatures, as well as voltages. If there's no such menu, the board likely has no support for such. P.S. -- You're the 2nd person I've encountered in under a week who's using 440BX/GX-based hardware in present day. I would not be surprised if the board is simply going bad/failing due to age. :-) -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[FreeBSD] Fix for ServerWorks HT1000 in upcoming 7.1?
Hi, I have a server (Dell PowerEdge SC1435, ServerWorks HT1000) on which I'd like to try installing FreeBSD. I've already failed to make 7.0 work on this box and was wondering if you have information about the behavior of the upcoming 7.1 on this hardware. I've been following the HT1000 chipset errata saga thread, and the commits by sos@ to CVS (around Jan 2008), but have not seen other more recent posts about this issue ... is it because it's already fixed and working fine for everyone? http://lists.freebsd.org/pipermail/freebsd-current/2007-December/081429.html http://lists.freebsd.org/pipermail/freebsd-current/2008-March/084272.html Thanks in advance for any update on this, -- fernan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [FreeBSD] Fix for ServerWorks HT1000 in upcoming 7.1?
On Tue, Sep 30, 2008 at 06:34:04PM -0300, Fernan Aguero wrote: I have a server (Dell PowerEdge SC1435, ServerWorks HT1000) on which I'd like to try installing FreeBSD. I've already failed to make 7.0 work on this box and was wondering if you have information about the behavior of the upcoming 7.1 on this hardware. Why don't you try a 7.1-PRERELEASE ISO and see if it works for you? ftp://ftp4.freebsd.org/pub/FreeBSD/snapshots/200809/ I've been following the HT1000 chipset errata saga thread, and the commits by sos@ to CVS (around Jan 2008), but have not seen other more recent posts about this issue ... is it because it's already fixed and working fine for everyone? http://lists.freebsd.org/pipermail/freebsd-current/2007-December/081429.html http://lists.freebsd.org/pipermail/freebsd-current/2008-March/084272.html Wow; the 2nd URL there is major/huge. I feel sorry for anyone having to deal with this problem. I'll update my Wiki page to reflect this data; thanks for bringing it (indirectly) to my attention. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: recommended setup for amd64 7-STABLE with ZFS, Samba 3.2 and possibly ACLs?
On Tue, Sep 30, 2008 at 12:51:48PM -0400, Gary Palmer wrote: On Tue, Sep 30, 2008 at 03:46:05AM -0700, Jeremy Chadwick wrote: - email (imap) I've had good experience with dovecot; I tend to stay away from Cyrus products (disgusting code with a history of security issues), and Courier (no interest). Also avoid /usr/ports/mail/imap-uw. Performance on imap-uw is lousy also. -- Clifton -- Clifton Royston -- [EMAIL PROTECTED] / [EMAIL PROTECTED] President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [FreeBSD] Fix for ServerWorks HT1000 in upcoming 7.1?
At 05:34 PM 9/30/2008, Fernan Aguero wrote: I've been following the HT1000 chipset errata saga thread, and the commits by sos@ to CVS (around Jan 2008), but have not seen other more recent posts about this issue ... is it because it's already fixed and working fine for everyone? http://lists.freebsd.org/pipermail/freebsd-current/2008-March/084272.html Yes, we ran into this yesterday on a fresh install using the 7.1 beta CD as it was set to PATA mode by accident. Also, on some earlier BIOS revs, we had to turn off enable USB legacy mode as well as EHCI handoff. By default we set those to disabled as it seems to sometimes create a high interrupt load on the USB bus if its enabled. If you forget to set the mode to SATA, the dmesg will look like Sep 30 13:37:08 dev2 kernel: ad4: DMA limited to UDMA33, device found non-ATA66 cable Sep 30 13:37:08 dev2 kernel: ad4: 152627MB Seagate ST3160815AS 3.AAD at ata2-master UDMA33 and you will indeed get corruption Turning onto normal SATA mode in the BIOS, you should see Sep 30 16:14:15 dev2 kernel: ad4: 152627MB Seagate ST3160815AS 3.AAD at ata2-master SATA150 ... And everything works great. [EMAIL PROTECTED]:1:14:0:class=0x010405 card=0x024a1166 chip=0x024a1166 rev=0x00 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'BCM5785 (HT1000) SATA Native SATA Mode' class = mass storage subclass = RAID cap 07[60] = PCI-X 64-bit supports 133MHz, 512 burst read, 8 split transactions cap 01[90] = powerspec 2 supports D0 D3 current D0 cap 05[a0] = MSI supports 1 message Start with ftp://ftp.freebsd.org//pub/FreeBSD/releases/i386/ISO-IMAGES/7.1/7.1-BETA-i386-disc1.iso ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD?
I think port HAMMER fs to FreeBSD is easier than any other fs like ZFS. Would anybody do this? I do not have the skill or I will do this.:) links: http://www.dragonflybsd.org/hammer/index.shtml http://www.dragonflybsd.org/hammer/hammer.pdf ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD?
On Tue, Sep 30, 2008 at 8:53 PM, lhmwzy [EMAIL PROTECTED] wrote: I think port HAMMER fs to FreeBSD is easier than any other fs like ZFS. Would anybody do this? I do not have the skill or I will do this.:) links: http://www.dragonflybsd.org/hammer/index.shtml http://www.dragonflybsd.org/hammer/hammer.pdf ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] Do you subscribe freebsd-stable? This has bee discussed recently in this list: http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045506.html -- cd /usr/ports/sysutils/life make clean ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD?
On Wed, Oct 1, 2008 at 1:53 AM, lhmwzy [EMAIL PROTECTED] wrote: I think port HAMMER fs to FreeBSD is easier than any other fs like ZFS. Would anybody do this? I do not have the skill or I will do this.:) links: http://www.dragonflybsd.org/hammer/index.shtml http://www.dragonflybsd.org/hammer/hammer.pdf I've been wanting to ask the same question since July 6, 2008 ... http://leaf.dragonflybsd.org/mailarchive/kernel/2008-07/msg00015.html ... specially in the light of the all the effort that went (and goes on) on ZFS ... I, for once, don't care at all about ZFS, but would really like to see HAMMER ported over to FreeBSD (just as much as I'd like to see sysctl hw.sensors framework or so called framework... whereas it comes from Murenin's code or from code with a more FreeBSD feel to it .. or from a better implementation or solution or unameit). But I'm still too new to FreeBSD ... Would really like to see some resources redirected in HAMMER fs direction though ... -- Blessings Gonzalo Nemmi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD?
Guys, please don't start a flamewar. And lhmwzy we discussed this on the DFly lists. It's really up to them... that is, a programmer who has an interest, inclination, and time. It isn't really fair to try to push it. I personally believe that the FreeBSD community as a whole should focus on ZFS for now. It has the momentum and the most interest on their lists. -Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: system hangup - I'm lost
Jeremy Chadwick wrote: I can't find anything on Intel's site that clues me in; all the PDFs are vague as far as what chips are on the board. Have you tried the Product specifications? http://download.intel.com/support/motherboards/server/l440gx/254151-003.pdf Beginning on page 33 (43 of the pdf) It has 3 different Server Management busses. the temperature part is handled within a Baseboard Management Controller. This BMC is implemented using a DS82CL10. Because it is a Server Board it offers a lot of managing features and other nice things like serial console at bootup and system monitoring features... but all unsupported withn FreeBSDs software ;) P.S. -- You're the 2nd person I've encountered in under a week who's using 440BX/GX-based hardware in present day. I would not be surprised if the board is simply going bad/failing due to age. :-) Hm - I'd wonder if this would be the case. I mean I'm using older hardware (Tyan Tsunami S1830S, PII300, DAC960P, RAID-1 2*IBM DFHS S2W) without any problems as router ;) -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: system hangup - I'm lost
On Wed, Oct 01, 2008 at 06:53:09AM +0200, Oliver Lehmann wrote: Jeremy Chadwick wrote: I can't find anything on Intel's site that clues me in; all the PDFs are vague as far as what chips are on the board. Have you tried the Product specifications? No need -- Charles Sprickman sent me high-resolution pictures of all the ICs on the 440GX board, and I was able to identify all of them except a few (and those are obviously bit-latches or gates of some kind, so not important). Here's the list: - National Semiconductor Super I/O chip [1] - Cirrus Logic GD5480 video/VGA chip - Samsung SGRAM module for VGA chip; 16MBytes, 70ns - Intel 82371EB (PIIX4E) chip [2] - Dallas Semiconductor DS80CH11 power management chip - EtronTech SRAM; 256kbit, 15ns - Unknown, looks like flash or DRAM - Intel S82093AA I/O APIC - Octal bit-latch IC - Intel SB21150BC PCI bridge; 66MHz - Intel chip of some kind, can't make it out due to dust - Texas Instrument UCC5638 SCSI terminator - Texas Instrument UCC5638 SCSI terminator - Cypress Semiconductor W48C101 clock chip - Numerous other bit-latching ICs - Cypress Semiconductor 3.3V SDRAM buffering chip; probably used to drive SDRAM DIMMs (system memory) - ??? Model 684702-003; not sure what this does, but is of no interest - Some TI chip, doesn't interest me - 2x California Micro Devices ECP/EPP (parallel port) terminator - Maxim MAX211ECA1, no idea but doesn't interest me [1]: I'll have to look up datasheets on this chip to see if it supports H/W monitoring. [2]: This chip does a **lot**, the most important piece being it drives the entire PCI bus. It *does* support SMBus, but not I2C. Linux lmsensors supports this chip, but I don't know how it supports it. I will need to look up the specs/datasheets on it http://www.lm-sensors.org/browser/lm-sensors/trunk/doc/busses/i2c-piix4 http://download.intel.com/support/motherboards/server/l440gx/254151-003.pdf Beginning on page 33 (43 of the pdf) It has 3 different Server Management busses. the temperature part is handled within a Baseboard Management Controller. This BMC is implemented using a DS82CL10. This tells me very little. :-) Because it is a Server Board it offers a lot of managing features and other nice things like serial console at bootup and system monitoring features... but all unsupported withn FreeBSDs software ;) Really? That's interesting, because Charles Sprickman told me that there is no hardware monitoring information in the BIOS if you go in there. Most motherboards provide that in the BIOS as a centralised place above all else. Either way, I'm going to look into the details. Examining what exactly Linux lm-sensors means by support will be the first step. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD?
Hello Carlos, Tuesday, September 30, 2008, 5:57:06 PM, you wrote: Do you subscribe freebsd-stable? This has bee discussed recently in this list: http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045506.html I wouldn't call it discussion. It was mentioned and then quickly it was forgotten. BTW: Matt Dillon, is the founder of DragonflyBSD, which apparently already supports HAMMER. As far as I know, no actual FreeBSD developer commented in that thread yet. -- Best regards, Derekmailto:[EMAIL PROTECTED] How many of you believe in telekinesis? Raise MY hand! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
