kern.smp.maxid error on i386 UP [was: powerd / cpufreq question]
On Wed, 13 Apr 2011, Ian Smith wrote:
On Tue, 12 Apr 2011, Daniel Gerzo wrote:
On 11.4.2011 6:08, Ian Smith wrote:
[..]
Are those kern.cp_times values as they came, or did you remove trailing
zeroes? Reason I ask is that on my Thinkpad T23, single-core 1133/733
MHz, sysctl kern.cp_time shows the usual 5 values, but kern.cp_times has
the same 5 values for cpu0, but then 5 zeroes for each of cpu1 through
cpu31, on 8.2-PRE about early January. I need to update the script to
remove surplus data for non-existing cpus, but wonder if the extra data
also appeared on your 12 core box?
I haven't removed anything, it's a pure copypaste.
Thanks. I'll check the single-cpu case again after updating to 8.2-R
Ok, still a problem on at least my i386 single core Thinkpad T23 at
8.2-R, since 8.0 I think, certainly evident in a sysctl -a at 8.1-R
FreeBSD t23.smithi.id.au 8.2-RELEASE FreeBSD 8.2-RELEASE #1: Thu Apr 14
21:45:47 EST 2011 r...@t23.smithi.id.au:/usr/obj/usr/src/sys/GENERIC i386
Verbose dmesg: http://smithi.id.au/t23_dmesg_boot-v.8.2-R.txt
sysctl -a: http://smithi.id.au/t23_sysctl-a_8.2-R.txt
kern.ccpu: 0
cpu count=1 mask=0x10/cpu
kern.smp.forward_signal_enabled: 1
kern.smp.topology: 0
kern.smp.cpus: 1
kern.smp.disabled: 0
kern.smp.active: 0
kern.smp.maxcpus: 32
kern.smp.maxid: 31
hw.ncpu: 1
kern.cp_times: 38548 1 120437 195677 9660939 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
/usr/src/sys/kern/kern_clock.c:
return SYSCTL_OUT(req, 0, sizeof(long) * CPUSTATES * (mp_maxid + 1));
Consumers of kern.cp_times like powerd, top, dtrace? and others have to
loop over 32 cpus, all but one non-existent, and there seem to be many
places in the kernel doing eg: for (cpu = 0; cpu = mp_maxid; cpu++) {
and while CPU_FOREACH / CPU_ABSENT will skip over them, seems wasteful
at best on machines least likely to have cycles to spare.
eg: powerd parses kern.cp_times to count cpus, wasting cycles adding
up the 31 'empty' cpus. I haven't explored other userland consumers.
Clearly kern.smp.maxid (ie mp_maxid) should be 0, not 31. On i386,
non-APIC i386 at least, mp_maxid is not set to (mp_ncpus - 1) as on some
other archs .. after having being initialised to (MAXCPU - 1) in
/sys/i386/i386/mp_machdep.c it's never updated for non-smp machines.
I haven't chased all of these rabbits down all of their holes by any
means, but it seems that making /sys/i386/i386/mp_machdep.c do what it
says it's gonna do ('with an id of 0') should help. Paste, tabs lost:
int
cpu_mp_probe(void)
{
/*
* Always record BSP in CPU map so that the mbuf init code works
* correctly.
*/
all_cpus = 1;
if (mp_ncpus == 0) {
/*
* No CPUs were found, so this must be a UP system. Setup
* the variables to represent a system with a single CPU
* with an id of 0.
*/
mp_ncpus = 1;
+ mp_maxid = 0;
return (0);
}
/* At least one CPU was found. */
if (mp_ncpus == 1) {
/*
* One CPU was found, so this must be a UP system with
* an I/O APIC.
*/
+ mp_maxid = 0;
return (0);
}
/* At least two CPUs were found. */
return (1);
}
Note that the second added line above already exists in
/sys/amd64/amd64/mp_machdep.c, maybe to fix a similar problem, though
that should only apply to 'a UP system with an I/O APIC'. Maybe better
could be to fix this in cpu_mp_probe's caller, /sys/kern/subr_smp.c:
static void
mp_start(void *dummy)
{
mtx_init(smp_ipi_mtx, smp rendezvous, NULL, MTX_SPIN);
/* Probe for MP hardware. */
if (smp_disabled != 0 || cpu_mp_probe() == 0) {
mp_ncpus = 1;
+ mp_maxid = 0;
all_cpus = PCPU_GET(cpumask);
return;
}
cpu_mp_start();
printf(FreeBSD/SMP: Multiprocessor System Detected: %d CPUs\n,
mp_ncpus);
cpu_mp_announce();
}
I'm probably a long way off base for a solution, but think I've located
the problem. Thoughts? Is this a known issue? Might any developers
actually still have a single-cpu i386 system to check this on? :)
Very happy to test any patches etc.
cheers, Ian
___
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: kern.smp.maxid error on i386 UP [was: powerd / cpufreq question]
On 20 April 2011 21:02, Ian Smith smi...@nimnet.asn.au wrote:
On Wed, 13 Apr 2011, Ian Smith wrote:
On Tue, 12 Apr 2011, Daniel Gerzo wrote:
On 11.4.2011 6:08, Ian Smith wrote:
[..]
Are those kern.cp_times values as they came, or did you remove
trailing
zeroes? Reason I ask is that on my Thinkpad T23, single-core 1133/733
MHz, sysctl kern.cp_time shows the usual 5 values, but kern.cp_times
has
the same 5 values for cpu0, but then 5 zeroes for each of cpu1 through
cpu31, on 8.2-PRE about early January. I need to update the script to
remove surplus data for non-existing cpus, but wonder if the extra
data
also appeared on your 12 core box?
I haven't removed anything, it's a pure copypaste.
Thanks. I'll check the single-cpu case again after updating to 8.2-R
Ok, still a problem on at least my i386 single core Thinkpad T23 at
8.2-R, since 8.0 I think, certainly evident in a sysctl -a at 8.1-R
FreeBSD t23.smithi.id.au 8.2-RELEASE FreeBSD 8.2-RELEASE #1: Thu Apr 14
21:45:47 EST 2011 r...@t23.smithi.id.au:/usr/obj/usr/src/sys/GENERIC i386
Verbose dmesg: http://smithi.id.au/t23_dmesg_boot-v.8.2-R.txt
sysctl -a: http://smithi.id.au/t23_sysctl-a_8.2-R.txt
kern.ccpu: 0
cpu count=1 mask=0x10/cpu
kern.smp.forward_signal_enabled: 1
kern.smp.topology: 0
kern.smp.cpus: 1
kern.smp.disabled: 0
kern.smp.active: 0
kern.smp.maxcpus: 32
kern.smp.maxid: 31
hw.ncpu: 1
kern.cp_times: 38548 1 120437 195677 9660939 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
/usr/src/sys/kern/kern_clock.c:
return SYSCTL_OUT(req, 0, sizeof(long) * CPUSTATES * (mp_maxid + 1));
Consumers of kern.cp_times like powerd, top, dtrace? and others have to
loop over 32 cpus, all but one non-existent, and there seem to be many
places in the kernel doing eg: for (cpu = 0; cpu = mp_maxid; cpu++) {
and while CPU_FOREACH / CPU_ABSENT will skip over them, seems wasteful
at best on machines least likely to have cycles to spare.
eg: powerd parses kern.cp_times to count cpus, wasting cycles adding
up the 31 'empty' cpus. I haven't explored other userland consumers.
Clearly kern.smp.maxid (ie mp_maxid) should be 0, not 31. On i386,
non-APIC i386 at least, mp_maxid is not set to (mp_ncpus - 1) as on some
other archs .. after having being initialised to (MAXCPU - 1) in
/sys/i386/i386/mp_machdep.c it's never updated for non-smp machines.
I haven't chased all of these rabbits down all of their holes by any
means, but it seems that making /sys/i386/i386/mp_machdep.c do what it
says it's gonna do ('with an id of 0') should help. Paste, tabs lost:
int
cpu_mp_probe(void)
{
/*
* Always record BSP in CPU map so that the mbuf init code works
* correctly.
*/
all_cpus = 1;
if (mp_ncpus == 0) {
/*
* No CPUs were found, so this must be a UP system. Setup
* the variables to represent a system with a single CPU
* with an id of 0.
*/
mp_ncpus = 1;
+ mp_maxid = 0;
return (0);
}
/* At least one CPU was found. */
if (mp_ncpus == 1) {
/*
* One CPU was found, so this must be a UP system with
* an I/O APIC.
*/
+ mp_maxid = 0;
return (0);
}
/* At least two CPUs were found. */
return (1);
}
Note that the second added line above already exists in
/sys/amd64/amd64/mp_machdep.c, maybe to fix a similar problem, though
that should only apply to 'a UP system with an I/O APIC'. Maybe better
could be to fix this in cpu_mp_probe's caller, /sys/kern/subr_smp.c:
static void
mp_start(void *dummy)
{
mtx_init(smp_ipi_mtx, smp rendezvous, NULL, MTX_SPIN);
/* Probe for MP hardware. */
if (smp_disabled != 0 || cpu_mp_probe() == 0) {
mp_ncpus = 1;
+ mp_maxid = 0;
all_cpus = PCPU_GET(cpumask);
return;
}
cpu_mp_start();
printf(FreeBSD/SMP: Multiprocessor System Detected: %d CPUs\n,
mp_ncpus);
cpu_mp_announce();
}
I'm probably a long way off base for a solution, but think I've located
the problem. Thoughts? Is this a known issue? Might any developers
actually still have a single-cpu i386 system to check this on? :)
Very happy to test any patches etc.
Ouch.
Looks like that affects a system with 2 cores as well.
Intel Core2 E7200, 8.2-R i386 SMP:
kern.smp.forward_signal_enabled: 1
kern.smp.topology: 0
kern.smp.cpus: 2
kern.smp.disabled: 0
Re: kern.smp.maxid error on i386 UP [was: powerd / cpufreq question]
On 20 April 2011 22:29, Sergey Kandaurov pluk...@gmail.com wrote:
On 20 April 2011 21:02, Ian Smith smi...@nimnet.asn.au wrote:
On Wed, 13 Apr 2011, Ian Smith wrote:
On Tue, 12 Apr 2011, Daniel Gerzo wrote:
On 11.4.2011 6:08, Ian Smith wrote:
[..]
Are those kern.cp_times values as they came, or did you remove
trailing
zeroes? Reason I ask is that on my Thinkpad T23, single-core
1133/733
MHz, sysctl kern.cp_time shows the usual 5 values, but kern.cp_times
has
the same 5 values for cpu0, but then 5 zeroes for each of cpu1
through
cpu31, on 8.2-PRE about early January. I need to update the script
to
remove surplus data for non-existing cpus, but wonder if the extra
data
also appeared on your 12 core box?
I haven't removed anything, it's a pure copypaste.
Thanks. I'll check the single-cpu case again after updating to 8.2-R
Ok, still a problem on at least my i386 single core Thinkpad T23 at
8.2-R, since 8.0 I think, certainly evident in a sysctl -a at 8.1-R
FreeBSD t23.smithi.id.au 8.2-RELEASE FreeBSD 8.2-RELEASE #1: Thu Apr 14
21:45:47 EST 2011 r...@t23.smithi.id.au:/usr/obj/usr/src/sys/GENERIC i386
Verbose dmesg: http://smithi.id.au/t23_dmesg_boot-v.8.2-R.txt
sysctl -a: http://smithi.id.au/t23_sysctl-a_8.2-R.txt
kern.ccpu: 0
cpu count=1 mask=0x10/cpu
kern.smp.forward_signal_enabled: 1
kern.smp.topology: 0
kern.smp.cpus: 1
kern.smp.disabled: 0
kern.smp.active: 0
kern.smp.maxcpus: 32
kern.smp.maxid: 31
hw.ncpu: 1
kern.cp_times: 38548 1 120437 195677 9660939 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
/usr/src/sys/kern/kern_clock.c:
return SYSCTL_OUT(req, 0, sizeof(long) * CPUSTATES * (mp_maxid + 1));
Consumers of kern.cp_times like powerd, top, dtrace? and others have to
loop over 32 cpus, all but one non-existent, and there seem to be many
places in the kernel doing eg: for (cpu = 0; cpu = mp_maxid; cpu++) {
and while CPU_FOREACH / CPU_ABSENT will skip over them, seems wasteful
at best on machines least likely to have cycles to spare.
eg: powerd parses kern.cp_times to count cpus, wasting cycles adding
up the 31 'empty' cpus. I haven't explored other userland consumers.
Clearly kern.smp.maxid (ie mp_maxid) should be 0, not 31. On i386,
non-APIC i386 at least, mp_maxid is not set to (mp_ncpus - 1) as on some
other archs .. after having being initialised to (MAXCPU - 1) in
/sys/i386/i386/mp_machdep.c it's never updated for non-smp machines.
I haven't chased all of these rabbits down all of their holes by any
means, but it seems that making /sys/i386/i386/mp_machdep.c do what it
says it's gonna do ('with an id of 0') should help. Paste, tabs lost:
int
cpu_mp_probe(void)
{
/*
* Always record BSP in CPU map so that the mbuf init code works
* correctly.
*/
all_cpus = 1;
if (mp_ncpus == 0) {
/*
* No CPUs were found, so this must be a UP system. Setup
* the variables to represent a system with a single CPU
* with an id of 0.
*/
mp_ncpus = 1;
+ mp_maxid = 0;
return (0);
}
/* At least one CPU was found. */
if (mp_ncpus == 1) {
/*
* One CPU was found, so this must be a UP system with
* an I/O APIC.
*/
+ mp_maxid = 0;
return (0);
}
/* At least two CPUs were found. */
return (1);
}
Note that the second added line above already exists in
/sys/amd64/amd64/mp_machdep.c, maybe to fix a similar problem, though
that should only apply to 'a UP system with an I/O APIC'. Maybe better
could be to fix this in cpu_mp_probe's caller, /sys/kern/subr_smp.c:
static void
mp_start(void *dummy)
{
mtx_init(smp_ipi_mtx, smp rendezvous, NULL, MTX_SPIN);
/* Probe for MP hardware. */
if (smp_disabled != 0 || cpu_mp_probe() == 0) {
mp_ncpus = 1;
+ mp_maxid = 0;
all_cpus = PCPU_GET(cpumask);
return;
}
cpu_mp_start();
printf(FreeBSD/SMP: Multiprocessor System Detected: %d CPUs\n,
mp_ncpus);
cpu_mp_announce();
}
I'm probably a long way off base for a solution, but think I've located
the problem. Thoughts? Is this a known issue? Might any developers
actually still have a single-cpu i386 system to check this on? :)
Very happy to test any patches etc.
Ouch.
Looks like that affects a system with 2 cores as well.
Intel Core2 E7200, 8.2-R i386 SMP:
Re: FreeBSD and DELL Perc H200
On 19 Apr 2011, at 22:16, Holger Kipp wrote: I have to install two production servers from Dell that come with a Perc H 200 controller. Disks are not recognized with 8.2-RELEASE :-( AFAIK Perc H 200 should be supported by mps(4) which wasn't merged to stable/8 until after 8.2. Any ideas? If this works with 8-stable, where can I download an ISO Image? Unfortunately the latest official snapshots were before the driver was merged. You could try first just to boot on the curent / FreeBSD 9 snapshots and see if it sees your disks at all. You can get the snapshot from ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/201102/ . I don't think there are any other snapshot services still running... so (assuming mps(4) actually works with H200) you need to make a build of stable/8 yourself - the simplest approach is probably to PXE boot the servers and install by hand... but that's of course not a trivial thing if you never tried it before. I suspect there will be new official snapshots at some point, but I don't know when... -- Simon L. B. Nielsen ___ 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: Large number of SATA commits (MFCs) to RELENG_8
On 4/19/2011 7:50 PM, Jeremy Chadwick wrote: I would advocate that folks rebuild world/kernel and make sure there aren't any issues seen, or any quirks which were previously needed are no longer. I haven't gone through *all* of the commits yet, but I do see some controller-centric things that got MFC'd, such as disabling of NCQ support on multiport Marvell 88SX61XX to relieve I/O timeouts when doing lots of I/O (common with ZFS). Below are the commits. Users should absolutely use cvsweb or similar tools to examine the commit message and see if anything relevant to their storage subsystems was modified. Remember, this is MFC'd in that it has been in HEAD for some time. Its not like its all untested. That being said, I tested out an updated kernel from today on a test box as well as upgraded my home server Hitachi HDS721010CLA332 JP4OA3EA at scbus0 target 0 lun 0 (pass0,ada0) Hitachi HDS721010CLA332 JP4OA3EA at scbus0 target 1 lun 0 (pass1,ada1) Hitachi HDS721010CLA332 JP4OA3EA at scbus0 target 2 lun 0 (pass2,ada2) Hitachi HDS721010CLA332 JP4OA3EA at scbus0 target 3 lun 0 (pass3,ada3) Port Multiplier 47261095 1f06at scbus0 target 15 lun 0 (pass4,pmp0) WDC WD1501FASS-00W2B0 01.00101 at scbus4 target 0 lun 0 (pass5,ada4) WDC WD1501FASS-00W2B0 01.00101 at scbus6 target 0 lun 0 (pass6,ada5) # zpool status pool: test1 state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM test1 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ada0 ONLINE 0 0 0 ada1 ONLINE 0 0 0 ada3 ONLINE 0 0 0 label/JP2940HD0352LC ONLINE 0 0 0 errors: No known data errors all off siis0@pci0:1:0:0: class=0x010400 card=0x71321095 chip=0x31321095 rev=0x01 hdr=0x00 vendor = 'Silicon Image Inc (Was: CMD Technology Inc)' device = 'PCI Express (1x) to 2 Port SATA300 (SiI 3132)' class = mass storage subclass = RAID cap 01[54] = powerspec 2 supports D0 D1 D2 D3 current D0 cap 05[5c] = MSI supports 1 message, 64 bit cap 10[70] = PCI-Express 1 legacy endpoint max data 128(1024) link x1(x1) ecap 0001[100] = AER 1 0 fatal 1 non-fatal 0 corrected ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: Large number of SATA commits (MFCs) to RELENG_8
On Wed, Apr 20, 2011 at 07:44:42PM -0400, Mike Tancsa wrote: On 4/19/2011 7:50 PM, Jeremy Chadwick wrote: I would advocate that folks rebuild world/kernel and make sure there aren't any issues seen, or any quirks which were previously needed are no longer. I haven't gone through *all* of the commits yet, but I do see some controller-centric things that got MFC'd, such as disabling of NCQ support on multiport Marvell 88SX61XX to relieve I/O timeouts when doing lots of I/O (common with ZFS). Below are the commits. Users should absolutely use cvsweb or similar tools to examine the commit message and see if anything relevant to their storage subsystems was modified. Remember, this is MFC'd in that it has been in HEAD for some time. Its not like its all untested. Understood, however the userbase of RELENG_8 is significantly higher than that of HEAD/CURRENT, and the userbase of RELENG_8 is a lot more likely to complain en masse when something breaks. My goal was to bring to the attention of the community that a large number of storage/AHCI/SATA-related MFCs had been done, and request that people (if possible) rebuild world/kernel to make sure all of their stuff still works. Better to catch it during RELENG_8 than during RELENG_8_3. :-) That being said, I tested out an updated kernel from today on a test box as well as upgraded my home server I also did the same on mine. INTEL SSDSA2M040G2GC 2CV102M3at scbus0 target 0 lun 0 (ada0,pass0) WDC WD1002FAEX-00Z3A0 05.01D05 at scbus3 target 0 lun 0 (ada1,pass1) WDC WD2001FASS-00U0B0 01.00101 at scbus4 target 0 lun 0 (ada2,pass2) WDC WD1001FALS-00J7B1 05.00K05 at scbus5 target 0 lun 0 (ada3,pass3) pool: backups state: ONLINE scrub: none requested config: NAMESTATE READ WRITE CKSUM backups ONLINE 0 0 0 ada2 ONLINE 0 0 0 errors: No known data errors pool: data state: ONLINE scrub: none requested config: NAMESTATE READ WRITE CKSUM dataONLINE 0 0 0 mirrorONLINE 0 0 0 ada1ONLINE 0 0 0 ada3ONLINE 0 0 0 errors: No known data errors ahci0@pci0:0:31:2: class=0x010601 card=0xd38015d9 chip=0x29228086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801IB/IR/IH (ICH9 Family) 6 port SATA AHCI Controller' class = mass storage subclass = SATA bar [10] = type I/O Port, range 32, base 0x1c50, size 8, enabled bar [14] = type I/O Port, range 32, base 0x1c44, size 4, enabled bar [18] = type I/O Port, range 32, base 0x1c48, size 8, enabled bar [1c] = type I/O Port, range 32, base 0x1c40, size 4, enabled bar [20] = type I/O Port, range 32, base 0x18e0, size 32, enabled bar [24] = type Memory, range 32, base 0xdc000800, size 2048, enabled cap 05[80] = MSI supports 16 messages enabled with 1 message cap 01[70] = powerspec 3 supports D0 D3 current D0 cap 12[a8] = SATA Index-Data Pair cap 13[b0] = PCI Advanced Features: FLR TP pass0: INTEL SSDSA2M040G2GC 2CV102M3 ATA-7 SATA 2.x device pass0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) protocol ATA/ATAPI-7 SATA 2.x device model INTEL SSDSA2M040G2GC firmware revision 2CV102M3 serial number XXX WWN 50015179591a451a cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 512, offset 0 LBA supported 78165360 sectors LBA48 supported 78165360 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 media RPM non-rotating Feature Support Enabled Value Vendor read ahead yes yes write cacheyes yes flush cacheyes yes overlapno Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management no no automatic acoustic management no no media status notification no no power-up in Standbyno no write-read-verify no no unload yes yes free-fall no no data set management (TRIM) yes pass1: WDC WD1002FAEX-00Z3A0 05.01D05 ATA-8 SATA 3.x device pass1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) protocol ATA/ATAPI-8 SATA 3.x device model WDC WD1002FAEX-00Z3A0 firmware revision 05.01D05 serial number XXX WWN 50014ee25a001e1c cylinders 16383 heads 16
Re: Large number of SATA commits (MFCs) to RELENG_8
Hello, Jeremy Chadwick! On Tue, Apr 19, 2011 at 04:50:38PM -0700 free...@jdc.parodius.com wrote about Large number of SATA commits (MFCs) to RELENG_8: Folks who use SATA (speaking generally here because there's too much that got touched) should be aware: Within the past ~7 hours there have been a *very* large number of commits by mav@ that pertain to SATA-related storage controllers and subsystems. I would advocate that folks rebuild world/kernel and make sure there aren't any issues seen, or any quirks which were previously needed are no longer. I haven't gone through *all* of the commits yet, but I do see some controller-centric things that got MFC'd, such as disabling of NCQ support on multiport Marvell 88SX61XX to relieve I/O timeouts when doing lots of I/O (common with ZFS). Below are the commits. Users should absolutely use cvsweb or similar tools to examine the commit message and see if anything relevant to their storage subsystems was modified. I have no problems with yesturday build world+kernel. All compiled ok and system boots ok. But I have 1 question, why needed src/UPDATING? There are a lot of changes in the tree since release date and there are no one in that file. May be we need another one file, like src/ChangeLog ? ;-) -- Lystopad Olexandr ___ 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
