Hi all,
Here is a list of some known regressions in 2.6.22-rc3.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
Suspend
Subject : 2.6.22-rc1 suspend to RAM problem
References : http://permalink.gmane.org/gmane.linux.power-management.general/5819
Submitter : Marcus Better <[email protected]>
Handled-By : Stefan Richter <[email protected]>
Kristian Høgsberg <[email protected]>
Status : caused by fw-ohci module
Timers
Subject : hrtimer overflow bug on 64-bit systems
References : http://lkml.org/lkml/2007/5/24/391
Submitter : David Miller <[email protected]>
Status : problem is being debugged
TTY
Subject : tty-related oops in latest kernel(s)
References : http://lkml.org/lkml/2007/5/27/104
Submitter : Tero Roponen <[email protected]>
Status : problem is being debugged
USB
Subject : usb hotplug/udev cannot correctly register usb/scanners
References : http://lkml.org/lkml/2007/5/15/205
Submitter : [email protected] <[email protected]>
Status : Unknown
Regards,
Michal
--
"Najbardziej brakowało mi twojego milczenia."
-- Andrzej Sapkowski "Coś więcej"
get_next_timer_interrupt() returns a delta of (LONG_MAX > 1) in case
there is no timer pending. On 64 bit machines this results in a
multiplication overflow in tick_nohz_stop_sched_tick().
Reported by: Dave Miller <[email protected]>
Make the return value a constant and limit the return value to a 32 bit
value.
When the max timeout value is returned, we can safely stop the tick
timer device. The max jiffies delta results in a 12 days timeout for
HZ=1000.
In the long term the get_next_timer_interrupt() code needs to be
reworked to return ktime instead of jiffies, but we have to wait until
the last users of the original NO_IDLE_HZ code are converted.
Signed-off-by: Thomas Gleixner <[email protected]>
---
include/linux/timer.h | 6 ++++++
kernel/time/tick-sched.c | 16 +++++++++++++++-
kernel/timer.c | 10 +++++++++-
3 files changed, 30 insertions(+), 2 deletions(-)
Index: linux-2.6.21/include/linux/timer.h
===================================================================
--- linux-2.6.21.orig/include/linux/timer.h 2007-05-29 17:58:04.000000000 +0200
+++ linux-2.6.21/include/linux/timer.h 2007-05-29 17:58:06.000000000 +0200
@@ -68,6 +68,12 @@
extern int mod_timer(struct timer_list *timer, unsigned long expires);
/*
+ * The jiffies value which is added to now, when there is no timer
+ * in the timer wheel:
+ */
+#define NEXT_TIMER_MAX_DELTA ((1UL << 30) - 1)
+
+/*
* Return when the next timer-wheel timeout occurs (in absolute jiffies),
* locks the timer base:
*/
Index: linux-2.6.21/kernel/time/tick-sched.c
===================================================================
--- linux-2.6.21.orig/kernel/time/tick-sched.c 2007-05-29 17:58:04.000000000 +0200
+++ linux-2.6.21/kernel/time/tick-sched.c 2007-05-29 17:58:06.000000000 +0200
@@ -233,6 +233,21 @@
if (cpu == tick_do_timer_cpu)
tick_do_timer_cpu = -1;
+ ts->idle_sleeps++;
+
+ /*
+ * delta_jiffies >= NEXT_TIMER_MAX_DELTA signals that
+ * there is no timer pending or at least extremly far
+ * into the future (12 days for HZ=1000). In this case
+ * we simply stop the tick timer:
+ */
+ if (unlikely(delta_jiffies >= NEXT_TIMER_MAX_DELTA)) {
+ ts->idle_expires.tv64 = KTIME_MAX;
+ if (ts->nohz_mode == NOHZ_MODE_HIGHRES)
+ hrtimer_cancel(&ts->sched_timer);
+ goto out;
+ }
+
/*
* calculate the expiry time for the next timer wheel
* timer
@@ -240,7 +255,6 @@
expires = ktime_add_ns(last_update, tick_period.tv64 *
delta_jiffies);
ts->idle_expires = expires;
- ts->idle_sleeps++;
if (ts->nohz_mode == NOHZ_MODE_HIGHRES) {
hrtimer_start(&ts->sched_timer, expires,
Index: linux-2.6.21/kernel/timer.c
===================================================================
--- linux-2.6.21.orig/kernel/timer.c 2007-05-29 17:58:05.000000000 +0200
+++ linux-2.6.21/kernel/timer.c 2007-05-29 17:58:06.000000000 +0200
@@ -625,7 +625,7 @@
static unsigned long __next_timer_interrupt(tvec_base_t *base)
{
unsigned long timer_jiffies = base->timer_jiffies;
- unsigned long expires = timer_jiffies + (LONG_MAX >> 1);
+ unsigned long expires = timer_jiffies + NEXT_TIMER_MAX_DELTA;
int index, slot, array, found = 0;
struct timer_list *nte;
tvec_t *varray[4];
@@ -708,6 +708,14 @@
tsdelta = ktime_to_timespec(hr_delta);
delta = timespec_to_jiffies(&tsdelta);
+
+ /*
+ * Limit the delta to the max value, which is checked in
+ * tick_nohz_stop_sched_tick():
+ */
+ if (delta > NEXT_TIMER_MAX_DELTA)
+ delta = NEXT_TIMER_MAX_DELTA;
+
/*
* Take rounding errors in to account and make sure, that it
* expires in the next tick. Otherwise we go into an endless
From: Thomas Gleixner <[email protected]>
Date: Tue, 29 May 2007 23:47:39 +0200
> get_next_timer_interrupt() returns a delta of (LONG_MAX > 1) in case
> there is no timer pending. On 64 bit machines this results in a
> multiplication overflow in tick_nohz_stop_sched_tick().
>
> Reported by: Dave Miller <[email protected]>
>
> Make the return value a constant and limit the return value to a 32 bit
> value.
>
> When the max timeout value is returned, we can safely stop the tick
> timer device. The max jiffies delta results in a 12 days timeout for
> HZ=1000.
>
> In the long term the get_next_timer_interrupt() code needs to be
> reworked to return ktime instead of jiffies, but we have to wait until
> the last users of the original NO_IDLE_HZ code are converted.
>
> Signed-off-by: Thomas Gleixner <[email protected]>
Acked-off-by: David S. Miller <[email protected]>
On Tue, 29 May 2007, Michal Piotrowski wrote:
>
> Subject : hrtimer overflow bug on 64-bit systems
> References : http://lkml.org/lkml/2007/5/24/391
> Submitter : David Miller <[email protected]>
> Status : problem is being debugged
Should be fixed by commit eaad084bb.
> TTY
>
> Subject : tty-related oops in latest kernel(s)
> References : http://lkml.org/lkml/2007/5/27/104
> Submitter : Tero Roponen <[email protected]>
> Status : problem is being debugged
People seem to have debugged this to neofb palette handling, but I haven't
seen a patch. Antonino?
Linus
On Wed, 2007-05-30 at 19:33 -0700, Linus Torvalds wrote:
>
> On Tue, 29 May 2007, Michal Piotrowski wrote:
> >
> > TTY
> >
> > Subject : tty-related oops in latest kernel(s)
> > References : http://lkml.org/lkml/2007/5/27/104
> > Submitter : Tero Roponen <[email protected]>
> > Status : problem is being debugged
>
> People seem to have debugged this to neofb palette handling, but I haven't
> seen a patch. Antonino?
>
Already posted one for testing. I'm waiting for Tero to confirm.
Tony
On Thu, 31 May 2007, Antonino A. Daplas wrote:
> On Wed, 2007-05-30 at 19:33 -0700, Linus Torvalds wrote:
> >
> > On Tue, 29 May 2007, Michal Piotrowski wrote:
> > >
>
> > > TTY
> > >
> > > Subject : tty-related oops in latest kernel(s)
> > > References : http://lkml.org/lkml/2007/5/27/104
> > > Submitter : Tero Roponen <[email protected]>
> > > Status : problem is being debugged
> >
> > People seem to have debugged this to neofb palette handling, but I haven't
> > seen a patch. Antonino?
> >
>
> Already posted one for testing. I'm waiting for Tero to confirm.
>
> Tony
>
Ok, I tested all the cases I have reported: no corruption
and nothing in slabinfo -v. This seems to be the right fix.
Thanks.
Acked-by: Tero Roponen <[email protected]>
The pseudo_palette has room for 16 entries only, but in truecolor mode, it
attempts to write 256.
Signed-off-by: Antonino Daplas <[email protected]>
Acked-by: Tero Roponen <[email protected]>
---
Tero Roponen wrote:
> On Thu, 31 May 2007, Antonino A. Daplas wrote:
>
>> On Wed, 2007-05-30 at 19:33 -0700, Linus Torvalds wrote:
>>> On Tue, 29 May 2007, Michal Piotrowski wrote:
>>>> TTY
>>>>
>>>> Subject : tty-related oops in latest kernel(s)
>>>> References : http://lkml.org/lkml/2007/5/27/104
>>>> Submitter : Tero Roponen <[email protected]>
>>>> Status : problem is being debugged
>>> People seem to have debugged this to neofb palette handling, but I haven't
>>> seen a patch. Antonino?
>>>
>> Already posted one for testing. I'm waiting for Tero to confirm.
>>
>> Tony
>>
>
> Ok, I tested all the cases I have reported: no corruption
> and nothing in slabinfo -v. This seems to be the right fix.
>
Okay, thanks for testing.
Tony
drivers/video/neofb.c | 30 ++++++++++++++++--------------
1 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/drivers/video/neofb.c b/drivers/video/neofb.c
index bd30aba..731d7a5 100644
--- a/drivers/video/neofb.c
+++ b/drivers/video/neofb.c
@@ -1286,34 +1286,36 @@ static int neofb_setcolreg(u_int regno,
if (regno >= fb->cmap.len || regno > 255)
return -EINVAL;
- switch (fb->var.bits_per_pixel) {
- case 8:
+ if (fb->var.bits_per_pixel <= 8) {
outb(regno, 0x3c8);
outb(red >> 10, 0x3c9);
outb(green >> 10, 0x3c9);
outb(blue >> 10, 0x3c9);
- break;
- case 16:
- ((u32 *) fb->pseudo_palette)[regno] =
+ } else if (regno < 16) {
+ switch (fb->var.bits_per_pixel) {
+ case 16:
+ ((u32 *) fb->pseudo_palette)[regno] =
((red & 0xf800)) | ((green & 0xfc00) >> 5) |
((blue & 0xf800) >> 11);
- break;
- case 24:
- ((u32 *) fb->pseudo_palette)[regno] =
+ break;
+ case 24:
+ ((u32 *) fb->pseudo_palette)[regno] =
((red & 0xff00) << 8) | ((green & 0xff00)) |
((blue & 0xff00) >> 8);
- break;
+ break;
#ifdef NO_32BIT_SUPPORT_YET
- case 32:
- ((u32 *) fb->pseudo_palette)[regno] =
+ case 32:
+ ((u32 *) fb->pseudo_palette)[regno] =
((transp & 0xff00) << 16) | ((red & 0xff00) << 8) |
((green & 0xff00)) | ((blue & 0xff00) >> 8);
- break;
+ break;
#endif
- default:
- return 1;
+ default:
+ return 1;
+ }
}
+
return 0;
}
The pseudo_palette has room for 16 entries only, but in truecolor mode, it
attempts to write 256.
Signed-off-by: Antonino Daplas <[email protected]>
Acked-by: Tero Roponen <[email protected]>
---
This fixes the following regression/bug reported as follows:
Subject : tty-related oops in latest kernel(s)
References : http://lkml.org/lkml/2007/5/27/104
Submitter : Tero Roponen <[email protected]>
Status : problem is being debugged
According to Tero, this is also reproducible with 2.6.21.3.
Tony
drivers/video/neofb.c | 30 ++++++++++++++++--------------
1 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/drivers/video/neofb.c b/drivers/video/neofb.c
index bd30aba..731d7a5 100644
--- a/drivers/video/neofb.c
+++ b/drivers/video/neofb.c
@@ -1286,34 +1286,36 @@ static int neofb_setcolreg(u_int regno,
if (regno >= fb->cmap.len || regno > 255)
return -EINVAL;
- switch (fb->var.bits_per_pixel) {
- case 8:
+ if (fb->var.bits_per_pixel <= 8) {
outb(regno, 0x3c8);
outb(red >> 10, 0x3c9);
outb(green >> 10, 0x3c9);
outb(blue >> 10, 0x3c9);
- break;
- case 16:
- ((u32 *) fb->pseudo_palette)[regno] =
+ } else if (regno < 16) {
+ switch (fb->var.bits_per_pixel) {
+ case 16:
+ ((u32 *) fb->pseudo_palette)[regno] =
((red & 0xf800)) | ((green & 0xfc00) >> 5) |
((blue & 0xf800) >> 11);
- break;
- case 24:
- ((u32 *) fb->pseudo_palette)[regno] =
+ break;
+ case 24:
+ ((u32 *) fb->pseudo_palette)[regno] =
((red & 0xff00) << 8) | ((green & 0xff00)) |
((blue & 0xff00) >> 8);
- break;
+ break;
#ifdef NO_32BIT_SUPPORT_YET
- case 32:
- ((u32 *) fb->pseudo_palette)[regno] =
+ case 32:
+ ((u32 *) fb->pseudo_palette)[regno] =
((transp & 0xff00) << 16) | ((red & 0xff00) << 8) |
((green & 0xff00)) | ((blue & 0xff00) >> 8);
- break;
+ break;
#endif
- default:
- return 1;
+ default:
+ return 1;
+ }
}
+
return 0;
}
The pseudo_palette has room for 16 entries only, but in truecolor mode, it
attempts to write 256.
Signed-off-by: Antonino Daplas <[email protected]>
Acked-by: Tero Roponen <[email protected]>
---
This fixes the following regression/bug reported as follows:
Subject : tty-related oops in latest kernel(s)
References : http://lkml.org/lkml/2007/5/27/104
Submitter : Tero Roponen <[email protected]>
Status : problem is being debugged
According to Tero, this is also reproducible with 2.6.21.3.
(Resending, wrong email address for [email protected])
Tony
drivers/video/neofb.c | 30 ++++++++++++++++--------------
1 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/drivers/video/neofb.c b/drivers/video/neofb.c
index bd30aba..731d7a5 100644
--- a/drivers/video/neofb.c
+++ b/drivers/video/neofb.c
@@ -1286,34 +1286,36 @@ static int neofb_setcolreg(u_int regno,
if (regno >= fb->cmap.len || regno > 255)
return -EINVAL;
- switch (fb->var.bits_per_pixel) {
- case 8:
+ if (fb->var.bits_per_pixel <= 8) {
outb(regno, 0x3c8);
outb(red >> 10, 0x3c9);
outb(green >> 10, 0x3c9);
outb(blue >> 10, 0x3c9);
- break;
- case 16:
- ((u32 *) fb->pseudo_palette)[regno] =
+ } else if (regno < 16) {
+ switch (fb->var.bits_per_pixel) {
+ case 16:
+ ((u32 *) fb->pseudo_palette)[regno] =
((red & 0xf800)) | ((green & 0xfc00) >> 5) |
((blue & 0xf800) >> 11);
- break;
- case 24:
- ((u32 *) fb->pseudo_palette)[regno] =
+ break;
+ case 24:
+ ((u32 *) fb->pseudo_palette)[regno] =
((red & 0xff00) << 8) | ((green & 0xff00)) |
((blue & 0xff00) >> 8);
- break;
+ break;
#ifdef NO_32BIT_SUPPORT_YET
- case 32:
- ((u32 *) fb->pseudo_palette)[regno] =
+ case 32:
+ ((u32 *) fb->pseudo_palette)[regno] =
((transp & 0xff00) << 16) | ((red & 0xff00) << 8) |
((green & 0xff00)) | ((blue & 0xff00) >> 8);
- break;
+ break;
#endif
- default:
- return 1;
+ default:
+ return 1;
+ }
}
+
return 0;
}