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.

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.

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.

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.

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.

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.

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.

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.

Note

You need to
log in
before you can comment on or make changes to this bug.