Re: disable 64-bit dma for one PCI slot only?
On 19.07.2011 1:22, Scott Long wrote: Btw, I *HATE* the chip and card identifiers used in pciconf. Can we change it to emit the standard (sub)vendor/(sub)device terminology? Oh, yeah. I hate that too. Would you want them as 4 separate entities or to just rename the labels to 'devid' and 'subdevid'? If we're going to change it, might as well break it down into 4 fields. Maybe we retain the old format under a legacy switch and/or env variable for users that have tools that parse the output (cough yahoo cough). Hi, Scott i think for keeping POLA it is better add new option to make new output format. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: Status of support for 4KB disk sectors
On Mon, Jul 18, 2011 at 4:41 PM, Jeremy Chadwick free...@jdc.parodius.com wrote: On Mon, Jul 18, 2011 at 03:50:15PM -0700, Kevin Oberman wrote: I just want to check on the status of 4K sector support in FreeBSD. I read a long thread on the topic from a while back and it looks like I might hit some issues if I'm not REALLY careful. Since I will be keeping the existing Windows installation, I need to be sure that I can set up the disk correctly without screwing up Windows 7. I was planning on just DDing the W7 slice over, but I am not sure how well this would play with GPT. Or should I not try to use GPT at all? I'd like to as this laptop spreads Windows 7 over two slices and adds a third for the recovery system, leaving only one for FreeBSD and I'd like to put my files in a separate slice. GPT would offer that fifth slice. I have read the handbook and don't see any reference to 4K sectors and only a one-liner about gpart(8) and GPT. Oncew I get this all figured out, I'll see about writing an update about this as GPT looks like the way to go in e future. When you say 4KB sector support, what do you mean by this? All drives on the market as of this writing, that I've seen, all claim a physical/logical sector size of 512 bytes -- yes, even SSDs, and EARS drives which we know use 4KB sectors. They do this to guarantee full compatibility with existing software. Since you're talking about gpart and 4KB sector support, did you mean to ask what's the state of FreeBSD and aligned partition support to ensure decent performance with 4KB-sector drives? If so: there have been some commits in recent days to RELENG_8 to help try to address the shortcomings of the existing utilities and GEOM infrastructure. Read the most recent commit text carefully: http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/geom/class/part/geom_part.c But the currently known method is to use gnop(8). Here's an example: http://www.leidinger.net/blog/2011/05/03/another-root-on-zfs-howto-optimized-for-4k-sector-drives/ Now, that's for ZFS, but I'm under the impression the exact same is needed for FFS/UFS. Jeremy, Yes, this is exactly what I mean. If I shell out for a high-end 7200 RPM drive for my laptop only to have it run like a dog. Thanks for the pointers. The first is good news. I'm a bit confused as to what I will need gnop(8) for, but I'll be spending some time reading both the article and the gnop man page and hopefully that will make it clear. I've only used gpart once and to took way too long to figure out what I needed to do, but it did work fine. I just wish FreeBSD had some decent documentation on such a fundamental operation. Fortunately there are some pretty good articles folks have written, but they did leave me with several questions. -- R. Kevin Oberman, Network Engineer - Retired E-mail: kob6...@gmail.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: disable 64-bit dma for one PCI slot only?
On 19/07/2011 07:56, Andrey V. Elsukov wrote: On 19.07.2011 1:22, Scott Long wrote: Btw, I *HATE* the chip and card identifiers used in pciconf. Can we change it to emit the standard (sub)vendor/(sub)device terminology? Oh, yeah. I hate that too. Would you want them as 4 separate entities or to just rename the labels to 'devid' and 'subdevid'? If we're going to change it, might as well break it down into 4 fields. Maybe we retain the old format under a legacy switch and/or env variable for users that have tools that parse the output (cough yahoo cough). Hi, Scott i think for keeping POLA it is better add new option to make new output format. This is a too strict interpretation of POLA! If the change is done for better compliance with standards and it is done in a major version (i.e. 9.0 or 10.0), it's not a matter of POLA (otherwise, the change will never happen). ___ 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: disable 64-bit dma for one PCI slot only?
On Monday, July 18, 2011 5:22:26 pm Scott Long wrote:
On Jul 18, 2011, at 3:14 PM, John Baldwin wrote:
On Monday, July 18, 2011 5:06:40 pm Scott Long wrote:
On Jul 18, 2011, at 12:02 PM, John Baldwin wrote:
On Friday, July 15, 2011 6:07:31 pm Mark McConnell wrote:
Dear folks,
I have two LSI raid cards, one of which (SCSI 320-I) supports
64-bit DMA when 4GB+ of DDR is present and another which
does not (SATA 150-D) . Consquently I've disabled 64-bit
addressing for amr devices.
I would like to disable 64-bit addressing for the SATA card, but
permit it for the SCSI card. Is this possible?
You'd have to hack the driver perhaps to only disable 64-bit DMA for
certain
PCI IDs. It probably already does this?
The driver already had a table for determining 64bit DMA based on the PCI
ID.
I guess there's a mistake in the table for this particular card. I think
that
changing the following line to remove the AMR_ID_DO_SG64 flag will fix the
problem:
{0x1000, 0x1960, AMR_ID_QUARTZ | AMR_ID_DO_SG64 | AMR_ID_PROBE_SIG},
Actually, what's probably going on is that the driver is only looking at
the
vendor and device id's, and is ignoring the subvendor and subdevice id's
that
would give it a better clue on the exact hardware in use. Fixing the
driver
to look at all 64bits of id info (and take into account wildcards where
needed) would be a good project, if anyone is interested.
Btw, I *HATE* the chip and card identifiers used in pciconf. Can we
change it to emit the standard (sub)vendor/(sub)device terminology?
Oh, yeah. I hate that too. Would you want them as 4 separate entities or
to
just rename the labels to 'devid' and 'subdevid'?
If we're going to change it, might as well break it down into 4 fields. Maybe
we retain the old format under a legacy switch and/or env variable for users
that have tools that parse the output (cough yahoo cough).
The only reason it might be nice to stick with two fields is due to the line
length (though the first line is over 80 cols even in the current format). Here
are two possible suggestions:
old:
hostb0@pci0:0:0:0: class=0x06 card=0x20108086 chip=0x01008086 rev=0x09
hdr=0x00
pcib1@pci0:0:1:0: class=0x060400 card=0x20108086 chip=0x01018086 rev=0x09
hdr=0x01
pcib2@pci0:0:1:1: class=0x060400 card=0x20108086 chip=0x01058086 rev=0x09
hdr=0x01
none0@pci0:0:22:0: class=0x078000 card=0x47428086 chip=0x1c3a8086 rev=0x04
hdr=0x00
em0@pci0:0:25:0:class=0x02 card=0x8086 chip=0x15038086 rev=0x04
hdr=0x00
...
A)
hostb0@pci0:0:0:0: class=0x06 vendor=0x8086 device=0x0100
subvendor=0x8086 subdevice=0x2010 rev=0x09 hdr=0x00
pcib1@pci0:0:1:0: class=0x060400 vendor=0x8086 device=0x0101
subvendor=0x8086 subdevice=0x2010 rev=0x09 hdr=0x01
pcib2@pci0:0:1:1: class=0x060400 vendor=0x8086 device=0x0105
subvendor=0x8086 subdevice=0x2010 rev=0x09 hdr=0x01
none0@pci0:0:22:0: class=0x078000 vendor=0x8086 device=0x1c3a
subvendor=0x8086 subdevice=0x4742 rev=0x04 hdr=0x00
em0@pci0:0:25:0:class=0x02 vendor=0x8086 device=0x1503
subvendor=0x8086 subdevice=0x rev=0x04 hdr=0x00
...
B)
hostb0@pci0:0:0:0: class=0x06 devid=0x8086:0100 subid=0x8086:2010
rev=0x09 hdr=0x00
pcib1@pci0:0:1:0: class=0x060400 devid=0x8086:0101 subid=0x8086:2010
rev=0x09 hdr=0x01
pcib2@pci0:0:1:1: class=0x060400 devid=0x8086:0105 subid=0x8086:2010
rev=0x09 hdr=0x01
none0@pci0:0:22:0: class=0x078000 devid=0x8086:1c3a subid=0x8086:4742
rev=0x04 hdr=0x00
em0@pci0:0:25:0:class=0x02 devid=0x8086:1503 subid=0x8086:
rev=0x04 hdr=0x00
...
I went with vendor word first for both A) and B) as in my experience that is
the more common ordering in driver tables, etc.
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
powernow regression in 8-STABLE
Hi, I've just noticed and tracked down a regression in x86/cpufreq/powernow.c (on amd64) which was first mentioned here: http://lists.freebsd.org/pipermail/freebsd-current/2011-March/023509.html although no followup seems to have occurred. Symptoms are that powerd stops working because the dev.cpu.0.freq OID is no longer gettable nor settable. This seems to have been caused by the following revision: http://svnweb.freebsd.org/base?view=revisionrevision=222148 which was in turn an MFC of r221102, so I guess the problem exists on -current as well, although I can't confirm that since I don't run it. Reverting the change fixes the problem and powerd will work again. Also other utilities, such as xacpim, work properly. I'm running a ML-40 Turion laptop (HP Compaq nx6125). regards, Callum -- Callum Gibson @ home http://members.optusnet.com.au/callumgibson/ ___ 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: disable 64-bit dma for one PCI slot only?
On Jul 19, 2011, at 7:31 AM, John Baldwin wrote: If we're going to change it, might as well break it down into 4 fields. Maybe we retain the old format under a legacy switch and/or env variable for users that have tools that parse the output (cough yahoo cough). The only reason it might be nice to stick with two fields is due to the line length (though the first line is over 80 cols even in the current format). Here are two possible suggestions: I like A for the explicitness, but B is a bit easier to read on an 80 column display. There's no 'verbose' flag for pciconf, and the '-v' flag has already been claimed for another use; if a verbose flag were to appear, I'd suggest hiding the rev and hdr fields under it and otherwise shortening the line. However, it's not my bikeshed to paint, and I'll be thrilled with either option A or B or anything in between. I went with vendor word first for both A) and B) as in my experience that is the more common ordering in driver tables, etc. Indeed. Thanks a lot for working on this. Scott ___ 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: powernow regression in 8-STABLE
On Tuesday 19 July 2011 07:20 am, Callum Gibson wrote: Hi, I've just noticed and tracked down a regression in x86/cpufreq/powernow.c (on amd64) which was first mentioned here: http://lists.freebsd.org/pipermail/freebsd-current/2011-March/02350 9.html although no followup seems to have occurred. Symptoms are that powerd stops working because the dev.cpu.0.freq OID is no longer gettable nor settable. This seems to have been caused by the following revision: http://svnweb.freebsd.org/base?view=revisionrevision=222148 which was in turn an MFC of r221102, so I guess the problem exists on -current as well, although I can't confirm that since I don't run it. Reverting the change fixes the problem and powerd will work again. Also other utilities, such as xacpim, work properly. I'm running a ML-40 Turion laptop (HP Compaq nx6125). HP again... Can you please show me verbose boot messages? Thanks, Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: disable 64-bit dma for one PCI slot only?
On Tue, Jul 19, 2011 at 6:31 AM, John Baldwin j...@freebsd.org wrote: The only reason it might be nice to stick with two fields is due to the line length (though the first line is over 80 cols even in the current format). Here are two possible suggestions: old: hostb0@pci0:0:0:0: class=0x06 card=0x20108086 chip=0x01008086 rev=0x09 hdr=0x00 pcib1@pci0:0:1:0: class=0x060400 card=0x20108086 chip=0x01018086 rev=0x09 hdr=0x01 pcib2@pci0:0:1:1: class=0x060400 card=0x20108086 chip=0x01058086 rev=0x09 hdr=0x01 none0@pci0:0:22:0: class=0x078000 card=0x47428086 chip=0x1c3a8086 rev=0x04 hdr=0x00 em0@pci0:0:25:0: class=0x02 card=0x8086 chip=0x15038086 rev=0x04 hdr=0x00 ... A) hostb0@pci0:0:0:0: class=0x06 vendor=0x8086 device=0x0100 subvendor=0x8086 subdevice=0x2010 rev=0x09 hdr=0x00 pcib1@pci0:0:1:0: class=0x060400 vendor=0x8086 device=0x0101 subvendor=0x8086 subdevice=0x2010 rev=0x09 hdr=0x01 pcib2@pci0:0:1:1: class=0x060400 vendor=0x8086 device=0x0105 subvendor=0x8086 subdevice=0x2010 rev=0x09 hdr=0x01 none0@pci0:0:22:0: class=0x078000 vendor=0x8086 device=0x1c3a subvendor=0x8086 subdevice=0x4742 rev=0x04 hdr=0x00 em0@pci0:0:25:0: class=0x02 vendor=0x8086 device=0x1503 subvendor=0x8086 subdevice=0x rev=0x04 hdr=0x00 ... B) hostb0@pci0:0:0:0: class=0x06 devid=0x8086:0100 subid=0x8086:2010 rev=0x09 hdr=0x00 pcib1@pci0:0:1:0: class=0x060400 devid=0x8086:0101 subid=0x8086:2010 rev=0x09 hdr=0x01 pcib2@pci0:0:1:1: class=0x060400 devid=0x8086:0105 subid=0x8086:2010 rev=0x09 hdr=0x01 none0@pci0:0:22:0: class=0x078000 devid=0x8086:1c3a subid=0x8086:4742 rev=0x04 hdr=0x00 em0@pci0:0:25:0: class=0x02 devid=0x8086:1503 subid=0x8086: rev=0x04 hdr=0x00 ... I went with vendor word first for both A) and B) as in my experience that is the more common ordering in driver tables, etc. Do we need to print (class|devid|device|subvendor|etc.)= on every line? IMHO they belong to a header line. Something like this: Driver Handle ClassVnd:Dev Sub Vnd:Dev Rev Hdr -- hostb0 pci0:0:0:0 0x06 0x8086:0100 0x8086:2010 0x09 0x00 pcib1 pci0:0:1:0 0x060400 0x8086:0101 0x8086:2010 0x09 0x01 pcib2 pci0:0:1:1 0x060400 0x8086:0105 0x8086:2010 0x09 0x01 none0 pci0:0:22:0 0x078000 0x8086:1c3a 0x8086:4742 0x04 0x00 em0pci0:0:25:0 0x02 0x8086:1503 0x8086: 0x04 0x00 --Artem ___ 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: Status of support for 4KB disk sectors
On Jul 18, 2011, at 11:04 PM, Kevin Oberman wrote: I just wish FreeBSD had some decent documentation on such a fundamental operation. Fortunately there are some pretty good articles folks have written, but they did leave me with several questions. Is there something in FreeBSD which is preventing you from using the drive's native DEV_BSIZE of 4096 bytes, or is it that the drive claims to have a physical block size of 512 bytes when it is really 4k? Except for a PC BIOS maybe wanting a 512-byte boot sector, there shouldn't be anything magical about that sector size. Unix operating systems like SunOS 3 and NEXTSTEP would happily run with a DEV_BSIZE of 1024 or larger-- they'd boot fine off of optical media using 2048-byte sectors, for example, and some of the early 1990's era SCSI hard drives supported low-level reformatting to a different sector size like 1024 or 2048 bytes. Regards, -- -Chuck ___ 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: Status of support for 4KB disk sectors
On 19.7.2011. 19:54, Chuck Swiger wrote: On Jul 18, 2011, at 11:04 PM, Kevin Oberman wrote: I just wish FreeBSD had some decent documentation on such a fundamental operation. Fortunately there are some pretty good articles folks have written, but they did leave me with several questions. Is there something in FreeBSD which is preventing you from using the drive's native DEV_BSIZE of 4096 bytes, or is it that the drive claims to have a physical block size of 512 bytes when it is really 4k? Nope, only that. The current state of the matter (i.e. for 9.0) is: * The new ATA driver has quirks for certain models of HDDs which have this false advertising (which can be manually triggered by kern.cam.ada.X.quirks=1) which causes the drive to report stripesize of 4k. * This information is used in gpart to size align partitions; it will be used by the new installer * Default fragment size for UFS was raised to 4K so it will be aligned by default. ___ 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: Status of support for 4KB disk sectors
On Jul 19, 2011, at 12:29 PM, Ivan Voras wrote: Is there something in FreeBSD which is preventing you from using the drive's native DEV_BSIZE of 4096 bytes, or is it that the drive claims to have a physical block size of 512 bytes when it is really 4k? Nope, only that. :-) It's nice to have well-defined problems-- although it's perhaps not so nice when hardware is compelled to lie about its status because of backwards-compatibility (C/H/S vs LBA comes to mind also). The current state of the matter (i.e. for 9.0) is: * The new ATA driver has quirks for certain models of HDDs which have this false advertising (which can be manually triggered by kern.cam.ada.X.quirks=1) which causes the drive to report stripesize of 4k. * This information is used in gpart to size align partitions; it will be used by the new installer * Default fragment size for UFS was raised to 4K so it will be aligned by default. Excellent; thanks for the detailed reply. Regards, -- -Chuck ___ 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: Status of support for 4KB disk sectors
On Mon, 18 Jul 2011 16:41:24 -0700 Jeremy Chadwick free...@jdc.parodius.com wrote: But the currently known method is to use gnop(8). Here's an example: http://www.leidinger.net/blog/2011/05/03/another-root-on-zfs-howto-optimized-for-4k-sector-drives/ Now, that's for ZFS, but I'm under the impression the exact same is needed for FFS/UFS. Info: gnop will not work for FFS/UFS because gnop is a temporary solution (needs to be done by hand at each reboot). For FFS/UFS you need to align the slice/partition and chose a good blocksize/fragsize combination (e.g. 32k/4k). Bye, Alexander. -- 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: Status of support for 4KB disk sectors
On 2011-Jul-19 10:54:38 -0700, Chuck Swiger cswi...@mac.com wrote: Unix operating systems like SunOS 3 and NEXTSTEP would happily run with a DEV_BSIZE of 1024 or larger-- they'd boot fine off of optical media using 2048-byte sectors, Actually, Sun used customised CD-ROM drives that faked 512-byte sectors to work around their lack of support for anything else. some of the early 1990's era SCSI hard drives supported low-level reformatting to a different sector size like 1024 or 2048 bytes. Did anyone actually do this? I wanted to but was warned against it by the local OS rep (this was a Motorola SVR2). -- Peter Jeremy pgp9GiYFCh7fP.pgp Description: PGP signature
Re: Status of support for 4KB disk sectors
On Tue, Jul 19, 2011 at 1:41 PM, Alexander Leidinger alexan...@leidinger.net wrote: On Mon, 18 Jul 2011 16:41:24 -0700 Jeremy Chadwick free...@jdc.parodius.com wrote: But the currently known method is to use gnop(8). Here's an example: http://www.leidinger.net/blog/2011/05/03/another-root-on-zfs-howto-optimized-for-4k-sector-drives/ Now, that's for ZFS, but I'm under the impression the exact same is needed for FFS/UFS. Info: gnop will not work for FFS/UFS because gnop is a temporary solution (needs to be done by hand at each reboot). For FFS/UFS you need to align the slice/partition and chose a good blocksize/fragsize combination (e.g. 32k/4k). Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 Thanks, Alexander. This is what I had expected after reading the man pages, though I would think -b 65560 -f 8192' would be a bit more reasonable in this day of bloated file formats. it's been years since I have hit a problem with lack of inodes. Probably around 1993 on an old SparcStation 1 running SunOS and then only due to a bad assumption I made when 'newfs'ing it. Again, thanks for the advice. At very least it will save me a bit of time! -- R. Kevin Oberman, Network Engineer - Retired E-mail: kob6...@gmail.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: Status of support for 4KB disk sectors
On Tue, Jul 19, 2011 at 02:33:27PM -0700, Kevin Oberman wrote: On Tue, Jul 19, 2011 at 1:41 PM, Alexander Leidinger alexan...@leidinger.net wrote: On Mon, 18 Jul 2011 16:41:24 -0700 Jeremy Chadwick free...@jdc.parodius.com wrote: But the currently known method is to use gnop(8). ?Here's an example: http://www.leidinger.net/blog/2011/05/03/another-root-on-zfs-howto-optimized-for-4k-sector-drives/ Now, that's for ZFS, but I'm under the impression the exact same is needed for FFS/UFS. Info: gnop will not work for FFS/UFS because gnop is a temporary solution (needs to be done by hand at each reboot). For FFS/UFS you need to align the slice/partition and chose a good blocksize/fragsize combination (e.g. 32k/4k). Bye, Alexander. -- http://www.Leidinger.net ? ?Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org ? ? ? netchild @ FreeBSD.org ?: PGP ID = 72077137 Thanks, Alexander. This is what I had expected after reading the man pages, though I would think -b 65560 -f 8192' would be a bit more reasonable in this Where did this number come from? Did you mean 65536? 65560 would not be properly aligned. day of bloated file formats. it's been years since I have hit a problem with lack of inodes. Probably around 1993 on an old SparcStation 1 running SunOS and then only due to a bad assumption I made when 'newfs'ing it. Again, thanks for the advice. At very least it will save me a bit of time! Agreed -- thanks for the advice, Alexander. -- | Jeremy Chadwickjdc at 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: Status of support for 4KB disk sectors
On Jul 19, 2011, at 2:10 PM, Peter Jeremy wrote: On 2011-Jul-19 10:54:38 -0700, Chuck Swiger cswi...@mac.com wrote: Unix operating systems like SunOS 3 and NEXTSTEP would happily run with a DEV_BSIZE of 1024 or larger-- they'd boot fine off of optical media using 2048-byte sectors, Actually, Sun used customised CD-ROM drives that faked 512-byte sectors to work around their lack of support for anything else. Hmm-- my brain could be fuzzy about things twenty-plus years ago. But I remember booting a Sun3_35 or _60 from a non-Sun or Sun OEM'ed SCSI CD-ROM drive, probably a Plextor? some of the early 1990's era SCSI hard drives supported low-level reformatting to a different sector size like 1024 or 2048 bytes. Did anyone actually do this? I wanted to but was warned against it by the local OS rep (this was a Motorola SVR2). Worked fine with 250MB Seagate ST1280 drives, and also a a 1GB Micropolis 2112. It made a decent gain to available disk capacity (about 10-15%), and a smaller improvement to performance (about 5% IIRC). It wouldn't work with drives using a dedicated embedded servo for sector positioning (ie, Quantum and DEC), but other vendors like Seagate used a normal platter surface for servo positioning, and you could reformat it with a different sector size. Regards, -- -Chuck ___ 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: Status of support for 4KB disk sectors
On Tue, Jul 19, 2011 at 2:49 PM, Jeremy Chadwick free...@jdc.parodius.com wrote: On Tue, Jul 19, 2011 at 02:33:27PM -0700, Kevin Oberman wrote: On Tue, Jul 19, 2011 at 1:41 PM, Alexander Leidinger alexan...@leidinger.net wrote: On Mon, 18 Jul 2011 16:41:24 -0700 Jeremy Chadwick free...@jdc.parodius.com wrote: But the currently known method is to use gnop(8). ?Here's an example: http://www.leidinger.net/blog/2011/05/03/another-root-on-zfs-howto-optimized-for-4k-sector-drives/ Now, that's for ZFS, but I'm under the impression the exact same is needed for FFS/UFS. Info: gnop will not work for FFS/UFS because gnop is a temporary solution (needs to be done by hand at each reboot). For FFS/UFS you need to align the slice/partition and chose a good blocksize/fragsize combination (e.g. 32k/4k). Bye, Alexander. -- http://www.Leidinger.net ? ?Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org ? ? ? netchild @ FreeBSD.org ?: PGP ID = 72077137 Thanks, Alexander. This is what I had expected after reading the man pages, though I would think -b 65560 -f 8192' would be a bit more reasonable in this Where did this number come from? Did you mean 65536? 65560 would not be properly aligned. Ack! Fingers and brain out of sync. Yes, 65536 is what I meant. day of bloated file formats. it's been years since I have hit a problem with lack of inodes. Probably around 1993 on an old SparcStation 1 running SunOS and then only due to a bad assumption I made when 'newfs'ing it. Again, thanks for the advice. At very least it will save me a bit of time! Agreed -- thanks for the advice, Alexander. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | -- R. Kevin Oberman, Network Engineer - Retired E-mail: kob6...@gmail.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: scp: Write Failed: Cannot allocate memory - Problem found and solved (for me)
Quoting Peter Ross peter.r...@bogen.in-berlin.de:
Quoting Scott Sipe csco...@gmail.com:
On Wed, Jul 6, 2011 at 4:21 AM, Peter Ross
peter.r...@bogen.in-berlin.dewrote:
Quoting Peter Ross peter.r...@bogen.in-berlin.de**:
Quoting Peter Ross peter.r...@bogen.in-berlin.de**:
Quoting Jeremy Chadwick free...@jdc.parodius.com:
On Wed, Jul 06, 2011 at 01:54:12PM +1000, Peter Ross wrote:
Quoting Jeremy Chadwick free...@jdc.parodius.com:
On Wed, Jul 06, 2011 at 01:07:53PM +1000, Peter Ross wrote:
Quoting Jeremy Chadwick free...@jdc.parodius.com:
On Wed, Jul 06, 2011 at 12:23:39PM +1000, Peter Ross wrote:
Quoting Jeremy Chadwick free...@jdc.parodius.com:
On Tue, Jul 05, 2011 at 01:03:20PM -0400, Scott Sipe wrote:
I'm running virtualbox 3.2.12_1 if that has anything to do with
it.
sysctl vfs.zfs.arc_max: 62
While I'm trying to scp, kstat.zfs.misc.arcstats.size is
hovering right around that value, sometimes above, sometimes
below (that's as it should be, right?). I don't think that it
dies when crossing over arc_max. I can run the same scp 10 times
and it might fail 1-3 times, with no correlation to the
arcstats.size being above/below arc_max that I can see.
Scott
On Jul 5, 2011, at 3:00 AM, Peter Ross wrote:
Hi all,
just as an addition: an upgrade to last Friday's
FreeBSD-Stable and to VirtualBox 4.0.8 does not fix the
problem.
I will experiment a bit more tomorrow after hours and grab
some statistics.
Regards
Peter
Quoting Peter Ross peter.r...@bogen.in-berlin.de**:
Hi all,
I noticed a similar problem last week. It is also very
similar to one reported last year:
http://lists.freebsd.org/**pipermail/freebsd-stable/2010-**
September/058708.htmlhttp://lists.freebsd.org/pipermail/freebsd-stable/2010-September/058708.html
My server is a Dell T410 server with the same bge card (the
same pciconf -lvc output as described by Mahlon:
http://lists.freebsd.org/**pipermail/freebsd-stable/2010-**
September/058711.htmlhttp://lists.freebsd.org/pipermail/freebsd-stable/2010-September/058711.html
Yours, Scott, is a em(4)..
Another similarity: In all cases we are using VirtualBox. I
just want to mention it, in case it matters. I am still
running VirtualBox 3.2.
Most of the time kstat.zfs.misc.arcstats.size was reaching
vfs.zfs.arc_max then, but I could catch one or two cases
then the value was still below.
I added vfs.zfs.prefetch_disable=1 to sysctl.conf but it
does not help.
BTW: It looks as ARC only gives back the memory when I
destroy the ZFS (a cloned snapshot containing virtual
machines). Even if nothing happens for hours the buffer
isn't released..
My machine was still running 8.2-PRERELEASE so I am upgrading.
I am happy to give information gathered on old/new kernel if it
helps.
Regards
Peter
Quoting Scott Sipe csco...@gmail.com:
On Jul 2, 2011, at 12:54 AM, jhell wrote:
On Fri, Jul 01, 2011 at 03:22:32PM -0700, Jeremy Chadwick
wrote:
On Fri, Jul 01, 2011 at 03:13:17PM -0400, Scott Sipe wrote:
I'm running 8.2-RELEASE and am having new problems
with scp. When scping
files to a ZFS directory on the FreeBSD server --
most notably large files
-- the transfer frequently dies after just a few
seconds. In my last test, I
tried to scp an 800mb file to the FreeBSD system and
the transfer died after
200mb. It completely copied the next 4 times I
tried, and then died again on
the next attempt.
On the client side:
Connection to home closed by remote host.
lost connection
In /var/log/auth.log:
Jul 1 14:54:42 freebsd sshd[18955]: fatal: Write
failed: Cannot allocate
memory
I've never seen this before and have used scp before
to transfer large files
without problems. This computer has been used in
production for months and
has a current uptime of 36 days. I have not been
able to notice any problems
copying files to the server via samba or netatalk, or
any problems in
apache.
Uname:
FreeBSD xeon 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Sat
Feb 19 01:02:54 EST
2011 root@xeon:/usr/obj/usr/src/**sys/GENERIC amd64
I've attached my dmesg and output of vmstat -z.
I have not restarted the sshd daemon or rebooted the
computer.
Am glad to provide any other information or test anything
else.
{snip vmstat -z and dmesg}
You didn't provide details about your networking setup
(rc.conf,
ifconfig -a, etc.). netstat -m would be useful too.
Next, please see this thread circa September 2010, titled
Network
memory allocation failures:
http://lists.freebsd.org/**pipermail/freebsd-stable/2010-**
September/thread.html#58708http://lists.freebsd.org/pipermail/freebsd-stable/2010-September/thread.html#58708
The user in that thread is using rsync, which relies on
scp by default.
I believe this problem is similar, if not identical, to yours.
Please also provide your output of ( /usr/bin/limits -a )
for the server
end and the client.
I am not quite sure I agree with the need for ifconfig -a but
some
information about the networking driver your using
Re: powernow regression in 8-STABLE
On 19Jul11 12:04, Jung-uk Kim wrote: }On Tuesday 19 July 2011 07:20 am, Callum Gibson wrote: } I've just noticed and tracked down a regression in } x86/cpufreq/powernow.c (on amd64) which was first mentioned here: } } http://lists.freebsd.org/pipermail/freebsd-current/2011-March/02350 }9.html } } although no followup seems to have occurred. } } Symptoms are that powerd stops working because the dev.cpu.0.freq } OID is no longer gettable nor settable. }[snip] } }HP again... Can you please show me verbose boot messages? I've put them in http://members.optusnet.com.au/callumgibson/verboseboot.out for you. This is a boot (and shutdown) of the kernel which exhibits the problem (hence kernel.old in output). (On the plus side, this HP laptop now suspends and resumes properly after 5 years. Not sure when that started happening.) regards, Callum -- Callum Gibson @ home http://members.optusnet.com.au/callumgibson/ ___ 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: Status of support for 4KB disk sectors
On Tue, 19 Jul 2011, Chuck Swiger wrote: Is there something in FreeBSD which is preventing you from using the drive's native DEV_BSIZE of 4096 bytes, or is it that the drive claims to have a physical block size of 512 bytes when it is really 4k? Are there any 4K-block drives that are honest about it, rather than reporting 512-byte blocks for backwards compatibility? ___ 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: Status of support for 4KB disk sectors
Chuck Swiger cswi...@mac.com wrote: On Jul 19, 2011, at 2:10 PM, Peter Jeremy wrote: On 2011-Jul-19 10:54:38 -0700, Chuck Swiger cswi...@mac.com wrote: Unix operating systems like SunOS 3 and NEXTSTEP would happily run with a DEV_BSIZE of 1024 or larger-- they'd boot fine off of optical media using 2048-byte sectors, Actually, Sun used customised CD-ROM drives that faked 512-byte sectors to work around their lack of support for anything else. Hmm-- my brain could be fuzzy about things twenty-plus years ago. But I remember booting a Sun3_35 or _60 from a non-Sun or Sun OEM'ed SCSI CD-ROM drive, probably a Plextor? IIRC, Plextor (and maybe some others) had a switch to select 512 or 2048 as the default transfer size, precisely so that they could be used as boot devices with systems that supported only 512. ___ 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: Status of support for 4KB disk sectors
On Wed, Jul 20, 2011 at 02:39:28AM -0700, per...@pluto.rain.com wrote: Chuck Swiger cswi...@mac.com wrote: On Jul 19, 2011, at 2:10 PM, Peter Jeremy wrote: On 2011-Jul-19 10:54:38 -0700, Chuck Swiger cswi...@mac.com wrote: Unix operating systems like SunOS 3 and NEXTSTEP would happily run with a DEV_BSIZE of 1024 or larger-- they'd boot fine off of optical media using 2048-byte sectors, Actually, Sun used customised CD-ROM drives that faked 512-byte sectors to work around their lack of support for anything else. Hmm-- my brain could be fuzzy about things twenty-plus years ago. But I remember booting a Sun3_35 or _60 from a non-Sun or Sun OEM'ed SCSI CD-ROM drive, probably a Plextor? IIRC, Plextor (and maybe some others) had a switch to select 512 or 2048 as the default transfer size, precisely so that they could be used as boot devices with systems that supported only 512. I don't think Plextor was around back then; they used to be called TEXEL back in the early 90s. The only Sun SCSI CD drives I saw were external and caddy-based, so I mentally correlate them with NEC. Back then I wasn't looking at brands as much as I do today, though. -- | Jeremy Chadwickjdc at 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: Status of support for 4KB disk sectors
On Jul 19, 2011, at 8:14 PM, Jeremy Chadwick wrote: On Wed, Jul 20, 2011 at 02:39:28AM -0700, per...@pluto.rain.com wrote: IIRC, Plextor (and maybe some others) had a switch to select 512 or 2048 as the default transfer size, precisely so that they could be used as boot devices with systems that supported only 512. Come to think of it, I do remember that switch, yes. Do you happen to know whether this limitation was part of the Sun hardware, or of SunOS? CMU had a lot of Sun3 machines and NeXT clusters, so I ended up mixing NeXT CD-ROM and the Canon? magneto-optical drives with Sun H/W, and vice versa. SunOS wasn't the only O/S which was run on a m68k Sun box. ;-) I don't think Plextor was around back then; they used to be called TEXEL back in the early 90s. The only Sun SCSI CD drives I saw were external and caddy-based, so I mentally correlate them with NEC. Back then I wasn't looking at brands as much as I do today, though. I'm pretty sure some folks had NEC caddy drives as well. Regards, -- -Chuck ___ 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
