Re: mergemaster annoyance or not?
Daniel O'Connor docon...@gsoft.com.au wrote: I wonder how hard it would be to add 3 way merging (like sysutils/etcmerge) to mergemaster.. One complication: to do a 3-way merge you have to have the common ancestor. To ensure the initial availability of such would require some infrastructure which AFAIK does not currently exist: * A standardized place to keep the original contents of /etc -- /origEtc or /etc-versionId anyone? * A way to ensure that installation populates that place with the needed redundant copy of the bits, either by including the additional instance within the distributions or by generating it in the course of installation. The former would likely be easier, if only because the latter would need to work for all installation methods. ___ 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: mergemaster annoyance or not?
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
The attached patch adds a -F option to automatically install files
when only the FreeBSD $Ids differ. I've tested this and it seems to do
what the people concerned about this issue are asking for.
If someone affected by this issue could please test this patch and
report back I'd appreciate it.
Doug
- --
This .signature sanitized for your protection
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (FreeBSD)
iEYEAREDAAYFAkm6G6oACgkQyIakK9Wy8PsUXwCg5hPG8G2swKOC0uhRA5L7Q6xb
a7kAn3DKCxL30ggNzTC9EKBhhjMfgpWq
=8U1J
-END PGP SIGNATURE-
Index: mergemaster.sh
===
--- mergemaster.sh (revision 189761)
+++ mergemaster.sh (working copy)
@@ -263,11 +265,14 @@
# Check the command line options
#
-while getopts :ascrvhipCPm:t:du:w:D:A:U COMMAND_LINE_ARGUMENT ; do
+while getopts :ascrvhipCPm:t:du:w:D:A:FU COMMAND_LINE_ARGUMENT ; do
case ${COMMAND_LINE_ARGUMENT} in
A)
ARCHSTRING='TARGET_ARCH='${OPTARG}
;;
+ F)
+FREEBSD_ID=yes
+;;
U)
AUTO_UPGRADE=yes
;;
@@ -1020,6 +1025,20 @@
# Use more if not.
# Use unified diffs by default. Context diffs give me a headache. :)
#
+
+ # XXX
+ if [ -n $FREEBSD_ID ]; then
+ if diff -q -I$FreeBSD:.*[$] ${DESTDIR}${COMPFILE#.} ${COMPFILE} \
+ /dev/null 21; then
+ if mm_install ${COMPFILE}; then
+echo *** Updated revision control Id for ${DESTDIR}${COMPFILE#.}
+ else
+echo *** Problem installing ${COMPFILE}, it will remain to merge
by hand later
+ fi
+ continue
+ fi
+ fi
+
case ${AUTO_RUN} in
'')
# prompt user to install/delete/merge changes
___
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: NICs locking up, *tcp_sc_h
On Fri, 13 Mar 2009, Nick Withers wrote: I recently installed my first amd64 system (currently running RELENG_7 from 2009-03-11) to replace an aged ppc box and have been having dramas with the network locking up. Breaking into the debugger manually and ps-ing shows the network card (e.g., [irq20: fxp0+]) in state LL in *tcp_sc_h. It seems the process(es) trying to access the card at the time is / are in state L in *tcp. I thought this may have been something-or-other in the fxp driver, so installed an rl card and sadly ran into the issue again. The console appears unresponsive, but I can get into the debugger (and as soon as I have, input I'd sent seems to go through, e.g., if I hit Enter a couple o' times, nothing happens; when I Ctrl+Alt+Esc into the debugger a few login prompts pop up before the debugger output). A where on the fxp / rl process (thread?) gives (transcribed from the console): Sounds like a lock leak -- if you're running INVARIANTS, then show allocks and show allchains would be useful. I've had a report of a TCP lock leak possibly in tcp_input(), but haven't managed to track it down yet -- this could well be it as well. Robert N M Watson Computer Laboratory University of Cambridge Tracing PID 31 tid 100030 td 0xff00012016e0 sched_switch() at sched_switch+0xf1 mi_switch() at mi_switch+0x18f turnstile_wait() at turnstile_wait+0x1cf _mtx_lock_sleep() at _mtx_lock_sleep+0x76 syncache_lookup() at syncache_lookup+0x176 syncache_expand() at syncache_expand+0x38 tcp_input() at tcp_input+0xa7d ip_input() at ip_input+0xa8 ether_demux() at ether_demux+0x1b9 ether_input() at ether_input+0x1bb fxp_intr() at fxp_intr+0x233 ithread_loop() at ithread_loop+0x17f fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe A where on a process stuck in *tcp, in this case [swi4: clock], gave the somewhat similar: sched_switch() at sched_switch+0xf1 mi_switch() at mi_switch+0x18f turnstile_wait() at turnstile_wait+0x1cf _rw_rlock() at _rw_rlock+0x8c ipfw_chk() at ipfw_chk+0x3ab2 ipfw_check_out() at ipfw_check_out+0xb1 pfil_run_hooks() at pfil_run_hooks+0x9c ip_output() at ip_output+0x367 syncache_respond() at syncache_respond+0x2fd syncache_timer() at syncache_timer+0x15a (...) In this particular case, the fxp0 card is in a lagg with rl0, but this problem can be triggered with either card on their own... The scheduler is SCHED_ULE. I'm not too sure how to give more useful information that this, I'm afraid. It's a custom kernel, too... Do I need to supply information on what code actually exists at the relevant addresses (I'm not at all clued in on how to do this... Sorry!)? Should I chuck WITNESS, INVARIANTS et al. in? I *think* every time this has been triggered there's been a python2.5 process in the *tcp state. This machine runs net-p2p/deluge and generally has at least 100 TCP connections on the go at any given time. Can anyone give me a clue as to what I might do to track this down? Appreciate any pointers. -- Nick Withers email: n...@nickwithers.com Web: http://www.nickwithers.com Mobile: +61 414 397 446 ___ 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: mergemaster annoyance or not?
On Friday 13 March 2009 17:56:17 per...@pluto.rain.com wrote: Daniel O'Connor docon...@gsoft.com.au wrote: I wonder how hard it would be to add 3 way merging (like sysutils/etcmerge) to mergemaster.. One complication: to do a 3-way merge you have to have the common ancestor. To ensure the initial availability of such would require some infrastructure which AFAIK does not currently exist: * A standardized place to keep the original contents of /etc -- /origEtc or /etc-versionId anyone? etcmerge keeps it in /var/db/etc * A way to ensure that installation populates that place with the needed redundant copy of the bits, either by including the additional instance within the distributions or by generating it in the course of installation. The former would likely be easier, if only because the latter would need to work for all installation methods. IMO it is OK to fall back to a 2 way diff if it doesn't exist (ie the first time you run it) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: NICs locking up, *tcp_sc_h
On Fri, 13 Mar 2009, Nick Withers wrote: Sorry for the original double-post, by the way, not quite sure how that happened... I can reproduce this problem relatively easily, by the way (every 3 days, on average). I meant to say this before, too, but it seems to happen a lot more often on the fxp than on rl. I'm sorry to ask what is probably a very simple question, but is there somewhere I should look to get clues on debugging from a manually generated dump? I tried panic after manually envoking the kernel debugger but proved highly inept at getting from the dump the same information ps / where gave me within the debugger live. If this is, in fact, a TCP input lock leak of some sort, then most likely some particular property of a host your system talks to, or a network it runs over, triggers this (presumably) unusual edge case -- perhaps a firewall that mucks with TCP in a funny way, etc. Of course, it might be something completely different -- the fact that everything is blocked on *tcp_sc_h and *tcp, simply means that something holding TCP locks hasn't released them, and this could happen for a number of reasons. Once you've acquired a crashdump, you can run crashinfo(8), which will produce a summary of useful debugging information. There are some things that are a bit easier to do in the run-time debugger, such as lock analysis, as the run-time debugger is more up-close and personal with in-kernel data structures; other things are easier in kgdb, which has complete source code and C type access. I find kgdb works pretty well for everything but show much what locks are held. Many of our system monitoring tools, including ps and portions of netstat, can actually be run on crashdumps to report the state of the system at the time it crashed -- take a look at the -M and -N command line arguments, which respectively allow you to point those tools at the crashdump and at a kernel with debugging symbols (typically kernel.debug or kernel.symbols) matching the kernel that was booted at the time of the crash. Robert N M Watson Computer Laboratory University of Cambridge Ta for your help! Robert N M Watson Computer Laboratory University of Cambridge Tracing PID 31 tid 100030 td 0xff00012016e0 sched_switch() at sched_switch+0xf1 mi_switch() at mi_switch+0x18f turnstile_wait() at turnstile_wait+0x1cf _mtx_lock_sleep() at _mtx_lock_sleep+0x76 syncache_lookup() at syncache_lookup+0x176 syncache_expand() at syncache_expand+0x38 tcp_input() at tcp_input+0xa7d ip_input() at ip_input+0xa8 ether_demux() at ether_demux+0x1b9 ether_input() at ether_input+0x1bb fxp_intr() at fxp_intr+0x233 ithread_loop() at ithread_loop+0x17f fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe A where on a process stuck in *tcp, in this case [swi4: clock], gave the somewhat similar: sched_switch() at sched_switch+0xf1 mi_switch() at mi_switch+0x18f turnstile_wait() at turnstile_wait+0x1cf _rw_rlock() at _rw_rlock+0x8c ipfw_chk() at ipfw_chk+0x3ab2 ipfw_check_out() at ipfw_check_out+0xb1 pfil_run_hooks() at pfil_run_hooks+0x9c ip_output() at ip_output+0x367 syncache_respond() at syncache_respond+0x2fd syncache_timer() at syncache_timer+0x15a (...) In this particular case, the fxp0 card is in a lagg with rl0, but this problem can be triggered with either card on their own... The scheduler is SCHED_ULE. I'm not too sure how to give more useful information that this, I'm afraid. It's a custom kernel, too... Do I need to supply information on what code actually exists at the relevant addresses (I'm not at all clued in on how to do this... Sorry!)? Should I chuck WITNESS, INVARIANTS et al. in? I *think* every time this has been triggered there's been a python2.5 process in the *tcp state. This machine runs net-p2p/deluge and generally has at least 100 TCP connections on the go at any given time. Can anyone give me a clue as to what I might do to track this down? Appreciate any pointers. -- Nick Withers email: n...@nickwithers.com Web: http://www.nickwithers.com Mobile: +61 414 397 446 -- Nick Withers email: n...@nickwithers.com Web: http://www.nickwithers.com Mobile: +61 414 397 446 ___ 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: NICs locking up, *tcp_sc_h
On Fri, 2009-03-13 at 09:37 +, Robert Watson wrote: On Fri, 13 Mar 2009, Nick Withers wrote: I recently installed my first amd64 system (currently running RELENG_7 from 2009-03-11) to replace an aged ppc box and have been having dramas with the network locking up. Breaking into the debugger manually and ps-ing shows the network card (e.g., [irq20: fxp0+]) in state LL in *tcp_sc_h. It seems the process(es) trying to access the card at the time is / are in state L in *tcp. I thought this may have been something-or-other in the fxp driver, so installed an rl card and sadly ran into the issue again. The console appears unresponsive, but I can get into the debugger (and as soon as I have, input I'd sent seems to go through, e.g., if I hit Enter a couple o' times, nothing happens; when I Ctrl+Alt+Esc into the debugger a few login prompts pop up before the debugger output). A where on the fxp / rl process (thread?) gives (transcribed from the console): Sounds like a lock leak -- if you're running INVARIANTS, then show allocks and show allchains would be useful. I've had a report of a TCP lock leak possibly in tcp_input(), but haven't managed to track it down yet -- this could well be it as well. Righto, I'll recompile the kernel with INVARIANTS (hell, I'll go bananas and include everything listed in http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-deadlocks.html - anything else I might include?). Sorry for the original double-post, by the way, not quite sure how that happened... I can reproduce this problem relatively easily, by the way (every 3 days, on average). I meant to say this before, too, but it seems to happen a lot more often on the fxp than on rl. I'm sorry to ask what is probably a very simple question, but is there somewhere I should look to get clues on debugging from a manually generated dump? I tried panic after manually envoking the kernel debugger but proved highly inept at getting from the dump the same information ps / where gave me within the debugger live. Ta for your help! Robert N M Watson Computer Laboratory University of Cambridge Tracing PID 31 tid 100030 td 0xff00012016e0 sched_switch() at sched_switch+0xf1 mi_switch() at mi_switch+0x18f turnstile_wait() at turnstile_wait+0x1cf _mtx_lock_sleep() at _mtx_lock_sleep+0x76 syncache_lookup() at syncache_lookup+0x176 syncache_expand() at syncache_expand+0x38 tcp_input() at tcp_input+0xa7d ip_input() at ip_input+0xa8 ether_demux() at ether_demux+0x1b9 ether_input() at ether_input+0x1bb fxp_intr() at fxp_intr+0x233 ithread_loop() at ithread_loop+0x17f fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe A where on a process stuck in *tcp, in this case [swi4: clock], gave the somewhat similar: sched_switch() at sched_switch+0xf1 mi_switch() at mi_switch+0x18f turnstile_wait() at turnstile_wait+0x1cf _rw_rlock() at _rw_rlock+0x8c ipfw_chk() at ipfw_chk+0x3ab2 ipfw_check_out() at ipfw_check_out+0xb1 pfil_run_hooks() at pfil_run_hooks+0x9c ip_output() at ip_output+0x367 syncache_respond() at syncache_respond+0x2fd syncache_timer() at syncache_timer+0x15a (...) In this particular case, the fxp0 card is in a lagg with rl0, but this problem can be triggered with either card on their own... The scheduler is SCHED_ULE. I'm not too sure how to give more useful information that this, I'm afraid. It's a custom kernel, too... Do I need to supply information on what code actually exists at the relevant addresses (I'm not at all clued in on how to do this... Sorry!)? Should I chuck WITNESS, INVARIANTS et al. in? I *think* every time this has been triggered there's been a python2.5 process in the *tcp state. This machine runs net-p2p/deluge and generally has at least 100 TCP connections on the go at any given time. Can anyone give me a clue as to what I might do to track this down? Appreciate any pointers. -- Nick Withers email: n...@nickwithers.com Web: http://www.nickwithers.com Mobile: +61 414 397 446 -- Nick Withers email: n...@nickwithers.com Web: http://www.nickwithers.com Mobile: +61 414 397 446 signature.asc Description: This is a digitally signed message part
Re: NICs locking up, *tcp_sc_h
On Fri, 13 Mar 2009, Robert Watson wrote: Sounds like a lock leak -- if you're running INVARIANTS, then show allocks should read WITNESS and show allchains would be useful. I've had a report of a TCP lock leak possibly in tcp_input(), but haven't managed to track it down yet -- this could well be it as well. Robert N M Watson Computer Laboratory University of Cambridge ___ 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: Page fault panic in scioctl and console-kit-daemon
On Mon, Mar 09, 2009 at 12:15:15PM +0100, spara wrote: Hello, I'm experiencing the same (http://www.mail-archive.com/freebsd-stable@freebsd.org/msg101997.html) after updating to last hald in 6.4-STABLE. Anyone tried to fix it with the Kostik Belousov patch as in http://lists.freebsd.org/pipermail/freebsd-current/2008-January/082581.html ? You mean the patch attached to this message: http://lists.freebsd.org/pipermail/freebsd-current/2008-February/083586.html ? If so, I didn't try because the message says committed to all branches. But I can try, if it's necessary... Any other fix ? It seems to me that no package has been depending on consolekit, since a couple of days. At least, portupgrade is not showing any more stale dependencies when I try to portupgrade -aR without having consolekit installed. So I'm living happily without it. :-) -- rigo http://rigo.altervista.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: NICs locking up, *tcp_sc_h
On Fri, 13 Mar 2009 20:56:24 +1100 Nick Withers wrote: I'm sorry to ask what is probably a very simple question, but is there somewhere I should look to get clues on debugging from a manually generated dump? I tried panic after manually envoking the kernel debugger but proved highly inept at getting from the dump the same information ps / where gave me within the debugger live. You can capture ddb session in capture buffer and then extract it from the dump. In ddb run capture on do your debugging then run panic or call doadump and after reboot: ddb capture -M /var/crash/vmcore.X print out I would recommend to increase debug.ddb.capture.bufsize sysctl variable to be sure all the ddb session will be captured. -- Mikolaj Golub ___ 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: Tester wanted for multipath failover iSCSI target software
Oh dear doing the test again caused the client machine to panic, with the following message: panic: solaris assert: 0 == dmu_buf_hold(os, lr-lr_foid, boff, zgd, db), file /usr/src/sys/modules/zfs/../../cddl/controb/opensolaris/uts/common/fs/zfs/zfs_nops.c, line: 955 I have not read the message in my experience. Do you have encountered frequency? -- Daisuke Aoyama ___ 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: Tester wanted for multipath failover iSCSI target software
I have not read the message in my experience. Do you have encountered frequency? Only once. I did not try it again because that is our work server. I did two testrs, copying files. 1) Using iscsi-target ... copies OK, but ZFS pool has errors 2) Using istgt - causes the panic described. The copy is 53 gigabytes of small files. -pete. ___ 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
Panic in radeon_get_vblank_counter()
After upgrading my laptop (Dell 600m) yesterday, I have begun to experience panics on it probably related to the DRM update. Killing the X server by Ctrl-Alt-Backspace is a good way to lock the system. Reboot to get a core dump. Piece of Xorg.log concerning the hardware using the xf86-video-ati-6.11.0 driver: (--) PCI:*(0...@1:0:0) ATI Technologies Inc Radeon RV250 [Mobility FireGL 9000] rev 1, Mem @ 0xe800/0, 0xfcff/0, I/O @ 0xc000/0, BIOS @ 0x/65536 ... (--) RADEON(0): Chipset: ATI Radeon Mobility 9000 (M9) Lf (AGP) (ChipID = 0x4c66) Special options in xorg.conf: Section Device ... Option EnablePageFlip true Option AccelMethodEXA EndSection Section Screen ... Option AddARGBGLXVisuals True Option DisableGLXRootClipping True Option XAANoOffscreenPixmaps True ... EndSection pciconf -lv of the device: vgap...@pci0:1:0:0: class=0x03 card=0x011e1028 chip=0x4c661002 rev=0x01 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'ATI MOBILITY RADEON 9000 (Microsoft Corporation - Radeon Mobility M9' class = display subclass = VGA /var/log/messages about drm: Mar 13 15:41:51 baba kernel: drm0: ATI Radeon Lf RV250 Mobility 9000 M9 / FireMV 2400 PCI on vgapci0 Mar 13 15:41:51 baba kernel: vgapci0: child drm0 requested pci_enable_busmaster Mar 13 15:41:51 baba kernel: info: [drm] AGP at 0xe000 128MB Mar 13 15:41:51 baba kernel: info: [drm] Initialized radeon 1.29.0 20080613 Mar 13 15:41:52 baba kernel: info: [drm] Setting GART location based on new memory map Mar 13 15:41:52 baba kernel: info: [drm] Loading R200 Microcode Mar 13 15:41:52 baba kernel: info: [drm] writeback test succeeded in 1 usecs Mar 13 15:41:52 baba kernel: drm0: [ITHREAD] Panic attached. Sean -- s...@freebsd.orgFatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x10 fault code = supervisor read, page not present instruction pointer = 0x20:0xc341eb48 stack pointer = 0x28:0xc2b2bc3c frame pointer = 0x28:0xc2b2bc4c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 13 (swi4: clock sio) trap number = 12 panic: page fault cpuid = 0 Uptime: 12h18m28s Physical memory: 503 MB Dumping 99 MB: 84 68 52 36 20 4 Reading symbols from /boot/kernel/if_tap.ko...Reading symbols from /boot/kernel/if_tap.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_tap.ko Reading symbols from /boot/kernel/snd_ich.ko...Reading symbols from /boot/kernel/snd_ich.ko.symbols...done. done. Loaded symbols for /boot/kernel/snd_ich.ko Reading symbols from /boot/kernel/sound.ko...Reading symbols from /boot/kernel/sound.ko.symbols...done. done. Loaded symbols for /boot/kernel/sound.ko Reading symbols from /boot/kernel/atapicam.ko...Reading symbols from /boot/kernel/atapicam.ko.symbols...done. done. Loaded symbols for /boot/kernel/atapicam.ko Reading symbols from /boot/kernel/aio.ko...Reading symbols from /boot/kernel/aio.ko.symbols...done. done. Loaded symbols for /boot/kernel/aio.ko Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/linprocfs.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/linsysfs.ko...Reading symbols from /boot/kernel/linsysfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/linsysfs.ko Reading symbols from /boot/kernel/pflog.ko...Reading symbols from /boot/kernel/pflog.ko.symbols...done. done. Loaded symbols for /boot/kernel/pflog.ko Reading symbols from /boot/kernel/pf.ko...Reading symbols from /boot/kernel/pf.ko.symbols...done. done. Loaded symbols for /boot/kernel/pf.ko Reading symbols from /boot/kernel/daemon_saver.ko...Reading symbols from /boot/kernel/daemon_saver.ko.symbols...done. done. Loaded symbols for /boot/kernel/daemon_saver.ko Reading symbols from /boot/kernel/radeon.ko...Reading symbols from /boot/kernel/radeon.ko.symbols...done. done. Loaded symbols for /boot/kernel/radeon.ko Reading symbols from /boot/kernel/drm.ko...Reading symbols from /boot/kernel/drm.ko.symbols...done. done. Loaded symbols for /boot/kernel/drm.ko #0 doadump () at pcpu.h:196 196 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump () at pcpu.h:196 #1 0xc05b6fe7 in boot (howto=260) at /usr/FreeBSD/RELENG_7/src/sys/kern/kern_shutdown.c:418 #2 0xc05b72b9 in panic (fmt=Variable fmt is not available. ) at
S. M. Ibrahim lavlu's Member Invite
Hey there, Not too long ago S. M. Ibrahim lavlu sent you an invite to join the Scour search community and your invite is still open! The Scour search engine is shaped by a community of users just like you, and your contributions are what make it a success! Why use Scour? 1. Get Yahoo, Google and MSN results in one search 2. Vote on result relevancy 3. Read user comments 4. Get paid for searching! Create your profile at http://scour.com/invite/lavluda/r/ and enjoy searching the web through your favorite search engines. With time, youll get paid like these loyal users: http://www.scour.com/leaderboard page. Come and be part of the largest Social Search community and help make the results better! See you soon, The Scour Team www.scour.com This message was sent to you as a friend referral to join scour.com, please feel free to review our http://scour.com/privacy page and our http://scour.com/communityguidelines/antispam page. If you prefer not to receive invitations from ANY scour members, please click here - http://www.scour.com/unsub/e/ZnJlZWJzZC1zdGFibGVAZnJlZWJzZC5vcmc= -OR- Write to us at: Scour, Inc., 15303 Ventura Blvd. Suite 860, Sherman Oaks, CA 91403, USA. campaignid: scour200903130002 ___ 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: Panic in radeon_get_vblank_counter()
On Fri, 2009-03-13 at 15:49 -0500, Sean C. Farley wrote: After upgrading my laptop (Dell 600m) yesterday, I have begun to experience panics on it probably related to the DRM update. Killing the X server by Ctrl-Alt-Backspace is a good way to lock the system. Reboot to get a core dump. Piece of Xorg.log concerning the hardware using the xf86-video-ati-6.11.0 driver: (--) PCI:*(0...@1:0:0) ATI Technologies Inc Radeon RV250 [Mobility FireGL 9000] rev 1, Mem @ 0xe800/0, 0xfcff/0, I/O @ 0xc000/0, BIOS @ 0x/65536 ... (--) RADEON(0): Chipset: ATI Radeon Mobility 9000 (M9) Lf (AGP) (ChipID = 0x4c66) Special options in xorg.conf: Section Device ... Option EnablePageFlip true Option AccelMethodEXA EndSection Section Screen ... Option AddARGBGLXVisuals True Option DisableGLXRootClipping True Option XAANoOffscreenPixmaps True ... EndSection pciconf -lv of the device: vgap...@pci0:1:0:0: class=0x03 card=0x011e1028 chip=0x4c661002 rev=0x01 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'ATI MOBILITY RADEON 9000 (Microsoft Corporation - Radeon Mobility M9' class = display subclass = VGA /var/log/messages about drm: Mar 13 15:41:51 baba kernel: drm0: ATI Radeon Lf RV250 Mobility 9000 M9 / FireMV 2400 PCI on vgapci0 Mar 13 15:41:51 baba kernel: vgapci0: child drm0 requested pci_enable_busmaster Mar 13 15:41:51 baba kernel: info: [drm] AGP at 0xe000 128MB Mar 13 15:41:51 baba kernel: info: [drm] Initialized radeon 1.29.0 20080613 Mar 13 15:41:52 baba kernel: info: [drm] Setting GART location based on new memory map Mar 13 15:41:52 baba kernel: info: [drm] Loading R200 Microcode Mar 13 15:41:52 baba kernel: info: [drm] writeback test succeeded in 1 usecs Mar 13 15:41:52 baba kernel: drm0: [ITHREAD] Ok, I'll try to look at this soon... It would be useful if you could enable hw.dri.0.debug=1 and send me the debug output as well, if you can get anything useful before it locks up. robert. Panic attached. Sean -- s...@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 -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: Panic in radeon_get_vblank_counter()
On Fri, 13 Mar 2009, Robert Noland wrote: On Fri, 2009-03-13 at 15:49 -0500, Sean C. Farley wrote: After upgrading my laptop (Dell 600m) yesterday, I have begun to experience panics on it probably related to the DRM update. Killing the X server by Ctrl-Alt-Backspace is a good way to lock the system. Reboot to get a core dump. Piece of Xorg.log concerning the hardware using the xf86-video-ati-6.11.0 driver: (--) PCI:*(0...@1:0:0) ATI Technologies Inc Radeon RV250 [Mobility FireGL 9000] rev 1, Mem @ 0xe800/0, 0xfcff/0, I/O @ 0xc000/0, BIOS @ 0x/65536 ... (--) RADEON(0): Chipset: ATI Radeon Mobility 9000 (M9) Lf (AGP) (ChipID = 0x4c66) Special options in xorg.conf: Section Device ... Option EnablePageFlip true Option AccelMethodEXA EndSection Section Screen ... Option AddARGBGLXVisuals True Option DisableGLXRootClipping True Option XAANoOffscreenPixmaps True ... EndSection pciconf -lv of the device: vgap...@pci0:1:0:0: class=0x03 card=0x011e1028 chip=0x4c661002 rev=0x01 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'ATI MOBILITY RADEON 9000 (Microsoft Corporation - Radeon Mobility M9' class = display subclass = VGA /var/log/messages about drm: Mar 13 15:41:51 baba kernel: drm0: ATI Radeon Lf RV250 Mobility 9000 M9 / FireMV 2400 PCI on vgapci0 Mar 13 15:41:51 baba kernel: vgapci0: child drm0 requested pci_enable_busmaster Mar 13 15:41:51 baba kernel: info: [drm] AGP at 0xe000 128MB Mar 13 15:41:51 baba kernel: info: [drm] Initialized radeon 1.29.0 20080613 Mar 13 15:41:52 baba kernel: info: [drm] Setting GART location based on new memory map Mar 13 15:41:52 baba kernel: info: [drm] Loading R200 Microcode Mar 13 15:41:52 baba kernel: info: [drm] writeback test succeeded in 1 usecs Mar 13 15:41:52 baba kernel: drm0: [ITHREAD] Ok, I'll try to look at this soon... It would be useful if you could enable hw.dri.0.debug=1 and send me the debug output as well, if you can get anything useful before it locks up. I have not had luck reproducing a panic, but I can get the computer to lock up at startup of the X server (rarely) and shutdown (often). This may not be accurate, but I think I am able to shutdown safely if I switch to a tty and wait until this debug line is printed: [drm:pid13:vblank_disable_fn] vblank_disable_allowed=1 If I start rebooting before it is printed, the system locks up. Of course, this is only after rebooting several times. Here is a successful start and shutdown: http://people.freebsd.org/~scf/drm-dmesg.log http://people.freebsd.org/~scf/Xorg.0.log Does that help? Sean -- s...@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
