On the day of Friday 07 September 2007 Chuck Ebbert hast written:
> On 09/06/2007 07:31 AM, Andi Kleen wrote:
> > Chuck Ebbert <[EMAIL PROTECTED]> writes:
> >> Some systems lock up without the noapic option.
> >
> > Please find patterns: cpu type, chipsets, mainboard vendors etc.
>
> This is the
On 9/5/07, Daniel Phillips <[EMAIL PROTECTED]> wrote:
> On Wednesday 05 September 2007 03:42, Christoph Lameter wrote:
> > On Wed, 5 Sep 2007, Daniel Phillips wrote:
> > > If we remove our anti-deadlock measures, including the
> > > ddsnap.vm.fixes (a roll-up of Peter's patch set) and the request
On Fri, Sep 07, 2007 at 05:09:17PM -0700, Bob Gilligan wrote:
>
> Proposed patch is below. We found the problem and tested this fix in
> 2.6.20, but it looks like the relevant code in blkcipher.c is the same
> in the latest tree.
Good catch!
I've fixed this slightly differently. Also, the
Chuck Ebbert wrote:
> On 09/06/2007 07:31 AM, Andi Kleen wrote:
> > Chuck Ebbert <[EMAIL PROTECTED]> writes:
> >> Some systems lock up without the noapic option.
> >
> > Please find patterns: cpu type, chipsets, mainboard vendors etc.
>
> This is the first one I've actually had in front of me:
>
>
Krzysztof Halasa wrote:
>> Ok, but that's not the most common situaties. What I'm suggesting is a
>> warning or a please note popup. Not neccessarily an error or refusing to
>> continue thing.
>
>What IMHO makes sense is changing all references to SCSI CDROM,
>SCSI DISK etc. to just CDROM, DISK,
On Fri, 07 Sep 2007, David Brownell wrote:
> > The platform for a ThinkPad is either i386 or amd64.
>
> Both i386 and x86_64 are clearly an "arch". They even live in
> an "arch" directory: linux/arch/{i386,x86_64}.
Well, I stand corrected on the "platform" term, then.
> When folk talk about a
Andrew Morton [EMAIL PROTECTED] wrote:
| On Fri, 10 Aug 2007 15:47:59 +0400
| [EMAIL PROTECTED] wrote:
|
| > struct pid
| > {
| > atomic_t count;
| > @@ -50,6 +50,8 @@ struct pid
| > /* lists of tasks that use this pid */
| > struct hlist_head tasks[PIDTYPE_MAX];
| > struct
include/asm-powerpc/elf.h:289
Why we need the second AT_IGNOREPPC entry here?
There is a mm_struct->saved_auxv overflow on PPC64 with AT_VECTOR_SIZE
== 44 (may be on PPC32 too, not checked) when adding all entries to
it. I've removed the second AT_IGNOREPCC from ARCH_DLINFO to prevent
On Fri, 2007-09-07 at 19:59 -0400, Jeff Garzik wrote:
> >
> > commit 9fd380e892e078b582920325357292c07cc9
> > Author: David S. Miller <[EMAIL PROTECTED](none)>
> > Date: Thu Sep 6 21:44:36 2007 +0100
> >
> > [MYRI10GE]: Need to select INET_LRO.
> >
> > Signed-off-by: David S.
Hi -- There appears to be a bug in the function blkcipher_get_spot(),
which resides in crypto/blkcipher.c. This small function reads:
static inline u8 *blkcipher_get_spot(u8 *start, unsigned int len)
{
if (offset_in_page(start + len) < len)
return (u8 *)((unsigned
This patch removes some incorrect formatting spaces and replaces them with tabs.
Signed-off-by: Jason Gaston <[EMAIL PROTECTED]>
--- linux-2.6.23-rc5/drivers/ata/ata_piix.c.orig2007-09-07
17:11:55.0 -0700
+++ linux-2.6.23-rc5/drivers/ata/ata_piix.c 2007-09-07
> > (Also, note that "platform", "host", and "board" are ambiguous.
> > In some contexts each is synonymous; in others, not. I avoid
>
> In this specific case I am talking about, they're not.
That is, in *YOUR* usage context they're not. I had to parse
what you wrote a few times before your
David Miller wrote:
From: David Miller <[EMAIL PROTECTED]>
Date: Thu, 06 Sep 2007 13:40:38 -0700 (PDT)
From: Mathieu Desnoyers <[EMAIL PROTECTED]>
Date: Thu, 6 Sep 2007 15:37:51 -0400
I got a link error on myri10ge when building 2.6.23-rc4-mm1 on x86_64 :
ERROR: "lro_flush_all"
Gaston, Jason D wrote:
At this time, I don't have any way to test those particular DeviceID's
and I know that the AHCI mode DeviceID works by using the class code
support. So, I would like to just leave them at they are, if that is
ok.
Fine by me... Overall I'll follow "vendor's best
Hi,
On 07/09/2007, Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
> Sep 7 11:42:49 p55lp2 kernel: kernel BUG at fs/nfs/nfs4xdr.c:945!
> Sep 7 11:42:49 p55lp2 kernel: Oops: Exception in kernel mode, sig: 5 [#1]
> Sep 7 11:42:49 p55lp2 kernel: SMP NR_CPUS=128 NUMA pSeries
> Sep 7 11:42:49 p55lp2
Gaston, Jason D wrote:
-Original Message-
From: Jeff Garzik [mailto:[EMAIL PROTECTED]
Sent: Friday, August 31, 2007 12:51 AM
To: Gaston, Jason D
Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org;
[EMAIL PROTECTED]
Subject: Re: [PATCH 2.6.23-rc4][reRESEND] ata_piix: IDE mode SATA patch
Hi Mark,
[Adding netdev to CC]
On 07/09/2007, Mark Nipper <[EMAIL PROTECTED]> wrote:
> I've received two oopses now from my kernel while running
> the 2.6.22 series. The first was with 2.6.22.1 back in July and
> the second which happened just within the last day is 2.6.22.5.
> They
res 51/84:00:3f:00:00/00:00:00:00:00/e0 Emask 0x10 (ATA bus error)
res 51/84:00:3f:00:00/00:00:00:00:00/e0 Emask 0x10 (ATA bus error)
res 51/84:00:21:9d:fc/00:00:00:00:00/e6 Emask 0x10 (ATA bus error)
ATA bus error == straight-from-hardware reported error
Cable or
>-Original Message-
>From: Jeff Garzik [mailto:[EMAIL PROTECTED]
>Sent: Friday, August 31, 2007 12:51 AM
>To: Gaston, Jason D
>Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org;
>[EMAIL PROTECTED]
>Subject: Re: [PATCH 2.6.23-rc4][reRESEND] ata_piix: IDE mode SATA patch
for
>Intel Tolapai
Reyk Floeter wrote:
I'm still waiting for an answer. Your process is taking too long.
Speaking as a person through which these changes flow upstream into the
official kernel (ath5k maintainers -> linville -> me -> linus)...
The most important thing for today is that no ath5k stuff has
At Fri, 07 Sep 2007 22:59:07 +0200,
Romano Giannetti wrote:
>
> On Fri, 2007-09-07 at 21:42 +0200, Thorsten Leemhuis wrote:
> > On 07.09.2007 14:58, Takashi Iwai wrote:
> > >>> Ah good. I added it to ALSA HG tree now.
>
> Thanks. BTW, is anywhere visible the current hg tree? It seems that
>
Hi David,
On 06/09/2007, David Woodhouse <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-09-03 at 12:11 +0200, Michal Piotrowski wrote:
> > MTD
> >
> > Subject : error: implicit declaration of function 'cfi_interleave'
> > References : http://lkml.org/lkml/2007/8/6/272
> > Last known good
At Fri, 07 Sep 2007 21:42:36 +0200,
Thorsten Leemhuis wrote:
>
> On 07.09.2007 14:58, Takashi Iwai wrote:
> > At Fri, 07 Sep 2007 14:04:01 +0200,
> > Thorsten Leemhuis wrote:
> >> On 07.09.2007 12:21, Takashi Iwai wrote:
> >>> At Fri, 07 Sep 2007 10:22:27 +0200,
> >>> Romano Giannetti wrote:
>
>-Original Message-
>From: Jeff Garzik [mailto:[EMAIL PROTECTED]
>Sent: Friday, September 07, 2007 3:39 PM
>To: Gaston, Jason D
>Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org
>Subject: Re: [PATCH 2.6.23-rc4][reRESEND] ahci: RAID mode SATA patch
for
>Intel Tolapai
>
>Gaston, Jason D
On Fri Aug 31 00:24:47 2007, [EMAIL PROTECTED] wrote:
>
> Jonathan Lim wrote:
> > On Sat Aug 25 21:58:44 2007, [EMAIL PROTECTED] wrote:
> >>> Also, I don't understand why the code to update btime:
> >>>
> >>> /* calculate task elapsed time in timespec */
> >>>
Micah Gruber wrote:
This patch fixes a potential null dereference bug where we dereference dev
before a null check. This patch simply moves the dereferencing after the null
check.
Signed-off-by: Micah Gruber <[EMAIL PROTECTED]>
---
--- a/drivers/net/tulip/uli526x.c
+++
On Sat, 8 Sep 2007, Nick Piggin wrote:
>
> So, can we finally noop smp_rmb and smp_wmb on x86?
Did AMD already release their version? If so, we should probably add a
commit that does that in somewhat early 2.6.24 rc, and add the pointers to
the whitepapers in the commit message.
Mark Lord wrote:
Ditto for selecting transfer modes.
Waiting on one thing AFAICS:
ability to drain/idle all ports +
issue a command on one port +
resume normal parallel port operation
SET FEATURES - XFER MODE is special in that it requires all sorts of
additional
Hi Alex,
On 07/09/2007, Alex Riesen <[EMAIL PROTECTED]> wrote:
> Kernel: v2.6.23-rc5+ (b21010ed6498391c0f359f2a89c907533fe07fec)
Is this a post 2.6.22 regression?
Regards,
Michal
--
LOG
http://www.stardust.webpages.pl/log/
-
To unsubscribe from this list: send the line "unsubscribe
On 09/07/2007 03:56 PM, Alex Riesen wrote:
> Kernel: v2.6.23-rc5+ (b21010ed6498391c0f359f2a89c907533fe07fec)
> Ubuntu Feisty, Radeon R200 (9200) dual head, MergedFB, BZFlag in
> OpenGL mode, frozen. That'll teach me playing games at home...
>
> BUG: unable to handle kernel paging request at
[EMAIL PROTECTED] wrote:
> Hello Bharata,
> I am developing a linux stackable/unification filesystem too.
>
> Bharata B Rao:
>
>> Questions
>> -
>>
> :::
>
>> First of all, should we even expect a sane lseek(2) on union mounted
>> directories ? If not, will the Approach 2,
> >> I know that it's difficult to get people to read docs & help text,
> >> and maybe it is needed in more places, but CONFIG_ATA (SATA/PATA)
> >> help text says:
> >> NOTE: ATA enables basic SCSI support; *however*,
> >> 'SCSI disk support', 'SCSI tape support', or
> >> 'SCSI CDROM
On Sep 7 2007 21:38, Krzysztof Halasa wrote:
>> Ok, but that's not the most common situaties. What I'm suggesting is a
>> warning or a please note popup. Not neccessarily an error or refusing to
>> continue thing.
>
>What IMHO makes sense is changing all references to SCSI CDROM,
>SCSI DISK etc.
On Saturday 08 September 2007 08:26, Jesse Barnes wrote:
> FYI, we just released a new white paper describing memory ordering for
> Intel processors:
> http://developer.intel.com/products/processor/manuals/index.htm
>
> Should help answer some questions about some of the ordering primitives
> we
Hi,
On 03/09/2007, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > On Mon, 03 Sep 2007 11:48:00 +0100 "H. Peter Anvin" <[EMAIL PROTECTED]>
> > wrote:
> > Michal Piotrowski wrote:
> > >
> > > Unclassified
> > >
> > > Subject : console is messed up after resume from s2ram or
> > > switching
On Fri, Sep 07, 2007 at 08:46:48AM -0400, Mathieu Desnoyers wrote:
> * Andi Kleen ([EMAIL PROTECTED]) wrote:
> > > +config IMMEDIATE
> > > + default y if !DISABLE_IMMEDIATE
> >
> > It's still unclear to me why DISABLE_IMMEDIATE is needed. It would
> > be better to make it just the default.
> >
>
Gaston, Jason D wrote:
-Original Message-
From: Gaston, Jason D
Sent: Friday, August 31, 2007 10:10 AM
To: 'Jeff Garzik'
Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org
Subject: RE: [PATCH 2.6.23-rc4][reRESEND] ahci: RAID mode SATA patch
for
Intel Tolapai
This device has both AHCI
On Fri, Sep 07, 2007 at 10:04:42AM -0400, Mathieu Desnoyers wrote:
> * Andi Kleen ([EMAIL PROTECTED]) wrote:
> > On Thu, Sep 06, 2007 at 04:01:29PM -0400, Mathieu Desnoyers wrote:
> > > + sync_core();
> > > + /* Not strictly needed, but can speed CPU recovery up. */
> >
> > That turned out to
FYI, we just released a new white paper describing memory ordering for
Intel processors:
http://developer.intel.com/products/processor/manuals/index.htm
Should help answer some questions about some of the ordering primitives
we use on i386 and x86_64.
Jesse
-
To unsubscribe from this list:
auth 2efbb938 subscribe linux-kernel [EMAIL PROTECTED]
auth a339d34a subscribe linux-net [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Wednesday 05 September 2007 17:07, Christoph Lameter wrote:
> On Wed, 5 Sep 2007, Zhang, Yanmin wrote:
> > > slub_max_order=3 slub_min_objects=8
> >
> > I tried this approach. The testing result showed 2.6.23-rc4 is about
> > 2.5% better than 2.6.22. It really resovles the issue.
>
> Note also
On Fri, 07 Sep 2007, David Brownell wrote:
> > > For that matter, a *driver* should never create its own device node(s)
> > > in the first place. Device creation belongs elsewhere, like as part of
> > > platform setup or, for busses with integral enumeration support like
> > > PCI or USB, bus
On 05/09/07, Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
>
> Are we guaranteed that the dc_kbd_callback is not running in a separate
> thread?
>
> Please also consider implementing support for changing keyma. Since
> the keymap is pretty full I think the best way is to copy the vanilla
> keymap
> > For that matter, a *driver* should never create its own device node(s)
> > in the first place. Device creation belongs elsewhere, like as part of
> > platform setup or, for busses with integral enumeration support like
> > PCI or USB, bus glue. Linux is moving away from that legacy model.
>
On Saturday 08 September 2007 17:25, Nick Piggin wrote:
> On Saturday 08 September 2007 07:12, Goswin von Brederlow wrote:
> > Nick Piggin <[EMAIL PROTECTED]> writes:
> > > On Saturday 08 September 2007 06:01, Goswin von Brederlow wrote:
> > >> b) a segment boundary
> > >
> > > This is done, as
> > Anybody got a proposed scheme for the case where somebody like myself
> > who is *not* a member of the Maintainer Cabal has looked at a patch, and
> > found a valid show-stopper that's bigger than just whitespace (breaks on
> > 64-bit, locking issues, etc), or other commentary that
On Saturday 08 September 2007 07:12, Goswin von Brederlow wrote:
> Nick Piggin <[EMAIL PROTECTED]> writes:
> > On Saturday 08 September 2007 06:01, Goswin von Brederlow wrote:
> >> b) a segment boundary
> >
> > This is done, as I said, because of the deadlock issue. While the issue
> > is more
On Saturday 08 September 2007 07:00, Goswin von Brederlow wrote:
> Nick Piggin <[EMAIL PROTECTED]> writes:
> > Anyway, there are fixes for this deadlock in Andrew's -mm tree, but
> > also a workaround for the NFSD problem in git commit 29dbb3fc. Did
> > you try a later kernel to see if it is fixed
Nick Piggin <[EMAIL PROTECTED]> writes:
> On Saturday 08 September 2007 06:01, Goswin von Brederlow wrote:
>> Nick Piggin <[EMAIL PROTECTED]> writes:
>> > So I believe the problem is that for a multi-segment iovec, we currently
>> > prepare_write/commit_write once for each segment, right? We do
On Fri, 07 Sep 2007, David Brownell wrote:
> For that matter, a *driver* should never create its own device node(s)
> in the first place. Device creation belongs elsewhere, like as part of
> platform setup or, for busses with integral enumeration support like
> PCI or USB, bus glue. Linux is
Nick Piggin <[EMAIL PROTECTED]> writes:
> Anyway, there are fixes for this deadlock in Andrew's -mm tree, but
> also a workaround for the NFSD problem in git commit 29dbb3fc. Did
> you try a later kernel to see if it is fixed there?
I had a chance to look up that commit (git clone took a while
On Fri, 2007-09-07 at 21:42 +0200, Thorsten Leemhuis wrote:
> On 07.09.2007 14:58, Takashi Iwai wrote:
> >>> Ah good. I added it to ALSA HG tree now.
Thanks. BTW, is anywhere visible the current hg tree? It seems that
http://hg-mirror.alsa-project.org/alsa-kernel/ lags a bit behind...
> It's
On Fri, 07 Sep 2007, Dmitry Torokhov wrote:
> On 9/7/07, Jean Delvare <[EMAIL PROTECTED]> wrote:
> > To go one step further, I am questioning the real value of this naming
> > exception for these "unique" platform devices. On top of the bugs I
> > mentioned above, it has potential for
Subject: [patch] Fix BIOS-e820 end address
--snip of boot message--
BIOS-provided physical RAM map:
BIOS-e820: - 000a (usable)
BIOS-e820: 000f - 0010 (reserved)
BIOS-e820: 0010 - 7fe8cc00 (usable)
end snip---
As you
Nick Piggin <[EMAIL PROTECTED]> writes:
> On Thursday 06 September 2007 03:41, Bernd Schubert wrote:
> Minor nit: when resubmitting a patch, you should include everything
> (ie. the full changelog of problem statement and fix description) in a
> single mail. It's just a bit easier...
Will do
On Saturday 08 September 2007 06:01, Goswin von Brederlow wrote:
> Nick Piggin <[EMAIL PROTECTED]> writes:
> > On Thursday 06 September 2007 03:41, Bernd Schubert wrote:
> > Minor nit: when resubmitting a patch, you should include everything
> > (ie. the full changelog of problem statement and fix
This driver uses the inet_lro facilities , but it doesn't force it
to be enabled .. Someone would have to know to enable inet_lro if
they select the driver ..
Instead, just force INET_LRO if this driver is selected..
Signed-off-by: Daniel Walker <[EMAIL PROTECTED]>
---
drivers/net/Kconfig |
Sorry to have left this dormant for so long.
Running eject in either of the ways suggested still leaves the light on
my particular key turned on.
Stefan Richter wrote:
Guennadi Liakhovetski wrote:
I might imagine how windows turns the LED off on
unmount. Try "eject /dev/sdX", where sdX
On Fri, 2007-09-07 at 12:57 -0700, Paul E. McKenney wrote:
> Actually, list_for_each_continue_rcu() needs to be removed in favor of
> your new list_for_each_entry_continue_rcu(). There are currently only
> two users as of 2.6.22. One of them immediately does a list_entry(),
> and the other
On Fri, Sep 07, 2007 at 09:09:52PM +0200, Johannes Berg wrote:
> On Fri, 2007-09-07 at 08:34 -0700, Paul E. McKenney wrote:
>
> > > + * Continue to iterate over rcu list of given type, continuing after
> > > + * the current position.
> >
> > Please add something like the following to this
Kernel: v2.6.23-rc5+ (b21010ed6498391c0f359f2a89c907533fe07fec)
Ubuntu Feisty, Radeon R200 (9200) dual head, MergedFB, BZFlag in
OpenGL mode, frozen. That'll teach me playing games at home...
BUG: unable to handle kernel paging request at virtual address ffa85000
printing eip:
c016eed1
*pde =
Subject: [RFC][Intel-IOMMU] Fix for IOMMU early crash
Populating pci_bus->sysdata way early in the pci discovery phase
sets NON-NULL value to pci_dev->sysdata which breaks the assumption
in the Intel IOMMU driver and crashes the system.
In the drivers/pci/probe.c, pci_dev->sysdata gets a copy
On 07.09.2007 14:58, Takashi Iwai wrote:
> At Fri, 07 Sep 2007 14:04:01 +0200,
> Thorsten Leemhuis wrote:
>> On 07.09.2007 12:21, Takashi Iwai wrote:
>>> At Fri, 07 Sep 2007 10:22:27 +0200,
>>> Romano Giannetti wrote:
Takashi: good news!
diff --git a/sound/pci/hda/patch_realtek.c
On 09/01/2007 06:07 AM, Andi Kleen wrote:
>> write_seqlock_irqsave(_gtod_data.lock, flags);
>> /* copy vsyscall data */
>> vsyscall_gtod_data.clock.vread = clock->vread;
>> vsyscall_gtod_data.clock.cycle_last = clock->cycle_last;
>>
On Fri, Sep 07, 2007 at 08:52:38PM +0200, Bernd Schubert wrote:
> No further response to our patches yet, so we are sending them again,
> re-diffed against 2.6.23-rc5
>
> Hi,
>
> recently we discovered writing to a nfs-exported lustre filesystem is rather
> slow (20-40 MB/s writing, but over
Folkert van Heusden <[EMAIL PROTECTED]> writes:
> Ok, but that's not the most common situaties. What I'm suggesting is a
> warning or a please note popup. Not neccessarily an error or refusing to
> continue thing.
What IMHO makes sense is changing all references to SCSI CDROM,
SCSI DISK etc. to
On 09/06/2007 07:31 AM, Andi Kleen wrote:
> Chuck Ebbert <[EMAIL PROTECTED]> writes:
>
>> Some systems lock up without the noapic option.
>
> Please find patterns: cpu type, chipsets, mainboard vendors etc.
>
This is the first one I've actually had in front of me:
HP TX1000 notebook
On Fri, Sep 07, 2007 at 01:10:54PM -0400, [EMAIL PROTECTED] wrote:
> Anybody got a proposed scheme for the case where somebody like myself
> who is *not* a member of the Maintainer Cabal has looked at a patch, and
> found a valid show-stopper that's bigger than just whitespace (breaks on
> 64-bit,
On Fri, 2007-09-07 at 18:01 +0200, Michael Buesch wrote:
> What's the problem with trying to lock it?
I think I had a problem with it once when I inserted it into some code
that was atomic and it all blew up badly ;) Nothing important really but
it sort of made me not like it much.
johannes
On Fri, 7 Sep 2007 20:52:38 +0200 Bernd Schubert wrote:
> mm/filemap.c | 139 +
> 1 file changed, 95 insertions(+), 44 deletions(-)
>
>
> Index: linux-2.6.23-rc5/mm/filemap.c
> ===
On Fri, 2007-09-07 at 08:34 -0700, Paul E. McKenney wrote:
> > + * Continue to iterate over rcu list of given type, continuing after
> > + * the current position.
>
> Please add something like the following to this comment:
>
> Note that the caller is responsible for making sure that
>
No further response to our patches yet, so we are sending them again,
re-diffed against 2.6.23-rc5
Hi,
recently we discovered writing to a nfs-exported lustre filesystem is rather
slow (20-40 MB/s writing, but over 200 MB/s reading).
As I already explained on the nfs mailing list, this
On Thursday 06 September 2007 03:41, Bernd Schubert wrote:
> > This comment block should be:
> >
> > /**
> > * generic_file_buffered_write - handle an iov
> > * @iocb: file operations
> > * @iov:vector of data to write
> > * @nr_segs:number of iov segments
> > * @pos:
In message <[EMAIL PROTECTED]>, "Josef 'Jeff' Sipek" writes:
> On Fri, Sep 07, 2007 at 01:28:55PM +0530, Bharata B Rao wrote:
> > On Fri, Sep 07, 2007 at 04:31:26PM +0900, [EMAIL PROTECTED] wrote:
> > >
> > > When the first readdir is issued:
> > > - call vfs_readdir for every underlying opened
On Fri, 2007-09-07 at 18:30 +0100, Denys Vlasenko wrote:
> On Friday 07 September 2007 17:31, Daniel Walker wrote:
> > On Thu, 2007-09-06 at 18:07 +0100, Denys Vlasenko wrote:
> > > A bit extended version:
> > >
> > > In the process in making it work I saw ~10% vmlinux size reductions
> > >
On Fri, Sep 07, 2007 at 01:28:55PM +0530, Bharata B Rao wrote:
> On Fri, Sep 07, 2007 at 04:31:26PM +0900, [EMAIL PROTECTED] wrote:
> >
> > When the first readdir is issued:
> > - call vfs_readdir for every underlying opened dir (file) object.
> > - store every entry to either the hash table for
On Fri, 2007-09-07 at 19:24 +0200, Sam Ravnborg wrote:
> Hi Daniel.
>
> > > I did that before I posted patches to lkml.
> > > IOW: posted patches are not broken versus module loading.
> >
> > Ok, this is more like the explanation I was looking for..
> >
> > During this thread you seemed to
On Friday 07 September 2007 17:31, Daniel Walker wrote:
> On Thu, 2007-09-06 at 18:07 +0100, Denys Vlasenko wrote:
> > A bit extended version:
> >
> > In the process in making it work I saw ~10% vmlinux size reductions
> > (which basically matches what Marcelo says) when I wasn't retaining
> >
Hi Daniel.
> > I did that before I posted patches to lkml.
> > IOW: posted patches are not broken versus module loading.
>
> Ok, this is more like the explanation I was looking for..
>
> During this thread you seemed to indicate the patches you release
> reduced the kernel ~10% , but now your
On Fri, 07 Sep 2007 12:04:45 EDT, Theodore Tso said:
> This was proposed by Andrew and discussed at the Kernel Summit; the
> basic idea is that it is a formal indication that the person has done
> a *full* review of the patch (a few random comments from the local
> whitespace police don't count),
Linus, please pull from the for-linus branch at
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git
for-linus
to receive a fix of the laptop-refuses-to-suspend kind. Or simply apply
the patch from this mail.
There is still an old underlying oddness though which I ask
> > I'm assuming you're running some sort of Fedora/RHEL/
> > derivative; this is what you get when you have a device that starts
> > out named ethX, but which needed to be renamed so that an already
> > configured ethX could be changed to that name.
>
> yes, it's FC6.
>
> > For the new device,
On Thu, 2007-09-06 at 18:07 +0100, Denys Vlasenko wrote:
> A bit extended version:
>
> In the process in making it work I saw ~10% vmlinux size reductions
> (which basically matches what Marcelo says) when I wasn't retaining
> sections needed for EXPORT_SYMBOLs, but module loading didn't work.
>
> If a device has a . scheme this implies possibility of
> having several instances of said device in a box. There are a few of
> platform devices that can only have one instance
Like USB peripheral controllers. Only one external "B" type
connector is allowed.
> - for example i8042
>
Hi Dmitry,
Thanks for your answer.
On Fri, 7 Sep 2007 10:58:31 -0400, Dmitry Torokhov wrote:
> On 9/7/07, Jean Delvare <[EMAIL PROTECTED]> wrote:
> > While platform_device.id is a u32, platform_device_add() handles "-1" as
> > a special id value. This has potential for confusion and bugs. One
The shrinking of a virtual memory area that is mmap(2)'d to a memory
special file (device drivers/char/mspec.c) can cause a panic.
If the mapped size of the vma (vm_area_struct) is very large, mspec allocates
a large vma_data structure with vmalloc(). But such a vma can be shrunk by
an
Folkert van Heusden wrote:
>> I know that it's difficult to get people to read docs & help text,
>> and maybe it is needed in more places, but CONFIG_ATA (SATA/PATA)
>> help text says:
>> NOTE: ATA enables basic SCSI support; *however*,
>> 'SCSI disk support', 'SCSI tape support', or
>>
On Thu, Sep 06, 2007 at 04:37:37PM -0700, Randy Dunlap wrote:
> Thanks. I look forward to the explanation of Reviewed-by, what it
> means, and how it differs from Acked-by.
This was proposed by Andrew and discussed at the Kernel Summit; the
basic idea is that it is a formal indication that the
Hi there!
Below is a fix for this:
http://bugzilla.kernel.org/show_bug.cgi?id=8876
Applies to any version since 2.6.22 to latest: 2.6.23-rc5-git1
please apply :)
-CUT-
diff -urN a/net/ipv4/devinet.c b/net/ipv4/devinet.c
--- a/net/ipv4/devinet.c
--- Kyle Moffett <[EMAIL PROTECTED]> wrote:
> ...
>
> As for the script, I'm partway through debugging it but my time is
> all chewed up with other stuff now, so it may take me an extra couple
> days.
Any progress on this?
Casey Schaufler
[EMAIL PROTECTED]
-
To unsubscribe from this
On Friday 07 September 2007, Johannes Berg wrote:
> On Thu, 2007-09-06 at 08:46 -0700, Paul E. McKenney wrote:
>
> > Looks good to me from an RCU viewpoint. I cannot claim familiarity with
> > this code. I therefore especially like the indications of where RTNL
> > is held and not!!!
>
> :)
>
> > Maybe it is a nice enhancement for make menuconfig to more explicitly
> > give a pop-up or so when someone selects for example a sata controller
> > while no 'scsi-disk' support was selected?
>
> I know that it's difficult to get people to read docs & help text,
> and maybe it is needed in
>From: Zhang Wei [mailto:[EMAIL PROTECTED]
>Sent: Friday, September 07, 2007 3:54 AM
>To: [EMAIL PROTECTED]; Nelson, Shannon
>Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED];
>[EMAIL PROTECTED]; Zhang Wei; Ebony Zhu
>Subject: [PATCH 5/5] Add DMA engine driver for Freescale
>MPC85xx
On Fri, 7 Sep 2007 18:54:18 +0800 Zhang Wei wrote:
> Signed-off-by: Zhang Wei <[EMAIL PROTECTED]>
> Signed-off-by: Ebony Zhu <[EMAIL PROTECTED]>
> ---
> drivers/dma/Kconfig |8 +
> drivers/dma/Makefile |1 +
> drivers/dma/fsldma.c | 995
>
On Thursday 06 September 2007 02:05, Andrew Morton wrote:
> > On Thu, 23 Aug 2007 11:25:18 -0400 Chuck Ebbert <[EMAIL PROTECTED]>
> > wrote: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248355
> >
> > Description of problem:
> > Warnings in the kernel log (dmesg):
> > BUG: warning at
Andrew Morton wrote:
>> On Fri, 7 Sep 2007 08:28:05 +0100 Andi Kleen <[EMAIL PROTECTED]> wrote:
>> On Friday 07 September 2007 05:09, [EMAIL PROTECTED] wrote:
>>> Since the core kernel routines need to reference cpu_sibling_map,
>>> whether it be a static array or a per_cpu data variable, an
Andi Kleen wrote:
> On Friday 07 September 2007 05:09, [EMAIL PROTECTED] wrote:
>> Since the core kernel routines need to reference cpu_sibling_map,
>> whether it be a static array or a per_cpu data variable, an access
>> function has been defined.
>>
>> In addition, changes have been made to the
Kamalesh Babulal wrote:
> Kamalesh Babulal wrote:
>> [EMAIL PROTECTED] wrote:
>>> Convert cpu_sibling_map to a per_cpu cpumask_t array for the ppc64
>>> architecture.
>>>
>>> Note: these changes have not been built nor tested.
>>>
>>> Note: I also don't know if these changes are particularly
>>>
On Friday 07 September 2007 09:00, Andrew Morton wrote:
> > On Thu, 6 Sep 2007 14:40:11 -0400 Mathieu Desnoyers
> > <[EMAIL PROTECTED]> wrote: Hi Andrew,
> >
> > Guess what, another one ;)
> >
> >
> > /opt/crosstool/gcc-4.1.1-glibc-2.3.6/powerpc-405-linux-gnu/bin/powerpc-40
> >5-linux-gnu-gcc
On Fri, 7 Sep 2007 14:48:00 +0200 Folkert van Heusden wrote:
> Hi,
>
> Maybe it is a nice enhancement for make menuconfig to more explicitly
> give a pop-up or so when someone selects for example a sata controller
> while no 'scsi-disk' support was selected?
I know that it's difficult to get
1 - 100 of 349 matches
Mail list logo
