... at least for PPC targets.
There was a set of patches applied for the 2.4.21-rc2 kernel
(some seem _very_ strange, maybe endianness issues...)
that makes sbp2 fail to recognize my external firewire drives.
The only way I have for now to make things work is to come back
to the 2.4.21-rc1 version, which work correctly for my Mac
and my PC (VIA Chipset & Firewire chip).
On the Mac (Ibook), I can see my disks in /proc/bus/ieee1394/devices:
Node[01:1023] GUID[000393fffeab0e76]:
Vendor ID: `Linux OHCI-1394' [0x000000]
Capabilities: 0x0083c0
Bus Options:
IRMC(1) CMC(1) ISC(1) BMC(0) PMC(0) GEN(8)
LSPD(2) MAX_REC(2048) CYC_CLK_ACC(0)
Host Node Status:
Host Driver : ohci1394
Nodes connected : 2
Nodes active : 2
SelfIDs received: 2
Irm ID : [01:1023]
BusMgr ID : [01:1023]
In Bus Reset : no
Root : yes
Cycle Master : yes
IRM : yes
Bus Manager : yes
Node[00:1023] GUID[00d04b0ce0900195]:
Vendor ID: `Oxford ' [0x00d04b]
Capabilities: 0x0083c0
Bus Options:
IRMC(0) CMC(0) ISC(0) BMC(0) PMC(0) GEN(0)
LSPD(0) MAX_REC(64) CYC_CLK_ACC(255)
Unit Directory 0:
Vendor/Model ID: Oxford [00d04b] / 911G [000001]
Software Specifier ID: 00609e
Software Version: 010483
Driver: SBP2 Driver
Length (in quads): 8
but not in /proc/scsi/scsi
Here's the output of /proc/scsi/sbp2/1 (with the working driver):
IEEE-1394 SBP-2 protocol driver (host: ohci1394)
$Rev: 878 $ James Goodwin <[email protected]>
SBP-2 module load options:
- Max speed supported: S400
- Max sectors per I/O supported: 255
- Max outstanding commands supported: 64
- Max outstanding commands per lun supported: 1
- Serialized I/O (debug): no
- Exclusive login: yes
I may do more tests to localize the bug, if I only knew which ones I
should do...
/proc/cpuinfo:
cpu : 750FX
temperature : 2 C (uncalibrated)
clock : 700MHz
revision : 1.18 (pvr 7000 0112)
bogomips : 1389.36
machine : PowerBook4,3
motherboard : PowerBook4,3 MacRISC2 MacRISC Power Macintosh
detected as : 257 (iBook 2 rev. 2)
pmac flags : 0000000b
L2 cache : 512K unified
memory : 384MB
pmac-generation : NewWorld
/proc/pci:
PCI devices found:
Bus 0, device 11, function 0:
Host bridge: Apple Computer Inc. UniNorth/Pangea AGP (rev 0).
Master Capable. Latency=16.
Bus 16, device 11, function 0:
Host bridge: Apple Computer Inc. UniNorth/Pangea PCI (rev 0).
Master Capable. Latency=16.
Bus 16, device 23, function 0:
Class ff00: Apple Computer Inc. KeyLargo/Pangea Mac I/O (rev 0).
Master Capable. Latency=16.
Non-prefetchable 32 bit memory at 0x80000000 [0x8007ffff].
--
Jocelyn Mayer <[email protected]>
On 02 Jun 2003 21:36:22 +0200
Jocelyn Mayer <[email protected]> wrote:
> ... at least for PPC targets.
As a datapoint, works fine for me with my x86 laptop:
(keller) 497$ cat /proc/bus/ieee1394/devices
Node[00:1023] GUID[0001d2000003a4ec]:
Vendor ID: `Oxford Semiconductor Ltd. ' [0x0001d2]
Capabilities: 0x0083c0
Bus Options:
IRMC(0) CMC(0) ISC(0) BMC(0) PMC(0) GEN(0)
LSPD(0) MAX_REC(64) CYC_CLK_ACC(255)
Unit Directory 0:
Vendor/Model ID: Oxford Semiconductor Ltd. [0001d2] / OXFORD IDE Device LUN 0 [42a258]
Software Specifier ID: 00609e
Software Version: 010483
Driver: SBP2 Driver
Length (in quads): 8
Node[01:1023] GUID[474fc000075f5001]:
Vendor ID: `Linux OHCI-1394' [0x000000]
Capabilities: 0x0083c0
Bus Options:
IRMC(1) CMC(1) ISC(1) BMC(0) PMC(0) GEN(0)
LSPD(2) MAX_REC(2048) CYC_CLK_ACC(0)
Host Node Status:
Host Driver : ohci1394
Nodes connected : 2
Nodes active : 2
SelfIDs received: 2
Irm ID : [01:1023]
BusMgr ID : [63:1023]
In Bus Reset : no
Root : yes
Cycle Master : yes
IRM : yes
Bus Manager : no
You have new mail in /var/mail/georgn
(keller) 498$ cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: IC35L120 Model: AVVA07-0 Rev:
Type: Direct-Access ANSI SCSI revision: 06
(keller) 499$ cat /proc/scsi/sbp2_0/0
Host scsi0 : SBP-2 IEEE-1394 (ohci1394)
Driver version : $Rev: 906 $ James Goodwin <[email protected]>
Module options :
max_speed : S800
max_sectors : 255
serialize_io : no
exclusive_login : yes
Attached devices :
[Channel: 00, Id: 00, Lun: 00] Direct-Access IC35L120 AVVA07-0
(keller) 500$ uname -a
Linux keller 2.4.21-rc6-rmap15j #1 Sun Jun 1 18:43:25 EDT 2003 i686 GNU/Linux
On Mon, 2003-06-02 at 22:34, Georg Nikodym wrote:
> On 02 Jun 2003 21:36:22 +0200
> Jocelyn Mayer <[email protected]> wrote:
>
> > ... at least for PPC targets.
>
> As a datapoint, works fine for me with my x86 laptop:
Hi,
OK, so it should be an endianness related problem...
I didn't test this on a PC because I need (want ?)
to always use the same kernel on my Mac & my PC
so I can test my patches always in the same conditions.
It gives me a start point to investigate...
Regards.
--
Jocelyn Mayer <[email protected]>
>
On Mon, Jun 02, 2003 at 11:20:32PM +0200, Jocelyn Mayer wrote:
> On Mon, 2003-06-02 at 22:34, Georg Nikodym wrote:
> > On 02 Jun 2003 21:36:22 +0200
> > Jocelyn Mayer <[email protected]> wrote:
> >
> > > ... at least for PPC targets.
> >
> > As a datapoint, works fine for me with my x86 laptop:
>
> Hi,
>
> OK, so it should be an endianness related problem...
> I didn't test this on a PC because I need (want ?)
> to always use the same kernel on my Mac & my PC
> so I can test my patches always in the same conditions.
> It gives me a start point to investigate...
No, it's a rescan-scsi-bus.sh issue. Get the script, and execute it.
Hotplug for 2.4.x scsi is a fantasy. Just so happens it used to work,
but that "work" used to cause oopses.
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
On Tue, 2003-06-03 at 13:36, Ben Collins wrote:
> On Mon, Jun 02, 2003 at 11:20:32PM +0200, Jocelyn Mayer wrote:
> > On Mon, 2003-06-02 at 22:34, Georg Nikodym wrote:
> > > On 02 Jun 2003 21:36:22 +0200
> > > Jocelyn Mayer <[email protected]> wrote:
> > >
> > > > ... at least for PPC targets.
> > >
> > > As a datapoint, works fine for me with my x86 laptop:
> >
> > Hi,
> >
> > OK, so it should be an endianness related problem...
> > I didn't test this on a PC because I need (want ?)
> > to always use the same kernel on my Mac & my PC
> > so I can test my patches always in the same conditions.
> > It gives me a start point to investigate...
>
> No, it's a rescan-scsi-bus.sh issue. Get the script, and execute it.
> Hotplug for 2.4.x scsi is a fantasy. Just so happens it used to work,
> but that "work" used to cause oopses.
Hi,
Thanks for your help, but I think you're wrong:
First, I never trust hotplug or other tools like this:
I do all insmod by hand, so I know all drivers have been loaded.
What is hotplug supposed to do (but wasn't in previous driver
version...) ?
The second thing I see is that it used to work,
before 2.4.21-rc2. The only difference is in the kernel driver,
so it should work with no user-space tool, as it used to.
If not, the driver is now buggy...
Regards.
--
Jocelyn Mayer <[email protected]>
On 03 Jun 2003 20:11:57 +0200
Jocelyn Mayer <[email protected]> wrote:
> Thanks for your help, but I think you're wrong:
I doubt it. Ben's one of the authorities on this stuff.
> First, I never trust hotplug or other tools like this:
> I do all insmod by hand, so I know all drivers have been loaded.
> What is hotplug supposed to do (but wasn't in previous driver
> version...) ?
I compile this stuff directly into my kernel. Doesn't make a
difference.
> The second thing I see is that it used to work,
> before 2.4.21-rc2. The only difference is in the kernel driver,
> so it should work with no user-space tool, as it used to.
> If not, the driver is now buggy...
Well, I've _always_ needed either rescan-scsi-bus.sh (or scsiadd -s
since I switched to Debian). If there's some magic that you've been
doing that obviates this requirement, we're all ears.
-g
On Tue, 2003-06-03 at 20:27, Georg Nikodym wrote:
> On 03 Jun 2003 20:11:57 +0200
> Jocelyn Mayer <[email protected]> wrote:
>
> > Thanks for your help, but I think you're wrong:
>
> I doubt it. Ben's one of the authorities on this stuff.
Right, I can believe this.
>
> > First, I never trust hotplug or other tools like this:
> > I do all insmod by hand, so I know all drivers have been loaded.
> > What is hotplug supposed to do (but wasn't in previous driver
> > version...) ?
>
> I compile this stuff directly into my kernel. Doesn't make a
> difference.
>
> > The second thing I see is that it used to work,
> > before 2.4.21-rc2. The only difference is in the kernel driver,
> > so it should work with no user-space tool, as it used to.
> > If not, the driver is now buggy...
>
> Well, I've _always_ needed either rescan-scsi-bus.sh (or scsiadd -s
> since I switched to Debian). If there's some magic that you've been
> doing that obviates this requirement, we're all ears.
>
> -g
No magics.
I must precise that I don't use any standard distribution:
I bootstrapped my own distrib from scratch,
using sources from the web.
Also note that I don't have neither rescan-scsi-bus nor scsiadd
anywhere on this machine.
I just did a new test a few minutes ago.
To be sure that there are nothing done that I can't control,
I removed /sbin/hotplug (rm -f /sbin/hotplug).
I did exactly:
modprobe ieee1394
modprobe cmp
modprobe ohci1394
modprobe amdtp
modprobe sd_mod
modprobe sbp2
(I use modprobe so I don't have to write the whole path for insmod,
but do all step by step...)
Before this I had:
/proc/scsi/scsi:
root:~$ cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: SONY Model: CD-RW CRX800E Rev: 1.3p
Type: CD-ROM ANSI SCSI revision: 02
After I inserted sbp2, I get:
root:~$ cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: SONY Model: CD-RW CRX800E Rev: 1.3p
Type: CD-ROM ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 00 Lun: 00
Vendor: Maxtor 6 Model: Y080L0 Rev: YAR4
Type: Direct-Access ANSI SCSI revision: 06
The Maxtor disk is my Firewire one !
I currently use 2.4.21-rc6 kernel with 2.4.21-rc1 ieee1394 stack:
jocelyn:~$ cat /proc/version
Linux version 2.4.21-rc6-compat (jocelyn@(none)) (gcc version 3.2) #3
Sun Jun 1 21:02:23 CEST 2003
jocelyn:~$ cat /proc/modules
sbp2 19024 0 (unused)
sd_mod 12332 0 (unused)
amdtp 8596 0 (unused)
ohci1394 28016 0 [amdtp]
cmp 2532 0 [amdtp]
ieee1394 45288 0 [sbp2 amdtp ohci1394 cmp]
sungem 25840 1 (autoclean)
sungem_phy 5952 0 (autoclean) [sungem]
jocelyn:~$ cat /proc/scsi/sbp2/1
IEEE-1394 SBP-2 protocol driver (host: ohci1394)
$Rev: 878 $ James Goodwin <[email protected]>
SBP-2 module load options:
- Max speed supported: S400
- Max sectors per I/O supported: 255
- Max outstanding commands supported: 64
- Max outstanding commands per lun supported: 1
- Serialized I/O (debug): no
- Exclusive login: yes
ote that I don't have neither rescan-scsi-bus nor scsiadd
anywhere on this machine.
I just did a new test a few minutes ago.
To be sure that there are nothing done that I can't control,
I removed /sbin/hotplug (rm -f /sbin/hotplug).
I did exactly:
modprobe ieee1394
modprobe cmp
modprobe ohci1394
modprobe amdtp
modprobe sd_mod
modprobe sbp2
as root.
(I use modprobe so I don't have to write the whole path for insmod,
but do all step by step...)
Before this I had:
/proc/scsi/scsi:
root:~$ cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: SONY Model: CD-RW CRX800E Rev: 1.3p
Type: CD-ROM ANSI SCSI revision: 02
After I inserted sbp2, I get:
root:~$ cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: SONY Model: CD-RW CRX800E Rev: 1.3p
Type: CD-ROM ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 00 Lun: 00
Vendor: Maxtor 6 Model: Y080L0 Rev: YAR4
Type: Direct-Access ANSI SCSI revision: 06
The Maxtor disk is my Firewire one !
I currently use 2.4.21-rc6 kernel with 2.4.21-rc1 ieee1394 stack:
jocelyn:~$ cat /proc/version
Linux version 2.4.21-rc6-compat (jocelyn@(none)) (gcc version 3.2) #3
Sun Jun 1 21:02:23 CEST 2003
jocelyn:~$ cat /proc/modules
sbp2 19024 0 (unused)
sd_mod 12332 0 (unused)
amdtp 8596 0 (unused)
ohci1394 28016 0 [amdtp]
cmp 2532 0 [amdtp]
ieee1394 45288 0 [sbp2 amdtp ohci1394 cmp]
sungem 25840 1 (autoclean)
sungem_phy 5952 0 (autoclean) [sungem]
jocelyn:~$ cat /proc/scsi/sbp2/1
IEEE-1394 SBP-2 protocol driver (host: ohci1394)
$Rev: 878 $ James Goodwin <[email protected]>
SBP-2 module load options:
- Max speed supported: S400
- Max sectors per I/O supported: 255
- Max outstanding commands supported: 64
- Max outstanding commands per lun supported: 1
- Serialized I/O (debug): no
- Exclusive login: yes
jocelyn:~$ cat /proc/bus/ieee1394/devices
Node[00:1023] GUID[000393fffeab0e76]:
Vendor ID: `Linux OHCI-1394' [0x000000]
Capabilities: 0x0083c0
Bus Options:
IRMC(1) CMC(1) ISC(1) BMC(0) PMC(0) GEN(8)
LSPD(2) MAX_REC(2048) CYC_CLK_ACC(0)
Host Node Status:
Host Driver : ohci1394
Nodes connected : 2
Nodes active : 2
SelfIDs received: 2
Irm ID : [00:1023]
BusMgr ID : [00:1023]
In Bus Reset : no
Root : no
Cycle Master : no
IRM : yes
Bus Manager : yes
Node[01:1023] GUID[00d04b0ce0900195]:
Vendor ID: `Oxford ' [0x00d04b]
Capabilities: 0x0083c0
Bus Options:
IRMC(0) CMC(0) ISC(0) BMC(0) PMC(0) GEN(0)
LSPD(0) MAX_REC(64) CYC_CLK_ACC(255)
Unit Directory 0:
Vendor/Model ID: Oxford [00d04b] / 911G [000001]
Software Specifier ID: 00609e
Software Version: 010483
Driver: SBP2 Driver
Length (in quads): 8
So, I'm quite sure that it should work with no special helper !
Is there any other informations I should give,
or things I should do to understand the problem ?
--
Jocelyn Mayer <[email protected]>
On Tue, 3 Jun 2003, Jocelyn Mayer wrote:
> On Tue, 2003-06-03 at 20:27, Georg Nikodym wrote:
> > On 03 Jun 2003 20:11:57 +0200
> > Jocelyn Mayer <[email protected]> wrote:
> >
> > > Thanks for your help, but I think you're wrong:
> >
> > I doubt it. Ben's one of the authorities on this stuff.
>
> Right, I can believe this.
>
> >
> > > First, I never trust hotplug or other tools like this:
> > > I do all insmod by hand, so I know all drivers have been loaded.
> > > What is hotplug supposed to do (but wasn't in previous driver
> > > version...) ?
> >
> > I compile this stuff directly into my kernel. Doesn't make a
> > difference.
> >
> > > The second thing I see is that it used to work,
> > > before 2.4.21-rc2. The only difference is in the kernel driver,
> > > so it should work with no user-space tool, as it used to.
> > > If not, the driver is now buggy...
> >
> > Well, I've _always_ needed either rescan-scsi-bus.sh (or scsiadd -s
> > since I switched to Debian). If there's some magic that you've been
> > doing that obviates this requirement, we're all ears.
> >
> > -g
>
> No magics.
> I must precise that I don't use any standard distribution:
> I bootstrapped my own distrib from scratch,
> using sources from the web.
> Also note that I don't have neither rescan-scsi-bus nor scsiadd
> anywhere on this machine.
>
> I just did a new test a few minutes ago.
> To be sure that there are nothing done that I can't control,
> I removed /sbin/hotplug (rm -f /sbin/hotplug).
>
> I did exactly:
>
> modprobe ieee1394
> modprobe cmp
> modprobe ohci1394
> modprobe amdtp
> modprobe sd_mod
> modprobe sbp2
>
> (I use modprobe so I don't have to write the whole path for insmod,
> but do all step by step...)
>
> Before this I had:
> /proc/scsi/scsi:
> root:~$ cat /proc/scsi/scsi
> Attached devices:
> Host: scsi0 Channel: 00 Id: 00 Lun: 00
> Vendor: SONY Model: CD-RW CRX800E Rev: 1.3p
> Type: CD-ROM ANSI SCSI revision: 02
>
> After I inserted sbp2, I get:
>
> root:~$ cat /proc/scsi/scsi
> Attached devices:
> Host: scsi0 Channel: 00 Id: 00 Lun: 00
> Vendor: SONY Model: CD-RW CRX800E Rev: 1.3p
> Type: CD-ROM ANSI SCSI revision: 02
> Host: scsi1 Channel: 00 Id: 00 Lun: 00
> Vendor: Maxtor 6 Model: Y080L0 Rev: YAR4
> Type: Direct-Access ANSI SCSI revision: 06
>
> The Maxtor disk is my Firewire one !
>
> I currently use 2.4.21-rc6 kernel with 2.4.21-rc1 ieee1394 stack:
>
> jocelyn:~$ cat /proc/version
> Linux version 2.4.21-rc6-compat (jocelyn@(none)) (gcc version 3.2) #3
> Sun Jun 1 21:02:23 CEST 2003
>
> jocelyn:~$ cat /proc/modules
> sbp2 19024 0 (unused)
> sd_mod 12332 0 (unused)
> amdtp 8596 0 (unused)
> ohci1394 28016 0 [amdtp]
> cmp 2532 0 [amdtp]
> ieee1394 45288 0 [sbp2 amdtp ohci1394 cmp]
> sungem 25840 1 (autoclean)
> sungem_phy 5952 0 (autoclean) [sungem]
>
> jocelyn:~$ cat /proc/scsi/sbp2/1
> IEEE-1394 SBP-2 protocol driver (host: ohci1394)
> $Rev: 878 $ James Goodwin <[email protected]>
> SBP-2 module load options:
> - Max speed supported: S400
> - Max sectors per I/O supported: 255
> - Max outstanding commands supported: 64
> - Max outstanding commands per lun supported: 1
> - Serialized I/O (debug): no
> - Exclusive login: yes
>
> ote that I don't have neither rescan-scsi-bus nor scsiadd
> anywhere on this machine.
>
> I just did a new test a few minutes ago.
> To be sure that there are nothing done that I can't control,
> I removed /sbin/hotplug (rm -f /sbin/hotplug).
>
> I did exactly:
>
> modprobe ieee1394
> modprobe cmp
> modprobe ohci1394
> modprobe amdtp
> modprobe sd_mod
> modprobe sbp2
>
> as root.
>
> (I use modprobe so I don't have to write the whole path for insmod,
> but do all step by step...)
>
> Before this I had:
> /proc/scsi/scsi:
> root:~$ cat /proc/scsi/scsi
> Attached devices:
> Host: scsi0 Channel: 00 Id: 00 Lun: 00
> Vendor: SONY Model: CD-RW CRX800E Rev: 1.3p
> Type: CD-ROM ANSI SCSI revision: 02
>
> After I inserted sbp2, I get:
>
> root:~$ cat /proc/scsi/scsi
> Attached devices:
> Host: scsi0 Channel: 00 Id: 00 Lun: 00
> Vendor: SONY Model: CD-RW CRX800E Rev: 1.3p
> Type: CD-ROM ANSI SCSI revision: 02
> Host: scsi1 Channel: 00 Id: 00 Lun: 00
> Vendor: Maxtor 6 Model: Y080L0 Rev: YAR4
> Type: Direct-Access ANSI SCSI revision: 06
>
> The Maxtor disk is my Firewire one !
>
> I currently use 2.4.21-rc6 kernel with 2.4.21-rc1 ieee1394 stack:
>
> jocelyn:~$ cat /proc/version
> Linux version 2.4.21-rc6-compat (jocelyn@(none)) (gcc version 3.2) #3
> Sun Jun 1 21:02:23 CEST 2003
>
> jocelyn:~$ cat /proc/modules
> sbp2 19024 0 (unused)
> sd_mod 12332 0 (unused)
> amdtp 8596 0 (unused)
> ohci1394 28016 0 [amdtp]
> cmp 2532 0 [amdtp]
> ieee1394 45288 0 [sbp2 amdtp ohci1394 cmp]
> sungem 25840 1 (autoclean)
> sungem_phy 5952 0 (autoclean) [sungem]
>
> jocelyn:~$ cat /proc/scsi/sbp2/1
> IEEE-1394 SBP-2 protocol driver (host: ohci1394)
> $Rev: 878 $ James Goodwin <[email protected]>
> SBP-2 module load options:
> - Max speed supported: S400
> - Max sectors per I/O supported: 255
> - Max outstanding commands supported: 64
> - Max outstanding commands per lun supported: 1
> - Serialized I/O (debug): no
> - Exclusive login: yes
>
> jocelyn:~$ cat /proc/bus/ieee1394/devices
> Node[00:1023] GUID[000393fffeab0e76]:
> Vendor ID: `Linux OHCI-1394' [0x000000]
> Capabilities: 0x0083c0
> Bus Options:
> IRMC(1) CMC(1) ISC(1) BMC(0) PMC(0) GEN(8)
> LSPD(2) MAX_REC(2048) CYC_CLK_ACC(0)
> Host Node Status:
> Host Driver : ohci1394
> Nodes connected : 2
> Nodes active : 2
> SelfIDs received: 2
> Irm ID : [00:1023]
> BusMgr ID : [00:1023]
> In Bus Reset : no
> Root : no
> Cycle Master : no
> IRM : yes
> Bus Manager : yes
> Node[01:1023] GUID[00d04b0ce0900195]:
> Vendor ID: `Oxford ' [0x00d04b]
> Capabilities: 0x0083c0
> Bus Options:
> IRMC(0) CMC(0) ISC(0) BMC(0) PMC(0) GEN(0)
> LSPD(0) MAX_REC(64) CYC_CLK_ACC(255)
> Unit Directory 0:
> Vendor/Model ID: Oxford [00d04b] / 911G [000001]
> Software Specifier ID: 00609e
> Software Version: 010483
> Driver: SBP2 Driver
> Length (in quads): 8
>
>
> So, I'm quite sure that it should work with no special helper !
> Is there any other informations I should give,
> or things I should do to understand the problem ?
>
> --
> Jocelyn Mayer <[email protected]>
>
Something else is fishy. If I put all the modules for my firewire
drive, in the correct order, in an initial RAM disk (initrd),
and then attempt to use the firewire drive as the root file-system,
it is not available. If I install all the modules for the firewire
drives from initrd, then mount a SCSI root file-system, the firewire
drive is still not available!!! An attempt to access the raw device
with `od` shows 'no such device or address'. If I remove all the
firewire modules, then install them again, like magic the drive
becomes available! This is not good magic. This is on 2.4.20 (RedHat 9
tools)
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
> First, I never trust hotplug or other tools like this:
> I do all insmod by hand, so I know all drivers have been loaded.
> What is hotplug supposed to do (but wasn't in previous driver
> version...) ?
I didn't say CONFIG_HOTPLUG, I said hotplug. Basically SCSI in 2.4 will
not let recognize devices that were not present when the scsi-host was
initially registered with the SCSI stack. You have to run
rescan-scsi-bus.sh (or manually send the add/remove commands via
procfs).
Please read the linux-kernel and/or linux1394-devel mailing list
archives. I really hate dredging this all up again.
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
On Tue, 2003-06-03 at 20:54, Ben Collins wrote:
> > First, I never trust hotplug or other tools like this:
> > I do all insmod by hand, so I know all drivers have been loaded.
> > What is hotplug supposed to do (but wasn't in previous driver
> > version...) ?
>
> I didn't say CONFIG_HOTPLUG, I said hotplug. Basically SCSI in 2.4 will
> not let recognize devices that were not present when the scsi-host was
> initially registered with the SCSI stack. You have to run
> rescan-scsi-bus.sh (or manually send the add/remove commands via
> procfs).
>
> Please read the linux-kernel and/or linux1394-devel mailing list
> archives. I really hate dredging this all up again.
Well, I did understand well hotplug...
I did read what's said about SBP2 on linux1394.org, BUT:
please read my latest mail, I did some try with the 2.4.21-rc1 ieee1394
stack, without /sbin/hotplug, and it worked.
I have neither rescan-scsi-bus.sh, nor scsiadd anywhere on this machine.
So, I'm sure that no user-space tool have been called by the kernel.
- I NEVER need to do an "echo ... > /proc/scsi/scsi" to see the device
(I tell again that I never use automatic tools to do this kind of
low level stuffs).
- I NEVER have to do this to see an USB mass-storage device:
I'm *REALLY* sure of this, as I wrote a very simple hotplug
and automounter for some embedded hardware which uses USB mass
storage devices. So, I don't see why SBP2 should need this...
- Please take a look at this session:
First, I reboot the Ibook:
root:~$ reboot
root:~$
Broadcast message from root (pts/0) (Tue Jun 3 22:06:13 2003):
The system is going down for reboot NOW!
Connection to mac closed by remote host.
Connection to mac closed.
jma ~ > ssh jocelyn@mac
jocelyn@mac's password:
jocelyn:~$ su -
Password:
root:~$ ls -l /bin/hotplug
ls: /bin/hotplug: No such file or directory
root:/lib/modules/2.4.21-rc6-compat/kernel/drivers/ieee1394$ cat
/proc/sys/kernel/hotplug
/sbin/hotplug
root:~$ cd /lib/modules/2.4.21-rc6-compat/kernel/drivers/ieee1394/
root:/lib/modules/2.4.21-rc6-compat/kernel/drivers/ieee1394$ insmod
./ieee1394.o
root:/lib/modules/2.4.21-rc6-compat/kernel/drivers/ieee1394$ insmod
./cmp.o
root:/lib/modules/2.4.21-rc6-compat/kernel/drivers/ieee1394$ cat
/proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: SONY Model: CD-RW CRX800E Rev: 1.3p
Type: CD-ROM ANSI SCSI revision: 02
root:/lib/modules/2.4.21-rc6-compat/kernel/drivers/ieee1394$ insmod
./ohci1394.o
root:/lib/modules/2.4.21-rc6-compat/kernel/drivers/ieee1394$ insmod
./amdtp.o
root:/lib/modules/2.4.21-rc6-compat/kernel/drivers/ieee1394$ insmod
../scsi/sd_m
od.o
root:/lib/modules/2.4.21-rc6-compat/kernel/drivers/ieee1394$ insmod
./sbp2.o
root:/lib/modules/2.4.21-rc6-compat/kernel/drivers/ieee1394$ cat
/proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: SONY Model: CD-RW CRX800E Rev: 1.3p
Type: CD-ROM ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 00 Lun: 00
Vendor: Maxtor 6 Model: Y080L0 Rev: YAR4
Type: Direct-Access ANSI SCSI revision: 06
So I NEVER write anything to /proc/scsi/scsi,
I got NO /sbin/hotplug, I use only insmod,
so I can have no side-effect due to modprobe usage,
and it works PERFECTLY on the Ibook,
using the 2.4.21-rc1 ieee1394 stack.
So, I'm sorry, but I keep thinking the new driver is buggy:
what used to work and doesn't...
Regards.
--
Jocelyn Mayer <[email protected]>
> - Please take a look at this session:
> First, I reboot the Ibook:
You didn't read a damn thing.
Look, things changed around rc2. They changed because the old way of
sbp2 that allowed sbp2 devices to be detected on module load caused
oopses. It was very buggy and very bad. Even the old logic didn't work
when you loaded sbp2 and _then_ plugged the device in.
I HAVE NOT once said anything about fucking /sbin/hotplug, nor the
kernel's idea of CONFIG_HOTPLUG. I just said "hotplug", which is a
generic term for being able to insert devices after the bus has already
been scanned for them. So stop bring up either of the two previous
notions that you may have.
Your behavior is expected, even if it changed and is inconvient to you.
This time, _really_ read the linux1394-devel mailing list archives. And
just get the damn script and use it. If you had ever really used sbp2
previously and wanted to plug/unplug devices without unloading/reloading
sbp2.o, you would already realize that the script was a must for 2.4.
Then again, if you had been unloading/loading sbp2 you would have also
hit the oopses I mentioned before.
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
I know jumping in the middle of a conversation is bad, but....
In conversations with the SBP2 folks, they indicated to me that the way
they do hotplugging is very different from the way usb-storage does it.
The end result (I'm told) is that invoking a scan from userspace is often
needed for SBP2 but never for usb-storage.
So, comparing the two is really pointless.
Matt
On Tue, Jun 03, 2003 at 10:20:19PM +0200, Jocelyn Mayer wrote:
> On Tue, 2003-06-03 at 20:54, Ben Collins wrote:
> > > First, I never trust hotplug or other tools like this:
> > > I do all insmod by hand, so I know all drivers have been loaded.
> > > What is hotplug supposed to do (but wasn't in previous driver
> > > version...) ?
> >
> > I didn't say CONFIG_HOTPLUG, I said hotplug. Basically SCSI in 2.4 will
> > not let recognize devices that were not present when the scsi-host was
> > initially registered with the SCSI stack. You have to run
> > rescan-scsi-bus.sh (or manually send the add/remove commands via
> > procfs).
> >
> > Please read the linux-kernel and/or linux1394-devel mailing list
> > archives. I really hate dredging this all up again.
>
> Well, I did understand well hotplug...
> I did read what's said about SBP2 on linux1394.org, BUT:
>
> please read my latest mail, I did some try with the 2.4.21-rc1 ieee1394
> stack, without /sbin/hotplug, and it worked.
> I have neither rescan-scsi-bus.sh, nor scsiadd anywhere on this machine.
> So, I'm sure that no user-space tool have been called by the kernel.
>
> - I NEVER need to do an "echo ... > /proc/scsi/scsi" to see the device
> (I tell again that I never use automatic tools to do this kind of
> low level stuffs).
> - I NEVER have to do this to see an USB mass-storage device:
> I'm *REALLY* sure of this, as I wrote a very simple hotplug
> and automounter for some embedded hardware which uses USB mass
> storage devices. So, I don't see why SBP2 should need this...
>
> - Please take a look at this session:
> First, I reboot the Ibook:
>
> root:~$ reboot
> root:~$
> Broadcast message from root (pts/0) (Tue Jun 3 22:06:13 2003):
>
> The system is going down for reboot NOW!
> Connection to mac closed by remote host.
> Connection to mac closed.
> jma ~ > ssh jocelyn@mac
> jocelyn@mac's password:
> jocelyn:~$ su -
> Password:
> root:~$ ls -l /bin/hotplug
> ls: /bin/hotplug: No such file or directory
> root:/lib/modules/2.4.21-rc6-compat/kernel/drivers/ieee1394$ cat
> /proc/sys/kernel/hotplug
> /sbin/hotplug
> root:~$ cd /lib/modules/2.4.21-rc6-compat/kernel/drivers/ieee1394/
> root:/lib/modules/2.4.21-rc6-compat/kernel/drivers/ieee1394$ insmod
> ./ieee1394.o
>
> root:/lib/modules/2.4.21-rc6-compat/kernel/drivers/ieee1394$ insmod
> ./cmp.o
> root:/lib/modules/2.4.21-rc6-compat/kernel/drivers/ieee1394$ cat
> /proc/scsi/scsi
>
> Attached devices:
> Host: scsi0 Channel: 00 Id: 00 Lun: 00
> Vendor: SONY Model: CD-RW CRX800E Rev: 1.3p
> Type: CD-ROM ANSI SCSI revision: 02
> root:/lib/modules/2.4.21-rc6-compat/kernel/drivers/ieee1394$ insmod
> ./ohci1394.o
>
> root:/lib/modules/2.4.21-rc6-compat/kernel/drivers/ieee1394$ insmod
> ./amdtp.o
> root:/lib/modules/2.4.21-rc6-compat/kernel/drivers/ieee1394$ insmod
> ../scsi/sd_m
> od.o
> root:/lib/modules/2.4.21-rc6-compat/kernel/drivers/ieee1394$ insmod
> ./sbp2.o
> root:/lib/modules/2.4.21-rc6-compat/kernel/drivers/ieee1394$ cat
> /proc/scsi/scsi
>
> Attached devices:
> Host: scsi0 Channel: 00 Id: 00 Lun: 00
> Vendor: SONY Model: CD-RW CRX800E Rev: 1.3p
> Type: CD-ROM ANSI SCSI revision: 02
> Host: scsi1 Channel: 00 Id: 00 Lun: 00
> Vendor: Maxtor 6 Model: Y080L0 Rev: YAR4
> Type: Direct-Access ANSI SCSI revision: 06
>
>
> So I NEVER write anything to /proc/scsi/scsi,
> I got NO /sbin/hotplug, I use only insmod,
> so I can have no side-effect due to modprobe usage,
> and it works PERFECTLY on the Ibook,
> using the 2.4.21-rc1 ieee1394 stack.
>
> So, I'm sorry, but I keep thinking the new driver is buggy:
> what used to work and doesn't...
>
>
> Regards.
>
> --
> Jocelyn Mayer <[email protected]>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Matthew Dharm Home: [email protected]
Maintainer, Linux USB Mass Storage Driver
Would you mind not using our Web server? We're trying to have a game of
Quake here.
-- Greg
User Friendly, 5/11/1998
> Attached devices:
> Host: scsi0 Channel: 00 Id: 00 Lun: 00
> Vendor: SONY Model: CD-RW CRX800E Rev: 1.3p
> Type: CD-ROM ANSI SCSI revision: 02
> Host: scsi1 Channel: 00 Id: 00 Lun: 00
> Vendor: Maxtor 6 Model: Y080L0 Rev: YAR4
> Type: Direct-Access ANSI SCSI revision: 06
>
>
> So I NEVER write anything to /proc/scsi/scsi,
> I got NO /sbin/hotplug, I use only insmod,
> so I can have no side-effect due to modprobe usage,
> and it works PERFECTLY on the Ibook,
> using the 2.4.21-rc1 ieee1394 stack.
>
> So, I'm sorry, but I keep thinking the new driver is buggy:
> what used to work and doesn't...
Want to see buggy? After you load all this up on rc1, rmmod sbp2 and
then do:
cat /proc/scsi/sbp2/1
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
On Tue, 2003-06-03 at 22:25, Matthew Dharm wrote:
> I know jumping in the middle of a conversation is bad, but....
>
> In conversations with the SBP2 folks, they indicated to me that the way
> they do hotplugging is very different from the way usb-storage does it.
> The end result (I'm told) is that invoking a scan from userspace is often
> needed for SBP2 but never for usb-storage.
>
> So, comparing the two is really pointless.
>
> Matt
>
Hi,
you're right, I just wanted to point that there's no reason
that we need to register a device etheir by hand or using
an "infamous script" (citation from Ben Collins
http://sourceforge.net/mailarchive/message.php?msg_id=4435485 )
due to the SCSI stack, but that it's only a SBP2 problem.
Regards.
On Tue, 2003-06-03 at 21:26, Ben Collins wrote:
> > - Please take a look at this session:
> > First, I reboot the Ibook:
>
> You didn't read a damn thing.
>
> Look, things changed around rc2. They changed because the old way of
> sbp2 that allowed sbp2 devices to be detected on module load caused
> oopses. It was very buggy and very bad. Even the old logic didn't work
> when you loaded sbp2 and _then_ plugged the device in.
>
> I HAVE NOT once said anything about fucking /sbin/hotplug, nor the
> kernel's idea of CONFIG_HOTPLUG. I just said "hotplug", which is a
> generic term for being able to insert devices after the bus has already
> been scanned for them. So stop bring up either of the two previous
> notions that you may have.
>
> Your behavior is expected, even if it changed and is inconvient to you.
> This time, _really_ read the linux1394-devel mailing list archives. And
> just get the damn script and use it. If you had ever really used sbp2
> previously and wanted to plug/unplug devices without unloading/reloading
> sbp2.o, you would already realize that the script was a must for 2.4.
> Then again, if you had been unloading/loading sbp2 you would have also
> hit the oopses I mentioned before.
Yes, I didn't read the mailing list,
only the SBP2 page.
I did, now, read the thread "initial bus scan gone" and YOU refer this
as a known bug, not as a normal feature.
I may be lucky, but I never had a Ooops.
You're right on one point: I ALWAYS unload/reload the sbp2 driver.
I do this on a PC about once a day and had an 30 days uptime.
I don't do it on the Mac because it's a laptop and I usually
keep the disk mounted until I stop it.
I know that echo to /proc/scsi/scsi is needed for device REMOVAL,
but, as I said before, I NEVER needed it for device's insertion.
I use sbp2 devices every day for monthes, but never tried to know how it
worked since it was working well for me, so please don't tell me I never
used it...
Sorry to have talked to you, making you so angry,
won't disturb you again.
Time to close this thread, now.
--
Jocelyn Mayer <[email protected]>
On Tue, Jun 03, 2003 at 11:12:34PM +0200, Jocelyn Mayer wrote:
> On Tue, 2003-06-03 at 22:25, Matthew Dharm wrote:
> > I know jumping in the middle of a conversation is bad, but....
> >
> > In conversations with the SBP2 folks, they indicated to me that the way
> > they do hotplugging is very different from the way usb-storage does it.
> > The end result (I'm told) is that invoking a scan from userspace is often
> > needed for SBP2 but never for usb-storage.
> >
> > So, comparing the two is really pointless.
>
> you're right, I just wanted to point that there's no reason
> that we need to register a device etheir by hand or using
> an "infamous script" (citation from Ben Collins
> http://sourceforge.net/mailarchive/message.php?msg_id=4435485 )
> due to the SCSI stack, but that it's only a SBP2 problem.
Actually, it is/was a SCSI problem. The short version being that it is/was
easier to hotplug an entire HBA rather than an individual device. That is
being changed in 2.5 right now. usb-storage used an HBA-per-device, while
SBP2 uses a single HBA.
Of course, all this is being changed right now in 2.5.x
Matt
--
Matthew Dharm Home: [email protected]
Maintainer, Linux USB Mass Storage Driver
It's monday. It must be monday.
-- Greg
User Friendly, 5/4/1998