Patch set to sync up some Ubuntu patches.
Git tree: git://kernel.ubuntu.com/bcollins/ubuntu-for-upstream
From: Ben Collins <[email protected]>
Date: Wed, 23 May 2007 18:30:46 -0400
> This work around has been in use by almost any distribution trying to
> support sparc64 since at least 2002. Without it, sunhme hangs fairly
> quickly on UltraSPARC 1's.
>
> Dave, I know it's not in the kernel because it isn't a "fix", but given
> that we haven't seen a fix in more than 5 years, can we get this out of my
> tree please? :)
It isn't needed any more, the hang no longer occurs.
Nobody should be applying that patch, my guess is that it was
a GCC bug that has been fixed over time that reordered the
writes to RX/TX descriptors which hung the chip.
Various unusual dev entries accumulated from Ubuntu bug reports.
CC: Phil Dibowitz <[email protected]>
CC: Alan Stern <[email protected]>
CC: [email protected]
Signed-off-by: Ben Collins <[email protected]>
---
drivers/usb/storage/unusual_devs.h | 21 +++++++++++++++++++--
1 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/storage/unusual_devs.h b/drivers/usb/storage/unusual_devs.h
index d230ee7..8a24f1c 100644
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -1179,8 +1179,8 @@ UNUSUAL_DEV( 0x0a17, 0x006, 0x0000, 0xffff,
US_SC_DEVICE, US_PR_DEVICE, NULL,
US_FL_FIX_INQUIRY ),
-/* These are virtual windows driver CDs, which the zd1211rw driver automatically
- * converts into a WLAN devices. */
+/* These are virtual windows driver CDs, which the zd1211rw driver
+ * automatically converts into WLAN devices. */
UNUSUAL_DEV( 0x0ace, 0x2011, 0x0101, 0x0101,
"ZyXEL",
"G-220F USB-WLAN Install",
@@ -1193,6 +1193,14 @@ UNUSUAL_DEV( 0x0ace, 0x20ff, 0x0101, 0x0101,
US_SC_DEVICE, US_PR_DEVICE, NULL,
US_FL_IGNORE_DEVICE ),
+/* SanDisk that has a second LUN for a driver ISO, reported by
+ * Ben Collins <[email protected]> */
+UNUSUAL_DEV( 0x0781, 0x5406, 0x0000, 0xffff,
+ "SanDisk",
+ "U3 Cruzer Micro driver ISO",
+ US_SC_DEVICE, US_PR_DEVICE, NULL,
+ US_FL_SINGLE_LUN ),
+
#ifdef CONFIG_USB_STORAGE_ISD200
UNUSUAL_DEV( 0x0bf6, 0xa001, 0x0100, 0x0110,
"ATI",
@@ -1271,6 +1279,15 @@ UNUSUAL_DEV( 0x0dd8, 0x1060, 0x0000, 0xffff,
US_SC_DEVICE, US_PR_DEVICE, NULL,
US_FL_FIX_INQUIRY ),
+/* Reported by Edward Chapman <[EMAIL PROTECTED]>
+ Netac OnlyDisk Mini U2CV2 512MB USB 2.0 Flash Drive */
+UNUSUAL_DEV( 0x0dd8, 0xd202, 0x0000, 0x9999,
+ "Netac",
+ "USB Flash Disk",
+ US_SC_DEVICE, US_PR_DEVICE, NULL,
+ US_FL_IGNORE_RESIDUE ),
+
+
/* Patch by Stephan Walter <[email protected]>
* I don't know why, but it works... */
UNUSUAL_DEV( 0x0dda, 0x0001, 0x0012, 0x0012,
--
1.5.1.4
Signed-off-by: Ben Collins <[email protected]>
---
arch/i386/Kconfig.debug | 6 ++++++
arch/i386/boot/compressed/misc.c | 8 +++++---
arch/x86_64/Kconfig.debug | 6 ++++++
arch/x86_64/boot/compressed/misc.c | 8 +++++---
4 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/arch/i386/Kconfig.debug b/arch/i386/Kconfig.debug
index b31c080..eb26441 100644
--- a/arch/i386/Kconfig.debug
+++ b/arch/i386/Kconfig.debug
@@ -19,6 +19,12 @@ config EARLY_PRINTK
with klogd/syslogd or the X server. You should normally N here,
unless you want to debug such a crash.
+config WRAPPER_PRINT
+ bool "Boot wrapper print" if EMBEDDED
+ default y
+ help
+ Enable informational output from the bootwrapper (bzImage and zImage).
+
config DEBUG_STACKOVERFLOW
bool "Check for stack overflows"
depends on DEBUG_KERNEL
diff --git a/arch/i386/boot/compressed/misc.c b/arch/i386/boot/compressed/misc.c
index b28505c..cc630d5 100644
--- a/arch/i386/boot/compressed/misc.c
+++ b/arch/i386/boot/compressed/misc.c
@@ -184,8 +184,6 @@ static void free(void *where);
static void *memset(void *s, int c, unsigned n);
static void *memcpy(void *dest, const void *src, unsigned n);
-static void putstr(const char *);
-
static unsigned long free_mem_ptr;
static unsigned long free_mem_end_ptr;
@@ -232,7 +230,8 @@ static void gzip_release(void **ptr)
{
free_mem_ptr = (unsigned long) *ptr;
}
-
+
+#ifdef CONFIG_WRAPPER_PRINT
static void scroll(void)
{
int i;
@@ -278,6 +277,9 @@ static void putstr(const char *s)
outb_p(15, vidport);
outb_p(0xff & (pos >> 1), vidport+1);
}
+#else
+#define putstr(__x) do{}while(0)
+#endif /* CONFIG_WRAPPER_PRINT */
static void* memset(void* s, int c, unsigned n)
{
diff --git a/arch/x86_64/Kconfig.debug b/arch/x86_64/Kconfig.debug
index 775d211..a1b87b8 100644
--- a/arch/x86_64/Kconfig.debug
+++ b/arch/x86_64/Kconfig.debug
@@ -6,6 +6,12 @@ config TRACE_IRQFLAGS_SUPPORT
source "lib/Kconfig.debug"
+config WRAPPER_PRINT
+ bool "Boot wrapper print" if EMBEDDED
+ default y
+ help
+ Enable informational output from the bootwrapper (bzImage and zImage).
+
config DEBUG_RODATA
bool "Write protect kernel read-only data structures"
depends on DEBUG_KERNEL
diff --git a/arch/x86_64/boot/compressed/misc.c b/arch/x86_64/boot/compressed/misc.c
index f932b0e..43bb44c 100644
--- a/arch/x86_64/boot/compressed/misc.c
+++ b/arch/x86_64/boot/compressed/misc.c
@@ -184,8 +184,6 @@ static void free(void *where);
static void *memset(void *s, int c, unsigned n);
static void *memcpy(void *dest, const void *src, unsigned n);
-static void putstr(const char *);
-
static long free_mem_ptr;
static long free_mem_end_ptr;
@@ -228,7 +226,8 @@ static void gzip_release(void **ptr)
{
free_mem_ptr = (long) *ptr;
}
-
+
+#ifdef CONFIG_WRAPPER_PRINT
static void scroll(void)
{
int i;
@@ -274,6 +273,9 @@ static void putstr(const char *s)
outb_p(15, vidport);
outb_p(0xff & (pos >> 1), vidport+1);
}
+#else
+#define putstr(__x) do{}while(0)
+#endif /* CONFIG_WRAPPER_PRINT */
static void* memset(void* s, int c, unsigned n)
{
--
1.5.1.4
CC: Marcel Holtmann <[email protected]>
CC: Maxim Krasnyansky <[email protected]>
Signed-off-by: Tim Gardner <[email protected]>
Signed-off-by: Phillip lougher <[email protected]>
Signed-off-by: Ben Collins <[email protected]>
---
drivers/bluetooth/hci_usb.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/bluetooth/hci_usb.c b/drivers/bluetooth/hci_usb.c
index b0238b4..d636142 100644
--- a/drivers/bluetooth/hci_usb.c
+++ b/drivers/bluetooth/hci_usb.c
@@ -131,7 +131,7 @@ static struct usb_device_id blacklist_ids[] = {
{ USB_DEVICE(0x03f0, 0x171d), .driver_info = HCI_WRONG_SCO_MTU },
/* Dell laptop with Broadcom chip */
- { USB_DEVICE(0x413c, 0x8126), .driver_info = HCI_WRONG_SCO_MTU },
+ { USB_DEVICE(0x413c, 0x8126), .driver_info = HCI_WRONG_SCO_MTU|HCI_RESET },
/* Microsoft Wireless Transceiver for Bluetooth 2.0 */
{ USB_DEVICE(0x045e, 0x009c), .driver_info = HCI_RESET },
--
1.5.1.4
Signed-off-by: Ben Collins <[email protected]>
---
drivers/char/rtc.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/char/rtc.c b/drivers/char/rtc.c
index 20380a2..22cf7aa 100644
--- a/drivers/char/rtc.c
+++ b/drivers/char/rtc.c
@@ -1159,7 +1159,8 @@ static void rtc_dropped_irq(unsigned long data)
spin_unlock_irq(&rtc_lock);
- printk(KERN_WARNING "rtc: lost some interrupts at %ldHz.\n", freq);
+ if (printk_ratelimit())
+ printk(KERN_WARNING "rtc: lost some interrupts at %ldHz.\n", freq);
/* Now we have new data */
wake_up_interruptible(&rtc_wait);
--
1.5.1.4
On Wed, 2007-05-23 at 17:17 -0700, David Miller wrote:
> From: Ben Collins <[email protected]>
> Date: Wed, 23 May 2007 18:30:46 -0400
>
> > This work around has been in use by almost any distribution trying to
> > support sparc64 since at least 2002. Without it, sunhme hangs fairly
> > quickly on UltraSPARC 1's.
> >
> > Dave, I know it's not in the kernel because it isn't a "fix", but given
> > that we haven't seen a fix in more than 5 years, can we get this out of my
> > tree please? :)
>
> It isn't needed any more, the hang no longer occurs.
>
> Nobody should be applying that patch, my guess is that it was
> a GCC bug that has been fixed over time that reordered the
> writes to RX/TX descriptors which hung the chip.
Ah, thanks. I'll revert it out. Seemed like every time I yanked it out
of the our tree (Debian/Ubuntu) some one would complain, and I had to
put it back in.
--
Ubuntu : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/
This work around has been in use by almost any distribution trying to
support sparc64 since at least 2002. Without it, sunhme hangs fairly
quickly on UltraSPARC 1's.
Dave, I know it's not in the kernel because it isn't a "fix", but given
that we haven't seen a fix in more than 5 years, can we get this out of my
tree please? :)
CC: David S. Miller <[email protected]>
Signed-off-by: Ben Collins <[email protected]>
---
drivers/net/sunhme.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/sunhme.c b/drivers/net/sunhme.c
index 51c3fe2..5753298 100644
--- a/drivers/net/sunhme.c
+++ b/drivers/net/sunhme.c
@@ -1969,6 +1969,7 @@ static void happy_meal_tx(struct happy_meal *hp)
}
hp->tx_old = elem;
TXD((">"));
+ udelay(1);
if (netif_queue_stopped(dev) &&
TX_BUFFS_AVAIL(hp) > (MAX_SKB_FRAGS + 1))
--
1.5.1.4
In order to enable things like PM_TRACE, you're required to enable
PM_DEBUG, which sends a large spew of messages on boot, and often times
can overflow dmesg buffer.
Create new PM_VERBOSE and shift that to be the option that enables
drivers/base/power's messages.
Signed-off-by: Ben Collins <[email protected]>
---
drivers/base/power/Makefile | 2 +-
kernel/power/Kconfig | 17 ++++++++++++-----
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/base/power/Makefile b/drivers/base/power/Makefile
index 91f2309..704d326 100644
--- a/drivers/base/power/Makefile
+++ b/drivers/base/power/Makefile
@@ -5,6 +5,6 @@ obj-$(CONFIG_PM_TRACE) += trace.o
ifeq ($(CONFIG_DEBUG_DRIVER),y)
EXTRA_CFLAGS += -DDEBUG
endif
-ifeq ($(CONFIG_PM_DEBUG),y)
+ifeq ($(CONFIG_PM_VERBOSE),y)
EXTRA_CFLAGS += -DDEBUG
endif
diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index 495b7d4..1f8cdbd 100644
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -33,13 +33,20 @@ config PM_DEBUG
bool "Power Management Debug Support"
depends on PM
---help---
- This option enables verbose debugging support in the Power Management
- code. This is helpful when debugging and reporting various PM bugs,
- like suspend support.
+ This option enables various debugging support in the Power Management
+ code. This is helpful when debugging and reporting PM bugs, like
+ suspend support.
+
+config PM_VERBOSE
+ bool "Verbose Power Management debugging"
+ depends on PM_DEBUG
+ default n
+ ---help---
+ This option enables verbose messages from the Power Management code.
config DISABLE_CONSOLE_SUSPEND
bool "Keep console(s) enabled during suspend/resume (DANGEROUS)"
- depends on PM && PM_DEBUG
+ depends on PM_DEBUG
default n
---help---
This option turns off the console suspend mechanism that prevents
@@ -50,7 +57,7 @@ config DISABLE_CONSOLE_SUSPEND
config PM_TRACE
bool "Suspend/resume event tracing"
- depends on PM && PM_DEBUG && X86_32 && EXPERIMENTAL
+ depends on PM_DEBUG && X86_32 && EXPERIMENTAL
default n
---help---
This enables some cheesy code to save the last PM event point in the
--
1.5.1.4
On Wed, 23 May 2007 17:59:10 -0400 Ben Collins wrote:
> diff --git a/arch/i386/boot/compressed/misc.c b/arch/i386/boot/compressed/misc.c
> index b28505c..cc630d5 100644
> --- a/arch/i386/boot/compressed/misc.c
> +++ b/arch/i386/boot/compressed/misc.c
> @@ -278,6 +277,9 @@ static void putstr(const char *s)
> outb_p(15, vidport);
> outb_p(0xff & (pos >> 1), vidport+1);
> }
> +#else
> +#define putstr(__x) do{}while(0)
Please find the spacebar:
#define putstr(__x) do {} while (0)
> +#endif /* CONFIG_WRAPPER_PRINT */
>
> static void* memset(void* s, int c, unsigned n)
> {
> diff --git a/arch/x86_64/boot/compressed/misc.c b/arch/x86_64/boot/compressed/misc.c
> index f932b0e..43bb44c 100644
> --- a/arch/x86_64/boot/compressed/misc.c
> +++ b/arch/x86_64/boot/compressed/misc.c
> @@ -274,6 +273,9 @@ static void putstr(const char *s)
> outb_p(15, vidport);
> outb_p(0xff & (pos >> 1), vidport+1);
> }
> +#else
> +#define putstr(__x) do{}while(0)
ditto.
> +#endif /* CONFIG_WRAPPER_PRINT */
>
> static void* memset(void* s, int c, unsigned n)
> {
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On Wed, 2007-05-23 at 20:59 -0700, Phil Dibowitz wrote:
> Ben Collins wrote:
> > Various unusual dev entries accumulated from Ubuntu bug reports.
> >
> > CC: Phil Dibowitz <[email protected]>
>
> NACK. Two fixes I'd like to see fixed.
>
> > +/* SanDisk that has a second LUN for a driver ISO, reported by
> > + * Ben Collins <[email protected]> */
> > +UNUSUAL_DEV( 0x0781, 0x5406, 0x0000, 0xffff,
>
> Please use specific device IDs unless you have reason to believe the range
> as a whole is affected (or large portions at least)
Unfortunately, I don't have this device anymore. I based it on an
existing entry, so mislead myself there.
> > +/* Reported by Edward Chapman <[EMAIL PROTECTED]>
> > + Netac OnlyDisk Mini U2CV2 512MB USB 2.0 Flash Drive */
> > +UNUSUAL_DEV( 0x0dd8, 0xd202, 0x0000, 0x9999,
>
> Same here.
This one I snatched off a mailing list archive somewhere. Was reported
to fix a bug reported to us. However, it is so old I can't find any
information on the bug submitters original USB ids.
--
Ubuntu : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/
Ben Collins wrote:
> Various unusual dev entries accumulated from Ubuntu bug reports.
>
> CC: Phil Dibowitz <[email protected]>
NACK. Two fixes I'd like to see fixed.
> +/* SanDisk that has a second LUN for a driver ISO, reported by
> + * Ben Collins <[email protected]> */
> +UNUSUAL_DEV( 0x0781, 0x5406, 0x0000, 0xffff,
Please use specific device IDs unless you have reason to believe the range
as a whole is affected (or large portions at least)
> +/* Reported by Edward Chapman <[EMAIL PROTECTED]>
> + Netac OnlyDisk Mini U2CV2 512MB USB 2.0 Flash Drive */
> +UNUSUAL_DEV( 0x0dd8, 0xd202, 0x0000, 0x9999,
Same here.
Thanks.
--
Phil Dibowitz [email protected]
Open Source software and tech docs Insanity Palace of Metallica
http://www.phildev.net/ http://www.ipom.com/
"Never write it in C if you can do it in 'awk';
Never do it in 'awk' if 'sed' can handle it;
Never use 'sed' when 'tr' can do the job;
Never invoke 'tr' when 'cat' is sufficient;
Avoid using 'cat' whenever possible" -- Taylor's Laws of Programming
Ben Collins wrote:
> This work around has been in use by almost any distribution trying to
> support sparc64 since at least 2002. Without it, sunhme hangs fairly
> quickly on UltraSPARC 1's.
>
> Dave, I know it's not in the kernel because it isn't a "fix", but given
> that we haven't seen a fix in more than 5 years, can we get this out of my
> tree please? :)
Are you sure it is still needed? Gentoo dropped this a few months ago
and have no regression reports.
http://www.mail-archive.com/[email protected]/msg00418.html
Daniel
Hi Ben,
> CC: Marcel Holtmann <[email protected]>
> CC: Maxim Krasnyansky <[email protected]>
> Signed-off-by: Tim Gardner <[email protected]>
> Signed-off-by: Phillip lougher <[email protected]>
> Signed-off-by: Ben Collins <[email protected]>
> ---
> drivers/bluetooth/hci_usb.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/bluetooth/hci_usb.c b/drivers/bluetooth/hci_usb.c
> index b0238b4..d636142 100644
> --- a/drivers/bluetooth/hci_usb.c
> +++ b/drivers/bluetooth/hci_usb.c
> @@ -131,7 +131,7 @@ static struct usb_device_id blacklist_ids[] = {
> { USB_DEVICE(0x03f0, 0x171d), .driver_info = HCI_WRONG_SCO_MTU },
>
> /* Dell laptop with Broadcom chip */
> - { USB_DEVICE(0x413c, 0x8126), .driver_info = HCI_WRONG_SCO_MTU },
> + { USB_DEVICE(0x413c, 0x8126), .driver_info = HCI_WRONG_SCO_MTU|HCI_RESET },
>
> /* Microsoft Wireless Transceiver for Bluetooth 2.0 */
> { USB_DEVICE(0x045e, 0x009c), .driver_info = HCI_RESET },
it is already in my tree.
Regards
Marcel
On Thu, 2007-05-24 at 19:02 +0200, Marcel Holtmann wrote:
> Hi Ben,
>
> > CC: Marcel Holtmann <[email protected]>
> > CC: Maxim Krasnyansky <[email protected]>
> > Signed-off-by: Tim Gardner <[email protected]>
> > Signed-off-by: Phillip lougher <[email protected]>
> > Signed-off-by: Ben Collins <[email protected]>
> > ---
> > drivers/bluetooth/hci_usb.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/bluetooth/hci_usb.c b/drivers/bluetooth/hci_usb.c
> > index b0238b4..d636142 100644
> > --- a/drivers/bluetooth/hci_usb.c
> > +++ b/drivers/bluetooth/hci_usb.c
> > @@ -131,7 +131,7 @@ static struct usb_device_id blacklist_ids[] = {
> > { USB_DEVICE(0x03f0, 0x171d), .driver_info = HCI_WRONG_SCO_MTU },
> >
> > /* Dell laptop with Broadcom chip */
> > - { USB_DEVICE(0x413c, 0x8126), .driver_info = HCI_WRONG_SCO_MTU },
> > + { USB_DEVICE(0x413c, 0x8126), .driver_info = HCI_WRONG_SCO_MTU|HCI_RESET },
> >
> > /* Microsoft Wireless Transceiver for Bluetooth 2.0 */
> > { USB_DEVICE(0x045e, 0x009c), .driver_info = HCI_RESET },
>
> it is already in my tree.
>
> Regards
Great, thanks Marcel.
--
Ubuntu : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/
On Wed, 23 May 2007 17:59:10 -0400
Ben Collins <[email protected]> wrote:
> Updated to include proper spacing for putstr() macro.
>
> Signed-off-by: Ben Collins <[email protected]>
> ---
> arch/i386/Kconfig.debug | 6 ++++++
> arch/i386/boot/compressed/misc.c | 8 +++++---
> arch/x86_64/Kconfig.debug | 6 ++++++
> arch/x86_64/boot/compressed/misc.c | 8 +++++---
> 4 files changed, 22 insertions(+), 6 deletions(-)
>
> diff --git a/arch/i386/Kconfig.debug b/arch/i386/Kconfig.debug
> --- a/arch/i386/Kconfig.debug
> +++ b/arch/i386/Kconfig.debug
> @@ -19,6 +19,12 @@ config EARLY_PRINTK
> with klogd/syslogd or the X server. You should normally N here,
> unless you want to debug such a crash.
>
> +config WRAPPER_PRINT
> + bool "Boot wrapper print" if EMBEDDED
> + default y
> + help
> + Enable informational output from the bootwrapper (bzImage and zImage).
> +
What is the reason for making this change to the kernel?
On Wed, 23 May 2007 18:23:06 -0400
Ben Collins <[email protected]> wrote:
> Signed-off-by: Ben Collins <[email protected]>
> ---
> drivers/char/rtc.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/char/rtc.c b/drivers/char/rtc.c
> index 20380a2..22cf7aa 100644
> --- a/drivers/char/rtc.c
> +++ b/drivers/char/rtc.c
> @@ -1159,7 +1159,8 @@ static void rtc_dropped_irq(unsigned long data)
>
> spin_unlock_irq(&rtc_lock);
>
> - printk(KERN_WARNING "rtc: lost some interrupts at %ldHz.\n", freq);
> + if (printk_ratelimit())
> + printk(KERN_WARNING "rtc: lost some interrupts at %ldHz.\n", freq);
>
Presumably someone is getting a lot of these messages.
Do we know why? Is there something which needs fixing here?
On Thu, 2007-05-24 at 13:48 -0700, Andrew Morton wrote:
> On Wed, 23 May 2007 18:23:06 -0400
> Ben Collins <[email protected]> wrote:
>
> > Signed-off-by: Ben Collins <[email protected]>
> > ---
> > drivers/char/rtc.c | 3 ++-
> > 1 files changed, 2 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/char/rtc.c b/drivers/char/rtc.c
> > index 20380a2..22cf7aa 100644
> > --- a/drivers/char/rtc.c
> > +++ b/drivers/char/rtc.c
> > @@ -1159,7 +1159,8 @@ static void rtc_dropped_irq(unsigned long data)
> >
> > spin_unlock_irq(&rtc_lock);
> >
> > - printk(KERN_WARNING "rtc: lost some interrupts at %ldHz.\n", freq);
> > + if (printk_ratelimit())
> > + printk(KERN_WARNING "rtc: lost some interrupts at %ldHz.\n", freq);
> >
>
> Presumably someone is getting a lot of these messages.
>
> Do we know why? Is there something which needs fixing here?
I got it a lot when using any sort of virtualization on my Core2Duo
(kvm, vmware, qemu). Just a big spew. Honestly, I was getting this with
2.6.20, and haven't tested again with latest kernel.
--
Ubuntu : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/
On Thu, 24 May 2007 16:56:52 -0400
Ben Collins <[email protected]> wrote:
> On Thu, 2007-05-24 at 13:48 -0700, Andrew Morton wrote:
> > On Wed, 23 May 2007 18:23:06 -0400
> > Ben Collins <[email protected]> wrote:
> >
> > > Signed-off-by: Ben Collins <[email protected]>
> > > ---
> > > drivers/char/rtc.c | 3 ++-
> > > 1 files changed, 2 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/drivers/char/rtc.c b/drivers/char/rtc.c
> > > index 20380a2..22cf7aa 100644
> > > --- a/drivers/char/rtc.c
> > > +++ b/drivers/char/rtc.c
> > > @@ -1159,7 +1159,8 @@ static void rtc_dropped_irq(unsigned long data)
> > >
> > > spin_unlock_irq(&rtc_lock);
> > >
> > > - printk(KERN_WARNING "rtc: lost some interrupts at %ldHz.\n", freq);
> > > + if (printk_ratelimit())
> > > + printk(KERN_WARNING "rtc: lost some interrupts at %ldHz.\n", freq);
> > >
> >
> > Presumably someone is getting a lot of these messages.
> >
> > Do we know why? Is there something which needs fixing here?
>
> I got it a lot when using any sort of virtualization on my Core2Duo
> (kvm, vmware, qemu). Just a big spew. Honestly, I was getting this with
> 2.6.20, and haven't tested again with latest kernel.
OK, a bit of googling finds things like this:
http://chxo.com/be2/20060821_3333.html, so I assume that it's some sort of
generic problem with the hypervisor's emulation of the RTC.
Zach, do you know what the score is here?
Thanks.
> > I got it a lot when using any sort of virtualization on my Core2Duo
> > (kvm, vmware, qemu). Just a big spew. Honestly, I was getting this with
> > 2.6.20, and haven't tested again with latest kernel.
>
> OK, a bit of googling finds things like this:
> http://chxo.com/be2/20060821_3333.html, so I assume that it's some sort of
> generic problem with the hypervisor's emulation of the RTC.
Actually I saw this "lost interrupts" spew on the host (ie the
non-virtualized kernel) running just plain qemu (no kvm or anything
scary like that). It seemed to be some long irqs-off latency in the
tun/tap or bridging code (it went away when I stopped using "-net tap"
on the qemu command line), but I never succeeded in getting Ingo's
latency tracer to be able to track it down.
- R.
Andrew Morton wrote:
>
>>> Presumably someone is getting a lot of these messages.
>>>
>>> Do we know why? Is there something which needs fixing here?
>>>
>> I got it a lot when using any sort of virtualization on my Core2Duo
>> (kvm, vmware, qemu). Just a big spew. Honestly, I was getting this with
>> 2.6.20, and haven't tested again with latest kernel.
>>
>
> OK, a bit of googling finds things like this:
> http://chxo.com/be2/20060821_3333.html, so I assume that it's some sort of
> generic problem with the hypervisor's emulation of the RTC.
>
> Zach, do you know what the score is here?
>
We at least jack up the rtc for fast clock timeouts with better
granularity - so it can be a host kernel issue, although a guest kernel
trying to get high frequency RTC will also be inaccurate, and inevitably
will have unhidable interrupt lateness.
Ratelimiting seems the right thing to do, as once you have noted late
RTC interrupts, it doesn't need to be noted again, and there is nothing
you can do to fix it. It is useful as a warning about interrupt
disabled handlers taking too long, but there are other ways of detecting
that too.
Zach
Ben Collins <[email protected]> writes:
Why?
-Andi
On Fri, 2007-05-25 at 13:33 +0200, Andi Kleen wrote:
> Ben Collins <[email protected]> writes:
>
> Why?
Because there's no other way to make the kernel totally quiet. We've
been patching this out so that the boot sequence has that "clean look".
Other than that, it's useless :)
--
Ubuntu : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/
Ben Collins wrote:
> On Fri, 2007-05-25 at 13:33 +0200, Andi Kleen wrote:
>> Ben Collins <[email protected]> writes:
>>
>> Why?
>
> Because there's no other way to make the kernel totally quiet. We've
> been patching this out so that the boot sequence has that "clean look".
>
> Other than that, it's useless :)
>
Worse than that, it's harmful.
"Clean look" means "undebuggable."
-hpa
On Friday, May 25, 2007 12:45:40 H. Peter Anvin wrote:
> Ben Collins wrote:
> > On Fri, 2007-05-25 at 13:33 +0200, Andi Kleen wrote:
> >> Ben Collins <[email protected]> writes:
> >>
> >> Why?
> >
> > Because there's no other way to make the kernel totally quiet. We've
> > been patching this out so that the boot sequence has that "clean look".
> >
> > Other than that, it's useless :)
>
> Worse than that, it's harmful.
>
> "Clean look" means "undebuggable."
But how often do you have to debug bootloader or compressed boot code? In
fact, most debug output like this isn't very useful after some initial
debugging, so we usually take it out. I'm not sure why this would be any
different...
Jesse
Jesse Barnes wrote:
>
> But how often do you have to debug bootloader or compressed boot code? In
> fact, most debug output like this isn't very useful after some initial
> debugging, so we usually take it out. I'm not sure why this would be any
> different...
>
You're asking me this?
I get to hear all the time about some new platform -- sometimes exotic,
sometimes not -- breaking early boot.
-hpa
On Friday, May 25, 2007 4:28:18 H. Peter Anvin wrote:
> Jesse Barnes wrote:
> > But how often do you have to debug bootloader or compressed boot code?
> > In fact, most debug output like this isn't very useful after some initial
> > debugging, so we usually take it out. I'm not sure why this would be any
> > different...
>
> You're asking me this?
>
> I get to hear all the time about some new platform -- sometimes exotic,
> sometimes not -- breaking early boot.
Right, but you're special that way. And moreover, you would know how to add
such debug statements as needed. But is this output something we really need
enabled unconditionally for everyone?
I personally don't care that much, aside from the feeling that we have way too
many printks in general...
Jesse
Jesse Barnes wrote:
>
> Right, but you're special that way. And moreover, you would know how to add
> such debug statements as needed. But is this output something we really need
> enabled unconditionally for everyone?
>
*I* can do that, yes, but I usually don't have access to the platform in
question.
As such I really don't want to see this as a compilation option. Make
it a runtime option[*] so the user with the problematic machine.
> I personally don't care that much, aside from the feeling that we have way too
> many printks in general...
[*] FWIW, my setup rewrite has a proper command-line parser in it, so we
can use the command line from the start.
On Fri, 2007-05-25 at 16:28 -0700, H. Peter Anvin wrote:
> Jesse Barnes wrote:
> >
> > But how often do you have to debug bootloader or compressed boot code? In
> > fact, most debug output like this isn't very useful after some initial
> > debugging, so we usually take it out. I'm not sure why this would be any
> > different...
> >
>
> You're asking me this?
>
> I get to hear all the time about some new platform -- sometimes exotic,
> sometimes not -- breaking early boot.
Truth be told, I'd much rather just remove the informational pustr's and
leave the error ones enabled. If it's acceptable, I can just remove
those lines, or make them only work with -DDEBUG.
--
Ubuntu : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/
On Friday, May 25, 2007 4:43:41 H. Peter Anvin wrote:
> Jesse Barnes wrote:
> > Right, but you're special that way. And moreover, you would know how to
> > add such debug statements as needed. But is this output something we
> > really need enabled unconditionally for everyone?
>
> *I* can do that, yes, but I usually don't have access to the platform in
> question.
>
> As such I really don't want to see this as a compilation option. Make
> it a runtime option[*] so the user with the problematic machine.
>
> > I personally don't care that much, aside from the feeling that we have
> > way too many printks in general...
>
> [*] FWIW, my setup rewrite has a proper command-line parser in it, so we
> can use the command line from the start.
Yeah, that sounds much better. Then it can just be under the usual 'debug'
command line option.
Jesse
Ben Collins wrote:
> On Fri, 2007-05-25 at 16:28 -0700, H. Peter Anvin wrote:
>> Jesse Barnes wrote:
>>> But how often do you have to debug bootloader or compressed boot code? In
>>> fact, most debug output like this isn't very useful after some initial
>>> debugging, so we usually take it out. I'm not sure why this would be any
>>> different...
>>>
>> You're asking me this?
>>
>> I get to hear all the time about some new platform -- sometimes exotic,
>> sometimes not -- breaking early boot.
>
> Truth be told, I'd much rather just remove the informational pustr's and
> leave the error ones enabled. If it's acceptable, I can just remove
> those lines, or make them only work with -DDEBUG.
The problem with that is you don't have any idea how far a boot
proceeded before a hang. That's actually a very important piece of
information.
-hpa
On Wed, May 23, 2007 at 06:39:24PM -0400, Ben Collins wrote:
> Various unusual dev entries accumulated from Ubuntu bug reports.
>
> CC: Phil Dibowitz <[email protected]>
> CC: Alan Stern <[email protected]>
> CC: [email protected]
> Signed-off-by: Ben Collins <[email protected]>
> ---
> drivers/usb/storage/unusual_devs.h | 21 +++++++++++++++++++--
>
> +/* Reported by Edward Chapman <[EMAIL PROTECTED]>
The "<[EMAIL PROTECTED]>" seems a bit pointless.
Dave
--
http://www.codemonkey.org.uk
On Wed, May 30, 2007 at 05:50:28PM -0400, Dave Jones wrote:
> On Wed, May 23, 2007 at 06:39:24PM -0400, Ben Collins wrote:
> > Various unusual dev entries accumulated from Ubuntu bug reports.
> >
> > CC: Phil Dibowitz <[email protected]>
> > CC: Alan Stern <[email protected]>
> > CC: [email protected]
> > Signed-off-by: Ben Collins <[email protected]>
> > ---
> > drivers/usb/storage/unusual_devs.h | 21 +++++++++++++++++++--
> >
> > +/* Reported by Edward Chapman <[EMAIL PROTECTED]>
>
> The "<[EMAIL PROTECTED]>" seems a bit pointless.
Yeah - I already asked for that to get nuked, it was removed before I
accepted the patch, and before Greg pushed it up to Linus.
--
Phil Dibowitz [email protected]
Open Source software and tech docs Insanity Palace of Metallica
http://www.phildev.net/ http://www.ipom.com/
"Never write it in C if you can do it in 'awk';
Never do it in 'awk' if 'sed' can handle it;
Never use 'sed' when 'tr' can do the job;
Never invoke 'tr' when 'cat' is sufficient;
Avoid using 'cat' whenever possible" -- Taylor's Laws of Programming