From: Andi Kleen <ak@suse.de>
To: "Lu, Yinghai" <yinghai.lu@amd.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
"David Brownell" <david-b@pacbell.net>,
linux-usb-devel@lists.sourceforge.net,
"Peter Stuge" <stuge-linuxbios@cdy.org>,
"Stefan Reinauer" <stepan@coresystems.de>,
"Greg KH" <gregkh@suse.de>,
linux-kernel@vger.kernel.org, linuxbios@linuxbios.org
Subject: Re: [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
Date: Wed, 6 Dec 2006 21:58:39 +0100 [thread overview]
Message-ID: <200612062158.39250.ak@suse.de> (raw)
In-Reply-To: <5986589C150B2F49A46483AC44C7BCA4907290@ssvlexmb2.amd.com>
On Wednesday 06 December 2006 21:43, Lu, Yinghai wrote:
> -----Original Message-----
> From: Andi Kleen [mailto:ak@suse.de]
> 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
next prev parent reply other threads:[~2006-12-06 20:58 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-06 20:43 [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support Lu, Yinghai
2006-12-06 20:58 ` Andi Kleen [this message]
2006-12-06 21:12 ` Eric W. Biederman
2006-12-06 21:17 ` David Brownell
2006-12-06 21:24 ` Andi Kleen
2006-12-06 21:37 ` Eric W. Biederman
2006-12-06 21:59 ` Andi Kleen
2006-12-06 23:47 ` David Brownell
-- strict thread matches above, loose matches on Subject: below --
2006-12-06 21:08 Lu, Yinghai
2006-12-01 18:55 [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device Lu, Yinghai
2006-12-03 15:49 ` Eric W. Biederman
2006-12-04 5:09 ` [RFC][PATCH 0/2] x86_64 Early usb debug port support Eric W. Biederman
[not found] ` <200612042001.09808.david-b@pacbell.net>
2006-12-05 11:01 ` [linux-usb-devel] " Eric W. Biederman
2006-12-06 17:31 ` Andi Kleen
2006-12-05 11:18 ` Eric W. Biederman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200612062158.39250.ak@suse.de \
--to=ak@suse.de \
--cc=david-b@pacbell.net \
--cc=ebiederm@xmission.com \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=linuxbios@linuxbios.org \
--cc=stepan@coresystems.de \
--cc=stuge-linuxbios@cdy.org \
--cc=yinghai.lu@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox