Hi All,
Is there any reason why the floppy module requires the ioport range
0x3f0-0x3f1 in order to load? On my computer /proc/ioports reports this
range as used by PnPBIOS PNP0c02, thus the floppy module cannot reserve
the range 0x3f0-0x3f5 and refuses to load.
I have taken a quick look at the port specification of the FDC and have
found no readon for any access to the 0x3f0 port, I have found a reason
for accessing the 0x3f1 port - but only on PS/2's. This ain't a PS/2 so
that is irrelevant. Furthermore analysis of the code fails to find any
place where these two ports would actually be used...
Deciding to take a try at it I changed the floppy module to reserve only
the 0x3f2-0x3f5 and 0x3f7 ports, recompiled and the module now loads.
I have not done any tests on it, however copying a diskette via mcopy,
mdir and plain old mount worked fine.
All in all I would say that at least in my case there is no reason for
floppy to reserve these two ports - I don't know about other machines
(especially PS/2's) - but I cannot see any use of them in the source code
any way.
Questions, Ideas?
Maciej Zenczykowski
> Is there any reason why the floppy module requires the ioport range
> 0x3f0-0x3f1 in order to load? On my computer /proc/ioports reports this
> range as used by PnPBIOS PNP0c02, thus the floppy module cannot reserve
> the range 0x3f0-0x3f5 and refuses to load.
This is a bug in the PnPBIOS experimental code - turn off PnPBIOS and/or
update for the moment
Alan Cox wrote:
> Maciej Zenczykowski wrote:
>> Is there any reason why the floppy module requires
>> the ioport range 0x3f0-0x3f1 in order to load? On
>> my computer /proc/ioports reports this range as used
>> by PnPBIOS PNP0c02, thus the floppy module cannot
>> reserve the range 0x3f0-0x3f5 and refuses to load.
>
> This is a bug in the PnPBIOS experimental code -
> turn off PnPBIOS and/or update for the moment
A fix for this problem went in to 2.4.13-ac2. Please
try that kernel (or a later -ac kernel) and report back.
--
Thomas
On 2 Nov 2001, Thomas Hood wrote:
> Alan Cox wrote:
> > Maciej Zenczykowski wrote:
> >> Is there any reason why the floppy module requires
> >> the ioport range 0x3f0-0x3f1 in order to load? On
> >> my computer /proc/ioports reports this range as used
> >> by PnPBIOS PNP0c02, thus the floppy module cannot
> >> reserve the range 0x3f0-0x3f5 and refuses to load.
> >
> > This is a bug in the PnPBIOS experimental code -
> > turn off PnPBIOS and/or update for the moment
>
> A fix for this problem went in to 2.4.13-ac2. Please
> try that kernel (or a later -ac kernel) and report back.
Well just tried kernel 2.4.13-ac6 and there is absolutely no difference.
After applying the attached patch all works OK...
Maciej Zenczykowski
nb. modprobe rivafb leaves the kernel's idea of whats on screen out of
sync with the truth. i.e. modprobe rivafb on tty2 and you end up with
tty1 on the screen, but keypresses going to tty2...
On Sun, 2001-11-04 at 19:00, Maciej Zenczykowski wrote:
> > A fix for this problem went in to 2.4.13-ac2. Please
> > try that kernel (or a later -ac kernel) and report back.
>
> Well just tried kernel 2.4.13-ac6 and there is absolutely no difference.
>
> After applying the attached patch all works OK...
>
> Maciej Zenczykowski
>
> nb. modprobe rivafb leaves the kernel's idea of whats on screen out of
> sync with the truth. i.e. modprobe rivafb on tty2 and you end up with
> tty1 on the screen, but keypresses going to tty2...
What I would like to know is: What is at 0x3f0-0x3f1 on
your machine, and why does your PnP BIOS list these
two ioports as used by "system peripheral: other"?
On my ThinkPad 600, the BIOS lists 0x3f0-0x3f5 as owned
by the floppy device:
jdthood@thanatos:~$ sudo lspnp -v 08
08 PNP0700 mass storage device: floppy
irq 6
io 0x03f0-0x03f5
dma 2
It looks like there's a bug in your BIOS. What we could do is
patch the PnP BIOS driver so that it refrains from reserving
0x3f0-0x3f1.
I'll let others comment on the appropriateness of your patch
to floppy.c . I don't know whether it's the right thing to
do or not.
--
Thomas Hood
Well here you have it...
W98SE reports the FDC at 0x3f0..0x3f5 and 0x3f7
all in all it is very weird and I do not know what to make of it...
[ABIT SA6 motherboard with AWARD bios]
>
> What I would like to know is: What is at 0x3f0-0x3f1 on
> your machine, and why does your PnP BIOS list these
> two ioports as used by "system peripheral: other"?
>
> On my ThinkPad 600, the BIOS lists 0x3f0-0x3f5 as owned
> by the floppy device:
> jdthood@thanatos:~$ sudo lspnp -v 08
> 08 PNP0700 mass storage device: floppy
> irq 6
> io 0x03f0-0x03f5
> dma 2
>
> It looks like there's a bug in your BIOS. What we could do is
> patch the PnP BIOS driver so that it refrains from reserving
> 0x3f0-0x3f1.
>
> I'll let others comment on the appropriateness of your patch
> to floppy.c . I don't know whether it's the right thing to
> do or not.
>
> --
> Thomas Hood
>
>
On Sun, 2001-11-04 at 20:18, Maciej Zenczykowski wrote:
> Well here you have it...
>
> W98SE reports the FDC at 0x3f0..0x3f5 and 0x3f7
That's what the ThinkPad 600 technical reference
manual says about my machine too.
> all in all it is very weird and I do not know what to make of it...
> [ABIT SA6 motherboard with AWARD bios]
Well, if the floppy driver never accesses 0x3f0 or 0x3f1,
then it would seem that it should not reserved those
ioports.
--
Thomas
On Sun, 2001-11-04 at 20:18, Maciej Zenczykowski wrote:
> W98SE reports the FDC at 0x3f0..0x3f5 and 0x3f7
In hw reference manuals I have looked at, the floppy
ioport range is listed as either 0x3f0-0x3f5 or
0x3f0-0x3f5,0x3f7 or 0x3f0-0x3f7.
0x3f6 is used by some IDE controllers, so it should
not be included in the range. Floppy controller
chips don't use this ioport.
Now I'm looking at the refence for the National Semi
87338 Super I/O chip which among other things emulates
a standard IBM-style floppy controller. It says:
0x3f0,0x3f1 are status registers that were added
to the PS/2. They do not exist on the PC-AT.
The 87338 uses these addresses only in "PS/2 mode",
not in "PC-AT" mode.
0x3f2 (*) is a digital output register
0x3f3 is a "tape drive register". Bring this one into
the Antiques Roadshow!
0x3f4 (*) is the main status register (r)
and data rate select register (w)
0x3f5 (*) is the data register FIFO
0x3f7 (*) is the digital input register (r)
and configuration control register (w)
When I look at the floppy driver itself, it reserves
0x3f0-0x3f5,0x3f7 but only uses 0x3f2, 0x3f4, 0x3f5, 0x3f7
(indicated above with an asterisk). See include/linux/fdreg.h.
I would suggest that the driver refrain from reserving
0x3f0-0x3f1 since not all floppy driver chips take up these
ioports and the Linux driver doesn't use them either.
Maciej: perhaps on your machine the motherboard uses 0x3f0-0x3f1
for some other (secret, highly classified) purpose. Have you
read your hardware reference manual?
--
Thomas
> Well here you have it...
>
> W98SE reports the FDC at 0x3f0..0x3f5 and 0x3f7
Its absolutely correct. 0x3f6 isnt floppy. That I suspect is what
is causing the problem because it tries to grab 0x3f6 in Linux
On Mon, 5 Nov 2001, Alan Cox wrote:
> > Well here you have it...
> > W98SE reports the FDC at 0x3f0..0x3f5 and 0x3f7
>
> Its absolutely correct. 0x3f6 isnt floppy. That I suspect is what
> is causing the problem because it tries to grab 0x3f6 in Linux
No Linux doesn't grab 0x3f6 - what it grabs is 0x3f0-0x3f5 and 0x3f7 -
exactly as reported by w98 - however 0x3f0-0x3f1 have already been
reserved by the pnpbios code, since they are listed in the bios as
motherboard resources, while 0x3f2-03xf5 and 03xf7 are listed as floppy
-> the problem is that the floppy reserves ports that it does not need (in
fact it could skip reserving 0x3f3 also...)
On 4 Nov 2001, Thomas Hood wrote:
>
> Maciej: perhaps on your machine the motherboard uses 0x3f0-0x3f1
> for some other (secret, highly classified) purpose. Have you
> read your hardware reference manual?
>
I did that before posting the previous time - beautiful over 100 page
manual - but no mention of 03xf0-0x3f1 being special and can't find them
in any bios setup screens either...
Maciej Zenczykowski wrote:
>
> On 4 Nov 2001, Thomas Hood wrote:
> >
> > Maciej: perhaps on your machine the motherboard uses 0x3f0-0x3f1
> > for some other (secret, highly classified) purpose. Have you
> > read your hardware reference manual?
> >
> I did that before posting the previous time - beautiful over 100 page
> manual - but no mention of 03xf0-0x3f1 being special and can't find them
> in any bios setup screens either...
Diagnosis:
----------
Your PNPBIOS announces these ports:
0c PNP0c02 Motherboard resources
io 0x03f0-0x03f1
These ports are used by various SuperIO chips, e.g.Winbond W83877ATF:
8.2 Extended Function Index Registers (EFIRs), Extended Function Data Registers(EFDRs)
After the extended function mode is entered, the Extended Function Index Register (EFIR) must be
loaded with an index value (0H, 1H, 2H, ..., or 29H) to access Configuration Register 0 (CR0),
Configuration Register 1 (CR1), Configuration Register 2 (CR2), and so forth through the Extended
Function Data Register (EFDR). The EFIRs are write-only registers with port address 251H or 3F0H
(as described in section 8.0) on PC/AT systems; the EFDRs are read/write registers with port address
252H or 3F1H (as described in section 8.0) on PC/AT systems. The function of each configuration
register is described ...
You have to write various magic vendor defined values to
vendor defined ports to enable "extended function mode" :-)
http://home.t-online.de/home/gunther.mayer/lssuperio-0.63.tar.gz will
identify your chip sitting at 0x3f0/0x3f1 !
Solution:
---------
PnPBIOS in linux should _not_ reserve these 2 ports (this kind of
solution is commonly called a quirks).
On Tue, 6 Nov 2001, Gunther Mayer wrote:
> Solution:
> ---------
> PnPBIOS in linux should _not_ reserve these 2 ports (this kind of
> solution is commonly called a quirks).
Actually, you may be right that it should not, however the floppy module
should not allocate these ports `with an even more sure` as it never uses
them.
Think this is the proper solution?
MaZe.
On Tue, 2001-11-06 at 15:02, Gunther Mayer wrote:
> Solution:
> ---------
> PnPBIOS in linux should _not_ reserve these 2 ports (this kind of
> solution is commonly called a quirks).
That would work. However the more appropriate solution would
seem to be for the floppy driver not to try to reserve them,
since it doesn't use them, and (judging from what you say)
on some machines they have nothing to do with the floppy
drive.