-----Original Message----- From: linuxbios-bounces@linuxbios.org [mailto:linuxbios-bounces@linuxbios.org] On Behalf Of ebiederm@xmission.com
Ok due to popular demands here is the slightly fixed patch that works on both i386 and x86_64. For the i386 version you must not have HIGHMEM64G enabled.
I just rolled it all into one patch as I'm to lazy to transmit all 3 of them.
I got
Firmware type: LinuxBIOS Linux version 2.6.19-smp-gc9976797-dirty (root@lbsrv) (gcc version 4.0.2) #196 6 Command line: earlyprintk=ttyS0,115200 apic=debug pci=noacpi,routeirq snd-hda-i BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 0000000000001000 (reserved) BIOS-e820: 0000000000001000 - 00000000000a0000 (usable) BIOS-e820: 00000000000c0000 - 00000000000f0000 (usable) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 00000000c0000000 (usable) BIOS-e820: 0000000100000000 - 0000000240000000 (usable) dbgp_num: 0 Found EHCI debug port bar: 10 offset: 098 bar: 10 offset: 098 dbgp pre-set_fixmap_nocache PANIC: early exception rip ffffffff809c24b4 error 0 cr2 ffff810000203ff8
Call Trace: [<ffffffff809c24b4>] __set_fixmap+0x84/0x202 [<ffffffff809c05bb>] early_dbgp_init+0x259/0x55c [<ffffffff8022d958>] __call_console_drivers+0x64/0x72 [<ffffffff809b242b>] do_early_param+0x0/0x57 [<ffffffff809c0a20>] setup_early_printk+0x162/0x17e [<ffffffff809b2459>] do_early_param+0x2e/0x57 [<ffffffff8023d051>] parse_args+0x159/0x1f3 [<ffffffff809b24c2>] parse_early_param+0x40/0x4c [<ffffffff809b88ca>] setup_arch+0x1c1/0x636 [<ffffffff809b2534>] start_kernel+0x55/0x208 [<ffffffff809b2173>] _sinittext+0x173/0x177
RIP __set_fixmap+0x84/0x202
With Greg's USB Debug, host and target can talk. target with console=ttyUSB0,115200n8 host with cat /dev/ttyUSB0 But if use minicom in host, it will not show '\r', I guess the usb debug cable eat return char. Greg, Can you add that back in usb_debug by replacing '\n' with '\r', '\n'?
With Eric code in LinuxBIOS, it will report "No device found in debug port"
YH
On Thu, Dec 07, 2006 at 07:48:17PM -0800, Lu, Yinghai wrote:
With Greg's USB Debug, host and target can talk. target with console=ttyUSB0,115200n8
Ugh, no, never use the usb-serial driver as a console device.
That was a bad hack done as a bet many years ago. For many obvious reasons it does not work well.
host with cat /dev/ttyUSB0 But if use minicom in host, it will not show '\r', I guess the usb debug cable eat return char. Greg, Can you add that back in usb_debug by replacing '\n' with '\r', '\n'?
The usb-serial console code should handle this, I thought we fixed it a while ago.
But this kind of interface is not what these devices are good for. They are for the debug port information, not as a usb-serial console device. Otherwise they are way too expensive of a device...
thanks,
greg k-h
On 12/7/06, Greg KH gregkh@suse.de wrote:
Ugh, no, never use the usb-serial driver as a console device.
That was a bad hack done as a bet many years ago. For many obvious reasons it does not work well.
understood, I found with usb_serial convertor could lose some chatacter. but the usb-debug cable seem it keep all character.
host with cat /dev/ttyUSB0 But if use minicom in host, it will not show '\r', I guess the usb debug cable eat return char. Greg, Can you add that back in usb_debug by replacing '\n' with '\r', '\n'?
The usb-serial console code should handle this, I thought we fixed it a while ago.
Is it in the git tree?
But this kind of interface is not what these devices are good for. They are for the debug port information, not as a usb-serial console device. Otherwise they are way too expensive of a device...
the problem is some "modern" PC will left out serial port. then the cable could get cheap.
YH
"Lu, Yinghai" yinghai.lu@amd.com writes:
-----Original Message----- From: linuxbios-bounces@linuxbios.org [mailto:linuxbios-bounces@linuxbios.org] On Behalf Of ebiederm@xmission.com
Ok due to popular demands here is the slightly fixed patch that works on both i386 and x86_64. For the i386 version you must not have HIGHMEM64G enabled.
I just rolled it all into one patch as I'm to lazy to transmit all 3 of them.
I got
Firmware type: LinuxBIOS Linux version 2.6.19-smp-gc9976797-dirty (root@lbsrv) (gcc version 4.0.2) #196 6 Command line: earlyprintk=ttyS0,115200 apic=debug pci=noacpi,routeirq snd-hda-i BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 0000000000001000 (reserved) BIOS-e820: 0000000000001000 - 00000000000a0000 (usable) BIOS-e820: 00000000000c0000 - 00000000000f0000 (usable) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 00000000c0000000 (usable) BIOS-e820: 0000000100000000 - 0000000240000000 (usable) dbgp_num: 0 Found EHCI debug port bar: 10 offset: 098 bar: 10 offset: 098 dbgp pre-set_fixmap_nocache PANIC: early exception rip ffffffff809c24b4 error 0 cr2 ffff810000203ff8
Call Trace: [<ffffffff809c24b4>] __set_fixmap+0x84/0x202 [<ffffffff809c05bb>] early_dbgp_init+0x259/0x55c [<ffffffff8022d958>] __call_console_drivers+0x64/0x72 [<ffffffff809b242b>] do_early_param+0x0/0x57 [<ffffffff809c0a20>] setup_early_printk+0x162/0x17e [<ffffffff809b2459>] do_early_param+0x2e/0x57 [<ffffffff8023d051>] parse_args+0x159/0x1f3 [<ffffffff809b24c2>] parse_early_param+0x40/0x4c [<ffffffff809b88ca>] setup_arch+0x1c1/0x636 [<ffffffff809b2534>] start_kernel+0x55/0x208 [<ffffffff809b2173>] _sinittext+0x173/0x177
RIP __set_fixmap+0x84/0x202
Ugh. I'd check the code. But it looks like my tweak to the early fixmap code. But my hunch is that my tweak to __fixmap so that it's pud and pmd were prepopulated didn't take on your build.
With Eric code in LinuxBIOS, it will report "No device found in debug port"
Hmm. At least this is partial progress :)
Eric
On 12/7/06, Eric W. Biederman ebiederm@xmission.com wrote:
Ugh. I'd check the code. But it looks like my tweak to the early fixmap code. But my hunch is that my tweak to __fixmap so that it's pud and pmd were prepopulated didn't take on your build.
I missed some options?
YH
"Yinghai Lu" yinghai.lu@amd.com writes:
On 12/7/06, Eric W. Biederman ebiederm@xmission.com wrote:
Ugh. I'd check the code. But it looks like my tweak to the early fixmap code. But my hunch is that my tweak to __fixmap so that it's pud and pmd were prepopulated didn't take on your build.
I missed some options?
Your or I missed a bug fix/enhancement in there somewhere.
Basically my very early setup of the fixmap failed. Now. I thought I had that covered by preallocated the pud and the pmd entries. So the only thing missing was the pte entries.
If that is not a big enough hint I will look into it in a bit...
I'm starting to become a big fan of constant initializers. So our core subsystems don't need initialization code to be useful. All of these early things are just a pain.
Eric
On 12/8/06, Eric W. Biederman ebiederm@xmission.com wrote:
Your or I missed a bug fix/enhancement in there somewhere.
I found the problem. the __set_fixmap need to __va, so the entries will be referred from PAGE_OFFSET.
solution will be 1. move enable_dbgp_console from setup_early_printk, and call it from setup_arch after init_memory_mapping. 2. or make __set_fixmap can use __pa or pa()+__START_KERNEL_map in addtion to _va.
please check attached updated patch that is your patch plus 1.
YH
"Yinghai Lu" yinghai.lu@amd.com writes:
On 12/8/06, Eric W. Biederman ebiederm@xmission.com wrote:
Your or I missed a bug fix/enhancement in there somewhere.
I found the problem. the __set_fixmap need to __va, so the entries will be referred from PAGE_OFFSET.
solution will be
- move enable_dbgp_console from setup_early_printk, and call it from
setup_arch after init_memory_mapping. 2. or make __set_fixmap can use __pa or pa()+__START_KERNEL_map in addtion to _va.
3. Make __va always work. I had this in my tree and I guess it didn't get into my big rollup patch.
Eric
x86_64: Fix the memory mapping in the early page table
diff --git a/arch/x86_64/kernel/head.S b/arch/x86_64/kernel/head.S index 1e6f808..2f65469 100644 --- a/arch/x86_64/kernel/head.S +++ b/arch/x86_64/kernel/head.S @@ -328,9 +328,9 @@ ENTRY(wakeup_level4_pgt) .align PAGE_SIZE ENTRY(boot_level4_pgt) .quad phys_level3_ident_pgt | 0x007 - .fill 255,8,0 + .fill 257,8,0 .quad phys_level3_physmem_pgt | 0x007 - .fill 254,8,0 + .fill 252,8,0 /* (2^48-(2*1024*1024*1024))/(2^39) = 511 */ .quad phys_level3_kernel_pgt | 0x007
On 12/12/06, Eric W. Biederman ebiederm@xmission.com wrote:
diff --git a/arch/x86_64/kernel/head.S b/arch/x86_64/kernel/head.S index 1e6f808..2f65469 100644 --- a/arch/x86_64/kernel/head.S +++ b/arch/x86_64/kernel/head.S @@ -328,9 +328,9 @@ ENTRY(wakeup_level4_pgt) .align PAGE_SIZE ENTRY(boot_level4_pgt) .quad phys_level3_ident_pgt | 0x007
.fill 255,8,0
.fill 257,8,0 .quad phys_level3_physmem_pgt | 0x007
.fill 254,8,0
.fill 252,8,0 /* (2^48-(2*1024*1024*1024))/(2^39) = 511 */ .quad phys_level3_kernel_pgt | 0x007
Good, it seems __PAGE_OFFSET used to be 0xfff800000000000 and then 1<<40, and then 0xfff810000000000
YH
wakeup_level4_pgt need to be updated in addtion to boot_level4_pgt?
also comment could be updated for good unstanding too.
YH
-
ebiederm＠xmission.com -
Greg KH -
Lu, Yinghai -
Yinghai Lu