From c-d.hailfinger.devel.2006 at gmx.net Sun Feb 1 13:30:57 2015 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sun, 01 Feb 2015 13:30:57 +0100 Subject: [coreboot] coreboot code of conduct In-Reply-To: <54BEE9E1.504@gmx.net> References: <54BB248A.4000300@gmx.net> <54BCF005.6000003@gmx.net> <16ee1bdd15c6779c90ff9cfca022f4c7@mail.georgi-clan.de> <54BEE9E1.504@gmx.net> Message-ID: <54CE1C81.5020101@gmx.net> Hi everyone, can we please put the Code of Conduct under some revision control? It seems patches are being ignored or getting lost. There are two possible solutions: Removing the lock on the wiki page or having the CoC in git/gerrit with automatic publishing. I'm fine with either solution. Regards, Carl-Daniel From kzer-za at cryptolab.net Sun Feb 1 19:12:05 2015 From: kzer-za at cryptolab.net (Kuba Kukielka) Date: Sun, 01 Feb 2015 18:12:05 +0000 Subject: [coreboot] Asus F2A85-M Message-ID: <54CE6C75.2030902@cryptolab.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, I was wanting to get a board that is compatible with coreboot and the Asus F2A85-M was the choice for me as it has DDR-3 RAM. But, after looking on the internet, the only board I could find was the PRO version, which is not supported. The wiki mentioned that it could be easily supported. After looking on the wiki, I found something talking about the CPUs. The only ones mentioned where: AMD Athlon X2 340 AMD Athlon X4 740 AMD Athlon X4 750k Are these the only ones supported? I own a AMD Athlon(tm) II X2 240 Processor so I don't know if it it compatible with this board. (I will need to upgrade it anyway but it would be nice if it was supported) Thanks, -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJUzmxtAAoJEI2NIwdfk/klRmUP/0OViwUuYdbZI6iGy8G3GFXh si1hewDg1ZP9VgkdG9jbRbq2ktY82tTNW3B5tqeiz+Bll5Cil4RamgmAX8V2vucx YS1wt0vqAMIORlDUCF32i5AsiG2XyTWRCoaLNBwpV32pkv9JtkaUF2IGuZHME71J TXWbk2h0lVxZ6lQyGIW5hMEmuM2nWKNXrBbVS6hr+32WP0OYiqIlsvUBJt47YmPr KZUNxGcfNwmWVo1hoZBJTB5EbAiQojasCANBGMH6vXkGXNHO2z8YkpH+6Yw0KbnG MS5mfuaMAEPfXx+ZZbQKguY7zjyTw0wI3sec6866tZz0575CwDTQSQKgD6y1nDrm AydD0Jhat7EdeWsowhmha1o2wllDv16DOpepcrC3R4Q3g83lNwzrImGzAIUJaDjC r1Fua8I7QBc6r30sN+hu1XXad6ghfq5c2IknYdOEaA7VQWMUvDI+6vztfl5E58Ii J9NDwfpBPrOFgXCtCqjtMX+uSf5xWNa3Au6gTn54mH25pSho6m4/BZnHSGtO8Rme qSw7KuVSb760gAcZgpEOdOUnlo9HJbd3xmmQl2P3etAvV5alOW4nNuYwKsmPGk5b ZTgPgEFIR7jfE1TiahuCoweW16R3u35hfNkNsD6yWQCPGpv6uuldf0GLOmgIzkH/ SvL+gV9WqhB7bLt0JjCr =mfxO -----END PGP SIGNATURE----- From mtjm at mtjm.eu Sun Feb 1 21:11:43 2015 From: mtjm at mtjm.eu (=?utf-8?Q?Micha=C5=82_Mas=C5=82owski?=) Date: Sun, 01 Feb 2015 21:11:43 +0100 Subject: [coreboot] Asus F2A85-M In-Reply-To: <54CE6C75.2030902@cryptolab.net> (Kuba Kukielka's message of "Sun, 01 Feb 2015 18:12:05 +0000") References: <54CE6C75.2030902@cryptolab.net> Message-ID: <87y4ohqtmo.fsf@mtjm.eu> Hello. > I was wanting to get a board that is compatible with coreboot and the > Asus F2A85-M was the choice for me as it has DDR-3 RAM. But, after > looking on the internet, the only board I could find was the PRO > version, which is not supported. The wiki mentioned that it could be > easily supported. F2A85-M LE is supported, while it might be more available than original F2A85-M. There is an in-progress port for PRO, probably without published code yet. > Are these the only ones supported? I own a AMD Athlon(tm) II X2 240 > Processor so I don't know if it it compatible with this board. (I will > need to upgrade it anyway but it would be nice if it was supported) Trinity APUs work, Richland needs changes in Kconfig and devicetree.cb. Athlon II X2 240 has a different socket: AM3, not FM2 used with F2A85-M. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From scott at notabs.org Mon Feb 2 04:40:56 2015 From: scott at notabs.org (Scott Duplichan) Date: Sun, 1 Feb 2015 21:40:56 -0600 Subject: [coreboot] AMD Mahogany Fam10 not booting Message-ID: <000001d03e9a$0f2dcd50$2d8967f0$@notabs.org> I found coreboot for AMD Mahogany Fam10 is no longer working. The problem starts with this change: http://www.coreboot.org/pipermail/coreboot-gerrit/2013-July/002391.html Some other older AMD boards are likely affected too. Here is a workaround: src/device/pci_ops.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/device/pci_ops.c b/src/device/pci_ops.c index 6ddb493..22bd0b1 100644 --- a/src/device/pci_ops.c +++ b/src/device/pci_ops.c @@ -27,7 +27,7 @@ const struct pci_bus_operations *pci_bus_default_ops(device_t dev) { -#if CONFIG_MMCONF_SUPPORT_DEFAULT +#if CONFIG_MMCONF_SUPPORT_DEFAULT && CONFIG_NORTHBRIDGE_AMD_AMDFAM10 == 0 return &pci_ops_mmconf; #else return &pci_cf8_conf1; -- The public version of AMD simnow (4.6.2) can boot Mahogany FAM10 coreboot using the included shiner model. But the following patch is needed to work around a simnow problem that exposes a coreboot problem: src/device/pci_device.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/src/device/pci_device.c b/src/device/pci_device.c index 8351e9c..c384877 100644 --- a/src/device/pci_device.c +++ b/src/device/pci_device.c @@ -228,6 +228,13 @@ struct resource *pci_get_resource(struct device *dev, unsigned long index) * This also catches the common case of unimplemented registers * that always read back as 0. */ + + // simnow workaround: clearing NB_BAR3_PCIEXP_ENABLE makes only the lower + // half of the BAR read-only, resulting in a memory BAR request for 4GB. + // coreboot does not support BARs of this size, and simnow boot fails. As + // a workaround, limit the BAR read-only check to the lower 32 bits. This + // causes memory BAR requests >= 4GB to be ignored. + moving &= 0xFFFFFFFF; if (moving == 0) { if (value != 0) { printk(BIOS_DEBUG, "%s register %02lx(%08lx), " Thanks, Scott From kyosti.malkki at gmail.com Mon Feb 2 06:30:57 2015 From: kyosti.malkki at gmail.com (=?ISO-8859-1?Q?Ky=F6sti_M=E4lkki?=) Date: Mon, 02 Feb 2015 07:30:57 +0200 Subject: [coreboot] AMD Mahogany Fam10 not booting In-Reply-To: <000001d03e9a$0f2dcd50$2d8967f0$@notabs.org> References: <000001d03e9a$0f2dcd50$2d8967f0$@notabs.org> Message-ID: <54CF0B91.30207@gmail.com> On 02/02/2015 05:40 AM, Scott Duplichan wrote: > I found coreboot for AMD Mahogany Fam10 is no longer working. The problem > starts with this change: > http://www.coreboot.org/pipermail/coreboot-gerrit/2013-July/002391.html > > Some other older AMD boards are likely affected too. Here is a workaround: > Hi Scott Known issue, I am sorry you had to bisect this one too in the lack of bug tracking. See: http://www.coreboot.org/pipermail/coreboot/2013-December/076813.html http://review.coreboot.org/#/c/4541/2 It would be great if you can help us to fix RS780 properly. We want to use MMCONF for PCI config access to avoid any concurrency problems with IO 0xcf8/0xcf9 index/data pair. Ky?sti From kuzmichevviktorv at gmail.com Mon Feb 2 11:33:48 2015 From: kuzmichevviktorv at gmail.com (Kuzmichev Viktor) Date: Mon, 02 Feb 2015 13:33:48 +0300 Subject: [coreboot] Mohon Peak, Memtest86+ does not start In-Reply-To: <54C85647.3030705@gmail.com> References: <54BE5897.5010909@gmail.com> <20150120193318.GA24909@coreboot.org> <54C1FBFC.10806@gmail.com> <54C78BAF.30309@gmail.com> <54C85647.3030705@gmail.com> Message-ID: <54CF528C.8070700@gmail.com> Hello, So, I've checked the memtest source files recently. And I guess, I was wrong when I thought that SeaBIOS should control serial IO. There is code in memtest (file named lib.c) that should handle serial input itself. I've added a debug message in the check_input() function and it seems like memtest just does not receive any input. Any suggestions? Viktor On 28.01.2015 06:23, Martin Roth wrote: > Hi Viktor, > I mentioned on the mailing list that Sage has done a read/write > implementation for SeaBIOS. You can find a copy of that SeaBIOS code > in the Gizmo BSP on this page: > http://www.gizmosphere.org/gizmoboard-support/resources/ > > Download the Gizmo BSP, extract it, and go to the > Gizmo_Reference/coreboot/payloads/seabios directory and run make > menuconfig. Enable 'Enable serial console to receive keystrokes'. > > This SeaBIOS tree is pretty out of date, but that's the feature you're > looking for. > > Hope this helps. > Martin > > On 01/27/2015 05:59 AM, Kuzmichev Viktor wrote: >> Thank you very much, this helped a lot! Now memtest is loading and it >> successfully performs RAM tests. >> But there is another issue. Somehow, input via serial console does >> not work. And it seems like the problem is not in memtest, rather >> it's in SeaBIOS or coreboot. There is no any prompt for input in >> coreboot. But there is in SeaBIOS, and I was not able to enter boot >> menu since it did not respond to F12. Although, SeaBIOS responds to >> the keyboard that is directly connected to the board while memtest >> does not seem to respond at all (at least, I tried to hit Esc which >> should reboot the board). >> I've tried to search for this but so far found nothing. >> Will appreciate any help. >> >> Viktor >> >> On 23.01.2015 18:47, Aaron Durbin wrote: >>> On Fri, Jan 23, 2015 at 1:45 AM, Kuzmichev Viktor >>> wrote: >>>> Hello Stefan, >>>> >>>> Thank you for the tip, I'm currently looking into that. But I'm >>>> still not >>>> sure how to specify the load address. My guess is that I should >>>> edit the >>>> linking script properly to do it. By default it looks as follows >>>> (memtest.lds): >>>> >>>> OUTPUT_FORMAT("elf32-i386"); >>>> OUTPUT_ARCH(i386); >>>> >>>> ENTRY(_start); >>>> SECTIONS { >>>> . = 0x10000; >>>> _start = . ; >>>> .data : { >>>> *(.data) >>>> } >>>> } >>>> >>>> And here is the output of 'readelf -a memtest' command: >>>> >>>> ELF Header: >>>> Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 >>>> Class: ELF32 >>>> Data: 2's complement, little endian >>>> Version: 1 (current) >>>> OS/ABI: UNIX - System V >>>> ABI Version: 0 >>>> Type: EXEC (Executable file) >>>> Machine: Intel 80386 >>>> Version: 0x1 >>>> Entry point address: 0x10000 >>>> Start of program headers: 52 (bytes into file) >>>> Start of section headers: 239496 (bytes into file) >>>> Flags: 0x0 >>>> Size of this header: 52 (bytes) >>>> Size of program headers: 32 (bytes) >>>> Number of program headers: 1 >>>> Size of section headers: 40 (bytes) >>>> Number of section headers: 3 >>>> Section header string table index: 2 >>>> >>>> Section Headers: >>>> [Nr] Name Type Addr Off Size ES >>>> Flg Lk >>>> Inf Al >>>> [ 0] NULL 00000000 000000 000000 >>>> 00 0 >>>> 0 0 >>>> [ 1] .data PROGBITS 00010000 010000 02a774 00 >>>> WA 0 0 >>>> 1 >>>> [ 2] .shstrtab STRTAB 00000000 03a774 000011 >>>> 00 0 >>>> 0 1 >>>> Key to Flags: >>>> W (write), A (alloc), X (execute), M (merge), S (strings) >>>> I (info), L (link order), G (group), T (TLS), E (exclude), x >>>> (unknown) >>>> O (extra OS processing required) o (OS specific), p (processor >>>> specific) >>>> >>>> There are no section groups in this file. >>>> >>>> Program Headers: >>>> Type Offset VirtAddr PhysAddr FileSiz MemSiz >>>> Flg Align >>>> LOAD 0x000000 0x00000000 0x00000000 0x3a774 0x3a774 RW >>>> 0x200000 >>>> >>>> Section to Segment mapping: >>>> Segment Sections... >>>> 00 .data >>>> >>>> There is no dynamic section in this file. >>>> >>>> There are no relocations in this file. >>>> >>>> The decoding of unwind sections for machine type Intel 80386 is not >>>> currently supported. >>>> >>>> No version information found in this file. >>>> >>>> So, the entry point is at the offset of 0x10000. But I think I should >>>> somehow change the 'VirtAddr'. I've tried to edit the script in >>>> different >>>> ways, for example, I've tried to add MEMORY command and then allocate >>>> certain sections to the regions as explained here: >>>> https://sourceware.org/binutils/docs/ld/REGION_005fALIAS.html#REGION_005fALIAS >>>> >>>> but haven't come to any success yet. >>>> >>>> Are there any advices you could give me? Am I even looking in the >>>> right >>>> direction? >>> Ya. You are on the right path. I just confirmed your findings locally. >>> What you'd like to see is VirtAddr/PhysAddr = 0x10000 as well as >>> offset to be 0x10000 because that would match with .data section. Also >>> notice that MemSiz is 0x10000 greater than the Size of the .data >>> section. So when this payload is loading all memory from 0x00000 to >>> 0x10000 is filled with zeros before the start of the program at >>> 0x10000. >>> >>> I poked around in trying to relink in different ways but it kept >>> loading at 0. You could hexedit the memtest elf file. Apparently there >>> is an 'ht editor' program. However, I couldn't for the life of me >>> figure it out, but I was able to make it coredump trying to figure out >>> how to navigate it. :/ >>> >>> But I just found this page: >>> http://dwarfdump.blogspot.com/2009/08/executable-file-editor-elf-editor.html >>> >>> >>> $ hte memtest >>> >>> >>> >>> Goto 'elf/program headers'. Hit >>> >>> Expand 'entry 0' with >>> Goto 'offset' >>> Hit . >>> Make 'offset', 'virtual address', 'physical address' all to 00010000 >>> Make 'in file size' and 'in memory size' 00027008. >>> >>> Hit to save. >>> Hit to quit. >>> >>> Those values were based on the memtest I compiled: >>> $ readelf -e memtest >>> ELF Header: >>> Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 >>> Class: ELF32 >>> Data: 2's complement, little endian >>> Version: 1 (current) >>> OS/ABI: UNIX - System V >>> ABI Version: 0 >>> Type: EXEC (Executable file) >>> Machine: Intel 80386 >>> Version: 0x1 >>> Entry point address: 0x10000 >>> Start of program headers: 52 (bytes into file) >>> Start of section headers: 225308 (bytes into file) >>> Flags: 0x0 >>> Size of this header: 52 (bytes) >>> Size of program headers: 32 (bytes) >>> Number of program headers: 1 >>> Size of section headers: 40 (bytes) >>> Number of section headers: 3 >>> Section header string table index: 2 >>> >>> Section Headers: >>> [Nr] Name Type Addr Off Size ES >>> Flg Lk Inf Al >>> [ 0] NULL 00000000 000000 000000 >>> 00 0 0 0 >>> [ 1] .data PROGBITS 00010000 010000 027008 00 >>> WA 0 0 1 >>> [ 2] .shstrtab STRTAB 00000000 037008 000011 >>> 00 0 0 1 >>> Key to Flags: >>> W (write), A (alloc), X (execute), M (merge), S (strings) >>> I (info), L (link order), G (group), T (TLS), E (exclude), x >>> (unknown) >>> O (extra OS processing required) o (OS specific), p (processor >>> specific) >>> >>> Program Headers: >>> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg >>> Align >>> LOAD 0x000000 0x00000000 0x00000000 0x37008 0x37008 RW >>> 0x200000 >>> >>> Section to Segment mapping: >>> Segment Sections... >>> 00 .data >>> >>> >>> After the instructions above I get the following: >>> >>> $ readelf -e memtest >>> ELF Header: >>> Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 >>> Class: ELF32 >>> Data: 2's complement, little endian >>> Version: 1 (current) >>> OS/ABI: UNIX - System V >>> ABI Version: 0 >>> Type: EXEC (Executable file) >>> Machine: Intel 80386 >>> Version: 0x1 >>> Entry point address: 0x10000 >>> Start of program headers: 52 (bytes into file) >>> Start of section headers: 225308 (bytes into file) >>> Flags: 0x0 >>> Size of this header: 52 (bytes) >>> Size of program headers: 32 (bytes) >>> Number of program headers: 1 >>> Size of section headers: 40 (bytes) >>> Number of section headers: 3 >>> Section header string table index: 2 >>> >>> Section Headers: >>> [Nr] Name Type Addr Off Size ES >>> Flg Lk Inf Al >>> [ 0] NULL 00000000 000000 000000 >>> 00 0 0 0 >>> [ 1] .data PROGBITS 00010000 010000 027008 00 >>> WA 0 0 1 >>> [ 2] .shstrtab STRTAB 00000000 037008 000011 >>> 00 0 0 1 >>> Key to Flags: >>> W (write), A (alloc), X (execute), M (merge), S (strings) >>> I (info), L (link order), G (group), T (TLS), E (exclude), x >>> (unknown) >>> O (extra OS processing required) o (OS specific), p (processor >>> specific) >>> >>> Program Headers: >>> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg >>> Align >>> LOAD 0x010000 0x00010000 0x00010000 0x27008 0x27008 RW >>> 0x200000 >>> >>> Section to Segment mapping: >>> Segment Sections... >>> 00 .data >>> >>> >>> Notice now that we're only loading the .data section at 0x10000. I >>> hope that helps. >>> >>>> Thanks in advance, >>>> Viktor >>>> >>>> >>>> On 20.01.2015 22:33, Stefan Reinauer wrote: >>>>> * Kuzmichev Viktor [150120 14:31]: >>>>>> Hello, >>>>>> >>>>>> I'm trying to load Memtest86+ on the Mohon Peak reference board from >>>>>> CBFS and it fails. >>>>>> My primary payload is SeaBIOS. Memtest is added using cbfstool, so >>>>>> the layout of my ROM file is as follows: >>>>>> >>>>>> $ ./build/cbfstool build/coreboot.rom print >>>>>> coreboot.rom: 8192 kB, bootblocksize 1024, romsize 8388608, offset >>>>>> 0x600000 >>>>>> alignment: 64 bytes, architecture: x86 >>>>>> >>>>>> Name Offset Type Size >>>>>> cmos_layout.bin 0x600000 cmos_layout 1352 >>>>>> fallback/romstage 0x600580 stage 26616 >>>>>> fallback/ramstage 0x606dc0 stage 60446 >>>>>> fallback/payload 0x615a40 payload 55799 >>>>>> config 0x623480 raw 4323 >>>>>> revision 0x6245c0 raw 714 >>>>>> img/Memtest86+ 0x6248c0 payload 225028 >>>>>> (empty) 0x65b800 null 1001368 >>>>>> mrc.cache 0x74ffc0 (unknown) 65536 >>>>>> cpu_microcode_blob.bin 0x760000 microcode 83968 >>>>>> (empty) 0x774840 null 46936 >>>>>> fsp.bin 0x77ffc0 (unknown) 372736 >>>>>> (empty) 0x7db000 null 150424 >>>>>> >>>>>> I've tried versions 4.20 and 5.01. Memtest86+ v4.20 just hangs, here >>>>>> is output of SeaBIOS trying to load it: >>>>>> Trying CBFS >>>>>> Booting from CBFS... >>>>>> Run img/Memtest86+ >>>>>> Segment 41544144 194420 at 0xffe24920 -> 194420 at 0x00000000 >>>>>> No compression >>>>>> >>>>>> And then nothing. Memtest86+ v5.01 goes a bit further, SeaBIOS finds >>>>>> its entry point: >>>>>> Trying CBFS >>>>>> Booting from CBFS... >>>>>> Run img/Memtest86+ >>>>>> Segment 41544144 224972 at 0xffe24920 -> 224972 at 0x00000000 >>>>>> No compression >>>>>> Calling addr 0x00010000 >>>>> It looks like in both cases memtest86+ is loaded at address >>>>> 0x00000000 >>>>> which will overwrite a bunch of memory, including the coreboot >>>>> tables. >>>>> Looks like the memtest86+ elf binary needs to specify a load address. >>>>> >>>>> Stefan >>>>> >>>> >>>> -- >>>> coreboot mailing list: coreboot at coreboot.org >>>> http://www.coreboot.org/mailman/listinfo/coreboot >> >> > From patrick at georgi-clan.de Mon Feb 2 12:09:35 2015 From: patrick at georgi-clan.de (Patrick Georgi) Date: Mon, 02 Feb 2015 12:09:35 +0100 Subject: [coreboot] coreboot code of conduct In-Reply-To: <54CE1C81.5020101@gmx.net> References: <54BB248A.4000300@gmx.net> <54BCF005.6000003@gmx.net> <16ee1bdd15c6779c90ff9cfca022f4c7@mail.georgi-clan.de> <54BEE9E1.504@gmx.net> <54CE1C81.5020101@gmx.net> Message-ID: <68e217820590580bfc94101a692df86f@mail.georgi-clan.de> Am 2015-02-01 13:30, schrieb Carl-Daniel Hailfinger: > It seems patches are being ignored or getting lost. It's not exactly news that people are busy. And "patches" on the list are ignored since 2011. > There are two possible solutions: Removing the lock on the wiki page or A CoC with no editorial oversight at all is probably worse than no CoC. Patrick From c-d.hailfinger.devel.2006 at gmx.net Tue Feb 3 11:38:10 2015 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Tue, 03 Feb 2015 11:38:10 +0100 Subject: [coreboot] coreboot code of conduct In-Reply-To: <68e217820590580bfc94101a692df86f@mail.georgi-clan.de> References: <54BB248A.4000300@gmx.net> <54BCF005.6000003@gmx.net> <16ee1bdd15c6779c90ff9cfca022f4c7@mail.georgi-clan.de> <54BEE9E1.504@gmx.net> <54CE1C81.5020101@gmx.net> <68e217820590580bfc94101a692df86f@mail.georgi-clan.de> Message-ID: <54D0A512.7080601@gmx.net> On 02.02.2015 12:09, Patrick Georgi wrote: > Am 2015-02-01 13:30, schrieb Carl-Daniel Hailfinger: >> It seems patches are being ignored or getting lost. > It's not exactly news that people are busy. And "patches" on the list > are ignored since 2011. Yes, but this is the first time a part of the community has decided how other parts of the community should behave and threatened draconian sanctions for any deviating behaviour. >> There are two possible solutions: Removing the lock on the wiki page or > A CoC with no editorial oversight at all is probably worse than no CoC. A CoC with no community backing is probably worse than no CoC. Marc wrote in his initial post: "Feel free to give feedback on the policy". I sincerely hope that the CoC will only be in effect after the feedback has been incorporated. The current development guidelines didn't appear overnight, but were refined over time without a lockdown on the wiki. Besides that, the development guidelines don't mention any sanctions and are thus less aggressive. Regards, Carl-Daniel From peter at stuge.se Tue Feb 3 17:11:22 2015 From: peter at stuge.se (Peter Stuge) Date: Tue, 3 Feb 2015 17:11:22 +0100 Subject: [coreboot] coreboot code of conduct In-Reply-To: <54D0A512.7080601@gmx.net> References: <54BB248A.4000300@gmx.net> <54BCF005.6000003@gmx.net> <16ee1bdd15c6779c90ff9cfca022f4c7@mail.georgi-clan.de> <54BEE9E1.504@gmx.net> <54CE1C81.5020101@gmx.net> <68e217820590580bfc94101a692df86f@mail.georgi-clan.de> <54D0A512.7080601@gmx.net> Message-ID: <20150203161122.8758.qmail@stuge.se> Carl-Daniel Hailfinger wrote: > this is the first time a part of the community has decided how > other parts of the community should behave That's not really the case here. The code of conduct applies to everyone in the community, not just "other parts of the community". > and threatened draconian sanctions for any deviating behaviour. Are you more concerned about how the code of conduct has been brought onto the agenda, or about the subject matter? It's hard to tell. :\ > > A CoC with no editorial oversight at all is probably worse than no CoC. > > A CoC with no community backing is probably worse than no CoC. I do not think that is true. And you can't claim to speak for the whole community. > Marc wrote in his initial post: "Feel free to give feedback on the > policy". I sincerely hope that the CoC will only be in effect after > the feedback has been incorporated. Maybe the code of conduct was always in effect, just not formalized? //Peter From tpearson at raptorengineeringinc.com Tue Feb 3 20:46:47 2015 From: tpearson at raptorengineeringinc.com (Timothy Pearson) Date: Tue, 03 Feb 2015 13:46:47 -0600 Subject: [coreboot] coreboot: amd debug In-Reply-To: <20150203204300.315750d8@lazus.yip> References: <20150203204300.315750d8@lazus.yip> Message-ID: <54D125A7.7010409@raptorengineeringinc.com> On 02/03/2015 01:43 PM, Alexander Couzens wrote: > Hi Timothy, > > thanks for your work on coreboot. I've here some amd boards which I would like to write support for coreboot. > I'm wondering how you debug your amd boards? Do you have jtag support? > > Best, > Alex I did not need to use JTAG when porting as there was already partially-functional K10 support in coreboot. I used the serial console mostly, and as the ROM was socketed it was fastest to simply hot-swap ROMs between a good vendor BIOS and the coreboot development image. What family of processor and northbridge are you looking to support? -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 http://www.raptorengineeringinc.com From c-d.hailfinger.devel.2006 at gmx.net Wed Feb 4 00:52:02 2015 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 04 Feb 2015 00:52:02 +0100 Subject: [coreboot] coreboot code of conduct In-Reply-To: <20150203161122.8758.qmail@stuge.se> References: <54BB248A.4000300@gmx.net> <54BCF005.6000003@gmx.net> <16ee1bdd15c6779c90ff9cfca022f4c7@mail.georgi-clan.de> <54BEE9E1.504@gmx.net> <54CE1C81.5020101@gmx.net> <68e217820590580bfc94101a692df86f@mail.georgi-clan.de> <54D0A512.7080601@gmx.net> <20150203161122.8758.qmail@stuge.se> Message-ID: <54D15F22.7050200@gmx.net> Opening remark: While I did try to phrase this in the most accurate way possible with the help of a dictionary, please keep in mind I'm not a native speaker of English. My apologies for any misunderstanding which may arise. There is no intent to offend on my side. On 03.02.2015 17:11, Peter Stuge wrote: > Carl-Daniel Hailfinger wrote: >> this is the first time a part of the community has decided how >> other parts of the community should behave > That's not really the case here. The code of conduct applies to > everyone in the community, not just "other parts of the community". Granted. Let me replace "other parts of the community" with "themselves and other parts of the community". This makes it more clear that one part of the community makes decisions and the other part of the community is expected to comply. It is kind of obvious that the decision-making part of the community would comply with their own decisions, and this is why I didn't mention them in my original statement. >> and threatened draconian sanctions for any deviating behaviour. > Are you more concerned about how the code of conduct has been brought > onto the agenda, or about the subject matter? It's hard to tell. :\ I am concerned with the combination of both. I already mentioned my objections to parts of the Code of Conduct earlier in this thread. I also object to the way the CoC was presented. I would have been totally OK with "this is a draft, please comment, then after the requested changes have consensus and everyone agrees, let's make this binding". Instead, we get a public announcement of a Code of Conduct which implies that it is finalized already. Let me quote from the associated blog post: "we are going a step farther and describing what is unacceptable within our community with the coreboot Code of Conduct". That doesn't sound like it's a draft or unfinished. Having the arbitration team be disjoint from the team creating the Code of Conduct would also have dispelled concern about one group of individuals acting as policymaker, judge, jury and executioner. I happen to have learned at school that separation of powers is essential and this shapes the way I think. >>> A CoC with no editorial oversight at all is probably worse than no CoC. >> A CoC with no community backing is probably worse than no CoC. > I do not think that is true. How would a CoC without community backing be any better than no CoC? Please note that wiki accounts for editing are only handed out manually by a select few people. This also means that even for an unlocked wiki page (suggested by me as one of the possible solutions) there is in fact oversight. > And you can't claim to speak for the whole community. I didn't claim to speak for the whole community. I didn't even claim to speak for the majority. I just took Patrick's statement word for word and replaced "editorial oversight" with "community backing". The most interesting question here is whether editorial oversight is more important than community backing. >> Marc wrote in his initial post: "Feel free to give feedback on the >> policy". I sincerely hope that the CoC will only be in effect after >> the feedback has been incorporated. > Maybe the code of conduct was always in effect, just not formalized? My impression is that there is/was some sort of universal agreement about being reasonably nice to everyone who was interested in or wanted to be involved with coreboot in some way. Occassional trolling on IRC is/was also being dealt with. However, formalizing a "be nice" policy would hopefully have resulted in a text which focuses less on unacceptable behaviour and associated sanctions. Being nice also means not treating community members as potential offenders. Reading sentences like "Behave." (yes, that is a complete sentence from the Code of Conduct) makes me feel like an unruly teenager getting a dressing-down from the headmaster. TL;DR: IMHO the CoC needs to be discussed, revised and ratified before taking effect. Regards, Carll-Daniel From c-d.hailfinger.devel.2006 at gmx.net Wed Feb 4 01:04:27 2015 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 04 Feb 2015 01:04:27 +0100 Subject: [coreboot] AMD Mahogany Fam10 not booting In-Reply-To: <54CF0B91.30207@gmail.com> References: <000001d03e9a$0f2dcd50$2d8967f0$@notabs.org> <54CF0B91.30207@gmail.com> Message-ID: <54D1620B.8000900@gmx.net> On 02.02.2015 06:30, Ky?sti M?lkki wrote: > On 02/02/2015 05:40 AM, Scott Duplichan wrote: >> I found coreboot for AMD Mahogany Fam10 is no longer working. The >> problem >> starts with this change: >> http://www.coreboot.org/pipermail/coreboot-gerrit/2013-July/002391.html >> >> Some other older AMD boards are likely affected too. [...] > > Known issue, I am sorry you had to bisect this one too in the lack of > bug tracking. [...] Would the automated testsystem have caught this? If yes, which platforms should be present in this automated testsystem to have reasonably good coverage of systems still relevant to the community? I hope to get the chance to allocate resources to run a bunch of platforms in my own automated testsystem. A list of maybe 5-10 desirable platforms/boards would be appreciated, preferably not just Thinkpads and Chromebooks. If this works out (should know about this by May/June), those boards would end up testing every mainline commit. Regards, Carl-Daniel From tpearson at raptorengineeringinc.com Wed Feb 4 01:09:31 2015 From: tpearson at raptorengineeringinc.com (Timothy Pearson) Date: Tue, 03 Feb 2015 18:09:31 -0600 Subject: [coreboot] AMD Mahogany Fam10 not booting In-Reply-To: <54D1620B.8000900@gmx.net> References: <000001d03e9a$0f2dcd50$2d8967f0$@notabs.org> <54CF0B91.30207@gmail.com> <54D1620B.8000900@gmx.net> Message-ID: <54D1633B.4070408@raptorengineeringinc.com> On 02/03/2015 06:04 PM, Carl-Daniel Hailfinger wrote: > On 02.02.2015 06:30, Ky?sti M?lkki wrote: >> On 02/02/2015 05:40 AM, Scott Duplichan wrote: >>> I found coreboot for AMD Mahogany Fam10 is no longer working. The >>> problem >>> starts with this change: >>> http://www.coreboot.org/pipermail/coreboot-gerrit/2013-July/002391.html >>> >>> Some other older AMD boards are likely affected too. [...] >> >> Known issue, I am sorry you had to bisect this one too in the lack of >> bug tracking. [...] > > Would the automated testsystem have caught this? If yes, which platforms > should be present in this automated testsystem to have reasonably good > coverage of systems still relevant to the community? > > I hope to get the chance to allocate resources to run a bunch of > platforms in my own automated testsystem. A list of maybe 5-10 desirable > platforms/boards would be appreciated, preferably not just Thinkpads and > Chromebooks. If this works out (should know about this by May/June), > those boards would end up testing every mainline commit. > > Regards, > Carl-Daniel > > I was looking into setting something up like this as well for the ASUS KFSN4-DRE series of boards (socket F K10). If you'll be testing K10 then maybe I don't have to do this after all. -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 http://www.raptorengineeringinc.com From york.yang at intel.com Wed Feb 4 01:18:24 2015 From: york.yang at intel.com (Yang, York) Date: Wed, 4 Feb 2015 00:18:24 +0000 Subject: [coreboot] Can I upstream an UEFI payload binary for MinnowMax board project Message-ID: <9A382F7099884143A15663C92EF473694FB2CA93@FMSMSX109.amr.corp.intel.com> Hello, Can I upstream an UEFI payload binary for MinnowMax board project? The reason is we want to reduce the effort that coreboot user spends to build one. UEFI payload contains two component, 1) is EDK2 infrastructure in tianocore.org, and 2) coreboot library and package in firmware.intel.com/develop. User need to download them separately, and put them together, and build it. It could be improved in the future, but for now it takes time. If upstream a binary is accepted, is any rule and guidance that I should follow up? Thanks, York -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick at georgi-clan.de Wed Feb 4 12:31:13 2015 From: patrick at georgi-clan.de (Patrick Georgi) Date: Wed, 04 Feb 2015 12:31:13 +0100 Subject: [coreboot] coreboot code of conduct In-Reply-To: <54D0A512.7080601@gmx.net> References: <54BB248A.4000300@gmx.net> <54BCF005.6000003@gmx.net> <16ee1bdd15c6779c90ff9cfca022f4c7@mail.georgi-clan.de> <54BEE9E1.504@gmx.net> <54CE1C81.5020101@gmx.net> <68e217820590580bfc94101a692df86f@mail.georgi-clan.de> <54D0A512.7080601@gmx.net> Message-ID: Am 2015-02-03 11:38, schrieb Carl-Daniel Hailfinger: > The current development guidelines didn't appear overnight, but were > refined over time without a lockdown on the wiki. And yet they're mostly useless. The CoC wikipage is now unlocked. Let's see what comes of it. Patrick From dsaklad at gnu.org Wed Feb 4 13:16:27 2015 From: dsaklad at gnu.org (Don Warner Saklad) Date: Wed, 04 Feb 2015 07:16:27 -0500 Subject: [coreboot] What are the intricacies?, what's the finese for operating the Neal Peacock PengPod1000 tablets' Buttons!?... Message-ID: <5ioap9x46c.fsf@fencepost.gnu.org> What are the intricacies?, what's the finese for operating the Neal Peacock PengPod1000 tablets' Buttons!?... What Button presses, what sequence of Button presses, what length of holding Button presses can be tried to get the Neal Peacock PengPod1000 to work from the included SD Card? Tried holding presses for different lengths of time, tried repeating presses, tried getting the Neal Peacock PengPod 1000 to work from the included SD Card starting with the power on and also starting with the power off and using the PowerButton, ResetButton, RockerButtonVolumeUp/VolumeDown The instructions didn't work... "To boot into Linux you must have either a Linux SD card or a device flashed with Linux. To boot from the Linux SD, starting in Android, insert the card (it will show as 'damaged") and reset the device. The screen should be blank for 15-30 seconds then boot into Linux." "There is an open root terminal on virtual console 1, use ctrl, alt, F1 to access it if needed." About tablet Model number BC1077 Build number crane_bc1077-eng 4.0.4 IMM76D 20121108 test-keys Android on Flash dual boot capable Micro SD 32GB 10-inch case with keyboard N500 Tablet PC CPU Allwinner A10 1.5GHz 560MHzDSP "PengPod 32GB Linux Bootable Micro SD Card for PengPod1000 TM and C 2013 Peacock imports LLC. All rights reserved. PengPod and the Pengpod logo are trademarks of Peacock Imports LLC, 5415 Lake Howell Rd. #317, Winter Park FL 32792 USA" From patrick at georgi-clan.de Wed Feb 4 14:21:53 2015 From: patrick at georgi-clan.de (Patrick Georgi) Date: Wed, 04 Feb 2015 14:21:53 +0100 Subject: [coreboot] Can I upstream an UEFI payload binary for MinnowMax board project In-Reply-To: <9A382F7099884143A15663C92EF473694FB2CA93@FMSMSX109.amr.corp.intel.com> References: <9A382F7099884143A15663C92EF473694FB2CA93@FMSMSX109.amr.corp.intel.com> Message-ID: <8d3beb1e69d0285d170bcc844c38f491@mail.georgi-clan.de> Am 2015-02-04 01:18, schrieb Yang, York: > Can I upstream an UEFI payload binary for MinnowMax board project? No. We don't ship payload binaries, and there's no reason to start doing that. coreboot is an Open Source project. > The reason is we want to reduce the effort that coreboot user spends to > build one. > UEFI payload contains two component, 1) is EDK2 infrastructure in > tianocore.org, and 2) coreboot library and package in > firmware.intel.com/develop. User need to download them separately, and > put them together, and build it. I like to think that the corebootPkg sources are rather easy to obtain: $ git clone https://github.com/pgeorgi/edk2 So the reason that your UEFI payload's sources are harder to assemble must be a problem within that project and its processes, not something that's fundamental to Tianocore based payloads. For example, I can't imagine a single good reason why that firmware site ships Open Source code in an encrypted zip file. > It could be improved in the future, but for now it takes time. Then take the time. What incentive is left to improve things in the future if users can simply be diverted to those binaries? Patrick From scott at notabs.org Wed Feb 4 18:01:18 2015 From: scott at notabs.org (Scott Duplichan) Date: Wed, 4 Feb 2015 11:01:18 -0600 Subject: [coreboot] AMD Mahogany Fam10 not booting In-Reply-To: <54D1620B.8000900@gmx.net> References: <000001d03e9a$0f2dcd50$2d8967f0$@notabs.org> <54CF0B91.30207@gmail.com> <54D1620B.8000900@gmx.net> Message-ID: <000f01d0409c$3324ccf0$996e66d0$@notabs.org> Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2006 at gmx.net] wrote: ]Sent: Tuesday, February 03, 2015 06:04 PM ]To: coreboot at coreboot.org ]Subject: Re: [coreboot] AMD Mahogany Fam10 not booting ] ]On 02.02.2015 06:30, Ky?sti M?lkki wrote: ]> On 02/02/2015 05:40 AM, Scott Duplichan wrote: ]>> I found coreboot for AMD Mahogany Fam10 is no longer working. The ]>> problem ]>> starts with this change: ]>> http://www.coreboot.org/pipermail/coreboot-gerrit/2013-July/002391.html ]>> ]>> Some other older AMD boards are likely affected too. [...] ]> ]> Known issue, I am sorry you had to bisect this one too in the lack of ]> bug tracking. [...] ] ]Would the automated testsystem have caught this? If yes, which platforms ]should be present in this automated testsystem to have reasonably good ]coverage of systems still relevant to the community? Hello Carl-Daniel, An automated test system would catch this problem, though setting up such a thing sounds like a lot of work. Also, RS780 boards are a couple of generations old now and losing importance. Why did I try to boot an old RS780 board after all these years? The reason is that I wanted to see if the public version of AMD simnow could boot a coreboot project. AMD simnow is the only publically available tool I know of that lets you step through coreboot code starting from the reset vector to see how it works. AMD simnow might still be able to boot AMD Serengeti Cheetah, but that one uses a really old chipset. Unfortunately the public version of simnow supports no processor newer than family 10h. The simnow Mahogany family 10h model is compatible with the ECS board I have, so I chose it. Interestingly, simnow does not catch the configuration space problem that keeps the real board from booting. Another complication is that the simnow RS780 model doesn't correctly handle the option to make 'BAR3' read only. This results in coreboot seeing a memory BAR that wants 4GB of space, and that causes a boot fail. Thanks, Scott ]I hope to get the chance to allocate resources to run a bunch of ]platforms in my own automated testsystem. A list of maybe 5-10 desirable ]platforms/boards would be appreciated, preferably not just Thinkpads and ]Chromebooks. If this works out (should know about this by May/June), ]those boards would end up testing every mainline commit. ] ]Regards, ]Carl-Daniel From patrick at georgi-clan.de Wed Feb 4 18:56:45 2015 From: patrick at georgi-clan.de (Patrick Georgi) Date: Wed, 04 Feb 2015 18:56:45 +0100 Subject: [coreboot] AMD Mahogany Fam10 not booting In-Reply-To: <000f01d0409c$3324ccf0$996e66d0$@notabs.org> References: <000001d03e9a$0f2dcd50$2d8967f0$@notabs.org> <54CF0B91.30207@gmail.com> <54D1620B.8000900@gmx.net> <000f01d0409c$3324ccf0$996e66d0$@notabs.org> Message-ID: Am 2015-02-04 18:01, schrieb Scott Duplichan: > The reason is that I wanted to > see if the public version of AMD simnow could boot a coreboot project. > AMD simnow is the only publically available tool I know of that lets > you > step through coreboot code starting from the reset vector to see how > it works. There's QEmu that allows single stepping, and SerialICE (www.serialice.com) that is based on it allows monitoring (up to single stepping) coreboot, or anything else, on real hardware (some limitations apply when timing critical code is involved). I guess Sage's probe can be used with different trade-offs for similar purposes on supported boards. Patrick From york.yang at intel.com Wed Feb 4 19:27:52 2015 From: york.yang at intel.com (Yang, York) Date: Wed, 4 Feb 2015 18:27:52 +0000 Subject: [coreboot] Can I upstream an UEFI payload binary for MinnowMax board project In-Reply-To: <8d3beb1e69d0285d170bcc844c38f491@mail.georgi-clan.de> References: <9A382F7099884143A15663C92EF473694FB2CA93@FMSMSX109.amr.corp.intel.com> <8d3beb1e69d0285d170bcc844c38f491@mail.georgi-clan.de> Message-ID: <9A382F7099884143A15663C92EF473694FB2D005@FMSMSX109.amr.corp.intel.com> Hi Patrick, I was told that to build an UEFI payload need to get two components from different sites, sounds I got some information out-of-date. I will try getting the corebootPkg and then build a payload myself. Understood your point that entire coreboot code must contain source code only. I will share this with inside our team. Thanks, York -----Original Message----- From: Patrick Georgi [mailto:patrick at georgi-clan.de] Sent: Wednesday, February 04, 2015 6:22 AM To: Yang, York Cc: coreboot at coreboot.org Subject: Re: [coreboot] Can I upstream an UEFI payload binary for MinnowMax board project Am 2015-02-04 01:18, schrieb Yang, York: > Can I upstream an UEFI payload binary for MinnowMax board project? No. We don't ship payload binaries, and there's no reason to start doing that. coreboot is an Open Source project. > The reason is we want to reduce the effort that coreboot user spends to > build one. > UEFI payload contains two component, 1) is EDK2 infrastructure in > tianocore.org, and 2) coreboot library and package in > firmware.intel.com/develop. User need to download them separately, and > put them together, and build it. I like to think that the corebootPkg sources are rather easy to obtain: $ git clone https://github.com/pgeorgi/edk2 So the reason that your UEFI payload's sources are harder to assemble must be a problem within that project and its processes, not something that's fundamental to Tianocore based payloads. For example, I can't imagine a single good reason why that firmware site ships Open Source code in an encrypted zip file. > It could be improved in the future, but for now it takes time. Then take the time. What incentive is left to improve things in the future if users can simply be diverted to those binaries? Patrick From patrick at georgi-clan.de Wed Feb 4 19:55:28 2015 From: patrick at georgi-clan.de (Patrick Georgi) Date: Wed, 04 Feb 2015 19:55:28 +0100 Subject: [coreboot] Can I upstream an UEFI payload binary for MinnowMax board project In-Reply-To: <9A382F7099884143A15663C92EF473694FB2D005@FMSMSX109.amr.corp.intel.com> References: <9A382F7099884143A15663C92EF473694FB2CA93@FMSMSX109.amr.corp.intel.com> <8d3beb1e69d0285d170bcc844c38f491@mail.georgi-clan.de> <9A382F7099884143A15663C92EF473694FB2D005@FMSMSX109.amr.corp.intel.com> Message-ID: <35abb752ba522c18766352930c67ebfa@mail.georgi-clan.de> Am 2015-02-04 19:27, schrieb Yang, York: > I was told that to build an UEFI payload need to get two components > from different sites, sounds I got some information out-of-date. I > will try getting the corebootPkg and then build a payload myself. corebootPkg is very likely a different project from yours. There are several attempts to make Tianocore into a payload. The thing is, if you want to make it easier on MinnowMax users, you (or anyone else) could open an account on github, fork the Tianocore repository there (https://github.com/tianocore/edk2) and integrate the stuff from firmware.intel.com/develop. After that, users of that payload version can just pull the entire code with a single git clone, too. And participate in the development through github's pull request feature and issue tracker. (Of course, if you want to do this, all this may require some sign-off by your team) But since that's possible (and really easy, too), there's no need to burden coreboot.org with more binaries. > Understood your point that entire coreboot code must contain source > code only. I will share this with inside our team. We compromise here and there, but that's not some thing we want to encourage - it is really just a compromise, and it's risky to try to push its boundaries. Patrick From scan-admin at coverity.com Wed Feb 4 20:10:09 2015 From: scan-admin at coverity.com (scan-admin at coverity.com) Date: Wed, 04 Feb 2015 11:10:09 -0800 Subject: [coreboot] New Defects reported by Coverity Scan for coreboot Message-ID: <54d26e91f00f4_7b3f1143330944f5@scan.coverity.com.mail> Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 11 new defect(s) introduced to coreboot found with Coverity Scan. 10 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 11 of 11 defect(s) ** CID 1268177: Out-of-bounds access (ARRAY_VS_SINGLETON) /src/cpu/x86/car.c: 137 in do_car_migrate_hooks() ** CID 1268176: Unchecked return value (CHECKED_RETURN) /src/lib/hardwaremain.c: 470 in main() ** CID 1268175: Operands don't affect result (CONSTANT_EXPRESSION_RESULT) /src/cpu/amd/model_10xxx/powernow_acpi.c: 215 in pstates_algorithm() ** CID 1268174: Same on both sides (CONSTANT_EXPRESSION_RESULT) /src/mainboard/asus/kfsn4-dre/romstage.c: 234 in cache_as_ram_main() ** CID 1268173: Out-of-bounds read (OVERRUN) /src/northbridge/intel/i440bx/raminit.c: 612 in spd_enable_refresh() ** CID 1268172: Out-of-bounds access (OVERRUN) /src/northbridge/intel/e7505/debug.c: 99 in dump_spd_registers() /src/northbridge/intel/e7505/debug.c: 117 in dump_spd_registers() ** CID 1268171: Uninitialized scalar variable (UNINIT) /src/cpu/amd/model_10xxx/powernow_acpi.c: 82 in pstates_algorithm() ** CID 1268170: Uninitialized scalar variable (UNINIT) /src/cpu/amd/model_10xxx/powernow_acpi.c: 215 in pstates_algorithm() ** CID 1268169: Uninitialized scalar variable (UNINIT) /src/cpu/amd/model_10xxx/powernow_acpi.c: 83 in pstates_algorithm() ** CID 1268168: Uninitialized scalar variable (UNINIT) /src/cpu/amd/model_10xxx/powernow_acpi.c: 208 in pstates_algorithm() ** CID 1268167: Uninitialized scalar variable (UNINIT) /src/cpu/amd/model_10xxx/powernow_acpi.c: 81 in pstates_algorithm() ________________________________________________________________________________________________________ *** CID 1268177: Out-of-bounds access (ARRAY_VS_SINGLETON) /src/cpu/x86/car.c: 137 in do_car_migrate_hooks() 131 { 132 car_migration_func_t *migrate_func; 133 /* Call all the migration functions. */ 134 migrate_func = &_car_migrate_start; 135 while (*migrate_func != NULL) { 136 (*migrate_func)(); >>> CID 1268177: Out-of-bounds access (ARRAY_VS_SINGLETON) >>> Using "migrate_func" as an array. This might corrupt or misinterpret adjacent memory locations. 137 migrate_func++; 138 } 139 } 140 141 void car_migrate_variables(void) 142 { ________________________________________________________________________________________________________ *** CID 1268176: Unchecked return value (CHECKED_RETURN) /src/lib/hardwaremain.c: 470 in main() 464 coreboot_version, coreboot_extra_version, coreboot_build); 465 466 post_code(POST_CONSOLE_BOOT_MSG); 467 468 /* Handoff sleep type from romstage. */ 469 #if CONFIG_HAVE_ACPI_RESUME >>> CID 1268176: Unchecked return value (CHECKED_RETURN) >>> Calling "acpi_is_wakeup" without checking return value (as is done elsewhere 4 out of 5 times). 470 acpi_is_wakeup(); 471 #endif 472 473 exception_init(); 474 threads_initialize(); 475 ________________________________________________________________________________________________________ *** CID 1268175: Operands don't affect result (CONSTANT_EXPRESSION_RESULT) /src/cpu/amd/model_10xxx/powernow_acpi.c: 215 in pstates_algorithm() 209 210 /* Calculate transition latency */ 211 dtemp = pci_read_config32(dev_find_slot(0, PCI_DEVFN(0x18, 3)), 0xD4); 212 power_step_up = (dtemp & 0xf000000) >> 24; 213 power_step_down = (dtemp & 0xf00000) >> 20; 214 dtemp = pci_read_config32(dev_find_slot(0, PCI_DEVFN(0x18, 3)), 0xA0); >>> CID 1268175: Operands don't affect result (CONSTANT_EXPRESSION_RESULT) >>> "pll_lock_time & 0x3800" is always 0 regardless of the values of its operands. This occurs as a value. 215 pll_lock_time = (pll_lock_time & 0x3800) >> 11; 216 if (all_enabled_cores_have_same_cpufid) 217 core_latency = ((12 * power_step_down) + power_step_up) / 1000; 218 else 219 core_latency = (12 * (power_step_down + power_step_up) / 1000) 220 + pll_lock_time; ________________________________________________________________________________________________________ *** CID 1268174: Same on both sides (CONSTANT_EXPRESSION_RESULT) /src/mainboard/asus/kfsn4-dre/romstage.c: 234 in cache_as_ram_main() 228 229 post_code(0x32); 230 231 winbond_enable_serial(SERIAL_DEV, CONFIG_TTYS0_BASE); 232 console_init(); 233 >>> CID 1268174: Same on both sides (CONSTANT_EXPRESSION_RESULT) >>> "2 != 2" is always false regardless of the values of its operands because those operands are identical. This occurs as the logical operand of if. 234 if (CONFIG_MAX_PHYSICAL_CPUS != 2) 235 printk(BIOS_WARNING, "CONFIG_MAX_PHYSICAL_CPUS is %d, but this is a dual socket board!\n", CONFIG_MAX_PHYSICAL_CPUS); 236 237 /* Halt if there was a built in self test failure */ 238 report_bist_failure(bist); 239 ________________________________________________________________________________________________________ *** CID 1268173: Out-of-bounds read (OVERRUN) /src/northbridge/intel/i440bx/raminit.c: 612 in spd_enable_refresh() 606 reg = pci_read_config8(NB, DRAMC); 607 608 for (i = 0; i < DIMM_SOCKETS; i++) { 609 value = spd_read_byte(DIMM0 + i, SPD_REFRESH); 610 if (value < 0) 611 continue; >>> CID 1268173: Out-of-bounds read (OVERRUN) >>> Overrunning array "refresh_rate_map" of 6 4-byte elements at element index 127 (byte offset 508) using index "value & 0x7f" (which evaluates to 127). 612 reg = (reg & 0xf8) | refresh_rate_map[(value & 0x7f)]; 613 614 PRINT_DEBUG(" Enabling refresh (DRAMC = 0x%02x) for DIMM %02x\n", reg, i); 615 } 616 617 pci_write_config8(NB, DRAMC, reg); ________________________________________________________________________________________________________ *** CID 1268172: Out-of-bounds access (OVERRUN) /src/northbridge/intel/e7505/debug.c: 99 in dump_spd_registers() 93 for(i = 0; i < 4; i++) { 94 unsigned device; 95 device = ctrl->channel0[i]; 96 if (device) { 97 int j; 98 printk(BIOS_DEBUG, "dimm: %02x.0: %02x", i, device); >>> CID 1268172: Out-of-bounds access (OVERRUN) >>> Checking "j < 128" implies that "j" has the value which may be up to 127 on the true branch. 99 for(j = 0; j < 128; j++) { 100 int status; 101 unsigned char byte; 102 if ((j & 0xf) == 0) 103 printk(BIOS_DEBUG, "\n%02x: ", j); 104 status = spd_read_byte(device, j); /src/northbridge/intel/e7505/debug.c: 117 in dump_spd_registers() 111 printk(BIOS_DEBUG, "\n"); 112 } 113 device = ctrl->channel1[i]; 114 if (device) { 115 int j; 116 printk(BIOS_DEBUG, "dimm: %02x.1: %02x", i, device); >>> CID 1268172: Out-of-bounds access (OVERRUN) >>> Checking "j < 128" implies that "j" has the value which may be up to 127 on the true branch. 117 for(j = 0; j < 128; j++) { 118 int status; 119 unsigned char byte; 120 if ((j & 0xf) == 0) 121 printk(BIOS_DEBUG, "\n%02x: ", j); 122 status = spd_read_byte(device, j); ________________________________________________________________________________________________________ *** CID 1268171: Uninitialized scalar variable (UNINIT) /src/cpu/amd/model_10xxx/powernow_acpi.c: 82 in pstates_algorithm() 76 u32 *v; 77 struct cpuid_result cpuid1; 78 79 u16 Pstate_feq[10]; 80 u32 Pstate_power[10]; 81 u32 Pstate_latency[10]; >>> CID 1268171: Uninitialized scalar variable (UNINIT) >>> Declaring variable "Pstate_control" without initializer. 82 u32 Pstate_control[10]; 83 u32 Pstate_status[10]; 84 u8 Pstate_num; 85 u8 cmp_cap; 86 u8 index; 87 msr_t msr; ________________________________________________________________________________________________________ *** CID 1268170: Uninitialized scalar variable (UNINIT) /src/cpu/amd/model_10xxx/powernow_acpi.c: 215 in pstates_algorithm() 209 210 /* Calculate transition latency */ 211 dtemp = pci_read_config32(dev_find_slot(0, PCI_DEVFN(0x18, 3)), 0xD4); 212 power_step_up = (dtemp & 0xf000000) >> 24; 213 power_step_down = (dtemp & 0xf00000) >> 20; 214 dtemp = pci_read_config32(dev_find_slot(0, PCI_DEVFN(0x18, 3)), 0xA0); >>> CID 1268170: Uninitialized scalar variable (UNINIT) >>> Using uninitialized value "pll_lock_time". 215 pll_lock_time = (pll_lock_time & 0x3800) >> 11; 216 if (all_enabled_cores_have_same_cpufid) 217 core_latency = ((12 * power_step_down) + power_step_up) / 1000; 218 else 219 core_latency = (12 * (power_step_down + power_step_up) / 1000) 220 + pll_lock_time; ________________________________________________________________________________________________________ *** CID 1268169: Uninitialized scalar variable (UNINIT) /src/cpu/amd/model_10xxx/powernow_acpi.c: 83 in pstates_algorithm() 77 struct cpuid_result cpuid1; 78 79 u16 Pstate_feq[10]; 80 u32 Pstate_power[10]; 81 u32 Pstate_latency[10]; 82 u32 Pstate_control[10]; >>> CID 1268169: Uninitialized scalar variable (UNINIT) >>> Declaring variable "Pstate_status" without initializer. 83 u32 Pstate_status[10]; 84 u8 Pstate_num; 85 u8 cmp_cap; 86 u8 index; 87 msr_t msr; 88 ________________________________________________________________________________________________________ *** CID 1268168: Uninitialized scalar variable (UNINIT) /src/cpu/amd/model_10xxx/powernow_acpi.c: 208 in pstates_algorithm() 202 expanded_cpuidv = 100; 203 break; 204 case 0x3: 205 expanded_cpuidv = 1000; 206 break; 207 } >>> CID 1268168: Uninitialized scalar variable (UNINIT) >>> Using uninitialized value "expanded_cpuidv". 208 core_power = (core_voltage * cpuidd) / (expanded_cpuidv * 10); 209 210 /* Calculate transition latency */ 211 dtemp = pci_read_config32(dev_find_slot(0, PCI_DEVFN(0x18, 3)), 0xD4); 212 power_step_up = (dtemp & 0xf000000) >> 24; 213 power_step_down = (dtemp & 0xf00000) >> 20; ________________________________________________________________________________________________________ *** CID 1268167: Uninitialized scalar variable (UNINIT) /src/cpu/amd/model_10xxx/powernow_acpi.c: 81 in pstates_algorithm() 75 u8 processor_brand[49]; 76 u32 *v; 77 struct cpuid_result cpuid1; 78 79 u16 Pstate_feq[10]; 80 u32 Pstate_power[10]; >>> CID 1268167: Uninitialized scalar variable (UNINIT) >>> Declaring variable "Pstate_latency" without initializer. 81 u32 Pstate_latency[10]; 82 u32 Pstate_control[10]; 83 u32 Pstate_status[10]; 84 u8 Pstate_num; 85 u8 cmp_cap; 86 u8 index; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://scan.coverity.com/projects/1016?tab=overview To manage Coverity Scan email notifications for "coreboot at coreboot.org", click https://scan.coverity.com/subscriptions/edit?email=coreboot%40coreboot.org&token=8ddd1fe26945626880b796e94d465567 . From york.yang at intel.com Wed Feb 4 20:22:11 2015 From: york.yang at intel.com (Yang, York) Date: Wed, 4 Feb 2015 19:22:11 +0000 Subject: [coreboot] Can I upstream an UEFI payload binary for MinnowMax board project In-Reply-To: <35abb752ba522c18766352930c67ebfa@mail.georgi-clan.de> References: <9A382F7099884143A15663C92EF473694FB2CA93@FMSMSX109.amr.corp.intel.com> <8d3beb1e69d0285d170bcc844c38f491@mail.georgi-clan.de> <9A382F7099884143A15663C92EF473694FB2D005@FMSMSX109.amr.corp.intel.com> <35abb752ba522c18766352930c67ebfa@mail.georgi-clan.de> Message-ID: <9A382F7099884143A15663C92EF473694FB2D0B0@FMSMSX109.amr.corp.intel.com> Actually we also work on a solution to build an UEFI payload easier (open source too), but it takes time to complete. Hence we are looking for a short team solution, and the binary upstreaming is just an idea to ask whether community is allowing such work. Never mind, we will keep evaluating another solution and make it happen as soon as possible. Github is a very good suggestion. Thank you very much Patrick. York -----Original Message----- From: Patrick Georgi [mailto:patrick at georgi-clan.de] Sent: Wednesday, February 04, 2015 11:55 AM To: Yang, York Cc: coreboot at coreboot.org Subject: RE: [coreboot] Can I upstream an UEFI payload binary for MinnowMax board project Am 2015-02-04 19:27, schrieb Yang, York: > I was told that to build an UEFI payload need to get two components > from different sites, sounds I got some information out-of-date. I > will try getting the corebootPkg and then build a payload myself. corebootPkg is very likely a different project from yours. There are several attempts to make Tianocore into a payload. The thing is, if you want to make it easier on MinnowMax users, you (or anyone else) could open an account on github, fork the Tianocore repository there (https://github.com/tianocore/edk2) and integrate the stuff from firmware.intel.com/develop. After that, users of that payload version can just pull the entire code with a single git clone, too. And participate in the development through github's pull request feature and issue tracker. (Of course, if you want to do this, all this may require some sign-off by your team) But since that's possible (and really easy, too), there's no need to burden coreboot.org with more binaries. > Understood your point that entire coreboot code must contain source > code only. I will share this with inside our team. We compromise here and there, but that's not some thing we want to encourage - it is really just a compromise, and it's risky to try to push its boundaries. Patrick From scott at notabs.org Wed Feb 4 21:05:00 2015 From: scott at notabs.org (Scott Duplichan) Date: Wed, 4 Feb 2015 14:05:00 -0600 Subject: [coreboot] AMD Mahogany Fam10 not booting In-Reply-To: References: <000001d03e9a$0f2dcd50$2d8967f0$@notabs.org> <54CF0B91.30207@gmail.com> <54D1620B.8000900@gmx.net> <000f01d0409c$3324ccf0$996e66d0$@notabs.org> Message-ID: <001201d040b5$dd0f4c90$972de5b0$@notabs.org> Patrick Georgi [mailto:patrick at georgi-clan.de] wrote: ]Sent: Wednesday, February 04, 2015 11:57 AM ]To: Scott Duplichan ]Cc: coreboot at coreboot.org ]Subject: Re: [coreboot] AMD Mahogany Fam10 not booting ] ]Am 2015-02-04 18:01, schrieb Scott Duplichan: ]> The reason is that I wanted to ]> see if the public version of AMD simnow could boot a coreboot project. ]> AMD simnow is the only publically available tool I know of that lets ]> you step through coreboot code starting from the reset vector to see how ]> it works. ]There's QEmu that allows single stepping, and SerialICE ](www.serialice.com) ]that is based on it allows monitoring (up to single stepping) coreboot, ]or ]anything else, on real hardware (some limitations apply when timing ]critical ]code is involved). Serialice sounds useful, though only if you also have real hardware. I think Qemu is good for developers working on certain parts of the code. But it can't boot the same binary that boots on real hardware like simnow can. It is unfortunate that the public version of simnow is so limited. Simnow NDA version boot just about every AMD reference board since Solo, the AMD 64 board from around 2000. ]I guess Sage's probe can be used with different trade-offs for similar ]purposes on supported boards. I have used the Sage SmartProbe and it is useful. But it is a little expensive for someone just tinkering or learning. A bigger problem is making the jtag connection to the board. Commercial boards almost never have the pads for soldering the jtag connector. AMD reference boards have the needed pads, but those boards are not available to the general public. ]Patrick From scott at notabs.org Thu Feb 5 07:08:29 2015 From: scott at notabs.org (Scott Duplichan) Date: Thu, 5 Feb 2015 00:08:29 -0600 Subject: [coreboot] Can I upstream an UEFI payload binary for MinnowMax board project In-Reply-To: <9A382F7099884143A15663C92EF473694FB2D0B0@FMSMSX109.amr.corp.intel.com> References: <9A382F7099884143A15663C92EF473694FB2CA93@FMSMSX109.amr.corp.intel.com> <8d3beb1e69d0285d170bcc844c38f491@mail.georgi-clan.de> <9A382F7099884143A15663C92EF473694FB2D005@FMSMSX109.amr.corp.intel.com> <35abb752ba522c18766352930c67ebfa@mail.georgi-clan.de> <9A382F7099884143A15663C92EF473694FB2D0B0@FMSMSX109.amr.corp.intel.com> Message-ID: <000001d0410a$2b00de60$81029b20$@notabs.org> Yang, York [mailto:york.yang at intel.com] wrote: ]Sent: Wednesday, February 04, 2015 01:22 PM ]To: Patrick Georgi ]Cc: coreboot at coreboot.org ]Subject: Re: [coreboot] Can I upstream an UEFI payload binary for MinnowMax board project ]Actually we also work on a solution to build an UEFI payload easier ](open source too), but it takes time to complete. Hence we are looking ]for a short team solution, and the binary upstreaming is just an idea to ]ask whether community is allowing such work. Never mind, we will keep ]evaluating another solution and make it happen as soon as possible. ]Github is a very good suggestion. Thank you very much Patrick. ]York Making your payload project easy to build is not difficult. Here are some ideas... 1) Use the latest EDK2 trunk code instead of the UDK2014 snapshot. 2) Make the project build with gcc and Microsoft tool chains. 3) Commit the code to https://svn.code.sf.net/p/edk2/code/trunk/edk2. 1) This way, it will be an official EDK2 project. Given that most of the recent EDK2 code commits have been for ARM or QEMU, a new Intel project would provide some needed variety. Committing the code to the main EDK2 repository will make getting all the needed source code easy. 2) Many readers of this list build using gcc, so supporting gcc is important. It is also easy because EDK2 officially supports gcc tool chains running from Windows and Linux. Gcc tool chains for Windows are here: http://sourceforge.net/projects/edk2developertoolsforwindows/ With the attached patch applied to your code, build testing using EDK2 trunk latest (SVN 16758) passes for all 48 combinations of release/debug, 32/64, and the following tool chains: DDK3790, VS2005, VS2008, VS2010, VS2012, VS2013, GCC44, GCC45, GCC46, GCC47, GCC48, GCC49. 3) Committing the code to the EDK2 repository. This takes a little work. You submit a patch and then wait for some code review. You would have to de-tabify the code to get it past code review. EDK2 has no automated build server. I could do build testing but I have no way to boot test. Here is what the patch does: CbSupportDxe.c -- fix a function prototype that differs from the actual function. The difference only affects gcc tool chains because gcc builds use a default abi of sysv and not ms. CbSupportPei.c -- add 'll' suffix to a 64-bit constant. This is needed only for old gcc tool chains (gcc 4.4). CbParseLib.h, CbParseLib.c -- change prototype to avoid gcc error. Also remove unused functions to prevent a gcc build fail. SecEntry.S -- format constant the way gas wants it. SerialIo.c -- use extra braces around initialization data to prevent gcc build fail. CorebootPayloadPkg.fdf - expand binary size a little to accommodate the gcc debug build. The gcc release build fits without change. Gcc builds are bigger because EDK2 does not yet enable gcc link time optimization. --- payload.patch --- diff -rupN original/CorebootModulePkg/CbSupportDxe/CbSupportDxe.c modified/CorebootModulePkg/CbSupportDxe/CbSupportDxe.c --- original/CorebootModulePkg/CbSupportDxe/CbSupportDxe.c 2014-06-24 03:04:33.927000000 -0500 +++ modified/CorebootModulePkg/CbSupportDxe/CbSupportDxe.c 2015-02-04 22:08:06.005430400 -0600 @@ -98,9 +98,10 @@ CbReserveResourceInGcd ( **/ VOID +EFIAPI OnReadyToBoot ( - EFI_EVENT Event, - VOID *Context + IN EFI_EVENT Event, + IN VOID *Context ) { // @@ -122,6 +123,7 @@ OnReadyToBoot ( **/ EFI_STATUS +EFIAPI CbDxeEntryPoint ( IN EFI_HANDLE ImageHandle, IN EFI_SYSTEM_TABLE *SystemTable diff -rupN original/CorebootModulePkg/CbSupportPei/CbSupportPei.c modified/CorebootModulePkg/CbSupportPei/CbSupportPei.c --- original/CorebootModulePkg/CbSupportPei/CbSupportPei.c 2014-06-24 03:04:33.662000000 -0500 +++ modified/CorebootModulePkg/CbSupportPei/CbSupportPei.c 2015-02-04 22:12:39.551910800 -0600 @@ -239,7 +239,7 @@ CbPeiEntryPoint ( EFI_RESOURCE_ATTRIBUTE_WRITE_THROUGH_CACHEABLE | EFI_RESOURCE_ATTRIBUTE_WRITE_BACK_CACHEABLE ), - (EFI_PHYSICAL_ADDRESS)(0x100000000), + (EFI_PHYSICAL_ADDRESS)(0x100000000ll), HighMemorySize ); } diff -rupN original/CorebootModulePkg/Include/Coreboot.h modified/CorebootModulePkg/Include/Coreboot.h --- original/CorebootModulePkg/Include/Coreboot.h 2014-06-17 21:15:25.814000000 -0500 +++ modified/CorebootModulePkg/Include/Coreboot.h 2015-02-04 16:38:57.524177800 -0600 @@ -45,7 +45,9 @@ #ifndef _COREBOOT_PEI_H_INCLUDED_ #define _COREBOOT_PEI_H_INCLUDED_ +#if defined(_MSC_VER) #pragma warning( disable : 4200 ) +#endif #define DYN_CBMEM_ALIGN_SIZE (4096) diff -rupN original/CorebootModulePkg/Include/Library/CbParseLib.h modified/CorebootModulePkg/Include/Library/CbParseLib.h --- original/CorebootModulePkg/Include/Library/CbParseLib.h 2014-06-24 03:04:33.958000000 -0500 +++ modified/CorebootModulePkg/Include/Library/CbParseLib.h 2015-02-04 15:40:00.544565300 -0600 @@ -63,7 +63,7 @@ CbParseCbMemTable ( **/ RETURN_STATUS CbParseAcpiTable ( - IN VOID** pMemTable, + IN VOID* pMemTable, IN UINT32* pMemTableSize ); diff -rupN original/CorebootModulePkg/Library/CbParseLib/CbParseLib.c modified/CorebootModulePkg/Library/CbParseLib/CbParseLib.c --- original/CorebootModulePkg/Library/CbParseLib/CbParseLib.c 2014-06-24 03:04:34.021000000 -0500 +++ modified/CorebootModulePkg/Library/CbParseLib/CbParseLib.c 2015-02-04 16:32:34.355304700 -0600 @@ -31,16 +31,6 @@ static UINT64 cb_unpack64(struct cbuint6 return (((UINT64) val.hi) << 32) | val.lo; } -static const char *cb_mb_vendor_string(const struct cb_mainboard *cbm) -{ - return (char *)(cbm->strings + cbm->vendor_idx); -} - -static const char *cb_mb_part_string(const struct cb_mainboard *cbm) -{ - return (char *)(cbm->strings + cbm->part_number_idx); -} - VOID * FindCbTag ( IN VOID *Start, @@ -245,11 +235,11 @@ CbParseCbMemTable ( **/ RETURN_STATUS CbParseAcpiTable ( - IN VOID** pMemTable, + IN VOID* pMemTable, IN UINT32* pMemTableSize ) { - return CbParseCbMemTable (SIGNATURE_32 ('I', 'P', 'C', 'A'), pMemTable, pMemTableSize); + return CbParseCbMemTable (SIGNATURE_32 ('I', 'P', 'C', 'A'), (void **)pMemTable, pMemTableSize); } /** diff -rupN original/CorebootModulePkg/SecCore/Ia32/SecEntry.S modified/CorebootModulePkg/SecCore/Ia32/SecEntry.S --- original/CorebootModulePkg/SecCore/Ia32/SecEntry.S 2014-06-17 21:15:26.064000000 -0500 +++ modified/CorebootModulePkg/SecCore/Ia32/SecEntry.S 2015-02-04 16:43:17.249033900 -0600 @@ -46,7 +46,7 @@ ASM_PFX(_ModuleEntryPoint): # # Construct the temporary memory at 0x80000, length 0x10000 # - movl ($BASE_512KB + $SIZE_64KB), %esp + movl $(BASE_512KB + SIZE_64KB), %esp # # Pass BFV into the PEI Core diff -rupN original/CorebootPayloadPkg/CorebootPayloadPkg.fdf modified/CorebootPayloadPkg/CorebootPayloadPkg.fdf --- original/CorebootPayloadPkg/CorebootPayloadPkg.fdf 2014-06-29 21:53:30.992000000 -0500 +++ modified/CorebootPayloadPkg/CorebootPayloadPkg.fdf 2015-02-04 18:13:08.571703300 -0600 @@ -17,15 +17,15 @@ ################################################################################ [FD.UefiPayload] BaseAddress = 0x800000|gUefiCorebootModulePkgTokenSpaceGuid.PcdPayloadFdMemBase -Size = 0x400000|gUefiCorebootModulePkgTokenSpaceGuid.PcdPayloadFdMemSize +Size = 0x402000|gUefiCorebootModulePkgTokenSpaceGuid.PcdPayloadFdMemSize ErasePolarity = 1 BlockSize = 0x1000 -NumBlocks = 0x400 +NumBlocks = 0x402 -0x00000000|0x020000 +0x00000000|0x022000 FV = PEIFV -0x00020000|0x3E0000 +0x00022000|0x3E0000 FV = DXEFV ################################################################################ diff -rupN original/CorebootPayloadPkg/SerialDxe/SerialIo.c modified/CorebootPayloadPkg/SerialDxe/SerialIo.c --- original/CorebootPayloadPkg/SerialDxe/SerialIo.c 2014-06-17 21:15:26.224000000 -0500 +++ modified/CorebootPayloadPkg/SerialDxe/SerialIo.c 2015-02-04 16:59:42.921165200 -0600 @@ -37,18 +37,18 @@ typedef struct { SIMPLE_TEXT_OUT_DEVICE_PATH mDevicePath = { { - { HARDWARE_DEVICE_PATH, HW_VENDOR_DP, sizeof (VENDOR_DEVICE_PATH), 0}, + { HARDWARE_DEVICE_PATH, HW_VENDOR_DP, { sizeof (VENDOR_DEVICE_PATH), 0} }, EFI_SERIAL_IO_PROTOCOL_GUID // Use the drivers GUID }, { - { MESSAGING_DEVICE_PATH, MSG_UART_DP, sizeof (UART_DEVICE_PATH), 0}, + { MESSAGING_DEVICE_PATH, MSG_UART_DP, { sizeof (UART_DEVICE_PATH), 0} }, 0, // Reserved FixedPcdGet64 (PcdUartDefaultBaudRate), // BaudRate FixedPcdGet8 (PcdUartDefaultDataBits), // DataBits FixedPcdGet8 (PcdUartDefaultParity), // Parity (N) FixedPcdGet8 (PcdUartDefaultStopBits) // StopBits }, - { END_DEVICE_PATH_TYPE, END_ENTIRE_DEVICE_PATH_SUBTYPE, sizeof (EFI_DEVICE_PATH_PROTOCOL), 0} + { END_DEVICE_PATH_TYPE, END_ENTIRE_DEVICE_PATH_SUBTYPE, { sizeof (EFI_DEVICE_PATH_PROTOCOL), 0 } } }; EFI_HANDLE gHandle = NULL; --- build-commands.txt --- build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b DEBUG -t DDK3790 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b RELEASE -t DDK3790 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b DEBUG -t DDK3790 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b RELEASE -t DDK3790 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b DEBUG -t VS2005x86 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b RELEASE -t VS2005x86 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b DEBUG -t VS2005x86 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b RELEASE -t VS2005x86 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b DEBUG -t VS2008x86 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b RELEASE -t VS2008x86 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b DEBUG -t VS2008x86 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b RELEASE -t VS2008x86 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b DEBUG -t VS2010x86 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b RELEASE -t VS2010x86 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b DEBUG -t VS2010x86 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b RELEASE -t VS2010x86 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b DEBUG -t VS2012x86 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b RELEASE -t VS2012x86 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b DEBUG -t VS2012x86 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b RELEASE -t VS2012x86 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b DEBUG -t VS2013x86 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b RELEASE -t VS2013x86 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b DEBUG -t VS2013x86 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b RELEASE -t VS2013x86 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b DEBUG -t GCC44 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b RELEASE -t GCC44 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b DEBUG -t GCC44 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b RELEASE -t GCC44 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b DEBUG -t GCC45 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b RELEASE -t GCC45 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b DEBUG -t GCC45 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b RELEASE -t GCC45 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b DEBUG -t GCC46 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b RELEASE -t GCC46 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b DEBUG -t GCC46 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b RELEASE -t GCC46 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b DEBUG -t GCC47 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b RELEASE -t GCC47 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b DEBUG -t GCC47 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b RELEASE -t GCC47 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b DEBUG -t GCC48 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b RELEASE -t GCC48 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b DEBUG -t GCC48 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b RELEASE -t GCC48 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b DEBUG -t GCC49 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b RELEASE -t GCC49 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b DEBUG -t GCC49 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b RELEASE -t GCC49 -n 0 -a IA32 -a X64 -------------------------- Thanks, Scott ]-----Original Message----- ]From: Patrick Georgi [mailto:patrick at georgi-clan.de] ]Sent: Wednesday, February 04, 2015 11:55 AM ]To: Yang, York ]Cc: coreboot at coreboot.org ]Subject: Re: [coreboot] Can I upstream an UEFI payload binary for MinnowMax board ]project ] ]Am 2015-02-04 19:27, schrieb Yang, York: ]> I was told that to build an UEFI payload need to get two components ]> from different sites, sounds I got some information out-of-date. I ]> will try getting the corebootPkg and then build a payload myself. ]corebootPkg is very likely a different project from yours. There are several attempts ]to make Tianocore into a payload. ] ]The thing is, if you want to make it easier on MinnowMax users, you (or anyone else) ]could open an account on github, fork the Tianocore repository there ](https://github.com/tianocore/edk2) ]and integrate the stuff from firmware.intel.com/develop. ] ]After that, users of that payload version can just pull the entire code with a single ]git clone, too. And participate in the development through github's pull request ]feature and issue tracker. ](Of course, if you want to do this, all this may require some sign-off by your team) ] ]But since that's possible (and really easy, too), there's no need to burden ]coreboot.org with more binaries. ] ]> Understood your point that entire coreboot code must contain source ]> code only. I will share this with inside our team. ]We compromise here and there, but that's not some thing we want to encourage - it is ]really just a compromise, and it's risky to try to push its boundaries. ] ] ]Patrick ]-- -------------- next part -------------- A non-text attachment was scrubbed... Name: payload.patch Type: application/octet-stream Size: 6080 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: build-commands.txt URL: From tpearson at raptorengineeringinc.com Thu Feb 5 19:23:40 2015 From: tpearson at raptorengineeringinc.com (Timothy Pearson) Date: Thu, 05 Feb 2015 12:23:40 -0600 Subject: [coreboot] memtest86 reading 0k memory Message-ID: <54D3B52C.2090904@raptorengineeringinc.com> All, I have a board here that loads memtest86 but won't actually test memory. This is the output: Memtest86+ v2.11 AMD K10 CPU @ 2312 MHz L1 Cache: 64K 35028 MB/s L2 Cache: 512K 6963 MB/s L3 Cache: 2048K 6052 MB/s Memory : 0K |------------------------------------------------- Chipset : 0K LinuxBIOS I'm guessing memtest86 doesn't understand coreboot's memory tables/structure, but I have no idea why that would be. The e820 map is valid: e820: BIOS-provided physical RAM map: BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved BIOS-e820: [mem 0x0000000000100000-0x000000003ffacfff] usable BIOS-e820: [mem 0x000000003ffad000-0x000000003fffffff] reserved BIOS-e820: [mem 0x00000000e0000000-0x00000000efffffff] reserved Any ideas? Other than this one irritating glitch coreboot is working perfectly on this board. Thanks! -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 http://www.raptorengineeringinc.com From jakllsch at kollasch.net Thu Feb 5 19:38:32 2015 From: jakllsch at kollasch.net (Jonathan A. Kollasch) Date: Thu, 5 Feb 2015 12:38:32 -0600 Subject: [coreboot] memtest86 reading 0k memory In-Reply-To: <54D3B52C.2090904@raptorengineeringinc.com> References: <54D3B52C.2090904@raptorengineeringinc.com> Message-ID: <20150205183815.GE2885@tazenda.kollasch.net> On Thu, Feb 05, 2015 at 12:23:40PM -0600, Timothy Pearson wrote: > All, > > I have a board here that loads memtest86 but won't actually test memory. > > This is the output: > > Memtest86+ v2.11 > AMD K10 CPU @ 2312 MHz > L1 Cache: 64K 35028 MB/s > L2 Cache: 512K 6963 MB/s > L3 Cache: 2048K 6052 MB/s > Memory : 0K |------------------------------------------------- > Chipset : > > > > > 0K LinuxBIOS > > > > I'm guessing memtest86 doesn't understand coreboot's memory > tables/structure, but I have no idea why that would be. The e820 > map is valid: > e820: BIOS-provided physical RAM map: > BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable > BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved > BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved > BIOS-e820: [mem 0x0000000000100000-0x000000003ffacfff] usable > BIOS-e820: [mem 0x000000003ffad000-0x000000003fffffff] reserved > BIOS-e820: [mem 0x00000000e0000000-0x00000000efffffff] reserved > > Any ideas? Other than this one irritating glitch coreboot is > working perfectly on this board. That's a pretty old memtest86+. Also, memtest86+ prefers linuxbios/coreboot memory map to e820. This becomes a problem when SeaBIOS sets up a USB controller to DMA to e820-reserved memory that wasn't reserved by coreboot. Try a modern memtest86+ with the coreboot table probe patched out. Jonathan Kollasch From tpearson at raptorengineeringinc.com Thu Feb 5 19:48:25 2015 From: tpearson at raptorengineeringinc.com (Timothy Pearson) Date: Thu, 05 Feb 2015 12:48:25 -0600 Subject: [coreboot] memtest86 reading 0k memory In-Reply-To: <20150205183815.GE2885@tazenda.kollasch.net> References: <54D3B52C.2090904@raptorengineeringinc.com> <20150205183815.GE2885@tazenda.kollasch.net> Message-ID: <54D3BAF9.9040605@raptorengineeringinc.com> On 02/05/2015 12:38 PM, Jonathan A. Kollasch wrote: > That's a pretty old memtest86+. Also, memtest86+ prefers > linuxbios/coreboot memory map to e820. This becomes a problem > when SeaBIOS sets up a USB controller to DMA to e820-reserved > memory that wasn't reserved by coreboot. > > Try a modern memtest86+ with the coreboot table probe patched out. > > Jonathan Kollasch Yep, that was it. Didn't catch the obsolete version number. I'm trying to figure out the point of memtest86 reading the coreboot tables. It doesn't help that the coreboot tables / e820 map are apparently wrong; memtest86+ almost immediately started stepping on the lower MMIO regions (e.g. 0xb800) rendering the display mostly useless. Interestingly Linux doesn't seem to have any problems; I'll need to investigate further. -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 http://www.raptorengineeringinc.com From adurbin at google.com Thu Feb 5 19:59:43 2015 From: adurbin at google.com (Aaron Durbin) Date: Thu, 5 Feb 2015 12:59:43 -0600 Subject: [coreboot] memtest86 reading 0k memory In-Reply-To: <54D3BAF9.9040605@raptorengineeringinc.com> References: <54D3B52C.2090904@raptorengineeringinc.com> <20150205183815.GE2885@tazenda.kollasch.net> <54D3BAF9.9040605@raptorengineeringinc.com> Message-ID: On Thu, Feb 5, 2015 at 12:48 PM, Timothy Pearson wrote: > On 02/05/2015 12:38 PM, Jonathan A. Kollasch wrote: >> >> That's a pretty old memtest86+. Also, memtest86+ prefers >> linuxbios/coreboot memory map to e820. This becomes a problem >> when SeaBIOS sets up a USB controller to DMA to e820-reserved >> memory that wasn't reserved by coreboot. >> >> Try a modern memtest86+ with the coreboot table probe patched out. >> >> Jonathan Kollasch > > > Yep, that was it. Didn't catch the obsolete version number. > > I'm trying to figure out the point of memtest86 reading the coreboot tables. > It doesn't help that the coreboot tables / e820 map are apparently wrong; > memtest86+ almost immediately started stepping on the lower MMIO regions > (e.g. 0xb800) rendering the display mostly useless. Interestingly Linux > doesn't seem to have any problems; I'll need to investigate further. > Your e820 looks fine to me. memtest86 should just be testing the usable regions. Since b800 isn't in there, the only issue that could arise is it using that physical address as a mmio bar. However, that'd be an OS level thing, and I wouldn't expect the memtest86 doing any such things. It sounds more like it does a merge of some sort with e820 and its notion of valid memory instead relying on e820 proper. > -- > Timothy Pearson > Raptor Engineering > +1 (415) 727-8645 > http://www.raptorengineeringinc.com > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot From tpearson at raptorengineeringinc.com Thu Feb 5 20:15:30 2015 From: tpearson at raptorengineeringinc.com (Timothy Pearson) Date: Thu, 05 Feb 2015 13:15:30 -0600 Subject: [coreboot] memtest86 reading 0k memory In-Reply-To: References: <54D3B52C.2090904@raptorengineeringinc.com> <20150205183815.GE2885@tazenda.kollasch.net> <54D3BAF9.9040605@raptorengineeringinc.com> Message-ID: <54D3C152.9050609@raptorengineeringinc.com> On 02/05/2015 12:59 PM, Aaron Durbin wrote: > On Thu, Feb 5, 2015 at 12:48 PM, Timothy Pearson > wrote: >> On 02/05/2015 12:38 PM, Jonathan A. Kollasch wrote: >>> >>> That's a pretty old memtest86+. Also, memtest86+ prefers >>> linuxbios/coreboot memory map to e820. This becomes a problem >>> when SeaBIOS sets up a USB controller to DMA to e820-reserved >>> memory that wasn't reserved by coreboot. >>> >>> Try a modern memtest86+ with the coreboot table probe patched out. >>> >>> Jonathan Kollasch >> >> >> Yep, that was it. Didn't catch the obsolete version number. >> >> I'm trying to figure out the point of memtest86 reading the coreboot tables. >> It doesn't help that the coreboot tables / e820 map are apparently wrong; >> memtest86+ almost immediately started stepping on the lower MMIO regions >> (e.g. 0xb800) rendering the display mostly useless. Interestingly Linux >> doesn't seem to have any problems; I'll need to investigate further. >> > > Your e820 looks fine to me. memtest86 should just be testing the > usable regions. Since b800 isn't in there, the only issue that could > arise is it using that physical address as a mmio bar. However, that'd > be an OS level thing, and I wouldn't expect the memtest86 doing any > such things. It sounds more like it does a merge of some sort with > e820 and its notion of valid memory instead relying on e820 proper. > Thanks for the information. The e820 map is comparable to the one generated from the proprietary BIOS so I agree it is likely correct. That leaves the coreboot tables themselves and/or memtest86's interpretation of them. BTW it looks I am not the only one to have run into this: http://www.coreboot.org/pipermail/coreboot/2010-December/062245.html At this point I'm not sure if the bug is in coreboot, SeaBIOS, or memtest86. -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 http://www.raptorengineeringinc.com From adurbin at chromium.org Thu Feb 5 20:51:28 2015 From: adurbin at chromium.org (Aaron Durbin) Date: Thu, 5 Feb 2015 13:51:28 -0600 Subject: [coreboot] memtest86 reading 0k memory In-Reply-To: <54D3C152.9050609@raptorengineeringinc.com> References: <54D3B52C.2090904@raptorengineeringinc.com> <20150205183815.GE2885@tazenda.kollasch.net> <54D3BAF9.9040605@raptorengineeringinc.com> <54D3C152.9050609@raptorengineeringinc.com> Message-ID: On Thu, Feb 5, 2015 at 1:15 PM, Timothy Pearson wrote: > On 02/05/2015 12:59 PM, Aaron Durbin wrote: >> >> On Thu, Feb 5, 2015 at 12:48 PM, Timothy Pearson >> wrote: >>> >>> On 02/05/2015 12:38 PM, Jonathan A. Kollasch wrote: >>>> >>>> >>>> That's a pretty old memtest86+. Also, memtest86+ prefers >>>> linuxbios/coreboot memory map to e820. This becomes a problem >>>> when SeaBIOS sets up a USB controller to DMA to e820-reserved >>>> memory that wasn't reserved by coreboot. >>>> >>>> Try a modern memtest86+ with the coreboot table probe patched out. >>>> >>>> Jonathan Kollasch >>> >>> >>> >>> Yep, that was it. Didn't catch the obsolete version number. >>> >>> I'm trying to figure out the point of memtest86 reading the coreboot >>> tables. >>> It doesn't help that the coreboot tables / e820 map are apparently wrong; >>> memtest86+ almost immediately started stepping on the lower MMIO regions >>> (e.g. 0xb800) rendering the display mostly useless. Interestingly Linux >>> doesn't seem to have any problems; I'll need to investigate further. >>> >> >> Your e820 looks fine to me. memtest86 should just be testing the >> usable regions. Since b800 isn't in there, the only issue that could >> arise is it using that physical address as a mmio bar. However, that'd >> be an OS level thing, and I wouldn't expect the memtest86 doing any >> such things. It sounds more like it does a merge of some sort with >> e820 and its notion of valid memory instead relying on e820 proper. >> > > Thanks for the information. The e820 map is comparable to the one generated > from the proprietary BIOS so I agree it is likely correct. That leaves the > coreboot tables themselves and/or memtest86's interpretation of them. > > BTW it looks I am not the only one to have run into this: > http://www.coreboot.org/pipermail/coreboot/2010-December/062245.html > > At this point I'm not sure if the bug is in coreboot, SeaBIOS, or memtest86. Do you have the coreboot console log? Looking at memtest86 it constructs its own e820 when using linuxbios. Additionally, it also has some concept of a "window" to test as well as plim_lower and plim_upper variables that seem to add to the mix. What's super frightening is that find_chunks(int tst) is called in the code as find_chunks() while the find_chunks() function actually references tst as an array index. That's all from config.c. But I think that's only if you hit c on the keyboard. I wouldn't do that... I can't make heads or tails of that code at the moment. for selecting the window to test. > > -- > Timothy Pearson > Raptor Engineering > +1 (415) 727-8645 > http://www.raptorengineeringinc.com > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot From tpearson at raptorengineeringinc.com Thu Feb 5 21:06:10 2015 From: tpearson at raptorengineeringinc.com (Timothy Pearson) Date: Thu, 05 Feb 2015 14:06:10 -0600 Subject: [coreboot] memtest86 reading 0k memory In-Reply-To: References: <54D3B52C.2090904@raptorengineeringinc.com> <20150205183815.GE2885@tazenda.kollasch.net> <54D3BAF9.9040605@raptorengineeringinc.com> <54D3C152.9050609@raptorengineeringinc.com> Message-ID: <54D3CD32.6090604@raptorengineeringinc.com> On 02/05/2015 01:51 PM, Aaron Durbin wrote: > Do you have the coreboot console log? Looking at memtest86 it > constructs its own e820 when using linuxbios. Additionally, it also > has some concept of a "window" to test as well as plim_lower and > plim_upper variables that seem to add to the mix. > > What's super frightening is that find_chunks(int tst) is called in the > code as find_chunks() while the find_chunks() function actually > references tst as an array index. That's all from config.c. But I > think that's only if you hit c on the keyboard. I wouldn't do that... > > I can't make heads or tails of that code at the moment. for selecting > the window to test. Please see text log attached. It looks like the failing accesses start at 0xa0000, which (judging by memtest's effects on the screen) appears to be mapped to the VGA text buffer. That region is *not* reserved under the proprietary BIOS's e820 map. Thanks! -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 http://www.raptorengineeringinc.com -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: memtest86_failure.txt URL: From tpearson at raptorengineeringinc.com Fri Feb 6 01:42:53 2015 From: tpearson at raptorengineeringinc.com (Timothy Pearson) Date: Thu, 05 Feb 2015 18:42:53 -0600 Subject: [coreboot] memtest86 reading 0k memory In-Reply-To: <54D3CD32.6090604@raptorengineeringinc.com> References: <54D3B52C.2090904@raptorengineeringinc.com> <20150205183815.GE2885@tazenda.kollasch.net> <54D3BAF9.9040605@raptorengineeringinc.com> <54D3C152.9050609@raptorengineeringinc.com> <54D3CD32.6090604@raptorengineeringinc.com> Message-ID: <54D40E0D.1000806@raptorengineeringinc.com> On 02/05/2015 02:06 PM, Timothy Pearson wrote: > On 02/05/2015 01:51 PM, Aaron Durbin wrote: >> Do you have the coreboot console log? Looking at memtest86 it >> constructs its own e820 when using linuxbios. Additionally, it also >> has some concept of a "window" to test as well as plim_lower and >> plim_upper variables that seem to add to the mix. >> >> What's super frightening is that find_chunks(int tst) is called in the >> code as find_chunks() while the find_chunks() function actually >> references tst as an array index. That's all from config.c. But I >> think that's only if you hit c on the keyboard. I wouldn't do that... >> >> I can't make heads or tails of that code at the moment. for selecting >> the window to test. > > Please see text log attached. It looks like the failing accesses start > at 0xa0000, which (judging by memtest's effects on the screen) appears > to be mapped to the VGA text buffer. That region is *not* reserved under > the proprietary BIOS's e820 map. > > Thanks! > I was able to resolve the lower MMIO region failures (coreboot driver patch in for review), but memtest86 is stubbornly insisting on testing reserved memory, causing a single failure at 3ffade80. The e820 map says that address is out of bounds but the coreboot tables do not: e820 map has 6 items: 0: 0000000000000000 - 000000000009fc00 = 1 RAM 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED 3: 0000000000100000 - 000000003ffad000 = 1 RAM 4: 000000003ffad000 - 0000000040000000 = 2 RESERVED 5: 00000000e0000000 - 00000000f0000000 = 2 RESERVED coreboot table: 460 bytes. CBMEM ROOT 0. 3ffff000 00001000 CONSOLE 1. 3ffdf000 00020000 TIME STAMP 2. 3ffde000 00001000 GDT 3. 3ffdd000 00001000 SMP TABLE 4. 3ffdc000 00001000 ACPI 5. 3ffb8000 00024000 SMBIOS 6. 3ffb7000 00001000 COREBOOT 7. 3ffaf000 00008000 Why the discrepancy? Am I correct in assuming this is a bug in coreboot that needs to be fixed? -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 http://www.raptorengineeringinc.com From tpearson at raptorengineeringinc.com Fri Feb 6 01:48:30 2015 From: tpearson at raptorengineeringinc.com (Timothy Pearson) Date: Thu, 05 Feb 2015 18:48:30 -0600 Subject: [coreboot] memtest86 reading 0k memory In-Reply-To: <54D40E0D.1000806@raptorengineeringinc.com> References: <54D3B52C.2090904@raptorengineeringinc.com> <20150205183815.GE2885@tazenda.kollasch.net> <54D3BAF9.9040605@raptorengineeringinc.com> <54D3C152.9050609@raptorengineeringinc.com> <54D3CD32.6090604@raptorengineeringinc.com> <54D40E0D.1000806@raptorengineeringinc.com> Message-ID: <54D40F5E.7050607@raptorengineeringinc.com> On 02/05/2015 06:42 PM, Timothy Pearson wrote: > On 02/05/2015 02:06 PM, Timothy Pearson wrote: >> On 02/05/2015 01:51 PM, Aaron Durbin wrote: >>> Do you have the coreboot console log? Looking at memtest86 it >>> constructs its own e820 when using linuxbios. Additionally, it also >>> has some concept of a "window" to test as well as plim_lower and >>> plim_upper variables that seem to add to the mix. >>> >>> What's super frightening is that find_chunks(int tst) is called in the >>> code as find_chunks() while the find_chunks() function actually >>> references tst as an array index. That's all from config.c. But I >>> think that's only if you hit c on the keyboard. I wouldn't do that... >>> >>> I can't make heads or tails of that code at the moment. for selecting >>> the window to test. >> >> Please see text log attached. It looks like the failing accesses start >> at 0xa0000, which (judging by memtest's effects on the screen) appears >> to be mapped to the VGA text buffer. That region is *not* reserved under >> the proprietary BIOS's e820 map. >> >> Thanks! >> > > I was able to resolve the lower MMIO region failures (coreboot driver > patch in for review), but memtest86 is stubbornly insisting on testing > reserved memory, causing a single failure at 3ffade80. The e820 map says > that address is out of bounds but the coreboot tables do not: > > e820 map has 6 items: > 0: 0000000000000000 - 000000000009fc00 = 1 RAM > 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED > 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED > 3: 0000000000100000 - 000000003ffad000 = 1 RAM > 4: 000000003ffad000 - 0000000040000000 = 2 RESERVED > 5: 00000000e0000000 - 00000000f0000000 = 2 RESERVED > > coreboot table: 460 bytes. > CBMEM ROOT 0. 3ffff000 00001000 > CONSOLE 1. 3ffdf000 00020000 > TIME STAMP 2. 3ffde000 00001000 > GDT 3. 3ffdd000 00001000 > SMP TABLE 4. 3ffdc000 00001000 > ACPI 5. 3ffb8000 00024000 > SMBIOS 6. 3ffb7000 00001000 > COREBOOT 7. 3ffaf000 00008000 > > Why the discrepancy? Am I correct in assuming this is a bug in coreboot > that needs to be fixed? > Sorry, wrong coreboot table above: Writing coreboot table at 0x3ffaf000 rom_table_end = 0x3ffaf000 ... aligned to 0x3ffb0000 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000009ffff: RAM 2. 00000000000a0000-00000000000affff: RESERVED 3. 00000000000b0000-00000000000b7fff: RAM 4. 00000000000b8000-00000000000bffff: RESERVED 5. 00000000000c0000-000000003ffaefff: RAM 6. 000000003ffaf000-000000003fffffff: CONFIGURATION TABLES 7. 00000000e0000000-00000000efffffff: RESERVED I assume something is placing itself at 3ffad000 (coreboot? SeaBIOS?) and that overwriting it is a Bad Thing, but whatever it is does not update the coreboot tables and memtest86 promptly stomps on it. -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 http://www.raptorengineeringinc.com From scott at notabs.org Fri Feb 6 04:13:06 2015 From: scott at notabs.org (Scott Duplichan) Date: Thu, 5 Feb 2015 21:13:06 -0600 Subject: [coreboot] memtest86 reading 0k memory In-Reply-To: <54D40F5E.7050607@raptorengineeringinc.com> References: <54D3B52C.2090904@raptorengineeringinc.com> <20150205183815.GE2885@tazenda.kollasch.net> <54D3BAF9.9040605@raptorengineeringinc.com> <54D3C152.9050609@raptorengineeringinc.com> <54D3CD32.6090604@raptorengineeringinc.com> <54D40E0D.1000806@raptorengineeringinc.com> <54D40F5E.7050607@raptorengineeringinc.com> Message-ID: <000001d041ba$d51cc7a0$7f5656e0$@notabs.org> Timothy Pearson [mailto:tpearson at raptorengineeringinc.com] wrote: ]Sent: Thursday, February 05, 2015 06:49 PM ]To: Coreboot ]Subject: Re: [coreboot] memtest86 reading 0k memory ] ]On 02/05/2015 06:42 PM, Timothy Pearson wrote: ]> On 02/05/2015 02:06 PM, Timothy Pearson wrote: ]>> On 02/05/2015 01:51 PM, Aaron Durbin wrote: ]>>> Do you have the coreboot console log? Looking at memtest86 it ]>>> constructs its own e820 when using linuxbios. Additionally, it also ]>>> has some concept of a "window" to test as well as plim_lower and ]>>> plim_upper variables that seem to add to the mix. ]>>> ]>>> What's super frightening is that find_chunks(int tst) is called in the ]>>> code as find_chunks() while the find_chunks() function actually ]>>> references tst as an array index. That's all from config.c. But I ]>>> think that's only if you hit c on the keyboard. I wouldn't do that... ]>>> ]>>> I can't make heads or tails of that code at the moment. for selecting ]>>> the window to test. ]>> ]>> Please see text log attached. It looks like the failing accesses start ]>> at 0xa0000, which (judging by memtest's effects on the screen) appears ]>> to be mapped to the VGA text buffer. That region is *not* reserved under ]>> the proprietary BIOS's e820 map. ]>> ]>> Thanks! ]>> ]> ]> I was able to resolve the lower MMIO region failures (coreboot driver ]> patch in for review), but memtest86 is stubbornly insisting on testing ]> reserved memory, causing a single failure at 3ffade80. The e820 map says ]> that address is out of bounds but the coreboot tables do not: ]> ]> e820 map has 6 items: ]> 0: 0000000000000000 - 000000000009fc00 = 1 RAM ]> 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED ]> 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED ]> 3: 0000000000100000 - 000000003ffad000 = 1 RAM ]> 4: 000000003ffad000 - 0000000040000000 = 2 RESERVED ]> 5: 00000000e0000000 - 00000000f0000000 = 2 RESERVED ]> ]> coreboot table: 460 bytes. ]> CBMEM ROOT 0. 3ffff000 00001000 ]> CONSOLE 1. 3ffdf000 00020000 ]> TIME STAMP 2. 3ffde000 00001000 ]> GDT 3. 3ffdd000 00001000 ]> SMP TABLE 4. 3ffdc000 00001000 ]> ACPI 5. 3ffb8000 00024000 ]> SMBIOS 6. 3ffb7000 00001000 ]> COREBOOT 7. 3ffaf000 00008000 ]> ]> Why the discrepancy? Am I correct in assuming this is a bug in coreboot ]> that needs to be fixed? ]> ] ]Sorry, wrong coreboot table above: ] ]Writing coreboot table at 0x3ffaf000 ]rom_table_end = 0x3ffaf000 ]... aligned to 0x3ffb0000 ] 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES ] 1. 0000000000001000-000000000009ffff: RAM ] 2. 00000000000a0000-00000000000affff: RESERVED ] 3. 00000000000b0000-00000000000b7fff: RAM ] 4. 00000000000b8000-00000000000bffff: RESERVED ] 5. 00000000000c0000-000000003ffaefff: RAM ] 6. 000000003ffaf000-000000003fffffff: CONFIGURATION TABLES ] 7. 00000000e0000000-00000000efffffff: RESERVED ] ]I assume something is placing itself at 3ffad000 (coreboot? SeaBIOS?) ]and that overwriting it is a Bad Thing, but whatever it is does not ]update the coreboot tables and memtest86 promptly stomps on it. I imagine SeaBIOS is taking memory from the end of free RAM below 4GB for USB structures. There is probably an incrementing frame counter at 3ffade80. It looks like SeaBIOS builds the E820 table to properly account for the memory it uses. If memtest86 uses the coreboot tables even when an E820 handler is installed, that seems wrong. Unless SeaBIOS is supposed to adjust the coreboot tables to reflect its memory usage, which I don't think is the case. ]-- ]Timothy Pearson ]Raptor Engineering ]+1 (415) 727-8645 ]http://www.raptorengineeringinc.com From tpearson at raptorengineeringinc.com Fri Feb 6 04:45:25 2015 From: tpearson at raptorengineeringinc.com (Timothy Pearson) Date: Thu, 05 Feb 2015 21:45:25 -0600 Subject: [coreboot] memtest86 reading 0k memory In-Reply-To: <000001d041ba$d51cc7a0$7f5656e0$@notabs.org> References: <54D3B52C.2090904@raptorengineeringinc.com> <20150205183815.GE2885@tazenda.kollasch.net> <54D3BAF9.9040605@raptorengineeringinc.com> <54D3C152.9050609@raptorengineeringinc.com> <54D3CD32.6090604@raptorengineeringinc.com> <54D40E0D.1000806@raptorengineeringinc.com> <54D40F5E.7050607@raptorengineeringinc.com> <000001d041ba$d51cc7a0$7f5656e0$@notabs.org> Message-ID: <54D438D5.5060709@raptorengineeringinc.com> On 02/05/2015 09:13 PM, Scott Duplichan wrote: > Timothy Pearson [mailto:tpearson at raptorengineeringinc.com] wrote: > > ]Sent: Thursday, February 05, 2015 06:49 PM > ]To: Coreboot > ]Subject: Re: [coreboot] memtest86 reading 0k memory > ] > ]On 02/05/2015 06:42 PM, Timothy Pearson wrote: > ]> On 02/05/2015 02:06 PM, Timothy Pearson wrote: > ]>> On 02/05/2015 01:51 PM, Aaron Durbin wrote: > ]>>> Do you have the coreboot console log? Looking at memtest86 it > ]>>> constructs its own e820 when using linuxbios. Additionally, it also > ]>>> has some concept of a "window" to test as well as plim_lower and > ]>>> plim_upper variables that seem to add to the mix. > ]>>> > ]>>> What's super frightening is that find_chunks(int tst) is called in the > ]>>> code as find_chunks() while the find_chunks() function actually > ]>>> references tst as an array index. That's all from config.c. But I > ]>>> think that's only if you hit c on the keyboard. I wouldn't do that... > ]>>> > ]>>> I can't make heads or tails of that code at the moment. for selecting > ]>>> the window to test. > ]>> > ]>> Please see text log attached. It looks like the failing accesses start > ]>> at 0xa0000, which (judging by memtest's effects on the screen) appears > ]>> to be mapped to the VGA text buffer. That region is *not* reserved under > ]>> the proprietary BIOS's e820 map. > ]>> > ]>> Thanks! > ]>> > ]> > ]> I was able to resolve the lower MMIO region failures (coreboot driver > ]> patch in for review), but memtest86 is stubbornly insisting on testing > ]> reserved memory, causing a single failure at 3ffade80. The e820 map says > ]> that address is out of bounds but the coreboot tables do not: > ]> > ]> e820 map has 6 items: > ]> 0: 0000000000000000 - 000000000009fc00 = 1 RAM > ]> 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED > ]> 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED > ]> 3: 0000000000100000 - 000000003ffad000 = 1 RAM > ]> 4: 000000003ffad000 - 0000000040000000 = 2 RESERVED > ]> 5: 00000000e0000000 - 00000000f0000000 = 2 RESERVED > ]> > ]> coreboot table: 460 bytes. > ]> CBMEM ROOT 0. 3ffff000 00001000 > ]> CONSOLE 1. 3ffdf000 00020000 > ]> TIME STAMP 2. 3ffde000 00001000 > ]> GDT 3. 3ffdd000 00001000 > ]> SMP TABLE 4. 3ffdc000 00001000 > ]> ACPI 5. 3ffb8000 00024000 > ]> SMBIOS 6. 3ffb7000 00001000 > ]> COREBOOT 7. 3ffaf000 00008000 > ]> > ]> Why the discrepancy? Am I correct in assuming this is a bug in coreboot > ]> that needs to be fixed? > ]> > ] > ]Sorry, wrong coreboot table above: > ] > ]Writing coreboot table at 0x3ffaf000 > ]rom_table_end = 0x3ffaf000 > ]... aligned to 0x3ffb0000 > ] 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES > ] 1. 0000000000001000-000000000009ffff: RAM > ] 2. 00000000000a0000-00000000000affff: RESERVED > ] 3. 00000000000b0000-00000000000b7fff: RAM > ] 4. 00000000000b8000-00000000000bffff: RESERVED > ] 5. 00000000000c0000-000000003ffaefff: RAM > ] 6. 000000003ffaf000-000000003fffffff: CONFIGURATION TABLES > ] 7. 00000000e0000000-00000000efffffff: RESERVED > ] > ]I assume something is placing itself at 3ffad000 (coreboot? SeaBIOS?) > ]and that overwriting it is a Bad Thing, but whatever it is does not > ]update the coreboot tables and memtest86 promptly stomps on it. > > I imagine SeaBIOS is taking memory from the end of free RAM below > 4GB for USB structures. There is probably an incrementing frame > counter at 3ffade80. It looks like SeaBIOS builds the E820 table > to properly account for the memory it uses. If memtest86 uses the > coreboot tables even when an E820 handler is installed, that seems > wrong. Unless SeaBIOS is supposed to adjust the coreboot tables to > reflect its memory usage, which I don't think is the case. I suspect you're right about the USB structures; my USB keyboard quit working when memtest started. Looks like I'll be building memtest86 with coreboot support disabled; judging by the numerous problems reported by other coreboot users memtest badly needs an update to disable coreboot support by default. -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 http://www.raptorengineeringinc.com From bo.bergman at winzenttech.com Fri Feb 6 10:06:42 2015 From: bo.bergman at winzenttech.com (Berth-Olof Bergman) Date: Fri, 6 Feb 2015 10:06:42 +0100 Subject: [coreboot] Bay trail and SATA legacy IDE mode Message-ID: <677ED26A-3682-4DF4-9990-CB9A6E326E07@winzenttech.com> Hi all, Has anyone run a Bay Trail SOC in SATA legacy IDE mode? It doesn?t work on my boards, even though I have identical settings of the PCI configuration space as AMI and Phoenix BIOS. The port works, but the IRQs are wrong polarity. Thus when issuing a command, I don?t get an interrupt. If I read the IDE status register (alternate or main) I get an interrupt. As reading the IDE status register, negates interrupt, I get the high level edge as the polarity is inverted. Can you verify if IDE legacy mode works for Bay Trail with correct? Best regards, B-O Bergman Winzent Technologies From stefan.tauner at alumni.tuwien.ac.at Fri Feb 6 10:23:58 2015 From: stefan.tauner at alumni.tuwien.ac.at (Stefan Tauner) Date: Fri, 6 Feb 2015 10:23:58 +0100 Subject: [coreboot] Plans for upcoming Broadwell Thinkpads Message-ID: <201502060923.t169Nwj8030251@mail2.student.tuwien.ac.at> I should probably not post about any Thinkpads till I get to test the T410s port... but anyway has anybody considered a port for the incoming Broadwell Thinkpads - especially the T450s? It would definitely be a plus to know that there will be others hacking at it as well before buying ;) -- Kind regards/Mit freundlichen Gr??en, Stefan Tauner From zaolin at das-labor.org Fri Feb 6 13:29:02 2015 From: zaolin at das-labor.org (Zaolin) Date: Fri, 06 Feb 2015 13:29:02 +0100 Subject: [coreboot] Plans for upcoming Broadwell Thinkpads In-Reply-To: <201502060923.t169Nwj8030251@das-labor.org> References: <201502060923.t169Nwj8030251@das-labor.org> Message-ID: <54D4B38E.5090009@das-labor.org> Hi, new thinkpad's can't be used anymore for coreboot. Especially the U and Y Intel CPU Series. They come with Intel Boot Guard and you are won't be able to boot anything which is unsigned and not approved by OEM. This means the OEM are fusing SHA256 public key hashes into the southbridge. For more details take a look at Intel Boot Guard architecture. It could be also confirmed by Secunet AG and Google. Regards Zaolin > I should probably not post about any Thinkpads till I get to test the > T410s port... but anyway has anybody considered a port for the incoming > Broadwell Thinkpads - especially the T450s? It would definitely be a > plus to know that there will be others hacking at it as well before > buying ;) > From tpearson at raptorengineeringinc.com Fri Feb 6 18:16:48 2015 From: tpearson at raptorengineeringinc.com (Timothy Pearson) Date: Fri, 06 Feb 2015 11:16:48 -0600 Subject: [coreboot] Plans for upcoming Broadwell Thinkpads In-Reply-To: <54D4B38E.5090009@das-labor.org> References: <201502060923.t169Nwj8030251@das-labor.org> <54D4B38E.5090009@das-labor.org> Message-ID: <54D4F700.2090404@raptorengineeringinc.com> On 02/06/2015 06:29 AM, Zaolin wrote: > Hi, > > new thinkpad's can't be used anymore for coreboot. Especially the U and > Y Intel CPU Series. > They come with Intel Boot Guard and you are won't be able to boot > anything which is unsigned and > not approved by OEM. This means the OEM are fusing SHA256 public key > hashes into the southbridge. > > For more details take a look at Intel Boot Guard architecture. It could > be also confirmed by Secunet AG and Google. > > Regards Zaolin That's scary to say the least. No more Thinkpads for us... From tpearson at raptorengineeringinc.com Fri Feb 6 19:06:38 2015 From: tpearson at raptorengineeringinc.com (Timothy Pearson) Date: Fri, 06 Feb 2015 12:06:38 -0600 Subject: [coreboot] memtest86 reading 0k memory In-Reply-To: <54D438D5.5060709@raptorengineeringinc.com> References: <54D3B52C.2090904@raptorengineeringinc.com> <20150205183815.GE2885@tazenda.kollasch.net> <54D3BAF9.9040605@raptorengineeringinc.com> <54D3C152.9050609@raptorengineeringinc.com> <54D3CD32.6090604@raptorengineeringinc.com> <54D40E0D.1000806@raptorengineeringinc.com> <54D40F5E.7050607@raptorengineeringinc.com> <000001d041ba$d51cc7a0$7f5656e0$@notabs.org> <54D438D5.5060709@raptorengineeringinc.com> Message-ID: <54D502AE.1070306@raptorengineeringinc.com> On 02/05/2015 09:45 PM, Timothy Pearson wrote: > On 02/05/2015 09:13 PM, Scott Duplichan wrote: >> Timothy Pearson [mailto:tpearson at raptorengineeringinc.com] wrote: >> >> ]Sent: Thursday, February 05, 2015 06:49 PM >> ]To: Coreboot >> ]Subject: Re: [coreboot] memtest86 reading 0k memory >> ] >> ]On 02/05/2015 06:42 PM, Timothy Pearson wrote: >> ]> On 02/05/2015 02:06 PM, Timothy Pearson wrote: >> ]>> On 02/05/2015 01:51 PM, Aaron Durbin wrote: >> ]>>> Do you have the coreboot console log? Looking at memtest86 it >> ]>>> constructs its own e820 when using linuxbios. Additionally, it also >> ]>>> has some concept of a "window" to test as well as plim_lower and >> ]>>> plim_upper variables that seem to add to the mix. >> ]>>> >> ]>>> What's super frightening is that find_chunks(int tst) is called >> in the >> ]>>> code as find_chunks() while the find_chunks() function actually >> ]>>> references tst as an array index. That's all from config.c. But I >> ]>>> think that's only if you hit c on the keyboard. I wouldn't do >> that... >> ]>>> >> ]>>> I can't make heads or tails of that code at the moment. for >> selecting >> ]>>> the window to test. >> ]>> >> ]>> Please see text log attached. It looks like the failing accesses >> start >> ]>> at 0xa0000, which (judging by memtest's effects on the screen) >> appears >> ]>> to be mapped to the VGA text buffer. That region is *not* reserved >> under >> ]>> the proprietary BIOS's e820 map. >> ]>> >> ]>> Thanks! >> ]>> >> ]> >> ]> I was able to resolve the lower MMIO region failures (coreboot driver >> ]> patch in for review), but memtest86 is stubbornly insisting on testing >> ]> reserved memory, causing a single failure at 3ffade80. The e820 map >> says >> ]> that address is out of bounds but the coreboot tables do not: >> ]> >> ]> e820 map has 6 items: >> ]> 0: 0000000000000000 - 000000000009fc00 = 1 RAM >> ]> 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED >> ]> 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED >> ]> 3: 0000000000100000 - 000000003ffad000 = 1 RAM >> ]> 4: 000000003ffad000 - 0000000040000000 = 2 RESERVED >> ]> 5: 00000000e0000000 - 00000000f0000000 = 2 RESERVED >> ]> >> ]> coreboot table: 460 bytes. >> ]> CBMEM ROOT 0. 3ffff000 00001000 >> ]> CONSOLE 1. 3ffdf000 00020000 >> ]> TIME STAMP 2. 3ffde000 00001000 >> ]> GDT 3. 3ffdd000 00001000 >> ]> SMP TABLE 4. 3ffdc000 00001000 >> ]> ACPI 5. 3ffb8000 00024000 >> ]> SMBIOS 6. 3ffb7000 00001000 >> ]> COREBOOT 7. 3ffaf000 00008000 >> ]> >> ]> Why the discrepancy? Am I correct in assuming this is a bug in >> coreboot >> ]> that needs to be fixed? >> ]> >> ] >> ]Sorry, wrong coreboot table above: >> ] >> ]Writing coreboot table at 0x3ffaf000 >> ]rom_table_end = 0x3ffaf000 >> ]... aligned to 0x3ffb0000 >> ] 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES >> ] 1. 0000000000001000-000000000009ffff: RAM >> ] 2. 00000000000a0000-00000000000affff: RESERVED >> ] 3. 00000000000b0000-00000000000b7fff: RAM >> ] 4. 00000000000b8000-00000000000bffff: RESERVED >> ] 5. 00000000000c0000-000000003ffaefff: RAM >> ] 6. 000000003ffaf000-000000003fffffff: CONFIGURATION TABLES >> ] 7. 00000000e0000000-00000000efffffff: RESERVED >> ] >> ]I assume something is placing itself at 3ffad000 (coreboot? SeaBIOS?) >> ]and that overwriting it is a Bad Thing, but whatever it is does not >> ]update the coreboot tables and memtest86 promptly stomps on it. >> >> I imagine SeaBIOS is taking memory from the end of free RAM below >> 4GB for USB structures. There is probably an incrementing frame >> counter at 3ffade80. It looks like SeaBIOS builds the E820 table >> to properly account for the memory it uses. If memtest86 uses the >> coreboot tables even when an E820 handler is installed, that seems >> wrong. Unless SeaBIOS is supposed to adjust the coreboot tables to >> reflect its memory usage, which I don't think is the case. > > I suspect you're right about the USB structures; my USB keyboard quit > working when memtest started. Looks like I'll be building memtest86 with > coreboot support disabled; judging by the numerous problems reported by > other coreboot users memtest badly needs an update to disable coreboot > support by default. > Recompiling memtest with the coreboot table detection bypassed resolved the problem. Thanks for the help! -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 http://www.raptorengineeringinc.com From lynxis at fe80.eu Fri Feb 6 19:23:28 2015 From: lynxis at fe80.eu (Alexander Couzens) Date: Fri, 6 Feb 2015 19:23:28 +0100 Subject: [coreboot] Plans for upcoming Broadwell Thinkpads In-Reply-To: <54D4F700.2090404@raptorengineeringinc.com> References: <201502060923.t169Nwj8030251@das-labor.org> <54D4B38E.5090009@das-labor.org> <54D4F700.2090404@raptorengineeringinc.com> Message-ID: <20150206192328.08367923@lazus.yip> On Fri, 06 Feb 2015 11:16:48 -0600 Timothy Pearson wrote: > On 02/06/2015 06:29 AM, Zaolin wrote: > > Hi, > > > > new thinkpad's can't be used anymore for coreboot. Especially the U and > > Y Intel CPU Series. > > They come with Intel Boot Guard and you are won't be able to boot > > anything which is unsigned and > > not approved by OEM. This means the OEM are fusing SHA256 public key > > hashes into the southbridge. > > > > For more details take a look at Intel Boot Guard architecture. It could > > be also confirmed by Secunet AG and Google. > > > > Regards Zaolin > > That's scary to say the least. No more Thinkpads for us... > Is it used by Lenovo? I think I can boot a USB-Linux on a new Thinkpad within a friendly Lenovo Store. How can it tested? What registers must be read? Best, lynxis -- Alexander Couzens mail: lynxis at fe80.eu jabber: lynxis at jabber.ccc.de mobile: +4915123277221 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From zaolin at das-labor.org Fri Feb 6 21:43:45 2015 From: zaolin at das-labor.org (Zaolin) Date: Fri, 06 Feb 2015 21:43:45 +0100 Subject: [coreboot] Plans for upcoming Broadwell Thinkpads In-Reply-To: <54D4F700.2090404@das-labor.org> References: <201502060923.t169Nwj8030251@das-labor.org> <54D4B38E.5090009@das-labor.org> <54D4F700.2090404@das-labor.org> Message-ID: <1423255425.20993.1.camel@das-labor.org> Hi, let's say goodbye to all Intel notebooks produced by OEM's which are not Google ( Chromebooks ). Maybe the haswell/broadwell notebooks of Lenovo without U/Y processor can be used ( Thinkpad tXX xXX ). It depends if they are supporting Intel Boot Guard on the southbridge... Regards Zaolin > On 02/06/2015 06:29 AM, Zaolin wrote: > > Hi, > > > > new thinkpad's can't be used anymore for coreboot. Especially the U and > > Y Intel CPU Series. > > They come with Intel Boot Guard and you are won't be able to boot > > anything which is unsigned and > > not approved by OEM. This means the OEM are fusing SHA256 public key > > hashes into the southbridge. > > > > For more details take a look at Intel Boot Guard architecture. It could > > be also confirmed by Secunet AG and Google. > > > > Regards Zaolin > > That's scary to say the least. No more Thinkpads for us... > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From zaolin at das-labor.org Fri Feb 6 21:42:30 2015 From: zaolin at das-labor.org (Zaolin) Date: Fri, 06 Feb 2015 21:42:30 +0100 Subject: [coreboot] Plans for upcoming Broadwell Thinkpads In-Reply-To: <54D4F700.2090404@das-labor.org> References: <201502060923.t169Nwj8030251@das-labor.org> <54D4B38E.5090009@das-labor.org> <54D4F700.2090404@das-labor.org> Message-ID: <1423255350.20319.2.camel@das-labor.org> Hi, let's say goodbye to all Intel notebooks produced by OEM's which are not Google ( Chromebooks ). Maybe the haswell/broadwell notebooks of Lenovo without U/Y processor can be used ( Thinkpad tXX xXX ). It depends if they are supporting Intel Boot Guard on the southbridge and if they are locked down... Regards Zaolin > On 02/06/2015 06:29 AM, Zaolin wrote: > > Hi, > > > > new thinkpad's can't be used anymore for coreboot. Especially the U and > > Y Intel CPU Series. > > They come with Intel Boot Guard and you are won't be able to boot > > anything which is unsigned and > > not approved by OEM. This means the OEM are fusing SHA256 public key > > hashes into the southbridge. > > > > For more details take a look at Intel Boot Guard architecture. It could > > be also confirmed by Secunet AG and Google. > > > > Regards Zaolin > > That's scary to say the least. No more Thinkpads for us... > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From tpearson at raptorengineeringinc.com Sat Feb 7 21:14:45 2015 From: tpearson at raptorengineeringinc.com (Timothy Pearson) Date: Sat, 07 Feb 2015 14:14:45 -0600 Subject: [coreboot] Plans for upcoming Broadwell Thinkpads In-Reply-To: <1423255350.20319.2.camel@das-labor.org> References: <201502060923.t169Nwj8030251@das-labor.org> <54D4B38E.5090009@das-labor.org> <54D4F700.2090404@das-labor.org> <1423255350.20319.2.camel@das-labor.org> Message-ID: <54D67235.4000906@raptorengineeringinc.com> On 02/06/2015 02:42 PM, Zaolin wrote: > Hi, > > let's say goodbye to all Intel notebooks produced by OEM's which are not > Google ( Chromebooks ). Maybe the haswell/broadwell notebooks of Lenovo > without U/Y processor can be used ( Thinkpad tXX xXX ). It depends if > they are supporting Intel Boot Guard on the southbridge and if they are > locked down... > > Regards Zaolin >> On 02/06/2015 06:29 AM, Zaolin wrote: >>> Hi, >>> >>> new thinkpad's can't be used anymore for coreboot. Especially the U and >>> Y Intel CPU Series. >>> They come with Intel Boot Guard and you are won't be able to boot >>> anything which is unsigned and >>> not approved by OEM. This means the OEM are fusing SHA256 public key >>> hashes into the southbridge. >>> >>> For more details take a look at Intel Boot Guard architecture. It could >>> be also confirmed by Secunet AG and Google. >>> >>> Regards Zaolin >> >> That's scary to say the least. No more Thinkpads for us... >> > > So the real question is: are there any AMD notebooks on the market with similar build quality to the old IBM Thinkpads? I've about had enough of Intel and their monopolistic ways. -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 http://www.raptorengineeringinc.com From c-d.hailfinger.devel.2006 at gmx.net Sat Feb 7 22:37:10 2015 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 07 Feb 2015 22:37:10 +0100 Subject: [coreboot] Plans for upcoming Broadwell Thinkpads In-Reply-To: <54D67235.4000906@raptorengineeringinc.com> References: <201502060923.t169Nwj8030251@das-labor.org> <54D4B38E.5090009@das-labor.org> <54D4F700.2090404@das-labor.org> <1423255350.20319.2.camel@das-labor.org> <54D67235.4000906@raptorengineeringinc.com> Message-ID: <54D68586.6030507@gmx.net> On 07.02.2015 21:14, Timothy Pearson wrote: > So the real question is: are there any AMD notebooks on the market > with similar build quality to the old IBM Thinkpads? I've about had > enough of Intel and their monopolistic ways. I saw AMD-based HP laptops (Probook/Elitebook) and they are nice (if you don't mind a miniscule return key on the keyboard). The build quality is comparable to newer Thinkpads (sharp edges included). The docking options are a bit limited, though. That said, I do _not_ know if HP is using anything similar to Boot Guard on those laptops. Judging from photos of an opened Elitebook 745 G2, there are two flash chips next to each other, so either it's some sort of Dual BIOS solution or possibly other parity checks or an EC accessing both flash chips. Before you spend 1000 USD on such a machine, it would be wise to make sure you are not being stopped by any AMD/HP equivalent of Boot Guard. Regards, Carl-Daniel From tpearson at raptorengineeringinc.com Sat Feb 7 22:39:49 2015 From: tpearson at raptorengineeringinc.com (Timothy Pearson) Date: Sat, 07 Feb 2015 15:39:49 -0600 Subject: [coreboot] Plans for upcoming Broadwell Thinkpads In-Reply-To: <54D68586.6030507@gmx.net> References: <201502060923.t169Nwj8030251@das-labor.org> <54D4B38E.5090009@das-labor.org> <54D4F700.2090404@das-labor.org> <1423255350.20319.2.camel@das-labor.org> <54D67235.4000906@raptorengineeringinc.com> <54D68586.6030507@gmx.net> Message-ID: <54D68625.3040401@raptorengineeringinc.com> On 02/07/2015 03:37 PM, Carl-Daniel Hailfinger wrote: > On 07.02.2015 21:14, Timothy Pearson wrote: >> So the real question is: are there any AMD notebooks on the market >> with similar build quality to the old IBM Thinkpads? I've about had >> enough of Intel and their monopolistic ways. > > I saw AMD-based HP laptops (Probook/Elitebook) and they are nice (if you > don't mind a miniscule return key on the keyboard). The build quality is > comparable to newer Thinkpads (sharp edges included). The docking > options are a bit limited, though. > > That said, I do _not_ know if HP is using anything similar to Boot Guard > on those laptops. Judging from photos of an opened Elitebook 745 G2, > there are two flash chips next to each other, so either it's some sort > of Dual BIOS solution or possibly other parity checks or an EC accessing > both flash chips. Before you spend 1000 USD on such a machine, it would > be wise to make sure you are not being stopped by any AMD/HP equivalent > of Boot Guard. > > Regards, > Carl-Daniel > We aren't looking at purchasing new laptops right now, but it's almost looking like the Chromebook might be one of the best options for a machine to run fully open-source software. Never used one so I don't know build quality or horsepower however. -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 http://www.raptorengineeringinc.com From c-d.hailfinger.devel.2006 at gmx.net Sun Feb 8 01:07:36 2015 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sun, 08 Feb 2015 01:07:36 +0100 Subject: [coreboot] coreboot code of conduct In-Reply-To: References: <54BB248A.4000300@gmx.net> <54BCF005.6000003@gmx.net> <16ee1bdd15c6779c90ff9cfca022f4c7@mail.georgi-clan.de> <54BEE9E1.504@gmx.net> <54CE1C81.5020101@gmx.net> <68e217820590580bfc94101a692df86f@mail.georgi-clan.de> <54D0A512.7080601@gmx.net> Message-ID: <54D6A8C8.4030705@gmx.net> On 04.02.2015 12:31, Patrick Georgi wrote: > Am 2015-02-03 11:38, schrieb Carl-Daniel Hailfinger: >> The current development guidelines didn't appear overnight, but were >> refined over time without a lockdown on the wiki. > And yet they're mostly useless. > > The CoC wikipage is now unlocked. Let's see what comes of it. Thanks! I changed the wording a bit, reordered some stuff and replaced one of the homegrown definitions with the one used by the UN which is hopefully not objectionable. There is another pending proposal (not by me) which IMHO would be a nice addition: https://www.coreboot.org/Talk:Code_of_Conduct#Some_words_about_assessing_code_quality > Some words about assessing code quality > > Proposal: Add to the list in the chat etiquette something like: 'Code > that you are changing wasn't perfect (or you wouldn't change it). > However, try to avoid assuming that it was written by monkeys, or that > it must have always been broken. It's likely that it used to work and > it's likely that your new work is necessary and important because > circumstances changed where the code didn't.' > > Pros: Remind people that there's a coder behind the code. Assuming bad > intent or stupidity (and doing so publicly) is as much a statement > about the code as about the coder. > > Cons: Is that micromanaging things? The "Mailing list and chat etiquette" section of the CoC already has two related items: > * People who intentionally insult others (users, developers, > corporations, other projects, or the coreboot project itself) will be > dealt with. See policy below. > * We are dealing with hardware with lots of undocumented pitfalls. It > is quite possible that you did everything right, but coreboot or its > tools still won?t work for you. Admittedly some code has always been broken and nobody may have noticed before, but I really do like the "avoid assuming it was written by monkeys" part. Quite a lot of code in coreboot (especially hardware-specific stuff) has been copy-pasted and changed until it worked well enough. Some cleanups have removed code of that type, but there probably still is such code that remains. In flashrom, we do notice from time to time that the remaining really old code was written in an age where some classes of bugs simply weren't widely known and thus the coder could not have known how to avoid them. Sometimes, enough code was written the wrong way to have zero net effect. Yes, head-scratching and exclamations of WTF?!? happen whenever we try to fix or clean up that code. Still, back then the code contribution (patch) seems to have been considered a net positive, otherwise it wouldn't have been merged. For me, this is mostly a question about respecting our elders who didn't have our modern tools and still got things to work. Opinions? Regards, Carl-Daniel From mr.nuke.me at gmail.com Sun Feb 8 19:07:16 2015 From: mr.nuke.me at gmail.com (Alexandru Gagniuc) Date: Sun, 08 Feb 2015 12:07:16 -0600 Subject: [coreboot] code of conduct (reloaded) Message-ID: <2200030.9kBh2SSoN8@nukelap.gtech> This comes in a new thread because my ML membership was somehow hosed coreboot-side, so I have no mail to reply to. I have until now ignored this code of conduct. There's been talk about how people feel unwelcome in _other_ projects, about how _other_ projects (fill in the blank). What there hasn't been any talk of, however, is any instance where this has been a problem in _our_ community. coreboot _is_ a hard thing. You _do_ need a _hard_skin_ to do coreboot. That's just the nature of our work. That is not because of our attitude; hardware is crap. People get annoyed at it. They bash it and vent out. It's normal. There's absolutely no point in burdening our developers with a generic code of of conduct. I don't know how much time Marc actually spends on IRC, but we have been great at policing ourselves. Pretending someone else's problem as our own is just silly. The fact is, the problem Marc pointed out, and the problems he tries to solve with this code of conduct are non-present in our community. I've seen more helpful people jumping to aid than in any other project. I've seen more good will and personal time invested to help others than in any other project. I've only seen Peter give new guys the RTFW, RTFS, or STFW, and those have been well deserved by the person receiving them. Are we going to start taking action against some of our most experienced and valuable developers because they didn't waste their personal time doing someone else's homework? There's a phenomenon of "Oh, I saw this thing here, so let's implement it irrespective of whether or not it's actually relevant". I call that liberal bullshit. That's exactly what this is. This code of conduct is an insult to our hard work over the years, and an insult to our friendly nature and countless personal hours spent helping others. When you've put up this code of conduct, you've basically said "our community is not capable of bettering itself by peer action and common sense, so we need to enforce it". It degrades every person who has ever contributed, and degrades the community as a whole. It's a degrading document that has no place. Alex From guru at unixarea.de Sun Feb 8 20:03:38 2015 From: guru at unixarea.de (Matthias Apitz) Date: Sun, 8 Feb 2015 20:03:38 +0100 Subject: [coreboot] updating coreboot && SeaBIOS on an Acer C720 Message-ID: <20150208190338.GA1261@c720-r276659> Hello, I'm new to this list and do not even know if it is the right place to ask my question. So please be patient and/or forgive me. I'm running FreeBSD 11-HEAD on an Acer C720 Chromebook, booting directly into SeaBIOS. I'm facing seldom (let's say once a week with 12h++ uptime per day) problems of complete power-off of the device. I.e. the problem is not related to ChromeOS (because it is not running anymore in my C720) and perhaps unrelated to FreeBSD (because I see with Google Linux users with the same problem). Before returning the C720 to Acer, which perhaps say "we can not reproduce" your problem, I wanted to check if the problem is related to changes or bugs in coreboot or in SeaBIOS. I git'ed out both, but can't see any lists or release notes of fixed issues. My C720 says about version of BIOS: SeaBIOS ver. 20131001_113210-build123-m2, and about coreboot: BIOS Information Vendor: coreboot Version: Release Date: 08/13/2014 ROM Size: 8192 kB Characteristics: PCI is supported PC Card (PCMCIA) is supported BIOS is upgradeable Selectable boot is supported ACPI is supported Targeted content distribution is supported BIOS Revision: 4.0 Firmware Revision: 0.0 Thanks in advance for any pointers to related information, esp. to lists of fixed issues or release notes. matthias -- Matthias Apitz, guru at unixarea.de, http://www.unixarea.de/ +49-170-4527211 La referencia de la Duma a la anexi?n de la RDA, en este caso al contrario con la Criml?a sin refer?ndum, no solamente tiene gracia sino da en el blanco.- Marinos Yannikos @MarinosYannikos en un blog de RTdeutsch. From mr.nuke.me at gmail.com Sun Feb 8 21:40:45 2015 From: mr.nuke.me at gmail.com (Alex G.) Date: Sun, 08 Feb 2015 14:40:45 -0600 Subject: [coreboot] updating coreboot && SeaBIOS on an Acer C720 In-Reply-To: <20150208190338.GA1261@c720-r276659> References: <20150208190338.GA1261@c720-r276659> Message-ID: <54D7C9CD.50100@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/08/2015 01:03 PM, Matthias Apitz wrote: > > Hello, > > I'm new to this list and do not even know if it is the right place > to ask my question. So please be patient and/or forgive me. > > I'm running FreeBSD 11-HEAD on an Acer C720 Chromebook, booting > directly into SeaBIOS. I'm facing seldom (let's say once a week > with 12h++ uptime per day) problems of complete power-off of the > device. I.e. the problem is not related to ChromeOS (because it is > not running anymore in my C720) and perhaps unrelated to FreeBSD > (because I see with Google Linux users with the same problem). > Suspect number one is the device overheating. The shutdown is triggered by the EC. I don't know how you can enable ACPI debug output on BSD though. On linux, it would be "echo 1 > /sys/module/acpi/parameters/aml_debug_output", so whatever the FreeBSD equivalent of that is. If you can see lines like "EC: LID OPEN" in wherever the system log is, then you know that's working. Look for things like "EC: THERMAL OVERLOAD" or "EC: THERMAL SHUTDOWN" in said system log, right after a shutdown. Alex -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJU18nGAAoJELCXTU3o76/OHAMQAL11y4KxAVjgxsy4IoCtXCnB HDVbLltPRol9LuQ29DqWGkfXWO6aPXyyWRfsoxALDG+a5cD9fp485/nW+RcPHbmK m6A+X8cF+qVR0HqHr5iS/AA8EtsSNouGUl14Q/k1LdclW3tGSrvKL4TmtVgoiasF HiEGTtgjipId0ZfKpAU+XqgAAUSdZ45nbooMHEJ++e2R0xPrz8Y/UBkxutoAVo11 Oo8e6o/MEDsFjYA6QhSGnkurX8zqj/e6+RKe5E6afJHvCEa7dcgyOxNZJ7QrFaXr ls75ANhn0+tCyNjVEmEhoey6PwP7sL5PbdTHz0GkG11Ye7u+Dtu2kkpS7EfTB+o8 HWsIQBg43P8MbzPfBKeNshfgtsyHbIuxvATZ0+TBqrpAvuabtKTCO2UDxlGQAHbS ueZM1oPTNhsB0gt0p8eAUsmg05uWtHUAdl0Z01l1Q3Y08wVMbnymKKImPaEzJUhu vCOo4Wb7d4b9ZcvNseP88WFTZpwWWVKhoyiDlnRRQiABCwELDEgfOFMLHoJlrVNp Cc/KyVkChQ/H3oxtFseS+COyYFffLN2p+es95TuhRcSfTjpdwGwHbsrtkEnTsPaZ H5LqukqvnJKpOpBEsUaRefTPPV1a6SkNeEsxU2/JHTnkiizbaSKeo+2OXJ9XlmuF OHq/G//DYaFV322VWU7q =Elxi -----END PGP SIGNATURE----- From guru at unixarea.de Sun Feb 8 21:55:49 2015 From: guru at unixarea.de (Matthias Apitz) Date: Sun, 8 Feb 2015 21:55:49 +0100 Subject: [coreboot] updating coreboot && SeaBIOS on an Acer C720 In-Reply-To: <54D7C9CD.50100@gmail.com> References: <20150208190338.GA1261@c720-r276659> <54D7C9CD.50100@gmail.com> Message-ID: <20150208205549.GA1771@c720-r276659> El d?a Sunday, February 08, 2015 a las 02:40:45PM -0600, Alex G. escribi?: > Suspect number one is the device overheating. The shutdown is > triggered by the EC. I don't know how you can enable ACPI debug output > on BSD though. On linux, it would be "echo 1 > > /sys/module/acpi/parameters/aml_debug_output", so whatever the FreeBSD > equivalent of that is. Thanks for your feedback. But this is not a thermal issue. I'm monitoring the core temps and they are always between 45-50 centi degrees. And, I'm more an ASCII user, i.e. writing and reading mails, and not using the C720 to view streams of pictures. matthias -- Matthias Apitz, guru at unixarea.de, http://www.unixarea.de/ +49-170-4527211 La referencia de la Duma a la anexi?n de la RDA, en este caso al contrario con la Criml?a sin refer?ndum, no solamente tiene gracia sino da en el blanco.- Marinos Yannikos @MarinosYannikos en un blog de RTdeutsch. From vidwer at gmail.com Sun Feb 8 23:14:10 2015 From: vidwer at gmail.com (Idwer Vollering) Date: Sun, 8 Feb 2015 23:14:10 +0100 Subject: [coreboot] updating coreboot && SeaBIOS on an Acer C720 In-Reply-To: <20150208205549.GA1771@c720-r276659> References: <20150208190338.GA1261@c720-r276659> <54D7C9CD.50100@gmail.com> <20150208205549.GA1771@c720-r276659> Message-ID: ? 2015-02-08 21:55 GMT+01:00 Matthias Apitz : > El d?a Sunday, February 08, 2015 a las 02:40:45PM -0600, Alex G. escribi?: > >> Suspect number one is the device overheating. The shutdown is >> triggered by the EC. I don't know how you can enable ACPI debug output >> on BSD though. On linux, it would be "echo 1 > >> /sys/module/acpi/parameters/aml_debug_output", so whatever the FreeBSD >> equivalent of that is. hw.acpi.verbose=1 would be a start. > > Thanks for your feedback. But this is not a thermal issue. I'm monitoring > the core temps and they are always between 45-50 centi degrees. And, I'm > more an ASCII user, i.e. writing and reading mails, and not using the > C720 to view streams of pictures. What's the value of debug.acpi.acpi_ca_version? I'd boot with verbose set to 'on', so that the default values from these tunables have changed: debug.boothowto=2048 / debug.bootverbose=1 Also you probaby need to increase kern.msgbufsize to be able to view every line. > > matthias > -- > Matthias Apitz, guru at unixarea.de, http://www.unixarea.de/ +49-170-4527211 > La referencia de la Duma a la anexi?n de la RDA, en este caso al contrario con la Criml?a sin > refer?ndum, no solamente tiene gracia sino da en el blanco.- > Marinos Yannikos @MarinosYannikos en un blog de RTdeutsch. > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot From zoran.stojsavljevic at intel.com Mon Feb 9 08:05:04 2015 From: zoran.stojsavljevic at intel.com (Stojsavljevic, Zoran) Date: Mon, 9 Feb 2015 07:05:04 +0000 Subject: [coreboot] Bay trail and SATA legacy IDE mode In-Reply-To: <677ED26A-3682-4DF4-9990-CB9A6E326E07@winzenttech.com> References: <677ED26A-3682-4DF4-9990-CB9A6E326E07@winzenttech.com> Message-ID: <67BFA875989E5748A862DFF55409F2A22EE04FBC@IRSMSX104.ger.corp.intel.com> Hello Patrick, Marc, Long-time no see, no talk... I need your help here. Here we have an interesting situation, since my best knowledge of FSP + Coreboot + SeaBIOS is limited... I am on the other side of the Galaxy now, for quite a (long) time. :) But still... I have some limited knowledge of Coreboot from 15 months ago, and I am trying to understand if Coreboot x86 code has some influence on the SATA IDE mode. From what I am reading... There is a possibility! The silicon is BYT SoC, ATOM. The boot time to OS bootloader is around 300 ms. My best understanding how this enumeration works for SATA is that all SATA are put in default AHCI mode. But some people (As Berth) must have SATA interfaces in IDE mode. What I know from what I see, what I understand... The Coreboot shown in stages is the following: - bootblock - romstage - ramstage - payload So let us magnify the one, important for this case: ramstage! In this stage the following is happening (among others) - Tables initialized: ACPI,..., IRQ Routing, etc. PCIe discovery is done... And, FSP 3rd call NotifyPhaseEntry () API is called twice. Let me magnify all of these... As my best understanding is! Let us concentrate to the next: DEVICETREE.CB code! I see that some devices are in the format: device pci 2.0 on end - 0.2.0 IDE interface... BIOS like! I also see that some devices are defined in Coreboot directory: northbridge/intel/... Since I am not sure where SATA IDE code is, for BYT... Could you, please, navigate me? Not sure where these definition are?! I need pointer to source code for BYT SATA IDE, if possible (pointer to Coreboot source code directories)? If this is NOT hidden in NotifyPhaseEntry ()... You will tell me, hopefully. Thank you, Zoran Stojsavljevic -----Original Message----- From: Berth-Olof Bergman [mailto:bo.bergman at winzenttech.com] Sent: Friday, February 06, 2015 10:07 AM To: coreboot at coreboot.org Subject: Bay trail and SATA legacy IDE mode Hi all, Has anyone run a Bay Trail SOC in SATA legacy IDE mode? It doesn?t work on my boards, even though I have identical settings of the PCI configuration space as AMI and Phoenix BIOS. The port works, but the IRQs are wrong polarity. Thus when issuing a command, I don?t get an interrupt. If I read the IDE status register (alternate or main) I get an interrupt. As reading the IDE status register, negates interrupt, I get the high level edge as the polarity is inverted. Can you verify if IDE legacy mode works for Bay Trail with correct? Best regards, B-O Bergman Winzent Technologies Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 From guru at unixarea.de Mon Feb 9 08:32:40 2015 From: guru at unixarea.de (Matthias Apitz) Date: Mon, 9 Feb 2015 08:32:40 +0100 Subject: [coreboot] updating coreboot && SeaBIOS on an Acer C720 In-Reply-To: References: <20150208190338.GA1261@c720-r276659> <54D7C9CD.50100@gmail.com> <20150208205549.GA1771@c720-r276659> Message-ID: <20150209073240.GA1469@c720-r276659> El d?a Sunday, February 08, 2015 a las 11:14:10PM +0100, Idwer Vollering escribi?: > ? > > 2015-02-08 21:55 GMT+01:00 Matthias Apitz : > > El d?a Sunday, February 08, 2015 a las 02:40:45PM -0600, Alex G. escribi?: > > > >> Suspect number one is the device overheating. The shutdown is > >> triggered by the EC. I don't know how you can enable ACPI debug output > >> on BSD though. On linux, it would be "echo 1 > > >> /sys/module/acpi/parameters/aml_debug_output", so whatever the FreeBSD > >> equivalent of that is. > > hw.acpi.verbose=1 would be a start. > ... Thanks for all the hints. As I said, the events are sporadic, seldom, but complete power-off (like as you would cut the cable from the motherboard). Of course the system has no chance to write anything to /var/log/messages or console. My hope while writing to coreboot@ was to get a pointer to the list of open ore solved issues within coreboot and/or SeaBIOS to see if this issue is somewhat known, solved or could be related to some known or solved issue. Where can I find such a list which is normally (as we do in my company) attached to the Release Notes of a new version of software. Thanks in advance Matthias http://www.coreboot.org/pipermail/coreboot/2015-February/079219.html -- Matthias Apitz, guru at unixarea.de, http://www.unixarea.de/ +49-170-4527211 La referencia de la Duma a la anexi?n de la RDA, en este caso al contrario con la Criml?a sin refer?ndum, no solamente tiene gracia sino da en el blanco.- Marinos Yannikos @MarinosYannikos en un blog de RTdeutsch. From mr.nuke.me at gmail.com Mon Feb 9 08:37:03 2015 From: mr.nuke.me at gmail.com (Alexandru Gagniuc) Date: Mon, 09 Feb 2015 01:37:03 -0600 Subject: [coreboot] Bay trail and SATA legacy IDE mode In-Reply-To: <67BFA875989E5748A862DFF55409F2A22EE04FBC@IRSMSX104.ger.corp.intel.com> References: <677ED26A-3682-4DF4-9990-CB9A6E326E07@winzenttech.com> <67BFA875989E5748A862DFF55409F2A22EE04FBC@IRSMSX104.ger.corp.intel.com> Message-ID: <2989106.GcMannOiWK@nukelap.gtech> On Monday, February 09, 2015 07:05:04 AM Stojsavljevic, Zoran wrote: > But still... I have some limited knowledge of Coreboot from 15 months ago, > and I am trying to understand if Coreboot x86 code has some influence on > the SATA IDE mode. From what I am reading... There is a possibility! Check src/soc/intel/baytrail/sata.c on how the registers are configured based on devicetree.cb if (!config->sata_ahci) { /* Set legacy or native decoding mode */ if (config->ide_legacy_combined) { > The silicon is BYT SoC, ATOM. The boot time to OS bootloader is around 300 > ms. > My best understanding how this enumeration works for SATA is that all SATA > are put in default AHCI mode. But some people (As Berth) must have SATA > interfaces in IDE mode. register "sata_ahci" = "0" register "ide_legacy_combined" = "1" Alex From adurbin at chromium.org Mon Feb 9 16:20:00 2015 From: adurbin at chromium.org (Aaron Durbin) Date: Mon, 9 Feb 2015 09:20:00 -0600 Subject: [coreboot] updating coreboot && SeaBIOS on an Acer C720 In-Reply-To: <20150209073240.GA1469@c720-r276659> References: <20150208190338.GA1261@c720-r276659> <54D7C9CD.50100@gmail.com> <20150208205549.GA1771@c720-r276659> <20150209073240.GA1469@c720-r276659> Message-ID: On Mon, Feb 9, 2015 at 1:32 AM, Matthias Apitz wrote: > El d?a Sunday, February 08, 2015 a las 11:14:10PM +0100, Idwer Vollering escribi?: > >> ? >> >> 2015-02-08 21:55 GMT+01:00 Matthias Apitz : >> > El d?a Sunday, February 08, 2015 a las 02:40:45PM -0600, Alex G. escribi?: >> > >> >> Suspect number one is the device overheating. The shutdown is >> >> triggered by the EC. I don't know how you can enable ACPI debug output >> >> on BSD though. On linux, it would be "echo 1 > >> >> /sys/module/acpi/parameters/aml_debug_output", so whatever the FreeBSD >> >> equivalent of that is. >> >> hw.acpi.verbose=1 would be a start. >> ... > > Thanks for all the hints. > > As I said, the events are sporadic, seldom, but complete power-off (like > as you would cut the cable from the motherboard). Of course the system has no > chance to write anything to /var/log/messages or console. > > My hope while writing to coreboot@ was to get a pointer to the list of > open ore solved issues within coreboot and/or SeaBIOS to see if this > issue is somewhat known, solved or could be related to some known or > solved issue. Where can I find such a list which is normally (as we do > in my company) attached to the Release Notes of a new version of > software. > On the surface this doesn't sound like anything coreboot or SeaBIOS specific. Can you grab the cbmem console logs on the boot after the power off (cbmem -c)? There is also an eventlog sitting in memory as well that can be grabbed. mosys (https://chromium.googlesource.com/chromiumos%2Fplatform%2Fmosys/+/refs%2Fheads%2Fmaster) should be able to do that work for you: mosys eventlog list The last thing to get is the EC console log. That's much harder to get as you have a kernel that doesn't have the EC driver in it. If you feel adventurous the tool (util/ectool) can be found here: https://chromium.googlesource.com/chromiumos%2Fplatform%2Fec/+/refs%2Fheads%2Fmaster Hope that helps. -Aaron From c-d.hailfinger.devel.2006 at gmx.net Tue Feb 10 00:06:59 2015 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Tue, 10 Feb 2015 00:06:59 +0100 Subject: [coreboot] code of conduct (reloaded) In-Reply-To: <2200030.9kBh2SSoN8@nukelap.gtech> References: <2200030.9kBh2SSoN8@nukelap.gtech> Message-ID: <54D93D93.4060705@gmx.net> On 08.02.2015 19:07, Alexandru Gagniuc wrote: > I have until now ignored this code of conduct. There's been talk about how > people feel unwelcome in _other_ projects, about how _other_ projects (fill in > the blank). What there hasn't been any talk of, however, is any instance where > this has been a problem in _our_ community. On January 16, 2015, Marc Jones wrote in a coreboot.org blog post: > While most developers don?t experience something as terrible as the > harassment that happened in the context of Gamergate or other terrible > behavior documented at technical and open source conferences the last > several years, it does indicate that there is a problem in our open > source communities. I think the sentence above pretty much describes what went wrong in the process creating the coreboot code of conduct. Using gamergate (Disclaimer: I'm not a gamer, I prefer real cardboard puzzles) as an indicator that there is a problem in our open source communities is a logical fallacy (majority of game market share is not open source). Using terrible behaviour documented at technical conferences as an indicator that there is a problem in our open source communities is a logical fallacy (majority of tech market share is not open source). However, using terrible behaviour documented at open source conferences as an indicator that there is a problem in our open source communities is logically correct. Now there are some open source communities which reportedly have more problems and some which reportedly have less or no problems. It would be very interesting to see how they differ, and then check how this can be applied to us. Right now prescribing a code of conduct is hip and trendy because everyone does it. It also seems to be necessary in many places. Marc wrote: "it's a part of growing up", but in the real-life community I was brought up (i.e. the city where I lived), a code of conduct was considered a sign that something had broken down before and needed patching up. See school rules for an example. Consider a relationship: If there is a code of conduct in a relationship, it's probably about who may see or interact with the joint children at any given time. On 08.02.2015 19:07, Alexandru Gagniuc wrote: > There's a phenomenon of "Oh, I saw this thing here, so let's implement it > irrespective of whether or not it's actually relevant". I call that liberal > bullshit. That's exactly what this is. I don't know about liberals in the USA, but in the EU, this would be a conservative position. Then again, the definitions of liberal and conservative seem to be completely different in the US vs EU. On 08.02.2015 19:07, Alexandru Gagniuc wrote: > This code of conduct is an insult to our hard work over the years, and an > insult to our friendly nature and countless personal hours spent helping > others. When you've put up this code of conduct, you've basically said "our > community is not capable of bettering itself by peer action and common sense, > so we need to enforce it". It degrades every person who has ever contributed, > and degrades the community as a whole. It's a degrading document that has no > place. On January 16, 2015, Marc Jones wrote in a coreboot.org blog post: > We can?t lose valuable contributors because they felt uncomfortable or > unwanted. Alexandru, since you are a valuable contributor and feel uncomfortable with the to-be-established Code of Conduct in its current form, those who created the Code of Conduct surely will want to make sure not to lose you. I trust them to come up with a solution for this. Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Tue Feb 10 01:16:26 2015 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Tue, 10 Feb 2015 01:16:26 +0100 Subject: [coreboot] GSoC 2015 Message-ID: <54D94DDA.2020200@gmx.net> Applications for organizations are open again. The deadline is very short this time: Only 10 days! http://www.google-melange.com/gsoc/homepage/google/gsoc2015 Regards, Carl-Daniel From coreboot at guylhem.net Tue Feb 10 01:52:57 2015 From: coreboot at guylhem.net (Charles Devereaux) Date: Mon, 9 Feb 2015 19:52:57 -0500 Subject: [coreboot] GSoC 2015 In-Reply-To: <54D94DDA.2020200@gmx.net> References: <54D94DDA.2020200@gmx.net> Message-ID: Hello My suggestions : - having freedos work on the X60 with free software only (this would include proper video bios support) - implementing a free software firmware for the EC - finding a way to flash a X220 without hardware modifications (to have another "public" platform besides the X60) This would help having more freedom, and could also apply to further models. On Mon, Feb 9, 2015 at 7:16 PM, Carl-Daniel Hailfinger < c-d.hailfinger.devel.2006 at gmx.net> wrote: > Applications for organizations are open again. The deadline is very > short this time: Only 10 days! > > http://www.google-melange.com/gsoc/homepage/google/gsoc2015 > > Regards, > Carl-Daniel > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.devillier at gmail.com Tue Feb 10 05:49:15 2015 From: matt.devillier at gmail.com (Matt DeVillier) Date: Mon, 09 Feb 2015 22:49:15 -0600 Subject: [coreboot] Haswell/panther - GPU memory allocation In-Reply-To: <54D93D93.4060705@gmx.net> References: <2200030.9kBh2SSoN8@nukelap.gtech> <54D93D93.4060705@gmx.net> Message-ID: <54D98DCB.3010507@gmail.com> Greetings! I'm looking to adjust the amount of system memory allocated to the GPU on panther (Haswell mobile), since certain applications (eg, Steam) report a suboptimal amount of GPU memory. lspci reports the following: 00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: Intel Corporation Haswell-ULT Integrated Graphics Controller Flags: bus master, fast devsel, latency 0, IRQ 43 Memory at e0000000 (64-bit, non-prefetchable) [size=4M] Memory at d0000000 (64-bit, prefetchable) [size=256M] I/O ports at 3000 [size=64] Expansion ROM at [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Capabilities: [a4] PCI Advanced Features Kernel driver in use: i915 Looking at src/northbridge/intel/haswell/early_init.c, the 256M appears to correlate to the MSAC register, and going by Intel's datasheet, setting the MSAC to 0x6 (from the current value of 0x2) should increase the allocation to 512MB, yet doing so appears to have no affect (at least as far as lspci is concerned). I also looked at the GMS portion of the GGC register, which is currently set to 32MB, but changing it, either in conjunction with or separately from MSAC, has no discernible effect either. Obviously there's something else I'm missing, so would appreciate any help. thanks, Matt From werner.zeh at gmx.net Tue Feb 10 07:29:33 2015 From: werner.zeh at gmx.net (Werner Zeh) Date: Tue, 10 Feb 2015 07:29:33 +0100 Subject: [coreboot] New interface for I2C in coreboot Message-ID: Hi coreboot community. Although I am working on coreboot for now more than one year mostly behind the scenes I am fairly new on the contributor side. Yesterday, I have started contribution and one of my first value that I would like to give back to the community is a driver for I2C controllers that starts to get integrated into x86-chips from intel (Baytrail has one as well as X1000 Quark). Please be aware that this is not a driver for the well-known SMBus controller. I have written the driver a few weeks ago and at this time there was a pretty simple and therefore really generic interface for I2C buses in coreboot. The interface is described in src/include/device/i2c.h and was consist of two simple functions: i2c_read() and i2c_write(). With this interface the user of the driver (which in most of the cases will be another driver for let?s say an EEPROM) can simply call for instance the i2c_read()-function and provide as arguments the i2c-bus, the chip-address of the slave (EEPROM here), the address inside the slave, a length and a buffer where to store the driver. With these parameters, the I2C driver is able to read the desired data in one call and store them into the buffer provided. Similar procedure is for the write function. You can see that one logical transfer can be directly mapped to one function call of the driver (i2c_read or i2c_write). In mid-December 2014, the interface was changed massive by this two commits: 7947 and 7751. I have had a look at the new interface and what should I say: It is not only completely different (what in general would be OK for me) but it is in my point of view a step back. Let?s see what is happened here. The functions i2c_read() and i2c_write() where replaced by i2c_readb(), i2c_writeb(), i2c_read_raw() and i2c_write_raw(). The first two functions can read a single byte from a slave on a given register address (EEPROM address in my example here). The second two are meant to read a chunk of data from the slave. Both of the functions actually are a wrapper to call the real i2c driver interface called i2c_transfer(). But wait a moment?with the last two functions there is no way to tell the driver _where_ to start reading inside the slave. Let us have a closer look to how this interface can be used to transfer a chunk of data from a given address inside the slave. To do this, let us consider we want to read 10 bytes starting at offset 20. 1. Store the offset we need (in this case 20) into a buffer 2. Call i2c_write_raw(bus, chip_adr, &buffer, 1); 3. Call i2c_read_raw(bus, chip_adr, &buffer,10); Here are my personal problems with this kind of interface: 1. Where we earlier had one simple call to i2c_read(), we now have to fill one variable with the length we need and call two different functions (i2c_write_raw and i2c_read_raw). 2. Though the read transfer is one logical access to the slave, we have split it into two (without any benefit I can see now) 3. We have added two wrapper layers where we earlier had none! Unfortunately, the first two mentioned functions of the interface cannot be used for transferring more than byte because the length field is missing. In contrast, the two functions that have a length field do not have a slave address field. This is frustrating! If one have a hardware implemented I2C-controller in mind, this interface is really not that intuitive and simple. This is because we have to perform a function switch in the middle of a logical bus action. And: why should one perform i2c_write operation in order to read the data? This is not logical to me. I know that I2C bus works this way, but it is the responsibility of the driver to hide this from the user. And with this interface, this ?hiding? is simply impossible because now the user have to do it! I do not see any benefits of this interface and I really cannot see the need for the introduced change in the interface. Of course it is technical possible to read and write data over I2C with this interface?but to be honest: I would not be proud of this solution! Of course we can add an address field to the i2c_read_raw and i2c_write_raw functions. But at the end we will end up with a complex interface for a very simple bus. And we will have several wrapper layers compared to the interface we had before. There is even no need of _one_ wrapper layer for this bus! I hope I was able to point out what my concern is about and want to discuss this with the community. I want to hear more opinions on this interface and at the end want to know whether it is worse to change my I2C driver to be used with this interface. The last point I will do if one can show me the _real_ benefit of the new interface. Thank you Werner From mr.nuke.me at gmail.com Tue Feb 10 08:56:50 2015 From: mr.nuke.me at gmail.com (Alexandru Gagniuc) Date: Tue, 10 Feb 2015 01:56:50 -0600 Subject: [coreboot] New interface for I2C in coreboot In-Reply-To: References: Message-ID: <3033179.djo87kQOdX@nukelap.gtech> On Tuesday, February 10, 2015 07:29:33 AM Werner Zeh wrote: > Hi coreboot community. > Hi back at you. > 1. Store the offset we need (in this case 20) into a buffer > 2. Call i2c_write_raw(bus, chip_adr, &buffer, 1); > 3. Call i2c_read_raw(bus, chip_adr, &buffer,10); > That's actually the way I2C is designed to work, and this sort of API models it more accurately. Linux uses it. libeopencm uses it. spidev uses it. > Here are my personal problems with this kind of interface: Then provide utility functions to do i2c_reg_(read|write) which wrap i2c_transfer() directly. Construct the complete I2c transaction as an array of i2c_seg and pass that to i2c_transfer(). > 1. Where we earlier had one simple call to i2c_read(), we now have to fill > one variable with the length we need and call two different functions > (i2c_write_raw and i2c_read_raw). 2. Though the read transfer is one > logical access to the slave, we have split it into two (without any benefit > I can see now) 3. We have added two wrapper layers where we earlier had > none! > Not quite so. The i2c read/write of the past actually squashed together several steps, which ended up being more code as you had to fully model every sort of transaction you could think of doing. There's no extra wrapping. The code was just reorganized. Alex From patrick at georgi-clan.de Tue Feb 10 09:18:47 2015 From: patrick at georgi-clan.de (Patrick Georgi) Date: Tue, 10 Feb 2015 09:18:47 +0100 Subject: [coreboot] New interface for I2C in coreboot In-Reply-To: <3033179.djo87kQOdX@nukelap.gtech> References: <3033179.djo87kQOdX@nukelap.gtech> Message-ID: <54D9BEE7.4090607@georgi-clan.de> Am 10.02.2015 um 08:56 schrieb Alexandru Gagniuc: > That's actually the way I2C is designed to work, and this sort of API models > it more accurately. Linux uses it. libeopencm uses it. spidev uses it. But hardware doesn't. The API is fine when you bitbang everything, but not when there's a controller that takes over some of the work, like programming the address. On such a controller, you have to pick apart struct i2c_seg* to figure out which elements are addresses and which are data, and split things into different registers. I really don't see how it's useful to keep the data structures as low level as possible and then require drivers for more capable devices to uplift them to a higher abstraction level. Patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From lynxis at fe80.eu Tue Feb 10 10:42:27 2015 From: lynxis at fe80.eu (Alexander Couzens) Date: Tue, 10 Feb 2015 10:42:27 +0100 Subject: [coreboot] GSoC 2015 In-Reply-To: <54D94DDA.2020200@gmx.net> References: <54D94DDA.2020200@gmx.net> Message-ID: <20150210104227.61f957bb@lazus.yip> On Tue, 10 Feb 2015 01:16:26 +0100 Carl-Daniel Hailfinger wrote: > Applications for organizations are open again. The deadline is very > short this time: Only 10 days! > > http://www.google-melange.com/gsoc/homepage/google/gsoc2015 Who is doing the application for coreboot? Is something missing? I would like to attend as student this year ;). Best, lynxis -- Alexander Couzens mail: lynxis at fe80.eu jabber: lynxis at jabber.ccc.de mobile: +4915123277221 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From c-d.hailfinger.devel.2006 at gmx.net Tue Feb 10 18:54:35 2015 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Tue, 10 Feb 2015 18:54:35 +0100 Subject: [coreboot] coreboot code of conduct In-Reply-To: References: Message-ID: <54DA45DB.4060600@gmx.net> On 16.01.2015 19:15, Marc Jones wrote: > A coreboot code of conduct has been posted on the wiki. > - http://www.coreboot.org/Code_of_Conduct > > I have written a blog post about why we have a code of conduct. > - http://blogs.coreboot.org/blog/2015/01/16/coreboot-code-of-conduct/ > > Feel free to give feedback on the policy and how else we can contribute to > a welcoming and collaborative environment. How do we handle a conflict between our own Code of Conduct and the Code of Conduct of a conference where coreboot is participating? Will we ignore our own CoC or will we simply not attend? Does it depend on whether the CoC is similar in spirit or not? Some conferences declare their own CoC as binding for everyone and disallow participating projects from enforcing any project CoC. Other conferences allow every participating project to declare the project CoC as binding. Having a Code of Conduct is no silver bullet against people criticizing you on the internet: The FOSDEM conference has a CoC on every printed conference programme, tells attendees to report concerns to any staff member, and the contact phone number is of one of the female staff members. FOSDEM staff+volunteers will do everything possible to make you feel welcome at their conference. The number of reports of harassment for FOSDEM apparently is zero, both for reports to the staff and reports on the internet. That didn't help them, though. A quick google search will find a few people calling for a boycott of FOSDEM because they think the FOSDEM CoC is "no proper code of conduct", others complaining that "zero reports is not the same as zero occurrences" and claiming that if harassment happens at other conferences it also must have happened at FOSDEM. Some people even complained that FOSDEM allowed individual communities to declare their own community CoC as binding for the community developer rooms. The Code of Conduct yes/no problem is a no-win situation with ideological background. Regardless of what we do, someone will be unhappy. It is fundamentally similar to the blob yes/no problem in coreboot vs. libreboot. I sincerely hope this will not cause a community split into a coreboot-be-nice and a coreboot-CoC camp. Side note: Most advocates for a CoC on the internet seem to live in the US and/or have visited conferences in the US. The harassment reports I found online about tech conferences seem to have a statistical anomaly: a disproportionately higher amount of complaints about US conferences. Some female colleagues of mine prefer to visit conferences in the EU for that reason. I would love to see a solid statistical study about this, though. So far it's only a first impression for me. Regards, Carl-Daniel From patrick at georgi-clan.de Tue Feb 10 19:22:31 2015 From: patrick at georgi-clan.de (Patrick Georgi) Date: Tue, 10 Feb 2015 19:22:31 +0100 Subject: [coreboot] Release Engineering (again) Message-ID: Hi, we had our last big discussion about building coreboot releases in November. It quickly moved to the topic of removing boards that don't comply to any kind of metric, and the discussion mostly went down with that. So, since I really like to get a release process up and running, let me a 'minimum viable' proposal here: Let's decide on a schedule and create releases, with only minimal testing for now. There's no support and no guarantees which things work (before you scream, see below). The main goal is to learn how to do releases, and go from there. From my point of view, a release entails the following: - a timeline (for now, an announcement akin to 'next release will be on february 32th') - a git tag - a tarball that contains that tree state - release notes and changelog (a bit more than just git log) For the first few releases, until we broaden the scope, those release notes need to be very clear about the nature of these releases (and that they are merely code dumps, not tested pieces of engineering). From there, we could set ourselves goals, for example 'by the release date the board(s) I maintain work with a commit that is at most a week old, and I'll provide board-status reports with the released version'. This provides us with a record of what happened between two points in time. It provides goalposts to attach goals to. And we're building experience with what kind of 'things work' guarantees are actually realistic for us and which aren't. From there we can discuss further ways to make use of those goalposts (including dropping boards or chipsets, at some point). Or drop the release concept if all that turns out not to be worthwhile - but with the knowledge why it isn't. Thoughts? Patrick From jwerner at chromium.org Tue Feb 10 20:36:55 2015 From: jwerner at chromium.org (Julius Werner) Date: Tue, 10 Feb 2015 11:36:55 -0800 Subject: [coreboot] New interface for I2C in coreboot In-Reply-To: References: Message-ID: I think the idea behind this change was mostly that the old API was too inflexible and some I2C device drivers could not be properly written with it. Take a look at line 139 in this file from the first patch: http://review.coreboot.org/#/c/7751/3/src/drivers/i2c/tpm/tpm.c at 139 . What this really does is trying to do all of the normal parts of an I2C read transaction manually, because TPMs can add so long delays at any point that the normal I2C controller drivers would already hit their timeout. With the old API this was only possible with a crude hack of setting the address length to 0 (so i2c_read() would skip the register address write completely). Doing a "raw read" with the new API does the same thing much clearer, and it's far more obvious to controller driver authors that they need to implement this (otherwise, it's easy to just assume alen == 0 is illegal until someone tries to use the TPM driver with it, which I think is what hit us on Tegra). The new API also makes the rules about when to use a repeated start vs a complete stop and start much clearer (which should not make a difference for the device, but in practice sometimes does). I think Werner's original issue is easy to solve: you can either just construct struct i2c_seg structures and call i2c_transfer() directly, or implement a new i2c_write() wrapper similar to i2c_writeb() (just with a variable data length). Maybe even just make i2c_writeb() a one-line wrapper macro on top of the new function... all fine by me, I think the only reason we didn't make more convenience functions is because we didn't need them at the time. The implementation problems Patrick mentioned are unfortunately true for some controllers which attempt to be more clever than they should... however, the thing is that we need to somehow implement raw I2C reads anyway (to support the alen == 0 case in the old API and make things like that TPM driver work). In the end we probably need to implement less primitives for the new API ("raw write" and "raw read") than for the old one ("full write", "full read", "raw write" and "raw read"). If that means we end up not using the do-everything-in-one-transaction "feature" of some controllers in favor of more controllable low-level accesses, I don't see a problem with that. From stefan.tauner at alumni.tuwien.ac.at Tue Feb 10 23:15:11 2015 From: stefan.tauner at alumni.tuwien.ac.at (Stefan Tauner) Date: Tue, 10 Feb 2015 23:15:11 +0100 Subject: [coreboot] Release Engineering (again) In-Reply-To: References: Message-ID: <201502102215.t1AMFB82012704@mail2.student.tuwien.ac.at> On Tue, 10 Feb 2015 19:22:31 +0100 Patrick Georgi wrote: > Hi, > > we had our last big discussion about building coreboot releases in > November. It quickly moved to the topic of removing boards that don't > comply to any kind of metric, and the discussion mostly went down with > that. > > So, since I really like to get a release process up and running TBH I have not followed that discussion very closely, so maybe that's clear for everybody but me... but WHY do we need releases at all? From my perspective it does not make too much sense, the board status thingy is good enough... coordinating people to obey arbitrary deadlines creates some friction that requires some rationale IMHO. I for one would rather read some changelog-like newsletters/blog posts and rely on board status than have some real changelogs + coreboot "versions". So, what advantages do you hope for? -- Kind regards/Mit freundlichen Gr??en, Stefan Tauner From stefan.tauner at alumni.tuwien.ac.at Tue Feb 10 23:20:09 2015 From: stefan.tauner at alumni.tuwien.ac.at (Stefan Tauner) Date: Tue, 10 Feb 2015 23:20:09 +0100 Subject: [coreboot] GSoC 2015 In-Reply-To: <20150210104227.61f957bb@lazus.yip> References: <54D94DDA.2020200@gmx.net> <20150210104227.61f957bb@lazus.yip> Message-ID: <201502102220.t1AMKAW9019972@mail2.student.tuwien.ac.at> On Tue, 10 Feb 2015 10:42:27 +0100 Alexander Couzens wrote: > On Tue, 10 Feb 2015 01:16:26 +0100 > Carl-Daniel Hailfinger wrote: > > > Applications for organizations are open again. The deadline is very > > short this time: Only 10 days! > > > > http://www.google-melange.com/gsoc/homepage/google/gsoc2015 > > Who is doing the application for coreboot? Is something missing? > I would like to attend as student this year ;). So far Marc was managing GSoC (with a lot of help from Patrick). He said that coreboot will be applying again this year, so I think everything is fine at this stage. Do you have a project idea already? -- Kind regards/Mit freundlichen Gr??en, Stefan Tauner From peter at stuge.se Wed Feb 11 01:55:39 2015 From: peter at stuge.se (Peter Stuge) Date: Wed, 11 Feb 2015 01:55:39 +0100 Subject: [coreboot] Release Engineering (again) In-Reply-To: <201502102215.t1AMFB82012704@mail2.student.tuwien.ac.at> References: <201502102215.t1AMFB82012704@mail2.student.tuwien.ac.at> Message-ID: <20150211005539.15517.qmail@stuge.se> Stefan Tauner wrote: > WHY do we need releases at all? Consumers are completely overwhelmed by dealing with repositories. > From my perspective it does not make too much sense, IMO it doesn't really, it's just psychological. Consumers use releases to judge ongoing development and assume that releases are significantly better than a given master. They also use it as a reference. I think it's learned from commercial software lifecycles. > So, what advantages do you hope for? Advantages come in the future when we know what promises we keep for a given release. That allows consumers to set their expectations and plan ahead to some degree, which matters a lot within the industry. //Peter From mylesgw at gmail.com Wed Feb 11 05:17:24 2015 From: mylesgw at gmail.com (Myles Watson) Date: Tue, 10 Feb 2015 20:17:24 -0800 Subject: [coreboot] updating coreboot && SeaBIOS on an Acer C720 In-Reply-To: References: <20150208190338.GA1261@c720-r276659> <54D7C9CD.50100@gmail.com> <20150208205549.GA1771@c720-r276659> <20150209073240.GA1469@c720-r276659> Message-ID: My C720 shuts down as well. Someone in this thread suggested that it was related to whether or not the adapter is connected: https://productforums.google.com/forum/#!topic/chromebook-central/gjSnZJeMEls%5B1-25-false%5D I've yet to have it shut down when the adapter is connected, whether or not the adapter is plugged into the wall. Although that's not an optimal solution, it has removed a lot of the frustration to have a workaround. Thanks, Myles On Mon, Feb 9, 2015 at 7:20 AM, Aaron Durbin wrote: > On Mon, Feb 9, 2015 at 1:32 AM, Matthias Apitz wrote: > > El d?a Sunday, February 08, 2015 a las 11:14:10PM +0100, Idwer Vollering > escribi?: > > > >> ? > >> > >> 2015-02-08 21:55 GMT+01:00 Matthias Apitz : > >> > El d?a Sunday, February 08, 2015 a las 02:40:45PM -0600, Alex G. > escribi?: > >> > > >> >> Suspect number one is the device overheating. The shutdown is > >> >> triggered by the EC. I don't know how you can enable ACPI debug > output > >> >> on BSD though. On linux, it would be "echo 1 > > >> >> /sys/module/acpi/parameters/aml_debug_output", so whatever the > FreeBSD > >> >> equivalent of that is. > >> > >> hw.acpi.verbose=1 would be a start. > >> ... > > > > Thanks for all the hints. > > > > As I said, the events are sporadic, seldom, but complete power-off (like > > as you would cut the cable from the motherboard). Of course the system > has no > > chance to write anything to /var/log/messages or console. > > > > My hope while writing to coreboot@ was to get a pointer to the list of > > open ore solved issues within coreboot and/or SeaBIOS to see if this > > issue is somewhat known, solved or could be related to some known or > > solved issue. Where can I find such a list which is normally (as we do > > in my company) attached to the Release Notes of a new version of > > software. > > > > On the surface this doesn't sound like anything coreboot or SeaBIOS > specific. Can you grab the cbmem console logs on the boot after the > power off (cbmem -c)? There is also an eventlog sitting in memory as > well that can be grabbed. mosys > ( > https://chromium.googlesource.com/chromiumos%2Fplatform%2Fmosys/+/refs%2Fheads%2Fmaster > ) > should be able to do that work for you: mosys eventlog list > > The last thing to get is the EC console log. That's much harder to get > as you have a kernel that doesn't have the EC driver in it. If you > feel adventurous the tool (util/ectool) can be found here: > > https://chromium.googlesource.com/chromiumos%2Fplatform%2Fec/+/refs%2Fheads%2Fmaster > > Hope that helps. > > -Aaron > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at gluglug.org.uk Wed Feb 11 05:45:44 2015 From: info at gluglug.org.uk (The Gluglug) Date: Wed, 11 Feb 2015 04:45:44 +0000 Subject: [coreboot] BB-xM spi Message-ID: <54DADE78.10701@gluglug.org.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Has anyone here used the BB-xM for SPI flashing before? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJU2t53AAoJEP9Ft0z50c+Ul2kIAJ40A8ovTgtxCOmg1wpprOOy Xp8RbAiaGeBzfGz9vVGIhbqNmz3TGDWbldNSn1VFe9ZJA51cyWNDl9oKxar4kr8o voE0h1p41KSgSHzZNM48MQEy1CN24HOTThlAioUiGqQP+z5clByhabZNlKppBqRl 5Mj/BJx7++dr4rZWWCHf5aIcgvLSL/8lG7rYAxtnoQ5sVv0IqjSqRfeT+5Nemj9N ag01DxU8Et6xCmzqbvReMjC8AiQDXd+CgbXeTRVBlfL9gP537z+dGZJQoRa0Zlh/ 3No54ya9+yTmy2eYzq1kDmfiqL87YIgHjMiD42u6r6jPsVzwR9Puk8GfkRHBBnM= =QJtr -----END PGP SIGNATURE----- From mr.nuke.me at gmail.com Wed Feb 11 07:54:17 2015 From: mr.nuke.me at gmail.com (Alex G.) Date: Wed, 11 Feb 2015 00:54:17 -0600 Subject: [coreboot] Fwd: Re: New interface for I2C in coreboot In-Reply-To: References: Message-ID: <54DAFC99.4050000@gmail.com> I knew there was something wrong to typing that from an Android phone. It didn't get sent to the list. -------- Forwarded Message -------- On Feb 10, 2015 2:19 AM, "Patrick Georgi" <> wrote: > Am 10.02.2015 um 08:56 schrieb Alexandru Gagniuc: > > That's actually the way I2C is designed to work, and this sort of API models > > it more accurately. Linux uses it. libeopencm uses it. spidev uses it. > But hardware doesn't. The API is fine when you bitbang everything, but > not when there's a controller that takes over some of the work, like > programming the address. > > On such a controller, you have to pick apart struct i2c_seg* to figure > out which elements are addresses and which are data, and split things > into different registers. > Is that proper i2c or smbus controllers? Smbus is a different beast that we really shouldn't simplify to i2c++ . Assuming it's i2c proper, how do we handle such cases? I2c is i2c and it makes more sense to abstract the nature of the hardware in an i2c centric way. A silicon-specific API is the wrong way here. I have patches in my pipeline to introduce generic i2c over displayport aux channel code. That makes use of the low level nature of i2c_seg to properly break down the AUX bus transactions in a hardware-agnostic way. > I really don't see how it's useful to keep the data structures as low > level as possible and then require drivers for more capable devices to > uplift them to a higher abstraction level. > See section about abstracting hardware details above. There's no measurable penalty for internal abstraction. There is however a penalty for driving the hardware in a suboptimal way. That's the driver's job. Sure, we can make a context based i2c API based on ops. Then we can check the direct_read pointer and use that if it's not null. Though most people will get it wrong when writing drivers. KISS. Alex From adurbin at chromium.org Wed Feb 11 16:17:31 2015 From: adurbin at chromium.org (Aaron Durbin) Date: Wed, 11 Feb 2015 09:17:31 -0600 Subject: [coreboot] Haswell/panther - GPU memory allocation In-Reply-To: <54D98DCB.3010507@gmail.com> References: <2200030.9kBh2SSoN8@nukelap.gtech> <54D93D93.4060705@gmx.net> <54D98DCB.3010507@gmail.com> Message-ID: On Mon, Feb 9, 2015 at 10:49 PM, Matt DeVillier wrote: > Greetings! > > I'm looking to adjust the amount of system memory allocated to the GPU on panther (Haswell mobile), since certain applications (eg, Steam) report a suboptimal amount of GPU memory. lspci reports the following: > > 00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller]) > Subsystem: Intel Corporation Haswell-ULT Integrated Graphics Controller > Flags: bus master, fast devsel, latency 0, IRQ 43 > Memory at e0000000 (64-bit, non-prefetchable) [size=4M] > Memory at d0000000 (64-bit, prefetchable) [size=256M] > I/O ports at 3000 [size=64] > Expansion ROM at [disabled] > Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- > Capabilities: [d0] Power Management version 2 > Capabilities: [a4] PCI Advanced Features > Kernel driver in use: i915 > > Looking at src/northbridge/intel/haswell/early_init.c, the 256M appears to correlate to the MSAC register, and going by Intel's datasheet, setting the MSAC to 0x6 (from the current value of 0x2) should increase the allocation to 512MB, yet doing so appears to have no affect (at least as far as lspci is concerned). > > I also looked at the GMS portion of the GGC register, which is currently set to 32MB, but changing it, either in conjunction with or separately from MSAC, has no discernible effect either. > > Obviously there's something else I'm missing, so would appreciate any help. The MSAC is the aperture window while the GGC is the stolen memory for the graphics. The aperture just gives a contiguous window into memory mapped by GPU (which could be the stolen memory). The stolen memory for graphics really just makes displaying things in firmware easier since there's a set aside piece of memory to use as a framebuffer. I'm not familiar with Steam's complaints about suboptimal GPU memory (or any other apps). Can you quote the complaint so further research can be done into what it's actually looking at. All that said, I looked into the reference code you're running. It sets a fixed 256MiB aperture. You should be able to change MSAC after the memory training is done in romstage. You can confirm this by keeping your 0x6 value in early_init.c and reading that register back after memory init has been done. Additionally, the 32MiB of stolen memory is also fixed in the MRC, but you can't just change that after the fact because that affects the physical address space directly. Hope that helps. -Aaron From lynxis at fe80.eu Wed Feb 11 16:53:00 2015 From: lynxis at fe80.eu (Alexander Couzens) Date: Wed, 11 Feb 2015 16:53:00 +0100 Subject: [coreboot] x201t + windows7 Message-ID: <20150211165300.08dfd130@lazus.yip> Hi, I tried today a windows 7 installation usb stick and a cd disc. Both 32bit and 64bit. Both Windows' stopping at disk.sys and the hdd led on. 32bit: sometimes windows boots, most time not. Any ideas, what's wrong? Best, lynxis -- Alexander Couzens mail: lynxis at fe80.eu jabber: lynxis at jabber.ccc.de mobile: +4915123277221 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From zaolin at das-labor.org Wed Feb 11 16:58:35 2015 From: zaolin at das-labor.org (Zaolin) Date: Wed, 11 Feb 2015 16:58:35 +0100 Subject: [coreboot] x201t + windows7 In-Reply-To: <20150211165300.08dfd130@das-labor.org> References: <20150211165300.08dfd130@das-labor.org> Message-ID: <54DB7C2B.7000507@das-labor.org> Hi, have seen the same problem on all thinkpad product types supported by coreboot. Maybe someone should get a Windows Developer Edition and solve this bug ;) . Regards Zaolin > Hi, > > I tried today a windows 7 installation usb stick and a cd disc. > Both 32bit and 64bit. > > Both Windows' stopping at disk.sys and the hdd led on. > 32bit: sometimes windows boots, most time not. > > Any ideas, what's wrong? > > Best, > lynxis > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 859 bytes Desc: OpenPGP digital signature URL: From patrick at georgi-clan.de Wed Feb 11 17:09:13 2015 From: patrick at georgi-clan.de (Patrick Georgi) Date: Wed, 11 Feb 2015 17:09:13 +0100 Subject: [coreboot] x201t + windows7 In-Reply-To: <54DB7C2B.7000507@das-labor.org> References: <20150211165300.08dfd130@das-labor.org> <54DB7C2B.7000507@das-labor.org> Message-ID: Am 2015-02-11 16:58, schrieb Zaolin: > Maybe someone should get a Windows Developer Edition > and solve this bug ;) . Those are called "checked builds" and are freely available to students through Microsoft's DreamSpark program. In addition to that you'll need another system running WinDbg (on Windows), and an EHCI USB debug or serial connection (no pci* serial card with mmio, it needs to use io ports). Most of the issues I've seen so far were somewhat ACPI related (except for one due to a messed up Int10 handler, ie VGABIOS), and I collected some bits and pieces on http://coreboot.org/ACPI. ACPI debugging is _much_ more powerful with checked builds than without, but for other issues the additional asserts, symbols and lower optimization level are useful, too. However they're of limited use when trying to find issues in the installer, since that (at least up to Win8) is non-"checked" even on checked build media. Patrick From duwe at lst.de Wed Feb 11 17:23:13 2015 From: duwe at lst.de (Torsten Duwe) Date: Wed, 11 Feb 2015 17:23:13 +0100 Subject: [coreboot] How to get rid of your UEFI Message-ID: <20150211162312.GA7720@lst.de> Your flash chip is protected? You're dealing with hideous SMM? Maybe this will help: http://blog.cr4.sh/2015/02/exploiting-uefi-boot-script-table.html Based on a 31c3 talk. I thought I'd post it here as long as it's useful. Torsten From tpearson at raptorengineeringinc.com Wed Feb 11 18:41:56 2015 From: tpearson at raptorengineeringinc.com (Timothy Pearson) Date: Wed, 11 Feb 2015 11:41:56 -0600 Subject: [coreboot] [RFH] ACPI testers needed! Message-ID: <54DB9464.50508@raptorengineeringinc.com> All, I have recently updated the coreboot ACPI autogeneration code to generate valid processor _PSS objects when more than 10 cores are installed in one system. Unfortunately this required a rather large update to multiple boards in order to change the _PSS object name from CPUn to CPnn. We would like some feedback to make sure this update didn't break anything before committing. The patch is available at: http://review.coreboot.org/8422 Thanks! -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 http://www.raptorengineeringinc.com From paulepanter at users.sourceforge.net Wed Feb 11 23:36:14 2015 From: paulepanter at users.sourceforge.net (Paul Menzel) Date: Wed, 11 Feb 2015 23:36:14 +0100 Subject: [coreboot] ASUS KFSN4-DRe: Board status with incomplete coreboot console and time stamps showing long device init Message-ID: <1423694174.2630.103.camel@users.sourceforge.net> Dear Timothy, thanks again for improving the support for the ASUS KFSN4-DRE and being so responsive. It?s a great example for how to work with upstream! You uploaded the board status output [1] with commit 8057285 [2]. Thanks! But, it looks like a lot of information is missing from the coreboot console messages, like it was cut. Could you upload another run with the same commit or, for example, from latest master? Does `util/cbmem/cbmem -c` show all messages? You?d need to enable CBMEM console in Kconfig for that though. (SeaBIOS is also able to write its messages to CBMEM console.) Lastly, you put the time stamps on the Wiki page [3]. Could you please also upload those into the board status repository as people expect such information to be there? They would probably not go looking in the Wiki and in the board status repository the time stamps can be mapped to a specific commit. 10:start of ramstage 20,261 30:device enumeration 25,566 (5,304) 40:device configuration 50,219 (24,653) 50:device enable 108,559 (58,339) 60:device initialization 109,734 (1,175) 70:device setup done 1,056,523 (946,789) 75:cbmem post 1,057,578 (1,054) 80:write tables 1,058,641 (1,063) 90:load payload 1,064,180 (5,539) 99:selfboot jump 1,123,383 (59,202) Looking at the actual time stamps below do you see from your logs why the device initialization takes almost one second? As the timings on the Wiki page [3] show, it?s not related to enabling graphics/VGA. I guess SeaBIOS executes fairly quickly too? Do you have timing data for that as well? Or do you use COMBOOT as a payload? Just for comparison, how long does the vendor firmware take to get to COMBOOT [4] or whatever you use? Thanks, Paul [1] http://review.coreboot.org/gitweb?p=board-status.git;a=commitdiff;h=96b9b0f3fa68eb4cc97cee16616024e83e94536e [2] http://review.coreboot.org/8270 [3] http://coreboot.org/Board:asus/kfsn4-dre [4] http://www.syslinux.org/doc/comboot.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From benediktwindolph at gmail.com Thu Feb 12 00:30:08 2015 From: benediktwindolph at gmail.com (Benny) Date: Thu, 12 Feb 2015 00:30:08 +0100 Subject: [coreboot] dell sputnik Message-ID: <1423697408.8208.1.camel@gmail.com> Hey everyone, is there a chance coreboot comes to the Dell Sputnik (XPS13, L322X1Y1)? Thanks, Benny From paulepanter at users.sourceforge.net Thu Feb 12 00:51:18 2015 From: paulepanter at users.sourceforge.net (Paul Menzel) Date: Thu, 12 Feb 2015 00:51:18 +0100 Subject: [coreboot] [RFH] ACPI testers needed! In-Reply-To: <54DB9464.50508@raptorengineeringinc.com> References: <54DB9464.50508@raptorengineeringinc.com> Message-ID: <1423698678.2630.123.camel@users.sourceforge.net> Dear Timothy, Am Mittwoch, den 11.02.2015, 11:41 -0600 schrieb Timothy Pearson: > I have recently updated the coreboot ACPI autogeneration code to > generate valid processor _PSS objects when more than 10 cores are > installed in one system. > > Unfortunately this required a rather large update to multiple boards in > order to change the _PSS object name from CPUn to CPnn. We would like > some feedback to make sure this update didn't break anything before > committing. > > The patch is available at: http://review.coreboot.org/8422 I tried to test this with an image built for QEMU/KVM as you can specify the number of CPUs there with the switch `-smp cpus=n`. But I have not looked yet, if the changed code is even used by the QEMU image and I did not have time yet, to get an OS image to actually verify that everything works. Do you have a suggestion? Just `/proc/cpuinfo`? Does that depend on correct ACPI entries? Thanks, Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From gregg.drwho8 at gmail.com Thu Feb 12 00:59:13 2015 From: gregg.drwho8 at gmail.com (Gregg Levine) Date: Wed, 11 Feb 2015 18:59:13 -0500 Subject: [coreboot] dell sputnik In-Reply-To: <1423697408.8208.1.camel@gmail.com> References: <1423697408.8208.1.camel@gmail.com> Message-ID: Hello! How about you do us the favor of telling us more about your laptop? You will need to run certain programs or use specific Linux commands to tell us what the laptop wears. Please note that the majority of laptops wear specialty chips who are specifically configured to run those features that enable the special functions that make them different from desktop motherboards. For example there is an embedded controller involved who handles those functions, and typically information is not involved. The one of the Linux commands are #lspci who will tell you what the internal PCI bus looks like and there are others. The coreboot wiki contains these, plus the programs needed, flashrom to, ah, program the flash, superio to identify that part. Please study this site http://www.coreboot.org/Welcome_to_coreboot from there you'll find out more then I can provide here. Plus you have the support of these friendly people to help you further. My problem is that your Dell Sputnik or Dell traveler is not known to me. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again." On Wed, Feb 11, 2015 at 6:30 PM, Benny wrote: > Hey everyone, > > is there a chance coreboot comes to the Dell Sputnik (XPS13, L322X1Y1)? > > Thanks, > > Benny > > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot From tpearson at raptorengineeringinc.com Thu Feb 12 01:21:09 2015 From: tpearson at raptorengineeringinc.com (Timothy Pearson) Date: Wed, 11 Feb 2015 18:21:09 -0600 Subject: [coreboot] [RFH] ACPI testers needed! In-Reply-To: <1423698678.2630.123.camel@users.sourceforge.net> References: <54DB9464.50508@raptorengineeringinc.com> <1423698678.2630.123.camel@users.sourceforge.net> Message-ID: <54DBF1F5.1030603@raptorengineeringinc.com> On 02/11/2015 05:51 PM, Paul Menzel wrote: > Dear Timothy, > > > Am Mittwoch, den 11.02.2015, 11:41 -0600 schrieb Timothy Pearson: > >> I have recently updated the coreboot ACPI autogeneration code to >> generate valid processor _PSS objects when more than 10 cores are >> installed in one system. >> >> Unfortunately this required a rather large update to multiple boards in >> order to change the _PSS object name from CPUn to CPnn. We would like >> some feedback to make sure this update didn't break anything before >> committing. >> >> The patch is available at: http://review.coreboot.org/8422 > > I tried to test this with an image built for QEMU/KVM as you can specify > the number of CPUs there with the switch `-smp cpus=n`. But I have not > looked yet, if the changed code is even used by the QEMU image and I did > not have time yet, to get an OS image to actually verify that everything > works. > > Do you have a suggestion? Just `/proc/cpuinfo`? Does that depend on > correct ACPI entries? > > > Thanks, > > Paul Sorry, I should have mentioned a test procedure with my request. :-) Boot Linux and execute: dmesg | grep ACPI Look for any failures in that output; they will be very obvious (e.g. AE_NOT_FOUND, etc.). If the dmesg output looks good and your CPU supports frequency scaling you can also check this: ls /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq | wc -l If all the processor objects were created correctly the output of that command should match the number of physical CPU cores active on your system. Note that if your mainboard does not support ACPI processor objects these checks won't work, but at the same time it should not have been affected by the patch in question. -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 http://www.raptorengineeringinc.com From gregg.drwho8 at gmail.com Thu Feb 12 01:35:55 2015 From: gregg.drwho8 at gmail.com (Gregg Levine) Date: Wed, 11 Feb 2015 19:35:55 -0500 Subject: [coreboot] dell sputnik In-Reply-To: <1423700338.4579.2.camel@gmail.com> References: <1423697408.8208.1.camel@gmail.com> <1423700338.4579.2.camel@gmail.com> Message-ID: Hello! Okay, I'll send them along to the list where we should be having this conversation. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again." On Wed, Feb 11, 2015 at 7:18 PM, Benny wrote: > I attached 2 files, i hope it contains the required information. > If there is something missing let me know. > > > Am Mittwoch, den 11.02.2015, 18:59 -0500 schrieb Gregg Levine: >> Hello! >> How about you do us the favor of telling us more about your laptop? >> You will need to run certain programs or use specific Linux commands >> to tell us what the laptop wears. >> >> Please note that the majority of laptops wear specialty chips who are >> specifically configured to run those features that enable the special >> functions that make them different from desktop motherboards. >> >> For example there is an embedded controller involved who handles those >> functions, and typically information is not involved. >> >> The one of the Linux commands are #lspci who will tell you what the >> internal PCI bus looks like and there are others. The coreboot wiki >> contains these, plus the programs needed, flashrom to, ah, program the >> flash, superio to identify that part. >> >> Please study this site http://www.coreboot.org/Welcome_to_coreboot >> from there you'll find out more then I can provide here. Plus you have >> the support of these friendly people to help you further. >> >> My problem is that your Dell Sputnik or Dell traveler is not known to me. >> ----- >> Gregg C Levine gregg.drwho8 at gmail.com >> "This signature fought the Time Wars, time and again." >> >> >> On Wed, Feb 11, 2015 at 6:30 PM, Benny wrote: >> > Hey everyone, >> > >> > is there a chance coreboot comes to the Dell Sputnik (XPS13, L322X1Y1)? >> > >> > Thanks, >> > >> > Benny >> > >> > >> > -- >> > coreboot mailing list: coreboot at coreboot.org >> > http://www.coreboot.org/mailman/listinfo/coreboot > -------------- next part -------------- ============ start debug info ============ libhd version 21.10u (x86-64) [7688] using /var/lib/hardware kernel version is 3.18 ----- /proc/cmdline ----- BOOT_IMAGE=/vmlinuz-linux root=UUID=ffca0b5e-a0d9-41e3-9aa4-20650ff12119 rw quiet ----- /proc/cmdline end ----- debug = 0xff7ffff7 probe = 0x15938fcdaa17fcf9fffe (+memory +pci +isapnp +net +floppy +misc +misc.serial +misc.par +misc.floppy +serial +cpu +bios +monitor +mouse +scsi +usb -usb.mods +modem +modem.usb +parallel +parallel.lp +parallel.zip -isa -isa.isdn +isdn +kbd +prom +sbus +int +braille +braille.alva +braille.fhp +braille.ht -ignx11 +sys -bios.vbe -isapnp.old -isapnp.new -isapnp.mod +braille.baum -manual +fb +pppoe -scan +pcmcia +fork -parallel.imm +s390 +cpuemu -sysfs -s390disks +udev +block +block.cdrom +block.part +edd +edd.mod -bios.ddc -bios.fb -bios.mode +input +block.mods +bios.vesa -cpuemu.debug -scsi.noserial +wlan -bios.crc -hal +bios.vram +bios.acpi -bios.ddc.ports=0 +modules.pata -net.eeprom +x86emu=dump -max -lxrc) shm: attached segment 7667723 at 0x7fab48fec000 >> hal.1: read hal data >> floppy.1: get nvram >> floppy.2: klog info >> bios.1: cmdline >> bios.1.1: apm >> bios.2: ram bios: 0 disks >> bios.2: rom >> bios.3: smp ----- BIOS data 0x00400 - 0x004ff ----- 400 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 "................" 410 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 "................" 420 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 "................" 430 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 "................" 440 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 "................" 450 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 "................" 460 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 "................" 470 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 "................" 480 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 "................" 490 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 "................" 4a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 "................" 4b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 "................" 4c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 "................" 4d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 "................" 4e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 "................" 4f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 "................" ----- BIOS data end ----- >> bios.4: vbe >> bios.4.1: vbe info === bios setup === failed to read /dev/mem x86emu: could not init vm >> bios.5: 32 >> bios.6: acpi >> sys.1: cpu vm check: vm_1 = 0, vm_2 = -1 is_vmware = 0, has_vmware_mouse = 0 >> misc.9: kernel log >> misc.1: misc data >> misc.1.1: open serial >> misc.1.2: open parallel ----- exec: "/sbin/modprobe parport " ----- modprobe: ERROR: could not insert 'parport': Operation not permitted ----- return code: ? ----- ----- exec: "/sbin/modprobe parport_pc " ----- modprobe: ERROR: could not insert 'parport_pc': Operation not permitted ----- return code: ? ----- >> misc.2.1: io >> misc.2.2: dma >> misc.2.3: irq ----- /proc/ioports ----- 0000-0cf7 : PCI Bus 0000:00 0000-001f : dma1 0020-0021 : pic1 0040-0043 : timer0 0050-0053 : timer1 0060-0060 : keyboard 0062-0062 : PNP0C09:00 0062-0062 : EC data 0064-0064 : keyboard 0066-0066 : PNP0C09:00 0066-0066 : EC cmd 0070-0077 : rtc0 0080-008f : dma page reg 00a0-00a1 : pic2 00c0-00df : dma2 00f0-00ff : fpu 00f0-00f0 : PNP0C04:00 0400-0403 : ACPI PM1a_EVT_BLK 0404-0405 : ACPI PM1a_CNT_BLK 0408-040b : ACPI PM_TMR 0410-0415 : ACPI CPU throttle 0420-042f : ACPI GPE0_BLK 0430-0433 : iTCO_wdt 0430-0433 : iTCO_wdt 0450-0450 : ACPI PM2_CNT_BLK 0454-0457 : pnp 00:02 0458-047f : pnp 00:00 0460-047f : iTCO_wdt 0460-047f : iTCO_wdt 0500-057f : pnp 00:00 0680-069f : pnp 00:00 0cf8-0cff : PCI conf1 0d00-ffff : PCI Bus 0000:00 1000-1003 : pnp 00:00 1004-1013 : pnp 00:00 164e-164f : pnp 00:00 2000-203f : 0000:00:02.0 2060-207f : 0000:00:1f.2 2060-207f : ahci 2080-2087 : 0000:00:1f.2 2080-2087 : ahci 2088-208f : 0000:00:1f.2 2088-208f : ahci 2098-209b : 0000:00:1f.2 2098-209b : ahci 209c-209f : 0000:00:1f.2 209c-209f : ahci efa0-efbf : 0000:00:1f.3 ffff-ffff : pnp 00:00 ----- /proc/ioports end ----- ----- /proc/interrupts ----- 0: 27 0 0 0 IO-APIC-edge timer 1: 7347 28184 5215 4331 IO-APIC-edge i8042 8: 1 0 0 0 IO-APIC-edge rtc0 9: 2223 3573 835 615 IO-APIC-fasteoi acpi 12: 231455 1105417 159564 142071 IO-APIC-edge i8042 16: 84 51 24 7 IO-APIC 16-fasteoi ehci_hcd:usb3 23: 143 144 75 78 IO-APIC 23-fasteoi ehci_hcd:usb4 24: 103617 298375 65666 61059 PCI-MSI-edge i915 25: 0 0 0 0 PCI-MSI-edge xhci_hcd 26: 106881 148524 42864 42880 PCI-MSI-edge 0000:00:1f.2 27: 14 0 0 1 PCI-MSI-edge mei_me 28: 447 108 19 101 PCI-MSI-edge snd_hda_intel 29: 156214 255207 78723 82674 PCI-MSI-edge iwlwifi NMI: 194 193 199 196 Non-maskable interrupts LOC: 2350574 1761372 3242410 2804763 Local timer interrupts SPU: 0 0 0 0 Spurious interrupts PMI: 194 193 199 196 Performance monitoring interrupts IWI: 0 1 0 2 IRQ work interrupts RTR: 2 0 0 0 APIC ICR read retries RES: 548574 498668 722931 630559 Rescheduling interrupts CAL: 1336 1230 1340 1183 Function call interrupts TLB: 178501 194167 191416 188484 TLB shootdowns TRM: 0 0 0 0 Thermal event interrupts THR: 0 0 0 0 Threshold APIC interrupts MCE: 0 0 0 0 Machine check exceptions MCP: 76 76 76 76 Machine check polls HYP: 0 0 0 0 Hypervisor callback interrupts ERR: 0 MIS: 0 ----- /proc/interrupts end ----- ----- /proc/dma ----- 4: cascade ----- /proc/dma end ----- >> misc.3: FPU >> misc.3.1: DMA >> misc.3.2: PIC >> misc.3.3: timer >> misc.3.4: RTC >> cpu.1: cpuinfo ----- /proc/cpuinfo ----- processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 58 model name : Intel(R) Core(TM) i7-3537U CPU @ 2.00GHz stepping : 9 microcode : 0x1b cpu MHz : 2452.539 cache size : 4096 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt bugs : bogomips : 4990.52 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 58 model name : Intel(R) Core(TM) i7-3537U CPU @ 2.00GHz stepping : 9 microcode : 0x1b cpu MHz : 2898.144 cache size : 4096 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 2 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt bugs : bogomips : 4990.52 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 2 vendor_id : GenuineIntel cpu family : 6 model : 58 model name : Intel(R) Core(TM) i7-3537U CPU @ 2.00GHz stepping : 9 microcode : 0x1b cpu MHz : 2738.574 cache size : 4096 KB physical id : 0 siblings : 4 core id : 1 cpu cores : 2 apicid : 2 initial apicid : 2 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt bugs : bogomips : 4990.52 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 58 model name : Intel(R) Core(TM) i7-3537U CPU @ 2.00GHz stepping : 9 microcode : 0x1b cpu MHz : 2921.972 cache size : 4096 KB physical id : 0 siblings : 4 core id : 1 cpu cores : 2 apicid : 3 initial apicid : 3 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt bugs : bogomips : 4990.52 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: ----- /proc/cpuinfo end ----- >> memory.1: main memory size kcore mem: 0x7fffff602000 klog mem 0: 0x0 klog mem 1: 0x0 klog mem: 0x0 bios mem: 0x0 meminfo: 0x1ea7df000 xen balloon: 0x0 >> pci.1: sysfs drivers ----- sysfs driver list (id 0xf742329027b1bb00) ----- processor: /devices/system/cpu/cpu0 processor: /devices/system/cpu/cpu1 processor: /devices/system/cpu/cpu2 processor: /devices/system/cpu/cpu3 dummy: module = i2c_core ahci: /devices/pci0000:00/0000:00:1f.2 ahci: module = ahci i915: /devices/pci0000:00/0000:00:02.0 i915: module = drm iwlwifi: /devices/pci0000:00/0000:00:1c.0/0000:01:00.0 iwlwifi: module = iwlwifi i801_smbus: module = i2c_i801 lpc_ich: /devices/pci0000:00/0000:00:1f.0 lpc_ich: module = lpc_ich ehci-pci: /devices/pci0000:00/0000:00:1a.0 ehci-pci: /devices/pci0000:00/0000:00:1d.0 ehci-pci: module = ehci_pci snd_hda_intel: /devices/pci0000:00/0000:00:1b.0 snd_hda_intel: module = snd_hda_intel pcieport: /devices/pci0000:00/0000:00:1c.0 mei_me: /devices/pci0000:00/0000:00:16.0 mei_me: module = mei_me shpchp: module = shpchp xhci_hcd: /devices/pci0000:00/0000:00:14.0 xhci_hcd: module = xhci_pci ivb_uncore: /devices/pci0000:00/0000:00:00.0 rtc_cmos: /devices/pnp0/00:01 system: /devices/pnp0/00:00 system: /devices/pnp0/00:02 system: /devices/pnp0/00:05 i8042 aux: /devices/pnp0/00:04 i8042 kbd: /devices/pnp0/00:03 hub: /devices/pci0000:00/0000:00:1a.0/usb3/3-0:1.0 hub: /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1:1.0 hub: /devices/pci0000:00/0000:00:1d.0/usb4/4-0:1.0 hub: /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1:1.0 hub: module = usbcore hub: /devices/pci0000:00/0000:00:14.0/usb1/1-0:1.0 hub: /devices/pci0000:00/0000:00:14.0/usb2/2-0:1.0 usb: /devices/pci0000:00/0000:00:1a.0/usb3/3-1 usb: /devices/pci0000:00/0000:00:1d.0/usb4/4-1 usb: /devices/pci0000:00/0000:00:14.0/usb1 usb: /devices/pci0000:00/0000:00:14.0/usb2 usb: /devices/pci0000:00/0000:00:1a.0/usb3 usb: /devices/pci0000:00/0000:00:1d.0/usb4 usb: /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5 usb: /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5 usb: module = usbcore btusb: module = btusb btusb: /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5:1.0 btusb: /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5:1.1 usbfs: module = usbcore uvcvideo: /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5/3-1.5:1.0 uvcvideo: /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5/3-1.5:1.1 uvcvideo: module = uvcvideo ac: /devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00 ec: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0C09:00 wmi: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C14:00 video: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00 intel_smart_connect: /devices/LNXSYSTM:00/LNXSYBUS:00/INT33A0:00 thermal: /devices/LNXSYSTM:00/LNXSYBUS:01/LNXTHERM:00 thermal: /devices/LNXSYSTM:00/LNXSYBUS:01/LNXTHERM:01 button: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00 button: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00 button: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00 button: /devices/LNXSYSTM:00/LNXPWRBN:00 battery: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00 sd: /devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0 serio_raw: module = serio_raw atkbd: module = atkbd atkbd: /devices/platform/i8042/serio0 psmouse: module = psmouse psmouse: /devices/platform/i8042/serio1 i8042: /devices/platform/i8042 alarmtimer: /devices/platform/alarmtimer dcdbas: /devices/platform/dcdbas dcdbas: module = dcdbas efi-framebuffer: /devices/platform/efi-framebuffer.0 coretemp: module = coretemp coretemp: /devices/platform/coretemp.0 iTCO_wdt: /devices/pci0000:00/0000:00:1f.0/iTCO_wdt iTCO_wdt: module = iTCO_wdt pcspkr: module = pcspkr pcspkr: /devices/platform/pcspkr serial8250: /devices/platform/serial8250 vboxdrv: module = vboxdrv vboxdrv: /devices/platform/vboxdrv.0 dell-laptop: module = dell_laptop dell-laptop: /devices/platform/dell-laptop ----- sysfs driver list end ----- >> pci.2: get sysfs pci data pci device: name = 0000:00:00.0 path = /devices/pci0000:00/0000:00:00.0 modalias = "pci:v00008086d00000154sv00001028sd0000058Bbc06sc00i00" class = 0x60000 vendor = 0x8086 device = 0x154 subvendor = 0x1028 subdevice = 0x58b irq = 0 config[64] pci device: name = 0000:00:02.0 path = /devices/pci0000:00/0000:00:02.0 modalias = "pci:v00008086d00000166sv00001028sd0000058Bbc03sc00i00" class = 0x30000 vendor = 0x8086 device = 0x166 subvendor = 0x1028 subdevice = 0x58b irq = 24 res[0] = 0xd0000000 0xd03fffff 0x140204 res[2] = 0xc0000000 0xcfffffff 0x14220c res[4] = 0x2000 0x203f 0x40101 config[64] pci device: name = 0000:00:14.0 path = /devices/pci0000:00/0000:00:14.0 modalias = "pci:v00008086d00001E31sv00001028sd0000058Bbc0Csc03i30" class = 0xc0330 vendor = 0x8086 device = 0x1e31 subvendor = 0x1028 subdevice = 0x58b irq = 25 res[0] = 0xd0500000 0xd050ffff 0x140204 config[64] pci device: name = 0000:00:16.0 path = /devices/pci0000:00/0000:00:16.0 modalias = "pci:v00008086d00001E3Asv00001028sd0000058Bbc07sc80i00" class = 0x78000 vendor = 0x8086 device = 0x1e3a subvendor = 0x1028 subdevice = 0x58b irq = 27 res[0] = 0xd0515000 0xd051500f 0x140204 config[64] pci device: name = 0000:00:1a.0 path = /devices/pci0000:00/0000:00:1a.0 modalias = "pci:v00008086d00001E2Dsv00001028sd0000058Bbc0Csc03i20" class = 0xc0320 vendor = 0x8086 device = 0x1e2d subvendor = 0x1028 subdevice = 0x58b irq = 16 res[0] = 0xd051a000 0xd051a3ff 0x40200 config[64] pci device: name = 0000:00:1b.0 path = /devices/pci0000:00/0000:00:1b.0 modalias = "pci:v00008086d00001E20sv00001028sd0000058Bbc04sc03i00" class = 0x40300 vendor = 0x8086 device = 0x1e20 subvendor = 0x1028 subdevice = 0x58b irq = 28 res[0] = 0xd0510000 0xd0513fff 0x140204 config[64] pci device: name = 0000:00:1c.0 path = /devices/pci0000:00/0000:00:1c.0 modalias = "pci:v00008086d00001E10sv00001028sd0000058Bbc06sc04i00" class = 0x60400 vendor = 0x8086 device = 0x1e10 subvendor = 0x1028 subdevice = 0x58b irq = 16 config[64] pci device: name = 0000:00:1d.0 path = /devices/pci0000:00/0000:00:1d.0 modalias = "pci:v00008086d00001E26sv00001028sd0000058Bbc0Csc03i20" class = 0xc0320 vendor = 0x8086 device = 0x1e26 subvendor = 0x1028 subdevice = 0x58b irq = 23 res[0] = 0xd0519000 0xd05193ff 0x40200 config[64] pci device: name = 0000:00:1f.0 path = /devices/pci0000:00/0000:00:1f.0 modalias = "pci:v00008086d00001E56sv00001028sd0000058Bbc06sc01i00" class = 0x60100 vendor = 0x8086 device = 0x1e56 subvendor = 0x1028 subdevice = 0x58b irq = 0 config[64] pci device: name = 0000:00:1f.2 path = /devices/pci0000:00/0000:00:1f.2 modalias = "pci:v00008086d00001E03sv00001028sd0000058Bbc01sc06i01" class = 0x10601 vendor = 0x8086 device = 0x1e03 subvendor = 0x1028 subdevice = 0x58b irq = 26 res[0] = 0x2088 0x208f 0x40101 res[1] = 0x209c 0x209f 0x40101 res[2] = 0x2080 0x2087 0x40101 res[3] = 0x2098 0x209b 0x40101 res[4] = 0x2060 0x207f 0x40101 res[5] = 0xd0518000 0xd05187ff 0x40200 config[64] pci device: name = 0000:00:1f.3 path = /devices/pci0000:00/0000:00:1f.3 modalias = "pci:v00008086d00001E22sv00001028sd0000058Bbc0Csc05i00" class = 0xc0500 vendor = 0x8086 device = 0x1e22 subvendor = 0x1028 subdevice = 0x58b irq = 18 res[0] = 0xd0514000 0xd05140ff 0x140204 res[4] = 0xefa0 0xefbf 0x40101 config[64] pci device: name = 0000:01:00.0 path = /devices/pci0000:00/0000:00:1c.0/0000:01:00.0 modalias = "pci:v00008086d000008B1sv00008086sd00004070bc02sc80i00" class = 0x28000 vendor = 0x8086 device = 0x8b1 subvendor = 0x8086 subdevice = 0x4070 irq = 29 res[0] = 0xd0400000 0xd0401fff 0x140204 config[64] ---------- PCI raw data ---------- bus 00, slot 00, func 0, vend:dev:s_vend:s_dev:rev 8086:0154:1028:058b:09 class 06, sub_class 00 prog_if 00, hdr 0, flags <>, irq 0 00: 86 80 54 01 06 00 90 20 09 00 00 06 00 00 00 00 "..T.... ........" 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 "................" 20: 00 00 00 00 00 00 00 00 00 00 00 00 28 10 8b 05 "............(..." 30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00 "................" bus 00, slot 02, func 0, vend:dev:s_vend:s_dev:rev 8086:0166:1028:058b:09 class 03, sub_class 00 prog_if 00, hdr 0, flags <>, irq 24 addr0 d0000000, size 00400000 addr2 c0000000, size 10000000 addr4 00002000, size 00000040 00: 86 80 66 01 07 04 90 00 09 00 00 03 00 00 00 00 "..f............." 10: 04 00 00 d0 00 00 00 00 0c 00 00 c0 00 00 00 00 "................" 20: 01 20 00 00 00 00 00 00 00 00 00 00 28 10 8b 05 ". ..........(..." 30: 00 00 00 00 90 00 00 00 00 00 00 00 ff 01 00 00 "................" bus 00, slot 14, func 0, vend:dev:s_vend:s_dev:rev 8086:1e31:1028:058b:04 class 0c, sub_class 03 prog_if 30, hdr 0, flags <>, irq 25 addr0 d0500000, size 00010000 00: 86 80 31 1e 06 04 90 02 04 30 03 0c 00 00 00 00 "..1......0......" 10: 04 00 50 d0 00 00 00 00 00 00 00 00 00 00 00 00 "..P............." 20: 00 00 00 00 00 00 00 00 00 00 00 00 28 10 8b 05 "............(..." 30: 00 00 00 00 70 00 00 00 00 00 00 00 ff 01 00 00 "....p..........." bus 00, slot 16, func 0, vend:dev:s_vend:s_dev:rev 8086:1e3a:1028:058b:04 class 07, sub_class 80 prog_if 00, hdr 0, flags <>, irq 27 addr0 d0515000, size 00000010 00: 86 80 3a 1e 06 04 10 00 04 00 80 07 00 00 80 00 "..:............." 10: 04 50 51 d0 00 00 00 00 00 00 00 00 00 00 00 00 ".PQ............." 20: 00 00 00 00 00 00 00 00 00 00 00 00 28 10 8b 05 "............(..." 30: 00 00 00 00 50 00 00 00 00 00 00 00 ff 01 00 00 "....P..........." bus 00, slot 1a, func 0, vend:dev:s_vend:s_dev:rev 8086:1e2d:1028:058b:04 class 0c, sub_class 03 prog_if 20, hdr 0, flags <>, irq 16 addr0 d051a000, size 00000400 00: 86 80 2d 1e 06 00 90 02 04 20 03 0c 00 00 00 00 "..-...... ......" 10: 00 a0 51 d0 00 00 00 00 00 00 00 00 00 00 00 00 "..Q............." 20: 00 00 00 00 00 00 00 00 00 00 00 00 28 10 8b 05 "............(..." 30: 00 00 00 00 50 00 00 00 00 00 00 00 ff 01 00 00 "....P..........." bus 00, slot 1b, func 0, vend:dev:s_vend:s_dev:rev 8086:1e20:1028:058b:04 class 04, sub_class 03 prog_if 00, hdr 0, flags <>, irq 28 addr0 d0510000, size 00004000 00: 86 80 20 1e 06 04 10 00 04 00 03 04 10 00 00 00 ".. ............." 10: 04 00 51 d0 00 00 00 00 00 00 00 00 00 00 00 00 "..Q............." 20: 00 00 00 00 00 00 00 00 00 00 00 00 28 10 8b 05 "............(..." 30: 00 00 00 00 50 00 00 00 00 00 00 00 ff 01 00 00 "....P..........." bus 00->01, slot 1c, func 0, vend:dev:s_vend:s_dev:rev 8086:1e10:1028:058b:c4 class 06, sub_class 04 prog_if 00, hdr 1, flags <>, irq 16 00: 86 80 10 1e 07 00 10 00 c4 00 04 06 10 00 81 00 "................" 10: 00 00 00 00 00 00 00 00 00 01 01 00 f0 00 00 20 "............... " 20: 40 d0 40 d0 f1 ff 01 00 00 00 00 00 00 00 00 00 "@. at ............." 30: 00 00 00 00 40 00 00 00 00 00 00 00 ff 01 00 00 ".... at ..........." bus 00, slot 1d, func 0, vend:dev:s_vend:s_dev:rev 8086:1e26:1028:058b:04 class 0c, sub_class 03 prog_if 20, hdr 0, flags <>, irq 23 addr0 d0519000, size 00000400 00: 86 80 26 1e 06 00 90 02 04 20 03 0c 00 00 00 00 "..&...... ......" 10: 00 90 51 d0 00 00 00 00 00 00 00 00 00 00 00 00 "..Q............." 20: 00 00 00 00 00 00 00 00 00 00 00 00 28 10 8b 05 "............(..." 30: 00 00 00 00 50 00 00 00 00 00 00 00 ff 01 00 00 "....P..........." bus 00, slot 1f, func 0, vend:dev:s_vend:s_dev:rev 8086:1e56:1028:058b:04 class 06, sub_class 01 prog_if 00, hdr 0, flags <>, irq 0 00: 86 80 56 1e 07 00 10 02 04 00 01 06 00 00 80 00 "..V............." 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 "................" 20: 00 00 00 00 00 00 00 00 00 00 00 00 28 10 8b 05 "............(..." 30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00 "................" bus 00, slot 1f, func 2, vend:dev:s_vend:s_dev:rev 8086:1e03:1028:058b:04 class 01, sub_class 06 prog_if 01, hdr 0, flags <>, irq 26 addr0 00002088, size 00000008 addr1 0000209c, size 00000004 addr2 00002080, size 00000008 addr3 00002098, size 00000004 addr4 00002060, size 00000020 addr5 d0518000, size 00000800 00: 86 80 03 1e 07 04 b0 02 04 01 06 01 00 00 00 00 "................" 10: 89 20 00 00 9d 20 00 00 81 20 00 00 99 20 00 00 ". ... ... ... .." 20: 61 20 00 00 00 80 51 d0 00 00 00 00 28 10 8b 05 "a ....Q.....(..." 30: 00 00 00 00 80 00 00 00 00 00 00 00 ff 02 00 00 "................" bus 00, slot 1f, func 3, vend:dev:s_vend:s_dev:rev 8086:1e22:1028:058b:04 class 0c, sub_class 05 prog_if 00, hdr 0, flags <>, irq 18 addr0 d0514000, size 00000100 addr4 0000efa0, size 00000020 00: 86 80 22 1e 03 00 80 02 04 00 05 0c 00 00 00 00 ".."............." 10: 04 40 51 d0 00 00 00 00 00 00 00 00 00 00 00 00 ". at Q............." 20: a1 ef 00 00 00 00 00 00 00 00 00 00 28 10 8b 05 "............(..." 30: 00 00 00 00 00 00 00 00 00 00 00 00 ff 03 00 00 "................" bus 01, slot 00, func 0, vend:dev:s_vend:s_dev:rev 8086:08b1:8086:4070:bb class 02, sub_class 80 prog_if 00, hdr 0, flags <>, irq 29 addr0 d0400000, size 00002000 00: 86 80 b1 08 06 04 10 00 bb 00 80 02 10 00 00 00 "................" 10: 04 00 40 d0 00 00 00 00 00 00 00 00 00 00 00 00 ".. at ............." 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 70 40 "..............p@" 30: 00 00 00 00 c8 00 00 00 00 00 00 00 ff 01 00 00 "................" ---------- PCI raw data end ---------- >> pci.4: build list >> pci.3: macio sysfs: no such bus: macio >> pci.4: vio sysfs: no such bus: vio >> pci.5: xen sysfs: no such bus: xen >> pci.6: ps3 sysfs: no such bus: ps3_system_bus >> pci.7: platform platform device: name = INT33A0:00 path = /devices/platform/INT33A0:00 type = "(null)", modalias = "acpi:INT33A0:" platform device: name = i8042 path = /devices/platform/i8042 type = "(null)", modalias = "platform:i8042" platform device: name = PNP0C04:00 path = /devices/pci0000:00/0000:00:1f.0/PNP0C04:00 type = "(null)", modalias = "acpi:PNP0C04:" platform device: name = PNP0C09:00 path = /devices/pci0000:00/0000:00:1f.0/PNP0C09:00 type = "(null)", modalias = "acpi:PNP0C09:" platform device: name = PNP0C14:00 path = /devices/platform/PNP0C14:00 type = "(null)", modalias = "acpi:PNP0C14:" platform device: name = PNP0C0A:00 path = /devices/platform/PNP0C0A:00 type = "(null)", modalias = "acpi:PNP0C0A:" platform device: name = PNP0C0C:00 path = /devices/platform/PNP0C0C:00 type = "(null)", modalias = "acpi:PNP0C0C:" platform device: name = PNP0C0D:00 path = /devices/platform/PNP0C0D:00 type = "(null)", modalias = "acpi:PNP0C0D:" platform device: name = PNP0C0E:00 path = /devices/platform/PNP0C0E:00 type = "(null)", modalias = "acpi:PNP0C0E:" platform device: name = PNP0C32:00 path = /devices/pci0000:00/0000:00:1f.0/PNP0C32:00 type = "(null)", modalias = "acpi:PNP0C32:" platform device: name = efi-framebuffer.0 path = /devices/platform/efi-framebuffer.0 type = "(null)", modalias = "platform:efi-framebuffer" platform device: name = alarmtimer path = /devices/platform/alarmtimer type = "(null)", modalias = "platform:alarmtimer" platform device: name = dcdbas path = /devices/platform/dcdbas type = "(null)", modalias = "platform:dcdbas" platform device: name = iTCO_wdt path = /devices/pci0000:00/0000:00:1f.0/iTCO_wdt type = "(null)", modalias = "platform:iTCO_wdt" platform device: name = pcspkr path = /devices/platform/pcspkr type = "(null)", modalias = "platform:pcspkr" platform device: name = serial8250 path = /devices/platform/serial8250 type = "(null)", modalias = "platform:serial8250" platform device: name = dell-laptop path = /devices/platform/dell-laptop type = "(null)", modalias = "platform:dell-laptop" platform device: name = vboxdrv.0 path = /devices/platform/vboxdrv.0 type = "(null)", modalias = "platform:vboxdrv" platform device: name = regulatory.0 path = /devices/platform/regulatory.0 type = "(null)", modalias = "platform:regulatory" platform device: name = microcode path = /devices/platform/microcode type = "(null)", modalias = "platform:microcode" platform device: name = coretemp.0 path = /devices/platform/coretemp.0 type = "(null)", modalias = "platform:coretemp" platform device: name = PNP0103:00 path = /devices/pci0000:00/0000:00:1f.0/PNP0103:00 type = "(null)", modalias = "acpi:PNP0103:" platform device: name = ACPI0003:00 path = /devices/platform/ACPI0003:00 type = "(null)", modalias = "acpi:ACPI0003:" platform device: name = ACPI0008:00 path = /devices/pci0000:00/0000:00:1f.0/PNP0C09:00/ACPI0008:00 type = "(null)", modalias = "acpi:ACPI0008:" >> pci.8: of_platform sysfs: no such bus: of_platform >> pci.9: vm sysfs: no such bus: vm >> pci.10: virtio sysfs: no such bus: virtio >> pci.11: ibmebus sysfs: no such bus: ibmebus >> pci.12: uisvirtpci sysfs: no such bus: uisvirtpci >> monitor.1: ddc >> monitor.2: bios >> monitor.3: pci >> monitor.4: internal db >> monitor.5: prom >> pcmcia.1: sysfs drivers >> pcmcia.2: pcmcia sysfs: no such bus: pcmcia >> pcmcia.3: pcmcia ctrl sysfs: no such class: pcmcia_socket >> serial.1: read info ----- serial info ----- ----- serial info end ----- >> serial.2: build list >> misc.5: misc data ----- misc resources ----- i/o:0 0x0000 - 0x0cf7 (0xcf8) "PCI Bus 0000:00" i/o:1 0x0000 - 0x001f (0x20) "dma1" i/o:1 0x0020 - 0x0021 (0x02) "pic1" i/o:0 0x0040 - 0x0043 (0x04) "timer0" i/o:0 0x0050 - 0x0053 (0x04) "timer1" i/o:1 0x0060 - 0x0060 (0x01) "keyboard" i/o:0 0x0062 - 0x0062 (0x01) "PNP0C09:00" i/o:0 0x0062 - 0x0062 (0x01) "EC data" i/o:1 0x0064 - 0x0064 (0x01) "keyboard" i/o:0 0x0066 - 0x0066 (0x01) "PNP0C09:00" i/o:0 0x0066 - 0x0066 (0x01) "EC cmd" i/o:0 0x0070 - 0x0077 (0x08) "rtc0" i/o:1 0x0080 - 0x008f (0x10) "dma page reg" i/o:1 0x00a0 - 0x00a1 (0x02) "pic2" i/o:1 0x00c0 - 0x00df (0x20) "dma2" i/o:1 0x00f0 - 0x00ff (0x10) "fpu" i/o:0 0x00f0 - 0x00f0 (0x01) "PNP0C04:00" i/o:0 0x0400 - 0x0403 (0x04) "ACPI PM1a_EVT_BLK" i/o:0 0x0404 - 0x0405 (0x02) "ACPI PM1a_CNT_BLK" i/o:0 0x0408 - 0x040b (0x04) "ACPI PM_TMR" i/o:0 0x0410 - 0x0415 (0x06) "ACPI CPU throttle" i/o:0 0x0420 - 0x042f (0x10) "ACPI GPE0_BLK" i/o:0 0x0430 - 0x0433 (0x04) "iTCO_wdt" i/o:0 0x0430 - 0x0433 (0x04) "iTCO_wdt" i/o:0 0x0450 - 0x0450 (0x01) "ACPI PM2_CNT_BLK" i/o:0 0x0454 - 0x0457 (0x04) "pnp 00:02" i/o:0 0x0458 - 0x047f (0x28) "pnp 00:00" i/o:0 0x0460 - 0x047f (0x20) "iTCO_wdt" i/o:0 0x0460 - 0x047f (0x20) "iTCO_wdt" i/o:0 0x0500 - 0x057f (0x80) "pnp 00:00" i/o:0 0x0680 - 0x069f (0x20) "pnp 00:00" i/o:0 0x0cf8 - 0x0cff (0x08) "PCI conf1" i/o:0 0x0d00 - 0xffff (0xf300) "PCI Bus 0000:00" i/o:0 0x1000 - 0x1003 (0x04) "pnp 00:00" i/o:0 0x1004 - 0x1013 (0x10) "pnp 00:00" i/o:0 0x164e - 0x164f (0x02) "pnp 00:00" i/o:0 0x2000 - 0x203f (0x40) "0000:00:02.0" i/o:0 0x2060 - 0x207f (0x20) "0000:00:1f.2" i/o:0 0x2060 - 0x207f (0x20) "ahci" i/o:0 0x2080 - 0x2087 (0x08) "0000:00:1f.2" i/o:0 0x2080 - 0x2087 (0x08) "ahci" i/o:0 0x2088 - 0x208f (0x08) "0000:00:1f.2" i/o:0 0x2088 - 0x208f (0x08) "ahci" i/o:0 0x2098 - 0x209b (0x04) "0000:00:1f.2" i/o:0 0x2098 - 0x209b (0x04) "ahci" i/o:0 0x209c - 0x209f (0x04) "0000:00:1f.2" i/o:0 0x209c - 0x209f (0x04) "ahci" i/o:0 0xefa0 - 0xefbf (0x20) "0000:00:1f.3" i/o:0 0xffff - 0xffff (0x01) "pnp 00:00" irq:1 0 ( 27) "timer" irq:0 1 ( 45077) "i8042" irq:0 8 ( 1) "rtc0" irq:0 9 ( 7246) "acpi" irq:0 12 ( 1638507) "i8042" irq:0 16 ( 166) "16-fasteoi ehci_hcd:usb3" irq:0 23 ( 440) "23-fasteoi ehci_hcd:usb4" irq:0 24 ( 528717) "i915" irq:0 25 ( 0) "xhci_hcd" irq:0 26 ( 341149) "0000:00:1f.2" irq:0 27 ( 15) "mei_me" irq:0 28 ( 675) "snd_hda_intel" irq:0 29 ( 572818) "iwlwifi" dma:1 4 "cascade" ----- misc resources end ----- >> parallel.1: pp mod ----- exec: "/sbin/modprobe parport_pc" ----- modprobe: ERROR: could not insert 'parport_pc': Operation not permitted ----- return code: ? ----- ----- exec: "/sbin/modprobe lp" ----- modprobe: ERROR: could not insert 'lp': Operation not permitted ----- return code: ? ----- >> parallel.2.1: lp read info >> parallel.2.2: lp read info >> parallel.2.3: lp read info ----- parallel info ----- ----- parallel info end ----- >> block.1: block modules ----- exec: "/sbin/modprobe ide-cd_mod " ----- modprobe: FATAL: Module ide-cd_mod not found. ----- return code: ? ----- ----- exec: "/sbin/modprobe ide-disk " ----- modprobe: FATAL: Module ide-disk not found. ----- return code: ? ----- ----- exec: "/sbin/modprobe sr_mod " ----- modprobe: ERROR: could not insert 'sr_mod': Operation not permitted ----- return code: ? ----- ----- exec: "/sbin/modprobe st " ----- modprobe: ERROR: could not insert 'st': Operation not permitted ----- return code: ? ----- >> block.2: sysfs drivers >> block.3: cdrom >> block.4: partition ----- /proc/partitions ----- 8 0 250059096 sda 8 1 1048576 sda1 8 2 8388608 sda2 8 3 240620871 sda3 ----- /proc/partitions end ----- disks: sda partitions: sda1 sda2 sda3 >> block.5: get sysfs block dev data ----- lsscsi ----- ----- lsscsi end ----- block: name = sda, path = /class/block/sda dev = 8:0 range = 16 block device: bus = scsi, bus_id = 0:0:0:0 driver = sd path = /devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0 vendor = ATA model = SAMSUNG SSD PM83 rev = 3D1Q type = 0 >> block.5: /dev/sda block: name = sda1, path = /class/block/sda1 dev = 8:1 block: name = sda2, path = /class/block/sda2 dev = 8:2 block: name = sda3, path = /class/block/sda3 dev = 8:3 >> scsi.1: scsi modules ----- exec: "/sbin/modprobe sg " ----- modprobe: ERROR: could not insert 'sg': Operation not permitted ----- return code: ? ----- >> scsi.2: scsi tape sysfs: no such class: scsi_tape >> scsi.3: scsi generic sysfs: no such class: scsi_generic >> usb.1: sysfs drivers >> usb.2: usb usb dev: /devices/pci0000:00/0000:00:1a.0/usb3/3-1 usb dev: /devices/pci0000:00/0000:00:1d.0/usb4/4-1 usb dev: /devices/pci0000:00/0000:00:14.0/usb1 usb dev: /devices/pci0000:00/0000:00:14.0/usb2 usb dev: /devices/pci0000:00/0000:00:1a.0/usb3 usb dev: /devices/pci0000:00/0000:00:1d.0/usb4 usb dev: /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5 usb dev: /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5 usb device: name = 3-1 path = /devices/pci0000:00/0000:00:1a.0/usb3/3-1 usb device: name = 4-1 path = /devices/pci0000:00/0000:00:1d.0/usb4/4-1 usb device: name = usb1 path = /devices/pci0000:00/0000:00:14.0/usb1 usb device: name = usb2 path = /devices/pci0000:00/0000:00:14.0/usb2 usb device: name = usb3 path = /devices/pci0000:00/0000:00:1a.0/usb3 usb device: name = usb4 path = /devices/pci0000:00/0000:00:1d.0/usb4 usb device: name = 3-1.5 path = /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5 usb device: name = 4-1.5 path = /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5 usb device: name = 3-0:1.0 path = /devices/pci0000:00/0000:00:1a.0/usb3/3-0:1.0 modalias = "usb:v1D6Bp0002d0318dc09dsc00dp00ic09isc00ip00in00" bInterfaceNumber = 0 bInterfaceClass = 9 bInterfaceSubClass = 0 bInterfaceProtocol = 0 if: 3-0:1.0 @ /devices/pci0000:00/0000:00:1a.0/usb3 bDeviceClass = 9 bDeviceSubClass = 0 bDeviceProtocol = 0 idVendor = 0x1d6b idProduct = 0x0002 manufacturer = "Linux 3.18.6-1-ARCH ehci_hcd" product = "EHCI Host Controller" serial = "0000:00:1a.0" bcdDevice = 0318 speed = "480" usb device: name = 3-1:1.0 path = /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1:1.0 modalias = "usb:v8087p0024d0000dc09dsc00dp01ic09isc00ip00in00" bInterfaceNumber = 0 bInterfaceClass = 9 bInterfaceSubClass = 0 bInterfaceProtocol = 0 if: 3-1:1.0 @ /devices/pci0000:00/0000:00:1a.0/usb3/3-1 bDeviceClass = 9 bDeviceSubClass = 0 bDeviceProtocol = 1 idVendor = 0x8087 idProduct = 0x0024 bcdDevice = 0000 speed = "480" usb device: name = 3-1.5:1.0 path = /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5/3-1.5:1.0 modalias = "usb:v1BCFp288Fd2710dcEFdsc02dp01ic0Eisc01ip00in00" bInterfaceNumber = 0 bInterfaceClass = 14 bInterfaceSubClass = 1 bInterfaceProtocol = 0 if: 3-1.5:1.0 @ /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5 bDeviceClass = 239 bDeviceSubClass = 2 bDeviceProtocol = 1 idVendor = 0x1bcf idProduct = 0x288f manufacturer = "CN01RH717248726AD005A00" product = "Laptop_Integrated_Webcam_1.3M" bcdDevice = 2710 speed = "480" usb device: name = 3-1.5:1.1 path = /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5/3-1.5:1.1 modalias = "usb:v1BCFp288Fd2710dcEFdsc02dp01ic0Eisc02ip00in01" bInterfaceNumber = 1 bInterfaceClass = 14 bInterfaceSubClass = 2 bInterfaceProtocol = 0 if: 3-1.5:1.1 @ /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5 bDeviceClass = 239 bDeviceSubClass = 2 bDeviceProtocol = 1 idVendor = 0x1bcf idProduct = 0x288f manufacturer = "CN01RH717248726AD005A00" product = "Laptop_Integrated_Webcam_1.3M" bcdDevice = 2710 speed = "480" usb device: name = 4-0:1.0 path = /devices/pci0000:00/0000:00:1d.0/usb4/4-0:1.0 modalias = "usb:v1D6Bp0002d0318dc09dsc00dp00ic09isc00ip00in00" bInterfaceNumber = 0 bInterfaceClass = 9 bInterfaceSubClass = 0 bInterfaceProtocol = 0 if: 4-0:1.0 @ /devices/pci0000:00/0000:00:1d.0/usb4 bDeviceClass = 9 bDeviceSubClass = 0 bDeviceProtocol = 0 idVendor = 0x1d6b idProduct = 0x0002 manufacturer = "Linux 3.18.6-1-ARCH ehci_hcd" product = "EHCI Host Controller" serial = "0000:00:1d.0" bcdDevice = 0318 speed = "480" usb device: name = 4-1:1.0 path = /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1:1.0 modalias = "usb:v8087p0024d0000dc09dsc00dp01ic09isc00ip00in00" bInterfaceNumber = 0 bInterfaceClass = 9 bInterfaceSubClass = 0 bInterfaceProtocol = 0 if: 4-1:1.0 @ /devices/pci0000:00/0000:00:1d.0/usb4/4-1 bDeviceClass = 9 bDeviceSubClass = 0 bDeviceProtocol = 1 idVendor = 0x8087 idProduct = 0x0024 bcdDevice = 0000 speed = "480" usb device: name = 4-1.5:1.0 path = /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5:1.0 modalias = "usb:v8087p07DCd0001dcE0dsc01dp01icE0isc01ip01in00" bInterfaceNumber = 0 bInterfaceClass = 224 bInterfaceSubClass = 1 bInterfaceProtocol = 1 if: 4-1.5:1.0 @ /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5 bDeviceClass = 224 bDeviceSubClass = 1 bDeviceProtocol = 1 idVendor = 0x8087 idProduct = 0x07dc bcdDevice = 0001 speed = "12" usb device: name = 4-1.5:1.1 path = /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5:1.1 modalias = "usb:v8087p07DCd0001dcE0dsc01dp01icE0isc01ip01in01" bInterfaceNumber = 1 bInterfaceClass = 224 bInterfaceSubClass = 1 bInterfaceProtocol = 1 if: 4-1.5:1.1 @ /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5 bDeviceClass = 224 bDeviceSubClass = 1 bDeviceProtocol = 1 idVendor = 0x8087 idProduct = 0x07dc bcdDevice = 0001 speed = "12" usb device: name = 1-0:1.0 path = /devices/pci0000:00/0000:00:14.0/usb1/1-0:1.0 modalias = "usb:v1D6Bp0002d0318dc09dsc00dp01ic09isc00ip00in00" bInterfaceNumber = 0 bInterfaceClass = 9 bInterfaceSubClass = 0 bInterfaceProtocol = 0 if: 1-0:1.0 @ /devices/pci0000:00/0000:00:14.0/usb1 bDeviceClass = 9 bDeviceSubClass = 0 bDeviceProtocol = 1 idVendor = 0x1d6b idProduct = 0x0002 manufacturer = "Linux 3.18.6-1-ARCH xhci-hcd" product = "xHCI Host Controller" serial = "0000:00:14.0" bcdDevice = 0318 speed = "480" usb device: name = 2-0:1.0 path = /devices/pci0000:00/0000:00:14.0/usb2/2-0:1.0 modalias = "usb:v1D6Bp0003d0318dc09dsc00dp03ic09isc00ip00in00" bInterfaceNumber = 0 bInterfaceClass = 9 bInterfaceSubClass = 0 bInterfaceProtocol = 0 if: 2-0:1.0 @ /devices/pci0000:00/0000:00:14.0/usb2 bDeviceClass = 9 bDeviceSubClass = 0 bDeviceProtocol = 3 idVendor = 0x1d6b idProduct = 0x0003 manufacturer = "Linux 3.18.6-1-ARCH xhci-hcd" product = "xHCI Host Controller" serial = "0000:00:14.0" bcdDevice = 0318 speed = "5000" removed: /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5/3-1.5:1.1 removed: /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5:1.1 >> usb.3.1: joydev mod >> usb.3.2: evdev mod >> usb.3.3: input input: name = mice, path = /devices/virtual/input/mice dev = 13:63 input: name = event10, path = /devices/pci0000:00/0000:00:1b.0/sound/card0/input12/event10 dev = 13:74 input device: bus = sound, bus_id = card0 driver = (null) path = /devices/pci0000:00/0000:00:1b.0/sound/card0 input: name = event11, path = /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5/3-1.5:1.0/input/input13/event11 dev = 13:75 input device: bus = usb, bus_id = 3-1.5:1.0 driver = uvcvideo path = /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5/3-1.5:1.0 input: name = event12, path = /devices/virtual/input/input14/event12 dev = 13:76 input device: bus = input, bus_id = input14 driver = (null) path = /devices/virtual/input/input14 input: name = event13, path = /devices/platform/i8042/serio1/input/input9/event13 dev = 13:77 input device: bus = serio, bus_id = serio1 driver = psmouse path = /devices/platform/i8042/serio1 input: name = event0, path = /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0/event0 dev = 13:64 input device: bus = acpi, bus_id = PNP0C0C:00 driver = button path = /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00 input: name = event1, path = /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input1/event1 dev = 13:65 input device: bus = acpi, bus_id = PNP0C0E:00 driver = button path = /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00 input: name = event2, path = /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/input/input2/event2 dev = 13:66 input device: bus = acpi, bus_id = PNP0C0D:00 driver = button path = /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00 input: name = event3, path = /devices/LNXSYSTM:00/LNXPWRBN:00/input/input3/event3 dev = 13:67 input device: bus = acpi, bus_id = LNXPWRBN:00 driver = button path = /devices/LNXSYSTM:00/LNXPWRBN:00 input: name = event4, path = /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input4/event4 dev = 13:68 input device: bus = acpi, bus_id = LNXVIDEO:00 driver = video path = /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00 input: name = event5, path = /devices/platform/i8042/serio0/input/input5/event5 dev = 13:69 input device: bus = serio, bus_id = serio0 driver = atkbd path = /devices/platform/i8042/serio0 input: name = event6, path = /devices/platform/pcspkr/input/input7/event6 dev = 13:70 input device: bus = platform, bus_id = pcspkr driver = pcspkr path = /devices/platform/pcspkr input: name = event7, path = /devices/pci0000:00/0000:00:1b.0/sound/card0/hdaudioC0D0/input8/event7 dev = 13:71 input device: bus = sound, bus_id = hdaudioC0D0 driver = (null) path = /devices/pci0000:00/0000:00:1b.0/sound/card0/hdaudioC0D0 input: name = event8, path = /devices/pci0000:00/0000:00:1b.0/sound/card0/input10/event8 dev = 13:72 input device: bus = sound, bus_id = card0 driver = (null) path = /devices/pci0000:00/0000:00:1b.0/sound/card0 input: name = event9, path = /devices/pci0000:00/0000:00:1b.0/sound/card0/input11/event9 dev = 13:73 input device: bus = sound, bus_id = card0 driver = (null) path = /devices/pci0000:00/0000:00:1b.0/sound/card0 input: name = input0, path = /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0 no dev - ignored input: name = input1, path = /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input1 no dev - ignored input: name = input2, path = /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/input/input2 no dev - ignored input: name = input3, path = /devices/LNXSYSTM:00/LNXPWRBN:00/input/input3 no dev - ignored input: name = input4, path = /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input4 no dev - ignored input: name = input5, path = /devices/platform/i8042/serio0/input/input5 no dev - ignored input: name = input7, path = /devices/platform/pcspkr/input/input7 no dev - ignored input: name = input8, path = /devices/pci0000:00/0000:00:1b.0/sound/card0/hdaudioC0D0/input8 no dev - ignored input: name = input9, path = /devices/platform/i8042/serio1/input/input9 no dev - ignored input: name = mouse0, path = /devices/platform/i8042/serio1/input/input9/mouse0 dev = 13:32 input device: bus = serio, bus_id = serio1 driver = psmouse path = /devices/platform/i8042/serio1 input: name = input10, path = /devices/pci0000:00/0000:00:1b.0/sound/card0/input10 no dev - ignored input: name = input11, path = /devices/pci0000:00/0000:00:1b.0/sound/card0/input11 no dev - ignored input: name = input12, path = /devices/pci0000:00/0000:00:1b.0/sound/card0/input12 no dev - ignored input: name = input13, path = /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5/3-1.5:1.0/input/input13 no dev - ignored input: name = input14, path = /devices/virtual/input/input14 no dev - ignored >> usb.3.4: lp sysfs: no such class: usb >> usb.3.5: serial >> edd.1: edd mod ----- exec: "/sbin/modprobe edd " ----- modprobe: ERROR: could not insert 'edd': Operation not permitted ----- return code: ? ----- >> edd.2: edd info >> modem.1: serial ****** started child process 10932 (15s/120s) ****** ****** stopped child process 10932 (120s) ****** >> mouse.2: serial ****** started child process 10933 (20s/20s) ****** ****** stopped child process 10933 (20s) ****** >> input.1: joydev mod >> input.1.1: evdev mod >> input.2: input ----- /proc/bus/input/devices ----- I: Bus=0019 Vendor=0000 Product=0001 Version=0000 N: Name="Power Button" P: Phys=PNP0C0C/button/input0 S: Sysfs=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0 U: Uniq= H: Handlers=kbd event0 B: PROP=0 B: EV=3 B: KEY=10000000000000 0 I: Bus=0019 Vendor=0000 Product=0003 Version=0000 N: Name="Sleep Button" P: Phys=PNP0C0E/button/input0 S: Sysfs=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input1 U: Uniq= H: Handlers=kbd event1 B: PROP=0 B: EV=3 B: KEY=4000 0 0 I: Bus=0019 Vendor=0000 Product=0005 Version=0000 N: Name="Lid Switch" P: Phys=PNP0C0D/button/input0 S: Sysfs=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/input/input2 U: Uniq= H: Handlers=event2 B: PROP=0 B: EV=21 B: SW=1 I: Bus=0019 Vendor=0000 Product=0001 Version=0000 N: Name="Power Button" P: Phys=LNXPWRBN/button/input0 S: Sysfs=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input3 U: Uniq= H: Handlers=kbd event3 B: PROP=0 B: EV=3 B: KEY=10000000000000 0 I: Bus=0019 Vendor=0000 Product=0006 Version=0000 N: Name="Video Bus" P: Phys=LNXVIDEO/video/input0 S: Sysfs=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input4 U: Uniq= H: Handlers=kbd event4 B: PROP=0 B: EV=3 B: KEY=3e000b00000000 0 0 0 I: Bus=0011 Vendor=0001 Product=0001 Version=ab83 N: Name="AT Translated Set 2 keyboard" P: Phys=isa0060/serio0/input0 S: Sysfs=/devices/platform/i8042/serio0/input/input5 U: Uniq= H: Handlers=sysrq kbd event5 B: PROP=0 B: EV=120013 B: KEY=1100f02902000 8380307cf910f001 feffffdfffefffff fffffffffffffffe B: MSC=10 B: LED=7 I: Bus=0010 Vendor=001f Product=0001 Version=0100 N: Name="PC Speaker" P: Phys=isa0061/input0 S: Sysfs=/devices/platform/pcspkr/input/input7 U: Uniq= H: Handlers=kbd event6 B: PROP=0 B: EV=40001 B: SND=6 I: Bus=0001 Vendor=10ec Product=0275 Version=0001 N: Name="HDA Digital PCBeep" P: Phys=card0/codec#0/beep0 S: Sysfs=/devices/pci0000:00/0000:00:1b.0/sound/card0/hdaudioC0D0/input8 U: Uniq= H: Handlers=kbd event7 B: PROP=0 B: EV=40001 B: SND=6 I: Bus=0000 Vendor=0000 Product=0000 Version=0000 N: Name="HDA Intel PCH Mic" P: Phys=ALSA S: Sysfs=/devices/pci0000:00/0000:00:1b.0/sound/card0/input10 U: Uniq= H: Handlers=event8 B: PROP=0 B: EV=21 B: SW=10 I: Bus=0000 Vendor=0000 Product=0000 Version=0000 N: Name="HDA Intel PCH Front Headphone" P: Phys=ALSA S: Sysfs=/devices/pci0000:00/0000:00:1b.0/sound/card0/input11 U: Uniq= H: Handlers=event9 B: PROP=0 B: EV=21 B: SW=4 I: Bus=0000 Vendor=0000 Product=0000 Version=0000 N: Name="HDA Intel PCH HDMI/DP,pcm=3" P: Phys=ALSA S: Sysfs=/devices/pci0000:00/0000:00:1b.0/sound/card0/input12 U: Uniq= H: Handlers=event10 B: PROP=0 B: EV=21 B: SW=140 I: Bus=0003 Vendor=1bcf Product=288f Version=2710 N: Name="Laptop_Integrated_Webcam_1.3M" P: Phys=usb-0000:00:1a.0-1.5/button S: Sysfs=/devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5/3-1.5:1.0/input/input13 U: Uniq= H: Handlers=kbd event11 B: PROP=0 B: EV=3 B: KEY=100000 0 0 0 I: Bus=0019 Vendor=0000 Product=0000 Version=0000 N: Name="Dell WMI hotkeys" P: Phys=wmi/input0 S: Sysfs=/devices/virtual/input/input14 U: Uniq= H: Handlers=kbd event12 rfkill B: PROP=0 B: EV=13 B: KEY=1500b00000000 200300000 0 0 B: MSC=10 I: Bus=0011 Vendor=0002 Product=0011 Version=0001 N: Name="CyPS/2 Cypress Trackpad" P: Phys=isa0060/serio1/input0 S: Sysfs=/devices/platform/i8042/serio1/input/input9 U: Uniq= H: Handlers=event13 mouse0 B: PROP=9 B: EV=b B: KEY=e520 70000 0 0 0 0 B: ABS=660800011000003 ----- /proc/bus/input/devices end ----- bus = 25, name = Power Button handlers = kbd event0 key = 00100000000000000000000000000000 mouse buttons = 0 mouse wheels = 0 is_mouse = 0 is_joystick = 0 unknown non-USB input device bus = 25, name = Sleep Button handlers = kbd event1 key = 000000000000400000000000000000000000000000000000 mouse buttons = 0 mouse wheels = 0 is_mouse = 0 is_joystick = 0 unknown non-USB input device bus = 25, name = Lid Switch handlers = event2 mouse buttons = 0 mouse wheels = 0 is_mouse = 0 is_joystick = 0 unknown non-USB input device bus = 25, name = Power Button handlers = kbd event3 key = 00100000000000000000000000000000 mouse buttons = 0 mouse wheels = 0 is_mouse = 0 is_joystick = 0 unknown non-USB input device bus = 25, name = Video Bus handlers = kbd event4 key = 003e000b00000000000000000000000000000000000000000000000000000000 mouse buttons = 0 mouse wheels = 0 is_mouse = 0 is_joystick = 0 unknown non-USB input device bus = 17, name = AT Translated Set 2 keyboard handlers = sysrq kbd event5 key = 0001100f029020008380307cf910f001feffffdfffeffffffffffffffffffffe mouse buttons = 0 mouse wheels = 0 is_mouse = 0 is_joystick = 0 bus = 16, name = PC Speaker handlers = kbd event6 mouse buttons = 0 mouse wheels = 0 is_mouse = 0 is_joystick = 0 unknown non-USB input device bus = 1, name = HDA Digital PCBeep handlers = kbd event7 mouse buttons = 0 mouse wheels = 0 is_mouse = 0 is_joystick = 0 unknown non-USB input device bus = 0, name = HDA Intel PCH Mic handlers = event8 mouse buttons = 0 mouse wheels = 0 is_mouse = 0 is_joystick = 0 unknown non-USB input device bus = 0, name = HDA Intel PCH Front Headphone handlers = event9 mouse buttons = 0 mouse wheels = 0 is_mouse = 0 is_joystick = 0 unknown non-USB input device bus = 0, name = HDA Intel PCH HDMI/DP,pcm=3 handlers = event10 mouse buttons = 0 mouse wheels = 0 is_mouse = 0 is_joystick = 0 unknown non-USB input device bus = 3, name = Laptop_Integrated_Webcam_1.3M handlers = kbd event11 key = 0000000000100000000000000000000000000000000000000000000000000000 mouse buttons = 0 mouse wheels = 0 is_mouse = 0 is_joystick = 0 bus = 25, name = Dell WMI hotkeys handlers = kbd event12 rfkill key = 0001500b00000000000000020030000000000000000000000000000000000000 mouse buttons = 0 mouse wheels = 0 is_mouse = 0 is_joystick = 0 unknown non-USB input device bus = 17, name = CyPS/2 Cypress Trackpad handlers = event13 mouse0 key = 000000000000e52000000000000700000000000000000000000000000000000000000000000000000000000000000000 abs = 0660800011000003 mouse buttons = 3 mouse wheels = 0 is_mouse = 1 is_joystick = 0 >> kbd.2: uml >> cpu.1: cpuinfo ----- /proc/cpuinfo ----- processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 58 model name : Intel(R) Core(TM) i7-3537U CPU @ 2.00GHz stepping : 9 microcode : 0x1b cpu MHz : 2987.402 cache size : 4096 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt bugs : bogomips : 4990.52 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 58 model name : Intel(R) Core(TM) i7-3537U CPU @ 2.00GHz stepping : 9 microcode : 0x1b cpu MHz : 2979.394 cache size : 4096 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 2 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt bugs : bogomips : 4990.52 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 2 vendor_id : GenuineIntel cpu family : 6 model : 58 model name : Intel(R) Core(TM) i7-3537U CPU @ 2.00GHz stepping : 9 microcode : 0x1b cpu MHz : 3079.003 cache size : 4096 KB physical id : 0 siblings : 4 core id : 1 cpu cores : 2 apicid : 2 initial apicid : 2 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt bugs : bogomips : 4990.52 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 58 model name : Intel(R) Core(TM) i7-3537U CPU @ 2.00GHz stepping : 9 microcode : 0x1b cpu MHz : 2919.335 cache size : 4096 KB physical id : 0 siblings : 4 core id : 1 cpu cores : 2 apicid : 3 initial apicid : 3 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt bugs : bogomips : 4990.52 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: ----- /proc/cpuinfo end ----- >> kbd.3: serial console >> fb.1: read info >> net.1: get network data net interface: name = lo, path = /class/net/lo type = 772 carrier = 1 hw_addr = 00:00:00:00:00:00 GDRVINFO ethtool error: Operation not supported ethtool private flags: 0 net interface: name = wlp1s0, path = /class/net/wlp1s0 type = 1 carrier = 1 hw_addr = f8:16:54:f8:24:e2 net device: path = /devices/pci0000:00/0000:00:1c.0/0000:01:00.0 net driver: name = iwlwifi, path = /bus/pci/drivers/iwlwifi ethtool private flags: 0 >> pppoe.1: looking for pppoe >> pppoe.2: discovery wlp1s0: socket failed: Operation not permitted >> wlan.1: detecting wlan features *** device wlp1s0 is wireless *** >> isdn.1: list >> dsl.1: list >> int.2: cdrom >> int.3: media >> int.4.1: /dev/sda read_block0: open(/dev/sda) failed >> int.4: floppy >> int.5: edd >> int.5.1: bios bios ctrl 0: 22 >> int.6: mouse >> int.15: system info system type: notebook acpi: 1 >> int.7: hdb >> int.7.1: modules >> int.8: usbscsi >> int.9: hotplug >> int.10: modem >> int.11: wlan >> int.12: udev ----- udevinfo ----- P: /devices/LNXSYSTM:00 E: DEVPATH=/devices/LNXSYSTM:00 E: MODALIAS=acpi:LNXSYSTM: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXCPU:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:00 E: MODALIAS=acpi:LNXCPU: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXCPU:01 E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:01 E: MODALIAS=acpi:LNXCPU: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXCPU:02 E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:02 E: MODALIAS=acpi:LNXCPU: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXCPU:03 E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:03 E: MODALIAS=acpi:LNXCPU: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXCPU:04 E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:04 E: MODALIAS=acpi:LNXCPU: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXCPU:05 E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:05 E: MODALIAS=acpi:LNXCPU: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXCPU:06 E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:06 E: MODALIAS=acpi:LNXCPU: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXCPU:07 E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:07 E: MODALIAS=acpi:LNXCPU: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXPWRBN:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00 E: DRIVER=button E: MODALIAS=acpi:LNXPWRBN: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input3 E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input3 E: EV=3 E: ID_FOR_SEAT=input-acpi-LNXPWRBN_00 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-LNXPWRBN:00 E: ID_PATH_TAG=acpi-LNXPWRBN_00 E: KEY=10000000000000 0 E: MODALIAS=input:b0019v0000p0001e0000-e0,1,k74,ramlsfw E: NAME="Power Button" E: PHYS="LNXPWRBN/button/input0" E: PRODUCT=19/0/1/0 E: PROP=0 E: SUBSYSTEM=input E: TAGS=:seat: E: USEC_INITIALIZED=83532 P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input3/event3 N: input/event3 E: DEVNAME=/dev/input/event3 E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input3/event3 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-LNXPWRBN:00 E: ID_PATH_TAG=acpi-LNXPWRBN_00 E: MAJOR=13 E: MINOR=67 E: SUBSYSTEM=input E: TAGS=:power-switch: E: USEC_INITIALIZED=75574 P: /devices/LNXSYSTM:00/LNXSYBUS:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00 E: MODALIAS=acpi:LNXSYBUS: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00 E: DRIVER=ac E: MODALIAS=acpi:ACPI0003: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ADP0 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ADP0 E: POWER_SUPPLY_NAME=ADP0 E: POWER_SUPPLY_ONLINE=0 E: SUBSYSTEM=power_supply P: /devices/LNXSYSTM:00/LNXSYBUS:00/INT33A0:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/INT33A0:00 E: DRIVER=intel_smart_connect E: ID_VENDOR_FROM_DATABASE=Interphase Corporation E: MODALIAS=acpi:INT33A0: E: SUBSYSTEM=acpi E: USEC_INITIALIZED=83555 P: /devices/LNXSYSTM:00/LNXSYBUS:00/INT340E:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/INT340E:00 E: ID_VENDOR_FROM_DATABASE=Interphase Corporation E: MODALIAS=acpi:INT340E:PNP0C02: E: SUBSYSTEM=acpi E: USEC_INITIALIZED=83563 P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00 E: MODALIAS=acpi:PNP0A08:PNP0A03: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00 E: DRIVER=video E: MODALIAS=acpi:LNXVIDEO: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/device:2c E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/device:2c E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/device:2d E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/device:2d E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/device:2e E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/device:2e E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/device:2f E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/device:2f E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/device:30 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/device:30 E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/device:31 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/device:31 E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/device:32 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/device:32 E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/device:33 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/device:33 E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input4 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input4 E: EV=3 E: ID_FOR_SEAT=input-acpi-LNXVIDEO_00 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-LNXVIDEO:00 E: ID_PATH_TAG=acpi-LNXVIDEO_00 E: KEY=3e000b00000000 0 0 0 E: MODALIAS=input:b0019v0000p0006e0000-e0,1,kE0,E1,E3,F1,F2,F3,F4,F5,ramlsfw E: NAME="Video Bus" E: PHYS="LNXVIDEO/video/input0" E: PRODUCT=19/0/6/0 E: PROP=0 E: SUBSYSTEM=input E: TAGS=:seat: E: USEC_INITIALIZED=83643 P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input4/event4 N: input/event4 E: DEVNAME=/dev/input/event4 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input4/event4 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-LNXVIDEO:00 E: ID_PATH_TAG=acpi-LNXVIDEO_00 E: MAJOR=13 E: MINOR=68 E: SUBSYSTEM=input E: TAGS=:power-switch: E: USEC_INITIALIZED=75700 P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/PNP0C02:01 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/PNP0C02:01 E: MODALIAS=acpi:PNP0C02: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00 E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01 E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/ATM1200:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/ATM1200:00 E: ID_VENDOR_FROM_DATABASE=ATM Ltd E: MODALIAS=acpi:ATM1200:PNP0C31: E: SUBSYSTEM=acpi E: USEC_INITIALIZED=83672 P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/DLL058B:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/DLL058B:00 E: ID_VENDOR_FROM_DATABASE=Dell Inc E: MODALIAS=acpi:DLL058B:PNP0F13: E: SUBSYSTEM=acpi E: USEC_INITIALIZED=83680 P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/INT3F0D:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/INT3F0D:00 E: ID_VENDOR_FROM_DATABASE=Interphase Corporation E: MODALIAS=acpi:INT3F0D:PNP0C02: E: SUBSYSTEM=acpi E: USEC_INITIALIZED=83688 P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/MSFT0001:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/MSFT0001:00 E: ID_VENDOR_FROM_DATABASE=M-Systems Flash Disk Pioneers E: MODALIAS=acpi:MSFT0001:PNP0303: E: SUBSYSTEM=acpi E: USEC_INITIALIZED=83695 P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0000:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0000:00 E: MODALIAS=acpi:PNP0000: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0100:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0100:00 E: MODALIAS=acpi:PNP0100: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0103:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0103:00 E: MODALIAS=acpi:PNP0103: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0200:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0200:00 E: MODALIAS=acpi:PNP0200: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0B00:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0B00:00 E: MODALIAS=acpi:PNP0B00: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0C02:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0C02:00 E: MODALIAS=acpi:PNP0C02: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0C04:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0C04:00 E: MODALIAS=acpi:PNP0C04: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0C09:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0C09:00 E: DRIVER=ec E: MODALIAS=acpi:PNP0C09: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0C09:00/ACPI0008:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0C09:00/ACPI0008:00 E: MODALIAS=acpi:ACPI0008: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0C31:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0C31:00 E: MODALIAS=acpi:PNP0C31:ZIC0101: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0C32:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0C32:00 E: MODALIAS=acpi:PNP0C32: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02 E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02/device:03 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02/device:03 E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02/device:03/device:04 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02/device:03/device:04 E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02/device:03/device:04/device:05 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02/device:03/device:04/device:05 E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02/device:03/device:04/device:06 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02/device:03/device:04/device:06 E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02/device:03/device:04/device:07 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02/device:03/device:04/device:07 E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02/device:03/device:04/device:08 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02/device:03/device:04/device:08 E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02/device:03/device:04/device:09 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02/device:03/device:04/device:09 E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02/device:03/device:04/device:0a E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02/device:03/device:04/device:0a E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02/device:03/device:04/device:0b E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02/device:03/device:04/device:0b E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02/device:03/device:04/device:0c E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02/device:03/device:04/device:0c E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0d E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0d E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0d/device:0e E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0d/device:0e E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0d/device:0e/device:0f E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0d/device:0e/device:0f E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0d/device:0e/device:0f/device:10 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0d/device:0e/device:0f/device:10 E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0d/device:0e/device:0f/device:11 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0d/device:0e/device:0f/device:11 E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0d/device:0e/device:0f/device:12 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0d/device:0e/device:0f/device:12 E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0d/device:0e/device:0f/device:13 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0d/device:0e/device:0f/device:13 E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0d/device:0e/device:0f/device:14 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0d/device:0e/device:0f/device:14 E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0d/device:0e/device:0f/device:14/device:15 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0d/device:0e/device:0f/device:14/device:15 E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0d/device:0e/device:0f/device:16 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0d/device:0e/device:0f/device:16 E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:17 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:17 E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:17/device:18 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:17/device:18 E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:17/device:18/device:19 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:17/device:18/device:19 E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:17/device:18/device:1a E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:17/device:18/device:1a E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:17/device:18/device:1b E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:17/device:18/device:1b E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:17/device:18/device:1c E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:17/device:18/device:1c E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:17/device:18/device:1d E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:17/device:18/device:1d E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:17/device:18/device:1e E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:17/device:18/device:1e E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:17/device:18/device:1f E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:17/device:18/device:1f E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:17/device:18/device:20 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:17/device:18/device:20 E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:21 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:21 E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:22 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:22 E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:22/device:23 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:22/device:23 E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:24 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:24 E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:24/device:25 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:24/device:25 E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:24/device:26 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:24/device:26 E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:27 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:27 E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:27/device:28 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:27/device:28 E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:27/device:29 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:27/device:29 E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:2a E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:2a E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:2b E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:2b E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C01:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C01:00 E: MODALIAS=acpi:PNP0C01: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00 E: DRIVER=battery E: MODALIAS=acpi:PNP0C0A: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0 E: POWER_SUPPLY_CAPACITY=61 E: POWER_SUPPLY_CAPACITY_LEVEL=Normal E: POWER_SUPPLY_CHARGE_FULL=5587000 E: POWER_SUPPLY_CHARGE_FULL_DESIGN=6390000 E: POWER_SUPPLY_CHARGE_NOW=3459000 E: POWER_SUPPLY_CURRENT_NOW=1533000 E: POWER_SUPPLY_CYCLE_COUNT=0 E: POWER_SUPPLY_MANUFACTURER=SIMPLO E: POWER_SUPPLY_MODEL_NAME=Dell E: POWER_SUPPLY_NAME=BAT0 E: POWER_SUPPLY_PRESENT=1 E: POWER_SUPPLY_SERIAL_NUMBER=785 E: POWER_SUPPLY_STATUS=Discharging E: POWER_SUPPLY_TECHNOLOGY=Li-ion E: POWER_SUPPLY_VOLTAGE_MIN_DESIGN=7400000 E: POWER_SUPPLY_VOLTAGE_NOW=7668000 E: SUBSYSTEM=power_supply P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00 E: DRIVER=button E: MODALIAS=acpi:PNP0C0C: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0 E: EV=3 E: ID_FOR_SEAT=input-acpi-PNP0C0C_00 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-PNP0C0C:00 E: ID_PATH_TAG=acpi-PNP0C0C_00 E: KEY=10000000000000 0 E: MODALIAS=input:b0019v0000p0001e0000-e0,1,k74,ramlsfw E: NAME="Power Button" E: PHYS="PNP0C0C/button/input0" E: PRODUCT=19/0/1/0 E: PROP=0 E: SUBSYSTEM=input E: TAGS=:seat: E: USEC_INITIALIZED=84178 P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0/event0 N: input/event0 E: DEVNAME=/dev/input/event0 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0/event0 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-PNP0C0C:00 E: ID_PATH_TAG=acpi-PNP0C0C_00 E: MAJOR=13 E: MINOR=64 E: SUBSYSTEM=input E: TAGS=:power-switch: E: USEC_INITIALIZED=75223 P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00 E: DRIVER=button E: MODALIAS=acpi:PNP0C0D: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/input/input2 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/input/input2 E: EV=21 E: ID_FOR_SEAT=input-acpi-PNP0C0D_00 E: ID_INPUT=1 E: ID_PATH=acpi-PNP0C0D:00 E: ID_PATH_TAG=acpi-PNP0C0D_00 E: MODALIAS=input:b0019v0000p0005e0000-e0,5,kramlsfw0, E: NAME="Lid Switch" E: PHYS="PNP0C0D/button/input0" E: PRODUCT=19/0/5/0 E: PROP=0 E: SUBSYSTEM=input E: SW=1 E: TAGS=:seat: E: USEC_INITIALIZED=84204 P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/input/input2/event2 N: input/event2 E: DEVNAME=/dev/input/event2 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/input/input2/event2 E: ID_INPUT=1 E: ID_PATH=acpi-PNP0C0D:00 E: ID_PATH_TAG=acpi-PNP0C0D_00 E: MAJOR=13 E: MINOR=66 E: SUBSYSTEM=input E: TAGS=:power-switch: E: USEC_INITIALIZED=75445 P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00 E: DRIVER=button E: MODALIAS=acpi:PNP0C0E: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input1 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input1 E: EV=3 E: ID_FOR_SEAT=input-acpi-PNP0C0E_00 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-PNP0C0E:00 E: ID_PATH_TAG=acpi-PNP0C0E_00 E: KEY=4000 0 0 E: MODALIAS=input:b0019v0000p0003e0000-e0,1,k8E,ramlsfw E: NAME="Sleep Button" E: PHYS="PNP0C0E/button/input0" E: PRODUCT=19/0/3/0 E: PROP=0 E: SUBSYSTEM=input E: TAGS=:seat: E: USEC_INITIALIZED=84228 P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input1/event1 N: input/event1 E: DEVNAME=/dev/input/event1 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input1/event1 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-PNP0C0E:00 E: ID_PATH_TAG=acpi-PNP0C0E_00 E: MAJOR=13 E: MINOR=65 E: SUBSYSTEM=input E: TAGS=:power-switch: E: USEC_INITIALIZED=75318 P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:00 E: MODALIAS=acpi:PNP0C0F: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:01 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:01 E: MODALIAS=acpi:PNP0C0F: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:02 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:02 E: MODALIAS=acpi:PNP0C0F: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:03 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:03 E: MODALIAS=acpi:PNP0C0F: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:04 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:04 E: MODALIAS=acpi:PNP0C0F: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:05 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:05 E: MODALIAS=acpi:PNP0C0F: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:06 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:06 E: MODALIAS=acpi:PNP0C0F: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:07 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:07 E: MODALIAS=acpi:PNP0C0F: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C14:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C14:00 E: DRIVER=wmi E: MODALIAS=acpi:PNP0C14: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:01 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:01 E: MODALIAS=acpi:LNXSYBUS: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:01/LNXTHERM:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:01/LNXTHERM:00 E: DRIVER=thermal E: MODALIAS=acpi:LNXTHERM: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:01/LNXTHERM:01 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:01/LNXTHERM:01 E: DRIVER=thermal E: MODALIAS=acpi:LNXTHERM: E: SUBSYSTEM=acpi P: /devices/breakpoint E: DEVPATH=/devices/breakpoint E: SUBSYSTEM=event_source P: /devices/cpu E: DEVPATH=/devices/cpu E: SUBSYSTEM=event_source P: /devices/pci0000:00/0000:00:00.0 E: DEVPATH=/devices/pci0000:00/0000:00:00.0 E: DRIVER=ivb_uncore E: ID_MODEL_FROM_DATABASE=3rd Gen Core processor DRAM Controller E: ID_PCI_CLASS_FROM_DATABASE=Bridge E: ID_PCI_SUBCLASS_FROM_DATABASE=Host bridge E: ID_VENDOR_FROM_DATABASE=Intel Corporation E: MODALIAS=pci:v00008086d00000154sv00001028sd0000058Bbc06sc00i00 E: PCI_CLASS=60000 E: PCI_ID=8086:0154 E: PCI_SLOT_NAME=0000:00:00.0 E: PCI_SUBSYS_ID=1028:058B E: SUBSYSTEM=pci E: USEC_INITIALIZED=84507 P: /devices/pci0000:00/0000:00:02.0 E: DEVPATH=/devices/pci0000:00/0000:00:02.0 E: DRIVER=i915 E: ID_MODEL_FROM_DATABASE=3rd Gen Core processor Graphics Controller E: ID_PCI_CLASS_FROM_DATABASE=Display controller E: ID_PCI_INTERFACE_FROM_DATABASE=VGA controller E: ID_PCI_SUBCLASS_FROM_DATABASE=VGA compatible controller E: ID_VENDOR_FROM_DATABASE=Intel Corporation E: MODALIAS=pci:v00008086d00000166sv00001028sd0000058Bbc03sc00i00 E: PCI_CLASS=30000 E: PCI_ID=8086:0166 E: PCI_SLOT_NAME=0000:00:02.0 E: PCI_SUBSYS_ID=1028:058B E: SUBSYSTEM=pci E: USEC_INITIALIZED=84576 P: /devices/pci0000:00/0000:00:02.0/drm/card0 N: dri/card0 E: DEVNAME=/dev/dri/card0 E: DEVPATH=/devices/pci0000:00/0000:00:02.0/drm/card0 E: DEVTYPE=drm_minor E: ID_FOR_SEAT=drm-pci-0000_00_02_0 E: ID_PATH=pci-0000:00:02.0 E: ID_PATH_TAG=pci-0000_00_02_0 E: MAJOR=226 E: MINOR=0 E: SUBSYSTEM=drm E: TAGS=:seat:uaccess: E: USEC_INITIALIZED=84631 P: /devices/pci0000:00/0000:00:02.0/drm/card0/card0-DP-1 E: DEVPATH=/devices/pci0000:00/0000:00:02.0/drm/card0/card0-DP-1 E: ID_PATH=pci-0000:00:02.0 E: ID_PATH_TAG=pci-0000_00_02_0 E: SUBSYSTEM=drm E: USEC_INITIALIZED=84648 P: /devices/pci0000:00/0000:00:02.0/drm/card0/card0-HDMI-A-1 E: DEVPATH=/devices/pci0000:00/0000:00:02.0/drm/card0/card0-HDMI-A-1 E: ID_PATH=pci-0000:00:02.0 E: ID_PATH_TAG=pci-0000_00_02_0 E: SUBSYSTEM=drm E: USEC_INITIALIZED=84663 P: /devices/pci0000:00/0000:00:02.0/drm/card0/card0-VGA-1 E: DEVPATH=/devices/pci0000:00/0000:00:02.0/drm/card0/card0-VGA-1 E: ID_PATH=pci-0000:00:02.0 E: ID_PATH_TAG=pci-0000_00_02_0 E: SUBSYSTEM=drm E: USEC_INITIALIZED=84679 P: /devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1 E: DEVPATH=/devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1 E: ID_PATH=pci-0000:00:02.0 E: ID_PATH_TAG=pci-0000_00_02_0 E: SUBSYSTEM=drm E: USEC_INITIALIZED=84693 P: /devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/intel_backlight E: DEVPATH=/devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/intel_backlight E: ID_PATH=pci-0000:00:02.0 E: ID_PATH_TAG=pci-0000_00_02_0 E: SUBSYSTEM=backlight E: SYSTEMD_WANTS=systemd-backlight at backlight:intel_backlight.service E: TAGS=:systemd: E: USEC_INITIALIZED=84712 P: /devices/pci0000:00/0000:00:02.0/drm/controlD64 N: dri/controlD64 E: DEVNAME=/dev/dri/controlD64 E: DEVPATH=/devices/pci0000:00/0000:00:02.0/drm/controlD64 E: DEVTYPE=drm_minor E: ID_PATH=pci-0000:00:02.0 E: ID_PATH_TAG=pci-0000_00_02_0 E: MAJOR=226 E: MINOR=64 E: SUBSYSTEM=drm E: USEC_INITIALIZED=84733 P: /devices/pci0000:00/0000:00:02.0/drm/renderD128 N: dri/renderD128 E: DEVNAME=/dev/dri/renderD128 E: DEVPATH=/devices/pci0000:00/0000:00:02.0/drm/renderD128 E: DEVTYPE=drm_minor E: ID_FOR_SEAT=drm-pci-0000_00_02_0 E: ID_PATH=pci-0000:00:02.0 E: ID_PATH_TAG=pci-0000_00_02_0 E: MAJOR=226 E: MINOR=128 E: SUBSYSTEM=drm E: TAGS=:seat:uaccess: E: USEC_INITIALIZED=84757 P: /devices/pci0000:00/0000:00:02.0/graphics/fb0 N: fb0 E: DEVNAME=/dev/fb0 E: DEVPATH=/devices/pci0000:00/0000:00:02.0/graphics/fb0 E: ID_FOR_SEAT=graphics-pci-0000_00_02_0 E: ID_PATH=pci-0000:00:02.0 E: ID_PATH_TAG=pci-0000_00_02_0 E: MAJOR=29 E: MINOR=0 E: SUBSYSTEM=graphics E: TAGS=:master-of-seat:seat: E: USEC_INITIALIZED=84781 P: /devices/pci0000:00/0000:00:02.0/i2c-0 E: DEVPATH=/devices/pci0000:00/0000:00:02.0/i2c-0 E: SUBSYSTEM=i2c P: /devices/pci0000:00/0000:00:02.0/i2c-1 E: DEVPATH=/devices/pci0000:00/0000:00:02.0/i2c-1 E: SUBSYSTEM=i2c P: /devices/pci0000:00/0000:00:02.0/i2c-2 E: DEVPATH=/devices/pci0000:00/0000:00:02.0/i2c-2 E: SUBSYSTEM=i2c P: /devices/pci0000:00/0000:00:02.0/i2c-3 E: DEVPATH=/devices/pci0000:00/0000:00:02.0/i2c-3 E: SUBSYSTEM=i2c P: /devices/pci0000:00/0000:00:02.0/i2c-4 E: DEVPATH=/devices/pci0000:00/0000:00:02.0/i2c-4 E: SUBSYSTEM=i2c P: /devices/pci0000:00/0000:00:02.0/i2c-5 E: DEVPATH=/devices/pci0000:00/0000:00:02.0/i2c-5 E: SUBSYSTEM=i2c P: /devices/pci0000:00/0000:00:02.0/i2c-6 E: DEVPATH=/devices/pci0000:00/0000:00:02.0/i2c-6 E: SUBSYSTEM=i2c P: /devices/pci0000:00/0000:00:02.0/i2c-7 E: DEVPATH=/devices/pci0000:00/0000:00:02.0/i2c-7 E: SUBSYSTEM=i2c P: /devices/pci0000:00/0000:00:14.0 E: DEVPATH=/devices/pci0000:00/0000:00:14.0 E: DRIVER=xhci_hcd E: ID_MODEL_FROM_DATABASE=7 Series/C210 Series Chipset Family USB xHCI Host Controller E: ID_PCI_CLASS_FROM_DATABASE=Serial bus controller E: ID_PCI_INTERFACE_FROM_DATABASE=XHCI E: ID_PCI_SUBCLASS_FROM_DATABASE=USB controller E: ID_VENDOR_FROM_DATABASE=Intel Corporation E: MODALIAS=pci:v00008086d00001E31sv00001028sd0000058Bbc0Csc03i30 E: PCI_CLASS=C0330 E: PCI_ID=8086:1E31 E: PCI_SLOT_NAME=0000:00:14.0 E: PCI_SUBSYS_ID=1028:058B E: SUBSYSTEM=pci E: USEC_INITIALIZED=84939 P: /devices/pci0000:00/0000:00:14.0/usb1 N: bus/usb/001/001 E: BUSNUM=001 E: DEVNAME=/dev/bus/usb/001/001 E: DEVNUM=001 E: DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1 E: DEVTYPE=usb_device E: DRIVER=usb E: ID_BUS=usb E: ID_FOR_SEAT=usb-pci-0000_00_14_0 E: ID_MODEL=xHCI_Host_Controller E: ID_MODEL_ENC=xHCI\x20Host\x20Controller E: ID_MODEL_FROM_DATABASE=2.0 root hub E: ID_MODEL_ID=0002 E: ID_PATH=pci-0000:00:14.0 E: ID_PATH_TAG=pci-0000_00_14_0 E: ID_REVISION=0318 E: ID_SERIAL=Linux_3.18.6-1-ARCH_xhci-hcd_xHCI_Host_Controller_0000:00:14.0 E: ID_SERIAL_SHORT=0000:00:14.0 E: ID_USB_INTERFACES=:090000: E: ID_VENDOR=Linux_3.18.6-1-ARCH_xhci-hcd E: ID_VENDOR_ENC=Linux\x203.18.6-1-ARCH\x20xhci-hcd E: ID_VENDOR_FROM_DATABASE=Linux Foundation E: ID_VENDOR_ID=1d6b E: MAJOR=189 E: MINOR=0 E: PRODUCT=1d6b/2/318 E: SUBSYSTEM=usb E: TAGS=:seat: E: TYPE=9/0/1 E: USEC_INITIALIZED=84995 P: /devices/pci0000:00/0000:00:14.0/usb1/1-0:1.0 E: DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-0:1.0 E: DEVTYPE=usb_interface E: DRIVER=hub E: ID_MODEL_FROM_DATABASE=2.0 root hub E: ID_USB_CLASS_FROM_DATABASE=Hub E: ID_USB_PROTOCOL_FROM_DATABASE=Single TT E: ID_VENDOR_FROM_DATABASE=Linux Foundation E: INTERFACE=9/0/0 E: MODALIAS=usb:v1D6Bp0002d0318dc09dsc00dp01ic09isc00ip00in00 E: PRODUCT=1d6b/2/318 E: SUBSYSTEM=usb E: TYPE=9/0/1 E: USEC_INITIALIZED=85031 P: /devices/pci0000:00/0000:00:14.0/usb2 N: bus/usb/002/001 E: BUSNUM=002 E: DEVNAME=/dev/bus/usb/002/001 E: DEVNUM=001 E: DEVPATH=/devices/pci0000:00/0000:00:14.0/usb2 E: DEVTYPE=usb_device E: DRIVER=usb E: ID_BUS=usb E: ID_FOR_SEAT=usb-pci-0000_00_14_0 E: ID_MODEL=xHCI_Host_Controller E: ID_MODEL_ENC=xHCI\x20Host\x20Controller E: ID_MODEL_FROM_DATABASE=3.0 root hub E: ID_MODEL_ID=0003 E: ID_PATH=pci-0000:00:14.0 E: ID_PATH_TAG=pci-0000_00_14_0 E: ID_REVISION=0318 E: ID_SERIAL=Linux_3.18.6-1-ARCH_xhci-hcd_xHCI_Host_Controller_0000:00:14.0 E: ID_SERIAL_SHORT=0000:00:14.0 E: ID_USB_INTERFACES=:090000: E: ID_VENDOR=Linux_3.18.6-1-ARCH_xhci-hcd E: ID_VENDOR_ENC=Linux\x203.18.6-1-ARCH\x20xhci-hcd E: ID_VENDOR_FROM_DATABASE=Linux Foundation E: ID_VENDOR_ID=1d6b E: MAJOR=189 E: MINOR=128 E: PRODUCT=1d6b/3/318 E: SUBSYSTEM=usb E: TAGS=:seat: E: TYPE=9/0/3 E: USEC_INITIALIZED=85065 P: /devices/pci0000:00/0000:00:14.0/usb2/2-0:1.0 E: DEVPATH=/devices/pci0000:00/0000:00:14.0/usb2/2-0:1.0 E: DEVTYPE=usb_interface E: DRIVER=hub E: ID_MODEL_FROM_DATABASE=3.0 root hub E: ID_USB_CLASS_FROM_DATABASE=Hub E: ID_VENDOR_FROM_DATABASE=Linux Foundation E: INTERFACE=9/0/0 E: MODALIAS=usb:v1D6Bp0003d0318dc09dsc00dp03ic09isc00ip00in00 E: PRODUCT=1d6b/3/318 E: SUBSYSTEM=usb E: TYPE=9/0/3 E: USEC_INITIALIZED=85086 P: /devices/pci0000:00/0000:00:16.0 E: DEVPATH=/devices/pci0000:00/0000:00:16.0 E: DRIVER=mei_me E: ID_MODEL_FROM_DATABASE=7 Series/C210 Series Chipset Family MEI Controller E: ID_PCI_CLASS_FROM_DATABASE=Communication controller E: ID_PCI_SUBCLASS_FROM_DATABASE=Communication controller E: ID_VENDOR_FROM_DATABASE=Intel Corporation E: MODALIAS=pci:v00008086d00001E3Asv00001028sd0000058Bbc07sc80i00 E: PCI_CLASS=78000 E: PCI_ID=8086:1E3A E: PCI_SLOT_NAME=0000:00:16.0 E: PCI_SUBSYS_ID=1028:058B E: SUBSYSTEM=pci E: USEC_INITIALIZED=85107 P: /devices/pci0000:00/0000:00:16.0/mei/mei0 N: mei0 E: DEVNAME=/dev/mei0 E: DEVPATH=/devices/pci0000:00/0000:00:16.0/mei/mei0 E: MAJOR=251 E: MINOR=0 E: SUBSYSTEM=mei P: /devices/pci0000:00/0000:00:1a.0 E: DEVPATH=/devices/pci0000:00/0000:00:1a.0 E: DRIVER=ehci-pci E: ID_MODEL_FROM_DATABASE=7 Series/C210 Series Chipset Family USB Enhanced Host Controller E: ID_PCI_CLASS_FROM_DATABASE=Serial bus controller E: ID_PCI_INTERFACE_FROM_DATABASE=EHCI E: ID_PCI_SUBCLASS_FROM_DATABASE=USB controller E: ID_VENDOR_FROM_DATABASE=Intel Corporation E: MODALIAS=pci:v00008086d00001E2Dsv00001028sd0000058Bbc0Csc03i20 E: PCI_CLASS=C0320 E: PCI_ID=8086:1E2D E: PCI_SLOT_NAME=0000:00:1a.0 E: PCI_SUBSYS_ID=1028:058B E: SUBSYSTEM=pci E: USEC_INITIALIZED=85162 P: /devices/pci0000:00/0000:00:1a.0/usb3 N: bus/usb/003/001 E: BUSNUM=003 E: DEVNAME=/dev/bus/usb/003/001 E: DEVNUM=001 E: DEVPATH=/devices/pci0000:00/0000:00:1a.0/usb3 E: DEVTYPE=usb_device E: DRIVER=usb E: ID_BUS=usb E: ID_FOR_SEAT=usb-pci-0000_00_1a_0 E: ID_MODEL=EHCI_Host_Controller E: ID_MODEL_ENC=EHCI\x20Host\x20Controller E: ID_MODEL_FROM_DATABASE=2.0 root hub E: ID_MODEL_ID=0002 E: ID_PATH=pci-0000:00:1a.0 E: ID_PATH_TAG=pci-0000_00_1a_0 E: ID_REVISION=0318 E: ID_SERIAL=Linux_3.18.6-1-ARCH_ehci_hcd_EHCI_Host_Controller_0000:00:1a.0 E: ID_SERIAL_SHORT=0000:00:1a.0 E: ID_USB_INTERFACES=:090000: E: ID_VENDOR=Linux_3.18.6-1-ARCH_ehci_hcd E: ID_VENDOR_ENC=Linux\x203.18.6-1-ARCH\x20ehci_hcd E: ID_VENDOR_FROM_DATABASE=Linux Foundation E: ID_VENDOR_ID=1d6b E: MAJOR=189 E: MINOR=256 E: PRODUCT=1d6b/2/318 E: SUBSYSTEM=usb E: TAGS=:seat: E: TYPE=9/0/0 E: USEC_INITIALIZED=85231 P: /devices/pci0000:00/0000:00:1a.0/usb3/3-0:1.0 E: DEVPATH=/devices/pci0000:00/0000:00:1a.0/usb3/3-0:1.0 E: DEVTYPE=usb_interface E: DRIVER=hub E: ID_MODEL_FROM_DATABASE=2.0 root hub E: ID_USB_CLASS_FROM_DATABASE=Hub E: ID_USB_PROTOCOL_FROM_DATABASE=Full speed (or root) hub E: ID_VENDOR_FROM_DATABASE=Linux Foundation E: INTERFACE=9/0/0 E: MODALIAS=usb:v1D6Bp0002d0318dc09dsc00dp00ic09isc00ip00in00 E: PRODUCT=1d6b/2/318 E: SUBSYSTEM=usb E: TYPE=9/0/0 E: USEC_INITIALIZED=85255 P: /devices/pci0000:00/0000:00:1a.0/usb3/3-1 N: bus/usb/003/002 E: BUSNUM=003 E: DEVNAME=/dev/bus/usb/003/002 E: DEVNUM=002 E: DEVPATH=/devices/pci0000:00/0000:00:1a.0/usb3/3-1 E: DEVTYPE=usb_device E: DRIVER=usb E: ID_BUS=usb E: ID_FOR_SEAT=usb-pci-0000_00_1a_0-usb-0_1 E: ID_MODEL=0024 E: ID_MODEL_ENC=0024 E: ID_MODEL_FROM_DATABASE=Integrated Rate Matching Hub E: ID_MODEL_ID=0024 E: ID_PATH=pci-0000:00:1a.0-usb-0:1 E: ID_PATH_TAG=pci-0000_00_1a_0-usb-0_1 E: ID_REVISION=0000 E: ID_SERIAL=8087_0024 E: ID_USB_INTERFACES=:090000: E: ID_VENDOR=8087 E: ID_VENDOR_ENC=8087 E: ID_VENDOR_FROM_DATABASE=Intel Corp. E: ID_VENDOR_ID=8087 E: MAJOR=189 E: MINOR=257 E: PRODUCT=8087/24/0 E: SUBSYSTEM=usb E: TAGS=:seat: E: TYPE=9/0/1 E: USEC_INITIALIZED=85279 P: /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5 N: bus/usb/003/003 E: BUSNUM=003 E: DEVNAME=/dev/bus/usb/003/003 E: DEVNUM=003 E: DEVPATH=/devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5 E: DEVTYPE=usb_device E: DRIVER=usb E: ID_BUS=usb E: ID_MODEL=Laptop_Integrated_Webcam_1.3M E: ID_MODEL_ENC=Laptop_Integrated_Webcam_1.3M E: ID_MODEL_ID=288f E: ID_REVISION=2710 E: ID_SERIAL=CN01RH717248726AD005A00_Laptop_Integrated_Webcam_1.3M E: ID_USB_INTERFACES=:0e0100:0e0200: E: ID_VENDOR=CN01RH717248726AD005A00 E: ID_VENDOR_ENC=CN01RH717248726AD005A00 E: ID_VENDOR_FROM_DATABASE=Sunplus Innovation Technology Inc. E: ID_VENDOR_ID=1bcf E: MAJOR=189 E: MINOR=258 E: PRODUCT=1bcf/288f/2710 E: SUBSYSTEM=usb E: TYPE=239/2/1 E: USEC_INITIALIZED=72071 P: /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5/3-1.5:1.0 E: DEVPATH=/devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5/3-1.5:1.0 E: DEVTYPE=usb_interface E: DRIVER=uvcvideo E: ID_USB_CLASS_FROM_DATABASE=Miscellaneous Device E: ID_USB_PROTOCOL_FROM_DATABASE=Interface Association E: ID_VENDOR_FROM_DATABASE=Sunplus Innovation Technology Inc. E: INTERFACE=14/1/0 E: MODALIAS=usb:v1BCFp288Fd2710dcEFdsc02dp01ic0Eisc01ip00in00 E: PRODUCT=1bcf/288f/2710 E: SUBSYSTEM=usb E: TYPE=239/2/1 E: USEC_INITIALIZED=72206 P: /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5/3-1.5:1.0/input/input13 E: DEVPATH=/devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5/3-1.5:1.0/input/input13 E: EV=3 E: ID_BUS=usb E: ID_FOR_SEAT=input-pci-0000_00_1a_0-usb-0_1_5_1_0 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_MODEL=Laptop_Integrated_Webcam_1.3M E: ID_MODEL_ENC=Laptop_Integrated_Webcam_1.3M E: ID_MODEL_ID=288f E: ID_PATH=pci-0000:00:1a.0-usb-0:1.5:1.0 E: ID_PATH_TAG=pci-0000_00_1a_0-usb-0_1_5_1_0 E: ID_REVISION=2710 E: ID_SERIAL=CN01RH717248726AD005A00_Laptop_Integrated_Webcam_1.3M E: ID_TYPE=video E: ID_USB_DRIVER=uvcvideo E: ID_USB_INTERFACES=:0e0100:0e0200: E: ID_USB_INTERFACE_NUM=00 E: ID_VENDOR=CN01RH717248726AD005A00 E: ID_VENDOR_ENC=CN01RH717248726AD005A00 E: ID_VENDOR_ID=1bcf E: KEY=100000 0 0 0 E: MODALIAS=input:b0003v1BCFp288Fe2710-e0,1,kD4,ramlsfw E: NAME="Laptop_Integrated_Webcam_1.3M" E: PHYS="usb-0000:00:1a.0-1.5/button" E: PRODUCT=3/1bcf/288f/2710 E: PROP=0 E: SUBSYSTEM=input E: TAGS=:seat: E: USEC_INITIALIZED=4246 P: /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5/3-1.5:1.0/input/input13/event11 N: input/event11 S: input/by-id/usb-CN01RH717248726AD005A00_Laptop_Integrated_Webcam_1.3M-event-if00 S: input/by-path/pci-0000:00:1a.0-usb-0:1.5:1.0-event E: DEVLINKS=/dev/input/by-id/usb-CN01RH717248726AD005A00_Laptop_Integrated_Webcam_1.3M-event-if00 /dev/input/by-path/pci-0000:00:1a.0-usb-0:1.5:1.0-event E: DEVNAME=/dev/input/event11 E: DEVPATH=/devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5/3-1.5:1.0/input/input13/event11 E: ID_BUS=usb E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_MODEL=Laptop_Integrated_Webcam_1.3M E: ID_MODEL_ENC=Laptop_Integrated_Webcam_1.3M E: ID_MODEL_ID=288f E: ID_PATH=pci-0000:00:1a.0-usb-0:1.5:1.0 E: ID_PATH_TAG=pci-0000_00_1a_0-usb-0_1_5_1_0 E: ID_REVISION=2710 E: ID_SERIAL=CN01RH717248726AD005A00_Laptop_Integrated_Webcam_1.3M E: ID_TYPE=video E: ID_USB_DRIVER=uvcvideo E: ID_USB_INTERFACES=:0e0100:0e0200: E: ID_USB_INTERFACE_NUM=00 E: ID_VENDOR=CN01RH717248726AD005A00 E: ID_VENDOR_ENC=CN01RH717248726AD005A00 E: ID_VENDOR_ID=1bcf E: MAJOR=13 E: MINOR=75 E: SUBSYSTEM=input E: USEC_INITIALIZED=4319 P: /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5/3-1.5:1.0/media0 N: media0 E: DEVNAME=/dev/media0 E: DEVPATH=/devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5/3-1.5:1.0/media0 E: MAJOR=250 E: MINOR=0 E: SUBSYSTEM=media P: /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5/3-1.5:1.0/video4linux/video0 N: video0 S: v4l/by-id/usb-CN01RH717248726AD005A00_Laptop_Integrated_Webcam_1.3M-video-index0 S: v4l/by-path/pci-0000:00:1a.0-usb-0:1.5:1.0-video-index0 E: COLORD_DEVICE=1 E: COLORD_KIND=camera E: DEVLINKS=/dev/v4l/by-id/usb-CN01RH717248726AD005A00_Laptop_Integrated_Webcam_1.3M-video-index0 /dev/v4l/by-path/pci-0000:00:1a.0-usb-0:1.5:1.0-video-index0 E: DEVNAME=/dev/video0 E: DEVPATH=/devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5/3-1.5:1.0/video4linux/video0 E: ID_BUS=usb E: ID_FOR_SEAT=video4linux-pci-0000_00_1a_0-usb-0_1_5_1_0 E: ID_MODEL=Laptop_Integrated_Webcam_1.3M E: ID_MODEL_ENC=Laptop_Integrated_Webcam_1.3M E: ID_MODEL_ID=288f E: ID_PATH=pci-0000:00:1a.0-usb-0:1.5:1.0 E: ID_PATH_TAG=pci-0000_00_1a_0-usb-0_1_5_1_0 E: ID_REVISION=2710 E: ID_SERIAL=CN01RH717248726AD005A00_Laptop_Integrated_Webcam_1.3M E: ID_TYPE=video E: ID_USB_DRIVER=uvcvideo E: ID_USB_INTERFACES=:0e0100:0e0200: E: ID_USB_INTERFACE_NUM=00 E: ID_V4L_CAPABILITIES=:capture: E: ID_V4L_PRODUCT=Laptop_Integrated_Webcam_1.3M E: ID_V4L_VERSION=2 E: ID_VENDOR=CN01RH717248726AD005A00 E: ID_VENDOR_ENC=CN01RH717248726AD005A00 E: ID_VENDOR_ID=1bcf E: MAJOR=81 E: MINOR=0 E: SUBSYSTEM=video4linux E: TAGS=:seat:uaccess: E: USEC_INITIALIZED=4179 P: /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5/3-1.5:1.1 E: DEVPATH=/devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5/3-1.5:1.1 E: DEVTYPE=usb_interface E: DRIVER=uvcvideo E: ID_USB_CLASS_FROM_DATABASE=Miscellaneous Device E: ID_USB_PROTOCOL_FROM_DATABASE=Interface Association E: ID_VENDOR_FROM_DATABASE=Sunplus Innovation Technology Inc. E: INTERFACE=14/2/0 E: MODALIAS=usb:v1BCFp288Fd2710dcEFdsc02dp01ic0Eisc02ip00in01 E: PRODUCT=1bcf/288f/2710 E: SUBSYSTEM=usb E: TYPE=239/2/1 E: USEC_INITIALIZED=72332 P: /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1:1.0 E: DEVPATH=/devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1:1.0 E: DEVTYPE=usb_interface E: DRIVER=hub E: ID_MODEL_FROM_DATABASE=Integrated Rate Matching Hub E: ID_USB_CLASS_FROM_DATABASE=Hub E: ID_USB_PROTOCOL_FROM_DATABASE=Single TT E: ID_VENDOR_FROM_DATABASE=Intel Corp. E: INTERFACE=9/0/0 E: MODALIAS=usb:v8087p0024d0000dc09dsc00dp01ic09isc00ip00in00 E: PRODUCT=8087/24/0 E: SUBSYSTEM=usb E: TYPE=9/0/1 E: USEC_INITIALIZED=85302 P: /devices/pci0000:00/0000:00:1b.0 E: DEVPATH=/devices/pci0000:00/0000:00:1b.0 E: DRIVER=snd_hda_intel E: ID_MODEL_FROM_DATABASE=7 Series/C210 Series Chipset Family High Definition Audio Controller E: ID_PCI_CLASS_FROM_DATABASE=Multimedia controller E: ID_PCI_SUBCLASS_FROM_DATABASE=Audio device E: ID_VENDOR_FROM_DATABASE=Intel Corporation E: MODALIAS=pci:v00008086d00001E20sv00001028sd0000058Bbc04sc03i00 E: PCI_CLASS=40300 E: PCI_ID=8086:1E20 E: PCI_SLOT_NAME=0000:00:1b.0 E: PCI_SUBSYS_ID=1028:058B E: SUBSYSTEM=pci E: USEC_INITIALIZED=85325 P: /devices/pci0000:00/0000:00:1b.0/sound/card0 E: DEVPATH=/devices/pci0000:00/0000:00:1b.0/sound/card0 E: ID_BUS=pci E: ID_FOR_SEAT=sound-pci-0000_00_1b_0 E: ID_MODEL_FROM_DATABASE=7 Series/C210 Series Chipset Family High Definition Audio Controller E: ID_MODEL_ID=0x1e20 E: ID_PATH=pci-0000:00:1b.0 E: ID_PATH_TAG=pci-0000_00_1b_0 E: ID_PCI_CLASS_FROM_DATABASE=Multimedia controller E: ID_PCI_SUBCLASS_FROM_DATABASE=Audio device E: ID_VENDOR_FROM_DATABASE=Intel Corporation E: ID_VENDOR_ID=0x8086 E: PULSE_PROFILE_SET=extra-hdmi.conf E: SOUND_FORM_FACTOR=internal E: SOUND_INITIALIZED=1 E: SUBSYSTEM=sound E: SYSTEMD_WANTS=sound.target E: TAGS=:seat:systemd: E: USEC_INITIALIZED=81901 P: /devices/pci0000:00/0000:00:1b.0/sound/card0/hdaudioC0D0 E: DEVPATH=/devices/pci0000:00/0000:00:1b.0/sound/card0/hdaudioC0D0 E: SUBSYSTEM=sound P: /devices/pci0000:00/0000:00:1b.0/sound/card0/hdaudioC0D0/hwC0D0 N: snd/hwC0D0 E: DEVNAME=/dev/snd/hwC0D0 E: DEVPATH=/devices/pci0000:00/0000:00:1b.0/sound/card0/hdaudioC0D0/hwC0D0 E: MAJOR=116 E: MINOR=6 E: SUBSYSTEM=sound E: TAGS=:uaccess: E: USEC_INITIALIZED=82761 P: /devices/pci0000:00/0000:00:1b.0/sound/card0/hdaudioC0D0/input8 E: DEVPATH=/devices/pci0000:00/0000:00:1b.0/sound/card0/hdaudioC0D0/input8 E: EV=40001 E: ID_FOR_SEAT=input-pci-0000_00_1b_0 E: ID_INPUT=1 E: ID_PATH=pci-0000:00:1b.0 E: ID_PATH_TAG=pci-0000_00_1b_0 E: MODALIAS=input:b0001v10ECp0275e0001-e0,12,kramls1,2,fw E: NAME="HDA Digital PCBeep" E: PHYS="card0/codec#0/beep0" E: PRODUCT=1/10ec/275/1 E: PROP=0 E: SND=6 E: SUBSYSTEM=input E: TAGS=:seat: E: USEC_INITIALIZED=82206 P: /devices/pci0000:00/0000:00:1b.0/sound/card0/hdaudioC0D0/input8/event7 N: input/event7 E: DEVNAME=/dev/input/event7 E: DEVPATH=/devices/pci0000:00/0000:00:1b.0/sound/card0/hdaudioC0D0/input8/event7 E: ID_INPUT=1 E: ID_PATH=pci-0000:00:1b.0 E: ID_PATH_TAG=pci-0000_00_1b_0 E: MAJOR=13 E: MINOR=71 E: SUBSYSTEM=input E: USEC_INITIALIZED=82325 P: /devices/pci0000:00/0000:00:1b.0/sound/card0/hdaudioC0D0/pcmC0D0c N: snd/pcmC0D0c E: DEVNAME=/dev/snd/pcmC0D0c E: DEVPATH=/devices/pci0000:00/0000:00:1b.0/sound/card0/hdaudioC0D0/pcmC0D0c E: MAJOR=116 E: MINOR=4 E: SUBSYSTEM=sound E: TAGS=:uaccess: E: USEC_INITIALIZED=82569 P: /devices/pci0000:00/0000:00:1b.0/sound/card0/hdaudioC0D0/pcmC0D0p N: snd/pcmC0D0p E: DEVNAME=/dev/snd/pcmC0D0p E: DEVPATH=/devices/pci0000:00/0000:00:1b.0/sound/card0/hdaudioC0D0/pcmC0D0p E: MAJOR=116 E: MINOR=3 E: SUBSYSTEM=sound E: TAGS=:uaccess: E: USEC_INITIALIZED=82499 P: /devices/pci0000:00/0000:00:1b.0/sound/card0/hdaudioC0D3 E: DEVPATH=/devices/pci0000:00/0000:00:1b.0/sound/card0/hdaudioC0D3 E: SUBSYSTEM=sound P: /devices/pci0000:00/0000:00:1b.0/sound/card0/hdaudioC0D3/hwC0D3 N: snd/hwC0D3 E: DEVNAME=/dev/snd/hwC0D3 E: DEVPATH=/devices/pci0000:00/0000:00:1b.0/sound/card0/hdaudioC0D3/hwC0D3 E: MAJOR=116 E: MINOR=7 E: SUBSYSTEM=sound E: TAGS=:uaccess: E: USEC_INITIALIZED=82860 P: /devices/pci0000:00/0000:00:1b.0/sound/card0/hdaudioC0D3/pcmC0D3p N: snd/pcmC0D3p E: DEVNAME=/dev/snd/pcmC0D3p E: DEVPATH=/devices/pci0000:00/0000:00:1b.0/sound/card0/hdaudioC0D3/pcmC0D3p E: MAJOR=116 E: MINOR=5 E: SUBSYSTEM=sound E: TAGS=:uaccess: E: USEC_INITIALIZED=82666 P: /devices/pci0000:00/0000:00:1b.0/sound/card0/input10 E: DEVPATH=/devices/pci0000:00/0000:00:1b.0/sound/card0/input10 E: EV=21 E: ID_FOR_SEAT=input-pci-0000_00_1b_0 E: ID_INPUT=1 E: ID_PATH=pci-0000:00:1b.0 E: ID_PATH_TAG=pci-0000_00_1b_0 E: MODALIAS=input:b0000v0000p0000e0000-e0,5,kramlsfw4, E: NAME="HDA Intel PCH Mic" E: PHYS="ALSA" E: PRODUCT=0/0/0/0 E: PROP=0 E: SUBSYSTEM=input E: SW=10 E: TAGS=:seat: E: USEC_INITIALIZED=82984 P: /devices/pci0000:00/0000:00:1b.0/sound/card0/input10/event8 N: input/event8 E: DEVNAME=/dev/input/event8 E: DEVPATH=/devices/pci0000:00/0000:00:1b.0/sound/card0/input10/event8 E: ID_INPUT=1 E: ID_PATH=pci-0000:00:1b.0 E: ID_PATH_TAG=pci-0000_00_1b_0 E: MAJOR=13 E: MINOR=72 E: SUBSYSTEM=input E: USEC_INITIALIZED=83074 P: /devices/pci0000:00/0000:00:1b.0/sound/card0/input11 E: DEVPATH=/devices/pci0000:00/0000:00:1b.0/sound/card0/input11 E: EV=21 E: ID_FOR_SEAT=input-pci-0000_00_1b_0 E: ID_INPUT=1 E: ID_PATH=pci-0000:00:1b.0 E: ID_PATH_TAG=pci-0000_00_1b_0 E: MODALIAS=input:b0000v0000p0000e0000-e0,5,kramlsfw2, E: NAME="HDA Intel PCH Front Headphone" E: PHYS="ALSA" E: PRODUCT=0/0/0/0 E: PROP=0 E: SUBSYSTEM=input E: SW=4 E: TAGS=:seat: E: USEC_INITIALIZED=83188 P: /devices/pci0000:00/0000:00:1b.0/sound/card0/input11/event9 N: input/event9 E: DEVNAME=/dev/input/event9 E: DEVPATH=/devices/pci0000:00/0000:00:1b.0/sound/card0/input11/event9 E: ID_INPUT=1 E: ID_PATH=pci-0000:00:1b.0 E: ID_PATH_TAG=pci-0000_00_1b_0 E: MAJOR=13 E: MINOR=73 E: SUBSYSTEM=input E: USEC_INITIALIZED=83288 P: /devices/pci0000:00/0000:00:1b.0/sound/card0/input12 E: DEVPATH=/devices/pci0000:00/0000:00:1b.0/sound/card0/input12 E: EV=21 E: ID_FOR_SEAT=input-pci-0000_00_1b_0 E: ID_INPUT=1 E: ID_PATH=pci-0000:00:1b.0 E: ID_PATH_TAG=pci-0000_00_1b_0 E: MODALIAS=input:b0000v0000p0000e0000-e0,5,kramlsfw6,8, E: NAME="HDA Intel PCH HDMI/DP,pcm=3" E: PHYS="ALSA" E: PRODUCT=0/0/0/0 E: PROP=0 E: SUBSYSTEM=input E: SW=140 E: TAGS=:seat: E: USEC_INITIALIZED=83469 P: /devices/pci0000:00/0000:00:1b.0/sound/card0/input12/event10 N: input/event10 E: DEVNAME=/dev/input/event10 E: DEVPATH=/devices/pci0000:00/0000:00:1b.0/sound/card0/input12/event10 E: ID_INPUT=1 E: ID_PATH=pci-0000:00:1b.0 E: ID_PATH_TAG=pci-0000_00_1b_0 E: MAJOR=13 E: MINOR=74 E: SUBSYSTEM=input E: USEC_INITIALIZED=83558 P: /devices/pci0000:00/0000:00:1b.0/sound/card0/controlC0 N: snd/controlC0 S: snd/by-path/pci-0000:00:1b.0 E: DEVLINKS=/dev/snd/by-path/pci-0000:00:1b.0 E: DEVNAME=/dev/snd/controlC0 E: DEVPATH=/devices/pci0000:00/0000:00:1b.0/sound/card0/controlC0 E: ID_PATH=pci-0000:00:1b.0 E: ID_PATH_TAG=pci-0000_00_1b_0 E: MAJOR=116 E: MINOR=2 E: SUBSYSTEM=sound E: TAGS=:uaccess: E: USEC_INITIALIZED=81987 P: /devices/pci0000:00/0000:00:1c.0 E: DEVPATH=/devices/pci0000:00/0000:00:1c.0 E: DRIVER=pcieport E: ID_MODEL_FROM_DATABASE=7 Series/C210 Series Chipset Family PCI Express Root Port 1 E: ID_PCI_CLASS_FROM_DATABASE=Bridge E: ID_PCI_INTERFACE_FROM_DATABASE=Normal decode E: ID_PCI_SUBCLASS_FROM_DATABASE=PCI bridge E: ID_VENDOR_FROM_DATABASE=Intel Corporation E: MODALIAS=pci:v00008086d00001E10sv00001028sd0000058Bbc06sc04i00 E: PCI_CLASS=60400 E: PCI_ID=8086:1E10 E: PCI_SLOT_NAME=0000:00:1c.0 E: PCI_SUBSYS_ID=1028:058B E: SUBSYSTEM=pci E: USEC_INITIALIZED=85381 P: /devices/pci0000:00/0000:00:1c.0/0000:01:00.0 E: DEVPATH=/devices/pci0000:00/0000:00:1c.0/0000:01:00.0 E: DRIVER=iwlwifi E: ID_MODEL_FROM_DATABASE=Wireless 7260 (Dual Band Wireless-AC 7260) E: ID_PCI_CLASS_FROM_DATABASE=Network controller E: ID_PCI_SUBCLASS_FROM_DATABASE=Network controller E: ID_VENDOR_FROM_DATABASE=Intel Corporation E: MODALIAS=pci:v00008086d000008B1sv00008086sd00004070bc02sc80i00 E: PCI_CLASS=28000 E: PCI_ID=8086:08B1 E: PCI_SLOT_NAME=0000:01:00.0 E: PCI_SUBSYS_ID=8086:4070 E: SUBSYSTEM=pci E: USEC_INITIALIZED=85450 P: /devices/pci0000:00/0000:00:1c.0/0000:01:00.0/ieee80211/phy0 E: DEVPATH=/devices/pci0000:00/0000:00:1c.0/0000:01:00.0/ieee80211/phy0 E: SUBSYSTEM=ieee80211 P: /devices/pci0000:00/0000:00:1c.0/0000:01:00.0/ieee80211/phy0/rfkill1 E: DEVPATH=/devices/pci0000:00/0000:00:1c.0/0000:01:00.0/ieee80211/phy0/rfkill1 E: ID_PATH=pci-0000:01:00.0 E: ID_PATH_TAG=pci-0000_01_00_0 E: RFKILL_NAME=phy0 E: RFKILL_STATE=1 E: RFKILL_TYPE=wlan E: SUBSYSTEM=rfkill E: SYSTEMD_ALIAS=/sys/subsystem/rfkill/devices/rfkill1 E: SYSTEMD_WANTS=systemd-rfkill at rfkill1.service E: TAGS=:systemd: E: USEC_INITIALIZED=4459 P: /devices/pci0000:00/0000:00:1c.0/0000:01:00.0/leds/phy0-led E: DEVPATH=/devices/pci0000:00/0000:00:1c.0/0000:01:00.0/leds/phy0-led E: SUBSYSTEM=leds P: /devices/pci0000:00/0000:00:1c.0/0000:01:00.0/net/wlp1s0 E: DEVPATH=/devices/pci0000:00/0000:00:1c.0/0000:01:00.0/net/wlp1s0 E: DEVTYPE=wlan E: ID_BUS=pci E: ID_MODEL_FROM_DATABASE=Wireless 7260 (Dual Band Wireless-AC 7260) E: ID_MODEL_ID=0x08b1 E: ID_NET_DRIVER=iwlwifi E: ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link E: ID_NET_NAME=wlp1s0 E: ID_NET_NAME_MAC=wlxf81654f824e2 E: ID_NET_NAME_PATH=wlp1s0 E: ID_OUI_FROM_DATABASE=Intel Corporate E: ID_PATH=pci-0000:01:00.0 E: ID_PATH_TAG=pci-0000_01_00_0 E: ID_PCI_CLASS_FROM_DATABASE=Network controller E: ID_PCI_SUBCLASS_FROM_DATABASE=Network controller E: ID_VENDOR_FROM_DATABASE=Intel Corporation E: ID_VENDOR_ID=0x8086 E: IFINDEX=2 E: INTERFACE=wlp1s0 E: MAJOR=0 E: MINOR=0 E: SUBSYSTEM=net E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/wlp1s0 /sys/subsystem/net/devices/wlp1s0 E: TAGS=:systemd: E: USEC_INITIALIZED=4523 P: /devices/pci0000:00/0000:00:1c.0/pci_bus/0000:01 E: DEVPATH=/devices/pci0000:00/0000:00:1c.0/pci_bus/0000:01 E: SUBSYSTEM=pci_bus P: /devices/pci0000:00/0000:00:1d.0 E: DEVPATH=/devices/pci0000:00/0000:00:1d.0 E: DRIVER=ehci-pci E: ID_MODEL_FROM_DATABASE=7 Series/C210 Series Chipset Family USB Enhanced Host Controller E: ID_PCI_CLASS_FROM_DATABASE=Serial bus controller E: ID_PCI_INTERFACE_FROM_DATABASE=EHCI E: ID_PCI_SUBCLASS_FROM_DATABASE=USB controller E: ID_VENDOR_FROM_DATABASE=Intel Corporation E: MODALIAS=pci:v00008086d00001E26sv00001028sd0000058Bbc0Csc03i20 E: PCI_CLASS=C0320 E: PCI_ID=8086:1E26 E: PCI_SLOT_NAME=0000:00:1d.0 E: PCI_SUBSYS_ID=1028:058B E: SUBSYSTEM=pci E: USEC_INITIALIZED=85508 P: /devices/pci0000:00/0000:00:1d.0/usb4 N: bus/usb/004/001 E: BUSNUM=004 E: DEVNAME=/dev/bus/usb/004/001 E: DEVNUM=001 E: DEVPATH=/devices/pci0000:00/0000:00:1d.0/usb4 E: DEVTYPE=usb_device E: DRIVER=usb E: ID_BUS=usb E: ID_FOR_SEAT=usb-pci-0000_00_1d_0 E: ID_MODEL=EHCI_Host_Controller E: ID_MODEL_ENC=EHCI\x20Host\x20Controller E: ID_MODEL_FROM_DATABASE=2.0 root hub E: ID_MODEL_ID=0002 E: ID_PATH=pci-0000:00:1d.0 E: ID_PATH_TAG=pci-0000_00_1d_0 E: ID_REVISION=0318 E: ID_SERIAL=Linux_3.18.6-1-ARCH_ehci_hcd_EHCI_Host_Controller_0000:00:1d.0 E: ID_SERIAL_SHORT=0000:00:1d.0 E: ID_USB_INTERFACES=:090000: E: ID_VENDOR=Linux_3.18.6-1-ARCH_ehci_hcd E: ID_VENDOR_ENC=Linux\x203.18.6-1-ARCH\x20ehci_hcd E: ID_VENDOR_FROM_DATABASE=Linux Foundation E: ID_VENDOR_ID=1d6b E: MAJOR=189 E: MINOR=384 E: PRODUCT=1d6b/2/318 E: SUBSYSTEM=usb E: TAGS=:seat: E: TYPE=9/0/0 E: USEC_INITIALIZED=85861 P: /devices/pci0000:00/0000:00:1d.0/usb4/4-0:1.0 E: DEVPATH=/devices/pci0000:00/0000:00:1d.0/usb4/4-0:1.0 E: DEVTYPE=usb_interface E: DRIVER=hub E: ID_MODEL_FROM_DATABASE=2.0 root hub E: ID_USB_CLASS_FROM_DATABASE=Hub E: ID_USB_PROTOCOL_FROM_DATABASE=Full speed (or root) hub E: ID_VENDOR_FROM_DATABASE=Linux Foundation E: INTERFACE=9/0/0 E: MODALIAS=usb:v1D6Bp0002d0318dc09dsc00dp00ic09isc00ip00in00 E: PRODUCT=1d6b/2/318 E: SUBSYSTEM=usb E: TYPE=9/0/0 E: USEC_INITIALIZED=85898 P: /devices/pci0000:00/0000:00:1d.0/usb4/4-1 N: bus/usb/004/002 E: BUSNUM=004 E: DEVNAME=/dev/bus/usb/004/002 E: DEVNUM=002 E: DEVPATH=/devices/pci0000:00/0000:00:1d.0/usb4/4-1 E: DEVTYPE=usb_device E: DRIVER=usb E: ID_BUS=usb E: ID_FOR_SEAT=usb-pci-0000_00_1d_0-usb-0_1 E: ID_MODEL=0024 E: ID_MODEL_ENC=0024 E: ID_MODEL_FROM_DATABASE=Integrated Rate Matching Hub E: ID_MODEL_ID=0024 E: ID_PATH=pci-0000:00:1d.0-usb-0:1 E: ID_PATH_TAG=pci-0000_00_1d_0-usb-0_1 E: ID_REVISION=0000 E: ID_SERIAL=8087_0024 E: ID_USB_INTERFACES=:090000: E: ID_VENDOR=8087 E: ID_VENDOR_ENC=8087 E: ID_VENDOR_FROM_DATABASE=Intel Corp. E: ID_VENDOR_ID=8087 E: MAJOR=189 E: MINOR=385 E: PRODUCT=8087/24/0 E: SUBSYSTEM=usb E: TAGS=:seat: E: TYPE=9/0/1 E: USEC_INITIALIZED=85940 P: /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5 N: bus/usb/004/003 E: BUSNUM=004 E: DEVNAME=/dev/bus/usb/004/003 E: DEVNUM=003 E: DEVPATH=/devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5 E: DEVTYPE=usb_device E: DRIVER=usb E: ID_BUS=usb E: ID_MODEL=07dc E: ID_MODEL_ENC=07dc E: ID_MODEL_ID=07dc E: ID_REVISION=0001 E: ID_SERIAL=8087_07dc E: ID_USB_INTERFACES=:e00101: E: ID_VENDOR=8087 E: ID_VENDOR_ENC=8087 E: ID_VENDOR_FROM_DATABASE=Intel Corp. E: ID_VENDOR_ID=8087 E: MAJOR=189 E: MINOR=386 E: PRODUCT=8087/7dc/1 E: SUBSYSTEM=usb E: TYPE=224/1/1 E: USEC_INITIALIZED=85973 P: /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5:1.0 E: DEVPATH=/devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5:1.0 E: DEVTYPE=usb_interface E: DRIVER=btusb E: ID_USB_CLASS_FROM_DATABASE=Wireless E: ID_USB_PROTOCOL_FROM_DATABASE=Bluetooth E: ID_USB_SUBCLASS_FROM_DATABASE=Radio Frequency E: ID_VENDOR_FROM_DATABASE=Intel Corp. E: INTERFACE=224/1/1 E: MODALIAS=usb:v8087p07DCd0001dcE0dsc01dp01icE0isc01ip01in00 E: PRODUCT=8087/7dc/1 E: SUBSYSTEM=usb E: TYPE=224/1/1 E: USEC_INITIALIZED=86000 P: /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5:1.0/bluetooth/hci0 E: DEVPATH=/devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5:1.0/bluetooth/hci0 E: DEVTYPE=host E: SUBSYSTEM=bluetooth E: SYSTEMD_ALIAS=/sys/subsystem/bluetooth/devices/hci0 E: SYSTEMD_WANTS=bluetooth.target E: TAGS=:systemd: E: USEC_INITIALIZED=83057 P: /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5:1.0/bluetooth/hci0/rfkill0 E: DEVPATH=/devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5:1.0/bluetooth/hci0/rfkill0 E: ID_PATH=pci-0000:00:1d.0-usb-0:1.5:1.0 E: ID_PATH_TAG=pci-0000_00_1d_0-usb-0_1_5_1_0 E: RFKILL_NAME=hci0 E: RFKILL_STATE=1 E: RFKILL_TYPE=bluetooth E: SUBSYSTEM=rfkill E: SYSTEMD_ALIAS=/sys/subsystem/rfkill/devices/rfkill0 E: SYSTEMD_WANTS=systemd-rfkill at rfkill0.service E: TAGS=:systemd: E: USEC_INITIALIZED=83079 P: /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5:1.1 E: DEVPATH=/devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5:1.1 E: DEVTYPE=usb_interface E: DRIVER=btusb E: ID_USB_CLASS_FROM_DATABASE=Wireless E: ID_USB_PROTOCOL_FROM_DATABASE=Bluetooth E: ID_USB_SUBCLASS_FROM_DATABASE=Radio Frequency E: ID_VENDOR_FROM_DATABASE=Intel Corp. E: INTERFACE=224/1/1 E: MODALIAS=usb:v8087p07DCd0001dcE0dsc01dp01icE0isc01ip01in01 E: PRODUCT=8087/7dc/1 E: SUBSYSTEM=usb E: TYPE=224/1/1 E: USEC_INITIALIZED=86030 P: /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1:1.0 E: DEVPATH=/devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1:1.0 E: DEVTYPE=usb_interface E: DRIVER=hub E: ID_MODEL_FROM_DATABASE=Integrated Rate Matching Hub E: ID_USB_CLASS_FROM_DATABASE=Hub E: ID_USB_PROTOCOL_FROM_DATABASE=Single TT E: ID_VENDOR_FROM_DATABASE=Intel Corp. E: INTERFACE=9/0/0 E: MODALIAS=usb:v8087p0024d0000dc09dsc00dp01ic09isc00ip00in00 E: PRODUCT=8087/24/0 E: SUBSYSTEM=usb E: TYPE=9/0/1 E: USEC_INITIALIZED=86058 P: /devices/pci0000:00/0000:00:1f.0 E: DEVPATH=/devices/pci0000:00/0000:00:1f.0 E: DRIVER=lpc_ich E: ID_MODEL_FROM_DATABASE=QS77 Express Chipset LPC Controller E: ID_PCI_CLASS_FROM_DATABASE=Bridge E: ID_PCI_SUBCLASS_FROM_DATABASE=ISA bridge E: ID_VENDOR_FROM_DATABASE=Intel Corporation E: MODALIAS=pci:v00008086d00001E56sv00001028sd0000058Bbc06sc01i00 E: PCI_CLASS=60100 E: PCI_ID=8086:1E56 E: PCI_SLOT_NAME=0000:00:1f.0 E: PCI_SUBSYS_ID=1028:058B E: SUBSYSTEM=pci E: USEC_INITIALIZED=86085 P: /devices/pci0000:00/0000:00:1f.0/PNP0103:00 E: DEVPATH=/devices/pci0000:00/0000:00:1f.0/PNP0103:00 E: MODALIAS=acpi:PNP0103: E: SUBSYSTEM=platform P: /devices/pci0000:00/0000:00:1f.0/PNP0C04:00 E: DEVPATH=/devices/pci0000:00/0000:00:1f.0/PNP0C04:00 E: MODALIAS=acpi:PNP0C04: E: SUBSYSTEM=platform P: /devices/pci0000:00/0000:00:1f.0/PNP0C09:00 E: DEVPATH=/devices/pci0000:00/0000:00:1f.0/PNP0C09:00 E: MODALIAS=acpi:PNP0C09: E: SUBSYSTEM=platform P: /devices/pci0000:00/0000:00:1f.0/PNP0C09:00/ACPI0008:00 E: DEVPATH=/devices/pci0000:00/0000:00:1f.0/PNP0C09:00/ACPI0008:00 E: MODALIAS=acpi:ACPI0008: E: SUBSYSTEM=platform P: /devices/pci0000:00/0000:00:1f.0/PNP0C32:00 E: DEVPATH=/devices/pci0000:00/0000:00:1f.0/PNP0C32:00 E: MODALIAS=acpi:PNP0C32: E: SUBSYSTEM=platform P: /devices/pci0000:00/0000:00:1f.0/iTCO_wdt E: DEVPATH=/devices/pci0000:00/0000:00:1f.0/iTCO_wdt E: DEVTYPE=mfd_device E: DRIVER=iTCO_wdt E: MODALIAS=platform:iTCO_wdt E: SUBSYSTEM=platform P: /devices/pci0000:00/0000:00:1f.0/iTCO_wdt/misc/watchdog N: watchdog E: DEVNAME=/dev/watchdog E: DEVPATH=/devices/pci0000:00/0000:00:1f.0/iTCO_wdt/misc/watchdog E: MAJOR=10 E: MINOR=130 E: SUBSYSTEM=misc P: /devices/pci0000:00/0000:00:1f.0/iTCO_wdt/watchdog/watchdog0 N: watchdog0 E: DEVNAME=/dev/watchdog0 E: DEVPATH=/devices/pci0000:00/0000:00:1f.0/iTCO_wdt/watchdog/watchdog0 E: MAJOR=253 E: MINOR=0 E: SUBSYSTEM=watchdog P: /devices/pci0000:00/0000:00:1f.2 E: DEVPATH=/devices/pci0000:00/0000:00:1f.2 E: DRIVER=ahci E: ID_MODEL_FROM_DATABASE=7 Series Chipset Family 6-port SATA Controller [AHCI mode] E: ID_PCI_CLASS_FROM_DATABASE=Mass storage controller E: ID_PCI_INTERFACE_FROM_DATABASE=AHCI 1.0 E: ID_PCI_SUBCLASS_FROM_DATABASE=SATA controller E: ID_VENDOR_FROM_DATABASE=Intel Corporation E: MODALIAS=pci:v00008086d00001E03sv00001028sd0000058Bbc01sc06i01 E: PCI_CLASS=10601 E: PCI_ID=8086:1E03 E: PCI_SLOT_NAME=0000:00:1f.2 E: PCI_SUBSYS_ID=1028:058B E: SUBSYSTEM=pci E: USEC_INITIALIZED=86310 P: /devices/pci0000:00/0000:00:1f.2/ata1/ata_port/ata1 E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata1/ata_port/ata1 E: SUBSYSTEM=ata_port P: /devices/pci0000:00/0000:00:1f.2/ata1/host0 E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata1/host0 E: DEVTYPE=scsi_host E: SUBSYSTEM=scsi P: /devices/pci0000:00/0000:00:1f.2/ata1/host0/scsi_host/host0 E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata1/host0/scsi_host/host0 E: SUBSYSTEM=scsi_host P: /devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0 E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0 E: DEVTYPE=scsi_target E: SUBSYSTEM=scsi P: /devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0 E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0 E: DEVTYPE=scsi_device E: DRIVER=sd E: MODALIAS=scsi:t-0x00 E: SUBSYSTEM=scsi P: /devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda N: sda S: disk/by-id/ata-SAMSUNG_SSD_PM830_mSATA_256GB_S0XPNYAD800120 S: disk/by-id/wwn-0x5002538043584d30 E: DEVLINKS=/dev/disk/by-id/ata-SAMSUNG_SSD_PM830_mSATA_256GB_S0XPNYAD800120 /dev/disk/by-id/wwn-0x5002538043584d30 E: DEVNAME=/dev/sda E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda E: DEVTYPE=disk E: ID_ATA=1 E: ID_ATA_DOWNLOAD_MICROCODE=1 E: ID_ATA_FEATURE_SET_AAM=1 E: ID_ATA_FEATURE_SET_AAM_CURRENT_VALUE=0 E: ID_ATA_FEATURE_SET_AAM_ENABLED=0 E: ID_ATA_FEATURE_SET_AAM_VENDOR_RECOMMENDED_VALUE=128 E: ID_ATA_FEATURE_SET_HPA=1 E: ID_ATA_FEATURE_SET_HPA_ENABLED=1 E: ID_ATA_FEATURE_SET_PM=1 E: ID_ATA_FEATURE_SET_PM_ENABLED=1 E: ID_ATA_FEATURE_SET_SECURITY=1 E: ID_ATA_FEATURE_SET_SECURITY_ENABLED=0 E: ID_ATA_FEATURE_SET_SECURITY_ENHANCED_ERASE_UNIT_MIN=32 E: ID_ATA_FEATURE_SET_SECURITY_ERASE_UNIT_MIN=6 E: ID_ATA_FEATURE_SET_SECURITY_FROZEN=1 E: ID_ATA_FEATURE_SET_SMART=1 E: ID_ATA_FEATURE_SET_SMART_ENABLED=1 E: ID_ATA_ROTATION_RATE_RPM=0 E: ID_ATA_SATA=1 E: ID_ATA_SATA_SIGNAL_RATE_GEN1=1 E: ID_ATA_SATA_SIGNAL_RATE_GEN2=1 E: ID_ATA_WRITE_CACHE=1 E: ID_ATA_WRITE_CACHE_ENABLED=1 E: ID_BUS=ata E: ID_MODEL=SAMSUNG_SSD_PM830_mSATA_256GB E: ID_MODEL_ENC=SAMSUNG\x20SSD\x20PM830\x20mSATA\x20256GB\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20 E: ID_PART_TABLE_TYPE=gpt E: ID_PART_TABLE_UUID=7575f9a6-a6cb-4037-b3ae-1af3f61c5169 E: ID_REVISION=CXM13D1Q E: ID_SERIAL=SAMSUNG_SSD_PM830_mSATA_256GB_S0XPNYAD800120 E: ID_SERIAL_SHORT=S0XPNYAD800120 E: ID_TYPE=disk E: ID_WWN=0x5002538043584d30 E: ID_WWN_WITH_EXTENSION=0x5002538043584d30 E: MAJOR=8 E: MINOR=0 E: SUBSYSTEM=block E: TAGS=:systemd: E: USEC_INITIALIZED=86554 P: /devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda1 N: sda1 S: disk/by-id/ata-SAMSUNG_SSD_PM830_mSATA_256GB_S0XPNYAD800120-part1 S: disk/by-id/wwn-0x5002538043584d30-part1 S: disk/by-partlabel/EFI\x20System S: disk/by-partuuid/67630c1f-875f-426b-9b9d-304defb1ee0c S: disk/by-uuid/2A36-307B E: DEVLINKS=/dev/disk/by-id/ata-SAMSUNG_SSD_PM830_mSATA_256GB_S0XPNYAD800120-part1 /dev/disk/by-id/wwn-0x5002538043584d30-part1 /dev/disk/by-partlabel/EFI\x20System /dev/disk/by-partuuid/67630c1f-875f-426b-9b9d-304defb1ee0c /dev/disk/by-uuid/2A36-307B E: DEVNAME=/dev/sda1 E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda1 E: DEVTYPE=partition E: ID_ATA=1 E: ID_ATA_DOWNLOAD_MICROCODE=1 E: ID_ATA_FEATURE_SET_AAM=1 E: ID_ATA_FEATURE_SET_AAM_CURRENT_VALUE=0 E: ID_ATA_FEATURE_SET_AAM_ENABLED=0 E: ID_ATA_FEATURE_SET_AAM_VENDOR_RECOMMENDED_VALUE=128 E: ID_ATA_FEATURE_SET_HPA=1 E: ID_ATA_FEATURE_SET_HPA_ENABLED=1 E: ID_ATA_FEATURE_SET_PM=1 E: ID_ATA_FEATURE_SET_PM_ENABLED=1 E: ID_ATA_FEATURE_SET_SECURITY=1 E: ID_ATA_FEATURE_SET_SECURITY_ENABLED=0 E: ID_ATA_FEATURE_SET_SECURITY_ENHANCED_ERASE_UNIT_MIN=32 E: ID_ATA_FEATURE_SET_SECURITY_ERASE_UNIT_MIN=6 E: ID_ATA_FEATURE_SET_SECURITY_FROZEN=1 E: ID_ATA_FEATURE_SET_SMART=1 E: ID_ATA_FEATURE_SET_SMART_ENABLED=1 E: ID_ATA_ROTATION_RATE_RPM=0 E: ID_ATA_SATA=1 E: ID_ATA_SATA_SIGNAL_RATE_GEN1=1 E: ID_ATA_SATA_SIGNAL_RATE_GEN2=1 E: ID_ATA_WRITE_CACHE=1 E: ID_ATA_WRITE_CACHE_ENABLED=1 E: ID_BUS=ata E: ID_FS_TYPE=vfat E: ID_FS_USAGE=filesystem E: ID_FS_UUID=2A36-307B E: ID_FS_UUID_ENC=2A36-307B E: ID_FS_VERSION=FAT32 E: ID_MODEL=SAMSUNG_SSD_PM830_mSATA_256GB E: ID_MODEL_ENC=SAMSUNG\x20SSD\x20PM830\x20mSATA\x20256GB\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20 E: ID_PART_ENTRY_DISK=8:0 E: ID_PART_ENTRY_NAME=EFI\x20System E: ID_PART_ENTRY_NUMBER=1 E: ID_PART_ENTRY_OFFSET=2048 E: ID_PART_ENTRY_SCHEME=gpt E: ID_PART_ENTRY_SIZE=2097152 E: ID_PART_ENTRY_TYPE=c12a7328-f81f-11d2-ba4b-00a0c93ec93b E: ID_PART_ENTRY_UUID=67630c1f-875f-426b-9b9d-304defb1ee0c E: ID_PART_TABLE_TYPE=gpt E: ID_PART_TABLE_UUID=7575f9a6-a6cb-4037-b3ae-1af3f61c5169 E: ID_REVISION=CXM13D1Q E: ID_SERIAL=SAMSUNG_SSD_PM830_mSATA_256GB_S0XPNYAD800120 E: ID_SERIAL_SHORT=S0XPNYAD800120 E: ID_TYPE=disk E: ID_WWN=0x5002538043584d30 E: ID_WWN_WITH_EXTENSION=0x5002538043584d30 E: MAJOR=8 E: MINOR=1 E: SUBSYSTEM=block E: TAGS=:systemd: E: UDISKS_IGNORE=1 E: USEC_INITIALIZED=86598 P: /devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda2 N: sda2 S: disk/by-id/ata-SAMSUNG_SSD_PM830_mSATA_256GB_S0XPNYAD800120-part2 S: disk/by-id/wwn-0x5002538043584d30-part2 S: disk/by-label/swap S: disk/by-partlabel/Linux\x20swap S: disk/by-partuuid/1662cc5b-029c-42b3-a57a-073d8b39d811 S: disk/by-uuid/7ddaaa70-9c0e-4b06-b76f-57f9544123d1 E: DEVLINKS=/dev/disk/by-id/ata-SAMSUNG_SSD_PM830_mSATA_256GB_S0XPNYAD800120-part2 /dev/disk/by-id/wwn-0x5002538043584d30-part2 /dev/disk/by-label/swap /dev/disk/by-partlabel/Linux\x20swap /dev/disk/by-partuuid/1662cc5b-029c-42b3-a57a-073d8b39d811 /dev/disk/by-uuid/7ddaaa70-9c0e-4b06-b76f-57f9544123d1 E: DEVNAME=/dev/sda2 E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda2 E: DEVTYPE=partition E: ID_ATA=1 E: ID_ATA_DOWNLOAD_MICROCODE=1 E: ID_ATA_FEATURE_SET_AAM=1 E: ID_ATA_FEATURE_SET_AAM_CURRENT_VALUE=0 E: ID_ATA_FEATURE_SET_AAM_ENABLED=0 E: ID_ATA_FEATURE_SET_AAM_VENDOR_RECOMMENDED_VALUE=128 E: ID_ATA_FEATURE_SET_HPA=1 E: ID_ATA_FEATURE_SET_HPA_ENABLED=1 E: ID_ATA_FEATURE_SET_PM=1 E: ID_ATA_FEATURE_SET_PM_ENABLED=1 E: ID_ATA_FEATURE_SET_SECURITY=1 E: ID_ATA_FEATURE_SET_SECURITY_ENABLED=0 E: ID_ATA_FEATURE_SET_SECURITY_ENHANCED_ERASE_UNIT_MIN=32 E: ID_ATA_FEATURE_SET_SECURITY_ERASE_UNIT_MIN=6 E: ID_ATA_FEATURE_SET_SECURITY_FROZEN=1 E: ID_ATA_FEATURE_SET_SMART=1 E: ID_ATA_FEATURE_SET_SMART_ENABLED=1 E: ID_ATA_ROTATION_RATE_RPM=0 E: ID_ATA_SATA=1 E: ID_ATA_SATA_SIGNAL_RATE_GEN1=1 E: ID_ATA_SATA_SIGNAL_RATE_GEN2=1 E: ID_ATA_WRITE_CACHE=1 E: ID_ATA_WRITE_CACHE_ENABLED=1 E: ID_BUS=ata E: ID_FS_LABEL=swap E: ID_FS_LABEL_ENC=swap E: ID_FS_TYPE=swap E: ID_FS_USAGE=other E: ID_FS_UUID=7ddaaa70-9c0e-4b06-b76f-57f9544123d1 E: ID_FS_UUID_ENC=7ddaaa70-9c0e-4b06-b76f-57f9544123d1 E: ID_FS_VERSION=1 E: ID_MODEL=SAMSUNG_SSD_PM830_mSATA_256GB E: ID_MODEL_ENC=SAMSUNG\x20SSD\x20PM830\x20mSATA\x20256GB\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20 E: ID_PART_ENTRY_DISK=8:0 E: ID_PART_ENTRY_NAME=Linux\x20swap E: ID_PART_ENTRY_NUMBER=2 E: ID_PART_ENTRY_OFFSET=2099200 E: ID_PART_ENTRY_SCHEME=gpt E: ID_PART_ENTRY_SIZE=16777216 E: ID_PART_ENTRY_TYPE=0657fd6d-a4ab-43c4-84e5-0933c84b4f4f E: ID_PART_ENTRY_UUID=1662cc5b-029c-42b3-a57a-073d8b39d811 E: ID_PART_TABLE_TYPE=gpt E: ID_PART_TABLE_UUID=7575f9a6-a6cb-4037-b3ae-1af3f61c5169 E: ID_REVISION=CXM13D1Q E: ID_SERIAL=SAMSUNG_SSD_PM830_mSATA_256GB_S0XPNYAD800120 E: ID_SERIAL_SHORT=S0XPNYAD800120 E: ID_TYPE=disk E: ID_WWN=0x5002538043584d30 E: ID_WWN_WITH_EXTENSION=0x5002538043584d30 E: MAJOR=8 E: MINOR=2 E: SUBSYSTEM=block E: TAGS=:systemd: E: USEC_INITIALIZED=86639 P: /devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda3 N: sda3 S: disk/by-id/ata-SAMSUNG_SSD_PM830_mSATA_256GB_S0XPNYAD800120-part3 S: disk/by-id/wwn-0x5002538043584d30-part3 S: disk/by-label/arch S: disk/by-partlabel/Linux\x20filesystem S: disk/by-partuuid/3bbf948c-a68f-4193-92be-de9099dd9914 S: disk/by-uuid/ffca0b5e-a0d9-41e3-9aa4-20650ff12119 E: DEVLINKS=/dev/disk/by-id/ata-SAMSUNG_SSD_PM830_mSATA_256GB_S0XPNYAD800120-part3 /dev/disk/by-id/wwn-0x5002538043584d30-part3 /dev/disk/by-label/arch /dev/disk/by-partlabel/Linux\x20filesystem /dev/disk/by-partuuid/3bbf948c-a68f-4193-92be-de9099dd9914 /dev/disk/by-uuid/ffca0b5e-a0d9-41e3-9aa4-20650ff12119 E: DEVNAME=/dev/sda3 E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda3 E: DEVTYPE=partition E: ID_ATA=1 E: ID_ATA_DOWNLOAD_MICROCODE=1 E: ID_ATA_FEATURE_SET_AAM=1 E: ID_ATA_FEATURE_SET_AAM_CURRENT_VALUE=0 E: ID_ATA_FEATURE_SET_AAM_ENABLED=0 E: ID_ATA_FEATURE_SET_AAM_VENDOR_RECOMMENDED_VALUE=128 E: ID_ATA_FEATURE_SET_HPA=1 E: ID_ATA_FEATURE_SET_HPA_ENABLED=1 E: ID_ATA_FEATURE_SET_PM=1 E: ID_ATA_FEATURE_SET_PM_ENABLED=1 E: ID_ATA_FEATURE_SET_SECURITY=1 E: ID_ATA_FEATURE_SET_SECURITY_ENABLED=0 E: ID_ATA_FEATURE_SET_SECURITY_ENHANCED_ERASE_UNIT_MIN=32 E: ID_ATA_FEATURE_SET_SECURITY_ERASE_UNIT_MIN=6 E: ID_ATA_FEATURE_SET_SECURITY_FROZEN=1 E: ID_ATA_FEATURE_SET_SMART=1 E: ID_ATA_FEATURE_SET_SMART_ENABLED=1 E: ID_ATA_ROTATION_RATE_RPM=0 E: ID_ATA_SATA=1 E: ID_ATA_SATA_SIGNAL_RATE_GEN1=1 E: ID_ATA_SATA_SIGNAL_RATE_GEN2=1 E: ID_ATA_WRITE_CACHE=1 E: ID_ATA_WRITE_CACHE_ENABLED=1 E: ID_BTRFS_READY=1 E: ID_BUS=ata E: ID_FS_LABEL=arch E: ID_FS_LABEL_ENC=arch E: ID_FS_TYPE=btrfs E: ID_FS_USAGE=filesystem E: ID_FS_UUID=ffca0b5e-a0d9-41e3-9aa4-20650ff12119 E: ID_FS_UUID_ENC=ffca0b5e-a0d9-41e3-9aa4-20650ff12119 E: ID_FS_UUID_SUB=451405ac-7747-46f2-9edb-bb8e9a6bccdd E: ID_FS_UUID_SUB_ENC=451405ac-7747-46f2-9edb-bb8e9a6bccdd E: ID_MODEL=SAMSUNG_SSD_PM830_mSATA_256GB E: ID_MODEL_ENC=SAMSUNG\x20SSD\x20PM830\x20mSATA\x20256GB\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20 E: ID_PART_ENTRY_DISK=8:0 E: ID_PART_ENTRY_NAME=Linux\x20filesystem E: ID_PART_ENTRY_NUMBER=3 E: ID_PART_ENTRY_OFFSET=18876416 E: ID_PART_ENTRY_SCHEME=gpt E: ID_PART_ENTRY_SIZE=481241743 E: ID_PART_ENTRY_TYPE=0fc63daf-8483-4772-8e79-3d69d8477de4 E: ID_PART_ENTRY_UUID=3bbf948c-a68f-4193-92be-de9099dd9914 E: ID_PART_TABLE_TYPE=gpt E: ID_PART_TABLE_UUID=7575f9a6-a6cb-4037-b3ae-1af3f61c5169 E: ID_REVISION=CXM13D1Q E: ID_SERIAL=SAMSUNG_SSD_PM830_mSATA_256GB_S0XPNYAD800120 E: ID_SERIAL_SHORT=S0XPNYAD800120 E: ID_TYPE=disk E: ID_WWN=0x5002538043584d30 E: ID_WWN_WITH_EXTENSION=0x5002538043584d30 E: MAJOR=8 E: MINOR=3 E: SUBSYSTEM=block E: TAGS=:systemd: E: USEC_INITIALIZED=86687 P: /devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/bsg/0:0:0:0 N: bsg/0:0:0:0 E: DEVNAME=/dev/bsg/0:0:0:0 E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/bsg/0:0:0:0 E: MAJOR=252 E: MINOR=0 E: SUBSYSTEM=bsg P: /devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/scsi_device/0:0:0:0 E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/scsi_device/0:0:0:0 E: SUBSYSTEM=scsi_device P: /devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/scsi_disk/0:0:0:0 E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/scsi_disk/0:0:0:0 E: SUBSYSTEM=scsi_disk P: /devices/pci0000:00/0000:00:1f.2/ata1/link1/ata_link/link1 E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata1/link1/ata_link/link1 E: SUBSYSTEM=ata_link P: /devices/pci0000:00/0000:00:1f.2/ata1/link1/dev1.0/ata_device/dev1.0 E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata1/link1/dev1.0/ata_device/dev1.0 E: SUBSYSTEM=ata_device P: /devices/pci0000:00/0000:00:1f.2/ata2/ata_port/ata2 E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata2/ata_port/ata2 E: SUBSYSTEM=ata_port P: /devices/pci0000:00/0000:00:1f.2/ata2/host1 E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata2/host1 E: DEVTYPE=scsi_host E: SUBSYSTEM=scsi P: /devices/pci0000:00/0000:00:1f.2/ata2/host1/scsi_host/host1 E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata2/host1/scsi_host/host1 E: SUBSYSTEM=scsi_host P: /devices/pci0000:00/0000:00:1f.2/ata2/link2/ata_link/link2 E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata2/link2/ata_link/link2 E: SUBSYSTEM=ata_link P: /devices/pci0000:00/0000:00:1f.2/ata2/link2/dev2.0/ata_device/dev2.0 E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata2/link2/dev2.0/ata_device/dev2.0 E: SUBSYSTEM=ata_device P: /devices/pci0000:00/0000:00:1f.2/ata3/ata_port/ata3 E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata3/ata_port/ata3 E: SUBSYSTEM=ata_port P: /devices/pci0000:00/0000:00:1f.2/ata3/host2 E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata3/host2 E: DEVTYPE=scsi_host E: SUBSYSTEM=scsi P: /devices/pci0000:00/0000:00:1f.2/ata3/host2/scsi_host/host2 E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata3/host2/scsi_host/host2 E: SUBSYSTEM=scsi_host P: /devices/pci0000:00/0000:00:1f.2/ata3/link3/ata_link/link3 E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata3/link3/ata_link/link3 E: SUBSYSTEM=ata_link P: /devices/pci0000:00/0000:00:1f.2/ata3/link3/dev3.0/ata_device/dev3.0 E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata3/link3/dev3.0/ata_device/dev3.0 E: SUBSYSTEM=ata_device P: /devices/pci0000:00/0000:00:1f.2/ata4/ata_port/ata4 E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata4/ata_port/ata4 E: SUBSYSTEM=ata_port P: /devices/pci0000:00/0000:00:1f.2/ata4/host3 E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata4/host3 E: DEVTYPE=scsi_host E: SUBSYSTEM=scsi P: /devices/pci0000:00/0000:00:1f.2/ata4/host3/scsi_host/host3 E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata4/host3/scsi_host/host3 E: SUBSYSTEM=scsi_host P: /devices/pci0000:00/0000:00:1f.2/ata4/link4/ata_link/link4 E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata4/link4/ata_link/link4 E: SUBSYSTEM=ata_link P: /devices/pci0000:00/0000:00:1f.2/ata4/link4/dev4.0/ata_device/dev4.0 E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata4/link4/dev4.0/ata_device/dev4.0 E: SUBSYSTEM=ata_device P: /devices/pci0000:00/0000:00:1f.2/ata5/ata_port/ata5 E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata5/ata_port/ata5 E: SUBSYSTEM=ata_port P: /devices/pci0000:00/0000:00:1f.2/ata5/host4 E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata5/host4 E: DEVTYPE=scsi_host E: SUBSYSTEM=scsi P: /devices/pci0000:00/0000:00:1f.2/ata5/host4/scsi_host/host4 E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata5/host4/scsi_host/host4 E: SUBSYSTEM=scsi_host P: /devices/pci0000:00/0000:00:1f.2/ata5/link5/ata_link/link5 E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata5/link5/ata_link/link5 E: SUBSYSTEM=ata_link P: /devices/pci0000:00/0000:00:1f.2/ata5/link5/dev5.0/ata_device/dev5.0 E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata5/link5/dev5.0/ata_device/dev5.0 E: SUBSYSTEM=ata_device P: /devices/pci0000:00/0000:00:1f.2/ata6/ata_port/ata6 E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata6/ata_port/ata6 E: SUBSYSTEM=ata_port P: /devices/pci0000:00/0000:00:1f.2/ata6/host5 E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata6/host5 E: DEVTYPE=scsi_host E: SUBSYSTEM=scsi P: /devices/pci0000:00/0000:00:1f.2/ata6/host5/scsi_host/host5 E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata6/host5/scsi_host/host5 E: SUBSYSTEM=scsi_host P: /devices/pci0000:00/0000:00:1f.2/ata6/link6/ata_link/link6 E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata6/link6/ata_link/link6 E: SUBSYSTEM=ata_link P: /devices/pci0000:00/0000:00:1f.2/ata6/link6/dev6.0/ata_device/dev6.0 E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata6/link6/dev6.0/ata_device/dev6.0 E: SUBSYSTEM=ata_device P: /devices/pci0000:00/0000:00:1f.3 E: DEVPATH=/devices/pci0000:00/0000:00:1f.3 E: ID_MODEL_FROM_DATABASE=7 Series/C210 Series Chipset Family SMBus Controller E: ID_PCI_CLASS_FROM_DATABASE=Serial bus controller E: ID_PCI_SUBCLASS_FROM_DATABASE=SMBus E: ID_VENDOR_FROM_DATABASE=Intel Corporation E: MODALIAS=pci:v00008086d00001E22sv00001028sd0000058Bbc0Csc05i00 E: PCI_CLASS=C0500 E: PCI_ID=8086:1E22 E: PCI_SLOT_NAME=0000:00:1f.3 E: PCI_SUBSYS_ID=1028:058B E: SUBSYSTEM=pci E: USEC_INITIALIZED=88944 P: /devices/pci0000:00/pci_bus/0000:00 E: DEVPATH=/devices/pci0000:00/pci_bus/0000:00 E: SUBSYSTEM=pci_bus P: /devices/platform/ACPI0003:00 E: DEVPATH=/devices/platform/ACPI0003:00 E: MODALIAS=acpi:ACPI0003: E: SUBSYSTEM=platform P: /devices/platform/INT33A0:00 E: DEVPATH=/devices/platform/INT33A0:00 E: ID_VENDOR_FROM_DATABASE=Interphase Corporation E: MODALIAS=acpi:INT33A0: E: SUBSYSTEM=platform E: USEC_INITIALIZED=89137 P: /devices/platform/PNP0C0A:00 E: DEVPATH=/devices/platform/PNP0C0A:00 E: MODALIAS=acpi:PNP0C0A: E: SUBSYSTEM=platform P: /devices/platform/PNP0C0C:00 E: DEVPATH=/devices/platform/PNP0C0C:00 E: MODALIAS=acpi:PNP0C0C: E: SUBSYSTEM=platform P: /devices/platform/PNP0C0D:00 E: DEVPATH=/devices/platform/PNP0C0D:00 E: MODALIAS=acpi:PNP0C0D: E: SUBSYSTEM=platform P: /devices/platform/PNP0C0E:00 E: DEVPATH=/devices/platform/PNP0C0E:00 E: MODALIAS=acpi:PNP0C0E: E: SUBSYSTEM=platform P: /devices/platform/PNP0C14:00 E: DEVPATH=/devices/platform/PNP0C14:00 E: MODALIAS=acpi:PNP0C14: E: SUBSYSTEM=platform P: /devices/platform/alarmtimer E: DEVPATH=/devices/platform/alarmtimer E: DRIVER=alarmtimer E: MODALIAS=platform:alarmtimer E: SUBSYSTEM=platform P: /devices/platform/coretemp.0 E: DEVPATH=/devices/platform/coretemp.0 E: DRIVER=coretemp E: MODALIAS=platform:coretemp E: SUBSYSTEM=platform P: /devices/platform/coretemp.0/hwmon/hwmon0 E: DEVPATH=/devices/platform/coretemp.0/hwmon/hwmon0 E: SUBSYSTEM=hwmon P: /devices/platform/dcdbas E: DEVPATH=/devices/platform/dcdbas E: DRIVER=dcdbas E: MODALIAS=platform:dcdbas E: SUBSYSTEM=platform P: /devices/platform/dell-laptop E: DEVPATH=/devices/platform/dell-laptop E: DRIVER=dell-laptop E: MODALIAS=platform:dell-laptop E: SUBSYSTEM=platform P: /devices/platform/efi-framebuffer.0 E: DEVPATH=/devices/platform/efi-framebuffer.0 E: DRIVER=efi-framebuffer E: MODALIAS=platform:efi-framebuffer E: SUBSYSTEM=platform P: /devices/platform/i8042 E: DEVPATH=/devices/platform/i8042 E: DRIVER=i8042 E: MODALIAS=platform:i8042 E: SUBSYSTEM=platform P: /devices/platform/i8042/serio0 E: DEVPATH=/devices/platform/i8042/serio0 E: DRIVER=atkbd E: MODALIAS=serio:ty06pr00id00ex00 E: SERIO_EXTRA=00 E: SERIO_FIRMWARE_ID=PNP: PNP0303 E: SERIO_ID=00 E: SERIO_PROTO=00 E: SERIO_TYPE=06 E: SUBSYSTEM=serio P: /devices/platform/i8042/serio0/input/input5 E: DEVPATH=/devices/platform/i8042/serio0/input/input5 E: EV=120013 E: ID_FOR_SEAT=input-platform-i8042-serio-0 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_INPUT_KEYBOARD=1 E: ID_PATH=platform-i8042-serio-0 E: ID_PATH_TAG=platform-i8042-serio-0 E: ID_SERIAL=noserial E: KEY=1100f02902000 8380307cf910f001 feffffdfffefffff fffffffffffffffe E: LED=7 E: MODALIAS=input:b0011v0001p0001eAB83-e0,1,4,11,14,k71,72,73,74,75,76,77,79,7A,7B,7C,7D,7E,7F,80,8C,8D,8E,8F,94,98,9B,9C,9D,9E,9F,A2,A3,A4,A5,A6,AC,AD,B7,B8,B9,BF,CD,D4,D7,D9,E0,E1,E2,E3,EC,F0,ram4,l0,1,2,sfw E: MSC=10 E: NAME="AT Translated Set 2 keyboard" E: PHYS="isa0060/serio0/input0" E: PRODUCT=11/1/1/ab83 E: PROP=0 E: SUBSYSTEM=input E: TAGS=:seat: E: USEC_INITIALIZED=90465 P: /devices/platform/i8042/serio0/input/input5/event5 N: input/event5 S: input/by-path/platform-i8042-serio-0-event-kbd E: DEVLINKS=/dev/input/by-path/platform-i8042-serio-0-event-kbd E: DEVNAME=/dev/input/event5 E: DEVPATH=/devices/platform/i8042/serio0/input/input5/event5 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_INPUT_KEYBOARD=1 E: ID_PATH=platform-i8042-serio-0 E: ID_PATH_TAG=platform-i8042-serio-0 E: ID_SERIAL=noserial E: KEYBOARD_KEY_81=playpause E: KEYBOARD_KEY_82=stopcd E: KEYBOARD_KEY_83=previoussong E: KEYBOARD_KEY_84=nextsong E: KEYBOARD_KEY_85=brightnessdown E: KEYBOARD_KEY_86=brightnessup E: KEYBOARD_KEY_87=battery E: KEYBOARD_KEY_88=unknown E: KEYBOARD_KEY_89=ejectclosecd E: KEYBOARD_KEY_8F=switchvideomode E: KEYBOARD_KEY_8a=suspend E: KEYBOARD_KEY_8b=switchvideomode E: KEYBOARD_KEY_8c=!unknown E: KEYBOARD_KEY_90=previoussong E: KEYBOARD_KEY_91=prog1 E: KEYBOARD_KEY_92=media E: KEYBOARD_KEY_93=unknown E: KEYBOARD_KEY_95=camera E: KEYBOARD_KEY_97=email E: KEYBOARD_KEY_98=f21 E: KEYBOARD_KEY_99=nextsong E: KEYBOARD_KEY_9a=setup E: KEYBOARD_KEY_9b=switchvideomode E: KEYBOARD_KEY_9e=f21 E: KEYBOARD_KEY_a2=playpause E: KEYBOARD_KEY_a4=stopcd E: KEYBOARD_KEY_d8=screenlock E: KEYBOARD_KEY_d9=f21 E: KEYBOARD_KEY_ed=media E: MAJOR=13 E: MINOR=69 E: SUBSYSTEM=input E: USEC_INITIALIZED=75834 P: /devices/platform/i8042/serio1 E: DEVPATH=/devices/platform/i8042/serio1 E: DRIVER=psmouse E: MODALIAS=serio:ty01pr00id00ex00 E: SERIO_EXTRA=00 E: SERIO_FIRMWARE_ID=PNP: DLL058b PNP0f13 E: SERIO_ID=00 E: SERIO_PROTO=00 E: SERIO_TYPE=01 E: SUBSYSTEM=serio P: /devices/platform/i8042/serio1/input/input9 E: ABS=660800011000003 E: DEVPATH=/devices/platform/i8042/serio1/input/input9 E: EV=b E: ID_FOR_SEAT=input-platform-i8042-serio-1 E: ID_INPUT=1 E: ID_INPUT_TOUCHPAD=1 E: ID_PATH=platform-i8042-serio-1 E: ID_PATH_TAG=platform-i8042-serio-1 E: ID_SERIAL=noserial E: KEY=e520 70000 0 0 0 0 E: MODALIAS=input:b0011v0002p0011e0001-e0,1,3,k110,111,112,145,148,14A,14D,14E,14F,ra0,1,18,1C,2F,35,36,39,3A,mlsfw E: NAME="CyPS/2 Cypress Trackpad" E: PHYS="isa0060/serio1/input0" E: PRODUCT=11/2/11/1 E: PROP=9 E: SUBSYSTEM=input E: TAGS=:seat: E: USEC_INITIALIZED=7496 P: /devices/platform/i8042/serio1/input/input9/event13 N: input/event13 S: input/by-path/platform-i8042-serio-1-event-mouse E: DEVLINKS=/dev/input/by-path/platform-i8042-serio-1-event-mouse E: DEVNAME=/dev/input/event13 E: DEVPATH=/devices/platform/i8042/serio1/input/input9/event13 E: ID_INPUT=1 E: ID_INPUT_TOUCHPAD=1 E: ID_PATH=platform-i8042-serio-1 E: ID_PATH_TAG=platform-i8042-serio-1 E: ID_SERIAL=noserial E: MAJOR=13 E: MINOR=77 E: SUBSYSTEM=input E: USEC_INITIALIZED=7586 P: /devices/platform/i8042/serio1/input/input9/mouse0 N: input/mouse0 S: input/by-path/platform-i8042-serio-1-mouse E: DEVLINKS=/dev/input/by-path/platform-i8042-serio-1-mouse E: DEVNAME=/dev/input/mouse0 E: DEVPATH=/devices/platform/i8042/serio1/input/input9/mouse0 E: ID_INPUT=1 E: ID_INPUT_TOUCHPAD=1 E: ID_PATH=platform-i8042-serio-1 E: ID_PATH_TAG=platform-i8042-serio-1 E: ID_SERIAL=noserial E: MAJOR=13 E: MINOR=32 E: SUBSYSTEM=input E: USEC_INITIALIZED=8636 P: /devices/platform/microcode E: DEVPATH=/devices/platform/microcode E: MODALIAS=platform:microcode E: SUBSYSTEM=platform P: /devices/platform/pcspkr E: DEVPATH=/devices/platform/pcspkr E: DRIVER=pcspkr E: MODALIAS=platform:pcspkr E: SUBSYSTEM=platform P: /devices/platform/pcspkr/input/input7 E: DEVPATH=/devices/platform/pcspkr/input/input7 E: EV=40001 E: ID_FOR_SEAT=input-platform-pcspkr E: ID_INPUT=1 E: ID_PATH=platform-pcspkr E: ID_PATH_TAG=platform-pcspkr E: ID_SERIAL=noserial E: MODALIAS=input:b0010v001Fp0001e0100-e0,12,kramls1,2,fw E: NAME="PC Speaker" E: PHYS="isa0061/input0" E: PRODUCT=10/1f/1/100 E: PROP=0 E: SND=6 E: SUBSYSTEM=input E: TAGS=:seat: E: USEC_INITIALIZED=80665 P: /devices/platform/pcspkr/input/input7/event6 N: input/event6 S: input/by-path/platform-pcspkr-event-spkr E: DEVLINKS=/dev/input/by-path/platform-pcspkr-event-spkr E: DEVNAME=/dev/input/event6 E: DEVPATH=/devices/platform/pcspkr/input/input7/event6 E: ID_INPUT=1 E: ID_PATH=platform-pcspkr E: ID_PATH_TAG=platform-pcspkr E: ID_SERIAL=noserial E: MAJOR=13 E: MINOR=70 E: SUBSYSTEM=input E: USEC_INITIALIZED=81142 P: /devices/platform/regulatory.0 E: DEVPATH=/devices/platform/regulatory.0 E: MODALIAS=platform:regulatory E: SUBSYSTEM=platform P: /devices/platform/serial8250 E: DEVPATH=/devices/platform/serial8250 E: DRIVER=serial8250 E: MODALIAS=platform:serial8250 E: SUBSYSTEM=platform P: /devices/platform/serial8250/tty/ttyS0 N: ttyS0 E: DEVNAME=/dev/ttyS0 E: DEVPATH=/devices/platform/serial8250/tty/ttyS0 E: MAJOR=4 E: MINOR=64 E: SUBSYSTEM=tty E: TAGS=:systemd: E: USEC_INITIALIZED=92509 P: /devices/platform/serial8250/tty/ttyS1 N: ttyS1 E: DEVNAME=/dev/ttyS1 E: DEVPATH=/devices/platform/serial8250/tty/ttyS1 E: MAJOR=4 E: MINOR=65 E: SUBSYSTEM=tty E: TAGS=:systemd: E: USEC_INITIALIZED=96748 P: /devices/platform/serial8250/tty/ttyS2 N: ttyS2 E: DEVNAME=/dev/ttyS2 E: DEVPATH=/devices/platform/serial8250/tty/ttyS2 E: MAJOR=4 E: MINOR=66 E: SUBSYSTEM=tty E: TAGS=:systemd: E: USEC_INITIALIZED=98067 P: /devices/platform/serial8250/tty/ttyS3 N: ttyS3 E: DEVNAME=/dev/ttyS3 E: DEVPATH=/devices/platform/serial8250/tty/ttyS3 E: MAJOR=4 E: MINOR=67 E: SUBSYSTEM=tty E: TAGS=:systemd: E: USEC_INITIALIZED=98998 P: /devices/platform/vboxdrv.0 E: DEVPATH=/devices/platform/vboxdrv.0 E: DRIVER=vboxdrv E: MODALIAS=platform:vboxdrv E: SUBSYSTEM=platform P: /devices/pnp0/00:00 E: DEVPATH=/devices/pnp0/00:00 E: DRIVER=system E: SUBSYSTEM=pnp P: /devices/pnp0/00:01 E: DEVPATH=/devices/pnp0/00:01 E: DRIVER=rtc_cmos E: SUBSYSTEM=pnp P: /devices/pnp0/00:01/rtc/rtc0 N: rtc0 L: -100 S: rtc E: DEVLINKS=/dev/rtc E: DEVNAME=/dev/rtc0 E: DEVPATH=/devices/pnp0/00:01/rtc/rtc0 E: MAJOR=254 E: MINOR=0 E: SUBSYSTEM=rtc E: USEC_INITIALIZED=1127 P: /devices/pnp0/00:02 E: DEVPATH=/devices/pnp0/00:02 E: DRIVER=system E: SUBSYSTEM=pnp P: /devices/pnp0/00:03 E: DEVPATH=/devices/pnp0/00:03 E: DRIVER=i8042 kbd E: SUBSYSTEM=pnp P: /devices/pnp0/00:04 E: DEVPATH=/devices/pnp0/00:04 E: DRIVER=i8042 aux E: SUBSYSTEM=pnp P: /devices/pnp0/00:05 E: DEVPATH=/devices/pnp0/00:05 E: DRIVER=system E: SUBSYSTEM=pnp P: /devices/power E: DEVPATH=/devices/power E: SUBSYSTEM=event_source P: /devices/software E: DEVPATH=/devices/software E: SUBSYSTEM=event_source P: /devices/system/clockevents/broadcast E: DEVPATH=/devices/system/clockevents/broadcast E: SUBSYSTEM=clockevents P: /devices/system/clockevents/clockevent0 E: DEVPATH=/devices/system/clockevents/clockevent0 E: SUBSYSTEM=clockevents P: /devices/system/clockevents/clockevent1 E: DEVPATH=/devices/system/clockevents/clockevent1 E: SUBSYSTEM=clockevents P: /devices/system/clockevents/clockevent2 E: DEVPATH=/devices/system/clockevents/clockevent2 E: SUBSYSTEM=clockevents P: /devices/system/clockevents/clockevent3 E: DEVPATH=/devices/system/clockevents/clockevent3 E: SUBSYSTEM=clockevents P: /devices/system/clockevents/clockevent4 E: DEVPATH=/devices/system/clockevents/clockevent4 E: SUBSYSTEM=clockevents P: /devices/system/clockevents/clockevent5 E: DEVPATH=/devices/system/clockevents/clockevent5 E: SUBSYSTEM=clockevents P: /devices/system/clockevents/clockevent6 E: DEVPATH=/devices/system/clockevents/clockevent6 E: SUBSYSTEM=clockevents P: /devices/system/clockevents/clockevent7 E: DEVPATH=/devices/system/clockevents/clockevent7 E: SUBSYSTEM=clockevents P: /devices/system/clocksource/clocksource0 E: DEVPATH=/devices/system/clocksource/clocksource0 E: SUBSYSTEM=clocksource P: /devices/system/cpu/cpu0 E: DEVPATH=/devices/system/cpu/cpu0 E: DRIVER=processor E: MODALIAS=cpu:type:x86,ven0000fam0006mod003A:feature:,0000,0001,0002,0003,0004,0005,0006,0007,0008,0009,000B,000C,000D,000E,000F,0010,0011,0013,0015,0016,0017,0018,0019,001A,001B,001C,001D,001F,002B,0034,003B,003D,0068,006B,006C,006D,006F,0070,0072,0074,0075,0076,0078,007C,007D,0080,0081,0082,0083,0084,0085,0087,0088,0089,008D,008E,008F,0091,0093,0094,0095,0097,0098,0099,009A,009B,009C,009D,009E,00C0,00E0,00E1,00E3,00E5,00E6,00E7,0100,0101,0102,0103,0104,0120,0127,0129,0140 E: SUBSYSTEM=cpu P: /devices/system/cpu/cpu1 E: DEVPATH=/devices/system/cpu/cpu1 E: DRIVER=processor E: MODALIAS=cpu:type:x86,ven0000fam0006mod003A:feature:,0000,0001,0002,0003,0004,0005,0006,0007,0008,0009,000B,000C,000D,000E,000F,0010,0011,0013,0015,0016,0017,0018,0019,001A,001B,001C,001D,001F,002B,0034,003B,003D,0068,006B,006C,006D,006F,0070,0072,0074,0075,0076,0078,007C,007D,0080,0081,0082,0083,0084,0085,0087,0088,0089,008D,008E,008F,0091,0093,0094,0095,0097,0098,0099,009A,009B,009C,009D,009E,00C0,00E0,00E1,00E3,00E5,00E6,00E7,0100,0101,0102,0103,0104,0120,0127,0129,0140 E: SUBSYSTEM=cpu P: /devices/system/cpu/cpu2 E: DEVPATH=/devices/system/cpu/cpu2 E: DRIVER=processor E: MODALIAS=cpu:type:x86,ven0000fam0006mod003A:feature:,0000,0001,0002,0003,0004,0005,0006,0007,0008,0009,000B,000C,000D,000E,000F,0010,0011,0013,0015,0016,0017,0018,0019,001A,001B,001C,001D,001F,002B,0034,003B,003D,0068,006B,006C,006D,006F,0070,0072,0074,0075,0076,0078,007C,007D,0080,0081,0082,0083,0084,0085,0087,0088,0089,008D,008E,008F,0091,0093,0094,0095,0097,0098,0099,009A,009B,009C,009D,009E,00C0,00E0,00E1,00E3,00E5,00E6,00E7,0100,0101,0102,0103,0104,0120,0127,0129,0140 E: SUBSYSTEM=cpu P: /devices/system/cpu/cpu3 E: DEVPATH=/devices/system/cpu/cpu3 E: DRIVER=processor E: MODALIAS=cpu:type:x86,ven0000fam0006mod003A:feature:,0000,0001,0002,0003,0004,0005,0006,0007,0008,0009,000B,000C,000D,000E,000F,0010,0011,0013,0015,0016,0017,0018,0019,001A,001B,001C,001D,001F,002B,0034,003B,003D,0068,006B,006C,006D,006F,0070,0072,0074,0075,0076,0078,007C,007D,0080,0081,0082,0083,0084,0085,0087,0088,0089,008D,008E,008F,0091,0093,0094,0095,0097,0098,0099,009A,009B,009C,009D,009E,00C0,00E0,00E1,00E3,00E5,00E6,00E7,0100,0101,0102,0103,0104,0120,0127,0129,0140 E: SUBSYSTEM=cpu P: /devices/system/machinecheck/machinecheck0 E: DEVPATH=/devices/system/machinecheck/machinecheck0 E: SUBSYSTEM=machinecheck P: /devices/system/machinecheck/machinecheck1 E: DEVPATH=/devices/system/machinecheck/machinecheck1 E: SUBSYSTEM=machinecheck P: /devices/system/machinecheck/machinecheck2 E: DEVPATH=/devices/system/machinecheck/machinecheck2 E: SUBSYSTEM=machinecheck P: /devices/system/machinecheck/machinecheck3 E: DEVPATH=/devices/system/machinecheck/machinecheck3 E: SUBSYSTEM=machinecheck P: /devices/system/memory/memory0 E: DEVPATH=/devices/system/memory/memory0 E: SUBSYSTEM=memory P: /devices/system/memory/memory1 E: DEVPATH=/devices/system/memory/memory1 E: SUBSYSTEM=memory P: /devices/system/memory/memory10 E: DEVPATH=/devices/system/memory/memory10 E: SUBSYSTEM=memory P: /devices/system/memory/memory11 E: DEVPATH=/devices/system/memory/memory11 E: SUBSYSTEM=memory P: /devices/system/memory/memory12 E: DEVPATH=/devices/system/memory/memory12 E: SUBSYSTEM=memory P: /devices/system/memory/memory13 E: DEVPATH=/devices/system/memory/memory13 E: SUBSYSTEM=memory P: /devices/system/memory/memory14 E: DEVPATH=/devices/system/memory/memory14 E: SUBSYSTEM=memory P: /devices/system/memory/memory15 E: DEVPATH=/devices/system/memory/memory15 E: SUBSYSTEM=memory P: /devices/system/memory/memory16 E: DEVPATH=/devices/system/memory/memory16 E: SUBSYSTEM=memory P: /devices/system/memory/memory17 E: DEVPATH=/devices/system/memory/memory17 E: SUBSYSTEM=memory P: /devices/system/memory/memory18 E: DEVPATH=/devices/system/memory/memory18 E: SUBSYSTEM=memory P: /devices/system/memory/memory19 E: DEVPATH=/devices/system/memory/memory19 E: SUBSYSTEM=memory P: /devices/system/memory/memory2 E: DEVPATH=/devices/system/memory/memory2 E: SUBSYSTEM=memory P: /devices/system/memory/memory20 E: DEVPATH=/devices/system/memory/memory20 E: SUBSYSTEM=memory P: /devices/system/memory/memory21 E: DEVPATH=/devices/system/memory/memory21 E: SUBSYSTEM=memory P: /devices/system/memory/memory22 E: DEVPATH=/devices/system/memory/memory22 E: SUBSYSTEM=memory P: /devices/system/memory/memory23 E: DEVPATH=/devices/system/memory/memory23 E: SUBSYSTEM=memory P: /devices/system/memory/memory3 E: DEVPATH=/devices/system/memory/memory3 E: SUBSYSTEM=memory P: /devices/system/memory/memory32 E: DEVPATH=/devices/system/memory/memory32 E: SUBSYSTEM=memory P: /devices/system/memory/memory33 E: DEVPATH=/devices/system/memory/memory33 E: SUBSYSTEM=memory P: /devices/system/memory/memory34 E: DEVPATH=/devices/system/memory/memory34 E: SUBSYSTEM=memory P: /devices/system/memory/memory35 E: DEVPATH=/devices/system/memory/memory35 E: SUBSYSTEM=memory P: /devices/system/memory/memory36 E: DEVPATH=/devices/system/memory/memory36 E: SUBSYSTEM=memory P: /devices/system/memory/memory37 E: DEVPATH=/devices/system/memory/memory37 E: SUBSYSTEM=memory P: /devices/system/memory/memory38 E: DEVPATH=/devices/system/memory/memory38 E: SUBSYSTEM=memory P: /devices/system/memory/memory39 E: DEVPATH=/devices/system/memory/memory39 E: SUBSYSTEM=memory P: /devices/system/memory/memory4 E: DEVPATH=/devices/system/memory/memory4 E: SUBSYSTEM=memory P: /devices/system/memory/memory40 E: DEVPATH=/devices/system/memory/memory40 E: SUBSYSTEM=memory P: /devices/system/memory/memory41 E: DEVPATH=/devices/system/memory/memory41 E: SUBSYSTEM=memory P: /devices/system/memory/memory42 E: DEVPATH=/devices/system/memory/memory42 E: SUBSYSTEM=memory P: /devices/system/memory/memory43 E: DEVPATH=/devices/system/memory/memory43 E: SUBSYSTEM=memory P: /devices/system/memory/memory44 E: DEVPATH=/devices/system/memory/memory44 E: SUBSYSTEM=memory P: /devices/system/memory/memory45 E: DEVPATH=/devices/system/memory/memory45 E: SUBSYSTEM=memory P: /devices/system/memory/memory46 E: DEVPATH=/devices/system/memory/memory46 E: SUBSYSTEM=memory P: /devices/system/memory/memory47 E: DEVPATH=/devices/system/memory/memory47 E: SUBSYSTEM=memory P: /devices/system/memory/memory48 E: DEVPATH=/devices/system/memory/memory48 E: SUBSYSTEM=memory P: /devices/system/memory/memory49 E: DEVPATH=/devices/system/memory/memory49 E: SUBSYSTEM=memory P: /devices/system/memory/memory5 E: DEVPATH=/devices/system/memory/memory5 E: SUBSYSTEM=memory P: /devices/system/memory/memory50 E: DEVPATH=/devices/system/memory/memory50 E: SUBSYSTEM=memory P: /devices/system/memory/memory51 E: DEVPATH=/devices/system/memory/memory51 E: SUBSYSTEM=memory P: /devices/system/memory/memory52 E: DEVPATH=/devices/system/memory/memory52 E: SUBSYSTEM=memory P: /devices/system/memory/memory53 E: DEVPATH=/devices/system/memory/memory53 E: SUBSYSTEM=memory P: /devices/system/memory/memory54 E: DEVPATH=/devices/system/memory/memory54 E: SUBSYSTEM=memory P: /devices/system/memory/memory55 E: DEVPATH=/devices/system/memory/memory55 E: SUBSYSTEM=memory P: /devices/system/memory/memory56 E: DEVPATH=/devices/system/memory/memory56 E: SUBSYSTEM=memory P: /devices/system/memory/memory57 E: DEVPATH=/devices/system/memory/memory57 E: SUBSYSTEM=memory P: /devices/system/memory/memory58 E: DEVPATH=/devices/system/memory/memory58 E: SUBSYSTEM=memory P: /devices/system/memory/memory59 E: DEVPATH=/devices/system/memory/memory59 E: SUBSYSTEM=memory P: /devices/system/memory/memory6 E: DEVPATH=/devices/system/memory/memory6 E: SUBSYSTEM=memory P: /devices/system/memory/memory60 E: DEVPATH=/devices/system/memory/memory60 E: SUBSYSTEM=memory P: /devices/system/memory/memory61 E: DEVPATH=/devices/system/memory/memory61 E: SUBSYSTEM=memory P: /devices/system/memory/memory62 E: DEVPATH=/devices/system/memory/memory62 E: SUBSYSTEM=memory P: /devices/system/memory/memory63 E: DEVPATH=/devices/system/memory/memory63 E: SUBSYSTEM=memory P: /devices/system/memory/memory64 E: DEVPATH=/devices/system/memory/memory64 E: SUBSYSTEM=memory P: /devices/system/memory/memory65 E: DEVPATH=/devices/system/memory/memory65 E: SUBSYSTEM=memory P: /devices/system/memory/memory66 E: DEVPATH=/devices/system/memory/memory66 E: SUBSYSTEM=memory P: /devices/system/memory/memory67 E: DEVPATH=/devices/system/memory/memory67 E: SUBSYSTEM=memory P: /devices/system/memory/memory68 E: DEVPATH=/devices/system/memory/memory68 E: SUBSYSTEM=memory P: /devices/system/memory/memory69 E: DEVPATH=/devices/system/memory/memory69 E: SUBSYSTEM=memory P: /devices/system/memory/memory7 E: DEVPATH=/devices/system/memory/memory7 E: SUBSYSTEM=memory P: /devices/system/memory/memory70 E: DEVPATH=/devices/system/memory/memory70 E: SUBSYSTEM=memory P: /devices/system/memory/memory71 E: DEVPATH=/devices/system/memory/memory71 E: SUBSYSTEM=memory P: /devices/system/memory/memory8 E: DEVPATH=/devices/system/memory/memory8 E: SUBSYSTEM=memory P: /devices/system/memory/memory9 E: DEVPATH=/devices/system/memory/memory9 E: SUBSYSTEM=memory P: /devices/system/node/node0 E: DEVPATH=/devices/system/node/node0 E: SUBSYSTEM=node P: /devices/tracepoint E: DEVPATH=/devices/tracepoint E: SUBSYSTEM=event_source P: /devices/uncore_cbox_0 E: DEVPATH=/devices/uncore_cbox_0 E: SUBSYSTEM=event_source P: /devices/uncore_cbox_1 E: DEVPATH=/devices/uncore_cbox_1 E: SUBSYSTEM=event_source P: /devices/uncore_imc E: DEVPATH=/devices/uncore_imc E: SUBSYSTEM=event_source P: /devices/virtual/bdi/0:40 E: DEVPATH=/devices/virtual/bdi/0:40 E: SUBSYSTEM=bdi P: /devices/virtual/bdi/8:0 E: DEVPATH=/devices/virtual/bdi/8:0 E: SUBSYSTEM=bdi P: /devices/virtual/bdi/btrfs-1 E: DEVPATH=/devices/virtual/bdi/btrfs-1 E: SUBSYSTEM=bdi P: /devices/virtual/bdi/default E: DEVPATH=/devices/virtual/bdi/default E: SUBSYSTEM=bdi P: /devices/virtual/dmi/id E: DEVPATH=/devices/virtual/dmi/id E: MODALIAS=dmi:bvnDellInc.:bvrA10:bd08/28/2013:svnDellInc.:pnXPSL322X:pvr:rvnDellInc.:rn0PJHXN:rvrA00:cvnDellInc.:ct8:cvr0.1: E: SUBSYSTEM=dmi P: /devices/virtual/graphics/fbcon E: DEVPATH=/devices/virtual/graphics/fbcon E: SUBSYSTEM=graphics P: /devices/virtual/input/input14 E: DEVPATH=/devices/virtual/input/input14 E: EV=13 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: KEY=1500b00000000 200300000 0 0 E: MODALIAS=input:b0019v0000p0000e0000-e0,1,4,k94,95,A1,E0,E1,E3,EC,EE,F0,ram4,lsfw E: MSC=10 E: NAME="Dell WMI hotkeys" E: PHYS="wmi/input0" E: PRODUCT=19/0/0/0 E: PROP=0 E: SUBSYSTEM=input E: TAGS=:seat: E: USEC_INITIALIZED=5806 P: /devices/virtual/input/input14/event12 N: input/event12 E: DEVNAME=/dev/input/event12 E: DEVPATH=/devices/virtual/input/input14/event12 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: MAJOR=13 E: MINOR=76 E: SUBSYSTEM=input E: USEC_INITIALIZED=7838 P: /devices/virtual/input/mice N: input/mice E: DEVNAME=/dev/input/mice E: DEVPATH=/devices/virtual/input/mice E: MAJOR=13 E: MINOR=63 E: SUBSYSTEM=input P: /devices/virtual/mem/full N: full E: DEVMODE=0666 E: DEVNAME=/dev/full E: DEVPATH=/devices/virtual/mem/full E: MAJOR=1 E: MINOR=7 E: SUBSYSTEM=mem P: /devices/virtual/mem/kmsg N: kmsg E: DEVMODE=0644 E: DEVNAME=/dev/kmsg E: DEVPATH=/devices/virtual/mem/kmsg E: MAJOR=1 E: MINOR=11 E: SUBSYSTEM=mem P: /devices/virtual/mem/mem N: mem E: DEVNAME=/dev/mem E: DEVPATH=/devices/virtual/mem/mem E: MAJOR=1 E: MINOR=1 E: SUBSYSTEM=mem P: /devices/virtual/mem/null N: null E: DEVMODE=0666 E: DEVNAME=/dev/null E: DEVPATH=/devices/virtual/mem/null E: MAJOR=1 E: MINOR=3 E: SUBSYSTEM=mem P: /devices/virtual/mem/port N: port E: DEVNAME=/dev/port E: DEVPATH=/devices/virtual/mem/port E: MAJOR=1 E: MINOR=4 E: SUBSYSTEM=mem P: /devices/virtual/mem/random N: random E: DEVMODE=0666 E: DEVNAME=/dev/random E: DEVPATH=/devices/virtual/mem/random E: MAJOR=1 E: MINOR=8 E: SUBSYSTEM=mem P: /devices/virtual/mem/urandom N: urandom E: DEVMODE=0666 E: DEVNAME=/dev/urandom E: DEVPATH=/devices/virtual/mem/urandom E: MAJOR=1 E: MINOR=9 E: SUBSYSTEM=mem P: /devices/virtual/mem/zero N: zero E: DEVMODE=0666 E: DEVNAME=/dev/zero E: DEVPATH=/devices/virtual/mem/zero E: MAJOR=1 E: MINOR=5 E: SUBSYSTEM=mem P: /devices/virtual/misc/autofs N: autofs E: DEVNAME=/dev/autofs E: DEVPATH=/devices/virtual/misc/autofs E: MAJOR=10 E: MINOR=235 E: SUBSYSTEM=misc P: /devices/virtual/misc/btrfs-control N: btrfs-control E: DEVNAME=/dev/btrfs-control E: DEVPATH=/devices/virtual/misc/btrfs-control E: MAJOR=10 E: MINOR=234 E: SUBSYSTEM=misc P: /devices/virtual/misc/cpu_dma_latency N: cpu_dma_latency E: DEVNAME=/dev/cpu_dma_latency E: DEVPATH=/devices/virtual/misc/cpu_dma_latency E: MAJOR=10 E: MINOR=62 E: SUBSYSTEM=misc P: /devices/virtual/misc/fuse N: fuse E: DEVNAME=/dev/fuse E: DEVPATH=/devices/virtual/misc/fuse E: MAJOR=10 E: MINOR=229 E: SUBSYSTEM=misc P: /devices/virtual/misc/hpet N: hpet E: DEVNAME=/dev/hpet E: DEVPATH=/devices/virtual/misc/hpet E: MAJOR=10 E: MINOR=228 E: SUBSYSTEM=misc P: /devices/virtual/misc/kvm N: kvm E: DEVNAME=/dev/kvm E: DEVPATH=/devices/virtual/misc/kvm E: MAJOR=10 E: MINOR=232 E: SUBSYSTEM=misc E: TAGS=:seat:uaccess: E: USEC_INITIALIZED=16944 P: /devices/virtual/misc/mcelog N: mcelog E: DEVNAME=/dev/mcelog E: DEVPATH=/devices/virtual/misc/mcelog E: MAJOR=10 E: MINOR=227 E: SUBSYSTEM=misc P: /devices/virtual/misc/memory_bandwidth N: memory_bandwidth E: DEVNAME=/dev/memory_bandwidth E: DEVPATH=/devices/virtual/misc/memory_bandwidth E: MAJOR=10 E: MINOR=59 E: SUBSYSTEM=misc P: /devices/virtual/misc/microcode N: cpu/microcode E: DEVNAME=/dev/cpu/microcode E: DEVPATH=/devices/virtual/misc/microcode E: MAJOR=10 E: MINOR=184 E: SUBSYSTEM=misc P: /devices/virtual/misc/network_latency N: network_latency E: DEVNAME=/dev/network_latency E: DEVPATH=/devices/virtual/misc/network_latency E: MAJOR=10 E: MINOR=61 E: SUBSYSTEM=misc P: /devices/virtual/misc/network_throughput N: network_throughput E: DEVNAME=/dev/network_throughput E: DEVPATH=/devices/virtual/misc/network_throughput E: MAJOR=10 E: MINOR=60 E: SUBSYSTEM=misc P: /devices/virtual/misc/psaux N: psaux E: DEVNAME=/dev/psaux E: DEVPATH=/devices/virtual/misc/psaux E: MAJOR=10 E: MINOR=1 E: SUBSYSTEM=misc P: /devices/virtual/misc/rfkill N: rfkill E: DEVNAME=/dev/rfkill E: DEVPATH=/devices/virtual/misc/rfkill E: MAJOR=10 E: MINOR=56 E: SUBSYSTEM=misc E: TAGS=:seat:uaccess: E: USEC_INITIALIZED=78442 P: /devices/virtual/misc/snapshot N: snapshot E: DEVNAME=/dev/snapshot E: DEVPATH=/devices/virtual/misc/snapshot E: MAJOR=10 E: MINOR=231 E: SUBSYSTEM=misc P: /devices/virtual/misc/vboxdrv N: vboxdrv E: DEVNAME=/dev/vboxdrv E: DEVPATH=/devices/virtual/misc/vboxdrv E: MAJOR=10 E: MINOR=58 E: SUBSYSTEM=misc P: /devices/virtual/misc/vboxdrvu N: vboxdrvu E: DEVNAME=/dev/vboxdrvu E: DEVPATH=/devices/virtual/misc/vboxdrvu E: MAJOR=10 E: MINOR=57 E: SUBSYSTEM=misc P: /devices/virtual/misc/vga_arbiter N: vga_arbiter E: DEVNAME=/dev/vga_arbiter E: DEVPATH=/devices/virtual/misc/vga_arbiter E: MAJOR=10 E: MINOR=63 E: SUBSYSTEM=misc P: /devices/virtual/net/lo E: DEVPATH=/devices/virtual/net/lo E: ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link E: IFINDEX=1 E: INTERFACE=lo E: SUBSYSTEM=net E: USEC_INITIALIZED=38974 P: /devices/virtual/powercap/intel-rapl E: DEVPATH=/devices/virtual/powercap/intel-rapl E: SUBSYSTEM=powercap P: /devices/virtual/powercap/intel-rapl/intel-rapl:0 E: DEVPATH=/devices/virtual/powercap/intel-rapl/intel-rapl:0 E: SUBSYSTEM=powercap P: /devices/virtual/powercap/intel-rapl/intel-rapl:0/intel-rapl:0:0 E: DEVPATH=/devices/virtual/powercap/intel-rapl/intel-rapl:0/intel-rapl:0:0 E: SUBSYSTEM=powercap P: /devices/virtual/powercap/intel-rapl/intel-rapl:0/intel-rapl:0:1 E: DEVPATH=/devices/virtual/powercap/intel-rapl/intel-rapl:0/intel-rapl:0:1 E: SUBSYSTEM=powercap P: /devices/virtual/sound/timer N: snd/timer E: DEVNAME=/dev/snd/timer E: DEVPATH=/devices/virtual/sound/timer E: MAJOR=116 E: MINOR=33 E: SUBSYSTEM=sound E: TAGS=:uaccess: E: USEC_INITIALIZED=76543 P: /devices/virtual/thermal/cooling_device0 E: DEVPATH=/devices/virtual/thermal/cooling_device0 E: SUBSYSTEM=thermal P: /devices/virtual/thermal/cooling_device1 E: DEVPATH=/devices/virtual/thermal/cooling_device1 E: SUBSYSTEM=thermal P: /devices/virtual/thermal/cooling_device2 E: DEVPATH=/devices/virtual/thermal/cooling_device2 E: SUBSYSTEM=thermal P: /devices/virtual/thermal/cooling_device3 E: DEVPATH=/devices/virtual/thermal/cooling_device3 E: SUBSYSTEM=thermal P: /devices/virtual/thermal/cooling_device4 E: DEVPATH=/devices/virtual/thermal/cooling_device4 E: SUBSYSTEM=thermal P: /devices/virtual/thermal/thermal_zone0 E: DEVPATH=/devices/virtual/thermal/thermal_zone0 E: SUBSYSTEM=thermal P: /devices/virtual/thermal/thermal_zone1 E: DEVPATH=/devices/virtual/thermal/thermal_zone1 E: SUBSYSTEM=thermal P: /devices/virtual/thermal/thermal_zone2 E: DEVPATH=/devices/virtual/thermal/thermal_zone2 E: SUBSYSTEM=thermal P: /devices/virtual/tty/console N: console E: DEVNAME=/dev/console E: DEVPATH=/devices/virtual/tty/console E: MAJOR=5 E: MINOR=1 E: SUBSYSTEM=tty P: /devices/virtual/tty/ptmx N: ptmx E: DEVMODE=0666 E: DEVNAME=/dev/ptmx E: DEVPATH=/devices/virtual/tty/ptmx E: MAJOR=5 E: MINOR=2 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty N: tty E: DEVMODE=0666 E: DEVNAME=/dev/tty E: DEVPATH=/devices/virtual/tty/tty E: MAJOR=5 E: MINOR=0 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty0 N: tty0 E: DEVNAME=/dev/tty0 E: DEVPATH=/devices/virtual/tty/tty0 E: MAJOR=4 E: MINOR=0 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty1 N: tty1 E: DEVNAME=/dev/tty1 E: DEVPATH=/devices/virtual/tty/tty1 E: MAJOR=4 E: MINOR=1 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty10 N: tty10 E: DEVNAME=/dev/tty10 E: DEVPATH=/devices/virtual/tty/tty10 E: MAJOR=4 E: MINOR=10 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty11 N: tty11 E: DEVNAME=/dev/tty11 E: DEVPATH=/devices/virtual/tty/tty11 E: MAJOR=4 E: MINOR=11 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty12 N: tty12 E: DEVNAME=/dev/tty12 E: DEVPATH=/devices/virtual/tty/tty12 E: MAJOR=4 E: MINOR=12 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty13 N: tty13 E: DEVNAME=/dev/tty13 E: DEVPATH=/devices/virtual/tty/tty13 E: MAJOR=4 E: MINOR=13 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty14 N: tty14 E: DEVNAME=/dev/tty14 E: DEVPATH=/devices/virtual/tty/tty14 E: MAJOR=4 E: MINOR=14 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty15 N: tty15 E: DEVNAME=/dev/tty15 E: DEVPATH=/devices/virtual/tty/tty15 E: MAJOR=4 E: MINOR=15 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty16 N: tty16 E: DEVNAME=/dev/tty16 E: DEVPATH=/devices/virtual/tty/tty16 E: MAJOR=4 E: MINOR=16 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty17 N: tty17 E: DEVNAME=/dev/tty17 E: DEVPATH=/devices/virtual/tty/tty17 E: MAJOR=4 E: MINOR=17 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty18 N: tty18 E: DEVNAME=/dev/tty18 E: DEVPATH=/devices/virtual/tty/tty18 E: MAJOR=4 E: MINOR=18 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty19 N: tty19 E: DEVNAME=/dev/tty19 E: DEVPATH=/devices/virtual/tty/tty19 E: MAJOR=4 E: MINOR=19 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty2 N: tty2 E: DEVNAME=/dev/tty2 E: DEVPATH=/devices/virtual/tty/tty2 E: MAJOR=4 E: MINOR=2 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty20 N: tty20 E: DEVNAME=/dev/tty20 E: DEVPATH=/devices/virtual/tty/tty20 E: MAJOR=4 E: MINOR=20 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty21 N: tty21 E: DEVNAME=/dev/tty21 E: DEVPATH=/devices/virtual/tty/tty21 E: MAJOR=4 E: MINOR=21 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty22 N: tty22 E: DEVNAME=/dev/tty22 E: DEVPATH=/devices/virtual/tty/tty22 E: MAJOR=4 E: MINOR=22 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty23 N: tty23 E: DEVNAME=/dev/tty23 E: DEVPATH=/devices/virtual/tty/tty23 E: MAJOR=4 E: MINOR=23 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty24 N: tty24 E: DEVNAME=/dev/tty24 E: DEVPATH=/devices/virtual/tty/tty24 E: MAJOR=4 E: MINOR=24 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty25 N: tty25 E: DEVNAME=/dev/tty25 E: DEVPATH=/devices/virtual/tty/tty25 E: MAJOR=4 E: MINOR=25 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty26 N: tty26 E: DEVNAME=/dev/tty26 E: DEVPATH=/devices/virtual/tty/tty26 E: MAJOR=4 E: MINOR=26 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty27 N: tty27 E: DEVNAME=/dev/tty27 E: DEVPATH=/devices/virtual/tty/tty27 E: MAJOR=4 E: MINOR=27 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty28 N: tty28 E: DEVNAME=/dev/tty28 E: DEVPATH=/devices/virtual/tty/tty28 E: MAJOR=4 E: MINOR=28 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty29 N: tty29 E: DEVNAME=/dev/tty29 E: DEVPATH=/devices/virtual/tty/tty29 E: MAJOR=4 E: MINOR=29 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty3 N: tty3 E: DEVNAME=/dev/tty3 E: DEVPATH=/devices/virtual/tty/tty3 E: MAJOR=4 E: MINOR=3 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty30 N: tty30 E: DEVNAME=/dev/tty30 E: DEVPATH=/devices/virtual/tty/tty30 E: MAJOR=4 E: MINOR=30 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty31 N: tty31 E: DEVNAME=/dev/tty31 E: DEVPATH=/devices/virtual/tty/tty31 E: MAJOR=4 E: MINOR=31 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty32 N: tty32 E: DEVNAME=/dev/tty32 E: DEVPATH=/devices/virtual/tty/tty32 E: MAJOR=4 E: MINOR=32 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty33 N: tty33 E: DEVNAME=/dev/tty33 E: DEVPATH=/devices/virtual/tty/tty33 E: MAJOR=4 E: MINOR=33 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty34 N: tty34 E: DEVNAME=/dev/tty34 E: DEVPATH=/devices/virtual/tty/tty34 E: MAJOR=4 E: MINOR=34 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty35 N: tty35 E: DEVNAME=/dev/tty35 E: DEVPATH=/devices/virtual/tty/tty35 E: MAJOR=4 E: MINOR=35 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty36 N: tty36 E: DEVNAME=/dev/tty36 E: DEVPATH=/devices/virtual/tty/tty36 E: MAJOR=4 E: MINOR=36 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty37 N: tty37 E: DEVNAME=/dev/tty37 E: DEVPATH=/devices/virtual/tty/tty37 E: MAJOR=4 E: MINOR=37 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty38 N: tty38 E: DEVNAME=/dev/tty38 E: DEVPATH=/devices/virtual/tty/tty38 E: MAJOR=4 E: MINOR=38 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty39 N: tty39 E: DEVNAME=/dev/tty39 E: DEVPATH=/devices/virtual/tty/tty39 E: MAJOR=4 E: MINOR=39 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty4 N: tty4 E: DEVNAME=/dev/tty4 E: DEVPATH=/devices/virtual/tty/tty4 E: MAJOR=4 E: MINOR=4 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty40 N: tty40 E: DEVNAME=/dev/tty40 E: DEVPATH=/devices/virtual/tty/tty40 E: MAJOR=4 E: MINOR=40 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty41 N: tty41 E: DEVNAME=/dev/tty41 E: DEVPATH=/devices/virtual/tty/tty41 E: MAJOR=4 E: MINOR=41 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty42 N: tty42 E: DEVNAME=/dev/tty42 E: DEVPATH=/devices/virtual/tty/tty42 E: MAJOR=4 E: MINOR=42 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty43 N: tty43 E: DEVNAME=/dev/tty43 E: DEVPATH=/devices/virtual/tty/tty43 E: MAJOR=4 E: MINOR=43 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty44 N: tty44 E: DEVNAME=/dev/tty44 E: DEVPATH=/devices/virtual/tty/tty44 E: MAJOR=4 E: MINOR=44 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty45 N: tty45 E: DEVNAME=/dev/tty45 E: DEVPATH=/devices/virtual/tty/tty45 E: MAJOR=4 E: MINOR=45 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty46 N: tty46 E: DEVNAME=/dev/tty46 E: DEVPATH=/devices/virtual/tty/tty46 E: MAJOR=4 E: MINOR=46 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty47 N: tty47 E: DEVNAME=/dev/tty47 E: DEVPATH=/devices/virtual/tty/tty47 E: MAJOR=4 E: MINOR=47 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty48 N: tty48 E: DEVNAME=/dev/tty48 E: DEVPATH=/devices/virtual/tty/tty48 E: MAJOR=4 E: MINOR=48 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty49 N: tty49 E: DEVNAME=/dev/tty49 E: DEVPATH=/devices/virtual/tty/tty49 E: MAJOR=4 E: MINOR=49 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty5 N: tty5 E: DEVNAME=/dev/tty5 E: DEVPATH=/devices/virtual/tty/tty5 E: MAJOR=4 E: MINOR=5 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty50 N: tty50 E: DEVNAME=/dev/tty50 E: DEVPATH=/devices/virtual/tty/tty50 E: MAJOR=4 E: MINOR=50 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty51 N: tty51 E: DEVNAME=/dev/tty51 E: DEVPATH=/devices/virtual/tty/tty51 E: MAJOR=4 E: MINOR=51 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty52 N: tty52 E: DEVNAME=/dev/tty52 E: DEVPATH=/devices/virtual/tty/tty52 E: MAJOR=4 E: MINOR=52 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty53 N: tty53 E: DEVNAME=/dev/tty53 E: DEVPATH=/devices/virtual/tty/tty53 E: MAJOR=4 E: MINOR=53 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty54 N: tty54 E: DEVNAME=/dev/tty54 E: DEVPATH=/devices/virtual/tty/tty54 E: MAJOR=4 E: MINOR=54 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty55 N: tty55 E: DEVNAME=/dev/tty55 E: DEVPATH=/devices/virtual/tty/tty55 E: MAJOR=4 E: MINOR=55 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty56 N: tty56 E: DEVNAME=/dev/tty56 E: DEVPATH=/devices/virtual/tty/tty56 E: MAJOR=4 E: MINOR=56 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty57 N: tty57 E: DEVNAME=/dev/tty57 E: DEVPATH=/devices/virtual/tty/tty57 E: MAJOR=4 E: MINOR=57 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty58 N: tty58 E: DEVNAME=/dev/tty58 E: DEVPATH=/devices/virtual/tty/tty58 E: MAJOR=4 E: MINOR=58 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty59 N: tty59 E: DEVNAME=/dev/tty59 E: DEVPATH=/devices/virtual/tty/tty59 E: MAJOR=4 E: MINOR=59 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty6 N: tty6 E: DEVNAME=/dev/tty6 E: DEVPATH=/devices/virtual/tty/tty6 E: MAJOR=4 E: MINOR=6 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty60 N: tty60 E: DEVNAME=/dev/tty60 E: DEVPATH=/devices/virtual/tty/tty60 E: MAJOR=4 E: MINOR=60 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty61 N: tty61 E: DEVNAME=/dev/tty61 E: DEVPATH=/devices/virtual/tty/tty61 E: MAJOR=4 E: MINOR=61 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty62 N: tty62 E: DEVNAME=/dev/tty62 E: DEVPATH=/devices/virtual/tty/tty62 E: MAJOR=4 E: MINOR=62 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty63 N: tty63 E: DEVNAME=/dev/tty63 E: DEVPATH=/devices/virtual/tty/tty63 E: MAJOR=4 E: MINOR=63 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty7 N: tty7 E: DEVNAME=/dev/tty7 E: DEVPATH=/devices/virtual/tty/tty7 E: MAJOR=4 E: MINOR=7 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty8 N: tty8 E: DEVNAME=/dev/tty8 E: DEVPATH=/devices/virtual/tty/tty8 E: MAJOR=4 E: MINOR=8 E: SUBSYSTEM=tty P: /devices/virtual/tty/tty9 N: tty9 E: DEVNAME=/dev/tty9 E: DEVPATH=/devices/virtual/tty/tty9 E: MAJOR=4 E: MINOR=9 E: SUBSYSTEM=tty P: /devices/virtual/vc/vcs N: vcs E: DEVNAME=/dev/vcs E: DEVPATH=/devices/virtual/vc/vcs E: MAJOR=7 E: MINOR=0 E: SUBSYSTEM=vc P: /devices/virtual/vc/vcs1 N: vcs1 E: DEVNAME=/dev/vcs1 E: DEVPATH=/devices/virtual/vc/vcs1 E: MAJOR=7 E: MINOR=1 E: SUBSYSTEM=vc P: /devices/virtual/vc/vcs2 N: vcs2 E: DEVNAME=/dev/vcs2 E: DEVPATH=/devices/virtual/vc/vcs2 E: MAJOR=7 E: MINOR=2 E: SUBSYSTEM=vc P: /devices/virtual/vc/vcs3 N: vcs3 E: DEVNAME=/dev/vcs3 E: DEVPATH=/devices/virtual/vc/vcs3 E: MAJOR=7 E: MINOR=3 E: SUBSYSTEM=vc P: /devices/virtual/vc/vcs4 N: vcs4 E: DEVNAME=/dev/vcs4 E: DEVPATH=/devices/virtual/vc/vcs4 E: MAJOR=7 E: MINOR=4 E: SUBSYSTEM=vc P: /devices/virtual/vc/vcs5 N: vcs5 E: DEVNAME=/dev/vcs5 E: DEVPATH=/devices/virtual/vc/vcs5 E: MAJOR=7 E: MINOR=5 E: SUBSYSTEM=vc P: /devices/virtual/vc/vcs6 N: vcs6 E: DEVNAME=/dev/vcs6 E: DEVPATH=/devices/virtual/vc/vcs6 E: MAJOR=7 E: MINOR=6 E: SUBSYSTEM=vc P: /devices/virtual/vc/vcsa N: vcsa E: DEVNAME=/dev/vcsa E: DEVPATH=/devices/virtual/vc/vcsa E: MAJOR=7 E: MINOR=128 E: SUBSYSTEM=vc P: /devices/virtual/vc/vcsa1 N: vcsa1 E: DEVNAME=/dev/vcsa1 E: DEVPATH=/devices/virtual/vc/vcsa1 E: MAJOR=7 E: MINOR=129 E: SUBSYSTEM=vc P: /devices/virtual/vc/vcsa2 N: vcsa2 E: DEVNAME=/dev/vcsa2 E: DEVPATH=/devices/virtual/vc/vcsa2 E: MAJOR=7 E: MINOR=130 E: SUBSYSTEM=vc P: /devices/virtual/vc/vcsa3 N: vcsa3 E: DEVNAME=/dev/vcsa3 E: DEVPATH=/devices/virtual/vc/vcsa3 E: MAJOR=7 E: MINOR=131 E: SUBSYSTEM=vc P: /devices/virtual/vc/vcsa4 N: vcsa4 E: DEVNAME=/dev/vcsa4 E: DEVPATH=/devices/virtual/vc/vcsa4 E: MAJOR=7 E: MINOR=132 E: SUBSYSTEM=vc P: /devices/virtual/vc/vcsa5 N: vcsa5 E: DEVNAME=/dev/vcsa5 E: DEVPATH=/devices/virtual/vc/vcsa5 E: MAJOR=7 E: MINOR=133 E: SUBSYSTEM=vc P: /devices/virtual/vc/vcsa6 N: vcsa6 E: DEVNAME=/dev/vcsa6 E: DEVPATH=/devices/virtual/vc/vcsa6 E: MAJOR=7 E: MINOR=134 E: SUBSYSTEM=vc P: /devices/virtual/vtconsole/vtcon0 E: DEVPATH=/devices/virtual/vtconsole/vtcon0 E: SUBSYSTEM=vtconsole P: /devices/virtual/vtconsole/vtcon1 E: DEVPATH=/devices/virtual/vtconsole/vtcon1 E: SUBSYSTEM=vtconsole P: /devices/virtual/wmi/05901221-D566-11D1-B2F0-00A0C9062910 E: DEVPATH=/devices/virtual/wmi/05901221-D566-11D1-B2F0-00A0C9062910 E: MODALIAS=wmi:05901221-D566-11D1-B2F0-00A0C9062910 E: SUBSYSTEM=wmi P: /devices/virtual/wmi/2FAE25E0-C342-4F49-AD2F-0F06A958721A E: DEVPATH=/devices/virtual/wmi/2FAE25E0-C342-4F49-AD2F-0F06A958721A E: MODALIAS=wmi:2FAE25E0-C342-4F49-AD2F-0F06A958721A E: SUBSYSTEM=wmi P: /devices/virtual/wmi/72E6BB2F-8380-46B2-9A9F-6D3F513223E7 E: DEVPATH=/devices/virtual/wmi/72E6BB2F-8380-46B2-9A9F-6D3F513223E7 E: MODALIAS=wmi:72E6BB2F-8380-46B2-9A9F-6D3F513223E7 E: SUBSYSTEM=wmi P: /devices/virtual/wmi/8D9DDCBC-A997-11DA-B012-B622A1EF5492 E: DEVPATH=/devices/virtual/wmi/8D9DDCBC-A997-11DA-B012-B622A1EF5492 E: MODALIAS=wmi:8D9DDCBC-A997-11DA-B012-B622A1EF5492 E: SUBSYSTEM=wmi P: /devices/virtual/wmi/9DBB5994-A997-11DA-B012-B622A1EF5492 E: DEVPATH=/devices/virtual/wmi/9DBB5994-A997-11DA-B012-B622A1EF5492 E: MODALIAS=wmi:9DBB5994-A997-11DA-B012-B622A1EF5492 E: SUBSYSTEM=wmi P: /devices/virtual/wmi/A3776CE0-1E88-11DB-A98B-0800200C9A66 E: DEVPATH=/devices/virtual/wmi/A3776CE0-1E88-11DB-A98B-0800200C9A66 E: MODALIAS=wmi:A3776CE0-1E88-11DB-A98B-0800200C9A66 E: SUBSYSTEM=wmi P: /devices/virtual/wmi/A80593CE-A997-11DA-B012-B622A1EF5492 E: DEVPATH=/devices/virtual/wmi/A80593CE-A997-11DA-B012-B622A1EF5492 E: MODALIAS=wmi:A80593CE-A997-11DA-B012-B622A1EF5492 E: SUBSYSTEM=wmi P: /devices/virtual/wmi/DD8C7670-1CB5-11DB-A98B-669A0C200008 E: DEVPATH=/devices/virtual/wmi/DD8C7670-1CB5-11DB-A98B-669A0C200008 E: MODALIAS=wmi:DD8C7670-1CB5-11DB-A98B-669A0C200008 E: SUBSYSTEM=wmi P: /devices/virtual/workqueue/writeback E: DEVPATH=/devices/virtual/workqueue/writeback E: SUBSYSTEM=workqueue ----- udevinfo end ----- /devices/LNXSYSTM:00 /devices/LNXSYSTM:00/LNXCPU:00 /devices/LNXSYSTM:00/LNXCPU:01 /devices/LNXSYSTM:00/LNXCPU:02 /devices/LNXSYSTM:00/LNXCPU:03 /devices/LNXSYSTM:00/LNXCPU:04 /devices/LNXSYSTM:00/LNXCPU:05 /devices/LNXSYSTM:00/LNXCPU:06 /devices/LNXSYSTM:00/LNXCPU:07 /devices/LNXSYSTM:00/LNXPWRBN:00 /devices/LNXSYSTM:00/LNXPWRBN:00/input/input3 /devices/LNXSYSTM:00/LNXPWRBN:00/input/input3/event3 name: /dev/input/event3 /devices/LNXSYSTM:00/LNXSYBUS:00 /devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00 /devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ADP0 /devices/LNXSYSTM:00/LNXSYBUS:00/INT33A0:00 /devices/LNXSYSTM:00/LNXSYBUS:00/INT340E:00 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/device:2c /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/device:2d /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/device:2e /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/device:2f /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/device:30 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/device:31 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/device:32 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/device:33 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input4 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input4/event4 name: /dev/input/event4 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/PNP0C02:01 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/ATM1200:00 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/DLL058B:00 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/INT3F0D:00 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/MSFT0001:00 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0000:00 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0100:00 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0103:00 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0200:00 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0B00:00 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0C02:00 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0C04:00 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0C09:00 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0C09:00/ACPI0008:00 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0C31:00 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0C32:00 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02/device:03 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02/device:03/device:04 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02/device:03/device:04/device:05 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02/device:03/device:04/device:06 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02/device:03/device:04/device:07 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02/device:03/device:04/device:08 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02/device:03/device:04/device:09 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02/device:03/device:04/device:0a /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02/device:03/device:04/device:0b /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02/device:03/device:04/device:0c /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0d /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0d/device:0e /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0d/device:0e/device:0f /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0d/device:0e/device:0f/device:10 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0d/device:0e/device:0f/device:11 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0d/device:0e/device:0f/device:12 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0d/device:0e/device:0f/device:13 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0d/device:0e/device:0f/device:14 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0d/device:0e/device:0f/device:14/device:15 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0d/device:0e/device:0f/device:16 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:17 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:17/device:18 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:17/device:18/device:19 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:17/device:18/device:1a /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:17/device:18/device:1b /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:17/device:18/device:1c /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:17/device:18/device:1d /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:17/device:18/device:1e /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:17/device:18/device:1f /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:17/device:18/device:20 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:21 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:22 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:22/device:23 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:24 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:24/device:25 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:24/device:26 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:27 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:27/device:28 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:27/device:29 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:2a /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:2b /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C01:00 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0/event0 name: /dev/input/event0 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/input/input2 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/input/input2/event2 name: /dev/input/event2 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input1 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input1/event1 name: /dev/input/event1 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:00 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:01 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:02 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:03 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:04 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:05 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:06 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:07 /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C14:00 /devices/LNXSYSTM:00/LNXSYBUS:01 /devices/LNXSYSTM:00/LNXSYBUS:01/LNXTHERM:00 /devices/LNXSYSTM:00/LNXSYBUS:01/LNXTHERM:01 /devices/breakpoint /devices/cpu /devices/pci0000:00/0000:00:00.0 /devices/pci0000:00/0000:00:02.0 /devices/pci0000:00/0000:00:02.0/drm/card0 name: /dev/dri/card0 /devices/pci0000:00/0000:00:02.0/drm/card0/card0-DP-1 /devices/pci0000:00/0000:00:02.0/drm/card0/card0-HDMI-A-1 /devices/pci0000:00/0000:00:02.0/drm/card0/card0-VGA-1 /devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1 /devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/intel_backlight /devices/pci0000:00/0000:00:02.0/drm/controlD64 name: /dev/dri/controlD64 /devices/pci0000:00/0000:00:02.0/drm/renderD128 name: /dev/dri/renderD128 /devices/pci0000:00/0000:00:02.0/graphics/fb0 name: /dev/fb0 /devices/pci0000:00/0000:00:02.0/i2c-0 /devices/pci0000:00/0000:00:02.0/i2c-1 /devices/pci0000:00/0000:00:02.0/i2c-2 /devices/pci0000:00/0000:00:02.0/i2c-3 /devices/pci0000:00/0000:00:02.0/i2c-4 /devices/pci0000:00/0000:00:02.0/i2c-5 /devices/pci0000:00/0000:00:02.0/i2c-6 /devices/pci0000:00/0000:00:02.0/i2c-7 /devices/pci0000:00/0000:00:14.0 /devices/pci0000:00/0000:00:14.0/usb1 name: /dev/bus/usb/001/001 /devices/pci0000:00/0000:00:14.0/usb1/1-0:1.0 /devices/pci0000:00/0000:00:14.0/usb2 name: /dev/bus/usb/002/001 /devices/pci0000:00/0000:00:14.0/usb2/2-0:1.0 /devices/pci0000:00/0000:00:16.0 /devices/pci0000:00/0000:00:16.0/mei/mei0 name: /dev/mei0 /devices/pci0000:00/0000:00:1a.0 /devices/pci0000:00/0000:00:1a.0/usb3 name: /dev/bus/usb/003/001 /devices/pci0000:00/0000:00:1a.0/usb3/3-0:1.0 /devices/pci0000:00/0000:00:1a.0/usb3/3-1 name: /dev/bus/usb/003/002 /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5 name: /dev/bus/usb/003/003 /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5/3-1.5:1.0 /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5/3-1.5:1.0/input/input13 /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5/3-1.5:1.0/input/input13/event11 name: /dev/input/event11 links: /dev/input/by-id/usb-CN01RH717248726AD005A00_Laptop_Integrated_Webcam_1.3M-event-if00, /dev/input/by-path/pci-0000:00:1a.0-usb-0:1.5:1.0-event /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5/3-1.5:1.0/media0 name: /dev/media0 /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5/3-1.5:1.0/video4linux/video0 name: /dev/video0 links: /dev/v4l/by-id/usb-CN01RH717248726AD005A00_Laptop_Integrated_Webcam_1.3M-video-index0, /dev/v4l/by-path/pci-0000:00:1a.0-usb-0:1.5:1.0-video-index0 /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5/3-1.5:1.1 /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1:1.0 /devices/pci0000:00/0000:00:1b.0 /devices/pci0000:00/0000:00:1b.0/sound/card0 /devices/pci0000:00/0000:00:1b.0/sound/card0/hdaudioC0D0 /devices/pci0000:00/0000:00:1b.0/sound/card0/hdaudioC0D0/hwC0D0 name: /dev/snd/hwC0D0 /devices/pci0000:00/0000:00:1b.0/sound/card0/hdaudioC0D0/input8 /devices/pci0000:00/0000:00:1b.0/sound/card0/hdaudioC0D0/input8/event7 name: /dev/input/event7 /devices/pci0000:00/0000:00:1b.0/sound/card0/hdaudioC0D0/pcmC0D0c name: /dev/snd/pcmC0D0c /devices/pci0000:00/0000:00:1b.0/sound/card0/hdaudioC0D0/pcmC0D0p name: /dev/snd/pcmC0D0p /devices/pci0000:00/0000:00:1b.0/sound/card0/hdaudioC0D3 /devices/pci0000:00/0000:00:1b.0/sound/card0/hdaudioC0D3/hwC0D3 name: /dev/snd/hwC0D3 /devices/pci0000:00/0000:00:1b.0/sound/card0/hdaudioC0D3/pcmC0D3p name: /dev/snd/pcmC0D3p /devices/pci0000:00/0000:00:1b.0/sound/card0/input10 /devices/pci0000:00/0000:00:1b.0/sound/card0/input10/event8 name: /dev/input/event8 /devices/pci0000:00/0000:00:1b.0/sound/card0/input11 /devices/pci0000:00/0000:00:1b.0/sound/card0/input11/event9 name: /dev/input/event9 /devices/pci0000:00/0000:00:1b.0/sound/card0/input12 /devices/pci0000:00/0000:00:1b.0/sound/card0/input12/event10 name: /dev/input/event10 /devices/pci0000:00/0000:00:1b.0/sound/card0/controlC0 name: /dev/snd/controlC0 links: /dev/snd/by-path/pci-0000:00:1b.0 /devices/pci0000:00/0000:00:1c.0 /devices/pci0000:00/0000:00:1c.0/0000:01:00.0 /devices/pci0000:00/0000:00:1c.0/0000:01:00.0/ieee80211/phy0 /devices/pci0000:00/0000:00:1c.0/0000:01:00.0/ieee80211/phy0/rfkill1 /devices/pci0000:00/0000:00:1c.0/0000:01:00.0/leds/phy0-led /devices/pci0000:00/0000:00:1c.0/0000:01:00.0/net/wlp1s0 /devices/pci0000:00/0000:00:1c.0/pci_bus/0000:01 /devices/pci0000:00/0000:00:1d.0 /devices/pci0000:00/0000:00:1d.0/usb4 name: /dev/bus/usb/004/001 /devices/pci0000:00/0000:00:1d.0/usb4/4-0:1.0 /devices/pci0000:00/0000:00:1d.0/usb4/4-1 name: /dev/bus/usb/004/002 /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5 name: /dev/bus/usb/004/003 /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5:1.0 /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5:1.0/bluetooth/hci0 /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5:1.0/bluetooth/hci0/rfkill0 /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5:1.1 /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1:1.0 /devices/pci0000:00/0000:00:1f.0 /devices/pci0000:00/0000:00:1f.0/PNP0103:00 /devices/pci0000:00/0000:00:1f.0/PNP0C04:00 /devices/pci0000:00/0000:00:1f.0/PNP0C09:00 /devices/pci0000:00/0000:00:1f.0/PNP0C09:00/ACPI0008:00 /devices/pci0000:00/0000:00:1f.0/PNP0C32:00 /devices/pci0000:00/0000:00:1f.0/iTCO_wdt /devices/pci0000:00/0000:00:1f.0/iTCO_wdt/misc/watchdog name: /dev/watchdog /devices/pci0000:00/0000:00:1f.0/iTCO_wdt/watchdog/watchdog0 name: /dev/watchdog0 /devices/pci0000:00/0000:00:1f.2 /devices/pci0000:00/0000:00:1f.2/ata1/ata_port/ata1 /devices/pci0000:00/0000:00:1f.2/ata1/host0 /devices/pci0000:00/0000:00:1f.2/ata1/host0/scsi_host/host0 /devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0 /devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0 /devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda name: /dev/sda links: /dev/disk/by-id/ata-SAMSUNG_SSD_PM830_mSATA_256GB_S0XPNYAD800120, /dev/disk/by-id/wwn-0x5002538043584d30 /devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda1 name: /dev/sda1 links: /dev/disk/by-id/ata-SAMSUNG_SSD_PM830_mSATA_256GB_S0XPNYAD800120-part1, /dev/disk/by-id/wwn-0x5002538043584d30-part1, /dev/disk/by-partlabel/EFI\x20System, /dev/disk/by-partuuid/67630c1f-875f-426b-9b9d-304defb1ee0c, /dev/disk/by-uuid/2A36-307B /devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda2 name: /dev/sda2 links: /dev/disk/by-id/ata-SAMSUNG_SSD_PM830_mSATA_256GB_S0XPNYAD800120-part2, /dev/disk/by-id/wwn-0x5002538043584d30-part2, /dev/disk/by-label/swap, /dev/disk/by-partlabel/Linux\x20swap, /dev/disk/by-partuuid/1662cc5b-029c-42b3-a57a-073d8b39d811, /dev/disk/by-uuid/7ddaaa70-9c0e-4b06-b76f-57f9544123d1 /devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda3 name: /dev/sda3 links: /dev/disk/by-id/ata-SAMSUNG_SSD_PM830_mSATA_256GB_S0XPNYAD800120-part3, /dev/disk/by-id/wwn-0x5002538043584d30-part3, /dev/disk/by-label/arch, /dev/disk/by-partlabel/Linux\x20filesystem, /dev/disk/by-partuuid/3bbf948c-a68f-4193-92be-de9099dd9914, /dev/disk/by-uuid/ffca0b5e-a0d9-41e3-9aa4-20650ff12119 /devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/bsg/0:0:0:0 name: /dev/bsg/0:0:0:0 /devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/scsi_device/0:0:0:0 /devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/scsi_disk/0:0:0:0 /devices/pci0000:00/0000:00:1f.2/ata1/link1/ata_link/link1 /devices/pci0000:00/0000:00:1f.2/ata1/link1/dev1.0/ata_device/dev1.0 /devices/pci0000:00/0000:00:1f.2/ata2/ata_port/ata2 /devices/pci0000:00/0000:00:1f.2/ata2/host1 /devices/pci0000:00/0000:00:1f.2/ata2/host1/scsi_host/host1 /devices/pci0000:00/0000:00:1f.2/ata2/link2/ata_link/link2 /devices/pci0000:00/0000:00:1f.2/ata2/link2/dev2.0/ata_device/dev2.0 /devices/pci0000:00/0000:00:1f.2/ata3/ata_port/ata3 /devices/pci0000:00/0000:00:1f.2/ata3/host2 /devices/pci0000:00/0000:00:1f.2/ata3/host2/scsi_host/host2 /devices/pci0000:00/0000:00:1f.2/ata3/link3/ata_link/link3 /devices/pci0000:00/0000:00:1f.2/ata3/link3/dev3.0/ata_device/dev3.0 /devices/pci0000:00/0000:00:1f.2/ata4/ata_port/ata4 /devices/pci0000:00/0000:00:1f.2/ata4/host3 /devices/pci0000:00/0000:00:1f.2/ata4/host3/scsi_host/host3 /devices/pci0000:00/0000:00:1f.2/ata4/link4/ata_link/link4 /devices/pci0000:00/0000:00:1f.2/ata4/link4/dev4.0/ata_device/dev4.0 /devices/pci0000:00/0000:00:1f.2/ata5/ata_port/ata5 /devices/pci0000:00/0000:00:1f.2/ata5/host4 /devices/pci0000:00/0000:00:1f.2/ata5/host4/scsi_host/host4 /devices/pci0000:00/0000:00:1f.2/ata5/link5/ata_link/link5 /devices/pci0000:00/0000:00:1f.2/ata5/link5/dev5.0/ata_device/dev5.0 /devices/pci0000:00/0000:00:1f.2/ata6/ata_port/ata6 /devices/pci0000:00/0000:00:1f.2/ata6/host5 /devices/pci0000:00/0000:00:1f.2/ata6/host5/scsi_host/host5 /devices/pci0000:00/0000:00:1f.2/ata6/link6/ata_link/link6 /devices/pci0000:00/0000:00:1f.2/ata6/link6/dev6.0/ata_device/dev6.0 /devices/pci0000:00/0000:00:1f.3 /devices/pci0000:00/pci_bus/0000:00 /devices/platform/ACPI0003:00 /devices/platform/INT33A0:00 /devices/platform/PNP0C0A:00 /devices/platform/PNP0C0C:00 /devices/platform/PNP0C0D:00 /devices/platform/PNP0C0E:00 /devices/platform/PNP0C14:00 /devices/platform/alarmtimer /devices/platform/coretemp.0 /devices/platform/coretemp.0/hwmon/hwmon0 /devices/platform/dcdbas /devices/platform/dell-laptop /devices/platform/efi-framebuffer.0 /devices/platform/i8042 /devices/platform/i8042/serio0 /devices/platform/i8042/serio0/input/input5 /devices/platform/i8042/serio0/input/input5/event5 name: /dev/input/event5 links: /dev/input/by-path/platform-i8042-serio-0-event-kbd /devices/platform/i8042/serio1 /devices/platform/i8042/serio1/input/input9 /devices/platform/i8042/serio1/input/input9/event13 name: /dev/input/event13 links: /dev/input/by-path/platform-i8042-serio-1-event-mouse /devices/platform/i8042/serio1/input/input9/mouse0 name: /dev/input/mouse0 links: /dev/input/by-path/platform-i8042-serio-1-mouse /devices/platform/microcode /devices/platform/pcspkr /devices/platform/pcspkr/input/input7 /devices/platform/pcspkr/input/input7/event6 name: /dev/input/event6 links: /dev/input/by-path/platform-pcspkr-event-spkr /devices/platform/regulatory.0 /devices/platform/serial8250 /devices/platform/serial8250/tty/ttyS0 name: /dev/ttyS0 /devices/platform/serial8250/tty/ttyS1 name: /dev/ttyS1 /devices/platform/serial8250/tty/ttyS2 name: /dev/ttyS2 /devices/platform/serial8250/tty/ttyS3 name: /dev/ttyS3 /devices/platform/vboxdrv.0 /devices/pnp0/00:00 /devices/pnp0/00:01 /devices/pnp0/00:01/rtc/rtc0 name: /dev/rtc0 links: /dev/rtc /devices/pnp0/00:02 /devices/pnp0/00:03 /devices/pnp0/00:04 /devices/pnp0/00:05 /devices/power /devices/software /devices/system/clockevents/broadcast /devices/system/clockevents/clockevent0 /devices/system/clockevents/clockevent1 /devices/system/clockevents/clockevent2 /devices/system/clockevents/clockevent3 /devices/system/clockevents/clockevent4 /devices/system/clockevents/clockevent5 /devices/system/clockevents/clockevent6 /devices/system/clockevents/clockevent7 /devices/system/clocksource/clocksource0 /devices/system/cpu/cpu0 /devices/system/cpu/cpu1 /devices/system/cpu/cpu2 /devices/system/cpu/cpu3 /devices/system/machinecheck/machinecheck0 /devices/system/machinecheck/machinecheck1 /devices/system/machinecheck/machinecheck2 /devices/system/machinecheck/machinecheck3 /devices/system/memory/memory0 /devices/system/memory/memory1 /devices/system/memory/memory10 /devices/system/memory/memory11 /devices/system/memory/memory12 /devices/system/memory/memory13 /devices/system/memory/memory14 /devices/system/memory/memory15 /devices/system/memory/memory16 /devices/system/memory/memory17 /devices/system/memory/memory18 /devices/system/memory/memory19 /devices/system/memory/memory2 /devices/system/memory/memory20 /devices/system/memory/memory21 /devices/system/memory/memory22 /devices/system/memory/memory23 /devices/system/memory/memory3 /devices/system/memory/memory32 /devices/system/memory/memory33 /devices/system/memory/memory34 /devices/system/memory/memory35 /devices/system/memory/memory36 /devices/system/memory/memory37 /devices/system/memory/memory38 /devices/system/memory/memory39 /devices/system/memory/memory4 /devices/system/memory/memory40 /devices/system/memory/memory41 /devices/system/memory/memory42 /devices/system/memory/memory43 /devices/system/memory/memory44 /devices/system/memory/memory45 /devices/system/memory/memory46 /devices/system/memory/memory47 /devices/system/memory/memory48 /devices/system/memory/memory49 /devices/system/memory/memory5 /devices/system/memory/memory50 /devices/system/memory/memory51 /devices/system/memory/memory52 /devices/system/memory/memory53 /devices/system/memory/memory54 /devices/system/memory/memory55 /devices/system/memory/memory56 /devices/system/memory/memory57 /devices/system/memory/memory58 /devices/system/memory/memory59 /devices/system/memory/memory6 /devices/system/memory/memory60 /devices/system/memory/memory61 /devices/system/memory/memory62 /devices/system/memory/memory63 /devices/system/memory/memory64 /devices/system/memory/memory65 /devices/system/memory/memory66 /devices/system/memory/memory67 /devices/system/memory/memory68 /devices/system/memory/memory69 /devices/system/memory/memory7 /devices/system/memory/memory70 /devices/system/memory/memory71 /devices/system/memory/memory8 /devices/system/memory/memory9 /devices/system/node/node0 /devices/tracepoint /devices/uncore_cbox_0 /devices/uncore_cbox_1 /devices/uncore_imc /devices/virtual/bdi/0:40 /devices/virtual/bdi/8:0 /devices/virtual/bdi/btrfs-1 /devices/virtual/bdi/default /devices/virtual/dmi/id /devices/virtual/graphics/fbcon /devices/virtual/input/input14 /devices/virtual/input/input14/event12 name: /dev/input/event12 /devices/virtual/input/mice name: /dev/input/mice /devices/virtual/mem/full name: /dev/full /devices/virtual/mem/kmsg name: /dev/kmsg /devices/virtual/mem/mem name: /dev/mem /devices/virtual/mem/null name: /dev/null /devices/virtual/mem/port name: /dev/port /devices/virtual/mem/random name: /dev/random /devices/virtual/mem/urandom name: /dev/urandom /devices/virtual/mem/zero name: /dev/zero /devices/virtual/misc/autofs name: /dev/autofs /devices/virtual/misc/btrfs-control name: /dev/btrfs-control /devices/virtual/misc/cpu_dma_latency name: /dev/cpu_dma_latency /devices/virtual/misc/fuse name: /dev/fuse /devices/virtual/misc/hpet name: /dev/hpet /devices/virtual/misc/kvm name: /dev/kvm /devices/virtual/misc/mcelog name: /dev/mcelog /devices/virtual/misc/memory_bandwidth name: /dev/memory_bandwidth /devices/virtual/misc/microcode name: /dev/cpu/microcode /devices/virtual/misc/network_latency name: /dev/network_latency /devices/virtual/misc/network_throughput name: /dev/network_throughput /devices/virtual/misc/psaux name: /dev/psaux /devices/virtual/misc/rfkill name: /dev/rfkill /devices/virtual/misc/snapshot name: /dev/snapshot /devices/virtual/misc/vboxdrv name: /dev/vboxdrv /devices/virtual/misc/vboxdrvu name: /dev/vboxdrvu /devices/virtual/misc/vga_arbiter name: /dev/vga_arbiter /devices/virtual/net/lo /devices/virtual/powercap/intel-rapl /devices/virtual/powercap/intel-rapl/intel-rapl:0 /devices/virtual/powercap/intel-rapl/intel-rapl:0/intel-rapl:0:0 /devices/virtual/powercap/intel-rapl/intel-rapl:0/intel-rapl:0:1 /devices/virtual/sound/timer name: /dev/snd/timer /devices/virtual/thermal/cooling_device0 /devices/virtual/thermal/cooling_device1 /devices/virtual/thermal/cooling_device2 /devices/virtual/thermal/cooling_device3 /devices/virtual/thermal/cooling_device4 /devices/virtual/thermal/thermal_zone0 /devices/virtual/thermal/thermal_zone1 /devices/virtual/thermal/thermal_zone2 /devices/virtual/tty/console name: /dev/console /devices/virtual/tty/ptmx name: /dev/ptmx /devices/virtual/tty/tty name: /dev/tty /devices/virtual/tty/tty0 name: /dev/tty0 /devices/virtual/tty/tty1 name: /dev/tty1 /devices/virtual/tty/tty10 name: /dev/tty10 /devices/virtual/tty/tty11 name: /dev/tty11 /devices/virtual/tty/tty12 name: /dev/tty12 /devices/virtual/tty/tty13 name: /dev/tty13 /devices/virtual/tty/tty14 name: /dev/tty14 /devices/virtual/tty/tty15 name: /dev/tty15 /devices/virtual/tty/tty16 name: /dev/tty16 /devices/virtual/tty/tty17 name: /dev/tty17 /devices/virtual/tty/tty18 name: /dev/tty18 /devices/virtual/tty/tty19 name: /dev/tty19 /devices/virtual/tty/tty2 name: /dev/tty2 /devices/virtual/tty/tty20 name: /dev/tty20 /devices/virtual/tty/tty21 name: /dev/tty21 /devices/virtual/tty/tty22 name: /dev/tty22 /devices/virtual/tty/tty23 name: /dev/tty23 /devices/virtual/tty/tty24 name: /dev/tty24 /devices/virtual/tty/tty25 name: /dev/tty25 /devices/virtual/tty/tty26 name: /dev/tty26 /devices/virtual/tty/tty27 name: /dev/tty27 /devices/virtual/tty/tty28 name: /dev/tty28 /devices/virtual/tty/tty29 name: /dev/tty29 /devices/virtual/tty/tty3 name: /dev/tty3 /devices/virtual/tty/tty30 name: /dev/tty30 /devices/virtual/tty/tty31 name: /dev/tty31 /devices/virtual/tty/tty32 name: /dev/tty32 /devices/virtual/tty/tty33 name: /dev/tty33 /devices/virtual/tty/tty34 name: /dev/tty34 /devices/virtual/tty/tty35 name: /dev/tty35 /devices/virtual/tty/tty36 name: /dev/tty36 /devices/virtual/tty/tty37 name: /dev/tty37 /devices/virtual/tty/tty38 name: /dev/tty38 /devices/virtual/tty/tty39 name: /dev/tty39 /devices/virtual/tty/tty4 name: /dev/tty4 /devices/virtual/tty/tty40 name: /dev/tty40 /devices/virtual/tty/tty41 name: /dev/tty41 /devices/virtual/tty/tty42 name: /dev/tty42 /devices/virtual/tty/tty43 name: /dev/tty43 /devices/virtual/tty/tty44 name: /dev/tty44 /devices/virtual/tty/tty45 name: /dev/tty45 /devices/virtual/tty/tty46 name: /dev/tty46 /devices/virtual/tty/tty47 name: /dev/tty47 /devices/virtual/tty/tty48 name: /dev/tty48 /devices/virtual/tty/tty49 name: /dev/tty49 /devices/virtual/tty/tty5 name: /dev/tty5 /devices/virtual/tty/tty50 name: /dev/tty50 /devices/virtual/tty/tty51 name: /dev/tty51 /devices/virtual/tty/tty52 name: /dev/tty52 /devices/virtual/tty/tty53 name: /dev/tty53 /devices/virtual/tty/tty54 name: /dev/tty54 /devices/virtual/tty/tty55 name: /dev/tty55 /devices/virtual/tty/tty56 name: /dev/tty56 /devices/virtual/tty/tty57 name: /dev/tty57 /devices/virtual/tty/tty58 name: /dev/tty58 /devices/virtual/tty/tty59 name: /dev/tty59 /devices/virtual/tty/tty6 name: /dev/tty6 /devices/virtual/tty/tty60 name: /dev/tty60 /devices/virtual/tty/tty61 name: /dev/tty61 /devices/virtual/tty/tty62 name: /dev/tty62 /devices/virtual/tty/tty63 name: /dev/tty63 /devices/virtual/tty/tty7 name: /dev/tty7 /devices/virtual/tty/tty8 name: /dev/tty8 /devices/virtual/tty/tty9 name: /dev/tty9 /devices/virtual/vc/vcs name: /dev/vcs /devices/virtual/vc/vcs1 name: /dev/vcs1 /devices/virtual/vc/vcs2 name: /dev/vcs2 /devices/virtual/vc/vcs3 name: /dev/vcs3 /devices/virtual/vc/vcs4 name: /dev/vcs4 /devices/virtual/vc/vcs5 name: /dev/vcs5 /devices/virtual/vc/vcs6 name: /dev/vcs6 /devices/virtual/vc/vcsa name: /dev/vcsa /devices/virtual/vc/vcsa1 name: /dev/vcsa1 /devices/virtual/vc/vcsa2 name: /dev/vcsa2 /devices/virtual/vc/vcsa3 name: /dev/vcsa3 /devices/virtual/vc/vcsa4 name: /dev/vcsa4 /devices/virtual/vc/vcsa5 name: /dev/vcsa5 /devices/virtual/vc/vcsa6 name: /dev/vcsa6 /devices/virtual/vtconsole/vtcon0 /devices/virtual/vtconsole/vtcon1 /devices/virtual/wmi/05901221-D566-11D1-B2F0-00A0C9062910 /devices/virtual/wmi/2FAE25E0-C342-4F49-AD2F-0F06A958721A /devices/virtual/wmi/72E6BB2F-8380-46B2-9A9F-6D3F513223E7 /devices/virtual/wmi/8D9DDCBC-A997-11DA-B012-B622A1EF5492 /devices/virtual/wmi/9DBB5994-A997-11DA-B012-B622A1EF5492 /devices/virtual/wmi/A3776CE0-1E88-11DB-A98B-0800200C9A66 /devices/virtual/wmi/A80593CE-A997-11DA-B012-B622A1EF5492 /devices/virtual/wmi/DD8C7670-1CB5-11DB-A98B-669A0C200008 /devices/virtual/workqueue/writeback >> int.13: device names >> int.14: soft raid ----- soft raid devices ----- ----- soft raid devices end ----- >> int.15: geo >> int.16: parent prop read: rdCR.lZF+r4EgHp4 (failed) old prop read: rdCR.lZF+r4EgHp4 (failed) prop read: rdCR.n_7QNeEnh23 (failed) old prop read: rdCR.n_7QNeEnh23 (failed) prop read: rdCR.EMpH5pjcahD (failed) old prop read: rdCR.EMpH5pjcahD (failed) prop read: rdCR.f5u1ucRm+H9 (failed) old prop read: rdCR.f5u1ucRm+H9 (failed) prop read: rdCR.8uRK7LxiIA2 (failed) old prop read: rdCR.8uRK7LxiIA2 (failed) prop read: rdCR.AJKleuxpiP0 (failed) old prop read: rdCR.AJKleuxpiP0 (failed) prop read: rdCR.9N+EecqykME (failed) old prop read: rdCR.9N+EecqykME (failed) prop read: rdCR.CxwsZFjVASF (failed) old prop read: rdCR.CxwsZFjVASF (failed) prop read: qLht.cw4HyBnSS+2 (failed) old prop read: qLht.cw4HyBnSS+2 (failed) prop read: _Znp.rwP03aZdcu3 (failed) old prop read: _Znp.rwP03aZdcu3 (failed) prop read: MZfG.y1p0BiaRo35 (failed) old prop read: MZfG.y1p0BiaRo35 (failed) prop read: WnlC.DkEgeC4CYT6 (failed) old prop read: WnlC.DkEgeC4CYT6 (failed) prop read: pwJ7.eNEx6sU0or4 (failed) old prop read: pwJ7.eNEx6sU0or4 (failed) prop read: u1Nb.J6xhTBJ6uT9 (failed) old prop read: u1Nb.J6xhTBJ6uT9 (failed) prop read: z8Q3.cCrMqDQX+R3 (failed) old prop read: z8Q3.cCrMqDQX+R3 (failed) prop read: 1GTX.1Udhlsf46A2 (failed) old prop read: 1GTX.1Udhlsf46A2 (failed) prop read: BUZT.918Zwupnou6 (failed) old prop read: BUZT.918Zwupnou6 (failed) prop read: w7Y8.tSawXCnS8U4 (failed) old prop read: w7Y8.tSawXCnS8U4 (failed) prop read: nS1_.VE8x34jct1A (failed) old prop read: nS1_.VE8x34jct1A (failed) prop read: yWPJ.uibugzCc6b5 (failed) old prop read: yWPJ.uibugzCc6b5 (failed) prop read: 3OOL.+ElxNP801RF (failed) old prop read: 3OOL.+ElxNP801RF (failed) prop read: bdUI.SE1wIdpsiiC (failed) old prop read: bdUI.SE1wIdpsiiC (failed) prop read: 2pkM.SE1wIdpsiiC (failed) old prop read: 2pkM.SE1wIdpsiiC (failed) prop read: W__Q.SE1wIdpsiiC (failed) old prop read: W__Q.SE1wIdpsiiC (failed) prop read: uIhY.FHd55n4xKo7 (failed) old prop read: uIhY.FHd55n4xKo7 (failed) prop read: KRJj.4Nx_qoDfSd7 (failed) old prop read: KRJj.4Nx_qoDfSd7 (failed) prop read: s8zo.VIVVYWREfzA (failed) old prop read: s8zo.VIVVYWREfzA (failed) prop read: zPk0.oLWCeziExdF (failed) old prop read: zPk0.oLWCeziExdF (failed) prop read: PYMB.4Nx_qoDfSd7 (failed) old prop read: PYMB.4Nx_qoDfSd7 (failed) prop read: YdCm.cdUiY6836R9 (failed) old prop read: YdCm.cdUiY6836R9 (failed) prop read: k4bc.2DFUsyrieMD (failed) old prop read: k4bc.2DFUsyrieMD (failed) prop read: pBe4.xYNhIwdOaa6 (failed) old prop read: pBe4.xYNhIwdOaa6 (failed) prop read: 3FDI.+49ps10DtUF (failed) old prop read: 3FDI.+49ps10DtUF (failed) prop read: AH6Q.kjMWrPZ39l6 (failed) old prop read: AH6Q.kjMWrPZ39l6 (failed) prop read: rdCR.j8NaKXDZtZ6 (failed) old prop read: rdCR.j8NaKXDZtZ6 (failed) prop read: wkFv.j8NaKXDZtZ6 (failed) old prop read: wkFv.j8NaKXDZtZ6 (failed) prop read: +rIN.j8NaKXDZtZ6 (failed) old prop read: +rIN.j8NaKXDZtZ6 (failed) prop read: 4zLr.j8NaKXDZtZ6 (failed) old prop read: 4zLr.j8NaKXDZtZ6 (failed) prop read: ZsBS.GQNx7L4uPNA (failed) old prop read: ZsBS.GQNx7L4uPNA (failed) prop read: eAgB.ndpeucax6V1 (failed) old prop read: eAgB.ndpeucax6V1 (failed) ----- kernel log ----- <6>[ 4.379261] dcdbas dcdbas: Dell Systems Management Base Driver (version 5.6.0-3.2) <6>[ 4.385568] AVX version of gcm_enc/dec engaged. <6>[ 4.385571] AES CTR mode by8 optimization enabled <6>[ 4.395008] iTCO_vendor_support: vendor-support=0 <6>[ 4.397285] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11 <6>[ 4.397325] iTCO_wdt: Found a Panther Point TCO device (Version=2, TCOBASE=0x0460) <6>[ 4.398100] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) <6>[ 4.400951] iwlwifi 0000:01:00.0: Detected Intel(R) Dual Band Wireless AC 7260, REV=0x144 <6>[ 4.401061] iwlwifi 0000:01:00.0: L1 Enabled - LTR Disabled <6>[ 4.401507] iwlwifi 0000:01:00.0: L1 Enabled - LTR Disabled <6>[ 4.446393] intel_rapl: Found RAPL domain package <6>[ 4.446397] intel_rapl: Found RAPL domain core <6>[ 4.446399] intel_rapl: Found RAPL domain uncore <5>[ 4.462911] random: nonblocking pool is initialized <6>[ 4.486035] media: Linux media interface: v0.10 <6>[ 4.490124] Linux video capture interface: v2.00 <6>[ 4.492614] Bluetooth: Core ver 2.19 <6>[ 4.492628] NET: Registered protocol family 31 <6>[ 4.492630] Bluetooth: HCI device and connection manager initialized <6>[ 4.492637] Bluetooth: HCI socket layer initialized <6>[ 4.492639] Bluetooth: L2CAP socket layer initialized <6>[ 4.492646] Bluetooth: SCO socket layer initialized <6>[ 4.494974] usbcore: registered new interface driver btusb <6>[ 4.498586] uvcvideo: Found UVC 1.00 device Laptop_Integrated_Webcam_1.3M (1bcf:288f) <6>[ 4.508665] Bluetooth: hci0: read Intel version: 3707100180012d0d00 <6>[ 4.510601] Bluetooth: hci0: Intel Bluetooth firmware file: intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq <6>[ 4.511955] ACPI: AC Adapter [ADP0] (on-line) <6>[ 4.517028] ACPI: Battery Slot [BAT0] (battery present) <6>[ 4.517227] wmi: Mapper loaded <6>[ 4.579366] input: Laptop_Integrated_Webcam_1.3M as /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5/3-1.5:1.0/input/input13 <6>[ 4.579418] usbcore: registered new interface driver uvcvideo <6>[ 4.579420] USB Video Class driver (1.1.1) <7>[ 4.610252] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs' <6>[ 4.617810] input: Dell WMI hotkeys as /devices/virtual/input/input14 <6>[ 4.620376] iwlwifi 0000:01:00.0 wlp1s0: renamed from wlan0 <6>[ 4.658847] Bluetooth: hci0: Intel Bluetooth firmware patch completed and activated <46>[ 4.759550] systemd-journald[165]: Received request to flush runtime journal from PID 1 <6>[ 4.993790] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 <6>[ 4.993793] Bluetooth: BNEP filters: protocol multicast <6>[ 4.993800] Bluetooth: BNEP socket layer initialized <6>[ 5.212383] iwlwifi 0000:01:00.0: L1 Enabled - LTR Disabled <6>[ 5.212645] iwlwifi 0000:01:00.0: L1 Enabled - LTR Disabled <6>[ 5.320272] input: CyPS/2 Cypress Trackpad as /devices/platform/i8042/serio1/input/input9 <6>[ 5.321490] mousedev: PS/2 mouse device common for all mice <6>[ 6.367654] fuse init (API version 7.23) <6>[ 6.380766] cfg80211: Calling CRDA to update world regulatory domain <6>[ 9.132281] wlp1s0: authenticate with 9c:c7:a6:9a:60:c0 <6>[ 9.135320] wlp1s0: send auth to 9c:c7:a6:9a:60:c0 (try 1/3) <6>[ 9.136932] wlp1s0: authenticated <6>[ 9.137112] wlp1s0: associate with 9c:c7:a6:9a:60:c0 (try 1/3) <6>[ 9.142629] wlp1s0: RX AssocResp from 9c:c7:a6:9a:60:c0 (capab=0x411 status=0 aid=3) <6>[ 9.144435] wlp1s0: associated <6>[ 9.144498] cfg80211: Calling CRDA to update world regulatory domain <6>[ 9.149954] wlp1s0: Limiting TX power to 23 (23 - 0) dBm as advertised by 9c:c7:a6:9a:60:c0 <6>[ 806.749643] wlp1s0: authenticate with 34:31:c4:6c:34:e6 <6>[ 806.752490] wlp1s0: send auth to 34:31:c4:6c:34:e6 (try 1/3) <6>[ 806.752771] cfg80211: Calling CRDA for country: DE <6>[ 806.762726] wlp1s0: authenticated <6>[ 806.763733] wlp1s0: associate with 34:31:c4:6c:34:e6 (try 1/3) <6>[ 806.792039] wlp1s0: RX AssocResp from 34:31:c4:6c:34:e6 (capab=0x411 status=0 aid=3) <6>[ 806.793836] wlp1s0: associated <6>[ 806.820463] wlp1s0: Limiting TX power to 27 (30 - 3) dBm as advertised by 34:31:c4:6c:34:e6 <6>[ 854.351372] Bluetooth: RFCOMM TTY layer initialized <6>[ 854.351384] Bluetooth: RFCOMM socket layer initialized <6>[ 854.351392] Bluetooth: RFCOMM ver 1.11 <6>[ 922.973724] cfg80211: Calling CRDA for country: DE <4>[10181.067289] perf interrupt took too long (2625 > 2495), lowering kernel.perf_event_max_sample_rate to 50100 <6>[11258.579553] wlp1s0: authenticate with 9c:c7:a6:9a:60:c0 <6>[11258.582003] wlp1s0: send auth to 9c:c7:a6:9a:60:c0 (try 1/3) <6>[11258.582330] cfg80211: Calling CRDA to update world regulatory domain <6>[11258.584796] wlp1s0: authenticated <6>[11258.584995] wlp1s0: associate with 9c:c7:a6:9a:60:c0 (try 1/3) <6>[11258.589642] wlp1s0: RX AssocResp from 9c:c7:a6:9a:60:c0 (capab=0x411 status=0 aid=3) <6>[11258.590828] wlp1s0: associated <6>[11258.590927] cfg80211: Calling CRDA to update world regulatory domain <6>[11258.695231] wlp1s0: Limiting TX power to 23 (23 - 0) dBm as advertised by 9c:c7:a6:9a:60:c0 <6>[11258.695261] cfg80211: Calling CRDA to update world regulatory domain <6>[20744.695027] cfg80211: Calling CRDA to update world regulatory domain <6>[20749.394521] wlp1s0: authenticate with 9c:c7:a6:61:ce:9c <6>[20749.397131] wlp1s0: send auth to 9c:c7:a6:61:ce:9c (try 1/3) <6>[20749.397997] cfg80211: Calling CRDA to update world regulatory domain <6>[20749.398914] wlp1s0: authenticated <6>[20749.402397] wlp1s0: associate with 9c:c7:a6:61:ce:9c (try 1/3) <6>[20749.505871] wlp1s0: associate with 9c:c7:a6:61:ce:9c (try 2/3) <6>[20749.609323] wlp1s0: associate with 9c:c7:a6:61:ce:9c (try 3/3) <6>[20749.712822] wlp1s0: association with 9c:c7:a6:61:ce:9c timed out <6>[20749.867753] cfg80211: Calling CRDA to update world regulatory domain <6>[20750.093732] wlp1s0: authenticate with 9c:c7:a6:9a:60:c0 <6>[20750.096993] wlp1s0: send auth to 9c:c7:a6:9a:60:c0 (try 1/3) <6>[20750.099229] wlp1s0: authenticated <6>[20750.099887] wlp1s0: associate with 9c:c7:a6:9a:60:c0 (try 1/3) <6>[20750.107818] wlp1s0: RX AssocResp from 9c:c7:a6:9a:60:c0 (capab=0x411 status=0 aid=3) <6>[20750.109923] wlp1s0: associated <6>[20750.110305] cfg80211: Calling CRDA to update world regulatory domain <6>[20750.175044] wlp1s0: Limiting TX power to 23 (23 - 0) dBm as advertised by 9c:c7:a6:9a:60:c0 <6>[20819.792891] wlp1s0: deauthenticating from 9c:c7:a6:9a:60:c0 by local choice (Reason: 3=DEAUTH_LEAVING) <6>[20819.800394] cfg80211: Calling CRDA for country: DE <6>[20820.345087] cfg80211: Calling CRDA for country: DE <6>[20820.908073] cfg80211: Calling CRDA for country: DE <6>[20823.683656] wlp1s0: authenticate with 9c:c7:a6:9a:60:c0 <6>[20823.686511] wlp1s0: send auth to 9c:c7:a6:9a:60:c0 (try 1/3) <6>[20823.689046] wlp1s0: authenticated <6>[20823.692397] wlp1s0: associate with 9c:c7:a6:9a:60:c0 (try 1/3) <6>[20823.695864] wlp1s0: RX AssocResp from 9c:c7:a6:9a:60:c0 (capab=0x411 status=0 aid=3) <6>[20823.697733] wlp1s0: associated <6>[20823.778444] wlp1s0: Limiting TX power to 23 (23 - 0) dBm as advertised by 9c:c7:a6:9a:60:c0 <6>[20829.114750] wlp1s0: deauthenticating from 9c:c7:a6:9a:60:c0 by local choice (Reason: 3=DEAUTH_LEAVING) <6>[20829.122082] cfg80211: Calling CRDA to update world regulatory domain <6>[20829.673651] cfg80211: Calling CRDA to update world regulatory domain <6>[20830.236849] cfg80211: Calling CRDA to update world regulatory domain <6>[20832.949648] wlp1s0: authenticate with 9c:c7:a6:9a:60:c0 <6>[20832.952256] wlp1s0: send auth to 9c:c7:a6:9a:60:c0 (try 1/3) <6>[20832.954377] wlp1s0: authenticated <6>[20832.956118] wlp1s0: associate with 9c:c7:a6:9a:60:c0 (try 1/3) <6>[20832.959861] wlp1s0: RX AssocResp from 9c:c7:a6:9a:60:c0 (capab=0x411 status=0 aid=3) <6>[20832.969562] wlp1s0: associated <6>[20832.969809] cfg80211: Calling CRDA to update world regulatory domain <6>[20833.004848] wlp1s0: Limiting TX power to 23 (23 - 0) dBm as advertised by 9c:c7:a6:9a:60:c0 <6>[21148.690502] cfg80211: Calling CRDA to update world regulatory domain ----- kernel log end ----- ----- /proc/modules ----- rfcomm 57927 12 - Live 0xffffffffa098c000 ctr 12927 3 - Live 0xffffffffa0635000 ccm 17534 3 - Live 0xffffffffa0951000 fuse 87410 3 - Live 0xffffffffa0975000 joydev 17063 0 - Live 0xffffffffa094b000 mousedev 17272 0 - Live 0xffffffffa0852000 bnep 17349 2 - Live 0xffffffffa084c000 ecb 12737 1 - Live 0xffffffffa0630000 dell_wmi 12477 0 - Live 0xffffffffa0526000 sparse_keymap 12818 1 dell_wmi, Live 0xffffffffa04ef000 arc4 12536 2 - Live 0xffffffffa043b000 nls_iso8859_1 12461 1 - Live 0xffffffffa0946000 uvcvideo 83143 0 - Live 0xffffffffa095f000 nls_cp437 16553 1 - Live 0xffffffffa0959000 btusb 29996 0 - Live 0xffffffffa093d000 videobuf2_vmalloc 12816 1 uvcvideo, Live 0xffffffffa085d000 videobuf2_memops 12519 1 videobuf2_vmalloc, Live 0xffffffffa0938000 videobuf2_core 39635 1 uvcvideo, Live 0xffffffffa08c6000 v4l2_common 12995 1 videobuf2_core, Live 0xffffffffa0781000 bluetooth 403971 32 rfcomm,bnep,btusb, Live 0xffffffffa08d4000 videodev 135040 3 uvcvideo,videobuf2_core,v4l2_common, Live 0xffffffffa08a4000 vfat 21231 1 - Live 0xffffffffa0869000 media 18365 2 uvcvideo,videodev, Live 0xffffffffa0863000 fat 61984 1 vfat, Live 0xffffffffa0805000 crc16 12343 1 bluetooth, Live 0xffffffffa0878000 coretemp 12820 0 - Live 0xffffffffa0800000 hwmon 12930 1 coretemp, Live 0xffffffffa077c000 intel_rapl 17356 0 - Live 0xffffffffa0872000 x86_pkg_temp_thermal 12951 0 - Live 0xffffffffa078b000 intel_powerclamp 17122 0 - Live 0xffffffffa07fa000 kvm_intel 143295 0 - Live 0xffffffffa0880000 kvm 426425 1 kvm_intel, Live 0xffffffffa0790000 crct10dif_pclmul 13394 0 - Live 0xffffffffa06de000 crc32_pclmul 12915 0 - Live 0xffffffffa0786000 ghash_clmulni_intel 12978 0 - Live 0xffffffffa0858000 iwlmvm 194181 0 - Live 0xffffffffa081b000 iTCO_wdt 12831 0 - Live 0xffffffffa0816000 iTCO_vendor_support 12649 1 iTCO_wdt, Live 0xffffffffa06ad000 mac80211 608652 1 iwlmvm, Live 0xffffffffa06e6000 aesni_intel 167997 7 - Live 0xffffffffa06b3000 dell_laptop 12945 0 - Live 0xffffffffa06a3000 led_class 12855 2 iwlmvm,dell_laptop, Live 0xffffffffa06a8000 dcdbas 13263 1 dell_laptop, Live 0xffffffffa069e000 aes_x86_64 16719 1 aesni_intel, Live 0xffffffffa0698000 lrw 12757 1 aesni_intel, Live 0xffffffffa0693000 gf128mul 12970 1 lrw, Live 0xffffffffa068e000 glue_helper 12649 1 aesni_intel, Live 0xffffffffa0581000 ablk_helper 12572 1 aesni_intel, Live 0xffffffffa065c000 cryptd 18553 3 ghash_clmulni_intel,aesni_intel,ablk_helper, Live 0xffffffffa057b000 snd_hda_codec_hdmi 49263 1 - Live 0xffffffffa0680000 psmouse 107442 0 - Live 0xffffffffa0664000 snd_hda_codec_realtek 63196 1 - Live 0xffffffffa063a000 snd_hda_codec_generic 63087 1 snd_hda_codec_realtek, Live 0xffffffffa064b000 serio_raw 12849 0 - Live 0xffffffffa0576000 iwlwifi 156878 1 iwlmvm, Live 0xffffffffa05fe000 pcspkr 12595 0 - Live 0xffffffffa0521000 i2c_i801 16965 0 - Live 0xffffffffa062a000 cfg80211 453926 3 iwlmvm,mac80211,iwlwifi, Live 0xffffffffa058e000 snd_hda_intel 26387 5 - Live 0xffffffffa0519000 snd_hda_controller 26938 1 snd_hda_intel, Live 0xffffffffa0586000 thermal 17559 0 - Live 0xffffffffa052f000 rfkill 18867 6 bluetooth,dell_laptop,cfg80211, Live 0xffffffffa028a000 snd_hda_codec 112621 5 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_codec_generic,snd_hda_intel,snd_hda_controller, Live 0xffffffffa0559000 wmi 17339 1 dell_wmi, Live 0xffffffffa04e9000 battery 17452 0 - Live 0xffffffffa050e000 tpm_tis 17182 0 - Live 0xffffffffa04b6000 snd_hwdep 17244 1 snd_hda_codec, Live 0xffffffffa04ac000 snd_pcm 88785 5 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_controller,snd_hda_codec, Live 0xffffffffa04d2000 tpm 31467 1 tpm_tis, Live 0xffffffffa04c0000 snd_timer 26614 1 snd_pcm, Live 0xffffffffa0548000 mei_me 17941 0 - Live 0xffffffffa0508000 evdev 21544 24 - Live 0xffffffffa0552000 snd 73436 17 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_codec_generic,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_timer, Live 0xffffffffa0535000 ac 12715 0 - Live 0xffffffffa04cd000 mac_hid 12633 0 - Live 0xffffffffa0514000 mei 75336 1 mei_me, Live 0xffffffffa04f4000 soundcore 13031 2 snd_hda_codec,snd, Live 0xffffffffa0290000 shpchp 35210 0 - Live 0xffffffffa044a000 lpc_ich 20768 0 - Live 0xffffffffa0443000 processor 27777 0 - Live 0xffffffffa0282000 sch_fq_codel 17343 5 - Live 0xffffffffa0256000 vboxdrv 352524 0 - Live 0xffffffffa0454000 (O) nfs 208487 0 - Live 0xffffffffa0407000 lockd 87230 1 nfs, Live 0xffffffffa03f0000 grace 12586 1 lockd, Live 0xffffffffa022d000 sunrpc 249295 2 nfs,lockd, Live 0xffffffffa03b2000 fscache 53701 1 nfs, Live 0xffffffffa0213000 btrfs 921388 1 - Live 0xffffffffa02d0000 xor 21040 1 btrfs, Live 0xffffffffa01f0000 raid6_pq 99334 1 btrfs, Live 0xffffffffa023c000 sd_mod 43575 4 - Live 0xffffffffa0207000 atkbd 22254 0 - Live 0xffffffffa0200000 libps2 12739 2 psmouse,atkbd, Live 0xffffffffa0179000 ahci 33248 3 - Live 0xffffffffa0232000 libahci 27215 1 ahci, Live 0xffffffffa0225000 crc32c_intel 21809 1 - Live 0xffffffffa01f9000 libata 181518 2 ahci,libahci, Live 0xffffffffa01c2000 ehci_pci 12512 0 - Live 0xffffffffa0174000 xhci_pci 12675 0 - Live 0xffffffffa01b9000 ehci_hcd 69939 1 ehci_pci, Live 0xffffffffa0296000 xhci_hcd 152471 1 xhci_pci,[permanent], Live 0xffffffffa02a9000 scsi_mod 147580 2 sd_mod,libata, Live 0xffffffffa025c000 usbcore 199382 6 uvcvideo,btusb,ehci_pci,xhci_pci,ehci_hcd,xhci_hcd, Live 0xffffffffa0187000 usb_common 12561 1 usbcore, Live 0xffffffffa0064000 i8042 18002 2 dell_laptop,libps2, Live 0xffffffffa017e000 serio 18282 6 psmouse,serio_raw,atkbd,i8042, Live 0xffffffffa006e000 i915 946695 6 - Live 0xffffffffa008b000 button 12953 1 i915, Live 0xffffffffa0069000 intel_gtt 17848 1 i915, Live 0xffffffffa0058000 i2c_algo_bit 12744 1 i915, Live 0xffffffffa005f000 video 18043 1 i915, Live 0xffffffffa000e000 drm_kms_helper 80985 1 i915, Live 0xffffffffa0076000 drm 263481 8 i915,drm_kms_helper, Live 0xffffffffa0016000 i2c_core 50152 7 v4l2_common,videodev,i2c_i801,i915,i2c_algo_bit,drm_kms_helper,drm, Live 0xffffffffa0000000 ----- /proc/modules end ----- used irqs: 0,1,8,9,12,16,18,23,24,25,26,27,28,29 =========== end debug info ============ 01: None 00.0: 10105 BIOS [Created at bios.186] Unique ID: rdCR.lZF+r4EgHp4 Hardware Class: bios BIOS Keyboard LED Status: Scroll Lock: off Num Lock: off Caps Lock: off Config Status: cfg=new, avail=yes, need=no, active=unknown 02: None 00.0: 10107 System [Created at sys.63] Unique ID: rdCR.n_7QNeEnh23 Hardware Class: system Model: "System" Formfactor: "laptop" Driver Info #0: Driver Status: thermal,fan are not active Driver Activation Cmd: "modprobe thermal; modprobe fan" Config Status: cfg=new, avail=yes, need=no, active=unknown 03: None 00.0: 10104 FPU [Created at misc.191] Unique ID: rdCR.EMpH5pjcahD Hardware Class: unknown Model: "FPU" I/O Ports: 0xf0-0xff (rw) Config Status: cfg=new, avail=yes, need=no, active=unknown 04: None 00.0: 0801 DMA controller (8237) [Created at misc.205] Unique ID: rdCR.f5u1ucRm+H9 Hardware Class: unknown Model: "DMA controller" I/O Ports: 0x00-0xcf7 (rw) I/O Ports: 0xc0-0xdf (rw) I/O Ports: 0x80-0x8f (rw) DMA: 4 Config Status: cfg=new, avail=yes, need=no, active=unknown 05: None 00.0: 0800 PIC (8259) [Created at misc.218] Unique ID: rdCR.8uRK7LxiIA2 Hardware Class: unknown Model: "PIC" I/O Ports: 0x20-0x21 (rw) I/O Ports: 0xa0-0xa1 (rw) Config Status: cfg=new, avail=yes, need=no, active=unknown 06: None 00.0: 0802 Timer (8254) [Created at misc.229] Unique ID: rdCR.AJKleuxpiP0 Hardware Class: unknown Model: "Timer" IRQ: 0 (27 events) Config Status: cfg=new, avail=yes, need=no, active=unknown 07: None 00.0: 0900 Keyboard controller [Created at misc.250] Unique ID: rdCR.9N+EecqykME Hardware Class: unknown Model: "Keyboard controller" I/O Port: 0x60 (rw) I/O Port: 0x64 (rw) Config Status: cfg=new, avail=yes, need=no, active=unknown 12: None 00.0: 10102 Main Memory [Created at memory.74] Unique ID: rdCR.CxwsZFjVASF Hardware Class: memory Model: "Main Memory" Memory Range: 0x00000000-0x1ea7defff (rw) Memory Size: 7 GB + 512 MB Config Status: cfg=new, avail=yes, need=no, active=unknown 13: PCI 00.0: 0600 Host bridge [Created at pci.328] Unique ID: qLht.cw4HyBnSS+2 SysFS ID: /devices/pci0000:00/0000:00:00.0 SysFS BusID: 0000:00:00.0 Hardware Class: bridge Model: "Intel 3rd Gen Core processor DRAM Controller" Vendor: pci 0x8086 "Intel Corporation" Device: pci 0x0154 "3rd Gen Core processor DRAM Controller" SubVendor: pci 0x1028 "Dell" SubDevice: pci 0x058b Revision: 0x09 Driver: "ivb_uncore" Module Alias: "pci:v00008086d00000154sv00001028sd0000058Bbc06sc00i00" Config Status: cfg=new, avail=yes, need=no, active=unknown 14: PCI 02.0: 0300 VGA compatible controller (VGA) [Created at pci.328] Unique ID: _Znp.rwP03aZdcu3 SysFS ID: /devices/pci0000:00/0000:00:02.0 SysFS BusID: 0000:00:02.0 Hardware Class: graphics card Model: "Intel 3rd Gen Core processor Graphics Controller" Vendor: pci 0x8086 "Intel Corporation" Device: pci 0x0166 "3rd Gen Core processor Graphics Controller" SubVendor: pci 0x1028 "Dell" SubDevice: pci 0x058b Revision: 0x09 Driver: "i915" Driver Modules: "drm" Memory Range: 0xd0000000-0xd03fffff (rw,non-prefetchable) Memory Range: 0xc0000000-0xcfffffff (ro,non-prefetchable) I/O Ports: 0x2000-0x203f (rw) IRQ: 24 (528717 events) Module Alias: "pci:v00008086d00000166sv00001028sd0000058Bbc03sc00i00" Driver Info #0: Driver Status: i915 is active Driver Activation Cmd: "modprobe i915" Config Status: cfg=new, avail=yes, need=no, active=unknown 15: PCI 14.0: 0c03 USB Controller (XHCI) [Created at pci.328] Unique ID: MZfG.y1p0BiaRo35 SysFS ID: /devices/pci0000:00/0000:00:14.0 SysFS BusID: 0000:00:14.0 Hardware Class: usb controller Model: "Intel 7 Series/C210 Series Chipset Family USB xHCI Host Controller" Vendor: pci 0x8086 "Intel Corporation" Device: pci 0x1e31 "7 Series/C210 Series Chipset Family USB xHCI Host Controller" SubVendor: pci 0x1028 "Dell" SubDevice: pci 0x058b Revision: 0x04 Driver: "xhci_hcd" Driver Modules: "xhci_pci" Memory Range: 0xd0500000-0xd050ffff (rw,non-prefetchable) IRQ: 25 (no events) Module Alias: "pci:v00008086d00001E31sv00001028sd0000058Bbc0Csc03i30" Driver Info #0: Driver Status: xhci_pci is active Driver Activation Cmd: "modprobe xhci_pci" Config Status: cfg=new, avail=yes, need=no, active=unknown 16: PCI 16.0: 0780 Communication controller [Created at pci.328] Unique ID: WnlC.DkEgeC4CYT6 SysFS ID: /devices/pci0000:00/0000:00:16.0 SysFS BusID: 0000:00:16.0 Hardware Class: unknown Model: "Intel 7 Series/C210 Series Chipset Family MEI Controller #1" Vendor: pci 0x8086 "Intel Corporation" Device: pci 0x1e3a "7 Series/C210 Series Chipset Family MEI Controller #1" SubVendor: pci 0x1028 "Dell" SubDevice: pci 0x058b Revision: 0x04 Driver: "mei_me" Driver Modules: "mei_me" Memory Range: 0xd0515000-0xd051500f (rw,non-prefetchable) IRQ: 27 (15 events) Module Alias: "pci:v00008086d00001E3Asv00001028sd0000058Bbc07sc80i00" Driver Info #0: Driver Status: mei_me is active Driver Activation Cmd: "modprobe mei_me" Config Status: cfg=new, avail=yes, need=no, active=unknown 17: PCI 1a.0: 0c03 USB Controller (EHCI) [Created at pci.328] Unique ID: pwJ7.eNEx6sU0or4 SysFS ID: /devices/pci0000:00/0000:00:1a.0 SysFS BusID: 0000:00:1a.0 Hardware Class: usb controller Model: "Intel 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2" Vendor: pci 0x8086 "Intel Corporation" Device: pci 0x1e2d "7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2" SubVendor: pci 0x1028 "Dell" SubDevice: pci 0x058b Revision: 0x04 Driver: "ehci-pci" Driver Modules: "ehci_pci" Memory Range: 0xd051a000-0xd051a3ff (rw,non-prefetchable) IRQ: 16 (166 events) Module Alias: "pci:v00008086d00001E2Dsv00001028sd0000058Bbc0Csc03i20" Driver Info #0: Driver Status: ehci-hcd is active Driver Activation Cmd: "modprobe ehci-hcd" Driver Info #1: Driver Status: ehci_pci is active Driver Activation Cmd: "modprobe ehci_pci" Config Status: cfg=new, avail=yes, need=no, active=unknown 18: PCI 1b.0: 0403 Audio device [Created at pci.328] Unique ID: u1Nb.J6xhTBJ6uT9 SysFS ID: /devices/pci0000:00/0000:00:1b.0 SysFS BusID: 0000:00:1b.0 Hardware Class: sound Model: "Intel 7 Series/C210 Series Chipset Family High Definition Audio Controller" Vendor: pci 0x8086 "Intel Corporation" Device: pci 0x1e20 "7 Series/C210 Series Chipset Family High Definition Audio Controller" SubVendor: pci 0x1028 "Dell" SubDevice: pci 0x058b Revision: 0x04 Driver: "snd_hda_intel" Driver Modules: "snd_hda_intel" Memory Range: 0xd0510000-0xd0513fff (rw,non-prefetchable) IRQ: 28 (675 events) Module Alias: "pci:v00008086d00001E20sv00001028sd0000058Bbc04sc03i00" Driver Info #0: Driver Status: snd_hda_intel is active Driver Activation Cmd: "modprobe snd_hda_intel" Config Status: cfg=new, avail=yes, need=no, active=unknown 19: PCI 1c.0: 0604 PCI bridge (Normal decode) [Created at pci.328] Unique ID: z8Q3.cCrMqDQX+R3 SysFS ID: /devices/pci0000:00/0000:00:1c.0 SysFS BusID: 0000:00:1c.0 Hardware Class: bridge Model: "Intel 7 Series/C210 Series Chipset Family PCI Express Root Port 1" Vendor: pci 0x8086 "Intel Corporation" Device: pci 0x1e10 "7 Series/C210 Series Chipset Family PCI Express Root Port 1" SubVendor: pci 0x1028 "Dell" SubDevice: pci 0x058b Revision: 0xc4 Driver: "pcieport" IRQ: 16 (166 events) Module Alias: "pci:v00008086d00001E10sv00001028sd0000058Bbc06sc04i00" Driver Info #0: Driver Status: shpchp is active Driver Activation Cmd: "modprobe shpchp" Config Status: cfg=new, avail=yes, need=no, active=unknown 20: PCI 1d.0: 0c03 USB Controller (EHCI) [Created at pci.328] Unique ID: 1GTX.1Udhlsf46A2 SysFS ID: /devices/pci0000:00/0000:00:1d.0 SysFS BusID: 0000:00:1d.0 Hardware Class: usb controller Model: "Intel 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1" Vendor: pci 0x8086 "Intel Corporation" Device: pci 0x1e26 "7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1" SubVendor: pci 0x1028 "Dell" SubDevice: pci 0x058b Revision: 0x04 Driver: "ehci-pci" Driver Modules: "ehci_pci" Memory Range: 0xd0519000-0xd05193ff (rw,non-prefetchable) IRQ: 23 (440 events) Module Alias: "pci:v00008086d00001E26sv00001028sd0000058Bbc0Csc03i20" Driver Info #0: Driver Status: ehci-hcd is active Driver Activation Cmd: "modprobe ehci-hcd" Driver Info #1: Driver Status: ehci_pci is active Driver Activation Cmd: "modprobe ehci_pci" Config Status: cfg=new, avail=yes, need=no, active=unknown 21: PCI 1f.0: 0601 ISA bridge [Created at pci.328] Unique ID: BUZT.918Zwupnou6 SysFS ID: /devices/pci0000:00/0000:00:1f.0 SysFS BusID: 0000:00:1f.0 Hardware Class: bridge Model: "Intel QS77 Express Chipset LPC Controller" Vendor: pci 0x8086 "Intel Corporation" Device: pci 0x1e56 "QS77 Express Chipset LPC Controller" SubVendor: pci 0x1028 "Dell" SubDevice: pci 0x058b Revision: 0x04 Driver: "lpc_ich" Driver Modules: "lpc_ich" Module Alias: "pci:v00008086d00001E56sv00001028sd0000058Bbc06sc01i00" Driver Info #0: Driver Status: lpc_ich is active Driver Activation Cmd: "modprobe lpc_ich" Config Status: cfg=new, avail=yes, need=no, active=unknown 22: PCI 1f.2: 0106 SATA controller (AHCI 1.0) [Created at pci.328] Unique ID: w7Y8.tSawXCnS8U4 SysFS ID: /devices/pci0000:00/0000:00:1f.2 SysFS BusID: 0000:00:1f.2 Hardware Class: storage Model: "Intel 7 Series Chipset Family 6-port SATA Controller [AHCI mode]" Vendor: pci 0x8086 "Intel Corporation" Device: pci 0x1e03 "7 Series Chipset Family 6-port SATA Controller [AHCI mode]" SubVendor: pci 0x1028 "Dell" SubDevice: pci 0x058b Revision: 0x04 Driver: "ahci" Driver Modules: "ahci" I/O Ports: 0x2088-0x208f (rw) I/O Ports: 0x209c-0x209f (rw) I/O Ports: 0x2080-0x2087 (rw) I/O Ports: 0x2098-0x209b (rw) I/O Ports: 0x2060-0x207f (rw) Memory Range: 0xd0518000-0xd05187ff (rw,non-prefetchable) IRQ: 26 (341149 events) Module Alias: "pci:v00008086d00001E03sv00001028sd0000058Bbc01sc06i01" Driver Info #0: Driver Status: ahci is active Driver Activation Cmd: "modprobe ahci" Config Status: cfg=new, avail=yes, need=no, active=unknown 23: PCI 1f.3: 0c05 SMBus [Created at pci.328] Unique ID: nS1_.VE8x34jct1A SysFS ID: /devices/pci0000:00/0000:00:1f.3 SysFS BusID: 0000:00:1f.3 Hardware Class: unknown Model: "Intel 7 Series/C210 Series Chipset Family SMBus Controller" Vendor: pci 0x8086 "Intel Corporation" Device: pci 0x1e22 "7 Series/C210 Series Chipset Family SMBus Controller" SubVendor: pci 0x1028 "Dell" SubDevice: pci 0x058b Revision: 0x04 Memory Range: 0xd0514000-0xd05140ff (rw,non-prefetchable) I/O Ports: 0xefa0-0xefbf (rw) IRQ: 18 (no events) Module Alias: "pci:v00008086d00001E22sv00001028sd0000058Bbc0Csc05i00" Driver Info #0: Driver Status: i2c_i801 is active Driver Activation Cmd: "modprobe i2c_i801" Config Status: cfg=new, avail=yes, need=no, active=unknown 24: PCI 100.0: 0282 WLAN controller [Created at pci.328] Unique ID: yWPJ.uibugzCc6b5 Parent ID: z8Q3.cCrMqDQX+R3 SysFS ID: /devices/pci0000:00/0000:00:1c.0/0000:01:00.0 SysFS BusID: 0000:01:00.0 Hardware Class: network Model: "Intel WLAN controller" Vendor: pci 0x8086 "Intel Corporation" Device: pci 0x08b1 SubVendor: pci 0x8086 "Intel Corporation" SubDevice: pci 0x4070 Revision: 0xbb Driver: "iwlwifi" Driver Modules: "iwlwifi" Device File: wlp1s0 Features: WLAN Memory Range: 0xd0400000-0xd0401fff (rw,non-prefetchable) IRQ: 29 (572818 events) HW Address: f8:16:54:f8:24:e2 Link detected: yes WLAN channels: 1 2 3 4 5 6 7 8 9 10 11 12 13 36 40 44 48 52 56 60 64 100 104 108 112 116 120 124 128 132 136 140 WLAN frequencies: 2.412 2.417 2.422 2.427 2.432 2.437 2.442 2.447 2.452 2.457 2.462 2.467 2.472 5.18 5.2 5.22 5.24 5.26 5.28 5.3 5.32 5.5 5.52 5.54 5.56 5.58 5.6 5.62 5.64 5.66 5.68 5.7 WLAN encryption modes: WEP40 WEP104 TKIP CCMP WLAN authentication modes: open sharedkey wpa-psk wpa-eap Module Alias: "pci:v00008086d000008B1sv00008086sd00004070bc02sc80i00" Driver Info #0: Driver Status: iwlwifi is active Driver Activation Cmd: "modprobe iwlwifi" Config Status: cfg=new, avail=yes, need=no, active=unknown Attached to: #19 (PCI bridge) 25: IDE 00.0: 10600 Disk [Created at block.245] Unique ID: 3OOL.+ElxNP801RF Parent ID: w7Y8.tSawXCnS8U4 SysFS ID: /class/block/sda SysFS BusID: 0:0:0:0 SysFS Device Link: /devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0 Hardware Class: disk Model: "SAMSUNG SSD PM83" Vendor: "SAMSUNG" Device: "SSD PM83" Revision: "3D1Q" Driver: "ahci", "sd" Driver Modules: "ahci" Device File: /dev/sda Device Files: /dev/sda, /dev/disk/by-id/ata-SAMSUNG_SSD_PM830_mSATA_256GB_S0XPNYAD800120, /dev/disk/by-id/wwn-0x5002538043584d30 Device Number: block 8:0-8:15 BIOS id: 0x80 Drive status: no medium Config Status: cfg=new, avail=yes, need=no, active=unknown Attached to: #22 (SATA controller) 26: None 00.0: 11300 Partition [Created at block.414] Unique ID: bdUI.SE1wIdpsiiC Parent ID: 3OOL.+ElxNP801RF SysFS ID: /class/block/sda/sda1 Hardware Class: partition Model: "Partition" Device File: /dev/sda1 Device Files: /dev/sda1, /dev/disk/by-id/ata-SAMSUNG_SSD_PM830_mSATA_256GB_S0XPNYAD800120-part1, /dev/disk/by-id/wwn-0x5002538043584d30-part1, /dev/disk/by-partlabel/EFI\x20System, /dev/disk/by-partuuid/67630c1f-875f-426b-9b9d-304defb1ee0c, /dev/disk/by-uuid/2A36-307B Config Status: cfg=new, avail=yes, need=no, active=unknown Attached to: #25 (Disk) 27: None 00.0: 11300 Partition [Created at block.414] Unique ID: 2pkM.SE1wIdpsiiC Parent ID: 3OOL.+ElxNP801RF SysFS ID: /class/block/sda/sda2 Hardware Class: partition Model: "Partition" Device File: /dev/sda2 Device Files: /dev/sda2, /dev/disk/by-id/ata-SAMSUNG_SSD_PM830_mSATA_256GB_S0XPNYAD800120-part2, /dev/disk/by-id/wwn-0x5002538043584d30-part2, /dev/disk/by-label/swap, /dev/disk/by-partlabel/Linux\x20swap, /dev/disk/by-partuuid/1662cc5b-029c-42b3-a57a-073d8b39d811, /dev/disk/by-uuid/7ddaaa70-9c0e-4b06-b76f-57f9544123d1 Config Status: cfg=new, avail=yes, need=no, active=unknown Attached to: #25 (Disk) 28: None 00.0: 11300 Partition [Created at block.414] Unique ID: W__Q.SE1wIdpsiiC Parent ID: 3OOL.+ElxNP801RF SysFS ID: /class/block/sda/sda3 Hardware Class: partition Model: "Partition" Device File: /dev/sda3 Device Files: /dev/sda3, /dev/disk/by-id/ata-SAMSUNG_SSD_PM830_mSATA_256GB_S0XPNYAD800120-part3, /dev/disk/by-id/wwn-0x5002538043584d30-part3, /dev/disk/by-label/arch, /dev/disk/by-partlabel/Linux\x20filesystem, /dev/disk/by-partuuid/3bbf948c-a68f-4193-92be-de9099dd9914, /dev/disk/by-uuid/ffca0b5e-a0d9-41e3-9aa4-20650ff12119 Config Status: cfg=new, avail=yes, need=no, active=unknown Attached to: #25 (Disk) 29: USB 00.0: 10a00 Hub [Created at usb.122] Unique ID: uIhY.FHd55n4xKo7 Parent ID: pwJ7.eNEx6sU0or4 SysFS ID: /devices/pci0000:00/0000:00:1a.0/usb3/3-0:1.0 SysFS BusID: 3-0:1.0 Hardware Class: hub Model: "Linux 3.18.6-1-ARCH ehci_hcd EHCI Host Controller" Hotplug: USB Vendor: usb 0x1d6b "Linux 3.18.6-1-ARCH ehci_hcd" Device: usb 0x0002 "EHCI Host Controller" Revision: "3.18" Serial ID: "0000:00:1a.0" Driver: "hub" Driver Modules: "usbcore" Speed: 480 Mbps Module Alias: "usb:v1D6Bp0002d0318dc09dsc00dp00ic09isc00ip00in00" Driver Info #0: Driver Status: usbcore is active Driver Activation Cmd: "modprobe usbcore" Config Status: cfg=new, avail=yes, need=no, active=unknown Attached to: #17 (USB Controller) 30: USB 00.0: 10a00 Hub [Created at usb.122] Unique ID: KRJj.4Nx_qoDfSd7 Parent ID: uIhY.FHd55n4xKo7 SysFS ID: /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1:1.0 SysFS BusID: 3-1:1.0 Hardware Class: hub Model: "Hub" Hotplug: USB Vendor: usb 0x8087 Device: usb 0x0024 Driver: "hub" Driver Modules: "usbcore" Speed: 480 Mbps Module Alias: "usb:v8087p0024d0000dc09dsc00dp01ic09isc00ip00in00" Driver Info #0: Driver Status: usbcore is active Driver Activation Cmd: "modprobe usbcore" Config Status: cfg=new, avail=yes, need=no, active=unknown Attached to: #29 (Hub) 31: USB 00.0: 0000 Unclassified device [Created at usb.122] Unique ID: s8zo.VIVVYWREfzA Parent ID: KRJj.4Nx_qoDfSd7 SysFS ID: /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5/3-1.5:1.0 SysFS BusID: 3-1.5:1.0 Hardware Class: unknown Model: "CN01RH717248726AD005A00 Laptop_Integrated_Webcam_1.3M" Hotplug: USB Vendor: usb 0x1bcf "CN01RH717248726AD005A00" Device: usb 0x288f "Laptop_Integrated_Webcam_1.3M" Revision: "27.10" Driver: "uvcvideo" Driver Modules: "uvcvideo" Device File: /dev/input/event11 Device Files: /dev/input/event11, /dev/input/by-id/usb-CN01RH717248726AD005A00_Laptop_Integrated_Webcam_1.3M-event-if00, /dev/input/by-path/pci-0000:00:1a.0-usb-0:1.5:1.0-event Device Number: char 13:75 Speed: 480 Mbps Module Alias: "usb:v1BCFp288Fd2710dcEFdsc02dp01ic0Eisc01ip00in00" Driver Info #0: Driver Status: uvcvideo is active Driver Activation Cmd: "modprobe uvcvideo" Config Status: cfg=new, avail=yes, need=no, active=unknown Attached to: #30 (Hub) 33: USB 00.0: 10a00 Hub [Created at usb.122] Unique ID: zPk0.oLWCeziExdF Parent ID: 1GTX.1Udhlsf46A2 SysFS ID: /devices/pci0000:00/0000:00:1d.0/usb4/4-0:1.0 SysFS BusID: 4-0:1.0 Hardware Class: hub Model: "Linux 3.18.6-1-ARCH ehci_hcd EHCI Host Controller" Hotplug: USB Vendor: usb 0x1d6b "Linux 3.18.6-1-ARCH ehci_hcd" Device: usb 0x0002 "EHCI Host Controller" Revision: "3.18" Serial ID: "0000:00:1d.0" Driver: "hub" Driver Modules: "usbcore" Speed: 480 Mbps Module Alias: "usb:v1D6Bp0002d0318dc09dsc00dp00ic09isc00ip00in00" Driver Info #0: Driver Status: usbcore is active Driver Activation Cmd: "modprobe usbcore" Config Status: cfg=new, avail=yes, need=no, active=unknown Attached to: #20 (USB Controller) 34: USB 00.0: 10a00 Hub [Created at usb.122] Unique ID: PYMB.4Nx_qoDfSd7 Parent ID: zPk0.oLWCeziExdF SysFS ID: /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1:1.0 SysFS BusID: 4-1:1.0 Hardware Class: hub Model: "Hub" Hotplug: USB Vendor: usb 0x8087 Device: usb 0x0024 Driver: "hub" Driver Modules: "usbcore" Speed: 480 Mbps Module Alias: "usb:v8087p0024d0000dc09dsc00dp01ic09isc00ip00in00" Driver Info #0: Driver Status: usbcore is active Driver Activation Cmd: "modprobe usbcore" Config Status: cfg=new, avail=yes, need=no, active=unknown Attached to: #33 (Hub) 35: USB 00.0: 11500 Bluetooth Device [Created at usb.122] Unique ID: YdCm.cdUiY6836R9 Parent ID: PYMB.4Nx_qoDfSd7 SysFS ID: /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5:1.0 SysFS BusID: 4-1.5:1.0 Hardware Class: bluetooth Model: "Bluetooth Device" Hotplug: USB Vendor: usb 0x8087 Device: usb 0x07dc Revision: "0.01" Driver: "btusb" Driver Modules: "btusb" Speed: 12 Mbps Module Alias: "usb:v8087p07DCd0001dcE0dsc01dp01icE0isc01ip01in00" Driver Info #0: Driver Status: btusb is active Driver Activation Cmd: "modprobe btusb" Config Status: cfg=new, avail=yes, need=no, active=unknown Attached to: #34 (Hub) 37: USB 00.0: 10a00 Hub [Created at usb.122] Unique ID: k4bc.2DFUsyrieMD Parent ID: MZfG.y1p0BiaRo35 SysFS ID: /devices/pci0000:00/0000:00:14.0/usb1/1-0:1.0 SysFS BusID: 1-0:1.0 Hardware Class: hub Model: "Linux 3.18.6-1-ARCH xhci-hcd xHCI Host Controller" Hotplug: USB Vendor: usb 0x1d6b "Linux 3.18.6-1-ARCH xhci-hcd" Device: usb 0x0002 "xHCI Host Controller" Revision: "3.18" Serial ID: "0000:00:14.0" Driver: "hub" Driver Modules: "usbcore" Speed: 480 Mbps Module Alias: "usb:v1D6Bp0002d0318dc09dsc00dp01ic09isc00ip00in00" Driver Info #0: Driver Status: usbcore is active Driver Activation Cmd: "modprobe usbcore" Config Status: cfg=new, avail=yes, need=no, active=unknown Attached to: #15 (USB Controller) 38: USB 00.0: 10a00 Hub [Created at usb.122] Unique ID: pBe4.xYNhIwdOaa6 Parent ID: MZfG.y1p0BiaRo35 SysFS ID: /devices/pci0000:00/0000:00:14.0/usb2/2-0:1.0 SysFS BusID: 2-0:1.0 Hardware Class: hub Model: "Linux 3.18.6-1-ARCH xhci-hcd xHCI Host Controller" Hotplug: USB Vendor: usb 0x1d6b "Linux 3.18.6-1-ARCH xhci-hcd" Device: usb 0x0003 "xHCI Host Controller" Revision: "3.18" Serial ID: "0000:00:14.0" Driver: "hub" Driver Modules: "usbcore" Module Alias: "usb:v1D6Bp0003d0318dc09dsc00dp03ic09isc00ip00in00" Driver Info #0: Driver Status: usbcore is active Driver Activation Cmd: "modprobe usbcore" Config Status: cfg=new, avail=yes, need=no, active=unknown Attached to: #15 (USB Controller) 39: PS/2 00.0: 10800 Keyboard [Created at input.226] Unique ID: 3FDI.+49ps10DtUF Hardware Class: keyboard Model: "AT Translated Set 2 keyboard" Vendor: 0x0001 Device: 0x0001 "AT Translated Set 2 keyboard" Compatible to: int 0x0211 0x0001 Device File: /dev/input/event5 Device Files: /dev/input/event5, /dev/input/by-path/platform-i8042-serio-0-event-kbd Device Number: char 13:69 Driver Info #0: XkbRules: xfree86 XkbModel: pc104 Config Status: cfg=new, avail=yes, need=no, active=unknown 40: PS/2 00.0: 10500 PS/2 Mouse [Created at input.249] Unique ID: AH6Q.kjMWrPZ39l6 Hardware Class: mouse Model: "CyPS/2 Cypress Trackpad" Vendor: 0x0002 Device: 0x0011 "CyPS/2 Cypress Trackpad" Compatible to: int 0x0210 0x0003 Device File: /dev/input/mice (/dev/input/mouse0) Device Files: /dev/input/mice, /dev/input/mouse0, /dev/input/event13, /dev/input/by-path/platform-i8042-serio-1-event-mouse, /dev/input/by-path/platform-i8042-serio-1-mouse Device Number: char 13:63 (char 13:32) Driver Info #0: Buttons: 3 Wheels: 0 XFree86 Protocol: explorerps/2 GPM Protocol: exps2 Config Status: cfg=new, avail=yes, need=no, active=unknown 41: None 00.0: 10103 CPU [Created at cpu.452] Unique ID: rdCR.j8NaKXDZtZ6 Hardware Class: cpu Arch: X86-64 Vendor: "GenuineIntel" Model: 6.58.9 "Intel(R) Core(TM) i7-3537U CPU @ 2.00GHz" Features: fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,rdtscp,lm,constant_tsc,arch_perfmon,pebs,bts,rep_good,nopl,xtopology,nonstop_tsc,aperfmperf,eagerfpu,pni,pclmulqdq,dtes64,monitor,ds_cpl,vmx,est,tm2,ssse3,cx16,xtpr,pdcm,pcid,sse4_1,sse4_2,x2apic,popcnt,tsc_deadline_timer,aes,xsave,avx,f16c,rdrand,lahf_lm,ida,arat,epb,pln,pts,dtherm,tpr_shadow,vnmi,flexpriority,ept,vpid,fsgsbase,smep,erms,xsaveopt Clock: 2987 MHz BogoMips: 4990.52 Cache: 4096 kb Units/Processor: 16 Config Status: cfg=new, avail=yes, need=no, active=unknown 42: None 01.0: 10103 CPU [Created at cpu.452] Unique ID: wkFv.j8NaKXDZtZ6 Hardware Class: cpu Arch: X86-64 Vendor: "GenuineIntel" Model: 6.58.9 "Intel(R) Core(TM) i7-3537U CPU @ 2.00GHz" Features: fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,rdtscp,lm,constant_tsc,arch_perfmon,pebs,bts,rep_good,nopl,xtopology,nonstop_tsc,aperfmperf,eagerfpu,pni,pclmulqdq,dtes64,monitor,ds_cpl,vmx,est,tm2,ssse3,cx16,xtpr,pdcm,pcid,sse4_1,sse4_2,x2apic,popcnt,tsc_deadline_timer,aes,xsave,avx,f16c,rdrand,lahf_lm,ida,arat,epb,pln,pts,dtherm,tpr_shadow,vnmi,flexpriority,ept,vpid,fsgsbase,smep,erms,xsaveopt Clock: 2980 MHz BogoMips: 4990.52 Cache: 4096 kb Units/Processor: 16 Config Status: cfg=new, avail=yes, need=no, active=unknown 43: None 02.0: 10103 CPU [Created at cpu.452] Unique ID: +rIN.j8NaKXDZtZ6 Hardware Class: cpu Arch: X86-64 Vendor: "GenuineIntel" Model: 6.58.9 "Intel(R) Core(TM) i7-3537U CPU @ 2.00GHz" Features: fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,rdtscp,lm,constant_tsc,arch_perfmon,pebs,bts,rep_good,nopl,xtopology,nonstop_tsc,aperfmperf,eagerfpu,pni,pclmulqdq,dtes64,monitor,ds_cpl,vmx,est,tm2,ssse3,cx16,xtpr,pdcm,pcid,sse4_1,sse4_2,x2apic,popcnt,tsc_deadline_timer,aes,xsave,avx,f16c,rdrand,lahf_lm,ida,arat,epb,pln,pts,dtherm,tpr_shadow,vnmi,flexpriority,ept,vpid,fsgsbase,smep,erms,xsaveopt Clock: 3080 MHz BogoMips: 4990.52 Cache: 4096 kb Units/Processor: 16 Config Status: cfg=new, avail=yes, need=no, active=unknown 44: None 03.0: 10103 CPU [Created at cpu.452] Unique ID: 4zLr.j8NaKXDZtZ6 Hardware Class: cpu Arch: X86-64 Vendor: "GenuineIntel" Model: 6.58.9 "Intel(R) Core(TM) i7-3537U CPU @ 2.00GHz" Features: fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,rdtscp,lm,constant_tsc,arch_perfmon,pebs,bts,rep_good,nopl,xtopology,nonstop_tsc,aperfmperf,eagerfpu,pni,pclmulqdq,dtes64,monitor,ds_cpl,vmx,est,tm2,ssse3,cx16,xtpr,pdcm,pcid,sse4_1,sse4_2,x2apic,popcnt,tsc_deadline_timer,aes,xsave,avx,f16c,rdrand,lahf_lm,ida,arat,epb,pln,pts,dtherm,tpr_shadow,vnmi,flexpriority,ept,vpid,fsgsbase,smep,erms,xsaveopt Clock: 2919 MHz BogoMips: 4990.52 Cache: 4096 kb Units/Processor: 16 Config Status: cfg=new, avail=yes, need=no, active=unknown 45: None 00.0: 10700 Loopback [Created at net.125] Unique ID: ZsBS.GQNx7L4uPNA SysFS ID: /class/net/lo Hardware Class: network interface Model: "Loopback network interface" Device File: lo Link detected: yes Config Status: cfg=new, avail=yes, need=no, active=unknown 46: None 00.0: 10701 Ethernet [Created at net.125] Unique ID: eAgB.ndpeucax6V1 Parent ID: yWPJ.uibugzCc6b5 SysFS ID: /class/net/wlp1s0 SysFS Device Link: /devices/pci0000:00/0000:00:1c.0/0000:01:00.0 Hardware Class: network interface Model: "Ethernet network interface" Driver: "iwlwifi" Driver Modules: "iwlwifi" Device File: wlp1s0 HW Address: f8:16:54:f8:24:e2 Link detected: yes Config Status: cfg=new, avail=yes, need=no, active=unknown Attached to: #24 (WLAN controller) -------------- next part -------------- 00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller (rev 09) 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04) 00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 (rev 04) 00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) 00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 (rev c4) 00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) 00:1f.0 ISA bridge: Intel Corporation QS77 Express Chipset LPC Controller (rev 04) 00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04) 00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller (rev 04) 01:00.0 Network controller: Intel Corporation Wireless 7260 (rev bb) From tpearson at raptorengineeringinc.com Thu Feb 12 02:56:45 2015 From: tpearson at raptorengineeringinc.com (Timothy Pearson) Date: Wed, 11 Feb 2015 19:56:45 -0600 Subject: [coreboot] ASUS KFSN4-DRe: Board status with incomplete coreboot console and time stamps showing long device init In-Reply-To: <1423694174.2630.103.camel@users.sourceforge.net> References: <1423694174.2630.103.camel@users.sourceforge.net> Message-ID: <54DC085D.6040500@raptorengineeringinc.com> On 02/11/2015 04:36 PM, Paul Menzel wrote: > Dear Timothy, > > > thanks again for improving the support for the ASUS KFSN4-DRE and being > so responsive. It?s a great example for how to work with upstream! > > You uploaded the board status output [1] with commit 8057285 [2]. > Thanks! > > But, it looks like a lot of information is missing from the coreboot > console messages, like it was cut. Could you upload another run with the > same commit or, for example, from latest master? I can, but I'm going to wait until the patches up for review are merged as it will make testing much easier on this end. There are just too many patches flying around right now and if I get even one wrong in my local build tree my development board won't boot, thus requiring a manual ROM swap. > Does `util/cbmem/cbmem -c` show all messages? You?d need to enable CBMEM > console in Kconfig for that though. (SeaBIOS is also able to write its > messages to CBMEM console.) SeaBIOS wasn't completely working with CBMEM last I checked, though that may have been the VGA/serial messages only that were getting lost. > Lastly, you put the time stamps on the Wiki page [3]. Could you please > also upload those into the board status repository as people expect such > information to be there? They would probably not go looking in the Wiki > and in the board status repository the time stamps can be mapped to a > specific commit. > > 10:start of ramstage 20,261 > 30:device enumeration 25,566 (5,304) > 40:device configuration 50,219 (24,653) > 50:device enable 108,559 (58,339) > 60:device initialization 109,734 (1,175) > 70:device setup done 1,056,523 (946,789) > 75:cbmem post 1,057,578 (1,054) > 80:write tables 1,058,641 (1,063) > 90:load payload 1,064,180 (5,539) > 99:selfboot jump 1,123,383 (59,202) > > Looking at the actual time stamps below do you see from your logs why > the device initialization takes almost one second? As the timings on the > Wiki page [3] show, it?s not related to enabling graphics/VGA. > > I guess SeaBIOS executes fairly quickly too? Do you have timing data for > that as well? Or do you use COMBOOT as a payload? > > Just for comparison, how long does the vendor firmware take to get to > COMBOOT [4] or whatever you use? I'd have to break out a stopwatch to see. Subjectively coreboot loads approximately twice as fast; if I can patch out the various option ROM delays (where SeaBIOS and iPXE are waiting for a potential keyboard interrupt) it would be even faster. -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 http://www.raptorengineeringinc.com From peter at stuge.se Thu Feb 12 06:17:05 2015 From: peter at stuge.se (Peter Stuge) Date: Thu, 12 Feb 2015 06:17:05 +0100 Subject: [coreboot] dell sputnik In-Reply-To: <1423697408.8208.1.camel@gmail.com> References: <1423697408.8208.1.camel@gmail.com> Message-ID: <20150212051705.5851.qmail@stuge.se> Benny wrote: > is there a chance coreboot comes to the Dell Sputnik (XPS13, L322X1Y1)? On its own? No, not really. It takes fairly significant development work, which will not happen by itself. There exists code in coreboot for similar platforms which may or may not be reusable, beyond that you're looking at studying about 30 years of PC development history in order to learn what is required to complete the missing pieces. //Peter From benediktwindolph at gmail.com Thu Feb 12 10:54:21 2015 From: benediktwindolph at gmail.com (benny windolph) Date: Thu, 12 Feb 2015 10:54:21 +0100 Subject: [coreboot] dell sputnik In-Reply-To: <20150212051705.5851.qmail@stuge.se> References: <1423697408.8208.1.camel@gmail.com> <20150212051705.5851.qmail@stuge.se> Message-ID: Thanks for the clarification, but is it possible that the coreboot-team will put this device on its agenda to bring coreboot to the dell sputnik? regards benny Am 12.02.2015 06:17 schrieb "Peter Stuge" : > Benny wrote: > > is there a chance coreboot comes to the Dell Sputnik (XPS13, L322X1Y1)? > > On its own? No, not really. It takes fairly significant development > work, which will not happen by itself. There exists code in coreboot > for similar platforms which may or may not be reusable, beyond that > you're looking at studying about 30 years of PC development history > in order to learn what is required to complete the missing pieces. > > > //Peter > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at stuge.se Thu Feb 12 10:58:56 2015 From: peter at stuge.se (Peter Stuge) Date: Thu, 12 Feb 2015 10:58:56 +0100 Subject: [coreboot] dell sputnik In-Reply-To: References: <1423697408.8208.1.camel@gmail.com> <20150212051705.5851.qmail@stuge.se> Message-ID: <20150212095856.25880.qmail@stuge.se> benny windolph wrote: > Thanks for the clarification, but is it possible that the coreboot-team > will put this device on its agenda to bring coreboot to the dell sputnik? It's not likely. If you care about something in open source you have to do the work. There's nothing wrong with asking someone else to do it, but if they don't then that's fine too. //Peter From benediktwindolph at gmail.com Thu Feb 12 11:11:30 2015 From: benediktwindolph at gmail.com (benny windolph) Date: Thu, 12 Feb 2015 11:11:30 +0100 Subject: [coreboot] dell sputnik In-Reply-To: <20150212095856.25880.qmail@stuge.se> References: <1423697408.8208.1.camel@gmail.com> <20150212051705.5851.qmail@stuge.se> <20150212095856.25880.qmail@stuge.se> Message-ID: Its absolutely fine if the team wont do it. I am not a developer, i would rather donate or something. But its okay. Thanks anyway and have a nice day Am 12.02.2015 10:59 schrieb "Peter Stuge" : > benny windolph wrote: > > Thanks for the clarification, but is it possible that the coreboot-team > > will put this device on its agenda to bring coreboot to the dell sputnik? > > It's not likely. If you care about something in open source you have > to do the work. There's nothing wrong with asking someone else to do > it, but if they don't then that's fine too. > > > //Peter > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at stuge.se Thu Feb 12 11:45:57 2015 From: peter at stuge.se (Peter Stuge) Date: Thu, 12 Feb 2015 11:45:57 +0100 Subject: [coreboot] dell sputnik In-Reply-To: References: <1423697408.8208.1.camel@gmail.com> <20150212051705.5851.qmail@stuge.se> <20150212095856.25880.qmail@stuge.se> Message-ID: <20150212104557.29124.qmail@stuge.se> benny windolph wrote: > Its absolutely fine if the team wont do it. I am not a developer, i > would rather donate or something. But its okay. Donations are difficult, but still much appreciated! The scarce resource is (as always?) development time, unfortunately neither money nor hardware. > Thanks anyway and have a nice day Thanks - the same to you! //Peter From mysterysscherub at cox.net Thu Feb 12 10:14:37 2015 From: mysterysscherub at cox.net (Erika Tibbs) Date: Thu, 12 Feb 2015 02:14:37 -0700 Subject: [coreboot] [review 1/2] Subject: Prepare for Clevo D900T Message-ID: Hi, Im looking at picking up an old alienware with this mainboard in it. I have read that the mainboard actually supports up to 8gb ram and that it can handle a 512mg video card. It looks like you may have done some bios tweaking and such to allow for significant upgrading beyond original bios limits. ?If this is the case wondering if you would share the program. I've read that this mainboard seems to have issues with seeing new hdds larger than 120gb(at least in the alienware model I'm looking at) and I'm hoping that among other improvements if you have made a bios upgrade that it might also address this issue.? Thank you in advance, Erika Sent from my Sprint Samsung Galaxy? Note 4. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcj303 at gmail.com Sat Feb 14 01:05:28 2015 From: marcj303 at gmail.com (Marc Jones) Date: Sat, 14 Feb 2015 00:05:28 +0000 Subject: [coreboot] GSOC 2015 Preperations Message-ID: Hi Everyone, It is time for coreboot to apply for GSOC 2015. We could use your help. We need student project ideas, mentors, and qualified students! Please update the wiki page with project ideas. http://www.coreboot.org/Project_Ideas Let me know if you would like to be a student mentor this summer. You need to signup with Google and then I can add you to the project. Start informing prospective GSOC students about coreboot. Please be helpful to new faces in IRC and direct them to me or Patrick if they have questions. Regards, Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: From mr.nuke.me at gmail.com Sat Feb 14 01:13:01 2015 From: mr.nuke.me at gmail.com (Alexandru Gagniuc) Date: Fri, 13 Feb 2015 18:13:01 -0600 Subject: [coreboot] GSOC 2015 Preperations In-Reply-To: References: Message-ID: <4150716.nvA6L3ET4p@nukelap.gtech> On Saturday, February 14, 2015 12:05:28 AM Marc Jones wrote: > Hi Everyone, > Hi, > Please update the wiki page with project ideas. > http://www.coreboot.org/Project_Ideas > That's the first unlocked page in the coreboot wiki I have seen for quite some time. Alex From marcj303 at gmail.com Sat Feb 14 01:33:11 2015 From: marcj303 at gmail.com (Marc Jones) Date: Sat, 14 Feb 2015 00:33:11 +0000 Subject: [coreboot] GSOC 2015 Preperations References: <4150716.nvA6L3ET4p@nukelap.gtech> Message-ID: On Fri Feb 13 2015 at 5:13:04 PM Alexandru Gagniuc wrote: > On Saturday, February 14, 2015 12:05:28 AM Marc Jones wrote: > > Hi Everyone, > > > Hi, > > > Please update the wiki page with project ideas. > > http://www.coreboot.org/Project_Ideas > > > That's the first unlocked page in the coreboot wiki I have seen for quite > some > time. > This comment is off topic. Please don't hijack the thread about GSOC. If you would like to discuss locked wiki pages please start another thread. Thanks, Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: From mr.nuke.me at gmail.com Sat Feb 14 02:14:26 2015 From: mr.nuke.me at gmail.com (Alexandru Gagniuc) Date: Fri, 13 Feb 2015 19:14:26 -0600 Subject: [coreboot] On the subject of collaboration In-Reply-To: References: <4150716.nvA6L3ET4p@nukelap.gtech> Message-ID: <5037198.UkVmxV0nFL@nukelap.gtech> On Saturday, February 14, 2015 12:33:11 AM Marc Jones wrote: > On Fri Feb 13 2015 at 5:13:04 PM Alexandru Gagniuc > > wrote: > > On Saturday, February 14, 2015 12:05:28 AM Marc Jones wrote: > > > Hi Everyone, > > > > Hi, > > > > > Please update the wiki page with project ideas. > > > http://www.coreboot.org/Project_Ideas > > > > That's the first unlocked page in the coreboot wiki I have seen for quite > > some > > time. > > This comment is off topic. Please don't hijack the thread about GSOC. If > you would like to discuss locked wiki pages please start another thread. > I respectfully disagree. I think collaboration is very relevant, _especially_ in the context of GSoC. And yet we have been moving away from this school of thought. It's that time of the year it seems. Last year, there were talks about reducing the number of gerrit submitters. I'm certain you remember the anger this caused amongst non-commercial members of the community when the proposed list contained exclusively commercial community members, and I'm certain you remember how that almost lead to a fork. This year's theme goes on the same lines. Except that it's not as tactful as last year. It's no longer "I'm planning to do this". It's "I've already done this". Let's see. We've locked most wiki pages to a select few contributors. A so-called code of conduct was unilaterally introduced. Let's look at each in part. When it comes to the locked wiki pages keep in mind that most contributors make minor edits in response to real events. It has happened in the past that people were confused by the wording. So someone comes in and clarifies it on the spot, before they forget. Now those contributions get lost behind a non- collaborative barrier. Now the code of conduct... What constitutes any of the 'bad' behaviors mentioned? What you really get is people refusing to express an idea or opinion in fear of violating said ill-defined code, and in fear of retaliation. It's called a chilling effect. Again, good ideas get lost behind a non-collaborative barrier. Do we really want to push people's nerves every year until we finally get a fork? Alex > Thanks, > Marc From lynxis at fe80.eu Sat Feb 14 02:50:15 2015 From: lynxis at fe80.eu (Alexander Couzens) Date: Sat, 14 Feb 2015 02:50:15 +0100 Subject: [coreboot] GSOC 2015 Preperations In-Reply-To: References: Message-ID: <20150214025015.44c06003@lazus.yip> Hi Marc, I would like to attend as a student this year. I'm open for most of the ideas at the page. Here are some of my ideas. - porting new mainboards (hp micro n54L and x121e atm) - porting new arm platforms - refactoring amd code - create an opensource firmware for some Thinkpad (H8S based) - building a basic testing system (looking for a x60 or other supported_board) - add usb debug support to SerialICE Best, lynxis On Sat, 14 Feb 2015 00:05:28 +0000 Marc Jones wrote: > Hi Everyone, > > It is time for coreboot to apply for GSOC 2015. We could use your help. We > need student project ideas, mentors, and qualified students! > > Please update the wiki page with project ideas. > http://www.coreboot.org/Project_Ideas > > Let me know if you would like to be a student mentor this summer. You need > to signup with Google and then I can add you to the project. > > Start informing prospective GSOC students about coreboot. Please be helpful > to new faces in IRC and direct them to me or Patrick if they have questions. > > Regards, > Marc -- Alexander Couzens mail: lynxis at fe80.eu jabber: lynxis at jabber.ccc.de mobile: +4915123277221 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From peter at stuge.se Sat Feb 14 02:54:09 2015 From: peter at stuge.se (Peter Stuge) Date: Sat, 14 Feb 2015 02:54:09 +0100 Subject: [coreboot] On the subject of collaboration In-Reply-To: <5037198.UkVmxV0nFL@nukelap.gtech> References: <4150716.nvA6L3ET4p@nukelap.gtech> <5037198.UkVmxV0nFL@nukelap.gtech> Message-ID: <20150214015409.10626.qmail@stuge.se> Alexandru Gagniuc wrote: > fork? If you feel that it would be good then please do not waste any more time. //Peter From mr.nuke.me at gmail.com Sat Feb 14 02:59:33 2015 From: mr.nuke.me at gmail.com (Alexandru Gagniuc) Date: Fri, 13 Feb 2015 19:59:33 -0600 Subject: [coreboot] On the subject of collaboration In-Reply-To: <20150214015409.10626.qmail@stuge.se> References: <5037198.UkVmxV0nFL@nukelap.gtech> <20150214015409.10626.qmail@stuge.se> Message-ID: <2099174.gAdcABSlky@nukelap.gtech> On Saturday, February 14, 2015 02:54:09 AM Peter Stuge wrote: > Alexandru Gagniuc wrote: > > fork? > Peter, you misquote me. > If you feel that it would be good then please do not waste any more time. > And then you misinterpret what I say. Alex From peter at stuge.se Sat Feb 14 03:01:15 2015 From: peter at stuge.se (Peter Stuge) Date: Sat, 14 Feb 2015 03:01:15 +0100 Subject: [coreboot] GSOC 2015 Preperations In-Reply-To: <20150214025015.44c06003@lazus.yip> References: <20150214025015.44c06003@lazus.yip> Message-ID: <20150214020115.11192.qmail@stuge.se> Alexander Couzens wrote: > - refactoring amd code I think this is an interesting project! As I understand it, the idea is to refactor the AMD-contributed AGESA trees into "our own" code. > - create an opensource firmware for some Thinkpad (H8S based) EC firmware, just to clarify. > - building a basic testing system (looking for a x60 or other supported_board) This has sort-of already been done, but testing is a topic I have been had ideas about for nearly a decade, and there still isn't a great universal tool. //Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From peter at stuge.se Sat Feb 14 03:05:55 2015 From: peter at stuge.se (Peter Stuge) Date: Sat, 14 Feb 2015 03:05:55 +0100 Subject: [coreboot] On the subject of collaboration In-Reply-To: <2099174.gAdcABSlky@nukelap.gtech> References: <5037198.UkVmxV0nFL@nukelap.gtech> <20150214015409.10626.qmail@stuge.se> <2099174.gAdcABSlky@nukelap.gtech> Message-ID: <20150214020555.11524.qmail@stuge.se> Alexandru Gagniuc wrote: > > Alexandru Gagniuc wrote: > > > fork? > > Peter, you misquote me. That *is* the last line of your mail. It's just one word though, so there's no context. > > If you feel that it would be good then please do not waste any more time. > > And then you misinterpret what I say. The you above isn't specifically you personally, but rather meant to those who want to create a fork. Forking can be a good thing, when done gracefully. But I also know the significant effort needed to create and maintain a respectful fork. //Peter From ality at pbrane.org Sat Feb 14 03:08:51 2015 From: ality at pbrane.org (Anthony Martin) Date: Fri, 13 Feb 2015 18:08:51 -0800 Subject: [coreboot] On the subject of collaboration In-Reply-To: <20150214015409.10626.qmail@stuge.se> References: <4150716.nvA6L3ET4p@nukelap.gtech> <5037198.UkVmxV0nFL@nukelap.gtech> <20150214015409.10626.qmail@stuge.se> Message-ID: <20150214020851.GA9995@dinah> Peter Stuge once said: > Alexandru Gagniuc wrote: > > fork? > > If you feel that it would be good then please do not waste any more time. At least we know malefic goading is permitted by the code of conduct. Anthony From mr.nuke.me at gmail.com Sat Feb 14 03:25:44 2015 From: mr.nuke.me at gmail.com (Alexandru Gagniuc) Date: Fri, 13 Feb 2015 20:25:44 -0600 Subject: [coreboot] GSOC 2015 Preperations In-Reply-To: <20150214025015.44c06003@lazus.yip> References: <20150214025015.44c06003@lazus.yip> Message-ID: <2200736.W0LpzbiCoi@nukelap.gtech> On Saturday, February 14, 2015 02:50:15 AM Alexander Couzens wrote: > I would like to attend as a student this year. > I'm open for most of the ideas at the page. > Here are some of my ideas. > > - porting new mainboards (hp micro n54L and x121e atm) > - porting new arm platforms > - refactoring amd code > - create an opensource firmware for some Thinkpad (H8S based) > - building a basic testing system (looking for a x60 or other > supported_board) - add usb debug support to SerialICE > Porting new boards is of limited value. As a former GSoC student, I can attest that the more generic the subject of your proposal is, the higher your chances of being selected. That's why a board port is a bit of a crapshoot. New ARM platforms is definitely an interesting topic. Although you have to consider whether your platform of choice can work blob-free, and whether or not there is already a uboot port for it. All these things, I believe, will be factored in. Refactoring code seems to have been a popular GSoC theme since I've been doing coreboot. Personally, and I will not be part of the decision making, I think this is of limited value when that source code works. You see, coreboot is nowadays being bombarded from all directions with binary-only components. I think that you can do a great deal more good by working on eliminating some of these blobs. Though tread carefully if you choose this path... reverse engineering is not a valid project for GSoC, so RE should not be part of your proposal or project. And this point is where you've really gotten my attention. It's gold. Pure gold. Having a free software implementation of H8 firmware is a worthy goal in itself. Although there's the argument to be made that there already is such a thing in ChromeEC, your should stress the counterpoint that the EC is not something that can just be replaced, and the mere popularity of the H8 makes it a great platform to target. Another amazing subject that I would suggest you consider is creating a free replacement for the SMU firmware in AMD chipsets. Talk to ruik about it. He may be able to tell you more. Regarding AMD chips up to fam16 at least, this is the final frontier. Alex From peter at stuge.se Sat Feb 14 03:27:43 2015 From: peter at stuge.se (Peter Stuge) Date: Sat, 14 Feb 2015 03:27:43 +0100 Subject: [coreboot] On the subject of collaboration In-Reply-To: <20150214020851.GA9995@dinah> References: <4150716.nvA6L3ET4p@nukelap.gtech> <5037198.UkVmxV0nFL@nukelap.gtech> <20150214015409.10626.qmail@stuge.se> <20150214020851.GA9995@dinah> Message-ID: <20150214022743.13145.qmail@stuge.se> Anthony Martin wrote: > Peter Stuge once said: > > Alexandru Gagniuc wrote: > > > fork? > > > > If you feel that it would be good then please do not waste any more time. > > At least we know malefic goading is permitted by the code of conduct. That's confusing to me. I'm not being the slightest malicious and I'm also not goading. I'll try to clarify: If there are some developers who feel that a fork would be a good thing and that they can pull it off then I think they should go for it, rather than feeling bad in a project which they essentially disagree with. It would be much better for everybody if they respectfully did their own thing. Some of you may know that I have a bit of experience with forks, and while it is a frequent opinion that forks are a waste of time I actually think it is the other way around - if there are different goals or different expectations then it is really important to be open and honest about that, and simply part ways on good terms. Not all forks happen like that, probably because of human nature, but with some effort it is certainly possible, and I think it's something worth striving for. //Peter From mr.nuke.me at gmail.com Sat Feb 14 03:27:59 2015 From: mr.nuke.me at gmail.com (Alexandru Gagniuc) Date: Fri, 13 Feb 2015 20:27:59 -0600 Subject: [coreboot] On the subject of collaboration In-Reply-To: <20150214020851.GA9995@dinah> References: <20150214015409.10626.qmail@stuge.se> <20150214020851.GA9995@dinah> Message-ID: <6555112.osMBMoZ4dJ@nukelap.gtech> On Friday, February 13, 2015 06:08:51 PM Anthony Martin wrote: > Peter Stuge once said: > > Alexandru Gagniuc wrote: > > > fork? > > > > If you feel that it would be good then please do not waste any more time. > > At least we know malefic goading is permitted by the code of conduct. > Coreboot has always been a free speech zone. One of the reasons I don't subscribe to the code of conduct is that it destroys this very fundamental aspect of our community. Alex From c-d.hailfinger.devel.2006 at gmx.net Sat Feb 14 09:44:32 2015 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 14 Feb 2015 09:44:32 +0100 Subject: [coreboot] On the subject of collaboration In-Reply-To: <20150214022743.13145.qmail@stuge.se> References: <4150716.nvA6L3ET4p@nukelap.gtech> <5037198.UkVmxV0nFL@nukelap.gtech> <20150214015409.10626.qmail@stuge.se> <20150214020851.GA9995@dinah> <20150214022743.13145.qmail@stuge.se> Message-ID: <54DF0AF0.1050301@gmx.net> On 14.02.2015 03:27, Peter Stuge wrote: >> Peter Stuge once said: >>> Alexandru Gagniuc wrote: >>>> fork? >>>> > a fork would be a good thing > Hey look, I can quote without context, too! I hope this explains why quoting without context should not be done. Regards, Carl-Daniel From peter at stuge.se Sat Feb 14 14:37:11 2015 From: peter at stuge.se (Peter Stuge) Date: Sat, 14 Feb 2015 14:37:11 +0100 Subject: [coreboot] On the subject of collaboration In-Reply-To: <54DF0AF0.1050301@gmx.net> References: <4150716.nvA6L3ET4p@nukelap.gtech> <5037198.UkVmxV0nFL@nukelap.gtech> <20150214015409.10626.qmail@stuge.se> <20150214020851.GA9995@dinah> <20150214022743.13145.qmail@stuge.se> <54DF0AF0.1050301@gmx.net> Message-ID: <20150214133711.9517.qmail@stuge.se> Carl-Daniel Hailfinger wrote: > >>>> fork? > > > > a fork would be a good thing > > Hey look, I can quote without context, too! > I hope this explains why quoting without context should not be done. Did you just hijack (or fork, as Alex likes to call it) the thread? //Peter From c-d.hailfinger.devel.2006 at gmx.net Sat Feb 14 17:56:23 2015 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 14 Feb 2015 17:56:23 +0100 Subject: [coreboot] GSOC 2015 Preperations In-Reply-To: <2200736.W0LpzbiCoi@nukelap.gtech> References: <20150214025015.44c06003@lazus.yip> <2200736.W0LpzbiCoi@nukelap.gtech> Message-ID: <54DF7E37.5090301@gmx.net> On 14.02.2015 03:25, Alexandru Gagniuc wrote: > On Saturday, February 14, 2015 02:50:15 AM Alexander Couzens wrote: >> I would like to attend as a student this year. >> I'm open for most of the ideas at the page. >> Here are some of my ideas. >> >> - porting new mainboards (hp micro n54L and x121e atm) >> - porting new arm platforms >> - refactoring amd code >> - create an opensource firmware for some Thinkpad (H8S based) >> - building a basic testing system (looking for a x60 or other >> supported_board) >> - add usb debug support to SerialICE > Porting new boards is of limited value. Indeed. Especially when those "new" boards are already 2-3 years off the market. In that case it would only make sense if they still have a really large user base, and AFAICS both your suggestions are in areas where either the user base regularly changes hardware (X121e) or is reluctant to touch something that's expected to run 24/7 (HP Micro N54L). > New ARM platforms is definitely an interesting topic. Although you have to > consider whether your platform of choice can work blob-free, and whether or > not there is already a uboot port for it. Especially in the ARM case it also depends on whether someone believes the student to realistically be able to bring up a platform without having the mentor figure out all the hard stuff. > Refactoring code seems to have been a popular GSoC theme since I've been doing > coreboot. Personally, and I will not be part of the decision making, I think > this is of limited value when that source code works. You see, coreboot is > nowadays being bombarded from all directions with binary-only components. You will face resistance from two camps: First camp doesn't see a benefit in the nth refactoring, second camp believes most refactoring will make merging vendor code harder. IMO a refactoring is OK if it only impacts binary-only vendor code, but others will disagree with me. > I think that you can do a great deal more good by working on eliminating some of > these blobs. Though tread carefully if you choose this path... reverse > engineering is not a valid project for GSoC, so RE should not be part of your > proposal or project. IMO RE and reimplementation could be done in one proposal, but please note that it all depends on your local legal landscape whether you want to go all the way to a Chinese Wall type of reverse engineering or not. That said, I believe that reverse engineering is one of the most valuable activities in a time where binary blobs crop up everywhere. > And this point is where you've really gotten my attention. It's gold. Pure > gold. Having a free software implementation of H8 firmware is a worthy goal in > itself. Although there's the argument to be made that there already is such a > thing in ChromeEC, your should stress the counterpoint that the EC is not > something that can just be replaced, and the mere popularity of the H8 makes > it a great platform to target. Doesn't Google have some open source code for H8-based ECs as well, not just their own ChromeEC? > Another amazing subject that I would suggest you consider is creating a free > replacement for the SMU firmware in AMD chipsets. Talk to ruik about it. He > may be able to tell you more. Regarding AMD chips up to fam16 at least, this > is the final frontier. AFAIK the SMU firmware is not enforcing any restrictions on coreboot or the platform, and thus I'd consider this a fun project, but without real benefits for coreboot. Regards, Carl-Daniel From mr.nuke.me at gmail.com Sat Feb 14 21:22:19 2015 From: mr.nuke.me at gmail.com (Alexandru Gagniuc) Date: Sat, 14 Feb 2015 14:22:19 -0600 Subject: [coreboot] On the subject of collaboration In-Reply-To: <20150214133711.9517.qmail@stuge.se> References: <54DF0AF0.1050301@gmx.net> <20150214133711.9517.qmail@stuge.se> Message-ID: <1499140.nTHTTMM0mR@nukelap.gtech> On Saturday, February 14, 2015 02:37:11 PM Peter Stuge wrote: > Carl-Daniel Hailfinger wrote: > > >>>> fork? > > > > > > a fork would be a good thing > > > > Hey look, I can quote without context, too! > > I hope this explains why quoting without context should not be done. > > Did you just hijack (or fork, as Alex likes to call it) the thread? > I don't understand why whenever there's a sarcastic comment we call that hijacking. I call that healthy. Sarcasm is healthy. Alex From mr.nuke.me at gmail.com Sat Feb 14 22:00:24 2015 From: mr.nuke.me at gmail.com (Alex G.) Date: Sat, 14 Feb 2015 15:00:24 -0600 Subject: [coreboot] [RFH] ACPI testers needed! -- free food* In-Reply-To: <54DB9464.50508@raptorengineeringinc.com> References: <54DB9464.50508@raptorengineeringinc.com> Message-ID: <54DFB768.3050805@gmail.com> On 02/11/2015 11:41 AM, Timothy Pearson wrote: > All, > > I have recently updated the coreboot ACPI autogeneration code to > generate valid processor _PSS objects when more than 10 cores are > installed in one system. > > Unfortunately this required a rather large update to multiple boards in > order to change the _PSS object name from CPUn to CPnn. We would like > some feedback to make sure this update didn't break anything before > committing. > > The patch is available at: http://review.coreboot.org/8422 > We're planning to merge that patch, but I'd like to give people a little more time to make sure there aren't any outstanding or obvious issues. Of course, the idea of free food usually gets people interested. Alex (*) free food for thought From c-d.hailfinger.devel.2006 at gmx.net Sun Feb 15 16:05:37 2015 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sun, 15 Feb 2015 16:05:37 +0100 Subject: [coreboot] On the subject of collaboration In-Reply-To: <20150214133711.9517.qmail@stuge.se> References: <4150716.nvA6L3ET4p@nukelap.gtech> <5037198.UkVmxV0nFL@nukelap.gtech> <20150214015409.10626.qmail@stuge.se> <20150214020851.GA9995@dinah> <20150214022743.13145.qmail@stuge.se> <54DF0AF0.1050301@gmx.net> <20150214133711.9517.qmail@stuge.se> Message-ID: <54E0B5C1.9070101@gmx.net> On 14.02.2015 14:37, Peter Stuge wrote: > Carl-Daniel Hailfinger wrote: >>>>>> fork? >>> a fork would be a good thing >> Hey look, I can quote without context, too! >> I hope this explains why quoting without context should not be done. > Did you just hijack (or fork, as Alex likes to call it) the thread? No, I was just replying to you, and by selectively quoting you I even kept the topic you were talking about. Regards, Carl-Daniel From peter at stuge.se Sun Feb 15 17:31:29 2015 From: peter at stuge.se (Peter Stuge) Date: Sun, 15 Feb 2015 17:31:29 +0100 Subject: [coreboot] On the subject of collaboration In-Reply-To: <54E0B5C1.9070101@gmx.net> References: <4150716.nvA6L3ET4p@nukelap.gtech> <5037198.UkVmxV0nFL@nukelap.gtech> <20150214015409.10626.qmail@stuge.se> <20150214020851.GA9995@dinah> <20150214022743.13145.qmail@stuge.se> <54DF0AF0.1050301@gmx.net> <20150214133711.9517.qmail@stuge.se> <54E0B5C1.9070101@gmx.net> Message-ID: <20150215163129.6584.qmail@stuge.se> Carl-Daniel Hailfinger wrote: > >>>>>> fork? .. > >> I hope this explains why quoting without context should not be done. > > > Did you just hijack (or fork, as Alex likes to call it) the thread? > > No, I was just replying to you, and by selectively quoting you I even > kept the topic you were talking about. To me it looks like you changed the topic of the thread to quoting. But never mind. Too much noise already. Everyone have a nice Sunday! //Peter From zoran.stojsavljevic at intel.com Tue Feb 17 17:07:37 2015 From: zoran.stojsavljevic at intel.com (Stojsavljevic, Zoran) Date: Tue, 17 Feb 2015 16:07:37 +0000 Subject: [coreboot] Bay trail and SATA legacy IDE mode In-Reply-To: <2989106.GcMannOiWK@nukelap.gtech> References: <677ED26A-3682-4DF4-9990-CB9A6E326E07@winzenttech.com> <67BFA875989E5748A862DFF55409F2A22EE04FBC@IRSMSX104.ger.corp.intel.com> <2989106.GcMannOiWK@nukelap.gtech> Message-ID: <67BFA875989E5748A862DFF55409F2A22EE23BEC@IRSMSX104.ger.corp.intel.com> Hello Alex, I would like to thank you for the help. We were able to track down the problem with the native and legacy SATA IDE mode. Coreboot code helped in the process. Stay in touch. :-) Best Regards, Zoran -----Original Message----- From: Alexandru Gagniuc [mailto:mr.nuke.me at gmail.com] Sent: Monday, February 09, 2015 8:37 AM To: coreboot at coreboot.org Cc: Stojsavljevic, Zoran; Patrick Georgi; Marc Jones; 'Berth-Olof Bergman' Subject: Re: [coreboot] Bay trail and SATA legacy IDE mode On Monday, February 09, 2015 07:05:04 AM Stojsavljevic, Zoran wrote: > But still... I have some limited knowledge of Coreboot from 15 months > ago, and I am trying to understand if Coreboot x86 code has some > influence on the SATA IDE mode. From what I am reading... There is a possibility! Check src/soc/intel/baytrail/sata.c on how the registers are configured based on devicetree.cb if (!config->sata_ahci) { /* Set legacy or native decoding mode */ if (config->ide_legacy_combined) { > The silicon is BYT SoC, ATOM. The boot time to OS bootloader is around 300 > ms. > My best understanding how this enumeration works for SATA is that all SATA > are put in default AHCI mode. But some people (As Berth) must have SATA > interfaces in IDE mode. register "sata_ahci" = "0" register "ide_legacy_combined" = "1" Alex Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 From scan-admin at coverity.com Tue Feb 17 21:26:23 2015 From: scan-admin at coverity.com (scan-admin at coverity.com) Date: Tue, 17 Feb 2015 12:26:23 -0800 Subject: [coreboot] New Defects reported by Coverity Scan for coreboot Message-ID: <54e3a3ef5709d_70fd423330313a0@scan.coverity.com.mail> Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 8 new defect(s) introduced to coreboot found with Coverity Scan. 521 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 8 of 8 defect(s) ** CID 1270744: Control flow issues (NO_EFFECT) /src/drivers/pc80/mc146818rtc.c: 270 in set_cmos_value() ________________________________________________________________________________________________________ *** CID 1270744: Control flow issues (NO_EFFECT) /src/drivers/pc80/mc146818rtc.c: 270 in set_cmos_value() 264 } else { /* more that one byte so transfer the whole bytes */ 265 if (byte_bit || length % 8) 266 return CB_ERR_ARG; 267 268 for (i = 0; length; i++, length -= 8, byte++) 269 cmos_write(ret[i], byte); >>> CID 1270744: Control flow issues (NO_EFFECT) >>> This greater-than-or-equal-to-zero comparison of an unsigned value is always true. "byte >= 0UL". 270 if (byte >= LB_CKS_RANGE_START && 271 byte <= LB_CKS_RANGE_END) 272 chksum_update_needed = 1; 273 } 274 275 if (chksum_update_needed) { ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://scan.coverity.com/projects/1016?tab=overview To manage Coverity Scan email notifications for "coreboot at coreboot.org", click https://scan.coverity.com/subscriptions/edit?email=coreboot%40coreboot.org&token=8ddd1fe26945626880b796e94d465567 . From jwerner at chromium.org Wed Feb 18 00:12:35 2015 From: jwerner at chromium.org (Julius Werner) Date: Tue, 17 Feb 2015 15:12:35 -0800 Subject: [coreboot] Unifying IO accessor macros Message-ID: I'd like to propose an API change/cleanup for a long-standing problem with architecture-independent code that people have hit and privately discussed/cursed multiple times already, but no one really had time to make the big change/fix yet. (Some earlier discussion among Chromium people about this is available at http://crbug.com/451388 ) For doing MMIO accesses to registers, x86 code has traditionally used a function with a signature like this: void write32(unsigned long addr, u32 value); // equivalents for read32(), write8(), etc. While ARM (and based on that, ARM64) has been brought up with both of these: void write32(u32 value, void *addr); void writel(u32 value, void *addr); There's two problems with this: first, the order of arguments (value and address) is switched around between the two architectures, meaning it is currently impossible to write any architecture-independent MMIO code (which blocks important features like generalizing src/lib/uart8250mem.c). Second, the x86 version is not type safe (it takes addresses as integers instead of pointers), making it extremely easy to accidentally swap address and value (especially due to all this architecture confusion about which order is correct). Changing the addresses to a pointer type will generate obvious compiler errors for most of those screw-ups, which I think is a good thing that x86 could benefit from as well. I want to unify all architectures under a single, type safe version of these macros that will remove the confusion and allow writing architecture-independent MMIO code in the future. For this, I plan to: 1. Switch all existing uses of write32() (and friends) in ARM(64) code to writel(). 2. Remove write32() from all architectures but x86. 3. Add writel(u32 value, void *addr) which is compatible with other architectures to x86. 4. Pronounce write32(unsigned long addr, u32 value) deprecated for x86 and slowly phase it out over time (at least from common/recent code). After this we'll be converged on writel(u32 value, void *addr) as the one and only way to do it across all architectures going forward. I know that there are probably people who prefer the name write32() aesthetically, or who have a strong preference for the first-address-then-value parameter order. I personally don't really like the way writel() looks myself, but at the end of the day it doesn't make a huge difference. I think this is the best solution because it has strong practical advantages and will allow us to solve the issue with the least amount of changes: most ARM(64) code already uses writel(), libpayload uses writel() across all architectures, and it's the standard for U-Boot and a majority of the Linux kernel which are popular import sources. Also, the amount of existing x86 code is probably too large to ever change (and appropriately test) it all... so it's useful to pick a solution that can leave the old untyped write32() in place on x86 as a deprecated fallback. Since the changes required for this would mostly affect ARM(64) SoCs and boards, which are currently much more developed (and in flux) in the Chromium tree, I'm planning to only change this there for now and wait until it gets merged into coreboot mainline in the right order as part of the current upstreaming process. I still wanted to float the idea here first to give everyone a chance to chime in before it's all said and done. From mr.nuke.me at gmail.com Wed Feb 18 00:34:32 2015 From: mr.nuke.me at gmail.com (Alexandru Gagniuc) Date: Tue, 17 Feb 2015 17:34:32 -0600 Subject: [coreboot] Unifying IO accessor macros In-Reply-To: References: Message-ID: <3392575.qzWs7OMOgZ@nukelap.gtech> On Tuesday, February 17, 2015 03:12:35 PM Julius Werner wrote: > I'd like to propose an API change/cleanup for a long-standing problem > with architecture-independent code that people have hit and privately > discussed/cursed multiple times already, but no one really had time to > make the big change/fix yet. (Some earlier discussion among Chromium > people about this is available at http://crbug.com/451388 ) > > For doing MMIO accesses to registers, x86 code has traditionally used > a function with a signature like this: > > void write32(unsigned long addr, u32 value); // equivalents for > read32(), write8(), etc. > > While ARM (and based on that, ARM64) has been brought up with both of these: > > void write32(u32 value, void *addr); > void writel(u32 value, void *addr); > > There's two problems with this: first, the order of arguments (value > and address) is switched around between the two architectures, meaning > it is currently impossible to write any architecture-independent MMIO > code (which blocks important features like generalizing > src/lib/uart8250mem.c). Second, the x86 version is not type safe (it > takes addresses as integers instead of pointers), making it extremely > easy to accidentally swap address and value (especially due to all > this architecture confusion about which order is correct). Changing > the addresses to a pointer type will generate obvious compiler errors > for most of those screw-ups, which I think is a good thing that x86 > could benefit from as well. The x86 was recently fixed to take in void *. The order of arguments was discussed before, and the agreement is to use write*(addr, val); This has the advantage of being consistent with other accessor functions, such as PCI, and follows the logical C ordering of the assignment operator. destination = value; > > I want to unify all architectures under a single, type safe version of > these macros that will remove the confusion and allow writing > architecture-independent MMIO code in the future. For this, I plan to: > > 1. Switch all existing uses of write32() (and friends) in ARM(64) code > to writel(). Please don't. Always use functions that indicate bitness. > 2. Remove write32() from all architectures but x86. See above point. > 3. Add writel(u32 value, void *addr) which is compatible with other > architectures to x86. What is writel? Is it 32 bits? 64 bits? This C70's mentality has to go away. We've worked pretty hard to go into the 21st century, with stdint types, and other "duh! This just makes sense" changes. > 4. Pronounce write32(unsigned long addr, u32 value) deprecated for x86 > and slowly phase it out over time (at least from common/recent code). > Already done. It's void * for the addr arg... just where we want it. And it indicates bitness, just like we want it. > After this we'll be converged on writel(u32 value, void *addr) as the Please don't use AT&T-centric syntax. It's inconsistent with every other accessor in coreboot. > one and only way to do it across all architectures going forward. I > know that there are probably people who prefer the name write32() > aesthetically, or who have a strong preference for the It's part of the critical system guidelines to use types that indicate bitness. > first-address-then-value parameter order. I personally don't really Again, this matches the logical order of the C programming language. Maybe we want to switch coreboot to assembly? JK, JK. > like the way writel() looks myself, but at the end of the day it > doesn't make a huge difference. I think this is the best solution But it does. You see, bitness is not obviuous from the likes of long, long long, int short, word, dword, etc. It's also compiler dependent, just adding to the overall confusion. Then what do you do for write64()... writell()? That's easily mistakeable for writel(). > because it has strong practical advantages and will allow us to solve > the issue with the least amount of changes: most ARM(64) code already > uses writel(), libpayload uses writel() across all architectures, and All it takes is a trivial semantic patch or short sed line to switch this. This is hardly any effort at all when compared to the efforts of integrating code from other codebases. > it's the standard for U-Boot and a majority of the Linux kernel which We got it right. And consistent. Using codebases that are either as old as linux, or got it wrong, like uboot, is really not a fair comparison. > are popular import sources. Also, the amount of existing x86 code is > probably too large to ever change (and appropriately test) it all... > so it's useful to pick a solution that can leave the old untyped > write32() in place on x86 as a deprecated fallback. Huh? It's almost trivial to do with a semantic patch. > > Since the changes required for this would mostly affect ARM(64) SoCs > and boards, which are currently much more developed (and in flux) in > the Chromium tree, I'm planning to only change this there for now and > wait until it gets merged into coreboot mainline in the right order as > part of the current upstreaming process. I still wanted to float the > idea here first to give everyone a chance to chime in before it's all > said and done. You're free to continue to provide writel() and friends as a fallback for ARM code picked from other codebases, but please consider that it's wrong. Alex From jwerner at chromium.org Wed Feb 18 01:32:18 2015 From: jwerner at chromium.org (Julius Werner) Date: Tue, 17 Feb 2015 16:32:18 -0800 Subject: [coreboot] Unifying IO accessor macros In-Reply-To: <3392575.qzWs7OMOgZ@nukelap.gtech> References: <3392575.qzWs7OMOgZ@nukelap.gtech> Message-ID: > The x86 was recently fixed to take in void *. The order of arguments was > discussed before, and the agreement is to use write*(addr, val); > This has the advantage of being consistent with other accessor functions, such > as PCI, and follows the logical C ordering of the assignment operator. > destination = value; Oh, wow... that merged literally just this weekend. Talk about bad timing. I wasn't aware this was going on (and none of the reviewers bothered to tell me -.- ). Guess that brings me back to the drawing board. I don't generally disagree with your reasonings about why you consider certain patterns better than others... at most I'd say that I don't think it's all that important at the end of the day (writel() has always referred to 32 bits wherever I've seen it yet, and 64 could easily be writeq() if we ever need it), and that doing things the way people are used to from other/bigger projects (like Linux) might ultimately be more useful to us than doing what we consider "the right way". But I really don't have a strong opinion in either direction, I just care about unifying this and making sure there is a single, consistent pattern everywhere. If most people here think write32(void *addr, u32 value) is the right way to go, I can instead switch ARM(64) over to that. It would be a pretty massive change, but since all those boards are Chromebooks for now I'm in a reasonably good position to ensure everything stays working. One issue we're left with is libpayload, which I think should definitely use the same pattern as coreboot. Right now it uses writel(v,a) on all architectures (typed on ARM and untyped on x86). I can change the library, but all external payloads will need to change their call sites themselves. Are we okay with that? From mr.nuke.me at gmail.com Wed Feb 18 05:44:47 2015 From: mr.nuke.me at gmail.com (Alexandru Gagniuc) Date: Tue, 17 Feb 2015 22:44:47 -0600 Subject: [coreboot] Unifying IO accessor macros In-Reply-To: References: <3392575.qzWs7OMOgZ@nukelap.gtech> Message-ID: <3180601.Vry57uOoJv@nukelap.gtech> On Tuesday, February 17, 2015 04:32:18 PM Julius Werner wrote: > > The x86 was recently fixed to take in void *. The order of arguments was > > discussed before, and the agreement is to use write*(addr, val); > > This has the advantage of being consistent with other accessor functions, > > such as PCI, and follows the logical C ordering of the assignment > > operator. destination = value; > > Oh, wow... that merged literally just this weekend. Talk about bad > timing. I wasn't aware this was going on (and none of the reviewers > bothered to tell me -.- ). > Well, I tried pinging you on IRC a few times, but I didn't realize you prefer ML over IRC. Sorry about that. To be fair, Ron did warn me about you being on the same tracks. > Guess that brings me back to the drawing board. I don't generally > disagree with your reasonings about why you consider certain patterns > better than others... at most I'd say that I don't think it's all that > important at the end of the day (writel() has always referred to 32 > bits wherever I've seen it yet, and 64 could easily be writeq() if we > ever need it), and that doing things the way people are used to from > other/bigger projects (like Linux) might ultimately be more useful to > us than doing what we consider "the right way". > Well, we're firmware. We're special. We used to do hardware. Now we mostly deal with hardhardhardhardhardhardware. Every little imperfection propagates faster than light and multiplies exponentially. Linux doesn't deal with that. U-boot doesn't deal with that. Not quite a fair comparison. > But I really don't have a strong opinion in either direction, I just > care about unifying this and making sure there is a single, consistent > pattern everywhere. If most people here think write32(void *addr, u32 > value) is the right way to go, I can instead switch ARM(64) over to > that. It would be a pretty massive change, but since all those boards > are Chromebooks for now I'm in a reasonably good position to ensure > everything stays working. > This reverse order hit me like a brick wall when I first started doing ARM on coreboot. But I was angry at ARM code for having gotten it wrong. I also hated uboot's setbits_le32(), but hey, at least it indicates bitness -- compare to setbits_lel(). > One issue we're left with is libpayload, which I think should > definitely use the same pattern as coreboot. Right now it uses > writel(v,a) on all architectures (typed on ARM and untyped on x86). I > can change the library, but all external payloads will need to change > their call sites themselves. Are we okay with that? Personally, I'm okay with unifying the order/type of arguments. As long as the the payloads that we have in-tree are updated, the external ones shouldn't be that hard to do at a later time. Alex From adurbin at google.com Wed Feb 18 16:16:07 2015 From: adurbin at google.com (Aaron Durbin) Date: Wed, 18 Feb 2015 09:16:07 -0600 Subject: [coreboot] Unifying IO accessor macros In-Reply-To: <3180601.Vry57uOoJv@nukelap.gtech> References: <3392575.qzWs7OMOgZ@nukelap.gtech> <3180601.Vry57uOoJv@nukelap.gtech> Message-ID: On Tue, Feb 17, 2015 at 10:44 PM, Alexandru Gagniuc wrote: > On Tuesday, February 17, 2015 04:32:18 PM Julius Werner wrote: >> > The x86 was recently fixed to take in void *. The order of arguments was >> > discussed before, and the agreement is to use write*(addr, val); >> > This has the advantage of being consistent with other accessor functions, >> > such as PCI, and follows the logical C ordering of the assignment >> > operator. destination = value; >> >> Oh, wow... that merged literally just this weekend. Talk about bad >> timing. I wasn't aware this was going on (and none of the reviewers >> bothered to tell me -.- ). >> > Well, I tried pinging you on IRC a few times, but I didn't realize you prefer > ML over IRC. Sorry about that. To be fair, Ron did warn me about you being on > the same tracks. > >> Guess that brings me back to the drawing board. I don't generally >> disagree with your reasonings about why you consider certain patterns >> better than others... at most I'd say that I don't think it's all that >> important at the end of the day (writel() has always referred to 32 >> bits wherever I've seen it yet, and 64 could easily be writeq() if we >> ever need it), and that doing things the way people are used to from >> other/bigger projects (like Linux) might ultimately be more useful to >> us than doing what we consider "the right way". >> > Well, we're firmware. We're special. We used to do hardware. Now we mostly > deal with hardhardhardhardhardhardware. Every little imperfection propagates > faster than light and multiplies exponentially. Linux doesn't deal with that. > U-boot doesn't deal with that. Not quite a fair comparison. > >> But I really don't have a strong opinion in either direction, I just >> care about unifying this and making sure there is a single, consistent >> pattern everywhere. If most people here think write32(void *addr, u32 >> value) is the right way to go, I can instead switch ARM(64) over to >> that. It would be a pretty massive change, but since all those boards >> are Chromebooks for now I'm in a reasonably good position to ensure >> everything stays working. >> > This reverse order hit me like a brick wall when I first started doing ARM on > coreboot. But I was angry at ARM code for having gotten it wrong. I also hated > uboot's setbits_le32(), but hey, at least it indicates bitness -- compare to > setbits_lel(). > >> One issue we're left with is libpayload, which I think should >> definitely use the same pattern as coreboot. Right now it uses >> writel(v,a) on all architectures (typed on ARM and untyped on x86). I >> can change the library, but all external payloads will need to change >> their call sites themselves. Are we okay with that? > > Personally, I'm okay with unifying the order/type of arguments. As long as the > the payloads that we have in-tree are updated, the external ones shouldn't be > that hard to do at a later time. > As I have noted on http://review.coreboot.org/#/c/7924/ it's very short sighted to go this route. In assembling a coreboot stack (which includes libpayload and the payload itself) the code usually comes from different software systems. Those include libpayload, linux kernel, u-boot, etc. They all have the write(val, addr) semantics. I see no good reason to artificially erect an ever present barrier for integrating code into a coreboot system. Alex, you've clearly stated your opinion you've not justified a reason for keeping the barrier. From adurbin at google.com Wed Feb 18 16:17:39 2015 From: adurbin at google.com (Aaron Durbin) Date: Wed, 18 Feb 2015 09:17:39 -0600 Subject: [coreboot] Unifying IO accessor macros In-Reply-To: References: <3392575.qzWs7OMOgZ@nukelap.gtech> <3180601.Vry57uOoJv@nukelap.gtech> Message-ID: On Wed, Feb 18, 2015 at 9:16 AM, Aaron Durbin wrote: > On Tue, Feb 17, 2015 at 10:44 PM, Alexandru Gagniuc > wrote: >> On Tuesday, February 17, 2015 04:32:18 PM Julius Werner wrote: >>> > The x86 was recently fixed to take in void *. The order of arguments was >>> > discussed before, and the agreement is to use write*(addr, val); >>> > This has the advantage of being consistent with other accessor functions, >>> > such as PCI, and follows the logical C ordering of the assignment >>> > operator. destination = value; >>> >>> Oh, wow... that merged literally just this weekend. Talk about bad >>> timing. I wasn't aware this was going on (and none of the reviewers >>> bothered to tell me -.- ). >>> >> Well, I tried pinging you on IRC a few times, but I didn't realize you prefer >> ML over IRC. Sorry about that. To be fair, Ron did warn me about you being on >> the same tracks. >> >>> Guess that brings me back to the drawing board. I don't generally >>> disagree with your reasonings about why you consider certain patterns >>> better than others... at most I'd say that I don't think it's all that >>> important at the end of the day (writel() has always referred to 32 >>> bits wherever I've seen it yet, and 64 could easily be writeq() if we >>> ever need it), and that doing things the way people are used to from >>> other/bigger projects (like Linux) might ultimately be more useful to >>> us than doing what we consider "the right way". >>> >> Well, we're firmware. We're special. We used to do hardware. Now we mostly >> deal with hardhardhardhardhardhardware. Every little imperfection propagates >> faster than light and multiplies exponentially. Linux doesn't deal with that. >> U-boot doesn't deal with that. Not quite a fair comparison. >> >>> But I really don't have a strong opinion in either direction, I just >>> care about unifying this and making sure there is a single, consistent >>> pattern everywhere. If most people here think write32(void *addr, u32 >>> value) is the right way to go, I can instead switch ARM(64) over to >>> that. It would be a pretty massive change, but since all those boards >>> are Chromebooks for now I'm in a reasonably good position to ensure >>> everything stays working. >>> >> This reverse order hit me like a brick wall when I first started doing ARM on >> coreboot. But I was angry at ARM code for having gotten it wrong. I also hated >> uboot's setbits_le32(), but hey, at least it indicates bitness -- compare to >> setbits_lel(). >> >>> One issue we're left with is libpayload, which I think should >>> definitely use the same pattern as coreboot. Right now it uses >>> writel(v,a) on all architectures (typed on ARM and untyped on x86). I >>> can change the library, but all external payloads will need to change >>> their call sites themselves. Are we okay with that? >> >> Personally, I'm okay with unifying the order/type of arguments. As long as the >> the payloads that we have in-tree are updated, the external ones shouldn't be >> that hard to do at a later time. >> > > > As I have noted on http://review.coreboot.org/#/c/7924/ it's very > short sighted to go this route. In assembling a coreboot stack (which > includes libpayload and the payload itself) the code usually comes > from different software systems. Those include libpayload, linux > kernel, u-boot, etc. They all have the write(val, addr) semantics. I > see no good reason to artificially erect an ever present barrier for > integrating code into a coreboot system. > > Alex, you've clearly stated your opinion you've not justified a reason > for keeping the barrier. Hit "send" accidentally. Anyway, I'd like to hear why it's OK to purposefully keep this barrier in place. Thanks. -Aaron From vbendeb at chromium.org Wed Feb 18 17:23:08 2015 From: vbendeb at chromium.org (Vadim Bendebury) Date: Wed, 18 Feb 2015 08:23:08 -0800 Subject: [coreboot] Unifying IO accessor macros In-Reply-To: References: <3392575.qzWs7OMOgZ@nukelap.gtech> <3180601.Vry57uOoJv@nukelap.gtech> Message-ID: On Wed, Feb 18, 2015 at 7:16 AM, Aaron Durbin via coreboot wrote: > On Tue, Feb 17, 2015 at 10:44 PM, Alexandru Gagniuc > > As I have noted on http://review.coreboot.org/#/c/7924/ it's very > short sighted to go this route. In assembling a coreboot stack (which > includes libpayload and the payload itself) the code usually comes > from different software systems. Those include libpayload, linux > kernel, u-boot, etc. They all have the write(val, addr) semantics. I > see no good reason to artificially erect an ever present barrier for > integrating code into a coreboot system. > This is a great reason to keep those accessors, IMO it tramps other considerations voiced on this thread. Let's be consistent with other software systems. --vb > Alex, you've clearly stated your opinion you've not justified a reason > for keeping the barrier. > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot From pgeorgi at google.com Wed Feb 18 17:35:30 2015 From: pgeorgi at google.com (Patrick Georgi) Date: Wed, 18 Feb 2015 17:35:30 +0100 Subject: [coreboot] Unifying IO accessor macros In-Reply-To: References: <3392575.qzWs7OMOgZ@nukelap.gtech> <3180601.Vry57uOoJv@nukelap.gtech> Message-ID: 2015-02-18 17:23 GMT+01:00 Vadim Bendebury : >> kernel, u-boot, etc. They all have the write(val, addr) semantics. I >> see no good reason to artificially erect an ever present barrier for >> integrating code into a coreboot system. >> Since all imported code requires some rework before it works for us, and redoing that particular issue is a matter of a simple spatch (http://coccinelle.lip6.fr/), I'm not sure that's actually that big a concern. @@ expression a,v; @@ -writel(v,a) +write32(a, v) Patrick -- Google Germany GmbH ABC-Str. 19 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Gesch?ftsf?hrer: Graham Law, Christine Elizabeth Flores From adurbin at google.com Wed Feb 18 17:40:27 2015 From: adurbin at google.com (Aaron Durbin) Date: Wed, 18 Feb 2015 10:40:27 -0600 Subject: [coreboot] Unifying IO accessor macros In-Reply-To: References: <3392575.qzWs7OMOgZ@nukelap.gtech> <3180601.Vry57uOoJv@nukelap.gtech> Message-ID: On Wed, Feb 18, 2015 at 10:35 AM, Patrick Georgi wrote: > 2015-02-18 17:23 GMT+01:00 Vadim Bendebury : >>> kernel, u-boot, etc. They all have the write(val, addr) semantics. I >>> see no good reason to artificially erect an ever present barrier for >>> integrating code into a coreboot system. >>> > Since all imported code requires some rework before it works for us, > and redoing that particular issue is a matter of a simple spatch > (http://coccinelle.lip6.fr/), I'm not sure that's actually that big a > concern. > > @@ > expression a,v; > @@ > -writel(v,a) > +write32(a, v) Can you provide the spatch utility and script as well as the documentation so that every potential contributor can perform the necessary steps? Or we could be done w/ it once and for all and fix the existing coreboot semantics. Then there's not another step for anyone in perpetuity. Also keep in mind it's not just software going into coreboot but reusing software within coreboot as well. It's a 2 way street. I did volunteer to do the big change, and if people want I will. Let me know. -Aaron From rminnich at gmail.com Wed Feb 18 17:41:13 2015 From: rminnich at gmail.com (ron minnich) Date: Wed, 18 Feb 2015 16:41:13 +0000 Subject: [coreboot] Unifying IO accessor macros References: <3392575.qzWs7OMOgZ@nukelap.gtech> <3180601.Vry57uOoJv@nukelap.gtech> Message-ID: Having spent 15 or so years on Plan 9 and Linux, the only conclusion I can make is that nothing is universal. Plan 9 is this: outl(int port, ulong value) And I used software that came long before Linux (back in the 70s, if you want to know) that followed that form too. I think Linux got it backwards, but it's the standard, so I guess that's what people want. I don't really care at this point, as long as whatever we use is defined with a correct prototype, so we don't get errors when people from other projects also get it "backwards", like me. It's just not that big a deal. Let's stop fussing about it. ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From mr.nuke.me at gmail.com Wed Feb 18 17:49:25 2015 From: mr.nuke.me at gmail.com (Alexandru Gagniuc) Date: Wed, 18 Feb 2015 10:49:25 -0600 Subject: [coreboot] Unifying IO accessor macros In-Reply-To: References: <3180601.Vry57uOoJv@nukelap.gtech> Message-ID: <8710381.Gsar9oJxnB@nukelap.gtech> On Wednesday, February 18, 2015 09:16:07 AM Aaron Durbin wrote: > As I have noted on http://review.coreboot.org/#/c/7924/ it's very > short sighted to go this route. In assembling a coreboot stack (which > includes libpayload and the payload itself) the code usually comes > from different software systems. Those include libpayload, linux > kernel, u-boot, etc. They all have the write(val, addr) semantics. I > see no good reason to artificially erect an ever present barrier for > integrating code into a coreboot system. > As Patrick already said, compared to the total effort to integrate external sources, the issue of argument order is insignificant. In the time you spent writing this email, you could have found out how to do it with coccinelle, and could have applied it to any number of sources. > Alex, you've clearly stated your opinion you've not justified a reason > for keeping the barrier. If you think that something as simple as this is a barrier, then you're likely just copypasting code. In that case, I do want a barrier to protect you from yourself, and from putting up code that was no reviewed in its entirety. Really, it's not a barrier. Alex From mr.nuke.me at gmail.com Wed Feb 18 17:51:20 2015 From: mr.nuke.me at gmail.com (Alexandru Gagniuc) Date: Wed, 18 Feb 2015 10:51:20 -0600 Subject: [coreboot] Unifying IO accessor macros In-Reply-To: References: Message-ID: <2247721.9JNzsjW3L8@nukelap.gtech> On Wednesday, February 18, 2015 04:41:13 PM ron minnich wrote: > Having spent 15 or so years on Plan 9 and Linux, the only conclusion I can > make is that nothing is universal. > > Plan 9 is this: > outl(int port, ulong value) > Finally an implementation that makes sense. Those out[lbw]() accessors always get me. > Linux got it backwards, > Thank you! Alex From mr.nuke.me at gmail.com Wed Feb 18 17:57:28 2015 From: mr.nuke.me at gmail.com (Alexandru Gagniuc) Date: Wed, 18 Feb 2015 10:57:28 -0600 Subject: [coreboot] Unifying IO accessor macros In-Reply-To: References: Message-ID: <10421953.7ZLyEGDsju@nukelap.gtech> On Wednesday, February 18, 2015 08:23:08 AM Vadim Bendebury wrote: > On Wed, Feb 18, 2015 at 7:16 AM, Aaron Durbin via coreboot > > > As I have noted on http://review.coreboot.org/#/c/7924/ it's very > > short sighted to go this route. In assembling a coreboot stack (which > > includes libpayload and the payload itself) the code usually comes > > from different software systems. Those include libpayload, linux > > kernel, u-boot, etc. They all have the write(val, addr) semantics. I > > see no good reason to artificially erect an ever present barrier for > > integrating code into a coreboot system. > > This is a great reason to keep those accessors, IMO it tramps other > considerations voiced on this thread. Let's be consistent with other > software systems. > Following that reasoning, we should switch to EFI style so we can better integrate vendorcode: read32 -> LibVendorMemRead(..., AccessWidth32, ...) Doing what other software stacks do without a real reason, and just because it's trendy... Alex From rminnich at gmail.com Wed Feb 18 18:14:15 2015 From: rminnich at gmail.com (ron minnich) Date: Wed, 18 Feb 2015 17:14:15 +0000 Subject: [coreboot] Unifying IO accessor macros References: <10421953.7ZLyEGDsju@nukelap.gtech> Message-ID: Well, I say it again: it matters not. I don't care how we do it, some ox is going to get gored. The order is much less important than consistency. And ox are tasty. So let's gore one. The problem for me is not that I have an opinion, but that people I respect so highly have different opinions. How can very smart people have different opinions? This can't be :-) Somebody make a decision and go for it. Just make sure it's type safe so we can catch it when I get it backwards. Sorry I have been absent, somehow I got unsubscribed and did not notice for a while ... I think it's probably more important to get sparse working for coreboot than this order of arguments thing anyway ... ron On Wed Feb 18 2015 at 8:58:23 AM Alexandru Gagniuc wrote: > On Wednesday, February 18, 2015 08:23:08 AM Vadim Bendebury wrote: > > On Wed, Feb 18, 2015 at 7:16 AM, Aaron Durbin via coreboot > > > > > As I have noted on http://review.coreboot.org/#/c/7924/ it's very > > > short sighted to go this route. In assembling a coreboot stack (which > > > includes libpayload and the payload itself) the code usually comes > > > from different software systems. Those include libpayload, linux > > > kernel, u-boot, etc. They all have the write(val, addr) semantics. I > > > see no good reason to artificially erect an ever present barrier for > > > integrating code into a coreboot system. > > > > This is a great reason to keep those accessors, IMO it tramps other > > considerations voiced on this thread. Let's be consistent with other > > software systems. > > > Following that reasoning, we should switch to EFI style so we can better > integrate vendorcode: > > read32 -> LibVendorMemRead(..., AccessWidth32, ...) > > Doing what other software stacks do without a real reason, and just because > it's trendy... > > Alex > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adurbin at google.com Wed Feb 18 18:35:13 2015 From: adurbin at google.com (Aaron Durbin) Date: Wed, 18 Feb 2015 11:35:13 -0600 Subject: [coreboot] Unifying IO accessor macros In-Reply-To: <8710381.Gsar9oJxnB@nukelap.gtech> References: <3180601.Vry57uOoJv@nukelap.gtech> <8710381.Gsar9oJxnB@nukelap.gtech> Message-ID: On Wed, Feb 18, 2015 at 10:49 AM, Alexandru Gagniuc wrote: > On Wednesday, February 18, 2015 09:16:07 AM Aaron Durbin wrote: >> As I have noted on http://review.coreboot.org/#/c/7924/ it's very >> short sighted to go this route. In assembling a coreboot stack (which >> includes libpayload and the payload itself) the code usually comes >> from different software systems. Those include libpayload, linux >> kernel, u-boot, etc. They all have the write(val, addr) semantics. I >> see no good reason to artificially erect an ever present barrier for >> integrating code into a coreboot system. >> > As Patrick already said, compared to the total effort to integrate external > sources, the issue of argument order is insignificant. In the time you spent > writing this email, you could have found out how to do it with coccinelle, and > could have applied it to any number of sources. http://review.coreboot.org/8483 > >> Alex, you've clearly stated your opinion you've not justified a reason >> for keeping the barrier. > > If you think that something as simple as this is a barrier, then you're likely > just copypasting code. In that case, I do want a barrier to protect you from > yourself, and from putting up code that was no reviewed in its entirety. > Really, it's not a barrier. Ok. A hurdle or a hoop. What's the point of adding more hoops? You still haven't made any counter-argument to the practicalness of being compatible with the software systems where coreboot gets contribution. You have an opinion, sure, but I haven't heard anything aside from "something is wrong". The current landscape is: coreboot is different than: 1. linux 2. uboot 3. libpayload 4. Anything using libpayload Being different is not necessarily better. coreboot's usage is tiny in comparison to the first 2 projects listed. -Aaron From mr.nuke.me at gmail.com Wed Feb 18 18:41:11 2015 From: mr.nuke.me at gmail.com (Alexandru Gagniuc) Date: Wed, 18 Feb 2015 11:41:11 -0600 Subject: [coreboot] Unifying IO accessor macros In-Reply-To: References: <8710381.Gsar9oJxnB@nukelap.gtech> Message-ID: <1727409.DxYcmTeq0u@nukelap.gtech> On Wednesday, February 18, 2015 11:35:13 AM Aaron Durbin wrote: > You still haven't made any counter-argument to the practicalness of being > compatible with the software systems where coreboot gets contribution. > And you still haven't responded to my proposal of using EFI style. Alex From mr.nuke.me at gmail.com Wed Feb 18 18:46:25 2015 From: mr.nuke.me at gmail.com (Alexandru Gagniuc) Date: Wed, 18 Feb 2015 11:46:25 -0600 Subject: [coreboot] Unifying IO accessor macros In-Reply-To: References: <10421953.7ZLyEGDsju@nukelap.gtech> Message-ID: <2092931.bn6aa0dv03@nukelap.gtech> On Wednesday, February 18, 2015 05:14:15 PM ron minnich wrote: > Somebody make a decision and go for it. Just make sure it's type safe so we > can catch it when I get it backwards. write[8|16|32|64](void *addr, uint[8|16|32|64]_t val); There. It's done :) > Sorry I have been absent, somehow I got unsubscribed and did not notice for > a while ... > Same thing happened to me. Alex From adurbin at google.com Wed Feb 18 18:50:04 2015 From: adurbin at google.com (Aaron Durbin) Date: Wed, 18 Feb 2015 11:50:04 -0600 Subject: [coreboot] Unifying IO accessor macros In-Reply-To: <1727409.DxYcmTeq0u@nukelap.gtech> References: <8710381.Gsar9oJxnB@nukelap.gtech> <1727409.DxYcmTeq0u@nukelap.gtech> Message-ID: On Wed, Feb 18, 2015 at 11:41 AM, Alexandru Gagniuc wrote: > On Wednesday, February 18, 2015 11:35:13 AM Aaron Durbin wrote: >> You still haven't made any counter-argument to the practicalness of being >> compatible with the software systems where coreboot gets contribution. >> > And you still haven't responded to my proposal of using EFI style. I thought that was a non-sensical proposal. I didn't think it was being floated as real. But as I see it there aren't a lot of people going to edk2 for drivers to incorporate into coreboot so using that as a basis doesn't make a lot of sense. -Aaron From mr.nuke.me at gmail.com Wed Feb 18 18:53:47 2015 From: mr.nuke.me at gmail.com (Alexandru Gagniuc) Date: Wed, 18 Feb 2015 11:53:47 -0600 Subject: [coreboot] Unifying IO accessor macros In-Reply-To: References: <1727409.DxYcmTeq0u@nukelap.gtech> Message-ID: <1826368.PGSoiXWGdk@nukelap.gtech> On Wednesday, February 18, 2015 11:50:04 AM Aaron Durbin wrote: > On Wed, Feb 18, 2015 at 11:41 AM, Alexandru Gagniuc > > And you still haven't responded to my proposal of using EFI style. > > I thought that was a non-sensical proposal. My point exactly. Alex From pgeorgi at google.com Wed Feb 18 19:09:17 2015 From: pgeorgi at google.com (Patrick Georgi) Date: Wed, 18 Feb 2015 19:09:17 +0100 Subject: [coreboot] Unifying IO accessor macros In-Reply-To: References: <3180601.Vry57uOoJv@nukelap.gtech> <8710381.Gsar9oJxnB@nukelap.gtech> Message-ID: 2015-02-18 18:35 GMT+01:00 Aaron Durbin via coreboot : > coreboot is different than: > 1. linux > 2. uboot And similar to Solaris, Windows and the BSDs. As for libpayload, I'd rather import code from BSD than Linux for licensing reasons. > 3. libpayload > 4. Anything using libpayload Which could be fixed (since some changes are necessary in any case) Patrick -- Google Germany GmbH ABC-Str. 19 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Gesch?ftsf?hrer: Graham Law, Christine Elizabeth Flores From kevin.herbert at meraki.net Wed Feb 18 17:48:26 2015 From: kevin.herbert at meraki.net (Kevin Herbert) Date: Wed, 18 Feb 2015 08:48:26 -0800 Subject: [coreboot] Unifying IO accessor macros In-Reply-To: References: <3392575.qzWs7OMOgZ@nukelap.gtech> <3180601.Vry57uOoJv@nukelap.gtech> Message-ID: <43848F0E-8B29-45BD-A9BD-D312731D970F@meraki.net> Once the order is the same on all architectures, we could change it to match Linux at any point. I think its important to stop holding up architectural unification in the name of the perfect solution. The Coccinelle to switch the ordering is much safer to do after you have the ordering consistent and both arguments to the write functions are types which are incompatible with each other. Personally I am in the camp of having the same order as Linux, but there is a lot of ARM work held up because they are *different*. This is the problem I am trying to solve. Lets make the best community decision regardless of our personal opinions. Kevin > On Feb 18, 2015, at 8:40 AM, Aaron Durbin via coreboot wrote: > > On Wed, Feb 18, 2015 at 10:35 AM, Patrick Georgi > wrote: >> 2015-02-18 17:23 GMT+01:00 Vadim Bendebury : >>>> kernel, u-boot, etc. They all have the write(val, addr) semantics. I >>>> see no good reason to artificially erect an ever present barrier for >>>> integrating code into a coreboot system. >>>> >> Since all imported code requires some rework before it works for us, >> and redoing that particular issue is a matter of a simple spatch >> (http://coccinelle.lip6.fr/), I'm not sure that's actually that big a >> concern. >> >> @@ >> expression a,v; >> @@ >> -writel(v,a) >> +write32(a, v) > > Can you provide the spatch utility and script as well as the > documentation so that every potential contributor can perform the > necessary steps? Or we could be done w/ it once and for all and fix > the existing coreboot semantics. Then there's not another step for > anyone in perpetuity. Also keep in mind it's not just software going > into coreboot but reusing software within coreboot as well. It's a 2 > way street. > > I did volunteer to do the big change, and if people want I will. Let me know. > > -Aaron > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwerner at chromium.org Wed Feb 18 19:52:32 2015 From: jwerner at chromium.org (Julius Werner) Date: Wed, 18 Feb 2015 10:52:32 -0800 Subject: [coreboot] Unifying IO accessor macros In-Reply-To: References: <3180601.Vry57uOoJv@nukelap.gtech> <8710381.Gsar9oJxnB@nukelap.gtech> Message-ID: >> As Patrick already said, compared to the total effort to integrate external >> sources, the issue of argument order is insignificant. In the time you spent >> writing this email, you could have found out how to do it with coccinelle, and >> could have applied it to any number of sources. > > http://review.coreboot.org/8483 Remember that those other code bases use writel(v, a), not write32(v, a). Just going half the way by changing the order but not the name wouldn't be very useful I think. FWIW I sightly prefer write32(a, v) for purely aesthetic reasons (it's also more in line with our current setbits_le32(a, v)), but I really don't care much as long as we make a decision at all. There's currently ~3500 write32()s in upstream coreboot and ~2800 writel()s in Chromium coreboot (which has more ARM code), so now the impact for going either direction should be roughly the same. From mr.nuke.me at gmail.com Wed Feb 18 20:04:30 2015 From: mr.nuke.me at gmail.com (Alex G.) Date: Wed, 18 Feb 2015 13:04:30 -0600 Subject: [coreboot] Unifying IO accessor macros In-Reply-To: References: <3180601.Vry57uOoJv@nukelap.gtech> <8710381.Gsar9oJxnB@nukelap.gtech> Message-ID: <54E4E23E.5090202@gmail.com> On 02/18/2015 12:52 PM, Julius Werner wrote: > FWIW I sightly prefer write32(a, v) Then go for it. Alex From kevin at koconnor.net Wed Feb 18 20:28:55 2015 From: kevin at koconnor.net (Kevin O'Connor) Date: Wed, 18 Feb 2015 14:28:55 -0500 Subject: [coreboot] [ANNOUNCE] SeaBIOS 1.8.0 Message-ID: <20150218192855.GA10609@morn.localdomain> The 1.8.0 version of SeaBIOS has now been released. For more information on the release, please see: http://seabios.org/Releases New in this release: * Several USB timing fixes for USB controllers on real hardware * Initial support for USB3 hubs * Initial support for SD cards (on QEMU only) * Initial support for transitioning to 32bit mode using SMIs (on QEMU TCG only) * SeaVGABIOS improvements * Added cursor emulation to coreboot native init vgabios (cbvga) * Added support for read character calls when in graphics mode * Developer documentation added to "docs/" directory in the code repository and several documentation updates * Several bug fixes and code cleanups For information on obtaining SeaBIOS, please see: http://seabios.org/Download From stefan.reinauer at coreboot.org Wed Feb 18 20:46:24 2015 From: stefan.reinauer at coreboot.org (Stefan Reinauer) Date: Wed, 18 Feb 2015 20:46:24 +0100 Subject: [coreboot] Unifying IO accessor macros In-Reply-To: References: Message-ID: <20150218194624.GA7909@coreboot.org> * Julius Werner [150218 00:12]: > I'd like to propose an API change/cleanup for a long-standing problem > with architecture-independent code that people have hit and privately > discussed/cursed multiple times already, but no one really had time to > make the big change/fix yet. (Some earlier discussion among Chromium > people about this is available at http://crbug.com/451388 ) [..] I think nobody disagrees that type checking is a bad idea here. It was a mistake to let type checking free versions of these accessors slip into the tree into the first place. The second part is a little bit more prone to personal preferences. - Using 8 / 16 / 32 / 64 for data size is more explicit that b / w / l / q - (addr, val) is more aligned with other APIs in coreboot - Using the Linux API as a standard will make it easier for people to switch between code bases, and thus is a lot less error prone - Using the Linux API makes it easier to share code with other projects. such as u-boot, Linux, libpayload based projects Since there is no clear winner, I would like to ask you to participate in a poll to measure what people would prefer: http://doodle.com/3dwbudycrypg9xyf Stefan From dhendrix at google.com Wed Feb 18 21:09:22 2015 From: dhendrix at google.com (David Hendricks) Date: Wed, 18 Feb 2015 12:09:22 -0800 Subject: [coreboot] Unifying IO accessor macros In-Reply-To: <8710381.Gsar9oJxnB@nukelap.gtech> References: <3180601.Vry57uOoJv@nukelap.gtech> <8710381.Gsar9oJxnB@nukelap.gtech> Message-ID: On Wed, Feb 18, 2015 at 8:49 AM, Alexandru Gagniuc wrote: > On Wednesday, February 18, 2015 09:16:07 AM Aaron Durbin wrote: > > As I have noted on http://review.coreboot.org/#/c/7924/ it's very > > short sighted to go this route. In assembling a coreboot stack (which > > includes libpayload and the payload itself) the code usually comes > > from different software systems. Those include libpayload, linux > > kernel, u-boot, etc. They all have the write(val, addr) semantics. I > > see no good reason to artificially erect an ever present barrier for > > integrating code into a coreboot system. > > > As Patrick already said, compared to the total effort to integrate external > sources, the issue of argument order is insignificant. In the time you > spent > writing this email, you could have found out how to do it with coccinelle, > and > could have applied it to any number of sources. > > > Alex, you've clearly stated your opinion you've not justified a reason > > for keeping the barrier. > > If you think that something as simple as this is a barrier, then you're > likely > just copypasting code. In that case, I do want a barrier to protect you > from > yourself, and from putting up code that was no reviewed in its entirety. > Really, it's not a barrier. > I don't think this argument makes sense for code that is being actively developed in other code bases and imported into coreboot. Of course, if you're importing stable code and don't expect much churn, tidying things up is a fine idea. But increasing deltas while a project is still under active development only serves to make integration and maintenance efforts more troublesome and prone to error. It's not a productive use of anyone's time when there are real bugs to solve. Vendors often have code which they have already qualified and are understandably reluctant to make any changes to it, even trivial aesthetic ones. I'd like to make it easier for them to contribute directly to coreboot, and throwing up artificial barriers does not help them gain traction. -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhendrix at google.com Wed Feb 18 21:11:05 2015 From: dhendrix at google.com (David Hendricks) Date: Wed, 18 Feb 2015 12:11:05 -0800 Subject: [coreboot] Unifying IO accessor macros In-Reply-To: References: <3180601.Vry57uOoJv@nukelap.gtech> <8710381.Gsar9oJxnB@nukelap.gtech> Message-ID: On Wed, Feb 18, 2015 at 10:52 AM, Julius Werner wrote: > >> As Patrick already said, compared to the total effort to integrate > external > >> sources, the issue of argument order is insignificant. In the time you > spent > >> writing this email, you could have found out how to do it with > coccinelle, and > >> could have applied it to any number of sources. > > > > http://review.coreboot.org/8483 > > Remember that those other code bases use writel(v, a), not write32(v, > a). Just going half the way by changing the order but not the name > wouldn't be very useful I think. > Yes, fixing the order is far more important. I wouldn't even care if we still end up with both write32(a, v) or writel(a, v) in the codebase (or u32 vs. uint32_t), so long the usage is consistent and wrappers are trivial. -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.reinauer at coreboot.org Wed Feb 18 22:17:21 2015 From: stefan.reinauer at coreboot.org (Stefan Reinauer) Date: Wed, 18 Feb 2015 22:17:21 +0100 Subject: [coreboot] GSOC 2015 Preperations In-Reply-To: <4150716.nvA6L3ET4p@nukelap.gtech> References: <4150716.nvA6L3ET4p@nukelap.gtech> Message-ID: <20150218211721.GA18973@coreboot.org> * Alexandru Gagniuc [150214 01:13]: > On Saturday, February 14, 2015 12:05:28 AM Marc Jones wrote: > > Hi Everyone, > > > Hi, > > > Please update the wiki page with project ideas. > > http://www.coreboot.org/Project_Ideas > > > That's the first unlocked page in the coreboot wiki I have seen for quite some > time. To put this into perspective, it turns out that 5 out of over 450 pages are protected. Stefan From stefan.reinauer at coreboot.org Wed Feb 18 22:21:44 2015 From: stefan.reinauer at coreboot.org (Stefan Reinauer) Date: Wed, 18 Feb 2015 22:21:44 +0100 Subject: [coreboot] On the subject of collaboration In-Reply-To: <5037198.UkVmxV0nFL@nukelap.gtech> References: <4150716.nvA6L3ET4p@nukelap.gtech> <5037198.UkVmxV0nFL@nukelap.gtech> Message-ID: <20150218212144.GB18973@coreboot.org> * Alexandru Gagniuc [150214 02:14]: > It's that time of the year it seems. Last year, there were talks about > reducing the number of gerrit submitters. I'm certain you remember the anger > this caused amongst non-commercial members of the community when the proposed > list contained exclusively commercial community members, and I'm certain you > remember how that almost lead to a fork. > > This year's theme goes on the same lines. Except that it's not as tactful as > last year. It's no longer "I'm planning to do this". It's "I've already done > this". Let's see. We've locked most wiki pages to a select few contributors. A > so-called code of conduct was unilaterally introduced. Let's look at each in > part. [..] > Do we really want to push people's nerves every year until we finally get a > fork? > > Alex Alex, the leadership of this project reserves the right to enforce standards and, where required, lock down parts of coreboot.org or the mailing list to enforce those standards. We value your contributions. We also understand that you may not find this situation acceptable and hence may not be able to continue as a contributor. Stefan From stefan.reinauer at coreboot.org Wed Feb 18 22:26:21 2015 From: stefan.reinauer at coreboot.org (Stefan Reinauer) Date: Wed, 18 Feb 2015 22:26:21 +0100 Subject: [coreboot] memtest86 reading 0k memory In-Reply-To: <54D3B52C.2090904@raptorengineeringinc.com> References: <54D3B52C.2090904@raptorengineeringinc.com> Message-ID: <20150218212621.GA23186@coreboot.org> * Timothy Pearson [150205 19:23]: > e820: BIOS-provided physical RAM map: > BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable > BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved > BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved > BIOS-e820: [mem 0x0000000000100000-0x000000003ffacfff] usable > BIOS-e820: [mem 0x000000003ffad000-0x000000003fffffff] reserved > BIOS-e820: [mem 0x00000000e0000000-0x00000000efffffff] reserved One of the issues seems to be that the coreboot table space is not marked as reserved (i.e. the lower 4k should be marked as reserved, and whatever is used at the top of memory) Stefan From mr.nuke.me at gmail.com Wed Feb 18 22:48:33 2015 From: mr.nuke.me at gmail.com (Alexandru Gagniuc) Date: Wed, 18 Feb 2015 15:48:33 -0600 Subject: [coreboot] On the subject of collaboration In-Reply-To: <20150218212144.GB18973@coreboot.org> References: <5037198.UkVmxV0nFL@nukelap.gtech> <20150218212144.GB18973@coreboot.org> Message-ID: <26401612.y3EYHMUHPB@nukelap.gtech> On Wednesday, February 18, 2015 10:21:44 PM Stefan Reinauer wrote: > * Alexandru Gagniuc [150214 02:14]: > [..] > > > Do we really want to push people's nerves every year until we finally get > > a > > fork? > > > > Alex > > Alex, > > the leadership of this project reserves the right to enforce standards > and, where required, lock down parts of coreboot.org or the mailing list > to enforce those standards. > > We value your contributions. We also understand that you may not find > this situation acceptable and hence may not be able to continue as a > contributor. > I think you've pointed just pointed out the root of the problem. Nobody can claim that you, or a small group of people is entitled to absolute power in the project. The fact that someone owns all or part of the infrastructure that runs coreboot does not entitle them to claim that they, or a small group of people have absolute power in the project. If you, or any of the persons we contributors look towards as examples and guides fail to recognize that we are in fact a community, things will go south. I've seen it happen before, and I keep hoping it won't happen here. I hope this gives all of us an idea of why people can get ticked off, and helps us avoid situations like this one (or the one last year) in the future. Alex P.S. I own part of the infrastructure that runs coreboot. Arguably, I own the most expensive part of said infrastructure. So what? From jwerner at chromium.org Wed Feb 18 23:47:51 2015 From: jwerner at chromium.org (Julius Werner) Date: Wed, 18 Feb 2015 14:47:51 -0800 Subject: [coreboot] Unifying IO accessor macros In-Reply-To: References: <3180601.Vry57uOoJv@nukelap.gtech> <8710381.Gsar9oJxnB@nukelap.gtech> Message-ID: > I think nobody disagrees that type checking is a bad idea here. I ain't not unsure that you failed to not make no mistake with the missing lack of double negatives there... ;) > I don't think this argument makes sense for code that is being actively > developed in other code bases and imported into coreboot. Of course, if > you're importing stable code and don't expect much churn, tidying things up > is a fine idea. But increasing deltas while a project is still under active > development only serves to make integration and maintenance efforts more > troublesome and prone to error. It's not a productive use of anyone's time > when there are real bugs to solve. > > Vendors often have code which they have already qualified and are > understandably reluctant to make any changes to it, even trivial aesthetic > ones. I'd like to make it easier for them to contribute directly to > coreboot, and throwing up artificial barriers does not help them gain > traction. Do we really want to facilitate more of these wholesale imports of untouched, existing code dumps from other sources into coreboot? It seems to me that those always end up bad for us... code is hard to read and follow because of switched conventions, it could have depended on different requirements for the environment than what coreboot provides, it often includes a lot of hacky and overcomplicated code that the original use case might have needed but we don't, people will end up making changes after the import that desync it with the source, etc. I think for small stuff like individual drivers we're better off just rewriting them with a sound design from the ground up tailored to our use case (at least that guarantees that someone really understood and thought through how it all works within the coreboot context). How often have we pulled in updates for something like that anyway? For really large scale external imports (like AMD Agesa), we can stow it away in vendorcode/ with translator headers to allow it to keep its own conventions completely unchanged, without risk of it leaking out into the rest of coreboot. From gregg.drwho8 at gmail.com Wed Feb 18 23:49:55 2015 From: gregg.drwho8 at gmail.com (Gregg Levine) Date: Wed, 18 Feb 2015 17:49:55 -0500 Subject: [coreboot] On the subject of collaboration In-Reply-To: <26401612.y3EYHMUHPB@nukelap.gtech> References: <5037198.UkVmxV0nFL@nukelap.gtech> <20150218212144.GB18973@coreboot.org> <26401612.y3EYHMUHPB@nukelap.gtech> Message-ID: Hello! Here's suggestion. Let's drop the whole business. Its taking over from the regular day to day business. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again." On Wed, Feb 18, 2015 at 4:48 PM, Alexandru Gagniuc wrote: > On Wednesday, February 18, 2015 10:21:44 PM Stefan Reinauer wrote: >> * Alexandru Gagniuc [150214 02:14]: >> [..] >> >> > Do we really want to push people's nerves every year until we finally get >> > a >> > fork? >> > >> > Alex >> >> Alex, >> >> the leadership of this project reserves the right to enforce standards >> and, where required, lock down parts of coreboot.org or the mailing list >> to enforce those standards. >> >> We value your contributions. We also understand that you may not find >> this situation acceptable and hence may not be able to continue as a >> contributor. >> > I think you've pointed just pointed out the root of the problem. Nobody can > claim that you, or a small group of people is entitled to absolute power in > the project. The fact that someone owns all or part of the infrastructure that > runs coreboot does not entitle them to claim that they, or a small group of > people have absolute power in the project. > > If you, or any of the persons we contributors look towards as examples and > guides fail to recognize that we are in fact a community, things will go > south. I've seen it happen before, and I keep hoping it won't happen here. > > I hope this gives all of us an idea of why people can get ticked off, and > helps us avoid situations like this one (or the one last year) in the future. > > Alex > > P.S. > I own part of the infrastructure that runs coreboot. Arguably, I own the most > expensive part of said infrastructure. So what? > > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot From c-d.hailfinger.devel.2006 at gmx.net Thu Feb 19 00:14:47 2015 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 19 Feb 2015 00:14:47 +0100 Subject: [coreboot] Automated test system: Nominations wanted Message-ID: <54E51CE7.5070801@gmx.net> Hi, I am currently planning to set up a test system with 5 (later up to 10) machines boot testing each new coreboot commit. This test system will be serviced (i.e. recovery from bricking) Mo-Fr during CET/CEST office hours. Current goals for every commit: - Check if coreboot + SeaBIOS are able to boot Linux to a point where network is up and running Current goals for every work day: - Check if screen, keyboard and touchpad/mouse work - Check if USB works and has the expected transfer speed (i.e. if USB High and Super Speed both work) Future goals for every work day: - Run memtest86+ (short run) - Run GRUB2 and boot Linux - Check if USB works (see above) Once any test running once per work day can be automated with reasonable effort (i.e. not requiring robots or human interaction), it can be moved to a per-commit goal. The selection of target systems should include: 1. at least one x86 laptop without an active ME (present but inactive would be OK) 2. at least one x86 laptop which can boot x86-blob-free (except microcode) 3. at least one x86 board or laptop which needs neither blobs (except microcode) nor ME 4. at least one x86 board with reasonable (past or present) business market penetration 5. if the first two laptops use the same CPU vendor, a board using a different x86 CPU vendor 1+2 are designed to partially remove the potential for nasty surprises, 3 should remove nasty surprises completely, 4 is the one I need to show that the test system is actually relevant for our goals, 5 should give us better coverage outside the most common systems used by coreboot developers. Please nominate machines (e.g. "Thinkpad T60 with Intel graphics") and tell me to which category they belong. If a system fits into multiple categories, please specify that as well. I will try to consolidate the recommendations and buy those machines. Once the system is up and running (hopefully in May), I will add more machines suggested by the community as time permits. The time window for suggestions will close at the end of February. Fire away! Regards, Carl-Daniel From dhendrix at google.com Thu Feb 19 00:46:25 2015 From: dhendrix at google.com (David Hendricks) Date: Wed, 18 Feb 2015 15:46:25 -0800 Subject: [coreboot] Unifying IO accessor macros In-Reply-To: References: <3180601.Vry57uOoJv@nukelap.gtech> <8710381.Gsar9oJxnB@nukelap.gtech> Message-ID: On Wed, Feb 18, 2015 at 2:47 PM, Julius Werner wrote: > > I think nobody disagrees that type checking is a bad idea here. > > I ain't not unsure that you failed to not make no mistake with the > missing lack of double negatives there... ;) > > > I don't think this argument makes sense for code that is being actively > > developed in other code bases and imported into coreboot. Of course, if > > you're importing stable code and don't expect much churn, tidying things > up > > is a fine idea. But increasing deltas while a project is still under > active > > development only serves to make integration and maintenance efforts more > > troublesome and prone to error. It's not a productive use of anyone's > time > > when there are real bugs to solve. > > > > Vendors often have code which they have already qualified and are > > understandably reluctant to make any changes to it, even trivial > aesthetic > > ones. I'd like to make it easier for them to contribute directly to > > coreboot, and throwing up artificial barriers does not help them gain > > traction. > > Do we really want to facilitate more of these wholesale imports of > untouched, existing code dumps from other sources into coreboot? I don't think that's necessarily a bad thing during heavy development. Obviously we'd want to tidy things up after the fact and use wrappers until then, but insofar as this whole write32/writel and arg ordering discussion goes there hasn't been much to aspire to in terms of tidying things. So basically what I'm advocating is to define a "proper" approach that we apply to coreboot in general, while being flexible about importing code. Once we define the proper approach, then applying an spatch to bring the style into conformance and remove the scaffolding should be relatively painless. It > seems to me that those always end up bad for us... code is hard to > read and follow because of switched conventions, Yep. And for the person porting the code, switching conventions on-the-fly might be even more confusing. I generally like to see code working before making such changes. > it could have > depended on different requirements for the environment than what > coreboot provides, it often includes a lot of hacky and > overcomplicated code that the original use case might have needed but > we don't, people will end up making changes after the import that > desync it with the source, etc. True, and I think it's more productive to prioritize fixing those issues over aesthetic ones. I'm all for re-factoring code. I just don't think forcing huge deltas from the get-go during heavy development is a great way to do it. > I think for small stuff like > individual drivers we're better off just rewriting them with a sound > design from the ground up tailored to our use case (at least that > guarantees that someone really understood and thought through how it > all works within the coreboot context). Agreed - For small stuff I'm totally on-board. That might not be the case, however, for more complicated stuff. For example, if a vendor updates DRAM init code in u-boot multiple times over a period of weeks/months and we need to apply the same updates to coreboot, having hundreds of cosmetic changes show up in the diff just makes the porting process more difficult and more prone to error. > For really large scale > external imports (like AMD Agesa), we can stow it away in vendorcode/ > with translator headers to allow it to keep its own conventions > completely unchanged, without risk of it leaking out into the rest of > coreboot. > Yep. -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vidwer at gmail.com Thu Feb 19 02:40:07 2015 From: vidwer at gmail.com (Idwer Vollering) Date: Thu, 19 Feb 2015 02:40:07 +0100 Subject: [coreboot] Automated test system: Nominations wanted In-Reply-To: <54E51CE7.5070801@gmx.net> References: <54E51CE7.5070801@gmx.net> Message-ID: 2015-02-19 0:14 GMT+01:00 Carl-Daniel Hailfinger : > Hi, > > I am currently planning to set up a test system with 5 (later up to 10) > machines boot testing each new coreboot commit. This test system will be > serviced (i.e. recovery from bricking) Mo-Fr during CET/CEST office hours. (..) > Please nominate machines (e.g. "Thinkpad T60 with Intel graphics") and > tell me to which category they belong. If a system fits into multiple > categories, please specify that as well. asus f2a85-m, desktop board tyan s8226 and/or supermicro h8scm and/or supermicro h8qgi, server boards > I will try to consolidate the recommendations and buy those machines. > Once the system is up and running (hopefully in May), I will add more > machines suggested by the community as time permits. > > The time window for suggestions will close at the end of February. > > Fire away! > > Regards, > Carl-Daniel > > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot From werner.zeh at gmx.net Thu Feb 19 07:41:56 2015 From: werner.zeh at gmx.net (Werner Zeh) Date: Thu, 19 Feb 2015 07:41:56 +0100 Subject: [coreboot] New interface for I2C in coreboot In-Reply-To: References: , Message-ID: Hi all. I am fully aware of how I2C bus works and I never liked this interface. This is because you cannot really probe devices on the bus, there is not really a status information available on the bus and one can confuse a slave in that way that it will block the bus without a way to reset it (at least there is a trick available). After I have thought for a long time about this issue, I can understand the need of the change that has been done. Nevertheless, I still not want the place where the cut in the interface was done. With the new interface the driver for I2C bus is truncated because with this interface the driver do not have the knowledge of the whole transfer that must be performed on the bus. Instead, the driver is fed with small pieces of data. In this way, we cannot design a driver that is smarter and can use all the abilities a hardware given I2C controller can provide. I would like to discuss the following approach: Construct all the data you need to transmit/receive outside of the I2C driver (i.e. inside the user of I2C driver which can be itself a driver for the slave e.g. an EEPROM, tpm, whatever). We can use a similar structure approach the new interface already has and chain this structures to build a complete transaction. We can add control information (read/write data, start/stop condition...) to every piece of the transaction (let's call it chunk) as well as needed timeout or retry requirements. The list of all this chunks builds up the complete transaction. This transaction will be passed into the I2C driver. Now the driver can handle the list as it wants to. We can write simple drivers that consist of GPIO manipulation to emulate the I2C controller. But we also can write smart drivers which can use all the abilities a given hardware controller provide. In my opinion this approach will allow us to be more flexible without wasting hardware possibilities and with a comparable complexity we currently have with the new interface. Any thoughts are welcome. Werner > Gesendet: Dienstag, 10. Februar 2015 um 20:36 Uhr > Von: "Julius Werner" > An: "Werner Zeh" > Cc: coreboot at coreboot.org, "Julius Werner" , "Marc Jones" , martin at se-eng.com, "Patrick Georgi" > Betreff: Re: New interface for I2C in coreboot > > I think the idea behind this change was mostly that the old API was > too inflexible and some I2C device drivers could not be properly > written with it. Take a look at line 139 in this file from the first > patch: http://review.coreboot.org/#/c/7751/3/src/drivers/i2c/tpm/tpm.c at 139 > . What this really does is trying to do all of the normal parts of an > I2C read transaction manually, because TPMs can add so long delays at > any point that the normal I2C controller drivers would already hit > their timeout. With the old API this was only possible with a crude > hack of setting the address length to 0 (so i2c_read() would skip the > register address write completely). Doing a "raw read" with the new > API does the same thing much clearer, and it's far more obvious to > controller driver authors that they need to implement this (otherwise, > it's easy to just assume alen == 0 is illegal until someone tries to > use the TPM driver with it, which I think is what hit us on Tegra). > The new API also makes the rules about when to use a repeated start vs > a complete stop and start much clearer (which should not make a > difference for the device, but in practice sometimes does). > > I think Werner's original issue is easy to solve: you can either just > construct struct i2c_seg structures and call i2c_transfer() directly, > or implement a new i2c_write() wrapper similar to i2c_writeb() (just > with a variable data length). Maybe even just make i2c_writeb() a > one-line wrapper macro on top of the new function... all fine by me, I > think the only reason we didn't make more convenience functions is > because we didn't need them at the time. > > The implementation problems Patrick mentioned are unfortunately true > for some controllers which attempt to be more clever than they > should... however, the thing is that we need to somehow implement raw > I2C reads anyway (to support the alen == 0 case in the old API and > make things like that TPM driver work). In the end we probably need to > implement less primitives for the new API ("raw write" and "raw read") > than for the old one ("full write", "full read", "raw write" and "raw > read"). If that means we end up not using the > do-everything-in-one-transaction "feature" of some controllers in > favor of more controllable low-level accesses, I don't see a problem > with that. > From werner.zeh at gmx.net Thu Feb 19 09:21:12 2015 From: werner.zeh at gmx.net (Werner Zeh) Date: Thu, 19 Feb 2015 09:21:12 +0100 Subject: [coreboot] New interface for I2C in coreboot In-Reply-To: References: , , Message-ID: OK, forget my last Mail...I was to blind to see the truth :-) We already have my approach with the new interface. We maybe can expand it to have informations like time-out or retry count for a given segment. Werner > Gesendet: Donnerstag, 19. Februar 2015 um 07:41 Uhr > Von: "Werner Zeh" > An: "Julius Werner" , gaumless at gmail.com, pgeorgi at google.com > Cc: coreboot at coreboot.org > Betreff: Re: [coreboot] New interface for I2C in coreboot > > Hi all. > > I am fully aware of how I2C bus works and I never liked this interface. This is because you cannot really probe devices on the bus, there is not really a status information available on the bus and one can confuse a slave in that way that it will block the bus without a way to reset it (at least there is a trick available). > After I have thought for a long time about this issue, I can understand the need of the change that has been done. Nevertheless, I still not want the place where the cut in the interface was done. > > With the new interface the driver for I2C bus is truncated because with this interface the driver do not have the knowledge of the whole transfer that must be performed on the bus. Instead, the driver is fed with small pieces of data. In this way, we cannot design a driver that is smarter and can use all the abilities a hardware given I2C controller can provide. > > I would like to discuss the following approach: > Construct all the data you need to transmit/receive outside of the I2C driver (i.e. inside the user of I2C driver which can be itself a driver for the slave e.g. an EEPROM, tpm, whatever). We can use a similar structure approach the new interface already has and chain this structures to build a complete transaction. We can add control information (read/write data, start/stop condition...) to every piece of the transaction (let's call it chunk) as well as needed timeout or retry requirements. The list of all this chunks builds up the complete transaction. This transaction will be passed into the I2C driver. > Now the driver can handle the list as it wants to. We can write simple drivers that consist of GPIO manipulation to emulate the I2C controller. But we also can write smart drivers which can use all the abilities a given hardware controller provide. > In my opinion this approach will allow us to be more flexible without wasting hardware possibilities and with a comparable complexity we currently have with the new interface. > > Any thoughts are welcome. > > Werner > > > > > Gesendet: Dienstag, 10. Februar 2015 um 20:36 Uhr > > Von: "Julius Werner" > > An: "Werner Zeh" > > Cc: coreboot at coreboot.org, "Julius Werner" , "Marc Jones" , martin at se-eng.com, "Patrick Georgi" > > Betreff: Re: New interface for I2C in coreboot > > > > I think the idea behind this change was mostly that the old API was > > too inflexible and some I2C device drivers could not be properly > > written with it. Take a look at line 139 in this file from the first > > patch: http://review.coreboot.org/#/c/7751/3/src/drivers/i2c/tpm/tpm.c at 139 > > . What this really does is trying to do all of the normal parts of an > > I2C read transaction manually, because TPMs can add so long delays at > > any point that the normal I2C controller drivers would already hit > > their timeout. With the old API this was only possible with a crude > > hack of setting the address length to 0 (so i2c_read() would skip the > > register address write completely). Doing a "raw read" with the new > > API does the same thing much clearer, and it's far more obvious to > > controller driver authors that they need to implement this (otherwise, > > it's easy to just assume alen == 0 is illegal until someone tries to > > use the TPM driver with it, which I think is what hit us on Tegra). > > The new API also makes the rules about when to use a repeated start vs > > a complete stop and start much clearer (which should not make a > > difference for the device, but in practice sometimes does). > > > > I think Werner's original issue is easy to solve: you can either just > > construct struct i2c_seg structures and call i2c_transfer() directly, > > or implement a new i2c_write() wrapper similar to i2c_writeb() (just > > with a variable data length). Maybe even just make i2c_writeb() a > > one-line wrapper macro on top of the new function... all fine by me, I > > think the only reason we didn't make more convenience functions is > > because we didn't need them at the time. > > > > The implementation problems Patrick mentioned are unfortunately true > > for some controllers which attempt to be more clever than they > > should... however, the thing is that we need to somehow implement raw > > I2C reads anyway (to support the alen == 0 case in the old API and > > make things like that TPM driver work). In the end we probably need to > > implement less primitives for the new API ("raw write" and "raw read") > > than for the old one ("full write", "full read", "raw write" and "raw > > read"). If that means we end up not using the > > do-everything-in-one-transaction "feature" of some controllers in > > favor of more controllable low-level accesses, I don't see a problem > > with that. > > > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > From peter at stuge.se Thu Feb 19 11:45:08 2015 From: peter at stuge.se (Peter Stuge) Date: Thu, 19 Feb 2015 11:45:08 +0100 Subject: [coreboot] New interface for I2C in coreboot In-Reply-To: References: Message-ID: <20150219104508.31471.qmail@stuge.se> Werner Zeh wrote: > We already have my approach with the new interface. > > We maybe can expand it to have informations like time-out or retry > count for a given segment. I think this is a really good idea. I also think that this structure applies to SPI as well. //Peter From pgeorgi at google.com Thu Feb 19 12:35:11 2015 From: pgeorgi at google.com (Patrick Georgi) Date: Thu, 19 Feb 2015 12:35:11 +0100 Subject: [coreboot] Automated test system: Nominations wanted In-Reply-To: <54E51CE7.5070801@gmx.net> References: <54E51CE7.5070801@gmx.net> Message-ID: 2015-02-19 0:14 GMT+01:00 Carl-Daniel Hailfinger : > I am currently planning to set up a test system with 5 (later up to 10) > machines boot testing each new coreboot commit. This test system will be > serviced (i.e. recovery from bricking) Mo-Fr during CET/CEST office hours. > > Current goals for every commit: > - Check if coreboot + SeaBIOS are able to boot Linux to a point where > network is up and running > > Current goals for every work day: > - Check if screen, keyboard and touchpad/mouse work > - Check if USB works and has the expected transfer speed (i.e. if USB > High and Super Speed both work) http://blogs.coreboot.org/blog/author/ayushsagar/ documents last year's GSoC project to implement some of those - incl. a screen test using the display present signals. Through external flashing, there's also no need to handle unbricking manually. Patrick -- Google Germany GmbH ABC-Str. 19 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Gesch?ftsf?hrer: Graham Law, Christine Elizabeth Flores From kevin at koconnor.net Thu Feb 19 16:11:35 2015 From: kevin at koconnor.net (Kevin O'Connor) Date: Thu, 19 Feb 2015 10:11:35 -0500 Subject: [coreboot] updating coreboot && SeaBIOS on an Acer C720 In-Reply-To: <20150209073240.GA1469@c720-r276659> References: <20150208190338.GA1261@c720-r276659> <54D7C9CD.50100@gmail.com> <20150208205549.GA1771@c720-r276659> <20150209073240.GA1469@c720-r276659> Message-ID: <20150219151134.GA5265@morn.localdomain> On Mon, Feb 09, 2015 at 08:32:40AM +0100, Matthias Apitz wrote: > El d?a Sunday, February 08, 2015 a las 11:14:10PM +0100, Idwer Vollering escribi?: > > 2015-02-08 21:55 GMT+01:00 Matthias Apitz : > > > El d?a Sunday, February 08, 2015 a las 02:40:45PM -0600, Alex G. escribi?: > > > > > >> Suspect number one is the device overheating. The shutdown is > > >> triggered by the EC. I don't know how you can enable ACPI debug output > > >> on BSD though. On linux, it would be "echo 1 > > > >> /sys/module/acpi/parameters/aml_debug_output", so whatever the FreeBSD > > >> equivalent of that is. > > > > hw.acpi.verbose=1 would be a start. > > ... > > Thanks for all the hints. > > As I said, the events are sporadic, seldom, but complete power-off (like > as you would cut the cable from the motherboard). Of course the system has no > chance to write anything to /var/log/messages or console. > > My hope while writing to coreboot@ was to get a pointer to the list of > open ore solved issues within coreboot and/or SeaBIOS to see if this > issue is somewhat known, solved or could be related to some known or > solved issue. Where can I find such a list which is normally (as we do > in my company) attached to the Release Notes of a new version of > software. The SeaBIOS release notes are at http://www.seabios.org/Releases . It only provides a list of high level features though. One can also read through the SeaBIOS git commit history. The symptons you report do not sound like a SeaBIOS issue. SeaBIOS relies on coreboot to initialize most hardware. Once the OS starts, it's unlikely that SeaBIOS would adversely impact the machine behavior. -Kevin From kevin at koconnor.net Thu Feb 19 16:28:02 2015 From: kevin at koconnor.net (Kevin O'Connor) Date: Thu, 19 Feb 2015 10:28:02 -0500 Subject: [coreboot] Mohon Peak, Memtest86+ does not start In-Reply-To: <54C78BAF.30309@gmail.com> References: <54BE5897.5010909@gmail.com> <20150120193318.GA24909@coreboot.org> <54C1FBFC.10806@gmail.com> <54C78BAF.30309@gmail.com> Message-ID: <20150219152802.GB5265@morn.localdomain> On Tue, Jan 27, 2015 at 03:59:27PM +0300, Kuzmichev Viktor wrote: > Thank you very much, this helped a lot! Now memtest is loading and it > successfully performs RAM tests. > But there is another issue. Somehow, input via serial console does not work. > And it seems like the problem is not in memtest, rather it's in SeaBIOS or > coreboot. There is no any prompt for input in coreboot. But there is in > SeaBIOS, and I was not able to enter boot menu since it did not respond to > F12. Although, SeaBIOS responds to the keyboard that is directly connected > to the board while memtest does not seem to respond at all (at least, I > tried to hit Esc which should reboot the board). > I've tried to search for this but so far found nothing. > Will appreciate any help. I'm not sure if you found a solution to your issue. SeaBIOS only supports debug output on serial. For a serial console, one can use sgabios with seabios - there is a description on how one can do this at: http://www.coreboot.org/SeaBIOS#Adding_sgabios_support -Kevin From kevin at koconnor.net Thu Feb 19 16:43:44 2015 From: kevin at koconnor.net (Kevin O'Connor) Date: Thu, 19 Feb 2015 10:43:44 -0500 Subject: [coreboot] memtest86 reading 0k memory In-Reply-To: <20150218212621.GA23186@coreboot.org> References: <54D3B52C.2090904@raptorengineeringinc.com> <20150218212621.GA23186@coreboot.org> Message-ID: <20150219154344.GC5265@morn.localdomain> On Wed, Feb 18, 2015 at 10:26:21PM +0100, Stefan Reinauer wrote: > * Timothy Pearson [150205 19:23]: > > e820: BIOS-provided physical RAM map: > > BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable > > BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved > > BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved > > BIOS-e820: [mem 0x0000000000100000-0x000000003ffacfff] usable > > BIOS-e820: [mem 0x000000003ffad000-0x000000003fffffff] reserved > > BIOS-e820: [mem 0x00000000e0000000-0x00000000efffffff] reserved > > One of the issues seems to be that the coreboot table space is not > marked as reserved (i.e. the lower 4k should be marked as reserved, and > whatever is used at the top of memory) coreboot tends to reserve the first 4K, but this breaks lots of bootloaders. So, SeaBIOS always overrides coreboot and unreserves the first 4K. My experience is that the first one megabyte of the e820 is just "magical" and should always read as listed above. Separately, it is possible for SeaBIOS to remove the coreboot table forwarder, and thus force memtest86 to not use the coreboot tables. I'm not sure if this would affect other programs though. -Kevin From kevin at koconnor.net Thu Feb 19 17:22:19 2015 From: kevin at koconnor.net (Kevin O'Connor) Date: Thu, 19 Feb 2015 11:22:19 -0500 Subject: [coreboot] Automated test system: Nominations wanted In-Reply-To: References: <54E51CE7.5070801@gmx.net> Message-ID: <20150219162219.GD5265@morn.localdomain> On Thu, Feb 19, 2015 at 12:35:11PM +0100, Patrick Georgi via coreboot wrote: > 2015-02-19 0:14 GMT+01:00 Carl-Daniel Hailfinger > : > > I am currently planning to set up a test system with 5 (later up to 10) > > machines boot testing each new coreboot commit. This test system will be > > serviced (i.e. recovery from bricking) Mo-Fr during CET/CEST office hours. > > > > Current goals for every commit: > > - Check if coreboot + SeaBIOS are able to boot Linux to a point where > > network is up and running > > > > Current goals for every work day: > > - Check if screen, keyboard and touchpad/mouse work > > - Check if USB works and has the expected transfer speed (i.e. if USB > > High and Super Speed both work) > http://blogs.coreboot.org/blog/author/ayushsagar/ documents last > year's GSoC project to implement some of those - incl. a screen test > using the display present signals. > > Through external flashing, there's also no need to handle unbricking manually. This is a bit off topic, but I've been thinking that a neat project would be to package up an automated test and recovery system using the Beagle Bone Black board. The Beagle Bone Black isn't too expensive ($55), it is widely available, it has an SPI interface (for emergency flashing), has GPIOs (which, with a level shifter, could be used to turn on/off the board and report LED status), and can emulate a USB client. The emulated USB client could (in theory) be used to emulate a USB boot drive, a USB networking adapter, a USB keyboard, a USB serial port, and/or a USB debug device. In theory, one could wrap many of the target board's standard interfaces so that automated testing and remote development could be done. It would be a bit of work to get the software working and packaged nicely - but if it was, I think it could enable many more users to participate in automated tests and remote development. -Kevin From pgeorgi at google.com Thu Feb 19 17:42:19 2015 From: pgeorgi at google.com (Patrick Georgi) Date: Thu, 19 Feb 2015 17:42:19 +0100 Subject: [coreboot] Automated test system: Nominations wanted In-Reply-To: <20150219162219.GD5265@morn.localdomain> References: <54E51CE7.5070801@gmx.net> <20150219162219.GD5265@morn.localdomain> Message-ID: 2015-02-19 17:22 GMT+01:00 Kevin O'Connor : > It would be a bit of work to get the software working and packaged > nicely - but if it was, I think it could enable many more users to > participate in automated tests and remote development. That already was the hope of many coreboot related automated testing projects before. Wiring up some hardware isn't the problem. Patrick -- Google Germany GmbH ABC-Str. 19 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Gesch?ftsf?hrer: Graham Law, Christine Elizabeth Flores From jwerner at chromium.org Thu Feb 19 20:43:20 2015 From: jwerner at chromium.org (Julius Werner) Date: Thu, 19 Feb 2015 11:43:20 -0800 Subject: [coreboot] New interface for I2C in coreboot In-Reply-To: References: Message-ID: On Thu, Feb 19, 2015 at 12:21 AM, Werner Zeh wrote: > OK, forget my last Mail...I was to blind to see the truth :-) > We already have my approach with the new interface. > > We maybe can expand it to have informations like time-out or retry count for a given segment. One word of caution I'd like to add here is that making this API more complex/powerful requires significant effort, now and in the future. We already have 4 I2C driver implementations in coreboot, and 4 more are going to be upstreamed soon from the Chromium tree. As we scale up to we'll probably add at least one new driver per SoC vendor, maybe even per SoC. Adding complex functionality like retries to the API will require us to account for it over an over again in every single implementation. I think the question is really what we would gain from this. Even though some I2C controllers have more efficient modes that do multiple things at once, all I've yet seen could somehow be coerced to do real simple step-by-step transfers. Since we need to implement that anyway for the API, why do anything more? Efficiency? I think I2C transfers are generally so slow that a little more overhead here and there isn't going to make a measurable difference. These transaction-at-a-time hardware features are designed for operating systems that have other threads to schedule or the power impact of a high interrupt frequency to worry about, not us. From peter at stuge.se Thu Feb 19 21:12:45 2015 From: peter at stuge.se (Peter Stuge) Date: Thu, 19 Feb 2015 21:12:45 +0100 Subject: [coreboot] New interface for I2C in coreboot In-Reply-To: References: Message-ID: <20150219201245.11133.qmail@stuge.se> Julius Werner wrote: > > We maybe can expand it to have informations like time-out or > > retry count for a given segment. > > One word of caution I'd like to add here is that making this API more > complex/powerful requires significant effort, now and in the future. Not if the architecture is any good. > We already have 4 I2C driver implementations in coreboot, and 4 more > are going to be upstreamed soon from the Chromium tree. As we scale up > to we'll probably add at least one new driver per SoC vendor, maybe > even per SoC. Adding complex functionality like retries to the API > will require us to account for it over an over again in every single > implementation. No - that doesn't make any sense. Probably there will be a fair bit of code that can be shared among controllers. There aren't that many ways to implement I?C. > I think the question is really what we would gain from this. I think it's less about performance and more about an accurate and clean model being available to mainboard code when needed. //Peter From cjn at post1.dansknet.dk Thu Feb 19 21:44:27 2015 From: cjn at post1.dansknet.dk (cjn at post1.dansknet.dk) Date: Thu, 19 Feb 2015 21:44:27 +0100 Subject: [coreboot] Need help with MSI MS-7260 (K9N Neo) / MSI MS-7250 (K9N SLI) Message-ID: Hi, I'd like to run coreboot on my MSI MS-7250 (K9N SLI) mainboard. This board is apparently quite similar to the MSI MS-7260 (K9N Neo) which is already supported: http://www.coreboot.org/Board:msi/ms7260 This is what my board looks like, though mine is a version 2.2: http://www.msi.com/product/mb/K9N_SLI.html#hero-specification I tried booting the board with a coreboot ROM built for the MS-7260 (and an "AMD Athlon(tm) 64 X2 Dual Core Processor 5000+" CPU, 4 1GB DIMM sticks, and a Radeon 7000 graphics card). That didn't work, but I've attached the log. I've also attached the outputs from lspci, superiotool, and flashrom, for good measure. What needs to be done and what's a good place to start? Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: coreboot-boot.log Type: application/octet-stream Size: 56613 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lspci-output URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: superiotool-output URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: flashrom-output URL: From mylesgw at gmail.com Thu Feb 19 23:50:22 2015 From: mylesgw at gmail.com (Myles Watson) Date: Thu, 19 Feb 2015 14:50:22 -0800 Subject: [coreboot] Automated test system: Nominations wanted In-Reply-To: <54E51CE7.5070801@gmx.net> References: <54E51CE7.5070801@gmx.net> Message-ID: On Wed, Feb 18, 2015 at 3:14 PM, Carl-Daniel Hailfinger < c-d.hailfinger.devel.2006 at gmx.net> wrote: > Hi, > > I am currently planning to set up a test system with 5 (later up to 10) > machines boot testing each new coreboot commit. This test system will be > serviced (i.e. recovery from bricking) Mo-Fr during CET/CEST office hours. > > Current goals for every commit: > - Check if coreboot + SeaBIOS are able to boot Linux to a point where > network is up and running > > Current goals for every work day: > - Check if screen, keyboard and touchpad/mouse work > - Check if USB works and has the expected transfer speed (i.e. if USB > High and Super Speed both work) > > Future goals for every work day: > - Run memtest86+ (short run) > - Run GRUB2 and boot Linux > - Check if USB works (see above) > > Once any test running once per work day can be automated with reasonable > effort (i.e. not requiring robots or human interaction), it can be moved > to a per-commit goal. > > The selection of target systems should include: > 1. at least one x86 laptop without an active ME (present but inactive > would be OK) > 2. at least one x86 laptop which can boot x86-blob-free (except microcode) > 3. at least one x86 board or laptop which needs neither blobs (except > microcode) nor ME > 4. at least one x86 board with reasonable (past or present) business > market penetration > 5. if the first two laptops use the same CPU vendor, a board using a > different x86 CPU vendor > > Hi Carl-Daniel, Thanks for setting this up. I think it would be great to have Qemu and a couple of the boards supported by SimNOW. They don't really fit into your categories, but it is important to keep them working. Thanks, Myles > 1+2 are designed to partially remove the potential for nasty surprises, > 3 should remove nasty surprises completely, 4 is the one I need to show > that the test system is actually relevant for our goals, 5 should give > us better coverage outside the most common systems used by coreboot > developers. > > > Please nominate machines (e.g. "Thinkpad T60 with Intel graphics") and > tell me to which category they belong. If a system fits into multiple > categories, please specify that as well. > I will try to consolidate the recommendations and buy those machines. > Once the system is up and running (hopefully in May), I will add more > machines suggested by the community as time permits. > > The time window for suggestions will close at the end of February. > > Fire away! > > Regards, > Carl-Daniel > > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyosti.malkki at gmail.com Fri Feb 20 06:30:15 2015 From: kyosti.malkki at gmail.com (=?ISO-8859-1?Q?Ky=F6sti_M=E4lkki?=) Date: Fri, 20 Feb 2015 07:30:15 +0200 Subject: [coreboot] Need help with MSI MS-7260 (K9N Neo) / MSI MS-7250 (K9N SLI) In-Reply-To: References: Message-ID: <54E6C667.6060603@gmail.com> On 02/19/2015 10:44 PM, cjn at post1.dansknet.dk wrote: > Hi, > > I'd like to run coreboot on my MSI MS-7250 (K9N SLI) mainboard. This > board is apparently quite similar to the MSI MS-7260 (K9N Neo) which is > already supported: > > http://www.coreboot.org/Board:msi/ms7260 > Hi I don't have experience with either of the boards. The log you attached suggests something is going wrong with cache coherency when doing MTRR setup. Seems like console spinlock no longer works as those printk() calls from different cores get interleaved. This problem may not be related to the exact board you have. Similarity does not mean it is easy to fix the remaining differences, the log seems fairly promising though. Ky?sti From kuzmichevviktorv at gmail.com Fri Feb 20 12:45:42 2015 From: kuzmichevviktorv at gmail.com (Kuzmichev Viktor) Date: Fri, 20 Feb 2015 14:45:42 +0300 Subject: [coreboot] Mohon Peak, Memtest86+ does not start In-Reply-To: <20150219152802.GB5265@morn.localdomain> References: <54BE5897.5010909@gmail.com> <20150120193318.GA24909@coreboot.org> <54C1FBFC.10806@gmail.com> <54C78BAF.30309@gmail.com> <20150219152802.GB5265@morn.localdomain> Message-ID: <54E71E66.3080103@gmail.com> Yes, Martin Roth mentioned earlier about SeaBIOS not supporting serial input. I've tried sgabios, but it looks like in order for it to work properly, I should disable all serial debug which is not very convenient. However, in one of my latest e-mails I suggested that SeaBIOS should not control serial input in memtest since memtest has its own code for serial input handling. And still, input via serial console does not work in memtest. Any idea why that's the case? -Viktor On 19.02.2015 18:28, Kevin O'Connor wrote: > On Tue, Jan 27, 2015 at 03:59:27PM +0300, Kuzmichev Viktor wrote: >> Thank you very much, this helped a lot! Now memtest is loading and it >> successfully performs RAM tests. >> But there is another issue. Somehow, input via serial console does not work. >> And it seems like the problem is not in memtest, rather it's in SeaBIOS or >> coreboot. There is no any prompt for input in coreboot. But there is in >> SeaBIOS, and I was not able to enter boot menu since it did not respond to >> F12. Although, SeaBIOS responds to the keyboard that is directly connected >> to the board while memtest does not seem to respond at all (at least, I >> tried to hit Esc which should reboot the board). >> I've tried to search for this but so far found nothing. >> Will appreciate any help. > I'm not sure if you found a solution to your issue. > > SeaBIOS only supports debug output on serial. For a serial console, > one can use sgabios with seabios - there is a description on how one > can do this at: http://www.coreboot.org/SeaBIOS#Adding_sgabios_support > > -Kevin From kevin at koconnor.net Fri Feb 20 14:27:49 2015 From: kevin at koconnor.net (Kevin O'Connor) Date: Fri, 20 Feb 2015 08:27:49 -0500 Subject: [coreboot] Mohon Peak, Memtest86+ does not start In-Reply-To: <54E71E66.3080103@gmail.com> References: <54BE5897.5010909@gmail.com> <20150120193318.GA24909@coreboot.org> <54C1FBFC.10806@gmail.com> <54C78BAF.30309@gmail.com> <20150219152802.GB5265@morn.localdomain> <54E71E66.3080103@gmail.com> Message-ID: <20150220132749.GA9694@morn.localdomain> On Fri, Feb 20, 2015 at 02:45:42PM +0300, Kuzmichev Viktor wrote: > Yes, Martin Roth mentioned earlier about SeaBIOS not supporting serial > input. > > I've tried sgabios, but it looks like in order for it to work properly, I > should disable all serial debug which is not very convenient. To prevent the duplicate messages from SeaBIOS, one can set the SeaBIOS debug level to 1 and set the "etc/screen-and-debug" setting as described at: http://www.coreboot.org/SeaBIOS#Adding_sgabios_support This wont prevent duplicates from grub, but if sgabios works properly then you may be able to disable grub serial. > However, in one of my latest e-mails I suggested that SeaBIOS should not > control serial input in memtest since memtest has its own code for serial > input handling. And still, input via serial console does not work in > memtest. Any idea why that's the case? I'm not familiar with memtest internals, so I can't help here. -Kevin From pgeorgi at google.com Fri Feb 20 17:30:13 2015 From: pgeorgi at google.com (Patrick Georgi) Date: Fri, 20 Feb 2015 17:30:13 +0100 Subject: [coreboot] New interface for I2C in coreboot In-Reply-To: <20150219201245.11133.qmail@stuge.se> References: <20150219201245.11133.qmail@stuge.se> Message-ID: 2015-02-19 21:12 GMT+01:00 Peter Stuge : >> I think the question is really what we would gain from this. > > I think it's less about performance and more about an accurate and > clean model being available to mainboard code when needed. >From discussing things with Werner, one of his concerns (as I understood them) was higher stability in light of picky I2C devices: When you schedule the entire communication in one pass, the (sufficiently capable) controller makes sure that things happen in the right order and at the right time. If some of that is arbitrated by CPU code, there's more room for error. Even for the I2C controllers that essentially bitbang things with no help by the controller chip, that should help avoid mistakes, since all the nasty warts of I2C (of which were seem to be many) are managed in the bus driver, not in every single slave driver. Patrick -- Google Germany GmbH ABC-Str. 19 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Gesch?ftsf?hrer: Graham Law, Christine Elizabeth Flores From werner.zeh at gmx.net Sat Feb 21 10:30:17 2015 From: werner.zeh at gmx.net (Werner Zeh) Date: Sat, 21 Feb 2015 10:30:17 +0100 Subject: [coreboot] New interface for I2C in coreboot In-Reply-To: References: <20150219201245.11133.qmail@stuge.se> Message-ID: <54E85029.5040300@gmx.net> Yes Patrick, you get me right. Why should we spread the work that can be commonly done by the I2C controller driver over several slave drivers. I was concerned of several issues on the I2C bus due to the following policy: I2C is a slow, low bandwidth bus, let us do the single transfers byte wise in the background task. This has two disadvantages: 1. If you have a serious bug and you have to look at the physical bus level to get a clue what is going on there, you have to capture a lot of time with an oscilloscope and your single transfers will be interrupted by huge gaps (because the transfers are spitted and other things happens in between). This makes it really hard to analyze. 2. There is a bigger chance to mess up the slave. If that is happen, you can get a hanging I2C bus. And in the worst case you will have to power-cycle your slave (and in the most cases your board as well) to get the slave in the working condition again. In my point of view, it is much better to keep transfers on I2C bus as close as possible together to avoid errors. Werner Am 20.02.2015 um 17:30 schrieb Patrick Georgi via coreboot: > 2015-02-19 21:12 GMT+01:00 Peter Stuge : >>> I think the question is really what we would gain from this. >> I think it's less about performance and more about an accurate and >> clean model being available to mainboard code when needed. > From discussing things with Werner, one of his concerns (as I > understood them) was higher stability in light of picky I2C devices: > When you schedule the entire communication in one pass, the > (sufficiently capable) controller makes sure that things happen in the > right order and at the right time. If some of that is arbitrated by > CPU code, there's more room for error. > > Even for the I2C controllers that essentially bitbang things with no > help by the controller chip, that should help avoid mistakes, since > all the nasty warts of I2C (of which were seem to be many) are managed > in the bus driver, not in every single slave driver. > > > Patrick From stefan.tauner at alumni.tuwien.ac.at Sun Feb 22 02:04:42 2015 From: stefan.tauner at alumni.tuwien.ac.at (Stefan Tauner) Date: Sun, 22 Feb 2015 02:04:42 +0100 Subject: [coreboot] New flashrom logo Message-ID: <201502220104.t1M14g36029085@mail2.student.tuwien.ac.at> Hello, we have used two logos in the past for flashrom. The one most are familiar with is actually a generic icon stemming from coreboot's "Related Tools" section, i.e.: http://www.coreboot.org/images/a/ae/Chip_tools.png This is not only set up as the "Mediawiki" icon on flashrom.org but is also used on our Twitter account and other sites like openhub (https://www.openhub.net/p/flashrom) The second logo was specifically designed for this purpose and was used at various occasions in presentation slides and on marketing materials (e.g. posters). Namely http://3.bp.blogspot.com/_PTt3TWYKjnQ/TI_oZ3cqvaI/AAAAAAAAALY/eLvM6K16Glw/s400/logo9white.png (the one described as "Different style of bolt" on http://kmacphail.blogspot.de/2010/09/flashrom-logos.html) I think that one is way lesser known since even I was not really aware about the fact that it kind of the "official" logo at the moment. I am not too happy with either. The hammer logo has grown dear to me... the hammer perfectly symbolizes the force we have to exert to get some systems to work and the logo as such is very recognizable. But... I only have it in very low quality... is there a better source for it? It also does not represent our generally gentle and cautious approach when dealing with hardware and our focus on stability. The DIP logo on the other hand is available in SVG (at least Carl-Daniel has it AFAIK), but it looks a bit inanimate. The major problems I have with it are that it is not even nearly rectangular and it is very complex. There is the text with the lightning bolt replacing the h character and the DIP32 chip. Both is ok for posters and other big displays but sucks for other uses where simple, rectangular icons are required. I have spent the last weekend with playing around with Blender and its freestyle renderer that is able to output SVG directly. I have managed to render a 3D model of a SOIC8 chip that way as a base for a possible new logo. It required some cleanup afterwards but it looks way better than everything I could draw by hand ;) I have made two logos that I think are worth sharing. They are quite similar and the only major difference is the orientation of the chip... I have created 3 versions of each: one fully colored, one with outlines only and a two-colored simple version (e.g. for PCB silkscreens). I have attached the Inkscape SVGs as well as 96 pixel-wide PNG exports. I have not decided on an appropriate license... probably something similar to how the coreboot hare is licensed. What do you think about my suggestions and the whole matter? I would love to see proposals for alternatives as well! -- Kind regards/Mit freundlichen Gr??en, Stefan Tauner -------------- next part -------------- A non-text attachment was scrubbed... Name: soic8_30degrees.png Type: image/png Size: 8421 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: soic8_30degrees.svg Type: image/svg+xml Size: 26966 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: soic8_straight.png Type: image/png Size: 5983 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: soic8_straight.svg Type: image/svg+xml Size: 19566 bytes Desc: not available URL: From peter at stuge.se Sun Feb 22 02:16:57 2015 From: peter at stuge.se (Peter Stuge) Date: Sun, 22 Feb 2015 02:16:57 +0100 Subject: [coreboot] New flashrom logo In-Reply-To: <201502220104.t1M14g36029085@mail2.student.tuwien.ac.at> References: <201502220104.t1M14g36029085@mail2.student.tuwien.ac.at> Message-ID: <20150222011657.19447.qmail@stuge.se> Stefan Tauner wrote: > What do you think about my suggestions and the whole matter? soic8_30degrees is really good. I would only suggest to perhaps rotate around the X axis a little bit, and to either make the lightning bolt smaller or perhaps just remove it, because the connection between lightning and memory chips isn't so obvious. //Peter From peter at stuge.se Sun Feb 22 02:26:19 2015 From: peter at stuge.se (Peter Stuge) Date: Sun, 22 Feb 2015 02:26:19 +0100 Subject: [coreboot] New flashrom logo In-Reply-To: <20150222011657.19447.qmail@stuge.se> References: <201502220104.t1M14g36029085@mail2.student.tuwien.ac.at> <20150222011657.19447.qmail@stuge.se> Message-ID: <20150222012619.20202.qmail@stuge.se> Peter Stuge wrote: > Stefan Tauner wrote: > > What do you think about my suggestions and the whole matter? > > soic8_30degrees is really good. I would only suggest to perhaps > rotate clockwise > around the X axis a little bit, to view the chip more from the side, rather than from above. //Peter From rminnich at gmail.com Sun Feb 22 02:39:46 2015 From: rminnich at gmail.com (ron minnich) Date: Sun, 22 Feb 2015 01:39:46 +0000 Subject: [coreboot] New flashrom logo References: <201502220104.t1M14g36029085@mail2.student.tuwien.ac.at> <20150222011657.19447.qmail@stuge.se> <20150222012619.20202.qmail@stuge.se> Message-ID: Wow, I love these, and I agree with peter's ideas too. This is great. On Sat Feb 21 2015 at 5:27:35 PM Peter Stuge wrote: > Peter Stuge wrote: > > Stefan Tauner wrote: > > > What do you think about my suggestions and the whole matter? > > > > soic8_30degrees is really good. I would only suggest to perhaps > > rotate > > clockwise > > > around the X axis a little bit, > > to view the chip more from the side, rather than from above. > > > //Peter > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.tauner at alumni.tuwien.ac.at Sun Feb 22 19:26:45 2015 From: stefan.tauner at alumni.tuwien.ac.at (Stefan Tauner) Date: Sun, 22 Feb 2015 19:26:45 +0100 Subject: [coreboot] New flashrom logo In-Reply-To: <20150222012619.20202.qmail@stuge.se> References: <201502220104.t1M14g36029085@mail2.student.tuwien.ac.at> <20150222011657.19447.qmail@stuge.se> <20150222012619.20202.qmail@stuge.se> Message-ID: <201502221826.t1MIQjS5007271@mail2.student.tuwien.ac.at> On Sun, 22 Feb 2015 02:26:19 +0100 Peter Stuge wrote: > Peter Stuge wrote: > > Stefan Tauner wrote: > > > What do you think about my suggestions and the whole matter? > > > > soic8_30degrees is really good. I would only suggest to perhaps > > rotate > > clockwise > > > around the X axis a little bit, > > to view the chip more from the side, rather than from above. I am not sure where your X axis and origin is, but I have rotated it 30? "back" around the Y axis now :) Is that what you meant? That makes the flash look a bit stupid and makes the whole thing way less recognizable IMHO. -- Kind regards/Mit freundlichen Gr??en, Stefan Tauner -------------- next part -------------- A non-text attachment was scrubbed... Name: soic8_30_30_degrees.png Type: image/png Size: 6933 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: soic8_30_30_degrees.svg Type: image/svg+xml Size: 7379 bytes Desc: not available URL: From stefan.tauner at alumni.tuwien.ac.at Sun Feb 22 19:40:09 2015 From: stefan.tauner at alumni.tuwien.ac.at (Stefan Tauner) Date: Sun, 22 Feb 2015 19:40:09 +0100 Subject: [coreboot] New flashrom logo In-Reply-To: <20150222011657.19447.qmail@stuge.se> References: <201502220104.t1M14g36029085@mail2.student.tuwien.ac.at> <20150222011657.19447.qmail@stuge.se> Message-ID: <201502221840.t1MIe9Zn023035@mail2.student.tuwien.ac.at> On Sun, 22 Feb 2015 02:16:57 +0100 Peter Stuge wrote: > either make the > lightning bolt smaller or perhaps just remove it, because the > connection between lightning and memory chips isn't so obvious. Removing it (without replacement) is not an option... that would make it simply a chip icon. That by no means qualifies as a good logo for a software project :) The logo's background idea does not have to be obvious (i.e. if one doesn't know it is related to flashrom, one does not necessarily need to derive that relationship), but it should be recognizable and clear once you know it to make the whole logo<->project relation memorable... and I really think that a flash and a rom/chip qualifies to represent flashrom in such a way :) -- Kind regards/Mit freundlichen Gr??en, Stefan Tauner From peter at stuge.se Mon Feb 23 00:50:46 2015 From: peter at stuge.se (Peter Stuge) Date: Mon, 23 Feb 2015 00:50:46 +0100 Subject: [coreboot] New flashrom logo In-Reply-To: <201502221826.t1MIQjS5007271@mail2.student.tuwien.ac.at> References: <201502220104.t1M14g36029085@mail2.student.tuwien.ac.at> <20150222011657.19447.qmail@stuge.se> <20150222012619.20202.qmail@stuge.se> <201502221826.t1MIQjS5007271@mail2.student.tuwien.ac.at> Message-ID: <20150222235046.27104.qmail@stuge.se> Stefan Tauner wrote: > > > soic8_30degrees is really good. I would only suggest to perhaps > > > rotate > > > > clockwise > > > > > around the X axis a little bit, > > > > to view the chip more from the side, rather than from above. > > I am not sure where your X axis and origin is, but I have rotated > it 30? "back" around the Y axis now :) Is that what you meant? I don't get the description but the result is as I meant. I agree that it is much less recognizable. Worth a shot. Maybe rotate a bit less. I think the flash chip looks "closer" now than when viewed from the top. Lightning bolt or not, and all the rotation, is all up to you. I just expressed some ideas. Kind regards //Peter From stefan.tauner at alumni.tuwien.ac.at Tue Feb 24 01:26:24 2015 From: stefan.tauner at alumni.tuwien.ac.at (Stefan Tauner) Date: Tue, 24 Feb 2015 01:26:24 +0100 Subject: [coreboot] New flashrom logo In-Reply-To: <20150222235046.27104.qmail@stuge.se> References: <201502220104.t1M14g36029085@mail2.student.tuwien.ac.at> <20150222011657.19447.qmail@stuge.se> <20150222012619.20202.qmail@stuge.se> <201502221826.t1MIQjS5007271@mail2.student.tuwien.ac.at> <20150222235046.27104.qmail@stuge.se> Message-ID: <201502240026.t1O0QOo5023263@mail2.student.tuwien.ac.at> On Mon, 23 Feb 2015 00:50:46 +0100 Peter Stuge wrote: > I don't get the description but the result is as I meant. I agree > that it is much less recognizable. Worth a shot. Maybe rotate a bit > less. logo with half of the rotation attached (15? instead of 30? backwards). -- Kind regards/Mit freundlichen Gr??en, Stefan Tauner -------------- next part -------------- A non-text attachment was scrubbed... Name: soic8_30_15_degrees.png Type: image/png Size: 12119 bytes Desc: not available URL: From peter at stuge.se Tue Feb 24 17:51:25 2015 From: peter at stuge.se (Peter Stuge) Date: Tue, 24 Feb 2015 17:51:25 +0100 Subject: [coreboot] New flashrom logo In-Reply-To: <201502240026.t1O0QOo5023263@mail2.student.tuwien.ac.at> References: <201502220104.t1M14g36029085@mail2.student.tuwien.ac.at> <20150222011657.19447.qmail@stuge.se> <20150222012619.20202.qmail@stuge.se> <201502221826.t1MIQjS5007271@mail2.student.tuwien.ac.at> <20150222235046.27104.qmail@stuge.se> <201502240026.t1O0QOo5023263@mail2.student.tuwien.ac.at> Message-ID: <20150224165125.24494.qmail@stuge.se> Stefan Tauner wrote: > logo with half of the rotation attached (15? instead of 30? backwards). I really like this one. Nice! //Peter From rminnich at gmail.com Tue Feb 24 18:17:27 2015 From: rminnich at gmail.com (ron minnich) Date: Tue, 24 Feb 2015 17:17:27 +0000 Subject: [coreboot] New flashrom logo References: <201502220104.t1M14g36029085@mail2.student.tuwien.ac.at> <20150222011657.19447.qmail@stuge.se> <20150222012619.20202.qmail@stuge.se> <201502221826.t1MIQjS5007271@mail2.student.tuwien.ac.at> <20150222235046.27104.qmail@stuge.se> <201502240026.t1O0QOo5023263@mail2.student.tuwien.ac.at> <20150224165125.24494.qmail@stuge.se> Message-ID: Very nice. I like the one on the left best. On Tue Feb 24 2015 at 8:52:26 AM Peter Stuge wrote: > Stefan Tauner wrote: > > logo with half of the rotation attached (15? instead of 30? backwards). > > I really like this one. Nice! > > > //Peter > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at stuge.se Tue Feb 24 18:51:38 2015 From: peter at stuge.se (Peter Stuge) Date: Tue, 24 Feb 2015 18:51:38 +0100 Subject: [coreboot] New flashrom logo In-Reply-To: References: <201502220104.t1M14g36029085@mail2.student.tuwien.ac.at> <20150222011657.19447.qmail@stuge.se> <20150222012619.20202.qmail@stuge.se> <201502221826.t1MIQjS5007271@mail2.student.tuwien.ac.at> <20150222235046.27104.qmail@stuge.se> <201502240026.t1O0QOo5023263@mail2.student.tuwien.ac.at> <20150224165125.24494.qmail@stuge.se> Message-ID: <20150224175138.29227.qmail@stuge.se> ron minnich wrote: > > > logo with half of the rotation attached (15? instead of 30? backwards). > > > > I really like this one. Nice! > > Very nice. I like the one on the left best. Same here. //Peter From c-d.hailfinger.devel.2006 at gmx.net Wed Feb 25 00:16:30 2015 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 25 Feb 2015 00:16:30 +0100 Subject: [coreboot] [flashrom] New flashrom logo In-Reply-To: <201502220104.t1M14g36029085@mail2.student.tuwien.ac.at> References: <201502220104.t1M14g36029085@mail2.student.tuwien.ac.at> Message-ID: <54ED064E.2020304@gmx.net> Hi, On 22.02.2015 02:04, Stefan Tauner wrote: > we have used two logos in the past for flashrom. The one most are > familiar with is actually a generic icon stemming from coreboot's > "Related Tools" section, i.e.: > http://www.coreboot.org/images/a/ae/Chip_tools.png > This is not only set up as the "Mediawiki" icon on flashrom.org but is > also used on our Twitter account and other sites like openhub > (https://www.openhub.net/p/flashrom) > > The second logo was specifically designed for this purpose and was used > at various occasions in presentation slides and on marketing materials > (e.g. posters). Namely > http://3.bp.blogspot.com/_PTt3TWYKjnQ/TI_oZ3cqvaI/AAAAAAAAALY/eLvM6K16Glw/s400/logo9white.png > (the one described as "Different style of bolt" on > http://kmacphail.blogspot.de/2010/09/flashrom-logos.html) > I think that one is way lesser known since even I was not really aware > about the fact that it kind of the "official" logo at the moment. That logo (with slight modifications) was used in all flyers, all presentations and at all booths since 2010. Please see the attachment for details. > I am not too happy with either. The hammer logo has grown dear to me... > the hammer perfectly symbolizes the force we have to exert to get some > systems to work and the logo as such is very recognizable. But... I > only have it in very low quality... is there a better source for it? > It also does not represent our generally gentle and cautious approach > when dealing with hardware and our focus on stability. To me, the hammer logo suggests "chip tool" in a general way, not something related to flash chips. Besides that, nowadays PLCC32 flash chips are almost extinct. > The DIP logo on the other hand is available in SVG (at least > Carl-Daniel has it AFAIK), but it looks a bit inanimate. The major > problems I have with it are that it is not even nearly rectangular and > it is very complex. There is the text with the lightning bolt replacing > the h character and the DIP32 chip. Both is ok for posters and other > big displays but sucks for other uses where simple, rectangular icons > are required. I don't really understand the requirement for a rectangular logo. "flashrom" is a long word and if we want to place that word below any logo, the logo will either need to be strechted out (like the one attached to this mail) or it will be a bit clumsy due to its blobby size. There is another question: Do we want a logo which can be used without the word "flashrom", and if so, should it still look good when the word "flashrom" is written below? > I have spent the last weekend with playing around with Blender and its > freestyle renderer that is able to output SVG directly. I have managed > to render a 3D model of a SOIC8 chip that way as a base for a possible > new logo. It required some cleanup afterwards but it looks way better > than everything I could draw by hand ;) The result looks nice, but I have trouble associating this with flashrom. The lightning bolt is a bit difficult to recognize as a lightning bolt. I do like that you used an 8-pin chip instead of a 32-pin chip. Looks more modern. > I have made two logos that I think are worth sharing. They are quite > similar and the only major difference is the orientation of the chip... > I have created 3 versions of each: one fully colored, one with outlines > only and a two-colored simple version (e.g. for PCB silkscreens). I > have attached the Inkscape SVGs as well as 96 pixel-wide PNG exports. I > have not decided on an appropriate license... probably something > similar to how the coreboot hare is licensed. > > What do you think about my suggestions and the whole matter? I would > love to see proposals for alternatives as well! I would like to keep the SVG logo used since 2010, perhaps paired with a simplified version of the logo which is small and simple enough for square icons. What do you think about having a DIP8 chip for icons and other space-constrained and detail-constrained applications? This would allow us to have two logos, each one for the purpose it fits best. There is also the question of whether we want a pure black-and-white logo like coreboot or if we'll go full/partial color. For posters, black-and-white vs. color is a matter of cost. Regards, Carl-Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: final_smallf.png Type: image/png Size: 21714 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: final_smallf.svg Type: image/svg+xml Size: 72510 bytes Desc: not available URL: From peter at stuge.se Wed Feb 25 03:38:01 2015 From: peter at stuge.se (Peter Stuge) Date: Wed, 25 Feb 2015 03:38:01 +0100 Subject: [coreboot] [flashrom] New flashrom logo In-Reply-To: <54ED064E.2020304@gmx.net> References: <201502220104.t1M14g36029085@mail2.student.tuwien.ac.at> <54ED064E.2020304@gmx.net> Message-ID: <20150225023801.4297.qmail@stuge.se> Carl-Daniel Hailfinger wrote: > two logos I'd recommend avoiding that. It becomes confusing for people. //Peter From paulepanter at users.sourceforge.net Thu Feb 26 01:24:45 2015 From: paulepanter at users.sourceforge.net (Paul Menzel) Date: Thu, 26 Feb 2015 01:24:45 +0100 Subject: [coreboot] Building ARM toolchain fails with `cc1: fatal error: .vis: No such file or directory` (was: Please advise: (new toolkit) crossgcc fails on ubuntu 32/64 bit fresh installs) In-Reply-To: References: Message-ID: <1424910285.6022.44.camel@users.sourceforge.net> Dear coreboot folks, Am Sonntag, den 08.09.2013, 15:27 +0100 schrieb Mark Mc: > Unfortunately it wont compile the rom without crossgcc compiling for both > platforms, my crossgcc-build.log ends with and appears to have no other > failures than: > > cc1: fatal error: .vis: No such file or directory > compilation terminated. > make[5]: *** [libunwind.o] Error 1 > make[4]: *** [multi-do] Error 1 > make[3]: *** [all-multi] Error 2 > make[2]: *** [all-target-libgcc] Error 2 > /usr/bin/install: cannot stat ?libgcc.a?: No such file or directory > make[3]: *** [install-leaf] Error 1 > make[2]: *** [install-target-libgcc] Error 2 trying to build the recommended toolchain for Google Rush, I am hitting the same problem in latest master at commit 6529c33a (build: mipsel cross compiler support). `make crossgcc-aarch64` succeeds, but `make crossgcc-arm` fails. $ make crossgcc-arm Warning: no suitable GCC for arm. Warning: no suitable GCC for arm64. Warning: no suitable GCC for riscv. Warning: no suitable GCC for mipsel. fatal: Repository '/home/paul/src/nvidia-cbootimage.git' existiert nicht. Klonen von '/home/paul/src/nvidia-cbootimage.git' in Submodul-Pfad 'util/nvidia/cbootimage' fehlgeschlagen Welcome to the coreboot cross toolchain builder v1.26 (February 23th, 2015) Target arch is now armv7-a-eabi Will skip GDB ... ok Downloading tar balls ... * gmp-5.1.2.tar.bz2 (downloading) * mpfr-3.1.2.tar.bz2 (downloading) * mpc-1.0.3.tar.gz (downloading) * libelf-0.8.13.tar.gz (downloading) * gcc-4.8.3.tar.bz2 (downloading) * binutils-2.23.2.tar.bz2 (downloading) * acpica-unix-20140114.tar.gz (downloading) Downloaded tar balls ... ok Unpacking and patching ... * gmp-5.1.2.tar.bz2 * mpfr-3.1.2.tar.bz2 * mpc-1.0.3.tar.gz * libelf-0.8.13.tar.gz * gcc-4.8.3.tar.bz2 * binutils-2.23.2.tar.bz2 o binutils-2.23.2_armv7a.patch o binutils-2.23.2_no-bfd-doc.patch * acpica-unix-20140114.tar.gz Unpacked and patched ... ok Building GMP 5.1.2 ... ok Building MPFR 3.1.2 ... ok Building MPC 1.0.3 ... ok Building libelf 0.8.13 ... ok Building binutils 2.23.2 ... ok Building GCC 4.8.3 ... failed Makefile:21: recipe for target 'build-armv7a-without-gdb' failed make[1]: *** [build-armv7a-without-gdb] Error 1 Makefile.inc:455: recipe for target 'crossgcc-arm' failed make: *** [crossgcc-arm] Error 2 Please find the log attached. I am using Debian Sid/unstable. $ more util/crossgcc/build-armv7-a-eabi-gcc/crossgcc-build.log configure.ac:34: error: Please use exactly Autoconf 2.64 instead of 2.69. config/override.m4:12: _GCC_AUTOCONF_VERSION_CHECK is expanded from... configure.ac:34: the top level [?] config.status: executing default commands Adding multilib support to Makefile in ../../../../gcc-4.8.3/libgcc with_multisubdir=fpu ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S: Assembler messages: ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S:351: use of r15 in bx in ARM mode is not really useful ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S: Assembler messages: ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S:351: use of r15 in bx in ARM mode is not really useful ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S: Assembler messages: ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S:351: use of r15 in bx in ARM mode is not really useful ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S: Assembler messages: ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S:351: use of r15 in bx in ARM mode is not really useful ../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:97:1: warning: no previous prototype for '__gnu_h2f_internal' [-Wmissing-prototypes] __gnu_h2f_internal(unsigned short a, int ieee) ^ ../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:122:1: warning: no previous prototype for '__gnu_f2h_ieee' [-Wmissing-prototypes] __gnu_f2h_ieee(unsigned int a) ^ ../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:128:1: warning: no previous prototype for '__gnu_h2f_ieee' [-Wmissing-prototypes] __gnu_h2f_ieee(unsigned short a) ^ ../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:134:1: warning: no previous prototype for '__gnu_f2h_alternative' [-Wmissing-prototypes] __gnu_f2h_alternative(unsigned int x) ^ ../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:140:1: warning: no previous prototype for '__gnu_h2f_alternative' [-Wmissing-prototypes] __gnu_h2f_alternative(unsigned short a) ^ In file included from ../../../../gcc-4.8.3/libgcc/config/arm/unwind-arm.c:143:0: ../../../../gcc-4.8.3/libgcc/unwind-arm-common.inc: In function 'get_eit_entry': ../../../../gcc-4.8.3/libgcc/unwind-arm-common.inc:245:29: warning: cast discards '__attribute__((const))' qualifier from pointer target type [-Wcast-qual] ucbp->pr_cache.ehtp = (_Unwind_EHT_Header *)&eitp->content; ^ cc1: fatal error: .vis: No such file or directory compilation terminated. ../../../../gcc-4.8.3/libgcc/static-object.mk:28: recipe for target 'libunwind.o' failed make[5]: *** [libunwind.o] Error 1 Makefile:1104: recipe for target 'multi-do' failed make[4]: *** [multi-do] Error 1 Makefile:113: recipe for target 'all-multi' failed make[3]: *** [all-multi] Error 2 Makefile:9962: recipe for target 'all-target-libgcc' failed make[2]: *** [all-target-libgcc] Error 2 /usr/bin/install: der Aufruf von stat f?r ?libgcc.a? ist nicht m?glich: Datei oder Verzeichnis nicht gefunden Makefile:1066: recipe for target 'install-leaf' failed make[3]: *** [install-leaf] Error 1 Makefile:10024: recipe for target 'install-target-libgcc' failed make[config.status: executing default commands Adding multilib support to Makefile in ../../../../gcc-4.8.3/libgcc with_multisubdir=fpu ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S: Assembler messages: ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S:351: use of r15 in bx in ARM mode is not really useful ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S: Assembler messages: ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S:351: use of r15 in bx in ARM mode is not really useful ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S: Assembler messages: ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S:351: use of r15 in bx in ARM mode is not really useful ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S: Assembler messages: ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S:351: use of r15 in bx in ARM mode is not really useful ../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:97:1: warning: no previous prototype for '__gnu_h2f_internal' [-Wmissing-prototypes] __gnu_h2f_internal(unsigned short a, int ieee) ^ ../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:122:1: warning: no previous prototype for '__gnu_f2h_ieee' [-Wmissing-prototypes] __gnu_f2h_ieee(unsigned int a) ^ ../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:128:1: warning: no previous prototype for '__gnu_h2f_ieee' [-Wmissing-prototypes] __gnu_h2f_ieee(unsigned short a) ^ ../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:134:1: warning: no previous prototype for '__gnu_f2h_alternative' [-Wmissing-prototypes] __gnu_f2h_alternative(unsigned int x) ^ ../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:140:1: warning: no previous prototype for '__gnu_h2f_alternative' [-Wmissing-prototypes] __gnu_h2f_alternative(unsigned short a) ^ In file included from ../../../../gcc-4.8.3/libgcc/config/arm/unwind-arm.c:143:0: ../../../../gcc-4.8.3/libgcc/unwind-arm-common.inc: In function 'get_eit_entry': ../../../../gcc-4.8.3/libgcc/unwind-arm-common.inc:245:29: warning: cast discards '__attribute__((const))' qualifier from pointer target type [-Wcast-qual] ucbp->pr_cache.ehtp = (_Unwind_EHT_Header *)&eitp->content; ^ cc1: fatal error: .vis: No such file or directory compilation terminated. ../../../../gcc-4.8.3/libgcc/static-object.mk:28: recipe for target 'libunwind.o' failed make[5]: *** [libunwind.o] Error 1 Makefile:1104: recipe for target 'multi-do' failed make[4]: *** [multi-do] Error 1 Makefile:113: recipe for target 'all-multi' failed make[3]: *** [all-multi] Error 2 Makefile:9962: recipe for target 'all-target-libgcc' failed make[2]: *** [all-target-libgcc] Error 2 /usr/bin/install: der Aufruf von stat f?r ?libgcc.a? ist nicht m?glich: Datei oder Verzeichnis nicht gefunden Makefile:1066: recipe for target 'install-leaf' failed make[3]: *** [install-leaf] Error 1 Makefile:10024: recipe for target 'install-target-libgcc' failed make[2]: *** [install-target-libgcc] Error 22]: *** [install-target-libgcc] Error 2 [?] Thanks, Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From paulepanter at users.sourceforge.net Thu Feb 26 02:04:52 2015 From: paulepanter at users.sourceforge.net (Paul Menzel) Date: Thu, 26 Feb 2015 02:04:52 +0100 Subject: [coreboot] Building ARM toolchain fails with `cc1: fatal error: .vis: No such file or directory` In-Reply-To: <1424910285.6022.44.camel@users.sourceforge.net> References: <1424910285.6022.44.camel@users.sourceforge.net> Message-ID: <1424912692.10507.1.camel@users.sourceforge.net> Dear coreboot folks, I forgot to attach the log file. Am Donnerstag, den 26.02.2015, 01:24 +0100 schrieb Paul Menzel: > Am Sonntag, den 08.09.2013, 15:27 +0100 schrieb Mark Mc: > > Unfortunately it wont compile the rom without crossgcc compiling for both > > platforms, my crossgcc-build.log ends with and appears to have no other > > failures than: > > > > cc1: fatal error: .vis: No such file or directory > > compilation terminated. > > make[5]: *** [libunwind.o] Error 1 > > make[4]: *** [multi-do] Error 1 > > make[3]: *** [all-multi] Error 2 > > make[2]: *** [all-target-libgcc] Error 2 > > /usr/bin/install: cannot stat ?libgcc.a?: No such file or directory > > make[3]: *** [install-leaf] Error 1 > > make[2]: *** [install-target-libgcc] Error 2 > > trying to build the recommended toolchain for Google Rush, I am hitting > the same problem in latest master at commit 6529c33a (build: mipsel > cross compiler support). > > `make crossgcc-aarch64` succeeds, but `make crossgcc-arm` fails. > > $ make crossgcc-arm > Warning: no suitable GCC for arm. > Warning: no suitable GCC for arm64. > Warning: no suitable GCC for riscv. > Warning: no suitable GCC for mipsel. > fatal: Repository '/home/paul/src/nvidia-cbootimage.git' existiert nicht. > Klonen von '/home/paul/src/nvidia-cbootimage.git' in Submodul-Pfad 'util/nvidia/cbootimage' fehlgeschlagen > Welcome to the coreboot cross toolchain builder v1.26 (February 23th, 2015) > > Target arch is now armv7-a-eabi > Will skip GDB ... ok > Downloading tar balls ... > * gmp-5.1.2.tar.bz2 (downloading) > * mpfr-3.1.2.tar.bz2 (downloading) > * mpc-1.0.3.tar.gz (downloading) > * libelf-0.8.13.tar.gz (downloading) > * gcc-4.8.3.tar.bz2 (downloading) > * binutils-2.23.2.tar.bz2 (downloading) > * acpica-unix-20140114.tar.gz (downloading) > Downloaded tar balls ... ok > Unpacking and patching ... > * gmp-5.1.2.tar.bz2 > * mpfr-3.1.2.tar.bz2 > * mpc-1.0.3.tar.gz > * libelf-0.8.13.tar.gz > * gcc-4.8.3.tar.bz2 > * binutils-2.23.2.tar.bz2 > o binutils-2.23.2_armv7a.patch > o binutils-2.23.2_no-bfd-doc.patch > * acpica-unix-20140114.tar.gz > Unpacked and patched ... ok > Building GMP 5.1.2 ... ok > Building MPFR 3.1.2 ... ok > Building MPC 1.0.3 ... ok > Building libelf 0.8.13 ... ok > Building binutils 2.23.2 ... ok > Building GCC 4.8.3 ... failed > Makefile:21: recipe for target 'build-armv7a-without-gdb' failed > make[1]: *** [build-armv7a-without-gdb] Error 1 > Makefile.inc:455: recipe for target 'crossgcc-arm' failed > make: *** [crossgcc-arm] Error 2 > > Please find the log attached. I am using Debian Sid/unstable. > > $ more util/crossgcc/build-armv7-a-eabi-gcc/crossgcc-build.log > configure.ac:34: error: Please use exactly Autoconf 2.64 instead of 2.69. > config/override.m4:12: _GCC_AUTOCONF_VERSION_CHECK is expanded from... > configure.ac:34: the top level > [?] > config.status: executing default commands > Adding multilib support to Makefile in ../../../../gcc-4.8.3/libgcc > with_multisubdir=fpu > ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S: Assembler messages: > ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S:351: use of r15 in bx in ARM mode is not really useful > ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S: Assembler messages: > ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S:351: use of r15 in bx in ARM mode is not really useful > ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S: Assembler messages: > ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S:351: use of r15 in bx in ARM mode is not really useful > ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S: Assembler messages: > ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S:351: use of r15 in bx in ARM mode is not really useful > ../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:97:1: warning: no previous prototype for '__gnu_h2f_internal' [-Wmissing-prototypes] > __gnu_h2f_internal(unsigned short a, int ieee) > ^ > ../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:122:1: warning: no previous prototype for '__gnu_f2h_ieee' [-Wmissing-prototypes] > __gnu_f2h_ieee(unsigned int a) > ^ > ../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:128:1: warning: no previous prototype for '__gnu_h2f_ieee' [-Wmissing-prototypes] > __gnu_h2f_ieee(unsigned short a) > ^ > ../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:134:1: warning: no previous prototype for '__gnu_f2h_alternative' [-Wmissing-prototypes] > __gnu_f2h_alternative(unsigned int x) > ^ > ../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:140:1: warning: no previous prototype for '__gnu_h2f_alternative' [-Wmissing-prototypes] > __gnu_h2f_alternative(unsigned short a) > ^ > In file included from ../../../../gcc-4.8.3/libgcc/config/arm/unwind-arm.c:143:0: > ../../../../gcc-4.8.3/libgcc/unwind-arm-common.inc: In function 'get_eit_entry': > ../../../../gcc-4.8.3/libgcc/unwind-arm-common.inc:245:29: warning: cast discards '__attribute__((const))' qualifier from pointer target type [-Wcast-qual] > ucbp->pr_cache.ehtp = (_Unwind_EHT_Header *)&eitp->content; > ^ > cc1: fatal error: .vis: No such file or directory > compilation terminated. > ../../../../gcc-4.8.3/libgcc/static-object.mk:28: recipe for target 'libunwind.o' failed > make[5]: *** [libunwind.o] Error 1 > Makefile:1104: recipe for target 'multi-do' failed > make[4]: *** [multi-do] Error 1 > Makefile:113: recipe for target 'all-multi' failed > make[3]: *** [all-multi] Error 2 > Makefile:9962: recipe for target 'all-target-libgcc' failed > make[2]: *** [all-target-libgcc] Error 2 > /usr/bin/install: der Aufruf von stat f?r ?libgcc.a? ist nicht m?glich: Datei oder Verzeichnis nicht gefunden > Makefile:1066: recipe for target 'install-leaf' failed > make[3]: *** [install-leaf] Error 1 > Makefile:10024: recipe for target 'install-target-libgcc' failed > make[config.status: executing default commands > Adding multilib support to Makefile in ../../../../gcc-4.8.3/libgcc > with_multisubdir=fpu > ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S: Assembler messages: > ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S:351: use of r15 in bx in ARM mode is not really useful > ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S: Assembler messages: > ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S:351: use of r15 in bx in ARM mode is not really useful > ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S: Assembler messages: > ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S:351: use of r15 in bx in ARM mode is not really useful > ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S: Assembler messages: > ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S:351: use of r15 in bx in ARM mode is not really useful > ../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:97:1: warning: no previous prototype for '__gnu_h2f_internal' [-Wmissing-prototypes] > __gnu_h2f_internal(unsigned short a, int ieee) > ^ > ../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:122:1: warning: no previous prototype for '__gnu_f2h_ieee' [-Wmissing-prototypes] > __gnu_f2h_ieee(unsigned int a) > ^ > ../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:128:1: warning: no previous prototype for '__gnu_h2f_ieee' [-Wmissing-prototypes] > __gnu_h2f_ieee(unsigned short a) > ^ > ../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:134:1: warning: no previous prototype for '__gnu_f2h_alternative' [-Wmissing-prototypes] > __gnu_f2h_alternative(unsigned int x) > ^ > ../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:140:1: warning: no previous prototype for '__gnu_h2f_alternative' [-Wmissing-prototypes] > __gnu_h2f_alternative(unsigned short a) > ^ > In file included from ../../../../gcc-4.8.3/libgcc/config/arm/unwind-arm.c:143:0: > ../../../../gcc-4.8.3/libgcc/unwind-arm-common.inc: In function 'get_eit_entry': > ../../../../gcc-4.8.3/libgcc/unwind-arm-common.inc:245:29: warning: cast discards '__attribute__((const))' qualifier from pointer target type [-Wcast-qual] > ucbp->pr_cache.ehtp = (_Unwind_EHT_Header *)&eitp->content; > ^ > cc1: fatal error: .vis: No such file or directory > compilation terminated. > ../../../../gcc-4.8.3/libgcc/static-object.mk:28: recipe for target 'libunwind.o' failed > make[5]: *** [libunwind.o] Error 1 > Makefile:1104: recipe for target 'multi-do' failed > make[4]: *** [multi-do] Error 1 > Makefile:113: recipe for target 'all-multi' failed > make[3]: *** [all-multi] Error 2 > Makefile:9962: recipe for target 'all-target-libgcc' failed > make[2]: *** [all-target-libgcc] Error 2 > /usr/bin/install: der Aufruf von stat f?r ?libgcc.a? ist nicht m?glich: Datei oder Verzeichnis nicht gefunden > Makefile:1066: recipe for target 'install-leaf' failed > make[3]: *** [install-leaf] Error 1 > Makefile:10024: recipe for target 'install-target-libgcc' failed > make[2]: *** [install-target-libgcc] Error 22]: *** [install-target-libgcc] Error 2 > > [?] > > > Thanks, > > Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log Type: text/x-log Size: 35425 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: config.status Type: application/x-shellscript Size: 35106 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: crossgcc-build.log Type: text/x-log Size: 140126 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From emilian.bold at gmail.com Thu Feb 26 16:23:04 2015 From: emilian.bold at gmail.com (Emilian Bold) Date: Thu, 26 Feb 2015 17:23:04 +0200 Subject: [coreboot] Coreboot reproducible builds Message-ID: Hello, I was trying to duplicate a coreboot build back in November and I noticed I couldn't get my ROM file to be identical to the one I found online. It seems that Coreboot doesn't have reproducible builds yet. Debian has been looking into this for a while https://wiki.debian.org/ReproducibleBuilds and I think Coreboot should adopt this concept. It seems like we are halfway there with INCLUDE_CONFIG_FILE but what I've noticed is that even if I extract the CONFIG_ values the build still needs some manual tweaking. Ideally we should record the tools used (crossgcc version, etc), the coreboot git revision id, the CONFIG_ values and the build info for the payloads (for the auto-downloaded SeaBIOS I think just the git revision id would be enough). If the timestamps and such are cleaned we should get a reproducible ROM. Is there anyone willing to help me with this (or already working on this)? --emi -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at stuge.se Thu Feb 26 16:34:48 2015 From: peter at stuge.se (Peter Stuge) Date: Thu, 26 Feb 2015 16:34:48 +0100 Subject: [coreboot] Coreboot reproducible builds In-Reply-To: References: Message-ID: <20150226153448.14135.qmail@stuge.se> Emilian Bold wrote: > It seems that Coreboot doesn't have reproducible builds yet. That is correct. > Ideally Yep. > Is there anyone willing to help me with this (or already working on this)? Yes, I am willing to help you review your patches when they are in Gerrit. //Peter From pgeorgi at google.com Thu Feb 26 17:10:51 2015 From: pgeorgi at google.com (Patrick Georgi) Date: Thu, 26 Feb 2015 17:10:51 +0100 Subject: [coreboot] Coreboot reproducible builds In-Reply-To: References: Message-ID: 2015-02-26 16:23 GMT+01:00 Emilian Bold : > It seems that Coreboot doesn't have reproducible builds yet. You're right, it doesn't. One of the major items is probably to replace the current build time stamps with something more reasonable. For example, the current commit's time stamp (unless the tree is dirty, in which reproducability is impossible). > I think Coreboot should adopt this concept. Patches accepted. > > It seems like we are halfway there with INCLUDE_CONFIG_FILE but what I've > noticed is that even if I extract the CONFIG_ values the build still needs > some manual tweaking. > > Ideally we should record the tools used (crossgcc version, etc), the We do. > coreboot git revision id, We do. > the CONFIG_ values and the build info for the We optionally do. > payloads (for the auto-downloaded SeaBIOS I think just the git revision id > would be enough). Payloads are more intricate. I'd stick with the coreboot parts, that is, a coreboot build without adding a payload is bit-identical. Then do the same for the payload (we can add meta-data to cbfs files or store payload information in a separate cbfs file). > Is there anyone willing to help me with this (or already working on this)? Like Peter I'm happy to review changesets on gerrit. Patrick -- Google Germany GmbH ABC-Str. 19 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Gesch?ftsf?hrer: Graham Law, Christine Elizabeth Flores From vbendeb at chromium.org Thu Feb 26 17:48:56 2015 From: vbendeb at chromium.org (Vadim Bendebury) Date: Thu, 26 Feb 2015 08:48:56 -0800 Subject: [coreboot] Coreboot reproducible builds In-Reply-To: References: Message-ID: On Thu, Feb 26, 2015 at 8:10 AM, Patrick Georgi via coreboot wrote: > 2015-02-26 16:23 GMT+01:00 Emilian Bold : >> It seems that Coreboot doesn't have reproducible builds yet. > You're right, it doesn't. One of the major items is probably to > replace the current build time stamps with something more reasonable. > For example, the current commit's time stamp (unless the tree is > dirty, in which reproducability is impossible). > There are two facets to this issue: - when an image needs to built from source, we want the binary to be the same. In case the tree is dirty we might include a hash of the tree diffs against the top SHA1, just a thought. - build always recompiles some files and relinks the image, even if there is not source code changes. Is this really necessary, shouldn't make just do nothing in case the source did not change? --vb >> I think Coreboot should adopt this concept. > Patches accepted. > >> >> It seems like we are halfway there with INCLUDE_CONFIG_FILE but what I've >> noticed is that even if I extract the CONFIG_ values the build still needs >> some manual tweaking. >> >> Ideally we should record the tools used (crossgcc version, etc), the > We do. > >> coreboot git revision id, > We do. > >> the CONFIG_ values and the build info for the > We optionally do. > >> payloads (for the auto-downloaded SeaBIOS I think just the git revision id >> would be enough). > Payloads are more intricate. I'd stick with the coreboot parts, that > is, a coreboot build without adding a payload is bit-identical. Then > do the same for the payload (we can add meta-data to cbfs files or > store payload information in a separate cbfs file). > >> Is there anyone willing to help me with this (or already working on this)? > Like Peter I'm happy to review changesets on gerrit. > > > Patrick > -- > Google Germany GmbH > ABC-Str. 19 > 20354 Hamburg > > Registergericht und -nummer: Hamburg, HRB 86891 > Sitz der Gesellschaft: Hamburg > Gesch?ftsf?hrer: Graham Law, Christine Elizabeth Flores > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot From adurbin at chromium.org Thu Feb 26 21:56:40 2015 From: adurbin at chromium.org (Aaron Durbin) Date: Thu, 26 Feb 2015 14:56:40 -0600 Subject: [coreboot] Building ARM toolchain fails with `cc1: fatal error: .vis: No such file or directory` In-Reply-To: <1424912692.10507.1.camel@users.sourceforge.net> References: <1424910285.6022.44.camel@users.sourceforge.net> <1424912692.10507.1.camel@users.sourceforge.net> Message-ID: I reproduced the error. I was trying to figure out how to debug it. I entered into the util/crossgcc/build-armv7-a-eabi-gcc directory and typed make. Everything worked... I'm trying again. I'm not really sure why one way would fail and the other not. On Wed, Feb 25, 2015 at 7:04 PM, Paul Menzel wrote: > Dear coreboot folks, > > > I forgot to attach the log file. > > > Am Donnerstag, den 26.02.2015, 01:24 +0100 schrieb Paul Menzel: > >> Am Sonntag, den 08.09.2013, 15:27 +0100 schrieb Mark Mc: >> > Unfortunately it wont compile the rom without crossgcc compiling for both >> > platforms, my crossgcc-build.log ends with and appears to have no other >> > failures than: >> > >> > cc1: fatal error: .vis: No such file or directory >> > compilation terminated. >> > make[5]: *** [libunwind.o] Error 1 >> > make[4]: *** [multi-do] Error 1 >> > make[3]: *** [all-multi] Error 2 >> > make[2]: *** [all-target-libgcc] Error 2 >> > /usr/bin/install: cannot stat ?libgcc.a?: No such file or directory >> > make[3]: *** [install-leaf] Error 1 >> > make[2]: *** [install-target-libgcc] Error 2 >> >> trying to build the recommended toolchain for Google Rush, I am hitting >> the same problem in latest master at commit 6529c33a (build: mipsel >> cross compiler support). >> >> `make crossgcc-aarch64` succeeds, but `make crossgcc-arm` fails. >> >> $ make crossgcc-arm >> Warning: no suitable GCC for arm. >> Warning: no suitable GCC for arm64. >> Warning: no suitable GCC for riscv. >> Warning: no suitable GCC for mipsel. >> fatal: Repository '/home/paul/src/nvidia-cbootimage.git' existiert nicht. >> Klonen von '/home/paul/src/nvidia-cbootimage.git' in Submodul-Pfad 'util/nvidia/cbootimage' fehlgeschlagen >> Welcome to the coreboot cross toolchain builder v1.26 (February 23th, 2015) >> >> Target arch is now armv7-a-eabi >> Will skip GDB ... ok >> Downloading tar balls ... >> * gmp-5.1.2.tar.bz2 (downloading) >> * mpfr-3.1.2.tar.bz2 (downloading) >> * mpc-1.0.3.tar.gz (downloading) >> * libelf-0.8.13.tar.gz (downloading) >> * gcc-4.8.3.tar.bz2 (downloading) >> * binutils-2.23.2.tar.bz2 (downloading) >> * acpica-unix-20140114.tar.gz (downloading) >> Downloaded tar balls ... ok >> Unpacking and patching ... >> * gmp-5.1.2.tar.bz2 >> * mpfr-3.1.2.tar.bz2 >> * mpc-1.0.3.tar.gz >> * libelf-0.8.13.tar.gz >> * gcc-4.8.3.tar.bz2 >> * binutils-2.23.2.tar.bz2 >> o binutils-2.23.2_armv7a.patch >> o binutils-2.23.2_no-bfd-doc.patch >> * acpica-unix-20140114.tar.gz >> Unpacked and patched ... ok >> Building GMP 5.1.2 ... ok >> Building MPFR 3.1.2 ... ok >> Building MPC 1.0.3 ... ok >> Building libelf 0.8.13 ... ok >> Building binutils 2.23.2 ... ok >> Building GCC 4.8.3 ... failed >> Makefile:21: recipe for target 'build-armv7a-without-gdb' failed >> make[1]: *** [build-armv7a-without-gdb] Error 1 >> Makefile.inc:455: recipe for target 'crossgcc-arm' failed >> make: *** [crossgcc-arm] Error 2 >> >> Please find the log attached. I am using Debian Sid/unstable. >> >> $ more util/crossgcc/build-armv7-a-eabi-gcc/crossgcc-build.log >> configure.ac:34: error: Please use exactly Autoconf 2.64 instead of 2.69. >> config/override.m4:12: _GCC_AUTOCONF_VERSION_CHECK is expanded from... >> configure.ac:34: the top level >> [?] >> config.status: executing default commands >> Adding multilib support to Makefile in ../../../../gcc-4.8.3/libgcc >> with_multisubdir=fpu >> ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S: Assembler messages: >> ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S:351: use of r15 in bx in ARM mode is not really useful >> ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S: Assembler messages: >> ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S:351: use of r15 in bx in ARM mode is not really useful >> ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S: Assembler messages: >> ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S:351: use of r15 in bx in ARM mode is not really useful >> ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S: Assembler messages: >> ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S:351: use of r15 in bx in ARM mode is not really useful >> ../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:97:1: warning: no previous prototype for '__gnu_h2f_internal' [-Wmissing-prototypes] >> __gnu_h2f_internal(unsigned short a, int ieee) >> ^ >> ../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:122:1: warning: no previous prototype for '__gnu_f2h_ieee' [-Wmissing-prototypes] >> __gnu_f2h_ieee(unsigned int a) >> ^ >> ../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:128:1: warning: no previous prototype for '__gnu_h2f_ieee' [-Wmissing-prototypes] >> __gnu_h2f_ieee(unsigned short a) >> ^ >> ../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:134:1: warning: no previous prototype for '__gnu_f2h_alternative' [-Wmissing-prototypes] >> __gnu_f2h_alternative(unsigned int x) >> ^ >> ../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:140:1: warning: no previous prototype for '__gnu_h2f_alternative' [-Wmissing-prototypes] >> __gnu_h2f_alternative(unsigned short a) >> ^ >> In file included from ../../../../gcc-4.8.3/libgcc/config/arm/unwind-arm.c:143:0: >> ../../../../gcc-4.8.3/libgcc/unwind-arm-common.inc: In function 'get_eit_entry': >> ../../../../gcc-4.8.3/libgcc/unwind-arm-common.inc:245:29: warning: cast discards '__attribute__((const))' qualifier from pointer target type [-Wcast-qual] >> ucbp->pr_cache.ehtp = (_Unwind_EHT_Header *)&eitp->content; >> ^ >> cc1: fatal error: .vis: No such file or directory >> compilation terminated. >> ../../../../gcc-4.8.3/libgcc/static-object.mk:28: recipe for target 'libunwind.o' failed >> make[5]: *** [libunwind.o] Error 1 >> Makefile:1104: recipe for target 'multi-do' failed >> make[4]: *** [multi-do] Error 1 >> Makefile:113: recipe for target 'all-multi' failed >> make[3]: *** [all-multi] Error 2 >> Makefile:9962: recipe for target 'all-target-libgcc' failed >> make[2]: *** [all-target-libgcc] Error 2 >> /usr/bin/install: der Aufruf von stat f?r ?libgcc.a? ist nicht m?glich: Datei oder Verzeichnis nicht gefunden >> Makefile:1066: recipe for target 'install-leaf' failed >> make[3]: *** [install-leaf] Error 1 >> Makefile:10024: recipe for target 'install-target-libgcc' failed >> make[config.status: executing default commands >> Adding multilib support to Makefile in ../../../../gcc-4.8.3/libgcc >> with_multisubdir=fpu >> ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S: Assembler messages: >> ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S:351: use of r15 in bx in ARM mode is not really useful >> ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S: Assembler messages: >> ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S:351: use of r15 in bx in ARM mode is not really useful >> ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S: Assembler messages: >> ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S:351: use of r15 in bx in ARM mode is not really useful >> ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S: Assembler messages: >> ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S:351: use of r15 in bx in ARM mode is not really useful >> ../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:97:1: warning: no previous prototype for '__gnu_h2f_internal' [-Wmissing-prototypes] >> __gnu_h2f_internal(unsigned short a, int ieee) >> ^ >> ../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:122:1: warning: no previous prototype for '__gnu_f2h_ieee' [-Wmissing-prototypes] >> __gnu_f2h_ieee(unsigned int a) >> ^ >> ../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:128:1: warning: no previous prototype for '__gnu_h2f_ieee' [-Wmissing-prototypes] >> __gnu_h2f_ieee(unsigned short a) >> ^ >> ../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:134:1: warning: no previous prototype for '__gnu_f2h_alternative' [-Wmissing-prototypes] >> __gnu_f2h_alternative(unsigned int x) >> ^ >> ../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:140:1: warning: no previous prototype for '__gnu_h2f_alternative' [-Wmissing-prototypes] >> __gnu_h2f_alternative(unsigned short a) >> ^ >> In file included from ../../../../gcc-4.8.3/libgcc/config/arm/unwind-arm.c:143:0: >> ../../../../gcc-4.8.3/libgcc/unwind-arm-common.inc: In function 'get_eit_entry': >> ../../../../gcc-4.8.3/libgcc/unwind-arm-common.inc:245:29: warning: cast discards '__attribute__((const))' qualifier from pointer target type [-Wcast-qual] >> ucbp->pr_cache.ehtp = (_Unwind_EHT_Header *)&eitp->content; >> ^ >> cc1: fatal error: .vis: No such file or directory >> compilation terminated. >> ../../../../gcc-4.8.3/libgcc/static-object.mk:28: recipe for target 'libunwind.o' failed >> make[5]: *** [libunwind.o] Error 1 >> Makefile:1104: recipe for target 'multi-do' failed >> make[4]: *** [multi-do] Error 1 >> Makefile:113: recipe for target 'all-multi' failed >> make[3]: *** [all-multi] Error 2 >> Makefile:9962: recipe for target 'all-target-libgcc' failed >> make[2]: *** [all-target-libgcc] Error 2 >> /usr/bin/install: der Aufruf von stat f?r ?libgcc.a? ist nicht m?glich: Datei oder Verzeichnis nicht gefunden >> Makefile:1066: recipe for target 'install-leaf' failed >> make[3]: *** [install-leaf] Error 1 >> Makefile:10024: recipe for target 'install-target-libgcc' failed >> make[2]: *** [install-target-libgcc] Error 22]: *** [install-target-libgcc] Error 2 >> >> [?] >> >> >> Thanks, >> >> Paul > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot From pgeorgi at google.com Thu Feb 26 22:15:07 2015 From: pgeorgi at google.com (Patrick Georgi) Date: Thu, 26 Feb 2015 22:15:07 +0100 Subject: [coreboot] Building ARM toolchain fails with `cc1: fatal error: .vis: No such file or directory` In-Reply-To: References: <1424910285.6022.44.camel@users.sourceforge.net> <1424912692.10507.1.camel@users.sourceforge.net> Message-ID: 2015-02-26 21:56 GMT+01:00 Aaron Durbin : > I reproduced the error. I was trying to figure out how to debug it. I > entered into the util/crossgcc/build-armv7-a-eabi-gcc directory and > typed make. Everything worked... I'm trying again. I'm not really sure > why one way would fail and the other not. Interesting. Paul, could you try executing buildgcc manually (not through a make rule)? If that works, there's some make environment stuff that survives and breaks things. Patrick -- Google Germany GmbH ABC-Str. 19 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Gesch?ftsf?hrer: Graham Law, Christine Elizabeth Flores From kevin.herbert at meraki.net Thu Feb 26 19:56:01 2015 From: kevin.herbert at meraki.net (Kevin Paul Herbert) Date: Thu, 26 Feb 2015 10:56:01 -0800 Subject: [coreboot] Building ARM toolchain fails with `cc1: fatal error: .vis: No such file or directory` In-Reply-To: <1424912692.10507.1.camel@users.sourceforge.net> References: <1424910285.6022.44.camel@users.sourceforge.net> <1424912692.10507.1.camel@users.sourceforge.net> Message-ID: <8CE224A5-20F2-471E-B1B8-A65BD0ABFD65@meraki.net> I have the same issue building ARM compilers for my board. I wasn't able to figure out the cause, so I reverted to 4.7.3. I tried 4.9.2 as well, and it failed in the same way. I am suspicious of gnu make as the cause. There is a pattern match base rule that is written as -include $*.vis - $* is null, so the compiler tries to include .vis, which obviously doesn't exist. I had another issue building on ARM as well - my board does not use verstage but builds without verstage fail right now. I have a patch for this - I'll submit it later today. Kevin > On Feb 25, 2015, at 17:04, Paul Menzel wrote: > > Dear coreboot folks, > > > I forgot to attach the log file. > > > Am Donnerstag, den 26.02.2015, 01:24 +0100 schrieb Paul Menzel: > >> Am Sonntag, den 08.09.2013, 15:27 +0100 schrieb Mark Mc: >>> Unfortunately it wont compile the rom without crossgcc compiling for both >>> platforms, my crossgcc-build.log ends with and appears to have no other >>> failures than: >>> >>> cc1: fatal error: .vis: No such file or directory >>> compilation terminated. >>> make[5]: *** [libunwind.o] Error 1 >>> make[4]: *** [multi-do] Error 1 >>> make[3]: *** [all-multi] Error 2 >>> make[2]: *** [all-target-libgcc] Error 2 >>> /usr/bin/install: cannot stat ?libgcc.a?: No such file or directory >>> make[3]: *** [install-leaf] Error 1 >>> make[2]: *** [install-target-libgcc] Error 2 >> >> trying to build the recommended toolchain for Google Rush, I am hitting >> the same problem in latest master at commit 6529c33a (build: mipsel >> cross compiler support). >> >> `make crossgcc-aarch64` succeeds, but `make crossgcc-arm` fails. >> >> $ make crossgcc-arm >> Warning: no suitable GCC for arm. >> Warning: no suitable GCC for arm64. >> Warning: no suitable GCC for riscv. >> Warning: no suitable GCC for mipsel. >> fatal: Repository '/home/paul/src/nvidia-cbootimage.git' existiert nicht. >> Klonen von '/home/paul/src/nvidia-cbootimage.git' in Submodul-Pfad 'util/nvidia/cbootimage' fehlgeschlagen >> Welcome to the coreboot cross toolchain builder v1.26 (February 23th, 2015) >> >> Target arch is now armv7-a-eabi >> Will skip GDB ... ok >> Downloading tar balls ... >> * gmp-5.1.2.tar.bz2 (downloading) >> * mpfr-3.1.2.tar.bz2 (downloading) >> * mpc-1.0.3.tar.gz (downloading) >> * libelf-0.8.13.tar.gz (downloading) >> * gcc-4.8.3.tar.bz2 (downloading) >> * binutils-2.23.2.tar.bz2 (downloading) >> * acpica-unix-20140114.tar.gz (downloading) >> Downloaded tar balls ... ok >> Unpacking and patching ... >> * gmp-5.1.2.tar.bz2 >> * mpfr-3.1.2.tar.bz2 >> * mpc-1.0.3.tar.gz >> * libelf-0.8.13.tar.gz >> * gcc-4.8.3.tar.bz2 >> * binutils-2.23.2.tar.bz2 >> o binutils-2.23.2_armv7a.patch >> o binutils-2.23.2_no-bfd-doc.patch >> * acpica-unix-20140114.tar.gz >> Unpacked and patched ... ok >> Building GMP 5.1.2 ... ok >> Building MPFR 3.1.2 ... ok >> Building MPC 1.0.3 ... ok >> Building libelf 0.8.13 ... ok >> Building binutils 2.23.2 ... ok >> Building GCC 4.8.3 ... failed >> Makefile:21: recipe for target 'build-armv7a-without-gdb' failed >> make[1]: *** [build-armv7a-without-gdb] Error 1 >> Makefile.inc:455: recipe for target 'crossgcc-arm' failed >> make: *** [crossgcc-arm] Error 2 >> >> Please find the log attached. I am using Debian Sid/unstable. >> >> $ more util/crossgcc/build-armv7-a-eabi-gcc/crossgcc-build.log >> configure.ac:34: error: Please use exactly Autoconf 2.64 instead of 2.69. >> config/override.m4:12: _GCC_AUTOCONF_VERSION_CHECK is expanded from... >> configure.ac:34: the top level >> [?] >> config.status: executing default commands >> Adding multilib support to Makefile in ../../../../gcc-4.8.3/libgcc >> with_multisubdir=fpu >> ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S: Assembler messages: >> ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S:351: use of r15 in bx in ARM mode is not really useful >> ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S: Assembler messages: >> ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S:351: use of r15 in bx in ARM mode is not really useful >> ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S: Assembler messages: >> ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S:351: use of r15 in bx in ARM mode is not really useful >> ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S: Assembler messages: >> ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S:351: use of r15 in bx in ARM mode is not really useful >> ../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:97:1: warning: no previous prototype for '__gnu_h2f_internal' [-Wmissing-prototypes] >> __gnu_h2f_internal(unsigned short a, int ieee) >> ^ >> ../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:122:1: warning: no previous prototype for '__gnu_f2h_ieee' [-Wmissing-prototypes] >> __gnu_f2h_ieee(unsigned int a) >> ^ >> ../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:128:1: warning: no previous prototype for '__gnu_h2f_ieee' [-Wmissing-prototypes] >> __gnu_h2f_ieee(unsigned short a) >> ^ >> ../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:134:1: warning: no previous prototype for '__gnu_f2h_alternative' [-Wmissing-prototypes] >> __gnu_f2h_alternative(unsigned int x) >> ^ >> ../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:140:1: warning: no previous prototype for '__gnu_h2f_alternative' [-Wmissing-prototypes] >> __gnu_h2f_alternative(unsigned short a) >> ^ >> In file included from ../../../../gcc-4.8.3/libgcc/config/arm/unwind-arm.c:143:0: >> ../../../../gcc-4.8.3/libgcc/unwind-arm-common.inc: In function 'get_eit_entry': >> ../../../../gcc-4.8.3/libgcc/unwind-arm-common.inc:245:29: warning: cast discards '__attribute__((const))' qualifier from pointer target type [-Wcast-qual] >> ucbp->pr_cache.ehtp = (_Unwind_EHT_Header *)&eitp->content; >> ^ >> cc1: fatal error: .vis: No such file or directory >> compilation terminated. >> ../../../../gcc-4.8.3/libgcc/static-object.mk:28: recipe for target 'libunwind.o' failed >> make[5]: *** [libunwind.o] Error 1 >> Makefile:1104: recipe for target 'multi-do' failed >> make[4]: *** [multi-do] Error 1 >> Makefile:113: recipe for target 'all-multi' failed >> make[3]: *** [all-multi] Error 2 >> Makefile:9962: recipe for target 'all-target-libgcc' failed >> make[2]: *** [all-target-libgcc] Error 2 >> /usr/bin/install: der Aufruf von stat f?r ?libgcc.a? ist nicht m?glich: Datei oder Verzeichnis nicht gefunden >> Makefile:1066: recipe for target 'install-leaf' failed >> make[3]: *** [install-leaf] Error 1 >> Makefile:10024: recipe for target 'install-target-libgcc' failed >> make[config.status: executing default commands >> Adding multilib support to Makefile in ../../../../gcc-4.8.3/libgcc >> with_multisubdir=fpu >> ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S: Assembler messages: >> ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S:351: use of r15 in bx in ARM mode is not really useful >> ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S: Assembler messages: >> ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S:351: use of r15 in bx in ARM mode is not really useful >> ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S: Assembler messages: >> ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S:351: use of r15 in bx in ARM mode is not really useful >> ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S: Assembler messages: >> ../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S:351: use of r15 in bx in ARM mode is not really useful >> ../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:97:1: warning: no previous prototype for '__gnu_h2f_internal' [-Wmissing-prototypes] >> __gnu_h2f_internal(unsigned short a, int ieee) >> ^ >> ../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:122:1: warning: no previous prototype for '__gnu_f2h_ieee' [-Wmissing-prototypes] >> __gnu_f2h_ieee(unsigned int a) >> ^ >> ../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:128:1: warning: no previous prototype for '__gnu_h2f_ieee' [-Wmissing-prototypes] >> __gnu_h2f_ieee(unsigned short a) >> ^ >> ../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:134:1: warning: no previous prototype for '__gnu_f2h_alternative' [-Wmissing-prototypes] >> __gnu_f2h_alternative(unsigned int x) >> ^ >> ../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:140:1: warning: no previous prototype for '__gnu_h2f_alternative' [-Wmissing-prototypes] >> __gnu_h2f_alternative(unsigned short a) >> ^ >> In file included from ../../../../gcc-4.8.3/libgcc/config/arm/unwind-arm.c:143:0: >> ../../../../gcc-4.8.3/libgcc/unwind-arm-common.inc: In function 'get_eit_entry': >> ../../../../gcc-4.8.3/libgcc/unwind-arm-common.inc:245:29: warning: cast discards '__attribute__((const))' qualifier from pointer target type [-Wcast-qual] >> ucbp->pr_cache.ehtp = (_Unwind_EHT_Header *)&eitp->content; >> ^ >> cc1: fatal error: .vis: No such file or directory >> compilation terminated. >> ../../../../gcc-4.8.3/libgcc/static-object.mk:28: recipe for target 'libunwind.o' failed >> make[5]: *** [libunwind.o] Error 1 >> Makefile:1104: recipe for target 'multi-do' failed >> make[4]: *** [multi-do] Error 1 >> Makefile:113: recipe for target 'all-multi' failed >> make[3]: *** [all-multi] Error 2 >> Makefile:9962: recipe for target 'all-target-libgcc' failed >> make[2]: *** [all-target-libgcc] Error 2 >> /usr/bin/install: der Aufruf von stat f?r ?libgcc.a? ist nicht m?glich: Datei oder Verzeichnis nicht gefunden >> Makefile:1066: recipe for target 'install-leaf' failed >> make[3]: *** [install-leaf] Error 1 >> Makefile:10024: recipe for target 'install-target-libgcc' failed >> make[2]: *** [install-target-libgcc] Error 22]: *** [install-target-libgcc] Error 2 >> >> [?] >> >> >> Thanks, >> >> Paul > > > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot From c-d.hailfinger.devel.2006 at gmx.net Fri Feb 27 12:20:46 2015 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 27 Feb 2015 12:20:46 +0100 Subject: [coreboot] Automated test system: Nominations wanted In-Reply-To: <54E51CE7.5070801@gmx.net> References: <54E51CE7.5070801@gmx.net> Message-ID: <54F0530E.6070709@gmx.net> This is a friendly reminder. 2 days left for nominations of systems. On 19.02.2015 00:14, Carl-Daniel Hailfinger wrote: > The selection of target systems should include: > 1. at least one x86 laptop without an active ME (present but inactive > would be OK) > 2. at least one x86 laptop which can boot x86-blob-free (except microcode) > 3. at least one x86 board or laptop which needs neither blobs (except > microcode) nor ME > 4. at least one x86 board with reasonable (past or present) business > market penetration > 5. if the first two laptops use the same CPU vendor, a board using a > different x86 CPU vendor > [...] > Please nominate machines (e.g. "Thinkpad T60 with Intel graphics") and > tell me to which category they belong. If a system fits into multiple > categories, please specify that as well. > I will try to consolidate the recommendations and buy those machines. > Once the system is up and running (hopefully in May), I will add more > machines suggested by the community as time permits. > > The time window for suggestions will close at the end of February. So far I got the following nominations: - asus f2a85-m (desktop board) - tyan s8226 and/or supermicro h8scm and/or supermicro h8qgi (server board) - Qemu and a couple of the boards supported by SimNOW (no category) - Thinkpad T60 with ATI graphics (no ME, but with graphics blob) I can't find the suggestions on IRC anymore (searching in the scrollback buffer is harder than I thought), so if you still remember which boards/machines were proposed on IRC, please send an email listing them. Thanks, Carl-Daniel From scan-admin at coverity.com Fri Feb 27 23:51:49 2015 From: scan-admin at coverity.com (scan-admin at coverity.com) Date: Fri, 27 Feb 2015 14:51:49 -0800 Subject: [coreboot] New Defects reported by Coverity Scan for coreboot Message-ID: <54f0f505ebd70_71a425338264e4@scan.coverity.com.mail> Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 3 new defect(s) introduced to coreboot found with Coverity Scan. 10 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 3 of 3 defect(s) ** CID 1271711: (DEADCODE) /src/include/device/hypertransport_def.h: 25 in offset_unit_id() /src/include/device/hypertransport_def.h: 25 in offset_unit_id() ________________________________________________________________________________________________________ *** CID 1271711: (DEADCODE) /src/include/device/hypertransport_def.h: 25 in offset_unit_id() 19 #define HT_FREQ_VENDOR 15 /* AMD defines this to be 100Mhz */ 20 21 22 static inline bool offset_unit_id(bool is_sb_ht_chain) 23 { 24 bool need_offset = (CONFIG_HT_CHAIN_UNITID_BASE != 1) || (CONFIG_HT_CHAIN_END_UNITID_BASE != 0x20); >>> CID 1271711: (DEADCODE) >>> Execution cannot reach the expression "0" inside this statement: "return need_offset && (0 ||...". 25 return need_offset && (!CONFIG_SB_HT_CHAIN_UNITID_OFFSET_ONLY || is_sb_ht_chain); 26 } 27 /src/include/device/hypertransport_def.h: 25 in offset_unit_id() 19 #define HT_FREQ_VENDOR 15 /* AMD defines this to be 100Mhz */ 20 21 22 static inline bool offset_unit_id(bool is_sb_ht_chain) 23 { 24 bool need_offset = (CONFIG_HT_CHAIN_UNITID_BASE != 1) || (CONFIG_HT_CHAIN_END_UNITID_BASE != 0x20); >>> CID 1271711: (DEADCODE) >>> Execution cannot reach the expression "1" inside this statement: "return need_offset && (1 ||...". 25 return need_offset && (!CONFIG_SB_HT_CHAIN_UNITID_OFFSET_ONLY || is_sb_ht_chain); 26 } 27 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://scan.coverity.com/projects/1016?tab=overview To manage Coverity Scan email notifications for "coreboot at coreboot.org", click https://scan.coverity.com/subscriptions/edit?email=coreboot%40coreboot.org&token=8ddd1fe26945626880b796e94d465567 . From paulepanter at users.sourceforge.net Sat Feb 28 00:47:46 2015 From: paulepanter at users.sourceforge.net (Paul Menzel) Date: Sat, 28 Feb 2015 00:47:46 +0100 Subject: [coreboot] Building ARM toolchain fails with `cc1: fatal error: .vis: No such file or directory` In-Reply-To: References: <1424910285.6022.44.camel@users.sourceforge.net> <1424912692.10507.1.camel@users.sourceforge.net> Message-ID: <1425080866.6672.82.camel@users.sourceforge.net> Am Donnerstag, den 26.02.2015, 22:15 +0100 schrieb Patrick Georgi: > 2015-02-26 21:56 GMT+01:00 Aaron Durbin : > > I reproduced the error. I was trying to figure out how to debug it. I > > entered into the util/crossgcc/build-armv7-a-eabi-gcc directory and > > typed make. Everything worked... I'm trying again. I'm not really sure > > why one way would fail and the other not. > > Interesting. > > Paul, could you try executing buildgcc manually (not through a make rule)? Just for the archive, running `./buildgcc -G -p armv7a-eabi` worked. > If that works, there's some make environment stuff that survives and > breaks things. Thank you for providing a patch [1]! I?ll test that tomorrow. Thanks, Paul [1] http://review.coreboot.org/8545 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From stefan.tauner at alumni.tuwien.ac.at Sat Feb 28 01:34:16 2015 From: stefan.tauner at alumni.tuwien.ac.at (Stefan Tauner) Date: Sat, 28 Feb 2015 01:34:16 +0100 Subject: [coreboot] [flashrom] New flashrom logo In-Reply-To: <20150225023801.4297.qmail@stuge.se> References: <201502220104.t1M14g36029085@mail2.student.tuwien.ac.at> <54ED064E.2020304@gmx.net> <20150225023801.4297.qmail@stuge.se> Message-ID: <201502280034.t1S0YGLq006863@mail2.student.tuwien.ac.at> On Wed, 25 Feb 2015 03:38:01 +0100 Peter Stuge wrote: > Carl-Daniel Hailfinger wrote: > > two logos > > I'd recommend avoiding that. It becomes confusing for people. Not necessarily... the facebook "f" or linkedin "in" are examples where parts of the lettering are reused in icons. Based on that idea I have created a lettering containing the SOIC chip and bolt. I doubt this would produce any confusion :) -- Kind regards/Mit freundlichen Gr??en, Stefan Tauner -------------- next part -------------- A non-text attachment was scrubbed... Name: lettering_chip_slanted.png Type: image/png Size: 38170 bytes Desc: not available URL: From jwerner at chromium.org Sat Feb 28 10:12:23 2015 From: jwerner at chromium.org (Julius Werner) Date: Sat, 28 Feb 2015 01:12:23 -0800 Subject: [coreboot] Unifying IO accessor macros In-Reply-To: References: <3180601.Vry57uOoJv@nukelap.gtech> <8710381.Gsar9oJxnB@nukelap.gtech> Message-ID: Okay, the doodle has been up for a while now and it seems that write32(address, value) is preferred by a clear majority of people. I've prepared a set of patches starting at https://chromium-review.googlesource.com/#/c/254862 to enact that change in the Chromium repo. As mentioned before, I think due to the fact that there's much more active ARM(64) development going on in Chromium right now I should only land it there for the time being and wait until it naturally bubbles up to mainline coreboot as part of the current upstreaming effort... trying to apply it to both trees at once would just require a lot of pointless conflict resolution effort to down the road. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.tauner at alumni.tuwien.ac.at Sat Feb 28 22:59:49 2015 From: stefan.tauner at alumni.tuwien.ac.at (Stefan Tauner) Date: Sat, 28 Feb 2015 22:59:49 +0100 Subject: [coreboot] [flashrom] New flashrom logo - please vote! In-Reply-To: <201502280034.t1S0YGLq006863@mail2.student.tuwien.ac.at> References: <201502220104.t1M14g36029085@mail2.student.tuwien.ac.at> <54ED064E.2020304@gmx.net> <20150225023801.4297.qmail@stuge.se> <201502280034.t1S0YGLq006863@mail2.student.tuwien.ac.at> Message-ID: <201502282159.t1SLxoMp004027@mail2.student.tuwien.ac.at> Hi, I have put most of my creations online together with some of the (old) alternatives and created a poll that should help finding the most popular ones. Please vote only once (the site will not try to inhibit multiple votes). http://epicdecide.com/bac504d1-0061-46c4-ac7c-9beecaba87e0/ The images are shown in random order which makes it a bit hard to compare similar ones... just follow your gut feeling or look at them more closely here: http://buildbot.flashrom.org/poll/ You can enter a name at the bottom which I would appreciate. (I can only see the name not how anybody has voted). Any additional comments are very much welcomed! If you think all of them are crap and you have some better ideas I'd like to hear them too :) -- Kind regards/Mit freundlichen Gr??en, Stefan Tauner