login
Search
| From | Subject | Date |
|---|---|---|
| Jesse Barnes | Intel Memory Ordering White Paper
FYI, we just released a new white paper describing memory ordering for
Intel processors:
http://developer.intel.com/products/processor/manuals/index.htm
Should help answer some questions about some of the ordering primitives
we use on i386 and x86_64.
Jesse
-
| Sep 7, 6:26 pm 2007 |
| Nick Piggin | Re: Intel Memory Ordering White Paper
As I said, we're not doing anything special in barriers for the ppro errata
AMD processors guarantee loads are ordered and stores are ordered
(with exceptions of non-temporal, and non-wb policy).
As for the others that do out of order stores, are any of them SMP?
-
| Sep 7, 4:49 pm 2007 |
| Nick Piggin | Re: Intel Memory Ordering White Paper
We already noop smp_wmb on i386 even when CONFIG_X86_PPRO_FENCE.
I'm not sure if either errata can be solved completely by adding lock ops
in barrier instructions anyway: they both seem to involve situations where
there is just a single problematic cacheline in question.
-
| Sep 7, 4:46 pm 2007 |
| Linus Torvalds | Re: Intel Memory Ordering White Paper
Did AMD already release their version? If so, we should probably add a
commit that does that in somewhat early 2.6.24 rc, and add the pointers to
the whitepapers in the commit message.
Linus
-
| Sep 7, 7:20 pm 2007 |
| Nick Piggin | Re: Intel Memory Ordering White Paper
Sorry, it looks from the AMD document like nontemporal stores to wb
memory can go out of order. It is a bit hard to decipher what the types
mean.
If this is the case, we can either retain the sfence in smp_wmb(), or noop
it, and put explicit sfences around any place that performs nontemporal
stores...
Anyway, the lfence should be able to go away without so much trouble.
-
| Sep 7, 2:13 pm 2007 |
| Nick Piggin | Re: Intel Memory Ordering White Paper
OK, but we just don't want to be making lots of little exceptions. For
bulk copies, I don't see it being a big issue to always sfence around
-
| Sep 7, 3:57 pm 2007 |
| Nick Piggin | Re: Intel Memory Ordering White Paper
smp_rmb() should not need to do anything because loads are done
in order anyway. Both AMD and Intel have committed to this now.
The important point is that they *appear* to be done in order. AFAIK,
the CPUs can still do speculative and out of order loads, but throw
out the results if they could be wrong.
-
| Sep 7, 4:32 pm 2007 |
| Jim Cromie | (no subject)
auth 2efbb938 subscribe linux-kernel jim.cromie@gmail.com
auth a339d34a subscribe linux-net jim.cromie@gmail.com
-
| Sep 7, 6:19 pm 2007 |
| Goswin von Brederlow | Re: patch: improve generic_file_buffered_write() (2nd try 1/2)
Can you tell me where to get the fix from -mm? If it is completly
Those are extremly costly for lustre. We have tested exporting a
lustre filesystem to NFS. Without fixes we get 40MB/s and with the
Then that means __grab_cache_page does return a locked page because
Actually due to a bug, as you noticed, we do the copy first and then
prepare/write. But fixing that would indeed do multiple copies between
I've got userspace application doing the writev. To be exact 14% of
the commits were sa...
| Sep 7, 5:12 pm 2007 |
| Nick Piggin | Re: patch: improve generic_file_buffered_write() (2nd try 1/2)
OK, but the filesystem client would need to support write_begin/write_end
in order for writes to do multi-seg iovecs. nfsd of course will also be fixed
by the earlier patch I referenced, but you did want userspace multi-seg
OK. Yes ext3 is converted in -mm.
-
| Sep 7, 4:12 pm 2007 |
| Daniel Walker | [PATCH] net: myri10ge: force select inet_lro
This driver uses the inet_lro facilities , but it doesn't force it
to be enabled .. Someone would have to know to enable inet_lro if
they select the driver ..
Instead, just force INET_LRO if this driver is selected..
Signed-off-by: Daniel Walker <dwalker@mvista.com>
---
drivers/net/Kconfig | 1 +
1 file changed, 1 insertion(+)
Index: linux-2.6.22/drivers/net/Kconfig
===================================================================
--- linux-2.6.22.orig/drivers/net/Kconfig
+++...
| Sep 7, 4:26 pm 2007 |
| Alex Riesen | crash while playing bzflag
Kernel: v2.6.23-rc5+ (b21010ed6498391c0f359f2a89c907533fe07fec)
Ubuntu Feisty, Radeon R200 (9200) dual head, MergedFB, BZFlag in
OpenGL mode, frozen. That'll teach me playing games at home...
BUG: unable to handle kernel paging request at virtual address ffa85000
printing eip:
c016eed1
*pde = 00005067
*pte = 00000000
Oops: 0000 [#1]
PREEMPT SMP
Modules linked in: binfmt_misc nfs radeon drm nfsd exportfs lockd sunrpc fan firmware_class it87 hwmon_vid hwmon p4_clockmod speedstep_lib ipv6 sg sr_m...
| Sep 7, 3:56 pm 2007 |
| Michal Piotrowski | Re: crash while playing bzflag
Hi Alex,
Is this a post 2.6.22 regression?
Regards,
Michal
--
LOG
http://www.stardust.webpages.pl/log/
-
| Sep 7, 7:18 pm 2007 |
| Chuck Ebbert | Re: crash while playing bzflag
Whee...
here, in __vfs_follow_link:
if (*link == '/') { <================ link points to unmapped memory
path_release(nd);
if (!walk_init_root(link, nd))
/* weird __emul_prefix() stuff did it */
goto out;
}
inlined from __do_follow_link:
if (!IS_ERR(cookie)) {
char *s = nd_get_link(nd);
error = 0;
if (s)
er...
| Sep 7, 7:14 pm 2007 |
| Bernd Schubert | [PATCH 1/2][RESEND] improve generic_file_buffered_write()
No further response to our patches yet, so we are sending them again,=20
re-diffed against 2.6.23-rc5
Hi,
recently we discovered writing to a nfs-exported lustre filesystem is rathe=
r=20
slow (20-40 MB/s writing, but over 200 MB/s reading).
As I already explained on the nfs mailing list, this happens since there is=
an=20
offset on the very first page due to the nfs header.
http://sourceforge.net/mailarchive/forum.php?thread_name=3D200708312003.304=
46.bernd-schubert%40gmx.de&forum_n...
| Sep 7, 2:52 pm 2007 |
| Christoph Hellwig | Re: [PATCH 1/2][RESEND] improve generic_file_buffered_write()
While the idea is sound in general the code your touching is almost entirely
gone in -mm and hopefully in 2.6.24. Can you take a look at the Nick's changes
in -mm that introduce begin_write and end_write methods replacing prepare_write
and commit_write and see if they improve your situation already. If not they
should at least provide a framework to deal with it in a slightly cleaner way.
-
| Sep 7, 3:38 pm 2007 |
| Randy Dunlap | Re: [PATCH 1/2][RESEND] improve generic_file_buffered_write()
Thanks.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
| Sep 7, 3:15 pm 2007 |
| Sumanth J.V | Spurious completions during NCQ
I keep seeing this message a few times a day on my box.
ata1.00: exception Emask 0x2 SAct 0x18 SErr 0x0 action 0x2 frozen
ata1.00: (spurious completions during NCQ issue=0x0 SAct=0x18
FIS=004040a1:00000004)
ata1.00: cmd 60/08:18:bf:04:df/00:00:23:00:00/40 tag 3 cdb 0x0 data 4096 in
res 40/00:24:c7:04:df/00:00:23:00:00/40 Emask 0x2 (HSM violation)
ata1.00: cmd 60/78:20:c7:04:df/00:00:23:00:00/40 tag 4 cdb 0x0 data 61440 in
res 40/00:24:c7:04:df/00:00:23:00:00/40 Emask 0x2 (HSM vio...
| Sep 7, 1:57 pm 2007 |
| Daniel Walker | Re: [PATCH 0/3] build system: section garbage collection for...
Right, but he contradicted that during the course of this thread.. Which
is why I'm asking about it..
Daniel
-
| Sep 7, 1:19 pm 2007 |
| Stefan Richter | [GIT PULL] FireWire fix
Linus, please pull from the for-linus branch at
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git for-linus
to receive a fix of the laptop-refuses-to-suspend kind. Or simply apply
the patch from this mail.
There is still an old underlying oddness though which I ask the PPC
folks to investigate and possibly fix post 2.6.23: On iBook G3 and
older PowerBooks, the onboard FireWire controller's pci_dev
current_state remains PCI_UNKNOWN long after initialization. Sounds ...
| Sep 7, 1:04 pm 2007 |
| Cliff Wickman | [PATCH 1] mspec: handle shrinking virtual memory areas
The shrinking of a virtual memory area that is mmap(2)'d to a memory
special file (device drivers/char/mspec.c) can cause a panic.
If the mapped size of the vma (vm_area_struct) is very large, mspec allocates
a large vma_data structure with vmalloc(). But such a vma can be shrunk by
an munmap(2). The current driver uses the current size of each vma to
deduce whether its vma_data structure was allocated by kmalloc() or vmalloc().
So if the vma was shrunk it appears to have been allocated by kmallo...
| Sep 7, 12:26 pm 2007 |
| Nikolay Kopitonenko | PATCH to bug #8876
Hi there!
Below is a fix for this:
http://bugzilla.kernel.org/show_bug.cgi?id=8876
Applies to any version since 2.6.22 to latest: 2.6.23-rc5-git1
please apply :)
-------------------------CUT---------------------
diff -urN a/net/ipv4/devinet.c b/net/ipv4/devinet.c
--- a/net/ipv4/devinet.c 2007-07-09 02:32:17.000000000 +0300
+++ b/net/ipv4/devinet.c 2007-08-10 20:33:22.000000000 +0300
@@ -1193,7 +1193,7 @@
for (ifa = in_dev->ifa_list, ip_idx = 0; ifa;
ifa = ifa->ifa_nex...
| Sep 7, 10:46 am 2007 |
| Johannes Berg | [PATCH] list.h: add list_for_each_entry_continue_rcu
To implement the multicast list callback in mac80211 we need to
do partial list iteration. Since I want to convert the interface
list to an RCU list, I need a new list walking primitive:
list_for_each_entry_continue_rcu().
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-kernel@vger.kernel.org
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Pavel Emelianov <xe...
| Sep 7, 10:34 am 2007 |
| Paul E. McKenney | Re: [PATCH] list.h: add list_for_each_entry_continue_rcu
Please add something like the following to this comment:
Note that the caller is responsible for making sure that
the element remains in place between the earlier iterator
and this one. One way to do this is to ensure that
both iterators are covered by the same rcu_read_lock(),
while others involve reference counts, flags, or mutexes.
-
| Sep 7, 11:34 am 2007 |
| Johannes Berg | Re: [PATCH] list.h: add list_for_each_entry_continue_rcu
Sure, will do. Should this comment also be added to
list_for_each_continue_rcu()?
johannes
| Sep 7, 3:09 pm 2007 |
| Paul E. McKenney | Re: [PATCH] list.h: add list_for_each_entry_continue_rcu
Actually, list_for_each_continue_rcu() needs to be removed in favor of
your new list_for_each_entry_continue_rcu(). There are currently only
two users as of 2.6.22. One of them immediately does a list_entry(),
and the other would convert easily as well. So please let me know
when this gets accepted! ;-)
Thanx, Paul
-
| Sep 7, 3:57 pm 2007 |
| Johannes Berg | Re: [PATCH] list.h: add list_for_each_entry_continue_rcu
Heh, ok, I won't add the text to that macro if you want to remove it
anyway. I guess I'll add your paragraph and ... hmm. what do I do with
it? Who's responsible for list.h? Can I push this through John Linville
and Dave Miller so I can get the fix into his tree easily without
synchronisation?
johannes
| Sep 7, 4:04 pm 2007 |
| Daniel Lezcano | [SYSFS - 2.6.23-rc5-git1 ] device_rename: sysfs_create_symli...
Hi,
when using the 2.6.23-rc5-git1 kernel and trying to change a network
device name, I have the following error:
device_rename: sysfs_create_symlink failed (-17)
That comes from drivers/base/core.c : 1261
I know anything about sysfs, so no much help to give... :(
I don't know if this is a bug, but my code use device_rename, check the
return value and fails. I will ignore it, but it seems not to be a
correct behavior to have such error.
Easy to reproduce:
load a dummy network drive...
| Sep 7, 10:14 am 2007 |
| Marco Berizzi | Re: EIP: [<c02d0069>] tcp_rto_min+0x8/0x12 SS:ESP 0068...
http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=...
Thanks everybody.
I was thinking that this fix was included in rc5 (looking at gitweb it
appear
to be)
-
| Sep 7, 10:00 am 2007 |
| Jean Delvare | Platform device id
Hi Greg, all,
While platform_device.id is a u32, platform_device_add() handles "-1" as
a special id value. This has potential for confusion and bugs. One such
bug was reported to me by David Brownell:
http://lists.lm-sensors.org/pipermail/i2c/2007-September/001787.html
And since then I've found two other drivers affected (uartlite and
i2c-pxa).
Could we at least make platform_device.id an int so as to clear up the
confusion? I doubt that the id will ever be a large number anyway.
To go o...
| Sep 7, 9:35 am 2007 |
| Dmitry Torokhov | Re: Platform device id
Hi Jean,
If a device has a <name>.<instance> scheme this implies possibility of
having several instances of said device in a box. There are a few of
platform devices that can only have one instance - for example i8042
keyboard controller (the -1 special handling came from me because
i80420 name was very confusing - there wasn't a dot separator in the
name back then). Drivers that allow multiple devices should not
attempt to use -1 for the very first instance - this should eliminate
p...
| Sep 7, 10:58 am 2007 |
| Henrique de Moraes H... | Re: Platform device id
Agreed. But the breakage might happen anyway, if you need to move
attributes from foo.0 to foo.1. After that first time, userspace will learn
No, it doesn't. It allows for, but it does not imply anything.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
-
| Sep 7, 4:56 pm 2007 |
| David Brownell | Re: Platform device id
Like USB peripheral controllers. Only one external "B" type
For that matter, a *driver* should never create its own device node(s)
in the first place. Device creation belongs elsewhere, like as part of
platform setup or, for busses with integral enumeration support like
PCI or USB, bus glue. Linux is moving away from that legacy model.
I realize that may be more easily said than done in some cases,
like i8042 on non-PNP systems.
- Dave
-
| Sep 7, 12:41 pm 2007 |
| Henrique de Moraes H... | Re: Platform device id
This assumes that we have a better bus than "platform" to dump drivers like
Yes, and there is a LOT of non-PNP stuff involved, since platform became the
dumping ground for host-specific devices (as opposed to platform-specific
devices).
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
-
| Sep 7, 5:00 pm 2007 |
| David Brownell | Re: Platform device id
I don't follow. If it's host-specific, then it's easy enough to
have a host-specific routine creating those platform devices.
A different host wouldn't call that routine.
Embedded Linux platforms do that *ALL* the time. ARM keys on a
board ID provided early in boot (e.g. by U-Boot). PowerPC uses
a device tree, which ISTR evolved from the OpenBoot as first used
on SPARC. Worst comes to worst, the kernel command line can say
which board is involved, and thus which setup code to run.
(Also, n...
| Sep 7, 5:41 pm 2007 |
| Henrique de Moraes H... | Re: Platform device id
We do that in the module that also provides the device driver. E.g. hdaps or
thikpad-acpi will provide both the platform device (and register it), and
In this specific case I am talking about, they're not. ThinkPads are the
host. The platform for a ThinkPad is either i386 or amd64. But there are
many more hosts that are i386 or amd64 than ThinkPads, and the devices in my
example are thinkpad-specific.
I don't feel like drivers like hdaps, thinkpad-acpi, dock, bay, and many
others really belo...
| Sep 7, 6:04 pm 2007 |
| Jean Delvare | Re: Platform device id
Hi Dmitry,
Thanks for your answer.
I agree that in general there is a single i8042 keyboard controller on
a system, but what prevents someone to build a system with several of
these (e.g. in a multi-console computer)?
I agree that "i80420" was a confusing name, but now that a dot was
inserted between the name and the id, it wouldn't be a problem to have
This isn't that easy. For a given kind of device, some systems might
have only one, it might even be strictly impossible to ever have mo...
| Sep 7, 12:36 pm 2007 |
| dlezcano | [GIT - resend][patch 1/1] Fix typos in Kconfig
From: Daniel Lezcano <dlezcano@fr.ibm.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
---
drivers/input/misc/Kconfig | 2 +-
drivers/leds/Kconfig | 2 +-
drivers/telephony/Kconfig | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
Index: 2.6-git/drivers/input/misc/Kconfig
===================================================================
--- 2.6-git.orig/drivers/input/misc/Kconfig
+++ 2.6-git/drivers/input/misc/Kconfig
@@ -152,7 +152,7 @@
co...
| Sep 7, 9:19 am 2007 |
| dlezcano | [GIT - resend][patch 0/1] fix kconfigs for 2.6.23-rc5-git1
Patch resend with right subject, sorry for that.
--
-
| Sep 7, 9:19 am 2007 |
| dlezcano | [GIT][patch 1/1] Fix some Kconfigs on net-2.6.24
From: Daniel Lezcano <dlezcano@fr.ibm.com>
Three fixes for Kconfigs.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
---
drivers/input/misc/Kconfig | 2 +-
drivers/leds/Kconfig | 2 +-
drivers/telephony/Kconfig | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
Index: net-2.6.24/drivers/input/misc/Kconfig
===================================================================
--- net-2.6.24.orig/drivers/input/misc/Kconfig
+++ net-2.6.24/drivers/input/mis...
| Sep 7, 9:01 am 2007 |
| dlezcano | [GIT][patch 0/1] Fix kconfigs typos
Applies to 2.6.23-rc5-git1
--
-
| Sep 7, 9:01 am 2007 |
| Marco Berizzi | EIP: [<c02d0069>] tcp_rto_min+0x8/0x12 SS:ESP 0068:c03bbd6c
Hello.
Linux 2.6.23-rc5 after 30 minutes crash with this
error message (taken from serial console):
BUG: unable to handle kernel NULL pointer dereference at virtual address
00000025
printing eip:
*pde = 00000000
Oops: 0000 [#1]
SMP
Modules linked in: nf_nat_pptp nf_nat_proto_gre nf_conntrack_pptp
nf_conntrack_proto_gre nf_nat_ftp nf_conntrack_ftp e1000 tg3
CPU: 0
EIP: 0060:[<c02d0069>] Not tainted VLI
EFLAGS: 00010202 (2.6.23-rc5 #1)
EIP is at tcp_rto_min+...
| Sep 7, 8:59 am 2007 |
| Guillaume Chazarain | Re: EIP: [<c02d0069>] tcp_rto_min+0x8/0x12 SS:ESP 0068...
Hi, this should be fixed in mainline by
http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=...
Also, network problems should be reported to netdev@vger.kernel.org
Hope this helps.
--
Guillaume
-
| Sep 7, 9:15 am 2007 |
| Alexey Dobriyan | Re: EIP: [<c02d0069>] tcp_rto_min+0x8/0x12 SS:ESP 0068...
get 2.6.23-rc5-git1, fix is in it.
http://kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.23-rc5-git1.bz2
-
| Sep 7, 9:12 am 2007 |
| Folkert van Heusden | sata & scsi suggestion for make menuconfig
Hi,
Maybe it is a nice enhancement for make menuconfig to more explicitly
give a pop-up or so when someone selects for example a sata controller
while no 'scsi-disk' support was selected?
Folkert van Heusden
--
Multi tail barnamaj mowahib li mora9abat attasjilat wa nataij awamir
al 7asoub. damj, talwin, mora9abat attarchi7 wa ila akhirih.
http://www.vanheusden.com/multitail/
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, ww...
| Sep 7, 8:48 am 2007 |
| Randy Dunlap | Re: sata & scsi suggestion for make menuconfig
I know that it's difficult to get people to read docs & help text,
and maybe it is needed in more places, but CONFIG_ATA (SATA/PATA)
help text says:
NOTE: ATA enables basic SCSI support; *however*,
'SCSI disk support', 'SCSI tape support', or
'SCSI CDROM support' may also be needed,
depending on your hardware configuration.
A popup makes some sense, but I don't know if menuconfig knows how to
do popup warnings... and it needs to be done for all *configs,
not just menuconfig.
...
| Sep 7, 11:35 am 2007 |
| Folkert van Heusden | Re: sata & scsi suggestion for make menuconfig
Yes but that would mean that you have to open the help for each item
Maybe add a new type?
Folkert van Heusden
--
MultiTail na wan makriki wrokosani fu tan luku den logfile nanga san
den commando spiti puru. Piki puru spesrutu sani, wroko nanga difreti
kroru, tja kon makandra, nanga wan lo moro.
http://www.vanheusden.com/multitail/
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
-
| Sep 7, 11:59 am 2007 |
| Stefan Richter | Re: sata & scsi suggestion for make menuconfig
How about
comment "Note: 'SCSI disk support' is required for SATA/PATA HDDs!"
depends on ATA && !BLK_DEV_SD
--
Stefan Richter
-=====-=-=== =--= --===
http://arcgraph.de/sr/
-
| Sep 7, 12:21 pm 2007 |
| Folkert van Heusden | Re: sata & scsi suggestion for make menuconfig
Yes! Maybe create some status-line at the bottom of the screen in which
these hints scrollby. Like powertop does.
Folkert van Heusden
--
MultiTail är en flexibel redskap för att fälja logfilar, utför av
commandoer, filtrera, ge färg, sammanfoga, o.s.v. följa.
http://www.vanheusden.com/multitail/
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
-
| Sep 7, 7:05 pm 2007 |
| Jan Engelhardt | Re: sata & scsi suggestion for make menuconfig
Having no sd support is perfectly valid. Imagine a diskless boot
with only sr support.
-
| Sep 7, 10:40 am 2007 |
| previous day | today | next day |
|---|---|---|
| September 6, 2007 | September 7, 2007 | September 8, 2007 |
| hooanon05 | [PATCH 67/67] merge aufs |
| Greg Kroah-Hartman | [PATCH 008/196] Chinese: add translation of volatile-considered-harmful.txt |
| monstr | [PATCH 33/52] [microblaze] bug headers files |
| Oliver Pinter | Re: x86: 4kstacks default |
git: | |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| David Miller | [GIT]: Networking |
| Natalie Protasevich | [BUG] New Kernel Bugs |
