System is a PIII UP 2.4.5-pre1, NFS client, options from /proc/mounts:
arezzo:/usr/src/dolphin /usr/src/dolphin nfs
rw,nodev,v3,rsize=32768,wsize=32768,hard,udp,nolock,addr=arezzo 0 0
Lately my arpwatch running on this 2.4.5-pre1 machine started to log
May 15 15:55:18 espoo
Got the image of 3 interesting packets by letting a modified tcpdump dump
the entire packet buffer in arp_print().
Original tcpdump output:
16:23:17.108993 P 0:60:97:ba:b4:f5 0:0:0:0:0:1 arp 1514: arp-#8192 for proto #1500
(138) hardware #17664 (36)
16:23:17.809024 P 0:60:97:ba:b4:f5
The last 1304 bytes of 1.bin and 2.bin are identical to the first 1304 bytes
of the .swp file made by VIM.
--
Frank
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
As the subject already says, reproduced in 2.4.5-pre2.
--
Frank
-
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/majordomo-info.html
Please read the FAQ at
To recap:
The machine is an NFSv3 client. The header of outgoing NFS UDP/IP packets
is sometimes corrupted, such that network sniffers on unrelated systems
report bogus ARP packets. AFAIK there is no data corruption on the
file level because the request is no longer recognized by the NFS
server.
On Wed, Sep 13, 2000 at 12:42:15PM +0200, Trond Myklebust wrote:
Is there any 'standard' function for reading the microseconds fields
in userland? I couldn't find anything with a brief search in the
X/Open docs.
Both Digital OSF/1 and Solaris use 3 undocumented spare fields in the
struct
On Wed, Oct 04, 2000 at 09:39:11AM +1300, Craig Whitmore wrote:
I need to set up a server with a user that is in more than 32 groups at a time
and as far as I know NGROUPS_MAX in limits.h changes this maximum.
If I increase (say to 256) this will this break anything or will linux work
On Sat, Sep 16, 2000 at 07:22:38PM +0200, Alain Knaff wrote:
The following patch (against 2.4.0-test8) restores floppy ioctl functionality,
which has been broken in 2.4.0-test6-pre7. It now tests for fake
ioctl's, so their should be no interaction with read-only mounts:
Still not in test9:
On Mon, Nov 20, 2000 at 08:53:19AM -0500, Charles Turner, Ph.D. wrote:
[root@merrimac linux-2.2.17]# make dep
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/mkdep
scripts/mkdep.c
collect2: ld terminated with signal 11 [Segmentation fault], core dumped
make: ***
The tcpdump program (tcpdump -p -i ppp1 -s 1500 not port login) will
not report any packets after adding a default route to eth0 in the setup
below. The packet generating command is ping 192.168.2.42
It has been verified at the ppp1 peer that packets really arrive there via
ppp. Tcpdumping eth0
While playing with routing (zebra) and PPP I regularly see this
message appearing. It always happens when pppd terminates a connection,
e.g:
Dec 3 23:09:08 mimas pppd[784]: Modem hangup
Dec 3 23:09:08 mimas pppd[784]: Connection terminated.
Dec 3 23:09:08 mimas pppd[784]: Connect time 2.0
On Tue, Dec 05, 2000 at 12:47:03PM +1100, Andrew Morton wrote:
Ted,
it's caused by exec_usermodehelper().
Patch seems to work. Tested on 2.4.0-test11 which revealed the problem
--
Frank
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Tue, Dec 05, 2000 at 12:47:03PM +1100, Andrew Morton wrote:
[EMAIL PROTECTED] wrote:
On Sun, Dec 03, 2000 at 11:36:11PM +0100, Frank van Maarseveen wrote:
While playing with routing (zebra) and PPP I regularly see this
message appearing. It always happens when pppd terminates
On Thu, Dec 07, 2000 at 05:34:44AM -0800, Daniel Chemko wrote:
Hello,
I am doing development work on the 2.4.0 kernel, and can not seem to get
multicasting to work.
I frequently experiment with "zebra" (http://www.zebra.org) routing engine
and multicasting works for me (2.4.0-test11),
[running make depend after a fresh tar xz of a linux tree]
Dec 10 15:31:36 iapetus kernel: attempt to access beyond end of device
Dec 10 15:31:36 iapetus kernel: 03:04: rw=0, want=1934262372, limit=6281415
Dec 10 15:31:36 iapetus kernel: attempt to access beyond end of device
Dec 10 15:31:36
In addition to the previous:
A clean rebuild of a linux tree failes because of EXT2 data block mixups
(?). A second rebuild reveals further corruptions of similar nature. A
final fsck uncovers a few lost inodes. All file lengths are reasonable
i.e. no magic power of two numbers there.
doit
+
Hmm, not only I see files stuffed with random data but sometimes also with
a block of zeroes (about 3600 consecutive zero bytes in a .depend file)
At one time /var/log/messages said while doing rm -rf:
Dec 10 21:23:04 iapetus kernel: EXT2-fs error (device ide0(3,4)): ext2_readdir: bad
entry in
After removing 128MB, leaving the original 64MB in the main board:
+ tar xzf /home/fvm/kernel/v2.4/linux-2.4.0-test10.tar.gz
+ bzcat /home/fvm/kernel/v2.4/patch-2.4.0-test11.bz2
+ patch -p0 -s
+ zcat /home/fvm/kernel/v2.4/test12-pre7.gz
+ patch -p0 -s
3 out of 3 hunks FAILED -- saving rejects to
I don't know why but make oldconfig keeps asking this:
ServerWorks OSB4 chipset support (CONFIG_BLK_DEV_OSB4) [N/y/?] (NEW)
Compilation problems:
plip.c: In function `plip_init_dev':
plip.c:352: structure has no member named `next'
plip.c:357: structure has no member named `next'
On Mon, Dec 11, 2000 at 01:37:36AM +0100, Guest section DW wrote:
I see lots of messages from you about corruption in 2.4.0-test11
but we all know very well that 2.4.0-test11 corrupts things
and further evidence is not necessary.
Hopefully all, or at least the most significant, problems
On Mon, Dec 11, 2000 at 07:53:05PM -0600, Peter Samuelson wrote:
[Mohammad A. Haque]
Wasn't there discussion that user space apps shouldn't include kernel
headers?
Oh, it's been discussed, many times. Here is my executive summary of
why nobody needs to use kernel headers in userspace
On Thu, Dec 14, 2000 at 12:58:26AM -0800, Matthew Dharm wrote:
I doubt that from this description, you've been hacked. Even if your
/etc/inetd.conf is in good shape, it looks like someone got in.
I'm guessing that your ls was also hijacked. You're using RedHat, so try
the rpm -V
I just had a solid lockup inside X. Just moved the serial mouse, nothing
special going on. No caps lock, no ping.
gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
Kernel is 2.4.0-test12-pre8 + this
Boot after a power cycle works. A ctrl-alt-del reboot always hangs during
startup (caps lock dead, ctrl-alt-del dead):
Oct 31 13:36:22 area51 kernel: (scsi0) Adaptec AHA-2940A Ultra SCSI host adapter
found at PCI 0/4/0
Oct 31 13:36:22 area51 kernel: (scsi0) Narrow Channel, SCSI ID=7, 3/255
First a firewall is installed (ppp0). Starting the network (eth0/lo only. ppp0 is
nonexistent at this point) gives the following Oops:
ksymoops 2.3.3 on i686 2.4.0-test10-x23. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o
On Tue, Nov 07, 2000 at 02:19:05PM +1100, Keith Owens wrote:
On Mon, 6 Nov 2000 23:03:44 +0100,
Frank van Maarseveen [EMAIL PROTECTED] wrote:
First a firewall is installed (ppp0). Starting the network (eth0/lo only. ppp0 is
nonexistent at this point) gives the following Oops:
klogd has
On Tue, Nov 07, 2000 at 11:19:37AM -0500, Chris Swiedler wrote:
Here's a small patch to allow a user to protect certain PIDs from death-
by-OOM-killer. It uses the proc entry '/proc/sys/vm/oom_protect'; echo the
PIDs to be protected:
echo 1 516 /proc/sys/vm/oom_protect
Hmm, I'd prefer
FYI, i810 audio still has problems. No sound at all and kernel says:
Nov 14 11:38:30 espoo kernel: agpgart: Detected an Intel i810 E Chipset.
Nov 14 11:38:30 espoo kernel: agpgart: detected 4MB dedicated video ram.
Nov 14 11:38:30 espoo kernel: agpgart: AGP aperture is 64M @ 0x4400
Nov 14
As reported earlier in test10-pre7 a /sbin/reboot hangs the machine
during boot right at the point marked [HANG]. Have to cycle power to
get it right. Attaching a device makes no difference. 2.2.14 was ok.
Oct 31 13:36:22 area51 kernel: (scsi0) Adaptec AHA-2940A Ultra SCSI host adapter
found at
On Fri, Nov 17, 2000 at 06:14:14PM +, Alan Cox wrote:
SHM is resolved but O_SYNC is not yet fixed. You could therefore easily lose
your entire database
I assume 2.2.18-pre-latest is ok?
Some oracle doc still refers to 2.0.34
--
Frank
-
To unsubscribe from this list: send the line
2.4.0-test11-pre3 kernel said
Nov 19 17:40:25 iapetus kernel: Attempt to read inode for relocated directory
Nov 19 17:40:25 iapetus last message repeated 8 times
while doing a
mount -t iso9660 /dev/hdc /cdrom
cd /cdrom
find -depth |cpio -pdm /dst
Is reproducable here,
System is a dual PIII. Oops occurred while starting the automounter
(autofs). starting it later on by hand again gave no oops anymore.
ksymoops 2.3.5 on i686 2.4.4-x40. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.4-x40/
On Mon, Apr 30, 2001 at 11:07:21AM -0400, Brian Gerst wrote:
Code; c021b5f6 __generic_copy_from_user+3a/64 =
0: f3 a5 repz movsl %ds:(%esi),%es:(%edi) =
There should be no way for this to cause an oops. There should be an
exception handler here that
This one has puzzled me for more than a year. Occasionally a machine
(This time a Compaq EPa PIII 665MHz running 2.4.0, inside XFree86 4.0.3
i810E) almost freezes for no appearent reason. Symptom: when hitting the
caps lock or num lock key the LED on the keyboard responds only after
a substancial
A PIII with 64MB ram, 256MB swap became extremely sluggish. While still
inside X11 the caps-lock LED responded only after about 10 seconds. Disk
LED was continuously on. Impossible to connect from another system (just too
slow) but the box still responded to ICMP echo.
I played a bit with magic
A PIII with 96MB ram became extremely sluggish inside X11. I managed
to terminate the X server, bringing the system in a useful state
again. While the system was completely quiet (no X server) I noticed
that a lot of both memory and swap was being used for no appearent reason:
# free
Maybe it's already fixed. But just in case it's not:
ksymoops 2.3.5 on i686 2.4.0. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.0/ (default)
-m /boot/System.map-2.4.0 (specified)
No modules in ksyms, skipping objects
2.6.19 is ok, 2.6.20.[12] hangs from the moment DMA is turned on (hdparm
-d 1 /dev/hda):
hda: dma_timer_expiry: dma status == 0x20
hda: DMA timeout retry
hda: timeout waiting for DMA
hda: status error: status=0x58 {
DriveReady
SeekComplete
On Mon, Mar 12, 2007 at 09:54:47AM +0100, Frank van Maarseveen wrote:
2.6.19 is ok, 2.6.20.[12] hangs from the moment DMA is turned on (hdparm
-d 1 /dev/hda):
hda: dma_timer_expiry: dma status == 0x20
hda: DMA timeout retry
hda: timeout waiting for DMA
hda: status
On Mon, Mar 12, 2007 at 01:21:18PM +0100, Bartlomiej Zolnierkiewicz wrote:
Hi,
Could you check if this is the same problem as this one:
http://bugzilla.kernel.org/show_bug.cgi?id=8169
Looks like it except that I don't see lost interrupt messages here. So,
it might be something different
On Mon, Mar 12, 2007 at 12:07:18PM +, Alistair John Strachan wrote:
On Monday 12 March 2007 11:24, Frank van Maarseveen wrote:
On Mon, Mar 12, 2007 at 09:54:47AM +0100, Frank van Maarseveen wrote:
2.6.19 is ok, 2.6.20.[12] hangs from the moment DMA is turned on (hdparm
-d 1 /dev/hda
On Mon, Mar 12, 2007 at 09:40:25PM +0100, Bartlomiej Zolnierkiewicz wrote:
Hi,
On Monday 12 March 2007, Frank van Maarseveen wrote:
On Mon, Mar 12, 2007 at 01:21:18PM +0100, Bartlomiej Zolnierkiewicz wrote:
Hi,
Could you check if this is the same problem as this one
FYI,
Just captured this one, I'm not sure it's NFS at fault because I saw
at least another AIO related mm/truncate.c:398 report with a totally
different stack trace.
The machine seems still running happily, as usual with a considerable
load. kernel is tainted by fglrx.
kernel: BUG: warning at
I'm still seeing the warnings below (2.6.22 started off with lots of
section mismatch warning) but I have no idea if it is safe to ignore
these:
WARNING: arch/i386/kernel/built-in.o(.text+0xea62): Section mismatch: reference
to .init.data:trampoline_end (between 'setup_trampoline' and
On Thu, Sep 13, 2007 at 09:02:00AM +0200, Sam Ravnborg wrote:
On Wed, Sep 12, 2007 at 06:00:17PM +0200, Frank van Maarseveen wrote:
I'm still seeing the warnings below (2.6.22 started off with lots of
section mismatch warning) but I have no idea if it is safe to ignore
these:
WARNING
On at least two Dell optiplex 755 systems with a Core 2 Duo I get
Feb 13 15:14:01 inari CPU 1: Machine Check Exception: 0004
Feb 13 15:14:01 inari CPU 0: Machine Check Exception: 0005
Feb 13 15:14:01 inari Bank 0: b2400800
Feb 13 15:14:01 inari Bank 5:
On Wed, Feb 13, 2008 at 05:25:28PM +0100, Frank van Maarseveen wrote:
On at least two Dell optiplex 755 systems with a Core 2 Duo I get
s/two/three/
Feb 13 15:14:01 inari CPU 1: Machine Check Exception: 0004
Feb 13 15:14:01 inari CPU 0: Machine Check Exception: 0005
On Fri, Feb 15, 2008 at 01:22:41PM +, Alan Cox wrote:
On Wed, 13 Feb 2008 17:25:28 +0100
Frank van Maarseveen [EMAIL PROTECTED] wrote:
On at least two Dell optiplex 755 systems with a Core 2 Duo I get
Feb 13 15:14:01 inari CPU 1: Machine Check Exception: 0004
Feb 13
On Fri, Aug 31, 2007 at 09:50:12AM -0400, Trond Myklebust wrote:
On Fri, 2007-08-31 at 15:12 +0200, Frank van Maarseveen wrote:
IMHO I'd only consider returning EBUSY when trying to mount _exactly_
the same directory with different flags, not for arbitrary subtrees. The
client should
On Fri, Aug 31, 2007 at 09:40:28AM +0200, Jakob Oestergaard wrote:
On Thu, Aug 30, 2007 at 10:16:37PM -0700, Linus Torvalds wrote:
...
Why aren't we doing that for any other filesystem than NFS?
How hard is it to acknowledge the following little word:
regression
It's
van Maarseveen [EMAIL PROTECTED]
Date: Mon Jul 9 22:25:29 2007 +0200
NLM: fix source address of callback to client
Use the destination address of the original NLM request as the
source address in callbacks to the client.
Signed-off-by: Frank van Maarseveen [EMAIL PROTECTED
On Fri, Aug 31, 2007 at 08:11:38AM -0400, Trond Myklebust wrote:
On Fri, 2007-08-31 at 01:07 -0700, Linus Torvalds wrote:
If you want new behaviour, you add a new flag saying you want new
behaviour. You don't just start behaving differently from what you've
always done before (and
On Tue, Jul 10, 2007 at 02:05:52AM +0200, Adrian Bunk wrote:
This patch fixes the following section mismatch reported by
Frank van Maarseveen:
-- snip --
...
MODPOST vmlinux
WARNING: arch/i386/kernel/built-in.o(.text+0xf201): Section mismatch:
reference to .init.data:trampoline_end
While executing
iptables -t nat -D OUTPUT -d 80.126.170.174 -p tcp --dport https -j DNAT --to
192.168.0.1
iptables -t nat -D OUTPUT -d 80.126.170.174 -p tcp --dport http -j DNAT --to
192.168.0.1
ip route del default
ip addr del 80.126.170.174 dev eth0
on a dual PIII during a shutdown:
kernel:
On Sun, Feb 06, 2005 at 08:51:11PM +0100, Frank van Maarseveen wrote:
While executing
iptables -t nat -D OUTPUT -d 80.126.170.174 -p tcp --dport https -j DNAT --to
192.168.0.1
iptables -t nat -D OUTPUT -d 80.126.170.174 -p tcp --dport http -j DNAT --to
192.168.0.1
still present in -rc4
On Mon, Feb 14, 2005 at 03:03:49PM +0100, Matthias-Christian Ott wrote:
On Sun, Feb 06, 2005 at 08:51:11PM +0100, Frank van Maarseveen wrote:
[...]
still present in -rc4:
kernel: BUG: using smp_processor_id() in preemptible [0001] code:
ip/6351
kernel: caller is get_next_corpse+0x13
On Mon, Jul 04, 2005 at 10:56:30AM +0200, Miklos Szeredi wrote:
It is important because on UNIX, root rules on local filesystems.
I dont't like the idea of root not being able to run find -xdev
anymore for administrative tasks, just because something got hidden
by accident or just for fun
On Mon, Jul 04, 2005 at 12:27:13PM +0200, Miklos Szeredi wrote:
E.g. with mount_nonempty it would not refuse to
mount on a non-leaf dir, and README would document, that using this
option might cause trouble. Otherwise the mount would be refused with
a reference to the above option.
that will
got an Oops the same time for 9 days, at the same EIP:
ksymoops 2.4.9 on i686 2.4.28-x97. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.28-x97/ (default)
-m /boot/System.map-2.4.28-x97 (default)
kernel: 1Unable to
On Tue, Jan 18, 2005 at 09:02:14AM +0100, Andries Brouwer wrote:
Suppose we have kernel command line options
rootdev=, rootpttype=, root=, rootfstype=, rootwait=
telling the kernel what device is the root device,
what type of partition table it has,
on which partition the root
On Fri, Aug 19, 2005 at 12:41:07AM -0700, Nathan Becker wrote:
Hi,
I'm running kernel 2.6.12.5 with x86_64 target on an AMD X2 4800+ and
Gigabyte GA-K8NXP-SLI motherboard (bios version F8). I'm having a problem
with lost clock ticks. The dmesg says
warning: many lost ticks.
Your time
After replacing the kernel on a fresh FC4 install with a stock 2.6.13
(using gcc 3.2) and my own config it appears that the clock is going too
fast: it gains at least an hour every 12 hours or so. FC4 kernel (rpm:
kernel-2.6.11-1.1369_FC4) seems ok
I tried the following from another system with
On Tue, Jan 23, 2007 at 11:13:03AM +0200, Yakov Lerner wrote:
On a small Celeron-based appliance, Usb2 disk is not recognized *if*
it is connected during kernel boot.
But if not connected during boot, and I connect it later, it is
recognized and works ok.
I tried various 2.6.16, 17 and 18
On Tue, Jan 02, 2007 at 01:04:06AM +0100, Mikulas Patocka wrote:
I didn't hardlink directories, I just patched stat, lstat and fstat to
always return st_ino == 0 --- and I've seen those failures. These failures
are going to happen on non-POSIX filesystems in real world too, very
rarely.
On Wed, Jan 03, 2007 at 08:17:34PM +0100, Mikulas Patocka wrote:
On Wed, 3 Jan 2007, Frank van Maarseveen wrote:
On Tue, Jan 02, 2007 at 01:04:06AM +0100, Mikulas Patocka wrote:
I didn't hardlink directories, I just patched stat, lstat and fstat to
always return st_ino == 0 --- and I've
On Wed, Jan 03, 2007 at 08:31:32PM +0100, Mikulas Patocka wrote:
I didn't hardlink directories, I just patched stat, lstat and fstat to
always return st_ino == 0 --- and I've seen those failures. These
failures
are going to happen on non-POSIX filesystems in real world too, very
rarely.
I
On Wed, Jan 03, 2007 at 01:09:41PM -0800, Bryan Henderson wrote:
On any decent filesystem st_ino should uniquely identify an object and
reliably provide hardlink information. The UNIX world has relied upon
this
for decades. A filesystem with st_ino collisions without being hardlinked
(or the
On Fri, Jan 05, 2007 at 09:43:22AM +0100, Miklos Szeredi wrote:
High probability is all you have. Cosmic radiation hitting your
computer will more likly cause problems, than colliding 64bit inode
numbers ;)
Some of us have machines designed to cope with cosmic rays, and
On Tue, Jan 09, 2007 at 11:26:25AM -0500, Steven Rostedt wrote:
On Mon, 2007-01-08 at 13:00 +0100, Miklos Szeredi wrote:
50% probability of false positive on 4G files seems like very ugly
design problem to me.
4 billion files, each with more than one link is pretty far fetched.
And
2.6.13-rc4 does not recognize the second CPU of a 3GHz HT P4:
/proc/cpuinfo:
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Pentium(R) 4 CPU 3.00GHz
stepping: 1
cpu MHz : 2993.277
cache size : 1024 KB
In addition, /proc/bus/usb got mounted but /proc/bus seems have changed into a
file:
$ df
df: `/proc/bus/usb': Not a directory
...
$ grep usb /proc/mounts
usbfs /proc/bus/usb usbfs rw 0 0
$ ls -l /proc/bus
-r--r--r-- 1 root root 0 Jul 29 17:54 /proc/bus
$ cat /proc/bus
Inter-| Receive
This is a /var/log/messages snippet from 2.6.12 where HT was working:
Jul 29 18:57:05 kotka syslogd 1.4.1#17: restart.
klogd 1.4.1#17, log source = /proc/kmsg started.
Inspecting /boot/System.map-2.6.12.2-y115
Loaded 38335 symbols from /boot/System.map-2.6.12.2-y115.
Symbols match kernel version
On Sat, Jul 30, 2005 at 08:27:24PM +0100, Hugh Dickins wrote:
On Fri, 29 Jul 2005, Frank van Maarseveen wrote:
2.6.13-rc4 does not recognize the second CPU of a 3GHz HT P4:
I think your problem is this: HT has depended on CONFIG_ACPI for
some while, and now in 2.6.13-rc CONFIG_ACPI depends
On Fri, Jul 29, 2005 at 05:03:19PM -0700, Andrew Morton wrote:
(The IDR problem is fixed in Linus's current tree)
yep, enabled PM and running rc4-git3, everything seems normal now.
--
Frank
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
wrapping just like in kernel bugzilla #4842, and fixed
by this patch - worth including in 2.6.13, though not yet confirmed that
it fixes that specific report from Frank van Maarseveen.
The patch works, thanks.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
--- 2.6.13-rc5-git2/mm/mremap.c
Most of the code suggests that it is valid to insert a NULL item,
possibly a zero item with pointer cast. However, in __lookup_slot()
whether or not the slot is found seems to depend on the actual value
of the item in one special case. But further on it doesn't make any
difference so to remove
While I have access to /proc/pid, readlink fails with EACCES on
/proc/pid/exe
/proc/pid/cwd
/proc/pid/root
even when I own pid though it runs with a different effective/saved/fs
uid such as the X server. This is a bit uncomfortable and doesn't
seem right.
Or is this to
On Tue, Sep 06, 2005 at 06:57:37PM +0100, [EMAIL PROTECTED] wrote:
On Tue, Sep 06, 2005 at 07:53:49PM +0200, Frank van Maarseveen wrote:
While I have access to /proc/pid, readlink fails with EACCES on
/proc/pid/exe
/proc/pid/cwd
/proc/pid/root
even when I own pid
While playing with a new AMD Athlon64 X2 3800+ (i386) the keyboard goes
wild for 10 (20?) seconds, behaves normally for 10 (20?) seconds, and
then goes wild again: when wild, every keypress results in a random
number of repeats, e.g.:
$ pppsss aaxxxuuu
bash: pppsss: command not found
$
$
For quite some time I'm seeing occasional lockups spread over 50 different
machines I'm maintaining. Symptom: a page allocation failure with order:1,
GFP_ATOMIC, while there is plenty of memory, as it seems (lots of free
pages, almost no swap used) followed by a lockup (everything dead). I've
On Wed, Nov 07, 2007 at 09:01:17AM +1100, Nick Piggin wrote:
On Tuesday 06 November 2007 04:42, Frank van Maarseveen wrote:
For quite some time I'm seeing occasional lockups spread over 50 different
machines I'm maintaining. Symptom: a page allocation failure with order:1,
GFP_ATOMIC, while
On Wed, Nov 07, 2007 at 02:56:45PM +0100, Frank van Maarseveen wrote:
On Tue, Nov 06, 2007 at 05:13:50PM -0600, Robert Hancock wrote:
Frank van Maarseveen wrote:
For quite some time I'm seeing occasional lockups spread over 50 different
machines I'm maintaining. Symptom: a page allocation
On Tue, Nov 06, 2007 at 05:13:50PM -0600, Robert Hancock wrote:
Frank van Maarseveen wrote:
For quite some time I'm seeing occasional lockups spread over 50 different
machines I'm maintaining. Symptom: a page allocation failure with order:1,
GFP_ATOMIC, while there is plenty of memory
WARNING: arch/i386/kernel/built-in.o(.text+0xf5c1): Section mismatch: reference
to .init.data:trampoline_end (between 'setup_trampoline' and
'cpu_coregroup_map')
WARNING: arch/i386/kernel/built-in.o(.text+0xf5c7): Section mismatch: reference
to .init.data:trampoline_data (between
On Mon, Jul 09, 2007 at 09:45:40PM +0200, Adrian Bunk wrote:
On Mon, Jul 09, 2007 at 08:42:01PM +0200, Frank van Maarseveen wrote:
WARNING: arch/i386/kernel/built-in.o(.text+0xf5c1): Section mismatch:
reference to .init.data:trampoline_end (between 'setup_trampoline
On Tue, Jul 10, 2007 at 02:14:14AM +0200, Adrian Bunk wrote:
On Mon, Jul 09, 2007 at 08:42:01PM +0200, Frank van Maarseveen wrote:
...
WARNING: kernel/built-in.o(.text+0x1add5): Section mismatch: reference to
.init.text: (between 'kthreadd' and 'init_waitqueue_head')
Below is the fix
FYI,
2.6.21.1, tainted with ATI fglrx driver (so maybe take it with a grain
of salt):
When I attempted to kill -9 an unresponsive looping X server (desktop
processes were gone at that time) the system locked up and reported
the following:
BUG: soft lockup detected on CPU#0!
[c01054a9]
Tested on 2.6.20.6 and 2.6.21.1
I decided to swich from the old IDE drivers to libata and now there
seems to be a little but annoying problem: cannot mount an ISO image
after burning it.
May 1 14:32:55 kernel: attempt to access beyond end of device
May 1 14:32:55 kernel: sr0: rw=0, want=68,
On Fri, May 04, 2007 at 10:16:32AM +0200, Tejun Heo wrote:
Michal Piotrowski wrote:
On 01/05/07, Mark Lord [EMAIL PROTECTED] wrote:
Forwarding to linux-scsi and linux-ide mailing lists.
Frank van Maarseveen wrote:
Tested on 2.6.20.6 and 2.6.21.1
I decided to swich from the old
On Fri, May 04, 2007 at 10:41:41AM +0200, Tejun Heo wrote:
Frank van Maarseveen wrote:
On Fri, May 04, 2007 at 10:16:32AM +0200, Tejun Heo wrote:
Michal Piotrowski wrote:
On 01/05/07, Mark Lord [EMAIL PROTECTED] wrote:
Forwarding to linux-scsi and linux-ide mailing lists.
Frank van
2.6.20.6, FYI,
This suddenly cropped up after starting to use the i915 and drm module
but maybe it is unrelated to that:
kernel BUG at mm/slab.c:2877!
invalid opcode: [#1]
SMP
Modules linked in: i915 drm
CPU:0
EIP:0060:[c016640b]Not tainted VLI
EFLAGS: 00010083 (2.6.20.6-x153
On Wed, May 02, 2007 at 09:56:52AM +0200, Miklos Szeredi wrote:
I tried the unprivileged mount v5 patches with 2.6.21.1. I made some
experiments with normal filesystems (ext3, xfs, iso9660). I removed the
FS_SAFE checks for that.
Thanks for looking at this.
Mounting and umounting as
2.6.20.6, FC4:
I created a 91248k ext3 fs with 4k blocksize:
| mke2fs -j -b 4096 /dev/vol1/project
| mke2fs 1.38 (30-Jun-2005)
| Filesystem label=
| OS type: Linux
| Block size=4096 (log=2)
| Fragment size=4096 (log=2)
| 23552 inodes, 23552 blocks
| 1177 blocks (5.00%) reserved for the super
On Sun, May 06, 2007 at 09:40:14PM -0700, Andrew Morton wrote:
On Mon, 7 May 2007 00:26:26 +0200 Frank van Maarseveen [EMAIL PROTECTED]
wrote:
Steps to reproduce:
Create a 3G partition, say /dev/vol1/project
mke2fs -j -b 4096 /dev/vol1/project 22812
mount it
ext2online /dev/vol1
System is a PIII UP 2.4.5-pre1, NFS client, options from /proc/mounts:
arezzo:/usr/src/dolphin /usr/src/dolphin nfs
rw,nodev,v3,rsize=32768,wsize=32768,hard,udp,nolock,addr=arezzo 0 0
Lately my "arpwatch" running on this 2.4.5-pre1 machine started to log
May 15 15:55:18 espoo
Got the image of 3 interesting packets by letting a modified tcpdump dump
the entire packet buffer in arp_print().
Original tcpdump output:
16:23:17.108993 P 0:60:97:ba:b4:f5 0:0:0:0:0:1 arp 1514: arp-#8192 for proto #1500
(138) hardware #17664 (36)
16:23:17.809024 P 0:60:97:ba:b4:f5
The last 1304 bytes of 1.bin and 2.bin are identical to the first 1304 bytes
of the .swp file made by VIM.
--
Frank
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
As the subject already says, reproduced in 2.4.5-pre2.
--
Frank
-
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/majordomo-info.html
Please read the FAQ at
To recap:
The machine is an NFSv3 client. The header of outgoing NFS UDP/IP packets
is sometimes corrupted, such that network sniffers on unrelated systems
report bogus ARP packets. AFAIK there is no data corruption on the
file level because the request is no longer recognized by the NFS
server.
System is a dual PIII. Oops occurred while starting the automounter
(autofs). starting it later on by hand again gave no oops anymore.
ksymoops 2.3.5 on i686 2.4.4-x40. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.4-x40/
1 - 100 of 190 matches
Mail list logo
