syslog-ng / acpi logging issue on laptop
Hello all, I am running FreeBSD on a Dell laptop (vostro 1000) and don't really have too many problems with it i have most things working now. I used linux for a while and so "Cut my teeth" on that but i have found freebsd to be much better suited to my needs. I have one small issue that is eating away at me that i hope someone might be able to help with, I am using syslog-ng and my battery doesn't appear to be supported by the ACPI in the bios so i get this a lot in the logfile : Dec 30 18:47:37 vostro ACPI-1304: *** Error: Method execution failed [\_SB_.BAT1._BST] (Node 0xc4bd27a0), AE_NOT_FOUND Is there any way to stop it logging every few seconds ? I have got "hald" working and can see the detail on the battery in the gnome applet but it still lists this in the log. Cheers, Darran http://www.deejc.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_7 jerky mouse and skipping sound (still a problem -BETA3)
On Sun, Dec 30, 2007 at 03:30:40PM -0800, David E. Thiel wrote: > On Sun, Dec 30, 2007 at 11:12:26PM +0100, Kris Kennaway wrote: > >> FWIW, the problem remains for me. Still terrible performance > >> during compiles. > > > > OK. Instead of going over all of the usual questions again, can you point > > me to a previous mail in which you explain your observations and test > > results in detail? > > The most recent is http://marc.info/?l=freebsd-stable&m=119428719505129&w=2, > but > it started way back at > http://marc.info/?l=freebsd-current&m=118998090512027&w=2. > > I've tried a lot of stuff in between, and all I've been able to narrow > it down to is that it's not a display driver issue, and that none of > my swap partition is getting used, so that's not the problem. During > compiles, my UP system with ULE still gets very unresponsive when > compiling, sometimes taking up to 10 seconds just to draw a new terminal > window. Even changing focus with the window manager can take several > seconds. I'd like to provide more info, but I'm not sure what stats > are useful for this particular issue. Please let me know. > > dmesg is at http://redundancy.redundancy.org/dmesg.txt, and kernel > config is at http://redundancy.redundancy.org/DEEPTHOUGHT. Even though > I'm still getting reported 80-95% memory utilization and no paging, > I'm going to get an extra gig of RAM on order to see if that improves > things. 2G of ram for a desktop, what's the world coming to? ;) BTW, mine similar problem completely disappeared after I switched to SMP kernel and turned on hyperthreading on my workstation Pentium IV 3GHz. I am able to run FPS games while doing 1 (and, most of the time, even 2) compilations/configure run) in parallel. The scheduler used is ULE, RELENG_7. I believe there is something wrong with UP; I did not investigated what. pgpAe6EjizGNK.pgp Description: PGP signature
Re: 7.0BETA4 ../cc_tools/insn-attrtab.c compiles forever
Sorry for delay (travelling), Answers to 1 private mail & 2 list posted replies further below, first my original posting for reference: >> Anyone else noticed on 7.0BETA4 (& hence Ive cc'd re@) >> >> This runs forever: >> >> ===> cc_int (all) >> Warning: Object directory not changed from original >> /usr/src/gnu/usr.bin/cc/cc_int >> cc -O2 -fno-strict-aliasing -march=i586 -DIN_GCC -DHAVE_CONFIG_H >> -DPREFIX=\"/usr\" -I/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools >> -I/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools >> -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc >> -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config >> -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/include >> -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libcpp/include >> -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libdecnumber >> -c ../cc_tools/insn-attrtab.c >> >> With or without -pipe & with or without /usr/obj >> All the rest of /usr/src compiles OK though. >> >> FreeBSD lapn.js.berklix.net 7.0-BETA4 FreeBSD 7.0-BETA4 #0: Sun Dec 16 >> 09:18:21 CET 2007 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/GENERIC >> i386 -- From: Michael Voorhis Wed, 19 Dec 2007 21:11:25 -0500 (Thu 03:11 CET): > What sort of machine do you have? I seem to recall that compile-line > taking an age, but not forever. It takes a while to finish on my > Thinkpad t42, which is a > >Pentium(R) M processor 1.70GHz (1694.51-MHz 686-class CPU) This an old laptop with small slow disc: http://www.berklix.com/~jhs/hardware/laptops/dell_latitude_xpi_p133st/ CPU: Pentium/P54C (133.64-MHz 586-class CPU) avail memory = 43507712 (41 MB) /boot/loader.conf: hw.ata.ata_dma=0 hw.ata.wc=0 swapinfo Device 1K-blocks UsedAvail Capacity /dev/ad0s1b102400101569224410% /dev/md0 10101448985610% -- From: Ivan Voras <[EMAIL PROTECTED]> Thu, 20 Dec 2007 11:47:57 +0100 > I did see some weird behaviour while compiling gcc, though I don't > remember if it's the same file (looks like it). They usually disappeared > after removing CPUTYPE and -O2 from compiler flags. My /etc/make.conf just has CFLAGS += -march=i586 I assume -O2 is coming out of /usr/src/ gcc itself. -- From: Nikos Ntarmos <[EMAIL PROTECTED]> Thu, 20 Dec 2007 13:33:31 +0200 > I'd bet you're seeing some serious thrashing there. I've come across at > least one other user having problems with that particular part of > buildworld and -O2/-Os optimization levels. Seems like gcc4 is quite the > memory hog so I don't know whether something can be done, other than > either adding more RAM, trying to tweak swappiness, or taking a break > while this thing compiles itself. Yes, on return from travels, I powered up, left it running for day[s?] looked again & finally it had finished. Now trying from BETA4 to 7-Stable. Seems your right about gcc4 & memory hog. (-pipe by default makes it even worse, subject of another thread). Thanks all. -- Julian Stacey. Munich Computer Consultant, BSD Unix C Linux. http://berklix.com Ihr Rauch = mein allergischer Kopfschmerz. Dump cigs 4 snuff. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
6.3-RC2 Available
Sorry for the delay with this phase of the 6.3 release. A few glitches were found during testing of the 6.3-RC2 ISOs that included pre-built packages. The 6.3-RC2 builds for amd64 and i386 should now be available on the majority of the FreeBSD mirror sites. I just finished loading the sparc64 build so that will take a little while to propagate to the mirrors. This is the last planned RC for 6.3. Unless a major show-stopper problem is found the release of 6.3 should happen in about two weeks. If updating an older system using cvs or c[v]sup based mechanisms the branch tag to use is RELENG_6_3. Or you can give FreeBSD Update a try, see the instructions here: http://www.daemonology.net/blog/2007-11-10-freebsd-minor-version-upgrade.html If you would like to test doing a fresh install ISOs for each are available at: ftp://ftp.freebsd.org/pub/FreeBSD/releases//ISO-IMAGES/6.3/ (or any of the mirror sites). Checksums for the ISOs: MD5 (6.3-RC2-alpha-bootonly.iso) = eb49c89dc1c71e145ff6f7bc01ce2960 MD5 (6.3-RC2-alpha-disc1.iso) = 7df322d9d637fa03bb01db833f022865 MD5 (6.3-RC2-alpha-disc2.iso) = b526b87c65286d84203a17d6d69ea224 MD5 (6.3-RC2-alpha-disc3.iso) = 93b983a29242cb88cb3015633096d617 MD5 (6.3-RC2-alpha-docs.iso) = 621cf01af7bde8d78f52f3789b6ccb6a MD5 (6.3-RC2-amd64-bootonly.iso) = 545504c2e89d174a10276434ff859269 MD5 (6.3-RC2-amd64-disc1.iso) = c690232615c8dfe08baa282b4a448c52 MD5 (6.3-RC2-amd64-disc2.iso) = 26c5ed6cc48b3c5b62ecf9fb9ca4e18c MD5 (6.3-RC2-amd64-disc3.iso) = 4183c520faf4f5564c0b6302c58428a1 MD5 (6.3-RC2-amd64-docs.iso) = 47d98d745469ce653f812a85e2441a23 MD5 (6.3-RC2-i386-bootonly.iso) = 6aa63ac36eee9c682207ce244d50afbe MD5 (6.3-RC2-i386-disc1.iso) = f55972f157d34f14f311748e39d5799a MD5 (6.3-RC2-i386-disc2.iso) = d05ab5f2ead0ddec0abce0bd2d3b612d MD5 (6.3-RC2-i386-disc3.iso) = 55e5453007b3a27c8b35966c1c119431 MD5 (6.3-RC2-i386-docs.iso) = d204a11d1c5845a52e148297aaa2fe0f MD5 (6.3-RC2-pc98-bootonly.iso) = e47e50db91fca45c2fcea77451d0e66f MD5 (6.3-RC2-pc98-disc1.iso) = f360f2e688f6711b8502176e386517d4 MD5 (6.3-RC2-sparc64-bootonly.iso) = 66e42fa45605f2b3ec3149622f73c943 MD5 (6.3-RC2-sparc64-disc1.iso) = 6b89be64e05cc91e165a939f976f933d MD5 (6.3-RC2-sparc64-disc2.iso) = ba32a6b30c5114c2846b7466a4b557a7 MD5 (6.3-RC2-sparc64-disc3.iso) = 10f17647aa9a4c14f71cd6d7cd367c95 MD5 (6.3-RC2-sparc64-docs.iso) = a82a1eb4e4b5f78c8e780af652bfed38 SHA256 (6.3-RC2-alpha-bootonly.iso) = 493d0351cbd2a7433a28530f731db6993c73c6bb46e07c96e6466b3a4c7c0373 SHA256 (6.3-RC2-alpha-disc1.iso) = b5d344f732885e9917b9ad962674171e05b64170ca6f2006a4dae68b7718dc51 SHA256 (6.3-RC2-alpha-disc2.iso) = 383201fd964d6941a4ff32d7801acf54caf804dfef9d877314c38e61dc628230 SHA256 (6.3-RC2-alpha-disc3.iso) = 0af3ea3986fd91605aa112c92624829b0bed3c29724c9ae6e5894e6c894452be SHA256 (6.3-RC2-alpha-docs.iso) = 77c54c2fd00a74bdd295d43a473bc4a03be2e686be66a17bfc02d351017d0b04 SHA256 (6.3-RC2-amd64-bootonly.iso) = 6e9f69d2633b1649bb77109dc7e2c0f693eceda4e8243d852218ce1b7a448acc SHA256 (6.3-RC2-amd64-disc1.iso) = 2c1443e921925a64b3b300634310cf3761e8e9b0b99f6e5dd54ff90cc8443bd0 SHA256 (6.3-RC2-amd64-disc2.iso) = 3f60b2c6fcca50b16be5232d2979effd79d22a82de60b0718646f68279bd6da2 SHA256 (6.3-RC2-amd64-disc3.iso) = 1c523461914c24c848945cec25b3e4934e9d707fdee9f0894e6e32535f9f032b SHA256 (6.3-RC2-amd64-docs.iso) = c2807ede83f81a6787b56ad7581c996774e2524824ed8ad699b4939c681e5822 SHA256 (6.3-RC2-i386-bootonly.iso) = 5e56fcc0066e56b66e3126346cf8e9887afa1db95379eebabb14963950318c14 SHA256 (6.3-RC2-i386-disc1.iso) = 968dbaee4d3c732e7e59cd9cdcd47e896370ff2948543026e1c8e84ebcb13ad4 SHA256 (6.3-RC2-i386-disc2.iso) = 61060fdb84ae0ec823c4b62b38720d91dc40c5550a1e521d375ebc1cf38a1484 SHA256 (6.3-RC2-i386-disc3.iso) = 1952e7e6d8f1b0a820aa75ea219ad67544eb7b73536ca0d3a429de9930f43457 SHA256 (6.3-RC2-i386-docs.iso) = 6c71ef56f044aa78399eb7c12740e403a2f5c0d7da4dd787c200afc752a2b45c SHA256 (6.3-RC2-pc98-bootonly.iso) = dadcbd9782ad5689d66d27330e3c6c4d1205b04bececbf1b274a9ff3b4006b1c SHA256 (6.3-RC2-pc98-disc1.iso) = 8020fd63b27664fd4cb8f44256038ae42d10a77ad15151d2d6e46d3cef9c286e SHA256 (6.3-RC2-sparc64-bootonly.iso) = a603945a435b386258799a3211fc178b924046d6fae09f607fbe58c483f5d362 SHA256 (6.3-RC2-sparc64-disc1.iso) = e20209f25bc9687b87697d339c3604146947c2999e3db8122d4fdd6d626f0555 SHA256 (6.3-RC2-sparc64-disc2.iso) = b675fedcd2b53c93ab073a3b517997290c8c7e942d2fdf5b87a1a0335918e449 SHA256 (6.3-RC2-sparc64-disc3.iso) = 391eb2220f57ba3b366fba097abd6b202fefb5d624e18dc4ced4060ef4ce4e12 SHA256 (6.3-RC2-sparc64-docs.iso) = 2178cec99a3c139a3b9b02c708db9711fb8612cf05389781e7386c5169a38f04 -- Ken Smith - From there to here, from here to | [EMAIL PROTECTED] there, funny things are everywhere. | - Theodore Geisel | signature.asc Description: This is a digitally signed message part
Re: syslog-ng / acpi logging issue on laptop ** FIXED
I fixed this by entering some filters to filter it out. Darran On Mon, 2007-12-31 at 09:19 +, Darran wrote: > Hello all, > > I am running FreeBSD on a Dell laptop (vostro 1000) and don't really have too > many problems with it i have most things working now. > I used linux for a while and so "Cut my teeth" on that but i have found > freebsd > to be much better suited to my needs. > > I have one small issue that is eating away at me that i hope someone might be > able to help with, I am using syslog-ng and my battery doesn't appear to be > supported by the ACPI in the bios so i get this a lot in the logfile : > > Dec 30 18:47:37 vostro ACPI-1304: *** Error: Method execution failed > [\_SB_.BAT1._BST] (Node 0xc4bd27a0), AE_NOT_FOUND > > Is there any way to stop it logging every few seconds ? > > I have got "hald" working and can see the detail on the battery in the gnome > applet but it still lists this in the log. > > Cheers, > > Darran > http://www.deejc.net > > > ___ > 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: 6.3-RC2 Available
On Dec 31, 2007 4:59 AM, Ken Smith <[EMAIL PROTECTED]> wrote: > > Sorry for the delay with this phase of the 6.3 release. A few glitches > were found during testing of the 6.3-RC2 ISOs that included pre-built > packages. > > The 6.3-RC2 builds for amd64 and i386 should now be available on the > majority of the FreeBSD mirror sites. I just finished loading the > sparc64 build so that will take a little while to propagate to the > mirrors. This is the last planned RC for 6.3. Unless a major > show-stopper problem is found the release of 6.3 should happen in about > two weeks. Is there a changes document that captures the delta between minor releases, and in this case between 6.2 and 6.3-RC2? I'm mostly interested in changes that happened under src/sys. Cheers, Karl. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Fatal trap 19 on Sony Vaio
I'm getting the following trap when i try to install from the i386 7.0RC1 disk1 and livefs install cds. I've also tried booting with acpi disabled. The error says it's a RAM issue but since i've been able to boot other operating systems on it without a problem. The laptop is a Sony VGN-FZ240E. The problems seems to be fixable by building a kernel without firewire but is there a way to get the stock kernel to work? This is what's on the screen after the panic: fwohci0: [MPSAFE] fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 08:00:46:03:02:90:3b:12 u NMI ISA b0, EISA ff RAM parity error, likely hardware failure. Fatal trap 19: non-maskable interrupt trap while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0xc059c336 stack pointer = 0x28:0xc14207a4 frame pointer= 0x28:0xc14207d0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, IOPL = 0 current process= 0 (swapper) trap number= 19 panic: non-maskable interrupt trap cpuid = 0 I tried some iso's i had lying around and I was able to get into sysinstall on 4.3/4.8,5.0, 6.1 and i'm currently running Vista without a problem. A PC BSD 1.4.1 (6.3 PRERELEASE) also panicked. When booting nothing is attached to the firewire port. http://marc.theaimsgroup.com/?t=10996717681&r=1&w=2 http://marc.info/?t=10996717681&r=1&w=2 http://www.google.com/search?hl=en&q=Fatal+trap+19%3A+non-maskable+interrupt+trap+while+in+kernel+mode thanks ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[PATCH] 7-STABLE Build broken in geom_io.c with KTR but no DDB
Hi,
I've been trying to do some debugging with ktrace(9) for the first time,
and ran in to a problem after trying to compile the kernel.
I didn't have DDB defined, and as a result the build failed
after adding "option KTR":
geom_io.o(.text+0x5ee): In function `g_alloc_bio':
../../../geom/geom_io.c:140: undefined reference to `stack_save'
geom_io.o(.text+0x61e):../../../geom/geom_io.c:141: undefined reference to
`stack_ktr'
geom_io.o(.text+0x6e1): In function `g_clone_bio':
The use of CTRx in the geom code appears to be correctly wrapped with
#ifdef KTR, but this is also all that protects the uses of CTRSTACK.
CTRSTACK is also defined to use stack_ktr conditionally on #ifdef KTR in
sys/stack.h, but the stack_ktr function is compiled in to the kernel only
if DDB is enabled.
Perhaps CTRSTACK should be non-empty only if both DDB and KTR are defined?
--
David Taylor
Index: sys/stack.h
===
RCS file: /home/ncvs/src/sys/sys/stack.h,v
retrieving revision 1.2
diff -u -r1.2 stack.h
--- sys/stack.h 29 Aug 2005 11:34:08 - 1.2
+++ sys/stack.h 31 Dec 2007 19:14:10 -
@@ -46,7 +46,7 @@
void stack_zero(struct stack *);
void stack_print(struct stack *);
void stack_sbuf_print(struct sbuf *, struct stack *);
-#ifdef KTR
+#if defined(DDB) && defined(KTR)
void stack_ktr(u_int, const char *, int, struct stack *, u_int, int);
#define CTRSTACK(m, st, depth, cheap) do {\
if (KTR_COMPILE & (m)) \
___
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-RC2 Available
If memory serves me right, Karl Triebes wrote:
> On Dec 31, 2007 4:59 AM, Ken Smith <[EMAIL PROTECTED]> wrote:
>> Sorry for the delay with this phase of the 6.3 release. A few glitches
>> were found during testing of the 6.3-RC2 ISOs that included pre-built
>> packages.
>>
>> The 6.3-RC2 builds for amd64 and i386 should now be available on the
>> majority of the FreeBSD mirror sites. I just finished loading the
>> sparc64 build so that will take a little while to propagate to the
>> mirrors. This is the last planned RC for 6.3. Unless a major
>> show-stopper problem is found the release of 6.3 should happen in about
>> two weeks.
>
> Is there a changes document that captures the delta between minor
> releases, and in this case between 6.2 and 6.3-RC2? I'm mostly
> interested in changes that happened under src/sys.
You mean like the release notes?
RELNOTES.{HTM,TXT} in the top-level of disk 1 for any release, or see here:
http://people.freebsd.org/~bmah/relnotes/
(The release notes get installed on www.freebsd.org just before the
release gets announced.)
Bruce.
signature.asc
Description: OpenPGP digital signature
Re: PR backlog [was: Re: usb/umass, devfs: this sucks]
It's sent out weekly. So only people which are on bugbusters@ receive it. If someone is interested in this but is not interested in the other bugbusters@ mails, they will not see it. Actually apart from this thread that weekly email is the only traffic on bugbusters@ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] 7-STABLE Build broken in geom_io.c with KTR but no DDB
On Mon, 31 Dec 2007, David Taylor wrote: > Hi, > > I've been trying to do some debugging with ktrace(9) for the first time, > and ran in to a problem after trying to compile the kernel. > > I didn't have DDB defined, and as a result the build failed > after adding "option KTR": > > geom_io.o(.text+0x5ee): In function `g_alloc_bio': > ../../../geom/geom_io.c:140: undefined reference to `stack_save' > geom_io.o(.text+0x61e):../../../geom/geom_io.c:141: undefined reference to > `stack_ktr' > geom_io.o(.text+0x6e1): In function `g_clone_bio': > > The use of CTRx in the geom code appears to be correctly wrapped with > #ifdef KTR, but this is also all that protects the uses of CTRSTACK. > > CTRSTACK is also defined to use stack_ktr conditionally on #ifdef KTR in > sys/stack.h, but the stack_ktr function is compiled in to the kernel only > if DDB is enabled. > > Perhaps CTRSTACK should be non-empty only if both DDB and KTR are defined? OK, the attached patch is necessary, but not quite sufficient to fix the problem. geom_io.c also calls stack_save() under #ifdef KTR, when it needs to be under an #ifdef DDB as well... P.S. Happy New Year everyone! -- David Taylor ___ 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-RC2 Available
On Dec 31, 2007 4:21 PM, Bruce A. Mah <[EMAIL PROTECTED]> wrote:
> You mean like the release notes?
>
> RELNOTES.{HTM,TXT} in the top-level of disk 1 for any release, or see here:
>
> http://people.freebsd.org/~bmah/relnotes/
Yes, thanks.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
