Re: Silicon Image 3132under RELENG_5
On 11/30/05, Brooks Davis [EMAIL PROTECTED] wrote: If the poster actually means 3132, it's an unknown quantity. The 3112 is the piece of junk. Yes, I mean 3132, I suppose it's a brand new model from SiI. lspci -v says: 02:00.0 RAID bus controller: Silicon Image, Inc. SiI 3132 Serial ATA Raid II Controller (rev 01) Subsystem: Silicon Image, Inc. SiI 3132 Serial ATA Raid II Controller Thanks -- Sincerely yours, Juraj Lutter ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
tx underrun ???
Hello all, When having a look at log files on my web servers, I regulary see next output on the 3COM ethernet interfaces : xl1: transmission error: 90 xl1: tx underrun, increasing tx start threshold to 120 bytes xl1: transmission error: 90 xl1: tx underrun, increasing tx start threshold to 180 bytes xl1: promiscuous mode enabled xl1: promiscuous mode disabled Can somebody explain me what it is and if this situation is normal ? Regards Vincent ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Any method to cross build and install to local box
Hello all: As I known FreeBSD has a function called cross-build, which can be build from architecture i386 to Architecture amd64 or wise versa. But I have freebsd 4.11 (it must be i386 arch.) installed on a AMD-64 mechine and upgraded to 5.4 and want upgrade to 6.0 stable then. Can I completely change the OS's arch. via the upgrade process (Not Clean Install) via the following make: make buildworld TARGET_ARCH=AMD64 make buildkernel TARGET_ARCH=AMD64 make installkernel TARGET_ARCH=AMD64 mergemaster -p reboot to single user mode make installworld TARGET_ARCH=AMD64 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
maximum process limit
To all, I am running squid-2.5 STABLE10 on 5.4-RELEASE FreeBSD in production, and I am trying to increase the maximum process size to be 2GB. I have found a few references, however, they are all related to older releases (FreeBSD 3) of FreeBSD. As this server is already in production, I just want to make sure that I am doing the right thing and the 2GB mem size is being supported on the above version. Can I have an option in the kernel option MAXDSIZE=\(2048*1024*1024\) will this option alone change the default maximum process size? Or do I have to edit the login.conf file to override the details as well as the kernel changes? Many thanks Tomas -- tp PRIVACY CONFIDENTIALITY This e-mail is private and confidential. If you have, or suspect you have received this message in error please notify the sender as soon as possible and remove from your system. You may not copy, distribute or take any action in reliance on it. Thank you for your co-operation. Please note that whilst best efforts are made, neither the company nor the sender accepts any responsibility for viruses and it is your responsibility to scan the email and attachments (if any). This e-mail has been automatically scanned for viruses by MessageLabs. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: high CPU load due to powerd
2005/11/29, Marco Calviani [EMAIL PROTECTED]: Hi list, i'm currently running 6.0-RELEASE and i activated powerd as the system power control utility. However, using top, i'm seeing that powerd normally uses nearly 18% of the CPU power, thus consuming energy and battery time (i'm using a laptop). Another point is that i'm seeing also more than one process named powerd. Is this all normal? For example (a part of top): 30397 root1 80 1188K 820K nanslp 3:07 17.14% powerd 2143 root1 80 1188K 820K nanslp 1:25 2.20% powerd 2146 root1 80 1188K 820K nanslp 0:47 1.03% powerd (plus other.) Many thanks in advance, MC Hi, i think this behaviour has been caused by my fault. Trying to modify the power settings i called powerd more than one time thinking of an automatic adjustment; however everytime i press powerd a new process started. Just my fault, sorry, MC ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
cpufreq and changing driver
Hi, having seen on the cpufreq(4) man page that there is more than one driver that is currently supported. In particular having a centrino processor, i would like to use the est driver. Currently, by default, the running driver is the one that comes with acpi (AFAIU), and i'm using powerd to control the cpu frequency in adaptive mode. In particular doing comparison with the linux case in which i have cpufreq with speedstep-centrino driver and the ondemand governor, in this case the system is much more responsive and also the fans runs much more quieter (although i cannot rely on proven data since i don't know any benchmark program). In particular i understood that the ondemand governor responds to the system much faster that powerd is able to do. Is there someone who can share some impression or thoughts? Best regards, MC ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
tx underrun ? (add entry into xl manpage)
Vincent Blondel wrote: Hello all, When having a look at log files on my web servers, I regulary see next output on the 3COM ethernet interfaces : xl1: transmission error: 90 xl1: tx underrun, increasing tx start threshold to 120 bytes xl1: transmission error: 90 xl1: tx underrun, increasing tx start threshold to 180 bytes xl1: promiscuous mode enabled xl1: promiscuous mode disabled Can somebody explain me what it is and if this situation is normal ? Rumours are that these messages are harmless, but if someone can explain these messages properly, it would be nice to add an entry to the DIAGNOSTICS section of the xl manpage (hence, this mail also goes to doc mailinglist) I see these messages too on my router/gateway: xl1: transmission error: 90 xl1: tx underrun, increasing tx start threshold to 120 bytes xl1: transmission error: 90 xl1: tx underrun, increasing tx start threshold to 180 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 120 bytes xl1: transmission error: 90 xl1: tx underrun, increasing tx start threshold to 240 bytes Regards, Rob. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cpufreq and changing driver
On Wed, Nov 30, 2005 at 12:37:43PM +0100, Marco Calviani wrote: Hi, having seen on the cpufreq(4) man page that there is more than one driver that is currently supported. In particular having a centrino processor, i would like to use the est driver. Currently, by default, the running driver is the one that comes with acpi (AFAIU), and i'm using powerd to control the cpu frequency in adaptive mode. You have to load the cpufreq.ko module at boot. Adding that line: cpufreq_load = YES to /boot/loader.conf should be OK. In particular doing comparison with the linux case in which i have cpufreq with speedstep-centrino driver and the ondemand governor, in this case the system is much more responsive and also the fans runs much more quieter (although i cannot rely on proven data since i don't know any benchmark program). In particular i understood that the ondemand governor responds to the system much faster that powerd is able to do. Is there someone who can share some impression or thoughts? powerd need some rework in order to get it working properly. There is one FreeBSD project on that subject if you are interrested. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cpufreq and changing driver
Hi, 2005/11/30, Bruno Ducrot [EMAIL PROTECTED]: You have to load the cpufreq.ko module at boot. Adding that line: cpufreq_load = YES to /boot/loader.conf should be OK. I have that line in that position, and it seems working. The point is that i would like to change the driver and use (AFAIU) a better driver for my system (est). In particular i have: dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 Maybe i didn't understood well: but what i have to do to use the Intel Enhanced SpeedStep driver? powerd need some rework in order to get it working properly. There is one FreeBSD project on that subject if you are interrested. Well, thanks i'm very interested, although i'm not at all experienced in kernel programming I'm not inside this issue, but it would not be possible to emulate the behaviour of the ondemand governor? (sorry if this question makes no sense) Bruno Ducrot Thanks, MC ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.0 on TC1000 (was: wireless, ndis problems on Compaq TC1000 Tablet running 6-STABLE)
On Tuesday 29 November 2005 06:03 pm, Milan Obuch wrote: On Tuesday 29 November 2005 21:39, John Nielsen wrote: After successfully installing FreeBSD 6.0 on a Compaq TC1000 Tablet PC By the way, how did you install 6.0 there? I am working with TC1000 too, but it looks almost impossible to install FreeBSD without keyboard. Just would like to know possibilities - I tried 7.0 but ACPI does not work (does not boot even, only with ACPI disabled). My only obstacle was getting a keyboard attached to the console - by default it would boot up to sysinstall just fine but the keyboard wouldn't work. (It was detected, but not attached.. i.e. caps lock, etc would work but sysinstall wasn't getting any input.) Using a 6.0-BETA or RC disk (I don't remember which one), I wasn't able to get around this. However, using 6.0-RELEASE I was able to use the builtin keyboard by disabling atkbd0 AND atkbdc0 in the loader. Loading the kbdmux module may or may not be helpful--I didn't end up needing it. Once installed (and with sshd running as a backup), I updated to -STABLE and built a custom kernel that does not include atkbdc, atkbd, or psm. It works fine. (And it's especially nice with a VESA 1024x768 mode in syscons.) JN ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: maximum process limit
Tomas Palfi wrote: To all, I am running squid-2.5 STABLE10 on 5.4-RELEASE FreeBSD in production, and I am trying to increase the maximum process size to be 2GB. I have found a few references, however, they are all related to older releases (FreeBSD 3) of FreeBSD. As this server is already in production, I just want to make sure that I am doing the right thing and the 2GB mem size is being supported on the above version. Can I have an option in the kernel option MAXDSIZE=\(2048*1024*1024\) Don't know that you need to backslash the parens there. will this option alone change the default maximum process size? Or do I have to edit the login.conf file to override the details as well as the kernel changes? No, recompiling (and installing) the kernel is all you need to do. David -- It's overkill of course, but you can never have too much overkill. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: maximum process limit
On Wednesday 30 November 2005 12:58, David Landgren wrote: option MAXDSIZE=\(2048*1024*1024\) Don't know that you need to backslash the parens there. No, recompiling (and installing) the kernel is all you need to do. all you need is setting something like this kern.maxdsiz=1073741824 in /boot/loader.conf and reboot the value is the amount in B, 1GB in this case João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
top(1) displaying threads
Hello, From some time in 6.0 and -current top(1) shows by default also the kernel threads. But the top(1) manual page still says that the default behaviour is NOT to show them. Maybe something like this will be enough: --- usr.bin/top/top.local.1 Fri Jul 18 02:56:39 2003 +++ usr.bin/top/top.local.1.fix Wed Nov 30 18:51:35 2005 @@ -3,7 +3,7 @@ .SH DISPLAY OF THREADS The '-H' option will toggle the display of kernel visible thread contexts. -At runtime the 'H' key will toggle this mode. The default is OFF. +At runtime the 'H' key will toggle this mode. The default is ON. .SH DESCRIPTION OF MEMORY Mem: 9220K Active, 1032K Inact, 3284K Wired, 1MB Cache, 2M Buf, 1320K Free ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: top(1) displaying threads
On Wed, Nov 30, 2005 at 06:55:19PM +0200 I heard the voice of Niki Denev, and lo! it spake thus: But the top(1) manual page still says that the default behaviour is NOT to show them. Because it's true. H mode shows the kernel-visible threads INDEPENDENTLY. Of course, it would be neat if we had CPU% accounting for threaded programs... -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: snd_ich and syntax error
On Tue, 29 Nov 2005 19:55:22 -0200 JoaoBR wrote: On Tuesday 29 November 2005 19:03, Kevin Oberman wrote: To get ICH audio to work on my system, I had to include the following in my kernel: # Sound card device smbus device ichsmb device smb device sound device snd_ich nice idea but in my case it doesn't help, still I get pcm0: SiS 7012 port 0x1400-0x14ff,0x1c80-0x1cff irq 18 at device 2.7 on pci0 pcm0: [GIANT-LOCKED] pcm0: Unknown AC97 Codec (id = 0x414c4770) AC97 has some incompatible codecs. Hence: # grep AC97 * | grep snd_ Binary file snd_ich.ko matches Binary file snd_maestro.ko matches Binary file snd_pcm.ko matches Maybe give a try to another kernel module? I am with releng_6 # uname -srm FreeBSD 6.0-RELEASE i386 WBR -- Boris B. Samorodov, Research Engineer InPharmTech Co, http://www.ipt.ru Telephone Internet Service Provider ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: tx underrun ? (add entry into xl manpage)
On Wed, 2005-11-30 at 04:37 -0800, Rob wrote: Vincent Blondel wrote: Hello all, When having a look at log files on my web servers, I regulary see next output on the 3COM ethernet interfaces : xl1: transmission error: 90 xl1: tx underrun, increasing tx start threshold to 120 bytes xl1: transmission error: 90 xl1: tx underrun, increasing tx start threshold to 180 bytes xl1: promiscuous mode enabled xl1: promiscuous mode disabled Can somebody explain me what it is and if this situation is normal ? Rumours are that these messages are harmless, but if someone can explain these messages properly, it would be nice to add an entry to the DIAGNOSTICS section of the xl manpage (hence, this mail also goes to doc mailinglist) I see these messages too on my router/gateway: xl1: transmission error: 90 xl1: tx underrun, increasing tx start threshold to 120 bytes xl1: transmission error: 90 xl1: tx underrun, increasing tx start threshold to 180 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 120 bytes xl1: transmission error: 90 xl1: tx underrun, increasing tx start threshold to 240 bytes This is from the dc(4) man page: dc%d: TX underrun -- increasing TX threshold The device generated a transmit underrun error while attempting to DMA and transmit a packet. This happens if the host is not able to DMA the packet data into the NIC's FIFO fast enough. The driver will dynamically increase the trans- mit start threshold so that more data must be DMAed into the FIFO before the NIC will start transmitting it onto the wire. I'm assuming the explanation also holds true for other drivers (xl, etc.) that issue this warning. Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cpufreq and changing driver
Marco Calviani wrote: Hi, 2005/11/30, Bruno Ducrot [EMAIL PROTECTED]: You have to load the cpufreq.ko module at boot. Adding that line: cpufreq_load = YES to /boot/loader.conf should be OK. I have that line in that position, and it seems working. The point is that i would like to change the driver and use (AFAIU) a better driver for my system (est). In particular i have: dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 Maybe i didn't understood well: but what i have to do to use the Intel Enhanced SpeedStep driver? You should send the full output of sysctl dev.cpu. There is no cpufreq driver (est, acpi_perf, or other) driver running. Perhaps look at your dmesg to see if one is probing/attaching. If you are using acpi and load cpufreq.ko, you've got all the cpufreq drivers in one package. The right one for your platform will automatically probe/attach. powerd need some rework in order to get it working properly. There is one FreeBSD project on that subject if you are interrested. Well, thanks i'm very interested, although i'm not at all experienced in kernel programming I'm not inside this issue, but it would not be possible to emulate the behaviour of the ondemand governor? (sorry if this question makes no sense) I have no idea what you mean by on-demand governor. The only automated control of cpu speed is either by the BIOS (which we can't control) or the TM/TM2 (and that one is heat-based, not load-based). -- Nate ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: top(1) displaying threads
On Wednesday 30 November 2005 11:55 am, Niki Denev wrote: Hello, From some time in 6.0 and -current top(1) shows by default also the kernel threads. But the top(1) manual page still says that the default behaviour is NOT to show them. Maybe something like this will be enough: --- usr.bin/top/top.local.1 Fri Jul 18 02:56:39 2003 +++ usr.bin/top/top.local.1.fix Wed Nov 30 18:51:35 2005 @@ -3,7 +3,7 @@ .SH DISPLAY OF THREADS The '-H' option will toggle the display of kernel visible thread contexts. -At runtime the 'H' key will toggle this mode. The default is OFF. +At runtime the 'H' key will toggle this mode. The default is ON. .SH DESCRIPTION OF MEMORY Mem: 9220K Active, 1032K Inact, 3284K Wired, 1MB Cache, 2M Buf, 1320K Free The manpage is correct. The problem is that kernel threads such as ithreads are really kernel processes currently. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Restarting ntpd on address change
On Tue, 29 Nov 2005, Ian D. Leroux wrote: Greetings, My machine's ip address is assigned by DHCP, and whenever it changes ntpd stops functioning and must be restarted. I gather this behavior will be changed in some future ntpd version, but in the meantime I had added a line to my /etc/dhclient-exit-hooks to restart ntpd every time a new address was obtained: # [...] setup variables for ipcheck if [ -n $new_ip_address ]; then # [...] run ipcheck to update my dyndns /etc/rc.d/ntpd restart fi This seemed work fine on 5.4, but on 6.0 it gives problems at boot. Specifically, I get repeated bad file descriptor errors after my network address is assigned, and running ps after the boot completes shows that there are two ntpd processes running. Killing one of them stops the file descriptor errors. My interpretation of this (for what it's worth) is that an ntpd process gets started before dhclient gets a chance to configure the address (perhaps when the interface initially comes up) and then when the address is assigned the /etc/rc.d/ntpd restart starts a second process, but somehow fails to stop the first one. For now I've removed that line from dhclient-exit-hooks, which avoids the problems at boot time. I have the feeling that I'm not doing the Right Thing here. So is there an accepted (or at least known-good) way of automatically managing the restart of ntpd on address change? Have I found a bug in rc.d worth investigating? Or should I just stick to manual restarts until ntpd stops needing them? Thanks, Ian D. Leroux I needed to solve that same problem and came up with the same solution you did. I saw it work under 5.4 several times when my ISP did maintenance on my upstream router. I've kept the same setup under 6 and haven't noticed any problems yet. I've been fortunate enough to keep my IP address leased since my upgrade to 6, so I haven't truly tested this under 6. Eventually my ISP will do something to make me lose my lease, and if I have any problems then, I'll post. I run pf on this system too. If I don't reset the firewall when I get a new IP address, I lose connectivity. That makes ntpd very upset. Here's what I'm doing in dhclient-exit-hooks to solve both problems: if [ $old_ip_address != $new_ip_address ]; then case $new_ip_address in 10.*) ;; 172.1[6-9].* | 172.2[0-9].* | 172.3[0-1].*) ;; 192.168.*) ;; *) logger -t dhclient IP address changed from $old_ip_address to $new_ip_address resetting pf pfctl -Fa -f /etc/pf.conf logger -t restarting ntpd /etc/rc.d/ntpd restart ;; esac fi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any method to cross build and install to local box
On Wed, Nov 30, 2005 at 06:22:58PM +0800, Paul.LKW wrote: Hello all: As I known FreeBSD has a function called cross-build, which can be build from architecture i386 to Architecture amd64 or wise versa. But I have freebsd 4.11 (it must be i386 arch.) installed on a AMD-64 mechine and upgraded to 5.4 and want upgrade to 6.0 stable then. Can I completely change the OS's arch. via the upgrade process (Not Clean Install) via the following make: make buildworld TARGET_ARCH=AMD64 make buildkernel TARGET_ARCH=AMD64 make installkernel TARGET_ARCH=AMD64 mergemaster -p reboot to single user mode make installworld TARGET_ARCH=AMD64 Search the amd64 archives, this is asked very frequently. Kris pgpCRCFICseKK.pgp Description: PGP signature
Re: top(1) displaying threads
On Wednesday 30 November 2005 20:18, John Baldwin wrote: On Wednesday 30 November 2005 11:55 am, Niki Denev wrote: Hello, From some time in 6.0 and -current top(1) shows by default also the kernel threads. But the top(1) manual page still says that the default behaviour is NOT to show them. Maybe something like this will be enough: --- usr.bin/top/top.local.1 Fri Jul 18 02:56:39 2003 +++ usr.bin/top/top.local.1.fix Wed Nov 30 18:51:35 2005 @@ -3,7 +3,7 @@ .SH DISPLAY OF THREADS The '-H' option will toggle the display of kernel visible thread contexts. -At runtime the 'H' key will toggle this mode. The default is OFF. +At runtime the 'H' key will toggle this mode. The default is ON. .SH DESCRIPTION OF MEMORY Mem: 9220K Active, 1032K Inact, 3284K Wired, 1MB Cache, 2M Buf, 1320K Free The manpage is correct. The problem is that kernel threads such as ithreads are really kernel processes currently. Oh, i see. I was confused by the THR column, but now everything is clear :) Thanks and sorry for the noise. --niki ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[backtrace] (snd_solo) mtx_lock_sleep: recursed on non-recursive mutex
Hi,
In my quest to find an other sound card that works with skype, I
salvaged an ESS Solo-1 (ES1938S H209). Trying to play anything through
it results from pcm channel dead to hard freezes and ,the last time I
got the panic bellow. Any chance to make it work or should I keep
searching ?
FreeBSD it.buh.tecnik93.com 6.0-STABLE FreeBSD 6.0-STABLE #4: Wed Nov 16
15:38:12 EET 2005
Unread portion of the kernel message buffer:
panic: _mtx_lock_sleep: recursed on non-recursive mutex pcm0 @
/usr/src/sys/modules/sound/sound/../../../dev/sound/pcm/sound.c:381
KDB: stack backtrace:
panic(c066692c,c2e194b0,c07eac3f,17d,c2e1f4c0) at panic+0x13a
_mtx_lock_sleep(c2e1f4c0,c2d08000,0,c07eac3f,17d) at _mtx_lock_sleep+0x131
_mtx_lock_flags(c2e1f4c0,0,c07eac3f,17d,0) at _mtx_lock_flags+0xae
pcm_chn_create(c2d99200,c26b1d80,c07eeac4,2,c26b1d80) at pcm_chn_create+0xb5
vchan_create(c26b1d80,8,c07eac3f,bf,3cb) at vchan_create+0x79
pcm_chnalloc(c2d99200,1,3cb,,0) at pcm_chnalloc+0x10c
dsp_open(c2737e00,6,2000,c2d08000,0) at dsp_open+0x20b
giant_open(c2737e00,6,2000,c2d08000,c2737e00) at giant_open+0x4f
devfs_open(ef80ba50,ef80bd04,6) at devfs_open+0x251
VOP_OPEN_APV(c0690540,ef80ba50,c0670b57,ef80ba60,0) at VOP_OPEN_APV+0x73
vn_open_cred(ef80bbc0,ef80bcc0,0,c2d2cb00,3) at vn_open_cred+0x359
vn_open(ef80bbc0,ef80bcc0,0,3,c0679b06) at vn_open+0x33
kern_open(c2d08000,280b99f6,0,6,0) at kern_open+0xd4
open(c2d08000,ef80bd04,c,418,3) at open+0x36
syscall(3b,3b,3b,1021,280b99f6) at syscall+0x13d
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (5, FreeBSD ELF32, open), eip = 0x2819a3f7, esp = 0xbfbfe9ec, ebp =
0xbfbfea18 ---
KDB: enter: panic
Dumping 1023 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 1023MB (261872 pages) 1007 991 975 959 943 927 911 895 879 863 847
831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527
511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207
191 175 159 143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:165
165 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) bt
#0 doadump () at pcpu.h:165
#1 0xc0d7 in db_fncall (dummy1=-276777220, dummy2=0, dummy3=16,
dummy4=0xef80b6f4 ÐÝaÀ\237tfÀ\017ögÀ)
at /usr/src/sys/ddb/db_command.c:492
#2 0xc0444970 in db_command_loop () at /usr/src/sys/ddb/db_command.c:350
#3 0xc0446794 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:221
#4 0xc04f4312 in kdb_trap (type=0, code=0, tf=0xef80b828) at
/usr/src/sys/kern/subr_kdb.c:473
#5 0xc0632697 in trap (frame=
{tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = 256, tf_esi = 1, tf_ebp =
-276776848, tf_isp = -276776876, tf_ebx = 1, tf_edx = 0, tf_ecx = -1066685504,
tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1068548478, tf_cs = 32,
tf_eflags = 646, tf_esp = -1067019002, tf_ss = -1067027503}) at
/usr/src/sys/i386/i386/trap.c:591
#6 0xc06201ca in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc04f3e82 in kdb_enter (msg=0x12 Address 0x12 out of bounds) at
cpufunc.h:60
#8 0xc04d785c in panic (fmt=0x1 Address 0x1 out of bounds) at
/usr/src/sys/kern/kern_shutdown.c:539
#9 0xc04ce231 in _mtx_lock_sleep (m=0xc2e1f4c0, tid=3268444160, opts=0,
file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:490
#10 0xc04ce2ee in _mtx_lock_flags (m=0xc2e1f4c0, opts=8,
file=0xc07eac3f
/usr/src/sys/modules/sound/sound/../../../dev/sound/pcm/sound.c, line=381) at
/usr/src/sys/kern/kern_mutex.c:276
#11 0xc07e7425 in ?? ()
#12 0xc2e1f4c0 in ?? ()
.
---Type return to continue, or q return to quit---q
Quit
(kgdb) l *0xc04ce2ee
0xc04ce2ee is in _mtx_lock_flags (/usr/src/sys/kern/kern_mutex.c:279).
274 WITNESS_CHECKORDER(m-mtx_object, opts | LOP_NEWORDER |
LOP_EXCLUSIVE,
275 file, line);
276 _get_sleep_lock(m, curthread, opts, file, line);
277 LOCK_LOG_LOCK(LOCK, m-mtx_object, opts, m-mtx_recurse,
file,
278 line);
279 WITNESS_LOCK(m-mtx_object, opts | LOP_EXCLUSIVE, file, line);
280 #ifdef MUTEX_PROFILING
281 /* don't reset the timer when/if recursing */
282 if (m-mtx_acqtime == 0) {
283 m-mtx_filename = file;
Thanks,
--
IOnut - Unregistered ;) FreeBSD user
Intellectual Property is nowhere near as valuable as Intellect
BOFH excuse #379:
We've picked COBOL as the language of choice
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cpufreq and changing driver
Hi Nate, 2005/11/30, Nate Lawson [EMAIL PROTECTED]: You should send the full output of sysctl dev.cpu. There is no cpufreq driver (est, acpi_perf, or other) driver running. Perhaps look at your dmesg to see if one is probing/attaching. sysctl dev.cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 1000 dev.cpu.0.freq_levels: 1800/24000 1600/2 1400/18000 1225/15750 1050/13500 1000/16000 875/14000 750/12000 625/1 600/12000 525/10500 450/9000 375/7500 300/6000 225/4500 150/3000 75/1500 and if useful, dmesg | grep -i acpi Features=0xafe9f9bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE acpi0: ACER TM8000 on motherboard acpi0: Power Button (fixed) pci_link0: ACPI PCI Link LNKA irq 6 on acpi0 pci_link1: ACPI PCI Link LNKB irq 10 on acpi0 pci_link2: ACPI PCI Link LNKC irq 6 on acpi0 pci_link3: ACPI PCI Link LNKD irq 6 on acpi0 pci_link4: ACPI PCI Link LNKE irq 10 on acpi0 pci_link5: ACPI PCI Link LNKF irq 0 on acpi0 pci_link6: ACPI PCI Link LNKG irq 0 on acpi0 pci_link7: ACPI PCI Link LNKH irq 10 on acpi0 acpi_ec0: Embedded Controller: GPE 0x1d port 0x62,0x66 on acpi0 Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 cpu0: ACPI CPU on acpi0 acpi_perf0: ACPI CPU Frequency Control on cpu0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0 pci2: ACPI PCI bus on pcib2 acpi_lid0: Control Method Lid Switch on acpi0 acpi_acad0: AC Adapter on acpi0 battery0: ACPI Control Method Battery on acpi0 battery1: ACPI Control Method Battery on acpi0 acpi_button0: Sleep Button on acpi0 acpi_tz0: Thermal Zone on acpi0 atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on acpi0 ppc0: ECP parallel printer port port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 sio0: 16550A-compatible COM port port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio1 port 0x2f8-0x2ff irq 3 drq 1 on acpi0 If you are using acpi and load cpufreq.ko, you've got all the cpufreq drivers in one package. The right one for your platform will automatically probe/attach. It seems that my system has recognized acpi_perf as the appropriate driver. But since my CPU is a dothan type centrino i would like to understand why is not possible to use the est driver. I have no idea what you mean by on-demand governor. The only automated control of cpu speed is either by the BIOS (which we can't control) or the TM/TM2 (and that one is heat-based, not load-based). I was referring to this http://www.intel.com/cd/ids/developer/asmo-na/eng/195910.htm?prn=Y and http://lwn.net/Articles/55589/ introduced in linux kernel 2.6.9 . Just to remind: sorry if this is not applicable to the freeBSD kernel. In the linux case the system is much more responsive to actual user actions in respect to what i'm experiencing with powerd. If i can help in some way in testing i would like to contribute. -- Nate Regards, MC ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cpufreq and changing driver
On Wed, Nov 30, 2005 at 10:05:04AM -0800, Nate Lawson wrote:
Marco Calviani wrote:
Hi,
2005/11/30, Bruno Ducrot [EMAIL PROTECTED]:
You have to load the cpufreq.ko module at boot.
Adding that line:
cpufreq_load = YES
to /boot/loader.conf
should be OK.
I have that line in that position, and it seems working. The point is
that i would like to change the driver and use (AFAIU) a better driver
for my system (est).
In particular i have:
dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=\_PR_.CPU0
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
Maybe i didn't understood well: but what i have to do to use the Intel
Enhanced SpeedStep driver?
You should send the full output of sysctl dev.cpu. There is no
cpufreq driver (est, acpi_perf, or other) driver running. Perhaps look
at your dmesg to see if one is probing/attaching.
If you are using acpi and load cpufreq.ko, you've got all the cpufreq
drivers in one package. The right one for your platform will
automatically probe/attach.
powerd need some rework in order to get it working properly. There
is one FreeBSD project on that subject if you are interrested.
Well, thanks i'm very interested, although i'm not at all experienced
in kernel programming
I'm not inside this issue, but it would not be possible to emulate
the behaviour of the ondemand governor? (sorry if this question makes
no sense)
I have no idea what you mean by on-demand governor. The only
automated control of cpu speed is either by the BIOS (which we can't
control) or the TM/TM2 (and that one is heat-based, not load-based).
The ondemand governor is basically an implemation of the following
algorithm:
There is a counter, say count.
at each given fixed intervall:
if (idle less than a watermark) {
frequency full
reinitialise count to 10
} else if (idle more than another watermark) {
decrement count
if count is 0 {
down one step the frequency
}
else reinitilize count to 10
Note that in the latter case, the down step is performed only
after 10 such comparison. In other word, intervall is ten times
larger for the down side than the full frequency one.
This work well when you can perform, say, 20 to 50 transitions per
second. Otherwise, it is pretty bad.
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cpufreq and changing driver
Bruno Ducrot wrote:
On Wed, Nov 30, 2005 at 10:05:04AM -0800, Nate Lawson wrote:
Marco Calviani wrote:
Hi,
2005/11/30, Bruno Ducrot [EMAIL PROTECTED]:
You have to load the cpufreq.ko module at boot.
Adding that line:
cpufreq_load = YES
to /boot/loader.conf
should be OK.
I have that line in that position, and it seems working. The point is
that i would like to change the driver and use (AFAIU) a better driver
for my system (est).
In particular i have:
dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=\_PR_.CPU0
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
Maybe i didn't understood well: but what i have to do to use the Intel
Enhanced SpeedStep driver?
You should send the full output of sysctl dev.cpu. There is no
cpufreq driver (est, acpi_perf, or other) driver running. Perhaps look
at your dmesg to see if one is probing/attaching.
If you are using acpi and load cpufreq.ko, you've got all the cpufreq
drivers in one package. The right one for your platform will
automatically probe/attach.
powerd need some rework in order to get it working properly. There
is one FreeBSD project on that subject if you are interrested.
Well, thanks i'm very interested, although i'm not at all experienced
in kernel programming
I'm not inside this issue, but it would not be possible to emulate
the behaviour of the ondemand governor? (sorry if this question makes
no sense)
I have no idea what you mean by on-demand governor. The only
automated control of cpu speed is either by the BIOS (which we can't
control) or the TM/TM2 (and that one is heat-based, not load-based).
The ondemand governor is basically an implemation of the following
algorithm:
There is a counter, say count.
at each given fixed intervall:
if (idle less than a watermark) {
frequency full
reinitialise count to 10
} else if (idle more than another watermark) {
decrement count
if count is 0 {
down one step the frequency
}
else reinitilize count to 10
Note that in the latter case, the down step is performed only
after 10 such comparison. In other word, intervall is ten times
larger for the down side than the full frequency one.
This work well when you can perform, say, 20 to 50 transitions per
second. Otherwise, it is pretty bad.
Send me a URL to the datasheet that says Intel implemented this.
That algorithm is basically what powerd does. So just run powerd.
--
Nate
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cpufreq and changing driver
Hi Bruno,
The ondemand governor is basically an implemation of the following
algorithm:
There is a counter, say count.
at each given fixed intervall:
if (idle less than a watermark) {
frequency full
reinitialise count to 10
} else if (idle more than another watermark) {
decrement count
if count is 0 {
down one step the frequency
}
else reinitilize count to 10
Note that in the latter case, the down step is performed only
after 10 such comparison. In other word, intervall is ten times
larger for the down side than the full frequency one.
This work well when you can perform, say, 20 to 50 transitions per
second. Otherwise, it is pretty bad.
Thanks very much!
But i'm not understanding if this high number of transitions are a
problem from the hardware point of view or from the software
implementation in freeBSD?
Best regards,
MC
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cpufreq and changing driver
On Wed, Nov 30, 2005 at 12:23:52PM -0800, Nate Lawson wrote:
Bruno Ducrot wrote:
On Wed, Nov 30, 2005 at 10:05:04AM -0800, Nate Lawson wrote:
Marco Calviani wrote:
Hi,
2005/11/30, Bruno Ducrot [EMAIL PROTECTED]:
You have to load the cpufreq.ko module at boot.
Adding that line:
cpufreq_load = YES
to /boot/loader.conf
should be OK.
I have that line in that position, and it seems working. The point is
that i would like to change the driver and use (AFAIU) a better driver
for my system (est).
In particular i have:
dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=\_PR_.CPU0
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
Maybe i didn't understood well: but what i have to do to use the Intel
Enhanced SpeedStep driver?
You should send the full output of sysctl dev.cpu. There is no
cpufreq driver (est, acpi_perf, or other) driver running. Perhaps look
at your dmesg to see if one is probing/attaching.
If you are using acpi and load cpufreq.ko, you've got all the cpufreq
drivers in one package. The right one for your platform will
automatically probe/attach.
powerd need some rework in order to get it working properly. There
is one FreeBSD project on that subject if you are interrested.
Well, thanks i'm very interested, although i'm not at all experienced
in kernel programming
I'm not inside this issue, but it would not be possible to emulate
the behaviour of the ondemand governor? (sorry if this question makes
no sense)
I have no idea what you mean by on-demand governor. The only
automated control of cpu speed is either by the BIOS (which we can't
control) or the TM/TM2 (and that one is heat-based, not load-based).
The ondemand governor is basically an implemation of the following
algorithm:
There is a counter, say count.
at each given fixed intervall:
if (idle less than a watermark) {
frequency full
reinitialise count to 10
} else if (idle more than another watermark) {
decrement count
if count is 0 {
down one step the frequency
}
else reinitilize count to 10
Note that in the latter case, the down step is performed only
after 10 such comparison. In other word, intervall is ten times
larger for the down side than the full frequency one.
This work well when you can perform, say, 20 to 50 transitions per
second. Otherwise, it is pretty bad.
Send me a URL to the datasheet that says Intel implemented this.
http://www.intel.com/cd/ids/developer/asmo-na/eng/195910.htm?prn=Y
That algorithm is basically what powerd does. So just run powerd.
Indeed.
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cpufreq and changing driver
On Wed, Nov 30, 2005 at 08:05:59PM +, Marco Calviani wrote: Hi Nate, 2005/11/30, Nate Lawson [EMAIL PROTECTED]: You should send the full output of sysctl dev.cpu. There is no cpufreq driver (est, acpi_perf, or other) driver running. Perhaps look at your dmesg to see if one is probing/attaching. sysctl dev.cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 1000 dev.cpu.0.freq_levels: 1800/24000 1600/2 1400/18000 1225/15750 1050/13500 1000/16000 875/14000 750/12000 625/1 600/12000 525/10500 450/9000 375/7500 300/6000 225/4500 150/3000 75/1500 If you are using acpi and load cpufreq.ko, you've got all the cpufreq drivers in one package. The right one for your platform will automatically probe/attach. It seems that my system has recognized acpi_perf as the appropriate driver. But since my CPU is a dothan type centrino i would like to understand why is not possible to use the est driver. Did you load the cpufreq driver at boot time which include the est driver as said before? It will replace the acpi_perf if appropriate. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cpufreq and changing driver
Hi Bruno, 2005/11/30, Bruno Ducrot [EMAIL PROTECTED]: Did you load the cpufreq driver at boot time which include the est driver as said before? It will replace the acpi_perf if appropriate. -- Bruno Ducrot Yes cpufreq is loaded at boot time in /boot/loader.conf .However i don't know how to tell him that i want to load est instead of acpi_perf. Regards, MC ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Reduced java/tomcat performance 6-beta3 - 6-stable ?
Clearly they're not 100% equal, but (100-epsilon)%. Your job is to identify the origin of the epsilon :-) Yea yea ;) Working on it.. Is there a way to force ACPI-safe on the slower system? I'm upgrading BIOSes on both boxes now, even though they seem equal. Then I'll see what ACPI debug output shows me. If you have any other hints or ideas, please let me know... thanks so far. I missed the beginning of this thread so sorry if this is impractical or stupid suggestion but could you swap hard disks between machines? At least that might tell you if it is a hardware/bios or operating system problem. Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cpufreq and changing driver
Marco Calviani wrote: Hi Bruno, 2005/11/30, Bruno Ducrot [EMAIL PROTECTED]: Did you load the cpufreq driver at boot time which include the est driver as said before? It will replace the acpi_perf if appropriate. -- Bruno Ducrot Yes cpufreq is loaded at boot time in /boot/loader.conf .However i don't know how to tell him that i want to load est instead of acpi_perf. est is preferred if supported. But probably est doesn't have a table for his processor so acpi_perf is used. There's nothing wrong with using acpi_perf -- it just gives a BIOS interface to est anyway. You can test this with: hint.acpi_perf.0.disabled=1 This will cause acpi_perf to let est attach. But I suspect est won't. -- Nate ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Trouble with amd64
Since this references 6.0-RELEASE it should have been sent to -stable, or since it references amd64 specifically it should have been sent to -amd64. Rerouting to -stable. On Wed, 23 Nov 2005, Nils Berzins wrote: Hi ! Few days ago I downloaded release 6.0 ISOs, in hope that I will finally be able to run FreeBSD on my home computer. Unfortunately, booting from CD dies with: panic: sym: VTOBUS FAILED ! Is there something I can do to get around this error, or do I just wait for more less stable 7.0 :-( According to the code this panic occurs when there is a problem with the DMA memory management. Typically we see this when the driver is not 64-bit clean, but I'd find that hard to believe with amd64 since the same driver runs on sparc64 fine (and must since many Sun machines have embedded sym controllers). Unfortunately it doesn't help that the sym driver has its own bizarre DMA management. It uses busdma but its kinda bolted on over the old memory-block management. Not going to make it any easier to debug. P.S. I have ASUS A8V-E Deluxe with Athlon 64D. Can we get the dmesg from this system? -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cpufreq and changing driver
On Wed, Nov 30, 2005 at 01:57:42PM -0800, Nate Lawson wrote: Marco Calviani wrote: Hi Bruno, Yes cpufreq is loaded at boot time in /boot/loader.conf .However i don't know how to tell him that i want to load est instead of acpi_perf. est is preferred if supported. But probably est doesn't have a table for his processor so acpi_perf is used. That's the case for any Dothan IIRC. There's nothing wrong with using acpi_perf -- it just gives a BIOS interface to est anyway. indeed. You can test this with: hint.acpi_perf.0.disabled=1 This will cause acpi_perf to let est attach. But I suspect est won't. est need acpi_perf if a dothan or above is in use... On the other hand, the linux driver work for the OP, and that's not acceptable we can't do the same :) Maybe a link to a 'acpidmp -d -t' may help to see a little deeper? Marco, could you send to me privately or better provide a link to this output? Cheers, -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Trouble with amd64
On Wed, Nov 30, 2005 at 02:05:55PM -0800, Doug White wrote: On Wed, 23 Nov 2005, Nils Berzins wrote: Hi ! Few days ago I downloaded release 6.0 ISOs, in hope that I will finally be able to run FreeBSD on my home computer. Unfortunately, booting from CD dies with: panic: sym: VTOBUS FAILED ! Is there something I can do to get around this error, or do I just wait for more less stable 7.0 :-( According to the code this panic occurs when there is a problem with the DMA memory management. Typically we see this when the driver is not 64-bit clean, but I'd find that hard to believe with amd64 since the same driver runs on sparc64 fine (and must since many Sun machines have embedded sym controllers). Unfortunately it doesn't help that the sym driver has its own bizarre DMA management. It uses busdma but its kinda bolted on over the old memory-block management. Not going to make it any easier to debug. sym(4) devices don't work on amd64. I sent one to scottl a while ago, but the release has kept him busy. If someone else want's to take a shot at it, you can get LSI-Logic sym(4) cards for $40 or less if you get a minimal white box OEM card. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgpcRtu7hTnpo.pgp Description: PGP signature
Re: Trouble with amd64
On Wed, Nov 30, 2005 at 03:24:08PM -0800, Brooks Davis wrote: sym(4) devices don't work on amd64. If the OP would please send a PR about this, it would at least let other folks know that the problem exists. This is probably also a good idea for whatever other drivers are not 64-bit clean (I do not know of anyplace else we are tracking that issue, e.g. a project page?) mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Restarting ntpd on address change
On Wed, 2005-11-30 at 10:55 -0800, Luke Dean wrote: On Tue, 29 Nov 2005, Ian D. Leroux wrote: I had added a line to my /etc/dhclient-exit-hooks to restart ntpd every time a new address was obtained: [...] This seemed work fine on 5.4, but on 6.0 it gives problems at boot. Specifically, I get repeated bad file descriptor errors after my network address is assigned, and running ps after the boot completes shows that there are two ntpd processes running. [...] I needed to solve that same problem and came up with the same solution you did. I saw it work under 5.4 several times when my ISP did maintenance on my upstream router. I've kept the same setup under 6 and haven't noticed any problems yet. I've been fortunate enough to keep my IP address leased since my upgrade to 6, so I haven't truly tested this under 6. Eventually my ISP will do something to make me lose my lease, and if I have any problems then, I'll post. Thanks for the second opinions and the tricks. I'll give it another try when I have a moment and report back if anything interesting and reproducible happens. Cheers, Ian D. Leroux ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD unstable on Dell 1750 using SMP?
This is encouraging - it's the first I've heard of someone who has found a way to trigger the problem on demand. The problems I was experiencing were on a dual Xeon with HTT enabled as well.Perhaps someone out there who knows much more about the inner workings of FreeBSD may have an idea of why running top in aggressive mode like this might trigger the random rebooting. In particular, it would be nice to *know* that someone out there specifically fixed whatever is wrong in 5.4 when bringing it to 6.0. It's encouraging that you haven't had any problems since upgrading to 6.0, but I have to wonder if the bug's actually fixed, or the specific trigger of running top doesn't trigger the problem but the problem is still lurking in the background waiting to strike with the right combination of events. In any case, I'm anxious to try it out myself on our server to see if top -s0 brings it down on command with HTT enabled, and not with HTT disabled. But I'm going to have to wait until some time over the Christmas holidays to do that sort of experimentation at a time when it isn't affecting the end users of the machine. I may also upgrade to 6.0 at that time, since by then it will have been out for a couple of months, so most of the worst quirks should be worked out by then. In the meantime, disabling HTT as I've done seems like a reasonable precaution to improve the stability.. Thanks for your help! Dan On Nov 29, 2005, at 10:50 PM, Stephen Montgomery-Smith wrote: Dan Charrois wrote: It actually may be a comfort, since perhaps HTT is related to the culprit. Since the last crash, about a month ago, I disabled HTT, both in the kernel as well in the BIOS. So as far as I know, it's completely been disabled (and the boot messages and top only show 2 CPUs). And I haven't had the system go down for nearly a month now. I don't know if it is related, but I used to have random reboots on a dual Xeon system with HTT enabled. It happened when I ran a CPU intensive threaded program at the same time as top - running top -s0 (which you have to do as root) could usually kill the machine in seconds if not minutes. All I can tell you is that with FreeBSD 6.0 the problem disappeared. Well not totally - I still get a bunch of harmless calcru negative messages, although I don't know if it is actually related to the boot problems I used to have with FreeBSD 5.4, because I get the calcru backwards messages even with HTT disabled. Anyway, if you are in the mood to try it out, you might like to try re-enabling HTT, starting up whatever process you usually use (I'm guessing it is MySQL), and then run top -s0. If you get a crash soon after that, you have the same problem I had. Let me also add that these crashes usually did not trigger a crash dump (I had dumpon set), and when it did the resulting dump looked rather corrupted. Stephen -- Syzygy Research Technology Box 83, Legal, AB T0G 1L0 Canada Phone: 780-961-2213 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
error after updated perl5.8 from 5.8.6 to 5.8.7
on FreeBSD srim.hn.org 6.0-STABLE FreeBSD 6.0-STABLE #0: Tue Nov 15 11:01:02 CST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NUCLEUS i386 have done 'perl-after-upgrade' according to 20050624: AFFECTS: users of lang/perl5.8 AUTHOR: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] lang/perl5.8 has been updated to 5.8.7. You should update everything depending on perl. The easiest way to do that is to use perl-after-upgrade script supplied with lang/perl5.8. Please see its manual page for details. but when executing: srim# cd /usr/ports/www/mod_perl2 srim# make install clean rehash NOTE: Version 2.0.0-RC5 and higher of mod_perl significantly change the API - old code *will* break! See http://perl.apache.org/docs/2.0/rename.html Hit Ctrl-C to abort now, if this is of concern. === Vulnerability check disabled, database not found === Extracting for mod_perl2-2.0.2,2 = MD5 Checksum OK for mod_perl-2.0.2.tar.gz. = No SHA256 checksum recorded for mod_perl-2.0.2.tar.gz. === mod_perl2-2.0.2,2 depends on file: /usr/local/bin/perl5.8.7 - found === Patching for mod_perl2-2.0.2,2 === mod_perl2-2.0.2,2 depends on file: /usr/local/bin/perl5.8.7 - found === Applying FreeBSD patches for mod_perl2-2.0.2,2 === mod_perl2-2.0.2,2 depends on file: /usr/local/sbin/apxs - found === mod_perl2-2.0.2,2 depends on file: /usr/local/bin/perl5.8.7 - found === mod_perl2-2.0.2,2 depends on file: /usr/local/sbin/apxs - found === Configuring for mod_perl2-2.0.2,2 /libexec/ld-elf.so.1: /usr/local/lib/perl5/site_perl/5.8.7/mach/auto/Cwd/Cwd.so: Undefined symbol Perl_Gthr_key_ptr *** Error code 1 Stop in /usr/ports/www/mod_perl2. srim# it can't make mod_perl2, the key error is Undefined symbol Perl_Gthr_key_ptr, what this meaning? and how to correct it? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: error after updated perl5.8 from 5.8.6 to 5.8.7
Hi, On 12/1/05, Zhang Qing [EMAIL PROTECTED] wrote: on FreeBSD srim.hn.org 6.0-STABLE FreeBSD 6.0-STABLE #0: Tue Nov 15 11:01:02 CST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NUCLEUS i386 have done 'perl-after-upgrade' according to I'd also do 'portupgrade -fr perl\*' after a perl upgrade if I have seen some problem... Cheers, -- Xin LI [EMAIL PROTECTED] http://www.delphij.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Reduced java/tomcat performance 6-beta3 - 6-stable ?
Some apps that use of frequent queries of the system time for example MySQL are well known in FreeBSD to be slower then Linux because its more expensive to call compared to Linux, maybe Tomcat is also another such app this can also be double the case depending on on your jsp and servlet code. If you are on good hardware, are using 6 and keep your systems time updated via ntp you might want to try changing from kern.timecounter.hardware: ACPI-fast to TSC(-100) and doing a benchmark this has already proven to increase performance of MySQL by a significantly amount. Also some new experimental low-precision time code has been added to current source tree to see how much performance increases can be gained, weirdly enough some people have argued against it for I guess a wide range of reasons such as they just have crap hardware and don't care about performance, don't like the extra maintenance of code or just like Red Hat fanatics having an easy way to bad mouth FreeBSD performance. I think most people would agree though that it has to be done, or have to choose to believe FreeBSD isn't about performance among other goals. With 6 you can also use the new thr threading library, try your libmap.conf to libthr for testing, for example [/usr/local/jdk1.4.2/] libpthread.so.2 libthr.so.2 libpthread.so libthr.so I been doing some 'ab' testing libthr with Apache2 compiled for worker MPM and have some really interesting differences on server load, loads of about 40 for pthread and around 5 thr under certain tests with ab with the exact same test. Mike Eirik Øverby wrote: Update: The diff below was made after making sure both systems are running the exact same kernel. Behavior is the same. Building new kernels (6-STABLE) now to get out of the BETA stage. /Eirik On Nov 28, 2005, at 22:53 , Eirik Øverby wrote: Firmware versions are equal. BIOS settings are equal. However, a diff of the dmesgs show (apart from MAC address differences): 30c30 Timecounter ACPI-safe frequency 3579545 Hz quality 1000 --- Timecounter ACPI-fast frequency 3579545 Hz quality 1000 What on earth is that all about? The slow box has the ACPI-fast timecounter... /Eirik On Nov 28, 2005, at 22:14 , Kris Kennaway wrote: On Mon, Nov 28, 2005 at 09:54:30PM +0100, Eirik ?verby wrote: Hi, I think I have found the culprit. There must be some sort of difference between the machines after all (BIOS revision?), because while on one machine the interrupt rate for the bge card stays very low (2 to be exact) during maximum load, the other machine goes beyond 1000 and keeps rising constantly. This might also explain why performance slowly degrades over time on that machine, and response times vary wildly, while the fast machine responds nicely within 1-2 seconds no matter the load and testing time. I will have to investigate this more closely. Is there a way to force the NIC to polling mode (I'm assuming that is the difference, an IRQ rate of 2 is too low for a heavily loaded server if the NIC is interrupt-driven)? Anything else I could look at? BIOS update. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: error after updated perl5.8 from 5.8.6 to 5.8.7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zhang Qing wrote: | === Configuring for mod_perl2-2.0.2,2 | /libexec/ld-elf.so.1: | /usr/local/lib/perl5/site_perl/5.8.7/mach/auto/Cwd/Cwd.so: Undefined | symbol Perl_Gthr_key_ptr | *** Error code 1 | | Stop in /usr/ports/www/mod_perl2. | srim# | | it can't make mod_perl2, the key error is Undefined symbol | Perl_Gthr_key_ptr, what this meaning? and how to correct it? Just a wild guess .. did you at any stage have WITH_THREADS=yes anywhere that a perl build might have seen it? Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDjmnciJykeV6HPMURApKZAKClsy7ke8DiSwmVBTCsTD4j2PUBXQCgl891 +MezMTOgzNk09GQYi3F5JJY= =DZwG -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: error after updated perl5.8 from 5.8.6 to 5.8.7
you are right, when first deinstall and install, indeed WITH_THREADS=yes, but the second time deinstall and build perl5.8 without WITH_THREADS=yes On 12/1/05, Michael Butler [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zhang Qing wrote: | === Configuring for mod_perl2-2.0.2,2 | /libexec/ld-elf.so.1: | /usr/local/lib/perl5/site_perl/5.8.7/mach/auto/Cwd/Cwd.so: Undefined | symbol Perl_Gthr_key_ptr | *** Error code 1 | | Stop in /usr/ports/www/mod_perl2. | srim# | | it can't make mod_perl2, the key error is Undefined symbol | Perl_Gthr_key_ptr, what this meaning? and how to correct it? Just a wild guess .. did you at any stage have WITH_THREADS=yes anywhere that a perl build might have seen it? Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDjmnciJykeV6HPMURApKZAKClsy7ke8DiSwmVBTCsTD4j2PUBXQCgl891 +MezMTOgzNk09GQYi3F5JJY= =DZwG -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
