ACPI debug on 7.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I am trying to debug ACPI but when recompile the acpi module with ACPI_DEBUG=1: link_elf: symbol AcpiDmDumpMethodInfo undefined KLD file acpi.ko - could not finalize loading This is on 7.0-PRERELEASE cvsup on 17.01 Any ideas? Best Regards -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHlvr/xJBWvpalMpkRAquAAJ47hs5ElVPW7bXD4zFq5u6gfQOZVgCfWuAP xKoilPSSkejrRJktiiqN0Dk= =EhM4 -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: 7.0 RC1/SPARC64 panic in boot [SOLVED]
On Jan 23, 2008, at 7:32 AM, Scott Long wrote:
Eirik Øverby wrote:
On Jan 22, 2008, at 7:23 PM, Marius Strobl wrote:
On Tue, Jan 22, 2008 at 07:16:16AM +0100, Eirik verby wrote:
Hi list,
by disabling the isp driver (set hint.isp.o.disabled=1), the
system comes up. This of course denies us access to the external
disk array hosted by the internal QLogic controller, but
pinpoints the problem.
We tried setting hint.isp.0.prefer_iomap=1, which made no
difference (though by reading the code, I don't see that it ever
used this).
Can anyone help us out here?
Scott, could this be due to a missing MFC of isp_sbus.c rev. 1.36?
If that would be the case I'd be most happy to hear that. I'll also
be more than happy to test, and can do so on relatively short
notice (at least for another few hours).
We have, for the record, gone through some basic troubleshooting:
Replaced memory (as this error also can show up under Solaris and
is usually an indicator of bad memory), replaced SCSI controller
with another one (still isp driven), and testing various device
hints - suffice to say we have wasted our time so far ;)
Are you able to compile a new kernel without having to install first?
if so, apply the attached patch and let me know if it works.
Works very well, thanks a bunch!
Will this make it into 7-RELEASE?
/Eirik
Scott
Index: isp_sbus.c
===
RCS file: /usr1/ncvs/src/sys/dev/isp/isp_sbus.c,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- isp_sbus.c 11 May 2007 13:47:28 - 1.35
+++ isp_sbus.c 5 Nov 2007 11:22:18 - 1.36
@@ -29,7 +29,7 @@
*/
#include sys/cdefs.h
-__FBSDID($FreeBSD: src/sys/dev/isp/isp_sbus.c,v 1.35 2007/05/11
13:47:28 mjacob Exp $);
+__FBSDID($FreeBSD: src/sys/dev/isp/isp_sbus.c,v 1.36 2007/11/05
11:22:18 scottl Exp $);
#include sys/param.h
#include sys/systm.h
@@ -327,21 +327,26 @@
/*
* Make sure we're in reset state.
*/
+ ISP_LOCK(isp);
isp_reset(isp);
if (isp-isp_state != ISP_RESETSTATE) {
isp_uninit(isp);
+ ISP_UNLOCK(isp);
goto bad;
}
isp_init(isp);
if (isp-isp_role != ISP_ROLE_NONE isp-isp_state !=
ISP_INITSTATE) {
isp_uninit(isp);
+ ISP_UNLOCK(isp);
goto bad;
}
isp_attach(isp);
if (isp-isp_role != ISP_ROLE_NONE isp-isp_state !=
ISP_RUNSTATE) {
isp_uninit(isp);
+ ISP_UNLOCK(isp);
goto bad;
}
+ ISP_UNLOCK(isp);
return (0);
bad:
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64
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: ACPI debug on 7.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Krassimir Slavchev wrote: Hi, I am trying to debug ACPI but when recompile the acpi module with ACPI_DEBUG=1: link_elf: symbol AcpiDmDumpMethodInfo undefined KLD file acpi.ko - could not finalize loading Removing 'options ACPI_DEBUG' from the kernel config file fixes this because for i386 acpi is not compiled into the kernel. Sorry for the noise :( This is on 7.0-PRERELEASE cvsup on 17.01 Any ideas? Best Regards ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHlyy2xJBWvpalMpkRAhHuAJsEDZLLDXr3pfnrslcRwU7vPf943ACfWwoh VL9OjTUxG5a1o7YhxNZlZhY= =gp7b -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]
'vidcontrol -m on' is killing my machine
Hi! I'm using a new HP 6715b notebook. When trying to use this with a docking station (PA286), the machine keeps hanging at message starting default moused:. The machine then just has died (I even can't break into debugger using ctrl+alt+esc). On investigation I figured out, `vidcontrol -m on' (called by /etc/rc.d/moused) is causing that freeze. Using an USB mouse, the system dies immediately when plugging in the mouse (starting ums0 moused: appears). Everything is fine when the system is undocked or moused _completely_ disabled. Running with WITNESS enabled does not give anything. Would INVARIANTS give me something here? FreeBSD cesar.sz.vwsoft.com 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #8: Tue Jan 22 01:29:52 CET 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CESAR i386 For now, I've commented out the vidcontrol call in /etc/rc.d/moused to work around that issue. Looking at the code in vidcontrol.c, I have no idea what might cause that as it's really simple code and basically just calling an IOCTL. The notebook has got an internal LCD with 1680x1050 and the docking station has a 1280x1024 display connected (what may get some code being confused?). What's going on there? Thx! Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.0-PRERELEASE desktop system periodically freezes momentarily
Doh! Now that I'm no longer using the 8 month old version of schedgraph.py that was displaying interesting but useless graphs, perhaps I won't continue to appear as though I'm raving like such a lunatic about what is contained in my ktr captures. Here follows a re-examination of the previously posted data with a recent schedgraph.py. Note that lacking any particular knowledge I'm only guessing at what might be significant. http://au.dyndns.ws/public/ktr-sched_gnome-netmonitor.out.bz2 (Stutter in glxgears with gnome metwork monitor) glxgears in runq for 236ms http://au.dyndns.ws/public/ktr-sched_move-glxgears_1.out.bz2 http://au.dyndns.ws/public/ktr-sched_move-glxgears_2.out.bz2 Nothing significant is apparent. http://au.dyndns.ws/public/ktr-sched_move-glxgears_3.out.bz2 (Dragging glxgears window which freezes - stops following mouse and stops updating, desktop doesn't respond to keyboard/mouse-clicks for the duration) glxgears in runq for 278ms and almost immediately again for 381ms. Note that this doesn't capture the entire period of interest which can be 1-2 seconds, due to the high number of context switches occurring with glxgears running and the difficulty of stopping the logging quickly after the event. I'll need a much larger (than 128k) buffer to catch an event in its entirety, unless someone can suggest a way to reduce the number of context switches significantly? http://au.dyndns.ws/public/ktr-sched-200801192346.out.bz2 Looks like this was probably just a mouse disconnect/reconnect - there is approx 1s of inactivity in irq20/ohci0 towards the end. Unfortunately these disconnects occur very frequently (typically multiple times per hour) since running with the KTR-enabled kernel (afaict). Unfortunately it looks as though that after gaining a false impression from this capture with the old schedgraph.py, I subsequently mis-interpreted numerous mouse disconnects as desktop freeze events. http://au.dyndns.ws/public/ktr-sched-200801200336.out.bz2 Looks like just another mouse disconnect. http://au.dyndns.ws/public/ktr-sched-200801200302.out.bz2 http://au.dyndns.ws/public/ktr-sched-200801210207.out.bz2 Nothing interesting is apparent. So it seems the only thing of interest that Ive managed to capture so far pertains to glxgears - an instance of the stutter and a part of a short freeze when dragging its window. Unfortunately these frequent mouse disconnects make it difficult to recognise genuine freezes during 'normal' use, if indeed they are still occurring with RELENG_7. However the glxgears behaviour remains (apparently) the same as it was on RELENG_6. Whether that's a telling sign or not remains to be seen. Wayne ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7-STABLE broke drscheme in week between 4 and 11 Jan
On Saturday 19 January 2008 08:29:41 pm Andrew Reilly wrote: Hi there, I'm still working on debugging this myself, but thought that a few more experienced eyes might be able to help me. I'm tracking 7-STABLE on my amd64 system, but something happened a couple of weeks ago that broke lang/drscheme. I've been doing a bit of regressing and testing, and have found that a mred executable built against a 7-STABLE checkout of 2008.01.04.00.00.00 works fine, but the exact same binary crashes with a SEGV on a kernel check-out of 2008.01.11.00.00.00. It's a bit hard to debug, because the code in question is a twisty maze of macros, #ifs and inlines, because it's in the garbage collector, and that's quite platform-sensitive. Anyway, the last part of the ktrace of the broken version (the earlier parts are just loading up shared libraries) looks like: (I sedded the ^pid out, so that I could get a better look at it with diff (meld, actually: it's nice)). There were changes to make binaries get SIGSEGV instead of SIGBUS (or vice versa) for certain VM-related traps. That might be related in which case the source code for the app will need to catch a different signal. You can test this by fiddling with the machdep.prot_fault_translation sysctl. So it looks as though it's in a section just before it establishes it's SIGSEGV handler, and so presumably isn't expecting to get segv'd just yet. If it hadn't been segv'd, the next thing to happen was that mredid mred CALL mmap(0,0x30,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,0x,0) the faulting instruction is: 0x000800bdecc6 GC_init_type_tags+598: mov %r13,(%rdx,%rax,8) r13 is 0x80390 rdx is -1 rax is 0xe40 Any thoughts on why that would be faulting? (Looks like a write to a very low address (code?) to me, but I'm not up on the VM map yet.) rdx should be a pointer to an array or some such, but it is a bogus pointer and that is why you are faulting. The only thing that looks appropriate that changed in that week was sys/vm/vm_map.c, which had some new code added to help with shm mappings. I looked at it, but it didn't look as though it would affect this. Those changes were only in HEAD, so if you are seeing them in your kernel you are running HEAD and not RELENG_7. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.3-RELEASE panic
On Monday 21 January 2008 04:51:54 pm Kris Kennaway wrote: Petr Holub wrote: Hi, I've just updated the 6.2-RELEASE to 6.3-RELEASE using freebsd-update as described in daemonology blog. While removing the old packages using pkg_delete -af I've tried to stop all the deamons from /usr/local/etc/rc.d and got the following panic (hand transcribed from a photo - I don't have that machine enabled for remote debugging). Panic seems to be deterministic when stopping those scripts (verified by subsequent attempts while pkg_delete was not running). (kgdb) bt #0 0xc06a46a6 in doadump () #1 0xc06a4b76 in boot () #2 0xc06a4e0c in panic () #3 0xc090d1b4 in trap_fatal () #4 0xc090cf1b in trap_pfault () #5 0xc090cb59 in trap () #6 0xc08f9fea in calltrap () #7 0xc073fa6f in in_delmulti () #8 0xc0748e15 in ip_freemoptions () #9 0xc07414cc in in_pcbdetach () #10 0xc075a0ee in udp_detach () #11 0xc06de0b8 in soclose () #12 0xc06cd83b in soo_close () #13 0xc0683ffc in fdrop_locked () #14 0xc0683f25 in fdrop () #15 0xc0682553 in closef () #16 0xc067f8e7 in kern_close () #17 0xc067f6d8 in close () #18 0xc090d4cb in syscall () #19 0xc08fa03f in Xint0x80_syscall () #20 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) Can you obtain a trace against the kernel.symbols? I've been seeing this panic (and several variations of) for quite a while on 6.x. It appears that a socket is being double-closed somehow. I usually see it during exit1() when a process' file descriptor table is being freed. I've spent a lot of time looking for a fd reference count leak or some such but haven't found one yet. :( I've also seen panics with vnodes having a ref cnt underflow in vrele or vput, so I've wondered if it's a fd-level bug that affects both vnodes and sockets rather than separate socket and vnode bugs. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell PERC6?
On Sunday 20 January 2008 09:50:36 am Jeremy Chadwick wrote: On Fri, Jan 18, 2008 at 10:35:21AM +0100, Ferdinand Goldmann wrote: Jeremy Chadwick wrote: You'd be best off with RELENG_7 and not 6.3, but yes, the controller in question should work on RELENG_6 and RELENG_6_3. Very well, seems like I am going to give RELENG_7 a try then. Thanks to everyone who replied! Another user just posted to -stable about problems with these Dell machines and PERC6. I'm not sure if you're subscribed to -stable or not, so here's the thread: http://lists.freebsd.org/pipermail/freebsd-stable/2008-January/039791.html The problem folks are having are with using volumes greater than 1 TB. The BSD label cannot handle such large disks. Instead, if you are just using the disk for data you can newfs /dev/mfid1 directly and use it as a filesystem, or if you need to partition the disk you can use gpt(8) to do so. If you need to boot from such a large disk you will need to use the GPT boot code in HEAD (I will backport it to 6.x and 7.x soon). I've successfully used it to boot on 2 TB mfi(4) volumes. Unfortunately sysinstall doesn't support GPT at all, only the older MBR + BSD label method. Note that this problem has nothing to do with mfi(4) at all, but it is a limitation of the BSD label + MBR that applies to any volume = 2 TB. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell Perc 6 disk geometry problem with RAID5 (both 6.3 final and 7.0 RC1)
On Sunday 20 January 2008 01:53:30 pm David Wood wrote: Hi there, In message [EMAIL PROTECTED], Erik Trulsson [EMAIL PROTECTED] writes On Sun, Jan 20, 2008 at 04:48:56PM +, David Wood wrote: In message [EMAIL PROTECTED], Aldas Nabazas [EMAIL PROTECTED] writes We bought a new Dell PowerEdge 2950III with Perc 6/i and have the disk geometry problem using 6.3 final or 7.0 RC1. Seems that we are not alone at least one guy has similar problem reported earlier: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/questions/2008-01/msg0 0506.html I do not know if the mfi(4) driver has any problems with large disks, but it is however well known that fdisk(8) and bsdlabel(8) (the tools normally used to partition disks) have problems with volumes larger than 2TB. If you want to use volumes larger than 2TB then gpt(8) is the recommended way to partition the disks. It is however doubtful if the BIOS in your system will allow you to boot from a gpt(8) parttioned volume which is best solved with having a separate - smaller - boot volume where the OS itself is installed. Erik's reminder is timely for those with 2TB volumes. You must use gpt and not fdisk on any disk, be it a single drive (in the future, at least!) or a virtual disk on a RAID setup that are bigger than 2TB. It may be wise to use gpt on any virtual disk that you might grow to 2TB or larger in the future, so long as you're not needing to boot from that virtual disk. fdisk will not work properly with 2TB and larger volumes - the MBR / partition table setup can't cope with these large volumes. You can't boot from a GPT volume - that's a limitation of the BIOS architecture. There is some thought about using EFI on x64 hardware in the future (EFI is used on ia64 hardware; GPT is part of EFI), but we're not there yet. This isn't just about adding GPT support to the BIOS - the whole BIOS setup is wedded to MBR. If you need to boot from a 2TB array, create two virtual disks - one smaller than 2TB to boot from (and use MBR on that), then the residue can be GPT. Actually, using gptboot in HEAD you can now boot from GPT on large volumes (I've booted from a 2 TB volume on a PERC5 using mfi(4) with it). I will see about getting that merged back to 6.x and 7.x in CVS. We use it for large volumes on 6.x and all volumes on 7.x at work. When I said there was nothing relevant waiting for MFC, I was aware of the change that Tom mentioned, but that seems to be about Dell PERC 6 being identified as such rather than a MegaRAID. It doesn't seem that it will change the behaviour of the driver in any way. In our testing at work the 2950 rev 3's worked fine with mfi(4). -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: bad pte
On Sunday 20 January 2008 11:57:29 am Mikhail Teterin wrote: Hello! Is this something, that should be fixed in the 6.3? The kernel is 6.2-STABLE from June (see uptime). Thanks! What kind of CPU? There was a fix for a certain edge condition in 6.x post 6.2, but usually when I see this panic it is due to a hardware failure. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NO_ knobs in /etc/make.conf
On Tuesday 22 January 2008 12:36:47 pm Vivek Khera wrote: On Jan 21, 2008, at 3:34 PM, Doug Barton wrote: There is a cross-reference to src.conf(5) at the end of make.conf(5), but IMO the connection needs to be made more explicit. Anyone want to take that on? This should also go in the release notes if it's not already. So do I need to move my settings from make.conf to src.conf, or can I just leave it as-is and not worry about it. Reading the make.conf man page implies it will just continue to work without change. You can just s/NO_/WITHOUT_/g on your /etc/make.conf and leave them there. What was broken that required this to be fixed? Inconsistent use of what NO_FOO= meant. Some places only checked if it was set, other places required it to be set to yes, so NO_FOO=no might disable FOO or it might not. The WITHOUT_* / WITH_* scheme was chosen to be compatible with how ports works. If WITHOUT_FOO is defined then FOO is disabled. If WITH_FOO is defined, then FOO is enabled. The WITH_FOO/WITHOUT_FOO variables end up setting an internal MK_FOO variable to yes or no and the actual Makefiles for FOO compare MK_FOO to yes to see if they should build. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.3-RELEASE panic
On Monday 21 January 2008 07:13:26 pm Kris Kennaway wrote: Colin Percival wrote: Kris Kennaway wrote: Petr Holub wrote: as I've said in my previous email (outside the list), I've got the kernel through freebsd-update and it seems there is no kernel.debug nor kernel.symbols present. Would it be possible to get the .symbols or .debug for that kernel? (See my previuous email with more detailed info). Ah, I missed that, sorry. Colin hopefully will have the kernel.debug handy. I'm afraid not -- FreeBSD Update is just distributing the bits from the release ISO image, and the release ISO doesn't include kernel debug bits (at least, not on 6.3-RELEASE -- I think it does on 7.0-RC1). I thought we shipped the debugging symbols in /boot precisely for the reason of making panics with default installs not report useless traces :( In the past re@ has removed the 'makeoptions DEBUG=-g' from GENERIC when making a stable branch. 6.x doesn't have the foo.symbols changes in it either. It's too late for 6.3, but we should make sure 7.0 has symbols enabled by default still. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.3-RELEASE panic
On Tuesday 22 January 2008 05:27:36 am Petr Holub wrote: I thought we shipped the debugging symbols in /boot precisely for the reason of making panics with default installs not report useless traces :( I think building GENERIC kernel from sources with tag=RELENG_6_3_0_RELEASE will help. I tried to build it from the sources that come from the freebsd-update and thus I assume they are actually RELENG_6_3_0_RELEASE. Still I was unable to run gdb with the given vmcore against such a kernel. You will need to build a debug kernel and reproduce the panic and use kgdb on the new crash with the new kernel. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 6.3-Release + squid 2.6.17 = Hang process.
Hi: We have a machine running 6.2-R-p10 and squid 2.6.17, and upgrade it to 6.3R yesterday, but squid will hang and eat 100% cpu time after restart about 1 hour later, machine still alive, and no response from squid. downgrade to 6.2-R-p10, everything ok again.. here is some infomations: machine type: FreeBSD 6.3-RELEASE #0: Wed Jan 23 01:58:39 CST 2008 CPU: Intel(R) Xeon(TM) CPU 2.40GHz (2399.33-MHz 686-class CPU) real memory = 3221159936 (3071 MB) top: PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 8674 squid 1 1210 105M 100M CPU3 1 0:26 98.54% squid truss: (no response) [EMAIL PROTECTED]:~#truss -p 8674 gdb: (gdb) bt #0 0x881679eb in pthread_sigmask () from /lib/libpthread.so.2 #1 0x8816799c in sigprocmask () from /lib/libpthread.so.2 #2 0x88172544 in pthread_mutexattr_init () from /lib/libpthread.so.2 #3 0x88164680 in fork () from /lib/libpthread.so.2 #4 0x08091091 in ?? () #5 0x0012 in ?? () #6 0x0004 in ?? () #7 0x080e6edb in ?? () #8 0xbfbfe4a4 in ?? () #9 0x0004 in ?? () #10 0x in ?? () netstat -h 8: 118K 037M 204K 0 262M 0 121K 037M 204K 0 255M 0 124K 030M 204K 0 248M 0 116K 036M 201K 0 257M 0 117K 040M 202K 0 260M 0 120K 045M 205K 0 261M 0 120K 049M 201K 0 253M 0 106K 041M 178K 0 224M 0 6.8K 0 3.1M 7.4K 0 5.7M 0 5.5K 0 3.2M 5.9K 0 3.5M 0 3.4K 0 1.6M 3.5K 0 1.6M 0 4.3K 0 2.5M 4.8K 0 2.5M 0 3.8K 0 2.2M 4.3K 0 2.2M 0 3.5K 0 1.7M 3.8K 0 1.9M 0 2.4K 0 857K 2.5K 0 948K 0 2.2K 0 593K 2.2K 0 586K 0 we try to use libmap.conf to make squid use libthr, but still hang... -- thanks. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell PERC6?
On Jan 23, 2008 1:58 PM, John Baldwin [EMAIL PROTECTED] wrote: On Sunday 20 January 2008 09:50:36 am Jeremy Chadwick wrote: On Fri, Jan 18, 2008 at 10:35:21AM +0100, Ferdinand Goldmann wrote: Jeremy Chadwick wrote: You'd be best off with RELENG_7 and not 6.3, but yes, the controller in question should work on RELENG_6 and RELENG_6_3. Very well, seems like I am going to give RELENG_7 a try then. Thanks to everyone who replied! Another user just posted to -stable about problems with these Dell machines and PERC6. I'm not sure if you're subscribed to -stable or not, so here's the thread: http://lists.freebsd.org/pipermail/freebsd-stable/2008-January/039791.html The problem folks are having are with using volumes greater than 1 TB. The BSD label cannot handle such large disks. Instead, if you are just using the disk for data you can newfs /dev/mfid1 directly and use it as a filesystem, or if you need to partition the disk you can use gpt(8) to do so. If you need to boot from such a large disk you will need to use the GPT boot code in HEAD (I will backport it to 6.x and 7.x soon). I've successfully used it to boot on 2 TB mfi(4) volumes. Unfortunately sysinstall doesn't support GPT at all, only the older MBR + BSD label method. Note that this problem has nothing to do with mfi(4) at all, but it is a limitation of the BSD label + MBR that applies to any volume = 2 TB. Hi John, It seems that the problem is exactly as you described as i was able to get everything working setting 2x146 disks as RAID1 and 4x146 as RAID5. Regards, Aldas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.0-PRERELEASE desktop system periodically freezes momentarily
Wayne Sierke wrote: So it seems the only thing of interest that Ive managed to capture so far pertains to glxgears - an instance of the stutter and a part of a short freeze when dragging its window. Unfortunately these frequent mouse disconnects make it difficult to recognise genuine freezes during 'normal' use, if indeed they are still occurring with RELENG_7. However the glxgears behaviour remains (apparently) the same as it was on RELENG_6. Whether that's a telling sign or not remains to be seen. Wayne, thanks for continuing to investigate, since these little freezes definitely affect usability. If I can help in any way, let me know. I have not made any further graphs, but I continue to see intermittent mouse freezing (for short sub-seconf periods, usually). As for mouse disconnects, I don't know if that is what I am seeing, but one thing I do notice is that the keyboard is also affected (easily seen by holding down a key and letting it repeat - short pauses can be seen in the echo, which could be xterm, X, or the keyboard input, of course). Also, I tried unplugging my ps/2 mouse and using a USB one instead - same issue exists. In case this is scheduler-related, I tried running a CPU-hogging task (xtrs in model 4 mode, which spins, polling for input). While running this and moving the mouse rapidly between two windows (I use focus-under-mouse, so this causes focus events), I eventually get repeated short mouse freezes for quite some time (maybe 10 seconds) until things can catch up. This is not reproducible on Linux CFS (2.6.23) - the CPU use certainly affects event catching up in X, but the mouse stays smooth. Also, it seems that intermittent mouse freezes happen more often when I've been away from the machine for a while and return to start using the mouse again, but that's not always the case. A few short freezes/stutters happen a second or so after mouse movement resumes. -Joe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell Perc 6 disk geometry problem with RAID5 (both 6.3 final and 7.0 RC1)
On Jan 23, 2008 2:19 PM, John Baldwin [EMAIL PROTECTED] wrote: On Sunday 20 January 2008 01:53:30 pm David Wood wrote: Hi there, In message [EMAIL PROTECTED], Erik Trulsson [EMAIL PROTECTED] writes On Sun, Jan 20, 2008 at 04:48:56PM +, David Wood wrote: In message [EMAIL PROTECTED] , Aldas Nabazas [EMAIL PROTECTED] writes We bought a new Dell PowerEdge 2950III with Perc 6/i and have the disk geometry problem using 6.3 final or 7.0 RC1. Seems that we are not alone at least one guy has similar problem reported earlier: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/questions/2008-01/msg0 0506.html I do not know if the mfi(4) driver has any problems with large disks, but it is however well known that fdisk(8) and bsdlabel(8) (the tools normally used to partition disks) have problems with volumes larger than 2TB. If you want to use volumes larger than 2TB then gpt(8) is the recommended way to partition the disks. It is however doubtful if the BIOS in your system will allow you to boot from a gpt(8) parttioned volume which is best solved with having a separate - smaller - boot volume where the OS itself is installed. Erik's reminder is timely for those with 2TB volumes. You must use gpt and not fdisk on any disk, be it a single drive (in the future, at least!) or a virtual disk on a RAID setup that are bigger than 2TB. It may be wise to use gpt on any virtual disk that you might grow to 2TB or larger in the future, so long as you're not needing to boot from that virtual disk. fdisk will not work properly with 2TB and larger volumes - the MBR / partition table setup can't cope with these large volumes. You can't boot from a GPT volume - that's a limitation of the BIOS architecture. There is some thought about using EFI on x64 hardware in the future (EFI is used on ia64 hardware; GPT is part of EFI), but we're not there yet. This isn't just about adding GPT support to the BIOS - the whole BIOS setup is wedded to MBR. If you need to boot from a 2TB array, create two virtual disks - one smaller than 2TB to boot from (and use MBR on that), then the residue can be GPT. Actually, using gptboot in HEAD you can now boot from GPT on large volumes (I've booted from a 2 TB volume on a PERC5 using mfi(4) with it). I will see about getting that merged back to 6.x and 7.x in CVS. We use it for large volumes on 6.x and all volumes on 7.x at work. When I said there was nothing relevant waiting for MFC, I was aware of the change that Tom mentioned, but that seems to be about Dell PERC 6 being identified as such rather than a MegaRAID. It doesn't seem that it will change the behaviour of the driver in any way. In our testing at work the 2950 rev 3's worked fine with mfi(4). -- John Baldwin Hi John, Nice to hear that. Regards, Aldas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NO_ knobs in /etc/make.conf
On Jan 23, 2008, at 9:24 AM, John Baldwin wrote: What was broken that required this to be fixed? Inconsistent use of what NO_FOO= meant. Some places only checked if it was set, other places required it to be set to yes, so NO_FOO=no might disable FOO or it might not. The WITHOUT_* / WITH_* scheme was I guess I wasn't clear about my confusion. What was broken about putting all this in make.conf that necessitated a src.conf file too? Having the names consistent is great, though. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Latest Stable FreeBSD release and is it supported on dell 2950
On Jan 23, 2008, at 12:30 AM, navneet Upadhyay wrote: Hi , I have following questions. 1. Which is the latest release of FreeBSD. 2. When was it released? 3. What is the patch level? 4.What is the stability See http://www.freebsd.org/ for above. Short answer: 6.3 released last week. 5. Which compiler to use: cc or gcc and which version . cc == gcc on freebsd. Unless your app requires a specific gcc version, just use the one the system installs for you. 6. Which platform/machine which BSD supports. Is Dell 2950 ok I've only ever had one compatibility issue with a Dell, and that was easily fixed by teaching the bge ethernet driver the name of the chipset used on that particular box. I have a PE1900 here we just got and it runs 7.0-RC1 quite nicely. In general, unless you're running some obscure devices, FreeBSD works just fine with most systems. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Latest Stable FreeBSD release and is it supported on dell 2950
Vivek Khera wrote: On Jan 23, 2008, at 12:30 AM, navneet Upadhyay wrote: SNIP 6. Which platform/machine which BSD supports. Is Dell 2950 ok I've only ever had one compatibility issue with a Dell, and that was easily fixed by teaching the bge ethernet driver the name of the chipset used on that particular box. I have a PE1900 here we just got and it runs 7.0-RC1 quite nicely. In general, unless you're running some obscure devices, FreeBSD works just fine with most systems. PE2950's use the bce driver, which works fine with 6.3+ Tom J ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.3-RELEASE panic
On January 23, 2008, John Baldwin wrote: On Monday 21 January 2008 04:51:54 pm Kris Kennaway wrote: Petr Holub wrote: Hi, I've just updated the 6.2-RELEASE to 6.3-RELEASE using freebsd-update as described in daemonology blog. While removing the old packages using pkg_delete -af I've tried to stop all the deamons from /usr/local/etc/rc.d and got the following panic (hand transcribed from a photo - I don't have that machine enabled for remote debugging). Panic seems to be deterministic when stopping those scripts (verified by subsequent attempts while pkg_delete was not running). (kgdb) bt #0 0xc06a46a6 in doadump () #1 0xc06a4b76 in boot () #2 0xc06a4e0c in panic () #3 0xc090d1b4 in trap_fatal () #4 0xc090cf1b in trap_pfault () #5 0xc090cb59 in trap () #6 0xc08f9fea in calltrap () #7 0xc073fa6f in in_delmulti () #8 0xc0748e15 in ip_freemoptions () #9 0xc07414cc in in_pcbdetach () #10 0xc075a0ee in udp_detach () #11 0xc06de0b8 in soclose () #12 0xc06cd83b in soo_close () #13 0xc0683ffc in fdrop_locked () #14 0xc0683f25 in fdrop () #15 0xc0682553 in closef () #16 0xc067f8e7 in kern_close () #17 0xc067f6d8 in close () #18 0xc090d4cb in syscall () #19 0xc08fa03f in Xint0x80_syscall () #20 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) Can you obtain a trace against the kernel.symbols? I've been seeing this panic (and several variations of) for quite a while on 6.x. It appears that a socket is being double-closed somehow. I usually see it during exit1() when a process' file descriptor table is being freed. I've spent a lot of time looking for a fd reference count leak or some such but haven't found one yet. :( I've also seen panics with vnodes having a ref cnt underflow in vrele or vput, so I've wondered if it's a fd-level bug that affects both vnodes and sockets rather than separate socket and vnode bugs. For comparison, here is the callstack from the panic reported in kern/116077. The PR has symbolic information. #0 doadump () #1 0xc055293e in boot #2 0xc0552c95 in panic #3 0xc06e6232 in trap_fatal #4 0xc06e5f3b in trap_pfault #5 0xc06e5b51 in trap #6 0xc06d0b1a in calltrap () #7 0xc05e3e6f in in_delmulti #8 0xc05ed8e9 in ip_freemoptions #9 0xc05e5d6c in in_pcbdetach #10 0xc05fee96 in udp_detach #11 0xc058e710 in soclose #12 0xc057db3f in soo_close #13 0xc052fd9c in fdrop_locked #14 0xc052fcc5 in fdrop #15 0xc052e263 in closef #16 0xc052d253 in fdfree #17 0xc0536b4b in exit1 #18 0xc05366b0 in sys_exit #19 0xc06e6577 in syscall #20 0xc06d0b6f in Xint0x80_syscall () #21 0x0033 in ?? () It is also triggered when a multi-cast client shuts down. The patch in the PR fixes this issue for me. I have been running with it since November. Cheers. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7-PRERELEASE Xorg - Fatal server error:could not open default font 'fixed'[SOLVED]
Quoting Kimi [EMAIL PROTECTED]: On 20/01/2008, Chris H. [EMAIL PROTECTED] wrote: Quoting Kimi [EMAIL PROTECTED]: On 20/01/2008, Chris H. [EMAIL PROTECTED] wrote: Greetings, Well, after not having any luck with Xorg after a fresh install of 7. I decided to try a more recent cvsup of the ports tree and [...] you need ports/x11-fonts/font-alias Thank you! You rock! That did it. You're the best. :) I can't believe I overlooked that. it bugged me like crazy when I could not find what it was causing the problem, even after installing all the misc fonts. ports should handle this dependency better, which means I should open a PR but never got around to it. You know, I'm /quite/ embarrassed about this one. Last year I wrote a /very/ long, and informative how-to for adding fonts to X. I gave a fair amount of background on the whole process too - including debugging the results of each step. You'd think I'd have figured this out on my own. :P Problem was - I /assumed/ that installing xorg-server, xorg-apps, and xorg-libraries would have /included/ all the prerequisites - D'oh! Anyway, looks like I have something else to add to that how-to. :) Thanks again for taking the time to help me out on this one. --Chris --Chris -- panic: kernel trap (ignored) -- Regards, Kimi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: bad pte
середа 23 січень 2008 09:20 до, John Baldwin Ви написали: Is this something, that should be fixed in the 6.3? The kernel is 6.2-STABLE from June (see uptime). What kind of CPU? Dual Opteron. FreeBSD/amd64. There was a fix for a certain edge condition in 6.x post 6.2, but usually when I see this panic it is due to a hardware failure. In the controller? It is a newish ahd (although from eBay) -- what could be wrong? Thanks! -mi ## The information contained in this communication is confidential and may contain information that is privileged or exempt from disclosure under applicable law. If you are not a named addressee, please notify the sender immediately and delete this email from your system. If you have received this communication, and are not a named recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. ## ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.0-PRERELEASE desktop system periodically freezes momentarily
On Wed, 23 Jan 2008 08:27:58 -0700, Joe Peterson [EMAIL PROTECTED] wrote: Also, it seems that intermittent mouse freezes happen more often when I've been away from the machine for a while and return to start using the mouse again, but that's not always the case. A few short freezes/stutters happen a second or so after mouse movement resumes. -Joe Joe, I don't see any postings from you showing any ktr dumps. Do you have any? Your symptoms (that it seems to happen after you've been away for a while and then return and move the mouse) sound a lot like mine. I posted some ktr dumps and have since chatted off-list with Kris and Sam about what may be up. My dumps show the shared irq ath/pcm and the ath taskq are hogging the cpu for ages without the clock swi getting to run at all. Sam has suggested experimenting with the ath taskq priority and also with disabling ath bg scans which I will do, but right now I am back to looking at powerd again as the possible cause. I ran without powerd for a while when originally suggested by David Lawrence on Jan 12th. I believe I did still see freezes then, but I re-enabled powerd when I was ready to do LOCK_PROFILING and then ktr monitoring; I re-enabled it so I could be sure I had the same test conditions. At this point, I am no longer sure what happened when powerd was disabled. My recollection is that there were freezes while powerd was off, but the only email in which I appear to have posted about that says no freezes so far. So I'm running without powerd again, and at this point, several hours at the computer over two days, I have not seen further freezes. Does anyone else who sees these freezes also have powerd enabled and can try without powerd for a while? Since these freezes are proving so hard to pinpoint, it may be worth comparing notes to try to find things in common between the systems or eliminate other things. But first, it seems like we may be chasing three separate causes: 1. the softupdate freeze after removing a very large file (e.g., 1Gb) there is a noticeable freeze while the softupdate runs 2. the busy freeze folk complain of short freezes and mouse jerkiness while the system is busy, e.g., glxgears or compilations 3. the idle freeze short and longer freezes (some going into minutes) apparently when resuming work after having left the system mostly idle for a while Now, I also had the busy freeze when I first tested 7.0. At that time (several weeks back now) someone suggested switching to the ULE scheduler, which I did, and the symptoms I had were dramatically improved. Since then I've had occasions to run several compilations at once and had no mouse jerkiness. But for folk who still have it: what scheduler do you have and what processes are running when it happens? At the moment, I'm chasing an idle freeze. In other emails, I've posted details of what processes are typically running and several ktr dumps of such events. As noted, I'm looking again into powerd right now, and if that isn't it, I'll go to the ath taskq prio and scan stuff that Sam suggested. Anyone else with an idle freeze care to post details of what scheduler and processes are in use? -jr signature.asc Description: PGP signature
Re: 7.0-PRERELEASE desktop system periodically freezes momentarily
J.R. Oldroyd wrote: On Wed, 23 Jan 2008 08:27:58 -0700, Joe Peterson [EMAIL PROTECTED] wrote: Also, it seems that intermittent mouse freezes happen more often when I've been away from the machine for a while and return to start using the mouse again, but that's not always the case. A few short freezes/stutters happen a second or so after mouse movement resumes. -Joe Joe, I don't see any postings from you showing any ktr dumps. Do you have any? Your symptoms (that it seems to happen after you've been away for a while and then return and move the mouse) sound a lot like mine. Hi J.R., here is the post that contains links to my dumps: http://lists.freebsd.org/pipermail/freebsd-stable/2008-January/039599.html I posted some ktr dumps and have since chatted off-list with Kris and Sam about what may be up. My dumps show the shared irq ath/pcm and the ath taskq are hogging the cpu for ages without the clock swi getting to run at all. Sam has suggested experimenting with the ath taskq priority and also with disabling ath bg scans which I will do, but right now I am back to looking at powerd again as the possible cause. Hmm, well I don't have an Atheros on this machine - only ethernet. Also, I have not tried playing audio, so what I am seeing is simply with normal use. I ran without powerd for a while when originally suggested by David Lawrence on Jan 12th. I believe I did still see freezes then, but I re-enabled powerd when I was ready to do LOCK_PROFILING and then ktr monitoring; I re-enabled it so I could be sure I had the same test conditions. At this point, I am no longer sure what happened when powerd was disabled. My recollection is that there were freezes while powerd was off, but the only email in which I appear to have posted about that says no freezes so far. So I'm running without powerd again, and at this point, several hours at the computer over two days, I have not seen further freezes. Does anyone else who sees these freezes also have powerd enabled and can try without powerd for a while? Mine is a desktop machine, so I have not enabled powerd. Since these freezes are proving so hard to pinpoint, it may be worth comparing notes to try to find things in common between the systems or eliminate other things. But first, it seems like we may be chasing three separate causes: 1. the softupdate freeze after removing a very large file (e.g., 1Gb) there is a noticeable freeze while the softupdate runs 2. the busy freeze folk complain of short freezes and mouse jerkiness while the system is busy, e.g., glxgears or compilations 3. the idle freeze short and longer freezes (some going into minutes) apparently when resuming work after having left the system mostly idle for a while Now, I also had the busy freeze when I first tested 7.0. At that time (several weeks back now) someone suggested switching to the ULE scheduler, which I did, and the symptoms I had were dramatically improved. Since then I've had occasions to run several compilations at once and had no mouse jerkiness. But for folk who still have it: what scheduler do you have and what processes are running when it happens? I seem to see #2 (busy freezes). They are usually very short (sub-second) freezes, and they happen randomly as I move the mouse (well, I assume that I see it manifested in a mouse freeze, but it could very well be a system or X freeze, since I see it in keyboard key-held-down too). The mouse usually moves smoothly, but every once in a while, it sticks for a fraction of a second as I move it - irritating to say the least. Often the small freezes come in spurts, but they often are one at a time as well. When it comes in spurts, it is often shortly after moving the mouse after lots of idle time (as if the scheduler wakes up and has some fits for a short time - a non-scientific description ;). I am using ULE on 7.0. I'm also using ZFS (so the soft-updates issue doesn't apply, and I spoke with someone else who uses UFS2, not ZFS, and he said the mouse jerked around pretty badly in 7.0 on his machine). I started with using 4BSD under 7.0, of course, and yes, there were worse batches of freezes with it, especially when starting KDE and when compiling the kernel (it was nearly constant). With ULE, I no longer see compiles causing freezes, and generally the freezes are more subtle and shorter - in other words, ULE *is* better than 4BSD in this respect, but it is still worse than normal operation under FreeBSD 6.2 with 4BSD (although under 6.2/4BSD, I did see the occasional freeze during compiles - not nearly as obvious or often as 4BSD under 7.0). So, in my experience: 6.2/4BSD: smooth mouse motion all of the time except rare freezes during compiles. 7.0/4BSD: terrible mouse jerkiness under any load, especially when compiling. 7.0/ULE: smoother than 7.0/4BSD
Re: FreeBSD 6.3-Release + squid 2.6.17 = Hang process.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vanilla Hsu wrote: Hi: We have a machine running 6.2-R-p10 and squid 2.6.17, and upgrade it to 6.3R yesterday, but squid will hang and eat 100% cpu time after restart about 1 hour later, machine still alive, and no response from squid. downgrade to 6.2-R-p10, everything ok again.. Just wanted to narrow down the problem, is it possible for you to try if it's within the kernel (say, use 6.2 userland and squid binary under 6.3 kernel)? Cheers, - -- Xin LI [EMAIL PROTECTED] http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHl5a9i+vbBBjt66ARArAZAKCiM35r8fGFCXFa2mbbUDHOCUpvywCgst+X pBdyNQ5ir4LhtYdyUPc80uk= =7kgd -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: firefox-2.0.0.11_1, 1 refuses to build because PORT_REPLACES_BASE_BIND
Peter Jeremy wrote: On Tue, Jan 22, 2008 at 05:09:23PM +, Robert Jameson wrote: I ran into a problem today trying to build the latest firefox in ports firefox-2.0.0.11_1,1. ... firefox-2.0.0.11_1,1: bind installed with PORT_REPLACES_BASE_BIND causes build problems. That seems fairly self-explanatory to me and has been the case for over two years. (The relevant test is at the end of the gecko-post-patch target in www/mozilla/Makefile.common). FYI, if the ports freeze ever ends I plan to split the bind94 port into binaries and libs, and turn off the installation of libs and headers for bind9; so this test will need to be adjusted. Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NO_ knobs in /etc/make.conf
Vivek Khera wrote: I guess I wasn't clear about my confusion. What was broken about putting all this in make.conf that necessitated a src.conf file too? One could argue that they didn't need to be moved at all. One of the rationales at the time was that we didn't want the knobs for the base to affect the ports. Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
6.3-RELEASE can not mount root on Cyrix 5530 ATA33 controller
Hello, I updated my Geode GX1 PC from RELENG_6_2 to RELENG_6_3 and found root mount failed after reboot. This problem was caused by a change to ata-pci.c to pick up wider old ata controller as ata-pci devices at ata_legacy() function, and roll backing that file resolved this problem for me. I'm not sure why attaching Cyrix 5530 ATA33 controller was failed at both 6.2 and 6.3, but I hope this contoller goes to work as an ATA33 controller. Making buildworld requires more than 24hours with PIO HDD... Is there anyone who has some information about this controller? Thanks, Here are the dmesgs: [RELENG_6_2] FreeBSD 6.2-RELEASE-p7 #0: Sun Aug 5 21:43:36 JST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CBUG_XCAST6 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Cyrix GXm (300.68-MHz 586-class CPU) Origin = CyrixInstead Id = 0x540 DIR=0x8244 Stepping=8 Revision=2 ... atapci0: Cyrix 5530 ATA33 controller port 0xf000-0xf00f at device 18.2 on pci0 atapci0: unable to map interrupt device_attach: atapci0 attach returned 6 ... ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata1 at port 0x170-0x177,0x376 irq 15 on isa0 ... ad0: 38154MB WDC WD400UE-22HCT0 09.07D09 at ata0-master PIO4 [RELENG_6_3] FreeBSD 6.3-RELEASE #5: Wed Jan 23 01:53:05 JST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CBUG_XCAST6 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Cyrix GXm (300.68-MHz 586-class CPU) Origin = CyrixInstead Id = 0x540 DIR=0x8244 Stepping=8 Revision=2 ... atapci0: Cyrix 5530 ATA33 controller port 0xf000-0xf00f at device 10.2 on pci0 ata0: ATA channel 0 on atapci0 device_attach: ata0 attach returned 6 ata1: ATA channel 1 on atapci0 device_attach: ata1 attach returned 6 ... Trying to mount root from ufs:/dev/ad0s1a Manual root filesystem specification: fstype:device Mount device using filesystem fstype eg. ufs:da0s1a ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
snd_emu10k1.ko after 6.2 to 6.3 upgrade
Hi, I've found a problem after updating from 6.2-RELEASE to 6.3-RELEASE using freebsd-update as described on daemonology blog. It looks like if the snd_emu10k1.ko along with a few others was not appropriately updated: # ls -l snd_* -r-xr-xr-x 1 root wheel 16566 Feb 20 2007 snd_ad1816.ko -r-xr-xr-x 1 root wheel 17731 Feb 20 2007 snd_als4000.ko -r-xr-xr-x 1 root wheel 20004 Jan 21 15:42 snd_atiixp.ko -r-xr-xr-x 1 root wheel 19192 Feb 20 2007 snd_cmi.ko -r-xr-xr-x 1 root wheel 18594 Feb 20 2007 snd_cs4281.ko -r-xr-xr-x 1 root wheel 30814 Feb 20 2007 snd_csa.ko -r-xr-xr-x 1 root wheel 11098 Jan 21 15:42 snd_driver.ko -r-xr-xr-x 1 root wheel 45839 Feb 20 2007 snd_ds1.ko -r-xr-xr-x 1 root wheel 30008 Feb 20 2007 snd_emu10k1.ko -r-xr-xr-x 1 root wheel 59398 Feb 20 2007 snd_emu10kx.ko -rwxr-xr-x 1 root wheel 31223 Jan 21 15:42 snd_envy24.ko -rwxr-xr-x 1 root wheel 30504 Jan 21 15:42 snd_envy24ht.ko -r-xr-xr-x 1 root wheel 32005 Feb 20 2007 snd_es137x.ko -r-xr-xr-x 1 root wheel 20075 Feb 20 2007 snd_ess.ko -r-xr-xr-x 1 root wheel 15636 Feb 20 2007 snd_fm801.ko -rwxr-xr-x 1 root wheel 77423 Jan 21 15:42 snd_hda.ko -r-xr-xr-x 1 root wheel 23812 Jan 21 15:42 snd_ich.ko -r-xr-xr-x 1 root wheel 31117 Feb 20 2007 snd_maestro.ko -r-xr-xr-x 1 root wheel 42945 Jan 21 15:42 snd_maestro3.ko -r-xr-xr-x 1 root wheel 46976 Feb 20 2007 snd_mss.ko -r-xr-xr-x 1 root wheel 68790 Feb 20 2007 snd_neomagic.ko -r-xr-xr-x 1 root wheel 14783 Feb 20 2007 snd_null.ko -r-xr-xr-x 1 root wheel 16934 Feb 20 2007 snd_sb16.ko -r-xr-xr-x 1 root wheel 15418 Feb 20 2007 snd_sb8.ko -r-xr-xr-x 1 root wheel 15397 Feb 20 2007 snd_sbc.ko -r-xr-xr-x 1 root wheel 19397 Feb 20 2007 snd_solo.ko -r-xr-xr-x 1 root wheel 7240 Jan 21 15:42 snd_spicds.ko -r-xr-xr-x 1 root wheel 18856 Jan 21 15:42 snd_t4dwave.ko -r-xr-xr-x 1 root wheel 36300 Jan 21 15:42 snd_uaudio.ko -r-xr-xr-x 1 root wheel 21918 Jan 21 15:42 snd_via8233.ko -r-xr-xr-x 1 root wheel 16075 Jan 21 15:42 snd_via82c686.ko -r-xr-xr-x 1 root wheel 18707 Feb 20 2007 snd_vibes.ko Those modules dated Feb 20 2007 are not loadable actually: # kldload snd_emu10k1.ko kldload: can't load snd_emu10k1.ko: No such file or directory When I build the module from source, it loads just fine. Maybe some bug in the freebsd-update list of what to update? Just for your reference, sound.ko has been updated properly and can be loaded fine. Petr ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.3-RELEASE can not mount root on Cyrix 5530 ATA33 controller
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yoshihiko Sarumaru wrote: Hello, I updated my Geode GX1 PC from RELENG_6_2 to RELENG_6_3 and found root mount failed after reboot. This problem was caused by a change to ata-pci.c to pick up wider old ata controller as ata-pci devices at ata_legacy() function, and roll backing that file resolved this problem for me. Which revision? I'm not sure why attaching Cyrix 5530 ATA33 controller was failed at both 6.2 and 6.3, but I hope this contoller goes to work as an ATA33 controller. Making buildworld requires more than 24hours with PIO Cheers, - -- Xin LI [EMAIL PROTECTED] http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHl576i+vbBBjt66ARAn0HAJ0Wg3h6ruok7YwRQX5RF4YC4YR33wCfeTPn 1FyI8MuJWGat/7FcCrPe+7k= =2ywz -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: 7-STABLE broke drscheme in week between 4 and 11 Jan
Hi John, On 24/01/2008, at 01:04, John Baldwin wrote: Anyway, the last part of the ktrace of the broken version (the earlier parts are just loading up shared libraries) looks like: (I sedded the ^pid out, so that I could get a better look at it with diff (meld, actually: it's nice)). There were changes to make binaries get SIGSEGV instead of SIGBUS (or vice versa) for certain VM-related traps. That might be related in which case the source code for the app will need to catch a different signal. You can test this by fiddling with the machdep.prot_fault_translation sysctl. That wasn't the problem: version 372 already had a patch to use SIGSEGV. the faulting instruction is: 0x000800bdecc6 GC_init_type_tags+598: mov %r13,(%rdx,%rax,8) r13 is 0x80390 rdx is -1 rax is 0xe40 Any thoughts on why that would be faulting? (Looks like a write to a very low address (code?) to me, but I'm not up on the VM map yet.) rdx should be a pointer to an array or some such, but it is a bogus pointer and that is why you are faulting. Yes, that was indeed the problem. The garbage collector was expecting memory returned by malloc to be zero, which, of course, it wasn't. It seems as though it was simply luck that the particular access was reliably zero before this particular change to FreeBSD. I should get more used to using the debugging support in our malloc, to grunge up malloc'd memory. The only thing that looks appropriate that changed in that week was sys/vm/vm_map.c, which had some new code added to help with shm mappings. I looked at it, but it didn't look as though it would affect this. Those changes were only in HEAD, so if you are seeing them in your kernel you are running HEAD and not RELENG_7. Yes. I did the binary-search thing, and found that the actual change that broke things was an MFC of src/contrib/gcc/gthr-posix.h, on 5 Jan. There's no obvious (to me) reason why that change would have affected the malloc system, but there must have been some epsilon of memory alignment that pushed a non-zero value into the particular memory that was being returned and tested in that instance. An entertaining debugging experience... Patches to drscheme have been accepted up-stream, so all should be dandy very soon. Cheers, Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.3-RELEASE can not mount root on Cyrix 5530 ATA33 controller
On 23Jan, 2008, at 21:09 , Xin LI wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yoshihiko Sarumaru wrote: Hello, I updated my Geode GX1 PC from RELENG_6_2 to RELENG_6_3 and found root mount failed after reboot. This problem was caused by a change to ata-pci.c to pick up wider old ata controller as ata-pci devices at ata_legacy() function, and roll backing that file resolved this problem for me. Which revision? Actually, its the fix to pci/pci.c that hasn't been backported to 6.x yet... -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Strange top output
Hello all i have a running 6.2 server with 2 jails 1 proxy and one for mailscanning with mailscanner and mailwatch if i log in on the mailscanner and do top i see normal numbers. now i have installed 7.0rc1 amd64 version on a quad core xeon and updated yesterday my src and did a buildworld cycle On this machine i am running the same jails 1 for proxy and one for the mailscanning. but if i do i top here i see much higher values of size used last pid: 3132; load averages: 0.15, 0.12, 0.07up 0+00:31:22 21:39:58 48 processes: 1 running, 47 sleeping CPU states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle Mem: 521M Active, 39M Inact, 148M Wired, 460K Cache, 113M Buf, 3227M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 3117 postfix 1 80 141M 101M nanslp 2 0:03 0.00% perl 3114 postfix 1 80 141M 101M nanslp 3 0:03 0.00% perl 3111 postfix 1 80 141M 101M nanslp 3 0:02 0.00% perl 3108 postfix 1 80 141M 101M nanslp 3 0:02 0.00% perl 3104 postfix 1 80 141M 101M nanslp 0 0:02 0.00% perl 2601 postfix 1 40 61144K 49544K accept 1 0:02 0.00% clamd 2772 www 1 40 133M 19296K accept 2 0:00 0.00% httpd 2736 root1 440 132M 16828K select 1 0:00 0.00% httpd 2727 www 1 80 24324K 7536K nanslp 0 0:00 0.00% perl 2773 www 1 40 133M 19284K accept 1 0:00 0.00% httpd 2774 www 1 40 133M 19276K accept 2 0:00 0.00% httpd 2776 www 1 40 133M 19276K accept 2 0:00 0.00% httpd 3010 www 1 40 133M 19276K accept 2 0:00 0.00% httpd 2906 mysql 15 40 72496K 25464K sbwait 2 0:00 0.00% mysqld 2800 beheer 1 440 32800K 4484K select 0 0:00 0.00% sshd 2606 postfix 1 200 13936K 2572K pause 3 0:00 0.00% freshclam like the http deamon 133M and the postfix (mailscanner) of 141M on the 6.2 it is around 11862 postfix 1 80 92140K 82340K nanslp 0:11 0.00% perl 11944 postfix 1 80 92120K 82112K nanslp 0:09 0.00% perl 16879 postfix 1 80 91736K 83812K nanslp 0:09 0.00% perl 11994 postfix 1 80 91808K 83788K nanslp 0:09 0.00% perl 92322 postfix 1 80 91752K 83864K nanslp 0:09 0.00% perl 859 www 1 40 21704K 12920K accept 0:00 0.00% httpd 857 www 1 40 21132K 12348K accept 0:00 0.00% httpd 861 www 1 40 21704K 12856K accept 0:00 0.00% httpd did i do something wrong or is it something else! this is my first amd64 install, the 6.2 is a i386 install regards, Johan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: bad pte
On Wednesday 23 January 2008 11:56:02 am Mikhail Teterin wrote: середа 23 січень 2008 09:20 до, John Baldwin Ви написали: Is this something, that should be fixed in the 6.3? The kernel is 6.2-STABLE from June (see uptime). What kind of CPU? Dual Opteron. FreeBSD/amd64. There was a fix for a certain edge condition in 6.x post 6.2, but usually when I see this panic it is due to a hardware failure. In the controller? It is a newish ahd (although from eBay) -- what could be wrong? RAM. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: bad pte
середа 23 січень 2008 03:45 по, John Baldwin Ви написали: In the controller? It is a newish ahd (although from eBay) -- what could be wrong? RAM. Ouch... You mean, the main computer RAM or the controller's own memory? The box itself is from a reputable workstation-maker and is otherwise functioning perfectly. Yet it had two pte-panics within 24-hours from each other (I reported the first one). 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: Strange top output
Johan Hendriks wrote: now i have installed 7.0rc1 amd64 version on a quad core xeon and updated yesterday my src and did a buildworld cycle On this machine i am running the same jails 1 for proxy and one for the mailscanning. but if i do i top here i see much higher values of size used this is my first amd64 install, the 6.2 is a i386 install There are two reasons for the behaviour you noticed: a) 64-bit software takes more memory than 32-bit, by definition (pointers are twice the size, etc.) b) The memory allocator (malloc) was completely changed in 7.0, and it requests more memory from the kernel than the one used before (don't worry: the amount of memory actually _used_ has nothing to do with how much virtual memory is allocated). In your case, these two factors have increased memory usage from 82 MB to 110 MB, and allocation from 92 MB to 141 MB. There's nothing bad here, if you have enough memory. signature.asc Description: OpenPGP digital signature
Re: FreeBSD 6.3-Release + squid 2.6.17 = Hang process.
2008/1/24, Xin LI [EMAIL PROTECTED]: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vanilla Hsu wrote: Hi: We have a machine running 6.2-R-p10 and squid 2.6.17, and upgrade it to 6.3R yesterday, but squid will hang and eat 100% cpu time after restart about 1 hour later, machine still alive, and no response from squid. downgrade to 6.2-R-p10, everything ok again.. Just wanted to narrow down the problem, is it possible for you to try if it's within the kernel (say, use 6.2 userland and squid binary under 6.3 kernel)? no, already reboot with new kernel, but use old squid binary. Cheers, - -- Xin LI [EMAIL PROTECTED]http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHl5a9i+vbBBjt66ARArAZAKCiM35r8fGFCXFa2mbbUDHOCUpvywCgst+X pBdyNQ5ir4LhtYdyUPc80uk= =7kgd -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]
New KTR trace for mouse freezing/stuttering in 7.0-RC1
In an attempt to track down this mouse freezing/stuttering (i.e. jerky mouse movement) behavior in FreeBSD 7.0-RC1, I have come up with a reliable way to cause it to happen, and I have created a longer trace showing the results. Note that I am using the ULE scheduler. In general, it becomes easier to see the effect if there is CPU activity. I have noticed it during kernel compiles, while at the same time loading web pages in firefox that contain images (and moving the mouse while this is happening). But a more controlled way to see it is to run something that uses some CPU and then generating lots of X events. In my case, I start xtrs (TRS-80 emulator) in Model IV mode, which happens to poll for input, using the CPU. Then I move the mouse back and forth quickly between windows in focus under mouse mode (in my case, a KDE focus mode), which causes many focus events quickly. In about 15 or 20 seconds, the mouse reliably starts to show erratic movement, not moving smoothly. I really hope this can shed more light on what might be going on. Here is the trace: http://www.skyrush.com/downloads/ktr_ule_4.out Thanks, Joe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7-STABLE regression that breaks lang/drscheme is src/contrib/gcc/gthr-posix.h 1.1.1.8.2.1
Andrew Reilly wrote: Hello again, [to recap: drscheme, (which is an IDE that runs under the mred runtime, built from ports/lang/drscheme (or actually manually from a personal copy of that Makefile that builds the current release: 372, rather than ver 370 in ports)) worked beautifully on my system until I updated to 7-STABLE after 4 Jan. I track -STABLE every week or two. After that, it segfaults before printing or displaying anything, and running under gdb has found that it stops in the garbage collector initialization. I haven't raised a PR for this yet because I still think that the problem is probably the drscheme FreeBSD configuration that has bit-rotted a little, now that FreeBSD has changed slightly. Still investigating... I've cc'd Joseph Koshy, because this seems to be somehow related to PR ports/118808.] [...] I had similar problems whith lang/drscheme. It refused to build ever since I switched to RELENG_7. Building it from source (version 370 and 371) wasn't succesfull at all: first it refused to find some X includes (which are present), then it wouldn't finish compiling because of a coredump in mred/mzscheme (I don't recall which one it was). My first thought was a broken compiler, but using gcc34 and icc 8.1 wasn't succesfull either ;-) After that, I decided not to spend any more time because I didn't know what steps were appropriate to take... I just did compile Drscheme 372 with a patched Makefile of the port: - uncomment this line: BROKEN= Fails to install (signal 11) - adapt distinfo: MD5 (drscheme/372/plt-372-src-unix.tgz) = 751217f63bc64423a29a05423f917af8 SHA256 (drscheme/372/plt-372-src-unix.tgz) = 6b635b41fcb27acbd1eaa773c88eb2c1131e9857b104c8ec1b111cff2d7fb2ec SIZE (drscheme/372/plt-372-src-unix.tgz) = 15267684 - make; make install This may be not the most correct way, but it works for me. I'm running FreeBSD 7.0-PRERELEASE as of Jan 17 2008. Regards, Philipp ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Asteisk-1.4.17 codec negotiation patch
Hello, Yesterday, I tried to use Asterisk-addons OOH323 channel driver with codec negotiation patch from www.b2bua.org. But I can't compile OOH323 channel driver patch applied Asterisk source. Is there any has success with this patch? I found that Maxim update Asterisk, codec negotiation patch into ports. Regards, Balgaa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
