kwhite | 1 Dec 2004 04:31
Picon
Favicon

Re: Boot order of LSI MPT Fusion devices controllable?

> I am running mdk 10.0 with kernel 2.6.3-16 out of box on a dual opteron
> 250 system.  The system has a LSI logic U320 controller with 7 internal
> disks on two channels.
> 
> 
> Well, the difference is that the fiber channel card seems to boot first,
> and thus reorders the scsi bus.  If I attach the fiber channel cables to
> the switch (making all of our storage visible) and re-probe the scsi bus
> by hand using the /dev interface, access to the SAN is fine etc.  Upon
> reboot with the fc connected, my system panics because now the root
> drive is no longer where it thinks it should be (sda is now a device on
> the fiber channel switch fabric).
> 
> Is there a way to control this process or to mitigate the problem?  I
> really need the system to boot properly off of local disk whether or not
> the fc is connected or the devices available.

You need to force the LSI U320 scsi driver to load before the fibre-channel
driver loads.

To do this you need to modify the /etc/modules.conf file and ensure your
scsi adapter driver loads first.  You then have to rebuild your ramdisk, if
you are using one, to ensure the modules.conf file is picked up at boot time.

Note: The load order is not determined by the entry order in modules.conf. It is
determined by "scsi_hostadapter" field.  If you want a scsi driver to load last,
make it have the highest numbered suffix.  Here is an example of entries in
modules.conf that would load the sym5c38xx driver first, and the Emulex lpfc
fibre-channel driver second:

(Continue reading)

Fabio Coatti | 1 Dec 2004 02:06
Picon

Re: Re: 2.6.10-rc2-mm2 usb storage still oopses

Alle 21:58, martedì 30 novembre 2004, Alan Stern ha scritto:

> It may be that the device wants old_scheme_first to be set when it's
> operating at high speed and not set when operating at full speed!  You can
> test this guess by unloading one driver or the other and then plugging in
> the device.

Well, I've tried and in fact without 
old_scheme_first set ehci hands over the device to uhci, that fails to detect 
it.
And in fact uhci is loaded at boot before ehci. I've modified this, but the 
behaviour is not ok: it seems that the device is detected ok even if already 
present at boot, but then I've a keyoboard/mouse lockup

