Re: arcmsr + archttp64 calls dma_free_coherent() with irqs disabled - dmesg filled with warnings
I assume you're aware that this patch is just a subset of commit
76d78300a6eb8 which you've already pushed up to Linus. Adding Nick Cheng
(commit author) to CC so that he can go over the feedback.
James Bottomley wrote:
diff --git a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
index f4a202e..4f9ff32 100644
--- a/drivers/scsi/arcmsr/arcmsr_hba.c
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c
@@ -1380,12 +1388,13 @@ static int arcmsr_iop_message_xfer(struct
AdapterControlBlock *acb, \
case ARCMSR_MESSAGE_READ_RQBUFFER: {
unsigned long *ver_addr;
- dma_addr_t buf_handle;
uint8_t *pQbuffer, *ptmpQbuffer;
int32_t allxfer_len = 0;
+ void *tmp;
- ver_addr = pci_alloc_consistent(acb->pdev, 1032, &buf_handle);
- if (!ver_addr) {
+ tmp = kmalloc(1032, GFP_KERNEL|GFP_DMA);
GFP_DMA is pretty pointless for a buffer which never actually gets anywhere
near a DMA, isn't it?
+ ver_addr = (unsigned long *)tmp;
No cast needed from void *
+ if (!tmp) {
retvalue = ARCMSR_MESSAGE_FAIL;
goto message_out;
}
@@ -1421,18 +1430,19 @@ static int arcmsr_iop_message_xfer(struct
AdapterControlBlock *acb, \
memcpy(pcmdmessagefld->messagedatabuffer, (uint8_t *)ver_addr,
allxfer_len);
pcmdmessagefld->cmdmessage.Length = allxfer_len;
pcmdmessagefld->cmdmessage.ReturnCode =
ARCMSR_MESSAGE_RETURNCODE_OK;
- pci_free_consistent(acb->pdev, 1032, ver_addr, buf_handle);
+ kfree(tmp);
}
break;
case ARCMSR_MESSAGE_WRITE_WQBUFFER: {
unsigned long *ver_addr;
- dma_addr_t buf_handle;
int32_t my_empty_len, user_len, wqbuf_firstindex,
wqbuf_lastindex;
uint8_t *pQbuffer, *ptmpuserbuffer;
+ void *tmp;
- ver_addr = pci_alloc_consistent(acb->pdev, 1032, &buf_handle);
- if (!ver_addr) {
+ tmp = kmalloc(1032, GFP_KERNEL|GFP_DMA);
Actually, also all the code around here implies we're in atomic context,
so that GFP_KERNEL can't be right either.
Further confirmed by the fact that dma_free_coherent() was complaining
about IRQs being disabled.
-
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
Re: USB regression (and other failures) in 2.6.2[45]*
add CC (Andrew, Greg and linux-usb) On 2/15/08, Andrew Buehler <[EMAIL PROTECTED]> wrote: > In my workplace, I use a customized version of Novell's ZENworks imaging > boot CD, which is based off of Linux. I have one particular model of > laptop - the IBM/Lenovo R61 - on which three different things fail > completely in current kernels (tested with 2.6.24.2 and 2.6.25-rc1): > USB, AHCI (and thus access to the SATA drive), and networking. As a > consequence of all three failing in parallel, I have no practical way to > get logs and other information off of the machine to help with tracking > down the bugs. > > I am primarily concerned about the AHCI and networking issues, since > they are what need to be working in order for us to do what we need to > with these boot discs and these laptops. However, I intend to focus on > the USB issue first, because it seems slightly more tractable and fixing > it would allow me to reliably get logs off of the computer so as to > provide information to help track down and fix the other problems. > > Specifically, the USB issue is more tractable in that I have found one > narrow set of circumstances in which I *can* get it to work, and so have > been able to obtain an lspci log and a dmesg log from the failing > laptop. I seem to remember the lkml FAQ advising not to simply attach > such files unsolicited, so I have not provided them here, but I am more > than willing to send them (and the matching .config file) along upon > request. Instead, I will do my best to summarize the errors as I have > observed them, though that best may be somewhat poor. In the following, > unless explicitly specified, I am using 2.6.25-rc1, simply because I > expect that it will be more likely to get attention and fixes than > earlier (released) versions. > > > Early in the boot process, immediately after the 'io scheduler foobar > registered' lines, the message > > > :00:1a.7 EHCI: BIOS handoff failed (BIOS bug?) 01010001 > > > appears twice. Despite the parenthetical suggestion, I do not believe > that the problem could be a bug in the BIOS, because Windows is able to > access all of the hardware on these laptops - including USB devices, > which is what I understand EHCI to involve - without the slightest > difficulty. > > If there is no USB Flash drive is connected during the boot process, > there are no further apparently-USB-related errors during boot that I > can recognize, and various messages about USB host controllers being > detected appear; they seem to be perfectly normal. When the boot process > completes, connecting such a drive produces no visible response > whatsoever. > > If on the other hand there *is* a USB Flash drive connected during the > boot process, there are many other USB-related messages, some of which > appear to be errors. I am not certain which are in fact relevant, and > would prefer not to simply copy-and-paste blindly from the log; if the > information is necessary, I would prefer to simply provide the entire > log rather than risk missing something important. However, when the boot > process is done and the usb-storage module is loaded, the drive is in > fact recognized and can be mounted, though it is very slow to respond; > in my one test it took ~20+ seconds to mount the drive (512MB, vfat), an > unmeasured but quite long time to dump dmesg into a file on that drive, > a barely noticeable but still present blink to copy /proc/config.gz to > the drive, and four seconds to unmount afterwards. > > > For reference, I have on hand a version of this same boot disc built > using kernel 2.6.23.1, which does not produce the EHCI errors, and on > which the USB drive is usable in exactly the way I expect from a Linux > system. I have not made a significant attempt to narrow down the point > at which the functionality broke, but I can do so if desired, though it > will take some time - the more so as I can test this only while at work, > and am facing an impending three-day weekend. > > (I do not have a working git environment, and do not understand well how > to set one up, as the mechanics and to some extent the interface > semantics of git seem to be rather different from those of any VCS with > which I am familiar. That is, however, the only reason - aside from the > time involved - why I would be unwilling to track down the exact change > which caused the regression.) > > I am quite certain that I have not provided enough information to > address the problem. Please let me know what would be necessary, and I > will do my best to provide it. Additionally, if I have made any major > flubs (of etiquette or otherwise), please do point them out so that I > can avoid them in future. > > -- > Andrew Buehler > -- > 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 FAQ at http://www.tux.org/lkml/ >
Re: arcmsr + archttp64 calls dma_free_coherent() with irqs disabled - dmesg filled with warnings
On Sat, 2008-02-16 at 11:49 +, Daniel Drake wrote: > I assume you're aware that this patch is just a subset of commit > 76d78300a6eb8 which you've already pushed up to Linus. Adding Nick Cheng > (commit author) to CC so that he can go over the feedback. Well, in case it's not obvious by now: The way to get bad code upstream is to send a patch that combines many changes (the more the better) so that any potential reviewer has no idea which change is meant by which hunk and then to make sure Andrew picks it up so he'll hound the subsystem Maintainer until it's applied. Best of all, mention that it fixes a bug and you're made. In this case, the problems with the changes weren't obvious to me until I saw the broken out diff for the backport. (And incidentally, never send URLs to code; 95% of people don't click on them. If you inline the code, most people at least glance over it). The odd thing is, it should have triggered a might_sleep() warning under testing ... do you know why it didn't? James - 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
Re: [PATCH 11/9 update] firewire: fw-sbp2: enforce a retry of __scsi_add_device if bus generation changed
Jarod Wilson wrote on 2008-02-10: > Now *this* does the trick. I get the 'READ CAPACITY failed' as before, > then 'firewire_sbp2: fw1.0: error status: 0:4', followed by a new login and > SCSI probe, both of which are successful this time, disk is available for use > and all that good stuff. FYI, I now committed this patch to linux1394-2.6.git after folding patch "firewire: fw-sbp2: retry login if scsi_device was offlined early" into it. -- Stefan Richter -=-==--- --=- = http://arcgraph.de/sr/ - 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
[PATCH] scsi_debug: disable clustering
From: FUJITA Tomonori <[EMAIL PROTECTED]>
Subject: [PATCH] scsi_debug: disable clustering
scsi_debug does at several places:
for_each_sg(sdb->table.sgl, sg, sdb->table.nents, k) {
kaddr = (unsigned char *)
kmap_atomic(sg_page(sg), KM_USER0);
We cannot do something like that with the clustering enabled (or we
can use scsi_kmap_atomic_sg).
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
drivers/scsi/scsi_debug.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
index 1541c17..d1777a9 100644
--- a/drivers/scsi/scsi_debug.c
+++ b/drivers/scsi/scsi_debug.c
@@ -222,7 +222,7 @@ static struct scsi_host_template sdebug_driver_template = {
.cmd_per_lun = 16,
.max_sectors = 0x,
.unchecked_isa_dma =0,
- .use_clustering = ENABLE_CLUSTERING,
+ .use_clustering = DISABLE_CLUSTERING,
.module = THIS_MODULE,
};
--
1.5.3.7
-
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
Re: USB regression (and other failures) in 2.6.2[45]*
On Sat, 16 Feb 2008, Oliver Pinter wrote: > On 2/15/08, Andrew Buehler <[EMAIL PROTECTED]> wrote: > > In my workplace, I use a customized version of Novell's ZENworks imaging > > boot CD, which is based off of Linux. I have one particular model of > > laptop - the IBM/Lenovo R61 - on which three different things fail > > completely in current kernels (tested with 2.6.24.2 and 2.6.25-rc1): > > USB, AHCI (and thus access to the SATA drive), and networking. As a > > consequence of all three failing in parallel, I have no practical way to > > get logs and other information off of the machine to help with tracking > > down the bugs. ... To make a long story short, the USB symptoms you describe indicate a problem with interrupt routing. This could well explain the other difficulties too. There are various kernel parameters you can try putting on the boot command line to work around it: acpi=noirq or acpi=off or pci=noacpi or a few others. Alan Stern - 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
Re: [PATCH] 2.6.25-rc1-git2: GDT SCSI: change drivers/scsi/gdth.c into using pci_get device
On Wed, Feb 13, 2008 at 10:57:37AM +0200, Boaz Harrosh wrote: > I still don't have a card for testing myself. Again anyone > wants to send me a card. Intel people anybody home? Apparently Intel sold this line of cards to Adaptec. The copyright notice in the file backs this up: * Copyright (C) 1995-06 ICP vortex GmbH, Achim Leubner * * Copyright (C) 2002-04 Intel Corporation * * Copyright (C) 2003-06 Adaptec Inc. * * <[EMAIL PROTECTED]> * -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." - 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
Re: USB regression (and other failures) in 2.6.2[45]*
On Sat, 16 Feb 2008, Andrew Buehler wrote: > (Note: I consider it blatantly incorrect to send a reply both to a > mailing list and directly to the address of someone who is subscribed to > that list unless you have reason to believe that that someone will not > see the message otherwise, but in this case I am doing so anyway because > I see no way to avoid it and still make sure all relevant people receive > the message.) I (and a lot of other people as well, to judge by the email I receive) don't think this is incorrect. For one thing, it's not always possible to tell whether or not the recipient is subscribed to any of the lists. For another, getting two copies of a message is no big deal -- more irritating (IMO) is getting a rejection message as a result of replying to message which was cross-posted to a closed list. But in each case, hitting the "d" key will delete the unwanted message. In fact, the thing that bothers me the most is when people reply to a long email with just a few lines of new text but don't bother to prune the long message down to its essential parts. This forces me to read through hundreds of lines containing nothing new or of interest in order to obtain a minimal amount of useful information. > On 2/16/2008 10:20 AM, Alan Stern wrote: > > To make a long story short, the USB symptoms you describe indicate a > > problem with interrupt routing. This could well explain the other > > difficulties too. There are various kernel parameters you can try > > putting on the boot command line to work around it: acpi=noirq or > > acpi=off or pci=noacpi or a few others. > > I have now tried all three of these, with no apparent effect; the USB > drive is still not detected when plugged in after boot. A naive search > on Google provides no indication of other possible parameters to try; > the only list I have found of ACPI-related kernel parameters includes no > others which seem likely to be helpful without more knowledge of the > specifics of the situation (and the subsystem) than I have. > > What would the next step be? People on LKML who are more familiar with interrupt routing problems might be able to offer more help. For now, you can try things like turning on CONFIG_USB_DEBUG, posting the output from dmesg, posting the contents of /proc/interrupts (say before and after a new USB device is plugged in). Assuming that the 2.6.23 kernel works on your computer, you can go the extreme route of installing git and doing a bisection to find the first patch causing your difficulty. Alan Stern - 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
Re: USB regression (and other failures) in 2.6.2[45]*
(Note: I consider it blatantly incorrect to send a reply both to a mailing list and directly to the address of someone who is subscribed to that list unless you have reason to believe that that someone will not see the message otherwise, but in this case I am doing so anyway because I see no way to avoid it and still make sure all relevant people receive the message.) On 2/16/2008 10:20 AM, Alan Stern wrote: On Sat, 16 Feb 2008, Oliver Pinter wrote: On 2/15/08, Andrew Buehler <[EMAIL PROTECTED]> wrote: In my workplace, I use a customized version of Novell's ZENworks imaging boot CD, which is based off of Linux. I have one particular model of laptop - the IBM/Lenovo R61 - on which three different things fail completely in current kernels (tested with 2.6.24.2 and 2.6.25-rc1): USB, AHCI (and thus access to the SATA drive), and networking. As a consequence of all three failing in parallel, I have no practical way to get logs and other information off of the machine to help with tracking down the bugs. ... To make a long story short, the USB symptoms you describe indicate a problem with interrupt routing. This could well explain the other difficulties too. There are various kernel parameters you can try putting on the boot command line to work around it: acpi=noirq or acpi=off or pci=noacpi or a few others. I have now tried all three of these, with no apparent effect; the USB drive is still not detected when plugged in after boot. A naive search on Google provides no indication of other possible parameters to try; the only list I have found of ACPI-related kernel parameters includes no others which seem likely to be helpful without more knowledge of the specifics of the situation (and the subsystem) than I have. What would the next step be? -- Andrew Buehler - 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
Re: USB regression (and other failures) in 2.6.2[45]*
On Sat, 16 Feb 2008, Andrew Buehler wrote: > > For another, getting two copies of a message is no big deal -- > > I disagree. Everyone has his own taste. Obviously there's no world-wide consensus, possibly because different people have different workflow habits and so are affected by duplicate messages to varying extents. > When I receive a message sent directly to me in a discussion which is on > a list, I expect that it is because someone either considered it > important enough to warrant making certain it came to my attention > specifically, or wanted to continue the discussion but felt that it > should not continue to take place on the mailing list. Sometimes that is the case but often it isn't. Your expectations are at variance with other people's behavior; you shouldn't expect everyone else to change just to match your personal ideals. On the other hand, I would be perfectly happy to edit your name out of the reply list -- but since you said you aren't receiving all the messages in this thread via the list that might not be a good thing to do at the moment... > > People on LKML who are more familiar with interrupt routing problems > > might be able to offer more help. For now, you can try things like > > turning on CONFIG_USB_DEBUG, posting the output from dmesg, posting > > the contents of /proc/interrupts (say before and after a new USB > > device is plugged in). > > In my current testing kernel, which I believe is the one with which I > captured the sole successful non-2.6.23.1 dmesg so far, CONFIG_USB_DEBUG > is on. The associated dmesg (obtained yesterday from booting with the > Flash drive connected) is attached. (The flood of 'no version magic, > tainting kernel' messages between line 600 and line 1160 are a side > effect of Novell's custom environment which I have not yet made the > effort to fix; the boot scripts attempt to detect the network card by > modprobing every network driver available until they find one which > works. Here, because the correct one fails, they wind up trying each one > twice.) The line saying: > ehci_hcd :00:1d.7: Unlink after no-IRQ? Controller is probably using the > wrong IRQ. is an indication that interrupt routing is indeed not working right. Or possibly your EHCI controller isn't working. You could try blacklisting or unloading ehci-hcd to see if that helps. Of course then none of your USB devices would be able to run at high speed. > I have transcribed the contents of /proc/interrupts both before and > after plugging in the Flash drive I have been using for testing, and > they are also attached. I have been as careful as I could to be sure > that the contents of the attached 'r61-interrupts-[12].txt' files is the > same as what was shown on the laptop, but cannot absolutely guarantee > that I have not missed something. For the record, the '1' is from before > connecting the drive, and the '2' is from after. Notice that the interrupt count for IRQ 11 doesn't change when you plug in the device. Obviously something is wrong there. In fact, it's a little surprising that almost all the USB controllers are routed to the same IRQ. However this is beyond my area of expertise. You could try posting a message on the linux-acpi mailing list; the people there should know a lot more about these issues. > > Assuming that the 2.6.23 kernel works on your computer, you can go > > the extreme route of installing git and doing a bisection to find the > > first patch causing your difficulty. > > That would require me to learn enough of how git works, as distinct from > more traditional VCSes, to be able to use it with some confidence. This > is not impossible - indeed I want to do it at some point - but for the > time being I have no idea where to start, and indeed I am not especially > clear on exactly what (from a user's perspective) the differences been > git and e.g. CVS or Subversion are. I know that the entire concept > relies around a lack of centralization, but I have not been able to get > my head around what that means in a practical sense. There are some excellent tutorials on the web, with detailed explanations of how to do a bisection to track down a kernel bug. Alan Stern - 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
Re: arcmsr + archttp64 calls dma_free_coherent() with irqs disabled - dmesg filled with warnings
James Bottomley wrote: On Sat, 2008-02-16 at 11:49 +, Daniel Drake wrote: I assume you're aware that this patch is just a subset of commit 76d78300a6eb8 which you've already pushed up to Linus. Adding Nick Cheng (commit author) to CC so that he can go over the feedback. Well, in case it's not obvious by now: The way to get bad code upstream is to send a patch that combines many changes (the more the better) so that any potential reviewer has no idea which change is meant by which hunk and then to make sure Andrew picks it up so he'll hound the subsystem Maintainer until it's applied. Best of all, mention that it fixes a bug and you're made. Sorry, I didn't mean to sound that as a criticism. I'm sure you have a lot of patches flowing by you at any one time. Here is a patch to address your comments. Joshua, would you mind testing this before I submit it properly? It will apply cleanly to 2.6.24 on top of the previous patch you tested. I have compile-tested it. The odd thing is, it should have triggered a might_sleep() warning under testing ... do you know why it didn't? No, and I can see that scsi_dispatch_command does invoke ->queuecommand under a spinlock so it must be atomic context... I'm not sure which might_sleep() codepath you are looking at though. At a guess it depends on SLUB vs SLAB? Daniel - 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
Re: arcmsr + archttp64 calls dma_free_coherent() with irqs disabled - dmesg filled with warnings
Daniel Drake wrote:
Here is a patch to address your comments.
Joshua, would you mind testing this before I submit it properly? It will
apply cleanly to 2.6.24 on top of the previous patch you tested. I have
compile-tested it.
It would help to include the patch.
>From 0a9cd6133fe4f0c3a8906d6be1b9d1ef083345dc Mon Sep 17 00:00:00 2001
From: Daniel Drake <[EMAIL PROTECTED]>
Date: Sat, 16 Feb 2008 23:25:02 +
Subject: [PATCH] arcmsr: fix message allocation
---
drivers/scsi/arcmsr/arcmsr_hba.c | 26 +++---
1 files changed, 11 insertions(+), 15 deletions(-)
diff --git a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
index 4f9ff32..f91f79c 100644
--- a/drivers/scsi/arcmsr/arcmsr_hba.c
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c
@@ -1387,18 +1387,16 @@ static int arcmsr_iop_message_xfer(struct
AdapterControlBlock *acb, \
switch(controlcode) {
case ARCMSR_MESSAGE_READ_RQBUFFER: {
- unsigned long *ver_addr;
+ unsigned char *ver_addr;
uint8_t *pQbuffer, *ptmpQbuffer;
int32_t allxfer_len = 0;
- void *tmp;
- tmp = kmalloc(1032, GFP_KERNEL|GFP_DMA);
- ver_addr = (unsigned long *)tmp;
- if (!tmp) {
+ ver_addr = kmalloc(1032, GFP_ATOMIC);
+ if (!ver_addr) {
retvalue = ARCMSR_MESSAGE_FAIL;
goto message_out;
}
- ptmpQbuffer = (uint8_t *) ver_addr;
+ ptmpQbuffer = ver_addr;
while ((acb->rqbuf_firstindex != acb->rqbuf_lastindex)
&& (allxfer_len < 1031)) {
pQbuffer = &acb->rqbuffer[acb->rqbuf_firstindex];
@@ -1427,26 +1425,24 @@ static int arcmsr_iop_message_xfer(struct
AdapterControlBlock *acb, \
}
arcmsr_iop_message_read(acb);
}
- memcpy(pcmdmessagefld->messagedatabuffer, (uint8_t *)ver_addr,
allxfer_len);
+ memcpy(pcmdmessagefld->messagedatabuffer, ver_addr,
allxfer_len);
pcmdmessagefld->cmdmessage.Length = allxfer_len;
pcmdmessagefld->cmdmessage.ReturnCode =
ARCMSR_MESSAGE_RETURNCODE_OK;
- kfree(tmp);
+ kfree(ver_addr);
}
break;
case ARCMSR_MESSAGE_WRITE_WQBUFFER: {
- unsigned long *ver_addr;
+ unsigned char *ver_addr;
int32_t my_empty_len, user_len, wqbuf_firstindex,
wqbuf_lastindex;
uint8_t *pQbuffer, *ptmpuserbuffer;
- void *tmp;
- tmp = kmalloc(1032, GFP_KERNEL|GFP_DMA);
- ver_addr = (unsigned long *)tmp;
- if (!tmp) {
+ ver_addr = kmalloc(1032, GFP_ATOMIC);
+ if (!ver_addr) {
retvalue = ARCMSR_MESSAGE_FAIL;
goto message_out;
}
- ptmpuserbuffer = (uint8_t *)ver_addr;
+ ptmpuserbuffer = ver_addr;
user_len = pcmdmessagefld->cmdmessage.Length;
memcpy(ptmpuserbuffer, pcmdmessagefld->messagedatabuffer,
user_len);
wqbuf_lastindex = acb->wqbuf_lastindex;
@@ -1492,7 +1488,7 @@ static int arcmsr_iop_message_xfer(struct
AdapterControlBlock *acb, \
retvalue = ARCMSR_MESSAGE_FAIL;
}
}
- kfree(tmp);
+ kfree(ver_addr);
}
break;
--
1.5.4
Re: USB regression (and other failures) in 2.6.2[45]*
On 2/16/2008 6:11 PM, Alan Stern wrote: On Sat, 16 Feb 2008, Andrew Buehler wrote: For another, getting two copies of a message is no big deal -- I disagree. Everyone has his own taste. Obviously there's no world-wide consensus, possibly because different people have different workflow habits and so are affected by duplicate messages to varying extents. I am well aware that this particular point is opinion. I have had justifications for and arguments in favor of it in the past, but none of them come readily to mind at the moment, except for the one gone over briefly below. When I receive a message sent directly to me in a discussion which is on a list, I expect that it is because someone either considered it important enough to warrant making certain it came to my attention specifically, or wanted to continue the discussion but felt that it should not continue to take place on the mailing list. Sometimes that is the case but often it isn't. Your expectations are at variance with other people's behavior; you shouldn't expect everyone else to change just to match your personal ideals. Messages sent to my address directly are explicitly not filtered into the folders I have set up for various mailing lists, so that if someone does send me a "heads up" reply for a specific topic on a list to which I am subscribed it does not get caught by the list filter and fail to come to my attention. If a message fails to be filtered into any mailing-list folder, then I should be able to conclude that it is specifically intended for me, and not part of normal mailing-list traffic. The practice of sending replies to both addresses renders this an invalid conclusion. I do not think that it is unreasonable to expect that conclusion to be valid. On the other hand, I would be perfectly happy to edit your name out of the reply list -- but since you said you aren't receiving all the messages in this thread via the list that might not be a good thing to do at the moment... It's not that I'm not receiving all of this thread's messages via the list - it's that I'm not receiving *any* of them via the list, and I suspect that the reason is that my address is in both the To:/Cc: and the list itself. Something is filtering it such that I do not receive "duplicate" replies in this way, but it is doing so by filtering out the list copy rather than the direct copy. I have seen mailing lists which do this before, but I see no other indication that the LKML is one of them, and I would not be in the least surprised if this turned out to be yet one more problem with gmail. As far as I am aware, I am seeing all messages posted to the list which do not have me in To: or Cc:. I suspect that if a reply in this thread were posted to the list but not sent to me, I would see it on the list. It might be worth an experiment, but since it would increase traffic for other list members to no purpose it is probably not worth it overall. People on LKML who are more familiar with interrupt routing problems might be able to offer more help. For now, you can try things like turning on CONFIG_USB_DEBUG, posting the output from dmesg, posting the contents of /proc/interrupts (say before and after a new USB device is plugged in). In my current testing kernel, which I believe is the one with which I captured the sole successful non-2.6.23.1 dmesg so far, CONFIG_USB_DEBUG is on. The associated dmesg (obtained yesterday from booting with the Flash drive connected) is attached. (The flood of 'no version magic, tainting kernel' messages between line 600 and line 1160 are a side effect of Novell's custom environment which I have not yet made the effort to fix; the boot scripts attempt to detect the network card by modprobing every network driver available until they find one which works. Here, because the correct one fails, they wind up trying each one twice.) The line saying: ehci_hcd :00:1d.7: Unlink after no-IRQ? Controller is probably using the wrong IRQ. is an indication that interrupt routing is indeed not working right. Or possibly your EHCI controller isn't working. You could try blacklisting or unloading ehci-hcd to see if that helps. Of course then none of your USB devices would be able to run at high speed. ehci-hcd is not modular in my current kernel, and if there is a way to turn it off without its being modular I am not aware of it. I will have to jump through a few hoops to be able to obtain a copy of the boot CD with an updated kernel while not at work, but I will try to do so sometime tomorrow. In practical terms, I am frankly not especially bothered by the lack of support for high-speed USB in Linux on this machine; the primary reason I am interested in USB there at the moment, aside from a general philosophy of "unsupported devices are bad and anything I can do to help them become supported is good", is because getting it working would allow me to easily get the necessary information out to be able to prop
Re: arcmsr + archttp64 calls dma_free_coherent() with irqs disabled - dmesg filled with warnings
Thanks James. I'll give a try tonight or tomorrow.
-J
--
On Sat, Feb 16, 2008 at 11:37:41PM +, Daniel Drake wrote:
> Daniel Drake wrote:
>> Here is a patch to address your comments.
>> Joshua, would you mind testing this before I submit it properly? It will
>> apply cleanly to 2.6.24 on top of the previous patch you tested. I have
>> compile-tested it.
>
> It would help to include the patch.
> >From 0a9cd6133fe4f0c3a8906d6be1b9d1ef083345dc Mon Sep 17 00:00:00 2001
> From: Daniel Drake <[EMAIL PROTECTED]>
> Date: Sat, 16 Feb 2008 23:25:02 +
> Subject: [PATCH] arcmsr: fix message allocation
>
> ---
> drivers/scsi/arcmsr/arcmsr_hba.c | 26 +++---
> 1 files changed, 11 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/scsi/arcmsr/arcmsr_hba.c
> b/drivers/scsi/arcmsr/arcmsr_hba.c
> index 4f9ff32..f91f79c 100644
> --- a/drivers/scsi/arcmsr/arcmsr_hba.c
> +++ b/drivers/scsi/arcmsr/arcmsr_hba.c
> @@ -1387,18 +1387,16 @@ static int arcmsr_iop_message_xfer(struct
> AdapterControlBlock *acb, \
> switch(controlcode) {
>
> case ARCMSR_MESSAGE_READ_RQBUFFER: {
> - unsigned long *ver_addr;
> + unsigned char *ver_addr;
> uint8_t *pQbuffer, *ptmpQbuffer;
> int32_t allxfer_len = 0;
> - void *tmp;
>
> - tmp = kmalloc(1032, GFP_KERNEL|GFP_DMA);
> - ver_addr = (unsigned long *)tmp;
> - if (!tmp) {
> + ver_addr = kmalloc(1032, GFP_ATOMIC);
> + if (!ver_addr) {
> retvalue = ARCMSR_MESSAGE_FAIL;
> goto message_out;
> }
> - ptmpQbuffer = (uint8_t *) ver_addr;
> + ptmpQbuffer = ver_addr;
> while ((acb->rqbuf_firstindex != acb->rqbuf_lastindex)
> && (allxfer_len < 1031)) {
> pQbuffer = &acb->rqbuffer[acb->rqbuf_firstindex];
> @@ -1427,26 +1425,24 @@ static int arcmsr_iop_message_xfer(struct
> AdapterControlBlock *acb, \
> }
> arcmsr_iop_message_read(acb);
> }
> - memcpy(pcmdmessagefld->messagedatabuffer, (uint8_t *)ver_addr,
> allxfer_len);
> + memcpy(pcmdmessagefld->messagedatabuffer, ver_addr,
> allxfer_len);
> pcmdmessagefld->cmdmessage.Length = allxfer_len;
> pcmdmessagefld->cmdmessage.ReturnCode =
> ARCMSR_MESSAGE_RETURNCODE_OK;
> - kfree(tmp);
> + kfree(ver_addr);
> }
> break;
>
> case ARCMSR_MESSAGE_WRITE_WQBUFFER: {
> - unsigned long *ver_addr;
> + unsigned char *ver_addr;
> int32_t my_empty_len, user_len, wqbuf_firstindex,
> wqbuf_lastindex;
> uint8_t *pQbuffer, *ptmpuserbuffer;
> - void *tmp;
>
> - tmp = kmalloc(1032, GFP_KERNEL|GFP_DMA);
> - ver_addr = (unsigned long *)tmp;
> - if (!tmp) {
> + ver_addr = kmalloc(1032, GFP_ATOMIC);
> + if (!ver_addr) {
> retvalue = ARCMSR_MESSAGE_FAIL;
> goto message_out;
> }
> - ptmpuserbuffer = (uint8_t *)ver_addr;
> + ptmpuserbuffer = ver_addr;
> user_len = pcmdmessagefld->cmdmessage.Length;
> memcpy(ptmpuserbuffer, pcmdmessagefld->messagedatabuffer,
> user_len);
> wqbuf_lastindex = acb->wqbuf_lastindex;
> @@ -1492,7 +1488,7 @@ static int arcmsr_iop_message_xfer(struct
> AdapterControlBlock *acb, \
> retvalue = ARCMSR_MESSAGE_FAIL;
> }
> }
> - kfree(tmp);
> + kfree(ver_addr);
> }
> break;
>
> --
> 1.5.4
>
-
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
Re: USB regression (and other failures) in 2.6.2[45]*
On Sat, 16 Feb 2008, Andrew Buehler wrote: > Messages sent to my address directly are explicitly not filtered into > the folders I have set up for various mailing lists, so that if someone > does send me a "heads up" reply for a specific topic on a list to which > I am subscribed it does not get caught by the list filter and fail to > come to my attention. If a message fails to be filtered into any > mailing-list folder, then I should be able to conclude that it is > specifically intended for me, and not part of normal mailing-list > traffic. The practice of sending replies to both addresses renders this > an invalid conclusion. I do not think that it is unreasonable to expect > that conclusion to be valid. It's not unreasonable. Neither is Aristotelian physics. Nevertheless, neither one is a good match to reality. Why not arrange instead that messages sent from a mailing list server _do_ get filtered into the corresponding folder, even if they were also sent to your address? This certainly should make your assumption (that messages not filtered into any mailing-list folder are specifically intended for you) much more valid than it is now. > It's not that I'm not receiving all of this thread's messages via the > list - it's that I'm not receiving *any* of them via the list, and I > suspect that the reason is that my address is in both the To:/Cc: and > the list itself. Something is filtering it such that I do not receive > "duplicate" replies in this way, but it is doing so by filtering out the > list copy rather than the direct copy. I have seen mailing lists which > do this before, but I see no other indication that the LKML is one of > them, and I would not be in the least surprised if this turned out to be > yet one more problem with gmail. Well, I _am_ receiving your messages by way of linux-usb as well as directly, for whatever that's worth. > > is an indication that interrupt routing is indeed not working right. > > Or possibly your EHCI controller isn't working. You could try > > blacklisting or unloading ehci-hcd to see if that helps. Of course > > then none of your USB devices would be able to run at high speed. > > ehci-hcd is not modular in my current kernel, and if there is a way to > turn it off without its being modular I am not aware of it. Go into the /sys/bus/pci/drivers/ehci_hcd directory. Then for each symbolic link to a controller device listed there, write the device's name (with "echo -n") to the "unbind" file. For example, echo -n :00:1d.7 >unbind That will have nearly the same effect as unloading ehci-hcd. > Until this thread, I was not even aware that ACPI was related to USB; I > had largely conflated it with a similar acronym which I think is related > to power management and which I can suddenly not even find in my kernel > config. I will, however, look into linux-acpi. ACPI isn't directly related to USB; rather it has to do with transferring information between the OS and the BIOS/vendor-specific-hardware. Power management is example where such a transfer is needed. In your case, the relevant information is which IRQ is connected to which motherboard device. If you don't have ACPI enabled in your configuration, then perhaps that's the problem -- try enabling it. > That will not be helpful for the other two problems, however, since > neither of them was ever working as far as I am aware. That also leaves > me hesitant to conclude that they are rooted in the same IRQ issue as > the USB problem appears to be. Maybe they aren't. But when you have multiple bugs, you have to fix them one at a time. > Which lists or other addresses would be appropriate for reporting > problems with AHCI/libata and with networking, specifically with the > e1000/e1000e drivers? I see a mailing list for e1000 in MAINTAINERS, but > only the maintainer's address for SATA/libata/whatever else may be > involved there, and I am reflexively reluctant to bother a maintainer > directly with as little information as I presently have. I don't know, but you should wait until the simpler problem is sorted out before tackling the more complicated ones. Alan Stern - 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
[OT] GMail (was USB regression (and other failures)...)
On Sat, Feb 16, 2008 at 08:12:40PM -0500, Andrew Buehler wrote: > [...] and I would not be in the least surprised if this turned out to > be yet one more problem with gmail It is; Gmail will refuse to POP more than one copy of a mail to you, no matter how many copies it recieves via different paths. Which copy you get seems to be dependant on which arrives first, so you can't even hope a mail exchange will consistently arrive in one mailbox or another. Note that this also applies to mails cross-posted to multiple lists you maybe be suscribed to; this breaks threading fantastically. Google is aware of the issue, and considers it a feature. If you find another free mail service which isn't so broken, I'd love to hear about it. --- That said, netiquette on the kernel lists is to *never* drop CC's. Too much traffic crosses the lists for anyone to read it all and note anything they might be interested and/or implicated in. Never dropping CC's allows busy people to keep track of conversations they've taken part in or that someone thinks they should see without the worry of missing any important parts of one. Or at least it does if your mail system isn't broken. We get what we pay for. :-/ -- Joseph Fannin [EMAIL PROTECTED] - 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
Re: [PATCH] scsi_debug: disable clustering
FUJITA Tomonori wrote:
From: FUJITA Tomonori <[EMAIL PROTECTED]>
Subject: [PATCH] scsi_debug: disable clustering
scsi_debug does at several places:
for_each_sg(sdb->table.sgl, sg, sdb->table.nents, k) {
kaddr = (unsigned char *)
kmap_atomic(sg_page(sg), KM_USER0);
We cannot do something like that with the clustering enabled (or we
can use scsi_kmap_atomic_sg).
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
Thanks, Tomo.
Signed-off-by: Douglas Gilbert <[EMAIL PROTECTED]>
---
drivers/scsi/scsi_debug.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
index 1541c17..d1777a9 100644
--- a/drivers/scsi/scsi_debug.c
+++ b/drivers/scsi/scsi_debug.c
@@ -222,7 +222,7 @@ static struct scsi_host_template sdebug_driver_template = {
.cmd_per_lun = 16,
.max_sectors = 0x,
.unchecked_isa_dma =0,
- .use_clustering = ENABLE_CLUSTERING,
+ .use_clustering = DISABLE_CLUSTERING,
.module = THIS_MODULE,
};
-
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
Re: USB regression (and other failures) in 2.6.2[45]*
Andrew wrote: > (Note: I consider it blatantly incorrect to send a reply both to a > mailing list and directly to the address of someone who is subscribed to > that list Regardless of how you consider it, that is how responding to these big lists -must- work. There is no practical way for respondents to know, without spending at a minimum several minutes of their time per reply, whether or not the explicit receipients of a message are or are not also on one or more of the receiving lists. Do you really expect, Andrew, that I should examine the membership lists of each of linux-scsi, linux-usb and linux-kernel (if they are even open to the public) to see if you're subscribed to them, before responding to a message addressed such as this? As subscribers and submitters to such lists, we just have to learn to deal with this reality. For example, I receive an average of a 100 messages per hour on this email address, -after- my employers spam filters have knocked off over 90% of the incoming. May I recommend you become an expert in procmail? That or speed reading (and speed ignoring ;). In a separate reply to this message, Alan Stern wrote: > Everyone has his own taste. This is not a matter of taste on these big lists. There is no other practical alternative. Most of the burden of ultimate filtering must be shifted to the recipients, and the senders asked only that they err on the side of including every individual list or person already on the address lists. Joseph Fannin also replied: > another free mail service which isn't so broken, I'd recommend fastmail.fm as one of the least broken, most tech savvy mail services. I believe that their free side includes IMAP, though not POP support. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.940.382.4214 - 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
