re: spkr vs spkr_synth module
FWIW, pcppi is *not* x86 specific. the module might only be built there today, but that's a build artifact not a code fact. it should probably be built for "all isa" platforms. whatever those are. ideally. .mrg.
re: spkr vs spkr_synth module
On Sat, 10 Dec 2016, matthew green wrote: FWIW, pcppi is *not* x86 specific. the module might only be built there today, but that's a build artifact not a code fact. it should probably be built for "all isa" platforms. whatever those are. ideally. Yeah. Too bad we don't have the ability to enumerate the set of "all platforms". We have the same issue with building pci driver modules for only those platforms that have pci ... +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | +--+--++
spkr vs spkr_synth module
I'm not sure if it's really correct to have the modules/spkr_synth.kmod file contain a module named "spkr". It makes the modload/modunload asymmetrical (modload spkr_synth vs modunload spkr), and makes it hard to determine, from the output of modstat(8), which module is actually loaded. I'm tempted to rearrange things, but I'm concerned about potential confusion. 1. Rename i386/amd64-only spkr module to spkr_pcppi and adjust the module name accordingly. 2. Rename spkr_synch module to spkr (leaving the module name alone). 3. Leave the device-autoload stuff alone, so the default will be to autoload the audio-based spkr module! 4. Add spkr, and mark spkr_synth obsolete in the modules/mi sets list; in the i384 and amd64 sets lists, rename spkr --> spkr_pcppi (do NOT mark the old spkr entry as "obsolete" since it will still exist based on the mi file). 5. If someone really wants to use the spkr_pcppi module, they will need to manually load, or include it in the kernel config (and remove spkr_synth). Thoughts? +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | +--+--++
Re: EFI native support on amd64
Kimihiro Nonaka wrote: > I updated the patches. It works great. Some observations: - When the kernel starts booting, it prints lines painfully slow on my Asus laptop. When the kernel initialises genfb(4), printing suddenly speeds up. If I connect to Sony TV via HDMI, it somewhat slow but acceptable. - I can't figure out how to change screen size in boot.cfg. Adding text=2 to boot.cfg doesn't work. - Likewise, I don't know how to change screen size in genfb(4). I will google more on the topic. - Does the bootloader suport msdos fs? Currently, I create an ffs partition solely for hosting boot.cfg file. It would be nice to read boot.cfg file from the boot EFI partition. Alex
re: x86: move the LAPIC va
these CPUs clearly aren't rare and the assertion that it's only old CPUs and ones without lapic is questionable. i see this problem on a pentium4-m system. this change needs to be fixed or reverted. .mrg.
Re: x86: move the LAPIC va
Le 25/11/2016 à 15:38, Maxime Villard a écrit : > I've committed the patch, but without the push/pop before iret. As I said in > the comment, the ddb ipi triggers a hardware context switch, so in fact we > don't care about overwriting %ebx before iret. > > As a general rule, and for the record: normally we should never have to worry > about the state of the registers upon exit when modifying an isr. If we had > to, > it would mean that there is already a problem. > > Now that it is committed, if someone here sees a regression, a panic or > whatever, please report it to me. > > (and thanks for the review) > My change apparently causes CPUs that have no LAPIC to crash [1] [2]. The reason is that our x86 implementation relies a lot on it and always uses the va of the LAPIC, even when it is not there. The cpus that don't have a lapic are quite old, apparently before i486. I'm not sure whether so far we have been using the va on those precisely because we didn't care about writing to it for no reason, or if it has always been an age-old bug that I just happen to have unearthed. When it comes to [2], I'm not even sure if the cpu has at least a 82489DX, and if it implies that somehow the kernel does not properly detect it. Clearly, given how rare these CPUs are, I am not going to develop a special support for them - I wouldn't be able to test it anyway. My initial intention was to always kenter the va to a fake pa on i386 [3], just to reproduce the old behavior and rehide the bug. But now I'm wondering whether someone has a better idea, or if we simply don't care about that kind of cpu anymore. [1] http://mail-index.netbsd.org/current-users/2016/11/30/msg030542.html [2] http://mail-index.netbsd.org/port-i386/2016/12/07/msg003561.html [3] http://m00nbsd.net/garbage/lapic/nolapic.diff
