* Re: Here is the tcp-zero-copy patch for kernel 2.6.12-6 .
From: Zach Brown @ 2006-04-05 16:47 UTC (permalink / raw)
To: Jeff Garzik; +Cc: yzy, linux-kernel, eeb, green
In-Reply-To: <4433DCAF.5060503@garzik.org>
> 1) Why, we already have zero-copy?
It's poorly named. The sendpage side is so that Lustre's in-kernel
'tcpnal' can get callbacks when an skb tx is completed. I don't know
what the recvpackets thing is for.
It certainly doesn't look like something that will be merged.
(duplicate code, nutty style, questionable double callback registration,
etc)
- z
^ permalink raw reply
* RE: [PATCH] add support for XCHG instruction accessingAPIC
From: Jiang, Yunhong @ 2006-04-05 16:50 UTC (permalink / raw)
To: Boris Ostrovsky, Keir Fraser; +Cc: xen-devel
I think the reason we don't take any lock here is; we are sure this is just used for local APIC range. However, if in future someone adds another MMIO range or if IOAPIC is accessed with XCHG (will this happen?), this may have potential issue.
So I'd suggest adding comments that we didn't take any lock here, or add a check to make sure the range is on local APIC range.
Thanks
Yunhong Jiang
>-----Original Message-----
>From: xen-devel-bounces@lists.xensource.com
>[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Boris Ostrovsky
>Sent: 2006年4月5日 7:26
>To: Keir Fraser
>Cc: xen-devel@lists.xensource.com
>Subject: Re: [Xen-devel] [PATCH] add support for XCHG instruction accessingAPIC
>
>Keir Fraser wrote:
>
>>>
>>> My only argument in favor of using the lock would be for completeness
>>> of the emulation. You are
>>> absolutely right in that for Linux there seems to be no need to hold
>>> the lock. My concern is that
>>> other OSs may treat this differently. And if we don't have sources,
>>> it may be somewhat difficult
>>> to figure out that the atomicity (or lack of it) was the cause of a
>>> problem.
>>>
>>> If, however, there is a strong feeling that we don't need the lock, I
>>> am happy to drop it.
>>> I guess you are mostly unhappy about adding a new field to
>>> hvm_domain, not about performance
>>> impact?
>>
>>
>> Yes, also my second argument was that there is *no way* for two VCPUs
>> to conflict on a local APIC access, since LAPIC accesses are always to
>> the VCPU's own LAPIC. So there is no potential concurrency that needs
>> to be serialised, regardless of the guest OS.
>
>
>OK, that's fair. Here is updated patch with lock removed.
>
>I don't think I then understand why Linux is using atomic accesses to
>local APICs. It's interesting though that 64-bit code doesn't do it ---
>they use vanilla apic_write().
>
>-boris
^ permalink raw reply
* Re: Building a small sparc32 kernel
From: Bob Breuer @ 2006-04-05 16:51 UTC (permalink / raw)
To: sparclinux
In-Reply-To: <20060404151927.GC2358@cassis>
Ludovic Courtès wrote:
> Hello,
>
> I'm trying to build a 2.6.11 kernel with Bob Breuer's sparc32 SMP
> patch[0] for a bi-processor SS20 (currently running a 2.4 SMP kernel).
2.6.11? You shouldn't need to go back that far. The patch in the
message you referenced was for 2.6.14, and also works for 2.6.15. As
long as you don't enable spinlock debugging, you will never get the lock
errors.
> I'm having a hard time trying to figure out an appropriate build
> configuration such that the resulting kernel image is small enough
> (i.e., avoiding the "uncompressed image too long" message at boot time).
>
> Does anyone have an appropriate `.config' that may be posted?
>
It's nearly a requirement for the kernel to be stripped before silo will
load it. Try using "strip arch/sparc/boot/image -o /boot/vmlinux" to
copy and strip the kernel in one step.
Bob
> [0] http://article.gmane.org/gmane.linux.ports.sparc/5650/
^ permalink raw reply
* help? converting to single global prio_array in scheduler, ran into snag
From: Christopher Friesen @ 2006-04-05 16:54 UTC (permalink / raw)
To: linux-kernel
We're having some issues with the load balancer algorithm in CKRM, so
due to time pressure I'm looking at converting the scheduler to use a
single global prio_array rather than the per-cpu ones that it currently
uses. I realize we're going to take a hit, but we don't have too many
cpus so I'm hoping it won't be too bad.
So far I've removed arrays/expired/active from the runqueue and made
them global, added a new spinlock to protect the global list (always
taken after the runqueue lock), and converted all the callers to use the
appropriate variable. All changes were in sched.h and sched.c.
This builds for both UP and SMP, boots for UP, and boots for SMP if I
set the "nosmp" boot arg.
Unfortunately I seem to have missed something. On my Mac G5 if I allow
it to use both cpus it gets to "smp_core99_setup_cpu 0 done", then hangs.
Anyone have any suggestions as to what I should look at? Maybe the idle
task initialization?
Thanks,
Chris
^ permalink raw reply
* Re: Compiling xenoprof
From: Chris Wright @ 2006-04-05 16:54 UTC (permalink / raw)
To: Santos, Jose Renato G; +Cc: David Carr, xen-devel
In-Reply-To: <6C21311CEE34E049B74CC0EF339464B95849E1@cacexc12.americas.cpqcorp.net>
* Santos, Jose Renato G (joserenato.santos@hp.com) wrote:
> It would be better if there was a "make" option to create the
> xen0/xenU trees without compiling them. Does anybody know if
> there is such an option?
make prep-kernels
> We are now working on getting the xenoprof code included in
> xen-unstable.
> This should make life much easier for those wanting to use oprofile.
Great, thanks. Does the patch to oprofile itself have a chance to get
upstream as well?
thanks,
-chris
^ permalink raw reply
* Re: Dual Core CPU on Abit NI8-Board
From: cerise @ 2006-04-05 16:57 UTC (permalink / raw)
To: linux-smp
In-Reply-To: <200604050913.58378.f.vondaak@kpage.de>
On Wed, Apr 05, 2006 at 09:13:57AM +0200, Frank von Daak wrote:
>
> I've build them myself with smp-support enabled. I've also tried a
> debian-smp-kernel with the same behaviour...
Well, so much for the easy answer 8)
> >> My problem is, that a "cat /proc/cpuinfo" shows me just one cpu with one
> >> core. I've tested this with kernels 2.6.16.1 and 2.6.17-rc1 (x86 and
> >> x86_64)
> >>
> >> If I add the following line in my lilo.conf to the kernel, I can see both
> >> cpu's:
> >> append="pci=noacpi pci=routeirq noapic acpi=off"
Probably the best step to take next is to take another pass through a kernel.
It seems like you have a lot of things built in which aren't necessary to boot
(your network card, for example). I generally recommend putting as much as
possible into modules so that you can boot with the bare minimum of stuff. If
it works that way, you can start slowly adding things and figure out with better
granularity what's causing it to freeze.
You'll use a little more memory that way (modules load in on page boundaries,
so one could in theory be wasting n * ($PAGE_SIZE - 1) bytes in loading n
modules, but the flexibility is very well worth it when figuring out problems
like this.
I have a few prejudices to begin with for your short list of what's causing
the box to die. The first is DRI. The second is one of the NFORCE drivers.
The fact that glxgears seems to trigger the problem and that I dislike DRI in
general sounds like a good place to start ; )
-Phil/CERisE
^ permalink raw reply
* Re: [Lhms-devel] [RFC 0/6] Swapless Page Migration V1: Overview
From: Lee Schermerhorn @ 2006-04-05 16:58 UTC (permalink / raw)
To: Christoph Lameter
Cc: linux-mm, lhms-devel, Hirokazu Takahashi, Marcelo Tosatti,
KAMEZAWA Hiroyuki
In-Reply-To: <Pine.LNX.4.64.0604050925110.1387@schroedinger.engr.sgi.com>
On Wed, 2006-04-05 at 09:28 -0700, Christoph Lameter wrote:
> On Wed, 5 Apr 2006, Lee Schermerhorn wrote:
>
> > Does this approach still allow "migrate-on-fault" for anon pages?
>
> I am not aware of something that would be in the way.
>
> > Especially, in the case where the migrating page has >1 pte referencing
> > it? How will the fault handler find all of the pte's referencing the
> > old page? Actually, I don't think we'd want to burden the task whose
>
> The fault handler can find these via the reverse maps.
>
> > fault caused the migration with finding and replacing and replacing all
> > pte's referecing the old page. Using a real cache, this isn't a problem
> > because we replace the old page with a new one in the cache, and the
> > cache ptes reference the cache entry. Tasks are free to fault in a real
> > pte for the new page at any time. I'd hate to lose this capability. I
> > believe that this is one of the reasons that Marcello used a real idr-
> > based cache for the migration cache.
>
> We never allow a faulting in of the new page before migration is
> complete. The replacing of the swap ptes with real ptes was always done
> after migration was complete. Same thing here.
Unless we're talking about different things [happens], my migrate-on-
fault patches do this. Pages are unmapped from ptes and left hanging in
the cache until some task touches them. Then the migration occurs, if
mapcount+policy so indicate, the new page replaces the old page in the
cache, the fault handler inserts a real pte referencing the new page and
removes one reference from the cache entry. In the case of migration
cache, if this was the last pte reference, the entry is freed. For the
swap cache, the page still references the swap entry and will until
explicitly removed. If other task's ptes reference the cache entry, it
remains available, pointing at the new page, to resolve subsequent page
faults by those tasks.
Series starts with:
http://marc.theaimsgroup.com/?l=linux-mm&m=114200021231527&w=4
I've been reworking these patches against your reorganized migration
code in 2.6.17-rc1. I planned to resubmit after refreshing against 17-
rc1-mm1. Unfortunately, 17-rc1-mm1 doesn't boot on my platform [sans
any of my patches], so now I'm investigating that...
In any case, I don't think we want to be walking reverse maps and other
task's pte's in one task's page fault path. Perhaps "migrate-on-fault"
and "auto-migration" are not going to go anywhere, but if they do, we'll
need something like the existing swap/migration cache behavior, where
the temporary ptes reference a single [reference counted] cache entry
that points at either the old or new page.
Lee
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: Can't mount /dev/md0 after stopping a synchronization
From: Mike Garey @ 2006-04-05 16:59 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <5b170a7d0604050920p674e10a9u9e26a52fcf3933c1@mail.gmail.com>
On 4/5/06, Tuomas Leikola <tuomas.leikola@gmail.com> wrote:
> On 4/5/06, Mike Garey <random51k@gmail.com> wrote:
> > I tried booting from /dev/hdc1 (as /dev/md0 in grub) using a 2.6.15
> > kernel with md and raid1 support built in and this is what I now get:
> >
> > md: autodetecting raid arrays
> > md: autorun ...
> > md: considering hdc1 ...
> > md: adding hdc1 ...
> > md: created md0
> > md: bind:<hdc1>
> > raid1: RAID set md0 active with 1 out of 2 mirrors
> > md: ...autrun done.
> >
> > Warning: unable to open an initial console
> > Input: AT translated set 2 keyboard as /class/input/input0
> >
> > and then at this point, the system just hangs and nothing happens. So
> > I seem to be getting closer.. If I try booting from a kernel without
> > raid1 and md support, but using an initrd with raid1/md modules, then
> > I get the "ALERT! /dev/md0 does not exist. Dropping to a shell!"
> > message. I can't understand why there would be any difference between
> > using a kernel with raid1/md support, or using an initrd image with
> > raid1/md support, but apparently there is. If anyone else has any
> > suggestions, please keep them coming.
>
> Sounds like your initrd could use a command like
>
> mdadm --assemble /dev/md0 /dev/hda1 /dev/hdc1
>
> at some point before mounting the real rootfs. There are many cleaner
> examples in the list archive, but that should do the trick. It seems
> like your initrd-kernel doesn't autostart the raid for some reason
> (config option?).
but wouldn't I need to have /dev/md0 available before doing mdadm
--assemble? When booting from an initrd image, /dev/md0 is never
created for some reason..
> Note, you should never do any read/write access to the component disks
> after creating the raid. I guess you know this already, but some
> wording seemed suspect.
I take it you mean after the disks are synchronized, it's a bad thing
to write directly to /dev/hda1 or /dev/hdc1... In my case, I've
written directly to /dev/hdc1, but it's the only disk in the array,
and I'm going to be resyncing /dev/hda1 anyways, so it seems in this
instance it's okay?
> Can you specify more what is the problem with mounting md0? The log
> snipped doesn't show any errors about that.
after googling a bit more, I seem to have found a solution to my problem:
http://linux.derkeiler.com/Mailing-Lists/Debian/2005-07/2953.html
It seems that when I followed rootraiddoc.97, "Step 4.3 Copy your
Debian system to RAID device.", issuing the command "cp -axu /
/mnt/md0" didn't copy over my /dev directory, which was mounted on a
separate partition (tmpfs on /dev type tmpfs) and since I used the -x
switch to cp, it forced it to stay on the current file system (which I
thought was okay, since I figured /dev was populated dynamically by
udev anyways).
In any case, I simply booted from /dev/hda1, mounted /dev/hdc1, then
copied /dev/console from hda1 to hdc1. After this, I was able to
disconnect hda and boot into /dev/md0 on hdc1. I guess I should've
figured this out when I first ran into the "Warning: unable to open an
initial console" error when booting from a raid1/md enabled kernel,
but at that point I switched to using an initrd image and everything
seemed fine (how wrong I was! :)
So in conclusion, I'm still unable to boot from a kernel with an
initrd image containing the md and raid1 modules (I'm sure this has
something to do with udev not creating /dev/md0 properly), but I can
successfully boot from a raid1/md enabled kernel. So after a very
large diversion, I'm back to my original problem of trying to decrease
the sync time. I've now disconnected the CDROM drive from the
secondary ide channel, and I've replaced the 40 conductor cable with
an 80 conductor cable. Hopefully it won't take me 25 hours to
synchronize the second time around!
Thanks to everyone who offered advice and suggestions, your help was
greatly appreciated (and possibly this thread may help some other poor
soul in the future, should they run into a similar situation).
Mike
^ permalink raw reply
* Re: CONFIG_FRAME_POINTER and module vermagic
From: Joshua Hudson @ 2006-04-05 17:00 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <Pine.LNX.4.61.0604050729210.4636@chaos.analogic.com>
> you refer, points to. The structure member, ebp, contains the
> value of the EBP register when the kernel was called. Since EBP
> was the first register saved in the array, it is likely (didn't check)
> that the location referenced by "regs->ebp + 4" was, in fact, the
> return address. In any event, the value of regs->ebp is simply
> the value in a structure member, not the value of any current
> registers.
Confirmed. This is the standard stack frame, and all debuggers assume this.
^ permalink raw reply
* Re: [OT] Non-GCC compilers used for linux userspace
From: Bryan O'Sullivan @ 2006-04-05 17:01 UTC (permalink / raw)
To: Kyle Moffett
Cc: Jason L Tibbitts III, Eric Piel, Jan Engelhardt, Rob Landley, nix,
mmazur, linux-kernel, llh-discuss
In-Reply-To: <54199D84-7DB7-434E-BA83-9B2658182124@mac.com>
On Tue, 2006-03-28 at 12:13 -0500, Kyle Moffett wrote:
> Mainly I want to know if I should even bother making the kabi headers
> compile with anything other than GCC.
The PathScale compiler is gcc-compatible, so there should be no problems
for us using gcc-isms in those headers.
<b
^ permalink raw reply
* Re: [patch 03/26] sysfs: zero terminate sysfs write buffers (CVE-2006-1055)
From: Al Viro @ 2006-04-05 17:02 UTC (permalink / raw)
To: Jon Smirl; +Cc: gregkh, linux-kernel, stable
In-Reply-To: <9e4733910604050934s46ec20fbr905f78832431d91d@mail.gmail.com>
On Wed, Apr 05, 2006 at 12:34:49PM -0400, Jon Smirl wrote:
> On 4/5/06, Al Viro <viro@ftp.linux.org.uk> wrote:
> > On Wed, Apr 05, 2006 at 07:09:28PM +0400, Sergey Vlasov wrote:
> > > This will break the "color_map" sysfs file for framebuffers -
> > > drivers/video/fbsysfs.c:store_cmap() expects to get exactly 4096 bytes
> > > for a colormap with 256 entries. In fact, the original patch which
> > > changed PAGE_SIZE - 1 to PAGE_SIZE:
> >
> > ... cheerfully assuming that nobody assumes NUL-termination and
> > everyone (sysfs patch writers!) certainly uses the length argument.
> > Fscking brilliant, that.
>
> Why does sysfs have two string length determination methods - both
> NULL termination and a length parameter. It should be one or the
> other, not both. Having both simply cause problems when some
> developers implement one scheme and others only implement the other.
Which part of "sysfs patches can be written by idiots and usually are"
is too hard to understand? Oh, wait. I see... Well, nevermind, then...
^ permalink raw reply
* Re: [parisc-linux] Strange newest LAB msg?
From: Helge Deller @ 2006-04-05 17:02 UTC (permalink / raw)
To: Joel Soete; +Cc: James.Bottomley, parisc-linux
In-Reply-To: <IX9D3V$BF2D86A8A8E037EBE75DD1CCA92265E8@scarlet.be>
On Wednesday 05 April 2006 18:43, Joel Soete wrote:
> > If a user then runs on a big iron like N4k he should use a 64bit kernel
> instead, which then would implement your 64bit-changes proposal.
> >
> Sorry but I misderstood: iirc only 64bit kernel runs on such system like A, L,
> N class; we haven't the choice?
Yes, 64bit kernel, but with additional changes as James proposed.
(the proposal is to implement an iomapping-region (in a very high memory region where you do not have physical memory), in which the ioremapping can happen.)
> PS: btw, I read a lot of your patch related to page size 16k and 64k (for
> pa8000) but not sure we can try it now?
It does not makes sense to test it yet, since it will crash your box.
I'm trying to read and understand the docs.
Not sure when I have it (at least partly) workable....
I'll let you know when you can try.
Helge
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply
* Re: [patch 03/26] sysfs: zero terminate sysfs write buffers (CVE-2006-1055)
From: Al Viro @ 2006-04-05 17:04 UTC (permalink / raw)
To: Jon Smirl; +Cc: gregkh, linux-kernel, stable
In-Reply-To: <9e4733910604050918s72fc16acla569c6f244e01b9e@mail.gmail.com>
On Wed, Apr 05, 2006 at 12:18:07PM -0400, Jon Smirl wrote:
> On 4/5/06, Al Viro <viro@ftp.linux.org.uk> wrote:
> > On Wed, Apr 05, 2006 at 11:43:15AM -0400, Jon Smirl wrote:
> > > > How about _NOT_ using sysfs and just having ->read()/->write() on a file in fs
~~~~~
> > ^^^^^^^^^^^^^^^^^
>
> Where does this file come from? A device node?
>
>
> > > > of your own? ~20 lines for all of it, not counting #include...
~~~~~~~~~~~
Are you really incapable of understanding a simple sentence?
^ permalink raw reply
* Re: [2.6 patch] ISDN_DRV_GIGASET should select, not depend on CRC_CCITT
From: Tilman Schmidt @ 2006-04-05 17:05 UTC (permalink / raw)
To: Adrian Bunk; +Cc: hjlipp, gigaset307x-common, kkeil, isdn4linux, linux-kernel
In-Reply-To: <20060405163202.GF8673@stusta.de>
[-- Attachment #1: Type: text/plain, Size: 904 bytes --]
On 05.04.2006 18:32, Adrian Bunk wrote:
> CRC_CCITT is an internal helper function that should be select'ed.
Good point. Thanks.
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Acked-by: Tilman Schmidt <tilman@imap.cc>
>
> --- linux-2.6.17-rc1-mm1-full/drivers/isdn/gigaset/Kconfig.old 2006-04-05 17:42:54.000000000 +0200
> +++ linux-2.6.17-rc1-mm1-full/drivers/isdn/gigaset/Kconfig 2006-04-05 17:43:07.000000000 +0200
> @@ -3,7 +3,8 @@
>
> config ISDN_DRV_GIGASET
> tristate "Siemens Gigaset support (isdn)"
> - depends on ISDN_I4L && CRC_CCITT
> + depends on ISDN_I4L
> + select CRC_CCITT
> help
> Say m here if you have a Gigaset or Sinus isdn device.
>
>
--
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]
^ permalink raw reply
* RE: Compiling xenoprof
From: Santos, Jose Renato G @ 2006-04-05 17:06 UTC (permalink / raw)
To: Chris Wright; +Cc: David Carr, xen-devel
>> -----Original Message-----
>> From: Chris Wright [mailto:chrisw@sous-sol.org]
>> Sent: Wednesday, April 05, 2006 9:55 AM
>> To: Santos, Jose Renato G
>> Cc: David Carr; xen-devel@lists.xensource.com
>> Subject: Re: [Xen-devel] Compiling xenoprof
>>
>> * Santos, Jose Renato G (joserenato.santos@hp.com) wrote:
>> > It would be better if there was a "make" option to create the
>> > xen0/xenU trees without compiling them. Does anybody know
>> if there is
>> > such an option?
>>
>> make prep-kernels
>>
Great. This will be very usefull. Thanks
>> > We are now working on getting the xenoprof code included in
>> > xen-unstable.
>> > This should make life much easier for those wanting to use
>> oprofile.
>>
>> Great, thanks. Does the patch to oprofile itself have a
>> chance to get upstream as well?
>>
Yes that is the plan. The feedback I received is that
oprofile patches to support Xen are unlikely to be
accepted until Xen makes upstream. The plan then is to wait
for that.
Renato
>> thanks,
>> -chris
>>
^ permalink raw reply
* Re: [patch 03/26] sysfs: zero terminate sysfs write buffers (CVE-2006-1055)
From: Jon Smirl @ 2006-04-05 17:06 UTC (permalink / raw)
To: Al Viro; +Cc: gregkh, linux-kernel, stable
In-Reply-To: <20060405170226.GL27946@ftp.linux.org.uk>
On 4/5/06, Al Viro <viro@ftp.linux.org.uk> wrote:
> On Wed, Apr 05, 2006 at 12:34:49PM -0400, Jon Smirl wrote:
> > On 4/5/06, Al Viro <viro@ftp.linux.org.uk> wrote:
> > > On Wed, Apr 05, 2006 at 07:09:28PM +0400, Sergey Vlasov wrote:
> > > > This will break the "color_map" sysfs file for framebuffers -
> > > > drivers/video/fbsysfs.c:store_cmap() expects to get exactly 4096 bytes
> > > > for a colormap with 256 entries. In fact, the original patch which
> > > > changed PAGE_SIZE - 1 to PAGE_SIZE:
> > >
> > > ... cheerfully assuming that nobody assumes NUL-termination and
> > > everyone (sysfs patch writers!) certainly uses the length argument.
> > > Fscking brilliant, that.
> >
> > Why does sysfs have two string length determination methods - both
> > NULL termination and a length parameter. It should be one or the
> > other, not both. Having both simply cause problems when some
> > developers implement one scheme and others only implement the other.
>
> Which part of "sysfs patches can be written by idiots and usually are"
> is too hard to understand? Oh, wait. I see... Well, nevermind, then...
I look forward to seeing your patches address these problems.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [2.6 patch] net/wanrouter/wanmain.c: cleanups
From: Adrian Bunk @ 2006-04-05 17:06 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
This patch contains the following cleanups:
- make the following needlessly global functions static:
- lock_adapter_irq()
- unlock_adapter_irq()
- #if 0 the following unused global functions:
- wanrouter_encapsulate()
- wanrouter_type_trans()
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
include/linux/wanrouter.h | 8 --------
net/wanrouter/wanmain.c | 17 ++++++++---------
2 files changed, 8 insertions(+), 17 deletions(-)
--- linux-2.6.17-rc1-mm1-full/include/linux/wanrouter.h.old 2006-04-05 17:03:07.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/include/linux/wanrouter.h 2006-04-05 17:15:20.000000000 +0200
@@ -516,9 +516,6 @@
/* Public functions available for device drivers */
extern int register_wan_device(struct wan_device *wandev);
extern int unregister_wan_device(char *name);
-__be16 wanrouter_type_trans(struct sk_buff *skb, struct net_device *dev);
-int wanrouter_encapsulate(struct sk_buff *skb, struct net_device *dev,
- unsigned short type);
/* Proc interface functions. These must not be called by the drivers! */
extern int wanrouter_proc_init(void);
@@ -527,11 +524,6 @@
extern int wanrouter_proc_delete(struct wan_device *wandev);
extern int wanrouter_ioctl( struct inode *inode, struct file *file, unsigned int cmd, unsigned long arg);
-extern void lock_adapter_irq(spinlock_t *lock, unsigned long *smp_flags);
-extern void unlock_adapter_irq(spinlock_t *lock, unsigned long *smp_flags);
-
-
-
/* Public Data */
/* list of registered devices */
extern struct wan_device *wanrouter_router_devlist;
--- linux-2.6.17-rc1-mm1-full/net/wanrouter/wanmain.c.old 2006-04-05 17:03:39.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/net/wanrouter/wanmain.c 2006-04-05 17:18:32.000000000 +0200
@@ -144,8 +144,8 @@
static struct wan_device *wanrouter_find_device(char *name);
static int wanrouter_delete_interface(struct wan_device *wandev, char *name);
-void lock_adapter_irq(spinlock_t *lock, unsigned long *smp_flags);
-void unlock_adapter_irq(spinlock_t *lock, unsigned long *smp_flags);
+static void lock_adapter_irq(spinlock_t *lock, unsigned long *smp_flags);
+static void unlock_adapter_irq(spinlock_t *lock, unsigned long *smp_flags);
@@ -162,8 +162,8 @@
* Organize Unique Identifiers for encapsulation/decapsulation
*/
-static unsigned char wanrouter_oui_ether[] = { 0x00, 0x00, 0x00 };
#if 0
+static unsigned char wanrouter_oui_ether[] = { 0x00, 0x00, 0x00 };
static unsigned char wanrouter_oui_802_2[] = { 0x00, 0x80, 0xC2 };
#endif
@@ -304,6 +304,8 @@
return 0;
}
+#if 0
+
/*
* Encapsulate packet.
*
@@ -399,6 +401,7 @@
return ethertype;
}
+#endif /* 0 */
/*
* WAN device IOCTL.
@@ -860,23 +863,19 @@
return 0;
}
-void lock_adapter_irq(spinlock_t *lock, unsigned long *smp_flags)
+static void lock_adapter_irq(spinlock_t *lock, unsigned long *smp_flags)
{
spin_lock_irqsave(lock, *smp_flags);
}
-void unlock_adapter_irq(spinlock_t *lock, unsigned long *smp_flags)
+static void unlock_adapter_irq(spinlock_t *lock, unsigned long *smp_flags)
{
spin_unlock_irqrestore(lock, *smp_flags);
}
EXPORT_SYMBOL(register_wan_device);
EXPORT_SYMBOL(unregister_wan_device);
-EXPORT_SYMBOL(wanrouter_encapsulate);
-EXPORT_SYMBOL(wanrouter_type_trans);
-EXPORT_SYMBOL(lock_adapter_irq);
-EXPORT_SYMBOL(unlock_adapter_irq);
MODULE_LICENSE("GPL");
^ permalink raw reply
* Re: [PATCH] kexec: typo in machine_kexec()
From: Randy.Dunlap @ 2006-04-05 17:09 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: kernel, linux-kernel, horms, fastboot
In-Reply-To: <m13bgs3tuz.fsf@ebiederm.dsl.xmission.com>
On Wed, 05 Apr 2006 09:49:40 -0600 Eric W. Biederman wrote:
one typo (below):
> How does this look for making that comment readable?
>
> Eric
>
>
> diff --git a/arch/i386/kernel/machine_kexec.c b/arch/i386/kernel/machine_kexec.c
> index f73d737..7a344b6 100644
> --- a/arch/i386/kernel/machine_kexec.c
> +++ b/arch/i386/kernel/machine_kexec.c
> @@ -189,14 +189,11 @@ NORET_TYPE void machine_kexec(struct kim
> memcpy((void *)reboot_code_buffer, relocate_new_kernel,
> relocate_new_kernel_size);
>
> - /* The segment registers are funny things, they are
> - * automatically loaded from a table, in memory wherever you
> - * set them to a specific selector, but this table is never
> - * accessed again you set the segment to a different selector.
> - *
> - * The more common model is are caches where the behide
> - * the scenes work is done, but is also dropped at arbitrary
> - * times.
> + /* The segment registers are funny things, they have both a
> + * visible and an invisible part. Whenver the visible part is
* Whenever
> + * set to a specific selector, the invisible part is loaded
> + * with from a table in memory. At no other time is the
> + * descriptor table in memory accessed.
> *
> * I take advantage of this here by force loading the
> * segments, before I zap the gdt with an invalid value.
Much better, thanks.
---
~Randy
^ permalink raw reply
* Re: [PATCH 00/15] powerpc: move some header files
From: Stephen Rothwell @ 2006-04-05 17:07 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, paulus
In-Reply-To: <C1CE62AD-7989-4DCA-B7B3-8A107ACBD153@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 824 bytes --]
On Wed, 5 Apr 2006 11:15:04 -0500 Kumar Gala <galak@kernel.crashing.org> wrote:
>
> I'm guessing you had to pull some of them in because of the following:
>
> io.h:#include <asm-ppc/io.h>
> mmu_context.h:#include <asm-ppc/mmu_context.h>
> mmu.h:#include <asm-ppc/mmu.h>
> pci-bridge.h:#include <asm-ppc/pci-bridge.h>
> pgalloc.h:#include <asm-ppc/pgalloc.h>
> pgtable.h:#include <asm-ppc/pgtable.h>
>
> I think addressing these will make life easier with the other includes.
I'll have a look at these in the morning, thanks for the hint.
I am thinking of creating an include/asm-powerpc/<xx>_32.h for each of the asm-ppc
files above and then only putting into them what we need for arch/powerpc.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [RFC] Auto rebind PCI devices
From: Muli Ben-Yehuda @ 2006-04-05 17:07 UTC (permalink / raw)
To: Mark Williamson; +Cc: xen-devel, hap9
In-Reply-To: <200604051618.16626.mark.williamson@cl.cam.ac.uk>
On Wed, Apr 05, 2006 at 04:18:16PM +0100, Mark Williamson wrote:
> To clarify my thinking on this a little more: I think it would be good to be
> able to move PCI devices between domains in a reasonably straightforward way.
> This would be something like the PCI hotplug for IBM's dynamic LPAR, which is
> already supported by Linux.
>
> The eventual goal being that you can reassign PCI devices "hotplug-style" (it
> would look like a hotplug to the pcifront kernel) at runtime, with the user
> interface providing appropriate safety checks / "do you really want this?"
> dialogs, according to the level of confidence of the user.
Thank for the clarification; sounds good to me!
Cheers,
Muli
--
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/
^ permalink raw reply
* Re: Compiling xenoprof
From: David Carr @ 2006-04-05 17:09 UTC (permalink / raw)
To: Santos, Jose Renato G, xen-devel
In-Reply-To: <6C21311CEE34E049B74CC0EF339464B95849F0@cacexc12.americas.cpqcorp.net>
Renato,
I should have been more specific. The sequence of commands from the
guide that I use is below:
On dom0:
[start guests]
opcontrol --reset
opcontrol --no-vmlinux
xm list
Name ID Mem(MiB) VCPUs State Time(s)
Domain-0 0 256 1 r----- 242.4
guest_0 11 128 1 -b---- 11.7
guest_1 12 128 1 -b---- 11.8
sudo opcontrol --start-daemon --active-domains=guest_0,guest_1
On each guest:
opcontrol --reset
opcontrol --no-vmlinux
opcontrol --start
Using default event: GLOBAL_POWER_EVENTS:100000:1:1:1
Failed to open profile device: Operation not permitted
Using 2.6+ OProfile kernel interface.
Couldn't start oprofiled.
Check the log file "/var/lib/oprofile/oprofiled.log" and kernel syslog
The above error always occurs when I issue the start command on the
guests...
Thanks,
David Carr
Santos, Jose Renato G wrote:
>David,
>
>You are not able to run oprofile on domU only.
>The current model supported for XenOProfile is system-wide
>profiling, i.e. profiling multiple domains, using the same
>hardware counters. In this model
>Dom0 has to be the coordinator of a profiling session.
>You have to first start oprofile daemon in dom0 indicating which
>domains are participating in the profiling session. Then you
>need to run "opcontrol --start" in each domU, and finally
>start profiling from dom0 (opcontrol --start).
>Look at the user guide in http://xenoprof.sourceforge.net
>for more details
>
>Renato
>
>
>
>>>-----Original Message-----
>>>From: David Carr [mailto:dc@dcarr.org]
>>>Sent: Wednesday, April 05, 2006 9:20 AM
>>>To: Santos, Jose Renato G
>>>Cc: xen-devel@lists.xensource.com
>>>Subject: Re: [Xen-devel] Compiling xenoprof
>>>
>>>Renato,
>>>
>>>Thanks for your reply. The steps below got the kernels to
>>>build. I'm not sure that everything is quite right yet
>>>though. I can profile on domain 0 and also run opcontrol
>>>--reset on the guests. However running "opcontrol --start"
>>>on the guests results in:
>>>
>>>Using default event: GLOBAL_POWER_EVENTS:100000:1:1:1 Failed
>>>to open profile device: Operation not permitted Using 2.6+
>>>OProfile kernel interface.
>>>
>>>Couldn't start oprofiled.
>>>Check the log file "/var/lib/oprofile/oprofiled.log" and
>>>kernel syslog
>>>
>>>It appears that this error is coming daemon/liblegacy/init.c
>>>or daemon/init.c This error only occurs on the guests (which
>>>are using the dom0 kernel).
>>>opcontrol --start suceeds on dom0.
>>>
>>>Any ideas?
>>>
>>>Thanks again,
>>>David Carr
>>>
>>>Install steps:
>>>
>>>In Xen 3.0.0 source directory:
>>>
>>>patch -p1 < xenoprof-2.0-xen-3.0.0.patch patch -p1 <
>>>xenoprof-2.0-linux-2.6-sparse.patch
>>>make kernels
>>>
>>>This will ultimately fail. Then do:
>>>
>>>In linux-2.6.12-xen0 directory:
>>>
>>>patch -p2 < xenoprof-2.0-linux-2.6.12.patch make kernels
>>>
>>>This will ultimately fail. Then do:
>>>
>>>In linux-2.6.12-xenU directory:
>>>
>>>patch -p2 < xenoprof-2.0-linux-2.6.12.patch make kernels
>>>
>>>This will succeed. Then do:
>>>
>>>make dist
>>>sudo make install
>>>
>>>
>>>In oprofile source directory:
>>>
>>>patch -p1 < oprofile-0.9.1-xen.patch
>>>
>>>
>>>Install oprofile normally
>>>
>>>
>>>Santos, Jose Renato G wrote:
>>>
>>>
>>>
>>>>David,
>>>>
>>>>You are right. This is not very clean.
>>>>Yes, you need to do a "make" to create the xen0 and xenU
>>>>
>>>>
>>>trees before
>>>
>>>
>>>>applying the patch in step c).
>>>>If you configure the kernel with oprofile support (CONFIG_OPROFILE)
>>>>before step c) you will probably get a compilation error
>>>>
>>>>
>>>when you run
>>>
>>>
>>>>make since the patch was not applied yet. You could either delay
>>>>setting (CONFIG_OPROFILE) for after you apply patch "c" or you can
>>>>apply the patch after you get the compilation error, and
>>>>
>>>>
>>>then run make
>>>
>>>
>>>>again.
>>>>
>>>>It would be better if there was a "make" option to create
>>>>
>>>>
>>>the xen0/xenU
>>>
>>>
>>>>trees without compiling them. Does anybody know if there is such an
>>>>option? I remember looking for it in the Makefile and not
>>>>
>>>>
>>>finding it,
>>>
>>>
>>>>but this was a while ago.
>>>>
>>>>We are now working on getting the xenoprof code included in
>>>>xen-unstable.
>>>>This should make life much easier for those wanting to use oprofile.
>>>>
>>>>Renato
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>>-----Original Message-----
>>>>>>From: xen-devel-bounces@lists.xensource.com
>>>>>>[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of David
>>>>>>Carr
>>>>>>Sent: Tuesday, April 04, 2006 7:31 PM
>>>>>>To: xen-devel@lists.xensource.com
>>>>>>Subject: [Xen-devel] Compiling xenoprof
>>>>>>
>>>>>>I'm having some trouble compiling Xen 3.0.0 with the xenoprof
>>>>>>patches.
>>>>>>
>>>>>>The xenoprof instructions say:
>>>>>>
>>>>>> In order to run OProfile in Xen environments four patches are
>>>>>>needed:
>>>>>> a) xenoprof-2.0-xen-3.0.0.patch
>>>>>> Patch for Xen hypervisor.
>>>>>> b) xenoprof-2.0-linux-2.6-sparse.patch
>>>>>> Patch for Xenolinux. Contains oprofile architecture specific
>>>>>>driver
>>>>>> for xen (Apply to linux-sparse tree in Xen source tree)
>>>>>> c) xenoprof-2.0-linux-2.6.12.patch
>>>>>> Patch for oprofile kernel module in linux 2.6.12.
>>>>>>Contain modifications
>>>>>> to generic oprofile driver code to support xen.
>>>>>>
>>>>>>
>>>(Apply twice,
>>>
>>>
>>>>>>once to
>>>>>> dom0 and once to domU trees)
>>>>>>
>>>>>>
>>>>>>Every thing goes fine until part c. The linux-2.6.12-xen0 and
>>>>>>linux-2.6.12-xenU directories are empty until you build xen (and
>>>>>>therefore can't be patched yet.) Doing a make world will
>>>>>>
>>>>>>
>>>populate
>>>
>>>
>>>>>>these trees but also compiles everything.
>>>>>>
>>>>>>What is the proper sequence of patching and make commands
>>>>>>
>>>>>>
>>>to build a
>>>
>>>
>>>>>>xenoprof tree?
>>>>>>
>>>>>>Thanks,
>>>>>>David Carr
>>>>>>
>>>>>>
>>>>>>
>>>>>>_______________________________________________
>>>>>>Xen-devel mailing list
>>>>>>Xen-devel@lists.xensource.com
>>>>>>http://lists.xensource.com/xen-devel
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>
>>>
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xensource.com
>http://lists.xensource.com/xen-devel
>
>
^ permalink raw reply
* Re: H.323 conntrack/NAT helper update for 2.6.17-rc1
From: Patrick McHardy @ 2006-04-05 17:10 UTC (permalink / raw)
To: Jing Min Zhao; +Cc: netfilter-devel
In-Reply-To: <BAY109-DAV15AA944ABA789908271E35B3CB0@phx.gbl>
Jing Min Zhao wrote:
> Hi, Patrick,
>
> This patch is to update 2.6.17-rc1 to the latest state. It includes
> following changes that are not in 2.6.17-rc1:
>
> 1. Add new parameter 'default_rrq_ttl'.
> 2. Change get_h245_addr to static
> 3. Change to use EXPORT_SYMBOL_GPL
> 4. Move some extern function prototypes from ip_nat_helper_h323.c to
> ip_conntrack_h323.h.
> 5. Move ip_conntrack_helper_h323_asn1.h and
> ip_conntrack_helper_h323_types.h from net/ipv4/netfilter/ to
> include/linux/netfilter_ipv4/.
>
> Please have a look at it and apply it.
Applied, thanks. A couple of comments though:
- I've split your patches into the logical changes, this is prefered
to "version-updates". Ideally you just send one patch per change.
- whitespace changes:
- /* ip_nat_mangle_udp_packet uses skb_make_writable() to copy
- * or pull everything in a linear buffer, so we can safely
+ /* ip_nat_mangle_udp_packet uses skb_make_writable() to
copy
+ * or pull everything in a linear buffer, so we can safely
Please try to avoid such things, except for seperated patches that
_remove_ whitespace :)
- I've changed default_rrq_timeout to unsigned because it is assigned
to an unsigned member.
- Changelogs in the source-code: its your choice, but I personally
prefer to avoid changelogs in the source files, they tend to
grow pretty fast and you are mostly not interested in them. If
you are, you can use the git history.
Thanks again.
^ permalink raw reply
* Re: [PATCH] [IPSEC] Avoid null pointer dereference in xfrm4_rcv_encap
From: Herbert Xu @ 2006-04-05 17:10 UTC (permalink / raw)
To: Dave Kleikamp; +Cc: David S. Miller, netdev, linux-kernel
In-Reply-To: <1144249178.10340.5.camel@kleikamp.austin.ibm.com>
On Wed, Apr 05, 2006 at 09:59:38AM -0500, Dave Kleikamp wrote:
> I'm getting a panic that I've traced back to this changeset:
> http://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e695633e21ffb6a443a8c2f8b3f095c7f1a48eb0
>
> xfrm4_rcv_encap dereferences x->encap without testing it for null.
The fix for this bug has just been merged. Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Very slow domU network performance - Moved to xen-devel
From: Matt Ayres @ 2006-04-05 17:11 UTC (permalink / raw)
To: Winston Chang; +Cc: soltesz, xen-devel@lists.xensource.com
In-Reply-To: <BA0FFF2C-49C1-48A7-B0DE-4C8B6DFB5B74@stdout.org>
Winston Chang wrote:
>>> I ran the test with the latest xen-unstable build. The results are
>>> the same.
>>> When I ran 'xm sched-sedf 0 0 0 0 1 1' to prevent domU CPU
>>> starvation, network performance was good. The numbers in this case
>>> are the same as in my other message where I detail the results using
>>> the week-old xen build -- it could handle 90Mb/s with no datagram
>>> loss. So it looks like the checksum patches had no effect on this
>>> phenomenon; the only thing that mattered was the scheduling.
>>
>> What was the previous weight of domain 0? What is the weight assigned
>> to the domU's and do the domU's have bursting enabled?
>
> I'm not really sure the answer to either of these questions. The weight
> is whatever is the default is with Fedora Core 5 and xen-unstable. I
> don't know anything about bursting. How do you find out?
>
I'd like to be corrected if I am wrong, but the last number (weight) is
set to 0 for all domains by default. By giving it a value of 1 you are
giving dom0 more CPU. The second to last number is a boolean that
decides whether a domain is hard locked to it's weight or if can burst
using idle CPU cycles. The 3 before that are generally set to 0 and the
first number is the domain name. I do not know of a way to grab the
weights personally. It is documented in the Xen distribution tgz.
I ran my own tests. I have dom0 with a weight of 512 (double it's memory
allocation) and each VM also has a weight equal to it's memory
allocation. My dom0 can transfer at 10MB/s+ over the LAN, but domU's
with 100% CPU used on the host could only transfer over the LAN at a
peak of 800KB/s. When I gave dom0 a weight of 1 domU transfers
decreased to a peak of 100KB/s over the "LAN" (quoted because due to
proxy ARP the host acts as a router)
The problem does not matter if you use bridged or routed mode.
I would have to believe the problem is in the hypervisor itself and
scheduling and CPU usage greatly affect it. Network bandwidth should
not be affected unless wanted (ie. by using the rate vif parameter).
Stephen Soltesz has experienced the same problem and has some graphs to
back it up. Stephen, will you share at least that one CPU + IPerf graph
with the community and perhaps elaborate on your weight configuration
(if any).
Thank you,
Matt Ayres
^ permalink raw reply
* Re: [2.6 patch] drivers/char/random.c: unexport secure_ipv6_port_ephemeral
From: Stephen Hemminger @ 2006-04-05 17:11 UTC (permalink / raw)
To: Adrian Bunk; +Cc: mpm, linux-kernel, netdev
In-Reply-To: <20060405163610.GG8673@stusta.de>
On Wed, 5 Apr 2006 18:36:10 +0200
Adrian Bunk <bunk@stusta.de> wrote:
> This patch removes the unused EXPORT_SYMBOL(secure_ipv6_port_ephemeral).
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
>
> --- linux-2.6.17-rc1-mm1-full/drivers/char/random.c.old 2006-04-05 17:00:04.000000000 +0200
> +++ linux-2.6.17-rc1-mm1-full/drivers/char/random.c 2006-04-05 17:00:22.000000000 +0200
> @@ -1584,7 +1584,6 @@
>
> return twothirdsMD4Transform(daddr, hash);
> }
> -EXPORT_SYMBOL(secure_ipv6_port_ephemeral);
> #endif
>
> #if defined(CONFIG_IP_DCCP) || defined(CONFIG_IP_DCCP_MODULE)
>
> -
> 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
NAK
If IPV6 is built as a module, then it is needed.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.