Re: Unexpected kernel device dependency for 'vga* at pci?'
Thanks for the explanation. It would seem to me that the vga console code should be separated from the rest of the vga driver. Then it would be rather easy to include the console code whenever vga or radeon or the Intel equivalent is configured. I've also noticed that even though no genfb is included in my config file, the generated file genfb.h sets NGENFB = 1, while the vga.h file contains NVGA = 0. Some how, this feels like a hack, in order to avoid making a similar split (console vs non-console) in the genfb code. Any way, thanks for all of the extra eyes looking at this, and all the explanations. At least now I know why I need the vga driver, even if I'd prefer to omit it. On Sun, 10 Jul 2016, Michael van Elst wrote: k...@munnari.oz.au (Robert Elz) writes: | While doing this, I've discovered that a radeondrmkmsfb0-based kernel | requires that I retain the | vga* at pci? dev ? func ? | line in the configuration, even though no such device is ever attached. The VGA driver is used very early as a console, this happens before autoconf and before the driver is really attached. For this you only need the VGA driver included in the kernel. The kernel would panic without the vga driver on conventional hardware, but there is a bug in the code. If the VGA driver is included, the radeon code will detach and reattach it as a console. When the VGA driver is not included, nothing like that happens, and the VGA hardware probably isn't mapped anywhere. In my (intel, not radeon) driver I detach the VGA console #if NVGA > 0 iaa.iaa_console = vga_cndetach() ? true : false; #else iaa.iaa_console = false; #endif and then map the hardware and attach a wsdisplay as if no VGA driver had existed. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree." !DSPAM:578273e731621319712218! +--+--++ | 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: Unexpected kernel device dependency for 'vga* at pci?'
k...@munnari.oz.au (Robert Elz) writes: >And as I (kind of said) I never actually tried a config with the "vga* at pci?" >config included but the wsdisplay* at vga? console ?" omitted, it was both >or neither for me (just the way it worked out.) Initially VGA gets attached as console. This has nothing to do with the config file. It's in the MD consinit() code. This also attaches an initial wsdisplay screen. Later VGA may attach at PCI. This provides the regular attachment and takes over the initial console screen. Later VGA may attach at ISA. This fails if there is already a PCI attachment because the hardware is already mapped and cannot be mapped again. If there is a radeon driver, it will take priority over the PCI attachment. No VGA attaches here but VGA is still the console. Then it gets a bit kludgy -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Unexpected kernel device dependency for 'vga* at pci?'
k...@munnari.oz.au (Robert Elz) writes: > | While doing this, I've discovered that a radeondrmkmsfb0-based kernel > | requires that I retain the > | vga* at pci? dev ? func ? > | line in the configuration, even though no such device is ever attached. The VGA driver is used very early as a console, this happens before autoconf and before the driver is really attached. For this you only need the VGA driver included in the kernel. The kernel would panic without the vga driver on conventional hardware, but there is a bug in the code. If the VGA driver is included, the radeon code will detach and reattach it as a console. When the VGA driver is not included, nothing like that happens, and the VGA hardware probably isn't mapped anywhere. In my (intel, not radeon) driver I detach the VGA console #if NVGA > 0 iaa.iaa_console = vga_cndetach() ? true : false; #else iaa.iaa_console = false; #endif and then map the hardware and attach a wsdisplay as if no VGA driver had existed. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Unexpected kernel device dependency for 'vga* at pci?'
Date:Sun, 10 Jul 2016 08:32:24 +0800 (PHT) From:Paul Goyette <p...@whooppee.com> Message-ID: <pine.neb.4.64.1607100828130.12...@pokey.whooppee.com> | "Common" yes, but they should not be normal. The whole point of the | config(1) mess is to be able to properly specify dependencies. Well, really, the point was to make it easier to build the config files, that before config(1 or 8) appeared used to be built by hand. Adding forms of dependency handling has been a more recent add on - and config files have (since I first saw one I think) never been "anything goes" - there have always been "of course if you config X you also need Y" type stuff (apart from the obvious ones that config itself complains about if you mess up, like a device at pci, and no pci at anything). | As I indicated in a follow-up Email, I still need to include a | | vga* at pci? dev ? func ? | | to avoid a compiler error. But I have already removed the | | wsdisplay* at vga? console ? | | line. The only wsdisplay line I currently have is | | wsdisplay* at radeondrmkmsfb0 That's interesting, I don't have that (or anything like it) in my config at all - not even commented out. What I have is (aside from the "at vga?" line) is ... wsdisplay* at wsemuldisplaydev? That one seems to be enough for the kernel to config ... wsdisplay0 at intelfb0 kbdmux 1: console (default, vt100 emulation) The other related config that I have are ... i915drmkms* at pci? dev ? function ? intelfb*at intelfbbus? | which, according to the dmesg, is where it actually gets attached! which is what gets attached in my case. I assume one of the files files has something that makes an intelfb attach a wsemuldisplaydev, or that the latter is some kind of macro device for the various fb devices. But I am just guessing... And as I (kind of said) I never actually tried a config with the "vga* at pci?" config included but the wsdisplay* at vga? console ?" omitted, it was both or neither for me (just the way it worked out.) kre
Re: Unexpected kernel device dependency for 'vga* at pci?'
On Sun, 10 Jul 2016, Robert Elz wrote: Date:Sun, 10 Jul 2016 07:00:11 +0800 (PHT) From:Paul Goyette <p...@whooppee.com> Message-ID: <pine.neb.4.64.1607100643520@pokey.whooppee.com> | While doing this, I've discovered that a radeondrmkmsfb0-based kernel | requires that I retain the | | vga* at pci? dev ? func ? | | line in the configuration, even though no such device is ever attached. I saw the exact same problem a month or so ago, but with a system using integrated intel graphics (core i3 processor). I didn't bother to mention it as config file inter-dependencies and weirdness are just "normal" ... "Common" yes, but they should not be normal. The whole point of the config(1) mess is to be able to properly specify dependencies. I think I concluded/assumed that the issue may have really related to the wsdisplay* at vga? console ? line that also had to be deleted (there being no vga? at anything left in the config - or in the console messages on a GENERIC boot) leaving nothing marked as "console" - whether that's actually true or not I didn't bother to find out - I put that entry back, and so had to also return the vga? at .. config, and after that, it all worked. As I indicated in a follow-up Email, I still need to include a vga* at pci? dev ? func ? to avoid a compiler error. But I have already removed the wsdisplay* at vga? console ? line. The only wsdisplay line I currently have is wsdisplay* at radeondrmkmsfb0 which, according to the dmesg, is where it actually gets attached! +--+--++ | 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: Unexpected kernel device dependency for 'vga* at pci?'
Date:Sun, 10 Jul 2016 07:00:11 +0800 (PHT) From:Paul Goyette <p...@whooppee.com> Message-ID: <pine.neb.4.64.1607100643520@pokey.whooppee.com> | While doing this, I've discovered that a radeondrmkmsfb0-based kernel | requires that I retain the | | vga* at pci? dev ? func ? | | line in the configuration, even though no such device is ever attached. I saw the exact same problem a month or so ago, but with a system using integrated intel graphics (core i3 processor). I didn't bother to mention it as config file inter-dependencies and weirdness are just "normal" ... I think I concluded/assumed that the issue may have really related to the wsdisplay* at vga? console ? line that also had to be deleted (there being no vga? at anything left in the config - or in the console messages on a GENERIC boot) leaving nothing marked as "console" - whether that's actually true or not I didn't bother to find out - I put that entry back, and so had to also return the vga? at .. config, and after that, it all worked. When it wasn't working, the symptoms were as you described (though I probably did less tests.) kre
Unexpected kernel device dependency for 'vga* at pci?'
I've been getting a new (well, new-to-me!) system up and running, and one of my usual steps is to build a minimal kernel. Starting with a GENERIC kernel and its dmesg(8) output, I remove all the device drivers that I don't need/use/want, and hard-wire most of the others. While doing this, I've discovered that a radeondrmkmsfb0-based kernel requires that I retain the vga* at pci? dev ? func ? line in the configuration, even though no such device is ever attached. If I remove that config line, the kernel will still build and link, but when booting the resulting kernel it fails. The system starts to come up normally, but at the point where it would normally "change the display mode" (from large-font to tiny-font) the screen just goes blank. When it "returns" the display is totally blank (except for the small, non-blinking cursor) and the system is hung. It's not just a "display failure" since blind typing doesn't do anything, either. (I boot in single-user, so either ddb should accept a reboot command, or init should access a "return for /bin/sh" followed by a reboot command!) I'm guessing that somewhere in the radeon code there's some .ifdef'd code that calls some common vga routine(s) if available. (I suspect it might be related to VGA_POST, but have no evidence to support.) It seems to me that, if the radeon code needs something from the vga driver, some sort of proper dependency should be used. Perhaps the "common vga routines" should be extracted into a separate file which can be required by both vga and radeon drivers, or the radeon driver can be dependent on the vga driver? The dmesg of the system in question is attached in case anyone wants to look at this more closely. +--+--++ | 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 | +--+--++Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016 The NetBSD Foundation, Inc. All rights reserved. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. NetBSD 7.99.33 (TEST 2016-07-07 22:19:31) #7: Sun Jul 10 05:35:20 PHT 2016 p...@pokey.whooppee.com:/build/netbsd-local/obj/amd64/sys/arch/amd64/compile/TEST total memory = 7613 MB avail memory = 7378 MB timecounter: Timecounters tick every 10.000 msec timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100 Gateway SX2185 () mainbus0 (root) ACPI: RSDP 0x000F0490 24 (v02 ACRSYS) ACPI: XSDT 0x9CC0C080 7C (v01 ACRSYS ACRPRDCT 01072009 AMI 00010013) ACPI: FACP 0x9CC12698 00010C (v05 ACRSYS ACRPRDCT 01072009 AMI 00010013) ACPI BIOS Warning (bug): Optional FADT field Pm2ControlBlock has valid Length but zero Address: 0x/0x1 (20160422/tbfadt-684) ACPI: DSDT 0x9CC0C188 00650D (v02 ACRSYS ACRPRDCT INTL 20051117) ACPI: FACS 0x9D0D3080 40 ACPI: APIC 0x9CC127A8 7E (v03 ACRSYS ACRPRDCT 01072009 AMI 00010013) ACPI: FPDT 0x9CC12828 44 (v01 ACRSYS ACRPRDCT 01072009 AMI 00010013) ACPI: MCFG 0x9CC12870 3C (v01 ACRSYS ACRPRDCT 01072009 MSFT 00010013) ACPI: MSDM 0x9CC128B0 55 (v03 ACRSYS ACRPRDCT 01072009 AMI 00010013) ACPI: HPET 0x9CC12908 38 (v01 ACRSYS ACRPRDCT 01072009 AMI 0005) ACPI: SSDT 0x9CC12940 0005E0 (v01 AMDAGESA0001 AMD 0001) ACPI: SSDT 0x9CC12F20 0046B7 (v02 AMDAGESA0002 MSFT 0400) ACPI: CRAT 0x9CC175D8 000278 (v01 AMDAGESA0001 AMD 0001) ACPI: SSDT 0x9CC17850 2B (v01 AMDCPMXPRES 0001 INTL 20051117) ACPI: SSDT 0x9CC17880 0010E8 (v01 AMDCPMCMN 0001 INTL 20051117) ACPI: Executed 1 blocks of module-level executable AML code ACPI: 5 ACPI AML tables successfully acquired and loaded ioapic0 at mainbus0 apid 3: pa 0xfec0, version 0x21, 24 pins ioapic1 at mainbus0 apid 4: pa 0xfec01000, version 0x21, 32 pins cpu0 at mainbus0 apid 0 cpu0: AMD E1-2500 APU with Radeon(TM) HD Graphics, id 0x700f01 cpu1 at mainbus0 apid 1 cpu1: AMD E1-2500 APU with Radeon(TM) HD Graphics, id 0x700f01 acpi0 at mainbus0: Intel ACPICA 20160422 acpi0: X/RSDT: OemId <ACRSYS,ACRPRDCT,01072009>, AslId acpi0: MCFG: segment 0, bus 0-255, address 0xe000 acpi0: SCI interrupting at int 9 timecounter: Timecounter "ACPI-Fast" frequency 3579545 Hz quality 1000 AMDN (PNP0C01) at acpi0 not configured BROD (PNP0C02) at acpi0 not configured SIO1 (PNP0C02) at acpi0 not configured NBRM
no vga* at pci?
If I configure a (amd64, 7.0) kernel with no vga* at pci? then it fails to boot (properly). This is despite the fact that no "vga at pci" ever seems to get configured (so it is unneeded). Instead, I have acpivga0 at acpi0 (OVGA): ACPI Display Adapter What happens is rather strange. After the kernel is loaded, the copyright message does not appear. After a few moments the screen is however switched to graphics mode and the text that happens to be on-screen is converted to it. The colour is however not the usual green but something fairly dark and hardly visible. The caps-lock led reacts. One could think that the kernel is continuing with the boot process but without further feedback, but waiting a while never results in being able to log in with ssh. Any idea why vga is more important than it seems to be? -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' signature.asc Description: PGP signature
Re: no vga* at pci?
rhia...@falu.nl (Rhialto) writes: >If I configure a (amd64, 7.0) kernel with >no vga* at pci? >then it fails to boot (properly). It probably fails to establish a console. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: no vga* at pci?
2015-12-02 23:37 GMT+01:00 Rhialto: > Any idea why vga is more important than it seems to be? Sounds as bothersome as the need to use a "LEGACY" kernel when you have vga@isa... Felix