Re: Status of support for 4KB disk sectors
On Mon, Jul 18, 2011 at 4:41 PM, Jeremy Chadwick 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 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 11:38:00PM -0400, Glen Barber wrote: > On 7/18/11 7:41 PM, Jeremy Chadwick 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/ > > > > Notice: I'm reading this as "how badly do 'green drives' suck?" It's important to note that not all WD Caviar Green drives use 4KB sectors. WD, as of this writing, uses the 4-letter "EARS" string in the drive model that denotes use of 4KB sectors. The Green series do have other problems that people have experienced, such as bugs/quirks in the firmware causing the drive to repetitively park its heads in the landing zone (witnessed as either really bad drive performance, or the drive falling off the bus + reattaching). You can detect this situation by looking at SMART attribute 193 (Load_Cycle_Count). A very high number (in the tens or hundreds of thousands for a drive that has only been in use for a week or so) is an indicator of the problem. WD apparently has given people firmware updates to fix the issue. However the drive firmware version number does not change after updating the microcode, but it does fix the problem. (For what it's worth, Samsung pulled this same manoeuvre when it came to firmware updates for a catastrophic bug on their SpinPoint F4 drives.) What I'm saying is there's no way to detect whether or not your drive is running the fixed firmware, other than looking at said SMART attribute. I do have references for this issue, but it will take me some time to dig up the URLs and so on. > FWIW, I've recently done the gnop(8) trick to two "green" drives in one > of my machines because I was seeing horrifying performance problems with > what I consider to be basic stuff, like 'portsnap extract', but more > severely with copying large data (file-backed bacula files to be exact) > into said datasets. I have yet to retry my read/write tests with drives > I have not converted with gnop(8). I imagine this would have a tremendous effect on performance. With SSDs, the estimated performance impact is between 30-50% depending on what the workload is. Meaning with SSDs, drives with aligned partitions perform 30-50% better. When you read about how NAND cell and NAND flash pages work (look it up on Wikipedia, look for FTL (flash transition layer)) it makes sense. With mechanical HDDs, I'm not sure what the performance hit is, but I imagine it's large. Furthermore, talking about SSDs again: I want to make folks aware of the fact that Intel SSDs use an 8KB NAND flash page (not 4KB!). NAND pages are erased 256 pages at a time (8*256=2MByte). When it comes to alignment, flash page size is what's of concern. So for Intel SSDs (X25 series, 320 series, and 510 series), 8KByte-aligned is the way to go. > I have not conclusively tested all possible combinations of > configurations, nor reverted the changes to the drives to retest, but if > it is of any interest, here's
Re: Status of support for 4KB disk sectors
On 7/18/11 7:41 PM, Jeremy Chadwick 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/ > Notice: I'm reading this as "how badly do 'green drives' suck?" FWIW, I've recently done the gnop(8) trick to two "green" drives in one of my machines because I was seeing horrifying performance problems with what I consider to be basic stuff, like 'portsnap extract', but more severely with copying large data (file-backed bacula files to be exact) into said datasets. I have yet to retry my read/write tests with drives I have not converted with gnop(8). I have not conclusively tested all possible combinations of configurations, nor reverted the changes to the drives to retest, but if it is of any interest, here's what I'm seeing. I have comparisons between WD "green" and "black" drives. Unfortunately, the machines are not completely similar - one is a Core2Quad, the other Core2Duo; one has 6GB RAM, the other 8GB RAM; also, 'orion' is running a month-old 8-STABLE; 'kaos' is running a 2-week-old -CURRENT. Both machines are using ZFSv28: orion % sysctl -n hw.ncpu; sysctl -n hw.physmem 4 6353416192 kaos % sysctl -n hw.ncpu; sysctl -n hw.physmem 2 8534401024 The drives in 'orion' are 1TB WD green drives in a ZFS mirror; the drives in 'kaos' are 1TB WD black drives in a raidz1 (3 drives). First the read test: kaos % sh -c 'time find /usr/src -type f -name \*.\[1-9\] >/dev/null' 12.94 real 0.60 user11.95 sys orion % sh -c 'time find /usr/src -type f -name \*.\[1-9\] >/dev/null' 118.02 real 0.46 user 8.74 sys I guess no real surprise here. 'kaos' has more spindles to read from, on top of faster seek times. Next the write test: The 'compressed' and 'dedup' datasets referenced below are 'lzjb' and 'sha256,verify', respectively. I'd wait for the 'compressed+dedup' tests to finish, but I have to wake up tomorrow morning. orion# sh -c 'time portsnap extract -p /zstore/perftest >/dev/null' 306.71 real44.37 user 110.28 sys orion# sh -c 'time portsnap extract -p /zstore/perftest_compress >/dev/null' 166.62 real43.87 user 109.49 sys orion# sh -c 'time portsnap extract -p /zstore/perftest_dedup >/dev/null' 3576.43 real44.98 user 109.12 sys kaos# sh -c 'time portsnap extract -p /perftest >/dev/null' 311.31 real51.23 user 193.37 sys kaos# sh -c 'time portsnap extract -p /perftest_compress >/dev/null' 269.85 real49.55 user 191.56 sys kaos# sh -c 'time portsnap extract -p /perftest_dedup >/dev/null' 4655.73 real51.86 user 196.22 sys Like I said, I have not yet had the time to retest this on drives without the gnop(8) fix (another similar zpool with 2 drives), so maybe the data I'm providing isn't relevant, but since the gnop(8) fix for 4K sector drives was mentioned, I thought it might be relevant to a point. > Now, that's for ZFS, but I'm under the impression the ex
Re: disable 64-bit dma for one PCI slot only?
On 18 Jul 2011 at 15:06, Scott Long wrote:
{Re: disable 64-bit dma for one PCI ...}:
> >> 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?
>
> Scott
Thank you for the discussion, John and Scott. I see
where this change would be made, Scott, and I want to try
it when I have an opportunity.
Mark
--
___
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, 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. Do I bother doing this with my SSDs? No. Am I suffering in performance? Probably. Why do I not care? Because the level of annoyance is extremely high -- remember, all of this has to be done from within the installer environment (referring to "Emergency Shell"), which on FreeBSD lacks an incredible amount of usability, and is even worse to deal with when doing a remote install via PXE/serial. Fixit is the only decent environment. Given that floppies are more or less gone, I don't understand why the Fixit environment doesn't replace the "Emergency Shell". -- | 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"
Status of support for 4KB disk sectors
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. -- 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: recommendations for laptop and desktop
On Mon, Jul 18, 2011 at 7:02 AM, Tom Evans wrote: > On Thu, Jul 14, 2011 at 9:44 PM, Jim Bryant wrote: >> stay away from newer hp laptops. >> > > HP also like to lock-down which wifi cards you can use from BIOS - the > machines won't complete POST with a 'bad' wifi card, so that's another > strike as far as I am concerned. > > I've never had problems from modern dell laptops with nvidia graphics. > I'm typing this on a Dell Latitude E6410 - Core i5, iwn wifi, em lan, > nvidia graphics, webcam supported by webcamd... I have a new Lenovo T520 which locks down the WiFi. How rude!! I even tried installing am Intel 6502, a card Lenovo sells with that system, but I still get the 104-unknown wireless card" message. I'm to the point where I am thinking of patching the whitelist in BIOS, but Lenovo's BIOS update is shipped as a CD image (.iso) and contains a single bootable file, [BOOT]. I know trat, if I screw it up, I have a dead MOBO, so it makes me more than a little nervous. I would assume that Lenovo ships its own version of the 6205 with a different PCI ID, but I have failed to find it on their web site. This leaves me tied to the wired GE port. :-( As far as nVidia graphics goes, beware the new nVidia daughter cards shipping with second gen Core i processors (a.k.a. Sandy Bridge). These processors include an integrated Intel GPU (Intel 3000) and nVidia is shipping "Optimus" versions of their GPUs which use the Intel GPU as the frame buffer and for some other (unspecified) functions. There is no xorg support and nVidia has stated very clearly that they have no plans to ever support Optimus cards for any OS but Windows. Since the Optimus versions share the model number of standalone graphics cards with the addition of "Optimus", it's easy to get one of these useless things by accident. I would have if I hadn't been warned at the last minute. -- 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 Mon, Jul 18, 2011 at 2:22 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).
Pretty please! This would be wonderful.
--
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 Mon, Jul 18, 2011 at 03:06:40PM -0600, 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?
>
+1
> 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: disable 64-bit dma for one PCI slot only?
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).
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: disable 64-bit dma for one PCI slot only?
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'?
--
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"
Re: disable 64-bit dma for one PCI slot only?
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?
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: disable 64-bit dma for one PCI slot only?
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? -- 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"
Re: diskless booting with 8.2 regression?
On Mon, 18 Jul 2011 12:38:22 +0200 Gerrit Kühn wrote about diskless booting with 8.2 regression?: I guess I found the root of all evil now: device nodes on zfs! This is how a linux /dev/console looked on the 8.0-FreeBSD server on zfsv15: crw--- 1 root wheel5, 1 Oct 28 2010 /tank/diskless/gco-fe2/dev/console Now, after updating to FreeBSD-8.2 and zfsv28 it looks like this on the server: crw-r--r-- 1 root wheel 255, 0x00ff Jul 18 16:33 /tank/diskless/pt-fe2/dev/console Strange enough, the Linux client still displays the correct values when using "ls -la", but it refuses to work properly. I tried creating new device nodes from the client side with mknod and I tried getting correct ones from a backup, but they always end up being broken. Even movong the directories over to a ufs volume leaves them unusable: crw-r--r-- 1 root wheel0, 0 Jul 18 16:33 /tmp/console Luckily, I am back into business now with my machines, because moving the stuff from zfs to ufs and dropping in a correct version of /dev on the ufs side works just fine. However, it would be great if this could be fixed, because I do not have many ufs partitions left these days... cu Gerrit GK> Hi all, GK> GK> I just updated my nfs/tftp server for diskless booting from 8.0-rel to GK> 8.2-stable. I have a bunch of Linux clients that used to work with the GK> 8.0-setup, but fail to boot now. GK> GK> On the server side I see GK> GK> Jul 18 11:18:24 mclane tftpd[72434]: Got ERROR packet: TFTP Aborted GK> GK> in the log/messages, but the Linux kernel appears to be transferred GK> over the net just fine (so this is probably not the real issue). It GK> starts to boot and fails at some later point (with no apparent error GK> message on screen) causing an endless reboot loop. GK> I already googled for quite some time on this now, but nothing useful GK> came up. The error message above seems to be harmless, at least the GK> machines of people reporting them work nevertheless. GK> GK> Are there any known issues/regressions with tftp/nfs diskless booting? GK> I read in some posts that people were vaguely "having problems" with GK> it when updating to 8.2-something, but could not find any details. Are GK> there any further hints what I could do to narrow down the problem? GK> GK> GK> cu GK> Gerrit GK> ___ GK> freebsd-stable@freebsd.org mailing list GK> http://lists.freebsd.org/mailman/listinfo/freebsd-stable GK> To unsubscribe, send any mail to GK> "freebsd-stable-unsubscr...@freebsd.org" GK> ___ 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"
recommendations for laptop and desktop
> I'm typing this on a Dell Latitude E6410 - Core i5, iwn wifi, em lan, > nvidia graphics, webcam supported by webcamd... There seems to be one interesting new laptop, lenovo e320, coded as 685D089. It is i3, 3000hd graphics, probably 5100 wifi. Model with freedos for about 460 euros. Matte screen, as far as I could find right now. And 13 inch. Available for 3-4 weeks. I assume 9.0 will have code ready. Best regards Zoran ___ 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: recommendations for laptop and desktop
On Thu, Jul 14, 2011 at 9:44 PM, Jim Bryant wrote: > stay away from newer hp laptops. > HP also like to lock-down which wifi cards you can use from BIOS - the machines won't complete POST with a 'bad' wifi card, so that's another strike as far as I am concerned. I've never had problems from modern dell laptops with nvidia graphics. I'm typing this on a Dell Latitude E6410 - Core i5, iwn wifi, em lan, nvidia graphics, webcam supported by webcamd... Cheers Tom ___ 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: Please, MFC r204087
Hello, Andriy. You wrote 18 июля 2011 г., 14:06:14: >> I've got panics, related to race, fixed in r204087, every second >> reboot on my 8-STABLE. This patch fixed them all. >> Applying custom patch after each update is painful. > You would get a better a chance of anyone looking into your request if you > provided a link to the commit or the commit log. > Just saying... Really, message was sent to committer too. But here is a links: http://svnweb.freebsd.org/base?view=revision&revision=204087 Log Message: Fix a race in regard of p_numthreads. -- // Black Lion AKA Lev Serebryakov ___ 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"
diskless booting with 8.2 regression?
Hi all, I just updated my nfs/tftp server for diskless booting from 8.0-rel to 8.2-stable. I have a bunch of Linux clients that used to work with the 8.0-setup, but fail to boot now. On the server side I see Jul 18 11:18:24 mclane tftpd[72434]: Got ERROR packet: TFTP Aborted in the log/messages, but the Linux kernel appears to be transferred over the net just fine (so this is probably not the real issue). It starts to boot and fails at some later point (with no apparent error message on screen) causing an endless reboot loop. I already googled for quite some time on this now, but nothing useful came up. The error message above seems to be harmless, at least the machines of people reporting them work nevertheless. Are there any known issues/regressions with tftp/nfs diskless booting? I read in some posts that people were vaguely "having problems" with it when updating to 8.2-something, but could not find any details. Are there any further hints what I could do to narrow down the problem? cu Gerrit ___ 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: Please, MFC r204087
on 17/07/2011 00:19 Lev Serebryakov said the following: > Hello, Freebsd-stable. > > I've got panics, related to race, fixed in r204087, every second > reboot on my 8-STABLE. This patch fixed them all. > > Applying custom patch after each update is painful. You would get a better a chance of anyone looking into your request if you provided a link to the commit or the commit log. Just saying... -- Andriy Gapon ___ 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"
