Hello Jeff,
I tested vanilla test7 with ptrace() patch.
It breaks uml exactly like I see with any kernel test7.
Seems like the ORIG_EAX != -1 is needed to correctly restart syscall
after PTRACE_SYSCALL, but I did not check this codepath thoroughly.
Following what is going with uml, just for
Hello,all
I use kernel 2.4.0-test8.
When i load the dmascc module my monitor turn off(power save mode).
It works well in 2.2.17.
Any idea?
Regards,
Metod
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
On Tue, Sep 19, 2000 at 12:48:14PM -0700, Christoph Lameter wrote:
On Tue, 19 Sep 2000, Marko Kreen wrote:
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
Linus Torvalds writes:
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
Indeed, my copy of the SCSI 3 SPC-1
(ftp://ftp.t10.org/t10/drafts/spc/spc-r11a.pdf dated 21-Mar-1997) and SPC-2
(ftp://ftp.t10.org/t10/drafts/spc2/spc2r18.pdf dated 21-May-2000) show them
differently. SPC-3 isn't available for download.Anyone have the "final"
copy (if indeed it's not still
} On Tue, Sep 19, 2000 at 09:53:41PM +0200, [EMAIL PROTECTED] wrote:
}
}
}Linus,
}
} Where do architecture maintainers stand when they don't submit their
} problems to linux-kernel or the great Ted Bug List(tm)?
}
} Up against the wall so we can shoot them?
}
} :)
}
} So I
On Tue, 19 Sep 2000, Martin Mares wrote:
Anyway, can you send me your /proc/ioports and /proc/iomem, please?
Yes, sure:
-0009fbff : System RAM
0009fc00-0009 : reserved
000a-000b : Video RAM area
000c-000c7fff : Video ROM
000d-000d0fff : Extension ROM
On Tue, Sep 19, 2000 at 10:38:52PM +0200, Jens Axboe wrote:
I haven't had a chance to really look at Peter's mods yet, but surely
the current elevator can have many entries with 0 sequence. As an
example, say the start sequence is 3 and we received request sector
10...1 in descending order.
Jens Axboe [EMAIL PROTECTED] writes:
modification Peter suggested there can be more and we should track the one
more on the back of the queue. I don't think it's worthwhile.
Agree, I don't think the added complexity would be worth it.
So that leaves two choices:
1. Perfect elevator
Hi,
I too tested to stress the new VM
Quintelas mmap002 "deadlocks" for me.
PPro, 96 MB, UP
active: 22337 (I think this varies, have too lock a 2nd time)
inactive_dirty: 324 varies
inactive_clean: 0
free: 288
... 1x 512 = 512 kB
... 2 x 16 + 1 x 32 + 1 x 64 = 640 kB
My feeling when looking at
Daniel Grimwood [EMAIL PROTECTED] said:
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.
Random
Cort Dougan writes:
I've had to create a 2.5 for the PPC tree so we aren't stuck with either no
experimentation or experimentation in the stable trees.
Well, you're not alone. There's a lot going on in the ARM side of Linux
which looks very promising; yes it is true that ARM is not the
On Wed, 20 Sep 2000, Andi Kleen wrote:
This patch fixes an obvious bug introduced with the ext2 changes in 2.2.18pre
(look up the definition of le32_to_cpu on BE machines without a special
assembler version for it and on machines that have it)
Patch against 2.2.18pre9
Wrong fix.
Hi
while I am running mmap002 in test9-pre4 I got the computer
frozen, it don't answer to my open windows anymore, it answers
only to pings. I have got the attached traces. The machine
is SMP with IDE disks.
I had no additional/local patches applied.
On Tue, Sep 19 2000, Andrea Arcangeli wrote:
7[3] 8[2] 9[1] 10[0] 3[3] 4[2] 5[1] 6[0] 1[3] 2[2]
p
With point `p' I mean the request after last barrier in the queue.
Ah, I suspected we were talking past each other.
Then when we try to insert 99 it
On Tue, 19 Sep 2000, Matthias Andree wrote:
Do you have the chance to borrow another of those K6-2s, possibly faster
ones (if your board supports those)? Is the case in a proper state (has
never been dropped, all perpendicular and so on)?
A K6-2 500 has become available for me to try, won't
Hello.
I am trying to mmap a frame buffer device (which I wrote) and it
doesn't seem to work. I verified the address - it appears OK.
However, whatever I write out to the address from my userland program,
the bits appear to go into the bit bucket.
I am trying to figure out remap_page_range;
On Tue, 19 Sep 2000 19:53:19 +0200,
Jorge Nerin [EMAIL PROTECTED] wrote:
All the traces end up in stext_lock, so I think it' the same bug
EIP; c01df3aa stext_lock+32ba/7f30 =
Trace; c015db32 generic_make_request+ce/120
Trace; c015dd03 ll_rw_block+17f/1f4
Trace; c0136149
On Tue, 19 Sep 2000, Horst von Brand wrote:
Random crashes is usually a hardware problem: Bad RAM, overheated CPU,
overclocking, ...
Yeah it probably is a dud CPU, but I'm just trying to be optimistic. :)
I've tried two other CPUs and they work fine, so it's definitely the CPU
that's the
Keith,
I've seen a some problems with the way Linus (or whoever) did this. I
had a bug I worked on for 5 weeks related to the buggy 2.7 gcc linker on
Caldera Linux 2.4 that would for whatever reason fail to fixup all the
.test.lock code sections in a file (probably because there were so many
Hello,
You cannot use MMX registers in the kernel either, since the kernel doesen't
save and restore FX state (fxsave, fxrstor) either (just like
(fsave/frstor).
Best Wishes,
Lyle
** Reply to message from "Richard B. Johnson" [EMAIL PROTECTED] on
Tue,
19 Sep 2000 11:58:34 -0400 (EDT)
Tell
Hello,
I have a program that makes HTTP requests in a loop to a box runing Linux.
It goes through another Linux box, which is using proxy ARP and is connected
to the client and the web server using a cross over cable
[CLIENT][PROXY][WEBSERVER]
When the proxy machine uses 2.2 series
On Tue, Sep 19, 2000 at 09:52:15AM -0700, Richard Henderson wrote:
Instead of *= 0.5, try /= 2.0
Yes indeed you've found a bug in the kernel's FP emulation.
I'll see about fixing it.
Rather than fix the old udiv128 function, which was trying to do
128/128 bit division, I've pulled in a
[EMAIL PROTECTED] said:
I tested vanilla test7 with ptrace() patch. It breaks uml exactly
like I see with any kernel test7.
exec_user.c:29 ptrace(PTRACE_SYSCALL, 4901, 0, 0) = 0
And voila, we got SIGSEGV instead of happy running child:
Child 4901 exited with signal 11
Yuri, I apologize
to see 2.3.1xx like we did with 2.1. But the 2.2.0-testX patches seemed like
small stuff (maybe my memory just sucks tho).
I don't think there ever were any 2.2.0-testX patches - my recollection is
that we went from 2.1.1xx to 2.2.0-preX, with no -testX in between like we
seem to be having
On Sep 19, 10:35am, Eric Youngdale wrote:
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
On Tue, Sep 19, 2000 at 09:26:44PM -0700, Barry K. Nathan wrote:
to see 2.3.1xx like we did with 2.1. But the 2.2.0-testX patches seemed like
small stuff (maybe my memory just sucks tho).
I don't think there ever were any 2.2.0-testX patches - my recollection is
that we went from 2.1.1xx
Ok, it's time to get test9 running on my laptop, so I played the "what
code didn't get cut-n-pasted" game.
With the attached tested patch against 2.4.0-test9-pre4, CardBus is
working again for me. This patch makes the logic match that of the old
code.
Jeff
-
To unsubscribe from this
Jeff Garzik wrote:
With the attached tested patch against 2.4.0-test9-pre4, CardBus is
working again for me. This patch makes the logic match that of the old
code.
-ENOSLEEP. Here is the patch.
Index: drivers/pci/pci.c
===
RCS
Jeff Garzik writes:
Ok, it's time to get test9 running on my laptop, so I played the "what
code didn't get cut-n-pasted" game.
With the attached tested patch against 2.4.0-test9-pre4, CardBus is
working again for me. This patch makes the logic match that of the
old code.
What patch?
On Tue, Sep 19, 2000 at 09:36:30PM -0700, David Ford wrote:
Tom Rini wrote:
that. I see that 2.4 is getting all kinds of changes merged in
that should be going on with 2.5. The recent VM changes have left
us with deadlocks that we didn't have before. Shouldn't that have
- Linux developers often do horribly stupid things, and use 64-bit
division etc instead of using a simple shift. Again, not linking
against libgcc finds those things early rather than late, because the
horribly stupid things end up requireing libgcc support.
I would have thought
Hello,
On Tue, 19 Sep 2000, Chuck Lever wrote:
also, the test at issue here (from line 363 of kernel/signal.c):
/* If this was sent by a rt mechanism, try again. */
if (info-si_code != SI_USER) {
ret =
Bernd Eckenfels [EMAIL PROTECTED] wrote:
* file-change notification
this is interesting for other stuff too, i think irix has an interface for
that, i think its an ioctl?
Someone did a file-change notification patch for Linux. I'm not sure exactly
what became of it, but it'd be nice
Andrea Arcangeli wrote:
int * p;
[...]
spin_lock(lock);
a = *p;
spin_unlock(lock);
spin_lock(lock);
b = *p;
spin_unlock(lock);
[With "memory" clobber"] the [second] reload of the address of `p'
isn't necessary and gcc is wrong in
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
distribution
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 updated
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 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 tell
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 personal
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, 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
the
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
^^^
I see. So Jamie was right and we reproduced a case of miscompilation.
Umm ... "miscompilation"? As in the compiler produced the wrong code
based on the input provided?
int * p;
...
a = *p;
movl p,%eax
movl (%eax),%edx
The assembly code appears to load the address
"jamal" == jamal [EMAIL PROTECTED] writes:
jamal Packets in flight?
In the extreme case, there could still arrive up to the window
size frames.
jamal Assuming this depends on path latency and not some bad
jamal programming
Yes. Although the latter could also possible.
"jamal" == jamal [EMAIL PROTECTED] writes:
[...]
Nice introduction!
jamal The driver uses the feedback information to intelligently
jamal adjust its sending rate. (i.e reduce or increase calls to
jamal netif_rx() or send a congestion-experienced frame to its
jamal peer eg in
Date:Wed, 20 Sep 2000 00:50:06 +0200
From: "Andi Kleen" [EMAIL PROTECTED]
This patch fixes an obvious bug introduced with the ext2 changes in
2.2.18pre (look up the definition of le32_to_cpu on BE machines
without a special assembler version for it and on machines that
29:07 2000
@@ -13,31 +13,35 @@
* See asm-i386/byteorder.h and suches for examples of how to provide
* architecture-dependent optimized versions
*
+ * They shouldn't be macros, damnit. AV, 2919
+ *
*/
/* casts are necessary for constants, because we never know how for sure
* how U/
On Tue, Sep 19, 2000 at 07:13:31PM -0400, Alexander Viro wrote:
Nice spotting, but bad fix, IMO. swab...() stuff is a perfect example of
the dangerous use of macros. BTW, 2.4 has the same problem.
inlines usually generate worse code than macros (the gcc manual lies on that),
e.g. the register
Date:Tue, 19 Sep 2000 19:13:31 -0400 (EDT)
From: Alexander Viro [EMAIL PROTECTED]
Nice spotting, but bad fix, IMO. swab...() stuff is a perfect
example of the dangerous use of macros. BTW, 2.4 has the same
problem.
Would you mind taking a look at the difference in code
On Tue, 19 Sep 2000, David S. Miller wrote:
Would you mind taking a look at the difference in code output when
register pressure in a given function is moderate to high? :-)
Immaterial.
If somebody cares about performance, they'd just better create the proper
architecture-specific
On Tue, Sep 19, 2000 at 07:13:31PM -0400, Alexander Viro wrote:
+static inline __u16 ___swab16(__u16 x)
+{
+ return ((x (__u16)0x00ffU) 8) | ((x (__u16)0xff00U) 8);
+}
+static inline __u32 ___swab16(__u32 x)
^
+{
+ return ((x
On Wed, Sep 20, 2000 at 01:22:50AM +0200, Andi Kleen wrote:
Better would be to use statement blocks like
#define bla(x) ({ __u32 tmp__ = (x); ; tmp__; })
Agreed.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
On Wed, 20 Sep 2000, Andi Kleen wrote:
On Tue, Sep 19, 2000 at 07:13:31PM -0400, Alexander Viro wrote:
Nice spotting, but bad fix, IMO. swab...() stuff is a perfect example of
the dangerous use of macros. BTW, 2.4 has the same problem.
inlines usually generate worse code than macros
On Wed, 20 Sep 2000, Andrea Arcangeli wrote:
On Tue, Sep 19, 2000 at 07:13:31PM -0400, Alexander Viro wrote:
+static inline __u16 ___swab16(__u16 x)
+{
+ return ((x (__u16)0x00ffU) 8) | ((x (__u16)0xff00U) 8);
+}
+static inline __u32 ___swab16(__u32 x)
Date:Tue, 19 Sep 2000 16:49:00 -0600
From: Cort Dougan [EMAIL PROTECTED]
If anyone else wants access to the 2.5 tree we have as a place to
keep experimental changes I'm happy to open it up to the outside.
Well, let's first step back for a second and really think about
what
On Tue, 19 Sep 2000, Andrew Morton 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
...
This is good. It would be useful to have this in place ASAP so driver
authors have something to look at and
Date: Wed, 20 Sep 2000 03:51:37 +0200
From: "Andi Kleen" [EMAIL PROTECTED]
Receiver side SMP reordering is still there, but I'm not sure if it is
fixable (but it'll surely hit people that cannot use Linux senders, I
just see the reports)
Reordering is a
}Date: Tue, 19 Sep 2000 16:49:00 -0600
}From: Cort Dougan [EMAIL PROTECTED]
}
}If anyone else wants access to the 2.5 tree we have as a place to
}keep experimental changes I'm happy to open it up to the outside.
}
} Well, let's first step back for a second and really think
On Wed, Sep 20, 2000 at 01:58:32AM +0200, Martin Dalecki wrote:
Not agreed. In this case older version of GCC will have
almost exactly the same provlems as with functions.
I guess the object was to remove the mistake-prone side effects anyway...
Andrea
-
To unsubscribe from this list: send
On Wed, Sep 20, 2000 at 01:55:58AM +0200, Martin Dalecki wrote:
The GCC manual doesn't lie on that ANY LONGER with respect to EGCS.
And we should adpat for the modern versions of the compiler instead
of dragging the *ugly* code with us until the earth stops spinning, iff
the only concern is
On Wed, Sep 20, 2000 at 01:58:32AM +0200, Martin Dalecki wrote:
Andrea Arcangeli wrote:
On Wed, Sep 20, 2000 at 01:22:50AM +0200, Andi Kleen wrote:
Better would be to use statement blocks like
#define bla(x) ({ __u32 tmp__ = (x); ; tmp__; })
Agreed.
Not agreed. In this
Date: Tue, 19 Sep 2000 18:07:20 -0600
From: Cort Dougan [EMAIL PROTECTED]
Do you really think that's forcing people to concentrate of fixing
bugs? Tell me if you disagree, I'd like to understand how you see
that. I see that 2.4 is getting all kinds of changes merged in
that
Date:Tue, 19 Sep 2000 13:59:53 +0200
From: Florian Lohoff [EMAIL PROTECTED]
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
Andrea Arcangeli wrote:
On Wed, Sep 20, 2000 at 01:22:50AM +0200, Andi Kleen wrote:
Better would be to use statement blocks like
#define bla(x) ({ __u32 tmp__ = (x); ; tmp__; })
Agreed.
Not agreed. In this case older version of GCC will have
almost exactly the same provlems as with
On Tue, Sep 19, 2000 at 05:14:39PM -0700, David S. Miller wrote:
And hey, guess what, as a result of this right now my "non-driver
caused" core/ipv4/ipv6 networking bug list is pretty much empty right
now. Only a few netfilter glitches appear to remain.
Some items for your list:
The ipid
On Tue, Sep 19, 2000 at 06:13:38PM -0700, David S. Miller wrote:
Date: Wed, 20 Sep 2000 03:14:10 +0200
From: "Andi Kleen" [EMAIL PROTECTED]
The ipid handling is still fishy, it will break when you talk to
more destinations than the inetpeer cache can take (I fixed it in
my
Date: Wed, 20 Sep 2000 01:58:32 +0200
From: Martin Dalecki [EMAIL PROTECTED]
Andrea Arcangeli wrote:
Agreed.
Not agreed. In this case older version of GCC will have
almost exactly the same provlems as with functions.
Care to show an example? I do not believe this is true.
Date:Tue, 19 Sep 2000 19:44:30 -0600
From: "Jeff V. Merkey" [EMAIL PROTECTED]
It does not seem to be saving any memory space doing it this way,
since I've noticed tons of these little segments all over the
place.
None of them can be eliminated because each one branches
Dave,
I did a
rpm -rebuild egcs
rpm -rebuild glibc
ldconfig
ldconfig
and it went away.
I reinstalled a clean Open Linux 2.4 and just did
ldconfig
ldconfig
without rebuilding and it went also went away, so I don't think rebuilding
had much to do with it. I did spend any time looking further
On Wed, 20 Sep 2000, Henner Eisen wrote:
[some suggestions for the next re-incarnation of the doc deleted]
jamal I have experimented with two schemes: one which samples the
jamal queue via a timer and one which does it per-packet and
jamal found that the per-packet sampler
On Tue, Sep 19, 2000 at 06:54:30PM -0700, David S. Miller wrote:
Date: Wed, 20 Sep 2000 03:51:37 +0200
From: "Andi Kleen" [EMAIL PROTECTED]
Receiver side SMP reordering is still there, but I'm not sure if it is
fixable (but it'll surely hit people that cannot use Linux
On Tue, Sep 19, 2000 at 05:14:39PM -0700, David S. Miller wrote:
Date: Tue, 19 Sep 2000 18:07:20 -0600
From: Cort Dougan [EMAIL PROTECTED]
Do you really think that's forcing people to concentrate of fixing
bugs? Tell me if you disagree, I'd like to understand how you see
On Tue, Sep 19, 2000 at 04:11:30PM -0700, David S. Miller wrote:
Unfortunately, gcc does not make inline functions as cheap as "macros
with type checking". There are extra costs and often the register
allocator cannot cope and stuff starts getting spilled to the stack.
It is supposedly on
Date:Wed, 20 Sep 2000 04:38:24 +0200
From: "Andi Kleen" [EMAIL PROTECTED]
We must be talking about different things. It of course detects it
on ACK input, but only for data it did send itself. Every TCP detects
reordering automatically on the input with the sequence
Date:Tue, 19 Sep 2000 19:23:42 -0700
From: Richard Henderson [EMAIL PROTECTED]
Rather than fix the old udiv128 function, which was trying to do
128/128 bit division, I've pulled in a subroutine from libgcc that
does 128/64 bit division, which is all we need here.
So it
301 - 376 of 376 matches
Mail list logo
