Re: Potential re(4) / netbsd-4 / i386 problem?
On 7/23/2010 12:54 PM, der Mouse wrote: Well, use machines whose designers cut corners on hardware design and guess what happens. Actually, my main reason for writing is to mention that I have a laptop, running 4.0.1, with an re onboard, and have never seen such random crashes. I can give more details if they matter. I've got 3 motherboards with re onboard that I've tested, 2 of the 3 have the problem. I checked the re hwrev and the one that works fine is 0x2800. The 2 boards that don't work have hwrev 0x3800 and 0x3C40. The board that's fine is a commercial Intel DG41MJ while the other 2 are both DFI industrial boards (LT600-DR, LT330-B).
Re: Potential re(4) / netbsd-4 / i386 problem?
Actually, my main reason for writing is to mention that I have a laptop, running 4.0.1, with an re onboard, and have never seen such random crashes. I can give more details if they matter. I've got 3 motherboards with re onboard that I've tested, 2 of the 3 have the problem. I checked the re hwrev and the one that works fine is 0x2800. The 2 boards that don't work have hwrev 0x3800 and 0x3C40. The board that's fine is a commercial Intel DG41MJ while the other 2 are both DFI industrial boards (LT600-DR, LT330-B). My laptop is a Sony Vaio (PCG-5G3L). The re is re0 at pci3 dev 0 function 0pci_mem_find: void region : RealTek 8100E/8101E PCIe 10/100BaseTX (rev. 0x01) re0: interrupting at ioapic0 pin 18 (irq 7) re0: Ethernet address 00:13:a9:f2:6f:af re0: using 256 tx descriptors rlphy0 at re0 phy 7: RTL8201L 10/100 media interface, rev. 1 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto I don't see anything there that looks like the rev numbers you're talking about. While now is not a good time, I'll have a look at the code and see if I can find the hwrev value you're talking about and print out its value for my hardware. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Potential re(4) / netbsd-4 / i386 problem?
On 7/26/2010 8:50 AM, der Mouse wrote: I don't see anything there that looks like the rev numbers you're talking about. While now is not a good time, I'll have a look at the code and see if I can find the hwrev value you're talking about and print out its value for my hardware. I manually printed it out in re_attach in rtl8169.c. Thanks, Brad
Re: Modules loading modules?
On Sun Jul 25 2010 at 15:17:29 -0700, Paul Goyette wrote: On Mon, 26 Jul 2010, matthew green wrote: it seems to me the root problem is that module_mutex is held while calling into the module startup routines. thus, the right solution is to remove this requirement. Yes, that's what is needed. I'm far from convinced that's a good idea. First, it will probably make the module code a nightmare -- what happens when you have multiple interleaved loads, some of which fail at some point in their dependency stack, and let's just throw in a manual modunload to mix up things further. Second, and pretty much related to number one, it goes against one of the most fundamental principles of robust code: atomic actions. If modload-from-modcmd is found necessary, sounds more like a case for the infamous recursive lock. (no comment on the actual problem)
Re: RFC: device flavours
On Mon, Jul 26, 2010 at 08:25:10AM +0300, Jukka Ruohonen wrote: On Sun, Jul 25, 2010 at 09:22:53PM +, Quentin Garnier wrote: bridges (mostly on x86). An even older idea of mine is to finally see legacy devices listed in the ACPI tables attached to the PCI-ISA bridge where they logically belong, and device flavours can be used for that, too. I am not sure if I understand all of this, so bear with me. While this is the direction we should go, it seems to me that the long- That's a bold statement that I wouldn't have dared say :-) standing issues in ACPI-PCI-ISA are not so much where the legacy drivers actually logically attach, but that these, like majority of drivers on modern x86, should utilize the information from ACPI. Sure. The ISA_DIRECT_CONFIG() macro is a kludge to allow direct configuration on the ISA bus. I could have fetched Jared McNeill's old patch that implemented direct configuration of the legacy devices using that (and he and I would certainly have had a good laugh about it), but here it was simpler to simply have an acpinodebus and attach the driver under dev/acpi. But here you get into autoconf(9) issues that are outside the scope of this thread. My long standing opinion is that drivers should have the possibility to have both a probe function (for indirect configuration) and a match function (for direct configuration). And even when you have that, at what point should the ACPI resources be decoded? The driver itself could still do it, in which case it wouldn't really be different from the current situation. Is this possible with flavours? Will the siblings still require a stub on the ACPI side of things? I think it is an orthogonal issue. The point of the flavours here for ACPI was to allow mixing the features without invading the *pcib drivers. pcib0 at pci0 dev 31 function 0: vendor 0x8086 product 0x27b9 (rev. 0x02) timecounter: Timecounter pcib0/ichlpc frequency 3579545 Hz quality 1000 pcib0/ichlpc: 24-bit timer pcib0/ichlpc: TCO (watchdog) timer configured. gpio5 at pcib0: 64 pins pcib0/acpiib: ACPI node SBRG npx1 at pcib0 (COPR, PNP0C04): io 0xf0-0xff irq 13 npx1: reported by CPUID; using exception 16 SIOR (PNP0C02) at pcib0 not configured RMSC (PNP0C02) at pcib0 not configured OMSC (PNP0C02) at pcib0 not configured In the above example it is known that the LPC bridge currently conflicts with the ACPI PM registers. So to put this to the logical end, the derivation using ACPI should start from there, and the pci_mapreg_map(9) call therein should use the information supplied by ACPI. That's entirely possible, and it is the kind of reasons why I have the pre-attach call to the flavours. The fact that the main driver doesn't have to know about the flavours doesn't mean they can't communicate, and for instance the flavour can set a device property. There are other situations in which I think device flavours could bring clarity and also better modularisation. For instance, support for CPU features on x86 like EST or PowerNow, or even ACPI P-states could be done that way, and it is more module-friendly because it wouldn't require the main CPU driver to explicitely call those feature-drivers. Here I can see use. I was actually seeking this kind of granularity with the ACPI CPU. Well, I'm sure you know how I feel about having a cpu(4) object somewhere in the device tree and an acpicpu(4) object somewhere else. -- Quentin Garnier - c...@cubidou.net - c...@netbsd.org See the look on my face from staying too long in one place [...] every time the morning breaks I know I'm closer to falling KT Tunstall, Saving My Face, Drastic Fantastic, 2007. pgpMIxGKpxIXO.pgp Description: PGP signature
Re: envsys issues [was Re: envstat wrong: who's at fault?]
On Mon, 26 Jul 2010, der Mouse wrote:
[moved from port-i386]
[me]
In passing, would it be appropriate and/or useful to suggest
improvements to [the envsys(4)] API? When I was writing code, I
found the envsys(4) ioctls to be deficient for my purposes.
[Paul Goyette]
I'd be interested in knowing in which ways you found the current API
lacking. [...]
Well, some things are underdocumented. For example, it seems that most
sensors are not in the units specified by envsys_tre_data_t.units, but
rather in 1e-6 of that unit - for example ENVSYS_SWATTHOUR sensors are
not in watthours but in microwatthours - and, as far as I've been able
to find, this factor of 1e6 is not documented anywhere but the source
to envstat(8). Except for temperature, which is specifically said to
be in microKelvins. But others are said to be in volts, amps, etc. To
quote both the envsys(4) and sys/envsys.h,
union { /* all data is given */
uint32_t data_us; /* in microKelvins, */
int32_t data_s; /* rpms, volts, amps, */
} cur, min, max, avg; /* ohms, watts, etc */
/* see units below */
This is greatly cleaned up in the envsysV2 implementation.
If the micro is supposed to apply to all those units, not just
Kelvins, then (a) rpms needs to be removed from the list and (b) the
wording needs to be improved.
But the one piece I've found so far that isn't just a lack of
documentation (well, unless there are totally undocumented calls) is
that there's no way to fetch multiple sensors' values without potential
for skew between them.. For example, to quote from the code I've been
developing,
In envsysV2, a single call is used to retrieve the whole set of sensors
(in a prop dictionary) so you don't need to worry about skew caused by
userland sampling. Of course, there is still the possibility of skew
caused by the driver's need to fiddle with hardware registers.
-
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer | | pgoyette at netbsd.org |
-
Re: envsys issues [was Re: envstat wrong: who's at fault?]
[...] This is greatly cleaned up in the envsysV2 implementation. [...] In envsysV2, a single call is used [...] Then there's not really anything to discuss, because it's all already been fixed. Excellent. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: RFC: device flavours
On Sun, Jul 25, 2010 at 09:22:53PM +, Quentin Garnier wrote: Hi all, I'm looking for comments about what I call device flavours. The best example of the kind of situation it tries to be an answer for is the multiplicity of drivers one can find around the source tree for PCI-ISA bridges (mostly on x86). An even older idea of mine is to finally see legacy devices listed in the ACPI tables attached to the PCI-ISA bridge where they logically belong, and device flavours can be used for that, too. Here's an exerpt of the dmesg output I get on my EeeBox, with two flavours defined, ichlpc (to replace ichlpcib(4)) and acpiib (to let legacy devices attach there; I've only let npx(4) attach though for the sake of the test): pcib0 at pci0 dev 31 function 0: vendor 0x8086 product 0x27b9 (rev. 0x02) timecounter: Timecounter pcib0/ichlpc frequency 3579545 Hz quality 1000 pcib0/ichlpc: 24-bit timer pcib0/ichlpc: TCO (watchdog) timer configured. gpio5 at pcib0: 64 pins pcib0/acpiib: ACPI node SBRG npx1 at pcib0 (COPR, PNP0C04): io 0xf0-0xff irq 13 npx1: reported by CPUID; using exception 16 SIOR (PNP0C02) at pcib0 not configured RMSC (PNP0C02) at pcib0 not configured OMSC (PNP0C02) at pcib0 not configured ISTM you can accomplish about the same thing and get the pmf(9) support for free with a slightly different approach: 0) Extract ISA direct configuration information from ACPI tables (and ISA Plug 'N' Play?) and stuff it somewhere that device_register(9) can get it. 1) Make device_register() attach ISA direct configuration information to each isa(4) instance as device properties. 2) Make isa(4) use direct configuration if the information is available in device properties. 3) Refactor ichlpcib0 and pcib0 so that you have ichlpc0 at pci0 dev 31 function 0: ... timecounter: Timecounter ichlpc0 frequency 3579545 Hz quality 1000 ichlpc0: 24-bit timer ichlpc0: TCO (watchdog) timer configured. pcib0 at ichlpc0: ... isa0 at pcib0: ... gpio5 at ichlpc0: 64 pins npx0 at isa0: ... ISTM that following such an approach, you get pmf(9) support and detachment virtually for free. Dave -- David Young OJC Technologies dyo...@ojctech.com Urbana, IL * (217) 278-3933
Re: RFC: device flavours
On Mon, Jul 26, 2010 at 06:27:55PM -0500, David Young wrote: On Sun, Jul 25, 2010 at 09:22:53PM +, Quentin Garnier wrote: Hi all, I'm looking for comments about what I call device flavours. The best example of the kind of situation it tries to be an answer for is the multiplicity of drivers one can find around the source tree for PCI-ISA bridges (mostly on x86). An even older idea of mine is to finally see legacy devices listed in the ACPI tables attached to the PCI-ISA bridge where they logically belong, and device flavours can be used for that, too. Here's an exerpt of the dmesg output I get on my EeeBox, with two flavours defined, ichlpc (to replace ichlpcib(4)) and acpiib (to let legacy devices attach there; I've only let npx(4) attach though for the sake of the test): pcib0 at pci0 dev 31 function 0: vendor 0x8086 product 0x27b9 (rev. 0x02) timecounter: Timecounter pcib0/ichlpc frequency 3579545 Hz quality 1000 pcib0/ichlpc: 24-bit timer pcib0/ichlpc: TCO (watchdog) timer configured. gpio5 at pcib0: 64 pins pcib0/acpiib: ACPI node SBRG npx1 at pcib0 (COPR, PNP0C04): io 0xf0-0xff irq 13 npx1: reported by CPUID; using exception 16 SIOR (PNP0C02) at pcib0 not configured RMSC (PNP0C02) at pcib0 not configured OMSC (PNP0C02) at pcib0 not configured ISTM you can accomplish about the same thing and get the pmf(9) support for free with a slightly different approach: 0) Extract ISA direct configuration information from ACPI tables (and ISA Plug 'N' Play?) and stuff it somewhere that device_register(9) can get it. 1) Make device_register() attach ISA direct configuration information to each isa(4) instance as device properties. 2) Make isa(4) use direct configuration if the information is available in device properties. 3) Refactor ichlpcib0 and pcib0 so that you have ichlpc0 at pci0 dev 31 function 0: ... timecounter: Timecounter ichlpc0 frequency 3579545 Hz quality 1000 ichlpc0: 24-bit timer ichlpc0: TCO (watchdog) timer configured. pcib0 at ichlpc0: ... isa0 at pcib0: ... gpio5 at ichlpc0: 64 pins npx0 at isa0: ... ISTM that following such an approach, you get pmf(9) support and detachment virtually for free. For free is a subjective thing. I don't think using device_register() --which is a MD callback--to pass information between two MI drivers is free. Nor the fact that you end up with three full devices in your tree when there is only one in the ACPI tree. You know, I've been there before: http://mail-index.netbsd.org/tech-kern/2005/11/11/0011.html And then Jared had his own approach a couple years later (which I'm not a big fan of, but still looks a lot nicer than using device_register()): http://mail-index.netbsd.org/tech-kern/2007/11/21/0010.html -- Quentin Garnier - c...@cubidou.net - c...@netbsd.org See the look on my face from staying too long in one place [...] every time the morning breaks I know I'm closer to falling KT Tunstall, Saving My Face, Drastic Fantastic, 2007. pgpCh5aNhRQm1.pgp Description: PGP signature
Re: Modules loading modules?
On Mon, 26 Jul 2010, der Mouse wrote: We have a modular device driver, let's call it xxxmod. [...] It [] might attempt to use an optional module (e.g., zzzverbose) to print some device attachment messages. First, a required module cannot be optional. If the desired module is not present, or if it is present but its own xxx_modcmd(MODULE_CMD_INIT, ...) fails, the failure is propagated back to the original outer call to module_load() which will also fail. The second reason why this is not suitable is that the outer load will add a reference to the module, preventing it from being auto-unloaded. Surely the right answer here is to provide a way to say refer to this module, but it's ok for its load to fail, and it's ok for it to get auto-unloaded, including passing up whatever information is necessary for the calling module to do something useful in failure cases? I actually considered adding a set of desired modules as well as the current required modules. That would certainly take care of the immediate problem with the xxx_verbose modules. But it doesn't address the need to have one module/driver loading another one for a child device, and it would be a maintenance nightmare to require updating the dependency-list every time a new child driver gets created. It really seems to me that the module system is there to help us, not to shackle us, and that if it has properties which are leading to problems, one of the options we should at the very least be considering is changing those properties. Yes, the current restriction appears to be burdensome. I'm just trying to get some consensus on that - so far I've seen only one negative opinion (from pooka@ IIRC). If we can agree that it's desirable for one module's xxx_modcmd() to load another module, then we can move to step 2 and figure out how to make it happen without breaking anything. If we don't get consensus, then I'll most likely need to revert the xxx_verbose modules. - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
