Re: Pioneer DVR-106D issues
>From: Meelis Roos <mroos@linux.ee>
>JS> The recent Linux kernels are full of IDE related bugs :-(
>Here I can mostly agree - several IDE drivers have bugs, mostly DMA
>related (sine most of IDE is DMA nowadays). In addition people report
>their IRQ routing bugs as IDE when IDE IRQ doesn't happen but this is
>rather an ACPI BIOS / Intel ACPI code / Linux chipset-specific IRQ
>routing problem. Disabling ACPI usually fixes the IRQ problems.
---> Solaris x86: "eeprom acpi-user-options=0x02"
>Not that other operating systems don't have IDE bugs - I have struggled
>with IDE problems that looked like driver bugs in Solaris too. Not that
>would prove anything, we know there is no bugfree software.
It is interesting to me that I only find few real bugs in Solaris 86.
It is on most cases a need to just set up the BIOS "correctly".
However, once you did this on Solaris x86, the problems usually did go
away completely - on Linux other problems start to become obvious.
>JS> A big problem is that Linux kernels are not compiles with a decent set
>JS> of GCC warning messages enable (maybe because they include so ugly code).
>Quite possible. The current Linux kernel uses the following warning and
>code-generation options on my x86 system:
>-Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing
>-fno-common -mpreferred-stack-boundary=2 -march=pentium3
>-fomit-frame-pointer
In the Schily makefile system (Developer set up) these warning options are
used:
CWOPTS= -Wall -Wtraditional \
-Wshadow -Wmissing-prototypes -Wstrict-prototypes
-Wtraditional more and more created problems with GCC-3.x
>What options do you suggest that don't give false positives? You can't
>use warnings with false positives in such a big piece of code, people
>would just start ignoring meaningful warnings too whan they get used to
>seeing many warnings. But quite possibly there are some gcc warning
>options that would be useful. What options would you suggest adding?
May be the problem is that there just too many false warnings so people
did oversee the real bugs.
>JS> Some peole completely did rework IDE internals (mainly in the DMA area)
>JS> and did change the number of parameters to functions. While a direct
>JS> function call with a parameter missmatch would result in a compilation
>JS> abort (with GCC at least ends up with a big warning), this cannot directly
>JS> be noticed as the functions get called via a function pointer. As long
>JS> as you don't enable compiler warnings for bad pointer assignements, you will
>JS> never see a warning for this kind of broken source...
>Are you sure you know what yo are talking here? Have you actually looked
>at the code? I did have a look at current Linux kernel IDE code and like
_I_ am definitely sure, I did try to fix DMA for a driver 6 months ago....
>other parts of the kernel, IDE code and drivers use strongly typed
>function pointers everywhere. Vast mayority of function parameters are
>also strongly typed for any non-atomic types. The only functions I found
>that have void* arguments that are not IO addresses are the following:
>extern void ata_input_data(ide_drive_t *, void *, u32);
>extern void ata_output_data(ide_drive_t *, void *, u32);
>extern void atapi_input_bytes(ide_drive_t *, void *, u32);
>extern void atapi_output_bytes(ide_drive_t *, void *, u32);
>extern void taskfile_input_data(ide_drive_t *, void *, u32);
>extern void taskfile_output_data(ide_drive_t *, void *, u32);
_You_ are looking at the wrong places :-(
The important things are called via function pointers that are in
a structure...
This is why you don"t get a compiler warning for bad function usage but
for a "illegal pointer combination" only.
Jörg
--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schilling@fokus.fraunhofer.de (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
Reply to: