Re: Journaling: Surviving or allowing unclean shutdown?

[Andreas Dilger]

Stefan, you write:
> [Re: read-only filesystem vs. read-only device]
> Anyway, it is "especially" critical on the root filesystem because the
> authors of filesystems can't support two ro states on boot.
> 
> Reiserfs allowed  -oro,noreplay.
> 
> Please tell me how to specify "noreplay" for the initial "/" mount :)

Actually, for ext3 Stephen added a kernel option "rootflags" so that you
can pass mount options to the root filesystem.  This was previously needed
to add a journal to an existing ext2 root filesystem.  I hope he keeps it
around anyways, and submits it as a regular kernel patch, because it is
useful for many other things.

> But this has nothing to do with forcing a write on "ro" mounts, which
> I interpret as design bug. (ro,noreplay is also a kind of design bug,
> everything except a virtual replay under physical ro conditions looks
> like a design bug to me because it breaks user expectations either
> by writing on "ro" or by giving an invalid view by "noreplay")

If the VM subsystem can tolerate keeping dirty pages around for a read-only
device then virtual replay can be made to work, for no more memory than
might be pinned by having a journal in the first place.  The only problem
is that normal journal pages will eventually be freed, whereas virtual
journal replay pages would not (until the filesystem is unmounted or mounted
read-write).  This _may_ be OK in some cases, but I think most people with
journalled filesystem have more journal space than RAM, so you will likely
get into bad situations very quickly, all for a technical nit.

Currently ext3 just refuses to load on a read-only device if the journal
is dirty.  However, changes are upcoming to allow LVM snapshots on ext3
filesystems, so there is little legitimate need for a dirty journal on
a read-only device.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/   -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Journaling: Surviving or allowing unclean shutdown?

[Andreas Dilger]

Daniel writes:
> Yes, and so long as your journal is not on another partition/disk things
> will eventually be set right.  The combination of a partially updated
> filesystem and its journal is in some sense a complete, consistent
> filesystem.
> 
> I'm curious - how does ext3 handle the possibility of a crash during
> journal recovery?

Unless Stephen says otherwise, my understanding is that a crash during
journal recovery will just mean the journal is replayed again at the next
recovery.  Because the ext3 journal is just a series of data blocks to
be copied into the filesystem (rather than "actions" to be done), it
doesn't matter how many times it is done.  The recovery flags are not
reset until after the journal replay is completed.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/   -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RE: How to Power off with ACPI/APM?

[Grover, Andrew]

> From: Michael D. Crawford [mailto:[EMAIL PROTECTED]]
> > How is each of your setups, ie, what is compiled in kernel 
> and what is 
> > a module ? My guess is: 
> > - ACPI+APM in kernel: ACPI wins 
> > - APM in kernel, ACPI module; APM starts, blocks ACPI 
> > - and so on 
> 
> Nope.  If they're both in the kernel, APM wins.
 
> Many folks have given me tips on getting power off to work, 
> I'll screw around to
> see if I can get it to go.  But I guess the fact that ACPI 
> exits if APM is
> enabled is a real bug.

Hey, that's not a bug, that's a feature! ;) ACPI and APM cannot both be
active, so we check on init. However, the fact that the help says ACPI
always wins is incorrect, and will be fixed.

Regards -- Andy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Dell Precision 330 (Pentium 4, i850 chipset, 3c905c)

[Andrew Morton]

I Lee Hetherington wrote:
> 
> Anybody get this working with 2.2.18 or 2.4.0-prerelease?  I can't seem
> to get the on-board 3c905c to work.  I've seen it without an interrupt
> assignment in /proc/interrupts.  With Red Hat's pump (DHCP), it sends
> packets out but doesn't seem to see the response.
> 
> I can provide more details.

