Re: panic: kmem_malloc(16384): kmem_map too small: md-mounted /tmp filled up
On Tue, Feb 27, 2007 at 04:03:30PM -0500, Mikhail Teterin wrote: On Tuesday 27 February 2007 15:53, Alex Kozlov wrote: = Yes, I switched to swap-backed md already. But the malloc-based variety is = currently the _default_ (see /etc/defaults/rc.conf)... = Bad default. Filing a PR. Keep in mind that changing the default can break existing setups. Such setups are likely to be broken anyway, but... E.g., if we drop the -M flag, it will break systems with tons of RAM but little swap using tmpmfs. OTOH, if we add '-o reserve', that will break systems with a too large but mostly unused tmpmfs. A sort of a loud announcement will be needed. By the way, I seem to be the one responsible for the paragraph in rc.conf(5) advocating -M for maximum performance and system stability at low memory conditions. When I wrote it, I thought as follows: were the system low on memory, additional swap activity due to mfs would just make the system start thrashing sooner, while malloc'd mfs would just report ENOSPC. I was unaware of the panic back then. Perhaps it was a misconception, either. I haven't heard of any real pitfalls in swap-backed mfs, and getting ENOSPC on /tmp early is no good. = Creation of a 2Gb malloc-based md should've failed on a machine with = 768Mb of RAM, shouldn't it have? = Only if you set '-o reserve'. Memory for malloc-based md was allocated = dynamically. But malloc can only allocate from RAM, right? So the amount of RAM is the hard limit, which a malloc-based md can not exceed even in theory. This means, md-creation should've failed... In fact, the limit should, of course, be even lower -- and mdmfs should be smart enough to substract the sizes of other kernel memory chunks from the maximum. Since even that would still not be a guarantee against running out, the system should be able to recover gracefully instead of panicing. Do you agree? FWIW, some discussion of the panic is in the audit trail of kern/87255. Irrespective of tmpmfs defaults, this is a way to panic the system with stock tools and without doing something totally stupid like writing junk to /dev/mem. -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: kmem_malloc(16384): kmem_map too small: md-mounted /tmp filled up
On Sun, Mar 04, 2007 at 10:59:46AM +0300, Yar Tikhiy wrote: On Tue, Feb 27, 2007 at 04:03:30PM -0500, Mikhail Teterin wrote: On Tuesday 27 February 2007 15:53, Alex Kozlov wrote: = Yes, I switched to swap-backed md already. But the malloc-based variety is = currently the _default_ (see /etc/defaults/rc.conf)... = Bad default. Filing a PR. Keep in mind that changing the default can break existing setups. Such setups are likely to be broken anyway, but... E.g., if we drop the -M flag, it will break systems with tons of RAM but little swap using tmpmfs. OTOH, if we add '-o reserve', that will break systems with a too large but mostly unused tmpmfs. A sort of a loud announcement will be needed. #sudo swapoff /dev/ad4s2b #swapinfo Device 1K-blocks UsedAvail Capacity #mdconfig -d -u 666 \ mdconfig -a -t swap -s1M -u 666 \ bsdlabel -w /dev/md666 auto \ newfs -U -f 512 -b 4096 -i 512 -m 0 /dev/md666a \ mkdir /tmp/mdtest \ mount /dev/md666a /tmp/mdtest $dd if=/dev/zero of=/tmp/mdtest #df /tmp/mdtest Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/md666a 3561822 3561622 200 100% /tmp/mdtest #dmesg Mar 4 10:20:35 ravenloft kernel: pid 97529 (firefox-bin), uid 1001, was killed: out of swap space Mar 4 10:20:39 ravenloft kernel: pid 79658 (Xorg), uid 0, was killed: out of swap space Mar 4 10:20:40 ravenloft kernel: pid 519 (thunderbird-bin), uid 1001, was killed: out of swap space Ouch, but this is still better than panic. By the way, I seem to be the one responsible for the paragraph in rc.conf(5) advocating -M for maximum performance and system stability at low memory conditions. When I wrote it, I thought as follows: were the system low on memory, additional swap activity due to mfs would just make the system start thrashing sooner, while malloc'd mfs would just report ENOSPC. I was unaware of the panic back then. Perhaps it was a misconception, either. I haven't heard of any real pitfalls in swap-backed mfs, and getting ENOSPC on /tmp early is no good. = Creation of a 2Gb malloc-based md should've failed on a machine with = 768Mb of RAM, shouldn't it have? = Only if you set '-o reserve'. Memory for malloc-based md was allocated = dynamically. But malloc can only allocate from RAM, right? So the amount of RAM is the hard limit, which a malloc-based md can not exceed even in theory. This means, md-creation should've failed... In fact, the limit should, of course, be even lower -- and mdmfs should be smart enough to substract the sizes of other kernel memory chunks from the maximum. Since even that would still not be a guarantee against running out, the system should be able to recover gracefully instead of panicing. Do you agree? FWIW, some discussion of the panic is in the audit trail of kern/87255. Irrespective of tmpmfs defaults, this is a way to panic the system with stock tools and without doing something totally stupid like writing junk to /dev/mem. -- Adios ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portsnap and cvsup for rebuilding world - Which one?
On Sunday 04 March 2007 06:02, Joe Holden wrote: frzburn wrote: Hi everyone, I'm a new FreeBSD user, but a veteran Linux user ;) I'm using FreeBSD 6, and I was wondering while I gave a try to rebuilding ``world'' how to properly synchronize my source. Here's what I mean: Create file: fastest_source.sh --- #/bin/sh csup -h $(fastest_cvsup -q -c us,de,uk,se,no,et,ru ) /usr/share/examples/cvsup/ports-supfile --- Now run it: # sh fastest_source.sh -=(oo)=(cvsup7.ru.freebsd.org)=- Connected to 195.14.50.21 Updating collection ports-all/cvs .. Change ports-supfile to standard-supfile if you want to update system source from fastest cvs server. You can run this script from cron if you want. Andrei ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portsnap and cvsup for rebuilding world - Which one?
Brandon S. Allbery KF8NH wrote: On Mar 3, 2007, at 22:23 , frzburn wrote: So here come my questions: Is portsnap syncing the sources correctly for rebuilding world, or must I use cvsup? If so, of what use is portsnap if I must use cvsup for synchronizing my source? There's more than one way to do it. Which alternative you choose is largely a matter of personal taste, convenience and if it supports the particular features you need. portsnap and csup are only the latest additions to the whole shebang. Before that there was sup -- but support for that has entirely gone now I believe; ctm which was (still is?) a means of receiving CVS deltas via e-mail, as well as such things as anon-cvs and rsync, bittorrent and plain old HTTP or FTP. It's a little out of date; instead of cvsup, you use csup which is in the base system (and only supports updating the base system, hence portsnap). Uh, no. csup will let you grab ports, docs, www or whatever else is available through any of the cvsup collections. Or any other cvsup collections you might choose to create yourself. So long as the output is a checked out tree of stuff, csup operates practically identically to cvsup. The difference comes if you want to replicate an entire cvs repository, for which you still need the original modula-3 based cvsup. Or if you want to serve any sort of cvsup collection -- csup is client side only. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: portsnap and cvsup for rebuilding world - Which one?
On Sun, 04 Mar 2007 04:23:55 +0100, frzburn [EMAIL PROTECTED] wrote: Hi everyone, [cut some text] So here come my questions: Is portsnap syncing the sources correctly for rebuilding world, or must I use cvsup? If so, of what use is portsnap if I must use cvsup for synchronizing my source? In fact, I'm just looking at the most up-to-date/approved/correct technique/tool to synchronize my source for ``rebuilding world'' with the latest sources from FreeBSD-6-STABLE. Read this. It tells you why portsnap is invented. And why cvsup/csup is still better for other things then ports. http://www.daemonology.net/portsnap/ Ronald. -- Ronald Klop Amsterdam, The Netherlands ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some days, it doesn't pay to upgrade ...
Marc G. Fournier wrote: I don't know how critical this is, but I just thought about it ... this is my only system running gmirror ... everything seems fine according ot gmirror status, but maybe something iswron gthere I'm not seeing: You should tell us, in which state those processes hung. It might also be good to use DDB and showalllocks to see if it is a deadlock. I for one had several deadlocks with gmirror on an SMP machine. Ulrich Spoerlein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Clamav-90_2 Lockup with freebsd 6.2
On 01/03/07, Renato Botelho [EMAIL PROTECTED] wrote:
On Thu, Mar 01, 2007 at 02:04:18PM -0500, Daniel Eischen wrote:
On Thu, 1 Mar 2007, Alexander Shikoff wrote:
Hi All,
On Thu, Mar 01, 2007 at 08:32:55AM -0500, Daniel Eischen wrote:
On Thu, 1 Mar 2007, Martin Blapp wrote:
Hi,
Clamd is currently broken with libpthread for some threading-reason.
You definitly need to use libthr (which is still CPU hungry, but
works better).
I don't think it is a problem with libpthread.
FYI: https://wwws.clamav.net/bugzilla/show_bug.cgi?id=307#c8
I have no idea what this bug report says. This link and
any other link I can find to clamav bug reports is not
working or down.
clamav's configure was wrong, using -lpthread -lc_r in freebsd, now it's
fixed on development version.
Anyway, I change it to ${PTHREAD_LIBS} on ports, to respect this var. Before
my last change, REINPLACE_CMD was changing openbsd entry, and it was causing
the problem.
--
Renato Botelho garga @ FreeBSD.org
freebsd @ galle.com.br
GnuPG Key: http://www.FreeBSD.org/~garga/pubkey.asc
Peterson's Admonition:
When you think you're going down for the third time --
just remember that you may have counted wrong.
so now the latest version of the port has same cpu utilisation as 0.88.7?
Chris
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portsnap and cvsup for rebuilding world - Which one?
Well, again, thanks for all your replies! =) After all you told me, I guess this guides describes the right tools to use and the right way for rebuilding world. http://www.bsdguides.org/guides/freebsd/beginners/update_freebsd.php Thanks! frzburn On 3/4/07, Ronald Klop [EMAIL PROTECTED] wrote: On Sun, 04 Mar 2007 04:23:55 +0100, frzburn [EMAIL PROTECTED] wrote: Hi everyone, [cut some text] So here come my questions: Is portsnap syncing the sources correctly for rebuilding world, or must I use cvsup? If so, of what use is portsnap if I must use cvsup for synchronizing my source? In fact, I'm just looking at the most up-to-date/approved/correct technique/tool to synchronize my source for ``rebuilding world'' with the latest sources from FreeBSD-6-STABLE. Read this. It tells you why portsnap is invented. And why cvsup/csup is still better for other things then ports. http://www.daemonology.net/portsnap/ Ronald. -- Ronald Klop Amsterdam, The Netherlands ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portsnap and cvsup for rebuilding world - Which one?
frzburn wrote: Well, again, thanks for all your replies! =) After all you told me, I guess this guides describes the right tools to use and the right way for rebuilding world. http://www.bsdguides.org/guides/freebsd/beginners/update_freebsd.php Thanks! frzburn On 3/4/07, Ronald Klop [EMAIL PROTECTED] wrote: On Sun, 04 Mar 2007 04:23:55 +0100, frzburn [EMAIL PROTECTED] wrote: Hi everyone, [cut some text] So here come my questions: Is portsnap syncing the sources correctly for rebuilding world, or must I use cvsup? If so, of what use is portsnap if I must use cvsup for synchronizing my source? In fact, I'm just looking at the most up-to-date/approved/correct technique/tool to synchronize my source for ``rebuilding world'' with the latest sources from FreeBSD-6-STABLE. Read this. It tells you why portsnap is invented. And why cvsup/csup is still better for other things then ports. http://www.daemonology.net/portsnap/ Ronald. -- Ronald Klop Amsterdam, The Netherlands ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] It might be worth noting you can set KERNCONF in your make.conf and you can just do make kernel instead of make buildkernel make installkernel. it just runs both for you. There's no difference it is just a shorter path (not much though). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Clamav-90_2 Lockup with freebsd 6.2
Hi all, After adding some debug stuff to clamd running with freebsd libpthread.so I found that: looking at the output value of 'ps -auxH | grep clamd | grep -v grep | wc -l' is always staying at 6 threads, but the number of threadpool-thr_alive is going higher and higher. So threadpool-thr_alive isn't decreased and is completly incorrect. In my tests the number of threads with libpthread.so is never going higher than 6 threads. That explains, why a higher load is going to delay all scan operations more and more. With libthr.so the value of threadpool-thr_alive is equal with the output of the ps. It can go very high, but always goes back if no more work is there to do. After the maxthreads limit is reached, clamd becomes completly unresponsive with libpthreads.so. SIGKILL and SIGSTOP don't work because some (unexisting) worker threads block on pthread_cond_timedwait(). Only kill -9 helps. Of course, the counter threadpool-thr_alive is wrong and may cause this problem. Maybe someone with more threads knowledge can help here. I'll now add some debug stuff to see where threadpool-thr_alive is going to be increased and where it is decreased. The strange thing is that this works fine with libthr.so. Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Clamav-90_2 Lockup with freebsd 6.2
Hi, looking at the output value of 'ps -auxH | grep clamd | grep -v grep | wc -l' is always staying at 6 threads, but the number of threadpool-thr_alive is going higher and higher. So threadpool-thr_alive isn't decreased and is completly incorrect. After setting IdleTimeout very low to 5 seconds, the threadpool-thr_alive gets decreased correctly. There are still always 6 threads running, but further threads get cleaned up correctly. IMHO the whole clamd thread management is somehow broken. -- Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Clamav-90_2 Lockup with freebsd 6.2
On Sun, 4 Mar 2007, Martin Blapp wrote: Hi all, After adding some debug stuff to clamd running with freebsd libpthread.so I found that: looking at the output value of 'ps -auxH | grep clamd | grep -v grep | wc -l' is always staying at 6 threads, but the number of threadpool-thr_alive is going higher and higher. So threadpool-thr_alive isn't decreased and is completly incorrect. In my tests the number of threads with libpthread.so is never going higher than 6 threads. That explains, why a higher load is going to delay all scan operations more and more. With libthr.so the value of threadpool-thr_alive is equal with the output of the ps. It can go very high, but always goes back if no more work is there to do. After the maxthreads limit is reached, clamd becomes completly unresponsive with libpthreads.so. SIGKILL and SIGSTOP don't work because some (unexisting) worker threads block on pthread_cond_timedwait(). Only kill -9 helps. Of course, the counter threadpool-thr_alive is wrong and may cause this problem. Maybe someone with more threads knowledge can help here. I'll now add some debug stuff to see where threadpool-thr_alive is going to be increased and where it is decreased. The strange thing is that this works fine with libthr.so. Make sure clamd is checking the return value of pthread_create() for errors. You can also set LIBPTHREAD_PROCESS_SCOPE=yes or LIBPTHREAD_SYSTEM_SCOPE=yes in your environment to force process scope or system scope threads (libpthread only) for clamd. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Clamav-90_2 Lockup with freebsd 6.2
Hi, Make sure clamd is checking the return value of pthread_create() for errors. You can also set LIBPTHREAD_PROCESS_SCOPE=yes or LIBPTHREAD_SYSTEM_SCOPE=yes in your environment to force process scope or system scope threads (libpthread only) for clamd. Yes, it does check the return value. And setting system or process scope doesn't make any difference. As I said, increasing the thread count works, decreading doesn't. -- Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Can't get sound to work!
Hi! I'm unable to get my sound card working =( I first tried kldload snd_ich, since I have a ICH7 chip. But there was no ``installed device'' in /dev/sndstat. So I tried kldload snd_driver, as suggested by the handbook, and I didn't get any result. I also loaded sound.ko before loading snd_driver, without success. I got a Dell Inspiron 6400 (e1505). Here's my uname -a: FreeBSD FronzenMind.FrozenLabs 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Sat Mar 3 13:48:11 EST 2007 root@:/usr/obj/usr/src/sys/MYKERNEL amd64 And my pciconf -l -v (truncated): [EMAIL PROTECTED]:27:0:class=0x040300 card=0x01bd1028 chip=0x27d88086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) High Definition Audio' class= multimedia Thanks! =) frzburn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fork wedging (I think)
On Thursday 01 March 2007 17:35, Daniel O'Connor wrote: in /rescue and use './sysctl' (and other commands in rescue). I think you will still be able to execute static executables in the current directory vis a relative path even if the FS is deadlocked. (As long as your shell isn't trying to write command history to a file). hmm.. I will see if I can maintain an open shell.. Going to be a PITA given the length of time between failures. I just logged in OK as it's done it again. Unfortunately it has a version of ATARAID which doesn't support crash dumps. Argh. I was incrementally dumping sysctl trees and when I got to vm it hung.. eureka:~sysctl vm load: 0.07 cmd: sysctl 72864 [user map] 0.00u 0.00s 0% 852k load: 0.07 cmd: sysctl 72864 [user map] 0.00u 0.00s 0% 852k load: 0.07 cmd: sysctl 72864 [user map] 0.00u 0.00s 0% 852k load: 0.05 cmd: sysctl 72864 [user map] 0.00u 0.00s 0% 852k I tried to reboot in another window but.. eureka:~reboot load: 0.06 cmd: csh 71159 [allproc] 0.03u 0.00s 0% 4652k I am pondering an update to at least the ATA sub system so I can generate a crash dump though. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpl3jJEVgXJd.pgp Description: PGP signature
Re: Can't get sound to work!
On 05/03/07, frzburn [EMAIL PROTECTED] wrote: Hi! I'm unable to get my sound card working =( I first tried kldload snd_ich, since I have a ICH7 chip. But there was no ``installed device'' in /dev/sndstat. So I tried kldload snd_driver, as suggested by the handbook, and I didn't get any result. I also loaded sound.ko before loading snd_driver, without success. I got a Dell Inspiron 6400 (e1505). Here's my uname -a: FreeBSD FronzenMind.FrozenLabs 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Sat Mar 3 13:48:11 EST 2007 root@:/usr/obj/usr/src/sys/MYKERNEL amd64 And my pciconf -l -v (truncated): [EMAIL PROTECTED]:27:0:class=0x040300 card=0x01bd1028 chip=0x27d88086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) High Definition Audio' class= multimedia Intel 82801G is an Intel High Definition Audio (HDA) soundcard. There is no driver for HDA in 6.2. See snd_hda(4) in CURRENT for details. wbr, pluknet Thanks! =) frzburn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fork wedging (I think)
On Monday 05 March 2007 11:36, Daniel O'Connor wrote: I tried to reboot in another window but.. eureka:~reboot load: 0.06 cmd: csh 71159 [allproc] 0.03u 0.00s 0% 4652k Interestingly this process did eventually finish. The system hasn't rebooted yet but perhaps it will eventually. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpsyjhJC0nZ2.pgp Description: PGP signature
Re: Can't get sound to work!
This works! =D Thank you very much! =) frzburn On 3/4/07, pluknet [EMAIL PROTECTED] wrote: On 05/03/07, frzburn [EMAIL PROTECTED] wrote: Hi! I'm unable to get my sound card working =( I first tried kldload snd_ich, since I have a ICH7 chip. But there was no ``installed device'' in /dev/sndstat. So I tried kldload snd_driver, as suggested by the handbook, and I didn't get any result. I also loaded sound.ko before loading snd_driver, without success. I got a Dell Inspiron 6400 (e1505). Here's my uname -a: FreeBSD FronzenMind.FrozenLabs 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Sat Mar 3 13:48:11 EST 2007 root@:/usr/obj/usr/src/sys/MYKERNEL amd64 And my pciconf -l -v (truncated): [EMAIL PROTECTED]:27:0:class=0x040300 card=0x01bd1028 chip=0x27d88086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) High Definition Audio' class= multimedia Intel 82801G is an Intel High Definition Audio (HDA) soundcard. There is no driver for HDA in 6.2. See snd_hda(4) in CURRENT for details. wbr, pluknet Thanks! =) frzburn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: kmem_malloc(16384): kmem_map too small: md-mounted /tmp filled up
On Sun, Mar 04, 2007 at 10:59:46AM +0300, Yar Tikhiy wrote: On Tue, Feb 27, 2007 at 04:03:30PM -0500, Mikhail Teterin wrote: On Tuesday 27 February 2007 15:53, Alex Kozlov wrote: = Yes, I switched to swap-backed md already. But the malloc-based variety is = currently the _default_ (see /etc/defaults/rc.conf)... = Bad default. Filing a PR. Keep in mind that changing the default can break existing setups. Such setups are likely to be broken anyway, but... E.g., if we drop the -M flag, it will break systems with tons of RAM but little swap using tmpmfs. How will it break them? swap backing only touches swap if there is memory pressure, i.e. precisely the situation in which malloc backing will panic. Kris pgppCSU7jpXyz.pgp Description: PGP signature
Re: Can't get sound to work!
Is there any intent to backport that into -STABLE? How ugly would that be to do? -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant Kids Rights Activist http://www.denninger.netMy home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://genesis3.blogspot.comMusings Of A Sentient Mind On Sun, Mar 04, 2007 at 09:31:25PM -0500, frzburn wrote: This works! =D Thank you very much! =) frzburn On 3/4/07, pluknet [EMAIL PROTECTED] wrote: On 05/03/07, frzburn [EMAIL PROTECTED] wrote: Hi! I'm unable to get my sound card working =( I first tried kldload snd_ich, since I have a ICH7 chip. But there was no ``installed device'' in /dev/sndstat. So I tried kldload snd_driver, as suggested by the handbook, and I didn't get any result. I also loaded sound.ko before loading snd_driver, without success. I got a Dell Inspiron 6400 (e1505). Here's my uname -a: FreeBSD FronzenMind.FrozenLabs 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Sat Mar 3 13:48:11 EST 2007 root@:/usr/obj/usr/src/sys/MYKERNEL amd64 And my pciconf -l -v (truncated): [EMAIL PROTECTED]:27:0:class=0x040300 card=0x01bd1028 chip=0x27d88086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) High Definition Audio' class= multimedia Intel 82801G is an Intel High Definition Audio (HDA) soundcard. There is no driver for HDA in 6.2. See snd_hda(4) in CURRENT for details. wbr, pluknet Thanks! =) frzburn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] %SPAMBLOCK-SYS: Matched [EMAIL PROTECTED], message ok %SPAMBLOCK-SYS: Matched [EMAIL PROTECTED], message ok ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ARP problem with 6.2-STABLE Intel PRO/1000 NIC, latest em driver
The Machine: I have a dual Xeon 5130 machine, Supermicro motherboard, with the 82563EB NIC. From dmesg: CPU: Intel(R) Xeon(R) CPU5130 @ 2.00GHz (2000.08-MHz 686-class CPU) cpu0: ACPI CPU on acpi0 em0: Intel(R) PRO/1000 Network Connection Version - 6.2.9 port 0x2000-0x201f mem 0xda00-0xda01 irq 18 at device 0.0 on pci4 The machine has 4G RAM and a 3ware 9000 series RAID controller with 2 drives. pciconf -l says: [EMAIL PROTECTED]:0:0: class=0x02 card=0x15d9 chip=0x10968086 rev=0x01 hdr=0x00 [EMAIL PROTECTED]:0:1: class=0x02 card=0x15d9 chip=0x10968086 rev=0x01 hdr=0x00 The symptom: The machine boots OK, but can only intermittently make netork connections. Eventually determined that it seems to only see a few ARP packets, so it's falling out of other machines' ARP tables, and is often unable to see the replies to its own ARP requests. It does see SOME ARPs though. When it is able to communicate with another machine, it does not appear to drop any packets between them (e.g. I scp'd a 500M file at 300Mbps to this machine). When I run tcpdump -n arp I see a few ARPs, but not many. In a 1-minute period, I saw 3 ARP who-has/reply packets. On a different machine on the same ethernet switch, I saw 225 who-has/reply packets in the same 1-minute period. I've tried different cables, and a different switch. I started with 6.2-RELEASE, and then went to 6.2-STABLE on 3/3/07 to get the latest em driver fixes. I've used SMP and GENERIC kernels. I get the same results in all cases. There are no firewall rules installed. I plugged in a USB ethernet adapter (realtek), and it works straight away. tcpdump -n arp sees the same noise as other machines on that LAN. I read through the recent threads on the em driver, but didn't see any reported symptoms like this. Has anyone seen anything like this? Got any hints for me? Am I doing something stupid? Did I leave out any useful information about my configuration? Thanks, Mark -- Mark Costlow| Southwest Cyberport | Fax: +1-505-232-7975 [EMAIL PROTECTED] | Web: www.swcp.com | Voice: +1-505-232-7992 abq-strange.com -- Interesting photos taken in Albuquerque, NM Last post: Art Is OK...And Dangerous - 2007-03-02 10:27:17 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARP problem with 6.2-STABLE Intel PRO/1000 NIC, latest em driver
On 3/4/07, Mark Costlow [EMAIL PROTECTED] wrote: The Machine: I have a dual Xeon 5130 machine, Supermicro motherboard, with the 82563EB NIC. From dmesg: CPU: Intel(R) Xeon(R) CPU5130 @ 2.00GHz (2000.08-MHz 686-class CPU) cpu0: ACPI CPU on acpi0 em0: Intel(R) PRO/1000 Network Connection Version - 6.2.9 port 0x2000-0x201f mem 0xda00-0xda01 irq 18 at device 0.0 on pci4 The machine has 4G RAM and a 3ware 9000 series RAID controller with 2 drives. pciconf -l says: [EMAIL PROTECTED]:0:0: class=0x02 card=0x15d9 chip=0x10968086 rev=0x01 hdr=0x00 [EMAIL PROTECTED]:0:1: class=0x02 card=0x15d9 chip=0x10968086 rev=0x01 hdr=0x00 The symptom: The machine boots OK, but can only intermittently make netork connections. Eventually determined that it seems to only see a few ARP packets, so it's falling out of other machines' ARP tables, and is often unable to see the replies to its own ARP requests. It does see SOME ARPs though. When it is able to communicate with another machine, it does not appear to drop any packets between them (e.g. I scp'd a 500M file at 300Mbps to this machine). When I run tcpdump -n arp I see a few ARPs, but not many. In a 1-minute period, I saw 3 ARP who-has/reply packets. On a different machine on the same ethernet switch, I saw 225 who-has/reply packets in the same 1-minute period. I've tried different cables, and a different switch. I started with 6.2-RELEASE, and then went to 6.2-STABLE on 3/3/07 to get the latest em driver fixes. I've used SMP and GENERIC kernels. I get the same results in all cases. There are no firewall rules installed. I plugged in a USB ethernet adapter (realtek), and it works straight away. tcpdump -n arp sees the same noise as other machines on that LAN. I read through the recent threads on the em driver, but didn't see any reported symptoms like this. Has anyone seen anything like this? Got any hints for me? Am I doing something stupid? Did I leave out any useful information about my configuration? These are one of our latest NICs, I have had no trouble with these but I'm used to using them on an Intel design, not SuperMicro. First question, do you get the same behavior on both ports? My first guess is that this is a BIOS/management problem. Double check SM website and see if there's any support updates to firmware for the system. I will check at work tomorrow morning to see if anyone else has heard of this. Cheers, Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
