Fusion MPT base driver fails during initialization when kdump capture
kernel boots. The details of the problem are reported here:
http://bugzilla.kernel.org/show_bug.cgi?id=4870
Regards,
Bharata.
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to
On Tue, 2005-07-12 at 16:52 +0530, Amrut Joshi wrote:
Hi,
Currently linux scsi subsystem doesnt store the 8-byte luns which are
recieved in REPORT_LUNS reply. This information is forver lost once
the scan is over. In my LDD I need this information. Currently I have
to snoop REPORT_LUNS
Hi,
On 7/12/05, Arjan van de Ven [EMAIL PROTECTED] wrote:
On Tue, 2005-07-12 at 16:52 +0530, Amrut Joshi wrote:
Hi,
Currently linux scsi subsystem doesnt store the 8-byte luns which are
recieved in REPORT_LUNS reply. This information is forver lost once
the scan is over. In my LDD I
James:
This patch adds a delay tailored for USB flash devices that are slow to
initialize their firmware. The symptom is a repeated Unit Attention with
ASC=0x28 (Not Ready to Ready transition). The patch will wait for up to 5
seconds for such devices to become ready. Normal devices won't
Hello Alexander,
Could you get the LSI MegaRAID SATA 300-8X controller
working for a long duration?
Have you run any performance benchmark on it yet? How much bandwidth do
you get with the controller?
Thanks,
Kallol
[EMAIL PROTECTED]
http://www.nucleodyne.com
On Thu, 2005-06-09
Kallol Biswas wrote:
Hello Alexander,
Could you get the LSI MegaRAID SATA 300-8X controller
working for a long duration?
Have you run any performance benchmark on it yet? How much bandwidth do
you get with the controller?
With a 2.6.11.11 kernel, I had it working for a few days
On Tue, Jul 12, 2005 at 04:42:11PM +0200, [EMAIL PROTECTED] wrote:
Hi all,
we are encountering SAN problems. Twice or threetimes a minute we can
neither read nor write for up to five seconds from/to our LUs. After that
short periode, it catches up and resumes normally. The diagnostics in
I'll try porting my changes to a recent kernel, verify that the bugs I
found are still bugs, and get back to you with a new patch.
In the meantime, responses to your comments:
- using a new kref in the scsi_tape structure: I've given this some
thought, and I think using a new kref is defintely
On Thu, 2005-06-16 at 11:15 -0700, Mike Anderson wrote:
Add a SCSI target state model similar to the SCSI device state model.
The first three patches look good (sorry been a hectic month, just
getting around to looking through them) so I'll stick them in scsi-misc
and see how they work out.
Thanks for redirecting to the correct list.
On Tue, 2005-07-12 at 13:38 +0200, Arjan van de Ven wrote:
On Tue, 2005-07-12 at 16:52 +0530, Amrut Joshi wrote:
Currently linux scsi subsystem doesnt store the 8-byte luns which are
recieved in REPORT_LUNS reply. This information is forver lost
On Tue, 12 Jul 2005, Dailey, Nate wrote:
I'll try porting my changes to a recent kernel, verify that the bugs I
found are still bugs, and get back to you with a new patch.
In the meantime, responses to your comments:
- using a new kref in the scsi_tape structure: I've given this some
This patch contains the following possible cleanups:
- make needlessly global code static
- #if 0 the following unused global functions:
- aic79xx_core.c: ahd_print_scb
- aic79xx_core.c: ahd_suspend
- aic79xx_core.c: ahd_resume
- aic79xx_core.c: ahd_dump_all_cards_state
- aic79xx_core.c:
On Sun, 2005-07-10 at 18:15 -0600, Moore, Eric Dean wrote:
I'd rather you not kill linux_compat.h file.
I use this file for compatibility of driver source
across various kernel versions. I provide our
customers with driver builds containing single source
which needs to compile in kernels
On Tue, 2005-07-12 at 16:42 +0200, [EMAIL PROTECTED] wrote:
Info: DiagRWBufferTest: Sense Key: 0xe, asc: 0x1d, ascq: 0x0.
That's a miscompare error with asc/ascq specifying miscompare on
verify ... it shouldn't be the product of a READ_BUFFER command it
should be the product of a VERIFY
scsi_init_io calls scsi_alloc_sgtable and then calls blk_rq_map_sg
to initialize the scatterlist structure. blk_rq_map_sg() already
memset the structure for every new segment. That makes the memset
in scsi_alloc_sgtable unnecessary.
Patch to delete the extra memset in scsi_alloc_sgtable.
Hi all; what's the proper way to get the scsi_device structure from a
gendisk structure? sd.c uses pointers through scsi_disk, but that
structure is private to sd.c. Will I need to add an access function in
sd.c or something?
-ed falk, [EMAIL PROTECTED]
-
To unsubscribe from this list:
Edward Falk wrote on Tuesday, July 12, 2005 5:38 PM
Hi all; what's the proper way to get the scsi_device structure from a
gendisk structure? sd.c uses pointers through scsi_disk, but that
structure is private to sd.c. Will I need to add an access function in
sd.c or something?
If you are
17 matches
Mail list logo
