ita wrote:
> > > > This fixes the wrong position of the comment introduced by
> > > > scsi-rename-random32-to-prandom_u32.patch in the -mm tree.
> > > >
> > > > Signed-off-by: Akinobu Mita
> > > > Cc: "James E.J. Bottomley"
> &
the wrong position of the comment introduced by
scsi-rename-random32-to-prandom_u32.patch in the -mm tree.
Signed-off-by: Akinobu Mita akinobu.m...@gmail.com
Cc: James E.J. Bottomley jbottom...@parallels.com
Cc: Andrew Vasquez andrew.vasq...@qlogic.com
---
drivers/scsi/qla2xxx
On Tue, 19 Feb 2008, James Bottomley wrote:
> On Tue, 2008-02-19 at 18:35 -0800, Andrew Vasquez wrote:
> > On Tue, 19 Feb 2008, James Bottomley wrote:
> >
> > > On Tue, 2008-02-19 at 21:29 +0200, Adrian Bunk wrote:
> > > > This patch removes dead
On Tue, 19 Feb 2008, James Bottomley wrote:
> On Tue, 2008-02-19 at 21:29 +0200, Adrian Bunk wrote:
> > This patch removes dead code spotted by the Coverity checker.
> >
> > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> >
> > ---
> >
> > drivers/scsi/qla4xxx/ql4_isr.c | 18
On Tue, 19 Feb 2008, James Bottomley wrote:
On Tue, 2008-02-19 at 21:29 +0200, Adrian Bunk wrote:
This patch removes dead code spotted by the Coverity checker.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/scsi/qla4xxx/ql4_isr.c | 18 +-
1 file
On Tue, 19 Feb 2008, James Bottomley wrote:
On Tue, 2008-02-19 at 18:35 -0800, Andrew Vasquez wrote:
On Tue, 19 Feb 2008, James Bottomley wrote:
On Tue, 2008-02-19 at 21:29 +0200, Adrian Bunk wrote:
This patch removes dead code spotted by the Coverity checker.
Signed-off
On Tue, 05 Feb 2008, Alan D. Brunelle wrote:
> > and send the resultant kernel logs?
>
> Here's the output to the console (if there are other logs you need,
> let me know). I'll try the patch next, and sorry, hadn't realized
> merges were still coming in under 2.6.24 in Linus' tree...
>
>
On Tue, 05 Feb 2008, Andrew Vasquez wrote:
> > Could you load the (default 2.6.24) driver with
> > ql2xextended_error_logging modules parameter set:
> >
> > # insmod qla2xxx ql2xextended_error_logging=1
> >
> > and send the resultant kernel logs?
>
On Tue, 05 Feb 2008, Andrew Vasquez wrote:
> On Tue, 05 Feb 2008, Alan D. Brunelle wrote:
>
> > commit 9b73e76f3cf63379dcf45fcd4f112f5812418d0a
> > Merge: 50d9a12... 23c3e29...
> > Author: Linus Torvalds <[EMAIL PROTECTED]>
> > Date: Fri Jan 25 17:19:
nly willing to help narrow down to the specific part in
> this patch...
That's a rather large patch... :( Any chance you could git-bisect?
Also, could you send your .config file you are using?
Thanks,
Andrew Vasquez
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel&q
git-bisect?
Also, could you send your .config file you are using?
Thanks,
Andrew Vasquez
--
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
On Tue, 05 Feb 2008, Andrew Vasquez wrote:
On Tue, 05 Feb 2008, Alan D. Brunelle wrote:
commit 9b73e76f3cf63379dcf45fcd4f112f5812418d0a
Merge: 50d9a12... 23c3e29...
Author: Linus Torvalds [EMAIL PROTECTED]
Date: Fri Jan 25 17:19:08 2008 -0800
Merge git://git.kernel.org/pub
On Tue, 05 Feb 2008, Andrew Vasquez wrote:
Could you load the (default 2.6.24) driver with
ql2xextended_error_logging modules parameter set:
# insmod qla2xxx ql2xextended_error_logging=1
and send the resultant kernel logs?
Could you tray the patch referenced here:
qla2xxx
On Tue, 05 Feb 2008, Alan D. Brunelle wrote:
and send the resultant kernel logs?
Here's the output to the console (if there are other logs you need,
let me know). I'll try the patch next, and sorry, hadn't realized
merges were still coming in under 2.6.24 in Linus' tree...
QLogic Fibre
On Tue, 08 Jan 2008, Benjamin Herrenschmidt wrote:
> On Mon, 2008-01-07 at 11:42 -0800, Andrew Vasquez wrote:
> > That's fine. I take it these patches will be funneled via
> > gregkh/pci-2.6.git. There's some qla2xxx updates which are queued for
> > post-2.6.24 consumption
On Tue, 08 Jan 2008, Benjamin Herrenschmidt wrote:
On Mon, 2008-01-07 at 11:42 -0800, Andrew Vasquez wrote:
That's fine. I take it these patches will be funneled via
gregkh/pci-2.6.git. There's some qla2xxx updates which are queued for
post-2.6.24 consumption in jejb/scsi-misc-2.6.git
On Tue, 29 Jan 2008, Luck, Tony wrote:
> > > Will try this next.
> >
> > Should work even better since it avoids a lock and copy, but please do
> > test if you have the time.
>
> That one works too (survived two full builds at "make -j32" on the 16-way
> system).
>
> Thanks for the quick
On Tue, 29 Jan 2008, Jens Axboe wrote:
> Great, thanks for confirming. It does look like a clear bug in cciss, it
> just got exposed now that it uses proper end request handling. We never
> need to clear ->data_len, since for blk_fs_request() it will be cleared
> on init. So just setting a
On Tue, 29 Jan 2008, Miller, Mike (OS Dev) wrote:
> Jens wrote:
>
> > -Original Message-
> > From: Jens Axboe [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, January 29, 2008 12:54 PM
> > To: Andrew Vasquez
> > Cc: Linux Kernel Mailing List; Miller,
On Tue, 29 Jan 2008, Jens Axboe wrote:
> On Tue, Jan 29 2008, Andrew Vasquez wrote:
> > On Tue, 29 Jan 2008, Jens Axboe wrote:
> >
> > > > Here the final snippet that was logged:
> > > >
> > > > [ 12.724997] input: USB HID v1.01 Mouse [
On Tue, 29 Jan 2008, Jens Axboe wrote:
> > Here the final snippet that was logged:
> >
> > [ 12.724997] input: USB HID v1.01 Mouse [HP Virtual Keyboard] on
> > usb-:01:04.4-1
> > [ 12.728971] usbcore: registered new interface driver usbhid
> > [ 12.732866]
On Tue, 29 Jan 2008, Jens Axboe wrote:
> Andrew, can you try with this applied?
>
> diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
> index ef50068..bd7b352 100644
> --- a/drivers/block/cciss.c
> +++ b/drivers/block/cciss.c
> @@ -1257,7 +1257,7 @@ static void cciss_softirq_done(struct
Hitting a consistent BUG() with recent Linus' linux-2.6.git:
[ 12.941428] [ cut here ]
[ 12.944874] kernel BUG at drivers/block/cciss.c:1260!
[ 12.944874] invalid opcode: [1] SMP
[ 12.944874] CPU 0
[ 12.944874]
Hitting a consistent BUG() with recent Linus' linux-2.6.git:
[ 12.941428] [ cut here ]
[ 12.944874] kernel BUG at drivers/block/cciss.c:1260!
[ 12.944874] invalid opcode: [1] SMP
[ 12.944874] CPU 0
[ 12.944874]
On Tue, 29 Jan 2008, Luck, Tony wrote:
Will try this next.
Should work even better since it avoids a lock and copy, but please do
test if you have the time.
That one works too (survived two full builds at make -j32 on the 16-way
system).
Thanks for the quick turnaround.
Jens,
On Tue, 29 Jan 2008, Jens Axboe wrote:
On Tue, Jan 29 2008, Andrew Vasquez wrote:
On Tue, 29 Jan 2008, Jens Axboe wrote:
Here the final snippet that was logged:
[ 12.724997] input: USB HID v1.01 Mouse [HP Virtual Keyboard] on
usb-:01:04.4-1
[ 12.728971] usbcore
On Tue, 29 Jan 2008, Jens Axboe wrote:
Andrew, can you try with this applied?
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index ef50068..bd7b352 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -1257,7 +1257,7 @@ static void cciss_softirq_done(struct
On Tue, 29 Jan 2008, Jens Axboe wrote:
Here the final snippet that was logged:
[ 12.724997] input: USB HID v1.01 Mouse [HP Virtual Keyboard] on
usb-:01:04.4-1
[ 12.728971] usbcore: registered new interface driver usbhid
[ 12.732866] drivers/hid/usbhid/hid-core.c: v2.6:USB
On Tue, 29 Jan 2008, Miller, Mike (OS Dev) wrote:
Jens wrote:
-Original Message-
From: Jens Axboe [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 29, 2008 12:54 PM
To: Andrew Vasquez
Cc: Linux Kernel Mailing List; Miller, Mike (OS Dev);
[EMAIL PROTECTED]; [EMAIL PROTECTED
I hold off on some of the cleanup post-merge time...
Thanks,
Andrew Vasquez
> Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> ---
>
> drivers/ata/pata_cs5520.c |2 +-
> drivers/i2c/busses/scx200_acb.c |2 +-
> drivers/ide/pci/cs5520.c|
of the cleanup post-merge time...
Thanks,
Andrew Vasquez
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
drivers/ata/pata_cs5520.c |2 +-
drivers/i2c/busses/scx200_acb.c |2 +-
drivers/ide/pci/cs5520.c| 10 --
drivers/ide/setup-pci.c |6
|4 ++--
> drivers/scsi/lpfc/lpfc.h |2 +-
> drivers/scsi/lpfc/lpfc_mbox.c |2 +-
> drivers/scsi/megaraid/megaraid_mbox.c | 10 +-
> drivers/scsi/psi240i.c|2 +-
> drivers/scsi/qla2xxx/qla_gs.c |2 +-
qla
+-
drivers/scsi/lpfc/lpfc_mbox.c |2 +-
drivers/scsi/megaraid/megaraid_mbox.c | 10 +-
drivers/scsi/psi240i.c|2 +-
drivers/scsi/qla2xxx/qla_gs.c |2 +-
qla2xxx bits:
Acked-by: Andrew Vasquez [EMAIL PROTECTED]
--
To unsubscribe from this list
On Tue, 09 Oct 2007, James Smart wrote:
> Why do you prefer request_firmware() vs something over sysfs ?
>
> Does environments like the kdump kernel also have access to data needed
> by request_firmware() ?
There's already much in the way of automation and infrastructure
present in
On Tue, 09 Oct 2007, James Smart wrote:
Why do you prefer request_firmware() vs something over sysfs ?
Does environments like the kdump kernel also have access to data needed
by request_firmware() ?
There's already much in the way of automation and infrastructure
present in supporting
On Mon, 08 Oct 2007, Darrick J. Wong wrote:
> On Mon, Oct 08, 2007 at 03:48:32PM -0700, Andrew Vasquez wrote:
>
> > So how about factoring that out to a transport-level interface. How
> > about something along the lines of the following patch, whereby the
> > softwa
On Mon, 08 Oct 2007, Darrick J. Wong wrote:
> If the aic94xx chip doesn't have a SAS address in the chip's flash memory,
> use the request_firmware() interface to get one from userspace. This
> way, there's no debate as to who or how an address gets generated--it's
> totally up to the
On Mon, 08 Oct 2007, Darrick J. Wong wrote:
If the aic94xx chip doesn't have a SAS address in the chip's flash memory,
use the request_firmware() interface to get one from userspace. This
way, there's no debate as to who or how an address gets generated--it's
totally up to the administrator
On Mon, 08 Oct 2007, Darrick J. Wong wrote:
On Mon, Oct 08, 2007 at 03:48:32PM -0700, Andrew Vasquez wrote:
So how about factoring that out to a transport-level interface. How
about something along the lines of the following patch, whereby the
software driver upon detecting no valid
On Wed, 08 Aug 2007, Michal Piotrowski wrote:
> Here is a list of some known regressions in 2.6.23-rc2.
>
> Feel free to add new regressions/remove fixed etc.
> http://kernelnewbies.org/known_regressions
...
> SCSI
>
> Subject : unable to handle kernel NULL pointer dereference in
>
On Wed, 08 Aug 2007, Michal Piotrowski wrote:
Here is a list of some known regressions in 2.6.23-rc2.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
...
SCSI
Subject : unable to handle kernel NULL pointer dereference in
Signed-off-by: Andrew Vasquez <[EMAIL PROTECTED]>
---
On Thu, 26 Jul 2007, Andrew Vasquez wrote:
> On Thu, 26 Jul 2007, Andrew Patterson wrote:
>
> > On Thu, 2007-07-26 at 15:36 +0200, Ulrich Windl wrote:
> > > Hi,
>
Signed-off-by: Andrew Vasquez [EMAIL PROTECTED]
---
On Thu, 26 Jul 2007, Andrew Vasquez wrote:
On Thu, 26 Jul 2007, Andrew Patterson wrote:
On Thu, 2007-07-26 at 15:36 +0200, Ulrich Windl wrote:
Hi,
6QLogic Fibre Channel HBA
scsi/qla2xxx/qla_init.c | 14 ++
> 1 file changed, 6 insertions(+), 8 deletions(-)
Acked-by: Andrew Vasquez <[EMAIL PROTECTED]>
-
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:
> On Fri, 27 Jul 2007, Andrew Patterson wrote:
>
> > On Thu, 2007-07-26 at 23:23 -0700, Andrew Vasquez wrote:
> >
> > > The 33/66/100/133 values refer to the bus-clock speed at which the
> > > card is operating. As is seen here (although a bit truncated --
&
On Fri, 27 Jul 2007, Andrew Patterson wrote:
On Thu, 2007-07-26 at 23:23 -0700, Andrew Vasquez wrote:
The 33/66/100/133 values refer to the bus-clock speed at which the
card is operating. As is seen here (although a bit truncated --
separate issue, I'll try to see if I can
changed, 6 insertions(+), 8 deletions(-)
Acked-by: Andrew Vasquez [EMAIL PROTECTED]
-
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
On Fri, 27 Jul 2007, Andrew Patterson wrote:
> On Thu, 2007-07-26 at 23:23 -0700, Andrew Vasquez wrote:
>
> > The 33/66/100/133 values refer to the bus-clock speed at which the
> > card is operating. As is seen here (although a bit truncated --
> > separate issue,
6 MHz, and is it just displayed
> > incorrectly,
> > or doesn't Linux support the speed of 266MHz yet?
>
> This is a bug in the driver. The lookup table only goes to 133 MHz.
>
> static char *pci_bus_modes[] = {
> "33", "66", "100"
,
or doesn't Linux support the speed of 266MHz yet?
This is a bug in the driver. The lookup table only goes to 133 MHz.
static char *pci_bus_modes[] = {
33, 66, 100, 133,
The same problem exists in the scsi_misc tree.
Regards,
Andrew Vasquez
-
To unsubscribe from this list
On Fri, 27 Jul 2007, Andrew Patterson wrote:
On Thu, 2007-07-26 at 23:23 -0700, Andrew Vasquez wrote:
The 33/66/100/133 values refer to the bus-clock speed at which the
card is operating. As is seen here (although a bit truncated --
separate issue, I'll try to see if I can reproduce
On Fri, 01 Jun 2007, Andi Kleen wrote:
> On Fri, Jun 01, 2007 at 03:38:57PM -0400, Rik van Riel wrote:
> > Andi Kleen wrote:
> >
> > >An pci_map_sg failing typically leads to an IO error and we've
> > >always printk'ed those. Otherwise people will wonder why they
> > >get EIO.
> >
> > In some
On Fri, 01 Jun 2007, Andi Kleen wrote:
> Rik van Riel <[EMAIL PROTECTED]> writes:
>
> > It turns out that the qla2xxx driver sometimes fills up the iotlb
> > on purpose and throttles itself when pci_map_sg() fails. In the
> > case of a driver that expects and handles pci_map_sg() failures,
> >
On Fri, 01 Jun 2007, Andi Kleen wrote:
Rik van Riel [EMAIL PROTECTED] writes:
It turns out that the qla2xxx driver sometimes fills up the iotlb
on purpose and throttles itself when pci_map_sg() fails. In the
case of a driver that expects and handles pci_map_sg() failures,
we should
On Fri, 01 Jun 2007, Andi Kleen wrote:
On Fri, Jun 01, 2007 at 03:38:57PM -0400, Rik van Riel wrote:
Andi Kleen wrote:
An pci_map_sg failing typically leads to an IO error and we've
always printk'ed those. Otherwise people will wonder why they
get EIO.
In some situations. In
On Tue, 15 May 2007, Andrew Morton wrote:
> On Tue, 15 May 2007 13:50:27 +0200
> "Peter Oruba" <[EMAIL PROTECTED]> wrote:
>
> > This patch set introduces a PCI-X / PCI-Express read byte count control
> > interface. Instead of letting every driver to directly read/write to PCI
> > config space
On Tue, 15 May 2007, Andrew Morton wrote:
On Tue, 15 May 2007 13:50:27 +0200
Peter Oruba [EMAIL PROTECTED] wrote:
This patch set introduces a PCI-X / PCI-Express read byte count control
interface. Instead of letting every driver to directly read/write to PCI
config space for that, an
> If it's just a time issue I can work on and push the patch, especially
> since I have the means to test things here.
I'll start with the final 2.6.21 -- add modify to add the *flashing*
light warning and some additional bits based on other archs I can test
with embedded ISPs. Thanks a
based on other archs I can test
with embedded ISPs. Thanks again for the SPARC tips.
Regards,
Andrew Vasquez
-
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
On Wed, 18 Apr 2007, Christoph Hellwig wrote:
> I don't think a module option is a good idea at this point. The problem
> is you broke some so far perfectly working setups, which is not okay.
> The only first step can be printing a really big warning. After this
> has been in for a while (at
On Wed, 18 Apr 2007, Christoph Hellwig wrote:
I don't think a module option is a good idea at this point. The problem
is you broke some so far perfectly working setups, which is not okay.
The only first step can be printing a really big warning. After this
has been in for a while (at lest
On Mon, 16 Apr 2007, David Miller wrote:
> From: Andrew Vasquez <[EMAIL PROTECTED]>
> Date: Mon, 16 Apr 2007 16:47:05 -0700
>
> > Dave, according to your earlier emails, the qla2xxx driver worked
> > 'fine' in driver versions before commit
> > 7aef45a
On Mon, 16 Apr 2007, David Miller wrote:
> From: Andrew Vasquez <[EMAIL PROTECTED]>
> Date: Mon, 16 Apr 2007 16:28:51 -0700
>
> > Sorry, but let's be realistic, this type of warning would have
> > *NEVER* been addressed if we kept the status quo
>
> Wron
On Mon, 16 Apr 2007, David Miller wrote:
> From: Andrew Vasquez <[EMAIL PROTECTED]>
> Date: Mon, 16 Apr 2007 15:25:17 -0700
>
> > Fine, I'll agree that wacking-users (and
> > I'll wager the outliers) with a 2x4 was a bit extreme,
>
> And that,
On Mon, 16 Apr 2007, David Miller wrote:
> From: Andrew Vasquez <[EMAIL PROTECTED]>
> Date: Mon, 16 Apr 2007 14:10:49 -0700
>
> > Ok, how about the following patch based on the one you posted which
> > adds the codes to retrieve the WWPN/WWNN from firmware on SPARC, a
On Mon, 16 Apr 2007, Andrew Vasquez wrote:
> On Mon, 16 Apr 2007, David Miller wrote:
>
> > They DON'T
> > CARE, they want their systems to work and if you don't give them that
> > you're not being a good driver maintainer.
>
> Let's push aside attitudes and un
On Mon, 16 Apr 2007, David Miller wrote:
> From: Andrew Vasquez <[EMAIL PROTECTED]>
> Date: Mon, 16 Apr 2007 09:37:12 -0700
>
> > On Mon, 16 Apr 2007, David Miller wrote:
> >
> > > But even if that fails, I think the fallback code should be put bac
t choose some random value that is a valid FC
> ID or use some characteristic ID that can be used to compose part of
> the port WWN in order to give it at least some uniqueness.
Look, there's a fine balance here that we must strike -- the solution
that you're proposing implies that there's
that you're proposing implies that there's some 'random' bit-space
within the IEEE NAA with which one can safely encode without stomping
on any valid OUI.
From 9ee6de3bbaa03390b83226e7bb84c49566a583b3 Mon Sep 17 00:00:00 2001
From: Andrew Vasquez [EMAIL PROTECTED]
Date: Wed, 11 Apr 2007 16:02:06 -0700
Subject
On Mon, 16 Apr 2007, David Miller wrote:
From: Andrew Vasquez [EMAIL PROTECTED]
Date: Mon, 16 Apr 2007 09:37:12 -0700
On Mon, 16 Apr 2007, David Miller wrote:
But even if that fails, I think the fallback code should be put back,
since it obviously was used by at least one system
On Mon, 16 Apr 2007, Andrew Vasquez wrote:
On Mon, 16 Apr 2007, David Miller wrote:
They DON'T
CARE, they want their systems to work and if you don't give them that
you're not being a good driver maintainer.
Let's push aside attitudes and unrealistic statistics, could we
perhaps
On Mon, 16 Apr 2007, David Miller wrote:
From: Andrew Vasquez [EMAIL PROTECTED]
Date: Mon, 16 Apr 2007 14:10:49 -0700
Ok, how about the following patch based on the one you posted which
adds the codes to retrieve the WWPN/WWNN from firmware on SPARC, and
also adds the module-parameter
On Mon, 16 Apr 2007, David Miller wrote:
From: Andrew Vasquez [EMAIL PROTECTED]
Date: Mon, 16 Apr 2007 15:25:17 -0700
Fine, I'll agree that wacking-users (and
I'll wager the outliers) with a 2x4 was a bit extreme,
And that, right there, is basically the end of the conversation.
You
On Mon, 16 Apr 2007, David Miller wrote:
From: Andrew Vasquez [EMAIL PROTECTED]
Date: Mon, 16 Apr 2007 16:28:51 -0700
Sorry, but let's be realistic, this type of warning would have
*NEVER* been addressed if we kept the status quo
Wrong. I watch the logs all the time and would have
On Mon, 16 Apr 2007, David Miller wrote:
From: Andrew Vasquez [EMAIL PROTECTED]
Date: Mon, 16 Apr 2007 16:47:05 -0700
Dave, according to your earlier emails, the qla2xxx driver worked
'fine' in driver versions before commit
7aef45ac92f49e76d990b51b7ecd714b9a608be1. If that were
On Tue, 27 Feb 2007, Andre Noll wrote:
> On 10:26, Andrew Vasquez wrote:
> > You are loading some stale firmware that's left over on the card --
> > I'm not even sure what 4.00.70 is, as the latest release firmware is
> > 4.00.27.
>
> That's the firmware which came wi
On Tue, 27 Feb 2007, Andre Noll wrote:
On 10:26, Andrew Vasquez wrote:
You are loading some stale firmware that's left over on the card --
I'm not even sure what 4.00.70 is, as the latest release firmware is
4.00.27.
That's the firmware which came with the card. Anyway, I just upgraded
process_response_queue+0xc1/0x1c0
> [ 75.780012] [] qla24xx_intr_handler+0x1d4/0x2b0
> [ 75.780131] [] handle_IRQ_event+0x20/0x60
Hmm
Regards,
Andrew Vasquez
-
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/
] [80462414] qla24xx_intr_handler+0x1d4/0x2b0
[ 75.780131] [8025e950] handle_IRQ_event+0x20/0x60
Hmm
Regards,
Andrew Vasquez
-
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
On Fri, 02 Feb 2007, Randy Dunlap wrote:
> On Fri, 2 Feb 2007 16:25:41 -0800 Andrew Morton wrote:
>
> > On Fri, 2 Feb 2007 12:56:30 -0800
> > Andrew Vasquez <[EMAIL PROTECTED]> wrote:
> >
> > > > > dt of=/dev/raw/raw1 procs=8 oncerr=abort bs
On Thu, 01 Feb 2007, Andrew Morton wrote:
> On Mon, 22 Jan 2007 10:35:10 -0800 Andrew Vasquez <[EMAIL PROTECTED]> wrote:
> > Basically what is happening from the FC side is the initiator executes
> > a simple dt test:
> >
> > dt of=/dev/raw/raw1 procs=8
On Thu, 01 Feb 2007, Andrew Morton wrote:
On Mon, 22 Jan 2007 10:35:10 -0800 Andrew Vasquez [EMAIL PROTECTED] wrote:
Basically what is happening from the FC side is the initiator executes
a simple dt test:
dt of=/dev/raw/raw1 procs=8 oncerr=abort bs=16k disable=stats
limit=2m
On Fri, 02 Feb 2007, Randy Dunlap wrote:
On Fri, 2 Feb 2007 16:25:41 -0800 Andrew Morton wrote:
On Fri, 2 Feb 2007 12:56:30 -0800
Andrew Vasquez [EMAIL PROTECTED] wrote:
dt of=/dev/raw/raw1 procs=8 oncerr=abort bs=16k disable=stats
limit=2m passes=100 pattern=iot
t is
not).
Anyway, any ideas or hints? Attached is the .config used.
Thanks,
Andrew Vasquez
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.19
# Fri Jan 19 16:53:19 2007
#
CONFIG_X86_64=y
CONFIG_64BIT=y
CONFIG_X86=y
CONFIG_ZONE_DMA32=y
CONFIG_LOCKDEP_
is the .config used.
Thanks,
Andrew Vasquez
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.19
# Fri Jan 19 16:53:19 2007
#
CONFIG_X86_64=y
CONFIG_64BIT=y
CONFIG_X86=y
CONFIG_ZONE_DMA32=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
now become static.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Acked-by: Andrew Vasquez <[EMAIL PROTECTED]>
-
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/
]
Acked-by: Andrew Vasquez [EMAIL PROTECTED]
-
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/
On Thu, 01 Sep 2005, Daniel Walker wrote:
> Remove possible uninitialized "sg" field warning in the qla24xx driver
>
> Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
>
> Index: linux-2.6.13/drivers/scsi/qla2xxx/qla_iocb.c
> ===
>
On Thu, 01 Sep 2005, Daniel Walker wrote:
Remove possible uninitialized sg field warning in the qla24xx driver
Signed-Off-By: Daniel Walker [EMAIL PROTECTED]
Index: linux-2.6.13/drivers/scsi/qla2xxx/qla_iocb.c
===
---
On Thu, 25 Aug 2005, Keith Owens wrote:
> On Wed, 24 Aug 2005 11:22:52 -0700,
> Andrew Vasquez <[EMAIL PROTECTED]> wrote:
> >On Wed, 24 Aug 2005, Keith Owens wrote:
> >
> >> 2.6.13-rc7 + kdb on ia64. The qla2xxx drivers are getting unaligned
> >> acces
On Thu, 25 Aug 2005, Keith Owens wrote:
On Wed, 24 Aug 2005 11:22:52 -0700,
Andrew Vasquez [EMAIL PROTECTED] wrote:
On Wed, 24 Aug 2005, Keith Owens wrote:
2.6.13-rc7 + kdb on ia64. The qla2xxx drivers are getting unaligned
accesses at startup.
qla2300 :01:02.0: Found
port_name arrays to an u64 would cause unaligned-access
warnings. Generalize the conversions with consistent
shifting of WWN bytes.
Signed-off-by: Andrew Vasquez <[EMAIL PROTECTED]>
---
drivers/scsi/qla2xxx/qla_attr.c | 27 +--
1
warnings. Generalize the conversions with consistent
shifting of WWN bytes.
Signed-off-by: Andrew Vasquez [EMAIL PROTECTED]
---
drivers/scsi/qla2xxx/qla_attr.c | 27 +--
1 files changed, 17 insertions(+), 10 deletions(-)
24e16c86578498fd71a3e33bebbd8be7323a03c6
diff
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 read
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
=e4ff4d7f9d85a2bc714307eb9113617182e62845
Would you also apply the attached patch which adds the appropriate
FW_LOADER pre-requisite and a separate entry for ISP24xx support.
Thanks to Adrian Bunk and Jesper Juhl for their efforts in fixing this
quirk.
Regards,
Andrew Vasquez
---
diff --git a/drivers/scsi/qla2xxx/Kconfig b
On Wed, 27 Jul 2005, Rajat Jain wrote:
> On 7/27/05, Andrew Vasquez <[EMAIL PROTECTED]> wrote:
> >
> > 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[a
On Wed, 27 Jul 2005, Rajat Jain wrote:
On 7/27/05, Andrew Vasquez [EMAIL PROTECTED] wrote:
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
=e4ff4d7f9d85a2bc714307eb9113617182e62845
Would you also apply the attached patch which adds the appropriate
FW_LOADER pre-requisite and a separate entry for ISP24xx support.
Thanks to Adrian Bunk and Jesper Juhl for their efforts in fixing this
quirk.
Regards,
Andrew Vasquez
---
diff --git a/drivers/scsi/qla2xxx/Kconfig b
h
> this problem?
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?
1 - 100 of 111 matches
Mail list logo
