-----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 usb_debug that Greg just added with
console=ttyUSB0 to get tty? Then you still need to disable that
early_console sometime later.
YH
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 make console can take command?
>
> Or transfer to generic usb_serial
I think the protocols are incompatible?
> 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.
However I see a certain advantage to keep using the early
usb console because it doesn't need any interrupts. So when the
kernel is very confused after an oops it might have a higher
chance to still get the oops out.
I haven't looked how the other usb_debug works -- if it's polled
too then it wouldn't have much advantage.
Ok one advantage of a non early usb_debug is that it will properly use pci
config space locking. The early implementation just ignores the port cf8
lock which might lead to corruption later. That's ok after
an oops, but during normal output it can actually lead to
data corruption if it interferes with somebody else's config write.
Also on some systems cf8 is broken and doesn't work.
Disadvantage of using the locks of course is that it can deadlock
if an oops happen inside the critical region. So they might need
to be added to bust_spinlocks()
And it would be good if the late usb_debug still wouldn't rely
on interrupts.
But I agree it's probably better to transition to another usb_debug
console and not do keep by default.
-Andi
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 duplicated.
>>
>> Still need to tx_read to make console can take command?
>>
>> Or transfer to generic usb_serial
>
> I think the protocols are incompatible?
>
>> 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.
>
> However I see a certain advantage to keep using the early
> usb console because it doesn't need any interrupts. So when the
> kernel is very confused after an oops it might have a higher
> chance to still get the oops out.
>
> I haven't looked how the other usb_debug works -- if it's polled
> too then it wouldn't have much advantage.
>
> Ok one advantage of a non early usb_debug is that it will properly use pci
> config space locking. The early implementation just ignores the port cf8
> lock which might lead to corruption later. That's ok after
> an oops, but during normal output it can actually lead to
> data corruption if it interferes with somebody else's config write.
> Also on some systems cf8 is broken and doesn't work.
>
> Disadvantage of using the locks of course is that it can deadlock
> if an oops happen inside the critical region. So they might need
> to be added to bust_spinlocks()
>
> And it would be good if the late usb_debug still wouldn't rely
> on interrupts.
>
> But I agree it's probably better to transition to another usb_debug
> console and not do keep by default.
The only use of the early pci code is for finding the hardware. Everything
else is through mmio.
The practical issue is that during the normal initialization of the ehci
the reset of the hardware state is going to remove the delegation to the
ehci debug registers.
Greg's current thing uses the hardware but through the normal interrupt
driven usb methods. I think it is worth using the ehci debug registers
if possible as that (except for reset) gives us independent control of
what is going on.
For understanding what needs to happen except for the initialization just
look at my dbgp_bulk_write routine. That and the functions it call is
the only code in there that is executed. It is just a hair more complicated
than other early debug port code because it has to deal with retransmits.
But I think it is still under 100 lines of code.
Eric
> > 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 up to the debug device;
runs this _new_ "early debug port" code.
- Host, to which that console connects (through the debug device);
runs usb_debug, much like any other usb-serial device
It's analagous to debugging an embedded box using a serial console
with a Linux host ... except the target here is a PC, not an ARM
(or PPC, MIPS, etc) custom board.
Once the coexistence issues between the debug port and normal EHCI
driver get worked, there's no reason not to keep using that debug
port as a system console. Heck, being able to do that might be a
huge win with some of the nasty suspend/resume problems we've got.
- Dave
\
> - 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 Linux host ... except the target here is a PC, not an ARM
> (or PPC, MIPS, etc) custom board.
>
>
> Once the coexistence issues between the debug port and normal EHCI
> driver get worked, there's no reason not to keep using that debug
> port as a system console.
One reason is the one I covered in my last mail -- locking of the PCI
type 1 ports.
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()
-Andi
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 greg's patch.
I still need to try it though.
> One reason is the one I covered in my last mail -- locking of the PCI
> type 1 ports.
>
> 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.
Eric
> > 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
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, if you didn't want to use it like a normal
serial consoe.
> > It's analagous to debugging an embedded box using a serial console
> > with a Linux host ... except the target here is a PC, not an ARM
> > (or PPC, MIPS, etc) custom board.
> >
> >
> > Once the coexistence issues between the debug port and normal EHCI
> > driver get worked, there's no reason not to keep using that debug
> > port as a system console.
>
> One reason is the one I covered in my last mail -- locking of the PCI
> type 1 ports.
That'd be part of coexistence. The debug port is _designed_ to share
two different drivers like that ... EHCI can see, as it comes up,
whether the debug port is in use, and could then ignore it. (At least,
unless/until the debug device gets removed.)
- Dave