to convert and store originally).
This also solves the dilemma of the thread:
http://marc.theaimsgroup.com/?l=linux-kernel&m=112116767118981&w=2
A patch for the lpfc driver to use this function will be along
in a few days (batched with other patches).
-- james
diff -upNr scsi-misc-2.
On Thu, 14 Jul 2005 01:57:54 +0200 Pierre Ossman wrote:
> Guennadi Liakhovetski wrote:
>
> >
> >Have you managed to get netconsole running? Do you have no chance at all
> >to use a serial console? You are, perhaps, the only / last user of dc395x
> >on a high-mem machine, the driver is known to
Guennadi Liakhovetski wrote:
>
>Have you managed to get netconsole running? Do you have no chance at all
>to use a serial console? You are, perhaps, the only / last user of dc395x
>on a high-mem machine, the driver is known to have a problem there,
>although from your dump I cannot see yet if t
On Wed, Jul 13, 2005 at 11:44:34AM -0700, Edward Falk wrote:
>
> >You should revisit your code to not need access to the scsi_device
> >structure, and follow the layering of the block and scsi subsystems.
>
> Maybe I should explain what I'm trying to do here.
>
> Some of our software reads some
Linux 2.6.13-rc2 treats RBC devices differently than before. (RBC: Reduced
Block Command set for logical block devices, commonly seen implemented by
SBP-2 harddisks.) Among else, the hotplug helpers now get to read type 14
from sysfs for RBC devices instead of type 0.
The patch updates scsi.agent'
Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
> Use the i2o_block and i2o_scsi drivers instead of dpt_i2o, they support
> the hardware and are written to proper APIs.
(Added originator to cc)
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAI
I wrote:
I'll try to get some more info.
There is no way to get more than I already posted. (Except maybe
with a serial console.) All other atempts ended at the first inquiry
command or even at sbp2's "Logged into SBP-2 device" message, leaving
the following SCSI commands to our imagination. Wh
Use the i2o_block and i2o_scsi drivers instead of dpt_i2o, they support
the hardware and are written to proper APIs.
-
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.h
You should revisit your code to not need access to the scsi_device
structure, and follow the layering of the block and scsi subsystems.
Maybe I should explain what I'm trying to do here.
Some of our software reads some of the values in /proc/ide/hda/. We're
porting this facility to libata-b
Hi
On Sun, 10 Jul 2005, Pierre Ossman wrote:
> randy_dunlap wrote:
>
> >Are you using netcat on the receive side?
>
> I've been using tcpdump and not a single packet eminates from the
> machine when printk:s show up.
Have you managed to get netconsole running? Do you have no chance at all
to
Begin forwarded message:
Date: Wed, 13 Jul 2005 09:10:10 -0700
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bugme-new] [Bug 4880] New: dpt_i2o.c does not register itself with
sysfs
http://bugzilla.kernel.org/show_bug.cgi?id=4880
Summary: dpt_i2o.c does not register itse
James Bottomley wrote:
On Wed, 2005-07-13 at 21:56 +0200, Stefan Richter wrote:
If I only new where the done() is taken from. Seems to come
from scsi.c.
I think it happens in sbp2scsi_complete_command.
OK, I will move scsi_print_sense just in front of the call to
->done().
Here is the log
On Wed, 2005-07-13 at 21:56 +0200, Stefan Richter wrote:
> If I only new where the done() is taken from. Seems to come
> from scsi.c.
I think it happens in sbp2scsi_complete_command.
> Here is the log with all the old conversions active in sbp2.
> I put scsi_print_command() into sbp2scsi_queuecom
James Bottomley wrote:
Could you get a trace of what's going on from the command response point
of view? Doing a scsi_print_command() in the queuecommand() routine and
printing the return code and sense (with scsi_print_sense()) in the
->done() should be sufficient.
If I only new where the don
I've attached patches against 2.6.13rc2. These are basically identical
to my earlier patches, as I found that all issues I'd seen in earlier
kernels still existed in this kernel.
To summarize, the changes are: (more details in my original email)
- add a kref to the scsi_tape structure, and associ
On Wednesday, July 13, 2005 8:38 AM, Christoph Hellwig wrote:
>
> > In general, this construct:
> >
> > > > -#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,6))
> > > > -static int inline scsi_device_online(struct scsi_device *sdev)
> > > > -{
> > > > - return sdev->online;
> > > > -}
> > > >
On Tue, Jul 12, 2005 at 05:38:19PM -0700, Edward Falk wrote:
> Hi all; what's the proper way to get the scsi_device structure from a
> gendisk structure?
No.
> 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 som
> In general, this construct:
>
> > > -#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,6))
> > > -static int inline scsi_device_online(struct scsi_device *sdev)
> > > -{
> > > - return sdev->online;
> > > -}
> > > -#endif
>
> is better tested as:
>
> #ifndef scsi_device_inline
> static int inline s
On Wed, Jul 13, 2005 at 04:05:03PM +0530, Bharata B Rao wrote:
> On Tue, 2005-07-12 at 12:15 -0600, Moore, Eric Dean wrote:
> > 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 confi
On Tue, 2005-07-12 at 12:15 -0600, Moore, Eric Dean wrote:
> 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 s
20 matches
Mail list logo
