twitter: linux.kernel - 26 new messages in 18 topics

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

Today's topics:

* af_packet: Don't use skb after dev_queue_xmit() - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/8e6b471b3077e37d?hl=en
* [RFC][PATCH] PM / Runtime: Add sysfs switch for disabling device run-time PM
- 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/59fe82d258aa2e2e?hl=en
* perf_events: improve x86 event scheduling (v5) - 3 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/aa79a791dda64750?hl=en
* xt_TCPMSS: SYN packets are allowed to contain data - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/7af1dfafd71400c2?hl=en
* "USB: use kfifo to buffer usb-generic serial writes" causes gobi_loader to
hang - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/24244e271ec4cffc?hl=en
* staging/dream: add missing include files/fix compilation - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/3de505808c3a3d4b?hl=en
* HW breakpoints perf_events request - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/26bf165e502a9000?hl=en
* Font selection with i915 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/1b720d049c91ab04?hl=en
* linux-next: Tree for January 12 (unlzo) - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/437a0b0074ca8e69?hl=en
* [PATCH] Fix indentation of the comments of do_migrate_pages - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/c54cc9abfe6c35d8?hl=en
* kconfig: dont hardcode path to lsmod - 3 messages, 3 authors
http://groups.google.com/group/linux.kernel/t/165dca96f1661d72?hl=en
* introduce sys_membarrier(): process-wide memory barrier (v5) - 2 messages, 2
authors
http://groups.google.com/group/linux.kernel/t/cd9d826251979299?hl=en
* x86: check range in update range - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/00dfba37428cbc3a?hl=en
* x86: move range related operation to one file - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/c09ad816aef8e274?hl=en
* Add "handle page fault" PV helper. - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/3f9936b06aed63f6?hl=en
* what's up with "make -j N" output? - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/c8655e0ed48dafd9?hl=en
* perf kmem: Print usage help for unknown commands - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/c78b183051f75dbc?hl=en
* perf kmem: Increase "Hit" column length - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/4d6a1837aedeb490?hl=en

==============================================================================
TOPIC: af_packet: Don't use skb after dev_queue_xmit()
http://groups.google.com/group/linux.kernel/t/8e6b471b3077e37d?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 19 2010 7:50 am
From: Michael Breuer

On 1/19/2010 5:47 AM, Jarek Poplawski wrote:
> On Tue, Jan 19, 2010 at 12:46:24AM -0500, Michael Breuer wrote:
>
>> Ok - one last update for a while ...not sure what's next... I put some
>> printk's into sky2.c xmit logic - the packets are being sent to the
>>
> ...
>
> Btw, could you try if this patch can makes difference in triggering
> the "lib/dma-debug.c:898" warning?
>
> Jarek P.
> ---
>
> drivers/net/sky2.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
> index 7650f73..e02e9e9 100644
> --- a/drivers/net/sky2.c
> +++ b/drivers/net/sky2.c
> @@ -2479,6 +2479,9 @@ static int sky2_status_intr(struct sky2_hw *hw, int to_do, u16 idx)
>
> port = le->css& CSS_LINK_BIT;
> dev = hw->dev[port];
> + if (!netif_running(dev))
> + continue;
> +
> sky2 = netdev_priv(dev);
> length = le16_to_cpu(le->length);
> status = le32_to_cpu(le->status);
>
Still get the warning... but now 60 bytes.
Jan 19 10:43:50 mail kernel: ------------[ cut here ]------------
Jan 19 10:43:50 mail kernel: WARNING: at lib/dma-debug.c:902
check_sync+0xc1/0x43f()
Jan 19 10:43:50 mail kernel: Hardware name: System Product Name
Jan 19 10:43:50 mail kernel: sky2 0000:04:00.0: DMA-API: device driver
tries to sync DMA memory it has not allocated [device
address=0x0000000320a0b022] [size=60 bytes]
Jan 19 10:43:50 mail kernel: Modules linked in: microcode(+)
ip6table_filter ip6table_mangle ip6_tables iptable_raw iptable_mangle
ipt_MASQUERADE iptable_nat nf_nat appletalk psnap llc nfsd lockd nfs_acl
auth_rpcgss exportfs hwmon_vid coretemp sunrpc acpi_cpufreq sit tunnel4
ipt_LOG nf_conntrack_netbios_ns nf_conntrack_ftp xt_DSCP xt_dscp xt_MARK
nf_conntrack_ipv6 xt_multiport ipv6 dm_multipath kvm_intel kvm
snd_hda_codec_analog snd_ens1371 gameport snd_rawmidi snd_ac97_codec
snd_hda_intel ac97_bus snd_hda_codec snd_hwdep snd_seq snd_seq_device
snd_pcm gspca_spca505 snd_timer gspca_main firewire_ohci snd soundcore
videodev i2c_i801 firewire_core v4l1_compat snd_page_alloc
v4l2_compat_ioctl32 pcspkr wmi crc_itu_t iTCO_wdt iTCO_vendor_support
asus_atk0110 sky2 hwmon fbcon tileblit font bitblit softcursor raid456
async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx
raid1 ata_generic pata_acpi pata_marvell nouveau ttm drm_kms_helper drm
agpgart fb i2c_algo_bit cfbcopyarea i2c_core cfbimgblt cfbf
Jan 19 10:43:50 mail kernel: illrect [last unloaded: ip6_tables]
Jan 19 10:43:50 mail kernel: Pid: 0, comm: swapper Not tainted
2.6.32.4MMAPNODMARAF3SKY2PSKBMAYPULL-00912-g914160d-dirty #3
Jan 19 10:43:50 mail kernel: Call Trace:
Jan 19 10:43:50 mail kernel: <IRQ> [<ffffffff810536ee>]
warn_slowpath_common+0x7c/0x94
Jan 19 10:43:50 mail kernel: [<ffffffff8105375d>]
warn_slowpath_fmt+0x41/0x43
Jan 19 10:43:50 mail kernel: [<ffffffff8127b871>] check_sync+0xc1/0x43f
Jan 19 10:43:50 mail kernel: [<ffffffff8107a683>] ?
timekeeping_get_ns+0x1b/0x3d
Jan 19 10:43:50 mail kernel: [<ffffffff813c6770>] ?
__netdev_alloc_skb+0x34/0x50
Jan 19 10:43:50 mail kernel: [<ffffffff8127bf42>]
debug_dma_sync_single_for_cpu+0x42/0x44
Jan 19 10:43:50 mail kernel: [<ffffffff812792c7>] ?
swiotlb_sync_single+0x2a/0xb6
Jan 19 10:43:50 mail kernel: [<ffffffff81279423>] ?
swiotlb_sync_single_for_cpu+0xc/0xe
Jan 19 10:43:50 mail kernel: [<ffffffffa0155ee0>] sky2_poll+0x4d0/0xaeb
[sky2]
Jan 19 10:43:50 mail kernel: [<ffffffff813cd40e>] net_rx_action+0xb5/0x1f3
Jan 19 10:43:50 mail kernel: [<ffffffff8105af0f>] __do_softirq+0xf8/0x1cd
Jan 19 10:43:50 mail kernel: [<ffffffff810a3006>] ?
handle_IRQ_event+0x119/0x12b
Jan 19 10:43:50 mail kernel: [<ffffffff81012e1c>] call_softirq+0x1c/0x30
Jan 19 10:43:50 mail kernel: [<ffffffff810143a3>] do_softirq+0x4b/0xa6
Jan 19 10:43:50 mail kernel: [<ffffffff8105aaef>] irq_exit+0x4a/0x8c
Jan 19 10:43:50 mail kernel: [<ffffffff8146c095>] do_IRQ+0xa5/0xbc
Jan 19 10:43:50 mail kernel: [<ffffffff81012613>] ret_from_intr+0x0/0x16
Jan 19 10:43:50 mail kernel: <EOI> [<ffffffff812c2f6e>] ?
acpi_idle_enter_bm+0x256/0x28a
Jan 19 10:43:50 mail kernel: [<ffffffff812c2f67>] ?
acpi_idle_enter_bm+0x24f/0x28a
Jan 19 10:43:50 mail kernel: [<ffffffff813a279c>] ?
cpuidle_idle_call+0x9e/0xfa
Jan 19 10:43:50 mail kernel: [<ffffffff81010c90>] ? cpu_idle+0xb4/0xf6
Jan 19 10:43:50 mail kernel: [<ffffffff814616d2>] ?
start_secondary+0x201/0x242
Jan 19 10:43:50 mail kernel: ---[ end trace 310dbc8966610916 ]---

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: [RFC][PATCH] PM / Runtime: Add sysfs switch for disabling device run-
time PM
http://groups.google.com/group/linux.kernel/t/59fe82d258aa2e2e?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 19 2010 7:50 am
From: Alan Stern

