Re: resource leak
On Wed, 2008-10-01 at 16:36 -0400, Stephen Clark wrote: Robert Watson wrote: On Wed, 1 Oct 2008, Gary Palmer wrote: ps alxw may be of interest in addition to ps auxw as it displays what the processes are waiting on. It could conceivably be a problem of some kind at the filesystem level. I've seen situations before where a problem escalates to the point where ls / hangs, and at that point you're stuck with an unresponsive box. If you want an even greater level of detail than ps -l, you can use procstat -k to generate kernel stack traces for all user/kernel threads. Wait channels are very useful, but they only tell you what the code that invoked the wait thinks it is for, not how that code was reached. A classic example is waiting on an exhausted UMA zone -- you get a uma wait channel, but no indication of what subsystem performed the memory allocation... This required FreeBSD 7.1 and higher, however. (Obviously, the same can be done easily using DDB, but that's hard on a box without a serial console, and requires interrupting the flow of the operating system, compiling with DDB, etc). Robert N M Watson Computer Laboratory University of Cambridge A big part of problem is this seems to take about 100 days of uptime to occur. We have some inhouse test boxes but have never seen the problem, probably because non of them have been up more than about 45 days. The units in the field, of which there is about 300, are headless and none are physically close. When the boxes are rebooted there are no error messages in any of the log files, only the absence of information that would normally be logged by new processes that would be spawned. We are getting ready to install a patch that will try to gather more information. I thought about writing an app the would try to fork a child periodically and record in a log file if there was an error. But EAGAIN is nonspecific as to the real reason the fork failed. I was looking for some way to periodically log the resources that would cause the fork failure. procstat -k looks like it would have been a good candidate but unfortunately we are running 6.1. Thanks for the response. Steve I have a VIA EPIA-based system that was rebooting and not leaving behind any diagnosable evidence that I could find. Attaching a serial console revealed a kernel-trap which was double-faulting as it went to write the kernel dump. I've not yet had the opportunity to investigate further except that out of desperation I threw in an additional 64M of RAM - all I had to hand - adding to its 256M and I haven't seen it fault again in the 37 days since (it would often stay up for less than a day before that). I wonder whether it would be worth your while running a bench unit with limited RAM, either physically or via the hw.physmem tunable. I would probably try to identify the amount of RAM that just allows it to run normally, ideally subjecting it to a typical workload if possible. If it bombs after running for a reasonable length of time, add back a fraction of the unused memory and see if it then stays up proportionally longer which could be indicative of a memory starvation issue. If you can get it to bomb in the above scenario then you can probably get some insight into where it's failing. Having said that, I should point out that I've not actually used the above technique so I may well be overlooking something which might prevent it from being useful or indeed from working at all. Wayne ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Fatal trap 12/TIMEOUT - READ_DMA (was Re: Stuck in geli)
On Tue, 2008-08-05 at 20:30 -0700, Jeremy Chadwick wrote: This looks like the issue I've been tracking for months now. I'm sorry the document isn't complete; it's an issue of time... http://wiki.freebsd.org/JeremyChadwick/ATA_issues_and_troubleshooting My experiences with disk timeouts on FreeBSD is that the OS does not handle it well at all, regardless of geli(4) being used or not. The entire system can deadlock, and in some cases panic (which for me is the more common result). Recently I returned to my desktop system to find it had rebooted itself and found the following: # kgdb /boot/kernel/kernel /var/crash/vmcore.3 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol ps_pglobal_lookup] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd. There is no member named pathname. Error while mapping shared library sections: rtc.ko: No such file or directory. Reading symbols from /boot/kernel/vesa.ko...Reading symbols from /boot/kernel/vesa.ko.symbols...done. done. Loaded symbols for /boot/kernel/vesa.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/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/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.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/green_saver.ko...Reading symbols from /boot/kernel/green_saver.ko.symbols...done. done. Loaded symbols for /boot/kernel/green_saver.ko Error while reading shared library symbols: rtc.ko: No such file or directory. Unread portion of the kernel message buffer: ad1: TIMEOUT - READ_DMA retrying (1 retry left) LBA=67332091 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x188 fault code = supervisor read, page not present instruction pointer = 0x20:0xc075ce24 stack pointer = 0x28:0xe52f1c04 frame pointer = 0x28:0xe52f1c1c 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 = 18 (swi6: task queue) trap number = 12 panic: page fault cpuid = 0 Uptime: 1d11h41m37s Physical memory: 1519 MB Dumping 214 MB: 199 183 167 151 135 119 103 87 71 55 39 23 7 #0 doadump () at pcpu.h:195 195 __asm __volatile(movl %%fs:0,%0 : =r (td)); (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc076a137 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc076a3f9 in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:572 #3 0xc0a71aec in trap_fatal (frame=0xe52f1bc4, eva=392) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc0a71d70 in trap_pfault (frame=0xe52f1bc4, usermode=0, eva=392) at /usr/src/sys/i386/i386/trap.c:812 #5 0xc0a7271c in trap (frame=0xe52f1bc4) at /usr/src/sys/i386/i386/trap.c:490 #6 0xc0a584ab in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc075ce24 in _mtx_lock_sleep (m=0xc5abedcc, tid=3302165152, opts=0, file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:335 #8 0xc07693b6 in _sema_post (sema=0xc5abedcc, file=0x0, line=0) at /usr/src/sys/kern/kern_sema.c:79 #9 0xc050bd30 in ata_completed (context=0xc5abed80, dummy=1) at /usr/src/sys/dev/ata/ata-queue.c:481 #10 0xc079ce85 in taskqueue_run (queue=0xc4d21680) at
Re: Frequent USB mouse disconnections under load with RELENG_7]
Curiouser and curiouser... Synopsis: attaching either or both of two Logitech MX500 mice directly to the (fixed) rear USB ports on this system results in frequent disconnections (disconnect/reconnects) of the mice (ums0/ums1). The frequency of the disconnections apparently increases under increased cpu load. A mouse attached via a second (expansion) pair of USB ports, taken from a header on the motherboard, results in no disconnections for that mouse. Interposing a 4-port USB hub between a mouse and the fixed rear USB ports results in no disconnections for that mouse - with the exception that attaching an FTDI serial adapter to the 4-port hub results in a single disconnection event, but the same symptom is not produced by attaching other assorted USB devices to the hub. Additionally, the disconnection so induced sometimes doesn't include a re-attach event for the mouse (i.e. it remains disconnected until physically detached then reattached). Now the details: After upgrading this system (i386) from RELENG_6 (6.3-PRERELEASE) to RELENG_7 (GENERIC) I started experiencing frequent disconnections with my Logitech USB MX500 mouse. After posting about it on -stable the only idea arrived at was to try removing the extant moused configuration from rc.conf, a remnant from previous configurations. What follows is the outcome of trying that and subsequent investigations. Removing moused_* from rc.conf didn't have any discernible effect other than eliminating the error from moused as seen in /var/log/messages. The disconnects still occur and I've done a little experimentation which has provided some interesting further info. This board (a Gigabyte 8SQ800) has two fixed USB ports on the rear connectors and four additional ports available via a pair of headers, one of which is currently fitted with a rear-panel expansion plate making two more ports accessible for a total of four out of the six supported by the board. kernel: ohci0: SiS 5571 USB controller mem 0xfb001000-0xfb001fff irq 20 at device 3.0 on pci0 kernel: ohci0: [GIANT-LOCKED] kernel: ohci0: [ITHREAD] kernel: usb0: OHCI version 1.0, legacy support kernel: usb0: SiS 5571 USB controller on ohci0 kernel: usb0: USB revision 1.0 kernel: uhub0: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb0 kernel: uhub0: 2 ports with 2 removable, self powered kernel: ohci1: SiS 5571 USB controller mem 0xfb002000-0xfb002fff irq 21 at device 3.1 on pci0 kernel: ohci1: [GIANT-LOCKED] kernel: ohci1: [ITHREAD] kernel: usb1: OHCI version 1.0, legacy support kernel: usb1: SiS 5571 USB controller on ohci1 kernel: usb1: USB revision 1.0 kernel: uhub1: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb1 kernel: uhub1: 2 ports with 2 removable, self powered kernel: ohci2: SiS 5571 USB controller mem 0xfb003000-0xfb003fff irq 22 at device 3.2 on pci0 kernel: ohci2: [GIANT-LOCKED] kernel: ohci2: [ITHREAD] kernel: usb2: OHCI version 1.0, legacy support kernel: usb2: SiS 5571 USB controller on ohci2 kernel: usb2: USB revision 1.0 kernel: uhub2: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb2 kernel: uhub2: 2 ports with 2 removable, self powered kernel: ehci0: EHCI (generic) USB 2.0 controller mem 0xfb004000-0xfb004fff irq 23 at device 3.3 on pci0 kernel: ehci0: [GIANT-LOCKED] kernel: ehci0: [ITHREAD] kernel: usb3: EHCI version 1.0 kernel: usb3: companion controllers, 2 ports each: usb0 usb1 usb2 kernel: usb3: EHCI (generic) USB 2.0 controller on ehci0 kernel: usb3: USB revision 2.0 kernel: uhub3: SiS EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 on usb3 kernel: uhub3: 6 ports with 6 removable, self powered The original MX500 mouse was attached to usb0/port 1. I added a second MX500 mouse (same model, different revision) attached to usb0/port 2. root: Unknown USB device: vendor 0x046d product 0xc025 bus uhub0 kernel: ums0: B16_b_02 USB-PS/2 Optical Mouse, class 0/0, rev 2.00/98.02, addr 2 on uhub0 kernel: ums0: 8 buttons and Z dir. root: Unknown USB device: vendor 0x046d product 0xc025 bus uhub0 kernel: ums1: Logitech USB-PS/2 Optical Mouse, class 0/0, rev 2.00/18.00, addr 3 on uhub0 kernel: ums1: 8 buttons and Z dir. It wasn't long before I experienced disconnections with both mice! kernel: ums1: at uhub0 port 2 (addr 3) disconnected kernel: ums1: detached root: Unknown USB device: vendor 0x046d product 0xc025 bus uhub0 kernel: ums1: Logitech USB-PS/2 Optical Mouse, class 0/0, rev 2.00/18.00, addr 3 on uhub0 kernel: ums1: 8 buttons and Z dir. kernel: ums0: at uhub0 port 1 (addr 2) disconnected kernel: ums0: detached root: Unknown USB device: vendor 0x046d product 0xc025 bus uhub0 kernel: ums0: B16_b_02 USB-PS/2 Optical Mouse, class 0/0, rev 2.00/98.02, addr 2 on uhub0 kernel: ums0: 8 buttons and Z dir. # cat /var/log/messages | grep 'ums0: detached$' | wc -l 63 # cat /var/log/messages | grep 'ums1: detached$' | wc -l 49 I then attached both mice to the expansion USB ports. The disconnections ceased. One of the mice was
Re: Frequent USB mouse disconnections under load with RELENG_7
On Fri, 2008-01-25 at 01:59 +1030, Wayne Sierke wrote: I'm getting a lot of USB mouse disconnects on RELENG_7. I wondered whether they might have been due to running with a KTR-enabled kernel but in just the last 7 hours I've been running on stock GENERIC and they're still happening. I get this set of messages for each disconnect: Jan 24 15:40:13 predator-ii kernel: ums0: at uhub0 port 2 (addr 2) disconnected Jan 24 15:40:13 predator-ii kernel: ums0: detached Jan 24 15:40:14 predator-ii root: Unknown USB device: vendor 0x046d product 0xc025 bus uhub0 Jan 24 15:40:14 predator-ii kernel: ums0: B16_b_02 USB-PS/2 Optical Mouse, class 0/0, rev 2.00/98.02, addr 2 on uhub0 Jan 24 15:40:14 predator-ii kernel: ums0: 8 buttons and Z dir. Rarely, twice that I can recall over the course of a couple of weeks, the mouse fails to reconnect but comes good with a physical disconnect/reconnect. Here's a recent (condensed) history running with stock GENERIC: Jan 24 15:47:04 predator-ii kernel: ums0: at uhub0 port 2 (addr 2) disconnected Jan 24 16:15:53 predator-ii kernel: ums0: at uhub0 port 2 (addr 2) disconnected Jan 24 16:21:46 predator-ii kernel: ums0: at uhub0 port 2 (addr 2) disconnected Jan 24 16:25:42 predator-ii kernel: ums0: at uhub0 port 2 (addr 2) disconnected Jan 24 16:26:17 predator-ii kernel: ums0: at uhub0 port 2 (addr 2) disconnected Jan 24 16:37:01 predator-ii kernel: ums0: at uhub0 port 2 (addr 2) disconnected Jan 24 16:39:22 predator-ii kernel: ums0: at uhub0 port 2 (addr 2) disconnected Jan 24 16:56:28 predator-ii kernel: ums0: at uhub0 port 2 (addr 2) disconnected Jan 24 17:06:36 predator-ii kernel: ums0: at uhub0 port 2 (addr 2) disconnected Jan 24 19:20:58 predator-ii kernel: ums0: at uhub0 port 2 (addr 2) disconnected Jan 24 21:17:30 predator-ii kernel: ums0: at uhub0 port 2 (addr 2) disconnected Sometime during 16:00-17:00 I was running a couple of cpu-intensive tasks (glxgears plus for brief periods a cpu-intensive script). I wasn't at the computer much during the 17:30-21:00 interval. So it seems like this gets exacerbated by high cpu load. I counted another 12 in the hour following on from the above list. I don't recall seeing these at all under RELENG_6. If they ever did occur they certainly weren't anywhere nearly as prolific. A copy of /var/log/messages from boot until the first disconnection is attached. Any ideas? Just a follow-up and bump as I recently realised that the listserver rejected the attachment on the previous message because evolution set its MIME type to text/x-log. Some other information and observations that might help: - the mouse is a wired Logitech MX-500 - it's more prevalent under high cpu load - it happens when the computer is unattended, so it's not tied in with active use of the mouse - I've also just noticed that I'm getting these messages on startup under 7.x: kernel: Starting devd. kernel: Starting ums0 moused: kernel: Starting default moused: moused: unable to open /dev/ums0: Device busy but I can't now recall whether I was seeing those under 6.x. Has devd changed with 7.x? I've got a feeling that I'd tried to get devd in 6.x to handle the USB mouse on startup, but that I'd found it necessary to configure moused explicitly (i.e. with moused_port) in rc.conf as listed below. However my memory of it now is hazy at best. In any case, disconnections aside, I've not noticed any change in mouse behaviour since moving to 7.x either in console or xorg. moused_enable=YES moused_port=/dev/ums0 I'm getting quite anxious for some pointers to resolving this as it's both highly annoying and is also frustrating my efforts in pursuing some of the other performance problems I've written about. Wayne kernel boot file is /boot/kernelktr0x2000/kernel Copyright (c) 1992-2008 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.0-PRERELEASE #1: Fri Jan 25 01:08:47 CST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC-KTR-0x2000 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2411.61-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf27 Stepping = 7 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x4400CNXT-ID,xTPR real memory = 1610547200 (1535 MB) avail memory = 1551495168 (1479 MB) ACPI APIC Table: GBTAWRDACPI ioapic0: Changing APIC ID to 2 ioapic0 Version 1.4 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) hptrr: HPT RocketRAID controller driver v1.1 (Jan 25 2008 01:08:23) acpi0: GBT AWRDACPI on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed
Re: Frequent USB mouse disconnections under load with RELENG_7
On Fri, 2008-02-01 at 07:17 -0800, Jeremy Chadwick wrote: On Fri, Feb 01, 2008 at 10:00:11PM +1030, Wayne Sierke wrote: - I've also just noticed that I'm getting these messages on startup under 7.x: kernel: Starting devd. kernel: Starting ums0 moused: kernel: Starting default moused: moused: unable to open /dev/ums0: Device busy but I can't now recall whether I was seeing those under 6.x. Has devd changed with 7.x? I've got a feeling that I'd tried to get devd in 6.x to handle the USB mouse on startup, but that I'd found it necessary to configure moused explicitly (i.e. with moused_port) in rc.conf as listed below. However my memory of it now is hazy at best. In any case, disconnections aside, I've not noticed any change in mouse behaviour since moving to 7.x either in console or xorg. moused_enable=YES moused_port=/dev/ums0 I think this is what's happening here: * kernel starts * usb stack loads, finds a USB mouse, attaches it to ums0 * attachment tells devd hey, theres a /dev/ums0 device that just attached * /etc/devd.conf automatically spawns moused, which attaches to the /dev/ums0 device * rc scripts begin * moused_enable=yes is detected, thus moused is run manually against /dev/ums0 * moused is already running from when devd spawned it, which is why /dev/ums0 is Device busy I would recommend removing the moused_* stuff in your rc.conf and let devd take care of it, or, consider editing /etc/devd.conf and removing the /dev/umsX detection which runs moused. Yes, well that's what I figured, but over the years getting the USB mouse to work with X has required manual configuration and I don't recall ever having any kind of automatic devd-style detection work previously. The handbook only appears to deal with setting up a mouse via sysinstall and it isn't apparent to me from the text what configuration settings would be made when installing a USB mouse. However this current behaviour looks encouraging so I shall give it a whirl and we'll see whether removing the manual moused config from rc.conf eliminates these disconnections. Wayne ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Frequent USB mouse disconnections under load with RELENG_7
On Fri, 2008-02-01 at 12:26 -0700, Joe Peterson wrote: Wayne Sierke wrote: On Fri, 2008-01-25 at 01:59 +1030, Wayne Sierke wrote: I'm getting a lot of USB mouse disconnects on RELENG_7. I wondered whether they might have been due to running with a KTR-enabled kernel but in just the last 7 hours I've been running on stock GENERIC and they're still happening. Hey Wayne, I'm not sure if you associating the disconnects with the jerky mouse behavior, but as an added datapoint, I have a PS/2 mouse, I see *no* disconnects in the system logs (well, it's PS/2...), and I still get the jerky mouse... Hi Joe, I've found the disconnects to be quite easily distinguishable from general mouse jerkiness as instances of the former are quite long, in the order of 2 seconds or so and also such a complete disabling compared to the shorter impairment of mouse cursor movement I experience during the latter. I have also at times set up a small terminal window tailing /var/log/messages so that I could monitor the disconnect messages in real time. I hold no doubts at all about being able to recognise when one of these disconnections occurs. Out of interest I just examined the messages written when I manually disconnect the mouse and they're identical to what's written during one of these events. As per my other message to Jeremy I'll see what transpires after I remove my moused configuration from /etc/rc.conf. Wayne ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Frequent USB mouse disconnections under load with RELENG_7
I'm getting a lot of USB mouse disconnects on RELENG_7. I wondered whether they might have been due to running with a KTR-enabled kernel but in just the last 7 hours I've been running on stock GENERIC and they're still happening. I get this set of messages for each disconnect: Jan 24 15:40:13 predator-ii kernel: ums0: at uhub0 port 2 (addr 2) disconnected Jan 24 15:40:13 predator-ii kernel: ums0: detached Jan 24 15:40:14 predator-ii root: Unknown USB device: vendor 0x046d product 0xc025 bus uhub0 Jan 24 15:40:14 predator-ii kernel: ums0: B16_b_02 USB-PS/2 Optical Mouse, class 0/0, rev 2.00/98.02, addr 2 on uhub0 Jan 24 15:40:14 predator-ii kernel: ums0: 8 buttons and Z dir. Rarely, twice that I can recall over the course of a couple of weeks, the mouse fails to reconnect but comes good with a physical disconnect/reconnect. Here's a recent (condensed) history running with stock GENERIC: Jan 24 15:47:04 predator-ii kernel: ums0: at uhub0 port 2 (addr 2) disconnected Jan 24 16:15:53 predator-ii kernel: ums0: at uhub0 port 2 (addr 2) disconnected Jan 24 16:21:46 predator-ii kernel: ums0: at uhub0 port 2 (addr 2) disconnected Jan 24 16:25:42 predator-ii kernel: ums0: at uhub0 port 2 (addr 2) disconnected Jan 24 16:26:17 predator-ii kernel: ums0: at uhub0 port 2 (addr 2) disconnected Jan 24 16:37:01 predator-ii kernel: ums0: at uhub0 port 2 (addr 2) disconnected Jan 24 16:39:22 predator-ii kernel: ums0: at uhub0 port 2 (addr 2) disconnected Jan 24 16:56:28 predator-ii kernel: ums0: at uhub0 port 2 (addr 2) disconnected Jan 24 17:06:36 predator-ii kernel: ums0: at uhub0 port 2 (addr 2) disconnected Jan 24 19:20:58 predator-ii kernel: ums0: at uhub0 port 2 (addr 2) disconnected Jan 24 21:17:30 predator-ii kernel: ums0: at uhub0 port 2 (addr 2) disconnected Sometime during 16:00-17:00 I was running a couple of cpu-intensive tasks (glxgears plus for brief periods a cpu-intensive script). I wasn't at the computer much during the 17:30-21:00 interval. So it seems like this gets exacerbated by high cpu load. I counted another 12 in the hour following on from the above list. I don't recall seeing these at all under RELENG_6. If they ever did occur they certainly weren't anywhere nearly as prolific. A copy of /var/log/messages from boot until the first disconnection is attached. Any ideas? Wayne ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ktrdumps for masochists (a dump with KTR_ENTRIES=524288)
In an attempt to obtain a ktrdump from one of these lengthy (1-2s) freezes I'm seeing when moving an active window running glxgears, I configured a kernel with a 512k ktr buffer size. I still couldn't catch any significant part of the event because of the high rate of context-switching with glxgears running, and the problem of stopping the logging quickly after cessation of the event. The dump contains less than 300ms of events. It required nearly 700MB of memory to open with schedgraph.py. Which took over 10 minutes to load on this 2.4GHz P4 (no swapping). I thought I'd make it available in case someone had a use for it... http://au.dyndns.ws/public/ktr-sched_move-glxgears-200801250033.out.bz2 Wayne ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.0-PRERELEASE desktop system periodically freezes momentarily
Doh! Now that I'm no longer using the 8 month old version of schedgraph.py that was displaying interesting but useless graphs, perhaps I won't continue to appear as though I'm raving like such a lunatic about what is contained in my ktr captures. Here follows a re-examination of the previously posted data with a recent schedgraph.py. Note that lacking any particular knowledge I'm only guessing at what might be significant. http://au.dyndns.ws/public/ktr-sched_gnome-netmonitor.out.bz2 (Stutter in glxgears with gnome metwork monitor) glxgears in runq for 236ms http://au.dyndns.ws/public/ktr-sched_move-glxgears_1.out.bz2 http://au.dyndns.ws/public/ktr-sched_move-glxgears_2.out.bz2 Nothing significant is apparent. http://au.dyndns.ws/public/ktr-sched_move-glxgears_3.out.bz2 (Dragging glxgears window which freezes - stops following mouse and stops updating, desktop doesn't respond to keyboard/mouse-clicks for the duration) glxgears in runq for 278ms and almost immediately again for 381ms. Note that this doesn't capture the entire period of interest which can be 1-2 seconds, due to the high number of context switches occurring with glxgears running and the difficulty of stopping the logging quickly after the event. I'll need a much larger (than 128k) buffer to catch an event in its entirety, unless someone can suggest a way to reduce the number of context switches significantly? http://au.dyndns.ws/public/ktr-sched-200801192346.out.bz2 Looks like this was probably just a mouse disconnect/reconnect - there is approx 1s of inactivity in irq20/ohci0 towards the end. Unfortunately these disconnects occur very frequently (typically multiple times per hour) since running with the KTR-enabled kernel (afaict). Unfortunately it looks as though that after gaining a false impression from this capture with the old schedgraph.py, I subsequently mis-interpreted numerous mouse disconnects as desktop freeze events. http://au.dyndns.ws/public/ktr-sched-200801200336.out.bz2 Looks like just another mouse disconnect. http://au.dyndns.ws/public/ktr-sched-200801200302.out.bz2 http://au.dyndns.ws/public/ktr-sched-200801210207.out.bz2 Nothing interesting is apparent. So it seems the only thing of interest that Ive managed to capture so far pertains to glxgears - an instance of the stutter and a part of a short freeze when dragging its window. Unfortunately these frequent mouse disconnects make it difficult to recognise genuine freezes during 'normal' use, if indeed they are still occurring with RELENG_7. However the glxgears behaviour remains (apparently) the same as it was on RELENG_6. Whether that's a telling sign or not remains to be seen. Wayne ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.0-PRERELEASE desktop system periodically freezes momentarily
Kris, Latest captures (of interest) - they're not hard to come by, it seems. I see more than a couple of these every hour at least while I'm actively doing anything on this system, and I've witnessed up to two or three times that many at times. It seems my initial glee about catching Epiphany out was unfounded. Each capture has successively shown a different process/thread with the long exclusive cpu use, and the first one I've linked to here doesn't even show any active 'running' processes for the period in question, it has evolution and xorg 'yielding' and irq14 in 'runq'. The second one shows 'xorg' with exclusive 'running' for the duration. So it's proving quite variable, and after examining more than a handful of these I'm surmising that the 'freeze' is interfering with ktr logging somehow, resulting in the loss of one or more data points and resulting in the anomalous graphs as I mentioned in my previous message. I won't strive to take any more of these for now unless you indicate that you believe it could be useful. If I happen to catch any that look of particular interest I'll post them up and send links. In the meantime I'll revert to a standard GENERIC kernel, too, to gauge how much effect running with this KTR-enabled kernel on the frequency of these events, and the mouse disconnects. I'm keen to hear your take on what you think might be going on here. http://au.dyndns.ws/public/ktr-sched-200801200302.out.bz2 http://au.dyndns.ws/public/ktr-sched-200801210207.out.bz2 Wayne ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.0-PRERELEASE desktop system periodically freezes momentarily
Kris, I caught this one during what I'd class as normal usage, with a handful of apps open, and no glxgears or other glx apps (intentionally) running. It shows Epiphany getting cpu solidly for 2 seconds! If you crank up the ticks per pixel and scroll to the end you can't miss it. This typifies an event that occurs regularly for me in my normal desktop use, albeit I normally use firefox with a large number of windows and tabs open. I'd long suspected that firefox might be involved in some of the pauses I've been experiencing. I'm quite chuffed about getting this one. http://au.dyndns.ws/public/ktr-sched-200801192346.out.bz2 Wayne ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.0-PRERELEASE desktop system periodically freezes momentarily
Kris, Another one, this time xorg for 2 seconds, approximately in the middle. I'm feeling inclined to doubt the validity of this and the previous data set, however. Looking at the tail end of each of the events in question, there is clearly activity on other processes before the supposedly long exclusive cpu event terminates. Unless this is some limitation of the schedgraph.py script, or the ktr logging mechanism, etc., then this must surely indicate that they are not valid captures? I am all the more inclined to question them because the very next capture/dump I did after the previous set was captured looked so similar to it that I felt prompted to do a diff between the files and found that they contained identical lines for the most part, with only approx every nth line being different (for n=about 4 or so - I don't recall exactly and unfortunately didn't keep that particular one). Is it sufficient to just set debug.ktr.mask to resume capturing, or is it necessary to set debug.ktr.clear? (Note that so far there has always a substantial time interval between setting the mask and clearing it again, at least some minutes and usually much more, so I've assumed that there's plenty of logging occurring to over-write the previous contents). I should also have mentioned that I'm getting these messages periodically: ums0: at uhub0 port 2 (addr 2) disconnected ums0: detached ums0: B16_b_02 USB-PS/2 Optical Mouse, class 0/0, rev 2.00/98.02, addr 2 on uhub0 ums0: 8 buttons and Z dir. which for the moment I'm assuming are related to running the KTR-enabled kernel as I can't recall seeing these previously. http://au.dyndns.ws/public/ktr-sched-200801200336.out.bz2 Wayne ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.0-PRERELEASE desktop system periodically freezes momentarily
On Thu, 2008-01-17 at 20:50 +0100, Kris Kennaway wrote: Wayne Sierke wrote: On Mon, 2008-01-14 at 21:06 +0100, Kris Kennaway wrote: Same deal as before then. It cannot be the same problem as in the previous 6.x trace (unless you are using a non-mpsafe filesystem, i.e. not UFS). Kris In fact I have some MSDOSFS auto-mounting from /etc/fstab, but normally not in active use (by me - as for what gnome-* are doing in the background?). Without those mounts the stuttering in glxgears when 'Harddisk' is enabled in System Monitor is barely perceptible. The stuttering with Network Monitor remains as do the other freezes. I didn't have the same luck getting nvidia-driver working with LOCK_PROFILING in RELENG_7 as I did with MUTEX_PROFILING in RELENG_6. Looks like I'll have to test with nv or vesa driver instead, now. I've also prepared a KTR testing kernel but in the process realise I don't know which trace classes to include? KTR_SCHED Kris Ah, yes. Thanks. I've finally latched on to the whole schedgraph concept. Links to logs below. ktr-sched_gnome-netmonitor.out is just the 2Hz stutter in glxgears with the gnome Network Monitor applet active. I believe I've caught an instance of one stutter. ktr-sched_move-glxgears_1.out is a first attempt to catch the freeze that occurs when moving the glxgears window. Because of the freeze it's difficult to stop the recording promptly. It appears that all keyboard and mouse input (other than movement) is either ignored or discarded during the freeze[1]. Consequently, I have to wait until the system unfreezes before clicking over the terminal window to activate it and then pressing enter to run the waiting 'debug.ktr.mask=0' command. ktr-sched_move-glxgears_2.out is a second attempt. ktr-sched_move-glxgears_3.out was conducted by running the command: sleep 2; sysctl debug.ktr.mask=0 then waiting about 1.5 seconds, then dragging the glxgears window in an attempt to have the freeze active at the end of recording. What's a sensible upper limit for KTR_ENTRIES? Wayne [1] With the very curious exception that when the freeze occurs due to an alt-tab window-switching action, mouse and keyboard *do* get buffered - if I continue hitting alt-tab after the system freezes, those alt-tabs get played out when the system unfreezes. Similarly if I click over a window while the system is frozen during alt-tab, that mouse click gets played as normal when the system unfreezes. Odd. http://au.dyndns.ws/public/ktr-sched_gnome-netmonitor.out.bz2 http://au.dyndns.ws/public/ktr-sched_move-glxgears_1.out.bz2 http://au.dyndns.ws/public/ktr-sched_move-glxgears_2.out.bz2 http://au.dyndns.ws/public/ktr-sched_move-glxgears_3.out.bz2 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.0-PRERELEASE desktop system periodically freezes momentarily
On Mon, 2008-01-14 at 21:06 +0100, Kris Kennaway wrote: Same deal as before then. It cannot be the same problem as in the previous 6.x trace (unless you are using a non-mpsafe filesystem, i.e. not UFS). Kris In fact I have some MSDOSFS auto-mounting from /etc/fstab, but normally not in active use (by me - as for what gnome-* are doing in the background?). Without those mounts the stuttering in glxgears when 'Harddisk' is enabled in System Monitor is barely perceptible. The stuttering with Network Monitor remains as do the other freezes. I didn't have the same luck getting nvidia-driver working with LOCK_PROFILING in RELENG_7 as I did with MUTEX_PROFILING in RELENG_6. Looks like I'll have to test with nv or vesa driver instead, now. I've also prepared a KTR testing kernel but in the process realise I don't know which trace classes to include? Wayne ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.0-PRERELEASE desktop system periodically freezes momentarily
On Sun, 2008-01-13 at 21:09 +0100, Kris Kennaway wrote: Yeah, this shows things like contention between the mouse device and other parts of the kernel that still require the Giant lock in 6.x. It is not likely that these will be fixed in 6.x but most of them are in 7.0, so you should obtain better performance by upgrading to 7.0. Kris This system is now: FreeBSD 7.0-PRERELEASE #0: Mon Jan 14 17:40:02 CST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 I haven't touched ports yet apart from nvidia-driver- and adding compat6x. I haven't done any extensive testing as yet but repeating what I was doing previously as a 'litmus test' - launch gnome, open a terminal, launch glxgears, (1) drag glxgears window, (2) add gnome 'Network Monitor' applet, (3) add 'System Monitor' applet with 'Harddisk' enabled as a 'Monitored Resource'. So far I'm seeing what seems to be identical behaviour: (1) Huge lag when I commence dragging glxgears window, typ. 1-2 seconds (2) glxgears stutters at 2Hz matching update rate of applet (3) ditto (1) manifests in two ways - window drags but glxgears freezes, and, more severely, window freezes where it is (stops both updating and following cursor). So far while launching/using evolution, epiphany, etc. I see stalls that look pretty similar to 6.x behaviour. Just thought I'd check in in case there are any suggestions at this point. If not I'll proceed with recompiling ports and preparing test kernels. Wayne ___ 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-PRERELEASE desktop system periodically freezes momentarily
On Sun, 2008-01-13 at 12:39 +0100, Kris Kennaway wrote: MUTEX_PROFILING changes the kernel ABI so modules that are not compiled with that option will not work. If you use make buildkernel to build your kernel + modules together then it uses the kernel config file for both so they are compatible, otherwise your modules only are built with default options. So, if you have any other modules apart from nvidia then use make buildkernel for those, and add -DMUTEX_PROFILING to the CFLAGS of the nvidia build and try that. It may still not be enough since nvidia is a wrapper around a binary module, so you may also need to revert to nv. Kris Kris, I added CFLAGS+= -DMUTEX_PROFILING to /usr/ports/x11/nvidia-driver-96xx/Makefile and re-built, was able to load the resulting nvidia.ko and launch gnome. I've taken a number of different log samples which I'll send separately. Wayne ___ 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-PRERELEASE desktop system periodically freezes momentarily
On Thu, 2008-01-10 at 21:27 +0100, Kris Kennaway wrote: Toomas Aas wrote: Kris Kennaway wrote: OK. Can you obtain a lock profiling dump? I'm trying, but not succeeding so far. I added the following to the kernel config: options MUTEX_PROFILING options MPROF_BUFFERS=1536 options MPROF_HASH_SIZE=1543 And set debug.mutex.prof.enable=1 However, kgmon says that profiling is not enabled in the kernel. Am I missing something essential or barking under completely wrong tree? Yes :) kgmon has nothing to do with mutex profiling, so remove the MPROF_*. sysctl debug.mutex.prof.enable=1 ... trigger hang ... sysctl debug.mutex.prof.enable=0 and send me the output of sysctl debug.mutex.prof.stats Kris I added options MUTEX_PROFILING and options HWPMC_HOOKS but the system hangs when going multi-user after printing: Entropy harvesting: interrupts ethernet point_to_point. ^t shows it stuck in dd, ^c brings out to sysctl [null] but I can't get past that and am forced to reset. I tried rebooting without loading modules which gets around that but then I can't get xorg to start even after loading nvidia.ko. I've seen the comment in the NOTES section in MUTEX_PROFILING re modules, does it mean that I won't be able to use nvidia.ko with this test kernel? If so perhaps someone could comment on how best to proceed re gathering test results? i.e. would it be better to just use 'nv' or 'vesa' driver for now and get mutex stats? Or forgo that and keep 'nvidia' and just use hwpmc, etc. I've found that the ~2Hz stuttering that I'm seeing in glxgears results from having the gnome 'Network Monitor' applet which updates at about 2Hz. Upon removing that applet from my desktop the stuttering ceases. I also have the 'System Monitor' applet loaded which updates at the same rate and creates a similar effect if I include 'Harddisk' as a monitored resource. Without 'Harddisk' even having all of 'Processor', Memory', 'Network', 'Swap Space' and 'Load' enabled has no discernible effect. I still see a multitude of lengthy pauses at random intervals without these applets loaded, however, and this session hasn't touched any swap yet. Wayne ___ 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-PRERELEASE desktop system periodically freezes momentarily
On Sun, 2008-01-13 at 03:24 +1030, Wayne Sierke wrote: I added options MUTEX_PROFILING and options HWPMC_HOOKS but the system hangs when going multi-user after printing: Entropy harvesting: interrupts ethernet point_to_point. ^t shows it stuck in dd, ^c brings out to sysctl [null] but I can't get past that and am forced to reset. I tried rebooting without loading modules which gets around that but then I can't get xorg to start even after loading nvidia.ko. I've seen the comment in the NOTES section in MUTEX_PROFILING re modules, does it mean that I won't be able to use nvidia.ko with this test kernel? If so perhaps someone could comment on how best to proceed re gathering test results? i.e. would it be better to just use 'nv' or 'vesa' driver for now and get mutex stats? Or forgo that and keep 'nvidia' and just use hwpmc, etc. Someone replied privately and evidently I didn't make some things clear about what I did/tried. After changing the kernel config, I used appropriate incarnations of 'make buildkernel KERNCONF=' and 'make installkernel KERNCONF= KODIR=' and used 'nextboot -k'. I also tried rebuilding nvidia.ko (including when booted under the profiling kernel) but not surprisingly the resulting file was identical to the original. I've just booted into a kernel with options HWPMC_HOOKS so I'll grab some results here. Meanwhile I'll prepare a kernel with just options MUTEX_PROFILING and if I haven't heard anything different in the meantime, I'll set about checking that out without nvidia.ko. Wayne ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
6.3-PRERELEASE desktop system periodically freezes momentarily
FreeBSD 6.3-PRERELEASE #5: Sat Dec 29 19:25:43 CST 2007 i386 I've noticed that this system is freezing periodically, for anywhere from around a fraction of a second up to perhaps 1.5 seconds, and occurring on average about twice a minute, but with no particular pattern - i.e. it could happen twice in fairly quick succession, or not for 40-50 seconds. By running glxgears the problem is easily witnessed, also by maintaining the mouse in constant motion, and it was originally noticed during normal use when, e.g. the system momentarily becomes unresponsive to keyboard input. I've now also witnessed it by running top with a delay setting of zero and displaying system processes. The shorter delays are not easily spotted but the longer delays are. This was seen both in a terminal session and at a console. Using top also revealed another interesting phenomenon - the 'top' display freezes for very brief periods, probably less than 0.1s, but quite regularly, at around once per second. Seeing this prompted me to realise that glxgears stutters in what appears to be a corresponding way. This behaviour (the freezing itself) is not entirely consistent, either. Just while I've been writing these paragraphs I've noticed glxgears' behaviour range from stuttering at around once per second, to around twice per second, to not doing it (perceptibly) at all. I now realise that I've actually witnessed this behaviour in glxgears for quite some time, extending back into the distant history of this system, which may include 6.0-RELEASE but would certainly include a few different revisions in the 6.x series. It has been always source-upgraded since the original install. I'd always just thought that it was some hiccough in the graphics system. Ports were recently upgraded so it is now running xorg-7.3_1, gnome-2.20.2, nvidia-driver-96.43.01. The system has been up for 5 days now and is quite loaded up with applications at the moment and is normally left running. Currently it has running (on gnome): evolution, firefox-devel (with some dozens of windows and tabs open), xmms, gimp, xchat, eclipse-devel, gedit, a handful of terminal sessions. It's running a custom kernel - mainly raid and unused network drivers removed - mods listed below. The hardware is a Gigabyte GA-8SQ800 motherboard (SiS), with a 2.4GHz P4, 1.5GB DDR, nVidia MX440 AGP graphics, RTL-8139 network, AHA-2940 SCSI controller (for a scanner), 2 x 80GB ATA disks. This system has also had a tendency at times to crash when switching VTs between console and xorg. This problem has varied in consistency with the different incarnations of OS and nvidia-driver versions and hasn't yet occurred with this latest update. I'd really appreciate any suggestions to help identify what's going on here. Thanks, Wayne diff of kernel config with GENERIC: -# cpu I486_CPU -# cpu I586_CPU -# device eisa -# device ataraid # ATA RAID drives -# device atapifd # ATAPI floppy drives -# device amr # AMI MegaRAID -# device arcmsr # Areca SATA II RAID -# device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID -# device ciss# Compaq Smart RAID 5* -# device dpt # DPT Smartcache III, IV - See NOTES for options -# device hptmv # Highpoint RocketRAID 182x -# device hptrr # Highpoint RocketRAID 17xx, 22xx, 23xx, 25xx -# device rr232x # Highpoint RocketRAID 232x -# device iir # Intel Integrated RAID -# device ips # IBM (Adaptec) ServeRAID -# device mly # Mylex AcceleRAID/eXtremeRAID -# device twa # 3ware 9000 series PATA/SATA RAID -# device aac # Adaptec FSA RAID -# device aacp# SCSI passthrough for aac (requires CAM) -# device ida # Compaq Smart RAID -# device mfi # LSI MegaRAID SAS -# device mlx # Mylex DAC960 family -# device pst # Promise Supertrak SX6000 -# device twe # 3ware ATA RAID -# device plip# TCP/IP over parallel -# device cs # Crystal Semiconductor CS89x0 NIC -# device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards -# device ex # Intel EtherExpress Pro/10 and Pro/10+ -# device ep # Etherlink III based cards -# device fe # Fujitsu MB8696x based cards -# device ie # EtherExpress 8/16, 3C507, StarLAN 10 etc. -# device lnc # NE2100, NE32-VL Lance Ethernet cards -# device sn # SMC's 9000 series of
Re: Missing pkg-descr
On Wed, 2006-12-13 at 12:27 -0600, Wayne M. Barnes wrote: Dear FreeBSD, Did something happen to the location for the pkg-descr so that ports can't find it? The following happens to me a lot, for many packages: === Installing for gmake-3.81_1 === Generating temporary packing list ** Missing pkg-descr for gmake-3.81_1. *** Error code 1 Stop in /usr/ports/devel/gmake. *** Error code 1 Stop in /usr/ports/x11-toolkits/open-motif. *** Error code 1 A workaround is to add this package with pkg_add -rv, but this is tiresome, since I must do it many times to finish a complicated port (this time the port is java/jdk15). This happened on a new install of FreeBSD poweredge.etaq.com 6.2-RC1 FreeBSD 6.2-RC1 #0: Thu Nov 16 05:12:08 UTC 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP i386 %ll /usr/ports/devel/gmake/pkg-descr -rw-r--r-- 1 root wheel 215 May 18 2000 /usr/ports/devel/gmake/pkg-descr If the file doesn't exist, is there anything unusual re the maintenance of the ports tree on that system? Perhaps old files were pruned, etc.? Refreshing the ports tree ought to fix it. Wayne P.S. This probably ought to have gone to ports@ or [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: Drives always come up dirty after shutdown on 6.2-PRERELEASE.
On Sun, 2006-10-01 at 02:45 -0700, Jeremy Chadwick wrote: On Sun, Oct 01, 2006 at 02:17:17PM +0930, Wayne Sierke wrote: If you run fsck (fsck -n is sufficient) without specifying a file system so that it reads the list of which file systems to check from fstab, does it check all those with a non-zero Pass#? Taken from fstab(5) manpage: The sixth field, (fs_passno), is used by the fsck(8) program to determine the order in which file system checks are done at reboot time. The root file system should be specified with a fs_passno of 1, and other file systems should have a fs_passno of 2. File systems within a drive will be checked sequentially, but file systems on different drives will be checked at the same time to utilize parallelism available in the hard- ware. If the sixth field is not present or is zero, a value of zero is returned and fsck(8) will assume that the file system does not need to be checked. Yes. However, I wasn't inquiring about the behaviour of fsck, I was asking the OP whether fsck exhibits the correct behaviour when run in that fahion, i.e. without specifying any filesystems. My intent was for the OP to verify both that the correct settings are present in /etc/fstab, and that the settings are being read correctly. Evidently I didn't structure my query very well. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Drives always come up dirty after shutdown on 6.2-PRERELEASE.
On Fri, 2006-09-29 at 15:58 +0100, Josef Karthauser wrote: On Fri, Sep 29, 2006 at 09:44:07AM -0500, Brooks Davis wrote: On my laptop running 6.2-PRERELEASE the drives always mount dirty, which suggests that they are not being shutdown clean; however the machine always syncs the disks and switches itself off after a 'shutdown -p now', and so I'm not sure what it could be. Has anyone else seen this? I haven't seen any other reports of this. Have you tried running a fsck -f on the drives? It's possible there's a latent error that isn't being fixed by bgfsck. I thought I did; I'll try again now and see what happens. It's strange though because it's every partition. The /var partition on this 6.1-STABLE box was always mounting dirty, until I realised that its fstab entry had its Pass# field set to 0: /dev/ad0s4e /varufs rw 0 0 If you run fsck (fsck -n is sufficient) without specifying a file system so that it reads the list of which file systems to check from fstab, does it check all those with a non-zero Pass#? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
On Fri, 2006-09-15 at 02:09 +0200, Karol Kwiatkowski wrote: On 15/09/2006 01:37, Benjamin Lutz wrote: On Friday 15 September 2006 01:15, Kris Kennaway wrote: Anyone who is confused but doesn't attempt to enlighten themselves by reading the provided documentation deserves to stay confused :) What if they're unaware of their own confusion? I guess they get what they deserves ;) Is there a be better source of enlightenment than a handbook? To quote[1]: --% 21.2.2.1 What Is FreeBSD-STABLE? FreeBSD-STABLE is our development branch from which major releases are made. Changes go into this branch at a different pace, and with the general assumption that they have first gone into FreeBSD-CURRENT for testing. This is still a development branch, however, and this means that at any given time, the sources for FreeBSD-STABLE may or may not be suitable for any particular purpose. It is simply another engineering development track, not a resource for end-users. --% Perhaps the flow of FAQs and confusion resulting from the misnomer might be stemmed somewhat if something like the following were appended to that: Note that -STABLE refers to the stability of the FreeBSD API, not to the run-time stability of the branch. The FreeBSD API (normally?) only changes across major version releases. Someone with a more intimate understanding of how it all works could probably write a better version of that. I suspect that the confusion for new users isn't helped by the following statement from the 'version-guide' article: 1.3 STABLE versus CURRENT During the lifetime of each major release, an individual branch may also be termed STABLE. This indicates that the FreeBSD Project believes that the branch is of sufficiently proven quality to be used by a wide range of users. Branches that need further testing before being widely adopted are named CURRENT. The crux of the confusion is exemplified here by the terms wide range of users and widely adopted used in reference to the suggested target audiences for STABLE and CURRENT, respectively. While the explanations themselves are not specifically inaccurate, they are easily misinterpreted or, rather, difficult to interpret correctly, for a new user trying to understand it all. It simply reflects the confusion caused by the use of the STABLE tag. All-in-all, I think Marc G. Fournier had the best suggestion: Or rename it what it is: 6.x-BETA Where x == the next -RELEASE ... Which has at least the following benefits: 1. highlights that the software is BETA (and thus in need of testing - in both senses) 2. shows that the software is version n+1 (n == existing -RELEASE) 3. avoids the confusion of the -STABLE tag (both for new, and - dare I say - existing, users) Wayne ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: xorg build failed
On Sun, 2006-06-04 at 21:29 +1200, Kaiwai Gardiner wrote: One would ask as to why xorg has failed to compile, and it appears no one else here has experienced the same issue; hence the reason I suggested a clean removal of installed ports and a vanilla compile of it. I've updated my ports from the cvs, and haven't experienced an xorg compilation issue - I compile from the standard /usr/ports/x11/xorg location, and I don't see to suffer the same issues - co-incidence or simply being boring with the locating of things has saved me from compilation problems? Matty If the OP's problem is merely a result of using WRKDIRPREFIX then something is buggy and needs attention. As mentioned in man ports, it can be useful if /usr/ports is on a read-only filesystem, e.g. cdrom. Another reason, for which I've used it, is if there is insufficient free space for the temporary work files in /usr/ports. Perhaps a more useful comment would by why you think /var/tmp could be a weird, or rather a problematic, location? For the OP: Is there anything significant about your /var/tmp? (Does it have enough free space? Is it mounted noexec, etc.?) Wayne ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
