Hello all,
I have new CPU opteron 175 - sigle cpu dualcore, I'm not able to initialize AP properly. http://assembler.cz/download/minicom_dc.txt
It seems I can boot them, but they never arrive to check point.
Any idea what might be wrong? Also I don't know why my core1 have APIC ID 0x11 instead of APIC ID 0x1...
Any help very appreciated.
Thanks,
Rudolf
On 10/22/07, Rudolf Marek r.marek@assembler.cz wrote:
Hello all,
I have new CPU opteron 175 - sigle cpu dualcore, I'm not able to initialize AP properly. http://assembler.cz/download/minicom_dc.txt
It seems I can boot them, but they never arrive to check point.
Any idea what might be wrong? Also I don't know why my core1 have APIC ID 0x11 instead of APIC ID 0x1...
in your MB Config.lb
default ENABLE_APIC_EXT_ID=1 default APIC_ID_OFFSET=0x10 default LIFT_BSP_APIC_ID=0
==>
default ENABLE_APIC_EXT_ID=0 default APIC_ID_OFFSET=0x10 default LIFT_BSP_APIC_ID=0
YH
Hello,
default ENABLE_APIC_EXT_ID=0 default APIC_ID_OFFSET=0x10 default LIFT_BSP_APIC_ID=0
Thanks, it helped a bit. Now I have APIC ID 0x1 as I expected. But still same trouble :/
Rudolf
On 10/23/07, Rudolf Marek r.marek@assembler.cz wrote:
Hello,
default ENABLE_APIC_EXT_ID=0 default APIC_ID_OFFSET=0x10 default LIFT_BSP_APIC_ID=0
Thanks, it helped a bit. Now I have APIC ID 0x1 as I expected. But still same trouble :/
new boot log with log level = 8?
YH
yhlu wrote:
On 10/23/07, Rudolf Marek r.marek@assembler.cz wrote:
Hello,
default ENABLE_APIC_EXT_ID=0 default APIC_ID_OFFSET=0x10 default LIFT_BSP_APIC_ID=0
Thanks, it helped a bit. Now I have APIC ID 0x1 as I expected. But still same trouble :/
new boot log with log level = 8?
Ok will do that in the evening. Now I'm away from that computer.
Rudolf
Rudolf Marek wrote:
yhlu wrote:
On 10/23/07, Rudolf Marek r.marek@assembler.cz wrote:
Hello,
default ENABLE_APIC_EXT_ID=0 default APIC_ID_OFFSET=0x10 default LIFT_BSP_APIC_ID=0
Thanks, it helped a bit. Now I have APIC ID 0x1 as I expected. But still same trouble :/
new boot log with log level = 8?
Ok will do that in the evening. Now I'm away from that computer.
Rudolf
Rudolf,
Check CONFIG_LOGICAL_CPUS=1 is set. I think that is the flag for intializing aditional cores on each CPU.
Marc
Hi all,
new boot log with log level = 8?
http://assembler.cz/download/dc3.txt
Check CONFIG_LOGICAL_CPUS=1 is set. I think that is the flag for intializing aditional cores on each CPU.
Yes it is correct, rest CPU related looks like this:
default CONFIG_SMP=1 default CONFIG_MAX_CPUS=2 default CONFIG_MAX_PHYSICAL_CPUS=1 default CONFIG_LOGICAL_CPUS=1 default ENABLE_APIC_EXT_ID=0 default APIC_ID_OFFSET=0x10 default LIFT_BSP_APIC_ID=0 default CONFIG_IOAPIC=1
I will try to dig deeper now, either the CPU crashes while trying to start or it is not started again after the first startup.
Rudolf
On Tue, Oct 23, 2007 at 10:31:48PM +0200, Rudolf Marek wrote:
Hi all,
new boot log with log level = 8?
Random unrelated note:
Please always post boot logs and debug output to the list, where it's archived. We want to be able to read up on old posts, problems, patches, discussions even in 5 five years from now...
Uwe.
Please always post boot logs and debug output to the list, where it's archived. We want to be able to read up on old posts, problems, patches, discussions even in 5 five years from now...
If the size does not matter I will.
R.
LinuxBIOS-2.0.0_Fallback Út říj 23 22:10:56 CEST 2007 starting... now booting... fallback
LinuxBIOS-2.0.0_Normal Út říj 23 22:10:39 CEST 2007 starting... now booting... real_main core0 started: now booting... Core0 started started ap apicid:
LinuxBIOS-2.0.0_Fallback Út říj 23 22:10:56 CEST 2007 starting... now booting... fallback
LinuxBIOS-2.0.0_Normal Út říj 23 22:10:39 CEST 2007 starting... now booting... real_main core1: ---- {APICID = 01 NODEID = 00 COREID = 01} --- 01 SBLink=00 NC node|link=00 LDT width and speed for K8T890 was1106ht reset - soft reset
LinuxBIOS-2.0.0_Fallback Út říj 23 22:10:56 CEST 2007 starting... now booting... fallback
LinuxBIOS-2.0.0_Normal Út říj 23 22:10:39 CEST 2007 starting... now booting... real_main core0 started: now booting... Core0 started started ap apicid:
LinuxBIOS-2.0.0_Fallback Út říj 23 22:10:56 CEST 2007 starting... now booting... fallback
LinuxBIOS-2.0.0_Normal Út říj 23 22:10:39 CEST 2007 starting... now booting... real_main core1: ---- {APICID = 01 NODEID = 00 COREID = 01} --- 01 SBLink=00 NC node|link=00 LDT width and speed for K8T890 was1106DIMM 50 OFFSET 00 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 80 After reset status: 0040 DIMM 50 OFFSET 01 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 08 After reset status: 0040 DIMM 50 OFFSET 02 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 07 After reset status: 0040 DIMM 50 OFFSET 03 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 0d After reset status: 0040 DIMM 50 OFFSET 04 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 0a After reset status: 0040 DIMM 50 OFFSET 05 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 02 After reset status: 0040 DIMM 50 OFFSET 06 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 40 After reset status: 0040 DIMM 50 OFFSET 07 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 00 After reset status: 0040 DIMM 50 OFFSET 08 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 04 After reset status: 0040 DIMM 50 OFFSET 09 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 50 After reset status: 0040 DIMM 50 OFFSET 0a After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 60 After reset status: 0040 DIMM 50 OFFSET 0b After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 00 After reset status: 0040 DIMM 50 OFFSET 0c After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 82 After reset status: 0040 DIMM 50 OFFSET 0d After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 08 After reset status: 0040 DIMM 50 OFFSET 0e After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 00 After reset status: 0040 DIMM 50 OFFSET 0f After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 01 After reset status: 0040 DIMM 50 OFFSET 10 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 0e After reset status: 0040 DIMM 50 OFFSET 11 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 04 After reset status: 0040 DIMM 50 OFFSET 12 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 0c After reset status: 0040 DIMM 50 OFFSET 13 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 01 After reset status: 0040 DIMM 50 OFFSET 14 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 02 After reset status: 0040 DIMM 50 OFFSET 15 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 20 After reset status: 0040 DIMM 50 OFFSET 16 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 00 After reset status: 0040 DIMM 50 OFFSET 17 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 60 After reset status: 0040 DIMM 50 OFFSET 18 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 70 After reset status: 0040 DIMM 50 OFFSET 19 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 00 After reset status: 0040 DIMM 50 OFFSET 1a After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 00 After reset status: 0040 DIMM 50 OFFSET 1b After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 3c After reset status: 0040 DIMM 50 OFFSET 1c After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 28 After reset status: 0040 DIMM 50 OFFSET 1d After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 3c After reset status: 0040 WA Ram1.00 Ram2.00 DIMM 50 OFFSET 02 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 07 After reset status: 0040 DIMM 51 OFFSET 02 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 07 After reset status: 0040 DIMM 52 OFFSET 02 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready
Device Error Read: 00 After reset status: 0040 DIMM 53 OFFSET 02 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready
Device Error Read: 00 After reset status: 0040 DIMM 50 OFFSET 02 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 07 After reset status: 0040 DIMM 51 OFFSET 02 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 07 After reset status: 0040 DIMM 50 OFFSET 03 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 0d After reset status: 0040 DIMM 51 OFFSET 03 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 0d After reset status: 0040 DIMM 50 OFFSET 04 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 0a After reset status: 0040 DIMM 51 OFFSET 04 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 0a After reset status: 0040 DIMM 50 OFFSET 05 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 02 After reset status: 0040 DIMM 51 OFFSET 05 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 02 After reset status: 0040 DIMM 50 OFFSET 06 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 40 After reset status: 0040 DIMM 51 OFFSET 06 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 40 After reset status: 0040 DIMM 50 OFFSET 07 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 00 After reset status: 0040 DIMM 51 OFFSET 07 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 00 After reset status: 0040 DIMM 50 OFFSET 09 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 50 After reset status: 0040 DIMM 51 OFFSET 09 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 50 After reset status: 0040 DIMM 50 OFFSET 0b After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 00 After reset status: 0040 DIMM 51 OFFSET 0b After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 00 After reset status: 0040 DIMM 50 OFFSET 0d After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 08 After reset status: 0040 DIMM 51 OFFSET 0d After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 08 After reset status: 0040 DIMM 50 OFFSET 11 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 04 After reset status: 0040 DIMM 51 OFFSET 11 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 04 After reset status: 0040 DIMM 50 OFFSET 12 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 0c After reset status: 0040 DIMM 51 OFFSET 12 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 0c After reset status: 0040 DIMM 50 OFFSET 15 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 20 After reset status: 0040 DIMM 51 OFFSET 15 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 20 After reset status: 0040 DIMM 50 OFFSET 17 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 60 After reset status: 0040 DIMM 51 OFFSET 17 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 60 After reset status: 0040 DIMM 50 OFFSET 1a After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 00 After reset status: 0040 DIMM 51 OFFSET 1a After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 00 After reset status: 0040 DIMM 50 OFFSET 1b After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 3c After reset status: 0040 DIMM 51 OFFSET 1b After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 3c After reset status: 0040 DIMM 50 OFFSET 1c After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 28 After reset status: 0040 DIMM 51 OFFSET 1c After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 28 After reset status: 0040 DIMM 50 OFFSET 1d After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 3c After reset status: 0040 DIMM 51 OFFSET 1d After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 3c After reset status: 0040 DIMM 50 OFFSET 1e After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 28 After reset status: 0040 DIMM 51 OFFSET 1e After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 28 After reset status: 0040 DIMM 50 OFFSET 29 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 37 After reset status: 0040 DIMM 51 OFFSET 29 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 37 After reset status: 0040 DIMM 50 OFFSET 2a After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 41 After reset status: 0040 DIMM 51 OFFSET 2a After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 41 After reset status: 0040 DIMM 50 OFFSET 03 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 0d After reset status: 0040 DIMM 50 OFFSET 04 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 0a After reset status: 0040 DIMM 50 OFFSET 11 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 04 After reset status: 0040 DIMM 50 OFFSET 07 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 00 After reset status: 0040 DIMM 50 OFFSET 06 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 40 After reset status: 0040 DIMM 50 OFFSET 05 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 02 After reset status: 0040 DIMM 50 OFFSET 03 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 0d After reset status: 0040 DIMM 50 OFFSET 15 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 20 After reset status: 0040 NB CAP REG:00001119 DIMM 50 OFFSET 12 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 0c After reset status: 0040 DIMM 50 OFFSET 17 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 60 After reset status: 0040 DIMM 50 OFFSET 09 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 50 After reset status: 0040 DIMM 50 OFFSET 12 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 0c After reset status: 0040 DIMM 50 OFFSET 09 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 50 After reset status: 0040 200Mhz DIMM 50 OFFSET 29 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 37 After reset status: 0040 DIMM 50 OFFSET 2a After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 41 After reset status: 0040 DIMM 50 OFFSET 1d After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 3c After reset status: 0040 DIMM 50 OFFSET 1c After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 28 After reset status: 0040 DIMM 50 OFFSET 1e After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 28 After reset status: 0040 DIMM 50 OFFSET 1b After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 3c After reset status: 0040 DIMM 50 OFFSET 03 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 0d After reset status: 0040 DIMM 50 OFFSET 0d After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 08 After reset status: 0040 DIMM 50 OFFSET 05 After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 02 After reset status: 0040 DIMM 50 OFFSET 0b After reset status: 0040 Waiting until smbus ready Waiting until smbus ready Read: 00 After reset status: 0040 RDPREAMBLE: 000a Ram3 Initializing memory: done Ram4 v_esp=000ceec8 testx = 5a5a5a5a Copying data from cache to RAM -- switching to use RAM as stack... Done testx = 5a5a5a5a Disabling cache as ram now Clearing initial memory region: Done Copying LinuxBIOS to RAM. src=fffa0000 dst=00004000 linxbios_ram.nrv2b length = 0000dc2a linxbios_ram.bin length = 00021e40 Jumping to LinuxBIOS. LinuxBIOS-2.0.0_Normal Út říj 23 22:10:39 CEST 2007 booting... Enumerating buses... APIC_CLUSTER: 0 enabled PCI_DOMAIN: 0000 enabled PCI: 00:18.3 siblings=1 CPU: APIC: 00 enabled CPU: APIC: 01 enabled PCI: pci_scan_bus for bus 00 PCI: 00:18.0 [1022/1100] enabled PCI: 00:18.1 [1022/1101] enabled PCI: 00:18.2 [1022/1102] enabled PCI: 00:18.3 [1022/1103] enabled In vt8237r_enable 1106 0238. PCI: 00:00.0 [1106/0238] enabled PCI: 00:00.0 [1106/0238] enabled next_unitid: 0013 PCI: pci_scan_bus for bus 00 In vt8237r_enable 1106 0238. PCI: 00:00.0 [1106/0238] enabled PCI: 00:00.1 [1106/1238] enabled 00: 06 11 38 22 06 00 00 02 00 00 00 06 00 00 00 00 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 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 80 00 31 30 08 00 86 7f cf 44 44 34 00 22 40 b0: 3f 13 00 00 03 00 00 00 00 00 00 00 00 00 00 00 c0: aa 00 aa 00 50 50 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Writeback to acfailed 34 00: 06 11 38 22 06 00 00 02 00 00 00 06 00 00 00 00 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 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 13 8e 0e 31 30 3c 80 86 7f cf 44 22 34 00 22 40 b0: 3f 13 00 00 02 00 00 00 00 00 00 00 00 00 00 00 c0: 20 aa aa 02 50 50 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 PCI: 00:00.2 [1106/2238] enabled PCI: 00:00.3 [1106/3238] enabled PCI: 00:00.4 [1106/4238] enabled PCI: 00:00.5 [1106/5238] enabled PCI: 00:00.7 [1106/7238] enabled PCI: 00:01.0 [1106/b188] enabled Configuring PCIe PEG 00: 06 11 38 a2 00 00 10 00 00 00 04 06 00 00 01 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 f0 00 00 00 20: f0 ff 00 00 f0 ff 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 01 00 00 40: 10 68 41 01 41 0e 00 00 00 00 10 00 01 0d 00 00 50: 00 00 01 01 60 00 00 00 00 00 48 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 01 70 22 c8 00 00 00 00 70: 05 00 80 01 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 01 04 00 00 10 00 00 00 00 00 00 00 00 00 00 00 b0: 0c 12 40 80 00 00 03 00 00 00 00 00 00 00 00 00 c0: 03 00 01 00 44 44 44 44 44 44 44 44 00 00 00 00 d0: 50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 0c 07 01 8a f8 00 00 00 01 82 f8 00 00 00 00 00 f0: 00 00 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00: 06 11 38 a2 00 00 10 00 00 00 04 06 00 00 01 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 f0 00 00 00 20: f0 ff 00 00 f0 ff 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 01 00 00 40: 10 68 41 01 41 0e 00 00 00 00 10 00 01 0d 00 00 50: 00 00 01 01 60 00 00 00 00 00 48 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 01 70 22 c8 00 00 00 00 70: 05 00 80 01 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 01 04 00 00 30 00 00 00 00 00 00 00 00 00 00 00 b0: 0c f0 40 80 00 00 03 00 01 00 00 00 00 00 00 00 c0: 43 00 01 00 44 44 44 44 44 44 44 44 00 00 00 00 d0: 50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 0c 0b 01 8a f8 00 00 00 01 82 f8 00 00 00 00 00 f0: 00 00 00 06 00 00 00 00 00 00 00 00 00 00 00 00 PCI: 00:02.0 [1106/a238] enabled Configuring PCIe PEXs 00: 06 11 38 c2 00 00 10 00 00 00 04 06 00 00 81 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 f0 00 00 00 20: f0 ff 00 00 f0 ff 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 01 00 00 40: 10 68 41 01 01 0e 00 00 00 00 10 00 41 0c 00 01 50: 00 00 01 00 60 00 00 00 00 00 48 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 01 70 22 c8 00 00 00 00 70: 05 00 80 01 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 01 04 00 00 10 00 00 00 00 00 00 00 00 00 00 00 b0: 3b 59 40 80 00 00 03 00 00 00 00 00 00 00 00 00 c0: 03 00 01 00 44 44 00 00 00 00 00 00 00 00 00 00 d0: 50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 0b 01 8a f8 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00: 06 11 38 c2 00 00 10 00 00 00 04 06 00 00 81 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 f0 00 00 00 20: f0 ff 00 00 f0 ff 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 01 00 00 40: 10 68 41 01 01 0e 00 00 00 00 10 00 41 0c 00 01 50: 00 00 01 00 60 00 00 00 00 00 48 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 01 70 22 c8 00 00 00 00 70: 05 00 80 01 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 01 04 00 00 10 00 00 00 00 00 00 00 00 00 00 00 b0: 3b f0 40 80 00 00 03 00 00 00 00 00 00 00 00 00 c0: 03 00 01 00 44 44 00 00 00 00 00 00 00 00 00 00 d0: 50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 0b 01 8a f8 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 06 00 00 00 00 00 00 00 00 00 00 00 00 PCI: 00:03.0 [1106/c238] enabled Configuring PCIe PEXs 00: 06 11 38 d2 00 00 10 00 00 00 04 06 00 00 81 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 f0 00 00 00 20: f0 ff 00 00 f0 ff 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 02 00 00 40: 10 68 41 01 01 0e 00 00 00 00 10 00 11 0c 00 02 50: 00 00 01 00 60 00 00 00 00 00 48 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 01 70 22 c8 00 00 00 00 70: 05 00 80 01 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 01 04 00 00 10 00 00 00 00 00 00 00 00 00 00 00 b0: 3b 59 40 80 00 00 03 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00 d0: 50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 0b 00 02 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00: 06 11 38 d2 00 00 10 00 00 00 04 06 00 00 81 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 f0 00 00 00 20: f0 ff 00 00 f0 ff 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 02 00 00 40: 10 68 41 01 01 0e 00 00 00 00 10 00 11 0c 00 02 50: 00 00 01 00 60 00 00 00 00 00 48 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 01 70 22 c8 00 00 00 00 70: 05 00 80 01 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 01 04 00 00 10 00 00 00 00 00 00 00 00 00 00 00 b0: 3b f0 40 80 00 00 03 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00 d0: 50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 0b 00 02 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 PCI: 00:03.1 [1106/d238] enabled Configuring PCIe PEXs 00: 06 11 38 e2 00 00 10 00 00 00 04 06 00 00 81 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 f0 00 00 00 20: f0 ff 00 00 f0 ff 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 03 00 00 40: 10 68 41 01 c1 0e 00 00 00 00 10 00 11 0c 00 03 50: 00 00 11 00 60 00 00 00 00 00 48 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 01 70 22 c8 00 00 00 00 70: 05 00 80 01 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 01 04 00 00 10 00 00 00 00 00 00 00 00 00 00 00 b0: 3b 59 40 80 00 00 03 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00 d0: 50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 0b 00 02 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00: 06 11 38 e2 00 00 10 00 00 00 04 06 00 00 81 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 f0 00 00 00 20: f0 ff 00 00 f0 ff 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 03 00 00 40: 10 68 41 01 c1 0e 00 00 00 00 10 00 11 0c 00 03 50: 00 00 11 00 60 00 00 00 00 00 48 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 01 70 22 c8 00 00 00 00 70: 05 00 80 01 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 01 04 00 00 10 00 00 00 00 00 00 00 00 00 00 00 b0: 3b f0 40 80 00 00 03 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00 d0: 50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 0b 00 02 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 PCI: 00:03.2 [1106/e238] enabled Configuring PCIe PEXs 00: 06 11 38 f2 00 00 10 00 00 00 04 06 00 00 81 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 f0 00 00 00 20: f0 ff 00 00 f0 ff 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 04 00 00 40: 10 68 41 01 01 0e 00 00 00 00 10 00 11 0c 00 04 50: 00 00 01 00 60 00 00 00 00 00 48 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 01 70 22 c8 00 00 00 00 70: 05 00 80 01 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 01 04 00 00 10 00 00 00 00 00 00 00 00 00 00 00 b0: 3b 59 40 80 00 00 03 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00 d0: 50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 0b 00 02 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00: 06 11 38 f2 00 00 10 00 00 00 04 06 00 00 81 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 f0 00 00 00 20: f0 ff 00 00 f0 ff 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 04 00 00 40: 10 68 41 01 01 0e 00 00 00 00 10 00 11 0c 00 04 50: 00 00 01 00 60 00 00 00 00 00 48 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 01 70 22 c8 00 00 00 00 70: 05 00 80 01 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 01 04 00 00 10 00 00 00 00 00 00 00 00 00 00 00 b0: 3b f0 40 80 00 00 03 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00 d0: 50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 0b 00 02 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 PCI: 00:03.3 [1106/f238] enabled PCI: 00:0c.0 [10ec/8139] enabled PCI: 00:0f.0 [1106/3149] enabled PCI: 00:0f.1 [1106/0571] enabled PCI: 00:10.0 [1106/3038] enabled PCI: 00:10.1 [1106/3038] enabled PCI: 00:10.2 [1106/3038] enabled PCI: 00:10.3 [1106/3038] enabled PCI: 00:10.4 [1106/3104] enabled PCI: 00:10.5 [1106/d104] enabled In vt8237r_enable 1106 3227. PCI: 00:11.0 [1106/3227] enabled PCI: 00:11.5 [1106/3059] enabled PCI: 00:11.6 [1106/3068] enabled In vt8237r_enable ffff ffff. PCI: pci_scan_bus for bus 01 PCI: pci_scan_bus returning with max=001 PCI: pci_scan_bus for bus 02 PCI: 02:00.0 [1002/5b60] enabled PCI: 02:00.1 [1002/5b70] enabled PCI: pci_scan_bus returning with max=002 PCIEXP: tunning PCI: 02:00.0 PCIEXP: tunning PCI: 02:00.1 PCI: pci_scan_bus for bus 03 PCI: pci_scan_bus returning with max=003 PCI: pci_scan_bus for bus 04 PCI: pci_scan_bus returning with max=004 PCI: pci_scan_bus for bus 05 PCI: 05:00.0 [11ab/4362] enabled PCI: pci_scan_bus returning with max=005 PCIEXP: tunning PCI: 05:00.0 PCI: pci_scan_bus for bus 06 PCI: pci_scan_bus returning with max=006 smbus: PCI: 00:11.0[0]->I2C: 01:50 enabled smbus: PCI: 00:11.0[0]->I2C: 01:51 enabled smbus: PCI: 00:11.0[0]->I2C: 01:52 enabled smbus: PCI: 00:11.0[0]->I2C: 01:53 enabled PNP: 002e.0 enabled PNP: 002e.1 disabled PNP: 002e.2 enabled PNP: 002e.3 disabled PNP: 002e.5 disabled PNP: 002e.6 disabled PNP: 002e.7 disabled PNP: 002e.8 disabled PNP: 002e.9 disabled PNP: 002e.a disabled PNP: 002e.b enabled PCI: pci_scan_bus returning with max=006 PCI: pci_scan_bus returning with max=006 done Allocating resources... Reading resources... PCI: 00:01.0 1c <- [0x000000f000 - 0x000000efff] bus 01 io PCI: 00:01.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 01 prefmem PCI: 00:01.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 01 mem PCI: 00:03.0 1c <- [0x000000f000 - 0x000000efff] bus 03 io PCI: 00:03.0 24 <- [0x0ffff00000 - 0x0fffefffff] bus 03 prefmem PCI: 00:03.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 03 mem PCI: 00:03.1 1c <- [0x000000f000 - 0x000000efff] bus 04 io PCI: 00:03.1 24 <- [0x0ffff00000 - 0x0fffefffff] bus 04 prefmem PCI: 00:03.1 20 <- [0x00fff00000 - 0x00ffefffff] bus 04 mem PCI: 00:03.2 24 <- [0x0ffff00000 - 0x0fffefffff] bus 05 prefmem PCI: 00:03.3 1c <- [0x000000f000 - 0x000000efff] bus 06 io PCI: 00:03.3 24 <- [0x0ffff00000 - 0x0fffefffff] bus 06 prefmem PCI: 00:03.3 20 <- [0x00fff00000 - 0x00ffefffff] bus 06 mem PCI: 00:10.5 register 10(ffffffff), read-only ignoring it PCI: 00:10.5 register 14(ffffffff), read-only ignoring it PCI: 00:10.5 register 18(ffffffff), read-only ignoring it PCI: 00:10.5 register 1c(ffffffff), read-only ignoring it PCI: 00:10.5 register 20(ffffffff), read-only ignoring it PCI: 00:10.5 register 24(ffffffff), read-only ignoring it PCI: 00:10.5 register 30(ffffffff), read-only ignoring it Done reading resources. Allocating VGA resource PCI: 02:00.0 Setting PCI_BRIDGE_CTL_VGA for bridge PCI: 00:02.0 Setting PCI_BRIDGE_CTL_VGA for bridge PCI: 00:18.0 Setting PCI_BRIDGE_CTL_VGA for bridge PCI_DOMAIN: 0000 Setting PCI_BRIDGE_CTL_VGA for bridge Root Device Setting resources... VGA: PCI: 00:18.0 (aka node 0) link 0 has VGA device PCI: 00:18.0 1b8 <- [0x00c0000000 - 0x00d7ffffff] prefmem <node 0 link 0> PCI: 00:18.0 1c0 <- [0x0000001000 - 0x0000004fff] io <node 0 link 0> PCI: 00:18.0 1b0 <- [0x00e0000000 - 0x00f02fffff] mem <node 0 link 0> PCI: 00:00.0 10 <- [0x00c0000000 - 0x00cfffffff] prefmem PCI: 00:02.0 1c <- [0x0000001000 - 0x0000001fff] bus 02 io PCI: 00:02.0 24 <- [0x00d0000000 - 0x00d7ffffff] bus 02 prefmem PCI: 00:02.0 20 <- [0x00f0000000 - 0x00f00fffff] bus 02 mem PCI: 02:00.0 10 <- [0x00d0000000 - 0x00d7ffffff] prefmem PCI: 02:00.0 14 <- [0x0000001000 - 0x00000010ff] io PCI: 02:00.0 18 <- [0x00f0020000 - 0x00f002ffff] mem PCI: 02:00.0 30 <- [0x00f0000000 - 0x00f001ffff] romem PCI: 02:00.1 10 <- [0x00f0030000 - 0x00f003ffff] mem PCI: 00:03.2 1c <- [0x0000002000 - 0x0000002fff] bus 05 io PCI: 00:03.2 20 <- [0x00f0100000 - 0x00f01fffff] bus 05 mem PCI: 05:00.0 10 <- [0x00f0120000 - 0x00f0123fff] mem64 PCI: 05:00.0 18 <- [0x0000002000 - 0x00000020ff] io PCI: 05:00.0 30 <- [0x00f0100000 - 0x00f011ffff] romem PCI: 00:0c.0 10 <- [0x0000003000 - 0x00000030ff] io PCI: 00:0c.0 14 <- [0x00f0210000 - 0x00f02100ff] mem PCI: 00:0c.0 30 <- [0x00f0200000 - 0x00f020ffff] romem PCI: 00:0f.0 10 <- [0x00000040a0 - 0x00000040a7] io PCI: 00:0f.0 14 <- [0x00000040c0 - 0x00000040c3] io PCI: 00:0f.0 18 <- [0x00000040b0 - 0x00000040b7] io PCI: 00:0f.0 1c <- [0x00000040d0 - 0x00000040d3] io PCI: 00:0f.0 20 <- [0x0000004080 - 0x000000408f] io PCI: 00:0f.0 24 <- [0x0000003400 - 0x00000034ff] io PCI: 00:0f.1 20 <- [0x0000004090 - 0x000000409f] io PCI: 00:10.0 20 <- [0x0000004000 - 0x000000401f] io PCI: 00:10.1 20 <- [0x0000004020 - 0x000000403f] io PCI: 00:10.2 20 <- [0x0000004040 - 0x000000405f] io PCI: 00:10.3 20 <- [0x0000004060 - 0x000000407f] io PCI: 00:10.4 10 <- [0x00f0211000 - 0x00f02110ff] mem PNP: 002e.0 60 <- [0x00000003f0 - 0x00000003f7] io PNP: 002e.0 70 <- [0x0000000006 - 0x0000000006] irq PNP: 002e.0 74 <- [0x0000000002 - 0x0000000002] drq PNP: 002e.2 60 <- [0x00000003f8 - 0x00000003ff] io PNP: 002e.2 70 <- [0x0000000004 - 0x0000000004] irq PNP: 002e.b 60 <- [0x0000000290 - 0x0000000297] io PNP: 002e.b 70 <- [0x0000000000 - 0x0000000000] irq PCI: 00:11.5 10 <- [0x0000003800 - 0x00000038ff] io PCI: 00:11.6 10 <- [0x0000003c00 - 0x0000003cff] io PCI: 00:18.3 94 <- [0x00f4000000 - 0x00f7ffffff] mem <gart> Done setting resources. Done allocating resources. Enabling resources... PCI: 00:18.0 cmd <- 140 PCI: 00:00.0 cmd <- 146 PCI: 00:00.1 cmd <- 146 PCI: 00:00.2 cmd <- 146 PCI: 00:00.3 cmd <- 146 PCI: 00:00.4 cmd <- 146 PCI: 00:00.5 cmd <- 146 PCI: 00:00.7 cmd <- 146 PCI: 00:01.0 bridge ctrl <- 0017 PCI: 00:01.0 cmd <- 147 PCI: 00:02.0 bridge ctrl <- 000b PCI: 00:02.0 cmd <- 147 PCI: 02:00.0 cmd <- 143 PCI: 02:00.1 cmd <- 142 PCI: 00:03.0 bridge ctrl <- 0003 PCI: 00:03.0 cmd <- 140 PCI: 00:03.1 bridge ctrl <- 0003 PCI: 00:03.1 cmd <- 140 PCI: 00:03.2 bridge ctrl <- 0003 PCI: 00:03.2 cmd <- 147 PCI: 05:00.0 cmd <- 143 PCI: 00:03.3 bridge ctrl <- 0003 PCI: 00:03.3 cmd <- 140 PCI: 00:0c.0 cmd <- 143 PCI: 00:0f.0 cmd <- 141 PCI: 00:0f.1 cmd <- 1c1 PCI: 00:10.0 cmd <- 141 PCI: 00:10.1 cmd <- 141 PCI: 00:10.2 cmd <- 141 PCI: 00:10.3 cmd <- 141 PCI: 00:10.4 cmd <- 142 PCI: 00:10.5 cmd <- ffff PCI: 00:11.0 cmd <- 147 I2C: 01:50 missing enable_resources I2C: 01:51 missing enable_resources I2C: 01:52 missing enable_resources I2C: 01:53 missing enable_resources w83627ehg hwm smbus enabled PCI: 00:11.5 cmd <- 141 PCI: 00:11.6 cmd <- 141 PCI: 00:18.1 subsystem <- 1462/9282 PCI: 00:18.1 cmd <- 140 PCI: 00:18.2 subsystem <- 1462/9282 PCI: 00:18.2 cmd <- 140 PCI: 00:18.3 cmd <- 140 done. Initializing devices... Root Device init APIC_CLUSTER: 0 init Initializing CPU #0 CPU: vendor AMD device 20f32 CPU: family 0f, model 23, stepping 02 Enabling cache
Setting fixed MTRRs(0-88) type: UC Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM DONE fixed MTRRs Setting variable MTRR 0, base: 0MB, range: 1024MB, type WB DONE variable MTRRs Clear out the extra MTRR's
MTRR check Fixed MTRRs : Enabled Variable MTRRs: Enabled
microcode: equivalent processor rev id = 0x0210, patch id = 0x00000000 microcode: patch id that want to apply= 0x0000004d microcode: updated to patch id = 0x0000004d success CPU model Dual Core AMD Opteron(tm) Processor 175 Setting up local apic... apic_id: 0x00 done. ECC Disabled CPU #0 Initialized Asserting INIT. on 1 CPU 0x01 would not start! CPU 0x01 did not initialize! All AP CPUs stopped PCI: 00:18.0 init PCI: 00:11.0 init vt8237r init RTC Init PNP: 002e.0 init PNP: 002e.2 init PNP: 002e.b init PCI: 00:18.1 init PCI: 00:18.2 init PCI: 00:18.3 init NB: Function 3 Misc Control.. done. PCI: 00:00.1 init PCI: 00:00.4 init PCI: 00:0c.0 init rom address for PCI: 00:0c.0 = f0200000 Incorrect Expansion ROM Header Signature 0000 PCI: 00:0f.0 init Configuring VIA SATA Controller PCI: 00:0f.1 init Enabling VIA IDE. enables in reg 0x40 0x38 enables in reg 0x40 read back as 0x3b ide_init: enabling compatibility IDE addresses enables in reg 0x42 0x9 enables in reg 0x42 read back as 0x9 enables in reg 0x9 0x8a enables in reg 0x9 read back as 0x8a command in reg 0x4 0x81 command in reg 0x4 reads back as 0x85 PCI: 00:10.0 init PCI: 00:10.1 init PCI: 00:10.2 init PCI: 00:10.3 init PCI: 00:10.4 init PCI: 00:10.5 init PCI: 00:11.5 init PCI: 00:11.6 init PCI: 02:00.0 init rom address for PCI: 02:00.0 = f0000000 copying VGA ROM Image from 0xf0000000 to 0xc0000, 0x10000 bytes entering emulator halt_sys: file /home/ruik/Moje_dilna/LinuxBIOSv2/src/devices/emulator/x86emu/ops.c, line 4387 PCI: 02:00.1 init PCI: 05:00.0 init rom address for PCI: 05:00.0 = f0100000 Incorrect Expansion ROM Header Signature ffff Devices initialized Copying IRQ routing tables to 0xf0000...done. Verifing copy of IRQ routing tables at 0xf0000...done Checking IRQ routing table consistency... Inconsistent IRQ routing table size (0xd0/0x140) check_pirq_routing_table() - irq_routing_table located at: 0x000f0000 /home/ruik/Moje_dilna/LinuxBIOSv2/src/arch/i386/boot/pirq_routing.c: 36:check_pirq_routing_table() - checksum is: 0xe3 but should be: 0xf1 done. ACPI: Writing ACPI tables at f0400... ACPI: * FACS ACPI: * DSDT @ 000f04ae Length 44e ACPI: * FADT ACPI: added table 1/9 Length now 40 ACPI: * HPET ACPI: added table 2/9 Length now 44 ACPI: * MADT ACPI: added table 3/9 Length now 48 ACPI: * MCFG ACPI: added table 4/9 Length now 52 ACPI: * SRAT SRAT: lapic cpu_index=00, node_id=00, apic_id=00 set_srat_mem: dev PCI_DOMAIN: 0000, res->index=0010 startk=00000000, sizek=00000280 set_srat_mem: dev PCI_DOMAIN: 0000, res->index=0020 startk=00000300, sizek=000ffd00 ACPI: added table 5/9 Length now 56 ACPI: done. Moving GDT to 0x500...ok Adjust low_table_end from 0x00000530 to 0x00001000 Adjust rom_table_end from 0x000f0c00 to 0x00100000 Wrote linuxbios table at: 00000530 - 000006c8 checksum d93e
Welcome to elfboot, the open sourced starter. January 2002, Eric Biederman. Version 1.3
rom_stream: 0xfff80000 - 0xfff9ffff Found ELF candidate at offset 0 header_offset is 0 Try to load at offset 0x0 New segment addr 0x100000 size 0x3cd40 offset 0xc0 filesize 0x12d28 (cleaned up) New segment addr 0x100000 size 0x3cd40 offset 0xc0 filesize 0x12d28 New segment addr 0x13cd40 size 0x48 offset 0x12e00 filesize 0x48 (cleaned up) New segment addr 0x13cd40 size 0x48 offset 0x12e00 filesize 0x48 Dropping non PT_LOAD segment Dropping non PT_LOAD segment Loading Segment: addr: 0x0000000000100000 memsz: 0x000000000003cd40 filesz: 0x0000000000012d28 Clearing Segment: addr: 0x0000000000112d28 memsz: 0x000000000002a018 Loading Segment: addr: 0x000000000013cd40 memsz: 0x0000000000000048 filesz: 0x0000000000000048 Jumping to boot code at 0x10e514 FILO version 0.5 (ruik@ruik) Sun Jun 24 16:30:56 CEST 2007 menu: hda6:/boot/filo/menu.lst hda: LBA48 250GB: ST3250824AS Mounted ext2fs Drive 1 does not exist Drive 1 does not exist
Hi All,
Good news everyone, it works!
The problem was that I did not put: allow_all_aps_stop(bsp_apicid);
into my auto.c code. I did not knew about it :/
The core was never put to sleep and this error was never reached: print_initcpu8("while waiting for BSP signal to STOP, timeout in ap ", apicid);
There is too big timeout.
All in all it does boot Linux and SMP kernel works. It only complains that some MTTRs are not same on both cores, but kernel fixes that. I will take a look into this later.
Thank you for help,
Rudolf
Great! What mainboard :-)
ron
ron minnich wrote:
Great! What mainboard :-)
Asus A8V-E SE,
I already published Northbridge patch, and southbridge yesterday.
Rudolf
On 10/27/07, Rudolf Marek r.marek@assembler.cz wrote:
ron minnich wrote:
Great! What mainboard :-)
Asus A8V-E SE,
Is this board still available?
I already published Northbridge patch, and southbridge yesterday.
If you don't get an ack soon from someone push me and I will do it. I have not done much k8 recently (all geode) so I try to let other experts ack. At the same time, I am sorry to see that Morgans' stuff has fallen through the cracks.
ron
Is this board still available?
Its on ebay. (they have like 60 boards) I think I will buy a spare one maybe ;)
If you don't get an ack soon from someone push me and I will do it. I have not done much k8 recently (all geode) so I try to let other experts ack. At the same time, I am sorry to see that Morgans' stuff has fallen through the cracks.
Well Uwe Peter and Corey are helping me a lot!
Rudolf
On Sat, Oct 27, 2007 at 10:13:47AM -0700, ron minnich wrote:
At the same time, I am sorry to see that Morgans' stuff has fallen through the cracks.
Nope, it has not, don't worry. It will be reviewed, fixed, acked and committed. It just a matter of enough spare time and reviewers, and also I'm not sure how to procede (wait for updated patch from Morgan vs. we try to post an updated patch ourselves -- which we can't test unfortunately).
Uwe.
On 10/27/07, Uwe Hermann uwe@hermann-uwe.de wrote:
Nope, it has not, don't worry. It will be reviewed, fixed, acked and committed.
Thanks Uwe and everyone. You folks do an amazing job!
ron
On Sat, Oct 27, 2007 at 10:13:47AM -0700, ron minnich wrote:
I already published Northbridge patch, and southbridge yesterday.
If you don't get an ack soon from someone push me and I will do it.
Please don't ack just because noone else does it. That defeats the purpose of the reviews.
At the same time, I am sorry to see that Morgans' stuff has fallen through the cracks.
At this point I think we are waiting for updated patches from SiS.
I would like to take this opportunity to address all companies that are already supporting or are interested in supporting the project:
Thank you very much for your interest! I think it's great to be working with you and I am confident that you've made a good choice. With LB your products are definately able to reach new markets!
That said, it is worthwhile to keep in mind that the project has a policy for accepting contributions and additions, with the only (but important) purpose of maintaining the highest possible source code quality. This includes a requirement that any non-trivial change or addition has to be reviewed and approved (via an Acked-by line) by other LB developers.
LB developers is a scarce resource, unfortunately. There is a high risk for bottlenecks at the review stage. This is where it gets interesting for you - you can help speed up the review process considerably:
1. Please talk to us (even if it is off-list) before and during major work on the LB source code. If you are new to the code base there will probably be at least a few things that are sort-of taken for granted within the project, but not really documented anywhere. By communicating at an early stage we can help you avoid these pitfalls which we will expect you to deal with before your contributions are accepted.
2. Please always work against current SVN. This may seem problematic if you need to do major work, but see (3) below.
3. Please send small patches to the mailing list often. This will preempt the problem in (2) above. Small patches are much more easily reviewed, which means that they are likely to be approved and committed quickly. Granted - a new chipset may require a large patch, but it is still good to first send a small patch and then build upon it in subsequent patches.
4. Conversely, please do not ever send a tarball of your entire development tree. It will be flat out rejected because it requires LB developers to do a lot of extra work before any reviewing can be done. Since LB development is a voluntary effort it could even be considered impolite to expect someone else to do a lot of extra work in order for your changes to be included.
5. Always expect at least two or three rounds of reviews and changes before your patch is included. This is connected to (1) above. The more you communicate with LB developers before and during development, the fewer review rounds will be needed before the patch is accepted.
6. Please pay close attention to the contribution guidelines on the wiki. Make sure that things such as coding style, documentation style, clear licensing statements, sign-off etc are all adequately cared for in your patch. Also remember to remove any dead code that was used only for debugging.
If you have already been involved in other open source projects, this will be rather familiar. Hopefully you even consider it to be common sense. If you have questions about any of our practices, please feel free to ask us anything - we'll be happy to answer so that we can include your contributions as quickly as possible.
We want to create world class boot software and we are very happy to have your help! :)
//Peter
Hi,
Am Sonntag, den 28.10.2007, 02:58 +0100 schrieb Peter Stuge:
On Sat, Oct 27, 2007 at 10:13:47AM -0700, ron minnich wrote:
I would like to take this opportunity to address all companies that are already supporting or are interested in supporting the project:
Thank you very much for your interest! I think it's great to be working with you and I am confident that you've made a good choice. With LB your products are definately able to reach new markets!
That said, it is worthwhile to keep in mind that the project has a policy for accepting contributions and additions, with the only (but important) purpose of maintaining the highest possible source code quality. This includes a requirement that any non-trivial change or addition has to be reviewed and approved (via an Acked-by line) by other LB developers.
LB developers is a scarce resource, unfortunately. There is a high risk for bottlenecks at the review stage. This is where it gets interesting for you - you can help speed up the review process considerably:
- Please talk to us (even if it is off-list) before and during major
work on the LB source code. If you are new to the code base there will probably be at least a few things that are sort-of taken for granted within the project, but not really documented anywhere. By communicating at an early stage we can help you avoid these pitfalls which we will expect you to deal with before your contributions are accepted.
- Please always work against current SVN. This may seem problematic
if you need to do major work, but see (3) below.
- Please send small patches to the mailing list often. This will
preempt the problem in (2) above. Small patches are much more easily reviewed, which means that they are likely to be approved and committed quickly. Granted - a new chipset may require a large patch, but it is still good to first send a small patch and then build upon it in subsequent patches.
- Conversely, please do not ever send a tarball of your entire
development tree. It will be flat out rejected because it requires LB developers to do a lot of extra work before any reviewing can be done. Since LB development is a voluntary effort it could even be considered impolite to expect someone else to do a lot of extra work in order for your changes to be included.
- Always expect at least two or three rounds of reviews and changes
before your patch is included. This is connected to (1) above. The more you communicate with LB developers before and during development, the fewer review rounds will be needed before the patch is accepted.
- Please pay close attention to the contribution guidelines on the
wiki. Make sure that things such as coding style, documentation style, clear licensing statements, sign-off etc are all adequately cared for in your patch. Also remember to remove any dead code that was used only for debugging.
If you have already been involved in other open source projects, this will be rather familiar. Hopefully you even consider it to be common sense. If you have questions about any of our practices, please feel free to ask us anything - we'll be happy to answer so that we can include your contributions as quickly as possible.
We want to create world class boot software and we are very happy to have your help! :)
This is a nice write-up and summary. Therefore I would like to see this in the wiki. But I have not been able to come up with a nice wiki-title
- Patch Quality (does not fit, IMHO) - Hints for contibuting companies / contributors
and where to link to it from.
If someone can answer the two issues above and nobody minds, I will add it to the wiki.
Greetings,
Paul
On Sun, Oct 28, 2007 at 10:36:14AM +0100, Paul Menzel wrote:
This is a nice write-up and summary. Therefore I would like to see this in the wiki.
Maybe it could be reworked a little and put on the contribution guidelines page?
//Peter
On 10/27/07, Peter Stuge peter@stuge.se wrote:
Please don't ack just because noone else does it. That defeats the purpose of the reviews.
no, what I meant was, "I will do the review and try to make sure the patch is clean"
Sorry for creating confusion. I'm not just going to ack for the sake of an ack :-); I was just very worried that we might have lost another board.
ron
On 28/10/07 09:06 -0700, ron minnich wrote:
On 10/27/07, Peter Stuge peter@stuge.se wrote:
Please don't ack just because noone else does it. That defeats the purpose of the reviews.
no, what I meant was, "I will do the review and try to make sure the patch is clean"
Sorry for creating confusion. I'm not just going to ack for the sake of an ack :-); I was just very worried that we might have lost another board.
Which is a very reasonable and real fear.
It is very important to remember that most of the companies and vendors that come to this project are not here because they believe in the ideals of open source, or even because they want to create a world class product. In fact, forst most, this is their first foray into the world of open source. Many of them have been convinced to come here by employees, partners, vendors or customers. They are here to present their products because they believe that participation in LinuxBIOS is a good business move, but few want to spend a lot of valuable money and engineering resources on it - they want to dump the code and run, so to speak.
It is all well and good to hold the code to very high standards - and we should continue to do so as an open source community. But we also need to realize that, at this point, we are completely dependent on the vendors to advance this project. If they are willing to buy into the coding standards and the loftier ideas of the open source creedo, then more power to them, and we thank them. But if not, then *we* need to take up the slack, and handle the style and other issues that turn good code into great code. Tossing these back into the face of vendor who really would rather not be here is just incentive for them to storm off and say bad things about us behind our back. Peter's manifesto, while correct, and reflecting our best intentions, is sure not to help the matter at all. The vendors we so desperately need just don't buy into it. Sorry.
I'm not sure if SiS is coming back, and I wouldn't be surprised if they didn't.
Jordan
On 10/29/07, Jordan Crouse jordan.crouse@amd.com wrote:
I'm not sure if SiS is coming back, and I wouldn't be surprised if they didn't.
Translation: we, collectively, need to do better. I realize we're all volunteers, and this is a 'time available' activity. Given that, what can we do better to make this smoother for people?
One possibility is, the next time someone comes in, rather than just critiquing the code, we get a group of people -- say 3 or 4 -- each of whom takes on the responsibility for a directory, starting at the leaves. Something like this:
superio (s) southbridge(s) northbridges(s) cpu
once those are absorbed, we do the mainboard, and then, the target.
This is the 'shepherd' model.
This team would form dynamically and communicate (via the list?) on the changes that have to be made. But people would have to sign up for a given piece, and a deadline.
But if we can't do better when someone like Morgan comes in, it's going to hurt us. I don't feel (me included) that we did what we needed to do. The 'code critique' approach works in some cases, but for those who need more assistance, we need a different procedure, which would be more active and helpful.
ron
This is really great discussion!
On Mon, Oct 29, 2007 at 09:57:38AM -0600, Jordan Crouse wrote:
I was just very worried that we might have lost another board.
Which is a very reasonable and real fear.
Board no, vendor maybe.
In fact, forst most, this is their first foray into the world of open source.
True. It's important that we make contributors feel welcome.
They are here to present their products because they believe that participation in LinuxBIOS is a good business move,
Indeed.
but few want to spend a lot of valuable money and engineering resources on it -
All business moves require an investment. Some resources will always be neccessary, be it money, sending out hardware samples, engineering resources or documentation resources.
they want to dump the code and run so to speak.
And they can. I understand this desire and the frustration newcomers experience from the review/revision process we practise on the list.
My point was that new contributors can save work and time (get patches committed sooner) by communicating with the project not only when the patch is submitted but also before and during the development.
But we also need to realize that, at this point, we are completely dependent on the vendors to advance this project.
We certainly need information from vendors, but I don't think we're dependent on them for code.
The way I see it, there is a competitive advantage for vendors who _do_ submit code because they will have support for their hardware much sooner than if they only contributed documentation and relied on volunteers to write the code.
If they are willing to buy into the coding standards and the loftier ideas of the open source creedo, then more power to them, and we thank them. But if not, then *we* need to take up the slack, and handle the style and other issues that turn good code into great code.
Yes and no. We are interested in the project so it's likely that someone eventually finds the time to work through a huge workload that would benefit the project. I think the best example of this is the MCP55 support. What I wanted to convey and probably should have emphasized more is that it will take much longer if volunteers need to do a lot of work before the code is committed.
Tossing these back into the face of vendor who really would rather not be here
Either a vendor thinks it's a good business move or they don't. Again - no business without investment. I'd like to reduce the investment.
is just incentive for them to storm off and say bad things about us behind our back.
We should be easy to work with, I agree completely.
Peter's manifesto, while correct, and reflecting our best intentions, is sure not to help the matter at all.
It could probably use a revision after this great review round, especially if it's going to the wiki.
I did not want to set rules in stone, rather I wanted to distill the practises we employ into concrete advice for new contributors so that they could make the most of their time working with the project.
The vendors we so desperately need just don't buy into it. Sorry.
If you're saying that vendors can't be bothered to work with the project then all I'm saying is that it will take longer for their hardware to be supported.
On Mon, Oct 29, 2007 at 03:51:38PM -0700, ron minnich wrote:
I'm not sure if SiS is coming back, and I wouldn't be surprised if they didn't.
Translation: we, collectively, need to do better. I realize we're all volunteers, and this is a 'time available' activity. Given that, what can we do better to make this smoother for people?
We can't do anything after the fact. If a vendor dumps a huge patch, or a tree with tons of changes, on us and runs, we just don't have the resources to review and commit over night.
This is the 'shepherd' model.
I like the idea.
This team would form dynamically and communicate (via the list?) on the changes that have to be made. But people would have to sign up for a given piece, and a deadline.
(I don't really believe in deadlines in open source projects, but that's just me, and a side track.)
But if we can't do better when someone like Morgan comes in, it's going to hurt us.
I think it hurts the contributor equally, assuming they actually want their code to be committed.
I don't feel (me included) that we did what we needed to do. The 'code critique' approach works in some cases, but
Without hardware or documentation there is not much more to be done.
Of course we could fix up any problems we notice, but that's usually left to the original contributor.
for those who need more assistance, we need a different procedure, which would be more active and helpful.
Spot on. I think it starts long before the final patch is sent.
//Peter
* Peter Stuge peter@stuge.se [071030 01:31]:
but few want to spend a lot of valuable money and engineering resources on it -
All business moves require an investment. Some resources will always be neccessary, be it money, sending out hardware samples, engineering resources or documentation resources.
I certainly agree on the investment. But: I would not visit a restaurant twice, no matter how delicious the food is, if the waiter annoys me and takes 2 weeks before getting me seated.
And they can. I understand this desire and the frustration newcomers experience from the review/revision process we practise on the list.
My point was that new contributors can save work and time (get patches committed sooner) by communicating with the project not only when the patch is submitted but also before and during the development.
This is also a matter of attitude. We should take this contribution as an "early communication" that we can use and improve until the final work results from it. A work where the community contributes its part, as does the vendors.
Trying to educate people how to indent is pretty common in the open source world, but is also kind of rude. We are very well capable of indenting and beautifying the LinuxBIOS code ourselfes. No need to torchure any vendor contributor with that.
The way I see it, there is a competitive advantage for vendors who _do_ submit code because they will have support for their hardware much sooner than if they only contributed documentation and relied on volunteers to write the code.
I absolutely agree. The number of ports that came out of just for fun development for a single board is rather small. It is very cool that it does happen though.
Yes and no. We are interested in the project so it's likely that someone eventually finds the time to work through a huge workload that would benefit the project. I think the best example of this is the MCP55 support. What I wanted to convey and probably should have emphasized more is that it will take much longer if volunteers need to do a lot of work before the code is committed.
I think the MCP55 is an excellent example. The code has been checked in for a while, and people start using it in more unusual constellations. Suddenly patches from all kinds of people start coming in. A few lines here, a few lines there, constantly improving the result.
Imagine this would have resulted from a code review. This would put the pressure on a single committer and keep the code from being available for improvement in the repository.
I am glad it did not stick in the review loop unless all GPIO issues were sorted out.
Tossing these back into the face of vendor who really would rather not be here
Either a vendor thinks it's a good business move or they don't.
This is the starting point. In the beginning of LinuxBIOS no vendor thought it would be. We convinced some of them. Why should we stop convincing them now? One way of convincing people if by making them feel understood and taken care of.
It could probably use a revision after this great review round, especially if it's going to the wiki.
I did not want to set rules in stone, rather I wanted to distill the practises we employ into concrete advice for new contributors so that they could make the most of their time working with the project.
You did a very good job bringing it to electrons (rather than stone)
Being a successful project, we should think about what vendors can do for us, and also what we can do for the vendors. Manus manum lavat.
We can't do anything after the fact. If a vendor dumps a huge patch, or a tree with tons of changes, on us and runs, we just don't have the resources to review and commit over night.
We are usually having huge delays, even though they do not really help the process but are caused by the hurdle of our "process". The "process" needs to be optimized to our needs. If there's a simple trick we can do to enable more people to improve what a contributor like Morgan gives us, we should definitely take the chance and do it.
Of course we could fix up any problems we notice, but that's usually left to the original contributor.
I think this proved top be an exhausting model in the last couple of months.
Spot on. I think it starts long before the final patch is sent.
There is no such thing as final. We are constantly moving and innovating ;-)
Stefan
* ron minnich rminnich@gmail.com [071029 23:51]:
One possibility is, the next time someone comes in, rather than just critiquing the code, we get a group of people -- say 3 or 4 -- each of whom takes on the responsibility for a directory, starting at the leaves. Something like this:
superio (s) southbridge(s) northbridges(s) cpu
In addition: New components are undangerous to add as long as they are signed off and do not contain proprietary licensed code. We can just commit them before finding a shepherd - Nothing will break except the fresh code is maybe not working yet.
The advantage is clear: Instead of keeping iterations of work on the vendor side while we waste our time on writing mails, we can spend the same time fixing the code ourselfes and take that burdon off the committers. Repeatedly asking for patches because of missing full stops and unsigned char -> uint8_t conversions is more effort than producing a stressful interface to potential committers. We need to become easier to handle in this way.
once those are absorbed, we do the mainboard, and then, the target.
This is the 'shepherd' model.
I like this idea a lot. The shepherds are the extended and more work-directed versions of reviewers. (which should not go away)
This team would form dynamically and communicate (via the list?) on the changes that have to be made. But people would have to sign up for a given piece, and a deadline.
How would signing up work? We have a pretty active community with many people having something to contribute. Assigning tasks and duties and deadlines might very well scare people off that would have something valuable to say, otherwise. Therefore I believe we should handle this very casual.
But if we can't do better when someone like Morgan comes in, it's going to hurt us. I don't feel (me included) that we did what we needed to do. The 'code critique' approach works in some cases, but for those who need more assistance, we need a different procedure, which would be more active and helpful.
I feel we became far to strict with the requirements to the contributors lately.
1. We do not want to educate anyone that does not ask for it 2. We do want to get as many contributions as possible, therefore it should be as easy as possible. 3. We need to beware of legal issues 4. We aim at having code of the best possible quality. 5. We do not want to break the tree.
Code reviews must protect us from issues with 3 and 5.
Shepherdship shall help us with 2 and 4.
Can we constitute this in the development guidelines?
Stefan
Stefan Reinauer wrote:
- ron minnich rminnich@gmail.com [071029 23:51]:
One possibility is, the next time someone comes in, rather than just critiquing the code, we get a group of people -- say 3 or 4 -- each of whom takes on the responsibility for a directory, starting at the leaves. Something like this:
superio (s) southbridge(s) northbridges(s) cpu
In addition: New components are undangerous to add as long as they are signed off and do not contain proprietary licensed code. We can just commit them before finding a shepherd - Nothing will break except the fresh code is maybe not working yet.
Completely agree!!!
The advantage is clear: Instead of keeping iterations of work on the vendor side while we waste our time on writing mails, we can spend the same time fixing the code ourselfes and take that burdon off the committers. Repeatedly asking for patches because of missing full stops and unsigned char -> uint8_t conversions is more effort than producing a stressful interface to potential committers. We need to become easier to handle in this way.
Again, agreed. If this were the linux kernel, the patches might be outright rejected over things like this. OTOH, we aren't the kernel, we don't have nearly the status nor the manpower.
once those are absorbed, we do the mainboard, and then, the target.
This is the 'shepherd' model.
I like this idea a lot. The shepherds are the extended and more work-directed versions of reviewers. (which should not go away)
This team would form dynamically and communicate (via the list?) on the changes that have to be made. But people would have to sign up for a given piece, and a deadline.
How would signing up work? We have a pretty active community with many people having something to contribute. Assigning tasks and duties and deadlines might very well scare people off that would have something valuable to say, otherwise. Therefore I believe we should handle this very casual.
I think we have some lurkers on the list who might be willing to step up and handle some of this ;) I know I barely have time to clean up my own code, let alone others.
But if we can't do better when someone like Morgan comes in, it's going to hurt us. I don't feel (me included) that we did what we needed to do. The 'code critique' approach works in some cases, but for those who need more assistance, we need a different procedure, which would be more active and helpful.
I feel we became far to strict with the requirements to the contributors lately.
I completely agree. However, I don't think requiring code in the form of a patch is too strict a requirement. But these endless reviews over trivial whitespace fixes, etc, get very annoying and very frustrating fast. These can be cleaned up later in the form of (much smaller!) patches.
- We do not want to educate anyone that does not ask for it
- We do want to get as many contributions as possible, therefore it should be as easy as possible.
- We need to beware of legal issues
- We aim at having code of the best possible quality.
- We do not want to break the tree.
Code reviews must protect us from issues with 3 and 5.
Shepherdship shall help us with 2 and 4.
Can we constitute this in the development guidelines?
Sounds like a good idea to me.
-Corey
can we try again then with morgan and sis?
The biggest issue was a concern with the licensing. We were a bit confused and never got a clear statement that SiS felt it was all gpl.
ron
* ron minnich rminnich@gmail.com [071030 02:56]:
can we try again then with morgan and sis?
The biggest issue was a concern with the licensing. We were a bit confused and never got a clear statement that SiS felt it was all gpl.
I did not check the VGA BIOS in yet. We are working on a different solution for that one.
All the source code had proper GPL licenses, and a lot of it is derived from other LinuxBIOS code, so it is safe to assume there is no licensing issue.
An important issue will be to get the code compiling. I was not successful doing so due to the old ld overlapping sections friend.
Patches welcome!
On 30/10/07 03:24 +0100, Stefan Reinauer wrote:
- ron minnich rminnich@gmail.com [071030 02:56]:
can we try again then with morgan and sis?
The biggest issue was a concern with the licensing. We were a bit confused and never got a clear statement that SiS felt it was all gpl.
I did not check the VGA BIOS in yet. We are working on a different solution for that one.
All the source code had proper GPL licenses, and a lot of it is derived from other LinuxBIOS code, so it is safe to assume there is no licensing issue.
An important issue will be to get the code compiling. I was not successful doing so due to the old ld overlapping sections friend.
Patches welcome!
I was working on a build when I went home - I'll finish it up tomorrow, and push buildrom too.
Jordan
On 30/10/07 03:24 +0100, Stefan Reinauer wrote:
An important issue will be to get the code compiling. I was not successful doing so due to the old ld overlapping sections friend.
We've seen this before - Whats happening here is that the ld script snippet for .id is going into the ld script after the snippet for .reset, so to LD, the current pointer appears to jump backwards, and it can't figure out the math correctly. The immediately work around is to re-arrange the order of the .id and the .reset snippets in the script. I believe this was fixed in later versions of ld - I can't get it to happen on my trusty Ubuntu Gutsy box.
Jordan
* Jordan Crouse jordan.crouse@amd.com [071030 18:03]:
On 30/10/07 03:24 +0100, Stefan Reinauer wrote:
An important issue will be to get the code compiling. I was not successful doing so due to the old ld overlapping sections friend.
We've seen this before - Whats happening here is that the ld script snippet for .id is going into the ld script after the snippet for .reset, so to LD, the current pointer appears to jump backwards, and it can't figure out the math correctly. The immediately work around is to re-arrange the order of the .id and the .reset snippets in the script. I believe this was fixed in later versions of ld - I can't get it to happen on my trusty Ubuntu Gutsy box.
What's your ld version?
here: GNU ld (GNU Binutils) 2.17.50.20070726-4 (SUSE Linux)
On 30/10/07 18:07 +0100, Stefan Reinauer wrote:
- Jordan Crouse jordan.crouse@amd.com [071030 18:03]:
On 30/10/07 03:24 +0100, Stefan Reinauer wrote:
An important issue will be to get the code compiling. I was not successful doing so due to the old ld overlapping sections friend.
We've seen this before - Whats happening here is that the ld script snippet for .id is going into the ld script after the snippet for .reset, so to LD, the current pointer appears to jump backwards, and it can't figure out the math correctly. The immediately work around is to re-arrange the order of the .id and the .reset snippets in the script. I believe this was fixed in later versions of ld - I can't get it to happen on my trusty Ubuntu Gutsy box.
What's your ld version?
here: GNU ld (GNU Binutils) 2.17.50.20070726-4 (SUSE Linux)
On the failing box: GNU ld version 2.17.50 20070103 Ubuntu
On the working box: GNU ld (GNU Binutils for Ubuntu) 2.18
-- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: info@coresystems.de • http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg • HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
On Tue, Oct 30, 2007 at 06:07:09PM +0100, Stefan Reinauer wrote:
- Jordan Crouse jordan.crouse@amd.com [071030 18:03]:
On 30/10/07 03:24 +0100, Stefan Reinauer wrote:
An important issue will be to get the code compiling. I was not successful doing so due to the old ld overlapping sections friend.
We've seen this before - Whats happening here is that the ld script snippet for .id is going into the ld script after the snippet for .reset, so to LD, the current pointer appears to jump backwards, and it can't figure out the math correctly. The immediately work around is to re-arrange the order of the .id and the .reset snippets in the script. I believe this was fixed in later versions of ld - I can't get it to happen on my trusty Ubuntu Gutsy box.
What's your ld version?
here: GNU ld (GNU Binutils) 2.17.50.20070726-4 (SUSE Linux)
FWIW, this is GNU ld (GNU Binutils for Debian) 2.18 and I can confirm that the build breaks for me too.
Uwe.
On 30/10/07 18:14 +0100, Uwe Hermann wrote:
On Tue, Oct 30, 2007 at 06:07:09PM +0100, Stefan Reinauer wrote:
- Jordan Crouse jordan.crouse@amd.com [071030 18:03]:
On 30/10/07 03:24 +0100, Stefan Reinauer wrote:
An important issue will be to get the code compiling. I was not successful doing so due to the old ld overlapping sections friend.
We've seen this before - Whats happening here is that the ld script snippet for .id is going into the ld script after the snippet for .reset, so to LD, the current pointer appears to jump backwards, and it can't figure out the math correctly. The immediately work around is to re-arrange the order of the .id and the .reset snippets in the script. I believe this was fixed in later versions of ld - I can't get it to happen on my trusty Ubuntu Gutsy box.
What's your ld version?
here: GNU ld (GNU Binutils) 2.17.50.20070726-4 (SUSE Linux)
FWIW, this is GNU ld (GNU Binutils for Debian) 2.18 and I can confirm that the build breaks for me too.
Doh! We've got silliness afoot. At least we know how to work around it.
Jordan
Jordan Crouse wrote:
On 30/10/07 18:14 +0100, Uwe Hermann wrote:
On Tue, Oct 30, 2007 at 06:07:09PM +0100, Stefan Reinauer wrote:
- Jordan Crouse jordan.crouse@amd.com [071030 18:03]:
On 30/10/07 03:24 +0100, Stefan Reinauer wrote:
An important issue will be to get the code compiling. I was not successful doing so due to the old ld overlapping sections friend.
We've seen this before - Whats happening here is that the ld script snippet for .id is going into the ld script after the snippet for .reset, so to LD, the current pointer appears to jump backwards, and it can't figure out the math correctly. The immediately work around is to re-arrange the order of the .id and the .reset snippets in the script. I believe this was fixed in later versions of ld - I can't get it to happen on my trusty Ubuntu Gutsy box.
What's your ld version?
here: GNU ld (GNU Binutils) 2.17.50.20070726-4 (SUSE Linux)
FWIW, this is GNU ld (GNU Binutils for Debian) 2.18 and I can confirm that the build breaks for me too.
Doh! We've got silliness afoot. At least we know how to work around it.
Jordan
Real silliness. Build is broken here with "GNU ld (GNU Binutils for Ubuntu) 2.18" o.O
-Corey
* Jordan Crouse jordan.crouse@amd.com [071030 18:03]:
We've seen this before - Whats happening here is that the ld script snippet for .id is going into the ld script after the snippet for .reset, so to LD, the current pointer appears to jump backwards, and it can't figure out the math correctly. The immediately work around is to re-arrange the order of the .id and the .reset snippets in the script. I believe this was fixed in later versions of ld - I can't get it to happen on my trusty Ubuntu Gutsy box.
Is it safe to permanently change this? Or will it break all the other boards?
On 30/10/07 18:07 +0100, Stefan Reinauer wrote:
- Jordan Crouse jordan.crouse@amd.com [071030 18:03]:
We've seen this before - Whats happening here is that the ld script snippet for .id is going into the ld script after the snippet for .reset, so to LD, the current pointer appears to jump backwards, and it can't figure out the math correctly. The immediately work around is to re-arrange the order of the .id and the .reset snippets in the script. I believe this was fixed in later versions of ld - I can't get it to happen on my trusty Ubuntu Gutsy box.
Is it safe to permanently change this? Or will it break all the other boards?
I think its safe to rearrange them - its more correct for humans to have the pointer always moving in a straight line anyway.
Jordan
On 10/30/07, Jordan Crouse jordan.crouse@amd.com wrote:
On 30/10/07 03:24 +0100, Stefan Reinauer wrote:
An important issue will be to get the code compiling. I was not successful doing so due to the old ld overlapping sections friend.
We've seen this before - Whats happening here is that the ld script snippet for .id is going into the ld script after the snippet for .reset, so to LD, the current pointer appears to jump backwards, and it can't figure out the math correctly. The immediately work around is to re-arrange the order of the .id and the .reset snippets in the script. I believe this was fixed in later versions of ld - I can't get it to happen on my trusty Ubuntu Gutsy box.
When I get this error, it is because my ROM_IMAGE_SIZE is set too small. Increasing it fixes the problem for me.
Myles
Jordan
-- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc.
-- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
On 11/1/07, Myles Watson myles@pel.cs.byu.edu wrote:
On 10/30/07, Jordan Crouse jordan.crouse@amd.com wrote:
On 30/10/07 03:24 +0100, Stefan Reinauer wrote:
An important issue will be to get the code compiling. I was not successful doing so due to the old ld overlapping sections friend.
We've seen this before - Whats happening here is that the ld script snippet for .id is going into the ld script after the snippet for .reset, so to LD, the current pointer appears to jump backwards, and it can't figure out the math correctly. The immediately work around is to re-arrange the order of the .id and the .reset snippets in the script. I believe this was fixed in later versions of ld - I can't get it to happen on my trusty Ubuntu Gutsy box.
When I get this error, it is because my ROM_IMAGE_SIZE is set too small. Increasing it fixes the problem for me.
It turns out none of these was the problem, for me, and I just figured it out this morning. Also, I am not totally convinced the .reset and .id section ordering in the ldscript is really a problem -- the start of each is pretty clearly laid out in the ldscript, and that code has been running that way for many years now. Were you folks seeing .reset and .id overlap, or .reset and .data? Do you have output I can see?
In my case I was getting overlapping sections of .reset and .data.
There should be no .data sections in the rom code. That's the first hint of trouble. A quick grep of .data in normal/cache_as_ram_auto.inc was enough to find the problem.
There are several u8 arrays in the sis southbridge early smbus code. This code is compiled into cache_as_ram_auto.c. Because it is not declared const, it gets passed through and compiled as a .data section. ld does not know where to put it, since the ldscript for the cache as ram code (ldscript.ld) only deals with .rom.text, .rom.data, and so on.
The fix is simple: declare the u8 arrays as const. This gets them passed in as rom.data, and all the conflicts on this board disappear. The board is building just fine for me now, and I have checked the last 16 bytes and can see the jump to the start of the rom code. In other words linuxbios.rom looks good.
I will test again tomorrow morning (or tonight, who knows) with Morgan's patches to 2925.
thanks
ron
On Sun, Oct 28, 2007 at 09:06:45AM -0700, ron minnich wrote:
Please don't ack just because noone else does it.
no, what I meant was, "I will do the review and try to make sure the patch is clean"
My bad. Sorry I did not give you more credit than that. :\
I was just very worried that we might have lost another board.
We can't lose the patch since it's on the list, but I agree we want to maintain good relations with all contributors.
//Peter
-
Corey Osgood -
Jordan Crouse -
Marc Jones -
Myles Watson -
Paul Menzel -
Peter Stuge -
ron minnich -
Rudolf Marek -
Stefan Reinauer -
Uwe Hermann -
yhlu