Re: MAKEDEV(8) manpage
On Mon, Mar 24, 2003 at 09:43:17PM +0200, Giorgos Keramidas wrote: On 2003-03-24 19:14, Christian Brueffer [EMAIL PROTECTED] wrote: I'll write a small manpage this evening which says that MAKEDEV is gone now with a short summary of what devfs does. Does that resolve your worries? If you write a detailed description of devfs please add it to devfs(5) and just replace the existing manpage of MAKEDEV with something like: The MAKEDEV script was deprecated by devfs(5) and geom(4) and removed from FreeBSD after GEOM became mandatory. Please see the devfs(5), devfs(8), geom(4) and mount_devfs(8) manpages for more details. This should be enough IMHO to point the reader to the right place. - Giorgos That was my original intent. I'm still uncertain if it would be better to write a small manpage or just create a MLINK to one of the devfs pages... - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgp0.pgp Description: PGP signature
subscribe
subscribe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: playing mp3s and burning a cd
On Mon, Mar 24, 2003 at 11:18:59PM +0100, Julian St. [EMAIL PROTECTED] wrote: Am Mo, 2003-03-24 um 20.33 schrieb Vallo Kallaste: Current isn't better. This is a long time problem and is most noticeable when you downgrade from -current to -stable... it's unforgettable feeling :-P I don't expect it will be fixed in the near future, because it's been so over a year now. Current has it's weak points and this is only one of the regressions. I remember having this problem on 5.0-RELEASE, but it was completely gone once I upgraded to -CURRENT (late february I think). Perhaps it could be interesting to know if this problem is connected to certain hardware components. (Athlon XP 2400+ (2008 MHZ), SiS board, realtek 8139B network, SB Live!, nVidia TNT2U, UDMA100 WD harddisk) Besides: my CDROM drive is working properly using PIO and UDMA33. Sorry I wasn't clear that my particular problem is related to network I/O. Mouse movement is jerky on sound skips while doing ftp transfer over 100Mbit interface. SMP system with two 500Mhz PIII, SCSI all over, fxp interface(s) and netgraph based bridge running. Physical media is crossover cable. Can't say anything about ATA(PI) I/O, but I will be installing just arrived ATAPI CD-RW/DVD drive today, so we'll see.. -- Vallo Kallaste To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- === lib/libatm cc1: warnings being treated as errors /tinderbox/sparc64/src/lib/libatm/ioctl_subr.c: In function `get_vcc_info': /tinderbox/sparc64/src/lib/libatm/ioctl_subr.c:175: warning: cast increases required alignment of target type /tinderbox/sparc64/src/lib/libatm/ioctl_subr.c: In function `get_subnet_mask': /tinderbox/sparc64/src/lib/libatm/ioctl_subr.c:229: warning: cast increases required alignment of target type /tinderbox/sparc64/src/lib/libatm/ioctl_subr.c: In function `get_cfg_info': /tinderbox/sparc64/src/lib/libatm/ioctl_subr.c:395: warning: cast increases required alignment of target type /tinderbox/sparc64/src/lib/libatm/ioctl_subr.c: In function `get_intf_info': /tinderbox/sparc64/src/lib/libatm/ioctl_subr.c:433: warning: cast increases required alignment of target type *** Error code 1 Stop in /tinderbox/sparc64/src/lib/libatm. *** Error code 1 Stop in /tinderbox/sparc64/src/lib. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
world@alpha børken in libatm
cc -pg -O -pipe -mcpu=ev4 -mtune=ev5 -Werror -Wall -Wno-format-y2k -W -Wstrict-p rototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite -strings -Wswitch -Wshadow -Wcast-align -Wuninitialized -c /bang/src/lib/libatm /ip_checksum.c -o ip_checksum.po cc1: warnings being treated as errors *** Error code 1 /bang/src/lib/libatm/ip_checksum.c: In function `ip_checksum': /bang/src/lib/libatm/ip_checksum.c:80: warning: cast increases required alignmen t of target type *** Error code 1 *** Error code 1 *** Error code 1 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: several background fsck panics
Thus spake Terry Lambert ([EMAIL PROTECTED]): Disable write caching on your ATA drive. You should be able to safely reset after that. Good idea, thanks. Nevertheless: I don't think the system should panic on background fsck's, while a manual fsck works. Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: several background fsck panics
Alexander Langer wrote: Thus spake Terry Lambert ([EMAIL PROTECTED]): Disable write caching on your ATA drive. You should be able to safely reset after that. Good idea, thanks. Nevertheless: I don't think the system should panic on background fsck's, while a manual fsck works. A manual fsck can deal with corrupt data. A background fsck can only deal with invalid cylinder group bitmaps, and operates on a snapshot. For a background fsck to be feasible, the FS has to be in a self-consistent state already, which it wasn't. When you killed the power on your system and reset it, you lost the cached data sitting in the ATA disk. This is due to the fact that the ATA disk lied, and claimed that it had committed some writes to stable storage, when in fact it had only copied them to the disk cache. As a result, when the device reset happened, you lost some writes which were in progress. Therefore you disk image was corrupt, and so your FS was *not* in a self-consistent state. This type of error happens on ATA disks because they do not permit disconnects during writes, only during reads. If you want to be able to reset your machine out from under your disk, with caching turned on, buy SCSI hardware, instead of ATA hardware: it does not lie to the host system, and claim tagged writes have been committed to stable storage when they have not, and are only in (volatile) cache RAM. The panic was not, in fact, a result of the background fsck itself: it was a result of an attempt to access FS structures by the kernel through the FS, assuming -- incorrectly -- that the FS structures were in a self-consistent state. This assumption was bogus, but there was no way for the kernel to know this because the failure state was not recovered, and that happened because PC hardware is bogus. This happened because you had background fsck enabled, and it was unable to tell the difference between a power failure vs. a panic vs. some other cause for a system crash (hardware or other failure). This is because the PC hardware itself doesn't record these types of events in NVRAM (e.g. CMOS), nor does it have sufficient DC holdup time that it could write a failure code to NVRAM, before losing its marbles. Hope this explains why you had the problem, and why real servers tend to specify SCSI hardware, and tend not to be PC-class hardware (i.e. an RS/6000 would have known the failure cause when it came back up from reading it's NVRAM, and performed a full recovery appropriate to the failure). PS: Unfortunately, this will not change on PC's any time soon, because people have been trained by computer vendors, disk vendors, and OS vendors that it's OK for PC's to need rebooting, and/or to crash unexpectedly in catastrophic ways that require reinstalling the OS. So people tolerate hardware that has ambiguous failure modes, as long as it costs less. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Solved??? Re: playing mp3s and burning a cd
The Anarcat wrote: On Mon Mar 24, 2003 at 02:14:48PM -0500, Don wrote: Should a PR be filed or some QA team contacted to make sure this problem doesn't stay alive in 5.2? :) This isn't, by chance, a problem with your setting for the sysctl hw.ata.atapi_dma is it? How extraordinarly cute! This solves it! I'm currently listening to Me, Mom and Morgentaler and burning a 4x CD without any slowdown, this is great. So I guess a workaround is to toggle DMA for my ATAPI bus. Indeed, the burner is IDE and should be working on DMA mode to get optimal performance. The thing is that atapicam hides the DMA/PIO magic from the usual boot messagesand there's therefore no way to see wether the device is in DMA mode unless you compile in both cd0 and acd0 which I heard isn't recommended... A. PS: what's the proper way to enable ATAPI DMA in the loader.conf file? I don't see any flag WRT that there.. I'm tempted to add: set hw.ata.atapi_cam=1 That would be: hw.ata.atapi_cam=1 if it works on loader at all. If not, /etc/sysctl.conf would be the place. anywhere there... Copyright (c) 1992-2003 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 5.0-RELEASE #2: Fri Mar 7 15:05:32 EST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/LENNII Preloaded elf kernel /boot/kernel/kernel at 0xc06ea000. Preloaded elf module /boot/kernel/snd_emu10k1.ko at 0xc06ea0a8. Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc06ea158. Preloaded elf module /boot/kernel/radeon.ko at 0xc06ea204. Preloaded elf module /boot/kernel/acpi.ko at 0xc06ea2b0. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 1008992834 Hz CPU: AMD Duron(tm) Processor (1008.99-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x670 Stepping = 0 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc044RSVD,AMIE,DSP,3DNow! real memory = 1207877632 (1151 MB) avail memory = 1166782464 (1112 MB) Initializing GEOMetry subsystem Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: ASUS A7V-133 on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 Using $PIR table, 9 entries at 0xc00f1750 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0 acpi_cpu0: CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: VIA 82C8363 (Apollo KT133A) host to PCI bridge mem 0xe600-0xe7ff at device 0.0 on pci0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 drm0: ATI Radeon QY VE (AGP) port 0xd800-0xd8ff mem 0xd700-0xd700,0xd800-0xdfff irq 11 at device 0.0 on pci1 info: [drm] AGP at 0xe600 32MB info: [drm] Initialized radeon 1.1.1 20010405 on minor 0 isab0: PCI-ISA bridge at device 4.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C686 ATA100 controller port 0xb800-0xb80f at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: VIA 83C572 USB controller port 0xb400-0xb41f irq 9 at device 4.2 on pci0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ugen0: Color FlatbedScanner 22, rev 1.00/1.00, addr 2 uhci1: VIA 83C572 USB controller port 0xb000-0xb01f irq 9 at device 4.3 on pci0 usb1: VIA 83C572 USB controller on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pci0: bridge, PCI-unknown at device 4.4 (no driver attached) vr0: VIA VT6102 Rhine II 10/100BaseTX port 0x9400-0x94ff mem 0xd680-0xd68000ff irq 9 at device 9.0 on pci0 vr0: Ethernet address: 00:50:ba:64:e3:6a miibus0: MII bus on vr0 ukphy0: Generic IEEE 802.3u media interface on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pcm0: Creative EMU10K1 port 0x9000-0x901f irq 5 at device 10.0 on pci0 atapci1: Promise ATA100 controller port 0x7000-0x703f,0x7400-0x7403,0x7800-0x7807,0x8000-0x8003,0x8400-0x8407 mem 0xd600-0xd601 irq 10 at device 17.0 on pci0 ata2: at 0x8400 on atapci1 ata3: at 0x7800 on atapci1 fdc0: Enhanced floppy controller (i82077, NE72065 or clone) port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 ppc0 port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff
Re: Linux emulation busted
On Tue, Mar 25, 2003 at 12:58:35AM +0900, [EMAIL PROTECTED] wrote: On Mon, Mar 24, 2003 at 08:40:55AM -0700, M. Warner Losh wrote: I had a working Linux world on my laptop. I upgraded my kernel and acroread4 stopped working. Now all I get is: Exited with error code: 0x400e0009. after a whole lot of disk access when I try to run it. This worked on a December kernel for sure. I'm pretty sure it was working as late as a January 15th kernel. It hasn't worked on a March 1st and subsequent kernels. I'm not sure where it broke inbetween. Has anybody else seen this? I've also seen this on two versions of -STABLE, one built this morning, and another built around February 24th. Ugh, I've found the fact that I was trying to start acrobat reader in Japanese mode (LANG set to ja_JP.eucJP) without installing Japanese font pack. After having installed ports/japanese/acroread5-jpnfont, acroread5 began to work without a problem. So maybe mine has nothing to do with what Warner was seeing. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: several background fsck panics
Thus spake Terry Lambert ([EMAIL PROTECTED]): A manual fsck can deal with corrupt data. [...] Yes, I recall the discussion about WC on ata vs. softupdates a few months back. I even have it disabled on more important machines than this one :-) The panic was not, in fact, a result of the background fsck itself: it was a result of an attempt to access FS structures by the kernel through the FS, assuming -- incorrectly -- that the FS structures were in a self-consistent state. Actually I don't care _where_ the panic happened. If I hadn't manually interupted the boot process, this kernel would have booted and paniced on that error for the next three years. I could fix that by simply doing a manual (background_fsck=NO), so something is broken, for some definition of broken: If my system panics, I call that broken. We claim background fsck as a cool new feature in the release notes, which is even the DEFAULT, including WC on ATA disks, which is ALSO the default. So , and if this is broken, there is a serious design flaw, which must be fixed. It doesn't help to explain why the error is there, the next user will have the same error, running a verbatim system. Ciao Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: MAKEDEV(8) manpage
On Tue, Mar 25, 2003 at 10:11:00AM +0100, Christian Brueffer wrote: On Mon, Mar 24, 2003 at 09:43:17PM +0200, Giorgos Keramidas wrote: On 2003-03-24 19:14, Christian Brueffer [EMAIL PROTECTED] wrote: I'll write a small manpage this evening which says that MAKEDEV is gone now with a short summary of what devfs does. Does that resolve your worries? If you write a detailed description of devfs please add it to devfs(5) and just replace the existing manpage of MAKEDEV with something like: The MAKEDEV script was deprecated by devfs(5) and geom(4) and removed from FreeBSD after GEOM became mandatory. Please see the devfs(5), devfs(8), geom(4) and mount_devfs(8) manpages for more details. This should be enough IMHO to point the reader to the right place. - Giorgos That was my original intent. I'm still uncertain if it would be better to write a small manpage or just create a MLINK to one of the devfs pages... Are you going to write a man page everytime a feature is deprecated? MAKEDEV is dead and gone. At most create the MLINK. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: MAKEDEV(8) manpage
On Tue, 25 Mar 2003, Steve Kargl wrote: SKOn Tue, Mar 25, 2003 at 10:11:00AM +0100, Christian Brueffer wrote: SK On Mon, Mar 24, 2003 at 09:43:17PM +0200, Giorgos Keramidas wrote: SK On 2003-03-24 19:14, Christian Brueffer [EMAIL PROTECTED] wrote: SK I'll write a small manpage this evening which says that MAKEDEV is SK gone now with a short summary of what devfs does. Does that resolve SK your worries? SK SK If you write a detailed description of devfs please add it to devfs(5) SK and just replace the existing manpage of MAKEDEV with something like: SK SK The MAKEDEV script was deprecated by devfs(5) and geom(4) and SK removed from FreeBSD after GEOM became mandatory. Please see SK the devfs(5), devfs(8), geom(4) and mount_devfs(8) manpages for SK more details. SK SK This should be enough IMHO to point the reader to the right place. SK SK - Giorgos SK SK SK That was my original intent. I'm still uncertain if it would be better SK to write a small manpage or just create a MLINK to one of the devfs SK pages... SK SK SKAre you going to write a man page everytime a feature SKis deprecated? MAKEDEV is dead and gone. At most SKcreate the MLINK. MAKEDEV has been in unix since at least version 7. That's about 30 years. If you deprecate a feature, that has been on virtually all unices for 30 years, it makes sense. Each time I type 'man vnconfig' (I don't use mdconfig often enough to remember which is actual and which of it is not there anymore) I'm puzzled that the mdconfig man page pops up. In that case it is easy to understand, that the functionality is almost the same. If I type 'man MAKEDEV' and devfs pops up, I have to think much more to find out, that these are somehow related. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: MAKEDEV(8) manpage
On 2003-03-25 07:10, Steve Kargl [EMAIL PROTECTED] wrote: On Tue, Mar 25, 2003 at 10:11:00AM +0100, Christian Brueffer wrote: On Mon, Mar 24, 2003 at 09:43:17PM +0200, Giorgos Keramidas wrote: On 2003-03-24 19:14, Christian Brueffer [EMAIL PROTECTED] wrote: I'll write a small manpage this evening which says that MAKEDEV is gone now with a short summary of what devfs does. Does that resolve your worries? If you write a detailed description of devfs please add it to devfs(5) and just replace the existing manpage of MAKEDEV with something like: The MAKEDEV script was deprecated by devfs(5) and geom(4) and removed from FreeBSD after GEOM became mandatory. Please see the devfs(5), devfs(8), geom(4) and mount_devfs(8) manpages for more details. This should be enough IMHO to point the reader to the right place. That was my original intent. I'm still uncertain if it would be better to write a small manpage or just create a MLINK to one of the devfs pages... Are you going to write a man page everytime a feature is deprecated? MAKEDEV is dead and gone. At most create the MLINK. Only for very important features that are a hardcoded part of most Unix users' brain patterns by now. MAKEDEV is a feature that has been with us for a long time. Actually, it's been in UNIX even before I was born! :-) Besides, I don't like (ab)using MLINKS for implicit redirects, because it feels like cheating or tricking the user to read something that he should instantly recognize and think ah, yes, here it is... this is not always the case though. Imagine the confusion if a Slackware Linux user who has learned that MAKEDEV is the place to look at, who goes into /dev and can't find it. He then goes on to type: % apropos MAKEDEV MAKEDEV: nothing appropriate. That must look annoying. Or even worse (using MLINKS), imagine the confusion when one types: % man MAKEDEV only to find that devfs(5) pops up. I can almost read already the posts to bugs@ or the PRs in the gnats database about manpage error, MAKEDEV loads devfs :-) - Giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: several background fsck panics
On Tue, 25 Mar 2003 16:04:07 +0100 Alexander Langer [EMAIL PROTECTED] wrote: We claim background fsck as a cool new feature in the release notes, which is even the DEFAULT, including WC on ATA disks, which is ALSO the default. So , and if this is broken, there is a serious design flaw, which must be fixed. It doesn't help to explain why the error is there, the next user will have the same error, running a verbatim system. AFAIK: Søren had the WC off for a while on -current, but a lot of people complained, so he switched it back on (I'm sure he regrets it every time he is reminded about it). So -- including you and me -- there are at least 3 committers which would like to see the WC turned off by default. There are a lot of other people without special @FreeBSD.org privileges which also don't like the actual default (if you can get a look at iX-10/2002 read the BSD-Softupdates vs. Linux-Journaling article - the tests for this article where done on SCSI hardware, but this doesn't matter in this case - it explains the interactions of WC, TQ and SO and how they affect the speed of some FS-operations). Maybe we can gain some momentum and restore POLA (in this case the default of going the safe way instead of the fast (but sometimes dangerous) way). Bye, Alexander. -- Yes, I've heard of decaf. What's your point? http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Broken DMA devices
On Tue Mar 25, 2003 at 08:16:28AM +0100, Soeren Schmidt wrote: It seems The Anarcat wrote: hw.ata.atapi_dma=1# Run the CD-ROM/DVD in DMA mode to /boot/loader.conf. This should be in almost EVERY /boot/loader.conf. The default is 0 (PIO) because DMA is broken on at least a few early CD readers, but it is very rare to have it fail. (I've never seen it.) Can't the ata drivers detect that condition or recognize the set of drives that are broken instead of penalizing everyone else? ATAPI DMA is more likely to be broken than to be working, it is a function of both controller chip and device, in some situations even a function of what master/slave device combo we have.. There is a reason that almost all OS's out there has it disabled as default :) Thanks for those precisions... This could be a FAQ, pertaining also to how to enable it. So it's enabled system-wide? Can't it be done at the bus or device level? A. -- Advertisers, not governments, are the primary censors of media content in the United States today. - C. Edwin Baker http://www.ad-mad.co.uk/quotes/freespeech.htm pgp0.pgp Description: PGP signature
Re: several background fsck panics
On Tue Mar 25, 2003 at 03:54:58AM -0800, Terry Lambert wrote: Alexander Langer wrote: Thus spake Terry Lambert ([EMAIL PROTECTED]): Disable write caching on your ATA drive. You should be able to safely reset after that. Good idea, thanks. Nevertheless: I don't think the system should panic on background fsck's, while a manual fsck works. A manual fsck can deal with corrupt data. A background fsck can only deal with invalid cylinder group bitmaps, and operates on a snapshot. For a background fsck to be feasible, the FS has to be in a self-consistent state already, which it wasn't. When you killed the power on your system and reset it, you lost the cached data sitting in the ATA disk. This is due to the fact that the ATA disk lied, and claimed that it had committed some writes to stable storage, when in fact it had only copied them to the disk cache. As a result, when the device reset happened, you lost some writes which were in progress. Therefore you disk image was corrupt, and so your FS was *not* in a self-consistent state. Shouldn't fsck run in the foreground for disks setup with WC? That would be a quick hack solving this issue altogether. A. -- Conformity-the natural instinct to passively yield to that vague something recognized as authority. - Mark Twain pgp0.pgp Description: PGP signature
=?x-unknown?q?Re=3A_world=40alpha_b=F8rken_in_libatm?=
On Tue, 25 Mar 2003, Poul-Henning Kamp wrote: /bang/src/lib/libatm/ip_checksum.c: In function `ip_checksum': /bang/src/lib/libatm/ip_checksum.c:80: warning: cast increases required alignmen I see in cvs that many of the files in this library have been updated in the last 11 or 12 hours... I get build problems still in that library at a different spot: -- liron# pwd /usr/src/lib/libatm liron# make cc -O -pipe -mcpu=ev4 -mtune=ev5 -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wuninitialized -c /usr/src/lib/libatm/ioctl_subr.c -o ioctl_subr.o cc1: warnings being treated as errors /usr/src/lib/libatm/ioctl_subr.c: In function `get_vcc_info': /usr/src/lib/libatm/ioctl_subr.c:175: warning: cast increases required alignment of target type /usr/src/lib/libatm/ioctl_subr.c: In function `get_subnet_mask': /usr/src/lib/libatm/ioctl_subr.c:229: warning: cast increases required alignment of target type /usr/src/lib/libatm/ioctl_subr.c: In function `get_cfg_info': /usr/src/lib/libatm/ioctl_subr.c:395: warning: cast increases required alignment of target type /usr/src/lib/libatm/ioctl_subr.c: In function `get_intf_info': /usr/src/lib/libatm/ioctl_subr.c:433: warning: cast increases required alignment of target type *** Error code 1 Stop in /usr/src/lib/libatm. -- This file aparently hasn't been modified in 5 months. 11 Hours ago, Makefile for this lib was modified to have WARNS?= 5 added which seems to have revealed the problem. For those who just want to get a complete buildworld, remvoing this is all that is needed (well, for this problem -- my buildworld is running right now...) As for the real problem I'm about to see what can be done about it. Fred -- Fred Clift - [EMAIL PROTECTED] -- Remember: If brute force doesn't work, you're just not using enough. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: =?x-unknown?q?Re=3A_world=40alpha_b=F8rken_in_libatm?=
On Tue, 25 Mar 2003, Fred Clift wrote: [SNIP] FC/usr/src/lib/libatm/ioctl_subr.c: In function `get_cfg_info': FC/usr/src/lib/libatm/ioctl_subr.c:395: warning: cast increases required FCalignment of target type FC/usr/src/lib/libatm/ioctl_subr.c: In function `get_intf_info': FC/usr/src/lib/libatm/ioctl_subr.c:433: warning: cast increases required FCalignment of target type FC*** Error code 1 FC FCStop in /usr/src/lib/libatm. FC FC FC-- FC FCThis file aparently hasn't been modified in 5 months. FC FC11 Hours ago, Makefile for this lib was modified to have FC FCWARNS?= 5 FC FCadded which seems to have revealed the problem. For those who just want FCto get a complete buildworld, remvoing this is all that is needed (well, FCfor this problem -- my buildworld is running right now...) FC FCAs for the real problem I'm about to see what can be done about it. I already contacted mdodd. One needs to get rid of caddr_t and replace it with void *. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Broken DMA devices
It seems The Anarcat wrote: On Tue Mar 25, 2003 at 08:16:28AM +0100, Soeren Schmidt wrote: It seems The Anarcat wrote: Can't the ata drivers detect that condition or recognize the set of drives that are broken instead of penalizing everyone else? ATAPI DMA is more likely to be broken than to be working, it is a function of both controller chip and device, in some situations even a function of what master/slave device combo we have.. There is a reason that almost all OS's out there has it disabled as default :) Thanks for those precisions... This could be a FAQ, pertaining also to how to enable it. So it's enabled system-wide? Can't it be done at the bus or device level? You can set the transfer mode of any ATA/ATAPI device with atacontrol... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
vinum broken by devstat changes?
Hi, when calling 'vinum start' it responds with usage: read drive [drive ...] from looking at the code, it appears that it cannot find the disk drives to read the configuration from. vinum read da0 da1 just works. So what's the problem? (kernel and user land from today) harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- === lib/libatm cc1: warnings being treated as errors /tinderbox/sparc64/src/lib/libatm/ioctl_subr.c: In function `get_vcc_info': /tinderbox/sparc64/src/lib/libatm/ioctl_subr.c:175: warning: cast increases required alignment of target type /tinderbox/sparc64/src/lib/libatm/ioctl_subr.c: In function `get_subnet_mask': /tinderbox/sparc64/src/lib/libatm/ioctl_subr.c:229: warning: cast increases required alignment of target type /tinderbox/sparc64/src/lib/libatm/ioctl_subr.c: In function `get_cfg_info': /tinderbox/sparc64/src/lib/libatm/ioctl_subr.c:395: warning: cast increases required alignment of target type /tinderbox/sparc64/src/lib/libatm/ioctl_subr.c: In function `get_intf_info': /tinderbox/sparc64/src/lib/libatm/ioctl_subr.c:433: warning: cast increases required alignment of target type *** Error code 1 Stop in /tinderbox/sparc64/src/lib/libatm. *** Error code 1 Stop in /tinderbox/sparc64/src/lib. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Broken DMA devices
On Tue Mar 25, 2003 at 06:28:38PM +0100, Soeren Schmidt wrote: It seems The Anarcat wrote: Thanks for those precisions... This could be a FAQ, pertaining also to how to enable it. So it's enabled system-wide? Can't it be done at the bus or device level? You can set the transfer mode of any ATA/ATAPI device with atacontrol... This is great. I should have looked at that earlier. So it looks like the sysctl, boot loader-time setting isn't really useful since I can set the modes when the kernel is booted, contrarly to the sysctl setting. And it still solves the skipping MP3 problem I had. Thanks for those precisions and that atacontrol pearl, Soeren. :) A. -- Advertisers, not governments, are the primary censors of media content in the United States today. - C. Edwin Baker http://www.ad-mad.co.uk/quotes/freespeech.htm pgp0.pgp Description: PGP signature
Re: Bluetooth on IBM T30 (USB device problem)
Tobias, yes it is a CSR chip based device. can you tell if its a USB device? yes, it is usb. windows clearly states it as usb. good. then you will most likely get it to work. if you get it to attach (see below). 1) at loader prompt type (without quotes) boot -v 2) do not press the Bluetooth button just yet 3) wait until system is fully loaded 4) kldload ugen (this is only required if you do not have device ugen the in the kernel config file) 5) press the Bluetooth button did 1), then 5) ugen did not attach, instead I got an error. see the attached files, the error is at the bottom of dmesg. Mar 25 21:59:36 angel5 kernel: uhub2: device problem, disabling port 1 well, this is a USB problem and has nothing to do with Bluetooth. you have a USB hub inside your laptop. for whatever reason USB stack does not like Bluetooth(?) USB devices when they plugged into hub. i have exactly the same problem with my laptop (Toshiba Tecra 8100). when i put it into the docking station (docking station has USB hub inside) my Bluetooth USB dongle stops working :( when i plug device directly into the laptop (without hub) evrything is working fine. i found out that if i unplug and re-plug the dongle quickly several times i can get it to attach. i guess you could try to press the Bluetooth button quickly few times :) i asked several times about this problem, but nobody answered :( you could try to do the same. i guess FreeBSD does not have USB guru anymore :( bottom line: ugen(4) must attach to the device, *if* USB stack attach the device. if you get the device to attach then you most likely will have working Bluetooth. thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic: blockable sleep lock (sleep mutex) Giant @ /usr/src/sys/vm/vm_fault.c:206
Hi,
My system: Current, cvsup'd Mon Mar 25 17:21:05 CET 2003
I load linux-compatability through /etc/rc.conf (linux_enable=YES).
If I unload it (kldunload linux.ko) and then run another command (so far, I've tested
kldstat(8) and ls(1)),
I get a panic:
panic: blockable sleep lock (sleep mutex) Giant @ /usr/src/sys/vm/vm_fault.c:206
The first time this happened was with a system built from yesterday's (March 24)
sources. Unloading
linux.ko, and running kldstat produced the panic. I noticed that
/usr/src/sys/vm/vm_fault.c had been
touched since my buildworld/installworld
($FreeBSD: src/sys/vm/vm_fault.c,v 1.164 2003/03/25 00:07:05 jake Exp $)
so I cvsup'd and built/installed world again.
This time I tested with kldunload linux.ko followed by ls. Panic again.
I'll be happy to supply more info if needed (but I'll probably need instructions).
You'll find my kernel-config at:
URL:http://www.krutov.org/martink/kernel-config
While searching on this, I came across a report of a similar
crash, to the -current list: (I don't know if this helps)
Message-ID: [EMAIL PROTECTED]
URL:http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1988511+0+archive/2003/freebsd-current/20030105.freebsd-current
Attached is a backtrace (at least I think it's a backtrace).
Best regards,
--
Martin Karlsson
c-303a70d5# gdb -k kernel.debug.0 vmcore.0
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 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-undermydesk-freebsd...
panic: from debugger
panic messages:
---
panic: blockable sleep lock (sleep mutex) Giant @ /usr/src/sys/vm/vm_fault.c:206
panic: from debugger
Uptime: 11m51s
Dumping 383 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368
---
Reading symbols from
/usr/obj/usr/src/sys/cuK20030325_2/modules/usr/src/sys/modules/acpi/acpi.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/cuK20030325_2/modules/usr/src/sys/modules/acpi/acpi.ko.debug
Reading symbols from /boot/kernel/blank_saver.ko...done.
Loaded symbols for /boot/kernel/blank_saver.ko
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239
239 dumping++;
(kgdb) where
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239
#1 0xc01e78c1 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:371
#2 0xc01e7b24 in poweroff_wait (junk=0xc030fa77, howto=-677123884) at
/usr/src/sys/kern/kern_shutdown.c:542
#3 0xc013a8fd in db_panic () at /usr/src/sys/ddb/db_command.c:448
#4 0xc013a8a0 in db_command (last_cmdp=0xc03415c0, cmd_table=0xc030fa77,
aux_cmd_tablep=0x104, aux_cmd_tablep_end=0xc345d000)
at /usr/src/sys/ddb/db_command.c:346
#5 0xc013a96b in db_command_loop () at /usr/src/sys/ddb/db_command.c:470
#6 0xc013ced2 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:72
#7 0xc02db570 in kdb_trap (type=3, code=0, regs=0xd7a3e974) at
/usr/src/sys/i386/i386/db_interface.c:170
#8 0xc02ea064 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1018834944, tf_esi = 256, tf_ebp
= -677123656, tf_isp = -677123680, tf_ebx = 0, tf_edx = 0, tf_ecx = 32, tf_eax = 18,
tf_trapno = 3, tf_err = 0, tf_eip = -1070745639, tf_cs = 8, tf_eflags = 662, tf_esp =
-1070446405, tf_ss = -677123628})
at /usr/src/sys/i386/i386/trap.c:602
#9 0xc02dca88 in calltrap () at {standard input}:96
#10 0xc01e7b0b in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:528
#11 0xc020256e in witness_lock (lock=0xc03760c0, flags=8, file=0xc0332416
/usr/src/sys/vm/vm_fault.c, line=206)
at /usr/src/sys/kern/subr_witness.c:604
#12 0xc01e0237 in _mtx_lock_flags (m=0xc03760c0, opts=0, file=0xc0332416
/usr/src/sys/vm/vm_fault.c, line=206) at /usr/src/sys/kern/kern_mutex.c:336
#13 0xc02aee16 in vm_fault (map=0xc082f000, vaddr=3277029376, fault_type=1 '\001',
fault_flags=0) at /usr/src/sys/vm/vm_fault.c:206
#14 0xc02ea231 in trap_pfault (frame=0xd7a3eb98, usermode=0, eva=3277031021) at
/usr/src/sys/i386/i386/trap.c:745
#15 0xc02e9eb5 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = -677183472, tf_edi = -1070112672, tf_esi =
-1070469158, tf_ebp = -677123108, tf_isp = -677123132, tf_ebx = -1069887352, tf_edx =
-1070469158, tf_ecx = -1017936275, tf_eax = 8, tf_trapno = 12, tf_err = 0, tf_eip =
-1071417774, tf_cs = 8, tf_eflags = 66050, tf_esp = -1069887352, tf_ss = -677123080})
at /usr/src/sys/i386/i386/trap.c:444
#16 0xc02dca88 in calltrap () at {standard input}:96
#17 0xc02030fe in enroll (description=0xc031efda filedesc structure,
lock_class=0xc0376060) at /usr/src/sys/kern/subr_witness.c:
#18 0xc02022a1 in witness_init (lock=0xc3775834) at
/usr/src/sys/kern/subr_witness.c:470
#19 0xc01e0a73 in mtx_init (m=0xc3775834, name=0xc031efda
LOR at boot
Hello! I'm running 5.0-RELEASE and this might have already been reported and/or fixed, but here it goes anyways. Copyright (c) 1992-2003 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 5.0-RELEASE #3: Mon Mar 24 15:39:05 EST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/LENNII Preloaded elf kernel /boot/kernel/kernel at 0xc0735000. Preloaded elf module /boot/kernel/snd_emu10k1.ko at 0xc07350b4. Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc0735164. Preloaded elf module /boot/kernel/radeon.ko at 0xc0735210. Preloaded elf module /boot/kernel/acpi.ko at 0xc07352bc. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 1008992999 Hz CPU: AMD Duron(tm) Processor (1008.99-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x670 Stepping = 0 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc044RSVD,AMIE,DSP,3DNow! real memory = 1207877632 (1151 MB) avail memory = 1166475264 (1112 MB) Initializing GEOMetry subsystem Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: ASUS A7V-133 on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 Using $PIR table, 9 entries at 0xc00f1750 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0 acpi_cpu0: CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: VIA 82C8363 (Apollo KT133A) host to PCI bridge mem 0xe600-0xe7ff at device 0.0 on pci0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 drm0: ATI Radeon QY VE (AGP) port 0xd800-0xd8ff mem 0xd700-0xd700,0xd800-0xdfff irq 11 at device 0.0 on pci1 info: [drm] AGP at 0xe600 32MB info: [drm] Initialized radeon 1.1.1 20010405 on minor 0 isab0: PCI-ISA bridge at device 4.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C686 ATA100 controller port 0xb800-0xb80f at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: VIA 83C572 USB controller port 0xb400-0xb41f irq 9 at device 4.2 on pci0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhub0: port error, restarting port 1 uhub0: port error, giving up port 1 ugen0: Color FlatbedScanner 22, rev 1.00/1.00, addr 2 uhub0: port error, restarting port 2 uhub0: port error, giving up port 2 uhci1: VIA 83C572 USB controller port 0xb000-0xb01f irq 9 at device 4.3 on pci0 usb1: VIA 83C572 USB controller on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhub1: port error, restarting port 1 uhub1: port error, giving up port 1 uhub1: port error, restarting port 2 uhub1: port error, giving up port 2 pci0: bridge, PCI-unknown at device 4.4 (no driver attached) vr0: VIA VT6102 Rhine II 10/100BaseTX port 0x9400-0x94ff mem 0xd680-0xd68000ff irq 9 at device 9.0 on pci0 ../../../vm/uma_core.c:1330: could sleep with vr0 locked from ../../../pci/if_vr.c:666 vr0: Ethernet address: 00:50:ba:64:e3:6a miibus0: MII bus on vr0 ukphy0: Generic IEEE 802.3u media interface on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ../../../vm/uma_core.c:1330: could sleep with vr0 locked from ../../../pci/if_vr.c:292 pcm0: Creative EMU10K1 port 0x9000-0x901f irq 5 at device 10.0 on pci0 atapci1: Promise ATA100 controller port 0x7000-0x703f,0x7400-0x7403,0x7800-0x7807,0x8000-0x8003,0x8400-0x8407 mem 0xd600-0xd601 irq 10 at device 17.0 on pci0 ata2: at 0x8400 on atapci1 ata3: at 0x7800 on atapci1 fdc0: Enhanced floppy controller (i82077, NE72065 or clone) port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 ppc0 port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model MouseMan+, device ID 0 orm0: Option ROMs at iomem 0xcc000-0xce7ff,0xc-0xcafff on isa0 pmtimer0 on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0
NFS -current
Hi, are there any known issues with NFS-mounts using UDP? I'm seeing some weird behaviour with a NFS-server (-current as of today). On several clients (-DP1, -DP2, 4-stable) mounting a nfs-share (mount_nfs -i -U -3 server:/nfs /mnt) and then copying data from that share to the local disk (find -x -d /mnt | cpio -pdumv /local) results in lost NFS-mount. client kernel: nfs server server:/nfs: not responding 10 9 I'm seeing this only while using UDP; with TCP everything works fine. The amount of data copied before it stalls is related to the number of nfsd-workers on the server. With 8 nfsd-processes (/usr/sbin/nfsd -u -t -n 8) running more data is copied before the mount gets lost. (The network works fine) Any hints? TIA, Patric -- The problem with troubleshooting is that trouble shoots back. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Unclean sync in current
I've been seeing this for a couple of weeks since I updated my laptop to CURRENT. I do a normal shutdown (-p or -r) and reboot. The shutdown looked normal, with no problems reported with the sync, but, when the system is rebooted, the partitions are all shown as possibly unclean. From my dmesg: Mounting root from ufs:/dev/ad0s3a WARNING: / was not properly dismounted WARNING: / was not properly dismounted WARNING: /tmp was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted All disks are mounted with soft-updates enabled. I don't see any other reports of this. Is this unique to my system? R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Panic in wait4()
I just got this on bento (running a kernel from Mar 17). It was under
heavy disk load at the time, which may or may not be relevant.
Kris
panic: mtx_lock() of spin mutex %s @ %s:%d
panic messages:
---
Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic.id =
fault virtual address = 0x5a0
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0218588
stack pointer = 0x10:0xe35e9ad8
frame pointer = 0x10:0xe35e9ad8
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 = 90819 (sshd)
Dumping 1024 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368
384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640 656 672 688 704
720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 992 1008
---
#0 doadump () at ../../../kern/kern_shutdown.c:239
239 dumping++;
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:239
#1 0xc0142645 in db_fncall (dummy1=1016, dummy2=0, dummy3=-1070744477,
dummy4=0xe35e98bc \f)
at ../../../ddb/db_command.c:546
#2 0xc01423c2 in db_command (last_cmdp=0xc03566a0, cmd_table=0x0,
aux_cmd_tablep=0xc0350978,
aux_cmd_tablep_end=0xc035097c) at ../../../ddb/db_command.c:346
#3 0xc01424d6 in db_command_loop () at ../../../ddb/db_command.c:470
#4 0xc014525a in db_trap (type=12, code=0) at ../../../ddb/db_trap.c:72
#5 0xc02ed61f in kdb_trap (type=12, code=0, regs=0xe35e9a98)
at ../../../i386/i386/db_interface.c:166
#6 0xc03068b2 in trap_fatal (frame=0xe35e9a98, eva=0) at ../../../i386/i386/trap.c:838
#7 0xc0306592 in trap_pfault (frame=0xe35e9a98, usermode=0, eva=1440)
at ../../../i386/i386/trap.c:757
#8 0xc030610d in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -944692528, tf_esi = -1070371206,
tf_ebp = -480339240, tf_isp = -480339260, tf_ebx = 1440, tf_edx = 1440, tf_ecx = 0,
tf_eax = 1440, tf_trapno = 12, tf_err = 0, tf_eip = -1071544952, tf_cs = 8, tf_eflags
= 66118, tf_esp = -480339040, tf_ss = -1071820373}) at ../../../i386/i386/trap.c:444
#9 0xc02eefc8 in calltrap () at {standard input}:97
#10 0xc01d51ab in kvprintf (fmt=0xc0336e7a @ %s:%d, func=0xc01d4b50 snprintf_func,
arg=0xe35e9bbc, radix=10, ap=0xe35e9c08 3\003) at ../../../kern/subr_prf.c:668
#11 0xc01d4ace in vsnprintf (str=0xc0398f40 mtx_lock() of spin mutex , size=0,
format=0x0,
ap=0x0) at ../../../kern/subr_prf.c:413
#12 0xc01b86b5 in panic (fmt=0xe35e9bbc Y\2179) at ../../../kern/kern_shutdown.c:509
#13 0xc01aeae3 in _mtx_lock_flags (m=0x0, opts=0,
file=0xc03375e7 ../../../kern/kern_resource.c, line=989) at
../../../kern/kern_mutex.c:333
#14 0xc01b75bb in chgproccnt (uip=0x3dd, diff=-1070369305, max=0)
at ../../../kern/kern_resource.c:989
#15 0xc01a2e48 in wait1 (td=0xc7b122d0, uap=0x0, compat=0) at
../../../kern/kern_exit.c:694
#16 0xc01a2970 in wait4 (td=0x0, uap=0x0) at ../../../kern/kern_exit.c:552
#17 0xc0306bfe in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = -1078001617, tf_edi = 134714784, tf_esi =
-1077939108, tf_ebp = -1077939144, tf_isp = -480338572, tf_ebx = 674575164, tf_edx =
0, tf_ecx = 19, tf_eax = 7, tf_trapno = 12, tf_err = 2, tf_eip = 674109043, tf_cs =
31, tf_eflags = 534, tf_esp = -1077939172, tf_ss = 47}) at
../../../i386/i386/trap.c:1030
#18 0xc02ef01d in Xint0x80_syscall () at {standard input}:139
---Can't read userspace from dump, or kernel process---
(kgdb)
pgp0.pgp
Description: PGP signature
Re: Panic in wait4()
On Tue, Mar 25, 2003 at 02:22:04PM -0800, Kris Kennaway wrote:
I just got this on bento (running a kernel from Mar 17). It was under
heavy disk load at the time, which may or may not be relevant.
[...]
#12 0xc01b86b5 in panic (fmt=0xe35e9bbc Y\2179) at ../../../kern/kern_shutdown.c:509
#13 0xc01aeae3 in _mtx_lock_flags (m=0x0, opts=0,
file=0xc03375e7 ../../../kern/kern_resource.c, line=989) at
../../../kern/kern_mutex.c:333
#14 0xc01b75bb in chgproccnt (uip=0x3dd, diff=-1070369305, max=0)
at ../../../kern/kern_resource.c:989
#15 0xc01a2e48 in wait1 (td=0xc7b122d0, uap=0x0, compat=0) at
../../../kern/kern_exit.c:694
#16 0xc01a2970 in wait4 (td=0x0, uap=0x0) at ../../../kern/kern_exit.c:552
#17 0xc0306bfe in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = -1078001617, tf_edi = 134714784, tf_esi =
-1077939108, tf_ebp = -1077939144, tf_isp = -480338572, tf_ebx = 674575164, tf_edx =
0, tf_ecx = 19, tf_eax = 7, tf_trapno = 12, tf_err = 2, tf_eip = 674109043, tf_cs =
31, tf_eflags = 534, tf_esp = -1077939172, tf_ss = 47}) at
../../../i386/i386/trap.c:1030
#18 0xc02ef01d in Xint0x80_syscall () at {standard input}:139
---Can't read userspace from dump, or kernel process---
Would you mind doing these commands from kgdb?
frame 15
print p-p_ucred
print *p-p_ucred
print p-p_ucred-cr_ruidinfo
print *p-p_ucred-cr_ruidinfo
Thanks,
Tim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: panic: blockable sleep lock (sleep mutex) Giant @ /usr/src/sys/vm/vm_fault.c:206
Martin Karlsson writes:
#9 0xc02dca88 in calltrap () at {standard input}:96
#10 0xc01e7b0b in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:528
#11 0xc020256e in witness_lock (lock=0xc03760c0, flags=8, file=0xc0332416
/usr/src/sys/vm/vm_fault.c, line=206)
at /usr/src/sys/kern/subr_witness.c:604
#12 0xc01e0237 in _mtx_lock_flags (m=0xc03760c0, opts=0, file=0xc0332416
/usr/src/sys/vm/vm_fault.c, line=206) at /usr/src/sys/kern/kern_mutex.c:336
It looks like the witness mutex debugging system crashed. This sort
of thing tends to happen when the witness data structures become
corrupt. A frequent cause of this is a module failing to destroy a
mutex.
I think the recent addition of the
MTX_SYSINIT(linux_osname, osname_lock, linux osname, MTX_DEF);
could be causing the problem, as I do not see how its getting torn
down.
Can you try the following patch (it may not even compile, I don't
have a current box handy):
(its obviously incomplete, just intended to see if it fixes the
problem you are seeing)
Drew
Index: compat/linux/linux_mib.c
===
RCS file: /home/ncvs/src/sys/compat/linux/linux_mib.c,v
retrieving revision 1.19
diff -u -r1.19 linux_mib.c
--- compat/linux/linux_mib.c13 Mar 2003 22:45:43 - 1.19
+++ compat/linux/linux_mib.c25 Mar 2003 23:05:08 -
@@ -50,7 +50,7 @@
SYSCTL_NODE(_compat, OID_AUTO, linux, CTLFLAG_RW, 0,
Linux mode);
-static struct mtx osname_lock;
+struct mtx osname_lock;
MTX_SYSINIT(linux_osname, osname_lock, linux osname, MTX_DEF);
static charlinux_osname[LINUX_MAX_UTSNAME] = Linux;
Index: i386/linux/linux_sysvec.c
===
RCS file: /home/ncvs/src/sys/i386/linux/linux_sysvec.c,v
retrieving revision 1.116
diff -u -r1.116 linux_sysvec.c
--- i386/linux/linux_sysvec.c 21 Mar 2003 19:49:34 - 1.116
+++ i386/linux/linux_sysvec.c 25 Mar 2003 23:07:36 -
@@ -885,6 +885,7 @@
linux_glibc2brand,
NULL
};
+extern struct mtx osname_lock;
static int
linux_elf_modevent(module_t mod, int type, void *data)
@@ -925,6 +926,7 @@
linux_ioctl_unregister_handler(*lihp);
if (bootverbose)
printf(Linux ELF exec handler removed\n);
+ mtx_destroy(osname_lock);
} else
printf(Could not deinstall ELF interpreter entry\n);
break;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: panic: blockable sleep lock (sleep mutex) Giant @ /usr/src/sys/vm/vm_fault.c:206
On 25-Mar-2003 Andrew Gallatin wrote:
Martin Karlsson writes:
#9 0xc02dca88 in calltrap () at {standard input}:96
#10 0xc01e7b0b in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:528
#11 0xc020256e in witness_lock (lock=0xc03760c0, flags=8, file=0xc0332416
/usr/src/sys/vm/vm_fault.c, line=206)
at /usr/src/sys/kern/subr_witness.c:604
#12 0xc01e0237 in _mtx_lock_flags (m=0xc03760c0, opts=0, file=0xc0332416
/usr/src/sys/vm/vm_fault.c, line=206) at /usr/src/sys/kern/kern_mutex.c:336
It looks like the witness mutex debugging system crashed. This sort
of thing tends to happen when the witness data structures become
corrupt. A frequent cause of this is a module failing to destroy a
mutex.
I think the recent addition of the
MTX_SYSINIT(linux_osname, osname_lock, linux osname, MTX_DEF);
could be causing the problem, as I do not see how its getting torn
down.
Oh, good catch Drew. My bad it seems :( I'll work up a patch.
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: panic: blockable sleep lock (sleep mutex) Giant @ /usr/src/sys/vm/vm_fault.c:206
John Baldwin writes: Oh, good catch Drew. My bad it seems :( I'll work up a patch. I see this all the time when people add code to our driver, test it only on linux. So I'm quite used to the symptoms ;) Thanks, Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: blockable sleep lock (sleep mutex) Giant @ /usr/src/sys/vm/vm_fault.c:206
On 25-Mar-2003 John Baldwin wrote:
On 25-Mar-2003 Andrew Gallatin wrote:
Martin Karlsson writes:
#9 0xc02dca88 in calltrap () at {standard input}:96
#10 0xc01e7b0b in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:528
#11 0xc020256e in witness_lock (lock=0xc03760c0, flags=8, file=0xc0332416
/usr/src/sys/vm/vm_fault.c, line=206)
at /usr/src/sys/kern/subr_witness.c:604
#12 0xc01e0237 in _mtx_lock_flags (m=0xc03760c0, opts=0, file=0xc0332416
/usr/src/sys/vm/vm_fault.c, line=206) at /usr/src/sys/kern/kern_mutex.c:336
It looks like the witness mutex debugging system crashed. This sort
of thing tends to happen when the witness data structures become
corrupt. A frequent cause of this is a module failing to destroy a
mutex.
I think the recent addition of the
MTX_SYSINIT(linux_osname, osname_lock, linux osname, MTX_DEF);
could be causing the problem, as I do not see how its getting torn
down.
Oh, good catch Drew. My bad it seems :( I'll work up a patch.
http://www.FreeBSD.org/~jhb/patches/linux.patch Similar to Drew's
except that I patched alpha as well. Similarly untested. Apply
with patch -p6 while in /sys. Please let me know if it fixes the
problem.
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: NFS -current
In message [EMAIL PROTECTED], Patric Mrawek writes: On several clients (-DP1, -DP2, 4-stable) mounting a nfs-share (mount_nfs -i -U -3 server:/nfs /mnt) and then copying data from that share to the local disk (find -x -d /mnt | cpio -pdumv /local) results in lost NFS-mount. client kernel: nfs server server:/nfs: not responding 10 9 I'm not sure what you mean by a lost mount. Do all further accesses to the filesystem hang? It is normal enough to get the above 'not responding' errors occasionally on a busy fileserver, but only if they are almost immediately followed by 'is alive again' messages. If the filesystem stops working and doesn't recover, could you run `tcpdump -nepX -s 1600 udp port 2049' when it hangs and record a few packets? Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic: indiracct: botched params (including a sound page fault)
Hi! With Terry's suggestion I turned ATA WC off this morning, and now, this happened: A crash when I pressed play in XMMS (this seems to be the first page fault you see, and then, with fsck in the background: yet another panic (UFS2 related?): The crashdump is a bit odd, since I don't know why it actually paniced (see the very end of this mail). Script started on Wed Mar 26 01:20:39 2003 (kgdb) core-file vmcore.2 panic: indiracct: botched params panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x24 fault code = supervisor read, page not present instruction pointer = 0x8:0xc021cdbb stack pointer = 0x10:0xd6828c40 frame pointer = 0x10:0xd6828c54 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 = 24 (irq5: pcm0) trap number = 12 panic: page fault syncing disks, buffers remaining... 3668 3668 Copyright (c) 1992-2003 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 5.0-CURRENT #5: Tue Mar 18 16:04:55 CET 2003 [EMAIL PROTECTED]:/data/obj/usr/src/sys/ZEROGRAVITY Preloaded elf kernel /boot/kernel/kernel at 0xc0682000. Preloaded elf module /boot/kernel/nvidia.ko at 0xc06820b4. Preloaded elf module /boot/kernel/linux.ko at 0xc0682160. Preloaded elf module /boot/kernel/acpi.ko at 0xc068220c. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 1477360975 Hz CPU: AMD Athlon(TM) XP1700+ (1477.36-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x662 Stepping = 2 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc048MP,AMIE,DSP,3DNow! real memory = 536788992 (511 MB) avail memory = 514334720 (490 MB) Allocating major#253 to net Allocating major#252 to pci Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: ASUS A7V266-E on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 pcibios: BIOS version 2.10 Using $PIR table, 10 entries at 0xc00f13a0 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0 acpi_cpu0: CPU port 0x530-0x537 on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 nvidia0: GeForce2 MX/MX 400 mem 0xf000-0xf7ff,0xeb00-0xebff irq 10 at device 0.0 on pci1 pcm0: CMedia CMI8738 port 0xd800-0xd8ff irq 5 at device 5.0 on pci0 sym0: 875 port 0xd400-0xd4ff mem 0xea00-0xea000fff,0xea80-0xea8000ff irq 9 at device 12.0 on pci0 sym0: No NVRAM, ID 7, Fast-20, SE, parity checking xl0: 3Com 3c905B-TX Fast Etherlink XL port 0xd000-0xd07f mem 0xe980-0xe980007f irq 10 at device 13.0 on pci0 xl0: Ethernet address: 00:50:04:0f:66:6f miibus0: MII bus on xl0 xlphy0: 3Com internal media interface on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci0: display, VGA at device 15.0 (no driver attached) pci0: multimedia, video at device 16.0 (no driver attached) pci0: multimedia at device 16.1 (no driver attached) isab0: PCI-ISA bridge at device 17.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 8233 UDMA100 controller port 0xb800-0xb80f at device 17.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: VIA 83C572 USB controller port 0xb400-0xb41f irq 9 at device 17.2 on pci0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ulpt0: Hewlett-Packard DeskJet 930C, rev 1.00/1.00, addr 2, iclass 7/1 ulpt0: using bi-directional mode uhci1: VIA 83C572 USB controller port 0xb000-0xb01f irq 9 at device 17.3 on pci0 usb1: VIA 83C572 USB controller on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhub1: port error, restarting port 1 uhub1: port error, restarting port 2 uhci2: VIA 83C572 USB controller port 0xa800-0xa81f irq 9 at device 17.4 on pci0 usb2: VIA 83C572 USB controller on uhci2 usb2: USB revision 1.0 uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhub2: port error, restarting port 1 uhub2: port error, restarting port 2 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0
Re: vinum broken by devstat changes?
On Tuesday, 25 March 2003 at 18:44:03 +0100, Hartmut Brandt wrote: Hi, when calling 'vinum start' it responds with usage: read drive [drive ...] from looking at the code, it appears that it cannot find the disk drives to read the configuration from. vinum read da0 da1 just works. So what's the problem? (kernel and user land from today) Check vinum(8), function vinum_start (in /usr/src/sbin/vinum/commands.c). It's possible that the changes have broken some of the tests, probably of stat-device_type. I can't think it's too difficult to fix. Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Re: Panic in wait4()
On Wed, Mar 26, 2003 at 10:13:05AM +1100, Tim Robbins wrote:
#12 0xc01b86b5 in panic (fmt=0xe35e9bbc Y\2179) at
../../../kern/kern_shutdown.c:509
#13 0xc01aeae3 in _mtx_lock_flags (m=0x0, opts=0,
file=0xc03375e7 ../../../kern/kern_resource.c, line=989) at
../../../kern/kern_mutex.c:333
#14 0xc01b75bb in chgproccnt (uip=0x3dd, diff=-1070369305, max=0)
at ../../../kern/kern_resource.c:989
#15 0xc01a2e48 in wait1 (td=0xc7b122d0, uap=0x0, compat=0) at
../../../kern/kern_exit.c:694
#16 0xc01a2970 in wait4 (td=0x0, uap=0x0) at ../../../kern/kern_exit.c:552
#17 0xc0306bfe in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = -1078001617, tf_edi = 134714784, tf_esi =
-1077939108, tf_ebp = -1077939144, tf_isp = -480338572, tf_ebx = 674575164, tf_edx
= 0, tf_ecx = 19, tf_eax = 7, tf_trapno = 12, tf_err = 2, tf_eip = 674109043,
tf_cs = 31, tf_eflags = 534, tf_esp = -1077939172, tf_ss = 47}) at
../../../i386/i386/trap.c:1030
#18 0xc02ef01d in Xint0x80_syscall () at {standard input}:139
---Can't read userspace from dump, or kernel process---
Would you mind doing these commands from kgdb?
frame 15
print p-p_ucred
print *p-p_ucred
(kgdb) frame 15
#15 0xc01a2e48 in wait1 (td=0xc7b122d0, uap=0x0, compat=0) at
../../../kern/kern_exit.c:694
694 (void)chgproccnt(p-p_ucred-cr_ruidinfo, -1, 0);
(kgdb) print p-p_ucred
$1 = (struct ucred *) 0x7572636c
(kgdb) print *p-p_ucred
---Can't read userspace from dump, or kernel process---
:-(
Kris
pgp0.pgp
Description: PGP signature
Re: panic: blockable sleep lock (sleep mutex) Giant @ /usr/src/sys/vm/vm_fault.c:206
* Andrew Gallatin [EMAIL PROTECTED] [2003-03-25 18.10 -0500]: [...snip text...] Index: compat/linux/linux_mib.c === [...snip patch] Hi! Sure, I'll try it. But, from where (i.e. which directory) should I apply it, and with which value N for patch -pN? And then what? '# cd /usr/src/sys make make install' followed by a reboot and do a crash test? (Or should I rebuild/reinstall world?) /me == newbie :) -- Martin Karlsson To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: blockable sleep lock (sleep mutex) Giant @ /usr/src/sys/vm/vm_fault.c:206
* John Baldwin [EMAIL PROTECTED] [2003-03-25 18.41 -0500]: [...snip...] http://www.FreeBSD.org/~jhb/patches/linux.patch Similar to Drew's except that I patched alpha as well. Similarly untested. Apply with patch -p6 while in /sys. Please let me know if it fixes the problem. Sure, I'll try it. And then? '# cd /usr/src/sys/compat/linux make make install' followed by reboot and crash test? (Or rebuild/reinstall world?) BTW, I've backed up my /usr/src dir, so I can apply the two patches one by one. Or should I apply them together? (Actually, I don't mind testing all three options, but I'd like to hear what you have to say about this. Best regards, -- Martin Karlsson --- newbie To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: several background fsck panics
Alexander Langer wrote: Actually I don't care _where_ the panic happened. If I hadn't manually interupted the boot process, this kernel would have booted and paniced on that error for the next three years. I could fix that by simply doing a manual (background_fsck=NO), so something is broken, for some definition of broken: If my system panics, I call that broken. Actually, you *do* care where the panic occurred. 8-). The issue with the repeating background fsck's is important. I suggest a counter that gets reset to zero each time the FS is marked clean by fsck, and incremented each time the background fsck process is started. When this counter reaches a predefined value (I sugest a command line option to background fsck, which defaults to 3, if left unspecified), then the fsck is automatically converted to a foreground fsck. This counter would be recorded in the superblock. We claim background fsck as a cool new feature in the release notes, I don't. I'm convinced it's technically infeasible, and Kirk has validated my reasoning on this, previously. It is about as safe or unsafe as running with async mounts. Maybe worse, depending on the MTBF for your disk drives (i.e. ATA drives fail fairly often, if not catastrophically, in the presence of power failures; this can be mitigated by dual power supplies and UPS equipment). which is even the DEFAULT, including WC on ATA disks, which is ALSO the default. So , and if this is broken, there is a serious design flaw, which must be fixed. It doesn't help to explain why the error is there, the next user will have the same error, running a verbatim system. The explanation is that the very idea of a background fsck, without additional hardware support, is flawed. Rather than the problem occuring in the snapshot code, it could just as easily occured as a result of some process running before it had the opportunity to fsck at all. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[Re: vinum broken by devstat changes?
On Wed, Mar 26, 2003 at 11:06:52 +1030, Greg 'groggy' Lehey wrote: On Tuesday, 25 March 2003 at 18:44:03 +0100, Hartmut Brandt wrote: Hi, when calling 'vinum start' it responds with usage: read drive [drive ...] from looking at the code, it appears that it cannot find the disk drives to read the configuration from. vinum read da0 da1 just works. So what's the problem? (kernel and user land from today) Check vinum(8), function vinum_start (in /usr/src/sbin/vinum/commands.c). It's possible that the changes have broken some of the tests, probably of stat-device_type. I can't think it's too difficult to fix. disk_create() now creates the devstat entry for disks, but defaults everything to be a direct access (with no interface type). I've got patches in progress to fix that, but it looks like things should work with the current state of affairs. Have you rebuilt world? It looks like vinum(8) doesn't include a call to devstat_checkversion(), so it's possible you've got a version mismatch but no way to know it. Ken -- Kenneth Merry [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[Re: several background fsck panics
The Anarcat wrote: When you killed the power on your system and reset it, you lost the cached data sitting in the ATA disk. This is due to the fact that the ATA disk lied, and claimed that it had committed some writes to stable storage, when in fact it had only copied them to the disk cache. As a result, when the device reset happened, you lost some writes which were in progress. Therefore you disk image was corrupt, and so your FS was *not* in a self-consistent state. Shouldn't fsck run in the foreground for disks setup with WC? That would be a quick hack solving this issue altogether. There are a lot of quick hacks that can be done to solve the issue. There are also real fixes: o Disable BG fsck if WC is on; I dislike this hack, mostly because of postings by drive engineers to FreeBSD lists, indicating a willingness to address ATA issues like this, and the fact that most SCSI drives don't actually have this issue. o Put a counter in the first superblock; it would be incremented when the BG fsck is started, and reset to zero when it completes. If the counter reaches 3 (or some command line specified number), then the BG flagging is ignored, and a full FG fsck is then performed instead. I like this idea because it will always work, and it's not actually a hack, it's a correct solution. o Implement soft read-only. The place that most of the complaints are coming from is desktop users, with relatively quiescent machines. Though swap is used, it does not occur in an FS partition. As a result, the FS could be marked read-only for long period of time. This marking would be in memory. The clean bit would be set on the superblock. When a write occurs, the clean bit would be reset to dirty, and committed to disk prior to the write operation being permitted to proceed (a stall barrier). I like this idea because, for the most part, it eliminates fsck, both BG and FG, on systems that crash while it's in effect. The net result is a system that is statistically much more tolerant of failures, but which still requires another safety net, such as the previous solution. o Disk manufacturers could fix the ATA write caching problem. I think this will happen eventually, so the first solution is out. o PC manufacturers could provide OS-usable NVRAM scratch areas, which would permit an OS to allocate a section, and use it. The OS would then write the FreeBSD marker into an area to allocate it, and then write power fail as the failure code into the allocated area. When a panic or hardware failure occurred, it could write panic or hardware fail as the failure code. When the system came back up, it would be able to distinguish which type of failure by reading the NVRAM area. If it was something like panic with sync, it could run the BG fsck, otherwise it would run the FG fsck. I really like this idea, too. I believe that more modern systems have this capability, but it has not yet been standardized. Therefore we should take a wait and see attitude towards it. o Disk manufacturers could provide a Lithium battery on board disks. This would not only bound their planned obsolesence curve to 5 years or so (lifetime of the battery), it would give them an aftermarket. The battery would trickle-charge from the disk drive power, and would be used to commit the write cache in event of power failure. I like this too; it makes disk drives obsolete at about 2X the distance that they become obsolete, it gives the drive manufacturers a bone for playing along, and it actually solves the problem at it's source. People might not like your disk lasts 5 years vs. your warranty is one year, but smoothing the market demand function is probably worth more, in terms of lower cost to consumers and assured profit to disk manufacturers, and it can be billed as a marketing checkbox item, to force all the other disk manufacturers into implementing it, too, so there should be no downside. o We can change our file system structure to journalled; I like this as well, but there are some issues with manufacturers who do not provide track bondary information, so you can assure yourselves that a track boundary doesn't span a corruption boundary, in the event of a power failure. If you can do this, journalling actually becomes incredibly fast, since you know the disk writes backwards on a given track, so you can just implemente the completed write datestamp, and perform a single
[Re: NFS -current
I'm not sure if it's related, but i've noticed under HEAVY nfs load my nfs server hangs for a while, then it REBOOTS! i'm pretty sure it's a nfs related problem, because doing heavy disk i/o on the server itself doen't have any related problems at all.. only when it's heavy access over nfs. I'm going to try makeworld again today, maybe it was a bug that has been fixed. we'll see On several clients (-DP1, -DP2, 4-stable) mounting a nfs-share (mount_nfs -i -U -3 server:/nfs /mnt) and then copying data from that share to the local disk (find -x -d /mnt | cpio -pdumv /local) results in lost NFS-mount. client kernel: nfs server server:/nfs: not responding 10 9 I'm not sure what you mean by a lost mount. Do all further accesses to the filesystem hang? It is normal enough to get the above 'not responding' errors occasionally on a busy fileserver, but only if they are almost immediately followed by 'is alive again' messages. If the filesystem stops working and doesn't recover, could you run `tcpdump -nepX -s 1600 udp port 2049' when it hangs and record a few packets? Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[Re: panic: blockable sleep lock (sleep mutex) Giant @/usr/src/sys/vm/vm_fault.c:206
Martin Karlsson writes: * John Baldwin [EMAIL PROTECTED] [2003-03-25 18.41 -0500]: [...snip...] http://www.FreeBSD.org/~jhb/patches/linux.patch Similar to Drew's except that I patched alpha as well. Similarly untested. Apply with patch -p6 while in /sys. Please let me know if it fixes the problem. Sure, I'll try it. And then? Rebuild your linux module. cd /sys/modules/linux make depend make If you've never loaded linux (and won't crash because of the bug), then load the new module: kldload ./linux.ko kldunload linux Else just install the module and reboot cp linux.ko /boot/kernel/ shutdown -r now BTW, I've backed up my /usr/src dir, so I can apply the two patches one by one. Or should I apply them together? (Actually, I don't mind testing all three options, but I'd like to hear what you have to say about this. Just apply John's patch. Its cleaner suitable for committing if it works. Mine was a quick hack while waiting for my dinner to microwave itself.. Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[Re: panic: blockable sleep lock (sleep mutex) Giant @/usr/src/sys/vm/vm_fault.c:206
* John Baldwin [EMAIL PROTECTED] [2003-03-25 18.41 -0500]: Hi John, http://www.FreeBSD.org/~jhb/patches/linux.patch Similar to Drew's except that I patched alpha as well. Similarly untested. Apply with patch -p6 while in /sys. Please let me know if it fixes the problem. It fixes the problem. I loaded/unloaded the module a few times, and ran various linux-dependant apps. Thank you. (And thanks for the instructions you mailed me, Drew.) Best regards, -- Martin Karlsson ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[Re: Unclean sync in current
Kevin Oberman wrote: I've been seeing this for a couple of weeks since I updated my laptop to CURRENT. I do a normal shutdown (-p or -r) and reboot. The shutdown looked normal, with no problems reported with the sync, but, when the system is rebooted, the partitions are all shown as possibly unclean. From my dmesg: Mounting root from ufs:/dev/ad0s3a WARNING: / was not properly dismounted [ ... ] There was an issue reported some time back about the power being shut off before the disks had been forced to sync their write caches out to stable storage, resulting in this behaviour. I believe Soeren updated the driver to force this sync before returning, at least for ATA drives, so you may just be running stale code. Alternately, you may just have disk drives that ignore the command. I think it was controlled by a sysctl with sync in the name, so you might want to look it up via: sysctl -A | grep sync if you are in fact running the most recent -CURRENT. I think there was a delay factor, in seconds, involved (FWIW). Another alternative is to disable write caching on the disk, as a workaround (amazing how many times recently that that's been the answer to someone's problem...). -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[Re: NFS -current
Ian Dowse wrote: In message [EMAIL PROTECTED], Patric Mrawek writes: On several clients (-DP1, -DP2, 4-stable) mounting a nfs-share (mount_nfs -i -U -3 server:/nfs /mnt) and then copying data from that share to the local disk (find -x -d /mnt | cpio -pdumv /local) results in lost NFS-mount. client kernel: nfs server server:/nfs: not responding 10 9 I'm not sure what you mean by a lost mount. Do all further accesses to the filesystem hang? It is normal enough to get the above 'not responding' errors occasionally on a busy fileserver, but only if they are almost immediately followed by 'is alive again' messages. Particularly when using UDP with a rsize or wsize larger than the MTU, which Linux people do all the time. As you are using UDP... If you hear hoofbeats, look for horses first, not zebras. This is arguably a bug in the FreeBSD UDP packet reassembly code not throwing away packets through ageing. There's a DOS attack you can use against FreeBSD against UDP protocols with larger than MTU packets, knowing this. But I think it's more arguably a bug in people using UDP in a wrong-headed way, in order to try and get a window size larger that the MTU, without using a sliding window protocol like TCP instead, which is designed to handle this much more gracefully. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
New signal code.
I'm looking for some poeple to try out my threading patches. I'm only looking for people to make sure that there have been no reversions in signal handling. I'm not ready for people to test out the actual threading interfaces. You should notice no changes in application behavior or system performance with these patches. Let me know how it goes.. http://www.chesapeake.net/~jroberson/thr.diff Thanks, Jeff ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Freeze from pppd
Your patch is working great here. Still struggling with pppd
configuration, but I am no longer getting any system freezes on my ppp
dialin attempts. Thanks, Maxim!
-Tod
On Sunday, March 23, 2003, at 09:18 AM, Maxim Konovalov wrote:
Try a next patch.
Index: if_ppp.c
===
RCS file: /home/ncvs/src/sys/net/if_ppp.c,v
retrieving revision 1.90
diff -u -r1.90 if_ppp.c
--- if_ppp.c4 Mar 2003 23:19:51 - 1.90
+++ if_ppp.c23 Mar 2003 17:05:28 -
@@ -1571,7 +1571,7 @@
rv = IF_HANDOFF(sc-sc_inq, m, NULL);
else
rv = netisr_queue(isr, m);
-if (rv) {
+if (!rv) {
if (sc-sc_flags SC_DEBUG)
if_printf(ifp, input queue full\n);
ifp-if_iqdrops++;
%%%
--
Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED]
--
Tod Oace [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New signal code.
I pooched the patch. It's updated now. On Tue, 25 Mar 2003, Jeff Roberson wrote: I'm looking for some poeple to try out my threading patches. I'm only looking for people to make sure that there have been no reversions in signal handling. I'm not ready for people to test out the actual threading interfaces. You should notice no changes in application behavior or system performance with these patches. Let me know how it goes.. http://www.chesapeake.net/~jroberson/thr.diff Thanks, Jeff ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unclean sync in current
Date: Tue, 25 Mar 2003 13:47:18 -0800 From: Kevin Oberman [EMAIL PROTECTED] On Tue, Mar 25, 2003 at 01:14:26PM -0800, Kevin Oberman wrote: I've been seeing this for a couple of weeks since I updated my laptop to CURRENT. I do a normal shutdown (-p or -r) and reboot. The shutdown looked normal, with no problems reported with the sync, but, when the system is rebooted, the partitions are all shown as possibly unclean. From my dmesg: Mounting root from ufs:/dev/ad0s3a WARNING: / was not properly dismounted ... All disks are mounted with soft-updates enabled. I don't see any other reports of this. Is this unique to my system? Go to single user mode and run fsck -f -p on each filesystem. ... Actually, 'fsck -f -p' didn't help at all. I had to do fsck_ffs on every partition (as per the message cited). Looks to me like this belongs in UPDATING, although it does not break anything. Maybe in the v4 to current update instructions. Sorry to quote so much; I was offline most of the day Anyway: I am continuing to track both -STABLE and -CURRENT on a daily basis on a couple of machines, one of which is my laptop (a Dell i5000e). I have soft updates enabled for each (UFS) file system. (I set up /tmp as mfs/md; I do not enable soft updates on it.) I have a couple of file systems that are mounted read-write regardless of what I boot (one of which is /var, so I have some assurance that both -STABLE and -CURRENT are mounting the file system and writing to it). (The other is the one that has my home directory, the local CVS repository, /usr/local, and the various /usr/obj hierarchies that correspond to each bootable slice. So yeah, this one gets mounted read-write, and is written to.) When I boot -STABLE, I typically mount all mountable file systems. When I boot -CURRENT, I typically do not mount the root and /usr file systems that I use for -STABLE. I have seen no problems doing this in several months. (Last time I did was because -STABLE's fsck needed a tweak to accomodate a change made in -CURRENT. This merely caused whines and annoyance; there was no data loss. Cheers, david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill [EMAIL PROTECTED] Based on what I have seen to date, the use of Microsoft products is not consistent with reliability. I recommend FreeBSD for reliable systems. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Re: NFS -current
In the last episode (Mar 25), Terry Lambert said: Ian Dowse wrote: I'm not sure what you mean by a lost mount. Do all further accesses to the filesystem hang? It is normal enough to get the above 'not responding' errors occasionally on a busy fileserver, but only if they are almost immediately followed by 'is alive again' messages. Particularly when using UDP with a rsize or wsize larger than the MTU, which Linux people do all the time. As you are using UDP... If you hear hoofbeats, look for horses first, not zebras. UDP works just fine on a switched network. On my NFS servers I use an 8k rsize/wsize and UDP mounts on everything and have relatively few dropped fragments. Server 1 (NFS homedir server): 21:22 up 23 days, 8:02, 36 users, load averages: 0.00 0.01 0.00 ip: 1783574152 total packets received 520544166 fragments received 82873817 packets reassembled ok 15246 fragments dropped after timeout Server 2: 21:31 up 223 days, 13:17, 35 users, load averages: 0.19, 0.12, 0.09 ip: 2089844841 total packets received (rolled over 4 times) 3965873984 fragments received 668066863 packets reassembled ok 25596 fragments dropped after timeout (hmm whatever happened to the 64-bit network counters idea) -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bluetooth on IBM T30 (USB device problem)
--On Tuesday, March 25, 2003 13:25:47 -0800 Maksim Yevmenkin [EMAIL PROTECTED] wrote: Tobias, yes it is a CSR chip based device. can you tell if its a USB device? yes, it is usb. windows clearly states it as usb. good. then you will most likely get it to work. if you get it to attach (see below). 1) at loader prompt type (without quotes) boot -v 2) do not press the Bluetooth button just yet 3) wait until system is fully loaded 4) kldload ugen (this is only required if you do not have device ugen the in the kernel config file) 5) press the Bluetooth button did 1), then 5) ugen did not attach, instead I got an error. see the attached files, the error is at the bottom of dmesg. Mar 25 21:59:36 angel5 kernel: uhub2: device problem, disabling port 1 I had a similar (USB) issue on my Fujitsu Laptop, until I **ENABLED** the USB Floppy option in my BIOS. Don't ask me why that fixed it, but ANY USB device I plugged in would garner the above response without that option being set. Just another data point. (BTW, 4-STABLE, if it matters). -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Bluetooth on IBM T30 (USB device problem)
Larry, [...] Mar 25 21:59:36 angel5 kernel: uhub2: device problem, disabling port 1 I had a similar (USB) issue on my Fujitsu Laptop, until I **ENABLED** the USB Floppy option in my BIOS. Don't ask me why that fixed it, but ANY USB device I plugged in would garner the above response without that option being set. man you are a genius :) why didn't you tell us before :) oh well, after quick google'ing i found this link. http://www.intel.com/support/peripherals/wd_wlss/usbnotes.htm it talks about USB Legacy Support or USB Legacy Emulator option in the BIOS. you should have this Enabled. so i went to BIOS on my Tecra and set it to Enabled and now my Bluetooth dongle works just fine when i plug it into the docking station. thanks a bunch! max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Bluetooth on IBM T30 (USB device problem)
--On Tuesday, March 25, 2003 13:51:34 -0800 Maksim Yevmenkin [EMAIL PROTECTED] wrote: Larry, [...] Mar 25 21:59:36 angel5 kernel: uhub2: device problem, disabling port 1 I had a similar (USB) issue on my Fujitsu Laptop, until I **ENABLED** the USB Floppy option in my BIOS. Don't ask me why that fixed it, but ANY USB device I plugged in would garner the above response without that option being set. man you are a genius :) why didn't you tell us before :) oh well, after quick google'ing i found this link. someone else helped ME with this issue with the USB stuff. Check the -mobile archives and the PR database. http://www.intel.com/support/peripherals/wd_wlss/usbnotes.htm it talks about USB Legacy Support or USB Legacy Emulator option in the BIOS. you should have this Enabled. so i went to BIOS on my Tecra and set it to Enabled and now my Bluetooth dongle works just fine when i plug it into the docking station. That's what the mailing-lists are for, to help each other. LER thanks a bunch! My pleasure. max -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
