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: b200221024
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 Che
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
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
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)
found at PCI 0/4/0
Oct 31 13:36:22 area51 kernel:
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 "unsub
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,
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: *** [script
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 l
While shutting down, /var/log/messages said:
Nov 25 23:15:12 mimas cardmgr[342]: exiting
Nov 25 23:15:14 mimas kernel: Trying to free nonexistent resource <03e0-03e1>
Nov 25 23:15:14 mimas kernel: unloading PCMCIA Card Services
mimas /proc# cat ioports
-001f : dma1
0020-003f : pic1
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 minu
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
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 appea
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), accor
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
stru
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)
found at PCI 0/4/0
Oct 31 13:36:22 area51 kernel: (scsi0) Narrow Channel, SCSI ID=7, 3/255 SCBs
Oct 31 13:36:22 area51 kernel: (scsi0)
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 /lib/modules/2.4.0-
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)
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
[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 ia
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
+ mkd
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 d
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'
plip.c:363
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 us
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 -
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 patch:
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 perfec
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:
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.
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 s
t; VmSize and VmData 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 PROT
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 ju
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
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
phys
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 2
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
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
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.
> Yo
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 re
While I have access to /proc/, readlink fails with EACCES on
/proc//exe
/proc//cwd
/proc//root
even when I own 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 make /proc mounti
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/, readlink fails with EACCES on
> >
> > /proc//exe
> > /proc//cwd
> > /pr
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
$
$
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
s
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:
> &g
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:
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
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
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
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 a
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 0:0:0:0:0:1
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 http://vger.kernel.org/majordomo-inf
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 http://www.tux.org/lk
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: <1>Unable to ha
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 fi
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:
> >
> > "regressio
:
>
> c98451bdb2f3e6d6cc1e03adad641e9497512b49 is first bad commit
> commit c98451bdb2f3e6d6cc1e03adad641e9497512b49
> Author: Frank van Maarseveen <[EMAIL PROTECTED]>
> Date: Mon Jul 9 22:25:29 2007 +0200
>
> NLM: fix source address of callback to client
>
> Use the destination addre
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 befor
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 s
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): Sec
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
colle
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 wit
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
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,
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
> rarel
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
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,
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
>
On Thu, Jan 04, 2007 at 12:43:20AM +0100, Mikulas Patocka wrote:
> On Wed, 3 Jan 2007, Frank van Maarseveen wrote:
> >Currently, large file support is already necessary to handle dvd and
> >video. It's also useful for images for virtualization. So the failing
> >stat()
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 mm
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 some
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 wi
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 fet
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 'setup_trampoli
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 's
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 '
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!
[] show_trace_log_lv
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
D
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 waitin
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 dif
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
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,
> > >
> &g
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:
> >>
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:
> >>>> F
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:[]Not tainted VLI
EFLAGS: 00010083 (2.6.20.6-x153 #1)
EIP
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 umou
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 use
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 /de
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, lim
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
'cpu_coreg
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
96 matches
Mail list logo
