Skip to contentSkip to conversation

two sym53c8xx.o modules

DISCUSSION Xose Vazquez Perez 5 participants 10 messages Oct 9, 2003

Subsystems (2)
SCSI LSI Logic/symbios/ncr 53C8XX and 53C1010 PCI-SCSI drivers
lore
Share & tools
lore

Xose Vazquez Perez

author
#0 lore raw

hi,

kernel 2.4 has two modules with *same name*:
/lib/modules/2.4.XX/kernel/drivers/scsi/sym53c8xx_2/sym53c8xx.o /lib/modules/2.4.XX/kernel/drivers/scsi/sym53c8xx.o

"# modprobe sym53c8xx" tries to load sym53c8xx.o first and then sym53c8xx_2/sym53c8xx.o bug or feature?

should be sym53c8xx_2/sym53c8xx.o renamed to sym53c8xx_2/sym53c8xx_2.o ?

                                                                  ^^

-thanks-

#1 lore raw
Quoted 10 lines · Xose Vazquez Perez

hi,

kernel 2.4 has two modules with *same name*:
/lib/modules/2.4.XX/kernel/drivers/scsi/sym53c8xx_2/sym53c8xx.o /lib/modules/2.4.XX/kernel/drivers/scsi/sym53c8xx.o

"# modprobe sym53c8xx" tries to load sym53c8xx.o first and then sym53c8xx_2/sym53c8xx.o bug or feature?

should be sym53c8xx_2/sym53c8xx.o renamed to sym53c8xx_2/sym53c8xx_2.o ?

Xose,

One should not have both drivers loaded at the same time, so I think this is alright.

#2 lore raw
Quoted 5 lines · Marcelo Tosatti
Quoted 4 lines · Xose Vazquez Perez

kernel 2.4 has two modules with *same name*:
/lib/modules/2.4.XX/kernel/drivers/scsi/sym53c8xx_2/sym53c8xx.o /lib/modules/2.4.XX/kernel/drivers/scsi/sym53c8xx.o

Quoted 7 lines
Quoted 4 lines

"# modprobe sym53c8xx" tries to load sym53c8xx.o first and then sym53c8xx_2/sym53c8xx.o bug or feature?

should be sym53c8xx_2/sym53c8xx.o renamed to sym53c8xx_2/sym53c8xx_2.o ?

One should not have both drivers loaded at the same time, so I think this is alright.

No, it's not allright. Modprobe can't distinguish between sym53c8xx_2/sym53c8xx.o and sym53c8xx.o, you have to figure out the full path and insmod one of them manually. Xose is right in that sym53c8xx_2/sym53c8xx.o should be renamed in sym53c8xx_2/sym53c8xx_2.o. Compare with aic7xxx and aic7xxx_old.

Erik

Signature · 3 lines
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
| Data lost? Stay calm and contact Harddisk-recovery.com
#3 lore raw
Quoted 5 lines · Erik Mouw

No, it's not allright. Modprobe can't distinguish between sym53c8xx_2/sym53c8xx.o and sym53c8xx.o, you have to figure out the full path and insmod one of them manually. Xose is right in that sym53c8xx_2/sym53c8xx.o should be renamed in sym53c8xx_2/sym53c8xx_2.o. Compare with aic7xxx and aic7xxx_old.

Is it really important to change this at this stage of 2.4? For reference, sym1 has already gone away in 2.6, so it'll be incovenient for users no matter what you change. Let's stick with the devil we know.

Signature · 3 lines
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk
#4 lore raw
Quoted 3 lines · Matthew Wilcox

Is it really important to change this at this stage of 2.4? For reference, sym1 has already gone away in 2.6, so it'll be incovenient for users no matter what you change. Let's stick with the devil we know.

Yes it is. The _2 driver supports newer hardware (or better: can do faster speeds on newer hardware), while the old driver doesn't. The old driver, however, is more reliable in case of hardware errors. It's very nice to be able to change drivers on the fly without having to figure out the full path to the correct module.

Hmm, just tested the _2 driver and now I remember why I hardly use it with flakey drives:

root@dagobert:~ # scsiinfo -eXR /dev/sda 0 0 0 0 0 0 0 0 0 0 0 0 0 1 <4>sym0:4:0:extraneous data discarded. <4>sym0:4:0:extraneous data discarded. <4>sym0:4:0:extraneous data discarded. <4>sym0:4:0:extraneous data discarded. <4>sym0:4:0:extraneous data discarded.
Unable to store Read-Write Error Recovery Page 01h
18 00 00 00 18 00 00 00 70 00 05 00 00 00 00 18
00 00 00 00 26 00 00 80 02 00 01 0a 00 00 00 00
00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00

