Also fix the style of the switch statement while here.
arch/x86/kernel/quirks.c:384:3: warning: returning void-valued expression
arch/x86/kernel/quirks.c:387:3: warning: returning void-valued expression
arch/x86/kernel/quirks.c:390:3: warning: returning void-valued expression
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24/2.6.24-mm1/
>
> - The x86 git tree has been dropped due to runtime failure on one of my test
> machines
ouch - rather unlucky timing. You updated to a fresh x86.git tree which
Sam Ravnborg wrote:
> On Sun, Feb 03, 2008 at 05:54:41AM +0100, Ingo Molnar wrote:
>> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>>
I could not reproduce the bug myself but I think I spotted it. We
had a missing dependency to the _reg.h file. Try following patch and
let me now if it
My HP nx6325 started printing the ACPI Error's below starting at the commit
below.
thanks,
-Len
266b9f8727976769e2ed2dad77ac9295f37e321e is first bad commit
commit 266b9f8727976769e2ed2dad77ac9295f37e321e
Author: Thomas Gleixner <[EMAIL PROTECTED]>
Date: Wed Jan 30 13:34:06 2008 +0100
On Sun, 3 Feb 2008 20:31:10 -0800 (PST) Alex Dubov <[EMAIL PROTECTED]> wrote:
> Signed-off-by: Alex Dubov <[EMAIL PROTECTED]>
>
> --- mspro_block.c.orig2008-02-04 15:25:16.0 +1100
> +++ mspro_block.c 2008-02-04 15:26:28.226886699 +1100
> @@ -668,20 +668,13 @@
>
>
Tejun Heo wrote:
Evgen L wrote:
Hi all
I have a problem with my Intel SR1550 server (S5000PAL motheboard,
SATA/SAS controller, 5 SATA HDD Seagate ST9120822AS ).
The four drivers are in two md raid1, which striping by lvm and one
drive used separately. I have problem like below with two
On Mon, Feb 04, 2008 at 06:37:02PM +1300, martin f krafft wrote:
> also sprach Robin Lee Powell <[EMAIL PROTECTED]> [2008.02.04.1021 +1300]:
> > /usr/share/mdadm/checkarray --cron --all --quiet
>
> FYI:
> http://git.debian.org/?p=pkg-mdadm/mdadm.git;a=blob;f=debian/checkarray
>
> It
Hi Daniel,
Sorry for not replying right away.
Daniel Walker wrote:
> On Mon, 2008-01-28 at 16:12 -0800, Max Krasnyanskiy wrote:
>
>> Not accurate enough and way too much overhead for what I need. I know at
>> this point it probably
>> sounds like I'm talking BS :). I wish I've released the
On Sun, Jan 27, 2008 at 07:32:59PM +0530, Sripathi Kodi wrote:
> Hi Paul,
>
> On PPC, I see a disparity between clock_getres implementations in the
> vdso and syscall. I am using a IBM Openpower hardware and 2.6.24 kernel
> with CONFIG_HIGH_RES_TIMERS=y.
>
> clock_getres call for CLOCK_REALTIME
On Sun, Feb 03, 2008 at 10:13:53PM -0800, Russell Leidich wrote:
> All,
>
> You can imagine my dismay when I recently learned that, after all our
> collective effort, hardware thermal throttling does not work reliably
> on Barcelona, according to AMD. Due to NDA restrictions, I am unable
> to
P.S. This patch also moves the responsibility for enabling hardware
thermal control from the OS to the BIOS.
On Feb 3, 2008 10:13 PM, Russell Leidich <[EMAIL PROTECTED]> wrote:
> All,
>
> You can imagine my dismay when I recently learned that, after all our
> collective effort, hardware thermal
On Sat, Feb 02, 2008 at 05:01:53PM -0800, Harvey Harrison wrote:
> The pt_regs arg is never used, make it agree with the other
> definitions of smp_thermal_interrupt.
They are all completely independent.
>
> It doesn't look like smp_thermal_interrupt is even called on
> 32-bit...
It is called
From: Len Brown <[EMAIL PROTECTED]>
This patch is appropriate for supporting a 2.6.23-based products.
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
---
drivers/acpi/blacklist.c | 388 -
drivers/acpi/osl.c| 173 +++-
All,
You can imagine my dismay when I recently learned that, after all our
collective effort, hardware thermal throttling does not work reliably
on Barcelona, according to AMD. Due to NDA restrictions, I am unable
to provide further details.
But the effort has not been a waste; whenever AMD
also sprach Robin Lee Powell <[EMAIL PROTECTED]> [2008.02.04.1021 +1300]:
> /usr/share/mdadm/checkarray --cron --all --quiet
FYI:
http://git.debian.org/?p=pkg-mdadm/mdadm.git;a=blob;f=debian/checkarray
It basically does
echo check > /sys/block/$array/md/sync_action
for all arrays.
--
Paul Jackson wrote:
> Max wrote:
>> Paul, I actually mentioned at the beginning of my email that I did read that
>> thread
>> started by Peter. I did learn quite a bit from it :)
>
> Ah - sorry - I missed that part. However, I'm still getting the feeling
> that there were some key points in
On Sun, 2008-02-03 at 14:23 -0400, Kevin Winchester wrote:
> And git blame lead me to the following commit:
>
> commit 266b9f8727976769e2ed2dad77ac9295f37e321e
> Author: Thomas Gleixner <[EMAIL PROTECTED]>
> Date: Wed Jan 30 13:34:06 2008 +0100
>
> x86: fix ioremap RAM check
>
>
On Mon, Feb 04, 2008 at 10:16:23AM +0800, Peter Teoh wrote:
> Compiling the latest linus tree will encounter the following warning:
>
> WARNING: kernel/built-in.o(.text+0x2f5e2): Section mismatch in
> reference from the function enable_nonboot_cpus() to the function
> .cpuinit.text:_cpu_up()
>
On Sunday 03 February 2008 17:15:02 Andrew Morton wrote:
> On Thu, 17 Jan 2008 17:57:58 +1100 Rusty Russell <[EMAIL PROTECTED]>
wrote:
> > I assume that these ancient network drivers were trying to find out if
> > an irq is available. eepro.c expecting +EBUSY was doubly wrong.
> >
> > I'm not
On Mon, Feb 04, 2008 at 10:57:18AM +0800, Peter Teoh wrote:
> During compilation of the linus tree the following warnings are encountered:
>
> WARNING: kernel/built-in.o(.data+0x2480): Section mismatch in
> reference from the variable workqueue_cpu_callback_nb.14223 to the
> function
Hi,
You can set a real-time priority to the user-process.
Ramgopal Kota
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of veerasena reddy
Sent: Friday, February 01, 2008 11:45 PM
To: linux-kernel.org; linux-mips
Subject: (no subject)
Hi,
I have a
On Sun, Feb 03, 2008 at 08:00:47PM +, Adrian McMenamin wrote:
> From: Adrian McMenamin
>
> This patch fixes the regression noted here:
> http://lkml.org/lkml/2008/1/26/189 as well as whitespace issues in the
> previous commit of this driver and the memory leaks noted here:
>
On Fri, Feb 01, 2008 at 09:02:40PM +0100, Bastian Blank wrote:
> Fix ext4 bitops.
>
> Signed-off-by: Bastian Blank <[EMAIL PROTECTED]>
>
> diff --git a/include/asm-powerpc/bitops.h b/include/asm-powerpc/bitops.h
> index 220d9a7..d0980df 100644
> --- a/include/asm-powerpc/bitops.h
> +++
On Mon, Feb 04, 2008 at 09:49:24AM +0800, Peter Teoh wrote:
> In kernel/cpu.c, there exists API that is declared as __cpuinit, and
> at the same time exported via EXPORT_SYMBOL().
>
> Can these two attribute coexists at the same time? I mean, when it
> is declared with EXPORT_SYMBOL, according
On Sun, Feb 03, 2008 at 01:39:02PM +0100, Geert Uytterhoeven wrote:
> On Sun, 3 Feb 2008, Heiko Carstens wrote:
> > On Fri, Feb 01, 2008 at 10:04:04PM +0100, Bastian Blank wrote:
> > > On Fri, Feb 01, 2008 at 12:22:57PM -0800, Andrew Morton wrote:
> > > > On Fri, 1 Feb 2008 21:02:08 +0100
> > > >
On Mon, Jan 28, 2008 at 05:35:58PM -0600, thus spake Robert Hancock:
> Any ideas guys? When the drive is plugged in, a stream of this shows up. It
> would seem like the controller is throwing hotplug interrupts but we never
> seem to get a "SATA link up". This is on nForce3, btw.
I just
On Sun, Feb 03, 2008 at 08:14:45PM -0800, Arjan van de Ven wrote:
> David Chinner wrote:
> >Hi Nick,
> >
> >When Matthew was describing this work at an LCA presentation (not
> >sure whether you were at that presentation or not), Zach came up
> >with the idea that allowing the submitting
Dmitry Adamushko wrote:
---
Subject: latencytop: optimize LT_BACKTRACEDEPTH loops a bit.
It looks like there is no need to loop any longer when 'same == 0'.
Signed-off-by: Dmitry Adamushko <[EMAIL PROTECTED]>
looks good to me; Ingo can you queue this one up ?
--
To unsubscribe from this
Although this looks strange:
gpa = vcpu->arch.mmu.gva_to_gpa(vcpu, (gva_t)tmp);
it is correct as tmp is just used a dummy for this one call and
not used again, just needed a stand-in. tmp will be used in a
kmap_atomic/kunmap_atomic pair right afterwards. Use the gva_t
cast to keep types happy.
Kamalesh Babulal wrote:
> Hi Andrew,
>
> The 2.6.24-mm1 kernel build fails with
>
> arch/x86/mm/pgtable_32.c: In function `pgd_mop_up_pmds':
> arch/x86/mm/pgtable_32.c:302: warning: passing arg 1 of `pmd_free' from
> incompatible pointer type
> arch/x86/mm/pgtable_32.c:302: error: too few
Signed-off-by: Alex Dubov <[EMAIL PROTECTED]>
--- mspro_block.c.orig 2008-02-04 15:25:16.0 +1100
+++ mspro_block.c 2008-02-04 15:26:28.226886699 +1100
@@ -668,20 +668,13 @@
spin_lock_irqsave(>q_lock, flags);
if (rc >= 0)
-
Jan Engelhardt wrote:
Hi,
sad to say, but f06e4ec... breaks booting the kernel in vmware
(bisected). Booting just stops after
Checking for 'hlt' instruction...
commit f06e4ec1c15691b0cfd2397ae32214fa36c90d71
Author: Ingo Molnar <[EMAIL PROTECTED]>
Date: Wed Jan 30 13:32:39 2008
David Chinner wrote:
Hi Nick,
When Matthew was describing this work at an LCA presentation (not
sure whether you were at that presentation or not), Zach came up
with the idea that allowing the submitting application control the
CPU that the io completion processing was occurring would be a good
Adjust the definition of lookup_address to take an unsigned long
level argument. Adjust callers in xen/mmu.c that pass in a
dummy variable.
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
Ingo, sorry for missing this hunk in my previous signedness fixes for
lookup_address.
Hi Andrew,
The 2.6.24-mm1 kernel build fails with
arch/x86/mm/pgtable_32.c: In function `pgd_mop_up_pmds':
arch/x86/mm/pgtable_32.c:302: warning: passing arg 1 of `pmd_free' from
incompatible pointer type
arch/x86/mm/pgtable_32.c:302: error: too few arguments to function `pmd_free'
I have
My review comments for this patch remain unaddressed so
I have put it on hold.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
Note: as said in the comments, this is currently only for the
VisioBraille device, but having this in the vanilla kernel will help a
lot to get people testing drivers for other devices, as they will not
have to recompile a patched kernel but just insert test modules
(remember that for blind people
This adds a minimalistic braille screen reader support.
This is meant to be used by blind people e.g. on boot failures or when /
cannot be mounted etc and thus the userland screen readers can not work.
Signed-off-by: Samuel Thibault <[EMAIL PROTECTED]
---
YOSHIFUJI Hideaki wrote:
> In article <[EMAIL PROTECTED]> (at Mon, 04 Feb 2008 08:47:29 +0800), Li Zefan
> <[EMAIL PROTECTED]> says:
>
>> compile error building without CONFIG_FS_PROC.
> :
>> The exit method should have no return values...
>
> Have you really tested this with CONFIG_FS_PROC?
>
The following is to fix the following warning (see earlier email):
WARNING: kernel/built-in.o(.data+0x7c00): Section mismatch in
reference from the variable relay_hotcpu_callback_nb.18789 to the
function .cpuinit.text:relay_hotcpu_callback()
The variable relay_hotcpu_callback_nb.18789 references
During compilation of the linus tree the following warnings are encountered:
WARNING: kernel/built-in.o(.data+0x2480): Section mismatch in
reference from the variable workqueue_cpu_callback_nb.14223 to the
function .devinit.text:workqueue_cpu_callback()
The variable
On Sat, Feb 02, 2008 at 11:03:47PM +1100, Stephen Rothwell wrote:
> now that platform_device_register_simple() takes a "const chat *".
>
Presumably you mean 'const char *'. Also, in the future, please don't use
a subject purposely crafted to thwart git-am. Trivial patches are enough
of a nuisance
On Feb 3, 2008 3:38 PM, Yinghai Lu <[EMAIL PROTECTED]> wrote:
> wonder if you still need that patch after following patch is a applied.
>
> YH
>
> diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c
> index 608152a..f645413 100644
> --- a/arch/x86/kernel/aperture_64.c
> +++
Hi Milan Broz
On Sun, 2008-02-03 at 23:06 +0100, Milan Broz wrote:
> Are you sure, that your USB-stick is not faulty ?
I actually tested the stick, too. But I consider problems in the stick
(you mean the key-holding stick, do you?) as highly unlikely.
If the key would be wrong a good crypto
In article <[EMAIL PROTECTED]> (at Mon, 04 Feb 2008 08:47:29 +0800), Li Zefan
<[EMAIL PROTECTED]> says:
> compile error building without CONFIG_FS_PROC.
:
> The exit method should have no return values...
Have you really tested this with CONFIG_FS_PROC?
--yoshfuji
--
To unsubscribe from this
Compiling the latest linus tree will encounter the following warning:
WARNING: kernel/built-in.o(.text+0x2f5e2): Section mismatch in
reference from the function enable_nonboot_cpus() to the function
.cpuinit.text:_cpu_up()
The function enable_nonboot_cpus() references
the function __cpuinit
On Mon, Feb 04, 2008 at 01:50:37AM +0100, Patrick Ringl wrote:
> Hello,
>
> I am suffering from the following (usb-related?) problem:
>
> I have several different mashines - all x86 architecture - just lets call
> them mashineA, mashineB and mashineC.
Is the kernel the same on all of these
On Sun, Feb 03, 2008 at 10:52:52AM +0100, Nick Piggin wrote:
> On Fri, Jul 27, 2007 at 06:21:28PM -0700, Suresh B wrote:
> >
> > Second experiment which we did was migrating the IO submission to the
> > IO completion cpu. Instead of submitting the IO on the same cpu where the
> > request arrived,
In kernel/cpu.c, there exists API that is declared as __cpuinit, and
at the same time exported via EXPORT_SYMBOL().
Can these two attribute coexists at the same time? I mean, when it
is declared with EXPORT_SYMBOL, according to include/linux/module.h,
it is placed in a __ksymtab section, and
Hi Peter,
Peter Zijlstra wrote:
move update_process_times() out from under xtime_lock.
Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
---
arch/alpha/kernel/time.c | 15 ---
arch/arm/common/time-acorn.c |2 --
arch/arm/mach-at91/at91sam926x_time.c |
On Sun, Feb 03, 2008 at 08:00:47PM +, Adrian McMenamin wrote:
> From: Adrian McMenamin
>
This is useless if you are submitting the patch, especially if you're
missing a mail address.
> This patch fixes the regression noted here:
> http://lkml.org/lkml/2008/1/26/189 as well as whitespace
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ismail Dönmez wrote:
| What I meant to ask was what does "per-process securebits" brings as
extra.
It allows you to create a legacy free process tree. For example, a
chroot, or container (which Serge can obviously explain in more detail),
Ingo Molnar wrote:
> * Kevin Winchester <[EMAIL PROTECTED]> wrote:
>
>>> x86: fix ioremap RAM check
>>>
>>> Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
>>> Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
>> Lucky first try - reverting this commit fixes the problem for me. Any
At Monday 04 February 2008 around 02:49:29 Andrew G. Morgan wrote:
> Another way to put this is that there needs to be some application code
> and documentation available to guide the way... Adding such things to
> the example programs in libcap2 helped me find the 24-rc2 CAP_SETPCAP
> bug and
Hello,
I am suffering from the following (usb-related?) problem:
I have several different mashines - all x86 architecture - just lets
call them mashineA, mashineB and mashineC.
Anyway, mashineA has a severe problem with a
Kingston-USB-pendrive(2gig). I simply cant install anything on it - the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ismail � wrote:
| At Sunday 03 February 2008 around 08:18:12 Andrew Morton wrote:
|> So how do we ever get to the stage where we can recommend that
distributors
|> turn these things on, and have them agree with us?
|
| FWIW with my distributor hat on
compile error building without CONFIG_FS_PROC.
net/ipv4/fib_frontend.c: In function 'fib_net_init':
net/ipv4/fib_frontend.c:1032: error: implicit declaration of function 'fib_proc_
init'
net/ipv4/fib_frontend.c: In function 'fib_net_exit':
net/ipv4/fib_frontend.c:1047: error: implicit declaration
On Sun, 3 Feb 2008 16:32:55 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote:
> If nothing happens (often the case), please raise a report at
> bugzilla.kernel.org so we can track the presence of the regression.
argh, please ignore. I got bitten by the
On Sat, 26 Jan 2008 15:06:25 +0100 Toralf Förster <[EMAIL PROTECTED]> wrote:
> I use a 1-liner for a simple performance check : "time factor
> 819734028463158891"
> Here is the result for the new (Gentoo) kernel 2.6.24:
>
> With the ondemand governor of the I get:
>
> [EMAIL PROTECTED] ~/tmp
On Mon, 28 Jan 2008 18:16:35 +0300 Pavel Emelyanov <[EMAIL PROTECTED]> wrote:
> This is the first stop (of two) in removing the kill_pgrp_info.
>
> All the users of this function are in kernel/signal.c, but all
> they need is to call __kill_pgrp_info() with the tasklist_lock
> read-locked.
>
>
On Sun, Feb 03, 2008 at 09:02:08PM +, Al Viro wrote:
> On ppc64 relocs => r/w, AFAICS. On other targets we might have any number
> of other rules.
And -fpic/PIC => (relocs => r/w) because of the DT_TEXTREL crap. Not
of immediate interest to the kernel though.
OG.
--
To unsubscribe from
Hi!
Here's updated diff. Video & Makefiles by hpa, rest by me ;-).
Pavel
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 8978e98..949b8eb 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -192,8 +192,8 @@
On Sun, 2008-02-03 at 23:03 +0100, Sam Ravnborg wrote:
> Hi James.
>
> Nitpicking only.
>
> Sam
Thanks for the review.
> > +
> > if MISC_DEVICES
>
> Unrelated change.
Yes, removed it.
> > +config ENCLOSURE_SERVICES
> > + tristate "Enclosure Services"
> > + default n
> Not needed.
On Mon 2008-02-04 00:59:38, Rafael J. Wysocki wrote:
> On Monday, 4 of February 2008, Pavel Machek wrote:
> > Hi!
> >
> > > BTW, I don't like the way in which the 'struct wakeup_header' fields are
> > > reproduced in rm/wakeup.S very much, because it makes the code fragile.
> > > It might be
On Monday, 4 of February 2008, Pavel Machek wrote:
> Hi!
>
> > - Could the real mode directory be called just "real-mode" or something like
> > this ("rm" is not very meaningful :-))?
> >
> > Apart from the above and the _WAKEUP hacks mentioned elsewhere, it looks
> > okay
> > (from a very
On Monday, 4 of February 2008, Pavel Machek wrote:
> Hi!
>
> > BTW, I don't like the way in which the 'struct wakeup_header' fields are
> > reproduced in rm/wakeup.S very much, because it makes the code fragile.
> > It might be better to define the offsets in asm-offsets*.c and refer to them
> >
Hi!
> BTW, I don't like the way in which the 'struct wakeup_header' fields are
> reproduced in rm/wakeup.S very much, because it makes the code fragile.
> It might be better to define the offsets in asm-offsets*.c and refer to them
> relative to wakeup_header (if possible).
If you can do that..
> it looks okay
> (from a very high orbit).
It should look better from closer look. Reusing trampoline_64.S
instead of cut gets us rid of some really nasty assembly
;-).
Pavel
--
(english)
On Monday, 4 of February 2008, Pavel Machek wrote:
> On Mon 2008-02-04 00:20:14, Rafael J. Wysocki wrote:
> > On Sunday, 3 of February 2008, Rafael J. Wysocki wrote:
> > > On Sunday, 3 of February 2008, Pavel Machek wrote:
> > > > Hi!
> > > >
> > > > > > This version works on 32-bit, and builds
Hi!
> - Could the real mode directory be called just "real-mode" or something like
> this ("rm" is not very meaningful :-))?
>
> Apart from the above and the _WAKEUP hacks mentioned elsewhere, it looks okay
> (from a very high orbit).
Wakeup hacks? You mean those #ifdef WAKEUP in video code?
Hi!
> Below is the arch/x86/kernel/acpi/sleep.c part without the warnings
> (untested).
>
> It still contains some hardcoded magic numbers and extern declarations, so
> I guess the #include list is not complete or another header is necessary.
>
> BTW:
> 1) why exactly is acpi_wakeup_address
On Monday, 4 of February 2008, Rafael J. Wysocki wrote:
> On Sunday, 3 of February 2008, Rafael J. Wysocki wrote:
> > On Sunday, 3 of February 2008, Pavel Machek wrote:
> > > Hi!
> > >
> > > > > This version works on 32-bit, and builds on 64-bit (but I'm pretty
> > > > > sure it does not work.
On Mon 2008-02-04 00:20:14, Rafael J. Wysocki wrote:
> On Sunday, 3 of February 2008, Rafael J. Wysocki wrote:
> > On Sunday, 3 of February 2008, Pavel Machek wrote:
> > > Hi!
> > >
> > > > > This version works on 32-bit, and builds on 64-bit (but I'm pretty
> > > > > sure it does not work.
wonder if you still need that patch after following patch is a applied.
YH
diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c
index 608152a..f645413 100644
--- a/arch/x86/kernel/aperture_64.c
+++ b/arch/x86/kernel/aperture_64.c
@@ -278,7 +278,7 @@ void __init
On Sun, Feb 03, 2008 at 06:04:24PM +0100, Christer Weinigel wrote:
> Pekka Enberg wrote:
>> Why are we discussing this again? The Linux kernel is distributed
>> under the GPLv2 and even though there are some legal gray areas
>> regarding derived work (think nvidia and ati binary blobs here), the
On Sunday, 3 of February 2008, Rafael J. Wysocki wrote:
> On Sunday, 3 of February 2008, Pavel Machek wrote:
> > Hi!
> >
> > > > This version works on 32-bit, and builds on 64-bit (but I'm pretty
> > > > sure it does not work. 32-bit code probably needs to go into rm/)
> > > >
> > >
> > >
On Sun, 3 Feb 2008 15:02:46 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> With current mainline I'm getting intermittent hangs here:
>
> http://userweb.kernel.org/~akpm/p2033590.jpg
>
> with this config:
>
> http://userweb.kernel.org/~akpm/config-sony.txt
>
> on the Vaio.
> > > The changes look good to me.
> >
> > They feel unfinished to me though. :)
> >
> > Like using "jiffies" instead of a clocksource, which makes trouble
> > since the timing covers periods with IRQs disabled. And the test
> > mode parameter needs work.
>
> Well, I'd say that timing has
From: Randy Dunlap <[EMAIL PROTECTED]>
Fix PCI kernel-doc warning:
Warning(linux-2.6.24-git12//drivers/pci/pci-acpi.c:166): No description found
for parameter 'hid'
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
drivers/pci/pci-acpi.c |1 +
1 file changed, 1 insertion(+)
---
From: Randy Dunlap <[EMAIL PROTECTED]>
Fix drivers/base/ missing kernel-doc parameters:
Warning(linux-2.6.24-git12//drivers/base/driver.c:133): No description found
for parameter 'drv'
Warning(linux-2.6.24-git12//drivers/base/driver.c:133): No description found
for parameter 'kobj'
From: Randy Dunlap <[EMAIL PROTECTED]>
kernel-doc for block/:
- add missing parameters
- fix one function's parameter list (remove blank line)
- add 2 source files to docbook for non-exported kernel-doc functions
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
From: Randy Dunlap <[EMAIL PROTECTED]>
Fix mtrr kernel-doc warning:
Warning(linux-2.6.24-git12//arch/x86/kernel/cpu/mtrr/main.c:677): No
description found for parameter 'end_pfn'
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
arch/x86/kernel/cpu/mtrr/main.c |1 +
1 file changed, 1
From: Randy Dunlap <[EMAIL PROTECTED]>
Fix kernel-doc warnings in audit.c.
Warning(linux-2.6.24-git12//kernel/audit.c:1268): No description found for
parameter 'string'
Warning(linux-2.6.24-git12//kernel/audit.c:1268): No description found for
parameter 'len'`
Signed-off-by: Randy Dunlap
With current mainline I'm getting intermittent hangs here:
http://userweb.kernel.org/~akpm/p2033590.jpg
with this config:
http://userweb.kernel.org/~akpm/config-sony.txt
on the Vaio. Sometimes it boots (then hits another different hang),
sometimes it gets stuck there.
--
To
Hi!
> > The changes look good to me.
>
> They feel unfinished to me though. :)
>
> Like using "jiffies" instead of a clocksource, which makes trouble
> since the timing covers periods with IRQs disabled. And the test
> mode parameter needs work.
Well, I'd say that timing has bigger problem,
On Sunday, 3 of February 2008, David Brownell wrote:
> > > See the appended; it includes more of Ingo's suggestions.
> > >
> > > Since this is increasingly unrelated to the "sleepy linux" concept
> > > (a version of what systems like OLPC, N700, and N800 are doing), I
> > > got rid of the
> > See the appended; it includes more of Ingo's suggestions.
> >
> > Since this is increasingly unrelated to the "sleepy linux" concept
> > (a version of what systems like OLPC, N700, and N800 are doing), I
> > got rid of the "sleepy.c" file.
>
> The changes look good to me.
They feel
On Sun, 2008-02-03 at 21:46 +0100, Kristoffer Ericson wrote:
> shortlog:
> The HP Jornada 6xx series have simple leds thats able to produce green or red
> light.
> This patch enables the leds to be used by the kernel and/or userland.
>
> signed-off-by: Kristoffer Ericson <[EMAIL PROTECTED]>
>
>
On Sunday, 3 of February 2008, Pavel Machek wrote:
> Hi!
>
> > > This version works on 32-bit, and builds on 64-bit (but I'm pretty
> > > sure it does not work. 32-bit code probably needs to go into rm/)
> > >
> >
> > Do you have an updated version or is this the latest one?
>
> I'm glad
On Sun, Feb 03, 2008 at 11:24:07PM +0100, Pavel Machek wrote:
> On Sun 2008-02-03 19:49:31, Sam Ravnborg wrote:
> > On Sun, Feb 03, 2008 at 07:16:48PM +0100, Pavel Machek wrote:
> > > Hi!
> > >
> > > > > This version works on 32-bit, and builds on 64-bit (but I'm pretty
> > > > > sure it does not
On Sun 2008-02-03 19:49:31, Sam Ravnborg wrote:
> On Sun, Feb 03, 2008 at 07:16:48PM +0100, Pavel Machek wrote:
> > Hi!
> >
> > > > This version works on 32-bit, and builds on 64-bit (but I'm pretty
> > > > sure it does not work. 32-bit code probably needs to go into rm/)
> > > >
> > >
> >
On Thu, Jan 31, 2008 at 12:23:11PM +0100, Peter Zijlstra wrote:
> Lets CC the XFS maintainer..
Adding the xfs list and hch.
It might be a couple of days before I get to this - I've got a
week of backlog to catch up on after LCA
> On Wed, 2008-01-30 at 20:23 +, Sven Geggus wrote:
> > Hi
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
drivers/firewire/fw-sbp2.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
Index: linux/drivers/firewire/fw-sbp2.c
===
---
While fw-sbp2 takes the necessary time to reconnect to a logical unit
after bus reset, the SCSI core keeps sending new commands. They are all
immediately completed with host busy status, and application clients or
filesystems will break quickly. The SCSI device might even be taken
offline:
When a reconnect failed but re-login succeeded, __scsi_add_device was
called again.
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
drivers/firewire/fw-sbp2.c |6 ++
1 file changed, 6 insertions(+)
Index: linux/drivers/firewire/fw-sbp2.c
for easier readable logs if more than one SBP-2 device is present.
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
drivers/firewire/fw-sbp2.c | 66 ++---
1 file changed, 33 insertions(+), 33 deletions(-)
Index: linux/drivers/firewire/fw-sbp2.c
Like the old sbp2 driver, wait for the write transaction to the
AGENT_RESET to complete before proceeding (after login, after reconnect,
or in SCSI error handling).
There is one occasion where AGENT_RESET is written to from atomic
context when getting DEAD status for a command ORB. There we
Add the same workaround as found in fw-sbp2 for feature parity and
compatibility of the workarounds module parameter.
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
drivers/ieee1394/sbp2.c | 12
drivers/ieee1394/sbp2.h |2 ++
2 files changed, 14 insertions(+)
Index:
Several different SBP-2 bridges accept a login early while the IDE
device is still powering up. They are therefore unable to respond to
SCSI INQUIRY immediately, and the SCSI core has to retry the INQUIRY.
One of these retries is typically successful, and all is well.
But in case of Momobay
Christoph Anton Mitterer wrote:
> ok but this is just, because those files are still cached in RAM>
>
>
>
> Here's the first problem:
> 1) When I now diff the two versions again (the unencrypted and the one
> from the encrypted partition) I get differences...
> I'm quite sure that this is not
1 - 100 of 492 matches
Mail list logo
