This should have gone on my last email:
[root@blackbird log]# cat /proc/pci
PCI devices found:
Bus 0, device 0, function 0:
Host bridge: VIA Technologies Unknown device (rev 68).
Vendor id=1106. Device id=691.
Medium devsel. Master Capable. No bursts.
Prefetchable 32
>There are no gcc 2.97 snapshots that compile the kernel correctly because
>they have the broken bitfield packing ABI change.
Oh right. I didn't know about that particular nicety.
>My belief however is that several million people have gcc 2.96-69+, about 50
>are likely to have random cvs snaps
Hallo all,
I found some posts in this list to the problem mentioned in the subject and
want to tell about my experiences. Maybe it can help to detect the problem.
I got a lot of messages while continuous writing / reading datas from one a
harddisk to another harddisk (both at 1. ide-channel)
Well... I remember this message showing on my console, although I was
doing nothing special...
Apr 18 14:37:01 blackbird kernel: probable hardware bug: clock timer
configuration lost - probably a VIA686a.
Apr 18 14:37:01 blackbird kernel: probable hardware bug: restoring chip
configuration.
--
Ap
> Are you being deliberately obtuse? 2.97+ snapshots do all support
> builtin_expect, which is what we were discussing.
I think we are having different conversations here.
The only valid inputs to the question are
Recommended
---
egcs-1.1.2 (miscom
On Sat, Apr 21, 2001 at 06:04:47PM +0200, Victor Julien wrote:
> I have a problem with kernels higher than 2.4.2, the sound distorts when
> playing a song with xmms while the seti@home client runs. 2.4.2 did not have
Would this be the same issue as describe in these threads:
http://www.uwsg.in
Alan,
>> /usr/src/linux-2.4.3-ac12/lib/lib.a(rwsem.o): In function
>> `rwsem_up_write_wake':rwsem.o(.text+0x3c6): undefined reference to
>> `__builtin_expect'
>
>Add a
>
>#define __builtin_expect
I had the same problem here, adding #define __builtin_expect in ../lib/rwsem.c
solved the problem.
sorry to write so many messages for the same thing... but I fotgot to
mention that I'm using 2.2.19, not 2.4.x
that's it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordo
> > But if you are suppressing preemption in all read-side critical
sections,
> > then wouldn't any already-preempted tasks be guaranteed to -not- be in
> > a read-side critical section, and therefore be guaranteed to be
unaffected
> > by the update (in other words, wouldn't such tasks not need t
f5ibh wrote:
> Alan,
>
>
>>> /usr/src/linux-2.4.3-ac12/lib/lib.a(rwsem.o): In function
>>> `rwsem_up_write_wake':rwsem.o(.text+0x3c6): undefined reference to
>>> `__builtin_expect'
>>
>> Add a
>>
>> #define __builtin_expect
>
>
> I had the same problem here, adding #define __builtin_expect
[EMAIL PROTECTED] said:
> [BTW, another solution is to truly support opaque "handles" to kernel
> objects; I believe David Howells is already working on something like
> this for Wine? The poll interface can be trivially extended to support
> waiting on those...]
ISTR it wasn't quite trivial to
Well, that's the reason for my small-negative-integer semaphore-FD idea...
(It won't support select() easily, but poll() is prob'ly good enough)
Still, there is the problem of read()/write()/etc. semantics; sure, we can
declare that 'negative FDs' have their own semantics which just happen to
incl
On Sun, 22 Apr 2001, Alon Ziv wrote:
> Well, that's the reason for my small-negative-integer semaphore-FD idea...
> (It won't support select() easily, but poll() is prob'ly good enough)
> Still, there is the problem of read()/write()/etc. semantics; sure, we can
> declare that 'negative FDs' ha
> Eric wants an easy way to find the owner of a CONFIG_ entry.
> True, the consensus seems to be that this isn't a particularly
> useful thing to do, but if it must be done, this seems like an
> eminently sane way to do it.
So we need a system to handle the thousand odd entries, a person to maint
oops :
both tried kernel 2.4.4-pre5 (with ide patches)
and kernel 2.2.14pre12 (with ide and raid patches)
On Sun, 22 Apr 2001 [EMAIL PROTECTED] wrote:
> i'm going to build a raid5 config with 6*maxtor 80gb
> mainbord is an asus p2b-d (with dual 450 and 512mb ram)
> and 2 addon ultra66 promise c
i'm going to build a raid5 config with 6*maxtor 80gb
mainbord is an asus p2b-d (with dual 450 and 512mb ram)
and 2 addon ultra66 promise controllers
i did some tests using hdparm (4.1)
and i get these result :
(hda and hdc are on the onboard controller)
/dev/hda:
Timing buffered disk reads: 6
On Sun, 22 Apr 2001, Russell King wrote:
> > C: CONFIG_SCSI_BLARG
> > F: drivers/scsi/blarg.c
> > F: drivers/scsi/blarg.h
> And what would:
>
> C: CONFIG_ARM
>
> tell you? Nothing that is not described in the rest of the "ARM PORT"
> entry.
True, but it would tell it to a script without interv
I'm reading Rubini's "Linux Device Drivers" and it isn't clear to me
whether the scheduler runs every time the timer interrupt increments
jiffies or less frequently.
Does the scheduler run every time jiffies is incremented?
--
Francis Litterio
[EMAIL PROTECTED]
http://world.std.com/~franl/
PGP pu
Am Sonntag, 22. April 2001 14:46 schrieb Alan Cox:
> > I got a lot of messages while continuous writing / reading datas from one
> > a harddisk to another harddisk (both at 1. ide-channel) during backup
> > with rsync. Both harddisks use udma4. The data-stream was between 0,5
> > MB/s and 20MB/s.
[please remove linux-kernel from the CC and move it to the
more appropriate kernelnewbies list]
On 22 Apr 2001, Francis Litterio wrote:
> I'm reading Rubini's "Linux Device Drivers" and it isn't clear to me
> whether the scheduler runs every time the timer interrupt increments
> jiffies or less
On Sun, Apr 22, 2001 at 10:52:15AM -0400, Francis Litterio wrote:
> Does the scheduler run every time jiffies is incremented?
No, it runs when something needs to be rescheduled (ie, when
the current tasks need_resched element (current->need_resched) is set).
This typically happens when someone wa
Oh, I don't argue about that. (Well, almost--- see below...)
It's just that we need _some_ method for getting over the silly POSIX
FD-handling restrictions... And the negative-FDs may be the solution.
(Note I said we 'can' declare other semantics; not 'should'. So these
FDs can still be normal
In article <[EMAIL PROTECTED]> you wrote:
>> They post on LKM as last resort.
> I tried that, too. It didn't work either.
Most lklm readers ignore posts that look like trolls or are for proposals
they disagree with.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
th
> "Daniel" == Daniel Dorau <[EMAIL PROTECTED]> writes:
Daniel> Hello, my Inspiron 8000 (BIOS A09) notebook running 2.4.3 does
Daniel> not resume after suspending. I have APM compiled in with the
Daniel> following options:
Daniel> - Enable PM at boot time - Make CPU Idle calls whe ide -
Danie
> "Alan" == Alan Cox <[EMAIL PROTECTED]> writes:
Alan> The recommended compilers for non x86 are different too - eg you
Alan> need 2.96 gcc for IA64, you need 2.95 not egcs for mips and so
Alan> on.
In principle you just need 2.7.2.3 for m68k, but someone decided to
raise the bar for all arc
Alan Cox wrote:
> 2.4.3-ac12
> o Further semaphore fixes (David Howells)
Getting unresolved symbols in some modules (notably, for me, microcode.o
and radeon.o)...
Using /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o
/lib/modules/2.4.3-ac12/kernel/drivers/c
Hi,
I'm still working on a packaging system for diskless (quasi-embedded)
devices. The root filesystem is all tmpfs, and I attach packages inside
it. Since symlinks in a tmpfs filesystem cost 4k each (ouch!), I'm
considering using mount --bind for everything. This appears to use very
little me
In case everyone missed my original patch =P
http://marc.theaimsgroup.com/?l=linux-kernel&m=98791931115515&w=2
Jes Sorensen wrote:
>
> > "Alan" == Alan Cox <[EMAIL PROTECTED]> writes:
>
> Alan> The recommended compilers for non x86 are different too - eg you
> Alan> need 2.96 gcc for IA64
On Sun, 22 Apr 2001, David L. Parsley wrote:
> Hi,
>
> I'm still working on a packaging system for diskless (quasi-embedded)
> devices. The root filesystem is all tmpfs, and I attach packages inside
> it. Since symlinks in a tmpfs filesystem cost 4k each (ouch!), I'm
> considering using moun
Horst von Brand <[EMAIL PROTECTED]>:
> > I'm an unusually stubborn and persistent person, as you have cause to
> > know. I really wonder how much good work we've lost because people less
> > stubborn than me simply gave up on the friction costs of trying to identify
> > the responsible person(s)
Russell King <[EMAIL PROTECTED]>:
> I'll grant you that it does solve the "who owns a CONFIG_ symbol", but
> that is only one small problem - there's the bigger problem as to who
> owns each line of code. Are we going to start labelling each source
> code line as well?
Per-file or per-directory
Matthew Kirkwood <[EMAIL PROTECTED]>:
> Eric wants an easy way to find the owner of a CONFIG_ entry.
No, I want much more than that.
--
http://www.tuxedo.org/~esr/">Eric S. Raymond
"This country, with its institutions, belongs to the people who
inhabit it. Whenever they shall gr
Russell King <[EMAIL PROTECTED]>:
> Could that be because there _is no_ maintainer for the config.in files?
> Therefore, splitting up the MAINTAINERS file achieves nothing.
It's not just splitting up the file that I'm advocating. However, as I
said, I'm going to stop arguing and demonstrate,
--
Giacomo A. Catenazzi <[EMAIL PROTECTED]>:
> Alternativelly we can generate MAINTAINER from ESR's map headers.
> In this case we should include this script in the Linus script to
> automagically create the i386 defconfig.
Aha! Somebody is actually *thinking* rather than having a
conservative refl
Alexander Viro <[EMAIL PROTECTED]>:
> Eric, it would save everyone a lot of time if you actually cared to
> pull your head out of your... theoretical constructions and spent
> some efforts figuring out how the things really work.
I've had my nose rubbed in how things really work. That's why I wa
> "Eric" == Eric S Raymond <[EMAIL PROTECTED]> writes:
Eric> Alan Cox <[EMAIL PROTECTED]>:
>> I actually prefer MAINTAINERS because it breaks things down by area
>> and reflects the actual maintainership and areas covered. Something
>> that per file does not
Eric> Instead of arguing this poi
[EMAIL PROTECTED] said:
> I've had my nose rubbed in how things really work. That's why I want
> to fix the things that are broken about how things really work.
Then you're going to conjure up maintainers for the code which is currently
orphaned?
For most stuff, the way to co-ordinate global
David Woodhouse <[EMAIL PROTECTED]>:
> [EMAIL PROTECTED] said:
> > I've had my nose rubbed in how things really work. That's why I want
> > to fix the things that are broken about how things really work.
>
> Then you're going to conjure up maintainers for the code which is currently
> orphaned
On Sun, 22 Apr 2001, Eric S. Raymond wrote:
> Alexander Viro <[EMAIL PROTECTED]>:
> > Eric, it would save everyone a lot of time if you actually cared to
> > pull your head out of your... theoretical constructions and spent
> > some efforts figuring out how the things really work.
>
> I've had
On Sun, Apr 22, 2001 at 02:42:29PM +0100, Matthew Kirkwood wrote:
> On Sun, 22 Apr 2001, Russell King wrote:
> > And what would:
> >
> > C: CONFIG_ARM
> >
> > tell you? Nothing that is not described in the rest of the "ARM PORT"
> > entry.
>
> True, but it would tell it to a script without inter
Alexander Viro <[EMAIL PROTECTED]>:
> Sigh... Would these broken things, by any chance, be "my grand ideas are
> not met with applause"?
Nope. Not at all. Stay tuned, because I'll explain.
And before you write me off as one of the $BIGNUM clueless
visionaries, you might do well to remember tha
On Sun, 22 Apr 2001, Eric S. Raymond wrote:
> David Woodhouse <[EMAIL PROTECTED]>:
> > [EMAIL PROTECTED] said:
> > > I've had my nose rubbed in how things really work. That's why I want
> > > to fix the things that are broken about how things really work.
> >
> > Then you're going to conjure up
On Sun, 22 Apr 2001, Eric S. Raymond wrote:
> And before you write me off as one of the $BIGNUM clueless
> visionaries, you might do well to remember that I actually *have*
> radically changed the world lkml operates in. At least twice.
Let me see ...
1) fetchmail, allowing dialup users to get
> My belief however is that several million people have gcc 2.96-69+, about 50
> are likely to have random cvs snapshots and none of them are going to build
> kernels with them anyway, as they wont work __builtin_expect or otherwise.
>
> Alan
I will not add fuel to the fire, but isn't 2.4.XX the
On 2001.04.22 09:25 John Cavan wrote:
> Alan Cox wrote:
> > 2.4.3-ac12
> > o Further semaphore fixes (David Howells)
>
> Getting unresolved symbols in some modules (notably, for me, microcode.o
> and radeon.o)...
>
> Using /lib/modules/2.4.3-ac12/kernel/drivers/cha
I'm having a problem with "su -" on ac11/ac12. ac5 doesn't show the
problem.
The problem is easy to reproduce - go to a console, log in as root, do an
"su -" (this will succeed) and then another "su -". The second "su -"
should hang - ps shows it started bash and that the bash process is
sleeping.
Hi,
Jes Sorensen wrote:
> In principle you just need 2.7.2.3 for m68k, but someone decided to
> raise the bar for all architectures by putting a check in a common
> header file.
IIRC 2.7.2.3 has problems with labeled initializers for structures,
which makes 2.7.2.3 unusable for all archs under
Recently, I decided to try out Debian 2.2. I downloaded the iso, installed
it, and went to compile kernel 2.4.3. I used the same .config file I've used
before, containing all the appropriate support (ATA66, notably) for my Via
Apollo Pro133A-based motherboard, installed it, and rebooted. To
> "Roman" == Roman Zippel <[EMAIL PROTECTED]> writes:
Roman> Hi, Jes Sorensen wrote:
>> In principle you just need 2.7.2.3 for m68k, but someone decided to
>> raise the bar for all architectures by putting a check in a common
>> header file.
Roman> IIRC 2.7.2.3 has problems with labeled ini
>We are still playing with the VIA fixups, but this may also be VM related.
I'm
>currently playing with several VM ideas, and potential fixes which might
>impact overall performance.
>
>Test 2.4.4pre6 that has the VIA fixes but does not have the VM changes
2.4.4-pre6 did only compile when I aplie
Thanks for your reply. It seems I am finally talking to the right person (I
had previously tried posting this on the pptp-server mailing list, and I
also tried sending it to you directly, but no luck).
> Hmmm... using CCP to negotiate encryption is a Bad Idea IMHO. I know
> Microsoft does, but t
Hello,
I have study the BPF, and I know it calls Socket Filtering in Linux.
(user)
|
(buffer)
|
(BPF)(origin protocol stack)
| |
(Data Link Layer)
Does the buffer above BPF is skb_buff?
If yes, origin protocol stack will get packet from it.
A
Hello from Germany,
I have trouble with a 2.2.18 kernel on a Gigabyte GA 5AX Rev. 5.2
Mainboard.
I have a lot of entrys in /var/log/messages like this:
kernel: probable hardware bug: clock timer configuration lost - probably
a VIA686a.
horst kernel: probable hardware bug: restoring chip configur
In article <01042213394300.23387@athena> you wrote:
> megs/second. So, my question is - why were they so much faster in debian,
> and how can I replicate that in redhat?
What version ? 7.1 tries to take countermeasures against the datacorruption
bugs in the VIA chipsets
-
To unsubscribe fr
Thank You everybody who helped me solve the problem. I found a working
back-up of the superblock at -b 32768 and was able to save all of my
important work from the harddrive. The filesystem was however badly
corrupted and lots of other files were truncated after e2fsck had finished.
So I ended up
I am getting the same message with kernel 2.2.19 on a Vaio 505VE. (Celeron
333 with 128 megs of memory.) I usually see the message when copying
large quantites from the PCMCIA CD-ROM to the hard drive.
On Sun, 22 Apr 2001, Andreas Neidhardt wrote:
> Hello from Germany,
>
> I have trouble with
> This sounds a little like the problem I am seeing with my
> StinkPad 600E, you might want to try enabling CONFIG_APM_ALLOW_INTS
> and see if that makes a difference (thats the magic option required
> for the 600E).
If you have machines which have requirements for specific APM settings please
ru
Wow! Now it not only boots right, the sound distortion problem also seems
to be fixed!!! Great work! However another problem is still here, i see
only one of the two ide-channels of the PDC20265.
>
> On 2001.04.22 10:47 Victor Julien wrote:
>
> > 2.4.4-pre6 did only compile when I aplied the '
Ulrich Drepper wrote:
> "Richard B. Johnson" <[EMAIL PROTECTED]> writes:
>
> > The kernel doesn't know if a process is going to use the FPU when
> > a new process is created. Only the user's code, i.e., the 'C' runtime
> > library knows.
>
> Maybe you should try to understand the kernel code and
> In principle you just need 2.7.2.3 for m68k, but someone decided to
> raise the bar for all architectures by putting a check in a common
> header file.
I suspect you would find that some of the problems with the initialisers
in structures were common to 2.7.2 across all platforms, but I may be
> > Using /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o
> > /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved
> > symbol rwsem_up_write_wake
> > /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved
> > symbol rwsem_down_write_failed
>
> Same thing wit
> 2.4.4-pre6 did only compile when I aplied the '__builtin_expect'-patch. It
> crashed at boot however, when initializing my onboard raidcontroller
> (PDC20265 on a MSI K7T Turbo-R). It seems to be the same problem as
> reported by Manuel A. McLure. So no word yet about the sound
> distortion-prob
> Wow! Now it not only boots right, the sound distortion problem also seems
> to be fixed!!! Great work! However another problem is still here, i see
> only one of the two ide-channels of the PDC20265.
There is a possible patch for that in the Red Hat source rpm but its a bit
ugly. I need to figu
On 2001.04.22 11:48 Alan Cox wrote:
> > > Using /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o
> > > /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved
> > > symbol rwsem_up_write_wake
> > > /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved
> > > sym
> OK, regardless of how the linux kernel actually manages the FPU for user-space
>
> programs, does anybody have any comments on the original bugreport?
Complete mystification.
> >of pi begins to look wrong. Then kill everything and run pi by itself
> >again. It will no longer produce good re
Alan Cox wrote:
> > > Using /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o
> > > /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved
> > > symbol rwsem_up_write_wake
> > > /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved
> > > symbol rwsem_down_write
Rik van Riel <[EMAIL PROTECTED]>:
> Let me see ...
>
> 1) fetchmail, allowing dialup users to get lkml
> 2) getting snake.thyrsus.com out of ORBS and starting
>the mother of all lkml threads
>
> Did I forget anything ?
Yes, Rik, you did. It's not `snake', it's `snark'.
:-)
--
> And before you write me off as one of the $BIGNUM clueless
> visionaries, you might do well to remember that I actually *have*
> radically changed the world lkml operates in. At least twice.
I must have missed them 8)
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-ker
On Sun, Apr 22, 2001 at 01:27:20AM +0100, D . W . Howells wrote:
> This patch (made against linux-2.4.4-pre6) makes a number of changes to the
> rwsem implementation:
>
> (1) Fixes a subtle contention bug between up_write and the down_* functions.
>
> (2) Optimises the i386 fastpath implementa
On Sun, 22 Apr 2001, Eric S. Raymond wrote:
> Alexander Viro <[EMAIL PROTECTED]>:
> > Sigh... Would these broken things, by any chance, be "my grand ideas are
> > not met with applause"?
>
> Nope. Not at all. Stay tuned, because I'll explain.
>
> And before you write me off as one of the $B
On Sun, Apr 22, 2001 at 09:07:03PM +0200, Andrea Arcangeli wrote:
> On Sun, Apr 22, 2001 at 01:27:20AM +0100, D . W . Howells wrote:
btw, I noticed I answered your previous email but for my benchmarks I really
used your latest #try2 posted today at 13 (not last night a 1am), just to avoid
mistake
Hi,
I'm using kernel-2.4.3 and pcmcia-cs-3.1.25.
The kernel module is called ide-cs while the pcmcia-cs package
looks for ide_cs. I'm not sure which should be corrected...
Rui Sousa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PR
In article <[EMAIL PROTECTED]> you wrote:
> The kernel module is called ide-cs while the pcmcia-cs package
> looks for ide_cs. I'm not sure which should be corrected...
pcmcia-cs I'd say.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAI
On Sun, Apr 22, 2001 at 01:53:59PM +0200, [EMAIL PROTECTED] wrote:
> Hi!
>
> why doesnt the dma for ide disks show up in /proc/dma?
>
> heineken:~# hdparm -d /dev/discs/disc0/disc
> /dev/discs/disc0/disc:
> using_dma= 1 (on)
>
> heineken:~# cat /proc/dma
> 4: cascade
I suspect this is
On 04.22 Dieter Nützel wrote:
> > My belief however is that several million people have gcc 2.96-69+, about 50
> > are likely to have random cvs snapshots and none of them are going to build
> > kernels with them anyway, as they wont work __builtin_expect or otherwise.
> >
> > Alan
>
> I will no
Something which came up in one of the hallway discussions at the
kernelsummit was that a lot of the architecture maintainers would find
it more convenient if the arch-specific header files were moved from
include/asm-$ARCH to arch/$ARCH/include. Since we use a symlink _anyway_,
no global changes
On Sun, Apr 22, 2001 at 11:22:24AM +0200, Hermann Himmelbauer wrote:
> Karsten Keil wrote:
> >
> > I have here the same board with 2*233 MMX and don't see this kind of ISDN
> > error on recent 2.2 kernels, but got also lot of APIC errors with the
> > 2.3/2.4, because the APIC errors are only repo
> * you've ignored the robustness of design behind the UNIX kernel.
> These beasts keep going without falling apart even after serious injuries.
Do you mean design or operation? In fact UNIX design has a number of
serious errors/problems, we just have gotten accustomed to it so much
that we
Hello,
Linux 2.2.19 SMP, confirm report. Even games are going weird after
running this test, (my wife is complaining :-))
Have to reboot.
Kees
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http:/
Hello David Hinds, Hello Kernelhackers,
sorry that I also directly contact you.
But I'am very confused, at the moment.
My Hardware:
Toshiba Satellite Pro 4280
PCMCIA: Xircom RBEM56G-100
When I use SuSE 7.1 and Kernel 2.4.2 (SuSE) the card
is recognized and network works, also configured vi
[EMAIL PROTECTED] said:
> Would anyone have a problem with this change?
UML already has a arch/um/include for private headers that the rest of the
kernel is not allowed to see.
It would mean moving it, which is not a big deal.
Jeff
-
To unsubscribe from this
Hi,
cmsfs does not compile without this fix.
Andrzej
diff -ur linux-2.4.3-ac12/fs/cmsfs/cmsfsvfs.c linux/fs/cmsfs/cmsfsvfs.c
--- linux-2.4.3-ac12/fs/cmsfs/cmsfsvfs.cSun Apr 22 14:48:52 2001
+++ linux/fs/cmsfs/cmsfsvfs.c Sun Apr 22 16:18:40 2001
@@ -26,6 +26,7 @@
#include
#in
Hi,
CONFIG_PPP_FILTER depends on CONFIG_FILTER (2.4.4-pre6, 2.4.3-ac12)
[ sk_run_filter(), ...]
So updated Config.in ...
Andrzej
diff -ur drivers/net/Config.in.old drivers/net/Config.in
--- drivers/net/Config.in.old Sun Apr 22 14:48:51 2001
+++ drivers/net/Config.in Sun Apr 22 16:24:10
In fs/open.c I see the following code in sys_utime in case the struct
utimbuf * is NULL:
if (current->fsuid != inode->i_uid &&
(error = permission(inode,MAY_WRITE)) != 0)
goto dput_and_out;
In sys_utimes, there is a similar piece of cod
Hi list,
can I assume that a member of a structure of type atomic_t is 0 after using
memset to zero on the structure ?
TIA
Oliver
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info a
> can I assume that a member of a structure of type atomic_t is 0 after
> using memset to zero on the structure ?
You must not do this. use atomic_init instead. on parisc, the locked value
of a spinlock is 0, so no more updates to that atomic value would ever work.
--
Revolutions do not requ
If I configure PCMCIA out of the build, the build will not link,
because the linker is still looking for the net_pcmcia.o file.
If I say yes for PCMCIA and enable a single module, it works.
compile configuration available if someone would like to see it.
Thanks,
Ben
--
Ben Greear ([EMAIL PROT
Hello Alan , To whom is this attributed ? Tia , JimL
On Sun, 22 Apr 2001, Alan Cox wrote:
> o Hopefully fix bugtraq reported netfilter ftp
> flaw
++
| James W. Laferriere | System Techniques |
Hello Andrea,
Interesting benchmarks... did you compile the test programs with "make
SCHED=yes" by any chance? Also what other software are you running?
The reason I ask is that running a full blown KDE setup running in the
background, I get the following numbers on the rwsem-ro test (XADD opt
Q> scripts/Menuconfig: MCmenu39: command not found
Please report this to the maintainer <[EMAIL PROTECTED]>. You may also
send a problem report to <[EMAIL PROTECTED]>.
Please indicate the kernel version you are trying to configure and
which menu you were trying to enter when this error occur
There is a bit more clarity on the performance degradation
issue now - In fact the degradation only appears when
using iptables. It's just that sometime shortly after 2.4.2,
the hit imposed by iptables got worse.
For instance:
netperf results without iptables with iptables
---
"Eric S. Raymond" <[EMAIL PROTECTED]> said:
> Alexander Viro <[EMAIL PROTECTED]>:
> > Eric, it would save everyone a lot of time if you actually cared to
> > pull your head out of your... theoretical constructions and spent
> > some efforts figuring out how the things really work.
>
> I've had my
Horst von Brand <[EMAIL PROTECTED]>:
> Then explain to everybody here in a language they'll understand _what_ is
> wrong and _why_. Then propose a solution.
I'm on it. You'll see the results fairly shortly.
--
http://www.tuxedo.org/~esr/">Eric S. Raymond
Strict gun laws are abo
A little while ago I was playing with building an elf self extracting
binary. In doing so I discovered that the linux kernel does not
handle elf program headers with multiple BSS segments.
Eric
Binary files linux-2.2.19/drivers/char/conmakehash and linux-2.2.19.elf-fix/drivers/char/conmakeha
Andrzej Krzysztofowicz writes:
> CONFIG_PPP_FILTER depends on CONFIG_FILTER (2.4.4-pre6, 2.4.3-ac12)
> [ sk_run_filter(), ...]
> So updated Config.in ...
> - bool ' PPP filtering' CONFIG_PPP_FILTER
> + dep_bool ' PPP filtering' CONFIG_PPP_FILTER $CONFIG_FILTER
Yep, definitely a good idea.
Alan Cox wrote:
>
> > > Using /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o
> > > /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved
> > > symbol rwsem_up_write_wake
> > > /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved
> > > symbol rwsem_down_wri
Tim Wilson writes:
> Thanks for your reply. It seems I am finally talking to the right person (I
> had previously tried posting this on the pptp-server mailing list, and I
> also tried sending it to you directly, but no luck).
Sorry, life has been a little turbulent for me over the last couple o
On Sun, Apr 22, 2001 at 11:52:29PM +0100, D . W . Howells wrote:
> Hello Andrea,
>
> Interesting benchmarks... did you compile the test programs with "make
> SCHED=yes" by any chance? Also what other software are you running?
No I never tried the SCHED=yes. However in my modification of the rws
On Mon, Apr 23, 2001 at 03:04:41AM +0200, Andrea Arcangeli wrote:
> that is supposed to be a performance optimization, I do the same too in my code.
ah no I see what you mean, yes you are hurted by that. I'm waiting your #try 3
against pre6, by that time I hope to be able to make a run of the ben
Byeong-ryeol Kim writes:
> I met 'unresolved symbol sk_chk_filter ...' after applying this patch
> and rebooting.( with CONFIG_PPP_FILTER=y )
> There shoud be folling lines in linux/net/netsyms.c or so:
>
> #ifdef CONFIG_PPP_FILTER
> EXPORT_SYMBOL(sk_chk_filter);
> #endif
Good idea, actually le
1 - 100 of 137 matches
Mail list logo