On Mon, 18 Jan 2010, Rafael J. Wysocki wrote:

> > Ouch. This does nearly the same thing as the power/level attribute in
> > the USB subsystem, but in an incompatible and more complicated way.
> >
> > The power/level attribute can contain either "on" or "auto", meaning
> > that the device is always on or that it is subject to automatic runtime
> > power management (autosuspend).
>
> It looks like my "disable" is similar to "on", while my "enable" is similar to
> "auto". I can use "auto" and "on" just fine.

Good.

> > Changing the setting from "auto" to "on" merely does sets a flag and does
> > pm_runtime_get_sync(); changing it from "on" to "auto" clears the flag and
> > does pm_runtime_put_sync().
>
> We can do it almost this way in general, although I think the flag should be
> changed under the power.lock.

Yes. I was using the device semaphore, but the power.lock is more
appropriate here.

> Updated patch is appended.

Why change the name from "level" to "runtime"?

> /*
> + * runtime - Report/change current runtime PM setting of the device
> + *
> + * Runtime power management of a device can be blocked with the help of
> + * this attribute. All devices have one of the following two values for
> + * the power/runtime file:
> + *
> + * + "auto\n" to allow the device to be power managed at run time;
> + * + "on\n" to prevent the device from being power managemed at run time;

---------------------------------------------------------------^^ typo

Don't forget to add an entry to Documentation/ABI/testing/.

Alan Stern

==============================================================================
TOPIC: perf_events: improve x86 event scheduling (v5)
http://groups.google.com/group/linux.kernel/t/aa79a791dda64750?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Jan 19 2010 7:50 am
From: Frederic Weisbecker

On Tue, Jan 19, 2010 at 01:22:53PM +0100, Peter Zijlstra wrote:
> On Mon, 2010-01-18 at 18:29 +0100, Frederic Weisbecker wrote:
>
> > It has constraints that only need to be checked when we register
> > the event. It has also constraint on enable time but nothing
> > tricky that requires an overwritten group scheduling.
>
> The fact that ->enable() can fail makes it a hardware counter. Software
> counters cannot fail enable.
>
> Having multiple groups of failable events (multiple hardware pmus) can
> go wrong with the current core in interesting ways, look for example at
> __perf_event_sched_in():
>
> It does:
>
> int can_add_hw = 1;
>
> ...
>
> list_for_each_entry(event, &ctx->flexible_groups, group_entry) {
> /* Ignore events in OFF or ERROR state */
> if (event->state <= PERF_EVENT_STATE_OFF)
> continue;
> /*
> * Listen to the 'cpu' scheduling filter constraint
> * of events:
> */
> if (event->cpu != -1 && event->cpu != cpu)
> continue;
>
> if (group_can_go_on(event, cpuctx, can_add_hw))
> if (group_sched_in(event, cpuctx, ctx, cpu))
> can_add_hw = 0;
> }
>
> Now, if you look at that logic you'll see that it assumes there's one hw
> device since it only has one can_add_hw state. So if your hw_breakpoint
> pmu starts to fail we'll also stop adding counters to the cpu pmu (for
> lack of a better name) and vs.

Indeed.

>
> This might be fixable by using per-cpu struct pmu variables.

Yeah or just a mask instead of can_add_hw that can testify
a given pmu type couldn't be scheduled anymore?

We can extend struct perf_event:group_flags:

enum perf_group_flag {
PERF_GROUP_NO_HARDWARE = 0x1,
PERF_GROUP_NO_BREAKPOINT = 0x2
PERF_GROUP_SOFTWARE = PERF_GROUP_NO_HARDWARE | PERF_GROUP_NO_BREAKPOINT;
};