I haven't figured out what it could be yet, scsiinfo works perfectly well with the old sym58xxx driver (and the aic7xxx driver, FWIW).

Anyway, here's a patch to rename sym53c8xx_2/sym53c8xx.o to sym53c8xx_2/sym53c8xx_2.o. It's against 2.4.22, but should apply to all 2.4 kernels.

Erik

drivers/scsi/Makefile renamed from drivers/scsi/Makefile.old +1 -1
@@ -97,7 +97,7 @@
 obj-$(CONFIG_SCSI_NCR53C7xx)	+= 53c7,8xx.o 
 subdir-$(CONFIG_SCSI_SYM53C8XX_2)	+= sym53c8xx_2
 ifeq ($(CONFIG_SCSI_SYM53C8XX_2),y)
-  obj-$(CONFIG_SCSI_SYM53C8XX_2)	+= sym53c8xx_2/sym53c8xx.o
+  obj-$(CONFIG_SCSI_SYM53C8XX_2)	+= sym53c8xx_2/sym53c8xx_2.o
 endif
 obj-$(CONFIG_SCSI_SYM53C8XX)	+= sym53c8xx.o 
 obj-$(CONFIG_SCSI_NCR53C8XX)	+= ncr53c8xx.o
drivers/scsi/sym53c8xx_2/Makefile renamed from drivers/scsi/sym53c8xx_2/Makefile.old +6 -6
@@ -1,14 +1,14 @@
-# File: drivers/sym53c8xx/Makefile
+# File: drivers/scsi/sym53c8xx_2/Makefile
 # Makefile for the NCR/SYMBIOS/LSI 53C8XX PCI SCSI controllers driver.
 
-list-multi := sym53c8xx.o
-sym53c8xx-objs := sym_fw.o sym_glue.o sym_hipd.o sym_malloc.o sym_misc.o sym_nvram.o
-obj-$(CONFIG_SCSI_SYM53C8XX_2) := sym53c8xx.o
+list-multi := sym53c8xx_2.o
+sym53c8xx_2-objs := sym_fw.o sym_glue.o sym_hipd.o sym_malloc.o sym_misc.o sym_nvram.o
+obj-$(CONFIG_SCSI_SYM53C8XX_2) := sym53c8xx_2.o
 
 EXTRA_CFLAGS += -I.
 
-sym53c8xx.o: $(sym53c8xx-objs)
-	$(LD) -r -o $@ $(sym53c8xx-objs)
+sym53c8xx_2.o: $(sym53c8xx_2-objs)
+	$(LD) -r -o $@ $(sym53c8xx_2-objs)
 
 include $(TOPDIR)/Rules.make
Signature · 4 lines
+-- Erik Mouw -- www.harddisk-recovery.nl -- 0800 220 20 20 --
| Eigen lab: Delftechpark 26, 2628 XH, Delft, Nederland
| Files foetsie, bestanden kwijt, alle data weg?!
| Blijf kalm en neem contact op met Harddisk-recovery.nl!
#5 lore raw
Quoted 10 lines · Erik Mouw
Quoted 3 lines · Matthew Wilcox

Is it really important to change this at this stage of 2.4? For reference, sym1 has already gone away in 2.6, so it'll be incovenient for users no matter what you change. Let's stick with the devil we know.

Yes it is. The _2 driver supports newer hardware (or better: can do faster speeds on newer hardware), while the old driver doesn't. The old driver, however, is more reliable in case of hardware errors. It's very nice to be able to change drivers on the fly without having to figure out the full path to the correct module.

No, that's not the point. For people who are already using either driver, there's no need to change anything between 2.4 and 2.6. It's only the foolish people who compile both as modules that have a problem.

If you change the sym2 driver to have a different module name, now people have to change when they switch between 2.4 and 2.6. That's bad.

We've had this problem all through 2.4 and it's never been an issue until now. I really think this is one problem which shouldn't be fixed.

Quoted 14 lines

Hmm, just tested the _2 driver and now I remember why I hardly use it with flakey drives:

root@dagobert:~ # scsiinfo -eXR /dev/sda 0 0 0 0 0 0 0 0 0 0 0 0 0 1 <4>sym0:4:0:extraneous data discarded. <4>sym0:4:0:extraneous data discarded. <4>sym0:4:0:extraneous data discarded. <4>sym0:4:0:extraneous data discarded. <4>sym0:4:0:extraneous data discarded.
Unable to store Read-Write Error Recovery Page 01h
18 00 00 00 18 00 00 00 70 00 05 00 00 00 00 18
00 00 00 00 26 00 00 80 02 00 01 0a 00 00 00 00
00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00

