* Re: [RFC PATCH] poll(): add poll_wait_set_exclusive()
From: Steven Rostedt @ 2010-10-07 20:44 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: Linus Torvalds, LKML, Andrew Morton, Peter Zijlstra, Ingo Molnar,
Frederic Weisbecker, Thomas Gleixner, Christoph Hellwig, Li Zefan,
Lai Jiangshan, Johannes Berg, Masami Hiramatsu,
Arnaldo Carvalho de Melo, Tom Zanussi, KOSAKI Motohiro,
Andi Kleen, Paul E. McKenney
In-Reply-To: <20101007180737.GA4300@Krystal>
On Thu, 2010-10-07 at 14:07 -0400, Mathieu Desnoyers wrote:
> * Steven Rostedt (rostedt@goodmis.org) wrote:
> > I never mention affinity. As with trace-cmd, it assigns a process per
> > CPU, but those processes can be on any CPU that the scheduler chooses. I
> > could probably do it with a single process reading all the CPU fds too.
> > I might add that as an option.
>
> Your scheme works fine because you have only one stream (and thus one fd) per
> cpu. How would you map that with many streams per cpu ?
>
> Also, you might want to consider using threads rather than processes, to save
> the unnecessary VM swaps.
I thought about threads and could go back to them. I'd have to benchmark
to see the performance hit.
>
> >
> > >
> > > > Or do you have an fd per event per CPU, in which case the threads should just
> > > > poll off of their own fds.
> > >
> > > I have one fd per per-cpu buffer, but there can be many per-cpu buffers, each
> > > transporting a group of events. Therefore, I don't want to associate one thread
> > > per event group, because this would be a resource waste. Typically, only a few
> > > per-cpu buffers will be very active, and others will be very quiet.
> >
> > Lets not talk about threads, what about fds? I'm wondering why you have
> > many threads on the same fd?
>
> That's because I have fewer threads than file descriptors. So I can choose to
> either:
>
> 1) somehow assign each thread to many fds statically or
> 2) make each thread wait for data on all fds
>
> Option (2) adapts much better to workloads where a lots of data would come from
> many file descriptors from a single CPU: all threads can collaboratively work to
> extract the data.
OK, this is what I wanted to know. Now as Linus suggested, go and ask
other application developers (web server developers?) if this is
something that could be useful for them? If you get positive feedback,
have them Cc LKML and we can go from there.
Or, if you see that this type of programming is being done in Apache,
and if you can demonstrate that adding this features helps Apache (or
some other popular program), that would also be of benefit.
-- Steve
^ permalink raw reply
* [PATCH net-next] neigh: speedup neigh_resolve_output()
From: Eric Dumazet @ 2010-10-07 20:44 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <1286456008.2912.171.camel@edumazet-laptop>
Le jeudi 07 octobre 2010 à 14:53 +0200, Eric Dumazet a écrit :
> Further improvements would need to use a seqlock instead of an rwlock to
> protect neigh->ha[], to not dirty neigh too often and remove two atomic
> ops.
>
I implemented this idea in following patch, on top on previous one.
[PATCH net-next] neigh: speedup neigh_resolve_output()
Add a seqlock in struct neighbour to protect neigh->ha[], and avoid
dirtying neighbour in stress situation (many different flows / dsts)
Dirtying takes place because of read_lock(&n->lock) and n->used writes.
Switching to a seqlock, and writing n->used only on jiffies changes
permits less dirtying.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
include/net/neighbour.h | 16 ++++++++++++
net/core/neighbour.c | 47 ++++++++++++++++++++++++--------------
net/ipv4/arp.c | 6 +---
net/sched/sch_teql.c | 8 +++---
4 files changed, 51 insertions(+), 26 deletions(-)
diff --git a/include/net/neighbour.h b/include/net/neighbour.h
index a4538d5..f04e7a2 100644
--- a/include/net/neighbour.h
+++ b/include/net/neighbour.h
@@ -105,6 +105,7 @@ struct neighbour {
atomic_t refcnt;
atomic_t probes;
rwlock_t lock;
+ seqlock_t ha_lock;
unsigned char ha[ALIGN(MAX_ADDR_LEN, sizeof(unsigned long))];
struct hh_cache *hh;
int (*output)(struct sk_buff *skb);
@@ -302,7 +303,10 @@ static inline void neigh_confirm(struct neighbour *neigh)
static inline int neigh_event_send(struct neighbour *neigh, struct sk_buff *skb)
{
- neigh->used = jiffies;
+ unsigned long now = ACCESS_ONCE(jiffies);
+
+ if (neigh->used != now)
+ neigh->used = now;
if (!(neigh->nud_state&(NUD_CONNECTED|NUD_DELAY|NUD_PROBE)))
return __neigh_event_send(neigh, skb);
return 0;
@@ -373,4 +377,14 @@ struct neighbour_cb {
#define NEIGH_CB(skb) ((struct neighbour_cb *)(skb)->cb)
+static inline void neigh_ha_snapshot(char *dst, const struct neighbour *n,
+ const struct net_device *dev)
+{
+ unsigned int seq;
+
+ do {
+ seq = read_seqbegin(&n->ha_lock);
+ memcpy(dst, n->ha, dev->addr_len);
+ } while (read_seqretry(&n->ha_lock, seq));
+}
#endif
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 53cc548..54aef9c 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -294,6 +294,7 @@ static struct neighbour *neigh_alloc(struct neigh_table *tbl)
skb_queue_head_init(&n->arp_queue);
rwlock_init(&n->lock);
+ seqlock_init(&n->ha_lock);
n->updated = n->used = now;
n->nud_state = NUD_NONE;
n->output = neigh_blackhole;
@@ -1015,7 +1016,7 @@ out_unlock_bh:
}
EXPORT_SYMBOL(__neigh_event_send);
-static void neigh_update_hhs(struct neighbour *neigh)
+static void neigh_update_hhs(const struct neighbour *neigh)
{
struct hh_cache *hh;
void (*update)(struct hh_cache*, const struct net_device*, const unsigned char *)
@@ -1151,7 +1152,9 @@ int neigh_update(struct neighbour *neigh, const u8 *lladdr, u8 new,
}
if (lladdr != neigh->ha) {
+ write_seqlock(&neigh->ha_lock);
memcpy(&neigh->ha, lladdr, dev->addr_len);
+ write_sequnlock(&neigh->ha_lock);
neigh_update_hhs(neigh);
if (!(new & NUD_CONNECTED))
neigh->confirmed = jiffies -
@@ -1214,6 +1217,7 @@ static inline bool neigh_hh_lookup(struct neighbour *n, struct dst_entry *dst,
{
struct hh_cache *hh;
+ smp_rmb(); /* paired with smp_wmb() in neigh_hh_init() */
for (hh = n->hh; hh; hh = hh->hh_next) {
if (hh->hh_type == protocol) {
atomic_inc(&hh->hh_refcnt);
@@ -1248,8 +1252,8 @@ static void neigh_hh_init(struct neighbour *n, struct dst_entry *dst,
kfree(hh);
return;
}
- read_unlock(&n->lock);
- write_lock(&n->lock);
+
+ write_lock_bh(&n->lock);
/* must check if another thread already did the insert */
if (neigh_hh_lookup(n, dst, protocol)) {
@@ -1263,13 +1267,13 @@ static void neigh_hh_init(struct neighbour *n, struct dst_entry *dst,
hh->hh_output = n->ops->output;
hh->hh_next = n->hh;
+ smp_wmb(); /* paired with smp_rmb() in neigh_hh_lookup() */
n->hh = hh;
if (unlikely(cmpxchg(&dst->hh, NULL, hh) != NULL))
hh_cache_put(hh);
end:
- write_unlock(&n->lock);
- read_lock(&n->lock);
+ write_unlock_bh(&n->lock);
}
/* This function can be used in contexts, where only old dev_queue_xmit
@@ -1308,16 +1312,18 @@ int neigh_resolve_output(struct sk_buff *skb)
if (!neigh_event_send(neigh, skb)) {
int err;
struct net_device *dev = neigh->dev;
+ unsigned int seq;
- read_lock_bh(&neigh->lock);
if (dev->header_ops->cache &&
!dst->hh &&
!(dst->flags & DST_NOCACHE))
neigh_hh_init(neigh, dst, dst->ops->protocol);
- err = dev_hard_header(skb, dev, ntohs(skb->protocol),
- neigh->ha, NULL, skb->len);
- read_unlock_bh(&neigh->lock);
+ do {
+ seq = read_seqbegin(&neigh->ha_lock);
+ err = dev_hard_header(skb, dev, ntohs(skb->protocol),
+ neigh->ha, NULL, skb->len);
+ } while (read_seqretry(&neigh->ha_lock, seq));
if (err >= 0)
rc = neigh->ops->queue_xmit(skb);
@@ -1344,13 +1350,16 @@ int neigh_connected_output(struct sk_buff *skb)
struct dst_entry *dst = skb_dst(skb);
struct neighbour *neigh = dst->neighbour;
struct net_device *dev = neigh->dev;
+ unsigned int seq;
__skb_pull(skb, skb_network_offset(skb));
- read_lock_bh(&neigh->lock);
- err = dev_hard_header(skb, dev, ntohs(skb->protocol),
- neigh->ha, NULL, skb->len);
- read_unlock_bh(&neigh->lock);
+ do {
+ seq = read_seqbegin(&neigh->ha_lock);
+ err = dev_hard_header(skb, dev, ntohs(skb->protocol),
+ neigh->ha, NULL, skb->len);
+ } while (read_seqretry(&neigh->ha_lock, seq));
+
if (err >= 0)
err = neigh->ops->queue_xmit(skb);
else {
@@ -2148,10 +2157,14 @@ static int neigh_fill_info(struct sk_buff *skb, struct neighbour *neigh,
read_lock_bh(&neigh->lock);
ndm->ndm_state = neigh->nud_state;
- if ((neigh->nud_state & NUD_VALID) &&
- nla_put(skb, NDA_LLADDR, neigh->dev->addr_len, neigh->ha) < 0) {
- read_unlock_bh(&neigh->lock);
- goto nla_put_failure;
+ if (neigh->nud_state & NUD_VALID) {
+ char haddr[MAX_ADDR_LEN];
+
+ neigh_ha_snapshot(haddr, neigh, neigh->dev);
+ if (nla_put(skb, NDA_LLADDR, neigh->dev->addr_len, haddr) < 0) {
+ read_unlock_bh(&neigh->lock);
+ goto nla_put_failure;
+ }
}
ci.ndm_used = jiffies_to_clock_t(now - neigh->used);
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index f353095..d8e540c 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -502,10 +502,8 @@ int arp_find(unsigned char *haddr, struct sk_buff *skb)
if (n) {
n->used = jiffies;
- if (n->nud_state&NUD_VALID || neigh_event_send(n, skb) == 0) {
- read_lock_bh(&n->lock);
- memcpy(haddr, n->ha, dev->addr_len);
- read_unlock_bh(&n->lock);
+ if (n->nud_state & NUD_VALID || neigh_event_send(n, skb) == 0) {
+ neigh_ha_snapshot(haddr, n, dev);
neigh_release(n);
return 0;
}
diff --git a/net/sched/sch_teql.c b/net/sched/sch_teql.c
index feaabc1..401af95 100644
--- a/net/sched/sch_teql.c
+++ b/net/sched/sch_teql.c
@@ -241,11 +241,11 @@ __teql_resolve(struct sk_buff *skb, struct sk_buff *skb_res, struct net_device *
}
if (neigh_event_send(n, skb_res) == 0) {
int err;
+ char haddr[MAX_ADDR_LEN];
- read_lock(&n->lock);
- err = dev_hard_header(skb, dev, ntohs(skb->protocol),
- n->ha, NULL, skb->len);
- read_unlock(&n->lock);
+ neigh_ha_snapshot(haddr, n, dev);
+ err = dev_hard_header(skb, dev, ntohs(skb->protocol), haddr,
+ NULL, skb->len);
if (err < 0) {
neigh_release(n);
^ permalink raw reply related
* Re: [PATCH] serial: DCC(JTAG) serial and console emulation support
From: Alan Cox @ 2010-10-07 21:08 UTC (permalink / raw)
To: Daniel Walker
Cc: Mike Frysinger, linux-kernel, Hyok S. Choi, Tony Lindgren,
Jeff Ohlstein, Greg Kroah-Hartman, Ben Dooks, Alan Cox,
Kukjin Kim, Feng Tang, Tobias Klauser, Jason Wessel,
Philippe Langlais
In-Reply-To: <1286483831.23836.40.camel@c-dwalke-linux.qualcomm.com>
> > I would agree 100% with this for the driver in question. The tty_port
> > helpers now make it trivial to do so and it'll be small and clean as a
> > result.
>
> Can you give some example of other drivers which have done this?
The blackfin driver is probably the nicest example for a very simple
device but see also the USB serial drivers (complex example), the SDIO
serial support (shows how to do fancy hotpluggable device stuff with it).
Basically tty_port_open/tty_port_close/tty_port_hangup do all the icky
nasty POSIX open/close/hangup handling and provide you with simple
methods to implement activate/shutdown of a port and carrier detect etc
most of which you don't even need to supply.
You can also skip a lot of other stuff like modem lines - although I can
see why you might want to provide an emulated modem line response for a
console emulation.
Alan
^ permalink raw reply
* Re: [PATCH] OLPC: Add XO-1 poweroff support
From: Daniel Drake @ 2010-10-07 20:42 UTC (permalink / raw)
To: Andres Salomon; +Cc: tglx, mingo, hpa, x86, linux-kernel
In-Reply-To: <20101007130904.29350df2@debxo>
On 7 October 2010 21:09, Andres Salomon <dilinger@queued.net> wrote:
> Any particular reason why this can't be modular?
Because of the pm_power_off thing.
Also, a similar situation would be encountered with set_suspend_ops().
I don't really understand your suggestion. If we set it to NULL on
module unload then the power off would crash on shutdown, right?
Daniel
^ permalink raw reply
* Re: [PATCH V2] Use firmware provided index to register a network interface
From: Matt Domsch @ 2010-10-07 20:42 UTC (permalink / raw)
To: Kay Sievers
Cc: Greg KH, K, Narendra, netdev@vger.kernel.org,
linux-hotplug@vger.kernel.org, linux-pci@vger.kernel.org,
Hargrave, Jordan, Nijhawan, Vijay, Rose, Charles
In-Reply-To: <AANLkTinP5WPDPvk+kq8vsyP=xC9qcoe+c=1EBp0XJNPk@mail.gmail.com>
On Thu, Oct 07, 2010 at 10:05:14AM -0700, Kay Sievers wrote:
> On Thu, Oct 7, 2010 at 18:48, Greg KH <greg@kroah.com> wrote:
> > On Thu, Oct 07, 2010 at 11:31:13AM -0500, Matt Domsch wrote:
> >> 1) SMBIOS type 41 method. Windows does not use this today, and I
> >> can't speak to their future plans. Narendra's kernel patch does,
> >> as has biosdevname, the udev helper we first wrote for this
> >> purpose, for several years.
> >
> > Then stick with that udev helper please :)
>
> What about just exporting this information in sysfs, and not touch the naming?
The config tools all take a netdevice name as their argument. What
would it look like then?
$ ifconfig $(netdevname 'Embedded NIC 1')
repeat for each tool that's called? This is similar to what we
proposed with the userspace patch and libnetdevname, so the lookup can
happen inside each app, rather than the system admin having to do the
translation themselves. That was rejected too...
otherwise, it's up to a human to do the translation in their head,
which isn't script-friendly.
-Matt
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
^ permalink raw reply
* Re: [PATCH V2] Use firmware provided index to register a network
From: Matt Domsch @ 2010-10-07 20:42 UTC (permalink / raw)
To: Kay Sievers
Cc: Greg KH, K, Narendra, netdev@vger.kernel.org,
linux-hotplug@vger.kernel.org, linux-pci@vger.kernel.org,
Hargrave, Jordan, Nijhawan, Vijay, Rose, Charles
In-Reply-To: <AANLkTinP5WPDPvk+kq8vsyP=xC9qcoe+c=1EBp0XJNPk@mail.gmail.com>
On Thu, Oct 07, 2010 at 10:05:14AM -0700, Kay Sievers wrote:
> On Thu, Oct 7, 2010 at 18:48, Greg KH <greg@kroah.com> wrote:
> > On Thu, Oct 07, 2010 at 11:31:13AM -0500, Matt Domsch wrote:
> >> 1) SMBIOS type 41 method. Windows does not use this today, and I
> >> can't speak to their future plans. Narendra's kernel patch does,
> >> as has biosdevname, the udev helper we first wrote for this
> >> purpose, for several years.
> >
> > Then stick with that udev helper please :)
>
> What about just exporting this information in sysfs, and not touch the naming?
The config tools all take a netdevice name as their argument. What
would it look like then?
$ ifconfig $(netdevname 'Embedded NIC 1')
repeat for each tool that's called? This is similar to what we
proposed with the userspace patch and libnetdevname, so the lookup can
happen inside each app, rather than the system admin having to do the
translation themselves. That was rejected too...
otherwise, it's up to a human to do the translation in their head,
which isn't script-friendly.
-Matt
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
^ permalink raw reply
* Re: [RFC v2 PATCH 1/1] PCI: override BIOS/firmware resource allocation
From: Ram Pai @ 2010-10-07 20:42 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Ram Pai, linux-pci, linux-kernel, clemens, Yinghai Lu,
Jesse Barnes, Linus Torvalds
In-Reply-To: <20101007041302.GA19867@helgaas.com>
On Wed, Oct 06, 2010 at 10:13:02PM -0600, Bjorn Helgaas wrote:
> On Wed, Oct 06, 2010 at 05:30:41PM -0700, Ram Pai wrote:
> > On Wed, Oct 06, 2010 at 05:39:53PM -0600, Bjorn Helgaas wrote:
> > > On Wed, Oct 06, 2010 at 03:58:34PM -0700, Ram Pai wrote:
> > > > PCI: override BIOS/firmware memory resource allocation
> > > > through command line parameters
> > > >
> > > > Platforms that are unaware of SRIOV BARs fail to allocate MMIO
> > > > resources to SRIOV PCIe devices. Hence on such platforms the
> > > > OS fails to enable SRIOV.
> > > > Some platforms where BIOS/uEFI resource allocations conflict
> > > > the conflicting devices are disabled.
> > > >
> > > > Ideally we would want the OS to detect and fix automatically
> > > > such problems and conflicts. However previous attempts to do so
> > > > have led to regression on legacy platforms.
> > >
> > > I'm sorry to be a nay-sayer, but I think we just haven't tried hard
> > > enough. Our ACPI/PCI/e820 resource management is not well integrated,
> > > and I suspect if we straightened that out, we could avoid some of the
> > > regressions we saw with previous attempts.
> >
> > Can you be more specific as to what can be done to fix it automatically?
> >
> > Neither accepting this approach nor telling what needs to be straightened out
> > to automatically fix all the systems out there, is just a deadend.
>
> Yeah, I guess that wasn't really fair, sorry. And keep in mind that I'm
> not the PCI maintainer, so these are just my opinions, nothing like an
> official "nack."
>
> I did look at this dmesg log from the thread you referenced:
> http://marc.info/?l=linux-kernel&m=127178918128740&w=2
> but it looks to me like we just completely botched it. I don't see an
> SRIOV device or anything else that didn't have resources, so as far as I
> can tell, we started with working resource assignments from the BIOS,
> threw them away, and started over from scratch. We failed because we
> tried to assign I/O port space to bridges with nothing behind them, and
> there was nothing left by the time we got to the 0000:09:04.0 device
> that actually *did* need the space.
hmm.. is that possible? Yinghai's patch sized the resource requirement of each
of the bridges, before actually allocating them. Which means a bridge with
no device behind it would not get any i/o space.
>
> I think what would be more interesting is to look at a log from *your*
> system, where you have SRIOV devices that don't have resources assigned,
> and see whether we have enough information to make the minimal changes
> required to assign resources to them. If we can come up with a strategy
> that only does something when absolutely required, and does it a little
> more carefully, I think we have a decent chance of success.
In my setup, the bridge has a BIOS allocated window large enough to
satisfy the standard BARs of my device. But nothing more to satisfy the
SRIOV BARs. We could come up with some strategy to satisfy this particular
configuration. Is that sufficient? Will that be the grand solution or
just a band-aid solution?
>
> > The choice is between
> > (a) an automated patch with the risk of regressing some platforms.
> > (b) an semi-automated patch that does not regress *any* platform,
> > with the ability to fix platforms that are currently broken.
> > (c) status quo, which means broken platforms continue to be so.
> >
> > I thought the initial proposal was to use (b), with the long
> > term goal of fixing it automatically, assuming that it is even possible.
> >
> > Let me know if that is *not* the goal and I will change directions.
>
> *My* goal is that a user would never need a kernel option except to help
> debug kernel problems. I think of an option like "pci=override" as a
> band-aid that covers up a kernel problem without really fixing it, so I
> guess my choice would be (a). Yes, there's a risk of regression, and we
> have to do everything we can to avoid it. But the result is a more
> usable system.
Ok. I think we agree with your goal, but the disagreement is on the approach.
You want to take one big leap, whereas the consensus I heard in earlier
threads was that we need to take baby steps.
RP
^ permalink raw reply
* Re: [PATCH] percpu_counter: change inaccurate comment
From: Eric Dumazet @ 2010-10-07 20:42 UTC (permalink / raw)
To: Christoph Lameter; +Cc: Andrew Morton, linux-kernel
In-Reply-To: <alpine.DEB.2.00.1010071509180.28032@router.home>
Le jeudi 07 octobre 2010 à 15:13 -0500, Christoph Lameter a écrit :
> On Thu, 7 Oct 2010, Eric Dumazet wrote:
>
> > If enclosed by preempt_disable()/preempt_enable(), maybe we could use
> > __this_cpu_ptr() ?
>
> The only difference between __this_cpu_ptr and this_cpu_ptr is that
> this_cpu_ptr checks that preempt was disabled. __this_cpu_ptr allows use
> even without preempt. Preempt must be disabled here so the use of
> this_cpu_ptr is appropriate.
>
>
Thats not how I read the thing.
In both variants, preemption _must_ be disabled, its only the context
that can tell how sure we are...
<quote>
commit 7340a0b15280c
__this_cpu_ptr -> Do not check for preemption context
this_cpu_ptr -> Check preemption context
</quote>
If preemption was enabled, both pointers would not be very useful...
We use __this_cpu_ptr() in contexts where cpu _cannot_ change under us,
(we just disabled preemption one line above), so its not necessary to
perform the check.
vi +316 include/linux/percpu.h
#define _this_cpu_generic_to_op(pcp, val, op) \
do { \
preempt_disable(); \
*__this_cpu_ptr(&(pcp)) op val; \
preempt_enable(); \
} while (0)
...
#define __this_cpu_generic_to_op(pcp, val, op) \
do { \
*__this_cpu_ptr(&(pcp)) op val; \
} while (0)
^ permalink raw reply
* Peculiar stuff in hci_ath3k/badness in hci_uart
From: Alan Cox @ 2010-10-07 20:41 UTC (permalink / raw)
To: linux-kernel, marcel, linux-bluetooth
Noticed this while looking at Savoy's stuff
ath_wakeup_ar3k:
int status = tty->driver->ops->tiocmget(tty, NULL);
Now if the tty driver it is bound to happens to use the file pointer or
worse still call into its file->ops badness is going to occur. Doubly fun
is this - a NULL tiocmget is perfectly acceptable and some drivers don't
have one. In the case of serial or usb core using code your backside is
saved by luck. For other hardware well the SELinux page 0 mapping stuff
will save your backside, and probably if enabled the sysctl bit on
current kernels, but if not - oh dear me.
It continues....
(kernel space)
struct termios settings;
n_tty_ioctl_helper(tty, NULL, TCGETS, (unsigned long)&settings);
settings.c_cflag &= ~CRTSCTS;
n_tty_ioctl_helper(tty, NULL, TCSETS, (unsigned long)&settings);
n_tty_ioctl_helper expects a user space pointer.
I've not reviewed it for security impacts. I'd imagine you can oops the
kernel happily with it and maybe more via the NULL pointers if suitable
obscure hardware happens to be present. My gut feeling is that for most
x86 boxes the worst will be an Oops or very bizarre behaviour because they
won't have any suitable serial ports you can hit or have permission to
access.
tiocmget needs a file pointer because some devices check for hangups
here. Now in fact it would actually make sense to move that into the core
code and see if we can kill the file pointer but right now it doesn't
seem safe.
The ioctl helper stuff can either use the ugly set_fs hackery or better
yet shove a helper in the kernel tree to get or set kernel termios which
just takes a struct ktermios and does the right mutex locks and ops calls
checks for NULL ops.
I can find no record of this code having been anywhere near
linux-kernel/linux-serial, which is a pity because after we'd mopped up
our spilled drinks the bug would have been reported.
Fortunately I looked further and the further I looked the more fun it gets
in hci_uart we have
len = tty->ops->write(tty, skb->data, skb->len);
but I can't find anywhere we check that the tty has a write op (a few
don't), and you should check this at open and refuse if the ops you need
don't exist (eg as SLIP does:
static int slip_open(struct tty_struct *tty)
{
struct slip *sl;
int err;
if (!capable(CAP_NET_ADMIN))
return -EPERM;
if (tty->ops->write == NULL)
return -EOPNOTSUPP;
Fortunately almost no system will have a driver loaded which lacks a
write op, but this should be fixed.
Alan
^ permalink raw reply
* Re: [PATCH] serial: DCC(JTAG) serial and console emulation support
From: Alan Cox @ 2010-10-07 21:05 UTC (permalink / raw)
To: Daniel Walker
Cc: linux-kernel, Hyok S. Choi, Tony Lindgren, Jeff Ohlstein,
Greg Kroah-Hartman, Ben Dooks, Alan Cox, Kukjin Kim,
Mike Frysinger, Feng Tang, Tobias Klauser, Jason Wessel,
Philippe Langlais
In-Reply-To: <1286483766.23836.39.camel@c-dwalke-linux.qualcomm.com>
On Thu, 07 Oct 2010 13:36:06 -0700
Daniel Walker <dwalker@codeaurora.org> wrote:
> On Thu, 2010-10-07 at 21:50 +0100, Alan Cox wrote:
> > > + Say Y here if you want to install DCC driver as a normal serial port
> > > + /dev/ttyS0 (major 4, minor 64). Otherwise, it appears as /dev/ttyJ0
> > > + (major 4, minor 128) and can co-exist with other UARTs, such as
> > > + 8250/16C550 compatibles.
> > > +
> >
> > NAK to both
>
> Both what?
Both device allocations. Please use the 204,186 assigned for JTAG DCC.
> I would agree if this wasn't strictly for debugging embedded devices in
> difficult situations.. After talking to Mike, it's seems like it would
> be useful to have this as a ttyS* specifically because embedded devices
> won't always create a ttyJ* for you and ttyS* will likely already exist.
If you are debugging an embedded device you are capable of changing it
(otherwise you wouldn't debug it). Therefore the fact you might need to
tweak the tty creation on the device is not a problem. If you can't
change the device well there is no point debugging it is there !
We've said no over a period of about ten years to a lot of attempts to
just borrow the ttyS0 range. If we'd said yes it would have been a
complete mess by now.
So the answer is no.
Alan
^ permalink raw reply
* Re: "do_IRQ: 0.89 No irq handler for vector (irq -1)"
From: Thomas Gleixner @ 2010-10-07 20:38 UTC (permalink / raw)
To: Dave Airlie; +Cc: LKML, Ingo Molnar, Jesse Barnes
In-Reply-To: <AANLkTikZj21CtFwC2ttvc0wJPx2qyedn7b1xXaxH659E@mail.gmail.com>
On Thu, 7 Oct 2010, Dave Airlie wrote:
> We are seeing this on both intel and radeon drivers when we reload the
> module with 2.6.36-rc7 or so, and we get no irqs for that device.
>
> you can reproduce by
>
> init 3
> echo 0 > /sys/class/vtconsole/vtcon1/bind
> rmmod i915
> modprobe i915
>
> or radeon.
>
> It seems to be possibly MSI related.
Yeah, can reproduce. Digging into it. I just discovered a even worse
thing. I wanted to know whether it recovers when I rmmod/modprobe the
module again, which resulted in:
Oct 7 22:24:19 ionos kernel: Console: switching to colour VGA+ 80x25
Oct 7 22:24:22 ionos kernel: drm: unregistered panic notifier
Oct 7 22:24:22 ionos kernel: vga_switcheroo: disabled
Oct 7 22:24:22 ionos kernel: BUG: sleeping function called from invalid context at /home/tglx/work/kernel/git/linux-2.6/arch/x86/mm/fault.c:1074
Oct 7 22:24:22 ionos kernel: in_atomic(): 0, irqs_disabled(): 1, pid: 2681, name: udevd
Oct 7 22:24:22 ionos kernel: Pid: 2681, comm: udevd Not tainted 2.6.36-rc7 #4
Oct 7 22:24:22 ionos kernel: Call Trace:
Oct 7 22:24:22 ionos kernel: [<ffffffff8103d3d1>] __might_sleep+0xed/0xef
Oct 7 22:24:22 ionos kernel: [<ffffffff81452d81>] do_page_fault+0x1b2/0x2bb
Oct 7 22:24:22 ionos kernel: [<ffffffff8144ff55>] page_fault+0x25/0x30
Oct 7 22:24:22 ionos kernel: [<ffffffff8106af14>] ? lock_hrtimer_base+0x22/0x50
Oct 7 22:24:22 ionos kernel: [<ffffffff8106af5e>] hrtimer_get_remaining+0x1c/0x46
Oct 7 22:24:22 ionos kernel: [<ffffffff8105119d>] itimer_get_remtime+0x16/0x3c
That means that the hrtimer in the shared signal handler is corrupted. Uurg.
Oct 7 22:24:22 ionos kernel: [<ffffffff8106d127>] ? abort_creds+0x1a/0x1c
Oct 7 22:24:22 ionos kernel: [<ffffffff81051445>] do_setitimer+0x97/0x1e7
Oct 7 22:24:22 ionos kernel: [<ffffffff81051674>] alarm_setitimer+0x3a/0x60
Oct 7 22:24:22 ionos kernel: [<ffffffff8105a248>] sys_alarm+0xe/0x12
Oct 7 22:24:22 ionos kernel: [<ffffffff81009c72>] system_call_fastpath+0x16/0x1b
Oct 7 22:24:22 ionos kernel: BUG: unable to handle kernel paging request at 00000000934a2400
Something is fishy here. That's not a kernel address
Oct 7 22:24:22 ionos kernel: IP: [<ffffffff8106af14>] lock_hrtimer_base+0x22/0x50
Oct 7 22:24:22 ionos kernel: PGD 716e6067 PUD 0
Oct 7 22:24:22 ionos kernel: Oops: 0000 [#1] SMP
Oct 7 22:24:22 ionos kernel: last sysfs file: /sys/devices/virtual/vtconsole/vtcon1/bind
Oct 7 22:24:22 ionos kernel: CPU 2
Oct 7 22:24:22 ionos kernel: Modules linked in: i915(-) fuse ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat bridge stp llc sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf xt_physdev ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 kvm_intel kvm uinput arc4 ecb iwlagn snd_hda_codec_intelhdmi snd_hda_codec_conexant iwlcore snd_hda_intel snd_hda_codec snd_hwdep mac80211 snd_seq snd_seq_device snd_pcm thinkpad_acpi snd_timer uvcvideo snd videodev sdhci_pci cfg80211 sdhci v4l1_compat soundcore snd_page_alloc v4l2_compat_ioctl32 mmc_core wmi microcode rfkill pcspkr joydev e1000e i2c_i801 shpchp iTCO_wdt iTCO_vendor_support firewire_ohci firewire_core crc_itu_t drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: i915]
Oct 7 22:24:22 ionos kernel:
Oct 7 22:24:22 ionos kernel: Pid: 2681, comm: udevd Not tainted 2.6.36-rc7 #4 25222AU/25222AU
Oct 7 22:24:22 ionos kernel: RIP: 0010:[<ffffffff8106af14>] [<ffffffff8106af14>] lock_hrtimer_base+0x22/0x50
Oct 7 22:24:22 ionos kernel: RSP: 0018:ffff8800573a7e58 EFLAGS: 00010006
Oct 7 22:24:22 ionos kernel: RAX: 00000000000006a4 RBX: 00000000934a2400 RCX: 0000000000000060
Oct 7 22:24:22 ionos kernel: RDX: 00000000000006a4 RSI: ffff8800573a7e90 RDI: ffff880037bffc70
Oct 7 22:24:22 ionos kernel: RBP: ffff8800573a7e78 R08: 0000000000000068 R09: 0101010101010101
Oct 7 22:24:22 ionos kernel: R10: 0000000000000060 R11: 0000000000000202 R12: ffff880037bffc70
Oct 7 22:24:22 ionos kernel: R13: ffff8800573a7e90 R14: ffff8800573a7f28 R15: 0000000000a97c20
Oct 7 22:24:22 ionos kernel: FS: 00007ff08870c7a0(0000) GS:ffff880002500000(0000) knlGS:0000000000000000
Oct 7 22:24:22 ionos kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Oct 7 22:24:22 ionos kernel: CR2: 000000313a047256 CR3: 00000000716e7000 CR4: 00000000000006e0
Oct 7 22:24:22 ionos kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Oct 7 22:24:22 ionos kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Oct 7 22:24:22 ionos kernel: Process udevd (pid: 2681, threadinfo ffff8800573a6000, task ffff880059238000)
Oct 7 22:24:22 ionos kernel: Stack:
Oct 7 22:24:22 ionos kernel: ffff88003798e180 ffff880037bffc70 ffff880059238000 ffff880037bffc70
Oct 7 22:24:22 ionos kernel: <0> ffff8800573a7ea8 ffffffff8106af5e ffff8800573a7e98 00000000810a069d
Oct 7 22:24:22 ionos kernel: <0> ffff880037bffc70 ffff880059238000 ffff8800573a7ee8 ffffffff8105119d
Oct 7 22:24:22 ionos kernel: Call Trace:
Oct 7 22:24:22 ionos kernel: [<ffffffff8106af5e>] hrtimer_get_remaining+0x1c/0x46
Oct 7 22:24:22 ionos kernel: [<ffffffff8105119d>] itimer_get_remtime+0x16/0x3c
Oct 7 22:24:22 ionos kernel: [<ffffffff8106d127>] ? abort_creds+0x1a/0x1c
Oct 7 22:24:22 ionos kernel: [<ffffffff81051445>] do_setitimer+0x97/0x1e7
Oct 7 22:24:22 ionos kernel: [<ffffffff81051674>] alarm_setitimer+0x3a/0x60
Oct 7 22:24:22 ionos kernel: [<ffffffff8105a248>] sys_alarm+0xe/0x12
Oct 7 22:24:22 ionos kernel: [<ffffffff81009c72>] system_call_fastpath+0x16/0x1b
Oct 7 22:24:22 ionos kernel: Code: 5c 41 5d 41 5e 41 5f c9 c3 55 48 89 e5 41 55 41 54 53 48 83 ec 08 0f 1f 44 00 00 49 89 fc 49 89 f5 49 8b 5c 24 30 48 85 db 74 2a <48> 8b 3b e8 bf 47 3e 00 49 89 45 00 49 3b 5c 24 30 75 0c 41 59
Oct 7 22:24:22 ionos kernel: RIP [<ffffffff8106af14>] lock_hrtimer_base+0x22/0x50
Oct 7 22:24:22 ionos kernel: RSP <ffff8800573a7e58>
Oct 7 22:24:22 ionos kernel: CR2: 00000000934a2400
Oct 7 22:24:22 ionos kernel: ---[ end trace 9b1fb5b66b44ba63 ]---
Oct 7 22:24:22 ionos kernel: BUG: unable to handle kernel paging request at 00000000934a2400
Oct 7 22:24:22 ionos kernel: IP: [<ffffffff8106af14>] lock_hrtimer_base+0x22/0x50
Oct 7 22:24:22 ionos kernel: PGD 716e6067 PUD 0
Oct 7 22:24:22 ionos kernel: Oops: 0000 [#2] SMP
Oct 7 22:24:22 ionos kernel: last sysfs file: /sys/devices/virtual/vtconsole/vtcon1/bind
Oct 7 22:24:22 ionos kernel: CPU 2
Oct 7 22:24:22 ionos kernel: Modules linked in: i915(-) fuse ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat bridge stp llc sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf xt_physdev ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 kvm_intel kvm uinput arc4 ecb iwlagn snd_hda_codec_intelhdmi snd_hda_codec_conexant iwlcore snd_hda_intel snd_hda_codec snd_hwdep mac80211 snd_seq snd_seq_device snd_pcm thinkpad_acpi snd_timer uvcvideo snd videodev sdhci_pci cfg80211 sdhci v4l1_compat soundcore snd_page_alloc v4l2_compat_ioctl32 mmc_core wmi microcode rfkill pcspkr joydev e1000e i2c_i801 shpchp iTCO_wdt iTCO_vendor_support firewire_ohci firewire_core crc_itu_t drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: i915]
Oct 7 22:24:22 ionos kernel:
Oct 7 22:24:22 ionos kernel: Pid: 2681, comm: udevd Tainted: G D 2.6.36-rc7 #4 25222AU/25222AU
Oct 7 22:24:22 ionos kernel: RIP: 0010:[<ffffffff8106af14>] [<ffffffff8106af14>] lock_hrtimer_base+0x22/0x50
Oct 7 22:24:22 ionos kernel: RSP: 0018:ffff8800573a7b48 EFLAGS: 00010206
Oct 7 22:24:22 ionos kernel: RAX: ffff880037bffc00 RBX: 00000000934a2400 RCX: 00000000000003e8
Oct 7 22:24:22 ionos kernel: RDX: 0000000000000001 RSI: ffff8800573a7b90 RDI: ffff880037bffc70
Oct 7 22:24:22 ionos kernel: RBP: ffff8800573a7b68 R08: 0000000000000000 R09: ffff880076c08000
Oct 7 22:24:22 ionos kernel: R10: ffff880076c08000 R11: 0000000000000020 R12: ffff880037bffc70
Oct 7 22:24:22 ionos kernel: R13: ffff8800573a7b90 R14: 0000000000000000 R15: 0000000000000001
Oct 7 22:24:22 ionos kernel: FS: 00007ff08870c7a0(0000) GS:ffff880002500000(0000) knlGS:0000000000000000
Oct 7 22:24:22 ionos kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Oct 7 22:24:22 ionos kernel: CR2: 00000000934a2400 CR3: 00000000716e7000 CR4: 00000000000006e0
Oct 7 22:24:22 ionos kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Oct 7 22:24:22 ionos kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Oct 7 22:24:22 ionos kernel: Process udevd (pid: 2681, threadinfo ffff8800573a6000, task ffff880059238000)
Oct 7 22:24:22 ionos kernel: Stack:
Oct 7 22:24:22 ionos kernel: ffff8800573a7b78 ffff880037bffc70 0000000000000009 0000000000000009
Oct 7 22:24:22 ionos kernel: <0> ffff8800573a7ba8 ffffffff8106afa2 ffff8800573a7c18 0000000000000046
Oct 7 22:24:22 ionos kernel: <0> ffff8800573a7bc8 0000000000000282 0000000000000000 ffff880037bffc70
Oct 7 22:24:22 ionos kernel: Call Trace:
Oct 7 22:24:22 ionos kernel: [<ffffffff8106afa2>] hrtimer_try_to_cancel+0x1a/0x4b
Oct 7 22:24:22 ionos kernel: [<ffffffff8106afec>] hrtimer_cancel+0x19/0x25
Oct 7 22:24:22 ionos kernel: [<ffffffff81050ac2>] do_exit+0x181/0x726
Oct 7 22:24:22 ionos kernel: [<ffffffff8104dfae>] ? kmsg_dump+0x12b/0x145
Oct 7 22:24:22 ionos kernel: [<ffffffff81450b16>] oops_end+0xbf/0xc7
Oct 7 22:24:22 ionos kernel: [<ffffffff81031e6b>] no_context+0x1fc/0x20b
Oct 7 22:24:22 ionos kernel: [<ffffffff81032004>] __bad_area_nosemaphore+0x18a/0x1ad
Oct 7 22:24:22 ionos kernel: [<ffffffff81032083>] bad_area+0x47/0x4e
Oct 7 22:24:22 ionos kernel: [<ffffffff81452dda>] do_page_fault+0x20b/0x2bb
Oct 7 22:24:22 ionos kernel: [<ffffffff8144ff55>] page_fault+0x25/0x30
Oct 7 22:24:22 ionos kernel: [<ffffffff8106af14>] ? lock_hrtimer_base+0x22/0x50
Oct 7 22:24:22 ionos kernel: [<ffffffff8106af5e>] hrtimer_get_remaining+0x1c/0x46
Oct 7 22:24:22 ionos kernel: [<ffffffff8105119d>] itimer_get_remtime+0x16/0x3c
Oct 7 22:24:22 ionos kernel: [<ffffffff8106d127>] ? abort_creds+0x1a/0x1c
Oct 7 22:24:22 ionos kernel: [<ffffffff81051445>] do_setitimer+0x97/0x1e7
Oct 7 22:24:22 ionos kernel: [<ffffffff81051674>] alarm_setitimer+0x3a/0x60
Oct 7 22:24:22 ionos kernel: [<ffffffff8105a248>] sys_alarm+0xe/0x12
Oct 7 22:24:22 ionos kernel: [<ffffffff81009c72>] system_call_fastpath+0x16/0x1b
Oct 7 22:24:22 ionos kernel: Code: 5c 41 5d 41 5e 41 5f c9 c3 55 48 89 e5 41 55 41 54 53 48 83 ec 08 0f 1f 44 00 00 49 89 fc 49 89 f5 49 8b 5c 24 30 48 85 db 74 2a <48> 8b 3b e8 bf 47 3e 00 49 89 45 00 49 3b 5c 24 30 75 0c 41 59
Oct 7 22:24:22 ionos kernel: RIP [<ffffffff8106af14>] lock_hrtimer_base+0x22/0x50
Oct 7 22:24:22 ionos kernel: RSP <ffff8800573a7b48>
Oct 7 22:24:22 ionos kernel: CR2: 00000000934a2400
Oct 7 22:24:22 ionos kernel: ---[ end trace 9b1fb5b66b44ba64 ]---
Oct 7 22:24:22 ionos kernel: Fixing recursive fault but reboot is needed!
Oct 7 22:24:22 ionos kernel: [drm] Module unloaded
^ permalink raw reply
* Re: OT: compilation
From: Grzesiek Sójka @ 2010-10-07 20:38 UTC (permalink / raw)
To: Pekka Paalanen, nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <20101007233420.1f763477-cxYvVS3buNOdIgDiPM52R8c4bpwCjbIv@public.gmane.org>
On 10/07/10 22:34, Pekka Paalanen wrote:
> On Thu, 07 Oct 2010 22:14:19 +0200
> Grzesiek Sójka<pld-t9zbU3WrWHI@public.gmane.org> wrote:
>
>> I have two problems with the kernel compilation.
>>
>> 1. I have a small rootfs. It is too small to put all the modules
>> there without gzipping it first. So installing it requires lots
>> of sweating. That is why I was wondering if there is a (more/less
>> easy) way to make the "make modules_install" command gzip the
>> modules "on the fly".
>
> Wait, does modprobe support compressed kernel modules? I've
Yes, it does. I thing that most of the distribution pre-compiled kernels
does have gziped modules.
> never heard of that. If you really do not want to touch
> the partitioning, how about symlinking some directories
> elsewhere? Be careful on what is needed to boot, though.
Wrong idea. I already tried this.
^ permalink raw reply
* Re: [PATCH] serial: DCC(JTAG) serial and console emulation support
From: Daniel Walker @ 2010-10-07 20:37 UTC (permalink / raw)
To: Alan Cox
Cc: Mike Frysinger, linux-kernel, Hyok S. Choi, Tony Lindgren,
Jeff Ohlstein, Greg Kroah-Hartman, Ben Dooks, Alan Cox,
Kukjin Kim, Feng Tang, Tobias Klauser, Jason Wessel,
Philippe Langlais
In-Reply-To: <20101007215202.65ffeace@lxorguk.ukuu.org.uk>
On Thu, 2010-10-07 at 21:52 +0100, Alan Cox wrote:
> On Thu, 7 Oct 2010 15:25:34 -0400
> Mike Frysinger <vapier@gentoo.org> wrote:
>
> > On Thu, Oct 7, 2010 at 14:36, Daniel Walker wrote:
> > > Many of JTAG debuggers for ARM support DCC protocol over JTAG
> > > connection, which is very useful to debug hardwares which has no
> > > serial port. This patch adds DCC serial emulation and the console
> > > support. System timer based polling method is used for the
> > > emulation of serial input interrupt handling.
> >
> > why use serial_core at all ? seems like you could just use the tty
> > layer directly. i did that with drivers/char/bfin_jtag_comm.c.
>
> I would agree 100% with this for the driver in question. The tty_port
> helpers now make it trivial to do so and it'll be small and clean as a
> result.
Can you give some example of other drivers which have done this?
Daniel
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [U-Boot] ¡Ruan Pablo te ha dejado un mensaje en Badoo!
From: Badoo @ 2010-10-07 20:37 UTC (permalink / raw)
To: u-boot
?Tienes un nuevo mensaje en Badoo!
Ruan Pablo te dej? un mensaje.
Haz click en este enlace para verlo:
http://us1.badoo.com/01125899210/in/YSBN7LxnooU/?lang_id=7
M?s gente que tambi?n te est? esperando:
JUAN FELIPE (Medell?n, Colombia)
Juli (Santa Fe, Colombia)
Juliancho (Medell?n, Colombia)
http://us1.badoo.com/01125899210/in/YSBN7LxnooU/?lang_id=7
Si al hacer click sobre el enlace, no funciona, copia y pega la direcci?n en tu barra del navegador.
Este email es parte del procedimiento para que leas los mensajes de Ruan Pablo. Si has recibido este email por equivocaci?n, por favor, ign?ralo. Tras un corto periodo de tiempo el mensaje sera eliminado del sistema.
?Divi?rtete!
El Equipo de Badoo
Has recibido este email porque un usuario de Badoo te ha dejado un mensaje en Badoo. Este mensaje es autom?tico. Las respuestas a este mensaje no estan controladas y no ser?n contestadas. Si no quieres recibir m?s mensajes de Badoo, h?znoslo saber:
http://us1.badoo.com/impersonation.phtml?lang_id=7&mail_code=21&email=u-boot%40lists.denx.de&secret=&invite_id=229087&user_id=1125899210
^ permalink raw reply
* Re: [PATCH] serial: DCC(JTAG) serial and console emulation support
From: Daniel Walker @ 2010-10-07 20:36 UTC (permalink / raw)
To: Alan Cox
Cc: linux-kernel, Hyok S. Choi, Tony Lindgren, Jeff Ohlstein,
Greg Kroah-Hartman, Ben Dooks, Alan Cox, Kukjin Kim,
Mike Frysinger, Feng Tang, Tobias Klauser, Jason Wessel,
Philippe Langlais
In-Reply-To: <20101007215019.17b4a34a@lxorguk.ukuu.org.uk>
On Thu, 2010-10-07 at 21:50 +0100, Alan Cox wrote:
> > + Say Y here if you want to install DCC driver as a normal serial port
> > + /dev/ttyS0 (major 4, minor 64). Otherwise, it appears as /dev/ttyJ0
> > + (major 4, minor 128) and can co-exist with other UARTs, such as
> > + 8250/16C550 compatibles.
> > +
>
> NAK to both
Both what?
> ttyJ0 is 204,186 for "JTAG1 DCC protocol based serial"
>
> so there is an existing name and minor allocation, which as you won't be
> using two of them should be quite usable.
>
> If you want to be able to switch at runtime to pretend it is ttyS0 please
> deal with that in your user space. The same rules apply to you as have
> been applied to everyone else who has tried to implement this same crap
> in their uart driver too (we'd have it in about 30 by now otherwise)
I would agree if this wasn't strictly for debugging embedded devices in
difficult situations.. After talking to Mike, it's seems like it would
be useful to have this as a ttyS* specifically because embedded devices
won't always create a ttyJ* for you and ttyS* will likely already exist.
Daniel
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCH 3/3] sysrq,keyboard: properly deal with alt-sysrq in sysrq input filter
From: Jason Wessel @ 2010-10-07 20:35 UTC (permalink / raw)
To: dmitry.torokhov
Cc: kgdb-bugreport, linux-input, linux-kernel, Jason Wessel,
Greg Kroah-Hartman
In-Reply-To: <1286483748-1171-1-git-send-email-jason.wessel@windriver.com>
This patch addresses 2 problems:
1) You should still be able to use alt-PrintScreen to capture a grab
of a single window when the sysrq filter is active.
2) The sysrq filter should reset the low level key mask so that future
key presses will not show up as a repeated key. The problem was
that when you executed alt-sysrq g and then resumed the kernel, you
would have to press 'g' twice to get it working again.
CC: Dmitry Torokhov <dmitry.torokhov@gmail.com>
CC: Greg Kroah-Hartman <gregkh@suse.de>
CC: linux-input@vger.kernel.org
Reported-by: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
---
drivers/char/sysrq.c | 64 +++++++++++++++++++++++++++++++++++++++++++++++--
1 files changed, 61 insertions(+), 3 deletions(-)
diff --git a/drivers/char/sysrq.c b/drivers/char/sysrq.c
index ef31bb8..b1fad74 100644
--- a/drivers/char/sysrq.c
+++ b/drivers/char/sysrq.c
@@ -566,6 +566,57 @@ static const unsigned char sysrq_xlate[KEY_MAX + 1] =
static bool sysrq_down;
static int sysrq_alt_use;
static int sysrq_alt;
+static bool sysrq_kbd_triggered;
+
+/*
+ * This function was a copy of input_pass_event but modified to allow
+ * by-passing a specific filter, to allow for injected events without
+ * filter recursion.
+ */
+static void input_pass_event_ignore(struct input_dev *dev,
+ unsigned int type, unsigned int code, int value,
+ struct input_handle *ignore_handle)
+{
+ struct input_handler *handler;
+ struct input_handle *handle;
+
+ rcu_read_lock();
+
+ handle = rcu_dereference(dev->grab);
+ if (handle)
+ handle->handler->event(handle, type, code, value);
+ else {
+ bool filtered = false;
+
+ list_for_each_entry_rcu(handle, &dev->h_list, d_node) {
+ if (!handle->open || handle == ignore_handle)
+ continue;
+ handler = handle->handler;
+ if (!handler->filter) {
+ if (filtered)
+ break;
+
+ handler->event(handle, type, code, value);
+
+ } else if (handler->filter(handle, type, code, value))
+ filtered = true;
+ }
+ }
+
+ rcu_read_unlock();
+}
+
+/*
+ * Pass along alt-print_screen, if there was no sysrq processing by
+ * sending a key press down and then passing the key up event.
+ */
+static void simulate_alt_sysrq(struct input_handle *handle)
+{
+ input_pass_event_ignore(handle->dev, EV_KEY, KEY_SYSRQ, 1, handle);
+ input_pass_event_ignore(handle->dev, EV_SYN, SYN_REPORT, 0, handle);
+ input_pass_event_ignore(handle->dev, EV_KEY, KEY_SYSRQ, 0, handle);
+ input_pass_event_ignore(handle->dev, EV_SYN, SYN_REPORT, 0, handle);
+}
static bool sysrq_filter(struct input_handle *handle, unsigned int type,
unsigned int code, int value)
@@ -580,9 +631,11 @@ static bool sysrq_filter(struct input_handle *handle, unsigned int type,
if (value)
sysrq_alt = code;
else {
- if (sysrq_down && code == sysrq_alt_use)
+ if (sysrq_down && code == sysrq_alt_use) {
sysrq_down = false;
-
+ if (!sysrq_kbd_triggered)
+ simulate_alt_sysrq(handle);
+ }
sysrq_alt = 0;
}
break;
@@ -590,13 +643,18 @@ static bool sysrq_filter(struct input_handle *handle, unsigned int type,
case KEY_SYSRQ:
if (value == 1 && sysrq_alt) {
sysrq_down = true;
+ sysrq_kbd_triggered = false;
sysrq_alt_use = sysrq_alt;
}
break;
default:
- if (sysrq_down && value && value != 2)
+ if (sysrq_down && value && value != 2 && !sysrq_kbd_triggered) {
+ sysrq_kbd_triggered = true;
__handle_sysrq(sysrq_xlate[code], true);
+ /* Clear handled keys from being flagged as a repeated stroke */
+ __clear_bit(code, handle->dev->key);
+ }
break;
}
--
1.6.3.3
^ permalink raw reply related
* [PATCH 1/3] keyboard,kgdboc: Allow key release on kernel resume
From: Jason Wessel @ 2010-10-07 20:35 UTC (permalink / raw)
To: dmitry.torokhov
Cc: kgdb-bugreport, linux-input, linux-kernel, Jason Wessel,
Greg Kroah-Hartman
In-Reply-To: <1286483748-1171-1-git-send-email-jason.wessel@windriver.com>
When using a keyboard with kdb, a hook point to free all the
keystrokes is required for resuming kernel operations.
This is mainly because there is no way to force the end user to hold
down the original keys that were pressed prior to entering kdb when
resuming the kernel.
The kgdboc driver will call kbd_dbg_clear_keys() just prior to
resuming the kernel execution which will schedule a callback to clear
any keys which were depressed prior to the entering the kernel
debugger.
CC: Dmitry Torokhov <dmitry.torokhov@gmail.com>
CC: Greg Kroah-Hartman <gregkh@suse.de>
CC: linux-input@vger.kernel.org
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
---
drivers/char/keyboard.c | 37 +++++++++++++++++++++++++++++++++++++
drivers/serial/kgdboc.c | 13 +++++++++++++
include/linux/kbd_kern.h | 1 +
3 files changed, 51 insertions(+), 0 deletions(-)
diff --git a/drivers/char/keyboard.c b/drivers/char/keyboard.c
index a7ca752..0c6c641 100644
--- a/drivers/char/keyboard.c
+++ b/drivers/char/keyboard.c
@@ -363,6 +363,43 @@ static void to_utf8(struct vc_data *vc, uint c)
}
}
+#ifdef CONFIG_KDB_KEYBOARD
+static int kbd_clear_keys_helper(struct input_handle *handle, void *data)
+{
+ unsigned int *keycode = data;
+ input_inject_event(handle, EV_KEY, *keycode, 0);
+ return 0;
+}
+
+static void kbd_clear_keys_callback(struct work_struct *dummy)
+{
+ unsigned int i, j, k;
+
+ for (i = 0; i < ARRAY_SIZE(key_down); i++) {
+ if (!key_down[i])
+ continue;
+
+ k = i * BITS_PER_LONG;
+
+ for (j = 0; j < BITS_PER_LONG; j++, k++) {
+ if (!test_bit(k, key_down))
+ continue;
+ input_handler_for_each_handle(&kbd_handler, &k,
+ kbd_clear_keys_helper);
+ }
+ }
+}
+
+static DECLARE_WORK(kbd_clear_keys_work, kbd_clear_keys_callback);
+
+/* Called to clear any key presses after resuming the kernel. */
+void kbd_dbg_clear_keys(void)
+{
+ schedule_work(&kbd_clear_keys_work);
+}
+EXPORT_SYMBOL_GPL(kbd_dbg_clear_keys);
+#endif /* CONFIG_KDB_KEYBOARD */
+
/*
* Called after returning from RAW mode or when changing consoles - recompute
* shift_down[] and shift_state from key_down[] maybe called when keymap is
diff --git a/drivers/serial/kgdboc.c b/drivers/serial/kgdboc.c
index 39f9a1a..62b6edc 100644
--- a/drivers/serial/kgdboc.c
+++ b/drivers/serial/kgdboc.c
@@ -18,6 +18,7 @@
#include <linux/tty.h>
#include <linux/console.h>
#include <linux/vt_kern.h>
+#include <linux/kbd_kern.h>
#define MAX_CONFIG_LEN 40
@@ -37,12 +38,16 @@ static struct tty_driver *kgdb_tty_driver;
static int kgdb_tty_line;
#ifdef CONFIG_KDB_KEYBOARD
+static bool kgdboc_use_kbd;
+
static int kgdboc_register_kbd(char **cptr)
{
+ kgdboc_use_kbd = false;
if (strncmp(*cptr, "kbd", 3) == 0) {
if (kdb_poll_idx < KDB_POLL_FUNC_MAX) {
kdb_poll_funcs[kdb_poll_idx] = kdb_get_kbd_char;
kdb_poll_idx++;
+ kgdboc_use_kbd = true;
if (cptr[0][3] == ',')
*cptr += 4;
else
@@ -65,9 +70,16 @@ static void kgdboc_unregister_kbd(void)
}
}
}
+
+static inline void kgdboc_clear_kbd(void)
+{
+ if (kgdboc_use_kbd)
+ kbd_dbg_clear_keys(); /* Release all pressed keys */
+}
#else /* ! CONFIG_KDB_KEYBOARD */
#define kgdboc_register_kbd(x) 0
#define kgdboc_unregister_kbd()
+#define kgdboc_clear_kbd()
#endif /* ! CONFIG_KDB_KEYBOARD */
static int kgdboc_option_setup(char *opt)
@@ -231,6 +243,7 @@ static void kgdboc_post_exp_handler(void)
dbg_restore_graphics = 0;
con_debug_leave();
}
+ kgdboc_clear_kbd();
}
static struct kgdb_io kgdboc_io_ops = {
diff --git a/include/linux/kbd_kern.h b/include/linux/kbd_kern.h
index 506ad20..ae87c0a 100644
--- a/include/linux/kbd_kern.h
+++ b/include/linux/kbd_kern.h
@@ -144,6 +144,7 @@ struct console;
int getkeycode(unsigned int scancode);
int setkeycode(unsigned int scancode, unsigned int keycode);
void compute_shiftstate(void);
+void kbd_dbg_clear_keys(void);
/* defkeymap.c */
--
1.6.3.3
^ permalink raw reply related
* [PATCH 2/3] keyboard,kdb: inject SYN events in kbd_clear_keys_helper
From: Jason Wessel @ 2010-10-07 20:35 UTC (permalink / raw)
To: dmitry.torokhov
Cc: kgdb-bugreport, linux-input, linux-kernel, Maxim Levitsky,
Jason Wessel
In-Reply-To: <1286483748-1171-1-git-send-email-jason.wessel@windriver.com>
From: Maxim Levitsky <maximlevitsky@gmail.com>
The kbd_clear_keys_helper injects the keyup events alright, but it
doesn't inject SYN events, and therefore X evdev driver doesn't pick
these injected events untill next SYN event.
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
---
drivers/char/keyboard.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/char/keyboard.c b/drivers/char/keyboard.c
index 0c6c641..7df6af5 100644
--- a/drivers/char/keyboard.c
+++ b/drivers/char/keyboard.c
@@ -368,6 +368,7 @@ static int kbd_clear_keys_helper(struct input_handle *handle, void *data)
{
unsigned int *keycode = data;
input_inject_event(handle, EV_KEY, *keycode, 0);
+ input_inject_event(handle, EV_SYN, SYN_REPORT, 0);
return 0;
}
--
1.6.3.3
^ permalink raw reply related
* [PATCH 0/3] input / sysrq fixes for use with kdb
From: Jason Wessel @ 2010-10-07 20:35 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: kgdb-bugreport, linux-input, linux-kernel
The goal of this patch set is to help eliminate the problems of
resuming from the kernel debugger and having "stuck keys".
I am completely open to moving the code chunks around if it makes more
sense to put the function in the input.c.
I had posted the first patch in the series before and never received
an ack or acceptance into the linux-input merge queue.
Thanks,
Jason.
---
The following changes since commit cb655d0f3d57c23db51b981648e452988c0223f9:
Linus Torvalds (1):
Linux 2.6.36-rc7
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb.git for_input
Jason Wessel (2):
keyboard,kgdboc: Allow key release on kernel resume
sysrq,keyboard: properly deal with alt-sysrq in sysrq input filter
Maxim Levitsky (1):
keyboard,kdb: inject SYN events in kbd_clear_keys_helper
drivers/char/keyboard.c | 38 +++++++++++++++++++++++++++
drivers/char/sysrq.c | 64 +++++++++++++++++++++++++++++++++++++++++++--
drivers/serial/kgdboc.c | 13 +++++++++
include/linux/kbd_kern.h | 1 +
4 files changed, 113 insertions(+), 3 deletions(-)
^ permalink raw reply
* [PATCH 3/3] sysrq, keyboard: properly deal with alt-sysrq in sysrq input filter
From: Jason Wessel @ 2010-10-07 20:35 UTC (permalink / raw)
To: dmitry.torokhov
Cc: kgdb-bugreport, Jason Wessel, Greg Kroah-Hartman, linux-kernel,
linux-input
In-Reply-To: <1286483748-1171-1-git-send-email-jason.wessel@windriver.com>
This patch addresses 2 problems:
1) You should still be able to use alt-PrintScreen to capture a grab
of a single window when the sysrq filter is active.
2) The sysrq filter should reset the low level key mask so that future
key presses will not show up as a repeated key. The problem was
that when you executed alt-sysrq g and then resumed the kernel, you
would have to press 'g' twice to get it working again.
CC: Dmitry Torokhov <dmitry.torokhov@gmail.com>
CC: Greg Kroah-Hartman <gregkh@suse.de>
CC: linux-input@vger.kernel.org
Reported-by: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
---
drivers/char/sysrq.c | 64 +++++++++++++++++++++++++++++++++++++++++++++++--
1 files changed, 61 insertions(+), 3 deletions(-)
diff --git a/drivers/char/sysrq.c b/drivers/char/sysrq.c
index ef31bb8..b1fad74 100644
--- a/drivers/char/sysrq.c
+++ b/drivers/char/sysrq.c
@@ -566,6 +566,57 @@ static const unsigned char sysrq_xlate[KEY_MAX + 1] =
static bool sysrq_down;
static int sysrq_alt_use;
static int sysrq_alt;
+static bool sysrq_kbd_triggered;
+
+/*
+ * This function was a copy of input_pass_event but modified to allow
+ * by-passing a specific filter, to allow for injected events without
+ * filter recursion.
+ */
+static void input_pass_event_ignore(struct input_dev *dev,
+ unsigned int type, unsigned int code, int value,
+ struct input_handle *ignore_handle)
+{
+ struct input_handler *handler;
+ struct input_handle *handle;
+
+ rcu_read_lock();
+
+ handle = rcu_dereference(dev->grab);
+ if (handle)
+ handle->handler->event(handle, type, code, value);
+ else {
+ bool filtered = false;
+
+ list_for_each_entry_rcu(handle, &dev->h_list, d_node) {
+ if (!handle->open || handle == ignore_handle)
+ continue;
+ handler = handle->handler;
+ if (!handler->filter) {
+ if (filtered)
+ break;
+
+ handler->event(handle, type, code, value);
+
+ } else if (handler->filter(handle, type, code, value))
+ filtered = true;
+ }
+ }
+
+ rcu_read_unlock();
+}
+
+/*
+ * Pass along alt-print_screen, if there was no sysrq processing by
+ * sending a key press down and then passing the key up event.
+ */
+static void simulate_alt_sysrq(struct input_handle *handle)
+{
+ input_pass_event_ignore(handle->dev, EV_KEY, KEY_SYSRQ, 1, handle);
+ input_pass_event_ignore(handle->dev, EV_SYN, SYN_REPORT, 0, handle);
+ input_pass_event_ignore(handle->dev, EV_KEY, KEY_SYSRQ, 0, handle);
+ input_pass_event_ignore(handle->dev, EV_SYN, SYN_REPORT, 0, handle);
+}
static bool sysrq_filter(struct input_handle *handle, unsigned int type,
unsigned int code, int value)
@@ -580,9 +631,11 @@ static bool sysrq_filter(struct input_handle *handle, unsigned int type,
if (value)
sysrq_alt = code;
else {
- if (sysrq_down && code == sysrq_alt_use)
+ if (sysrq_down && code == sysrq_alt_use) {
sysrq_down = false;
-
+ if (!sysrq_kbd_triggered)
+ simulate_alt_sysrq(handle);
+ }
sysrq_alt = 0;
}
break;
@@ -590,13 +643,18 @@ static bool sysrq_filter(struct input_handle *handle, unsigned int type,
case KEY_SYSRQ:
if (value == 1 && sysrq_alt) {
sysrq_down = true;
+ sysrq_kbd_triggered = false;
sysrq_alt_use = sysrq_alt;
}
break;
default:
- if (sysrq_down && value && value != 2)
+ if (sysrq_down && value && value != 2 && !sysrq_kbd_triggered) {
+ sysrq_kbd_triggered = true;
__handle_sysrq(sysrq_xlate[code], true);
+ /* Clear handled keys from being flagged as a repeated stroke */
+ __clear_bit(code, handle->dev->key);
+ }
break;
}
--
1.6.3.3
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
^ permalink raw reply related
* Re: [PATCH] fast-import: Allow filemodify to set the root
From: Sverre Rabbelier @ 2010-10-07 20:35 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: David Barr, Git Mailing List, Ramkumar Ramachandra
In-Reply-To: <20101007202847.GA13234@burratino>
Heya,
On Thu, Oct 7, 2010 at 22:28, Jonathan Nieder <jrnieder@gmail.com> wrote:
> | is a synonym for the deleteall command.
Thanks, the updated doc is more understandable.
> [*] how significant? Numbers are always nice. :)
Yes, numbers please! :)
>> Ok, so maybe I do understand, is it basically 'git read-tree
>> 4b825dc642cb6eb9a060e54bf8d69288fbee4904' for fast-import?
>
> Yep.
Perhaps mention that in the commit message as well then. Of course,
the fast-import doc needs updating, and it needs test.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [PATCH 2/3] keyboard, kdb: inject SYN events in kbd_clear_keys_helper
From: Jason Wessel @ 2010-10-07 20:35 UTC (permalink / raw)
To: dmitry.torokhov
Cc: Maxim Levitsky, kgdb-bugreport, Jason Wessel, linux-kernel,
linux-input
In-Reply-To: <1286483748-1171-1-git-send-email-jason.wessel@windriver.com>
From: Maxim Levitsky <maximlevitsky@gmail.com>
The kbd_clear_keys_helper injects the keyup events alright, but it
doesn't inject SYN events, and therefore X evdev driver doesn't pick
these injected events untill next SYN event.
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
---
drivers/char/keyboard.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/char/keyboard.c b/drivers/char/keyboard.c
index 0c6c641..7df6af5 100644
--- a/drivers/char/keyboard.c
+++ b/drivers/char/keyboard.c
@@ -368,6 +368,7 @@ static int kbd_clear_keys_helper(struct input_handle *handle, void *data)
{
unsigned int *keycode = data;
input_inject_event(handle, EV_KEY, *keycode, 0);
+ input_inject_event(handle, EV_SYN, SYN_REPORT, 0);
return 0;
}
--
1.6.3.3
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
^ permalink raw reply related
* [PATCH 1/3] keyboard, kgdboc: Allow key release on kernel resume
From: Jason Wessel @ 2010-10-07 20:35 UTC (permalink / raw)
To: dmitry.torokhov
Cc: kgdb-bugreport, Jason Wessel, Greg Kroah-Hartman, linux-kernel,
linux-input
In-Reply-To: <1286483748-1171-1-git-send-email-jason.wessel@windriver.com>
When using a keyboard with kdb, a hook point to free all the
keystrokes is required for resuming kernel operations.
This is mainly because there is no way to force the end user to hold
down the original keys that were pressed prior to entering kdb when
resuming the kernel.
The kgdboc driver will call kbd_dbg_clear_keys() just prior to
resuming the kernel execution which will schedule a callback to clear
any keys which were depressed prior to the entering the kernel
debugger.
CC: Dmitry Torokhov <dmitry.torokhov@gmail.com>
CC: Greg Kroah-Hartman <gregkh@suse.de>
CC: linux-input@vger.kernel.org
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
---
drivers/char/keyboard.c | 37 +++++++++++++++++++++++++++++++++++++
drivers/serial/kgdboc.c | 13 +++++++++++++
include/linux/kbd_kern.h | 1 +
3 files changed, 51 insertions(+), 0 deletions(-)
diff --git a/drivers/char/keyboard.c b/drivers/char/keyboard.c
index a7ca752..0c6c641 100644
--- a/drivers/char/keyboard.c
+++ b/drivers/char/keyboard.c
@@ -363,6 +363,43 @@ static void to_utf8(struct vc_data *vc, uint c)
}
}
+#ifdef CONFIG_KDB_KEYBOARD
+static int kbd_clear_keys_helper(struct input_handle *handle, void *data)
+{
+ unsigned int *keycode = data;
+ input_inject_event(handle, EV_KEY, *keycode, 0);
+ return 0;
+}
+
+static void kbd_clear_keys_callback(struct work_struct *dummy)
+{
+ unsigned int i, j, k;
+
+ for (i = 0; i < ARRAY_SIZE(key_down); i++) {
+ if (!key_down[i])
+ continue;
+
+ k = i * BITS_PER_LONG;
+
+ for (j = 0; j < BITS_PER_LONG; j++, k++) {
+ if (!test_bit(k, key_down))
+ continue;
+ input_handler_for_each_handle(&kbd_handler, &k,
+ kbd_clear_keys_helper);
+ }
+ }
+}
+
+static DECLARE_WORK(kbd_clear_keys_work, kbd_clear_keys_callback);
+
+/* Called to clear any key presses after resuming the kernel. */
+void kbd_dbg_clear_keys(void)
+{
+ schedule_work(&kbd_clear_keys_work);
+}
+EXPORT_SYMBOL_GPL(kbd_dbg_clear_keys);
+#endif /* CONFIG_KDB_KEYBOARD */
+
/*
* Called after returning from RAW mode or when changing consoles - recompute
* shift_down[] and shift_state from key_down[] maybe called when keymap is
diff --git a/drivers/serial/kgdboc.c b/drivers/serial/kgdboc.c
index 39f9a1a..62b6edc 100644
--- a/drivers/serial/kgdboc.c
+++ b/drivers/serial/kgdboc.c
@@ -18,6 +18,7 @@
#include <linux/tty.h>
#include <linux/console.h>
#include <linux/vt_kern.h>
+#include <linux/kbd_kern.h>
#define MAX_CONFIG_LEN 40
@@ -37,12 +38,16 @@ static struct tty_driver *kgdb_tty_driver;
static int kgdb_tty_line;
#ifdef CONFIG_KDB_KEYBOARD
+static bool kgdboc_use_kbd;
+
static int kgdboc_register_kbd(char **cptr)
{
+ kgdboc_use_kbd = false;
if (strncmp(*cptr, "kbd", 3) == 0) {
if (kdb_poll_idx < KDB_POLL_FUNC_MAX) {
kdb_poll_funcs[kdb_poll_idx] = kdb_get_kbd_char;
kdb_poll_idx++;
+ kgdboc_use_kbd = true;
if (cptr[0][3] == ',')
*cptr += 4;
else
@@ -65,9 +70,16 @@ static void kgdboc_unregister_kbd(void)
}
}
}
+
+static inline void kgdboc_clear_kbd(void)
+{
+ if (kgdboc_use_kbd)
+ kbd_dbg_clear_keys(); /* Release all pressed keys */
+}
#else /* ! CONFIG_KDB_KEYBOARD */
#define kgdboc_register_kbd(x) 0
#define kgdboc_unregister_kbd()
+#define kgdboc_clear_kbd()
#endif /* ! CONFIG_KDB_KEYBOARD */
static int kgdboc_option_setup(char *opt)
@@ -231,6 +243,7 @@ static void kgdboc_post_exp_handler(void)
dbg_restore_graphics = 0;
con_debug_leave();
}
+ kgdboc_clear_kbd();
}
static struct kgdb_io kgdboc_io_ops = {
diff --git a/include/linux/kbd_kern.h b/include/linux/kbd_kern.h
index 506ad20..ae87c0a 100644
--- a/include/linux/kbd_kern.h
+++ b/include/linux/kbd_kern.h
@@ -144,6 +144,7 @@ struct console;
int getkeycode(unsigned int scancode);
int setkeycode(unsigned int scancode, unsigned int keycode);
void compute_shiftstate(void);
+void kbd_dbg_clear_keys(void);
/* defkeymap.c */
--
1.6.3.3
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
^ permalink raw reply related
* Re: [PATCH] Bluetooth: hci_uart: Fix typo in stats for sco tx
From: Gustavo F. Padovan @ 2010-10-07 20:35 UTC (permalink / raw)
To: Karl Beldan; +Cc: Jiri Kosina, linux-bluetooth, Marcel Holtmann
In-Reply-To: <1286481430-6761-1-git-send-email-karl.beldan@gmail.com>
Hi Karl,
* Karl Beldan <karl.beldan@gmail.com> [2010-10-07 21:57:10 +0200]:
> s/stat.cmd_tx++/stat.sco_tx++ for HCI_SCODATA_PKT
>
> Signed-off-by: Karl Beldan <karl.beldan@gmail.com>
> Cc: Marcel Holtmann <marcel@holtmann.org>
> ---
> drivers/bluetooth/hci_ldisc.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Good catch! Applied, Thanks.
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* Kernel Ooops when using kdesu
From: "Sven Müller" @ 2010-10-07 20:35 UTC (permalink / raw)
To: edward.shishkin; +Cc: reiserfs-devel
Hi Edward,
according to the advice in Gentoo Forums:
http://forums.gentoo.org/viewtopic-t-845764.html
I'll send you the bug report.
Behaviour:
When I try start a program via kdesu (KDE4) I'll get a Kernel Ooops. It's reproducible. The Ooops occurs on x86 and amd64. I've tested it on 2.6.34 and on 2.6.35 (r1 and r5). And until now it seems that only kdesu is affected.
Configuration:
Kernel: Gentoo-Sources-2.6.35-r5
Root Device is Reiser4
Reiser4 Patch is from Kernel.org (Reiser4-for-2.6.35.patch)
CPU: x86
The Posting in Gentoo Forums (Link) is from a amd64.
/var/log/messages:
Oct 7 22:26:32 localhost kernel: BUG: unable to handle kernel NULL pointer dereference at (null)
Oct 7 22:26:32 localhost kernel: IP: [<c01b846a>] checkin_logical_cluster+0xb1/0x176
Oct 7 22:26:32 localhost kernel: *pde = 00000000
Oct 7 22:26:32 localhost kernel: Oops: 0000 [#1]
Oct 7 22:26:32 localhost kernel: last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
Oct 7 22:26:32 localhost kernel: Modules linked in: pcmcia
Oct 7 22:26:32 localhost kernel:
Oct 7 22:26:32 localhost kernel: Pid: 2306, comm: kio_file Not tainted 2.6.35-gentoo-r5 #2 Latitude C610 /Latitude C610
Oct 7 22:26:32 localhost kernel: EIP: 0060:[<c01b846a>] EFLAGS: 00010246 CPU: 0
Oct 7 22:26:32 localhost kernel: EIP is at checkin_logical_cluster+0xb1/0x176
Oct 7 22:26:32 localhost kernel: EAX: 00000001 EBX: c9176d58 ECX: 00000000 EDX: 00000000
Oct 7 22:26:32 localhost kernel: ESI: 00000000 EDI: 00000000 EBP: cb572eb4 ESP: c9176d14
Oct 7 22:26:32 localhost kernel: DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
Oct 7 22:26:32 localhost kernel: Process kio_file (pid: 2306, ti=c9176000 task=cb376360 task.ti=c9176000)
Oct 7 22:26:32 localhost kernel: Stack:
Oct 7 22:26:32 localhost kernel: 00000000 c9176d58 00000000 cb572eb4 00000000 c9176d58 00000000 cb572eb4
Oct 7 22:26:32 localhost kernel: <0> 00000000 c01bacff 00000000 c9192100 00000000 0000000d cb572eb4 c01baf36
Oct 7 22:26:32 localhost kernel: <0> fffffff4 00000000 00000000 00000000 00000000 00000001 00000000 00000000
Oct 7 22:26:32 localhost kernel: Call Trace:
Oct 7 22:26:32 localhost kernel: [<c01bacff>] ? capture_page_cluster+0xa2/0xc7
Oct 7 22:26:32 localhost kernel: [<c01baf36>] ? write_end_cryptcompress+0x212/0x222
Oct 7 22:26:32 localhost kernel: [<c01b7455>] ? reiser4_write_end_careful+0xe8/0x153
Oct 7 22:26:32 localhost kernel: [<c0148127>] ? pagecache_write_end+0x37/0x3e
Oct 7 22:26:32 localhost kernel: [<c01ac107>] ? reiser4_dirty_inode+0x8/0x59
Oct 7 22:26:32 localhost kernel: [<c017c356>] ? pipe_to_file+0x109/0x114
Oct 7 22:26:32 localhost kernel: [<c01ac107>] ? reiser4_dirty_inode+0x8/0x59
Oct 7 22:26:32 localhost kernel: [<c01ac107>] ? reiser4_dirty_inode+0x8/0x59
Oct 7 22:26:32 localhost kernel: [<c017b3ff>] ? splice_from_pipe_feed+0x31/0x9e
Oct 7 22:26:32 localhost kernel: [<c017c24d>] ? pipe_to_file+0x0/0x114
Oct 7 22:26:32 localhost kernel: [<c017c1c0>] ? generic_file_splice_write+0xa2/0x12f
Oct 7 22:26:32 localhost kernel: [<c017c11e>] ? generic_file_splice_write+0x0/0x12f
Oct 7 22:26:32 localhost kernel: [<c017bca0>] ? vfs_splice_from+0x53/0x5a
Oct 7 22:26:32 localhost kernel: [<c017c093>] ? direct_splice_actor+0x14/0x18
Oct 7 22:26:32 localhost kernel: [<c017bb35>] ? splice_direct_to_actor+0xbe/0x172
Oct 7 22:26:32 localhost kernel: [<c017c07f>] ? direct_splice_actor+0x0/0x18
Oct 7 22:26:32 localhost kernel: [<c017bc34>] ? do_splice_direct+0x4b/0x64
Oct 7 22:26:32 localhost kernel: [<c0166440>] ? do_sendfile+0x16c/0x1b5
Oct 7 22:26:32 localhost kernel: [<c01664c9>] ? sys_sendfile64+0x40/0x86
Oct 7 22:26:32 localhost kernel: [<c0102510>] ? sysenter_do_call+0x12/0x26
Oct 7 22:26:32 localhost kernel: Code: 01 74 09 31 f6 83 f8 02 75 1e eb 05 8b 73 3c eb 17 8b 43 0c 31 ff 8b 70 04 03 30 81 c6 ff 0f 00 00 83 d7 00 0f ac fe 0c 8b 7b 48 <8b> 07 f6 c4 01 74 24 89 e8 e8 2f 4a fe ff e8 ac a3 fe ff 8b 4b
Oct 7 22:26:32 localhost kernel: EIP: [<c01b846a>] checkin_logical_cluster+0xb1/0x176 SS:ESP 0068:c9176d14
Oct 7 22:26:32 localhost kernel: CR2: 0000000000000000
Oct 7 22:26:32 localhost kernel: ---[ end trace 401667030bed02db ]---
addr2line -e /usr/src/linux/vmlinux -i c01b846a:
/usr/src/linux/fs/reiser4/plugin/file/cryptcompress.c:1722
/usr/src/linux/fs/reiser4/plugin/file/cryptcompress.c:1780
Let me know if you need any further information. I would be glad if I could help you.
Thx
Sven
--
GRATIS! Movie-FLAT mit über 300 Videos.
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.