Linux-Development-Sys Digest #870, Volume #7 Wed, 17 May 00 22:13:12 EDT
Contents:
Re: inline-limit might be fun to try (David Wragg)
Re: Windows98 IDE driver screwed up Linux UDMA disk access? (Stefaan A Eeckels)
Re: porting NT device drivers to linux (Todd Knarr)
Re: Need ideas for university funded project for linux (eyez)
Re: Linux Mutexes and Conditions & 2.3.99 (Bill Waddington)
Re: Need ideas for university funded project for linux ([EMAIL PROTECTED])
C routine calls (Steve)
Re: inline-limit might be fun to try (Eric Taylor)
Dvd patches for SUSE kernel (Ashwin Kapur)
----------------------------------------------------------------------------
From: David Wragg <[EMAIL PROTECTED]>
Subject: Re: inline-limit might be fun to try
Date: 17 May 2000 19:40:46 +0000
Eric Taylor <[EMAIL PROTECTED]> writes:
> I just got a copy of R. Stallman's GCC user guide, for version 2.95
> and I see that there is a new option called -f-inline-limit-n where
> you can adjust according to size what procedures get inlined.
>
> I think this should allow us to see what would happen with inlining
> turned off. For example, I have to use bzImage for my kernel as zImage
> is too large. There could be uses for this other than just speed
> tradeoffs.
>
> My version of GCC, which is 2.91 and came with redhat 6.1, does not
> have this feature yet.
>
> Perhaps someone who already has the new compiler installed might want
> to experiment.
It won't make any difference. The kernel is compiled with -O2, which
does not do automatic inlining. The only functions that are inlined
are those where it is explicitly requested using "inline", and
generally the authors have made that choice by carefully considering
the trade-off between performance and memory footprint. Disabling
inlining will discard that work.
If you compile a kernel with -O3, you will find that it gets bigger
but not much faster, and I suspect that conversely disabling inlining
will cause it to get slower but not much smaller. Also, I seem to
remember that for some architectures there are cases where inlining is
needed for the code to work properly.
On the other hand, experimenting with disabling inlining for
particular functions (or in particular subsystems) to find the costs
and benefits in particular cases might be worthwhile.
David Wragg
------------------------------
From: [EMAIL PROTECTED] (Stefaan A Eeckels)
Subject: Re: Windows98 IDE driver screwed up Linux UDMA disk access?
Date: Thu, 18 May 2000 01:16:47 +0200
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Paul D. Smith) writes:
> %% [EMAIL PROTECTED] (Stefaan A Eeckels) writes:
>
> sae> That really should have removed all the effects of the new
> sae> driver.
>
> I would expect that settings such as those manipulated by hdparm would
> survive a power-cycle; couldn't the Windows driver have set those as
> well?
That could well be - I'm not an IDE fundi (all but one
of my machines are SCSI). From the hdparm man-page, I gather
the "keepsettings" works across soft resets, not power-cycling.
>
> >> May 16 21:43:59 homebase kernel: hda: dma_intr: status=0x51 { DriveReady
>SeekComplete Error }
> >> May 16 21:43:59 homebase kernel: hda: dma_intr: error=0x40 { UncorrectableError
>}, LBAsect=952, sector=889
> >> May 16 21:43:59 homebase kernel: end_request: I/O error, dev 03:01 (hda), sector
>889
>
> sae> Now that's an easy one: you've got a bad sector, and the machine
> sae> tells you nicely which one: 889. As this sector falls in the File
> sae> Allocation Table, the Linux driver disables writes to the disk,
> sae> to avoid damage to the logical structure.
>
> Hmm. I dunno. I'm pretty suspicious. First, this disk is only a year
> old (I know, disks sometimes go bad, but still). Second, it seems very
> coincidental that this error just happened to appear at the same time as
> Windows wouldn't boot with that bad driver. Third, I don't see how this
> explains why Linux hangs on boot until I turned off DMA in the BIOS,
> which I never had to do before.
In your first message you wrote:
+ Windows would hang in some random spot, and Linux would go through until
+ it tried to check the partition on /dev/hda, then it would say "timeout
+ waiting for UDMA" or something similar and hang.
>
> I guess it could be just a big coincidence...
It's not that you couldn't boot, but that things started to get
screwy when accessing hda. Not booting in my book is that you can't
load the kernel. IMHO, your hdb is OK. Just try to change the boot
scripts not to mount hda, and you should be able to boot Linux
without hassles.
In my experience, PC OSes react very badly to bad sectors (SCSI isn't
any better. Once your disk starts to fail, you're toast.
Try to enable S.M.A.R.T. in your BIOS, and see if it comes up
with information on hda. There's software for Linux that allows
you to query S.M.A.R.T. data:
http://csl.cse.ucsc.edu/software/smart/
>
> sae> I suggested that to avoid going through booting from Windows, or
> sae> using hda's MBR.
>
> Ah. Good idea.
>
> sae> No need to fix anything. Your problem is due to hda going bad
> sae> (EIDE drives correct bad tracks automatically. When they start
> sae> showing them to the OS, it means that the alternate track table
> sae> is overflowing. If I were you, I'd get a new drive.
>
> Hmm hmm. That would suck (not the new drive part so much as
> transferring all the @$#%& data).
I know, it's a royal PITA. NT is OK, you can copy it all to a new
partition and make the new one bootable. Maybe a tool like
Norton Ghost (don't know it, never used it, no shares in Symantec)
could help? Alternatively, "dd"ing the Windows partition to the new
disk might be enough (and fixing the MBR, obviously).
>
> If the drive were going that bad, wouldn't I be able to see it from
> Windows, too, somehow? So far as I can tell, Windows has no problems
> with the disk.
Under NT, the C: disk was showing bad sectors left, right and
centre, resulting in time-outs, lost and corrupted system DLLs,
and weird behaviour, without a single entry in the system log.
If NT is so bad, then Win98 will be worse, I guess.
> I'll try dosfsck and see if I can find any disk checking tools in
> Windows.
Try scandisk. I'm sure it will show a bad sector.
> Thanks for all your help!
You're very welcome.
--
Stefaan
--
--PGP key available from PGP key servers (http://www.pgp.net/pgpnet/)--
Ninety-Ninety Rule of Project Schedules:
The first ninety percent of the task takes ninety percent of
the time, and the last ten percent takes the other ninety percent.
------------------------------
From: Todd Knarr <[EMAIL PROTECTED]>
Subject: Re: porting NT device drivers to linux
Date: 18 May 2000 00:21:15 GMT
In comp.os.linux.development.system <8fumh4$la0$[EMAIL PROTECTED]>
[EMAIL PROTECTED] wrote:
> Im a student and for my dissertation I have to
> port a NT driver (plus DLL) for a PCI Card to
> LINUX.
> Im a newbie in driverprogramming and Linux but I
> read
> lots of books about it (i.e. Rubini, KHG, LKMPG).
In general, it's not possible to port a binary NT driver to
Linux. You've got two options:
1) Get the specs for the card and write a driver to those specs.
2) Get the source code for the NT driver and reverse-engineer
the specs, then write the driver to them.
NT is simply too different from Linux down at this level. The
APIs between the driver and the other kernel components are not
anywhere near the same.
> I think the best way for the driver is a module,
> but
> I dont know how to port the dll - is there a
> similar
> concept in Linux or should I write a second
> module for
> it and stack it onto the driver module.
What you've run into here is the fact that much of a lot of NT
'drivers' aren't drivers at all, but libraries of functions that
access the actual driver. In Linux, the driver itself is the
kernel module and it runs as part of the kernel, handling I/O
and other things. You can then provide a shared library of
routines that provide a higher-level interface to programs
and use the driver for the actual communication with the
device.
Example: my SCSI scanner. There is no scanner driver as such,
just the SCSI generic driver built into the kernel. The SANE
libraries provide high-level user-space routines to identify
the type of scanner, do any setup needed and scan images in.
Programs call SANE routines to do things, and SANE at the bottom
uses the SCSI generic driver to communicate with the scanner.
This is much more robust since problems in the SANE library
layer may crash the program but will usually not crash the whole
system, whereas bugs in the driver can easily crash the entire
system since they're occurring inside the kernel.
--
Collin was right. Never give a virus a missile launcher.
-- Erk, Reality Check #8
------------------------------
From: [EMAIL PROTECTED] (eyez)
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Need ideas for university funded project for linux
Reply-To: [EMAIL PROTECTED]
Date: Thu, 18 May 2000 00:33:00 GMT
quoting <[EMAIL PROTECTED]>:
>[EMAIL PROTECTED] (eyez) writes:
>> quoting <[EMAIL PROTECTED]>:
>> >Mongoose <[EMAIL PROTECTED]> writes:
>
>> >In order to beat Windows, client-side, we need:
>
>> >1. A GUI interface to *all* configuration files;
>
>> Ugh. that's why i LEFT windows.
>
>I'm not saying that you should *have* to go through the GUI, just that
>you can if you want to.
True Enough. However, it seems in my mind that that can cause an evil
spiral. Once you can do it with a gui, you may never learn the RIGHT way,
and especially with the way commercial distributions are, They probably
will all be separate models for doing so.
>
>I concur, though, that for some applications (recovery and
>auto-configs/-installs, to name two) it's a really bad idea. And it's
>a trap that Windows has never managed to get out of. (It's why the
>"Windows Resource Kit" includes a bunch of UNIX utilities.)
>
>> maybe the whole world SHOULDN'T run linux. It's not a system that's
>> made to be like windows.
>
>Perhaps it wasn't made to have a GUI (and I'm not saying "Windows," I'm
>saying "a GUI"), but it's certainly become a part of it over time.
I wouldn't say it wasn't made to have a GUI, i say it wasn't made to DEPEND
ON the GUI.
>
>--
>Eric P. McCoy ([EMAIL PROTECTED])
>
>non-combatant, n. A dead Quaker.
> - Ambrose Bierce, _The Devil's Dictionary_
--
Rando Christensen
[EMAIL PROTECTED]
<perception is reality>
------------------------------
From: Bill Waddington <[EMAIL PROTECTED]>
Subject: Re: Linux Mutexes and Conditions & 2.3.99
Date: Thu, 18 May 2000 00:42:19 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
> Thanks for the patches; I already reworked your ikon_*.[ch] files into
> a similar patch. I guess I should have waited. ;)
>
Sorry about the slop I sent you - I (obviously) have a lot to learn
about coding style.
>
> It does look like a lost wakeup. Are you using a predicate variable
correctly?
I don't think I need one (but, obviously, something is wrong).
The flow of the code is pretty simple. I start a DMA and enable an
end-of-DMA iterrupt, and sleep until it comes in. I don't check a
predicate, since the interrupt always occurs after the DMA start, and
usually milliseconds after - although it certainly could happen between
the DMA start and the wait:
/* in the waiting code */
mutex_lock(&unit_p->mutex);
start DMA and enable int;
cond_timed_wait_rel(&unit_p->cond, &unit_p->mutex,
unit_p->dma_time);
mutex_unlock(&unit_p->mutex);
/* in the interrupt code */
mutex_lock(&unit_p->mutex);
if(our interrupt)
flag = 1;
quiet the hardware;
mutex_unlock(&unit_p->mutex);
if(flag)
cond_broadcast(&unit_p->cond);
If I set the size of the DMA block to one quadbyte (1 xfer), so that the
interrupt _always_ happens in the critical section, it doesn't fail (at
least any more often than the normal DMA xfer size does). Strangely,
the failure always happens w/a screensaver running, but since that't
most of the time, and it only fails every few hours, I doubt that means
anything.
I don't expect you to debug my driver (although that would be nice), but
if you see anything fishy about the above, or the patch, please let me
know.
Thanks for the quick reply,
Bill
--
Bill Waddington
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Need ideas for university funded project for linux
From: [EMAIL PROTECTED]
Date: Thu, 18 May 2000 01:00:45 GMT
[EMAIL PROTECTED] (Leslie Mikesell) writes:
[installing from source]
> Odd, I've got an xemacs from the default install...
Really? I haven't used a bleeding-edge RH, but all the ones I *have*
used don't have XEmacs packages.
> >I want to click on a damn button and have the program install. I want
> >the option to do it by hand if I have to, but installing anything on
> >Linux is a nightmare if you have to build it from the source. Note
> >also that "make install" will occasionally break, depending on your
> >distribution. And they all seem to be going in tangential directions
> >on this one.
> Have you found something you wanted where you couldn't find a
> recent source rpm already tuned for your base installation
> that you could tweak and rebuild with a couple of rpm commands?
Actually, I use Debian, not RedHat. Basically the same situation
(though Debian doesn't package their sources). No, my only point
there was that, frex, Debian makes extensive use of /usr/share,
whereas some other distros use /usr/local for the same thing.
Actually, Debian is now putting all docs in /usr/share/doc instead of
/usr/doc, which is certainly a big departure. (Although they've been
good about putting symlinks in, so far.)
> >There's just no excuse for not having an adequate installer. We have
> >two excellent package-management tools, dpkg (and apt) and rpm. All
> >we have to do is put a shiny new GUI front-end on them.
> What is wrong with clicking on an rpm file with the kde
> file manager/browser? It will automatically start kpackage
> so you can click the install button. Toss in the powertools
> CD and go wild.
Oh, nothing's wrong with it. But some (non-free) programs require you
to, for example, first download the program to /tmp and then "install"
the package. And packages often run behind the latest release,
because the maintainers can't be bothered to wrap them up in anything
but a tarball.
I didn't know RH/KDE had a GUI installer. That's great. Debian
doesn't have one. (I'm talking about something other than gnome-apt.)
> >Not that I am bitter.
> Have you been doing it the hard way?
Sometimes, that's the only way to do it.
[too many Linux packages]
> If it is free and useful you'll probably find it in either the
> RedHat or Mandrake base RPMs or on the powertools CD. Or
> the VALinux variation - all pretty much binary-rpm compatible.
Searching through billions and billions of packages is no fun. Maybe
I'm in worse shape because I use Debian (where if it ends in ".dpkg"
it's on the master list of packages).
Actually, Debian seems to have some nice categories (optional, extra,
important, required) that would be useful, if they were implemented
properly. Well, in time, maybe.
> >I much, much, much prefer being able to right-click on something and
> >hit "Properties." I also like being able to press F1 when the mouse
> >is over a confusing field and get an explanation of it. (The
> >explanation often isn't a help, and I expect that would carry over to
> >Linux, but at least there's no flipping around between screens.)
> So what is the problem with doing this in the KDE desktop?
KDE isn't free.
And GNOME is nowhere near fully-developed.
> >Please excuse the rant. But Linux has been a pain in the ass to
> >configure since I started using it in the early 90's, and it's
> >improved not at all since then.
> Huh? A recent Mandrake/RedHat does most of what you say
> is missing right out of the box.
Perhaps. I've never actively administered a RedHat system. Are all
of RH's configuration tools proprietary or non-free? If they were
open source and portable between distros, I'd think they'd show up in
Debian. (After all, Bonobo and friends have.)
--
Eric P. McCoy ([EMAIL PROTECTED])
non-combatant, n. A dead Quaker.
- Ambrose Bierce, _The Devil's Dictionary_
------------------------------
From: Steve <[EMAIL PROTECTED]>
Subject: C routine calls
Date: Wed, 17 May 2000 21:15:15 -0400
Reply-To: [EMAIL PROTECTED]
I'm trying to record all C routine calls of a program. Is there any good
way to do this? Please give me some useful links about C Library
implementation.
Also, I need the source code for some small applications and commands,
such ps and ls, under Linux/FreeBSD. Where can I get them?
Thanks,
--Steve
------------------------------
From: Eric Taylor <[EMAIL PROTECTED]>
Subject: Re: inline-limit might be fun to try
Date: Wed, 17 May 2000 18:36:52 -0700
David Wragg wrote:
>
> Eric Taylor <[EMAIL PROTECTED]> writes:
> > I just got a copy of R. Stallman's GCC user guide, for version 2.95
> > and I see that there is a new option called -f-inline-limit-n where
> > you can adjust according to size what procedures get inlined.
> >
> > I think this should allow us to see what would happen with inlining
> > turned off. For example, I have to use bzImage for my kernel as zImage
> > is too large. There could be uses for this other than just speed
> > tradeoffs.
> >
> > My version of GCC, which is 2.91 and came with redhat 6.1, does not
> > have this feature yet.
> >
> > Perhaps someone who already has the new compiler installed might want
> > to experiment.
>
> It won't make any difference. The kernel is compiled with -O2, which
> does not do automatic inlining. The only functions that are inlined
> are those where it is explicitly requested using "inline", and
> generally the authors have made that choice by carefully considering
> the trade-off between performance and memory footprint. Disabling
> inlining will discard that work.
The reason I questioned all this inlining was that in an effort to
understand the kernel, I compiled
it under an alternate C environment. I wanted to use a
"browser" instead of "heavy grep-ing".
After a lot of brute force editing, I found that
some 100-200 routines were specified as inline, as each
had to be removed to compile sucessfully. After getting the
browser to work, i found that some inlined procedures get
called in lots of places. But the browsing wasn't working
well enough to get an overall impression. Many inlined routines
only showed up once as a reference and some had no references
because I didn't include all the source code.
I thought if one could turn off all inlining in one easy step,
we could get a quick size comparison which would be an interesting
metric for how much inlining was being done. And if it ran, we
could do a timing comparison. But if not inlining would actually
break code, then i guess we will never know.
regards
eric
------------------------------
From: Ashwin Kapur <[EMAIL PROTECTED]>
Subject: Dvd patches for SUSE kernel
Date: Thu, 18 May 2000 01:59:41 GMT
Hi:
I'm wondering how to apply the linux dvd patches to the SUSE
linux kernel. I like the SUSE linux kernel because it has a
number of things in it that I like a lot like UDF support
already there but it's too different from the stock kernel
to apply the publicly available dvd patches. Just wondering
if someone had the dvd patches modified for the SuSE 6.4
kernel or if I'll just have to get the stock kernel or apply
all the patches manually.
When you reply, it would be great if you could also reply to
my email.
Thanks
Ashwin
--
We are all agreed that your theory is crazy. The question
which
divides us is whether it is crazy enough to have a chance of
being
correct. My own feeling is that it is not crazy enough.
-- Niels Bohr
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
