On Tue, 28 Nov 2000, Peter Samuelson wrote:
> [Tigran Aivazian]
> > First, they are not trivially equivalent. In fact, they are not
> > equivalent at all. Any good C book should tell you that one places
> > data in "data segment" and another in "bss segment" (with a footnote
> > explaining histor
Whoops, my bad. Yes, 4k blocks.
Block size: 4096
Ion Badulescu wrote:
>
> No, you misunderstood me. df is always going to say 1k-blocks, but that
> doesn't mean that the filesystem's allocation unit is actually 1k.
>
> Try doing a tune2fs -l on the device holding the filesystem
On Wed, 29 Nov 2000, Mohammad A. Haque wrote:
> [mhaque@viper mhaque]$ df
> Filesystem 1k-blocks Used Available Use% Mounted on
> /dev/hda3 12737128 9988400 2101712 83% /
> /dev/hda246668 15106 29153 35% /boot
> /dev/hdd1 443274
Petr Vandrovec wrote:
>
> On 29 Nov 00 at 1:53, Andrew Morton wrote:
>
> > hmm.. Quite a few things fixed here.
> >
> > Could you please test this patch? It's against 2.4.0-test12-pre2,
> > should be OK against test11.
>
> I upgraded to 12-pre2 already ;-) It looks like that it works.
Yup.
[mhaque@viper mhaque]$ df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda3 12737128 9988400 2101712 83% /
/dev/hda246668 15106 29153 35% /boot
/dev/hdd1 44327416 26319188 15756484 63% /home2
none
The bulk of this is architecture updates (most lately mips64). The most
interesting (but fairly small) part is the VM cleanups. Any day now
kiobuf's can just use PageDirty on everything, and we won't have any nasty
races any more.
Linus
- pre3:
- me: more PageDirty /
On Tue, 28 Nov 2000 23:37:49 -0500, Mohammad A. Haque <[EMAIL PROTECTED]> wrote:
> Ok, I just found a file with about the first 4k of it filled with nulls
> (^@^@). No telling if this was a result of what originally started this
> thread or not. I hadn't accessed that file since Nov 9th.
1k- or 4
Ok, I just found a file with about the first 4k of it filled with nulls
(^@^@). No telling if this was a result of what originally started this
thread or not. I hadn't accessed that file since Nov 9th.
--
=
Mohammad A. Haque
On Wed, 29 Nov 2000 [EMAIL PROTECTED] wrote:
>
> I did again a large test comparing two identical trees.
> Found again corruption, and, upon inspection, the disk
> files did not differ - this is in-core corruption only.
Ok. It definitely looks like the 1kB thing has become broken somehow.
The
On Wed, 29 Nov 2000 01:37:22 +0100,
Kurt Garloff <[EMAIL PROTECTED]> wrote:
>this is a 2.4.0-test11 system;
>rmmod -a (modutils-2.3.21) fails to unload unused autocleanable modules:
Designed behaviour. sys_delete_module only removes autoclean modules
that have been used at least once, either the
I did again a large test comparing two identical trees.
Found again corruption, and, upon inspection, the disk
files did not differ - this is in-core corruption only.
A few days ago:
diff -r /c2/linux/linux-2.4.0-test10/linux/include/asm-sparc/ecc.h /g1/linux/li\
nux-2.4.0-test10/linux/include/a
Hi,
I'm trying to capture IP packets over a Token Ring network through a
(PF_PACKET, SOCK_RAW) socket, but for some
reason the sll_protocol field in the sockaddr_ll structure doesn't
contain ETH_P_IP for IP packets but rather contains 0x100 (of course, in
network byte order).
Is this a bug, or
[Keith Owens]
> Binary patches against bss on disk cannot work, there is nothing to
> patch.
OK, me dumkopf.
Peter
-
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/
On Tue, 28 Nov 2000 17:53:48 -0600,
Peter Samuelson <[EMAIL PROTECTED]> wrote:
>Binary patching? If you are binary patching something you need to get
>the exact location, one way or another. Whatever tool you use to
>extract the location of a symbol in an object file, that same tool
>should tel
[Albert D. Cahalan]
> Choosing an initializer that tends to catch unintended reliance on
> zeroed data would be good. Too bad it is too late to fix.
Why would that be good? Why is it bad to accidentally rely on zeroed
data, if the data is in fact guaranteed to be zeroed? It's not like
this is
[Remi Turk]
> Do I understand correctly that this means hardlinks to directories
> (except . and ..) are fundamentally impossible in Linux?
Why do you want to be able to do that? Use symlinks or loopback mounts
and stay out of trouble.
> (I'm thinking about trying to write a garbage collected f
On Wed, 29 Nov 2000, Alan Cox wrote:
> > I've never seen such thing as code without bugs. In my experience,
> > the NVIDIA drivers are by far the most complete and solid 3D drivers
> > under Linux.
>
> You are welcome to your opinion. I've got this great bridge to sell you too
BTW, in case this
Is there any support for the mobile IBM disk drive Advanced Battery Life
Extender power settings in Linux?
http://www.alphaworks.ibm.com/tech/powerbooster
Power Booster allows any computer running Windows 95/98 and an IBM ATAPI 4
mobile disk drive to directly control advanced power managemen
On Wed, 29 Nov 2000, Alan Cox wrote:
> > I've never seen such thing as code without bugs. In my experience,
> > the NVIDIA drivers are by far the most complete and solid 3D drivers
> > under Linux.
>
> You are welcome to your opinion. I've got this great bridge to sell you too
I don't see the n
> I've never seen such thing as code without bugs. In my experience,
> the NVIDIA drivers are by far the most complete and solid 3D drivers
> under Linux.
You are welcome to your opinion. I've got this great bridge to sell you too
-
To unsubscribe from this list: send the line "unsubscribe lin
On Wed, 29 Nov 2000, Alan Cox wrote:
> > On Tue, 28 Nov 2000, Dan Hollis wrote:
> > > Dont forget the nvidia driver is completely SMP broken. As in, trash your
> > > filesystems broken.
> >
> > Not true. It works for us with no problems on a number of SMP boxes
> > running 2.2.{14,16}. I don't k
> - pre2:
> - Richard Henderson: PCI bridge initialization on alpha
Doesn't boot on noritake alpha.
It gets to POSIX conformance testing by UNIFIX
and hard locks. the halt switch doesn't even work.
--
Lab tests show that use of micro$oft causes cancer in lab animals
-
To unsubscribe fr
> On Tue, 28 Nov 2000, Dan Hollis wrote:
> > Dont forget the nvidia driver is completely SMP broken. As in, trash your
> > filesystems broken.
>
> Not true. It works for us with no problems on a number of SMP boxes
> running 2.2.{14,16}. I don't know about 2.4.x.
Dan is not the only one to repo
2.2.18pre24
o Expose put_unused_fd for modules(Andi Kleen)
o Fix the ps/2 mouse probe I hope (me)
o Fix crash in cosa driver(Jan Kasprzak)
o Fix procfs negative seek offset error reporting (HJ Lu)
o Fix ext2 fil
On Tue, 28 Nov 2000, Dan Hollis wrote:
> Dont forget the nvidia driver is completely SMP broken. As in, trash your
> filesystems broken.
Not true. It works for us with no problems on a number of SMP boxes
running 2.2.{14,16}. I don't know about 2.4.x.
KV
--
___
On Wed, 29 Nov 2000 02:29:04 Dan Hollis wrote:
> On Wed, 29 Nov 2000, J . A . Magallon wrote:
> > On Wed, 29 Nov 2000 01:39:56 Dan Hollis wrote:
> > > Dont forget the nvidia driver is completely SMP broken. As in, trash your
> > > filesystems broken.
> > Not so broken. I use it under SMP 2.2.18-p
Russell King writes:
> Albert D. Cahalan writes:
>> It is too late to fix things now. It would have been good to
>> have the compiler put explicitly zeroed data in a segment that
>> isn't shared with non-zero or uninitialized data, so that the
>> uninitialized data could be set to 0xfff00fff to c
On Wed, 29 Nov 2000, Jens Axboe wrote:
> On Wed, Nov 29 2000, Andrea Arcangeli wrote:
> > Side note: that could generate mem/io corruption only on headactive devices
> > (like IDE).
>
> Yep, that's why I told Linus it was a long shot and couldn't possibly
> account for all the corruption cases r
On Wed, 29 Nov 2000, J . A . Magallon wrote:
> On Wed, 29 Nov 2000 01:39:56 Dan Hollis wrote:
> > Dont forget the nvidia driver is completely SMP broken. As in, trash your
> > filesystems broken.
> Not so broken. I use it under SMP 2.2.18-pre23 and works fine.
Try unreal tournament. Locks up hard
On Wed, Nov 29 2000, Andrea Arcangeli wrote:
> Side note: that could generate mem/io corruption only on headactive devices
> (like IDE).
Yep, that's why I told Linus it was a long shot and couldn't possibly
account for all the corruption cases reported. And one would expect
fs corruption to go wi
On Wed, 29 Nov 2000 01:39:56 Dan Hollis wrote:
>
> Dont forget the nvidia driver is completely SMP broken. As in, trash your
> filesystems broken.
>
Not so broken. I use it under SMP 2.2.18-pre23 and works fine. But under 2.4
hangs. So I think it is something that changed between 2.2 and 2.4 (
Side note: that could generate mem/io corruption only on headactive devices
(like IDE).
Andrea
-
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/
On Tue, Nov 28, 2000 at 10:24:48PM +0100, Kurt Garloff wrote:
> This is a pity, because I think the current behaviour is not acceptable,
> as it can kill the machine by just being invoked by kmod.
> I will try to make sense out of the code and make sure that modprobe
> will not go crazy, by either
On Tue, Nov 28 2000, Petr Vandrovec wrote:
> On 28 Nov 00 at 12:04, David S. Miller wrote:
> >
> >Yes, it is identical copy. But I do not think that hdd can write same
> >data into two places with one command...
> >
> > Petr, did the af_inet.c assertions get triggered on this
> > same ma
On Wed, 29 Nov 2000, Alan Cox wrote:
> > Thanks to some nice people in #NVIDIA I found what seems to be a
> > solution; compile with processor type as "K6". No segfaults, lost
> > terminfo or disabled consoles.
> > So are there issues with the K7 processor code? Bleh, never mind, I have
> > no ide
Hi,
this is a 2.4.0-test11 system;
rmmod -a (modutils-2.3.21) fails to unload unused autocleanable modules:
modprobe -r behaves the same, BTW
root@cantaloupe:~ > lsmod
Module Size Used by
ppp_deflate44736 0 (autoclean) (unused)
ppp_generic25728 0 (
On Tue, Nov 28, 2000 at 01:44:18PM +0200, Ville Herva wrote:
> try Andrea's vm-global-7 now. It seems to include the bits Rik posted, or
It doesn't include the bits Rik posted because they were unnecessary.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the b
On Wed, Nov 29, 2000 at 01:04:16AM +0100, Andrea Arcangeli wrote:
> On Tue, Nov 28, 2000 at 03:36:15PM -0800, John Kennedy wrote:
> > No, it is all ext3fs stuff that is touching the same areas your
>
> Ok this now makes sense. I ported VM-global-7 on top of ext3 right now
> but it's untested:
On Tue, 28 Nov 2000, Alan Cox wrote:
> > Why is RLIMIT_NPROC apllied to root(uid 0) processes? It's not kernel j=
> > ob to
> > prevent admin from shooting him/her self in the foot.
> >
> > root should be able to do fork() regardless of any limits,
> > and IMHO the following patch is the right t
Alan Cox wrote:
> The K7 optimisations are not used for I/O space accessess. Or shouldnt be,
> but the nvidia code is unreadable so they may have done so
OK. I believe at least one of the NVIDIA developers read this list, so
hopefully they can look at what can be done on their side.
But seeing as
> Thanks to some nice people in #NVIDIA I found what seems to be a
> solution; compile with processor type as "K6". No segfaults, lost
> terminfo or disabled consoles.
>
> So are there issues with the K7 processor code? Bleh, never mind, I have
> no idea what I am talking about.
The K7 optimisat
On Tue, Nov 28, 2000 at 03:36:15PM -0800, John Kennedy wrote:
> No, it is all ext3fs stuff that is touching the same areas your
Ok this now makes sense. I ported VM-global-7 on top of ext3 right now
but it's untested:
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2
Thanks to some nice people in #NVIDIA I found what seems to be a
solution; compile with processor type as "K6". No segfaults, lost
terminfo or disabled consoles.
So are there issues with the K7 processor code? Bleh, never mind, I have
no idea what I am talking about.
Original bug report: http://
On Tue, Nov 28, 2000 at 04:17:12PM -0700, Ian S. Nelson wrote:
> Is there a standardized way of doing this yet? I'm not using any MTD
> stuff, yet, and it doesn't look like something that the code currently
> does.
The standard way of doing it on ARM linux systems is that the boot
loader copies
[Tigran Aivazian]
> First, they are not trivially equivalent. In fact, they are not
> equivalent at all. Any good C book should tell you that one places
> data in "data segment" and another in "bss segment" (with a footnote
> explaining historical meaning of "block started by symbol")
Do you ha
On Wed, Nov 29, 2000 at 12:20:09AM +0100, Andrea Arcangeli wrote:
> On Tue, Nov 28, 2000 at 03:02:35PM -0800, John Kennedy wrote:
> > On Sat, Nov 25, 2000 at 02:57:01PM +0100, Andrea Arcangeli wrote:
> > > ... VM-global-*-7 has no known bugs AFIK.
> >
> > Is there anything more recent than VM-g
On Tue, 28 Nov 2000, Peter Cordes wrote:
> I'm of the opinion that Linux should work in the way that is most useful,
> as long as that doesn't stop us from running stuff written for other unices.
> Unix is mostly good, but parts of it suck. There's no reason to keep the
> parts that suck, exc
In article <[EMAIL PROTECTED]>,
Frank v Waveren <[EMAIL PROTECTED]> wrote:
>On Tue, Nov 28, 2000 at 09:58:14PM +, Alan Cox wrote:
>> > Because you want to be able to `kill `?
>> > And if you are over-limits you can't?
>> Wrong. limit is a shell built in
>
>I assume you mean kill is a shell bu
On Tue, Nov 28, 2000 at 03:02:35PM -0800, John Kennedy wrote:
> On Sat, Nov 25, 2000 at 02:57:01PM +0100, Andrea Arcangeli wrote:
> > ... VM-global-*-7 has no known bugs AFIK.
>
> Is there anything more recent than VM-global-2.2.18pre18-7? It isn't
> patching very cleanly against my pre-patch-
Is there a standardized way of doing this yet? I'm not using any MTD
stuff, yet, and it doesn't look like something that the code currently
does.
Ian
-
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 h
Geert Uytterhoeven wrote:
>
> Hi Jorge,
>
> In linux-2.4.0-test12-pre2/Documentation/filesystems/proc.txt, you wrote:
>
> | fb Frame Buffer devices (2.4)
>
> This entry existed in 2.2 as well.
>
> Gr{oetje,eeting}s,
>
>
On Sat, Nov 25, 2000 at 02:57:01PM +0100, Andrea Arcangeli wrote:
> ... VM-global-*-7 has no known bugs AFIK.
Is there anything more recent than VM-global-2.2.18pre18-7? It isn't
patching very cleanly against my pre-patch-2.2.18-23 tree.
(I don't see anything under your pre19 thru pre23 di
2.4.0test12-pre2
Please reorder config to group DMA options together.
Pavel Rabel
--- drivers/ide/Config.in.old Tue Nov 28 22:22:49 2000
+++ drivers/ide/Config.in Tue Nov 28 22:24:19 2000
@@ -42,8 +42,8 @@
bool ' Generic PCI IDE chipset support' CONFIG_BLK_DEV_IDEPCI
On Mon, Nov 27, 2000 at 01:42:51PM +0100, Andries Brouwer wrote:
> On Sun, Nov 26, 2000 at 11:35:22PM -0400, Peter Cordes wrote:
>
> > While doing some hdparm hacking, after booting with init=/bin/sh, I noticed
> > that open(1) doesn't work when / is mounted read only.
>
> Already long ago open
Ok, I'm not sure what else to try. I've even tried throwing around 1.6
GB of data, and copying and deleting at the same time. Nothing. Again,
this is _without_ the patches sent by Alexander.
I think I'm just gonna go on to test12-pre2.
Neil Brown wrote:
>
> Turns out my data is a false alarm.
On Tue, Nov 28, 2000 at 09:58:14PM +, Alan Cox wrote:
> > Because you want to be able to `kill `?
> > And if you are over-limits you can't?
> Wrong. limit is a shell built in
I assume you mean kill is a shell builtin. Depending on your shell. :-).
It's still a real pain when you want to get t
I still get those at random (and no, I'm not hot-rebooting from ms windows)
Normally the cookie is 0xfff8 or similar.
--
/| Ragnar Højland Freedom - Linux - OpenGL Fingerprint 94C4B
\ o.O| 2F0D27DE025BE2302C
=(_)= "Thou shalt
> > AFAICS, _all_ resource limits are equally applied to root processes. =
> Why
> > should NPROC be different?
>
> Because you want to be able to `kill `?
> And if you are over-limits you can't?
Wrong. limit is a shell built in
-
To unsubscribe from this list: send the line "unsubscribe linux
> Why is RLIMIT_NPROC apllied to root(uid 0) processes? It's not kernel j=
> ob to
> prevent admin from shooting him/her self in the foot.
>
> root should be able to do fork() regardless of any limits,
> and IMHO the following patch is the right thing.
This patch is bogus. root can always raise
On Tue, Nov 28, 2000 at 03:04:31PM +0100, Rogier Wolff wrote:
> Ok, so if you read the standard carefully you get a bogus result.
Why bogus? Things could have been otherwise, but the important
part is that all Unices do things the same way.
> Question: Was it meant this way, or did someone jus
On Wed, Nov 29, 2000 at 07:33:53AM +1100, Keith Owens wrote:
> On Tue, 28 Nov 2000 20:22:59 +0100,
> Kurt Garloff <[EMAIL PROTECTED]> wrote:
> >Find attached the modules.dep that caused this: There is a circular
> >dependency of pppoe on pppox on pppoe on
>
> The kernel code is broken. Cir
On Tue, 28 Nov 2000, Andreas Schwab wrote:
> Jan Rekorajski <[EMAIL PROTECTED]> writes:
>
> |> Why is RLIMIT_NPROC apllied to root(uid 0) processes? It's not kernel job to
> |> prevent admin from shooting him/her self in the foot.
> |>
> |> root should be able to do fork() regardless of any lim
On Tue, Nov 28, 2000 at 01:08:44PM -0800, Ben Ford wrote:
> Jakob Østergaard wrote:
>
>
>
> > comments, Riel or Andrea ?). I don't know of any good solution to this problem
> > other than just having enough swap space - after all, seriously, with today's
> > disks, who can't spare an extra few
Jan Rekorajski <[EMAIL PROTECTED]> writes:
|> Why is RLIMIT_NPROC apllied to root(uid 0) processes? It's not kernel job to
|> prevent admin from shooting him/her self in the foot.
|>
|> root should be able to do fork() regardless of any limits,
|> and IMHO the following patch is the right thing.
Jakob Østergaard wrote:
> comments, Riel or Andrea ?). I don't know of any good solution to this problem
> other than just having enough swap space - after all, seriously, with today's
> disks, who can't spare an extra few hundred megs (which would usually be more
> than enough).
An embedded
On Tue, 28 Nov 2000, Tigran Aivazian wrote:
> On Tue, 28 Nov 2000, Jan Rekorajski wrote:
> > --- linux/kernel/fork.c~Tue Sep 5 23:48:59 2000
> > +++ linux/kernel/fork.c Sun Nov 26 20:22:20 2000
> > @@ -560,7 +560,8 @@
> > *p = *current;
> >
> > retval = -EAGAIN;
> > - if (ato
Jan R_korajski writes:
> Why is RLIMIT_NPROC apllied to root(uid 0) processes? It's not kernel job to
> prevent admin from shooting him/her self in the foot.
> - if (atomic_read(&p->user->processes) >= p->rlim[RLIMIT_NPROC].rlim_cur)
By default, root has no real process limits anyways, so th
On Tue, 28 Nov 2000, David Hinds wrote:
> I would contend that it is a compiler bug in gcc if it treats the two
> statements differently, since they are trivially equivalent. I guess
> that it has been decided that linux kernel coding style dictates no
> zero initializers, so that's that. Person
On Sat, 25 Nov 2000, Adam J. Richter wrote:
> For those of you playing with Alan Cox's linux-2.4.0-test11ac4
> release, I have made a separate patch of the remaining device ID
> changes which patches against that kernel and builds cleanly (the
> primary difference is that it omits the files
> What information is lost? Unless you're working on a really strange
> machine which does not zero bss, the following means the same from the
> codes point of view:
>
> static int foo = 0;
> static int foo;
I think the argument is that "static int foo;" implies you don't
actually care how "foo"
> On Tue, 28 Nov 2000, Jan Rekorajski wrote:
> > --- linux/kernel/fork.c~Tue Sep 5 23:48:59 2000
> > +++ linux/kernel/fork.c Sun Nov 26 20:22:20 2000
> > @@ -560,7 +560,8 @@
> > *p = *current;
> >
> > retval = -EAGAIN;
> > - if (atomic_read(&p->user->processes) >= p->rlim[RLIM
On Tue, 28 Nov 2000, Jan Rekorajski wrote:
> --- linux/kernel/fork.c~ Tue Sep 5 23:48:59 2000
> +++ linux/kernel/fork.c Sun Nov 26 20:22:20 2000
> @@ -560,7 +560,8 @@
> *p = *current;
>
> retval = -EAGAIN;
> - if (atomic_read(&p->user->processes) >= p->rlim[RLIMIT_NPR
HI!
> This patch adds a workaround for the Dallas chip; the chip tags
> its 8bit formats with PCM8 but expects signed data.
> @@ -2895,6 +2897,9 @@
> continue;
> }
> format = (fmt[5] == 2) ? (AFMT_U16_LE | AFMT_U8) :
>(AF
Following patch is removing old config stuff which probably survived from
OSS.
Pavel Rabel
--- linux/drivers/sound/mad16.c.old Tue Nov 28 20:34:52 2000
+++ linux/drivers/sound/mad16.c Tue Nov 28 20:47:05 2000
@@ -20,38 +20,6 @@
* issues of the card, using the OTI-605 chip, have an MPU-401
On 28 Nov 00 at 12:04, David S. Miller wrote:
>
>Yes, it is identical copy. But I do not think that hdd can write same
>data into two places with one command...
>
> Petr, did the af_inet.c assertions get triggered on this
> same machine?
No, ext2fs is at home, and af_inet is at work...
Why is RLIMIT_NPROC apllied to root(uid 0) processes? It's not kernel job to
prevent admin from shooting him/her self in the foot.
root should be able to do fork() regardless of any limits,
and IMHO the following patch is the right thing.
--- linux/kernel/fork.c~Tue Sep 5 23:48:59 200
On Tue, 28 Nov 2000, Petr Vandrovec wrote:
> > two ranges? Then it looks like something way below the fs level... Weird.
> > Could you verify it with dd?
>
> Yes, it is identical copy. But I do not think that hdd can write same
> data into two places with one command...
>
> vana:/# dd if=/dev
On Tue, 28 Nov 2000, Eli Carter wrote:
> Patch is against 2.2.17, drivers/net/lance.c.
> I believe this to be "obviously correct," but please correct me if I'm
> wrong.
> This moves a reference to skb->len to before the possible
> dev_kfree_skb(skb) call. Though it appears to work as is, I suspe
> when doing mount/umount of a MSDOS floppy on 2.2.16-22
> I often get
>
> /var/log/messages.1:Nov 25 21:02:18 localhost kernel: set_blocksize: dev
> 02:00 buffer_dirty 19 size 512
> /var/log/messages.2:Nov 16 18:19:05 localhost kernel: set_blocksize: dev
> 02:00 buffer_dirty 19 size 512
It impl
On Mon, 27 Nov 2000, Jeff V. Merkey wrote:
> A level IV issue in 2.2.18-23. With frame buffer enabled, upon boot,
> the OS is displaying four penguin images instead of one penguin in the
> upper left corner of the screen. Looks rather tacky. Also puts the
> VGA text mode default into mode 274.
On Wed, 29 Nov 2000, Keith Owens wrote:
> On Tue, 28 Nov 2000 20:22:59 +0100,
> Kurt Garloff <[EMAIL PROTECTED]> wrote:
> >Find attached the modules.dep that caused this: There is a circular
> >dependency of pppoe on pppox on pppoe on
>
> The kernel code is broken. Circular dependencies m
On Tue, 28 Nov 2000 20:22:59 +0100,
Kurt Garloff <[EMAIL PROTECTED]> wrote:
>Find attached the modules.dep that caused this: There is a circular
>dependency of pppoe on pppox on pppoe on
The kernel code is broken. Circular dependencies make no sense, the
pppoe maintainer agrees and I thoug
when doing mount/umount of a MSDOS floppy on 2.2.16-22
I often get
/var/log/messages.1:Nov 25 21:02:18 localhost kernel: set_blocksize: dev
02:00 buffer_dirty 19 size 512
/var/log/messages.2:Nov 16 18:19:05 localhost kernel: set_blocksize: dev
02:00 buffer_dirty 19 size 512
Is this harmless or s
From: "Petr Vandrovec" <[EMAIL PROTECTED]>
Date: Tue, 28 Nov 2000 21:10:36 MET-1
Yes, it is identical copy. But I do not think that hdd can write same
data into two places with one command...
Petr, did the af_inet.c assertions get triggered on this
same machine?
If yes, you
On 28 Nov 00 at 15:02, Alexander Viro wrote:
> On Tue, 28 Nov 2000, Petr Vandrovec wrote:
>
> > Hi Al,
> > during weekend I was uncompressing XFree (Debian's 4.0.1-7) at home,
> > with 2.4.0-test11 running on Celeron 300A, 128MB RAM, SMP kernel on up.
> > It failed to compile lbxproxy/di/main.c
On Tue, 28 Nov 2000, Petr Vandrovec wrote:
> Hi Al,
> during weekend I was uncompressing XFree (Debian's 4.0.1-7) at home,
> with 2.4.0-test11 running on Celeron 300A, 128MB RAM, SMP kernel on up.
> It failed to compile lbxproxy/di/main.c. After some investigation I found
> that they were ove
Miles Lane wrote:
>
> /usr/src/linux/include/linux/kernel_stat.h:48: for each function it
> appears in.)make[2]: *** [ksyms.o] Error 1
> make[2]: Leaving directory `/usr/src/linux/kernel'
> make[1]: *** [first_rule] Error 2
> make[1]: Leaving directory `/usr/src/linux/kernel'
> make: *** [_dir_ke
Hi Al,
during weekend I was uncompressing XFree (Debian's 4.0.1-7) at home,
with 2.4.0-test11 running on Celeron 300A, 128MB RAM, SMP kernel on up.
It failed to compile lbxproxy/di/main.c. After some investigation I found
that they were overwritten by some source font data. fsck did not reveal
a
On Tue, Nov 28, 2000 at 05:09:48PM +0100, Andreas Schwab wrote:
> including the Linux kernel. :-)
As it's a worthless extension it's always trivial to fixup after its removal :).
The fixup also shown that the sis_300 and sis_301 driver would break if used at
the same time (probably unlikely to h
Hi Keith,
thanks for your modutils-2.3.21!
During testing I found a problem:
modprobe pppoe was recursing endlessly in build_stack().
Find attached the modules.dep that caused this: There is a circular
dependency of pppoe on pppox on pppoe on
modprobe has code to detect this in build_stac
I retract the comment about "accept() 2nd argument scribbled over
in the child". That was a misinterpretation of the strace log.
strace shows the struct sockaddr * scribble in the parent after a restart
of the accept() call. Also, the firewalling code is eliminated from
consideration. I compiled i
> > The output of lspci -v:
> [...]
> > 00:0e.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08)
> > Subsystem: Intel Corporation 82559 Fast Ethernet LAN on Motherboard
> > Flags: bus master, medium devsel, latency 64, IRQ 5
>
> Hmm, this is the device yo
On Fri, 24 Nov 2000, Igor Yu. Zhbanov wrote:
> Hello!
Hello, sorry for the slow response.
> I have found a bug in drivers of file systems which use a DOS-like format
> of date (16 bit: years since 1980 - 7 bits, month - 4 bits, day - 5 bits).
[snip]
> 2) VFAT for example have three kinds of d
Followup to: <[EMAIL PROTECTED]>
By author:Gianluca Anzolin <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> |No, the problem is the utterly braindamaged way the motherboard chose to
> |enable/disable it (*especially* if it's PCI... sheech, port 92h isn't
> |exactly something new in tha
Greetings all,
Patch is against 2.2.17, drivers/net/lance.c.
I believe this to be "obviously correct," but please correct me if I'm
wrong.
This moves a reference to skb->len to before the possible
dev_kfree_skb(skb) call. Though it appears to work as is, I suspect it
is incorrect.
Please apply
On Tue, 28 Nov 2000, Alexander Viro wrote:
> You know, in such cases usual course of actions is to remove the bloody
> thing. It's not used, it's not set to anything useful, semantics is
> fundamentally non-obvious, so Occam's Razor applies. Until somebody
> comes up with a reasonable use _and_ cl
On 29 Nov 00 at 1:53, Andrew Morton wrote:
> hmm.. Quite a few things fixed here.
>
> Could you please test this patch? It's against 2.4.0-test12-pre2,
> should be OK against test11.
I upgraded to 12-pre2 already ;-) It looks like that it works.
> - keventd is now capable of reaping dead ch
On Tue, 28 Nov 2000, Tigran Aivazian wrote:
> it is not basic at all. The problems you point out are extremely complex
> (at least the fd in transit issue, definitely is).
>
> So, yes it requires a bit more thought. I will come back when the issues
> you pointed out are dealt with. Someone ha
I bought this card on the promise that there'd be open drivers.
Sigh.
I shall forward the bug report to NVIDIA.
Alan Cox wrote:
>
> > My graphics card is a NVIDIA GeForce DDR, using the 0.9-5 release. For
> > -test11 I had to patch 0.9-5 (but this was only a very trivial patch, I
> > am told).
Date: Tue, 28 Nov 2000 18:23:52 +0100
From: Lorenzo Allegrucci <[EMAIL PROTECTED]>
BTW, all local services (smtp, telnet etc) work well. Any ideas?
No ideas, and since the indicated programs from lmbench work
perfectly fine here on my machines, you're going to have to do some
detecti
1 - 100 of 162 matches
Mail list logo
