[Bug 7246] 3w-xxxx, IOMMU and 1go RAM
http://bugzilla.kernel.org/show_bug.cgi?id=7246 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] ||m --- Comment #12 from [EMAIL PROTECTED] 2008-02-25 01:34 --- (In reply to comment #11) If there is no more problems then it looks like the bug can be closed now. Thanks. The bug still exists as you can see in the following bug report on debian: linux-2.6.18-6-amd64: 3w- v1.26.02.001 causes datacorruption with AMD64/EM64T with 2GB RAM http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464923 The problem is with the driver included in the kernel. More information on http://www.3ware.com/KB/article.aspx?id=15243 I'll quote the first post of the bug report, it includes very relevant/useful information: Package: linux-2.6.18-6-amd64 Severity: critical Tags: patch Justification: causes serious data loss How to reproduce: 10036:/tmp# uname -a Linux 10036 2.6.18-6-amd64 #1 SMP Wed Jan 23 06:27:23 UTC 2008 x86_64 GNU/Linux 10036:/tmp# grep MemTotal /proc/meminfo MemTotal: 8179992 kB 10036:/tmp# dd if=/dev/urandom bs=1048576 count=10240 | tee testfile | md5sum 00a513dc3da637c4c86557102b0e6098 - 10239+1 records in 10239+1 records out 10737297534 bytes (11 GB) copied, 1584.6 seconds, 6.8 MB/s 10036:/tmp# md5sum testfile bfceb91a358dfc3d09e22ad74b7ebefb testfile 10036:/tmp# How to fix: There is a 3ware KB article on this: http://www.3ware.com/KB/article.aspx?id=15243 This includes 3ware Storage Controller device driver for Linux v1.26.03.000-2.6.18. From the driver: 1.26.03.000 - Use default DMA data direction to prevent data corruption when using SWIOTLB with 4GB+ on EM64T. Installing this fixes the problem for me. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-vserver-k7 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) My server installation is also suffering from this bug (datacorruption): Debian Release: 4.0 (stable) Architecture: amd64 (64bits) Kernel: 2.6.18-5-amd64 RAM: 4GB RAID Controller: 3w-8500 series Processor: Intel Xeon - EMT64 As I've stated before, the problem resides in the driver included in the kernel, so it's just a matter of replacing it as a patch in the kernel. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 7246] 3w-xxxx, IOMMU and 1go RAM
http://bugzilla.kernel.org/show_bug.cgi?id=7246 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #13 from [EMAIL PROTECTED] 2008-02-25 11:54 --- Javier, The final issue you are talking about (different from original issue in this bugzilla entry): The 3w- driver calling pci_map_sg() with sc_data_direction == DMA_BIDIRECTIONAL caused data corruption when going through swiotlb.c, on EM64T with 4GB or higher of RAM. AMD64 systems using IOMMU were never affected. This problem doesn't exist in the 3w- driver in kernels 2.6.23 and higher. The reason is the 'scsi data buffer accessors' patches removed most instances of scsi drivers calling pci_map_sg() and replaced them with scsi_dma_map(). This corrected the problem of the 3w- driver over-riding the default sc_data_direction that was causing data corruption with EM64T systems with 4GB+ RAM. If you need a driver update for an older kernel to fix this issue, please go to www.3ware.com, however no driver patch to 3w- needs to be sent to the kernel tree to fix this issue. Please close this BUG. -Adam Radford -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 10050] message/fusion/mptbase.c: fix use-after-free's
http://bugzilla.kernel.org/show_bug.cgi?id=10050 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |CLOSED Resolution||CODE_FIX --- Comment #1 from [EMAIL PROTECTED] 2008-02-24 23:57 --- Fixed by commit ad008d42bcec99911b3270a8349f8ec8405a1c4e. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 10050] New: message/fusion/mptbase.c: fix use-after-free's
http://bugzilla.kernel.org/show_bug.cgi?id=10050 Summary: message/fusion/mptbase.c: fix use-after-free's Product: SCSI Drivers Version: 2.5 KernelVersion: 2.6.25-rc2-git Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Other AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] OtherBugsDependingO 9832 nThis: Regression: 1 Subject : message/fusion/mptbase.c: fix use-after-free's Submitter : Adrian Bunk [EMAIL PROTECTED] References : http://lkml.org/lkml/2008/2/19/562 Caused-By : Sathya Prakash [EMAIL PROTECTED] commit e78d5b8f1e73ab82f3fd041d05824cfee7d83a2c Handled-By : Adrian Bunk [EMAIL PROTECTED] Patch : http://lkml.org/lkml/2008/2/19/562 -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 9769] CONFIG_SCSI_WAIT_SCAN configure error
http://bugzilla.kernel.org/show_bug.cgi?id=9769 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] Status|REOPENED|REJECTED Resolution||INVALID --- Comment #5 from [EMAIL PROTECTED] 2008-02-18 06:19 --- Sorry, it is an invalid bug. This has been discussed a few times on linux-scsi. If you have any SCSI driver built as a module, you (or the distro you are running) may need it. We can't tell in Kconfig -- and you might choose to build another driver as a module later. Or out of tree. If you're sure you don't need it, then don't run 'make modules_install'. It's about 2500 bytes ... why waste so much energy being angry? -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 9775] HOST_MSG_LOOP invalid SCB ff
http://bugzilla.kernel.org/show_bug.cgi?id=9775 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |CLOSED Resolution||CODE_FIX --- Comment #11 from [EMAIL PROTECTED] 2008-02-16 18:40 --- Thanks James, I've spent an afternoon rebooting now and finally discovered I had a faulty external SSCI cable. Initial tests suggest its ok. However I remain perplexed. The problem initially manifested when I upgraded my kernel, not when I diddled with my hardware. This now seems to have fixed udev bug http://bugs.gentoo.org/show_bug.cgi?id=200437 as well how bizarre! Thanks for your help everyone. Regards John -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 8004] a likely bug in scsi/arm/cumana_2.c
http://bugzilla.kernel.org/show_bug.cgi?id=8004 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] AssignedTo|[EMAIL PROTECTED] |linux-scsi@vger.kernel.org |bugs.osdl.org | --- Comment #4 from [EMAIL PROTECTED] 2008-02-14 22:44 --- Well, the offending line is still there. Lingxiao, would you like to submit a patch to [EMAIL PROTECTED] -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 9775] HOST_MSG_LOOP invalid SCB ff
http://bugzilla.kernel.org/show_bug.cgi?id=9775
--- Comment #10 from [EMAIL PROTECTED] 2008-02-12 13:56 ---
Reply-To: [EMAIL PROTECTED]
On Fri, 2008-02-08 at 18:52 -0800, [EMAIL PROTECTED]
wrote:
Ok, I've spent some time trying different combinations of devices.
Against kernel 2.6.24
T0 is Quantum DLT8000 ID0
T1 is Quantum DLT8000 ID1
MTX is STK L80 ID 15
Terminators A, B
Channel A B
T0,T1,MTX,B Nil
Crash
Nil T0,T1,MTX,B
Parity Error in Data-in Phase
Nil T0,MTX,B
Ok, Tar test ok, MTX ok
Nil T1,MTX,B
Ok, Tar test ok, MTX ok
-- Both drives work ok
T1,MTX,BNil
Ok Skipped Tests
T1,MTX,ANil
Ok Skipped Tests
T0,MTX,BNil
Crash
T0,MTX,ANil
Crash
-- Not the terminator
--Test on two channels
T0,MTX,AT1,B
Crash
T1,BT0,MTX,A
Parity Error in Data-in Phase
It really doesn't like three devices, on two busses or one.
Well, I still think you have some type of bus instability, but that said
we need to get rid of the panic.
I'm afraid this is going to be a long process. For the first attempt,
let's see if this is an unsolicited msgin ... it looks like the driver
handling for those is wrong. Can you try this patch?
Thanks,
James
---
diff --git a/drivers/scsi/aic7xxx/aic7xxx_core.c
b/drivers/scsi/aic7xxx/aic7xxx_core.c
index 6d2ae64..64e62ce 100644
--- a/drivers/scsi/aic7xxx/aic7xxx_core.c
+++ b/drivers/scsi/aic7xxx/aic7xxx_core.c
@@ -695,15 +695,16 @@ ahc_handle_seqint(struct ahc_softc *ahc, u_int intstat)
scb_index = ahc_inb(ahc, SCB_TAG);
scb = ahc_lookup_scb(ahc, scb_index);
if (devinfo.role == ROLE_INITIATOR) {
- if (scb == NULL)
- panic(HOST_MSG_LOOP with
- invalid SCB %x\n, scb_index);
+ if (bus_phase == P_MESGOUT) {
+ if (scb == NULL)
+ panic(HOST_MSG_LOOP with
+ invalid SCB %x\n,
+ scb_index);
- if (bus_phase == P_MESGOUT)
ahc_setup_initiator_msgout(ahc,
devinfo,
scb);
- else {
+ } else {
ahc-msg_type =
MSG_TYPE_INITIATOR_MSGIN;
ahc-msgin_index = 0;
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 8908] 3ware 9650SE -8LPML not recognized by 3w-9xxx driver
http://bugzilla.kernel.org/show_bug.cgi?id=8908 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |REJECTED Resolution||DOCUMENTED --- Comment #7 from [EMAIL PROTECTED] 2008-02-12 11:32 --- Thanks much, closing the bug. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 8908] 3ware 9650SE -8LPML not recognized by 3w-9xxx driver
http://bugzilla.kernel.org/show_bug.cgi?id=8908 --- Comment #6 from [EMAIL PROTECTED] 2008-02-12 11:30 --- The 9650SE (vendor:0x13c1, device id: 0x1004) controller series has been supported by the in-kernel 3w-9xxx driver since 2.6.19 kernel. The user did not properly configure 'single disk' support through the 3ware BIOS, tw_cli or 3dm2 tool. Please close this bug. -Adam Radford -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 8908] 3ware 9650SE -8LPML not recognized by 3w-9xxx driver
http://bugzilla.kernel.org/show_bug.cgi?id=8908 [EMAIL PROTECTED] changed: What|Removed |Added CC|linux-scsi@vger.kernel.org | AssignedTo|[EMAIL PROTECTED]|[EMAIL PROTECTED] ||bugs.osdl.org --- Comment #5 from [EMAIL PROTECTED] 2008-02-12 10:49 --- (Reassigning to the [EMAIL PROTECTED], instead of CC-ing) -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. You are on the CC list for the bug, or are watching someone who is. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 9880] dma_free_coherent in arcmsr when calling areca tools
http://bugzilla.kernel.org/show_bug.cgi?id=9880 --- Comment #4 from [EMAIL PROTECTED] 2008-02-09 08:52 --- Reply-To: [EMAIL PROTECTED] On Mon, 2008-02-04 at 08:19 +, Russell King wrote: On Sun, Feb 03, 2008 at 09:55:37PM -0600, James Bottomley wrote: I've cc'd the people responsible for this apparent bit of idiocy. Since the API addition to dma_alloc_coherent() was the GFP flags so you could call it from interrupt context with GFP_ATOMIC if so desired, (pci_dma_alloc_consistent always has GFP_ATOMIC semantics), why on earth would the corresponding free routine require non-atomic semantics? For the N-th time, when tearing down the MMU mappings which we need to setup for coherent mappings, we need to invalidate the TLB. On SMP systems, that means doing an IPI to the other CPUs to tell them to invalidate their TLBs as well. Actually it's the first time I'm seeing this. Now, look at the restrictions on calling smp_call_function_on_cpu() or equivalent function which is used to do the IPIs. I don't care if you look that up for x86 or ARM, because the restrictions are the same - see the last two lines: x86: /** * smp_call_function_mask(): Run a function on a set of other CPUs. * @mask: The set of cpus to run on. Must not include the current cpu. * @func: The function to run. This must be fast and non-blocking. * @info: An arbitrary pointer to pass to the function. * @wait: If true, wait (atomically) until function has completed on other CPUs. * * Returns 0 on success, else a negative status code. * * If @wait is true, then returns once @func has returned; otherwise * it returns just before the target cpu calls @func. * * You must not call this function with disabled interrupts or from a * hardware interrupt handler or from a bottom half handler. */ arm: /* * You must not call this function with disabled interrupts, from a * hardware interrupt handler, nor from a bottom half handler. */ So, if the architecture requires you to IPI the TLB flush to other CPUs this restriction has to propagate to dma_free_coherent. Or we just don't provide *any* DMA coherent memory and dictate that such platforms can never use DMA. Which is more idiotic? Why are you actually going to the trouble of freeing the mappings? The MO of most consumers is either to allocate once on attach and free on detach (effectively tying up the memory forever) or to alloc and free descriptors as they come in and go out. In the former case, there's no need for free, in the latter the cycle of setup followed by teardown will add a pretty big latency overhead. Why not just use a pool implementation, so you always add but never free ... it should reach a steady state for the system and be a lot faster than the current implementation. Most architectures actually operate like this ... and they tend to alloc and free in page size chunks to make it easy. If you're worried about memory, you can always reap the pool in the background. James -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 9880] dma_free_coherent in arcmsr when calling areca tools
http://bugzilla.kernel.org/show_bug.cgi?id=9880 --- Comment #5 from [EMAIL PROTECTED] 2008-02-09 09:24 --- On Sat, Feb 09, 2008 at 10:51:16AM -0600, James Bottomley wrote: On Mon, 2008-02-04 at 08:19 +, Russell King wrote: On Sun, Feb 03, 2008 at 09:55:37PM -0600, James Bottomley wrote: I've cc'd the people responsible for this apparent bit of idiocy. Since the API addition to dma_alloc_coherent() was the GFP flags so you could call it from interrupt context with GFP_ATOMIC if so desired, (pci_dma_alloc_consistent always has GFP_ATOMIC semantics), why on earth would the corresponding free routine require non-atomic semantics? For the N-th time, when tearing down the MMU mappings which we need to setup for coherent mappings, we need to invalidate the TLB. On SMP systems, that means doing an IPI to the other CPUs to tell them to invalidate their TLBs as well. Actually it's the first time I'm seeing this. Now, look at the restrictions on calling smp_call_function_on_cpu() or equivalent function which is used to do the IPIs. I don't care if you look that up for x86 or ARM, because the restrictions are the same - see the last two lines: x86: /** * smp_call_function_mask(): Run a function on a set of other CPUs. * @mask: The set of cpus to run on. Must not include the current cpu. * @func: The function to run. This must be fast and non-blocking. * @info: An arbitrary pointer to pass to the function. * @wait: If true, wait (atomically) until function has completed on other CPUs. * * Returns 0 on success, else a negative status code. * * If @wait is true, then returns once @func has returned; otherwise * it returns just before the target cpu calls @func. * * You must not call this function with disabled interrupts or from a * hardware interrupt handler or from a bottom half handler. */ arm: /* * You must not call this function with disabled interrupts, from a * hardware interrupt handler, nor from a bottom half handler. */ So, if the architecture requires you to IPI the TLB flush to other CPUs this restriction has to propagate to dma_free_coherent. Or we just don't provide *any* DMA coherent memory and dictate that such platforms can never use DMA. Which is more idiotic? Why are you actually going to the trouble of freeing the mappings? If we don't free the mappings, we'll eventually end up running out of VM space for the coherent DMA. We only have about 2MB of virtual space for these mappings on most machines. The MO of most consumers is either to allocate once on attach and free on detach (effectively tying up the memory forever) or to alloc and free descriptors as they come in and go out. In the former case, there's no need for free, in the latter the cycle of setup followed by teardown will add a pretty big latency overhead. Why not just use a pool implementation, so you always add but never free ... it should reach a steady state for the system and be a lot faster than the current implementation. Most architectures actually operate like this ... and they tend to alloc and free in page size chunks to make it easy. If you're worried about memory, you can always reap the pool in the background. The existing implementation comes from the original PCI DMA code, which had the restriction that free was not called from interrupt contexts. We now seem to be saying that the newer generic DMA API has different requirements, and these have not been reflected in the ARM implementation. If some of these folk who have the problem want to provide a patch to implement what you've outlined above, I'll certainly review it. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 9880] dma_free_coherent in arcmsr when calling areca tools
http://bugzilla.kernel.org/show_bug.cgi?id=9880 --- Comment #6 from [EMAIL PROTECTED] 2008-02-09 09:34 --- Reply-To: [EMAIL PROTECTED] On Sat, 2008-02-09 at 17:21 +, Russell King wrote: On Sat, Feb 09, 2008 at 10:51:16AM -0600, James Bottomley wrote: On Mon, 2008-02-04 at 08:19 +, Russell King wrote: On Sun, Feb 03, 2008 at 09:55:37PM -0600, James Bottomley wrote: I've cc'd the people responsible for this apparent bit of idiocy. Since the API addition to dma_alloc_coherent() was the GFP flags so you could call it from interrupt context with GFP_ATOMIC if so desired, (pci_dma_alloc_consistent always has GFP_ATOMIC semantics), why on earth would the corresponding free routine require non-atomic semantics? For the N-th time, when tearing down the MMU mappings which we need to setup for coherent mappings, we need to invalidate the TLB. On SMP systems, that means doing an IPI to the other CPUs to tell them to invalidate their TLBs as well. Actually it's the first time I'm seeing this. Now, look at the restrictions on calling smp_call_function_on_cpu() or equivalent function which is used to do the IPIs. I don't care if you look that up for x86 or ARM, because the restrictions are the same - see the last two lines: x86: /** * smp_call_function_mask(): Run a function on a set of other CPUs. * @mask: The set of cpus to run on. Must not include the current cpu. * @func: The function to run. This must be fast and non-blocking. * @info: An arbitrary pointer to pass to the function. * @wait: If true, wait (atomically) until function has completed on other CPUs. * * Returns 0 on success, else a negative status code. * * If @wait is true, then returns once @func has returned; otherwise * it returns just before the target cpu calls @func. * * You must not call this function with disabled interrupts or from a * hardware interrupt handler or from a bottom half handler. */ arm: /* * You must not call this function with disabled interrupts, from a * hardware interrupt handler, nor from a bottom half handler. */ So, if the architecture requires you to IPI the TLB flush to other CPUs this restriction has to propagate to dma_free_coherent. Or we just don't provide *any* DMA coherent memory and dictate that such platforms can never use DMA. Which is more idiotic? Why are you actually going to the trouble of freeing the mappings? If we don't free the mappings, we'll eventually end up running out of VM space for the coherent DMA. We only have about 2MB of virtual space for these mappings on most machines. No, free the memory back to the coherent DMA pool but don't free the mappings; the next use takes a page with existing mappings, thus saving the mapping setup/teardown cycle. My contention is that the system reaches steady state even for alloc/free drivers. The MO of most consumers is either to allocate once on attach and free on detach (effectively tying up the memory forever) or to alloc and free descriptors as they come in and go out. In the former case, there's no need for free, in the latter the cycle of setup followed by teardown will add a pretty big latency overhead. Why not just use a pool implementation, so you always add but never free ... it should reach a steady state for the system and be a lot faster than the current implementation. Most architectures actually operate like this ... and they tend to alloc and free in page size chunks to make it easy. If you're worried about memory, you can always reap the pool in the background. The existing implementation comes from the original PCI DMA code, which had the restriction that free was not called from interrupt contexts. We now seem to be saying that the newer generic DMA API has different requirements, and these have not been reflected in the ARM implementation. If some of these folk who have the problem want to provide a patch to implement what you've outlined above, I'll certainly review it. Being able to allocate from interrupt but not free from interrupt does violate the principle of least surprise. James -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 9769] CONFIG_SCSI_WAIT_SCAN configure error
http://bugzilla.kernel.org/show_bug.cgi?id=9769 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |REJECTED Resolution||INVALID --- Comment #3 from [EMAIL PROTECTED] 2008-02-08 07:56 --- Thanks, closing the bug. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 9769] CONFIG_SCSI_WAIT_SCAN configure error
http://bugzilla.kernel.org/show_bug.cgi?id=9769 --- Comment #2 from [EMAIL PROTECTED] 2008-02-08 07:01 --- Reply-To: [EMAIL PROTECTED] On Thu, 2008-02-07 at 23:28 -0800, [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=9769 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED], ||[EMAIL PROTECTED] --- Comment #1 from [EMAIL PROTECTED] 2008-02-07 23:28 --- This appears to be a dependency, but these are not dependent defines. CONFIG_SCSI_SCAN_ASYNC defines the default scan type, which can be overridden by the module parameter. Yes, this is exactly right. CONFIG_SCSI_ASYNC_SCAN doesn't affect the code (async scan is always included) it affects the boot default. In either case, with the correct kernel parameters, you can boot either sync or async scanning. James -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 9775] HOST_MSG_LOOP invalid SCB ff
http://bugzilla.kernel.org/show_bug.cgi?id=9775 --- Comment #8 from [EMAIL PROTECTED] 2008-02-08 18:52 --- Ok, I've spent some time trying different combinations of devices. Against kernel 2.6.24 T0 is Quantum DLT8000 ID0 T1 is Quantum DLT8000 ID1 MTX is STK L80 ID 15 Terminators A, B Channel A B T0,T1,MTX,B Nil Crash Nil T0,T1,MTX,B Parity Error in Data-in Phase Nil T0,MTX,B Ok, Tar test ok, MTX ok Nil T1,MTX,B Ok, Tar test ok, MTX ok -- Both drives work ok T1,MTX,BNil Ok Skipped Tests T1,MTX,ANil Ok Skipped Tests T0,MTX,BNil Crash T0,MTX,ANil Crash -- Not the terminator --Test on two channels T0,MTX,AT1,B Crash T1,BT0,MTX,A Parity Error in Data-in Phase It really doesn't like three devices, on two busses or one. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 9909] New: Unable to handle kernel NULL pointer dereference at 0000000000000010 (mptsas_probe_expander_phys+0x62/0x427)
http://bugzilla.kernel.org/show_bug.cgi?id=9909 Summary: Unable to handle kernel NULL pointer dereference at 0010 (mptsas_probe_expander_phys+0x62/0x427) Product: IO/Storage Version: 2.5 KernelVersion: 2.6.23 - 2.6.23.14 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: blocking Priority: P1 Component: SCSI AssignedTo: linux-scsi@vger.kernel.org ReportedBy: [EMAIL PROTECTED] Latest working kernel version: 2.6.22-2.6.22.17 Distribution: Gentoo Hardware Environment: 00:00.0 Host bridge [0600]: Intel Corporation 5000X Chipset Memory Controller Hub [8086:25c0] (rev 12) 00:02.0 PCI bridge [0604]: Intel Corporation 5000 Series Chipset PCI Express x4 Port 2 [8086:25e2] (rev 12) 00:03.0 PCI bridge [0604]: Intel Corporation 5000 Series Chipset PCI Express x4 Port 3 [8086:25e3] (rev 12) 00:04.0 PCI bridge [0604]: Intel Corporation 5000 Series Chipset PCI Express x8 Port 4-5 [8086:25f8] (rev 12) 00:05.0 PCI bridge [0604]: Intel Corporation 5000 Series Chipset PCI Express x4 Port 5 [8086:25e5] (rev 12) 00:06.0 PCI bridge [0604]: Intel Corporation 5000 Series Chipset PCI Express x8 Port 6-7 [8086:25f9] (rev 12) 00:07.0 PCI bridge [0604]: Intel Corporation 5000 Series Chipset PCI Express x4 Port 7 [8086:25e7] (rev 12) 00:08.0 System peripheral [0880]: Intel Corporation 5000 Series Chipset DMA Engine [8086:1a38] (rev 12) 00:10.0 Host bridge [0600]: Intel Corporation 5000 Series Chipset FSB Registers [8086:25f0] (rev 12) 00:10.1 Host bridge [0600]: Intel Corporation 5000 Series Chipset FSB Registers [8086:25f0] (rev 12) 00:10.2 Host bridge [0600]: Intel Corporation 5000 Series Chipset FSB Registers [8086:25f0] (rev 12) 00:11.0 Host bridge [0600]: Intel Corporation 5000 Series Chipset Reserved Registers [8086:25f1] (rev 12) 00:13.0 Host bridge [0600]: Intel Corporation 5000 Series Chipset Reserved Registers [8086:25f3] (rev 12) 00:15.0 Host bridge [0600]: Intel Corporation 5000 Series Chipset FBD Registers [8086:25f5] (rev 12) 00:16.0 Host bridge [0600]: Intel Corporation 5000 Series Chipset FBD Registers [8086:25f6] (rev 12) 00:1c.0 PCI bridge [0604]: Intel Corporation 631xESB/632xESB/3100 Chipset PCI Express Root Port 1 [8086:2690] (rev 09) 00:1d.0 USB Controller [0c03]: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #1 [8086:2688] (rev 09) 00:1d.1 USB Controller [0c03]: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #2 [8086:2689] (rev 09) 00:1d.7 USB Controller [0c03]: Intel Corporation 631xESB/632xESB/3100 Chipset EHCI USB2 Controller [8086:268c] (rev 09) 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev d9) 00:1f.0 ISA bridge [0601]: Intel Corporation 631xESB/632xESB/3100 Chipset LPC Interface Controller [8086:2670] (rev 09) 00:1f.1 IDE interface [0101]: Intel Corporation 631xESB/632xESB IDE Controller [8086:269e] (rev 09) 00:1f.2 IDE interface [0101]: Intel Corporation 631xESB/632xESB/3100 Chipset SATA IDE Controller [8086:2680] (rev 09) 01:00.0 SCSI storage controller [0100]: LSI Logic / Symbios Logic SAS1068E PCI-Express Fusion-MPT SAS [1000:0058] (rev 08) 02:00.0 PCI bridge [0604]: Broadcom EPB PCI-Express to PCI-X Bridge [1166:0103] (rev c3) 03:00.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet [14e4:164c] (rev 12) 04:00.0 PCI bridge [0604]: Intel Corporation 6311ESB/6321ESB PCI Express Upstream Port [8086:3500] (rev 01) 04:00.3 PCI bridge [0604]: Intel Corporation 6311ESB/6321ESB PCI Express to PCI-X Bridge [8086:350c] (rev 01) 05:00.0 PCI bridge [0604]: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E1 [8086:3510] (rev 01) 05:01.0 PCI bridge [0604]: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E2 [8086:3514] (rev 01) 06:00.0 PCI bridge [0604]: Broadcom EPB PCI-Express to PCI-X Bridge [1166:0103] (rev c3) 07:00.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet [14e4:164c] (rev 12) 0e:0d.0 VGA compatible controller [0300]: ATI Technologies Inc ES1000 [1002:515e] (rev 02) Software Environment: Gnu C 4.1.2 Gnu make 3.81 binutils Binutils util-linux 2.12r mount 2.12r module-init-tools 3.4 e2fsprogs 1.40.5 Linux C Library2.7 Dynamic linker (ldd) 2.7 Procps 3.2.7 Net-tools 1.60 Kbd1.13 Sh-utils 6.9 Attaching dmesg with oopses (2.6.23 and 2.6.23.14) and dmesg from 2.6.14.17 (working kernel). Please also note that 2.6.23.14 is not able to dump a full Oops msg! -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line
[Bug 9909] Unable to handle kernel NULL pointer dereference at 0000000000000010 (mptsas_probe_expander_phys+0x62/0x427)
http://bugzilla.kernel.org/show_bug.cgi?id=9909 --- Comment #5 from [EMAIL PROTECTED] 2008-02-07 06:26 --- Created an attachment (id=14736) -- (http://bugzilla.kernel.org/attachment.cgi?id=14736action=view) Oops from 2.6.24 -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 9909] Unable to handle kernel NULL pointer dereference at 0000000000000010 (mptsas_probe_expander_phys+0x62/0x427)
http://bugzilla.kernel.org/show_bug.cgi?id=9909 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #4 from [EMAIL PROTECTED] 2008-02-07 06:25 --- The same problem exists in 2.6.24. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 9872] Driver 'sd' needs updating - please use bus_type methods
http://bugzilla.kernel.org/show_bug.cgi?id=9872 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED] ||bugs.osdl.org -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 9909] Unable to handle kernel NULL pointer dereference at 0000000000000010 (mptsas_probe_expander_phys+0x62/0x427)
http://bugzilla.kernel.org/show_bug.cgi?id=9909 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|linux-scsi@vger.kernel.org |[EMAIL PROTECTED] -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 9909] Unable to handle kernel NULL pointer dereference at 0000000000000010 (mptsas_probe_expander_phys+0x62/0x427)
http://bugzilla.kernel.org/show_bug.cgi?id=9909 [EMAIL PROTECTED] changed: What|Removed |Added KernelVersion|2.6.23 - 2.6.23.14 |2.6.23, 2.6.23.14, 2.6.24 -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 9909] Unable to handle kernel NULL pointer dereference at 0000000000000010 (mptsas_probe_expander_phys+0x62/0x427)
http://bugzilla.kernel.org/show_bug.cgi?id=9909 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #14733|Oops from 2.6.23 (truncated)|Oops from 2.6.23.14 description||(truncated) -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 9909] Unable to handle kernel NULL pointer dereference at 0000000000000010 (mptsas_probe_expander_phys+0x62/0x427)
http://bugzilla.kernel.org/show_bug.cgi?id=9909 --- Comment #1 from [EMAIL PROTECTED] 2008-02-07 05:53 --- Created an attachment (id=14732) -- (http://bugzilla.kernel.org/attachment.cgi?id=14732action=view) Oops from 2.6.23 -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 9909] Unable to handle kernel NULL pointer dereference at 0000000000000010 (mptsas_probe_expander_phys+0x62/0x427)
http://bugzilla.kernel.org/show_bug.cgi?id=9909 --- Comment #2 from [EMAIL PROTECTED] 2008-02-07 05:54 --- Created an attachment (id=14733) -- (http://bugzilla.kernel.org/attachment.cgi?id=14733action=view) Oops from 2.6.23 (truncated) -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 9769] CONFIG_SCSI_WAIT_SCAN configure error
http://bugzilla.kernel.org/show_bug.cgi?id=9769 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED], ||[EMAIL PROTECTED] --- Comment #1 from [EMAIL PROTECTED] 2008-02-07 23:28 --- This appears to be a dependency, but these are not dependent defines. CONFIG_SCSI_SCAN_ASYNC defines the default scan type, which can be overridden by the module parameter. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 9880] dma_free_coherent in arcmsr when calling areca tools
http://bugzilla.kernel.org/show_bug.cgi?id=9880 --- Comment #3 from [EMAIL PROTECTED] 2008-02-04 00:20 --- On Sun, Feb 03, 2008 at 09:55:37PM -0600, James Bottomley wrote: I've cc'd the people responsible for this apparent bit of idiocy. Since the API addition to dma_alloc_coherent() was the GFP flags so you could call it from interrupt context with GFP_ATOMIC if so desired, (pci_dma_alloc_consistent always has GFP_ATOMIC semantics), why on earth would the corresponding free routine require non-atomic semantics? For the N-th time, when tearing down the MMU mappings which we need to setup for coherent mappings, we need to invalidate the TLB. On SMP systems, that means doing an IPI to the other CPUs to tell them to invalidate their TLBs as well. Now, look at the restrictions on calling smp_call_function_on_cpu() or equivalent function which is used to do the IPIs. I don't care if you look that up for x86 or ARM, because the restrictions are the same - see the last two lines: x86: /** * smp_call_function_mask(): Run a function on a set of other CPUs. * @mask: The set of cpus to run on. Must not include the current cpu. * @func: The function to run. This must be fast and non-blocking. * @info: An arbitrary pointer to pass to the function. * @wait: If true, wait (atomically) until function has completed on other CPUs. * * Returns 0 on success, else a negative status code. * * If @wait is true, then returns once @func has returned; otherwise * it returns just before the target cpu calls @func. * * You must not call this function with disabled interrupts or from a * hardware interrupt handler or from a bottom half handler. */ arm: /* * You must not call this function with disabled interrupts, from a * hardware interrupt handler, nor from a bottom half handler. */ So, if the architecture requires you to IPI the TLB flush to other CPUs this restriction has to propagate to dma_free_coherent. Or we just don't provide *any* DMA coherent memory and dictate that such platforms can never use DMA. Which is more idiotic? Is it seriously true that you can call dma_alloc_coherent() from atomic context on arm, but not dma_free_coherent()? Yes. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 9880] dma_free_coherent in arcmsr when calling areca tools
http://bugzilla.kernel.org/show_bug.cgi?id=9880 --- Comment #2 from [EMAIL PROTECTED] 2008-02-03 20:36 --- Reply-To: [EMAIL PROTECTED] On Sunday 03 February 2008, James Bottomley wrote: That's caused by this commit: commit aa24886e379d2b641c5117e178b15ce1d5d366ba Author: David Brownell [EMAIL PROTECTED] Date: � Fri Aug 10 13:10:27 2007 -0700 � � dma_free_coherent() needs irqs enabled (sigh) � � I've cc'd the people responsible for this apparent bit of idiocy. �Since the API addition to dma_alloc_coherent() was the GFP flags so you could call it from interrupt context with GFP_ATOMIC if so desired, (pci_dma_alloc_consistent always has GFP_ATOMIC semantics), why on earth would the corresponding free routine require non-atomic semantics? That was my reaction ... but I was told this would not be fixed. See also 8a3c1f573c771e60f67ef172d2392d1a28385b4a ... several other controller drivers needed similar logic at one point. (I eventually ripped that programming interface out, or *EVERY* driver would have needed crap like that. The interface was mostly misused anyway, so it was no big loss.) Is it seriously true that you can call dma_alloc_coherent() from atomic context on arm, but not dma_free_coherent()? Lacking a tasklet in dma_free_coherent() analagous to that omap_udc commit I referenced ... -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 9844] CONFIG_SCSI_MULTI_LUN hangs a camera HARD
http://bugzilla.kernel.org/show_bug.cgi?id=9844 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED] |bugs.osdl.org | Component|Other |USB Product|SCSI Drivers|Drivers -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 9844] New: CONFIG_SCSI_MULTI_LUN hangs a camera HARD
http://bugzilla.kernel.org/show_bug.cgi?id=9844 Summary: CONFIG_SCSI_MULTI_LUN hangs a camera HARD Product: SCSI Drivers Version: 2.5 KernelVersion: 2.6.24 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Other AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I've tried posting this on lkml usig two different domain addresses, but none got through... (too many capital letters in the subject?) Ah, well, here's the text: I am in need of setting CONFIG_SCSI_MULTI_LUN=y to access an SD(HC) slot on (iAudio) COWON D2 flash player, but doing so hangs my Nikon CoolPix 5600 _hard_ when connecting that to an USB slot for picture downloading. It is in fact so hard hung that the batteries must be removed to even turn the camera off. Bought the D2 last week, so don't know of a working kernel. Messages from working/non-working scenarios - not very useful. Holler if you want me to turn on debugging etc: _Working - # CONFIG_SCSI_MULTI_LUN is not set_ Jan 27 19:55:42 sleipner kernel: Time: acpi_pm clocksource has been installed. Jan 27 19:55:43 sleipner kernel: Clocksource tsc unstable (delta = -65041374 ns) Jan 27 19:57:25 sleipner kernel: usb 2-2: new full speed USB device using uhci_hcd and address 2 Jan 27 19:57:26 sleipner kernel: usb 2-2: configuration #1 chosen from 1 choice Jan 27 19:57:26 sleipner kernel: Initializing USB Mass Storage driver... Jan 27 19:57:26 sleipner kernel: scsi0 : SCSI emulation for USB Mass Storage devices Jan 27 19:57:26 sleipner kernel: usbcore: registered new interface driver usb-storage Jan 27 19:57:26 sleipner kernel: USB Mass Storage support registered. Jan 27 19:57:31 sleipner kernel: scsi 0:0:0:0: Direct-Access NIKONNIKON DSC E5600 1.00 PQ: 0 ANSI: 2 Jan 27 19:57:31 sleipner kernel: Driver 'sd' needs updating - please use bus_type methods Jan 27 19:57:31 sleipner kernel: sd 0:0:0:0: [sda] 1984000 512-byte hardware sectors (1016 MB) Jan 27 19:57:31 sleipner kernel: sd 0:0:0:0: [sda] Write Protect is off Jan 27 19:57:31 sleipner kernel: sd 0:0:0:0: [sda] 1984000 512-byte hardware sectors (1016 MB) Jan 27 19:57:31 sleipner kernel: sd 0:0:0:0: [sda] Write Protect is off Jan 27 19:57:31 sleipner kernel: sda: sda1 Jan 27 19:57:31 sleipner kernel: sd 0:0:0:0: [sda] Attached SCSI removable disk Jan 27 19:57:31 sleipner kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0 _Not working - CONFIG_SCSI_MULTI_LUN=y_ Jan 27 20:17:13 sleipner kernel: Time: acpi_pm clocksource has been installed. Jan 27 20:17:14 sleipner kernel: Clocksource tsc unstable (delta = -90855698 ns) Jan 27 20:19:06 sleipner kernel: usb 2-2: new full speed USB device using uhci_hcd and address 2 Jan 27 20:19:27 sleipner kernel: usb 2-2: new full speed USB device using uhci_hcd and address 3 Jan 27 20:19:57 sleipner kernel: usb 2-2: new full speed USB device using uhci_hcd and address 4 Jan 27 20:20:07 sleipner kernel: usb 2-2: new full speed USB device using uhci_hcd and address 5 That was really strange ---^ with all the usages. Nothing at all happens except for the camera dying. Forgot to check in kern.log, but an additional kernel with CONFIG_USB_DEVICE_CLASS=y at least finds the camera after ca 20 seconds, but can't really use it - and it's dead to the world: (This is from kern.log) Jan 27 20:27:54 sleipner kernel: Time: acpi_pm clocksource has been installed. Jan 27 20:27:55 sleipner kernel: Clocksource tsc unstable (delta = -86237258 ns) Jan 27 20:28:04 sleipner kernel: ath0: no IPv6 routers present Jan 27 20:29:23 sleipner kernel: usb 2-2: new full speed USB device using uhci_hcd and address 2 Jan 27 20:29:23 sleipner kernel: usb 2-2: configuration #1 chosen from 1 choice Jan 27 20:29:23 sleipner kernel: Initializing USB Mass Storage driver... Jan 27 20:29:23 sleipner kernel: scsi0 : SCSI emulation for USB Mass Storage devices Jan 27 20:29:23 sleipner kernel: usbcore: registered new interface driver usb-storage Jan 27 20:29:23 sleipner kernel: USB Mass Storage support registered. Jan 27 20:29:23 sleipner kernel: usb-storage: device found at 2 Jan 27 20:29:23 sleipner kernel: usb-storage: waiting for device to settle before scanning Jan 27 20:29:41 sleipner kernel: usb 2-2: usbfs: USBDEVFS_CONTROL failed cmd kio_kamera rqt 33 rq 102 len 0 ret -110 Jan 27 20:30:13 sleipner last message repeated 2 times -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 9775] HOST_MSG_LOOP invalid SCB ff
http://bugzilla.kernel.org/show_bug.cgi?id=9775 --- Comment #7 from [EMAIL PROTECTED] 2008-01-18 14:36 --- Duh! I mean boot with it off, power it up and rescan. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 9775] HOST_MSG_LOOP invalid SCB ff
http://bugzilla.kernel.org/show_bug.cgi?id=9775 --- Comment #6 from [EMAIL PROTECTED] 2008-01-18 14:35 --- Thanks, I've just done some more testing. There are no tapes in the drives. Normally, there is the L80 and a DLT8000 on channel B and a DLT8000 on channel A Both busses have external terminators. If Ch B is used alone the system is fine! If Ch A is used alone it will fail. If you you are thinking of some hardware problem, its possible to boot with the L80 off, cause the scsi bus to rescan and have everything work fine. Regards, john -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 9775] HOST_MSG_LOOP invalid SCB ff
http://bugzilla.kernel.org/show_bug.cgi?id=9775 --- Comment #5 from [EMAIL PROTECTED] 2008-01-18 14:27 --- Reply-To: [EMAIL PROTECTED] Latest working kernel version: Earliest failing kernel version: Distribution: Gentoo Hardware Environment: ML150G3, (2Core cpu, 64Bit) AHA3944AUWD card, Storagetek L80 +2x DLT8000 Software Environment: gentoo Problem Description: kernel panic Steps to reproduce: Panic if the L80 is powered up when the kernel boots. 100% on any failing kernel. Not all kernels fail but most do. Git Bisect across linus's tree did not produce a convincing patch. Originally filed here: http://bugs.gentoo.org/show_bug.cgi?id=200708 I have joined the linux-scsi list and will The event that brought the problem to light was the installation of a secondhand Storagetek L80 tape library. This has two DLT8000 drives on a HV-Differential bus. This needed special card, an adaptec 3944AUWD. The kernel I was running at that time was 2.6.22-gentoo-r8. It worked fine. Then when -r9 came out and this error manifested, the assumption was that -r9 was broken. I no longer think this to be the case. I think they are _ALL_ broken, possibly going way back toward the start of the 2.6 series. I think that the bug may or may not manifest depending on the internal layout of data in the kernel --A true heisenbug-- All that the git bisect did was to change the internal layout, not add/remove a bad patch. This explains why I could take the 2.6.23.8 kernel and compile for SMP and have it fail. Compile it for UP and have it work. Initially I thought that meant a locking or race issue. Now I think its was just another case of altering the internal kernel layout. Actually, I'd investigate either your tapes or the SCSI bus. The message is produced deep in the heart of the aic7xxx driver. It happens when the driver gets reselected with a tag that doesn't exist. However, in this case, I think your device is untagged, in which case this is some handling issue with SCB_LIST_NULL (the value 0xff). James -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 9734] New: I/O error when inserting a second firewire sata disk
http://bugzilla.kernel.org/show_bug.cgi?id=9734 Summary: I/O error when inserting a second firewire sata disk Product: IO/Storage Version: 2.5 KernelVersion: 2.6.24 rc7 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: SCSI AssignedTo: linux-scsi@vger.kernel.org ReportedBy: [EMAIL PROTECTED] Latest working kernel version: 2.6.18-5 (can't test any other kernel between 2.6.18-5 and 2.6.22-3 because aren't in the repo) Earliest failing kernel version: 2.6.22-3 Distribution: debian lenny 32bit AND 64 bit (it happens the same on both) Hardware Environment: ibm x3400 quad core 2GB ram type/number 7976-KBG bios version 1.56 http://www-03.ibm.com/systems/x/tower/x3400/specs.html cpu info: - http://www.pastebin.org/15078 lspci firewire: - http://www.pastebin.org/15081 lsmod: - http://www.pastebin.org/15083 Software Environment: bash Problem Description: We have a 64bit pci double firewire 800 port to which I attach 2 sata hdd (it doesn't matter the brand of the hdd. We tried many) Everything works well until we use only one disk. Connecting a second disk when we are working on the first one (i.e. writing to the first device) causes the interruption of the first job. once happened also a kernel freeze but we can't document and reproduce it right now. Steps to reproduce: We attach a sata disk to the first port of the pci firewire B controller 08:02.0 FireWire (IEEE 1394): Texas Instruments TSB82AA2 IEEE-1394b Link Layer Controller (rev 01) Jan 12 16:19:13 x3400 kernel: ieee1394: Error parsing configrom for node 1-00:1023 Jan 12 16:19:13 x3400 kernel: ieee1394: Node changed: 1-00:1023 - 1-01:1023 Jan 12 16:19:14 x3400 kernel: ieee1394: Node resumed: ID:BUS[1-00:1023] GUID[0030e002e0454697] Jan 12 16:19:14 x3400 kernel: scsi9 : SBP-2 IEEE-1394 Jan 12 16:19:15 x3400 kernel: ieee1394: sbp2: Logged into SBP-2 device Jan 12 16:19:15 x3400 kernel: ieee1394: Node 1-00:1023: Max speed [S800] - Max payload [4096] Jan 12 16:19:15 x3400 kernel: Vendor: WDC WD16 Model: 00JD-00HBC0 Rev: 08.0 Jan 12 16:19:15 x3400 kernel: Type: Direct-Access-RBC ANSI SCSI revision: 04 Jan 12 16:19:15 x3400 kernel: SCSI device sdc: 312579695 512-byte hdwr sectors (160041 MB) Jan 12 16:19:15 x3400 kernel: sdc: Write Protect is off Jan 12 16:19:15 x3400 kernel: sdc: Mode Sense: 11 00 00 00 Jan 12 16:19:15 x3400 kernel: SCSI device sdc: drive cache: write back Jan 12 16:19:15 x3400 kernel: SCSI device sdc: 312579695 512-byte hdwr sectors (160041 MB) Jan 12 16:19:15 x3400 kernel: sdc: Write Protect is off Jan 12 16:19:15 x3400 kernel: sdc: Mode Sense: 11 00 00 00 Jan 12 16:19:15 x3400 kernel: SCSI device sdc: drive cache: write back Jan 12 16:19:15 x3400 kernel: sdc: unknown partition table Jan 12 16:19:15 x3400 kernel: sd 9:0:0:0: Attached scsi disk sdc now we launch : dd if=/dev/zero of=/dev/sdc everything ok until now now we attach another sata disc to the second port of the pci firewire controller: Jan 12 16:20:09 x3400 kernel: ieee1394: Error parsing configrom for node 1-00:1023 Jan 12 16:20:09 x3400 kernel: ieee1394: Node changed: 1-00:1023 - 1-01:1023 Jan 12 16:20:09 x3400 kernel: ieee1394: Node changed: 1-01:1023 - 1-02:1023 Jan 12 16:20:10 x3400 kernel: ieee1394: Reconnected to SBP-2 device Jan 12 16:20:10 x3400 kernel: ieee1394: Node 1-01:1023: Max speed [S800] - Max payload [4096] using 2.6.18-5-686 everything works well dd still works now we disconnect the disk from the second port Jan 12 16:21:13 x3400 kernel: ieee1394: Node changed: 1-01:1023 - 1-00:1023 Jan 12 16:21:13 x3400 kernel: ieee1394: Node changed: 1-02:1023 - 1-01:1023 Jan 12 16:21:13 x3400 kernel: ieee1394: Reconnected to SBP-2 device Jan 12 16:21:13 x3400 kernel: ieee1394: Node 1-00:1023: Max speed [S800] - Max payload [4096] everything ok also disconnecting the second device --- now the same issue using 2.6.24-rc7-686: we attach a sata disk to the first port of the pci firewire B controller Jan 12 16:49:45 x3400 kernel: firewire_core: phy config: card 1, new root=ffc1, gap_count=5 Jan 12 16:49:46 x3400 kernel: scsi11 : SBP-2 IEEE-1394 Jan 12 16:49:46 x3400 kernel: firewire_core: created new fw device fw2 (2 config rom retries, S800) Jan 12 16:49:46 x3400 kernel: firewire_sbp2: logged in to fw2.0 LUN (0 retries) Jan 12 16:49:46 x3400 kernel: scsi 11:0:0:0: Direct-Access-RBC WDC WD16 00JD-00HBC0 08.0 PQ: 0 ANSI: 4 Jan 12 16:49:46 x3400 kernel: sd 11:0:0:0: [sdc] 312579695 512-byte hardware sectors (160041 MB) Jan 12 16:49:46 x3400 kernel: sd 11:0:0:0: [sdc] Write Protect is off Jan 12 16:49:46 x3400 kernel: sd 11:0:0:0: [sdc] Mode Sense: 11 00 00 00 Jan 12 16:49:46 x3400 kernel: sd 11:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Jan 12 16:49:46 x3400
[Bug 9734] I/O error when inserting a second firewire sata disk
http://bugzilla.kernel.org/show_bug.cgi?id=9734 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] AssignedTo|linux-scsi@vger.kernel.org |[EMAIL PROTECTED] ||bugs.osdl.org Component|SCSI|IEEE1394 Product|IO/Storage |Drivers Regression|0 |1 -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
