Rusty Trivial Russell | 1 Apr 2003 02:16
Picon
Gravatar

[TRIVIAL] [2.5 patch] remove unneeded #define LinuxVersionCode from eata.c (fwd)

From:  Adrian Bunk <bunk <at> fs.tum.de>

  Hi Linus,

  the trivial patch in the mail below still applies against and compiles 
  under 2.5.63.

  Please apply
  Adrian

  
  ----- Forwarded message from Adrian Bunk <bunk <at> fs.tum.de> -----

  Date: Sun, 12 Jan 2003 09:42:53 +0100
  From: Adrian Bunk <bunk <at> fs.tum.de>
  To: ballabio_dario <at> emc.com
  Subject: [2.5 patch] remove unneeded #define LinuxVersionCode from eata.c

  Hi Dario,

  the patch below removes the unneeded #define LinuxVersionCode from 
  eata.c. It's not used and if it was needed KERNEL_VERSION in 
  include/linux/version.h does the same.

  I've tested the compilation with 2.5.56.

  Please apply
  Adrian

--- trivial-2.5.66-bk6/drivers/scsi/eata.c.orig	2003-04-01 09:55:27.000000000 +1000
(Continue reading)

Mike Anderson | 1 Apr 2003 04:48
Picon
Favicon

Re: [PATCH] scsi_set_host_offline (resend)

Oliver Neukum [oliver <at> neukum.org] wrote:
> Am Samstag, 29. M?rz 2003 22:54 schrieb James Bottomley:
> > On Sat, 2003-03-29 at 14:53, Matthew Dharm wrote:
> > > My understanding was that I couldn't call set_device_offline with the
> > > host lock held, which is a problem because I need the host lock to
> > > traverse the device list.
> >
> > The solution we're talking about here is from the user level hotplug
> > scripts.  Once we get the remove-single-device fixed, you simply use the
> > device hot unplug script to traverse the attached SCSI devices, clean up
> > the user land (kill processes, unmount filesystems etc.) and then blow
> > the devices away.  After the host has no devices, you should simply be
> > able to trigger a host removal from within your driver.
> 
> It seems you are still trying this overcomplicated going through
> user space and back thing.
> There's no benefit at all in this. If you make this work you can just
> as well make a straightforward thing work. Which will not be a nightmare
> to make work right under all circumstances.

Matthew / James I believe I am out of sync with how much is being done
by userspace and how much is being done in the kernel. I believed there
was always userspace action to umount / close devices.

Matthew I know in the previous mail you wrote a numbered list of steps.
I believe item #2 should have called scsi_set_host_offline or
scsi_set_device_offline. Item #6 would only happen if scsi_remove_host
was called sometime prior.

I wrote the following text on the interface I thought we had / where
(Continue reading)

Zwane Mwaikambo | 2 Apr 2003 08:08
Picon

isp1020 memory trample in 2.5.66

2.5.65 was ok, 2.5.66 can't boot, there is nothing obvious in the patch 
which could have led to this. I'd try a binary search but i'm afraid i 
won't have that much free time for a while.

Box is 32way PIII-450, devices attached to the only real active isp1020 
HBA are;

qlogicisp : new isp1020 revision ID (5)
qlogicisp : interrupt 233 already in use
scsi0 : QLogic ISP1020 SCSI on PCI bus 01 device 70 irq 41 MEM base 
0xf8c1a000
  Vendor: IBM       Model: DRHS36V           Rev: 0270
  Type:   Direct-Access                      ANSI SCSI revision: 03
  Vendor: IBM       Model: DRHS36V           Rev: 0270
  Type:   Direct-Access                      ANSI SCSI revision: 03
  Vendor: PLEXTOR   Model: CD-ROM PX-32CS    Rev: 1.02
  Type:   CD-ROM                             ANSI SCSI revision: 02
scsi1 : QLogic ISP1020 SCSI on PCI bus 04 device 70 irq 89 MEM base 0xf8c1c000
SCSI device sda: 72170879 512-byte hdwr sectors (36951 MB)
SCSI device sda: drive cache: write through
 sda: sda1 sda2 sda3
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
SCSI device sdb: 72170879 512-byte hdwr sectors (36951 MB)
SCSI device sdb: drive cache: write through
 sdb: unknown partition table

Unable to handle kernel paging request at virtual address 6b6b6b6b
 printing eip:
6b6b6b6b
*pde = 00000000
(Continue reading)

Matthew Dharm | 2 Apr 2003 09:42

Re: [PATCH] scsi_set_host_offline (resend)

