IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]

IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]

[Tony Spinillo]

Stelian

Similiar problem here. Machine boots fine, but when I plug my DV
camera in I can't cat /proc/bus/ieee1394/ devices, and I get looping
messages in dmesg. If I move the 1394 drivers from pre-7 in, all works
fine.
(Thanks Dan). I submitted my logs and hw info to:
http://sourceforge.net/mailarchive/forum.php?thread_id=2009188&forum_id=5387

Tony

>Something gone wrong with this changes. My Sony Vaio Picturebook C1VE
>hangs on boot when the firewire controller is probed by the init
>scripts.

>This happens exactly in the sequence:
>	modprobe ohci1394
>	grep something /proc/bus/ieee1394/devices
>I'm not sure yet if the lockup is related to the ohci1394
initialisation
>or the read in /proc possibly eariler than the driver expects.
>
>The kernel still reacts to sysrq (umount/sync etc), however
task/memory/pc
>sysrq function do NOT work...
>
>I'll investigate a bit further on this today.

Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]

[Stelian Pop]

On Wed, Apr 23, 2003 at 05:29:40AM -0700, Tony Spinillo wrote:

> Stelian
> 
> Similiar problem here. Machine boots fine, but when I plug my DV
> camera in I can't cat /proc/bus/ieee1394/ devices, and I get looping
> messages in dmesg. If I move the 1394 drivers from pre-7 in, all works
> fine.
> (Thanks Dan). I submitted my logs and hw info to:
> http://sourceforge.net/mailarchive/forum.php?thread_id=2009188&forum_id=5387
> 

The following patch seems to cure my problem, I'm not sure yours
is the same.

I'm not absolutely sure about the corectness of the patch, but I
believe that kernel_thread should not be called with interrupts
disabled.

I'll leave up to the ieee1394 developpers to decide if some other,
semaphore based, locking is still necessary here.

Stelian.

===== drivers/ieee1394/nodemgr.c 1.19 vs edited =====
--- 1.19/drivers/ieee1394/nodemgr.c	Thu Apr 17 19:40:56 2003
+++ edited/drivers/ieee1394/nodemgr.c	Wed Apr 23 14:32:57 2003
@@ -1417,8 +1417,6 @@
 	init_completion(&hi->exited);
         sema_init(&hi->reset_sem, 0);
 
-	spin_lock_irqsave (&host_info_lock, flags);
-
 	hi->pid = kernel_thread(nodemgr_host_thread, hi,
 				CLONE_FS | CLONE_FILES | CLONE_SIGHAND);
 	
@@ -1426,9 +1424,10 @@
 		HPSB_ERR ("NodeMgr: failed to start NodeMgr thread for %s",
 			  host->driver->name);
 		kfree(hi);
-		spin_unlock_irqrestore (&host_info_lock, flags);
 		return;
 	}
+
+	spin_lock_irqsave (&host_info_lock, flags);
 
 	list_add_tail(&hi->list, &host_info_list);
 
-- 
Stelian Pop <stelian.pop@fr.alcove.com>
Alcove - http://www.alcove.com

Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]

[Ben Collins]

On Wed, Apr 23, 2003 at 02:53:15PM +0200, Stelian Pop wrote:
> On Wed, Apr 23, 2003 at 05:29:40AM -0700, Tony Spinillo wrote:
> 
> > Stelian
> > 
> > Similiar problem here. Machine boots fine, but when I plug my DV
> > camera in I can't cat /proc/bus/ieee1394/ devices, and I get looping
> > messages in dmesg. If I move the 1394 drivers from pre-7 in, all works
> > fine.
> > (Thanks Dan). I submitted my logs and hw info to:
> > http://sourceforge.net/mailarchive/forum.php?thread_id=2009188&forum_id=5387
> > 
> 
> The following patch seems to cure my problem, I'm not sure yours
> is the same.
> 
> I'm not absolutely sure about the corectness of the patch, but I
> believe that kernel_thread should not be called with interrupts
> disabled.
> 
> I'll leave up to the ieee1394 developpers to decide if some other,
> semaphore based, locking is still necessary here.

The patch is broken, and the problem is already fixed in our repo. Just
a matter of getting Marcelo to accept my patch before 2.4.21 is
released.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo       - http://www.deqo.com/

Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]

[Stelian Pop]

On Wed, Apr 23, 2003 at 09:01:39AM -0400, Ben Collins wrote:

> > I'll leave up to the ieee1394 developpers to decide if some other,
> > semaphore based, locking is still necessary here.
> 
> The patch is broken, and the problem is already fixed in our repo. Just
> a matter of getting Marcelo to accept my patch before 2.4.21 is
> released.

Can we see it please ?

Stelian.
-- 
Stelian Pop <stelian.pop@fr.alcove.com>
Alcove - http://www.alcove.com

Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]

[Ben Collins]

On Wed, Apr 23, 2003 at 03:22:27PM +0200, Stelian Pop wrote:
> On Wed, Apr 23, 2003 at 09:01:39AM -0400, Ben Collins wrote:
> 
> > > I'll leave up to the ieee1394 developpers to decide if some other,
> > > semaphore based, locking is still necessary here.
> > 
> > The patch is broken, and the problem is already fixed in our repo. Just
> > a matter of getting Marcelo to accept my patch before 2.4.21 is
> > released.
> 
> Can we see it please ?

Stelia,

http://www.linux1394.org/viewcvs/ieee1394/branches/linux-2.4

Click the "Download tarball" link and replace drivers/ieee1394 with what
you get.


Tony, you are seeing a different problem. I'll get you a patch soon (for
the record, I'm not even subscribed to linux1394-user, but to
linux1394-devel).

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo       - http://www.deqo.com/

Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]

[Ben Collins]

> Tony, you are seeing a different problem. I'll get you a patch soon (for
> the record, I'm not even subscribed to linux1394-user, but to
> linux1394-devel).

Give this patch a try. It's only a workaround, but this check needs to
be there anyway for sanity. Seems cameras cause this problem more than
anything else. Has never happeneed to me with my DV camera and DCAM) so
I haven't been able to pin down the problem yet.


Index: nodemgr.c
===================================================================
--- nodemgr.c	(revision 899)
+++ nodemgr.c	(working copy)
@@ -1264,7 +1264,7 @@
 /* We need to ensure that if we are not the IRM, that the IRM node is capable of
  * everything we can do, otherwise issue a bus reset and try to become the IRM
  * ourselves. */
-static int nodemgr_check_irm_capability(struct hpsb_host *host)
+static int nodemgr_check_irm_capability(struct hpsb_host *host, int cycles)
 {
 	quadlet_t bc;
 	int status;
@@ -1281,10 +1281,19 @@
 		/* The current irm node does not have a valid BROADCAST_CHANNEL
 		 * register and we do, so reset the bus with force_root set */
 		HPSB_DEBUG("Current remote IRM is not 1394a-2000 compliant, resetting...");
+
+		if (cycles >= 5) {
+			/* Oh screw it! Just leave the bus as it is */
+			HPSB_DEBUG("Stopping reset loop for IRM sanity");
+			return 1;
+		}
+
 		hpsb_send_phy_config(host, host->node_id, -1);
 		hpsb_reset_bus(host, LONG_RESET_FORCE_ROOT);
+
 		return 0;
 	}
