[PATCH 0/6] Patch sync from Ubuntu tree

[PATCH 0/6] Patch sync from Ubuntu tree

[Ben Collins]

Patch set to sync up some Ubuntu patches.

Git tree: git://kernel.ubuntu.com/bcollins/ubuntu-for-upstream

[PATCH 1/6] i386/x86_64: Allow disabling the putstr's from compressed boot wrapper

[Ben Collins]

Signed-off-by: Ben Collins <bcollins@ubuntu.com>
---
 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

Re: [PATCH 1/6] i386/x86_64: Allow disabling the putstr's from compressed boot wrapper

[Randy Dunlap]

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 ***

Re: [PATCH 1/6] i386/x86_64: Allow disabling the putstr's from compressed boot wrapper (fixed)

[Andrew Morton]

On Wed, 23 May 2007 17:59:10 -0400
Ben Collins <bcollins@ubuntu.com> wrote:

> Updated to include proper spacing for putstr() macro.
> 
> Signed-off-by: Ben Collins <bcollins@ubuntu.com>
> ---
>  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?

Re: [PATCH 1/6] i386/x86_64: Allow disabling the putstr's from compressed boot wrapper

[Andi Kleen]

Ben Collins <bcollins@ubuntu.com> writes:

Why? 

-Andi

Re: [PATCH 1/6] i386/x86_64: Allow disabling the putstr's from compressed boot wrapper

[Ben Collins]

On Fri, 2007-05-25 at 13:33 +0200, Andi Kleen wrote:
> Ben Collins <bcollins@ubuntu.com> 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/

Re: [PATCH 1/6] i386/x86_64: Allow disabling the putstr's from compressed boot wrapper

[H. Peter Anvin]

Ben Collins wrote:
> On Fri, 2007-05-25 at 13:33 +0200, Andi Kleen wrote:
>> Ben Collins <bcollins@ubuntu.com> 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

Re: [PATCH 1/6] i386/x86_64: Allow disabling the putstr's from compressed boot wrapper

[Jesse Barnes]

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 <bcollins@ubuntu.com> 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

Re: [PATCH 1/6] i386/x86_64: Allow disabling the putstr's from compressed boot wrapper

[H. Peter Anvin]

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

Re: [PATCH 1/6] i386/x86_64: Allow disabling the putstr's from compressed boot wrapper

[Jesse Barnes]

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

Re: [PATCH 1/6] i386/x86_64: Allow disabling the putstr's from compressed boot wrapper

[H. Peter Anvin]

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.

Re: [PATCH 1/6] i386/x86_64: Allow disabling the putstr's from compressed boot wrapper

[Jesse Barnes]

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

Re: [PATCH 1/6] i386/x86_64: Allow disabling the putstr's from compressed boot wrapper

[Ben Collins]

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/

Re: [PATCH 1/6] i386/x86_64: Allow disabling the putstr's from compressed boot wrapper

[H. Peter Anvin]

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

[PATCH 2/6] PM: Do not require dev spew to get PM_DEBUG

[Ben Collins]

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 <bcollins@ubuntu.com>
---
 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

[PATCH 3/6] HCIUSB: Initialize the Broadcom USB Bluetooth device in Dell laptops.

[Ben Collins]

CC: Marcel Holtmann <marcel@holtmann.org>
CC: Maxim Krasnyansky <maxk@qualcomm.com>
Signed-off-by: Tim Gardner <tim.gardner@ubuntu.com>
Signed-off-by: Phillip lougher <phillip@ubuntu.com>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
---
 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

Re: [PATCH 3/6] HCIUSB: Initialize the Broadcom USB Bluetooth device in Dell laptops.

[Marcel Holtmann]

Hi Ben,

> CC: Marcel Holtmann <marcel@holtmann.org>
> CC: Maxim Krasnyansky <maxk@qualcomm.com>
> Signed-off-by: Tim Gardner <tim.gardner@ubuntu.com>
> Signed-off-by: Phillip lougher <phillip@ubuntu.com>
> Signed-off-by: Ben Collins <bcollins@ubuntu.com>
> ---
>  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

Re: [PATCH 3/6] HCIUSB: Initialize the Broadcom USB Bluetooth device in Dell laptops.

[Ben Collins]

On Thu, 2007-05-24 at 19:02 +0200, Marcel Holtmann wrote:
> Hi Ben,
> 
> > CC: Marcel Holtmann <marcel@holtmann.org>
> > CC: Maxim Krasnyansky <maxk@qualcomm.com>
> > Signed-off-by: Tim Gardner <tim.gardner@ubuntu.com>
> > Signed-off-by: Phillip lougher <phillip@ubuntu.com>
> > Signed-off-by: Ben Collins <bcollins@ubuntu.com>
> > ---
> >  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/

[PATCH 4/6] RTC: Ratelimit "lost interrupts" message

[Ben Collins]

Signed-off-by: Ben Collins <bcollins@ubuntu.com>
---
 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

