On Mon, Mar 26, 2001 at 08:39:21AM -0800, LA Walsh wrote:
> So...is it the plan, or has it been though about -- 'abstracting'
> block numbes as a typedef 'block_nr', then at compile time
> having it be selectable as to whether or not this was to
> be a 32-bit or 64 bit quantity -- that way older
Explication:
i am a newbie in kernel prog. and i try to write a module for an can-bus
pci card
but the problem begin.
In the module i want to create the /dev/ file with mknod function.
The function was not exported by the kernel, so i found in the _syscall
table adress for
call sys_mknod but the
Steve Lord wrote:
> Just a brief add to the discussion, besides which I have a vested interest
> in this!
I'll add my little comments as well, and hopefully not start a flamewar... :)
[snip comments about blocksize, etc.]
Here's a real-life example of something that most of you will probably
Well, why can't the ELF loader module/kernel detect or have some sort of
restriction on modifying other/ELF binaries including itself from changing
the Entry point?
There has to be a way stop this. WHY would anyone want to modify the entry
point anyway? (there may be some reasons but I really
On Wed, Mar 28, 2001 at 01:16:02AM -0500, Shawn Starr wrote:
> Date: Wed, 28 Mar 2001 01:16:02 -0500 (EST)
> From: Shawn Starr <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Subject: Disturbing news..
>
> http://news.cnet.com/news/0-1003-200-5329436.html?tag=lh
> Isn't it time to change the
On Wed, 28 Mar 2001, Alan Cox wrote:
> They will mostly break. Installers tend to parse /proc/scsi and have fairly
> complex ioctl based relationships based on knowing ide v scsi.
>
> /dev/disc/ is a little un-unix but its clean
Then make a '/proc/block/{ide|scsi|raid|wtf|ram|net}' which has a
Gents,
With this new patch set we have lost the compatibility with
pcmcia-cs-3.1.25.
The system at startup reports:
Mar 27 17:04:51 pluto depmod: *** Unresolved symbols in
/lib/modules/2.4.3-pre8/kernel/drivers/net/3c59x.o
Mar 27 17:04:51 pluto depmod: depmod: *** Unresolved symbols in
Werner Almesberger wrote:
> Easy solution: don't run linuxrc, run something else instead. E.g.
> putting the following into the kernel's command line should do th
> trick:
> init=/your_script root=/dev/ram
>
> (With your_script being the original version, without real-root-dev)
This works.
Why not make a new file permission?
to deny a ELF binary the ability to modify the ELF entry point?
like +p if the file had +p (by default) the kernel would deny the ELF
binary the ability to modify files.
Shawn.
On Wed, 28 Mar 2001, Shawn Starr wrote:
>
>
http://news.cnet.com/news/0-1003-200-5329436.html?tag=lh
Isn't it time to change the ELF format to stop this crap?
Shawn.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Is anyone succesfully using a FA311 card (or anthing with a NatSemi
DP83815 chip?)
The natsemi.c driver in 2.4.0 (and the one from Donald Becker's site
for 2.2.x)
Something seems to be handled incorrectly in the driver, because whenever
I subject the card to moderate to heavy load (nfs does
I'm going to be gentle here and try to point out where your suggestions are
flawed...
>a. don't kill any task with a uid < 100
Suppose your system daemon springs a leak? It will have to be killed
eventually, however system daemons can sensibly be given a little "grace".
Also, the UIDs used by
Hi,
On Fri, Mar 23, 2001 at 10:13:44PM +, Alan Cox wrote:
> >
> > I really need to know any *specific* issues with RAWIO.
>
> All I know is that Stephen said he had a set of patches needed to fix rawio.
> I've not applied them nor afaik has Linus.
Ben LaHaise has been testing Oracle on
linux kernel- 2.2.12
processor - pentirum III, 64 MB RAM, 667MHz.
lmbench test suit - used to test the memory bandwidth and latency
measurement for a system. downloaded from : http://www.bitmover.com/lmbench/
I downloaded and ran this lmbench test suit successfully on intel i386
platform
Hi,
We know from debugging tlb IPIs recently that it is possible for a
single IPI to be delivered more than once to a CPU on Intel SMP. (The
most common mechanism seems to be a CPU detecting CRC failure of a
multicast IPI, and the sender resending the entire multicast so that
any CPU which did
On 27 Mar 2001, Johan Kullstam wrote:
> it might be a mostly userspace solvable problem. a device daemon
> could create new devices on the fly, only they'd be ordinary
> filesystem devices. for example it might be better to hack ls to not
> show dormant devices. a cronjob could call a grim
On Wed, 28 Mar 2001, Elmer Joandi wrote:
> 2.4.2-ac26,
> mkreiserfs /dev/hda11
> mount /dev/hda11 /mnt/space
> cp -dpR /usr/* /mnt/space/
followup:
if using older 3.5 reiserfs format cp just gets stuck in WCHAN=do_jour...
problem is reproducable,
also 2.4.3-pre8, not tested others.
first
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Alan Cox wrote:
> >
> > > Another example: all the stupid pseudo-SCSI drivers that got their own
> > > major numbers, and wanted their very own names in /dev. They are BAD for
> > > the user. Install-scripts etc used to be able to just test
On Tue, 27 Mar 2001, Doug Ledford wrote:
> Now, I wouldn't bring this up as a big issue except I keep seeing
> people say things like "why so complex a solution for something that
> is only used in emergency situations". My point is that it *IS NOT*
> being using only in emergency situations
Rik van Riel wrote:
>
> On Tue, 27 Mar 2001, Doug Ledford wrote:
>
> > I've been using our internal tree for my testing, and I'm reluctant to
> > let my experiences there cause me to draw conclusions about other
> > trees. So, will you please tell me which version of the kernel you
> > think
Tyan 260 Dual PIII, 512M RAM,
2.4.2-ac26,
mkreiserfs /dev/hda11
mount /dev/hda11 /mnt/space
cp -dpR /usr/* /mnt/space/
immediately:
Mar 28 04:23:17 server kernel: Unable to handle kernel NULL pointer dereference at
virtual address 0014
Mar 28 04:23:17 server kernel: printing eip:
Mar 28
> Then, my question will be, why is the kernel loosing the irq for eth1
> and gets unusable?
In the APIC case on many intel boards it appears to be a hardware bug. THere
is a workaround for the apic problems in -ac
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
Joerg Pommnitz wrote:
> David Konerding <[EMAIL PROTECTED]> wrote:
>
> > But the attitude that "many eyes make all bugs shallow" and "let the
> > users test the code for us" just don't hold up. For the former,
> > clearly, many eyes didn't find a lot of basically obvious bugs, for the
> >
> Exactly. It's just that for historical reasons, I think the major for
> "disk" should be either the old IDE or SCSI one, which just can show more
> devices. That way old installers etc work without having to suddenly start
> knowing about /dev/disk0.
They will mostly break. Installers tend to
On Tue, 27 Mar 2001 20:09:13 +0200,
Tea Age <[EMAIL PROTECTED]> wrote:
>I found out, that agpgart, which is needed by i810fb, is initialized
>_after_ i810fb setup. Therefore i810fb failes to initialize.
This will be messy. I assume you put i810fb in drivers/char/Makefile
as something like this
I'm about halfway through the video directory, making all the pci
drivers that access resources/irq use pci_enable_device first.
Here's the first 8 patches (1 patch per driver); if you prefer, I'll
send you the rest when I'm done, or I can just tell you and you
can grab 'em off
On Wed, 28 Mar 2001, Paul Jakma wrote:
> On Tue, 27 Mar 2001, Dan Hollis wrote:
>
> > On Tue, 27 Mar 2001, H. Peter Anvin wrote:
> > > c) Make sure chown/chmod/link/symlink/rename/rm etc does the right thing,
> > > without the need for "tar hacks" or anything equivalently gross.
> >
> >
Spettabile!
Mi scusi per questa e-mail,ma volevo avvisarla,che il nuovo indirizzo e'
WWW.DOPLAND.COM
con tante novita' per lei,per la sua famiglia e per i suoi amici!
Cordiali
[EMAIL PROTECTED] writes:
> > > NETDEV WATCHDOG: eth0: transmit timed out
> > > eth0: Transmit timed out: status f048 0c00 at 0/28 command 001a000
> >
> > Same here on 2.4.1 smp with two dirt-cheap ne2pci-clones. System
> > unusuable (as stated by clem ealier today) and need for
> >
On Tuesday 27 March 2001 18:52, Rik van Riel wrote:
> On Tue, 27 Mar 2001, james wrote:
> > Here are my ideas on how too deal with the oom situation,
> >
> > I propose a three prong approach too this problem
>
> Isn't that a bit much for an emergency situation that never
> even occurs on most
Rik van Riel wrote:
>
> On Tue, 27 Mar 2001, james wrote:
>
> > Here are my ideas on how too deal with the oom situation,
>
> > I propose a three prong approach too this problem
>
> Isn't that a bit much for an emergency situation that never
> even occurs on most systems ?
I've been using
On Tue, 27 Mar 2001, Dan Hollis wrote:
> On Tue, 27 Mar 2001, H. Peter Anvin wrote:
> > c) Make sure chown/chmod/link/symlink/rename/rm etc does the right thing,
> > without the need for "tar hacks" or anything equivalently gross.
>
> write-through filesystem, like overlaying a r/w ext2 on top
On Tue, 27 Mar 2001, james wrote:
> Here are my ideas on how too deal with the oom situation,
> I propose a three prong approach too this problem
Isn't that a bit much for an emergency situation that never
even occurs on most systems ?
Rik
--
Virtual memory is like a game you can't win;
[1.] One line summary of the problem:
ftp FROM 2.4.2 ix86 machine to system with true 64-bit or otherwise no 2GB limit
system complains that the file size is too large.
[2.] Full description of the problem/report:
On the 2.4.2 ix86 machine doing put:
-
UNIX
Andrew Pimlott writes:
> On Tue, Mar 27, 2001 at 02:13:47PM -0800, H. Peter Anvin wrote:
>> The problems with devfs (other than kernel memory bloat, which is pretty
>> much guaranteed to be much worse than the bloat a larger dev_t would
>> entail) is that it needs complex auxilliary mechanisms
Hi Kernel Guru's
Here are my ideas on how too deal with the oom situation, most of these
should be thought of stuff to do in 2.5.x kernels, because it touches a lot
of kernel path ways, with possible back porting
once it is tested.
I propose a three prong approach too this problem
Prong
Hi,
>From [EMAIL PROTECTED] Wed Mar 28 05:06:59 2001
>
> David Balazic <[EMAIL PROTECTED]> writes:
>
> > While isn't this merged into the official kernel ?
>
> The maintainer hasn't the time to do it. He promised me he would in
True.
> February, when I telephone, but hasn't bothered to do
On Tue, 27 Mar 2001, H. Peter Anvin wrote:
>
> They would still have to change, since now we'd have to worry about
> /dev/hd* having changed meanings;
This is why I'd select the SCSI major, which has always had more of a
"random disk" connotation, with fewer people being aware of the fact that
Jens Gecius wrote:
>
> John Madden <[EMAIL PROTECTED]> writes:
>
> > I'm receiving the following errors while botting a previously-fine 2.2
> > machine (Dell 2450, 2 eepro 100's):
> >
> > NETDEV WATCHDOG: eth0: transmit timed out
> > eth0: Transmit timed out: status f048 0c00 at 0/28
John Madden <[EMAIL PROTECTED]> writes:
> I'm receiving the following errors while botting a previously-fine 2.2
> machine (Dell 2450, 2 eepro 100's):
>
> NETDEV WATCHDOG: eth0: transmit timed out
> eth0: Transmit timed out: status f048 0c00 at 0/28 command 001a000
Same here on 2.4.1
On Wed, 28 Mar 2001, Jorge Nerin wrote:
Despite your improper massive crossposting, I think you missed
the place where such a problem would be best discussed. That
would be the dri lists at sourceforge. Barring that the
[EMAIL PROTECTED] site. Any X related problems should be
discussed there.
On Tue, 27 Mar 2001, Alan Cox wrote:
>
> A major for 'disk' generically makes total sense. Classing raid controllers
> as 'scsi' isnt neccessarily accurate. A major for 'serial ports' would also
> solve a lot of misery
Exactly. It's just that for historical reasons, I think the major for
In article <[EMAIL PROTECTED]>,
Martin Dalecki <[EMAIL PROTECTED]> wrote:
>Plase change to 100 to 500 - this would make it consistant with
>the useradd command, which starts adding new users at the UID 500
"the" useradd command? Which distribution ?
Mike.
-
To unsubscribe from this list:
Linus Torvalds wrote:
>
> On Tue, 27 Mar 2001, Alan Cox wrote:
> >
> > A major for 'disk' generically makes total sense. Classing raid controllers
> > as 'scsi' isnt neccessarily accurate. A major for 'serial ports' would also
> > solve a lot of misery
>
> Exactly. It's just that for historical
On Tue, 27 Mar 2001, Andre Hedrick wrote:
>
> Am I hearing you state you want dynamic device points and dynamic majors?
Yes and no.
We need static structures for user space - from a user perspective it
makes a ton more sense to say "I want to see all disks" than it does to
know that you have
Hi,
Just a brief add to the discussion, besides which I have a vested interest
in this!
I do not believe that you can make the addressability of a device larger at
the expense of granularity of address space at the bottom end. Just because
ext2 has a single size for metadata does not mean
H. Peter Anvin writes:
> Dan Hollis wrote:
> >
> > On Tue, 27 Mar 2001, H. Peter Anvin wrote:
> > > c) Make sure chown/chmod/link/symlink/rename/rm etc does the right thing,
> > > without the need for "tar hacks" or anything equivalently gross.
> >
> > write-through filesystem, like overlaying
On Tue, Mar 27, 2001 at 02:13:47PM -0800, H. Peter Anvin wrote:
> The problems with devfs (other than kernel memory bloat, which is pretty
> much guaranteed to be much worse than the bloat a larger dev_t would
> entail) is that it needs complex auxilliary mechanisms to make
> "chmod /dev/foo"
Clem Taylor wrote:
>
> Every few weeks, since switching to 2.4.2, I get a series of 'NETDEV
> WATCHDOG' errors. When this happens the system becomes unusable (homes
> are NFS mounted) and does not recover. A small number of packets do get
> out when it's in this state, but not enough to be
Guest section DW wrote:
> On Tue, Mar 27, 2001 at 11:33:34PM +0200, Jorge Nerin wrote:
>
>
>> Hello, good work with 2.4.x, but I miss one thing. in early 2.3.x the MS
>> keys, you know, two flags and one "properties" key worked as navigation
>> keys in the console.
>>
>> The flags get you
On Tue, Mar 27, 2001 at 11:33:34PM +0200, Jorge Nerin wrote:
> Hello, good work with 2.4.x, but I miss one thing. in early 2.3.x the MS
> keys, you know, two flags and one "properties" key worked as navigation
> keys in the console.
>
> The flags get you to the "left" or "rigth" virtual
On Tue, 27 Mar 2001, Richard Jerrell wrote:
> Oops... I sent out the wrong version of the patch the first time.
> This one has comments, promise. And it has one less bug. :)
Looks good to me (at first glance). Any volunteer to
stress-test this on an SMP machine ?
Rik
--
Virtual memory is
Dan Hollis wrote:
>
> On Tue, 27 Mar 2001, H. Peter Anvin wrote:
> > c) Make sure chown/chmod/link/symlink/rename/rm etc does the right thing,
> > without the need for "tar hacks" or anything equivalently gross.
>
> write-through filesystem, like overlaying a r/w ext2 on top of an iso9660
> fs.
On Tue, 27 Mar 2001, H. Peter Anvin wrote:
> c) Make sure chown/chmod/link/symlink/rename/rm etc does the right thing,
> without the need for "tar hacks" or anything equivalently gross.
write-through filesystem, like overlaying a r/w ext2 on top of an iso9660
fs.
-Dan
-
To unsubscribe from
> 1. we take an extra reference on the page, how does that
>affect the test for if the page is shared or not ?
is_page_shared expects us to have our own reference to the page.
> 2. we call delete_from_swap_cache with the pagemap_lru_lock
>held, since this tries to grab the
On Tue, Mar 27, 2001 at 02:16:37PM -0800, H. Peter Anvin wrote:
> Alan Cox wrote:
> > A major for 'disk' generically makes total sense. Classing raid controllers
> > as 'scsi' isnt neccessarily accurate. A major for 'serial ports' would also
> > solve a lot of misery
>
> But it might also cause
I'm receiving the following errors while botting a previously-fine 2.2
machine (Dell 2450, 2 eepro 100's):
NETDEV WATCHDOG: eth0: transmit timed out
eth0: Transmit timed out: status f048 0c00 at 0/28 command 001a000
(repeating with different status codes..)
Any thoughts?
John
-
To
Jesse Pollard wrote:
> > >
> > > > high-end-disks. Rather the reverse. I'm advocating the SCSI layer not
> > > > hogging a major number, but letting low-level drivers get at _their_
> > > > requests directly.
> > >
> > > A major for 'disk' generically makes total sense. Classing raid controllers
I have a problem with kernel 2.4.0 and my initrd image.
I have a 500 KB bzImage, and I have a 1.200 KBytes initrd image.
My sistem have 8 MB RAM memory. When I init my bzImage from a
MSDOS floppy with this command:
loadlin bzImage initrd=myinitrd.img
I obtain this error:
"initrd extends
- Received message begins Here -
>
> Alan Cox wrote:
> >
> > > high-end-disks. Rather the reverse. I'm advocating the SCSI layer not
> > > hogging a major number, but letting low-level drivers get at _their_
> > > requests directly.
> >
> > A major for 'disk' generically
Hello, good work with 2.4.x, but I miss one thing. in early 2.3.x the MS
keys, you know, two flags and one "properties" key worked as navigation
keys in the console.
The flags get you to the "left" or "rigth" virtual console, and the
"properties" key put you on the last console you where
Hello, I'm using 2.4.2-ac24, Xfree86 4.0.2 + 4.0.3 upgrade,
Glide_V3-2.60-16 & Glide_V3-DRI-3.10-6, and tdfx framebuffer.
My system is a 2x200MMX on a Gigabyte 586DX with 96Mb, a Voodoo3 2000
pci and a bt848 tv card.
I have the card working ok, except for a few nonstopers.
- I cannot use the
Jan Harkes <[EMAIL PROTECTED]>:
>
> On Tue, Mar 27, 2001 at 01:57:42PM -0600, Jesse Pollard wrote:
> > > Using similar numbers as presented. If we are working our way through
> > > every single block in a Pentabyte filesystem, and the blocksize is 512
> > > bytes. Then the 1us in extra CPU
Alan Cox wrote:
>
> > high-end-disks. Rather the reverse. I'm advocating the SCSI layer not
> > hogging a major number, but letting low-level drivers get at _their_
> > requests directly.
>
> A major for 'disk' generically makes total sense. Classing raid controllers
> as 'scsi' isnt
On Tuesday 27 March 2001 08:51, James Lewis Nance wrote:
> Instead I think we need to encourage people who want to use Linux,
> rather than develop it, to use kernels from a distribution.
I hope that's not the opinion of all the kernel developers - where does that
leave distributions like
> high-end-disks. Rather the reverse. I'm advocating the SCSI layer not
> hogging a major number, but letting low-level drivers get at _their_
> requests directly.
A major for 'disk' generically makes total sense. Classing raid controllers
as 'scsi' isnt neccessarily accurate. A major for
Alan Cox wrote:
>
> > Another example: all the stupid pseudo-SCSI drivers that got their own
> > major numbers, and wanted their very own names in /dev. They are BAD for
> > the user. Install-scripts etc used to be able to just test /dev/hd[a-d]
> > and /dev/sd[0-x] and they'd get all the disks.
On Tue, 27 Mar 2001, Linus Torvalds wrote:
>
>
> On Tue, 27 Mar 2001, Alan Cox wrote:
> >
> > > layer made it impossible for a driver writer to be nice to the user, so
> > > instead they got their own major numbers.
> >
> > Not deficiencies in the SCSI layer, there is no way the scsi layer can
Oops, the last patch isn't the one I meant to send. Here is the right
one.
Tim.
*/
2001-03-27 Tim Waugh <[EMAIL PROTECTED]>
* parport_pc: Fix save/restore_state to take account of the soft
control port.
* ChangeLog: Updated.
---
Jan Harkes wrote:
>
> On Tue, Mar 27, 2001 at 01:57:42PM -0600, Jesse Pollard wrote:
> > > Using similar numbers as presented. If we are working our way through
> > > every single block in a Pentabyte filesystem, and the blocksize is 512
> > > bytes. Then the 1us in extra CPU cycles because of
On Tue, Mar 27, 2001 at 01:42:39PM +0200, Thomas Pfaff wrote:
> Hi all,
>
> i decided to make a test for the 2.4 kernel on my old hardware (Gigabyte
> EISA/VLB with an AMD 486 DX4 133). The kernel boots fine but there is one
> strange thing: The system clock slows down under load, after a make
>
On Tue, 27 Mar 2001, Richard Jerrell wrote:
>
> Instead of removing the swap cache page at process exit and possibly
> expending time doing disk IO as you have pointed out, we check during
> refill_inactive_scan and page_launder for a page that is
I think this patch looks pretty good. However,
On Tue, 27 Mar 2001, Chris Mason wrote:
> On Tuesday, March 27, 2001 11:14:57 AM -0800 Christoph Lameter
> <[EMAIL PROTECTED]> wrote:
> I should have been more clear. Everyt ime you mount the filesystem, a it
> prints the hash used. This is probably recorded in your log files, either
> 'Using
Every few weeks, since switching to 2.4.2, I get a series of 'NETDEV
WATCHDOG' errors. When this happens the system becomes unusable (homes
are NFS mounted) and does not recover. A small number of packets do get
out when it's in this state, but not enough to be useful. I've tried an
ifconfig
On Fri, 23 Mar 2001 09:34:36 -0800, Jun Sun <[EMAIL PROTECTED]> wrote:
> BTW, does the eepro100 patch for 2.2.19pre apply to 2.4.2? Or it is already
> in it?
It was backported from 2.4.1, so yes, it's already in.
Ion
--
It is better to keep your mouth shut and be thought a fool,
This fixes a printing bug that only seems to show up with some
chipsets. Please apply.
Thanks,
Tim.
*/
2001-03-27 Tim Waugh <[EMAIL PROTECTED]>
* parport_pc: Fix save/restore_state to take account of the soft
control port.
* ChangeLog: Updated.
---
On Tue, 27 Mar 2001, Alan Cox wrote:
>
> > layer made it impossible for a driver writer to be nice to the user, so
> > instead they got their own major numbers.
>
> Not deficiencies in the SCSI layer, there is no way the scsi layer can
> handle high end raid controllers. In fact one of the
> Another example: all the stupid pseudo-SCSI drivers that got their own
> major numbers, and wanted their very own names in /dev. They are BAD for
> the user. Install-scripts etc used to be able to just test /dev/hd[a-d]
> and /dev/sd[0-x] and they'd get all the disks. Deficiencies in the SCSI
On Tue, 27 Mar 2001, Richard Jerrell wrote:
> Instead of removing the swap cache page at process exit and possibly
> expending time doing disk IO as you have pointed out, we check during
> refill_inactive_scan and page_launder for a page that is
Three comments:
1. we take an extra reference on
On Tue, 27 Mar 2001, Uncle George wrote:
> The fix is a lot simpler. It has to be placed in release notes that the
> generic ide can cause the sound device to distort the sound stream.
> Would that be a fair statement ?
GAT,
Not sure how to comment, but did enabling the chipset code make it
The fix is a lot simpler. It has to be placed in release notes that the
generic ide can cause the sound device to distort the sound stream.
Would that be a fair statement ?
Andre Hedrick wrote:
>
>
>
> This is your fix
>
> Andre Hedrick
>
-
To unsubscribe from this list: send the line
--On Tuesday, March 27, 2001 12:55:50 -0700 Andreas Dilger
<[EMAIL PROTECTED]> wrote:
> Every time this subject comes up, I point to AIX and SIGDANGER - a signal
> sent to processes when the system gets OOM. If the process has registered
> a SIGDANGER handler, it has a chance to free cache and
> fork and exit are very hot paths in the kernel, and this patch can force
> a page cache lookup on a large number of pte which wouldn't be looked
> up before.
True, but I don't know how large of a performance hit the system takes.
> Given that the leak is, as you say, temporary, and that the
It's been rumoured that James Simmons said:
>
>
> >This is easily explained: some byte of the mouse protocol was lost.
> >(Some mouse protocols are even designed to allow
> >easy resync/recovery by fixed bit patterns!)
> >
> >Write an intelligent mouse driver for XFree86 to compensate for
>
James Simmons wrote:
>
> >This is easily explained: some byte of the mouse protocol was lost.
> >(Some mouse protocols are even designed to allow
> >easy resync/recovery by fixed bit patterns!)
> >
> >Write an intelligent mouse driver for XFree86 to compensate for
> >lost bytes.
>
> Or write a
It's been rumoured that Gunther Mayer said:
>
> > I am experiencing debilitating intermittent mouse problems & was about
> ...
> > Symptoms:
> > After a long time of flawless operation (ranging from nearly a week to
> > as little as five minutes), the X11 pointer flies up to top-right corner,
>
Hi,
BTW, ACPI in ac20 doesn't work for me either :(
Alex
On Mon, Mar 26, 2001 at 10:35:33AM -0800, Grover, Andrew wrote:
> > From: Ingo Oeser [mailto:[EMAIL PROTECTED]]
> > > > As i recompiled 2.4.2-ac20 with ACPI support
> > > > the system cannot switch itself off.
> > > > I get a message
[EMAIL PROTECTED] said:
> The build fails here for lack of "toshiba.h". Changing that to
> gets the build through. While at it, I fixed some
> "#include<..." (no ' ' before the '<'), which may be right but look
> ugly IMVHO.
Apologies to all for that. I have been a bit of a dunderhead. I
1: One line summary of the problem:
Logfile is full of APIC errors
2: Full description of the problem/report:
My logfile for kernel-errors is full of messages like that:
Mar 27 20:57:27 E-Werk kernel: APIC error on CPU0: 02(04)
Mar 27 20:57:27 E-Werk kernel: APIC error on CPU1: 08(08)
Mar 27
>This is easily explained: some byte of the mouse protocol was lost.
>(Some mouse protocols are even designed to allow
>easy resync/recovery by fixed bit patterns!)
>
>Write an intelligent mouse driver for XFree86 to compensate for
>lost bytes.
Or write a kernel input device driver. In fact I
On Tue, Mar 27, 2001 at 01:57:42PM -0600, Jesse Pollard wrote:
> > Using similar numbers as presented. If we are working our way through
> > every single block in a Pentabyte filesystem, and the blocksize is 512
> > bytes. Then the 1us in extra CPU cycles because of 64-bit operations
> > would
[EMAIL PROTECTED] wrote:
>
> I am experiencing debilitating intermittent mouse problems & was about
...
> Symptoms:
> After a long time of flawless operation (ranging from nearly a week to
> as little as five minutes), the X11 pointer flies up to top-right corner,
> Unable to handle kernel NULL pointer dereference at virtual address
> 0004
> [...]
>
> EIP; c0111720
It accesses a wait queue pointer
>
> Trace; c2810add <[lanstreamer]streamer_open+2cd/8f0>
>
Uninitialized old style waitqueue?
I assume a
init_waitqueue_head(_priv->srb_wait);
is
hdx=flash is only a flag to deal with flash.
a better description is probe-slave-with-master-flash, or
to-hell-with-flash-go-look.
On Tue, 27 Mar 2001, Richard A. Smith wrote:
> On Tue, 27 Mar 2001 09:17:48 -0800 (PST), Andre Hedrick wrote:
>
> >not acceptable. If you have a complain take
Ok, here's the trace, this time it didn't die on me.
mozilla-bin D CDC1779C 0 6530 1(NOTLB) 6533
Call Trace: [] [] [] []
[] [] []
[] [] [] [] []
[] [] []
[] [] []
[scsi_queue_next_request+62/248] [__scsi_end_request+327/340]
At 23:23 26-3-01 +0200, you wrote:
>On Mon, 26 Mar 2001, Theodoor Scholte wrote:
>
> > There are no relevant messsages in that file.
>
>Strange, but I bet that you can compile again, right? (Just remove the
>broken compile.h that the dd command created) Must have been an NFS
>fluke, and without
Martin Dalecki writes:
> Ingo Oeser wrote:
> > So as Rik stated: The OOM killer cannot suit all people, so it
> > has to be configurable, to be OOM kill, not overkill ;-)
>
> Irony: Why then not store this information permanently - inside
> the UID of the application?
Because in some cases
Hi!
> The attached patch is against 2.4.1 and incorporates the following:
The patch seems to be word-wrapped...
Pavel
> diff -ur -x via-rhine* linux-2.4.1.orig/fs/exec.c linux/fs/exec.c
> ---
> linux-2.4.1.orig/fs/exec.cTue
- Received message begins Here -
>
> On Tue, Mar 27, 2001 at 09:15:08AM -0800, LA Walsh wrote:
> > Now lets look at the sites want to process terabytes of
> > data -- perhaps files systems up into the Pentabyte range. Often I
> > can see these being large multi-node
On Tue, 27 Mar 2001, H. Peter Anvin wrote:
>
> Part of the reason we haven't -- quite -- run out of 8-bit majors yet is
> because I have been an absolute *bastard* with registrants lately. It
> would cut down on my workload if I could assign majors without worrying
> too much about whether or
1 - 100 of 394 matches
Mail list logo