+
 	return 1;
 }
 
@@ -1292,6 +1301,7 @@
 {
 	struct host_info *hi = (struct host_info *)__hi;
 	struct hpsb_host *host = hi->host;
+	int reset_cycles = 0;
 
 	/* No userlevel access needed */
 	daemonize();
@@ -1324,12 +1334,14 @@
 				i = HZ/4;
 		}
 
-		if (!nodemgr_check_irm_capability(host)) {
+		if (!nodemgr_check_irm_capability(host, reset_cycles++)) {
 			/* Do nothing, we are resetting */
 			up(&nodemgr_serialize);
 			continue;
 		}
 
+		reset_cycles = 0;
+
 		nodemgr_node_probe(hi, generation);
 		nodemgr_do_irm_duties(host);
 

Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]

[Ben Collins]

On Wed, Apr 23, 2003 at 03:58:14PM +0200, Stelian Pop wrote:
> On Wed, Apr 23, 2003 at 09:32:56AM -0400, Ben Collins wrote:
> 
> > > Can we see it please ?
> > 
> > Stelia,
> > 
> > http://www.linux1394.org/viewcvs/ieee1394/branches/linux-2.4
> > 
> > Click the "Download tarball" link and replace drivers/ieee1394 with what
> > you get.
> 
> Hey, that's a whole new version of ieee1394 subsystem, see below the
> diffstat.
> 
> There is *NO WAY* Marcelo will accept such a patch in the -rc stage.
> 
> >From a quick reading, your version seem to do exactly the same thing
> that my patch suggested (removing the spinlock around kernel_thread()),
> possibly with the locking being moved to the upper layer.
> 
> Do you have a stripped down patch correcting only the outstanding issues ?
> If you haven't, the choice will be either accepting my patch or 
> reverting your entire ieee1394 changes for the time being.
> 

Your patch leaves a race condition open. And no, I don't have a stripped
down patch. It's impossible for me to syncronize layers of linux1394
development with the timing of 2.4/2.5 development. The size of the
current 2.4 diff is only because of the amount of stuff merged from our
2.5 tree and a serious code cleanup (fixing locking problems like you saw
here).

Fixing your particular locking problem required removal of some shared
data, which required an additional API in the lowlevel subsystem. It's
not trivial to extrapolate just this from the patch.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo       - http://www.deqo.com/

Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]

[Stelian Pop]

On Wed, Apr 23, 2003 at 09:32:56AM -0400, Ben Collins wrote:

> > Can we see it please ?
> 
> Stelia,
> 
> http://www.linux1394.org/viewcvs/ieee1394/branches/linux-2.4
> 
> Click the "Download tarball" link and replace drivers/ieee1394 with what
> you get.

Hey, that's a whole new version of ieee1394 subsystem, see below the
diffstat.

There is *NO WAY* Marcelo will accept such a patch in the -rc stage.

>From a quick reading, your version seem to do exactly the same thing
that my patch suggested (removing the spinlock around kernel_thread()),
possibly with the locking being moved to the upper layer.

Do you have a stripped down patch correcting only the outstanding issues ?
If you haven't, the choice will be either accepting my patch or 
reverting your entire ieee1394 changes for the time being.

Stelian.


 amdtp.c                 |   78 ++--
 cmp.c                   |   70 ---
 csr.c                   |   14 
 dv1394-private.h        |    2 
 dv1394.c                |   12 
 eth1394.c               |  110 +-----
 eth1394.h               |    1 
 highlevel.c             |  247 +++++++++++--
 highlevel.h             |   26 +
 hosts.c                 |   68 +--
 hosts.h                 |   21 -
 ieee1394-ioctl.h        |    4 
 ieee1394.h              |   10 
 ieee1394_core.c         |  232 +++++++++---
 ieee1394_core.h         |   15 
 ieee1394_hotplug.h      |    2 
 ieee1394_transactions.c |  473 ++++++++++---------------
 ieee1394_transactions.h |   57 ---
 ieee1394_types.h        |   26 +
 nodemgr.c               |  344 +++++++++---------
 nodemgr.h               |   23 -
 ohci1394.c              |   37 --
 pcilynx.c               |  119 +++++-
 raw1394-private.h       |    1 
 raw1394.c               |  151 +++-----
 sbp2.c                  |  875 +++++++++++++++++-------------------------------
 sbp2.h                  |  149 ++------
 video1394.c             |  136 ++-----
 video1394.h             |    1 
 29 files changed, 1562 insertions(+), 1742 deletions(-)


-- 
Stelian Pop <stelian.pop@fr.alcove.com>
Alcove - http://www.alcove.com

Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]

[Stelian Pop]

On Wed, Apr 23, 2003 at 09:54:48AM -0400, Ben Collins wrote:

> Your patch leaves a race condition open. And no, I don't have a stripped
> down patch. It's impossible for me to syncronize layers of linux1394
> development with the timing of 2.4/2.5 development. The size of the
> current 2.4 diff is only because of the amount of stuff merged from our
> 2.5 tree and a serious code cleanup (fixing locking problems like you saw
> here).

While this is a reasonable explanation, we are now in rc mode, and 
your changes are not trivial, they could introduce a big pile of
new bugs.

Marcelo, please revert the latest IEEE1394 changeset entirely.

Let's hope that things will happen differently in 2.4.22-pre :(

Stelian.
-- 
Stelian Pop <stelian.pop@fr.alcove.com>
Alcove - http://www.alcove.com

Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]

[Ben Collins]

On Wed, Apr 23, 2003 at 04:21:31PM +0200, Stelian Pop wrote:
> On Wed, Apr 23, 2003 at 09:54:48AM -0400, Ben Collins wrote:
> 
> > Your patch leaves a race condition open. And no, I don't have a stripped
> > down patch. It's impossible for me to syncronize layers of linux1394
> > development with the timing of 2.4/2.5 development. The size of the
> > current 2.4 diff is only because of the amount of stuff merged from our
> > 2.5 tree and a serious code cleanup (fixing locking problems like you saw
> > here).
> 
> While this is a reasonable explanation, we are now in rc mode, and 
> your changes are not trivial, they could introduce a big pile of
> new bugs.
> 
> Marcelo, please revert the latest IEEE1394 changeset entirely.
> 
> Let's hope that things will happen differently in 2.4.22-pre :(

Uh no, reverting it will just re-introduce bugs that it fixed.
2.4.22-pre should have come around a long time ago. The only reason most
of the changes in 2.4.21-pre for ieee1394 are there is because of the
amount of time that 2.4.21-pre has been sitting around. I was trying to
hold off most of these changes for 2.4.22-pre, but .21-pre lingered for
so long it became unreasonable.

Then after a long huge pause, it suddenly goes -rc. Should that leave me
stuck? Don't think so.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo       - http://www.deqo.com/

Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]

[Ben Collins]

