2.4.2-pre1
Mainly a number of small details and some driver updates. The socket datagram handling one is important, and has already been posted separately here on linux-kernel. The VIA driver update is rather important if you have one of the newer VIA chipsets. Linus -pre1: - XMM: don't allow illegal mxcsr values - ACPI: handle non-existent battery strings gracefully - Compaq Smart Array driver update - Kanoj Sarcar: serial console hardware flow control support - ide-cs: revert toc-valid cache checking in 2.4.1 - Vojtech Pavlik: update via82cxxx driver to handle the vt82c686 - raid5 graceful failure handling fix - ne2k-pci: enable device before asking the irq number - sis900 driver update - riva FB driver update - fix silly inode hashing pessimization - add SO_ACCEPTCONN for SuS - remove modinfo hack workaround, all newer modutils do it correctly - datagram socket shutdown fix - mark process as running when it takes a page-fault - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.2-pre1
[ Linux-kernel added to the cc, as others probably also wonder ] On Sat, 3 Feb 2001, David D.W. Downey wrote: > > How often does Alan's patches get rolled into your main line? I'm > having difficulty following the divergence here. I'm trying to run THE > latest release(s) of your kernel with applicaple patches. I'm just trying > to figure out if everything that is in the ac## line is ALWAYS rolled into > your pre## line or not. Which patch sequence am I supposed to follow to > have THE most current release of all fixes et. al.? Alan tends to have much more experimental patches than I do - and we don't sync up more often than maybe once a month or so. And even then, the sync-up won't be complete, exactly because I don't take the experimental parts (or more accurately, Alan mostly doesn't even try to send them to me and we tend to agree pretty well on what is appropriate and what is not). We're nearing another sync-point right now - I actually have a lot of Alans patches in my mail-box, and -pre2 will probably contain a lot of the -ac stuff. But don't expect a complete sync, as explained above. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.2-pre1
On Sat, Feb 03, 2001 at 08:24:27PM -0800, Linus Torvalds wrote: ... > -pre1: ... > - riva FB driver update Er, what exactly is the CONFIG_PREP stuff in this driver supposed to be for? "CONFIG_PREP" doesn't exist anymore to start with, and secondly I'm not sure if any PReP boxes ever shipped with a riva card to start with. The only real way to handle this in 2.4 is something like: #ifdef CONFIG_ALL_PPC /* CHRP/PMAC/PREP */ #include #define isPReP (_machine == _MACH_prep) #else #define isPReP 0 #endif That is, if there's really any need to test explicitly for a PReP box. I asked Ani Joshi about this a while ago, and he wasn't quite sure why they were in there either.. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.2-pre1
Tom Rini wrote: > Er, what exactly is the CONFIG_PREP stuff in this driver supposed to be > for? "CONFIG_PREP" doesn't exist anymore to start with, and secondly I'm > not sure if any PReP boxes ever shipped with a riva card to start with. The > only real way to handle this in 2.4 is something like: > #ifdef CONFIG_ALL_PPC /* CHRP/PMAC/PREP */ > #include > #define isPReP (_machine == _MACH_prep) > #else > #define isPReP 0 > #endif > > That is, if there's really any need to test explicitly for a PReP box. > I asked Ani Joshi about this a while ago, and he wasn't quite sure why they > were in there either.. It looks like it might have come from drivers/video/clgenfb.c, perhaps for use with big endian framebuffers? If the driver works on PPC without CONFIG_PREP code, let's get rid of it. Jeff -- Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.2-pre1
On Tue, Feb 06, 2001 at 01:52:36PM -0500, Jeff Garzik wrote: > Tom Rini wrote: > > Er, what exactly is the CONFIG_PREP stuff in this driver supposed to be > > for? "CONFIG_PREP" doesn't exist anymore to start with, and secondly I'm > > not sure if any PReP boxes ever shipped with a riva card to start with. The > > only real way to handle this in 2.4 is something like: > > #ifdef CONFIG_ALL_PPC /* CHRP/PMAC/PREP */ > > #include > > #define isPReP (_machine == _MACH_prep) > > #else > > #define isPReP 0 > > #endif > > > > That is, if there's really any need to test explicitly for a PReP box. > > I asked Ani Joshi about this a while ago, and he wasn't quite sure why they > > were in there either.. > > It looks like it might have come from drivers/video/clgenfb.c, perhaps > for use with big endian framebuffers? It is indeed from clgen, but even there it's only needed on the PReP boxes with a cirrus logic card. The MacPicasso cards (also clgen) need some other magic (see linux-fbdev). > If the driver works on PPC without CONFIG_PREP code, let's get rid of > it. Well, it's definatly not doing anything now. It probably shouldn't be there anyways, as in clgen it seems to be for PReP black magic. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
APIC Errors with 2.4.2-pre1
First off, here's something from my dmesg. mapped APIC to e000 (fee0) mapped IOAPIC to d000 (fec0) CALLIN, before setup_local_APIC(). ENABLING IO-APIC IRQs ...changing IO-APIC physical APIC ID to 2 ... ok. init IO_APIC IRQs IO-APIC (apicid-pin) 2-0, 2-9, 2-10, 2-11, 2-20, 2-21, 2-22, 2-23 not connected. number of IO-APIC #2 registers: 24. testing the IO APIC... IO APIC #2.. ...: physical APIC id: 02 ... : IO APIC version: 0011 WARNING: unexpected IO-APIC, please mail calibrating APIC timer ... PCI->APIC IRQ transform: (B0,I7,P3) -> 19 PCI->APIC IRQ transform: (B0,I7,P3) -> 19 PCI->APIC IRQ transform: (B0,I10,P0) -> 17 PCI->APIC IRQ transform: (B0,I12,P0) -> 19 PCI->APIC IRQ transform: (B0,I13,P0) -> 18 PCI->APIC IRQ transform: (B0,I14,P0) -> 18 PCI->APIC IRQ transform: (B1,I0,P0) -> 16 Then whenever I do heavy CPU or RAM testing using something like cputest and ubench, I get the following errors in my log.. APIC error on CPU0: 00(08) APIC error on CPU1: 00(08) APIC error on CPU1: 08(08) APIC error on CPU1: 08(08) APIC error on CPU1: 08(08) APIC error on CPU0: 08(08) APIC error on CPU0: 08(08) APIC error on CPU0: 08(08) APIC error on CPU0: 08(08) APIC error on CPU1: 08(08) APIC error on CPU1: 08(08) APIC error on CPU0: 08(08) APIC error on CPU1: 08(02) APIC error on CPU1: 02(02) APIC error on CPU1: 02(08) APIC error on CPU0: 08(02) APIC error on CPU1: 08(01) APIC error on CPU0: 02(02) APIC error on CPU1: 01(02) APIC error on CPU0: 02(02) APIC error on CPU1: 02(04) APIC error on CPU1: 04(04) APIC error on CPU1: 04(02) APIC error on CPU1: 02(08) APIC error on CPU1: 08(02) APIC error on CPU1: 02(02) and on and on and on and on... I found the error codes in /usr/src/linux/arch/i386/kernel/apic.c. I could use a little help though on interpreting the error code(s) returned. Also, from the source code I see that apic_read(APIC_ESR) is called. In /usr/src/linux/include/asm/apicdef.h, I see that APIC_ESR is 0x280 which I take is the offset into the APIC_DEFAULT_PHYS_BASE. Since this is a controller, I'd like to know what the ##(##) represent. I take it that these numbers are the error code the controller reported just before and just after the apic_write(). To me it looks like this was done this way just to save state because the next thing called was the ack_APIC_irq(). Can someone also please explain what the ESR is? (Please forgive my ignorance of this stuff.) -- David D.W. Downey - RHCE Consulting Engineer Ensim Corporation - Sunnyvale, CA - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.2-pre1 mkdep and symlinked $TOPDIR
Keith,
I do builds in /usr/src/linux, which is a symlink
to /usr/src/linux-akpm. The recent `mkdep' changes
have broken this practice most horridly. When searching
.hdepend, `make' doesn't recognise that nested headers
have changed. This is because .hdepend has things like
/usr/src/linux/include/asm/byteorder.h: \
/usr/src/linux-akpm/include/asm/types.h \
So when it looks for dependencies for
/usr/src/linux-akpm/include/asm/byteorder.h
it doesn't find anything. In earlier kernels, the
whole toolchain honoured the symlink form of the name.
The net effect of all this is that changes to included
headers are *not* causing recompiles, and use of a
symlinked $TOPDIR is not feasible.
The workaround at this time is to do a `cd' to the
real $TOPDIR directory before starting development,
rather than a `cd' to the symlink.
If it is your intention that everything in the
build system use the "real" pathname then I suggest
we need to make it happen consistently. Or can we
restore the old behaviour?
--- linux-2.4.3-pre1/scripts/mkdep.cSat Mar 3 20:52:24 2001
+++ linux-akpm/scripts/mkdep.c Sun Mar 4 16:16:00 2001
@@ -218,19 +218,12 @@
void add_path(const char * name)
{
struct path_struct *path;
- char resolved_path[PATH_MAX+1];
const char *name2;
- if (strcmp(name, ".")) {
- name2 = realpath(name, resolved_path);
- if (!name2) {
- fprintf(stderr, "realpath(%s) failed, %m\n", name);
- exit(1);
- }
- }
- else {
+ if (strcmp(name, "."))
+ name2 = name;
+ else
name2 = "";
- }
path_array = realloc(path_array, (++paths)*sizeof(*path_array));
if (!path_array) {
-
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/lkml/
[patch-2.4.2-pre1] rootfs boot parameter
Hi Linus,
This patch adds "rootfs" boot parameter which selects the filesystem type
for the root filesystem. Useful (nay, live-saving :) to distinguish
between filesystems which cannot detect damage to their structural
integrity. E.g. ext2 cannot detect if the block device has had another
filesystem made on it if it's superblock is left intact.
Regards,
Tigran
diff -urN -X ../dontdiff linux/Documentation/kernel-parameters.txt
rootfs/Documentation/kernel-parameters.txt
--- linux/Documentation/kernel-parameters.txt Sat Dec 30 19:23:13 2000
+++ rootfs/Documentation/kernel-parameters.txt Mon Feb 5 13:51:16 2001
@@ -479,7 +479,10 @@
ro [KNL] Mount root device read-only on boot.
- root= [KNL] root filesystem.
+ root= [KNL] Mount root filesystem on specified (as hex or
+"/dev/XXX") device.
+
+ rootfs= [KNL] Use filesystem type specified (e.g. rootfs=ext2) for
+root.
+
rw [KNL] Mount root device read-write on boot.
diff -urN -X ../dontdiff linux/fs/super.c rootfs/fs/super.c
--- linux/fs/super.cTue Jan 16 04:53:11 2001
+++ rootfs/fs/super.c Mon Feb 5 13:54:08 2001
@@ -18,6 +18,7 @@
*Torbjörn Lindh ([EMAIL PROTECTED]), April 14, 1996.
* Added devfs support: Richard Gooch <[EMAIL PROTECTED]>, 13-JAN-1998
* Heavily rewritten for 'one fs - one tree' dcache architecture. AV, Mar 2000
+ * Added rootfs boot param. used by mount_root(): Tigran Aivazian. Feb 2001.
*/
#include
@@ -59,6 +60,12 @@
/* this is initialized in init/main.c */
kdev_t ROOT_DEV;
+/* this can be set at boot time, e.g. rootfs=ext2
+ * if set to an invalid value or if read_super() fails on the specified
+ * filesystem type then mount_root() will panic
+ */
+static char rootfs[32] __initdata = "";
+
int nr_super_blocks;
int max_super_blocks = NR_SUPER;
LIST_HEAD(super_blocks);
@@ -79,6 +86,17 @@
static struct file_system_type *file_systems;
static rwlock_t file_systems_lock = RW_LOCK_UNLOCKED;
+static int __init rootfs_setup(char *line)
+{
+ int n = strlen(line) + 1;
+
+ if (n > 1 && n <= sizeof(rootfs))
+ strncpy(rootfs, line, n);
+ return 1;
+}
+
+__setup("rootfs=", rootfs_setup);
+
/* WARNING: This can be used only if we _already_ own a reference */
static void get_filesystem(struct file_system_type *fs)
{
@@ -1577,6 +1595,16 @@
goto mount_it;
}
+ if (*rootfs) {
+ fs_type = get_fs_type(rootfs);
+ if (fs_type) {
+ sb = read_super(ROOT_DEV,bdev,fs_type,root_mountflags,NULL,1);
+ if (sb)
+ goto mount_it;
+ }
+ /* don't try others if type given explicitly, same behaviour as
+mount(8) */
+ goto fail;
+ }
read_lock(&file_systems_lock);
for (fs_type = file_systems ; fs_type ; fs_type = fs_type->next) {
if (!(fs_type->fs_flags & FS_REQUIRES_DEV))
@@ -1591,7 +1619,8 @@
put_filesystem(fs_type);
}
read_unlock(&file_systems_lock);
- panic("VFS: Unable to mount root fs on %s", kdevname(ROOT_DEV));
+fail:
+ panic("VFS: Unable to mount root %s on %s", *rootfs ? rootfs : "fs",
+kdevname(ROOT_DEV));
mount_it:
printk ("VFS: Mounted root (%s filesystem)%s.\n",
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[UPDATE] New zerocopy against 2.4.2-pre1
In the usual spot: ftp://ftp.kernel.org/pub/linux/kernel/people/davem/zerocopy-2.4.2p1-1.diff.gz Changes since last installment: 1) Merge in lots of AC patch fixes, from Alan. 2) Use more reasonable MTU for loopback under Zerocopy, basically it's 16K + sizeof TCP/IP headers now. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.2-pre1: kernel oops during unmount
2.4.2-pre1 + ReiserFS 3.6.25 (included) + loop-4 ksymoops 2.3.7 on i686 2.4.2-pre1. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.2-pre1/ (default) -m /boot/System.map (specified) Unable to handle kernel NULL pointer dereference at virtual address c0143023 *pde = Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00013206 eax: c14d3e00 ebx: c81051c0 ecx: cfa3f000 edx: cf7f36c0 esi: edi: ebp: ce469f3c esp: ce469f04 ds: 0018 es: 0018 ss: 0018 Process umount (pid: 9117, stackpage=ce469000) Stack: c14d3e00 ce469f3c ce469f3c c025d5b8 c01430d5 c025bf1c c14d3e00 ce469f3c c14d3e00 cf9b32c0 c025d580 c025d5b8 ce469f3c ce469f3c c01354d3 c14d3e00 c14c0440 c14d3e00 b53c c0134839 c01358d1 Call Trace: [] [] [] [] [] [] [] [] Code: 8b 3f 3b 74 24 1c 74 65 8d 5e f8 8b 44 24 20 39 83 8c 00 00 >>EIP; c0143023<= Trace; c01430d5 Trace; c01354d3 Trace; c0134839 Trace; c01358d1 Trace; c01359aa Trace; c0122fcb Trace; c01359eb Trace; c0108fe7 Code; c0143023 <_EIP>: Code; c0143023<= 0: 8b 3f mov(%edi),%edi <= Code; c0143025 2: 3b 74 24 1c cmp0x1c(%esp,1),%esi Code; c0143029 6: 74 65 je 6d <_EIP+0x6d> c0143090 Code; c014302b 8: 8d 5e f8 lea0xfff8(%esi),%ebx Code; c014302e b: 8b 44 24 20 mov0x20(%esp,1),%eax Code; c0143032 f: 39 83 8c 00 00 00 cmp%eax,0x8c(%ebx) -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: APIC errors with 2.4.2-pre1
OK, talked with someone who knows a little more about this than i do. According to him, one reason I may be getting these errors is due to the fact that the HPT370 controller is using IRQ18 which falls in the APIC extended IRQ range (16 - 31). If this is a problem is there a work-around? I don't know how to change the IRQ the HPT370 is using since it's an onboard card. -- David D.W. Downey - RHCE Consulting Engineer Ensim Corporation - Sunnyvale, CA - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Problems with 2.4.2-pre1 & reiser & vfs
Hello, I have dual PIII 800 machine running as mail server on DAC 960 RAID & reiserfs comming with 2.4.1kernel. Under very high loads I get following messages in my kernel log: kernel: vs-13060: reiserfs_update_sd: stat data of object [7906789 7906806 0x0 SD](nlink == 1) not found (pos 23) kernel: vs-13060: reiserfs_update_sd: stat data of object [7906789 7906806 0x0 SD] (nlink == 1) not found (pos 23) kernel: PAP-5660: reiserfs_do_truncate: wrong result -1 of search for [7906789 7906806 0xfff DIRECT] kernel: vs-13060: reiserfs_update_sd: stat data of object [7906789 7906806 0x0 SD] (nlink == 1) not found (pos 23) kernel: PAP-5660: reiserfs_do_truncate: wrong result -1 of search for [7906789 7906806 0xfff DIRECT] . and afterwards come these: kernel: vs-3050: wait_buffer_until_released: nobody releases buffer (dev 30:09, size 4096, blocknr 1661732, count 16, kernel: vs-3050: wait_buffer_until_released: nobody releases buffer (dev 30:09, size 4096, blocknr 1661732, count 16, ... and so on. The interesting thing is that system is still operational, but load jumps up to 260 or so, and any attempts to reboot system fail. ps aux shows that there exists imortal (kill -9 $PID doesn't kill it) qmail process that consumes 97% of one CPU's resources. Also `vmstat` shows tons of processes in uninterruptable sleep, but `free` reports that it is still enough memory (no swap used) and huge buffers... Machine gets slugish but works for a while (0.5-2h dependent on mail request rate). System is Debian potato, gcc version 2.95.2 2220 (Debian GNU/Linux), reiserfs utils 3.6.25. Any patches or suggestions to fix that would be appreciated... P.S. Also I thought wouldn't it be good to have some sysctl entry in proc that rebooted machine dependent on the value in control file when proper software reboot is impossible (like in situation described above)? Or probably there already exist(s) such thing(s)? Thanks. -- Andrius [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.2-pre1 mkdep and symlinked $TOPDIR
On Sun, 04 Mar 2001 16:24:57 +1100, Andrew Morton <[EMAIL PROTECTED]> wrote: >I do builds in /usr/src/linux, which is a symlink >to /usr/src/linux-akpm. The recent `mkdep' changes >have broken this practice most horridly. When searching >.hdepend, `make' doesn't recognise that nested headers >have changed. This is because .hdepend has things like > >/usr/src/linux/include/asm/byteorder.h: \ > /usr/src/linux-akpm/include/asm/types.h \ I do not see this problem in 2.4.3-pre2. # ls -l linux lrwxrwxrwx 1 kaos ocs10 Mar 5 10:47 linux -> 2.4.3-pre2 # cd linux # make dep make dep gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/mkdep scripts/mkdep.c make[1]: Entering directory `/usr/src/2.4.3-pre2/arch/i386/boot' make[1]: Nothing to be done for `dep'. make[1]: Leaving directory `/usr/src/2.4.3-pre2/arch/i386/boot' scripts/mkdep -- init/*.c > .depend scripts/mkdep -- `find /usr/src/2.4.3-pre2/include/asm /usr/src/2.4.3-pre2/include/linux /usr/src/2.4.3-pre2/include/scsi /usr/src/2.4.3-pre2/include/net -name SCCS -prune -o -follow -name \*.h ! -name modversions.h -print` > .hdepend The find command is given the real pathname, not the symlink so the .hdepend and .depend files all contain the real paths. Your problem is probably this line in the top level Makefile. TOPDIR := $(shell if [ "$$PWD" != "" ]; then echo $$PWD; else pwd; fi) TOPDIR must be getting set to the symlink name instead of the real pathname. Can you confirm what TOPDIR is being set to and why? This may be a shell problem. TOPDIR := $(shell if [ "$$PWD" != "" ]; then echo $$PWD; else pwd; fi) dummy := $(shell echo PWD="$$PWD" pwd=$(shell pwd) TOPDIR=$(TOPDIR) >&2) - 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/lkml/
Re: [patch-2.4.2-pre1] rootfs boot parameter
Tigran Aivazian wrote: > This patch adds "rootfs" boot parameter which selects the filesystem type > for the root filesystem. Could you please make this rootfstype= or fstype= or maybe root=[,] or such ? Calling it "rootfs" is just asking for trouble ... - Werner -- _ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch-2.4.2-pre1] rootfs boot parameter
ok, since so many people ask for it to be called "rootfstype=", I will do so and resend the patch. Any other comments? I think on the last round I have incorporated all the comments (except the "rootfs" -> "rootfstype" one)... Tigran On Mon, 5 Feb 2001, Werner Almesberger wrote: > Tigran Aivazian wrote: > > This patch adds "rootfs" boot parameter which selects the filesystem type > > for the root filesystem. > > Could you please make this rootfstype= or fstype= or maybe > root=[,] or such ? Calling it "rootfs" is just asking > for trouble ... > > - Werner > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Oops on UHCI module unload (2.4.2-pre1)
When trying to figure out how to get USB to work (it was the MPS setting, more in other post) I got a repeatable Oops (is it an oops? it doesn't say "Oops!" like I thought they do). That is, I'd boot, modprobe uhci, plug something in, get lots of timeouts, unplug the something, modprobe -r uhci. Oops. Attached are two ksymoops outputs, for the two times I did this. I stopped modprobe -r'ing after that, then fixed the problem wrt timeouts, and am now unable to reproduce the bug (even going back to MPS 1.4). Let me know if there's anything else of use I can provide, and if I got the ksymoops thing right :) -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: Amnesia used to be my favorite word, but then I forgot it. ksymoops.out.1.gz ksymoops.out.2.gz
Re: Problems with 2.4.2-pre1 & reiser & vfs
On Thursday, February 08, 2001 04:00:26 PM +0100 Andrius Adomaitis <[EMAIL PROTECTED]> wrote: > > Hello, > > I have dual PIII 800 machine running as mail server on DAC 960 RAID & > reiserfs comming with 2.4.1kernel. > > Under very high loads I get following messages in my kernel log: > > kernel: vs-13060: reiserfs_update_sd: stat data of object [7906789 > 7906806 0x0 SD](nlink == 1) not found (pos 23) > kernel: vs-13060: reiserfs_update_sd: stat data of object [7906789 > 7906806 0x0 SD] (nlink == 1) not found (pos 23) > kernel: PAP-5660: reiserfs_do_truncate: wrong result -1 of search for > [7906789 7906806 0xfff DIRECT] > kernel: vs-13060: reiserfs_update_sd: stat data of object [7906789 > 7906806 0x0 SD] (nlink == 1) not found (pos 23) > kernel: PAP-5660: reiserfs_do_truncate: wrong result -1 of search for > [7906789 7906806 0xfff DIRECT] > . These aren't good at all, and show a general corruption problem. I know the ac kernels have at least one small DAC960 bug fixes, are there other fixes pending? > > and afterwards come these: > > kernel: vs-3050: wait_buffer_until_released: nobody releases buffer > (dev 30:09, size 4096, blocknr 1661732, count 16, > kernel: vs-3050: wait_buffer_until_released: nobody releases buffer > (dev 30:09, size 4096, blocknr 1661732, count 16, > ... > and so on. > There is more info in this message, it would help if you could send the entire line. > The interesting thing is that system is still operational, but load > jumps up to 260 or so, and any attempts to reboot system fail. ps aux > shows that there exists imortal (kill -9 $PID doesn't kill it) qmail > process that consumes 97% of one CPU's resources. Also `vmstat` shows > tons of processes in uninterruptable sleep, but `free` reports that it > is still enough memory (no swap used) and huge buffers... Machine gets > slugish but works for a while (0.5-2h dependent on mail request rate). > Once you get a vs-3050, any process that tries to change the FS ends up waiting on the journal, which is waiting on the process stuck in vs-3050. There is no escape. -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with 2.4.2-pre1 & reiser & vfs
> > kernel: PAP-5660: reiserfs_do_truncate: wrong result -1 of search for > > [7906789 7906806 0xfff DIRECT] > > . > > These aren't good at all, and show a general corruption problem. I know the ac >kernels have at least one small DAC960 bug fixes, are there other fixes pending? > The dac960 changes relate to gcc 2.96 stuff and wouldnt account for real bugs. DAC960 built with cvs gcc or 2.96 < 2.96-74 or so could do because of the ABI thing but wouldnt boot that far. If its straight 2.4.1 suspect the elevator corruption thing too - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Oops on UHCI module unload (2.4.2-pre1)
On Tue, 6 Feb 2001 05:40:40 -0300, John R Lenton <[EMAIL PROTECTED]> wrote: >When trying to figure out how to get USB to work (it was the MPS >setting, more in other post) I got a repeatable Oops (is it an >oops? it doesn't say "Oops!" like I thought they do). The kernel makes you guess what the error messages are, to add some spice to life :-) >Attached are two ksymoops outputs, for the two times I did this. Error (expand_objects): cannot stat(/lib/modules/2.4.2-pre1/kernel/drivers/usb/uhci.o) for uhci Error (expand_objects): cannot stat(/lib/modules/2.4.2-pre1/kernel/drivers/usb/usbcore.o) for usbcore Error (expand_objects): cannot stat(/lib/modules/2.4.2-pre1/kernel/drivers/input/mousedev.o) for mousedev Error (expand_objects): cannot stat(/lib/modules/2.4.2-pre1/kernel/drivers/input/input.o) for input Feb 4 04:32:20 burocracia kernel: Unable to handle kernel paging request at virtual address d10ff9e8 ksymoops could not find the modules you loaded. Did you rename, delete or overwrite /lib/modules/2.4.2-pre1 between the oops and the time you ran ksymoops? Error (expand_objects): cannot stat(/lib/modules/2.4.2-pre1/kernel/drivers/usb/uhci.o) for uhci Error (expand_objects): cannot stat(/lib/modules/2.4.2-pre1/kernel/drivers/usb/usbcore.o) for usbcore Warning (expand_objects): object /lib/modules/2.4.2-pre1/kernel/drivers/net/ppp_deflate.o for module ppp_deflate has changed since load Warning (expand_objects): object /lib/modules/2.4.2-pre1/kernel/drivers/net/bsd_comp.o for module bsd_comp has changed since load Warning (expand_objects): object /lib/modules/2.4.2-pre1/kernel/drivers/net/ppp_async.o for module ppp_async has changed since load Warning (expand_objects): object /lib/modules/2.4.2-pre1/kernel/drivers/net/ppp_generic.o for module ppp_generic has changed since load Warning (expand_objects): object /lib/modules/2.4.2-pre1/kernel/drivers/net/slhc.o for module slhc has changed since load ksymoops could could not find some modules, those it could find have changed since the oops. I would treat all your traces with suspicion, the base data is very unreliable. Try to reproduce with current modules, instead of modules that have changed since the oops. BTW, do not specify -O unless you have a good reason to ignore objects, which you don't. You should supply a system map with -m instead of suppressing it with -M. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.2-pre1 won't boot on my SMP P-II
Last kernel that booted was Redhat's build of 2.4.0-pre11. I'm not sure where the issue is at, so I attach a log of the system booting up. It's an ASUS P2B-DS with dual Deschutes PII-450s. Anybody with a clue as to where to look, please advise. (Have other boot logs) -- .:. Bryan W. Headley - [EMAIL PROTECTED] bootup-2.4.2-pre1.log
Re: 2.4.2-pre1 won't boot on my SMP P-II
Bryan W. Headley writes: > Last kernel that booted was Redhat's build of 2.4.0-pre11. I'm not sure > where the issue is at, so I attach a log of the system booting up. > > It's an ASUS P2B-DS with dual Deschutes PII-450s. > Linux version 2.4.2-pre1 ([EMAIL PROTECTED]) (gcc version 2.96 2731 >(Red Hat Linux 7.0)) #1 SMP Sun Feb 4 15:57:05 CST 2001 gcc 2.96 -- is this the vanilla RH7.0 gcc or the updated one? The vanilla one is known to miscompile stuff. Use kgcc, 2.95.2, or the updated RH7.0 gcc. > md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 > md.c: sizeof(mdp_super_t) = 4096 > autodetecting RAID arrays > autorun ... > ... autorun DONE. > ACPI: Core Subsystem version [20010125] > LNMI Watchdog detected LOCKUP on CPU0, registers: > CPU:0 > EIP:0010:[] > EFLAGS: 0086 > eax: ebx: 000f8040 ecx: 0001 edx: c0272b42 > esi: cfd6ff70 edi: cfd6e331 ebp: esp: cfd6ff48 > ds: 0018 es: 0018 ss: 0018 > Process kacpid (pid: 7, stackpage=cfd6f000) > Stack: 0286 0007 00c7 c01c10c1 000f8040 cfd6ff70 cfd6e331 >c01d47fa c0272b42 003c cfd6ffa0 000f8040 > cfd6e000 0001 cfd6e000 20010125 0003 > Call Trace: [] [] [] [] [] > > Code: 80 3d 20 50 29 c0 00 f3 90 7e f5 e9 93 5c ee ff 80 3d 20 50 > console shuts up ... The NMI watchdog detected an apparent lockup (interrupts masked for too long) during boot. This is fatal. Note that the last message before the oops mentioned "ACPI" and the process killed is "kacpid". Hmm, I don't know how well ACPI works on SMP (or at all), but you should try a new kernel built with ACPI disabled. /Mikael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.2-pre1 won't boot on my SMP P-II
Mikael Pettersson wrote:
> Bryan W. Headley writes:
> > Last kernel that booted was Redhat's build of 2.4.0-pre11. I'm not sure
> > where the issue is at, so I attach a log of the system booting up.
> >
> > It's an ASUS P2B-DS with dual Deschutes PII-450s.
>
> > Linux version 2.4.2-pre1 ([EMAIL PROTECTED]) (gcc version 2.96 2731
>(Red Hat Linux 7.0)) #1 SMP Sun Feb 4 15:57:05 CST 2001
>
> gcc 2.96 -- is this the vanilla RH7.0 gcc or the updated one? The vanilla one
> is known to miscompile stuff. Use kgcc, 2.95.2, or the updated RH7.0 gcc.
>
The updated one. On suggestion, I upgraded the BIOS which seems to have fixed the
issue.
>
> > md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
> > md.c: sizeof(mdp_super_t) = 4096
> > autodetecting RAID arrays
> > autorun ...
> > ... autorun DONE.
> > ACPI: Core Subsystem version [20010125]
> > LNMI Watchdog detected LOCKUP on CPU0, registers:
> > CPU:0
> > EIP:0010:[]
> > EFLAGS: 0086
> > eax: ebx: 000f8040 ecx: 0001 edx: c0272b42
> > esi: cfd6ff70 edi: cfd6e331 ebp: esp: cfd6ff48
> > ds: 0018 es: 0018 ss: 0018
> > Process kacpid (pid: 7, stackpage=cfd6f000)
> > Stack: 0286 0007 00c7 c01c10c1 000f8040 cfd6ff70 cfd6e331
> >c01d47fa c0272b42 003c cfd6ffa0 000f8040
> > cfd6e000 0001 cfd6e000 20010125 0003
> > Call Trace: [] [] [] [] []
> >
> > Code: 80 3d 20 50 29 c0 00 f3 90 7e f5 e9 93 5c ee ff 80 3d 20 50
> > console shuts up ...
>
> The NMI watchdog detected an apparent lockup (interrupts masked
> for too long) during boot. This is fatal. Note that the last message
> before the oops mentioned "ACPI" and the process killed is "kacpid".
> Hmm, I don't know how well ACPI works on SMP (or at all), but you
> should try a new kernel built with ACPI disabled.
>
> /Mikael
--
.:.
Bryan W. Headley - [EMAIL PROTECTED]
N§²æìr¸yúèØb²X¬¶Ç§vØ^)Þº{.nÇ+·¥{±êçzX§¶¡Ü¨}©²Æ zÚ&j:+v¨¾«êçzZ+ù^jÇ«y§m
á@A«a¶Úÿ
0¶ìh®åi
