Hi,
why in sock_alloc_send_skb(sk,
length+hh_len+15,0,flags_DONTWAIT, )
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
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
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
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
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
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
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
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
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
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
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
>> 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
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
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
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.]
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
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,
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
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
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
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
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
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
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
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
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
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
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
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).
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
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 -
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
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
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
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
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
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.
>> [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
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
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
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
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(>count)) {
from page_alloc.c (this
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
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
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,
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
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
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
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
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
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
** 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,
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
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
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
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
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
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
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
> 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]
-
[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
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
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
This is probably due to the source being 'none', but the shm mount point
can be mounted twice at the same mount point.
Shouldn't mount(2) return -EBUSY in this case?
# cat /etc/mtab
/dev/hda4 / ext2 rw,errors=remount-ro,errors=remount-ro 0 0
proc /proc proc rw 0 0
devpts /dev/pts devpts
On Wed, 3 Jan 2001, Alexander Viro wrote:
>
>
> 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
On Wed, 3 Jan 2001, Alexander Viro 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 intended to be an insult. Plain and simple advice. Idea is
[..]
Did you
On Wed, 3 Jan 2001, Mark Zealey wrote:
> On Wed, 3 Jan 2001, Alexander Viro wrote:
>
> >
> >
> > 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
> depmod: *** Unresolved symbols in /lib/modules/2.2.19pre5/fs/binfmt_elf.o
> depmod: get_pte_slow
> depmod: get_pmd_slow
> depmod: pgt_quicklists
Thanks, fix is in cvs.
Anton
--- arch/sparc64/kernel/sparc64_ksyms.c.origThu Jan 4 09:04:07 2001
+++
On Wed, 3 Jan 2001, Tom Rini wrote:
> 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
On Wed, Jan 03, 2001 at 11:32:52PM +0200, Marko Kreen wrote:
> -udelay(15000); /* delay for 50 (15) ms */
> +mdelay(15); /* delay for 50 (15) ms */
Per Mark Hahn suggestion here is a patch that fixes the weird
comments too. This is cumulative to the previous patch.
--
marko
---
On Wed, 3 Jan 2001, Petr Vandrovec wrote:
> 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
On Wed, 3 Jan 2001, Alexander Viro wrote:
>
>
> On Wed, 3 Jan 2001, Mark Zealey wrote:
>
> > On Wed, 3 Jan 2001, Alexander Viro wrote:
> >
> > >
> > >
> > > On Wed, 3 Jan 2001, Dan Hollis wrote:
> > >
> > > > On Wed, 3 Jan 2001, Alexander Viro wrote:
> > > > > On Wed, 3 Jan 2001, Dan
Hi,
I have a strange problem (preventing me from testing the latest
2.4 kernel ... *sigh*) with my LVM setup.
The latest LVM utils + the latest kernel works just fine on my
test machine, but breaks horribly on my workstation. The only
difference I have found is that one PV of my VG has "NOT
> 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, small patch prevents execution of system calls which
> were executed from a writable segment.
On Thu, 4 Jan 2001, Dan Aloni wrote:
> Did you notice that question was ambiguous? I understood that sentence in
> its other meaning, i.e, someone insulting Alex ;-)
Well, _that_ definitely takes more than posting a patch ;-)
> Anyway, while it is agreed that you can't completely eliminate
hello,
Would XML be considered human readable enough for /proc files? If not,
how about a /xproc filesystem ( maybe as a kernel build option ), same
as /proc but uses an xml grammer for reporting.
I can see tons of uses for this, no more 'fuzzy' parsing for gui
configuration tools, resource
Rik van Riel <[EMAIL PROTECTED]> writes:
> 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)
>
> recent kernels. It looks like there may be a slight drop
> in performance for -ac5. For -ac4 and -ac5, the throughput
-ac5 touches stuff which would have performance effects. That would be
reasonable to suspect.
- Rik's partial page changes
- A couple of other
On Wed, 3 Jan 2001, Andrea Arcangeli wrote:
> 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
Marc ZYNGIER wrote:
>
> 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
Hi!
I've just released LOMAC v1.0 - an LKM for Linux 2.2 kernels that
implements a form of Low Water-Mark Mandatory Access Control (MAC) to
protect the integrity of processes and data from viruses, Trojan
horses, malicious remote users, and compromised root daemons. LOMAC
is designed for
301 - 400 of 475 matches
Mail list logo