> I entirely agree.
> 
> However, the patch we are discussing has only *6 days*. If you had
> submitted it 2 months ago, there wouldn't be such problems.
> 
> [BTW: searching back the l-k archives doesn't find any occurances of
> your patch. I guess you sended it directly to Marcelo...]
> 
> > Then after a long huge pause, it suddenly goes -rc. Should that leave me
> > stuck? Don't think so.
> 
> Sure, you should continue development and submit a fresh new version
> ready to be tested in 2.4.22-pre1/pre2. 
> 
> As for 2.4.21, well, we want something pretty well tested. Will this
> be the case with your new mega-patch ? I don't think so. The safest
> is to go back to a version which worked. At least the bugs of that
> version are known, which is not the case for the new version.

Mega patch? I hardly call it a mega patch. It's mostly cleanups and it
was taken from an existing branch. Stuff that is already in Linus' tree.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo       - http://www.deqo.com/

Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]

[Ben Collins]

> As for 2.4.21, well, we want something pretty well tested. Will this
> be the case with your new mega-patch ? I don't think so. The safest
> is to go back to a version which worked. At least the bugs of that
> version are known, which is not the case for the new version.

BTW, have you even tested the patch? I can almost guarantee is is more
stable than what was in -pre7 (outside of the one small fix I had to
apply for the IRM looping). The -pre7 code has loads of irq disabling
problems and dead lock issues, not to mention the race conditions.

The problem you see with the irq disabling around kernel_thread() may
not be there in -pre7, but that's only because the shared data with the
thread was not protected from a race condition that causes an oops in
some not-so-rare cases.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo       - http://www.deqo.com/

Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]

[Stelian Pop]

On Wed, Apr 23, 2003 at 10:23:53AM -0400, Ben Collins wrote:

> > While this is a reasonable explanation, we are now in rc mode, and 
> > your changes are not trivial, they could introduce a big pile of
> > new bugs.
> > 
> > Marcelo, please revert the latest IEEE1394 changeset entirely.
> > 
> > Let's hope that things will happen differently in 2.4.22-pre :(
> 
> Uh no, reverting it will just re-introduce bugs that it fixed.

Maybe, but the version prior to 2.4.21-pre7 worked pretty good 
for me.

> 2.4.22-pre should have come around a long time ago. The only reason most
> of the changes in 2.4.21-pre for ieee1394 are there is because of the
> amount of time that 2.4.21-pre has been sitting around. I was trying to
> hold off most of these changes for 2.4.22-pre, but .21-pre lingered for
> so long it became unreasonable.

I entirely agree.

However, the patch we are discussing has only *6 days*. If you had
submitted it 2 months ago, there wouldn't be such problems.

[BTW: searching back the l-k archives doesn't find any occurances of
your patch. I guess you sended it directly to Marcelo...]

> Then after a long huge pause, it suddenly goes -rc. Should that leave me
> stuck? Don't think so.

Sure, you should continue development and submit a fresh new version
ready to be tested in 2.4.22-pre1/pre2. 

As for 2.4.21, well, we want something pretty well tested. Will this
be the case with your new mega-patch ? I don't think so. The safest
is to go back to a version which worked. At least the bugs of that
version are known, which is not the case for the new version.

Stelian.
-- 
Stelian Pop <stelian.pop@fr.alcove.com>
Alcove - http://www.alcove.com

Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]

[Stelian Pop]

On Wed, Apr 23, 2003 at 10:48:58AM -0400, Ben Collins wrote:

> > As for 2.4.21, well, we want something pretty well tested. Will this
> > be the case with your new mega-patch ? I don't think so. The safest
> > is to go back to a version which worked. At least the bugs of that
> > version are known, which is not the case for the new version.
> 
> BTW, have you even tested the patch? I can almost guarantee is is more
> stable than what was in -pre7 (outside of the one small fix I had to
> apply for the IRM looping). The -pre7 code has loads of irq disabling
> problems and dead lock issues, not to mention the race conditions.
> 
> The problem you see with the irq disabling around kernel_thread() may
> not be there in -pre7, but that's only because the shared data with the
> thread was not protected from a race condition that causes an oops in
> some not-so-rare cases.

I confirm that your patch at least solves the initialisation issues.
I'll test later with some ieee devices and I'll report back if I found
other issues.

Stelian.
-- 
Stelian Pop <stelian.pop@fr.alcove.com>
Alcove - http://www.alcove.com

Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]

[Ben Collins]

> > > The problem you see with the irq disabling around kernel_thread() may
> > > not be there in -pre7, but that's only because the shared data with the
> > > thread was not protected from a race condition that causes an oops in
> > > some not-so-rare cases.
> >
> > I confirm that your patch at least solves the initialisation issues.
> > I'll test later with some ieee devices and I'll report back if I found
> > other issues.
> 
> Any news on that, Stelian ?
> 
> I guess Ben's mega patch (and yes, I also consider it a megapatch for
> -rc) has to be applied. I just mailed him asking about the possibility
> of getting only fixes in and not the cleanups, but I guess that might be a
> bit hard to do _today_. Right Ben ?

Yeah, it's pretty hard. I didn't do all these changes with the intent of
it being a 2.4.21 thing, but it definitely dragged on to the point where
I had no choice, and pulling the fixes out of the major work became too
much work.

> And about the sweet complaints about -pre timing, I will release -pre's
> each damn week for .22.

If you could just commit patches to the bk repo as you get them, instead
of holding them for a month and dumping them all in at once, it would be
easier to follow things. Instead, we got several huge lumps late in
2.4.21-pre's.

Wasn't my intent to bash you, but I will admit that 2.4.21 has been a
pain in my ass because of the cycle :)

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo       - http://www.deqo.com/

Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]

[Marcelo Tosatti]

On Wed, 23 Apr 2003, Stelian Pop wrote:

> On Wed, Apr 23, 2003 at 10:48:58AM -0400, Ben Collins wrote:
>
> > > As for 2.4.21, well, we want something pretty well tested. Will this
> > > be the case with your new mega-patch ? I don't think so. The safest
> > > is to go back to a version which worked. At least the bugs of that
> > > version are known, which is not the case for the new version.
> >
> > BTW, have you even tested the patch? I can almost guarantee is is more
> > stable than what was in -pre7 (outside of the one small fix I had to
> > apply for the IRM looping). The -pre7 code has loads of irq disabling
> > problems and dead lock issues, not to mention the race conditions.
> >
> > The problem you see with the irq disabling around kernel_thread() may
> > not be there in -pre7, but that's only because the shared data with the
> > thread was not protected from a race condition that causes an oops in
> > some not-so-rare cases.
>
> I confirm that your patch at least solves the initialisation issues.
> I'll test later with some ieee devices and I'll report back if I found
> other issues.

Any news on that, Stelian ?

I guess Ben's mega patch (and yes, I also consider it a megapatch for
-rc) has to be applied. I just mailed him asking about the possibility
of getting only fixes in and not the cleanups, but I guess that might be a
bit hard to do _today_. Right Ben ?

And about the sweet complaints about -pre timing, I will release -pre's
each damn week for .22.

*!@#!&*.

Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]

[Marcelo Tosatti]

a

On Wed, 23 Apr 2003, Ben Collins wrote:

