Eric, I have to have a similar compat file for the IPMI drivers
backported onto RHEL3, RHEL4, and SLES9. They aren't in mainline of
course, but each OS has a slightly different copy for its needs, so my
DKMS packages carry it.
In general, this construct:
> > -#if (LINUX_VERSION_CODE < KERNEL_VER
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
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: send
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. Tested
I was going over the scsi I/O submit path, when sd_init_command
construct the scsi command, this_count is already checked in the
previous else if clause. Why does it need to check it again in
the last else block?
Patch to delete the spurious check.
Signed-off-by: Ken Chen <[EMAIL PROTECTED]>
-
> > But Id rather have same files in our maintained driver,
> > and whats in the kernel tree.
>
> Just think what a mess we'd have on our hands if we let
> everyone do that. Sorry, please don't put compat header
> files into the current upstream tree, thanks.
>
Fine.
-
To unsubscribe from this
From: "Moore, Eric Dean" <[EMAIL PROTECTED]>
Date: Tue, 12 Jul 2005 14:50:19 -0600
> But Id rather have same files in our maintained driver,
> and whats in the kernel tree.
Just think what a mess we'd have on our hands if we let
everyone do that. Sorry, please don't put compat header
files into
On 32 bit archs with LBD set, setsize can cast a capacity so
that we result in heads==0 (capacity is sector_t which would
be a 64 bit value with LBD but it gets cast to a unsigned long
which is only 32 bits). Some userspace programs will then blindly
use this heads value to do fun things. This patc
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 comma
On Tue, 2005-07-12 at 14:50 -0600, Moore, Eric Dean wrote:
> The 3.02.18 driver and the driver in kernel tree are totally different
> drivers.
> One thing is 3.02.18 has SAS support, and the kernel tree doesn't.Id
> wish
> kernel folks would take our SAS drivers.
Is there a patch that applies
>
> 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 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 kerne
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 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
I've seen the report. I need more info from Bharata on how
to reproduce. Perhaps you can send me email offline which
provides specific instructions to how to configure kdump,
how to capture the dump, and what you did to crash your system.
Eric Moore
LSI Logic Corporation
On Tuesday, July 12, 2005
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.
Cur
On Tue, 2005-07-12 at 11:26 +0530, Bharata B Rao wrote:
> Fusion MPT base driver fails during initialization when kdump capture
> kernel boots. The details of the problem are reported here:
This bug report is pretty useless to me because I do a lot of my email
when I'm offline, so I can't get to t
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 los
The 3ware controller you used is a PCI 2.2 64/66Mhz 900 series
controller, right?
What is the theoretical limit with the adapter? 528MB/sec, right?
On Tue, 2005-07-12 at 07:52, Alexander Jolk wrote:
> Kallol Biswas wrote:
> > Hello Alexander,
> >Could you get the LSI MegaRAID SATA
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 th
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
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 10:35:09AM -0400, [EMAIL PROTECTED] wrote:
> I really hated these patches. The issue that was causing >90% of the
> problems we encountered was that pci_alloc_consistent was overextending
> when no_iommu was set by ignoring the dma masks of the adapter and
> forcing the us
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
SANsurfer (Read/Write Buffer Test) runs a few times successfully (approx.
8-
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 sen
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 at
I really hated these patches. The issue that was causing >90% of the
problems we encountered was that pci_alloc_consistent was overextending
when no_iommu was set by ignoring the dma masks of the adapter and
forcing the use of the dma map pool when it wasn't necessary. IMHO, fixing
this issue see
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
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_LUN
29 matches
Mail list logo
