apparent need to blacklist Lexar flash drive in ide-dma.c

apparent need to blacklist Lexar flash drive in ide-dma.c

[kilgota]

I am trying to set up a rather weird piece of hardware to run Linux. 
The machine is an old Compaq IA-1 internet appliance, containing 32 meg of 
RAM and a K6-2-266 CPU, with VIA Apollo chipset on board. The machine has 
an internal flash drive consisting of a Sandisk SP3B-16 (16 megabytes) 
which is apparently a chip or chips permanently attached to the board and 
which contained an installation of WinCE which would do nothing except to 
boot and to attempt to connect to MSN.

The machine's BIOS "sees" the SP3B-16 as drive "C" and the default BIOS 
setting is to boot from it.

The  machine also contains an interface into which a CF card can be 
plugged, and if you put one there it is seen as the "D" drive (/dev/hdc in 
Linux). The BIOS also allows the possibility to boot from "D". The BIOS 
also has settings, whiich can be toggled, for

"IDE Drive Translation" (what this was supposed to mean I have no idea 
and I can see no practical difference if it is enabled or disabled)

"Enhanced IDE Transfer" (I would assume this means the pio mode can be 
enhanced)

"Ultra 33/66" (I would assume this means UDMA 33 or 66)

So, feeling adventurous, I went and bought a CF card on which is written

Lexar 2GB Compact Flash Platinum II 80x

and ran fdisk, creating a large partition re-formatted with Reiserfs on 
which I did an installation and a small one for swap, installed a 2.6.22.3 
kernel and LILO, and set the machine's BIOS to boot from "D".

Aside from some issues which are relevant for some other list (relating to 
issues with a USB keyboard and mouse), the machine boots. With DMA support 
for the VIA Apollo chip built in, the kernel while booting sees the SP3B 
first, of course, gives a couple of access errors, then duly blacklists 
it, and there are no further problems with that one. However, the Lexar 
gave repeated DMA errors and tried 3 times during the boot process to set 
up the DMA for the Lexar CF card and finally gave up and booted with DMA 
disabled. The only way to stop this rather agonizing and lengthy process 
was either to use the boot option ide=nodma or, more permanently, to put a 
line like this

         {"LEXAR ATA FLASH",             "ALL"},

into the blacklist in drivers/ide/ide-dma.c (note that "LEXAR ATA FLASH" 
is the way the drive is seen during the bootup messages).

To do this blacklisting essentially stops the problem while booting, but 
of course the "drive" is then not accessed with any DMA.

Under the circumstances, I am of course uncertain whether the "ALL" is 
appropriate or not, but I suspect it is. So perhaps you would like to add 
this entry to the blacklist.

I also remain rather puzzled that the BIOS in this machine had EIDE 
transfer and UDMA 33/66 turned on when I got the machine, and WinCE did 
not seem to have any big problems with that. Perhaps WinCE simply ignores 
those settings? I dunno. I do not claim to know much about WinCE.

Finally, when doing research about this problem, I came across a rather 
long thread on the kernel mailing list which related to the SP3B and its 
problems with DMA. I recall that this thread pretty much petered out 
without coming to any firm resolution of whether there is any solution to 
the problem. It seemed that one of the fundamental problems was the way 
the device is "seen". Namely, is it some kind of flash device, or is it an 
ordinary hard drive? And is it possible to use DMA with a flash device or 
not? Does it make any difference if the device is removable, or not? That 
kind of thing.

But at any rate, to say again what is seen here:

The BIOS says that the SP3B (which is not removable and is so physically 
inobtrusive that I could actually not even find it when I took the machine 
apart!) is the equivalent of /dev/hda, and the booting Linux kernel sees 
it as such, too.

The BIOS says that the LEXAR (which is obviously removable) is the 
equivalent of /dev/hdc, and the booting Linux kernel sees it as such, too.

The BIOS seems to think that DMA should work, but it doesn't, at least 
neither with the SP3B soldered on the board nor with the Lexar flash drive 
put in the CF slot.

Access to both of these devices is through the Linux IDE interface. I can 
imagine that it might be somehow superior to access them as flash devices, 
but it is difficult for me to visualize how to do that if the BIOS thinks 
they are "ordinary" IDE hard drives.

So you have a possible suggestion for the blacklist, or in the alternative 
or as well as that, some questions which might possibly be interesting. 
Frankly, I hope that some of the questions are interesting.

Theodore Kilgore

Re: apparent need to blacklist Lexar flash drive in ide-dma.c

[Alan Cox]

> "Ultra 33/66" (I would assume this means UDMA 33 or 66)

If it is cabled for it, DMA capable CF is quite new and that seems to
cause problems sometimes.

