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
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
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 scsi_device_online(struct
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;
-}
-#endif
is better tested
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
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
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 use a
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
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
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. Why
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 of the
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 that
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 have a
and store originally).
This also solves the dilemma of the thread:
http://marc.theaimsgroup.com/?l=linux-kernelm=112116767118981w=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.6-20050713.ORIG/drivers/scsi
14 matches
Mail list logo