Please do.  The boot-time messages which come out of the driver
would be interesting.  It would help if you add `debug=7' to
the 3c59x modprobe command line also.

Thanks.

-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RE: ACPI in Via Apollo (vt82C686) broken badly in 2.4.x ?

[Grover, Andrew]

> From: safemode [mailto:[EMAIL PROTECTED]]

> Well, it seems the only way to look at sensor readings with 
> lmsensors is
> to activate acpi in linux for my motherboard.

Can you please send me the output from dmesg, as well as /proc/interrupts? I
don't think anyone's tried lmsensors and acpi. It may be that they will need
some work to coexist..

> According to 
> the docs, my
> motherboard is supposed to be supported and is detected when linux
> boots, the problem comes when i try to move the mouse (in console and
> X).  It totally flips out, i get irregular mouse movement across the
> screen and button clicks when i just barely touched it.  It 
> is directly
> related to enabling acpi so i was wondering if anyone else 
> has had this
> problem and if there was/is a fix for it or if it's a bug right now.
> If there is specific debugging info that i can get to help, tell me
> where... dmesg just shows successful messages.

Never seen that before.. does /proc/interrupts indicate mouse driver and
acpi are sharing one?

Regards -- Andy (ACPI maintainer)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.4.0ac1

[Miles Lane]

Bill Wendling wrote:

> Also sprach Keith Owens:
> } On Thu, 04 Jan 2001 21:54:29 -0800, 
> } Miles Lane <[EMAIL PROTECTED]> wrote:
> } >make[4]: Entering directory `/usr/src/linux/drivers/acpi'
> } >/usr/src/linux/Rules.make:224: *** Recursive variable `CFLAGS' references itself 
>(eventually).  Stop.
> } 

> Changing that line to:
> 
> $(MODINCL)/%.ver: CFLAGS := -I./include $(CFLAGS)
> 
> might work as well...

Seems to work here.  Thanks, Bill.

Miles

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Patch: Fix for r128 DRM compilation problem

[Gareth Hughes]

The 2.4.0 kernel will fail to compile if the r128 DRM module is enabled
but AGP support (agpgart) is not.  The following patch fixes this error:

--- linux/drivers/char/drm/Config.inWed Aug  9 02:27:33 2000
+++ linux.gth/drivers/char/drm/Config.inFri Jan  5 18:11:53 2001
@@ -9,7 +9,7 @@
 if [ "$CONFIG_DRM" != "n" ]; then
 tristate '  3dfx Banshee/Voodoo3+' CONFIG_DRM_TDFX
 tristate '  3dlabs GMX 2000' CONFIG_DRM_GAMMA
-tristate '  ATI Rage 128' CONFIG_DRM_R128
+dep_tristate '  ATI Rage 128' CONFIG_DRM_R128 $CONFIG_AGP
 dep_tristate '  Intel I810' CONFIG_DRM_I810 $CONFIG_AGP
 dep_tristate '  Matrox g200/g400' CONFIG_DRM_MGA $CONFIG_AGP
 fi

I will apply this to DRI CVS now.  Apologies for letting this slip
through.

-- Gareth
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [linux-usb-devel] Re: Announce: modutils 2.4.0 is available

[Greg KH]

On Thu, Jan 04, 2001 at 11:17:49PM -0800, Miles Lane wrote:
> Greg KH wrote:
> 
> 
> 
> > I agree.  I can set up a "linux-hotplug" group using SourceForge if
> > others also think that this is a needed thing.  I don't want to see
> > things like this happen again.
> > 
> > Actually almost anyone can, but at least I'm volunteering :)
> > 
> > greg k-h
> 
> Hi Greg,
> 
> David Brownell had mentioned previously that he thought the
> throughput on vger.kernel.org might be better than
> lists.sourceforge.net because vger is better matched to
> its server load.  Do you know whether this is true?
> My preference would be to see this list be hosted by a
> relatively quick mailserver.
> 
> If the concensus is that sourceforge is good enough,
> than you have my gratitude for getting this set up.

Throughput on vger.kernel.org does seem incredible.  But lately
SourceForge doesn't seem very bad at all, as it seems they have beefed
up their servers.

I'm only proposing SourceForge as I can set up a list easily there
easily, and I don't know the right people to ask to get it done on
vger.kernel.org :)

Unless anyone objects in the next 10 hours, I'll try to create it, and
let everyone know about it.

thanks,

greg k-h

-- 
greg@(kroah|wirex).com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RE: Change of policy for future 2.2 driver submissions

[Gerhard Mack]

On Fri, 5 Jan 2001, Andre Tomt wrote:

> I would wait for at least 2.4.10 on production systems (servers in
> particular). Not to start a flame or anything (yeah, right), but 2.2.x was
> not usable on such systems before it reached 2.2.16 IMHO.
> 
> So, I guess, the "crippling" of driver submissions could hurt me bit, in
> theory, which I don't like. ;-)

I don't remember 2.2.0 being this well tested... I seem to recall it
having a huge list of known bugs at the time too.

2.4.0 seems to have come with much better bug tracking and the time was
spent fixing those bugs.

Some of the servers I ran at the time wouldn't stabilize until 2.2.7 ..
I'm betting on things going much more smoothly (though I won't know
for sure since that company lost it's ability to afford me ;) ) 

Gerhard



--
Gerhard Mack

[EMAIL PROTECTED]

<>< As a computer I find your faith in technology amusing.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

FW: You've Been Slashdotted

[Dylan Vanderhoof]

Likewise with my mirror out of Semaphore in Seattle.

However, most people aren't using LKAMS, they're hitting zeus.kernel.org.

-D

---
Dylan C. Vanderhoof
Internal Software Developer
Semaphore Corporation
http://www.semaphore.com/
perl -e "print(pack('h38','c6c616279616e604c6c616279616e6e2e65647'))"

"RFC 822 puts the 'dot' in .com"

PGP Fingerprint -- 0CFC 7FC7 7A35 9980 2CB6  43C2 8FCF CD5F 538E 8081

---


-Original Message-
From: Scott Laird [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 04, 2001 11:15 PM
To: Michael D. Crawford
Cc: [EMAIL PROTECTED]
Subject: Re: You've Been Slashdotted



On Fri, 5 Jan 2001, Michael D. Crawford wrote:
> 
> You're probably not going to have much luck getting any source off any
servers
> tonight.  Might I suggest you pop over to Slashdot and give the clueless
some
> clues on getting their new kernels working?  They need help.

Dunno -- my mirror (ftp-mirror.internap.com, or ftp15.us.kernel.org) is
only seeing 1-2 Mbps worth of traffic, out of 10 Mbps available to it.  I
suspect that a lot of mirrors are similar.


Scott
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Change of policy for future 2.2 driver submissions

[Michael D. Crawford]

You might find it interesting to read the section entitled "Monkeywrenching the
Virtual Machine" towards the end of "Why We Should All Test the New Linux
Kernel".  It's in my second comment after the main article:

http://advogato.org/article/224.html

I understand Linus' desire to have more widespread testing done on the kernel,
and certainly he can accomplish that by labeling some random build as the new
stable version.  But I think a better choice would have been to advocate testing
more widely - don't just announce it to the linux-kernel list, get on National
Public Radio, the Linux Journal and Slashdot and stuff.  

Don't just announce the existence of a kernel that people ought to test, but hit
the streets and provide advice and assistance and encouragement to those who
might help out.

That's the kind of thing I was trying to do in my article above.

My concern is that declaring this kernel as production and stable, with patching
still happening by the minute, is that a lot of people who don't know what
they're doing will slap it into machines they depend on for their livelihood,
and a lot of distributions will quickly adopt it in order to be perceived as
competitive.  The very first experience many people will ever have with Free
Software will boot off Linux 2.4.0 - not 2.4.1, because some distro will want to
be the first.

You might think this is great because of all the extra testing the new users
will do but I assert that it isn't.  The environment for Linux is quite
different these days than when 2.2 or 2.0 were released.

A lot of the people who will be using it are not technically savvy people, and
many of those who do know technology depend on its reliability for the
profitability of large businesses but may not read Linus' message that indicates
this is really just for testing.

It would be really bad if this particular version of the kernel turns out to
have a lot of problems.

I guess you can get more people testing by releasing it yourselves than I can
with my websites saying people should test, but I feel that having the testing
done by people who know what they're getting into and have some guidance is a
wiser course of action.

If you're in the neighborhood, please stop by:

http://linuxquality.sunsite.dk

Mike


-- 
Michael D. Crawford
GoingWare Inc. - Expert Software Development and Consulting
http://www.goingware.com/
[EMAIL PROTECTED]

   Tilting at Windmills for a Better Tomorrow.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: You've Been Slashdotted

[Scott Laird]

On Fri, 5 Jan 2001, Michael D. Crawford wrote:
> 
> You're probably not going to have much luck getting any source off any servers
> tonight.  Might I suggest you pop over to Slashdot and give the clueless some
> clues on getting their new kernels working?  They need help.

Dunno -- my mirror (ftp-mirror.internap.com, or ftp15.us.kernel.org) is
only seeing 1-2 Mbps worth of traffic, out of 10 Mbps available to it.  I
suspect that a lot of mirrors are similar.


Scott

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [Ext2-devel] Re: [RFC] ext2_new_block() behaviour

[Andreas Dilger]

Stephen, you write:
> On Thu, Jan 04, 2001 at 05:31:12PM -0500, Alexander Viro wrote:
> > BTW, what inumber do you want for whiteouts? IIRC, we decided to use
> > the same entry type as UFS does (14), but I don't remember what was
> > the decision on inumber. UFS uses 1 for them, is it OK with you?
> 
> 0 is used for padding, so 1 makes sense, yes.

Sorry, but what are whiteouts?  Inode 1 in ext2 is the bad blocks inode,
so it will never be used for a valid directory entry, but depending on
what it is we may want to make sure e2fsck is OK with it as well.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/   -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [linux-usb-devel] Re: Announce: modutils 2.4.0 is available

[Greg KH]

On Thu, Jan 04, 2001 at 08:54:33PM -0800, David Brownell wrote:
> Matt --
> 
> > It's pretty much the same patch (functionally) as I posted to the
> > linux-usb-devel mailing list, which I presumed would inform the hotplugging
> > people.  Mea culpa, I seem to have been in error there.
> 
> Miles had a suggestion for a "linux-hotplug" mailing list; this
> could have been a good issue to coordinate on such a smaller
> (lower traffic?) list.

I agree.  I can set up a "linux-hotplug" group using SourceForge if
others also think that this is a needed thing.  I don't want to see
things like this happen again.

Actually almost anyone can, but at least I'm volunteering :)

greg k-h

-- 
greg@(kroah|wirex).com
http://immunix.org/~greg
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: How to Power off with ACPI/APM?

[Michael D. Crawford]

As suggested, I added:

apm=power-off

to the kernel line of my grub menu.lst file and now I can power off. I almost
jumped when the machine snapped off - my bloody monitor doesn't go dark when it
loses signal it lights up with an RGB test pattern (TTX - don't buy one).

I think the real reason it wasn't working was that, although I'm using a
one-processor machine with a motherboard that only allows for one processor, I
had enabled SMP in the kernel, and this disables APM.

In my own work I mostly do multithreaded software development and I just sort of
felt like it would be good karma to enable it even if my machine didn't support
it.  Go figure.  So this was mostly a user error, although I guess I've been
helpful in discovering the current interaction of ACPI and APM.

I'll read up a bit more on ACPI and see what I can do with that later on.

Thanks for the help.  If you're in the neighborhood, stop by:

http://linuxquality.sunsite.dk

Mike
-- 
Michael D. Crawford
GoingWare Inc. - Expert Software Development and Consulting
http://www.goingware.com/
[EMAIL PROTECTED]

   Tilting at Windmills for a Better Tomorrow.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RE: Change of policy for future 2.2 driver submissions

[Andre Tomt]

> I was in your position, I feel it may be a mistake.
> I personaly do not trust the 2.4.x kernel entirely yet, and would
> prefer to
> wait for 2.4.1 or 2.4.2 before upgrading from 2.2.18 to ensure last-minute
> wrinkles have been completely ironed out, and I know there are people who
> share my viewpoint, and would rather use 2.2.XX for a while yet, and I'm
> afraid that this may partialy criple 2.2 driver development.

I would wait for at least 2.4.10 on production systems (servers in
particular). Not to start a flame or anything (yeah, right), but 2.2.x was
not usable on such systems before it reached 2.2.16 IMHO.

So, I guess, the "crippling" of driver submissions could hurt me bit, in
theory, which I don't like. ;-)

--
André. Alfred?
http://www.tomt.net

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Announce: modutils 2.4.0 is available

[Miles Lane]

Matthew Dharm wrote:

> Well, I'll be the one to fall on my sword...
> 
> This is probably my fault.  The matching code was pretty much broken for a
> non-trivial subset of usb devices.  I'd submitted the patch to Linus before
> the holdiays, but it was rejected for various reasons.  After some back and
> forth, Linus finally accepted it on about the 2st of the year.
> 
> It's pretty much the same patch (functionally) as I posted to the
> linux-usb-devel mailing list, which I presumed would inform the hotplugging
> people.



We really do need a linux-hotplug mailing list.  Who would be able to
set up such a list on vger.kernel.org (or anywhere else that supports
maillist archives and has decent server loads)?  I've already floated
this idea once, but noone who can make this happen has volunteered.

Why we need this:

There are too many people working on hotplug issues in disjoint corners
of the kernel and utility community.  This work requires coordination
from the various bus developers (USB, SCSI, PCI, IrDA, Firewire,
Wireless, etc.) as well as folks working on the usermode scripts,
utilities and so forth.  There is also the need to sort out all the
PCMCIA/Cardbus issues having to do with migrating the installed base
over time to the new kernel drivers (yenta and friends).

Miles

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Announce: modutils 2.4.0 is available

[Anuradha Ratnaweera]

On Fri, 5 Jan 2001, Keith Owens wrote:

> modutils-2.4.0.tar.gz   Source tarball, includes RPM spec file
> modutils-2.4.0-1.src.rpmAs above, in SRPM format
> modutils-2.4.0-1.i386.rpm   Compiled with egcs-2.91.66, glibc 2.1.2
> modutils-2.4.0-1.sparc.rpm  Compiled for combined sparc 32/64
> patch-2.4.0-persistent.gz Adds persistent data and generic string
>   support to kernel 2.4.0.

Why not DEB?

Anuradha

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] 2.4.0-prerelease: preemptive kernel.

[ludovic fernandez]

george anzinger wrote:

> Roger Larsson wrote:
> >
>
> > This part can probably be put in a proper non inline function.
> > Cache issues...
> > +/*
> > +* At that point a scheduling is healthy iff:
> > +* - a scheduling request is pending.
> > +* - the task is in running state.
> > +* - this is not an interrupt context.
> > +* - local interrupts are enabled.
> > +*/
> > +if (current->need_resched == 1 &&
> > +   current->state == TASK_RUNNING &&
> > +   !in_interrupt()&&
> > +   local_irq_are_enabled())
> > +{
> > +schedule();
> > +}
> >
> Actually the MontaVista Patch cleverly removes the tests for
> in_interrupt() and local_irq_are_enabled() AND the state ==
> TASK_RUNNING.  In actual fact these states can be considered way points
> on the system status vector.  For example the interrupts off state
> implies all the rest, the in_interrupt() implies not preemptable and
> finally, not preemptable is one station away from fully preemptable.
>
> TASK_RUNNING is easily solved by makeing schedule() aware that it is
> being called for preemption.  See the MontaVista patch for details.
>

Humm, I'm just curious,
Regarding in_interrupt(). How do you deal with soft interrupts?
Guys calling cpu_bh_disable() or even incrementing the count on
their own. I don't know if this acceptable but definitely can be done,
I prefer to rely on fact than on API.
Regarding local_irq_enabled(). How do you handle the code that
call local_irq_disable(), then spin_lock(), spin_unlock() and only
re-enable the interruptions ? In this case, you preempt code that
is supposed to run interruptions disabled.
Finally, regarding the test on the task state, there may be a cache issue
but calling schedule() has also some overhead.

Ludo.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Change of policy for future 2.2 driver submissions

[Tim Riker]

Nicholas,

While I can see what you are asking, here are some comments in Alan's
favor:

He did not say people can not release 2.2 patches without 2.4 patches.
He only said they will not be integrated into the kernel distribution
without 2.4 patches.

If people continue to develop for 2.2 and have someone else, who is
probably less familiar with the hardware, port to 2.4 for them, how soon
would you trust the drivers over the 2.2 drivers?

In short, I agree with Alan completely. This is the correct move forward
to cause 2.4 to become the stable release that everyone will be willing
to adopt.

Nicholas Knight wrote:
> 
> - Original Message -
> From: "Alan Cox" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, January 04, 2001 6:41 PM
> Subject: Change of policy for future 2.2 driver submissions
> 
> >
> > Linux 2.4 is now out, it is also what people should be concentrating on
> first
> > when issuing production drivers and driver updates. Effective from this
> point
> > 2.2 driver submissions or major driver updates will only be accepted if
> the
> > same code is also available for 2.4.
> >
> > Someone has to do the merging otherwise, and it isnt going to be me...
> 
> This is the first time I'll have sent anything to this list, and I hadn't
> planned on sending anything for a long time to come, but I think in this
> case I must toss in my 2cents.
> While I understand the reasoning behind this, and might do the same thing if
> I was in your position, I feel it may be a mistake.
> I personaly do not trust the 2.4.x kernel entirely yet, and would prefer to
> wait for 2.4.1 or 2.4.2 before upgrading from 2.2.18 to ensure last-minute
> wrinkles have been completely ironed out, and I know there are people who
> share my viewpoint, and would rather use 2.2.XX for a while yet, and I'm
> afraid that this may partialy criple 2.2 driver development.
> It can take little or a lot of time to port a driver from 2.2 to 2.4, and in
> some cases people may just not want to do it untill 2.4 has gone through a
> little more refining, and that could take a while.
> 
> To sum it up, I just don't think this is the right decision to make, at
> least not yet.
> My opinion probably won't matter one bit, but I thought I might as well toss
> it out there.
> 
> -NK
-- 
Tim Riker - http://rikers.org/ - short SIGs! 
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.4.0ac1

[Bill Wendling]

Also sprach Keith Owens:
} On Thu, 04 Jan 2001 21:54:29 -0800, 
} Miles Lane <[EMAIL PROTECTED]> wrote:
} >make[4]: Entering directory `/usr/src/linux/drivers/acpi'
} >/usr/src/linux/Rules.make:224: *** Recursive variable `CFLAGS' references itself 
(eventually).  Stop.
} 
} In drivers/acpi/Makefile, delete the line
} 
} $(MODINCL)/%.ver: CFLAGS = -I./include $(CFLAGS)
} 
} You will be able to compile but acpi may not work with module symbol
} versions, so do not select module symbol versions.
} 
Changing that line to:

$(MODINCL)/%.ver: CFLAGS := -I./include $(CFLAGS)

might work as well...

-- 
|| Bill Wendling[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: How to Power off with ACPI/APM?

[Michael D. Crawford]

> How is each of your setups, ie, what is compiled in kernel and what is 
> a module ? My guess is: 
> - ACPI+APM in kernel: ACPI wins 
> - APM in kernel, ACPI module; APM starts, blocks ACPI 
> - and so on 

Nope.  If they're both in the kernel, APM wins.

When I built with both ACPI and APM, and then APM ran first.  ACPI started up in
the kernel, commented that APM was already there, and exited.

Many folks have given me tips on getting power off to work, I'll screw around to
see if I can get it to go.  But I guess the fact that ACPI exits if APM is
enabled is a real bug.

I know it's hip, cool and efficient to use modules but I often start by
hardwiring things into the kernel because I may not have stuff set up right yet
to load the modules after getting the new kernel.  Just saying Y instead of M
often makes things work without further trouble.

CONFIG_PM=y
CONFIG_ACPI=y
CONFIG_APM=y
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
# CONFIG_APM_DO_ENABLE is not set
# CONFIG_APM_CPU_IDLE is not set
# CONFIG_APM_DISPLAY_BLANK is not set
# CONFIG_APM_RTC_IS_GMT is not set
# CONFIG_APM_ALLOW_INTS is not set
# CONFIG_APM_REAL_MODE_POWER_OFF is not set


-- 
Michael D. Crawford
GoingWare Inc. - Expert Software Development and Consulting
http://www.goingware.com/
[EMAIL PROTECTED]

   Tilting at Windmills for a Better Tomorrow.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

You've Been Slashdotted

[Michael D. Crawford]

Even mighty ftp.kernel.org has fallen under the /. effect after they ran the
annoucenement:

http://slashdot.org/article.pl?sid=01/01/05/0049246&mode=thread

You're probably not going to have much luck getting any source off any servers
tonight.  Might I suggest you pop over to Slashdot and give the clueless some
clues on getting their new kernels working?  They need help.

Mike
-- 
Michael D. Crawford
GoingWare Inc. - Expert Software Development and Consulting
http://www.goingware.com/
[EMAIL PROTECTED]

   Tilting at Windmills for a Better Tomorrow.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Compilation error in Red Hat 6.2

[Peter Samuelson]

> Kindly let me know in which part comes the IDE, ext2 and ELF after
> running the command make menuconfig.

Oh come on, these things aren't *that* hard to find.  In any case,
judging from the device number 08:01, I suspect you are using SCSI
rather than IDE.  Check your SCSI options.  You must compile in (not as
modules) the SCSI disk driver as well as your host adapter.

If you are indeed using IDE, make sure you are passing the correct root
dev into the booting kernel.  Check your boot loader config (lilo.conf,
likely as not) or try the 'rdev' utility.

Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.4.0ac1

[Keith Owens]

On Thu, 04 Jan 2001 21:54:29 -0800, 
Miles Lane <[EMAIL PROTECTED]> wrote:
>make[4]: Entering directory `/usr/src/linux/drivers/acpi'
>/usr/src/linux/Rules.make:224: *** Recursive variable `CFLAGS' references itself 
>(eventually).  Stop.

In drivers/acpi/Makefile, delete the line

$(MODINCL)/%.ver: CFLAGS = -I./include $(CFLAGS)

You will be able to compile but acpi may not work with module symbol
versions, so do not select module symbol versions.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] StackGuard patch for 2.4.0

[Greg KH]

Just because I _know_ someone will ask me if I don't send this out, here
is the patch to allow the kernel to compile with the StackGuard version
of gcc.

thanks,

greg k-h

-- 
greg@(kroah|wirex).com


diff -Naur -X dontdiff linux-2.4.0/Makefile linux-2.4.0-greg/Makefile
--- linux-2.4.0/MakefileThu Jan  4 13:48:13 2001
+++ linux-2.4.0-greg/Makefile   Thu Jan  4 21:40:49 2001
@@ -228,6 +228,10 @@
 
 include arch/$(ARCH)/Makefile
 
+# if we have a StackGuard compiler, then we need to turn off the canary death handler 
+stuff
+CFLAGS += $(shell if $(CC) -fno-canary-all-functions -S -o /dev/null -xc /dev/null 
+>/dev/null 2>&1; then echo "-fno-canary-all-functions"; fi)
+CFLAGS += $(shell if $(CC) -mno-terminator-canary -S -o /dev/null -xc /dev/null 
+>/dev/null 2>&1; then echo "-mno-terminator-canary"; fi)
+
 export CPPFLAGS CFLAGS AFLAGS
 
 export NETWORKS DRIVERS LIBS HEAD LDFLAGS LINKFLAGS MAKEBOOT ASFLAGS
diff -Naur -X dontdiff linux-2.4.0/arch/i386/boot/compressed/Makefile 
linux-2.4.0-greg/arch/i386/boot/compressed/Makefile
--- linux-2.4.0/arch/i386/boot/compressed/Makefile  Tue Mar  7 11:04:12 2000
+++ linux-2.4.0-greg/arch/i386/boot/compressed/Makefile Thu Jan  4 21:40:49 2001
@@ -12,6 +12,12 @@
 CFLAGS = $(CPPFLAGS) -O2 -DSTDC_HEADERS
 ZLDFLAGS = -e startup_32
 
+# if we have a StackGuard compiler, then we need to turn off the canary death handler 
+stuff
+CFLAGS += $(shell if $(CC) -fno-canary-all-functions -S -o /dev/null -xc /dev/null 
+>/dev/null 2>&1; then echo "-fno-canary-all-functions"; fi)
+CFLAGS += $(shell if $(CC) -mno-terminator-canary -S -o /dev/null -xc /dev/null 
+>/dev/null 2>&1; then echo "-mno-terminator-canary"; fi)
+
+
+
 #
 # ZIMAGE_OFFSET is the load offset of the compression loader
 # BZIMAGE_OFFSET is the load offset of the high loaded compression loader

Re: Fw: Change of policy for future 2.2 driver submissions

[Mike Galbraith]

On Thu, 4 Jan 2001, Nicholas Knight wrote:

> since Mark posted his views to the list, I figured I could safely post the
> conversation I've been having with him in email

No excuse is good enough to justify posting private mail.

-Mike

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [linux-usb-devel] Re: Announce: modutils 2.4.0 is available

[Matthew Dharm]

On Thu, Jan 04, 2001 at 08:54:33PM -0800, David Brownell wrote:
> Miles had a suggestion for a "linux-hotplug" mailing list; this
> could have been a good issue to coordinate on such a smaller
> (lower traffic?) list.

Given that I (and many people on linux-scsi, it seems) are looking to
"hotplugging" as one of the major enhancements for 2.5.x development, this
is probably a good idea.  Can vger.kernel.org host this list?  Who do we
conatct about this?

Matt

-- 
Matthew Dharm  Home: [EMAIL PROTECTED] 
Maintainer, Linux USB Mass Storage Driver

It's not that hard.  No matter what the problem is, tell the customer 
to reinstall Windows.
-- Nurse
User Friendly, 3/22/1998

 PGP signature

Re: Linux 2.4.0ac1

[Miles Lane]

I get this error when attempting to compile.
I ran:

make mrproper
cp ../.config .
make oldconfig
make dep

make[4]: Entering directory `/usr/src/linux/drivers/acpi'
/usr/src/linux/Rules.make:224: *** Recursive variable `CFLAGS' references itself 
(eventually).  Stop.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] 8139too.c patch to allow setting of MAC address to actually work.

[Ben Greear]

This was gleaned from conversations with Donald Becker w/regard
to why:   ifconfig eth1 hw ether a:b:c:d:e:f
fails to work with the RTL drivers.

This fixes the problem, at least on my machine:

(The new line has ### in front of it..)

8139too.c, line 1229, from kernel 2.4.prerelease:

/* Check that the chip has finished the reset. */
for (i = 1000; i > 0; i--)
if ((RTL_R8 (ChipCmd) & CmdReset) == 0)
break;

/* Restore our idea of the MAC address. */
###RTL_W8_F  (Cfg9346, 0xC0); /* Fix provided by Becker */
RTL_W32_F (MAC0 + 0, cpu_to_le32 (*(u32 *) (dev->dev_addr + 0)));
RTL_W32_F (MAC0 + 4, cpu_to_le32 (*(u32 *) (dev->dev_addr + 4)));


The 2.2.18 driver is broken too, but I think Donald is going to send
the fixes for it.

Thanks,
Ben

-- 
Ben Greear ([EMAIL PROTECTED])  http://www.candelatech.com
Author of ScryMUD:  scry.wanfear.com (Released under GPL)
http://scry.wanfear.com   http://scry.wanfear.com/~greear
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

2.4.0-ac1 : 'make dep' drivers/acpi error

[Frank Davis]

Hello,
 I just downloaded 2.4.0-ac1 , and received the following error
during 'make dep':

make -C acpi fastdep
make[4]: Entering directory `/usr/src/linux/drivers/acpi'
/usr/src/linux/Rules.make:224: *** Recursive variable `CFLAGS' references
itself (eventually).  Stop.

I saw Keith's email about moving to make v3.77 or v3.79, if you are using
v3.78 . I confirmed that I am using make version v3.77 . So, it appears
that v3.77 doesn't work to compile drivers/acpi .
Should we look into patching Changes to make 3.79 the minimum version for
make, or 'fix' drivers/acpi (Makefile, Rules.make, etc.)? Has v3.79 been
confirmed to work? I understand v3.78 is confirmed broken.

Regards,
Frank
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] 2.4.0-prerelease: preemptive kernel.

[george anzinger]

Roger Larsson wrote:
> 
> On Thursday 04 January 2001 09:43, ludovic fernandez wrote:
> > Daniel Phillips wrote:
> > > The key idea here is to disable preemption on spin lock and reenable on
> > > spin unlock.  That's a practical idea, highly compatible with the
> > > current way of doing things.  Its a fairly heavy hit on spinlock
> > > performance, but maybe the overall performance hit is small.  Benchmarks
> > > are needed.
> >
> > I'm not sure the hit on spinlock is this heavy (one increment for lock
> > and one dec + test on unlock), but I completely agree (and volonteer)
> > for benchmarking.
> 
> And the conditional jump is usually predicted correctly :-)
> +static inline void enable_preempt(void)
> 
> +{
> +if (atomic_read(¤t->preemptable) <= 0) {
> +BUG();
> +}
> +if (atomic_read(¤t->preemptable) == 1) {
> 
> This part can probably be put in a proper non inline function.
> Cache issues...
> +/*
> +* At that point a scheduling is healthy iff:
> +* - a scheduling request is pending.
> +* - the task is in running state.
> +* - this is not an interrupt context.
> +* - local interrupts are enabled.
> +*/
> +if (current->need_resched == 1 &&
> +   current->state == TASK_RUNNING &&
> +   !in_interrupt()&&
> +   local_irq_are_enabled())
> +{
> +schedule();
> +}
>
Actually the MontaVista Patch cleverly removes the tests for
in_interrupt() and local_irq_are_enabled() AND the state ==
TASK_RUNNING.  In actual fact these states can be considered way points
on the system status vector.  For example the interrupts off state
implies all the rest, the in_interrupt() implies not preemptable and
finally, not preemptable is one station away from fully preemptable.  

TASK_RUNNING is easily solved by makeing schedule() aware that it is
being called for preemption.  See the MontaVista patch for details.


ftp://ftp.mvista.com/pub/Area51/preemptible_kernel/


 
> +}
> +atomic_dec(¤t->preemptable);
> 
> What if something happens during the schedule() that would require
> another thread...?
> 
> +}
> 
> I have been discussing different layout with George on Montavista
> also doing this kind of work... (different var and value range)
> 
> static incline void enable_preempt(void) {
> if (--current->preempt_count) {
> smp_mb(); /* not shure if needed... */
> preempt_schedule();
> }
> }
> 
> in sched.c (some smp_mb might be needed here too...)
> void preempt_schedule() {
> while (current->need_resched) {
> current->preempt->count++; /* prevent competition with IRQ code */
> if (current->need_resched)
> schedule();
> current->preempt_count--;
> }
> }
> 
> > I'm not convinced a full preemptive kernel is something
> > interesting mainly due to the context switch cost (actually mmu contex
> > switch).
> 
> It will NOT be fully, it will be mostly.
> You will only context switch when a higher prio thread gets runnable, two
> ways:
> 1) external intterupt waking higher prio process, same context swithes as
> when running in user code. We won't get more interrupts.
> 2) wake up due to something we do. Not that many places, mostly due to
> releasing syncronization objects (spinlocks does not count).
> 
> If this still is a problem, we can select to only preemt to processes running
> RT stuff. SCHED_FIFO and SCHED_RR by letting them set need_resched to 2...

The preemption ususally just switches earlier.  The switch would happen
soon anyway.  That is what need_resched =1; means.
> 
> > Benchmarking is a good way to get a global overview on this.
> 
> Remember to benchmark with stuff that will make the positive aspects visible
> too. Playing audio (with smaller buffers), more reliably burning CD ROMs,
> less hichups while playing video [if run with higher prio...]
> Plain throuput tests won't tell the whole story!
> 
> see
>  http://www.gardena.net/benno/linux/audio
>  http://www.linuxdj.com/latency-graph/
> 
> > What about only preemptable kernel threads ?
> 
> No, it won't help enough.
> 
> --
> --
> Home page:
>   http://www.norran.net/nra02596/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Fw: Change of policy for future 2.2 driver submissions

[Nicholas Knight]

since Mark posted his views to the list, I figured I could safely post the
conversation I've been having with him in email


- Original Message -
From: "Mark Hahn" <[EMAIL PROTECTED]>
To: "Nicholas Knight" <[EMAIL PROTECTED]>
Sent: Thursday, January 04, 2001 8:44 PM
Subject: Re: Change of policy for future 2.2 driver submissions


> > > I can safely claim that I've used 2.3 and 2.4 a lot more than you.
> > > while there have certainly been some bad kernels, many of them
> > > have been far more stable than any 2.2.
> >
> > Alan Cox himself has said he doesn't entirely trust 2.4, you're going to
> > dispute him?
>
> absolutely.

Alan Cox has the most credability in my view of any person in the linux
community (this is just my view, but I think it's pretty safe to say that
Alan is a very respected member of the linux community.) If he doesn't
entirely trust a kernel, I don't think I'd be very willing to either... this
combined with my experiences with 2.3 and 2.4 kernels leads me to mistrust
2.4 untill it's more refined

>
> > > > the simple fact is, DEVELOPMENT HAS TO OCCUR TO KEEP UP WITH CURRENT
> > > > HARDWARE AND NEEDS!
> > >
> > > I'm curious why you think 2.4 was developed at all.
> >
> > 2.4 contained MASSIVE changes to MANY aspects of the kernel, that's why
it's
> > 2.4 and not 2.2.19
> > 2.2.x's that included new drivers were neccisary while 2.4 was in
>
> I guess you don't read 2.2 patches.  it has contained MASSIVE changes
> to MANY aspects of the kernel.  about the only thing that has been
> off-limits is the SMP locking strategy (and that, by the way, is what
> Alan says his policy has been.)
>

> > take ATA/66 support, this needed to be avalible in a stable kernel, but
it
> > wasn't in original 2.2 kernels, but was added in 2.2.12 (or 14, can't
recall
> > precisely at the present time if it was .12 or .14)
>
> so 2.2 transmorgrified from "stable" to "development for conservatives"
> because 2.4 took so long.

according to kernel.org, there were *seven* 2.2 kernels not including the
original 2.2.0 prior to the day 2.3.0 was posted
there was also an 8th 2.2 kernel posted just hours before 2.3.0 was posted
on may 11th of 1999
this is not an abnormal pattern for linux
the linux kernel is simply too complex and still isn't to a point where you
can wait very long between kernel changes (i.e. as long as 2.2 to 2.4
took... or how long it would have taken even if 2.2 development had
completely *HALTED* and *everyone* concentraited *Entirely* on 2.4
again, take ATA/66, it should be considered an essential component of the
kernel, it NEEDED to be there, if they'd waited for 2.4 and all the changes
it had incorporated, there would have been some major problems



>
> > if you really feel this way, why not post it to the kernel list? then
maybe
>
> did.
>
> > when enough people explain it, you'll understand why development
continues
> > on stable kernels after they've been released
>
> nonsense.
>


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: USB problems with 2.4.0: USBDEVFS_BULK failed

[Greg KH]

On Thu, Jan 04, 2001 at 07:52:15PM -0800, Jordan Mendelson wrote:
> 
> Alright, this is driving me nuts. I have a Canon S20 digital camera
> hooked up to a Sony XG series laptop via the USB port and am using s10sh
> to access it. s10sh uses libusb 0.1.1, but I've also tried it using
> libusb 0.1.2 without any luck. libusb uses usbfs to access to the device
> from userspace. 
> 
> The last time it worked was around 2.4.0test10, but might have been
> test9. test12, prerelease and 2.4.0 final all fail.

Could you try to verify exactly which version things died on?  As you
know USB has had a number of changes to the code recently :)

That would help us try to determine what broke.

thanks,

greg k-h


-- 
greg@(kroah|wirex).com
http://immunix.org/~greg
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: make menuconfig: where's USB Mass Storage?

[Johannes Erdfelt]

On Fri, Jan 05, 2001, Keith Owens <[EMAIL PROTECTED]> wrote:
> On Fri, 5 Jan 2001 02:42:11 -0200, 
> Fr d ric L . W . Meunier <[EMAIL PROTECTED]> wrote:
> >Is this just me? Configuring 2.4.0 with make menuconfig with
> >CONFIG_EXPERIMENTAL=y I get no prompt for USB Mass Storage,
> >but the .config is saved with # CONFIG_USB_STORAGE is not set
> 
> CONFIG_USB_STORAGE is only available if you have both USB and SCSI
> selected.  Is that the correct combination?  I have no idea, but that
> is what is coded.

Yup, obviously USB is required, but USB storage devices are all SCSI
(atleast the class devices are), so we need the SCSI layer as well.

JE

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: make menuconfig: where's USB Mass Storage?

[Keith Owens]

On Fri, 5 Jan 2001 02:42:11 -0200, 
Fr d ric L . W . Meunier <[EMAIL PROTECTED]> wrote:
>Is this just me? Configuring 2.4.0 with make menuconfig with
>CONFIG_EXPERIMENTAL=y I get no prompt for USB Mass Storage,
>but the .config is saved with # CONFIG_USB_STORAGE is not set

CONFIG_USB_STORAGE is only available if you have both USB and SCSI
selected.  Is that the correct combination?  I have no idea, but that
is what is coded.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [linux-usb-devel] Re: Announce: modutils 2.4.0 is available

[David Brownell]

Matt --

> It's pretty much the same patch (functionally) as I posted to the
> linux-usb-devel mailing list, which I presumed would inform the hotplugging
> people.  Mea culpa, I seem to have been in error there.

Miles had a suggestion for a "linux-hotplug" mailing list; this
could have been a good issue to coordinate on such a smaller
(lower traffic?) list.

In this case, the ball just got dropped when it looked like this
patch wasn't even going to Linus.  After the Linux 2.4.0 change
notes, that ball just got picked up again!

- Dave


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

make menuconfig: where's USB Mass Storage?

[Frédéric L . W . Meunier]

Is this just me? Configuring 2.4.0 with make menuconfig with
CONFIG_EXPERIMENTAL=y I get no prompt for USB Mass Storage,
but the .config is saved with # CONFIG_USB_STORAGE is not set

I have the following:

#
# USB support
#
CONFIG_USB=m
# CONFIG_USB_DEBUG is not set
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_BANDWIDTH is not set
CONFIG_USB_UHCI_ALT=m
# CONFIG_USB_OHCI is not set
# CONFIG_USB_AUDIO is not set
# CONFIG_USB_BLUETOOTH is not set
# CONFIG_USB_STORAGE is not set
# CONFIG_USB_ACM is not set
CONFIG_USB_PRINTER=m
# CONFIG_USB_DC2XX is not set
# CONFIG_USB_MDC800 is not set
CONFIG_USB_SCANNER=m
# CONFIG_USB_MICROTEK is not set
# CONFIG_USB_IBMCAM is not set
# CONFIG_USB_OV511 is not set
# CONFIG_USB_DSBR is not set
# CONFIG_USB_DABUSB is not set
# CONFIG_USB_PLUSB is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_NET1080 is not set
# CONFIG_USB_USS720 is not set

#
# USB Serial Converter support
#
# CONFIG_USB_SERIAL is not set
# CONFIG_USB_RIO500 is not set

I checked a lot of times, and there's no such option here.

< >   OHCI (Compaq, iMacs, OPTi, SiS, ALi, ...) support
--- USB Device Class drivers
< >   USB Audio support
< >   USB Bluetooth support (EXPERIMENTAL)
< >   USB Modem (CDC ACM) support

-- 
0@pervalidus.{net, {dyndns.}org} Tel: 55-21-717-2399 (Niterói-RJ BR)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Change of policy for future 2.2 driver submissions

[Mark Hahn]

> I personaly do not trust the 2.4.x kernel entirely yet, and would prefer to
...
> afraid that this may partialy criple 2.2 driver development.

egads!  how can there be "development" on a *stable* kernel line?

maybe this is the time to reconsider terminology/policy:
does "stable" mean "bugfixes only"?  
or does it mean "development kernel for conservatives"?

me, I've run the "progressive" kernel line on production boxes since ~2.3.36.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[Announce] kdb v1.7 is available for 2.4.0

[Keith Owens]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Content-Type: text/plain; charset=us-ascii

http://oss.sgi.com/projects/kdb/download/ix86/ contains patches for kdb
v1.7 against kernel 2.4.0.

No significant changes since 2.4.0-test13 and 2.4.0-prerelease.  Just
fitting the patch to the new kernel.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.3 (GNU/Linux)
Comment: Exmh version 2.1.1 10/15/1999

iD8DBQE6VUqyi4UHNye0ZOoRAsT2AKDuZqYxy6c9yejqawPo4Z908iABVgCg80/x
DKMCyxQvwl2fAHMKxm+2eec=
=YofV
-END PGP SIGNATURE-

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Journaling: Surviving or allowing unclean shutdown?

[Alan Cox]

> I have an old IBM Aptiva 486 SX that actually DOES something like this; what
> it does is, it suspends to disk when you hit the power button (you have to
> turn that option on though).
> Point being, if it was possible back then (6 years ago), why on earth would
> it be too expensive now?

I'd guess the aptiva new was a bit over $100 ?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Journaling: Surviving or allowing unclean shutdown?

[Chipzz]

On Thu, 4 Jan 2001, Alan Cox wrote:

> From: Alan Cox <[EMAIL PROTECTED]>
> Subject: Re: Journaling: Surviving or allowing unclean shutdown?
> 
> > in an enbedded device you can
> > 1. setup the power switch so it doesn't actually turn things off (it
> > issues the shutdown command instead)
> 
> Costs too much money

I have an old IBM Aptiva 486 SX that actually DOES something like this; what
it does is, it suspends to disk when you hit the power button (you have to
turn that option on though).
I once actually had a situation where a badly behaved application prevented
this suspend-to-disk, and I had to pull the plug.
Point being, if it was possible back then (6 years ago), why on earth would
it be too expensive now?

Greetings,

Chipzz AKA
Jan Van Buggenhout
-- 

--
  UNIX isn't dead - It just smells funny
[EMAIL PROTECTED]
--

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Announce: modutils 2.4.0 is available

[Matthew Dharm]

Well, I'll be the one to fall on my sword...

This is probably my fault.  The matching code was pretty much broken for a
non-trivial subset of usb devices.  I'd submitted the patch to Linus before
the holdiays, but it was rejected for various reasons.  After some back and
forth, Linus finally accepted it on about the 2st of the year.

It's pretty much the same patch (functionally) as I posted to the
linux-usb-devel mailing list, which I presumed would inform the hotplugging
people.  Mea culpa, I seem to have been in error there.  Tho, that was
several weeks ago, so it may have just fallen out of people's heads in the
interim time.

Keith, if you need any info on what the new structure means, please let me
know and I can fill you in on all the details.

Matt

On Fri, Jan 05, 2001 at 02:56:29PM +1100, Keith Owens wrote:
> On Fri, 05 Jan 2001 13:59:12 +1100, 
> Keith Owens <[EMAIL PROTECTED]> wrote:
> >modutils-2.4.0.tar.gz   Source tarball, includes RPM spec file
> 
> I have just found out that there was an incompatible change to struct
> usb_device_id during 2.4.0-prerelease :(((.  That means that all
> versions of depmod will break on kernel 2.4.0 if you have any modules
> that use MODULE_DEVICE_TABLE(usb).  Incompatible changes to an ABI
> structure without notification immediately prior to a major kernel
> release, yech!
> 
> If you have usb modules then stay on kernel 2.4.0-prerelease or compile
> usb without modules or wait until I can test and release modutils
> 2.4.1.  The usb hotplug utilities will also have to change to handle
> the new table layout.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/

-- 
Matthew Dharm  Home: [EMAIL PROTECTED] 
Maintainer, Linux USB Mass Storage Driver

A:  The most ironic oxymoron wins ...
DP: "Microsoft Works"
A:  Uh, okay, you win.
-- A.J. & Dust Puppy
User Friendly, 1/18/1998

 PGP signature

Re: Announce: modutils 2.4.0 is available

[Keith Owens]

On Fri, 05 Jan 2001 13:59:12 +1100, 
Keith Owens <[EMAIL PROTECTED]> wrote:
>modutils-2.4.0.tar.gz   Source tarball, includes RPM spec file

I have just found out that there was an incompatible change to struct
usb_device_id during 2.4.0-prerelease :(((.  That means that all
versions of depmod will break on kernel 2.4.0 if you have any modules
that use MODULE_DEVICE_TABLE(usb).  Incompatible changes to an ABI
structure without notification immediately prior to a major kernel
release, yech!

If you have usb modules then stay on kernel 2.4.0-prerelease or compile
usb without modules or wait until I can test and release modutils
2.4.1.  The usb hotplug utilities will also have to change to handle
the new table layout.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

USB problems with 2.4.0: USBDEVFS_BULK failed

[Jordan Mendelson]

Alright, this is driving me nuts. I have a Canon S20 digital camera
hooked up to a Sony XG series laptop via the USB port and am using s10sh
to access it. s10sh uses libusb 0.1.1, but I've also tried it using
libusb 0.1.2 without any luck. libusb uses usbfs to access to the device
from userspace. 

The last time it worked was around 2.4.0test10, but might have been
test9. test12, prerelease and 2.4.0 final all fail.

I've compiled the uhci driver with debugging. The log starts before I
send the file transfer request to the camera and ends after the camera
blows up and disconnects itself. This was done using 2.4.0 final.

I have also included a protocol dump from s10sh, recorded during a
second attempt. It looks like s10sh might strip header bytes from the
log, but it should help somewhat.

Now as far as I can tell, we submit a bulk transfer request and start
reading. We want to read 2872 bytes (44 @ 64 bytes, 1 @ 56 bytes). We
read off 44 @ 64 bytes, but for some reason don't read off the last 56
bytes and a babble is detected.


Jordan

Jan  4 18:06:29 u2 kernel: klogd 1.3-3#33.1, log source = /proc/kmsg started.
Jan  4 18:06:29 u2 kernel: Inspecting /boot/System.map-2.4.0
Jan  4 18:06:29 u2 kernel: Loaded 13430 symbols from /boot/System.map-2.4.0.
Jan  4 18:06:29 u2 kernel: Symbols match kernel version 2.4.0.
Jan  4 18:06:29 u2 kernel: Loaded 145 symbols from 6 modules.
Jan  4 18:06:32 u2 kernel: usb-uhci.c: search_dev_ep:
Jan  4 18:06:32 u2 kernel: usb-uhci.c: submit_urb: scheduling cf2cfba0
Jan  4 18:06:32 u2 kernel: usb-uhci.c: uhci_submit_control start
Jan  4 18:06:32 u2 kernel: usb-uhci.c: Allocated qh @ c43809e0
Jan  4 18:06:32 u2 kernel: usb-uhci.c: uhci_submit_control end
Jan  4 18:06:32 u2 kernel: usb-uhci.c: submit_urb: scheduled with ret: 0
Jan  4 18:06:32 u2 kernel: usb-uhci.c: interrupt
Jan  4 18:06:32 u2 kernel: usb-uhci.c: process_transfer: len:8 status:3807 
mapped:0 toggle:0
Jan  4 18:06:32 u2 kernel: usb-uhci.c: process_transfer: len:32 status:381f 
mapped:0 toggle:1
Jan  4 18:06:32 u2 kernel: usb-uhci.c: process_transfer: len:32 status:381f 
mapped:0 toggle:0
Jan  4 18:06:32 u2 kernel: usb-uhci.c: process_transfer: len:32 status:381f 
mapped:0 toggle:1
Jan  4 18:06:32 u2 kernel: usb-uhci.c: process_transfer: len:22 status:3815 
mapped:0 toggle:0
Jan  4 18:06:32 u2 kernel: usb-uhci.c: process_transfer: len:0 status:190007ff 
mapped:0 toggle:1
Jan  4 18:06:32 u2 kernel: usb-uhci.c: uhci_clean_transfer: No more bulks for urb 
cf2cfba0, qh c43809e0, bqh , nqh 
Jan  4 18:06:32 u2 kernel: usb-uhci.c: unlink qh c43809e0, pqh c4380720, nxqh 
c43806e0, to 043806e0
Jan  4 18:06:32 u2 kernel: usb-uhci.c: process_transfer: (end) urb cf2cfba0, wanted 
len 118, len 118 status 0 err 0
Jan  4 18:06:32 u2 kernel: usb-uhci.c: dequeued urb: cf2cfba0
Jan  4 18:06:32 u2 kernel: usb-uhci.c: unlink td @ c4380e20
Jan  4 18:06:32 u2 kernel: usb-uhci.c: unlink td @ c4380de0
Jan  4 18:06:32 u2 kernel: usb-uhci.c: unlink td @ c4380ee0
Jan  4 18:06:32 u2 kernel: usb-uhci.c: search_dev_ep:
Jan  4 18:06:32 u2 kernel: usb-uhci.c: submit_urb: scheduling cf2cfba0
Jan  4 18:06:32 u2 kernel: usb-uhci.c: uhci_submit_bulk_urb: urb cf2cfba0, old 
, pipe c0008280, len 64
Jan  4 18:06:32 u2 kernel: usb-uhci.c: Allocated qh @ c4380aa0
Jan  4 18:06:32 u2 kernel: usb-uhci.c: uhci_submit_bulk: qh c4380aa0 bqh 0001 nqh 
c02595f2
Jan  4 18:06:32 u2 kernel: usb-uhci.c: submit_urb: scheduled with ret: 0
Jan  4 18:06:32 u2 kernel: usb-uhci.c: interrupt
Jan  4 18:06:32 u2 kernel: usb-uhci.c: process_transfer: len:64 status:393f 
mapped:0 toggle:0
Jan  4 18:06:32 u2 kernel: usb-uhci.c: uhci_clean_transfer: No more bulks for urb 
cf2cfba0, qh c4380aa0, bqh , nqh 
Jan  4 18:06:32 u2 kernel: usb-uhci.c: unlink qh c4380aa0, pqh c43806e0, nxqh 
c4380660, to 04380660
Jan  4 18:06:32 u2 kernel: usb-uhci.c: process_transfer: (end) urb cf2cfba0, wanted 
len 64, len 64 status 0 err 0
Jan  4 18:06:32 u2 kernel: usb-uhci.c: dequeued urb: cf2cfba0
Jan  4 18:06:32 u2 kernel: usb-uhci.c: unlink td @ c4380e60
Jan  4 18:06:32 u2 kernel: usb-uhci.c: unlink td @ c4380d60
Jan  4 18:06:32 u2 kernel: usb-uhci.c: unlink td @ c4380ea0
Jan  4 18:06:32 u2 kernel: usb-uhci.c: unlink td @ c4380d20
Jan  4 18:06:32 u2 kernel: usb-uhci.c: unlink td @ c4380f20
Jan  4 18:06:32 u2 kernel: usb-uhci.c: unlink td @ c4380da0
Jan  4 18:06:32 u2 kernel: usb-uhci.c: search_dev_ep:
Jan  4 18:06:32 u2 kernel: usb-uhci.c: submit_urb: scheduling cf2cfba0
Jan  4 18:06:32 u2 kernel: usb-uhci.c: uhci_submit_bulk_urb: urb cf2cfba0, old 
, pipe c0008280, len 2872
Jan  4 18:06:32 u2 kernel: usb-uhci.c: Allocated qh @ c43809e0
Jan  4 18:06:32 u2 kernel: usb-uhci.c: uhci_submit_bulk: qh c43809e0 bqh 0001 nqh 
c02595f2
Jan  4 18:06:32 u2 kernel: usb-uhci.c: submit_urb: scheduled with ret: 0
Jan  4 18:06:32 u2 kernel: usb-uhci.c: interrupt
Jan  4 18:06:32 u2 kernel: usb-uhci.c: interrupt, status 3, frame# 1648

Re: Chipsets, DVD-RAM, and timeouts....

[Andre Hedrick]

Because I was not prepared for the sudden release!
Nor is the TIME Solution that is in final testing.

On Fri, 5 Jan 2001, Hakan Lennestal wrote:

> 
> 2.4.0 and still no IBM DTLA drives in the hpt366 bad_ata66_4 list
> (or udma 66 disabled by default in any other way).
> 
> /Håkan
> 
> In message <[EMAIL PROTECTED]>, David Woodhouse writes:
> > 
> > The IBM DTLA drives aren't in the hpt366 bad_ata66_4 list still.
> 
> 
> 
> ---
> e-mail: [EMAIL PROTECTED] |
>  or [EMAIL PROTECTED]   |
> ---
> 

Andre Hedrick
CTO Timpanogas Research Group
EVP Linux Development, TRG
Linux ATA Development

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

user-mode port 0.37-2.4.0

[Jeff Dike]

The user-mode port of 2.4.0 is available.

It was updated to 2.4.0 and that's it.

The project's home page is http://user-mode-linux.sourceforge.net

The project's download page is http://sourceforge.net/project/filelist.php?grou
p_id=429

Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Anyone else interested in a high-precision monotonic counter?

[Manfred Bartz]

"Christopher Friesen" <[EMAIL PROTECTED]> writes:

> Has anyone ever considered including a microsecond-precision
> monotonically-increasing counter in the kernel?  This would allow for
> easy timing of alarms and such by using absolute values of when the
> alarm should expire rather than a list of deltas from previous alarms.
> 
> The thing I have in mind would store a value something like "xtime"
> (maybe call it "ytime"?) in the kernel.  This value would be initialized
> to zero on startup, and would be incremented at the same time as
> "xtime".  However, while "xtime" reflects adjustments to the actual
> system time (settimeofday(), date, ntp, etc.), this value would not. 
> Finally, it would be accessed with a system call essentially identical
> to sys_gettimeofday(), only it would access "ytime" instead of "xtime"
> before going down and getting the microseconds from the RTC.
> 
> This doesn't seem to me as though it would be all that tricky to add,
> and I could see it being very useful in providing a timing source that
> is guaranteed to 
> a) be accurate to microseconds and 
> b) never go backwards.

Why a new system call?  

regarding a:  it could have microsecond resolution but not
  microseconds accuracy.
regarding b:  have you looked at the return-value of times(2)
  Or roll your own using setitimer(2)
-- 
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Change of policy for future 2.2 driver submissions

[Nicholas Knight]

- Original Message -
From: "Alan Cox" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, January 04, 2001 6:41 PM
Subject: Change of policy for future 2.2 driver submissions


>
> Linux 2.4 is now out, it is also what people should be concentrating on
first
> when issuing production drivers and driver updates. Effective from this
point
> 2.2 driver submissions or major driver updates will only be accepted if
the
> same code is also available for 2.4.
>
> Someone has to do the merging otherwise, and it isnt going to be me...

This is the first time I'll have sent anything to this list, and I hadn't
planned on sending anything for a long time to come, but I think in this
case I must toss in my 2cents.
While I understand the reasoning behind this, and might do the same thing if
I was in your position, I feel it may be a mistake.
I personaly do not trust the 2.4.x kernel entirely yet, and would prefer to
wait for 2.4.1 or 2.4.2 before upgrading from 2.2.18 to ensure last-minute
wrinkles have been completely ironed out, and I know there are people who
share my viewpoint, and would rather use 2.2.XX for a while yet, and I'm
afraid that this may partialy criple 2.2 driver development.
It can take little or a lot of time to port a driver from 2.2 to 2.4, and in
some cases people may just not want to do it untill 2.4 has gone through a
little more refining, and that could take a while.

To sum it up, I just don't think this is the right decision to make, at
least not yet.
My opinion probably won't matter one bit, but I thought I might as well toss
it out there.

-NK


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Announce: ksymoops 2.4.0 is available

[Keith Owens]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Content-Type: text/plain; charset=us-ascii

Mirror at ftp://ftp..kernel.org/pub/linux/utils/kernel/ksymoops/v2.4

ksymoops-2.4.0.tar.gz   Source tarball, includes RPM spec file
ksymoops-2.4.0-1.src.rpmAs above, in SRPM format
ksymoops-2.4.0-1.i386.rpm   Compiled with egcs-2.91.66, glibc 2.1.2

Changelog extract

* Clone from ksymoops 2.3.6.
* Correct DEF_VMLINUX.  Eirikur Hjartarson.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.3 (GNU/Linux)
Comment: Exmh version 2.1.1 10/15/1999

iD8DBQE6VTsNi4UHNye0ZOoRAuLLAJ9lof9VNXJKoUlZFwnTnPRpfk2/RACgjiDo
6f3pscCbZBSuek/BeGG0SnI=
=cb5z
-END PGP SIGNATURE-

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Crypto in 2.4

[Jon Masters]

Hello,

I am aware of work being done to create crypto patches for 2.4 however I
am wondering what kind of time scale is likely to be involved before a
patch for 2.4.0 becomes available and, more importantly, when such a
patch will be suitable for daily use (disclaimers withstanding
obviously).

Let's just say I'm cautious after a bad experience with one of the
previous dud patch releases :P

Thanks,
Jonathan.

P.S. Congrats to everyone involved with 2.4 - I guess the
"vapourwareists" finally got what they wanted.

-- 
 _ [EMAIL PROTECTED] _
| Technical, Easy Penguin.  +44 777 61 31337   GPG keys available. |
|"And am I, who lived but for my country" [quote: Robert Emmet]|
  http://www.jonmasters.org.uk 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Announce: modutils 2.4.0 is available

[Keith Owens]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Content-Type: text/plain; charset=us-ascii

ftp://ftp..kernel.org/pub/linux/utils/kernel/modutils/v2.4

modutils-2.4.0.tar.gz   Source tarball, includes RPM spec file
modutils-2.4.0-1.src.rpmAs above, in SRPM format
modutils-2.4.0-1.i386.rpm   Compiled with egcs-2.91.66, glibc 2.1.2
modutils-2.4.0-1.sparc.rpm  Compiled for combined sparc 32/64
patch-2.4.0-persistent.gz   Adds persistent data and generic string
support to kernel 2.4.0.

Changelog extract

* Clone from modutils 2.3.24.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.3 (GNU/Linux)
Comment: Exmh version 2.1.1 10/15/1999

iD8DBQE6VTh8i4UHNye0ZOoRArO+AJ9JLhwmcwBWeZJDUpiS66W8lONsxgCfRl1U
YVvqJZzTbl5ewcc6vI0juFA=
=wKRG
-END PGP SIGNATURE-

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

ACPI in Via Apollo (vt82C686) broken badly in 2.4.x ?

[safemode]

Well, it seems the only way to look at sensor readings with lmsensors is
to activate acpi in linux for my motherboard.  According to the docs, my
motherboard is supposed to be supported and is detected when linux
boots, the problem comes when i try to move the mouse (in console and
X).  It totally flips out, i get irregular mouse movement across the
screen and button clicks when i just barely touched it.  It is directly
related to enabling acpi so i was wondering if anyone else has had this
problem and if there was/is a fix for it or if it's a bug right now.
If there is specific debugging info that i can get to help, tell me
where... dmesg just shows successful messages.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Change of policy for future 2.2 driver submissions

[Alan Cox]

Linux 2.4 is now out, it is also what people should be concentrating on first
when issuing production drivers and driver updates. Effective from this point
2.2 driver submissions or major driver updates will only be accepted if the
same code is also available for 2.4.

Someone has to do the merging otherwise, and it isnt going to be me...

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Linux 2.4.0ac1

[Alan Cox]

ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4

2.4.0-ac1
o   Resync with Linus
o   Fix serial compile bug  (Bill Notthingham)
o   Clean up lapbether  (Hans Grobler)
o   Fix endian handling in ne.c (Geert Uytterhoeven)
o   Fix root umount handling(Chris Mason &
 Al Viro)
o   Bring wan drivers up to scratch for 2.4 (Krzysztof Halasa)
o   SD module locking fix   (Oliver Neukum)
o   Merge S/390 32/64bit ports  (IBM)
| some rough edges to tidy up yet - guys can
| you change the DMA ifdefs to match 2.2 style..

2.4.0prerelease-ac6
o   Cleanup econet  (Hans Grobler)
o   Further amateur radio cleanups  (Hans Grobler)
o   Fix irda/SMP deadlocks  (Marc Zyngier)
o   Further YAM fixes   (Hans Grobler)
o   Fix rio500 locking bug  (Greg Kroah-Hartmann)
o   Fix isdn net leak on error  (Arnaldo Carvalho de Melo)
o   Fix proc_get_inode export (for comx)(Hans Grobler)
o   Fix locking error on get_swap_page  (Marcelo Tosatti)
o   Fix further warnings, and other stuff new gcc   (Arjan van de Ven)
shows up
o   Add isapnp module device tables to drivers  (Bill Nottingham)
[Added to ns558, serial, ide-pnp, cadet,
 3c509,3c515, aironet4500,ne,sb1000, aha1542,
 NCR5380, ad1816, awe_wave, sb, ixj]
o   Resync with Linus prepatch

2.4.0prerelease-ac5
o   Resync with Linus prepatch
o   One liner microcode driver fix  (Tigran Aivazian)
o   Fix ACPI ksyms problems (Keith Owens)
o   Correctly resync ide-cd fixes   (Byron Stanoszek)
o   Fix i2o block driver race   (Arjan van de Ven)
o   Acorn makefile/driver fixes (Russell King)
o   Make cyberfb use pci_get_drvdata(Russell King)
o   Kill redundant ARM timer irq code   (Russell King)
o   Remove some ARM hacks from fbmem.c  (Russell King)
o   Fix config bugs with fusion, indenting  (Andrzej M. Krzysztofowicz)
o   Handle bootmem order changes in arm (Russell King)
o   SA1100 update   (Russell King)
o   Handle ALI AGP flushes  (??)
o   Merge some of the PPC changes   (Cort Dougan)

2.4.0prerelease-ac4
o   DecNET updates  (Steve Whitehouse)
o   Devices.txt typo fix(Roberto Nibali)
o   Fix 15-23bit direct colour in logos (Geert Uytterhoeven)
o   Correct framebuffer device.txt  (Geert Uytterhoeven)
o   Small mkiss fixes   (Hans Grobler)
o   Fix write off end of disk bug   (Jari Ruusu)

2.4.0prerelease-ac3
o   Fix cs46xx driver crash (David Huggins-Daines)

2.4.0prerelease-ac2
o   Fix further CVS gcc compile warnings(Rich Baum)

2.4.0prerelease-ac1
o   Merge with Linux prerelease

2.4.0test13pre7-ac1
o   Merge Linus pre7
o   Fix eepro100 on machines with unsigned char (Russell King)
o   Give the FIQ on the ARM its own handlers(Russell King)
o   Update ARM mm code  (Russell King)
o   Fix ARM optimisations   (Russell King)
o   Update arm initd patch  (Russell King)
o   Improve ARM I/O operations  (Russell King)
o   ARM boot code updates   (Russell King)
o   ARM scsi driver updates (Russell King)
o   Update ARM makefiles to new style   (Russell King)
o   Add missing sections to arm link script for glue(Russell King)
o   Update ARM io includes  (Russell King)
o   Clean up frame pointer printing on ARM traps(Russell King)
o   Update ARM machine definitions  (Russell King)
o   Move the ARM task unmapped base definition  (Russell King)
o   Remove ARM specific hacks from char/mem.c   (Russell King)
o   Fix BIOS32 code for ARM (Russell King)
o   Back out bogus SMP halt change  (Andi Kleen)
o   Update logo palette handling(Geert Uytterhoeven)
o   Drop out the compiler selector (2.96/7 seem to work)

2.4.0test13pre6-ac1
o   Merge Linus pre6

2.4.0test13pre5-ac1
o   Merge Linus pre5

2.4.0test13pre4-ac2
o   Further quota build fix (Jarno Paananen)
o 

2.4.0 module compile error (DRI for ATI Rage?)

[stewart]

{standard input}: Assembler messages:
{standard input}:8: Warning: Ignoring changed section attributes for
.modinfo
gcc -D__KERNEL__ -I/local/build/2.4.0/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2
-march=i686 -DMODULE -DMODVERSIONS -include
/local/build/2.4.0/include/linux/modversions.h   -c -o r128_cce.o r128_cce.c
r128_cce.c: In function `r128_cce_init_ring_buffer':
r128_cce.c:339: structure has no member named `agp'
r128_cce.c:333: warning: `ring_start' might be used uninitialized in this
function
r128_cce.c: In function `r128_cce_packet':
r128_cce.c:1023: warning: unused variable `size'
r128_cce.c:1021: warning: unused variable `buffer'
r128_cce.c:1019: warning: unused variable `dev_priv'
{standard input}: Assembler messages:
{standard input}:8: Warning: Ignoring changed section attributes for
.modinfo
make[3]: *** [r128_cce.o] Error 1
make[3]: Leaving directory `/local/build/2.4.0/drivers/char/drm'
make[2]: *** [_modsubdir_drm] Error 2
make[2]: Leaving directory `/local/build/2.4.0/drivers/char'
make[1]: *** [_modsubdir_char] Error 2
make[1]: Leaving directory `/local/build/2.4.0/drivers'
make: *** [_mod_drivers] Error 2


from a clean, unpatched 2.4.0 source base. 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [patch] big udelay's in fb drivers (2.4.0-prerelease)

[Alan Cox]

>  udelay(15000); /* delay 15ms */
> 
> the comment is just extra baggage. No sense touching it generally, but if
> you're gonna change it to mdelay..

The comments are 15 (50) implying someone swapped them around for a reason
and noted it
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Can I submit a bug report on this mailing list?

[Evan Thompson]

Alright.

I hear about the 2.4.0 release.  I have, in my mailbox, many messages
titled "Re: And oh, btw...", BUT NO ORIGINAL MESSAGE!  What happened?
Is my stupid mailserver selective or something?

Anyways.  My bug report is: "[EMAIL PROTECTED] does not send
me important mails that are important and that should be sent due to
their high importancy."
-- 
+--+---+
| Evan Thompson|POWERED BY:|
| [EMAIL PROTECTED]   | Linux cd168990-a 2.4.0-prerelease |
| Freelance Computer Nerd  |  #1 Wed Jan 3 16:30:45 CST 2001   |
| http://evaner.penguinpowered.com |   i686 unknown (2001/01/02 19:35) |
+--+---+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] reiserfs patch for 2.4.0-prerelease

[Ed Tomlinson]

Hi,

I have been doing some dbench runs with the original and latest (Jan 4 22:xx) 
prerelease.diff kernels.  Looks like both the latest kernels and the reiserfs 
patch both are costing some performance.

prerelease
MB/susersystem  cpu time
ext214.650.5s76.4s  29%  7:14.9m
ext212.650.9s76.7s  25%  8:23.6m

reiser  14.553.8s   149.2s  46%  7:16.1m
reiser  10.754.1s   154.5s  35%  9:49.9m

prerelease (2.4.0 jan 4 22:xx)
MB/susersystem  cpu time
ext210.552.8s81.5s  22% 10:02.3m

reiser   5.854.6s   198.5s  23% 18:12.5m
reiser   6.455.1s   188.7s  24% 16.19.3m

Using the notail reiserfs mount option improves the reiserfs numbers 10-20% 
with both kernels.

All benchmarks run on a K6-III 400 with 128M just after boot with no X 
running.

Comments?
Ed Tomlinson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Chipsets, DVD-RAM, and timeouts....

[Hakan Lennestal]

2.4.0 and still no IBM DTLA drives in the hpt366 bad_ata66_4 list
(or udma 66 disabled by default in any other way).

/Håkan

In message <[EMAIL PROTECTED]>, David Woodhouse writes:
> 
> The IBM DTLA drives aren't in the hpt366 bad_ata66_4 list still.



---
e-mail: [EMAIL PROTECTED] |
 or [EMAIL PROTECTED]   |
---

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: How to Power off with ACPI/APM?

[James H. Cloos Jr.]

> "JA" == J A Magallon <[EMAIL PROTECTED]> writes:

JA> How is each of your setups, ie, what is compiled in kernel and
JA> what is a module ? 

Good point.  I never tried w/ APM in kernel and ACPI as module.  Just
both in and ACPI in / APM module.  (And that last was only due to
operator error when configing the kernel.)

Kernel version may also be a factor when both are in.

-JimC
-- 
James H. Cloos, Jr.   1024D/ED7DAEA6 
<[EMAIL PROTECTED]>  E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

compile problem in prerelease-ac6 on alpha

[Peter De Schrijver]

Hi,

At line 1156 of kernel/sched.c a function is called which only seems to exist
on ia32 (show_trace). I guess this should be :

#if __i386__
show_trace(p->thread.esp):
#endif

Cheers,

Peter.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [patch] big udelay's in fb drivers (2.4.0-prerelease)

[Oliver Xymoron]

On Fri, 5 Jan 2001, Alan Cox wrote:

> > Once the comments are unweirded, they become completely superfluous. At
> > which point its best not to have them - when someone next comes along and
> > changes the delay, it might end up disagreeing with the comment and
> > causing confusion.
>
> Before you remove the comments check with the author and the manuals.

Huh? Granted that's generally a good idea, but if you've got code that
says

 udelay(15000); /* delay 15ms */

the comment is just extra baggage. No sense touching it generally, but if
you're gonna change it to mdelay..

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: How to Power off with ACPI/APM?

[J . A . Magallon]

On 2001.01.05 J . A . Magallon wrote:
> 
> > 
> > Either way you need the userspace daemon running to actually do
> > anything.  Even my notebook's key for toggling full-screen vs
> > un-expanded display on the lcd does nothing unless apmd or acpid
> > as applicable are running
> > 

I forgot it. If you just want to power-off:
- activate APM in the BIOS
- activate APM in kernel

I have an SMP box, so APM does not work fully, but just power-off works.
So if for any reason you box says is not capable of doing APM, add this
to lilo.conf:
append="apm=power-off"
so at least this will work.

-- 
J.A. Magallon $> cd pub
mailto:[EMAIL PROTECTED] $> more beer

Linux werewolf 2.2.19-pre6 #1 SMP Wed Jan 3 21:28:10 CET 2001 i686

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Printing to off-line printer in 2.4.0-prerelease

[Jesse Pollard]

On Thu, 04 Jan 2001, Gunther Mayer wrote:
>Jesse Pollard wrote:
>> Originally, (wayback machine on) this was handled by a pull-up resistor
>> in the parallel interface, on the "off-line" signal. ANY time the printer
>> was powered off, set offline, or cable unplugged, the "off-line" signal
>> was raised by the pull-up. No data lost.
>> 
>> Now the parallel interface is bidirectional, and can have multiple devices
>> attached - this "fix" cannot be used. The interface is now more of a
>> buss than a single attached interface, and signals from a missing device
>> (powered off or disconnected) are floating. They may float high or low,
>> and depending on the environment (and which end of the cable is unplugged)
>> any thing in between.
>
>Not true. Electrical characteristics for parallel port implementations/cards
>differ wildly, nevertheless most implementations have:
>- data lines: bidirectional (see datasheets)
>- signal lines: see datasheets, never floating !
>
>Floating signal lines are a silicon bug/bad engineering and have nothing
>to do with bidirectional interfaces ! 

I didn't mean to imply that it was - just that it is much harder to determine
if the device is attached or detatched. That depends on the characteristics of
the interface and the cable (acting as an antenna).

>
>Nowadays most integrated chips have internal signal line pull-ups internally, e.g. 
>W83877TF says:
>-BUSY, ACK, PE, SLCT, ERR:
>  TTL level input pin. This pin is pulled high internally.
>-AFD, STB, INIT, SLIN
>  Open-drain output pin with 12 mA sink capability. Pulled up internally.
>-Data lines:
>  TTL level bi-directional with 24 mA source-sink capability.
>
>Of course I would expect add-in cards to exist, with not so sophisticated chipsets
>and makers that have "forgotten" external pull-ups for economical reasons (2 cents :-)
>We should NOT care for broken hardware !!! I haven't seen any of these yet, even.
>
>On the other hand printer implmentations vary wildly, too.
>LJ1100: leave signal lines alone if powered off (0x7f)
>i.e. signal printer-not-ready ack-active out-of-paper
>DJ500: signal printer-error and off-line when powered off (0x87) !!!
>=> Linux would dump data on this printer, if switched off.
>
>I think the current linux lp code tries to handle exotic/weird printers 
>gracefully and leaves mainstream printers and users alone.

It all depends - I've seen printers work perfectly ... and yet others
completely fail. The Xerox 5700 printers wouldn't work if the cable were
over 9 feet long. They would if a high signal quality data cable were obtained,
worked at 15', but no longer than that. Even then, they would not identify
(and neither would Zerox) what happens when they were powered off (you loose
data).

And yet no problem with a HP laserjet at 40'.

And the signals do vary if it is unplugged at the printer end and not
at the host end (major difference - shielded cable works MUCH better).

-- 
-
Jesse I Pollard, II
Email: [EMAIL PROTECTED]

Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: How to Power off with ACPI/APM?

[egger]

On  4 Jan, Michael D. Crawford wrote:

> I got the message "Power Down" but my system stayed on and I was still
> in my shell.
 
> I'm using the binary of halt that came with Slackware 7.1.  Do I need
> to update any of my executable programs to work with the new kernel? 
> The only thing I've done is installed the latest modutils.  I did
> download the latest util-linux from kernel.org but this didn't appear
> to have the same program Slackware uses - there's a shutdown program,
> but on slackware I think shutdown is a script and there's a halt
> binary with reboot symlinked to it.

 Try the different APM options in the kernel. One will for sure work
 with your system.

-- 

Servus,
   Daniel

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: How to Power off with ACPI/APM?

[J . A . Magallon]

On 2001.01.05 James H. Cloos Jr. wrote:
> Michael> APM gives its message first in the boot process, then later
> Michael> ACPI does.  But ACPI says something like "APM already
> Michael> present, exiting", so the doc is wrong both ways you read it,
> Michael> or else ACPI doesn't succeed in the intended behavior to
> Michael> override APM.
> 
> I get th eopposite behavior.  If both are compiled in only ACPI works.
> (Only tested w/ 2.4.0-test kernels, though.)
> 
> Either way you need the userspace daemon running to actually do
> anything.  Even my notebook's key for toggling full-screen vs
> un-expanded display on the lcd does nothing unless apmd or acpid
> as applicable are running
> 

How is each of your setups, ie, what is compiled in kernel and what is
a module ? My guess is:
- ACPI+APM in kernel: ACPI wins
- APM in kernel, ACPI module; APM starts, blocks ACPI
- and so on

-- 
J.A. Magallon $> cd pub
mailto:[EMAIL PROTECTED] $> more beer

Linux werewolf 2.2.19-pre6 #1 SMP Wed Jan 3 21:28:10 CET 2001 i686

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: And oh, btw..

[Linus Torvalds]

On Thu, 4 Jan 2001, Marcelo Tosatti wrote:
>
> I have 1 patch which has not been answered and I still dont know if you
> want it only for 2.5.

The swap clustering looks ok, but it also looked like something I could
safely delay until a bit later in the 2.4.x series. Basically, the
PageDirty handling is new enough that I didn't want to add any other
wrinkles on top of it, even if they looked clean..

Life does not end at 2.4.0. Think o fit more as a "no more excuses"
release.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: How to Power off with ACPI/APM?

[James H. Cloos Jr.]

Michael> APM gives its message first in the boot process, then later
Michael> ACPI does.  But ACPI says something like "APM already
Michael> present, exiting", so the doc is wrong both ways you read it,
Michael> or else ACPI doesn't succeed in the intended behavior to
Michael> override APM.

I get th eopposite behavior.  If both are compiled in only ACPI works.
(Only tested w/ 2.4.0-test kernels, though.)

Either way you need the userspace daemon running to actually do
anything.  Even my notebook's key for toggling full-screen vs
un-expanded display on the lcd does nothing unless apmd or acpid
as applicable are running

-JimC
-- 
James H. Cloos, Jr.   1024D/ED7DAEA6 
<[EMAIL PROTECTED]>  E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: And oh, btw..

[Linus Torvalds]

On Thu, 4 Jan 2001, Miles Lane wrote:
>
> Is there a patch against test12 somewhere?  I don't see it.

In v2.4/test-kernels:
 patch-2.4.0-prerelease.gz - patch from test12 to the prerelease
 prerelease-to-final.gz - patch from prerelease to final.

And it will apparently take some time for the ftp servers to sync up: when
I moved the test-kernels away from the main v2.4 directory I didn't think
of the fact that the mirror scripts will spend quite a bit of time just
synchronizing everything (the fact that _I_ did it with a simple "mv" on
the master copies doesn't mean that the mirror services will be able to do
it ;)

Right now the sync from the master copy has gotten to the patches in the
test directory, which means that it shouldn't take more than maybe 15
minutes until everything has been synched - but I suspect that if people
pound on ftp.kernel.org it will only slow stuff down further, so try to
see if you can find other mirrors that got in early and don't synchronize
the test-kernels...

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: And oh, btw..

[J . A . Magallon]

On 2001.01.05 Alan Cox wrote:
> > http://www.kernel.org/pub/linux/kernel/testing/prerelease-diff
> > Please don't flood kernel.org though... use a mirror.
> 
> You'll find the proper 2.4.0 on
> 
>   ftp://ftp.linux.org/pub/linux/linux-2.4/linux-2.4.0.tar.gz
> 

Also ftp://ftp.uk.linux.org/pub/linux/linux-2.4/linux-2.4.0.tar.gz,
seems less saturated. 15 Kb/s from Spain over cable-modem.

-- 
J.A. Magallon $> cd pub
mailto:[EMAIL PROTECTED] $> more beer

Linux werewolf 2.2.19-pre6 #1 SMP Wed Jan 3 21:28:10 CET 2001 i686

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: And oh, btw..

[Alan Cox]

> > http://www.kernel.org/pub/linux/kernel/testing/prerelease-diff
> > Please don't flood kernel.org though... use a mirror.
> 
> You'll find the proper 2.4.0 on
> 
>   ftp://ftp.linux.org/pub/linux/linux-2.4/linux-2.4.0.tar.gz

Oops slight detail error

ftp.linux.org.uk


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] 2.4.0-prerelease: preemptive kernel.

[Alan Olsen]

On Fri, 5 Jan 2001, Andi Kleen wrote:

> On Thu, Jan 04, 2001 at 04:36:32PM -0800, ludovic fernandez wrote:
> > Saying that, I definitely agree that I want/need to one day listen to
> > my MP3s while building  my kernel.
> 
> ??? I can listen to MP3s just fine while building kernels, on a not very
> powerful K6. 

I have found that sound card "hick-ups" while doing heavy work under Linux
are an indication of an IRQ problem.  I had that problem on my P-III 650
until I went in and rearranged cards and sorted out what was on what IRQ.
(The BIOS just picked numbers, it gave you no way to determine order or
slots.  What IRQ you got depended on the slot and there was no real way
to chenge it.) 

Some boards have a very poor way of chosing the assignment
of IRQs. You just have to shuffle things until you get what you want. 

Since I did the manual reorg of the hardware, things have run MUCH
smoother.

[EMAIL PROTECTED] | Note to AOL users: for a quick shortcut to reply
Alan Olsen| to my mail, just hit the ctrl, alt and del keys.
"In the future, everything will have its 15 minutes of blame."

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Journaling: Surviving or allowing unclean shutdown?

[Stefan Traby]

On Thu, Jan 04, 2001 at 10:49:46PM +, Stephen C. Tweedie wrote:
> > I think any other action (only replaying on rw mount and presenting
> > a broken filesystem on ro) is quite fatal, at least if I think of
> > a replay on -remount,rw :)
> 
> Correct.
> 
> > Also, an unconditional hidden replay even if "ro" is specified is not nice.
> 
> > This is especially critical on root filesystem
> 
> In what way?  A root fs readonly mount is usually designed to prevent
> fsck can run without the filesystem being volatile.  That's the only

There are people out that say that readonly mount was
initially designed to behave as physically read only.
fsck was a wanted side-effect...
And trust me, most people think so before dialing
with a journaled filesystem. This was discussed
to death on the reiserFS list.

Clearly the definition of "ro" is weak, does it mean media or
filesystem view ? It's even weak on lower levels: There are
also disks out there that write even if physical write-protection
is enabled (for example auto-remapping after an ECC-recovery read).

Anyway, it is "especially" critical on the root filesystem because the
authors of filesystems can't support two ro states on boot.

Reiserfs allowed  -oro,noreplay.

Please tell me how to specify "noreplay" for the initial "/" mount
:)

Yes, I think that the journal is an integral part of the filesystem.
But this has nothing to do with forcing a write on "ro" mounts, which
I interpret as design bug. (ro,noreplay is also a kind of design bug,
everything except a virtual replay under physical ro conditions looks
like a design bug to me because it breaks user expectations either
by writing on "ro" or by giving an invalid view by "noreplay")

-- 

  ciao - 
Stefan

" ( cd /lib ; ln -s libBrokenLocale-2.2.so libNiedersachsen.so ) "

Stefan TrabyLinux/ia32   fax:  +43-3133-6107-9
Mitterlasznitzstr. 13   Linux/alphaphone:  +43-3133-6107-2
8302 Nestelbach Linux/sparc   http://www.hello-penguin.com
Austriamailto:[EMAIL PROTECTED]
Europe   mailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] 2.4.0-prerelease: preemptive kernel.

[Daniel Phillips]

ludovic fernandez wrote:
> Right now I will be interested to run some benchmarks (latency but
> also performance) to see how the system is disturbed by beeing
> preemptable. I'm little bit lost on this and I don't know where to start.
> Do you have any pointers on benchmark suites I could run ?
> Also, maybe it's a off topic subject now

No!  Not off topic.  And I hope you don't throw away that simple patch,
it will always be useful for doing reality checks on the performance of
the fancy system, and who knows, maybe it's useful in its own right.

The current fashion is to use dbench:

  ftp://samba.org/pub/tridge/dbench

I think this is good for your patch because it's inherently parallel. 
Interesting numbers of tasks are, e.g., 1, 2, 10, 50.   Of course dbench
is not the last word in benchmarks but it's been pretty useful so far. 
You probably want something entirely cpu-bound too.  How about dbench
with ramfs?

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: And oh, btw..

[Marcelo Tosatti]

On Thu, 4 Jan 2001, Linus Torvalds wrote:

> 
> In a move unanimously hailed by the trade press and industry analysts as
> being a sure sign of incipient braindamage, Linus Torvalds (also known as
> the "father of Linux" or, more commonly, as "mush-for-brains") decided
> that enough is enough, and that things don't get better from having the
> same people test it over and over again. In short, 2.4.0 is out there.

I have 1 patch which has not been answered and I still dont know if you
want it only for 2.5.

I dunno if you've read the swap write clustering patch I sent sometime
ago. Basically it changes swap_writepage to search for physically
contiguous dirty swap cache pages and if it finds them, it writes all of
them in a cluster. The nice thing is that we save disk seek time which are
well known to be nasty.

I've received one report of 13% improvement with dbench and reiserfs, and
on my own benchmarks I've seen improvements of 15% successful write merges
on the swap device (using SAR patch to measure).

I'm not sure if its a intrusive change now with 2.4.0 released. What do
you think?



Another problem which we have now is swap-in readahead. Currently swapin
readahead is done on a physical device basis.

The problem is that physical swap pages are not necessarily virtually
contiguous. So what can happen (and is happening) is that we readahead
pages which are not going to be used soon.

What we probably want to do is only readahead swap pages if they really
are virtually contiguous too, to avoid wasting memory and IO processing
with "guesses" about the swap device.

I have a patch which does that (I'm still searching for an SMP deadlock
but I'm looking at it). It walks the virtually contiguous pte's starting
from the one which was faulted, and then it only cluster them if they are
virtually contiguous too.

I'll send the patch as soon as I figured out the deadlock and stress it a
more.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: And oh, btw..

[Alan Cox]

> http://www.kernel.org/pub/linux/kernel/testing/prerelease-diff
> Please don't flood kernel.org though... use a mirror.

You'll find the proper 2.4.0 on

ftp://ftp.linux.org/pub/linux/linux-2.4/linux-2.4.0.tar.gz


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: And oh, btw..

[Jordan Mendelson]

dep wrote:
> 
> On Thursday 04 January 2001 07:36 pm, Jordan Mendelson wrote:
> 
> | Go home, get out the epson salts, fill up the tub with hot water
> | and just relax.
> 
> right after getting the source posted on kernel.org!


Sigh, try:

http://www.kernel.org/pub/linux/kernel/testing/prerelease-diff


Please don't flood kernel.org though... use a mirror.


Jordan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: And oh, btw..

[Miles Lane]

Is there a patch against test12 somewhere?  I don't see it.

Have some happy downtime,

Miles



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: And oh, btw..

[dep]

On Thursday 04 January 2001 07:36 pm, Jordan Mendelson wrote:

| Go home, get out the epson salts, fill up the tub with hot water
| and just relax.

right after getting the source posted on kernel.org!
-- 
dep
--
bipartisanship: an illogical construct not unlike the idea that
if half the people like red and half the people like blue, the 
country's favorite color is purple.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] 2.4.0-prerelease: preemptive kernel.

[Andi Kleen]

On Thu, Jan 04, 2001 at 04:36:32PM -0800, ludovic fernandez wrote:
> Saying that, I definitely agree that I want/need to one day listen to
> my MP3s while building  my kernel.

??? I can listen to MP3s just fine while building kernels, on a not very
powerful K6. 

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: And oh, btw..

[Jordan Mendelson]

Linus Torvalds wrote:
> 
> In a move unanimously hailed by the trade press and industry analysts as
> being a sure sign of incipient braindamage, Linus Torvalds (also known as
> the "father of Linux" or, more commonly, as "mush-for-brains") decided
> that enough is enough, and that things don't get better from having the
> same people test it over and over again. In short, 2.4.0 is out there.

Everyone who has ever been the press spotlight knows that most of it is
inaccurate, rushed and written to bring in readers rather than to report
well thought out stories.

Go home, get out the epson salts, fill up the tub with hot water and
just relax.


Jordan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Printing to off-line printer in 2.4.0-prerelease

[Peter Osterlund]

Tim Waugh <[EMAIL PROTECTED]> writes:

> On Thu, Jan 04, 2001 at 08:07:19PM +0100, Peter Osterlund wrote:
> 
> > If you do this, you should probably also return -EAGAIN if the printer
> > is out of paper, otherwise I would still lose data when the printer
> > goes out of paper. Currently it returns -ENOSPC in this situation. I
> > suppose the different return codes were meant as a way for user space
> > to be able to know why printing failed, so that it could take
> > appropriate actions, but maybe this is not used by any programs.
> 
> They were intended for that, yes, but it's probably better to stick
> with the 2.2 return codes.  Here's a patch to do that.  Look okay?

I assume you meant to return -EAGAIN, not -EIO. However, it doesn't
work if the printer is powered off and LP_ABORT is false. In that case
lp_write calls lp_check_status, which detects the error, waits 10
seconds, but then returns 0. lp_write then calls parport_write which
will happily send the data to the powered off printer, then return
success to user space and the data is lost.

> 
> Tim.
> */
> 
> 2001-01-04  Tim Waugh  <[EMAIL PROTECTED]>
> 
>   * drivers/char/lp.c: Follow 2.2 behaviour more closely.
> 
> --- linux-2.4.0-prerelease/drivers/char/lp.c.offline  Thu Jan  4 21:13:02 2001
> +++ linux-2.4.0-prerelease/drivers/char/lp.c  Thu Jan  4 21:42:19 2001
> @@ -207,7 +207,7 @@
>   last = LP_POUTPA;
>   printk(KERN_INFO "lp%d out of paper\n", minor);
>   }
> - error = -ENOSPC;
> + error = -EIO;
>   } else if (!(status & LP_PSELECD)) {
>   if (last != LP_PSELECD) {
>   last = LP_PSELECD;
> @@ -230,7 +230,10 @@
>   if (last != 0)
>   lp_error(minor);
>  
> - return error;
> + if (LP_F (minor) & LP_ABORT)
> + return error;
> +
> + return 0;
>  }
>  
>  static ssize_t lp_write(struct file * file, const char * buf,
> @@ -292,7 +295,7 @@
>   /* incomplete write -> check error ! */
>   int error = lp_check_status (minor);
>  
> - if (LP_F(minor) & LP_ABORT) {
> + if (error) {
>   if (retv == 0)
>   retv = error;
>   break;

-- 
Peter Österlund [EMAIL PROTECTED]
Sköndalsvägen 35http://home1.swipnet.se/~w-15919
S-128 66 Sköndal+46 8 942647
Sweden

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Journaling: Surviving or allowing unclean shutdown?

[Daniel Phillips]

"Stephen C. Tweedie" wrote:
> 
> On Wed, Jan 03, 2001 at 05:27:25PM +0100, Daniel Phillips wrote:
> >
> > Tux2 is explicitly designed to legitimize pulling the plug as a valid
> > way of shutting down.  Metadata-only journalling filesystems are not
> > designed to be used this way, and even with full-data journalling you
> > should bear in mind that your on-disk filesystem image remains in an
> > invalid state until the journal recovery program has run successfully.
> 
> ext3 does the recovery automatically during mount(8), so user space
> will never see an unrecovered filesystem.  (There are filesystem flags
> set by the journal code to make sure that an unrecovered filesystem
> never gets mounted by a kernel which doesn't know how to do the
> appropriate recovery.)

Hi Stephen.

Yes, and so long as your journal is not on another partition/disk things
will eventually be set right.  The combination of a partially updated
filesystem and its journal is in some sense a complete, consistent
filesystem.

I'm curious - how does ext3 handle the possibility of a crash during
journal recovery?

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] 2.4.0-prerelease: preemptive kernel.

[ludovic fernandez]

Nigel Gamble wrote:

> On Thu, 4 Jan 2001, ludovic fernandez wrote:
> > This is not the point I was trying to make .
> > So far we are talking about real time behaviour. This is a very 
>interesting/exciting
> > thing and we all agree it's a huge task which goes much more behind
> > just having a preemptive kernel.
>
> You're right that it is more than just a preemptible kernel, but I don't
> agree that it's all that huge.  But this is the third time I have worked
> on enabling real-time behavior in unix-like OSes, so I may be biased ;-)
>
> > I'm not convinced that a preemptive kernel is interesting for apps using
> > the time sharing scheduling, mainly because it is not deterministic and the
> > price of a mmu conntext switch is still way to heavy (that's my 2 cents belief
> > anyway).
>
> But as Roger pointed out, the number of extra context switches
> introduced by having a preemptible kernel is actually very low.  If an
> interrupt occurs while running in user mode, the context switch it may
> cause will happen even in a non-preemptible kernel.  I think that
> running a kernel compile for example, the number of context switches per
> second caused by kernel preemption is probably between 1% and 10% of the
> total context switches per second.  And it's certainly interesting to me
> that I can listen to MP3s without interruption now, while doing a kernel
> build!
>

I agree Nigel, but as you pointed out you will have to deal with
scheduling behaviour, interrupt latency and priority inversion to
achieve that.
I was just trying to point out that just having kernel preemptable threads
will enable, for example, kswapd to adjust itself more efficiently with the
current load of the system and what it needs to achieve (running from
low priority to non preemptable thread). Providing a better (smoother)
swap behaviour.
Saying that, I definitely agree that I want/need to one day listen to
my MP3s while building  my kernel.

Ludo.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

2.4.0-pre: usbdevfs: USBDEVFS_BULK failed ...

[Jordan Mendelson]

I've been having some problems with the recent 2.4.x kernels with my
digital camera. The s10sh program accesses the Canon S20 digital camera
using libusb in conjunction with usbfs to download images. Apparently,
incorrect data about the size of images is being sent down the line
after the first image transfer.

Here are some messages printed to syslog:

hub.c: USB new device connect on bus1/1, assigned device number 4
usbserial.c: none matched
usb.c: USB device 4 (vend/prod 0x4a9/0x3043) is not claimed by any
active driver.
usb-uhci.c: interrupt, status 3, frame# 496
usbdevfs: USBDEVFS_BULK failed dev 4 ep 0x81 len 2872 ret -32
usbdevfs: USBDEVFS_BULK failed dev 4 ep 0x81 len 84 ret -32
usbdevfs: USBDEVFS_BULK failed dev 4 ep 0x81 len 64 ret -32
usb.c: USB disconnect on device 4

Now, the USB disconnect never actually happened physically. The camera
looks like it stopped responding to it's USB port.


Jordan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Oops 2.2.17 and 2.0.37pre10 - same machine

[John O'Donnell]

I am trying to install Slackware Linux.
I boot the 2.2.17 from slackware-current series
I fdisk /dev/hda1 as 128MB Swap and /dev/hda2 as root.
I run mkswap -c -v1 /dev/hda1 - it chugs and finishes...
I run swapon /dev/hda1 and I get an oops!

Unable to handle kernel NULL pointer dereference at virtual address 001c
Current->tss.cr3 = 07737000, %cr3 = 07737000
*pde = 
Oops: 
CPU:0
EIP:0010[]
EFLAGS: 00010202
eax: c7ffd5e0  ebx:   ecx: c6980801  edx: 
esi: 00016fc4  edi:   ebp:   esp: c7739efc
ds: 018  es: 0018  ss: 0018
Process swapon (pid: 88, process nr: 13, stackpage=c7739000)
Stack: c7731140  0801  0801 c0123771 0801 1000
c7738000 bd7c 08049106   009d 0c7feb32 c7739f88
 c7647009 c02abac0 c776aee0 0801 1140 c7739f68 
Call Trace: [] []
Code: 8b 6b 1c 66 86 4c 24 1a 66 39 4b 0c 0f 85 c3 00 00 00 8b 4c
Segmentation fault
#

This is a brand new machine.
PIII 800 (133Mhz bus)
Acorp 6BX/VIA83
128Mb RAM

I thought it might have something to do with the IDE drive or controller.
I installed a trusty Adaptec 2940AU and a Seagate 4G drive.  Same thing?!?!
So it is not the drives or controllers...
For kicks I put in a Slackware 3.9 (kernel 2.0.37pre10) cd I had next to me.
Boot.   fdisk - partitions ok.
mkswap -c -v0 /dev/sda1
Oops.

Can anyone help me?  I have scoured the BIOS for any flaky settings.
I can see none.  helpp.  :-)
Johnny O

-- 
 what's the difference between chattr and chmod?
 SomeLamer: man chattr > 1; man chmod > 2; diff -u 1 2 | less
-- Seen on #linux on irc
=== Never ask a geek why, just nod your head and slowly back away.===
+==++
| John O'Donnell (Sr. Systems Engineer, Net Admin, Webmaster, etc.) |
| Voice FX Corporation (a subsidiary of Student Advantage)  |
| One Plymouth Meeting | E-Mail: [EMAIL PROTECTED] |
| Suite 610|   www.voicefx.com  |
| Plymouth Meeting, PA 19462   | www.campusdirect.com   |
+==++

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] 2.4.0-prerelease: preemptive kernel.

[Nigel Gamble]

On Thu, 4 Jan 2001, ludovic fernandez wrote:
> This is not the point I was trying to make .
> So far we are talking about real time behaviour. This is a very interesting/exciting
> thing and we all agree it's a huge task which goes much more behind
> just having a preemptive kernel.

You're right that it is more than just a preemptible kernel, but I don't
agree that it's all that huge.  But this is the third time I have worked
on enabling real-time behavior in unix-like OSes, so I may be biased ;-)

> I'm not convinced that a preemptive kernel is interesting for apps using
> the time sharing scheduling, mainly because it is not deterministic and the
> price of a mmu conntext switch is still way to heavy (that's my 2 cents belief
> anyway).

But as Roger pointed out, the number of extra context switches
introduced by having a preemptible kernel is actually very low.  If an
interrupt occurs while running in user mode, the context switch it may
cause will happen even in a non-preemptible kernel.  I think that
running a kernel compile for example, the number of context switches per
second caused by kernel preemption is probably between 1% and 10% of the
total context switches per second.  And it's certainly interesting to me
that I can listen to MP3s without interruption now, while doing a kernel
build!

Nigel Gamble[EMAIL PROTECTED]
Mountain View, CA, USA. http://www.nrg.org/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Network oddity....

[Rogier Wolff]

Hi all, 

I have a server, and it reports ("netstat -a")

tcp0  0 server:sshclient:1022 SYN_RECV

This sounds normal right?

However there are 79 of these lines in the netstat output. Not normal!

A TCP connection is identified by the 12 bytes source IP, dest IP,
source port, dest port. Right? Then as far as I can see, these should
all refer to the SAME socket. (yes, they all refer to server:ssh, and
client: 1022!)

Oh, this situation seems to continue: it sends a syn-ack and then the
client replies with a reset. This goes on and on. I'm going to make
the client disappear, and hope that this makes the number of these
connections go away.

Kernel is 2.2.13. That was "fresh" when the system was booted. Yes,
that's over 14 months ago. 

Roger. 

-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

And oh, btw..

[Linus Torvalds]

In a move unanimously hailed by the trade press and industry analysts as
being a sure sign of incipient braindamage, Linus Torvalds (also known as
the "father of Linux" or, more commonly, as "mush-for-brains") decided
that enough is enough, and that things don't get better from having the
same people test it over and over again. In short, 2.4.0 is out there.

Anxiously awaited for the last too many months, 2.4.0 brings to the table
many improvements, none of which come to mind to the exhausted release
manager right now. "It's better", was the only printable quote. Pressed
for details, Linus bared his teeth and hissed at reporters, most of which
suddenly remembered that they'd rather cover "Home and Gardening" than the
IT industry anyway.

Anyway, have fun. And don't bother reporting any bugs for the next few
days. I won't care anyway.

Linus

-
Changes since the prerelease:

David Mosberger:
 - ia64 update

NIIBE Yutaka:
 - SuperH update

Karsten Keil:
 - re-do ISDN certification checksums

Tim Waugh:
 - VIA DMA=255 bug fix
 - IEEE 1284 config message
 - IEEE 1284 probe fix
 - missing printk argument
 - ppa driver reconnect timeout tweak

Matthew Dharm:
 - USB hotplug fix - specify exactly which fields to match on

Rik Faith:
 - drm driver synch with XFree86-4.0.2
 - oops: we synched a bit too far. Backsync to the _real_ 4.0.2 level.

Geert Uytterhoeven:
 - m68k updates
  - Amiga resource management updates
  - m68k loops_per_jiffy updates
  - m68k keyboard delay/repeat
  - m68k SCSI updates
  - m68k exported symbols update
  - m68k Lance updates
  - fbdev config fixes
  - Amiga Ethernet updates
  - Amiga builtin serial updates
  - m68k config updates
  - m68k __ashldi3
  - Amiga Y2K fixes (a bit late, wouldn't you say?)
  - Misc m68k updates
  - fbdev init order fix
  - Mac/m68k IDE updates
  - m68k asm constraint fixes


Marc ZYNGIER:
 - SMP lockup with IrDA

David Huggins-Daines:
 - remove extra "remove_wait_queue()" in drivers/sound/cs46xx.c.  It
   would lock up badly on nonblocking reads.

Matti Aarnio:
 - teach tulip driver about media types 5 and 6
 - fix ATM LANE driver linkage issues
 - fix DECNET driver unload time cleanup
 - fix pointer comparison type warning
 - get rid of excessive '##' token pasting that newer gcc's warn about

Keith Owens:
 - fix drm Makefile to not use the same objects built-in and in a module
 - update modutils version numbers to match 2.4.x kernel

Russell Kroll:
 - fix radio card drivers that got the request_region sense inverted

Rich Baum:
 - Remove compile warnings with newer gcc versions for lables with no
   expression at the end of a compound block

Andreas Franck:
 - Make the x86 semaphore implementation compile properly with current
   gcc snapshots.  Newer gcc's will release the memory allocated for a
   data structure too early if only the pointer to that memory is passed
   to an asm.

Alan Cox:
 - pcxx.c: make it compile ("mseconds" -> "msec")
 - Documentation: fix typos/glitches
 - CCISS bugfix
 - riscom setup bugfix
 - toshoboe and wavelan overlarge udelay
 - clean/bugfixes amateur radio
 - yam/mkiss build fix
 - old tulip chips driver update
 - sg driver unchecked scsi_allocate_request
 - i810 audio fix
 - RTC CMOS locking fixes

David Miller:
 - update sparc to "loops_per_jiffy"
 - sparc32 uses ix86-like semaphores now
 - missing flush_dcache_page in kiovec support layer
 - netfilter: use "long" for values operated on using bitops
 - more empty statement warning fixes
 - LVM 32-bit compat ioctl checks
 - Include param.h into Sparc64's delay.h to get HZ define
 - Fix Zilog serial port speed setting checks

Neil Brown:
 - raid5 missing unlock on degraded array
 - knfsd inode semaphore: get it early

Johannes Erdfelt:
 - USB oops on unplug fix for dc2xx and ov511 driver

Mitch Davis:
 - prettier printout of IDE registers if < 0x100

Richard Henderson:
 - alpha "loops_per_jiffy" update

Oliver Neukum:
 - fix for SMP race in v4l open()

Andreas Bombe:
 - Makefile fix for ieee1394
 - IEEE 1394 up-to-date

Kai Germaschewski:
 - fix ISDN diversion services name-clash (and crash)

Andre Hedrick:
 - IDE chipset update, DVD-RAM update

Rik van Riel:
 - don't deactivate partially written pages in generic_file_write

Michael Lang:
 - ibmmca upgrade: docs and small bugs

Marko Kreen:
 - big udelay's in fb drivers. Fix.

Me:
 - drivers/net/rcpci45.c: make it compile ("rcpci_pci_table" ->
   "rcpci45_pci_table")
 - mark_buffer_dirty() only does a "balance_dirty()" if the
   buffer was previously clean.
 - mm sanity: never decrement page count past zero
 - no synchronous bdflush wait
 - mm VM scanning and exit race cleanup: mmlist_lock

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [patch] big udelay's in fb drivers (2.4.0-prerelease)

[Alan Cox]

> Once the comments are unweirded, they become completely superfluous. At
> which point its best not to have them - when someone next comes along and
> changes the delay, it might end up disagreeing with the comment and
> causing confusion.

Before you remove the comments check with the author and the manuals.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: How to Power off with ACPI/APM?

[Michael D. Crawford]

I said:

> Looking back in the ACPI kernel config help, it says you can use ACPI 
> if you also have APM enabled, which I didn't do at first. 

[EMAIL PROTECTED] (Daniel) replied:

> That's wrong then, you can't use ACPI and APM at the same time. 

I think the documentation in the kernel config help is unclear.  The way it's
phrased seems to imply that you want to use them together.  Thinking about it, I
believe what is really meant is that if ACPI and APM are both enabled, ACPI will
take precedence - but that is not what happens.

 APM gives its message first in the boot process, then later ACPI does.  But
ACPI says something like "APM already present, exiting", so the doc is wrong
both ways you read it, or else ACPI doesn't succeed in the intended behavior to
override APM.

in linux/Documentation/Configure.help, the following text appears in ACPI's
entry:

If both ACPI and Advanced Power Management (APM) support
are configured, ACPI is used.

Perhaps better wording would be (um, perhaps someone could show this clueless
old Mac programmer how to use diff to make a patch?):

If both ACPI and Advanced Power Management (APM) support
are configured, ACPI takes precedence and APM is not used.

but that's not what actually happens, in practice APM gets used.

Anyway, I turned off ACPI in my config and rebuilt my kernel, and I still can't
power off.

Just to make sure, I tried to force the power off with this:

sync
sync
sync
halt -f -p

I got the message "Power Down" but my system stayed on and I was still in my
shell.

I verfied that apmd got started at boot time and that the file /proc/apm exists
and has some stuff in it:

1.14 1.2 0x03 0x01 0xff 0x80 -1% -1 ?

I'm using the binary of halt that came with Slackware 7.1.  Do I need to update
any of my executable programs to work with the new kernel?  The only thing I've
done is installed the latest modutils.  I did download the latest util-linux
from kernel.org but this didn't appear to have the same program Slackware uses -
there's a shutdown program, but on slackware I think shutdown is a script and
there's a halt binary with reboot symlinked to it.

Mike
-- 
Michael D. Crawford
GoingWare Inc. - Expert Software Development and Consulting
http://www.goingware.com/
[EMAIL PROTECTED]

   Tilting at Windmills for a Better Tomorrow.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Anyone else interested in a high-precision monotonic counter?

[Christopher Friesen]

Has anyone ever considered including a microsecond-precision
monotonically-increasing counter in the kernel?  This would allow for
easy timing of alarms and such by using absolute values of when the
alarm should expire rather than a list of deltas from previous alarms.

The thing I have in mind would store a value something like "xtime"
(maybe call it "ytime"?) in the kernel.  This value would be initialized
to zero on startup, and would be incremented at the same time as
"xtime".  However, while "xtime" reflects adjustments to the actual
system time (settimeofday(), date, ntp, etc.), this value would not. 
Finally, it would be accessed with a system call essentially identical
to sys_gettimeofday(), only it would access "ytime" instead of "xtime"
before going down and getting the microseconds from the RTC.

This doesn't seem to me as though it would be all that tricky to add,
and I could see it being very useful in providing a timing source that
is guaranteed to a) be accurate to microseconds and b) never go
backwards.


Chris

-- 
Chris Friesen| MailStop: 043/33/F10  
Nortel Networks  | work: (613) 765-0557
3500 Carling Avenue  | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada| email: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: linux-2.4.0-prerelease-ac6 compile errors

[Bill Nottingham]

Ignacio Monge ([EMAIL PROTECTED]) said: 
> Problem: compile error in linux-2.4.0-prerelease-ac6

--- linux/drivers/char/serial.c.foo Thu Jan  4 17:31:43 2001
+++ linux/drivers/char/serial.c Thu Jan  4 17:32:38 2001
@@ -5184,12 +5184,12 @@
   
   for (pnp_board = pnp_devices; pnp_board->vendor; pnp_board++)
   if ((dev->vendor == pnp_board->vendor) &&
-  (dev->device == pnp_board->device))
+  (dev->device == pnp_board->function))
   break;
 
   if (pnp_board->vendor) {
   board.vendor = pnp_board->vendor;
-  board.device = pnp_board->device;
+  board.device = pnp_board->function;
   /* Special case that's more efficient to hardcode */
   if ((board.vendor == ISAPNP_VENDOR('A', 'K', 'Y') &&
board.device == ISAPNP_DEVICE(0x1021)))

Bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [Ext2-devel] Re: [RFC] ext2_new_block() behaviour

[Stephen C. Tweedie]

Hi,

On Thu, Jan 04, 2001 at 05:31:12PM -0500, Alexander Viro wrote:
> 
> BTW, what inumber do you want for whiteouts? IIRC, we decided to use
> the same entry type as UFS does (14), but I don't remember what was
> the decision on inumber. UFS uses 1 for them, is it OK with you?

0 is used for padding, so 1 makes sense, yes.

--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Make errors in 2.4 drivers/acpi, recursive CFLAGS

[Keith Owens]

On Thu, 4 Jan 2001 17:19:51 -0600, 
Michael Elizabeth Chastain <[EMAIL PROTECTED]> wrote:
>I wonder if Gnu Make 3.78.1 has the same problem?
>I know of one bug in 3.78.1 where ...

It did.

  GNU Make version 3.78.1, by Richard Stallman and Roland McGrath.
  Built for alpha-redhat-linux-gnu

Definitely deprecate make 3.78.1.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

linux-2.4.0-prerelease-ac6 compile errors

[Ignacio Monge]

Problem: compile error in linux-2.4.0-prerelease-ac6

System:
Intel Pentium II 233 Mhz 96 Mb RAM
Red Hat Linux System 7.0
Glibc-2.2-5
Gcc-2.95.2-12

Output error:
[...]

ld -m elf_i386  -r -o drm.o tdfx.o drmlib.a
make[4]: Saliendo directorio `/usr/src/linux/drivers/char/drm'
make[3]: Saliendo directorio `/usr/src/linux/drivers/char/drm'
make all_targets
make[3]: Cambiando a directorio `/usr/src/linux/drivers/char'
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2
-march=i686-DEXPORT_SYMTAB -c serial.c
serial.c: In function `probe_serial_pnp':
serial.c:5187: structure has no member named `device'
serial.c:5192: structure has no member named `device'
make[3]: *** [serial.o] Error 1
make[3]: Saliendo directorio `/usr/src/linux/drivers/char'
make[2]: *** [first_rule] Error 2
make[2]: Saliendo directorio `/usr/src/linux/drivers/char'
make[1]: *** [_subdir_char] Error 2
make[1]: Saliendo directorio `/usr/src/linux/drivers'
make: *** [_dir_drivers] Error 2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Printing to off-line printer in 2.4.0-prerelease