Looks easy to maintain and to use for quick bitwise check
on flexible groups scheduling.

> However I'm afraid its far to late to push any of that into .33, which
> means .33 will have rather funny behaviour once the breakpoints start
> getting used.

No. Because for now it is not supposed to happen that a breakpoint
can't be scheduled.

We have constraints that check whether a pinned breakpoint will
always be able to go in, on registration. Similarly we have
constraints for flexible ones, to ensure it's possible for these
to be scheduled. But these are broken because of the non-strict
ordering between pinned and non-pinned events.

Anyway, the point is that for now we treat flexible breakpoints
as if these were pinned, so a breakpoint is not supposed to
be unschedulable, ever. So .33 is not broken.

But we need to fix what you described for .34, because once we
get a strict ordering between pinned and flexible, I'm going
to reactivate the breakpoint constraints for flexibles.

== 2 of 3 ==
Date: Tues, Jan 19 2010 8:00 am
From: Frederic Weisbecker

On Tue, Jan 19, 2010 at 02:24:49PM +0100, Peter Zijlstra wrote:
> Hrmph, so I read some of that hw_breakpoint stuff, and now I'm sorta
> confused, it looks like ->enable should never fail, but that means you
> cannot overcommit breakpoints, which doesn't fit the perf model nicely.

Yeah :)
I described this in my previous mail to you. Breakpoint events, for
now, are not supposed to fail on enable().

But once we have the strict pinned -> flexible ordering,
I'll rework this.

> Also, I see you set an ->unthrottle, but then don't implement it, but
> comment it as todo, which is strange because that implies its broken. If
> there's an ->unthrottle method it will throttle, so if its todo, the
> safest thing is to not set it.

Yeah, that's because I have a too vague idea on what is the purpose
of the unthrottle() callback.

I've read the concerned codes that call this, several times, and I still
can't figure out what happens there, not sure what is meant by throttle
or unthrottle there :-/

> /me mutters something and goes look at something else for a while.

Yeah, that's still a young code that needs improvement :)

== 3 of 3 ==
Date: Tues, Jan 19 2010 8:40 am
From: Peter Zijlstra

On Tue, 2010-01-19 at 16:55 +0100, Frederic Weisbecker wrote:
> > Also, I see you set an ->unthrottle, but then don't implement it, but
> > comment it as todo, which is strange because that implies its broken. If
> > there's an ->unthrottle method it will throttle, so if its todo, the
> > safest thing is to not set it.
>
>
> Yeah, that's because I have a too vague idea on what is the purpose
> of the unthrottle() callback.
>
> I've read the concerned codes that call this, several times, and I still
> can't figure out what happens there, not sure what is meant by throttle
> or unthrottle there :-/

OK, so not setting it is relatively safe.

As to what it does, it has to undo everything you do when
perf_event_overflow() returns true, which happens when ->unthrottle is
set and we get more than sysctl_perf_event_sample_rate/HZ events in a
jiffy.

If you look at the x86 implementation, you'll see that we simply disable
the hardware counter when the overflow call returns true, so the
unthrottle() callback simply enables it again.

==============================================================================
TOPIC: xt_TCPMSS: SYN packets are allowed to contain data
http://groups.google.com/group/linux.kernel/t/7af1dfafd71400c2?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 19 2010 7:50 am
From: William Allen Simpson

Simon Arlott wrote:
> On Tue, January 19, 2010 09:17, William Allen Simpson wrote:
>> 2) There certainly *can* be data on SYN. That code is already in
>> 2.6.33....
>
> I could change the comment too, but the same logic applies when
> there is data and no MSS option - the packet can't be increased
> in size if it would then exceed 576 bytes and/or the destination
> MTU.
>
Please change the comment.

If there is no MSS option, it should *not* be added, under *ANY*
circumstances. That violates the end-to-end arguments (some call
them principles).

MSS isn't about the _destination_ MTU, it's about the *source*.
If you cannot guarantee you know the source MTU, there's no basis
for deciding the MSS.

While I understand that sometimes it's useful to reduce (never,
NEVER, *NEVER* increase) the MSS as a packet goes into a tunnel
(because there are problems in some NAT'd networks with determining
Path MTU via ICMP), I'm not aware of any circumstance where the MSS
would need to be reduced below 536.

I'm having some difficulty figuring out how this code originated --
with a nice log entry explaining the exact manufacturer's device
and network topology that the contributor had in mind?

> If it's possible to know that the packet can have an additional
> option added without exceeding MTU then this could be changed.
> The data part would need to be moved to make space at the end of
> the header.
>
No options should be added to TCP in a router -- ever!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: "USB: use kfifo to buffer usb-generic serial writes" causes gobi_loader
to hang
http://groups.google.com/group/linux.kernel/t/24244e271ec4cffc?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Jan 19 2010 8:00 am
From: Johan Hovold

> > > The log shows no call to usb_serial_generic_write_room()
> > > Do you consider this a bug in the tty layer?
> >
> > Actually this all makes sense because of where it was hanging. A reply of
> > 0 to the tty->ops->write will cause it to either return (O_NONBLOCK) or
> > sleep in the n_tty write code waiting for a write_wait wakeup
> > (tty_wakeup(tty))
> >
> > So the fix does indeed look correct.
>
> Is it really a fix? If the fifo is already full the write urb should be
> in use and Oliver's patch would amount to only a minor optimisation as
> usb_serial_generic_write_start would return 0 anyway.

So the question seems to be: why doesn't the on-going transfer finish (so
that tty_wakeup is called)?

> drivers/usb/serial/usb-serial.c: usb_serial_port_work - port 0
> drivers/usb/serial/usb-serial.c: serial_write - port 0, 29 byte(s)
> drivers/usb/serial/generic.c: usb_serial_generic_write - port 0, 29
> bytes
> drivers/usb/serial/generic.c: usb_serial_generic_write - put 0 bytes
> into fifo

Writer got woken but fifo is still full so write returns 0 and writer goes
back to sleep.

