| From | Subject | Date |
|---|---|---|
| Yinghai Lu | [PATCH] x86_64: restore mask_bits in msi shutdown
I can not kexec RHEL 5.1 from 2.6.25-rc3 later
caused by:
commit 89d694b9dbe769ca1004e01db0ca43964806a611
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Mon Feb 18 18:25:17 2008 +0100
genirq: do not leave interupts enabled on free_irq
The default_disable() function was changed in commit:
76d2160147f43f982dfe881404cfde9fd0a9da21
genirq: do not mask interrupts by default
It removed the mask function in favour of the default delayed
interrupt disabling. ...
| Apr 11, 4:26 pm 2008 |
| mark gross | [RFC] Patch to add private notification data to block no ...
We where trying to get pm-qos to work with a wireless driver and found
that the idiom of passing the *dev in the callback (notification)
parameters was not supported.
This makes having drivers as clients of PM-QOS sort of a challenge. The
driver writer would have to mimic code in md.c where it keeps a list of
all its instances and iterates over each upon notifier callback. Not
that difficult but as the driver writers are so accustomed to having
there instance data passed to them by the ...
| Apr 11, 4:05 pm 2008 |
| Yinghai Lu | [PATCH] x86_64: don't need set default res if only have ...
only one root bus, don't need to split that root resources.
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
diff --git a/arch/x86/pci/k8-bus_64.c b/arch/x86/pci/k8-bus_64.c
index 7ed7f51..c433982 100644
--- a/arch/x86/pci/k8-bus_64.c
+++ b/arch/x86/pci/k8-bus_64.c
@@ -69,7 +69,8 @@ void set_pci_bus_resources_arch_default(struct pci_bus *b)
int j;
struct pci_root_info *info;
- if (!pci_root_num)
+ /* if only one root bus, don't need to anything */
+ if (pci_root_num < 2)
...
| Apr 11, 3:14 pm 2008 |
| Rafael J. Wysocki | Re: [PATCH] x86_64: don't need set default res if only h ...
This patch fixes the issue described at
Thanks,
Rafael
--
| Apr 11, 3:54 pm 2008 |
| Miguel Ojeda | 2.6.25-rc9: hda: task_no_data_intr: error=0x04
Hi!
I'm getting the following messages at the very end of dmesg after
booting in a new laptop (Dell Vostro 1500, bought about four months
ago) in (all?) -rc releases:
hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
hda: task_no_data_intr: error=0x04 { AbortedCommand }
ide: failed opcode was: 0xef
The laptops works perfectly, so I'm not sure if there is a problem
with the hard disk / controller, with the kernel or with nothing at
all. Just in case, I'm reporting ...
| Apr 11, 2:45 pm 2008 |
| Gary Shi | get a still sysrq-t call trace, not a moving one
Hi friends,
when I read sysrq-t call trace, I find the collected call trace for
some cases is not a still snapshot, but a moving one. After checking
show_state src, I realize other cpus are not frozen when one cpu is
doing show_state; thus some task switching can occur among those cpus,
even the cpu doing sysrq for some kind of kernels.
This moving call traces make debugging much more difficult, or even
impossible for some cases, since some tasks have been switched in/out
which make us lose ...
| Apr 11, 2:43 pm 2008 |
| Matthew Wilcox | [PATCH] Replace completions with semaphores
A long long time ago when dinosaurs roamed the earth and tech
company stock valuations were high (2001), the primitive
of the completion was introduced to save us from a problem
with semaphores. Those interested in the details can examine
http://www.ussg.iu.edu/hypermail/linux/kernel/0107.3/0674.html and
related messages, but everyone else can take my word for it that, with
the generic semaphores I hope will be merged in 2.6.26, semaphores no
longer have the problem that caused us to switch to ...
| Apr 11, 2:00 pm 2008 |
| Linus Torvalds | Linux 2.6.25-rc9
I really don't want to do this, and I was actually hoping to release
2.6.25 last weekend (which is why -rc9 is a few days late - just me hoping
to not do another -rc at all), but I've done an -rc9.
The changes in -rc9 are pretty small (shortlog appended), and 60% of them
are m68k updates - mostly defconfigs. And some doc updates.
But there's some network driver updates (tg3 and wireless hostap stand
out), some late XFS patches and a mvsas driver update (the mvsas driver is
new in ...
| Apr 11, 1:51 pm 2008 |
| Alexey Dobriyan | Re: Shutdown and Reboot Regression 2.6.25-rc[78]
Is it 100% reproducable? I mean sometimes I also have complete lockup right
after one of eth interfaces shutdown during shutdown sequence. And it's
also recent.
But it triggers ~1 time in 10 subjectively..
--
| Apr 11, 2:42 pm 2008 |
| Linus Torvalds | Re: Shutdown and Reboot Regression 2.6.25-rc[78]
Interesting. That commit _should_ have just moved code around with no
actual semantic changes.
Can you verify that undoing just that one commit makes current git (-rc9)
work for you? Ie just try a
git revert 266c2e0abeca649fa6667a1a427ad1da507c6375
on top of the current tree. I just want to check, because even after
looking at that diff again, I'm not seeing what it could actually change.
Linus
--
| Apr 11, 1:58 pm 2008 |
| Bongani Hlope | Re: Shutdown and Reboot Regression 2.6.25-rc[78]
After about 4 restarts and 4 reboots, 2.6.25-rc9 seems to work fine with and
without the revert. I'll do some more testing. The assembly output files for
kernel/printk.c don't seem that different between rc9 and rc7. I'll see what
else I can test.
Thanx
--
| Apr 11, 2:42 pm 2008 |
| Bongani Hlope | Shutdown and Reboot Regression 2.6.25-rc[78]
Hi
I found a regression in version 2.6.25-rc7, which causes my computer not to
shutdown or reboot. I get a complete lock up (no keyboard and Sys-Rq) just
before it normally shuts down the alsa service.
I did a git bisect and it points to this reversion:
[266c2e0abeca649fa6667a1a427ad1da507c6375] Make printk() console semaphore
accesses sensible
00:00.0 Host bridge: VIA Technologies, Inc. VT8385 [K8T800 AGP] Host Bridge
(rev 01)
00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI ...
| Apr 11, 1:41 pm 2008 |
| Linus Torvalds | Re: Shutdown and Reboot Regression 2.6.25-rc[78]
Ok, I suspect it may be timing-dependent and slightly random.
Sadly, that is absolutely the case where "git bisect" works the worst. The
end result of bisection will basically be _totally_ random if even one of
the "git bisect bad/good" choises were wrong - doing a binary search is
a very efficient way to find the buggy commit, but it also means that a
single wrong turn will efficiently find a commit that is somewhere totally
different.
So if your shutdown/reboot regression is even ...
| Apr 11, 4:12 pm 2008 |
| Henrique de Moraes H ... | [GIT PATCH] rfkill support for r/w and r/o rfkill switches
This patch series (based on v2.6.25-rc8-mm2) has several improvements to
the rfkill class that I need for thinkpad-acpi, plus two fluff and
documentation fixes.
I'd appreciate comments, and if the patches are acceptable, that they are
sent to mainline early during the 2.6.26 merge window. That way, I could
try for a thinkpad-acpi rfkill submission for 2.6.26 as well.
The thinkpad-acpi work that needs these patches is ready, and can be
looked at on the thinkpad-acpi git tree (devel ...
| Apr 11, 1:37 pm 2008 |
| Henrique de Moraes H ... | [PATCH 1/8] rfkill: clarify meaning of rfkill states
rfkill really should have been named rfswitch. As it is, one can get
confused whether RFKILL_STATE_ON means the KILL switch is on (and
therefore, the radio is being *blocked* from operating), or whether it
means the RADIO rf output is on.
Clearly state that RFKILL_STATE_ON means the radio is *unblocked* from
operating (i.e. there is no rf killing going on).
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Ivo van Doorn <IvDoorn@gmail.com>
Cc: John W. Linville ...
| Apr 11, 1:37 pm 2008 |
| Henrique de Moraes H ... | [PATCH 3/8] rfkill: handle KEY_RADIO and SW_RADIO events
The *_RADIO input events are related to all radios in a system. There are
two: KEY_RADIO and SW_RADIO.
Teach rfkill-input how to handle them. In particular, SW_RADIO is not a
toggle, but an absolute enable-or-disable command.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Ivo van Doorn <IvDoorn@gmail.com>
Cc: John W. Linville <linville@tuxdriver.com>
Cc: Dmitry Torokhov <dtor@mail.ru>
---
net/rfkill/rfkill-input.c | 57 +++++++++++++++++++++++++++++++++++++++++++-
1 ...
| Apr 11, 1:37 pm 2008 |
| Henrique de Moraes H ... | [PATCH 5/8] rfkill: add read-only rfkill switch support
Some devices (notably laptops) have read-only rfkill switches. Those
devices are slider or rocker switches that are *physically* manipulated by
the user, most of the time tied to hardware or firmware functions that
automatically rf-kill and/or hot-unplug radio devices when in the "radios
off" position.
Software must not (and in fact, cannot) attempt to change the state of any
such switch. These switches exist because of international regulations
regarding radio emission devices on airplanes ...
| Apr 11, 1:37 pm 2008 |
| Henrique de Moraes H ... | [PATCH 7/8] rfkill: add an "any radio" switch type and f ...
Add a RFKILL_TYPE_ANY switch. This switch can control more than one type
of radio, and it is always subject to toggling by any type of rfkill-input
event. It is suitable to implement kill-all-radios functionality when
coupled with input event EV_SW SW_RADIO.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Ivo van Doorn <IvDoorn@gmail.com>
Cc: John W. Linville <linville@tuxdriver.com>
Cc: Dmitry Torokhov <dtor@mail.ru>
---
include/linux/rfkill.h | 2 ++
...
| Apr 11, 1:37 pm 2008 |
| Inaky Perez-Gonzalez | Re: [PATCH 6/8] rfkill: add the WWAN radio type
I know it is easier to complain than to submit code, but at this
point, shouldn't we make this dynamic? [so that the interested technology
that provides an rfkill switch registers it?].
Something that given a technology name registers a dynamic key and type
number that can be use throughout?
--
Inaky
--
| Apr 11, 1:44 pm 2008 |
| Henrique de Moraes H ... | [PATCH 4/8] rfkill: add read-write rfkill switch support
Currently, rfkill supports only write-only rfkill switches. There is no
provision for querying the current switch state from the hardware/firmware.
This is bad on hardware where the switch state can change behind the
kernel's back (which is rather common). There is no reason to keep kernel
state incorrect, when we have the possibility to match reality.
There is also the issue of read-only rfkill switches (support to be added
in a later patch), which absolutely requires support to read the ...
| Apr 11, 1:37 pm 2008 |
| Henrique de Moraes H ... | [PATCH 8/8] rfkill: add parameter to disable radios by default
Currently, radios are always enabled when their rfkill interface is
registered. This is not optimal, the safest state for a radio is to be
offline unless the user turns it on.
Add a module parameter that causes all radios to be disabled when their
rfkill interface is registered. Add override parameters for each rfkill
switch type as well, just in case the user wants the defaults to be
different for a given radio type.
We don't change the module default, but I'd really recommed doing so in ...
| Apr 11, 1:37 pm 2008 |
| Henrique de Moraes H ... | [PATCH 2/8] rfkill: fix minor typo in kernel doc
Fix a minor typo in an exported function documentation
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Ivo van Doorn <IvDoorn@gmail.com>
Cc: John W. Linville <linville@tuxdriver.com>
Cc: Dmitry Torokhov <dtor@mail.ru>
---
net/rfkill/rfkill.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/rfkill/rfkill.c b/net/rfkill/rfkill.c
index 140a0a8..1601e50 100644
--- a/net/rfkill/rfkill.c
+++ b/net/rfkill/rfkill.c
@@ -412,7 +412,7 @@ int ...
| Apr 11, 1:37 pm 2008 |
| Henrique de Moraes H ... | Re: [PATCH 6/8] rfkill: add the WWAN radio type
I wouldn't have anything against that, but we do need to coalesce the
types when possible, otherwise the "type" notion becomes useless for
rfkill-input.
--
"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
--
| Apr 11, 1:53 pm 2008 |
| Henrique de Moraes H ... | [PATCH 6/8] rfkill: add the WWAN radio type
Unfortunately, instead of adding a generic Wireless WAN type, a technology-
specific type (WiMAX) was added. That's useless for other WWAN devices,
such as EDGE, UMTS, X-RTT and other such radios.
Add a WWAN rfkill type for generic wireless WAN devices. No keys are added
as most devices use KEY_RADIO for WWAN control and need no specific keycode
added.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Cc: Iñaky Pérez-González <inaky.perez-gonzalez@intel.com>
Cc: Ivo van Doorn ...
| Apr 11, 1:37 pm 2008 |
| Jonathan Corbet | [PULL] Current documentation tree
I have a current version of the documentation tree at:
git://git.lwn.net/linux-2.6.git docs
There are a couple of code comment changes, but no changes to any code
itself. It's safe to pull now (and it would be nice to get a couple of
these changes in), but can also easily wait for the merge window to
open.
What's there:
J. Bruce Fields (4):
Spell out behavior of atomic_dec_and_lock() in kerneldoc
Documentation: move nfsroot.txt to filesystems/
Documentation: move ...
| Apr 11, 12:45 pm 2008 |
| Miles Lane | 2.6.25-rc8-mm2 -- initcall acpi_init+0x0/0x216() returne ...
Is this indicative of a kernel or hardware problem?
[ 0.279606] ACPI: Using IOAPIC for interrupt routing
[ 0.279789] initcall acpi_init+0x0/0x216() returned with preemption imbalance
[ 0.330789] ACPI: PCI Root Bridge [PCI0] (0000:00)
Thanks,
Miles
--
| Apr 11, 12:41 pm 2008 |
| Jochen Friedrich | [PATCHv2 7/7] [POWERPC] Add i2c pins to dts and board setup
Initialize I2C pins on boards with CPM1/CPM2 controllers.
Signed-off-by: Jochen Friedrich <jochen@scram.de>
---
arch/powerpc/boot/dts/mpc8272ads.dts | 10 ++++++++++
arch/powerpc/boot/dts/mpc866ads.dts | 10 ++++++++++
arch/powerpc/boot/dts/mpc885ads.dts | 10 ++++++++++
arch/powerpc/platforms/82xx/mpc8272_ads.c | 4 ++++
arch/powerpc/platforms/8xx/mpc86xads_setup.c | 4 ++++
arch/powerpc/platforms/8xx/mpc885ads_setup.c | 3 +++
6 files changed, 41 ...
| Apr 11, 12:26 pm 2008 |
| Matthew Wilcox | [DOC PATCH] semaphore documentation
I've never programmed in C++ ... I just expect to find API documentation
I see that as being "move the complexity around" and "get the interfaces
Fine, I've done it the other way round.
Please review this doc-patch. Without comments, I'll commit it to the
semaphore git tree tomorrow.
diff --git a/include/linux/semaphore.h b/include/linux/semaphore.h
index a7125da..9cae64b 100644
--- a/include/linux/semaphore.h
+++ b/include/linux/semaphore.h
@@ -4,8 +4,7 @@
*
* Distributed ...
| Apr 11, 12:21 pm 2008 |
| Randy Dunlap | Re: [DOC PATCH] semaphore documentation
Looks good to me. Thanks.
---
~Randy
--
| Apr 11, 1:27 pm 2008 |
| David Miller | Re: [PATCHv2 3/7] i2c: OF helpers for the i2c API
From: Jochen Friedrich <jochen@scram.de>
Acked-by: David S. Miller <davem@davemloft.net>
--
| Apr 11, 12:27 pm 2008 |
| Jochen Friedrich | [PATCHv2 3/7] i2c: OF helpers for the i2c API
This patch implements various helpers to support OF bindings for
the i2c API.
Signed-off-by: Jochen Friedrich <jochen@scram.de>
---
drivers/of/Kconfig | 6 +++
drivers/of/Makefile | 1 +
drivers/of/i2c.c | 115 ++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/of_i2c.h | 24 ++++++++++
4 files changed, 146 insertions(+), 0 deletions(-)
create mode 100644 drivers/of/i2c.c
create mode 100644 include/linux/of_i2c.h
diff --git a/drivers/of/Kconfig ...
| Apr 11, 12:22 pm 2008 |
| Phil Oester | PCI probe order changes after 2.6.22
In commit 08f1c192c3c32797068bfe97738babb3295bbf42 (x86-64: introduce
struct pci_sysdata to facilitate sharing of ->sysdata), a change was
made from using pcibios_scan_root to pci_scan_bus_parented. pcibios_scan_root
applies some quirks to various systems via pciprobe_dmi_table, including a
number of Dell PowerEdge servers. The similarly named acpi_pciprobe_dmi_table,
however, does not apply the same set_bf_sort quirk, so between .22 and .23, the
onboard Broadcom nics reversed their probe ...
| Apr 11, 11:55 am 2008 |
| Marc Perkel | Re: AMD Quad Core clock problem?
No - it's not wild like it was back in the early X2
days and I think you're right about the drift being
normal. Interesting thing though I am running ntpd and
it's not working. I am fairly sure the ntp.conf file
is exactly as it was installed by fedora. I'm now
looking into that.
Thanks for your help. Sorry for the false alarm. But
if thee was an issue I thought you would want to know
it.
Marc Perkel
Junk Email Filter dot ...
| Apr 11, 2:36 pm 2008 |
| Chris Snook | Re: AMD Quad Core clock problem?
With the older chips, each core had its own TSC, which caused
synchronization problems. The Barcelona generation chips (including
your Phenom) have a constant frequency TSC on the northbridge, so they
should be immune to these problems.
If it's steadily losing a few seconds every hour, it's probably just
slightly mis-calibrated hardware. ntp should fix this right up. If the
drift is more extreme than ntp can correct for, or the drift keeps
changing, or time is jumping around, that is ...
| Apr 11, 2:11 pm 2008 |
| Lennart Sorensen | Re: AMD Quad Core clock problem?
I have found that ntp tends to fail to work on any machine with spread
spectrum clocking enabled. On those machines disabling spread specturm
in the BIOS seems to fix it. I had to update the BIOS on one machine to
even get the option to disable it though.
--
Len Sorensen
--
| Apr 11, 2:38 pm 2008 |
| Krzysztof Halasa | Re: AMD Quad Core clock problem?
Few seconds an hour is hardly normal, thats 0.1%. The prime suspect
is probably the motherboard and it's faulty clock generator (one of
- HPET's?).
What motherboard is it?
--
Krzysztof Halasa
--
| Apr 11, 2:46 pm 2008 |
| Marc Perkel | AMD Quad Core clock problem?
I was just wondering if there were any known issues
with AMD quad core phenom clock drift problems? I';m
running a 2.6.24 kernel and it's losing time. I
remember the first dual core AMD chips had a lot of
clock issues.
If this is something new let me know what information
to check and post to this list.
Marc Perkel
Junk Email Filter dot com
http://www.junkemailfilter.com
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam ...
| Apr 11, 11:27 am 2008 |
| Marc Perkel | Re: AMD Quad Core clock problem?
Is it possible due to calibration that ntpd isn't able
to correct the problem? Is there a setting to make ntp
more agressive?
Marc Perkel
Junk Email Filter dot com
http://www.junkemailfilter.com
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--
| Apr 11, 3:09 pm 2008 |
| Chris Snook | Re: AMD Quad Core clock problem?
When reporting clock problems, please post dmesg. This has all the
interesting timekeeping-related log messages from the kernel. Please
also describe the drift quantitatively.
-- Chris
--
| Apr 11, 11:38 am 2008 |
| Marc Perkel | Re: AMD Quad Core clock problem?
OK - thanks Chris.
The drift is small. It loses a few seconds every hour.
And it might not be kernel related. I just remembered
the early dual core days when this took months to get
right. I'm running several dual core computers and the
only one drifting is the quad. All are running the
same OS and kernel.
Initializing cgroup subsys cpuset
Linux version 2.6.24-ovz004.1
(root@centos4-build.vzlin.sw.ru) (gcc version 3.4.6
20060404 (Red Hat 3.4.6-3)) #1 SMP Tue Mar 25 16:23:06
MSK ...
| Apr 11, 1:28 pm 2008 |
| H. Willstrand | Re: AMD Quad Core clock problem?
I don't know if this is related, however check
http://marc.info/?l=linux-kernel&m=120784269708442&w=2
--
| Apr 11, 11:35 am 2008 |
| Sam Ravnborg | Re: linux-2.6.25-rc8-git7 - section mismatches on x86
Thanks for your report Davide.
We have several "Section mismatch warning" fixes queued
up in -mm and in x86.git so I expect most of the ones below
to be already fixed.
Merging is postponed until next merge window.
A similar report at -rc1 time would be good.
Sam
--
| Apr 11, 11:25 am 2008 |
| Davide Pesavento | linux-2.6.25-rc8-git7 - section mismatches on x86
While compiling linux-2.6.25-rc8-git7 with
CONFIG_DEBUG_SECTION_MISMATCH=y, I noticed the following "section
mismatch" warnings.
Please CC me as I'm not subscribed to this list.
WARNING: vmlinux.o(.text+0x10d58): Section mismatch in reference from
the function cpu_exit_clear() to the function
.cpuinit.text:cpu_uninit()
The function cpu_exit_clear() references
the function __cpuinit cpu_uninit().
This is often because cpu_exit_clear lacks a __cpuinit
annotation or the annotation of cpu_uninit ...
| Apr 11, 11:02 am 2008 |
| David Brownell | [patch 2.6.25-rc8] leds: fix platform driver hotplug/coldplug
From: Kay Sievers <kay.sievers@vrfy.org>
Since 43cc71eed1250755986da4c0f9898f9a635cb3bf, the platform
modalias is prefixed with "platform:". Add MODULE_ALIAS() to the
hotpluggable platform LED drivers, to re-enable auto loading.
[ dbrownell@users.sourceforge.net: more drivers, registration fixes ]
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
---
drivers/leds/leds-ams-delta.c | 2 ++
drivers/leds/leds-atmel-pwm.c | ...
| Apr 11, 10:38 am 2008 |
| Alan Cox | Re: [2.6 patch] make ali_atapi_dma static
On Fri, 11 Apr 2008 20:28:27 +0300
Acked-by: Alan Cox <alan@redhat.com>
--
| Apr 11, 11:36 am 2008 |
| Adrian Bunk | [2.6 patch] make ali_atapi_dma static
This patch makes the needlessly global ali_atapi_dma static.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
de012fdf57e025cf243181cb3fce87f890ccc955 diff --git a/drivers/ata/pata_ali.c b/drivers/ata/pata_ali.c
index ce830fe..511a830 100644
--- a/drivers/ata/pata_ali.c
+++ b/drivers/ata/pata_ali.c
@@ -36,7 +36,7 @@
#define DRV_NAME "pata_ali"
#define DRV_VERSION "0.7.5"
-int ali_atapi_dma = 0;
+static int ali_atapi_dma = 0;
module_param_named(atapi_dma, ali_atapi_dma, int, ...
| Apr 11, 10:28 am 2008 |
| Dan Upton | CFS rq lock question
I'm poking around with some scheduler stuff, and there's something I'm
not clear on for the CFS runqueue locks. The comments before
__load_balance_iterator(...) in sched_fair.c suggests things can be
dequeued even though the runqueue lock is held. Can things also be
added to the queue while the lock is held? (Also, either way, what's
the rationale that dequeueing is a safe procedure when somebody else
holds a lock?)
-dan
--
| Apr 11, 10:21 am 2008 |
| Peter Zijlstra | Re: CFS rq lock question
D'oh, I'm silly..
the task can be dequeued because we move it to another cpu.
--
| Apr 11, 10:41 am 2008 |
| Peter Zijlstra | Re: CFS rq lock question
/*
* Load-balancing iterator. Note: while the runqueue stays locked
* during the whole iteration, the current task might be
* dequeued so the iterator has to be dequeue-safe. Here we
* achieve that by always pre-iterating before returning
* the current task:
*/
I don't think this comment is correct, but if it were, it would only
apply to rq->curr, not for any enqueue/dequeue.
--
| Apr 11, 10:37 am 2008 |
| Erik Bosman | [PATCH 3/3] Add tests for prctl PR_GET_TSC and PR_SET_TSC
This patch adds three tests that test whether the PR_GET_TSC and
PR_SET_TSC commands have the desirable effect.
The tests check whether the control register is updated correctly
at context switches and try to discover bugs while enabling/disabling
the timestamp counter.
Signed-off-by: Erik Bosman <ejbosman@cs.vu.nl>
---
.../prctl/disable-tsc-ctxt-sw-stress-test.c | 96 ++++++++++++++++++++
.../prctl/disable-tsc-on-off-stress-test.c | 95 ...
| Apr 11, 9:57 am 2008 |
| Erik Bosman | [PATCH 2/3] x86: Implement prctl PR_GET_TSC and PR_SET_TSC
x86: Implement prctl PR_GET_TSC and PR_SET_TSC
This patch adds a configure option CONFIG_DISABLE_TSC
(off by default) for the x86 platform to enable the
PR_GET_TSC and PR_SET_TSC commands. These control the
ability to use the timestamp counter from userspace
(the RDTSC instruction.)
This patch uses code earlier used to disable the
timestamp counter for the SECCOMP framework. It used
to disable the RDTSC on 32 bit kernels, but allow it
on x86_64. ...
| Apr 11, 9:55 am 2008 |
| Erik Bosman | [PATCH 1/3] Add prctl commands PR_GET_TSC and PR_SET_TSC
This patch adds prctl commands that make it possible
to deny the execution of timestamp counters in userspace.
If this is not implemented on a specific architecture,
prctl will return -EINVAL.
Signed-off-by: Erik Bosman <ejbosman@cs.vu.nl>
---
include/linux/prctl.h | 6 ++++++
kernel/sys.c | 13 ++++++++++++-
2 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/include/linux/prctl.h b/include/linux/prctl.h
index 3800639..5c80b19 100644
--- ...
| Apr 11, 9:54 am 2008 |
| Nadia.Derbey | [PATCH 13/13] Get rid of ipc_lock_down()
[PATCH 13/13]
With the previous patch ipc_lock() becomes lockless.
So there is no need anymore for ipc_lock_down()-like routines.
Signed-off-by: Nadia Derbey <Nadia.Derbey@bull.net>
---
ipc/shm.c | 21 +++------------------
ipc/util.c | 52 +---------------------------------------------------
ipc/util.h | 6 ------
3 files changed, 4 insertions(+), 75 deletions(-)
Index: linux-2.6.25-rc8-mm1/ipc/util.h
===================================================================
--- ...
| Apr 11, 9:17 am 2008 |
| Nadia.Derbey | [PATCH 12/13] Integrate the ridr code into IPC code
[PATCH 12/13]
This patche makes the ipc ode use the ridr api.
Signed-off-by: Nadia Derbey <Nadia.Derbey@bull.net>
---
include/linux/ipc_namespace.h | 4 +--
ipc/namespace.c | 2 -
ipc/shm.c | 2 -
ipc/util.c | 44 ++++++++++++++++++------------------------
4 files changed, 23 insertions(+), 29 deletions(-)
Index: ...
| Apr 11, 9:17 am 2008 |
| Nadia.Derbey | [PATCH 11/13] Integrate the ridr code
[PATCH 11/13]
From now on the ridr code can be compiled and used (the initialization routine
is called during kernel init).
Signed-off-by: Nadia Derbey <Nadia.Derbey@bull.net>
---
init/main.c | 2 ++
lib/Makefile | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
Index: linux-2.6.25-rc8-mm1/lib/Makefile
===================================================================
--- linux-2.6.25-rc8-mm1.orig/lib/Makefile 2008-04-11 17:14:08.000000000 +0200
+++ ...
| Apr 11, 9:17 am 2008 |
| Nadia.Derbey | [PATCH 10/13] Fix ridr_find()
[PATCH 10/13]
This patch only fixes the ridr_find() portion of ridr.c,
to make it RCU based.
Signed-off-by: Nadia Derbey <Nadia.Derbey@bull.net>
---
lib/ridr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6.25-rc8-mm1/lib/ridr.c
===================================================================
--- linux-2.6.25-rc8-mm1.orig/lib/ridr.c 2008-04-11 18:04:08.000000000 +0200
+++ linux-2.6.25-rc8-mm1/lib/ridr.c 2008-04-11 18:09:00.000000000 +0200
@@ -381,7 ...
| Apr 11, 9:17 am 2008 |
| Nadia.Derbey | [PATCH 09/13] Fix ridr_remove()
[PATCH 09/13]
This patch only fixes the sub_remove() and ridr_remove() portions of ridr.c,
to make them RCU based.
Note: also fixes idr_remove(): looks like there is a return that is not at the
right place.
Signed-off-by: Nadia Derbey <Nadia.Derbey@bull.net>
---
include/linux/idr.h | 1 +
lib/idr.c | 9 +++++----
lib/ridr.c | 29 +++++++++++++----------------
3 files changed, 19 insertions(+), 20 deletions(-)
Index: ...
| Apr 11, 9:17 am 2008 |
| Nadia.Derbey | [PATCH 08/13] Fix ridr_get_new_above_int()
[PATCH 08/13]
This patch only fixes the ridr_get_new_above_int() portion of ridr.c, to make
it RCU based.
Signed-off-by: Nadia Derbey <Nadia.Derbey@bull.net>
---
lib/ridr.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
Index: linux-2.6.25-rc8-mm1/lib/ridr.c
===================================================================
--- linux-2.6.25-rc8-mm1.orig/lib/ridr.c 2008-04-11 17:55:37.000000000 +0200
+++ linux-2.6.25-rc8-mm1/lib/ridr.c 2008-04-11 17:58:41.000000000 ...
| Apr 11, 9:17 am 2008 |
| Nadia.Derbey | [PATCH 07/13] Fix get_empty_slot()
[PATCH 07/13]
This patch only fixes the ridr_get_empty_slot() portion of ridr.c, to make
it RCU based.
Signed-off-by: Nadia Derbey <Nadia.Derbey@bull.net>
---
lib/ridr.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
Index: linux-2.6.25-rc8-mm1/lib/ridr.c
===================================================================
--- linux-2.6.25-rc8-mm1.orig/lib/ridr.c 2008-04-11 17:51:34.000000000 +0200
+++ linux-2.6.25-rc8-mm1/lib/ridr.c 2008-04-11 17:55:37.000000000 ...
| Apr 11, 9:17 am 2008 |
| Nadia.Derbey | [PATCH 06/13] Fix sub_alloc()
[PATCH 06/13]
This patch only fixes the sub_alloc() portion of ridr.c, to make it RCU based.
Signed-off-by: Nadia Derbey <Nadia.Derbey@bull.net>
---
lib/ridr.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
Index: linux-2.6.25-rc8-mm1/lib/ridr.c
===================================================================
--- linux-2.6.25-rc8-mm1.orig/lib/ridr.c 2008-04-11 17:47:48.000000000 +0200
+++ linux-2.6.25-rc8-mm1/lib/ridr.c 2008-04-11 17:51:34.000000000 +0200
@@ ...
| Apr 11, 9:17 am 2008 |
| Nadia.Derbey | [PATCH 05/13] Fix free_layer()
[PATCH 05/13]
This patch only fixes the free_layer() portion of ridr.c, to make it use
call_rcu().
Signed-off-by: Nadia Derbey <Nadia.Derbey@bull.net>
---
lib/ridr.c | 27 ++++++++++-----------------
1 file changed, 10 insertions(+), 17 deletions(-)
Index: linux-2.6.25-rc8-mm1/lib/ridr.c
===================================================================
--- linux-2.6.25-rc8-mm1.orig/lib/ridr.c 2008-04-11 17:43:44.000000000 +0200
+++ linux-2.6.25-rc8-mm1/lib/ridr.c 2008-04-11 ...
| Apr 11, 9:17 am 2008 |
| Nadia.Derbey | [PATCH 04/13] Fix ridr_alloc_layer()
[PATCH 04/13]
This patch only fixes the alloc_layer() portion of ridr.c, to make it use the
per-cpu pool of preloaded ridr layer structures.
Signed-off-by: Nadia Derbey <Nadia.Derbey@bull.net>
---
lib/ridr.c | 35 +++++++++++++++++++++++++----------
1 file changed, 25 insertions(+), 10 deletions(-)
Index: linux-2.6.25-rc8-mm1/lib/ridr.c
===================================================================
--- linux-2.6.25-rc8-mm1.orig/lib/ridr.c 2008-04-11 17:40:13.000000000 +0200
+++ ...
| Apr 11, 9:17 am 2008 |
| Nadia.Derbey | [PATCH 03/13] Fix ridr_pre_get()
[PATCH 03/13]
This patch only fixes the ridr_pre_get() portion of ridr.c, to introduce a
per-cpu pool of preloaded ridr layer structures, and define the
ridr_pre_get[_end]() routines.
Signed-off-by: Nadia Derbey <Nadia.Derbey@bull.net>
---
include/linux/ridr.h | 7 ++++++-
lib/ridr.c | 50 ++++++++++++++++++++++++++++++++++++--------------
2 files changed, 42 insertions(+), 15 deletions(-)
Index: ...
| Apr 11, 9:17 am 2008 |
| Nadia.Derbey | [PATCH 02/13] Change ridr structure
[PATCH 02/13]
This patch changes the ridr structures to make them use RCU.
Signed-off-by: Nadia Derbey <Nadia.Derbey@bull.net>
---
include/linux/ridr.h | 42 +++++++++++++++++++++++++++---------------
1 file changed, 27 insertions(+), 15 deletions(-)
Index: linux-2.6.25-rc8-mm1/include/linux/ridr.h
===================================================================
--- linux-2.6.25-rc8-mm1.orig/include/linux/ridr.h 2008-04-11 17:17:41.000000000 +0200
+++ ...
| Apr 11, 9:17 am 2008 |
| Nadia.Derbey | [PATCH 01/13] duplicate idr code
[PATCH 01/13]
This patch duplicates idr.c and idr.h, only changing the routines and
structures names where needed.
Signed-off-by: Nadia Derbey <Nadia.Derbey@bull.net>
---
include/linux/ridr.h | 58 +++++++
lib/ridr.c | 386 +++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 444 insertions(+)
Index: linux-2.6.25-rc8-mm1/include/linux/ridr.h
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 ...
| Apr 11, 9:17 am 2008 |
| Peter Zijlstra | Re: [PATCH 00/13] Re: Scalability requirements for sysv ipc
Why duplicate the whole thing, when we converted the Radix tree to be
RCU safe we did it in-place. Is there a reason this is not done for idr?
--
| Apr 11, 9:27 am 2008 |
| Nadia.Derbey | [PATCH 00/13] Re: Scalability requirements for sysv ipc
Here is finally the ipc ridr-based implementation I was talking about last
week (see http://lkml.org/lkml/2008/4/4/208).
I couldn't avoid much of the code duplication, but at least made things
incremental.
Does somebody now a test suite that exists for the idr API, that I could
run on this new api?
Mike, can you try to run it on your victim: I had such a hard time building
this patch, that I couldn't re-run the test on my 8-core with this new
version. So the last results I have are for ...
| Apr 11, 9:17 am 2008 |
| Andy Whitcroft | [PATCH] update checkpatch.pl to version 0.18
[This update is lighter than normal as I want to get these out before
leaving for vacation.]
This version brings a few fixes for the extern checks, and a couple of
new checks.
Of note:
- false is now recognised as a 0 assignment in static/external
assignments,
- printf format strings including %L are reported,
- a number of fixes for the extern in .c file detector which had
temporarily lost its ability to detect variables; undetected due to
the loss of its test.
Andy ...
| Apr 11, 8:41 am 2008 |
| Nick Andrew | [RFC] x86: Cleanup prose of Documentation/i386/IO-APIC.txt
I'm doing a couple of cleanups to Documentation/i386/IO-APIC.txt
and I have a problem with this line, which is supposed to compute
a sample pirq= kernel parameter:
echo -n pirq=; echo `scanpci | grep T_L | cut -c56-` | sed 's/ /,/g'
The 'scanpci' command used to be part of xutils and/or XFree86.
Xorg implements "Xorg -scanpci" but the output is different and it won't
run while X is running.
Firstly I propose using the $( ) construct rather than backticks, since
it is easier to read:
...
| Apr 11, 8:40 am 2008 |
| Al Viro | Re: Introducing Fredux: a redundant project
Far more interesting question: who _cares_? The notion of "legitimacy" in
that context is, AFAICS, based on unfounded assumption that there somebody
owes you something - be it their time, their "loyalty", etc. Developers'
minds are not resources you might have a claim upon.
If you make a sufficient nuisance of yourself by playing marketing games,
you will certainly be flamed, but not because of some mystical drain on
resources. Landing pointless drivel in mailboxes is quite sufficient ...
| Apr 11, 9:40 am 2008 |
| Fred Trotter | Introducing Fredux: a redundant project
Hi,
This message is not actually about a new project. It is also
not about the Linux Kernel specifically. Rather, I have a question
about how your community operates. If you feel this is off-topic,
please feel free to ignore it entirely. If you feel that this is
off-topic but interesting (my hope) then feel free to email me
directly at fred.trotter@gmail.com rather than gum up the mailing list
with a 'community' discussion. While this is marginally off-topic,
note that it is a ...
| Apr 11, 8:38 am 2008 |
| Uladzislau Rezki | Kernel Oops within Linux Fedore Core 5
HI,
I am running linux Fedore Core 5 with 2.6.15 linux kernel.
So , the problem is that, while loading my own kernel module, kernel gets Oops.
---> usbfs
---> tmpfs
---> binfmt_misc
---> rpc_pipefs
---> autofs
Unable to handle kernel paging request at virtual address dead4ead
printing eip:
c7034018
*pde = 00000000
Oops: 0000 [#1]
last sysfs file: /class/net/sit0/address
Modules linked in: sb_show(U) ipv6 autofs4 hidp rfcomm l2cap bluetooth
sunrpc dm_mirror dm_mod video button ...
| Apr 11, 8:13 am 2008 |
| Dpto de Marketing - ... | Divulgue seu Site ou
ANUNCIE SEU SITE OU SERVI
| Apr 11, 7:30 am 2008 |
| Jochen Friedrich | [PATCH7/7] [POWERPC] Add i2c pins to dts and board setup
Initialize I2C pins on boards with CPM1/CPM2 controllers.
Signed-off-by: Jochen Friedrich <jochen@scram.de>
---
arch/powerpc/boot/dts/mpc8272ads.dts | 10 ++++++++++
arch/powerpc/boot/dts/mpc866ads.dts | 10 ++++++++++
arch/powerpc/boot/dts/mpc885ads.dts | 10 ++++++++++
arch/powerpc/platforms/82xx/mpc8272_ads.c | 4 ++++
arch/powerpc/platforms/8xx/mpc86xads_setup.c | 4 ++++
arch/powerpc/platforms/8xx/mpc885ads_setup.c | 3 +++
6 files changed, 41 ...
| Apr 11, 7:12 am 2008 |
| Scott Wood | Re: [PATCH7/7] [POWERPC] Add i2c pins to dts and board setup
mpc8272-i2c
-Scott
--
| Apr 11, 8:02 am 2008 |
| Jochen Friedrich | [PATCH6/7] i2c: adds support for i2c bus on Freescale CP ...
This driver uses the port of 2.4 code from Vitaly Bordug
<vitb@kernel.crashing.org> and the actual algorithm used by the i2c
driver of the DBox code on cvs.tuxboc.org from Felix Domke
(tmbinc@gmx.net) and Gillem (htoa@gmx.net) converted to an
of_platform_driver. Tested on CPM1 (MPC823 on dbox2 hardware) and
CPM2 (MPC8272).
Signed-off-by: Jochen Friedrich <jochen@scram.de>
---
drivers/i2c/busses/Kconfig | 10 +
drivers/i2c/busses/Makefile | 1 +
drivers/i2c/busses/i2c-cpm.c | 728 ...
| Apr 11, 7:11 am 2008 |
| Jochen Friedrich | [PATCH5/7] i2c: Kill the old driver matching scheme
Based on earlier work by Jon Smirl and Jean Delvare.
Remove the old driver_name/type scheme for i2c driver matching. Only the
standard aliasing model will be used from now on.
Signed-off-by: Jochen Friedrich <jochen@scram.de>
Cc: Jean Delvare <khali@linux-fr.org>
Cc: Jon Smirl <jonsmirl@gmail.com>
---
drivers/i2c/i2c-core.c | 35 +++++++++++++----------------------
include/linux/i2c.h | 9 ++-------
2 files changed, 15 insertions(+), 29 deletions(-)
diff --git ...
| Apr 11, 7:11 am 2008 |
| Jochen Friedrich | [PATCH4/7] i2c: Convert PowerPC MPC i2c to of_platform_d ...
Based on earlier work by Jon Smirl.
Changed common name from powerpc_ to of_ per Olof's suggestion.
Convert MPC i2c driver from a platform_driver to a of_platform_driver. Add the ability to dynamically load i2c drivers based on device tree names. Routine names were changed from fsl_ to mpc_ to make them match the file name. Common code moved to of-common.* Orginal ppc driver left intact for deletion when ppc arch is removed.
Signed-off-by: Jochen Friedrich <jochen@scram.de>
Cc: Jon Smirl ...
| Apr 11, 7:10 am 2008 |
| Jochen Friedrich | Re: [PATCH3/7] i2c: OF helpers for the i2c API
I've resenf the patch without the dependency on PPC_OF.
Thanks for the comment.
Jochen
--
| Apr 11, 12:23 pm 2008 |
| David Miller | Re: [PATCH3/7] i2c: OF helpers for the i2c API
From: Jochen Friedrich <jochen@scram.de>
I wouldn't mind trying to use this infrastructure on
sparc64, and I don't see any powerpc specific interfaces
being invoked, so if you could remove the PPC_OF
requirement I'd appreciate it.
Thanks.
--
| Apr 11, 10:43 am 2008 |
| Jochen Friedrich | [PATCH3/7] i2c: OF helpers for the i2c API
This patch implements various helpers to support OF bindings for
the i2c API.
Signed-off-by: Jochen Friedrich <jochen@scram.de>
---
drivers/of/Kconfig | 6 +++
drivers/of/Makefile | 1 +
drivers/of/i2c.c | 115 ++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/of_i2c.h | 24 ++++++++++
4 files changed, 146 insertions(+), 0 deletions(-)
create mode 100644 drivers/of/i2c.c
create mode 100644 include/linux/of_i2c.h
diff --git a/drivers/of/Kconfig ...
| Apr 11, 7:09 am 2008 |
| Jochen Friedrich | [PATCH2/7] i2c: Convert all new-style drivers to use mod ...
Based on earlier work by Jon Smirl and Jean Delvare.
Update all the new-style i2c drivers to use standard module aliasing
instead of the old driver_name/type driver matching scheme.
Signed-off-by: Jochen Friedrich <jochen@scram.de>
Cc: Jean Delvare <khali@linux-fr.org>
Cc: Jon Smirl <jonsmirl@gmail.com>
---
arch/arm/mach-at91/board-csb337.c | 3 +-
arch/arm/mach-at91/board-dk.c | 3 +-
arch/arm/mach-at91/board-eb9200.c | 3 +-
...
| Apr 11, 7:08 am 2008 |
| Jochen Friedrich | [PATCH1/7] i2c: Add support for device alias names
Based on earlier work by Jon Smirl and Jean Delvare.
This patch allows new-style i2c chip drivers to have alias names using
the official kernel aliasing system and MODULE_DEVICE_TABLE(). At this
point, the old i2c driver binding scheme (driver_name/type) is still
supported.
Signed-off-by: Jochen Friedrich <jochen@scram.de>
Cc: Jean Delvare <khali@linux-fr.org>
Cc: Jon Smirl <jonsmirl@gmail.com>
---
drivers/hwmon/f75375s.c | 21 ++++++++----
drivers/i2c/chips/ds1682.c ...
| Apr 11, 7:07 am 2008 |
| Jochen Friedrich | [PATCH0/7] OF support for i2c bus drivers
This series of patches implements the framework needed by of_platform_driver i2c bus drivers.
i2c-mpc is then converted to an of_platform_driver and i2c-cpm is added as new driver.
This is based on earlier work by Jon Smirl and Jean Delvare.
[PATCH1/7] i2c: Add support for device alias names
[PATCH2/7] i2c: Convert all new-style drivers to use module aliasing
[PATCH3/7] i2c: OF helpers for the i2c API
[PATCH4/7] i2c: Convert PowerPC MPC i2c to of_platform_driver from ...
| Apr 11, 7:06 am 2008 |
| Peter Zijlstra | Re: 2.6.25-rc8-mm2 -- kernel/sched.c:8294: error: unknow ...
someone mucked around with the cgroup api; this should fix it:
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
---
diff --git a/kernel/sched.c b/kernel/sched.c
index 7119895..8b4e0b6 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -8291,8 +8291,8 @@ static struct cftype cpu_files[] = {
},
{
.name = "rt_period_us",
- .read_uint = cpu_rt_period_read_uint,
- .write_uint = cpu_rt_period_write_uint,
+ .read_u64 = cpu_rt_period_read_uint,
+ .write_u64 = ...
| Apr 11, 9:55 am 2008 |
| Ingo Molnar | Re: 2.6.25-rc8-mm2 --
cannot reproduce it in sched-devel/for-akpm (which -mm is based off) nor
in sched-devel/latest, using your config. Could you check sched-devel
via:
http://people.redhat.com/mingo/sched-devel.git/README
or maybe it's some other sched.c change in -mm? That line is around the
control groups code and maybe that got changed in -mm?
meanwhile i built and successfully booted your config on a testsystem on
sched-devel/latest. So if sched-devel/latest still fails for you then
it's some ...
| Apr 11, 6:55 am 2008 |
| Peter Zijlstra | Re: 2.6.25-rc8-mm2 -- kernel/sched.c:8294: error: unknow ...
Yeah, no worries, I recognised it the moment I looked at it. This is
just a merge artefact from changes in different trees.
--
| Apr 11, 11:55 am 2008 |
| Miles Lane | Re: 2.6.25-rc8-mm2 -- kernel/sched.c:8294: error:
This seems to be the option that causes the error to trigger:
CONFIG_CGROUP_SCHED=y
If I switch to USER_SCHED, the build continues.
Miles
--
| Apr 11, 8:47 am 2008 |
| Miles Lane | 2.6.25-rc8-mm2 -- kernel/sched.c:8294: error: un
CC kernel/sched.o
kernel/sched.c:8294: error: unknown field 'read_uint' specified in initializer
kernel/sched.c:8294: warning: initialization makes integer from
pointer without a cast
kernel/sched.c:8295: error: unknown field 'write_uint' specified in initializer
kernel/sched.c:8295: warning: initialization from incompatible pointer type
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.25-rc8-mm2
# Fri Apr 11 09:36:32 2008
#
# CONFIG_64BIT is not ...
| Apr 11, 6:48 am 2008 |
| Miles Lane | Re: 2.6.25-rc8-mm2 -- kernel/sched.c:8294: error:
I tried a "make mrproper" before compiling the 2.6.25-rc8-mm2 tree and it
still gave the same error. This seems to be something specific to the latest
MM tree.
Miles
--
| Apr 11, 8:29 am 2008 |
| Paul Menage | Re: 2.6.25-rc8-mm2 -- kernel/sched.c:8294: error:
Sorry - this change was in my original API patch (plus renaming the
read/write functions to have u64 suffices) but I think it collided
with the git-sched instability around the end of February.
Paul
--
| Apr 11, 11:46 am 2008 |
| Guadalupe Chrestman | [Fotigate_Spam] boastfully
Hello,
=20
Real men!=20
MMillions of people acrooss the world have already tested THIS and ARE maki=
ng their girlfriendds feel brand new sexual sensationns! YOU are the best i=
n bed, aren't you ?Girls! Devvelop your sexual relationsship and get even M=
ORE pleasuree!=20
Make your booyfriend a gift!
http://wv06wv25x0cia.blogspot.com
=09
Side and the bogle tell me about the game you barrier. To
the southwest, approximately twenty that left white patches
amongst that beautiful amid the ...
| Apr 11, 6:24 am 2008 |
| Antonio Ávila | Re: Error using "make KBUILD_OUTPUT=path" or "make O=path"
D'oh!
Many thanks, I could repeat this again and again and I wouldn't have noticed :S
cu
Anthony
--
| Apr 11, 2:50 pm 2008 |
| Adrian Bunk | Re: Error using "make KBUILD_OUTPUT=path" or "make O=path"
You also have to give the O= to the make commandline when configuring
the kernel - this will put the .config to the right place.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
| Apr 11, 6:00 am 2008 |
| Antonio Ávila | Error using "make KBUILD_OUTPUT=path" or "make O=path"
First of all, I'd like to introduce myself, my name is Anthony and
I've been using linux during the last 8 years.
I have googled around and I haven't found anything so let's go to the question:
It seems that when initializing either KBUILD_OUTPUT or O variables
(make KBUILD_OUTPUT="../build/" ) there is a problem, the output is
effectivly working, but the problem is that some files (.config) that
has been generated at the begining of the make process, are later used
and as a consecuence, the ...
| Apr 11, 5:38 am 2008 |
| Bryan Henderson | Re: file offset corruption on 32-bit machines?
Only if you make an assumption about what this program considers the right
location. One difference is that in the first case, data gets written
only at a place to which the program seeked, while in the second, it gets
written to a totally illogical place. Another is that in the first, the
data gets written as specified in standards and in the second, it doesn't.
I can imagine a program that would be satisfied with the first and not
the second, and for such a program, I cannot use the ...
| Apr 11, 2:29 pm 2008 |
| Bryan Henderson | Re: file offset corruption on 32-bit machines?
I think I know what locking around shared resources is for, which is why
I'm surprised the kernel doesn't do it.
Is it normal for a kernel resource not to be thread-safe (i.e. you don't
get advertised/sensible results if two threads access it at the same
I could accept (though I haven't thought about it) that there aren't any
real-world applications that do simultaneous reads and writes through the
same file pointer. I might even accept that there can be no useful
application that ...
| Apr 11, 9:59 am 2008 |
| Bodo Eggert | Re: file offset corruption on 32-bit machines?
AS far as I understand, the race is e.g.:
fpos := A:a, we want to make process/thread a read A:b or B:a without it
being a correct value in fpos. a!=b!=c, A!=B, A!=C.
a: read fpos.high (A:?)
b: write fpos (B:b)
a: read fpos.low (A:b)
If you change this to
a: read fpos.high
a: read fpos.low
a: read fpos.high
a: read fpos.low
and compare the results, you need to
a: read fpos.high (A:?)
b: write fpos (B:b)
a: read fpos.low (A:b)
b: write fpos (A:c)
a: read fpos.high ...
| Apr 11, 5:24 am 2008 |
| Lennart Sorensen | Re: file offset corruption on 32-bit machines?
If two threads are changing one filehandle at the same time, then the
program is broken. I can't see how the kernel making updates to 64bit
filehandles "atomic" helps. You could still seek in one thread, then
seek in another and then start the write in the first and get a wrong
result. Changes to a shared filehandle of any kind requires locking to
work reliably, so additional slow downs and locking in the kernel won't
Unless the application has it's own locking to ensure multiple ...
| Apr 11, 10:15 am 2008 |
| Lennart Sorensen | Re: file offset corruption on 32-bit machines?
So if you write multithreaded code and don't understand what locking
around shared resources is for, then your application might break. Can
you give an example where locking is being used correctly where this can
possibly fail? The kernel can't prevent idiots from writing bad code
that breaks.
I just don't get this "problem".
--
Len Sorensen
--
| Apr 11, 6:55 am 2008 |
| Jacek Luczak | [PATCH 3/3] x86: Section mismatch fixes
This patch fixes section mismatch warnings in unlock_ExtINT_logic().
WARNING: arch/x86/kernel/built-in.o(.text+0x14a92): Section mismatch in reference from the function unlock_ExtINT_logic()
to the function .init.text:find_isa_irq_pin()
The function unlock_ExtINT_logic() references
the function __init find_isa_irq_pin().
This is often because unlock_ExtINT_logic lacks a __init
annotation or the annotation of find_isa_irq_pin is wrong.
Signed-off-by: Jacek Luczak ...
| Apr 11, 4:29 am 2008 |
| Jacek Luczak | [PATCH 2/3] x86: Section mismatch fixes
This patch fixes section mismatch warnings in smpboot_setup_io_apic().
WARNING: arch/x86/kernel/built-in.o(.text+0x11781): Section mismatch in reference from the function smpboot_setup_io_apic()
to the function .init.text:setup_IO_APIC()
The function smpboot_setup_io_apic() references
the function __init setup_IO_APIC().
This is often because smpboot_setup_io_apic lacks a __init
annotation or the annotation of setup_IO_APIC is wrong.
Signed-off-by: Jacek Luczak ...
| Apr 11, 4:28 am 2008 |
| Jacek Luczak | [PATCH 1/3] x86: Section mismatch fixes
This patch fixes mismatch warnings in smp_checks() (in arch/x86/kernel/smpboot.c):
WARNING: arch/x86/kernel/built-in.o(.text+0x11922): Section mismatch in reference from the function smp_checks()
to the variable .cpuinit.data:smp_b_stepping
The function smp_checks() references
the variable __cpuinitdata smp_b_stepping.
This is often because smp_checks lacks a __cpuinitdata
annotation or the annotation of smp_b_stepping is wrong.
Signed-off-by: Jacek Luczak <luczak.jacek@gmail.com>
---
...
| Apr 11, 4:28 am 2008 |
| Ingo Molnar | Re: [PATCH 0/3] x86: Section mismatch fixes
thanks, applied.
(one sidenote: please do not use the same subject line for all patches,
that makes it harder to auto-generate patch names and makes the shortlog
harder to read as well.)
Ingo
--
| Apr 11, 4:42 am 2008 |
| Jacek Luczak | [PATCH 0/3] x86: Section mismatch fixes
Hi,
those patches fixes some section mismatch warnings, which appear on x86_64 with linux-next-200804[09,10,11].
It's continuation of work on section mismatches which result in two patches send previously:
- http://lkml.org/lkml/2008/4/10/88
- http://lkml.org/lkml/2008/4/10/290
Patches are against x86/latest.
-Jacek
--
| Apr 11, 4:28 am 2008 |
| Jean Delvare | [GIT PULL] i2c fixes for 2.6.25
Linus,
Please pull the i2c subsystem fixes for Linux 2.6.25 from:
git://jdelvare.pck.nerim.net/jdelvare-2.6 i2c-for-linus
drivers/i2c/busses/i2c-davinci.c | 17 ++++++-----------
drivers/i2c/busses/i2c-ibm_iic.c | 2 +-
drivers/i2c/busses/i2c-tiny-usb.c | 12 ++++++++----
3 files changed, 15 insertions(+), 16 deletions(-)
---------------
Paul Mundt (1):
i2c-ibm_iic: Fast mode parm desc fixup
Till Harbaum (1):
i2c-tiny-usb: New VID/PID pair
Troy Kisky ...
| Apr 11, 3:22 am 2008 |
| 張佳盈 | 校園網路二手書店-歡迎你來尋寶
↓?▼↖◆▼×♀
﹦校園網路二手書店-歡迎你來尋寶↓
http://book.sam.com.tw/
這是一個完全免費開放的二手書買賣平台
現在註冊還送1,000點註冊金(相當於台幣$1,000喔)
有書要出清的歡迎PO上來賣吧^.^
當然想買書的人也歡迎上來尋寶阿^^
∴?←■⊙▼∴⊕
| Apr 11, 3:03 am 2008 |
| Dimitri Gorokhovik | Re: [RFC][PATCH] HPET: register additional counter-only ...
Right. I hesitated to put it in, but multiple #ifdef/endif clutter too
much the resulting code. Something better should be devised in this
case, like separating the added code into another file, changing a
couple of symbols from static to extern etc.
However, why people wanted the original 'mmap' of /dev/hpet to be
disabled? Probably to prevent the HPET registers from poking with? Gain
in code size is too small, can't think it was the primary reason. If so,
Good point. The patch would be ...
| Apr 11, 7:06 am 2008 |
| Dimitri Gorokhovik | [RFC][PATCH] HPET: register additional counter-only char ...
Hi,
I need to have many processes all reading from userspace the counter register
of the (same) HPET hardware. Just reading counter values, not handling timers,
enabling/disabling interrupts etc. `/dev/hpet' doesn't allow for this, as the
number of times it can be opened is limited by the number of timers available.
What would be the right way to implement such a support? For now, I simply
register a new misc device, '/dev/hpetctr', along with '/dev/hpet', for the same
ACPI device and on ...
| Apr 11, 1:58 am 2008 |
| Clemens Ladisch | Re: [RFC][PATCH] HPET: register additional counter-only ...
Indeed. The driver assumes that userspace wants to program its own
timer (like an RTC device). Allowing mmap() on the hardware counter was
Your patch circumvents CONFIG_HPET_MMAP.
Another possibility would be to allow the device to be opened
infinitely many times but not to allocate a hardware timer until one of
the ioctls is called. This means that opening /dev/hpet does not
guarantee that a timer is available, but this has already been possible
previously because request_irq() might ...
| Apr 11, 6:20 am 2008 |
| Clemens Ladisch | Re: [RFC][PATCH] HPET: register additional counter-only ...
Reading HPET registers should not be dangerous in any way, but it might
be possible to read other devices' registers that happen to lie inside
Yes, definitely. I've wanted to do this patch for some time but haven't
There are at least as many available timers as before the change -- a
program that tries to use a timer will still get a timer, and now this
will succeed even if there are other programs that use only the counter.
Even now, for most programs using /dev/hpet, it actually is just ...
| Apr 11, 8:57 am 2008 |
| rae l | iowait stability regressed from kernel 2.6.22 under heav ...
I found a problem with the vanilla kernel from 2.6.22 (include 23, 24):
the situation is to test a customized linux distribution under heavy IO load:
1. the client process initiates tens of POSIX threads (using
libpthread), each thread uses aio_write or aio_read(using librt)
operating
on one small file, then close it and write another small file;
the whole objective is to get a maxium throughput of small files,
by generating heavy aio stress on the system;
I have tested the vanilla ...
| Apr 11, 2:17 am 2008 |
| David Brownell | Re: [PATCH] GPIO: #include <linux/kernel.h> for might_sleep
That's a pretty unusual policy. Not one that's generally
So include <linux/kernel.h> first. There *is* a policy
of avoiding extra #includes ... extras slow down builds.
- Dave
--
| Apr 11, 10:05 am 2008 |
| Uwe Kleine-König | [PATCH] GPIO: #include <linux/kernel.h> for might_sleep
Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
---
Hello David,
I like having headers being independend of the order of inclusion.
Usually I order all includes alphabetically (and grouped by linux/,
asm/, etc.). This doesn't work with gpio.h because then kernel.h is
included to late.
Best regards
Uwe
include/asm-generic/gpio.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index ...
| Apr 11, 1:24 am 2008 |
| Uwe | Re: [PATCH] GPIO: #include <linux/kernel.h> for might_sleep
Hello again,
I just noticed that you need include/asm/types.h also for the
CONFIG_HAVE_GPIO_LIB=y case. So the #include can better go to the top
of include/asm-generic/gpio.h.
I won't send a new version untill you say if it's OK for you to add
#includes to that header.
Best regards
Uwe
--
Uwe Kleine-König, Software Engineer
Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany
Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962
--
| Apr 11, 3:46 am 2008 |
| Nick Piggin | Re: [patch 11/17] hugetlbfs: support larger than MAX_ORDER
Ah, hmm, I might have missed a couple of emails worth of feedback when
you last posted. Thanks for pointing this out, I'll read over them again.
--
| Apr 11, 1:59 am 2008 |
| Andi Kleen | Re: [patch 11/17] hugetlbfs: support larger than MAX_ORDER
As Andrew Hastings pointed out earlier this all needs to be h->order < MAX_ORDER
[got pretty much all the checks wrong off by one]. It won't affect anything
on x86-64 but might cause problems on archs which have exactly MAX_ORDER
-Andi
--
| Apr 11, 1:13 am 2008 |
| Nick Andrew | [PATCH 1/2] RAID: Remove leading TAB on printk messages
RAID: Remove leading TAB on printk messages
MD drivers use one printk() call to print 2 log messages and the second
line may be prefixed by a TAB character. It may also output a trailing
space before newline. klogd (I think) turns the TAB character into the
2 characters '^I' when logging to a file. This looks ugly.
Instead of a leading TAB to indicate continuation, prefix both output
lines with 'raid:' or similar. Also remove any trailing space in the
vicinity of the affected code and ...
| Apr 11, 1:06 am 2008 |
| Nick Andrew | [PATCH 2/2] RAID: remove trailing space from printk line
RAID: remove trailing space from printk line
drivers/md/*.[ch] contains only one more printk line with a trailing space.
Remove it.
Signed-off-by: Nick Andrew <nick@nick-andrew.net>
---
drivers/md/md.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 61ccbd2..5ebfb4d 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -4152,7 +4152,7 @@ static int hot_remove_disk(mddev_t * mddev, dev_t dev)
return 0;
...
| Apr 11, 1:07 am 2008 |
| Michal Simek | microblaze: Merge window + git
Hi everybody,
Can you tell me when is open next merge window?
and my next question is about GIT.
I have second release at my git server and I have some changes which you
reported. I would like to collect all changes in the same set of patches.
I mean I have patch with 4 files and I did next changes. I would like to
integrate these changes to the same patches. Is it possible to do it?
It is easier to review all changes together.
I think it is no good way to send first release with ...
| Apr 11, 12:50 am 2008 |
| Stefan Richter | Re: microblaze: Merge window + git
You can combine several commits into one in a few ways. Of course the
combined commit is an entirely new one (with its own SHA1 etc.). One
possible way:
# you are at <commit0>
$ git cherry-pick --no-commit <commit1> # apply but don't commit yet
$ git cherry-pick --edit <commit2> # apply, edit the changelog, commit
There will now be a <commit3> whose parent is <commit0>. <commit3>
incorporates changes of <commit1> and <commit2>.
Another way:
# you are at <commit0>
$ patch < ...
| Apr 11, 3:51 am 2008 |
| Ilpo Järvinen | Re: microblaze: Merge window + git
If you have a tree which has those four commits on top, it's rather easy
with git:
$ git-reset --soft HEAD^^^
$ git-commit --amend
...In order the git-reset --soft to leave the index into the desired
state, no pending stuff should be in index before beginning (index
is the thing controlled with cmds like git-add/git-update-index/etc.).
...The commit's message is taken from the bottommost of those four
original commits.
--
i.
--
| Apr 11, 5:45 am 2008 |
| Takenori Nagano | [PATCH 2/2] implement new notifier function to panic_not ...
This patch implements new notifier function to panic_notifier_list. We can
change the list of order by debugfs.
Thanks,
---
Signed-off-by: Takenori Nagano <t-nagano@ah.jp.nec.com>
---
diff -uprN linux-2.6.25-rc8-mm1.orig/arch/alpha/kernel/setup.c linux-2.6.25-rc8-mm1/arch/alpha/kernel/setup.c
--- linux-2.6.25-rc8-mm1.orig/arch/alpha/kernel/setup.c 2008-04-02 04:44:26.000000000 +0900
+++ linux-2.6.25-rc8-mm1/arch/alpha/kernel/setup.c 2008-04-10 21:30:16.143555075 +0900
@@ -44,14 +44,18 ...
| Apr 11, 12:53 am 2008 |
| Takenori Nagano | [PATCH 0/2] add new notifier function ,take3
Hi,
A big thanks to everybody who read and replied to previous version.
changelog take2 -> take3
- Rebased 2.6.25-rc8-mm1
- comment updated
- renamed the notifiner name "tunable_notifier" to "tunable_atomic_notifier"
- fixed typo
- move control files debugfs to /sys/kernel
These patches add new notifier function and implement it to panic_notifier_list.
We used the hardcoded notifier chain so far, but it was not flexible. New
notifier is very flexible, because user can change a list of ...
| Apr 11, 12:53 am 2008 |
| Greg KH | Re: [PATCH 1/2] add tunable_notifier function ,take2
You are adding sysfs files, not debugfs files, please change your
announcement text.
Also, as you are adding new sysfs files, we need some documentation to
be added to Documentation/ABI/ describing what these files are, what are
in them, and how to use them.
thanks,
greg k-h
--
| Apr 11, 12:55 pm 2008 |
| Takenori Nagano | [PATCH 1/2] add tunable_notifier function ,take2
This patch adds new notifier function tunable_notifier_chain. Its base is
atomic_notifier_chain.
Thanks,
---
Signed-off-by: Takenori Nagano <t-nagano@ah.jp.nec.com>
---
diff -uprN linux-2.6.25-rc8-mm1.orig/include/linux/notifier.h linux-2.6.25-rc8-mm1/include/linux/notifier.h
--- linux-2.6.25-rc8-mm1.orig/include/linux/notifier.h 2008-04-08 16:37:43.700000000 +0900
+++ linux-2.6.25-rc8-mm1/include/linux/notifier.h 2008-04-09 20:01:10.328000000 +0900
@@ -13,6 +13,7 @@
#include ...
| Apr 11, 12:53 am 2008 |
| Nick Piggin | Re: [bug] mm/slab.c boot crash in -git, "kernel BUG at m ...
BTW. I think I'm seeing some problems perhaps related to change page
attr stuff for DEBUG_PAGEALLOC on x86-64. And I don't know if it is the
same thing, but some general instability around either the page allocator
or slab allocator.
The debug pagealloc problems seem to be that a thread suddenly get stuck
in the kernel spinning in cpa (usually on one of the locks) and never
seems to recover. Once it seemed to be spinning in clear_page_... too,
but perhaps could it be messing up the page ...
| Apr 11, 3:34 am 2008 |
| Pekka Enberg | Re: [bug] mm/slab.c boot crash in -git, "kernel BUG at m ...
Hi Ingo,
As mentioned privately, I suspect it's the page allocator changes that
went into 2.6.24. Mel, Christoph, any ideas?
--
| Apr 11, 1:21 am 2008 |
| Pekka Enberg | Re: [bug] mm/slab.c boot crash in -git, "kernel BUG at m ...
So I'm thinking it's probably related to this patch:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=523b94...
As kmalloc_node() in setup_cpu_cache() returns NULL, it seems likely
to be due to the use of GFP_THISNODE in cache_alloc_refill() when
calling cache_grow() and that the semantics changed. No idea why page
allocator would think your UMA "local node" has no memory though.
Pekka
--
| Apr 11, 1:50 am 2008 |
| Ingo Molnar | [bug] mm/slab.c boot crash in -git, "kernel BUG at mm/sl ...
our x86.git randconfig auto-qa found a mm/slab.c early-bootup crash in
mainline that got introduced since v2.6.24.
http://redhat.com/~mingo/misc/log-Thu_Apr_10_10_41_16_CEST_2008.bad
http://redhat.com/~mingo/misc/config-Thu_Apr_10_10_41_16_CEST_2008.bad
Note, the very same bzImage does not crash on other testboxes - only on
this 8-way box with 4GB of RAM.
i tried a "use v2.6.24's slab.c" revert (with a few API fixes needed for
it to build on .25) but that didnt solve the problem ...
| Apr 11, 12:41 am 2008 |
| Ingo Molnar | Re: [bug] mm/slab.c boot crash in -git, "kernel BUG at m ...
but ... as i said it in my report, this is a regression since v2.6.24 -
v2.6.24 (and a whole bunch of commits since then, i listed the IDs)
booted up fine. The commit ID you mention is: v2.6.23-4345-g523b945, way
earlier than the good commit IDs.
so this is a recent regression.
Ingo
--
| Apr 11, 1:54 am 2008 |
| Ingo Molnar | Re: [bug] mm/slab.c boot crash in -git, "kernel BUG at m ...
yeah, sorry - we are working hard to unify generic bits like that, but
it's a huge architecture.
btw., i always felt that the zone/memory setup is rather fragile and
ad-hoc in places and it trusts the architecture code too much. Just in
the .25 cycle i've seen about a dozen bugs all around that thing. I
believe we should work on making the info that an architecture feeds to
the MM "fool proof" - i.e. sanity-check for overlaps and other common
setup errors. It is easy for an ...
| Apr 11, 2:24 am 2008 |
| Pekka Enberg | Re: [bug] mm/slab.c boot crash in -git, "kernel BUG at m ...
And I'd lose as you're 32-bit. Oh well, that's the price to pay for
pretending to know x86 arch internals.
--
| Apr 11, 2:11 am 2008 |
| Christoph Lameter | Re: [bug] mm/slab.c boot crash in -git, "kernel BUG at m ...
I also have an internal report that x86-git causes boot to fail with an 8p
if one starts with a x86_64 config file and then converts to
x86_32. Somehow the NR_CPUS is set to 255 in that case. Could this
exhaust memory? I guess the per cpu cleanup work may figure in that area.
Mike?
--
| Apr 11, 12:25 pm 2008 |
| Pekka Enberg | Re: [bug] mm/slab.c boot crash in -git, "kernel BUG at m ...
I'd be willing to put some money on this:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b7ad14...
--
| Apr 11, 2:08 am 2008 |
| Christoph Lameter | Re: [bug] mm/slab.c boot crash in -git, "kernel BUG at m ...
Could you post the zone setup of the system that fails? A memory map would
be useful and full dmesg output up to the failure.
--
| Apr 11, 12:28 pm 2008 |
| Christoph Lameter | Re: [bug] mm/slab.c boot crash in -git, "kernel BUG at m ...
Allowing systems without node 0 is a major change for x86.
--
| Apr 11, 12:26 pm 2008 |
| Pekka Enberg | Re: [bug] mm/slab.c boot crash in -git, "kernel BUG at m ...
Hi Ingo.
Right. Then you probably want to look into any changes in arch/x86/
related to setting up the zonelists. I'm fairly certain this is not a
slab bug and I don't see any recent changes to the page allocator
either that would explain this.
--
| Apr 11, 2:05 am 2008 |
| Randy Dunlap | Re: linux-next: Tree for April 11 (x86-es7000)
In mainline, x86-32-subarch es7000 builds cleanly.
.config attached. (CONFIG_ACPI=n)
In linux-next, the same .config (with minimal -next changes) fails:
arch/x86/mach-es7000/built-in.o: In function `es7000_rename_gsi':
next-20080411/arch/x86/mach-es7000/es7000plat.c:64: undefined reference to `es7000_plat'
arch/x86/mach-es7000/built-in.o: In function `setup_unisys':
next-20080411/arch/x86/mach-es7000/es7000plat.c:89: undefined reference to ...
| Apr 11, 2:45 pm 2008 |
| Stephen Rothwell | linux-next: Tree for April 11
Hi all,
Changes since next-20080411:
No need for libata-fix-1 (a typo fixup)
New conflicts in XFS (caused by some XFS patches being merged upstream and
also existing in the xfs tree - trivial).
Added a small Kconfig patch for powerpc to make allmodconfig build (I expect
to be added to the powerpc next tree shortly).
----------------------------------------------------------------------------
I have created today's linux-next tree ...
| Apr 11, 12:36 am 2008 |
| Mike Galbraith | latencytop kills volanomark throughput. yawn?
Greetings list,
The moral of this story is probably "don't do that", but...
While doing some scheduler testing recently, I ran volanomark, and
accidentally left latencytop running. The results were decidedly
un-good, and the reason appears to be that MUCH time is spent crawling
over a list of (106 loaded) modules.
-Mike
| Apr 10, 11:47 pm 2008 |
| Thomas Gleixner | Re: regression caused by: genirq: do not leave interupts ...
So forcedeth does not come up again, when you kexec from linus.git
into an older distro kernel. Or is it the other way round ?
Which causes an interrupt storm on the enabled irq line, when the
interrupt line is still active for whatever reason. So we trade one
badness vs. the other.
Reverting the patch is not going to give us any answer about the real
problem.
Is there anything in dmesg, which might give us an hint about that ?
Thanks,
tglx
--
| Apr 11, 12:01 am 2008 |
| Yinghai Lu | regression caused by: genirq: do not leave interupts ena ...
last week found:
after latest kernel kexec RHEL 5.1 or other stack kernel, the nvidia
forcedeth doesn't work anymore.
I stared at forcedeth.c two days. and revert every patches about that
doesn't help.
and figure out 2.6.25-rc2 works.
with git-bisect found
commit 89d694b9dbe769ca1004e01db0ca43964806a611
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Mon Feb 18 18:25:17 2008 +0100
genirq: do not leave interupts enabled on free_irq
The default_disable() function was ...
| Apr 10, 11:13 pm 2008 |
| Yinghai Lu | Re: regression caused by: genirq: do not leave interupts ...
the forcedeth can not get IP address...
YH
--
| Apr 11, 12:17 am 2008 |
| Yinghai Lu | Re: regression caused by: genirq: do not leave interupts ...
On Fri, Apr 11, 2008 at 12:30 AM, Eric W. Biederman
mcp55 is using msi for forcedeth
MSI.. will look at the driver in RHEL 5.1
it seems that another server with ck804 works because it is using ioapic.
YH
--
| Apr 11, 1:40 am 2008 |
| Yinghai Lu | Re: regression caused by: genirq: do not leave interupts ...
it is RHEL 5.1 problem...with msi.
somehow msi entry msi_attrib_maskbit=is_mask_bit_support always get
0...., and use msi_irq_wo_maskbit_type instead of
msi_irq_w_maskbit_type
so when load that directly without kexec
that 0x60 always to 0x00.
and this time kernel after 2.6.25-rc2 ( not included) really shutdown
the msi with 0xff the all maskbit...
YH
--
| Apr 11, 12:48 pm 2008 |
| Rafael J. Wysocki | Re: regression caused by: genirq: do not leave interupts ...
I've just got a report from a forcedeth user that it doesn't work after a
resume from RAM for him any more. Can it be related?
Rafael
--
| Apr 11, 8:19 am 2008 |
| Thomas Gleixner | Re: regression caused by: genirq: do not leave interupts ...
Hmm, we disable the interrupt on free_irq(), but we reenable it in
request_irq()/setup_irq(), which is called when the forcedeth driver
initializes in the kexeced kernel. So there is some other deeper down
problem lurking.
Yinghai, can you apply that patch to RHEL 5.1 and check, what happens
if you do:
modprobe forcedeth
ifup ...
ifdown ...
rmmod forcedeth
modprobe forcedeth
ifup ...
This should result in the same problem, but probably simpler to debug.
Thanks,
tglx
--
| Apr 11, 3:31 am 2008 |
| Daniel Barkalow | Re: regression caused by: genirq: do not leave interupts ...
When turning on MSI for forcedeth, we do the INTx disable thing (and it's
actually necessary for at least some forcedeth-driven hardware); if we're
not disabling MSI (and making INTx undisabled), the old kernel may not
undisable INTx but expect to have legacy interrupts delivered.
-Daniel
*This .sig left intentionally blank*
--
| Apr 11, 8:59 am 2008 |
| Yinghai Lu | Re: regression caused by: genirq: do not leave interupts ...
then another path that missing enable irq..
YH
--
| Apr 11, 9:23 am 2008 |
| Eric W. Biederman | Re: regression caused by: genirq: do not leave interupts ...
Sounds like you are not getting any interrupts when you receive a
packet. (i.e. The interrupt line is staying disabled).
Is MSI an option here? I'm wondering if we disable the MSI and
something is not enabling it.
Eric
--
| Apr 11, 12:30 am 2008 |
| Yinghai Lu | Re: regression caused by: genirq: do not leave interupts ...
RHEL 5.1 kexec RHEL 5.1 : works
RHEL 5.1 kexec linus kernel: works
linus (after -rc2) kexec linus tree: works:
linus (after -rc2) kexec RHEL 5.1 : forcedeth will not come up
everything looks normal.
YH
--
| Apr 11, 12:14 am 2008 |
| Yinghai Lu | Re: regression caused by: genirq: do not leave interupts ...
On Fri, Apr 11, 2008 at 12:30 AM, Eric W. Biederman
after
setpci -s 0x00:08.0 0x60.b=0xfe
the eth0 can get ip address with ifup eth0.
YH
| Apr 11, 11:22 am 2008 |
| David Miller | Re: [PATCH] reorganize <linux/linkage.h>
From: Linus Torvalds <torvalds@linux-foundation.org>
A lot of it is probably simply copy and paste from other ports.
When I removed it from Sparc long ago, the only issue I had was that
there were some things using "/**/" concatenation in some sparc
assembler CPP macros, and those were easily fixed.
--
| Apr 11, 11:26 am 2008 |
| Kyle McMartin | [PATCH] reorganize <linux/linkage.h>
Commit 54a015104136974262afa4b8ddd943ea70dec8a2 adds some new magic
asmlinkage_protect gizmo, but that can only be used from C code, not
assembly. Protect relevant bits of <linux/linkage.h> with !__ASSEMBLY__
so this can't leak into assembly source.
Fixes a couple build errors on my boxes,
AS arch/parisc/kernel/pacache.o
In file included from arch/parisc/kernel/pacache.S:40:
include/linux/linkage.h:34: error: syntax error in macro parameter list
make[1]: *** ...
| Apr 10, 10:00 pm 2008 |
| Linus Torvalds | Re: [PATCH] reorganize <linux/linkage.h>
Ok, so s390 had a similar issue, and I assumed that they were just usign a
broken C pre-processor for asm, but now I'm starting to wonder about it.
Why cannot your pre-processor handle that thing?
It doesn't matter if it is C or assembly, the pre-processor should be the
same. That #define isn't used for asm, so it shouldn't _matter_ for asm.
What's going on?
I'm starting to suspect that it's the fact that some architectures still
have
EXTRA_AFLAGS := -traditional
or ...
| Apr 11, 7:58 am 2008 |
| David Brownell | [patch 2.6.25-rc8] mmc: fix platform driver hotplug/coldplug
From: Kay Sievers <kay.sievers@vrfy.org>
Since 43cc71eed1250755986da4c0f9898f9a635cb3bf, the platform
modalias is prefixed with "platform:". Add MODULE_ALIAS() to the
hotpluggable MMC host platform drivers, to re-enable auto loading.
Also, add missing owner declarations in driver init.
[ dbrownell@users.sourceforge.net: registration fixes ]
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
---
drivers/mmc/host/at91_mci.c | ...
| Apr 10, 9:46 pm 2008 |
| David Brownell | [patch 2.6.25-rc8] omap_rng minor updates
Minor cleanups to the OMAP RNG:
- Comment update re RNG status:
* yes, it works on 16xx; "rngtest" is quite happy
* it's fast enough that polling vs IRQ is a non-issue
- Get rid of BUG_ON
- Help GCC not be stupid about inlining (object code shrink)
- Remove "sparse" warning
- Cope with new hotplug rule requiring "platform:" modalias
And make the file header match kernel conventions.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
---
...
| Apr 10, 9:32 pm 2008 |
| Cyrill Gorcunov | Re: [PATCH 1/2] kernel: add common infrastructure for un ...
[Harvey Harrison - Thu, Apr 10, 2008 at 08:38:57PM -0700]
[...]
| +
| +static inline void __put_unaligned_be16(u16 val, u8 *p)
| +{
| + *p++ = val >> 8;
| + *p++ = val;
| +}
| +
[...]
| +static inline void __put_unaligned_le16(u16 val, u8 *p)
| +{
| + *p++ = val;
| + *p++ = val >> 8;
| +}
[...]
Hi Harvey, do we really need second increments? I mean, wouldn't
be better to use *p = val >> 8 and *p << 8?
- Cyrill -
--
| Apr 11, 1:22 pm 2008 |
| Harvey Harrison | [PATCH 1/2] kernel: add common infrastructure for unalig ...
Create a linux/unaligned folder similar in spirit to the linux/byteorder
folder to hold generic implementations collected from various arches.
Currently there are five implementations:
1) cpu_endian.h: C-struct based, from asm-generic/unaligned.h
2) little_endian.h: Open coded byte-swapping, heavily based on asm-arm
3) big_endian.h: Open coded byte-swapping, heavily based on asm-arm
4) no_builtin_memcpy.h: taken from multiple implementations in tree
5) access_ok.h: taken from x86 and others, ...
| Apr 10, 8:38 pm 2008 |
| David Miller | Re: [PATCH 2/2] kernel: Move arches to use common unalig ...
From: David Howells <dhowells@redhat.com>
No, I think it has something to do with what cases GCC is allowed to
optimize the call inline and what cases it cannot wrt. alignment of
datums.
--
| Apr 11, 3:16 am 2008 |
| David Howells | Re: [PATCH 2/2] kernel: Move arches to use common unalig ...
But not M68K(NOMMU), Alpha, Blackfin, Cris, H8300, MN10300, ..., but generally
consistent with the other FRV headers (some other people have added differ).
Hmmm... It looks like MIPS is weird. That says __ASM_GENERIC_UNALIGNED_H,
which is probably wrong.
David
--
| Apr 11, 8:50 am 2008 |
| Harvey Harrison | Re: [PATCH 2/2] kernel: Move arches to use common unalig ...
OK, just let me know what you decide. I'm stil open to bringing back
I suppose an out-of-line version could be easily added to accomplish
this. It would be identical to the byteshifting implementation-wise.
Let me know if you'd like me to spin such a patch.
Harvey
--
| Apr 11, 8:19 am 2008 |
| Ingo Molnar | Re: [PATCH 2/2] kernel: Move arches to use common unalig ...
nice work - the x86 bits and the general concept:
Acked-by: Ingo Molnar <mingo@elte.hu>
Ingo
--
| Apr 11, 12:48 am 2008 |
| David Howells | Re: [PATCH 2/2] kernel: Move arches to use common unalig ...
That's memmove, not memmov. Any why memmove, not memcpy? Is __tmp likely to
overlap with *ptr?
Also, for FRV, I think calling memmove/memcpy for MMU kernels may be the wrong
thing to do... I'm sort of leaning towards doing the same thing as NOMMU
kernels and just using your inline ones.
The advantage of the inline ones is that they are quicker and probably involve
fewer instructions executed; whereas using memcpy/memmove may end up with
smaller, but slower code. Hmmm... Maybe key on ...
| Apr 11, 3:11 am 2008 |
| David Howells | Re: [PATCH 2/2] kernel: Move arches to use common unalig ...
As he says in his comment, in fact.
David
--
| Apr 11, 3:27 am 2008 |
| Harvey Harrison | Re: [PATCH 2/2] kernel: Move arches to use common unalig ...
Well, now's the time to decide on something as I'm changing every arch.
What is the general pattern used for this kind of thing? Or am I just
asking what color to paint this bikeshed?
Harvey
--
| Apr 11, 10:31 am 2008 |
| Harvey Harrison | [PATCH 2/2] kernel: Move arches to use common unaligned access
Unaligned access is ok for the following arches:
cris, m68k, mn10300, powerpc, s390, x86
Arches that use the no-builtin-memcpy implementation:
h8300, m32r, xtensa
generic_le:
alpha, blackfin, ia64,
generic_be:
parisc, sparc, sparc64
generic_le or be, choice based on compiler flags:
mips, sh
m86knommu is generic_be for Coldfire, otherwise unaligned access is ok.
frv uses the no_builtin_memcpy implementation when there is an MMU
configured, otherwise uses the generic be ...
| Apr 10, 8:38 pm 2008 |
| Harvey Harrison | Re: [PATCH 2/2-revised] kernel: Move arches to use commo ...
Unaligned access is ok for the following arches:
cris, m68k, mn10300, powerpc, s390, x86
Arches that use the no-builtin-memcpy implementation:
h8300, m32r, xtensa
generic_le:
alpha, blackfin, ia64,
generic_be:
parisc, sparc, sparc64
generic_le or be, choice based on compiler flags:
mips, sh
m86knommu is generic_be for Coldfire, otherwise unaligned access is ok.
frv uses the no_builtin_memcpy implementation when there is an MMU
configured, otherwise uses the generic be ...
| Apr 11, 10:55 am 2008 |
| KAMEZAWA Hiroyuki | Re: 2.6.25-rc8-mm2
On Fri, 11 Apr 2008 18:57:03 +0900
with slub_nomerge , booted.
Thanks,
-Kame
--
| Apr 11, 3:23 am 2008 |
| Alexey Dobriyan | Re: 2.6.25-rc8-mm2: boot hang after "ACPI: using IOAPIC ...
nomerge doesn't help as well as turning on combinations of SLUB debug options.
--
| Apr 11, 2:07 pm 2008 |
| KAMEZAWA Hiroyuki | Re: 2.6.25-rc8-mm2
On Thu, 10 Apr 2008 20:33:54 -0700
On ia64/NUMA box (which has empty nodes.)
CONFIG_SLAB ..... booted well
CONFIG_SLUB ..... can't boot
CONFIG_SLUB + CONFIG_SLUB_DEBUG_ON .... booted. Hmm?
I'll dig more if I can.
2.6.25-rc8-mm1 had no troubles.
Thanks,
-Kame
--
| Apr 11, 2:57 am 2008 |
| Pekka Enberg | Re: 2.6.25-rc8-mm2: boot hang after "ACPI: using IOAPIC ...
Hi Alexey,
That's odd. I don't immediately see anything there that can cause a
this... Can you see the hang with the 'for-mm' branch of my tree:
git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6.git
If so, can you do a git bisect? Does sysrq-t tell us anything?
Pekka
--
| Apr 10, 11:43 pm 2008 |
| Adrian Bunk | Re: 2.6.25-rc8-mm2
Is this due to the generic_find_next_le_bit compile error I reported as
2.6.25 regression (there seems to be some discussion recently how to
fix it - hopefully for 2.6.25) or is there even more breakage in -mm?
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
| Apr 11, 6:40 am 2008 |
| Alexey Dobriyan | 2.6.25-rc8-mm2: boot hang after "ACPI: using IOAPIC for ...
I bisected boot hang after "ACPI: using IOAPIC for interrupt routing"
down to git-pekka.
normal dmesg from 2.6.25-rc8-something and .config snippets for -mm
# CONFIG_SLUB_DEBUG is not set (hey, I thought this was on!)
CONFIG_SLUB=y
# CONFIG_SLUB_STATS is not set
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_DEBUG_FS is not ...
| Apr 10, 11:29 pm 2008 |
| Andrew Morton | 2.6.25-rc8-mm2
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc8/2.6.25-rc8-mm2/
- Compilation is busted on mips due to the page-flags patches
- Compilation is busted on sparc64 due to the page-flags patches
- Compilation is partially busted on powerpc due to the page-flags patches.
It compiles for my g5 but allmodconfig fails.
- git-drm is dropped due to build errors
- git-xfs is dropped due to failure to get a clean git diff
- git-slub has been temporarily replaced by ...
| Apr 10, 8:33 pm 2008 |
| Alexey Dobriyan | 2.6.25-rc8-mm2: boot hang after "ACPI: using IOAPIC for ...
I bisected boot hang after "ACPI: using IOAPIC for interrupt routing"
down to git-pekka.
normal dmesg from 2.6.25-rc8-something and .config snippets for -mm
# CONFIG_SLUB_DEBUG is not set (hey, I thought this was on!)
CONFIG_SLUB=y
# CONFIG_SLUB_STATS is not set
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_DEBUG_FS is not ...
| Apr 10, 11:28 pm 2008 |
| Pekka J Enberg | Re: 2.6.25-rc8-mm2: boot hang after "ACPI: using IOAPIC ...
Does the following patch fix it?
Pekka
From 7c7e7e5e7ec07c0a47705b2d21c779c39ba02252 Mon Sep 17 00:00:00 2001
From: Pekka Enberg <penberg@cs.helsinki.fi>
Date: Fri, 11 Apr 2008 17:17:43 +0300
Subject: [PATCH] slub: add missing slab_unlock() to __kmem_cache_shrink()
If page is not kickable, remember to slab_unlock() before continuing the loop.
Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>
---
mm/slub.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff ...
| Apr 11, 2:25 pm 2008 |
| KAMEZAWA Hiroyuki | Re: 2.6.25-rc8-mm2
On Fri, 11 Apr 2008 20:17:24 +0900
Sorry, I tested *master* branch ;), under *testing* branch it reproduced.
bisected. (see below)
I'm sorry I can't use my box for next 2 days. I can test possible fix
on Monday (in Japan).
==bisect result==
831d78b552aade2c383cf8d75b180dd35f81a4e3 is first bad commit
commit 831d78b552aade2c383cf8d75b180dd35f81a4e3
Author: Christoph Lameter <clameter@sgi.com>
Date: Tue Apr 8 22:26:30 2008 +0300
SLUB: Add KICKABLE to avoid repeated kick() ...
| Apr 11, 6:17 am 2008 |
| Pekka Enberg | Re: 2.6.25-rc8-mm2
What happens when it doesn't boot? Does it hang or do you get an oops?
Can you reproduce it with the 'for-mm' branch of:
git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6.git
Pekka
--
| Apr 11, 3:34 am 2008 |
| KAMEZAWA Hiroyuki | Re: 2.6.25-rc8-mm2
On Fri, 11 Apr 2008 13:34:18 +0300
will try.
Thanks,
-Kame
--
| Apr 11, 3:57 am 2008 |
| Alexey Dobriyan | 2.6.25-rc8-mm2: panic involving mount_block_root and dow ...
Pekka fixed SLUB for me, and now core2 box survives up and including to
not finding / :
Setup is SATA disk with plain old partitions, nothing lvmancy:
/dev/sda2 on / type ext3 (rw,noatime)
CONFIG_ATA=y
CONFIG_ATA_ACPI=y
CONFIG_SATA_AHCI=y
CONFIG_ATA_PIIX=y
CONFIG_PATA_JMICRON=y
sda1 is for swap.
[ 3.920000] NET: Registered protocol family 1
[ 3.920000] VFS: Cannot open root device "sda2" or unknown-block(0,0)
[ 3.920000] Please append a correct "root=" boot option; here ...
| Apr 11, 4:43 pm 2008 |
| Pekka Enberg | Re: 2.6.25-rc8-mm2: boot hang after "ACPI: using IOAPIC ...
Alexey, can you try passing the 'slub_nomerge' option to the kernel to
see if the hang goes away with that?
Pekka
--
| Apr 11, 3:35 am 2008 |
| KAMEZAWA Hiroyuki | Re: 2.6.25-rc8-mm2
On Fri, 11 Apr 2008 19:57:38 +0900
slab-2.6.git booted well :(
Hmm, It seems I have to dig somewhere different...
Thanks,
-Kame
--
| Apr 11, 4:17 am 2008 |
| Pekka Enberg | Re: 2.6.25-rc8-mm2
My bad, sorry. Fixed and pushed out.
From: Pekka Enberg <penberg@cs.helsinki.fi>
Date: Fri, 11 Apr 2008 17:17:43 +0300
Subject: [PATCH] slub: add missing slab_unlock() to __kmem_cache_shrink()
If page is not kickable, remember to slab_unlock() before continuing the loop.
Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>
---
mm/slub.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/mm/slub.c b/mm/slub.c
index 4b694a7..f09f1fb 100644
--- a/mm/slub.c
+++ ...
| Apr 11, 7:24 am 2008 |
| Alexey Dobriyan | Re: 2.6.25-rc8-mm2: boot hang after "ACPI: using IOAPIC ...
Yes, it helps. Now I have some more bugs to report. :-(
--
| Apr 11, 4:09 pm 2008 |
| Mikulas Patocka | Re: Data corruption on software RAID
It can already happen that one device writes the sector and other not if
the power is interrupted. And all RAID implementations already deal with
it by resynchronizing the modified areas in case of crash. So they could
resynchronize modify-while-write cases as well, with the same code.
... or I don't know if MM maintainers want to add locking to the pages
There would be no problem with fsync. Fsync writes the synced data to both
devices. So after a crash you can select any of the ...
| Apr 10, 7:55 pm 2008 |
| Josef 'Jeff' Sipek | Guilt: Autotagging - aye or nay?
Greetings all!
I was trying to figure out what the default for Guilt's autotagging feature
should be. Currently, the default is for it to be on, unless it's
overridden by an already existing config setting.
For those who may not be familiar with autotagging, here's an excerpt from
the guilt(7) man page:
Autotagging is a feature that automatically creates unannotated tags
for top, bottom, and base of the stack.
On every push or pop operation (refresh is a pop followed by a
push), ...
| Apr 10, 5:26 pm 2008 |
| Josef 'Jeff' Sipek | [ANNOUNCE] Guilt v0.30
Guilt v0.30 is available for download (once it mirrors out on kernel.org).
Guilt (Git Quilt) is a series of bash scripts which add a Mercurial
queues-like functionality and interface to git.
Tarballs:
http://www.kernel.org/pub/linux/kernel/people/jsipek/guilt/
Git repo:
git://git.kernel.org/pub/scm/linux/kernel/git/jsipek/guilt.git
As promissed, this version includes some interesting changes. The major one
being the status file now has a new format. The motivation for this was ...
| Apr 10, 5:01 pm 2008 |
| Nish Aravamudan | Re: [patch 00/17] multi size, and giant hugetlb page sup ...
[Trimming Andi's SUSE address, as it gave me permanent failures on my
last message]
Just FYI, we tagged 1.3-pre1 today and it's out now:
http://libhugetlbfs.ozlabs.org/releases/libhugetlbfs-1.3-pre1.tar.gz.
The kernel tests should work fine on x86 as is, even with 1G pages. I
expect some of the linker script testcases to fail, though, as they
will require alignment changes, I think (Adam is actually reworking
the segment remapping code for libhugetlbfs 2.0, which will release
Agreed, I ...
| Apr 11, 12:57 pm 2008 |
| Nick Piggin | Re: [patch 00/17] multi size, and giant hugetlb page sup ...
Yeah, it should be easy to disable the 2MB default and just make it
look exactly the same but with 1G pages.
Thanks a lot for your suggestion, I'll pull the snapshot over the
weekend and try to make it pass on x86 and work with Jon to ensure it
Yes I don't like the proc interface, nor the way it has been extended
(although that's not Andi's fault it is just a limitation of the old
API).
I think actually we should have individual directories for each hstate
size, and we can put all other ...
| Apr 11, 1:28 am 2008 |
| Linus Torvalds | Re: [PATCH] Fix compile breakage caused by asmlinkage_protect
There are no side effects on asm code. It just adds a #define that
obviously won't be used.
Is the s390 assembler using some strange C pre-processor that is different
from the main C preprocessor and doesn't understand this pattern?
I really think you should fix *that*, because otherwise you'll hit these
kinds of bugs occasionally. There aren't that many asm files, it's not
worth it optimizing them to use some faster-but-stupider preprocessor.
Linus
--
| Apr 11, 7:46 am 2008 |
| Jakub Jelinek | Re: [PATCH] Fix compile breakage caused by asmlinkage_protect
Not if (some) kernel assembly files are preprocessed with -traditional-cpp
or -traditional, which supports neither GNU style arg... nor
ISO C99 ... + __VA_ARGS__ vararg macros.
Jakub
--
| Apr 11, 8:06 am 2008 |
| Martin Schwidefsky | Re: [PATCH] Fix compile breakage caused by asmlinkage_protect
So there is at least one architecture that really requires -traditional,
it is not an option to just remove them. For s390 the kernel compiles
fine without -traditional on the AFLAGS so we can as well remove them.
I'll queue the patch below. In the meantime Heikos patch will have to
do.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
---
[PATCH] s390: remove -traditional from AFLAGS
From: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Martin ...
| Apr 11, 9:03 am 2008 |
| Adrian Bunk | Re: [PATCH] Fix compile breakage caused by asmlinkage_protect
You can simply ditch the line.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
| Apr 11, 10:09 am 2008 |
| Al Viro | Re: [PATCH] Fix compile breakage caused by asmlinkage_protect
FWIW, at least m68k and m32r cross-builds hit the same. I think I've a very
good guess about the reasons:
arch/m32r/kernel/Makefile:EXTRA_AFLAGS := -traditional
arch/m68k/fpsp040/Makefile:EXTRA_AFLAGS := -traditional
arch/m68k/ifpsp060/Makefile:EXTRA_AFLAGS := -traditional
arch/m68k/kernel/Makefile:EXTRA_AFLAGS := -traditional
arch/m68k/lib/Makefile:EXTRA_AFLAGS := -traditional
arch/m68k/math-emu/Makefile:EXTRA_AFLAGS := -traditional
arch/parisc/kernel/Makefile:AFLAGS_entry.o := ...
| Apr 11, 8:11 am 2008 |
| Linus Torvalds | Re: [PATCH] Fix compile breakage caused by asmlinkage_protect
Yeah, I figured it out eventually.
I do think the architectures should try to avoid it, if only because x86
doesn't use -traditional (so they'll hit things like this unnecessarily
otherwise), but I'll apply Heiko's minimal patch in the meantime.
Linus
--
| Apr 11, 8:25 am 2008 |
| Heiko Carstens | [PATCH] Fix compile breakage caused by asmlinkage_protect
From: Heiko Carstens <heiko.carstens@de.ibm.com>
git commit 54a015104136974262afa4b8ddd943ea70dec8a2
"asmlinkage_protect replaces prevent_tail_call" causes this build failure
on s390:
AS arch/s390/kernel/entry64.o
In file included from arch/s390/kernel/entry64.S:14:
include/linux/linkage.h:34: error: syntax error in macro parameter list
make[1]: *** [arch/s390/kernel/entry64.o] Error 1
make: *** [arch/s390/kernel] Error 2
So just surround the new define with an #ifndef __ASSEMBLY__ ...
| Apr 11, 4:46 am 2008 |
| Kyle McMartin | Re: [PATCH] Fix compile breakage caused by asmlinkage_protect
Cool with me; I'll try to puzzle out why removing -traditional breaks on
those two specific files. Ugh, big cleanups likely.
cheers, Kyle
--
| Apr 11, 8:37 am 2008 |
| Tvrtko A. Ursulin | Re: Western Digital GreenPower drives and Linux
Followup with some good news.
Head unload timer settings seems to be persistent across powering off. Having
set it to a maximum value of 25.5 seconds my disk is now behaving much more
reasonable.
To actually do it I used FreeDOS floppy image burnt on a CD-RW as a bootable
image plus wdidle3.exe in the filesystem itself.
BTW, WD's tech support has gone silent so chances for an easier solution are
not so great.
Tvrtko
--
| Apr 11, 2:00 pm 2008 |
| Andi Kleen | Re: [PATCH] x86: set_cyc2ns_scale() remove tsc_now and ns_now
I don't think you should remove those. At some point the offset
needs to be reset when the frequency scale changes for obvious reasons,
and that needs to be fixed, not the code removed. Right now you'll get
scheduling inconsistencies during frequency changes on
!constant_tsc CPUs.
(actually it is still the wrong time -- really needs a grace
period during which the TSC is not used
ftp://firstfloor.org/pub/ak/quilt/patches/sched-clock implemented
some of these ideas against an older ...
| Apr 11, 12:42 am 2008 |
| Guillaume Chazarain | Re: [PATCH] x86: set_cyc2ns_scale() remove tsc_now and ns_now
This offset is already there, represented by rq->clock - sched_clock()
--
Guillaume
--
| Apr 11, 1:25 am 2008 |
| Ingo Molnar | Re: [PATCH] x86: set_cyc2ns_scale() remove tsc_now and ns_now
recent CPUs have constant-freq TSCs so it's mostly a legacy issue, but
the affected installed base is still significant to warrant a fix.
we dont really have to worry about complications like grace periods -
higher layers in the scheduler protect against temporary sched_clock()
outliers. So i think this can all be done much simpler. Just get rid of
the global cpu_khz notion, sched_clock() should simply follow the ->freq
value - and that's it.
Ingo
--
| Apr 11, 12:55 am 2008 |
| Andi Kleen | Re: [PATCH] x86: set_cyc2ns_scale() remove tsc_now and ns_now
Actually there millions of non constant freq TSC CPUs shipped each
But you still get scheduling hickups even with the sanity check. If the
scheduler depends on a smooth time that is not good and my (admittedly much less
than yours) understanding of CFS is that it relies on that. Especially ondemand
At some point you have to generate an offset to something and that
offset must be different for different frequencies, otherwise
you get large systematic errors
(<imagine complicated ...
| Apr 11, 1:06 am 2008 |
| Andi Kleen | Re: [PATCH] x86: set_cyc2ns_scale() remove tsc_now and ns_now
Same issue. Think about it. Perhaps I should have written
the complicated proof :)
You really have to compute the offset before the scaling, otherwise it
is useless.
TSC is a counter that adds up time units. Now when the frequency
changes the time units change, but counter doesn't reset.
Now the full absolue value of the counter is useless for exact time
because there is no way to reconstruct what the lengths of the different
time units meshed together in the single counter value ...
| Apr 11, 1:40 am 2008 |
| Rafael J. Wysocki | Re: x86 git tree broken (bisected)
Attached is a boot dmesg output from the current x86 git tree with your two
patches applied.
Thanks,
Rafael
| Apr 11, 1:51 pm 2008 |
| Ingo Molnar | Re: x86 git tree broken
hm, that's very close to the system i tried: Athlon64 X2 with Radeon
X300SE (PCIe), 1GB RAM. (Asus A8N-E mobo)
Ingo
--
| Apr 10, 11:43 pm 2008 |
| Rafael J. Wysocki | Re: x86 git tree broken (bisected)
That also works from under a framebuffer console, so one of these commits
(presumably ea1441bdf53692c3dc1fd2658addcf1205629661) also breaks suspend on
this box.
Thanks,
Rafael
--
| Apr 11, 1:29 pm 2008 |
| Yinghai Lu | Re: x86 git tree broken (bisected)
i got some hint. Will send you one patch to workaround the overlapping.
YH
--
| Apr 11, 2:31 pm 2008 |
| Rafael J. Wysocki | Re: x86 git tree broken (bisected)
The bisection turned up commit ea1441bdf53692c3dc1fd2658addcf1205629661
"x86: use bus conf in NB conf fun1 to get bus range on, on 64-bit" as the one
causing problems.
Unfortunately, I can't revert cleanly it, because there are two more commits
depending on it in a highly nontrivial fashion, so I have reverted all three
commits
a365998cd2cecfb827469dbd57c29602c106cb83
44f7f90fbe7a3a99aab082f765346514b7b5c705
ea1441bdf53692c3dc1fd2658addcf1205629661
and X starts again. Also, suspend to ...
| Apr 11, 12:26 pm 2008 |
| Yinghai Lu | Re: x86 git tree broken (bisected)
can you put boot in your command line?
Thanks
YH
--
| Apr 11, 2:11 pm 2008 |
| Rafael J. Wysocki | Re: x86 git tree broken (bisected)
I'm not quite sure what you mean.
Can you please tell me what exactly you want me to do?
Thanks,
Rafael
--
| Apr 11, 2:21 pm 2008 |
| Yinghai Lu | Re: x86 git tree broken (bisected)
please keep the three patches and applied the two attached debug patches.
i wonder if there is some io allocation overlapping with your system.
YH
| Apr 11, 1:26 pm 2008 |
| Rafael J. Wysocki | Re: x86 git tree broken (bisected)
Update:
With the above three commits reverted both X itself and suspend to RAM from
X also work with the current x86-git (as of HEAD equal to
1192aeb957402b45f311895f124e4ca41206843c).
Thanks,
Rafael
--
| Apr 11, 1:23 pm 2008 |
| J. Bruce Fields | Apr 11, 12:19 pm 2008 | |
| Miklos Szeredi | Re: nfs: infinite loop in fcntl(F_SETLKW)
Ah, sorry. I was only looking at the last half year of archives :)
Miklos
--
| Apr 11, 12:22 pm 2008 |
| Miklos Szeredi | Re: nfs: infinite loop in fcntl(F_SETLKW)
Yeah, that patch looks totally wrong. It's not generally a good idea
to do a loop where the exit condition depends on something you don't
control. And error values from filesystem methods are typically like
that. For example with fuse, the error code could come from an
unprivileged userspace process.
I didn't realize this aspect of the bug previously, because I
concentrated on the lockd inconsistency.
Btw, why hasn't this work been posted on -fsdevel prior to merging
EAGAIN for a ...
| Apr 11, 12:12 pm 2008 |
| Ingo Molnar | Re: [PATCH] x86: setup_trampoline() - fix section mismat ...
it worked just fine. (another minor nit: in future patches please
include a Signed-off-by line.)
Ingo
--
| Apr 11, 2:03 am 2008 |
| Sam Ravnborg | Re: [PATCH] x86: setup_trampoline() - fix section mismat ...
Hi Jacek
The correct fix would be to drop the
preprocessor directves and use __CPUINITDATA
If your testing confirms this then please apply similar fix to the _32.S
version of the file too.
Nore that this looses the @progbits annotation but it should be OK to do so.
I may later add it to init.h.
Sam
--
| Apr 11, 10:50 am 2008 |
| Nick Piggin | Re: [patch 10/17] mm: fix bootmem alignment
Ah, with this patch I'm actually able to allocate 2 1GB pages (on my 4GB
box), so it must be doing something right ;) Will be helpful for my
testing, thanks.
--
| Apr 11, 4:58 am 2008 |
| Ross Biro | Re: [PATCH 1/2] MM: Make Page Tables Relocatable -- cond ...
This race appears to have been fixed between 2.6.25rc5-mm1 and
2.6.25rc8-mm1. I've been running the later over night and have over 7
million iterations with out a crash.
Ross
--
| Apr 11, 6:49 am 2008 |
| Serge Belyshev | Re: [PATCH 5/7] PPS: serial clients support.
What about adding precise timestamping to the lowest possible irq
handling level ( arch/*/entry*.S ) and then export that information
in a general way so it is useful for other applications?
--
| Apr 11, 7:43 am 2008 |
| Rodolfo Giometti | Re: [PATCH 5/7] PPS: serial clients support.
The problem is that at such level you cannot easily retrieve info
about where your serial port is connected to and which PPS source you
should manage...
Ciao,
Rodolfo
--
GNU/Linux Solutions e-mail: giometti@enneenne.com
Linux Device Driver giometti@linux.it
Embedded Systems phone: +39 349 2432127
UNIX programming skype: rodolfo.giometti
--
| Apr 11, 9:58 am 2008 |
| Rodolfo Giometti | Re: [PATCH 5/7] PPS: serial clients support.
The problem is that deferencing the pps_event() call will cause severe
problems to PPS accuracy... here you can find some considerations on
this topic:
Can you please give me an URL where I can see that patch?
Thanks a lot for your help,
Rodolfo
--
GNU/Linux Solutions e-mail: giometti@enneenne.com
Linux Device Driver giometti@linux.it
Embedded Systems phone: +39 349 2432127
UNIX programming ...
| Apr 11, 1:49 am 2008 |
| Alan Cox | Re: [PATCH 5/7] PPS: serial clients support.
uart_ is only used by some drivers. We have a whole army of drivers using
the tty layer directly and another army of drivers using the USB layer.
You also need a sensible way to talk to the devices, identify support and
avoid clashing uses of carrier pins.
Alan
--
| Apr 11, 7:46 am 2008 |
| Rodolfo Giometti | Re: [PATCH 5/7] PPS: serial clients support.
How can I do that? From a serial device I just need the IRQ time
arrival, no other data at all. How a ldisc can help me in this task?
This patch adds PPS support just for UARTs, other devices should
provide their own support by using the new provided API. :)
Ciao,
Rodolfo
--
GNU/Linux Solutions e-mail: giometti@enneenne.com
Linux Device Driver giometti@linux.it
Embedded Systems phone: +39 349 2432127
UNIX ...
| Apr 11, 12:55 am 2008 |
| Alan Cox | Re: [PATCH 5/7] PPS: serial clients support.
At the moment you can't. That needs fixing. Most of the infrastructure is
I do not want PPS code adding to every single serial driver. That way
lies madness. We do it once, and in the right layer. I'll take a further
look at it after the tty->ops patch is merged. At that point we'll be in
a good position to add the needed ops/callbacks.
Alan
--
| Apr 11, 1:28 am 2008 |
| Lennart Sorensen | Re: [PATCH 5/7] PPS: serial clients support.
I thought it just required that the uart driver call
uart_handle_dcd_change when the state of the CD changes, and all the PPS
stuff happened in that function.
That seems pretty low intrusion, since the serial driver wouldn't need
to be touched with the PPS code at all as long as it already calls the
uart_handle functions.
Now if the driver doesn't generate an IRQ whenever a status line
changes, then the driver does need to be updated to do that. Some (like
jsm) already do, and have no ...
| Apr 11, 6:47 am 2008 |
| Mark McLoughlin | Re: [PATCH] xen: Enable Xen console by default in domU
On Thu, 2008-04-10 at 17:46 +0200, Markus Armbruster wrote:
How about adding a new console flag so that e.g. you could do:
if (!strcmp(c->name, "tty") && c->index == 0 &&
!(c->flags & CON_SET_ON_CMDLINE))
--
| Apr 11, 1:52 am 2008 |
| Mark McLoughlin | Re: [PATCH] xen: Enable Xen console by default in domU
You'd also need to export this symbol for the unusual case where fbfront
is a module ...
Cheers,
Mark.
--
| Apr 11, 1:59 am 2008 |
| Johannes Berg | Re: [RFC 1/3] add macros for new sparse features
I was looking at making sparse check that certain variable references
are under rcu, but it's not as easy. Also, the lock context is just an
arbitrary name, there's no way to actually link it to a certain variable
or so to differentiate between them. I think that's not really solvable
in sparse, look at the things lockdep has to do.
johannes
| Apr 11, 5:20 am 2008 |
| Hans J. Koch | Re: [PATCH 4/4 v2] [RFC] UIO: generic platform driver
I know. Unfortunately, I tested on x86_64, and it doesn't compile.
If it's depending on something, then this dependency should be added in
Kconfig. If it can be selected in the configuration, I expect it to
compile (and work).
Thanks,
--
| Apr 11, 4:17 am 2008 |
| Hans J. Koch | Re: [PATCH 4/4] [RFC] UIO: generic platform driver
I looked around a bit and talked to some people. It seems that a local
variable declaration within a for{} block is OK. I still don't like it,
but I won't object any longer.
So, AFAICT you've only got that arch dependency problem left to solve.
Thanks,
Hans
--
| Apr 11, 12:59 pm 2008 |
| Uwe | Re: [PATCH 4/4 v2] [RFC] UIO: generic platform driver
Hello,
[Added Russell King to Cc:]
Maybe adding a dummy implementation that is compiled for machines that
don't provide a native one. Currently there is no cpp symbol that tells
if an machine supports the API.
@Russell: Do you have an opinion regarding this!?
Best regards
Uwe
--
Uwe Kleine-König, Software Engineer
Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany
Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962
--
| Apr 11, 4:25 am 2008 |
| Uwe | Re: [PATCH 4/4] [RFC] UIO: generic platform driver
Hello Hans,
See below.
BTW, I found it, it's in linux/stringify.h. And there are several
possible users:
ukleinek@zentaur:~/gsrc/linux-2.6$ git ls-files -z | xargs -0 perl -n -e 'print "$ARGV\n" if ...
| Apr 10, 11:21 pm 2008 |
| Uwe | [PATCH 1/4 v2] UIO: hold a reference to the device's own ...
Otherwise the device might just disappear while /dev/uioX is being used
which results in an Oops.
Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
---
That thing about code reordering is minor compared to having all error
... , it's your code, so you can find a new version below.
Best regards
Uwe
drivers/uio/uio.c | 36 +++++++++++++++++++++---------------
1 files changed, 21 insertions(+), 15 deletions(-)
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index ...
| Apr 11, 2:07 am 2008 |
| Ben Nizette | Re: [PATCH 4/4] [RFC] UIO: generic platform driver
I've seen this kind of thing hacked up by a few people already, mainly
as a replacement for /dev/mem. Many people are being scared off
using /dev/mem (and rightly so) because
- They've seen discussions regarding future plans whereby /dev/mem
wouldn't be allowed access to physical memory
- They don't have anything like X forcing them to have /dev/mem and
therefore want to disable it completely for (perceived?) security
reasons.
I like it, it'll sure be used.
--Ben.
--
| Apr 10, 6:34 pm 2008 |
| Hans J. Koch | Re: [PATCH 1/4] UIO: hold a reference to the device's ow ...
Maybe. It's merely an example to explain what I mean.
Documentation/CodingStyle says nothing about how to place labels, but I
find it best to have all error path exits at the end of a function. All
Well, it depends. It's all about readability. Any function should be
written in a way that makes it as clear as possible what it does. Your
code is certainly not critical regarding that aspect, but I think it can
still be improved. And a label that is used only once and contains only
one line of ...
| Apr 11, 1:44 am 2008 |
| Greg KH | Re: [PATCH 3/4] UIO: wrap all uio drivers in "if UIO" an ...
Already in the -mm tree...
thanks,
greg k-h
--
| Apr 11, 2:36 pm 2008 |
| Uwe | [PATCH 4/4 v2] [RFC] UIO: generic platform driver
Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
---
While reworking the code I saw that your variant is not correct because
if pdev has resources with flags != IORESOURCE_MEM the constraint
uiomem == &uioinfo->mem[i]
doesn't hold.
Below is a new version that uses linux/stringify and zeros size for
unused mappings (line 102ff).
Best regards
Uwe
drivers/uio/Kconfig | 7 ++
drivers/uio/Makefile | 1 +
drivers/uio/uio_pdrv.c | 163 ...
| Apr 11, 2:21 am 2008 |
| Hans J. Koch | Re: [PATCH 4/4 v2] [RFC] UIO: generic platform driver
Hi Greg,
PATCH 4/4 still has a problem. It uses some clock framework functions
not available on every architecture. E.g. on x86_64 you can select this
driver in menuconfig, but it won't compile.
The first three patches are OK in my opinion. Uwe provided a second
version of PATCH 1/4, PATCH 2/4 and PATCH 3/4 were alright in their
original version. I added my Signed-off-by to 1-3, but not to 4.
Thanks,
Hans
--
| Apr 11, 3:54 pm 2008 |
| Uwe | Re: [PATCH 1/4] UIO: hold a reference to the device's ow ...
Hello,
As Greg already pointed out, mmap only works for open files and so the
With that you leak a reference to idev->owner if idev->info->open() fails.
Things like that don't happen that easy if all error handing is in one
This makes code shuffling easier. For example if someone decides that
try_module_get should be done after allocating listener then you only
have to exchange the two corresponding code blocks and the two groups
(label + cleanup) in the error handling block.
If the error ...
| Apr 10, 11:50 pm 2008 |
| Greg KH | Re: [PATCH 4/4 v2] [RFC] UIO: generic platform driver
Care to send the latest version of this, I'm a bit lost as to what
people want me to apply...
thanks,
greg k-h
--
| Apr 11, 2:41 pm 2008 |
| Hans J. Koch | Re: [PATCH 4/4] [RFC] UIO: generic platform driver
OK, as this is a generic driver where we don't know what crap people
No. It's more important to see which variables are declared in the
function and which are declared elsewhere. If you have to search the
whole body of a function for possible declarations, this is BAD. And if
it's not clear where a variable is used, the function is too long or has
other style problems. Your function is short and clean, so where's the
I don't like it. It makes things more complicated without any ...
| Apr 11, 2:24 am 2008 |
| Hans J. Koch | Re: [PATCH 4/4 v2] [RFC] UIO: generic platform driver
Thanks, but it doesn't compile, neither with -rc8 nor with Linus' git.
One problem can easily be fixed, the macro is called __stringify, not
stringify.
But what about this:
ERROR: "clk_get" [drivers/uio/uio_pdrv.ko] undefined!
ERROR: "clk_enable" [drivers/uio/uio_pdrv.ko] undefined!
ERROR: "clk_disable" [drivers/uio/uio_pdrv.ko] undefined!
ERROR: "clk_put" [drivers/uio/uio_pdrv.ko] undefined!
Do you have any extra patches applied?
Against which kernel do you test?
Thanks,
--
| Apr 11, 3:33 am 2008 |
| Uwe | Re: [PATCH 4/4] [RFC] UIO: generic platform driver
Hello Hans,
I'm not conviced and still prefer it that way. I gave way for your
requests in uio.c because it's your code. I want to leave it as it is
Most use cases I imagine only use a single mapping, so the gain would be
For which definition of wrong? sizeof(struct uio_info) don't include
space for mem then, but in my eyes that's correct. Having to care about
There is no extra memory because uioinfo and it's mem member are
allocated together with a single kzalloc (and must be). (Thats ...
| Apr 11, 3:41 am 2008 |
| Hans J. Koch | Re: [PATCH 2/4] UIO: use menuconfig
Hey, I just wanted to improve my Signed-off-by statistics :-) Damn it,
one less...
No, seriously, it looked somehow familiar but I didn't remember. Sorry.
Thanks,
Hans
--
| Apr 11, 3:58 pm 2008 |
| Greg KH | Re: [PATCH 4/4 v2] [RFC] UIO: generic platform driver
Ok, I grabbed patch 1, 2 and 3 are already in my tree and -mm :)
Let me know if you all come to an agreement on patch 4.
thanks,
greg k-h
--
| Apr 11, 4:06 pm 2008 |
| Uwe | Re: [PATCH 4/4 v2] [RFC] UIO: generic platform driver
Hello,
I just notice that, too. My mail address that and your's just crossed
Yes I have, but nothing special. This is part of a generic API defined
in include/linux/clk.h. One of it's use it to abstract away some
platform dependencies. There are several architectures that define
it[1]. I used it to allow enabling the device only when the device is
opened. Typical things in the enable routine are enabling a clock or
reserve and configure gpios etc.
A minimal dummy implementation that ...
| Apr 11, 4:03 am 2008 |
| Uwe | Re: [PATCH 4/4 v2] [RFC] UIO: generic platform driver
Hello,
This must read __stringify(MAX_UIO_MAPS). Sorry, I didn't compile test
that.
Uwe
--
Uwe Kleine-König, Software Engineer
Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany
Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962
--
| Apr 11, 3:48 am 2008 |
| Greg KH | Re: [PATCH 2/4] UIO: use menuconfig
You like it so much you already acked this same change from someone
else, which is in my tree at:
thanks,
greg k-h
--
| Apr 11, 2:36 pm 2008 |
| Hans J. Koch | Re: [PATCH 1/4 v2] UIO: hold a reference to the device's ...
Looks alright, thanks!
It's not _my_ code, it's _our_ code, partly written by me. At home, I use any
coding style I like. But this is in mainline, so we use the coding style the
--
| Apr 11, 4:39 am 2008 |
| Sam Morris | Re: Samsung Q45 hard freeze during boot
Further to this--I found that if I blacklist the 'video' driver then I can =
boot up normally.
--=20
Sam Morris
http://robots.org.uk/
PGP key id 1024D/5EA01078
3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078
| Apr 10, 5:50 pm 2008 |
| YOSHIFUJI Hideaki / | Re: [PATCH net-2.6.26] [IPV6] Adjust IPV6 multicast rout ...
Applied, thanks.
--yoshfuji
--
| Apr 11, 2:11 am 2008 |
| Balbir Singh | Re: [-mm] Add an owner to the mm_struct (v9)
The way this works is
If I select memory resource controller, CONFIG_MM_OWNER is set to y, else it
do_each_thread(), while_each_thread() walks all processes and threads of those
processes in the system. It is a common pattern used in the kernel (see
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
--
| Apr 10, 9:27 pm 2008 |
| KAMEZAWA Hiroyuki | Re: [-mm] Add an owner to the mm_struct (v9)
On Fri, 11 Apr 2008 09:57:06 +0530
What you want is finding a thread which has the "mm_struct". Why search all
threads ? I think you only have to search processes(i.e. thread-group-leaders).
try_to_freeze_tasks()/oom_kill_task() have to chase all threads because
it have to check flags in task_structs in a process.
Thanks,
-Kame
--
| Apr 10, 9:47 pm 2008 |
| KAMEZAWA Hiroyuki | Re: [-mm] Add an owner to the mm_struct (v9)
maybe I don't undestand correctlly...
On Thu, 10 Apr 2008 14:46:02 +0530
no default is ok here ? what value will this have if not selected ?
Again, do_each_thread() is suitable here ?
for_each_process() ?
Thanks,
-Kame
--
| Apr 10, 8:33 pm 2008 |
| KAMEZAWA Hiroyuki | Re: [-mm] Add an owner to the mm_struct (v9)
On Fri, 11 Apr 2008 10:17:35 +0530
Oh. thank you for kindly explanation.
I'll test this on 2.6.25-rc8-mm2.
Regards,
-Kame
--
| Apr 10, 9:58 pm 2008 |
| Balbir Singh | Re: [-mm] Add an owner to the mm_struct (v9)
Thanks for the review and help with testing.
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
--
| Apr 10, 9:56 pm 2008 |
| Balbir Singh | Re: [-mm] Add an owner to the mm_struct (v9)
Good question. It is possible that clone() was called with CLONE_VM without
CLONE_THREAD. In which case we have threads sharing the VM without a thread
group leader. Please see zap_threads() for a similar search pattern.
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
--
| Apr 10, 9:47 pm 2008 |
| Ingo Molnar | Re: linux-next: Tree for April 10 (arch/x86)
is there really no way to solve this more cleanly than a forced cast? It
is a totally uninteresting warning that we pass in a narrower type to
printk(). It cannot ever cause any bugs or problems. Why does gcc warn
about it?
Ingo
--
| Apr 11, 12:46 am 2008 |
| Randy Dunlap | Re: linux-next: Tree for April 10 (arch/x86)
I haven't seen any other decent solutions. This is what we do
No idea about that part.
---
~Randy
--
| Apr 11, 8:19 am 2008 |
| Suresh Siddha | Re: [BUG] linux-next: April 10 - kernel oops at kmem_c ...
I noticed in another thread, that you are using gcc 4.1.1. I think
both 4.1.0 and 4.1.1 has some issues with weak symbols. Can you please
try gcc 4.1.2 and see if that fixes your issue.
When I go back to 4.1.0, I am bitten by smilar oops. But not with 4.1.2.
thanks,
suresh
--
| Apr 11, 10:56 am 2008 |
| Al Viro | Re: linux-next: Tree for April 10 (arch/x86)
Er... That's kinda obvious - vararg function getting the wrong-sized
argument is *NOT* a harmless situation. And yes, it's certainly a bug -
gcc manages to recover by using the knowledge of printf() formats (i.e.
it guesses that we want a long long and does conversion), but try to
do
char *s = "%llx %c";
printf(s, 1, '.');
and watch the show...
--
| Apr 11, 8:26 am 2008 |
| Chris Snook | Re: OOPS: found a fatal bug in Redhat Enterprise Server ...
Please report this at bugzilla.redhat.com, or to Red Hat support. This
kernel is very out of scope for this mailing list, unless you can
reproduce the problem on newer kernels.
-- Chris
--
| Apr 11, 11:31 am 2008 |
| H. Peter Anvin | Re: [GIT] git-clone failure over http
This happens when the repository maintainer hasn't done:
chmod +x <repo>.git/hooks/post-update
This has to be done manually for some reason.
-hpa
--
| Apr 10, 9:49 pm 2008 |
| Andres Salomon | Re: [PATCH 2/3] x86: GEODE: add Virtual Systems Architec ...
On Thu, 10 Apr 2008 15:20:19 +0100
How about this?
This is generic VSA2 detection. It's used by OLPC to determine whether or
not the BIOS contains VSA2, but since other BIOSes are coming out that don't
use the VSA (ie, tinybios), it might end up being useful for others.
Signed-off-by: Andres Salomon <dilinger@debian.org>
---
include/asm-x86/geode.h | 19 +++++++++++++++++++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/include/asm-x86/geode.h ...
| Apr 10, 6:53 pm 2008 |
| Daniel Hokka Zakrisson | Re: [PATCH 1/3] change clone_flags type to u64
I think putting mq under CLONE_NEWIPC makes sense, as well as using
CLONE_NEWDEV for the ptys. If CLONE_NEWUSER is to be combined with
anything, I think it makes more sense to combine it with CLONE_NEWPID than
--
Daniel Hokka Zakrisson
--
| Apr 11, 1:45 am 2008 |
| Ingo Molnar | Re: [PATCH] e1000e: set CONFIG_E1000E=y in x86 defconfigs
thanks, applied.
Ingo
--
| Apr 11, 1:59 am 2008 |
| KOSAKI Motohiro | Re: [patch 11/17] Implement immediate update via stop_ma ...
Ah, OK. I understand.
Thanks.
--
| Apr 10, 9:50 pm 2008 |
| Rusty Russell | Re: [patch 16/17] Immediate Values - Documentation
In theory although not in practice, since everyone vmallocs modules. Let's
not rely on that tho.
How about we sweep the immediate table on init discard and remove/mark all the
init and exit references?
Cheers,
Rusty.
--
| Apr 11, 8:06 am 2008 |
| Mathieu Desnoyers | Re: [patch 16/17] Immediate Values - Documentation
Yeah, I know :(
Well, only if we can find a way to detect the macro is put within a init
or exit section. Is there some assembly trickery that would permit us to
do that ?
Otherwise, given the memory freed from the init section could be reused
later by the kernel, I don't see how we can detect the pointer leads to
a freed init section and, say, a module.
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C ...
| Apr 10, 6:16 pm 2008 |
| Mathieu Desnoyers | [RFC PATCH] Immediate Values Support init
Supports placing immediate values in init code
We need to put the immediate values in RW data section so we can edit them
before init section unload.
This code puts NULL pointers in lieu of original pointer referencing init code
before the init sections are freed, both in the core kernel and in modules.
(experimental patch submitted for comments and testing)
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
CC: Rusty Russell <rusty@rustcorp.com.au>
CC: "Frank Ch. Eigler" ...
| Apr 11, 6:44 am 2008 |
| Andreas Grimm | Re: VM - a plenty of inactive memory
Hi everybody,
i investigated this further. The tunables swappiness, drop_caches etc.
are no options to solve this. The problem is becoming very unpleasent,
because the system isn't able to cache that much:
The 16GB system (expected behaviour):
MemTotal: 16619808 kB
MemFree: 4490032 kB
Cached: 6929448 kB
Inactive: 1670812 kB
The 32GB system :
MemTotal: 33265916 kB
MemFree: 600000 kB
Cached: 1561124 kB
Inactive: 25873128 kB
Don't you think ...
| Apr 11, 6:13 am 2008 |
| Peter Zijlstra | Re: VM - a plenty of inactive memory
It should not be locked (being on the inactive list does not imply that
in any way). Being on the inactive list just means its first in line to
Why would you want to do that for? Would you not rather have a copy of
some page in memory than having to go back to disk to fetch it? Free
memory is a waste, better have something in it that might potentially be
See above, free memory is a waste. Really, you don't want 24GB of free
If it really would have hit swap then it just means you have a ...
| Apr 11, 10:55 am 2008 |
| linux-os (Dick Johnson) | Re: VM - a plenty of inactive memory
Wasting 25GB? It looks to me as though the kernel cached
(didn't write pages to disk yet) just about all it needed,
and there is lots of memory that it just doesn't need
--yet! This means that if you have tasks that need memory
in a hurry, they'll get it without any disk accesses.
The kernel doesn't expand to use all the memory just to
spread itself all over the place. It uses what it needs,
caches some buffered data, and keepts track of all the
memory it has. If you want to use more ...
| Apr 11, 7:34 am 2008 |
| Ingo Molnar | Re: [BUG] linux-next: Tree for April 9 warning on CC_STA ...
i've reverted the guilty patch and will push out a new x86.git soon.
Ingo
--
| Apr 11, 2:45 am 2008 |
| Ingo Molnar | Re: mutex_unlock
to perhaps get more kernel messages about this, try the earlyprintk=vga
boot option - does it produce any messages?
Ingo
--
| Apr 11, 2:07 am 2008 |
| Justin Mattock | Re: mutex_unlock
Thanks for the info, I can try that and see if I receive any kind of messages.
regards;
--
Justin P. Mattock
--
| Apr 11, 9:07 am 2008 |
| David Miller | Re: 2.6.25-rc8: FTP transfer errors
From: Mark Lord <lkml@rtr.ca>
Thanks Mark.
Pavel can you take a look? I suspect that the namespace
changes or gets NULL'd out somehow and this leads to the
resets because the socket can no longer be found. Perhaps
it's even a problem with time-wait socket namespace
propagation.
--
| Apr 10, 5:26 pm 2008 |
| David Miller | Re: 2.6.25-rc8: FTP transfer errors
From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
ROFL
--
| Apr 11, 3:27 pm 2008 |
| Valdis.Kletnieks | Re: 2.6.25-rc8: FTP transfer errors
Like it or not, when you're the owner of the only box that can reliably
reproduce an error condition, it's your bug.
Been there, done that, plenty of times.
| Apr 11, 12:58 pm 2008 |
| Valdis.Kletnieks | Re: 2.6.25-rc8: FTP transfer errors
The nice thing about binary search is that it's by definition an
O(log2(N)) operation, which isn't bad at all as far as algorithms go.
The truly blunt instrument here would be a linear search of every commit...
| Apr 11, 12:58 pm 2008 |
| Mark Lord | Re: 2.6.25-rc8: FTP transfer errors
..
Absolutely, though to a varying degree. That's the responsibility
that goes with the role of a subsystem maintainer. I once had
such a role, and gave it up when I felt I could no longer keep up.
You still keep refering to it as "your (my) bug".
It's not. I had nothing to do with it, other than stumbling over it.
When people stumble over a libata bug, I look hard to see if my code
could possibly cause it. Jeff looks even harder, because he's the
current subsystem dude for ...
| Apr 10, 6:23 pm 2008 |
| Tilman Schmidt | Re: 2.6.25-rc8: FTP transfer errors
Thanks for the advice. I'll keep it in mind next time I have to decide
whether to report a bug I'm stumbling over.
T.
| Apr 11, 3:27 pm 2008 |
| Mark Lord | Re: 2.6.25-rc8: FTP transfer errors
..
It's not "my bug". I'm just the first person to notice,
take time to report it, and even hand it to you on a platter (bisect).
It's *your* bug -- you signed off on the commit.
Cheers
--
| Apr 10, 5:27 pm 2008 |
| David Miller | Re: 2.6.25-rc8: FTP transfer errors
From: Mark Lord <lkml@rtr.ca>
And if I invest my spare time on your bug how does this statement
apply to me? Or does it only apply to you?
Every single argument you make that supports why you should not be
investing the necessary time into the bug applies equally to the
very developers you are so quickly to quip at and want help from.
--
| Apr 10, 5:24 pm 2008 |
| Mark Lord | Re: 2.6.25-rc8: FTP transfer errors
..
Because I care, about Linux's reputation and performance.
I care about basic networking operations, and knew that this bug
would probably affect other applications once widely deployed.
Where the hell did I *ever* say that?
I did nothing but offer help, and respond quickly.
The one thing I did not have time for initially,
was a painstaking blunt instrument binary search of
every commit since v2.6.24.
There are other ways to debug things and find the causes
quickly, with less ...
| Apr 11, 7:59 am 2008 |
| David Miller | Re: [PATCH 2.6.25] net sockets: fix timewait namespace r ...
From: Mark Lord <lkml@rtr.ca>
Will do, thanks for testing.
--
| Apr 10, 8:51 pm 2008 |
| David Miller | Re: 2.6.25-rc8: FTP transfer errors
From: Mark Lord <lkml@rtr.ca>
I sign off on basically every networking commit, does that mean I have
to fix every networking bug and every networking bug is "mine"?
Of course not, that doesn't scale at all. What does scale is a
combination of good fully formed bug reports from users combined with
the efforts of the global developer pool.
Linus signs off on every patch from Andrew Morton he puts into the
tree, which is a lot, but does Linus work on every bug introduced by
one of those ...
| Apr 10, 5:39 pm 2008 |
| Mark Lord | Re: 2.6.25-rc8: FTP transfer errors
..
Duh.. more like, "If I take 5-8 hours to attempt a bisect (which may not
even work), then that's 5-8 hours I do not get paid for."
Gotta eat, dude.
Anyways, here's five hours of free consulting for you:
git-bisect start
# bad: [7180c4c9e09888db0a188f729c96c6d7bd61fa83] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/selinux-2.6
git-bisect bad 7180c4c9e09888db0a188f729c96c6d7bd61fa83
# good: [49914084e797530d9baaf51df9eda77babc98fa8] Linux ...
| Apr 10, 5:16 pm 2008 |
| Tilman Schmidt | Re: 2.6.25-rc8: FTP transfer errors
I think you got it backwards. Mark and other bug reporters (including,
at times, yours truly) are helping you and other developers to make
Linux better. Most of the times I report a bug, I am not asking for help
- I have no personal need to get it fixed, as I can easily avoid it, and
I only report it to give developers like you a chance to fix it before
it really hurts someone - and I gather that Mark has been in a similar
position wrt to the bug in question.
So what would you have us do? Not ...
| Apr 10, 5:56 pm 2008 |
| Evgeniy Polyakov | Re: 2.6.25-rc8: FTP transfer errors
You got it wrong.
If bug is subtle and developers can not reproduce it, there are only two
ways out of the problem: to help developers or not to help.
In the latter case bug report is useless (except that to show that it
exists, since practically no one can fix it until some new details
added).
In the former case there is a discussion between developers and
reporters, so things have progress. In this particular case there were
no healthy discussion, that is why all this is ...
| Apr 11, 3:25 pm 2008 |
| Tilman Schmidt | Re: 2.6.25-rc8: FTP transfer errors
=20
So I was right after all? Bug reports from people who (for whatever
reason, including having to earn their living) cannot do a bisect are
T.
| Apr 11, 3:16 pm 2008 |
| David Miller | Re: 2.6.25-rc8: FTP transfer errors
From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Every time I see someone play the "I care about Linux" card, they are
typically being a hypocrit. It's a knee jerk, defensive gesture, and
Thanks for your support Evgeniy, it is truly appreciated.
We had Mark's bug fixed in 15 minutes once the bisect result was
known, even after Ilpo and myself had scanned through the changesets.
This proves the utility of bisect and in fact that trying to intuit
the cause by continuing to study changesets and ...
| Apr 11, 11:07 am 2008 |
| Mark Lord | [PATCH 2.6.25] net sockets: fix timewait namespace regression
..
Works perfectly, thanks. Looks obvious, too.
Push it out to Linus now for 2.6.25.
Thanks!
--
| Apr 10, 8:18 pm 2008 |
| Mark Lord | Re: 2.6.25-rc8: FTP transfer errors
..
My system here is now set up for quick/easy retest, if you have any
suggestions or patches to try out.
Thanks guys.
--
| Apr 10, 5:29 pm 2008 |
| YOSHIFUJI Hideaki / | Re: 2.6.25-rc8: FTP transfer errors
Please try this, from net-2.6.26 tree.
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
----
From 8d9f1744cab50acb0c6c9553be533621e01f178b Mon Sep 17 00:00:00 2001
From: Daniel Lezcano <dlezcano@fr.ibm.com>
Date: Fri, 21 Mar 2008 04:12:54 -0700
Subject: [PATCH] [NETNS][IPV6] tcp - assign the netns for timewait sockets
Copy the network namespace from the socket to the timewait socket.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
Signed-off-by: David S. Miller ...
| Apr 10, 7:59 pm 2008 |
| Mark Lord | Re: 2.6.25-rc8: FTP transfer errors
..
That's not demanding, that's quite relaxed. I had a good workaround,
and didn't really care any more at that point. Just though it was rather
odd that none of the developers seemed interested in tracking it down.
I offered tons of help, gave it, and said I didn't have time for a full
bisect at that juncture.
For that, I get repeatedly slammed by the netdev folks.
Even after I put aside *paid* work to submit to your demands.
Next time around, I won't bother reporting bugs to you ...
| Apr 11, 6:19 am 2008 |
| David Miller | Re: 2.6.25-rc8: FTP transfer errors
From: Tilman Schmidt <tilman@imap.cc>
You need to qualify this with: when a bisect is asked of them
You seem to be quite eager to harp on this specitic point, to make it
seem as if a bug report is useless if the person cannot or will not
bisect in all cases. And that simply is not what we are saying here.
--
| Apr 11, 3:26 pm 2008 |
| Pavel Emelyanov | Re: 2.6.25-rc8: FTP transfer errors
Too late, but still
Acked-by: Pavel Emelyanov <xemul@openvz.org>
Sorry, guys, but my timezone does not allow me to react in time
to found bugs :( So, when I wake up in the morning I usually just
find out that someone has caught a BUG made by me and someone
--
| Apr 11, 12:50 am 2008 |
| David Miller | Re: 2.6.25-rc8: FTP transfer errors
From: Tilman Schmidt <tilman@imap.cc>
I appreciate the bug reports, believe me.
The issue is which of the limited developer resources get put onto
which bugs.
A developer who does this for fun is going to prioritize to things
that are pleasant and interesting to work on, and also a good
effective use of their time.
So people prioritize.
Therefore, my point is, the net result is that user have a direct
influence on which bugs get worked on with the highest priority and
thus get fixed ...
| Apr 10, 6:08 pm 2008 |
| Evgeniy Polyakov | Re: 2.6.25-rc8: FTP transfer errors
Actually that will be the best decision from evolutional point of view.
Bugs, which 'are thrown back to your face' like what you did with this
one, are useless. Developers already know, that bugs exist.
If you do not care about bug, why do you ever bothered filling it?
You expected that anyone will start running to fix it for you.
You were wrong. Developers only fix bugs, which do not require
mind-reading and magnetic quantification of your brain.
If you do not want to help fixing it, ...
| Apr 11, 7:35 am 2008 |
| Evgeniy Polyakov | Re: 2.6.25-rc8: FTP transfer errors
Blah-blah-blah, you care so much, that pissed people off which suggested
you how to really help Linux. And then you returned with besiect
Or I can ignore it, like the net developers, since I have a workaround.
And then we'll see what other apps are broken upon 2.6.25 final release.
*Somebody* is responsible for those changes.
That particular *somebody* ought to volunteer some help here,
reducing the mountain of commits to a big handful or two.
-----
If you do not know math, binary ...
| Apr 11, 8:18 am 2008 |
| Evgeniy Polyakov | Re: 2.6.25-rc8: FTP transfer errors
No problemo :)
--
Evgeniy Polyakov
--
| Apr 11, 2:29 pm 2008 |
| Ilpo Järvinen | Re: 2.6.25-rc8: FTP transfer errors
This bug is perfect example where bisect clearly was useful :-). Nobody
But it is ok for you to ask an innocent net developer to do that (even
with your terms as I hadn't signed off _anything_ related to that one),
hmm?
...Sure I could use similar words, but you might use the not-mine
bug approach again to deflect... :-( ...No, I don't mind really :-).
I well understand that I occassionally end up chasing things
which are bugs that other people have caused, that's part of the
Now ...
| Apr 10, 11:40 pm 2008 |
| Tilman Schmidt | Re: 2.6.25-rc8: FTP transfer errors
Looks like you're saying I was right after all. Useless bug reports
shouldn't be submitted.
So please answer this simple question: If I know beforehand that I won't
have the time to do a bisect (or other similarly time-consuming task the
maintainers might ask from me), should I report the bug, or should I
keep my knowledge to myself?
This question is not theoretical. It's a situation I find myself in
quite regularly, because I allow myself the luxury of building most rc
kernels and even ...
| Apr 11, 4:23 pm 2008 |
| Serge E. Hallyn | Re: [RFC] Control Groups Roadmap ideas
I'm tempted to ask what the use case is for this (I assume you have one,
you don't generally introduce features for no good reason), but it
doesn't sound like this would have any performance effect on the general
case, so it sounds good.
I'd stick with mount semantics. Just
mount -t cgroup -o remount,devices,cpu none /devwh"
I guess I'm hoping that if libcg goes well then a userspace daemon can
do all we need. Of course the use case I envision is having a container
which is locked to ...
| Apr 11, 7:48 am 2008 |
| Ingo Molnar | Re: [regression] e1000e broke e1000
well, your 2.6.26 plans, if i understand them correctly, is to move
currently working PCI IDs from e1000 to e1000e, like you attempted to d
it in v2.6.24, which Linus reverted - correct? I.e. e1000 simply wont
support eth0 on my T60 from 2.6.26 on? That is still an incredibly
stupid plan, and no amount of announcement on lkml will make it any less
stupid.
... which pretty much pulls the rug from under your argument, no?
Ingo
--
| Apr 11, 4:30 am 2008 |
| Christoph Hellwig | Re: [patch] e1000=y && e1000e=m regression fix
Hey, hey calm down. The device moving over to e1000e shouldn never
have been added to e1000. They're totally differnet and the only reason
they got added in thefirst time was because soemone talked intel into
it.
We discussed this a long time and came to a wide agreement it should
move out. Now the actual transition could and should have been handled
better, but with all the pci-e hardware in a separate driver we're all
off better in the long term.
And this is not really comparable to ...
| Apr 11, 4:36 am 2008 |
| Martin Mares | Re: [patch] e1000=y && e1000e=m regression fix
Maybe you could rename both configuration switches, so that you bring it to
the attention of everybody who does make oldconfig?
Have a nice fortnight
--
Martin `MJ' Mares <mj@ucw.cz> http://mj.ucw.cz/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
main(){char *s="main(){char *s=%c%s%c;printf(s,34,s,34);}";printf(s,34,s,34);}
--
| Apr 11, 10:10 am 2008 |
| Linus Torvalds | Re: [patch] e1000=y && e1000e=m regression fix
Because your version has exactly the same problem that the current code
has: it asks questions that aren't sensible to people who don't care. It
also keeps the old E1000 name for "PCI chips only", which means that
people who just use an old config and ignore new questions will suddenly
lose their ability to use the E1000 driver if they have a PCI-E card.
So most users:
- want to just say "E1000", and not care about type.
- want to have old configurations continue working (ie if you ...
| Apr 11, 11:51 am 2008 |
| Linus Torvalds | Re: [patch] e1000=y && e1000e=m regression fix
Ok, I'm not even interested in discussing this.
Have you followed the discussion at all? Did you even notice _why_ we're
discussing it?
Here's a damn big hint: teh thing you say "Presumably they'd think" is
exactly what we're talking about, AND HELL NO THEY DIDN'T!
That goes for both me and Ingo.
So stop blathering. The _fact_ is that two kernel developers were really
upset about the fact that their machines stopped working with old
configurations. Stop the inane ".. but that ...
| Apr 11, 1:21 pm 2008 |
| Jeff Garzik | Re: [patch] e1000=y && e1000e=m regression fix
It's even more confusing than that :)
E1000 means "support PCI and a few PCI-E"
E1000E means "all PCI-E"
There is a goodly number of PCI-E not supported by e1000 (some ich8, all
ich9 and thereafter).
Jeff
--
| Apr 11, 3:21 pm 2008 |
| Jeff Garzik | Re: [patch] e1000=y && e1000e=m regression fix
You mean never ever remove PCI-E support from e1000?
Won't that will inflict long term headaches on the people that matter
most -- users and maintainers -- to avoid short term headaches for
kernel power users?
To review the overall situation,
* e1000 supports so many chips, that making a change for new hardware in
e1000 involves breaking stability of older chips
* //You know this// from past kernel history, when late-breaking e1000
changes for new hardware wound up breaking ...
| Apr 11, 4:43 pm 2008 |
| Chris Friesen | Re: [regression] e1000e broke e1000
It seems like you're saying that once hardware is supported by a
particular config option, it can never ever be split out to another
config option, even if it makes both drivers cleaner.
A similar situation happened when the sk98lin driver was split into skge
and sky2...I don't remember a big fuss back then. Is it just that no
major developers were using the hardware so they didn't notice?
Chris
--
| Apr 11, 8:40 am 2008 |
| Christoph Hellwig | Re: [patch] e1000=y && e1000e=m regression fix
As a start we could do two driver keyed off a single Kconfig variable.
And then find a way to get users informed that they might need to
enabled the other one
--
| Apr 11, 9:45 am 2008 |
| Ingo Molnar | Re: [regression] e1000e broke e1000
yes, but note that the breakage you are talking about is not caused my
patch, it is caused by the planned change to remove those PCI IDs from
e1000.
my suggested change only solves part of the more general problem you
touch upon. (and it does not make it worse in any way)
Ingo
--
| Apr 11, 1:59 am 2008 |
| Willy Tarreau | Re: [patch] e1000=y && e1000e=m regression fix
I don't think this will happen like that. People will simply think as
usual "ah, they have added support for new hardware, but since everything
in my machine was supported, I don't need it".
I think that the correct solution to help people is not at build time,
but at run time. The e1000 driver should just *check* if there are PCI-IDs
that it used to manage and that it does not anymore, for unclaimed devices,
and report a warning message clearly indicating that these devices are not
handled ...
| Apr 11, 12:25 pm 2008 |
| Linus Torvalds | Re: [patch] e1000=y && e1000e=m regression fix
Nope. You apparently guessed just because I had told earlier about how the
E1000 changes screwed over my setup.
The fact is, people don't know. And they shouldn't care. If the E1000
driver worked before, we simply shouldn't break that from a configuration
standpoint.
Linus
--
| Apr 11, 1:29 pm 2008 |
| Ingo Molnar | Re: [patch] e1000=y && e1000e=m regression fix
that's an insane argument ... because we messed up in the past and have
hurt users (and probably lost users) you feel like it gives you a free
card to mess up again???
The IDE -> SATA migration, while i like the new SATA code and find it
excellent and well-maintained (many kudos for that to Tejun, Jeff, Alan
& co), caused a lot of trouble for users in one specific area, for no
good reasons other than stupid personality conflicts: /dev/hda worked
just as well as /dev/sda, the _name_ of ...
| Apr 11, 4:26 am 2008 |
| Matthew Wilcox | Re: [patch] e1000=y && e1000e=m regression fix
I learned not to do that ... back in 2.3, iirc, when the console
became selectable ;-)
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
--
| Apr 11, 12:38 pm 2008 |
| Daniel Barkalow | Re: [patch] e1000=y && e1000e=m regression fix
Okay, so with my change E1000 will incidentally give you ich9 support. But
it doesn't fail to "support PCI and a few PCI-E", it just does some more
that it has to give you for coverage of the traditional things.
-Daniel
*This .sig left intentionally blank*
--
| Apr 11, 4:05 pm 2008 |
| Daniel Barkalow | Re: [patch] e1000=y && e1000e=m regression fix
Eh, they'll both default to Y on PCs individually, so it's only people who
are turning unused stuff off who will even look, and they'll probably ask
/sys/class/net/eth0/device/driver or lsmod.
-Daniel
*This .sig left intentionally blank*
--
| Apr 11, 4:15 pm 2008 |
| Linus Torvalds | Re: [patch] e1000=y && e1000e=m regression fix
I think that's a great solution.
Here's a suggested patch. Not much tested, but it's fairly obvious.
It basically makes one top-level config option (E1000) to pick the driver
at all, and two sub-options (E1000_PCI and E1000_PCIE) that you can choose
between.
If you pick E1000 support, you're given the choice between "PCI only",
"PCI-E only" or "support both", and that will then pick the right
combination of support for E1000_PCI and E1000_PCIE.
This also does imply that you ...
| Apr 11, 10:34 am 2008 |
| Matthew Wilcox | Re: [patch] e1000=y && e1000e=m regression fix
I think it's a little over-engineered ... why not simply:
config E1000_SUPPORT
bool "Intel(R) PRO/1000 Gigabit Ethernet support"
depends on PCI
config E1000
depends on E1000_SUPPORT
tristate "E1000 PCI support"
help
Include support for Conventional PCI devices. This includes
chips built into motherboards ... blah blah, if unsure say "Y"
or "M"
config E1000E
depends on E1000_SUPPORT
tristate "E1000 PCI Express support"
help
Include support for PCI Express ...
| Apr 11, 10:53 am 2008 |
| Linus Torvalds | Re: [patch] e1000=y && e1000e=m regression fix
Yes, that sounds fine too. Although you need to add a
depends on PCI
to the E1000 thing (because the "select" would not honor the dependencies
that E1000E and E1000_PCI have).
I agree we could, but as I tried to explain, I fundamentally don't think
we _should_.
Why should people _ever_ be asked about whether they want "E1000 PCI
support" vs "E1000 PCI-E" support, when it's almost impossible to tell
which kind of card you have?
In other words, I suspect that anybody who ...
| Apr 11, 4:00 pm 2008 |
| Philip Craig | Re: [patch] e1000=y && e1000e=m regression fix
One problem is that the meaning of E1000 has been changed. It covers less
hardware than it used to.
You could add a new option to control the e1000 driver, and make E1000 set
both this new option and E1000E. Thus it will always cover at least all
the IDs that the original e1000 driver handled.
config E1000
tristate "Both Intel(R) PRO/1000 Gigabit Ethernet support"
depends on PCI
config E1000_ONLY
tristate "Intel(R) PRO/1000 Gigabit Ethernet support" if E1000=n
default ...
| Apr 10, 5:46 pm 2008 |
| Ingo Molnar | Re: [patch] e1000=y && e1000e=m regression fix
firstly, a good deal of our alpha testers use =y drivers. Secondly, your
kind of constructive email is exactly what i wanted to see in the first
place...
i dont really care _how_ this gets solved - i'm not maintaining this
code. What forced me to deal with it was this outright denial of my
problem, the ridiculing and NACK-ing of it and general stonewalling.
I'd have preferred to have sent only my first report. The networking
driver guys on the other hand:
1) forced me to send a ...
| Apr 11, 5:16 am 2008 |
| Kok, Auke | Re: [patch] e1000=y && e1000e=m regression fix
this is a gross misrepresentation and misunderstanding. You're completely ignoring
the fact that:
(1) I debated whether it was a "regression" - in my opinion design changes that
deliberately break things are hardly worth this incredibly negative stamp
(2) I never NACK'ed your patch. I just withdrew my ack.
(3) You're stonewalling me by pretty much forcing me to completely drop the driver
split and not showing any understanding for the reason behind the split at all.
You don't provide ...
| Apr 11, 9:22 am 2008 |
| Daniel Barkalow | Re: [patch] e1000=y && e1000e=m regression fix
Wouldn't it make more sense to turn E1000 into a option that does nothing
except select both E1000E and E1000_PCI, and have those two be the options
that build drivers? Then, after a while, we drop the E1000 option
entirely, and people are fine as long as they used any of the kernels in
between (since the system will have forgotten that E1000E was only set by
an option that has disappeared).
Right now, E1000 means "support both PCI and PCI-E E1000" and E1000E means
"support PCI-E ...
| Apr 11, 3:06 pm 2008 |
| Kok, Auke | Re: [patch] e1000=y && e1000e=m regression fix
This is probably the ugliest way to do it, but I just checked and if E1000=m then
automatically becomes E1000E=m etc.
Using 'default' will not work as people will misunderstand the issue and disable
e1000e anyway, while they often need e1000e instead of e1000.
Yes, this does mean that it's impossible to have e1000 but not enable e1000e, but
given the threads I think this is becoming more reasonable then ever for this
particular issue.
---
e1000e: select automatically if e1000 is ...
| Apr 11, 10:26 am 2008 |
| Andi Kleen | Re: [patch] e1000=y && e1000e=m regression fix
In my experience with FUSION=y and AIC78xx=y most of the relatively
modern (2000+) pre SAS SCSI systems are covered, at least near all
those without special RAID controllers. That is why I kept both of
those enabled in the defconfigs originally.
Might actually make sense to update this for SAS, but I don't have
a good feeling what chipsets are really popular here.
-Andi
--
| Apr 11, 12:54 am 2008 |
| david | Re: [patch] e1000=y && e1000e=m regression fix
no, it sounds like he's saying make the E1000 option select both E1000_PCI
and E1000_PCIE (which could be selected seperately) and never remove the
E1000 option.
after people trust the E1000e driver the PCI ids can be removed from
E1000, but people who only select E1000 will continue to work becouse the
build system will now build both the PCI and PCI-e drivers when E1000 is
selected.
David Lang
--
| Apr 11, 4:58 pm 2008 |
| Willy Tarreau | Re: [regression] e1000e broke e1000
The difference is that :
1) either could be used for a long time
2) the old worked so bad that the word has spread among people in forums
to try the new driver instead.
I think that splitting drivers should be something accepted in the kernel's
lifetime, but users must not be left confused. It's clearly easier to insert
ourselves in their common process to wave hands indicating that their setup
will soon not work anymore (eg: by having e1000 indicate what driver must be
loaded for ...
| Apr 11, 12:29 pm 2008 |
| Dan Noe | Re: [patch] e1000=y && e1000e=m regression fix
lspci -vv will tell you (if you're root :)!
Yet, the only part of that output that makes it even somewhat obvious is
the "Link: Speed 2.5Gb/s, Width x1" which clearly makes no sense for
legacy PCI.
Cheers,
Dan
--
/--------------- - - - - - -
| Dan Noe
| http://isomerica.net/~dpn/
--
| Apr 11, 2:01 pm 2008 |
| Matthew Wilcox | Re: [patch] e1000=y && e1000e=m regression fix
We only support people keeping their old configs after they run 'make
oldconfig', right? At which point they'd be prompted for E1000_SUPPORT.
Presumably they'd think "That's odd. I'm sure I had that selected
before", then select it. Then oldconfig skips over CONFIG_E1000 because
it already knows the answer to that one and they're prompted with a
question about PCIe support. Now something is clearly strange. Perhaps
they look at the help text at this point and it says to go with 'Y' or
'M' ...
| Apr 11, 12:01 pm 2008 |
| Krzysztof Halasa | Re: [patch] e1000=y && e1000e=m regression fix
I guess PCIE. You already came across a similar problem.
Have I won something? :-)
--
Krzysztof Halasa
--
| Apr 11, 1:22 pm 2008 |
| Peter Zijlstra | Re: Using sparse to catch invalid RCU dereferences?
We could start by annotating those as well, for example:
__rcu spinlock_t tree_lock;
Then we would know that when tree lock is held the data structure is
stable and we can ommit the rcu_*() functions.
--
| Apr 11, 11:18 am 2008 |
| Johannes Berg | Re: Using sparse to catch invalid RCU dereferences?
Oh. Hmm, I guess that wouldn't really be possible to find at least not
with sparse right now. Though maybe we can add some sort of annotation
Ah. Yeah, but we probably need a "raw" accessor anyway if we're going to
Not sure if applying that to an array would work, and I wouldn't want to
convert it to pointers either. But I suppose you could declare the array
like this:
static struct foo * __attribute__((bitwise or address_space)) array[7];
which should, as far as I understand, apply ...
| Apr 11, 1:54 pm 2008 |
| Paul E. McKenney | Re: Using sparse to catch invalid RCU dereferences?
Good point! Though IIRC there are are cases where we are updating
one RCU-protected data structure while in an RCU read-side critical
section with respect to another RCU-protected data structure.
But it would probably best to start as you say rather than trying
to classify different RCU uses. :-)
Thanx, Paul
--
| Apr 11, 11:43 am 2008 |
| Pavel Machek | Re: file offset corruption on 32-bit machines?
Don't we have rlimit on max file size? I'd guess this could work
around it?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
| Apr 11, 12:26 pm 2008 |
| Ingo Molnar | Re: BUG: using smp_processor_id() during suspend with 2. ...
thanks Pavel, i picked this up into sched-devel.git - it makes sense
independently of whether it solves the warning.
Ingo
--
| Apr 11, 3:51 am 2008 |
| Rafael J. Wysocki | Re: BUG: using smp_processor_id() during suspend with 2. ...
Well, I'd say the BUG_ON()s are over the top in here (why to crash the system
even if it wouldn't have crashed otherwise?).
WARN_ON_ONCE() should be enough.
Thanks,
Rafael
--
| Apr 11, 8:29 am 2008 |
| Andi Kleen | Re: BUG: using smp_processor_id() during suspend with 2. ...
Please unapply them, as discussed in the earlier thread they are not
the correct fix. The original bug is still not found unfortunately, but it's
most likely somewhere in the KVM suspend/resume code.
-Andi
--
| Apr 11, 3:39 am 2008 |
| Ingo Molnar | Re: BUG: using smp_processor_id() during suspend with 2. ...
if sticking a WARN_ON_ONCE(!irqs_disabled()) somewhere would help in
making the breakage more visible i'd be glad to apply such a patch.
Ingo
--
| Apr 11, 3:40 am 2008 |
| Ingo Molnar | Re: BUG: using smp_processor_id() during suspend with 2. ...
thanks Jiri, i've applied both patches of yours. (let me know if there
are any updated patches)
do they solve the problem?
Ingo
--
| Apr 11, 3:25 am 2008 |
| Jiri Kosina | Re: BUG: using smp_processor_id() during suspend with 2. ...
Hi Ingo,
thanks, but I don't think they are the proper fix anymore. We'd rather
figure out why interrupts were enabled in the first place while the code
was running.
Which is quite difficult, because Zdenek doesn't seem to be able to
reproduce it, so we even don't know whether it has been caused by KVM or
not.
--
Jiri Kosina
SUSE Labs
--
| Apr 11, 3:34 am 2008 |
| Pavel Machek | Re: BUG: using smp_processor_id() during suspend with 2. ...
Well, we can discuss it personally.
Yes, it is probably bug that interrupts are enabled there. No, the bug
can't potentially bite the user because there should be just one CPU
"plugged in"... so it is kind of false-positive, too..
Does the warning go away with this?
Pavel
diff --git a/lib/smp_processor_id.c b/lib/smp_processor_id.c
index 6c90fb9..8195c37 100644
--- a/lib/smp_processor_id.c
+++ b/lib/smp_processor_id.c
@@ -35,6 +35,13 @@ unsigned int ...
| Apr 11, 3:49 am 2008 |
| Rafael J. Wysocki | Re: BUG: using smp_processor_id() during suspend with 2. ...
Agreed.
Besides, I'd like to learn what caused the problem to appear in the first
That would make sense.
Thanks,
Rafael
--
| Apr 11, 8:27 am 2008 |
| Pavel Machek | Re: BUG: using smp_processor_id() during suspend with 2. ...
Thanks!
(I just want to fix the underlying problem in suspend, too. I guess
I'll just do something like
diff --git a/drivers/base/sys.c b/drivers/base/sys.c
index 8e13fd9..adb7850 100644
--- a/drivers/base/sys.c
+++ b/drivers/base/sys.c
@@ -367,6 +367,7 @@ int sysdev_suspend(pm_message_t state)
/* Call auxillary drivers first */
list_for_each_entry(drv, &cls->drivers, entry) {
if (drv->suspend) {
+ BUG_ON(!in_interrupt());
ret = drv->suspend(sysdev, state);
...
| Apr 11, 3:54 am 2008 |
| Andi Kleen | Re: BUG: using smp_processor_id() during suspend with 2. ...
This means the CPU preempt sanity checking is effectively disabled
on UP kernels. Even though more and more people should run multi-core
now there is still a sizeable user base left on single core.
Don't think this is a good idea. We need even the UP testers.
If he wants this for suspend or machine check/oops (always useful there
to disable such warnings) then there should
be separate checks for this. Perhaps system_state could be enhanced for this?
-Andi
--
| Apr 11, 4:37 am 2008 |
| Ingo Molnar | Re: BUG: using smp_processor_id() during suspend with 2. ...
small note: please always use WARN_ON_ONCE() in such cases. That way
people's boxes dont blow up and the problem will be debuggable if the
box survives despite the error condition. (and thus it can be relayed to
kerneloops.org - all major distros have the package included already and
Fedora enables the client by default)
Ingo
--
| Apr 11, 4:09 am 2008 |
| Pavel Machek | Re: [PATCH] Fix booting pentium+ with dodgy TSC
CONFIG_X86_TSC means 'cpu has _some_ tsc, rdmsr will work'. If you are
confident noone will read broken tsc, please also remove the config
option. It is meaningless after your patch.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
| Apr 11, 8:43 am 2008 |
| Andy Whitcroft | Re: [patch] checkpatch: relax spacing and line length
Ok. I've just pushed out a testing version of checkpatch which is
identicle the 0.18 delta I just pushed to Andrew with the printk width
restriction lifted. Perhaps those interested might test it to see if it
whines appropriatly:
http://www.kernel.org/pub/linux/kernel/people/apw/checkpatch/checkpatch.pl-testing
I am going to be off next week, but will likely be dipping into email
now and again.
-apw
--
| Apr 11, 8:54 am 2008 |
| Jan Engelhardt | Re: [patch] checkpatch: relax spacing and line length
We have these people too. And by large, I find spell fixes
better than oh-I-decided-to-run-checkpatch-on-existing-code bombs.
--
| Apr 10, 9:24 pm 2008 |
| Soeren Sonnenburg | Apr 11, 5:11 am 2008 | |
| Soeren Sonnenburg | Re: suspend issue
lets focus on console only - no Xserver - no X - because already for
that it doesn't work.
Soeren
--
| Apr 10, 10:32 pm 2008 |
| Justin Mattock | Re: suspend issue
Do you think the problem may be with the xserver? Did you upgrade to 7.3?
Over here I did the upgrade to 7.3, but with testing with vesa there
seems to be no module with the xserver for vesa
or at least I haven't located it yet. On a positive note suspend does
work with the ati driver installer, the negative side is
it doesn't work without it. So from my perspective over here, Does
xserver(7.3) have vesa support?
regards;
--
Justin P. Mattock
--
| Apr 10, 10:18 pm 2008 |
| Justin Mattock | Re: suspend issue
Alright; I didn't get what you said at first, but now I see.
--
Justin P. Mattock
--
| Apr 10, 11:12 pm 2008 |
| Pavel Machek | Re: suspend issue
Hmm, you could bisect the resume regression, revert that, and then go
on to find the suspend regression.
...ok, not easy, I see.
Do you have kernel.org bugzilla # I could look at? Perhaps this can be
debugged using printks or something...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
| Apr 11, 3:57 am 2008 |
| Kasper Sandberg | Re: Realtek 8111c weirdness problems, apic/msi, and normal bug
Sorry for top posting, but its just easier in this case :)
I may have just gotten some new information to share.
I just built -git8. and the nic didnt work.. by booting with
noapic/nomsi i got it running though. then i did some tests, and
rebooted into the default(has worked mostly for me) noapic/msi boot.
Then it worked.
i did get some interresting information though, which i think may help
to fix the problem..
if its a boot where the nic works, i can usually rmmod/modprobe the
module ...
| Apr 10, 6:11 pm 2008 |
| Kasper Sandberg | Re: Realtek 8111c weirdness problems, apic/msi, and normal bug
I've got more information again. This is dmesg, and /proc/interrupts
from a livecd (systemrescuecd), its a .23.14, and only 1 nic works (the
one that doesent work on .25 noapic/msi), the other gets detected as
fiber.. strangely enough, the link detection works on the working nic,
on .23.14.
attached are /proc/interrupts and dmesg..
oh, and this is a 64bit livecd kernel, but it appears to act the same on
the 32bit kernel on the livecd..
This, and the previous information i have given, does ...
| Apr 11, 11:06 am 2008 |
| James Bottomley | Re: [PATCH bz #10388] doc: fix DMA-API function parameters
Acked-by: James Bottomley <James.Bottomley@HansenPartnership.com>
James
--
| Apr 11, 8:24 am 2008 |
| Tetsuo Handa | Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.
Sorry for slow response.
If write access is denied because of a rule "No modifications to /etc/passwd",
a rule "Allow modifications to /tmp/passwd" can no longer be enforced after
"mount --bind /etc/ /tmp/" or "mount --bind /etc/passwd /tmp/passwd" or
"mv /etc/passwd /tmp/passwd" or "ln /etc/passwd /tmp/passwd" is done.
"No modifications" (i.e. "forbid modifications") and
"Allow modifications" (i.e. "don't forbid modifications") are incompatible
rules as long as the rules are described ...
| Apr 11, 7:12 am 2008 |
| Toshiharu Harada | Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.
What annoyed us was the fact we didn't know how the merge would take place.
No nacks can mean no interests and does not mean the ack.
Coding issues/problems can be corrected, but we didn't know how to react with
different way of thinking and concepts. We were at a loss rather than
being frustrated.
BUT I know every those things can't be an excuse. I feel sorry for our
last posting. I apology you all and promise we will never do that.
We started following the thread and found it's very close ...
| Apr 10, 8:57 pm 2008 |
| Matthew Wilcox | Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.
That's a fundamental limitation of pathname-based security though.
If the same file exists in two places, you have to resolve the question
of which rule overrides the other.
In my role as a sysadmin, I would consider it a flaw if someone could
edit a file I'd marked uneditable -- simply by creating a hard-link to it.
If we look at existing systems, such as the immutable bit, those apply to
inodes, not to paths, so they can't be evaded. If a system such as TOMOYA
allows evasion this easily, ...
| Apr 11, 7:30 am 2008 |
| Toshiharu Harada | Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.
The diagram was meant to help clarifying things not to add/change
the information. I also like texts but IMO diagrams are useful
for starting arguments over networks.
Yes. Regarding the third option, Tetsuo is preparing to respond
My diagram worked very well for me. I noticed theoretically
there are four options.
option (1) "pass down the vfsmounts to the vfs helpers"
(let "vfsmount" bridge namespace and filesystems)
+ LSM needs less changes
- VFS and filesystems need more ...
| Apr 11, 4:48 am 2008 |
| Rafael J. Wysocki | Re: 2.6.25-rc6 regression - hang on resume
Please also test the kernel with the patch from
http://bugzilla.kernel.org/attachment.cgi?id=15736&action=view
applied.
Thanks,
Rafael
--
| Apr 11, 2:08 pm 2008 |
| Pavel Machek | Re: 2.6.25-rc6 regression - hang on resume
Could you get us any debugging output from s2ram? Or maybe even strace
it in both working and broken case, and comparing them? (You may want
to disable randomization so that results are comparable).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
| Apr 11, 2:04 pm 2008 |
| Roland McGrath | Re: [PATCH] powerpc TLF_RESTORE_SIGMASK
> This crashes my powerpc mac g5.
I had only tested with Linus's tree plus the small handful of post-2.6.25
cleanup patches I've posted in the last few weeks. To be precise it was
9597362d354f8655ece324b01d0c640a0e99c077 plus several of my cleanup patches
(that are probably all in -mm, but I'm not sure off hand).
I'd rebased my tree today to 783e391b7b5b273cd20856d8f6f4878da8ec31b3
anyway. I just tried the new kernel with the sigmask cleanups and only
a few other patches, and have no ...
| Apr 10, 6:36 pm 2008 |
| Andrew Morton | Re: [PATCH] powerpc TLF_RESTORE_SIGMASK
It's 100% repeatable and I bisected it to this change.
I expect you could repeat it by applying it to
http://userweb.kernel.org/~akpm/mmotm/ (or to -rc6-mm2, if I ever manage to
get it to boot on something) and using
http://userweb.kernel.org/~akpm/config-g5.txt
--
| Apr 10, 6:50 pm 2008 |
| Pavel Machek | Re: [RFC PATCH 0/4] Container Freezer: Reuse Suspend Freezer
Okay, freezer probably does what you want, but be warned that Linus is
not exactly in love with freezer. You probably can get away with using
it for user processes, but maybe you should drop him the line saying
you want to expand freezer usage and see what happens.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
| Apr 11, 4:49 am 2008 |
| Pavel Machek | Re: [RFC PATCH 3/4] Container Freezer: Implement freezer ...
Function headers are somehow non-traditional.
+ struct freezer *freezer;
+
+ if (!capable(CAP_SYS_ADMIN))
+ return ERR_PTR(-EPERM);
+
+ freezer = kzalloc(sizeof(struct freezer), GFP_KERNEL);
+ if (!freezer)
+ return ERR_PTR(-ENOMEM);
+
+ spin_lock_init(&freezer->lock);
+ freezer->state = STATE_RUNNING;
+ return &freezer->css;
+}
One space too many after "return" :-).
Hmm, returning pointer inside struct ...
| Apr 11, 4:49 am 2008 |
| Pavel Machek | Re: [RFC PATCH 1/4] Container Freezer: Add TIF_FREEZE fl ...
ACK.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
| Apr 11, 4:49 am 2008 |
| Randy Dunlap | Re: [PATCH v2] documentation: build source files in Docu ...
Those __kernel_* types shouldn't be used outside of the #ifdef __KERNEL__
block, should they?
Patch below fixes kernel side for me. Don't have any idea what it
may do to userspace users of the header file.
---
include/linux/types.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- mmotm-2008-0410-0157.orig/include/linux/types.h
+++ mmotm-2008-0410-0157/include/linux/types.h
@@ -200,8 +200,8 @@ typedef u32 resource_size_t;
#endif /* __KERNEL__ */
struct ustat ...
| Apr 10, 5:56 pm 2008 |
| Andrew Morton | Re: [PATCH v2] documentation: build source files in Docu ...
hm.
It'd be nice to know how git-x86 managed to make this happen. I haven't
looked, apart from noting that it doesn't seem to touch any of the relevant
files.
--
| Apr 10, 6:11 pm 2008 |
| Jörn | Re: [patch 4/15] fs/logfs/compr.c
Several years back (before logfs) I was planning to do just that. It
turned out that ipsec doesn't work in such a fashion, because each
connection is a stream. And the two block-oriented users, jffs2 and
cramfs just weren't worth it.
Might be a good idea by now. I guess it should become self-contained
code, so that jffs2, cramfs and ubifs can use it as well.
Jörn
--
Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text ...
| Apr 11, 3:41 am 2008 |
| Jörn | Re: [patch 10/15] fs/logfs/memtree.c
Indeed. Will change the definition.
Long-term I'd like to generalize the btree a bit and allow three key
variants: long, u64 and u8[]. Some people want to stuff a
(u64, u64, u8) tupel into a btree. For those it seems ideal to just
treat the key as an array and do memcmp() for comparison.
Jörn
--
You can't tell where a program is going to spend its time. Bottlenecks
occur in surprising places, so don't try to second guess and put in a
speed hack until you've proven that's where the ...
| Apr 11, 3:37 am 2008 |
| Dmitry Baryshkov | Re: [PATCH 6/6] Clocklib: use correct name for 3,6MHz clock
Hi,
BTW: Who should know that there should be a clock for a device?
E.g. on pxa, 3.6MHz clock is registered in clock.c, various CKEN-based
clocks are registered from pxa*.c. Which file should contain
host_name -> device_name allocation board config?
And BTW2: The sa1111 spec names the clock simply as "CLK". Should we use
this name?
--
With best wishes
Dmitry
--
| Apr 11, 3:25 am 2008 |
| David Miller | Re: WARNING: at net/ipv4/tcp_input.c:2173 tcp_mark_head_ ...
From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
Linus has pulled those changes in.
--
| Apr 11, 11:22 am 2008 |
| Ilpo Järvinen | Re: WARNING: at net/ipv4/tcp_input.c:2173 tcp_mark_head_ ...
Once Linus pulls net-2.6 fixes in, Robin's bug should be among the fixed
ones (NewReno&TSO fix). ...Whereas the bugzilla's report might be due to
another bug (it's different warn_on in any case).
--
i.
--
| Apr 11, 6:05 am 2008 |
| David Woodhouse | Re: [PATCH 1/2] HAVE_SET_RESTORE_SIGMASK
You're not likely to see demand for it from users. I believe glibc will
emulate it as best it can (which is not very well), and things will
appear to work.... most of the time.
--
dwmw2
--
| Apr 11, 6:40 am 2008 |
| Marcus Better | Re: [Bug 10327] New: keyboard stops responding after "if ...
This doesn't seem to help, it freezes without printing anything, and
there is nothing in the logs either.
--
| Apr 11, 4:12 am 2008 |
| Dan Williams | Re: What to do about the 2TB limit on HDIO_GETGEO ?
This thread fizzled out without a patch... here goes:
[ note: I'm replying via gmail, so if it has whitespace mangled the
patch please see the attachment ]
-----snip---->
sysfs: add /sys/dev/{char,block} to lookup sysfs path by major:minor
From: Dan Williams <dan.j.williams@intel.com>
Why?:
There are occasions where userspace would like to access sysfs
attributes for a device but it may not know how sysfs has named the
device or the path. For example what is the sysfs path ...
| Apr 11, 4:25 pm 2008 |
| Jiri Slaby | Re: [PATCH 1/2] Driver for Freescale 8610 and 5121 DIU
ping.
Seeing this in -mm yet. Are those comments all wrong? Are you working on it?
--
| Apr 11, 2:45 pm 2008 |
| Krzysztof Halasa | Re: [PATCH v2] Re: WAN: new PPP code for generic HDLC
Hi,
Linus just made 2.6.25-rclast (I hope), I understand 2.6.25 will have
broken drivers/net/wan/hdlc_ppp, any chance to apply the temporary
Kconfig ("depends on BROKEN") patch?
Would you like me to resend it?
TIA.
--
Krzysztof Halasa
--
| Apr 11, 2:35 pm 2008 |
| Peer Chen | RE: 2.6.24.X: SATA/AHCI related boot delay. - not with 2 ...
I checked our chipset errata, didn't find any useful information about
SRST and MSI issue of AHCI controller.
Looks like it's related to BIOS because different mode setting in BIOS
result in different behavior, could you point out the BIOS version and
also send me the 'lspci -xxx' dump of AHCI/non-raid mode?
One question, what kind of setting option for AHCI controller in your
BIOS, there are IDE/RAID/AHCI modes for the board of mine, no 'non-raid'
mode. Non-raid mode confuse me.
BRs
Peer ...
| Apr 11, 2:50 am 2008 |
| Tejun Heo | Re: 2.6.24.X: SATA/AHCI related boot delay. - not with 2 ...
Any progress?
--
tejun
--
| Apr 10, 11:06 pm 2008 |
| Volker Armin Hemmann | Re: 2.6.24.X: SATA/AHCI related boot delay. - not with 2 ...
2.6.25-rc8 is a 'no change'. AHCI+pci=3Dnomsi boots, AHCI without hangs.
with AHCI I also get this:
[ 0.363828] ------------[ cut here ]------------
[ 0.363828] WARNING: at drivers/ata/ahci.c:645 ahci_init_one+0x190/0xa3a=
()
[ 0.363828] Modules linked in:
[ 0.363828] Pid: 1, comm: swapper Not tainted 2.6.25-rc8 #2
[ 0.363828]
[ 0.363828] Call Trace:
[ 0.363828] [<ffffffff8022c5a5>] warn_on_slowpath+0x51/0x63
[ 0.363832] [<ffffffff80220061>] __ioremap+0x8/0x197
[ ...
| Apr 11, 4:55 am 2008 |
| Tejun Heo | Re: 2.6.24.X: SATA/AHCI related boot delay. - not with 2 ...
Aiee.... Can you please try 2.6.25-rc8 with both configurations? And
w/o systemrescuecd? Just seeing whether things mount properly or not is
good enough. There isn't much risk of losing data.
--
tejun
--
| Apr 10, 11:05 pm 2008 |
| Volker Armin Hemmann | Re: 2.6.24.X: SATA/AHCI related boot delay. - not with 2 ...
in the handbook it says that non-raid is for no-hotplug, no-ncq
configurations, ahci for hotplug and ncq configurations and raid to use the
nvidia raid functions. So there are three settings: non-raid, ahci and raid.
The bios version is P1.90 and the bios is definetly quirky - disabling IDE
because I don't have any IDE devices will make the BIOS hang while
posting ...
following three lspci -xxx. AHCI+pci=nomsi, non-raid+pci=nomsi and non-raid:
cat /lspci_ahci_2.6.25rc8_xxx
00:00.0 RAM ...
| Apr 11, 4:46 am 2008 |
| Sergei Shtylyov | Re: [PATCH 3/4] ide: add struct ide_dma_ops
Hello.
I'm still not seeing the code to deals with the PCI device ID 4 which may
be HPT36x, or HPT370, or HPT372[N] depending on revision -- you're always
Wrong -- HPT374 should have hpt37x_dma_ops...
MBR, Sergei
--
| Apr 11, 6:11 am 2008 |
| Ian Kent | Re: [PATCH 4/4] autofs4 - add miscelaneous device for ioctls
I've spent several weeks on this now and I'm having considerable
difficulty with the expire function.
First, I think using a raw netlink implementation defeats the point of
using this approach at all due to increased complexity. So I've used the
generic netlink facility and the libnl library for user space. While the
complexity on the kernel side is acceptable that isn't the case in user
space, the code for the library to issue mount point control commands has
more than doubled in size ...
| Apr 11, 12:02 am 2008 |
| Michael Kerrisk | Re: [PATCH] proc: Add RLIMIT_RTTIME to /proc/<pid>/limits
I'm curious: what scenarios require sub-millisecond timeouts?
--
Michael Kerrisk
Maintainer of the Linux man-pages project
http://www.kernel.org/doc/man-pages/
Want to report a man-pages bug? Look here:
http://www.kernel.org/doc/man-pages/reporting_bugs.html
--
| Apr 11, 2:16 am 2008 |
| Michael Kerrisk | Re: [PATCH] proc: Add RLIMIT_RTTIME to /proc/<pid>/limits
On the one hand, it seems reasonable to reset the counter. The POSIX
definition of sched_yield() says that it "shall force the running
thread to relinquish the processor until it again becomes the head of
its thread list".
On the other hand, what if this is the only runnable real-time
process? Then sched_yield() is effectively a no-op, and a runaway
process could lock up the system (which I gather is what RLIMIT_RTTIME
was primarily designed to prevent).
I don't really have a strong ...
| Apr 11, 1:01 am 2008 |
| Peter Zijlstra | Re: [PATCH] proc: Add RLIMIT_RTTIME to /proc/<pid>/limits
The us scale seemed the best fit in that it allows sub-ms granularity
while still allowing for quite long periods too. I'd preferred ns scale
as that is what we use throughout the scheduler where possible - but
that seemed too restrictive at the high end.
No real hard arguments either way.
--
| Apr 11, 2:01 am 2008 |
| Michael Kerrisk | Re: [PATCH] proc: Add RLIMIT_RTTIME to /proc/<pid>/limits
Peter,
I've been testing this patch. Above you seemed to be saying that
doing a sched_yield() would be equivalent to a sleep, causing the rt
counter to be reset to zero. Howver, the results I'm seeing suggest
that a sched_yield() does not cause the counter to be reset to zero
(i.e., despite calling sched_yield() at frequent intervals, the
process still encounters the RLIM_RTTIME soft limit and gets SIGXCPU).
Can you comment?
Cheers,
Michael
--
Michael Kerrisk
Maintainer of the ...
| Apr 11, 12:38 am 2008 |
| Michael Kerrisk | Re: [PATCH] proc: Add RLIMIT_RTTIME to /proc/<pid>/limits
Just to make sure me and the man page are clear: by tick-based, you
Okay.
And following on from my other conversation in this thread... What
should/will be the specified behavior w.r.t. resetting or not
resetting the timer on a sched_yield()?
Cheers,
Michael
--
Michael Kerrisk
Maintainer of the Linux man-pages project
http://www.kernel.org/doc/man-pages/
Want to report a man-pages bug? Look here:
http://www.kernel.org/doc/man-pages/reporting_bugs.html
--
| Apr 11, 2:27 am 2008 |
| Michael Kerrisk | Re: [PATCH] proc: Add RLIMIT_RTTIME to /proc/<pid>/limits
So I have another question: why is the granularity of this rlimit
microseconds? On the one hand, specifying limits down at the
microsecond level seems (to my naive eye) unlikely to be useful. (But
perhaps I have missed a thread where this was explained.) On the
other hand, it means that on 32-bit the largest time limit we can set
is ~4000 seconds, and I wonder if there are scenarios where it might
be useful to have larger limits than that.
Why not, for example, have a granularity of ...
| Apr 11, 1:56 am 2008 |
| Peter Zijlstra | Re: [PATCH] proc: Add RLIMIT_RTTIME to /proc/<pid>/limits
It appears you are right. I must have been staring at something else
than code when I said that :-(, yield() will indeed _not_ reset the
counter.
Now, I think it makes some sense to reset it, because we do try to play
nice by calling yield. OTOH we don't actually block and become
unrunnable - we'll still be contending for CPU time.
--
| Apr 11, 12:45 am 2008 |
| Peter Zijlstra | Re: [PATCH] proc: Add RLIMIT_RTTIME to /proc/<pid>/limits
I'm not sure, nor will they actually work atm since its tick based. But
I'm not wanting to exclude too many things, and 4k second upper limit is
plenty large.
--
| Apr 11, 2:21 am 2008 |
| Michael Kerrisk | Re: [PATCH] proc: Add RLIMIT_RTTIME to /proc/<pid>/limits
Okay -- thanks. I will make that clear in the man page.
Cheers,
Michael
--
Michael Kerrisk
Maintainer of the Linux man-pages project
http://www.kernel.org/doc/man-pages/
Want to report a man-pages bug? Look here:
http://www.kernel.org/doc/man-pages/reporting_bugs.html
--
| Apr 11, 2:38 am 2008 |
| Peter Zijlstra | Re: [PATCH] proc: Add RLIMIT_RTTIME to /proc/<pid>/limits
Yes, they are currently jiffy based - but I could do hrtimer if someone
I think I'll keep it as is; so sched_yield() will _not_ reset the
counter. The rationale is that the process didn't actually stop running
- it just got scheduled away.
--
| Apr 11, 2:32 am 2008 |
| john stultz | Re: gettimeofday() jumping into the future
On Thu, Apr 3, 2008 at 5:44 AM, James Courtier-Dutton
Yea. I see Thomas' patch was applied then reverted as it caused
problems with the TSC reseting over suspend and resume (since the
timekeeping core doesn't have a hook into the tsc clocksource to
inform it that the comparision is invalid, so the resume-time read
will always return the cycle_last value and not the actual smaller TSC
value).
This suggested bounding of how much a negative value is considered
valid would resolve this issue, ...
| Apr 11, 4:11 pm 2008 |
| Tejun Heo | Re: [PATCH 6/13] devres: implement managed iomap interface
Yes, please go ahead. In case it wasn't clear, I wasn't objecting to
the fix at all. I was just curious what could actually happen on x86.
--
tejun
--
| Apr 10, 7:08 pm 2008 |
| previous day | today | next day |
|---|---|---|
| April 10, 2008 | April 11, 2008 | April 12, 2008 |
