On Mon, Jan 29, 2007 at 12:04:59PM -0800, Mark Fasheh wrote:
> Hi Linus,
> I made a silly error in my last upstream push. This patch makes
> ocfs2 build again.
Ok, never mind - I just noticed that you directly applied my patch on
Friday. Thanks!
--Mark
--
Mark Fasheh
Senior Software
Ben Pfaff <[EMAIL PROTECTED]> writes:
> When I modify a source file or two that belong to a particular
> module, and then rebuild just that module with "make
> dir1/dir/module.ko" (e.g.), the build system spends a couple of
> minutes grinding away on "MODPOST" operations. Am I doing
> something w
On Mon, 29 Jan 2007 17:49:14 -0800
"Martin J. Bligh" <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > On Mon, 29 Jan 2007 17:31:20 -0800
> > "Martin J. Bligh" <[EMAIL PROTECTED]> wrote:
> >
> >> Peter Zijlstra wrote:
> >>> On Sun, 2007-01-28 at 14:29 -0800, Andrew Morton wrote:
> >>>
>
Greg KH wrote:
Free Linux Driver Development!
Mind if I include this offer on http://kernelnewbies.org/UpstreamMerge ?
--
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is. Each group
calls the other unpatriotic.
-
On Mon, Jan 29, 2007 at 09:19:21PM -0500, Rik van Riel wrote:
> Greg KH wrote:
> >Free Linux Driver Development!
>
> Mind if I include this offer on http://kernelnewbies.org/UpstreamMerge ?
Please do, spread it around as much as you want.
thanks,
greg k-h
-
To unsubscribe from this list: send t
Jean Delvare wrote:
Ni Nick, Alan,
Le Mercredi 24 Janvier 2007 01:33, Nick Piggin a écrit :
Recently updated an old box to a new kernel, and the USB mouse stops
working. Well it sort of works, but stutters and is very unresponsive. This
happens now and again when the IRQ routing for my board g
On Sun, Jan 28, 2007 at 03:01:33PM -0800, Andrew Morton wrote:
> On Sun, 28 Jan 2007 08:56:08 -0800
> "Martin J. Bligh" <[EMAIL PROTECTED]> wrote:
>
> > > - It seems that people have been busy creating the need for this. I had
> > > to
> > > apply over sixty patches to this tree to fix post-2.
On Tue, 30 Jan 2007 00:56:19 +0100
Rodolfo Giometti <[EMAIL PROTECTED]> wrote:
> Hello,
>
> attached a patch to add support for Taos TSL2550 ambient light sensors
> (http://www.taosinc.com/product_detail.asp?cateid=4&proid=18).
>
Some minor things:
> +#include
> +#include
> +#include
> +#in
On Mon, 29 Jan 2007 18:39:50 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> > attached a patch to add support for Taos TSL2550 ambient light sensors
> > (http://www.taosinc.com/product_detail.asp?cateid=4&proid=18).
> >
>
> Some minor things:
Oh, and please send a signoff for this work as per
On Thu, Jan 25, 2007 at 10:30:56PM -0800, Andrew Morton wrote:
> On Thu, 25 Jan 2007 23:26:59 -0600
> "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote:
>
> > Fix exit race by splitting the nsproxy putting into two pieces.
> > First piece reduces the nsproxy refcount. If we dropped the last
> > referen
On Tue, 30 Jan 2007 08:12:31 +0530
Suparna Bhattacharya <[EMAIL PROTECTED]> wrote:
> On Sun, Jan 28, 2007 at 03:01:33PM -0800, Andrew Morton wrote:
> > On Sun, 28 Jan 2007 08:56:08 -0800
> > "Martin J. Bligh" <[EMAIL PROTECTED]> wrote:
> >
> > > > - It seems that people have been busy creating th
On Mon, Jan 29, 2007 at 08:12:41PM +0100, Ingo Molnar wrote:
>
> * Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > > The idea being to essentially suspend the system to RAM, remove the
> > > CPU and then unsuspend it? Seems like quite high overhead -- or am
> > > I misunderstanding the proposal
Hello!
Change a hard-coded constant 0 to the symbolic equivalent NOTIFY_DONE
in the ratelimit_handler() CPU notifier handler function.
Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]>
---
page-writeback.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -urpNa -X dontdiff linu
Quoting Herbert Poetzl ([EMAIL PROTECTED]):
> On Thu, Jan 25, 2007 at 10:30:56PM -0800, Andrew Morton wrote:
> > On Thu, 25 Jan 2007 23:26:59 -0600
> > "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote:
> >
> > > Fix exit race by splitting the nsproxy putting into two pieces.
> > > First piece reduces t
Andrew Morton wrote:
On Tue, 30 Jan 2007 08:12:31 +0530
Suparna Bhattacharya <[EMAIL PROTECTED]> wrote:
On Sun, Jan 28, 2007 at 03:01:33PM -0800, Andrew Morton wrote:
On Sun, 28 Jan 2007 08:56:08 -0800
"Martin J. Bligh" <[EMAIL PROTECTED]> wrote:
- It seems that people have been busy creatin
* Martin J. Bligh ([EMAIL PROTECTED]) wrote:
> Mathieu Desnoyers wrote:
> >Hi,
> >
> >Trying to build cross-compilers (or kernels) on a 2-way x86_64 (amd64) with
> >make -j3 triggers the following OOPS after about 30 minutes on
> >2.6.19.2. Due to the amount of time and the heavy load it takes befo
On Tue, Jan 30, 2007 at 01:30:56PM +1000, Greg Ungerer wrote:
>
> Dave Jones wrote:
> > On Tue, Jan 30, 2007 at 01:06:17AM +0100, Jes Sorensen wrote:
> > > Then there is the issue of architectures, at least in my book KS should
> > > focus on the ones that are really live and not in mainten
Denis Vlasenko <[EMAIL PROTECTED]> writes:
> Hi,
>
> I am currently on Linux 2.6.18, x86_64.
> I came across strange behavior while working on one
> of busybox applets. I narrowed it down to these two
> trivial testcases:
>
> #include
> #include
> int main() {
> fcntl(0, F_SETFL, fcntl
"Yakov Lerner" <[EMAIL PROTECTED]> writes:
> Does /proc have any entries to flip the "software read-only flag"
> for a partition or disk (which are physically read-write) ?
No, but you can use blockdev --setro /dev/hdXX
Phil.
-
To unsubscribe from this list: send the line "unsubscribe linux-kern
Dave Jones wrote:
On Tue, Jan 30, 2007 at 01:06:17AM +0100, Jes Sorensen wrote:
> Then there is the issue of architectures, at least in my book KS should
> focus on the ones that are really live and not in maintenance mode.
> x86_64, x86_32, PPC, ia64, ARM seems to be the driving ones these d
On Mon, Jan 29, 2007 at 07:25:08PM -0500, Mike Frysinger wrote:
> the checking_wrmsrl() macro in asm-x86_64/msr.h which is exported to
> userspace
> utilizes the u32 type instead of __u32 ... trivial attached patch fixes that
Better would be to not export those macros to userspace at all,
as
On Mon, 29 Jan 2007 14:06:04 -0500
Alan Cox <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 29, 2007 at 07:12:35PM +0100, Christoph Hellwig wrote:
> > Okay. Now that we get into the details I've also added some renaming,
> > release_mem becomes release_tty and the new factored out function is
> > releas
Dave Jones wrote:
On Tue, Jan 30, 2007 at 01:30:56PM +1000, Greg Ungerer wrote:
>
> Dave Jones wrote:
> > On Tue, Jan 30, 2007 at 01:06:17AM +0100, Jes Sorensen wrote:
> > > Then there is the issue of architectures, at least in my book KS should
> > > focus on the ones that are really l
Dave Jones wrote:
On Tue, Jan 30, 2007 at 01:30:56PM +1000, Greg Ungerer wrote:
>
> Dave Jones wrote:
> > On Tue, Jan 30, 2007 at 01:06:17AM +0100, Jes Sorensen wrote:
> > > Then there is the issue of architectures, at least in my book KS should
> > > focus on the ones that are really l
On Monday 29 January 2007 20:46, Maynard Johnson wrote:
> This is a clean up patch that includes the following changes:
>
> -It removes some macro definitions that are only used once
> with the actual code.
> -Some comments were added to clarify the code based on feedbac
On Monday 29 January 2007 20:47, Maynard Johnson wrote:
> The code was setting up the debug bus for group 21 when profiling on the
> event PPU CYCLES. The debug bus is not actually used by the hardware
> performance counters when counting PPU CYCLES. Setting up the debug bus
> for PPU CYCLES
On Tue, Jan 30, 2007 at 02:01:07PM +1000, Greg Ungerer wrote:
> Dave Jones wrote:
> >Right, other than during the CPU architects panel, I don't remember
> >any non x86/ia64/ppc stuff being brought up at all.
>
> Yep. IIRC the CPU architects panel was all x86/x86_64/ppc too wasn't it?
>
Similarly,
On Tue, Jan 30, 2007 at 02:01:07PM +1000, Greg Ungerer wrote:
> > > > Again, I don't recall us spending any time at all discussing m68k, or
> > > > sparc, whilst the others you mention were well represented.
> > >
> > > Well, others where represented, I was there looking after non-mmu m6
Dave Jones wrote:
On Tue, Jan 30, 2007 at 01:06:17AM +0100, Jes Sorensen wrote:
> Then there is the issue of architectures, at least in my book KS should
> focus on the ones that are really live and not in maintenance mode.
> x86_64, x86_32, PPC, ia64, ARM seems to be the driving ones these d
Dave Jones wrote:
On Tue, Jan 30, 2007 at 02:01:07PM +1000, Greg Ungerer wrote:
> > > > Again, I don't recall us spending any time at all discussing m68k, or
> > > > sparc, whilst the others you mention were well represented.
> > >
> > > Well, others where represented, I was there lo
On Monday 29 January 2007 20:48, Maynard Johnson wrote:
> Subject: Enable SPU switch notification to detect currently active SPU tasks.
>
> From: Maynard Johnson <[EMAIL PROTECTED]>
>
> This patch adds to the capability of spu_switch_event_register so that the
> caller is also notified of current
On 1/29/07 8:10 PM, "Dave Jones" <[EMAIL PROTECTED]> wrote:
>
> Again, I don't recall us spending any time at all discussing m68k, or
> sparc, whilst the others you mention were well represented.
Well, others where represented, I was there looking after non-mmu m68k
for ex
On 1/29/07 8:22 PM, "Greg Ungerer" <[EMAIL PROTECTED]> wrote:
>>> Yep. IIRC the CPU architects panel was all x86/x86_64/ppc too wasn't it?
>>
>> I thought there was coldfire mentioned too, or maybe my memory is
>> playing tricks on me. Maybe I'm misremembering the ppc bit.
>
> Your right, the p
I finally re-ran memtest86 on the machine since it began to have too
many different kind of errors (GPF, invalid instruction...). It turned
out that one of the memory modules was bad. I guess my brand new
list_debug race condition debugger will be useful in the future, but not
now. :)
I'll reme
On Tue, Jan 30, 2007 at 01:08:26PM +0900, Paul Mundt wrote:
> On Tue, Jan 30, 2007 at 02:01:07PM +1000, Greg Ungerer wrote:
> > Dave Jones wrote:
> > >Right, other than during the CPU architects panel, I don't remember
> > >any non x86/ia64/ppc stuff being brought up at all.
> >
> > Yep. IIR
Temporarily at
http://userweb.kernel.org/~akpm/2.6.20-rc6-mm3/
Will appear later at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc6/2.6.20-rc6-mm3/
- Restored git-block.patch: mainly the block unplugging rework. The
problematic CFQ updates have bee
Andrew Morton wrote:
Temporarily at
http://userweb.kernel.org/~akpm/2.6.20-rc6-mm3/
Will appear later at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc6/2.6.20-rc6-mm3/
- Restored git-block.patch: mainly the block unplugging rework. The
problemati
Dave Jones wrote:
> Then there is the issue of architectures, at least in my book KS should
> focus on the ones that are really live and not in maintenance mode.
> x86_64, x86_32, PPC, ia64, ARM seems to be the driving ones these days,
> m68k, Sparc32, and others, somewhat less so .
Agai
Adrian Bunk wrote:
This patch contains the following cleanups:
- make needlessly global code static
- remove pointless fastcall annotations
- don't mark functions in C files as inline
- #if 0 the following unused function:
- arch/i386/kernel/vmitime.c: read_stolen_cycles()
Signed-off-by: Adria
Greg Ungerer wrote:
Dave Jones wrote:
Again, I don't recall us spending any time at all discussing m68k, or
sparc, whilst the others you mention were well represented.
Well, others where represented, I was there looking after non-mmu m68k
for example (and other general non-mmu stuff). There ju
> Next is the issue of subjects. Last year the final list came out a few
> days before the summit started, making it impossible for people who were
> not attending the summit to prepare material for those attending to
> present/include on their behalf.
I think you completely miss the point of KS
On Tuesday 30 January 2007 04:41, Dave Jones wrote:
> Right, other than during the CPU architects panel, I don't remember
> any non x86/ia64/ppc stuff being brought up at all.
No IA64 stuff that I can remember. And there was a presentation on PPC.
But that was planned to be differently with more
On Tue, 2007-01-30 at 05:51 +0100, Jes Sorensen wrote:
> > So far though, there's been nothing proposed at all, so feel free
> > to throw your hat in the ring, if nothing else, it'll kickstart
> > the process.
>
> Actually I'm in the process of investigating launching a mini summit
> cabal, which
On Mon, 29 Jan 2007 23:50:51 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > Temporarily at
> >
> > http://userweb.kernel.org/~akpm/2.6.20-rc6-mm3/
> >
> > Will appear later at
> >
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc6/
Paweł Sikora wrote:
> On Thursday 25 of January 2007 05:50:45 Len Brown wrote:
>
>> On Wednesday 24 January 2007 17:52, Adrian Bunk wrote:
>>
>>> On Wed, Jan 24, 2007 at 11:46:44PM +0100, Paweł Sikora wrote:
>>>
for 2.6.20rc5 i get an acpi related oops during x86-64 boot:
h
This patch makes two needlessly global structs static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.20-rc6-mm1/drivers/acpi/hotkey.c.old 2007-01-28
23:31:03.0 +0100
+++ linux-2.6.20-rc6-mm1/drivers/acpi/hotkey.c 2007-01-28 23:31:23.0
+0100
@@ -234,8 +234,8
On Sun, 2007-01-28 at 22:28 +0100, Johannes Berg wrote:
> On Sat, 2007-01-27 at 07:08 -0500, Dan Williams wrote:
>
> > I really, really don't know why ieee80211 uses , but it's a pain
> > in the ass and should NOT be done for d80211. I don't know if we can
> > ever remove it from ieee80211 though
This patch fixes the wrong query and logging of the per interface jumbo frames
enabled/disabled status.
Signed-off-by: Thomas Klein <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea.h |2 +-
drivers/net/ehea/ehea_main.c | 30 +++---
2 files changed, 24 insertions
NEQ-Tasklet wasn't killed when module is removed.
Signed-off-by: Thomas Klein <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea_main.c |1 +
1 files changed, 1 insertion(+)
diff -Nurp -X dontdiff linux-2.6.20-rc6/drivers/net/ehea/ehea_main.c
patched_kernel/drivers/net/ehea/ehea_main.c
--- l
i'd like to rename the members in the _xt_align struct in
netfilter/x_tables.h ... by not using 'u8', 'u16', etc..., it's possible to
filter headers meant for userspace through the preprocessor and pull out
people who accidentally utilize these internal types ... however, by using
struct member
The Sony VAIO BIOS resets to INTx on resume. This happens
after device resume, so device irq's get misrouted.
This hack turns off MSI on this laptop, until power management
initialization order is fixed.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
drivers/pci/quirks.c | 32 ++
On Mon, 2007-01-29 at 15:50 -0800, Stephen Hemminger wrote:
> The Sony VAIO BIOS resets to INTx on resume. This happens
> after device resume, so device irq's get misrouted.
Err? My Sony VAIO does _NOT_ do that. It works fine without that.
It's just the sky2 hackery which fucked up things.
On Tue, 30 Jan 2007 01:22:54 +0100
Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-01-29 at 15:50 -0800, Stephen Hemminger wrote:
> > The Sony VAIO BIOS resets to INTx on resume. This happens
> > after device resume, so device irq's get misrouted.
>
> Err? My Sony VAIO does _NOT_ do tha
On Tue, 2007-01-30 at 01:22 +0100, Thomas Gleixner wrote:
> On Mon, 2007-01-29 at 15:50 -0800, Stephen Hemminger wrote:
> > The Sony VAIO BIOS resets to INTx on resume. This happens
> > after device resume, so device irq's get misrouted.
>
> Err? My Sony VAIO does _NOT_ do that. It works fine with
On Mon, 2007-01-29 at 16:21 -0800, Stephen Hemminger wrote:
> > > The Sony VAIO BIOS resets to INTx on resume. This happens
> > > after device resume, so device irq's get misrouted.
> >
> > Err? My Sony VAIO does _NOT_ do that. It works fine without that.
> > It's just the sky2 hackery which fuck
On Tue, 30 Jan 2007 01:31:33 +0100
Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-01-29 at 16:21 -0800, Stephen Hemminger wrote:
> > > > The Sony VAIO BIOS resets to INTx on resume. This happens
> > > > after device resume, so device irq's get misrouted.
> > >
> > > Err? My Sony VAIO d
On Mon, 2007-01-29 at 19:09 -0800, Jouni Malinen wrote:
> On Mon, Jan 29, 2007 at 08:00:11AM -0500, Dan Williams wrote:
>
> > Well, there's no way a userspace program could depend on all hidden SSID
> > APs having the tag, since if you stick in another,
> > non-ieee80211-stack card it won't be li
On Mon, Jan 29, 2007 at 08:00:11AM -0500, Dan Williams wrote:
> Well, there's no way a userspace program could depend on all hidden SSID
> APs having the tag, since if you stick in another,
> non-ieee80211-stack card it won't be like that. So I don't think we
> should care about in d80211, but
Dan Williams wrote:
> On Mon, 2007-01-29 at 19:09 -0800, Jouni Malinen wrote:
>> On Mon, Jan 29, 2007 at 08:00:11AM -0500, Dan Williams wrote:
>>
>>> Well, there's no way a userspace program could depend on all hidden SSID
>>> APs having the tag, since if you stick in another,
>>> non-ieee80211-st
On Mon, Jan 29, 2007 at 10:52:20PM -0600, Larry Finger wrote:
> When an AP has a hidden SSID, ieee80211 fails, at least with wpa_supplicant,
> which searches through the scan data looking for a particular ssid. Because
> ieee80211 has substituted a false ssid, namely "", wpa_supplicant
> cannot au
On Tue, Jan 30, 2007 at 05:51:00AM +0100, Jes Sorensen wrote:
> I'm not too bothered about the subjects, but rather the issue that we
> keep seeing this strict "only this small group, which defines the most
> important people in the community" thing.
I don't think it's intentionally meant to c
On Tue, Jan 30, 2007 at 06:11:18AM +0100, Andi Kleen wrote:
> On Tuesday 30 January 2007 04:41, Dave Jones wrote:
>
> > Right, other than during the CPU architects panel, I don't remember
> > any non x86/ia64/ppc stuff being brought up at all.
>
> No IA64 stuff that I can remember. And ther
Hi Christoph,
Thanks for the input. The following has your recommendations;
drivers/char/agp/Makefile |1
drivers/char/agp/agp.h |2
drivers/char/agp/compat_ioctl.c | 282
drivers/char/agp/compat_ioctl.h | 105 ++
dr
> > > The function changes mem limit to USER_DS before possible modprobe, but
> > > never restored it again.
Truly. The road to hell is paved with good intentions.
Martin Schwidefsky <[EMAIL PROTECTED]> writes:
> On Mon, 2007-01-29 at 09:37 -0800, Andrew Morton wrote:
>> hm, thanks for testing - I
On ppc the compiler gripes about:
kernel/kprobes.c: In function 'collect_garbage_slots':
kernel/kprobes.c:215: warning: comparison is always false due to limited range
of data type
The compiler ends up optimizing away the test since char's are unsigned on ppc.
Signed-off-by: Kumar Gala <[EMAIL
Dave Jones wrote:
On Tue, Jan 30, 2007 at 05:51:00AM +0100, Jes Sorensen wrote:
> I'm not too bothered about the subjects, but rather the issue that we
> keep seeing this strict "only this small group, which defines the most
> important people in the community" thing.
I don't think it's inten
Andi Kleen wrote:
Next is the issue of subjects. Last year the final list came out a few
days before the summit started, making it impossible for people who were
not attending the summit to prepare material for those attending to
present/include on their behalf.
I think you completely miss the
On Mon, Jan 29, 2007 at 11:43:33PM -0600, Kumar Gala wrote:
> On ppc the compiler gripes about:
>
> kernel/kprobes.c: In function 'collect_garbage_slots':
> kernel/kprobes.c:215: warning: comparison is always false due to limited
> range of data type
>
> The compiler ends up optimizing away the
Hi, this is just a reminder that discussion is now starting on the 2007
ksummit discuss list, and that I will be turning off the 2006 discuss
list shortly after sending out this note. Please direct all comments
about the Kernel Summit to the 2007 ksummit discussion list.
If you missed last week'
> Last year the subject of DMA engines was put up, however most of the
> people interested in the subject weren't even invited. In that case
> there's really little concrete that can come out of the discussion.
Nobody claimed the committee was perfect. Shit happens.
There were also plenty of prod
Andi Kleen wrote:
Abstract of a discussion? Interesting concept. Maybe.
If you mean abstract of a talk then I think you're wrong.
Not sure that abstract of a discussion thing would really work though.
It seems a bit contradicting in itself.
I was thinking more an abstract as in something tha
On Tue, Jan 30, 2007 at 06:11:18AM +0100, Andi Kleen wrote:
> On Tuesday 30 January 2007 04:41, Dave Jones wrote:
> > Right, other than during the CPU architects panel, I don't remember
> > any non x86/ia64/ppc stuff being brought up at all.
>
> No IA64 stuff that I can remember. And there was a p
Hi there,
Dunno who does IPC so hoping you do ;) (ref.config: 20-rc6-mm2b/048)
Cheers,
Grant.
From: Grant Coady <[EMAIL PROTECTED]>
Fix typos causing compile failure when CONFIG_PROC_FS not set in
ipc/ipc_sysctl.c, compile tested.
ipc/ipc_sysctl.c:107: error: `proc_ipc_doulongvec_minmax' unde
On 1/30/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
BUG: unable to handle kernel paging request at virtual address 6b6b6bdf
Use after free. The new code does module_put() _after_
free_tty_struct() which is obviously wrong.
-
To unsubscribe from this list: send the line "unsubscribe linux-kerne
On Tue, Jan 30, 2007 at 06:51:51AM +0100, Jes Sorensen wrote:
> Last year the subject of DMA engines was put up, however most of the
> people interested in the subject weren't even invited. In that case
> there's really little concrete that can come out of the discussion.
Likewise IOMMUs.
I thin
From: Pavel Roskin <[EMAIL PROTECTED]>
SMP systems without preemption and spinlock debugging enabled use unlock
macros that don't tell sparse that the lock is being released. Add
sparse annotations in this case.
Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
---
include/linux/spinlock.h | 3
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> On Mon, 29 Jan 2007, Stephen Hemminger wrote:
> >
> > On one and only one platform. It works fine on others. Don't blame
> > the driver, stop it in PCI.
>
> How sure are you that it's only those Sony laptops?
i'm wondering, could we go with Thomas
On Jan 29, 2007, at 11:55 PM, Ananth N Mavinakayanahalli wrote:
On Mon, Jan 29, 2007 at 11:43:33PM -0600, Kumar Gala wrote:
On ppc the compiler gripes about:
kernel/kprobes.c: In function 'collect_garbage_slots':
kernel/kprobes.c:215: warning: comparison is always false due to
limited
rang
On Jan 30, 2007, at 1:05 AM, Kumar Gala wrote:
On Jan 29, 2007, at 11:55 PM, Ananth N Mavinakayanahalli wrote:
On Mon, Jan 29, 2007 at 11:43:33PM -0600, Kumar Gala wrote:
On ppc the compiler gripes about:
kernel/kprobes.c: In function 'collect_garbage_slots':
kernel/kprobes.c:215: warning:
Heh, you're right Robert -- this was a typo.
So I applied your patch, looked at my dmesg and realized that
we don't need the output it enables, so I deleted the whole routine:-)
thanks,
-Len
On Saturday 27 January 2007 01:55, Robert P. J. Day wrote:
>
> Replace the apparent typo CONFIG_ACPI_DE
On Tue, Jan 30, 2007 at 08:43:12AM +0200, Muli Ben-Yehuda wrote:
> On Tue, Jan 30, 2007 at 06:51:51AM +0100, Jes Sorensen wrote:
>
> > Last year the subject of DMA engines was put up, however most of the
> > people interested in the subject weren't even invited. In that case
> > there's reall
On Sun, 28 Jan 2007 11:25:42 +0100
Jiri Slaby <[EMAIL PROTECTED]> wrote:
> Andrew Morton napsal(a):
> > Temporarily at
> >
> > http://userweb.kernel.org/~akpm/2.6.20-rc6-mm1/
>
> I'm still seeing this during bootup:
> BUG: at /home/l/latest/xxx/arch/i386/mm/highmem.c:52 kmap_atomic()
> []
On Tue, Jan 30, 2007 at 02:18:16AM -0500, Dave Jones wrote:
> > Likewise IOMMUs.
>
> There were a number of people there last year who understood IOMMUs
> and could easily talk at length about them if able to do so. iirc,
> you were also invited, but were unable to travel due to bad things
> f
Greg KH wrote on 30-01-07 02:29:
An offer they can't refuse.
This offer is in affect for all different types of devices, from USB
toys to PCI video devices to high-speed networking cards. If you build
it, we can get Linux drivers working for it.
s/affect/effect/
and maybe
s/build/manufactur
Hi Robin,
Robin Holt wrote:
> Can you make this a little more transparent? Having a magic bitmask does
> not seem like the best way to do stuff. Could you maybe make a core_flags
> directory with a seperate file for each flag. It could still map to a
> single field in the mm, but be broken out
Ingo Molnar wrote:
i'm wondering, could we go with Thomas' temporary patch that disables
sky2 MSI if CONFIG_PM is enabled - we could revert that after 2.6.20.
It's not like MSI is a life and death feature. On IO-APIC systems
vectors are abundant and in any case we share irqs just fine. The true
Hi Pavel and Andrew,
Pavel Machek wrote:
>>This patch adds the documentation for the following parameters:
>> /proc//core_flags
>> /proc/sys/kernel/core_flags_enable
>
> Sysctl seems really strange to me. Either the feature is safe to use,
> or it is not. Users can already ulimit -c 0, and we d
On Tue, 30 Jan 2007 01:12:17 -0600
Kumar Gala <[EMAIL PROTECTED]> wrote:
> What are your thoughts on forward Masami patch to Linus for 2.6.20
> since it fixes a real bug on PPC?
I bumped it up into the for-2.6.20 slot.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
* Paul E. McKenney <[EMAIL PROTECTED]> wrote:
> > in fact (new) kprobes uses the freezer, and it's far more
> > performance sensitive than the handling of CPU hotplug events.
>
> Outside of realtime workloads, I agree that performance should not be
> a problem. And I don't know of any reason
* Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
> >i'm wondering, could we go with Thomas' temporary patch that disables
> >sky2 MSI if CONFIG_PM is enabled - we could revert that after 2.6.20.
> >It's not like MSI is a life and death feature. On IO-APIC systems
> >vectors are ab
> > +/* Defines used for sync_start */
> > +#define SKIP_GENERIC_SYNC 0
> > +#define SYNC_START_ERROR -1
> > +#define DO_GENERIC_SYNC 1
> > +
> > +typedef struct vma_map
> > +{
> > + struct vma_map *next;
> > + unsigned int vma;
> > + unsigned int size;
> > + unsigned int o
Hi Nick,
Thanks for testing and reporting.
Le Mardi 30 Janvier 2007 03:35, Nick Piggin a écrit :
> Jean Delvare wrote:
> > Here is the patch I have come up with. It might not qualify as elegant,
> > but at least it appears to solve the issue. Nick, can you please give it
> > a try and confirm it
Acked-by: Tejun Heo <[EMAIL PROTECTED]>
Please repost with proper subject.
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
Thanks.
--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at ht
Patch is against 2.6.20-rc6-mm2, jmicron module detects all JMB36x as JMB361
and PATA0 has wrong pin status of XICBLID.
--- a/drivers/ide/pci/jmicron.c 2007-01-30 10:08:35.0 +0800
+++ b/drivers/ide/pci/jmicron.c 2007-01-30 10:11:31.0 +0800
@@ -70,8 +70,8 @@
{
case
On Sun, 28 Jan 2007 19:47:27 -0600
Robert Hancock <[EMAIL PROTECTED]> wrote:
> Here's a patch for sd.c I've cooked up which issues a START STOP UNIT
> command to stop the drive when the SCSI disk is removed or the machine
> is powered down. The rationale behind this is that apparently on many
> dr
Andrew Morton wrote:
triviata:
--- linux-2.6.20-rc6nv/drivers/scsi/sd.c2007-01-28 17:00:00.0
-0600
+++ linux-2.6.20-rc6nvedit/drivers/scsi/sd.c2007-01-28 18:08:53.0
-0600
@@ -821,6 +821,39 @@ static int sd_sync_cache(struct scsi_dev
return res;
}
+static
On Mon, 2007-01-29 at 15:47 -0800, Andrew Morton wrote:
> What we don't want to happen is for those disks to spin down during a
> reboot.
> It seems that this is OK with this patch.
>
> Also, we probably don't want them to be spun down during a kexec_load,
> but
> I expect that's OK too.
Actually
James Bottomley wrote:
On Mon, 2007-01-29 at 15:47 -0800, Andrew Morton wrote:
What we don't want to happen is for those disks to spin down during a
reboot.
It seems that this is OK with this patch.
Also, we probably don't want them to be spun down during a kexec_load,
but
I expect that's OK to
Jouni Malinen wrote:
> On Mon, Jan 29, 2007 at 10:52:20PM -0600, Larry Finger wrote:
>
>> When an AP has a hidden SSID, ieee80211 fails, at least with wpa_supplicant,
>> which searches through the scan data looking for a particular ssid. Because
>> ieee80211 has substituted a false ssid, namely ""
On Sat, Jan 27, 2007 at 02:04:43AM -0500, Len Brown wrote:
> From: John Keller <[EMAIL PROTECTED]>
>
> Support for dynamic loading and unloading of ACPI SSDT tables upon slot
> hotplugs and unplugs.
>
> On SN platforms, we now represent every populated root bus slot with a single
> ACPI SSDT tabl
301 - 400 of 400 matches
Mail list logo