Quoted 2 lines

I haven't figured out what it could be yet, scsiinfo works perfectly well with the old sym58xxx driver (and the aic7xxx driver, FWIW).

It works perfectly fine with the drives I have access to under 2.6 ...

Quoted 3 lines

Anyway, here's a patch to rename sym53c8xx_2/sym53c8xx.o to sym53c8xx_2/sym53c8xx_2.o. It's against 2.4.22, but should apply to all 2.4 kernels.

Please don't apply this patch.

Signature · 3 lines
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk
#6 lore raw
Quoted 10 lines · Matthew Wilcox
Quoted 5 lines · Erik Mouw

Yes it is. The _2 driver supports newer hardware (or better: can do faster speeds on newer hardware), while the old driver doesn't. The old driver, however, is more reliable in case of hardware errors. It's very nice to be able to change drivers on the fly without having to figure out the full path to the correct module.

No, that's not the point. For people who are already using either driver, there's no need to change anything between 2.4 and 2.6. It's only the foolish people who compile both as modules that have a problem.

It's not foolish to compile both modules. The 53c895 works faster with the sym538cxxx_2 driver, the 53c810 can do with the sym53cxxx driver. For otherwise the same machines, it's nice to compile a single kernel for all of them and have the sym58cxxx drivers as modules, so you can specify in modules.conf which driver to use. (also think about fully modular distribution kernels).

Quoted 2 lines

If you change the sym2 driver to have a different module name, now people have to change when they switch between 2.4 and 2.6. That's bad.

Upgrading major kernel versions usually breaks things. That has never been a problem in the past, so I don't see why it should be one in this particular case. There were other modules with completely different names, like usb-uhci --> uhci-hcd.

Quoted 2 lines

We've had this problem all through 2.4 and it's never been an issue until now. I really think this is one problem which shouldn't be fixed.

It hasn't been an issue until now simply because nobody has actually seen it going wrong. If you load sym53cxxx, you get the old driver, and hey, it works well with all sym53cxxx SCSI cards. The old driver simply masks the new driver and I think the new driver didn't get as much real-life testing as it should have had.

Selecting everything as a module never was a problem in Linux, you can load any driver just by name. The sym53cxxx is an exception to this:
the old driver masks the new one. It's a namespace collision. That's bad and it should be fixed.

Quoted 4 lines
Quoted 2 lines

I haven't figured out what it could be yet, scsiinfo works perfectly well with the old sym58xxx driver (and the aic7xxx driver, FWIW).

It works perfectly fine with the drives I have access to under 2.6 ...

I know (I think you even told me). The fact that I only recently figured out about this bug proves my point: in linux-2.4 the sym53cxx_2 driver didn't get as much testing as it should have had. Apply my patch, and the driver might even get real use.

Erik

Signature · 3 lines
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
| Data lost? Stay calm and contact Harddisk-recovery.com
author
#7 lore raw
Quoted 4 lines · Erik Mouw

I know (I think you even told me). The fact that I only recently figured out about this bug proves my point: in linux-2.4 the sym53cxx_2 driver didn't get as much testing as it should have had. Apply my patch, and the driver might even get real use.

What's best approach ? to replace sym53c8xx_2/sym53c8xx.o with sym53c8xx_2/sym53c8xx_2.o or sym53c8xx.o with sym53c8xx_old.o

:-?

#8 lore raw
In reply to Erik Mouw
Quoted 11 lines · Erik Mouw
Quoted 10 lines · Marcelo Tosatti
Quoted 8 lines · Xose Vazquez Perez

kernel 2.4 has two modules with *same name*:
/lib/modules/2.4.XX/kernel/drivers/scsi/sym53c8xx_2/sym53c8xx.o /lib/modules/2.4.XX/kernel/drivers/scsi/sym53c8xx.o

"# modprobe sym53c8xx" tries to load sym53c8xx.o first and then sym53c8xx_2/sym53c8xx.o bug or feature?

should be sym53c8xx_2/sym53c8xx.o renamed to sym53c8xx_2/sym53c8xx_2.o ?

Quoted 8 lines
Quoted 2 lines

One should not have both drivers loaded at the same time, so I think this is alright.

No, it's not allright. Modprobe can't distinguish between sym53c8xx_2/sym53c8xx.o and sym53c8xx.o, you have to figure out the full path and insmod one of them manually. Xose is right in that sym53c8xx_2/sym53c8xx.o should be renamed in sym53c8xx_2/sym53c8xx_2.o. Compare with aic7xxx and aic7xxx_old.

True. Mind sending me a patch?