Re: GCC segfaulting while trying to compile latest Qt4 code
Nikos Ntarmos writes: [...] Hi there. Could you be running out of memory during that compilation? I'd suggest adding some swap space[1] and trying again, or play around with lower gcc optimization levels (-O0, -O). I'm already using a 2 GiB swap device. I added -dH option in existing c++ command-line[1] to force it to dump a core file, and then I loaded it in gdb and following is the backtrace. #v+ (gdb) bt #0 0x0088893c in kill () at kill.S:2 #1 0x008879c4 in abort () at /usr/src/lib/libc/stdlib/abort.c:65 #2 0x00811fb3 in real_abort () at /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/diagnostic.c:652 #3 0x0081239b in diagnostic_action_after_output ( context=0x575, diagnostic=0x6) at /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/diagnostic.c:270 #4 0x008120f5 in diagnostic_report_diagnostic ( context=0xbb16e0, diagnostic=0x7fffcad0) at /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/diagnostic.c:409 #5 0x00812312 in internal_error (gmsgid=Variable gmsgid is not available. ) at /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/diagnostic.c:588 #6 0x0055c07d in crash_signal (signo=Variable signo is not available. ) at /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/toplev.c:607 #7 signal handler called #8 gimplify_va_arg_expr (expr_p=0x80521de00, pre_p=0x7fffd2d0, post_p=0x7fffd2c8) at /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/builtins.c:4377 #9 0x007e9881 in gimplify_expr (expr_p=0x80521de00, pre_p=0x7fffd2d0, post_p=0x7fffd2c8, gimple_test_f=0x7f1cb3 is_gimple_reg_rhs, fallback=fb_rvalue) at /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/gimplify.c:5545 #10 0x007e8b83 in gimplify_modify_expr ( expr_p=0x7fffd400, pre_p=0x7fffd2d0, post_p=0x7fffd2c8, want_value=0 '\0') at /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/gimplify.c:3565 #11 0x007e9c25 in gimplify_expr (expr_p=0x7fffd400, pre_p=0x7fffd2d0, post_p=0x7fffd2c8, gimple_test_f=0x7f1bf5 is_gimple_stmt, fallback=fb_none) at /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/gimplify.c:5518 #12 0x007eb1b4 in gimplify_to_stmt_list ( stmt_p=0x7fffd400) at /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/gimplify.c:4309 #13 0x007e958f in gimplify_expr (expr_p=0x805216e90, pre_p=0x7fffd410, post_p=0x7fffd408, gimple_test_f=0x7f1bf5 is_gimple_stmt, fallback=fb_none) at /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/gimplify.c:4124 #14 0x007e9919 in gimplify_expr (expr_p=0x7fffd588, pre_p=0x7fffd530, post_p=0x7fffd528, gimple_test_f=0x7f1bf5 is_gimple_stmt, fallback=fb_none) at /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/gimplify.c:3746 #15 0x00488dac in gimplify_cp_loop (cond=Variable cond is not available. ) at /usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/cp-gimplify.c:246 #16 0x00489151 in cp_gimplify_expr (expr_p=0x805216e70, pre_p=0x7fffd720, post_p=0x7fffd718) at /usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/cp-gimplify.c:283 #17 0x007e8fbe in gimplify_expr (expr_p=0x805216e70, pre_p=0x7fffd720, post_p=0x7fffd718, gimple_test_f=0x7f1bf5 is_gimple_stmt, fallback=fb_none) at /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/gimplify.c:5449 #18 0x007e9919 in gimplify_expr (expr_p=0x80521dfe0, pre_p=0x7fffd840, post_p=0x7fffd838, gimple_test_f=0x7f1bf5 is_gimple_stmt, fallback=fb_none) at /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/gimplify.c:3746 #19 0x007eb1b4 in gimplify_to_stmt_list (stmt_p=0x80521dfe0) at /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/gimplify.c:4309 #20 0x007ea13d in gimplify_expr (expr_p=0x803ee97b0, pre_p=0x7fffd980, post_p=0x7fffd978, gimple_test_f=0x7f1bf5 is_gimple_stmt, fallback=fb_none) at /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/gimplify.c:1091 #21 0x007eabc8 in gimplify_body (body_p=0x803ee97b0, fndecl=0x803ee9700, do_parms=1 '\001') at /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/gimplify.c:6317 #22 0x007eadaf in gimplify_function_tree (fndecl=0x803ee9700) at /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/gimplify.c:6393 #23 0x0048e208 in c_genericize (fndecl=0x803ee9700) at /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/c-gimplify.c:106 #24 0x00488c18 in cp_genericize (fndecl=0x803ee9700) at /usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/cp-gimplify.c:755 #25 0x004287bb in finish_function (flags=0) at /usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/decl.c:11336 #26 0x0045824f in
Re: Fatal trap 12: page fault while in kernel mode on 7.1/amd64, but not 7.0
On Thu, Mar 05, 2009 at 07:55:30PM -0500, Boris Kochergin wrote: Ahoy. I recently upgraded an amd64 machine to 7.1-RELEASE, and started getting a bunch of these at a pretty high frequency (a few hours to a day apart): http://acm.poly.edu/~spawk/IMG00033.jpg The current process is always httpd. They're particularly annoying because the machine doesn't actually ever reboot, requiring manual intervention. Reverting the kernel back to 7.0 makes the panic go away, and the machine had been happily running 7.0 for about a year beforehand. I realize that the photo hardly contains any useful debugging information, but I was hoping it might look familiar to someone. If not, I guess I'll come back with a backtrace. You need to provide the backtrace from kgdb. pgpifKOEedU0J.pgp Description: PGP signature
Re: Fatal trap 12: page fault while in kernel mode on 7.1/amd64, but not 7.0
On Thu, 2009-03-05 at 19:55 -0500, Boris Kochergin wrote: Ahoy. I recently upgraded an amd64 machine to 7.1-RELEASE, and started getting a bunch of these at a pretty high frequency (a few hours to a day apart): http://acm.poly.edu/~spawk/IMG00033.jpg The current process is always httpd. They're particularly annoying because the machine doesn't actually ever reboot, requiring manual intervention. Reverting the kernel back to 7.0 makes the panic go away, and the machine had been happily running 7.0 for about a year beforehand. I realize that the photo hardly contains any useful debugging information, but I was hoping it might look familiar to someone. If not, I guess I'll come back with a backtrace. A backtrace will almost certainly be necessary to figure out what this issue is, although there is a possibility that the output of addr2line -e /boot/kernel/kernel.symbols 0x8:0x802d7010 might help, assuming you've not recompiled your kernel yet. (That number should be the same as the instruction pointer shown by the panic, but as the photo is quite blurred there's a chance I've got it wrong, if you have a better picture of it or wrote it down then use that) Gavin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: GCC segfaulting while trying to compile latest Qt4 code
John Baldwin wrote: I believe superpages were mfc'd to -stable as well. I have one machine that faults in gcc with this turned on. You can try adding vm.pmap.pg_ps_enabled=0 to /boot/loader.conf, rebooting and see if that fixes the problem. If so, you might provide the list with your hardware configuration. Note that superpages is not on by default in 7 the way it is in 8. BTW, can you get more details from your actual crash dump? I'm not sure if there's a way you can either add some debug printfs or something else to determine what the faulting address that results in the SIGBUS you are seeing? Ahh, my bad, I didn't realize it defaulted to off. I'm not having any luck at diagnosing it further, the stack is so far gone at that point. Since no-one else is really seeing my issue at this point, I'm going to wait until I have some different, slower memory to try.For now, disabling superpages works well. If Ashish is still having issues, I've seen this sort of thing with runtime library problems. Bad libmap entries and disk corruption can cause this. If you can complete a buildworld, a fresh buildworld and installworld with make delete-old might solve your compilation problems.If qt depends on the gcc in ports, you may have to rebuild that one as well afterwards. -- Mark Atkinson atkin...@yahoo.com (!wired)?(coffee++):(wired); ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: GCC segfaulting while trying to compile latest Qt4 code
Mark Atkinson writes: [...] If Ashish is still having issues, I've seen this sort of thing with runtime library problems. Bad libmap entries and disk corruption can cause this. If you can complete a buildworld, a fresh buildworld and installworld with make delete-old might solve your compilation problems.If qt depends on the gcc in ports, you may have to rebuild that one as well afterwards. Okay, I'll try updating my box again. -- Ashish SHUKLA pgpJCzlH3lbNg.pgp Description: PGP signature
Sata disc management
Hi all! How to can I stop the idle sata disc under fbsd (for power save) ? I searched many hours on google, but I don't find any information for it, only for scsi subsystem. I think a program like camcontrol, but for sata disk. Thanks, Oliver ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Problems about usbhidaction
Hi, Today I got a new USB keyboard, ukbd0: Microsoft Natural\M-. Ergonomic Keyboard 4000, class 0/0, rev 2.00/1.73, addr 2 on uhub3 kbd2 at ukbd0 uhid0: Microsoft Natural\M-. Ergonomic Keyboard 4000, class 0/0, rev 2.00/1.73, addr 2 on uhub3 Normal keys are sent through ukbd0, and special keys (volume up, etc) are sent through uhid0. I tried to use usbhidaction to make the special keys functional, and I found that there are some problems about usbhidaction: 1. The length of data it tried to read is wrong. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Problems about usbhidaction
Hi, Today I got a new USB keyboard, ukbd0: Microsoft Natural\M-. Ergonomic Keyboard 4000, class 0/0, rev 2.00/1.73, addr 2 on uhub3 kbd2 at ukbd0 uhid0: Microsoft Natural\M-. Ergonomic Keyboard 4000, class 0/0, rev 2.00/1.73, addr 2 on uhub3 Normal keys are sent through ukbd0, and special keys (volume up, etc) are sent through uhid0. I tried to use usbhidaction to make the special keys functional, and I found that there are some problems about usbhidaction: 1. The length of data it tried to read is wrong. According to the UHID Device Class Definition, if Report ID tags are used in the Report descriptor, there would be a 1-byte report ID prefix before the report data. But if no Report ID tags are used, then the report ID prefix is omitted. But usbhidaction does not admit this (I modified libusbhid to allow client program to know if Report ID tags have appeared), and always reads one byte less than the data received, and the parse of the data received leads to a wrong result. However I found that usbhidctl somewhere admit this (although the way it handles it seems like a hack). I modified usbhidaction to read one more byte if it found that Report ID tags had appeared. This also needs some modification to libusbhid. 2. There's no way to specify report ID. There should be one way to specify which Report ID one item is referring to, and usbhidaction should check the report ID prefix to determine if the item is corresponding to it. 3. ioctl USB_GET_REPORT_ID returns 0 According to the Definition, report ID 0 is reserved and should not be used. In fact, this keyboard sent its special key events with report ID = 1. So I have to hack usbhidaction to set reportid to 1. I think this is not right and should be fixed. In the Definition, there might be multiple report IDs, so why there's such an ioctl? 4. usbhidctl does not set reportid. reportid in usbhidctl is always zero. There's even no ioctl to set it. So to use it to listen to events I had manually changed reportid to 1. I think there should be an option to set which report ID to listen to. PS. Sorry for the incomplete mail. I've not been used to the new keyboard yet Cheers, Henry ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Sata disc management
On Fri, Mar 06, 2009 at 06:50:10PM +0100, Oliver Pinter wrote: Hi all! How to can I stop the idle sata disc under fbsd (for power save) ? I searched many hours on google, but I don't find any information for it, only for scsi subsystem. I think a program like camcontrol, but for sata disk. The sysutils/ataidle port ought to do the trick. -- Insert your favourite quote here. Erik Trulsson ertr1...@student.uu.se ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Fatal trap 12: page fault while in kernel mode on 7.1/amd64, but not 7.0
Gavin Atkinson wrote:
On Thu, 2009-03-05 at 19:55 -0500, Boris Kochergin wrote:
Ahoy. I recently upgraded an amd64 machine to 7.1-RELEASE, and started
getting a bunch of these at a pretty high frequency (a few hours to a
day apart):
http://acm.poly.edu/~spawk/IMG00033.jpg
The current process is always httpd. They're particularly annoying
because the machine doesn't actually ever reboot, requiring manual
intervention. Reverting the kernel back to 7.0 makes the panic go away,
and the machine had been happily running 7.0 for about a year
beforehand. I realize that the photo hardly contains any useful
debugging information, but I was hoping it might look familiar to
someone. If not, I guess I'll come back with a backtrace.
A backtrace will almost certainly be necessary to figure out what this
issue is, although there is a possibility that the output of
addr2line -e /boot/kernel/kernel.symbols 0x8:0x802d7010
might help, assuming you've not recompiled your kernel yet. (That
number should be the same as the instruction pointer shown by the
panic, but as the photo is quite blurred there's a chance I've got it
wrong, if you have a better picture of it or wrote it down then use
that)
Gavin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Here it is, with some additional information afterward:
Unread portion of the kernel message buffer:
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0x30
fault code = supervisor read data, page not present
instruction pointer = 0x8:0x80293faf
stack pointer = 0x10:0x9cbaea70
frame pointer = 0x10:0xff000fc14000
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= resume, IOPL = 0
current process = 881 (httpd)
trap number = 12
panic: page fault
cpuid = 1
Uptime: 1m51s
Physical memory: 8185 MB
Dumping 328 MB: 313 297 281 265 249 233 217 201 185 169 153 137 121 105
89 73 57 41 25 9
#0 doadump () at pcpu.h:195
195 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) where
#0 doadump () at pcpu.h:195
#1 0xff000fc14000 in ?? ()
#2 0x8025eba9 in boot (howto=260) at
/usr/src-7.1/sys/kern/kern_shutdown.c:418
#3 0x8025efb2 in panic (fmt=0x104 Address 0x104 out of
bounds) at /usr/src-7.1/sys/kern/kern_shutdown.c:574
#4 0x803df5c3 in trap_fatal (frame=0xff000fc14000,
eva=Variable eva is not available.
) at /usr/src-7.1/sys/amd64/amd64/trap.c:764
#5 0x803e018f in trap (frame=0x9cbae9c0) at
/usr/src-7.1/sys/amd64/amd64/trap.c:290
#6 0x803c5c4e in calltrap () at
/usr/src-7.1/sys/amd64/amd64/exception.S:209
#7 0x80293faf in turnstile_broadcast (ts=0x0, queue=0) at
/usr/src-7.1/sys/kern/subr_turnstile.c:836
#8 0x8025256a in _mtx_unlock_sleep (m=0x80593538,
opts=Variable opts is not available.
) at /usr/src-7.1/sys/kern/kern_mutex.c:619
#9 0x80275ed3 in __umtx_op_cv_wait (td=0x1ee, uap=Variable
uap is not available.
) at /usr/src-7.1/sys/kern/kern_umtx.c:312
#10 0x803dfb78 in syscall (frame=0x9cbaec80) at
/usr/src-7.1/sys/amd64/amd64/trap.c:907
#11 0x803c5e5b in Xfast_syscall () at
/usr/src-7.1/sys/amd64/amd64/exception.S:330
#12 0x000800f5354c in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb)
The dump was difficult to acquire--the system would often lock up after
dumping only a portion of the memory it wanted to save. I can also now
trigger the panic pretty reliably using this bit of script:
#!/usr/local/bin/bash
for i in {1..900}
do
wget --quiet -O /dev/null http://acm.poly.edu/wiki/Hosting
done
...where the URL is a MediaWiki installation on the afflicted machine.
-Boris
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Sata disc management
thanks, the sysutils/ataidle is the best answer On 3/6/09, Philipp Ost p...@smo.de wrote: Oliver Pinter wrote: How to can I stop the idle sata disc under fbsd (for power save) ? I searched many hours on google, but I don't find any information for it, only for scsi subsystem. I think a program like camcontrol, but for sata disk. Did you (already) check your BIOS if there's such an option? HTH, Philipp ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Sata disc management
7.1 adds the spindown command to atacontrol(8), which may also be worth a look. -Boris Oliver Pinter wrote: thanks, the sysutils/ataidle is the best answer On 3/6/09, Philipp Ost p...@smo.de wrote: Oliver Pinter wrote: How to can I stop the idle sata disc under fbsd (for power save) ? I searched many hours on google, but I don't find any information for it, only for scsi subsystem. I think a program like camcontrol, but for sata disk. Did you (already) check your BIOS if there's such an option? HTH, Philipp ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Sata disc management
Oliver Pinter wrote: How to can I stop the idle sata disc under fbsd (for power save) ? I searched many hours on google, but I don't find any information for it, only for scsi subsystem. I think a program like camcontrol, but for sata disk. Did you (already) check your BIOS if there's such an option? HTH, Philipp ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
cd ripping to flac
Howdy!
I'd like to rip my cd-s to flac files using some
command line app, like cdda2wav or cdparanoia.
Using pipe to flac utility would be nice and the
way I'd take. What program acts in that matter?
Since cdda2wav is in the base, I suppose people
use it regurarly. Something like:
program {options} - | flac - flac_file.flac
One more thing bothers me. I cannot see songs on
the cd in the way of /dev/acd0t1. I tried to
stress it using cdcontrol, but no way. The kernel
is customized, no sound in it, and a lot of others
has gone. The box is speakers-free, so cannot
check if it plays in deed.
Best regards
Zoran
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
