svn commit: r216249 - head/sys/dev/usb
Author: hselasky
Date: Tue Dec 7 08:20:20 2010
New Revision: 216249
URL: http://svn.freebsd.org/changeset/base/216249
Log:
Re-add a status check which sneaked out during r214804.
This change can fix some USB error messages showing up
during bootup.
MFC after:3 days
Approved by: thompsa (mentor)
Modified:
head/sys/dev/usb/usb_request.c
Modified: head/sys/dev/usb/usb_request.c
==
--- head/sys/dev/usb/usb_request.c Tue Dec 7 03:29:36 2010
(r216248)
+++ head/sys/dev/usb/usb_request.c Tue Dec 7 08:20:20 2010
(r216249)
@@ -793,6 +793,10 @@ usbd_req_reset_port(struct usb_device *u
if (err) {
goto done;
}
+ /* if the device disappeared, just give up */
+ if (!(UGETW(ps.wPortStatus) & UPS_CURRENT_CONNECT_STATUS)) {
+ goto done;
+ }
/* check if reset is complete */
if (UGETW(ps.wPortChange) & UPS_C_PORT_RESET) {
break;
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r216250 - in head/sys/cddl/dev/dtrace: amd64 i386
Author: avg
Date: Tue Dec 7 09:03:17 2010
New Revision: 216250
URL: http://svn.freebsd.org/changeset/base/216250
Log:
dtrace_gethrtime_init: pin to master while examining other CPUs
Also use pc_cpumask to be future-friendly.
Reviewed by: jhb
MFC after:2 weeks
Modified:
head/sys/cddl/dev/dtrace/amd64/dtrace_subr.c
head/sys/cddl/dev/dtrace/i386/dtrace_subr.c
Modified: head/sys/cddl/dev/dtrace/amd64/dtrace_subr.c
==
--- head/sys/cddl/dev/dtrace/amd64/dtrace_subr.cTue Dec 7 08:20:20
2010(r216249)
+++ head/sys/cddl/dev/dtrace/amd64/dtrace_subr.cTue Dec 7 09:03:17
2010(r216250)
@@ -405,6 +405,7 @@ dtrace_gethrtime_init_cpu(void *arg)
static void
dtrace_gethrtime_init(void *arg)
{
+ struct pcpu *pc;
uint64_t tsc_f;
cpumask_t map;
int i;
@@ -437,15 +438,14 @@ dtrace_gethrtime_init(void *arg)
nsec_scale = ((uint64_t)NANOSEC << SCALE_SHIFT) / tsc_f;
/* The current CPU is the reference one. */
+ sched_pin();
tsc_skew[curcpu] = 0;
-
CPU_FOREACH(i) {
if (i == curcpu)
continue;
- map = 0;
- map |= (1 << curcpu);
- map |= (1 << i);
+ pc = pcpu_find(i);
+ map = PCPU_GET(cpumask) | pc->pc_cpumask;
smp_rendezvous_cpus(map, dtrace_gethrtime_init_sync,
dtrace_gethrtime_init_cpu,
@@ -453,6 +453,7 @@ dtrace_gethrtime_init(void *arg)
tsc_skew[i] = tgt_cpu_tsc - hst_cpu_tsc;
}
+ sched_unpin();
}
SYSINIT(dtrace_gethrtime_init, SI_SUB_SMP, SI_ORDER_ANY,
dtrace_gethrtime_init, NULL);
Modified: head/sys/cddl/dev/dtrace/i386/dtrace_subr.c
==
--- head/sys/cddl/dev/dtrace/i386/dtrace_subr.c Tue Dec 7 08:20:20 2010
(r216249)
+++ head/sys/cddl/dev/dtrace/i386/dtrace_subr.c Tue Dec 7 09:03:17 2010
(r216250)
@@ -405,6 +405,7 @@ dtrace_gethrtime_init_cpu(void *arg)
static void
dtrace_gethrtime_init(void *arg)
{
+ struct pcpu *pc;
uint64_t tsc_f;
cpumask_t map;
int i;
@@ -437,15 +438,14 @@ dtrace_gethrtime_init(void *arg)
nsec_scale = ((uint64_t)NANOSEC << SCALE_SHIFT) / tsc_f;
/* The current CPU is the reference one. */
+ sched_pin();
tsc_skew[curcpu] = 0;
-
CPU_FOREACH(i) {
if (i == curcpu)
continue;
- map = 0;
- map |= (1 << curcpu);
- map |= (1 << i);
+ pc = pcpu_find(i);
+ map = PCPU_GET(cpumask) | pc->pc_cpumask;
smp_rendezvous_cpus(map, dtrace_gethrtime_init_sync,
dtrace_gethrtime_init_cpu,
@@ -453,6 +453,7 @@ dtrace_gethrtime_init(void *arg)
tsc_skew[i] = tgt_cpu_tsc - hst_cpu_tsc;
}
+ sched_unpin();
}
SYSINIT(dtrace_gethrtime_init, SI_SUB_SMP, SI_ORDER_ANY,
dtrace_gethrtime_init, NULL);
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r216251 - in head/sys/cddl/dev/dtrace: amd64 i386
Author: avg
Date: Tue Dec 7 09:19:47 2010
New Revision: 216251
URL: http://svn.freebsd.org/changeset/base/216251
Log:
dtrace_xcall: no need for special handling of curcpu
smp_rendezvous_cpus alreadt does the right thing in a very similar
fashion, so the code was kind of duplicating that.
MFC after:3 weeks
Modified:
head/sys/cddl/dev/dtrace/amd64/dtrace_subr.c
head/sys/cddl/dev/dtrace/i386/dtrace_subr.c
Modified: head/sys/cddl/dev/dtrace/amd64/dtrace_subr.c
==
--- head/sys/cddl/dev/dtrace/amd64/dtrace_subr.cTue Dec 7 09:03:17
2010(r216250)
+++ head/sys/cddl/dev/dtrace/amd64/dtrace_subr.cTue Dec 7 09:19:47
2010(r216251)
@@ -115,26 +115,13 @@ dtrace_xcall(processorid_t cpu, dtrace_x
{
cpumask_t cpus;
- critical_enter();
-
if (cpu == DTRACE_CPUALL)
cpus = all_cpus;
else
- cpus = (cpumask_t) (1 << cpu);
-
- /* If the current CPU is in the set, call the function directly: */
- if ((cpus & (1 << curcpu)) != 0) {
- (*func)(arg);
-
- /* Mask the current CPU from the set */
- cpus &= ~(1 << curcpu);
- }
-
- /* If there are any CPUs in the set, cross-call to those CPUs */
- if (cpus != 0)
- smp_rendezvous_cpus(cpus, NULL, func, smp_no_rendevous_barrier,
arg);
+ cpus = (cpumask_t)1 << cpu;
- critical_exit();
+ smp_rendezvous_cpus(cpus, smp_no_rendevous_barrier, func,
+ smp_no_rendevous_barrier, arg);
}
static void
Modified: head/sys/cddl/dev/dtrace/i386/dtrace_subr.c
==
--- head/sys/cddl/dev/dtrace/i386/dtrace_subr.c Tue Dec 7 09:03:17 2010
(r216250)
+++ head/sys/cddl/dev/dtrace/i386/dtrace_subr.c Tue Dec 7 09:19:47 2010
(r216251)
@@ -115,26 +115,13 @@ dtrace_xcall(processorid_t cpu, dtrace_x
{
cpumask_t cpus;
- critical_enter();
-
if (cpu == DTRACE_CPUALL)
cpus = all_cpus;
else
- cpus = (cpumask_t) (1 << cpu);
-
- /* If the current CPU is in the set, call the function directly: */
- if ((cpus & (1 << curcpu)) != 0) {
- (*func)(arg);
-
- /* Mask the current CPU from the set */
- cpus &= ~(1 << curcpu);
- }
-
- /* If there are any CPUs in the set, cross-call to those CPUs */
- if (cpus != 0)
- smp_rendezvous_cpus(cpus, NULL, func, smp_no_rendevous_barrier,
arg);
+ cpus = (cpumask_t)1 << cpu;
- critical_exit();
+ smp_rendezvous_cpus(cpus, smp_no_rendevous_barrier, func,
+ smp_no_rendevous_barrier, arg);
}
static void
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r216230 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
On Mon, Dec 06, 2010 at 03:18:49PM -0500, John Baldwin wrote: > On Monday, December 06, 2010 2:53:27 pm Pawel Jakub Dawidek wrote: > > On Mon, Dec 06, 2010 at 08:35:36PM +0100, Ivan Voras wrote: > > > Please persuade me on technical grounds why ashift, a property > > > intended for address alignment, should not be set in this way. If your > > > answer is "I don't know but you are still wrong because I say so" I > > > will respect it and back it out but only until I/we discuss the > > > question with upstream ZFS developers. > > > > No. You persuade me why changing ashift in ZFS, which, as the comment > > clearly states is "device's minimum transfer size" is better and not > > hackish than presenting the disk with properly configured sector size. > > This can not only affect disks that still use 512 bytes sectors, but > > doesn't fix the problem at all. It just works around the problem in ZFS > > when configured on top of raw disks. > > > > What about other file systems? What about other GEOM classes? GELI is > > great example here, as people use ZFS on top of GELI alot. GELI > > integrity verification works in a way that not reporting disk sector > > size properly will have huge negative performance impact. ZFS' ashift > > won't change that. > > I am mostly on your side here, but I wonder if GELI shouldn't prefer the > stripesize anyway? For example, if you ran GELI on top of RAID-5 I imagine > it > would be far more performant for it to use stripe-size logical blocks instead > of individual sectors for the underlying media. Not exactly. GELI with authentication stores checksum in the same sector as data. This way we have less than 512 bytes of data per sector. To still be able to provide power of 2 sectors GELI and not to lose too much space, GELI has to present larger sector to the upper layers. For example with 512 bytes sectors of the underlying provider, GELI presents 4kB sector to the upper layers, but every 4kB GELI sector is build from nine 512 bytes sector of the underlying provider. I'm not sure if my description is readable:) If you are interested, take a look at the top of g_eli_integrity.c. It might be better described in there. > The RAID-5 argument also suggests that other filesystems should probably > prefer stripe sizes to physical sector sizes when picking block sizes, etc. I'm not so sure. Stripe size of RAID5 tends to be too large to do that. By using 128kB ashift we will lose way too much space when it comes to smaller files and metadata. Stripesize is just a hit what alignment is optimal, but it is optional - consumer can decide to ignore it if we care more about space than performance, for example. Sectorsize on the other hand is not a hint, but really the smallest block a provider can handle. -- Pawel Jakub Dawidek http://www.wheelsystems.com p...@freebsd.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpTPfG47pgAr.pgp Description: PGP signature
Re: svn commit: r216230 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
On Mon, Dec 06, 2010 at 11:10:38PM +0200, Alexander Motin wrote: > On 06.12.2010 22:18, John Baldwin wrote: > >On Monday, December 06, 2010 2:53:27 pm Pawel Jakub Dawidek wrote: > >>On Mon, Dec 06, 2010 at 08:35:36PM +0100, Ivan Voras wrote: > >>>Please persuade me on technical grounds why ashift, a property > >>>intended for address alignment, should not be set in this way. If your > >>>answer is "I don't know but you are still wrong because I say so" I > >>>will respect it and back it out but only until I/we discuss the > >>>question with upstream ZFS developers. > >> > >>No. You persuade me why changing ashift in ZFS, which, as the comment > >>clearly states is "device's minimum transfer size" is better and not > >>hackish than presenting the disk with properly configured sector size. > >>This can not only affect disks that still use 512 bytes sectors, but > >>doesn't fix the problem at all. It just works around the problem in ZFS > >>when configured on top of raw disks. > > Both ATA and SCSI standards implemented support for different logical > and physical sector sizes. It is not a hack - it seems to be the way > manufacturers decided to go. At least on their words. IMHO hack in this > situation would be to report to GEOM some fake sector size, different > from one reported by device. In any way it is the main visible disk > characteristic, independently of what it's firmware does inside. We can be smarter than that, really. We all know the disk presents 512 bytes sectors only(?) because most of the software out there (including Windows, I guess) will simply break when they see disk with 4kB sector. We were trying very hard not to be limited to 512 byte sectors and we actually succedded: GEOM supports any sector size just fine, most (if not all) GEOM classes support power of 2 sectors just fine, even our two main file systems (UFS and ZFS) support !512 sectors. After all this work do we really don't want to take advantage of it? Maybe other operating systems can't deal with 4kB sectors, but we can, we were well prepared for this, why do we want to forget about that? -- Pawel Jakub Dawidek http://www.wheelsystems.com p...@freebsd.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpxwxBKK6fGx.pgp Description: PGP signature
Re: svn commit: r216230 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
On Mon, Dec 06, 2010 at 09:28:42PM +0100, Ivan Voras wrote: > But there are two reasons that I think are important, which resulted > in changing this: > > 1) It is being used out of the original context in the mailing list > posts I've referenced - it was being used (and in a worse way, by > having a hacked zpool binary) for alignment like I did in the patch, > despite that the sectorsize wasn't changed. FreeBSD is not Solaris, really. ZFS has a lot of code that is not needed in FreeBSD. For example we don't need to partition raw disks and use partition, we can simply use raw disks (or any other GEOM provider), thanks to GEOM. I also think that Solaris needs a lot of work to support 4kB sectors. We don't. We are prepared for that for a long time now. As I said many times now, doing such a change in ZFS will of course work for you, but it doesn't solve the problem properly. It doesn't solve the problem for all the other disks consumers. If you want to use hacked zpool binary that's fine by me, but don't commit this. > 2) The solaris "big sector" project, described in > http://arc.opensolaris.org/caselog/PSARC/2008/769/final_spec.txt > basically blesses ZFS to work with big sectors, and states "ZFS can > automatically run on larger sector size disk after the label change > and I/O path change." Since the effect of having a larger sectorsize > will effectively be only the change in ashift, this is what I've done. Hmm, what kind of argument is that? Yes, ZFS can work with larger sectors just fine. I have many such installations where I use ZFS on top of 4kB GELI providers. What this sentence describe is simply that ZFS is 4kB-sector ready. What you did actually suggest that ZFS can work only with 512 byte sectors, so you need to change alignment internally, which is not true - there is no need to modify ZFS, because it can support disks with larger sectors. > > BTW. ZFS is no longer open-source if you didn't notice. > > I have noticed but I don't understand how it affects FreeBSD. I would > like to discuss this sometime but unless you have some urgent > interpretation of this information, I think it's best to start another > thread about it. I'm just saying that discussing anything upstream is much harder now. PS. Do you know your change breaks all current ZFS installation if stripesize is defined for a provider? # zpool create tank ada0 (upgrade FreeBSD so that ada0 now reports 4kB stripesize) # zpool import tank cannot import 'tank': invalid vdev configuration So you change was not only poorly thought out and not reviewed, but also not even minimally tested. Before we go any further, back it out. -- Pawel Jakub Dawidek http://www.wheelsystems.com p...@freebsd.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpLfhpPH08mN.pgp Description: PGP signature
Re: svn commit: r216230 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
Pawel Jakub Dawidek wrote: > On Mon, Dec 06, 2010 at 11:10:38PM +0200, Alexander Motin wrote: >> On 06.12.2010 22:18, John Baldwin wrote: >>> On Monday, December 06, 2010 2:53:27 pm Pawel Jakub Dawidek wrote: On Mon, Dec 06, 2010 at 08:35:36PM +0100, Ivan Voras wrote: > Please persuade me on technical grounds why ashift, a property > intended for address alignment, should not be set in this way. If your > answer is "I don't know but you are still wrong because I say so" I > will respect it and back it out but only until I/we discuss the > question with upstream ZFS developers. No. You persuade me why changing ashift in ZFS, which, as the comment clearly states is "device's minimum transfer size" is better and not hackish than presenting the disk with properly configured sector size. This can not only affect disks that still use 512 bytes sectors, but doesn't fix the problem at all. It just works around the problem in ZFS when configured on top of raw disks. >> Both ATA and SCSI standards implemented support for different logical >> and physical sector sizes. It is not a hack - it seems to be the way >> manufacturers decided to go. At least on their words. IMHO hack in this >> situation would be to report to GEOM some fake sector size, different >> from one reported by device. In any way it is the main visible disk >> characteristic, independently of what it's firmware does inside. > > We can be smarter than that, really. We all know the disk presents 512 > bytes sectors only(?) because most of the software out there (including > Windows, I guess) will simply break when they see disk with 4kB sector. > We were trying very hard not to be limited to 512 byte sectors and we > actually succedded: GEOM supports any sector size just fine, most (if > not all) GEOM classes support power of 2 sectors just fine, even our two > main file systems (UFS and ZFS) support !512 sectors. After all this > work do we really don't want to take advantage of it? Maybe other > operating systems can't deal with 4kB sectors, but we can, we were well > prepared for this, why do we want to forget about that? It is really nice that we support bigger sector sizes. But unluckily we are not the only OS in universe. Disks with data may move between systems, partition could be shared, etc. We must keep compatibility -- period. Can you predict what happen if we try to use some FAT partition created by Windows (using 512bytes sectors) after we set disk sector size to 4K? I have feeling that we won't even read partition table properly, not speaking about FAT. Even GEOM classes supporting big sector sizes depend on that size to be constant -- otherwise they will just be unable to locate their own metadata in last sector. -- Alexander Motin ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r216230 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
On Tue, 7 Dec 2010 10:51:37 +0100 Pawel Jakub Dawidek wrote: > We can be smarter than that, really. We all know the disk presents 512 > bytes sectors only(?) because most of the software out there > (including Windows, I guess) will simply break when they see disk > with 4kB sector. 8 years ago Windows didn't support larger sector sizes; Vista and Windows 7 do. -- Bruce Cran ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r216230 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
On Tue, Dec 07, 2010 at 12:25:34PM +0200, Alexander Motin wrote: > It is really nice that we support bigger sector sizes. But unluckily we > are not the only OS in universe. Disks with data may move between > systems, partition could be shared, etc. We must keep compatibility -- > period. Can you predict what happen if we try to use some FAT partition > created by Windows (using 512bytes sectors) after we set disk sector > size to 4K? I have feeling that we won't even read partition table > properly, not speaking about FAT. Even GEOM classes supporting big > sector sizes depend on that size to be constant -- otherwise they will > just be unable to locate their own metadata in last sector. First valid argument, thank you:) BTW. What Ivan did changes ashift for existing ZFS pools as well, so it breaks them too. If we decide to align other things to stripesize we can still break compatibility with other operating systems. Also stripesize is really not good idea. For RAID5 it might be like 64kB or larger, which is definiately too large for ashift in ZFS or fragment size in UFS. -- Pawel Jakub Dawidek http://www.wheelsystems.com p...@freebsd.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpPfFCMmBD1D.pgp Description: PGP signature
Re: svn commit: r216230 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
On 7 December 2010 11:21, Pawel Jakub Dawidek wrote: > PS. Do you know your change breaks all current ZFS installation if > stripesize is defined for a provider? > > # zpool create tank ada0 > (upgrade FreeBSD so that ada0 now reports 4kB stripesize) > # zpool import tank > cannot import 'tank': invalid vdev configuration Actually I did test the patch and, similar to the Solaris people, found that ZFS records ashift in metadata and uses the recorded one instead of hardcoded / detected one. What you found here really shouldn't happen. Are you sure only stripesize was increased in your case, not sectorsize? > So you change was not only poorly thought out and not reviewed, but also > not even minimally tested. Before we go any further, back it out. This actually is the first problem that requires backing it out. I will do it. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r216230 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
On 07.12.2010 13:04, Pawel Jakub Dawidek wrote: On Tue, Dec 07, 2010 at 12:25:34PM +0200, Alexander Motin wrote: It is really nice that we support bigger sector sizes. But unluckily we are not the only OS in universe. Disks with data may move between systems, partition could be shared, etc. We must keep compatibility -- period. Can you predict what happen if we try to use some FAT partition created by Windows (using 512bytes sectors) after we set disk sector size to 4K? I have feeling that we won't even read partition table properly, not speaking about FAT. Even GEOM classes supporting big sector sizes depend on that size to be constant -- otherwise they will just be unable to locate their own metadata in last sector. First valid argument, thank you:) BTW. What Ivan did changes ashift for existing ZFS pools as well, so it breaks them too. I can't say anything about it. Ivan told me that it's not. You may discuss it between yourselves and I'll listen. :) If we decide to align other things to stripesize we can still break compatibility with other operating systems. Not necessary. Some places indeed may have some legacy requirements, for example, in theory MBR want partition to be aligned to "track boundary" (but I've seen many pre-formatted SD cards with MBR violating it to align partition to flash sector). Same time for BSD label I see no problem to align partitions any way we want. I also see no problems to make FAT cluster, UFS block/fragment, etc, to match some sizes. Also stripesize is really not good idea. For RAID5 it might be like 64kB or larger, which is definiately too large for ashift in ZFS or fragment size in UFS. I agree that minimal I/O size of 64K or 128K may be too much. In this case I've proposed Ivan to limit maximum used stripesize with some lower value, possibly tunable. But he preferred to not introduce new constants. I think we should not depend that stripesize should be small or big or power-of-2 or anything else. World is not uniform. Even for RAID it can theoretically vary from 1 sector to half of the disk. We have to reconsider it each time we are going to use it, taking to account local limitations and preferences. -- Alexander Motin ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r216230 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
On Tue, Dec 07, 2010 at 12:25:28PM +0100, Ivan Voras wrote: > On 7 December 2010 11:21, Pawel Jakub Dawidek wrote: > > > PS. Do you know your change breaks all current ZFS installation if > > stripesize is defined for a provider? > > > > # zpool create tank ada0 > > (upgrade FreeBSD so that ada0 now reports 4kB stripesize) > > # zpool import tank > > cannot import 'tank': invalid vdev configuration > > Actually I did test the patch and, similar to the Solaris people, > found that ZFS records ashift in metadata and uses the recorded one > instead of hardcoded / detected one. What you found here really > shouldn't happen. Are you sure only stripesize was increased in your > case, not sectorsize? if (pp->stripesize > pp->sectorsize) *ashift = highbit(MIN(pp->stripesize, SPA_MAXBLOCKSIZE)) - 1; else *ashift = highbit(MAX(pp->sectorsize, SPA_MINBLOCKSIZE)) - 1; If stripesize will start to be 4096, the ashift will change. Not sure what you test was, but it only works the other way around - create pool with 4kB ashift and import it when ashift is 512 bytes. -- Pawel Jakub Dawidek http://www.wheelsystems.com p...@freebsd.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpSLtqgvdycM.pgp Description: PGP signature
Re: svn commit: r216230 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
On Tue, Dec 07, 2010 at 01:31:27PM +0200, Alexander Motin wrote: > Not necessary. Some places indeed may have some legacy requirements, > for example, in theory MBR want partition to be aligned to "track > boundary" (but I've seen many pre-formatted SD cards with MBR > violating it to align partition to flash sector). Same time for BSD > label I see no problem to align partitions any way we want. I also > see no problems to make FAT cluster, UFS block/fragment, etc, to > match some sizes. >From a new installation of Windows 7 and FreeBSD CURRENT: GEOM: ada0: partition 3 does not start on a track boundary. GEOM: ada0: partition 3 does not end on a track boundary. GEOM: ada0: partition 2 does not start on a track boundary. GEOM: ada0: partition 2 does not end on a track bounary. Partition 2 is the reserved partition while 3 is an NTFS partition, both created in the Windows setup application. Since Windows isn't bothering to align partitions do we still need to warn about it? -- Bruce Cran ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r216230 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
on 07/12/2010 13:51 Bruce Cran said the following: > On Tue, Dec 07, 2010 at 01:31:27PM +0200, Alexander Motin wrote: >> Not necessary. Some places indeed may have some legacy requirements, >> for example, in theory MBR want partition to be aligned to "track >> boundary" (but I've seen many pre-formatted SD cards with MBR >> violating it to align partition to flash sector). Same time for BSD >> label I see no problem to align partitions any way we want. I also >> see no problems to make FAT cluster, UFS block/fragment, etc, to >> match some sizes. > >>From a new installation of Windows 7 and FreeBSD CURRENT: > > GEOM: ada0: partition 3 does not start on a track boundary. > GEOM: ada0: partition 3 does not end on a track boundary. > GEOM: ada0: partition 2 does not start on a track boundary. > GEOM: ada0: partition 2 does not end on a track bounary. > > Partition 2 is the reserved partition while 3 is an NTFS partition, both > created in the Windows setup application. > > Since Windows isn't bothering to align partitions do we still need to > warn about it? > No. And another reason is that modern drives do not actually report any CHS parameters, so I don't even know where we get them and how we (pretend to) know we track boundaries are. -- Andriy Gapon ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r216252 - head/sys/cddl/dev/cyclic/i386
Author: avg
Date: Tue Dec 7 12:04:06 2010
New Revision: 216252
URL: http://svn.freebsd.org/changeset/base/216252
Log:
opensolaris cyclic xcall: no need for special handling of curcpu
smp_rendezvous_cpus already properly handles current CPU case
and non-SMP case.
MFC after:3 weeks
Modified:
head/sys/cddl/dev/cyclic/i386/cyclic_machdep.c
Modified: head/sys/cddl/dev/cyclic/i386/cyclic_machdep.c
==
--- head/sys/cddl/dev/cyclic/i386/cyclic_machdep.c Tue Dec 7 09:19:47
2010(r216251)
+++ head/sys/cddl/dev/cyclic/i386/cyclic_machdep.c Tue Dec 7 12:04:06
2010(r216252)
@@ -121,13 +121,7 @@ static void reprogram(cyb_arg_t arg, hrt
static void xcall(cyb_arg_t arg, cpu_t *c, cyc_func_t func, void *param)
{
- /*
-* If the target CPU is the current one, just call the
-* function. This covers the non-SMP case.
-*/
- if (c == &solaris_cpu[curcpu])
- (*func)(param);
- else
- smp_rendezvous_cpus((cpumask_t) (1 << c->cpuid), NULL,
- func, smp_no_rendevous_barrier, param);
+
+ smp_rendezvous_cpus((cpumask_t) (1 << c->cpuid), NULL,
+ func, smp_no_rendevous_barrier, param);
}
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r216230 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
On Tue, Dec 07, 2010 at 01:57:04PM +0200, Andriy Gapon wrote: > on 07/12/2010 13:51 Bruce Cran said the following: > > On Tue, Dec 07, 2010 at 01:31:27PM +0200, Alexander Motin wrote: > >> Not necessary. Some places indeed may have some legacy requirements, > >> for example, in theory MBR want partition to be aligned to "track > >> boundary" (but I've seen many pre-formatted SD cards with MBR > >> violating it to align partition to flash sector). Same time for BSD > >> label I see no problem to align partitions any way we want. I also > >> see no problems to make FAT cluster, UFS block/fragment, etc, to > >> match some sizes. > > > >>From a new installation of Windows 7 and FreeBSD CURRENT: > > > > GEOM: ada0: partition 3 does not start on a track boundary. > > GEOM: ada0: partition 3 does not end on a track boundary. > > GEOM: ada0: partition 2 does not start on a track boundary. > > GEOM: ada0: partition 2 does not end on a track bounary. > > > > Partition 2 is the reserved partition while 3 is an NTFS partition, both > > created in the Windows setup application. > > > > Since Windows isn't bothering to align partitions do we still need to > > warn about it? > > > > No. > And another reason is that modern drives do not actually report any CHS > parameters, so I don't even know where we get them and how we (pretend to) > know > we track boundaries are. Modern drives do actually report CHS parameters. The values reported rarely (if ever) have any relationship whatsoever to reality, but they are reported. I guess the reason for them still being reported is to satisfy old systems that do not undestand LBA and insist on getting CHS parameters. -- Erik Trulsson ertr1...@student.uu.se ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r216253 - in head/sys/amd64: amd64 ia32 include linux32
Author: kib
Date: Tue Dec 7 12:17:43 2010
New Revision: 216253
URL: http://svn.freebsd.org/changeset/base/216253
Log:
Retire write-only PCB_FULLCTX pcb flag on amd64.
Reminded by: Petr Salinger
Tested by:pho
MFC after:1 week
Modified:
head/sys/amd64/amd64/exception.S
head/sys/amd64/amd64/genassym.c
head/sys/amd64/amd64/machdep.c
head/sys/amd64/amd64/vm_machdep.c
head/sys/amd64/ia32/ia32_signal.c
head/sys/amd64/include/pcb.h
head/sys/amd64/linux32/linux32_sysvec.c
Modified: head/sys/amd64/amd64/exception.S
==
--- head/sys/amd64/amd64/exception.STue Dec 7 12:04:06 2010
(r216252)
+++ head/sys/amd64/amd64/exception.STue Dec 7 12:17:43 2010
(r216253)
@@ -380,7 +380,6 @@ IDTVEC(fast_syscall)
movq%rsp,%rdi
callsyscall
movqPCPU(CURPCB),%rax
- andq$~PCB_FULLCTX,PCB_FLAGS(%rax)
MEXITCOUNT
jmp doreti
Modified: head/sys/amd64/amd64/genassym.c
==
--- head/sys/amd64/amd64/genassym.c Tue Dec 7 12:04:06 2010
(r216252)
+++ head/sys/amd64/amd64/genassym.c Tue Dec 7 12:17:43 2010
(r216253)
@@ -161,7 +161,6 @@ ASSYM(PCB_SIZE, sizeof(struct pcb));
ASSYM(PCB_DBREGS, PCB_DBREGS);
ASSYM(PCB_32BIT, PCB_32BIT);
ASSYM(PCB_GS32BIT, PCB_GS32BIT);
-ASSYM(PCB_FULLCTX, PCB_FULLCTX);
ASSYM(COMMON_TSS_RSP0, offsetof(struct amd64tss, tss_rsp0));
Modified: head/sys/amd64/amd64/machdep.c
==
--- head/sys/amd64/amd64/machdep.c Tue Dec 7 12:04:06 2010
(r216252)
+++ head/sys/amd64/amd64/machdep.c Tue Dec 7 12:17:43 2010
(r216253)
@@ -492,7 +492,6 @@ sigreturn(td, uap)
#endif
kern_sigprocmask(td, SIG_SETMASK, &ucp->uc_sigmask, NULL, 0);
- td->td_pcb->pcb_flags |= PCB_FULLCTX;
td->td_pcb->pcb_full_iret = 1;
return (EJUSTRETURN);
}
@@ -1908,7 +1907,6 @@ set_regs(struct thread *td, struct reg *
tp->tf_gs = regs->r_gs;
tp->tf_flags = TF_HASSEGS;
}
- td->td_pcb->pcb_flags |= PCB_FULLCTX;
return (0);
}
@@ -2095,7 +2093,6 @@ set_mcontext(struct thread *td, const mc
td->td_pcb->pcb_fsbase = mcp->mc_fsbase;
td->td_pcb->pcb_gsbase = mcp->mc_gsbase;
}
- td->td_pcb->pcb_flags |= PCB_FULLCTX;
td->td_pcb->pcb_full_iret = 1;
return (0);
}
Modified: head/sys/amd64/amd64/vm_machdep.c
==
--- head/sys/amd64/amd64/vm_machdep.c Tue Dec 7 12:04:06 2010
(r216252)
+++ head/sys/amd64/amd64/vm_machdep.c Tue Dec 7 12:17:43 2010
(r216253)
@@ -347,7 +347,6 @@ cpu_set_syscall_retval(struct thread *td
*/
td->td_frame->tf_rip -= td->td_frame->tf_err;
td->td_frame->tf_r10 = td->td_frame->tf_rcx;
- td->td_pcb->pcb_flags |= PCB_FULLCTX;
break;
case EJUSTRETURN:
Modified: head/sys/amd64/ia32/ia32_signal.c
==
--- head/sys/amd64/ia32/ia32_signal.c Tue Dec 7 12:04:06 2010
(r216252)
+++ head/sys/amd64/ia32/ia32_signal.c Tue Dec 7 12:17:43 2010
(r216253)
@@ -207,7 +207,6 @@ ia32_set_mcontext(struct thread *td, con
tp->tf_rflags = rflags;
tp->tf_rsp = mcp->mc_esp;
tp->tf_ss = mcp->mc_ss;
- td->td_pcb->pcb_flags |= PCB_FULLCTX;
td->td_pcb->pcb_full_iret = 1;
return (0);
}
@@ -743,7 +742,7 @@ ia32_setregs(struct thread *td, struct i
fpstate_drop(td);
/* Return via doreti so that we can change to a different %cs */
- pcb->pcb_flags |= PCB_FULLCTX | PCB_32BIT;
+ pcb->pcb_flags |= PCB_32BIT;
pcb->pcb_flags &= ~PCB_GS32BIT;
td->td_pcb->pcb_full_iret = 1;
td->td_retval[1] = 0;
Modified: head/sys/amd64/include/pcb.h
==
--- head/sys/amd64/include/pcb.hTue Dec 7 12:04:06 2010
(r216252)
+++ head/sys/amd64/include/pcb.hTue Dec 7 12:17:43 2010
(r216253)
@@ -73,7 +73,6 @@ struct pcb {
#definePCB_USERFPUINITDONE 0x10 /* fpu user state is initialized */
#definePCB_GS32BIT 0x20/* linux gs switch */
#definePCB_32BIT 0x40/* process has 32 bit context (segs
etc) */
-#definePCB_FULLCTX 0x80/* full context restore on sysret */
uint16_tpcb_initial_fpucw;
Modified: head/sys/amd64/linux32/linux32_sysvec.c
==
--- head/sys/amd64/linux32/linux32_sysvec.c Tue Dec 7 12:04:06 2010
(r216252)
++
Re: svn commit: r216252 - head/sys/cddl/dev/cyclic/i386
on 07/12/2010 14:04 Andriy Gapon said the following:
> Author: avg
> Date: Tue Dec 7 12:04:06 2010
> New Revision: 216252
> URL: http://svn.freebsd.org/changeset/base/216252
>
> Log:
> opensolaris cyclic xcall: no need for special handling of curcpu
>
> smp_rendezvous_cpus already properly handles current CPU case
> and non-SMP case.
This could also lead to problems because a thread could be not pinned to its
current CPU during direct (*func)(param) call.
> MFC after: 3 weeks
>
> Modified:
> head/sys/cddl/dev/cyclic/i386/cyclic_machdep.c
>
> Modified: head/sys/cddl/dev/cyclic/i386/cyclic_machdep.c
> ==
> --- head/sys/cddl/dev/cyclic/i386/cyclic_machdep.cTue Dec 7 09:19:47
> 2010(r216251)
> +++ head/sys/cddl/dev/cyclic/i386/cyclic_machdep.cTue Dec 7 12:04:06
> 2010(r216252)
> @@ -121,13 +121,7 @@ static void reprogram(cyb_arg_t arg, hrt
>
> static void xcall(cyb_arg_t arg, cpu_t *c, cyc_func_t func, void *param)
> {
> - /*
> - * If the target CPU is the current one, just call the
> - * function. This covers the non-SMP case.
> - */
> - if (c == &solaris_cpu[curcpu])
> - (*func)(param);
> - else
> - smp_rendezvous_cpus((cpumask_t) (1 << c->cpuid), NULL,
> - func, smp_no_rendevous_barrier, param);
> +
> + smp_rendezvous_cpus((cpumask_t) (1 << c->cpuid), NULL,
> + func, smp_no_rendevous_barrier, param);
> }
--
Andriy Gapon
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r216254 - in head/sys/cddl: compat/opensolaris/sys dev/cyclic
Author: avg
Date: Tue Dec 7 12:25:26 2010
New Revision: 216254
URL: http://svn.freebsd.org/changeset/base/216254
Log:
opensolaris cyclic: fix deadlock and make a little bit closer to upstream
The dealock was caused in the following way:
- thread T1 on CPU C1 holds a spin mutex, IPIs CPU C2 and waits for the
IPI to be handled
- C2 executes timer interrupt filter, thus has interrupts disabled, and
gets blocked on the spin mutex held by T1
The problem seems to have been introduced by simplifications made to
OpenSolaris code during porting.
The problem is fixed by reorganizing the code to more closely resemble
the upstream version. Interrupt filter (cyclic_fire) now doesn't
acquire any locks, all per-CPU data accesses are performed on a
target CPU with preemption and interrupts disabled thus precluding
concurrent access to the data.
cyp_mtx spin mutex is used to disable preemtion and interrupts; it's not
used for classical mutual exclusion, because xcall already serializes
calls to a CPU. It's an emulation of OpenSolaris
cyb_set_level(CY_HIGH_LEVEL) call, the spin mutexes could probably be
reduced to just a spinlock_enter()/_exit() pair.
Diff with upstream version is now reduced by ~500 lines, however it still
remains quite large - many things that are not needed (at the moment) or
are irrelevant on FreeBSD were simply ripped out during porting.
Examples of such things:
- support for CPU onlining/offlining
- support for suspend/resume
- support for running callouts at soft interrupt levels
- support for callout rebinding from CPU to CPU
- support for CPU partitions
Tested by:Artem Belevich
MFC after:3 weeks
X-MFC with: r216252
Modified:
head/sys/cddl/compat/opensolaris/sys/cyclic_impl.h
head/sys/cddl/dev/cyclic/cyclic.c
Modified: head/sys/cddl/compat/opensolaris/sys/cyclic_impl.h
==
--- head/sys/cddl/compat/opensolaris/sys/cyclic_impl.h Tue Dec 7 12:17:43
2010(r216253)
+++ head/sys/cddl/compat/opensolaris/sys/cyclic_impl.h Tue Dec 7 12:25:26
2010(r216254)
@@ -288,7 +288,14 @@ typedef struct cyc_id {
typedef struct cyc_xcallarg {
cyc_cpu_t *cyx_cpu;
- hrtime_t cyx_exp;
+ cyc_handler_t *cyx_hdlr;
+ cyc_time_t *cyx_when;
+ cyc_index_t cyx_ndx;
+ cyc_index_t *cyx_heap;
+ cyclic_t *cyx_cyclics;
+ cyc_index_t cyx_size;
+ uint16_t cyx_flags;
+ int cyx_wait;
} cyc_xcallarg_t;
#defineCY_DEFAULT_PERCPU 1
Modified: head/sys/cddl/dev/cyclic/cyclic.c
==
--- head/sys/cddl/dev/cyclic/cyclic.c Tue Dec 7 12:17:43 2010
(r216253)
+++ head/sys/cddl/dev/cyclic/cyclic.c Tue Dec 7 12:25:26 2010
(r216254)
@@ -473,73 +473,6 @@ cyclic_expire(cyc_cpu_t *cpu, cyc_index_
(*handler)(arg);
}
-static void
-cyclic_enable_xcall(void *v)
-{
- cyc_xcallarg_t *argp = v;
- cyc_cpu_t *cpu = argp->cyx_cpu;
- cyc_backend_t *be = cpu->cyp_backend;
-
- be->cyb_enable(be->cyb_arg);
-}
-
-static void
-cyclic_enable(cyc_cpu_t *cpu)
-{
- cyc_backend_t *be = cpu->cyp_backend;
- cyc_xcallarg_t arg;
-
- arg.cyx_cpu = cpu;
-
- /* Cross call to the target CPU */
- be->cyb_xcall(be->cyb_arg, cpu->cyp_cpu, cyclic_enable_xcall, &arg);
-}
-
-static void
-cyclic_disable_xcall(void *v)
-{
- cyc_xcallarg_t *argp = v;
- cyc_cpu_t *cpu = argp->cyx_cpu;
- cyc_backend_t *be = cpu->cyp_backend;
-
- be->cyb_disable(be->cyb_arg);
-}
-
-static void
-cyclic_disable(cyc_cpu_t *cpu)
-{
- cyc_backend_t *be = cpu->cyp_backend;
- cyc_xcallarg_t arg;
-
- arg.cyx_cpu = cpu;
-
- /* Cross call to the target CPU */
- be->cyb_xcall(be->cyb_arg, cpu->cyp_cpu, cyclic_disable_xcall, &arg);
-}
-
-static void
-cyclic_reprogram_xcall(void *v)
-{
- cyc_xcallarg_t *argp = v;
- cyc_cpu_t *cpu = argp->cyx_cpu;
- cyc_backend_t *be = cpu->cyp_backend;
-
- be->cyb_reprogram(be->cyb_arg, argp->cyx_exp);
-}
-
-static void
-cyclic_reprogram(cyc_cpu_t *cpu, hrtime_t exp)
-{
- cyc_backend_t *be = cpu->cyp_backend;
- cyc_xcallarg_t arg;
-
- arg.cyx_cpu = cpu;
- arg.cyx_exp = exp;
-
- /* Cross call to the target CPU */
- be->cyb_xcall(be->cyb_arg, cpu->cyp_cpu, cyclic_reprogram_xcall, &arg);
-}
-
/*
* cyclic_fire(cpu_t *)
*
@@ -570,17 +503,15 @@ static void
cyclic_fire(cpu_t *c)
{
cyc_cpu_t *cpu = c->cpu_cyclic;
-
- mtx_lock_spin(&cpu->cyp_mtx);
-
+ cyc_backend_t *be = cpu->cyp_backend;
cyc_index_t *heap = cpu->cyp_heap;
cyclic_t *cyclic, *cyclics = cpu->cyp_cyclics;
+ void *arg = be->cyb_arg;
hrtime_t now = gethrtime();
hrtime_t exp;
if (cpu->cyp_nelems == 0) {
/* This is a
svn commit: r216255 - in head/sys/amd64: amd64 linux32
Author: kib Date: Tue Dec 7 12:44:33 2010 New Revision: 216255 URL: http://svn.freebsd.org/changeset/base/216255 Log: Update some comments related to use of amd64 full context switch. In exec_linux_setregs(), use locally cached pointer to pcb to set pcb_full_iret. In set_regs(), note that full return is needed when code that sets segment registers is enabled. MFC after:1 week Modified: head/sys/amd64/amd64/machdep.c head/sys/amd64/amd64/vm_machdep.c head/sys/amd64/linux32/linux32_sysvec.c Modified: head/sys/amd64/amd64/machdep.c == --- head/sys/amd64/amd64/machdep.c Tue Dec 7 12:25:26 2010 (r216254) +++ head/sys/amd64/amd64/machdep.c Tue Dec 7 12:44:33 2010 (r216255) @@ -1906,6 +1906,7 @@ set_regs(struct thread *td, struct reg * tp->tf_fs = regs->r_fs; tp->tf_gs = regs->r_gs; tp->tf_flags = TF_HASSEGS; + td->td_pcb->pcb_full_iret = 1; } return (0); } Modified: head/sys/amd64/amd64/vm_machdep.c == --- head/sys/amd64/amd64/vm_machdep.c Tue Dec 7 12:25:26 2010 (r216254) +++ head/sys/amd64/amd64/vm_machdep.c Tue Dec 7 12:44:33 2010 (r216255) @@ -339,10 +339,9 @@ cpu_set_syscall_retval(struct thread *td * Reconstruct pc, we know that 'syscall' is 2 bytes, * lcall $X,y is 7 bytes, int 0x80 is 2 bytes. * We saved this in tf_err. -* We have to do a full context restore so that %r10 -* (which was holding the value of %rcx) is restored +* %r10 (which was holding the value of %rcx) is restored * for the next iteration. -* r10 restore is only required for freebsd/amd64 processes, +* %r10 restore is only required for freebsd/amd64 processes, * but shall be innocent for any ia32 ABI. */ td->td_frame->tf_rip -= td->td_frame->tf_err; Modified: head/sys/amd64/linux32/linux32_sysvec.c == --- head/sys/amd64/linux32/linux32_sysvec.c Tue Dec 7 12:25:26 2010 (r216254) +++ head/sys/amd64/linux32/linux32_sysvec.c Tue Dec 7 12:44:33 2010 (r216255) @@ -865,13 +865,13 @@ exec_linux_setregs(struct thread *td, st regs->tf_flags = TF_HASSEGS; regs->tf_cs = _ucode32sel; regs->tf_rbx = imgp->ps_strings; - td->td_pcb->pcb_full_iret = 1; load_cr0(rcr0() | CR0_MP | CR0_TS); fpstate_drop(td); - /* Return via doreti so that we can change to a different %cs */ + /* Do full restore on return so that we can change to a different %cs */ pcb->pcb_flags |= PCB_32BIT; pcb->pcb_flags &= ~PCB_GS32BIT; + pcb->pcb_full_iret = 1; td->td_retval[1] = 0; } ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r216230 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
on 07/12/2010 14:10 Erik Trulsson said the following: > On Tue, Dec 07, 2010 at 01:57:04PM +0200, Andriy Gapon wrote: >> And another reason is that modern drives do not actually report any CHS >> parameters, so I don't even know where we get them and how we (pretend to) >> know >> we track boundaries are. > > Modern drives do actually report CHS parameters. The values reported Hmm, can you give me a reference? That is, a command, a byte, etc... > rarely (if ever) have any relationship whatsoever to reality, but they > are reported. That's without a doubt. -- Andriy Gapon ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r216016 - head/sys/sparc64/include
On Mon, Dec 06, 2010 at 02:30:01PM -0800, m...@freebsd.org wrote: > On Mon, Dec 6, 2010 at 2:07 PM, Marius Strobl > wrote: > [lots of snip] > > > With that one the kernel now survies memguard_init() but then panics > > right afterwards when kmeminit() calls kmem_suballoc(): > > KDB: debugger backends: ddb > > KDB: current backend: ddb > > Copyright (c) 1992-2010 The FreeBSD Project. > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > ? ? ? ?The Regents of the University of California. All rights reserved. > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > FreeBSD 9.0-CURRENT #18 r215249:216120M: Mon Dec ?6 13:27:57 CET 2010 > > ? > > ?mar...@v20z.zeist.de:/home/marius/co/build/head2/sparc64.sparc64/usr/home/m4 > > WARNING: WITNESS option enabled, expect reduced performance. > > panic: kmem_suballoc: bad status return of 3 > > [more snip] > > Shooting in the dark a little... > > The bad status of 3 is presumably KERN_NO_SPACE because we attempted > to allocate too much space from the kernel_map. What are the actual > values of vm_kmem_size, kernel_map->min_offset, kernel_map->max_offset > at panic time? vm_kmem_size=5610405888 min_offset=3221225472 max_offset=13958643712 This is on a US3i machine with 16GB RAM. > How much virtual space does sparc64 support (since > earlier it was reported it's computed based on hardware capability, > for this specific machine?) > Currently, the limiting factor is that the kernel TSB is addressed virtually, which means that the TTEs for kernel TSB itself have to be put into locked dTLB slots taking up 1 4MB dTLB slot per 1GB. US3 family CPUs have 16 lockable 4MB dTLB and iTLB slots, which need to be shared between the TSB and the kernel itself though, i.e. a 9MB kernel also takes up 3 slots (US1/2 machines have 64 dTLB and iTLB slots but there these are also used for unlocked TTEs so we don't use more than 32 for kernel plus TSB on these). VM_MAX_KERNEL_ADDRESS is limited according to how many slots are available for the TSB, that's what I was referring to previously. Actually, US3 and later as well as SPARC64 V and later CPUs have a feature allowing the TSB to be addressed physically, circumventing the need to lock the TSB into the TLB, thus allowing the full 64-bit virtual address space to be used. Implementing that is on my TODO list but unfortunately that's not exactly straight forward and also requires some instructions to be patched at runtime so the kernel still works on US1/2 machines. Marius ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r216230 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
From: Bruce Cran Subject: Re: svn commit: r216230 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs Date: Tue, 7 Dec 2010 11:51:06 + > On Tue, Dec 07, 2010 at 01:31:27PM +0200, Alexander Motin wrote: > > Not necessary. Some places indeed may have some legacy requirements, > > for example, in theory MBR want partition to be aligned to "track > > boundary" (but I've seen many pre-formatted SD cards with MBR > > violating it to align partition to flash sector). Same time for BSD > > label I see no problem to align partitions any way we want. I also > > see no problems to make FAT cluster, UFS block/fragment, etc, to > > match some sizes. > > From a new installation of Windows 7 and FreeBSD CURRENT: > > GEOM: ada0: partition 3 does not start on a track boundary. > GEOM: ada0: partition 3 does not end on a track boundary. > GEOM: ada0: partition 2 does not start on a track boundary. > GEOM: ada0: partition 2 does not end on a track bounary. > > Partition 2 is the reserved partition while 3 is an NTFS partition, both > created in the Windows setup application. > > Since Windows isn't bothering to align partitions do we still need to > warn about it? The geom warnings are totally bogus, and no conclusion about anything can be drawn from them other than the disk partitions don't match the *FAKE* geometry cam creates for the disk. Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r216230 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
From: Erik Trulsson Subject: Re: svn commit: r216230 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs Date: Tue, 7 Dec 2010 13:10:58 +0100 > On Tue, Dec 07, 2010 at 01:57:04PM +0200, Andriy Gapon wrote: > > on 07/12/2010 13:51 Bruce Cran said the following: > > > On Tue, Dec 07, 2010 at 01:31:27PM +0200, Alexander Motin wrote: > > >> Not necessary. Some places indeed may have some legacy requirements, > > >> for example, in theory MBR want partition to be aligned to "track > > >> boundary" (but I've seen many pre-formatted SD cards with MBR > > >> violating it to align partition to flash sector). Same time for BSD > > >> label I see no problem to align partitions any way we want. I also > > >> see no problems to make FAT cluster, UFS block/fragment, etc, to > > >> match some sizes. > > > > > >>From a new installation of Windows 7 and FreeBSD CURRENT: > > > > > > GEOM: ada0: partition 3 does not start on a track boundary. > > > GEOM: ada0: partition 3 does not end on a track boundary. > > > GEOM: ada0: partition 2 does not start on a track boundary. > > > GEOM: ada0: partition 2 does not end on a track bounary. > > > > > > Partition 2 is the reserved partition while 3 is an NTFS partition, both > > > created in the Windows setup application. > > > > > > Since Windows isn't bothering to align partitions do we still need to > > > warn about it? > > > > > > > No. > > And another reason is that modern drives do not actually report any CHS > > parameters, so I don't even know where we get them and how we (pretend to) > > know > > we track boundaries are. > > Modern drives do actually report CHS parameters. The values reported > rarely (if ever) have any relationship whatsoever to reality, but they > are reported. I guess the reason for them still being reported is to > satisfy old systems that do not undestand LBA and insist on getting CHS > parameters. And even if the CHS parameters are reported, they are molested at many layers so cannot be trusted at all. CF Cards will report one thing if attached via usb adapters and another thing if attached directly to a pata bus, for example. Sometimes this is software (cam lying), other times this is hardware (usb adapter lying). Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r216256 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
Author: ivoras Date: Tue Dec 7 15:24:08 2010 New Revision: 216256 URL: http://svn.freebsd.org/changeset/base/216256 Log: Undo r216230: the interaction between saved ashift in metadata and detected ashift does not support this. With this change, pools created while stripesize=512 could not be imported when stripesize becomes larger (on the same drive). Noticed by: pjd Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c == --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c Tue Dec 7 12:44:33 2010(r216255) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c Tue Dec 7 15:24:08 2010(r216256) @@ -496,10 +496,7 @@ vdev_geom_open(vdev_t *vd, uint64_t *psi /* * Determine the device's minimum transfer size. */ - if (pp->stripesize > pp->sectorsize) - *ashift = highbit(MIN(pp->stripesize, SPA_MAXBLOCKSIZE)) - 1; - else - *ashift = highbit(MAX(pp->sectorsize, SPA_MINBLOCKSIZE)) - 1; + *ashift = highbit(MAX(pp->sectorsize, SPA_MINBLOCKSIZE)) - 1; /* * Clear the nowritecache bit, so that on a vdev_reopen() we will ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r216257 - head/usr.sbin/fifolog/lib
Author: phk
Date: Tue Dec 7 16:30:52 2010
New Revision: 216257
URL: http://svn.freebsd.org/changeset/base/216257
Log:
Use a "push" strategy to get data through libz, rather than a "pull" strategy.
Modified:
head/usr.sbin/fifolog/lib/fifolog_write.h
head/usr.sbin/fifolog/lib/fifolog_write_poll.c
Modified: head/usr.sbin/fifolog/lib/fifolog_write.h
==
--- head/usr.sbin/fifolog/lib/fifolog_write.h Tue Dec 7 15:24:08 2010
(r216256)
+++ head/usr.sbin/fifolog/lib/fifolog_write.h Tue Dec 7 16:30:52 2010
(r216257)
@@ -44,8 +44,6 @@ struct fifolog_writer {
unsignedsyncrate;
unsignedcompression;
- unsignedwrites_since_sync;
-
int cleanup;
intmax_tcnt[FIFOLOG_NPOINT];
@@ -55,9 +53,11 @@ struct fifolog_writer {
int flag;
time_t last;
+ u_int obufsize;
+ u_char *obuf;
+
u_int ibufsize;
u_char *ibuf;
- u_char *iptr;
time_t starttime;
time_t lastwrite;
Modified: head/usr.sbin/fifolog/lib/fifolog_write_poll.c
==
--- head/usr.sbin/fifolog/lib/fifolog_write_poll.c Tue Dec 7 15:24:08
2010(r216256)
+++ head/usr.sbin/fifolog/lib/fifolog_write_poll.c Tue Dec 7 16:30:52
2010(r216257)
@@ -33,6 +33,9 @@
#include
#include
#include
+#if 0
+#include
+#endif
#include
@@ -65,9 +68,8 @@ fifolog_write_assert(const struct fifolo
{
CHECK_OBJ_NOTNULL(f, FIFOLOG_WRITER_MAGIC);
- assert(f->iptr == f->ff->zs->next_in + f->ff->zs->avail_in);
assert(f->ff->zs->next_out + f->ff->zs->avail_out == \
- f->ff->recbuf + f->ff->recsize);
+ f->obuf + f->obufsize);
}
struct fifolog_writer *
@@ -75,8 +77,8 @@ fifolog_write_new(void)
{
struct fifolog_writer *f;
- ALLOC(&f, sizeof *f);
- f->magic = FIFOLOG_WRITER_MAGIC;
+ ALLOC_OBJ(f, FIFOLOG_WRITER_MAGIC);
+ assert(f != NULL);
return (f);
}
@@ -94,36 +96,11 @@ fifolog_write_close(struct fifolog_write
CHECK_OBJ_NOTNULL(f, FIFOLOG_WRITER_MAGIC);
fifolog_int_close(&f->ff);
free(f->ff);
- if (f->ibuf != NULL)
- free(f->ibuf);
+ if (f->obuf != NULL)
+ free(f->obuf);
free(f);
}
-static void
-fifo_prepobuf(struct fifolog_writer *f, time_t now, int flag)
-{
-
- memset(f->ff->recbuf, 0, f->ff->recsize);
- f->ff->zs->next_out = f->ff->recbuf + 5;
- f->ff->zs->avail_out = f->ff->recsize - 5;
- if (f->recno == 0 && f->seq == 0) {
- srandomdev();
- do {
- f->seq = random();
- } while (f->seq == 0);
- }
- be32enc(f->ff->recbuf, f->seq++);
- f->ff->recbuf[4] = f->flag;
- f->flag = 0;
- if (flag) {
- f->ff->recbuf[4] |= FIFOLOG_FLG_SYNC;
- be32enc(f->ff->recbuf + 5, (u_int)now);
- f->ff->zs->next_out += 4;
- f->ff->zs->avail_out -= 4;
- }
- fifolog_write_assert(f);
-}
-
const char *
fifolog_write_open(struct fifolog_writer *f, const char *fn, unsigned
writerate, unsigned syncrate, int compression)
{
@@ -164,144 +141,154 @@ fifolog_write_open(struct fifolog_writer
f->seq++;
}
- f->ibufsize = 32768;
- ALLOC(&f->ibuf, f->ibufsize);
- f->iptr = f->ibuf;
- f->ff->zs->next_in = f->iptr;
+ f->obufsize = f->ff->recsize;
+ ALLOC(&f->obuf, f->obufsize);
+
i = deflateInit(f->ff->zs, (int)f->compression);
assert(i == Z_OK);
f->flag |= FIFOLOG_FLG_RESTART;
+ f->flag |= FIFOLOG_FLG_SYNC;
+ f->ff->zs->next_out = f->obuf + 9;
+ f->ff->zs->avail_out = f->obufsize - 9;
time(&now);
- fifo_prepobuf(f, now, 1);
f->starttime = now;
+ f->lastsync = now;
+ f->lastwrite = now;
fifolog_write_assert(f);
return (NULL);
}
-static void
-fifo_writerec(struct fifolog_writer *f)
+static int
+fifolog_write_output(struct fifolog_writer *f, int fl, time_t now)
{
- int i;
- time_t t;
+ long h, l = f->ff->zs->next_out - f->obuf;
+ int i, w;
- fifolog_write_assert(f);
- f->writes_since_sync++;
+ h = 4; /* seq */
+ be32enc(f->obuf, f->seq);
+ f->obuf[h] = f->flag;
+ h += 1; /* flag */
+ if (f->flag & FIFOLOG_FLG_SYNC) {
+ b
svn commit: r216258 - in head/lib/libarchive: . test
Author: kientzle
Date: Tue Dec 7 16:48:01 2010
New Revision: 216258
URL: http://svn.freebsd.org/changeset/base/216258
Log:
Don't write data into an empty "file."
In particular, this check avoids a warning when
extracting directory entries from certain GNU tar
archives that store directory contents.
MFC after: 3 days
Modified:
head/lib/libarchive/archive_read_extract.c
head/lib/libarchive/test/Makefile
head/lib/libarchive/test/test_acl_freebsd.c
Modified: head/lib/libarchive/archive_read_extract.c
==
--- head/lib/libarchive/archive_read_extract.c Tue Dec 7 16:30:52 2010
(r216257)
+++ head/lib/libarchive/archive_read_extract.c Tue Dec 7 16:48:01 2010
(r216258)
@@ -40,6 +40,7 @@ __FBSDID("$FreeBSD$");
#endif
#include "archive.h"
+#include "archive_entry.h"
#include "archive_private.h"
#include "archive_read_private.h"
#include "archive_write_disk_private.h"
@@ -107,7 +108,7 @@ archive_read_extract2(struct archive *_a
if (r != ARCHIVE_OK)
/* If _write_header failed, copy the error. */
archive_copy_error(&a->archive, ad);
- else
+ else if (archive_entry_size(entry) > 0)
/* Otherwise, pour data into the entry. */
r = copy_data(_a, ad);
r2 = archive_write_finish_entry(ad);
Modified: head/lib/libarchive/test/Makefile
==
--- head/lib/libarchive/test/Makefile Tue Dec 7 16:30:52 2010
(r216257)
+++ head/lib/libarchive/test/Makefile Tue Dec 7 16:48:01 2010
(r216258)
@@ -2,10 +2,6 @@
# Where to find the libarchive sources
LA_SRCDIR=${.CURDIR}/..
-.PATH: ${LA_SRCDIR}
-
-# Get a list of all libarchive source files
-LA_SRCS!=make -f ${LA_SRCDIR}/Makefile -V SRCS
TESTS= \
test_acl_basic.c\
@@ -113,8 +109,8 @@ TESTS= \
test_write_open_memory.c
-# Build the test program using all libarchive sources + the test sources.
-SRCS= ${LA_SRCS} \
+# Build the test program.
+SRCS= \
${TESTS}\
list.h \
main.c \
@@ -125,14 +121,11 @@ NO_MAN=yes
PROG=libarchive_test
INTERNALPROG=yes # Don't install this; it's just for testing
DPADD=${LIBBZ2} ${LIBZ} ${LIBMD} ${LIBCRYPTO} ${LIBBSDXML}
-CFLAGS+= -DPLATFORM_CONFIG_H=\"config_freebsd.h\"
-LDADD= -lz -lbz2 -lmd -lcrypto -lbsdxml
+LDADD= -L ${.OBJDIR}/.. -larchive
+LDADD+= -lz -lbz2 -llzma -lmd -lcrypto -lbsdxml
CFLAGS+= -g
CFLAGS+= -I${LA_SRCDIR} -I.
-
-# Uncomment to build and test lzma and xz support via liblzma
-#CFLAGS+= -I/usr/local/include -DHAVE_LIBLZMA=1 -DHAVE_LZMA_H=1
-#LDADD+= -L/usr/local/lib -llzma
+CFLAGS+= -DHAVE_LIBLZMA=1 -DHAVE_LZMA_H=1
# Uncomment to link against dmalloc
#LDADD+= -L/usr/local/lib -ldmalloc
Modified: head/lib/libarchive/test/test_acl_freebsd.c
==
--- head/lib/libarchive/test/test_acl_freebsd.c Tue Dec 7 16:30:52 2010
(r216257)
+++ head/lib/libarchive/test/test_acl_freebsd.c Tue Dec 7 16:48:01 2010
(r216258)
@@ -220,6 +220,11 @@ DEFINE_TEST(test_acl_freebsd)
skipping("ACL tests require that ACL support be enabled on the
filesystem");
return;
}
+ if (n != 0 && errno == EINVAL) {
+ close(fd);
+ skipping("POSIX.1e ACL tests require that POSIX.1e ACL support
be enabled on the filesystem");
+ return;
+ }
failure("acl_set_fd(): errno = %d (%s)",
errno, strerror(errno));
assertEqualInt(0, n);
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r216261 - in stable/8/sys: amd64/amd64 i386/i386
Author: jkim Date: Tue Dec 7 18:14:38 2010 New Revision: 216261 URL: http://svn.freebsd.org/changeset/base/216261 Log: MFC: r216159 Do not change CPU ticker frequency if TSC is P-state invariant. Approved by: re (kib) Modified: stable/8/sys/amd64/amd64/tsc.c stable/8/sys/i386/i386/tsc.c Directory Properties: stable/8/sys/ (props changed) stable/8/sys/amd64/include/xen/ (props changed) stable/8/sys/cddl/contrib/opensolaris/ (props changed) stable/8/sys/contrib/dev/acpica/ (props changed) stable/8/sys/contrib/pf/ (props changed) Modified: stable/8/sys/amd64/amd64/tsc.c == --- stable/8/sys/amd64/amd64/tsc.c Tue Dec 7 17:54:04 2010 (r216260) +++ stable/8/sys/amd64/amd64/tsc.c Tue Dec 7 18:14:38 2010 (r216261) @@ -146,6 +146,9 @@ tsc_levels_changed(void *arg, int unit) int count, error; uint64_t max_freq; + if (tsc_is_invariant) + return; + /* Only use values from the first CPU, assuming all are equal. */ if (unit != 0) return; Modified: stable/8/sys/i386/i386/tsc.c == --- stable/8/sys/i386/i386/tsc.cTue Dec 7 17:54:04 2010 (r216260) +++ stable/8/sys/i386/i386/tsc.cTue Dec 7 18:14:38 2010 (r216261) @@ -170,6 +170,9 @@ tsc_levels_changed(void *arg, int unit) int count, error; uint64_t max_freq; + if (tsc_is_invariant) + return; + /* Only use values from the first CPU, assuming all are equal. */ if (unit != 0) return; ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r216262 - in stable/7/sys: amd64/amd64 i386/i386
Author: jkim Date: Tue Dec 7 18:15:18 2010 New Revision: 216262 URL: http://svn.freebsd.org/changeset/base/216262 Log: MFC: r216159 Do not change CPU ticker frequency if TSC is P-state invariant. Approved by: re (kib) Modified: stable/7/sys/amd64/amd64/tsc.c stable/7/sys/i386/i386/tsc.c Directory Properties: stable/7/sys/ (props changed) stable/7/sys/cddl/contrib/opensolaris/ (props changed) stable/7/sys/contrib/dev/acpica/ (props changed) stable/7/sys/contrib/pf/ (props changed) Modified: stable/7/sys/amd64/amd64/tsc.c == --- stable/7/sys/amd64/amd64/tsc.c Tue Dec 7 18:14:38 2010 (r216261) +++ stable/7/sys/amd64/amd64/tsc.c Tue Dec 7 18:15:18 2010 (r216262) @@ -151,6 +151,9 @@ tsc_levels_changed(void *arg, int unit) int count, error; uint64_t max_freq; + if (tsc_is_invariant) + return; + /* Only use values from the first CPU, assuming all are equal. */ if (unit != 0) return; Modified: stable/7/sys/i386/i386/tsc.c == --- stable/7/sys/i386/i386/tsc.cTue Dec 7 18:14:38 2010 (r216261) +++ stable/7/sys/i386/i386/tsc.cTue Dec 7 18:15:18 2010 (r216262) @@ -170,6 +170,9 @@ tsc_levels_changed(void *arg, int unit) int count, error; uint64_t max_freq; + if (tsc_is_invariant) + return; + /* Only use values from the first CPU, assuming all are equal. */ if (unit != 0) return; ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r216263 - head/sys/dev/acpica
Author: jhb
Date: Tue Dec 7 18:49:11 2010
New Revision: 216263
URL: http://svn.freebsd.org/changeset/base/216263
Log:
Use proper resource ID's for HPET IRQ resources. This mostly consists of
looking to see if there is an existing IRQ resource for a given IRQ
provided by the BIOS and using that RID if so. Otherwise, allocate a new
RID for the new IRQ.
Reviewed by: mav (a while ago)
Modified:
head/sys/dev/acpica/acpi_hpet.c
Modified: head/sys/dev/acpica/acpi_hpet.c
==
--- head/sys/dev/acpica/acpi_hpet.c Tue Dec 7 18:15:18 2010
(r216262)
+++ head/sys/dev/acpica/acpi_hpet.c Tue Dec 7 18:49:11 2010
(r216263)
@@ -303,6 +303,23 @@ hpet_find(ACPI_HANDLE handle, UINT32 lev
return (AE_OK);
}
+/*
+ * Find an existing IRQ resource that matches the requested IRQ range
+ * and return its RID. If one is not found, use a new RID.
+ */
+static int
+hpet_find_irq_rid(device_t dev, u_long start, u_long end)
+{
+ u_long irq;
+ int error, rid;
+
+ for (rid = 0;; rid++) {
+ error = bus_get_resource(dev, SYS_RES_IRQ, rid, &irq, NULL);
+ if (error != 0 || (start <= irq && irq <= end))
+ return (rid);
+ }
+}
+
/* Discover the HPET via the ACPI table of the same name. */
static void
hpet_identify(driver_t *driver, device_t parent)
@@ -540,6 +557,7 @@ hpet_attach(device_t dev)
dvectors &= ~(1 << t->irq);
}
if (t->irq >= 0) {
+ t->intr_rid = hpet_find_irq_rid(dev, t->irq, t->irq);
if (!(t->intr_res =
bus_alloc_resource(dev, SYS_RES_IRQ, &t->intr_rid,
t->irq, t->irq, 1, RF_ACTIVE))) {
@@ -590,12 +608,12 @@ hpet_attach(device_t dev)
}
bus_write_4(sc->mem_res, HPET_ISR, 0x);
sc->irq = -1;
- sc->intr_rid = -1;
/* If at least one timer needs legacy IRQ - set it up. */
if (sc->useirq) {
j = i = fls(cvectors) - 1;
while (j > 0 && (cvectors & (1 << (j - 1))) != 0)
j--;
+ sc->intr_rid = hpet_find_irq_rid(dev, j, i);
if (!(sc->intr_res = bus_alloc_resource(dev, SYS_RES_IRQ,
&sc->intr_rid, j, i, 1, RF_SHAREABLE | RF_ACTIVE)))
device_printf(dev,"Can't map interrupt.\n");
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r216264 - stable/8/sys/dev/fxp
Author: yongari
Date: Tue Dec 7 19:14:18 2010
New Revision: 216264
URL: http://svn.freebsd.org/changeset/base/216264
Log:
MFC r216111:
If RX lockup workaround is enabled, fxp(4) will periodically reset
the controller to workaround silicon bug of i82557. Each reset will
re-establish link which in turn triggers MII status change
callback. The callback will try to reconfigure controller if the
controller is not i82557 to enable flow-control. This caused
endless link UP/DOWN when the workaround was enabled on non-i82557
controller.
To fix the issue, apply RX lockup workaround only for i82557.
Previously it blindly checked undocumented EEPROM location such
that it sometimes enabled the workaround for other controllers. At
this time, only i82557 is known to have the silicon bug.
This fixes a regression introduced in r215906 which enabled flow
control support for all controllers except i82557.
Reported by:Karl Denninger (karl <> denninger dot net)
Tested by: Karl Denninger (karl <> denninger dot net)
Approved by:re (kensmith)
Modified:
stable/8/sys/dev/fxp/if_fxp.c
Directory Properties:
stable/8/sys/ (props changed)
stable/8/sys/amd64/include/xen/ (props changed)
stable/8/sys/cddl/contrib/opensolaris/ (props changed)
stable/8/sys/contrib/dev/acpica/ (props changed)
stable/8/sys/contrib/pf/ (props changed)
Modified: stable/8/sys/dev/fxp/if_fxp.c
==
--- stable/8/sys/dev/fxp/if_fxp.c Tue Dec 7 18:49:11 2010
(r216263)
+++ stable/8/sys/dev/fxp/if_fxp.c Tue Dec 7 19:14:18 2010
(r216264)
@@ -526,10 +526,12 @@ fxp_attach(device_t dev)
}
/* Receiver lock-up workaround detection. */
- fxp_read_eeprom(sc, &data, 3, 1);
- if ((data & 0x03) != 0x03) {
- sc->flags |= FXP_FLAG_RXBUG;
- device_printf(dev, "Enabling Rx lock-up workaround\n");
+ if (sc->revision < FXP_REV_82558_A4) {
+ fxp_read_eeprom(sc, &data, 3, 1);
+ if ((data & 0x03) != 0x03) {
+ sc->flags |= FXP_FLAG_RXBUG;
+ device_printf(dev, "Enabling Rx lock-up workaround\n");
+ }
}
/*
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r216265 - stable/7/sys/dev/fxp
Author: yongari
Date: Tue Dec 7 19:15:33 2010
New Revision: 216265
URL: http://svn.freebsd.org/changeset/base/216265
Log:
MFC r216111:
If RX lockup workaround is enabled, fxp(4) will periodically reset
the controller to workaround silicon bug of i82557. Each reset will
re-establish link which in turn triggers MII status change
callback. The callback will try to reconfigure controller if the
controller is not i82557 to enable flow-control. This caused
endless link UP/DOWN when the workaround was enabled on non-i82557
controller.
To fix the issue, apply RX lockup workaround only for i82557.
Previously it blindly checked undocumented EEPROM location such
that it sometimes enabled the workaround for other controllers. At
this time, only i82557 is known to have the silicon bug.
This fixes a regression introduced in r215906 which enabled flow
control support for all controllers except i82557.
Reported by:Karl Denninger (karl <> denninger dot net)
Tested by: Karl Denninger (karl <> denninger dot net)
Approved by:re (kensmith)
Modified:
stable/7/sys/dev/fxp/if_fxp.c
Directory Properties:
stable/7/sys/ (props changed)
stable/7/sys/cddl/contrib/opensolaris/ (props changed)
stable/7/sys/contrib/dev/acpica/ (props changed)
stable/7/sys/contrib/pf/ (props changed)
Modified: stable/7/sys/dev/fxp/if_fxp.c
==
--- stable/7/sys/dev/fxp/if_fxp.c Tue Dec 7 19:14:18 2010
(r216264)
+++ stable/7/sys/dev/fxp/if_fxp.c Tue Dec 7 19:15:33 2010
(r216265)
@@ -527,10 +527,12 @@ fxp_attach(device_t dev)
}
/* Receiver lock-up workaround detection. */
- fxp_read_eeprom(sc, &data, 3, 1);
- if ((data & 0x03) != 0x03) {
- sc->flags |= FXP_FLAG_RXBUG;
- device_printf(dev, "Enabling Rx lock-up workaround\n");
+ if (sc->revision < FXP_REV_82558_A4) {
+ fxp_read_eeprom(sc, &data, 3, 1);
+ if ((data & 0x03) != 0x03) {
+ sc->flags |= FXP_FLAG_RXBUG;
+ device_printf(dev, "Enabling Rx lock-up workaround\n");
+ }
}
/*
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r216266 - head/sys/dev/ichwd
Author: emaste Date: Tue Dec 7 19:18:00 2010 New Revision: 216266 URL: http://svn.freebsd.org/changeset/base/216266 Log: Add a comment to clarify that some BIOSes may clear the hw watchdog indicator bit, preventing us from reporting in that case. X-MFC-with: r215868 Modified: head/sys/dev/ichwd/ichwd.c Modified: head/sys/dev/ichwd/ichwd.c == --- head/sys/dev/ichwd/ichwd.c Tue Dec 7 19:15:33 2010(r216265) +++ head/sys/dev/ichwd/ichwd.c Tue Dec 7 19:18:00 2010(r216266) @@ -520,8 +520,9 @@ ichwd_attach(device_t dev) device_get_desc(dev), sc->ich_version); /* -* Determine if we are coming up after a watchdog-induced reset. -* This bit is cleared in ichwd_sts_reset(). +* Determine if we are coming up after a watchdog-induced reset. Some +* BIOSes may clear this bit at bootup, preventing us from reporting +* this case on such systems. We clear this bit in ichwd_sts_reset(). */ if ((ichwd_read_tco_2(sc, TCO2_STS) & TCO_SECOND_TO_STS) != 0) device_printf(dev, ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r216016 - head/sys/sparc64/include
On Tue, Dec 7, 2010 at 5:41 AM, Marius Strobl wrote: > On Mon, Dec 06, 2010 at 02:30:01PM -0800, m...@freebsd.org wrote: >> On Mon, Dec 6, 2010 at 2:07 PM, Marius Strobl >> wrote: >> [lots of snip] >> >> > With that one the kernel now survies memguard_init() but then panics >> > right afterwards when kmeminit() calls kmem_suballoc(): >> > KDB: debugger backends: ddb >> > KDB: current backend: ddb >> > Copyright (c) 1992-2010 The FreeBSD Project. >> > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >> > ? ? ? ?The Regents of the University of California. All rights reserved. >> > FreeBSD is a registered trademark of The FreeBSD Foundation. >> > FreeBSD 9.0-CURRENT #18 r215249:216120M: Mon Dec ?6 13:27:57 CET 2010 >> > ? >> > ?mar...@v20z.zeist.de:/home/marius/co/build/head2/sparc64.sparc64/usr/home/m4 >> > WARNING: WITNESS option enabled, expect reduced performance. >> > panic: kmem_suballoc: bad status return of 3 >> >> [more snip] >> >> Shooting in the dark a little... >> >> The bad status of 3 is presumably KERN_NO_SPACE because we attempted >> to allocate too much space from the kernel_map. What are the actual >> values of vm_kmem_size, kernel_map->min_offset, kernel_map->max_offset >> at panic time? > > vm_kmem_size=5610405888 min_offset=3221225472 max_offset=13958643712 > This is on a US3i machine with 16GB RAM. So kernel_map is from 0xC000_ to 0x3_4000_, or 0x2_8000_ bytes large. Double the vm_kmem_size is 0x2_9CD0_, which is why this is failing. This to me says that, for the moment, you need the VM_MAX_KERNEL_ADDRESS define so that memguard does not take up too much virtual space; at the moment this hardware is somewhat constrained on virtual space. Thanks, matthew > >> How much virtual space does sparc64 support (since >> earlier it was reported it's computed based on hardware capability, >> for this specific machine?) >> > > Currently, the limiting factor is that the kernel TSB is addressed > virtually, which means that the TTEs for kernel TSB itself have to be > put into locked dTLB slots taking up 1 4MB dTLB slot per 1GB. US3 > family CPUs have 16 lockable 4MB dTLB and iTLB slots, which need to > be shared between the TSB and the kernel itself though, i.e. a 9MB > kernel also takes up 3 slots (US1/2 machines have 64 dTLB and iTLB > slots but there these are also used for unlocked TTEs so we don't use > more than 32 for kernel plus TSB on these). VM_MAX_KERNEL_ADDRESS is > limited according to how many slots are available for the TSB, that's > what I was referring to previously. > Actually, US3 and later as well as SPARC64 V and later CPUs have > a feature allowing the TSB to be addressed physically, circumventing > the need to lock the TSB into the TLB, thus allowing the full 64-bit > virtual address space to be used. Implementing that is on my TODO > list but unfortunately that's not exactly straight forward and also > requires some instructions to be patched at runtime so the kernel > still works on US1/2 machines. > > Marius > > ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r216267 - in head: sbin/ifconfig sys/dev/usb sys/net
Author: weongyo
Date: Tue Dec 7 20:23:47 2010
New Revision: 216267
URL: http://svn.freebsd.org/changeset/base/216267
Log:
Introduces IFF_CANTCONFIG interface flag to point that the interface
isn't configurable in a meaningful way. This is for ifconfig(8) or
other tools not to change code whenever IFT_USB-like interfaces are
registered at the interface list.
Reviewed by: brooks
No objections:gavin, jkim
Modified:
head/sbin/ifconfig/ifconfig.c
head/sys/dev/usb/usb_pf.c
head/sys/net/if.h
Modified: head/sbin/ifconfig/ifconfig.c
==
--- head/sbin/ifconfig/ifconfig.c Tue Dec 7 19:18:00 2010
(r216266)
+++ head/sbin/ifconfig/ifconfig.c Tue Dec 7 20:23:47 2010
(r216267)
@@ -295,8 +295,6 @@ main(int argc, char *argv[])
sdl = (const struct sockaddr_dl *) ifa->ifa_addr;
else
sdl = NULL;
- if (sdl != NULL && sdl->sdl_type == IFT_USB)
- continue;
if (cp != NULL && strcmp(cp, ifa->ifa_name) == 0 && !namesonly)
continue;
iflen = strlcpy(name, ifa->ifa_name, sizeof(name));
@@ -307,6 +305,8 @@ main(int argc, char *argv[])
}
cp = ifa->ifa_name;
+ if ((ifa->ifa_flags & IFF_CANTCONFIG) != 0)
+ continue;
if (downonly && (ifa->ifa_flags & IFF_UP) != 0)
continue;
if (uponly && (ifa->ifa_flags & IFF_UP) == 0)
Modified: head/sys/dev/usb/usb_pf.c
==
--- head/sys/dev/usb/usb_pf.c Tue Dec 7 19:18:00 2010(r216266)
+++ head/sys/dev/usb/usb_pf.c Tue Dec 7 20:23:47 2010(r216267)
@@ -64,6 +64,7 @@ usbpf_attach(struct usb_bus *ubus)
ifp = ubus->ifp = if_alloc(IFT_USB);
if_initname(ifp, "usbus", device_get_unit(ubus->bdev));
+ ifp->if_flags = IFF_CANTCONFIG;
if_attach(ifp);
if_up(ifp);
Modified: head/sys/net/if.h
==
--- head/sys/net/if.h Tue Dec 7 19:18:00 2010(r216266)
+++ head/sys/net/if.h Tue Dec 7 20:23:47 2010(r216267)
@@ -145,7 +145,7 @@ struct if_data {
#defineIFF_LINK2 0x4000 /* per link layer defined bit */
#defineIFF_ALTPHYS IFF_LINK2 /* use alternate physical
connection */
#defineIFF_MULTICAST 0x8000 /* (i) supports multicast */
-/* 0x1 */
+#defineIFF_CANTCONFIG 0x1 /* (i) unconfigurable using
ioctl(2) */
#defineIFF_PPROMISC0x2 /* (n) user-requested promisc
mode */
#defineIFF_MONITOR 0x4 /* (n) user-requested monitor
mode */
#defineIFF_STATICARP 0x8 /* (n) static ARP */
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r216268 - head/sys/net
Author: weongyo
Date: Tue Dec 7 20:31:04 2010
New Revision: 216268
URL: http://svn.freebsd.org/changeset/base/216268
Log:
Adds IFF_CANTCONFIG to IFF_CANTCHANGE that it shouldn't happen through
ioctl(2).
Modified:
head/sys/net/if.h
Modified: head/sys/net/if.h
==
--- head/sys/net/if.h Tue Dec 7 20:23:47 2010(r216267)
+++ head/sys/net/if.h Tue Dec 7 20:31:04 2010(r216268)
@@ -165,7 +165,7 @@ struct if_data {
#defineIFF_CANTCHANGE \
(IFF_BROADCAST|IFF_POINTOPOINT|IFF_DRV_RUNNING|IFF_DRV_OACTIVE|\
IFF_SIMPLEX|IFF_MULTICAST|IFF_ALLMULTI|IFF_SMART|IFF_PROMISC|\
- IFF_DYING)
+ IFF_DYING|IFF_CANTCONFIG)
/*
* Values for if_link_state.
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r216230 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
On 12/07/2010 03:51, Bruce Cran wrote: On Tue, Dec 07, 2010 at 01:31:27PM +0200, Alexander Motin wrote: Not necessary. Some places indeed may have some legacy requirements, for example, in theory MBR want partition to be aligned to "track boundary" (but I've seen many pre-formatted SD cards with MBR violating it to align partition to flash sector). Same time for BSD label I see no problem to align partitions any way we want. I also see no problems to make FAT cluster, UFS block/fragment, etc, to match some sizes. From a new installation of Windows 7 and FreeBSD CURRENT: GEOM: ada0: partition 3 does not start on a track boundary. GEOM: ada0: partition 3 does not end on a track boundary. GEOM: ada0: partition 2 does not start on a track boundary. GEOM: ada0: partition 2 does not end on a track bounary. Partition 2 is the reserved partition while 3 is an NTFS partition, both created in the Windows setup application. Since Windows isn't bothering to align partitions do we still need to warn about it? It would be great to remove this warning. I see the same problem with partitions created by Linux, which uses the Windows'y version of CHS. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r216269 - head/sys/geom/part
Author: brucec
Date: Tue Dec 7 20:46:11 2010
New Revision: 216269
URL: http://svn.freebsd.org/changeset/base/216269
Log:
Don't warn if a partition appears not to be aligned on a track boundary.
Modern disks use LBA and create a fake CHS geometry that doesn't have any
relation to the on-disk layout of data.
Modified:
head/sys/geom/part/g_part_mbr.c
Modified: head/sys/geom/part/g_part_mbr.c
==
--- head/sys/geom/part/g_part_mbr.c Tue Dec 7 20:31:04 2010
(r216268)
+++ head/sys/geom/part/g_part_mbr.c Tue Dec 7 20:46:11 2010
(r216269)
@@ -449,12 +449,6 @@ g_part_mbr_read(struct g_part_table *bas
basetable->gpt_heads = heads;
}
}
- if ((ent.dp_start % basetable->gpt_sectors) != 0)
- printf("GEOM: %s: partition %d does not start on a "
- "track boundary.\n", pp->name, index + 1);
- if ((ent.dp_size % basetable->gpt_sectors) != 0)
- printf("GEOM: %s: partition %d does not end on a "
- "track boundary.\n", pp->name, index + 1);
entry = (struct g_part_mbr_entry *)g_part_new_entry(basetable,
index + 1, ent.dp_start, ent.dp_start + ent.dp_size - 1);
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r216269 - head/sys/geom/part
on 07/12/2010 22:46 Bruce Cran said the following: > Don't warn if a partition appears not to be aligned on a track boundary. > Modern disks use LBA and create a fake CHS geometry that doesn't have any > relation to the on-disk layout of data. You repeated that statement, so I am picking on you :-) Can someone show me how/where exactly modern drives fakes CHS geometry? Let me specifically ask that question about modern (S)ATA drives directly connected to a system (controller). My impression is at least since ATA-7 there is no mentioning of anything CHS-related in the specification. The fact that we keep reading and interpreting some historically defined bytes that are now marked as unused/reserved doesn't mean that those bytes actually mean anything. -- Andriy Gapon ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r216271 - stable/8/sys/cddl/compat/opensolaris/kern
Author: trasz
Date: Tue Dec 7 22:00:48 2010
New Revision: 216271
URL: http://svn.freebsd.org/changeset/base/216271
Log:
MFC r216084:
Don't panic when we read an empty ACL from ZFS. Apparently this may happen
with filesystems created under MacOS X ZFS port. This is kind of filesystem
corruption (we don't allow for setting empty ACLs), so make acl_get_file(3)
and related syscalls fail with EINVAL in that case. In theory, we could
return empty ACL to userland, but I'm afraid this would break some code.
Approved by: re (kib)
Modified:
stable/8/sys/cddl/compat/opensolaris/kern/opensolaris_acl.c
Directory Properties:
stable/8/sys/ (props changed)
stable/8/sys/amd64/include/xen/ (props changed)
stable/8/sys/cddl/contrib/opensolaris/ (props changed)
stable/8/sys/contrib/dev/acpica/ (props changed)
stable/8/sys/contrib/pf/ (props changed)
Modified: stable/8/sys/cddl/compat/opensolaris/kern/opensolaris_acl.c
==
--- stable/8/sys/cddl/compat/opensolaris/kern/opensolaris_acl.c Tue Dec 7
21:39:36 2010(r216270)
+++ stable/8/sys/cddl/compat/opensolaris/kern/opensolaris_acl.c Tue Dec 7
22:00:48 2010(r216271)
@@ -105,7 +105,10 @@ acl_from_aces(struct acl *aclp, const ac
struct acl_entry *entry;
const ace_t *ace;
- KASSERT(nentries >= 1, ("empty ZFS ACL"));
+ if (nentries < 1) {
+ printf("acl_from_aces: empty ZFS ACL; returning EINVAL.\n");
+ return (EINVAL);
+ }
if (nentries > ACL_MAX_ENTRIES) {
/*
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r216269 - head/sys/geom/part
On 12/7/2010 1:54 PM, Andriy Gapon wrote: on 07/12/2010 22:46 Bruce Cran said the following: Don't warn if a partition appears not to be aligned on a track boundary. Modern disks use LBA and create a fake CHS geometry that doesn't have any relation to the on-disk layout of data. You repeated that statement, so I am picking on you :-) Can someone show me how/where exactly modern drives fakes CHS geometry? cf cam_calc_geometry ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r216272 - in head/sys: amd64/amd64 i386/i386
Author: jkim
Date: Tue Dec 7 22:12:02 2010
New Revision: 216272
URL: http://svn.freebsd.org/changeset/base/216272
Log:
Probe P-state invariant TSC from rightful place.
Modified:
head/sys/amd64/amd64/identcpu.c
head/sys/amd64/amd64/tsc.c
head/sys/i386/i386/identcpu.c
head/sys/i386/i386/tsc.c
Modified: head/sys/amd64/amd64/identcpu.c
==
--- head/sys/amd64/amd64/identcpu.c Tue Dec 7 22:00:48 2010
(r216271)
+++ head/sys/amd64/amd64/identcpu.c Tue Dec 7 22:12:02 2010
(r216272)
@@ -392,28 +392,6 @@ printcpuinfo(void)
* If this CPU supports P-state invariant TSC then
* mention the capability.
*/
- switch (cpu_vendor_id) {
- case CPU_VENDOR_AMD:
- if ((amd_pminfo & AMDPM_TSC_INVARIANT) ||
- CPUID_TO_FAMILY(cpu_id) >= 0x10 ||
- cpu_id == 0x60fb2)
- tsc_is_invariant = 1;
- break;
- case CPU_VENDOR_INTEL:
- if ((amd_pminfo & AMDPM_TSC_INVARIANT) ||
- (CPUID_TO_FAMILY(cpu_id) == 0x6 &&
- CPUID_TO_MODEL(cpu_id) >= 0xe) ||
- (CPUID_TO_FAMILY(cpu_id) == 0xf &&
- CPUID_TO_MODEL(cpu_id) >= 0x3))
- tsc_is_invariant = 1;
- break;
- case CPU_VENDOR_CENTAUR:
- if (CPUID_TO_FAMILY(cpu_id) == 0x6 &&
- CPUID_TO_MODEL(cpu_id) >= 0xf &&
- (rdmsr(0x1203) & 0x1ULL) == 0)
- tsc_is_invariant = 1;
- break;
- }
if (tsc_is_invariant)
printf("\n TSC: P-state invariant");
Modified: head/sys/amd64/amd64/tsc.c
==
--- head/sys/amd64/amd64/tsc.c Tue Dec 7 22:00:48 2010(r216271)
+++ head/sys/amd64/amd64/tsc.c Tue Dec 7 22:12:02 2010(r216272)
@@ -41,6 +41,7 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
+#include
#include
#include
@@ -94,6 +95,28 @@ init_TSC(void)
if (bootverbose)
printf("TSC clock: %lu Hz\n", tsc_freq);
+ switch (cpu_vendor_id) {
+ case CPU_VENDOR_AMD:
+ if ((amd_pminfo & AMDPM_TSC_INVARIANT) ||
+ CPUID_TO_FAMILY(cpu_id) >= 0x10 || cpu_id == 0x60fb2)
+ tsc_is_invariant = 1;
+ break;
+ case CPU_VENDOR_INTEL:
+ if ((amd_pminfo & AMDPM_TSC_INVARIANT) ||
+ (CPUID_TO_FAMILY(cpu_id) == 0x6 &&
+ CPUID_TO_MODEL(cpu_id) >= 0xe) ||
+ (CPUID_TO_FAMILY(cpu_id) == 0xf &&
+ CPUID_TO_MODEL(cpu_id) >= 0x3))
+ tsc_is_invariant = 1;
+ break;
+ case CPU_VENDOR_CENTAUR:
+ if (CPUID_TO_FAMILY(cpu_id) == 0x6 &&
+ CPUID_TO_MODEL(cpu_id) >= 0xf &&
+ (rdmsr(0x1203) & 0x1ULL) == 0)
+ tsc_is_invariant = 1;
+ break;
+ }
+
/*
* Inform CPU accounting about our boot-time clock rate. Once the
* system is finished booting, we will get the real max clock rate
Modified: head/sys/i386/i386/identcpu.c
==
--- head/sys/i386/i386/identcpu.c Tue Dec 7 22:00:48 2010
(r216271)
+++ head/sys/i386/i386/identcpu.c Tue Dec 7 22:12:02 2010
(r216272)
@@ -856,28 +856,6 @@ printcpuinfo(void)
* If this CPU supports P-state invariant TSC then
* mention the capability.
*/
- switch (cpu_vendor_id) {
- case CPU_VENDOR_AMD:
- if ((amd_pminfo & AMDPM_TSC_INVARIANT) ||
- CPUID_TO_FAMILY(cpu_id) >= 0x10 ||
- cpu_id == 0x60fb2)
- tsc_is_invariant = 1;
- break;
- case CPU_VENDOR_INTEL:
- if ((amd_pminfo & AMDPM_TSC_INVARIANT) ||
- (CPUID_TO_FAMILY(cpu_id) == 0x6 &&
- CPUID_TO_MODEL(cpu_id) >= 0xe) ||
- (CPUID_TO_FAMILY(cpu_id) == 0xf &&
-
Re: svn commit: r216269 - head/sys/geom/part
on 08/12/2010 00:05 Matthew Jacob said the following: > > > On 12/7/2010 1:54 PM, Andriy Gapon wrote: >> on 07/12/2010 22:46 Bruce Cran said the following: >>>Don't warn if a partition appears not to be aligned on a track boundary. >>>Modern disks use LBA and create a fake CHS geometry that doesn't have any >>>relation to the on-disk layout of data. >> You repeated that statement, so I am picking on you :-) >> Can someone show me how/where exactly modern drives fakes CHS geometry? >> > > cf cam_calc_geometry But that's not drive firmware code :-) It's us faking those parameters for ourselves for some unknown reason. Stupid us :-) But not the drives / manufacturers. -- Andriy Gapon ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r216272 - in head/sys: amd64/amd64 i386/i386
On Tuesday, December 07, 2010 5:12:02 pm Jung-uk Kim wrote:
> Author: jkim
> Date: Tue Dec 7 22:12:02 2010
> New Revision: 216272
> URL: http://svn.freebsd.org/changeset/base/216272
>
> Log:
> Probe P-state invariant TSC from rightful place.
>
> Modified:
> head/sys/amd64/amd64/identcpu.c
> head/sys/amd64/amd64/tsc.c
> head/sys/i386/i386/identcpu.c
> head/sys/i386/i386/tsc.c
>
> Modified: head/sys/amd64/amd64/identcpu.c
>
==
> --- head/sys/amd64/amd64/identcpu.c Tue Dec 7 22:00:48 2010
> (r216271)
> +++ head/sys/amd64/amd64/identcpu.c Tue Dec 7 22:12:02 2010
> (r216272)
> @@ -392,28 +392,6 @@ printcpuinfo(void)
>* If this CPU supports P-state invariant TSC then
>* mention the capability.
>*/
> - switch (cpu_vendor_id) {
> - case CPU_VENDOR_AMD:
> - if ((amd_pminfo & AMDPM_TSC_INVARIANT) ||
> - CPUID_TO_FAMILY(cpu_id) >= 0x10 ||
> - cpu_id == 0x60fb2)
> - tsc_is_invariant = 1;
> - break;
> - case CPU_VENDOR_INTEL:
> - if ((amd_pminfo & AMDPM_TSC_INVARIANT) ||
> - (CPUID_TO_FAMILY(cpu_id) == 0x6 &&
> - CPUID_TO_MODEL(cpu_id) >= 0xe) ||
> - (CPUID_TO_FAMILY(cpu_id) == 0xf &&
> - CPUID_TO_MODEL(cpu_id) >= 0x3))
> - tsc_is_invariant = 1;
> - break;
> - case CPU_VENDOR_CENTAUR:
> - if (CPUID_TO_FAMILY(cpu_id) == 0x6 &&
> - CPUID_TO_MODEL(cpu_id) >= 0xf &&
> - (rdmsr(0x1203) & 0x1ULL) == 0)
> - tsc_is_invariant = 1;
> - break;
> - }
> if (tsc_is_invariant)
> printf("\n TSC: P-state invariant");
Doesn't that break this printf?
--
John Baldwin
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r216274 - in head/sys: amd64/amd64 i386/i386
Author: jkim
Date: Tue Dec 7 22:23:26 2010
New Revision: 216274
URL: http://svn.freebsd.org/changeset/base/216274
Log:
Now the P-state invariant TSC is probed early enough, do not register event
handlers for CPU freqency changes when it is found P-state invariant.
Adjust a comment about non-existent tsc_freq_max() while I am here.
Modified:
head/sys/amd64/amd64/tsc.c
head/sys/i386/i386/tsc.c
Modified: head/sys/amd64/amd64/tsc.c
==
--- head/sys/amd64/amd64/tsc.c Tue Dec 7 22:16:37 2010(r216273)
+++ head/sys/amd64/amd64/tsc.c Tue Dec 7 22:23:26 2010(r216274)
@@ -118,13 +118,15 @@ init_TSC(void)
}
/*
-* Inform CPU accounting about our boot-time clock rate. Once the
-* system is finished booting, we will get the real max clock rate
-* via tsc_freq_max(). This also will be updated if someone loads
-* a cpufreq driver after boot that discovers a new max frequency.
+* Inform CPU accounting about our boot-time clock rate. This will
+* be updated if someone loads a cpufreq driver after boot that
+* discovers a new max frequency.
*/
set_cputicker(rdtsc, tsc_freq, 1);
+ if (tsc_is_invariant)
+ return;
+
/* Register to find out about changes in CPU frequency. */
tsc_pre_tag = EVENTHANDLER_REGISTER(cpufreq_pre_change,
tsc_freq_changing, NULL, EVENTHANDLER_PRI_FIRST);
@@ -169,9 +171,6 @@ tsc_levels_changed(void *arg, int unit)
int count, error;
uint64_t max_freq;
- if (tsc_is_invariant)
- return;
-
/* Only use values from the first CPU, assuming all are equal. */
if (unit != 0)
return;
@@ -205,8 +204,7 @@ static void
tsc_freq_changing(void *arg, const struct cf_level *level, int *status)
{
- if (*status != 0 || timecounter != &tsc_timecounter ||
- tsc_is_invariant)
+ if (*status != 0 || timecounter != &tsc_timecounter)
return;
printf("timecounter TSC must not be in use when "
@@ -222,7 +220,7 @@ tsc_freq_changed(void *arg, const struct
* If there was an error during the transition or
* TSC is P-state invariant, don't do anything.
*/
- if (status != 0 || tsc_is_invariant)
+ if (status != 0)
return;
/* Total setting for this level gives the new frequency in MHz. */
Modified: head/sys/i386/i386/tsc.c
==
--- head/sys/i386/i386/tsc.cTue Dec 7 22:16:37 2010(r216273)
+++ head/sys/i386/i386/tsc.cTue Dec 7 22:23:26 2010(r216274)
@@ -127,13 +127,15 @@ init_TSC(void)
}
/*
-* Inform CPU accounting about our boot-time clock rate. Once the
-* system is finished booting, we will get the real max clock rate
-* via tsc_freq_max(). This also will be updated if someone loads
-* a cpufreq driver after boot that discovers a new max frequency.
+* Inform CPU accounting about our boot-time clock rate. This will
+* be updated if someone loads a cpufreq driver after boot that
+* discovers a new max frequency.
*/
set_cputicker(rdtsc, tsc_freq, 1);
+ if (tsc_is_invariant)
+ return;
+
/* Register to find out about changes in CPU frequency. */
tsc_pre_tag = EVENTHANDLER_REGISTER(cpufreq_pre_change,
tsc_freq_changing, NULL, EVENTHANDLER_PRI_FIRST);
@@ -197,9 +199,6 @@ tsc_levels_changed(void *arg, int unit)
int count, error;
uint64_t max_freq;
- if (tsc_is_invariant)
- return;
-
/* Only use values from the first CPU, assuming all are equal. */
if (unit != 0)
return;
@@ -233,8 +232,7 @@ static void
tsc_freq_changing(void *arg, const struct cf_level *level, int *status)
{
- if (*status != 0 || timecounter != &tsc_timecounter ||
- tsc_is_invariant)
+ if (*status != 0 || timecounter != &tsc_timecounter)
return;
printf("timecounter TSC must not be in use when "
@@ -250,7 +248,7 @@ tsc_freq_changed(void *arg, const struct
* If there was an error during the transition or
* TSC is P-state invariant, don't do anything.
*/
- if (status != 0 || tsc_is_invariant)
+ if (status != 0)
return;
/* Total setting for this level gives the new frequency in MHz. */
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r216272 - in head/sys: amd64/amd64 i386/i386
On Tuesday, December 07, 2010 5:22:29 pm John Baldwin wrote:
> On Tuesday, December 07, 2010 5:12:02 pm Jung-uk Kim wrote:
> > Author: jkim
> > Date: Tue Dec 7 22:12:02 2010
> > New Revision: 216272
> > URL: http://svn.freebsd.org/changeset/base/216272
> >
> > Log:
> > Probe P-state invariant TSC from rightful place.
> >
> > if (tsc_is_invariant)
> > printf("\n TSC: P-state invariant");
>
> Doesn't that break this printf?
Nevermind. :-P
--
John Baldwin
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r216230 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
On 7 December 2010 12:31, Pawel Jakub Dawidek wrote: > On Tue, Dec 07, 2010 at 12:25:28PM +0100, Ivan Voras wrote: >> On 7 December 2010 11:21, Pawel Jakub Dawidek wrote: >> >> > PS. Do you know your change breaks all current ZFS installation if >> > stripesize is defined for a provider? >> > >> > # zpool create tank ada0 >> > (upgrade FreeBSD so that ada0 now reports 4kB stripesize) >> > # zpool import tank >> > cannot import 'tank': invalid vdev configuration >> >> Actually I did test the patch and, similar to the Solaris people, >> found that ZFS records ashift in metadata and uses the recorded one >> instead of hardcoded / detected one. What you found here really >> shouldn't happen. Are you sure only stripesize was increased in your >> case, not sectorsize? > > if (pp->stripesize > pp->sectorsize) > *ashift = highbit(MIN(pp->stripesize, SPA_MAXBLOCKSIZE)) - 1; > else > *ashift = highbit(MAX(pp->sectorsize, SPA_MINBLOCKSIZE)) - 1; > > If stripesize will start to be 4096, the ashift will change. > > Not sure what you test was, but it only works the other way around - > create pool with 4kB ashift and import it when ashift is 512 bytes. My test was flawed, it made me conclude that ashift from metadata would be used in this case (this case is actually one of the more trivial ones - vdev created with ashift=9 used on device which is capable of ashift=9 but advertises ashift=12). In case it would be useful in the future, this is blocked in vdev_open(): http://fxr.watson.org/fxr/source/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c#L1075 I think that to solve this edge case properly, ZFS would have to know that both ashift values are "valid" for the device, i.e. basically it would at this point need to somehow know about our sectorsize and stripesize, not just ashift. OpenSolaris lists mention that pools can be created from devices with different ashift values, which is good news. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r216275 - in head/sys: amd64/amd64 i386/i386
Author: jkim
Date: Tue Dec 7 22:34:51 2010
New Revision: 216275
URL: http://svn.freebsd.org/changeset/base/216275
Log:
Do not register a event handler for CPU freqency changes when it is found
P-state invariant. This is continuation of r216274.
Modified:
head/sys/amd64/amd64/identcpu.c
head/sys/i386/i386/identcpu.c
Modified: head/sys/amd64/amd64/identcpu.c
==
--- head/sys/amd64/amd64/identcpu.c Tue Dec 7 22:23:26 2010
(r216274)
+++ head/sys/amd64/amd64/identcpu.c Tue Dec 7 22:34:51 2010
(r216275)
@@ -109,6 +109,8 @@ static int hw_clockrate;
SYSCTL_INT(_hw, OID_AUTO, clockrate, CTLFLAG_RD,
&hw_clockrate, 0, "CPU instruction clock rate");
+static eventhandler_tag tsc_post_tag;
+
static char cpu_brand[48];
static struct {
@@ -433,21 +435,31 @@ panicifcpuunsupported(void)
/* Update TSC freq with the value indicated by the caller. */
static void
-tsc_freq_changed(void *arg, const struct cf_level *level, int status)
+tsc_freq_changed(void *arg __unused, const struct cf_level *level, int status)
{
/*
* If there was an error during the transition or
* TSC is P-state invariant, don't do anything.
*/
- if (status != 0 || tsc_is_invariant)
+ if (status != 0)
return;
/* Total setting for this level gives the new frequency in MHz. */
hw_clockrate = level->total_set.freq;
}
-EVENTHANDLER_DEFINE(cpufreq_post_change, tsc_freq_changed, NULL,
-EVENTHANDLER_PRI_ANY);
+static void
+hook_tsc_freq(void *arg __unused)
+{
+
+ if (tsc_is_invariant)
+ return;
+
+ tsc_post_tag = EVENTHANDLER_REGISTER(cpufreq_post_change,
+ tsc_freq_changed, NULL, EVENTHANDLER_PRI_ANY);
+}
+
+SYSINIT(hook_tsc_freq, SI_SUB_CONFIGURE, SI_ORDER_ANY, hook_tsc_freq, NULL);
/*
* Final stage of CPU identification.
Modified: head/sys/i386/i386/identcpu.c
==
--- head/sys/i386/i386/identcpu.c Tue Dec 7 22:23:26 2010
(r216274)
+++ head/sys/i386/i386/identcpu.c Tue Dec 7 22:34:51 2010
(r216275)
@@ -100,6 +100,8 @@ static int hw_clockrate;
SYSCTL_INT(_hw, OID_AUTO, clockrate, CTLFLAG_RD,
&hw_clockrate, 0, "CPU instruction clock rate");
+static eventhandler_tag tsc_post_tag;
+
static char cpu_brand[48];
#defineMAX_BRAND_INDEX 8
@@ -1049,21 +1051,31 @@ identifycyrix(void)
/* Update TSC freq with the value indicated by the caller. */
static void
-tsc_freq_changed(void *arg, const struct cf_level *level, int status)
+tsc_freq_changed(void *arg __unused, const struct cf_level *level, int status)
{
/*
* If there was an error during the transition or
* TSC is P-state invariant, don't do anything.
*/
- if (status != 0 || tsc_is_invariant)
+ if (status != 0)
return;
/* Total setting for this level gives the new frequency in MHz. */
hw_clockrate = level->total_set.freq;
}
-EVENTHANDLER_DEFINE(cpufreq_post_change, tsc_freq_changed, NULL,
-EVENTHANDLER_PRI_ANY);
+static void
+hook_tsc_freq(void *arg __unused)
+{
+
+ if (tsc_is_invariant)
+ return;
+
+ tsc_post_tag = EVENTHANDLER_REGISTER(cpufreq_post_change,
+ tsc_freq_changed, NULL, EVENTHANDLER_PRI_ANY);
+}
+
+SYSINIT(hook_tsc_freq, SI_SUB_CONFIGURE, SI_ORDER_ANY, hook_tsc_freq, NULL);
/*
* Final stage of CPU identification. -- Should I check TI?
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r216276 - in head/sys: amd64/amd64 i386/i386
Author: jkim
Date: Tue Dec 7 22:43:25 2010
New Revision: 216276
URL: http://svn.freebsd.org/changeset/base/216276
Log:
Remove stale comments about P-state invariant TSC and fix style(9) nits.
Modified:
head/sys/amd64/amd64/identcpu.c
head/sys/amd64/amd64/tsc.c
head/sys/i386/i386/identcpu.c
head/sys/i386/i386/tsc.c
Modified: head/sys/amd64/amd64/identcpu.c
==
--- head/sys/amd64/amd64/identcpu.c Tue Dec 7 22:34:51 2010
(r216275)
+++ head/sys/amd64/amd64/identcpu.c Tue Dec 7 22:43:25 2010
(r216276)
@@ -437,10 +437,8 @@ panicifcpuunsupported(void)
static void
tsc_freq_changed(void *arg __unused, const struct cf_level *level, int status)
{
- /*
-* If there was an error during the transition or
-* TSC is P-state invariant, don't do anything.
-*/
+
+ /* If there was an error during the transition, don't do anything. */
if (status != 0)
return;
Modified: head/sys/amd64/amd64/tsc.c
==
--- head/sys/amd64/amd64/tsc.c Tue Dec 7 22:34:51 2010(r216275)
+++ head/sys/amd64/amd64/tsc.c Tue Dec 7 22:43:25 2010(r216276)
@@ -216,10 +216,8 @@ tsc_freq_changing(void *arg, const struc
static void
tsc_freq_changed(void *arg, const struct cf_level *level, int status)
{
- /*
-* If there was an error during the transition or
-* TSC is P-state invariant, don't do anything.
-*/
+
+ /* If there was an error during the transition, don't do anything. */
if (status != 0)
return;
Modified: head/sys/i386/i386/identcpu.c
==
--- head/sys/i386/i386/identcpu.c Tue Dec 7 22:34:51 2010
(r216275)
+++ head/sys/i386/i386/identcpu.c Tue Dec 7 22:43:25 2010
(r216276)
@@ -1053,10 +1053,8 @@ identifycyrix(void)
static void
tsc_freq_changed(void *arg __unused, const struct cf_level *level, int status)
{
- /*
-* If there was an error during the transition or
-* TSC is P-state invariant, don't do anything.
-*/
+
+ /* If there was an error during the transition, don't do anything. */
if (status != 0)
return;
Modified: head/sys/i386/i386/tsc.c
==
--- head/sys/i386/i386/tsc.cTue Dec 7 22:34:51 2010(r216275)
+++ head/sys/i386/i386/tsc.cTue Dec 7 22:43:25 2010(r216276)
@@ -244,10 +244,8 @@ tsc_freq_changing(void *arg, const struc
static void
tsc_freq_changed(void *arg, const struct cf_level *level, int status)
{
- /*
-* If there was an error during the transition or
-* TSC is P-state invariant, don't do anything.
-*/
+
+ /* If there was an error during the transition, don't do anything. */
if (status != 0)
return;
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r216277 - head/sys/netinet6
Author: bz
Date: Tue Dec 7 22:43:29 2010
New Revision: 216277
URL: http://svn.freebsd.org/changeset/base/216277
Log:
Loosen the locking in nd6-free() again after r216022 to avoid
a LOR and a recursed lock.
Reported by: delphij
Tested by:delphij
PR: kern/148857
MFC After:3 days
Modified:
head/sys/netinet6/nd6.c
Modified: head/sys/netinet6/nd6.c
==
--- head/sys/netinet6/nd6.c Tue Dec 7 22:43:25 2010(r216276)
+++ head/sys/netinet6/nd6.c Tue Dec 7 22:43:29 2010(r216277)
@@ -1053,15 +1053,6 @@ nd6_free(struct llentry *ln, int gc)
return (next);
}
- if (ln->ln_router || dr) {
- /*
-* rt6_flush must be called whether or not the neighbor
-* is in the Default Router List.
-* See a corresponding comment in nd6_na_input().
-*/
- rt6_flush(&L3_ADDR_SIN6(ln)->sin6_addr, ifp);
- }
-
if (dr) {
/*
* Unreachablity of a router might affect the default
@@ -1077,8 +1068,28 @@ nd6_free(struct llentry *ln, int gc)
* or the entry itself will be deleted.
*/
ln->ln_state = ND6_LLINFO_INCOMPLETE;
+ }
+
+ if (ln->ln_router || dr) {
/*
+* We need to unlock to avoid a LOR with rt6_flush()
with the
+* rnh and for the calls to pfxlist_onlink_check() and
+* defrouter_select() in the block further down for
calls
+* into nd6_lookup(). We still hold a ref.
+*/
+ LLE_WUNLOCK(ln);
+
+ /*
+* rt6_flush must be called whether or not the neighbor
+* is in the Default Router List.
+* See a corresponding comment in nd6_na_input().
+*/
+ rt6_flush(&L3_ADDR_SIN6(ln)->sin6_addr, ifp);
+ }
+
+ if (dr) {
+ /*
* Since defrouter_select() does not affect the
* on-link determination and MIP6 needs the check
* before the default router selection, we perform
@@ -1087,13 +1098,13 @@ nd6_free(struct llentry *ln, int gc)
pfxlist_onlink_check();
/*
-* Refresh default router list. Have to unlock as
-* it calls into nd6_lookup(), still holding a ref.
+* Refresh default router list.
*/
- LLE_WUNLOCK(ln);
defrouter_select();
- LLE_WLOCK(ln);
}
+
+ if (ln->ln_router || dr)
+ LLE_WLOCK(ln);
}
/*
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r216269 - head/sys/geom/part
On Tue, 07 Dec 2010 23:54:17 +0200 Andriy Gapon wrote: > You repeated that statement, so I am picking on you :-) > Can someone show me how/where exactly modern drives fakes CHS > geometry? Let me specifically ask that question about modern (S)ATA > drives directly connected to a system (controller). > My impression is at least since ATA-7 there is no mentioning of > anything CHS-related in the specification. The fact that we keep > reading and interpreting some historically defined bytes that are now > marked as unused/reserved doesn't mean that those bytes actually mean > anything. You're right: I last looked at the IDENTIFY data about 7 years ago when those fields were defined; now they're marked as "obsolete". I guess the fields are still defined to keep old tools happy. Both atacontrol and camcontrol are still reading the IDENTIFY data and outputting the CHS fields even on ATA-8 drives, which I guess they shouldn't be. -- Bruce ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r216269 - head/sys/geom/part
On Tue, 7 Dec 2010 23:06:24 + Bruce Cran wrote: > I guess the fields are still defined to keep old tools happy. I mean that values are still returned by the drive firmware, while they could be left zero according to the spec. For example a new 1TB ATA-8 drive returns a geometry of 16H/63S/16383C in those fields. -- Bruce Cran ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r216269 - head/sys/geom/part
Geometry is still important. Trying booting a USB flash drive on all BIOS' with a 63/255 geometry instead of a 64/32 geometry. On 12/7/2010 2:14 PM, Andriy Gapon wrote: on 08/12/2010 00:05 Matthew Jacob said the following: On 12/7/2010 1:54 PM, Andriy Gapon wrote: on 07/12/2010 22:46 Bruce Cran said the following: Don't warn if a partition appears not to be aligned on a track boundary. Modern disks use LBA and create a fake CHS geometry that doesn't have any relation to the on-disk layout of data. You repeated that statement, so I am picking on you :-) Can someone show me how/where exactly modern drives fakes CHS geometry? cf cam_calc_geometry But that's not drive firmware code :-) It's us faking those parameters for ourselves for some unknown reason. Stupid us :-) But not the drives / manufacturers. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r216279 - in head/sys/i386: i386 include
Author: jkim
Date: Tue Dec 7 23:19:49 2010
New Revision: 216279
URL: http://svn.freebsd.org/changeset/base/216279
Log:
Use int for 'tsc_present' instead of u_int. It is just a boolean.
Modified:
head/sys/i386/i386/tsc.c
head/sys/i386/include/cpu.h
Modified: head/sys/i386/i386/tsc.c
==
--- head/sys/i386/i386/tsc.cTue Dec 7 23:14:00 2010(r216278)
+++ head/sys/i386/i386/tsc.cTue Dec 7 23:19:49 2010(r216279)
@@ -50,7 +50,7 @@ __FBSDID("$FreeBSD$");
uint64_t tsc_freq;
inttsc_is_broken;
inttsc_is_invariant;
-u_int tsc_present;
+inttsc_present;
static eventhandler_tag tsc_levels_tag, tsc_pre_tag, tsc_post_tag;
SYSCTL_INT(_kern_timecounter, OID_AUTO, invariant_tsc, CTLFLAG_RDTUN,
Modified: head/sys/i386/include/cpu.h
==
--- head/sys/i386/include/cpu.h Tue Dec 7 23:14:00 2010(r216278)
+++ head/sys/i386/include/cpu.h Tue Dec 7 23:19:49 2010(r216279)
@@ -56,7 +56,7 @@
#ifdef _KERNEL
extern charbtext[];
extern charetext[];
-extern u_int tsc_present;
+extern int tsc_present;
void cpu_halt(void);
void cpu_reset(void);
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r216280 - head/sys/xen/evtchn
Author: cperciva
Date: Tue Dec 7 23:33:20 2010
New Revision: 216280
URL: http://svn.freebsd.org/changeset/base/216280
Log:
Postpone the unmasking of event channels (aka. interrupts) until after
the interrupt handlers have been registered. NULL isn't a very good
interrupt handler.
Modified:
head/sys/xen/evtchn/evtchn.c
Modified: head/sys/xen/evtchn/evtchn.c
==
--- head/sys/xen/evtchn/evtchn.cTue Dec 7 23:19:49 2010
(r216279)
+++ head/sys/xen/evtchn/evtchn.cTue Dec 7 23:33:20 2010
(r216280)
@@ -256,7 +256,7 @@ find_unbound_irq(void)
}
static int
-bind_caller_port_to_irq(unsigned int caller_port)
+bind_caller_port_to_irq(unsigned int caller_port, int * port)
{
int irq;
@@ -271,7 +271,7 @@ bind_caller_port_to_irq(unsigned int cal
}
irq_bindcount[irq]++;
- unmask_evtchn(caller_port);
+ *port = caller_port;
out:
mtx_unlock_spin(&irq_mapping_update_lock);
@@ -279,7 +279,7 @@ bind_caller_port_to_irq(unsigned int cal
}
static int
-bind_local_port_to_irq(unsigned int local_port)
+bind_local_port_to_irq(unsigned int local_port, int * port)
{
int irq;
@@ -298,7 +298,7 @@ bind_local_port_to_irq(unsigned int loca
evtchn_to_irq[local_port] = irq;
irq_info[irq] = mk_irq_info(IRQT_LOCAL_PORT, 0, local_port);
irq_bindcount[irq]++;
- unmask_evtchn(local_port);
+ *port = local_port;
out:
mtx_unlock_spin(&irq_mapping_update_lock);
@@ -306,7 +306,7 @@ bind_local_port_to_irq(unsigned int loca
}
static int
-bind_listening_port_to_irq(unsigned int remote_domain)
+bind_listening_port_to_irq(unsigned int remote_domain, int * port)
{
struct evtchn_alloc_unbound alloc_unbound;
int err;
@@ -317,12 +317,12 @@ bind_listening_port_to_irq(unsigned int
err = HYPERVISOR_event_channel_op(EVTCHNOP_alloc_unbound,
&alloc_unbound);
-return err ? : bind_local_port_to_irq(alloc_unbound.port);
+return err ? : bind_local_port_to_irq(alloc_unbound.port, port);
}
static int
bind_interdomain_evtchn_to_irq(unsigned int remote_domain,
-unsigned int remote_port)
+unsigned int remote_port, int * port)
{
struct evtchn_bind_interdomain bind_interdomain;
int err;
@@ -333,11 +333,11 @@ bind_interdomain_evtchn_to_irq(unsigned
err = HYPERVISOR_event_channel_op(EVTCHNOP_bind_interdomain,
&bind_interdomain);
-return err ? : bind_local_port_to_irq(bind_interdomain.local_port);
+return err ? : bind_local_port_to_irq(bind_interdomain.local_port,
port);
}
static int
-bind_virq_to_irq(unsigned int virq, unsigned int cpu)
+bind_virq_to_irq(unsigned int virq, unsigned int cpu, int * port)
{
struct evtchn_bind_virq bind_virq;
int evtchn = 0, irq;
@@ -363,7 +363,7 @@ bind_virq_to_irq(unsigned int virq, unsi
}
irq_bindcount[irq]++;
- unmask_evtchn(evtchn);
+ *port = evtchn;
out:
mtx_unlock_spin(&irq_mapping_update_lock);
@@ -371,10 +371,8 @@ out:
}
-extern int bind_ipi_to_irq(unsigned int ipi, unsigned int cpu);
-
-int
-bind_ipi_to_irq(unsigned int ipi, unsigned int cpu)
+static int
+bind_ipi_to_irq(unsigned int ipi, unsigned int cpu, int * port)
{
struct evtchn_bind_ipi bind_ipi;
int irq;
@@ -398,7 +396,7 @@ bind_ipi_to_irq(unsigned int ipi, unsign
bind_evtchn_to_cpu(evtchn, cpu);
}
irq_bindcount[irq]++;
- unmask_evtchn(evtchn);
+ *port = evtchn;
out:
mtx_unlock_spin(&irq_mapping_update_lock);
@@ -449,9 +447,10 @@ bind_caller_port_to_irqhandler(unsigned
unsigned long irqflags, unsigned int *irqp)
{
unsigned int irq;
+ int port = -1;
int error;
- irq = bind_caller_port_to_irq(caller_port);
+ irq = bind_caller_port_to_irq(caller_port, &port);
intr_register_source(&xp->xp_pins[irq].xp_intsrc);
error = intr_add_handler(devname, irq, NULL, handler, arg, irqflags,
&xp->xp_pins[irq].xp_cookie);
@@ -460,6 +459,8 @@ bind_caller_port_to_irqhandler(unsigned
unbind_from_irq(irq);
return (error);
}
+ if (port != -1)
+ unmask_evtchn(port);
if (irqp)
*irqp = irq;
@@ -473,9 +474,10 @@ bind_listening_port_to_irqhandler(unsign
unsigned long irqflags, unsigned int *irqp)
{
unsigned int irq;
+ int port = -1;
int error;
- irq = bind_listening_port_to_irq(remote_domain);
+ irq = bind_listening_port_to_irq(remote_domain, &port);
intr_register_source(&xp->xp_pins[irq].xp_intsrc);
error = intr_add_handler(devname, irq, NULL, handler, arg, irqflags,
&xp->xp_pins[irq].xp_cookie);
@@ -483,6
Re: svn commit: r216269 - head/sys/geom/part
on 08/12/2010 01:11 Matthew Jacob said the following: > Geometry is still important. Trying booting a USB flash drive on all BIOS' > with > a 63/255 geometry instead of a 64/32 geometry. Well, I don't know anything about USB... My point about modern HDDs still stands. > On 12/7/2010 2:14 PM, Andriy Gapon wrote: >> on 08/12/2010 00:05 Matthew Jacob said the following: >>> >>> On 12/7/2010 1:54 PM, Andriy Gapon wrote: on 07/12/2010 22:46 Bruce Cran said the following: > Don't warn if a partition appears not to be aligned on a track > boundary. > Modern disks use LBA and create a fake CHS geometry that doesn't have > any > relation to the on-disk layout of data. You repeated that statement, so I am picking on you :-) Can someone show me how/where exactly modern drives fakes CHS geometry? >>> cf cam_calc_geometry >> But that's not drive firmware code :-) >> It's us faking those parameters for ourselves for some unknown reason. >> Stupid us :-) But not the drives / manufacturers. >> -- Andriy Gapon ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r216269 - head/sys/geom/part
on 08/12/2010 01:11 Bruce Cran said the following: > On Tue, 7 Dec 2010 23:06:24 + > Bruce Cran wrote: >> I guess the fields are still defined to keep old tools happy. > > I mean that values are still returned by the drive firmware, > while they could be left zero according to the spec. For example a new > 1TB ATA-8 drive returns a geometry of 16H/63S/16383C in those fields. Right. But we shouldn't bother reading those values, because they are specified as unused. Well, some retarded 10+ years old software should probably be kept happy, but modern FreeBSD is not like that, right? :) -- Andriy Gapon ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r216282 - in head: share/misc usr.bin/calendar/calendars
Author: flo (ports committer) Date: Tue Dec 7 23:56:51 2010 New Revision: 216282 URL: http://svn.freebsd.org/changeset/base/216282 Log: Add myself to calendar.freebsd and committers-ports.dot Approved by: fjoe (mentor) Modified: head/share/misc/committers-ports.dot head/usr.bin/calendar/calendars/calendar.freebsd Modified: head/share/misc/committers-ports.dot == --- head/share/misc/committers-ports.dotTue Dec 7 23:44:07 2010 (r216281) +++ head/share/misc/committers-ports.dotTue Dec 7 23:56:51 2010 (r216282) @@ -80,6 +80,7 @@ eik [label="Oliver eikemeier\n...@freebs erwin [label="Erwin lansing\ner...@freebsd.org\n2003/06/04"] farrokhi [label="Babak farrokhi\nfarro...@freebsd.org\n2006/11/07"] fjoe [label="Max khon\nf...@freebsd.org\n2001/08/06"] +flo [label="Florian smeets\n...@freebsd.org\n2010/12/07"] fluffy [label="Dima panov\nflu...@freebsd.org\n2009/08/10"] flz [label="Florent thoumie\n...@freebsd.org\n2005/03/01"] gabor [label="Gabor kovesdan\nga...@freebsd.org\n2006/12/05"] @@ -230,6 +231,7 @@ erwin -> lth erwin -> simon fjoe -> danfe +fjoe -> flo fjoe -> krion fjoe -> osa @@ -262,6 +264,7 @@ itetcu -> dryice itetcu -> sahil jadawin -> bapt +jadawin -> flo joerg -> netchild Modified: head/usr.bin/calendar/calendars/calendar.freebsd == --- head/usr.bin/calendar/calendars/calendar.freebsdTue Dec 7 23:44:07 2010(r216281) +++ head/usr.bin/calendar/calendars/calendar.freebsdTue Dec 7 23:56:51 2010(r216282) @@ -159,6 +159,7 @@ 05/25 Tom Rhodes born in Ellwood City, Pennsylvania, United States, 1981 05/25 Roman Divacky born in Brno, Czech Republic, 1983 05/26 Jim Pirzyk born in Chicago, Illinois, United States, 1968 +05/26 Florian Smeets born in Schwerte, Nordrhein-Westfalen, Germany, 1982 05/27 Ollivier Robert born in Paris, France, 1967 05/29 Wilko Bulte born in Arnhem, the Netherlands, 1965 05/29 Seigo Tanimura born in Kitakyushu, Fukuoka, Japan, 1976 ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r216280 - head/sys/xen/evtchn
On 12/07/10 15:33, Colin Percival wrote: > Log: > Postpone the unmasking of event channels (aka. interrupts) until after > the interrupt handlers have been registered. NULL isn't a very good > interrupt handler. Forgot to add: While here, make bind_ipi_to_irq static, since it isn't used from any other files in the tree, and all the other bind_*_to_irq functions are already static. -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r216283 - in head/sys: amd64/amd64 amd64/include conf i386/i386 x86/x86
Author: jkim Date: Wed Dec 8 00:09:24 2010 New Revision: 216283 URL: http://svn.freebsd.org/changeset/base/216283 Log: Merge sys/amd64/amd64/tsc.c and sys/i386/i386/tsc.c and move to sys/x86/x86. Discussed with: avg Added: head/sys/x86/x86/tsc.c - copied unchanged from r216279, head/sys/i386/i386/tsc.c Deleted: head/sys/amd64/amd64/tsc.c head/sys/i386/i386/tsc.c Modified: head/sys/amd64/include/cpu.h head/sys/conf/files.amd64 head/sys/conf/files.i386 head/sys/conf/files.pc98 Modified: head/sys/amd64/include/cpu.h == --- head/sys/amd64/include/cpu.hTue Dec 7 23:56:51 2010 (r216282) +++ head/sys/amd64/include/cpu.hWed Dec 8 00:09:24 2010 (r216283) @@ -56,6 +56,7 @@ #ifdef _KERNEL extern charbtext[]; extern charetext[]; +extern int tsc_present; void cpu_halt(void); void cpu_reset(void); Modified: head/sys/conf/files.amd64 == --- head/sys/conf/files.amd64 Tue Dec 7 23:56:51 2010(r216282) +++ head/sys/conf/files.amd64 Wed Dec 8 00:09:24 2010(r216283) @@ -126,7 +126,6 @@ amd64/amd64/stack_machdep.c optionalddb amd64/amd64/support.S standard amd64/amd64/sys_machdep.c standard amd64/amd64/trap.c standard -amd64/amd64/tsc.c standard amd64/amd64/uio_machdep.c standard amd64/amd64/uma_machdep.c standard amd64/amd64/vm_machdep.c standard @@ -326,3 +325,4 @@ x86/x86/mptable.c optionalmptable x86/x86/mptable_pci.c optionalmptable pci x86/x86/msi.c optionalpci x86/x86/nexus.cstandard +x86/x86/tsc.c standard Modified: head/sys/conf/files.i386 == --- head/sys/conf/files.i386Tue Dec 7 23:56:51 2010(r216282) +++ head/sys/conf/files.i386Wed Dec 8 00:09:24 2010(r216283) @@ -312,7 +312,6 @@ i386/i386/support.s standard i386/i386/swtch.s standard i386/i386/sys_machdep.cstandard i386/i386/trap.c standard -i386/i386/tsc.cstandard i386/i386/uio_machdep.cstandard i386/i386/vm86.c standard i386/i386/vm_machdep.c standard @@ -415,3 +414,4 @@ x86/x86/mptable.c optional apic native x86/x86/mptable_pci.c optional apic pci x86/x86/msi.c optional apic pci x86/x86/nexus.cstandard +x86/x86/tsc.c standard Modified: head/sys/conf/files.pc98 == --- head/sys/conf/files.pc98Tue Dec 7 23:56:51 2010(r216282) +++ head/sys/conf/files.pc98Wed Dec 8 00:09:24 2010(r216283) @@ -164,7 +164,6 @@ i386/i386/support.s standard i386/i386/swtch.s standard i386/i386/sys_machdep.cstandard i386/i386/trap.c standard -i386/i386/tsc.cstandard i386/i386/uio_machdep.cstandard i386/i386/vm86.c standard i386/i386/vm_machdep.c standard @@ -259,3 +258,4 @@ x86/x86/mptable.c optional apic x86/x86/mptable_pci.c optional apic pci x86/x86/msi.c optional apic pci x86/x86/nexus.cstandard +x86/x86/tsc.c standard Copied: head/sys/x86/x86/tsc.c (from r216279, head/sys/i386/i386/tsc.c) == --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/sys/x86/x86/tsc.c Wed Dec 8 00:09:24 2010(r216283, copy of r216279, head/sys/i386/i386/tsc.c) @@ -0,0 +1,281 @@ +/*- + * Copyright (c) 1998-2003 Poul-Henning Kamp + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + *notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + *notice, this list of conditions and the following disclaimer in the + *documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT
svn commit: r216284 - head/sys/dev/usb/net
Author: yongari
Date: Wed Dec 8 01:24:05 2010
New Revision: 216284
URL: http://svn.freebsd.org/changeset/base/216284
Log:
r184610 changed the way how TX frames are handled on AX88178 and
AX88772 controllers. ASIX added a new feature for AX88178/AX88772
controllers which allows combining multiple TX frames into a single
big frame. This was to overcome one of USB limitation where it
can't generate more than 8k interrupts/sec which in turn means USB
ethernet controllers can not send more than 8k packets per second.
Using ASIX's feature greatly enhanced TX performance(more than 3~4
times) compared to 7.x driver. However it seems r184610 removed
boundary checking for buffered frames which in turn caused
instability issues under certain conditions. In addition, using
ASIX's feature triggered another issue which made USB controller
hang under certain conditions. Restarting ethernet controller
didn't help under this hang condition and unplugging and replugging
the controller was the only solution. I believe there is a silicon
bug in TX frame combining feature on AX88178/AX88772 controllers.
To address these issues, reintroduce the boundary checking for both
AX88178 and AX88772 after copying a frame to USB buffer and do not
use ASIX's multiple frame combining feature. Instead, use USB
controller's multi-frame transmit capability to enhance TX
performance as suggested by Hans[1].
This should fix a long standing axe(4) instability issues reported
on AX88772 and AX88178 controllers. While I'm here remove
unnecessary TX frame length check since upper stack always
guarantee the size of a frame to be less than MCLBYTES.
Special thanks to Derrick Brashear who tried numerous patches
during last 4 months and waited real fix with patience. Without
this enthusiastic support, patience and H/W donation I couldn't fix
it since I was not able to trigger the issue on my box.
Suggested by: hselasky [1]
Tested by:Derrick Brashear (shadow <> gmail dot com>
H/W donated by: Derrick Brashear (shadow <> gmail dot com>
PR: usb/140883
Modified:
head/sys/dev/usb/net/if_axe.c
Modified: head/sys/dev/usb/net/if_axe.c
==
--- head/sys/dev/usb/net/if_axe.c Wed Dec 8 00:09:24 2010
(r216283)
+++ head/sys/dev/usb/net/if_axe.c Wed Dec 8 01:24:05 2010
(r216284)
@@ -200,7 +200,8 @@ static const struct usb_config axe_confi
.type = UE_BULK,
.endpoint = UE_ADDR_ANY,
.direction = UE_DIR_OUT,
- .bufsize = AXE_BULK_BUF_SIZE,
+ .frames = 16,
+ .bufsize = 16 * MCLBYTES,
.flags = {.pipe_bof = 1,.force_short_xfer = 1,},
.callback = axe_bulk_write_callback,
.timeout = 1, /* 10 seconds */
@@ -939,7 +940,7 @@ axe_bulk_write_callback(struct usb_xfer
struct ifnet *ifp = uether_getifp(&sc->sc_ue);
struct usb_page_cache *pc;
struct mbuf *m;
- int pos;
+ int nframes, pos;
switch (USB_GET_STATE(xfer)) {
case USB_ST_TRANSFERRED:
@@ -956,40 +957,34 @@ tr_setup:
*/
return;
}
- pos = 0;
- pc = usbd_xfer_get_frame(xfer, 0);
-
- while (1) {
+ for (nframes = 0; nframes < 16 &&
+ !IFQ_DRV_IS_EMPTY(&ifp->if_snd); nframes++) {
IFQ_DRV_DEQUEUE(&ifp->if_snd, m);
-
- if (m == NULL) {
- if (pos > 0)
- break; /* send out data */
- return;
- }
- if (m->m_pkthdr.len > MCLBYTES) {
- m->m_pkthdr.len = MCLBYTES;
- }
+ if (m == NULL)
+ break;
+ usbd_xfer_set_frame_offset(xfer, nframes * MCLBYTES,
+ nframes);
+ pos = 0;
+ pc = usbd_xfer_get_frame(xfer, nframes);
if (AXE_IS_178_FAMILY(sc)) {
-
hdr.len = htole16(m->m_pkthdr.len);
hdr.ilen = ~hdr.len;
-
usbd_copy_in(pc, pos, &hdr, sizeof(hdr));
-
pos += sizeof(hdr);
-
- /*
-* NOTE: Some drivers force a short packet
-* by appending a dummy header with zero
-* length at then end of the USB transfer.
-* This driver uses the
-* USB_FORCE_SHORT_XFER flag instead.
-*/
Re: svn commit: r216263 - head/sys/dev/acpica
On Tue, Dec 07, 2010 at 06:49:11PM +, John Baldwin wrote: > Author: jhb > Date: Tue Dec 7 18:49:11 2010 > New Revision: 216263 > URL: http://svn.freebsd.org/changeset/base/216263 > > Log: > Use proper resource ID's for HPET IRQ resources. This mostly consists of > looking to see if there is an existing IRQ resource for a given IRQ > provided by the BIOS and using that RID if so. Otherwise, allocate a new > RID for the new IRQ. Could it be related to "device_attach: acpi_hpet0 attach returned 12" messages quite a few of us are seeing by chance? If yes, will it be MFCed to 7/8? ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r216285 - head/usr.sbin/cxgbtool
Author: kevlo Date: Wed Dec 8 01:35:19 2010 New Revision: 216285 URL: http://svn.freebsd.org/changeset/base/216285 Log: Closing file descriptors when it's done Reviewed by: np Modified: head/usr.sbin/cxgbtool/cxgbtool.c Modified: head/usr.sbin/cxgbtool/cxgbtool.c == --- head/usr.sbin/cxgbtool/cxgbtool.c Wed Dec 8 01:24:05 2010 (r216284) +++ head/usr.sbin/cxgbtool/cxgbtool.c Wed Dec 8 01:35:19 2010 (r216285) @@ -1014,6 +1014,8 @@ load_fw(int argc, char *argv[], int star op.len = len; if (doit(iff_name, CHELSIO_LOAD_FW, &op) < 0) err(1, "load firmware"); + + close(fd); return 0; } @@ -1048,6 +1050,7 @@ load_boot(int argc, char *argv[], int st if (doit(iff_name, CHELSIO_LOAD_BOOT, &op) < 0) err(1, "load boot image"); + close(fd); return 0; } ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r216230 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
On Tue, 7 Dec 2010, Doug Barton wrote: On 12/07/2010 03:51, Bruce Cran wrote: From a new installation of Windows 7 and FreeBSD CURRENT: GEOM: ada0: partition 3 does not start on a track boundary. GEOM: ada0: partition 3 does not end on a track boundary. GEOM: ada0: partition 2 does not start on a track boundary. GEOM: ada0: partition 2 does not end on a track bounary. Partition 2 is the reserved partition while 3 is an NTFS partition, both created in the Windows setup application. Since Windows isn't bothering to align partitions do we still need to warn about it? It would be great to remove this warning. I see the same problem with partitions created by Linux, which uses the Windows'y version of CHS. GEOM_PART spews warnings like this (IIRC the same ones) for partitions created by FreeBSD when FreeBSD actually knew the correct (fictitious BIOS) geometry. Killing GEOM_PART stopped them. Note that GEOM_PART is inflicted by conf/DEFAULTS, at least for i386. # Kill bad default options. nooptions GEOM_PART_BSD nooptions GEOM_PART_EBR nooptions GEOM_PART_EBR_COMPAT nooptions GEOM_PART_MBR # Add non-default options. options GEOM_BSD options GEOM_MBR GEOM_PART also gave weirdness for FreeBSD partitions, with multiple device entries for some partitions and other aliasing bugs. Bruce ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r216269 - head/sys/geom/part
On Wed, 8 Dec 2010, Andriy Gapon wrote: on 08/12/2010 00:05 Matthew Jacob said the following: On 12/7/2010 1:54 PM, Andriy Gapon wrote: on 07/12/2010 22:46 Bruce Cran said the following: Don't warn if a partition appears not to be aligned on a track boundary. Modern disks use LBA and create a fake CHS geometry that doesn't have any relation to the on-disk layout of data. You repeated that statement, so I am picking on you :-) Can someone show me how/where exactly modern drives fakes CHS geometry? cf cam_calc_geometry But that's not drive firmware code :-) Indeed. It's us faking those parameters for ourselves for some unknown reason. Stupid us :-) But not the drives / manufacturers. Faking the geometry, and determining the correct fake, goes back at least 20 years to Adaptec SCSI BIOSes for host adaptors. AFAIK, SCSI drives never had any CHS geometry, fake or otherwise. But some O/S's wanted CHS. This was faked in BIOS ROMs for at least the better host adaptors, since booting is too hard if it is only in a driver loaded from a file system. Originally the fake was fairly statically configured using rules like the ones in cam_calc_geometry(), but different adaptor manufacturers used different rules (or maybe there was a jumper or BIOS option to control the behaviour, but this was too confusing for users) so there were large problems changing the adaptor. So BIOSes started attempting to determine the CHS geometry that is actually used by O/S's, according to partition table entries, and supplied that as a fake instead of their default fake. This caused different large problems changing the adaptor, when bugs or differences in the algorithm caused different fakes to be determined. FreeBSD used to try to determine determine the CHS geometry that is actually used by O/S's, using similar algorithms to the BIOSes. This has been lost to GEOM. GEOM now "uses" whatever geometry is supplied by lower layers. I know of the following cases: - for SCSI drives, I think it uses the fake generated by cam_calc_geometry(). This is not too bad. It would have been invariant over the last for 20-30 years if SCSI BIOSes had agreed on it originally. Perhaps the SCSI standard now specifies this. Unfortunately, cam_calc_geometry() has no comment about this. - I think the next case would break pc98, so pc98 uses a hook to supply a more compatible default. - for ATA drives, it uses the "firmware" geometry supplied by the drive firmware. The ATA standard specifies this to be H=16/S=63 for all drives larger than a certain size (IIRC, about 8GB, which is the size at which the better default fake of H=255/S=63 generated by cam_calc_geometry() for drives larger than 1GB, stops working for systems that can't handle more than 1024 fake cylinders. The magic 1GB is the size at which the even better default fake of H=64/S=32 stops working with more than 1024 fake cylinders. cam_calc_geometry() has no comment about this either). Since all modern ATA drives are larger than 8GB, H=16/S=63 is almost hard-coded for ATA. This results in GEOM "using" a geometry that is wrong in many cases for non-pc98 ATA drives, since many were configured with H=255/S=63. The other cases are more compatible. After this commit, GEOM hopefully doesn't actually use the CHS geometry for anything. It should just report it to userland, and should get it right for that. The correct geometry has little to do with the "firmware" geometry. It is whatever the BIOS or disks are using, if anything is still using CHS. Modern BIOSes should "use" CHS in the same way that GEOM should, that is, never, but they should report it for old software to use, and should get it right for that. I don't know how far they have got towards that. Some support H=16/S=63 but default to weird geometries. Some allow this to be configured. I always configure to "LBA" (H=255/S=63) for compatibility. Let me specifically ask that question about modern (S)ATA drives directly connected to a system (controller). My impression is at least since ATA-7 there is no mentioning of anything CHS-related in the specification. The fact that we keep reading and interpreting some historically defined bytes that are now marked as unused/reserved doesn't mean that those bytes actually mean anything. Aren't they optional? Last time I looked at the ATA standard (5-10 years ago), IIRC it said that support for CHS translation mode is optional, but when it is supported all the fields for using it (the default translation mode (always H=16/C=63 for modern drives) and the current translation mode) must be supported. I guess support for it is now so cheap that most manufacturers support it for compatibility. Bruce ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r216269 - head/sys/geom/part
On Tue, 7 Dec 2010, Bruce Cran wrote: On Tue, 07 Dec 2010 23:54:17 +0200 Andriy Gapon wrote: You repeated that statement, so I am picking on you :-) Can someone show me how/where exactly modern drives fakes CHS geometry? Let me specifically ask that question about modern (S)ATA drives directly connected to a system (controller). My impression is at least since ATA-7 there is no mentioning of anything CHS-related in the specification. The fact that we keep reading and interpreting some historically defined bytes that are now marked as unused/reserved doesn't mean that those bytes actually mean anything. You're right: I last looked at the IDENTIFY data about 7 years ago when those fields were defined; now they're marked as "obsolete". I guess the fields are still defined to keep old tools happy. Both atacontrol and camcontrol are still reading the IDENTIFY data and outputting the CHS fields even on ATA-8 drives, which I guess they shouldn't be. Utilities for reporting capabilities must report capabilities if they are supported. Whether unsupported fields should be reported as integer 0's or in a special format (e.g., not printing anything for unsupported sub-fields) is another question. atacontrol is a bit too simple and inconsistent. It prints CHS values unconditionally. Then it prints "CFA supported" if CFA is supported, else nothing. Then it inconsistently prints "LBA supported " if LBA is supported, else "LBA not supported ". Then it prints the number of sectors supported by LBA, but under a different condition. Then it prints many more things like it prints LBA, using "supported/not supported" or, again inconsistently, "yes/no" instead of "supported"/nothing. Bruce ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r216269 - head/sys/geom/part
On Wed, 8 Dec 2010, Andriy Gapon wrote: on 08/12/2010 01:11 Matthew Jacob said the following: Geometry is still important. Trying booting a USB flash drive on all BIOS' with a 63/255 geometry instead of a 64/32 geometry. Well, I don't know anything about USB... My point about modern HDDs still stands. Hmm, I know how to avoid geometry errors in FreeBSD, but recently had them for Linux, and had problems booting USB drives, which I didn't know might be caused by geometry. One USB drive has the manufacturer's partitioning, which has starting CHS consistent with H=any/C=44 and ending CHS consistent with H=255/S=63. cam gives the default fake geometry of H=255/S=63, and my de-GEOMed kernel doesn't change this since it is consistent enough with the partitioning. This drive is not bootable and I haven't noticed any problems with it. Another USB drive has all partitions configured using the cam default. It boots on some systems only, almost never on one except IIRC it once booted on that too, when the partitioning may have been simpler. Bruce ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r216286 - stable/8/share/man/man4
Author: dougb Date: Wed Dec 8 07:00:22 2010 New Revision: 216286 URL: http://svn.freebsd.org/changeset/base/216286 Log: MFC r216065: Update the description of green_saver.ko Improvements to my suggested text from: jhb Approved by: re (kib) Modified: stable/8/share/man/man4/splash.4 Directory Properties: stable/8/share/man/man4/ (props changed) Modified: stable/8/share/man/man4/splash.4 == --- stable/8/share/man/man4/splash.4Wed Dec 8 01:35:19 2010 (r216285) +++ stable/8/share/man/man4/splash.4Wed Dec 8 07:00:22 2010 (r216286) @@ -26,7 +26,7 @@ .\" .\" $FreeBSD$ .\" -.Dd January 15, 2006 +.Dd November 29, 2010 .Dt SPLASH 4 .Os .Sh NAME @@ -108,7 +108,10 @@ The screen will gradually fade away. .It Pa fire_saver.ko A fire which becomes higher as load increases. .It Pa green_saver.ko -If the monitor supports power saving mode, it will be turned off. +The screen will be blanked, similar to +.Pa blank_saver.ko . +If the monitor and the video card's BIOS support it +the screen will also be powered off. .It Pa logo_saver.ko Animated graphical .Bx ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r216287 - stable/7/share/man/man4
Author: dougb Date: Wed Dec 8 07:00:53 2010 New Revision: 216287 URL: http://svn.freebsd.org/changeset/base/216287 Log: MFC r216065: Update the description of green_saver.ko Improvements to my suggested text from: jhb Approved by: re (kib) Modified: stable/7/share/man/man4/splash.4 Directory Properties: stable/7/share/man/man4/ (props changed) Modified: stable/7/share/man/man4/splash.4 == --- stable/7/share/man/man4/splash.4Wed Dec 8 07:00:22 2010 (r216286) +++ stable/7/share/man/man4/splash.4Wed Dec 8 07:00:53 2010 (r216287) @@ -26,7 +26,7 @@ .\" .\" $FreeBSD$ .\" -.Dd January 15, 2006 +.Dd November 29, 2010 .Dt SPLASH 4 .Os .Sh NAME @@ -108,7 +108,10 @@ The screen will gradually fade away. .It Pa fire_saver.ko A fire which becomes higher as load increases. .It Pa green_saver.ko -If the monitor supports power saving mode, it will be turned off. +The screen will be blanked, similar to +.Pa blank_saver.ko . +If the monitor and the video card's BIOS support it +the screen will also be powered off. .It Pa logo_saver.ko Animated graphical .Bx ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r216288 - head/share/man/man5
Author: hrs Date: Wed Dec 8 07:10:25 2010 New Revision: 216288 URL: http://svn.freebsd.org/changeset/base/216288 Log: Fix a typo. Submitted by: Garrett Cooper Modified: head/share/man/man5/rc.conf.5 Modified: head/share/man/man5/rc.conf.5 == --- head/share/man/man5/rc.conf.5 Wed Dec 8 07:00:53 2010 (r216287) +++ head/share/man/man5/rc.conf.5 Wed Dec 8 07:10:25 2010 (r216288) @@ -1293,7 +1293,7 @@ the default address selection policy tab will be IPv4-preferred. .Pp This variable is deprecated. Use -.Va ip6addtctl_policy +.Va ip6addrctl_policy instead. .It Va ipv6_activate_all_interfaces If the variable is ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r216284 - head/sys/dev/usb/net
On Wednesday 08 December 2010 02:24:05 Pyun YongHyeon wrote:
> - if (m->m_pkthdr.len > MCLBYTES) {
> - m->m_pkthdr.len = MCLBYTES;
> - }
You are sure that no packets passed to this code is bigger than MCLBYTES minus
overhead by AXE protocol ? Even if MTU is changed by ifconfig?
--HPS
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r216263 - head/sys/dev/acpica
Alexey Dokuchaev wrote: > On Tue, Dec 07, 2010 at 06:49:11PM +, John Baldwin wrote: >> Author: jhb >> Date: Tue Dec 7 18:49:11 2010 >> New Revision: 216263 >> URL: http://svn.freebsd.org/changeset/base/216263 >> >> Log: >> Use proper resource ID's for HPET IRQ resources. This mostly consists of >> looking to see if there is an existing IRQ resource for a given IRQ >> provided by the BIOS and using that RID if so. Otherwise, allocate a new >> RID for the new IRQ. > > Could it be related to "device_attach: acpi_hpet0 attach returned 12" > messages quite a few of us are seeing by chance? If yes, will it be > MFCed to 7/8? HPET driver on 7/8 doesn't yet using IRQs at all. If it fails, then for some other reason. -- Alexander Motin ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
