Mark Lord wrote:
..
While doing insert/remove (quickly) tests on USB,
I managed to trigger an Oops on 2.6.23.8 on a call
to strlen() in make_class_name().
USB maintainers can try this themselves, by plugging in an
external USB XX-in-1 flash reader, with a CF card inserted.
Then just jiggle
Mark Lord wrote:
Mark Lord wrote:
Mark Lord wrote:
...
And here is a "prevented" oops, courtesy of the patch (2.6.23.8).
These are easy to reproduce (just jiggle the connection on an
attached USB multi-card reader with a CF card inserted):
...
[ 347.099562] usb 5-6: USB disconnec
Mark Lord wrote:
Mark Lord wrote:
...
And here is a "prevented" oops, courtesy of the patch (2.6.23.8).
These are easy to reproduce (just jiggle the connection on an
attached USB multi-card reader with a CF card inserted):
...
[ 347.099562] usb 5-6: USB disconnect, address 10
[
Mark Lord wrote:
(reposting for linux-usb-devel list)
Greg KH wrote:
On Wed, Nov 28, 2007 at 11:00:36PM -0500, Mark Lord wrote:
While doing insert/remove (quickly) tests on USB, I managed to trigger
an Oops on 2.6.23.8 on the call to strlen() in make_class_name().
This patch prevents
(reposting for linux-usb-devel list)
Greg KH wrote:
On Wed, Nov 28, 2007 at 11:00:36PM -0500, Mark Lord wrote:
While doing insert/remove (quickly) tests on USB, I managed to trigger
an Oops on 2.6.23.8 on the call to strlen() in make_class_name().
This patch prevents this oops
Greg KH wrote:
On Wed, Nov 28, 2007 at 11:00:36PM -0500, Mark Lord wrote:
While doing insert/remove (quickly) tests on USB, I managed to trigger
an Oops on 2.6.23.1 on the call to strlen() in make_class_name().
This patch prevents this oops.
There is still the larger problem of the overall
Greg KH wrote:
On Wed, Nov 28, 2007 at 11:00:36PM -0500, Mark Lord wrote:
While doing insert/remove (quickly) tests on USB, I managed to trigger
an Oops on 2.6.23.1 on the call to strlen() in make_class_name().
This patch prevents this oops.
There is still the larger problem of the overall
Greg KH wrote:
On Wed, Nov 28, 2007 at 11:00:36PM -0500, Mark Lord wrote:
While doing insert/remove (quickly) tests on USB, I managed to trigger
an Oops on 2.6.23.1 on the call to strlen() in make_class_name().
This patch prevents this oops.
There is still the larger problem of the overall
Greg KH wrote:
On Wed, Nov 28, 2007 at 11:00:36PM -0500, Mark Lord wrote:
While doing insert/remove (quickly) tests on USB, I managed to trigger
an Oops on 2.6.23.1 on the call to strlen() in make_class_name().
This patch prevents this oops.
There is still the larger problem of the overall
(reposting for linux-usb-devel list)
Greg KH wrote:
On Wed, Nov 28, 2007 at 11:00:36PM -0500, Mark Lord wrote:
While doing insert/remove (quickly) tests on USB, I managed to trigger
an Oops on 2.6.23.8 on the call to strlen() in make_class_name().
This patch prevents this oops
Mark Lord wrote:
(reposting for linux-usb-devel list)
Greg KH wrote:
On Wed, Nov 28, 2007 at 11:00:36PM -0500, Mark Lord wrote:
While doing insert/remove (quickly) tests on USB, I managed to trigger
an Oops on 2.6.23.8 on the call to strlen() in make_class_name().
This patch prevents
Mark Lord wrote:
Mark Lord wrote:
...
And here is a prevented oops, courtesy of the patch (2.6.23.8).
These are easy to reproduce (just jiggle the connection on an
attached USB multi-card reader with a CF card inserted):
...
[ 347.099562] usb 5-6: USB disconnect, address 10
[ 347.101077] BUG
Mark Lord wrote:
Mark Lord wrote:
Mark Lord wrote:
...
And here is a prevented oops, courtesy of the patch (2.6.23.8).
These are easy to reproduce (just jiggle the connection on an
attached USB multi-card reader with a CF card inserted):
...
[ 347.099562] usb 5-6: USB disconnect, address 10
Mark Lord wrote:
..
While doing insert/remove (quickly) tests on USB,
I managed to trigger an Oops on 2.6.23.8 on a call
to strlen() in make_class_name().
USB maintainers can try this themselves, by plugging in an
external USB XX-in-1 flash reader, with a CF card inserted.
Then just jiggle
Kristen wrote:
...
+* XXX will need Port Multiplier support
What's that all about ?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the
Alan Stern wrote:
On Thu, 29 Nov 2007, Raymano Garibaldi wrote:
The feature does work as long as the device remains plugged in and
that is what I have said in my previous postings too. What I'm saying
that should work and worked under 2.6.21 and is not working currently
is the ability to
Nick Warne wrote:
Hi all,
2.6.23.9
I have noticed after applying Bart's patch to word93 blacklist my new
DVD drive:
http://lkml.org/lkml/2007/10/23/475
I see now in logs (look at the hdd line:
[dmesg]
hdc: 39876480 sectors (20416 MB) w/2048KiB Cache, CHS=39560/16/63,
UDMA(66)
hdc: cache
(resending with condensed version of original syslog)
Alan Stern wrote:
On Thu, 29 Nov 2007, Mark Lord wrote:
But the flogging continues multiple times per second
until the system is shutdown, so it is the next bug to fix.
That's not true. The number of commands sent while probing a device
(resending .. somebody trimmed the CC: list earlier)
Greg KH wrote:
Mark Lord wrote:
..
While doing insert/remove (quickly) tests on USB,
I managed to trigger an Oops on 2.6.23.8 on a call
to strlen() in make_class_name().
...
I'll hold off on adding this patch for now.
..
Why?
Bugs
Kristen Carlson Accardi wrote:
On Thu, 29 Nov 2007 13:16:07 -0500
Mark Lord [EMAIL PROTECTED] wrote:
Kristen wrote:
...
+* XXX will need Port Multiplier support
What's that all about ?
I didn't have any hardware that had LED support as well as Port
Multiplier, so I didn't
Alan Stern wrote:
On Thu, 29 Nov 2007, Mark Lord wrote:
Mark Lord wrote:
..
While doing insert/remove (quickly) tests on USB,
I managed to trigger an Oops on 2.6.23.8 on a call
to strlen() in make_class_name().
Does this oops occur under 2.6.24? The SCSI async scanning code was
changed
Greg KH wrote:
On Thu, Nov 29, 2007 at 03:25:04PM -0500, Mark Lord wrote:
(resending .. somebody trimmed the CC: list earlier)
Greg KH wrote:
Mark Lord wrote:
..
While doing insert/remove (quickly) tests on USB,
I managed to trigger an Oops on 2.6.23.8 on a call
to strlen
Alan Stern wrote:
On Thu, 29 Nov 2007, Mark Lord wrote:
So again, the problem is in the higher up scsi layer, and that is where
the problem should already be fixed.
..
Ahhh.. so you figure the Oops should also have been fixed
as part of the 2.6.24 SCSI fixes ? That's what I was missing here
in class.c appears to also do NULL checks to
avoid Oops'ing, so this continues the tradition.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
Patch applies to both 2.6.24 and 2.6.23.
--- old/drivers/base/class.c2007-11-28 22:54:59.0 -0500
+++ linux/drivers/base/class.c 2007-11
Greg KH wrote:
On Wed, Nov 28, 2007 at 03:02:35PM -0500, Mark Lord wrote:
While testing a new USB reader/cable today,
I was plugging/unplugging the USB multi-flash reader (22 in 1),
and produced this weird oops.
There's a locking problem in there somewhere, Greg.
2.6.23.8
Can you duplicate
While testing a new USB reader/cable today,
I was plugging/unplugging the USB multi-flash reader (22 in 1),
and produced this weird oops.
There's a locking problem in there somewhere, Greg.
2.6.23.8
Cheers
[ 140.987726] usb-storage: waiting for device to settle before scanning
[
Tejun Heo wrote:
Your BIOS is probably trying to issue DCO freeze lock to all drives. I
don't have the faintest idea why it does but it does. I think there are
several choices here.
1. Ignore device errors for _GTF commands. Report the failure with
KERN_DEBUG priority and just keep
Tejun Heo wrote:
Your BIOS is probably trying to issue DCO freeze lock to all drives. I
don't have the faintest idea why it does but it does. I think there are
several choices here.
1. Ignore device errors for _GTF commands. Report the failure with
KERN_DEBUG priority and just keep
While testing a new USB reader/cable today,
I was plugging/unplugging the USB multi-flash reader (22 in 1),
and produced this weird oops.
There's a locking problem in there somewhere, Greg.
2.6.23.8
Cheers
[ 140.987726] usb-storage: waiting for device to settle before scanning
[
Greg KH wrote:
On Wed, Nov 28, 2007 at 03:02:35PM -0500, Mark Lord wrote:
While testing a new USB reader/cable today,
I was plugging/unplugging the USB multi-flash reader (22 in 1),
and produced this weird oops.
There's a locking problem in there somewhere, Greg.
2.6.23.8
Can you duplicate
in class.c appears to also do NULL checks to
avoid Oops'ing, so this continues the tradition.
Signed-off-by: Mark Lord [EMAIL PROTECTED]
---
Patch applies to both 2.6.24 and 2.6.23.
--- old/drivers/base/class.c2007-11-28 22:54:59.0 -0500
+++ linux/drivers/base/class.c 2007-11-28 22:54
Jeff Garzik wrote:
Robert Hancock wrote:
Based on a quick look at sata_mv it appears it sets a 64-bit DMA mask
unconditionally, but for non-ATA_PROT_DMA commands (which includes all
ATAPI), it just falls back to ata_qc_issue_prot which issues via the
legacy SFF interface and can only handle
Mark wrote:
Yeah, I kind of had your reports in mind when I asked that. :)
On a related note, I now have lots of Marvell (sata_mv) hardware here,
and an Intel CPU/chipset box with physical RAM above the 4GB boundary.
Morrison, Tom wrote:
Yes, I believe that - otherwise, this problem would
Morrison, Tom wrote:
I am hopeful that the sata_mv has this bug (I proved that the
problem I was experiencing was due to the sata_mv driver
with 3.75Gig or more of memory)...
I am on vacation for a week or more ...or I'd tell you today
if it did have this bug!
..
Yeah, I kind of had your
Robert Hancock wrote:
This fixes some problems with ATAPI devices on nForce4 controllers in ADMA mode
on systems with memory located above 4GB. We need to delay setting the 64-bit
DMA mask until the PRD table and padding buffer are allocated so that they don't
get allocated above 4GB and break
Robert Hancock wrote:
This fixes some problems with ATAPI devices on nForce4 controllers in ADMA mode
on systems with memory located above 4GB. We need to delay setting the 64-bit
DMA mask until the PRD table and padding buffer are allocated so that they don't
get allocated above 4GB and break
Morrison, Tom wrote:
I am hopeful that the sata_mv has this bug (I proved that the
problem I was experiencing was due to the sata_mv driver
with 3.75Gig or more of memory)...
I am on vacation for a week or more ...or I'd tell you today
if it did have this bug!
..
Yeah, I kind of had your
Mark wrote:
Yeah, I kind of had your reports in mind when I asked that. :)
On a related note, I now have lots of Marvell (sata_mv) hardware here,
and an Intel CPU/chipset box with physical RAM above the 4GB boundary.
Morrison, Tom wrote:
Yes, I believe that - otherwise, this problem would
Jeff Garzik wrote:
Robert Hancock wrote:
Based on a quick look at sata_mv it appears it sets a 64-bit DMA mask
unconditionally, but for non-ATA_PROT_DMA commands (which includes all
ATAPI), it just falls back to ata_qc_issue_prot which issues via the
legacy SFF interface and can only handle
Markus Rechberger wrote:
Hi,
I'm looking at the linux uvc driver, and noticed after resuming my
..
Pardon me.. what is the "uvc" driver? Which module/source file is that?
Thanks
notebook it deadlocks at usb_set_interface.
The linux kernel version on that notebook is 2.6.21.4, I searched
Ingo Molnar wrote:
* Arjan van de Ven <[EMAIL PROTECTED]> wrote:
kernel or kernel source? If there was a good place in the kernel
source I'd not be against moving irqbalance there. [...]
would this be a good case study to use klibc and start up irqbalanced
automatically? I'd love it if we
Arjan van de Ven wrote:
On Tue, 20 Nov 2007 15:02:43 -0500
Mark Lord <[EMAIL PROTECTED]> wrote:
..
Well, for my dualCore notebook, dualCore MythTV box, and QuadCore
desktop, the behaviour of the existing, working, 32-bit kernel
IRQBALANCE code outperforms the userspace utility.
Mos
Arjan van de Ven wrote:
On Wed, 21 Nov 2007 02:43:46 +1100
Nick Piggin <[EMAIL PROTECTED]> wrote:
On Wednesday 21 November 2007 01:47, Arjan van de Ven wrote:
On Tue, 20 Nov 2007 18:37:39 +1100
Nick Piggin <[EMAIL PROTECTED]> wrote:
actually no. IRQ balancing is not a "fast" decision;
(resending this one to the list).
Arjan van de Ven wrote:
On Tue, 20 Nov 2007 10:47:24 -0500
Mark Lord <[EMAIL PROTECTED]> wrote:
..
After reading some of the replies, I installed it on my
malfunctioning 64-bit system, but discovered it does not perform
nearly as well as the kernel so
Arjan van de Ven wrote:
On Tue, 20 Nov 2007 10:52:48 -0500
Mark Lord <[EMAIL PROTECTED]> wro
All of which reminds me of perhaps *the* most important reason to keep
core functionality like "IRQ distribution" *inside* the kernel:
It has to pass peer review on this mailing
Mark Lord wrote:
Arjan van de Ven wrote:
..
I listed a few;
1) it's policy 2) the memory is only needed for a short time (20
seconds or so) on
single-socket machines
3) it makes decisions on "subjective" information such as interrupt
device classes that the kernel currently just do
Arjan van de Ven wrote:
..
I listed a few;
1) it's policy
2) the memory is only needed for a short time (20 seconds or so) on
single-socket machines
3) it makes decisions on "subjective" information such as interrupt
device classes that the kernel currently just doesn't have (it could
grow
Arjan van de Ven wrote:
..
I listed a few;
1) it's policy
2) the memory is only needed for a short time (20 seconds or so) on
single-socket machines
3) it makes decisions on subjective information such as interrupt
device classes that the kernel currently just doesn't have (it could
grow that
Mark Lord wrote:
Arjan van de Ven wrote:
..
I listed a few;
1) it's policy 2) the memory is only needed for a short time (20
seconds or so) on
single-socket machines
3) it makes decisions on subjective information such as interrupt
device classes that the kernel currently just doesn't have
Arjan van de Ven wrote:
On Tue, 20 Nov 2007 10:52:48 -0500
Mark Lord [EMAIL PROTECTED] wro
All of which reminds me of perhaps *the* most important reason to keep
core functionality like IRQ distribution *inside* the kernel:
It has to pass peer review on this mailing list.
that's a reason
(resending this one to the list).
Arjan van de Ven wrote:
On Tue, 20 Nov 2007 10:47:24 -0500
Mark Lord [EMAIL PROTECTED] wrote:
..
After reading some of the replies, I installed it on my
malfunctioning 64-bit system, but discovered it does not perform
nearly as well as the kernel solution
Arjan van de Ven wrote:
On Wed, 21 Nov 2007 02:43:46 +1100
Nick Piggin [EMAIL PROTECTED] wrote:
On Wednesday 21 November 2007 01:47, Arjan van de Ven wrote:
On Tue, 20 Nov 2007 18:37:39 +1100
Nick Piggin [EMAIL PROTECTED] wrote:
actually no. IRQ balancing is not a fast decision; every
Arjan van de Ven wrote:
On Tue, 20 Nov 2007 15:02:43 -0500
Mark Lord [EMAIL PROTECTED] wrote:
..
Well, for my dualCore notebook, dualCore MythTV box, and QuadCore
desktop, the behaviour of the existing, working, 32-bit kernel
IRQBALANCE code outperforms the userspace utility.
Mostly, I
Ingo Molnar wrote:
* Arjan van de Ven [EMAIL PROTECTED] wrote:
kernel or kernel source? If there was a good place in the kernel
source I'd not be against moving irqbalance there. [...]
would this be a good case study to use klibc and start up irqbalanced
automatically? I'd love it if we
Markus Rechberger wrote:
Hi,
I'm looking at the linux uvc driver, and noticed after resuming my
..
Pardon me.. what is the uvc driver? Which module/source file is that?
Thanks
notebook it deadlocks at usb_set_interface.
The linux kernel version on that notebook is 2.6.21.4, I searched
On 32-bit x86, we have CONFIG_IRQBALANCE available,
but not on 64-bit x86. Why not?
I ask, because this feature seems almost essential to obtaining
reasonable latencies during heavy I/O with fast devices.
My 32-bit Core2Duo MythTV box drops audio frames without it,
but works perfectly *with*
On 32-bit x86, we have CONFIG_IRQBALANCE available,
but not on 64-bit x86. Why not?
I ask, because this feature seems almost essential to obtaining
reasonable latencies during heavy I/O with fast devices.
My 32-bit Core2Duo MythTV box drops audio frames without it,
but works perfectly *with*
Ingo Molnar wrote:
* Mark Lord <[EMAIL PROTECTED]> wrote:
Since Ingo's latency trace patches lock up the machine on resume, the
next thing I'll try instead is to re-enable CONFIG_IRQBALANCE=y.
hm, which patch did you try? Could you check whether all chunks from the
patch below are a
Mark Lord wrote:
I have been reporting this off and on since 2.6.23 was released.
This problem was not apparent up to perhaps 2.6.23-rc8,
but definitely became common in 2.6.23 and 2.6.23.1.
Most of the time, a resume-from-RAM on my notebook takes about 2.1 seconds
of kernel time to complete
kernel coder wrote:
hi,
I'm trying to add some code to netif_receive_skb function in
dev.c file . The cycles consumed by that code was around 16 cycles on
Dual Core Opetron machine.I'm working on that code for last 6 months
now and the consumed cycles have always been around 16 cycles .I
Mark Lord wrote:
Rafael J. Wysocki wrote:
..
Which kernel is it against?
..
This patch is for -mm and for Kristen's queue. Not for 2.6.24.
..
Patch was generated against 2.6.24-rc2-git4.
..
That is, against 2.6.24-rc2-git4 with the earlier PCIe hotplug patches
also already applied
Rafael J. Wysocki wrote:
..
Which kernel is it against?
..
This patch is for -mm and for Kristen's queue. Not for 2.6.24.
..
Patch was generated against 2.6.24-rc2-git4.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Rafael J. Wysocki wrote:
..
Which kernel is it against?
..
This patch is for -mm and for Kristen's queue. Not for 2.6.24.
..
Patch was generated against 2.6.24-rc2-git4.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
kernel coder wrote:
hi,
I'm trying to add some code to netif_receive_skb function in
dev.c file . The cycles consumed by that code was around 16 cycles on
Dual Core Opetron machine.I'm working on that code for last 6 months
now and the consumed cycles have always been around 16 cycles .I
Mark Lord wrote:
Rafael J. Wysocki wrote:
..
Which kernel is it against?
..
This patch is for -mm and for Kristen's queue. Not for 2.6.24.
..
Patch was generated against 2.6.24-rc2-git4.
..
That is, against 2.6.24-rc2-git4 with the earlier PCIe hotplug patches
also already applied
Mark Lord wrote:
I have been reporting this off and on since 2.6.23 was released.
This problem was not apparent up to perhaps 2.6.23-rc8,
but definitely became common in 2.6.23 and 2.6.23.1.
Most of the time, a resume-from-RAM on my notebook takes about 2.1 seconds
of kernel time to complete
Ingo Molnar wrote:
* Mark Lord [EMAIL PROTECTED] wrote:
Since Ingo's latency trace patches lock up the machine on resume, the
next thing I'll try instead is to re-enable CONFIG_IRQBALANCE=y.
hm, which patch did you try? Could you check whether all chunks from the
patch below are applied
initializations from those
so that they only ever get done once, as intended.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
This patch is for -mm and for Kristen's queue. Not for 2.6.24.
drivers/pci/hotplug/pciehp.h |2
drivers/pci/hotplug/pciehp_core.c |2
drivers/pci/h
initializations from those
so that they only ever get done once, as intended.
Signed-off-by: Mark Lord [EMAIL PROTECTED]
---
This patch is for -mm and for Kristen's queue. Not for 2.6.24.
drivers/pci/hotplug/pciehp.h |2
drivers/pci/hotplug/pciehp_core.c |2
drivers/pci/hotplug/pciehp_hpc.c
Greg Kroah-Hartman wrote:
We (the -stable team) are announcing the release of the 2.6.23.2 kernel.
It contains a number of bugfixes for the core kernel code.
I'll also be replying to this message with a copy of the patch between
2.6.23.1 and 2.6.23.2
..
Tsugikazu Shibata (1):
HOWTO:
Ingo Molnar wrote:
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
Is there a version of these that works with 2.6.23.1 ?
yes, i've backported it and have uploaded the v2.6.23 version to:
http://redhat.com/~mingo/latency-tracing-patches/latency-tracer-v2.6.23.1-combo.patch
..
ok, i
Mark Lord wrote:
Ingo Molnar wrote:
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
pick up the latest latency tracer patch from:
sorry, wrong URLs, the correct links are:
http://redhat.com/~mingo/latency-tracing-patches/latency-tracer-v2.6.24-rc2-git5-combo.patch
http://redh
Ingo Molnar wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
Is there a version of these that works with 2.6.23.1 ?
yes, i've backported it and have uploaded the v2.6.23 version to:
http://redhat.com/~mingo/latency-tracing-patches/latency-tracer-v2.6.23.1-combo.patch
..
ok, i experimented
Mark Lord wrote:
Ingo Molnar wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
pick up the latest latency tracer patch from:
sorry, wrong URLs, the correct links are:
http://redhat.com/~mingo/latency-tracing-patches/latency-tracer-v2.6.24-rc2-git5-combo.patch
http://redhat.com/~mingo
Greg Kroah-Hartman wrote:
We (the -stable team) are announcing the release of the 2.6.23.2 kernel.
It contains a number of bugfixes for the core kernel code.
I'll also be replying to this message with a copy of the patch between
2.6.23.1 and 2.6.23.2
..
Tsugikazu Shibata (1):
HOWTO:
Ingo Molnar wrote:
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
pick up the latest latency tracer patch from:
sorry, wrong URLs, the correct links are:
http://redhat.com/~mingo/latency-tracing-patches/latency-tracer-v2.6.24-rc2-git5-combo.patch
Morrison, Tom wrote:
The plot thickens - it looks like it might be some type
of problem interacting with the setup of my 4Gig DDR memory
and how I setup some translation windows in my MPC8548E
I realized this morning that I have an inbound/ output PEX window
Translation Setup for mapping all
Bartlomiej Zolnierkiewicz wrote:
Hi,
On Wednesday 14 November 2007, Mark Lord wrote:
Sebastian Kemper wrote:
Hi Mark!
On Wed, Nov 14, 2007 at 11:41:37AM -0500, Mark Lord wrote:
Ahh.. got it. The host_status returned (not checked by that code) was 7,
which means "host error".
In
Greg KH wrote:
On Thu, Nov 15, 2007 at 01:29:04PM -0500, Mark Lord wrote:
Greg KH wrote:
On Thu, Nov 15, 2007 at 12:07:48PM -0500, Mark Lord wrote:
..
Greg, I don't know if this is relevant or not,
but x86 has bugs in the halt/reboot code for SMP.
Specifically, in native_smp_send_stop
Greg KH wrote:
On Thu, Nov 15, 2007 at 12:07:48PM -0500, Mark Lord wrote:
..
Greg, I don't know if this is relevant or not,
but x86 has bugs in the halt/reboot code for SMP.
Specifically, in native_smp_send_stop() the code now uses
spin_trylock() to "lock" the shared ca
Hi!
> I have been reporting this off and on since 2.6.23 was released.
> This problem was not apparent up to perhaps 2.6.23-rc8,
> but definitely became common in 2.6.23 and 2.6.23.1.
>
> Most of the time, a resume-from-RAM on my notebook takes about 2.1 seconds
> of kernel time to complete.
Greg KH wrote:
On Thu, Nov 15, 2007 at 09:55:34PM +0900, Yasunori Goto wrote:
On Thu, 15 Nov 2007 12:11:58 +0300 Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
Three boxes rarely oops during reboot or poweroff with 2.6.24-rc2-mm1
(1) and during 2.6.24 cycle (2):
kernel_restart
Raymano Garibaldi wrote:
Hi,
Is there a way/patch that would revert the USB mass storage
suspend/resume behavior to the way things worked on and prior to
kernel 2.6.21?
The problem is mounting a usb drive, suspending while mounted,
detaching the usb drive during suspend, reattaching usb drive
Mark Lord wrote:
Ray Lee wrote:
..
The real question is, why the 1-sec pauses?
Well, and why the 1-second pauses eventually stop, too. Seems
interesting that they don't continue. Also, they're pretty much
dead-on one- and two-second pauses, with HZ accuracy. Is this with a
NO_HZ kernel
Ray Lee wrote:
On Nov 15, 2007 8:32 AM, Mark Lord <[EMAIL PROTECTED]> wrote:
I have been reporting this off and on since 2.6.23 was released.
This problem was not apparent up to perhaps 2.6.23-rc8,
but definitely became common in 2.6.23 and 2.6.23.1.
Most of the time, a resume-from-RAM
Morrison, Tom wrote:
Additional information - the ~file size this is caused
is somewhere close to 260Mbytesfiles.
If I create a ~260Mbytes file - my program finishes creating
the file - but ~5 seconds later (I timed this by hitting enter
on the console every second after completion of the
I have been reporting this off and on since 2.6.23 was released.
This problem was not apparent up to perhaps 2.6.23-rc8,
but definitely became common in 2.6.23 and 2.6.23.1.
Most of the time, a resume-from-RAM on my notebook takes about 2.1 seconds
of kernel time to complete.
Once in a while,
Greg KH wrote:
On Thu, Nov 15, 2007 at 09:55:34PM +0900, Yasunori Goto wrote:
On Thu, 15 Nov 2007 12:11:58 +0300 Alexey Dobriyan [EMAIL PROTECTED] wrote:
Three boxes rarely oops during reboot or poweroff with 2.6.24-rc2-mm1
(1) and during 2.6.24 cycle (2):
kernel_restart
Raymano Garibaldi wrote:
Hi,
Is there a way/patch that would revert the USB mass storage
suspend/resume behavior to the way things worked on and prior to
kernel 2.6.21?
The problem is mounting a usb drive, suspending while mounted,
detaching the usb drive during suspend, reattaching usb drive
I have been reporting this off and on since 2.6.23 was released.
This problem was not apparent up to perhaps 2.6.23-rc8,
but definitely became common in 2.6.23 and 2.6.23.1.
Most of the time, a resume-from-RAM on my notebook takes about 2.1 seconds
of kernel time to complete.
Once in a while,
Morrison, Tom wrote:
Additional information - the ~file size this is caused
is somewhere close to 260Mbytesfiles.
If I create a ~260Mbytes file - my program finishes creating
the file - but ~5 seconds later (I timed this by hitting enter
on the console every second after completion of the
Ray Lee wrote:
On Nov 15, 2007 8:32 AM, Mark Lord [EMAIL PROTECTED] wrote:
I have been reporting this off and on since 2.6.23 was released.
This problem was not apparent up to perhaps 2.6.23-rc8,
but definitely became common in 2.6.23 and 2.6.23.1.
Most of the time, a resume-from-RAM on my
Mark Lord wrote:
Ray Lee wrote:
..
The real question is, why the 1-sec pauses?
Well, and why the 1-second pauses eventually stop, too. Seems
interesting that they don't continue. Also, they're pretty much
dead-on one- and two-second pauses, with HZ accuracy. Is this with a
NO_HZ kernel
Hi!
I have been reporting this off and on since 2.6.23 was released.
This problem was not apparent up to perhaps 2.6.23-rc8,
but definitely became common in 2.6.23 and 2.6.23.1.
Most of the time, a resume-from-RAM on my notebook takes about 2.1 seconds
of kernel time to complete.
Greg KH wrote:
On Thu, Nov 15, 2007 at 12:07:48PM -0500, Mark Lord wrote:
..
Greg, I don't know if this is relevant or not,
but x86 has bugs in the halt/reboot code for SMP.
Specifically, in native_smp_send_stop() the code now uses
spin_trylock() to lock the shared call buffers
Greg KH wrote:
On Thu, Nov 15, 2007 at 01:29:04PM -0500, Mark Lord wrote:
Greg KH wrote:
On Thu, Nov 15, 2007 at 12:07:48PM -0500, Mark Lord wrote:
..
Greg, I don't know if this is relevant or not,
but x86 has bugs in the halt/reboot code for SMP.
Specifically, in native_smp_send_stop
Bartlomiej Zolnierkiewicz wrote:
Hi,
On Wednesday 14 November 2007, Mark Lord wrote:
Sebastian Kemper wrote:
Hi Mark!
On Wed, Nov 14, 2007 at 11:41:37AM -0500, Mark Lord wrote:
Ahh.. got it. The host_status returned (not checked by that code) was 7,
which means host error.
In this case
Morrison, Tom wrote:
The plot thickens - it looks like it might be some type
of problem interacting with the setup of my 4Gig DDR memory
and how I setup some translation windows in my MPC8548E
I realized this morning that I have an inbound/ output PEX window
Translation Setup for mapping all
Ingo Molnar wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
pick up the latest latency tracer patch from:
sorry, wrong URLs, the correct links are:
http://redhat.com/~mingo/latency-tracing-patches/latency-tracer-v2.6.24-rc2-git5-combo.patch
Mark Lord wrote:
Morrison, Tom wrote:
I have gotten it to boot from those hard-drives and it has the same
behavior:
Copying a large file to the same partition (>150MEG)
causes the system to hang (no I/O - no input/output - nothing -
complete freeze - like a prim
501 - 600 of 1516 matches
Mail list logo
