The following code in kobject_add
if (!kobj->k_name)
kobj->k_name = kobj->name;
if (!kobj->k_name) {
pr_debug("kobject attempted to be registered with no name!\n");
WARN_ON(1);
return -EINVAL;
}
doesn't look right to me. The second 'if' statement looks u
> Since 2.6.20-rc1 (tested both -rc1 and rc2), system notification sounds under
> KDE, and sound in games (e.g. TuxPaint) no longer seem to work on my T60
> thinkpad. Works fine under 2.6.19 though. The strange thing is e.g. Amarok
> still plays music fine.
Tis is on Kubuntu 6.06, BTW.
--
MST
-
Hello!
Thank you for your comments. It seems to me the issue was the readability.
It was my goal to improve the readability. I failed.
I personally prefer to use standard functions instead of writing code.
In my opinion using standard functions means less code that is easier to read.
Best rega
On Fri, 29 Dec 2006, Segher Boessenkool wrote:
>
> > I think what might be happening is that pdflush writes them out fine,
> > however we don't trap writes by the application _during_ that writeout.
>
> Yeah. I believe that more exactly it happens if the very last
> write to the page causes a w
I've re-published my work on quilt, sorry.
Index: linux-2.6.16.29/Documentation/vm_pps.txt
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6.16.29/Documentation/vm_pps.txt2006-12-29 14:36:36.507332384
+0800
Not sure if this is right. I just copied the other conversions.
Given every other driver added a 'NULL' too, I'm a bit suspicious
but I lack the hardware to test this.
drivers/macintosh/via-pmu-backlight.c: In function 'pmu_backlight_init':
drivers/macintosh/via-pmu-backlight.c:150: error: too few
On 28-12-2006 04:23, Sid Boyce wrote:
>
>
> I first saw the problem on the 64x2 box after upgrading to 2.6.19. The
> network appeared OK with ifconfig and route -n, but I had no network
> access. Pinging any other box, the box was responding, but no response
...
> barrabas:/usr/src/linux-2.6.20-r
drivers/macintosh/via-pmu.c: In function 'pmac_suspend_devices':
drivers/macintosh/via-pmu.c:2014: error: implicit declaration of function
'pm_prepare_console'
drivers/macintosh/via-pmu.c: In function 'pmac_wakeup_devices':
drivers/macintosh/via-pmu.c:2139: error: implicit declaration of function
Building the kernel with -Werror-implicit fails pretty fast with this..
arch/i386/kernel/process.c: In function '__switch_to':
arch/i386/kernel/process.c:645: error: implicit declaration of function
'load_user_cs_desc'
arch/i386/kernel/process.c: In function 'arch_add_exec_range':
arch/i386/kerne
On Thursday 28 December 2006 17:37, David Brownell wrote:
> > > > I think these helpers just obfuscate the code, just call
> > > > input_report_*() and input_sync() drectly like you used to do.
> > >
> > > Fair enough, I had a similar thought. Imre, could you do that update?
> >
> > Yes, the pat
is there some reason there are so many calls of the form
memset(addr, 0, PAGE_SIZE)
rather than the apparently equivalent invocation of
clear_page(addr)
the majority of architectures appear to define the clear_page() macro
in their include//page.h header file, but not entirely
identicall
On Thu, 28 Dec 2006 19:58:40 -0800
Daniel Walker <[EMAIL PROTECTED]> wrote:
> Got several of the messages below on 2.6.20-rc2-mm1 .
>
>
> Dec 29 03:34:08 10 kernel: [ 264.519401] BUG: at arch/i386/mm/highmem.c:50
> kmap_atomic()
doh, I had a copy-n-paste error in the debug code, thanks.
-
To
Dmitry Torokhov wrote:
On Friday 29 December 2006 00:17, Rene Herman wrote:
Yes, I do have that in my tree. From the looks of it it's probably not
surprising, but the following gets me blinking leds without the spurious
ACK messages. Maybe still useful to know?
diff --git a/drivers/input/s
On Thursday 28 December 2006 16:51, Avi Kivity wrote:
> Greg, /dev/kvm is a MISC_DYNAMIC_MINOR device. Is there any way of
> using it without udev? Should I allocate a static number?
You can write a small script that parses /proc/misc and creates the device,
like
# /sbin/mknod /dev/kvm c 10 `gr
> Quoting Adrian Bunk <[EMAIL PROTECTED]>:
> Subject: [-mm patch] infiniband/ulp/ipoib/ipoib_cm.c: make functions static
>
> On Thu, Dec 28, 2006 at 02:42:37AM -0800, Andrew Morton wrote:
> >...
> > Changes since 2.6.20-rc1-mm1:
> >...
> > git-infiniband.patch
> >...
> > git trees
> >...
>
>
>
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Sat, 23 Dec 2006 08:04:46 +1100
> On Fri, Dec 22, 2006 at 05:26:43PM +0100, Martin Willi wrote:
> > Installing an IPsec SA using old algorithm names (.compat) does not work
> > if the algorithm is not already loaded. When not using the PF_KEY
> > interfac
On Thursday 28 December 2006 5:31 am, Alan wrote:
> > Seems to me anyone really desperate to put PCI devices into a low
> > power mode, without driver support at the "ifdown" level, would be
> > able just "rmmod driver; setpci".
>
> Incorrect for very obvious reasons - there may be two devices d
On Friday 29 December 2006 00:17, Rene Herman wrote:
> Dmitry Torokhov wrote:
>
> >>> The change to suppress ACKs from paic blinking is already in Linus's
> >>> tree. I just tried booting with root=/dev/sdg and I had leds blinking
> >>> but no messages from atkbd were seen.
> >>>
> >>> Could it be
Dmitry Torokhov wrote:
The change to suppress ACKs from paic blinking is already in Linus's
tree. I just tried booting with root=/dev/sdg and I had leds blinking
but no messages from atkbd were seen.
Could it be that you loaded older kernel by accident? Does anybody
else still seeing "Spurios A
On Thursday 28 December 2006 23:20, Rene Herman wrote:
> Dmitry Torokhov wrote:
>
> > The change to suppress ACKs from paic blinking is already in Linus's
> > tree. I just tried booting with root=/dev/sdg and I had leds blinking
> > but no messages from atkbd were seen.
> >
> > Could it be that y
From: Balbir Singh <[EMAIL PROTECTED]>
Date: Fri, 29 Dec 2006 09:43:10 +0530
> page_mkclean_one() passes vma instead of the expected mm as argument1 to
> set_pte_at. Below is a simple fix (tested by compiling the kernel on
> powerpc). Please ignore the patch, if a fix has already been applied.
>
> David Chinner (DC) writes:
DC> So that mean's we'll have 2 separate mechanisms for marking
DC> pages as delalloc. XFS uses the BH_delay flag to indicate
DC> that a buffer (block) attached to the page is using delalloc.
>>
>> well, for blocksize=pagesize we can save 56 bytes on every pa
From: "Horst H. von Brand" <[EMAIL PROTECTED]>
Date: Thu, 28 Dec 2006 22:36:02 -0300
> Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > This email lists some known regressions in 2.6.20-rc2 compared to 2.6.19.
>
> Add that on SPARC64 boot fails due to missing /dev/root. Vanilla 2.6.19 and
> 2.6.19.1 wo
On 12/28/06, Jeff Chua <[EMAIL PROTECTED]> wrote:
> Are you sure the kvm_intel & kvm modules are loaded?
> Please check your dmesg.
I checked and it's loaded ...
Module Size Used by
kvm_intel 18572 0
kvm 46276 1 kvm_intel
Any chance of
Dmitry Torokhov wrote:
The change to suppress ACKs from paic blinking is already in Linus's
tree. I just tried booting with root=/dev/sdg and I had leds blinking
but no messages from atkbd were seen.
Could it be that you loaded older kernel by accident? Does anybody
else still seeing "Spurios A
page_mkclean_one() passes vma instead of the expected mm as argument1 to
set_pte_at. Below is a simple fix (tested by compiling the kernel on
powerpc). Please ignore the patch, if a fix has already been applied.
Signed-off-by: Balbir Singh <[EMAIL PROTECTED]>
---
mm/rmap.c |2 +-
1 file chan
Got this while trying to mount a ext3 block device. The host was running nfs
root
[ 929.130331] nfs: server 10.0.13.21 not responding, still trying
[ 931.346289] BUG: soft lockup detected on CPU#3!
[ 931.350860] [] show_trace_log_lvl+0x1a/0x2f
[ 931.356081] [] show_trace+0x12/0x14
[ 931.
Got several of the messages below on 2.6.20-rc2-mm1 .
Dec 29 03:34:08 10 kernel: [ 264.519401] BUG: at arch/i386/mm/highmem.c:50
kmap_atomic()
Dec 29 03:34:08 10 kernel: [ 264.524973] []
show_trace_log_lvl+0x1a/0x2f
Dec 29 03:34:08 10 kernel: [ 264.530129] [] show_trace+0x12/0x14
Dec 29
From: Zheng XiaoJun <[EMAIL PROTECTED]>
Add CIDC USB device to HID blacklist since it is actually a USB token
and has its own driver.
Signed-off-by: Zheng XiaoJun <[EMAIL PROTECTED]>
---
--- linux-2.6.19.1.orig/drivers/usb/input/hid-core.c2006-12-09
19:29:47.0 +0800
+++ linux-2.6.19.
From: Zheng XiaoJun <[EMAIL PROTECTED]>
Add CIDC USB device to HID blacklist since it is actually a USB token
and has its own driver.
Signed-off-by: Zheng XiaoJun <[EMAIL PROTECTED]>
---
--- linux-2.6.19.1.orig/drivers/usb/input/hid-core.c2006-12-09
19:29:47.0 +0800
+++ linux-2.6.19.
Subject: [PATCH] Input: HID - add CIDC USB device to HID blacklist
From: Zheng XiaoJun <[EMAIL PROTECTED]>
Add CIDC USB device to HID blacklist since it is actually a USB token
and has its own driver.
Signed-off-by: Zheng XiaoJun <[EMAIL PROTECTED]>
---
--- linux-2.6.19.1.orig/drivers/usb/input/
On Thursday 28 December 2006 16:45, Rene Herman wrote:
> Dave Jones wrote:
>
> > On Wed, Dec 27, 2006 at 10:32:53PM +0100, Rene Herman wrote:
>
> >> The bug where the kernel repetitively emits "atkbd.c: Spurious ACK
> >> on isa0060/serio0. Some program might be trying access hardware
> >> directl
I think what might be happening is that pdflush writes them out fine,
however we don't trap writes by the application _during_ that writeout.
Yeah. I believe that more exactly it happens if the very last
write to the page causes a writeback (due to dirty balancing)
while another writeback for t
On Sat, Dec 23, 2006 at 10:09:57PM +0300, Alex Tomas wrote:
>
> Good day,
>
> > David Chinner (DC) writes:
>
> DC> So that mean's we'll have 2 separate mechanisms for marking
> DC> pages as delalloc. XFS uses the BH_delay flag to indicate
> DC> that a buffer (block) attached to the page i
On Sat, Dec 23, 2006 at 09:27:18AM +, Christoph Hellwig wrote:
> On Sat, Dec 23, 2006 at 02:31:23PM +1100, David Chinner wrote:
> > > - ext4-delayed-allocation.patch
> > >delayed allocation itself, enabled by "delalloc" mount option.
> > >extents support is also required. currently it
On Thu, Dec 28, 2006 at 02:42:37AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.20-rc1-mm1:
>...
> git-ubi.patch
>...
> git trees
>...
This patch makes two needlessly global functions static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/mtd/ubi/vtbl.c | 12 ++-
On Thu, Dec 28, 2006 at 02:42:37AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.20-rc1-mm1:
>...
> git-dvb.patch
>...
> git trees
>...
usbvision_rvfree() can now become static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.20-rc2-mm1/drivers/media/video/usbvision/usbvis
On Thu, Dec 28, 2006 at 02:42:37AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.20-rc1-mm1:
>...
> git-infiniband.patch
>...
> git trees
>...
This patch makes some needlessly global functions static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/infiniband/ulp/ipoib/ipo
On Thu, 28 Dec 2006 17:38:38 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> in
> the hope that somebody else is working on this corruption issue and is
> interested..
What corruption issue? ;)
I'm finding that the corruption happens trivially with your test app, but
apparently doesn'
Btw,
much cleaned-up page tracing patch here, in case anybody cares (and
"test.c" attached, although I don't think it changed since last time).
The test.c output is a bit hard to read at times, since it will give
offsets in bytes as hex (ie "00a77664" means page frame 0a77, and byte
664
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> This email lists some known regressions in 2.6.20-rc2 compared to 2.6.19.
Add that on SPARC64 boot fails due to missing /dev/root. Vanilla 2.6.19 and
2.6.19.1 work fine, before 2.6.20-rc1 it broke. I checked the initrds for
both versions, the only differenc
This patch resolves the issue of running with numa=fake=X on kernel
command line on x86_64 machines that have big IO hole. While
calculating the size of each node now we look at the total hole size in
that range. Previously there were nodes that only had IO holes in them
causing kernel boot probl
On Fri, 29 Dec 2006 01:37:39 +0100 (CET) Tim Schmielau wrote:
> On Thu, 28 Dec 2006, Randy Dunlap wrote:
> > On Thu, 28 Dec 2006 21:48:30 + Russell King wrote:
> > > On Thu, Dec 28, 2006 at 01:32:46PM -0800, Randy Dunlap wrote:
> > > > On Thu, 28 Dec 2006 21:34:38 + Russell King wrote:
> >
On Thu, 28 Dec 2006, Randy Dunlap wrote:
> On Thu, 28 Dec 2006 21:48:30 + Russell King wrote:
> > On Thu, Dec 28, 2006 at 01:32:46PM -0800, Randy Dunlap wrote:
> > > On Thu, 28 Dec 2006 21:34:38 + Russell King wrote:
> > > > The whole "all*config" idea on ARM is utterly useless - you can _n
On Thu, Dec 28, 2006 at 02:42:37AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.20-rc1-mm1:
>...
> +add-i386-idle-notifier-take-3.patch
>...
> x86/x86_64 updates
>...
As already said:
- merges infrastructure without any users (the corresponding x86_64 code
is now merged and bloating the
> Good afternoon. :)
Good after-midnight :-).
> > > +Identifying GPIOs
> > > +-
> > > +GPIOs are identified by unsigned integers in the range 0..MAX_INT. That
> > > +reserves "negative" numbers for other purposes like marking signals as
> > > +"not available on this board", or
On Thu, 28 Dec 2006 21:48:30 + Russell King wrote:
> On Thu, Dec 28, 2006 at 01:32:46PM -0800, Randy Dunlap wrote:
> > On Thu, 28 Dec 2006 21:34:38 + Russell King wrote:
> > > The whole "all*config" idea on ARM is utterly useless - you can _not_
> > > get build coverage that way.
> >
> >
On Thu, 2006-12-28 at 15:56 -0800, Andrew Morton wrote:
> On Fri, 29 Dec 2006 10:34:21 +1100
> Rusty Russell <[EMAIL PROTECTED]> wrote:
>
> > This make sure it's paravirtualized correctly when CONFIG_PARAVIRT=y.
> >
> > Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
> >
> > diff -r 4ff04862239
On Thu, 28 Dec 2006, Linus Torvalds wrote:
> Ok,
> with the ugly trace capture patch, I've actually captured this corruption
> in action, I think.
>
> I did a full trace of all pages involved in one run, and picked one
> corruption at random:
>
> Chunk 14465 corrupted (0-75) (01423fb4-0
On Fri, 29 Dec 2006 10:34:21 +1100
Rusty Russell <[EMAIL PROTECTED]> wrote:
> This make sure it's paravirtualized correctly when CONFIG_PARAVIRT=y.
>
> Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
>
> diff -r 4ff048622391 drivers/md/raid6x86.h
> --- a/drivers/md/raid6x86.h Thu Dec 28 16:52
On Thu, 28 Dec 2006, Anton Altaparmakov wrote:
>
> But are chunks 3 and 4 in separate buffer heads? Sorry could not see it
> immediately from the output you showed...
No, this is a 4kB filesystem. A single bh per page.
> It is just that there may be a different cause rather than buffer dirty
On Dec 28 2006 19:53, Arjan van de Ven wrote:
>On Thu, 2006-12-28 at 19:41 +0100, Daniel Marjamäki wrote:
>> Hello all!
>>
>> I sent a patch with this content:
>>
>> - for (i = 0; i < MAX_PIRQS; i++)
>> - pirq_entries[i] = -1;
>> + memset(pirq_entries, -1, sizeof(pirq_e
On Fri, 29 Dec 2006, Rusty Russell wrote:
>
> This make sure it's paravirtualized correctly when CONFIG_PARAVIRT=y.
Why doesn't this code use "kernel_fpu_begin()" and "kernel_fpu_end()"?
The raid6 code is crap, and slower. It does "fsave/frstor" or movaps or
other crud, and the thing is, it sh
Could someone please test this?
From: Andrew Morton <[EMAIL PROTECTED]>
Various people have reported machines failing to boot since pci_bus_sem was
switched from a spinlock to an rwsem.
The reason for this is that these people had "ide=" on the kernel commandline,
and ide_setup() can end up ca
This make sure it's paravirtualized correctly when CONFIG_PARAVIRT=y.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
diff -r 4ff048622391 drivers/md/raid6x86.h
--- a/drivers/md/raid6x86.h Thu Dec 28 16:52:54 2006 +1100
+++ b/drivers/md/raid6x86.h Fri Dec 29 10:09:38 2006 +1100
@@ -75,13
Sergei Organov wrote:
> Hi, Jiri!
Hi.
> I'm so sorry, I don't know what I smoked yesterday, but the latest
> version you've sent me does not have this problem anymore! I think I
YES!
> copied compiled module to modules directory for different kernel and
> thus tested old code all the time. BTW,
On Thu, Dec 28, 2006 at 03:17:53PM -0800, Linus Torvalds wrote:
>
>
> On Fri, 29 Dec 2006, Adrian Bunk wrote:
> >
> > In Linus' tree, it currently only depends on EXPERIMENTAL.
> >
> > It seems commit 009af1ff78bfc30b9a27807dd0207fc32848218a wasn't intended
> > for Linus?
>
> I think we shoul
On Fri, 29 Dec 2006, Adrian Bunk wrote:
>
> In Linus' tree, it currently only depends on EXPERIMENTAL.
>
> It seems commit 009af1ff78bfc30b9a27807dd0207fc32848218a wasn't intended
> for Linus?
I think we should just remove it.
It's broken.
Nobody cares.
If people want to do concurrent stuf
On Thu, Dec 28, 2006 at 02:57:06PM -0800, Greg KH wrote:
> On Thu, Dec 28, 2006 at 11:39:09PM +0100, Adrian Bunk wrote:
> >
> > Subject: PCI_MULTITHREAD_PROBE breakage
> > References : http://lkml.org/lkml/2006/12/12/21
> > Submitter : Ben Castricum <[EMAIL PROTECTED]>
> > Caused-By : Greg K
On Thu, 28 Dec 2006, David Miller wrote:
>
> What happens when we writeback, to the PTEs?
Not a damn thing.
We clear the PTE's _before_ we even start the write. The writeback does
nothing to them. If the user dirties the page while writeback is in
progress, we'll take the page fault and re-d
On Thu, Dec 28, 2006 at 11:39:09PM +0100, Adrian Bunk wrote:
>
> Subject: PCI_MULTITHREAD_PROBE breakage
> References : http://lkml.org/lkml/2006/12/12/21
> Submitter : Ben Castricum <[EMAIL PROTECTED]>
> Caused-By : Greg Kroah-Hartman <[EMAIL PROTECTED]>
> commit 009af1ff78bfc3
On Thu, 28 Dec 2006 13:53:08 +0530
Suparna Bhattacharya <[EMAIL PROTECTED]> wrote:
> This patchset implements changes to make filesystem AIO read
> and write asynchronous for the non O_DIRECT case.
I did s/lock_page_slow/lock_page_blocking/g then merged all these
into -mm, thanks.
-
To unsubscrib
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Thu, 28 Dec 2006 14:37:37 -0800 (PST)
> So if we're not losing any dirty bits, what's going on?
What happens when we writeback, to the PTEs?
page_mkclean_file() iterates the VMAs and when it finds a shared
one it goes:
entry = ptep_
On 12/28/06, Arnd Bergmann <[EMAIL PROTECTED]> wrote:
On Thursday 28 December 2006 03:16, Jon Smirl wrote:
> BUG: scheduling while atomic: hald-addon-stor/0x2000/5078
> [] __sched_text_start+0x5f9/0xb00
> [] net_rx_action+0xb3/0x180
> [] __do_softirq+0x72/0xe0
> [] do_IRQ+0x45/0x80
This does
On 12/28/06, Arnd Bergmann <[EMAIL PROTECTED]> wrote:
On Thursday 28 December 2006 03:16, Jon Smirl wrote:
> BUG: scheduling while atomic: hald-addon-stor/0x2000/5078
> [] __sched_text_start+0x5f9/0xb00
> [] net_rx_action+0xb3/0x180
> [] __do_softirq+0x72/0xe0
> [] do_IRQ+0x45/0x80
This does
On Thu, 28 Dec 2006 14:09:00 +0530
Suparna Bhattacharya <[EMAIL PROTECTED]> wrote:
> +#define init_wait_bit_key(waitbit, word, bit)
> \
> + do {\
> + (waitbit)->key.flags = word;
This email lists some known regressions in 2.6.20-rc2 compared to 2.6.19.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way possibly
involve
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Thu, 28 Dec 2006 12:14:31 -0800 (PST)
> I get corruption - but the whole point is that it's very much pdflush that
> should be writing these pages out.
I think what might be happening is that pdflush writes them out fine,
however we don't trap write
Ok,
with the ugly trace capture patch, I've actually captured this corruption
in action, I think.
I did a full trace of all pages involved in one run, and picked one
corruption at random:
Chunk 14465 corrupted (0-75) (01423fb4-01423fff)
Expected 129, got 0
Written as
> > > I think these helpers just obfuscate the code, just call
> > > input_report_*() and input_sync() drectly like you used to do.
> >
> > Fair enough, I had a similar thought. Imre, could you do that update?
>
> Yes, the patch is against the OMAP tree.
Thanks ... still hoping that the OMAP t
On Thu, 28 Dec 2006, David Schwartz wrote:
Patents don't provide any ability to keep things secret. Copyright doesn't
apply to a creative work you made yourself, even if it describes the creative
work of another in *functional* detail.
in fact, to get a Patent you are required to explain the
On Thu, 2006-12-28 at 11:45 -0800, Andrew Morton wrote:
> On Thu, 28 Dec 2006 11:28:52 -0800 (PST)
> Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> >
> >
> > On Thu, 28 Dec 2006, Guillaume Chazarain wrote:
> > >
> > > The attached patch fixes the corruption for me.
> >
> > Well, that's a good h
> Do we have a right to reverse engineer hardware, or they are protected by
> patents or something similar that would prevent you from
> publishing results
> adn/or drivers (open source).
As I understand the issues, you have the right to reverse engineer hardware
except where the DMCA applies.
This email lists some known regressions in 2.6.20-rc2 compared to 2.6.19
with patches available
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any othe
On Thu, 28 Dec 2006, Russell King wrote:
> I'm talking about cross-builds... I don't know the spec of the machine,
> only that it's x86 based (I don't run it.)
>
> The last report at the beginning of this month said: 11 1/2 hours per
> git snapshot, which is apparantly for building a total of ab
On Thu, Dec 28, 2006 at 10:53:44PM +0100, Tim Schmielau wrote:
> On Thu, 28 Dec 2006, Russell King wrote:
> > Given that it takes about 8 to 12 hours to do a build cycle, that's
>
> My build cycle takes about 2 hours for 4 configs, on a decent AMD64
> system (running completely in tmpfs). Am I do
On Thu, Dec 28, 2006 at 12:24:22PM -0800, Randy Dunlap wrote:
> On Thu, 28 Dec 2006 11:55:04 -0800 Paul E. McKenney wrote:
>
> > list.h | 58 ++
> > 1 file changed, 58 insertions(+)
> >
> > diff -urpNa -X dontdiff linux-2.6.19/include/linu
On Tue, Dec 26, 2006 at 01:15:38AM +0100, Berthold Cogel wrote:
> Hello!
Hi Berthold!
> 'shutdown -h now' doesn't work for my system (Acer Extensa 3002 WLMi)
> with linux-2.6.20-rc kernels. The system reboots instead.
> I've checked linux-2.6.19.1 with an almost identical .config file
> (differe
On Thursday 28 December 2006 2:05 am, Arjan van de Ven wrote:
>
> > Hmm, then maybe it'd be worth updating that patch I just sent so that
> > the only change is to switch #includes for the extern decl ... i.e. to
> > "export" it only to other statically linked kernel code, rather than to
> > modul
On Wednesday 27 December 2006 9:49 am, Pavel Machek wrote:
> Hi!
Good afternoon. :)
> > +Identifying GPIOs
> > +-
> > +GPIOs are identified by unsigned integers in the range 0..MAX_INT. That
> > +reserves "negative" numbers for other purposes like marking signals as
> > +"not a
On Thu, 28 Dec 2006, Russell King wrote:
> Given that it takes about 8 to 12 hours to do a build cycle, that's
My build cycle takes about 2 hours for 4 configs, on a decent AMD64
system (running completely in tmpfs). Am I doing something wrong or are
you talking about native builds?
Tim
-
To u
CAP_LINUX_IMMUTABLE currently makes it impossible both to chattr +i or
chattr -i.
I think it would be convenient if there was someone to make it only
illegal for chattr -i. So that I could still make files unchangeable,
while not allowing myself to ever make them changeable again without
the cap
Hello Alan, Jeff,
Reading a paper on this new libata, I just want to try but failled yet for what said this
thread "ATAPI CDROM" ;_(.
I first test the latest stable 2.6.19.1 without luck, so I also want to try latest 2.6.20-rc2 unfortunately without more
success.
Here it was the test of new
On Thu, Dec 28, 2006 at 01:32:46PM -0800, Randy Dunlap wrote:
> On Thu, 28 Dec 2006 21:34:38 + Russell King wrote:
> > The whole "all*config" idea on ARM is utterly useless - you can _not_
> > get build coverage that way.
>
> Uh, can J. Random Developer submit patches to the ARM build system
>
Dave Jones wrote:
On Wed, Dec 27, 2006 at 10:32:53PM +0100, Rene Herman wrote:
The bug where the kernel repetitively emits "atkbd.c: Spurious ACK
on isa0060/serio0. Some program might be trying access hardware
directly" (sic) on a panic, thereby scrolling away the information
that would help
On Thursday 28 December 2006 03:16, Jon Smirl wrote:
> BUG: scheduling while atomic: hald-addon-stor/0x2000/5078
> [] __sched_text_start+0x5f9/0xb00
> [] net_rx_action+0xb3/0x180
> [] __do_softirq+0x72/0xe0
> [] do_IRQ+0x45/0x80
This doesn't seem to be related to libata at all. Like your
f
On Thu, 28 Dec 2006, Russell King wrote:
> To cover these, you need to build at least rpc_defconfig, lubbock_defconfig,
> netwinder_defconfig, badge4_defconfig, cerf_defconfig, ...etc...
OK, I'll try to do that.
Do I need to build all the configs in arch/arm/configs?
> The whole "all*config" ide
On Thu, 28 Dec 2006 21:34:38 + Russell King wrote:
> On Thu, Dec 28, 2006 at 10:18:12PM +0100, Tim Schmielau wrote:
> > On Thu, 28 Dec 2006, Al Viro wrote:
> >
> > > Uh-huh. How much of build coverage have you got with it?
> >
> > Well, as said in the patch description, I compiled alpha, ar
On Thu, Dec 28, 2006 at 01:24:30PM -0800, Linus Torvalds wrote:
> On Thu, 28 Dec 2006, Linus Torvalds wrote:
> >
> > What we need now is actually looking at the source code, and people who
> > understand the VM, I'm afraid. I'm gathering traces now that I have a good
> > test-case. I'll post my
On Thu, Dec 28, 2006 at 10:18:12PM +0100, Tim Schmielau wrote:
> On Thu, 28 Dec 2006, Al Viro wrote:
>
> > Uh-huh. How much of build coverage have you got with it?
>
> Well, as said in the patch description, I compiled alpha, arm, i386, ia64,
> mips, powerpc, and x86_64 with allnoconfig, defcon
Le 28.12.2006 11:42, Andrew Morton a écrit :
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc2/2.6.20-rc2-mm1/
Hello,
got this with 2.6.20-rc2-mm1, reverting
gregkh-driver-driver-core-fix-race-in-sysfs-between-sysfs_remove_file-and-read-write.patch
made it disappear.
On Thu, 28 Dec 2006, Linus Torvalds wrote:
>
> What we need now is actually looking at the source code, and people who
> understand the VM, I'm afraid. I'm gathering traces now that I have a good
> test-case. I'll post my trace tools once I've tested that they work, in
> case others want to h
Ravikiran G Thirumalai wrote:
Hi Andrew,
dev_to_node() does not work as expected on x86 and x86_64 as pointed out
earlier here:
http://lkml.org/lkml/2006/11/7/10
Following patch fixes it, please apply. (Note: The fix depends on support
for PCI domains for x86/x86_64)
Thanks, I'll merge into m
On Thu, 28 Dec 2006, Al Viro wrote:
> Uh-huh. How much of build coverage have you got with it?
Well, as said in the patch description, I compiled alpha, arm, i386, ia64,
mips, powerpc, and x86_64 with allnoconfig, defconfig, allmodconfig, and
allyesconfig as well as a few randconfigs on x86_64
On Thu, 28 Dec 2006, Randy Dunlap wrote:
> I'm half done with a patch to remove includes of smp_lock.h.
> For the files that I have patched, I checked each source file
> for all interfaces in smp_lock.h to verify that none of them
> are used, so the #include is just waste.
Yes, that's what I also
On Thu, Dec 28, 2006 at 09:58:17PM +0100, Tim Schmielau wrote:
> On Thu, 28 Dec 2006, Andrew Morton wrote:
>
> > On Thu, 28 Dec 2006 21:27:40 +0100 (CET)
> > Tim Schmielau <[EMAIL PROTECTED]> wrote:
> >
> > > After Al Viro (finally) succeeded in removing the sched.h #include in
> > > module.h re
Hi Andrew,
dev_to_node() does not work as expected on x86 and x86_64 as pointed out
earlier here:
http://lkml.org/lkml/2006/11/7/10
Following patch fixes it, please apply. (Note: The fix depends on support
for PCI domains for x86/x86_64)
Thanks,
Kiran
dev_to_node does not work as expected on x
On Tue, Dec 19, 2006 at 06:53:22PM +0100, Roman Zippel wrote:
> Hi,
>
> On Mon, 18 Dec 2006, Adrian Bunk wrote:
>
> > On Mon, Dec 18, 2006 at 11:41:59AM -0500, Robert P. J. Day wrote:
> > >
> > > Remove the note in the documentation that suggests people can use
> > > "requires" for dependencie
On Thu, 28 Dec 2006 12:46:44 -0800 Andrew Morton wrote:
> On Thu, 28 Dec 2006 21:27:40 +0100 (CET)
> Tim Schmielau <[EMAIL PROTECTED]> wrote:
>
> > After Al Viro (finally) succeeded in removing the sched.h #include in
> > module.h recently, it makes sense again to remove other superfluous
> > s
On Thu, 28 Dec 2006, Andrew Morton wrote:
> On Thu, 28 Dec 2006 21:27:40 +0100 (CET)
> Tim Schmielau <[EMAIL PROTECTED]> wrote:
>
> > After Al Viro (finally) succeeded in removing the sched.h #include in
> > module.h recently, it makes sense again to remove other superfluous
> > sched.h include
1 - 100 of 270 matches
Mail list logo
