Hi Linus, Alan,
the following (trivial) patch fixes drop-behind behaviour
in generic_file_write to only drop fully written pages.
This increases performance in dbench by about 8% (as
measured by Daniel Phillips) and should get rid of the
logfile bottleneck Ingo Molnar found with the drop-behind
On Wed, 3 Jan 2001, Daniel Phillips wrote:
> Mike Galbraith wrote:
> >
> > On Wed, 3 Jan 2001, Daniel Phillips wrote:
> >
> > > Could you try this patch just to see what happens? It uses semaphores
> > > for the bdflush synchronization instead of banging directly on the task
> > > wait queues.
Hi Linus, Alan, Mike,
the following patch sets PF_MEMALLOC for the current task
in __alloc_pages() to avoid infinite recursion when we try
to free memory from __alloc_pages().
Please apply the patch below, which fixes this (embarrasing)
bug...
regards,
Rik
--
Hollywood goes for world dumbinati
1. Kernel oopses after cronjob starts
2. I recently noticed that my maschine crashes exactly on cronjob times.
It seems to me that it is mainly caused (because it happened 2 times at 4 o clock) by
the mandrake security scripts i installed (msec-0.9-14mdk) - after some network failure
(eg router
This kernel
VERSION = 2
PATCHLEVEL = 4
SUBLEVEL = 0
EXTRAVERSION = -test12
Sometimes locks solid (alt-sysrq doesn't work), sometimes less so (alt-sysrq
does work) but more often reboots when a user (me with my usual account, me
with an alternate little-user account) logs in and starts XFree, o
On Wed, 3 Jan 2001, Rik van Riel wrote:
> the following (trivial) patch fixes drop-behind behaviour
> in generic_file_write to only drop fully written pages.
OK, please ignore. It is already in prerelease-diff
in the testing/ directory .. ;)
regards,
Rik
--
Hollywood goes for world dumbinatio
On Wed, 3 Jan 2001, Dr. David Gilbert wrote:
> I got wondering as to whether the various journaling file
> system activities were designed to survive the occasional
> unclean shutdown or were designed to allow the user to just pull
> the plug as a regular means of shutting down.
> Thoughts?
On Wed, Jan 03, 2001 at 01:50:46PM +0100, Geert Uytterhoeven wrote:
> On Tue, 2 Jan 2001, Tom Rini wrote:
> > Hey all. While going through the 2.4 tree and removing dead CONFIG_xxx's for
> > PPC stuff, I noticed clgenfb still had CONFIG_PREP stuff (which may have
> > partily explained why it no l
On Wed, 03 Jan 2001, Rik van Riel wrote:
> Hi Linus, Alan,
>
> the following (trivial) patch fixes drop-behind behaviour
> in generic_file_write to only drop fully written pages.
>
> This increases performance in dbench by about 8% (as
> measured by Daniel Phillips) and should get rid of the
> l
> On Wed, 3 Jan 2001, Dr. David Gilbert wrote:
>
> > I got wondering as to whether the various journaling file
> > system activities were designed to survive the occasional
> > unclean shutdown or were designed to allow the user to just pull
> > the plug as a regular means of shutting down.
>
I had the same problem on my machine, I solved unloading agpgart and drm
(r128.o for me, cause I have a Rage 128 video card), I think there's a bug
into the XFree drm support, but when I post the problem I received no reply.
P.
On Wed, 3 Jan 2001, John Summerfield wrote:
>
> This kernel
> VERS
On Wed, 3 Jan 2001 [EMAIL PROTECTED] wrote:
> (Ordinarily a key-up event gets scancode of key-down but with
> high-order bit set. In scancode set 1, a key-up event get the
> scancode of key-down prefixed by 0xf0. Since the high-order bit
> is masked here, this 0xf0 would show up as 0x70.
> Moreov
On Wed, 3 Jan 2001, Daniel Phillips wrote:
> Mike Galbraith wrote:
> > Semaphore timed out during boot, leaving bdflush as zombie.
>
> Wait a sec, what do you mean by 'semaphore timed out'? These should
> wait patiently forever.
IKD has a semaphore deadlock detector. Any place you take a sema
Two small fixes:
- fix the comments in include/linux/delay.h
- someone changed the actual calculation for s390 (added /HZ), but forgot to
replace loops_per_sec by loops_per_jiffy
--- linux-2.4.0-prerelease-ac4/include/linux/delay.hMon Jan 1 23:30:23 2001
+++ test/linux-merge20-2.4.0
Mike Galbraith wrote:
>
> On Wed, 3 Jan 2001, Daniel Phillips wrote:
>
> > Mike Galbraith wrote:
> > > Semaphore timed out during boot, leaving bdflush as zombie.
> >
> > Wait a sec, what do you mean by 'semaphore timed out'? These should
> > wait patiently forever.
>
> IKD has a semaphore dea
On Tue, 2 Jan 2001, Kai Germaschewski wrote:
> I think the problem was that we relied on divert_if being initialized to
> zero automatically, which didn't happen because it was not declared static
> and therefore not in .bss (*is this true?*).
This is true in this particular case, and your added
On Wed, 3 Jan 2001, Stephen C. Tweedie wrote:
> Having preallocated blocks allocated immediately is deliberate:
> directories grow slowly and remain closed most of the time, so the
> normal preallocation regime of only preallocating open files and
> discarding preallocation on close just doesn'
Hello.
Some time ago, Vojtech Pavlik sent a message stating that he had found
a critical bug in some VIA chipsets, and suggested a patch.
The bug would "cause X to blank the screen when it should not, squid
to terminate connections with a 'timeout' randomly and other nice
effects."
The problem
Hi,
why in sock_alloc_send_skb(sk,
length+hh_len+15,0,flags&MSG_DONTWAIT, &err)
15 is added to the length of the the data of the socket. Here
length=data_len+ip_hdr+udp_hdr all we need is hrd_hdr ie hh_len which is
being added here, why that 15 is needed?
Sourav
-
To u
On Wed, Jan 03, 2001 at 01:26:18PM -0200, Rik van Riel wrote:
> On Wed, 3 Jan 2001, Dr. David Gilbert wrote:
>
> > I got wondering as to whether the various journaling file
> > system activities were designed to survive the occasional
> > unclean shutdown or were designed to allow the user to j
Mike / Mark,
Thank-you very much for your replies.
With regard to Mike, (a) I am using a PIII 800, so I really should be seeing better
results than your Celeron. It seems, therefore, that my setup may be defective in
more fundamental ways than I had imagined. (b) I do appreciate that I may n
Hello all. I've recently been playing with modules on my PPC system, and
noticed that matroxfb doesn't work as a module, because of mac_vmode_to_par.
But, after looking at other drivers which did work (aty and aty128) I noticed
matroxfb was doing something it didn't need to be doing.
First, the c
Rik van Riel wrote:
>
> On Wed, 3 Jan 2001, Dr. David Gilbert wrote:
>
> > I got wondering as to whether the various journaling file
> > system activities were designed to survive the occasional
> > unclean shutdown or were designed to allow the user to just pull
> > the plug as a regular mean
All,
I installed 2.4.0 prerelease and the problem I was seeing
w/ kernel: "seemingly random characters" went away. So it would
appear that this is a 2.2 problem only.
One thing I noticed in going to 2.4 was that my sound card
initialization/parameters were/are not ava
Hi guys,
Just noticed the filemap_fdatasync code doesn't check the return value from
writepage. Linus, would you take a patch that redirtied the page, puts it
back onto the dirty list (at the tail), and unlocks the page when writepage
returns 1?
That would loop forever if the writepage func ke
On Wed, 3 Jan 2001, Daniel Phillips wrote:
> I don't doubt that if the 'power switch' method of shutdown becomes
> popular we will discover some applications that have windows where they
> can be hurt by sudden shutdown, even will full filesystem data state
> being preserved. Such applications a
I run 'swapoff -a' in the middle of 'make j10 bzImage'
with 32M (by lilo) and got this:
Jan 3 17:30:07 lenstra kernel: VM: Undead swap entry 000f3100
Jan 3 17:30:07 lenstra kernel: VM: Bad swap entry 000f3100
Jan 3 17:30:07 lenstra kernel: VM: Bad swap entry 000f3100
Jan 3 17:30:07 lenstra k
Chris Mason wrote:
>
> Hi guys,
>
> Just noticed the filemap_fdatasync code doesn't check the return value from
> writepage. Linus, would you take a patch that redirtied the page, puts it
> back onto the dirty list (at the tail), and unlocks the page when writepage
> returns 1?
It would be a l
Hi all,
just a small question. The pre13-x.diff.gz patches vanished
from ftp.xx.kernel.org. I need pre13-5 and pre13-6 (and later,
if there where any).
They have not been moved to testing/old or something, hopefully
they're not lost ?
cheers,
Patrick
-
To unsubscribe from this list: send the li
>> It looks like scancode mode 1
> It looks like untranslated mode 2
Yes, that gives the same codes.
(But you are right, this point of view gives a few more possibilities
to get into this state.)
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
Al, you write:
> Folks, there is a pretty strange detail of the allocation policy -
> if cylinder group has no free blocks past the goal ext2 tries very hard to
> avoid allocation in the beginning of the group. I.e. order looks so:
>
> * goal
> * goal .. (goal+63) & ~63
>
Chris, you write:
> I'm seeing a new warning with the 2.4.0-prerelease (could have been
> introduced in -pre11 or 12):
>
> EXT2-fs warning: feature flags set on rev 0 fs, running e2fsck is recommended
>
> Well I've run e2fsck (version 1.18) twice, and looked at the options for
> tune2fs.
The fe
SS U1, RH 6.2 + updates
depmod: *** Unresolved symbols in /lib/modules/2.2.19pre5/fs/binfmt_elf.o
depmod: get_pte_slow
depmod: get_pmd_slow
depmod: pgt_quicklists
--
Dr. Horst H. von Brand mailto:[EMAIL PROTECTED]
Departamento de Informatica
Hi,
In the function ip_build_xmit(), immediately after
sk_alloc_send_skb(), skb_reserve(skb, hh_len) is called. Now
skb_reserve(skb,len) only increment the data pointer and tail pointer by
len amt.
Now in a particular hard_start_xmit() say for rtl8139, the data
transfer is takin
On 3 Jan 01 at 13:08, Udo A. Steinberg wrote:
> Alexander Viro wrote:
> >
> > In principle, it might be that d_find_alias() is broken. I don't see where
> > it could happen, but then I'm half-asleep right now... While we are at it,
> > do you have
>
> > * autofs
>
> Yes.
>
> >
I have been torturing a couple of boxes and came up with these benchmark
results. I have also enclosed the script used to do the benchmark, and I
am well aware that this is a very specialized benchmark, testing only
limited parts of the kernel, and so on, BUT I am convinced that I'm seeing
someth
On Wed, Jan 03, 2001 at 10:59:48PM +0530, Sourav Sen wrote:
>
> Hi,
> In the function ip_build_xmit(), immediately after
> sk_alloc_send_skb(), skb_reserve(skb, hh_len) is called. Now
> skb_reserve(skb,len) only increment the data pointer and tail pointer by
> len amt.
>
> Now in a
Good day, all,
This is just meant as an informational message, not a complaint.
Ted, could you note that this still exists on 2.4.0-test13-pre7 in the
todo page? Many thanks.
[1.] One line summary of the problem:
Loopback filesystem writes still hang on 2.4.0-test13-pre7.
[2.] F
Tobias Ringstrom wrote:
> 3) The 2.2 kernels outperform the 2.4 kernels for few clients (see
>especially the "dbench 1" numbers for the PII-128M. Oops!
I noticed that too. Furthermore I noticed that the results of the more
heavily loaded tests on the whole 2.4.0 series tend to be highly
var
Kernel Version: 2.4.0-test11 - 2.4.0-prerelease
Platform: ix86 (PIII)
Problem Hardware: Kodac DC280, firmware 1.01
Ever since test10 or after, removing my dc280 from the usb
bus causes khubd to crash. I have tried both UHCI drivers
and they produce the same effect.
dmesg, syslog, messages, an
2.2.19pre6
o Yamaha PCI sound updates(Pete Zaitcev)
o Alpha SMP ASN reuse races (Andrea Arcangeli)
o Alpha bottom half SMP race fixes(Andrea Arcangeli)
o Alpha SMP read_unloc race fix (Andrea A
On Wed, 3 Jan 2001, Chris Mason wrote:
>
> Just noticed the filemap_fdatasync code doesn't check the return value from
> writepage. Linus, would you take a patch that redirtied the page, puts it
> back onto the dirty list (at the tail), and unlocks the page when writepage
> returns 1?
I don't
On 3 Jan 01 at 10:54, Tom Rini wrote:
> I agree this sounds good. I just think it's too late to do it now. :)
>
> The vmode/cmode/vesa number stuff should stick around in 2.4 (it's too late
> now to remove it) but documented as obsolete, and removed in 2.5.
I personally prefer 'video=matrox:ve
On Wed, 3 Jan 2001, Tom Rini wrote:
> Third, the nvram_read_byte needs to be protected by CONFIG_NVRAM.
I'd really like to move the nvram part to mac_fb_find_mode() in macmodes.c, so
it will work automagically for all drivers on PowerMac.
I'd also like to remove the `vmode' and `cmode' `video='
On Wed, Jan 03, 2001 at 06:44:59PM +0100, Geert Uytterhoeven wrote:
> On Wed, 3 Jan 2001, Tom Rini wrote:
> > Third, the nvram_read_byte needs to be protected by CONFIG_NVRAM.
>
> I'd really like to move the nvram part to mac_fb_find_mode() in macmodes.c, so
> it will work automagically for all d
Hello,
When trying to print to an off-line printer with 2.4 kernels, the
"write" system call to /dev/lp0 stalls for 10 seconds and then returns
EIO. This has the unfortunate effect that the printout will be lost,
because the redhat print filters (in rh7) use "cat" to send data to
the printer dev
Alan,
I have linux 2.2.19pre5 on a UMSDOS based Dell Optiplex Gx1 using
libc5 v2.0.7. Below is my "lsmod" of all modules loaded.
Note: the cpuid module when it isn'tloaded and oopsing the kernel is
fixed now. However, I found a new problem in /proc.
A). Problem: If you "cat /proc/sys/net/
On Wed, 3 Jan 2001, Daniel Phillips wrote:
> Tux2 is explicitly designed to legitimize pulling the plug as a valid
> way of shutting down.
Hmm - that IMHO is a good thing; I'll have to look at Tux2.
> Metadata-only journalling filesystems are not
> designed to be used this way, and even with f
Hi,
I rediffed this trivial patch by Andrea (that went
into 2.2.19-pre5) which adds 2nd chance replacement
to the dentry cache, this should make our dcache
behave a little bit better than the current FIFO.
I know this probably isn't of any help under very low
and very high loads, but it should p
On Wed, 3 Jan 2001, Rik van Riel wrote:
>
> I rediffed this trivial patch by Andrea (that went
> into 2.2.19-pre5) which adds 2nd chance replacement
> to the dentry cache, this should make our dcache
> behave a little bit better than the current FIFO.
Looks ok, but I'd be happier if the
On Wednesday, January 03, 2001 10:28:05 AM -0800 Linus Torvalds
<[EMAIL PROTECTED]> wrote:
> On Wed, 3 Jan 2001, Chris Mason wrote:
>>
>> Just noticed the filemap_fdatasync code doesn't check the return value
>> from writepage. Linus, would you take a patch that redirtied the page,
>> puts i
On Wed, 3 Jan 2001, Linus Torvalds wrote:
> On Wed, 3 Jan 2001, Rik van Riel wrote:
> >
> > I rediffed this trivial patch by Andrea (that went
> > into 2.2.19-pre5) which adds 2nd chance replacement
> > to the dentry cache, this should make our dcache
> > behave a little bit better than the curre
On Wed, Jan 03, 2001 at 07:44:19PM +0100, Peter Osterlund wrote:
> Is there a better way to fix this problem?
It looks the simpler fix to me (main loop needs someway to handle errors
anyways) but ask Tim too.
Another way to fix it is to loop in interruptible mode inside lp_error waiting
the erro
gcc2.96 + prerelease BUG at inode.c:372
I've compiled by mistake the kernel with the wrong compiler: gcc 2.96
(RedHat 7.0 without the upgrade to gcc 2.96-69)
->1: The sound module for my mad16 based card plays the bytes swapped
(the same module recompiled with egcs-2.91.66 works fine).
->2
Kai Germaschewski <[EMAIL PROTECTED]> writes:
> On Tue, 2 Jan 2001, Gerold Jury wrote:
>
> > I have reversed the patches part by part, the only thing that makes a
> > difference is the diversion services.
> > The reason for this remains unknown for me.
>
> I think I found it. Could everybody wh
Hi,
Looks like dc2xx.c shouldn't use __devinit/__devexit
[patch attached]
or you should enable CONFIG_HOTPLUG under General Setup.
David?
The ov511 (usb) driver is the only other USB device driver
that uses __devinit/__devexit.
~Randy
josh wrote:
>
> Kernel Version: 2.4.0-test11 - 2.4.0-prer
I have created the shm directory in /dev
drwxrwxrwt 1 root root0 Jan 3 09:51 shm/
in my fstab i have:
shmfs /dev/shm shm defaults 0 0
when I display with top:
Mem:62496K av, 61248K used,1248K free, 0K shrd,1868K
buff
Swap: 64252K av, 20016K used,
On Wed, 3 Jan 2001, Daniel Phillips wrote:
> Tobias Ringstrom wrote:
> > 3) The 2.2 kernels outperform the 2.4 kernels for few clients (see
> >especially the "dbench 1" numbers for the PII-128M. Oops!
>
> I noticed that too. Furthermore I noticed that the results of the more
> heavily load
2.4.0prerelease-ac5
o Resync with Linus prepatch in testing
o Fix loops per jiffy oddments(Geert Uytterhoeven)
o Fixed lost video patch in -ac (Geert Uytterhoeven)
o One liner microcode driver fix (Tigran Aivazian)
o
On Wed, Jan 03, 2001 at 04:59:16PM -0200, Rik van Riel wrote:
> I know this probably isn't of any help under very low
> and very high loads, but it should provide a nice
> improvement under medium loads...
It should provide an improvement under high VFS load (lots of files lookedup
and not kept r
Craig Schlenter <[EMAIL PROTECTED]> writes:
> [snip, vmstat stuff, me]
> > There is a perl program running (80 Meg's in size, 20 Megs
> > resident) that is chatting to a database and building up a large
> > hash in memory. The machine has 64M of RAM. The bit that doesn't
> > make sense is why the
Hello!
The iprofd contained in isdnutils 3.0 use the same buffer and buffer size
in GETting and SETting via IOCTL IIOC[GS]ETPRF the virtual modem profiles.
The kernel use different sizes, so iprofd set incorrect data, resulting in a
hang of the ttyI from 1 to last. I suppose the right way to imp
Diego Liziero wrote:
> ->2: after two day under heavy load I've got the following BUG:
> (I don't know if it's related to the compiler, that's why I'm reporting
> this.)
>
> kernel BUG at inode.c:372!
It's a known bug. A fix is in process and may already be available at
ftp://ftp.kern
Shawn Starr <[EMAIL PROTECTED]> writes:
> [spstarr@coredump /etc]$ free
> total used free sharedbuffers
> cached
> Mem: 62496 61264 1232 0 1248
> 28848
>
>
> There's no shared memory being used?
[...]
> the shmfs is mounted. I
>> [spstarr@coredump /etc]$ free
>> total used free sharedbuffers
...
>> the shmfs is mounted. Is there any configuration i need to get
>> shm memory activiated?
>
> The 'shared' field in /proc/meminfo (source for 'top' and 'free')
> has nothing to do with {SysV,PO
ahh ok, so everythings fine then. It would be nice though to see that
value perhaps in future they'll be a way.
Thanks,
Shawn.
Doug McNaught wrote:
> Shawn Starr <[EMAIL PROTECTED]> writes:
>
> > [spstarr@coredump /etc]$ free
> > total used free sharedbuffers
>
On Wed, 3 Jan 2001, Andrea Arcangeli wrote:
> On Wed, Jan 03, 2001 at 04:59:16PM -0200, Rik van Riel wrote:
> > I know this probably isn't of any help under very low
> > and very high loads, but it should provide a nice
> > improvement under medium loads...
>
> It should provide an improvement un
On 2001.01.03 Alan Cox wrote:
>
> 2.2.19pre6
> o Yamaha PCI sound updates(Pete Zaitcev)
> o Alpha SMP ASN reuse races (Andrea Arcangeli)
> o Alpha bottom half SMP race fixes(Andrea Arcangeli)
> o Alpha SMP read_unloc r
Andrea Arcangeli <[EMAIL PROTECTED]> writes:
> On Wed, Jan 03, 2001 at 07:44:19PM +0100, Peter Osterlund wrote:
> > Is there a better way to fix this problem?
>
> It looks the simpler fix to me (main loop needs someway to handle errors
> anyways) but ask Tim too.
>
> Another way to fix it is to
I'm experiencing some kind of memory leaks playing with ioremap and iounmap,
and I've narrowed down the problem to iounmap refusing to unmap the memory that
I just mapped. The line of code in question is
if (!PageReserved(page) && atomic_dec_and_test(&page->count)) {
from page_alloc.c (
The sis5513 has for quite a while had fatal problems with udma on some
machines. (At least the thelinuxstore PIAs with the P6SET-ML
motherboard, I have heard other people with the same problem).
The sis5513 driver deliberatly overrides the CONFIG_IDEDMA_AUTO and
the BIOS settings that might disa
On Wed, Jan 03, 2001 at 05:47:39PM -0200, Rik van Riel wrote:
> Not really. Under very high VFS loads we'd just scan
> through the list twice and free the entries anyway.
You're obviously wrong.
The higher was the load, the faster your working set was getting dropped from
the dcache. (with the p
It is known that most remote exploits use the fact that stacks are
executable (in i386, at least).
On Linux, they use INT 80 system calls to execute functions in the kernel
as root, when the stack is smashed as a result of a buffer overflow bug in
various server software.
This preliminary, smal
On Wed, Jan 03, 2001 at 10:00:59PM +0100, Peter Osterlund wrote:
> off. Apparently the printer tells the computer it is OK to send data
> to it when it is off.
So then parport_write is probably buggy because it's losing data silenty while
the printer is off. So the below is probably a band aid.
Dan Aloni wrote:
>
> It is known that most remote exploits use the fact that stacks are
> executable (in i386, at least).
>
> On Linux, they use INT 80 system calls to execute functions in the kernel
> as root, when the stack is smashed as a result of a buffer overflow bug in
> various server so
My 2.4.0-prerelease freezes solid on certain serial port events. The
ones I have seen (and are both repeatable) are when powering off the
modem and powering it on causes the system to hang solid. Also if an
incoming call is received on the telephone, the system hangs ( I
assume that this is when t
On Wed, Jan 03, 2001 at 03:07:03PM -0600, Timur Tabi wrote:
> I'm experiencing some kind of memory leaks playing with ioremap and iounmap,
> and I've narrowed down the problem to iounmap refusing to unmap the memory that
> I just mapped. The line of code in question is
>
> if (!PageReserve
On Wed, 3 Jan 2001, Dan Aloni wrote:
> It is known that most remote exploits use the fact that stacks are
> executable (in i386, at least).
>
> On Linux, they use INT 80 system calls to execute functions in the kernel
> as root, when the stack is smashed as a result of a buffer overflow bug in
I hope these are right fixes...
--
marko
diff -urNX /home/marko/misc/diff-exclude linux-2.4.0-prerelease/drivers/video/atyfb.c
linux/drivers/video/atyfb.c
--- linux-2.4.0-prerelease/drivers/video/atyfb.cWed Jan 3 19:55:56 2001
+++ linux/drivers/video/atyfb.c Wed Jan 3 22:42:32 2001
On Wed, Jan 03, 2001 at 11:13:31PM +0200, Dan Aloni wrote:
> It is known that most remote exploits use the fact that stacks are
> executable (in i386, at least).
>
> On Linux, they use INT 80 system calls to execute functions in the kernel
> as root, when the stack is smashed as a result of a buf
** Reply to message from Andrea Arcangeli <[EMAIL PROTECTED]> on Wed, 3 Jan 2001
22:55:05 +0100
> > from page_alloc.c (this is 2.2.18pre15). It appears that page->count is
> > already zero when this code is executed, and after it's executed, page->count
> > becomes -1 (or more accurately, 0xFFF
On Tue, 02 Jan 2001, Alan Cox wrote:
> The TSC one is fairly sane, the CMOS gets messy because host and CMOS time
> are not always the same
The idea is to read out the CMOS clock before and after polling the
BIOS, hoping that the BIOS would not tamper with the CMOS time. However,
thinking more e
On Wed, Jan 03, 2001 at 03:10:39PM -0600, Jim Studt wrote:
> The sis5513 has for quite a while had fatal problems with udma on some
> machines. (At least the thelinuxstore PIAs with the P6SET-ML
> motherboard, I have heard other people with the same problem).
>
> The sis5513 driver deliberatly o
On Wed, 3 Jan 2001, Alexander Viro wrote:
> > This preliminary, small patch prevents execution of system calls which
> > were executed from a writable segment. It was tested and seems to work,
> > without breaking anything. It also reports of such calls by using printk.
>
> Get real. Attacker ca
On Wed, Jan 03, 2001 at 04:54:38PM -0500, Alexander Viro wrote:
> On Wed, 3 Jan 2001, Dan Aloni wrote:
>
> > It is known that most remote exploits use the fact that stacks are
> > executable (in i386, at least).
> >
> > On Linux, they use INT 80 system calls to execute functions in the kernel
>
On 3 Jan 2001, Eric W. Biederman wrote:
> Kai Germaschewski <[EMAIL PROTECTED]> writes:
>
> > I think the problem was that we relied on divert_if being initialized to
> > zero automatically, which didn't happen because it was not declared static
> > and therefore not in .bss (*is this true?*).
>
On Wed, 3 Jan 2001, Andrea Baldoni wrote:
> The iprofd contained in isdnutils 3.0 use the same buffer and buffer size
> in GETting and SETting via IOCTL IIOC[GS]ETPRF the virtual modem profiles.
>
> The kernel use different sizes, so iprofd set incorrect data, resulting in a
> hang of the ttyI fr
On Wed, 3 Jan 2001, Alexander Viro wrote:
> On Wed, 3 Jan 2001, Dan Aloni wrote:
> > without breaking anything. It also reports of such calls by using printk.
> Get real.
Why do you always have to be insulting alex? Sheesh.
-Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-
On Wed, 3 Jan 2001, Dan Aloni wrote:
>
> This preliminary, small patch prevents execution of system calls which
> were executed from a writable segment. It was tested and seems to work,
> without breaking anything. It also reports of such calls by using printk.
>
Hum,
Allow-me to give you thi
On Wed, 3 Jan 2001, Brian Gerst wrote:
> Dan Aloni wrote:
> >
> > It is known that most remote exploits use the fact that stacks are
> > executable (in i386, at least).
> >
> > On Linux, they use INT 80 system calls to execute functions in the kernel
> > as root, when the stack is smashed as a
Dan Hollis <[EMAIL PROTECTED]> writes:
> On Wed, 3 Jan 2001, Alexander Viro wrote:
> > On Wed, 3 Jan 2001, Dan Aloni wrote:
> > > without breaking anything. It also reports of such calls by using printk.
> > Get real.
>
> Why do you always have to be insulting alex? Sheesh.
I was thinking it's
[EMAIL PROTECTED] said:
> This preliminary, small patch prevents execution of system calls which
> were executed from a writable segment. It was tested and seems to
> work, without breaking anything. It also reports of such calls by
> using printk.
Have you tried running UML on this kernel?
On Thu, 4 Jan 2001, Dan Aloni wrote:
> On Wed, 3 Jan 2001, Alexander Viro wrote:
>
> > > This preliminary, small patch prevents execution of system calls which
> > > were executed from a writable segment. It was tested and seems to work,
> > > without breaking anything. It also reports of such
> I get the following errors during the final linking of 2.4.0-prerelease
> on a Sparc IPX (sun4c). .config available upon request.
sun4c is badly broken at the moment for other reasons. However the problems
you are seeing should be fixed in cvs.
Anton
-
To unsubscribe from this list: send the
Hi all,
Having just started playing with IrDA on my dual celeron (Abit "APIC
error..." BP6), I managed to kill it every single time (NMI watchdog
in handle_IRQ_event) while connecting to my mobile phone (in fact,
when closing the connection to the phone. even 'cat /dev/ircomm0' will
do...). This
On Wed, 3 Jan 2001, Dan Aloni wrote:
> +
> +void print_bad_syscall(struct task_struct *task)
> +{
> + printk("process %s (%d) tried to syscall from an executable segment!\n",
>task->comm, task->pid);
> +}
Hmm, should be "writable segment", perhaps ;-)
--
Dan Aloni
[EMAIL PROTECTED]
-
To
[1.] System crash killing idle task
[2.] I returned home after 8 hours of disuse to find the system crashed
with various jibberish on the screen. As I could get no response, I could
not copy all of the information I saw, but wrote down the final lines
after the screenfull of jibberish:
Code: 89
I ran dbench 48 four times in succession for the following
recent kernels. It looks like there may be a slight drop
in performance for -ac5. For -ac4 and -ac5, the throughput
dropped on run #3. That's probably just a fluke. I'll repeat
these runs later when I get a chance.
This was performed
On Wed, 3 Jan 2001, Dan Hollis wrote:
> On Wed, 3 Jan 2001, Alexander Viro wrote:
> > On Wed, 3 Jan 2001, Dan Aloni wrote:
> > > without breaking anything. It also reports of such calls by using printk.
> > Get real.
>
> Why do you always have to be insulting alex? Sheesh.
Sigh... Not intende
Kai Germaschewski writes:
> The patch is right, the explanation was wrong. Sorry, I didn't CC l-k when
> I found what was really going on. Other source files used a global
> initialized variable "divert_if" as well, so this became the same one as
> the one referenced in isdn_common.c. That's why
101 - 200 of 246 matches
Mail list logo
