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/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: Modules loading modules?
On Mon, Jul 26, 2010 at 06:41:11AM +1000, matthew green wrote: > it seems to me the root problem is that module_mutex is held while > calling into the module startup routines. Here is one related question: is it ensured that the module lock is dropped immediately after a modular device driver returns from its attachment routine? I am thinking of a case where a modular driver defers its configuration by using config_interrupts(9) or config_finalize_register(9). - Jukka.
Re: RFC: device flavours
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- 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. Is this possible with flavours? Will the siblings still require a stub on the ACPI side of things? > 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. > 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. - Jukka.
Re: RFC: device flavours
On Sun, Jul 25, 2010 at 05:54:01PM -0400, der Mouse wrote: > > I'm looking for comments about what I call "device flavours". [...] > > I'm having trouble seeing what this offers over things (like scsibus) > where an abstraction attaches at real hardware and then other things > attach to the abstraction. It seems to me that scsibus serves a different purpose, but yes, it is surely possible to achieve similar results using the current autoconf(9) and probably abusing it in various ways. > > flavour acpiib at pci: acpinodebus > > filedev/acpi/acpiib.c acpiib > > > > flavour ichlpc at pci: acpipmtimer, sysmon_wdog, fwhichbus, hpetichbus, gp= > > iobus > > filearch/x86/pci/ichlpc.c ichlpc > > > flavours ichlpc, acpiib > > npx*at pcib? > > gpio* at gpiobus? > > > I've been wondering about simply allowing more than one driver to > > attach to a device, > > It seems to me that we already have something effectively the same as > that, mediated by a "controller" driver. For example, consider the > way, on sparc, zs attaches to the chip and then zstty or kbd or ms > attaches to zs (or at least that's how it used to work). The interaction between zs and zstty looks to me like plain regular direct configuration, with zs enumerating features. > You write that > > > But the main point is that a flavour can be created without the main > > driver being aware of it; > > but, again, it looks to me as though we already have that: to return to > the zs example, the zs code does not need to know anything about the > list "zstty, kbd, ms" in order for those child devices to work. It has to know the features (and yes, calling them devices would be somewhat incorrect) exist, even if it doesn't know their purpose. > But I feel certain you are already familiar with all that. So I must > be missing something. What? My explanations are certainly most unclear; I think the point of the flavours is to add a bit of indirect configuration over a direct configuration bus. The way I understand zs(4) works, the zs device serves as an enumerator of a list of features. The intended purpose of the flavours is indeed to push that kind of behaviour back into the configuration framework. Now, I don't think they're entirely swapable, especially not in the example I give. Part of the difference between zs(4) and the pcib(4) case is that in the former case, the features are not terribly different from one another, or at least not different enough to warrant a different interface attribute. In the pcib(4) case, the features are logically at complete odds, and having them as children enumerated by a "controller" pcib driver would mean pushing a lot of knowledge about they work into said controller driver. With the flavours, pcib(4) doesn't have to do anything but attach the isa(4) bus. Does that clear things a little? -- 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. pgpcfPxnNySo1.pgp Description: PGP signature
re: Modules loading modules?
> 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. > > But it sounds a lot simpler than it is. oh, i'm sure it's not trivial. :-( .mrg.
re: Modules loading modules?
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. But it sounds a lot simpler than it is. Among other issues, we'd need to ensure that we continue to detect circular dependencies between both sets of required modules. And, since we call the module startup routine for a required module _before_ we call it for the required module, we would need to release and then reacquire the mutex, all the while being sure that the data structures don't get changed out from under us. We would end up with something like this sequence,where module A requires A1 and A2, and module B requires B1 and B2, and hopefully (B1 != A && B2 != A) (which would be a hidden circular dependency). mutex_enter() load module A load required module A1 mutex_exit() call A1's init routine mutex_enter() load required module A2 mutex_exit() call A2's init routine mutex_enter() load module B load required module B1 mutex_exit() call B1's init routine mutex_enter() load required module B2 mutex_exit() call B2's init routine mutex_enter() mutex_exit() call B's init routine mutex_enter() mutex_exit() mutex_enter() mutex_exit() call A's init routine mutex_enter() mutex_exit() - | 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: RFC: device flavours
> I'm looking for comments about what I call "device flavours". [...] I'm having trouble seeing what this offers over things (like scsibus) where an abstraction attaches at real hardware and then other things attach to the abstraction. > flavour acpiib at pci: acpinodebus > filedev/acpi/acpiib.c acpiib > > flavour ichlpc at pci: acpipmtimer, sysmon_wdog, fwhichbus, hpetichbus, gp= > iobus > filearch/x86/pci/ichlpc.c ichlpc > flavours ichlpc, acpiib > npx*at pcib? > gpio* at gpiobus? > I've been wondering about simply allowing more than one driver to > attach to a device, It seems to me that we already have something effectively the same as that, mediated by a "controller" driver. For example, consider the way, on sparc, zs attaches to the chip and then zstty or kbd or ms attaches to zs (or at least that's how it used to work). You write that > But the main point is that a flavour can be created without the main > driver being aware of it; but, again, it looks to me as though we already have that: to return to the zs example, the zs code does not need to know anything about the list "zstty, kbd, ms" in order for those child devices to work. But I feel certain you are already familiar with all that. So I must be missing something. What? /~\ 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
RFC: device flavours
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 A device flavour is essentially an incomplete device driver. That means it will never be active unless a driver has already attached to a device. But the main point is that a flavour can be created without the main driver being aware of it; additionally, a flavour gets its own device_t and thus can interact on its own with any subsystem that uses device_t, mostly pmf(9). (And, as you can see in the example, aprint_*_dev functions.) On the config(5) side, a device flavour is defined as something that attaches to an interface attribute. The reason for that is of course that there is no need for it to assume the name of the main driver to function properly. So, in my files.* I have defined the following: flavour acpiib at pci: acpinodebus filedev/acpi/acpiib.c acpiib flavour ichlpc at pci: acpipmtimer, sysmon_wdog, fwhichbus, hpetichbus, gpiobus filearch/x86/pci/ichlpc.c ichlpc And then in my kernel config file I added the following: flavours ichlpc, acpiib npx*at pcib? gpio* at gpiobus? (The last two lines are there only to explain the attachments in the example.) At run time, I am only going to describe what happens at attachment time, because I haven't done anything about detach yet. When a device is *found* (i.e., once its device_t has been created and linked) using the interface attribute "pci", the match functions of all flavours of the pci interface attribute are called, and for each that returns non-zero, a device_t object is created using the name "device/flavour" and add to the "parent" device_t's list of flavours. Then when what is really a sibling driver is attached, a call is made the the flavour's callback. In my proof-of-concept code I added a call right before the main driver is attached, and another one right after, because there might be situations where either is needed (and typically for a flavour that enumerates children, it might prefer doing it before the main driver gets a chance to do it). For reference, my current patch: http://taryn.cubidou.net/~cube/flavours.diff Again, it is a proof of concept; detaching is not handled, so the kernel will fail to reboot, and there is no locking whatsoever, so Bad Things could happen. 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. I've been wondering about simply allowing more than one driver to attach to a device, and while this might be a lot simpler as far as config(1) and even autoconf(9) are concerned, it raises other issues, like how to deal with device_t's. One thing I'd like to get input on anyway is how to actually deal with pmf(9). I haven't looked at it at all yet, but I don't really expect miracles for my current patch. -- 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. pgpt1CgG4YB9c.pgp Description: PGP signature
re: Modules loading modules?
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. .mrg.
Modules loading modules?
Consider the following scenario: We have a modular device driver, let's call it xxxmod. The driver's xxx_modcmd(MODULE_CMD_INIT, ...) routine handles all of its initialization, including interaction with autoconf(9). It therefore might attempt to use an optional module (e.g., zzzverbose) to print some device attachment messages. (Another possible scenario would be to have one modular driver xxxmod that calls config_found_xxx() which in turn requires another modular driver yyymod.) We have no problem if the zzzverbose module is already auto-loaded. But if the module is not present, or if it has already been auto- unloaded, the current code will call module_autoload() to attempt to (re)load it. Since this call happens in xxx_modcmd(), we end calling mutex_enter() while the mutex is still owned. There is currently a "requires" mechanism that allows recursion within the module loading process. But it doesn't quite solve the problem, for at least three reasons. 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. (A key benefit of having the xxx_verbose modules is that their large text tables can be unloaded.) A third reason that tends to make this option unuseable is the need to identify ahead of time all of the possible optional modules and maintain the dependency list. Adding a new driver would thus require updating the dependency list in the parent device's driver. Any suggestions on how to resolve this conundrum? Without a solution, the zzz_verbose modules and modularized drivers that might use the zzz_verbose modules cannot co-exist, and we won't be able to have modular drivers for devices whose children are served by other modular drivers. - | 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 | -
