Paul Rolland wrote:
Oh... that's just weird. It seems you'll have to continue
boot with the
timeouts for the time being. Sorry about that.
Would you agree to a patch to add a kernel boot parameter to skip some
ata ports ?
I found some archives refering to some "ataX=noprobe", but it seems
to
Where are several places where the same code used for iovec checks.
This patch just move this code to separate helper function, and replace
duplicated code with it. IMHO it is better because these are checks that
we want for all filesystems/drivers that use vectored I/O.
Signed-off-by: Dmitriy Mo
> Oh... that's just weird. It seems you'll have to continue
> boot with the
> timeouts for the time being. Sorry about that.
Would you agree to a patch to add a kernel boot parameter to skip some
ata ports ?
I found some archives refering to some "ataX=noprobe", but it seems
to have no effect,
If generic_file_direct_write() has fail (ENOSPC condition) inside
__generic_file_aio_write_nolock() it may have instantiated a few blocks outside
i_size in case of non blockdev files. At least ext2, ext3 and reiserfs interpret
i_size and biggest block difference as error. Later fsck will complain
Christian wrote:
> Yes, for me the problem was introduced recently. I have moved around
> terabytes
> (sic!) on my discs with older kernels and I never got errors.
There is always the possibility of disk going bad, so it would be great
if you can boot an older kernel and verify that the problem
Andrew Morton wrote:
> On Mon, 19 Mar 2007 13:19:00 +0800 Nicolas Boichat <[EMAIL PROTECTED]> wrote:
>
>> This driver provides support for the Apple System Management Controller,
>> which
>> provides an accelerometer (Apple Sudden Motion Sensor), light sensors,
>> temperature sensors, keyboard ba
From: Márton Németh <[EMAIL PROTECTED]>
Typo: iwithout -> without.
Signed-off-by: Márton Németh <[EMAIL PROTECTED]>
---
--- linux-2.6.21-rc4.orig/drivers/base/platform.c 2007-03-16
01:20:01.0 +0100
+++ linux-2.6.21-rc4/drivers/base/platform.c2007-03-19 08:08:33.0
+01
On Mon, Mar 19, 2007 at 08:41:33AM +0200, Meelis Roos wrote:
> I was using my laptop as the serial console of another computer with
> pl2303 usb-to-serial cable. minicom was running but I do not remember
> whether the other end was connected or was already disconnected. Anyway,
> I unplugged the
Hi Richard,
On Sun, 18 Mar 2007 14:36:08 -0500, Richard Voigt wrote:
> On 3/3/07, Jean Delvare wrote:
> > On Fri, 2 Mar 2007 21:12:51 +, Matthew Garrett wrote:
> > > Assuming arbitration of access, what's the problem with having two
> > > drivers accessing the same hardware? Do these chips gen
On Monday 19 March 2007 03:48:14 you wrote:
> Christian wrote:
> > On Sunday 18 March 2007 06:43:09 you wrote:
> >> Christian wrote:
> This does indeed look like a drive side issue to me (the controller is
> reporting CPBs with response flags 2 which as far as I can tell
> indicates
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/lethal/sh-2.6.git
Which contains:
Hideo Saito (1):
sh: Fix PCI BAR address-space wraparound.
Mike Frysinger (1):
sh: Convert struct ioctls to static defines.
Paul Mundt (4):
sh: Define missing __NR_readahea
In article <[EMAIL PROTECTED]> you wrote:
> 2) Output of "yes --help" from the same terminal
Question: what do you expect?
#> yes --version
#yes (GNU coreutils) 5.2.1
#Written by David MacKenzie.
#
#Copyright (C) 2004 Free Software Foundation, Inc.
#This is free software; see the source for copyi
On Mon, Mar 19, 2007 at 07:21:47AM +0100, Mike Galbraith wrote:
> On Sun, 2007-03-18 at 19:27 -0700, David Schwartz wrote:
>
> > > Wrong. I call a good job giving a _preference_ to the desktop. I call
> > > rigid fairness impractical for the desktop, and a denial of reality.
> >
> > Assuming yo
On Mon, 19 Mar 2007, Nick Piggin wrote:
> So you could just attempt a trylock, and if it works, then you
> could revoke the vma right then and there. OTOH, the patch you
> subsequently posted looks fine, so unless this is performance
> critical then I wouldn't bother ;)
The patch in -mm uses trylo
On Mon, Mar 19, 2007 at 01:59:32AM -0400, Robin Humble wrote:
> On Mon, Mar 19, 2007 at 06:31:51AM +0100, Willy Tarreau wrote:
> >On Sun, Mar 18, 2007 at 11:20:09PM -0600, Robert Hancock wrote:
> >> [EMAIL PROTECTED] wrote:
> >> >lspci -v shows the message below, and I am moving files between syste
On Mon, 19 Mar 2007 13:19:00 +0800 Nicolas Boichat <[EMAIL PROTECTED]> wrote:
>
> This driver provides support for the Apple System Management Controller, which
> provides an accelerometer (Apple Sudden Motion Sensor), light sensors,
> temperature sensors, keyboard backlight control and fan contr
I was using my laptop as the serial console of another computer with
pl2303 usb-to-serial cable. minicom was running but I do not remember
whether the other end was connected or was already disconnected. Anyway,
I unplugged the usb cable and got a couple of oopses from pl2303. Kernel
2.6.21-rc4
David Chinner wrote:
Generic page_mkwrite functionality.
Filesystems that make use of the VM ->page_mkwrite() callout will generally use
the same core code to implement it. There are several tricky truncate-related
issues that we need to deal with here as we cannot take the i_mutex as we
normall
On Friday March 16, [EMAIL PROTECTED] wrote:
>
> OK. That's not necessarily a bug: one could envisage a (weird) piece of
> code which takes a lock then releases it on a later workqueue invokation.
> But I'm not sure that nfs4_laundromat() is actually supposed to be doing
> anything like that.
>
On Sun, 2007-03-18 at 19:27 -0700, David Schwartz wrote:
> > Wrong. I call a good job giving a _preference_ to the desktop. I call
> > rigid fairness impractical for the desktop, and a denial of reality.
>
> Assuming you *want* that. It's possible that the desktop may not be
> particularly impo
On Mon, Mar 19, 2007 at 06:31:51AM +0100, Willy Tarreau wrote:
>On Sun, Mar 18, 2007 at 11:20:09PM -0600, Robert Hancock wrote:
>> [EMAIL PROTECTED] wrote:
>> >lspci -v shows the message below, and I am moving files between systems,
>> >{from RAMdisk to RAMdisk} on idle machines.
>> >The transfer r
From: ebiederman@lnxi.com (Eric W. Biederman)
Date: Sun, 18 Mar 2007 23:30:39 -0600
> Sure. In the network namespace case I think the careful ordering of the
> shutdown handles that case. Even with per network namespace lo
> unregistered it still existed until the network namespace actually
> e
Kristian Høgsberg wrote:
> But the question is, is it worth it? One of the primary reasons for
> me to write an alternative stack was to be able to leave linux1394
> in maintenence mode.
I have been asking this myself on nearly every one of my patches since
you announced the new stack. :-)
The s
On Mon, 19 Mar 2007 00:44:43 + Ralf Baechle <[EMAIL PROTECTED]> wrote:
> On Sun, Mar 18, 2007 at 08:36:48PM -0400, Alan Stern wrote:
>
> > Acked-by: Alan Stern <[EMAIL PROTECTED]>
> >
> > Thank you for spotting and fixing this.
>
> It's the second time I've fixed a CONFIG_SYSFS=n bug. Of c
On Mon, 19 Mar 2007 01:34:22 +0100 Andreas Steinmetz <[EMAIL PROTECTED]> wrote:
> As posted to lkml and linux-scsi on 2007-03-15 without reply, see
> http://marc.info/?l=linux-kernel&m=117395128412313&w=2 for original post:
Repeatable oops in our most recently released kernel, nobody bothers to
r
OGAWA Hirofumi wrote:
I don't care about "read", because it doesn't corrupt filesystem. I care
about only "write", because it can corrupt filesystem.
If it's read-only, I'll not care at all, and will agree.
Here you are right, but please tell RedHat about this (and you'll be at
least called
"Alexander E. Patrakov" <[EMAIL PROTECTED]> writes:
> OGAWA Hirofumi wrote:
>> "Alexander E. Patrakov" <[EMAIL PROTECTED]> writes:
>>
You allow to set any nls to codepage? If so, it is not good.
>>> I did this because it involved less changes. Only FAT treats codepage as a
>>> number. All o
Pekka Enberg wrote:
On 3/16/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
Also, a down_write_trylock attempt inside i_mmap_lock should be a valid
optimisation.
I am not sure what you're thinking here. down_write_trylock acquires
->mmap_sem which can deadlock with ->i_mmap_lock, no?
You need h
On Sun, Mar 18, 2007 at 11:20:09PM -0600, Robert Hancock wrote:
> [EMAIL PROTECTED] wrote:
> >lspci -v shows the message below, and I am moving files between systems,
> >{from RAMdisk to RAMdisk} on idle machines.
> >The transfer rate is concurrent with just under the max throughput
> >capable on a
David Miller <[EMAIL PROTECTED]> writes:
> From: "Michael S. Tsirkin" <[EMAIL PROTECTED]>
> Date: Mon, 19 Mar 2007 00:42:34 +0200
>> > Hmm. Then the code moving dst->dev to point to the loopback
>> > device will have to be fixed too. I'll post a patch a bit later.
>>
>> Does this look sane (unte
Hello,
Nicolas Boichat wrote:
> Hello,
>
> I developed, a while ago, a driver the Apple System Management
> Controller, which provides an accelerometer (Apple Sudden Motion
> Sensor), light sensors, temperature sensors, keyboard backlight control
> and fan control on Intel-based Apple's computers
[EMAIL PROTECTED] wrote:
lspci -v shows the message below, and I am moving files between systems,
{from RAMdisk to RAMdisk} on idle machines.
The transfer rate is concurrent with just under the max throughput
capable on a 64-bit/66Mhz PCI socket.
I think you miscalculate, that bus can transfer
> Quoting David Miller <[EMAIL PROTECTED]>:
> Subject: Re: [ofa-general] Re: dst_ifdown breaks infiniband?
>
> From: "Michael S. Tsirkin" <[EMAIL PROTECTED]>
> Date: Mon, 19 Mar 2007 00:42:34 +0200
>
> > > Quoting Michael S. Tsirkin <[EMAIL PROTECTED]>:
> > > Subject: Re: [ofa-general] Re: dst_if
> Quoting Michael S. Tsirkin <[EMAIL PROTECTED]>:
> Subject: Re: dst_ifdown breaks infiniband?
>
> > Quoting Michael S. Tsirkin <[EMAIL PROTECTED]>:
> > Subject: Re: dst_ifdown breaks infiniband?
> >
> > > Quoting Michael S. Tsirkin <[EMAIL PROTECTED]>:
> > > Subject: Re: dst_ifdown breaks infini
Tony Vroon wrote:
> This duplicates the IDE core LED trigger in the libata core.
> I plan to use this by allowing PMU LED control on G5 towers. My test platform
> is a PowerMac 7,3 (Dual G5 2.0GHz, June 2004) with a K2 (sata_svw) controller.
I think this fits better in libata-core.c::ata_qc_issue
OGAWA Hirofumi wrote:
"Alexander E. Patrakov" <[EMAIL PROTECTED]> writes:
You allow to set any nls to codepage? If so, it is not good.
I did this because it involved less changes. Only FAT treats codepage as a
number. All other filesystems already allow arbitrary NLS as a codepage
mount param
Paul Rolland wrote:
> Doh ! Got that :
>
>
> ACPI: PCI Interrupt :00:1f.2[B] -> GSI 23 (level, low) -> IRQ 23
> ahci :00:1f.2: AHCI 0001.0100 32 slots 4 ports 3 Gbps 0xf impl SATA mode
> ahci :00:1f.2: flags: 64bit ncq led clo pio slum part
> ata1: SATA max UDMA/133 cmd 0xc20
On Sun, 18 Mar 2007 13:39:45 +0100 Sam Ravnborg wrote:
> On Sat, Mar 17, 2007 at 07:43:40AM +0100, Sam Ravnborg wrote:
> > On Fri, Mar 16, 2007 at 03:39:57PM -0700, Randy Dunlap wrote:
> > > On Fri, 16 Mar 2007 14:11:21 -0700 Randy Dunlap wrote:
> > >
> > > > On Fri, 16 Mar 2007 09:33:54 -0700 (P
That would completely and uttly suck if it were the case.
So in theory, the card should be talking at full speed, but since the
bridge is 66 then it would be the bottleneck right?
There are 3 pci busses in the server I am working on, so I know there is
at least _a_ bridge there.
-Origi
"Alexander E. Patrakov" <[EMAIL PROTECTED]> writes:
>> You allow to set any nls to codepage? If so, it is not good.
>
> I did this because it involved less changes. Only FAT treats codepage as a
> number. All other filesystems already allow arbitrary NLS as a codepage
> mount parameter.
I'm say
[EMAIL PROTECTED] wrote:
If you mean dmesg it says this:
e1000: :0d:02.0: e1000_probe: (PCI-X:100MHz:64-bit) {macaddress}
That's weird... dmesg shows one thing, lspci shows another, and my data
transfers seem to point to the lspci info...
Any idea which I should trust?
Both, the e1000 d
>On Friday, March 16, 2007 10:20 am Bjorn Helgaas wrote:
>> Are there really ia64 machines where we need to use the option ROM
>> copy at 0xC? If so, is this documented somewhere? I couldn't
>> find any mention in DIG64, EFI, or internal HP architecture specs.
>>
>> If we do need to use it, i
On Sat, 17 Mar 2007 21:59:03 -0700
Randy Dunlap <[EMAIL PROTECTED]> wrote:
> On Sat, 17 Mar 2007 14:44:51 -0400 Matt LaPlante wrote:
>
> > Fix various typos in kernel docs and Kconfigs, 2.6.21-rc4.
> >
> > Signed-off-by: Matt LaPlante <[EMAIL PROTECTED]>
>
> Acked-by: Randy Dunlap <[EMAIL PROTE
If you mean dmesg it says this:
e1000: :0d:02.0: e1000_probe: (PCI-X:100MHz:64-bit) {macaddress}
That's weird... dmesg shows one thing, lspci shows another, and my data
transfers seem to point to the lspci info...
Any idea which I should trust?
-Original Message-
From: Kok, Auke [
OGAWA Hirofumi wrote:
"Alexander E. Patrakov" <[EMAIL PROTECTED]> writes:
* Removes CONFIG_FAT_DEFAULT_IOCHARSET, now CONFIG_NLS_DEFAULT is used
for this purpose. This is because the correct setting of both must match
the user's locale
The some filesystems want to use utf-8, and others don'
lspci -v shows the message below, and I am moving files between systems,
{from RAMdisk to RAMdisk} on idle machines.
The transfer rate is concurrent with just under the max throughput
capable on a 64-bit/66Mhz PCI socket.
-Original Message-
From: Robert Hancock [mailto:[EMAIL PROTECTED]
Christian wrote:
> On Sunday 18 March 2007 06:43:09 you wrote:
>> Christian wrote:
This does indeed look like a drive side issue to me (the controller is
reporting CPBs with response flags 2 which as far as I can tell
indicates it's still waiting for the drive to complete the request
On Sun, 2007-03-18 at 13:08 +0100, Andi Kleen wrote:
> > The idea is _NOT_ that you go look for references to the paravirt_ops
> > members structure, that would be stupid and you wouldn't be able to
> > use the most efficient addressing mode on a given cpu, you'd be
> > patching up indirect calls a
On 3/17/07, Stefan Richter <[EMAIL PROTECTED]> wrote:
This considerably reduces the memory requirements for a packet and
eliminates ieee1394's dependency on CONFIG_NET.
Nice work Stefan, the skb rewrite was one of the most pointless
rewrites in the history of the linux1394 stack.
TODO:
- Do
> P.S. "utter failure" was too harsh. What sticks in my craw is that the
> world has to adjust to fit this new scheduler.
>
> -Mike
Even when it's totally clear that this scheduler is doing what you asked it
do while the old one wasn't? It still bothers you that now you have to ask
for wh
> I didn't suggest adding any unfairness! I suggested being fair by
> user/job/process instead of being fair by thread (which is actually
> unfair as it favors multi threaded processes over single threaded
> processes).
Wouldn't that be unfair because it favors multi-user approaches over
single-
On Sun, Mar 18, 2007 at 08:36:48PM -0400, Alan Stern wrote:
> Acked-by: Alan Stern <[EMAIL PROTECTED]>
>
> Thank you for spotting and fixing this.
It's the second time I've fixed a CONFIG_SYSFS=n bug. Of course that
sort of thing just shouldn't happen - but the fact that in both cases
the bug w
The latest maintenance release GIT 1.5.0.5 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.0.5.tar.{gz,bz2} (tarball)
git-htmldocs-1.5.0.5.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.0.5.tar.{gz,bz2}
Ingo Molnar wrote:
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
>> Once again here's an attempt to put the shared files of x86_64 and
>> i386 into a separate directory.
>
> what do you think about the idea i suggested: to do an x32_/x64_ prefix
> (or _32/_64 postfix), in a brute-force way, _
On Sun, 18 Mar 2007, Ralf Baechle wrote:
> Since d9a9cdfb078d755e648d53ec25b7370f84ee5729 is using
> ENOSYS without including if CONFIG_SYSFS is disabled.
>
> Fixed by including .
>
> Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]>
>
> diff --git a/include/linux/sysfs.h b/include/linux/sysfs.
As posted to lkml and linux-scsi on 2007-03-15 without reply, see
http://marc.info/?l=linux-kernel&m=117395128412313&w=2 for original post:
It is not so nice when one can write backup tapes but the tapes cannot
be read. I don't know if memory management or the st driver is the
culprit, but this is
From: Kyungmin Park <[EMAIL PROTECTED]>
Subject: [PATCH] [JFFS2] Implement block trace features in JFFS2
As JFFS2 don't use the block layer. We can't use block trace features.
Now we hook the mtd functions to implement block trace in JFFS2
With this feature, we can measure the real I/O time in MT
"Michael S. Tsirkin" <[EMAIL PROTECTED]> writes:
>> > Why is neighbour->dev changed here?
>>
>> It holds reference to device and prevents its destruction.
>> If dst is held somewhere, we cannot destroy the device and deadlock
>> while unregister.
>
> BTW, can this ever happen for the loopback dev
On Mon, 19 Mar 2007, Arnd Bergmann wrote:
> On Sunday 18 March 2007, Davide Libenzi wrote:
> > bah, __put_user is basically a move, so I don't think that efficency would
> > be that different (assuming that it'd matter in this case). The only thing
> > many __put_user do, is increase the excepti
From: "Michael S. Tsirkin" <[EMAIL PROTECTED]>
Date: Mon, 19 Mar 2007 00:42:34 +0200
> > Quoting Michael S. Tsirkin <[EMAIL PROTECTED]>:
> > Subject: Re: [ofa-general] Re: dst_ifdown breaks infiniband?
> >
> > > Quoting Eric W. Biederman :
> > > Subject: Re: [ofa-general] Re: dst_ifdown breaks in
Hi,
At Fri, 16 Mar 2007 22:20:27 +0300,
Sergei Shtylyov wrote:
> Argh, I've missed this one! :-(
> But shouldn't we also add !need_resched_delayed() to another place below?
>
> if (ppc_md.power_save) {
> [...]
> if (!need_resched() && !cpu_should_die())
Thanks for pointing it o
On Mar 18 2007 14:13, Matthew Wilcox wrote:
>
>Equally, if one has one's ogg collection stored on said NFS server, the
>ogg player will be in uninterruptible sleep while holding the sound device
>open, preventing other applications from making sounds.
Only if you have
- a card with no hardware
Andi Kleen wrote:
> Yes. All inline assembly tells gcc what registers are clobbered
> and it fills in the tables. Hand clobbering in inline assembly cannot
> be expressed with the current toolchain, so we moved all those
> out of line.
>
> But again I'm not sure it will work anyways. For once you w
On Sunday 18 March 2007, Davide Libenzi wrote:
> bah, __put_user is basically a move, so I don't think that efficency would
> be that different (assuming that it'd matter in this case). The only thing
> many __put_user do, is increase the exception table sizes.
The cost of user access functions
Implement ->page_mkwrite in XFS.
Signed-Off-By: Dave Chinner <[EMAIL PROTECTED]>
---
fs/xfs/linux-2.6/xfs_file.c | 16
1 file changed, 16 insertions(+)
Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_file.c
===
--- 2.
Generic page_mkwrite functionality.
Filesystems that make use of the VM ->page_mkwrite() callout will generally use
the same core code to implement it. There are several tricky truncate-related
issues that we need to deal with here as we cannot take the i_mutex as we
normally would for these path
On Mon, Mar 19, 2007 at 12:58:31AM +0200, ahmed wrote:
>
> P.S. I've tried commenting out both lines which led to a non functional init,
> Also setting them to __USER_DS made init start but stopped issuing the error:
> `Panic: Segment violation at 0x8049798 - Sleeping for 30 seconds'
>
Sorry, I
> the new fault hander made the memory manager code a lot cleaner and
> very less hacky in a lot of cases. so I'd rather merge the clean code
> than have to fight with the current code...
Note that you can probably get away with NOPFN_REFAULT etc... like I did
for the SPEs in the meantime.
Inde
On Fri, 16 Mar 2007, Andi Kleen wrote:
> > In the future it is likely that x86_64 will significantly deviate from
>
> It already is in some cases. And I agree more will happen.
This is a *totally* bogus and idiotic argument.
x86-64 will get new capabilities, BUT IT WILL CONTINUE TO SUPPORT O
Hi list,
Reading the kernel threads initialization code I see:
int kernel_thread(...) {
struct pt_regs regs;
memset(®s, 0, sizeof(regs));
[...]
** regs.xds = __USER_DS;
** regs.xes = __USER_DS;
[...]
/* Ok, create the new process.. */
ret
On Sun, 18 Mar 2007, Lee Revell wrote:
On 3/17/07, Mike Galbraith <[EMAIL PROTECTED]> wrote:
P.S. "utter failure" was too harsh. What sticks in my craw is that the
world has to adjust to fit this new scheduler.
I have never seen X run nearly as smooth as our favorite proprietary
OS on simil
On 3/13/07, Dave Hansen <[EMAIL PROTECTED]> wrote:
How do we determine what is shared, and goes into the shared zones?
Once we've allocated a page, it's too late because we already picked.
Do we just assume all page cache is shared? Base it on filesystem,
mount, ...? Mount seems the most logica
> Quoting Michael S. Tsirkin <[EMAIL PROTECTED]>:
> Subject: Re: [ofa-general] Re: dst_ifdown breaks infiniband?
>
> > Quoting Eric W. Biederman :
> > Subject: Re: [ofa-general] Re: dst_ifdown breaks infiniband?
> >
> > "Michael S. Tsirkin" <[EMAIL PROTECTED]> writes:
> >
> > >> > Why is neighbo
On Sun, Mar 18, 2007 at 02:49:27PM -0700, David Miller wrote:
> From: Dan Aloni <[EMAIL PROTECTED]>
> Date: Sun, 18 Mar 2007 14:43:46 +0200
>
> > do_tcp_sendpages() should not iterate 'pages' as an array since
> > it is not an array of 'struct page *', but a pointer to a single
> > entity of 'st
> Quoting Eric W. Biederman :
> Subject: Re: [ofa-general] Re: dst_ifdown breaks infiniband?
>
> "Michael S. Tsirkin" <[EMAIL PROTECTED]> writes:
>
> >> > Why is neighbour->dev changed here?
> >>
> >> It holds reference to device and prevents its destruction.
> >> If dst is held somewhere, we ca
On Sun, 18 Mar 2007, Andrew Morton wrote:
On Sun, 18 Mar 2007 20:08:49 + (GMT) Mel Gorman <[EMAIL PROTECTED]> wrote:
On Sun, 18 Mar 2007, Andrew Morton wrote:
On Sun, 18 Mar 2007 19:05:41 + (GMT) Mel Gorman <[EMAIL PROTECTED]> wrote:
How much additional memory consumption are we ex
Thomas Gleixner wrote:
> On Sun, 2007-03-18 at 17:53 -0400, Chuck Ebbert wrote:
Just to be clear: this replaces the earlier patch, right?
>>> This replaces the fix Andrew did.
>>>
>>> http://marc.info/?l=linux-kernel&m=117407812411997&w=2
>>>
>> Right, but is the original "Prevent DOS" patch f
2007/3/18, Mathieu Desnoyers <[EMAIL PROTECTED]>:
Hi Guillaume,
Hi Mathieu, thanks for your extensive reply.
yet another level of band-aid over a
I don't agree it's a band-aid, changing the scaling coefficient
without adjusting an offset is a bug.
broken architecture : AMD 7th and 8th gen
"Alexander E. Patrakov" <[EMAIL PROTECTED]> writes:
> * Removes CONFIG_FAT_DEFAULT_IOCHARSET, now CONFIG_NLS_DEFAULT is used
> for this purpose. This is because the correct setting of both must match
> the user's locale
The some filesystems want to use utf-8, and others don't want to use
utf-8
On Sun, 2007-03-18 at 17:53 -0400, Chuck Ebbert wrote:
> >> Just to be clear: this replaces the earlier patch, right?
> >
> > This replaces the fix Andrew did.
> >
> > http://marc.info/?l=linux-kernel&m=117407812411997&w=2
> >
>
> Right, but is the original "Prevent DOS" patch from you still ne
Thomas Gleixner wrote:
> On Sun, 2007-03-18 at 17:16 -0400, Chuck Ebbert wrote:
>> Thomas Gleixner wrote:
>>> I'd prefer this one: The maximum seconds value we can handle on 32bit is
>>> LONG_MAX.
>>>
>>> diff --git a/include/linux/ktime.h b/include/linux/ktime.h
>>> index c68c7ac..248305b 100644
>
From: Dan Aloni <[EMAIL PROTECTED]>
Date: Sun, 18 Mar 2007 14:43:46 +0200
> do_tcp_sendpages() should not iterate 'pages' as an array since
> it is not an array of 'struct page *', but a pointer to a single
> entity of 'struct page *' passed on the stack as a parameter to
> tcp_send_page() (hen
Hi,
On Sunday 18 March 2007 22:06, Robert P. J. Day wrote:
> p.s. just FYI, i ran my "find dead CONFIG variables" script on the
> entire tree and, as we speak, there are 316 preprocessor tests that
> are testing variables of the form "CONFIG_whatever" for which that
> option is not set anywhere i
Hello,
This is a new version of my patch to add support for more laptops to the
wistron_btns driver. Modifications from the previous version:
* sends lid close/open event as a switch event (not a key event)
* Display on/off is KEY_SCREEN and Display selection is
KEY_SWITCHVIDEOMODE, from the d
This patch adds a generic map. That is, a keymap that should output the
correct keycodes for most laptops. This is simply based on the
observation of all those keymaps already gathered, as most of the
wistron codes are always mapped to the same keycode.
Hopefully, this way users which have a n
This patch declares keymaps as initdata, so they are discarded at
runtime, saving about 1kb (10% of the module size). This idea to save
memory comes from Dmitry Torokhov.
Eric
From: Eric Piel <[EMAIL PROTECTED]>
wriston_btns: Declare keymaps as initdata
As the number of keymaps increases and
This patch adds all the "tm_new" laptops information that is in acerhk
to wistron_btns. That's about 25 more laptops. Obviously, I couldn't try
them all. I've just tried the Aspire 3020. For this reason, I've also
added a printk which ask the users of those laptops to confirm me it
works (or no
On Sun, 18 Mar 2007, Jiri Kosina wrote:
> On Sun, 18 Mar 2007, Robert P. J. Day wrote:
>
> > $ grep -r PROVE_SPIN_LOCKING *
> > Documentation/irqflags-tracing.txt:CONFIG_TRACE_IRQFLAGS_SUPPORT is needed
> > for CONFIG_PROVE_SPIN_LOCKING
> > kernel/spinlock.c:#ifdef CONFIG_PROVE_SPIN_LOCKING
>
> T
On Sun, 2007-03-18 at 17:16 -0400, Chuck Ebbert wrote:
> Thomas Gleixner wrote:
> >
> > I'd prefer this one: The maximum seconds value we can handle on 32bit is
> > LONG_MAX.
> >
> > diff --git a/include/linux/ktime.h b/include/linux/ktime.h
> > index c68c7ac..248305b 100644
> > --- a/include/lin
Tejun Heo wrote:
> Jon Masters wrote:
>> Chuck Ebbert wrote:
>>
>>> If you try to load both the pata_atiixp and the ahci driver
>>> (for the same ATI SB600 adapter), very strange things happen.
>>> The AHCI driver churns for three minutes or so, spewing
>>> messages like this, then nothing works:
>
Thomas Gleixner wrote:
>
> I'd prefer this one: The maximum seconds value we can handle on 32bit is
> LONG_MAX.
>
> diff --git a/include/linux/ktime.h b/include/linux/ktime.h
> index c68c7ac..248305b 100644
> --- a/include/linux/ktime.h
> +++ b/include/linux/ktime.h
> @@ -57,7 +57,11 @@ typedef u
> Quoting Michael S. Tsirkin <[EMAIL PROTECTED]>:
> Subject: Re: dst_ifdown breaks infiniband?
>
> > Quoting Michael S. Tsirkin <[EMAIL PROTECTED]>:
> > Subject: Re: dst_ifdown breaks infiniband?
> >
> > Quoting Alexey Kuznetsov <[EMAIL PROTECTED]>:
> > Subject: Re: dst_ifdown breaks infiniband?
Hello all,
> I'm just wondering if it is right to export the functions msr_read and
> msr_write from arch/i386/kernel/msr.c, or if it would be better to put
> these functions in arch/i386/lib/msr-on-cpu.c with rdmsr_on_cpu and
> wrmsr_on_cpu.
I'm fixing this, please stay tuned. I will CC you in ne
Hi Guillaume,
I understand your need for a working system, but the impression I get
is that this looks too much like yet another level of band-aid over a
broken architecture : AMD 7th and 8th generations, which does not give a
synchronized TSC.
The patch you suggest may work for scheduler purpose
> Quoting Michael S. Tsirkin <[EMAIL PROTECTED]>:
> Subject: Re: dst_ifdown breaks infiniband?
>
> Quoting Alexey Kuznetsov <[EMAIL PROTECTED]>:
> Subject: Re: dst_ifdown breaks infiniband?
> > > Can dst->neighbour be changed to point to NULL instead, and the neighbour
> > > released?
> >
> > It
Hello!
We've a very strange Problem with Kernel 2.6.20.x
If i try to access a SCSI or SATA Disk (tested with Adaptec U320
ASC-29320, ICP Vortex 9024, Promise TX300) the whole server hangs - no
output - no error on the screen - but it hangs completely. But it does
not happen on all our systems
On Sun, 18 Mar 2007, Robert P. J. Day wrote:
> $ grep -r PROVE_SPIN_LOCKING *
> Documentation/irqflags-tracing.txt:CONFIG_TRACE_IRQFLAGS_SUPPORT is needed
> for CONFIG_PROVE_SPIN_LOCKING
> kernel/spinlock.c:#ifdef CONFIG_PROVE_SPIN_LOCKING
This should almost certainly be CONFIG_PROVE_LOCKING ...
Robert Hancock wrote:
[EMAIL PROTECTED] wrote:
I'm running a e1000xf adapter in a 64-bit/100Mhz PCI slot. The intel
site shows this is a supported config for the card, but linux is pulling
this info:
ed:02.0 Ethernet controller: Intel Corporation 82544EI Gigabit Ethernet
Controller (Fiber) (re
On Sun, 18 Mar 2007 20:08:49 + (GMT) Mel Gorman <[EMAIL PROTECTED]> wrote:
> On Sun, 18 Mar 2007, Andrew Morton wrote:
>
> > On Sun, 18 Mar 2007 19:05:41 + (GMT) Mel Gorman <[EMAIL PROTECTED]>
> > wrote:
> >
> >>> How much additional memory consumption are we expecting here?
> >>>
> >>
>
On Sat, 17 Mar 2007, Arnd Bergmann wrote:
> On Friday 16 March 2007 01:22:15 Davide Libenzi wrote:
> > +asmlinkage long compat_sys_signalfd(int ufd,
> > + const compat_sigset_t __user *sigmask,
> > + compat_size_t sigsetsize)
> >
1 - 100 of 231 matches
Mail list logo