> drivers/usb/serial/generic.c: usb_serial_generic_write_bulk_callback -
> port 0
> drivers/usb/serial/generic.c: usb_serial_generic_write_start - starting
> IO
> qcserial ttyUSB0: usb_serial_generic_write_start - length = 512, data =
> f0 f8 0a 01 f0 00 0b 01 f0 0c 10 01 f0 38 10 01 f0 0f 22 a0 e3 04 40 92
> e5 1c 30 94 e5 a3 32 a0 e1 7f 3f c3 e3 ff 33 c3 e3 0f 35 c3 e3 0e 12 83
> e2 08 00 91 e5 00 00 50 e3 0a 00 00 0a 0a 20 d0 e5 02 00 52 e3 0d 00 00
> 0a 60 31 91 e5 0a 30 c0 e5 64 21 91 e5 0b 20 c0 e5 38 10 81 e2 44 30 91
> e5 c0 30 c3 e3 44 30 81 e5 04 00 a0 e1 96 fc ff eb 50 31 94 e5 fe df 8d
> e3 03 f0 a0 e1 fe ff ff ea 08 30 94 e5 0a 20 c3 e5 38 20 84 e2 44 30 92
> e5 80 30 83 e3 44 30 82 e5 ea ff ff ea 02 60 a0 e1 01 50 a0 e1 04 d0 4d
> e2 00 70 a0 e1 03 80 a0 e1 4d ff ff eb a5 2f a0 e1 86 30 82 e1 00 00 a0
> e3 2f 20 e0 e3 00 00 8d e5 b2 20 cd e1 00 10 9d e5 03 19 81 e3 00 10 8d
> e5 a6 4f a0 e1 a3 20 a0 e1 84 3f 82 e1 08 20 97 e5 48 30 82 e5 0f 32 a0
> e3 40 10 82 e5 0c 00 82 e5 44 50 82 e5 04 10 93 e5 2c 30 91 e5 e4 00 97
> e5 20 20 9f e5 01 30 83 e3 2c 30 81 e5 80 20 87 e5 50 81 87 e5 10 30 9f
> e5 00 10 a0 e1 0c e0 9f e5 03 f0 a0 e1 fe ff ff ea 20 81 00 f0 8c 89 00
> f0 10 b6 00 f0 0f 32 a0 e3 04 40 93 e5 08 20 94 e5 40 30 92 e5 04 d0 4d
> e2 00 30 8d e5 04 00 a0 e1 5b fc ff eb d1 30 dd e1 00 00 53 e3 03 00 00
> ba 50 31 94 e5 fe df 8d e3 03 f0 a0 e1 fe ff ff ea 04 00 9f e5 73 05 00
> eb f8 ff ff ea 4c 10 01 f0 0f c2 a0 e3 18 40 dc e5 18 d0 4d e2 00 00 54
> e3 0e 60 a0 e1 14 00 8d e5 01 a0 a0 e1 10 20 8d e5 03 90 a0 e1 20 b0 9d
> e5 51 01 00 1a 0f 32 a0 e3 04 80 93 e5 50 26 9f e5 0c 30 98 e5 00 10 92
> e5 01 00 53 e1 00 00 a0 13 01 00 a0 03 00 00 50 e3 41 01 00 0a 14 50 9d
> e5 01 20 75 e2 00 20 a0 33 00 00 52 e3 0d 00 00 1a b4 31 dd e1 3f 00 13
> e3 02 30 a0 e1 03 00 00

New transfer started from completion handler.

> drivers/usb/serial/usb-serial.c: usb_serial_port_work - port 0

Writer woken up from completion handler after having started the
next transfer.

> drivers/usb/serial/usb-serial.c: serial_write - port 0, 29 byte(s)
> drivers/usb/serial/generic.c: usb_serial_generic_write - port 0, 29
> bytes
> drivers/usb/serial/generic.c: usb_serial_generic_write - put 29 bytes
> into fifo
> drivers/usb/serial/usb-serial.c: serial_write - port 0, 2048 byte(s)
> drivers/usb/serial/generic.c: usb_serial_generic_write - port 0, 2048
> bytes
> drivers/usb/serial/generic.c: usb_serial_generic_write - put 483 bytes
> into fifo
> drivers/usb/serial/usb-serial.c: serial_write - port 0, 1565 byte(s)
> drivers/usb/serial/generic.c: usb_serial_generic_write - port 0, 1565
> bytes
> drivers/usb/serial/generic.c: usb_serial_generic_write - put 0 bytes
> into fifo

Now there was some room (29 + 483 = 512 bytes bytes just transfered).

> drivers/usb/serial/generic.c: usb_serial_generic_read_bulk_callback -
> port 0

Waiting forever for on-going transfer to finish...

== 2 of 2 ==
Date: Tues, Jan 19 2010 8:30 am
From: Alan Cox

On Tue, 19 Jan 2010 16:25:36 +0100
Johan Hovold <jhovold@gmail.com> wrote:

IF the write returns a zero then it will sleep in n_tty waiting for a
wakeup when the FIFO level drops sufficiently. If that isn't working
check that all cases where data is cleared from the FIFO called
tty_wakeup and do so *after* the FIFO has been partly emptied and the
locking has ensured the space is visible to the write side.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: staging/dream: add missing include files/fix compilation
http://groups.google.com/group/linux.kernel/t/3de505808c3a3d4b?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 19 2010 8:00 am
From: Greg KH

On Tue, Jan 19, 2010 at 06:45:17AM +0100, Pavel Machek wrote:
> On Thu 2010-01-14 16:24:19, Greg KH wrote:
> > On Fri, Dec 25, 2009 at 09:59:18PM +0100, Pavel Machek wrote:
> > > This adds missing include files, so it should now compile. ifdef
> > > guards were added to Kconfig, so it should not cause problems on
> > > non-arch-msm machines.
> > >
> > > Signed-off-by: Pavel Machek <pavel@ucw.cz>
> >
> > Odd, this doesn't apply to the linux-next tree, some of the files are
> > already there.
>
> Strange, it seems it is almost all already in. Well, good :-).
>
> But there's small problem. linux-next now contains dwalker's tree, and
> I could not get it to compile, even with staging disabled. I'll need
> to look into that.
>
> Here are remaining few patches, now easy to read. (It also shows that
> at least CONFIG_AMSS_VERSION and CONFIG_GPIO should really be in
> arch/arm. I believe it will get there in .34 or so...)
>
> ---
>
> Guard whole dream/ specific Kconfig with CONFIG_DREAM so that we don't
> cause compile failures in other architectures. Add missing pieces so
> that it compiles.
>
> I am not sure if this is ready for staging. I guess we should wait
> till I get tree to compile in -next...?

