* Re: [OOPS] related to swap?
From: Nick Piggin @ 2006-04-05 9:38 UTC (permalink / raw)
To: pomac; +Cc: Linux-kernel
In-Reply-To: <1144225363.7112.10.camel@localhost>
Ian Kumlien wrote:
>>Ian Kumlien wrote:
>>
>>
>>>Yes, i run a tainted kernel! either live with it or ignore this mail
>>>=)
>>
>>>starting swap lead to a deadlock within 15 mins
>>
>>>I have never had the energy to perform a full memtext86+
>>
>>It would be useful if you could perform a memtest overnight one night,
>>then run a non-patched and non-tained 2.6.16.1 kernel, and try to
>>reproduce the problems.
>
>
> As i said, i really doubt that the memory is at fault here, it has done
> several passes over the memory but not all tests. I can give it a go
> though, but i really doubt it'll find anything.
>
If it doesn't cost you much time (ie. do it overnight) it could save some
developers a lot of time.
> The kernel i run is a plain 2.6.16.1 from kernel.org (i have heard that
> you can actually compile gentoos own these days)
>
OK, good.
> Since this is my *cough* desktop, running it without that ability is
> kinda a show stopper, thats why i included the thing above.
>
But if the problem can be reproduced in 15 minutes, it shouldn't be
too hard to get a trace without nvidia loaded.
> But the thing is, my laptop runs with the same compiler, "same" nvidia
> driver and the "same" kernel ("same" as in 32 bit not 64 bit).
> Eventhough "same" in this case usually means nothing, i doubt that one
> would have a serius bug and the other wouldn't, ie it's most likley a
> bug related to 64 bits or one or more of the drivers involved.
>
> The only errors i get in dmesg atm is:
> KERNEL: assertion (!sk->sk_forward_alloc) failed at net/core/stream.c
> (283)
> KERNEL: assertion (!sk->sk_forward_alloc) failed at net/ipv4/af_inet.c
> (150)
>
> Which is related to TSO, from what i gather, but i can't turn off tso on
> forcedeth... (i suspected this to cause corruption a while back....)
>
If your network hardware or driver is flakey, try compiling a kernel
without that as well before reproducing this swap problem.
Thanks,
Nick
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
^ permalink raw reply
* Re: libata machine check on Alpha
From: Doug Maxey @ 2006-04-06 6:44 UTC (permalink / raw)
To: Albert Lee
Cc: Tejun Heo, Jeff Garzik, albertl, Carlos Pardo,
Jonathan Blake Benson, linux-ide
In-Reply-To: <4434B76F.7020206@tw.ibm.com>
On Thu, 06 Apr 2006 14:38:39 +0800, Albert Lee wrote:
>Tejun Heo wrote:
>> Jeff Garzik wrote:
>>
>>> Albert Lee wrote:
>>>
>>>> Per Jeff's comment, there is a document on t13
>>>> (http://www.t13.org/docs2003/e03131r0.pdf).
>>>> The documents reads:
>>>> "Eg. – Word 50, bit 13: Set to 1 for devices that support DMAIN bit
>>>> in Features Register for Packet Command".
>>>> However, this looks more for the ATAPI device than for the bridge?
>>>> Also it looks not a t13 standard yet?
>>>> Can we use this word 50 to identify 3611/3811?
>>>
>>>
>>>
>>> DMADIR is in my copy of ATA-7...
>>>
>>
>> Here's the relavant part from ATA8 draft. It seems that the bridge is
>> supposed to mangle the IDENTIFY PACKET DEVICE result. It's supposed to
>> nuke all DMA transfer mode information reported from the original device
>> and report supported modes from the view point of the bridge in bits
>> 10:1 (which, BTW, should be all 1's).
>>
>> The question is whether or not bridges implement this properly. I think
>> we can add a printk to word 62 and ask Jonathan to test it.
>>
>
>Ah, thanks for the info. The DMADIR is in my copy ATA-7, too.
>I just checked word 50 and overlooked it. :(
>I should have checked other part of the spec...
>
>Anyway, will try to make a patch based on the ATA-7 spec.
Do we have any devices to test your patch with? Perhaps in Rochester?
++doug
^ permalink raw reply
* Routing directed broadcast
From: Matthew Clark @ 2006-04-06 6:44 UTC (permalink / raw)
To: netfilter
Hi List,
I am wondering if there is any way to route directed broadcast packets
through a linux box using iptables.
So far I have tried (through a friends suggestion) to mark the packet
in the mangle table of the PREROUTING chain, change the packet to be a
packet that will route and then change it back to a broadcast on the
OUTPUT chain.
i.e.
Broadcasting to 10.200.172.255
Packets are coming in to eth0 (10.14.172.250/24)
Packets need to go out eth1 (10.200.172.250/24)
Have tried
iptables -t mangle -A PREROUTING -i eth0 -d 10.200.172.255 -j MARK
--set-mark 0x10
iptables -t nat -A PREROUTING -i eth0 -d 10.200.172.255 -j DNAT
--to-dest 10.200.172.254
iptables -v -t nat -A OUTPUT -d 10.200.172.254 --match mark --mark
0x10 -j DNAT --to-dest 10.200.172.255
But the problem I find is that whilst matching in the mangle table
Chain PREROUTING (policy ACCEPT 246K packets, 35M bytes)
pkts bytes target prot opt in out source destination
79687 19M MARK all -- eth0 * 0.0.0.0/0
10.200.172.255 MARK set 0x10
The packets don't make it to the nat table
Chain PREROUTING (policy ACCEPT 9014 packets, 567K bytes)
pkts bytes target prot opt in out source destination
0 0 DNAT all -- eth0 * 0.0.0.0/0
10.200.172.255 to:10.200.172.254
Why are the packets not making to the nat PREROUTING chain?
Is there a better way of doing this?
Thanks in advance,
Matt.
^ permalink raw reply
* Re: [PATCH] modules_install must not remove existing modules
From: Sam Ravnborg @ 2006-04-06 6:43 UTC (permalink / raw)
To: Andreas Gruenbacher; +Cc: linux-kernel
In-Reply-To: <200604052333.51085.agruen@suse.de>
On Wed, Apr 05, 2006 at 11:33:50PM +0200, Andreas Gruenbacher wrote:
> When installing external modules with `make modules_install', the
> first thing that happens is a rm -rf of the target directory. This
> works only once, and breaks when installing more than one (set of)
> external module(s). Bug introduced in:
> http://www.kernel.org/hg/linux-2.6/?cs=bbb3915836f5
>
> Sam, is this fix okay with you?
Applied.
We should document this somewhere...
Sam
^ permalink raw reply
* -- warning("vs-44", "out of memory?");
From: Roy Lanek @ 2006-04-06 6:41 UTC (permalink / raw)
To: reiserfs-list
There might be something to debug around:
warning("vs-44", "out of memory?");
line 2674 of /.../linux/fs/reiser4/plugin/file/file.c
In fact, I just have seen a long, unterminated series of
reiser4-out-of-memory warnings in my logs when my box
has started to freeze ... till it has frozen completely
several minutes later.
Unfortunately I have lost all the logs (see below) ... I
am sad for the #---- cut out --- thing that I have seen
and can't reproduce; I had to reboot and did not want to
write down by hand the few items that were visible trough
the few overlapped xterms (+ elvis).
Don't worry, it will happen again enough soon: if you say
that it makes sense, I will manage to not be caught by
surprise again, will try to save the logs immediately,
when the system starts to freeze.
OK, here a bit more context:
** kernel (... uname):
2.6.16.1-grsec #3 Wed Apr 5 22:46:36 WIT 006 i586 pentium
i386 GNU/Linux
compiled without debug support for reiser4
vanilla patches reiser4-for-2.6.16-1
+ grsecurity-2.1.9-2.6.16.1-200604041154
** runit-1.4.1 + socklog-2.1.0
** Slackware current, i.e., gcc 3.4.6
** a P166/32 Mb + non SCSI HDs. (It works, I swear, and
well too!)
Cheers,
/Roy Lanek (West Sumatra)
--
######################## tak ada gading yang tak retak
##### . slackware ###### there are no ivory that is not cracked
##### +-----linux ###### [nothing is perfect in this world]
########################
^ permalink raw reply
* Re: Very slow domU network performance - Moved to xen-devel
From: Winston Chang @ 2006-04-06 6:40 UTC (permalink / raw)
To: Matt Ayres; +Cc: soltesz, xen-devel@lists.xensource.com
In-Reply-To: <4433FA2B.8050005@tektonic.net>
On Apr 5, 2006, at 1:11 PM, Matt Ayres wrote:
> 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 can tell you the symptoms I had: whenever a process in dom0 grabs
100% of the CPU, the domU console freezes. After a little while, the
domU console says "BUG: soft lockup detected on CPU#0!" So I believe
that with my default settings, dom0 always gets first priority, and
domU gets the leftovers.
For those that have just seen this (this thread started on xen-
users): I had very poor UDP performance using iperf with domU as the
server and dom0 as the client. I had 99.98% packet loss when running
at 90Mb/s in this case, until I changed the scheduling, as above.
Then packet loss dropped to 0. In the reverse direction there was
never a problem.
For more details, see the original thread here:
http://lists.xensource.com/archives/html/xen-users/2006-04/msg00096.html
It's possible that iperf is partially at fault here. (I used version
1.7.0 since 2.0.2 wouldn't compile on my iBook.) I noticed that it
takes 100% of CPU time when it's used as a UDP client, even when
running at lower speeds -- I saw this at 4Mb/s. I would wager that
it uses a while loop to delay between sending datagrams. Since iperf
always wants all the CPU cycles and because domU has last priority in
my default scheduling config, domU just wouldn't get enough CPU time
to process the incoming datagrams.
A more general note about using iperf:
It seems to me that as long as iperf uses 100% of the CPU, it is not
a good tool for testing dom0-domU or domU-domU network performance.
This sort of timing loop would be fine for network tests using "real"
hosts, but not ones in which CPU resources are shared and network I/O
is CPU-bound, as is the case here.
I would guess that this would not occur on SMP machines (and maybe
hyperthreaded ones also), since iperf's timing loop wouly use up only
one CPU.
The other network issue I had was very slow TCP performance when domU
was the iperf server and an external machine was the iperf client. I
had 2 Mb/s in this case, but about 90Mb/s in the other direction (on
100Mbit ethernet). This problem disappeared when I did the
scheduling change above.
This issue is _not_ explained by the iperf hogging the CPU as I
mentioned above. No user-level process in dom0 should be involved;
dom0 just does some low-level networking. But if the cause of this
TCP problem is that dom0 is taking all the CPU resources, then that
would suggest that somewhere in the xen networking/bridging code, it
is getting 100% CPU time, just to do bridging for the incoming data.
Does this indicate a problem in the networking code?
Again, the TCP slowness does not occur in the reverse direction, when
domU is sending to an external machine. My guess is that, like the
iperf UDP issue above, that this problem would not occur on SMP
machines.
--Winston
> 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: libata machine check on Alpha
From: Albert Lee @ 2006-04-06 6:38 UTC (permalink / raw)
To: Tejun Heo
Cc: Jeff Garzik, albertl, Carlos Pardo, Jonathan Blake Benson,
linux-ide
In-Reply-To: <44347D9E.8080107@gmail.com>
Tejun Heo wrote:
> Jeff Garzik wrote:
>
>> Albert Lee wrote:
>>
>>> Per Jeff's comment, there is a document on t13
>>> (http://www.t13.org/docs2003/e03131r0.pdf).
>>> The documents reads:
>>> "Eg. – Word 50, bit 13: Set to 1 for devices that support DMAIN bit
>>> in Features Register for Packet Command".
>>> However, this looks more for the ATAPI device than for the bridge?
>>> Also it looks not a t13 standard yet?
>>> Can we use this word 50 to identify 3611/3811?
>>
>>
>>
>> DMADIR is in my copy of ATA-7...
>>
>
> Here's the relavant part from ATA8 draft. It seems that the bridge is
> supposed to mangle the IDENTIFY PACKET DEVICE result. It's supposed to
> nuke all DMA transfer mode information reported from the original device
> and report supported modes from the view point of the bridge in bits
> 10:1 (which, BTW, should be all 1's).
>
> The question is whether or not bridges implement this properly. I think
> we can add a printk to word 62 and ask Jonathan to test it.
>
Ah, thanks for the info. The DMADIR is in my copy ATA-7, too.
I just checked word 50 and overlooked it. :(
I should have checked other part of the spec...
Anyway, will try to make a patch based on the ATA-7 spec.
--
Albert
^ permalink raw reply
* deleting partition does not effect superblock?
From: Sumit Narayan @ 2006-04-06 6:37 UTC (permalink / raw)
To: linux-kernel, ext3-users
Hi,
I am using kernel 2.6.15.4.
On my system, I first created a partition with EXT3 and put some data
on it. Later, I deleted the partition, and re-created another
partition with the same starting block number and a higher ending
block number. I intended to format it with another filesystem, but
surprisingly (or maybe just to me), the superblock of the partition
had not changed. I could still mount the new partition as the same old
filesystem. I could see all the files which was present earlier. Doing
'df' showed me the older partition details (size, % used etc.).
Shouldn't the superblock be changed/deleted once the partition is
deleted? I tried a reboot, but the output remained the same.
-- Sumit
^ permalink raw reply
* Fixes to parsecvs
From: Keith Packard @ 2006-04-06 6:36 UTC (permalink / raw)
To: Git Mailing List; +Cc: keithp
[-- Attachment #1: Type: text/plain, Size: 656 bytes --]
note, parsecvs remains available from:
git://git.freedesktop.org/~keithp/parsecvs
I've "fixed" the lexer to permit getc/ungetc in the data parsing
functions. This should resolve the flex -l / -X problems.
Jim Radford send a patch to add '/' as a legal tag character
I added my custom edit-change-log script for people dealing with
X.org-style commit messages.
And, it deals with import branch revisions that aren't supposed to
get merged back to the trunk, creating a custom branch name based on the
branch revision (which must be global across all files).
5e5f4c012aec2db012a08b1c7ed5219ed5100111
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* [lm-sensors] ali1563 problems
From: Jean Delvare @ 2006-04-06 6:35 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <000001c657ef$bd81d2c0$937ba8c0@genesis>
Hi Jo,
> The contents of /proc/ioports:
>
> regawebdev proc # cat ioports
> (...)
> 0295-0296 : pnp 00:07
OK, that's what I suspected then. You have PNP ACPI enabled, and before
2.6.15, the w83627hf driver doesn't work properly with this option
enabled.
Your options are:
1* Upgrade to a 2.6.15+ kernel.
Or:
2* Boot with pnpacpi=off.
Or:
3* Recompile your kernel with CONFIG_PNPACPI disabled.
--
Jean Delvare
^ permalink raw reply
* Re: Hotplug only coldplugs...
From: Matthew Percival @ 2006-04-06 6:33 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1143760894.8931.14.camel@localhost.localdomain>
G'Day,
I have not yet had much luck working out what is wrong with my udev
set-up (*.rules files are not applied), but I have spotted something odd
which may turn on a lightbulb for someone.
When I look in /dev/.udev/ on my desktop, I see it full of directories
--- it seems to be one for every device in /dev/. On the embedded
system, however, /dev/.udev/ only contains one directory, failed/, which
itself only contains class@dspctl@dspctl/. No changes to the *.rules
files in /etc/udev/rules.d/ seems to have any effect on this. I have
also messed around with udev.conf, but it did not seem to change things
here. Whenever I use udevinfo, it complains that there is no record in
the database (which I guess is synonymous with there being no reference
in /dev/.udev/).
Does this suggest anything to anyone, as I do not seem to be getting
anywhere with this.
-- Matthew
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* Re: [PATCH] Fix unneeded rebuilds in drivers/media/video after moving source tree
From: Sam Ravnborg @ 2006-04-06 6:31 UTC (permalink / raw)
To: Carl-Daniel Hailfinger; +Cc: Linux Kernel Mailing List
In-Reply-To: <44345391.4000704@gmx.net>
On Thu, Apr 06, 2006 at 01:32:33AM +0200, Carl-Daniel Hailfinger wrote:
>
> Thanks. Was it intentional to leave the line below in
> drivers/media/video/bt8xx/Makefile?
>
> EXTRA_CFLAGS += -I$(src)/..
>
> I think it could be replaced with
>
> EXTRA_CFLAGS += -Idrivers/media/video
>
> but I'm not a kbuild expert.
That's a functionality equivalent - yes.
Since it was not a bug-fix I left it as is.
One day I will sweep through all of the kernel Makefiles and get rid of
the relative paths. But thats not -rc fodder.
Sam
^ permalink raw reply
* Re: [PATCH] Fix memory barrier docs wrt atomic ops
From: Nick Piggin @ 2006-04-05 9:32 UTC (permalink / raw)
To: David Howells; +Cc: torvalds, akpm, linux-kernel, linux-arch, davem
In-Reply-To: <29800.1144228639@warthog.cambridge.redhat.com>
David Howells wrote:
> ATOMIC OPERATIONS
> -----------------
>
> -Though they are technically interprocessor interaction considerations, atomic
> -operations are noted specially as they do _not_ generally imply memory
> -barriers. The possible offenders include:
> +Whilst they are technically interprocessor interaction considerations, atomic
> +operations are noted specially as some of them imply full memory barriers and
> +some don't, but they're very heavily relied on as a group throughout the
> +kernel.
> +
> +Any atomic_t operation, for instance, that returns a value implies an
> +SMP-conditional general memory barrier (smp_mb()) on each side of the actual
> +operation. These include:
Actually: this only applies to operations which _both_ modify their atomic_t
operand and return a value. Eg. atomic_read() does not have barrier semantics.
>
> - xchg();
> - cmpxchg();
> - test_and_set_bit();
> - test_and_clear_bit();
> - test_and_change_bit();
> atomic_cmpxchg();
> atomic_inc_return();
> atomic_dec_return();
> @@ -1283,20 +1283,30 @@ barriers. The possible offenders includ
> atomic_add_negative();
> atomic_add_unless();
>
> -These may be used for such things as implementing LOCK operations or controlling
> -the lifetime of objects by decreasing their reference counts. In such cases
> -they need preceding memory barriers.
>
> -The following may also be possible offenders as they may be used as UNLOCK
> -operations.
> +The following, however, do _not_ imply memory barrier effects:
> +
> + xchg();
> + cmpxchg();
> + test_and_set_bit();
> + test_and_clear_bit();
> + test_and_change_bit();
> +
> +These may be used for such things as implementing LOCK-class operations. In
> +such cases they need explicit memory barriers.
> +
I believe all the bitops are essentially the same as the atomic semantics.
That is, if they change their operand and return something, they are full
barriers both ways.
atomic_ops.txt says of them:
"These routines, like the atomic_t counter operations returning values,
require explicit memory barrier semantics around their execution."
I think we'd have problems at least with TestSetPageLocked if this were
not the case.
I'm not sure if I like the words imply, explicit, implicit, etc. They're
a bit confusing. provide, semantics may be better?
> +The following are also potential offenders as they may be used as UNLOCK-class
> +operations, amongst other things, but do _not_ imply memory barriers either:
>
> set_bit();
> clear_bit();
> change_bit();
> atomic_set();
>
> +With these the appropriate explicit memory barrier should be used if necessary.
> +
>
In particular, when clearing a bit to signal the end of a critical section,
clear_bit must be preceeded by smp_mb__before_clear_bit();
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
^ permalink raw reply
* Re: libnetfilter_queue conditions required to rewrite packets...
From: David Vogt @ 2006-04-06 6:30 UTC (permalink / raw)
To: Mike Auty; +Cc: netfilter
In-Reply-To: <44348A27.60602@gmail.com>
2006/4/6, Mike Auty <mike.auty@gmail.com>:
> from all the tests I've run, the original packet is continuing on, and
> the new payload seems to be ignored.
Same here, just ported an libipq application (which was working fine)
to libnetfilter_queue and encountered the same problem. I will post to
the list, once I found out anything. Any advice would be highly
appreciated.
David
^ permalink raw reply
* Re: Dual Core CPU on Abit NI8-Board
From: Frank von Daak @ 2006-04-06 6:27 UTC (permalink / raw)
To: linux-smp
In-Reply-To: <200604051405.13901.f.vondaak@kpage.de>
Hi!
I'ld like to sum up, what I've tried to solve my smp(?)-problem:
- I've bootet my vanilla 2.6.17-rc1 kernel with the following options appended
in "lilo.conf":
1. noapic
2. pci=noacpi
3. pci=biosirq
4. pci=routeirq
5. pci=conf1
6. acpi=off
and I've tried to combine most of the options together. (very much reboots as
you can believe :-})
- I've started my x-server with just one geforce card.
- I've disconnected the SLI-bridge from my card and put the board into normal
(not sli)-mode. (In this case the board has one 16xPCIe and one 1XPCIe-Slot.
In the other case it hase two 16XPCIe-slots, and the gra.-cards are sharing
one irq)
- I've removed PREEMPT from the kernel
- I've tried kernel 2.6.16.1 and installed a 64Bit Debian with 2.6.15
- I've removed the usb-module so that the graphics-adapters don't have to
share an irq with usb
- I've upgraded my motherboard-bios to the latest version
- I've tried some different bios-settings (low cpuid for example)
- I've contacted nvidia - they also have not heard about this problem
The result was always the same:
If I start the kernel with ACPI the system is running rock solid, but I have
just one cpu-core.
If I start with disabled ACPI the system is hard-crashing after a short while.
(Sometimes it is crashing without starting an OpenGL-app!)
So I have no more ideas at the moment...
Should I go and buy a new motherboard?
Greetings
Frank
--
Name: Frank von Daak
eMail: f.vondaak@kpage.de Homepage: http://www.kpage.de
"It takes a revolution, to make a solution!
Bob Marley"
^ permalink raw reply
* tcf_generic_walker(): what's going on?
From: Denis Vlasenko @ 2006-04-06 6:11 UTC (permalink / raw)
To: linux-kernel, netdev, kuznet, David S. Miller
While hunting down oversized inlines
I stumbled on tcf_generic_walker().
It is defined in two separate files:
once as an inline in include/net/pkt_act.h
(really big one, ~750 bytes of code)
and once as a static function in net/sched/act_police.c
These two instances are not identical.
Second one has one extra parameter (int type)
and it uses it like this:
for (i = 0; i < MY_TAB_SIZE; i++) {
p = tcf_police_ht[tcf_police_hash(i)];
for (; p; p = p->next) {
index++;
if (index < s_i)
continue;
a->priv = p;
a->order = index;
r = (struct rtattr*) skb->tail;
RTA_PUT(skb, a->order, 0, NULL);
+ if (type == RTM_DELACTION)
+ err = tcf_action_dump_1(skb, a, 0, 1);
+ else
+ err = tcf_action_dump_1(skb, a, 0, 0);
Having two functions with same name is rather confusing.
Worse, they are both are called via five different
tc_action_ops structs:
static struct tc_action_ops act_ipt_ops = {
...
.walk = tcf_generic_walker
and I fail to understand how it is supposed to work,
considering the fact that these two tcf_generic_walker's
have different prototypes.
1) What should I do with tcf_generic_walker?
2) Should I deinline huge inlines in include/net/pkt_act.h?
If yes, to which .c file should I move them?
--
vda
^ permalink raw reply
* [PATCH] use PAGE_OFFSET instead of __PAGE_OFFSET in netfront.c
From: Isaku Yamahata @ 2006-04-06 5:56 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1: Type: text/plain, Size: 180 bytes --]
use PAGE_OFFSET instead of __PAGE_OFFSET in netfront.c.
__PAGE_OFFSET is not defined on all platforms.
Linux/ia64 and Linux/ppc don't have __PAGE_OFFSET definition.
--
yamahata
[-- Attachment #2: use_offset.patch --]
[-- Type: text/plain, Size: 2018 bytes --]
changeset: 9545:c18bdc9985d304a625d54efe8c1729ece3298818
tag: tip
user: yamahata@valinux.co.jp
date: Thu Apr 6 14:43:50 2006 +0900
files: linux-2.6-xen-sparse/drivers/xen/netfront/netfront.c
description:
use PAGE_OFFSET instead of __PAGE_OFFSET in netfront.c.
__PAGE_OFFSET is not defined on all platforms.
Linux/ia64 and Linux/ppc don't have __PAGE_OFFSET definition.
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
diff -r 8f7aad20b4a5ba33762db56bb7e5cb94fe24395e -r c18bdc9985d304a625d54efe8c1729ece3298818 linux-2.6-xen-sparse/drivers/xen/netfront/netfront.c
--- a/linux-2.6-xen-sparse/drivers/xen/netfront/netfront.c Wed Apr 5 19:30:02 2006 +0100
+++ b/linux-2.6-xen-sparse/drivers/xen/netfront/netfront.c Thu Apr 6 14:43:50 2006 +0900
@@ -993,8 +993,8 @@ static void network_connect(struct net_d
* the RX ring because some of our pages are currently flipped out
* so we can't just free the RX skbs.
* NB2. Freelist index entries are always going to be less than
- * __PAGE_OFFSET, whereas pointers to skbs will always be equal or
- * greater than __PAGE_OFFSET: we use this property to distinguish
+ * PAGE_OFFSET, whereas pointers to skbs will always be equal or
+ * greater than PAGE_OFFSET: we use this property to distinguish
* them.
*/
@@ -1005,7 +1005,7 @@ static void network_connect(struct net_d
* interface has been down.
*/
for (requeue_idx = 0, i = 1; i <= NET_TX_RING_SIZE; i++) {
- if ((unsigned long)np->tx_skbs[i] < __PAGE_OFFSET)
+ if ((unsigned long)np->tx_skbs[i] < PAGE_OFFSET)
continue;
skb = np->tx_skbs[i];
@@ -1036,7 +1036,7 @@ static void network_connect(struct net_d
/* Rebuild the RX buffer freelist and the RX ring itself. */
for (requeue_idx = 0, i = 1; i <= NET_RX_RING_SIZE; i++) {
- if ((unsigned long)np->rx_skbs[i] < __PAGE_OFFSET)
+ if ((unsigned long)np->rx_skbs[i] < PAGE_OFFSET)
continue;
gnttab_grant_foreign_transfer_ref(
np->grant_rx_ref[i], np->xbdev->otherend_id,
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: [Xen-changelog] Define Xen interface version for tools build.
From: Muli Ben-Yehuda @ 2006-04-06 5:54 UTC (permalink / raw)
To: Keir Fraser; +Cc: xen-devel
In-Reply-To: <E1FRDpR-0003Lw-7l@xenbits.xensource.com>
On Wed, Apr 05, 2006 at 07:38:08PM +0000, Xen patchbot -unstable wrote:
> # HG changeset patch
> # User kaf24@firebug.cl.cam.ac.uk
> # Node ID d1ddd7d35ed5387467cf4022e4d87b5bbca74553
> # Parent 806d042527619a985d69d57d93e670a4e150eb44
> Define Xen interface version for tools build.
>
> Signed-off-by: Keir Fraser <keir@xensource.com>
>
> diff -r 806d04252761 -r d1ddd7d35ed5 tools/Rules.mk
> --- a/tools/Rules.mk Wed Apr 5 09:37:37 2006
> +++ b/tools/Rules.mk Wed Apr 5 09:41:11 2006
> @@ -11,6 +11,8 @@
> XEN_LIBXENSTAT = $(XEN_ROOT)/tools/xenstat/libxenstat/src
>
> X11_LDPATH = -L/usr/X11R6/$(LIBDIR)
> +
> +CFLAGS += -D__XEN_INTERFACE_VERSION__=0x00030101
This is now another place you have to remember to change the version
string. Can we stick it in its own file with nothing else and have
other users include it?
Cheers,
Muli
--
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/
^ permalink raw reply
* Re: [PATCH] IrDA: Support for Sigmatel STIR421x chip
From: David S. Miller @ 2006-04-06 5:41 UTC (permalink / raw)
To: samuel.ortiz-xNZwKgViW5gAvxtiuMwx3w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
irda-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
jt-sDzT885Ts8HQT0dZR+AlfA
In-Reply-To: <20060405232137.GB377@irie>
From: Samuel Ortiz <samuel.ortiz-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>
Date: Thu, 6 Apr 2006 02:21:37 +0300
> This patch enables support for the Sigmatel's STIR421x IrDA chip.
> Once patched with Sigmatel's firmware, this chip "almost" follows the USB-IrDA spec. Thus this patch is against irda-usb.[ch].
>
> The code has been tested by Nick Fedchik on an STIR4210 chipset based dongle.
>
> Signed-off-by: Samuel Ortiz <samuel.ortiz-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>
Applied, but I had to fix up an enormous amount of trailing
white space on this patch too.
Also, functions such as stir421x_upload_patch() were not properly
indented using tabs, it's using a 4 space indentation.
Lots of other coding style errors such as:
if(cond) {
instead of:
if (cond) {
You may wish to review Documentation/CodingStyle before submitting
future IRDA patches.
Thanks a lot.
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: [PATCH] IrDA: smcinit merged into smsc-ircc driver
From: David S. Miller @ 2006-04-06 5:34 UTC (permalink / raw)
To: samuel.ortiz-xNZwKgViW5gAvxtiuMwx3w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
irda-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
jt-sDzT885Ts8HQT0dZR+AlfA
In-Reply-To: <20060405232125.GA377@irie>
From: Samuel Ortiz <samuel.ortiz-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>
Date: Thu, 6 Apr 2006 02:21:25 +0300
> This patch integrates the smcinit code into the smsc-ircc driver.
> Some laptops have their smsc-ircc chip not properly configured by the BIOS and needs some preconfiguration. Currently, this can be done from userspace with smcinit, a utility that comes with the irda-utils package. It messes with ioports and PCI settings, from userspace.
> Now with this patch, if we happen to be on one of the known to be faulty laptops, we preconfigure the chip from the driver.
>
> Patch from Linus Walleij <triad-HEm3bjczhZmzQB+pC5nmwQ@public.gmane.org>
> Signed-off-by: Samuel Ortiz <samuel.ortiz-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>
Applied.
This patch added a lot of trailing whitespace which I had to
fix up by hand, I did it for you this time but next time I
will not. You can check you patches with this simple command:
git apply --check --whitespace=error-all diff
Thanks.
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: [Patch] Possible double free in net/bluetooth/sco.c
From: David S. Miller @ 2006-04-06 5:28 UTC (permalink / raw)
To: snakebyte; +Cc: linux-kernel, maxk
In-Reply-To: <1144178718.12132.4.camel@alice>
From: Eric Sesterhenn <snakebyte@gmx.de>
Date: Tue, 04 Apr 2006 21:25:18 +0200
> this fixes coverity bug id #1068.
> hci_send_sco() frees skb if (skb->len > hdev->sco_mtu).
> Since it returns a negative error value only in this case, we
> can directly return here.
>
> Signed-off-by: Eric Sesterhenn <snakebyte@gmx.de>
This looks fine, applied.
Thanks.
^ permalink raw reply
* Re: [2.6 patch] drivers/net/tg3.c: fix a memory leak
From: David S. Miller @ 2006-04-06 5:21 UTC (permalink / raw)
To: bunk; +Cc: netdev, linux-kernel
In-Reply-To: <20060404190935.GB6529@stusta.de>
From: Adrian Bunk <bunk@stusta.de>
Date: Tue, 4 Apr 2006 21:09:35 +0200
> This patch fixes a memory leak (buf wasn't freed) spotted by the
> Coverity checker.
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Applied, thanks Adrian.
^ permalink raw reply
* Re: [2.6 patch] net/core/net-sysfs.c: fix an off-by-21-or-49 error
From: David S. Miller @ 2006-04-06 5:19 UTC (permalink / raw)
To: bunk; +Cc: netdev, linux-kernel
In-Reply-To: <20060404190742.GA6529@stusta.de>
From: Adrian Bunk <bunk@stusta.de>
Date: Tue, 4 Apr 2006 21:07:42 +0200
> This patch fixes an off-by-21-or-49 error ;-) spotted by the Coverity
> checker.
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Applied, thanks Adrian.
^ permalink raw reply
* Re: [PATCH] Add prctl to change endian of a task
From: Paul Mackerras @ 2006-04-06 5:13 UTC (permalink / raw)
To: David S. Miller; +Cc: anton, alan, ioe-lkml, linux-kernel, akpm
In-Reply-To: <20060403.154048.133638224.davem@davemloft.net>
David S. Miller writes:
> Doesn't PPC have a PTE bit that does endian swapping? Wouldn't
> that be easier to use for something like qemu?
Some embedded PPC chips do, but most PPCs don't.
Paul.
^ permalink raw reply
* Re: Bonnie++ Burps on XFS
From: Nathan Scott @ 2006-04-06 5:13 UTC (permalink / raw)
To: Kurt Wall; +Cc: LKML, linux-xfs
In-Reply-To: <20060406125756.H1110920@wobbly.melbourne.sgi.com>
On Thu, Apr 06, 2006 at 12:57:56PM +1000, Nathan Scott wrote:
> On Wed, Apr 05, 2006 at 10:34:45PM -0400, Kurt Wall wrote:
> > I've been using bonnie++ off and on for a long time. Suddenly, it has
> > started failing when run against an XFS filesystem situated on a SATA
> > drive. Here's the output of a run:
>
> [ Please report these things to linux-xfs@oss.sgi.com... ]
>
> > Delete files in sequential order...Bonnie: drastic I/O error (rmdir):
>
> Anything in your system log?
Lemme answer that for you - "no". I've reproduced the problem,
I'll get back to you once I've nutted out whats gone wrong.
Thanks for reporting it.
cheers.
--
Nathan
^ 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.