> > > > The problem you see with the irq disabling around kernel_thread() may
> > > > not be there in -pre7, but that's only because the shared data with the
> > > > thread was not protected from a race condition that causes an oops in
> > > > some not-so-rare cases.
> > >
> > > I confirm that your patch at least solves the initialisation issues.
> > > I'll test later with some ieee devices and I'll report back if I found
> > > other issues.
> >
> > Any news on that, Stelian ?
> >
> > I guess Ben's mega patch (and yes, I also consider it a megapatch for
> > -rc) has to be applied. I just mailed him asking about the possibility
> > of getting only fixes in and not the cleanups, but I guess that might be a
> > bit hard to do _today_. Right Ben ?
>
> Yeah, it's pretty hard. I didn't do all these changes with the intent of
> it being a 2.4.21 thing, but it definitely dragged on to the point where
> I had no choice, and pulling the fixes out of the major work became too
> much work.
>
> > And about the sweet complaints about -pre timing, I will release -pre's
> > each damn week for .22.
>
> If you could just commit patches to the bk repo as you get them, instead
> of holding them for a month and dumping them all in at once, it would be
> easier to follow things. Instead, we got several huge lumps late in
> 2.4.21-pre's.
>
> Wasn't my intent to bash you, but I will admit that 2.4.21 has been a
> pain in my ass because of the cycle :)

I also agree that 2.4.21 was a _too_ long cycle. Very bad thing indeed.

Well, the megapatch is in bk already (together with some other stuff).

-rc2 should be out today.

Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]

[Stelian Pop]

On Wed, Apr 23, 2003 at 04:13:42PM -0300, Marcelo Tosatti wrote:

> > I confirm that your patch at least solves the initialisation issues.
> > I'll test later with some ieee devices and I'll report back if I found
> > other issues.
> 
> Any news on that, Stelian ?


Well, mixed success. I've done just some simple tests with an Apple
iPod (seen as a firewire drive). When plugged in, it is automatically
recognized and hotplug loads sbp2, which sees the drive and the two
partitions.

Mounted it, did a dd if=/dev/zero of=/mnt/ipod bs=1M count=1024.

It stalled without transferring anything. Strange.

Interrupted the dd, relaunched, all worked correctly this time. I've
tried several times but unable to reproduce the stall. Copied several
files from/to the iPod without problems.

Umounted, rmmod sbp2, unplugged the iPod. Replugged the ipod, try
to remount.

Three different behaviours follow, all reproductible (!):
* correct behaviour, the mount succeeds
* mount hangs. wchan is 'end' (?)
* mount oopses, see the report below.

Is this better or not than the -pre7 version ? Honestly I don't know,
there were problems with the old one too (however the old version
reacted to plug/unplug mount/umount events by freezing hard the
laptop, while the new one just oopses, so this is an improvement
from some point of view...)

Stelian.

ksymoops 2.4.5 on i686 2.4.21-rc1.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.21-rc1/ (default)
     -m /boot/System.map-2.4.21-rc1 (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

CPU: 20000805 23:30 official release 4.1.4#2
WARNING: USB Mass Storage data integrity not assured
ds: no socket drivers loaded!
cs: IO port probe 0x0c00-0x0cff: clean.
cs: IO port probe 0x0100-0x04ff: excluding 0x170-0x177 0x370-0x377 0x4d0-0x4d7
cs: IO port probe 0x0a00-0x0aff: clean.
cs: memory probe 0xa0000000-0xa0ffffff: clean.
Unable to handle kernel NULL pointer dereference at virtual address 00000004
c78b99f4
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[<c78b99f4>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010212
eax: 00000000   ebx: c115ba60   ecx: c78b9940   edx: c6d9dc00
esi: 00000001   edi: c4f7e3c0   ebp: 00000010   esp: c4f0befc
ds: 0018   es: 0018   ss: 0018
Process mount (pid: 931, stackpage=c4f0b000)
Stack: c115ba60 c02f0e50 c014f47f fffffffa c502a2c0 c6f7e2a0 c6f7e2bc 00000812 
       c0140d83 c4f7e3c0 c502a2c0 00000000 c502a2c0 c4f7e3c0 ffffffe9 c113e2e0 
       c0140e78 c6f7e2a0 c4f7e3c0 c502a2c0 c502a2c0 c4f7e3c0 c0139463 c4f7e3c0 
Call Trace:    [<c014f47f>] [<c0140d83>] [<c0140e78>] [<c0139463>] [<c0139388>]
  [<c0139723>] [<c01090ff>]
Code: 8b 40 04 85 c0 74 10 ff 40 10 8b 43 10 8b 40 24 8b 40 04 83 


>>EIP; c78b99f4 <[sd_mod]sd_open+b4/230>   <=====

>>ebx; c115ba60 <_end+e48b88/74f7188>
>>ecx; c78b9940 <[sd_mod]sd_open+0/230>
>>edx; c6d9dc00 <_end+6a8ad28/74f7188>
>>edi; c4f7e3c0 <_end+4c6b4e8/74f7188>
>>esp; c4f0befc <_end+4bf9024/74f7188>

Trace; c014f47f <new_inode+f/50>
Trace; c0140d83 <do_open+123/150>
Trace; c0140e78 <blkdev_open+38/50>
Trace; c0139463 <dentry_open+d3/1d0>
Trace; c0139388 <filp_open+68/70>
Trace; c0139723 <sys_open+53/a0>
Trace; c01090ff <system_call+33/38>

Code;  c78b99f4 <[sd_mod]sd_open+b4/230>
00000000 <_EIP>:
Code;  c78b99f4 <[sd_mod]sd_open+b4/230>   <=====
   0:   8b 40 04                  mov    0x4(%eax),%eax   <=====
Code;  c78b99f7 <[sd_mod]sd_open+b7/230>
   3:   85 c0                     test   %eax,%eax
Code;  c78b99f9 <[sd_mod]sd_open+b9/230>
   5:   74 10                     je     17 <_EIP+0x17>
Code;  c78b99fb <[sd_mod]sd_open+bb/230>
   7:   ff 40 10                  incl   0x10(%eax)
Code;  c78b99fe <[sd_mod]sd_open+be/230>
   a:   8b 43 10                  mov    0x10(%ebx),%eax
Code;  c78b9a01 <[sd_mod]sd_open+c1/230>
   d:   8b 40 24                  mov    0x24(%eax),%eax
Code;  c78b9a04 <[sd_mod]sd_open+c4/230>
  10:   8b 40 04                  mov    0x4(%eax),%eax
Code;  c78b9a07 <[sd_mod]sd_open+c7/230>
  13:   83 00 00                  addl   $0x0,(%eax)


1 warning issued.  Results may not be reliable.

-- 
Stelian Pop <stelian.pop@fr.alcove.com>
Alcove - http://www.alcove.com

Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]

[Ben Collins]

> Is this better or not than the -pre7 version ? Honestly I don't know,
> there were problems with the old one too (however the old version
> reacted to plug/unplug mount/umount events by freezing hard the
> laptop, while the new one just oopses, so this is an improvement
> from some point of view...)

This is the same oops I get except that for me I see it as a left over
scsi device even after sbp2 is unloaded (unload sbp2 and check
/proc/partitions). I haven't been able to figure out how to get the scsi
subsystem to remove devices in this condition:

	scsi_register_module(MODULE_SCSI_HA, &sbp2_template);


	scsi_host = scsi_register(&sbp2_template, 0);

	// (some devices get detected)


	// removal of host
	scsi_unregister(scsi_host);


	// Removal of sbp2 module to unregister template
	scsi_unregister_module(MODULE_SCSI_HA, &sbp2_template);



In actuality, doing scsi_unregister(scsi_host), in my eyes should also
deallocate the devices associated with that scsi_host. That doesn't
happen. It seems to me that the logic is that I should not call
scsi_unregister(scsi_host), since it gets called for the
scsi_unregister_module() of the template. However, that allows a
scsi_host leak for situations where ieee1394 controllers are getting
plugged/unplugged. It will continue to leak until sbp2 is unloaded.

I'm not sure if the leak is more optimal than the oops...maybe it is.
I'll revisit this in the next week.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo       - http://www.deqo.com/

Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]