Ok, I'll wait for you to get things building. Feel free to send the
patch to me after that.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: HW breakpoints perf_events request
http://groups.google.com/group/linux.kernel/t/26bf165e502a9000?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Jan 19 2010 8:30 am
From: Frederic Weisbecker

On Tue, Jan 19, 2010 at 10:12:10AM -0500, Frank Ch. Eigler wrote:
> Hi -
>
> > > > [...]
> > > > What about extending ptrace to support a new type of
> > > > breakpoint debugging interface?
> > >
> > > This is the sort of reason why the utrace-gdbstub prototype was
> > > constructed. It should allow in-kernel implementation of the
> > > multithreaded gdb extensions. (By the way, it can already use uprobes
> > > rather than userspace-managed breakpoints.)
> >
> > Can utrace somehow meet Joshua's needs?
>
> Not directly, I'm afraid. I jumped in at a late stage of the thread
> that got a bit away from Joshua's original note
> (http://lkml.org/lkml/2010/1/13/490). OTOH, it could be made to work
> a few different ways.
>
> One is a systemtap or hand-written module that maps selected
> perf-event hits in the kernel to an application SIGTRAP.

Yeah would work.

But I rather hope we can extend ptrace interface to handle
such new needs instead (ie: having a more scalable breakpoint
interface support by ptrace).

> Another is using the gdbstub, extended with gdb watchpoint support (Z*
> packets), which would tie into the hw-breakpoint system directly.
> Joshua's application would manage the debug registers by means of a
> userspace supervisor process sending the appropriate Z* packets to the
> gdbstub, and otherwise letting the program run. When a watchpoint
> fires, the supervisor process can instruct gdbstub to send a SIGTRAP
> to the application. In this scenario, the perf syscall / subsystem is
> not used at all.

Is this gdbstub an interface to utrace?

This: http://lwn.net/Articles/364268/ ?

>
> > I'm not sure what kind of interface it can offer for that. The fact
> > is I don't know very well utrace :)
>
> That's ok. utrace is an in-kernel API for process management. ptrace
> and the RFC gdbstub are two possible userspace interfaces tuned for
> third-party debugging.

Ok.

>
> > Do you plan a resubmission soon?
>
> Utrace core has been resubmitted at the end of December
> (http://lkml.org/lkml/2009/12/17/466), with no further comments
> received.

Hmm, there has been deep review from Peter, IIRC.

> I hope it gets plopped into linux-next ASAP and merged next
> time. The gdbstub was an RFC only at this stage, but if other people
> get excited about it, we're happy to spiff it up for proposed merging.

Ok.

Thanks.

== 2 of 2 ==
Date: Tues, Jan 19 2010 8:40 am
From: Peter Zijlstra

On Tue, 2010-01-19 at 17:21 +0100, Frederic Weisbecker wrote:
>
>
> Hmm, there has been deep review from Peter, IIRC.

I did provide some feedback on an earlier version, didn't get around to
look at the latest. Also I didn't cover all of it.

==============================================================================
TOPIC: Font selection with i915
http://groups.google.com/group/linux.kernel/t/1b720d049c91ab04?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 19 2010 8:40 am
From: James Simmons

> When Fedora 12 loads i915 during initramfs probing on my system, the
> driver automatically installs a tiny 160x64 font. How can I prevent it
> from doing this, or tell it to use a larger 80x25 font instead?
>
> Is this documented anywhere?

Not really. Here is how you enable larger fonts. Configure your kernel. Go
into the Graphics support menu. This the the menu that has the
DRI/Framebuffer and backlight options. You will see a "Console display
driver support" option. Select it and you will have a new menu. You will
see the option "Select compiled-in fonts". Enable that and select the font
you want. Most likely it will be the Sun 12x22 font. Build your kernel.

Their might be one more setup to do. Some distros like to load a console
font at boot up. Depending on the distro if that is the case you will have
to disable it.

> In addition, are the error messages in the following dmesg log anything
> to be concerned about? They appear during every boot:
>
>
> [drm] Initialized drm 1.1.0 20060810
> i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
> i915 0000:00:02.0: setting latency timer to 64
> fbcon: inteldrmfb (fb0) is primary device
> render error detected, EIR: 0x00000010
> [drm:i915_handle_error] *ERROR* EIR stuck: 0x00000010, masking
> render error detected, EIR: 0x00000010
> [drm] DAC-5: set mode 1280x1024 16
> Console: switching to colour frame buffer device 160x64
> fb0: inteldrmfb frame buffer device
> registered panic notifier
> [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0

No idea here.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: linux-next: Tree for January 12 (unlzo)
http://groups.google.com/group/linux.kernel/t/437a0b0074ca8e69?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 19 2010 8:40 am
From: Randy Dunlap

On Wed, 13 Jan 2010 00:26:56 +0000 Phillip Lougher wrote:

> On Tue, Jan 12, 2010 at 11:22 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > Hi Randy,
> >
> > On Tue, 12 Jan 2010 08:30:13 -0800 Randy Dunlap <randy.dunlap@oracle.com> wrote:
> >>
> >> arch/x86/boot/compressed/../../../../lib/decompress_unlzo.c:53: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'parse_header'
> >> arch/x86/boot/compressed/../../../../lib/decompress_unlzo.c:90: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'unlzo'
> >>
> >> Problem is the "INIT" there, seems to be undefined.
> >
> > Caused by an interaction between Linus' tree and the squashfs tree that
> > is being worked on. It should not occur with today's linux-next as the
> > squashfs changes have been removed pending a fix.
>
> This problem is caused by the introduction of the unlzo code in Linus'
> tree, and some patches in
> the squashfs-next tree that move things out of
> include/linux/decompress/mm.h into separate
> xxx_mm.h files for each decompressor. These parches were, obviously,
> done before the unlzo
> code was present.
>
> I've fixed the patches in the squashfs-next tree for unlzo, and the
> breakage should be fixed :-)

linux-next-20100119 .. still happening.

---
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: [PATCH] Fix indentation of the comments of do_migrate_pages
http://groups.google.com/group/linux.kernel/t/c54cc9abfe6c35d8?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 19 2010 8:40 am
From: Christoph Lameter

Reviewed-by: Christoph Lameter <cl@linux-foundation.org>

==============================================================================
TOPIC: kconfig: dont hardcode path to lsmod
http://groups.google.com/group/linux.kernel/t/165dca96f1661d72?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Jan 19 2010 8:40 am
From: Steven Rostedt

On Tue, 2010-01-19 at 17:29 +0100, John Kacur wrote:

> diff --git a/scripts/kconfig/streamline_config.pl b/scripts/kconfig/streamline_config.pl
> index 0d80082..1803d2e 100644
> --- a/scripts/kconfig/streamline_config.pl
> +++ b/scripts/kconfig/streamline_config.pl
> @@ -238,7 +238,8 @@ foreach my $makefile (@makefiles) {
> my %modules;
>
> # see what modules are loaded on this system
> -open(LIN,"/sbin/lsmod|") || die "Cant lsmod";
> +# If lsmod isn't in the sbin dir, check if it is in the path
> +open(LIN,"/sbin/lsmod|") || open(LIN,"lsmod|") || die "Cant lsmod";

I've tried this before, but it gives an error that the "|" pipe failed.

-- Steve

> while (<LIN>) {
> next if (/^Module/); # Skip the first line.
> if (/^(\S+)/) {

== 2 of 3 ==
Date: Tues, Jan 19 2010 8:40 am
From: John Kacur

>> On Tue, Jan 19, 2010 at 01:52:00AM -0500, Mike Frysinger wrote:
>> The lsmod utility has always been installed into /bin with the newer
>> module-init-tools package, so let lsmod be found via PATH instead of
>> hardcoding the old modutils /sbin path.
>>
>
> Some distro doesn't set /sbin to PATH, so for me a better solution
> would be making PATH contain /sbin, and then use "lsmod".

How about the following solution then? (Warning, untested)

From 6a98295f6dc260d13e1abb39210a2a832c9bdd1f Mon Sep 17 00:00:00 2001
From: John Kacur <jkacur@redhat.com>
Date: Tue, 19 Jan 2010 17:10:48 +0100
Subject: [PATCH] kconfig: If lsmod is not in the /sbin, check the path
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

Mike Frysinger reported that lsmod is installed in /bin on newer kernels
which causes a problem when we hardcode the path to /sbin

However, Américo Wang reports that some distros don't have /sbin in PATH,
so you can't just let lsmod be found via PATH.

So, first check if lsmod is at /sbin/lsmod, and then check PATH if that fails.

Signed-off-by: John Kacur <jkacur@redhat.com>
---
scripts/kconfig/streamline_config.pl | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/scripts/kconfig/streamline_config.pl b/scripts/kconfig/streamline_config.pl
index 0d80082..1803d2e 100644
--- a/scripts/kconfig/streamline_config.pl
+++ b/scripts/kconfig/streamline_config.pl
@@ -238,7 +238,8 @@ foreach my $makefile (@makefiles) {
my %modules;

# see what modules are loaded on this system
-open(LIN,"/sbin/lsmod|") || die "Cant lsmod";
+# If lsmod isn't in the sbin dir, check if it is in the path
+open(LIN,"/sbin/lsmod|") || open(LIN,"lsmod|") || die "Cant lsmod";
while (<LIN>) {
next if (/^Module/); # Skip the first line.
if (/^(\S+)/) {
--
1.6.0.6

== 3 of 3 ==
Date: Tues, Jan 19 2010 9:30 am
From: Mike Frysinger

On Tue, Jan 19, 2010 at 09:25, Américo Wang wrote:
> On Tue, Jan 19, 2010 at 01:52:00AM -0500, Mike Frysinger wrote:
>>The lsmod utility has always been installed into /bin with the newer
>>module-init-tools package, so let lsmod be found via PATH instead of
>>hardcoding the old modutils /sbin path.
>>
>
> Some distro doesn't set /sbin to PATH, so for me a better solution
> would be making PATH contain /sbin, and then use "lsmod".

read my changelog -- module-init-tools has always installed into /bin.
so what your distro does with /sbin doesnt matter.
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: introduce sys_membarrier(): process-wide memory barrier (v5)
http://groups.google.com/group/linux.kernel/t/cd9d826251979299?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Jan 19 2010 8:50 am
From: Peter Zijlstra

On Thu, 2010-01-14 at 11:26 -0500, Mathieu Desnoyers wrote:
> * Peter Zijlstra (peterz@infradead.org) wrote:
> > On Wed, 2010-01-13 at 14:36 -0500, Mathieu Desnoyers wrote:
> > > * Peter Zijlstra (peterz@infradead.org) wrote:
> > > > On Tue, 2010-01-12 at 20:37 -0500, Mathieu Desnoyers wrote:
> > > > > + for_each_cpu(cpu, tmpmask) {
> > > > > + spin_lock_irq(&cpu_rq(cpu)->lock);
> > > > > + mm = cpu_curr(cpu)->mm;
> > > > > + spin_unlock_irq(&cpu_rq(cpu)->lock);
> > > > > + if (current->mm != mm)
> > > > > + cpumask_clear_cpu(cpu, tmpmask);
> > > > > + }
> > > >
> > > > Why not:
> > > >
> > > > rcu_read_lock();
> > > > if (current->mm != cpu_curr(cpu)->mm)
> > > > cpumask_clear_cpu(cpu, tmpmask);
> > > > rcu_read_unlock();
> > > >
> > > > the RCU read lock ensures the task_struct obtained remains valid, and it
> > > > avoids taking the rq->lock.
> > > >
> > >
> > > If we go for a simple rcu_read_lock, I think that we need a smp_mb()
> > > after switch_to() updates the current task on the remote CPU, before it
> > > returns to user-space. Do we have this guarantee for all architectures ?
> > >
> > > So what I'm looking for, overall, is:
> > >
> > > schedule()
> > > ...
> > > switch_mm()
> > > smp_mb()
> > > clear mm_cpumask
> > > set mm_cpumask
> > > switch_to()
> > > update current task
> > > smp_mb()
> > >
> > > If we have that, then the rcu_read_lock should work.
> > >
> > > What the rq lock currently gives us is the guarantee that if the current
> > > thread changes on a remote CPU while we are not holding this lock, then
> > > a full scheduler execution is performed, which implies a memory barrier
> > > if we change the current thread (it does, right ?).
> >
> > I'm not quite seeing it, we have 4 possibilities, switches between
> > threads with:
> >
> > a) our mm, another mm
> >
> > - if we observe the former, we'll send an IPI (redundant)
> > - if we observe the latter, the switch_mm will have issued an mb
> >
> > b) another mm, our mm
> >
> > - if we observe the former, we're good because the cpu didn't run our
> > thread when we called sys_membarrier()
> > - if we observe the latter, we'll send an IPI (redundant)
>
> It's this scenario that is causing problem. Let's consider this
> execution:
>
> CPU 0 (membarrier) CPU 1 (another mm -> our mm)
> <kernel-space> <kernel-space>
> switch_mm()
> smp_mb()
> clear_mm_cpumask()
> set_mm_cpumask()
> smp_mb() (by load_cr3() on x86)
> switch_to()
> mm_cpumask includes CPU 1
> rcu_read_lock()
> if (CPU 1 mm != our mm)
> skip CPU 1.
> rcu_read_unlock()
> current = next (1)

OK, so on x86 current uses esp and will be flipped somewhere in the
switch_to() magic, cpu_curr(cpu) as used by CPU 0 uses rq->curr, which
will be set before context_switch() and that always implies a mb() for
non matching ->mm's [*]

> <switch back to user-space>
> read-lock()
> read gp, store local gp
> barrier()
> access critical section (2)
>
> So if we don't have any memory barrier between (1) and (2), the memory
> operations can be reordered in such a way that CPU 0 will not send IPI
> to a CPU that would need to have it's barrier() promoted into a
> smp_mb().

OK, so I'm utterly failing to make sense of the above, do you need more
than the 2 cpus discussed to make it go boom?

> Replacing these kernel rcu_read_lock/unlock() by rq locks ensures that
> when the scheduler runs concurrently on another CPU, _all_ the scheduling
> code is executed atomically wrt the spin lock taken on cpu 0.

Sure, but taking the rq->lock is fairly heavy handed.

> When x86 uses iret to return to user-space, then we have a serializing
> instruction. But if it uses sysexit, or if we are on a different
> architecture, are we sure that a memory barrier is issued before
> returning to user-space ?

[*] and possibly also for matching ->mm's, because:

OK, so I had a quick look at the switch_to() magic, and from what I can
make of it it implies an mb, if only because poking at the segment
registers implies LOCK semantics.

== 2 of 2 ==
Date: Tues, Jan 19 2010 9:20 am
From: Mathieu Desnoyers

* Peter Zijlstra (peterz@infradead.org) wrote:
[...]
> > It's this scenario that is causing problem. Let's consider this
> > execution:
> >
> > CPU 0 (membarrier) CPU 1 (another mm -> our mm)
> > <kernel-space> <kernel-space>
> > switch_mm()
> > smp_mb()
> > clear_mm_cpumask()
> > set_mm_cpumask()
> > smp_mb() (by load_cr3() on x86)
> > switch_to()
> > mm_cpumask includes CPU 1
> > rcu_read_lock()
> > if (CPU 1 mm != our mm)
> > skip CPU 1.
> > rcu_read_unlock()
> > current = next (1)
>
> OK, so on x86 current uses esp and will be flipped somewhere in the
> switch_to() magic, cpu_curr(cpu) as used by CPU 0 uses rq->curr, which
> will be set before context_switch() and that always implies a mb() for
> non matching ->mm's [*]

Hi Peter,

Please refer to the discussion with Steven further down this thread
(http://lkml.org/lkml/2010/1/14/319), which I update the scenario
when I figured out that "current" and rq->curr are indeed two different
things. It's rq->curr we are interested into here, not "current" as I
previously thought. (sorry about the mixup)

>
> > <switch back to user-space>
> > read-lock()
> > read gp, store local gp
> > barrier()
> > access critical section (2)
> >
> > So if we don't have any memory barrier between (1) and (2), the memory
> > operations can be reordered in such a way that CPU 0 will not send IPI
> > to a CPU that would need to have it's barrier() promoted into a
> > smp_mb().
>
> OK, so I'm utterly failing to make sense of the above, do you need more
> than the 2 cpus discussed to make it go boom?
>
> > Replacing these kernel rcu_read_lock/unlock() by rq locks ensures that
> > when the scheduler runs concurrently on another CPU, _all_ the scheduling
> > code is executed atomically wrt the spin lock taken on cpu 0.
>
> Sure, but taking the rq->lock is fairly heavy handed.
>
> > When x86 uses iret to return to user-space, then we have a serializing
> > instruction. But if it uses sysexit, or if we are on a different
> > architecture, are we sure that a memory barrier is issued before
> > returning to user-space ?
>
> [*] and possibly also for matching ->mm's, because:
>
> OK, so I had a quick look at the switch_to() magic, and from what I can
> make of it it implies an mb, if only because poking at the segment
> registers implies LOCK semantics.

Can you have a look at the updated scenario and reply with questions
that might arise ?

Thanks!

Mathieu

>
>

--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: x86: check range in update range
http://groups.google.com/group/linux.kernel/t/00dfba37428cbc3a?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Jan 19 2010 9:00 am
From: Christoph Lameter

On Fri, 15 Jan 2010, Yinghai Lu wrote:

> fend off wrong range

Why is it ok now to call these functions with start >= end? Bootmem
compatibilty?

== 2 of 2 ==
Date: Tues, Jan 19 2010 9:20 am
From: Christoph Lameter

Introduces a lot of churn into the early map allocation but looks like its
worth it.

Acked-by: Christoph Lameter <cl@linux-foundation.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: x86: move range related operation to one file
http://groups.google.com/group/linux.kernel/t/c09ad816aef8e274?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 19 2010 9:00 am
From: Christoph Lameter

On Fri, 15 Jan 2010, Yinghai Lu wrote:

> Signed-off-by: Yinghai Lu <yinghai@kernel.org>

> -
> -static int __init cmp_range(const void *x1, const void *x2)
> -{
> - const struct res_range *r1 = x1;
> - const struct res_range *r2 = x2;
> - long start1, start2;
> -
> - start1 = r1->start;
> - start2 = r2->start;
> -
> - return start1 - start2;
> -}

Function is passed to sort() should not be used directly. Maybe add
comments.

> - static struct res_range range_new[RANGE_NUM];
> + static struct range range_new[RANGE_NUM];

Renaming res_range -> range. Good but explain.

> - nr_range = add_range_with_merge(range, nr_range, 0,
> + nr_range = add_range_with_merge(range, RANGE_NUM, nr_range, 0,
> (1ULL<<(20 - PAGE_SHIFT)) - 1);

add_range_with_merge semantics changed. Explain.

> update_res(info, start, end, IORESOURCE_IO, 1);
> - update_range(range, start, end);
> + subtract_range(range, RANGE_NUM, start, end);

Two functions merged?

> +void subtract_range(struct range *range, int az, u64 start, u64 end)

Subtract range can now do what update_range did? How so?

Looks quite good. Just add some ornaments describing things to make it
clearer.

==============================================================================
TOPIC: Add "handle page fault" PV helper.
http://groups.google.com/group/linux.kernel/t/3f9936b06aed63f6?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 19 2010 9:10 am
From: "H. Peter Anvin"

On 01/18/2010 10:55 PM, Gleb Natapov wrote:
>>
>> What I mean is that vector 14 is page faults -- that's what it is all
>> about. Why on Earth do you need another vector?
>>
> Because this is not usual pagefault that tell the OS that page is not
> mapped. This is a notification to a guest OS that the page it is trying
> to access is swapped out by the host OS. There is nothing guest can do
> about it except schedule another task. So the guest should handle both
> type of exceptions: usual #PF when page is not mapped by the guest and
> new type of notifications. Ideally we would use one of unused exception
> vectors for new type of notifications.
>

Ah, this kind of stuff. We have talked about this in the past, and the
right way to do that is to have the guest OS pick a vector our of the
standard 0x20-0xff range, and then notify the hypervisor via a hypercall
which vector to use.

In Linux this means marking it as a system vector. Note that there are
real hardware system vectors which will be mutually exclusive with this,
e.g. the UV one.

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.

==============================================================================
TOPIC: what's up with "make -j N" output?
http://groups.google.com/group/linux.kernel/t/c8655e0ed48dafd9?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 19 2010 9:10 am
From: Ralf Baechle

On Mon, Jan 18, 2010 at 10:24:14PM +0200, Alexey Dobriyan wrote:

> Script does effectively:
>
> make -k -j5 &>1.log

My automated builds effectively run a number of "make -j 1" builds in
parallel so I get sane parsable and readable logs. I don't think we
give any guarantees for -j 2 or higher even though that would be highly
desirable when things go wrong.

Ralf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: perf kmem: Print usage help for unknown commands
http://groups.google.com/group/linux.kernel/t/c78b183051f75dbc?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 19 2010 9:30 am
From: Pekka Enberg

This patch fixes "perf kmem" to print usage help instead of doing nothing.

Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Li Zefan <lizf@cn.fujitsu.com>
Cc: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com>
Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>
---
tools/perf/builtin-kmem.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/tools/perf/builtin-kmem.c b/tools/perf/builtin-kmem.c
index 33bb9df..93c67bf 100644
--- a/tools/perf/builtin-kmem.c
+++ b/tools/perf/builtin-kmem.c
@@ -784,7 +784,8 @@ int cmd_kmem(int argc, const char **argv, const char *prefix __used)
setup_sorting(&alloc_sort, default_sort_order);

return __cmd_kmem();
- }
+ } else
+ usage_with_options(kmem_usage, kmem_options);

return 0;
}
--
1.6.0.4

==============================================================================
TOPIC: perf kmem: Increase "Hit" column length
http://groups.google.com/group/linux.kernel/t/4d6a1837aedeb490?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 19 2010 9:30 am
From: Pekka Enberg

It's fairly easy to overflow the "Hit" column with just few seconds of tracing
so increase the column length to avoid broken formatting.

Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Li Zefan <lizf@cn.fujitsu.com>
Cc: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com>
Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>
---
tools/perf/builtin-kmem.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/builtin-kmem.c b/tools/perf/builtin-kmem.c
index 7ceb741..33bb9df 100644
--- a/tools/perf/builtin-kmem.c
+++ b/tools/perf/builtin-kmem.c
@@ -375,7 +375,7 @@ static void __print_result(struct rb_root *root, struct perf_session *session,

printf("%.102s\n", graph_dotted_line);
printf(" %-34s |", is_caller ? "Callsite": "Alloc Ptr");
- printf(" Total_alloc/Per | Total_req/Per | Hit | Ping-pong | Frag\n");
+ printf(" Total_alloc/Per | Total_req/Per | Hit | Ping-pong | Frag\n");
printf("%.102s\n", graph_dotted_line);

next = rb_first(root);
@@ -401,7 +401,7 @@ static void __print_result(struct rb_root *root, struct perf_session *session,
snprintf(buf, sizeof(buf), "%#Lx", addr);
printf(" %-34s |", buf);

- printf(" %9llu/%-5lu | %9llu/%-5lu | %6lu | %8lu | %6.3f%%\n",
+ printf(" %9llu/%-5lu | %9llu/%-5lu | %8lu | %8lu | %6.3f%%\n",
(unsigned long long)data->bytes_alloc,
(unsigned long)data->bytes_alloc / data->hit,
(unsigned long long)data->bytes_req,
--
1.6.0.4

==============================================================================

You received this message because you are subscribed to the Google Groups "linux.kernel"
group.

To post to this group, visit http://groups.google.com/group/linux.kernel?hl=en

To unsubscribe from this group, send email to linux.kernel+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/linux.kernel/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

twitter

Tuesday, January 19, 2010

linux.kernel - 26 new messages in 18 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts