---
 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(-)

arch/i386/Kconfig.debug +6 -0

index b31c080..eb26441 100644
@@ -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

arch/i386/boot/compressed/misc.c +5 -3

index b28505c..cc630d5 100644
@@ -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)
 {

arch/x86_64/Kconfig.debug +6 -0

index 775d211..a1b87b8 100644
@@ -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

arch/x86_64/boot/compressed/misc.c +5 -3

index f932b0e..43bb44c 100644
@@ -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)
 {

Signature · 1 line

1.5.1.4

Randy Dunlap

2007-05-24 03:10 UTC #2 lore raw

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

arch/i386/boot/compressed/misc.c static void putstr(const char *s) · line 281

Quoted 10 lines · On Wed, 23 May 2007 17:59:10 -0400 Ben Collins wrote:

arch/i386/boot/compressed/misc.c +2 -0

index b28505c..cc630d5 100644
@@ -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)

Quoted 9 lines

arch/i386/boot/compressed/misc.c +1 -0
+#endif /* CONFIG_WRAPPER_PRINT */
 
 static void* memset(void* s, int c, unsigned n)
 {
arch/x86_64/boot/compressed/misc.c +0 -0
index f932b0e..43bb44c 100644

arch/x86_64/boot/compressed/misc.c static void putstr(const char *s) · line 277

Quoted 5 lines

arch/x86_64/boot/compressed/misc.c +2 -0

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

arch/x86_64/boot/compressed/misc.c static void putstr(const char *s) · line 281

Quoted 4 lines

arch/x86_64/boot/compressed/misc.c +1 -0

+#endif /* CONFIG_WRAPPER_PRINT */
 
 static void* memset(void* s, int c, unsigned n)
 {

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Andrew Morton

2007-05-24 20:44 UTC #3 lore raw

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

In reply to Ben Collins

Quoted 14 lines · 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(-)

arch/i386/Kconfig.debug config EARLY_PRINTK · line 27

Quoted 9 lines

arch/i386/Kconfig.debug +6 -0

@@ -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?

Andi Kleen

2007-05-25 10:36 UTC #4 lore raw

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

In reply to Ben Collins

Ben Collins <[email protected]> writes:

Why?

-Andi

Ben Collins

2007-05-25 12:52 UTC #5 lore raw

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

Quoted 3 lines · Andi Kleen

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 :)

Signature · 2 lines

Ubuntu   : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/

H. Peter Anvin

2007-05-25 19:46 UTC #6 lore raw

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

Quoted 10 lines · Ben Collins

Quoted 3 lines · Andi Kleen
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

Jesse Barnes

2007-05-25 23:24 UTC #7 lore raw

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

Quoted 6 lines · On Friday, May 25, 2007 12:45:40 H. Peter Anvin wrote:

Quoted 5 lines · Ben Collins
Quoted 3 lines · Andi Kleen
Ben Collins <[email protected]> writes:
Why?

Quoted 8 lines

Quoted 4 lines
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

H. Peter Anvin

2007-05-25 23:28 UTC #8 lore raw

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

Quoted 6 lines · Jesse Barnes

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

Jesse Barnes

2007-05-25 23:38 UTC #9 lore raw

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

Quoted 10 lines · On Friday, May 25, 2007 4:28:18 H. Peter Anvin wrote:

Quoted 4 lines · Jesse Barnes
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

H. Peter Anvin

2007-05-25 23:43 UTC #10 lore raw

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

Quoted 5 lines · Jesse Barnes

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.

Quoted 2 lines

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.

Jesse Barnes

2007-05-25 23:51 UTC #11 lore raw

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

Quoted 8 lines · On Friday, May 25, 2007 4:43:41 H. Peter Anvin wrote:

Quoted 3 lines · Jesse Barnes
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.

Quoted 8 lines

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.
Quoted 2 lines
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

2007-05-25 23:50 UTC #12 lore raw

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

In reply to H. Peter Anvin

Quoted 8 lines · H. Peter Anvin

Quoted 6 lines · Jesse Barnes
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...

Quoted 4 lines

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.

Signature · 2 lines

Ubuntu   : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/

H. Peter Anvin

2007-05-25 23:53 UTC #13 lore raw

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

Quoted 7 lines · Ben Collins

Quoted 6 lines · H. Peter Anvin
Quoted 5 lines · Jesse Barnes
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...

Quoted 8 lines

Quoted 4 lines
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

Ben Collins

author

2007-05-24 02:42 UTC #14 lore raw

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

In reply to 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 <[email protected]>

---
 drivers/base/power/Makefile |    2 +-
 kernel/power/Kconfig        |   17 ++++++++++++-----
 2 files changed, 13 insertions(+), 6 deletions(-)

drivers/base/power/Makefile +1 -1

index 91f2309..704d326 100644
@@ -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

kernel/power/Kconfig +12 -5

index 495b7d4..1f8cdbd 100644
@@ -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

Signature · 1 line

1.5.1.4

Ben Collins

author

2007-05-24 01:12 UTC #15 lore raw

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

In reply to Ben Collins

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(-)

drivers/bluetooth/hci_usb.c +1 -1

index b0238b4..d636142 100644
@@ -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 },