Re: [PATCH 4/6] RTC: Ratelimit "lost interrupts" message

[Andrew Morton]

On Wed, 23 May 2007 18:23:06 -0400
Ben Collins <bcollins@ubuntu.com> wrote:

> Signed-off-by: Ben Collins <bcollins@ubuntu.com>
> ---
>  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?

Re: [PATCH 4/6] RTC: Ratelimit "lost interrupts" message

[Ben Collins]

On Thu, 2007-05-24 at 13:48 -0700, Andrew Morton wrote:
> On Wed, 23 May 2007 18:23:06 -0400
> Ben Collins <bcollins@ubuntu.com> wrote:
> 
> > Signed-off-by: Ben Collins <bcollins@ubuntu.com>
> > ---
> >  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/

Re: [PATCH 4/6] RTC: Ratelimit "lost interrupts" message

[Andrew Morton]

On Thu, 24 May 2007 16:56:52 -0400
Ben Collins <ben.collins@ubuntu.com> wrote:

> On Thu, 2007-05-24 at 13:48 -0700, Andrew Morton wrote:
> > On Wed, 23 May 2007 18:23:06 -0400
> > Ben Collins <bcollins@ubuntu.com> wrote:
> > 
> > > Signed-off-by: Ben Collins <bcollins@ubuntu.com>
> > > ---
> > >  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.

Re: [PATCH 4/6] RTC: Ratelimit "lost interrupts" message

[Roland Dreier]

 > > 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.

Re: [PATCH 4/6] RTC: Ratelimit "lost interrupts" message

[Zachary Amsden]

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

[PATCH 5/6] SUNHME: Workaround ancient hang on U1's

[Ben Collins]

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 <davem@davemloft.net>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
---
 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

Re: [PATCH 5/6] SUNHME: Workaround ancient hang on U1's

[David Miller]

From: Ben Collins <bcollins@ubuntu.com>
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.

Re: [PATCH 5/6] SUNHME: Workaround ancient hang on U1's

[Ben Collins]

On Wed, 2007-05-23 at 17:17 -0700, David Miller wrote:
> From: Ben Collins <bcollins@ubuntu.com>
> 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/

Re: [PATCH 5/6] SUNHME: Workaround ancient hang on U1's

[Daniel Drake]

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/sparclinux@vger.kernel.org/msg00418.html

Daniel

[PATCH 6/6] UNUSUAL_DEV: Sync up some reported devices from Ubuntu

[Ben Collins]

Various unusual dev entries accumulated from Ubuntu bug reports.

CC: Phil Dibowitz <phil@ipom.com>
CC: Alan Stern <stern@rowland.harvard.edu>
CC: linux-usb-devel@lists.sourceforge.net
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
---
 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 <bcollins@ubuntu.com> */
+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 <stephan.walter@epfl.ch>
  * I don't know why, but it works... */
 UNUSUAL_DEV( 0x0dda, 0x0001, 0x0012, 0x0012,
-- 
1.5.1.4

Re: [PATCH 6/6] UNUSUAL_DEV: Sync up some reported devices from Ubuntu

[Phil Dibowitz]

[-- Attachment #1: Type: text/plain, Size: 1117 bytes --]

Ben Collins wrote:
> Various unusual dev entries accumulated from Ubuntu bug reports.
> 
> CC: Phil Dibowitz <phil@ipom.com>

NACK. Two fixes I'd like to see fixed.

> +/* SanDisk that has a second LUN for a driver ISO, reported by
> + * Ben Collins <bcollins@ubuntu.com> */
> +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                             phil@ipom.com
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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [PATCH 6/6] UNUSUAL_DEV: Sync up some reported devices from Ubuntu

[Ben Collins]

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 <phil@ipom.com>
> 
> NACK. Two fixes I'd like to see fixed.
> 
> > +/* SanDisk that has a second LUN for a driver ISO, reported by
> > + * Ben Collins <bcollins@ubuntu.com> */
> > +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/

Re: [PATCH 6/6] UNUSUAL_DEV: Sync up some reported devices from Ubuntu

[Dave Jones]

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 <phil@ipom.com>
 > CC: Alan Stern <stern@rowland.harvard.edu>
 > CC: linux-usb-devel@lists.sourceforge.net
 > Signed-off-by: Ben Collins <bcollins@ubuntu.com>
 > ---
 >  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

Re: [PATCH 6/6] UNUSUAL_DEV: Sync up some reported devices from Ubuntu

[Phil Dibowitz]

[-- Attachment #1: Type: text/plain, Size: 1191 bytes --]

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 <phil@ipom.com>
>  > CC: Alan Stern <stern@rowland.harvard.edu>
>  > CC: linux-usb-devel@lists.sourceforge.net
>  > Signed-off-by: Ben Collins <bcollins@ubuntu.com>
>  > ---
>  >  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                             phil@ipom.com
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


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]