On Fri, 22 April 2005 11:22:51 +0300, Denis Vlasenko wrote:
>
> I do it this way:
>
> int f()
> {
> - tuple_t tuple;
> - cisparse_t parse;
> - u_char buf[255];
> + struct {
> + tuple_t tuple;
> + cisparse_t parse;
> + u_char buf[255];
> + }
On Fri, 22 April 2005 11:22:51 +0300, Denis Vlasenko wrote:
I do it this way:
int f()
{
- tuple_t tuple;
- cisparse_t parse;
- u_char buf[255];
+ struct {
+ tuple_t tuple;
+ cisparse_t parse;
+ u_char buf[255];
+ } local;
+
On Friday 22 April 2005 01:02, Yum Rayan wrote:
> This patch reduces the stack usage of the function smc91c92_event() in
> smc91c92_cs driver from 3540 to 132. Currently this is the highest
> stack user in linux-2.6.12-rc2-mm3. I used a patched version of gcc
> 3.4.3 on i386 wi
On Friday 22 April 2005 01:02, Yum Rayan wrote:
This patch reduces the stack usage of the function smc91c92_event() in
smc91c92_cs driver from 3540 to 132. Currently this is the highest
stack user in linux-2.6.12-rc2-mm3. I used a patched version of gcc
3.4.3 on i386 with -fno-unit-at-a-time
to test it.
Acked-by: Randy Dunlap <[EMAIL PROTECTED]>
Signed-off-by: Yum Rayan <[EMAIL PROTECTED]>
serial_cs.c | 170 ++--
1 files changed, 110 insertions(+), 60 deletions(-)
diff -Nupr -X dontdiff
linux-2.6.12-rc2-mm3.a/dr
This patch reduces the stack usage of the function smc91c92_event() in
smc91c92_cs driver from 3540 to 132. Currently this is the highest
stack user in linux-2.6.12-rc2-mm3. I used a patched version of gcc
3.4.3 on i386 with -fno-unit-at-a-time disabled.
The patch has only been compile tested
This patch reduces the stack usage of the function smc91c92_event() in
smc91c92_cs driver from 3540 to 132. Currently this is the highest
stack user in linux-2.6.12-rc2-mm3. I used a patched version of gcc
3.4.3 on i386 with -fno-unit-at-a-time disabled.
The patch has only been compile tested
to test it.
Acked-by: Randy Dunlap [EMAIL PROTECTED]
Signed-off-by: Yum Rayan [EMAIL PROTECTED]
serial_cs.c | 170 ++--
1 files changed, 110 insertions(+), 60 deletions(-)
diff -Nupr -X dontdiff
linux-2.6.12-rc2-mm3.a/drivers/serial
On Wed, Apr 20 2005, Tejun Heo wrote:
> Hello, Jens.
>
> These are fixes to generic tag support in the blk layer. They all
> compile okay and I've proof read it, but as I don't have any HBA which
> uses generic tag support, I wasn't able to test directly. However,
> all changes are fairly
04_blk_tag_map_error_handling_cleanup.patch
Add KERN_ERR and __FUNCTION__ to generic tag error messages,
and add a comment in blk_queue_end_tag() which explains the
silent failure path.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
ll_rw_blk.c | 18 +-
03_blk_tag_map_remove_BLK_TAGS_PER_LONG.patch
Replace BLK_TAGS_PER_LONG with BITS_PER_LONG and remove unused
BLK_TAGS_MASK.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
drivers/block/ll_rw_blk.c |4 ++--
include/linux/blkdev.h|3 ---
2 files changed, 2
02_blk_tag_map_remove_real_max_depth.patch
blk_queue_tag->real_max_depth was used to optimize out
unnecessary allocations/frees on tag resize. However, the
whole thing was very broken - tag_map was never allocated to
real_max_depth resulting in access beyond the
01_blk_tag_map_use_find_first_zero_bit.patch
blk_queue_start_tag() hand-coded searching for the first zero
bit in the tag map. Replace it with find_first_zero_bit().
With this patch, blk_queue_star_tag() doesn't need to fill
remains of tag map with 1, thus
Hello, Jens.
These are fixes to generic tag support in the blk layer. They all
compile okay and I've proof read it, but as I don't have any HBA which
uses generic tag support, I wasn't able to test directly. However,
all changes are fairly straight-forward.
[ Start of patch descriptions ]
01_blk_tag_map_use_find_first_zero_bit.patch
blk_queue_start_tag() hand-coded searching for the first zero
bit in the tag map. Replace it with find_first_zero_bit().
With this patch, blk_queue_star_tag() doesn't need to fill
remains of tag map with 1, thus
Hello, Jens.
These are fixes to generic tag support in the blk layer. They all
compile okay and I've proof read it, but as I don't have any HBA which
uses generic tag support, I wasn't able to test directly. However,
all changes are fairly straight-forward.
[ Start of patch descriptions ]
02_blk_tag_map_remove_real_max_depth.patch
blk_queue_tag-real_max_depth was used to optimize out
unnecessary allocations/frees on tag resize. However, the
whole thing was very broken - tag_map was never allocated to
real_max_depth resulting in access beyond the
03_blk_tag_map_remove_BLK_TAGS_PER_LONG.patch
Replace BLK_TAGS_PER_LONG with BITS_PER_LONG and remove unused
BLK_TAGS_MASK.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
drivers/block/ll_rw_blk.c |4 ++--
include/linux/blkdev.h|3 ---
2 files changed, 2 insertions(+),
04_blk_tag_map_error_handling_cleanup.patch
Add KERN_ERR and __FUNCTION__ to generic tag error messages,
and add a comment in blk_queue_end_tag() which explains the
silent failure path.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
ll_rw_blk.c | 18 +-
1
On Wed, Apr 20 2005, Tejun Heo wrote:
Hello, Jens.
These are fixes to generic tag support in the blk layer. They all
compile okay and I've proof read it, but as I don't have any HBA which
uses generic tag support, I wasn't able to test directly. However,
all changes are fairly
Its a T41 "without p" :)
On Apr 8, 2005 9:09 PM, Nish Aravamudan <[EMAIL PROTECTED]> wrote:
> On Apr 7, 2005 11:28 PM, AsterixTheGaul <[EMAIL PROTECTED]> wrote:
> > > FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2,
> > > except that neither returns from suspend-to-ram with
On Apr 7, 2005 11:28 PM, AsterixTheGaul <[EMAIL PROTECTED]> wrote:
> > FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2,
> > except that neither returns from suspend-to-ram with video restored on
> > the LCD. I believe I was able to get video restored on an external CRT
> > in
Ok this time I did with radeontool and it works good :)) (2.6.12-rc2 on T41).
1. I have "radeontool regs" before susp to ram (presusp)
2. turn off LCD with "radeontool light off"
3. Suspend to RAM and wake up. (same backtrace)
4. LCD is back on (no problem)
5. regs in postsusp
only diff is
<
Err... never mind... I was not doing any radeon control.
On Apr 8, 2005 11:58 AM, AsterixTheGaul <[EMAIL PROTECTED]> wrote:
> > FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2,
> > except that neither returns from suspend-to-ram with video restored on
> > the LCD. I believe I
> FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2,
> except that neither returns from suspend-to-ram with video restored on
> the LCD. I believe I was able to get video restored on an external CRT
> in either 2.6.12-rc2 or 2.6.12-rc2-mm1, but the LCD still didn't
> restore (can
FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2,
except that neither returns from suspend-to-ram with video restored on
the LCD. I believe I was able to get video restored on an external CRT
in either 2.6.12-rc2 or 2.6.12-rc2-mm1, but the LCD still didn't
restore (can
Err... never mind... I was not doing any radeon control.
On Apr 8, 2005 11:58 AM, AsterixTheGaul [EMAIL PROTECTED] wrote:
FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2,
except that neither returns from suspend-to-ram with video restored on
the LCD. I believe I was able
Ok this time I did with radeontool and it works good :)) (2.6.12-rc2 on T41).
1. I have radeontool regs before susp to ram (presusp)
2. turn off LCD with radeontool light off
3. Suspend to RAM and wake up. (same backtrace)
4. LCD is back on (no problem)
5. regs in postsusp
only diff is
On Apr 7, 2005 11:28 PM, AsterixTheGaul [EMAIL PROTECTED] wrote:
FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2,
except that neither returns from suspend-to-ram with video restored on
the LCD. I believe I was able to get video restored on an external CRT
in either
Its a T41 without p :)
On Apr 8, 2005 9:09 PM, Nish Aravamudan [EMAIL PROTECTED] wrote:
On Apr 7, 2005 11:28 PM, AsterixTheGaul [EMAIL PROTECTED] wrote:
FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2,
except that neither returns from suspend-to-ram with video restored
On Apr 7, 2005 3:45 PM, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-04-07 at 11:54 -0700, Nish Aravamudan wrote:
> > On Apr 7, 2005 10:50 AM, Moritz Muehlenhoff <[EMAIL PROTECTED]> wrote:
> > > Benjamin Herrenschmidt wrote:
> > > > > 1. When resuming from S3 suspend and having
On Thu, 2005-04-07 at 11:54 -0700, Nish Aravamudan wrote:
> On Apr 7, 2005 10:50 AM, Moritz Muehlenhoff <[EMAIL PROTECTED]> wrote:
> > Benjamin Herrenschmidt wrote:
> > > > 1. When resuming from S3 suspend and having switched off the backlight
> > > > with radeontool the backlight isn't switched
On Thu, 2005-04-07 at 19:50 +0200, Moritz Muehlenhoff wrote:
> Benjamin Herrenschmidt wrote:
> > > 1. When resuming from S3 suspend and having switched off the backlight
> > > with radeontool the backlight isn't switched back on any more.
> >
> > I'm not sure what's up here, it's a nasty issue
On Apr 7, 2005 10:50 AM, Moritz Muehlenhoff <[EMAIL PROTECTED]> wrote:
> Benjamin Herrenschmidt wrote:
> > > 1. When resuming from S3 suspend and having switched off the backlight
> > > with radeontool the backlight isn't switched back on any more.
> >
> > I'm not sure what's up here, it's a nasty
Benjamin Herrenschmidt wrote:
> > 1. When resuming from S3 suspend and having switched off the backlight
> > with radeontool the backlight isn't switched back on any more.
>
> I'm not sure what's up here, it's a nasty issue with backlight. Can
> radeontool bring it back ?
Before suspending I
Benjamin Herrenschmidt wrote:
1. When resuming from S3 suspend and having switched off the backlight
with radeontool the backlight isn't switched back on any more.
I'm not sure what's up here, it's a nasty issue with backlight. Can
radeontool bring it back ?
Before suspending I power down
On Apr 7, 2005 10:50 AM, Moritz Muehlenhoff [EMAIL PROTECTED] wrote:
Benjamin Herrenschmidt wrote:
1. When resuming from S3 suspend and having switched off the backlight
with radeontool the backlight isn't switched back on any more.
I'm not sure what's up here, it's a nasty issue with
On Thu, 2005-04-07 at 19:50 +0200, Moritz Muehlenhoff wrote:
Benjamin Herrenschmidt wrote:
1. When resuming from S3 suspend and having switched off the backlight
with radeontool the backlight isn't switched back on any more.
I'm not sure what's up here, it's a nasty issue with
On Thu, 2005-04-07 at 11:54 -0700, Nish Aravamudan wrote:
On Apr 7, 2005 10:50 AM, Moritz Muehlenhoff [EMAIL PROTECTED] wrote:
Benjamin Herrenschmidt wrote:
1. When resuming from S3 suspend and having switched off the backlight
with radeontool the backlight isn't switched back on any
On Apr 7, 2005 3:45 PM, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
On Thu, 2005-04-07 at 11:54 -0700, Nish Aravamudan wrote:
On Apr 7, 2005 10:50 AM, Moritz Muehlenhoff [EMAIL PROTECTED] wrote:
Benjamin Herrenschmidt wrote:
1. When resuming from S3 suspend and having switched off
On Wed, Apr 06, 2005 at 05:20:52PM -0600, Bob Gill wrote:
> OK. So far so good. I can get 2.6.12-rc2 to run fine if:
> 1. I do not in any way attempt to *ahem* overclock the box.
> --if I do, I get really ugly race errors flying around from just about
> everywhere (pick a device at random,
OK. So far so good. I can get 2.6.12-rc2 to run fine if:
1. I do not in any way attempt to *ahem* overclock the box.
--if I do, I get really ugly race errors flying around from just about
everywhere (pick a device at random, have it trip, and the scheduler
tripping right behind it).
2. I do not
On Wed, 2005-04-06 at 19:14 +0200, Moritz Muehlenhoff wrote:
> Linus Torvalds wrote:
> > Benjamin Herrenschmidt:
> > o radeonfb: Implement proper workarounds for PLL accesses
> > o radeonfb: DDC i2c fix
> > o radeonfb: Fix mode setting on CRT monitors
> > o radeonfb: Preserve TMDS setting
Linus Torvalds wrote:
> Benjamin Herrenschmidt:
> o radeonfb: Implement proper workarounds for PLL accesses
> o radeonfb: DDC i2c fix
> o radeonfb: Fix mode setting on CRT monitors
> o radeonfb: Preserve TMDS setting
One of these patches introduced two regressions on my Thinkpad X31 with
Linus Torvalds wrote:
Benjamin Herrenschmidt:
o radeonfb: Implement proper workarounds for PLL accesses
o radeonfb: DDC i2c fix
o radeonfb: Fix mode setting on CRT monitors
o radeonfb: Preserve TMDS setting
One of these patches introduced two regressions on my Thinkpad X31 with
ATI
On Wed, 2005-04-06 at 19:14 +0200, Moritz Muehlenhoff wrote:
Linus Torvalds wrote:
Benjamin Herrenschmidt:
o radeonfb: Implement proper workarounds for PLL accesses
o radeonfb: DDC i2c fix
o radeonfb: Fix mode setting on CRT monitors
o radeonfb: Preserve TMDS setting
One of
OK. So far so good. I can get 2.6.12-rc2 to run fine if:
1. I do not in any way attempt to *ahem* overclock the box.
--if I do, I get really ugly race errors flying around from just about
everywhere (pick a device at random, have it trip, and the scheduler
tripping right behind it).
2. I do not
On Wed, Apr 06, 2005 at 05:20:52PM -0600, Bob Gill wrote:
OK. So far so good. I can get 2.6.12-rc2 to run fine if:
1. I do not in any way attempt to *ahem* overclock the box.
--if I do, I get really ugly race errors flying around from just about
everywhere (pick a device at random, have
I have finally added support for a page size greater than 4K for jfs and
the code is now in 2.6.12-rc2-mm1. This will allow jfs to work on
architectures with larger page sizes: alpha, sparc, all configs of ia64,
etc.
I completely replaced the address-space operations for jfs's metadata,
and I
2.6.12-rc2 still does not boot properly on my box.
Hubert Tonneau wrote:
>
> When switching from 2.6.11 to 2.6.12-rc1,
> I get a 'cannot open root device' fatal error at end of kernel boot process.
> Root device is 'hda1'.
>
> Hardware content of the box:
>
> 8086 Intel Corporation 3340
Oleg Nesterov <[EMAIL PROTECTED]> wrote:
>
> > Oleg Nesterov:
> > o x86: fix ESP corruption CPU bug (take 2)
>
> I don't even absolutely understand what this patch does :)
> I only send a very minor fix on top of Stas Sergeev's patch.
>
I'm suspecting a problem in the reporting scripts. The
> Oleg Nesterov:
> o x86: fix ESP corruption CPU bug (take 2)
I don't even absolutely understand what this patch does :)
I only send a very minor fix on top of Stas Sergeev's patch.
Oleg.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
I have finally added support for a page size greater than 4K for jfs and
the code is now in 2.6.12-rc2-mm1. This will allow jfs to work on
architectures with larger page sizes: alpha, sparc, all configs of ia64,
etc.
I completely replaced the address-space operations for jfs's metadata,
and I
Oleg Nesterov:
o x86: fix ESP corruption CPU bug (take 2)
I don't even absolutely understand what this patch does :)
I only send a very minor fix on top of Stas Sergeev's patch.
Oleg.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
Oleg Nesterov [EMAIL PROTECTED] wrote:
Oleg Nesterov:
o x86: fix ESP corruption CPU bug (take 2)
I don't even absolutely understand what this patch does :)
I only send a very minor fix on top of Stas Sergeev's patch.
I'm suspecting a problem in the reporting scripts. The patch had:
2.6.12-rc2 still does not boot properly on my box.
Hubert Tonneau wrote:
When switching from 2.6.11 to 2.6.12-rc1,
I get a 'cannot open root device' fatal error at end of kernel boot process.
Root device is 'hda1'.
Hardware content of the box:
8086 Intel Corporation 3340
On Monday 04 April 2005 17:32, Linus Torvalds wrote:
>The diffstat output tells the story: this is a lot of very small
> changes, ie tons of small cleanups and bug fixes. With a few new
> drivers thrown in for good measure.
>
>This is also the point where I ask people to calm down, and not send
>
On Tue, Apr 05, 2005 at 12:49:55AM +0100, Russell King wrote:
> IOW, when sysdev.h is updated to prototype the function pointer with
> pm_message_t, this'll also be solved.
>
> Therefore, if anything, linux/pm.h should be added to linux/sysdev.h as
> the minimal patch.
OK...
-
To unsubscribe
On Tue, Apr 05, 2005 at 09:37:18AM +1000, Stephen Rothwell wrote:
> On Mon, 4 Apr 2005 14:32:52 -0700 (PDT) Linus Torvalds <[EMAIL PROTECTED]>
> wrote:
> >
> > o missing include in lanai.c
>
> After this patch I have ended up with linux/dma-mapping.h included twice
> in this file ...
Argh.
On Tue, Apr 05, 2005 at 12:24:19AM +0100, Al Viro wrote:
> On Mon, Apr 04, 2005 at 02:32:52PM -0700, Linus Torvalds wrote:
> > This is also the point where I ask people to calm down, and not send me
> > anything but clear bug-fixes etc. We're definitely well into -rc land. So
> > keep it quiet
On Mon, 04 Apr 2005 14:32:52 -0700, Linus Torvalds wrote:
>
>
> The diffstat output tells the story: this is a lot of very small changes,
> ie tons of small cleanups and bug fixes. With a few new drivers thrown in
> for good measure.
>
> This is also the point where I ask people to calm down,
On Mon, 4 Apr 2005 14:32:52 -0700 (PDT) Linus Torvalds <[EMAIL PROTECTED]>
wrote:
>
> o missing include in lanai.c
After this patch I have ended up with linux/dma-mapping.h included twice
in this file ...
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
On Mon, Apr 04, 2005 at 02:32:52PM -0700, Linus Torvalds wrote:
> This is also the point where I ask people to calm down, and not send me
> anything but clear bug-fixes etc. We're definitely well into -rc land. So
> keep it quiet out there,
* missing include in arm/kernel/time.c - see
On Mon, 04 Apr 2005 14:32:52 -0700, Linus Torvalds wrote:
>
>
> The diffstat output tells the story: this is a lot of very small changes,
> ie tons of small cleanups and bug fixes. With a few new drivers thrown in
> for good measure.
>
> This is also the point where I ask people to calm down,
On Mon, 04 Apr 2005 14:32:52 -0700, Linus Torvalds wrote:
[...]
>
>
> Summary of changes from v2.6.12-rc1 to v2.6.12-rc2
> ==
>
[...]
>
> Andres Salomon:
> o Possible AMD8111e free irq issue
> o Possible VIA-Rhine free irq issue
Those
On Mon, 04 Apr 2005 14:32:52 -0700, Linus Torvalds wrote:
[...]
Summary of changes from v2.6.12-rc1 to v2.6.12-rc2
==
[...]
Andres Salomon:
o Possible AMD8111e free irq issue
o Possible VIA-Rhine free irq issue
Those two were
On Mon, 04 Apr 2005 14:32:52 -0700, Linus Torvalds wrote:
The diffstat output tells the story: this is a lot of very small changes,
ie tons of small cleanups and bug fixes. With a few new drivers thrown in
for good measure.
This is also the point where I ask people to calm down, and not
On Mon, Apr 04, 2005 at 02:32:52PM -0700, Linus Torvalds wrote:
This is also the point where I ask people to calm down, and not send me
anything but clear bug-fixes etc. We're definitely well into -rc land. So
keep it quiet out there,
* missing include in arm/kernel/time.c - see
On Mon, 4 Apr 2005 14:32:52 -0700 (PDT) Linus Torvalds [EMAIL PROTECTED]
wrote:
o missing include in lanai.c
After this patch I have ended up with linux/dma-mapping.h included twice
in this file ...
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
On Mon, 04 Apr 2005 14:32:52 -0700, Linus Torvalds wrote:
The diffstat output tells the story: this is a lot of very small changes,
ie tons of small cleanups and bug fixes. With a few new drivers thrown in
for good measure.
This is also the point where I ask people to calm down, and not
On Tue, Apr 05, 2005 at 09:37:18AM +1000, Stephen Rothwell wrote:
On Mon, 4 Apr 2005 14:32:52 -0700 (PDT) Linus Torvalds [EMAIL PROTECTED]
wrote:
o missing include in lanai.c
After this patch I have ended up with linux/dma-mapping.h included twice
in this file ...
Argh. Looks like
On Tue, Apr 05, 2005 at 12:49:55AM +0100, Russell King wrote:
IOW, when sysdev.h is updated to prototype the function pointer with
pm_message_t, this'll also be solved.
Therefore, if anything, linux/pm.h should be added to linux/sysdev.h as
the minimal patch.
OK...
-
To unsubscribe from
On Monday 04 April 2005 17:32, Linus Torvalds wrote:
The diffstat output tells the story: this is a lot of very small
changes, ie tons of small cleanups and bug fixes. With a few new
drivers thrown in for good measure.
This is also the point where I ask people to calm down, and not send
me
73 matches
Mail list logo