Signature · 1 line

1.5.1.4

Marcel Holtmann

maintainer

2007-05-24 17:03 UTC #16 lore raw

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

Hi Ben,

Quoted 14 lines

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(-)
drivers/bluetooth/hci_usb.c +0 -0
index b0238b4..d636142 100644

drivers/bluetooth/hci_usb.c static struct usb_device_id blacklist_ids[] = { · line 137

Quoted 8 lines

drivers/bluetooth/hci_usb.c +1 -1

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

Ben Collins

2007-05-24 17:32 UTC #17 lore raw

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

Quoted 22 lines · Marcel Holtmann

Hi Ben,
Quoted 20 lines
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(-)
drivers/bluetooth/hci_usb.c +1 -1
index b0238b4..d636142 100644
@@ -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 },
 

Quoted 6 lines

drivers/bluetooth/hci_usb.c static struct usb_device_id blacklist_ids[] = { · line 137
Quoted 2 lines
drivers/bluetooth/hci_usb.c +0 -0
 	/* 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.

Signature · 2 lines

Ubuntu   : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/

Ben Collins

author

2007-05-24 01:12 UTC #18 lore raw

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

In reply to Ben Collins

Signed-off-by Ben Collins <[email protected]>

---
 drivers/char/rtc.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

drivers/char/rtc.c +2 -1

index 20380a2..22cf7aa 100644
@@ -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);

Signature · 1 line

1.5.1.4

Andrew Morton

2007-05-24 20:48 UTC #19 lore raw

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

Quoted 10 lines · 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(-)
drivers/char/rtc.c +0 -0
index 20380a2..22cf7aa 100644

drivers/char/rtc.c static void rtc_dropped_irq(unsigned long data) · line 1164

Quoted 7 lines

drivers/char/rtc.c +2 -1

@@ -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?

Ben Collins

2007-05-24 20:56 UTC #20 lore raw

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

Quoted 16 lines · Andrew Morton

Quoted 13 lines · 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(-)
drivers/char/rtc.c +0 -0
index 20380a2..22cf7aa 100644
@@ -1159,7 +1159,8 @@ static void rtc_dropped_irq(unsigned long data)
 
 	spin_unlock_irq(&rtc_lock);
 

Quoted 8 lines

drivers/char/rtc.c static void rtc_dropped_irq(unsigned long data) · line 1164
Quoted 4 lines
drivers/char/rtc.c +2 -1
-	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.

Signature · 2 lines

Ubuntu   : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/

Andrew Morton

2007-05-24 21:10 UTC #21 lore raw

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

Quoted 24 lines · On Thu, 24 May 2007 16:56:52 -0400 Ben Collins <[email protected]> wrote:

Quoted 23 lines · Andrew Morton
Quoted 10 lines · 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(-)
drivers/char/rtc.c +0 -0
index 20380a2..22cf7aa 100644
drivers/char/rtc.c static void rtc_dropped_irq(unsigned long data) · line 1164
Quoted 7 lines
drivers/char/rtc.c +2 -1
@@ -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.

Quoted 5 lines

Quoted 1 line
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.

Roland Dreier

2007-05-24 21:15 UTC #22 lore raw

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

Quoted 7 lines

Quoted 3 lines
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.

Zachary Amsden

2007-05-24 21:22 UTC #23 lore raw

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

In reply to Andrew Morton

Quoted 10 lines · Andrew Morton

Quoted 9 lines
Quoted 5 lines
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.

Quoted 6 lines

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

author

2007-05-24 02:06 UTC #24 lore raw

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

In reply to 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 <[email protected]>

Signed-off-by Ben Collins <[email protected]>

---
 drivers/net/sunhme.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

drivers/net/sunhme.c +1 -0

index 51c3fe2..5753298 100644
@@ -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))

Signature · 1 line

1.5.1.4

David Miller

maintainer

2007-05-24 00:17 UTC #25 lore raw

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

From: Ben Collins <[email protected]>
Date: Wed, 23 May 2007 18:30:46 -0400

Quoted 7 lines

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.

Ben Collins

2007-05-24 01:59 UTC #26 lore raw

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

Quoted 11 lines · David Miller

From: Ben Collins <[email protected]>
Date: Wed, 23 May 2007 18:30:46 -0400
Quoted 7 lines
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? :)

Quoted 5 lines

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.

Signature · 2 lines

Ubuntu   : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/

Daniel Drake

2007-05-24 12:32 UTC #27 lore raw

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

In reply to Ben Collins

Quoted 7 lines · 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? :)

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

Ben Collins

author

2007-05-24 00:44 UTC #28 lore raw

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

In reply to Ben Collins

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(-)

drivers/usb/storage/unusual_devs.h +19 -2

index d230ee7..8a24f1c 100644
@@ -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,

Signature · 1 line

1.5.1.4

Phil Dibowitz

2007-05-24 04:19 UTC #29 lore raw

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

Quoted 3 lines · Ben Collins

Various unusual dev entries accumulated from Ubuntu bug reports.
CC Phil Dibowitz <[email protected]>

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

drivers/usb/storage/unusual_devs.h UNUSUAL_DEV( 0x0ace, 0x20ff, 0x0101, 0x0101, · line 1198

Quoted 3 lines

drivers/usb/storage/unusual_devs.h +3 -0

+/* 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)

drivers/usb/storage/unusual_devs.h UNUSUAL_DEV( 0x0dd8, 0x1060, 0x0000, 0xffff, · line 1284

Quoted 3 lines

drivers/usb/storage/unusual_devs.h +3 -0

+/* 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.

Signature · 9 lines

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

2007-05-24 04:09 UTC #30 lore raw

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

Quoted 5 lines · Phil Dibowitz

Quoted 3 lines · Ben Collins
Various unusual dev entries accumulated from Ubuntu bug reports.
CC Phil Dibowitz <[email protected]>

Quoted 8 lines

NACK. Two fixes I'd like to see fixed.
drivers/usb/storage/unusual_devs.h UNUSUAL_DEV( 0x0ace, 0x20ff, 0x0101, 0x0101, · line 1198
Quoted 3 lines
drivers/usb/storage/unusual_devs.h +3 -0
+/* 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.

Quoted 5 lines

drivers/usb/storage/unusual_devs.h UNUSUAL_DEV( 0x0dd8, 0x1060, 0x0000, 0xffff, · line 1284
Quoted 3 lines
drivers/usb/storage/unusual_devs.h +3 -0
+/* 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.

Signature · 2 lines

Ubuntu   : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/

Dave Jones

2007-05-30 21:51 UTC #31 lore raw

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

In reply to Ben Collins

Quoted 10 lines · Ben Collins

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

Signature · 1 line

http://www.codemonkey.org.uk

Phil Dibowitz

2007-05-30 22:25 UTC #32 lore raw

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

Quoted 10 lines · Dave Jones

Quoted 9 lines · Ben Collins
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 +++++++++++++++++++--

Quoted 3 lines

Quoted 1 line
+/* 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.

Signature · 9 lines

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