On Mon, 16 Oct 2000, Keith Owens wrote:
> On Sun, 15 Oct 2000 09:57:08 -0700,
> Miles Lane <[EMAIL PROTECTED]> wrote:
> >> On Mon, 16 Oct 2000 14:30:39 +1000,
> >> "Mike McLeod" <[EMAIL PROTECTED]> wrote:
> >> >All of the code is open except for an image file that is loaded
> >> >onto the card
On Sun, Oct 15, 2000 at 06:25:34PM -0700, J. S. Connell wrote:
> Any time I disconnect and then reconnect the ethernet cable from my Netgear
> FA310TX cards, the card appears to not notice and doesn't reestablish the
> link. Under 2.2.17pre4, the link light comes on, but until I do ifconfig
>
Problem fixed (installed RH7). Thanks for the help (with OT stuff, no
less).
--A
-==*==-
Alison Stewart (aka Luna Torquill)
http://www.strappe.com/arcturus/
"I may regret what I have lost, but
I will not regret what I have become."
Thanks, all, for the education.
Sounds like I got this wrong.
Miles
Keith Owens wrote:
>
> On Sun, 15 Oct 2000 09:57:08 -0700,
> Miles Lane <[EMAIL PROTECTED]> wrote:
> >> On Mon, 16 Oct 2000 14:30:39 +1000,
> >> "Mike McLeod" <[EMAIL PROTECTED]> wrote:
> >> >All of the code is open
From: Marty Fouts <[EMAIL PROTECTED]>
Date:Sun, 15 Oct 2000 22:03:58 -0700
The end user of a computer system cares about the *entire*
performance of that system, not just the kernel.
This entire paragraph is %100 true, however it does ignore the
possibility that what these
On Sun, 15 Oct 2000 09:57:08 -0700,
Miles Lane <[EMAIL PROTECTED]> wrote:
>> On Mon, 16 Oct 2000 14:30:39 +1000,
>> "Mike McLeod" <[EMAIL PROTECTED]> wrote:
>> >All of the code is open except for an image file that is loaded
>> >onto the card when the driver is installed that handles it's
>>
On Mon, Oct 16, 2000 at 12:23:13AM -0400, Mark Hahn wrote:
> > are there any known issues with programs like top/free etc displaying
> > memory etc used incorrectly... this bis the output from one of our machines
>
> no. but why ponder: /proc/net/meminfo is the horses mouth.
>
> >
As several people are sure to remind me, the Linux Kernel mailing list is
not the right forum for a discussion on language choice and the impact on
kernel development, but as this is not the first time I've followed this
class of argument, I'd like to make a couple of general observations that I
hi,
i need to change the parent of a process, basically i
need to kill a process in between in a family of
processes and change the parent of a process to a
process one level higher.
any idea as to how this could be done.
thanks
ksr
__
Do You
> On Mon, 16 Oct 2000 14:30:39 +1000,
> "Mike McLeod" <[EMAIL PROTECTED]> wrote:
> >All of the code is open except for an image file that is loaded
> >onto the card when the driver is installed that handles it's
> >logic. From here, how do we begin the process of getting our
> >drivers
"Jeff V. Merkey" wrote:
>
> Eray Ozkural wrote:
> >
> > I don't how you would do such a thing in C++. Allocators and the
> > stuff I talked about make it more efficient and safer to manage
> > memory. They don't throw memory calls all over the place. :P
>
> More routines touching more memory on
Linus Torvalds wrote:
>> In article <[EMAIL PROTECTED]>,
>> <[EMAIL PROTECTED]> wrote:
>> >
>> >I have a user buffer and i want to map it to kernel address space
>> >can anyone tell how to do this like in AIX we have xmattach
>
>> Note that it is usually MUCH better to do this the other way
that would be great if you could give me some instructions on generating a
patch
and updating the kernel. Thanks
regards
Mike
ps. I can't seem to mail you directly
- The following addresses had permanent fatal errors -
<[EMAIL PROTECTED]>
- Original Message -
From:
On Mon, 16 Oct 2000 14:30:39 +1000,
"Mike McLeod" <[EMAIL PROTECTED]> wrote:
>The company I work for has developed a new piece of hardware, and we are
>eager to have the drivers for this hardware included as part of the
>Linux kernel. Currently, we have customers who have been using our
Hi, i've made this little patch against drivers/char/drm/proc.c to
enable dual head in /proc/dri. I'm quite sure
that it's not SMP safe, so if anybody could give a look. Anyway it
worked for me.
*** proc.c.orig Mon Oct 16 00:45:53 2000
--- proc.c Mon Oct 16 03:42:30 2000
***
***
"J . A . Magallon" <[EMAIL PROTECTED]> said:
[...]
> But there are some features of C++ that would be of great value for kernel
> development (in general for imperative programming), for example:
> - args : dont break your untouchable data, and get rid of
> pointer mess
It isn't _that_
Hello,
The company I work for has developed a new piece of
hardware, and we are eager to have the drivers for this hardware included as
part of the Linux kernel. Currently, we have customers who have been using
our product for a couple of months, and so far we have had no problems.
All
On Mon, Oct 16, 2000 at 01:27:25AM +0100, Alan Cox wrote:
> -=usb backport (no effect if you say no to usb)
Alan --
As the USB Mass Storage driver maintainer, I'd like to ask you to mark the
USB Mass Storage driver as EXPERIMENTAL for the 2.2.x kernel series.
This is an unsupported, known
Any particular reason why the new asm-m68k/*.h headers ended up under
asm-i386? :-)
I know this makes more work for you Alan, but all of these silly
errors (bogus reject files left in the tree, mistakedly leaving
vmlinux.lds autogenerated files in the tree, etc.) would have a
minuscule chance
Eray Ozkural wrote:
>
> "Jeff V. Merkey" wrote:
> > There are some elements that are attractive, but overall, why would a
> > device thread want to allocate memory from an interrupt
>
> I don't how you would do such a thing in C++. Allocators and the
> stuff I talked about make it more
"Jeff V. Merkey" wrote:
> There are some elements that are attractive, but overall, why would a
> device thread want to allocate memory from an interrupt
I don't how you would do such a thing in C++. Allocators and the
stuff I talked about make it more efficient and safer to manage
memory. They
Alan Cox wrote:
>
> > is in cdrecord itself, since I have seen that if the FIFO ever hits 0%
> > during CD burning, cdrecord has a tendency to bomb. =20
>
> If you empty the fifo and the drive fifo you burn a coaster. Thats a feature
> of CD burning and one reason I use 640Mb magneto opticals
C++ in kernel development should be discouraged in general. Structured
Exception handling would be a nice C++ implementation in Linux, and the
way the FS is using the name : function construct for the VFS function
tables is very nice as well since we don't have to align the strucures.
There
"J . A . Magallon" wrote:
> I agree that C++ for kernel is not a good idea, libstdc++ should be in the
> kernel,
> code would be bigger, there's a complicated runtime under C++ doing things
> by itself (copy constructors-operators and so on), inheritance adds some
> little calling overhead.
>
I'm seeing a similar problem with the Xircom Realport card
which uses the 'xircom_tulip_cb' driver.
Workaround:
Putting the card into promiscuous mode seems to get it going again.
If feels like (but I haven't investigated further) the ARP table isn't
being updated properly.
This was
hey,
Apologies if this has been brought up before...
are there any known issues with programs like top/free etc displaying
memory etc used incorrectly... this bis the output from one of our machines
with dual pIII 450's and 5½2MB ram...
roady@matrix:~$
Richard B. Johnson wrote..
> Robert Kaiser didn't write this. I did.
You and a few hundred other embedded systems programmers.
> FYI, the code that was submitted can't possibly work (it was backwards).
> If it made your board 'work' there is something else broken.
What do you mean backwards?
"J. S. Connell" wrote:
>
> Any time I disconnect and then reconnect the ethernet cable from my Netgear
> FA310TX cards, the card appears to not notice and doesn't reestablish the
> link. Under 2.2.17pre4, the link light comes on, but until I do ifconfig
> ethX down; ifconfig ethX up, the kernel
"Jeff V. Merkey" wrote:
>
> The [new] and constructor/destructor operations create hidden memory
> allocations in C++ that can blow performance in kernel "fast paths".
That is designed to decrease the number of syscalls, not to increase
them. Besides, in a successful C++ design memory
Any time I disconnect and then reconnect the ethernet cable from my Netgear
FA310TX cards, the card appears to not notice and doesn't reestablish the
link. Under 2.2.17pre4, the link light comes on, but until I do ifconfig
ethX down; ifconfig ethX up, the kernel ignores any traffic on that
On Sun, Oct 15, 2000 at 03:48:55PM -0400, Jeff Garzik wrote:
> Changes:
> * both: we know we are in an interrupt, so
> s/spin_lock_irqsave/spin_lock/
There request_irq is not called passing the SA_INTERRUPT flag so the irq
handler is recalled with irqs enabled and in turn irqsave is necessary.
On Sun, 15 Oct 2000, Andrew Morton wrote:
> There is a bug in gcc-2.7.2.3. It incorrectly lays out
> structure initialisers when the `name:value;' construct is used.
>
>
> Here is the degenerate case:
>
> struct struct_1 { int a; };
>
> struct thing {
> int a;
>
On Mon, 16 Oct 2000 02:06:05 Jeff V. Merkey wrote:
>
>
> The [new] and constructor/destructor operations create hidden memory
> allocations in C++ that can blow performance in kernel "fast paths".
> Writing kernel code in C++ is never a good idea because of this problem,
I agree that C++ for
On Mon, Oct 16 2000, Mark Cooke wrote:
> Identifikation : 'CD-Writer+ 7100 '
>
> Blanking entire disk
> CDB: A1 00 00 00 00 00 00 00 00 00 00 00
> cdrecord: Input/output error. blank unit: scsi sendcmd: retryable error
> Sense Bytes: F0 00 05 00 00 00 00 19 00 02 89 16 A1 10 00 80
> status: 0x2
> is in cdrecord itself, since I have seen that if the FIFO ever hits 0%
> during CD burning, cdrecord has a tendency to bomb. =20
If you empty the fifo and the drive fifo you burn a coaster. Thats a feature
of CD burning and one reason I use 640Mb magneto opticals for testing CD
stuff
> >
On Sun, 15 Oct 2000, Robert Kaiser wrote:
> > The AMD/Elan box snoops for the sequence sent to the keyboard
> > controller to enable A<20>.
>
Robert Kaiser didn't write this. I did. And yes. It makes no difference
about the 'board' it's in the chip.
> Are you sure this is true of all boards
Ok so Im back and its time to shift the backlog. Nothing too bad has come up
so far. This merges the pending DSL driver and NFSv3 patches and fixes
further bugs along the way. The big chunk is the m68k patches which dont
touch non m68k code.
Various folks have commented on the size of the
This is bad. I am seeing problems as well, but speed=2 and even speed=4
are working here non 2.2.18 with both CDRW and CD-RW/DVD Ram. You may
have a hardware problem of some type, or perhaps the bug is more easily
reproducable for you. I have noticed that perhaps some of the problem
is in
The [new] and constructor/destructor operations create hidden memory
allocations in C++ that can blow performance in kernel "fast paths".
Writing kernel code in C++ is never a good idea because of this problem,
and the fact that with function overloading, it's possible for someone
to write
Hi all,
Just to follow up on an earlier message / thread. I've updated to
2.2.18pre15 on the machine (dual celeron, gigabyte 6bxd) I was having
trouble writing CDRWs to, and it has made no difference,
unfortunately.
With the same tools / os on my other cdrw equipped machine
(k7/up/ricoh 9060)
Sorry for the delay, the docking station in question is a few kilometers
away.
On Fri, 13 Oct 2000, Linus Torvalds wrote:
> And I don't find any code that would ever have done this, either. It must
> be somewhere, if 2.2 works for you.
>
I can put up the 2.2 bootup with DEBUG in pci.c if
hi,
i recently got a Sun Sparcstation 2, (sun4c)
and am wondering whether the memory issues that i had heard about linux
having on sun4c have been fixed?
Thanks
David F.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
On Sun, Oct 01, 2000 at 12:45:47PM -0700, LA Walsh wrote:
> Forgive me if this has been asked before, but has there ever been any
> thought of having a 'nice' value for disk accesses?. I was on a
> server with 4 CPU's but only 2 SCSI disks. Many times I'll see 4 processes
> on disk wait, 3 of
On Fri, Oct 13, 2000 at 02:23:44PM -0700, Linus Torvalds wrote:
> Note that it would be nicer to _not_ do the page fault case anyway, and
> just extend on the current special case of one PGD entry - just make that
> one PGD entry be two, and pre-allocate the (one) PMD entry that you use
> for SRM
On Sun, 15 Oct 2000, Alan Cox wrote:
> > or to write a "drmfs" (Al Viro's suggestion) or to abandon the original
> > design of not-sharing the code and do share it (my suggestion but of
> > course it's up to Rick and other maintainers of that code -- they know
> > better how to make their own
> or to write a "drmfs" (Al Viro's suggestion) or to abandon the original
> design of not-sharing the code and do share it (my suggestion but of
> course it's up to Rick and other maintainers of that code -- they know
> better how to make their own life easier).
Or you write a very thin
On Sun, Oct 15, 2000 at 09:45:11PM +0100, Alan Cox wrote:
> > Well, we ain't got these luxuries/complications in VAXland... Hell,
> > we don't even have two-level page tables :-(
>
> Really. Ugh. I always assumed Vax had at least two levels because mmap on
> 4.2 BSD used to panic on 128K+
> On Sun, Oct 15, 2000 at 05:18:29AM -0400, Mike A. Harris wrote:
> > I just built a new kernel, installed, ran lilo, rebooted, and it
> > gets to "Uncompressing Linux" and hangs dead.
>
> I'm expreiencing the same thing on my VAIO PCG-C1XD notebook
> (using RH7 [yes, i know about kgcc]).
>
Tigran Aivazian wrote:
> Hi David,
>
> Yes, this is a well-known problem and was briefly discussed between Rick
> Faith, Al Viro and myself. The thing is that DRI design dictates
> duplication of the code instead of sharing it between individual low-level
> drivers (this is not silly -- there
On Sun, Oct 15, 2000 at 05:09:37PM +0200, Erik Mouw wrote:
> (Second try, this time with the correct mailing list address. Duh.)
>
> Hi,
>
> This patch makes the X and Y resolution in drivers/input/mousedev.c a
> module parameter. In this way the screen resolution can be set by
> using:
>
>
On Sat, Oct 14, 2000 at 07:17:57PM -0700, Linus Torvalds wrote:
>
>
> On Sat, 14 Oct 2000, Rogier Wolff wrote:
> > > Note that it is usually MUCH better to do this the other way around:
> > > having a kernel-side buffer, and mapping that into user space. I don't
> > > understand why so many
just to add one more detail -- your comparison with /proc/irq is
superficial, i.e. only looks the same on the surface but not when you look
in depth. The case with /proc/irq was a bug whilst here we have a design
that dictates this behavior (but can possibly be worked around)
On Sun, 15 Oct
Hi David,
Yes, this is a well-known problem and was briefly discussed between Rick
Faith, Al Viro and myself. The thing is that DRI design dictates
duplication of the code instead of sharing it between individual low-level
drivers (this is not silly -- there are lots of valid reasons for this as
Hi,
On Sun, 15 Oct 2000, Andi Kleen wrote:
> You can just use the coded out variant (x<>(sizeof(x)*8-n)))
> gcc is clever enough to turn it into an rotate when the CPU supports it.
Hmm, I just tried it and two things one should take care of here. 1. x
must be unsigned of course and 2. only
Hi,
I've just got a look at file drivers/char/drm/proc.c, correct me if
i'm wrong but
when registering using "drm_proc_init" each device supporting drm duplicates
the dri dir entry, as "create_proc_entry " blindly create a new dri entry
even if one already exists.
IIRC a few month ago the same
Hi,
On Sun, 15 Oct 2000 [EMAIL PROTECTED] wrote:
[...snip...]
> What happens if you try the following patch instead? The original
> out-of-memory behaviour seems a bit bogus to me. This patch is untested,
> but should work.
I applied this patch and the box didn't reboot or hang during my
On Sun, Oct 15, 2000 at 04:35:13AM -0500, Brian Parris wrote:
> I apologise if this is the wrong place for this, but i've been searching for
Well... the list is about kernel develoment, so it is a bit off-topic.
> 3 weeks for a way to record the bandwidth used by each user under 2.2.17, i
>
On Sun, Oct 15, 2000 at 05:18:29AM -0400, Mike A. Harris wrote:
> I just built a new kernel, installed, ran lilo, rebooted, and it
> gets to "Uncompressing Linux" and hangs dead.
I'm expreiencing the same thing on my VAIO PCG-C1XD notebook
(using RH7 [yes, i know about kgcc]).
Exactly the
Hi Linus,
In an ideal work (free of bugs) notify_change() can never receive a
negative dentry because it would subsequently oops in
inode_change_ok() when dereferencing inode->i_uid. Therefore:
a) instead of oopsing in inode_change_ok() and having to trace the reason
back to notify_change() it
[EMAIL PROTECTED] wrote:
>
> On Sun, 15 Oct 2000, Shane Shrybman wrote:
> > I applied these changes to 2.4.0-test10-pre3 and I got these messages in
> > the system log:
> >
> > Oct 15 11:24:05 mars kernel: __alloc_pages: 5-order allocation failed.
> > Oct 15 11:24:05 mars kernel: eth0: Memory
> You mean like the way the Alpha has a PTE bit that says 'this page is
> valid at the same address in every process', and the address space
> number (ASN) that can be used to 'uniquefy' cache entries for the
> same virtual addresses in different processes?
Exactly
> Well, we ain't got these
On Sun, 15 Oct 2000, Shane Shrybman wrote:
> I applied these changes to 2.4.0-test10-pre3 and I got these messages in
> the system log:
>
> Oct 15 11:24:05 mars kernel: __alloc_pages: 5-order allocation failed.
> Oct 15 11:24:05 mars kernel: eth0: Memory squeeze, dropping packet.
> Oct 15
On Sun, Oct 15, 2000 at 09:22:58PM +0100, Alan Cox wrote:
> > > or you have a sane memory management model with tags/spaces then its a non issue
> >
> > You've lost me here. Tags/spaces?
>
> A lot of memory management hardware allows you to build page tables that contain
> more than just the
Hi Linus and Alexander,
The fs/super.c:kill_super() function can be simplified to return 'void'
and also caching sb->s_op and sb->s_type makes the code more readable.
Regards,
Tigran
--- linux/fs/super.cMon Sep 25 21:13:53 2000
+++ work/fs/super.c Sun Oct 15 21:18:56 2000
@@ -884,24
> > or you have a sane memory management model with tags/spaces then its a non issue
>
> You've lost me here. Tags/spaces?
A lot of memory management hardware allows you to build page tables that contain
more than just the addresses. Instead a tag register or the processor state
or both are
Hi Linus and Rik,
The last for(;;) loop in mm/page_allo.c:__alloc_pages() looks strange to
me:
for (;;) {
struct page * page = NULL;
...
if (direct_reclaim)
page = reclaim_page(z);
if (page)
On Sun, Oct 15, 2000 at 08:35:46PM +0100, Alan Cox wrote:
> > I understand that 2.4 no longer maps all physical memory as 2.2
> > and earlier used to do.
>
> Its really up to you if you choose to do that or not. If you have enough
> address space to create all your virtual and physical mappings
Changes:
* both: we know we are in an interrupt, so
s/spin_lock_irqsave/spin_lock/
* both: kbd_controller_lock is local to the module, mark it 'static'
* pc_keyb: move the printk out of the loop
--
Jeff Garzik| The difference between laziness and
Building 1024
> I understand that 2.4 no longer maps all physical memory as 2.2
> and earlier used to do.
Its really up to you if you choose to do that or not. If you have enough
address space to create all your virtual and physical mappings without problems,
or you have a sane memory management model with
On Sun, Oct 15, 2000 at 08:07:06PM +0200, Andi Kleen wrote:
> On Sun, Oct 15, 2000 at 05:29:46PM +0100, Kenn Humborg wrote:
> >
> >
> > __pa() and __va() are still defined as addr -/+ PAGE_OFFSET. So
> > where did I hear about 2.4 not mapping all memory? Could it be
> > that this applies only
On Fri, Oct 13, 2000 at 09:16:36PM +0200, Erik Mouw wrote:
> On Fri, Oct 13, 2000 at 10:27:05AM -0700, Dunlap, Randy wrote:
> > How about trying latency_timer=10, which will apparently
> > show up as being 0 (since 10 is smaller than its
> > implemented granularity).
>
> That didn't help, but I
Andi Kleen writes:
> On Sun, Oct 15, 2000 at 05:29:46PM +0100, Kenn Humborg wrote:
> >
> >
> > __pa() and __va() are still defined as addr -/+ PAGE_OFFSET. So
> > where did I hear about 2.4 not mapping all memory? Could it be
> > that this applies only to "high memory" in x86?
>
> It only
Hi!
> 7. Obvious Projects For People (well if you have the hardware..)
>
> * Make syncppp use new ppp code
> * Fix SPX socket code
USB: plusb is b0rken.
Pavel
--
I'm [EMAIL PROTECTED] "In my country we have almost
Hello,
I was told that I should see if the bug is repeatable with a vanilla gcc
(and not pgcc).
/proc/version is now:
Linux version 2.4.0-test9-my-fb ([EMAIL PROTECTED])
(gcc version 2.7.2.3) #26 SMP Son Okt 15 18:50:40 CEST 2000
The other information stays the same.
bye
Gert
PS: Pleas
Hi guys,
Quite a few cases of the usage of smp_call_function() (generic call
function IPI) look like:
smp_call_function(function, info,...);
function(info);
i.e. we invoke it on all other cpus and then on this cpu. The examples are
flush_tlb_all() and do_microcode_update() (possibly others, I
On Sun, Oct 15, 2000 at 05:29:46PM +0100, Kenn Humborg wrote:
>
>
> __pa() and __va() are still defined as addr -/+ PAGE_OFFSET. So
> where did I hear about 2.4 not mapping all memory? Could it be
> that this applies only to "high memory" in x86?
It only applies to high memory. To access it
I have a program that reads and prints /proc/loadavg once per second
(look below). Note that the file is reopened for each read operation.
I'm mainly interested in the fourth value, i.e., the number of processes
in the run queue. Its initial value is one. After starting a cpu-intensive
background
I too was having this problem from 2.4.0-test5 to 2.4.0-test9.
2.4.0-test10-pre1 appears to have corrected it (so far at least). I am
indeed using a half duplex 10mbs LAN, but there are really only 2 hosts
transmitting, me and my NFS server (Well, my ISDN router too, but all
things considered
On Sun, Oct 15, 2000 at 06:03:40PM +0200, Erik Mouw wrote:
> On Sun, Oct 15, 2000 at 04:24:45PM +0100, Kenn Humborg wrote:
> > I understand that 2.4 no longer maps all physical memory as 2.2
> > and earlier used to do.
> >
> > Is there any documentation on this change and how it affects
> >
On Sun, Oct 15, 2000 at 04:24:45PM +0100, Kenn Humborg wrote:
> I understand that 2.4 no longer maps all physical memory as 2.2
> and earlier used to do.
>
> Is there any documentation on this change and how it affects
> arch-specific code?
>
> Specifically, we've been basing the VAX port on
On Sun, 15 Oct 2000 [EMAIL PROTECTED] wrote:
> Hi!
>
> Instead of checking all possible error bits, the RxStatusOK bit should be
> checked. I encounter rx_status==0 when I stress my P90, which gives a
> negative packet size (-4), and an oops in eth_copy_and_sum.
>
> Applies to
[EMAIL PROTECTED] wrote:
>
> I know it crashes some via chipsets when autotuning (IIRC), but
> if it were added behind CONFIG_EXPERIMENTAL it couldn't do any
> harm, could it?
>
> I stuck between HPT370 support in 2.4.x but non-working isdn lzs
> compression code and the reverse in 2.2.x. Just
I understand that 2.4 no longer maps all physical memory as 2.2
and earlier used to do.
Is there any documentation on this change and how it affects
arch-specific code?
Specifically, we've been basing the VAX port on 2.2 while waiting
for 2.4 to stabilize. Now we're looking at moving to 2.4.
Alison Stewart wrote:
>
> We built a new system a little while ago, and have been trying to track
> down a problem. There's a stock Red Hat 6.2 install on it (Athlon 700
> Thunderbird, Asus A7V board, 128M RAM). Windows runs fine, go figure.
>
> The system crashes on boot of the linux
(Second try, this time with the correct mailing list address. Duh.)
Hi,
This patch makes the X and Y resolution in drivers/input/mousedev.c a
module parameter. In this way the screen resolution can be set by
using:
modprobe mousedev xres=1280 yres=1024
The configure-time resolution is used
On Sun, Oct 15, 2000 at 03:35:36PM +0200, Harald Welte wrote:
> Hi!
>
> In the 2.2 series kernel are some fucntions for rotating left / right.
>
> But it seems that the generic_rotr32 / generic_rotl32 as well as the
> architecture dependent counterparts rotr32 /rotl32 have disappeared.
>
> Is
> down a problem. There's a stock Red Hat 6.2 install on it (Athlon 700
> Thunderbird, Asus A7V board, 128M RAM). Windows runs fine, go figure.
Easy to figure alas
> The system crashes on boot of the linux partition. Unfortunately, this
> does mean that we haven't been able to run ksymoops
Hi!
In the 2.2 series kernel are some fucntions for rotating left / right.
But it seems that the generic_rotr32 / generic_rotl32 as well as the
architecture dependent counterparts rotr32 /rotl32 have disappeared.
Is ther any replacement, and if yes, where ?
thanks.
--
Live long and prosper
Hi,
I've read a summary of a discussion about C++ module writing on
this list, and I'd like to make some comments on it. [I'm not
subscribed to this list, please retain a Cc: to my address]
To rephrase, Stepan Kasal had started writing a C++ kernel module
and while including kernel headers he
Michael Meding wrote:
> that's what redhat support is for. They should have told you that there
> is an issue with the supplied kernel and durons and thunderbirds.
That's if I had a registered box of RH6.2 and thus had access to RH
support I figured that if there were a serious conflict
Date: Sun, 15 Oct 2000 23:55:12 +1100
From: Andrew Morton <[EMAIL PROTECTED]>
Option 1
--- linux-2.4.0-test10-pre3/net/ipv4/tcp_ipv4.c Sat Oct 14 17:02:04 2000
+++ linux-akpm/net/ipv4/tcp_ipv4.c Sun Oct 15 23:47:57 2000
Patch applied, thanks.
Later,
David S.
"David S. Miller" wrote:
>
> The soltuion you have chosen is not acceptable, the ordering is
> critical and is why all of this stuff is done this way in the first
> place. The members must be in _that_ order and the alignment must
> occur at that precise spot.
Yes, I know. But that patch did
On Thu, 12 Oct 2000, Keith Owens wrote:
> On Thu, 12 Oct 2000 12:56:09 +0100 (BST),
> Tigran Aivazian <[EMAIL PROTECTED]> wrote:
> >one correction -- it was "down and up the interface" that did the trick
> >and not deleting the 64M mtrr entry. I.e. the eepro100 problem is better
> >formulated
Hi Alison,
> The system crashes on boot of the linux partition. Unfortunately, this
> does mean that we haven't been able to run ksymoops or get any of the
> system files, so all we've got is what's on screen, including any
> visible system messages before that point.
I guess this is not the
The soltuion you have chosen is not acceptable, the ordering is
critical and is why all of this stuff is done this way in the first
place. The members must be in _that_ order and the alignment must
occur at that precise spot.
So please propose another patch, perhaps option #1 (the easiest)
There is a bug in gcc-2.7.2.3. It incorrectly lays out
structure initialisers when the `name:value;' construct is used.
Here is the degenerate case:
struct struct_1 { int a; };
struct thing {
int a;
struct struct_1 b;
};
struct
On Fri, 13 Oct 2000, Linus Torvalds wrote:
> Ingo, I'd like you to comment on all the PAE issues just in case, but
> I personally don't have any real issues any more. [...]
there is one small thing apart of the issue Stephen noticed, barrier()
between the two 32-bit writes should IMO be
On Sat, 14 Oct 2000, Stephen Tweedie wrote:
> Looks good. The only trouble I can see left is that pte_clear() is
> still using set_pte(), which doesn't work right for PAE36. set_pte()
> is setting the high word first, which is fine for installing a new
> pte, but if you do that to clear a pte
On Sun, 15 Oct 2000, Andre Hedrick wrote:
>If they will be accepted, I will update them and maintain them.
>I just do not have the time to run two/three trees and prepare the stuff
>for 2.5
>
>> Because it is unmaintained? Once it is in the kernel, Alan will
>> be the one getting bug reports,
On Sun, Oct 15 2000, David S. Miller wrote:
>Date: Sun, 15 Oct 2000 11:19:24 +0200
>From: Torben Mathiasen <[EMAIL PROTECTED]>
>
>It seems reasonable. We'd been thinking of makeing proc_name part
>of the host structure, but no need for that if we just do the
>above.
>
>
1 - 100 of 182 matches
Mail list logo