On Mon, Mar 31, 2003 at 06:48:06PM -0800, Mike Anderson wrote:
> Matthew / James I believe I am out of sync with how much is being done
> by userspace and how much is being done in the kernel. I believed there
> was always userspace action to umount / close devices.

I have no objection to userspace being notified -- I only object to
requiring userspace to complete the unplug operation.

> Matthew I know in the previous mail you wrote a numbered list of steps.
> I believe item #2 should have called scsi_set_host_offline or
> scsi_set_device_offline. Item #6 would only happen if scsi_remove_host
> was called sometime prior.

The assumption was that #5 was the call to scsi_remove_host() -- the only
question in my mind is: How do I know it is 'safe' to call that?

> I wrote the following text on the interface I thought we had / where
> trying to complete. I would like to add to this so that we possibly
> could archive an interface contract between the LLDD and scsi-mid.

Based on my reading of the following, userspace is notified but not
required to take any action.  Would that be accurate?

> 2.5 SCSI host register interfaces (scsi_add_host / scsi_remove_host)
> 
> 1. LLDD call graph standard
> 
> (PROBE)
> LLDD                  Mid                  Sysfs
> scsi_register      -->
(Continue reading)

Patrick Mansfield | 2 Apr 2003 18:02
Picon
Favicon

Re: isp1020 memory trample in 2.5.66

On Wed, Apr 02, 2003 at 01:08:54AM -0500, Zwane Mwaikambo wrote:
> 2.5.65 was ok, 2.5.66 can't boot, there is nothing obvious in the patch 
> which could have led to this. I'd try a binary search but i'm afraid i 
> won't have that much free time for a while.

> Box is 32way PIII-450, devices attached to the only real active isp1020 
> HBA are;

I've been booting OK with 2.5.66 with isp1020 and qlogicisp driver with
multiple disks, though the boot sometimes hangs.

I've also booted OK with the feral driver.

> qlogicisp : new isp1020 revision ID (5)
> qlogicisp : interrupt 233 already in use
> scsi0 : QLogic ISP1020 SCSI on PCI bus 01 device 70 irq 41 MEM base 
> 0xf8c1a000
>   Vendor: IBM       Model: DRHS36V           Rev: 0270
>   Type:   Direct-Access                      ANSI SCSI revision: 03
>   Vendor: IBM       Model: DRHS36V           Rev: 0270
>   Type:   Direct-Access                      ANSI SCSI revision: 03
>   Vendor: PLEXTOR   Model: CD-ROM PX-32CS    Rev: 1.02
>   Type:   CD-ROM                             ANSI SCSI revision: 02
> scsi1 : QLogic ISP1020 SCSI on PCI bus 04 device 70 irq 89 MEM base 0xf8c1c000
> SCSI device sda: 72170879 512-byte hdwr sectors (36951 MB)
> SCSI device sda: drive cache: write through
>  sda: sda1 sda2 sda3
> Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
> SCSI device sdb: 72170879 512-byte hdwr sectors (36951 MB)
> SCSI device sdb: drive cache: write through
(Continue reading)

Patrick Mansfield | 2 Apr 2003 18:08
Picon
Favicon

Re: [PATCH] some more entries for the largelun list

