Re: [2.4.0-test9-pre5] SCSI still broken, trident/mixer still broken
On Thu, Sep 21 2000, Douglas Gilbert wrote: > Torben Mathiasen wrote: > > > > Ok, small patch cooked up. Not tested, not compiled. Give > > it a try, and if it works please send it off to Linus. > > I really need to get some work done on a project... > > Here is a very similar patch that has been tested > [with a USB zip drive using sg (builtin) to read it]. > It worked and the /proc/scsi/sg directory was > properly populated. > Looks good, but you should make the init functions static. -- Torben Mathiasen <[EMAIL PROTECTED]> Linux ThunderLAN maintainer http://tlan.kernel.dk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4.0-test9-pre5] SCSI still broken, trident/mixer still broken
On Thu, Sep 21, 2000 at 09:39:07PM +0200, Torben Mathiasen wrote:
> Ok, small patch cooked up. Not tested, not compiled. Give
> it a try, and if it works please send it off to Linus.
> I really need to get some work done on a project...
This worked, thanks. :)
Simon-
[ Stormix Technologies Inc. ][ NetNation Communications Inc. ]
[ [EMAIL PROTECTED] ][ [EMAIL PROTECTED]]
[ Opinions expressed are not necessarily those of my employers. ]
> diff -ur --exclude-from=/root/torben /opt/kernel/kernels/linux/drivers/scsi/sg.c
>linux/drivers/scsi/sg.c
> --- /opt/kernel/kernels/linux/drivers/scsi/sg.c Thu Sep 21 21:29:44 2000
> +++ linux/drivers/scsi/sg.c Thu Sep 21 21:35:46 2000
> @@ -1298,18 +1298,18 @@
> }
>
> #ifdef MODULE
> -
> MODULE_PARM(def_reserved_size, "i");
> MODULE_PARM_DESC(def_reserved_size, "size of buffer reserved for each fd");
> +#endif
>
> -int init_module(void) {
> +static int __init init_sg(void) {
> if (def_reserved_size >= 0)
> sg_big_buff = def_reserved_size;
> sg_template.module = THIS_MODULE;
> return scsi_register_module(MODULE_SCSI_DEV, _template);
> }
>
> -void cleanup_module( void)
> +static void __exit exit_sg( void)
> {
> #ifdef CONFIG_PROC_FS
> sg_proc_cleanup();
> @@ -1324,7 +1324,9 @@
> }
> sg_template.dev_max = 0;
> }
> -#endif /* MODULE */
> +
> +module_init(init_sg);
> +module_exit(exit_sg);
>
>
> #if 0
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4.0-test9-pre5] SCSI still broken, trident/mixer still broken
Torben Mathiasen wrote:
>
> Ok, small patch cooked up. Not tested, not compiled. Give
> it a try, and if it works please send it off to Linus.
> I really need to get some work done on a project...
Here is a very similar patch that has been tested
[with a USB zip drive using sg (builtin) to read it].
It worked and the /proc/scsi/sg directory was
properly populated.
Doug Gilbert
--- linux/drivers/scsi/sg.c Thu Sep 21 15:05:28 2000
+++ linux/drivers/scsi/sg.c3117 Thu Sep 21 15:22:08 2000
@@ -17,8 +17,8 @@
* any later version.
*
*/
- static char * sg_version_str = "Version: 3.1.16 (2716)";
- static int sg_version_num = 30116; /* 2 digits for each component */
+ static char * sg_version_str = "Version: 3.1.17 (2921)";
+ static int sg_version_num = 30117; /* 2 digits for each component */
/*
* D. P. Gilbert ([EMAIL PROTECTED], [EMAIL PROTECTED]), notes:
* - scsi logging is available via SCSI_LOG_TIMEOUT macros. First
@@ -1298,18 +1298,20 @@
}
#ifdef MODULE
-
MODULE_PARM(def_reserved_size, "i");
MODULE_PARM_DESC(def_reserved_size, "size of buffer reserved for each fd");
+#endif /* MODULE */
-int init_module(void) {
+int __init init_sg(void) {
+#ifdef MODULE
if (def_reserved_size >= 0)
sg_big_buff = def_reserved_size;
+#endif /* MODULE */
sg_template.module = THIS_MODULE;
return scsi_register_module(MODULE_SCSI_DEV, _template);
}
-void cleanup_module( void)
+void __exit exit_sg( void)
{
#ifdef CONFIG_PROC_FS
sg_proc_cleanup();
@@ -1324,7 +1326,6 @@
}
sg_template.dev_max = 0;
}
-#endif /* MODULE */
#if 0
@@ -2782,3 +2783,7 @@
return 1;
}
#endif /* CONFIG_PROC_FS */
+
+
+module_init(init_sg);
+module_exit(exit_sg);
Re: [2.4.0-test9-pre5] SCSI still broken, trident/mixer still broken
Ok, small patch cooked up. Not tested, not compiled. Give
it a try, and if it works please send it off to Linus.
I really need to get some work done on a project...
--
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer
http://tlan.kernel.dk
diff -ur --exclude-from=/root/torben /opt/kernel/kernels/linux/drivers/scsi/sg.c
linux/drivers/scsi/sg.c
--- /opt/kernel/kernels/linux/drivers/scsi/sg.c Thu Sep 21 21:29:44 2000
+++ linux/drivers/scsi/sg.c Thu Sep 21 21:35:46 2000
@@ -1298,18 +1298,18 @@
}
#ifdef MODULE
-
MODULE_PARM(def_reserved_size, "i");
MODULE_PARM_DESC(def_reserved_size, "size of buffer reserved for each fd");
+#endif
-int init_module(void) {
+static int __init init_sg(void) {
if (def_reserved_size >= 0)
sg_big_buff = def_reserved_size;
sg_template.module = THIS_MODULE;
return scsi_register_module(MODULE_SCSI_DEV, _template);
}
-void cleanup_module( void)
+static void __exit exit_sg( void)
{
#ifdef CONFIG_PROC_FS
sg_proc_cleanup();
@@ -1324,7 +1324,9 @@
}
sg_template.dev_max = 0;
}
-#endif /* MODULE */
+
+module_init(init_sg);
+module_exit(exit_sg);
#if 0
Re: [2.4.0-test9-pre5] SCSI still broken, trident/mixer still broken
On Thu, Sep 21 2000, Douglas Gilbert wrote: [delete] > > At one point before I followed some of the debug/logging commands listed > > at the top of sg.c and got an Oops as well... > > Seems as though I've got a lot of retesting to do. > Please note that the changes to the scsi midlayer requires all upper layers to use the module_init/exit functions. We do _not_ explicitly call the layers init funtions anymore. Adding the module stuff will probaly fix most problems (asuming module and builtin do not differ). The link order should make sure everything gets called in order. -- Torben Mathiasen <[EMAIL PROTECTED]> Linux ThunderLAN maintainer http://tlan.kernel.dk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4.0-test9-pre5] SCSI still broken, trident/mixer still broken
On Thu, Sep 21, 2000 at 02:34:01PM -0400, Douglas Gilbert wrote: > I do nearly all of my testing with sg as a module. > So this looks like (another recent) breakage. > > It is beginning to look like the sg driver is not > (properly) initialized when it is built into the > kernel. Perhaps you could put a printk in > sg_init() and sg_attach() to see if they are called. Actually, I also had a printk in sg_init() and it never got printed. I didn't have one in sg_attach, but I can try that. > > At one point before I followed some of the debug/logging commands listed > > at the top of sg.c and got an Oops as well... > > Seems as though I've got a lot of retesting to do. The oops may have been the result of it not being properly initialized or something... Simon- [ Stormix Technologies Inc. ][ NetNation Communications Inc. ] [ [EMAIL PROTECTED] ][ [EMAIL PROTECTED]] [ Opinions expressed are not necessarily those of my employers. ] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4.0-test9-pre5] SCSI still broken, trident/mixer still broken
Simon Kirby wrote: > > On Thu, Sep 21, 2000 at 01:12:27PM -0400, Douglas Gilbert wrote: > > > Interesting. 'cat /proc/scsi/scsi' should show the same > > devices as 'cat /proc/scsi/sg/device_strs' [and > > 'cat /proc/scsi/sg/devices']. If not, then the SCSI > > mid-level is not calling sg_detect() [in sg.c] for > > all new scsi devices detected by the mid-level. > > > > The sg_detect() routine is silent for all devices that > > are "owned" by other upper level drivers (i.e. disks, > > cdroms and tapes) but outputs a line for any other > > scsi type (e.g. scanners which are scsi type 6). > > I didn't fiddle with it too much, but I added a printk to sg_detect and > verified it was not getting called at all. I notice now, however, that I > don't even have a /proc/scsi/sg. Does that mean it's not getting > initialized at all? CONFIG_CHR_DEV_SG=y, assuming that's what needs to > be set (config didn't change between kernel versions). I do nearly all of my testing with sg as a module. So this looks like (another recent) breakage. It is beginning to look like the sg driver is not (properly) initialized when it is built into the kernel. Perhaps you could put a printk in sg_init() and sg_attach() to see if they are called. > At one point before I followed some of the debug/logging commands listed > at the top of sg.c and got an Oops as well... Seems as though I've got a lot of retesting to do. Doug Gilbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4.0-test9-pre5] SCSI still broken, trident/mixer still broken
Torben Mathiasen wrote: > > On Thu, Sep 21 2000, Douglas Gilbert wrote: > > [deleted] > > > It is not clear to me what "hacking" sg requires as > > Torben Mathiasen suggested in his response. This seems > > like a mid level problem. I'll check with my scsi > > scanner this evening. > > > > Well first of all the sg driver needs to be updated the > same way sd and sr was. Well looking at sr in test9-pre5 the only changes are the addition of 'static' before the sr_template definition and various functions. Sg already has the corresponding functions declared static and the sg_template definition has been changed to 'static'. So as far as I can see the mid level has failed to call sg_detect() when it should have. Simon has now confirmed with a printk that sg_detect() was not called for the scanner which the mid level obviously knows about. Doug Gilbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4.0-test9-pre5] SCSI still broken, trident/mixer still broken
On Thu, Sep 21, 2000 at 01:12:27PM -0400, Douglas Gilbert wrote: > Interesting. 'cat /proc/scsi/scsi' should show the same > devices as 'cat /proc/scsi/sg/device_strs' [and > 'cat /proc/scsi/sg/devices']. If not, then the SCSI > mid-level is not calling sg_detect() [in sg.c] for > all new scsi devices detected by the mid-level. > > The sg_detect() routine is silent for all devices that > are "owned" by other upper level drivers (i.e. disks, > cdroms and tapes) but outputs a line for any other > scsi type (e.g. scanners which are scsi type 6). I didn't fiddle with it too much, but I added a printk to sg_detect and verified it was not getting called at all. I notice now, however, that I don't even have a /proc/scsi/sg. Does that mean it's not getting initialized at all? CONFIG_CHR_DEV_SG=y, assuming that's what needs to be set (config didn't change between kernel versions). At one point before I followed some of the debug/logging commands listed at the top of sg.c and got an Oops as well... Simon- [ Stormix Technologies Inc. ][ NetNation Communications Inc. ] [ [EMAIL PROTECTED] ][ [EMAIL PROTECTED]] [ Opinions expressed are not necessarily those of my employers. ] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4.0-test9-pre5] SCSI still broken, trident/mixer still broken
On Thu, Sep 21 2000, Douglas Gilbert wrote: [deleted] > It is not clear to me what "hacking" sg requires as > Torben Mathiasen suggested in his response. This seems > like a mid level problem. I'll check with my scsi > scanner this evening. > Well first of all the sg driver needs to be updated the same way sd and sr was. > > Other random scsi notes: > - scsi modules were completely broken in 2.4.0-test9-pre4 > but worked again in pre5 [Makefile hacks?] [snip] Yes, check the scsi scanning thread, and the patch I sent yesterday. -- Torben Mathiasen <[EMAIL PROTECTED]> Linux ThunderLAN maintainer http://tlan.kernel.dk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4.0-test9-pre5] SCSI still broken, trident/mixer still broken
Simon Kirby wrote:
> Around 2.4.0-test9-pre2 (or so, definitely in pre3) both my SCSI scanner
> and trident sound card stopped being happy. They are still both broken
> in pre5. On test8, both work perfectly.
>
> On test8:
>
> (scsi0:6:0) Synchronous Data Transfer Request was rejected
> Vendor: Model: Scanner Rev: 1.70
> Type: ScannerANSI SCSI revision: 04
> Detected scsi generic sg0 at scsi0, channel 0, id 6, lun 0, type 6
> (scsi1:0:3:0) Synchronous at 8.0 Mbyte/sec, offset 31.
> Vendor: YAMAHAModel: CRW4416S Rev: 1.0e
> Type: CD-ROM ANSI SCSI revision: 02
> Detected scsi CD-ROM sr0 at scsi1, channel 0, id 3, lun 0
> scsi : detected 1 SCSI cdrom total.
> sr0: scsi3-mmc drive: 16x/16x writer cd/rw xa/form2 cdda tray
>
> ... on test9pre5 and test9pre3:
>
> (scsi0:6:0) Synchronous Data Transfer Request was rejected
> Vendor: Model: Scanner Rev: 1.70
> Type: ScannerANSI SCSI revision: 04
> (scsi0:0:3:0) Synchronous at 8.0 Mbyte/sec, offset 31.
> Vendor: YAMAHAModel: CRW4416S Rev: 1.0e
> Type: CD-ROM ANSI SCSI revision: 02
> Detected scsi CD-ROM sr0 at scsi0, channel 0, id 3, lun 0
> sr0: scsi3-mmc drive: 16x/16x writer cd/rw xa/form2 cdda tray
>
> ("Detected scsi generic..." line missing.)
[snipped trident problem report]
Interesting. 'cat /proc/scsi/scsi' should show the same
devices as 'cat /proc/scsi/sg/device_strs' [and
'cat /proc/scsi/sg/devices']. If not, then the SCSI
mid-level is not calling sg_detect() [in sg.c] for
all new scsi devices detected by the mid-level.
The sg_detect() routine is silent for all devices that
are "owned" by other upper level drivers (i.e. disks,
cdroms and tapes) but outputs a line for any other
scsi type (e.g. scanners which are scsi type 6).
It is not clear to me what "hacking" sg requires as
Torben Mathiasen suggested in his response. This seems
like a mid level problem. I'll check with my scsi
scanner this evening.
Other random scsi notes:
- scsi modules were completely broken in 2.4.0-test9-pre4
but worked again in pre5 [Makefile hacks?]
- the sd module's name has now reverted to its historic name
of "sd_mod.o"
- the imm module (scsi over parallel port for ZIP drives)
works on a UP machine but locks up a SMP machine (until
the NMI notices)
- the sg "stall" problem (plugged queues) has not been
addressed yet
Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4.0-test9-pre5] SCSI still broken, trident/mixer still broken
On Thu, Sep 21 2000, Simon Kirby wrote: > ... on test9pre5 and test9pre3: > > (scsi0:6:0) Synchronous Data Transfer Request was rejected > Vendor: Model: Scanner Rev: 1.70 > Type: ScannerANSI SCSI revision: 04 > (scsi0:0:3:0) Synchronous at 8.0 Mbyte/sec, offset 31. > Vendor: YAMAHAModel: CRW4416S Rev: 1.0e > Type: CD-ROM ANSI SCSI revision: 02 > Detected scsi CD-ROM sr0 at scsi0, channel 0, id 3, lun 0 > sr0: scsi3-mmc drive: 16x/16x writer cd/rw xa/form2 cdda tray > I suspect this to only be a minor issue. sg needs the same overhauls as the other layers. Unfortunately I won't be doing much hacking today, so if someone else could take a look. Otherwise I'll take a look, sometime tonight. Does it work when using modules? -- Torben Mathiasen <[EMAIL PROTECTED]> Linux ThunderLAN maintainer http://tlan.kernel.dk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4.0-test9-pre5] SCSI still broken, trident/mixer still broken
On Thu, Sep 21 2000, Simon Kirby wrote: ... on test9pre5 and test9pre3: (scsi0:6:0) Synchronous Data Transfer Request was rejected Vendor: Model: Scanner Rev: 1.70 Type: ScannerANSI SCSI revision: 04 (scsi0:0:3:0) Synchronous at 8.0 Mbyte/sec, offset 31. Vendor: YAMAHAModel: CRW4416S Rev: 1.0e Type: CD-ROM ANSI SCSI revision: 02 Detected scsi CD-ROM sr0 at scsi0, channel 0, id 3, lun 0 sr0: scsi3-mmc drive: 16x/16x writer cd/rw xa/form2 cdda tray I suspect this to only be a minor issue. sg needs the same overhauls as the other layers. Unfortunately I won't be doing much hacking today, so if someone else could take a look. Otherwise I'll take a look, sometime tonight. Does it work when using modules? -- Torben Mathiasen [EMAIL PROTECTED] Linux ThunderLAN maintainer http://tlan.kernel.dk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4.0-test9-pre5] SCSI still broken, trident/mixer still broken
Simon Kirby wrote:
Around 2.4.0-test9-pre2 (or so, definitely in pre3) both my SCSI scanner
and trident sound card stopped being happy. They are still both broken
in pre5. On test8, both work perfectly.
On test8:
(scsi0:6:0) Synchronous Data Transfer Request was rejected
Vendor: Model: Scanner Rev: 1.70
Type: ScannerANSI SCSI revision: 04
Detected scsi generic sg0 at scsi0, channel 0, id 6, lun 0, type 6
(scsi1:0:3:0) Synchronous at 8.0 Mbyte/sec, offset 31.
Vendor: YAMAHAModel: CRW4416S Rev: 1.0e
Type: CD-ROM ANSI SCSI revision: 02
Detected scsi CD-ROM sr0 at scsi1, channel 0, id 3, lun 0
scsi : detected 1 SCSI cdrom total.
sr0: scsi3-mmc drive: 16x/16x writer cd/rw xa/form2 cdda tray
... on test9pre5 and test9pre3:
(scsi0:6:0) Synchronous Data Transfer Request was rejected
Vendor: Model: Scanner Rev: 1.70
Type: ScannerANSI SCSI revision: 04
(scsi0:0:3:0) Synchronous at 8.0 Mbyte/sec, offset 31.
Vendor: YAMAHAModel: CRW4416S Rev: 1.0e
Type: CD-ROM ANSI SCSI revision: 02
Detected scsi CD-ROM sr0 at scsi0, channel 0, id 3, lun 0
sr0: scsi3-mmc drive: 16x/16x writer cd/rw xa/form2 cdda tray
("Detected scsi generic..." line missing.)
[snipped trident problem report]
Interesting. 'cat /proc/scsi/scsi' should show the same
devices as 'cat /proc/scsi/sg/device_strs' [and
'cat /proc/scsi/sg/devices']. If not, then the SCSI
mid-level is not calling sg_detect() [in sg.c] for
all new scsi devices detected by the mid-level.
The sg_detect() routine is silent for all devices that
are "owned" by other upper level drivers (i.e. disks,
cdroms and tapes) but outputs a line for any other
scsi type (e.g. scanners which are scsi type 6).
It is not clear to me what "hacking" sg requires as
Torben Mathiasen suggested in his response. This seems
like a mid level problem. I'll check with my scsi
scanner this evening.
Other random scsi notes:
- scsi modules were completely broken in 2.4.0-test9-pre4
but worked again in pre5 [Makefile hacks?]
- the sd module's name has now reverted to its historic name
of "sd_mod.o"
- the imm module (scsi over parallel port for ZIP drives)
works on a UP machine but locks up a SMP machine (until
the NMI notices)
- the sg "stall" problem (plugged queues) has not been
addressed yet
Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4.0-test9-pre5] SCSI still broken, trident/mixer still broken
On Thu, Sep 21 2000, Douglas Gilbert wrote: [deleted] It is not clear to me what "hacking" sg requires as Torben Mathiasen suggested in his response. This seems like a mid level problem. I'll check with my scsi scanner this evening. Well first of all the sg driver needs to be updated the same way sd and sr was. Other random scsi notes: - scsi modules were completely broken in 2.4.0-test9-pre4 but worked again in pre5 [Makefile hacks?] [snip] Yes, check the scsi scanning thread, and the patch I sent yesterday. -- Torben Mathiasen [EMAIL PROTECTED] Linux ThunderLAN maintainer http://tlan.kernel.dk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4.0-test9-pre5] SCSI still broken, trident/mixer still broken
On Thu, Sep 21, 2000 at 01:12:27PM -0400, Douglas Gilbert wrote: Interesting. 'cat /proc/scsi/scsi' should show the same devices as 'cat /proc/scsi/sg/device_strs' [and 'cat /proc/scsi/sg/devices']. If not, then the SCSI mid-level is not calling sg_detect() [in sg.c] for all new scsi devices detected by the mid-level. The sg_detect() routine is silent for all devices that are "owned" by other upper level drivers (i.e. disks, cdroms and tapes) but outputs a line for any other scsi type (e.g. scanners which are scsi type 6). I didn't fiddle with it too much, but I added a printk to sg_detect and verified it was not getting called at all. I notice now, however, that I don't even have a /proc/scsi/sg. Does that mean it's not getting initialized at all? CONFIG_CHR_DEV_SG=y, assuming that's what needs to be set (config didn't change between kernel versions). At one point before I followed some of the debug/logging commands listed at the top of sg.c and got an Oops as well... Simon- [ Stormix Technologies Inc. ][ NetNation Communications Inc. ] [ [EMAIL PROTECTED] ][ [EMAIL PROTECTED]] [ Opinions expressed are not necessarily those of my employers. ] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4.0-test9-pre5] SCSI still broken, trident/mixer still broken
Torben Mathiasen wrote: On Thu, Sep 21 2000, Douglas Gilbert wrote: [deleted] It is not clear to me what "hacking" sg requires as Torben Mathiasen suggested in his response. This seems like a mid level problem. I'll check with my scsi scanner this evening. Well first of all the sg driver needs to be updated the same way sd and sr was. Well looking at sr in test9-pre5 the only changes are the addition of 'static' before the sr_template definition and various functions. Sg already has the corresponding functions declared static and the sg_template definition has been changed to 'static'. So as far as I can see the mid level has failed to call sg_detect() when it should have. Simon has now confirmed with a printk that sg_detect() was not called for the scanner which the mid level obviously knows about. Doug Gilbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4.0-test9-pre5] SCSI still broken, trident/mixer still broken
Simon Kirby wrote: On Thu, Sep 21, 2000 at 01:12:27PM -0400, Douglas Gilbert wrote: Interesting. 'cat /proc/scsi/scsi' should show the same devices as 'cat /proc/scsi/sg/device_strs' [and 'cat /proc/scsi/sg/devices']. If not, then the SCSI mid-level is not calling sg_detect() [in sg.c] for all new scsi devices detected by the mid-level. The sg_detect() routine is silent for all devices that are "owned" by other upper level drivers (i.e. disks, cdroms and tapes) but outputs a line for any other scsi type (e.g. scanners which are scsi type 6). I didn't fiddle with it too much, but I added a printk to sg_detect and verified it was not getting called at all. I notice now, however, that I don't even have a /proc/scsi/sg. Does that mean it's not getting initialized at all? CONFIG_CHR_DEV_SG=y, assuming that's what needs to be set (config didn't change between kernel versions). I do nearly all of my testing with sg as a module. So this looks like (another recent) breakage. It is beginning to look like the sg driver is not (properly) initialized when it is built into the kernel. Perhaps you could put a printk in sg_init() and sg_attach() to see if they are called. At one point before I followed some of the debug/logging commands listed at the top of sg.c and got an Oops as well... Seems as though I've got a lot of retesting to do. Doug Gilbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4.0-test9-pre5] SCSI still broken, trident/mixer still broken
On Thu, Sep 21, 2000 at 02:34:01PM -0400, Douglas Gilbert wrote: I do nearly all of my testing with sg as a module. So this looks like (another recent) breakage. It is beginning to look like the sg driver is not (properly) initialized when it is built into the kernel. Perhaps you could put a printk in sg_init() and sg_attach() to see if they are called. Actually, I also had a printk in sg_init() and it never got printed. I didn't have one in sg_attach, but I can try that. At one point before I followed some of the debug/logging commands listed at the top of sg.c and got an Oops as well... Seems as though I've got a lot of retesting to do. The oops may have been the result of it not being properly initialized or something... Simon- [ Stormix Technologies Inc. ][ NetNation Communications Inc. ] [ [EMAIL PROTECTED] ][ [EMAIL PROTECTED]] [ Opinions expressed are not necessarily those of my employers. ] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4.0-test9-pre5] SCSI still broken, trident/mixer still broken
On Thu, Sep 21 2000, Douglas Gilbert wrote: [delete] At one point before I followed some of the debug/logging commands listed at the top of sg.c and got an Oops as well... Seems as though I've got a lot of retesting to do. Please note that the changes to the scsi midlayer requires all upper layers to use the module_init/exit functions. We do _not_ explicitly call the layers init funtions anymore. Adding the module stuff will probaly fix most problems (asuming module and builtin do not differ). The link order should make sure everything gets called in order. -- Torben Mathiasen [EMAIL PROTECTED] Linux ThunderLAN maintainer http://tlan.kernel.dk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4.0-test9-pre5] SCSI still broken, trident/mixer still broken
Ok, small patch cooked up. Not tested, not compiled. Give
it a try, and if it works please send it off to Linus.
I really need to get some work done on a project...
--
Torben Mathiasen [EMAIL PROTECTED]
Linux ThunderLAN maintainer
http://tlan.kernel.dk
diff -ur --exclude-from=/root/torben /opt/kernel/kernels/linux/drivers/scsi/sg.c
linux/drivers/scsi/sg.c
--- /opt/kernel/kernels/linux/drivers/scsi/sg.c Thu Sep 21 21:29:44 2000
+++ linux/drivers/scsi/sg.c Thu Sep 21 21:35:46 2000
@@ -1298,18 +1298,18 @@
}
#ifdef MODULE
-
MODULE_PARM(def_reserved_size, "i");
MODULE_PARM_DESC(def_reserved_size, "size of buffer reserved for each fd");
+#endif
-int init_module(void) {
+static int __init init_sg(void) {
if (def_reserved_size = 0)
sg_big_buff = def_reserved_size;
sg_template.module = THIS_MODULE;
return scsi_register_module(MODULE_SCSI_DEV, sg_template);
}
-void cleanup_module( void)
+static void __exit exit_sg( void)
{
#ifdef CONFIG_PROC_FS
sg_proc_cleanup();
@@ -1324,7 +1324,9 @@
}
sg_template.dev_max = 0;
}
-#endif /* MODULE */
+
+module_init(init_sg);
+module_exit(exit_sg);
#if 0
Re: [2.4.0-test9-pre5] SCSI still broken, trident/mixer still broken
Torben Mathiasen wrote:
Ok, small patch cooked up. Not tested, not compiled. Give
it a try, and if it works please send it off to Linus.
I really need to get some work done on a project...
Here is a very similar patch that has been tested
[with a USB zip drive using sg (builtin) to read it].
It worked and the /proc/scsi/sg directory was
properly populated.
Doug Gilbert
--- linux/drivers/scsi/sg.c Thu Sep 21 15:05:28 2000
+++ linux/drivers/scsi/sg.c3117 Thu Sep 21 15:22:08 2000
@@ -17,8 +17,8 @@
* any later version.
*
*/
- static char * sg_version_str = "Version: 3.1.16 (2716)";
- static int sg_version_num = 30116; /* 2 digits for each component */
+ static char * sg_version_str = "Version: 3.1.17 (2921)";
+ static int sg_version_num = 30117; /* 2 digits for each component */
/*
* D. P. Gilbert ([EMAIL PROTECTED], [EMAIL PROTECTED]), notes:
* - scsi logging is available via SCSI_LOG_TIMEOUT macros. First
@@ -1298,18 +1298,20 @@
}
#ifdef MODULE
-
MODULE_PARM(def_reserved_size, "i");
MODULE_PARM_DESC(def_reserved_size, "size of buffer reserved for each fd");
+#endif /* MODULE */
-int init_module(void) {
+int __init init_sg(void) {
+#ifdef MODULE
if (def_reserved_size = 0)
sg_big_buff = def_reserved_size;
+#endif /* MODULE */
sg_template.module = THIS_MODULE;
return scsi_register_module(MODULE_SCSI_DEV, sg_template);
}
-void cleanup_module( void)
+void __exit exit_sg( void)
{
#ifdef CONFIG_PROC_FS
sg_proc_cleanup();
@@ -1324,7 +1326,6 @@
}
sg_template.dev_max = 0;
}
-#endif /* MODULE */
#if 0
@@ -2782,3 +2783,7 @@
return 1;
}
#endif /* CONFIG_PROC_FS */
+
+
+module_init(init_sg);
+module_exit(exit_sg);
Re: [2.4.0-test9-pre5] SCSI still broken, trident/mixer still broken
On Thu, Sep 21, 2000 at 09:39:07PM +0200, Torben Mathiasen wrote:
Ok, small patch cooked up. Not tested, not compiled. Give
it a try, and if it works please send it off to Linus.
I really need to get some work done on a project...
This worked, thanks. :)
Simon-
[ Stormix Technologies Inc. ][ NetNation Communications Inc. ]
[ [EMAIL PROTECTED] ][ [EMAIL PROTECTED]]
[ Opinions expressed are not necessarily those of my employers. ]
diff -ur --exclude-from=/root/torben /opt/kernel/kernels/linux/drivers/scsi/sg.c
linux/drivers/scsi/sg.c
--- /opt/kernel/kernels/linux/drivers/scsi/sg.c Thu Sep 21 21:29:44 2000
+++ linux/drivers/scsi/sg.c Thu Sep 21 21:35:46 2000
@@ -1298,18 +1298,18 @@
}
#ifdef MODULE
-
MODULE_PARM(def_reserved_size, "i");
MODULE_PARM_DESC(def_reserved_size, "size of buffer reserved for each fd");
+#endif
-int init_module(void) {
+static int __init init_sg(void) {
if (def_reserved_size = 0)
sg_big_buff = def_reserved_size;
sg_template.module = THIS_MODULE;
return scsi_register_module(MODULE_SCSI_DEV, sg_template);
}
-void cleanup_module( void)
+static void __exit exit_sg( void)
{
#ifdef CONFIG_PROC_FS
sg_proc_cleanup();
@@ -1324,7 +1324,9 @@
}
sg_template.dev_max = 0;
}
-#endif /* MODULE */
+
+module_init(init_sg);
+module_exit(exit_sg);
#if 0
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4.0-test9-pre5] SCSI still broken, trident/mixer still broken
On Thu, Sep 21 2000, Douglas Gilbert wrote: Torben Mathiasen wrote: Ok, small patch cooked up. Not tested, not compiled. Give it a try, and if it works please send it off to Linus. I really need to get some work done on a project... Here is a very similar patch that has been tested [with a USB zip drive using sg (builtin) to read it]. It worked and the /proc/scsi/sg directory was properly populated. Looks good, but you should make the init functions static. -- Torben Mathiasen [EMAIL PROTECTED] Linux ThunderLAN maintainer http://tlan.kernel.dk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