> Under the circumstances, I am of course uncertain whether the "ALL" is 
> appropriate or not, but I suspect it is. So perhaps you would like to add 
> this entry to the blacklist.

The problem is almost certainly your box not the flash drive so ide=nodma
is probably most appropriate. It really ought to handle both flash drives
however.

ide=nodma seems the right answer.

Alan

Re: apparent need to blacklist Lexar flash drive in ide-dma.c

[kilgota]

On Sat, 6 Oct 2007, Alan Cox wrote:

>> "Ultra 33/66" (I would assume this means UDMA 33 or 66)
>
> If it is cabled for it, DMA capable CF is quite new and that seems to
> cause problems sometimes.
>
>> Under the circumstances, I am of course uncertain whether the "ALL" is
>> appropriate or not, but I suspect it is. So perhaps you would like to add
>> this entry to the blacklist.
>
> The problem is almost certainly your box not the flash drive so ide=nodma
> is probably most appropriate. It really ought to handle both flash drives
> however.
>
> ide=nodma seems the right answer.
>
> Alan
>

Alan,

Thanks for the speedy answer.

If you think that the Lexar flash drive ought to function with DMA and you 
suspect that the problem might be in the box (which it could easily be!) 
then I would be curious if you have any ideas what one could do about 
that.

Current situation is that I stuck in a blacklist line for the Lexar flash, 
but otherwise

PCI access mode set to "any"

PCMCIA/CardBus support not turned on at all (would seem irrelevant but I 
could be wrong?)

IDE ACPI support on (and IIRC this gets used, too)

generic/default IDE chipset support (on)

PCI IDE chipset support (on)
Sharing PCI IDE interrupts (on) (but the bootup does report that primary 
interface gets IRQ 14 and secondary gets IRQ 15, which might mean this is 
not required?)

Generic PCI IDE chipset support (on)

Generic PCI busmaster support (on)

VIA 82CXXX chipset support (on)

and lspci output is as follows which looks pretty standard to me for VIA 
stuff of that vintage

---------------------------
00:00.0 Host bridge: VIA Technologies, Inc. VT8501 [Apollo MVP4] (rev 04)
00:01.0 PCI bridge: VIA Technologies, Inc. VT8501 [Apollo MVP4 AGP]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] 
(rev 1b)
00:07.1 IDE interface: VIA Technologies, Inc. 
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:07.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 
Controller (rev 0e)
00:07.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 
Controller (rev 0e)
00:07.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 
20)
00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 AC97 
Audio
Controller (rev 21)
00:07.6 Communication controller: VIA Technologies, Inc. AC'97 Modem 
Controller
(rev 20)
01:00.0 VGA compatible controller: Trident Microsystems CyberBlade/i7d 
(rev 5d)
-----------------------------------------

So I do not know exactly what other tricks to try :(

The old box does have some other quirks, though. It seems to me that the 
BIOS must be quite flaky. It does have some intersting challenges as a 
project box. The first one is to get it to boot without glitches (the 
cursed BIOS, again, is what seems to blame here; it hangs if one attaches 
USB devices like keyboards and mice before booting) and after that it 
would be interesting to see what kinds of things can be done to cut the 
software on it, including the kernel, to a machine of such small 
resources.

Thanks again for answering.

Theodore Kilgore

Re: apparent need to blacklist Lexar flash drive in ide-dma.c

[Alan Cox]

> If you think that the Lexar flash drive ought to function with DMA and you 
> suspect that the problem might be in the box (which it could easily be!) 
> then I would be curious if you have any ideas what one could do about 
> that.

If they didn't wire the CF slot for DMA (as sometimes happens, and the
idea of CF cards with DMA was considered ludicrous not many years ago)
then you'll need to be very very good with a fine soldering iron 8)

Alan

Re: apparent need to blacklist Lexar flash drive in ide-dma.c

[kilgota]

On Sat, 6 Oct 2007, Alan Cox wrote:

>> If you think that the Lexar flash drive ought to function with DMA and you
>> suspect that the problem might be in the box (which it could easily be!)
>> then I would be curious if you have any ideas what one could do about
>> that.
>
> If they didn't wire the CF slot for DMA (as sometimes happens, and the
> idea of CF cards with DMA was considered ludicrous not many years ago)
> then you'll need to be very very good with a fine soldering iron 8)
>
> Alan
>

I am good with one, but not that good. And I know some engineers around 
here who are about 10 times better than I am. But still not good enough 
for that kind of job, I think. So, OK.

But then I wonder why the DMA can be and was enabled in the BIOS and, one 
might surmise, DMA was used to access the Sandisk SDP3B-16 -- which is 
not hooked up to the CF slot at all, and which _is_ blacklisted. Strange.

Thanks, I guess that there is not much more to do with this one except to 
get everything else to work.

Cheers,
Theodore Kilgore