Re: Status of support for 4KB disk sectors
Jeremy Chadwick free...@jdc.parodius.com wrote: On Wed, Jul 20, 2011 at 02:39:28AM -0700, per...@pluto.rain.com wrote: IIRC, Plextor (and maybe some others) had a switch to select 512 or 2048 as the default transfer size, precisely so that they could be used as boot devices with systems that supported only 512. I don't think Plextor was around back then; they used to be called TEXEL back in the early 90s. The only Sun SCSI CD drives I saw were external and caddy-based, so I mentally correlate them with NEC. Back then I wasn't looking at brands as much as I do today, though. I still have a non-Sun 512-2048 drive; turns out it is a (caddy- based) Hitachi CDR-1750S rather than a Plextor. So much for remembering all the details from late in the Sun-3 era. (Plextor still rings a bell WRT the 512-2048 switch though; maybe some of the early Plextor drives also provided one.) Chuck Swiger cswi...@mac.com wrote: Come to think of it, I do remember that switch, yes. Do you happen to know whether this limitation was part of the Sun hardware, or of SunOS? CMU had a lot of Sun3 machines and NeXT clusters, so I ended up mixing NeXT CD-ROM and the Canon? magneto- optical drives with Sun H/W, and vice versa. Dunno if there were any hardware limitations, but most Sun-3 _bootroms_ predated CDROM support and thus could boot from a CD only by being fooled into believing it was a normal MFM or ESDI hard drive connected via an Adaptec ACB-4000 (SCSI-MFM) or Emulex MD21 (SCSI-ESDI) bridge controller. Remember those? This only worked if the CD drive's transfer size matched the expected hard drive sector size. I think the SunOS sr driver took the path of least resistance and issued an explicit set transfer size 512 before trying to access the drive, thus enabling off-brand CD drives to work with the OS without running into any limitations that might have existed in either the hardware or the lower-level SCSI drivers, but that only worked after the OS had been booted :) SunOS wasn't the only O/S which was run on a m68k Sun box. ;-) I'm aware of a NetBSD port that may still exist even today. Others? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: disable 64-bit dma for one PCI slot only?
Am 19.07.2011 20:17, schrieb Artem Belevich: On Tue, Jul 19, 2011 at 6:31 AM, John Baldwin j...@freebsd.org wrote: The only reason it might be nice to stick with two fields is due to the line length (though the first line is over 80 cols even in the current format). Here are two possible suggestions: old: hostb0@pci0:0:0:0: class=0x06 card=0x20108086 chip=0x01008086 rev=0x09 hdr=0x00 pcib1@pci0:0:1:0: class=0x060400 card=0x20108086 chip=0x01018086 rev=0x09 hdr=0x01 pcib2@pci0:0:1:1: class=0x060400 card=0x20108086 chip=0x01058086 rev=0x09 hdr=0x01 none0@pci0:0:22:0: class=0x078000 card=0x47428086 chip=0x1c3a8086 rev=0x04 hdr=0x00 em0@pci0:0:25:0:class=0x02 card=0x8086 chip=0x15038086 rev=0x04 hdr=0x00 ... A) hostb0@pci0:0:0:0: class=0x06 vendor=0x8086 device=0x0100 subvendor=0x8086 subdevice=0x2010 rev=0x09 hdr=0x00 pcib1@pci0:0:1:0: class=0x060400 vendor=0x8086 device=0x0101 subvendor=0x8086 subdevice=0x2010 rev=0x09 hdr=0x01 pcib2@pci0:0:1:1: class=0x060400 vendor=0x8086 device=0x0105 subvendor=0x8086 subdevice=0x2010 rev=0x09 hdr=0x01 none0@pci0:0:22:0: class=0x078000 vendor=0x8086 device=0x1c3a subvendor=0x8086 subdevice=0x4742 rev=0x04 hdr=0x00 em0@pci0:0:25:0:class=0x02 vendor=0x8086 device=0x1503 subvendor=0x8086 subdevice=0x rev=0x04 hdr=0x00 ... B) hostb0@pci0:0:0:0: class=0x06 devid=0x8086:0100 subid=0x8086:2010 rev=0x09 hdr=0x00 pcib1@pci0:0:1:0: class=0x060400 devid=0x8086:0101 subid=0x8086:2010 rev=0x09 hdr=0x01 pcib2@pci0:0:1:1: class=0x060400 devid=0x8086:0105 subid=0x8086:2010 rev=0x09 hdr=0x01 none0@pci0:0:22:0: class=0x078000 devid=0x8086:1c3a subid=0x8086:4742 rev=0x04 hdr=0x00 em0@pci0:0:25:0:class=0x02 devid=0x8086:1503 subid=0x8086: rev=0x04 hdr=0x00 ... I went with vendor word first for both A) and B) as in my experience that is the more common ordering in driver tables, etc. Do we need to print (class|devid|device|subvendor|etc.)= on every line? IMHO they belong to a header line. Something like this: Driver Handle ClassVnd:Dev Sub Vnd:Dev Rev Hdr -- hostb0 pci0:0:0:0 0x06 0x8086:0100 0x8086:2010 0x09 0x00 pcib1 pci0:0:1:0 0x060400 0x8086:0101 0x8086:2010 0x09 0x01 pcib2 pci0:0:1:1 0x060400 0x8086:0105 0x8086:2010 0x09 0x01 none0 pci0:0:22:0 0x078000 0x8086:1c3a 0x8086:4742 0x04 0x00 em0pci0:0:25:0 0x02 0x8086:1503 0x8086: 0x04 0x00 This is a very good idea, IMHO. When I committed pciconf back in 1996 (it had been contributed by gwollman) for PCI 1.0 (at a time when their was no standard for PCI to PCI brigdes, yet ;-) ), the current format seemed sensible, but the tabular form suggested by Artem is much better to parse. I'd want to suggest another slightly different format: Driver Handle ClassVndDevSubVnd SubDev Rev Hdr hostb0 0:0:0:00x06 0x8086 0x0100 0x8086 0x2010 0x09 0x00 pcib1 0:0:1:00x060400 0x8086 0x0101 0x8086 0x2010 0x09 0x01 pcib2 0:0:1:10x060400 0x8086 0x0105 0x8086 0x2010 0x09 0x01 none0 0:0:22:0 0x078000 0x8086 0x1c3a 0x8086 0x4742 0x04 0x00 em00:0:25:0 0x02 0x8086 0x1503 0x8086 0x 0x04 0x00 dummy0 65535:255:31:7 0x02 0x8086 0x1503 0x8086 0x 0x04 0x00 I.e., print only one header line (no ---), make the Handle column wide enough to hold the longest possible value, use only white space to separate columns and print 0x as a prefix for all hex numbers. Instead of pci0:0:0:0 for the PCI handle, just 0:0:0:0 could be printed, IMHO. (But this is bikeshed material, I guess ...) The Rev column is required for of devices that are not uniquely identified by their Vnd/Dev-IDs. (These used to exist, e.g. the Symbios SCSI controllers, though I'm not aware of any device that needed a different driver depending on the PCI revision number.) I'd be happy to modify pciconf to print the new format in -CURRENT (having been the maintainer of the PCI code for quite some time), if consensus is reached on a format and if this change is accepted by RE. Regards, STefan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: disable 64-bit dma for one PCI slot only?
On Wed, Jul 20, 2011 at 11:54:06AM +0200, Stefan Esser wrote: The Rev column is required for of devices that are not uniquely identified by their Vnd/Dev-IDs. (These used to exist, e.g. the Symbios SCSI controllers, though I'm not aware of any device that needed a different driver depending on the PCI revision number.) Might be there is indeed no such device which require different driver due to revision, but there are definitely devices that require different workarounds in the driver based on revision. Seeing the revision in the output of pciconf very much helps to reduce the mail turnaround when analyzing user reports. pgp5QDCLC8Yv0.pgp Description: PGP signature
Re: disable 64-bit dma for one PCI slot only?
On Jul 20, 2011, at 3:54 AM, Stefan Esser wrote: This is a very good idea, IMHO. When I committed pciconf back in 1996 (it had been contributed by gwollman) for PCI 1.0 (at a time when their was no standard for PCI to PCI brigdes, yet ;-) ), the current format seemed sensible, but the tabular form suggested by Artem is much better to parse. I'd want to suggest another slightly different format: Driver Handle ClassVndDevSubVnd SubDev Rev Hdr hostb0 0:0:0:00x06 0x8086 0x0100 0x8086 0x2010 0x09 0x00 pcib1 0:0:1:00x060400 0x8086 0x0101 0x8086 0x2010 0x09 0x01 pcib2 0:0:1:10x060400 0x8086 0x0105 0x8086 0x2010 0x09 0x01 none0 0:0:22:0 0x078000 0x8086 0x1c3a 0x8086 0x4742 0x04 0x00 em00:0:25:0 0x02 0x8086 0x1503 0x8086 0x 0x04 0x00 dummy0 65535:255:31:7 0x02 0x8086 0x1503 0x8086 0x 0x04 0x00 I.e., print only one header line (no ---), make the Handle column wide enough to hold the longest possible value, use only white space to separate columns and print 0x as a prefix for all hex numbers. Instead of pci0:0:0:0 for the PCI handle, just 0:0:0:0 could be printed, IMHO. (But this is bikeshed material, I guess ...) The Rev column is required for of devices that are not uniquely identified by their Vnd/Dev-IDs. (These used to exist, e.g. the Symbios SCSI controllers, though I'm not aware of any device that needed a different driver depending on the PCI revision number.) Actually, a few drivers (amr in particular) look at this rev field during probe, though they should be looking at the subdev/ven ids instead. I think that this behavior has actually caused recent headaches for LSI with other drivers. But as Kostik points out, the rev field is still moderately useful for informational purposes. I'd be happy to modify pciconf to print the new format in -CURRENT (having been the maintainer of the PCI code for quite some time), if consensus is reached on a format and if this change is accepted by RE. I'm pretty sure that we scrape the current format at Yahoo and use it in our tools. Implementing a switch of some sort to fall back to the old format is something that will have to happen at some point, whether it's done now or not. I'd probably implement it as an env variable such as PCICONF_COMPAT, similar to what is used by expr(1). Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: disable 64-bit dma for one PCI slot only?
On Wed, Jul 20, 2011 at 11:54:06AM +0200, Stefan Esser wrote: Am 19.07.2011 20:17, schrieb Artem Belevich: On Tue, Jul 19, 2011 at 6:31 AM, John Baldwin j...@freebsd.org wrote: The only reason it might be nice to stick with two fields is due to the line length (though the first line is over 80 cols even in the current format). Here are two possible suggestions: old: hostb0@pci0:0:0:0: class=0x06 card=0x20108086 chip=0x01008086 rev=0x09 hdr=0x00 pcib1@pci0:0:1:0: class=0x060400 card=0x20108086 chip=0x01018086 rev=0x09 hdr=0x01 pcib2@pci0:0:1:1: class=0x060400 card=0x20108086 chip=0x01058086 rev=0x09 hdr=0x01 none0@pci0:0:22:0: class=0x078000 card=0x47428086 chip=0x1c3a8086 rev=0x04 hdr=0x00 em0@pci0:0:25:0:class=0x02 card=0x8086 chip=0x15038086 rev=0x04 hdr=0x00 ... A) hostb0@pci0:0:0:0: class=0x06 vendor=0x8086 device=0x0100 subvendor=0x8086 subdevice=0x2010 rev=0x09 hdr=0x00 pcib1@pci0:0:1:0: class=0x060400 vendor=0x8086 device=0x0101 subvendor=0x8086 subdevice=0x2010 rev=0x09 hdr=0x01 pcib2@pci0:0:1:1: class=0x060400 vendor=0x8086 device=0x0105 subvendor=0x8086 subdevice=0x2010 rev=0x09 hdr=0x01 none0@pci0:0:22:0: class=0x078000 vendor=0x8086 device=0x1c3a subvendor=0x8086 subdevice=0x4742 rev=0x04 hdr=0x00 em0@pci0:0:25:0:class=0x02 vendor=0x8086 device=0x1503 subvendor=0x8086 subdevice=0x rev=0x04 hdr=0x00 ... B) hostb0@pci0:0:0:0: class=0x06 devid=0x8086:0100 subid=0x8086:2010 rev=0x09 hdr=0x00 pcib1@pci0:0:1:0: class=0x060400 devid=0x8086:0101 subid=0x8086:2010 rev=0x09 hdr=0x01 pcib2@pci0:0:1:1: class=0x060400 devid=0x8086:0105 subid=0x8086:2010 rev=0x09 hdr=0x01 none0@pci0:0:22:0: class=0x078000 devid=0x8086:1c3a subid=0x8086:4742 rev=0x04 hdr=0x00 em0@pci0:0:25:0:class=0x02 devid=0x8086:1503 subid=0x8086: rev=0x04 hdr=0x00 ... I went with vendor word first for both A) and B) as in my experience that is the more common ordering in driver tables, etc. Do we need to print (class|devid|device|subvendor|etc.)= on every line? IMHO they belong to a header line. Something like this: Driver Handle ClassVnd:Dev Sub Vnd:Dev Rev Hdr -- hostb0 pci0:0:0:0 0x06 0x8086:0100 0x8086:2010 0x09 0x00 pcib1 pci0:0:1:0 0x060400 0x8086:0101 0x8086:2010 0x09 0x01 pcib2 pci0:0:1:1 0x060400 0x8086:0105 0x8086:2010 0x09 0x01 none0 pci0:0:22:0 0x078000 0x8086:1c3a 0x8086:4742 0x04 0x00 em0pci0:0:25:0 0x02 0x8086:1503 0x8086: 0x04 0x00 This is a very good idea, IMHO. When I committed pciconf back in 1996 (it had been contributed by gwollman) for PCI 1.0 (at a time when their was no standard for PCI to PCI brigdes, yet ;-) ), the current format seemed sensible, but the tabular form suggested by Artem is much better to parse. I'd want to suggest another slightly different format: Driver Handle ClassVndDevSubVnd SubDev Rev Hdr hostb0 0:0:0:00x06 0x8086 0x0100 0x8086 0x2010 0x09 0x00 pcib1 0:0:1:00x060400 0x8086 0x0101 0x8086 0x2010 0x09 0x01 pcib2 0:0:1:10x060400 0x8086 0x0105 0x8086 0x2010 0x09 0x01 none0 0:0:22:0 0x078000 0x8086 0x1c3a 0x8086 0x4742 0x04 0x00 em00:0:25:0 0x02 0x8086 0x1503 0x8086 0x 0x04 0x00 dummy0 65535:255:31:7 0x02 0x8086 0x1503 0x8086 0x 0x04 0x00 I.e., print only one header line (no ---), make the Handle column wide enough to hold the longest possible value, use only white space to separate columns and print 0x as a prefix for all hex numbers. Instead of pci0:0:0:0 for the PCI handle, just 0:0:0:0 could be printed, IMHO. (But this is bikeshed material, I guess ...) The Rev column is required for of devices that are not uniquely identified by their Vnd/Dev-IDs. (These used to exist, e.g. the Symbios SCSI controllers, though I'm not aware of any device that needed a different driver depending on the PCI revision number.) re(4) and rl(4) are one of example that needs the Rev. I'd be happy to modify pciconf to print the new format in -CURRENT (having been the maintainer of the PCI code for quite some time), if consensus is reached on a format and if this change is accepted by RE. Regards, STefan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: disable 64-bit dma for one PCI slot only?
Am 20.07.2011 18:11, schrieb Scott Long: On Jul 20, 2011, at 3:54 AM, Stefan Esser wrote: This is a very good idea, IMHO. When I committed pciconf back in 1996 (it had been contributed by gwollman) for PCI 1.0 (at a time when their was no standard for PCI to PCI brigdes, yet ;-) ), the current format seemed sensible, but the tabular form suggested by Artem is much better to parse. I'd want to suggest another slightly different format: Driver Handle ClassVndDevSubVnd SubDev Rev Hdr hostb0 0:0:0:00x06 0x8086 0x0100 0x8086 0x2010 0x09 0x00 pcib1 0:0:1:00x060400 0x8086 0x0101 0x8086 0x2010 0x09 0x01 pcib2 0:0:1:10x060400 0x8086 0x0105 0x8086 0x2010 0x09 0x01 none0 0:0:22:0 0x078000 0x8086 0x1c3a 0x8086 0x4742 0x04 0x00 em00:0:25:0 0x02 0x8086 0x1503 0x8086 0x 0x04 0x00 dummy0 65535:255:31:7 0x02 0x8086 0x1503 0x8086 0x 0x04 0x00 I.e., print only one header line (no ---), make the Handle column wide enough to hold the longest possible value, use only white space to separate columns and print 0x as a prefix for all hex numbers. Instead of pci0:0:0:0 for the PCI handle, just 0:0:0:0 could be printed, IMHO. (But this is bikeshed material, I guess ...) The Rev column is required for of devices that are not uniquely identified by their Vnd/Dev-IDs. (These used to exist, e.g. the Symbios SCSI controllers, though I'm not aware of any device that needed a different driver depending on the PCI revision number.) Actually, a few drivers (amr in particular) look at this rev field during probe, though they should be looking at the subdev/ven ids instead. I think that this behavior has actually caused recent headaches for LSI with other drivers. But as Kostik points out, the rev field is still moderately useful for informational purposes. Dependency on the revision is bad, if it is a required criterion for the selection of a driver. This used to be the case for the Symbios 53c810 vs. 53c860 (where the latter could take advantage of the sym driver, while the prior lacked support of features originally required by the sym driver and only worked with ncr). The subvendor/subdevice ID is not well suited to select a driver in that case, since it was not used in general (PCI 1.0, on-board controllers) and even if it was used, the list of subvendor/subdevice tuples is hard to maintain if there are many vendors using a certain PCI(e) chip. I'd be happy to modify pciconf to print the new format in -CURRENT (having been the maintainer of the PCI code for quite some time), if consensus is reached on a format and if this change is accepted by RE. I'm pretty sure that we scrape the current format at Yahoo and use it in our tools. Implementing a switch of some sort to fall back to the old format is something that will have to happen at some point, whether it's done now or not. I'd probably implement it as an env variable such as PCICONF_COMPAT, similar to what is used by expr(1). Hmm, then how about a new option (e.g. -t for tabular output, or -L for an alternate list format). For the current format, -l can be combined with -b, -c and/or -v to print BARs, CAPs and/or decoded vendor and device information. The new tabular format suggested above does not mix well with these extended list options, and thus I think we should introduce a new list option that is incompatible with -b, -c and -v. The old option would produce unchanged output and thus there is no need for PCICONF_COMPAT. Regards, STefan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: disable 64-bit dma for one PCI slot only?
On 20.07.2011 18:25, YongHyeon PYUN wrote: The Rev column is required for of devices that are not uniquely identified by their Vnd/Dev-IDs. (These used to exist, e.g. the Symbios SCSI controllers, though I'm not aware of any device that needed a different driver depending on the PCI revision number.) re(4) and rl(4) are one of example that needs the Rev. Does the decision whether re or rl attaches the device depend on the revision field? This used to be the case for ncr and sym, too, but one driver was extended to cover all devices supported by the other ... Anyway: I agree that the revision is significant information and should be kept in pciconf output. Regards, STefan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: powernow regression in 8-STABLE
On Tuesday 19 July 2011 07:20 am, Callum Gibson wrote:
Hi,
I've just noticed and tracked down a regression in
x86/cpufreq/powernow.c (on amd64) which was first mentioned here:
http://lists.freebsd.org/pipermail/freebsd-current/2011-March/02350
9.html
although no followup seems to have occurred.
The above thread is irrelevant. It was an Intel processor.
Symptoms are that powerd stops working because the dev.cpu.0.freq
OID is no longer gettable nor settable.
This seems to have been caused by the following revision:
http://svnweb.freebsd.org/base?view=revisionrevision=222148
which was in turn an MFC of r221102, so I guess the problem exists
on -current as well, although I can't confirm that since I don't
run it.
Reverting the change fixes the problem and powerd will work again.
Also other utilities, such as xacpim, work properly.
I'm running a ML-40 Turion laptop (HP Compaq nx6125).
From your dmesg output, I see that the processor speed was not
calibrated properly. ML-40's max. core freq. is 2,200 MHz according
to its specification but it was probed at 2,282 MHz, which is too
high. I think that's the problem. Can you please try the attached
patch?
Jung-uk Kim
Index: sys/kern/kern_cpu.c
===
--- sys/kern/kern_cpu.c (revision 224231)
+++ sys/kern/kern_cpu.c (working copy)
@@ -159,16 +159,21 @@ cpufreq_attach(device_t dev)
CF_MTX_INIT(sc-lock);
sc-curr_level.total_set.freq = CPUFREQ_VAL_UNKNOWN;
SLIST_INIT(sc-saved_freq);
- /* Try to get nominal CPU freq to use it as maximum later if needed */
- sc-max_mhz = cpu_get_nominal_mhz(dev);
- /* If that fails, try to measure the current rate */
- if (sc-max_mhz = 0) {
- pc = cpu_get_pcpu(dev);
- if (cpu_est_clockrate(pc-pc_cpuid, rate) == 0)
- sc-max_mhz = rate / 100;
- else
- sc-max_mhz = CPUFREQ_VAL_UNKNOWN;
+ if (sc-max_mhz == CPUFREQ_VAL_UNKNOWN) {
+ /* Try to get nominal CPU freq to use it as maximum later. */
+ sc-max_mhz = cpu_get_nominal_mhz(dev);
+ /* If that fails, try to measure the current rate */
+ if (sc-max_mhz = 0) {
+ pc = cpu_get_pcpu(dev);
+ if (cpu_est_clockrate(pc-pc_cpuid, rate) == 0)
+ sc-max_mhz = rate / 100;
+ else
+ sc-max_mhz = CPUFREQ_VAL_UNKNOWN;
+ }
}
+ if (sc-max_mhz == CPUFREQ_VAL_UNKNOWN)
+ CF_DEBUG(unknown max frequency for %s\n,
+ device_get_nameunit(dev));
/*
* Only initialize one set of sysctls for all CPUs. In the future,
@@ -1001,7 +1006,9 @@ int
cpufreq_register(device_t dev)
{
struct cpufreq_softc *sc;
+ struct cf_setting *sets;
device_t cf_dev, cpu_dev;
+ int error, max, set_count, type;
/* Add a sysctl to get each driver's settings separately. */
SYSCTL_ADD_PROC(device_get_sysctl_ctx(dev),
@@ -1009,14 +1016,29 @@ cpufreq_register(device_t dev)
OID_AUTO, freq_settings, CTLTYPE_STRING | CTLFLAG_RD, dev, 0,
cpufreq_settings_sysctl, A, CPU frequency driver settings);
+ /* Get settings from the device and find maximum if possible. */
+ max = CPUFREQ_VAL_UNKNOWN;
+ if (CPUFREQ_DRV_TYPE(dev, type) == 0
+ (type CPUFREQ_TYPE_MASK) == CPUFREQ_TYPE_ABSOLUTE) {
+ set_count = MAX_SETTINGS;
+ sets = malloc(set_count * sizeof(*sets), M_TEMP, M_NOWAIT);
+ if (sets != NULL) {
+ if (CPUFREQ_DRV_SETTINGS(dev, sets, set_count) == 0
+ set_count 0)
+ max = sets[0].freq;
+ free(sets, M_TEMP);
+ }
+ }
+
/*
* Add only one cpufreq device to each CPU. Currently, all CPUs
* must offer the same levels and be switched at the same time.
*/
cpu_dev = device_get_parent(dev);
- if ((cf_dev = device_find_child(cpu_dev, cpufreq, -1))) {
+ cf_dev = device_find_child(cpu_dev, cpufreq, -1);
+ if (cf_dev != NULL) {
sc = device_get_softc(cf_dev);
- sc-max_mhz = CPUFREQ_VAL_UNKNOWN;
+ sc-max_mhz = max;
return (0);
}
@@ -1025,8 +1047,12 @@ cpufreq_register(device_t dev)
if (cf_dev == NULL)
return (ENOMEM);
device_quiet(cf_dev);
-
- return (device_probe_and_attach(cf_dev));
+ error = device_probe(cf_dev);
+ if (error != 0)
+ return (error);
+ sc = device_get_softc(cf_dev);
+ sc-max_mhz = max;
+ return (device_attach(cf_dev));
}
int
___
Re: powernow regression in 8-STABLE
On 20Jul11 19:28, Jung-uk Kim wrote: }From your dmesg output, I see that the processor speed was not }calibrated properly. ML-40's max. core freq. is 2,200 MHz according }to its specification but it was probed at 2,282 MHz, which is too }high. I think that's the problem. Can you please try the attached }patch? Yes, I have seen core freq wobble around for most of the time I've owned it, but usually close to 2200. This morning (with my reverted powernow.c) I had: dev.cpu.0.freq_levels: 3080/35000 2800/29000 2520/24000 2240/2 1120/9000 which I don't believe I've seen before. Anyway... With your new patch applied (and powernow.c changed back to r222148) I get exact freq levels: dev.cpu.0.freq_levels: 2200/35000 2000/29000 1800/24000 1600/2 800/9000 However, dev.cpu.0.freq OID is still missing from sysctl output. As another data point, with your new patch applied, but the old powernow.c, (which I booted into mistakenly first time), I did have dev.cpu.0.freq, but the freq levels weren't exact. Here is a new verbose boot output with a cleaned and built kernel, 8-STABLE as at time=1311028656 and your patch applied: http://members.optusnet.com.au/callumgibson/verboseboot2.out regards, Callum -- Callum Gibson @ home http://members.optusnet.com.au/callumgibson/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
