On Tue, Sep 19 2000, Peter Osterlund wrote:
> > 2) the block number is smaller than head (or head->next
> >if the current request is unplugged)
>
> The second condition is not so simple in the case of latency control.
> Consider the following queue:
>
> sector: 100 200 300 400 10 20 30
>
On Tue, Sep 19 2000, Rik van Riel wrote:
> This is a bug in Andrea's idea. The request should only
> be inserted at the end of the list if:
>
> 1) the block numbre is bigger than head->prev (which you
>already have)
Of course.
> 2) the block number is smaller than head (or head->next
>
This will break NWFS and require I put back in all the locks Al Viro
told me to remove.
Jeff
Linus Torvalds wrote:
>
> In article <[EMAIL PROTECTED]>,
> Eric PAIRE <[EMAIL PROTECTED]> wrote:
> >
> >In open.c:do_truncate(), the call to notify_change() is protected by
> >the inode->i_sem,
Linus Torvalds wrote:
>
> I'd love to link against libgcc, but for the fact that
>
> - gcc developers have sometimes done horribly stupid things, and NOT
>linking against libgcc has been an excellent way of not getting
>bitten by it. Things like the exception handling etc, where not
On Tue, 19 Sep 2000, Daniel Lange wrote:
> Hi all,
> I don't know how relevant to this list my question is, as I'm a quite
> new subscriber, but I was perusing the linux kernel (2.2.16) Makefiles and
> ran into this in /usr/src/linux/net/ethernet/Makefile:
>
>tar -cvf /dev/f1 .
>
I
In article <[EMAIL PROTECTED]>,
Eric PAIRE <[EMAIL PROTECTED]> wrote:
>
>In open.c:do_truncate(), the call to notify_change() is protected by
>the inode->i_sem, which seems to me useless, and thus can be removed.
And exactly how do you now protect against the race of another process
doing a
In article <[EMAIL PROTECTED]>,
Richard Henderson <[EMAIL PROTECTED]> wrote:
>On Tue, Sep 19, 2000 at 12:22:41PM +0200, Andreas Schwab wrote:
>> IMHO it's a bug in gcc that it does not inline the comparison inside the
>> switch expression, since it already does it in all other places. Perhaps
On Linux kernel 2.2.17 running on an intel PIII system with 1GB RAM I
cannot successfully create a ramdisk of greater than 512MB. The relevant
kernel parameter (CONFIG_BLK_DEV_RAM_SIZE) was set to 737280 before
rebuilding the kernel.
So I do the following from the command line:
dd bs=1024
In article <[EMAIL PROTECTED]>, Dag Bakke <[EMAIL PROTECTED]> wrote:
>Tigran Aivazian wrote:
>>
>> On Mon, 18 Sep 2000, Derek Wildstar wrote:
>>
>> > On 18 Sep 2000, Alex Romosan wrote:
>> >
>> > I get the same thing with a Xircon realport 10/100/modem card. Works
>> > great in test9-pre1 and
Hi all,
I don't know how relevant to this list my question is, as I'm a quite
new subscriber, but I was perusing the linux kernel (2.2.16) Makefiles and
ran into this in /usr/src/linux/net/ethernet/Makefile:
tar -cvf /dev/f1 .
Since I do all my compiling for the i386 tree, I don't know
Rik van Riel <[EMAIL PROTECTED]> writes:
> This is a bug in Andrea's idea. The request should only
> be inserted at the end of the list if:
>
> 1) the block numbre is bigger than head->prev (which you
>already have)
>
> AND
>
> 2) the block number is smaller than head (or head->next
>
On Tue, Sep 19, 2000 at 07:22:48PM +0200, Jamie Lokier wrote:
> That instruction loads the _value_ of p. I.e. reads the memory from
> location 0x80495a4 into %eax. The source instruction was:
>
>movl p,%eax
>
> The instructions that you're thinking of, that load fixed addresses,
>
Thanks, Chris Mason,
> > few weeks ago, I installed a PROMISE Ultra66 IDE card into my SMP Linux
> > box. But my box sometimes hang up at high load average with "stuck on TLB
> > IPI wait (CPU#0)" messages.
> > My kernel is linux-2.2.17 with following patches.
> >
On Tue, Sep 19, 2000 at 10:23:05AM -0700, Richard Henderson wrote:
> On Tue, Sep 19, 2000 at 04:32:16PM +0200, Andrea Arcangeli wrote:
> > Wrong: it's really loading the _address_.
> [...]
> > 80483f5: a1 a4 95 04 08 mov0x80495a4,%eax
> >^^^
On Mon, 18 Sep 2000, Alan Cox wrote:
>> The problem is really that SI_SIGIO is negative, but it should be positive
>> to make SI_FROMUSER return false on it.
>>
>> Changing it would unfortunately break binary compatibility. This patch
>
It would be better to change SI_SIGIO in all the
On Tue, 19 Sep 2000, Andries Brouwer wrote:
>
> The same here. However, reverting the 1-line change in
> linux/drivers/scsi/Makefile makes things work again.
Yes, the SCSI layer is fragile wrt some initialization ordering. The devfs
setup in particular, but there might be other things there
Hello, using 2.4.0-test9-pre2 and thinking that there are no major bugs
I found this again, I have observed what I think it's the same bug since
2.4.0-test7.
All the traces end up in stext_lock, so I think it' the same bug, this
time it happened when I was about to use the iomega parport zip
On Tue, Sep 19, 2000 at 09:32:09AM -0700, Christoph Lameter wrote:
> Tried burning a cd with pre4 and devfs. There is no /dev/sg0 and /dev/scsi
> is empty.
It 'moved'. Do a 'cd /dev/scsi; ln ../host0' for temporary workaround.
Well, I 'tried to boot' from scsi, its even more fun...
--
marko
** Reply to message from "Richard B. Johnson" <[EMAIL PROTECTED]> on Tue,
19 Sep 2000 11:58:34 -0400 (EDT)
> Tell the driver maintainer that you found a BUG. There is no floating-
> point allowed in the kernel because the state of the FP Unit is
> undefined in the kernel. If you 'define' it,
On Tue, Sep 19, 2000 at 04:32:16PM +0200, Andrea Arcangeli wrote:
> Wrong: it's really loading the _address_.
[...]
> 80483f5: a1 a4 95 04 08 mov0x80495a4,%eax
>^^^ ^
No, that's an absolute memory load. If we were loading
[EMAIL PROTECTED] (Michael Vines) writes:
> I was just wondering if you can use floating point while servicing a
> syscall in the kernel? Doing a
> find -name \*.c -exec grep float {} \; -print
> turned up a couple drivers that seem to be using fp. Are there any
> known issues that I should
On Tue, Sep 19 2000, Andries Brouwer wrote:
> On Tue, Sep 19, 2000 at 11:29:31AM -0400, Simon Kirby wrote:
> > Hello,
> >
> > 2.4.0-test9-pre3 seems to boot and work fine, but 2.4.0-test9-pre4 with
> > the same .config doesn't. It stops here:
>
> The same here. However, reverting the 1-line
On Tue, 19 Sep 2000, Linus Torvalds wrote:
> > moving the software RAID drivers into drivers/md/,
> Make it so.
OK. Apply the attached diff and then:
$ mv drivers/block/{md,raid{0,1,5},xor}.c drivers/md/
and all might be well.
The Config.in should probably move at some stage too.
I'm not
On Tue, Sep 19, 2000 at 07:50:05AM -0700, Linus Torvalds wrote:
>
>
> On Tue, 19 Sep 2000, Rogier Wolff wrote:
> >
> > If gcc starts shouting:
> >
> > somefile.c:1234: declared inline function 'serial_paranoia_check' is
> > somefile.c:1234: larger than 1k. Declining to honor the inline
Keith Owens wrote:
>
> Sections marked __exit get discarded when the code is linked into the
> kernel, they are kept when the code is a module. But the spin lock
> code is kept (in another section) and relocation from .text.lock back
> to .text.exit fails. Possible fixes:
>
> Use RTC as a
On Tue, Sep 19, 2000 at 11:29:31AM -0400, Simon Kirby wrote:
> Hello,
>
> 2.4.0-test9-pre3 seems to boot and work fine, but 2.4.0-test9-pre4 with
> the same .config doesn't. It stops here:
The same here. However, reverting the 1-line change in
linux/drivers/scsi/Makefile makes things work
On Tue, 19 Sep 2000, Riley Williams wrote:
> Additional comments from other developers should be cc'd to Tony as I
> don't think he's on this list. However, I am on the list, so there is
> no need to CC to me...
>
> > any hints?
>
> Well, I'm not even sure what you mean by "kernel governance"
Tried burning a cd with pre4 and devfs. There is no /dev/sg0 and /dev/scsi
is empty.
-
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/
Daniel Phillips wrote:
> Alexander Viro wrote:
> > On Tue, 19 Sep 2000, Daniel Phillips wrote:
> >
> > > !Mapped, !Uptodate, Dirty: pending map and write
> >
> > Wrong. It's an instant BUG at line 711 in ll_rw_blk.c - remember these
> > reports?
Yes, correct, this state should not escape
It looks like the reason for this error was that my hardware real time
clock was not functioning properly. I ran the server's hardware
diagnostics and that seems to have fixed the problem.
>Date: Wed, 13 Sep 2000 17:04:02 -0700
>To: [EMAIL PROTECTED]
>From: Kamlesh Bans <[EMAIL PROTECTED]>
On Tue, Sep 19 2000, Alan Cox wrote:
> > Thus my gut tells me the correct link order should be:
> >
> > 1) SCSI core.
> > 2) low-level drivers (in same order as specified in hosts.c).
> > 3) upper level drivers.
>
> You need to get the i2o scsi driver run last afte the low level and
On Tue, Sep 19 2000, Marko Kreen wrote:
> Tried running pre4, here notes:
>
> 1) scsi devfs: /dev/scsi/host0 is now /dev/host0, /dev/scsi exist
>but is empty.
> 2) lots of messages: Warning - running *really* short on DMA buffers
>No oops yet.
>
Probaly because we used the module part
On Tue, 19 Sep 2000, Michael Vines wrote:
> I was just wondering if you can use floating point while servicing a
> syscall in the kernel? Doing a
> find -name \*.c -exec grep float {} \; -print
> turned up a couple drivers that seem to be using fp. Are there any
> known issues that I should
Alexander Viro wrote:
>
> On Tue, 19 Sep 2000, Daniel Phillips wrote:
>
> > The more I think about it the less clear and ambiguous I find it.
> > When you add the dirty bit into the pot you get:
> >
> >Mapped, Uptodate, Dirty: not possible
>
> Sure, it is possible - that's how the
On Tue, Sep 19, 2000 at 12:22:41PM +0200, Andreas Schwab wrote:
> IMHO it's a bug in gcc that it does not inline the comparison inside the
> switch expression, since it already does it in all other places. Perhaps
> some problem with the patterns in the machine description.
Perhaps, but without
Followup to: <[EMAIL PROTECTED]>
By author:"Chris Swiedler" <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> I didn't want to post to the list with this, but [EMAIL PROTECTED]
> didn't get a reply.
>
> The NNTP gateway hasn't been working for two weeks-- the last list message
> was
Hello,
2.4.0-test9-pre3 seems to boot and work fine, but 2.4.0-test9-pre4 with
the same .config doesn't. It stops here:
agpgart: AGP aperture is 64M @ 0xe400
aha152x: processing commandline: ok
aha152x: BIOS test: passed, detected 1 controller(s)
aha152x: resetting bus...
aha152x0: vital
On Tue, 19 Sep 2000, Matthew Kirkwood wrote:
>
> It's probably solely an init-order thing but, short of
> moving the software RAID drivers into drivers/md/, I
> can't see an easy way to fix it.
That would probably not be a bad fix - especially as some people want to
split up xor.c into
Daniel Pittman <[EMAIL PROTECTED]> wrote:
> Hrm. It would seem more sensible to me that the registry, like the GDI,
> live outside the kernel. This would have some cost in terms of
> performance, I admit, but I don't think it's significant enough to care.
>
> This is, I confess, based on my
On Tue, Sep 19, 2000 at 04:01:26PM +0100, David Howells wrote:
> I can't remember exactly what it was now, but I think it was either something
> to do with spinlocks or bitops. I'll re-investigate tonight and see if I can
> come back with some benchmarks/code-snippets tomorrow.
Yes you should
I was just wondering if you can use floating point while servicing a
syscall in the kernel? Doing a
find -name \*.c -exec grep float {} \; -print
turned up a couple drivers that seem to be using fp. Are there any
known issues that I should to be aware off?
Thanks,
Mike
-
To
I've been writing a kernel module and I've noticed a measurable performance
drop between the same code compiled against linux-2.4.0-test7 and against
test8. I disassembled the code to try and work out what was going on and I saw
the following happen:
* [test8]
One of the atomic memory
On Tue, Sep 19, 2000 at 05:58:48AM -0300, Rik van Riel wrote:
> One of the issues which seems to be affecting performance
> is the elevator starvation bug, though, so I'm not sure how
You are contraddicting yourself. If you decrease the latency (so if you fix the
starvation) the global disk
On Tue, 19 Sep 2000, Rogier Wolff wrote:
>
> If gcc starts shouting:
>
> somefile.c:1234: declared inline function 'serial_paranoia_check' is
> somefile.c:1234: larger than 1k. Declining to honor the inline directive.
That's not what gcc does.
Gcc silently just doesn't inline it.
And
> Thus my gut tells me the correct link order should be:
>
> 1) SCSI core.
> 2) low-level drivers (in same order as specified in hosts.c).
> 3) upper level drivers.
You need to get the i2o scsi driver run last afte the low level and before
the high level drivers despite being in
On Tue, Sep 19, 2000 at 05:29:29AM -0300, Rik van Riel wrote:
> what I wanted to do in the new VM, except that I didn't
> see why we would want to restrict it to swap pages only?
You _must_ do that _only_ for the swap_cache, that's a specific issue of the
swap_cache during swapout (notenote: not
Hi all!!
I just compiled 2.4.0-test9-pre4 and get the following error in my
syslog:
Warning - Running really short on DMA buffers. I dont have any
ISA-devices installed and no device is in /proc/dma. I always thought
that DMA buffers are only for "old" DMA on ISA bus ...
The system runs
OK, my guess is that we may need to do some tweaking to the Makefile.
The basic idea is that you need to probe for hosts in a specific order.
The reason for this is that some host adapters emulate other types of
hardware. For example, some Buslogic cards emulate Adaptec 1542.
Typically in
Hi Rik et al.
As stated before the new mm does break shm swapping.
Under the ipctst program driving my machine into swap I get the
appended console output. After this it locked up.
I can make it run longer by giving mem= with less memory.
Greetings
Christoph
--
LILO boot:
On Mon, Sep 18, 2000 at 09:37:43PM -0400, John Wehle wrote:
> It's perhaps not optimal, however I'm not sure that it's wrong. In
It's not "wrong" in the sense that something breaks but it's definitely
suboptimal. There's no reason to reload a value that can't change because it's
embedded into
On Tue, 19 Sep 2000, Daniel Phillips wrote:
> The more I think about it the less clear and ambiguous I find it.
> When you add the dirty bit into the pot you get:
>
>Mapped, Uptodate, Dirty: not possible
Sure, it is possible - that's how the write happens
> !Mapped,
On Tue, Sep 19, 2000 at 07:17:42AM -0300, Rik van Riel wrote:
> This is a bug in Andrea's idea. The request should only
> be inserted at the end of the list if:
>
> 1) the block numbre is bigger than head->prev (which you
>already have)
If you read the code you'll see that in his previous
On Tue, Sep 19, 2000 at 04:50:26AM -0300, Rik van Riel wrote:
> When the latency gets above 10 minutes, I'd call it starvation ;)
Me too, no argument about that.
> Not average latency no, but the starvation issue should be
> fixed...
2.2.18pre9aa1 delivers acceptable latency for me with the
Hi,
Ever since the introduction of the new file locking code in 2.4.x,
NFS locking has been seriously broken. A preliminary look seems to
indicate that the problems might lie in the generic locking code: when
running the connectathon tests against another server I get crap like
Linus Torvalds wrote:
>
> On Mon, 18 Sep 2000, Alexander Viro wrote:
> > * we have several bh state components and the thing is a big,
> > fscking mess. If we look at the areas outside of the page lock we have:
>
> It's not a mess at all.
>
> I don't see why you call things "first stage"
On Tue, 19 Sep 2000, Julian Anastasov wrote:
> On Mon, 18 Sep 2000, Andi Kleen wrote:
>
> > > SI_SIGIO is not generated from kernel. The same is for the
> > > other SI_ consts < 0 not defined with __SI_CODE.
> >
> > Ok, then you have already broken binary compatibility between 2.2 and 2.4
>
>
I don't see the oops in my logs and couldn't copy it down because I was
on my way to class.
Looked like swapper barfed. The file mentioned was buffer.c I think.
Sorry I couldn't grab more details. I'll be sure to try if it happens
again.
Anyone else seeing anythign similar?
--
On Mon, 18 Sep 2000, John Rafferty Zedlewski wrote:
> Hi, I've noticed that there are quite a few hardware performance counter
> patches (which allow access to things like the Pentium Model Specific
> Registers for gathering profiling info) floating around, including Rabbit
>
Alexander Viro wrote:
> ??? You had explicitly enabled the code that was marked "experimental". If
> the warning from make config was not enough, how the hell would runtime
> warning be more useful?
Yeah, you see, If you have about 100 Linux servers to maintain, part your own,
part installed
I didn't want to post to the list with this, but [EMAIL PROTECTED]
didn't get a reply.
The NNTP gateway hasn't been working for two weeks-- the last list message
was 9/2/2000. Maybe this is common knowledge on the list (since I'm not
subscribed, I obviously wouldn't know...) but it's a little
Jeff Garzik wrote:
>
> This patch, against 2.4.0-test9-pre2, moves ethtool.h from the private
> domain of the sparc ports into include/linux. This publishes an
> existing interface, and has been discussed before. (search past lkml
> subject headers for "media tool" and "ethtool")
>
> This
Hi Tony.
> sorry for the cold call - i've been trying to find a statement
> about 'kernel governance' and how new code is accepted into the
> kernel...
To help anybody else wondering about these issues, I've cc'd my reply
to the Linux-Kernel mailing list for comments. However, please note
On Tue, 19 Sep 2000, Elmer Joandi wrote:
> Alexander Viro wrote:
>
> > How about syslog?
>
> Well, I read syslog a lot at home and servers, but customer on-site
> production computer deep reconfiguration ,
> there is another paradigm - it either works 100% or I dont care.
That's nice, but
Hi,
while porting a serial multiport driver to sparc64 i disovered that the
function get_tty_baud_rate() only returns 50 or 75 Baud
for 57600 and 115200 which is *aehm* not what i expected.
Is this something i made wrong when setting up something or
is it another "Sparc[64] is different" issue ?
Alexander Viro wrote:
> How about syslog?
Well, I read syslog a lot at home and servers, but customer on-site
production computer deep reconfiguration ,
there is another paradigm - it either works 100% or I dont care.
Looks from general talk here, that some kernel people should try
servicing
On Tue, 19 Sep 2000, Rik van Riel wrote:
> IMHO it would be really nice if this problem was solved
> on the /PAGE/ level, so it will work for non-buffer
> filesystems as well ;)
It would be nice if we separated the buffer-cache storage pages from the
pagecache buffer-using ones and from the
On Tue, Sep 19, 2000 at 04:52:25AM -0300, Rik van Riel wrote:
> > I don't like self tuning algorithms for this case, because they
> > tend to cause a disruption on the first spike (e.g. causing lots
> > of packets dropped first until the VM can adapt). When the admin
> > says "I don't care if
On Tue, 19 Sep 2000, Stephen C. Tweedie wrote:
> > ?
> > I'm afraid that I've lost you here - what do you mean?
>
> loop does a bmap() and then submits block IO. You don't want
> truncate() to revoke blocks in between the bmap and the IO completion.
It used to do bmap(), but unless somebody
Marko Kreen <[EMAIL PROTECTED]> wrote:
>Reproducible oops: 'gmix -i --sm-disable' on test9-pre2.
The fix exists but it seems it isn't merged yet.
>--
--- soundcard.c.origTue Sep 19 12:37:52 2000
+++ soundcard.c Tue Sep 19 12:38:45 2000
@@ -267,6 +267,7 @@
On Tue, Sep 19, 2000 at 06:45:43AM -0400, Alexander Viro wrote:
>
>
> On Tue, 19 Sep 2000, Stephen C. Tweedie wrote:
>
> > > ?
> > > I'm afraid that I've lost you here - what do you mean?
> >
> > loop does a bmap() and then submits block IO. You don't want
> > truncate() to revoke blocks in
Hi Linus,
a) in fget, file=NULL is not needed
b) removing _fput and __fput makes fput() code a lot more readable because
on their own _fput/__fput are meaningless and not used at all.
Please consider this patch. Fully tested under 2.4.0-test9-pre4.
Regards,
Tigran
---
Hi,
On Fri, Sep 15, 2000 at 08:31:43AM -0400, Alexander Viro wrote:
> > Also truncate inode locking is needed to get a halfway reliable loopback
> > device (unlike the current one)
>
> ?
> I'm afraid that I've lost you here - what do you mean?
loop does a bmap() and then submits block IO.
On Sep 19, 1:08pm, Matti Aarnio wrote:
>
> On Tue, Sep 19, 2000 at 02:58:01AM -0700, Jeremy Higdon wrote:
> > Hello,
> >
> > I'm using a 64 bit variable in a switch statement. Gcc is generating code
> > which make calls to __ucmpdi2, a function defined in libgcc. I figured
> > out that it
On Tue, 19 Sep 2000, Anton Petrusevich wrote:
> please, check carefully Rik's VM patch, it definitly contains a
> deadlock, which can be seen on low-memory computers. Try mem=8m. I
> wasn't able to use any Rik patch since against -test8 (-t8-vmpatch{2,4},
> -test9-pre{1,2}). It boots
Matti Aarnio <[EMAIL PROTECTED]> writes:
|> On Tue, Sep 19, 2000 at 02:58:01AM -0700, Jeremy Higdon wrote:
|> > Hello,
|> >
|> > I'm using a 64 bit variable in a switch statement. Gcc is generating code
|> > which make calls to __ucmpdi2, a function defined in libgcc. I figured
|> > out that
On 18 Sep 2000, Peter Osterlund wrote:
> Andrea Arcangeli <[EMAIL PROTECTED]> writes:
>
> > > The only disadvantage I can see is that the new patch doesn't handle
> > > consecutive insertions in O(1) time, but then again, the pre-latency
> >
> > We can still do that by trivially fixing a bit
On Mon, 18 Sep 2000, Christopher Allen Wing wrote:
.. snipped ..
> tar should work okay, I think; by default it uses textual user names
> instead of numeric UIDs.
Not true. All the kernels I download from a certain local mirror are owned
by the local user 'tarabas' since the uid happens to
Tried running pre4, here notes:
1) scsi devfs: /dev/scsi/host0 is now /dev/host0, /dev/scsi exist
but is empty.
2) lots of messages: Warning - running *really* short on DMA buffers
No oops yet.
--
marko
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Tue, Sep 19, 2000 at 02:58:01AM -0700, Jeremy Higdon wrote:
> Hello,
>
> I'm using a 64 bit variable in a switch statement. Gcc is generating code
> which make calls to __ucmpdi2, a function defined in libgcc. I figured
> out that it was the switch statement from examining the generated
Hello,
I'm using a 64 bit variable in a switch statement. Gcc is generating code
which make calls to __ucmpdi2, a function defined in libgcc. I figured
out that it was the switch statement from examining the generated code.
The question is whether I should change C code to avoid constructions
On Tue, 19 Sep 2000, Daniel Grimwood wrote:
> am having many random fatal oopses with my K6-2 350. Can't find
> anything related on the mailing list archive, so here it is. Also, I'm
> not subscribed to the mailing list but do read it via NNTP, a CC: would
> be much appreciated :). TIA.
Do
Hi,
It would appear that the changes in pre3 and pre4 break
RAID autorun. This is rather bothersome for those who
have RAIDed root filesystems.
It's probably solely an init-order thing but, short of
moving the software RAID drivers into drivers/md/, I
can't see an easy way to fix it.
cheers,
On Mon, 18 Sep 2000, Byron Stanoszek wrote:
> I've finally had a chance to test out the new VM patch on my 32mb system.
>
> It runs much, much better than the previous test8, and the
> pages->swap change is actually much smoother than I had expected
> it to be considering the recent talk about
Jeff Garzik wrote:
> Helge Hafting wrote:
> >
> > Rogier Wolff wrote:
> > [...]
> > > No, that's not it. They parse /proc/pci or the output of lspci to
> > > determine which module to insert.
> >
> > Faster, and fine for pci-scsi. I believe you still need
> > to testload modules for isa-scsi.
Helge Hafting wrote:
>
> Rogier Wolff wrote:
> [...]
> > No, that's not it. They parse /proc/pci or the output of lspci to
> > determine which module to insert.
>
> Faster, and fine for pci-scsi. I believe you still need
> to testload modules for isa-scsi.
When PCI probing fails, the user is
On Mon, 18 Sep 2000, Alexander Viro wrote:
> On Sun, 17 Sep 2000, Linus Torvalds wrote:
>
> > And as we've seen, simplifying this area would not necessarily be a bad
> > thing ;)
> >
> > Right now I'll just do the minimal fix, though, I think.
>
> Fine with me. I'll do the full analysis
Rogier Wolff wrote:
[...]
> No, that's not it. They parse /proc/pci or the output of lspci to
> determine which module to insert.
Faster, and fine for pci-scsi. I believe you still need
to testload modules for isa-scsi.
Helge Hafting
-
To unsubscribe from this list: send the line
Byron Stanoszek wrote:
>
> I've finally had a chance to test out the new VM patch on my 32mb system.
>
> It runs much, much better than the previous test8, and the pages->swap change
> is actually much smoother than I had expected it to be considering the recent
> talk about making it more
On Sun, 17 Sep 2000, Mark Orr wrote:
> Has anyone else tried 240-test9-pre2 on low-memory systems?
>
> I compiled 240t9p2, bzlilo'ed it, and rebooted. During
> boot it tripped up on e2fsck -- it was at maximum mount count
> and it stopped during the check.
> Sys: pentium 100, 16Mb RAM + 17 Mb
I just found a big bug in kernel 2.4.0-test8 that leads to a major
crash because PID 4 [kupdate] dies.
I could reproduce the problem by doing this:
- Open StarOffice under KDE
- Create new textfile
- Try to save it under a via NFS mounted directory
Here are the two kernel oopses that occured on
Andrea Arcangeli wrote:
> int * p;
> [...]
> spin_lock();
> a = *p;
> spin_unlock();
>
> spin_lock();
> b = *p;
> spin_unlock();
> [With "memory" clobber"] the [second] reload of the address of `p'
> isn't necessary and gcc is wrong in
Hello,
Trying kernel 2.4.0-test9-pre3 and 2.4.0-test9-pre4 results in kernel
panic with AIC-7890...
Regards
--
Angel Luis Uruñuela <> Unix Systems Administrator
"You can't change the past, but you can ruin
the present by worrying over the future"
-
To unsubscribe from this list: send
Linus Torvalds wrote:
> > Maybe nobody ever insmod'ed a module for a scsi device they don't
> > have?
>
> No, that's not it - the way most distributions do SCSI auto-detection is
> to load modules until they succeed.
> At least I _think_ that's what they do. That's what I'd do if I were a
>
On Sun, 17 Sep 2000, Andrea Arcangeli wrote:
> I don't know the internals of other OSes so I've no idea if that
> was a generic problem or not (guess why I started playing with
> linux: just to finally see the internals of an OS :) thus I
> don't know if this problem is generic or not.
Please
Reproducible oops: 'gmix -i --sm-disable' on test9-pre2.
Loaded sound modules: sb, gus (in this order)
Oops itself:
ksymoops 2.3.4 on i686 2.4.0-test9. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.0-test9/ (default)
Linus Torvalds wrote:
>
>
> On Mon, 18 Sep 2000, David Woodhouse wrote:
> >
> > [EMAIL PROTECTED] said:
> > > Note that with most versions of gcc this is all a complete non-issue,
> > > as most versions of gcc will _always_ inline a function that the user
> > > has asked to be inlined. So the
** On Sep 19, Marty Fouts scribbled:
> Gene did the instruction set architecture along with some others. I think he
> was also involved in the i/o architecture.
Marty, could you _please_ stop posting to this thread on lkml and _PLEASE_
learn how to snip messages and _DON'T_ quote everything you
Has anyone had any problems with software RAID causing high loadaverage
peaks? I've got a number of i586 boxes here, dual IDE controllers, one
drive on each controller. They're using RAID 1 across the two
drives. Every few hours, the load average peaks very high, and it appears
to be the RAID
Hi
I am working on booting linux from diskonchip2000 provided by M-systems.
kernel version 2.2.14-12
TFFS 4.2
I am following Aug installation manual.
I have successfully made DOC as additional chip and created a personal
filesystem from doc.
When i am trying to make run doc-lilo command i get
On Tue, 19 Sep 2000, Dan Aloni wrote:
> /sbin/hdparm -c 1 -m 16 -d -X66 /dev/hda
> /sbin/hdparm -S 50 /dev/hda
> /sbin/hdparm -c 1 -m 16 -d -X66 /dev/hdc
We do not do this kind of mucking around if you use chipset code.
Not all chipsets support reprograming of the interface with the hdparm
101 - 200 of 376 matches
Mail list logo
