* 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; 35+ 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] 35+ 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; 35+ 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] 35+ 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; 35+ 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] 35+ 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; 35+ 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] 35+ 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; 35+ 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] 35+ 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; 35+ 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] 35+ 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; 35+ 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] 35+ 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; 35+ 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] 35+ 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; 35+ 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] 35+ 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; 35+ 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] 35+ 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; 35+ 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] 35+ 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; 35+ 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] 35+ 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; 35+ 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] 35+ 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; 35+ 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] 35+ 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; 35+ 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] 35+ 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; 35+ 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] 35+ 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; 35+ 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] 35+ 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; 35+ 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] 35+ 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; 35+ 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] 35+ messages in thread