[Stelian Pop]

On Wed, Apr 23, 2003 at 04:24:53PM -0400, Ben Collins wrote:

> This is the same oops I get except that for me I see it as a left over
> scsi device even after sbp2 is unloaded (unload sbp2 and check
> /proc/partitions). 

Confirmed. sbp2 isn't loaded anymore but I still have sdb1/sdb2
in /proc/partitions, and even sdc1/sdc2 which must have been
created when I plugged the iPod the second time.

> I haven't been able to figure out how to get the scsi
> subsystem to remove devices in this condition:

Well, hopefully someone here will direct you towards the 
correct solution before 2.4.21 gets final... Firewire devices
tend to be plugged / unplugged quite often.

Stelian.
-- 
Stelian Pop <stelian.pop@fr.alcove.com>
Alcove - http://www.alcove.com

Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]

[Ben Collins]

On Thu, Apr 24, 2003 at 05:44:39PM -0400, Bill Davidsen wrote:
> On Wed, 23 Apr 2003, Marcelo Tosatti wrote:
> 
> > I guess Ben's mega patch (and yes, I also consider it a megapatch for
> > -rc) has to be applied. I just mailed him asking about the possibility
> > of getting only fixes in and not the cleanups, but I guess that might be a
> > bit hard to do _today_. Right Ben ?
> > 
> > And about the sweet complaints about -pre timing, I will release -pre's
> > each damn week for .22.
> > 
> > *!@#!&*.
> 
> If I might offer a course of action, if you put thing which are *fixes* in
> the bk releases, and hold *changes* for the next -pre, it might allow
> people to grab bk's to fix the quickly caught things in a new pre, without
> being hit with major changes which might decrease stability.
> 
> Clearly any pre is a risk, but there always seem to be errors of the "XXX
> doesn't compile because of typo" type. That way Alan could put all new IDE
> code in each -pre and Andre and others could put fixes in the bk's until
> it worked. => JOKING!! <== but you get the idea.
> 
> I'd love to see this in 2.5 as well, just to encourage people to use it!

You do realize that the -pre's are pulled from bk, right?

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo       - http://www.deqo.com/

Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]

[Bill Davidsen]

On Wed, 23 Apr 2003, Marcelo Tosatti wrote:

> I guess Ben's mega patch (and yes, I also consider it a megapatch for
> -rc) has to be applied. I just mailed him asking about the possibility
> of getting only fixes in and not the cleanups, but I guess that might be a
> bit hard to do _today_. Right Ben ?
> 
> And about the sweet complaints about -pre timing, I will release -pre's
> each damn week for .22.
> 
> *!@#!&*.

If I might offer a course of action, if you put thing which are *fixes* in
the bk releases, and hold *changes* for the next -pre, it might allow
people to grab bk's to fix the quickly caught things in a new pre, without
being hit with major changes which might decrease stability.

Clearly any pre is a risk, but there always seem to be errors of the "XXX
doesn't compile because of typo" type. That way Alan could put all new IDE
code in each -pre and Andre and others could put fixes in the bk's until
it worked. => JOKING!! <== but you get the idea.

I'd love to see this in 2.5 as well, just to encourage people to use it!
I'm not even going to suggest that, there would be the usual flamewar.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]

[Bill Davidsen]

On Thu, 24 Apr 2003, Ben Collins wrote:

> On Thu, Apr 24, 2003 at 05:44:39PM -0400, Bill Davidsen wrote:
> > On Wed, 23 Apr 2003, Marcelo Tosatti wrote:
> > 
> > > I guess Ben's mega patch (and yes, I also consider it a megapatch for
> > > -rc) has to be applied. I just mailed him asking about the possibility
> > > of getting only fixes in and not the cleanups, but I guess that might be a
> > > bit hard to do _today_. Right Ben ?
> > > 
> > > And about the sweet complaints about -pre timing, I will release -pre's
> > > each damn week for .22.
> > > 
> > > *!@#!&*.
> > 
> > If I might offer a course of action, if you put thing which are *fixes* in
> > the bk releases, and hold *changes* for the next -pre, it might allow
> > people to grab bk's to fix the quickly caught things in a new pre, without
> > being hit with major changes which might decrease stability.
> > 
> > Clearly any pre is a risk, but there always seem to be errors of the "XXX
> > doesn't compile because of typo" type. That way Alan could put all new IDE
> > code in each -pre and Andre and others could put fixes in the bk's until
> > it worked. => JOKING!! <== but you get the idea.
> > 
> > I'd love to see this in 2.5 as well, just to encourage people to use it!
> 
> You do realize that the -pre's are pulled from bk, right?

Yes, and I miss why that matters. Let me see if I can make the idea clear
to you:
  2.4.22-pre5		some code
  2.4.22-pre5-bk1	fixes
  2.4.22-pre5-bk2	more fixes
  2.4.22-pre5-bk3	still more fixes
  2.4.22-pre6		fixes to date plus major changes

So when a maintainer got something major it wouldn't go into bk (the
commercial software database) until a new -pre, while the -bk patches
available for download would get the fixes only.

Just a matter of staging, so that after a new -pre the -bk patch files
against it would hopefully get more stable for a few days. A new -pre need
not have something major, it would be nice if they came out every few
weeks at most. Any -pre release is an adventure, but usually there are a
few days of minor fixes posted, and it would be nice if those got
somewhere before the next major change.

Did I make it clear this time? You don't have to agree it's a good idea,
but I'd like you to understand what I have in mind.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]

[Ben Collins]

> Yes, and I miss why that matters. Let me see if I can make the idea clear
> to you:
>   2.4.22-pre5		some code
>   2.4.22-pre5-bk1	fixes
>   2.4.22-pre5-bk2	more fixes
>   2.4.22-pre5-bk3	still more fixes
>   2.4.22-pre6		fixes to date plus major changes
> 
> So when a maintainer got something major it wouldn't go into bk (the
> commercial software database) until a new -pre, while the -bk patches
> available for download would get the fixes only.

What if a fix depends on a major-change-patch? What if a fix is itself a
major change?

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo       - http://www.deqo.com/

The IEEE-1394 saga continued... [ was: IEEE-1394 problem on init ]

[Stelian Pop]

On Wed, Apr 23, 2003 at 10:42:58PM +0200, Stelian Pop wrote:

> > I haven't been able to figure out how to get the scsi
> > subsystem to remove devices in this condition:
> 
> Well, hopefully someone here will direct you towards the 
> correct solution before 2.4.21 gets final... Firewire devices
> tend to be plugged / unplugged quite often.

This was three days ago. Today, without *any* notice (like posting
a patch on lkml for example, as I already suggested it), I saw a
new IEEE1394 patch was checked in into Marcelo's tree.

As usual, the patch was quite big, in Ben's own words "virtualy
bloated [...] by format changes". Why he continues to submit patches
like that one in -rc stage is beyond my understanding.

And guess what ? The new patch broke (again) my setup. When I plug
in my iPod, the scsi layer does not see it anymore.

Since I reported issues about this 3 days ago, I would have appreciated
being CC:'ed on the patch mail, so I could have reported issues 
like this _before_ such a patch being applied. 

Is this so hard to get it right Ben ? From a Debian developer like you
I would have expected you to be a bit more organized and respectful
about the kernel community. And no, the long 2.4.21 release cycle
does not justify everything.

You're now one of those who slow down the final release. All this 
makes me think that the initial feeling I had, to completly backout
the ieee1394 changes until 2.4.22-pre, was correct...

Stelian.

PS: In case they are useful, various logs are included below:

dmesg (with #define CONFIG_IEEE1394_SBP2_DEBUG 2 activated):
	ieee1394: sbp2: sbp2_module_init
	ieee1394: sbp2: sbp2_add_host
	ieee1394: sbp2: sbp2scsi_detect
	scsi1 : SCSI emulation for IEEE-1394 SBP-2 Devices
	ieee1394: sbp2: sbp2scsi_queuecommand
	ieee1394: sbp2: sbp2scsi_queuecommand
	ieee1394: sbp2: sbp2scsi_queuecommand
	ieee1394: sbp2: sbp2scsi_queuecommand
	ieee1394: sbp2: sbp2scsi_queuecommand
	ieee1394: sbp2: sbp2scsi_queuecommand
	ieee1394: sbp2: sbp2scsi_queuecommand
	ieee1394: sbp2: sbp2scsi_queuecommand
	ieee1394: sbp2: sbp2_probe
	ieee1394: sbp2: sbp2_start_device
	ieee1394: sbp2: sbp2_parse_unit_directory
	ieee1394: sbp2: sbp2_unit_characteristics = 1e08
	ieee1394: sbp2: sbp2_command_set_spec_id = 609e
	ieee1394: sbp2: sbp2_command_set = 104d8
	ieee1394: sbp2: sbp2_firmware_revision = a2700
	ieee1394: sbp2: sbp2_management_agent_addr = f0010000
	ieee1394: sbp2: sbp2_device_type_and_lun = e0000
	ieee1394: sbp2: New SBP-2 device inserted, SCSI ID = 0
	ieee1394: sbp2: sbp2_login_device
	ieee1394: sbp2: sbp2_login_device: password_hi/lo initialized
	ieee1394: sbp2: sbp2_login_device: login_response_hi/lo initialized
	ieee1394: sbp2: sbp2_login_device: lun_misc initialized
	ieee1394: sbp2: sbp2_login_device: passwd_resp_lengths initialized
	ieee1394: sbp2: sbp2_login_device: status FIFO initialized
	ieee1394: sbp2: sbp2_login_device: orb byte-swapped
	ieee1394: sbp2: sbp2_login_device: login_response/status FIFO memset
	ieee1394: sbp2: sbp2_login_device: prepared to write
	ieee1394: sbp2: sbp2_login_device: written
	ieee1394: sbp2: sbp2_handle_status_write
	ieee1394: sbp2: command_block_agent_hi = ffc1ffff
	ieee1394: sbp2: command_block_agent_lo = f0010020
	ieee1394: sbp2: Logged into SBP-2 device
	ieee1394: sbp2: sbp2_set_busy_timeout
	ieee1394: sbp2: sbp2_agent_reset
	ieee1394: sbp2: sbp2_max_speed_and_size
	ieee1394: sbp2: Node[01:1023]: Max speed [S400] - Max payload [2048]
/proc/scsi/scsi
	Attached devices: 
	Host: scsi0 Channel: 00 Id: 00 Lun: 00
	  Vendor: Sony     Model: MSC-U01N         Rev: 1.00
	  Type:   Direct-Access                    ANSI SCSI revision: 02

/proc/scsi/sbp2_0/1
	Host scsi1             : SBP-2 IEEE-1394 (ohci1394)
	Driver version         : $Rev: 906 $ James Goodwin <jamesg@filanet.com>
	
	Module options         :
	  max_speed            : S800
	  max_sectors          : 255
	  serialize_io         : no
	  exclusive_login      : yes
	
	Attached devices       : none
	
-- 
Stelian Pop <stelian.pop@fr.alcove.com>
Alcove - http://www.alcove.com

Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]

[Bill Davidsen]

On Fri, 25 Apr 2003, Ben Collins wrote:

> > Yes, and I miss why that matters. Let me see if I can make the idea clear
> > to you:
> >   2.4.22-pre5		some code
> >   2.4.22-pre5-bk1	fixes
> >   2.4.22-pre5-bk2	more fixes
> >   2.4.22-pre5-bk3	still more fixes
> >   2.4.22-pre6		fixes to date plus major changes
> > 
> > So when a maintainer got something major it wouldn't go into bk (the
> > commercial software database) until a new -pre, while the -bk patches
> > available for download would get the fixes only.
> 
> What if a fix depends on a major-change-patch? What if a fix is itself a
> major change?

Time for a -pre. That's a change management decision. Hopefully -pre would
be somewhat closer spaced than has happened with 2.4.21.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: The IEEE-1394 saga continued... [ was: IEEE-1394 problem on init ]

[Ben Collins]

On Sat, Apr 26, 2003 at 10:29:57AM +0200, Stelian Pop wrote:
> On Wed, Apr 23, 2003 at 10:42:58PM +0200, Stelian Pop wrote:
> 
> > > I haven't been able to figure out how to get the scsi
> > > subsystem to remove devices in this condition:
> > 
> > Well, hopefully someone here will direct you towards the 
> > correct solution before 2.4.21 gets final... Firewire devices
> > tend to be plugged / unplugged quite often.
> 
> This was three days ago. Today, without *any* notice (like posting
> a patch on lkml for example, as I already suggested it), I saw a
> new IEEE1394 patch was checked in into Marcelo's tree.
> 
> As usual, the patch was quite big, in Ben's own words "virtualy
> bloated [...] by format changes". Why he continues to submit patches
> like that one in -rc stage is beyond my understanding.
> 
> And guess what ? The new patch broke (again) my setup. When I plug
> in my iPod, the scsi layer does not see it anymore.

Good lord would you calm down.

Run the rescan-scan-scsi.sh script floating around. Out own website
describes having to use this for 2.4 kernels. It was either leave sbp2
oopsing, or rewrite the load logic so that there was no way for left
over scsi cruft. The side affect is that the only hot-plug situation
ieee1394 had in 2.4 is gone.

Before, loading sbp2 before loading ohci1394 gave the same affect. Now,
loading sbp2 before ohci1394 also requires running rescan-scan-scsi.sh.
Blame the scsi layer, not me.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo       - http://www.deqo.com/

Re: The IEEE-1394 saga continued... [ was: IEEE-1394 problem on init ]

