Re: 9-stable from i386 to amd64
> Do you have a spare partition? Probably use the swap partition temporarily. > Install the 64 bits stuff into it. Boot from it and than install the 64 > bits stuff over the (now unused) 32 bits stuff and reboot into that. If > something fails you can always go back to a bootable system. > NB: disclaimer: I have never done this. You may not, but I have, several times, and it works fine - indeed it is how I originally moved all my 32 bit systems over to 64 bit. Doing this remotely, as the original poster wanted, is tricky though without some kind of iLo-style access. -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: LSI supported mps(4) driver in stable/9 and stable/8
Kenneth D. Merry schreef: Hi folks, The LSI-supported version of the mps(4) driver that supports their 6Gb SAS HBAs as well as WarpDrive controllers, is now in stable/9 and stable/8. Please test it out and let me and Kashyap (CCed) know if you run into any problems. In addition to supporting WarpDrive, the driver also supports Integrated RAID. Thanks to LSI for doing the work on this driver! Note that the CAM infrastructure changes that went into FreeBSD/head along with this driver have not gone into either stable/9 or stable/8. Only the driver itself has been merged. The CAM infrastructure changes depend on some other da(4) driver changes that will need to get merged before they can go back. If that merge happens, it will probably only be into stable/9. A couple of notes about issues with this driver: - Unlike the previous mps(4) driver, it probes sequentially. If you have a lot of drives in your system, it will take a while to probe them all. - You may see warning messages like this: _mapping_add_new_device: failed to add the device with handle 0x0019 to persiste nt table because there is no free space available _mapping_add_new_device: failed to add the device with handle 0x001a to persiste nt table because there is no free space available - The driver is not endian safe. (It assumes a little endian machine.) This is not new, the previous version of the driver had the same issue. The LSI folks know about these issues. The driver has passed their testing process. Many thanks to LSI for going through the effort to support FreeBSD. Ken Hello all. I am running FreeBSD 9.0 STABLE now, on a LSI 9211-8i controller and a 16 ports backplane identified as LSI CORP SAS2X28 0717 ses0 pass6 On FreeBSD 9.0RELEASE i have the following order. Seen from the front of the case. da3 da7 da11 da15 da2 da6 da10 da14 da1 da5 da9 da13 da0 da4 da8 da12 But now it has shuffled the order. da8 da 14 da12 da10 da9 da15 da13 da11 da1 da6 da2 da5 da0 da7 da3 da4 There is no logic at all, and it is very hard to figure out when a disk dies which one it is. regards Johan Hendriks ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
RE: LSI supported mps(4) driver in stable/9 and stable/8
> -Original Message- > From: owner-freebsd-sta...@freebsd.org [mailto:owner-freebsd- > sta...@freebsd.org] On Behalf Of Johan Hendriks > Sent: Monday, February 13, 2012 3:34 PM > To: Kenneth D. Merry > Cc: freebsd-stable > Subject: Re: LSI supported mps(4) driver in stable/9 and stable/8 > > Kenneth D. Merry schreef: > > Hi folks, > > > > The LSI-supported version of the mps(4) driver that supports their 6Gb > SAS > > HBAs as well as WarpDrive controllers, is now in stable/9 and > stable/8. > > > > Please test it out and let me and Kashyap (CCed) know if you run into > > any problems. > > > > In addition to supporting WarpDrive, the driver also supports > Integrated > > RAID. > > > > Thanks to LSI for doing the work on this driver! > > > > Note that the CAM infrastructure changes that went into FreeBSD/head > along > > with this driver have not gone into either stable/9 or stable/8. Only > the > > driver itself has been merged. > > > > The CAM infrastructure changes depend on some other da(4) driver > changes > > that will need to get merged before they can go back. If that merge > > happens, it will probably only be into stable/9. > > > > A couple of notes about issues with this driver: > > > > - Unlike the previous mps(4) driver, it probes sequentially. If you > have > > a lot of drives in your system, it will take a while to probe them > all. > > - You may see warning messages like this: > > > > _mapping_add_new_device: failed to add the device with handle 0x0019 > to persiste > > nt table because there is no free space available > > _mapping_add_new_device: failed to add the device with handle 0x001a > to persiste > > nt table because there is no free space available > > > > - The driver is not endian safe. (It assumes a little endian > machine.) > > This is not new, the previous version of the driver had the same > issue. > > > > The LSI folks know about these issues. The driver has passed their > testing > > process. > > > > Many thanks to LSI for going through the effort to support FreeBSD. > > > > Ken > Hello all. > > I am running FreeBSD 9.0 STABLE now, on a LSI 9211-8i controller and a > 16 ports backplane identified as LSI CORP SAS2X28 0717 ses0 pass6 > On FreeBSD 9.0RELEASE i have the following order. > Seen from the front of the case. > da3 da7 da11 da15 > da2 da6 da10 da14 > da1 da5 da9 da13 > da0 da4 da8 da12 > > But now it has shuffled the order. > da8 da 14 da12 da10 > da9 da15 da13 da11 > da1 da6 da2 da5 > da0 da7 da3 da4 > > There is no logic at all, and it is very hard to figure out when a disk > dies which one it is. Can you attach dmesg logs ? Basically now Drive will not ask CAM layer to add device using XPT_ASYC call. It will ask CAM layer to rescan the bus. So how CAM layer detects Drives is beyond Low level driver and it is obviously no guaranty of sequence of daX. If you have some X Drives attached to enclosure, target IDs of those Drive will be generated by Driver based on which mode mapping table is. 1. Enclosure slot mapping 2. Device mapping. For your case best choice will be Enclosure slot mapping. Assume you have Enclosure slop mapping. Target ID assignment is part of Driver which will consistence across all reboot. _but_ when Driver call rescan bus (as part of device add), it will scan bus in sequence and later peripher layer will assing device naming. So it is completely unsure which device will get what device name. e.a I have four Drive in "Enclosure slot mapping" Drive-A, Drive-B, Drive-C and Drive-D. (Consider alphabetical order is mapped to slot number ) So Driver will assign below target id. (target id 0-7 is reserved for local port of HBA) Drive- A Target ID -8 Drive- B Target ID -9 Drive- C Target ID -10 Drive- D Target ID -11 You cannot expect Drive-A will be assigned to da0. (and similar Drive-D will get da3). In summary, This behavior is visible just because of new change in driver, but it is never *must* follow condition for any driver. Device naming is part of CAM layer. > > > regards > Johan Hendriks > > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable- > unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Reducing the need to compile a custom kernel
Quoting per...@pluto.rain.com (from Mon, 13 Feb 2012 02:17:46 -0800): Alexander Leidinger wrote: On Sun, 12 Feb 2012 03:05:02 -0800 per...@pluto.rain.com wrote: > Alexander Leidinger wrote: > > On Sat, 11 Feb 2012 13:40:41 +0100 Thierry Thomas > > wrote: > > > is there another place to put options to atkbd and sc, like > > > these ones: > > > > > > options ATKBD_DFLT_KEYMAP # specify the built-in > > > keymap makeoptions ATKBD_DFLT_KEYMAP=fr.iso.acc > > > ... > > > > No, there is no other way to add the keymap to the kernel > > directly (if you want to have it working correctly in > > single-user mode) instead of loading it with rc.conf. > > Might it be feasible to make it into a sysctl, so it could be > set in loader.conf? There is already a way to configure this as soon as you have a working userland. What this setting is doing is to replace the compiled-in default keymap with a different one, so that you have the one which matches your keyboard even when you enter the very first keystrokes in single-user mode (root-pw, path to shell, ...). My point is, if it were made into a sysctl, it could presumably be set in loader.conf -- thereby providing the correct keymap for those "very first keystrokes" without needing a custom kernel. I know that's not how it works _now_, but is there some reason why this approach is not feasible? It seems like something that could potentially go on the the list of projects to reduce the need for custom kernels. Feasible: depend upon your definition of "feasible". You would have to add all keymaps statically into the kernel. No idea which parts exactly we talk about, but: ---snip--- % du -h /usr/share/syscons/ 40k/usr/share/syscons/scrnmaps 570k/usr/share/syscons/fonts 1.1M/usr/share/syscons/keymaps 1.8M/usr/share/syscons/ ---snip--- I wouldn't mind for 40k, but 1.8M looks more like the value to calculate with. Anyway, this is out of the scope of the original question. Bye, Alexander. -- On successive charts of the same organization, the number of boxes will never decrease. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: LSI supported mps(4) driver in stable/9 and stable/8
Desai, Kashyap schreef: -Original Message- From: owner-freebsd-sta...@freebsd.org [mailto:owner-freebsd- sta...@freebsd.org] On Behalf Of Johan Hendriks Sent: Monday, February 13, 2012 3:34 PM To: Kenneth D. Merry Cc: freebsd-stable Subject: Re: LSI supported mps(4) driver in stable/9 and stable/8 Kenneth D. Merry schreef: Hi folks, The LSI-supported version of the mps(4) driver that supports their 6Gb SAS HBAs as well as WarpDrive controllers, is now in stable/9 and stable/8. Please test it out and let me and Kashyap (CCed) know if you run into any problems. In addition to supporting WarpDrive, the driver also supports Integrated RAID. Thanks to LSI for doing the work on this driver! Note that the CAM infrastructure changes that went into FreeBSD/head along with this driver have not gone into either stable/9 or stable/8. Only the driver itself has been merged. The CAM infrastructure changes depend on some other da(4) driver changes that will need to get merged before they can go back. If that merge happens, it will probably only be into stable/9. A couple of notes about issues with this driver: - Unlike the previous mps(4) driver, it probes sequentially. If you have a lot of drives in your system, it will take a while to probe them all. - You may see warning messages like this: _mapping_add_new_device: failed to add the device with handle 0x0019 to persiste nt table because there is no free space available _mapping_add_new_device: failed to add the device with handle 0x001a to persiste nt table because there is no free space available - The driver is not endian safe. (It assumes a little endian machine.) This is not new, the previous version of the driver had the same issue. The LSI folks know about these issues. The driver has passed their testing process. Many thanks to LSI for going through the effort to support FreeBSD. Ken Hello all. I am running FreeBSD 9.0 STABLE now, on a LSI 9211-8i controller and a 16 ports backplane identified as LSI CORP SAS2X28 0717 ses0 pass6 On FreeBSD 9.0RELEASE i have the following order. Seen from the front of the case. da3 da7 da11 da15 da2 da6 da10 da14 da1 da5 da9 da13 da0 da4 da8 da12 But now it has shuffled the order. da8 da 14 da12 da10 da9 da15 da13 da11 da1 da6 da2 da5 da0 da7 da3 da4 There is no logic at all, and it is very hard to figure out when a disk dies which one it is. Can you attach dmesg logs ? Basically now Drive will not ask CAM layer to add device using XPT_ASYC call. It will ask CAM layer to rescan the bus. So how CAM layer detects Drives is beyond Low level driver and it is obviously no guaranty of sequence of daX. If you have some X Drives attached to enclosure, target IDs of those Drive will be generated by Driver based on which mode mapping table is. 1. Enclosure slot mapping 2. Device mapping. For your case best choice will be Enclosure slot mapping. Assume you have Enclosure slop mapping. Target ID assignment is part of Driver which will consistence across all reboot. _but_ when Driver call rescan bus (as part of device add), it will scan bus in sequence and later peripher layer will assing device naming. So it is completely unsure which device will get what device name. e.a I have four Drive in "Enclosure slot mapping" Drive-A, Drive-B, Drive-C and Drive-D. (Consider alphabetical order is mapped to slot number ) So Driver will assign below target id. (target id 0-7 is reserved for local port of HBA) Drive- A Target ID -8 Drive- B Target ID -9 Drive- C Target ID -10 Drive- D Target ID -11 You cannot expect Drive-A will be assigned to da0. (and similar Drive-D will get da3). In summary, This behavior is visible just because of new change in driver, but it is never *must* follow condition for any driver. Device naming is part of CAM layer. regards Johan Hendriks ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable- unsubscr...@freebsd.org" Ok so it is not the mps driver who does the naming but cam, and that also has changed on 9.0 Stable. Well i use gpart labels for the pool, so i can use the gpart labels to yank the right disk. But it would be nicer if there was some kind of logic in the numbering of the devices. Here is the dmesg Copyright (c) 1992-2012 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 9.0-STABLE #0: Mon Feb 13 10:22:44 CET 2012 root@filer01.testdomain.local:/usr/obj/usr/src/sys/KRNL amd64 CPU: Intel(R) Xeon(R) CPU E31220 @ 3.10GHz (3093.04-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x206a7 Family = 6 Model = 2a Stepping = 7 Features=0xbfebfbff Features2=0x15bae3ff AMD Featu
RE: LSI supported mps(4) driver in stable/9 and stable/8
> -Original Message- > From: Johan Hendriks [mailto:joh.hendr...@gmail.com] > Sent: Monday, February 13, 2012 4:42 PM > To: Desai, Kashyap > Cc: freebsd-stable > Subject: Re: LSI supported mps(4) driver in stable/9 and stable/8 > > Desai, Kashyap schreef: > > > >> -Original Message- > >> From: owner-freebsd-sta...@freebsd.org [mailto:owner-freebsd- > >> sta...@freebsd.org] On Behalf Of Johan Hendriks > >> Sent: Monday, February 13, 2012 3:34 PM > >> To: Kenneth D. Merry > >> Cc: freebsd-stable > >> Subject: Re: LSI supported mps(4) driver in stable/9 and stable/8 > >> > >> Kenneth D. Merry schreef: > >>> Hi folks, > >>> > >>> The LSI-supported version of the mps(4) driver that supports their > 6Gb > >> SAS > >>> HBAs as well as WarpDrive controllers, is now in stable/9 and > >> stable/8. > >>> Please test it out and let me and Kashyap (CCed) know if you run > into > >>> any problems. > >>> > >>> In addition to supporting WarpDrive, the driver also supports > >> Integrated > >>> RAID. > >>> > >>> Thanks to LSI for doing the work on this driver! > >>> > >>> Note that the CAM infrastructure changes that went into FreeBSD/head > >> along > >>> with this driver have not gone into either stable/9 or stable/8. > Only > >> the > >>> driver itself has been merged. > >>> > >>> The CAM infrastructure changes depend on some other da(4) driver > >> changes > >>> that will need to get merged before they can go back. If that merge > >>> happens, it will probably only be into stable/9. > >>> > >>> A couple of notes about issues with this driver: > >>> > >>>- Unlike the previous mps(4) driver, it probes sequentially. If > you > >> have > >>> a lot of drives in your system, it will take a while to probe > them > >> all. > >>>- You may see warning messages like this: > >>> > >>> _mapping_add_new_device: failed to add the device with handle 0x0019 > >> to persiste > >>> nt table because there is no free space available > >>> _mapping_add_new_device: failed to add the device with handle 0x001a > >> to persiste > >>> nt table because there is no free space available > >>> > >>>- The driver is not endian safe. (It assumes a little endian > >> machine.) > >>> This is not new, the previous version of the driver had the > same > >> issue. > >>> The LSI folks know about these issues. The driver has passed their > >> testing > >>> process. > >>> > >>> Many thanks to LSI for going through the effort to support FreeBSD. > >>> > >>> Ken > >> Hello all. > >> > >> I am running FreeBSD 9.0 STABLE now, on a LSI 9211-8i controller and > a > >> 16 ports backplane identified as LSI CORP SAS2X28 0717 ses0 pass6 > >> On FreeBSD 9.0RELEASE i have the following order. > >> Seen from the front of the case. > >> da3 da7 da11 da15 > >> da2 da6 da10 da14 > >> da1 da5 da9 da13 > >> da0 da4 da8 da12 > >> > >> But now it has shuffled the order. > >> da8 da 14 da12 da10 > >> da9 da15 da13 da11 > >> da1 da6 da2 da5 > >> da0 da7 da3 da4 > >> > >> There is no logic at all, and it is very hard to figure out when a > disk > >> dies which one it is. > > Can you attach dmesg logs ? > > Basically now Drive will not ask CAM layer to add device using > XPT_ASYC call. > > It will ask CAM layer to rescan the bus. > > > > So how CAM layer detects Drives is beyond Low level driver and it is > obviously no guaranty of sequence of daX. > > If you have some X Drives attached to enclosure, target IDs of those > Drive will be generated by Driver based on > > which mode mapping table is. > > 1. Enclosure slot mapping > > 2. Device mapping. > > > > For your case best choice will be Enclosure slot mapping. Assume you > have Enclosure slop mapping. > > > > Target ID assignment is part of Driver which will consistence across > all reboot. > > _but_ when Driver call rescan bus (as part of device add), it will > scan bus in sequence and later peripher layer will assing device naming. > > So it is completely unsure which device will get what device name. > > > > e.a I have four Drive in "Enclosure slot mapping" Drive-A, Drive-B, > Drive-C and Drive-D. (Consider alphabetical order is mapped to slot > number ) > > So Driver will assign below target id. (target id 0-7 is reserved for > local port of HBA) > > > > Drive- A Target ID -8 > > Drive- B Target ID -9 > > Drive- C Target ID -10 > > Drive- D Target ID -11 > > > > You cannot expect Drive-A will be assigned to da0. (and similar Drive- > D will get da3). > > > > In summary, This behavior is visible just because of new change in > driver, but it is never *must* follow condition for any driver. > > Device naming is part of CAM layer. > > > > > >> > >> regards > >> Johan Hendriks > >> > >> > >> ___ > >> freebsd-stable@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable > >> To unsubscribe, send any mail to "freebsd-stable- > >> unsubscr...@freebsd.org" > > Ok so it is not the mps driver who does the naming but ca
Re: LSI supported mps(4) driver in stable/9 and stable/8
On Mon, Feb 13, 2012 at 12:11:30PM +0100, Johan Hendriks wrote: > Ok so it is not the mps driver who does the naming but cam, and that > also has changed on 9.0 Stable. > Well i use gpart labels for the pool, so i can use the gpart labels > to yank the right disk. > But it would be nicer if there was some kind of logic in the > numbering of the devices. "Wire them down" in FreeBSD using loader.conf variables and this issue will cease to be a problem. Example is below, despite being for SATA with AHCI -- really doesn't matter, just change the appropriate bits and it should be fine for you. # "Wire down" device names (ada[0-5]) to each individual port # on the SATA/AHCI controller. This ensures that if we reboot # with a disk missing, the device names stay the same, and stay # attached to the same SATA/AHCI controller. # http://lists.freebsd.org/pipermail/freebsd-fs/2011-March/011036.html # hint.scbus.0.at="ahcich0" hint.scbus.1.at="ahcich1" hint.scbus.2.at="ahcich2" hint.scbus.3.at="ahcich3" hint.scbus.4.at="ahcich4" hint.scbus.5.at="ahcich5" hint.ada.0.at="scbus0" hint.ada.1.at="scbus1" hint.ada.2.at="scbus2" hint.ada.3.at="scbus3" hint.ada.4.at="scbus4" hint.ada.5.at="scbus5" -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | 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 "freebsd-stable-unsubscr...@freebsd.org"
Re: LSI supported mps(4) driver in stable/9 and stable/8
On Mon, Feb 13, 2012 at 03:49:41AM -0800, Jeremy Chadwick wrote: > On Mon, Feb 13, 2012 at 12:11:30PM +0100, Johan Hendriks wrote: > > Ok so it is not the mps driver who does the naming but cam, and that > > also has changed on 9.0 Stable. > > Well i use gpart labels for the pool, so i can use the gpart labels > > to yank the right disk. > > But it would be nicer if there was some kind of logic in the > > numbering of the devices. > > "Wire them down" in FreeBSD using loader.conf variables and this issue > will cease to be a problem. Example is below, despite being for SATA > with AHCI -- really doesn't matter, just change the appropriate bits and > it should be fine for you. > > > # "Wire down" device names (ada[0-5]) to each individual port > # on the SATA/AHCI controller. This ensures that if we reboot > # with a disk missing, the device names stay the same, and stay > # attached to the same SATA/AHCI controller. > # http://lists.freebsd.org/pipermail/freebsd-fs/2011-March/011036.html > # > hint.scbus.0.at="ahcich0" > hint.scbus.1.at="ahcich1" > hint.scbus.2.at="ahcich2" > hint.scbus.3.at="ahcich3" > hint.scbus.4.at="ahcich4" > hint.scbus.5.at="ahcich5" > hint.ada.0.at="scbus0" > hint.ada.1.at="scbus1" > hint.ada.2.at="scbus2" > hint.ada.3.at="scbus3" > hint.ada.4.at="scbus4" > hint.ada.5.at="scbus5" To be more specific: please see the CAM(4) man page and look at some of the example hint settings shown there. In your case I believe you'd want the below (which is a static map that matches your provided dmesg in the previous mail). If you want different device names tied to the different targets, it should be pretty obvious what to change. hint.scbus.0.at="mps0" hint.da.0.at="scbus0" hint.da.0.target="8" hint.da.0.unit="0" hint.da.1.at="scbus0" hint.da.1.target="9" hint.da.1.unit="0" hint.da.2.at="scbus0" hint.da.2.target="10" hint.da.2.unit="0" hint.da.3.at="scbus0" hint.da.3.target="11" hint.da.3.unit="0" hint.da.4.at="scbus0" hint.da.4.target="12" hint.da.4.unit="0" hint.da.5.at="scbus0" hint.da.5.target="13" hint.da.5.unit="0" hint.da.8.at="scbus0" hint.da.8.target="19" hint.da.8.unit="0" hint.da.9.at="scbus0" hint.da.9.target="20" hint.da.9.unit="0" hint.da.11.at="scbus0" hint.da.11.target="22" hint.da.11.unit="0" hint.da.12.at="scbus0" hint.da.12.target="23" hint.da.12.unit="0" hint.da.13.at="scbus0" hint.da.13.target="24" hint.da.13.unit="0" hint.da.14.at="scbus0" hint.da.14.target="27" hint.da.14.unit="0" hint.da.15.at="scbus0" hint.da.15.target="28" hint.da.15.unit="0" Naturally you can do the same for your AHCI controller bits too, though understand that each channel/port on the controller there matches to a separate scbusX unit, so you may want to start the numbering higher (in the case the LSI controller could ever have more scbusX entries added; e.g. LVMs or similar -- not sure how those are implemented there, but it doesn't matter, you get my drift I hope). -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | 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 "freebsd-stable-unsubscr...@freebsd.org"
Re: LSI supported mps(4) driver in stable/9 and stable/8
Jeremy Chadwick schreef: On Mon, Feb 13, 2012 at 03:49:41AM -0800, Jeremy Chadwick wrote: On Mon, Feb 13, 2012 at 12:11:30PM +0100, Johan Hendriks wrote: Ok so it is not the mps driver who does the naming but cam, and that also has changed on 9.0 Stable. Well i use gpart labels for the pool, so i can use the gpart labels to yank the right disk. But it would be nicer if there was some kind of logic in the numbering of the devices. "Wire them down" in FreeBSD using loader.conf variables and this issue will cease to be a problem. Example is below, despite being for SATA with AHCI -- really doesn't matter, just change the appropriate bits and it should be fine for you. # "Wire down" device names (ada[0-5]) to each individual port # on the SATA/AHCI controller. This ensures that if we reboot # with a disk missing, the device names stay the same, and stay # attached to the same SATA/AHCI controller. # http://lists.freebsd.org/pipermail/freebsd-fs/2011-March/011036.html # hint.scbus.0.at="ahcich0" hint.scbus.1.at="ahcich1" hint.scbus.2.at="ahcich2" hint.scbus.3.at="ahcich3" hint.scbus.4.at="ahcich4" hint.scbus.5.at="ahcich5" hint.ada.0.at="scbus0" hint.ada.1.at="scbus1" hint.ada.2.at="scbus2" hint.ada.3.at="scbus3" hint.ada.4.at="scbus4" hint.ada.5.at="scbus5" To be more specific: please see the CAM(4) man page and look at some of the example hint settings shown there. In your case I believe you'd want the below (which is a static map that matches your provided dmesg in the previous mail). If you want different device names tied to the different targets, it should be pretty obvious what to change. hint.scbus.0.at="mps0" hint.da.0.at="scbus0" hint.da.0.target="8" hint.da.0.unit="0" hint.da.1.at="scbus0" hint.da.1.target="9" hint.da.1.unit="0" hint.da.2.at="scbus0" hint.da.2.target="10" hint.da.2.unit="0" hint.da.3.at="scbus0" hint.da.3.target="11" hint.da.3.unit="0" hint.da.4.at="scbus0" hint.da.4.target="12" hint.da.4.unit="0" hint.da.5.at="scbus0" hint.da.5.target="13" hint.da.5.unit="0" hint.da.8.at="scbus0" hint.da.8.target="19" hint.da.8.unit="0" hint.da.9.at="scbus0" hint.da.9.target="20" hint.da.9.unit="0" hint.da.11.at="scbus0" hint.da.11.target="22" hint.da.11.unit="0" hint.da.12.at="scbus0" hint.da.12.target="23" hint.da.12.unit="0" hint.da.13.at="scbus0" hint.da.13.target="24" hint.da.13.unit="0" hint.da.14.at="scbus0" hint.da.14.target="27" hint.da.14.unit="0" hint.da.15.at="scbus0" hint.da.15.target="28" hint.da.15.unit="0" Naturally you can do the same for your AHCI controller bits too, though understand that each channel/port on the controller there matches to a separate scbusX unit, so you may want to start the numbering higher (in the case the LSI controller could ever have more scbusX entries added; e.g. LVMs or similar -- not sure how those are implemented there, but it doesn't matter, you get my drift I hope). Thanks i will look into this, and the enclosure slot mapping. Thank you all for your time. And sorry for using this topic as it was not related. regards Johan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: disk devices speed is ugly
On Mon, Feb 13, 2012 at 07:36:25AM +0100, Alex Samorukov wrote: > On 02/13/2012 06:27 AM, Adrian Chadd wrote: > >On 12 February 2012 09:34, Alex Samorukov wrote: > > > >>Yes. But it will nit fix non-cached access to the disk (raw) devices. And > >>this is the main reason why ntfs-3g and exfat are much slower then working > >>on Linux. > >But _that_ can be fixed with the appropriate application of a sensible > >caching layer. > With every application? :) Are you know anyone who wants to do this? At > least for 3 fuse filesystems. The filesystem is the *BEST* place to do caching. It knows what metadata is most effective to cache and what other data (e.g. file contents) doesn't need to be cached. Any attempt to do this in layers between the FS and the disk won't achieve the same gains as a properly written filesystem. e.g. in a UFS implementation the disk layer may see a lot of I/Os for blocks, not necessarily sequential, as a program lists a directory and stats all the files which pulls in the inode tables. The filesystem knows that it needs the inode tables and is likely to need not only the current inode table disk block but subsequent ones also, and instead of requesting the disk sector that it needs to service the immediate stat(2) request but maybe the next few also. Without that insight into whats going on it is difficult to see how a highly effective cache could be done at the geom layer. Gary ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: LSI supported mps(4) driver in stable/9 and stable/8
According to Kenneth D. Merry: > The LSI-supported version of the mps(4) driver that supports their 6Gb SAS > HBAs as well as WarpDrive controllers, is now in stable/9 and stable/8. Thanks. > Note that the CAM infrastructure changes that went into FreeBSD/head along > with this driver have not gone into either stable/9 or stable/8. Only the > driver itself has been merged. > > The CAM infrastructure changes depend on some other da(4) driver changes > that will need to get merged before they can go back. If that merge > happens, it will probably only be into stable/9. Got an ETA for this? Saying differently, is it reasonable to run stable/9 with the new driver but w/o the CAM changes? What do these changes bring BTW? Sorry, been out-of-touch these days :( Thanks. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.net In memoriam to Ondine, our 2nd child: http://ondine.keltia.net/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: disk devices speed is ugly
On 02/13/2012 02:28 PM, Gary Palmer wrote: Yes. But it will nit fix non-cached access to the disk (raw) devices. And this is the main reason why ntfs-3g and exfat are much slower then working on Linux. But _that_ can be fixed with the appropriate application of a sensible caching layer. With every application? :) Are you know anyone who wants to do this? At least for 3 fuse filesystems. The filesystem is the *BEST* place to do caching. It knows what metadata is most effective to cache and what other data (e.g. file contents) doesn't need to be cached. Any attempt to do this in layers between the FS and the disk won't achieve the same gains as a properly written filesystem. e.g. in a UFS implementation the disk layer may see a lot of I/Os for blocks, not necessarily sequential, as a program lists a directory and stats all the files which pulls in the inode tables. The filesystem knows that it needs the inode tables and is likely to need not only the current inode table disk block but subsequent ones also, and instead of requesting the disk sector that it needs to service the immediate stat(2) request but maybe the next few also. Without that insight into whats going on it is difficult to see how a highly effective cache could be done at the geom layer. I think we are playing in a "captain obvious". I have nothing against statement that FS is a "best place for caching". Also - i am absolutely sure that its better to have kernel space fs driver then FUSE one. But unfortunately there is no kernel space driver for the exfat, kernel driver for ntfs is ugly and buggy (and r/o) and i don`t think that anyone is going to change this. And i really don`t understand why are you trying to tell that it cannot be effective when its so easy to proof that it can. Just try this with fuse based filesystems in Linux, and you will get speed compared to underlying device (especially on relatively slow USB devices). Then try the same code on FreeBSD to see how ugly things are. And yes, in ideal world ever fs needs to have good written cache implementation and kernel should not care about caching raw devices at all. But as i mentioned before - there is no kernel-space drivers with a good cache implementation for this 2 widely used systems (and probably not only). Linux is a good example that device-level caching works, and works fine. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: New BSD Installer
I don't think that reverting is either an option or a solution at this point. You can consider filing PRs. -- George Kontostanos Aicom telecoms ltd http://www.aisecure.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Reducing the need to compile a custom kernel
Jeremy Chadwick wrote: I want to note here: the pf ALTQ options are a pain in the butt, quite honestly. I've found in the past that removing the ones you don't use won't result in a successful build, thus one must include them all. We do need ALTQ support though, for rate-limiting capability. The NOPCC option is needed for SMP builds, which makes me wonder what the state of SMP is in this regard -- meaning, on non-SMP builds, is it still safe to include ALTQ_NOPCC? It seems like I'm missing something. What is good about using non-SMP kernel? -- Sphinx of black quartz judge my vow. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Tuning needed for slow RDP FreeBSD 9 -> Win 2008 R2
On 13/02/2012 02:50, Peter Olsson wrote: > Desktop: FreeBSD 9.0-RELEASE amd64, generic kernel, > running Openbox. My WAN is about 1.2 Mbps, and I try > to run RDP to windows servers beyond my WAN. > > RDP to a Windows Server 2003 SP2 is fast and works > without problems. > > RDP to a Windows Server 2008 R2 is very slow, > and sometimes just disconnects. > > I tried changing a couple of net.inet.tcp sysctl: > Nothing has helped, do you have any ideas what I > should tune? It is highly unlikely that any network tuning will help here - this is almost certainly an application-level problem. For what it's worth, I'm using rdesktop to a Win2k8 R2 server without any lag other problems. signature.asc Description: OpenPGP digital signature
Re: Swap on zvol - recommendable?
> > I can confirm that this is still a problem on 8.2 and 9.0. > > -- > CTO, Hybrid Logic > +447791750420 | +1-415-449-1165 | www.hybrid-cluster.com > > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" You can not compare 8.2 with 9.0 per ZFS. What problems are you facing with your swap in 9.0 ? -- George Kontostanos Aicom telecoms ltd http://www.aisecure.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Tuning needed for slow RDP FreeBSD 9 -> Win 2008 R2
On Mon, Feb 13, 2012 at 04:09:05PM +0100, Ivan Voras wrote: > On 13/02/2012 02:50, Peter Olsson wrote: > > Desktop: FreeBSD 9.0-RELEASE amd64, generic kernel, > > running Openbox. My WAN is about 1.2 Mbps, and I try > > to run RDP to windows servers beyond my WAN. > > > > RDP to a Windows Server 2003 SP2 is fast and works > > without problems. > > > > RDP to a Windows Server 2008 R2 is very slow, > > and sometimes just disconnects. > > > > I tried changing a couple of net.inet.tcp sysctl: > > > Nothing has helped, do you have any ideas what I > > should tune? > > It is highly unlikely that any network tuning will help here - this is > almost certainly an application-level problem. > > For what it's worth, I'm using rdesktop to a Win2k8 R2 server without > any lag other problems. I have a colleague who runs Crunchbang (ie Debian) desktop. He had exactly the same performance problem until he used these sysctl: net.core.rmem_max=1048576 net.core.rmem_default=1048576 net.core.wmem_max=1048576 net.core.wmem_default=1048576 net.ipv4.tcp_rmem=1048576 1048576 3444736 net.ipv4.tcp_wmem=1048576 1048576 3444736 I don't know where he got those values, or what they could be translated to in FreeBSD, but they did solve the problem for him. That's why I'm hoping to find a similar sysctl solution for FreeBSD. I did sysctl -a | grep mem and grep buf, but find nothing obvious, except the net.inet.tcp.recvbuf and sendbuf values I have already tried changing. Also, I run Win7 in Virtualbox in my desktop, and from that Win7 I don't have the performance problem towards that RDP server. -- Peter Olssonp...@leissner.se ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Tuning needed for slow RDP FreeBSD 9 -> Win 2008 R2
On Mon, Feb 13, 2012 at 02:50:13AM +0100, Peter Olsson wrote: > Desktop: FreeBSD 9.0-RELEASE amd64, generic kernel, > running Openbox. My WAN is about 1.2 Mbps, and I try > to run RDP to windows servers beyond my WAN. > > RDP to a Windows Server 2003 SP2 is fast and works > without problems. > > RDP to a Windows Server 2008 R2 is very slow, > and sometimes just disconnects. > > I tried changing a couple of net.inet.tcp sysctl: > net.inet.tcp.recvbuf_max=10485760 > net.inet.tcp.recvbuf_inc=65535 > net.inet.tcp.sendbuf_max=10485760 > net.inet.tcp.sendbuf_inc=65535 > net.inet.tcp.recvbuf_auto=0 > net.inet.tcp.sendbuf_auto=0 > net.inet.tcp.sendspace=65536 > net.inet.tcp.ecn.enable=1 > net.inet.tcp.delayed_ack=0 > net.inet.tcp.tso=0 > net.inet.tcp.sack.enable=0 > net.inet.tcp.path_mtu_discovery=0 > > Some in combination with others, and some by themselves. > > I also tried net.link.ifqmaxlen=1024 in /boot/loader.conf. > > Nothing has helped, do you have any ideas what I > should tune? The above things you've tinkered with have probably done more damage than good. I strongly recommend you not "flail around" when it comes to adjustments like this; just guessing at seemingly random sysctls is a really bad idea. Please don't do this, for your own sake. You should probably engage a networking resource within your company or upstream from you, and provide them packet captures taken from both the FreeBSD machine as well as the Windows machine. Also, you specify 9.0 -- does using 8.2 to RDP to the same W2K8 R2 server work/behave fine, and thus the problem started with 9.0? The only thing I can think of is possibly RFC1323 "quirks" causing some kind of problem across a WAN link, or some very bizarre behaviour in the Ethernet/NIC driver on FreeBSD. You should probably try to reproduce this problem on a LAN, because I can assure you if you're using RDP across the Internet, you will have zero (I repeat: ZERO) chance of figuring this one out without every peering provider getting involved (both forward path and return path). Remember: the Internet is broken 24x7x365, and dedicated links/circuits are often neglected by providers regardless of who they are or where they are. You really didn't give any hard evidence or technical information besides "I see this problem, what is the cause?" Engaging network engineers on your side would probably be a good first step. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | 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 "freebsd-stable-unsubscr...@freebsd.org"
Re: disk devices speed is ugly
On Mon, Feb 13, 2012 at 03:50:36PM +0100, Alex Samorukov wrote: > On 02/13/2012 02:28 PM, Gary Palmer wrote: > >>> > Yes. But it will nit fix non-cached access to the disk (raw) devices. > And > this is the main reason why ntfs-3g and exfat are much slower then > working > on Linux. > >>>But _that_ can be fixed with the appropriate application of a sensible > >>>caching layer. > >>With every application? :) Are you know anyone who wants to do this? At > >>least for 3 fuse filesystems. > >The filesystem is the *BEST* place to do caching. It knows what metadata > >is most effective to cache and what other data (e.g. file contents) doesn't > >need to be cached. Any attempt to do this in layers between the FS and > >the disk won't achieve the same gains as a properly written filesystem. > >e.g. in a UFS implementation the disk layer may see a lot of I/Os for > >blocks, not necessarily sequential, as a program lists a directory and > >stats > >all the files which pulls in the inode tables. The filesystem knows that > >it > >needs the inode tables and is likely to need not only the current inode > >table > >disk block but subsequent ones also, and instead of requesting the disk > >sector > >that it needs to service the immediate stat(2) request but maybe the next > >few > >also. Without that insight into whats going on it is difficult to see how > >a > >highly effective cache could be done at the geom layer. > I think we are playing in a "captain obvious". > > I have nothing against statement that FS is a "best place for caching". > Also - i am absolutely sure that its better to have kernel space fs > driver then FUSE one. > > But unfortunately there is no kernel space driver for the exfat, kernel > driver for ntfs is ugly and buggy (and r/o) and i don`t think that > anyone is going to change this. > > And i really don`t understand why are you trying to tell that it cannot > be effective when its so easy to proof that it can. Just try this with > fuse based filesystems in Linux, and you will get speed compared to > underlying device (especially on relatively slow USB devices). Then try > the same code on FreeBSD to see how ugly things are. > > And yes, in ideal world ever fs needs to have good written cache > implementation and kernel should not care about caching raw devices at > all. But as i mentioned before - there is no kernel-space drivers with a > good cache implementation for this 2 widely used systems (and probably > not only). Linux is a good example that device-level caching works, and > works fine. Please re-read my message. At no time did I say that caching below the FS could not provide speed improvements. I said it could not be as effective as a properly implemented filesystem. I'm sure if you throw memory at it, a geom layer cache can provide substantial speed ups. However I strongly suspect that a proper FS cache would provide a better memory/hit ratio than a geom layer cache. Gary ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Reducing the need to compile a custom kernel
Jeremy Chadwick wrote: On Mon, Feb 13, 2012 at 05:05:41PM +0200, Volodymyr Kostyrko wrote: Jeremy Chadwick wrote: I want to note here: the pf ALTQ options are a pain in the butt, quite honestly. I've found in the past that removing the ones you don't use won't result in a successful build, thus one must include them all. We do need ALTQ support though, for rate-limiting capability. The NOPCC option is needed for SMP builds, which makes me wonder what the state of SMP is in this regard -- meaning, on non-SMP builds, is it still safe to include ALTQ_NOPCC? It seems like I'm missing something. What is good about using non-SMP kernel? Nothing. It's a question of whether or not use of ALTQ_NOPCC causes breakage on non-SMP kernels, or if FreeBSD even bothers to support non-SMP at this point. "Non-SMP" means "without options SMP". You got my point. I'm a single core user today but I run SMP-enabled kernel. Rephrased: if SMP is the default, and "options SMP" works just fine on systems without multiple processors/cores, then the ALTQ_NOPCC option should probably be removed. Yep, works for me. However I had found some cruft about extra processing power which would be used in expense of correct work. Can this be something like IPFIREWALL_FORWARD that adds some latency to most cases providing some use only for chosen ones? -- Sphinx of black quartz judge my vow. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Reducing the need to compile a custom kernel
On Mon, Feb 13, 2012 at 05:05:41PM +0200, Volodymyr Kostyrko wrote: > Jeremy Chadwick wrote: > >I want to note here: the pf ALTQ options are a pain in the butt, quite > >honestly. I've found in the past that removing the ones you don't use > >won't result in a successful build, thus one must include them all. We > >do need ALTQ support though, for rate-limiting capability. The NOPCC > >option is needed for SMP builds, which makes me wonder what the state of > >SMP is in this regard -- meaning, on non-SMP builds, is it still safe > >to include ALTQ_NOPCC? > > It seems like I'm missing something. What is good about using > non-SMP kernel? Nothing. It's a question of whether or not use of ALTQ_NOPCC causes breakage on non-SMP kernels, or if FreeBSD even bothers to support non-SMP at this point. "Non-SMP" means "without options SMP". Rephrased: if SMP is the default, and "options SMP" works just fine on systems without multiple processors/cores, then the ALTQ_NOPCC option should probably be removed. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | 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 "freebsd-stable-unsubscr...@freebsd.org"
Re: New BSD Installer
On Mon, Feb 13, 2012 at 3:58 PM, George Kontostanos wrote: > I don't think that reverting is either an option or a solution at this > point. You can consider filing PRs. > How compatible is bsdinstaller with pc-sysinstaller? Are there any notes on why a new installer was created over reusing pc-sysinstall? Regards Andreas Nilsson > > -- > George Kontostanos > Aicom telecoms ltd > http://www.aisecure.net > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Reducing the need to compile a custom kernel
Alexander Leidinger wrote: Feasible: depend upon your definition of "feasible". You would have to add all keymaps statically into the kernel. No idea which parts exactly we talk about, but: ---snip--- % du -h /usr/share/syscons/ 40k /usr/share/syscons/scrnmaps 570k /usr/share/syscons/fonts 1.1M /usr/share/syscons/keymaps 1.8M /usr/share/syscons/ ---snip--- I wouldn't mind for 40k, but 1.8M looks more like the value to calculate with. Anyway, this is out of the scope of the original question. Correct me if I'm wrong but zfs already fetches plain file /boot/zfs/zpool.cache on load. Can't this be: 1. Postponed to later processing. 2. After filesystems are mounted the keymap is loaded. Or even: 1. Put all viable files on the / partition. 2. Select and load correct one before kernel is fired. -- Sphinx of black quartz judge my vow. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: New BSD Installer
pc-sysinstall doesn't work (well?) on non-x86 platforms so bsdinstall was created as an interim solution. -- Bruce Cran Sent from my iPhone On 13 Feb 2012, at 15:44, Andreas Nilsson wrote: > On Mon, Feb 13, 2012 at 3:58 PM, George Kontostanos > wrote: > >> I don't think that reverting is either an option or a solution at this >> point. You can consider filing PRs. >> > > How compatible is bsdinstaller with pc-sysinstaller? Are there any notes on > why a new installer was created over reusing pc-sysinstall? > > Regards > Andreas Nilsson > > >> >> -- >> George Kontostanos >> Aicom telecoms ltd >> http://www.aisecure.net >> ___ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" >> > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
ZFS faulted pool problem
Hi there, I run in production a FreeBSD-8 stable server with a ZFS file system. It used raidz2, so that ought to be very safe, I thought. Recently a disk failed, and it was replaced today. However, the file pool doesn't want to come back. Below is the status. da4 was bad and was replaced (by a somewhat bigger disk) in-place. The raidz2 shows to be DEGRADED but somehow the pool as a whole is FAULTED? And whatever I do, the new disk isn't recognised. I cut and pasted some commands below. In all cases it complains that pool "tank" is unavailable... What to do? No I/O errors show up in /var/log/messages. Previously, I had some weird directory where there were CRC errors in the directory entries, and as long as you didn't try to do anything with the files, there was no problem. Removing them was impossible though. I hope it isn't that what is holding my whole pool hostage... I don't mind losing that one directory. fourquid.1:/lib$ sudo zpool status Password: pool: tank state: FAULTED status: One or more devices could not be opened. There are insufficient replicas for the pool to continue functioning. action: Attach the missing device and online it using 'zpool online'. see: http://www.sun.com/msg/ZFS-8000-3C scan: scrub repaired 0 in 49h3m with 2 errors on Fri Jan 20 15:10:35 2012 config: NAME STATE READ WRITE CKSUM tank FAULTED 0 0 2 raidz2-0 DEGRADED 0 0 8 da0 ONLINE 0 0 0 da1 ONLINE 0 0 0 da2 ONLINE 0 0 0 da3 ONLINE 0 0 0 3758301462980058947 UNAVAIL 0 0 0 was /dev/da4 da5 ONLINE 0 0 0 fourquid.1:/lib$ sudo zpool replace tank da4 cannot open 'tank': pool is unavailable fourquid.1:/lib$ sudo zpool replace raidz2-0 da4 cannot open 'raidz2-0': no such pool fourquid.1:/lib$ sudo zpool replace tank da4 da4 cannot open 'tank': pool is unavailable fourquid.1:/lib$ sudo zpool online tank da4 cannot open 'tank': pool is unavailable fourquid.1:/lib$ sudo zpool clear tank da4 cannot clear errors for da4: I/O error fourquid.1:/lib$ sudo zpool clear tank cannot clear errors for tank: I/O error fourquid.1:/lib$ sudo zpool replace tank 3758301462980058947 da4 cannot open 'tank': pool is unavailable fourquid.1:/lib$ sudo zpool scrub tank cannot scrub 'tank': pool is currently unavailable -Olaf. -- Pipe rene = new PipePicture(); assert(Not rene.GetType().Equals(Pipe)); ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Troube with SSD
On 2012-02-01 19:09, Willem Jan Withagen wrote: > On 2012-02-01 17:35, Jeremy Chadwick wrote: Hi Jeremy, Took a little longer, since "holidays got in the way". But even in the original server connected to regular intel sataports, the device is not known and 2 commands failed. Flash SSD is connected for about 1 hour now. --WjW >>> The output of the first one command, but it contains some real weird >>> values.?? >> >> All the values below look fine to me. I will try my best to explain. > >>> SMART Attributes Data Structure revision number: 10 >>> Vendor Specific SMART Attributes with Thresholds: >>> ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED >>> WHEN_FAILED RAW_VALUE >>> 1 Raw_Read_Error_Rate 0x000f 082 082 050Pre-fail Always >>>- 897651373777 >>> 5 Reallocated_Sector_Ct 0x0033 100 100 003Pre-fail Always >>>- 0 >>> 9 Power_On_Hours 0x0032 100 100 000Old_age Always >>>- 121242631799621 >>> 12 Power_Cycle_Count 0x0032 100 100 000Old_age Always >>>- 31 >>> 171 Unknown_Attribute 0x0032 000 000 000Old_age Always >>>- 0 >>> 172 Unknown_Attribute 0x0032 000 000 000Old_age Always >>>- 0 >>> 174 Unknown_Attribute 0x0030 000 000 000Old_age Offline >>>- 19 >>> 177 Wear_Leveling_Count 0x 000 000 000Old_age Offline >>>- 0 >>> 181 Program_Fail_Cnt_Total 0x0032 000 000 000Old_age Always >>>- 0 >>> 182 Erase_Fail_Count_Total 0x0032 000 000 000Old_age Always >>>- 0 >>> 187 Reported_Uncorrect 0x0032 100 100 000Old_age Always >>>- 0 >>> 194 Temperature_Celsius 0x0022 026 035 000Old_age Always >>>- 26 (Min/Max 21/35) >>> 195 Hardware_ECC_Recovered 0x001c 120 120 000Old_age Offline >>>- 897651373777 >>> 196 Reallocated_Event_Count 0x0033 100 100 003Pre-fail Always >>>- 0 >>> 201 Soft_Read_Error_Rate0x001c 120 120 000Old_age Offline >>>- 897651373777 >>> 204 Soft_ECC_Correction 0x001c 120 120 000Old_age Offline >>>- 897651373777 >>> 230 Head_Amplitude 0x0013 100 100 000Pre-fail Always >>>- 429496729700 >>> 231 Temperature_Celsius 0x0013 100 100 010Pre-fail Always >>>- 0 >>> 233 Media_Wearout_Indicator 0x 000 000 000Old_age Offline >>>- 1260 >>> 234 Unknown_Attribute 0x0032 000 000 000Old_age Always >>>- 1925 >>> 241 Total_LBAs_Written 0x0032 000 000 000Old_age Always >>>- 1925 >>> 242 Total_LBAs_Read 0x0032 000 000 000Old_age Always >>>- 1032 * smartctl -l devstat /dev/whatever * smartctl -l sataphy /dev/whatever * smartctl -l ssd /dev/whatever > > It'll have to wait until later this evening, before I able to swap the > disk back in the old box. [~wjw] r...@zfs.digiware.nl# smartctl -l devstat /dev/ada2 smartctl 5.42 2011-10-20 r3458 [FreeBSD 8.2-STABLE amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net Device Statistics (GP Log 0x04) not supported [~wjw] r...@zfs.digiware.nl# smartctl -l sataphy /dev/ada2 smartctl 5.42 2011-10-20 r3458 [FreeBSD 8.2-STABLE amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net SATA Phy Event Counters (GP Log 0x11) ID Size Value Description 0x0001 40 Command failed due to ICRC error 0x0003 40 R_ERR response for device-to-host data FIS 0x0004 40 R_ERR response for host-to-device data FIS 0x0006 40 R_ERR response for device-to-host non-data FIS 0x0007 40 R_ERR response for host-to-device non-data FIS 0x0008 40 Device-to-host non-data FIS retries 0x0009 40 Transition from drive PhyRdy to drive PhyNRdy 0x000a 4 11 Device-to-host register FISes sent due to a COMRESET 0x000f 40 R_ERR response for host-to-device data FIS, CRC 0x0010 40 R_ERR response for host-to-device data FIS, non-CRC 0x0012 40 R_ERR response for host-to-device non-data FIS, CRC 0x0013 4 0 R_ERR response for host-to-device non-data FIS, non-CRC 0x0002 40 R_ERR response for data FIS 0x0005 40 R_ERR response for non-data FIS 0x000b 40 CRC errors within host-to-device FIS 0x000d 40 Non-CRC errors within host-to-device FIS [~wjw] r...@zfs.digiware.nl# smartctl -l ssd /dev/ada2 smartctl 5.42 2011-10-20 r3458 [FreeBSD 8.2-STABLE amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net Device Statistics (GP Log 0x04) not supported --
Re: Troube with SSD
On Mon, Feb 13, 2012 at 05:15:42PM +0100, Willem Jan Withagen wrote: > On 2012-02-01 19:09, Willem Jan Withagen wrote: > > On 2012-02-01 17:35, Jeremy Chadwick wrote: > > Hi Jeremy, > > Took a little longer, since "holidays got in the way". > But even in the original server connected to regular intel sataports, > the device is not known and 2 commands failed. > > Flash SSD is connected for about 1 hour now. > > --WjW > > > >>> The output of the first one command, but it contains some real weird > >>> values.?? > >> > >> All the values below look fine to me. I will try my best to explain. > > > >>> SMART Attributes Data Structure revision number: 10 > >>> Vendor Specific SMART Attributes with Thresholds: > >>> ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED > >>> WHEN_FAILED RAW_VALUE > >>> 1 Raw_Read_Error_Rate 0x000f 082 082 050Pre-fail Always > >>> - 897651373777 > >>> 5 Reallocated_Sector_Ct 0x0033 100 100 003Pre-fail Always > >>> - 0 > >>> 9 Power_On_Hours 0x0032 100 100 000Old_age Always > >>> - 121242631799621 > >>> 12 Power_Cycle_Count 0x0032 100 100 000Old_age Always > >>> - 31 > >>> 171 Unknown_Attribute 0x0032 000 000 000Old_age Always > >>> - 0 > >>> 172 Unknown_Attribute 0x0032 000 000 000Old_age Always > >>> - 0 > >>> 174 Unknown_Attribute 0x0030 000 000 000Old_age Offline > >>> - 19 > >>> 177 Wear_Leveling_Count 0x 000 000 000Old_age Offline > >>> - 0 > >>> 181 Program_Fail_Cnt_Total 0x0032 000 000 000Old_age Always > >>> - 0 > >>> 182 Erase_Fail_Count_Total 0x0032 000 000 000Old_age Always > >>> - 0 > >>> 187 Reported_Uncorrect 0x0032 100 100 000Old_age Always > >>> - 0 > >>> 194 Temperature_Celsius 0x0022 026 035 000Old_age Always > >>> - 26 (Min/Max 21/35) > >>> 195 Hardware_ECC_Recovered 0x001c 120 120 000Old_age Offline > >>> - 897651373777 > >>> 196 Reallocated_Event_Count 0x0033 100 100 003Pre-fail Always > >>> - 0 > >>> 201 Soft_Read_Error_Rate0x001c 120 120 000Old_age Offline > >>> - 897651373777 > >>> 204 Soft_ECC_Correction 0x001c 120 120 000Old_age Offline > >>> - 897651373777 > >>> 230 Head_Amplitude 0x0013 100 100 000Pre-fail Always > >>> - 429496729700 > >>> 231 Temperature_Celsius 0x0013 100 100 010Pre-fail Always > >>> - 0 > >>> 233 Media_Wearout_Indicator 0x 000 000 000Old_age Offline > >>> - 1260 > >>> 234 Unknown_Attribute 0x0032 000 000 000Old_age Always > >>> - 1925 > >>> 241 Total_LBAs_Written 0x0032 000 000 000Old_age Always > >>> - 1925 > >>> 242 Total_LBAs_Read 0x0032 000 000 000Old_age Always > >>> - 1032 > > * smartctl -l devstat /dev/whatever > * smartctl -l sataphy /dev/whatever > * smartctl -l ssd /dev/whatever > > > > It'll have to wait until later this evening, before I able to swap the > > disk back in the old box. > > [~wjw] r...@zfs.digiware.nl# smartctl -l devstat /dev/ada2 > smartctl 5.42 2011-10-20 r3458 [FreeBSD 8.2-STABLE amd64] (local build) > Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net > > Device Statistics (GP Log 0x04) not supported > [~wjw] r...@zfs.digiware.nl# smartctl -l sataphy /dev/ada2 > smartctl 5.42 2011-10-20 r3458 [FreeBSD 8.2-STABLE amd64] (local build) > Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net > > SATA Phy Event Counters (GP Log 0x11) > ID Size Value Description > 0x0001 40 Command failed due to ICRC error > 0x0003 40 R_ERR response for device-to-host data FIS > 0x0004 40 R_ERR response for host-to-device data FIS > 0x0006 40 R_ERR response for device-to-host non-data FIS > 0x0007 40 R_ERR response for host-to-device non-data FIS > 0x0008 40 Device-to-host non-data FIS retries > 0x0009 40 Transition from drive PhyRdy to drive PhyNRdy > 0x000a 4 11 Device-to-host register FISes sent due to a COMRESET > 0x000f 40 R_ERR response for host-to-device data FIS, CRC > 0x0010 40 R_ERR response for host-to-device data FIS, non-CRC > 0x0012 40 R_ERR response for host-to-device non-data FIS, CRC > 0x0013 4 0 R_ERR response for host-to-device non-data FIS, non-CRC > 0x0002 40 R_ERR response for data FIS > 0x0005 40 R_ERR response for non-data FIS > 0x000b 40 CRC errors within host-to-device FIS > 0x000d 40 Non-CRC errors within
lock violation in unionfs (9.0-STABLE r230270)
http://www.freebsd.org/cgi/query-pr.cgi?pr=165087 Occurs simply trying to use unionfs: mount -t unionfs -o noatime /usr /mnt insmntque: mp-safe fs and non-locked vp: 0xfe01d96704f0 is not exclusive locked but should be KDB: enter: lock violation Its possible to continue tho. Then locks encounter on every file/dir access under mounted path. It can be resumed from KDB, but sometimes leads to deadlock and system freezes at "db> " prompt. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: New BSD Installer
On 13 feb 2012, at 17:08, Bruce Cran wrote: > pc-sysinstall doesn't work (well?) on non-x86 platforms so bsdinstall was > created as an interim solution. I'll take your word for it, but as far as I know the backend is shell-based as well. /Andreas > > -- > Bruce Cran > > Sent from my iPhone > > On 13 Feb 2012, at 15:44, Andreas Nilsson wrote: > >> On Mon, Feb 13, 2012 at 3:58 PM, George Kontostanos >> wrote: >> >>> I don't think that reverting is either an option or a solution at this >>> point. You can consider filing PRs. >>> >> >> How compatible is bsdinstaller with pc-sysinstaller? Are there any notes on >> why a new installer was created over reusing pc-sysinstall? >> >> Regards >> Andreas Nilsson >> >> >>> >>> -- >>> George Kontostanos >>> Aicom telecoms ltd >>> http://www.aisecure.net >>> ___ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" >>> >> ___ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Swap on zvol - recommendable?
On Mon, Feb 13, 2012 at 9:02 AM, George Kontostanos wrote: > > > > I can confirm that this is still a problem on 8.2 and 9.0. > > > > > You can not compare 8.2 with 9.0 per ZFS. What problems are you facing > with your swap in 9.0 ? > I suppose you are having problems similar to the following: http://lists.freebsd.org/pipermail/freebsd-fs/2012-January/013546.html Perhaps setting vfs.zfs.arc_max to some reasonable value might help, but that is just a guess. -- Adam Vande More ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: disk devices speed is ugly
I tend to say "the right solution to a problem is to not do it wrong." But.. given that Linux is fine with all the unaligned accesses, is the major sticking point here the fact that Linux's block dev layer is doing all the caching that FreeBSD's direct device layer isn't, and all of those (cached) accesses are what is improving performance? So perhaps it'd be worthwhile investing some time in a geom caching layer to see if that's at all feasible. I had the same problem with userland cyclic filesystems on FreeBSD versus Linux - the Linux FS performed better in synthetic tests because it did caching of the blockdev data. FreeBSD was doing direct IO. Tuning the direct IO sizes and fixing the filesystem code to do everything correctly aligned eliminated a lot of the ridiculous issues. Making Squid cache reads from disk would've improved it too. :-) Finally - I've seen this same issue under linux, especially when you stick a filesystem on a RAID device with the stripe/alignment all wrong. It's not just a BSD problem. :) Adrian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
sysutils/pftop on 9.x+
sysutils/pftop was marked broken on 9.x and above last March[1]. Are there any plans to fix it soon? It's a really handy utility. [1] http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/pftop/Makefile?rev=1.17 -- Greg Rivers ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Why won't 8.2 umount -f?
Is there some magic I'm missing to convince an 8.2 system to umount -f? I had an NFS server crash, so I'm trying to get the mounts updated. All of the 7.x systems happily did 'umount -f', but the 8.x systems (mostly 8.2-pN) are just hanging forever. Is this a bug, or is it something I'm missing? Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: New BSD Installer
On 13/02/2012 17:41, Andreas Nilsson wrote: On 13 feb 2012, at 17:08, Bruce Cran wrote: pc-sysinstall doesn't work (well?) on non-x86 platforms so bsdinstall was created as an interim solution. I'll take your word for it, but as far as I know the backend is shell-based as well. Yes, they're both written in shell script - that's the only compatibility there is between bsdinstall and pc-sysinstall. -- Bruce Cran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Why won't 8.2 umount -f?
On 02/13/2012 13:02, Doug Barton wrote: > Is there some magic I'm missing to convince an 8.2 system to umount -f? > I had an NFS server crash, so I'm trying to get the mounts updated. All > of the 7.x systems happily did 'umount -f', but the 8.x systems (mostly > 8.2-pN) are just hanging forever. ... and it gets worse. I just 'shutdown -r now'ed one of my less-critical 8.2 systems, and it hung for several minutes after "All buffers synced." After a power cycle it came back, but the buffers weren't actually synced because it's still fsck'ing some pretty large file systems. What the heck? -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Troube with SSD
On 13-2-2012 17:28, Jeremy Chadwick wrote: > On Mon, Feb 13, 2012 at 05:15:42PM +0100, Willem Jan Withagen wrote: >> On 2012-02-01 19:09, Willem Jan Withagen wrote: >>> On 2012-02-01 17:35, Jeremy Chadwick wrote: > The SATA PHY counters for the disk, kept in GP log area 0x11, look > perfectly fine. The 11 you see at offset 0xa are completely fine; > nothing to worry about there. > > Sadly the SSD does not support GP log area 0x04. > > Overall I see no real problems with the drive itself given the > information above, which is literally all I can go off of. Sorry I > can't be of more assistance past this point; honestly your drive looks > fine given what I can tell. Only Corsair would be able to help at this > point, but it's unlikely any Tier 1 individual would know how to > troubleshoot this kind of thing. I'll let it run, until it disconnects again, and I'll check to see what the SATA stats are. Perhaps there is something that triggers. But that might take a few days Last time it took 23 days under my regular load to be dropped from the bus. --WjW ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Why won't 8.2 umount -f?
On Mon, Feb 13, 2012 at 10:20 PM, Doug Barton wrote: > On 02/13/2012 13:02, Doug Barton wrote: > > Is there some magic I'm missing to convince an 8.2 system to umount -f? > > I had an NFS server crash, so I'm trying to get the mounts updated. All > > of the 7.x systems happily did 'umount -f', but the 8.x systems (mostly > > 8.2-pN) are just hanging forever. > > ... and it gets worse. I just 'shutdown -r now'ed one of my > less-critical 8.2 systems, and it hung for several minutes after "All > buffers synced." After a power cycle it came back, but the buffers > weren't actually synced because it's still fsck'ing some pretty large > file systems. > > What the heck? > > -- > >It's always a long day; 86400 doesn't fit into a short. > >Breadth of IT experience, and depth of knowledge in the DNS. >Yours for the right price. :) http://SupersetSolutions.com/ > > ___ > freebsd...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscr...@freebsd.org" > Ok, I remember another bug we had some while ago ... so, humor me on this: reproduce the problem where you "shutdown -r now", actually do "shutdown -r now" and leave it be, but check the time at which you issued the cmd. If this is the old but I was told about, the system should reboot exactly after 60 minutes (1 hour). PS: I might be wrong, It's just a hunch. -- Best regards, Claudiu Vasadi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
RE: Re: Why won't 8.2 umount -f?
> Original Message > Subject: Re: Why won't 8.2 umount -f? > Date: Mon, 13 Feb 2012 13:20:55 -0800 > From: Doug Barton > Organization: http://SupersetSolutions.com/ > To: > CC: > Cross posting? (gasp!) > On 02/13/2012 13:02, Doug Barton wrote: > > Is there some magic I'm missing to convince an 8.2 system to umount -f? > > I had an NFS server crash, so I'm trying to get the mounts updated. All > > of the 7.x systems happily did 'umount -f', but the 8.x systems (mostly > > 8.2-pN) are just hanging forever. > > ... and it gets worse. I just 'shutdown -r now'ed one of my > less-critical 8.2 systems, and it hung for several minutes after "All > buffers synced." After a power cycle it came back, but the buffers > weren't actually synced because it's still fsck'ing some pretty large > file systems. > > What the heck? We've noticed this behavior too (on 8.1-RELEASE-p6). The work-around (to avoid long fsck) is to: 1. Drop to the kernel debugger (Ctrl+Alt+ESC -- requires DDB to be enabled in kernel) 2. Type: call boot(0) This causes the system to attempt a second sync of the buffers. This second attempt ends up timing out but succeeds in resetting the CPU (after 3x 60s timeouts). The price (waiting 180s before cpu_reset() is called) can be well worth it (avoiding multi-hour fsck) because the disks will be marked clean. For us, this is a serious issue and like Doug, we too exclaim "what the heck?" Shouldn't have to drop to kernel debugger and [redundantly] invoke boot(0) after syncer's hang just prior to cpu_reset(). -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Why won't 8.2 umount -f?
Doug Barton wrote: > Is there some magic I'm missing to convince an 8.2 system to umount > -f? > I had an NFS server crash, so I'm trying to get the mounts updated. > All > of the 7.x systems happily did 'umount -f', but the 8.x systems > (mostly > 8.2-pN) are just hanging forever. > > Is this a bug, or is it something I'm missing? > Well, I didn't realize that a 7.n system would "umount -f" an NFS mount when the server was down and there were dirty blocks that needed to be written back, but I don't know. (I seem to recall that someone encouraged me to MFC one of my changes related to this back to stable/7, but I'm not sure if it mattered?) I have pretty well fixed the new client w.r.t. this except for the case where you do a "umount " and that gets hung. Once a non "-f" umount gets hung, there is nothing you can do, because the mount point is locked up, so a subsequent "umount -f" can't get as far as nfs_umount(). My guess is that the old (default for 8.n) client isn't fixed for this. If you "grep MNTK_UNMOUNTF" in the sources, you'll see it used some in the old/regular client, but not as much as the new one. You also need a fairly recent (can't remember if that is in 8.2) version of umount.c, since the code had a "sync();" at the beginning of it that would hang before even getting to the umount(2) syscall. Bottom line, I think the newnfs client (the default for 9.0) can do this, but I'm doubtful the old/reguler one can. (I also wouldn't be surprised if there is still a bug other than the above mentioned one w.r.t. doing a "umount /mnt" and getting that hung before trying "umount -f /mnt". rick > > Doug > > -- > > It's always a long day; 86400 doesn't fit into a short. > > Breadth of IT experience, and depth of knowledge in the DNS. > Yours for the right price. :) http://SupersetSolutions.com/ > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Why won't 8.2 umount -f?
On 02/13/2012 18:23, Rick Macklem wrote: > Doug Barton wrote: >> Is there some magic I'm missing to convince an 8.2 system to umount >> -f? >> I had an NFS server crash, so I'm trying to get the mounts updated. >> All >> of the 7.x systems happily did 'umount -f', but the 8.x systems >> (mostly >> 8.2-pN) are just hanging forever. >> >> Is this a bug, or is it something I'm missing? >> > Well, I didn't realize that a 7.n system would "umount -f" an NFS > mount when the server was down and there were dirty blocks that > needed to be written back, but I don't know. I'm doubtful that any of those systems had dirty blocks. > (I seem to recall that > someone encouraged me to MFC one of my changes related to this back > to stable/7, but I'm not sure if it mattered?) Please don't unless you can verify that it doesn't make this situation worse. :) > I have pretty well fixed the new client w.r.t. this except for the > case where you do a "umount " and that gets hung. Once a non "-f" > umount gets hung, there is nothing you can do, because the mount point is > locked up, so a subsequent "umount -f" can't get as far as nfs_umount(). I'm aware of this issue, and I did 'umount -f' first. But I wonder if this isn't something that should be fixed because I think most users would expect that 'umount -> umount -f' would be the natural progression, similar to 'kill -> kill -9'. > My guess is that the old (default for 8.n) client isn't fixed for > this. If you "grep MNTK_UNMOUNTF" in the sources, you'll see it > used some in the old/regular client, but not as much as the new one. > > You also need a fairly recent (can't remember if that is in 8.2) > version of umount.c, since the code had a "sync();" at the beginning > of it that would hang before even getting to the umount(2) syscall. > > Bottom line, I think the newnfs client (the default for 9.0) can > do this, but I'm doubtful the old/reguler one can. (I also wouldn't > be surprised if there is still a bug other than the above mentioned > one w.r.t. doing a "umount /mnt" and getting that hung before trying > "umount -f /mnt". Is the new client in 8-stable up to date relevant to 9.0, and/or is it considered safe to use in production? Thanks, Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Why won't 8.2 umount -f?
Doug Barton wrote: > On 02/13/2012 18:23, Rick Macklem wrote: > > Doug Barton wrote: > >> Is there some magic I'm missing to convince an 8.2 system to umount > >> -f? > >> I had an NFS server crash, so I'm trying to get the mounts updated. > >> All > >> of the 7.x systems happily did 'umount -f', but the 8.x systems > >> (mostly > >> 8.2-pN) are just hanging forever. > >> > >> Is this a bug, or is it something I'm missing? > >> > > Well, I didn't realize that a 7.n system would "umount -f" an NFS > > mount when the server was down and there were dirty blocks that > > needed to be written back, but I don't know. > > I'm doubtful that any of those systems had dirty blocks. > > > (I seem to recall that > > someone encouraged me to MFC one of my changes related to this back > > to stable/7, but I'm not sure if it mattered?) > > Please don't unless you can verify that it doesn't make this situation > worse. :) > sbruno did the MFC. I don't think the changes would make it worse. > > I have pretty well fixed the new client w.r.t. this except for the > > case where you do a "umount " and that gets hung. Once a non > > "-f" > > umount gets hung, there is nothing you can do, because the mount > > point is > > locked up, so a subsequent "umount -f" can't get as far as > > nfs_umount(). > > I'm aware of this issue, and I did 'umount -f' first. But I wonder if > this isn't something that should be fixed because I think most users > would expect that 'umount -> umount -f' would be the natural > progression, similar to 'kill -> kill -9'. > > > My guess is that the old (default for 8.n) client isn't fixed for > > this. If you "grep MNTK_UNMOUNTF" in the sources, you'll see it > > used some in the old/regular client, but not as much as the new one. > > > > You also need a fairly recent (can't remember if that is in 8.2) > > version of umount.c, since the code had a "sync();" at the beginning > > of it that would hang before even getting to the umount(2) syscall. > > I just looked and at least some of the fixes were MFC'd to stable/8 about 8months ago. So, they aren't in 8.2, but will be in 8.3. > > Bottom line, I think the newnfs client (the default for 9.0) can > > do this, but I'm doubtful the old/reguler one can. (I also wouldn't > > be surprised if there is still a bug other than the above mentioned > > one w.r.t. doing a "umount /mnt" and getting that hung before trying > > "umount -f /mnt". > > Is the new client in 8-stable up to date relevant to 9.0, and/or is it > considered safe to use in production? > It looks like stable/8 might be ok using either client. The newnfs in stable/8 should be up to date w.r.t. bugfixes in the new/regular client in 9.0. > > Thanks, > > Doug > > -- > > It's always a long day; 86400 doesn't fit into a short. > > Breadth of IT experience, and depth of knowledge in the DNS. > Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Why won't 8.2 umount -f?
Doug Barton wrote: > On 02/13/2012 18:23, Rick Macklem wrote: > > Doug Barton wrote: > >> Is there some magic I'm missing to convince an 8.2 system to umount > >> -f? > >> I had an NFS server crash, so I'm trying to get the mounts updated. > >> All > >> of the 7.x systems happily did 'umount -f', but the 8.x systems > >> (mostly > >> 8.2-pN) are just hanging forever. > >> > >> Is this a bug, or is it something I'm missing? > >> > > Well, I didn't realize that a 7.n system would "umount -f" an NFS > > mount when the server was down and there were dirty blocks that > > needed to be written back, but I don't know. > > I'm doubtful that any of those systems had dirty blocks. > > > (I seem to recall that > > someone encouraged me to MFC one of my changes related to this back > > to stable/7, but I'm not sure if it mattered?) > > Please don't unless you can verify that it doesn't make this situation > worse. :) > > > I have pretty well fixed the new client w.r.t. this except for the > > case where you do a "umount " and that gets hung. Once a non > > "-f" > > umount gets hung, there is nothing you can do, because the mount > > point is > > locked up, so a subsequent "umount -f" can't get as far as > > nfs_umount(). > > I'm aware of this issue, and I did 'umount -f' first. But I wonder if > this isn't something that should be fixed because I think most users > would expect that 'umount -> umount -f' would be the natural > progression, similar to 'kill -> kill -9'. > I suspect that is "very difficult" to fix. The regular "umount /mnt" will stuck somewhere inside vinvalbuf() trying to flush blocks back to the server while holding a lock on the mount point. Although kib@ is the guy who would most likely know, I don't think it would be easy to get it to come out ok. For example, one approach might be to make all the sleeps interruptible and then add code to gracefully handle an EINTR return from them and then release locks as they return and. well it's not something I would want to tackle. > > My guess is that the old (default for 8.n) client isn't fixed for > > this. If you "grep MNTK_UNMOUNTF" in the sources, you'll see it > > used some in the old/regular client, but not as much as the new one. > > > > You also need a fairly recent (can't remember if that is in 8.2) > > version of umount.c, since the code had a "sync();" at the beginning > > of it that would hang before even getting to the umount(2) syscall. > > > > Bottom line, I think the newnfs client (the default for 9.0) can > > do this, but I'm doubtful the old/reguler one can. (I also wouldn't > > be surprised if there is still a bug other than the above mentioned > > one w.r.t. doing a "umount /mnt" and getting that hung before trying > > "umount -f /mnt". > > Is the new client in 8-stable up to date relevant to 9.0, and/or is it > considered safe to use in production? > > > Thanks, > > Doug > > -- > > It's always a long day; 86400 doesn't fit into a short. > > Breadth of IT experience, and depth of knowledge in the DNS. > Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Why won't 8.2 umount -f?
On 02/13/2012 19:13, Rick Macklem wrote: > I just looked and at least some of the fixes were MFC'd to stable/8 about > 8months ago. So, they aren't in 8.2, but will be in 8.3. Well 8.3 is about to enter code freeze, any way we can check to be sure all of the relevant fixes can be mfc'ed? Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
6.2-Release ..ish.. CF + ata == freeze?
Just thought i would post over here as i'm not getting a warm fuzzy from checkpoint about being able to find the root cause of an issue. I have a large install base of IPSO checkpoint firewalls, which are based on FreeBSD 6.2. I've had 3 firewalls hang basically the same way, with something that looks like a filesystem issue or an issue with a CF card. Does anyone happen to know of any bugs (i've been looking around) that could cause something like that? Granted, it could be a batch of bad CF cards, but its odd that i'm seeing the same thing on 3 different boxes and once rebooted they seem ok. Also is it possible to get useful info form the atacontroller when things go south like this from the ddb prompt? This is what shows in show msgbuf ad0: timeout waiting to issue command ad0: error issuing WRITE command ad0: timeout waiting to issue command ad0: error issuing WRITE command ad0: timeout waiting to issue command ad0: error issuing WRITE command ad0: timeout waiting to issue command ad0: error issuing WRITE command g_vfs_done():ad0s4h[WRITE(offset=33849344, length=131072)]error = 5 g_vfs_done():ad0s4h[WRITE(offset=33980416, length=131072)]error = 5 g_vfs_done():ad0s4h[WRITE(offset=34111488, length=131072)]error = 5 g_vfs_done():ad0s4h[WRITE(offset=34242560, length=131072)]error = 5 g_vfs_done():ad0s4h[WRITE(offset=34373632, length=131072)]error = 5 ad0: 1882MB at ata0-master PIO4 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x5070-0x507f mem 0x80301000-0x803013ff at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 atapci1: port 0x5088-0x508f,0x50a4-0x50a7,0x5080-0x5087,0x50a0-0x50a3,0x5060-0x506f irq 15 at device 31.2 on pci0 ata2: on atapci1 ata3: on atapci1ad0s4h is basically a r/w ufs partition on the box where almost anything that needs to be written goes. trace Tracing pid 1101 tid 100043 td 0x656d8460 kdb_enter(608cc388,6246,656d8460,64ba1400,6095d580,...) at kdb_enter+0x2b siointr1(64ba1400) at siointr1+0xf0 siointr(64ba1400) at siointr+0x38 intr_execute_handler(6095d580,f0a4ab04,6,6095d580,f0a4aafc,...) at intr_execute_handler+0x61 intr_execute_handlers(6095d580,f0a4ab04,6,0,656d8460,...) at intr_execute_handlers+0x40 atpic_handle_intr(4) at atpic_handle_intr+0x96 Xatpic_intr4() at Xatpic_intr4+0x20 --- interrupt, eip = 0x606044af, esp = 0xf0a4ab48, ebp = 0xf0a4ab5c --- lockmgr(e1456a04,6,0,656d8460) at lockmgr+0x58f getdirtybuf(e14569a4,60a405e4,1) at getdirtybuf+0x2e2 flush_deplist(68b30850,1,f0a4abb8) at flush_deplist+0x30 flush_inodedep_deps(656fa28c,1f235) at flush_inodedep_deps+0xcf softdep_sync_metadata(65964618) at softdep_sync_metadata+0x61 ffs_syncvnode(65964618,1) at ffs_syncvnode+0x3a2 ffs_fsync(f0a4ac74) at ffs_fsync+0x12 VOP_FSYNC_APV(60949260,f0a4ac74) at VOP_FSYNC_APV+0x38 fsync(656d8460,f0a4acb4) at fsync+0x170 syscall(805003b,806003b,5fbf003b,805,288be450,...) at syscall+0x2ee Xint0x80_syscall() at Xint0x80_syscall+0x1f --More-- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 6.2-Release ..ish.. CF + ata == freeze?
On Mon, Feb 13, 2012 at 08:43:08PM -0800, john fleming wrote: > Just thought i would post over here as i'm not getting a warm fuzzy from > checkpoint about being able to find the root cause of an issue. I have a > large install base of IPSO checkpoint firewalls, which are based on FreeBSD > 6.2. I've had 3 firewalls hang basically the same way, with something that > looks like a filesystem issue or an issue with a CF card. > > Does anyone happen to know of any bugs (i've been looking around) that could > cause something like that? Granted, it could be a batch of bad CF cards, but > its odd that i'm seeing the same thing on 3 different boxes and once rebooted > they seem ok. > > Also is it possible to get useful info form the atacontroller when things go > south like this from the ddb prompt? > > This is what shows in show msgbuf > ad0: timeout waiting to issue command > ad0: error issuing WRITE command > ad0: timeout waiting to issue command > ad0: error issuing WRITE command > ad0: timeout waiting to issue command > ad0: error issuing WRITE command > ad0: timeout waiting to issue command > ad0: error issuing WRITE command > g_vfs_done():ad0s4h[WRITE(offset=33849344, length=131072)]error = 5 > g_vfs_done():ad0s4h[WRITE(offset=33980416, length=131072)]error = 5 > g_vfs_done():ad0s4h[WRITE(offset=34111488, length=131072)]error = 5 > g_vfs_done():ad0s4h[WRITE(offset=34242560, length=131072)]error = 5 > g_vfs_done():ad0s4h[WRITE(offset=34373632, length=131072)]error = 5 > > ad0: 1882MB at ata0-master PIO4 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x5070-0x507f mem 0x80301000-0x803013ff > at device 31.1 on pci0 > ata0: on atapci0 > ata1: on atapci0 > atapci1: port > 0x5088-0x508f,0x50a4-0x50a7,0x5080-0x5087,0x50a0-0x50a3,0x5060-0x506f irq 15 > at device 31.2 on pci0 > ata2: on atapci1 > ata3: on atapci1ad0s4h is basically a r/w ufs partition on > the box where almost anything that needs to be written goes. > trace > Tracing pid 1101 tid 100043 td 0x656d8460 > kdb_enter(608cc388,6246,656d8460,64ba1400,6095d580,...) at kdb_enter+0x2b > siointr1(64ba1400) at siointr1+0xf0 > siointr(64ba1400) at siointr+0x38 > intr_execute_handler(6095d580,f0a4ab04,6,6095d580,f0a4aafc,...) at > intr_execute_handler+0x61 > intr_execute_handlers(6095d580,f0a4ab04,6,0,656d8460,...) at > intr_execute_handlers+0x40 > atpic_handle_intr(4) at atpic_handle_intr+0x96 > Xatpic_intr4() at Xatpic_intr4+0x20 > --- interrupt, eip = 0x606044af, esp = 0xf0a4ab48, ebp = 0xf0a4ab5c --- > lockmgr(e1456a04,6,0,656d8460) at lockmgr+0x58f > getdirtybuf(e14569a4,60a405e4,1) at getdirtybuf+0x2e2 > flush_deplist(68b30850,1,f0a4abb8) at flush_deplist+0x30 > flush_inodedep_deps(656fa28c,1f235) at flush_inodedep_deps+0xcf > softdep_sync_metadata(65964618) at softdep_sync_metadata+0x61 > ffs_syncvnode(65964618,1) at ffs_syncvnode+0x3a2 > ffs_fsync(f0a4ac74) at ffs_fsync+0x12 > VOP_FSYNC_APV(60949260,f0a4ac74) at VOP_FSYNC_APV+0x38 > fsync(656d8460,f0a4acb4) at fsync+0x170 > syscall(805003b,806003b,5fbf003b,805,288be450,...) at syscall+0x2ee > Xint0x80_syscall() at Xint0x80_syscall+0x1f This looks to be a problem with softupdates and CF cards. Can you get this to repeat on a brand new (good) card ? -- ;s =; ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 6.2-Release ..ish.. CF + ata == freeze?
On Mon, Feb 13, 2012 at 08:43:08PM -0800, john fleming wrote: > Just thought i would post over here as i'm not getting a warm fuzzy from > checkpoint about being able to find the root cause of an issue. I have a > large install base of IPSO checkpoint firewalls, which are based on FreeBSD > 6.2. I've had 3 firewalls hang basically the same way, with something that > looks like a filesystem issue or an?issue with a CF card. FreeBSD 6.2 was EOL'd in early-to-mid-2008. The ATA driver has changed significantly since then (present-day uses CAM). > Does anyone happen to know of any bugs (i've been looking around) that could > cause something like that? Granted, it could be a batch of bad CF cards, but > its odd that i'm seeing the same thing on 3 different boxes and once rebooted > they seem ok. > ? > Also is it possible to get useful info form the atacontroller when things go > south like this from the ddb prompt? Not particularly. What's shown below indicates that the driver had issued some form of ATA write command (there are multiple kinds per ATA specification), and either the underlying media (CF/disk) or controller stalled/locked up/took too long. I forget what the timeout value is in 6.2; I can't be bothered to remember such from 6 years ago. :-) > This is what shows in show msgbuf > ad0: timeout waiting to issue command > ad0: error issuing WRITE command > ad0: timeout waiting to issue command > ad0: error issuing WRITE command > ad0: timeout waiting to issue command > ad0: error issuing WRITE command > ad0: timeout waiting to issue command > ad0: error issuing WRITE command > g_vfs_done():ad0s4h[WRITE(offset=33849344, length=131072)]error = 5 > g_vfs_done():ad0s4h[WRITE(offset=33980416, length=131072)]error = 5 > g_vfs_done():ad0s4h[WRITE(offset=34111488, length=131072)]error = 5 > ?g_vfs_done():ad0s4h[WRITE(offset=34242560, length=131072)]error = 5 > g_vfs_done():ad0s4h[WRITE(offset=34373632, length=131072)]error = 5 error 5 = EIO = Input/output error. But this isn't too big of a surprise given the timeouts you see prior. Are these CF cards brand new -- meaning, are they completely unused (having never had any writes done to them), or have they been in use a while? I'm betting they've been in use a while, and have probably been doing many writes over the years. Two things to note here: 1) The errors you've shown are only happening on writes, not reads. Of course if you omitted information then this isn't an accurate statement. 2) Timeouts are seen when issuing writes to some LBA regions. How full is the CF card, disk-space-wise? Not just ad0s4h, I'm talking about the entire card. How much space is roughly available? They're very small CF cards (1.8GByte roughly), and the less space available, the less effectiveness of wear levelling (and in some cases the slower the writes are). Reason I ask: given that these are CF cards, this smells of cards which are simply "worn down". CF cards have limited numbers of writes, and the card may be "freaking out" internally when attempting to write to some LBAs which map to CF sectors that are, in effect, "bad". The CF cards' ECC implementation may be buggy, or may simply be "spinning hard" for too long. You can read about this sort of behaviour on Wikipedia's CompactFlash article. You wouldn't be able to verify this with dd if=/dev/ad0, because those are read operations. You could zero the media (dd if=/dev/zero of=/dev/ad0) as a form of verification if you wanted. Do you happen to know if these CF cards support SMART? If so, installing smartmontools (version 5.42 or newer please) and providing output from "smartctl -a /dev/ad0" may be helpful to me, but I make no guarantees anything of use will be shown there. Overall my advice would be to replace the CF cards, especially if they have been in use for a long while. It really doesn't matter to me that it's happening on 3 machines (honest), especially if these are 6.2 machines with CF cards that have been in use for years. We're lucky to get 2 years out of our CF cards on our Juniper M120/320s before they start spitting I/O errors. Pick larger CF cards as well; more space = more room for effective wear levelling. > ? > ad0: 1882MB at ata0-master PIO4 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x5070-0x507f mem 0x80301000-0x803013ff > at device 31.1 on pci0 > ata0: on atapci0 > ata1: on atapci0 > atapci1: port > 0x5088-0x508f,0x50a4-0x50a7,0x5080-0x5087,0x50a0-0x50a3,0x5060-0x506f irq 15 > at device 31.2 on pci0 > ata2: on atapci1 > ata3: on atapci1ad0s4h is basically a r/w ufs partition on > the box where almost anything that needs to be written goes. > trace > Tracing pid 1101 tid 100043 td 0x656d8460 > kdb_enter(608cc388,6246,656d8460,64ba1400,6095d580,...) at kdb_enter+0x2b > siointr1(64ba1400) at siointr1+0xf0 > siointr(64ba1400) at siointr+0x38 > intr_execute_handler(6095d580,f0a4ab04,6,6095d580,f0a4aafc,...) at > intr_execute_handler+0x61 > int
Re: 6.2-Release ..ish.. CF + ata == freeze?
I can't seem to replicate it at all. I've seen it happen on 3 different IPSO boxes so far. The last machine it happened on is maybe 4 months old. Basically on all 3 machines once rebooted the problem doesn't come back. Checkpoint so far is telling me its a known issue and they don't know what the fix is. What makes you think its softupdates? Would that cause the write timeout as well? Just not sure what level of this is failing, filesystem, flash or ata controller. thanks for the reply! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 6.2-Release ..ish.. CF + ata == freeze?
On Mon, Feb 13, 2012 at 10:43 PM, john fleming wrote: > Just thought i would post over here as i'm not getting a warm fuzzy from > checkpoint about being able to find the root cause of an issue. I have a > large install base of IPSO checkpoint firewalls, which are based on FreeBSD > 6.2. I've had 3 firewalls hang basically the same way, with something that > looks like a filesystem issue or an issue with a CF card. > There was a thread just the other day mentioned lockup problems with DMA and CF cards. Disabling DMA or reducing the mode helped. Not sure if applicable to that old of FreeBSD version. -- Adam Vande More ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 6.2-Release ..ish.. CF + ata == freeze?
On Mon, Feb 13, 2012 at 11:38:06PM -0600, Adam Vande More wrote: > On Mon, Feb 13, 2012 at 10:43 PM, john fleming wrote: > > > Just thought i would post over here as i'm not getting a warm fuzzy from > > checkpoint about being able to find the root cause of an issue. I have a > > large install base of IPSO checkpoint firewalls, which are based on FreeBSD > > 6.2. I've had 3 firewalls hang basically the same way, with something that > > looks like a filesystem issue or an issue with a CF card. > > > > There was a thread just the other day mentioned lockup problems with DMA > and CF cards. Disabling DMA or reducing the mode helped. Not sure if > applicable to that old of FreeBSD version. > I seen that thread. Doubt it is related to his issue since he is running 6.2. And besides his dmesg proves otherwise. ad0: 1882MB at ata0-master PIO4 -- ;s =; ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: dhclient script adjustments
Anyone ? On Sat, Feb 11, 2012 at 01:58:57AM -0500, Jason Hellenthal wrote: > > After recent merges to stable/8 I am now seeing errors on bootup of > the following for three interfaces that will never see the light of > DHCP. ? > > /etc/rc.d/dhclient: ERROR: 'dc1' is not a DHCP-enabled interface > > Can someone please revert these changes or some other action. ? > > -- > ;s =; -- ;s =; ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
