* [Bug #13328] b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear.
From: Rafael J. Wysocki @ 2009-08-19 20:40 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Francis Moreau, netdev
In-Reply-To: <xDf-7eSwYsC.A.-6B.klIjKB@chimera>
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.
The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13328
Subject : b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear.
Submitter : Francis Moreau <francis.moro-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-05-03 16:22 (109 days old)
References : http://marc.info/?l=linux-kernel&m=124136778012280&w=4
^ permalink raw reply
* Re: [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model for vbus_driver objects
From: Avi Kivity @ 2009-08-19 20:37 UTC (permalink / raw)
To: Gregory Haskins
Cc: Ingo Molnar, kvm, alacrityvm-devel, linux-kernel, netdev,
Michael S. Tsirkin, Patrick Mullaney
In-Reply-To: <4A8C43D3.7030002@gmail.com>
On 08/19/2009 09:26 PM, Gregory Haskins wrote:
>>> This is for things like the setup of queue-pairs, and the transport of
>>> door-bells, and ib-verbs. I am not on the team doing that work, so I am
>>> not an expert in this area. What I do know is having a flexible and
>>> low-latency signal-path was deemed a key requirement.
>>>
>>>
>> That's not a full bypass, then. AFAIK kernel bypass has userspace
>> talking directly to the device.
>>
> Like I said, I am not an expert on the details here. I only work on the
> vbus plumbing. FWIW, the work is derivative from the "Xen-IB" project
>
> http://www.openib.org/archives/nov2006sc/xen-ib-presentation.pdf
>
> There were issues with getting Xen-IB to map well into the Xen model.
> Vbus was specifically designed to address some of those short-comings.
>
Well I'm not an Infiniband expert. But from what I understand VMM
bypass means avoiding the call to the VMM entirely by exposing hardware
registers directly to the guest.
>> This is best done using cr8/tpr so you don't have to exit at all. See
>> also my vtpr support for Windows which does this in software, generally
>> avoiding the exit even when lowering priority.
>>
> You can think of vTPR as a good model, yes. Generally, you can't
> actually use it for our purposes for several reasons, however:
>
> 1) the prio granularity is too coarse (16 levels, -rt has 100)
>
> 2) it is too scope limited (it covers only interrupts, we need to have
> additional considerations, like nested guest/host scheduling algorithms
> against the vcpu, and prio-remap policies)
>
> 3) I use "priority" generally..there may be other non-priority based
> policies that need to add state to the table (such as EDF deadlines, etc).
>
> but, otherwise, the idea is the same. Besides, this was one example.
>
Well, if priority is so important then I'd recommend exposing it via a
virtual interrupt controller. A bus is the wrong model to use, because
its scope is only the devices it contains, and because it is system-wide
in nature, not per-cpu.
>>> This is where the really fast call() type mechanism is important.
>>>
>>> Its also about having the priority flow-end to end, and having the vcpu
>>> interrupt state affect the task-priority, etc (e.g. pending interrupts
>>> affect the vcpu task prio).
>>>
>>> etc, etc.
>>>
>>> I can go on and on (as you know ;), but will wait till this work is more
>>> concrete and proven.
>>>
>>>
>> Generally cpu state shouldn't flow through a device but rather through
>> MSRs, hypercalls, and cpu registers.
>>
>
> Well, you can blame yourself for that one ;)
>
> The original vbus was implemented as cpuid+hypercalls, partly for that
> reason. You kicked me out of kvm.ko, so I had to make due with plan B
> via a less direct PCI-BRIDGE route.
>
A bus has no business doing these things. But cpu state definitely
needs to be manipulated using hypercalls, see the pvmmu and vtpr
hypercalls or the pvclock msr.
> But in reality, it doesn't matter much. You can certainly have "system"
> devices sitting on vbus that fit a similar role as "MSRs", so the access
> method is more of an implementation detail. The key is it needs to be
> fast, and optimize out extraneous exits when possible.
>
No, percpu state belongs in the vcpu model, not the device model. cpu
priority is logically a cpu register or state, not device state.
>> Well, do you plan to address this before submission for inclusion?
>>
> Maybe, maybe not. Its workable for now (i.e. run as root), so its
> inclusion is not predicated on the availability of the fix, per se (at
> least IMHO). If I can get it working before I get to pushing the core,
> great! Patches welcome.
>
The lack of so many feature indicates the whole thing is immature. That
would be find if the whole thing was the first of its kind, but it isn't.
> For the time being, windows will not be RT, and windows can fall-back to
> use virtio-net, etc. So I am ok with this. It will come in due time.
>
>
So we need to work on optimizing both virtio-net and venet. Great.
>>> The point is: the things we build on top have costs associated with
>>> them, and I aim to minimize it. For instance, to do a "call()" kind of
>>> interface, you generally need to pre-setup some per-cpu mappings so that
>>> you can just do a single iowrite32() to kick the call off. Those
>>> per-cpu mappings have a cost if you want them to be high-performance, so
>>> my argument is that you ideally want to limit the number of times you
>>> have to do this. My current design reduces this to "once".
>>>
>>>
>> Do you mean minimizing the setup cost? Seriously?
>>
> Not the time-to-complete-setup overhead. The residual costs, like
> heap/vmap usage at run-time. You generally have to set up per-cpu
> mappings to gain maximum performance. You would need it per-device, I
> do it per-system. Its not a big deal in the grand-scheme of things,
> really. But chalk that up as an advantage to my approach over yours,
> nonetheless.
>
Without measurements, it's just handwaving.
>> I guess it isn't that important then. I note that clever prioritization
>> in a guest is pointless if you can't do the same prioritization in the
>> host.
>>
> I answer this below...
>
> The point is that I am eliminating as many exits as possible, so 1us,
> 2us, whatever...it doesn't matter. The fastest exit is the one you
> don't have to take.
>
You'll still have to exit if the host takes a low priority interrupt,
schedule the irq thread according to its priority, and return to the
guest. At this point you may as well inject the interrupt and let the
guest do the same thing.
>> IIRC we reuse the PCI IDs for non-PCI.
>>
>
> You already know how I feel about this gem.
>
The earth keeps rotating despite the widespread use of PCI IDs.
>> I'm not okay with it. If you wish people to adopt vbus over virtio
>> you'll have to address all concerns, not just yours.
>>
> By building a community around the development of vbus, isnt this what I
> am doing? Working towards making it usable for all?
>
I've no idea if you're actually doing that. Maybe inclusion should be
predicated on achieving feature parity.
>>>> and multiqueue out of your design.
>>>>
>>>>
>>> AFAICT, multiqueue should work quite nicely with vbus. Can you
>>> elaborate on where you see the problem?
>>>
>>>
>> You said you aren't interested in it previously IIRC.
>>
>>
> I don't think so, no. Perhaps I misspoke or was misunderstood. I
> actually think its a good idea and will be looking to do this.
>
When I pointed out that multiplexing all interrupts onto a single vector
is bad for per-vcpu multiqueue, you said you're not interested in that.
>> I agree that it isn't very clever (not that I am a real time expert) but
>> I disagree about dismissing Linux support so easily. If prioritization
>> is such a win it should be a win on the host as well and we should make
>> it work on the host as well. Further I don't see how priorities on the
>> guest can work if they don't on the host.
>>
> Its more about task priority in the case of real-time. We do stuff with
> 802.1p as well for control messages, etc. But for the most part, this
> is an orthogonal effort. And yes, you are right, it would be nice to
> have this interrupt classification capability in the host.
>
> Generally this is mitigated by the use of irq-threads. You could argue
> that if irq-threads help the host without a prioritized interrupt
> controller, why cant the guest? The answer is simply that the host can
> afford sub-optimal behavior w.r.t. IDT injection here, where the guest
> cannot (due to the disparity of hw-injection vs guest-injection overheads).
>
Guest injection overhead is not too bad, most of the cost is the exit
itself, and you can't avoid that without host task priorities.
>> They had to write 414 lines in drivers/s390/kvm/kvm_virtio.c and
>> something similar for lguest.
>>
> Well, then I retract that statement. I think the small amount of code
> is probably because they are re-using the qemu device-models, however.
>
No that's guest code, it isn't related to qemu.
> Note that I am essentially advocating the same basic idea here.
>
Right, duplicating existing infrastructure.
>> I don't see what vbus adds to virtio-net.
>>
> Well, as you stated in your last reply, you don't want it. So I guess
> that doesn't matter much at this point. I will continue developing
> vbus, and pushing things your way. You can opt to accept or reject
> those things at your own discretion.
>
I'm not the one to merge it. However my opinion is that it shouldn't be
merged.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
^ permalink raw reply
* 2.6.31-rc6-git5: Reported regressions 2.6.29 -> 2.6.30
From: Rafael J. Wysocki @ 2009-08-19 20:36 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Andrew Morton, Linus Torvalds, Natalie Protasevich,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
This message contains a list of some regressions introduced between 2.6.29 and
2.6.30, for which there are no fixes in the mainline I know of. If any of them
have been fixed already, please let me know.
If you know of any other unresolved regressions introduced between 2.6.29
and 2.6.30, please let me know either and I'll add them to the list.
Also, please let me know if any of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2009-08-20 150 35 32
2009-08-10 148 39 37
2009-08-02 145 44 39
2009-07-27 143 48 45
2009-07-07 138 50 46
2009-06-29 133 46 43
2009-06-07 110 35 31
2009-05-31 100 32 27
2009-05-24 92 34 27
2009-05-16 81 36 33
2009-04-25 55 36 26
2009-04-17 37 35 28
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13958
Subject : ath5k Atheros AR5001 low signal
Submitter : Marco Siviero <darker1985@slacky.it>
Date : 2009-08-10 15:03 (10 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13949
Subject : XFS regression
Submitter : Justin Piszcz <jpiszcz@lucidpixels.com>
Date : 2009-08-08 8:39 (12 days old)
References : http://marc.info/?l=linux-kernel&m=124972079229959&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13933
Subject : System lockup on dual Pentium-3 with kernel 2.6.30
Submitter : Martin Rogge <marogge@onlinehome.de>
Date : 2009-08-08 13:16 (12 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13898
Subject : Intel 3945ABG - problems on 2.6.30.X
Submitter : dienet <dienet@poczta.fm>
Date : 2009-07-31 15:17 (20 days old)
References : http://marc.info/?l=linux-kernel&m=124905346729959&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13797
Subject : iBook G4 doesn't suspend since 2ed8d2b3a8
Submitter : Jörg Sommer <joerg@alea.gnuu.de>
Date : 2009-07-18 20:18 (33 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13795
Subject : abnormal boot and no suspend due to 'async' (fastboot)
Submitter : Rafal Kaczynski <fscnoboot@wp.pl>
Date : 2009-07-18 17:19 (33 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13780
Subject : NULL pointer dereference loading powernowk8
Submitter : Kurt Roeckx <kurt@roeckx.be>
Date : 2009-07-15 18:00 (36 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13770
Subject : System freeze on XFS filesystem recovery on an external disk
Submitter : Jean-Luc Coulon <jean.luc.coulon@gmail.com>
Date : 2009-07-14 10:31 (37 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13739
Subject : 2.6.30 leaking keys on console switch
Submitter : Andi Kleen <andi@firstfloor.org>
Date : 2009-07-07 8:44 (44 days old)
References : http://marc.info/?l=linux-kernel&m=124695628924382&w=4
Handled-By : Jiri Kosina <jkosina@suse.cz>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13694
Subject : i915 phantom TV
Submitter : Maciek Józiewicz <mjoziew@gmail.com>
Date : 2009-07-02 12:26 (49 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13682
Subject : The webcam stopped working when upgrading from 2.6.29 to 2.6.30
Submitter : Nathanael Schaeffer <nathanael.schaeffer@gmail.com>
Date : 2009-06-30 13:34 (51 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13646
Subject : warn_on tty_io.c, broken bluetooth
Submitter : Pavel Machek <pavel@ucw.cz>
Date : 2009-06-19 17:05 (62 days old)
References : http://lkml.org/lkml/2009/6/19/187
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13634
Subject : [drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22
Submitter : Cijoml Cijomlovic Cijomlov <cijoml@volny.cz>
Date : 2009-06-27 07:02 (54 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13583
Subject : pdflush uses 5% CPU on otherwise idle system
Submitter : Paul Martin <pm@debian.org>
Date : 2009-06-19 13:33 (62 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13581
Subject : ath9k doesn't work with newer kernels
Submitter : Matteo <rootkit85@yahoo.it>
Date : 2009-06-19 12:04 (62 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13564
Subject : random general protection fault at boot time caused by khubd.
Submitter : Pauli <suokkos@gmail.com>
Date : 2009-06-18 12:44 (63 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13558
Subject : Tracelog during resume
Submitter : Cijoml Cijomlovic Cijomlov <cijoml@volny.cz>
Date : 2009-06-17 11:32 (64 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13514
Subject : acer_wmi causes stack corruption
Submitter : Rus <harbour@sfinx.od.ua>
Date : 2009-06-12 08:13 (69 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13512
Subject : D43 on 2.6.30 doesn't suspend anymore
Submitter : Daniel Smolik <marvin@mydatex.cz>
Date : 2009-06-11 20:12 (70 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13502
Subject : GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1
Submitter : <sveina@gmail.com>
Date : 2009-06-10 20:04 (71 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13408
Subject : Performance regression in 2.6.30-rc7
Submitter : Diego Calleja <diegocg@gmail.com>
Date : 2009-05-30 18:51 (82 days old)
References : http://lkml.org/lkml/2009/5/30/146
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13407
Subject : adb trackpad disappears after suspend to ram
Submitter : Jan Scholz <scholz@fias.uni-frankfurt.de>
Date : 2009-05-28 7:59 (84 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2ed8d2b3a81bdbb0418301628ccdb008ac9f40b7
References : http://marc.info/?l=linux-kernel&m=124349762314976&w=4
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13401
Subject : pktcdvd writing is really slow with CFQ scheduler (bisected)
Submitter : Laurent Riffard <laurent.riffard@free.fr>
Date : 2009-05-28 18:43 (84 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13373
Subject : fbcon, intelfb, i915: INFO: possible circular locking dependency detected
Submitter : Miles Lane <miles.lane@gmail.com>
Date : 2009-05-23 5:08 (89 days old)
References : http://marc.info/?l=linux-kernel&m=124305538130702&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13362
Subject : rt2x00: slow wifi with correct basic rate bitmap
Submitter : Alejandro Riveira <ariveira@gmail.com>
Date : 2009-05-22 13:32 (90 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13351
Subject : 2.6.30 - 2.6.31 corrupts my system after suspend resume with readonly mounted hard disk
Submitter : <unggnu@googlemail.com>
Date : 2009-05-20 14:09 (92 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=78a8b35bc7abf8b8333d6f625e08c0f7cc1c3742
Handled-By : Yinghai Lu <yinghai@kernel.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13341
Subject : Random Oops at boot at loading ip6tables rules
Submitter : <patrick@ostenberg.de>
Date : 2009-05-19 09:08 (93 days old)
Handled-By : Rusty Russell <rusty@rustcorp.com.au>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13328
Subject : b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear.
Submitter : Francis Moreau <francis.moro@gmail.com>
Date : 2009-05-03 16:22 (109 days old)
References : http://marc.info/?l=linux-kernel&m=124136778012280&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13318
Subject : AGP doesn't work anymore on nforce2
Submitter : Karsten Mehrhoff <kawime@gmx.de>
Date : 2009-04-30 8:51 (112 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=59de2bebabc5027f93df999d59cc65df591c3e6e
References : http://marc.info/?l=linux-kernel&m=124108156417560&w=4
Handled-By : Shaohua Li <shaohua.li@intel.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13306
Subject : hibernate slow on _second_ run
Submitter : Johannes Berg <johannes@sipsolutions.net>
Date : 2009-05-14 09:34 (98 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13219
Subject : Intel 440GX: Since kernel 2.6.30-rc1, computers hangs randomly but not with kernel <= 2.6.29.6
Submitter : David Hill <hilld@binarystorm.net>
Date : 2009-05-01 16:57 (111 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13180
Subject : 2.6.30-rc2: WARNING at i915_gem.c for i915_gem_idle
Submitter : Niel Lambrechts <niel.lambrechts@gmail.com>
Date : 2009-04-21 21:35 (121 days old)
References : http://marc.info/?l=linux-kernel&m=124034980819102&w=4
http://lkml.org/lkml/2009/4/27/290
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13620
Subject : acpi_enforce_resources broken - conflicting i2c module loaded on some EeePCs
Submitter : Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Date : 2009-06-25 08:31 (56 days old)
References : <http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/2009-June/002316.html>
Handled-By : Lin Ming <ming.m.lin@intel.com>
Patch : http://patchwork.kernel.org/patch/33626/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13389
Subject : Warning 'Invalid throttling state, reset' gets displayed when it should not be
Submitter : Frans Pop <elendil@planet.nl>
Date : 2009-05-26 15:24 (86 days old)
Handled-By : Frans Pop <elendil@planet.nl>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=21671
http://bugzilla.kernel.org/attachment.cgi?id=21672
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319
Subject : Page allocation failures with b43 and p54usb
Submitter : Larry Finger <Larry.Finger@lwfinger.net>
Date : 2009-04-29 21:01 (113 days old)
References : http://marc.info/?l=linux-kernel&m=124103897101088&w=4
http://lkml.org/lkml/2009/6/7/136
http://lkml.org/lkml/2009/7/26/213
Handled-By : Johannes Berg <johannes@sipsolutions.net>
David Rientjes <rientjes@google.com>
Patch : http://patchwork.kernel.org/patch/37655/
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions introduced
between 2.6.29 and 2.6.30, unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=13070
Please let me know if there are any Bugzilla entries that should be added to
the list in there.
Thanks,
Rafael
^ permalink raw reply
* 2.6.31-rc6-git5: Reported regressions from 2.6.30
From: Rafael J. Wysocki @ 2009-08-19 20:20 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Adrian Bunk, Andrew Morton, Linus Torvalds, Natalie Protasevich,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
This message contains a list of some regressions from 2.6.30, for which there
are no fixes in the mainline I know of. If any of them have been fixed already,
please let me know.
If you know of any other unresolved regressions from 2.6.30, please let me know
either and I'll add them to the list. Also, please let me know if any of the
entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2009-08-20 102 32 29
2009-08-10 89 27 24
2009-08-02 76 36 28
2009-07-27 70 51 43
2009-07-07 35 25 21
2009-06-29 22 22 15
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14018
Subject : kernel freezes, inotify problem
Submitter : Christoph Thielecke <christoph.thielecke-Mmb7MZpHnFY@public.gmane.org>
Date : 2009-08-19 12:48 (1 days old)
References : http://marc.info/?l=linux-kernel&m=125068616818353&w=4
Handled-By : Eric Paris <eparis-FjpueFixGhCM4zKIHC2jIg@public.gmane.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14016
Subject : mm/ipw2200 regression
Submitter : Bartlomiej Zolnierkiewicz <bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-08-15 16:56 (5 days old)
References : http://marc.info/?l=linux-kernel&m=125036437221408&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14015
Subject : pty regressed again, breaking expect and gcc's testsuite
Submitter : Mikael Pettersson <mikpe-1zs4UD6AkMk@public.gmane.org>
Date : 2009-08-14 23:41 (6 days old)
References : http://marc.info/?l=linux-kernel&m=125029329805643&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14014
Subject : kernel bug at shut down
Submitter : Norbert Preining <preining-DX+603jRYB8@public.gmane.org>
Date : 2009-08-14 9:11 (6 days old)
References : http://marc.info/?l=linux-kernel&m=125024112418870&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14013
Subject : hd don't show up
Submitter : Tim Blechmann <tim-xpEK/MU0Hawdnm+yROfE0A@public.gmane.org>
Date : 2009-08-14 8:26 (6 days old)
References : http://marc.info/?l=linux-kernel&m=125023842514480&w=4
Handled-By : Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14012
Subject : latest git fried my x86_64 imac
Submitter : Justin P. Mattock <justinmattock-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-08-13 07:20 (7 days old)
References : http://marc.info/?l=linux-kernel&m=125014080427090&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14011
Subject : Kernel paging request failed in kmem_cache_alloc
Submitter : Matthias Dahl <ml_kernel-Rk1lLwyeSiSCvTm3UDtA3g@public.gmane.org>
Date : 2009-08-10 22:26 (10 days old)
References : http://marc.info/?l=linux-kernel&m=124993603825082&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14003
Subject : Infinite loop on bootup while handling DMAR
Submitter : Bernhard Rosenkraenzer <bero-9zdaV+82baBg9hUCZPvPmw@public.gmane.org>
Date : 2009-08-18 14:54 (2 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14002
Subject : WARNING: at net/ipv4/af_inet.c:154 inet_sock_destruct+0x164/0x1c0()
Submitter : Ralf Hildebrandt <ralf.hildebrandt-jq1tPX9l7E6ELgA04lAiVw@public.gmane.org>
Date : 2009-08-18 12:37 (2 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13987
Subject : Received NMI interrupt at resume
Submitter : Christian Casteyde <casteyde.christian-GANU6spQydw@public.gmane.org>
Date : 2009-08-15 07:55 (5 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13960
Subject : rtl8187 not connect to wifi
Submitter : okias <d.okias-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-08-10 19:16 (10 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13950
Subject : Oops when USB Serial disconnected while in use
Submitter : Bruno Prémont <bonbons-ud5FBsm0p/xEiooADzr8i9i2O/JbrIOy@public.gmane.org>
Date : 2009-08-08 17:47 (12 days old)
References : http://marc.info/?l=linux-kernel&m=124975432900466&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13947
Subject : Libertas: Association request to the driver failed
Submitter : Daniel Mack <daniel-rDUAYElUppE@public.gmane.org>
Date : 2009-08-07 19:11 (13 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=57921c312e8cef72ba35a4cfe870b376da0b1b87
References : http://marc.info/?l=linux-kernel&m=124967234311481&w=4
Handled-By : Roel Kluin <roel.kluin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13943
Subject : WARNING: at net/mac80211/mlme.c:2292 with ath5k
Submitter : Fabio Comolli <fabio.comolli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-08-06 20:15 (14 days old)
References : http://marc.info/?l=linux-kernel&m=124958978600600&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13942
Subject : Troubles with AoE and uninitialized object
Submitter : Bruno Prémont <bonbons-ud5FBsm0p/xEiooADzr8i9i2O/JbrIOy@public.gmane.org>
Date : 2009-08-04 10:12 (16 days old)
References : http://marc.info/?l=linux-kernel&m=124938117104811&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13941
Subject : x86 Geode issue
Submitter : Martin-Éric Racine <q-funk-X3B1VOXEql0@public.gmane.org>
Date : 2009-08-03 12:58 (17 days old)
References : http://marc.info/?l=linux-kernel&m=124930434732481&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13940
Subject : iwlagn and sky2 stopped working, ACPI-related
Submitter : Ricardo Jorge da Fonseca Marques Ferreira <storm@sys49152.net>
Date : 2009-08-07 22:33 (13 days old)
References : http://marc.info/?l=linux-kernel&m=124968457731107&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13935
Subject : 2.6.31-rcX breaks Apple MightyMouse (Bluetooth version)
Submitter : Adrian Ulrich <kernel-4ZM2p5qjiQGewZBzVTKGGg@public.gmane.org>
Date : 2009-08-08 22:08 (12 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fa047e4f6fa63a6e9d0ae4d7749538830d14a343
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13914
Subject : e1000e reports invalid NVM Checksum on 82566DM-2 (bisected)
Submitter : <jsbronder-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>
Date : 2009-08-04 18:06 (16 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13906
Subject : Huawei E169 GPRS connection causes Ooops
Submitter : Clemens Eisserer <linuxhippy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-08-04 09:02 (16 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13899
Subject : Oops from tar, 2.6.31-rc5, 32 bit on quad core phenom.
Submitter : Gene Heskett <gene.heskett-H+0wwilmMs3R7s880joybQ@public.gmane.org>
Date : 2009-08-01 13:04 (19 days old)
References : http://marc.info/?l=linux-kernel&m=124913190304149&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13869
Subject : Radeon framebuffer (w/o KMS) corruption at boot.
Submitter : Duncan <1i5t5.duncan-j9pdmedNgrk@public.gmane.org>
Date : 2009-07-29 16:44 (22 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13848
Subject : iwlwifi (4965) regression since 2.6.30
Submitter : Lukas Hejtmanek <xhejtman-8qz54MUs51PtwjQa/ONI9g@public.gmane.org>
Date : 2009-07-26 7:57 (25 days old)
References : http://marc.info/?l=linux-kernel&m=124859658502866&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13836
Subject : suspend script fails, related to stdout?
Submitter : Tomas M. <tmezzadra-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-07-17 21:24 (34 days old)
References : http://marc.info/?l=linux-kernel&m=124785853811667&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13819
Subject : system freeze when switching to console
Submitter : Reinette Chatre <reinette.chatre-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date : 2009-07-23 17:57 (28 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13809
Subject : oprofile: possible circular locking dependency detected
Submitter : Jerome Marchand <jmarchan-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Date : 2009-07-22 13:35 (29 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13740
Subject : X server crashes with 2.6.31-rc2 when options are changed
Submitter : Michael S. Tsirkin <m.s.tsirkin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-07-07 15:19 (44 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13733
Subject : 2.6.31-rc2: irq 16: nobody cared
Submitter : Niel Lambrechts <niel.lambrechts-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-07-06 18:32 (45 days old)
References : http://marc.info/?l=linux-kernel&m=124690524027166&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13645
Subject : NULL pointer dereference at (null) (level2_spare_pgt)
Submitter : poornima nayak <mpnayak-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Date : 2009-06-17 17:56 (64 days old)
References : http://lkml.org/lkml/2009/6/17/194
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14017
Subject : _end symbol missing from Symbol.map
Submitter : Hannes Reinecke <hare-l3A5Bk7waGM@public.gmane.org>
Date : 2009-08-13 6:45 (7 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=091e52c3551d3031343df24b573b770b4c6c72b6
References : http://marc.info/?l=linux-kernel&m=125014649102253&w=4
Handled-By : Hannes Reinecke <hare-l3A5Bk7waGM@public.gmane.org>
Patch : http://marc.info/?l=linux-kernel&m=125014649102253&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13948
Subject : ath5k broken after suspend-to-ram
Submitter : Johannes Stezenbach <js-FF7aIK3TAVNeoWH0uzbU5w@public.gmane.org>
Date : 2009-08-07 21:51 (13 days old)
References : http://marc.info/?l=linux-kernel&m=124968192727854&w=4
Handled-By : Nick Kossifidis <mickflemm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Patch : http://patchwork.kernel.org/patch/38550/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13946
Subject : x86 MCE malfunction on Thinkpad T42p
Submitter : Johannes Stezenbach <js-FF7aIK3TAVNeoWH0uzbU5w@public.gmane.org>
Date : 2009-08-07 17:09 (13 days old)
References : http://marc.info/?l=linux-kernel&m=124966500232399&w=4
Handled-By : Bartlomiej Zolnierkiewicz <bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Patch : http://patchwork.kernel.org/patch/37908/
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions from 2.6.30,
unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=13615
Please let me know if there are any Bugzilla entries that should be added to
the list in there.
Thanks,
Rafael
^ permalink raw reply
* configfs/sysfs
From: Avi Kivity @ 2009-08-19 20:12 UTC (permalink / raw)
To: Nicholas A. Bellinger
Cc: Ingo Molnar, Anthony Liguori, kvm, alacrityvm-devel, linux-kernel,
netdev, Michael S. Tsirkin, Ira W. Snyder, Joel Becker
In-Reply-To: <1250706227.27590.156.camel@haakon2.linux-iscsi.org>
On 08/19/2009 09:23 PM, Nicholas A. Bellinger wrote:
> Anyways, I was wondering if you might be interesting in sharing your
> concerns wrt to configfs (conigfs maintainer CC'ed), at some point..?
>
My concerns aren't specifically with configfs, but with all the text
based pseudo filesystems that the kernel exposes.
My high level concern is that we're optimizing for the active sysadmin,
not for libraries and management programs. configfs and sysfs are easy
to use from the shell, discoverable, and easily scripted. But they
discourage documentation, the text format is ambiguous, and they require
a lot of boilerplate to use in code.
You could argue that you can wrap *fs in a library that hides the
details of accessing it, but that's the wrong approach IMO. We should
make the information easy to use and manipulate for programs; one of
these programs can be a fuse filesystem for the active sysadmin if
someone thinks it's important.
Now for the low level concerns:
- efficiency
Each attribute access requires an open/read/close triplet and
binary->ascii->binary conversions. In contrast an ordinary
syscall/ioctl interface can fetch all attributes of an object, or even
all attributes of all objects, in one call.
- atomicity
One attribute per file means that, lacking userspace-visible
transactions, there is no way to change several attributes at once.
When you read attributes, there is no way to read several attributes
atomically so you can be sure their values correlate. Another example
of a problem is when an object disappears while reading its attributes.
Sure, openat() can mitigate this, but it's better to avoid introducing
problem than having a fix.
- ambiguity
What format is the attribute? does it accept lowercase or uppercase hex
digits? is there a newline at the end? how many digits can it take
before the attribute overflows? All of this has to be documented and
checked by the OS, otherwise we risk regressions later. In contrast,
__u64 says everything in a binary interface.
- lifetime and access control
If a process brings an object into being (using mkdir) and then dies,
the object remains behind. The syscall/ioctl approach ties the object
into an fd, which will be destroyed when the process dies, and which can
be passed around using SCM_RIGHTS, allowing a server process to create
and configure an object before passing it to an unprivileged program
- notifications
It's hard to notify users about changes in attributes. Sure, you can
use inotify, but that limits you to watching subtrees. Once you do get
the notification, you run into the atomicity problem. When do you know
all attributes are valid? This can be solved using sequence counters,
but that's just gratuitous complexity. Netlink type interfaces are much
more robust and flexible.
- readdir
You can either list everything, or nothing. Sure, you can have trees to
ease searching, even multiple views of the same data, but it's painful.
You may argue, correctly, that syscalls and ioctls are not as flexible.
But this is because no one has invested the effort in making them so. A
struct passed as an argument to a syscall is not extensible. But if you
pass the size of the structure, and also a bitmap of which attributes
are present, you gain extensibility and retain the atomicity property of
a syscall interface. I don't think a lot of effort is needed to make an
extensible syscall interface just as usable and a lot more efficient
than configfs/sysfs. It should also be simple to bolt a fuse interface
on top to expose it to us commandline types.
> As you may recall, I have been using configfs extensively for the 3.x
> generic target core infrastructure and iSCSI fabric modules living in
> lio-core-2.6.git/drivers/target/target_core_configfs.c and
> lio-core-2.6.git/drivers/lio-core/iscsi_target_config.c, and have found
> it to be extraordinarly useful for the purposes of a implementing a
> complex kernel level target mode stack that is expected to manage
> massive amounts of metadata, allow for real-time configuration, share
> data structures (eg: SCSI Target Ports) between other kernel fabric
> modules and manage the entire set of fabrics using only intrepetered
> userspace code.
>
> Using the 10000 1:1 mapped TCM Virtual HBA+FILEIO LUNs<-> iSCSI Target
> Endpoints inside of a KVM Guest (from the results in May posted with
> IOMMU aware 10 Gb on modern Nahelem hardware, see
> http://linux-iscsi.org/index.php/KVM-LIO-Target), we have been able to
> dump the entire running target fabric configfs hierarchy to a single
> struct file on a KVM Guest root device using python code on the order of
> ~30 seconds for those 10000 active iSCSI endpoints. In configfs terms,
> this means:
>
> *) 7 configfs groups (directories), ~50 configfs attributes (files) per
> Virtual HBA+FILEIO LUN
> *) 15 configfs groups (directories), ~60 configfs attributes (files per
> iSCSI fabric Endpoint
>
> Which comes out to a total of ~220000 groups and ~1100000 attributes
> active configfs objects living in the configfs_dir_cache that are being
> dumped inside of the single KVM guest instances, including symlinks
> between the fabric modules to establish the SCSI ports containing
> complete set of SPC-4 and RFC-3720 features, et al.
>
You achieved 3 million syscalls/sec from Python code? That's very
impressive.
Note with syscalls you could have done it with 10K syscalls (Python
supports packing and unpacking structs quite well, and also directly
calling C code IIRC).
> Also on the kernel<-> user API interaction compatibility side, I have
> found the 3.x configfs enabled code adventagous over the LIO 2.9 code
> (that used an ioctl for everything) because it allows us to do backwards
> compat for future versions without using any userspace C code, which in
> IMHO makes maintaining userspace packages for complex kernel stacks with
> massive amounts of metadata + real-time configuration considerations.
> No longer having ioctl compatibility issues between LIO versions as the
> structures passed via ioctl change, and being able to do backwards
> compat with small amounts of interpreted code against configfs layout
> changes makes maintaining the kernel<-> user API really have made this
> that much easier for me.
>
configfs is more maintainable that a bunch of hand-maintained ioctls.
But if we put some effort into an extendable syscall infrastructure
(perhaps to the point of using an IDL) I'm sure we can improve on that
without the problems pseudo filesystems introduce.
> Anyways, I though these might be useful to the discussion as it releates
> to potental uses of configfs on the KVM Host or other projects that
> really make sense, and/or to improve the upstream implementation so that
> other users (like myself) can benefit from improvements to configfs.
>
I can't really fault a project for using configfs; it's an accepted and
recommented (by the community) interface. I'd much prefer it though if
there was an effort to create a usable fd/struct based alternative.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
^ permalink raw reply
* Re: mlx4 2.6.31-rc5: SW2HW_EQ failed.
From: Christoph Lameter @ 2009-08-19 19:58 UTC (permalink / raw)
To: Roland Dreier; +Cc: netdev, Yevgeny Petrilin
In-Reply-To: <adaab1v1t93.fsf@cisco.com>
On Wed, 19 Aug 2009, Roland Dreier wrote:
>
> > System hangs when unloading the mlx4 driver f.e.
>
> I guess that means things work for a while if you get to the point of
> unloading? Or do you still get an error on load? Any way to get a
> trace or anything?
It hung on unload. Playing around with BIOS configs now. Seems that C
states were disabled so we also had some ACPI issues.
> BTW, are you using mlx4_en or mlx4_ib?
mlx4_ib.
> I'll try to reproduce here by booting with "possible_cpus=32" and see
> what happens...
Thanks.
^ permalink raw reply
* Re: [PATCH 6/7] sky2: no recycling
From: Stephen Hemminger @ 2009-08-19 19:58 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20090819011738.993523293@vyatta.com>
On Tue, 18 Aug 2009 18:17:10 -0700
Stephen Hemminger <shemminger@vyatta.com> wrote:
> Recycling turns out to be a bad idea! For most use cases, the
> packet can not be reused: TCP packets are cloned. Even for the ideal
> case of forwarding, it hurts performance because of CPU ping/pong.
> On a multi-core system forwarding of 64 byte packets is worse
> much worse: recycling = 24% forwarded vs no recycling = 42% forwarded
Minor correction on numbers. The actual data for unidirectional
forwarding is 30% vs 24%. Previous data had hardware flow/control enabled
which skewed the numbers.
^ permalink raw reply
* Re: sd8686 linux system hang: not always
From: Dan Williams @ 2009-08-19 19:39 UTC (permalink / raw)
To: Benoît Vaillant; +Cc: netdev
In-Reply-To: <20090819185605.GA19345@kaos.fbx.proxad.net>
On Wed, 2009-08-19 at 20:56 +0200, Benoît Vaillant wrote:
> Hi list,
>
> It seems my previous message for libertas-dev didn't make its ways
> through, so resending it... Appologies if it did in any way and for
> multiple receptions if any :/
>
> Here are a few notes, to try to isolate the issue(s?) regarding this
> problem.
>
> /*
> Just a bit of context information:
> I'm using an MID (quite close to an Aigo, although bios differs,
> probably some hardware too, yet I've not checked much on that). I'm
> trying to use my Marvell card to get wifi access on a debian
> installation. The other OS installed (midinux) successfully gets a
> connection using the 8686_v9 mobilin driver, so I'd not go for any
> hardware issue. This driver failing to compile 'out of the box' on
> fresh kernels, I thought getting the libertas module working would be
> a better way to get through.
> */
>
> I had the same kernel hang issue as reported earlier on this list[1]
> and can also confirm the reload issue[2] still seems to be here,
> although I'm not really bothered by that for the moment and didn't
> take any time at assessing it.
>
> I did a few attempts at getting associated with an AP, initially
> unsuccessfully getting a hang, my latest attempts leading to a better
> result (no association, yet no hang! :) ).
>
> I've tried both 8.73.7.p3 and 9.70.3.p24 versions of the firmware (and
> the one provided by midinux, which I highly suspect to be a mere
> 8.73.7.p3). In my latest attempts, I focused only on the 8.73.7.p3
> since it gave good results using iwlist scannig: I could list the
> available APs fine.
>
> Now, with the attempts I did, using a kernel 2.6.31-rc5, I used to
> hang. Using some manually inserted printk()s, it lead me from the
> libertas driver to mmc, esp. in drivers/mmc/core.c the
> mmc_wait_for_req(...) function. It was done without mmc debugging
> messages, with libertas debugging symbols activated but not printed
> out.
Just for context, what SDIO controller are you using on this platform?
Dan
> From there on, I switched to the wireless git[3] in order to be able
> to provide more convinient patches if needed. I immediately patched it
> against the attached proposal from last thread[4], adapting it due to
> compile issues (see below). I also gave a quick try at Philip's
> proposal[5], which didn't seem to work, unfortunately.
>
> about the patch: I didn't adapt it as proposed latter on in the thread
> by setting 0 values, but by reinserting the "old"
> cmd_ds_802_11_get_log log structure. Wrong thing?
>
> The good news using this kernel was that I wasn't always stuck in a
> hang: listing the APs works, connecting to an AP using WPA & french
> bands failed, yet without hanging (here, I had MMC & libertas
> debugging messages).
>
> The bad news is I can reproduce the hang using these sources quite
> easily if I do, say: an association request, followed by an iwconfig
> to check if the association was done *before* all the attempts were
> done. The attempts I did using iwconfig once the previous one
> timed-out were successfull.
>
> This leads me to think there are in fact two issues:
> - an association issue (at least in France). Maybe not much of a
> problem? I might even be the one doing the wrong thing, not the
> kernel :)
> - an issue when accessing the card (race condition?), which could be
> more subtle to handle.
>
> Using the fresh 2.6.31-rc6 kernel.org release, with MMC & libertas
> debugging messages on, I still can do an association request without
> getting neither a hang, nor an association. So maybe one of the race
> issues that are patched in it do solve part of this problem. Yet,
> running several AP association requests does hang.
>
> I'd be glad to do more testing and provide usefull information. Any
> idea(s) on which track(s) I should now follow and how I can help you
> solve this issue?
>
> Thanks,
>
> --
> Benoît
>
> [1] http://lists.infradead.org/pipermail/libertas-dev/2009-June/002487.html
> [2] http://lists.infradead.org/pipermail/libertas-dev/2009-June/002510.html
> [3] git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
> [4] http://lists.infradead.org/pipermail/libertas-dev/2009-June/002496.html
> [5] http://lists.infradead.org/pipermail/libertas-dev/2009-June/002494.html
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" 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
* [PATCH net-next-2.6] tcp: Remove redundant copy of MD5 authentication key
From: John Dykstra @ 2009-08-19 19:47 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger
Stephen, you might want to review this, since you use MD5
authentication.
---
Remove the copy of the MD5 authentication key from tcp_check_req().
This key has already been copied by tcp_v4_syn_recv_sock() or
tcp_v6_syn_recv_sock().
Signed-off-by: John Dykstra <john.dykstra1@gmail.com>
---
net/ipv4/tcp_minisocks.c | 23 -----------------------
1 files changed, 0 insertions(+), 23 deletions(-)
diff --git a/net/ipv4/tcp_minisocks.c b/net/ipv4/tcp_minisocks.c
index f8d67cc..6c8b422 100644
--- a/net/ipv4/tcp_minisocks.c
+++ b/net/ipv4/tcp_minisocks.c
@@ -657,29 +657,6 @@ struct sock *tcp_check_req(struct sock *sk, struct sk_buff *skb,
child = inet_csk(sk)->icsk_af_ops->syn_recv_sock(sk, skb, req, NULL);
if (child == NULL)
goto listen_overflow;
-#ifdef CONFIG_TCP_MD5SIG
- else {
- /* Copy over the MD5 key from the original socket */
- struct tcp_md5sig_key *key;
- struct tcp_sock *tp = tcp_sk(sk);
- key = tp->af_specific->md5_lookup(sk, child);
- if (key != NULL) {
- /*
- * We're using one, so create a matching key on the
- * newsk structure. If we fail to get memory then we
- * end up not copying the key across. Shucks.
- */
- char *newkey = kmemdup(key->key, key->keylen,
- GFP_ATOMIC);
- if (newkey) {
- if (!tcp_alloc_md5sig_pool())
- BUG();
- tp->af_specific->md5_add(child, child, newkey,
- key->keylen);
- }
- }
- }
-#endif
inet_csk_reqsk_queue_unlink(sk, req, prev);
inet_csk_reqsk_queue_removed(sk, req);
--
1.5.4.3
^ permalink raw reply related
* Re: mlx4 2.6.31-rc5: SW2HW_EQ failed.
From: Roland Dreier @ 2009-08-19 19:46 UTC (permalink / raw)
To: Christoph Lameter; +Cc: netdev, Yevgeny Petrilin
In-Reply-To: <alpine.DEB.1.10.0908191135110.32015@gentwo.org>
> System hangs when unloading the mlx4 driver f.e.
I guess that means things work for a while if you get to the point of
unloading? Or do you still get an error on load? Any way to get a
trace or anything?
BTW, are you using mlx4_en or mlx4_ib?
I'll try to reproduce here by booting with "possible_cpus=32" and see
what happens...
- R.
^ permalink raw reply
* RE: PATCH: Network Device Naming mechanism and policy
From: Jordan_Hargrave @ 2009-08-19 19:40 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-hotplug
In-Reply-To: <1250709985.2874.41.camel@achroite>
-----Original Message-----
From: Ben Hutchings [mailto:bhutchings@solarflare.com]
Sent: Wed 8/19/2009 14:26
To: Hargrave, Jordan
Cc: netdev@vger.kernel.org; linux-hotplug@vger.kernel.org
Subject: Re: PATCH: Network Device Naming mechanism and policy
On Wed, 2009-08-19 at 13:56 -0500, Jordan_Hargrave@Dell.com wrote:
> This is from an old discussion several months ago:
> http://lkml.org/lkml/2009/3/24/357
> http://lkml.org/lkml/2009/3/24/380
>
> Basically the issue is that between a race in udev and PCI scan order the ethX IDs may not
> be consistent between reboots. The idea is to use a mechanism similar to how disks now can
> be accessed by their LABEL/PATH/UUID instead of raw /dev/sdX ids.
>
> example udev config:
> SUBSYSTEM=="net", SYMLINK+="net/by-mac/$sysfs{ifindex}.$sysfs{address}"
> SUBSYSTEM=="net", PROGRAM="/sbin/biosdevname -i %k --policy=all_names", SYMLINK+="net/by-chassis-id/%c"
>
> The following patch will create a device node for network devices based off their ifindex;
> udev can then use this device node for creating symlinks in /dev/net/xxxx similar to the
> way that disks now use by-label and by-path symlinks.
>
> Combining this with the biosdevname utility and patches to common network utilities,
> it could be possible to access ethernet devices by their PCI path or BIOS Label.
>
> eg. ifconfig Embedded_NIC_1
Nice idea, but wouldn't it be "ifconfig LABEL=Embedded_NIC_1"?
** Still debating that.. if ifconfig and other tools were smart enough to figure it out
** Right now we have a library that lets you specify it by device node:
** ifconfig /dev/net/by-chassis-id/eth0_s0 for example
> --- include/linux/major.h~ 2009-07-30 18:34:47.000000000 -0400
> +++ include/linux/major.h 2009-08-05 14:52:10.000000000 -0400
> @@ -169,6 +169,7 @@
> #define IBM_FS3270_MAJOR 228
>
> #define VIOTAPE_MAJOR 230
> +#define NETDEV_MAJOR 234
>
> #define BLOCK_EXT_MAJOR 259
> #define SCSI_OSD_MAJOR 260 /* open-osd's OSD scsi device */
> --- net/core/net-sysfs.cx 2009-08-05 15:00:13.000000000 -0400
> +++ net/core/net-sysfs.c 2009-08-05 15:01:20.000000000 -0400
> @@ -11,6 +11,7 @@
>
> #include <linux/capability.h>
> #include <linux/kernel.h>
> +#include <linux/major.h>
> #include <linux/netdevice.h>
> #include <linux/if_arp.h>
> #include <net/sock.h>
> @@ -496,6 +497,7 @@ int netdev_register_kobject(struct net_d
> dev->class = &net_class;
> dev->platform_data = net;
> dev->groups = groups;
> + dev->devt = MKDEV(NETDEV_MAJOR, net->ifindex);
[...]
Since this major number is unregistered, the device inode can only be
stat'd and not open'd, which seems like a bit of a hack. Is there
anything that would stop register_chrdev(0, ...) from allocating this
major number, causing network devices to be confused with some other
device type?
** yeah a bit of a hack.. I suppose the netdev code could allocate a
** dynamic major node at startup with register_chrdev.. since nothing
** would use the hardcoded major:minor #s anyway (yet).
Maybe there *should* be character devices for network device
manipulation. It seems like that would avoid the race conditions that
device renaming and removal causes for name-based socket ioctls. But
maybe everyone should be using netlink for that instead.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model for vbus_driver objects
From: Nicholas A. Bellinger @ 2009-08-19 19:34 UTC (permalink / raw)
To: Gregory Haskins
Cc: Avi Kivity, Ingo Molnar, Anthony Liguori, kvm, alacrityvm-devel,
linux-kernel, netdev, Michael S. Tsirkin, Ira W. Snyder,
Joel Becker
In-Reply-To: <1250709574.27590.178.camel@haakon2.linux-iscsi.org>
On Wed, 2009-08-19 at 12:19 -0700, Nicholas A. Bellinger wrote:
> On Wed, 2009-08-19 at 14:39 -0400, Gregory Haskins wrote:
> > Hi Nicholas
> >
> > Nicholas A. Bellinger wrote:
> > > On Wed, 2009-08-19 at 10:11 +0300, Avi Kivity wrote:
> > >> On 08/19/2009 09:28 AM, Gregory Haskins wrote:
> > >>> Avi Kivity wrote:
> > >
> > > <SNIP>
> > >
> > >>> Basically, what it comes down to is both vbus and vhost need
> > >>> configuration/management. Vbus does it with sysfs/configfs, and vhost
> > >>> does it with ioctls. I ultimately decided to go with sysfs/configfs
> > >>> because, at least that the time I looked, it seemed like the "blessed"
> > >>> way to do user->kernel interfaces.
> > >>>
> > >> I really dislike that trend but that's an unrelated discussion.
> > >>
> > >>>> They need to be connected to the real world somehow. What about
> > >>>> security? can any user create a container and devices and link them to
> > >>>> real interfaces? If not, do you need to run the VM as root?
> > >>>>
> > >>> Today it has to be root as a result of weak mode support in configfs, so
> > >>> you have me there. I am looking for help patching this limitation, though.
> > >>>
> > >>>
> > >> Well, do you plan to address this before submission for inclusion?
> > >>
> > >
> > > Greetings Avi and Co,
> > >
> > > I have been following this thread, and although I cannot say that I am
> > > intimately fimilar with all of the virtualization considerations
> > > involved to really add anything use to that side of the discussion, I
> > > think you guys are doing a good job of explaining the technical issues
> > > for the non virtualization wizards following this thread. :-)
> > >
> > > Anyways, I was wondering if you might be interesting in sharing your
> > > concerns wrt to configfs (conigfs maintainer CC'ed), at some point..?
> >
> > So for those tuning in, the reference here is the use of configfs for
> > the management of this component of AlacrityVM, called "virtual-bus"
> >
> > http://developer.novell.com/wiki/index.php/Virtual-bus
> >
> > > As you may recall, I have been using configfs extensively for the 3.x
> > > generic target core infrastructure and iSCSI fabric modules living in
> > > lio-core-2.6.git/drivers/target/target_core_configfs.c and
> > > lio-core-2.6.git/drivers/lio-core/iscsi_target_config.c, and have found
> > > it to be extraordinarly useful for the purposes of a implementing a
> > > complex kernel level target mode stack that is expected to manage
> > > massive amounts of metadata, allow for real-time configuration, share
> > > data structures (eg: SCSI Target Ports) between other kernel fabric
> > > modules and manage the entire set of fabrics using only intrepetered
> > > userspace code.
> >
> > I concur. Configfs provided me a very natural model to express
> > resource-containers and their respective virtual-device objects.
> >
> > >
> > > Using the 10000 1:1 mapped TCM Virtual HBA+FILEIO LUNs <-> iSCSI Target
> > > Endpoints inside of a KVM Guest (from the results in May posted with
> > > IOMMU aware 10 Gb on modern Nahelem hardware, see
> > > http://linux-iscsi.org/index.php/KVM-LIO-Target), we have been able to
> > > dump the entire running target fabric configfs hierarchy to a single
> > > struct file on a KVM Guest root device using python code on the order of
> > > ~30 seconds for those 10000 active iSCSI endpoints. In configfs terms,
> > > this means:
> > >
> > > *) 7 configfs groups (directories), ~50 configfs attributes (files) per
> > > Virtual HBA+FILEIO LUN
> > > *) 15 configfs groups (directories), ~60 configfs attributes (files per
> > > iSCSI fabric Endpoint
> > >
> > > Which comes out to a total of ~220000 groups and ~1100000 attributes
> > > active configfs objects living in the configfs_dir_cache that are being
> > > dumped inside of the single KVM guest instances, including symlinks
> > > between the fabric modules to establish the SCSI ports containing
> > > complete set of SPC-4 and RFC-3720 features, et al.
> > >
> > > Also on the kernel <-> user API interaction compatibility side, I have
> > > found the 3.x configfs enabled code adventagous over the LIO 2.9 code
> > > (that used an ioctl for everything) because it allows us to do backwards
> > > compat for future versions without using any userspace C code, which in
> > > IMHO makes maintaining userspace packages for complex kernel stacks with
> > > massive amounts of metadata + real-time configuration considerations.
> > > No longer having ioctl compatibility issues between LIO versions as the
> > > structures passed via ioctl change, and being able to do backwards
> > > compat with small amounts of interpreted code against configfs layout
> > > changes makes maintaining the kernel <-> user API really have made this
> > > that much easier for me.
> > >
> > > Anyways, I though these might be useful to the discussion as it releates
> > > to potental uses of configfs on the KVM Host or other projects that
> > > really make sense, and/or to improve the upstream implementation so that
> > > other users (like myself) can benefit from improvements to configfs.
> > >
> > > Many thanks for your most valuable of time,
> >
> > Thank you for the explanation of your setup.
> >
> > Configfs mostly works for the vbus project "as is". As Avi pointed out,
> > I currently have a limitation w.r.t. perms. Forgive me if what I am
> > about to say is overly simplistic. Its been quite a few months since I
> > worked on the configfs portion of the code, so my details may be fuzzy.
> >
> > What it boiled down to is I need is a way to better manage perms
>
> I have not looked at implementing this personally, so I am not sure how
> this would look in fs/configfs/ off the top of my head.. Joel, have you
> had any thoughts on this..?
>
Actually, something that I have been using is for simple stuff is:
if (!capable(CAP_SYS_ADMIN))
for controlling I/O to configfs attributes from non priviledged users
for iSCSI authentication information living in struct
config_item_operations lio_target_nacl_auth_cit, the code is here:
http://git.kernel.org/?p=linux/kernel/git/nab/lio-core-2.6.git;a=blob;f=drivers/lio-core/iscsi_target_configfs.c;h=1230b74577076a184b756b3883fb56c6050c7d87;hb=HEAD#l803
I am also using the CONFIGFS Extended Macros, CONFIGS_EATTR() which I
created to allow me to use more than one struct config_groups per parent
structure, and use less lines of code when defining configfs attributes
using generic store() and show() functions:
http://git.kernel.org/?p=linux/kernel/git/nab/lio-core-2.6.git;a=blob;f=include/target/configfs_macros.h
--nab
^ permalink raw reply
* [patch]replace runtime power management primitives in kaweth driver
From: Oliver Neukum @ 2009-08-19 19:35 UTC (permalink / raw)
To: Alan Stern, linux-usb, netdev
This patch removes a rare use of the USB power management API which
won't be supported after the conversion to the new generic runtime power
management framework. Functionality is not altered.
Signed-off-by: Oliver Neukum <oliver@neukum.org>
Hi,
please accept this for the next merge window. It will be needed for
the adoption of the generic framework for USB.
Regards
Oliver
--
commit eb6ea8b517c6390e85585aa3f24483840296487e
Author: Oliver Neukum <oliver@neukum.org>
Date: Wed Aug 19 20:27:42 2009 +0200
usb: remove rare pm primitive for conversion to new API
diff --git a/drivers/net/usb/kaweth.c b/drivers/net/usb/kaweth.c
index 1f9ec29..6db2c70 100644
--- a/drivers/net/usb/kaweth.c
+++ b/drivers/net/usb/kaweth.c
@@ -721,7 +721,7 @@ static int kaweth_open(struct net_device *net)
return 0;
err_out:
- usb_autopm_enable(kaweth->intf);
+ usb_autopm_put_interface(kaweth->intf);
return -EIO;
}
@@ -758,7 +758,7 @@ static int kaweth_close(struct net_device *net)
kaweth->status &= ~KAWETH_STATUS_CLOSING;
- usb_autopm_enable(kaweth->intf);
+ usb_autopm_put_interface(kaweth->intf);
return 0;
}
^ permalink raw reply related
* Re: PATCH: Network Device Naming mechanism and policy
From: Ben Hutchings @ 2009-08-19 19:26 UTC (permalink / raw)
To: Jordan_Hargrave; +Cc: netdev, linux-hotplug
In-Reply-To: <5DDAB7BA7BDB58439DD0EED0B8E9A3AE011CD964@ausx3mpc102.aus.amer.dell.com>
On Wed, 2009-08-19 at 13:56 -0500, Jordan_Hargrave@Dell.com wrote:
> This is from an old discussion several months ago:
> http://lkml.org/lkml/2009/3/24/357
> http://lkml.org/lkml/2009/3/24/380
>
> Basically the issue is that between a race in udev and PCI scan order the ethX IDs may not
> be consistent between reboots. The idea is to use a mechanism similar to how disks now can
> be accessed by their LABEL/PATH/UUID instead of raw /dev/sdX ids.
>
> example udev config:
> SUBSYSTEM=="net", SYMLINK+="net/by-mac/$sysfs{ifindex}.$sysfs{address}"
> SUBSYSTEM=="net", PROGRAM="/sbin/biosdevname -i %k --policy=all_names", SYMLINK+="net/by-chassis-id/%c"
>
> The following patch will create a device node for network devices based off their ifindex;
> udev can then use this device node for creating symlinks in /dev/net/xxxx similar to the
> way that disks now use by-label and by-path symlinks.
>
> Combining this with the biosdevname utility and patches to common network utilities,
> it could be possible to access ethernet devices by their PCI path or BIOS Label.
>
> eg. ifconfig Embedded_NIC_1
Nice idea, but wouldn't it be "ifconfig LABEL=Embedded_NIC_1"?
> --- include/linux/major.h~ 2009-07-30 18:34:47.000000000 -0400
> +++ include/linux/major.h 2009-08-05 14:52:10.000000000 -0400
> @@ -169,6 +169,7 @@
> #define IBM_FS3270_MAJOR 228
>
> #define VIOTAPE_MAJOR 230
> +#define NETDEV_MAJOR 234
>
> #define BLOCK_EXT_MAJOR 259
> #define SCSI_OSD_MAJOR 260 /* open-osd's OSD scsi device */
> --- net/core/net-sysfs.cx 2009-08-05 15:00:13.000000000 -0400
> +++ net/core/net-sysfs.c 2009-08-05 15:01:20.000000000 -0400
> @@ -11,6 +11,7 @@
>
> #include <linux/capability.h>
> #include <linux/kernel.h>
> +#include <linux/major.h>
> #include <linux/netdevice.h>
> #include <linux/if_arp.h>
> #include <net/sock.h>
> @@ -496,6 +497,7 @@ int netdev_register_kobject(struct net_d
> dev->class = &net_class;
> dev->platform_data = net;
> dev->groups = groups;
> + dev->devt = MKDEV(NETDEV_MAJOR, net->ifindex);
[...]
Since this major number is unregistered, the device inode can only be
stat'd and not open'd, which seems like a bit of a hack. Is there
anything that would stop register_chrdev(0, ...) from allocating this
major number, causing network devices to be confused with some other
device type?
Maybe there *should* be character devices for network device
manipulation. It seems like that would avoid the race conditions that
device renaming and removal causes for name-based socket ioctls. But
maybe everyone should be using netlink for that instead.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model for vbus_driver objects
From: Nicholas A. Bellinger @ 2009-08-19 19:19 UTC (permalink / raw)
To: Gregory Haskins
Cc: Avi Kivity, Ingo Molnar, Anthony Liguori, kvm, alacrityvm-devel,
linux-kernel, netdev, Michael S. Tsirkin, Ira W. Snyder,
Joel Becker
In-Reply-To: <4A8C46FF.1070107@gmail.com>
On Wed, 2009-08-19 at 14:39 -0400, Gregory Haskins wrote:
> Hi Nicholas
>
> Nicholas A. Bellinger wrote:
> > On Wed, 2009-08-19 at 10:11 +0300, Avi Kivity wrote:
> >> On 08/19/2009 09:28 AM, Gregory Haskins wrote:
> >>> Avi Kivity wrote:
> >
> > <SNIP>
> >
> >>> Basically, what it comes down to is both vbus and vhost need
> >>> configuration/management. Vbus does it with sysfs/configfs, and vhost
> >>> does it with ioctls. I ultimately decided to go with sysfs/configfs
> >>> because, at least that the time I looked, it seemed like the "blessed"
> >>> way to do user->kernel interfaces.
> >>>
> >> I really dislike that trend but that's an unrelated discussion.
> >>
> >>>> They need to be connected to the real world somehow. What about
> >>>> security? can any user create a container and devices and link them to
> >>>> real interfaces? If not, do you need to run the VM as root?
> >>>>
> >>> Today it has to be root as a result of weak mode support in configfs, so
> >>> you have me there. I am looking for help patching this limitation, though.
> >>>
> >>>
> >> Well, do you plan to address this before submission for inclusion?
> >>
> >
> > Greetings Avi and Co,
> >
> > I have been following this thread, and although I cannot say that I am
> > intimately fimilar with all of the virtualization considerations
> > involved to really add anything use to that side of the discussion, I
> > think you guys are doing a good job of explaining the technical issues
> > for the non virtualization wizards following this thread. :-)
> >
> > Anyways, I was wondering if you might be interesting in sharing your
> > concerns wrt to configfs (conigfs maintainer CC'ed), at some point..?
>
> So for those tuning in, the reference here is the use of configfs for
> the management of this component of AlacrityVM, called "virtual-bus"
>
> http://developer.novell.com/wiki/index.php/Virtual-bus
>
> > As you may recall, I have been using configfs extensively for the 3.x
> > generic target core infrastructure and iSCSI fabric modules living in
> > lio-core-2.6.git/drivers/target/target_core_configfs.c and
> > lio-core-2.6.git/drivers/lio-core/iscsi_target_config.c, and have found
> > it to be extraordinarly useful for the purposes of a implementing a
> > complex kernel level target mode stack that is expected to manage
> > massive amounts of metadata, allow for real-time configuration, share
> > data structures (eg: SCSI Target Ports) between other kernel fabric
> > modules and manage the entire set of fabrics using only intrepetered
> > userspace code.
>
> I concur. Configfs provided me a very natural model to express
> resource-containers and their respective virtual-device objects.
>
> >
> > Using the 10000 1:1 mapped TCM Virtual HBA+FILEIO LUNs <-> iSCSI Target
> > Endpoints inside of a KVM Guest (from the results in May posted with
> > IOMMU aware 10 Gb on modern Nahelem hardware, see
> > http://linux-iscsi.org/index.php/KVM-LIO-Target), we have been able to
> > dump the entire running target fabric configfs hierarchy to a single
> > struct file on a KVM Guest root device using python code on the order of
> > ~30 seconds for those 10000 active iSCSI endpoints. In configfs terms,
> > this means:
> >
> > *) 7 configfs groups (directories), ~50 configfs attributes (files) per
> > Virtual HBA+FILEIO LUN
> > *) 15 configfs groups (directories), ~60 configfs attributes (files per
> > iSCSI fabric Endpoint
> >
> > Which comes out to a total of ~220000 groups and ~1100000 attributes
> > active configfs objects living in the configfs_dir_cache that are being
> > dumped inside of the single KVM guest instances, including symlinks
> > between the fabric modules to establish the SCSI ports containing
> > complete set of SPC-4 and RFC-3720 features, et al.
> >
> > Also on the kernel <-> user API interaction compatibility side, I have
> > found the 3.x configfs enabled code adventagous over the LIO 2.9 code
> > (that used an ioctl for everything) because it allows us to do backwards
> > compat for future versions without using any userspace C code, which in
> > IMHO makes maintaining userspace packages for complex kernel stacks with
> > massive amounts of metadata + real-time configuration considerations.
> > No longer having ioctl compatibility issues between LIO versions as the
> > structures passed via ioctl change, and being able to do backwards
> > compat with small amounts of interpreted code against configfs layout
> > changes makes maintaining the kernel <-> user API really have made this
> > that much easier for me.
> >
> > Anyways, I though these might be useful to the discussion as it releates
> > to potental uses of configfs on the KVM Host or other projects that
> > really make sense, and/or to improve the upstream implementation so that
> > other users (like myself) can benefit from improvements to configfs.
> >
> > Many thanks for your most valuable of time,
>
> Thank you for the explanation of your setup.
>
> Configfs mostly works for the vbus project "as is". As Avi pointed out,
> I currently have a limitation w.r.t. perms. Forgive me if what I am
> about to say is overly simplistic. Its been quite a few months since I
> worked on the configfs portion of the code, so my details may be fuzzy.
>
> What it boiled down to is I need is a way to better manage perms
I have not looked at implementing this personally, so I am not sure how
this would look in fs/configfs/ off the top of my head.. Joel, have you
had any thoughts on this..?
> (and to
> be able to do it cross sysfs and configfs would be ideal).
>
I had coded up a patch last year to to allow configfs to access sysfs
symlinks in the context of target_core_mod storage object (Linux/SCSI,
Linux/Block, Linux/FILEIO) registration, which did work but ended up not
really making sense and was (thankully) rejected by GregKH, more of that
discussion here:
http://linux.derkeiler.com/Mailing-Lists/Kernel/2008-10/msg06559.html
I am not sure if the sharing of permissions between sysfs and configfs
would run into the same types of limitiations as the above..
> For instance, I would like to be able to assign groups to configfs
> directories, like /config/vbus/devices, such that
>
> mkdir /config/vbus/devices/foo
>
> would not require root if that GID was permitted.
>
> Are there ways to do this (now, or in upcoming releases)? If not, I may
> be interested in helping to add this feature, so please advise how best
> to achieve this.
>
Not that I am aware of. However, I think this would be useful for
generic configfs, and I think user/group permissions on configfs
groups/dirs and attribute/items would be quite useful for the LIO 3.x
configfs enabled generic target engine.
Many thanks for your most valuable of time,
--nab
> Kind Regards,
> -Greg
>
^ permalink raw reply
* Re: [PATCH v2] net: fix ks8851 build errors
From: David Miller @ 2009-08-19 19:13 UTC (permalink / raw)
To: randy.dunlap; +Cc: sfr, netdev, akpm, linux-next, linux-kernel
In-Reply-To: <20090819085202.810630a2.randy.dunlap@oracle.com>
From: Randy Dunlap <randy.dunlap@oracle.com>
Date: Wed, 19 Aug 2009 08:52:02 -0700
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> Fix build errors due to missing Kconfig select of CRC32:
>
> ks8851.c:(.text+0x7d2ee): undefined reference to `crc32_le'
> ks8851.c:(.text+0x7d2f5): undefined reference to `bitrev32'
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Applied, thanks Randy.
^ permalink raw reply
* PATCH: Network Device Naming mechanism and policy
From: Jordan_Hargrave @ 2009-08-19 18:56 UTC (permalink / raw)
To: netdev, linux-hotplug
In-Reply-To: <5DDAB7BA7BDB58439DD0EED0B8E9A3AE011CD92D@ausx3mpc102.aus.amer.dell.com>
This is from an old discussion several months ago:
http://lkml.org/lkml/2009/3/24/357
http://lkml.org/lkml/2009/3/24/380
Basically the issue is that between a race in udev and PCI scan order the ethX IDs may not
be consistent between reboots. The idea is to use a mechanism similar to how disks now can
be accessed by their LABEL/PATH/UUID instead of raw /dev/sdX ids.
example udev config:
SUBSYSTEM=="net", SYMLINK+="net/by-mac/$sysfs{ifindex}.$sysfs{address}"
SUBSYSTEM=="net", PROGRAM="/sbin/biosdevname -i %k --policy=all_names", SYMLINK+="net/by-chassis-id/%c"
The following patch will create a device node for network devices based off their ifindex;
udev can then use this device node for creating symlinks in /dev/net/xxxx similar to the
way that disks now use by-label and by-path symlinks.
Combining this with the biosdevname utility and patches to common network utilities,
it could be possible to access ethernet devices by their PCI path or BIOS Label.
eg. ifconfig Embedded_NIC_1
--- include/linux/major.h~ 2009-07-30 18:34:47.000000000 -0400
+++ include/linux/major.h 2009-08-05 14:52:10.000000000 -0400
@@ -169,6 +169,7 @@
#define IBM_FS3270_MAJOR 228
#define VIOTAPE_MAJOR 230
+#define NETDEV_MAJOR 234
#define BLOCK_EXT_MAJOR 259
#define SCSI_OSD_MAJOR 260 /* open-osd's OSD scsi device */
--- net/core/net-sysfs.cx 2009-08-05 15:00:13.000000000 -0400
+++ net/core/net-sysfs.c 2009-08-05 15:01:20.000000000 -0400
@@ -11,6 +11,7 @@
#include <linux/capability.h>
#include <linux/kernel.h>
+#include <linux/major.h>
#include <linux/netdevice.h>
#include <linux/if_arp.h>
#include <net/sock.h>
@@ -496,6 +497,7 @@ int netdev_register_kobject(struct net_d
dev->class = &net_class;
dev->platform_data = net;
dev->groups = groups;
+ dev->devt = MKDEV(NETDEV_MAJOR, net->ifindex);
BUILD_BUG_ON(BUS_ID_SIZE < IFNAMSIZ);
dev_set_name(dev, "%s", net->name);
--jordan hargrave
Dell Enterprise Linux Engineering
^ permalink raw reply
* sd8686 linux system hang: not always
From: Benoît Vaillant @ 2009-08-19 18:56 UTC (permalink / raw)
To: netdev
Hi list,
It seems my previous message for libertas-dev didn't make its ways
through, so resending it... Appologies if it did in any way and for
multiple receptions if any :/
Here are a few notes, to try to isolate the issue(s?) regarding this
problem.
/*
Just a bit of context information:
I'm using an MID (quite close to an Aigo, although bios differs,
probably some hardware too, yet I've not checked much on that). I'm
trying to use my Marvell card to get wifi access on a debian
installation. The other OS installed (midinux) successfully gets a
connection using the 8686_v9 mobilin driver, so I'd not go for any
hardware issue. This driver failing to compile 'out of the box' on
fresh kernels, I thought getting the libertas module working would be
a better way to get through.
*/
I had the same kernel hang issue as reported earlier on this list[1]
and can also confirm the reload issue[2] still seems to be here,
although I'm not really bothered by that for the moment and didn't
take any time at assessing it.
I did a few attempts at getting associated with an AP, initially
unsuccessfully getting a hang, my latest attempts leading to a better
result (no association, yet no hang! :) ).
I've tried both 8.73.7.p3 and 9.70.3.p24 versions of the firmware (and
the one provided by midinux, which I highly suspect to be a mere
8.73.7.p3). In my latest attempts, I focused only on the 8.73.7.p3
since it gave good results using iwlist scannig: I could list the
available APs fine.
Now, with the attempts I did, using a kernel 2.6.31-rc5, I used to
hang. Using some manually inserted printk()s, it lead me from the
libertas driver to mmc, esp. in drivers/mmc/core.c the
mmc_wait_for_req(...) function. It was done without mmc debugging
messages, with libertas debugging symbols activated but not printed
out.
From there on, I switched to the wireless git[3] in order to be able
to provide more convinient patches if needed. I immediately patched it
against the attached proposal from last thread[4], adapting it due to
compile issues (see below). I also gave a quick try at Philip's
proposal[5], which didn't seem to work, unfortunately.
about the patch: I didn't adapt it as proposed latter on in the thread
by setting 0 values, but by reinserting the "old"
cmd_ds_802_11_get_log log structure. Wrong thing?
The good news using this kernel was that I wasn't always stuck in a
hang: listing the APs works, connecting to an AP using WPA & french
bands failed, yet without hanging (here, I had MMC & libertas
debugging messages).
The bad news is I can reproduce the hang using these sources quite
easily if I do, say: an association request, followed by an iwconfig
to check if the association was done *before* all the attempts were
done. The attempts I did using iwconfig once the previous one
timed-out were successfull.
This leads me to think there are in fact two issues:
- an association issue (at least in France). Maybe not much of a
problem? I might even be the one doing the wrong thing, not the
kernel :)
- an issue when accessing the card (race condition?), which could be
more subtle to handle.
Using the fresh 2.6.31-rc6 kernel.org release, with MMC & libertas
debugging messages on, I still can do an association request without
getting neither a hang, nor an association. So maybe one of the race
issues that are patched in it do solve part of this problem. Yet,
running several AP association requests does hang.
I'd be glad to do more testing and provide usefull information. Any
idea(s) on which track(s) I should now follow and how I can help you
solve this issue?
Thanks,
--
Benoît
[1] http://lists.infradead.org/pipermail/libertas-dev/2009-June/002487.html
[2] http://lists.infradead.org/pipermail/libertas-dev/2009-June/002510.html
[3] git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
[4] http://lists.infradead.org/pipermail/libertas-dev/2009-June/002496.html
[5] http://lists.infradead.org/pipermail/libertas-dev/2009-June/002494.html
^ permalink raw reply
* (no subject)
From: Uknl @ 2009-08-19 18:31 UTC (permalink / raw)
(£1,000,000.00)Pounds is now yours.Congrats...Send your information to Mark
Robinson(markrobinson@9.cn).
Provide your Name, Address, Age, Phone, Occupation
^ permalink raw reply
* Re: [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model for vbus_driver objects
From: Gregory Haskins @ 2009-08-19 18:39 UTC (permalink / raw)
To: Nicholas A. Bellinger
Cc: Avi Kivity, Ingo Molnar, Anthony Liguori, kvm, alacrityvm-devel,
linux-kernel, netdev, Michael S. Tsirkin, Ira W. Snyder,
Joel Becker
In-Reply-To: <1250706227.27590.156.camel@haakon2.linux-iscsi.org>
[-- Attachment #1: Type: text/plain, Size: 5681 bytes --]
Hi Nicholas
Nicholas A. Bellinger wrote:
> On Wed, 2009-08-19 at 10:11 +0300, Avi Kivity wrote:
>> On 08/19/2009 09:28 AM, Gregory Haskins wrote:
>>> Avi Kivity wrote:
>
> <SNIP>
>
>>> Basically, what it comes down to is both vbus and vhost need
>>> configuration/management. Vbus does it with sysfs/configfs, and vhost
>>> does it with ioctls. I ultimately decided to go with sysfs/configfs
>>> because, at least that the time I looked, it seemed like the "blessed"
>>> way to do user->kernel interfaces.
>>>
>> I really dislike that trend but that's an unrelated discussion.
>>
>>>> They need to be connected to the real world somehow. What about
>>>> security? can any user create a container and devices and link them to
>>>> real interfaces? If not, do you need to run the VM as root?
>>>>
>>> Today it has to be root as a result of weak mode support in configfs, so
>>> you have me there. I am looking for help patching this limitation, though.
>>>
>>>
>> Well, do you plan to address this before submission for inclusion?
>>
>
> Greetings Avi and Co,
>
> I have been following this thread, and although I cannot say that I am
> intimately fimilar with all of the virtualization considerations
> involved to really add anything use to that side of the discussion, I
> think you guys are doing a good job of explaining the technical issues
> for the non virtualization wizards following this thread. :-)
>
> Anyways, I was wondering if you might be interesting in sharing your
> concerns wrt to configfs (conigfs maintainer CC'ed), at some point..?
So for those tuning in, the reference here is the use of configfs for
the management of this component of AlacrityVM, called "virtual-bus"
http://developer.novell.com/wiki/index.php/Virtual-bus
> As you may recall, I have been using configfs extensively for the 3.x
> generic target core infrastructure and iSCSI fabric modules living in
> lio-core-2.6.git/drivers/target/target_core_configfs.c and
> lio-core-2.6.git/drivers/lio-core/iscsi_target_config.c, and have found
> it to be extraordinarly useful for the purposes of a implementing a
> complex kernel level target mode stack that is expected to manage
> massive amounts of metadata, allow for real-time configuration, share
> data structures (eg: SCSI Target Ports) between other kernel fabric
> modules and manage the entire set of fabrics using only intrepetered
> userspace code.
I concur. Configfs provided me a very natural model to express
resource-containers and their respective virtual-device objects.
>
> Using the 10000 1:1 mapped TCM Virtual HBA+FILEIO LUNs <-> iSCSI Target
> Endpoints inside of a KVM Guest (from the results in May posted with
> IOMMU aware 10 Gb on modern Nahelem hardware, see
> http://linux-iscsi.org/index.php/KVM-LIO-Target), we have been able to
> dump the entire running target fabric configfs hierarchy to a single
> struct file on a KVM Guest root device using python code on the order of
> ~30 seconds for those 10000 active iSCSI endpoints. In configfs terms,
> this means:
>
> *) 7 configfs groups (directories), ~50 configfs attributes (files) per
> Virtual HBA+FILEIO LUN
> *) 15 configfs groups (directories), ~60 configfs attributes (files per
> iSCSI fabric Endpoint
>
> Which comes out to a total of ~220000 groups and ~1100000 attributes
> active configfs objects living in the configfs_dir_cache that are being
> dumped inside of the single KVM guest instances, including symlinks
> between the fabric modules to establish the SCSI ports containing
> complete set of SPC-4 and RFC-3720 features, et al.
>
> Also on the kernel <-> user API interaction compatibility side, I have
> found the 3.x configfs enabled code adventagous over the LIO 2.9 code
> (that used an ioctl for everything) because it allows us to do backwards
> compat for future versions without using any userspace C code, which in
> IMHO makes maintaining userspace packages for complex kernel stacks with
> massive amounts of metadata + real-time configuration considerations.
> No longer having ioctl compatibility issues between LIO versions as the
> structures passed via ioctl change, and being able to do backwards
> compat with small amounts of interpreted code against configfs layout
> changes makes maintaining the kernel <-> user API really have made this
> that much easier for me.
>
> Anyways, I though these might be useful to the discussion as it releates
> to potental uses of configfs on the KVM Host or other projects that
> really make sense, and/or to improve the upstream implementation so that
> other users (like myself) can benefit from improvements to configfs.
>
> Many thanks for your most valuable of time,
Thank you for the explanation of your setup.
Configfs mostly works for the vbus project "as is". As Avi pointed out,
I currently have a limitation w.r.t. perms. Forgive me if what I am
about to say is overly simplistic. Its been quite a few months since I
worked on the configfs portion of the code, so my details may be fuzzy.
What it boiled down to is I need is a way to better manage perms (and to
be able to do it cross sysfs and configfs would be ideal).
For instance, I would like to be able to assign groups to configfs
directories, like /config/vbus/devices, such that
mkdir /config/vbus/devices/foo
would not require root if that GID was permitted.
Are there ways to do this (now, or in upcoming releases)? If not, I may
be interested in helping to add this feature, so please advise how best
to achieve this.
Kind Regards,
-Greg
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]
^ permalink raw reply
* Re: [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model for vbus_driver objects
From: Gregory Haskins @ 2009-08-19 18:26 UTC (permalink / raw)
To: Avi Kivity
Cc: Ingo Molnar, kvm, alacrityvm-devel, linux-kernel, netdev,
Michael S. Tsirkin, Patrick Mullaney
In-Reply-To: <4A8BA5AE.3030308@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 16186 bytes --]
Avi Kivity wrote:
> On 08/19/2009 09:28 AM, Gregory Haskins wrote:
>> Avi Kivity wrote:
>>
>>> On 08/18/2009 05:46 PM, Gregory Haskins wrote:
>>>
>>>>
>>>>> Can you explain how vbus achieves RDMA?
>>>>>
>>>>> I also don't see the connection to real time guests.
>>>>>
>>>>>
>>>> Both of these are still in development. Trying to stay true to the
>>>> "release early and often" mantra, the core vbus technology is being
>>>> pushed now so it can be reviewed. Stay tuned for these other
>>>> developments.
>>>>
>>>>
>>> Hopefully you can outline how it works. AFAICT, RDMA and kernel bypass
>>> will need device assignment. If you're bypassing the call into the host
>>> kernel, it doesn't really matter how that call is made, does it?
>>>
>> This is for things like the setup of queue-pairs, and the transport of
>> door-bells, and ib-verbs. I am not on the team doing that work, so I am
>> not an expert in this area. What I do know is having a flexible and
>> low-latency signal-path was deemed a key requirement.
>>
>
> That's not a full bypass, then. AFAIK kernel bypass has userspace
> talking directly to the device.
Like I said, I am not an expert on the details here. I only work on the
vbus plumbing. FWIW, the work is derivative from the "Xen-IB" project
http://www.openib.org/archives/nov2006sc/xen-ib-presentation.pdf
There were issues with getting Xen-IB to map well into the Xen model.
Vbus was specifically designed to address some of those short-comings.
>
> Given that both virtio and vbus can use ioeventfds, I don't see how one
> can perform better than the other.
>
>> For real-time, a big part of it is relaying the guest scheduler state to
>> the host, but in a smart way. For instance, the cpu priority for each
>> vcpu is in a shared-table. When the priority is raised, we can simply
>> update the table without taking a VMEXIT. When it is lowered, we need
>> to inform the host of the change in case the underlying task needs to
>> reschedule.
>>
>
> This is best done using cr8/tpr so you don't have to exit at all. See
> also my vtpr support for Windows which does this in software, generally
> avoiding the exit even when lowering priority.
You can think of vTPR as a good model, yes. Generally, you can't
actually use it for our purposes for several reasons, however:
1) the prio granularity is too coarse (16 levels, -rt has 100)
2) it is too scope limited (it covers only interrupts, we need to have
additional considerations, like nested guest/host scheduling algorithms
against the vcpu, and prio-remap policies)
3) I use "priority" generally..there may be other non-priority based
policies that need to add state to the table (such as EDF deadlines, etc).
but, otherwise, the idea is the same. Besides, this was one example.
>
>> This is where the really fast call() type mechanism is important.
>>
>> Its also about having the priority flow-end to end, and having the vcpu
>> interrupt state affect the task-priority, etc (e.g. pending interrupts
>> affect the vcpu task prio).
>>
>> etc, etc.
>>
>> I can go on and on (as you know ;), but will wait till this work is more
>> concrete and proven.
>>
>
> Generally cpu state shouldn't flow through a device but rather through
> MSRs, hypercalls, and cpu registers.
Well, you can blame yourself for that one ;)
The original vbus was implemented as cpuid+hypercalls, partly for that
reason. You kicked me out of kvm.ko, so I had to make due with plan B
via a less direct PCI-BRIDGE route.
But in reality, it doesn't matter much. You can certainly have "system"
devices sitting on vbus that fit a similar role as "MSRs", so the access
method is more of an implementation detail. The key is it needs to be
fast, and optimize out extraneous exits when possible.
>
>> Basically, what it comes down to is both vbus and vhost need
>> configuration/management. Vbus does it with sysfs/configfs, and vhost
>> does it with ioctls. I ultimately decided to go with sysfs/configfs
>> because, at least that the time I looked, it seemed like the "blessed"
>> way to do user->kernel interfaces.
>>
>
> I really dislike that trend but that's an unrelated discussion.
Ok
>
>>> They need to be connected to the real world somehow. What about
>>> security? can any user create a container and devices and link them to
>>> real interfaces? If not, do you need to run the VM as root?
>>>
>> Today it has to be root as a result of weak mode support in configfs, so
>> you have me there. I am looking for help patching this limitation,
>> though.
>>
>>
>
> Well, do you plan to address this before submission for inclusion?
Maybe, maybe not. Its workable for now (i.e. run as root), so its
inclusion is not predicated on the availability of the fix, per se (at
least IMHO). If I can get it working before I get to pushing the core,
great! Patches welcome.
>
>>> I hope everyone agrees that it's an important issue for me and that I
>>> have to consider non-Linux guests. I also hope that you're considering
>>> non-Linux guests since they have considerable market share.
>>>
>> I didn't mean non-Linux guests are not important. I was disagreeing
>> with your assertion that it only works if its PCI. There are numerous
>> examples of IHV/ISV "bridge" implementations deployed in Windows, no?
>>
>
> I don't know.
>
>> If vbus is exposed as a PCI-BRIDGE, how is this different?
>>
>
> Technically it would work, but given you're not interested in Windows,
s/interested in/priortizing
For the time being, windows will not be RT, and windows can fall-back to
use virtio-net, etc. So I am ok with this. It will come in due time.
> who would write a driver?
Someone from the vbus community who is motivated enough and has the time
to do it, I suppose. We have people interested in looking at this
internally, but other items have pushed it primarily to the back-burner.
>
>>> Given I'm not the gateway to inclusion of vbus/venet, you don't need to
>>> ask me anything. I'm still free to give my opinion.
>>>
>> Agreed, and I didn't mean to suggest otherwise. It not clear if you are
>> wearing the "kvm maintainer" hat, or the "lkml community member" hat at
>> times, so its important to make that distinction. Otherwise, its not
>> clear if this is edict as my superior, or input as my peer. ;)
>>
>
> When I wear a hat, it is a Red Hat. However I am bareheaded most often.
>
> (that is, look at the contents of my message, not who wrote it or his
> role).
Like it or not, maintainers always carry more weight when they opine
what can and can't be done w.r.t. what can be perceived as their
relevant subsystem.
>
>>> With virtio, the number is 1 (or less if you amortize). Set up the ring
>>> entries and kick.
>>>
>> Again, I am just talking about basic PCI here, not the things we build
>> on top.
>>
>
> Whatever that means, it isn't interesting. Performance is measure for
> the whole stack.
>
>> The point is: the things we build on top have costs associated with
>> them, and I aim to minimize it. For instance, to do a "call()" kind of
>> interface, you generally need to pre-setup some per-cpu mappings so that
>> you can just do a single iowrite32() to kick the call off. Those
>> per-cpu mappings have a cost if you want them to be high-performance, so
>> my argument is that you ideally want to limit the number of times you
>> have to do this. My current design reduces this to "once".
>>
>
> Do you mean minimizing the setup cost? Seriously?
Not the time-to-complete-setup overhead. The residual costs, like
heap/vmap usage at run-time. You generally have to set up per-cpu
mappings to gain maximum performance. You would need it per-device, I
do it per-system. Its not a big deal in the grand-scheme of things,
really. But chalk that up as an advantage to my approach over yours,
nonetheless.
>
>>> There's no such thing as raw PCI. Every PCI device has a protocol. The
>>> protocol virtio chose is optimized for virtualization.
>>>
>> And its a question of how that protocol scales, more than how the
>> protocol works.
>>
>> Obviously the general idea of the protocol works, as vbus itself is
>> implemented as a PCI-BRIDGE and is therefore limited to the underlying
>> characteristics that I can get out of PCI (like PIO latency).
>>
>
> I thought we agreed that was insignificant?
I think I was agreeing with you, there. (e.g. obviously PIO latency is
acceptable, as I use it to underpin vbus)
>
>>> As I've mentioned before, prioritization is available on x86
>>>
>> But as Ive mentioned, it doesn't work very well.
>>
>
> I guess it isn't that important then. I note that clever prioritization
> in a guest is pointless if you can't do the same prioritization in the
> host.
I answer this below...
>
>>> , and coalescing scales badly.
>>>
>> Depends on what is scaling. Scaling vcpus? Yes, you are right.
>> Scaling the number of devices? No, this is where it improves.
>>
>
> If you queue pending messages instead of walking the device list, you
> may be right. Still, if hard interrupt processing takes 10% of your
> time you'll only have coalesced 10% of interrupts on average.
>
>>> irq window exits ought to be pretty rare, so we're only left with
>>> injection vmexits. At around 1us/vmexit, even 100,000 interrupts/vcpu
>>> (which is excessive) will only cost you 10% cpu time.
>>>
>> 1us is too much for what I am building, IMHO.
>
> You can't use current hardware then.
The point is that I am eliminating as many exits as possible, so 1us,
2us, whatever...it doesn't matter. The fastest exit is the one you
don't have to take.
>
>>> You're free to demultiplex an MSI to however many consumers you want,
>>> there's no need for a new bus for that.
>>>
>> Hmmm...can you elaborate?
>>
>
> Point all those MSIs at one vector. Its handler will have to poll all
> the attached devices though.
Right, thats broken.
>
>>> Do you use DNS. We use PCI-SIG. If Novell is a PCI-SIG member you can
>>> get a vendor ID and control your own virtio space.
>>>
>> Yeah, we have our own id. I am more concerned about making this design
>> make sense outside of PCI oriented environments.
>>
>
> IIRC we reuse the PCI IDs for non-PCI.
You already know how I feel about this gem.
>
>
>
>
>>>>> That's a bug, not a feature. It means poor scaling as the number of
>>>>> vcpus increases and as the number of devices increases.
>>>>>
>> vcpu increases, I agree (and am ok with, as I expect low vcpu count
>> machines to be typical).
>
> I'm not okay with it. If you wish people to adopt vbus over virtio
> you'll have to address all concerns, not just yours.
By building a community around the development of vbus, isnt this what I
am doing? Working towards making it usable for all?
>
>> nr of devices, I disagree. can you elaborate?
>>
>
> With message queueing, I retract my remark.
Ok.
>
>>> Windows,
>>>
>> Work in progress.
>>
>
> Interesting. Do you plan to open source the code? If not, will the
> binaries be freely available?
Ideally, yeah. But I guess that has to go through legal, etc. Right
now its primarily back-burnered. If someone wants to submit code to
support this, great!
>
>>
>>> large guests
>>>
>> Can you elaborate? I am not familiar with the term.
>>
>
> Many vcpus.
>
>>
>>> and multiqueue out of your design.
>>>
>> AFAICT, multiqueue should work quite nicely with vbus. Can you
>> elaborate on where you see the problem?
>>
>
> You said you aren't interested in it previously IIRC.
>
I don't think so, no. Perhaps I misspoke or was misunderstood. I
actually think its a good idea and will be looking to do this.
>>>>> x86 APIC is priority aware.
>>>>>
>>>>>
>>>> Have you ever tried to use it?
>>>>
>>>>
>>> I haven't, but Windows does.
>>>
>> Yeah, it doesn't really work well. Its an extremely rigid model that
>> (IIRC) only lets you prioritize in 16 groups spaced by IDT (0-15 are one
>> level, 16-31 are another, etc). Most of the embedded PICs I have worked
>> with supported direct remapping, etc. But in any case, Linux doesn't
>> support it so we are hosed no matter how good it is.
>>
>
> I agree that it isn't very clever (not that I am a real time expert) but
> I disagree about dismissing Linux support so easily. If prioritization
> is such a win it should be a win on the host as well and we should make
> it work on the host as well. Further I don't see how priorities on the
> guest can work if they don't on the host.
Its more about task priority in the case of real-time. We do stuff with
802.1p as well for control messages, etc. But for the most part, this
is an orthogonal effort. And yes, you are right, it would be nice to
have this interrupt classification capability in the host.
Generally this is mitigated by the use of irq-threads. You could argue
that if irq-threads help the host without a prioritized interrupt
controller, why cant the guest? The answer is simply that the host can
afford sub-optimal behavior w.r.t. IDT injection here, where the guest
cannot (due to the disparity of hw-injection vs guest-injection overheads).
IOW: The cost of an IDT dispatch in real-hardware adds minimal latency,
even if a low-priority IDT preempts a high-priority interrupt thread.
The cost of an IDT dispatch in a guest, OTOH, especially when you factor
in the complete picture (IPI-exit, inject, eoi exit, re-enter) is
greater...to great, in fact. So if you can get the guests interrupts
priority aware, you can avoid even the IDT preempting the irq-thread
until the system is in the ideal state.
>
>>>>
>>>>
>>> They had to build connectors just like you propose to do.
>>>
>> More importantly, they had to build back-end busses too, no?
>>
>
> They had to write 414 lines in drivers/s390/kvm/kvm_virtio.c and
> something similar for lguest.
Well, then I retract that statement. I think the small amount of code
is probably because they are re-using the qemu device-models, however.
Note that I am essentially advocating the same basic idea here.
>
>>> But you still need vbus-connector-lguest and vbus-connector-s390 because
>>> they all talk to the host differently. So what's changed? the names?
>>>
>> The fact that they don't need to redo most of the in-kernel backend
>> stuff. Just the connector.
>>
>
> So they save 414 lines but have to write a connector which is... how large?
I guess that depends on the features they want. A pci-based connector
would probably be pretty thin, since you don't need event channels like
I use in the pci-bridge connector.
The idea, of course, is that the vbus can become your whole bus if you
want. So you wouldn't need to tunnel, say, vbus over some lguest bus.
You just base the design on vbus outright.
Note that this was kind of what the first pass of vbus did for KVM. The
bus was exposed via cpuid and hypercalls as kind of a system-service.
It wasn't until later that I surfaced it as a bridge model.
>
>>> Well, venet doesn't complement virtio-net, and virtio-pci doesn't
>>> complement vbus-connector.
>>>
>> Agreed, but virtio complements vbus by virtue of virtio-vbus.
>>
>
> I don't see what vbus adds to virtio-net.
Well, as you stated in your last reply, you don't want it. So I guess
that doesn't matter much at this point. I will continue developing
vbus, and pushing things your way. You can opt to accept or reject
those things at your own discretion.
Kind Regards,
-Greg
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]
^ permalink raw reply
* Re: [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model for vbus_driver objects
From: Nicholas A. Bellinger @ 2009-08-19 18:23 UTC (permalink / raw)
To: Avi Kivity
Cc: Ingo Molnar, Anthony Liguori, kvm, alacrityvm-devel, linux-kernel,
netdev, Michael S. Tsirkin, Ira W. Snyder, Joel Becker
In-Reply-To: <4A8BA5AE.3030308@redhat.com>
On Wed, 2009-08-19 at 10:11 +0300, Avi Kivity wrote:
> On 08/19/2009 09:28 AM, Gregory Haskins wrote:
> > Avi Kivity wrote:
<SNIP>
> > Basically, what it comes down to is both vbus and vhost need
> > configuration/management. Vbus does it with sysfs/configfs, and vhost
> > does it with ioctls. I ultimately decided to go with sysfs/configfs
> > because, at least that the time I looked, it seemed like the "blessed"
> > way to do user->kernel interfaces.
> >
>
> I really dislike that trend but that's an unrelated discussion.
>
> >> They need to be connected to the real world somehow. What about
> >> security? can any user create a container and devices and link them to
> >> real interfaces? If not, do you need to run the VM as root?
> >>
> > Today it has to be root as a result of weak mode support in configfs, so
> > you have me there. I am looking for help patching this limitation, though.
> >
> >
>
> Well, do you plan to address this before submission for inclusion?
>
Greetings Avi and Co,
I have been following this thread, and although I cannot say that I am
intimately fimilar with all of the virtualization considerations
involved to really add anything use to that side of the discussion, I
think you guys are doing a good job of explaining the technical issues
for the non virtualization wizards following this thread. :-)
Anyways, I was wondering if you might be interesting in sharing your
concerns wrt to configfs (conigfs maintainer CC'ed), at some point..?
As you may recall, I have been using configfs extensively for the 3.x
generic target core infrastructure and iSCSI fabric modules living in
lio-core-2.6.git/drivers/target/target_core_configfs.c and
lio-core-2.6.git/drivers/lio-core/iscsi_target_config.c, and have found
it to be extraordinarly useful for the purposes of a implementing a
complex kernel level target mode stack that is expected to manage
massive amounts of metadata, allow for real-time configuration, share
data structures (eg: SCSI Target Ports) between other kernel fabric
modules and manage the entire set of fabrics using only intrepetered
userspace code.
Using the 10000 1:1 mapped TCM Virtual HBA+FILEIO LUNs <-> iSCSI Target
Endpoints inside of a KVM Guest (from the results in May posted with
IOMMU aware 10 Gb on modern Nahelem hardware, see
http://linux-iscsi.org/index.php/KVM-LIO-Target), we have been able to
dump the entire running target fabric configfs hierarchy to a single
struct file on a KVM Guest root device using python code on the order of
~30 seconds for those 10000 active iSCSI endpoints. In configfs terms,
this means:
*) 7 configfs groups (directories), ~50 configfs attributes (files) per
Virtual HBA+FILEIO LUN
*) 15 configfs groups (directories), ~60 configfs attributes (files per
iSCSI fabric Endpoint
Which comes out to a total of ~220000 groups and ~1100000 attributes
active configfs objects living in the configfs_dir_cache that are being
dumped inside of the single KVM guest instances, including symlinks
between the fabric modules to establish the SCSI ports containing
complete set of SPC-4 and RFC-3720 features, et al.
Also on the kernel <-> user API interaction compatibility side, I have
found the 3.x configfs enabled code adventagous over the LIO 2.9 code
(that used an ioctl for everything) because it allows us to do backwards
compat for future versions without using any userspace C code, which in
IMHO makes maintaining userspace packages for complex kernel stacks with
massive amounts of metadata + real-time configuration considerations.
No longer having ioctl compatibility issues between LIO versions as the
structures passed via ioctl change, and being able to do backwards
compat with small amounts of interpreted code against configfs layout
changes makes maintaining the kernel <-> user API really have made this
that much easier for me.
Anyways, I though these might be useful to the discussion as it releates
to potental uses of configfs on the KVM Host or other projects that
really make sense, and/or to improve the upstream implementation so that
other users (like myself) can benefit from improvements to configfs.
Many thanks for your most valuable of time,
--nab
^ permalink raw reply
* Kernel forwarding performance test regressions
From: Stephen Hemminger @ 2009-08-19 18:00 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Vyatta regularly runs RFC2544 performance tests as part of
the QA release regression tests. These tests are run using
a Spirent analyzer that sends packets at maximum rate and
measures the number of packets received.
The interesting (worst case) number is the forwarding percentage for
minimum size Ethernet packets. For packets 1K and above all the packets
get through but for smaller sizes the system can't keep up.
The hardware is Dell based
CPU is Intel Dual Core E2220 @ 2.40GHz (or 2.2GHz)
NIC's are internal Broadcom (tg3).
Size 2.6.23 2.6.24 2.6.26 2.6.29 2.6.30
64 14.% 20% 21% 17% 19%
128 22 33 34 28 32
256 37 52 58 49 54
512 67 85 83 85 85
1024 100 100 100 100 100
1280 100 100 100 100 100
1518 100 100 100 100 100
Some other details:
* Hardware change between 2.6.24 -> 2.6.26 numbers
went from 2.2 to 2.4Ghz
* no SMP affinity (or irqbalance) is done,
numbers are significantly better if IRQ's are pinned.
2.6.26 goes from 20% to 32%
* unidirectional numbers are 2X the bidirectional numbers:
2.6.26 goes from 20% to 40%
* this is single stream (doesn't help/use multiqueue)
* system loads iptables but does not use it, so each packet
sees the overhead of null rules.
So kernel 2.6.29 had an observable dip in performance
which seems to be mostly recovered in 2.6.30.
These are from our QA, not me so please don't ask me for
"please rerun with XX enabled", go run the same test
yourself with pktgen.
--
^ permalink raw reply
* Re: Receive side performance issue with multi-10-GigE and NUMA
From: Bill Fink @ 2009-08-19 17:59 UTC (permalink / raw)
To: Andrew Gallatin
Cc: Jesse Barnes, Brandeburg, Jesse, Neil Horman, Brice Goglin,
Linux Network Developers, Yinghai Lu
In-Reply-To: <4A8A9671.8060002@myri.com>
On Tue, 18 Aug 2009, Andrew Gallatin wrote:
> Bill Fink wrote:
>
> > < Latency: 0, Cache Line Size: 64 bytes
>
> <...>
>
> >> Latency: 0, Cache Line Size: 256 bytes
>
>
> A cache line size of 256 clearly seems wrong for a Xeon. I assume all
> devices on the SuperMicro show the same value?
I forgot to check that.
> > Interestingly, the "WC Enabled" is only indicated on the first two
>
> The WC is probably a red herring.
>
> What does ethtool -S show for the DMA write bandwidth of the
> NICs on the SuperMicro?
I've attached the full "ethtool -S" output from both the Asus and
SuperMicro systems. Here's just the bandwidth info:
Asus eth2:
[root@i7test1 ~]# ethtool -S eth2
NIC statistics:
...
read_dma_bw_MBs: 1625
write_dma_bw_MBs: 1599
read_write_dma_bw_MBs: 3192
SuperMicro eth2 (on 5520 connected to NUMA node 1):
[root@xeontest1 ~]# ethtool -S eth2
NIC statistics:
...
read_dma_bw_MBs: 1624
write_dma_bw_MBs: 1605
read_write_dma_bw_MBs: 1323
SuperMicro eth8 (on 5520 connected to NUMA node 0):
[root@xeontest1 ~]# ethtool -S eth8
NIC statistics:
...
read_dma_bw_MBs: 1572
write_dma_bw_MBs: 1605
read_write_dma_bw_MBs: 2113
> These values are obtained serially, as the driver resets
> the NIC (reset happens at load time, and ifconfig up),
> so they could easily sum to more than the memory bandwidth
> of the system. But it would be good to check for any anomalies.
>
> I can send you a pointer to a tool we use internally, which loads
> some custom firmware on the NIC, and can exercise the DMA engines
> on all the NICs in parallel. This would give an idea of the
> aggregate DMA bandwidth available on the system. Let me know
> if you're interested.
Yes, I'd be interested.
-Thanks
-Bill
Full ethtool output:
--------------------------------------------------------------------------------
Asus eth2:
[root@i7test1 ~]# ethtool -S eth2
NIC statistics:
rx_packets: 4
tx_packets: 10
rx_bytes: 240
tx_bytes: 708
rx_errors: 0
tx_errors: 0
rx_dropped: 0
tx_dropped: 0
multicast: 0
collisions: 0
rx_length_errors: 0
rx_over_errors: 0
rx_crc_errors: 0
rx_frame_errors: 0
rx_fifo_errors: 0
rx_missed_errors: 0
tx_aborted_errors: 0
tx_carrier_errors: 0
tx_fifo_errors: 0
tx_heartbeat_errors: 0
tx_window_errors: 0
tx_boundary: 4096
WC: 0
irq: 2282
MSI: 1
MSIX: 0
read_dma_bw_MBs: 1625
write_dma_bw_MBs: 1599
read_write_dma_bw_MBs: 3192
serial_number: 356055
watchdog_resets: 0
link_changes: 6
link_up: 1
dropped_link_overflow: 0
dropped_link_error_or_filtered: 631516
dropped_pause: 631516
dropped_bad_phy: 0
dropped_bad_crc32: 0
dropped_unicast_filtered: 0
dropped_multicast_filtered: 11
dropped_runt: 0
dropped_overrun: 0
dropped_no_small_buffer: 0
dropped_no_big_buffer: 0
----------- slice ---------: 0
tx_pkt_start: 421736
tx_pkt_done: 421736
tx_req: 2866189
tx_done: 2866189
rx_small_cnt: 257731
rx_big_cnt: 3830824
wake_queue: 5698
stop_queue: 5698
tx_linearized: 0
LRO aggregated: 1276950
LRO flushed: 264545
LRO avg aggr: 4
LRO no_desc: 0
SuperMicro eth2 (on 5520 connected to NUMA node 1):
[root@xeontest1 ~]# ethtool -S eth2
NIC statistics:
rx_packets: 0
tx_packets: 10
rx_bytes: 0
tx_bytes: 708
rx_errors: 0
tx_errors: 0
rx_dropped: 0
tx_dropped: 0
multicast: 0
collisions: 0
rx_length_errors: 0
rx_over_errors: 0
rx_crc_errors: 0
rx_frame_errors: 0
rx_fifo_errors: 0
rx_missed_errors: 0
tx_aborted_errors: 0
tx_carrier_errors: 0
tx_fifo_errors: 0
tx_heartbeat_errors: 0
tx_window_errors: 0
tx_boundary: 4096
WC: 0
irq: 112
MSI: 1
MSIX: 0
read_dma_bw_MBs: 1624
write_dma_bw_MBs: 1605
read_write_dma_bw_MBs: 1323
serial_number: 363134
watchdog_resets: 0
dca_capable_firmware: 1
dca_device_present: 0
link_changes: 2
link_up: 1
dropped_link_overflow: 0
dropped_link_error_or_filtered: 200
dropped_pause: 200
dropped_bad_phy: 0
dropped_bad_crc32: 0
dropped_unicast_filtered: 0
dropped_multicast_filtered: 0
dropped_runt: 0
dropped_overrun: 0
dropped_no_small_buffer: 0
dropped_no_big_buffer: 0
----------- slice ---------: 0
tx_pkt_start: 440223
tx_pkt_done: 440223
tx_req: 3412102
tx_done: 3412102
rx_small_cnt: 213976
rx_big_cnt: 3071854
wake_queue: 1846
stop_queue: 1846
tx_linearized: 0
LRO aggregated: 1024029
LRO flushed: 269709
LRO avg aggr: 3
LRO no_desc: 0
SuperMicro eth8 (on 5520 connected to NUMA node 0):
[root@xeontest1 ~]# ethtool -S eth8
NIC statistics:
rx_packets: 11
tx_packets: 16
rx_bytes: 864
tx_bytes: 1228
rx_errors: 0
tx_errors: 0
rx_dropped: 0
tx_dropped: 0
multicast: 0
collisions: 0
rx_length_errors: 0
rx_over_errors: 0
rx_crc_errors: 0
rx_frame_errors: 0
rx_fifo_errors: 0
rx_missed_errors: 0
tx_aborted_errors: 0
tx_carrier_errors: 0
tx_fifo_errors: 0
tx_heartbeat_errors: 0
tx_window_errors: 0
tx_boundary: 4096
WC: 0
irq: 118
MSI: 1
MSIX: 0
read_dma_bw_MBs: 1572
write_dma_bw_MBs: 1605
read_write_dma_bw_MBs: 2113
serial_number: 361233
watchdog_resets: 0
dca_capable_firmware: 1
dca_device_present: 0
link_changes: 4
link_up: 1
dropped_link_overflow: 0
dropped_link_error_or_filtered: 224
dropped_pause: 224
dropped_bad_phy: 0
dropped_bad_crc32: 0
dropped_unicast_filtered: 0
dropped_multicast_filtered: 0
dropped_runt: 0
dropped_overrun: 0
dropped_no_small_buffer: 0
dropped_no_big_buffer: 0
----------- slice ---------: 0
tx_pkt_start: 575354
tx_pkt_done: 575354
tx_req: 3590761
tx_done: 3590761
rx_small_cnt: 227078
rx_big_cnt: 4733499
wake_queue: 2199
stop_queue: 2199
tx_linearized: 0
LRO aggregated: 1578229
LRO flushed: 404901
LRO avg aggr: 3
LRO no_desc: 0
^ permalink raw reply
* Re: [PATCH] ethtool: Add "-f" option to flash a firmware image from the specified file to a device.
From: Ben Hutchings @ 2009-08-19 17:23 UTC (permalink / raw)
To: Ajit Khaparde; +Cc: davem, jgarzik, netdev
In-Reply-To: <20090818112522.GA22134@serverengines.com>
On Tue, 2009-08-18 at 16:55 +0530, Ajit Khaparde wrote:
> This patch adds a new "-f" option to the ethtool utility
> to flash a firmware image specified by a file, to a network device.
> The filename is passed to the network driver which will flash the image
> on the chip using the request_firmware path.
> The region to be flashed - like redboot, phy can be specified as an argument,
> which will be passed to the driver.
> More options for other flash regions can be added in future.
> The default behavior is to flash all the regions on the chip.
>
> Usage:
> ethtool -f <interface name> <filename of firmware image>
>
> ethtool -f <interface name> <filename of firmware image> [ all|redboot|phy ]
>
> Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>
> ---
> ethtool-copy.h | 16 ++++++++++++
> ethtool.c | 71 +++++++++++++++++++++++++++++++++++++++++++++++++++++++-
> 2 files changed, 86 insertions(+), 1 deletions(-)
>
> diff --git a/ethtool-copy.h b/ethtool-copy.h
> index 3ca4e2c..a7d11fb 100644
> --- a/ethtool-copy.h
> +++ b/ethtool-copy.h
> @@ -272,6 +272,21 @@ struct ethtool_perm_addr {
> __u8 data[0];
> };
>
> +#define ETHTOOL_FLASH_MAX_FILENAME 128
> +#define ETHTOOL_FLASH_OP_TYPE_SIZE 32
These are missing from your patch to the in-kernel ethtool.h. What do
they mean? They are inconsistent with the ethtool_flash::data field.
[...]
> @@ -516,6 +525,10 @@ static void parse_cmdline(int argc, char **argp)
> if (phys_id_time < 0)
> show_usage(1);
> break;
> + } else if (mode == MODE_FLASHDEV) {
> + sprintf(flash_file, "%s", argp[i]);
This is missing a length check.
[...]
> @@ -2398,6 +2424,49 @@ static int do_grxclass(int fd, struct ifreq
> *ifr)
> return 0;
> }
>
> +static int do_flash(int fd, struct ifreq *ifr)
> +{
> + struct ethtool_flash efl;
> + int err;
> + char path[ETHTOOL_FLASH_MAX_FILENAME * 2] = "/lib/firmware/";
> + FILE *f;
> +
> + if (flash < 0) {
> + fprintf(stdout, "Missing filename argument\n");
> + show_usage(1);
> + return -EPERM;
This doesn't follow the ethtool convention for error codes, which is to
use unique positive numbers.
> + }
> +
> + strcat(path, flash_file);
> +
> + if (strlen(flash_file) > ETHTOOL_FLASH_MAX_FILENAME) {
> + fprintf(stdout, "Filename too long\n");
> + return -EINVAL;
> + }
> +
> + f = fopen(path, "r");
> + if (!f) {
> + perror(path);
> + return -ENOENT;
> + }
> + fclose(f);
request_firmware() relies on a user-space agent to load firmware;
normally this is udev's firmware_agent which can be configured to look
in directories other than /lib/firmware/. So this check is too strict.
The driver should report back any error from request_firmware(), so it
should not be necessary to check here at all.
> + efl.cmd = ETHTOOL_FLASHDEV;
> + sprintf(efl.data, "%s", flash_file);
[...]
What's wrong with strcpy() anyway?
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox