* IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]
@ 2003-04-23 12:29 Tony Spinillo
2003-04-23 12:53 ` Stelian Pop
0 siblings, 1 reply; 36+ messages in thread
From: Tony Spinillo @ 2003-04-23 12:29 UTC (permalink / raw)
To: linux-kernel; +Cc: stelian.pop
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.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]
2003-04-23 12:29 IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ] Tony Spinillo
@ 2003-04-23 12:53 ` Stelian Pop
2003-04-23 13:01 ` Ben Collins
0 siblings, 1 reply; 36+ messages in thread
From: Stelian Pop @ 2003-04-23 12:53 UTC (permalink / raw)
To: Tony Spinillo; +Cc: Linux Kernel Mailing List, Ben Collins
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
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]
2003-04-23 12:53 ` Stelian Pop
@ 2003-04-23 13:01 ` Ben Collins
2003-04-23 13:22 ` Stelian Pop
0 siblings, 1 reply; 36+ messages in thread
From: Ben Collins @ 2003-04-23 13:01 UTC (permalink / raw)
To: Stelian Pop, Tony Spinillo, Linux Kernel Mailing List
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/
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]
2003-04-23 13:01 ` Ben Collins
@ 2003-04-23 13:22 ` Stelian Pop
2003-04-23 13:32 ` Ben Collins
0 siblings, 1 reply; 36+ messages in thread
From: Stelian Pop @ 2003-04-23 13:22 UTC (permalink / raw)
To: Ben Collins; +Cc: Tony Spinillo, Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]
2003-04-23 13:22 ` Stelian Pop
@ 2003-04-23 13:32 ` Ben Collins
2003-04-23 13:46 ` Ben Collins
2003-04-23 13:58 ` Stelian Pop
0 siblings, 2 replies; 36+ messages in thread
From: Ben Collins @ 2003-04-23 13:32 UTC (permalink / raw)
To: Stelian Pop, Tony Spinillo, Linux Kernel Mailing List
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/
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]
2003-04-23 13:32 ` Ben Collins
@ 2003-04-23 13:46 ` Ben Collins
2003-04-23 13:58 ` Stelian Pop
1 sibling, 0 replies; 36+ messages in thread
From: Ben Collins @ 2003-04-23 13:46 UTC (permalink / raw)
To: Tony Spinillo; +Cc: Linux Kernel Mailing List
> 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);
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]
2003-04-23 13:32 ` Ben Collins
2003-04-23 13:46 ` Ben Collins
@ 2003-04-23 13:58 ` Stelian Pop
2003-04-23 13:54 ` Ben Collins
1 sibling, 1 reply; 36+ messages in thread
From: Stelian Pop @ 2003-04-23 13:58 UTC (permalink / raw)
To: Ben Collins; +Cc: Tony Spinillo, Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]
2003-04-23 13:58 ` Stelian Pop
@ 2003-04-23 13:54 ` Ben Collins
2003-04-23 14:21 ` Stelian Pop
0 siblings, 1 reply; 36+ messages in thread
From: Ben Collins @ 2003-04-23 13:54 UTC (permalink / raw)
To: Stelian Pop; +Cc: Linux Kernel Mailing List
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/
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]
2003-04-23 13:54 ` Ben Collins
@ 2003-04-23 14:21 ` Stelian Pop
2003-04-23 14:23 ` Ben Collins
0 siblings, 1 reply; 36+ messages in thread
From: Stelian Pop @ 2003-04-23 14:21 UTC (permalink / raw)
To: Ben Collins; +Cc: Linux Kernel Mailing List, Marcelo Tosatti
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]
2003-04-23 14:21 ` Stelian Pop
@ 2003-04-23 14:23 ` Ben Collins
2003-04-23 14:51 ` Stelian Pop
0 siblings, 1 reply; 36+ messages in thread
From: Ben Collins @ 2003-04-23 14:23 UTC (permalink / raw)
To: Stelian Pop, Linux Kernel Mailing List, Marcelo Tosatti
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/
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]
2003-04-23 14:23 ` Ben Collins
@ 2003-04-23 14:51 ` Stelian Pop
2003-04-23 14:44 ` Ben Collins
2003-04-23 14:48 ` Ben Collins
0 siblings, 2 replies; 36+ messages in thread
From: Stelian Pop @ 2003-04-23 14:51 UTC (permalink / raw)
To: Ben Collins; +Cc: Linux Kernel Mailing List, Marcelo Tosatti
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]
2003-04-23 14:51 ` Stelian Pop
@ 2003-04-23 14:44 ` Ben Collins
2003-04-23 14:48 ` Ben Collins
1 sibling, 0 replies; 36+ messages in thread
From: Ben Collins @ 2003-04-23 14:44 UTC (permalink / raw)
To: Stelian Pop, Linux Kernel Mailing List, Marcelo Tosatti
> 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/
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]
2003-04-23 14:51 ` Stelian Pop
2003-04-23 14:44 ` Ben Collins
@ 2003-04-23 14:48 ` Ben Collins
2003-04-23 15:29 ` Stelian Pop
1 sibling, 1 reply; 36+ messages in thread
From: Ben Collins @ 2003-04-23 14:48 UTC (permalink / raw)
To: Stelian Pop, Linux Kernel Mailing List, Marcelo Tosatti
> 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/
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]
2003-04-23 14:48 ` Ben Collins
@ 2003-04-23 15:29 ` Stelian Pop
2003-04-23 19:13 ` Marcelo Tosatti
0 siblings, 1 reply; 36+ messages in thread
From: Stelian Pop @ 2003-04-23 15:29 UTC (permalink / raw)
To: Ben Collins; +Cc: Linux Kernel Mailing List, Marcelo Tosatti
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]
2003-04-23 15:29 ` Stelian Pop
@ 2003-04-23 19:13 ` Marcelo Tosatti
2003-04-23 19:05 ` Ben Collins
` (2 more replies)
0 siblings, 3 replies; 36+ messages in thread
From: Marcelo Tosatti @ 2003-04-23 19:13 UTC (permalink / raw)
To: Stelian Pop; +Cc: Ben Collins, Linux Kernel Mailing List
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.
*!@#!&*.
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]
2003-04-23 19:13 ` Marcelo Tosatti
@ 2003-04-23 19:05 ` Ben Collins
2003-04-23 19:27 ` Marcelo Tosatti
2003-04-23 20:20 ` Stelian Pop
2003-04-24 21:44 ` IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ] Bill Davidsen
2 siblings, 1 reply; 36+ messages in thread
From: Ben Collins @ 2003-04-23 19:05 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Stelian Pop, Linux Kernel Mailing List
> > > 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/
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]
2003-04-23 19:05 ` Ben Collins
@ 2003-04-23 19:27 ` Marcelo Tosatti
0 siblings, 0 replies; 36+ messages in thread
From: Marcelo Tosatti @ 2003-04-23 19:27 UTC (permalink / raw)
To: Ben Collins; +Cc: Stelian Pop, Linux Kernel Mailing List
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.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]
2003-04-23 19:13 ` Marcelo Tosatti
2003-04-23 19:05 ` Ben Collins
@ 2003-04-23 20:20 ` Stelian Pop
2003-04-23 20:24 ` Ben Collins
2003-04-24 21:44 ` IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ] Bill Davidsen
2 siblings, 1 reply; 36+ messages in thread
From: Stelian Pop @ 2003-04-23 20:20 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Ben Collins, Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]
2003-04-23 20:20 ` Stelian Pop
@ 2003-04-23 20:24 ` Ben Collins
2003-04-23 20:42 ` Stelian Pop
0 siblings, 1 reply; 36+ messages in thread
From: Ben Collins @ 2003-04-23 20:24 UTC (permalink / raw)
To: Stelian Pop, Marcelo Tosatti, Linux Kernel Mailing List
> 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/
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]
2003-04-23 20:24 ` Ben Collins
@ 2003-04-23 20:42 ` Stelian Pop
2003-04-26 8:29 ` The IEEE-1394 saga continued... [ was: IEEE-1394 problem on init ] Stelian Pop
0 siblings, 1 reply; 36+ messages in thread
From: Stelian Pop @ 2003-04-23 20:42 UTC (permalink / raw)
To: Ben Collins; +Cc: Marcelo Tosatti, Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* The IEEE-1394 saga continued... [ was: IEEE-1394 problem on init ]
2003-04-23 20:42 ` Stelian Pop
@ 2003-04-26 8:29 ` Stelian Pop
2003-04-26 14:34 ` Ben Collins
2003-04-26 14:40 ` Ben Collins
0 siblings, 2 replies; 36+ messages in thread
From: Stelian Pop @ 2003-04-26 8:29 UTC (permalink / raw)
To: Ben Collins, Marcelo Tosatti, Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: The IEEE-1394 saga continued... [ was: IEEE-1394 problem on init ]
2003-04-26 8:29 ` The IEEE-1394 saga continued... [ was: IEEE-1394 problem on init ] Stelian Pop
@ 2003-04-26 14:34 ` Ben Collins
2003-04-26 16:10 ` Stelian Pop
2003-04-26 14:40 ` Ben Collins
1 sibling, 1 reply; 36+ messages in thread
From: Ben Collins @ 2003-04-26 14:34 UTC (permalink / raw)
To: Stelian Pop, Marcelo Tosatti, Linux Kernel Mailing List
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/
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: The IEEE-1394 saga continued... [ was: IEEE-1394 problem on init ]
2003-04-26 14:34 ` Ben Collins
@ 2003-04-26 16:10 ` Stelian Pop
2003-04-26 16:12 ` Ben Collins
0 siblings, 1 reply; 36+ messages in thread
From: Stelian Pop @ 2003-04-26 16:10 UTC (permalink / raw)
To: Ben Collins; +Cc: Marcelo Tosatti, Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: The IEEE-1394 saga continued... [ was: IEEE-1394 problem on init ]
2003-04-26 16:10 ` Stelian Pop
@ 2003-04-26 16:12 ` Ben Collins
2003-04-26 17:00 ` Stelian Pop
0 siblings, 1 reply; 36+ messages in thread
From: Ben Collins @ 2003-04-26 16:12 UTC (permalink / raw)
To: Stelian Pop, Marcelo Tosatti, Linux Kernel Mailing List
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/
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: The IEEE-1394 saga continued... [ was: IEEE-1394 problem on init ]
2003-04-26 16:12 ` Ben Collins
@ 2003-04-26 17:00 ` Stelian Pop
2003-04-26 16:59 ` Ben Collins
0 siblings, 1 reply; 36+ messages in thread
From: Stelian Pop @ 2003-04-26 17:00 UTC (permalink / raw)
To: Ben Collins; +Cc: Marcelo Tosatti, Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: The IEEE-1394 saga continued... [ was: IEEE-1394 problem on init ]
2003-04-26 8:29 ` The IEEE-1394 saga continued... [ was: IEEE-1394 problem on init ] Stelian Pop
2003-04-26 14:34 ` Ben Collins
@ 2003-04-26 14:40 ` Ben Collins
2003-04-26 16:23 ` Stelian Pop
1 sibling, 1 reply; 36+ messages in thread
From: Ben Collins @ 2003-04-26 14:40 UTC (permalink / raw)
To: Stelian Pop, Marcelo Tosatti, Linux Kernel Mailing List
> 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/
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: The IEEE-1394 saga continued... [ was: IEEE-1394 problem on init ]
2003-04-26 14:40 ` Ben Collins
@ 2003-04-26 16:23 ` Stelian Pop
2003-04-26 16:25 ` Ben Collins
0 siblings, 1 reply; 36+ messages in thread
From: Stelian Pop @ 2003-04-26 16:23 UTC (permalink / raw)
To: Ben Collins; +Cc: Marcelo Tosatti, Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: The IEEE-1394 saga continued... [ was: IEEE-1394 problem on init ]
2003-04-26 16:23 ` Stelian Pop
@ 2003-04-26 16:25 ` Ben Collins
2003-04-26 17:15 ` Stelian Pop
0 siblings, 1 reply; 36+ messages in thread
From: Ben Collins @ 2003-04-26 16:25 UTC (permalink / raw)
To: Stelian Pop, Linux Kernel Mailing List
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/
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: The IEEE-1394 saga continued... [ was: IEEE-1394 problem on init ]
2003-04-26 16:25 ` Ben Collins
@ 2003-04-26 17:15 ` Stelian Pop
0 siblings, 0 replies; 36+ messages in thread
From: Stelian Pop @ 2003-04-26 17:15 UTC (permalink / raw)
To: Ben Collins; +Cc: Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]
2003-04-23 19:13 ` Marcelo Tosatti
2003-04-23 19:05 ` Ben Collins
2003-04-23 20:20 ` Stelian Pop
@ 2003-04-24 21:44 ` Bill Davidsen
2003-04-24 21:41 ` Ben Collins
2 siblings, 1 reply; 36+ messages in thread
From: Bill Davidsen @ 2003-04-24 21:44 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Stelian Pop, Ben Collins, Linux Kernel Mailing List
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.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]
2003-04-24 21:44 ` IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ] Bill Davidsen
@ 2003-04-24 21:41 ` Ben Collins
2003-04-25 18:06 ` Bill Davidsen
0 siblings, 1 reply; 36+ messages in thread
From: Ben Collins @ 2003-04-24 21:41 UTC (permalink / raw)
To: Bill Davidsen; +Cc: Linux Kernel Mailing List
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/
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]
2003-04-24 21:41 ` Ben Collins
@ 2003-04-25 18:06 ` Bill Davidsen
2003-04-25 18:16 ` Ben Collins
0 siblings, 1 reply; 36+ messages in thread
From: Bill Davidsen @ 2003-04-25 18:06 UTC (permalink / raw)
To: Ben Collins; +Cc: Linux Kernel Mailing List
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.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]
2003-04-25 18:06 ` Bill Davidsen
@ 2003-04-25 18:16 ` Ben Collins
2003-04-26 10:36 ` Bill Davidsen
0 siblings, 1 reply; 36+ messages in thread
From: Ben Collins @ 2003-04-25 18:16 UTC (permalink / raw)
To: Bill Davidsen; +Cc: Linux Kernel Mailing List
> 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/
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]
2003-04-25 18:16 ` Ben Collins
@ 2003-04-26 10:36 ` Bill Davidsen
0 siblings, 0 replies; 36+ messages in thread
From: Bill Davidsen @ 2003-04-26 10:36 UTC (permalink / raw)
To: Ben Collins; +Cc: Linux Kernel Mailing List
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.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Linux 2.4.21-rc1
@ 2003-04-21 18:47 Marcelo Tosatti
2003-04-23 7:59 ` IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ] Stelian Pop
0 siblings, 1 reply; 36+ messages in thread
From: Marcelo Tosatti @ 2003-04-21 18:47 UTC (permalink / raw)
To: lkml
Here goes the first candidate for 2.4.21.
Please test it extensively.
Summary of changes from v2.4.21-pre7 to v2.4.21-rc1
============================================
<alborchers@steinerpoint.com>:
o USB: patch for oops in io_edgeport.c
<arndt@lin02384n012.mc.schoenewald.de>:
o USB: Patch against unusual_devs.h to enable Pontis SP600
<baldrick@wanadoo.fr>:
o USB: uhci bandaid
<bryder@paradise.net.nz>:
o USB: ftdi_sio update
<bwa@us.ibm.com>:
o [SCTP/IPV6]: Move sockaddr storage and in6addr_{any,loopback} to generic places
<chas@cmf.nrl.navy.mil>:
o [ATM]: Make ia64 include ATM driver config
<chas@locutus.cmf.nrl.navy.mil>:
o [ATM]: Get lec net_device names correct
o [ATM]: Obsolete some atm_vcc members
o [ATM]: Fix idt77252/sch_atm/pppoatm compilation
o [ATM]: cleanup nicstat, suni and idt77105
o [ATM] nicstar doesnt count all dropped pdus and powerpc fixup
o [ATM] s/uni driver overwrites 8-/16-bit mode
o [ATM]: Fix total_len calculation in IPHASE driver
o [ATM]: Fix IPHASE build with debugging enabled
<dlstevens@us.ibm.com>:
o [IPV6]: Add anycast support
<gandalf@netfilter.org>:
o [NETFILTER]: Fix modify-after-free bug in ip_conntrack
<gandalf@wlug.westbo.se>:
o [NETFILTER]: Fix ipfwadm_core.c compile failure
o [NETFILTER IPV6]: Fix Makefile typo
<green@linuxhacker.ru>:
o [VLAN]: Fix memory leak in procfs handling
<henning@meier-geinitz.de>:
o USB: scanner.c endpoint detection fix
<laforge@netfilter.org>:
o [NETFILTER]: iptables iptable_mangle LOCAL_IN bugfix
o [NETFILTER]: ipt_REJECT bugfix for TCP RST packets + asymm. routing
<legoll@free.fr>:
o USB: New USB serial device ID: Asus A600 PDA cradle
<mb@ozaba.mine.nu>:
o [NETFILTER]: Add tftp conntrack + NAT support
<mrr@nexthop.com>:
o [IPV6]: Allow protocol to percolate up into rt6 routing operations
<netfilter@interlinx.bc.ca>:
o [NETFILTER]: Add amanda conntrack + NAT support
<niv@us.ibm.com>:
o [TCP]: Missing SNMP stats
<paulm@routefree.com>:
o [NETFILTER]: ip_conntrack bugfix for LOCAL_NAT and PPTP
<riel@redhat.com>:
o Fix kunmap_atomic debugging problem
<riel@surriel.com>:
o [ATM]: Compile fix for net/atm/br2684.c
<soruk@eridani.co.uk>:
o USB: enable Motorola cellphone USB modems
<swiergot@intersec.pl>:
o Fix ac97 incomplete headers
<yoshfuji@nuts.ninka.net>:
o [IPV6]: Use RFC2553 constant variable
Adrian Bunk <bunk@fs.tum.de>:
o [NF/IPV6]: Remove all ipv6_ext_hdrs from ip6tables
o [ATM]: Fix IPHASE driver build
o Fix aic7xxx compilation
Alan Stern <stern@rowland.harvard.edu>:
o USB: usb-storage START-STOP under Linux 2.4
Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>:
o [IPV4]: Fix deadlock in IGMP locking
o [IPV6]: Correct CHECKSUM_HW handling in tcp_v6_send_check
Andi Kleen <ak@muc.de>:
o x86-64 update
Andreas Dilger <adilger@clusterfs.com>:
o don't allocate/free blocks in system areas
Andries E. Brouwer <andries.brouwer@cwi.nl>:
o compilation fix for 2.4.21-pre7
o Fix SCSI size reporting
Ben Collins <bcollins@debian.org>:
o IEEE-1394/Firewire update
Benjamin Herrenschmidt <benh@kernel.crashing.org>:
o PPC32: Do better cache flushes around L2 cache ctrl register changes
o PPC32: Factor out common code for saving/restore CPU special-purpose registers, used on SMP and for sleep/wakeup.
o PPC32: Make sure IPI handlers run with interrupts disabled
o PPC32: Add proper /proc/ide entry for pmac
o PPC32: Update ide-pmac driver
Christoph Hellwig <hch@lst.de>:
o [NETFILTER]: 2.4 firewalling compat code removal
o [NET]: Backport generic fc_type_trans to 2.4
David Brownell <david-b@pacbell.net>:
o USB: ehci-hcd, minor hardware tweaks
o USB: usbcore deadlock paranoia
o USB: CDC Ether fix notifications
David S. Miller <davem@nuts.ninka.net>:
o [IPV6]: Undo __constant_{n,h}to{n,h}l from anycast patch
o [SPARC64]: Fix trap stack allocations so gcc-3.x builds work
o [SCHED]: Some schedulers forget to flush filter list at destroy
o [PKTSCHED]: Fix double-define of __inline__ et al
o [IP TUNNEL]: inet_ecn_decapsulate modifies bits in wrong header
o [PKT_SCHED]: Remove ugly arch ifdefs from generic code
o [NETFILTER IPV6]: Fix route leak in ip6_route_me_harder
Geert Uytterhoeven <geert@linux-m68k.org>:
o Amiflop mod_timer()
o Duplicate PROC_CONSOLE()
o 2.4 IDE core code for m68k
o 2.4 IDE driver code for m68k
o M68k raw I/O updates
o Generic RTC driver
o M68k ndelay()
o M68k needs WANT_PAGE_VIRTUAL
Hideaki Yoshifuji <yoshfuji@linux-ipv6.org>:
o [IPV6]: Use "const" qualifier
o [IPV6]: Use ipv6_addr_any() for testing unspecified address
o [IPV6]: Don't allow multiple instances of the same IPv6 address on an interface
o [IPV6]: Set noblock to 1 in NDISC sock_alloc_send_skb calls
James Morris <jmorris@intercode.com.au>:
o [NET]: dst_clone --> dst_hold where appropriate
o [PKTSCHED]: Kill redefinition of IPPROTO_ESP in sch_sfq.c
Jens Axboe <axboe@suse.de>:
o Fix ide request races which resulted in corruption
Marcelo Tosatti <marcelo@freak.distro.conectiva>:
o Cset exclude: mikpe@csd.uu.se|ChangeSet|20030417235935|56567
o Add missing HPT366 ID
o Updated EXTRAVERSION to -rc1
Mark A. Greer <mgreer@mvista.com>:
o PPC32: Add support for SERIAL_IO_PORT ports to the gen550 backend
Mikael Pettersson <mikpe@csd.uu.se>:
o fix dmi_scan breakage
o fix APIC bus errors on SMP K7 boxes in UP mode
Oleg Drokin <green@angband.namesys.com>:
o reiserfs: Fix recenly introduced journal sanity check that breaks replay on old filesystems
o reiserfs: Fix for journal replay process, to only replay transactions from last mount. By Chris Mason
Oliver Neukum <oliver@neukum.org>:
o Honour HFS lock bits
Paul Mackerras <paulus@samba.org>:
o PPC32: Fix the interrupt entry path for POWER3 processors
o PPC32: Clean up arch/ppc/mm/Makefile a little
o PPC32: xmon fixes for CHRP, powerbooks, and SMP systems
o PPC32: fix indentation in include/asm-ppc/bootinfo.h
o PPC32: Restructure the top-level interrupt handling loop
o PPC32: Align boot wrapper data segment on page boundary
o PPC32: Make readb/w/l completely synchronous
Petko Manolov <petkan@users.sourceforge.net>:
o USB: pegasus link status detection fix
Randy Dunlap <randy.dunlap@verizon.net>:
o [NET]: typo and comment fixes
Randy Dunlap <rddunlap@osdl.org>:
o update unexpected IO APIC detection
Rusty Russell <rusty@rustcorp.com.au>:
o Fix minor NAT parsing issue
Stephen C. Tweedie <sct@redhat.com>:
o 2.4: Fix for jbd compiler warnings
Tom Rini <trini@kernel.crashing.org>:
o PPC32: Actually fix KGDB like Mark Greer mentioned
o PPC32: Remove an option to partically disable the d-cache
^ permalink raw reply [flat|nested] 36+ messages in thread* IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ]
2003-04-21 18:47 Linux 2.4.21-rc1 Marcelo Tosatti
@ 2003-04-23 7:59 ` Stelian Pop
0 siblings, 0 replies; 36+ messages in thread
From: Stelian Pop @ 2003-04-23 7:59 UTC (permalink / raw)
To: Marcelo Tosatti, Ben Collins; +Cc: Linux Kernel Mailing List
On Mon, Apr 21, 2003 at 03:47:32PM -0300, Marcelo Tosatti wrote:
> Here goes the first candidate for 2.4.21.
>
> Please test it extensively.
[...]
> Ben Collins <bcollins@debian.org>:
> o IEEE-1394/Firewire update
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.
Stelian.
--
Stelian Pop <stelian.pop@fr.alcove.com>
Alcove - http://www.alcove.com
^ permalink raw reply [flat|nested] 36+ messages in thread
end of thread, other threads:[~2003-04-26 17:03 UTC | newest]
Thread overview: 36+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-04-23 12:29 IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ] Tony Spinillo
2003-04-23 12:53 ` Stelian Pop
2003-04-23 13:01 ` Ben Collins
2003-04-23 13:22 ` Stelian Pop
2003-04-23 13:32 ` Ben Collins
2003-04-23 13:46 ` Ben Collins
2003-04-23 13:58 ` Stelian Pop
2003-04-23 13:54 ` Ben Collins
2003-04-23 14:21 ` Stelian Pop
2003-04-23 14:23 ` Ben Collins
2003-04-23 14:51 ` Stelian Pop
2003-04-23 14:44 ` Ben Collins
2003-04-23 14:48 ` Ben Collins
2003-04-23 15:29 ` Stelian Pop
2003-04-23 19:13 ` Marcelo Tosatti
2003-04-23 19:05 ` Ben Collins
2003-04-23 19:27 ` Marcelo Tosatti
2003-04-23 20:20 ` Stelian Pop
2003-04-23 20:24 ` Ben Collins
2003-04-23 20:42 ` Stelian Pop
2003-04-26 8:29 ` The IEEE-1394 saga continued... [ was: IEEE-1394 problem on init ] Stelian Pop
2003-04-26 14:34 ` Ben Collins
2003-04-26 16:10 ` Stelian Pop
2003-04-26 16:12 ` Ben Collins
2003-04-26 17:00 ` Stelian Pop
2003-04-26 16:59 ` Ben Collins
2003-04-26 14:40 ` Ben Collins
2003-04-26 16:23 ` Stelian Pop
2003-04-26 16:25 ` Ben Collins
2003-04-26 17:15 ` Stelian Pop
2003-04-24 21:44 ` IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ] Bill Davidsen
2003-04-24 21:41 ` Ben Collins
2003-04-25 18:06 ` Bill Davidsen
2003-04-25 18:16 ` Ben Collins
2003-04-26 10:36 ` Bill Davidsen
-- strict thread matches above, loose matches on Subject: below --
2003-04-21 18:47 Linux 2.4.21-rc1 Marcelo Tosatti
2003-04-23 7:59 ` IEEE-1394 problem on init [ was Re: Linux 2.4.21-rc1 ] Stelian Pop
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).