Dec  1 01:40:26 kefk kernel: ehci_hcd 0000:00:1d.7: port 3 high speed
Dec  1 01:40:26 kefk kernel: ehci_hcd 0000:00:1d.7: GetStatus port 3 status 
001005 POWER sig=se0  PE CONNECT
Dec  1 01:40:26 kefk kernel: usb 1-3: new high speed USB device using ehci_hcd 
and address 3
Dec  1 01:40:26 kefk kernel: usb 1-3: new device strings: Mfr=1, Product=2, 
SerialNumber=3
Dec  1 01:40:26 kefk kernel: usb 1-3: default language 0x0409
Dec  1 01:40:26 kefk kernel: usb 1-3: Product: Mass storage
Dec  1 01:40:26 kefk kernel: usb 1-3: Manufacturer: USB
Dec  1 01:40:26 kefk kernel: usb 1-3: SerialNumber: 142E19413C2FCA34
Dec  1 01:40:26 kefk kernel: usb 1-3: hotplug
Dec  1 01:40:26 kefk kernel: PCI: Setting latency timer of device 0000:00:1d.2 
to 64
Dec  1 01:40:26 kefk kernel: uhci_hcd 0000:00:1d.2: irq 169, io base 0xb400
Dec  1 01:40:26 kefk kernel: usb 1-3: adding 1-3:1.0 (config #1, interface 0)
(Continue reading)

Matthew Wilcox | 1 Dec 2004 05:23

[PATCH] [2.4] sym2 module option to behave like 2.6


Several people have expressed dissatisfaction with their scsi drives
rearranging when they switch between 2.4 and 2.6.  It's particularly
gruesome for people with an HP A500 as the internal discs swap positions.

I can't make the 2.6 driver behave like the 2.4 driver, so here's an
alternative: add an option to make the 2.4 driver detect hosts in the
same order as the 2.6 driver.  This patch is only compile tested, so is
probably buggy.

Index: drivers/scsi/sym53c8xx_2/sym53c8xx.h
===================================================================
RCS file: /var/cvs/linux-2.4/drivers/scsi/sym53c8xx_2/sym53c8xx.h,v
retrieving revision 1.4
diff -u -p -r1.4 sym53c8xx.h
--- drivers/scsi/sym53c8xx_2/sym53c8xx.h	13 Nov 2002 15:15:44 -0000	1.4
+++ drivers/scsi/sym53c8xx_2/sym53c8xx.h	1 Dec 2004 04:15:56 -0000
 <at>  <at>  -268,6 +268,7  <at>  <at>  struct sym_driver_setup {
 	u_short	debug;
 	u_char	settle_delay;
 	u_char	use_nvram;
+	u_char	probe_26;
 	u_long	excludes[8];
 	char	tag_ctrl[100];
 };
 <at>  <at>  -313,6 +314,7  <at>  <at>  struct sym_driver_setup {
 	0,	/* debug */			\
 	3,	/* settle_delay */		\
 	1,	/* use_nvram */			\
+	0,	/* probe_26 */			\
(Continue reading)

James.Smart | 1 Dec 2004 05:35
Favicon

[Patch] [Repost] Add basic infrastructure for transport host statistics

This patch has been updated so that it backs against scsi-misc-2.6 as of 2004/11/27

-- James S

> -----Original Message-----
> From: linux-scsi-owner <at> vger.kernel.org
> [mailto:linux-scsi-owner <at> vger.kernel.org]On Behalf Of Smart, James
> Sent: Thursday, October 14, 2004 10:43 AM
> To: linux-scsi <at> vger.kernel.org
> Subject: [Patch] Add basic infrastructure for host statistics
> 
> 
> This patch adds the basic hooks to the scsi subsystem to 
> support transport-specific statistics to be added to a host. 
> Its basic nature follows the way in which net devices showed 
> their statistics.
> 
> -- James
> 
> 

Attachment (patch.host_stats): application/octet-stream, 1960 bytes
James.Smart | 1 Dec 2004 05:45
Favicon

[Patch] [Repost] Add FC transport host statistics

This patch has been updated so that it backs against scsi-misc-2.6 as of 2004/11/27. This patch depends on
the previous patch:
  "[Patch] [Repost] Add basic infrastructure for transport host statistics".

-- James S

> -----Original Message-----
> From: linux-scsi-owner <at> vger.kernel.org
> [mailto:linux-scsi-owner <at> vger.kernel.org]On Behalf Of Smart, James
> Sent: Thursday, October 14, 2004 10:49 AM
> To: linux-scsi <at> vger.kernel.org
> Cc: andrew.vasquez <at> qlogic.com; michaelc <at> cs.wisc.edu
> Subject: [Patch RFC] Add FC transport host statistics
> 
> 
> 
> This patch updates the fc_transport with statistics for local FC ports
> (e.g. Hosts).  The statistics are defined per HBAAPI v2.0 definitions.
> 
> Caveats:
> ------------
> - This patch applies to the scsi-target-2.6 bitkeeper tree. 
> It is dependent
>   upon the previous "host statistics" patch.
> 
> - The information below is supplied by a simple test driver 
> that does not
>   talk to real hardware, but fully acts as a LLDD that supports the
>   fc transport.
> 
(Continue reading)

James.Smart | 1 Dec 2004 05:49
Favicon

[Patch] [Repost] Add FC transport host attributes

This patch has been updated so that it backs against scsi-misc-2.6 as of 2004/11/27. This patch depends on
the previous patches:
  "[Patch] [Repost] Add basic infrastructure for transport host statistics"
  "[Patch] [Repost] Add FC transport host statistics"

This corresponds to the version 2, which was updated for comments from Christoph and Andrew. 

-- James S

> -----Original Message-----
> From: linux-scsi-owner <at> vger.kernel.org
> [mailto:linux-scsi-owner <at> vger.kernel.org]On Behalf Of Smart, James
> Sent: Thursday, October 14, 2004 10:53 AM
> To: linux-scsi <at> vger.kernel.org
> Cc: andrew.vasquez <at> qlogic.com; michaelc <at> cs.wisc.edu
> Subject: [Patch RFC] Add FC transport host attributes
> 
> 
> 
> This patch updates the fc_transport with attributes for local FC ports
> (e.g. Hosts).  The port attributes are defined per HBAAPI 
> v2.0 definitions.
> 
> Caveats:
> ------------
> - This patch applies to the scsi-target-2.6 bitkeeper tree. 
> It is dependent
>   upon the previous "host statistics" and "fc statistics" patches.
> 
> - This does not address remote port (target) information. 
(Continue reading)

James.Smart | 1 Dec 2004 05:58
Favicon

[Patch] [Repost] Add FC transport host statistics (w/ patch attached)

Sorry.. here's the patch as well...

-----Original Message-----
From: Smart, James 
Sent: Tuesday, November 30, 2004 11:45 PM
To: linux-scsi <at> vger.kernel.org
Cc: andrew.vasquez <at> qlogic.com; michaelc <at> cs.wisc.edu;
MPESCHKE <at> de.ibm.com; schwidefsky <at> de.ibm.com; akpm <at> osdl.org
Subject: [Patch] [Repost] Add FC transport host statistics

This patch has been updated so that it backs against scsi-misc-2.6 as of 2004/11/27. This patch depends on
the previous patch:
  "[Patch] [Repost] Add basic infrastructure for transport host statistics".

-- James S

> -----Original Message-----
> From: linux-scsi-owner <at> vger.kernel.org
> [mailto:linux-scsi-owner <at> vger.kernel.org]On Behalf Of Smart, James
> Sent: Thursday, October 14, 2004 10:49 AM
> To: linux-scsi <at> vger.kernel.org
> Cc: andrew.vasquez <at> qlogic.com; michaelc <at> cs.wisc.edu
> Subject: [Patch RFC] Add FC transport host statistics
> 
> 
> 
> This patch updates the fc_transport with statistics for local FC ports
> (e.g. Hosts).  The statistics are defined per HBAAPI v2.0 definitions.
> 
> Caveats:
(Continue reading)

James.Smart | 1 Dec 2004 05:59
Favicon

[Patch RFC ] Update FC transport for FC Remote Ports

All,

I've updated the fc transport with port attributes for remote ports (whether
they be FCP Targets or not). The implementation additionally manages consistent
scsi target id bindings for the remote ports.

Please bear with the lengthy intro below...

Comments welcome.

-- James S

-----------------------------------------

Background:
---------------------------
Remote port attributes would have been easy to add as target transport
attributes. However, that only works if the ports are FCP Targets. 
HBAAPI requires that you be able to report all ports, regardless of whether
they are FCP Targets, (other) FCP Initiators, FC-IP ports, etc.  Also,
giving a wider picture of the known topology to the administrator is a large
diagnostic aid.

What is a consistent binding ? In FC, the target id value is simply a logical
value and is not part of the physical transport address. As such, any device
can be associated with any target id. For coherent behavior of the system,
the desire is that once a device is assigned a target id, that id stays
associated with the device. If the device temporarily disappears then
reappears with a different physical transport address, the same target id
is used for the device - even though there was a period in which it didn't
(Continue reading)

gentoo-gwn+owner | 1 Dec 2004 17:45
Picon

Commands available for gentoo-gwn <at> robin.gentoo.org

Hello,

There exists the following options:

To unsubscribe send a mail to:

gentoo-gwn+unsubscribe <at> robin.gentoo.org

To subscribe to the digest of this list send a mail to:

gentoo-gwn+subscribe-digest <at> robin.gentoo.org

To subscribe to the nomail version of this list send a mail to:

gentoo-gwn+subscribe-nomail <at> robin.gentoo.org

The nomail version of a list means that you are reckognized as a
subscriber, but will not get any mails to the list. Useful when it's
necessary to post from several emailaddresses to a subscribers only list.

For retrieval of message number N in the archive send a mail to

gentoo-gwn+get-N <at> robin.gentoo.org

To send a mail to the list owner, send a mail to:

gentoo-gwn+owner <at> robin.gentoo.org

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
(Continue reading)

Jose R. Santos | 1 Dec 2004 17:56
Picon
Favicon

Re: phase change messages cusing slowdown with sym53c8xx_2 driver

Jose R. Santos <jrsantos <at> austin.ibm.com> [041129]:
> I'm having a bit of trouble with a integrated SCSI adapter using the 
> sym53c8xx_2 driver on a RS6K-170.  Somewhere during 2.6.9 development I started
> seeing a bunch of "phase change" messages generated every time I did any IO on 
> the disks attached to the SCSI adapter.
> 
> Nov 28 23:05:12 orb kernel: sym0: <896> rev 0x5 at pci 0000:00:0c.0 irq 20
> Nov 28 23:05:12 orb kernel: sym0: No NVRAM, ID 7, Fast-40, SE, parity checking
> Nov 28 23:05:12 orb kernel: sym0: SCSI BUS has been reset.
> Nov 28 23:05:12 orb kernel: scsi0 : sym-2.1.18m
> Nov 28 23:05:12 orb kernel: sym0:1: FAST-20 WIDE SCSI 40.0 MB/s ST (50.0 ns, offset 15)
> Nov 28 23:05:12 orb kernel:   Vendor: IBM       Model: DGHS09U	Rev: 03E0
> Nov 28 23:05:12 orb kernel:   Type:   Direct-Access		ANSI SCSI revision: 03
> Nov 28 23:05:12 orb kernel:  target0:0:1: Beginning Domain Validation
> Nov 28 23:05:12 orb kernel: sym0:1:0:phase change 6-7 9 <at> 10050390 resid=6.
> Nov 28 23:05:12 orb last message repeated 10 times
> Nov 28 23:05:12 orb kernel: sym0:1:0:phase change 6-7 9 <at> 1005039c resid=6.
> Nov 28 23:05:12 orb kernel: sym0:1:0:phase change 6-7 9 <at> 10050390 resid=6.
> Nov 28 23:05:12 orb kernel: sym0:1:0:phase change 6-7 9 <at> 10050390 resid=6.
> Nov 28 23:05:12 orb kernel: sym0:1:0:phase change 6-7 9 <at> 1005039c resid=6.
> Nov 28 23:05:12 orb kernel:  target0:0:1: Domain Validation skipping write tests
> Nov 28 23:05:12 orb kernel:  target0:0:1: Ending Domain Validation
> Nov 28 23:05:12 orb kernel: sym0:1:0:phase change 6-7 9 <at> 10050390 resid=6.
> 
> When these errors show up, the maximum performance I can get out of the disk is
> about 1.3MB/s.  After several hours, the adapters seems to receive some ABORT 
> operations and the messages stop showing.  Once this happens, performance for 
> the disk goes back to 15MB/s.

I manage to get access to another PPC64 box that has uses this same
(Continue reading)


Gmane