Chris Mason wrote:
On Sun, Jun 24, 2007 at 05:47:55AM +0200, Nick Piggin wrote:
My gut feeling is that there are several problem areas you haven't hit
yet, with the new code.
I would agree with your gut :)
Without having read the code yet (light reading for monday morning ;),
ext3 and re
Tomasz Kłoczko wrote:
Few dayas ago OSS source code was oppened uder CDDL for Solaris and
GLPv2 for Linux:
http://www.opensound.com/press/2007/oss-gpl-cddl.txt
So this source without problems code can be integragrated in Linus tree
and after this Linux can provide much better soud supoport
Tomasz Kłoczko wrote:
On Sun, 24 Jun 2007, Alan Cox wrote:
[..]
Years ago Linux dumped OSS for ALSA because ALSA offered far better
functionality and support. Why would we go back to the stone age ?
Its something useful to various other platforms with basically no
hardware support but Linux has
At Fri, 22 Jun 2007 09:56:35 -0500,
Matt Mackall wrote:
>
> On Fri, Jun 22, 2007 at 05:08:07PM +0900, Yoshinori Sato wrote:
> > Because the page which SLOB allocator got does not have PG_slab,
>
> This is for a NOMMU system?
Yes.
> You're using an old kernel with an old version of SLOB. SLOB i
Andrew Morton wrote:
On Tue, 19 Jun 2007 15:38:01 -0700 (PDT)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
Ok and BUILD_BUG_ON really works? Had some bad experiences with it.
hm, I don't recall any problems, apart from its very obscure error
reporting.
But if it breaks, we get an opportuni
On Sat, Jun 23, 2007 at 12:36:08PM +0200, Miklos Szeredi wrote:
...
> And it's not a NO_HZ kernel.
...
BTW, maybe I've missed this and it's unconnected, but I hope the
first config has been changed - especially this CONFIG_AGP_AMD64 = y,
and this bug from mm/slab.c has gone long ago...
Jarek P.
-
On Sun, Jun 24, 2007 at 06:23:45AM +0200, Nick Piggin wrote:
> I'd just like to take the chance also to ask about a VM/FS meetup some
> time around kernel summit (maybe take a big of time during UKUUG or so).
I won't be around until a day or two before KS, so I'd prefer to have it
after KS if poss
Am Montag 25 Juni 2007 04:51 schrieb David Brownell:
> On Thursday 10 May 2007, Hans-Jürgen Koch wrote:
> > Am Donnerstag 10 Mai 2007 22:07 schrieb David Brownell:
> > > On Friday 27 April 2007, David Brownell wrote:
> > > > On Friday 27 April 2007, Hans-Jürgen Koch wrote:
> > > >
> > > > > >
On Mon, Jun 25, 2007 at 04:17:56PM +1000, Nick Piggin wrote:
> Paul Mundt wrote:
> >This adds preliminary NUMA support to SLOB, primarily aimed at systems
> >with small nodes (tested all the way down to a 128kB SRAM block), whether
> >asymmetric or otherwise.
>
> Fine by me as well, FWIW. My point
Paul Mundt wrote:
This adds preliminary NUMA support to SLOB, primarily aimed at systems
with small nodes (tested all the way down to a 128kB SRAM block), whether
asymmetric or otherwise.
Fine by me as well, FWIW. My points about per-cpu/node queues were not
to say that I'm really opposed to ge
don't forget -> if you're going to accept extra stuff. GCC forgot ->
with the parser rewrite, yes I filed a PR.
-> is not allowed within the second arg to __builtin_offsetof().
Or do you mean something else? What's the PR #, and did it ever
get fixed?
Segher
-
To unsubscribe from this list:
Humm... Right, so __builtin_offsetof() needs special treatment too.
Oh, bugger. Is
offsetof(struct foo, a.x[n])
a documented extension?
It is. See info gcc -> C Extensions -> Offsetof
Segher
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
I'm happy to say that things seem to have calmed down after -rc5, and that
most of this really is just bugfixes and regression fixing in particular.
Knock wood.
So nothing really too exciting here, but hopefully we're getting closer to
a real 2.6.22 release. Please *do* test it, and in particu
> +static int bus_notify(struct notifier_block *nb, unsigned long action,
> + void *data)
> +{
> + struct device *dev = data;
> +
> + printk("bus notify called\n");
> +
> + /* We are only intereted in device addition */
> + if (action != BUS_NOTIFY_ADD_DEVICE)
> +
On Sun, Jun 24, 2007 at 07:54:39PM -0500, Olof Johansson wrote:
> ppc64 really needs ioaddr_t to be 32-bit, since I/O addresses really are
> MMIO addresses, and remapped at an offset that's well above 16 bits in
> some cases.
>
> While the type is exported to userspace, there hasn't been any platf
Al Viro wrote:
> Joy. OK, folks, disregard 16/16 in the current form; everything prior
> to it stands on its own.
Acknowledged. The rest of the patches look good to me, so I'll merge 1-15
soon, and ignore 16.
Do you have those patches in public git somewhere, or would you like me to
just apply
On Sun, Jun 24, 2007 at 09:43:03PM -0700, Arjan van de Ven wrote:
> On Sun, 2007-06-24 at 22:45 -0500, Matt Mackall wrote:
> > On Sun, Jun 24, 2007 at 07:45:04PM +0200, Alexander Gabert wrote:
> > > Hi Linus,
> > > hi LKML,
> > >
> > > i would like to thank LKML and especially Eric (thanks for the
On Sat, Jun 09, 2007 at 10:25:16AM +0100, Richard Purdie wrote:
> Anyhow, time to stop pretending I have any choice in this ;-). I will
> have the LED class use random numbers for busids and add a name
> attribute unless anyone else voices an opinion.
Thank you, I really appreciate it, and so does
On Sun, Jun 24, 2007 at 06:33:15PM -0700, [EMAIL PROTECTED] wrote:
> On Sun, 24 Jun 2007, Arjan van de Ven wrote:
>
> >On Sun, 2007-06-24 at 18:08 -0700, [EMAIL PROTECTED] wrote:
> >>>
> >>>on a system level, size can help performance because you have more
> >>>memory available for other things.
So i choice to use switch_root which is already inside the busybox but with a
bit(?) of unluck cause it still wont run.
It hangs on !S_ISREG(st1.st_mode)
Can you explain to me how to interpret it?
Regards
S.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
Robert Iakobashvili wrote:
Hi,
On Sun, 24 Jun 2007 12:20:01 -0500 David Jones <[EMAIL PROTECTED]>
wrote:
> I am trying to add multiple IP addresses ( v6 ) to my FC7 box on eth0.
> But I am hitting a max limit of 4000 IP address . Seems like there
is a
> limiting variable in linux kernel (w
On Sun, 24 Jun 2007, Petr Vandrovec wrote:
> > -module_param(debug, bool, 0600);
> > -MODULE_PARM_DESC(debug, "Debug enabled or not");
> > +static int __init root_plug_debug(char *str)
> > +{
> > + debug = simple_strtol(str, NULL, 0);
> > + return 1;
> > +}
> > +__setup("root_plug_debug=", roo
Quoting Chris Wright ([EMAIL PROTECTED]):
> * Serge E. Hallyn ([EMAIL PROTECTED]) wrote:
> > Sigh, as much as I would *like* to stay out of this (I don't
> > use modules at all on any system where I can avoid it), won't
> > it make development - and especially testing - of new lsms
> > much more pa
James Morris wrote:
Convert LSM into a static interface, as the ability to unload a security
module is not required by in-tree users and potentially complicates the
overall security architecture.
Hello,
-module_param(debug, bool, 0600);
-MODULE_PARM_DESC(debug, "Debug enabled or not");
+stat
On Sun, 2007-06-24 at 22:45 -0500, Matt Mackall wrote:
> On Sun, Jun 24, 2007 at 07:45:04PM +0200, Alexander Gabert wrote:
> > Hi Linus,
> > hi LKML,
> >
> > i would like to thank LKML and especially Eric (thanks for the per_cpu
> > macro tips and design guidelines!) and the other contributors to
Convert LSM into a static interface, as the ability to unload a security
module is not required by in-tree users and potentially complicates the
overall security architecture.
Needlessly exported LSM symbols have been unexported, to help reduce API
abuse.
Parameters for the capability and root_
Petr Vandrovec wrote:
>>> Hmmm... The last one (HTS541612J9SA00) is taken directly from hdparm
>>> output, and I think I verified the patch with the reporter. Hmm... Can
>>> anyone verify these module strings?
>>
>> Could well be that they've started attaching Hitachi to the ID strings
>> now.. In
Robert Hancock wrote:
Tejun Heo wrote:
Petr Vandrovec wrote:
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index adfae9d..fbca8d8 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3803,6 +3803,7 @@ static const struct ata_blacklist_entry
ata_device_
Tejun Heo wrote:
Robert Hancock wrote:
Tejun Heo wrote:
Another member of HTS5416* family doing spurious NCQ completion.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Cc: Enrico Sardi <[EMAIL PROTECTED]>
---
drivers/ata/libata-core.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drive
Tejun Heo wrote:
Petr Vandrovec wrote:
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index adfae9d..fbca8d8 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3803,6 +3803,7 @@ static const struct ata_blacklist_entry
ata_device_blacklist [] = {
/
* Serge E. Hallyn ([EMAIL PROTECTED]) wrote:
> Sigh, as much as I would *like* to stay out of this (I don't
> use modules at all on any system where I can avoid it), won't
> it make development - and especially testing - of new lsms
> much more painful and therefore less likely?
Dev, hopefully not
Petr Vandrovec wrote:
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index adfae9d..fbca8d8 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3803,6 +3803,7 @@ static const struct ata_blacklist_entry
ata_device_blacklist []
Mark Lord wrote:
> Robert de Rooy wrote:
>
>>
>> I did another try with libata pcmcia support using 2.6.22-rc5 which
>> already includes the nodata polling fix, in combination with
>> disable-dev_init_param-and-setxfermode-for-CFA.patch and the
>> timing-debug.patch
>
> ...
>
>> Jun 22 13:19:44
Arnd Hannemann wrote:
> Jan Engelhardt schrieb:
>> On Jun 24 2007 23:27, Salvatore De Paolis wrote:
>>> i built the kernel with a busybox initramfs which runs from a usb stick.
>>> While
>>> i boot i need to mount the real root and i'm using pivot_root.
>>> Pivot_root . old-root return to me an "I
* Casey Schaufler ([EMAIL PROTECTED]) wrote:
> Just hoping to avoid a change collision. If I have to deal
> with this today it's easy, if it doesn't show up anywhere
> until 2.6.28 I'm breezing, but if it all hits in two weeks I
> have some scrambling and yet another delay to deal with. Not
> your
Quoting James Morris ([EMAIL PROTECTED]):
> Convert LSM into a static interface, as the ability to unload a security
> module is not required by in-tree users and potentially complicates the
> overall security architecture.
>
> Needlessly exported LSM symbols have been unexported, to help reduce
On Sun, Jun 24, 2007 at 07:45:04PM +0200, Alexander Gabert wrote:
> Hi Linus,
> hi LKML,
>
> i would like to thank LKML and especially Eric (thanks for the per_cpu
> macro tips and design guidelines!) and the other contributors to this idea.
>
> This time the patch is rather big because it also
Hi,
I reconfig my kernel, boot and oops, EIP in __change_page_attr:166, I
tried 2.6.22-rc4-mm2 and 2.6.22-rc5 , same result.
Anyone has some clues?
here is my config file:
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.22-rc5
# Mon Jun 25 11:11:05 2007
#
CONFIG_
I sent a patch to the ALSA developers 4 years ago.
It was never included in the kernel :/
ALSA maintainers are very open to patches. try sending this again
Here's the comment from a script that I once wrote to
make some closed-source dinosar code run (speech recognition)
on modern linux:
# N
--- Chris Wright <[EMAIL PROTECTED]> wrote:
> * Casey Schaufler ([EMAIL PROTECTED]) wrote:
> > So, for planning purposes, when ought I expect to have to start
> > dealing with this?
>
> What is your specific concern or use case?
Just hoping to avoid a change collision. If I have to deal
with th
Currently there are 97 occurrences where drivers need the pci
revision ID. We can do this once for all devices. Even the pci
subsystem needs the revision several times for quirks. The extra
u8 member pads out nicely in the pci_dev struct.
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
arch/powe
On Jun 22, 2007, at 18:51:10, C. Scott Ananian wrote:
Back to kernel-land: in an IPv6 only world, it might make sense to
export a /proc file compatible with the format of /etc/resolv.conf,
with one DNS server address per line. If glibc uses/used inotify
on /etc/resolv.conf, then symlinking
On Thursday 10 May 2007, Hans-Jürgen Koch wrote:
> Am Donnerstag 10 Mai 2007 22:07 schrieb David Brownell:
> > On Friday 27 April 2007, David Brownell wrote:
> > > On Friday 27 April 2007, Hans-Jürgen Koch wrote:
> > >
> > > > >the m25p80 driver
> > > > > was pretty close to working with t
Robert Hancock wrote:
> Tejun Heo wrote:
>> Another member of HTS5416* family doing spurious NCQ completion.
>>
>> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
>> Cc: Enrico Sardi <[EMAIL PROTECTED]>
>> ---
>> drivers/ata/libata-core.c |1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a
Tejun Heo wrote:
Another member of HTS5416* family doing spurious NCQ completion.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Cc: Enrico Sardi <[EMAIL PROTECTED]>
---
drivers/ata/libata-core.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata
On Mon, Jun 25, 2007 at 03:35:56AM +0200, Arnd Bergmann wrote:
> On Monday 25 June 2007, Olof Johansson wrote:
> > ppc64 really needs ioaddr_t to be 32-bit, since I/O addresses really are
> > MMIO addresses, and remapped at an offset that's well above 16 bits in
> > some cases.
> >
> > While the t
Enrico Sardi wrote:
> This is the result of hdparm -I /dev/sda:
>
> /dev/sda:
>
> ATA device, with non-removable media
>Model Number: Hitachi HTS541616J9SA00
Just in case, you didn't add "Hitachi " in the front of Model Number
string, right? It looks a bit odd because all other HTS541
Another member of HTS5416* family doing spurious NCQ completion.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Cc: Enrico Sardi <[EMAIL PROTECTED]>
---
drivers/ata/libata-core.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index adfae
On Mon, 25 Jun 2007, Adrian Bunk wrote:
On Sun, Jun 24, 2007 at 09:34:05PM -0400, Jeff Garzik wrote:
Adrian Bunk wrote:
The interesting questions are:
Does -Os still sometimes generate faster code with gcc 4.2?
If yes, why?
Smaller code can mean fewer page faults, fewer cache invalidations,
Andrew Morton wrote:
> That great spew of "set_level status: 0" is fairly annoying and useless.
I don't know where those are coming from. It's not from libata.
--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More m
Robert Hancock wrote:
> Andrew Morton wrote:
>> On Sun, 24 Jun 2007 14:32:22 +0200 Enrico Sardi <[EMAIL PROTECTED]>
>> wrote:
>>> [ 61.176000] ata1.00: exception Emask 0x2 SAct 0x2 SErr 0x0 action
>>> 0x2 frozen
>>> [ 61.176000] ata1.00: (spurious completions during NCQ issue=0x0
>>> SAct=0x2 F
On Sun, Jun 24, 2007 at 05:22:30PM -0700, Yinghai Lu wrote:
> On 6/23/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> >> void __init gart_iommu_init(void)
> >> {
> >> struct agp_kern_info info;
> >> diff --git a/arch/x86_64/kernel/pci-dma.c b/arch/x86_64/kernel/pci-dma.c
> >> index 9f80aad..
On Sun, Jun 24, 2007 at 09:34:05PM -0400, Jeff Garzik wrote:
> Adrian Bunk wrote:
>> The interesting questions are:
>> Does -Os still sometimes generate faster code with gcc 4.2?
>> If yes, why?
>
> Smaller code can mean fewer page faults, fewer cache invalidations, etc.
>
> It's not just a matter
On 06/25/2007 03:33 AM, [EMAIL PROTECTED] wrote:
is the list of what's included in -O2 vs -Os different for different
CPU's? what about within a single family of processors? (even in the x86
family the costs of jumps, loops, and cache misses varies drasticly)
At least not in the example Duron
* Casey Schaufler ([EMAIL PROTECTED]) wrote:
> So, for planning purposes, when ought I expect to have to start
> dealing with this?
What is your specific concern or use case?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Mor
* James Morris ([EMAIL PROTECTED]) wrote:
> On Sun, 24 Jun 2007, Chris Wright wrote:
>
> > * James Morris ([EMAIL PROTECTED]) wrote:
> > > -module_param_named(disable, capability_disable, int, 0);
> > > -MODULE_PARM_DESC(disable, "To disable capabilities module set disable =
> > > 1");
> > > +
>
On Monday 25 June 2007, Olof Johansson wrote:
> ppc64 really needs ioaddr_t to be 32-bit, since I/O addresses really are
> MMIO addresses, and remapped at an offset that's well above 16 bits in
> some cases.
>
> While the type is exported to userspace, there hasn't been any platforms
> with PCMCIA
On 06/25/2007 03:23 AM, Rene Herman wrote:
On 06/25/2007 02:41 AM, Adrian Bunk wrote:
The interesting questions are:
Does -Os still sometimes generate faster code with gcc 4.2?
If yes, why?
I would wager that the CPU type makes more of a difference than the
compiler version. That is, I'd ex
Adrian Bunk wrote:
The interesting questions are:
Does -Os still sometimes generate faster code with gcc 4.2?
If yes, why?
Smaller code can mean fewer page faults, fewer cache invalidations, etc.
It's not just a matter of compiler code generation, gotta look at the
whole picture.
Je
On Sun, 24 Jun 2007, Arjan van de Ven wrote:
On Sun, 2007-06-24 at 18:08 -0700, [EMAIL PROTECTED] wrote:
on a system level, size can help performance because you have more
memory available for other things. It also reduces download size and
gives you more space on the live CD
if you want
On Sun, Jun 24, 2007 at 05:58:46PM -0700, Arjan van de Ven wrote:
>
> > I wouldn't care if CONFIG_CC_OPTIMIZE_FOR_SIZE was hidden behind
> > CONFIG_EMBEDDED, but as long as it's available as a general purpose
> > option we have to consider it's performance.
>
> I think you are missing the point.
On 06/25/2007 02:41 AM, Adrian Bunk wrote:
The interesting questions are:
Does -Os still sometimes generate faster code with gcc 4.2?
If yes, why?
I would wager that the CPU type makes more of a difference than the compiler
version. That is, I'd expect my Duron with it's "puny" 64K L1 to have
On Sun, 2007-06-24 at 18:08 -0700, [EMAIL PROTECTED] wrote:
> >
> > on a system level, size can help performance because you have more
> > memory available for other things. It also reduces download size and
> > gives you more space on the live CD
> >
> > if you want to make things bigger agai
On Sun, 24 Jun 2007, Arjan van de Ven wrote:
I wouldn't care if CONFIG_CC_OPTIMIZE_FOR_SIZE was hidden behind
CONFIG_EMBEDDED, but as long as it's available as a general purpose
option we have to consider it's performance.
I think you are missing the point. You tell the kernel to
OPTIMIZE_FOR_
On 2007.06.23 11:50:49 +, Andrew Morton wrote:
> On Sat, 23 Jun 2007 14:42:21 -0400 Dave Jones <[EMAIL PROTECTED]> wrote:
>
> > > I probably _could_ work this out, and kinda did with a bit of
> > list-trolling
> > > (verdict: needed in 2.6.22) but please, take care to describe the
> > > im
> I wouldn't care if CONFIG_CC_OPTIMIZE_FOR_SIZE was hidden behind
> CONFIG_EMBEDDED, but as long as it's available as a general purpose
> option we have to consider it's performance.
I think you are missing the point. You tell the kernel to
OPTIMIZE_FOR_SIZE. *over performance*. Sure. Performanc
Driver for the CompactFlash slot on the PA Semi Electra eval board. It's
a simple device sitting on localbus, with interrupts and detect/voltage
control over GPIO.
The driver is implemented as an of_platform driver, and adds localbus
as a bus being probed by the of_platform framework.
Signed-off
ppc64 really needs ioaddr_t to be 32-bit, since I/O addresses really are
MMIO addresses, and remapped at an offset that's well above 16 bits in
some cases.
While the type is exported to userspace, there hasn't been any platforms
with PCMCIA on 64-bit powerpc until now, so changing it won't regress
On Sun, Jun 24, 2007 at 05:23:42PM -0700, Arjan van de Ven wrote:
> On Sun, 2007-06-24 at 20:12 -0400, Benjamin LaHaise wrote:
> > On Sun, Jun 24, 2007 at 05:09:16PM -0700, Arjan van de Ven wrote:
> > > if you care about the last cycle, don't specify -Os but -O2.
> > > simple as that... you get wha
On Mon, Jun 25, 2007 at 12:07:23AM +0200, Carlo Wood wrote:
> On Sun, Jun 24, 2007 at 12:59:10PM -0400, Justin Piszcz wrote:
> > Concerning NCQ/no NCQ, without NCQ I get an additional 15-50MB/s in speed
> > per various bonnie++ tests.
>
> There is more going on than a bad NCQ implementation of th
On Sun, 24 Jun 2007, Russell King wrote:
> On Sun, Jun 24, 2007 at 11:24:16AM +0100, Hugh Dickins wrote:
> > On Sun, 24 Jun 2007, Russell King wrote:
> > > On Fri, Jun 22, 2007 at 07:39:33PM +0100, Hugh Dickins wrote:
> > >
> > > Please forward the original problem report.
> >
> > Done.
>
> Okay
On Sun, 2007-06-24 at 20:12 -0400, Benjamin LaHaise wrote:
> On Sun, Jun 24, 2007 at 05:09:16PM -0700, Arjan van de Ven wrote:
> > if you care about the last cycle, don't specify -Os but -O2.
> > simple as that... you get what you tell the compiler you want.
>
> Certain distros are shipping kernel
On 6/23/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> void __init gart_iommu_init(void)
> {
> struct agp_kern_info info;
> diff --git a/arch/x86_64/kernel/pci-dma.c b/arch/x86_64/kernel/pci-dma.c
> index 9f80aad..64f2ab3 100644
> --- a/arch/x86_64/kernel/pci-dma.c
> +++ b/arch/x86_64/ker
On 6/23/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
So my suggestion would be:
(1) implement sysfs platform device based shutdown hooks (preferable
before PCI shutdown)
BTW, it would be better if DMA ram range was registered there too.
(2) make sure GART is never enabled in kernels that are a
On Sun, 2007-06-24 at 09:40 -0700, Linus Torvalds wrote:
>
> On Sat, 23 Jun 2007, Peter Zijlstra wrote:
>
> > On Thu, 2007-06-21 at 16:08 -0700, Linus Torvalds wrote:
> > >
> > > The vm_dirty_ratio thing is a global value, and I think we need that
> > > regardless (for the independent issue of
Hi,
On Sat, 23 Jun 2007, Jan Engelhardt wrote:
> Would it make sense to define a new entity called "configmenu" (or something
> else) that is equivalent to menuconfig with the following changes?
>
> * it creates a CM_ variable instead of a CONFIG_ one
> * the CM_ symbols are not available to M
On Sun, Jun 24, 2007 at 05:09:16PM -0700, Arjan van de Ven wrote:
> if you care about the last cycle, don't specify -Os but -O2.
> simple as that... you get what you tell the compiler you want.
Certain distros are shipping kernels compiled with -Os. And it's more
than just a couple of cycles.
On Sun, 2007-06-24 at 19:23 -0400, Benjamin LaHaise wrote:
> On Sun, Jun 24, 2007 at 03:15:17PM -0700, Arjan van de Ven wrote:
> > we should just alias our memset to the __builtin one, and then provide a
> > generic one from lib/ for the cases gcc needs to do a fallback.
>
> The last time I checke
Carlo Wood wrote:
The following can be observed:
1) There is hardly any difference between the two schedulers (noop
is a little faster for the bonny test).
2) An NCQ depth of 1 is WAY faster on RAID5 (bonnie; around 125 MB/s),
the NCQ depth of 2 is by far the slowest for the RAID5 (bonnie
--- Chris Wright <[EMAIL PROTECTED]> wrote:
> * James Morris ([EMAIL PROTECTED]) wrote:
> > -module_param_named(disable, capability_disable, int, 0);
> > -MODULE_PARM_DESC(disable, "To disable capabilities module set disable =
> 1");
> > +
> > +static int __init capability_disable_setup(char *str
On Sat, 2007-06-23 at 23:07 -0700, David Miller wrote:
The original version of this fix have made it to the 2.6.22-rc5 already
and should be replaced with this one, however the two can coexist in the
same code for a while.
> > --- linux-2.6.21.3/drivers/net/ppp_generic.c.orig 2007-06-20
> > 09
On Jun 24, 2007, at 17:27:34, Salvatore De Paolis wrote:
i built the kernel with a busybox initramfs which runs from a usb
stick. While i boot i need to mount the real root and i'm using
pivot_root. Pivot_root . old-root return to me an "Invalid
argument" error and googling i found here htt
On Sat, Jun 23, 2007 at 12:53:11AM +0200, Michal Piotrowski wrote:
> Hi Oliver,
>
> On 22/06/07, Oliver Pinter <[EMAIL PROTECTED]> wrote:
> >Hi all!
> >
> >I found this info:
> >
> >=== [ INFO: possible
> >circular locking dependency detected ] 2
On Sun, Jun 24, 2007 at 03:15:17PM -0700, Arjan van de Ven wrote:
> we should just alias our memset to the __builtin one, and then provide a
> generic one from lib/ for the cases gcc needs to do a fallback.
The last time I checked, gcc generated horrible badly performing code for
builtin memset/m
On Sun, Jun 24, 2007 at 03:15:17PM -0700, Arjan van de Ven wrote:
>
> > > I think all these benefits are the gcc's __builtin_memset optimization
> > > than the explicit call to memset.
> >
> > ... or from complex memset() implementation (some chips even didn't do
> > `rep' fast enough somehow). M
Hi.
On Monday 25 June 2007 07:03:20 Rafael J. Wysocki wrote:
> Hi,
>
> On Friday, 22 June 2007 08:07, Nigel Cunningham wrote:
> > Hi.
> >
> > I have recently begun to try and use suspend to ram more, and have an
> > intermittent problem. Actually, it's a couple of (possibly related)
> > proble
On Mon, Jun 25, 2007 at 12:48:45AM +0200, Jesper Juhl wrote:
> Did you try resending it?
> Sometimes patches get missed, overlooked, dropped on the floor by mistake
> etc.
...
> When it comes to getting patches into mainline, asking twice (or more)
> is sometimes required, and it's considered your
On 25/06/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
On Mon, 25 Jun 2007 00:02:03 +0200 "Jesper Juhl" <[EMAIL PROTECTED]> wrote:
> > > + if (!file || !e)
> > > + exit(1);
> > >*e = '\0';
> > >cur_filename = memcpy(xmalloc(e-file+1), file, e-file+1);
> > >cur_lin
On Mon, Jun 25, 2007 at 06:42:53AM +0900, Neil Booth wrote:
> > such a big deal... Parser would need to accept
> > ident ( \[ expr \] | . ident )*
>
> don't forget -> if you're going to accept extra stuff. GCC forgot ->
> with the parser rewrite, yes I filed a PR.
In offsetof() second argum
If we fail to allocate an skb in
drivers/isdn/capi/capidrv.c::send_message(), then we'll end up
dereferencing a NULL pointer.
Since out of memory conditions are not unheard of, I believe it
is better to print a error message and just return rather than
bring down the whole kernel.
Sure, doing
On Sunday June 24, [EMAIL PROTECTED] wrote:
>
> +#define PG_blocks20 /* Page has block mappings */
> +
I've only had a very quick look, but this line looks *very* wrong.
You should be using PG_private.
There should never be any confusion about whether ->private has
buffers or b
On Mon, 25 Jun 2007 00:02:03 +0200 "Jesper Juhl" <[EMAIL PROTECTED]> wrote:
> > > + if (!file || !e)
> > > + exit(1);
> > >*e = '\0';
> > >cur_filename = memcpy(xmalloc(e-file+1), file, e-file+1);
> > >cur_line = atoi(yytext+2);
> >
> > I don't think the bug which
On 070622 21:40, Satyam Sharma <[EMAIL PROTECTED]> wrote:
> Hi Alexander, Johannes,
>
> But first: Have you checked the digsig project? It's been doing
> (for some time) what your current patchset proposes -- and
> it uses public key cryptosystems for the key management,
> which is decidedly better
On 22/06/07, Chuck Ebbert <[EMAIL PROTECTED]> wrote:
[snip]
Step 1: run fsck on the filesystem.
I agree that running fsck on the filesystem is a good idea, but still,
even a corrupt filesystem should never be able to cause an Oops. In
fact, nothing done from userspace should be able to cause a
On 25/06/07, Carlo Wood <[EMAIL PROTECTED]> wrote:
On Sun, Jun 24, 2007 at 09:57:24PM +0100, Alan Cox wrote:
> > Sory Alan but I don't want philosophical/historical discuss.
> > Try to answer on question "ALSA or OSS ?" using *only* technical arguments.
>
> We dropped OSS for ALSA for technical r
On Sun, Jun 24, 2007 at 09:57:24PM +0100, Alan Cox wrote:
> > Sory Alan but I don't want philosophical/historical discuss.
> > Try to answer on question "ALSA or OSS ?" using *only* technical arguments.
>
> We dropped OSS for ALSA for technical reasons. Those being that ALSA
> - has a better audio
On Sun, Jun 24, 2007 at 09:57:24PM +0100, Alan Cox wrote:
> > Sory Alan but I don't want philosophical/historical discuss.
> > Try to answer on question "ALSA or OSS ?" using *only* technical arguments.
>
> We dropped OSS for ALSA for technical reasons. Those being that ALSA
> - has a better audio
On Sun, 24 Jun 2007, Chris Wright wrote:
> * James Morris ([EMAIL PROTECTED]) wrote:
> > -module_param_named(disable, capability_disable, int, 0);
> > -MODULE_PARM_DESC(disable, "To disable capabilities module set disable =
> > 1");
> > +
> > +static int __init capability_disable_setup(char *str)
In drivers/isdn/capi/kcapi.c::old_capi_manufacturer(), if the call
to get_capi_ctr_by_nr(ldef.contr); in line 823 returns NULL, then
we'll be dereferencing a NULL pointer in the very next line.
(Found by Coverity checker as bug #402)
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
drivers
On Sun, 24 Jun 2007, Andrew Morton wrote:
> On Sun, 24 Jun 2007 15:21:37 -0400 (EDT) "Robert P. J. Day" <[EMAIL
> PROTECTED]> wrote:
>
> > arch/i386/kernel/irq.c |8 ++--
> > arch/sh/kernel/irq.c |8 ++--
>
> These two files are maintained by different developers who run
> separ
1 - 100 of 248 matches
Mail list logo
