[PATCH] New updated devices.txt - LANANA
Here's the updated version with additonal spelling fixes. Please use this one instead of the one that was sent 2 days ago. Thanks, Torben --- linux-2.6.19-rc6/Documentation/devices.txt 2006-11-16 05:03:40.0 +0100 +++ linux-2.6.19-rc6new/Documentation/devices.txt 2006-12-01 11:04:28.0 +0100 @@ -3,7 +3,7 @@ Maintained by Torben Mathiasen <[EMAIL PROTECTED]> - Last revised: 15 May 2006 + Last revised: 29 November 2006 This list is the Linux Device List, the official registry of allocated device numbers and /dev directory nodes for the Linux operating @@ -92,7 +92,7 @@ Your cooperation is appreciated. 7 = /dev/full Returns ENOSPC on write 8 = /dev/random Nondeterministic random number gen. 9 = /dev/urandom Faster, less secure random number gen. -10 = /dev/aio Asyncronous I/O notification interface +10 = /dev/aio Asynchronous I/O notification interface 11 = /dev/kmsg Writes to this come out as printk's 1 block RAM disk 0 = /dev/ram0 First RAM disk @@ -122,7 +122,7 @@ Your cooperation is appreciated. devices are on major 128 and above and use the PTY master multiplex (/dev/ptmx) to acquire a PTY on demand. - + 2 block Floppy disks 0 = /dev/fd0 Controller 0, drive 0, autodetect 1 = /dev/fd1 Controller 0, drive 1, autodetect @@ -257,7 +257,7 @@ Your cooperation is appreciated. 129 = /dev/vcsa1tty1 text/attribute contents ... 191 = /dev/vcsa63 tty63 text/attribute contents - + NOTE: These devices permit both read and write access. 7 block Loopback devices @@ -411,7 +411,7 @@ Your cooperation is appreciated. 207 = /dev/video/em8300_sp EM8300 DVD decoder subpicture 208 = /dev/compaq/cpqphpc Compaq PCI Hot Plug Controller 209 = /dev/compaq/cpqridCompaq Remote Insight Driver - 210 = /dev/impi/bt IMPI coprocessor block transfer + 210 = /dev/impi/bt IMPI coprocessor block transfer 211 = /dev/impi/smicIMPI coprocessor stream interface 212 = /dev/watchdogs/0 First watchdog device 213 = /dev/watchdogs/1 Second watchdog device @@ -582,7 +582,7 @@ Your cooperation is appreciated. This device is used on the ARM-based Acorn RiscPC. Partitions are handled the same way as for IDE disks - (see major number 3). + (see major number 3). 22 char Digiboard serial card 0 = /dev/ttyD0First Digiboard port @@ -591,7 +591,7 @@ Your cooperation is appreciated. 22 block Second IDE hard disk/CD-ROM interface 0 = /dev/hdc Master: whole disk (or CD-ROM) 64 = /dev/hdd Slave: whole disk (or CD-ROM) - + Partitions are handled the same way as for the first interface (see major number 3). @@ -801,7 +801,7 @@ Your cooperation is appreciated. 34 block Fourth IDE hard disk/CD-ROM interface 0 = /dev/hdg Master: whole disk (or CD-ROM) 64 = /dev/hdh Slave: whole disk (or CD-ROM) - + Partitions are handled the same way as for the first interface (see major number 3). @@ -939,7 +939,7 @@ Your cooperation is appreciated. 16 = /dev/ftlb FTL on second Memory Technology Device 32 = /dev/ftlc FTL on third Memory Technology Device ... - 240 = /dev/ftlp FTL on 16th Memory Technology Device + 240 = /dev/ftlp FTL on 16th Memory Technology Device Partitions are handled in the same way as for IDE disks (see major number 3) except that the partition @@ -1093,7 +1093,7 @@ Your cooperation is appreciated. 55 char DSP56001 digital signal processor 0 = /dev/dsp56k First DSP56001 - 55 block Mylex DAC960 PCI RAID controller; eigth controller + 55 block Mylex DAC960 PCI RAID controller; eighth controller 0 = /dev/rd/c7d0 First disk, whole disk 8 = /dev/rd/c7d1 Second disk, whole disk ... @@ -1456,7 +1456,7 @@ Your cooperation is appreciated. 1 = /dev/cum1 Callout device for ttyM1 ... - 79 block Compaq Intelligent Drive Array, eigth controller + 79 block Compaq Intelligent Drive Array, eighth controller
[PATCH] devices.txt - LANANA merge
Here's a merge with the latest from LANANA. Its been a while, so _please_ let me know if anyone sees unwanted changes. A few whitespaces and formatting changes included too. Thanks, Torben --- linux-2.6.19-rc6/Documentation/devices.txt 2006-11-16 05:03:40.0 +0100 +++ linux-2.6.19-rc6new/Documentation/devices.txt 2006-11-29 10:43:41.0 +0100 @@ -3,7 +3,7 @@ Maintained by Torben Mathiasen <[EMAIL PROTECTED]> - Last revised: 15 May 2006 + Last revised: 27 October 2006 This list is the Linux Device List, the official registry of allocated device numbers and /dev directory nodes for the Linux operating @@ -122,7 +122,7 @@ devices are on major 128 and above and use the PTY master multiplex (/dev/ptmx) to acquire a PTY on demand. - + 2 block Floppy disks 0 = /dev/fd0 Controller 0, drive 0, autodetect 1 = /dev/fd1 Controller 0, drive 1, autodetect @@ -257,7 +257,7 @@ 129 = /dev/vcsa1tty1 text/attribute contents ... 191 = /dev/vcsa63 tty63 text/attribute contents - + NOTE: These devices permit both read and write access. 7 block Loopback devices @@ -411,7 +411,7 @@ 207 = /dev/video/em8300_sp EM8300 DVD decoder subpicture 208 = /dev/compaq/cpqphpc Compaq PCI Hot Plug Controller 209 = /dev/compaq/cpqridCompaq Remote Insight Driver - 210 = /dev/impi/bt IMPI coprocessor block transfer + 210 = /dev/impi/bt IMPI coprocessor block transfer 211 = /dev/impi/smicIMPI coprocessor stream interface 212 = /dev/watchdogs/0 First watchdog device 213 = /dev/watchdogs/1 Second watchdog device @@ -582,7 +582,7 @@ This device is used on the ARM-based Acorn RiscPC. Partitions are handled the same way as for IDE disks - (see major number 3). + (see major number 3). 22 char Digiboard serial card 0 = /dev/ttyD0First Digiboard port @@ -591,7 +591,7 @@ 22 block Second IDE hard disk/CD-ROM interface 0 = /dev/hdc Master: whole disk (or CD-ROM) 64 = /dev/hdd Slave: whole disk (or CD-ROM) - + Partitions are handled the same way as for the first interface (see major number 3). @@ -801,7 +801,7 @@ 34 block Fourth IDE hard disk/CD-ROM interface 0 = /dev/hdg Master: whole disk (or CD-ROM) 64 = /dev/hdh Slave: whole disk (or CD-ROM) - + Partitions are handled the same way as for the first interface (see major number 3). @@ -939,7 +939,7 @@ 16 = /dev/ftlb FTL on second Memory Technology Device 32 = /dev/ftlc FTL on third Memory Technology Device ... - 240 = /dev/ftlp FTL on 16th Memory Technology Device + 240 = /dev/ftlp FTL on 16th Memory Technology Device Partitions are handled in the same way as for IDE disks (see major number 3) except that the partition @@ -1695,7 +1695,7 @@ 1 = /dev/ipnatNAT control device/log file 2 = /dev/ipstate State information log file 3 = /dev/ipauth Authentication control device/log file - ... + ... 96 char Parallel port ATAPI tape devices 0 = /dev/pt0 First parallel port ATAPI tape @@ -2427,7 +2427,7 @@ Partitions are handled in the same way as for IDE disks (see major number 3) except that the limit on - partitions is 31. + partitions is 31. 162 char Raw block device interface 0 = /dev/rawctl Raw I/O control device @@ -2543,9 +2543,6 @@ 64 = /dev/usb/rio500 Diamond Rio 500 65 = /dev/usb/usblcd USBLCD Interface ([EMAIL PROTECTED]) 66 = /dev/usb/cpad0Synaptics cPad (mouse/LCD) -67 = /dev/usb/adutux0 1st Ontrak ADU device - ... -76 = /dev/usb/adutux10 10th Ontrak ADU device 96 = /dev/usb/hiddev0 1st USB HID device ... 111 = /dev/usb/hiddev15 16th USB HID device @@ -2571,7 +2568,7 @@ 0 = /dev/uba First USB block device 8 = /dev/ubb Second USB block device 16 = /dev/ubc Third USB b
Re: [PATCH] Devices.txt, update with LANANA
On Thu, Feb 03 2005, Greg KH wrote: > Hm, this is just wrong. As I recall, LANANA is in charge of the major > numbers, but for the USB major, the USB developers have been assigning > the USB minors. This patch just made the file different from what is > currently present in the kernel. > > Should I just submit a patch to LANANA to update the USB minors for > their copy so this doesn't happen again? > Yes please!. Since the devices file at lanana.org is the one being merged into the one in the kernel tree, please send future updates to lanana and it'll go in that way. Thanks, Torben - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.1-ac7
On Thu, Feb 08 2001, Rik van Riel wrote: > On Thu, 8 Feb 2001, Alan Cox wrote: > > > ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ > > > > 2.4.1-ac7 > > o Rebalance the 2.4.1 VM (Rik van Riel) > > | This should make things feel a lot faster especially > > | on small boxes .. feedback to Rik > > I'd really like feedback from people when it comes to this > change. The change /should/ fix most paging performance bugs > because it makes kswapd do the right amount of work in order > to solve the free memory shortage every time it is run. Rik, Just installed ac7 and after some 30 minutes of unpacking kernel-sources and diffing patches, I left my computer unattended for about 1 hour. When I came back the system was unusable (like it was frozen), and /var/log/messages just displayed messages of the type: Feb 8 22:54:40 fry kernel: Out of Memory: Killed process 455 (xmms). ... The OOM killer killed most of my apps, and finally X. I had to reboot in order to get the system back. I've been running ac1-ac6 since they came out with no problems, so I guess its the VM hack that is buggy. This is on an AMD K7 1200Mhz, 512MB Ram, ATA100. Nothing big was running at the time (xchat, xmms, mozilla, gnome, x, a few xterms). I'll do some more testing tomorrow and provide any further information you might need. -- Torben Mathiasen <[EMAIL PROTECTED]> Linux ThunderLAN maintainer http://opensource.compaq.com - 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/
[PATCH] Acorn SCSI loading
Hi, Just noticed the SCSI drivers for the ACORN bus weren't updated to the new initialization. AFAIK these drivers couldn't have been functional without this patch. Patch is against 2.4.1 -- Torben Mathiasen <[EMAIL PROTECTED]> Linux ThunderLAN maintainer http://opensource.compaq.com diff -ur /opt/kernel/kernels/linux/drivers/acorn/scsi/acornscsi.c linux/drivers/acorn/scsi/acornscsi.c --- /opt/kernel/kernels/linux/drivers/acorn/scsi/acornscsi.cTue Sep 19 00:15:22 2000 +++ linux/drivers/acorn/scsi/acornscsi.cTue Jan 30 22:18:50 2001 @@ -3118,9 +3118,7 @@ return pos; } -#ifdef MODULE Scsi_Host_Template driver_template = ACORNSCSI_3; #include "../../scsi/scsi_module.c" -#endif diff -ur /opt/kernel/kernels/linux/drivers/acorn/scsi/arxescsi.c linux/drivers/acorn/scsi/arxescsi.c --- /opt/kernel/kernels/linux/drivers/acorn/scsi/arxescsi.c Tue Sep 19 00:15:22 2000 +++ linux/drivers/acorn/scsi/arxescsi.c Tue Jan 30 22:19:06 2001 @@ -416,8 +416,6 @@ return pos; } -#ifdef MODULE Scsi_Host_Template driver_template = ARXEScsi; #include "../../scsi/scsi_module.c" -#endif diff -ur /opt/kernel/kernels/linux/drivers/acorn/scsi/cumana_1.c linux/drivers/acorn/scsi/cumana_1.c --- /opt/kernel/kernels/linux/drivers/acorn/scsi/cumana_1.c Fri Nov 12 01:57:30 1999 +++ linux/drivers/acorn/scsi/cumana_1.c Tue Jan 30 22:19:29 2001 @@ -359,9 +359,7 @@ #include "../../scsi/NCR5380.c" -#ifdef MODULE Scsi_Host_Template driver_template = CUMANA_NCR5380; #include "../../scsi/scsi_module.c" -#endif diff -ur /opt/kernel/kernels/linux/drivers/acorn/scsi/cumana_2.c linux/drivers/acorn/scsi/cumana_2.c --- /opt/kernel/kernels/linux/drivers/acorn/scsi/cumana_2.c Tue Sep 19 00:15:22 2000 +++ linux/drivers/acorn/scsi/cumana_2.c Tue Jan 30 22:19:41 2001 @@ -541,8 +541,6 @@ return pos; } -#ifdef MODULE Scsi_Host_Template driver_template = CUMANASCSI_2; #include "../../scsi/scsi_module.c" -#endif diff -ur /opt/kernel/kernels/linux/drivers/acorn/scsi/ecoscsi.c linux/drivers/acorn/scsi/ecoscsi.c --- /opt/kernel/kernels/linux/drivers/acorn/scsi/ecoscsi.c Fri Nov 12 01:57:30 1999 +++ linux/drivers/acorn/scsi/ecoscsi.c Tue Jan 30 22:19:56 2001 @@ -233,9 +233,7 @@ #include "../../scsi/NCR5380.c" -#ifdef MODULE Scsi_Host_Template driver_template = ECOSCSI_NCR5380; #include "../../scsi/scsi_module.c" -#endif diff -ur /opt/kernel/kernels/linux/drivers/acorn/scsi/eesox.c linux/drivers/acorn/scsi/eesox.c --- /opt/kernel/kernels/linux/drivers/acorn/scsi/eesox.cTue Sep 19 00:15:22 2000 +++ linux/drivers/acorn/scsi/eesox.cTue Jan 30 22:20:09 2001 @@ -543,8 +543,6 @@ return pos; } -#ifdef MODULE Scsi_Host_Template driver_template = EESOXSCSI; #include "../../scsi/scsi_module.c" -#endif diff -ur /opt/kernel/kernels/linux/drivers/acorn/scsi/oak.c linux/drivers/acorn/scsi/oak.c --- /opt/kernel/kernels/linux/drivers/acorn/scsi/oak.c Fri Nov 12 01:57:30 1999 +++ linux/drivers/acorn/scsi/oak.c Tue Jan 30 22:20:51 2001 @@ -226,9 +226,7 @@ #include "../../scsi/NCR5380.c" -#ifdef MODULE Scsi_Host_Template driver_template = OAK_NCR5380; #include "../../scsi/scsi_module.c" -#endif diff -ur /opt/kernel/kernels/linux/drivers/acorn/scsi/powertec.c linux/drivers/acorn/scsi/powertec.c --- /opt/kernel/kernels/linux/drivers/acorn/scsi/powertec.c Tue Sep 19 00:15:22 2000 +++ linux/drivers/acorn/scsi/powertec.c Tue Jan 30 22:21:00 2001 @@ -445,8 +445,6 @@ return pos; } -#ifdef MODULE Scsi_Host_Template driver_template = POWERTECSCSI; #include "../../scsi/scsi_module.c" -#endif
Re: eepro100 problems in 2.4.0
On Friday, 26 January 2001, [EMAIL PROTECTED] wrote: > Hi, > > On Thu, Jan 25, 2001 at 04:19:27PM -0500, Jeff Garzik wrote: > > Oops, sorry guys. Thanks to DaveM for correcting me -- my patch has > > nothing to do with the "card reports no resources" problem. My > > apologies. > > No problems. > > However, there is a real problem with eepro100 when the system resumes > operations after a sleep. > May be, you could guess what's wrong in this case? > I had to add this small patch to make it work properly with my Armada M700. It basiclly just does something similar to what happens when we get TX timeouts. Its just a quick hack, as I got tired of the eepro100 driver dumping the tx/rx queues when resuming. Regards, Torben Mathiasen
Re: [PATCH][RFC] Converting drivers/net/rcpci45.c to new PCI API
On Tue, Dec 19 2000, Rasmus Andersen wrote: > On Tue, Dec 19, 2000 at 10:05:30PM +0100, Torben Mathiasen wrote: > > > > You should release the irq when the adapter is closed, not removed, > > unless there's some special case that can't be handled if you take > > ints during init. > > You seem to be right. I have moved the free_irq to the close function. > This driver seems a bit odd. It also request irq's durint init instead of device open. Normally one would request any resource as late as possible (to prevent the driver from using resources when it is not even used). It makes one wonder if this driver has just not been updated in a while, or if it does things for a reason. -- 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: [PATCH][RFC] Converting drivers/net/rcpci45.c to new PCI API
On Tue, Dec 19 2000, Francois Romieu wrote: [deleted] > > - if (pci_enable_device(pdev)) > > - break; > > - pci_set_master(pdev); > > + unregister_netdev(dev); > > + iounmap((void *)dev->base_addr); > > +free_irq(dev->irq, dev); > > I'd rather inhibit irq first then release the ressources. > + free_irq(dev->irq, dev); > + iounmap((void *)dev->base_addr); > + unregister_netdev(dev); > You should release the irq when the adapter is closed, not removed, unless there's some special case that can't be handled if you take ints during init. And why would you unregister your netdev after releasing resources? -- 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: SCSI modules and kmod
On Thu, Dec 07 2000, [EMAIL PROTECTED] wrote:
[deleted]
> int regdevresult;
>
> case MODULE_SCSI_DEV:
> #ifdef CONFIG_KMOD
> if (scsi_hosts == NULL)
> {
> request_module("scsi_hostadapter");
> return scsi_register_device_module((struct
> Scsi_Device_Template *) ptr);
> }
> #endif
> regdevresult = scsi_register_device_module((struct
> Scsi_Device_Template *) ptr);
> #ifdef CONFIG_KMOD
> if (regdevresult != 0) /* is this the right case? */
> request_module("scsi_hostadapter");
> regdevresult = scsi_register_device_module((struct
> Scsi_Device_Template *) ptr);
> #endif
> return regdevresult;
>
This won't work. scsi_register_device_module returns 0 when the
driver loads ok, not when a device was actually found. Remember
its possible to load the sd driver with no host adapter present.
How about just removing the check for scsi_hosts == NULL. If some
hostadapter was already loaded, so be it. It won't change anything,
besides maybe more devices beeing loaded which shouldn't hurt anyone.
Small patch attached (against t12p7). Not tested, not even compiled.
--
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer
http://tlan.kernel.dk
--- /opt/kernel/kernels/linux/drivers/scsi/scsi.c Wed Nov 1 15:04:02 2000
+++ linux/drivers/scsi/scsi.c Fri Dec 8 02:13:47 2000
@@ -2322,11 +2322,9 @@
/* Load upper level device handler of some kind */
case MODULE_SCSI_DEV:
#ifdef CONFIG_KMOD
- if (scsi_hosts == NULL)
- request_module("scsi_hostadapter");
+ request_module("scsi_hostadapter");
#endif
- return scsi_register_device_module((struct Scsi_Device_Template *)
ptr);
- /* The rest of these are not yet implemented */
+ return scsi_register_device_module((struct Scsi_Device_Template *) ptr);
/* Load constants.o */
case MODULE_SCSI_CONST:
Re: SCSI Oops (was test12-pre4)
On Mon, Dec 04 2000, Borislav Deianov wrote: > (cross-posted to linux-kernel and linux-scsi) > > Hi, > > The SCSI oops I reported last week is still present in test12-pre4. > This is on a Dell PowerEdge 6300. It has two Adaptec AIC-7890, one > Adaptec AIC-7860, and an AMI MegaRAID controller. There's nothing on > the 7890s, a CDROM and a tape drive on the 7890. > > With all of the above enabled the kernel boots with no problems. > However, if I disable the two 7890s from the BIOS (to save 30 seconds > of boot time), I get an oops. > > The decoded oops is below. Please email me directly for further > information. > Could you find out exactly when this broke? -- 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: scsi init problem in 2.4.0-test10?
The SCSI spec says that INQUIRY and not TUR + INQUIRY is the way to go, but maybe we should make it a compile time option for buggy drives. On Thu, Nov 02 2000, Elizabeth Morris-Baker wrote: > > > > You need to send the TUR first, but yes, > START_STOP will guarantee that you are > ready to rock and roll. > The first fix I wrote did a TUR, then > 3 tries at a START_STOP, till it worked. > > cheers, > > Elizabeth > [deleted] -- 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: [PATCH] Fix SCSI proc oops
On Sun, Oct 15 2000, David S. Miller wrote: >Date: Sun, 15 Oct 2000 11:19:24 +0200 >From: Torben Mathiasen <[EMAIL PROTECTED]> > >It seems reasonable. We'd been thinking of makeing proc_name part >of the host structure, but no need for that if we just do the >above. > > Either fix is ok by me, but it does seem that enforcing proc_name > initialization might be the better fix long term. Agreed, it'll clean it up also. Lets make both. If Linus moves the remove_proc_entry people will stop oopsing, and I'll have some time to test the proc_name changes. -- 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: [PATCH] Fix SCSI proc oops
On Sat, Oct 14 2000, Linus Torvalds wrote: > > > On Sat, 14 Oct 2000, David S. Miller wrote: > > > > The loop would be a no-op but the remove_proc_entry call would not. > > Perhaps you didn't notice that there too? It's pretty close to the > > loop :-) > > Ok. > > In fact, it's in the _wrong_ part. > > That remove_proc_entry() should be there in the same place where we remove > the entry in teh list, wouldn't you say? Makes tons more sense that way, > doesn't crash, and is understandable. > It seems reasonable. We'd been thinking of makeing proc_name part of the host structure, but no need for that if we just do the above. -- 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: Hudge collection of Oops ;-)
On Sat, Oct 14 2000, Gregoire Favre wrote: > Hello, > > I have put configuration files (in acsii and in bz2) on: > http://ulima.unil.ch/greg/linux/ > > Briefly, there are /var/log/messages System-map from test8 and test9 > and the conf files I used to compile my kernels, and finally one dmesg. > > What I use non standard are: Reiserfs, DVB, BTTV and lirc (Hauppauge). > (and EMU10K1,aic7xxx). > > Anyone got an idea on the reason of the Oopses? > It would be much easier if you could try to narrow down exacly what breaks. If these opps's are reproduceable, please try removing some of your drivers. SCSI had an overhaul lately, so it seem like a good place to start. -- 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: [PATCH] Fix SCSI proc oops
On Sat, Oct 14 2000, David S. Miller wrote: >Date: Sat, 14 Oct 2000 12:12:39 +0200 >From: Torben Mathiasen <[EMAIL PROTECTED]> > >Are there any reason why sym53c8xx and others initialize proc_name >only if an adapter was actually found (or in the sym case, if a >pcibus was found)? > > I see no particular reason. Why not code up the patch to fix all > these cases so we can find out? :-) I would recommend putting them all > into the host structure for that driver, unless there is some weird > reason the driver absolutely must generate the string at run time. > Yeah, lets find out. I'll cook it up. Linus, What do you think. Something you would accept for 2.4? -- 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: [PATCH] Fix SCSI proc oops
On Sat, Oct 14 2000, David S. Miller wrote:
>Date: Sat, 14 Oct 2000 11:43:09 +0200
>From: Torben Mathiasen <[EMAIL PROTECTED]>
>
>David, why is tpnt->proc_name NULL on sparc for devices not
>existing? Every driver has this as part of their tpnt struct, so
>it doesn't matter if the underlying device really exists.
>
> In the mentioned case it would be NULL on all architectures, not just
> Sparc ;-) (it happens on ix86 too, ix86 is different only because it
> does not trap kernel NULL pointer derefences during bootup for some
> odd reason)
>
> Here is what happens:
>
> scsi_register_host()
> tpnt->present = tpnt->detect(tpnt);
> /* tpnt->present is zero since no such adapters were found */
>
> If no hosts are detected the driver is under no obligation to
> initialize the tpnt->proc_name field. For example,
> sym53c8xx.c:sym53c8xx_detect() does not if PCI is not present and this
> is the specific case hit on my SBUS-only workstation :-)
>
> Subsequently scsi_unregister_host() is called for this TPNT and
> this is where the NULL pointer is hit.
>
Ahh, the drivers I looked at all had proc_name as part of their:
define IN2000 {
bla:bla,
proc_name: IN2000,
}
structure. I see your point now.
Are there any reason why sym53c8xx and others initialize proc_name only
if an adapter was actually found (or in the sym case, if a pcibus was
found)?
--
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: [PATCH] Fix SCSI proc oops
On Sat, Oct 14 2000, David S. Miller wrote: >Date: Fri, 13 Oct 2000 20:37:46 -0700 (PDT) >From: Linus Torvalds <[EMAIL PROTECTED]> > >Why would it crash the sparc? > >If it wasn't there originally, the loop will not find it, and the >loop will be a no-op. > > The loop would be a no-op but the remove_proc_entry call would not. > Perhaps you didn't notice that there too? It's pretty close to the > loop :-) > > tpnt->proc_name in this case is NULL, that is fed to the procfs > unregister code (and next to strncmp), leading to an OOPS on non-x86 > during bootup with scsi adapter drivers not in the machine compiled > statically into the kernel. > David, why is tpnt->proc_name NULL on sparc for devices not existing? Every driver has this as part of their tpnt struct, so it doesn't matter if the underlying device really exists. -- 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: [PATCH] Fix SCSI proc oops
On Thu, Oct 12 2000, Linus Torvalds wrote: > > > On Thu, 12 Oct 2000, Torben Mathiasen wrote: > > > > Attached patch should fix the oops's people have been getting > > while using /proc/scsi. > > This patch makes no sense. Why > > if (!present) > > when that is obviously the wrong way around. > We want to make sure that all hostadapters have been unregistered befor we pull it out of the scsi_hosts list. We do tpnt->present-- for every hostadaper we unregister. Prior to the new init code, we'd just do something like, if (tpnt->present) return; I might be wrong though, it could be another bug that I've missed. -- 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/
[PATCH] Fix SCSI proc oops
Linus,
Attached patch should fix the oops's people have been getting
while using /proc/scsi.
Patch is against test10p1.
--
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer
http://tlan.kernel.dk
--- linux-test10p1/drivers/scsi/scsi.c Thu Oct 12 20:18:47 2000
+++ linux/drivers/scsi/scsi.c Thu Oct 12 21:03:39 2000
@@ -36,8 +36,8 @@
* out_of_space hacks, D. Gilbert (dpg) 990608
*/
-#define REVISION "Revision: 1.00"
-#define VERSION"Id: scsi.c 1.00 2000/09/26"
+#define REVISION "Revision: 1.01"
+#define VERSION"Id: scsi.c 1.01 2000/10/12"
#include
#include
@@ -2156,7 +2156,7 @@
#endif
/* Remove it from the linked list and /proc */
- if (tpnt->present) {
+ if (!tpnt->present) {
Scsi_Host_Template **SHTp = &scsi_hosts;
Scsi_Host_Template *SHT;
@@ -2169,8 +2169,9 @@
}
/* Rebuild the /proc/scsi directory entries */
remove_proc_entry(tpnt->proc_name, proc_scsi);
+ MOD_DEC_USE_COUNT;
+
}
- MOD_DEC_USE_COUNT;
}
static int scsi_unregister_device(struct Scsi_Device_Template *tpnt);
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
On Thu, Oct 12 2000, [EMAIL PROTECTED] wrote: > 8. Fix Exists But Isnt Merged > * TLAN nic appears to be adding a timer twice (2.4.0test8pre6, Arjan >ve de Ven) (Fixed, but patch not sent to Linus yet -- Torben > Mathiasen) > * Loading the qlogicfc driver in 2.4.0-test8 causes the kernel to >loop forver reporting SCSI disks that aren't present (Paul > Hubbard, Torben Mathiasen has a potential patch, sent to Linus, >need to very with Paul) These two have been merged. -- 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: [PATCH] Link order of drivers outside drivers/scsi
On Mon, Oct 09 2000, Alan Cox wrote: > > > You have to do Buslogic and AHA17xx before AHA15xx or you get a wrong driver > > > and in the 17xx case data corruption risks > > > > Hmm.. The current order is the same as in 2.2.x, and puts aha17xx _after_ > > the other ones. Or did that change in the later 2.2.x series? > > I will double check that with Eric Youngdale. It may be the driver in the 1542 > code was changed to detect a 17xx and leave it alone at some point in 2.0 > days. The buslogic one the comments still claim is needed > > > > You must do scsi before i2o_scsi or AMI Megaraids break > > > > So change the drivers/Makefile to put scsi before i2o and > > drivers/scsi/Makefile to do the aha17xx thing first, and we're all done. > > Yep. > Okay I might be too tired to see this now, but AFAIK i2o does link after scsi in test9. We need however to remove the #ifdef MODULE around "#include scsi_module.c" in i2o_scsi.c and everything should be set. -- 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: [PATCH] Link order of drivers outside drivers/scsi
On Mon, Oct 09 2000, Alan Cox wrote: > > Yes, that can be done pretty easy, but Then I2O will link > > > > core - hosts - upper - I2O and I'm not sure this is okay. > > Thats fine. I2O scsi is the last scsi driver anyway, the rest of i2o registers > devices on different majors with no ordering issues > Excellent. But Alan, you wrote earlier that i2o needed to be the last host adapter and _before_ the upper layers. This is what made me start this patch. -- 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: [PATCH] Link order of drivers outside drivers/scsi
On Mon, Oct 09 2000, Linus Torvalds wrote: > > > On Mon, 9 Oct 2000, Torben Mathiasen wrote: > > > > My point exactly. The ordering of driver in drivers/scsi is done now, > > but I don't see a clean way of doing I2O without moving upperlayers > > into a seperate dir. > > Why? > I was referring to Alan's statement about i2o should be the last lowlevel driver before the upper layers. I'm not familar with the i2o code, just thought there was a reason. -- 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: [PATCH] Link order of drivers outside drivers/scsi
On Mon, Oct 09 2000, Linus Torvalds wrote: > > > On Mon, 9 Oct 2000, Alan Cox wrote: > > > > Link scsi as a whole before i2o ? > > Yup. > > Also, we should really finalise the host order thing in scsi/Makefile. If > it's true that aha17xx must come before aha1542, it's wrong as it stands > now. Any other gotchas that were caught in 2.2.x? > Okay. I'll wait a few hours for additional host adapter information, and then send a patch with the i2o stuff included. -- 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: [PATCH] Link order of drivers outside drivers/scsi
On Mon, Oct 09 2000, Alan Cox wrote: > > > You have to do Buslogic and AHA17xx before AHA15xx or you get a wrong driver > > > and in the 17xx case data corruption risks > > > You must do scsi before i2o_scsi or AMI Megaraids break > > > > > > > My point exactly. The ordering of driver in drivers/scsi is done now, > > but I don't see a clean way of doing I2O without moving upperlayers > > into a seperate dir. > > Link scsi as a whole before i2o ? > Yes, that can be done pretty easy, but Then I2O will link core - hosts - upper - I2O and I'm not sure this is okay. -- 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: [PATCH] Link order of drivers outside drivers/scsi
On Mon, Oct 09 2000, Alan Cox wrote: > > At this point, I would prefer that we just leave the ordering alone - I > > don' tknow of any actual problems with it, and I don't think it's worth > > re-organizing things to make it the exact same thing it used to be.. > > SCSI has real ordering requirements for drivers. > > You have to do Buslogic and AHA17xx before AHA15xx or you get a wrong driver > and in the 17xx case data corruption risks > You must do scsi before i2o_scsi or AMI Megaraids break > My point exactly. The ordering of driver in drivers/scsi is done now, but I don't see a clean way of doing I2O without moving upperlayers into a seperate dir. -- 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: [PATCH] Link order of drivers outside drivers/scsi
On Sun, Oct 08 2000, Linus Torvalds wrote: > > > On Thu, 5 Oct 2000, Torben Mathiasen wrote: > > > > This patch is a resend of my other link fix patch that didn't get > > in test9-pre9. I assume this is because of some other changes > > to upper layer scsi drivers. > > No, I just felt it was too big, and with not enough reason for it at all. > > At this point, I would prefer that we just leave the ordering alone - I > don' tknow of any actual problems with it, and I don't think it's worth > re-organizing things to make it the exact same thing it used to be.. > No problem, but what about Alan's statement? : > You need to get the i2o scsi driver run last afte the low level and before > the high level drivers despite being in drivers/i2o. There are some other > drivers which arent in drivers/scsi too > It seems reasonable. -- 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: [PATCH] 2nd go for scsi upper layers + I2O
On Fri, Oct 06 2000, Douglas Gilbert wrote: > Torben Mathiasen wrote: > > > Ok this patch should be diffed correctly. Same things apply: > > > > apply patch > > copy sd.c st.c sg.c sr.c sr_ioctl.c sr_vendor.c from > > drivers/scsi to drivers/scsi/upper > > > > The EXPORT_SYMBOL has been removed as Jeff suggested. > > > > TLAN will hopefully follow soon. > > [snipped most of patch, see lkml] > > > +sg_mod.o: $(sg_mod-objs) > > + $(LD) -r -o $@ $(sg_mod-objs) > > Firstly, I just spent 2 months trying to get the sd module > name reverted to "sd_mod.o" as it is in lk 2.2 and 2.0 .Now > this patch seems to rename the sg module to "sg_mod.o"! > Since the vast majority of distributions build sg as a module, > there could be a lot of irate SANE and cdrecord users out > there. Also devfsd and other module loading software would > need to be changed. Hopefully this is an oversight. > Sure, no problem. > Secondly, do we really need the scsi Makefile and directory > structure changed this close to the lk 2.4 release? > What does it gain us? Could changes of this dimension be > sent to Eric Youngdale or at least the linux-scsi list > rather than just sent to the linux-kernel list? First of all I _did_ send a patch off to linux-scsi, and this issue _has_ been discussed with Eric. And yes its needed. The lowlevel scsi drivers needs to link in before the high level ones. Alan posted this to l-k. > You need to get the i2o scsi driver run last afte the low level and before > the high level drivers despite being in drivers/i2o. There are some other > drivers which arent in drivers/scsi too > Maybe you should take a look at the archives before bitching. Now I'm tired of fixes this and that. Can we agree on this patch going in when I rename sg_mod.o to sg.o??? -- 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/
[PATCH] 2nd go for scsi upper layers + I2O
Ok this patch should be diffed correctly. Same things apply:
apply patch
copy sd.c st.c sg.c sr.c sr_ioctl.c sr_vendor.c from
drivers/scsi to drivers/scsi/upper
The EXPORT_SYMBOL has been removed as Jeff suggested.
TLAN will hopefully follow soon.
--
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer
http://tlan.kernel.dk
diff -urN linux-test9/Makefile linux/Makefile
--- linux-test9/MakefileThu Oct 5 22:21:00 2000
+++ linux/Makefile Thu Oct 5 22:24:11 2000
@@ -144,7 +144,13 @@
DRIVERS-$(CONFIG_ARCNET) += drivers/net/arcnet/arcnet.a
DRIVERS-$(CONFIG_ATM) += drivers/atm/atm.o
DRIVERS-$(CONFIG_IDE) += drivers/ide/idedriver.o
+
+# Init ordering constraint:
+# scsidrv.o < !drivers/scsi < scsi_upper.o
DRIVERS-$(CONFIG_SCSI) += drivers/scsi/scsidrv.o
+DRIVERS-$(CONFIG_I2O) += drivers/i2o/i2o.o
+DRIVERS-$(CONFIG_SCSI) += drivers/scsi/upper/scsi_upper.o
+
DRIVERS-$(CONFIG_IEEE1394) += drivers/ieee1394/ieee1394.a
ifneq
($(CONFIG_CD_NO_IDESCSI)$(CONFIG_BLK_DEV_IDECD)$(CONFIG_BLK_DEV_SR)$(CONFIG_PARIDE_PCD),)
@@ -171,7 +177,6 @@
DRIVERS-$(CONFIG_TC) += drivers/tc/tc.a
DRIVERS-$(CONFIG_USB) += drivers/usb/usbdrv.o
DRIVERS-$(CONFIG_INPUT) += drivers/input/inputdrv.o
-DRIVERS-$(CONFIG_I2O) += drivers/i2o/i2o.o
DRIVERS-$(CONFIG_IRDA) += drivers/net/irda/irda.o
DRIVERS-$(CONFIG_I2C) += drivers/i2c/i2c.o
DRIVERS-$(CONFIG_PHONE) += drivers/telephony/telephony.o
diff -urN linux-test9/drivers/block/genhd.c linux/drivers/block/genhd.c
--- linux-test9/drivers/block/genhd.c Thu Oct 5 22:21:03 2000
+++ linux/drivers/block/genhd.c Thu Oct 5 22:24:11 2000
@@ -27,7 +27,6 @@
extern void console_map_init(void);
extern int soc_probe(void);
extern int atmdev_init(void);
-extern int i2o_init(void);
extern int cpqarray_init(void);
extern void ieee1394_init(void);
@@ -39,9 +38,6 @@
chr_dev_init();
blk_dev_init();
sti();
-#ifdef CONFIG_I2O
- i2o_init();
-#endif
#ifdef CONFIG_BLK_DEV_DAC960
DAC960_Initialize();
#endif
diff -urN linux-test9/drivers/i2o/i2o_block.c linux/drivers/i2o/i2o_block.c
--- linux-test9/drivers/i2o/i2o_block.c Thu Oct 5 22:21:04 2000
+++ linux/drivers/i2o/i2o_block.c Thu Oct 5 22:28:24 2000
@@ -46,6 +46,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1591,11 +1592,7 @@
* (Just smiley confuses emacs :-)
*/
-#ifdef MODULE
-#define i2o_block_init init_module
-#endif
-
-int i2o_block_init(void)
+static int __init i2o_block_init(void)
{
int i;
@@ -1611,9 +1608,8 @@
MAJOR_NR);
return -EIO;
}
-#ifdef MODULE
+
printk(KERN_INFO "i2o_block: registered device at major %d\n", MAJOR_NR);
-#endif
/*
* Now fill in the boiler plate
@@ -1694,13 +1690,7 @@
return 0;
}
-#ifdef MODULE
-
-EXPORT_NO_SYMBOLS;
-MODULE_AUTHOR("Red Hat Software");
-MODULE_DESCRIPTION("I2O Block Device OSM");
-
-void cleanup_module(void)
+static void __exit i2o_block_exit(void)
{
struct gendisk **gdp;
int i;
@@ -1760,4 +1750,10 @@
break;
}
-#endif
+
+MODULE_AUTHOR("Red Hat Software");
+MODULE_DESCRIPTION("I2O Block Device OSM");
+
+module_init(i2o_block_init);
+module_exit(i2o_block_exit);
+
diff -urN linux-test9/drivers/i2o/i2o_config.c linux/drivers/i2o/i2o_config.c
--- linux-test9/drivers/i2o/i2o_config.cThu Oct 5 22:21:04 2000
+++ linux/drivers/i2o/i2o_config.c Thu Oct 5 22:46:18 2000
@@ -910,11 +910,7 @@
&config_fops
};
-#ifdef MODULE
-int init_module(void)
-#else
-int __init i2o_config_init(void)
-#endif
+static int __init i2o_config_init(void)
{
printk(KERN_INFO "I2O configuration manager v 0.04.\n");
printk(KERN_INFO " (C) Copyright 1999 Red Hat Software\n");
@@ -948,9 +944,7 @@
return 0;
}
-#ifdef MODULE
-
-void cleanup_module(void)
+void __exit i2o_config_exit(void)
{
misc_deregister(&i2o_miscdev);
@@ -961,9 +955,10 @@
if(i2o_buffer)
kfree(i2o_buffer);
}
+
+module_init(i2o_config_init);
+module_exit(i2o_config_exit);
-EXPORT_NO_SYMBOLS;
MODULE_AUTHOR("Red Hat Software");
MODULE_DESCRIPTION("I2O Configuration");
-#endif
diff -urN linux-test9/drivers/i2o/i2o_core.c linux/drivers/i2o/i2o_core.c
--- linux-test9/drivers/i2o/i2o_core.c Thu Oct 5 22:21:04 2000
+++ linux/drivers/i2o/i2o_core.cThu Oct 5 22:24:11 2000
@@ -19,7 +19,7 @@
* Auvo Häkkinen <[EMAIL PROTECTED]>
* Deepak Saxena <[EMAIL PROTECTED]>
* Boji T Kannanthanam <[EMAIL PROTECTED]>
- *
+ * Torben Mathiasen <[EMAIL PROTECTED]>
*/
#include
@@ -119,7 +119,6 @@
*/
static spinlock_t i2o_dev_lock = SPIN_LOC
Re: Majordomo Problems?
On Thu, Oct 05 2000, Post, Mark K wrote: > I don't know if anyone else is seeing this, but I'm getting multiple copies > of > a lot of the emails to this list. For some, it's two copies, for others it > is up > to four copies. Am I the only one seeing this? > I have the same problems, thought it was because my resubscription went wrong. -- 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: [PATCH] tlan timer fix on tytso's list.
On Thu, Oct 05 2000, Jeff Garzik wrote: > * return value from pci_module_init and TLan_EisaProbe is never checked. > If you don't care about the return value, just remove 'rc' var. > I was going to have some code here, but haven't had the time. I'll remove it. > * does TLan_EisaProbe work? It looks like request_region may be called > twice for the same I/O region, once in TLan_EisaProbe, and once in > TLan_Init (via TLan_probe1). Yes it works. Check the code again: if (!priv->is_eisa) Jeff I'll make the other changes you suggested. -- 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: [PATCH] Link order of drivers outside drivers/scsi
On Thu, Oct 05 2000, Jeff Garzik wrote: > Please include your patches inline so we can easily quote them via the > standard e-mail reply feature. > > i2o_block.c: you don't need EXPORT_NO_SYMBOLS (yes, I know it was there > before) I' remove it. > sg.c: ug. the worst part of the patch. you revert some of doug > gilbert's correct changes, which went in after test9-pre9. This is > way wrong, so maybe it's a version/diff problem? > My fault. It seems I've had and old sg.c in my tree. Sorry should have double checked. -- 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: [PATCH] tlan timer fix on tytso's list.
On Thu, Oct 05 2000, Tigran Aivazian wrote: > Hi Torben, > > Just a tiny comment - maybe you noticed the recent "trend" in moving > zero-initialised data out of data into where it belongs, i.e. bss. Your > patch does a little bit to the contrary, namely bits like: > > +static struct net_device *TLan_Eisa_Devices = NULL; > > > > +static int tlan_have_pci = 0; > +static int tlan_have_eisa = 0; > True. I'll submit a new patch ASAP. Thanks for noticing Tigran. -- 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/
[PATCH] Link order of drivers outside drivers/scsi
Linus,
This patch is a resend of my other link fix patch that didn't get
in test9-pre9. I assume this is because of some other changes
to upper layer scsi drivers.
This patch is a lot smaller because the "moving files around" part
has been omittet.
So please apply this patch and do the following:
copy sd.c sg.c sr.c sr_ioctl.c sr_vendor st.c to
drivers/scsi/upper
I really hope you don't mind this way of applying a patch, so if
you do please let me know. The patch still includes the I2O
fixes (verified by Alan).
BTW. To fix other drivers outside drivers/scsi to link corretly
they need the same changes as I2O:
convert to initcalls
move them in top makefile.
I just need to identify which drivers needs this.
--
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer
http://tlan.kernel.dk
diff -urN linux-test9/Makefile linux/Makefile
--- linux-test9/MakefileTue Oct 3 23:39:53 2000
+++ linux/Makefile Tue Oct 3 23:38:41 2000
@@ -144,7 +144,13 @@
DRIVERS-$(CONFIG_ARCNET) += drivers/net/arcnet/arcnet.a
DRIVERS-$(CONFIG_ATM) += drivers/atm/atm.o
DRIVERS-$(CONFIG_IDE) += drivers/ide/idedriver.o
+
+# Init ordering constraint:
+# scsidrv.o < !drivers/scsi < scsi_upper.o
DRIVERS-$(CONFIG_SCSI) += drivers/scsi/scsidrv.o
+DRIVERS-$(CONFIG_I2O) += drivers/i2o/i2o.o
+DRIVERS-$(CONFIG_SCSI) += drivers/scsi/upper/scsi_upper.o
+
DRIVERS-$(CONFIG_IEEE1394) += drivers/ieee1394/ieee1394.a
ifneq
($(CONFIG_CD_NO_IDESCSI)$(CONFIG_BLK_DEV_IDECD)$(CONFIG_BLK_DEV_SR)$(CONFIG_PARIDE_PCD),)
@@ -171,7 +177,6 @@
DRIVERS-$(CONFIG_TC) += drivers/tc/tc.a
DRIVERS-$(CONFIG_USB) += drivers/usb/usbdrv.o
DRIVERS-$(CONFIG_INPUT) += drivers/input/inputdrv.o
-DRIVERS-$(CONFIG_I2O) += drivers/i2o/i2o.o
DRIVERS-$(CONFIG_IRDA) += drivers/net/irda/irda.o
DRIVERS-$(CONFIG_I2C) += drivers/i2c/i2c.o
DRIVERS-$(CONFIG_PHONE) += drivers/telephony/telephony.o
diff -urN linux-test9/drivers/block/genhd.c linux/drivers/block/genhd.c
--- linux-test9/drivers/block/genhd.c Tue Oct 3 23:39:58 2000
+++ linux/drivers/block/genhd.c Tue Oct 3 23:38:41 2000
@@ -27,7 +27,6 @@
extern void console_map_init(void);
extern int soc_probe(void);
extern int atmdev_init(void);
-extern int i2o_init(void);
extern int cpqarray_init(void);
extern void ieee1394_init(void);
@@ -39,9 +38,6 @@
chr_dev_init();
blk_dev_init();
sti();
-#ifdef CONFIG_I2O
- i2o_init();
-#endif
#ifdef CONFIG_BLK_DEV_DAC960
DAC960_Initialize();
#endif
diff -urN linux-test9/drivers/i2o/i2o_block.c linux/drivers/i2o/i2o_block.c
--- linux-test9/drivers/i2o/i2o_block.c Tue Oct 3 23:40:13 2000
+++ linux/drivers/i2o/i2o_block.c Tue Oct 3 23:38:41 2000
@@ -46,6 +46,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -108,6 +109,7 @@
#define I2O_BSA_DSC_VOLUME_CHANGED 0x000D
#define I2O_BSA_DSC_TIMEOUT 0x000E
+
/*
* Some of these can be made smaller later
*/
@@ -1591,11 +1593,7 @@
* (Just smiley confuses emacs :-)
*/
-#ifdef MODULE
-#define i2o_block_init init_module
-#endif
-
-int i2o_block_init(void)
+static int __init i2o_block_init(void)
{
int i;
@@ -1611,9 +1609,8 @@
MAJOR_NR);
return -EIO;
}
-#ifdef MODULE
+
printk(KERN_INFO "i2o_block: registered device at major %d\n", MAJOR_NR);
-#endif
/*
* Now fill in the boiler plate
@@ -1694,13 +1691,7 @@
return 0;
}
-#ifdef MODULE
-
-EXPORT_NO_SYMBOLS;
-MODULE_AUTHOR("Red Hat Software");
-MODULE_DESCRIPTION("I2O Block Device OSM");
-
-void cleanup_module(void)
+static void __exit i2o_block_exit(void)
{
struct gendisk **gdp;
int i;
@@ -1760,4 +1751,11 @@
break;
}
-#endif
+
+EXPORT_NO_SYMBOLS;
+MODULE_AUTHOR("Red Hat Software");
+MODULE_DESCRIPTION("I2O Block Device OSM");
+
+module_init(i2o_block_init);
+module_exit(i2o_block_exit);
+
diff -urN linux-test9/drivers/i2o/i2o_config.c linux/drivers/i2o/i2o_config.c
--- linux-test9/drivers/i2o/i2o_config.cTue Oct 3 23:40:13 2000
+++ linux/drivers/i2o/i2o_config.c Tue Oct 3 23:38:41 2000
@@ -910,11 +910,7 @@
&config_fops
};
-#ifdef MODULE
-int init_module(void)
-#else
-int __init i2o_config_init(void)
-#endif
+static int __init i2o_config_init(void)
{
printk(KERN_INFO "I2O configuration manager v 0.04.\n");
printk(KERN_INFO " (C) Copyright 1999 Red Hat Software\n");
@@ -948,9 +944,7 @@
return 0;
}
-#ifdef MODULE
-
-void cleanup_module(void)
+void __exit i2o_config_exit(void)
{
misc_deregister(&i2o_miscdev);
@@ -961,9 +955,11 @@
if(i2o_buffer)
kfree(i2o_buffer);
}
+
+module_init(i2o_config_init);
+module_exit(i2o_config_exit);
EXPORT_NO_SYMBOLS;
[PATCH] tlan timer fix on tytso's list.
Linus,
This patch includes the following:
Fixes the timer being added twice bug (on tytso's list)
Convertes driver to new PCI layout
Adds support for EISA based TLAN adapters.
Patch has been tested for over a month now and is ready for 2.4.
Against final test9.
--
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer
http://tlan.kernel.dk
diff -ur --exclude-from=/root/dontdiff linux-test9/drivers/net/tlan.c
linux/drivers/net/tlan.c
--- linux-test9/drivers/net/tlan.c Tue Oct 3 23:39:57 2000
+++ linux/drivers/net/tlan.cWed Oct 4 21:33:06 2000
@@ -98,14 +98,45 @@
* v1.8a May 28, 2000 - Minor updates.
*
* v1.9 July 25, 2000 - Fixed a few remaining Full-Duplex issues.
- * - Updated with timer fixes from Andrew Morton.
- * - Fixed module race in TLan_Open.
- * - Added routine to monitor PHY status.
- * - Added activity led support for Proliant devices.
+ * - Updated with timer fixes from Andrew Morton.
+ * - Fixed module race in TLan_Open.
+ * - Added routine to monitor PHY status.
+ * - Added activity led support for Proliant devices.
+ *
+ * v1.10 Aug 30, 2000 - Added support for EISA based tlan controllers
+ *like the Compaq NetFlex3/E.
+ * - Rewrote tlan_probe to better handle multiple
+ *bus probes. Probing and device setup is now
+ *done through TLan_Probe and TLan_init_one. Actual
+ *hardware probe is done with kernel API and
+ *TLan_EisaProbe.
+ * - Adjusted debug information for probing.
+ * - Fixed bug that would cause general debug information
+ *to be printed after driver removal.
+ * - Added transmit timeout handling.
+ * - Fixed OOM return values in tlan_probe.
+ * - Fixed possible mem leak in tlan_exit
+ *(now tlan_remove_one).
+ * - Fixed timer bug in TLan_phyMonitor.
+ * - This driver version is alpha quality, please
+ *send me any bug issues you may encounter.
+ *
+ * v1.11 Aug 31, 2000 - Do not try to register irq 0 if no irq line was
+ *set for EISA cards.
+ * - Added support for NetFlex3/E with nibble-rate
+ *10Base-T PHY. This is untestet as I haven't got
+ *one of these cards.
+ * - Fixed timer being added twice.
+ * - Disabled PhyMonitoring by default as this is
+ *work in progress. Define MONITOR to enable it.
+ * - Now we don't display link info with PHYs that
+ *doesn't support it (level1).
+ * - Incresed tx_timeout beacuse of auto-neg.
+ * - Adjusted timers for forced speeds.
*
***/
-
+
#include
#include "tlan.h"
@@ -121,8 +152,9 @@
typedef u32 (TLanIntVectorFunc)( struct net_device *, u16 );
+/* For removing EISA devices */
+static struct net_device *TLan_Eisa_Devices = NULL;
-static struct net_device *TLanDevices = NULL;
static int TLanDevicesInstalled = 0;
/* Force speed, duplex and aui settings */
@@ -138,13 +170,18 @@
MODULE_PARM(debug, "i");
EXPORT_NO_SYMBOLS;
+/* Define this to enable Link beat monitoring */
+#undef MONITOR
+
/* Turn on debugging. See linux/Documentation/networking/tlan.txt for details */
static intdebug = 0;
static int bbuf = 0;
static u8 *TLanPadBuffer;
static charTLanSignature[] = "TLAN";
-static const char *tlan_banner = "ThunderLAN driver v1.9\n";
+static const char *tlan_banner = "ThunderLAN driver v1.11\n";
+static int tlan_have_pci = 0;
+static int tlan_have_eisa = 0;
const char *media[] = {
"10BaseT-HD ", "10BaseT-FD ","100baseTx-HD ",
@@ -153,103 +190,73 @@
int media_map[] = { 0x0020, 0x0040, 0x0080, 0x0100, 0x0200,};
-static TLanAdapterEntry TLanAdapterList[] __initdata = {
- { PCI_VENDOR_ID_COMPAQ,
- PCI_DEVICE_ID_NETELLIGENT_10,
- "Compaq Netelligent 10 T PCI UTP",
- TLAN_ADAPTER_ACTIVITY_LED,
- 0x83
- },
-
Re: aic7xxx problem with 2.4.0-test8
On Mon, Oct 02 2000, Pierfrancesco Caci wrote: > :-> "Pierfrancesco" == Pierfrancesco Caci <[EMAIL PROTECTED]> writes: > > > > Now I'm going to try the test9-pre7 stuff :-) > > > > Tested. It works as a module now. Didn't try to actually _use_ the > scanner. > > What was the problem, then ? > The scsi routines had an overhaul that wasn't completely fixed in test8. -- 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/
For Alan, i2o updates.
Sorry for the disturbance folks, but my mailer currently has
something against Alan.
Alan,
This is the i2o patch I'm going to put into the bigger "move-scsi
things-around" patch. This is just for you to verify.
--
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer
http://tlan.kernel.dk
diff -urN --exclude-from=/root/torben linux-test9p7-patched/drivers/block/genhd.c
linux/drivers/block/genhd.c
--- linux-test9p7-patched/drivers/block/genhd.c Sat Sep 30 20:47:06 2000
+++ linux/drivers/block/genhd.c Thu Sep 28 17:18:42 2000
@@ -27,7 +27,6 @@
extern void console_map_init(void);
extern int soc_probe(void);
extern int atmdev_init(void);
-extern int i2o_init(void);
extern int cpqarray_init(void);
extern void ieee1394_init(void);
@@ -39,9 +38,6 @@
chr_dev_init();
blk_dev_init();
sti();
-#ifdef CONFIG_I2O
- i2o_init();
-#endif
#ifdef CONFIG_BLK_DEV_DAC960
DAC960_Initialize();
#endif
diff -urN --exclude-from=/root/torben linux-test9p7-patched/drivers/i2o/i2o_block.c
linux/drivers/i2o/i2o_block.c
--- linux-test9p7-patched/drivers/i2o/i2o_block.c Fri Jul 7 04:24:51 2000
+++ linux/drivers/i2o/i2o_block.c Sat Sep 30 17:20:02 2000
@@ -46,6 +46,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -108,6 +109,7 @@
#define I2O_BSA_DSC_VOLUME_CHANGED 0x000D
#define I2O_BSA_DSC_TIMEOUT 0x000E
+
/*
* Some of these can be made smaller later
*/
@@ -1591,11 +1593,7 @@
* (Just smiley confuses emacs :-)
*/
-#ifdef MODULE
-#define i2o_block_init init_module
-#endif
-
-int i2o_block_init(void)
+static int __init i2o_block_init(void)
{
int i;
@@ -1611,9 +1609,8 @@
MAJOR_NR);
return -EIO;
}
-#ifdef MODULE
+
printk(KERN_INFO "i2o_block: registered device at major %d\n", MAJOR_NR);
-#endif
/*
* Now fill in the boiler plate
@@ -1694,13 +1691,7 @@
return 0;
}
-#ifdef MODULE
-
-EXPORT_NO_SYMBOLS;
-MODULE_AUTHOR("Red Hat Software");
-MODULE_DESCRIPTION("I2O Block Device OSM");
-
-void cleanup_module(void)
+static void __exit i2o_block_exit(void)
{
struct gendisk **gdp;
int i;
@@ -1760,4 +1751,11 @@
break;
}
-#endif
+
+EXPORT_NO_SYMBOLS;
+MODULE_AUTHOR("Red Hat Software");
+MODULE_DESCRIPTION("I2O Block Device OSM");
+
+module_init(i2o_block_init);
+module_exit(i2o_block_exit);
+
diff -urN --exclude-from=/root/torben linux-test9p7-patched/drivers/i2o/i2o_config.c
linux/drivers/i2o/i2o_config.c
--- linux-test9p7-patched/drivers/i2o/i2o_config.c Thu Jul 13 06:58:42 2000
+++ linux/drivers/i2o/i2o_config.c Thu Sep 28 23:54:09 2000
@@ -910,11 +910,7 @@
&config_fops
};
-#ifdef MODULE
-int init_module(void)
-#else
-int __init i2o_config_init(void)
-#endif
+static int __init i2o_config_init(void)
{
printk(KERN_INFO "I2O configuration manager v 0.04.\n");
printk(KERN_INFO " (C) Copyright 1999 Red Hat Software\n");
@@ -948,9 +944,7 @@
return 0;
}
-#ifdef MODULE
-
-void cleanup_module(void)
+void __exit i2o_config_exit(void)
{
misc_deregister(&i2o_miscdev);
@@ -961,9 +955,11 @@
if(i2o_buffer)
kfree(i2o_buffer);
}
+
+module_init(i2o_config_init);
+module_exit(i2o_config_exit);
EXPORT_NO_SYMBOLS;
MODULE_AUTHOR("Red Hat Software");
MODULE_DESCRIPTION("I2O Configuration");
-#endif
diff -urN --exclude-from=/root/torben linux-test9p7-patched/drivers/i2o/i2o_core.c
linux/drivers/i2o/i2o_core.c
--- linux-test9p7-patched/drivers/i2o/i2o_core.cMon Jun 19 22:30:56 2000
+++ linux/drivers/i2o/i2o_core.cSat Sep 30 18:56:33 2000
@@ -19,7 +19,7 @@
* Auvo Häkkinen <[EMAIL PROTECTED]>
* Deepak Saxena <[EMAIL PROTECTED]>
* Boji T Kannanthanam <[EMAIL PROTECTED]>
- *
+ * Torben Mathiasen <[EMAIL PROTECTED]>
*/
#include
@@ -119,7 +119,6 @@
*/
static spinlock_t i2o_dev_lock = SPIN_LOCK_UNLOCKED;
-#ifdef MODULE
/*
* Function table to send to bus specific layers
* See for explanation of this
@@ -134,12 +133,9 @@
i2o_delete_controller
};
-#ifdef CONFIG_I2O_PCI_MODULE
extern int i2o_pci_core_attach(struct i2o_core_func_table *);
extern void i2o_pci_core_detach(void);
-#endif /* CONFIG_I2O_PCI_MODULE */
-#endif /* MODULE */
/*
* Structures and definitions for synchronous message posting.
@@ -3115,8 +3111,6 @@
}
-#ifdef MODULE
-
EXPORT_SYMBOL(i2o_controller_chain);
EXPORT_SYMBOL(i2o_num_controllers);
EXPORT_SYMBOL(i2o_find_controller);
@@ -3152,8 +3146,7 @@
MODULE_AUTHOR("Red Hat Software");
MODULE_DESCRIPTION("I2O Core");
-
-int init_module(void)
+static int __init init_i2o
Re: aic7xxx problem with 2.4.0-test8
On Sun, Oct 01 2000, Pierfrancesco Caci wrote: > > When modprobing for this module, my machine gets stuck with no > messages whatsoever in the log. Only Alt-SysRq-R works (the other > combinations, while outputting something to the screen, do not > actually terminate the tasks or remount r/o the filesystem). > The last thing on the screen was the output of the probe of the scsi > chain on the aic adapter. It just had the time to print the name of > the scanner that it is connected to it and then nothing more. > I still can switch between the different vc, but no input is accepted. > > Any hints? > Could you give test9-pre7 a try? -- 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: SA_INTERRUPT
On Sun, Oct 01 2000, Torben Mathiasen wrote: > On Sat, Sep 30 2000, Sandy Harris wrote: > > Don Becker has some text at: > > > > http://www.scyld.com/expert/irq-conflict.html > > > > which includes a section: > > > > > Why SA_INTERRUPT in the SCSI drivers is a Bad Thing > > > > > ... it could potentially have a very negative impact on all other >interrupt-driven > > > kernel service. That includes just about everything ... > > > > > > I believe that very few complex devices can be correctly run by a device driver > > > that uses SA_INTERRUPT. > > > > So I grepped drivers/*/*.c in the nearest handy kernel source, which happened to >be > > 2.2.16, and found 113 uses of SA_INTEERUPT, 64 in drivers/scsi/*.c and the rest >spread > > around. > > > > Do we have a problem? Should it be fixed as part of the cleanup before 2.4.0? > > No. SA_INTERRUPT is a must today. Its much better to just do BIOS tweaks to force > irq assignments. Thats just IMHO. > Ooops. Just saw Andrea's mail. Don't know what I was smoking. SA_INTERRUPT Not SA_SHIRQ. Sorry, for the crap. -- 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: SA_INTERRUPT
On Sat, Sep 30 2000, Sandy Harris wrote: > Don Becker has some text at: > > http://www.scyld.com/expert/irq-conflict.html > > which includes a section: > > > Why SA_INTERRUPT in the SCSI drivers is a Bad Thing > > > ... it could potentially have a very negative impact on all other interrupt-driven > > kernel service. That includes just about everything ... > > > > I believe that very few complex devices can be correctly run by a device driver > > that uses SA_INTERRUPT. > > So I grepped drivers/*/*.c in the nearest handy kernel source, which happened to be > 2.2.16, and found 113 uses of SA_INTEERUPT, 64 in drivers/scsi/*.c and the rest >spread > around. > > Do we have a problem? Should it be fixed as part of the cleanup before 2.4.0? No. SA_INTERRUPT is a must today. Its much better to just do BIOS tweaks to force irq assignments. Thats just IMHO. -- 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: [PATCH] link-order of drivers outside drivers/scsi (i2o)
On Thu, Sep 28 2000, Alan Cox wrote: > > Note that for this to work properly, i2o (and the others) needs to > > be converted to initialization by initcalls. This is trivial? or do the module > > case differ from builtin? > > It shouldnt be a problem. The order inside of i2o just needs to start with core > and pci. > Good. I'm on it.. -- 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/
[PATCH] link-order of drivers outside drivers/scsi (i2o)
Alan and others, The following patch changes the link order of i2o to link: scsi core - hosts - i2o - upper layers. The patch moves things around a bit, like all upper layer drivers going into scsi/upper. Other drivers outside drivers/scsi can be changed to link in after the other hosts by just moving them in the top Makefile. Note that for this to work properly, i2o (and the others) needs to be converted to initialization by initcalls. This is trivial? or do the module case differ from builtin? This patch is pretty big(625Kbytes), so grab it from: http://tlan.kernel.dk/div/scsi_upper4.diff It includes a lot of work from Michael Chastain. A typical patched kernel compile with everyting built into the kernel looks like this: drivers/ide/idedriver.o drivers/scsi/scsidrv.o drivers/i2o/i2o.o drivers/scsi/upper/scsi_upper.o drivers/... The scsi_upper.o object includes st, sr, sg, sd. Have a nice day. -- 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: [PATCH] Re: SCSI scanning
On Thu, Sep 21 2000, Michael Elizabeth Chastain wrote: > torben> core-hosts/i2o-upper. > > Ok, I understand the problem. > > Can you elaborate some more on exactly which files go in "core", > "hosts", and "upper"? My understanding is: > > # drivers/scsi > scsi-core-files := scsi_mod.o scsi_syms.o > scsi-hosts-files := ... everything not in core and upper ... > scsi-upper-files := st.o sd_mod.o sr_mod.o sg.o > > # i2o > i2o-files:= %.o > Eaxctly. The core and upperlayers are ok now. You just need to get all hosts adapters into hosts.o. Everything is there except those outside drivers/scsi. It would be great if someone with an i2o adapter could verify any changes. Please note I already sorted the hosts.o files in the drivers/scsi/Makefile. > I can do this in the top Makefile by declaring lists like the above > using $(filter) and $(filter-out). The hard part is going to be defining > "scsi-hosts-files" to work properly. I think I will need to add a few > more lines to drivers/scsi/Makefile and make one more multi. Or maybe > three more multis. Yeah I've been thinking of doing this, but was afraid to srew it up. Give it a try, and lets see what Linus thinks. BTW, while you are at it, could you rename sg.o to sg_mod.o. It would look better... -- 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: [PATCH] Re: SCSI scanning
On Thu, Sep 21 2000, Michael Elizabeth Chastain wrote: > Torben Mathiasen wrote: > > > I can't seem to find a clean way of getting the drivers outside > > "drivers/scsi" to link _after_ the other low-level drivers. > > Can you characterize the problem in more detail for me? That is, > exactly what link order constraints you are trying to obey. > > I am thinking about this: > > # Makefile > link-first := drivers/scsi/foo.o drivers/i2o/%o drivers/scsi/bar.o > link-last := > > DRIVERS := \ > $(filter $(link-first), $(DRIVERS)) \ > $(filter-out $(link-first) $(link-last), $(DRIVERS)) \ > $(filter $(link-last), $(DRIVERS)) > Okay, in pre5 I got the scsi system to link core-hosts-upperlayers. We need to get the drivers outside drivers/scsi to link as the _last_ ones in the host section: core-hosts/i2o-upper. Now this is difficult without moving things around, which is bad. I'm not a makefile guru, so if you have any ideas go for it. Alan problaly wants to verify the i2o stuff... The perfect solution would be to remove the link order dependency. -- 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, 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
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
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, 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, 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/
[PATCH] Scsi scanning fixes
Linus and others, Patch attached that should fix some of the problems with the new scsi scanning: devfs registration should be ok now with both builtin and module. link order changed to reflect hosts.c + minor additions. minor cleanups. First of all, please don't yell too loud about the Makefile changes. I really stink at this, but it seems to work for me. Tested different configs, with different hosts. Layers get linked: core - hosts - upper I'm sure the Makefile stuff can be done a lot better, so someone please do if my attempt is crap. I had to link scsi_syms separately in order not to get unresolved symbols with modules. Also, those of you that have special needs with regards to host order initialization, please let us know. Please specify which driver runs what controller. Thanks -- Torben Mathiasen <[EMAIL PROTECTED]> Linux ThunderLAN maintainer http://tlan.kernel.dk diff -ur --exclude-from=/root/torben linux-2.4.0-test9p4/drivers/scsi/Makefile linux/drivers/scsi/Makefile --- linux-2.4.0-test9p4/drivers/scsi/Makefile Wed Sep 20 16:52:35 2000 +++ linux/drivers/scsi/Makefile Wed Sep 20 17:12:36 2000 @@ -4,6 +4,8 @@ # 30 May 2000, Christoph Hellwig <[EMAIL PROTECTED]> # Rewritten to use lists instead of if-statements. # +# 20 Sep 2000, Torben Mathiasen <[EMAIL PROTECTED]> +# Changed link order to reflect new scsi initialization. O_TARGET := scsidrv.o @@ -22,25 +24,14 @@ endif export-objs:= scsi_syms.o -list-multi := scsi_mod.o sr_mod.o initio.o a100u2w.o +list-multi := scsi_mod.o initio.o a100u2w.o CFLAGS_aha152x.o = -DAHA152X_STAT -DAUTOCONF CFLAGS_gdth.o= # -DDEBUG_GDTH=2 -D__SERIAL__ -D__COM2__ -DGDTH_STATISTICS CFLAGS_seagate.o = -DARBITRATE -DPARITY -DSEAGATE_USE_ASM -obj-$(CONFIG_SCSI) += scsi_mod.o -obj-$(CONFIG_CHR_DEV_ST) += st.o -obj-$(CONFIG_BLK_DEV_SD) += sd_mod.o -obj-$(CONFIG_BLK_DEV_SR) += sr_mod.o -obj-$(CONFIG_CHR_DEV_SG) += sg.o +obj-$(CONFIG_SCSI) += scsi_mod.o scsi_syms.o -obj-$(CONFIG_SCSI_ADVANSYS)+= advansys.o -obj-$(CONFIG_SCSI_PCI2000) += pci2000.o -obj-$(CONFIG_SCSI_PCI2220I)+= pci2220i.o -obj-$(CONFIG_SCSI_PSI240I) += psi240i.o -obj-$(CONFIG_MVME16x_SCSI) += mvme16x.o53c7xx.o -obj-$(CONFIG_BVME6000_SCSI)+= bvme6000.o 53c7xx.o -obj-$(CONFIG_SCSI_SIM710) += sim710.o obj-$(CONFIG_A4000T_SCSI) += amiga7xx.o 53c7xx.o obj-$(CONFIG_A4091_SCSI) += amiga7xx.o 53c7xx.o obj-$(CONFIG_BLZ603EPLUS_SCSI) += amiga7xx.o 53c7xx.o @@ -48,8 +39,6 @@ obj-$(CONFIG_A3000_SCSI) += a3000.o wd33c93.o obj-$(CONFIG_A2091_SCSI) += a2091.o wd33c93.o obj-$(CONFIG_GVP11_SCSI) += gvp11.o wd33c93.o -obj-$(CONFIG_SCSI_SGIWD93) += sgiwd93.owd33c93.o -obj-$(CONFIG_SCSI_MCA_53C9X) += NCR53C9x.o mca_53c9x.o obj-$(CONFIG_CYBERSTORM_SCSI) += NCR53C9x.o cyberstorm.o obj-$(CONFIG_CYBERSTORMII_SCSI)+= NCR53C9x.o cyberstormII.o obj-$(CONFIG_BLZ2060_SCSI) += NCR53C9x.o blz2060.o @@ -58,69 +47,82 @@ obj-$(CONFIG_OKTAGON_SCSI) += NCR53C9x.o oktagon_esp.o oktagon_io.o obj-$(CONFIG_ATARI_SCSI) += atari_scsi.o obj-$(CONFIG_MAC_SCSI) += mac_scsi.o -obj-$(CONFIG_SUN3_SCSI)+= sun3_scsi.o obj-$(CONFIG_SCSI_MAC_ESP) += mac_esp.oNCR53C9x.o -obj-$(CONFIG_SCSI_PPA) += ppa.o -obj-$(CONFIG_SCSI_IMM) += imm.o -obj-$(CONFIG_SCSI_QLOGIC_FAS) += qlogicfas.o -obj-$(CONFIG_SCSI_QLOGIC_ISP) += qlogicisp.o -obj-$(CONFIG_SCSI_QLOGIC_1280) += qla1280.o -obj-$(CONFIG_SCSI_ACARD) += atp870u.o -obj-$(CONFIG_SCSI_INITIO) += initio.o -obj-$(CONFIG_SCSI_INIA100) += a100u2w.o -obj-$(CONFIG_SCSI_QLOGIC_FC) += qlogicfc.o +obj-$(CONFIG_SUN3_SCSI)+= sun3_scsi.o +obj-$(CONFIG_MVME16x_SCSI) += mvme16x.o53c7xx.o +obj-$(CONFIG_BVME6000_SCSI)+= bvme6000.o 53c7xx.o +obj-$(CONFIG_SCSI_SIM710) += sim710.o +obj-$(CONFIG_SCSI_ADVANSYS)+= advansys.o +obj-$(CONFIG_SCSI_PCI2000) += pci2000.o +obj-$(CONFIG_SCSI_PCI2220I)+= pci2220i.o +obj-$(CONFIG_SCSI_PSI240I) += psi240i.o +obj-$(CONFIG_SCSI_BUSLOGIC)+= BusLogic.o +obj-$(CONFIG_SCSI_U14_34F) += u14-34f.o +obj-$(CONFIG_SCSI_ULTRASTOR) += ultrastor.o obj-$(CONFIG_SCSI_AHA152X) += aha152x.o obj-$(CONFIG_SCSI_AHA1542) += aha1542.o obj-$(CONFIG_SCSI_AHA1740) += aha1740.o obj-$(CONFIG_SCSI_AIC7XXX) += aic7xxx.o obj-$(CONFIG_SCSI_IPS) += ips.o -obj-$(CONFIG_SCSI_DC390T) += tmscsim.o -obj-$(CONFIG_SCSI_AM53C974)+= AM53C974.o -obj-$(CONFIG_SCSI_BUSLOGIC)+= BusLogic.o -obj-$(CONFIG_SCSI_EATA_DMA)+= eata_dma.o -obj-$(CONFIG_SCSI_EATA_PIO)+= eata_pio.o -obj-$(CONFIG_SCSI_U14_34F) += u14-34f.o -obj-$(CONFIG_SCSI_SUNESP) += esp.o -obj-$(CONFIG_SCSI_QLOGICPTI) += qlogicpti.o -obj-$(CONFIG_SCSI_MESH)+= mesh.o -obj-$(CONFIG_SCSI_MAC
Re: [PATCH] Re: SCSI scanning
On Tue, Sep 19 2000, Eric Youngdale wrote: > 1) SCSI core. > 2) low-level drivers (in same order as specified in hosts.c). > 3) upper level drivers. > Okay, I've just spent a couple of hours browsing through the scsi code, compiling different configs, and trying to figure out what to do with the Makefile stuff. I can't seem to find a clean way of getting the drivers outside "drivers/scsi" to link _after_ the other low-level drivers. My linux Makefile abilities is limited though, so if someone with the knowledge would do what Eric requests above please. We will probaly have to move some thing around, and that would be a _bad_ move at this point I guess. Now as I see it we have a few things we also need to fix: DMA-POOL: Someone on lkm reported getting low on dma-pool memory when using scsi as builtin. Now Eric, how big is the difference between the two cases (module vs. builtin) in the old scsi code? We use the module case for allocating dma mem now. I guess the module case tries to alloc as little as possible in order to not hit fragmentated mem? INIT: The initialization routines needs to be looked at. Because we use the module stuff, some information gets printed wrong, like "scsi: 0 hosts" scrolling down the screen for each host. I begin to wonder if some of this _really_ is 2.5 stuff. If someone can come up with a clean solution to the Makefile issue, we might pull it off. If we need to move the other scsi drivers (i2o, etc.) around I think we should back off and do it nice and slow for 2.5. In this case we could revert to the point where sd/st/sr are modulized, and saving the core system for 2.5. This is just IMHO, let me know what you think. -- 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-pre3 boots, 2.4.0-test9-pre4 doesn't (SCSI)
On Tue, Sep 19 2000, Andries Brouwer wrote: > On Tue, Sep 19, 2000 at 11:29:31AM -0400, Simon Kirby wrote: > > Hello, > > > > 2.4.0-test9-pre3 seems to boot and work fine, but 2.4.0-test9-pre4 with > > the same .config doesn't. It stops here: > > The same here. However, reverting the 1-line change in > linux/drivers/scsi/Makefile makes things work again. > I'm doing a patch to fix the link order of scsi. This will hopefully fix most problems. Stay tuned... -- 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: [PATCH] Re: SCSI scanning
On Tue, Sep 19 2000, Alan Cox wrote: > > Thus my gut tells me the correct link order should be: > > > > 1) SCSI core. > > 2) low-level drivers (in same order as specified in hosts.c). > > 3) upper level drivers. > > You need to get the i2o scsi driver run last afte the low level and before > the high level drivers despite being in drivers/i2o. There are some other > drivers which arent in drivers/scsi too > Did anyone start to cook up a patch for this? Otherwise I'll take look tonight. (which is now, BTW.) -- 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: test9-pre4 bugs
On Tue, Sep 19 2000, Marko Kreen wrote: > Tried running pre4, here notes: > > 1) scsi devfs: /dev/scsi/host0 is now /dev/host0, /dev/scsi exist >but is empty. > 2) lots of messages: Warning - running *really* short on DMA buffers >No oops yet. > Probaly because we used the module part of dma pool allocation. I'll take a look at it. -- 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: [PATCH] Re: SCSI scanning
This will probaly fix a bunch of scsi problems in tytso's list at linux24.sourceforge.net. Could people please verify this and send him a note. Thanks. -- 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: [PATCH] Re: SCSI scanning
On Mon, Sep 18 2000, Torben Mathiasen wrote: > It just hit me when I touched the send button (yeah right!). I'm basicly > compiling the same kernel right now. > Glad we got that in place, otherwise it would have been a long wasted night 8). > And just to follow up on my own mail, this patch works great. This has to be one of the cleanest module conversions I've seen in a while. Although it _will_ require a minor change to all of the scsi drivers, the scsi_module.c implementation helps a lot. At first I was sceptical about the scsi subsytem structure, but it turns out this _is_ what made it possible to do it cleanly, so kudos to Eric. -- 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: [PATCH] Re: SCSI scanning
On Mon, Sep 18 2000, Linus Torvalds wrote: > And think about it - if this part didn't work, then loadable SCSI modules > would never have worked. And every single distribution I know of basically > depends on SCSI drivers being loadable modules, because there are just too > effing many of them ;) > It just hit me when I touched the send button (yeah right!). I'm basicly compiling the same kernel right now. Glad we got that in place, otherwise it would have been a long wasted night 8). > I'll make a test9-pre3 so that you can synch up, but I need to integrate > all the 2.2.x stuff that Alan sent me yesterday first ;) > Excellent, people are starting to cry... -- 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: [PATCH] Re: SCSI scanning
On Mon, Sep 18 2000, Eric Youngdale wrote: > What is the primary objective here - getting rid of #ifdef MODULE, or is > it removing redundant code for the two paths? Or both? > > I am just trying to get a handle on what is driving this. Well the code clean-up came as a pleasent side effect of removing ifdef MODULE. But now it seems Linus has done it without this. I think this is okay, as it gives us a _nice_ working scsi layer back, on which we can build our cleanup. -- 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: [PATCH] Re: SCSI scanning
On Mon, Sep 18 2000, Linus Torvalds wrote: > Actually, hold off a moment. > > It turns out that the MODULE case does all the right things, for all the > obvious reasons. I'm running a kernel that has the #ifdef MODULE stuff > just removed, and it seems to be a rather easy approach. It really only > required making a few things static (the init routines would clash > otherwise), and removing a lot of #ifdef MODULE. > > (And removing some code that was enabled only for non-modules). > > It looks very straightforward. > What about the case when scsi is compiled into the kernel with one or more host adapters? We have to initialize those right away. Please explain what you did with all the host initialization (spin-up, etc.) in scsi_dev_init. You could also just send me a diff, and I'll take a look. -- 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: [PATCH] Re: SCSI scanning
On Mon, Sep 18 2000, Eric Youngdale wrote: > Historical. SCSI was made modular very early on when the modules > technology was pretty primative. As time has gone on, the two > initialization paths have converged, and now they are essentially redundant. > Thats understandable. > The one thing that is different in the module/non-module case is for the > case of SCSI compiled into the kernel, you need to look at the list of > compiled-in host adapters. Unless of course you are cleaning that up as > well. I haven't seen the threads that got this work started, and it is only > in reading this morning's messages that I see the rationale for all these > changes in the first place. There are a couple of ways of addressing this, > some better than others, and some are more work than others. I can give you > assistance and ideas if you want. > Thanks a lot. I've started to do the basics, like getting all subsystems to work with the module_init/exit stuff. This of course leds to some rewriteting/restructuring of the scsi layer. Nothing major though. It seems I can't avoid some of the ifdef MODULE stuff in the initialization routines in scsi.c, exactly because of the issues you mention (init builtin host adapters when scsi is also builtin) Let me know if you have any hints as what should be looked at while we are at it. I'll send you a patch soon for your comments. -- 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: [PATCH] Re: SCSI scanning]
> On Sun, 17 Sep 2000, Linus Torvalds wrote: > That's another case where the SCSI layer is module dependent. If it's a > module, we use the "init_module()" in scsi/scsi.c, and if not, we instead > use "scsi_dev_init()". They do some of the same things (well, they > obviously would have to, otherwise there wouldn't be any point to having a > init routine at all), but in general do it in very different ways for no > good reason I can see. > I agree. The scsi subsystem has been like this for ages, and I've taken the task of cleaning it up. The reason for not doing the _big_ patch right away, was because of the complextity of this paticular layer. This complexity is _not_ needed, as the recent changes to the network layer has taught us. In fact I think making the scsi layer behave more like the network layer in terms of initialization would benefit not only those hacking on scsi, but all of those maintaining scsi host drivers. > Torben, would you mind terribly expanding on your previous patch a bit, > and also cleaning this part up? As far as I can tell, we should just > remove scsi_dev_init() completely, and use the module init code with an > initcall(). Two less regions of #ifdef MODULE, and one less different > code-path to worry about.. > I'll do this. I agree about the scsi_dev_init part. We _need_ one entry point into each module (scsi/host/device). This change will actually make some code a duplicate and therefore needs to be removed which I consider a good ting. -- Regards, Torben Mathiasen - 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/
[PATCH] Re: SCSI scanning
On Sun, Sep 17 2000, Jan Niehusmann wrote:
> On Sun, Sep 17, 2000 at 09:59:30AM -0700, Linus Torvalds wrote:
> > On Sun, 17 Sep 2000, Torben Mathiasen wrote:
> > >
> > > The proper way of fixing this is to add #ifdef MODULE around the init
> > > functions or going back to init/exit_module.
> >
> > Please explain why it does it twice for compiled-in, and only once for
> > modules. There must be some other logic that does the extra
> > initializations (and that does not trigger for modules), and I'd much
> > rather just get rid of THAT thing instead.
>
> #ifdef CONFIG_BLK_DEV_SD
> scsi_register_device(&sd_template);
> #endif
>
I've attached a patch that seems to do "The Right Thing". The problem was
that the host detection routines would initialize the upper layers of scsi
drivers (sd/st/sr), and then the module_init routines would
do it again. I've removed this so now all device initialization is
done through the module_init stuff. Now this change has required all upper
layers to use this init method, and the patch therefore also updates st.
I've done some testing the last few hours with different configs to be sure
nothing breaks, but to be absolutely sure I've CC'ed Eric to verify. This
change makes the upper layers initialize a litte later when the initcall
functions are called.
--
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer
http://tlan.kernel.dk
diff -ur --exclude-from=/root/torben linux-2.4.0-test9p2/drivers/scsi/hosts.c
linux/drivers/scsi/hosts.c
--- linux-2.4.0-test9p2/drivers/scsi/hosts.cTue Jul 11 20:17:45 2000
+++ linux/drivers/scsi/hosts.c Sun Sep 17 21:28:35 2000
@@ -11,6 +11,10 @@
* Jiffies wrap fixes (host->resetting), 3 Dec 1998 Andrea Arcangeli
* Added QLOGIC QLA1280 SCSI controller kernel host support.
* August 4, 1999 Fred Lewis, Intel DuPont
+ *
+ * Updated to reflect the new initialization scheme for the higher
+ * level of scsi drivers (sd/sr/st)
+ * September 17, 2000 Torben Mathiasen <[EMAIL PROTECTED]>
*/
@@ -998,20 +1002,7 @@
printk ("scsi : %d host%s.\n", next_scsi_host,
(next_scsi_host == 1) ? "" : "s");
-/* Now attach the high level drivers */
-#ifdef CONFIG_BLK_DEV_SD
-scsi_register_device(&sd_template);
-#endif
-#ifdef CONFIG_BLK_DEV_SR
-scsi_register_device(&sr_template);
-#endif
-#ifdef CONFIG_CHR_DEV_ST
-scsi_register_device(&st_template);
-#endif
-#ifdef CONFIG_CHR_DEV_SG
-scsi_register_device(&sg_template);
-#endif
-
+
#if 0
max_scsi_hosts = next_scsi_host;
#endif
diff -ur --exclude-from=/root/torben linux-2.4.0-test9p2/drivers/scsi/sd.c
linux/drivers/scsi/sd.c
--- linux-2.4.0-test9p2/drivers/scsi/sd.c Sun Sep 17 21:23:48 2000
+++ linux/drivers/scsi/sd.c Sun Sep 17 21:26:46 2000
@@ -1335,13 +1335,13 @@
return;
}
-static int init_sd(void)
+static int __init init_sd(void)
{
sd_template.module = THIS_MODULE;
return scsi_register_module(MODULE_SCSI_DEV, &sd_template);
}
-static void exit_sd(void)
+static void __exit exit_sd(void)
{
struct gendisk **prev_sdgd_link;
struct gendisk *sdgd;
diff -ur --exclude-from=/root/torben linux-2.4.0-test9p2/drivers/scsi/st.c
linux/drivers/scsi/st.c
--- linux-2.4.0-test9p2/drivers/scsi/st.c Wed Sep 6 21:53:14 2000
+++ linux/drivers/scsi/st.c Sun Sep 17 21:27:12 2000
@@ -3700,9 +3700,7 @@
}
-#ifdef MODULE
-
-int __init init_module(void)
+static int __init init_st(void)
{
validate_options();
@@ -3710,7 +3708,7 @@
return scsi_register_module(MODULE_SCSI_DEV, &st_template);
}
-void cleanup_module(void)
+static void __exit exit_st(void)
{
int i;
@@ -3736,4 +3734,6 @@
st_template.dev_max = 0;
printk(KERN_INFO "st: Unloaded.\n");
}
-#endif /* MODULE */
+
+module_init(init_st);
+module_exit(exit_st);
Re: test9-pre1 hang when loading scsi-ide cdrom
On Sun, Sep 17 2000, Frank van de Pol wrote: > On Sat, Sep 16, 2000 at 07:27:01PM +0200, Frank van de Pol wrote: > > > > Just experienced a (reproducable) hang of the system when loading the > > drivers for my cdrom drives. (ide-cd and ide-scsi). System freezes > > completely; interupts / alt-sysreq is still working. > > > > Just before the lockup I get next message on my console: > > > > " > > scsi1 : SCSI host adapter emulation for IDE ATAPI devices > > scsi : 2 hosts. > >Vendor: E-IDE Model: CD-ROM 36X/AKU Rev: U21I > >Type: CD-ROM > > ANSI SCSI revision: 02 > > Detected scsi CD-ROM sr0 at scsi1, channel 0, id 0, lun 0 > > " > > > > I tried to compile the sr_mod without the __init & __exit but this did (as > expected) to cure the problem. > > The problem seems to reside in the ide-scsi driver; if the cdrom (sr_mod) is > not loaded, I get during initialisation of the ide-scsi module a lockup > after printing the information about the 1st host (dies after the 'Type: > CDROM' line). Probing the 2nd host seems to fail. > When did this start to happen? I sustect this is something similar to what has been happening with sd because of the module_init/exit stuff. Some people are seeing lockups because of the sd changes, going back to init_module cures it. The problems is within the scsi subsystem itself. Could you try reverting the init_sr/exit_sr to init_module/cleanup_module and removing module_init/exit please? -- 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: Ethernet Driver for Built in Network Card
On Sun, Sep 17 2000, David Ford wrote: > Craig Whitmore wrote: > > > I checked again and its a Intel 815 Board. > > Someone told me to use tulip and someone told me to use eepro > > Is this the CNR based network device? > You need to use the eepro100 driver. I've added this card in 2.2.18. If you use a 2.4.0 kernel, you can do the patch yourself by just looking at the 2.2 eepro100 driver. You only need to add the PCI ID's. -- 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: undefined reference to `scsi_register_module'
On Sun, Sep 17 2000, Mr. James W. Laferriere wrote: > > drivers/scsi/scsidrv.o: In function `init_sd': > drivers/scsi/scsidrv.o(.text+0x7326): undefined reference to > `scsi_register_module' > drivers/scsi/scsidrv.o: In function `exit_sd': > drivers/scsi/scsidrv.o(.text+0x733e): undefined reference to > `scsi_unregister_module' > drivers/scsi/scsidrv.o: In function `init_sr': > drivers/scsi/scsidrv.o(.text.init+0x385a): undefined reference to > `scsi_register_module' > make: *** [vmlinux] Error 1 > Compile error fixed in test9-pre1, working fix should go into pre2. -- 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: SCSI scanning
On Sat, Sep 16 2000, Jan Niehusmann wrote: > test9-pre1 does not contain a fix for the test8 scsi scanning problem. SCSI > disks are detected twice if scsi is not compiled as a module. Torben already > posted a patch. > Linus, The proper way of fixing this is to add #ifdef MODULE around the init functions or going back to init/exit_module. I know it looks ugly, but because of the structure of the scsi subsytem this is the only way out besides doing a nasty hack to scsi.c. And even with the hack, the initialisation functions will get called twice which is wrong. I guess the scsi subsystem is in need of an overhaul for 2.5. Patches have already been sent to you for sd (me) and sr (Jens Axboe). -- 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 SCSI doesn't compile without modules
On Wed, Sep 13 2000, Mr. James W. Laferriere wrote:
>
> Hello Torben ,
> Has anyone caught this one yet . I assume it is just the same
> patch added (manually) to sr.c/h as well ? Tia , JimL
>
> drivers/scsi/scsidrv.o: In function `init_sr':
> drivers/scsi/scsidrv.o(.text+0x1cfce): undefined reference to
> `scsi_register_module'
> drivers/scsi/scsidrv.o: In function `exit_sr':
> drivers/scsi/scsidrv.o(.text+0x1cfe0): undefined reference to
> `scsi_unregister_module'
> make: *** [vmlinux] Error 1
>
>
Probaly, I prefer to revert to good old init/cleanup_module. Forcing
the new module_init with older non compatible drivers seems wrong.
I'll look into what needs to be done to get it clean.
The patch attached goes back to the old interface, please verify its
success. I'll then send it to Linus for test9-p1.
--
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer
http://tlan.kernel.dk
diff -ur linux-2.4.0-test8/drivers/scsi/sr.c linux/drivers/scsi/sr.c
--- linux-2.4.0-test8/drivers/scsi/sr.c Wed Sep 13 23:24:42 2000
+++ linux/drivers/scsi/sr.c Wed Sep 13 23:54:26 2000
@@ -849,13 +849,15 @@
return;
}
-int init_sr(void)
+#ifdef MODULE
+
+int init_module(void)
{
sr_template.module = THIS_MODULE;
return scsi_register_module(MODULE_SCSI_DEV, &sr_template);
}
-void exit_sr(void)
+void cleanup_module(void)
{
scsi_unregister_module(MODULE_SCSI_DEV, &sr_template);
devfs_unregister_blkdev(MAJOR_NR, "sr");
@@ -879,5 +881,4 @@
sr_template.dev_max = 0;
}
-module_init(init_sr);
-module_exit(exit_sr);
+#endif /* MODULE */
Re: 2.4.0 SCSI doesn't compile without modules
On Wed, Sep 13 2000, Anton Altaparmakov wrote: > Just discovered that if you try to compile 2.4.0-test8 without module > support then the compilation (or linking to be more exact) fails at: > > drivers/scsi/scsidrv.o: In function 'init_sd': > drivers/scsi/scsidrv.o(.text+0x1efa): undefined reference to > 'scsi_register_module' > drivers/scsi/scsidrv.o: In function 'exit_sd': > drivers/scsi/scsidrv.o(.text+0x1f12): undefined reference to > 'scsi_unregister_module' > > I have attached the .config file with which this happens... > Check the list, patch already posted. -- 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: SCSI scan problem in 2.4test8
On Wed, Sep 13 2000, Matthew Kirkwood wrote:
> Hi,
>
> 2.4 seems to have problems scanning SCSI busses. It
> looks rather like it is scanning the first bus for
> every host that it finds.
>
> My dmesg is attached. In my dual-P3 box, I have three
> disks on the first channel of an on-board aic7xxx:
>
> $ cat /proc/scsi/scsi
> Attached devices:
> Host: scsi0 Channel: 00 Id: 00 Lun: 00
> Vendor: QUANTUM Model: ATLAS IV 9 WLS Rev: 0909
> Type: Direct-AccessANSI SCSI revision: 03
> Host: scsi0 Channel: 00 Id: 01 Lun: 00
> Vendor: QUANTUM Model: ATLAS IV 9 WLS Rev: 0909
> Type: Direct-AccessANSI SCSI revision: 03
> Host: scsi0 Channel: 00 Id: 02 Lun: 00
> Vendor: QUANTUM Model: ATLAS IV 9 WLS Rev: 0909
> Type: Direct-AccessANSI SCSI revision: 03
>
Could you try out this patch. The module_init/exit stuff in sd.c
has given some people a real headache.
--
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer
http://tlan.kernel.dk
diff -ur --exclude-from=/root/torben linux-2.4.0-test8/drivers/scsi/sd.c
linux/drivers/scsi/sd.c
--- linux-2.4.0-test8/drivers/scsi/sd.c Sun Sep 10 11:55:58 2000
+++ linux/drivers/scsi/sd.c Sun Sep 10 12:07:09 2000
@@ -1335,12 +1335,14 @@
return;
}
-int init_sd(void)
+#ifdef MODULE
+
+int init_module(void)
{
sd_template.module = THIS_MODULE;
return scsi_register_module(MODULE_SCSI_DEV, &sd_template);
}
-void exit_sd(void)
+void cleanup_module(void)
{
struct gendisk **prev_sdgd_link;
struct gendisk *sdgd;
@@ -1388,5 +1390,4 @@
kfree(sd_gendisks);
}
-module_init(init_sd);
-module_exit(exit_sd);
+#endif /* MODULE */
Re: Update Linux 2.4 Status/TODO list
On Wed, Sep 13 2000, [EMAIL PROTECTED] wrote: > * Loading the qlogicfc driver in 2.4.0-test8 causes the kernel to >loop forver reporting SCSI disks that aren't present (Paul >Hubbard) This is probaly due to the module_init/exit stuff that got into test8. I have already sent Linus a patch, but I still need to verify this with Paul Hubbard. -- 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: Update Linux 2.4 Status/TODO list
On Wed, Sep 13 2000, [EMAIL PROTECTED] wrote: > * TLAN nic appears to be adding a timer twice (2.4.0test8pre6, Arjan >ve de Ven) This has been fixed, just not sent off to Linus yet. -- 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: Scsi disks duplicated
On Sat, Sep 09 2000, Jan Niehusmann wrote: > With linux-2.4.0-test8, all my scsi disks appear duplicated: > > Detected scsi disk sda at scsi0, channel 0, id 3, lun 0 > [...] > Detected scsi disk sdb at scsi0, channel 0, id 4, lun 0 > [...] > Detected scsi disk sdc at scsi0, channel 0, id 3, lun 0 > [...] > Detected scsi disk sdd at scsi0, channel 0, id 4, lun 0 > > I think this is caused by the addition of module_init(init_sd); > at the end of drivers/scsi/sd.c. > This seems to some kind of scsi weirdness. Jens reports its the same with sr. Maybe Eric have a comment on this? -- 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: [PATCH] af_netrom.c: do resource release on failure
On Fri, Sep 08 2000, Marcelo Tosatti wrote: > > On Fri, 8 Sep 2000, Torben Mathiasen wrote: > > > On Fri, Sep 08 2000, Arnaldo Carvalho de Melo wrote: > > > Hi, > > > > > > Please take a look and consider applying. Some of it are small cleanups, if > > > they're deemed unnecessary, lemme now and I'm back it off. I think that there > > > are some more unchecked calls that need fixing, but I think its better to keep > > > the patches smaller and incremental, what do you think? > > > > > > > How about converting the cli() code to spin_locks while we are at it? > > ipx is using cli() too. > Mmmm, any reason for this besides just lazyness? I'd hate to do it, cause I'd hate to test it 8) -- 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: [PATCH] af_netrom.c: do resource release on failure
On Fri, Sep 08 2000, Arnaldo Carvalho de Melo wrote: > Hi, > > Please take a look and consider applying. Some of it are small cleanups, if > they're deemed unnecessary, lemme now and I'm back it off. I think that there > are some more unchecked calls that need fixing, but I think its better to keep > the patches smaller and incremental, what do you think? > How about converting the cli() code to spin_locks while we are at it? -- 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/
[PATCH] sd.c Resource allocation fixes + cleanups
Linus and others,
Please take a look at the patch attached, and consider applying. It fixes
some of the OOM issues with sd.c and does general cleanups (module_init/exit,
removing casts, etc.).
I just searched the archives and found that Arnaldo Carvalho de Melo submitted
a similar patch for test7-pre7 that didn't get in. Please let me know if
something is missing from this one, or if Analdo is currently working on this.
Patch is against test8-pre6
--
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer
http://tlan.kernel.dk
diff -ur --exclude-from=/root/torben linux-2.4.0-test8p6/drivers/scsi/sd.c
linux/drivers/scsi/sd.c
--- linux-2.4.0-test8p6/drivers/scsi/sd.c Thu Sep 7 10:25:29 2000
+++ linux/drivers/scsi/sd.c Thu Sep 7 13:05:13 2000
@@ -19,6 +19,9 @@
* scsi disks using eight major numbers.
*
* Modified by Richard Gooch [EMAIL PROTECTED] to support devfs.
+ *
+ * Modified by Torben Mathiasen [EMAIL PROTECTED]
+ * Resource allocation fixes in sd_init and cleanups.
*/
#include
@@ -1039,16 +1042,24 @@
if (rscsi_disks)
return 0;
- rscsi_disks = (Scsi_Disk *)
- kmalloc(sd_template.dev_max * sizeof(Scsi_Disk), GFP_ATOMIC);
+ rscsi_disks = kmalloc(sd_template.dev_max * sizeof(Scsi_Disk), GFP_ATOMIC);
+ if (!rscsi_disks)
+ goto cleanup_devfs;
memset(rscsi_disks, 0, sd_template.dev_max * sizeof(Scsi_Disk));
/* for every (necessary) major: */
- sd_sizes = (int *) kmalloc((sd_template.dev_max << 4) * sizeof(int),
GFP_ATOMIC);
+ sd_sizes = kmalloc((sd_template.dev_max << 4) * sizeof(int), GFP_ATOMIC);
+ if (!sd_sizes)
+ goto cleanup_disks;
memset(sd_sizes, 0, (sd_template.dev_max << 4) * sizeof(int));
- sd_blocksizes = (int *) kmalloc((sd_template.dev_max << 4) * sizeof(int),
GFP_ATOMIC);
- sd_hardsizes = (int *) kmalloc((sd_template.dev_max << 4) * sizeof(int),
GFP_ATOMIC);
+ sd_blocksizes = kmalloc((sd_template.dev_max << 4) * sizeof(int), GFP_ATOMIC);
+ if (!sd_blocksizes)
+ goto cleanup_sizes;
+
+ sd_hardsizes = kmalloc((sd_template.dev_max << 4) * sizeof(int), GFP_ATOMIC);
+ if (!sd_hardsizes)
+ goto cleanup_blocksizes;
for (i = 0; i < sd_template.dev_max << 4; i++) {
sd_blocksizes[i] = 1024;
@@ -1059,22 +1070,29 @@
blksize_size[SD_MAJOR(i)] = sd_blocksizes + i * (SCSI_DISKS_PER_MAJOR
<< 4);
hardsect_size[SD_MAJOR(i)] = sd_hardsizes + i * (SCSI_DISKS_PER_MAJOR
<< 4);
}
- sd = (struct hd_struct *) kmalloc((sd_template.dev_max << 4) *
+ sd = kmalloc((sd_template.dev_max << 4) *
sizeof(struct hd_struct),
GFP_ATOMIC);
+ if (!sd)
+ goto cleanup_sd;
memset(sd, 0, (sd_template.dev_max << 4) * sizeof(struct hd_struct));
if (N_USED_SD_MAJORS > 1)
- sd_gendisks = (struct gendisk *)
- kmalloc(N_USED_SD_MAJORS * sizeof(struct gendisk), GFP_ATOMIC);
+ sd_gendisks = kmalloc(N_USED_SD_MAJORS * sizeof(struct gendisk),
+GFP_ATOMIC);
+ if (!sd_gendisks)
+ goto cleanup_sd_gendisks;
for (i = 0; i < N_USED_SD_MAJORS; i++) {
sd_gendisks[i] = sd_gendisk;
sd_gendisks[i].de_arr = kmalloc (SCSI_DISKS_PER_MAJOR * sizeof
*sd_gendisks[i].de_arr,
GFP_ATOMIC);
+ if (!sd_gendisks[i].de_arr)
+ goto cleanup_gendisks_de_arr;
memset (sd_gendisks[i].de_arr, 0,
SCSI_DISKS_PER_MAJOR * sizeof *sd_gendisks[i].de_arr);
sd_gendisks[i].flags = kmalloc (SCSI_DISKS_PER_MAJOR * sizeof
*sd_gendisks[i].flags,
GFP_ATOMIC);
+ if (!sd_gendisks[i].flags)
+ goto cleanup_gendisks_flags;
memset (sd_gendisks[i].flags, 0,
SCSI_DISKS_PER_MAJOR * sizeof *sd_gendisks[i].flags);
sd_gendisks[i].major = SD_MAJOR(i);
@@ -1091,6 +1109,31 @@
LAST_SD_GENDISK.next = NULL;
return 0;
+
+cleanup_gendisks_flags:
+ kfree(sd_gendisks[i].de_arr);
+cleanup_gendisks_de_arr:
+ while (--i >= 0 ) {
+ kfree(sd_gendisks[i].de_arr);
+ kfree(sd_gendisks[i].flags);
+ }
+ kfree(sd_gendisks);
+cleanup_sd_gendisks:
+ kfree(sd);
+cleanup_sd:
+ kfree(sd_hardsizes);
+cleanup_blocksizes:
+ kfree(sd_blocksizes);
+cleanup_sizes:
+ kfree(sd_sizes);
+cleanup_disks:
+ kfree(rscsi_disks);
+cleanup_devfs:
+
[PATCH]: TLAN EISA support + PCI fixes
This patch (against 2.4.0-test7 and later) take the tlan driver to v1.10
and has the following fixes/enhancements:
Support for EISA controllers
New PCI probe layout
Other fixes (see patch).
Currently only the Compaq NetFlex-3/E controller is supported, and as I
only had access to one, it might not find your controller. If it dosen't
please load the driver with "insmod tlan debug=0x10" and send me the output.
You'll be able to check if you EISA board was found by watching "dmesg" output.
The driver should report something similar to this:
ThunderLAN driver v1.10
TLAN: eth0 irq=11, io=70a0, Compaq Netelligent 10/100 TX PCI UTP, Rev. 16
TLAN: eth1 irq= 9, io=3000, Compaq NetFlex-3/E, Rev. 0
TLAN: 2 devices installed, PCI: 1 EISA: 1
Please note this driver version is experimental. Some issues are
still left (timers on SMP, revision, etc.).
Have fun.
--
Torben Mathiasen
Linux ThunderLAN maintainer
http://tlan.kernel.dk
diff -ur linux-2.4.0-test7/drivers/net/tlan.c linux/drivers/net/tlan.c
--- linux-2.4.0-test7/drivers/net/tlan.cThu Aug 31 13:48:07 2000
+++ linux/drivers/net/tlan.cThu Aug 31 14:26:43 2000
@@ -98,10 +98,28 @@
* v1.8a May 28, 2000 - Minor updates.
*
* v1.9 July 25, 2000 - Fixed a few remaining Full-Duplex issues.
- * - Updated with timer fixes from Andrew Morton.
- * - Fixed module race in TLan_Open.
- * - Added routine to monitor PHY status.
- * - Added activity led support for Proliant devices.
+ * - Updated with timer fixes from Andrew Morton.
+ * - Fixed module race in TLan_Open.
+ * - Added routine to monitor PHY status.
+ * - Added activity led support for Proliant devices.
+ *
+ * v1.10 Aug 30, 2000 - Added support for EISA based tlan controllers
+ *like the Compaq NetFlex3/E.
+ * - Rewrote tlan_probe to better handle multiple
+ *bus probes. Probing and device setup is now
+ *done through TLan_Probe and TLan_init_one. Actual
+ *hardware probe is done with kernel API and
+ *TLan_EisaProbe.
+ * - Adjusted debug information for probing.
+ * - Fixed bug that would cause general debug information
+ *to be printed after driver removal.
+ * - Added transmit timeout handling.
+ * - Fixed OOM return values in tlan_probe.
+ * - Fixed possible mem leak in tlan_exit
+ *(now tlan_remove_one).
+ * - Fixed timer bug in TLan_PhyMonitor.
+ * - This driver version is alpha quality, please
+ *send me any bug issues you may encounter.
*
***/
@@ -121,8 +139,9 @@
typedef u32 (TLanIntVectorFunc)( struct net_device *, u16 );
+/* For removing EISA devices */
+static struct net_device *TLan_Eisa_Devices = NULL;
-static struct net_device *TLanDevices = NULL;
static int TLanDevicesInstalled = 0;
/* Force speed, duplex and aui settings */
@@ -144,7 +163,10 @@
static int bbuf = 0;
static u8 *TLanPadBuffer;
static charTLanSignature[] = "TLAN";
-static const char *tlan_banner = "ThunderLAN driver v1.9\n";
+static const char *tlan_banner = "ThunderLAN driver v1.10\n";
+static int tlan_have_pci = 0;
+static int tlan_have_eisa = 0;
+static int manual_priv = 0;
const char *media[] = {
"10BaseT-HD ", "10BaseT-FD ","100baseTx-HD ",
@@ -153,103 +175,72 @@
int media_map[] = { 0x0020, 0x0040, 0x0080, 0x0100, 0x0200,};
-static TLanAdapterEntry TLanAdapterList[] __initdata = {
- { PCI_VENDOR_ID_COMPAQ,
- PCI_DEVICE_ID_NETELLIGENT_10,
- "Compaq Netelligent 10 T PCI UTP",
- TLAN_ADAPTER_ACTIVITY_LED,
- 0x83
- },
- { PCI_VENDOR_ID_COMPAQ,
- PCI_DEVICE_ID_NETELLIGENT_10_100,
- "Compaq Netelligent 10/100 TX PCI UTP",
- TLAN_ADAPTER_ACTIVITY_LED,
- 0x83
- },
- { PCI_VENDOR_ID_COMPAQ,
- PCI_DEVICE_ID_NETFLEX_3P_INTEGRATED,
- "Compaq Integrated NetFlex-3/P",
- TLAN_ADAPTER_NONE,
- 0x83
- },
- { PCI_VENDOR_ID_COMPAQ,
- PCI_DEVICE_ID_NETFLEX_3P,
- "Compaq NetFlex-3/P",
- TLAN_ADAPTER_UNMANAGED_PHY | TLAN_ADAPTER_BIT_RATE_PHY,
- 0x83
- },
- { PCI_VEN