[David Ford]

The only way to _assume_ a printer is online is to attempt a dummy poll for
information.  Again note that this is a strong assumption as only some new printers
return data for a poll, and legacy printers control of the data port are undefined.

The poll btw needs to be done in userspace because printers respond differently with
different polls.  Thus a 'printer driver' interface needs developed.  Oddly enough,
WinPrinters won't suffer this problem simply because of their bidirectional design
:(

-d

Jesse Pollard wrote:

> -  Received message begins Here  -
> Tim Waugh <[EMAIL PROTECTED]>:
> > On Thu, Jan 04, 2001 at 03:39:10PM +0100, Andrea Arcangeli wrote:
> >
> > > As noted yesterday falling into parport_write will silenty lose data when the
> > > printer is off.
> >
> > (Actually it depends; I think FIFO/DMA paths are fine, but yes, the
> > software implementation can lose data.)
> >
> > > If it's not feasible to make parport_write reliable against
> > > power-off printer, then I recommend to loop in interruptible mode
> > > before entering the main loop (waiting the printer to power-on) like
> > > in latest patch from Peter.
> >
> > Have I missed a patch?  How do you know whether or not the printer is
> > on yet?
> >
> > As I understand it, you can't guarantee anything about any of the
> > signals when the printer is off, so all you can do is look for
> > 'suspicous' things (like 'no error' and 'paper out').  But some
> > printers do this during normal operation, and hence the LP_CAREFUL
> > switch.
> >
> > Return -EIO when the printer is on and off-line is a bug, sure enough.
> > That's what the -EAGAIN patch was for, and Peter's patch fixes this
> > too.
> >
> > But if you want to avoid losing data when your printer is off you need
> > to use LP_CAREFUL, and hope printing still works at all (depends on
> > your printer).
> >
> > If this goes away:
> >
> > if ((status & LP_PERRORP) && !(LP_F(minor) & LP_CAREFUL))
> > /* No error. */
> > last = 0;
> >
> > then some people might not be able to print at all.
>
> I don't believe this is a problem that CAN be fixe, either by hardware
> or software.
>
> Originally, (wayback machine on) this was handled by a pull-up resistor
> in the parallel interface, on the "off-line" signal. ANY time the printer
> was powered off, set offline, or cable unplugged, the "off-line" signal
> was raised by the pull-up. No data lost.
>
> Now the parallel interface is bidirectional, and can have multiple devices
> attached - this "fix" cannot be used. The interface is now more of a
> buss than a single attached interface, and signals from a missing device
> (powered off or disconnected) are floating. They may float high or low,
> and depending on the environment (and which end of the cable is unplugged)
> any thing in between.
>
> Yes, I've lost printouts this way, but there's nothing I can really do
> about it other than than tell the users "don't do that - make sure the
> printer is turned on before you print".
>
> -
> Jesse I Pollard, II
> Email: [EMAIL PROTECTED]
>
> Any opinions expressed are solely my own.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/


begin:vcard 
n:Ford;David
x-mozilla-html:TRUE
url:www.blue-labs.org
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Blue Labs Developer
note;quoted-printable:GPG key: http:[EMAIL PROTECTED]=0D=0A
x-mozilla-cpt:;9952
fn:David Ford
end:vcard

Re: Make errors in 2.4 drivers/acpi, recursive CFLAGS

[Michael Elizabeth Chastain]

I wonder if Gnu Make 3.78.1 has the same problem?

I know of one bug in 3.78.1 where $(if ...) statements which have an
"else" clause screw up the parsing of the "else" clause.  But there
shouldn't be any $(if ...) constructs in the kernel Makefiles.

I guess we'll either have to find the problem and work around it,
or deprecate Gnu Make 3.78.

Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] 2.4.0-prerelease: preemptive kernel.

