On Wed, 10 Jan 2001, David Woodhouse wrote:
[EMAIL PROTECTED] said:
The no-swap behaviour shoul dactually be pretty much identical,
simply because both 2.2 and 2.4 will do the same thing: just skip
dirty pages in the page tables because they cannot do anything about
them.
So
On Wed, 10 Jan 2001, Marco Colombo wrote:
case xxx:
/* fallthrough */ ;
}
or something (or maybe just a "break" statement), just so that we don't
turn the poor C language into line noise (can anybody say "perl" ;)
Of course, you don't mean that the
On 10 Jan 2001, Eric W. Biederman wrote:
Andrea Arcangeli [EMAIL PROTECTED] writes:
Once I or other developer finishes with the reverse lookup from page to
pte-chain (an implementation from DaveM just exists) we'll be able to put them
in a separate lru, but it's certainly not a
On Wed, 10 Jan 2001, Alan Cox wrote:
That is extremely undesirable behaviour. setuid() changes for pthreads crud
should be done by the library emulation layer. Many people have very real
and very good reasons for running multiple parallel ids. Just try writing
a threaded ftp daemon (non
In article [EMAIL PROTECTED],
Andrew Morton [EMAIL PROTECTED] wrote:
Linus Torvalds wrote:
De gustibus non disputandum.
http://cogprints.soton.ac.uk/documents/disk0/00/00/07/57/
"ingestion of the afterbirth during delivery"
eh?
http://www.degustibus.co.uk/
&quo
On Wed, 10 Jan 2001, David L. Parsley wrote:
Yup, I backed out Adam's one-liner in favor of the attached one-liner.
Tested on 2.4.0, but should patch cleanly to just about anything. ;-)
BTW Linus - you were of course right on the cramfs wanting 4096
blocksize... but without this fix,
In article [EMAIL PROTECTED],
Udo A. Steinberg [EMAIL PROTECTED] wrote:
Next backed out the entire XMM and FXSR related stuff and now everything
is fine again. The CPU in question is an AMD Thunderbird (see cpuinfo
below). A friend with a similar setup but a Pentium-3 CPU doesn't seem
to see the
Could people with Athlons please verify that pre3 works for them?
It's basically Andrea's patch, but I moved the FPU save/restore games away
from arch/i386/lib/mmx.c, so that everything is properly done in one place
and others call the appropriate helper functions instead of thinking that
they
On Fri, 12 Jan 2001, Andrea Arcangeli wrote:
Note that there was a precise reason for not implementing it as the TSC disable
(infact at first in 2.2.x I was clearing the bigflag in x86_capabilities too).
The reason is that the way TSC gets disabled breaks /proc/cpuinfo.
No.
It FIXES
On Fri, 12 Jan 2001, Andrea Arcangeli wrote:
On Fri, Jan 12, 2001 at 11:42:32AM -0500, Richard A Nelson wrote:
Its fine either way on current x86 and many other platforms, but falls
on its face in the presence of asymetric MP.
Point taken, feel free to have a can_I_use per-cpu
On Fri, 12 Jan 2001, Andre Hedrick wrote:
Scratch that patch it has 2 typos that are in amd74xx.c
will do it again..
I will scratch your new patch too.
I want to see the code to handle the apparent VIA DMA bug. At this point,
preferably by just disabling DMA on VIA chipsets or
In article [EMAIL PROTECTED],
Manfred Spraul [EMAIL PROTECTED] wrote:
The processor's local APIC includes an in-service entry and a holding
entry for each priority level. To avoid losing interrupts, software
should allocate no more than 2 interrupt vectors per priority.
Ok, we must reorder the
In article [EMAIL PROTECTED],
Alan Cox [EMAIL PROTECTED] wrote:
The fact that 2.2.x has bad control over capabilities and is messy is NOT
an excuse to screw up forever.
2.2 has a mix of 'can I use' and 'does the cpu have' so using 2.2 as an
example doesnt work
The above was exactly what I
In article [EMAIL PROTECTED],
Alan Cox [EMAIL PROTECTED] wrote:
The PCI ids I kill autodma on for 2.2 to cover this are:
/*
* Don't try and tune a VIA 82C586 or 586A
*/
if (IDE_PCI_DEVID_EQ(devid, DEVID_VP_IDE))
In article [EMAIL PROTECTED],
Andre Hedrick [EMAIL PROTECTED] wrote:
Well that "experimental patch" is designed to get out of the dreaded
"DMA Timeout Hang" or deadlock that is most noted by the PIIX4 on the
Intel 440*X Chipset groups. Since it appears that their bug was copied
but other
On Fri, 12 Jan 2001, Vojtech Pavlik wrote:
I've got a vt82c586 here (bought it just for testing of this problem),
and I wasn't able to create any corruption using that board and the 2.4
drivers.
The fact that it works on one board doesn't mean that it works on _every_
board.
This is, in
On Fri, 12 Jan 2001, Frank de Lange wrote:
On Fri, Jan 12, 2001 at 08:33:15PM +0100, Manfred Spraul wrote:
Frank, the 2.4.0 contains 2 band aids that were added for ne2k smp:
* From Ingo: focus cpu disabled, in arch/i386/kernel/apic.c
* From myself: TARGET_CPU = cpu_online_mask, was
In article [EMAIL PROTECTED],
Frank de Lange [EMAIL PROTECTED] wrote:
As per Linus' suggestion, I removed the disable_irq/enable_irq statements from
the 8390 core driver, and replace the spinlocks with irq-safe versions. This
seems to solve the network hangs, as I am currently running a heavy
On Fri, 12 Jan 2001, Vojtech Pavlik wrote:
However - Alan's IDE patch for 2.2 kills autodma on ALL VIA chipsets.
That's because all VIA chipsets starting from vt82c586 to vt82c686b
(UDMA100), share the same PCI ID.
Would you prefer to filter just vt82c586 and vt82c586a as the comment in
On Fri, 12 Jan 2001, Frank de Lange wrote:
Gentleman, this (the patch to 8390.c) seems to fix the problem.
The problem with this patch is that anybody with a slow ISA ne2000 clone
will basically have absolutely _horrible_ interrupt latency because we
hold the irq lock over some quite
On Fri, 12 Jan 2001, Alan Cox wrote:
interrupt controllers (io-apic definitely included). Drivers would
generally be better off if they disabled their own chip from sending
interrupts, rather than disabling the interrupt line the chip is on.
That doesn't work very well because the
On Fri, 12 Jan 2001, Alan Cox wrote:
Could you disable both bandaids? I disabled them, no problems so far.
Now back to the disable_irq_nosync().
Ok so it looks like the disable_irq code is buggy. Unfortunately its not
just used for these drivers they are just the heaviest users.
It
On Sat, 13 Jan 2001, Alan Cox wrote:
interrupt_handler()
{
status = readl(dev-status);
if (status MY_IRQ_DISABLE)
return;
Unfortunately on the 8390 the IRQ statud register is on page 0. The code
on the other CPU might not be on
On Fri, 12 Jan 2001, John Heil wrote:
On Sat, 13 Jan 2001, Alan Cox wrote:
Date: Sat, 13 Jan 2001 00:25:28 + (GMT)
From: Alan Cox [EMAIL PROTECTED]
To: Linus Torvalds [EMAIL PROTECTED]
Cc: Vojtech Pavlik [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: ide.2.4.1-p3.01112001
On Sat, 13 Jan 2001, Frank de Lange wrote:
On Fri, Jan 12, 2001 at 04:36:33PM -0800, Linus Torvalds wrote:
It may well not be disable_irq() that is buggy. In fact, there's good
reason to believe that it's a hardware problem.
I am inclined to believe it IS a hardware problem
On Fri, 12 Jan 2001, John Heil wrote:
Yes, initially the 686a was problematic, now with an 80 wire cable its
fine.
One point of clarification... I started out with a simple hdparm -d1
which failed 85% of the time. I added the other stuff only to enhance the
-d0 state I was left with.
On Fri, 12 Jan 2001, Andre Hedrick wrote:
I told you that I have the new code that is scheduled for 2.5 certified on
analizers to be technically correct as it relates to the "state diagrams"
in the standard.
"Technically correct" and "state diagrams as in the standard" mean less
that
On Fri, 12 Jan 2001, Andre Hedrick wrote:
It works perfectly and exactly as it is defined to work by the rules.
Getting the rules correct == 'the concept of "working"'.
Don't be silly.
You're entirely ignoring the concept of hardware bugs. Which is one very
likely reason for this whole
On Sat, 13 Jan 2001, Andrew Morton wrote:
3c59x calls disable_irq() once per minute, and seems to be
one of the most-affected drivers.
The ne2k thing seems to be the _most_ affected one, as far as I can tell.
However, it could easily be a matter of timing - for example, if the
driver does
In article [EMAIL PROTECTED],
David Woodhouse [EMAIL PROTECTED] wrote:
We don't need to overdesign it. get_module_symbol() basically provided
this for us. The only thing really wrong with it was the lack of use
count handling, which I fixed a while ago.
NO NO NO!
You miss _entirely_ the
On Sun, 14 Jan 2001, David S. Miller wrote:
Marcelo Tosatti writes:
While taking a look at page_launder()...
...
set_page_dirty() may lock the pagecache_lock which means potential
deadlock since we have the pagemap_lru_lock locked.
Indeed, the following should work as a
On Sun, 14 Jan 2001, David Woodhouse wrote:
But I have no particular attachment to it. All I'm asking for is a way to
avoid having init order dependencies where previously there was no need
for them, by having a way to put entries in the inter_module_get() table
at compile time.
Note
On 14 Jan 2001, Christoph Rohland wrote:
Since we do not mark the page dirty at allocation time the vm can drop
it at any time as long as it is not written to. But shmem never
adjusts its accounting to that and will happily increase the use
counter for both the inode and the fs.
Why do
On Sun, 14 Jan 2001, David Woodhouse wrote:
But in the case of the CFI probe code and also I believe DRM, we don't
actually know precisely which feature we're going to require until we've
done the hardware probe at runtime.
That's ok.
This is what "request_module()" and "kmod" is all
In article [EMAIL PROTECTED],
jamal [EMAIL PROTECTED] wrote:
Before getting excited i had the courage to give plain 2.4.0-pre3 a whirl
and somethings bothered me.
Note that "sendfile(fd, file, len)" is never going to be faster than
"write(fd, userdata, len)".
That's not the point of
On Sun, 14 Jan 2001, Ingo Molnar wrote:
There is a Samba patch as well that makes it sendfile() based. Various
other projects use it too (phttpd for example), some FTP servers i
believe, and khttpd and TUX.
At least khttpd uses "do_generic_file_read()", not sendfile per se. I
assume TUX
On Sun, 14 Jan 2001, David Woodhouse wrote:
That's the one flaw in the inter_module_get() stuff - we could do with a
way to put entries in the table at _compile_ time, rather than _only_ at
run time.
Ok, I can buy that. Not having to initialize explicitly would be nice, but
if so we
On Sun, 14 Jan 2001, Gerhard Mack wrote:
PS I wish someone would explain to me why distros insist on using WU
instead given it's horrid security record.
I think it's a case of "better the devil you know..".
Think of all the security scares sendmail has historically had. But it's a
pretty
In article [EMAIL PROTECTED],
Jonathan Thackray [EMAIL PROTECTED] wrote:
how would sendpath() construct the Content-Length in the HTTP header?
You'd still stat() the file to decide whether to use sendpath() to
send it or not, if it was Last-Modified: etc. Of course, you'd cache
stat() calls
On Mon, 15 Jan 2001, Robert Kaiser wrote:
I finally found the reason why 386es have trouble booting the 2.4.0 kernel:
Good job.
Pentiums are only lucky to not crash because they have a bigger TLB than 386s.
Actually, with the 4M pages, it's not a question of luck any more - they
just
On Mon, 15 Jan 2001, Tobias Ringstrom wrote:
Last time I checked this was issued for perfectly known and valid bridges
that advertice no IO resources. Isn't it a bit silly to issue that
warning for that case, or am I missing something?
Ehh - so what do they bridge, then?
I'd say that a
In article [EMAIL PROTECTED],
Albert D. Cahalan [EMAIL PROTECTED] wrote:
Ingo Molnar writes:
On Mon, 15 Jan 2001, Jonathan Thackray wrote:
It's a very useful system call and makes file serving much more
scalable, and I'm glad that most Un*xes now have support for it
(Linux, FreeBSD, HP-UX,
In article [EMAIL PROTECTED],
Paul Hubbard [EMAIL PROTECTED] wrote:
We're having some problems with the 2.4.0 kernel on our SGI 1450, and
were hoping for some help.
The box is a quad Xeon 700/2MB, with 4GB of memory, ServerSet III HE
chipset, RH6.1 (slightly modified for local configuration)
In article [EMAIL PROTECTED],
Jeff Garzik [EMAIL PROTECTED] wrote:
Linus Torvalds wrote:
In article [EMAIL PROTECTED],
Jeff Garzik [EMAIL PROTECTED] wrote:
$!@#@! pre6 is already out :)
Yes, and for heavens sake don't use it, [...]
Too late... First and foremost, a correction: The VM
On Mon, 15 Jan 2001, Dunlap, Randy wrote:
Thanks for looking into this. I'll be out of touch for
the rest of this week, but Petr ([EMAIL PROTECTED])
should be able to test patches that Ingo comes up with.
Ok. That means that the problem is that we _should_ look at
the pirq table
On Mon, 15 Jan 2001, dean gaudet wrote:
On Mon, 15 Jan 2001, Ingo Molnar wrote:
just for kicks i've implemented sendpath() support.
_syscall4 (int, sendpath, int, out_fd, char *, path, off_t *, off, size_t, size)
hey so how do you implement transmit timeouts with sendpath() ?
On Tue, 16 Jan 2001, Ingo Molnar wrote:
yep, correct. But take a look at the trick it does with file descriptors,
i believe it could be a useful way of doing things. It basically
privatizes a struct file, without inserting it into the enumerated file
descriptors. This shows that 'native
In article [EMAIL PROTECTED],
Jakob Borg [EMAIL PROTECTED] wrote:
Hi,
I recently got this in my logs after moving /home to reiserfs. It is a plain
2.4.1-pre7 SMP system (.config attached).
Jan 16 19:15:02 narayan kernel: journal_begin called without kernel lock held
Jan 16 19:15:02 narayan
In article [EMAIL PROTECTED],
=?us-ascii?Q?Andr=E9?= Dahlqvist [EMAIL PROTECTED] wrote:
Don't get me wrong, I am personally really excited that reiserfs was
included. I just thought that you basically wanted 2.4.1 to be "boring".
Reiserfs inclusion in 2.4.1 was basically the plan for the very
On Tue, 16 Jan 2001, Aaron Lehmann wrote:
On Tue, Jan 16, 2001 at 08:55:58PM +0100, Andr? Dahlqvist wrote:
I was very surprised when I checked my local kernel.org mirror this
morning, and noticed that the latest 2.4.1 pre-patch had grown to
~180 kb in size. I was even more surprised when
Rick Jones [EMAIL PROTECTED] wrote:
: Agreed -- the hard-coded Nagle algorithm makes no sense these days.
:
: The fact I dislike about the HP-UX implementation is that it is so
: _obviously_ stupid.
:
: And I have to say that I absolutely despise the BSD people. They did
: sendfile()
In article [EMAIL PROTECTED],
Ben Mansell [EMAIL PROTECTED] wrote:
On 14 Jan 2001, Linus Torvalds wrote:
And no, I don't actually hink that sendfile() is all that hot. It was
_very_ easy to implement, and can be considered a 5-minute hack to give
a feature that fit very well in the MM
On Wed, 17 Jan 2001, Rick Jones wrote:
The fact that I understand _why_ it is done that way doesn't mean that I
don't think it's a hack. It doesn't allow you to sendfile multiple files
etc without having nagle boundaries, and the header/trailer stuff really
isn't a generic solution.
On Wed, 17 Jan 2001, Petr Matula wrote:
I did the changes above to 2.4.0 source.
Did you also remove the two lines that disabled pirq routing if an IO-APIC
was enabled?
Kernel with these changes can't detect my SCSI drive. It prints these messages
in cycle:
Which SCSI adapter is this?
On Wed, 17 Jan 2001, Rick Jones wrote:
(a) make sure that system call latency is low enough that there really
aren't any major reasons to avoid system calls. They're just function
calls - they may be a bit heavier than most functions, of course, but
people shouldn't
On Thu, 18 Jan 2001, Christoph Hellwig wrote:
/*
* a simple page,offset,legth tuple like Linus wants it
*/
struct kiobuf2 {
struct page * page; /* The page itself */
u_int16_t offset; /* Offset to start of valid data */
u_int16_t
In article [EMAIL PROTECTED],
Rik van Riel [EMAIL PROTECTED] wrote:
On Wed, 10 Jan 2001, Linus Torvalds wrote:
I looked at it a year or two ago myself, and came to the
conclusion that I don't want to blow up our page table size by a
factor of three or more, so I'm not personally interested
Current half-assed changelog:
2.4.1-pre8:
- Don't drop a megabyte off the old-style memory size detection
- remember to UnlockPage() in ramfs_writepage()
- 3c59x driver update from Andrew Morton
- egcs-1.1.2 miscompiles depca: workaround by Andrew Morton
- dmfe.c module init fix: Andrew
In article [EMAIL PROTECTED],
Eric S. Raymond [EMAIL PROTECTED] wrote:
* For a socket or FIFO (S_IFSOCK, S_IFIFO) it reports the count of bytes
waiting to be read.
Don't depend on it. That's pretty much implementation-defined: use the
FIONREAD ioctl to fetch available info from pipes, sockets,
On Thu, 18 Jan 2001, Andreas Dilger wrote:
Actually, this is a great example, because at one point I was working
on a device interface which would offload all of the disk-disk copying
overhead to the disks themselves, and not involve the CPU/RAM at all.
It's a horrible example.
On Thu, 18 Jan 2001, Ingo Molnar wrote:
[ BSD's TCP_NOPUSH ]
this is what MSG_MORE does.Basically i added MSG_MORE for the purpose of
getting perfect TUX packet boundaries (and was ignorant enough to not know
about BSD's NOPUSH), without an additional system-call overhead, and
without
On Thu, 18 Jan 2001, Ingo Molnar wrote:
Basically MSG_MORE is a simplified probability distribution of the next
SEND, and it already covers all the other (iovec, nagle, TCP_CORK)
mechanizm available, in a surprisingly easy way IMO. I believe MSG_MORE is
very robust from a theoreticaly
On Thu, 18 Jan 2001, Christoph Hellwig wrote:
Remove this. I don't think it's valid to lock the pages. Who wants to use
this anyway?
E.g. in the block IO pathes the pages have to be locked.
It's also used by free_kiovec to see wether to do unlock_kiovec before.
This is all MUCH
On Thu, 18 Jan 2001, Rick Jones wrote:
Linus Torvalds wrote:
Remember the UNIX philosophy: everything is a file.
...and a file is simply a stream of bytes (iirc?)
Indeed.
And normal applications really shouldn't need to worry about things like
packetization etc.
Of course, many
On Thu, 18 Jan 2001, Roman Zippel wrote:
Not going to happen.
device-to-device is not the same as disk-to-disk. A better example would
be a streaming file server.
No, it wouldn't be.
[ Crystal ball mode: ON ]
It's too damn device-dependent, and it's not worth it. There's no way to
On Thu, 18 Jan 2001, Andrea Arcangeli wrote:
I'm all for TCP_CORK but it has the disavantage of two syscalls for doing the
flush of the outgoing queue to the network. And one of those two syscalls is
spurious. Certainly it makes perfect sense that the uncork flushes the outgoing
queue,
On Fri, 19 Jan 2001, Roman Zippel wrote:
On Thu, 18 Jan 2001, Linus Torvalds wrote:
It's too damn device-dependent, and it's not worth it. There's no way to
make it general with any current hardware, and there probably isn't going
to be for at least another decade or so. And because
In article [EMAIL PROTECTED],
Russell Leighton [EMAIL PROTECTED] wrote:
"copy this fd to that one, and optimize that if you can"
... isn't this Larry M's "splice" (http://www.bitmover.com/lm/papers/splice.ps)?
We talked extensively about "splice()" with Larry. It was one of the
motivations
In article [EMAIL PROTECTED],
Albert D. Cahalan [EMAIL PROTECTED] wrote:
What about getting rid of both that and the pointer, and just
hanging that data on the end as a variable length array?
struct kiovec2{
int nbufs;
/* ... */
struct kiobuf[0];
}
If the struct ends up having lots of
On Thu, 18 Jan 2001, Ingo Molnar wrote:
i believe a network-conscious application should use MSG_MORE - that has
no system-call overhead.
I think Andrea was thinking more of the case of the anonymous IO
generator, and having the "controller" program thgat keeps the socket
always in CORK
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] wrote:
Hello!
It's about direct i/o from/to pages,
Yes. Formally, there are no problems to send to tcp directly from io space.
Actually, as long as there is no "struct page" there _are_ problems.
This is why the NUMA stuff was brought up - it
In article [EMAIL PROTECTED],
Albert D. Cahalan [EMAIL PROTECTED] wrote:
Tabs are 8 characters so NO tabs should be used in ANY source file what
...
Rationale: Tabs force your code out to the right edge of the display
leaving no room for comments. You don't need great big gaping spaces to
On Fri, 19 Jan 2001, Mark I Manning IV wrote:
Two spaces are perfect, they delineate the blocks very nicely and dont
eat up the comments real estate.
WHAT "comments real estate". You have tons of real estate - up and down.
Don't try to move it sideways where it won't fit anyway.
Write
On Sat, 20 Jan 2001, Albert Cranford wrote:
2.4.1-pre9 changes to drivers/char/drm/drm.h are incorrect.
Please reverse this small change to compile correctly.
Actually, please revert a bit more.
(The XFree86 CVS tree is being silly - they've renamed the ioctl's after
4.0.2 instead of just
On Sat, 20 Jan 2001 [EMAIL PROTECTED] wrote:
Actually, as long as there is no "struct page" there _are_ problems.
This is why the NUMA stuff was brought up - it would require that there
be a mem_map for the PCI pages.. (to do ref-counting etc).
I see.
Is this strong "no-no-no"? What
On Sat, 20 Jan 2001, Andrea Arcangeli wrote:
On Sat, Jan 20, 2001 at 10:05:45PM +0300, [EMAIL PROTECTED] wrote:
It makes. One small packet is allowed to fly, not depending on packets_out.
So this mean if I do:
write(10*MSS)
write(1)
write(1)
2.4 can send
On 20 Jan 2001, Kai Henningsen wrote:
Then again, I could easily see those I/O devices go the general embedded
route, which in a decade or two could well mean they run some sort of
embedded Linux on the controller.
Which would make some features rather easy to implement.
I'm not
On Sat, 20 Jan 2001, Roman Zippel wrote:
AFAIK as long as that dummy page struct is only used in the page cache,
that should work, but you get new problems as soon as you map the page
also into a user process (grep for CONFIG_DISCONTIGMEM under
include/asm-mips64 to see the needed
On Sat, 20 Jan 2001, Roman Zippel wrote:
On Sat, 20 Jan 2001, Linus Torvalds wrote:
But point-to-point also means that you don't get any real advantage from
doing things like device-to-device DMA. Because the links are
asynchronous, you need buffers in between them anyway
On Mon, 22 Jan 2001, Val Henson wrote:
On Wed, Jan 17, 2001 at 11:32:35AM -0800, Linus Torvalds wrote:
However, for socket-socket, we would not have such an advantage. A
socket-socket sendfile() would not avoid any copies the way the
networking is done today. That _may_ change
The ChangeLog may not be 100% complete. The physically big things are the
PPC and ACPI updates, even if most people won't notice.
Linus
pre10:
- got a few too-new R128 #defines in the Radeon merge. Fix.
- tulip driver update from Jeff Garzik
- more cpq and DAC elevator
On Tue, 23 Jan 2001, Marcelo Tosatti wrote:
Any technical reason why the background page aging fix was not applied?
Because I have not heard anybody claim that it makes a huge difference..
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
In article [EMAIL PROTECTED], David Ford [EMAIL PROTECTED] wrote:
Unfortunately klogd reads /procerg.
So the following is a painstakingly slow hand translation, I'll only print
the D state entries unless someone asks otherwise.
You seem to be pretty much able to reproduce this at will,
On Sun, 28 Jan 2001, Jens Axboe wrote:
So what happens is that somebody takes a page fault (and gets the mm
lock), tries to read something in, and never gets anything back, thus
leaving the MM locked.
What was the trace of this? Just curious, the below case outlined by
Linus should
On Sun, 28 Jan 2001, Marcelo Tosatti wrote:
This is the smoking gun here, I bet, but I'd like to make sure I see the
whole thing. I don't see _why_ we'd have deadlocked on __wait_on_page(),
but I think this is the thread that hangs on to the mm semaphore.
I was able to reproduce it
On Sun, 28 Jan 2001, Marcelo Tosatti wrote:
Why dont you just put set_page_dirty() back in page_launder() in case
writepage() fails?
Because a EIO or similar should _not_ be re-tried or kept dirty.
Imagine a bad user that goes over his quota on purpose, and then every
single write will
On Sun, 28 Jan 2001, Jens Axboe wrote:
How about this instead?
I really don't like this one. It will basically re-introduce the old
behaviour of waking people up in a trickle, as far as I can tell. The
reason we want the batching is to make people have more requests to sort
in the elevator,
I just uploaded it to kernel.org, and I expect that I'll do the final
2.4.1 tomorrow, before leaving for NY and LinuxWorld. Please test that the
pre-kernel works for you..
The main noticeable things in pre11 are fixing some bugs that crept in
after 2.4.0 - the block device queuing improvements
On Sun, 28 Jan 2001, Dieter Ntzel wrote:
I just uploaded it to kernel.org, and I expect that I'll do the final
2.4.1 tomorrow, before leaving for NY and LinuxWorld. Please test that the
pre-kernel works for you..
Hello Linus,
can we please see Andrew's latest ACPI fixes ([Acpi]
In article 01a301c0895e$b142cc90$[EMAIL PROTECTED],
mirabilos [EMAIL PROTECTED] wrote:
Does 2.4.1 when released, include e.g. Jens' loop patch?
Because it seems stable and loop else were buggy.
Only if Jens sends it to me in a timely fashion (which by now means
"real soon").
On Sun, 28 Jan 2001, David D.W. Downey wrote:
I was on ftp.kernel.org and ftp.us.kernel.org and could not find it in the
/pub/linux/kernel/v2.4 or /pub/linux/kernel/v2.4/test-kernels/
directories. Is it somewhere different?
All my "current" test-patches are always under
On Mon, 29 Jan 2001, Robert Siemer wrote:
From: Linus Torvalds [EMAIL PROTECTED]
Another one..
Robert, can you get the dump_pirq script from the pcmcia_cs package
and send the output to us?
...it seems to reflect my settings in the bios:
No, but that's really interesting
On Mon, 29 Jan 2001, Aaron Tiensivu wrote:
My ASUS SP97-V complains about PIRQ conflicts so I gave this a whirl
(It is SiS 5598 based)
Your pirq values are different - they are in the 0x41-0x44 range, like the
old SiS router code assumes. Except for one that has value 0x62, which the
old
On Sun, 28 Jan 2001, Tim Hockin wrote:
In reading the PIRQ specs, and making it work for our board, I thought
about this. PIRQ states that link is chipset-dependant. No chipset that I
have seen specifies what link should be. So, as this case demonstrates, it
may be 'A' - the value the
On Mon, 29 Jan 2001, Robert Siemer wrote:
and see if that changes the behaviour.
It doesn't. A diff from the kernel output is following. Maybe it
helps...
Actually, this looks like it _did_ fix something - now the kernel no
longer thinks there is a IRQ routing conflict, so it does
On Mon, 29 Jan 2001, Aaron Tiensivu wrote:
| Which one was it you got a PIRQ conflict for before? as it te device at
| 00:01.00 with the strange "0x62" entry?
Yes.
You've got the pirq setup from hell.
Mind doing that "dump_pirq" thing, preferably run on an _unmodified_ 2.4.0
kernel (ie
On Mon, 29 Jan 2001, Robert Siemer wrote:
Further I always see '09' in the Configuration Space at Interrupt_Line
(0x3c) for the 00:01.2 USB Controller. But 2.4.0 says:
Interrupt: pin A routed to IRQ 12
while 2.4.0-test9 states:
Interrupt: pin A routed to IRQ 9
Ahhah!
I bet it's the
On Mon, 29 Jan 2001, Martin Diehl wrote:
Right, seems the 0x41/0x01 thing. I have the 0x01 case with SiS 85C503
router rev. 01. Hopefully the 0x41 boards have a different revision. My
fear however is, this is due to BIOS implementation of the routing table.
Using the docs of the 85C503
Could people that had problems with SiS interrupt handling before please
give 2.4.0-test12 a final whirl before I release it as 2.4.1? We got a lot
of pirq tables from people, and Martin Diehl put them together with the
hardware specs to come up with what looks to be the "final and correct"
SiS
On Mon, 29 Jan 2001, Aaron Tiensivu wrote:
Problem still exists, diffed to last kernel:
Yes. But everything works for you, no? Including USB?
The problem is that you have this routing table entry:
00:01 slot=00 0:62/1eb8 1:00/ 2:00/ 3:00/
which is really for the USB
1 - 100 of 24431 matches
Mail list logo
