I attempted a text dd install and the installer refuses to either scan base addresses or accept my input for sbpcd=0x230,1. I cross tested on the 7.0 installer and when I dont provided a base address it scans and finds the cd-rom. Rebooting to 7.0 allows me to mount the cd-drive w/o any errors.
Did an NFS text install instead and got the system up and running. The sbpcd.o provided only scans for 0x340 and then gives up despite entries in modules.conf and gives me a: no drive found /dev/cdrom has a wrong major or minor number (that was against ln -s sbpcd cdrom) /dev/sbpcd has a wrong major or minor number. Happy Yule.
Assigning to a developer with sbpcd experience.
Addendum: I have compared the source code from kernel.org (2.4) and the beta1 stuff and they are identical. I have also contacted the maintainer as the version in question is 4.63 of sbpcd.c and I know that sbpcd.c (v4.61) in the 2.2.16 series (rh70) does work. This was done w/o reference to being on the Beta Team.
Have you provided the driver command-line parameters to force it to look lower?
Yes, didnt you read the entire bug report? "or accept my input for sbpcd=0x230,1." Version 4.63 of sbpcd.c errors out if you do not provide command line parameters. Version 4.61 (2.2.16-22) will probe all addresses if no command line or module.conf parameters are set.
When you select the module, have you selected the checkbox to specfiy module parameters?
OK let's do this step by step, since I dont seem to be clear enough to you on this. (likely my fault) 1. Attempt beta1 install with a text dd 2. Select cd-rom, select ok based on spbcd.c v4.61 autoprobe behavior (it fails, new behavior "requires" input parameters) 3. Second install attempt. 4. Provide input parameters and yes checkmark module parameters. 5. It probes only and only 0x340 (ignoring my input of 0x230,1) and fails. 6. Do an NFS install of beta1 7. Attempt to load sbpcd.o with modules.conf settings and / or manual insmod sbpcd.o sbpcd=0x230,1 8. It probes only and only 0x340 and fails. 9. Compare source code for rpm and linux.org source code (identical v 4.63 of sbpcd.c) and that of srpm of 2.2.18-22 (ver 4.61 of sbpcd.c). The first time I did this I reverted back to a re-install of RH7.0 where the sbpcd does work. Then did the beta1 all over again to document all the steps. There is something wrong with the source code as provided by the maintainer/developer of the legacy cd-rom source code. From what I am reading he is a new maintainter replacing emonke. I am recompiling the new code (4.63) as I type and if it fails I will attempt to revert to 4.61 of sbpcd.c. and if that fails ( I may need to modify to make it compile under 2.4) Enclosed is the template for this machine as submitted to beta-hw: Machine ID/name: #4/shonjir CPU: 486 1 Memory: 16MB 1 Motherboard: N/A 1 Video: Trident 1MB SVGA 1 Storage: WDC AC13200B 3098MB IDE 1 CD-Rom: Panasonic CR-563 5 * Network: 3c503 Etherlink II-TP ISA 2 lspci: N/A lspci -n: N/A Bugzilla entries: 22755 sbpcd.o no longer detects at base address 0x230 installer/kernel-drivers * Works in all releases from RH7 back.
This defect is considered MUST-FIX for Florence Gold release
Addendum. I have contact the developer/maintainer(Andrew Kroll) of the legacy cdroms and he thinks it may be an issue with modutils and is setting up a crash box. Apparently I wasnt the only one that has reported this problem. I made no mention of beta testing and pitched this a person running rawhide. He has set up a news site http://legacy.dr.ea.ms for updates.
Doesnt work under beta2. Didnt expect it to work bacause of the timing between version releases and no new input from devloper/maintainer.
This isn't an anaconda problem as it doesn't work normally either.
Maybe the "1" is confusing it; the moddule currently has instructions that look like this: * use: tell LILO: * sbpcd=0x230,SoundBlaster * or * sbpcd=0x300,LaserMate * or * sbpcd=0x338,SoundScape * or * sbpcd=0x2C0,Teac16bit Can you see if that works?
The "1" is not confusing. Further down in the sbpcd.h file you will note that the proper syntax for insmod is 0x230,1. What you are looking at is for lilo. Since the installer failed to find the cd I was forced to do an NFS install and afterward the insmod fails. I have appended the 0x230,SoundBlaster to lilo as you requested and rebooted the machine. Scanning begins at 0x340 and ignores any other provided value. And fails.
Thanks, sorry for the confusion.
This defect has been re-classified as MUST-FIX for Florence Release-Candidate #1
I don't think this is a modutils problem, since 2.3.17 gives the same behaviour as 2.4.2 for me. Not that I actually have one of these drives, but 'modprobe sbpcd sbpcd=0x230,1' puts two 'probing 0x340' messages in the kernel ring buffer for both modutils versions.
I am bumping this to beta3 as it still fails as defined and the developer/maintainer states on his web site: Jan 31, 2001: Crash box is nearly set to go, just lacking disk space. Patch recieved from Paul Gortmaker, to be released after full review and it's impact on older kernels. A test replacement c file or and patch will be available on this web page.
The sbpcd driver didn't parse it's arguments. Fix is in the next build. (2.4.1-0.1.9 or later). Please reopen this bug if this is not fixed in a such a build.
Unable to verify because of #29143
I am re-opening this under RC1 because it was broken there too, however the nightly build diskettes worked just fine so I will change this this to an RFE because one cannot assume that everyone knows their base address of the cdrom drive. I have two of these and they are both set to 0x230,1 (I like consistency in hardware). Until RH70 this would auto probe all the supported base addresses. I think that the chocie would be good. If supply module parameters is not selected probe all addresses (which is the normal behaviour on insmod/modprobe anyway) or if they know it let 'em put it in.