wakeup_level4_pgt need to be updated in addtion to boot_level4_pgt?
also comment could be updated for good unstanding too.
YH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On 12/12/06, Eric W. Biederman <[EMAIL PROTECTED]> 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
On 12/12/06, Eric W. Biederman [EMAIL PROTECTED] 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
wakeup_level4_pgt need to be updated in addtion to boot_level4_pgt?
also comment could be updated for good unstanding too.
YH
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
"Yinghai Lu" <[EMAIL PROTECTED]> writes:
> On 12/8/06, Eric W. Biederman <[EMAIL PROTECTED]> 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
On 12/8/06, Eric W. Biederman <[EMAIL PROTECTED]> 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
On 12/8/06, Eric W. Biederman [EMAIL PROTECTED] 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
Yinghai Lu [EMAIL PROTECTED] writes:
On 12/8/06, Eric W. Biederman [EMAIL PROTECTED] 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
On Fri, Dec 08, 2006 at 07:16:09PM -0800, Lu, Yinghai wrote:
> It works in LinuxBIOS now.
Cool, can't wait to try it out.
Good work!
//Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Fri, Dec 08, 2006 at 07:16:09PM -0800, Lu, Yinghai wrote:
It works in LinuxBIOS now.
Cool, can't wait to try it out.
Good work!
//Peter
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 07, 2006 11:42 PM
>> With Eric code in LinuxBIOS, it will report "No device found in debug
>> port"
>Hmm. At least this is partial progress :)
It works in LinuxBIOS now. It will loop all
"Yinghai Lu" <[EMAIL PROTECTED]> writes:
> On 12/7/06, Eric W. Biederman <[EMAIL PROTECTED]> 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
On 12/7/06, Eric W. Biederman <[EMAIL PROTECTED]> 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
-
To unsubscribe
On 12/7/06, Greg KH <[EMAIL PROTECTED]> 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
On 12/7/06, Greg KH [EMAIL PROTECTED] 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
On 12/7/06, Eric W. Biederman [EMAIL PROTECTED] 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
-
To unsubscribe
Yinghai Lu [EMAIL PROTECTED] writes:
On 12/7/06, Eric W. Biederman [EMAIL PROTECTED] 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
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 07, 2006 11:42 PM
With Eric code in LinuxBIOS, it will report No device found in debug
port
Hmm. At least this is partial progress :)
It works in LinuxBIOS now. It will loop all connected
"Lu, Yinghai" <[EMAIL PROTECTED]> writes:
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> [EMAIL PROTECTED]
>
>
>>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
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
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
>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
Two side are identical if two side are connected.
YH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Wed, Dec 06, 2006 at 01:08:14PM -0800, Lu, Yinghai wrote:
> -Original Message-
> From: Andi Kleen [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 06, 2006 12:59 PM
>
> >I haven't looked how the other usb_debug works -- if it's polled
> >too then it wouldn't have much advantage.
On Wed, Dec 06, 2006 at 01:08:14PM -0800, Lu, Yinghai wrote:
-Original Message-
From: Andi Kleen [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 06, 2006 12:59 PM
I haven't looked how the other usb_debug works -- if it's polled
too then it wouldn't have much advantage.
Need
Two side are identical if two side are connected.
YH
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
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
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
Lu, Yinghai [EMAIL PROTECTED] writes:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
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
On Wednesday 06 December 2006 1:24 pm, Andi Kleen wrote:
> > - Host, to which that console connects (through the debug device);
> > runs usb_debug, much like any other usb-serial device
>
> My understanding was that the client could run in user
> space only on top of libusb.
I suppose it
> > However I suppose it would be ok to switch Eric's code between early
> > pci access and locked one once the PCI subsystem is up and running.
> > Just don't forget bust_spinlocks()
>
> No pci access on that path.
Hmm good point. Ok ignore that then.
keep should be default then.
-Andi
-
To
Andi Kleen <[EMAIL PROTECTED]> writes:
> \
>> - Host, to which that console connects (through the debug device);
>> runs usb_debug, much like any other usb-serial device
>
> My understanding was that the client could run in user
> space only on top of libusb.
Looks like a normal serial
\
> - Host, to which that console connects (through the debug device);
> runs usb_debug, much like any other usb-serial device
My understanding was that the client could run in user
space only on top of libusb.
>
> It's analagous to debugging an embedded box using a serial console
> with
> > or usb_debug that Greg just added
>
> Ah I didn't notice that. If there is a usb_debug that works later
> then yes it would need to be disabled.
I detect confusion here ... remember that there are potentially two
distinct Linux systems involved here:
- Target, with some kind of console
Andi Kleen <[EMAIL PROTECTED]> writes:
> On Wednesday 06 December 2006 21:43, Lu, Yinghai wrote:
>> -Original Message-
>> From: Andi Kleen [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, December 06, 2006 9:31 AM
>>
>> >Also for usb console keep should be made default because the output
-Original Message-
From: Andi Kleen [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 06, 2006 12:59 PM
>I haven't looked how the other usb_debug works -- if it's polled
>too then it wouldn't have much advantage.
Need to verify if the two sides of debug cable are identical.
>And it
On Wednesday 06 December 2006 21:43, Lu, Yinghai wrote:
> -Original Message-
> From: Andi Kleen [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 06, 2006 9:31 AM
>
> >Also for usb console keep should be made default because the output
> won't
> >be duplicated.
>
> Still need to
-Original Message-
From: Andi Kleen [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 06, 2006 9:31 AM
>Also for usb console keep should be made default because the output
won't
>be duplicated.
Still need to tx_read to make console can take command?
Or transfer to generic usb_serial
On Tuesday 05 December 2006 12:01, Eric W. Biederman wrote:
>
> 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
>
What do you mean by
+ for (reps = 0; reps >= 0; reps++) {
?
If you will not reps is negative. Roughly it is a loop
that will timeout eventually if a usb debug cable is not present.
So since I didn't know how many loop iterations made sense I allowed
it to loop for 2^31 times or until
What do you mean by
+ for (reps = 0; reps = 0; reps++) {
?
If you will not reps is negative. Roughly it is a loop
that will timeout eventually if a usb debug cable is not present.
So since I didn't know how many loop iterations made sense I allowed
it to loop for 2^31 times or until
On Tuesday 05 December 2006 12:01, Eric W. Biederman wrote:
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
-Original Message-
From: Andi Kleen [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 06, 2006 9:31 AM
Also for usb console keep should be made default because the output
won't
be duplicated.
Still need to tx_read to make console can take command?
Or transfer to generic usb_serial or
On Wednesday 06 December 2006 21:43, Lu, Yinghai wrote:
-Original Message-
From: Andi Kleen [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 06, 2006 9:31 AM
Also for usb console keep should be made default because the output
won't
be duplicated.
Still need to tx_read to
-Original Message-
From: Andi Kleen [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 06, 2006 12:59 PM
I haven't looked how the other usb_debug works -- if it's polled
too then it wouldn't have much advantage.
Need to verify if the two sides of debug cable are identical.
And it
Andi Kleen [EMAIL PROTECTED] writes:
On Wednesday 06 December 2006 21:43, Lu, Yinghai wrote:
-Original Message-
From: Andi Kleen [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 06, 2006 9:31 AM
Also for usb console keep should be made default because the output
won't
be
or usb_debug that Greg just added
Ah I didn't notice that. If there is a usb_debug that works later
then yes it would need to be disabled.
I detect confusion here ... remember that there are potentially two
distinct Linux systems involved here:
- Target, with some kind of console hooked
\
- Host, to which that console connects (through the debug device);
runs usb_debug, much like any other usb-serial device
My understanding was that the client could run in user
space only on top of libusb.
It's analagous to debugging an embedded box using a serial console
with a
Andi Kleen [EMAIL PROTECTED] writes:
\
- Host, to which that console connects (through the debug device);
runs usb_debug, much like any other usb-serial device
My understanding was that the client could run in user
space only on top of libusb.
Looks like a normal serial port with
However I suppose it would be ok to switch Eric's code between early
pci access and locked one once the PCI subsystem is up and running.
Just don't forget bust_spinlocks()
No pci access on that path.
Hmm good point. Ok ignore that then.
keep should be default then.
-Andi
-
To
On Wednesday 06 December 2006 1:24 pm, Andi Kleen wrote:
- Host, to which that console connects (through the debug device);
runs usb_debug, much like any other usb-serial device
My understanding was that the client could run in user
space only on top of libusb.
I suppose it could,
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 05, 2006 3:50 PM
>If you will not reps is negative. Roughly it is a loop
>that will timeout eventually if a usb debug cable is not present.
>Putting some deliberate delays in there so I could
"Lu, Yinghai" <[EMAIL PROTECTED]> writes:
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> [EMAIL PROTECTED]
> Sent: Tuesday, December 05, 2006 3:01 AM
>
>>+static int ehci_wait_for_port(int port)
>>+{
>>+ unsigned status;
>>+ int ret,
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Tuesday, December 05, 2006 3:01 AM
>+static int ehci_wait_for_port(int port)
>+{
>+ unsigned status;
>+ int ret, reps;
>+ for (reps = 0; reps >= 0; reps++) {
>+
David Brownell <[EMAIL PROTECTED]> writes:
> On Sunday 03 December 2006 9:09 pm, Eric W. Biederman wrote:
>>
>> My driver should be sufficient to work with any EHCI in a realatively
>> clean state, and needs no special BIOS support just the hardware.
>> This appears to be different than the way
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.
Eric
arch/i386/kernel/head.S |8 +
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.
Eric
arch/i386/kernel/head.S |8 +
David Brownell [EMAIL PROTECTED] writes:
On Sunday 03 December 2006 9:09 pm, Eric W. Biederman wrote:
My driver should be sufficient to work with any EHCI in a realatively
clean state, and needs no special BIOS support just the hardware.
This appears to be different than the way the windows
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Tuesday, December 05, 2006 3:01 AM
+static int ehci_wait_for_port(int port)
+{
+ unsigned status;
+ int ret, reps;
+ for (reps = 0; reps = 0; reps++) {
+
Lu, Yinghai [EMAIL PROTECTED] writes:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Tuesday, December 05, 2006 3:01 AM
+static int ehci_wait_for_port(int port)
+{
+ unsigned status;
+ int ret, reps;
+ for (reps
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 05, 2006 3:50 PM
If you will not reps is negative. Roughly it is a loop
that will timeout eventually if a usb debug cable is not present.
Putting some deliberate delays in there so I could be
60 matches
Mail list logo
