Re: Incorrect driver getting loaded for Qlogic FC-HBA
> > > A similar problem was noted with RHEL4, it seems the modules.pcimap > > > and pci.ids file were correct, but the pcitable file contained entries > > > for all ql[ae]23xx based HBAs to load qla2300.ko. > > > > > > It's my understanding that this was fixed for RHEL4 U1. Which distro > > > are you using? If you are using RHEL, and are still having problems, > > > I'd suggest you file a report with Redhat. > > > > > > Regards, > > > Andrew Vasquez > > > > > > > BINGO! I AM using RHEL 4. So does that mean I can rectify the problem > > by making appropriate changes to "pcitable" file? > > I'm trying to get a firm answer from the folks who originally > discvoered the problem some time back, it seems you have two options: Hey Thanks. I would really appreciate if you could update list/me on it IF you get any updates (I know its too much pain). > - (post installation) modify the /etc/modprobe.conf to and rename the > qla2300 entry to qla2322 (i.e.): > >alias scsi_hostadapter1 qla2322 > > modify the modules.pcimap table to load qla2322 for the 2322 > device-id: > >qla2300 0x1077 0x2322 ... > > to: > >qla2322 0x1077 0x2322 ... > > > Beyond that, I'd suggest you log a report with Redhat, as that's the > extent of the workaround knowledge without going to RHEL4U1. > > Hope this helps, > Andrew Vasquez > THANKS. It worked for me, for time being. In the mean time, I plan to file report with RedHat and will update list as and when I get any response. regards, Rajat - 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
[ANNOUNCE] sdparm 0.94
sdparm is a command line utility designed to get and set SCSI device parameters (cf hdparm for ATA disks). Apart from SCSI devices (e.g. disks, tapes and enclosures) sdparm can be used on any device that uses a SCSI command set. Virtually all CD/DVD drives use the SCSI MMC set irrespective of the transport. sdparm also can list VPD pages including the device identification page. sdparm can be used in both the lk 2.4 and 2.6 series. The major addition in version 0.94 is a set of commands mainly for devices with removable media: eject, load, ready, start, stop and unlock. For more information and downloads see: http://www.torque.net/sg/sdparm.html ChangeLog for sdparm-0.94 [20050728] - add CD/DVD (MM) capabilities and mechanical status mode page - add Background medium scan (SBC-2 pending) mode subpage - add '--command=' option with these s: ready, start, stop, load, eject and unlock - add decoding for SCSI Ports VPD page - updated to automake version 1.9.5 - copy of sdparm.html placed in doc directory Doug Gilbert - 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: Fix up qla2xxx configuration bogosity
On Wed, 2005-07-27 at 22:10 -0700, Andrew Vasquez wrote: > Would you also apply the attached patch which adds the appropriate > FW_LOADER pre-requisite and a separate entry for ISP24xx support. That's what I see reading the code; however, it looks like it's *only* the 24xx that needs it (qla24xx_load_risc_hotplug). The patch below pulls in the FW loader for every qlogic fibre driver, not just the qla24xx; is there a reason for doing this? 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 0/3] Add disk hotswap support to libata
On Thu, 21 Jul 2005 21:35:24 EDT, Jeff Garzik wrote:
>As soon as I finish SATA ATAPI (this week[end]), I'll take a look at
>this. A quick review of the patches didn't turn up anything terribly
>objectionable, though :)
>
I would like to offer to test when you are ready. Some older and new SATAPI
drives, various chipsets (ICH{5,6}, TX4 on the way). And a SATA analyzer
for anything really odd.
++doug
-
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: Fix up qla2xxx configuration bogosity
On Thu, 28 Jul 2005, James Bottomley wrote: > On Wed, 2005-07-27 at 22:10 -0700, Andrew Vasquez wrote: > > Would you also apply the attached patch which adds the appropriate > > FW_LOADER pre-requisite and a separate entry for ISP24xx support. > > That's what I see reading the code; however, it looks like it's *only* > the 24xx that needs it (qla24xx_load_risc_hotplug). The patch below > pulls in the FW loader for every qlogic fibre driver, not just the > qla24xx; is there a reason for doing this? Yes, I've been working on a set of patches which add this functionality across the board with supported ISP types (21xx, 22xx, 23xx). I should have some patches for submission in next week's time-frame. So rather than a adding #if code around the relevant 24xx specific codes in qla2xxx, I chose the fw_loader path for all types. -- Andrew Vasquez - 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 0/3] Add disk hotswap support to libata
Doug Maxey wrote:
On Thu, 21 Jul 2005 21:35:24 EDT, Jeff Garzik wrote:
As soon as I finish SATA ATAPI (this week[end]), I'll take a look at
this. A quick review of the patches didn't turn up anything terribly
objectionable, though :)
I would like to offer to test when you are ready. Some older and new SATAPI
drives, various chipsets (ICH{5,6}, TX4 on the way). And a SATA analyzer
for anything really odd.
Great!
It'll be posted here on linux-ide, so just keep an eye out.
Analysis of any portion of libata, with a SATA analyzer, would be much
appreciated.
Jeff
-
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: SAS transport class status?
On 07/28/05 16:27, Tom Duffy wrote: > Luben, et. al. > > Any updates on the SAS transport class code? Are we likely to see this > happening in the 2.6.14 time frame? After the BOF at OLS, I figured we > would be moving quick on this... It really depends on when 2.6.14 is coming out. I'm doing discovery at the moment. Luben > Eric, have you tried to get your code ported to Luben's patch? > > Thanks, > > -tduffy - 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
SAS transport class status?
Luben, et. al. Any updates on the SAS transport class code? Are we likely to see this happening in the 2.6.14 time frame? After the BOF at OLS, I figured we would be moving quick on this... Eric, have you tried to get your code ported to Luben's patch? Thanks, -tduffy signature.asc Description: This is a digitally signed message part
Re: Megaraid problems with >8GB RAM
Firstly many thanks to LSI who responded so promptly to an e-mail which
wasn't even addressed to them :), we really appreciate the support.
I went back to the datacenter yesterday for another try, and managed to
get both boxes booting with SuSe Pro 9.3 (instead of Debian). However,
the amusing part is that they only sucessfully boot about 1/3rd of the
time. The rest of the time it results in the "mailbox adapter did not
initialize" error (after a timeout). Oddly enough, it seems to boot fine
when it's "warm". Cold boots are less successful.
Very occasionally, it results in a kernel panic (hastily transcribed):
megaraid cmm: 2.20.2.5
megaraid: 2.20.4.5
Unable to handle kernel paging request at RIP:
{:megaraid_mbox:megaraid_isr+298}
PGD 0
Oops: 0002 [1] SMP
CPU 1
Modules linked in: megaraid_mbox megaraid_mm amd74xx ide_core sd_mod
scsi_mod
Pid: 0, comm: swapper Not tainted 2.6.11.4-21.7-smp
RIP: 0010:[]
{:megaraid_mbox:megaraid_isr+298}
RSP: 0018:810037d17e98 EFLAGS: 00010082
RAX: RBX: 8100101e5010 RCX: 2370
RDX: RSI: 81020a094000 RDI: 8100fbca0028
We've had to push one of these boxes into production very urgently, and
it seems to be running fine under heavy load. So as long as it doesn't
reboot, we're fine...
Our hardware spec:
- Tyan motherboard (spec unknown, I'll find it out if it helps), AMD
chipset.
- Dual Opteron 2.2GHz
- 16GB RAM
- Megaraid 320-2 (1L37/G119)
Cheers,
Russ Garrett
[EMAIL PROTECTED]
-Original Message-
From: Russ Garrett [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 26, 2005 6:01 PM
To: linux-scsi@vger.kernel.org
Subject: Megaraid problems with >8GB RAM
When installing Linux on a pair of new dual-opteron servers (16GB of RAM
and a MegaRAID 320-2), neither the megaraid v1, nor v2 drivers could
talk to the actual MegaRAID hardware. The v1 driver simply caused the
system to lock up, wheras the v2 driver produces the error "megaraid:
maibox adapter did not initialize" after a while.
Googling for the error produced this slightly old result, which fits the
problem perfectly:
http://lists.suse.com/archive/suse-amd64/2004-Jun/0345.html
And indeed, passing the argument "mem=300k" to the kernel allows the
card to be detected fine by the v2 driver. We have a lot of 8GB Opterons
running Megaraid cards fine, but this is the first time we've bought
16GB models. This is the first problem we've seen, so I'm guessing that
the MegaRAID firmware has issues writing to RAM higher than somewhere
between 8 and 16GB...
Should we be looking for a new RAID card or is there a way to fix this?
Why has seemingly nobody else had this problem?
Thanks in advance,
Russ Garrett
[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: Fw: Kernel panic with dc395x in 2.6.12.2
randy_dunlap wrote: > >oh drat. Please test 2.6.12.2 with the following patch segment >backed out (-R, reversed). I don't see any other patches that could >be the cause. If this isn't the problem, I would have to begin >to suspect some kind of toolchain problem. > > > It seems the blame falls solely on my shoulders. I hadn't undone one of the patches I had previously applied when searching for the HIGHMEM bug. :( So there is no problem with the driver without HIGHMEM enabled, 2.6.12.2 or otherwise. I'll get on figuring out with -rc caused the HIGHMEM issue instead.. Sorry Pierre - 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: Fw: Kernel panic with dc395x in 2.6.12.2
On Fri, 29 Jul 2005 01:05:48 +0200 Pierre Ossman wrote: > randy_dunlap wrote: > > > > >oh drat. Please test 2.6.12.2 with the following patch segment > >backed out (-R, reversed). I don't see any other patches that could > >be the cause. If this isn't the problem, I would have to begin > >to suspect some kind of toolchain problem. > > > > > > > > It seems the blame falls solely on my shoulders. I hadn't undone one of > the patches I had previously applied when searching for the HIGHMEM bug. :( > > So there is no problem with the driver without HIGHMEM enabled, 2.6.12.2 > or otherwise. > > I'll get on figuring out with -rc caused the HIGHMEM issue instead.. Well, that's actually a relief IMO. Thanks for the info. later, --- ~Randy - 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
[RFC][PATCH] libata ATAPI alignment
So, one thing that's terribly ugly about SATA ATAPI is that we need to
pad DMA transfers to the next 32-bit boundary, if the length is not
evenly divisible by 4.
Messing with the scatterlist to accomplish this is terribly ugly
no matter how you slice it. One way would be to create my own
scatterlist, via memcpy and then manual labor. Another way would be
to special case a pad buffer, appending it onto the end of various
scatterlist code.
Complicating matters, we currently must support two methods of data
buffer submission: a single kernel virtual address, or a struct
scatterlist.
Review is requested by any and all parties, as well as suggestions for
a prettier approach.
This is one of the last steps needed to get ATAPI going.
diff --git a/drivers/scsi/ahci.c b/drivers/scsi/ahci.c
--- a/drivers/scsi/ahci.c
+++ b/drivers/scsi/ahci.c
@@ -44,7 +44,7 @@
enum {
AHCI_PCI_BAR= 5,
- AHCI_MAX_SG = 168, /* hardware max is 64K */
+ AHCI_MAX_SG = 300, /* hardware max is 64K */
AHCI_DMA_BOUNDARY = 0x,
AHCI_USE_CLUSTERING = 0,
AHCI_CMD_SLOT_SZ= 32 * 32,
@@ -197,7 +197,7 @@ static Scsi_Host_Template ahci_sht = {
.eh_strategy_handler= ata_scsi_error,
.can_queue = ATA_DEF_QUEUE,
.this_id= ATA_SHT_THIS_ID,
- .sg_tablesize = AHCI_MAX_SG,
+ .sg_tablesize = AHCI_MAX_SG - 1,
.max_sectors= ATA_MAX_SECTORS,
.cmd_per_lun= ATA_SHT_CMD_PER_LUN,
.emulated = ATA_SHT_EMULATED,
@@ -313,8 +313,15 @@ static int ahci_port_start(struct ata_po
return -ENOMEM;
memset(pp, 0, sizeof(*pp));
+ ap->pad = dma_alloc_coherent(dev, ATA_DMA_PAD_BUF_SZ, &ap->pad_dma,
GFP_KERNEL);
+ if (!ap->pad) {
+ kfree(pp);
+ return -ENOMEM;
+ }
+
mem = dma_alloc_coherent(dev, AHCI_PORT_PRIV_DMA_SZ, &mem_dma,
GFP_KERNEL);
if (!mem) {
+ dma_free_coherent(dev, ATA_DMA_PAD_BUF_SZ, ap->pad,
ap->pad_dma);
kfree(pp);
return -ENOMEM;
}
@@ -390,6 +397,7 @@ static void ahci_port_stop(struct ata_po
ap->private_data = NULL;
dma_free_coherent(dev, AHCI_PORT_PRIV_DMA_SZ,
pp->cmd_slot, pp->cmd_slot_dma);
+ dma_free_coherent(dev, ATA_DMA_PAD_BUF_SZ, ap->pad, ap->pad_dma);
kfree(pp);
}
@@ -474,7 +482,8 @@ static void ahci_tf_read(struct ata_port
static void ahci_fill_sg(struct ata_queued_cmd *qc)
{
- struct ahci_port_priv *pp = qc->ap->private_data;
+ struct ata_port *ap = qc->ap;
+ struct ahci_port_priv *pp = ap->private_data;
unsigned int i;
VPRINTK("ENTER\n");
@@ -493,6 +502,24 @@ static void ahci_fill_sg(struct ata_queu
pp->cmd_tbl_sg[i].addr_hi = cpu_to_le32((addr >> 16) >> 16);
pp->cmd_tbl_sg[i].flags_size = cpu_to_le32(sg_len - 1);
}
+
+ /* if we added a small buffer, to pad xfer to next 32-bit bound,
+* add it to the s/g list here
+*/
+ if (qc->flags & ATA_QCFLAG_PADDED) {
+ dma_addr_t pad_addr = ap->pad_dma + (qc->tag * ATA_DMA_PAD_SZ);
+ u32 len;
+
+ /* fixup last s/g entry */
+ len = le32_to_cpu(pp->cmd_tbl_sg[i - 1].flags_size);
+ pp->cmd_tbl_sg[i - 1].flags_size =
+ cpu_to_le32(len - qc->pad_len);
+
+ /* append pad buffer to s/g list */
+ pp->cmd_tbl_sg[i].addr = cpu_to_le32(pad_addr & 0x);
+ pp->cmd_tbl_sg[i].addr_hi = cpu_to_le32((pad_addr >> 16) >> 16);
+ pp->cmd_tbl_sg[i].flags_size = cpu_to_le32(ATA_DMA_PAD_SZ - 1);
+ }
}
static void ahci_qc_prep(struct ata_queued_cmd *qc)
@@ -501,13 +528,16 @@ static void ahci_qc_prep(struct ata_queu
struct ahci_port_priv *pp = ap->private_data;
u32 opts;
const u32 cmd_fis_len = 5; /* five dwords */
+ unsigned int n_elem = qc->n_elem;
/*
* Fill in command slot information (currently only one slot,
* slot 0, is currently since we don't do queueing)
*/
- opts = (qc->n_elem << 16) | cmd_fis_len;
+ if (qc->flags & ATA_QCFLAG_PADDED)
+ n_elem++;
+ opts = (n_elem << 16) | cmd_fis_len;
if (qc->tf.flags & ATA_TFLAG_WRITE)
opts |= AHCI_CMD_WRITE;
if (is_atapi_taskfile(&qc->tf))
diff --git a/drivers/scsi/libata-core.c b/drivers/scsi/libata-core.c
--- a/drivers/scsi/libata-core.c
+++ b/drivers/scsi/libata-core.c
@@ -2144,6 +2144,8 @@ static void ata_sg_clean(struct ata_queu
struct ata_port *ap = qc->ap;
struct scatterlist *sg = qc->sg;
int dir = qc->dma_dir;
+ unsigned int copy_pad = 0;
+ void *pad_buf = NULL;
assert(qc->flags & ATA
Fw: variable used before set
This is surely a bug. Can someone please suggest how it should be fixed? Thanks. Begin forwarded message: Date: Tue, 28 Jun 2005 09:14:28 + From: "d binderman" <[EMAIL PROTECTED]> To: linux-kernel@vger.kernel.org Subject: variable used before set Hello there, I just tried to compile the Linux Kernel version 2.6.11.12 with the most excellent Intel C compiler. It said drivers/scsi/pcmcia/aha152x_stub.c(313): remark #592: variable "tmp" is used before its value is set tmp.device->host = info->host; ^ This is clearly broken code, since the field tmp.device has not been initialised, and so isn't pointing to anything. Suggest code rework. _ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/ - 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/ - 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