On Thu, Mar 27, 2003 at 04:07:44PM +0100, Christoph Hellwig wrote:
> 
> --- 1.65/drivers/scsi/scsi_scan.c	Mon Mar 10 09:23:23 2003
> +++ edited/drivers/scsi/scsi_scan.c	Fri Mar 21 21:14:13 2003
>  <at>  <at>  -191,6 +191,13  <at>  <at> 
>  	{"IBM", "ProFibre 4000R", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
>  	{"SUN", "T300", "*", BLIST_SPARSELUN},
>  	{"SUN", "T4", "*", BLIST_SPARSELUN},
> +	{"SGI", "RAID3", "*", BLIST_SPARSELUN},
> +	{"SGI", "RAID5", "*", BLIST_SPARSELUN},
> +	{"SGI", "TP9100", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
> +	{"SGI", "TP9300", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
> +	{"SGI", "TP9400", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
> +	{"SGI", "TP9500", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
> +	{"MYLEX", "DACARMRB", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
>  	{ NULL, NULL, NULL, 0 },
>  };

Can any of the above instead report as SCSI-3? That is a much better
solution, especially since these seem to be fibre attached, and SCSI-3
also enables report luns support.

Most disk arrays (and even some standard disk drives) can change the SCSI
level.

-- Patrick Mansfield
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Alan Stern | 2 Apr 2003 20:49
Picon
Favicon

Re: START-STOP under Linux 2.4

Greg:

This patch for 2.4.21-pre6 (a backport from 2.5) removes a source of
problems for many usb-storage devices by replacing a START-STOP command,
used to determine if the drive media is loaded, with a TEST-UNIT-READY.  
In the past people have handled this by creating entries in unusual_devs.h
with the US_FL_START_STOP flag; now that should no longer be necessary.

Alan Stern

On Wed, 2 Apr 2003, Matthew Dharm wrote:

> Send it to Greg K-H -- he'll send it to Marcello.
> 
> Matt
> 
> On Wed, Apr 02, 2003 at 10:24:47AM -0500, Alan Stern wrote:
> > Great!  I'll try to get this into the official kernel source.
> > 
> > Matt:  Do you know the appropriate person to send this patch to for
> > inclusion in 2.4.21?
> > 
> > Alan Stern
> > 
> > 
> > On Tue, 1 Apr 2003, John Goerzen wrote:
> > 
> > > Alan Stern <stern <at> rowland.harvard.edu> writes:
> > >
> > > > Based on the kernel log you posted earlier, it looks like your problem may
(Continue reading)

Mike Anderson | 3 Apr 2003 04:05
Picon
Favicon

Re: [PATCH] scsi_set_host_offline (resend)

Matthew Dharm [mdharm-scsi <at> one-eyed-alien.net] wrote:
> On Mon, Mar 31, 2003 at 06:48:06PM -0800, Mike Anderson wrote:
> > Matthew / James I believe I am out of sync with how much is being done
> > by userspace and how much is being done in the kernel. I believed there
> > was always userspace action to umount / close devices.
> 
> I have no objection to userspace being notified -- I only object to
> requiring userspace to complete the unplug operation.
> 

If the unplug operation includes cleanup (i.e. free of the memory) then
userspace needs to be involved. 

> > Matthew I know in the previous mail you wrote a numbered list of steps.
> > I believe item #2 should have called scsi_set_host_offline or
> > scsi_set_device_offline. Item #6 would only happen if scsi_remove_host
> > was called sometime prior.
> 
> The assumption was that #5 was the call to scsi_remove_host() -- the only
> question in my mind is: How do I know it is 'safe' to call that?
> 

The changes I am making would allow you to call scsi_remove_host()
anytime and have your release called later when ref counts go to zero.

I am traveling until late Friday night so hopefully I will have
something to post after I get back.

> > I wrote the following text on the interface I thought we had / where
> > trying to complete. I would like to add to this so that we possibly
(Continue reading)

Zwane Mwaikambo | 3 Apr 2003 10:27
Picon

Re: isp1020 memory trample in 2.5.66

On Wed, 2 Apr 2003, Patrick Mansfield wrote:

> I've been booting OK with 2.5.66 with isp1020 and qlogicisp driver with
> multiple disks, though the boot sometimes hangs.
> 
> I've also booted OK with the feral driver.

I'll be prepping a kernel with that.

> This looks a lot like the oops when trying to send IO to more than one
> disk at a time with the isp1020 + qlogicisp.
> 
> Is there something different causing IO to muliple disks at that point?

Yes it is possible as i have another disk on the same HBA with /usr

> I hit this once when I enabled parallel fsck (it didn't oops until after I
> got a late oops, and rebooted).
> 
> Martin hit it when the queue depth was not properly checked.
> 
> wli has hit it with parallel mkfs (or something).

Ok this thing sounds _very_ fragile ;)

> The following thread was pretty useful, Doug L mentions that the qlogicisp
> does bad things, starting with Martin's analysis:
> 
> http://marc.theaimsgroup.com/?l=linux-kernel&m=104457083601573&w=2

(Continue reading)

William Lee Irwin III | 3 Apr 2003 10:55

Re: isp1020 memory trample in 2.5.66

On Wed, 2 Apr 2003, Patrick Mansfield wrote:
>> Martin hit it when the queue depth was not properly checked.
>> wli has hit it with parallel mkfs (or something).

On Thu, Apr 03, 2003 at 03:27:38AM -0500, Zwane Mwaikambo wrote:
> Ok this thing sounds _very_ fragile ;)

Debugging ode this obfuscated and crappy is as hopeless as trying to
debug the nvidia binary-only oops-o-rama.

What are the odds of just throwing away the isp1020 and replacing it
with anything else? It won't fix it, but it can't be fixed due to
utter lack of information about the things and/or lack of maintainers
with information hidden by NDA's anyway.

-- wli
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Gmane