* 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
* Re: [Qemu-devel] [STATUS] static instrumentation
From: Lluís @ 2010-10-07 20:34 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <AANLkTikdue6xCnBWtxAZhh4BMcR=nTjP9=V_jgPwGN2r@mail.gmail.com>
Blue Swirl writes:
> The patches there seem to be fixes or small changes to your other
> patches. This makes any review very difficult.
Sorry, I'm really new to git, so I don't really know how to maintain and
"grow" an organized set of patches for review while I keep improving the
work.
> But I'm not sure the architecture is what we'd like to see integrated
> in QEMU, though I may have missed the whole picture because of the
> patch fragmentation problem. Before doing any work to possibly go
> further in wrong direction, please try to submit early some preview
> version for comments and review.
I can try to refactor the changes into a sensible set of patches, but
please read first the motivation of this work (below).
> Just as an example, perhaps the existing tracing framework could be
> extended to cover also your needs.
Well, for what I've seen of the tracing infrastructure ("tracing" from
here on), it is geared towards tracing qemu internal events (for
analyzing qemu performance), while static instrumentation
("instrumentation" from here on) is geared towards tracing guest events,
in order to analyze guest behaviour.
The reason for having static instrumentation points in the form of
macros (diverging from the approach taken in tracing) is that the most
common instrumentation points are invoked at code generation time. This
way the user can dynamically select which extra code to call and/or
generate (if any) on each of these points, with the addition that code
can be selected for regeneration when the instrumentation points need to
produce different code (e.g., no instrumentation, event counting,
sketchy trace generation, detailed trace generation, etc.).
So, I think they are geared towards different goals, although they are
indeed composable (e.g., the user can expand the instrumentation macros
into calls to the tracing infrastructure).
Wether or not this fits into upstream qemu is not for me to say, but it
provides the initial stepping stone that is commonly used in computer
architecture research (e.g., http://www.ptlsim.org or
http://sesc.sourceforge.net/), with the added bonus that qemu supports
multiple ISAs, as well as executing standalone applications and a
full-fledged system.
Of course, the simulator itself would be out of qemu, thus the macros :)
Lluis
--
"And it's much the same thing with knowledge, for whenever you learn
something new, the whole world becomes that much richer."
-- The Princess of Pure Reason, as told by Norton Juster in The Phantom
Tollbooth
^ permalink raw reply
* Re: [PATCH 1/2] drivers:staging:ti-st: move TI_ST from staging
From: Alan Cox @ 2010-10-07 20:35 UTC (permalink / raw)
To: Savoy, Pavan
Cc: Jiri Slaby, gregkh@suse.de, linux-kernel@vger.kernel.org,
devel@driverdev.osuosl.org, linux-bluetooth
In-Reply-To: <19F8576C6E063C45BE387C64729E739404AA21D23B@dbde02.ent.ti.com>
> ldisc is the ONLY way to do it, isn't it? Do I have any other option?
Userspace but even then it wouldn't solve your problem
> The situation was something similar here.
> What I was trying to get to is how we can have a per-device context if a driver is just a line discipline driver?
tty->driver_data
TTY private data
tty->disc_data
LDISC per instance private data
So when your ldisc is opened attach your data to the tty->disc_data, and
when it is closed free the data.
> I have 3 sub-devices if you will on a device which is interfaced over UART,
> One of them is Bluetooth which requires any UART Bluetooth device to have its
> Own line discipline - N_HCI.
The problem is that your chip by the sound of it does not talk the
bluetooth ldisc - it talks something more complex.
The obvious question then is
Does it talk
1. HCI with bits nailed on
2. Something rather different which contains muxed data some of
which is reformatted up to create HCI
In the first case it may be worth seeing if the existing N_HCI could
support forwarding unknown frame types to a helper. In the latter it's a
lot trickier. It is possible to create a mux tty layer (see n_gsm.c) but
that is almost certainly overkill for this.
I wonder what Marcel thinks in terms of re-using the bluetooth ldisc ?
^ permalink raw reply
* Re: Trac+Git: rev-list with pathspec performance?
From: Jakub Narebski @ 2010-10-07 20:33 UTC (permalink / raw)
To: Stephen Bash; +Cc: Git Mailing List
In-Reply-To: <2595121.446745.1286473792827.JavaMail.root@mail.hq.genarts.com>
On Thu, 7 Oct 2010, Stephen Bash wrote:
>>> Note that there is proof of concept
>>> "tree blame" (in Perl) which generates such 'last change to file'
>>> information, I think faster than running 'git rev-list -1 <file>'
>>> for
>>> each file. Even better would be to encode used algorithm in C.
>>>
>>> http://thread.gmane.org/gmane.comp.version-control.git/150063/focus=150183
>>
>> My early experiments with your script are good for speed, but for some
>> reason I'm always getting the first commit for a file rather than the
>> most recent. I'll do some experimenting to see if I can uncover the
>> issue.
>
> Following up, I had to add -r to the diff-tree command line when
> requesting a subdirectory to work around the problem (script always
> returned the first commit).
Hmmm... I thought that I have added '-r' if there is path provided,
i.e. we don't run tree blame on root commit.
> I'm curious if it's faster to get the SHA of the sub-tree and compare
> that before actually running diff-tree? And for that matter, just run
> diff-tree on the sub-tree that we care about rather than a recursive
> sub-tree on the root? These may be early optimizations, but they're
> ideas that occurred to me while debugging the code...
There are many possible optimizations (see also below); for the time
being I was concerned with getting the fast tree blame algorithm right
(and as you can see didn't get it, not completely).
>>> P.S. Alternate solution would be to simply get rid of SVN-inspired
>>> view. Git tracks history of a *project* as a whole, not set of
>>> histories for individual files (like CVS).
>
> After a lot of experimentation, this is basically what we did.
> I modified the Trac templates to not list the last change SHA or log
> message in the directory view. After all my testing, I just don't
> think there's a fast way to get this information from Git. This
> blame-dir script is the fastest alternative I've tried (about 5x
> faster than rev-list'ing each file), but it's still ~30 seconds on my
> machine (which is faster than our web server), and IMHO that's too
> long to ask a user to wait for a page to load.
First, there is lot of room for optimization of tree blame script, some
of which I have noted as comments, some which you have found. During
developing this script I noticed that current plumbing doesn't completly
fit the tree blame algorithm; for example we need '-r' for blaming
subtree (subdirectory), while we need paths only up to depth of blamed
directory, no more.
Rewriting tree-blame in C, using in-core revision and tree traversal
should be faster, though I'm not sure how much would that be.
Unfortunately I don't know enough git API; I thought that writing
Perl script would be easier.
But you are right in that such view would always be expensive in Git,
because Git tracks history of porject *as a whole*. If file was
created in root commit (first commit) and left unchanged, it would be
easy to find in VCS that stored history on per-file basis at least to
some extent; in git you have to go through comit up till the root
commit in this case. If history is long, it might take some time.
Second, you can use the trick that GitHub web interface uses to display
similar view, namely in displaying first just a tree of files, and then
incrmentally filling in 'last changed' info. Gitweb does something
similar in 'blame_incremental' view; that is why the idea was to have
tree blame ("git blame <directory>") to have support for incremental
format, similar to an ordinary blame.
This might take some effort to develop, though...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: OT: compilation
From: Pekka Paalanen @ 2010-10-07 20:34 UTC (permalink / raw)
To: Grzesiek Sójka; +Cc: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <4CAE2A1B.1000105-t9zbU3WrWHI@public.gmane.org>
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
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.
> 2. I modified the sources and after compilation the string
> "g76f6e1f-dirty" was appended to the kernel version. It is a bit
> annoying because of the lack of the space at the rootfs. Is there
> a way to avoid this kind of a version extension??
Yes, it is CONFIG_LOCALVERSION_AUTO as far as I recall, disable that.
--
Pekka Paalanen
http://www.iki.fi/pq/
^ 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.