[ludovic fernandez]

Roger Larsson wrote:

> On Thursday 04 January 2001 09:43, ludovic fernandez wrote:
>
> > I'm not convinced a full preemptive kernel is something
> > interesting mainly due to the context switch cost (actually mmu contex
> > switch).
>
> It will NOT be fully, it will be mostly.
> You will only context switch when a higher prio thread gets runnable, two
> ways:
> 1) external intterupt waking higher prio process, same context swithes as
> when running in user code. We won't get more interrupts.
> 2) wake up due to something we do. Not that many places, mostly due to
> releasing syncronization objects (spinlocks does not count).
>
> If this still is a problem, we can select to only preemt to processes running
> RT stuff. SCHED_FIFO and SCHED_RR by letting them set need_resched to 2...
> > What about only preemptable kernel threads ?
>
> No, it won't help enough.
>

This is not the point I was trying to make .
So far we are talking about real time behaviour. This is a very interesting/exciting
thing and we all agree it's a huge task which goes much more behind
just having a preemptive kernel.
I'm not convinced that a preemptive kernel is interesting for apps using
the time sharing scheduling, mainly because it is not deterministic and the
price of a mmu conntext switch is still way to heavy (that's my 2 cents belief
anyway).
But, having a preemptive kernel could be interesting for an another issue.
More and more the linux kernel is using the concept of kernel threads to
defer part of the processing. Right now they are not preemptable and one
has to put explicit preemption points. I believe this solution doesn't fly in
the long term (the code changes, the locking design changes and the
preemption points become irrelevant). They could be preemptable because
they have a way of being deterministic (preemption disable) and they
are lightweight to schedule since they don't use a mmu context.

Ludo.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/