Re: RELENG_7 - has mergemaster changed logic since 7.2-RELEASE?
On Sun, 10 May 2009 21:49:23 -0700 Doug Barton wrote: > Torfinn Ingolfsen wrote: > > To be clear, I follow this procedure: > > 1. make buildworld > > 2. make kernel > > 3. shutdown now > > 4. mergemaster -p > > 5. make installworld > > 6. mergemaster -iU > > 7. fastboot > > By any chance is any of this happening in a jail? No - no jails. > Or by any chance is /etc a symlink? No, /etc is a regular directory (I just checked the machines). -- Regards, Torfinn Ingolfsen ___ 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"
zfs: dataset is busy
Hi all, I have several machines here that do automatic snapshotting via RSEs snapshot-tool (sysutils/freebsd-snapshot). I use a homemade script to incrementally transfer daily snapshots to a backup server. This runs fine with machines running 7.0-STABLE of Jun 08. However, I have one box with 7.1-PRERELEASE from Sep 08 showing the following error after some time (when trying to rotate the snapshots via the freebsd-snapshot tool): cannot destroy 'tank/w...@daily.6': dataset is busy I fact I cannot do anything to the snapshot, neither destroy nor export (not even with "-f"), it is always "busy". The only chance to get away from this I found is to reboot the machine. After a reboot it is fine for some weeks, but then comes back with the same problem. Has anyone seen this before? Is there a fix or workaround available? Are there any improvements I could take profit of by upgrading to 7.2-stable? Right now the machine is in this state, so I could get some more information from it (if anyone tells me what to do :-). cu Gerrit ___ 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: EEEPC and FreeBSD 7.2
Hello, On Fri, May 8, 2009 at 11:47 AM, David Marec wrote: > I am trying to use an EEEPC 701 as a diskless station, running FreeBSD 7. Great mini machine ! > The EEPC station boots well with PXE then runs the kernel, but the only > network card that is recognized is the wireless one (ath0). > > I read that the wired NIC ( ae? ) has been committed to HEAD; is there any way > to make it work on 7-STABLE ? It works out of the box with 7.2 You hust have to add if_ae_load="YES" in your /boot/loader.conf H-P -- HPC ___ 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: failure building nanobsd with FreeBSD Stable
On Mon, 11 May 2009 15:56:11 +1000 Graham Menhennitt wrote: > touch: not found Please check it the system time was changed between c(v)sup -> buildworld. I case yes, just redo the process. WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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: lock up in 6.2 (procs massively stuck in Giant)
On Monday 04 May 2009 11:41:35 pm pluknet wrote:
> 2009/5/1 John Baldwin :
> > On Thursday 30 April 2009 2:36:34 am pluknet wrote:
> >> Hi folks.
> >>
> >> Today I got a new locking issue.
> >> This is the first time I got it, and it's merely reproduced.
> >>
> >> The box has lost both remote connection and local access.
> >> No SIGINFO output on the local console even.
> >> Jumping in ddb> shows the next:
> >>
> >> 1) first, this is a 8-way web server. No processes on runqueue except one
> > httpd
> >> (i.e. ps shows R in its state):
> >
> > You need to find who owns Giant and what that thread is doing. You can
try
> > using 'show lock Giant' as well as 'show lockchain 11568'.
> >
>
> Hi, John!
>
> Just reproduced now on another box.
> Hmm.. stack of the process owing Giant looks garbled.
>
> db> show lock Giant
> class: sleep mutex
> name: Giant
> flags: {DEF, RECURSE}
> state: {OWNED, CONTESTED}
> owner: 0xd0d79320 (tid 102754, pid 34594, "httpd")
>
> db> show lockchain 34594
> thread 102754 (pid 34594, httpd) running on CPU 7
> db> show lockchain 102754
> thread 102754 (pid 34594, httpd) running on CPU 7
The thread is running, so we don't know what it's top of stack is and you
can't a good stack trace in that case.
None of your CPUs are idle, so I don't think you have any sort of deadlock.
You might have a livelock.
--
John Baldwin
___
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: devd doesn't fire event on boot
On Wednesday 06 May 2009 6:03:14 am Ronald Klop wrote: > Hello, > > Running 7.2-STABLE/amd64. I have a USB-disk and added stuff to devd to > mount it readonly on attach. This does work if I attach it after booting > up, but not if it is attached before booting. devd throws away all events that happen prior to devd starting up I think. -- John Baldwin ___ 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: RELENG_7 fatal trap
On Thursday 07 May 2009 8:41:44 am Alexander Kriventsov wrote: > Hi, > Sorry for my english. > I have fatal trap on my box. > Kernel compiled with debug options. System is RELENG_7 amd64 dated > 2009-04-14. I think this is fixed in the latest RELENG_7. -- John Baldwin ___ 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: kern/130330: [mpt] [panic] Panic and reboot machine MPT ...
On Mon, May 11, 2009 at 09:53:21AM -0400, John Baldwin wrote: >> What can I do now? > Can you get more details on the crash, perhaps a crash dump? All what you want, but you need to drive me, I was unable to setup serial/debug console so I must wrote down by hand (followed handbook, tryed all speed/duplex pairs, still having "graphics" strange chars, maybe the cable or setup). Using a kernel with all know (to me) debug knobs enabled :-) -- Riccardo. ___ 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: kern/130330: [mpt] [panic] Panic and reboot machine MPT ...
On Thursday 07 May 2009 11:50:12 am Riccardo Torrini wrote: > I just submitted a follow-up to PR kern/130330 with the same > info. Maybe I found the committed lines doing the crash. > > Please see PR for more detailed info (and cc: this thread to me). > > I restricted the time window of the problem doing (a lot of) > build&install world from 2008.07 up to now (read last week). > > With 2008.07.28.17.00.00 (7.0-STABLE) works fine but > with 2008.07.28.18.00.00 start crashing removing the > the second disk of a mirror (when the mirror is ok) > or adding the second disk of a degraded ones. > > Also note that the same crash happens with all 7.1 > stable or release and even all 7.2-PRE I tested. > > (wrapping long lines) > # cd /home/ncvs/src/sys/ > # grep -R "date.*2008\.07\.28\.17" ./ | grep -v /Attic > > ./dev/wi/if_wi.c,v: > date2008.07.28.17.00.37;author imp; state Exp; > ./dev/wi/if_wivar.h,v: > date2008.07.28.17.00.37;author imp; state Exp; > ./dev/mpt/mpt_raid.c,v: > date2008.07.28.17.10.09;author jhb; state Exp; > ./dev/mpt/mpt_raid.c,v: > date2008.07.28.17.05.09;author jhb; state Exp; > ./kern/sched_4bsd.c,v: > date2008.07.28.17.25.24;author jhb; state Exp; > ./modules/et/Makefile,v: > date2008.07.28.17.56.37;author antoine; state Exp; > > In that time window there are only 4 file changed in > src/sys/dev, and I bet to mpt_raid.c :-) > > This is the commit log extracted from cvsweb > -8<- > Revision 1.15.2.1: > Mon Jul 28 17:05:09 2008 UTC (9 months, 1 week ago) by jhb > Branches: RELENG_7 > CVS tags: RELENG_7_1_BP > Branch point for: RELENG_7_1 > Diff to: previous 1.15: preferred, colored > Changes since revision 1.15: +4 -4 lines > > SVN rev 180920 on 2008-07-28 17:05:09Z by jhb > > MFC: Allocate a single CCB at the start of the main loop of the RAID > monitoring kthread of the mpt(4) driver. > -8<- > > Here are the diff: > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/mpt/mpt_raid.c.diff?r1=1.15;r2=1.15.2.1 > > > What can I do now? Can you get more details on the crash, perhaps a crash dump? -- John Baldwin ___ 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: 7.1-STABLE Sun Mar 29 01:06:46 ADT 2009 Locks up ...
On Saturday 09 May 2009 6:43:16 pm Marc G. Fournier wrote: > On Tue, 28 Apr 2009, Gavin Atkinson wrote: > > > On Fri, 2009-04-24 at 20:39 +0200, Martin Schmidt wrote: > >> Hi Marc and List, > >> > >> i had similar issues with FreeBSD 7.2-PRERELEASE. Server (zfs,nfs) > >> seems to hang in intervals of about 8 hours. > >> kernel is still there but no connections can be made to nfs/ssh and > >> login on local console doesn't seem to > >> work due to incredible slowness. breaking to the debugger takes a > >> moment but works. > >> (compiling kernel with WITNESS didnt help) > >> > >> the server had been solid before with 7 stable kernel from around 19 > >> October 2008. > >> > >> I now added these lines to /boot/loader.conf > >> > >> hw.pci.enable_msi=0 > >> hw.pci.enable_msix=0 > >> > >> to disable Message Signaled Interrupts. Which are used by the 3ware > >> twa driver and igb network driver on our server. > > > > If you are willing to test further on your server, it may be helpful if > > you could determine which of those two lines in loader.conf fixes the > > problem for you. It would also be useful to provide a dmesg from the > > machine when both msi and msix are enabled. > > > > FWIW, looking at the "vmstat -i" output it appears that only the igb > > driver that are using MSI/MSIX, unless you have a reason to suspect > > otherwise? > > How do you tell that, about igb? looking at the server I have the igb > device on, it doesn't seem to say anything about that ... IRQs > 256 are MSI/MSI-X. -- John Baldwin ___ 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: Garbled output from kgdb?
On Tuesday 05 May 2009 5:43:01 pm Jung-uk Kim wrote: > On Tuesday 05 May 2009 04:09 pm, Jung-uk Kim wrote: > > On Tuesday 05 May 2009 12:51 pm, Andriy Gapon wrote: > > > BTW, this issue seems to be fixed in Jung-uk's acpi patches for > > > newer acpica imports, but it is not fixed both in stable/7 and > > > head. > > > > Yes, it was fixed in my patchsets long ago, which uses spin lock > > for AcpiOsAcquireLock(). :-) > > The attached patch is for -STABLE. Note that it is only compile > tested on amd64. This looks fine to test. The patch has gratuitous style changes I wouldn't include in a commit though. -- John Baldwin ___ 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: Garbled output from kgdb?
On Monday 11 May 2009 09:52 am, John Baldwin wrote: > On Tuesday 05 May 2009 5:43:01 pm Jung-uk Kim wrote: > > On Tuesday 05 May 2009 04:09 pm, Jung-uk Kim wrote: > > > On Tuesday 05 May 2009 12:51 pm, Andriy Gapon wrote: > > > > BTW, this issue seems to be fixed in Jung-uk's acpi patches > > > > for newer acpica imports, but it is not fixed both in > > > > stable/7 and head. > > > > > > Yes, it was fixed in my patchsets long ago, which uses spin > > > lock for AcpiOsAcquireLock(). :-) > > > > The attached patch is for -STABLE. Note that it is only compile > > tested on amd64. > > This looks fine to test. The patch has gratuitous style changes I > wouldn't include in a commit though. It should work but I don't plan to commit it any time soon. :-) In fact, the patch was meant to be a rewrite for new ACPI-CA, which actually has a real mutex. Currently, mutex is emulated with semaphore. The problem is semaphore has no concept of ownership while mutex does, i.e., any thread can acquire/release it without checking its ownership or order. FYI, the OSL API (ACPI_MUTEX_TYPE) is finalized in ACPI-CA 20081204. Jung-uk Kim ___ 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: kern/130330: [mpt] [panic] Panic and reboot machine MPT ...
On Monday 11 May 2009 12:55:22 pm Riccardo Torrini wrote: > On Mon, May 11, 2009 at 09:53:21AM -0400, John Baldwin wrote: > > >> What can I do now? > > > Can you get more details on the crash, perhaps a crash dump? > > All what you want, but you need to drive me, I was unable > to setup serial/debug console so I must wrote down by hand > (followed handbook, tryed all speed/duplex pairs, still > having "graphics" strange chars, maybe the cable or setup). > > Using a kernel with all know (to me) debug knobs enabled :-) Do you have kernel crashdumps enabled and a swap partition? If so, do you happen to have any files in /var/crash? -- John Baldwin ___ 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: ipfilter seems to be broken on 7.2-PRERELEASE as of April 25:th 2009.
Jonas Bülow wrote: > > After reboot it was not reachable from the network. After some > troubleshooting I found that ipfilter seems to be the problem. Returning > traffic originating from my host (XXX) is blocked: > (... snip ...) > > Anyone seen this behaviour? > Yes. This appears to have made it to the RELEASE as well. I believe it is due to updates to the FXP driver that allow checksumming for tx/rx. My guess is checksumming is enabled by default and you (and I) happen to have the cards recognized by FXP that do not support it. (The BAD in the ipf log represents bad checksum) If you do "ifconfig fxp0 -txcsum -rxcsum" your problem should go away. For /etc/rc.conf, just add -txcsum -rxcsum to the interface definition. Regards, --Jason ___ 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: EEEPC and FreeBSD 7.2
Le Monday 11 May 2009 12:35:13 Henri-Pierre Charles, vous avez écrit : > Hello, > > On Fri, May 8, 2009 at 11:47 AM, David Marec wrote: > > I am trying to use an EEEPC 701 as a diskless station, running FreeBSD 7. > > Great mini machine ! I agree. This one is owned by my wife, who does not want to change the system that was shipped with it ( Xandros). > > The EEPC station boots well with PXE then runs the kernel, but the only > > network card that is recognized is the wireless one (ath0). > > > > I read that the wired NIC ( ae? ) has been committed to HEAD; is there > > any way to make it work on 7-STABLE ? > > It works out of the box with 7.2 > > You hust have to add if_ae_load="YES" in your /boot/loader.conf I built a kernel that included this driver and the EEEPC is now working quite well as a diskless station. But i have to launch Xorg locally. It doesn't start on XDMCP mode and i didn't found yet what is wrong with this. /I think i will start another thread on a Xorg dedicated list about this point and the touchpad configuration./ -- http://david.marec.free.fr/ http://www.freebsd.org/fr/ http://www.diablotins.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"
run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config
Hallo, I've just tried 7.2-RELEASE (amd64) on Asus M3A78-EM motherboard and booting got stuck with the following: run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config From what I've found via Google it should be fixed already but apparently it is not. :-( Is there a way to work around this issue and successfully boot and install FreeBSD, please ? Thanks, Martin ___ 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: run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config
In the last episode (May 12), martinko said: > I've just tried 7.2-RELEASE (amd64) on Asus M3A78-EM motherboard and > booting got stuck with the following: > > run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config > > From what I've found via Google it should be fixed already but apparently > it is not. :-( > > Is there a way to work around this issue and successfully boot and install > FreeBSD, please ? Do you have a connected firewire device? Try unplugging it during bootup, or kldload the sbp module after bootup instead of via loader.conf. -- Dan Nelson dnel...@allantgroup.com ___ 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: ipfilter seems to be broken on 7.2-PRERELEASE as of April 25:th 2009.
On Mon, May 11, 2009 at 01:07:46PM -0700, Jason Chambers wrote: > Jonas B?low wrote: > > > > After reboot it was not reachable from the network. After some > > troubleshooting I found that ipfilter seems to be the problem. Returning > > traffic originating from my host (XXX) is blocked: > > > (... snip ...) > > > > Anyone seen this behaviour? > > > > Yes. This appears to have made it to the RELEASE as well. > > I believe it is due to updates to the FXP driver that allow checksumming > for tx/rx. My guess is checksumming is enabled by default and you (and > I) happen to have the cards recognized by FXP that do not support it. I guess your controller is 82559 or compatibles. If you can receive packets without problems after disabling ipfilter it's not fault of fxp(4). You have a good controller that do support Rx checksum offloading. > (The BAD in the ipf log represents bad checksum) > No, ipfilter's notion of Rx checksum offloading was broken. ipfilter simply does not understand partial checksummed frame(e.g. checksummed frame without pseudo header) so driver that supports this type of checksum offloading(gem(4), hme(4), sk(4) and fxp(4)) wouldn't work on ipfilter. > If you do "ifconfig fxp0 -txcsum -rxcsum" your problem should go away. > For /etc/rc.conf, just add -txcsum -rxcsum to the interface definition. > Yeah, that would fix it or you can switch to pf(4). ___ 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"
Error message: run_interrupt_driven_hooks:...
Greetings... Basic data on my experience with the xpt_config hang; I have more detail if needed, but I doubt anyone will believe it. I'm not even sure I do. Some other reports: http://lists.freebsd.org/pipermail/freebsd-questions/2009-April/196116.html Seur Bors Thu Apr 9 14:43:34 UTC 2009. http://lists.freebsd.org/pipermail/freebsd-stable/2009-May/049901.html martinko gamato Mon May 11 22:05:56 UTC 2009 http://www.nabble.com/Freebsd-7.2-RC-boot-problem-tt23257632.html#a23257632 http://forums.pcbsd.org/viewtopic.php?f=1&t=13312 Here is the entire error for me during boot: run_interrupt_driven_hooks: still waiting after BIGNUM seconds for xpt_config It hangs after this point in the boot process: pcm0: pcm0: the boot process does not continue, so the next normal thing does not appear on the console: SMP: AP CPU #1 Launched! but during the hang, this scrolls past (punctuated by the BIGNUM seconds wait) over and over on the console: acpi_tz0: _TMP value is absurd, ignored (-269.4C) Normally, that message is suppressed by this /etc/sysctl.conf entry: hw.acpi.thermal.polling_rate=0 I suppose this means that /etc/sysctl.conf is not parsed and the second CPU is not launched. Hardware in question, as seen by dmesg, is attached; the vendor's specs are: Core 2 Duo (C) E6400 2.13 GHz 1066 MHz front side bus Socket 775 Chipset P965 Motherboard: Asus P5BW-LA HP/Compaq motherboard name: Basswood-UL8E There is RAID on the motherboard; I don't use it. I do use AHCI. BIOS is current; there are no available updates. The onboard firewire is disabled, since it began (prior to 7.1) causing unresolvable panics. CAM is in my kernel: # SCSI peripherals #Added atapicam; apparently, cdparanoia requires it. device atapicam device scbus # SCSI bus (required for SCSI) device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass# Passthrough device (direct SCSI access) As of 9:30 PM EDT May 11, the issue has de-Heisenberged from my PC. I'm not subscribed to the list; so you'll need to Cc: me if you think I can help. Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-RELEASE-p5 #0: Sun May 3 06:43:50 EDT 2009 r...@whisperer.chthonixia.net:/usr/obj/usr/src/sys/WHISPERER Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz (2135.55-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x2000 AMD Features2=0x1 Cores per package: 2 real memory = 2146299904 (2046 MB) avail memory = 2094936064 (1997 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 4 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 7fde (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_hpet0: iomem 0xfed0-0xfed003ff on acpi0 device_attach: acpi_hpet0 attach returned 12 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xde00-0xdeff mem 0xe000-0xefff,0xfddf-0xfddf irq 16 at device 0.0 on pci1 vgapci1: mem 0xfdde-0xfdde at device 0.1 on pci1 uhci0: port 0xff00-0xff1f irq 21 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xfe00-0xfe1f irq 18 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered ehci0: mem 0xfdfff000-0xfdfff3ff irq 21 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb2: EHCI version 1.0 usb2: companion controllers, 2 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: on usb2 uhub2: 4 ports with 4 removable, self powered pcm0: mem 0xfdff4000-0xfdff7fff irq 22 at device 27.0 on pci0 pcm0: [ITHREAD] uhci2: port 0xfd00-0xfd1f irq 23 at device 29.0 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb3: on uhci2 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered uhci3: port 0xfc00-0xfc1f irq 17 at device 29.1 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb
Re: lock up in 6.2 (procs massively stuck in Giant)
2009/5/11 John Baldwin :
> On Monday 04 May 2009 11:41:35 pm pluknet wrote:
>> 2009/5/1 John Baldwin :
>> > On Thursday 30 April 2009 2:36:34 am pluknet wrote:
>> >> Hi folks.
>> >>
>> >> Today I got a new locking issue.
>> >> This is the first time I got it, and it's merely reproduced.
>> >>
>> >> The box has lost both remote connection and local access.
>> >> No SIGINFO output on the local console even.
>> >> Jumping in ddb> shows the next:
>> >>
>> >> 1) first, this is a 8-way web server. No processes on runqueue except one
>> > httpd
>> >> (i.e. ps shows R in its state):
>> >
>> > You need to find who owns Giant and what that thread is doing. You can
> try
>> > using 'show lock Giant' as well as 'show lockchain 11568'.
>> >
>>
>> Hi, John!
>>
>> Just reproduced now on another box.
>> Hmm.. stack of the process owing Giant looks garbled.
>>
>> db> show lock Giant
>> class: sleep mutex
>> name: Giant
>> flags: {DEF, RECURSE}
>> state: {OWNED, CONTESTED}
>> owner: 0xd0d79320 (tid 102754, pid 34594, "httpd")
>>
>> db> show lockchain 34594
>> thread 102754 (pid 34594, httpd) running on CPU 7
>> db> show lockchain 102754
>> thread 102754 (pid 34594, httpd) running on CPU 7
>
> The thread is running, so we don't know what it's top of stack is and you
> can't a good stack trace in that case.
>
> None of your CPUs are idle, so I don't think you have any sort of deadlock.
> You might have a livelock.
>
> --
> John Baldwin
>
I'm curious if it could be caused by heavy load.
I don't know what it might be definitely,
as it's non-trivial for me to determine the reason
of a livelock, and to debug it.
So I think it may have sense to try 7.x, as there
has been done much locking work.
Thank you.
--
wbr,
pluknet
___
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"
