Re: USB stalled errors
On Jan 31, 2007, at 22:48, Alban Hertroys wrote: Good day (or night, if more appropriate), I'm seeing these for a while now, it's time to see if it can be fixed :P I have a setup where a KVM/USB switch (Gefen 2x1 DVI switcher) is connected to my athlon64 machine, which is connected to yet another hub in my TFT display to which my keyboard and mouse are connected. I would have expected some response to this. I'm kind of disappointed. Well, I have a new data point. I found a PR about the Apple Cinema Display USB device hanging the usb stack or some such. Thinking it might solve my problem I disconnected the ACD USB device and plugged my keyboard and mouse directly in the KVM switch and booted the machine. Same problem, but on uhub3 this time. It gave a device write error instead of a TIMEOUT, but I've seen that before when the ACD was still connected too. So the problem _does not seem to be related_ to the ACD problem(s). Apparently the KVM switch contains a Cypress Tetra hub (acc. to the vendor/device codes in dmesg). Could someone please shed some light on this? Schematically the USB devices are connected like this: Athlon64 --- KVM switch --- Display --- Keyboard Mac ---/\-- Mouse This time it looked like: Athlon64 --- KVM switch --- Keyboard Mac ---/\-- Mouse While booting I see messages like these: uhub3: vendor 0x04b4 product 0x6560, class 9/0, rev 2.00/0.09, addr 2 uhub3: multiple transaction translators uhub3: 4 ports with 4 removable, self powered uhub4: vendor 0x05ac product 0x9131, class 9/0, rev 2.00/1.01, addr 3 uhub4: multiple transaction translators uhub4: 3 ports with 2 removable, self powered uhub4: device problem (STALLED), disabling port 1 uhub4: device problem (STALLED), disabling port 2 uhub4: device problem (TIMEOUT), disabling port 3 uhub3 is the KVM switch, while uhub4 is the display. The messages are usually STALLED, but I've seen TIMEOUT (as above) and SHORT_XFER as well. I have tried eliminating the hub in the display from the equation, the results are the same (the errors are on uhub3 in that case - although I'm not 100% sure now I write this). I've tried different hub cables (all but one came new with the switch), to no avail. The KVM switch replaced a Sweex USB hub that had very similar problems. Something that I think is odd is that the vendor/product ID's of the hub in the KVM switch are listed among those in the sources, yet looking them up apparently fails. I compiled a kernel with DEBUG_USB enabled and attached the resulting dmesg. I tried retrying usbd_new_device after the first failure, but that just resulted in another STALLED message (as suggested by an XXX remark in uhub.c). Anything else I can do to help solve this? Regards, -- Alban Hertroys If you throw your hands up in the air, how're you gonna catch them? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable- [EMAIL PROTECTED] -- Alban Hertroys It's not a bug! It's a six-legged feature! !DSPAM:74,45e3e56f9411858390337! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Sequence of packet processing with ipfw, pf, ipfilter ?
Hello, can someone point me to some documentation about the sequence of packet processing in fbsd6 if more than one of the filter systems is active ? There once was a nice ascii graphic which described the flow of packets through the rules -- I can't find it any more ? Thanks! -- [EMAIL PROTECTED] +49 171 310137213 years to go ! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems installing JDK 1.5
I did not have any problems with 5.5 however I started by installing Tomcat and everything else need was installed . I usualy compile my ports by hand and updated them by ctm. (getting deltas) regards, wlodek - Original Message - From: Juergen Nickelsen [EMAIL PROTECTED] lsen.de Newsgroups: w21.lists.freebsd-stable To: [EMAIL PROTECTED] d.org Sent: Monday, February 26, 2007 4:37 PM Subject: Problems installing JDK 1.5 Hello, on a more or less newly installed machine with 5.5-STABLE (updated recently) I tried to install JDK 1.5 via /usr/ports/. After retrieving all necessary files, the build failed quite mysteriously, even more so as I had succeeded with another machine fine last year. In the build protocol the problems seem to begin like this: Java HotSpot(TM) Client VM warning: Can't detect initial thread stack location /usr/ports/java/jdk15/work/control/build/bsd-i586/gensrc/sun/nio/cs/St = andardChar\ sets.java:226: identifier expected and then a series of other errors in the Java code; as if it is compiled using the wrong compiler version. It looks weird to me, as I think I fetched the correct files and did everything as carefully as last year. Is this a known problem? Does anyone know a way around it? Is the port currently broken, perhaps? Details can be found in [3]http://www.schlabun.org/screenlog.2; and I'll gladly provide more details if necessary. Regards, Juergen. ___ [EMAIL PROTECTED] rg mailing list [5]h= ttp://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] References 1. 3Dmailto:[EMAIL PROTECTED] 2. 3Dmailto:freebsd-stable@freebsd.org; 3. 3Dhttp://www.schlabun.org/screenl 4. 3Dmailto:freebsd-stable@freebsd.org; 5. 3Dhttp://lists.freebsd.org/mailman/listinfo/freebsd-stable; 6. 3Dmailto:freebsd-stable-uns___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ALi SATA controller
Søren Schmidt wrote: The problem is that your BIOS registers the resources used for AHCI operation but apparently hasn't really enabled them. Look for an option in the BIOS to turn on/off AHCI mode. There is no such option in the BIOS on this machine, as stated in the original thread. BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ALi SATA controller
On 2/27/07, Bruce M. Simpson [EMAIL PROTECTED] wrote: Søren Schmidt wrote: The problem is that your BIOS registers the resources used for AHCI operation but apparently hasn't really enabled them. Look for an option in the BIOS to turn on/off AHCI mode. There is no such option in the BIOS on this machine, as stated in the original thread. Yeah, I don't see it either. The only option regardige AHCI in BIOS is to choose whether the SATA controller will be in AHCI or RAID mode. JL -- 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]
Re: ALi SATA controller
Juraj Lutter wrote: On 2/27/07, Bruce M. Simpson [EMAIL PROTECTED] wrote: Søren Schmidt wrote: The problem is that your BIOS registers the resources used for AHCI operation but apparently hasn't really enabled them. Look for an option in the BIOS to turn on/off AHCI mode. There is no such option in the BIOS on this machine, as stated in the original thread. Lame BIOS writers :/ Yeah, I don't see it either. The only option regardige AHCI in BIOS is to choose whether the SATA controller will be in AHCI or RAID mode. Does it change anything if you shift between those two ? -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ALi SATA controller
On 2/27/07, Søren Schmidt [EMAIL PROTECTED] wrote: Does it change anything if you shift between those two ? I need to figure out how to do it effectively :-) The machine is somewhere in serverhousing room and is doing some production right now.. I will plan a short outage in near future. -- 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]
Re: PATCH: new acpi embedded controller I/O model
On Mon, 26 Feb 2007 18:20:02 -0800
Nate Lawson [EMAIL PROTECTED] wrote:
If you are having EC timeout problems as in the below PR, please try
the latest EC code. I just committed it in rev 1.69 of acpi_ec.c to
-current. Attached is the patch for 6-stable.
http://www.freebsd.org/cgi/query-pr.cgi?pr=98171
To use it, just recompile your acpi kernel module and load it at
boot: cd /sys/modules/acpi/acpi make cp acpi.ko /
Then at the loader prompt after rebooting:
load /acpi.ko
boot
You should be able to see battery status and thermal settings via
sysctl hw.acpi as normal. Check dmesg for any new errors.
If you notice slower performance or get EC timed out messages on
console, you try increasing these sysctls/tunables:
debug.acpi.ec.timeout
debug.acpi.ec.poll_time
Or turn off this sysctl/tunable, disabling the new burst mode:
debug.acpi.ec.burst=0
To find any performance problems, you'll need to rebuild the kernel
and modules with this added to your kernel config:
options KTR
options KTR_ENTRIES=65536
Then reboot, load this kernel/acpi.ko, use the system for a while to
trigger the problem behavior and generate output:
ktrdump -t | gzip -c ktr.out.gz
This code is pretty well-tested so I expect the only issues we might
see is it not totally fixing some systems that previously didn't
work or needing to add some workaround code for systems that don't
properly support burst mode.
Not quite a success, unless with debug.acpi.ec.burst=0 plus this
additional patch. Even so, the timed out message keep appearing once
in a while though not so frequent as before. In terms of performance,
things are a bit smoother (acpiconf -i 0 works, no longer exhibit
delay or producing timed out messages). Tuning
debug.acpi.ec.timeout/poll_timeout upside-down has no real effect on
eliminating those timed out messages.
Compaq V3000/Turion64 X2.
--
Ariff Abdullah
FreeBSD
... Recording in stereo is obviously too advanced
and confusing for us idiot * users :P
--- sys/dev/acpica/acpi_ec.c Tue Feb 27 19:21:12 2007
+++ sys/dev/acpica/acpi_ec.c Tue Feb 27 19:22:17 2007
@@ -936,6 +936,7 @@
count = ec_poll_time / EC_POLL_DELAY;
if (count = 0)
count = 1;
+slp_ival = max(hz / 1000, 1);
for (i = 0; i count; i++) {
EcStatus = EC_GET_CSR(sc);
if (sc-ec_burstactive (EcStatus EC_FLAG_BURST_MODE) == 0) {
@@ -947,7 +948,15 @@
Status = AE_OK;
break;
}
- AcpiOsStall(EC_POLL_DELAY);
+ if (sc-ec_burstactive)
+ AcpiOsStall(EC_POLL_DELAY);
+ else {
+ if (!cold)
+ msleep(sc-ec_csrvalue, sc-ec_mtx, PZERO, ecpoll,
+ slp_ival);
+ else
+ AcpiOsStall(1000);
+ }
}
/*
pgpqRbRSrOSef.pgp
Description: PGP signature
Re: Pentium 640 and Enhanced SpeedStep
On Monday 26 February 2007 13:45, Andrei Kolu wrote: On Saturday 24 February 2007 7:51 pm, Andrei Kolu wrote: FreeBSD 6.1-RELEASE-p11 Motherboard: Supermicro P8SCi CPU: Pentium 4 640 I have HyperThreading enabled... Enabling powerd gave me this error message: est0: Enhanced SpeedStep Frequency Control on cpu0 est1: Enhanced SpeedStep Frequency Control on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: Please update driver or contact the maintainer. est: cpu_vendor GenuineIntel, msr 102d102d, bus_clk, 64 device_attach: est1 attach returned 6 OK, I figured it out by myself. Added cpufreq_load=YES into /boot/loader.conf but got error: est0: Enhanced SpeedStep Frequency Control on cpu0 p4tcc0: CPU Frequency Thermal Control on cpu0 cpu1: ACPI CPU on acpi0 est1: Enhanced SpeedStep Frequency Control on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: Please update driver or contact the maintainer. est: cpu_vendor GenuineIntel, msr 102d102d, bus_clk, 64 device_attach: est1 attach returned 6 p4tcc1: CPU Frequency Thermal Control on cpu1 BUT # sysctl -a | grep dev.cpu I found out what is caused problem with SpeedStep. I had to disable HyperThreading from BIOS and after that everything works just fine: cpu0: ACPI CPU on acpi0 acpi_perf0: ACPI CPU Frequency Control on cpu0 p4tcc0: CPU Frequency Thermal Control on cpu0 # sysctl dev.cpu dev.cpu.0.freq: 900 dev.cpu.0.freq_levels: 3200/88000 2800/75000 2450/65625 2400/63000 2100/55125 1800/47250 1500/39375 1200/31500 900/23625 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sequence of packet processing with ipfw, pf, ipfilter ?
On Tuesday 27 February 2007 09:31, Kurt Jaeger wrote:
can someone point me to some documentation about the sequence
of packet processing in fbsd6 if more than one of the filter
systems is active ?
Unfortunately, there is no defined sequence. Currently it depends on the
sequence the individual components are enabled, or - more specificly -
the sequence of pfil_add_hook() calls. Note that ipfw does this on
module load, while pf waits until you issue pfctl -e. I had
experimental patches to control the sequence back in 2005 (see attached).
Note that this will not work!!! It's more for reference. Back then
nobody was interesting in testing.
There once was a nice ascii graphic which described the flow
of packets through the rules -- I can't find it any more ?
--
/\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
Index: contrib/pf/net/pf_ioctl.c
===
RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/pf/net/pf_ioctl.c,v
retrieving revision 1.21
diff -u -r1.21 pf_ioctl.c
--- contrib/pf/net/pf_ioctl.c 8 Sep 2005 15:06:52 - 1.21
+++ contrib/pf/net/pf_ioctl.c 4 Dec 2005 13:47:24 -
@@ -3461,19 +3461,23 @@
pfh_inet = pfil_head_get(PFIL_TYPE_AF, AF_INET);
if (pfh_inet == NULL)
return (ESRCH); /* XXX */
- pfil_add_hook(pf_check_in, NULL, PFIL_IN | PFIL_WAITOK, pfh_inet);
- pfil_add_hook(pf_check_out, NULL, PFIL_OUT | PFIL_WAITOK, pfh_inet);
+ pfil_add_named_hook(pf_check_in, NULL, pf, PFIL_IN|PFIL_WAITOK,
+ pfh_inet);
+ pfil_add_named_hook(pf_check_out, NULL, pf, PFIL_OUT|PFIL_WAITOK,
+ pfh_inet);
#ifdef INET6
pfh_inet6 = pfil_head_get(PFIL_TYPE_AF, AF_INET6);
if (pfh_inet6 == NULL) {
- pfil_remove_hook(pf_check_in, NULL, PFIL_IN | PFIL_WAITOK,
+ pfil_remove_hook(pf_check_in, NULL, PFIL_IN|PFIL_WAITOK,
pfh_inet);
- pfil_remove_hook(pf_check_out, NULL, PFIL_OUT | PFIL_WAITOK,
+ pfil_remove_hook(pf_check_out, NULL, PFIL_OUT|PFIL_WAITOK,
pfh_inet);
return (ESRCH); /* XXX */
}
- pfil_add_hook(pf_check6_in, NULL, PFIL_IN | PFIL_WAITOK, pfh_inet6);
- pfil_add_hook(pf_check6_out, NULL, PFIL_OUT | PFIL_WAITOK, pfh_inet6);
+ pfil_add_named_hook(pf_check6_in, NULL, pf, PFIL_IN|PFIL_WAITOK,
+ pfh_inet6);
+ pfil_add_named_hook(pf_check6_out, NULL, pf, PFIL_OUT|PFIL_WAITOK,
+ pfh_inet6);
#endif
pf_pfil_hooked = 1;
Index: net/bridge.c
===
RCS file: /usr/store/mlaier/fcvs/src/sys/net/Attic/bridge.c,v
retrieving revision 1.93.2.1
diff -u -r1.93.2.1 bridge.c
--- net/bridge.c 25 Aug 2005 05:01:19 - 1.93.2.1
+++ net/bridge.c 3 Dec 2005 16:47:15 -
@@ -995,7 +995,7 @@
* and pkts already gone through a pipe.
*/
if (src != NULL (
- (inet_pfil_hook.ph_busy_count = 0 bdg_ipf != 0) ||
+ (!PFIL_IS_EMPTY(inet_pfil_hook) bdg_ipf != 0) ||
(IPFW_LOADED bdg_ipfw != 0))) {
int i;
@@ -1044,7 +1044,7 @@
* Enables ipf(8) in bridging.
*/
if (!IPFW_LOADED) { /* XXX: Prevent ipfw from being run twice. */
- if (inet_pfil_hook.ph_busy_count = 0
+ if (!PFIL_IS_EMPTY(inet_pfil_hook)
m0-m_pkthdr.len = sizeof(struct ip)
ntohs(save_eh.ether_type) == ETHERTYPE_IP) {
/*
Index: net/if_bridge.c
===
RCS file: /usr/store/mlaier/fcvs/src/sys/net/if_bridge.c,v
retrieving revision 1.35
diff -u -r1.35 if_bridge.c
--- net/if_bridge.c 29 Nov 2005 20:29:44 - 1.35
+++ net/if_bridge.c 4 Dec 2005 13:47:57 -
@@ -1315,9 +1315,9 @@
return;
}
- if (inet_pfil_hook.ph_busy_count = 0
+ if (!PFIL_IS_EMPTY(inet_pfil_hook)
#ifdef INET6
- || inet6_pfil_hook.ph_busy_count = 0
+ || !PFIL_IS_EMPTY(inet6_pfil_hook)
#endif
) {
if (bridge_pfil(m, sc-sc_ifp, ifp, PFIL_OUT) != 0)
@@ -1577,9 +1577,9 @@
}
/* run the packet filter */
- if (inet_pfil_hook.ph_busy_count = 0
+ if (!PFIL_IS_EMPTY(inet_pfil_hook)
#ifdef INET6
- || inet6_pfil_hook.ph_busy_count = 0
+ || !PFIL_IS_EMPTY(inet6_pfil_hook)
#endif
) {
BRIDGE_UNLOCK(sc);
@@ -1630,9 +1630,9 @@
BRIDGE_UNLOCK(sc);
- if (inet_pfil_hook.ph_busy_count = 0
+ if (!PFIL_IS_EMPTY(inet_pfil_hook)
#ifdef INET6
- || inet6_pfil_hook.ph_busy_count = 0
+ || !PFIL_IS_EMPTY(inet6_pfil_hook)
#endif
) {
if (bridge_pfil(m, sc-sc_ifp, dst_if, PFIL_OUT) != 0)
@@ -1819,9 +1819,9 @@
}
/* Filter on the bridge interface before broadcasting */
- if (runfilt (inet_pfil_hook.ph_busy_count = 0
+ if (runfilt (!PFIL_IS_EMPTY(inet_pfil_hook)
#ifdef INET6
- || inet6_pfil_hook.ph_busy_count = 0
+ || PFIL_IS_EMPTY(inet6_pfil_hook)
#endif
)) {
if (bridge_pfil(m, sc-sc_ifp, NULL, PFIL_OUT) != 0)
@@ -1866,9 +1866,9 @@
* pointer so we do not redundantly
Some days, it doesn't pay to upgrade ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 After 155 days of problem free uptime, I upgraded my 6-STABLE system the other day to the latest cvsup ... 3 days later, the whole thing hung solid with: Feb 27 04:32:49 mars uptimec: The server requested that we do a new login Feb 27 04:33:00 mars kernel: maxproc limit exceeded by uid 0, please see tuning(7) and login.conf(5). Feb 27 04:33:10 mars kernel: maxproc limit exceeded by uid 60, please see tuning(7) and login.conf(5). Stupid question: why isn't there some mechanism that prevents new processes from starting up, instead of locking up the whole server? I'm not asking for the evilness of Linux, where it arbitrarily kills off existing processes, but if maxproc is hit, why continue to try and start up new ones? - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFF5Csz4QvfyHIvDvMRAvriAJ48K+5X/YdY7YW13Ro8z/nVuca3cQCeIlYk L8cLOgpzH4W4+tz6V8GVVqc= =x/Ok -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]
is localtime file binary compatible with older releases?
Is the compiled time zone info file binary compatible across FreeBSD versions? I have a couple of 4.x and one 5.x box still on my network, and I was wondering if it was possible to just copy the /etc/ localtime from a new 6.1 box on to all of them rather than having to install the updated zone file port. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
panic: kmem_malloc(16384): kmem_map too small: md-mounted /tmp filled up
The memory-mounted /tmp filled up on this 6.2-PRERELEASE system (as of Nov 7). Unfortunately, instead of the process existing due to ENOSPC, the entire system paniced: [...] g_vfs_done():md0[WRITE(offset=982335488, length=131072)]error = 28 g_vfs_done():md0[WRITE(offset=982466560, length=131072)]error = 28 panic: kmem_malloc(16384): kmem_map too small: 259153920 total allocated Uptime: 34d21h13m21s Dumping 767 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 767MB (196288 pages) 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 ... ok Dump complete Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... I don't think, such DoS-ing is normal -- a regular user shot the entire system in the knee... Is anybody interested in the stack/etc.? Is this something, that's fixed in the more recent 6.2? Machine has 3/4Gb RAM and ample swap: Device 1K-blocks UsedAvail Capacity /dev/ad0s1b 3145728 32 3145696 0% /dev/ad2s1b 1048576 32 1048544 0% Total 4194304 64 4194240 0% /tmp's space allocation (after reboot) is as follows: Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md0 2026030 3552 1860396 0%/tmp Note, that it is supposed to hold 2Gb, but was filled up and paniced holding about 300Mb... Probably, because it is created with ``-M'' by default -- but it is not supposed to panic anyway! Please, advise. Thanks! -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems installing JDK 1.5
I'm assuming that you installed linux compatibility and then the linux-jdk 1.4? I failed to do that and saw a very similar error a while back. :) Sam Baskinger Lumeta - Securing the Network in the Face of Change www.lumeta.com Juergen Nickelsen wrote: Hello, on a more or less newly installed machine with 5.5-STABLE (updated recently) I tried to install JDK 1.5 via /usr/ports/. After retrieving all necessary files, the build failed quite mysteriously, even more so as I had succeeded with another machine fine last year. In the build protocol the problems seem to begin like this: Java HotSpot(TM) Client VM warning: Can't detect initial thread stack location /usr/ports/java/jdk15/work/control/build/bsd-i586/gensrc/sun/nio/cs/StandardChar\ sets.java:226: identifier expected and then a series of other errors in the Java code; as if it is compiled using the wrong compiler version. It looks weird to me, as I think I fetched the correct files and did everything as carefully as last year. Is this a known problem? Does anyone know a way around it? Is the port currently broken, perhaps? Details can be found in http://www.schlabun.org/screenlog.2; and I'll gladly provide more details if necessary. Regards, Juergen. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Stable on Blade server
Martin [EMAIL PROTECTED] writes: We're 100% FreeBSD-only and i was looking to buy IBM blade servers: can anyone reccomend any of them? models? particular hw/firmware/misc If you use FreeBSD don't look upon IBM blades at all. I've installed few freebsd 5.4 on IBM HS20 blades. If you need console, the only way to get there is through java web interface that sucks, brakes and crashes constantly. Because the keyboard is not supported you have to use it. Everything else also sucked. We had two blade chassis with 28 blade servers and I have never been so frustrated like I was with them and IBM people that did not solve our problem. -- One cannot sell the earth upon which the people walk Tacunka Witco ___ 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 Tue, Feb 27, 2007 at 10:59:08AM -0500, Mikhail Teterin wrote: /tmp's space allocation (after reboot) is as follows: Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md0 2026030 3552 1860396 0%/tmp Note, that it is supposed to hold 2Gb, but was filled up and paniced holding about 300Mb... Probably, because it is created with ``-M'' by default -- but it is not supposed to panic anyway! You may want to set -o reserve option. Or better, switch to a swap backed md. -- Adios ___ 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, Change the threading lib. It fixed it for us. % cat /etc/libmap.conf [clamd] libc_r.so.5 libthr.so.2 libc_r.so.6 libthr.so.2 libthr.so.2 libthr.so.2 libpthread.so.1 libthr.so.2 libpthread.so.2 libthr.so.2 Even with libthr the CPU usage is still far too high ... I'm currently looking at the code. 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
I've seen it go loop as well on my Dual-Xeon. I did just switch it to libthr, but still had one occurace. I did switch maxthreads to 1. If I can test, please let me know. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Blapp Sent: Tuesday, February 27, 2007 11:37 AM To: Sergey N. Voronkov Cc: freebsd-stable@freebsd.org Subject: Re: Clamav-90_2 Lockup with freebsd 6.2 Hi, Change the threading lib. It fixed it for us. % cat /etc/libmap.conf [clamd] libc_r.so.5 libthr.so.2 libc_r.so.6 libthr.so.2 libthr.so.2 libthr.so.2 libpthread.so.1 libthr.so.2 libpthread.so.2 libthr.so.2 Even with libthr the CPU usage is still far too high ... I'm currently looking at the code. Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Clamav-90_2 Lockup with freebsd 6.2
Was this indeed compiled with pthread or with lpthread? I had this issue on a 4.11-RELEASE machine very recently. As it does not have lpthread, it would fail to compile against this. Martin Blapp wrote: Hi, Change the threading lib. It fixed it for us. % cat /etc/libmap.conf [clamd] libc_r.so.5 libthr.so.2 libc_r.so.6 libthr.so.2 libthr.so.2 libthr.so.2 libpthread.so.1 libthr.so.2 libpthread.so.2 libthr.so.2 Even with libthr the CPU usage is still far too high ... I'm currently looking at the code. Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems installing JDK 1.5
On Tue, Feb 27, 2007 at 11:22:44AM -0500, Sam Baskinger wrote: I'm assuming that you installed linux compatibility and then the linux-jdk 1.4? I failed to do that and saw a very similar error a while back. :) That may well be the case. I assumed the port installed it as a dependency, but I didn't really look close. Thanks for the hint! I'll report back later. Regards, Juergen. [...] Juergen Nickelsen wrote: Hello, on a more or less newly installed machine with 5.5-STABLE (updated recently) I tried to install JDK 1.5 via /usr/ports/. After retrieving all necessary files, the build failed quite mysteriously, even more so as I had succeeded with another machine fine last year. In the build protocol the problems seem to begin like this: -- Never trust an operating system you don't have sources for. -- Joerg Wunsch ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems installing JDK 1.5
In the last episode (Feb 27), Juergen Nickelsen said: On Tue, Feb 27, 2007 at 11:22:44AM -0500, Sam Baskinger wrote: I'm assuming that you installed linux compatibility and then the linux-jdk 1.4? I failed to do that and saw a very similar error a while back. :) That may well be the case. I assumed the port installed it as a dependency, but I didn't really look close. Thanks for the hint! I'll report back later. You could also install the native diablo-jdk15 port instead of a Linux one. -- Dan Nelson [EMAIL PROTECTED] ___ 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
At 12:36 PM 2/27/2007, Martin Blapp wrote: Hi, Change the threading lib. It fixed it for us. % cat /etc/libmap.conf [clamd] libc_r.so.5 libthr.so.2 libc_r.so.6 libthr.so.2 libthr.so.2 libthr.so.2 libpthread.so.1 libthr.so.2 libpthread.so.2 libthr.so.2 Even with libthr the CPU usage is still far too high ... I'm currently looking at the code. We have our boxes setup so that we have the milter running on different boxes than clamd. Clamd doesnt seem to take up too much more CPU power than it did before using the old libs. ---Mike ___ 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 Tuesday 27 February 2007 11:41, Alex Kozlov wrote: = On Tue, Feb 27, 2007 at 10:59:08AM -0500, Mikhail Teterin wrote: = /tmp's space allocation (after reboot) is as follows: = =Filesystem 1K-blocks Used Avail Capacity Mounted on =/dev/md0 2026030 3552 1860396 0%/tmp = = Note, that it is supposed to hold 2Gb, but was filled up and paniced = holding about 300Mb... Probably, because it is created with ``-M'' = by default -- but it is not supposed to panic anyway! = You may want to set -o reserve option. Or better, switch to a swap backed = md. Yes, I switched to swap-backed md already. But the malloc-based variety is currently the _default_ (see /etc/defaults/rc.conf)... Creation of a 2Gb malloc-based md should've failed on a machine with 768Mb of RAM, shouldn't it have? On Tuesday 27 February 2007 11:45, Zaphod Beeblebrox wrote: = IIRC, the total kernel memory on a normally configured 6.xor 7.x box is 1G = on 32 bit. = So I've pretty much abandoned ram disks on 32 bit machines. Not enough = memory. Memory disks used to be served by user-space processes (mount_mfs), making them not care for the whole malloc/swap distinctions, and the address-space concerns. Are you sure, swap-based mds still consume kernel's address space, though? -mi ___ 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, I can confirm the same situation. My dual xeon x236 server runs very high cpu utilisation with clamav. Also tried with maxthreads to 1. Result is the same but frequency of locked process seems to be reduced. Cheers Dimi -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Martin Blapp Sent: Wednesday, 28 February 2007 4:37 AM To: Sergey N. Voronkov Cc: freebsd-stable@freebsd.org Subject: Re: Clamav-90_2 Lockup with freebsd 6.2 Hi, Change the threading lib. It fixed it for us. % cat /etc/libmap.conf [clamd] libc_r.so.5 libthr.so.2 libc_r.so.6 libthr.so.2 libthr.so.2 libthr.so.2 libpthread.so.1 libthr.so.2 libpthread.so.2 libthr.so.2 Even with libthr the CPU usage is still far too high ... I'm currently looking at the code. Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PATCH: new acpi embedded controller I/O model
Mån 2007-02-26 klockan 18:20 -0800 skrev Nate Lawson: If you are having EC timeout problems as in the below PR, please try the latest EC code. I just committed it in rev 1.69 of acpi_ec.c to -current. Thanks for working on this, but my laptop (HP nx7400) shuts down right after boot (or sometimes during boot) after this commit. I see this on the console: acpi_tz3: WARNING - Current temperature (3416.3) exceeds safe limits ... WARNING: System temperature too high, shutting down soon! Everything works fine with an older kernel. -- Joel ___ 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 Tue, Feb 27, 2007 at 02:48:11PM -0500, Mikhail Teterin wrote: On Tuesday 27 February 2007 11:41, Alex Kozlov wrote: = On Tue, Feb 27, 2007 at 10:59:08AM -0500, Mikhail Teterin wrote: = /tmp's space allocation (after reboot) is as follows: = =Filesystem 1K-blocks Used Avail Capacity Mounted on =/dev/md0 2026030 3552 1860396 0%/tmp = = Note, that it is supposed to hold 2Gb, but was filled up and paniced = holding about 300Mb... Probably, because it is created with ``-M'' = by default -- but it is not supposed to panic anyway! = You may want to set -o reserve option. Or better, switch to a swap backed = md. Yes, I switched to swap-backed md already. But the malloc-based variety is currently the _default_ (see /etc/defaults/rc.conf)... Bad default. Anyway, you may wish to change tmpmfs_flags on something like that: -S -m0 -o async,nosymfollow,nosuid 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. -- Adios ___ 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 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. = 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? -mi ___ 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
Documented in the manpage, use swap backing or reserve enough space. Kris On Tue, Feb 27, 2007 at 10:59:08AM -0500, Mikhail Teterin wrote: The memory-mounted /tmp filled up on this 6.2-PRERELEASE system (as of Nov 7). Unfortunately, instead of the process existing due to ENOSPC, the entire system paniced: [...] g_vfs_done():md0[WRITE(offset=982335488, length=131072)]error = 28 g_vfs_done():md0[WRITE(offset=982466560, length=131072)]error = 28 panic: kmem_malloc(16384): kmem_map too small: 259153920 total allocated Uptime: 34d21h13m21s Dumping 767 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 767MB (196288 pages) 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 ... ok Dump complete Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... I don't think, such DoS-ing is normal -- a regular user shot the entire system in the knee... Is anybody interested in the stack/etc.? Is this something, that's fixed in the more recent 6.2? Machine has 3/4Gb RAM and ample swap: Device 1K-blocks UsedAvail Capacity /dev/ad0s1b 3145728 32 3145696 0% /dev/ad2s1b 1048576 32 1048544 0% Total 4194304 64 4194240 0% /tmp's space allocation (after reboot) is as follows: Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md0 2026030 3552 1860396 0%/tmp Note, that it is supposed to hold 2Gb, but was filled up and paniced holding about 300Mb... Probably, because it is created with ``-M'' by default -- but it is not supposed to panic anyway! Please, advise. Thanks! -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Clamav-90_2 Lockup with freebsd 6.2
On Wed, 28 Feb 2007, Dimuthu Parussalla wrote: Hi, I can confirm the same situation. My dual xeon x236 server runs very high cpu utilisation with clamav. Also tried with maxthreads to 1. Result is the same but frequency of locked process seems to be reduced. I think clamav has a bug somewhere. I seem to recall some other application having bad assumptions about sockets, but can't remember exactly what it was. I do know that a close() on a file descriptor does not wakeup and return an error to all threads waiting on it. FreeBSD and supposedly Linux have this behavior, but Solaris will return an error to all threads. I'm not sure this has anything to do with it, but after seeing the bug report of clamd having a lot of threads waiting in accept(), it might be a place to start investigating... -- DE ___ 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 Tuesday 27 February 2007 16:09, Kris Kennaway wrote: = Documented in the manpage, use swap backing or reserve enough space. = = Kris The strings panic and -o reserve are mentioned in neither mdmfs(8) nor in rc.conf(5)... Is one supposed to look elsewhere? Worse, the use of malloc-based mds is touted in rc.conf as something, that is supposed to help system stability at low memory conditions. All I did on this system, was set tmpmfs=YES tmpsize=2048m in the /etc/rc.conf. Alex has already said, that using malloc-backed md is a bad default -- do you disagree? -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems installing JDK 1.5
Don't forget that the linux JDK will want you to have linprocfs mounted. I recently had a similar build experience of jdk-1.5.0p4 which cleared up fine after I remembered about linprocfs. linprocfs /compat/linux/proc linprocfs rw 0 0 -Chris On Tue, 27 Feb 2007, Juergen Nickelsen wrote: On Tue, Feb 27, 2007 at 11:22:44AM -0500, Sam Baskinger wrote: I'm assuming that you installed linux compatibility and then the linux-jdk 1.4? I failed to do that and saw a very similar error a while back. :) That may well be the case. I assumed the port installed it as a dependency, but I didn't really look close. Thanks for the hint! I'll report back later. Regards, Juergen. ___ 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 Tue, Feb 27, 2007 at 04:24:21PM -0500, Mikhail Teterin wrote: On Tuesday 27 February 2007 16:09, Kris Kennaway wrote: = Documented in the manpage, use swap backing or reserve enough space. = = Kris The strings panic and -o reserve are mentioned in neither mdmfs(8) nor in rc.conf(5)... Is one supposed to look elsewhere? Yes, mdconfig, which is what creates the device (mdmfs is a legacy wrapper for 4.x compatibility). Worse, the use of malloc-based mds is touted in rc.conf as something, that is supposed to help system stability at low memory conditions. All I did on this system, was set tmpmfs=YES tmpsize=2048m in the /etc/rc.conf. Alex has already said, that using malloc-backed md is a bad default -- do you disagree? No, that's what I said too (on this occasion and several times in the past :). I am not aware of a good reason to use malloc backing over swap, under any circumstances. Kris pgpdmgJlFZc5z.pgp Description: PGP signature
Re: panic: kmem_malloc(16384): kmem_map too small: md-mounted /tmp filled up
On Tue, Feb 27, 2007 at 04:46:57PM -0500, Michael Proto wrote: Kris Kennaway wrote: On Tue, Feb 27, 2007 at 04:24:21PM -0500, Mikhail Teterin wrote: The strings panic and -o reserve are mentioned in neither mdmfs(8) nor in rc.conf(5)... Is one supposed to look elsewhere? Yes, mdconfig, which is what creates the device (mdmfs is a legacy wrapper for 4.x compatibility). Isn't this backwards? mdconfig is the legacy-compatibility wrapper for mdmfs, not the other way around. No. DESCRIPTION The mdmfs utility is designed to be a work-alike and look-alike of the deprecated mount_mfs(8). The end result is essentially the same, but is accomplished in a completely different way. The mdmfs utility configures an md(4) disk using mdconfig(8), puts a UFS file system on it using newfs(8), and mounts it using mount(8). Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Hardware Security Modules
Anybody have a list of hardware security modules that work with FreeBSD? Mostly looking for units that certificate authority functions (signing, secure key storage). Any help that you can provide would be greatly appreciated. Thanks for your time, -- Dave ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: is localtime file binary compatible with older releases?
In message: [EMAIL PROTECTED] Vivek Khera [EMAIL PROTECTED] writes: : Is the compiled time zone info file binary compatible across FreeBSD : versions? I have a couple of 4.x and one 5.x box still on my : network, and I was wondering if it was possible to just copy the /etc/ : localtime from a new 6.1 box on to all of them rather than having to : install the updated zone file port. Yes. Warner ___ 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
Kris Kennaway wrote: On Tue, Feb 27, 2007 at 04:24:21PM -0500, Mikhail Teterin wrote: The strings panic and -o reserve are mentioned in neither mdmfs(8) nor in rc.conf(5)... Is one supposed to look elsewhere? Yes, mdconfig, which is what creates the device (mdmfs is a legacy wrapper for 4.x compatibility). Isn't this backwards? mdconfig is the legacy-compatibility wrapper for mdmfs, not the other way around. -Proto ___ 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
Kris Kennaway wrote: On Tue, Feb 27, 2007 at 04:24:21PM -0500, Mikhail Teterin wrote: The strings panic and -o reserve are mentioned in neither mdmfs(8) nor in rc.conf(5)... Is one supposed to look elsewhere? Yes, mdconfig, which is what creates the device (mdmfs is a legacy wrapper for 4.x compatibility). Please disregard my last post I was thinking of mount_mfs, which is a compatibility interface into mdmfs, not mdconfig. -Proto ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[EMAIL PROTECTED]
-- -Ryan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: is localtime file binary compatible with older releases?
In article [EMAIL PROTECTED] you write: Is the compiled time zone info file binary compatible across FreeBSD versions? It is backwards-compatible across all versions of the Olson timezone library going back to before there was a FreeBSD, on all platforms, regardless of architecture (modulo bugs in libc). -GAWollman ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PATCH: new acpi embedded controller I/O model
Ariff Abdullah wrote:
On Mon, 26 Feb 2007 18:20:02 -0800
Nate Lawson [EMAIL PROTECTED] wrote:
If you notice slower performance or get EC timed out messages on
console, you try increasing these sysctls/tunables:
debug.acpi.ec.timeout
debug.acpi.ec.poll_time
Before you go changing the logic, please...
Try adjusting these parameters, including other values besides these:
debug.acpi.ec.timeout=1000 # 1 sec total
debug.acpi.ec.poll_time=100 # 100 usec polling (or try larger like 800)
Or turn off this sysctl/tunable, disabling the new burst mode:
debug.acpi.ec.burst=0
Try the above values both with and without burst mode.
To find any performance problems, you'll need to rebuild the kernel
and modules with this added to your kernel config:
options KTR
options KTR_ENTRIES=65536
Then reboot, load this kernel/acpi.ko, use the system for a while to
trigger the problem behavior and generate output:
ktrdump -t | gzip -c ktr.out.gz
Would you please submit the output requested above, along with sysctl
debug.acpi.ec so I can know what parameters you were using?
--- sys/dev/acpica/acpi_ec.c Tue Feb 27 19:21:12 2007
+++ sys/dev/acpica/acpi_ec.c Tue Feb 27 19:22:17 2007
@@ -936,6 +936,7 @@
count = ec_poll_time / EC_POLL_DELAY;
if (count = 0)
count = 1;
+slp_ival = max(hz / 1000, 1);
for (i = 0; i count; i++) {
EcStatus = EC_GET_CSR(sc);
if (sc-ec_burstactive (EcStatus EC_FLAG_BURST_MODE) == 0) {
@@ -947,7 +948,15 @@
Status = AE_OK;
break;
}
- AcpiOsStall(EC_POLL_DELAY);
+ if (sc-ec_burstactive)
+ AcpiOsStall(EC_POLL_DELAY);
+ else {
+ if (!cold)
+ msleep(sc-ec_csrvalue, sc-ec_mtx, PZERO, ecpoll,
+ slp_ival);
+ else
+ AcpiOsStall(1000);
+ }
}
/*
Your patch just goes straight into msleep() instead of doing any
DELAY(). Does enabling the #if 0 code right before your patch help?
Please revert your patch and try the above. We need to reduce the
amount of variation to track it down.
--
Nate
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PATCH: new acpi embedded controller I/O model
Joel Dahl wrote: Mån 2007-02-26 klockan 18:20 -0800 skrev Nate Lawson: If you are having EC timeout problems as in the below PR, please try the latest EC code. I just committed it in rev 1.69 of acpi_ec.c to -current. Thanks for working on this, but my laptop (HP nx7400) shuts down right after boot (or sometimes during boot) after this commit. I see this on the console: acpi_tz3: WARNING - Current temperature (3416.3) exceeds safe limits ... WARNING: System temperature too high, shutting down soon! Everything works fine with an older kernel. First, try booting with these changes. You can set a tunable (debug.acpi.disabled=thermal) to avoid the erroneous thermal shutdown. 1. set debug.acpi.ec.burst=0 2. set debug.acpi.ec.timeout=1000 3. uncomment the #if 0 code in acpi_ec.c and recompile Then, collect the data with the method I provided: To find any performance problems, you'll need to rebuild the kernel and modules with this added to your kernel config: options KTR options KTR_ENTRIES=65536 Then reboot, load this kernel/acpi.ko, use the system for a while to trigger the problem behavior and generate output: ktrdump -t | gzip -c ktr.out.gz -- Nate ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Apache13/MoinMoin/Python vs PATH? What changed?
Hi all, Funny thing happened after the last upgrade (upgraded to 6-STABLE yesterday): the moinmoin wiki that I've been playing with stopped working. A little fiddling found that I could make it work again by changing the shebang at the top of /usr/local/www/wiki/moin.cgi (ScriptAlias points there, in httpd.conf) from #!/usr/bin/env python to #!/usr/local/bin/python Now, it appears that * python is in /usr/local/bin, as expected * /usr/local/bin is still in the default path in /etc/login.conf * none of the Apache or MoinMoin config files have been touched since November last year, when I set it up. It seems that apache-1.3 went through an upgrade on Jan 17 (here), probably the last time that I ran portupgrade. Has it changed, to filter /usr/local/bin out of the PATH that cgi scripts see? I'm not very adept at Apache configuration, but I don't see anything in the httpd.conf file that talks about PATH. Any thoughts? -- Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sysutils/fusefs-ntfs working for anyone?
On Sunday 18 February 2007 13:59, John Nielsen wrote: On Sunday 18 February 2007 12:45, Ulrich Spoerlein wrote: I've been trying to mount my NTFS partitions with the NTFS-3g project's FUSE implementation but am unable to mount anything. I'm on 6-STABLE and have the latest versions of FUSE installed: [big snip] ... So, the basic question is: Has _anybody_ used ntfs-3g successfully on RELENG_6? When I tried it a couple months ago (on -STABLE) all I got were coredumps.. I just tried this again (running -STABLE from a few days ago, reinstalled the port today) and it's working fine for a volume created with mkntfs and for a volume created under Windows XP (over iSCSI no less). JN ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PATCH: new acpi embedded controller I/O model
On Tue, Feb 27, 2007 at 09:05:17PM +0100, Joel Dahl wrote.. Mån 2007-02-26 klockan 18:20 -0800 skrev Nate Lawson: If you are having EC timeout problems as in the below PR, please try the latest EC code. I just committed it in rev 1.69 of acpi_ec.c to -current. Thanks for working on this, but my laptop (HP nx7400) shuts down right after boot (or sometimes during boot) after this commit. I see this on the console: acpi_tz3: WARNING - Current temperature (3416.3) exceeds safe limits Nice.. You should ship this laptop to the folks at JET or NIF, we are now one step closer to nuclear fusion. :-) -- Wilko Bulte [EMAIL PROTECTED] ___ 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 [EMAIL PROTECTED] wrote: Feb 27 04:32:49 mars uptimec: The server requested that we do a new login Feb 27 04:33:00 mars kernel: maxproc limit exceeded by uid 0, please see tuning(7) and login.conf(5). Feb 27 04:33:10 mars kernel: maxproc limit exceeded by uid 60, please see tuning(7) and login.conf(5). Stupid question: why isn't there some mechanism that prevents new processes from starting up, instead of locking up the whole server? I'm not asking for ... Isn't that what is happening? When maxproc is hit, new processes can't be created. It is harmless, except for the uid that exceeded its process limit. I think the hang is some side-effect. Either because init can't fork a process, therefore there is nothing to login to. Did you try ping the system from remote to really see whether it was a solid hang? Or did you just pound on the keyboard? Or it is just a deadlock. That would be a bug. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
