Re: FreeBSD 7.0 Questions
On Wed, Feb 27, 2008 at 11:15:30PM -0800, Doug Hardie wrote: > I have just installed 7.0 on some new hardware. Have never tried earlier > versions. There are a couple of unexpected items that I do not understand. > > 2. I have 2 SATA drives in the system. The first is recognized as ad10 > and the second as ad12. I expected to see ad0 and ad1. You shouldn't "expect" this in any way shape or form. The device numbers are not consistent, and are known to change depending upon lots of reasons (AHCI disabled/enabled, another ATA controller in place, SATA in "compatible" mode or "enhanced" mode, etc. etc.). Thus, never expect the adX devices to "start with 0". -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD 7.0 Questions
I have just installed 7.0 on some new hardware. Have never tried earlier versions. There are a couple of unexpected items that I do not understand. 1. When booting there are a few messages like: acd0: TIMEOUT - READ_BIG retrying When the system is booted off CD (like installation disk), it takes about 10 minutes after these messages first appear and then it finally starts up sysinstall properly. After the system is installed on disk, it reboots and just continues on past those messages with no delays. Sometimes those messages do not appear in dmesg.boot. Why are there long delays when booting from CD? 2. I have 2 SATA drives in the system. The first is recognized as ad10 and the second as ad12. I expected to see ad0 and ad1. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fsck_ufs: cannot alloc 94208 bytes for inoinfo
On Wed, Feb 27, 2008 at 11:53:01AM -0800, Matthew Dillon wrote: > You can also reduce fsck time by reducing the number of cylinder > groups on the disk. I usually max them out (-c 999 and newfs then > sets it to the maximum, usually in the 50-80 range). This will > improve performance but not reduce the memory required. Note that this advice is relevant for UFS1 only. In UFS2, '-c' specifies the cylinder group size in _BLOCKS_ not cylinders and defaults to the maximum size for the given blocksize and IPG etc. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpHRuuGnCnwn.pgp Description: PGP signature
Re: FreeBSD 7.0-RELEASE Available
Ken Smith wrote: Just in case some interested parties are not subscribed to the freebsd-announce mailing list... FreeBSD 7.0-RELEASE has been formally released. If you would like to see the release announcement it's here: http://www.freebsd.org/releases/7.0R/announce.html On behalf of the FreeBSD Project thanks for your interest in FreeBSD. We hope you enjoy the new release. Thanks guys - much appreciated by those of us that use it as our everyday os! ... upgrading from 6.3 stable as we speak... regards Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems with promise SATA300 TX2Plus
Jisakiel wrote: Is there any way to make this card work on FreeBSD 7, or anything else that I could try? Did you find any new BIOS versions for you motherboard? -- WBR, Andrey V. Elsukov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ad0 READ_DMA TIMEOUT errors on install of 7.0-RELEASE
Scott Long wrote: I'd like to attack these driver problems. What I need is to spend a couple of days with an affected system that can reliably reproduce the problem, instrumenting and testing the driver. I have a number of theories about what might be going wrong, but nothing that I'm definitely sure about. If you are willing to set up your system with remote power and remote serial, and if we knew a reliable way to reproduce the problem, I could probably have the problem identified and fixed pretty quickly. So, it turns out that I can't have multiple PPPoE sessions at the same time. :-( I should be able to hack together something though if the rest of the stuff I mentioned is fine. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ad0 READ_DMA TIMEOUT errors on install of 7.0-RELEASE
Scott Long wrote: I'm betting that it's a driver problem and not a hardware problem, though you should probably think about migrating your data off to a new drive sometime soon. Yeah, ordered a replacement drive today. I'd like to attack these driver problems. What I need is to spend a couple of days with an affected system that can reliably reproduce the problem, instrumenting and testing the driver. I have a number of theories about what might be going wrong, but nothing that I'm definitely sure about. If you are willing to set up your system with remote power and remote serial, and if we knew a reliable way to reproduce the problem, I could probably have the problem identified and fixed pretty quickly. Hrm... if my ISP allows multiple PPPoE sessions, the remote serial shouldn't be a problem. Remote power though... would my idling in IRC and you poking me whenever you want the power state changed work? I'm not completely certain it's even possible to turn the system in question off short of the physical power switch and even if it is, I'm positive that it's not possible to turn it back on again since there is no power switch header on the motherboard. If I *can* get multiple PPPoE sessions running, the setup would be SSHing to a FreeBSD-sparc64 system with a serial and network connection to the affected system. I could give you root access on one or both boxes as needed. I would want you to make me feel a bit more comfortable about letting someone play with the ata driver on a system with a known flakey HD. Some kinda of "It's super-duper unlikely that I would thrash the FS" thing since I won't be able to put the new HD in for a week or two and I have the usual home system backup plan in place (that is, I plan on backing up someday...) I'll try setting up the extra PPPoE session now (since I'm curious about it anyways) and get back to you on that detail. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 7.0-RELEASE Available
Ken Smith <[EMAIL PROTECTED]> writes: [...] > http://www.freebsd.org/releases/7.0R/announce.html > > On behalf of the FreeBSD Project thanks for your interest in FreeBSD. > We hope you enjoy the new release. > Thanks for all your work (done and to be done). Dirk ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 7, Razer Copperhead mouse patch
Hi this patch works (console, mousepointer) but it doesn't work in X. ums0: on uhub0 ums0: 7 buttons and Z dir. ukbd1: o n uhub0 kbd3 at ukbd1 --- AUDIT: Wed Feb 27 23:36:12 2008: 1149 X: client 1 rejected from local host (uid 1001) Auth name: MIT-MAGIC-COOKIE-1 ID: -1 Xlib: connection to ":0.0" refused by server Xlib: Invalid MIT-MAGIC-COOKIE-1 key waiting for X server to begin accepting connections . AUDIT: Wed Feb 27 23:36:14 2008: 1149 X: client 1 rejected from local host (uid 1001) Auth name: MIT-MAGIC-COOKIE-1 ID: -1 Xlib: connection to ":0.0" refused by server Xlib: Invalid MIT-MAGIC-COOKIE-1 key --- So I cannot use the Razer (or any other mouse) in X with this patch. --Oliver John Baldwin <[EMAIL PROTECTED]> wrote: > On Saturday 23 February 2008 03:32:41 pm Dominic Fandrey wrote: > > Oliver Herold wrote: > > > Hi > > > > > > the Razer Copperhead mouse did work in FreeBSD 7 (current) for a long > > > time, but after some period it stopped working. This patch from Uwe > > > Grohnwaldt: > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/118670 > > > > > > fixes this wrong behaviour (it's detected as keyboard) and makes the > > > mouse work in FreeBSD 7 again. Would be imho a nice addition for > > > RELENG_7 (stable) or even Release. > > > > > > Cheers, Oliver > > > > Being a Razer fan and user I totally agree. > > Can you try this patch instead? > > Index: ums.c > === > RCS file: /usr/cvs/src/sys/dev/usb/ums.c,v > retrieving revision 1.97 > diff -u -r1.97 ums.c > --- ums.c 26 Dec 2007 14:31:16 - 1.97 > +++ ums.c 27 Feb 2008 21:40:48 - > @@ -198,7 +198,10 @@ > if (err) > return (UMATCH_NONE); > > - if (id->bInterfaceClass == UICLASS_HID && > + if (hid_is_collection(desc, size, > + HID_USAGE2(HUP_GENERIC_DESKTOP, HUG_MOUSE))) > + ret = UMATCH_IFACECLASS; > + else if (id->bInterfaceClass == UICLASS_HID && > id->bInterfaceSubClass == UISUBCLASS_BOOT && > id->bInterfaceProtocol == UIPROTO_MOUSE) > ret = UMATCH_IFACECLASS; > > -- > John Baldwin -- When you have an efficient government, you have a dictatorship. -- Harry S. Truman pgpy3JWkhf3fb.pgp Description: PGP signature
FreeBSD 7.0-RELEASE Available
Just in case some interested parties are not subscribed to the freebsd-announce mailing list... FreeBSD 7.0-RELEASE has been formally released. If you would like to see the release announcement it's here: http://www.freebsd.org/releases/7.0R/announce.html On behalf of the FreeBSD Project thanks for your interest in FreeBSD. We hope you enjoy the new release. -- Ken Smith - From there to here, from here to | [EMAIL PROTECTED] there, funny things are everywhere. | - Theodore Geisel | signature.asc Description: This is a digitally signed message part
Re: Problems with promise SATA300 TX2Plus
Jisakiel wrote: > Greetings. I was trying to install FreeBSD 7 on an old machine to make it a > fileserver. Machine is an AMD K7 1200 on an Abit AN-7 mobo (nforce2 400), > which has booted Freebsd 7.0 RC1 beforehand (for testing ZFS; only ACPI > didn't work as it hung it). > > I recently bought a PCI SATA card on the cheap variety, Promise SATA300 > TX2Plus, and a couple of 500GB Maxtors. Unfortunately, when any hard drive > (both of the 500's and an older 250 Maxtor which I use) is plugged to the > SATA ports of the pci card I get an instantaneous reboot when trying to boot > the bootonly cd (it doesn't reach the bootloader). If no disks are plugged it > works but hangs while booting (with ACPI disabled). > > Things I tried: > > - Booting another OS. Card works perfectly both in linux (2.6.24) and > windows, with the two hard drives visible. > - Leaving just one SATA drive connected to the whole system through the PCI > card. It doesn't matter which drive I let, both the 250G and the 500G make it > reboot. > - Swapping the power cable. > - Unplugging my former 2 drives to ease the load on the Enermax 365W power > supply. It works in Windows though, with everything on... > - Disabling both integrated SATA of the motherboard (SI3112 which works both > in linux and freebsd), and integrated firewire (just in case). > - Moving the PCI card to another slot. I only have another pci device, a > soundcard, and moving it changed the bios boot order (first the pci, then the > integrated sata or viceversa) with no change at all afterwards. > - Trying 6.3 livecd. Same insta-reboot. > - Updating the card's bios. There is no newer one, 1.0.0.34 is what came and > what's on the promise web. > > Is there any way to make this card work on FreeBSD 7, or anything else that I > could try? I bought it specifically for that; I might be in time to return > it, though I'd have to buy another one on the same price range then (perhaps > Promise FastTrak TX2300, HightPoint RocketRaid 1520 or Adaptec 1210SA which I > seem to recall that doesn't work too well on linux). Otherwise I'd be more > than willing to help debugging it ^^. > > Thanks everybody... > > > [EMAIL PROTECTED] > For what its worth, I have a RocketRaid 1520 in my fileserver at home that I've been using for over a year without any problems: atapci0: port 0xff00-0xff07,0xfe00-0xfe03 ,0xfd00-0xfd07,0xfc00-0xfc03,0xec00-0xecff irq 17 at device 8.0 on pci0 ata2: on atapci0 ata3: on atapci0 ... ad4: 286168MB at ata2-master UDMA133 ad6: 286168MB at ata3-master UDMA133 ar0: 286168MB status: READY -Proto ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 7, Razer Copperhead mouse patch
On Saturday 23 February 2008 03:32:41 pm Dominic Fandrey wrote: > Oliver Herold wrote: > > Hi > > > > the Razer Copperhead mouse did work in FreeBSD 7 (current) for a long > > time, but after some period it stopped working. This patch from Uwe > > Grohnwaldt: > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/118670 > > > > fixes this wrong behaviour (it's detected as keyboard) and makes the > > mouse work in FreeBSD 7 again. Would be imho a nice addition for > > RELENG_7 (stable) or even Release. > > > > Cheers, Oliver > > Being a Razer fan and user I totally agree. Can you try this patch instead? Index: ums.c === RCS file: /usr/cvs/src/sys/dev/usb/ums.c,v retrieving revision 1.97 diff -u -r1.97 ums.c --- ums.c 26 Dec 2007 14:31:16 - 1.97 +++ ums.c 27 Feb 2008 21:40:48 - @@ -198,7 +198,10 @@ if (err) return (UMATCH_NONE); - if (id->bInterfaceClass == UICLASS_HID && + if (hid_is_collection(desc, size, + HID_USAGE2(HUP_GENERIC_DESKTOP, HUG_MOUSE))) + ret = UMATCH_IFACECLASS; + else if (id->bInterfaceClass == UICLASS_HID && id->bInterfaceSubClass == UISUBCLASS_BOOT && id->bInterfaceProtocol == UIPROTO_MOUSE) ret = UMATCH_IFACECLASS; -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ldconfig -R issue (Was: Problems with icu - 3.8)
On Monday 18 February 2008 05:10:24 am Sergey Matveychuk wrote: > +stable@ > > Yoshihiro Ota wrote: > > Why are so many people are bitten by this? Is that the jobs of port-upgrading > > tool to safe copy these libraries to compat so that all programs using > > the old libraries works? > > Portupgrade preserves the libraries in /usr/local/lib/compat/pkg: > % ls /usr/local/lib/compat/pkg/ > libicudata.so.36.0 libicule.so.36.0libicuuc.so.36.0 > libicui18n.so.36.0 libiculx.so.36.0 > libicuio.so.36.0libicutu.so.36.0 > > ldconfig knows about the directory: > % ldconfig -r | head -2 > /var/run/ld-elf.so.hints: > search directories: > /lib:/usr/lib:/usr/lib/compat:/usr/X11R6/lib:/usr/local/lib:/usr/local/lib/mysql:/usr/local/lib/compat/pkg > > But ldconfig -R don't rescan them: > % ldconfig -R > % ldconfig -r | grep libicudata > 231:-licudata.38 => /usr/X11R6/lib/libicudata.so.38 > 386:-licudata.38 => /usr/local/lib/libicudata.so.38 > > Could anybody investigate it? I have no time now. Drop the .0 from the filenames or add libfoo.so.36 symlinks. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Tar regression from 6.2 to 6.3 with --strip-components
Tim Kientzle wrote: > Please file this in a PR so I won't lose > track. I don't have time to investigate this > right now, but I should be able to get to it > sometime next week. Filed as PR bin/121158. Thanks! Jan. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Problems with promise SATA300 TX2Plus
Greetings. I was trying to install FreeBSD 7 on an old machine to make it a fileserver. Machine is an AMD K7 1200 on an Abit AN-7 mobo (nforce2 400), which has booted Freebsd 7.0 RC1 beforehand (for testing ZFS; only ACPI didn't work as it hung it). I recently bought a PCI SATA card on the cheap variety, Promise SATA300 TX2Plus, and a couple of 500GB Maxtors. Unfortunately, when any hard drive (both of the 500's and an older 250 Maxtor which I use) is plugged to the SATA ports of the pci card I get an instantaneous reboot when trying to boot the bootonly cd (it doesn't reach the bootloader). If no disks are plugged it works but hangs while booting (with ACPI disabled). Things I tried: - Booting another OS. Card works perfectly both in linux (2.6.24) and windows, with the two hard drives visible. - Leaving just one SATA drive connected to the whole system through the PCI card. It doesn't matter which drive I let, both the 250G and the 500G make it reboot. - Swapping the power cable. - Unplugging my former 2 drives to ease the load on the Enermax 365W power supply. It works in Windows though, with everything on... - Disabling both integrated SATA of the motherboard (SI3112 which works both in linux and freebsd), and integrated firewire (just in case). - Moving the PCI card to another slot. I only have another pci device, a soundcard, and moving it changed the bios boot order (first the pci, then the integrated sata or viceversa) with no change at all afterwards. - Trying 6.3 livecd. Same insta-reboot. - Updating the card's bios. There is no newer one, 1.0.0.34 is what came and what's on the promise web. Is there any way to make this card work on FreeBSD 7, or anything else that I could try? I bought it specifically for that; I might be in time to return it, though I'd have to buy another one on the same price range then (perhaps Promise FastTrak TX2300, HightPoint RocketRaid 1520 or Adaptec 1210SA which I seem to recall that doesn't work too well on linux). Otherwise I'd be more than willing to help debugging it ^^. Thanks everybody... [EMAIL PROTECTED] - ¿Con Mascota por primera vez? - Sé un mejor Amigo Entra en Yahoo! Respuestas. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [solved/workaround?] Re: em very slow, shared irq... on 6.3p8
On Wed, Feb 27, 2008 at 12:16:27PM -0800, Jack Vogel wrote: > > Hmmm, something is really broken here that POLL just is just bypassing, > what was the adapter type exactly (pciconf -l). Sorry, but I must have > missed this email earlier. Problem is with em0-em13 that many share an IRQ 16/17, and because I was using 6.2-p8 and therefore did not have MSI enabled/available. Polling was also not compiled into the kernel. Polling alone will give times between 0.2 and 1.3 ms (with HZ=1000), and MSI alone (after activated during boot within loader.conf) will give best results (around 0.4 to 0.5 ms for a ping through firewall and back across two lans). This was then with 6.3-p1 Still, 6.3-p1 without msi and polling is still very slow in handling IRQs from the em-nics. I still don't know exactly why this took up to 1.5 seconds (sometimes even more) without MSI or POLLING. Please see my previous emails for dmesg. pciconf -l gives: [EMAIL PROTECTED]:4:0: class=0x02 card=0x11998086 chip=0x10b58086 rev=0x03 hdr=0x00 [EMAIL PROTECTED]:4:1: class=0x02 card=0x11998086 chip=0x10b58086 rev=0x03 hdr=0x00 [EMAIL PROTECTED]:6:0: class=0x02 card=0x11998086 chip=0x10b58086 rev=0x03 hdr=0x00 [EMAIL PROTECTED]:6:1: class=0x02 card=0x11998086 chip=0x10b58086 rev=0x03 hdr=0x00 [EMAIL PROTECTED]:0:0: class=0x02 card=0x10a48086 chip=0x10a48086 rev=0x06 hdr=0x00 [EMAIL PROTECTED]:0:1: class=0x02 card=0x10a48086 chip=0x10a48086 rev=0x06 hdr=0x00 [EMAIL PROTECTED]:0:0: class=0x02 card=0x10a48086 chip=0x10a48086 rev=0x06 hdr=0x00 [EMAIL PROTECTED]:0:1: class=0x02 card=0x10a48086 chip=0x10a48086 rev=0x06 hdr=0x00 [EMAIL PROTECTED]:0:0: class=0x02 card=0x10a48086 chip=0x10a48086 rev=0x06 hdr=0x00 [EMAIL PROTECTED]:0:1: class=0x02 card=0x10a48086 chip=0x10a48086 rev=0x06 hdr=0x00 [EMAIL PROTECTED]:0:0: class=0x02 card=0x10a48086 chip=0x10a48086 rev=0x06 hdr=0x00 [EMAIL PROTECTED]:0:1: class=0x02 card=0x10a48086 chip=0x10a48086 rev=0x06 hdr=0x00 [EMAIL PROTECTED]:0:0: class=0x02 card=0x108c15d9 chip=0x108c8086 rev=0x03 hdr=0x00 [EMAIL PROTECTED]:0:0: class=0x02 card=0x109a15d9 chip=0x109a8086 rev=0x00 hdr=0x00 We have one quad PCI-X 64bit card (the first four) and two quad PCI-Express cards. The last two devices are on-board ports. device = '82546GB PRO/1000 GT Quad Port Server Adapter' device = '82546GB PRO/1000 GT Quad Port Server Adapter' device = '82546GB PRO/1000 GT Quad Port Server Adapter' device = '82546GB PRO/1000 GT Quad Port Server Adapter' device = '82571EB Gigabit Ethernet Controller' device = '82571EB Gigabit Ethernet Controller' device = '82571EB Gigabit Ethernet Controller' device = '82571EB Gigabit Ethernet Controller' device = '82571EB Gigabit Ethernet Controller' device = '82571EB Gigabit Ethernet Controller' device = '82571EB Gigabit Ethernet Controller' device = '82571EB Gigabit Ethernet Controller' device = '82573E Intel Corporation 82573E Gigabit Ethernet Controller (Copper)' device = '82573L Intel PRO/1000 PL Network Adaptor' Is this helpful? Please let me know if you need anything else. Best regards, Holger Kipp ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [solved/workaround?] Re: em very slow, shared irq... on 6.3p8
On Wed, Feb 27, 2008 at 11:50 AM, Holger Kipp <[EMAIL PROTECTED]> wrote: > On Wed, Feb 27, 2008 at 09:50:16AM -0500, Mike Tancsa wrote: > > more details below. as it currently is, polling seems to do > the trick, however handling several em-interfaces with the > same irq (mind you, it is pci) shouldn't cause delays of > up to 1.5 seconds for a simple ping... Therefore I consider > using polling for a nearly idle system more a workaround > than a solution to this problem :-( > > > At 05:49 AM 2/27/2008, Holger Kipp wrote: > > > > >I therefore assume that the problem is between receiving the > > >irq from em and getting the data from the interface on the firewall > > >itself. > > > > I would try upgrading to 6.3R (there are several em driver bug fixes) > done. system is now 6.3-RELEASE-p1 which also gave me -c option for pciconf > and msi syscontrols (were missing in the old 6.2). > > > > and then try the box with > > % cat /boot/loader.conf > > hw.pci.enable_msi=1 > > > > ...if the cards support msi. > > > > I think pciconf -lvc should tell you if the cards and slots support it or > > not. > > pciconf -lvc says for all em: > cap 05[d0] = MSI supports 1 message, 64 bit > so I assume they do support MSI. > > with msi disabled I get > > 38 packets transmitted, 38 packets received, 0% packet loss > round-trip min/avg/max/stddev = 4.833/228.022/1539.337/339.768 ms > > with msi enabled (via sysctl) I get > > 33 packets transmitted, 33 packets received, 0% packet loss > round-trip min/avg/max/stddev = 1.865/156.421/1339.841/239.375 ms > > so looks equally bad (I don't consider 30-40 packets a meaningful sample). > I don't know if it makes any differences if switched on directly in > loader.conf, though. > > enabling polling (withous MSI) gives > > 30 packets transmitted, 30 packets received, 0% packet loss > round-trip min/avg/max/stddev = 0.366/0.790/1.339/0.290 ms > > (maybe I should have used HZ=2000 to keep it below 0.6ms ;-) > > > Also, if you dont need IPV6, use FAST_IPSEC. It does not need > > mpsafe. If you do need IPSEC and IPV6, 7.0R got rid of that restriction. > > I think this enough changes in one go for a production system ;-) Hmmm, something is really broken here that POLL just is just bypassing, what was the adapter type exactly (pciconf -l). Sorry, but I must have missed this email earlier. Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ad0 READ_DMA TIMEOUT errors on install of 7.0-RELEASE
Stephen Hurd wrote: This shows you've had 4 reallocated sectors, meaning your disk does in fact have bad blocks. In 90% of the cases out there, bad blocks continue to "grow" over time, due to whatever reason (I remember reading an article explaining it, but I can't for the life of me find the URL). This is unusual now? I've always "known" that a small number of bad blocks is normal. Time to readjust my knowledge again? Modern drives hide bad sectors by keeping a pool of spare tracks and automatically remapping bad sectors to that pool. The problem lies in when the drive has aged enough that it's run out of spares. 194 Temperature_Celsius 0x0032 253 253 000Old_age Always - 48 This is excessive, and may be attributing to problems. A hard disk running at 48C is not a good sign. This should really be somewhere between high 20s and mid 30s. Yeah, this is a known problem with this drive... it's been running hot for years. I always figured it was due to the rotational speed increase in commodity drives. 48C is high, but I wouldn't consider it excessive. Drives that start generating "excessive" heat tend to fail shortly thereafter. I do agree that the heat is probably shortening the lifespan on the drive. Error 2 occurred at disk power-on lifetime: 5171 hours (215 days + 11 hours) When the command that caused the error occurred, the device was in an unknown state. Error 1 occurred at disk power-on lifetime: 5171 hours (215 days + 11 hours) When the command that caused the error occurred, the device was in an unknown state. These are automated SMART log entries confirming the DMA failures. The fact that SMART saw them means that the disk is also aware of said issues. These may have been caused by the reallocated sectors. It's also interesting that the LBAs are different than the ones FreeBSD reported issues with. If that power on lifetime is accurate, that was at least a year ago... but I can't find any documentation as to when the power-on lifetime wraps or what it actually indicates. I'm assuming that it is total power on time since the drive was manufactured. If it's total hours as a 16-bit integer, it shouldn't wrap. Is there a way of getting the "current" power-on lifetime value that you're aware of? That power on minutes is interesting, but its current value is lower than the value at the error (but higher than the power uptime of the system): 9 Power_On_Minutes0x0032 219 219 000Old_age Always - 1061h+40m Also interesting is that after getting more errors from FreeBSD, I did not get more errors in smartctl. The errors you're getting from FreeBSD have nothing to do directly with SMART. The driver thinks that commands are timing out and that the drive is becoming unresponsive. Whether they actually are is another question. Given that this problem changes behavior with the version of FreeBSD that you're running (and even happens in completely virtual environments like vmware) I'm betting that it's a driver problem and not a hardware problem, though you should probably think about migrating your data off to a new drive sometime soon. I'd like to attack these driver problems. What I need is to spend a couple of days with an affected system that can reliably reproduce the problem, instrumenting and testing the driver. I have a number of theories about what might be going wrong, but nothing that I'm definitely sure about. If you are willing to set up your system with remote power and remote serial, and if we knew a reliable way to reproduce the problem, I could probably have the problem identified and fixed pretty quickly. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [solved!] Re: em very slow, shared irq... on 6.2p8
At 03:09 PM 2/27/2008, Holger Kipp wrote: On Wed, Feb 27, 2008 at 08:50:58PM +0100, Holger Kipp wrote: > On Wed, Feb 27, 2008 at 09:50:16AM -0500, Mike Tancsa wrote: > > more details below. as it currently is, polling seems to do > the trick, however handling several em-interfaces with the > same irq (mind you, it is pci) shouldn't cause delays of > up to 1.5 seconds for a simple ping... Therefore I consider > using polling for a nearly idle system more a workaround > than a solution to this problem :-( [...] > with msi enabled (via sysctl) I get > > 33 packets transmitted, 33 packets received, 0% packet loss > round-trip min/avg/max/stddev = 1.865/156.421/1339.841/239.375 ms > > so looks equally bad (I don't consider 30-40 packets a meaningful sample). > I don't know if it makes any differences if switched on directly in > loader.conf, though. have now activated msi in loader.conf and get very good results again. 38 packets transmitted, 38 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.291/0.425/0.595/0.067 ms without polling activated. So it was msi after all I needed here. Maybe this should go into docu for em or ifconfig? Hi, Yes, sorry I should have mentioned, you need to reboot. But I strongly suggest upgrading to 6.3R as there are a number of em bugs that are fixed Perhaps some IRQ issues as well. But for MSI in general, I think the Intel guy recommended running that way for the NIC. ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [solved!] Re: em very slow, shared irq... on 6.2p8
On Wed, Feb 27, 2008 at 08:50:58PM +0100, Holger Kipp wrote: > On Wed, Feb 27, 2008 at 09:50:16AM -0500, Mike Tancsa wrote: > > more details below. as it currently is, polling seems to do > the trick, however handling several em-interfaces with the > same irq (mind you, it is pci) shouldn't cause delays of > up to 1.5 seconds for a simple ping... Therefore I consider > using polling for a nearly idle system more a workaround > than a solution to this problem :-( [...] > with msi enabled (via sysctl) I get > > 33 packets transmitted, 33 packets received, 0% packet loss > round-trip min/avg/max/stddev = 1.865/156.421/1339.841/239.375 ms > > so looks equally bad (I don't consider 30-40 packets a meaningful sample). > I don't know if it makes any differences if switched on directly in > loader.conf, though. have now activated msi in loader.conf and get very good results again. 38 packets transmitted, 38 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.291/0.425/0.595/0.067 ms without polling activated. So it was msi after all I needed here. Maybe this should go into docu for em or ifconfig? > enabling polling (withous MSI) gives > > 30 packets transmitted, 30 packets received, 0% packet loss > round-trip min/avg/max/stddev = 0.366/0.790/1.339/0.290 ms this is still the same with msi activated in loader.conf Best regards, Holger Kipp ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fsck_ufs: cannot alloc 94208 bytes for inoinfo
fsck's memory usage is directly related to the number of inodes and the number of directories in the filesystem. Directories are particularly memory intensive. I've found on my backup system that a UFS1 filesystem with 40 million inodes is about the limit that can be fsck'd (at least with a 32 bit architecture). My cron jobs keep my backup partition below that point. Even in a 64 bit environment you will be limited by swap and the sheer time it takes for fsck to run. It takes well over 8 hours for my backup system to fsck. You can also reduce fsck time by reducing the number of cylinder groups on the disk. I usually max them out (-c 999 and newfs then sets it to the maximum, usually in the 50-80 range). This will improve performance but not reduce the memory required. -Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[solved/workaround?] Re: em very slow, shared irq... on 6.3p8
On Wed, Feb 27, 2008 at 09:50:16AM -0500, Mike Tancsa wrote: more details below. as it currently is, polling seems to do the trick, however handling several em-interfaces with the same irq (mind you, it is pci) shouldn't cause delays of up to 1.5 seconds for a simple ping... Therefore I consider using polling for a nearly idle system more a workaround than a solution to this problem :-( > At 05:49 AM 2/27/2008, Holger Kipp wrote: > > >I therefore assume that the problem is between receiving the > >irq from em and getting the data from the interface on the firewall > >itself. > > I would try upgrading to 6.3R (there are several em driver bug fixes) done. system is now 6.3-RELEASE-p1 which also gave me -c option for pciconf and msi syscontrols (were missing in the old 6.2). > and then try the box with > % cat /boot/loader.conf > hw.pci.enable_msi=1 > > ...if the cards support msi. > > I think pciconf -lvc should tell you if the cards and slots support it or > not. pciconf -lvc says for all em: cap 05[d0] = MSI supports 1 message, 64 bit so I assume they do support MSI. with msi disabled I get 38 packets transmitted, 38 packets received, 0% packet loss round-trip min/avg/max/stddev = 4.833/228.022/1539.337/339.768 ms with msi enabled (via sysctl) I get 33 packets transmitted, 33 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.865/156.421/1339.841/239.375 ms so looks equally bad (I don't consider 30-40 packets a meaningful sample). I don't know if it makes any differences if switched on directly in loader.conf, though. enabling polling (withous MSI) gives 30 packets transmitted, 30 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.366/0.790/1.339/0.290 ms (maybe I should have used HZ=2000 to keep it below 0.6ms ;-) > Also, if you dont need IPV6, use FAST_IPSEC. It does not need > mpsafe. If you do need IPSEC and IPV6, 7.0R got rid of that restriction. I think this enough changes in one go for a production system ;-) many thanks for the recommendations! Best regards, Holger ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ad0 READ_DMA TIMEOUT errors on install of 7.0-RELEASE
Stephen Hurd wrote: Jeremy Chadwick wrote: SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0033 253 253 063Pre-fail Always - 4 This shows you've had 4 reallocated sectors, meaning your disk does in fact have bad blocks. In 90% of the cases out there, bad blocks continue to "grow" over time, due to whatever reason (I remember reading an article explaining it, but I can't for the life of me find the URL). This is unusual now? I've always "known" that a small number of bad blocks is normal. Time to readjust my knowledge again? I have bought disks where the value of Reallocated_Sector_Ct was not 0, at least by the time I looked at it with smartctl. Nothing bad has happened to those disks in several years (hope that's not tempting fate). I have always assumed that what matters is when this value *changes*. If it's not changing, who cares? smartd will monitor disks and email you when certain attributes change (e.g. Pre-fail attributes like Reallocated_Sector_Ct). If it changed, it would mean that an attempt to write data had failed and that reallocation had happened. e.g. from smartd.conf /dev/ad4 -o on -S on -a -m root -M daily If your Current_Pending_Sector were non-zero you'd be in trouble, I believe. 0.02, pinch of salt, not an expert, slippery when hot, long time since I read the specs, etc etc. --Alex ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Tar regression from 6.2 to 6.3 with --strip-components
I've just noticed a regression in tar from 6.2 to 6.3: Running this on 6.2 produces no output: #!/bin/sh mkdir -p a b output touch a/file1 b/file2 tar cf test.tar a b tar -x -C output --strip-components 1 -f test.tar On 6.3, it produces this output: : Invalid empty pathname : Invalid empty pathname tar: Error exit delayed from previous errors. Please file this in a PR so I won't lose track. I don't have time to investigate this right now, but I should be able to get to it sometime next week. Tim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ad0 READ_DMA TIMEOUT errors on install of 7.0-RELEASE
On Wed, Feb 27, 2008 at 10:32:48AM -0800, Stephen Hurd wrote: > Booting the 6.3-RELEASE CD seems to make the problem go away... possibly > 7.0 stresses the HD more? We don't know. The author of the ATA subsystem is somewhat MIA, likely busy with real-life things (jobs, etc.). My main point was that you're not alone with DMA timeouts and other oddities, but the reallocated sector count being non-zero doesn't permit me to say "Yeah, you're experiencing what others are". >>> SMART Attributes Data Structure revision number: 16 >>> Vendor Specific SMART Attributes with Thresholds: >>> ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED >>> WHEN_FAILED RAW_VALUE >>> 5 Reallocated_Sector_Ct 0x0033 253 253 063Pre-fail Always >>> - 4 >> >> This shows you've had 4 reallocated sectors, meaning your disk does in >> fact have bad blocks. In 90% of the cases out there, bad blocks >> continue to "grow" over time, due to whatever reason (I remember reading >> an article explaining it, but I can't for the life of me find the URL). > > This is unusual now? I've always "known" that a small number of bad blocks > is normal. Time to readjust my knowledge again? This isn't normal. The realloc sector count in SMART, when a disk comes out of the factory, is zero. That number increases only when new defects are found, and when those sectors are remapped to spares which are available (there is a limited number of spares). This is also called a "grown defect list". This isn't to be confused with what's called a "physical defect list", which are known sectors/LBAs which are bad, straight out of the factory. On ATA disks, the manufacturer stores the list in the drive and its not modifiable via formatting or even a BIOS-based format (e.g. a SATA RAID controller); some vendors do implement "low level formatting" via undocumented ATA commands, which can erase that list, but that's besides the point. On SCSI disks, the physical defect list is readable and also erasable via a low-level format, but SCSI disks also have a grown defect list which is separate. What I'm trying to say is that your disk already has 4 bad blocks that the disk firmware itself is aware of, which means chances are there are others which it hasn't figured out. A high number of ECCs could indicate that as well. >>> 194 Temperature_Celsius 0x0032 253 253 000Old_age Always >>> - 48 >> >> This is excessive, and may be attributing to problems. A hard disk >> running at 48C is not a good sign. This should really be somewhere >> between high 20s and mid 30s. > > Yeah, this is a known problem with this drive... it's been running hot for > years. I always figured it was due to the rotational speed increase in > commodity drives. 7200rpm disks shouldn't be running at 48C. None of my 7200rpm disks, in my barely-cooled FreeBSD box at home (e.g. two 1100rpm fans and that's it) get anywhere near that. 36C is the highest they've seen -- and there's 4 stacked right on top of one another. Heck, on my disks, the SMART warning threshold (set by the manufacturer, which is Western Digital) is 45C. 10krpm disks probably run hotter, but are not commodity. >>> Error 2 occurred at disk power-on lifetime: 5171 hours (215 days + 11 >>> hours) >>> When the command that caused the error occurred, the device was in an >>> unknown state. >>> Error 1 occurred at disk power-on lifetime: 5171 hours (215 days + 11 >>> hours) >>> When the command that caused the error occurred, the device was in an >>> unknown state. >> >> These are automated SMART log entries confirming the DMA failures. The >> fact that SMART saw them means that the disk is also aware of said >> issues. These may have been caused by the reallocated sectors. It's >> also interesting that the LBAs are different than the ones FreeBSD >> reported issues with. > > If that power on lifetime is accurate, that was at least a year ago... but > I can't find any documentation as to when the power-on lifetime wraps or > what it actually indicates. I'm assuming that it is total power on time > since the drive was manufactured. Correct: it indicates how many hours the drive itself has been powered on as an aggregate total. E.g. if powered on for 48 hours, then shut off for 3 hours, then powered on for another 7, the stat would read 55 hours. > If it's total hours as a 16-bit integer, it shouldn't wrap. Is there a way > of getting the "current" power-on lifetime value that you're aware of? I would have to go look at the SMART extension to ATA/SATA and find out how large the counter is. It probably varies from vendor to vendor too, as SMART, despite being a standard, has a lot of "loose ends" in the specification which vendors take advantage of. > That power on minutes is interesting, but its current value is lower > than the value at the error (but higher than the power uptime of the > system): > 9 Power_On_Minutes
Re: Documentation of NO_* knobs
Hello, On Wed, Feb 27, 2008 at 09:18:31AM -0800, Jeremy Chadwick wrote: > I think you're looking for all the WITHOUT knobs in src.conf(5). I'm running RELENG_6_3 on production machines unlikely to change any time real soon. > Note that src.conf(5) does not apply to RELENG_6 or earlier, where the > knobs are named NO_xxx. You can get a list of those from > /usr/share/examples/etc/make.conf. I knew about that file. NO_SYSCONS and NO_EXAMPLES are neither in this one nor in the manpage for make.conf. Yet they are in the handbook example for NanoBSD builds. That's why I'm asking for the "official" exhaustive list. Thanks for taking the time to answer, Patrick -- punkt.de GmbH * Vorholzstr. 25 * 76137 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 [EMAIL PROTECTED] http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fsck_ufs: cannot alloc 94208 bytes for inoinfo
Olivier Mueller wrote: > "fsck_ufs: cannot alloc 94208 bytes for inoinfo" > > This is what I get after about one hour while trying a fsck on a large > (1.4TB) partition "broken" since a power outage. > > HW: HP DL380G5, under freebsd 6.1/i386, with 1GB of RAM and: Your fsck will need roughly 1 GB memory per 1 TB file system size. That formular was posted some time ago on the -fs mailing list. It only applies with the default newfs parameters -- if you used other parameters (inode density, bsize/fsize), fsck's memory requirements are different. > Now I added this to the /boot/loader.conf: > kern.maxdsiz="1073741824" # 1GB > kern.dfldsiz="1073741824" # 1GB > and I'm trying the fsck again, but I'm not sure it will help. Given the above formula, it's probably not enough, so you might have to increase it further. Also make sure that you have enough swap space. If you have a spare box, it might be helpful to transplant some RAM from it so fsck doesn't have to swap. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor, and when was the last time you needed one?" -- Tom Cargil, C++ Journal ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ad0 READ_DMA TIMEOUT errors on install of 7.0-RELEASE
Jeremy Chadwick wrote: And after the reboot, the READ_DMA timeouts were back. You're not the only one seeing this behaviour. There are too many posts in the past reporting similar. Here's the breakdown: * Some have switched to alternate operating systems (usually Linux) for a short while and seen no sign of DMA timeouts. Booting the 6.3-RELEASE CD seems to make the problem go away... possibly 7.0 stresses the HD more? However: in your case, your disk does look to have problems based on the SMART output you provided. It does not matter how new/old the disk is, by the way. I'll point out the problematic stats. You need to replace the disk ASAP. Yeah, that's pretty much what I figured, the timing (ie: the moment I boot 7.0-RELEASE) is the only bit that seems fishy. This HD has been powered on pretty much continuously for around three years. Given that it's a Maxtor, I'm honestly a bit surprised that it's lasted as well as it has. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0033 253 253 063Pre-fail Always - 4 This shows you've had 4 reallocated sectors, meaning your disk does in fact have bad blocks. In 90% of the cases out there, bad blocks continue to "grow" over time, due to whatever reason (I remember reading an article explaining it, but I can't for the life of me find the URL). This is unusual now? I've always "known" that a small number of bad blocks is normal. Time to readjust my knowledge again? 194 Temperature_Celsius 0x0032 253 253 000Old_age Always - 48 This is excessive, and may be attributing to problems. A hard disk running at 48C is not a good sign. This should really be somewhere between high 20s and mid 30s. Yeah, this is a known problem with this drive... it's been running hot for years. I always figured it was due to the rotational speed increase in commodity drives. Error 2 occurred at disk power-on lifetime: 5171 hours (215 days + 11 hours) When the command that caused the error occurred, the device was in an unknown state. Error 1 occurred at disk power-on lifetime: 5171 hours (215 days + 11 hours) When the command that caused the error occurred, the device was in an unknown state. These are automated SMART log entries confirming the DMA failures. The fact that SMART saw them means that the disk is also aware of said issues. These may have been caused by the reallocated sectors. It's also interesting that the LBAs are different than the ones FreeBSD reported issues with. If that power on lifetime is accurate, that was at least a year ago... but I can't find any documentation as to when the power-on lifetime wraps or what it actually indicates. I'm assuming that it is total power on time since the drive was manufactured. If it's total hours as a 16-bit integer, it shouldn't wrap. Is there a way of getting the "current" power-on lifetime value that you're aware of? That power on minutes is interesting, but its current value is lower than the value at the error (but higher than the power uptime of the system): 9 Power_On_Minutes0x0032 219 219 000Old_age Always - 1061h+40m Also interesting is that after getting more errors from FreeBSD, I did not get more errors in smartctl. My advice to you is: replace the disk ASAP. This problem will only get worse. Try another hard disk brand too (I don't have anything "against" Maxtor, but usually its recommended to avoid a brand you have problems with until the next time you have issues, then switch brands, etc. etc...). I'm very fond of Western Digital's SE16, RE, and RE2 series currently. But avoid Fujitsu and Samsung (both have a long track record of having buggy drive firmwares, forcing vendors to make custom workarounds for issues); stick with Seagate, Western Digital, or Maxtor. Yeah, that's my plan... but I wanted to stake out some whining rights in advance so I can do the "But you said it was a bad HD or cable! Now I'm out $x00 and my system still doesn't work! Help me or I switch to DragonFly BSD/Desktop BSD/Linux which is perfect and has no problems!" thing. Then go on Slashdot and post long rambling messages about how FreeBSD is dead and it doesn't matter than the manpages on any given Linux box are useless. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Documentation of NO_* knobs
On Wed, Feb 27, 2008 at 05:32:55PM +0100, Patrick M. Hausen wrote: > is there an exhaustive list of all possible NO_* knobs > for make.conf? While experimenting with NanoBSD I found > e.g. that the handbook > - just two out of many. Yet, these are not in the manpage of > make.conf(5) on a 6.3-RELEASE. So, where did the handbook > author find them? I think you're looking for all the WITHOUT knobs in src.conf(5). Starting with RELENG_7, all of the NO knobs for removal of features in the base system were moved into /etc/src.conf and renamed to WITHOUT. Some may also have changed names, so look closely. Note that src.conf(5) does not apply to RELENG_6 or earlier, where the knobs are named NO_xxx. You can get a list of those from /usr/share/examples/etc/make.conf. Hope this helps. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Documentation of NO_* knobs
Hi, all, is there an exhaustive list of all possible NO_* knobs for make.conf? While experimenting with NanoBSD I found e.g. that the handbook http://www.freebsd.org/doc/en_US.ISO8859-1/articles/nanobsd/index.html mentions NO_EXAMPLES NO_SYSCONS ... - just two out of many. Yet, these are not in the manpage of make.conf(5) on a 6.3-RELEASE. So, where did the handbook author find them? Thanks, Patrick -- punkt.de GmbH * Vorholzstr. 25 * 76137 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 [EMAIL PROTECTED] http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ 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 Fatal Trap 12 with sysctl and acpi
Jim Pingle wrote: Jim Pingle wrote: I'm having some trouble with a SuperMicro SuperServer 6022L-6 that previously ran 7.0-BETA4 without problems. Today, I updated this machine to 7.0-PRERELEASE and now it will not fully boot unless I disable ACPI. A quick search of the PR database didn't turn up anything similar with sysctl and ACPI. I wiped the machine, installed from the RC3 CD, and it did not crash. If I update to RELENG_7, the crash comes back. If I go back to RELENG_7_0, there is no crash. Kernel config is GENERIC, with ULE scheduler and "options ASR_COMPAT" This happens with GENERIC, with no extra options, as well as with my custom kernel. If I get some time next week I might try a binary search of commits between BETA4 and now, to pinpoint where it stopped working. As a buildworld/buildkernel takes about an hour and a half on this hardware (2x2GHz Xeon), I haven't fully narrowed this down yet. It is somewhere between 12/15/2007 (works) and 12/25/2007 (crashes). I glanced at the archives between those points but I didn't see any similar complaints. The only ACPI references I saw in the archives were referring to thermal zone problems, and a commit relating to those. I'll return to this early next week to see if I can narrow this down more precisely. I tried a binary search of the source tree to narrow down the crash. I found that one vector for the crash was introduced between 2007/12/19 20:00:00 and 2007/12/19 23:59:00, which left me with only a handful of files to test. By process of elimination, I found that if I backed some changes out in machdep.c, the crash stopped. machdep.c v1.658 2007/08/09 njl - Boots OK machdep.c v1.658.2.1 2007/12/19 rpaulo - Crashes The confusing part (to me) is that my next step was to update all the way to RELENG_7 as of yesterday, then back out those same changes, but the crash still happened. So either I misidentified the cause of the crash -- which is quite possible -- or it was reintroduced in some other change (or both!). I have a debug kernel built now, and I can generate vmcore files at will. Does anyone have any ideas? Is there some more information that I can gather that will help find the cause? Now that I have some more solid information, I'll open a PR. Jim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ntpd fails to synchronize on FreeBSD 6.3-STABLE
On Wed, Feb 27, 2008 at 09:58:28PM +0700, Pongthep Kulkrisada wrote: > [EMAIL PROTECTED]:~# /etc/rc.d/ntpdate start > Setting date via ntp. > 27 Feb 20:46:53 ntpdate[2000]: no server suitable for synchronization found > [EMAIL PROTECTED]:~# tcpdump -l -n -s 8192 -p "port 123" > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on fxp0, link-type EN10MB (Ethernet), capture size 8192 bytes > 20:51:46.149541 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, > length 48 > 20:51:47.149369 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length > 48 > 20:51:48.149192 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, > length 48 > 20:52:50.148777 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, > length 48 > 20:52:50.148818 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length > 48 > 20:52:54.149147 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, > length 48 > 20:53:53.149127 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length > 48 > 20:53:56.148700 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, > length 48 > 20:53:57.149545 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, > length 48 > 20:54:56.149586 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length > 48 > 20:55:02.149701 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, > length 48 > 20:55:02.149749 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, > length 48 > 20:56:00.148838 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length > 48 > 20:56:05.149070 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, > length 48 > 20:56:07.148751 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, > length 48 > 20:57:06.148789 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length > 48 > 20:57:11.148992 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, > length 48 > 20:57:13.148718 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, > length 48 > 20:58:10.149016 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length > 48 > 20:58:17.148954 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, > length 48 > 20:58:17.148997 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, > length 48 > 20:59:14.149296 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length > 48 > 20:59:22.149048 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, > length 48 > 20:59:23.148886 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, > length 48 > 21:00:19.149376 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length > 48 > 21:00:26.149309 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, > length 48 > 21:00:29.148856 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, > length 48 > 21:01:23.149634 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length > 48 > 21:01:30.149579 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, > length 48 > 21:01:33.149117 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, > length 48 > 21:02:29.149586 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length > 48 > 21:02:35.148637 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, > length 48 > 21:02:37.149400 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, > length 48 > 21:03:32.149004 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length > 48 > 21:03:40.148796 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, > length 48 > 21:03:41.149618 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, > length 48 > 21:04:35.149397 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length > 48 > 21:04:45.148898 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, > length 48 > 21:04:46.148714 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, > length 48 > 21:05:39.149665 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length > 48 > 21:05:50.148985 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, > length 48 > 21:05:50.149032 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, > length 48 > 21:06:44.148776 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length > 48 > 21:06:54.149246 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, > length 48 > 21:06:56.148916 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, > length 48 > 21:07:49.148879 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length > 48 > 21:07:58.149478 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, > length 48 > 21:08:00.149183 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, > length 48 > 21:09:56.149530 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length > 48 > ^C > 49 packets captured > 230 packets received by filter > 0 packets dropped by kernel You're not getting responses back from __any__ of those NTP servers. If you have a firewall *in front* of your BSD box (meaning a separate box, not ipfw/ipfilter/pf on the same BSD box!), then this i
Re: ntpd fails to synchronize on FreeBSD 6.3-STABLE
> This isn't enough time. Please try this instead. > > # /etc/rc.d/ntpd stop > # /etc/rc.d/ntpdate start > > This should set your clock, even if only by a few milliseconds. > Assuming the ntpdate part is successful, continue on: > > # tcpdump -l -n -s 8192 -p "port 123" > > Now, in another window, execute: > > # /etc/rc.d/ntpd start > > Then let the tcpdump go for about 15 minutes. You aren't using the > "iburst" feature on any of the servers, so it will take some time before > they try to sync up. Alright, here is the output. Script started on Wed Feb 27 20:46:19 2008 [EMAIL PROTECTED]:~#/etc/rc.c/ntpd stop Stopping ntpd. [EMAIL PROTECTED]:~#/etc/rc.d/ntpdate start Setting date via ntp. 27 Feb 20:46:53 ntpdate[2000]: no server suitable for synchronization found [EMAIL PROTECTED]:~#tcpdump -l -n -s 8192 -p "port 123" tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on fxp0, link-type EN10MB (Ethernet), capture size 8192 bytes 20:51:46.149541 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, length 48 20:51:47.149369 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length 48 20:51:48.149192 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, length 48 20:52:50.148777 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, length 48 20:52:50.148818 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length 48 20:52:54.149147 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, length 48 20:53:53.149127 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length 48 20:53:56.148700 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, length 48 20:53:57.149545 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, length 48 20:54:56.149586 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length 48 20:55:02.149701 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, length 48 20:55:02.149749 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, length 48 20:56:00.148838 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length 48 20:56:05.149070 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, length 48 20:56:07.148751 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, length 48 20:57:06.148789 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length 48 20:57:11.148992 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, length 48 20:57:13.148718 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, length 48 20:58:10.149016 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length 48 20:58:17.148954 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, length 48 20:58:17.148997 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, length 48 20:59:14.149296 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length 48 20:59:22.149048 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, length 48 20:59:23.148886 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, length 48 21:00:19.149376 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length 48 21:00:26.149309 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, length 48 21:00:29.148856 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, length 48 21:01:23.149634 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length 48 21:01:30.149579 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, length 48 21:01:33.149117 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, length 48 21:02:29.149586 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length 48 21:02:35.148637 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, length 48 21:02:37.149400 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, length 48 21:03:32.149004 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length 48 21:03:40.148796 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, length 48 21:03:41.149618 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, length 48 21:04:35.149397 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length 48 21:04:45.148898 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, length 48 21:04:46.148714 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, length 48 21:05:39.149665 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length 48 21:05:50.148985 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, length 48 21:05:50.149032 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, length 48 21:06:44.148776 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length 48 21:06:54.149246 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, length 48 21:06:56.148916 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, length 48 21:07:49.148879 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length 48 21:07:58.149478 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, length 48 21:08:00.149183 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, length 48 21:09:56.149530 IP
Re: em very slow, shared irq... on 6.3p8
At 05:49 AM 2/27/2008, Holger Kipp wrote: I therefore assume that the problem is between receiving the irq from em and getting the data from the interface on the firewall itself. I would try upgrading to 6.3R (there are several em driver bug fixes) and then try the box with % cat /boot/loader.conf hw.pci.enable_msi=1 ...if the cards support msi. I think pciconf -lvc should tell you if the cards and slots support it or not. Also, if you dont need IPV6, use FAST_IPSEC. It does not need mpsafe. If you do need IPSEC and IPV6, 7.0R got rid of that restriction. ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Tar regression from 6.2 to 6.3 with --strip-components
Hi, On Thu, Feb 28, 2008 at 12:09:50AM +1100, Jan Mikkelsen wrote: > And the tar extraction returns a failure. I can confirm this does not work on 8-CURRENT either. > Is this known? Should I raise a PR? That seems a good idea to me. Thanks! -- Rink P.W. Springer- http://rink.nu "Anyway boys, this is America. Just because you get more votes doesn't mean you win." - Fox Mulder ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Tar regression from 6.2 to 6.3 with --strip-components
Jan Mikkelsen wrote: Hi, I've just noticed a regression in tar from 6.2 to 6.3: Running this on 6.2 produces no output: #!/bin/sh mkdir -p a b output touch a/file1 b/file2 tar cf test.tar a b tar -x -C output --strip-components 1 -f test.tar On 6.3, it produces this output: : Invalid empty pathname : Invalid empty pathname tar: Error exit delayed from previous errors. And the tar extraction returns a failure. Is this known? Should I raise a PR? Let's see what Tim has to say. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Tar regression from 6.2 to 6.3 with --strip-components
Hi, I've just noticed a regression in tar from 6.2 to 6.3: Running this on 6.2 produces no output: #!/bin/sh mkdir -p a b output touch a/file1 b/file2 tar cf test.tar a b tar -x -C output --strip-components 1 -f test.tar On 6.3, it produces this output: : Invalid empty pathname : Invalid empty pathname tar: Error exit delayed from previous errors. And the tar extraction returns a failure. Is this known? Should I raise a PR? Regards, Jan Mikkelsen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em very slow, shared irq... on 6.3p8
On Wednesday 27 February 2008 07:49:42 Holger Kipp wrote: > Hello, > > I updated a system with 12 dc-interfaces to a new hardware > with 14 em-interfaces. Yes, it is a firewall. > New System is 6.2-RELEASE-p8. > > What I now experience between two internal networks (100MBit/s each) > is the following: > 1318 packets transmitted, 1317 packets received, 0% packet loss > round-trip min/avg/max/stddev = 0.387/246.153/2441.392/324.142 ms > > tcpdump on the firewall shows similar delays (on the outgoing > interface). > > tcpdump on the system I ping however shows very quick responses > for incoming packages (ie usually less than a millisecond). > > I therefore assume that the problem is between receiving the > irq from em and getting the data from the interface on the firewall > itself. > > My first option would be to activate polling on em-interfaces - but as > I did not experience this sort of notieceable slowdown with the old > dc-based firewall (without polling), maybe someone can shed some light > on this strange behaviour or has other suggestions as well? I had a setup with 4 (dlink 4port + 1 nic nfe onboard) which run extremely stable 6.3 I upgraded the hardware (S939 -> AM2) and used two em 2port cards, without polling it was certanly unusable but with polling I got very good performance without polling normally in a day or less the machine hung, no msg, simply freezed with polling it stands some days up to two weeks when it freeze again I upgraded to 7.0 same result check your setup with vmstat -i and if you see two nics on the same interrupt I guess you get the same result as I got actual I am running one em 2port and two single port pci cards what seems to be stable anyway, similare setup on Tyan MBs do not have this problem where I also have 8 nics on one system I also do not have this problems on S939 boards only on AM2, so I am not sure where the problem is exactly but seems in a certain way hardware related You could try changing your PS unit because you might be short on power with lots of em cards and SATA disks -- João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic in ufs_lookup (6.2-STABLE)
Andrew N. Below wrote: > RELENG_6 cvsuped at 2007-01-15 > > what should I check (source revisions) to ensure we have same bug? This is a quite old version of FreeBSD. I don't know for sure if the bug was fixed by that time, but you should update to newest RELENG_6 or RELENG_6_3 to make sure. Alternatively, something might be corrupting the file system data. Maybe you should experiment with a few rounds of rsync followed by md5 on both the source and destination file systems. signature.asc Description: OpenPGP digital signature
Re: ad0 READ_DMA TIMEOUT errors on install of 7.0-RELEASE
On Wed, Feb 27, 2008 at 01:11:36AM -0800, Stephen Hurd wrote: > ... The corrupted sync message scared the heck out of me: > Waiting (max 60 seconds) for system process `vnlru' to stop...done > Waiti > Synncgi n(gm adxi sk6s0, svencoodnedss )r efmoari nsiynsgte.m. .pr1o0c ess > `syncer' to stop...8 7 8 3 3 3 1 0 0 0 0 done http://lists.freebsd.org/pipermail/freebsd-current/2007-October/078145.html http://lists.freebsd.org/pipermail/freebsd-current/2007-November/079130.html http://lists.freebsd.org/pipermail/freebsd-current/2007-November/079131.html http://lists.freebsd.org/pipermail/freebsd-stable/2007-December/038727.html > And after the reboot, the READ_DMA timeouts were back. You're not the only one seeing this behaviour. There are too many posts in the past reporting similar. Here's the breakdown: * Some reporting this problem have been told to replace their ATA or SATA cables (which have previously been known to be working, but cables going bad does happen) -- and this has fixed the problem for a couple. * Some have checked their SMART stats and found their disks to be in perfect condition. * Some have switched to alternate operating systems (usually Linux) for a short while and seen no sign of DMA timeouts. * Some have replaced the storage controller to no avail, and some have replaced the entire motherboard to no avail. In some cases (myself included), replacing the motherboard did in fact help. However: in your case, your disk does look to have problems based on the SMART output you provided. It does not matter how new/old the disk is, by the way. I'll point out the problematic stats. You need to replace the disk ASAP. BTW, any SMART stats you see labelled "Offline" means the numbers will not be updated until you perform an offline test (smartctl -t short or smartctl -t long). > The only "odd" think I can think of about my system is an unusually high HZ > value (2386) I'm building a kernel now with 1000 to check if that makes a > difference. This is not the cause, rest assured. > SMART Attributes Data Structure revision number: 16 > Vendor Specific SMART Attributes with Thresholds: > ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED > WHEN_FAILED RAW_VALUE > 5 Reallocated_Sector_Ct 0x0033 253 253 063Pre-fail Always > - 4 This shows you've had 4 reallocated sectors, meaning your disk does in fact have bad blocks. In 90% of the cases out there, bad blocks continue to "grow" over time, due to whatever reason (I remember reading an article explaining it, but I can't for the life of me find the URL). > 194 Temperature_Celsius 0x0032 253 253 000Old_age Always > - 48 This is excessive, and may be attributing to problems. A hard disk running at 48C is not a good sign. This should really be somewhere between high 20s and mid 30s. > 195 Hardware_ECC_Recovered 0x000a 253 252 000Old_age Always > - 11498 This implies a large number of ECC (error correction) activities have occured, but all were successful. > Error 2 occurred at disk power-on lifetime: 5171 hours (215 days + 11 hours) > When the command that caused the error occurred, the device was in an > unknown state. > Error 1 occurred at disk power-on lifetime: 5171 hours (215 days + 11 hours) > When the command that caused the error occurred, the device was in an > unknown state. These are automated SMART log entries confirming the DMA failures. The fact that SMART saw them means that the disk is also aware of said issues. These may have been caused by the reallocated sectors. It's also interesting that the LBAs are different than the ones FreeBSD reported issues with. My advice to you is: replace the disk ASAP. This problem will only get worse. Try another hard disk brand too (I don't have anything "against" Maxtor, but usually its recommended to avoid a brand you have problems with until the next time you have issues, then switch brands, etc. etc...). I'm very fond of Western Digital's SE16, RE, and RE2 series currently. But avoid Fujitsu and Samsung (both have a long track record of having buggy drive firmwares, forcing vendors to make custom workarounds for issues); stick with Seagate, Western Digital, or Maxtor. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
em very slow, shared irq... on 6.3p8
Hello, I updated a system with 12 dc-interfaces to a new hardware with 14 em-interfaces. Yes, it is a firewall. New System is 6.2-RELEASE-p8. What I now experience between two internal networks (100MBit/s each) is the following: 1318 packets transmitted, 1317 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.387/246.153/2441.392/324.142 ms tcpdump on the firewall shows similar delays (on the outgoing interface). tcpdump on the system I ping however shows very quick responses for incoming packages (ie usually less than a millisecond). I therefore assume that the problem is between receiving the irq from em and getting the data from the interface on the firewall itself. My first option would be to activate polling on em-interfaces - but as I did not experience this sort of notieceable slowdown with the old dc-based firewall (without polling), maybe someone can shed some light on this strange behaviour or has other suggestions as well? More details and dmesg below. Help and suggestions welcome :-) Best regards, Holger Kipp PS: Regarding the MPSAFE-issue - I need to use ipsec, so don't have a choice here. On the firewall I see many irqs (sometimes more than 5000) very often on one of the em-interfaces using sysctl/vmstat: 2 usersLoad 0.00 0.00 0.04 Feb 27 12:20 Mem:KBREALVIRTUAL VN PAGER SWAP PAGER Tot Share TotShareFree in out in out Act 14804372432800 3800 1327728 count All 7223245248 76723364 5696 pages Interrupts Proc:r p d s wCsw Trp Sys Int Sof Fltcow7606 total 27 78621 462 4105 158840 wire1: atkb 14988 act 6: fdc0 0.2%Sys 3.0%Intr 0.0%User 0.0%Nice 96.8%Idl 547868 inact 12: psm |||||||||| 1244 cache 14: ata ++1326484 free359 16: em4 daefr 2761 17: em5 Namei Name-cacheDir-cache prcfr 28: twe Calls hits% hits% react 306 52: em0 pdwak 1 53: em1 zfodpdpgs 177 55: em3 Disks twed0 ozfod intrn 2001 cpu0: time KB/t 21.33 %slo-z 114464 buf2001 cpu1: time tps 1 1 tfree10 dirtybuf MB/s 0.0110 desiredvnodes % busy0 66594 numvnodes 19758 freevnodes dmesg Copyright (c) 1992-2007 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 6.2-RELEASE-p8 #1: Thu Oct 4 16:07:31 CEST 2007 WARNING: debug.mpsafenet forced to 0 as ipsec requires Giant WARNING: MPSAFE network stack disabled, expect reduced performance. MPTable: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 CPU 6420 @ 2.13GHz (2128.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 Features=0xbfebfbff Features2=0xe3bd,CX16,,> AMD Features=0x2010 AMD Features2=0x1 Cores per package: 2 real memory = 2146349056 (2046 MB) avail memory = 2095296512 (1998 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Assuming intbase of 0 ioapic1: Assuming intbase of 24 ioapic2: Assuming intbase of 48 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard ioapic2 irqs 48-71 on motherboard kbd1 at kbdmux0 cpu0 on motherboard cpu1 on motherboard pcib0: pcibus 0 on motherboard pci0: on pcib0 pcib0: unable to route slot 28 INTB pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 pcib2: at device 0.0 on pci1 pci2: on pcib2 twe0: <3ware Storage Controller. Driver version 1.50.01.002> port 0x4000-0x400f mem 0xe010-0xe01f,0xe080-0xe0ff irq 28 at device 2.0 on pci2 twe0: [GIANT-LOCKED] twe0: 2 ports, Firmware FE8S 1.05.00.068, BIOS BE7X 1.08.00.048 pci1: at device 0.1 (no driver attached) pcib3: at device 0.2 on pci1 pci3: on pcib3 pcib4: at device 3.0 on pci3 pci4: on pcib4 em0: port 0x5000-0x503f mem 0xe100-0xe101 irq 52 at device 4.0 on pci4 em0: Ethernet address: 00:0e:0c:c6:cc:54 em
ad0 READ_DMA TIMEOUT errors on install of 7.0-RELEASE
My system has been working reliably with 6.3 for quite some time... when I rebooted into single user mode to do the installworld with the 7.0-RELEASE kernel, the install died about halfway through with READ_DMA TIMEOUT errors. Since I had a mixed system at that point, I set hw.ata.ata_dma="0" in /boot/loader.conf and completed the install. After a good boot to verify everything was working, I flipped hw.ata.ata_dma back and rebooted. The corrupted sync message scared the heck out of me: Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiti Synncgi n(gm adxi sk6s0, svencoodnedss )r efmoari nsiynsgte.m. .pr1o0c ess `syncer' to stop...8 7 8 3 3 3 1 0 0 0 0 done And after the reboot, the READ_DMA timeouts were back. I installed sysutils/smartmontools (output attached in case it's usefull) The only "odd" think I can think of about my system is an unusually high HZ value (2386) I'm building a kernel now with 1000 to check if that makes a difference. 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-RELEASE #1: Tue Feb 26 22:49:13 PST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SERVER Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel Pentium III (996.85-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x387fbff real memory = 1207959552 (1152 MB) avail memory = 1172832256 (1118 MB) MPTable: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Assuming intbase of 0 ioapic1: Assuming intbase of 16 ioapic0 irqs 0-15 on motherboard ioapic1 irqs 16-31 on motherboard kbd1 at kbdmux0 cpu0 on motherboard cpu1 on motherboard pcib0: pcibus 0 on motherboard pci0: on pcib0 vgapci0: port 0xd800-0xd8ff mem 0xfd00-0xfdff,0xfeaff000-0xfeaf irq 22 at device 1.0 on pci0 drm0: on vgapci0 info: [drm] Initialized mach64 1.0.0 20020904 fxp0: port 0xd400-0xd43f mem 0xfeafe000-0xfeafefff,0xfe90-0xfe9f irq 20 at device 4.0 on pci0 miibus0: on fxp0 inphy0: PHY 1 on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:e0:81:21:49:7e fxp0: [ITHREAD] fxp1: port 0xd000-0xd03f mem 0xfeafd000-0xfeafdfff,0xfe70-0xfe7f irq 21 at device 5.0 on pci0 miibus1: on fxp1 inphy1: PHY 1 on miibus1 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp1: Ethernet address: 00:e0:81:21:49:7f fxp1: [ITHREAD] isab0: port 0x580-0x58f at device 15.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 15.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] ohci0: mem 0xfeafc000-0xfeafcfff irq 10 at device 15.2 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: <(0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0 uhub0: 2 ports with 2 removable, self powered pcib1: pcibus 1 on motherboard pci1: on pcib1 pcm0: port 0xef00-0xef3f irq 27 at device 2.0 on pci1 pcm0: pcm0: [ITHREAD] pcm0: pmtimer0 on isa0 orm0: at iomem 0xc-0xc7fff,0xc8000-0xc8fff,0xc9000-0xc9fff pnpid ORM on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model MouseMan+, device ID 0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 ppbus0: [ITHREAD] lpt0: on ppbus0 lpt0: Interrupt-driven port ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled unknown: can't assign resources (memory) unknown: can't assign resources (port) speaker0: at port 0x61 pnpid PNP0800 on isa0 unknown: can't assign resources (port) unknown: can't assign resources (irq) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) uhid0: 2> on uhub0 uhub0: device problem (IOERROR), disabling port 2 Timecounters tick every 0.838 msec ipfw2 (+ipv6) initialized, divert enabled, rule-based forwarding disabled, default to deny, logging disabled ad0: 239372MB at ata0-master PIO4 acd0: CDRW at ata1-master UDMA33 SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad0s1a fxp0: Microcode loaded