[Ben Collins]

> Since I reported issues about this 3 days ago, I would have appreciated
> being CC:'ed on the patch mail, so I could have reported issues 
> like this _before_ such a patch being applied. 

BTW, there are atleast 2 dozen people looking for this patch. I tested
it and several others on the linux1394 mailing list tested it. If you
want to be more closely involved with linux1394 specifically, then don't
expect me to search you out...come to us where our development happens.
We have a commit list to the repo and a developers list.

Things happen there...the only reason I bother the general linux-kernel
list is for things that affect outside the scope of drivers/ieee1394/*.
I don't think that's much different than a lot of projects in the
kernel.

I've never sent my patches to the list prior to inclusion in the kernel,
and a lot of folks don't, depending on neccessity. I don't see the need
to start now, not when interested parties have a place to go to see the
patches before hand anyway. Nothing major I send to Marcelo or Linus is
done so without it being committed in out repo first.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo       - http://www.deqo.com/

Re: The IEEE-1394 saga continued... [ was: IEEE-1394 problem on init ]

[Stelian Pop]

On Sat, Apr 26, 2003 at 10:34:45AM -0400, Ben Collins wrote:

> > And guess what ? The new patch broke (again) my setup. When I plug
> > in my iPod, the scsi layer does not see it anymore.
> 
> Good lord would you calm down.

No. You did broke the subsystem in several occasions, you do this
at the bad moment, and now you introduced a change in behaviour
in a stable kernel release, between -rc1 and -rc2, without any
warning. I think I have enough reasons to be angry.

> Run the rescan-scan-scsi.sh script floating around. Out own website
> describes having to use this for 2.4 kernels.
[...]

The FAQ on linux1394 site was indeed updated 2 days ago. I'm sorry
I didn't think to look there.

Before posting, I did try to check the linux1394 mailing lists for 
information. linux1394-announce has no new mails since march, 
linux1394-devel didn't seem to contain anything obvious about this
(besides a thread "Re: Problem with Kernel 2.4.21-rc1 - latest svn"
which I couldn't read due to sourceforge problems - it kept saying
"no such forum"...)

I did look at the subversion checkin' log. I did look at the bitkeeper
checkin' log. Nothing there.

> It was either leave sbp2
> oopsing, or rewrite the load logic so that there was no way for left
> over scsi cruft. The side affect is that the only hot-plug situation
> ieee1394 had in 2.4 is gone.

Strange, usb-storage seems to work quite fine with respect to the
scsi layer and hotplug...

> Before, loading sbp2 before loading ohci1394 gave the same affect. Now,
> loading sbp2 before ohci1394 also requires running rescan-scan-scsi.sh.
> Blame the scsi layer, not me.

BTW: hotplug removing is still half broken: the hotplug remove event
is send only when the device is physically disconnected. If I remove
the sbp2 module with rmmod, I'll get nothing.

This means that if you do
	rmmod sbp2
	modprobe sbp2
your SCSI device will be lost and you'll have to call 'rescan-scsi-bus'
by hand...

> 
> -- 
> Debian     - http://www.debian.org/
> Linux 1394 - http://www.linux1394.org/
> Subversion - http://subversion.tigris.org/
> Deqo       - http://www.deqo.com/

-- 
Stelian Pop <stelian.pop@fr.alcove.com>
Alcove - http://www.alcove.com

Re: The IEEE-1394 saga continued... [ was: IEEE-1394 problem on init ]

[Ben Collins]

On Sat, Apr 26, 2003 at 06:10:09PM +0200, Stelian Pop wrote:
> On Sat, Apr 26, 2003 at 10:34:45AM -0400, Ben Collins wrote:
> 
> > > And guess what ? The new patch broke (again) my setup. When I plug
> > > in my iPod, the scsi layer does not see it anymore.
> > 
> > Good lord would you calm down.
> 
> No. You did broke the subsystem in several occasions, you do this
> at the bad moment, and now you introduced a change in behaviour
> in a stable kernel release, between -rc1 and -rc2, without any
> warning. I think I have enough reasons to be angry.

IEEE-1394 is marked "EXPERIMENTAL" for a reason. It's not stable. Just
because it exists in a stable kernel doesn't mean the tree adheres to
the same principals. Fixing a crash at the cost of making you run a
simple script for an interim is a likely thing in an EXPERIMENTAL
subsystem. If you would rather hotplug work, at the cost of your system
crashing after two or three reconnects...then maybe you need to be
running some more unstable code.

> > Run the rescan-scan-scsi.sh script floating around. Out own website
> > describes having to use this for 2.4 kernels.
> [...]
> 
> The FAQ on linux1394 site was indeed updated 2 days ago. I'm sorry
> I didn't think to look there.

The rescan-scsi-bus.sh info has been there since sbp2 was introduced
over a year ago.

> > It was either leave sbp2
> > oopsing, or rewrite the load logic so that there was no way for left
> > over scsi cruft. The side affect is that the only hot-plug situation
> > ieee1394 had in 2.4 is gone.
> 
> Strange, usb-storage seems to work quite fine with respect to the
> scsi layer and hotplug...

USB also allocates a template/host for each device. Sorry, but I'm not
about to go that far. Not to mention the callback system in USB is
different than IEEE1394. So the same logic doesn't transfer.

> > Before, loading sbp2 before loading ohci1394 gave the same affect. Now,
> > loading sbp2 before ohci1394 also requires running rescan-scan-scsi.sh.
> > Blame the scsi layer, not me.
> 
> BTW: hotplug removing is still half broken: the hotplug remove event
> is send only when the device is physically disconnected. If I remove
> the sbp2 module with rmmod, I'll get nothing.
> 
> This means that if you do
> 	rmmod sbp2
> 	modprobe sbp2
> your SCSI device will be lost and you'll have to call 'rescan-scsi-bus'
> by hand...

That's what /sbin/hotplug et al are for. If you want dork-free hotplug
in scsi/ieee1394, use 2.5.x.

Look, I'm not going to get pulled into this argument anymore. If you
want to control how ieee1394 is developed, join the list and put up, or
just shut up.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo       - http://www.deqo.com/

Re: The IEEE-1394 saga continued... [ was: IEEE-1394 problem on init ]

[Stelian Pop]

On Sat, Apr 26, 2003 at 10:40:18AM -0400, Ben Collins wrote:

> > Since I reported issues about this 3 days ago, I would have appreciated
> > being CC:'ed on the patch mail, so I could have reported issues 
> > like this _before_ such a patch being applied. 
> 
> BTW, there are atleast 2 dozen people looking for this patch. I tested
> it and several others on the linux1394 mailing list tested it. If you
> want to be more closely involved with linux1394 specifically, then don't
> expect me to search you out...

So if I report a bug I must be subscribed to your list to get the answer,
that's it ? 

You don't have to 'come search me out'. *I* sent you a bug report, the least
you could do is to CC: me on the answers. (Or gently tell me that this is
a known bug being discussed on your list and inviting me to go there to
find the answers).

> come to us where our development happens.
> We have a commit list to the repo and a developers list.

As I said in the previous mail, I did check the archives and saw nothing
trivially relevant. But of course, I could have missed something.

> I've never sent my patches to the list prior to inclusion in the kernel,
> and a lot of folks don't, depending on neccessity. I don't see the need
> to start now, not when interested parties have a place to go to see the
> patches before hand anyway.

Keeping the development discussions on your own list is of course ok,
but I believe posting an announce on lkml each time you send something
for inclusion in the main kernel would be a good idea. Especially when
you're not sending patches every day and when your patches tend to be
considerably big.

This is what (a lot of) other subsystem maintainers do.

Stelian.
-- 
Stelian Pop <stelian.pop@fr.alcove.com>
Alcove - http://www.alcove.com

Re: The IEEE-1394 saga continued... [ was: IEEE-1394 problem on init ]

[Ben Collins]

On Sat, Apr 26, 2003 at 06:23:23PM +0200, Stelian Pop wrote:
> On Sat, Apr 26, 2003 at 10:40:18AM -0400, Ben Collins wrote:
> 
> > > Since I reported issues about this 3 days ago, I would have appreciated
> > > being CC:'ed on the patch mail, so I could have reported issues 
> > > like this _before_ such a patch being applied. 
> > 
> > BTW, there are atleast 2 dozen people looking for this patch. I tested
> > it and several others on the linux1394 mailing list tested it. If you
> > want to be more closely involved with linux1394 specifically, then don't
> > expect me to search you out...
> 
> So if I report a bug I must be subscribed to your list to get the answer,
> that's it ? 
> 
> You don't have to 'come search me out'. *I* sent you a bug report, the least
> you could do is to CC: me on the answers. (Or gently tell me that this is
> a known bug being discussed on your list and inviting me to go there to
> find the answers).

I already told you I could reproduce the bug and that it was known. The
fact that i fixed it for myself is enough for me to know I fixed it for
you too.

Now if I couldn't reproduce the bug, I'd go back to you in a attempt to
test patches and pinpoint the problem. That just isn't the case here.
Once I reproduce the problem, your job is done.

> > come to us where our development happens.
> > We have a commit list to the repo and a developers list.
> 
> As I said in the previous mail, I did check the archives and saw nothing
> trivially relevant. But of course, I could have missed something.

Then you must not be looking in the proper place.

> > I've never sent my patches to the list prior to inclusion in the kernel,
> > and a lot of folks don't, depending on neccessity. I don't see the need
> > to start now, not when interested parties have a place to go to see the
> > patches before hand anyway.
> 
> Keeping the development discussions on your own list is of course ok,
> but I believe posting an announce on lkml each time you send something
> for inclusion in the main kernel would be a good idea. Especially when
> you're not sending patches every day and when your patches tend to be
> considerably big.
> 
> This is what (a lot of) other subsystem maintainers do.

But not all...I personally choose to keep specific discussions about
linux1394 on the linux1394 mailing lists. That's not to say I wont
respond on this list, but it is to say that if I announce something
important, it will be there and only there.

Sounds to me like you want to be in the middle of me and Marcelo. That
neither I nor him have the ability to agree on what patches should and
should not be moved from Linux1394 to the 2.4.x tree. Do you want either
or both of our jobs?

The fact is that the current 2.4.21-rc+bk tree is more stable for
ieee1394 than it was in 2.4.20. The only drawback at this point in time
is the fact that you have to run a single script for sbp2 to scan scsi
devices. I could fill a page with the things that are fixed. I have
_zero_ bug reports about the current tree other than a nagging problem
with a rare TI chip that doesn't seem to fit into OHCI specs too well.

No crashes, no lockups...now that's progress over 2.4.20's ieee1394
tree. I can tell you 20 ways to crash that with something as simple as
replugging a device.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo       - http://www.deqo.com/

Re: The IEEE-1394 saga continued... [ was: IEEE-1394 problem on init ]

[Ben Collins]

On Sat, Apr 26, 2003 at 07:00:19PM +0200, Stelian Pop wrote:
> On Sat, Apr 26, 2003 at 12:12:34PM -0400, Ben Collins wrote:
> 
> > > The FAQ on linux1394 site was indeed updated 2 days ago. I'm sorry
> > > I didn't think to look there.
> > 
> > The rescan-scsi-bus.sh info has been there since sbp2 was introduced
> > over a year ago.
> 
> The wording in that section suggested something changed three days ago.

It was updated to reflect the superior hotplug support in 2.5.x.


-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo       - http://www.deqo.com/

Re: The IEEE-1394 saga continued... [ was: IEEE-1394 problem on init ]

[Stelian Pop]

On Sat, Apr 26, 2003 at 12:12:34PM -0400, Ben Collins wrote:

> > The FAQ on linux1394 site was indeed updated 2 days ago. I'm sorry
> > I didn't think to look there.
> 
> The rescan-scsi-bus.sh info has been there since sbp2 was introduced
> over a year ago.

The wording in that section suggested something changed three days ago.

> > This means that if you do
> > 	rmmod sbp2
> > 	modprobe sbp2
> > your SCSI device will be lost and you'll have to call 'rescan-scsi-bus'
> > by hand...
> 
> That's what /sbin/hotplug et al are for.

I don't think you understood my problem. Read again.

> in scsi/ieee1394, use 2.5.x.
> 
> Look, I'm not going to get pulled into this argument anymore. 

Neither will I.

Stelian.
-- 
Stelian Pop <stelian.pop@fr.alcove.com>
Alcove - http://www.alcove.com

Re: The IEEE-1394 saga continued... [ was: IEEE-1394 problem on init ]

[Stelian Pop]

On Sat, Apr 26, 2003 at 12:25:04PM -0400, Ben Collins wrote:

> Now if I couldn't reproduce the bug, I'd go back to you in a attempt to
> test patches and pinpoint the problem. That just isn't the case here.
> Once I reproduce the problem, your job is done.

It is done from your point of view but not mine. You expect people
to find bugs and report to you. I expect the bug to be fixed and 
the solution be given to me. See the difference ?

Look I'm not a luser, I do maintain several projects myself, so it's
not like I'm talking of osmething I don't fully understand. When someone
reports a bug, even if I can fix and test the fix myself, I do have
the respect to let the reported know it is fixed, and how and when he
will get the fix.

> > As I said in the previous mail, I did check the archives and saw nothing
> > trivially relevant. But of course, I could have missed something.
> 
> Then you must not be looking in the proper place.

Thanks for pointing me to the right thread then.

> But not all...I personally choose to keep specific discussions about
> linux1394 on the linux1394 mailing lists. That's not to say I wont
> respond on this list, but it is to say that if I announce something
> important, it will be there and only there.

If the final point is that you just *don't want'* sending an announce mail
(either here or on your own linux1394-announce) than I think it is clear
why we had all this thread.
> 
> Sounds to me like you want to be in the middle of me and Marcelo. That
> neither I nor him have the ability to agree on what patches should and
> should not be moved from Linux1394 to the 2.4.x tree. Do you want either
> or both of our jobs?

I never said that, and you know it. But it is part of maintainer job to
answer to criticism and be open to suggestions.

I don't think there is anymore to get from this discussion, so let's end
it there.

Stelian.
-- 
Stelian Pop <stelian.pop@fr.alcove.com>
Alcove - http://www.alcove.com