Re: Problems with reiserfs
Patrick Mackinlay : If your use redhat 7.0 ;Your will check the kernel "Makefile" ,change the gcc to kgcc , Try again ! Update the gcc from http://www.redhat.com/ > <_EIP>: >Code; d2cf9db8 <[reiserfs]create_virtual_node+298/490> <= > 0: 8b 40 14 mov0x14(%eax),%eax <= >Code; d2cf9dbb <[reiserfs]create_virtual_node+29b/490> > 3: ff d0 call *%eax > < *eax ==0 >Code; d2cf9dbd <[reiserfs]create_virtual_node+29d/490> -- Hu Gang Email : [EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED] Comany : China Beijing Soul Phone : +860168425741~~44 MP : 13601394711 Linux Reigstered User ID#204016 - 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: binfmt-464c and 2.4.1
[Drew Bertola] > Feb 23 20:48:24 babylon modprobe: modprobe: Can't locate module binfmt-464c > Although I've looked through the documentation, I can't find any > reference to binfmt-464c. binfmt-464c is ELF -- it means your kernel came across an ELF executable and was unable to execute it so it tried to load the ELF binary format module. Since you have ELF compiled into your kernel already, this didn't work. My guess is that you have a corrupt ELF executable on your system, which your ELF loader refuses to load. Every time someone tries to execute it, your kernel will do a 'modprobe -k binfmt-464c'. If you can't find the executable in question and just want to get the message out of your logs, add alias binfmt-464c off to your /etc/modules.conf . Peter - 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: PROBLEM: loopback block device freezes mount
[Jon Hart] > 1. I am unable to mount loopback block devices using kernel 2.4.2. Apparently fixed in -ac3. Peter - 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/
PROBLEM: loopback block device freezes mount
Per /usr/src/linux/REPORTING-BUGS... 1. I am unable to mount loopback block devices using kernel 2.4.2. 2. Using the 2.4.2 kernel, the mount command freezes while trying to mount /dev/loop0. Further, the mount command will not die even with kill -9. I have not experienced this problem in kernel 2.4.1 and below; however, I did experience the problem with 2.4.2-pre4. 3. Keywords: loopback block mount 4. /proc/version Linux version 2.4.2-jah01 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #2 Fri Feb 23 21:54:34 PST 2001 5. No Oops.. message 6. The specific command I'm using is... mount -t iso9660 -oro,loop=/dev/loop0 /mnt/cdrom /apath/animage.iso On my system, the above command will hang until reboot. I can change virtual terminals etc. However, after the above command is issued, no filesystems can be mounted/unmounted until the system is restarted (even the shutdown hangs while trying to unmount all filesystems). 7. No modules loaded (e.g. loopback, nic, sound compiled directly into the kernel). Thanks for your help. Please let me know if you need any additional information. -- =-=-=-=-=-=-=-=-=-=-=-=-= Jonathan Hart =-=-=-=-=-=-=-=-=-=-=-=-= - 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: reiserfs: still problems with tail conversion
From: Michal Gornisiewicz <[EMAIL PROTECTED]> Subject: Re: reiserfs: still problems with tail conversion Date: Sat, 24 Feb 2001 10:52:07 +0800 Message-ID: <[EMAIL PROTECTED]> I'm running 2.4.2ac3 and tried also the reisertest program. No problems here... The created files are all of 8192 bytes. Partition size was 1Gig. keep hacking the right site of life ! :-) Meino > I'm running 2.4.2 and I get similar results using your test program. > This is on an IBM 390 Laptop. P2-233, 96mb RAM, 3.2gb HDD. > > See program results below. I can supply more info > (.config etc, & do testing) if needed. > > MG > - 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: [rfc] Near-constant time directory index for Ext2
Andries,
> > int hash_fn (char * p)
> > {
> > int hash = 0;
> > while (*p) {
> > hash = hash + *p;
> > // Rotate a 31 bit field 7 bits:
> > hash = ((hash << 7) | (hash >> 24)) & 0x7fff;
> > }
> > return hash;
> > }
>
> Hmm. This one goes in the "catastrophic" category.
>
> For actual names:
>
> N=557398, m=51 sz=2048, min 82, max 4002, av 272.17, stddev 45122.99
>
> For generated names:
>
> N=557398, m=51 sz=2048, min 0, max 44800, av 272.17, stddev 10208445.83
>
Instead of masking the hash value down to 11 bits you could try:
index = (hash ^ (hash >> 11) ^ (hash >> 22)) & 0x7ff;
I ran a quick test which gave fairly good results with that: 12871
identifiers
from a source tree) gave a mean square bucket size of 45.65, expected
value for a random function is 45.78.
That change might improve some of your other hashes as well - there
doesn't
seem to be much point in computing a 32 bit value only to throw 20 bits
away -
stirring in the extra bits makes much more sense to me.
> > The rotate is equivalent to a multiplication by x**7 in Z_2[P=0],
> > where P is the polynomial x**31 - 1 (over Z_2).
> > Presumably the "best" P would be irreducible - but that would have more
> > bits set in the polynomial, making reduction harder. A compromise is to
> > choose P in the form x**N - 1 but with relatively few factors.
> > X**31 - 1 is such a P.
>
> It has seven irreducible factors. Hardly "almost irreducible".
I didn't say it was. "almost irreducible" polynomials with Hamming
weight two are pretty rare... Relative to say, x**32 - 1 or x**24 - 1,
having 7 factors is good.
Ralph.
-
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: APM suspend system lockup under 2.4.2 and 2.4.2ac1
i thought that it was my network driver (xircom), but i recompiled 2.4.2 without sound support and apm --suspend has begun to work again. the sound card is a yamaha YMF-744B. i hadn't been compiling with sound support (i dont care about sound on my laptop), but when i got 2.4.2 i decided to try, and now i'm pretty sure that was the problem. is there anything else i should do, or information i could provide that would confirm this analysis or help to find a fix? --- Alan Cox <[EMAIL PROTECTED]> wrote: > Can you see if 2.4.1ac20 was ok > __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ - 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: APM suspend system lockup under 2.4.2 and 2.4.2ac1
i thought that it was my network driver, but i recompiled 2.4.2 without sound support and apm --suspend has begun to work again. the sound card is a yamaha YMF-744B. i hadn't been compiling with sound support (i dont care about sound on my laptop), but when i got 2.4.2 i decided to try, and now i'm pretty sure that was the problem. is there anything else i should do, or information i could provide that would confirm this analysis or help to find a fix? --- Alan Cox <[EMAIL PROTECTED]> wrote: > Can you see if 2.4.1ac20 was ok > __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ - 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: Linux 2.4.1-ac15
This new one should be better. Using the spinlock for the SMP serialization is
ok because that's an extremely slow path.
diff -urN -X /home/andrea/bin/dontdiff 2.4.2/arch/i386/mm/fault.c
2.4.2aa/arch/i386/mm/fault.c
--- 2.4.2/arch/i386/mm/fault.c Thu Feb 22 03:44:53 2001
+++ 2.4.2aa/arch/i386/mm/fault.cSat Feb 24 05:41:11 2001
@@ -326,23 +326,27 @@
int offset = __pgd_offset(address);
pgd_t *pgd, *pgd_k;
pmd_t *pmd, *pmd_k;
+ static spinlock_t lazy_vmalloc_lock = SPIN_LOCK_UNLOCKED;
+ unsigned long flags;
pgd = tsk->active_mm->pgd + offset;
pgd_k = init_mm.pgd + offset;
- if (!pgd_present(*pgd)) {
- if (!pgd_present(*pgd_k))
- goto bad_area_nosemaphore;
+ spin_lock_irqsave(_vmalloc_lock, flags);
+ if (!pgd_present(*pgd) && pgd_present(*pgd_k)) {
set_pgd(pgd, *pgd_k);
+ spin_unlock_irqrestore(_vmalloc_lock, flags);
return;
}
-
pmd = pmd_offset(pgd, address);
pmd_k = pmd_offset(pgd_k, address);
- if (pmd_present(*pmd) || !pmd_present(*pmd_k))
- goto bad_area_nosemaphore;
- set_pmd(pmd, *pmd_k);
- return;
+ if (!pmd_present(*pmd) && pmd_present(*pmd_k)) {
+ set_pmd(pmd, *pmd_k);
+ spin_unlock_irqrestore(_vmalloc_lock, flags);
+ return;
+ }
+ spin_unlock_irqrestore(_vmalloc_lock, flags);
+ goto bad_area_nosemaphore;
}
}
diff -urN -X /home/andrea/bin/dontdiff 2.4.2/arch/i386/mm/init.c
2.4.2aa/arch/i386/mm/init.c
--- 2.4.2/arch/i386/mm/init.c Sat Feb 10 02:34:03 2001
+++ 2.4.2aa/arch/i386/mm/init.c Fri Feb 23 19:09:25 2001
@@ -116,21 +116,13 @@
pte_t *pte;
pte = (pte_t *) __get_free_page(GFP_KERNEL);
- if (pmd_none(*pmd)) {
- if (pte) {
- clear_page(pte);
- set_pmd(pmd, __pmd(_KERNPG_TABLE + __pa(pte)));
- return pte + offset;
- }
- set_pmd(pmd, __pmd(_KERNPG_TABLE + __pa(get_bad_pte_table(;
- return NULL;
+ if (pte) {
+ clear_page(pte);
+ set_pmd(pmd, __pmd(_KERNPG_TABLE + __pa(pte)));
+ return pte + offset;
}
- free_page((unsigned long)pte);
- if (pmd_bad(*pmd)) {
- __handle_bad_pmd_kernel(pmd);
- return NULL;
- }
- return (pte_t *) pmd_page(*pmd) + offset;
+ set_pmd(pmd, __pmd(_KERNPG_TABLE + __pa(get_bad_pte_table(;
+ return NULL;
}
pte_t *get_pte_slow(pmd_t *pmd, unsigned long offset)
diff -urN -X /home/andrea/bin/dontdiff 2.4.2/include/asm-i386/pgalloc-3level.h
2.4.2aa/include/asm-i386/pgalloc-3level.h
--- 2.4.2/include/asm-i386/pgalloc-3level.h Fri Dec 3 20:12:23 1999
+++ 2.4.2aa/include/asm-i386/pgalloc-3level.h Fri Feb 23 19:03:14 2001
@@ -53,12 +53,9 @@
if (!page)
page = get_pmd_slow();
if (page) {
- if (pgd_none(*pgd)) {
- set_pgd(pgd, __pgd(1 + __pa(page)));
- __flush_tlb();
- return page + address;
- } else
- free_pmd_fast(page);
+ set_pgd(pgd, __pgd(1 + __pa(page)));
+ __flush_tlb();
+ return page + address;
} else
return NULL;
}
non pae mode is still untested but it should now have a chance to work.
Andrea
-
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/
Felicidades y bienvenido a dobleU.com!
Para quienes trabajamos en dobleU es un gusto informarte que tu sitio http://www.mazingerz.org ha sido agregado a nuestro directorio por haber cumplido con estandares estrictos de calidad. La certificacion dobleU se otorga unicamente a aquellos sitios que, despues de ser evaluados por nuestro equipo editorial, cumplen con los requisitos de contenido, diseno, profesionalismo, originalidad y funcionalidad. La mision de dobleU es brindar una herramienta de busqueda mas segura y eficiente, para esto vamos a evaluar todos los sitios de Internet en espanol y portugues. Hasta el momento hemos evaluado mas de 100,000 sitios y solo 40,000 se han hecho acreedores al Certificado de Calidad dobleU. Estos podran portar el reconocimiento en sus paginas. Nuestros esfuerzos se han enfocado a sitios regionales y de paises como Argentina, Chile, Colombia, Espana, Mexico, Uruguay y Venezuela. Pronto estaremos abriendo aun mas nuestro campo de accion para cumplir nuestro objetivo de evaluar todos los sitios en espaqol y portuguis. El esfuerzo de dobleU, unido a la cultura de calidad presente en los sitios seleccionados y a una intensiva campana de publicidad en toda America Latina, pretende conscientizar a los usuarios de la red sobre la necesidad de exigir un nivel mmnimo de calidad en los sitios que ingresan. El utilizar sitios que han sido previamente evaluados por editores especialistas en sus areas, ofrece ventajas de tiempo y eficiencia a los usuarios de la red. De nuevo felicidades por tu sitio. Te invitamos a que portes con orgullo el certificado dobleU en tu pagina. Puedes obtenerlo en http://www.dobleu.com/bin/certificado.du?ID=83034=certificado Si tienes alguna duda o comentario no dudes en contactarnos en [EMAIL PROTECTED] Atentamente, Humberto Guzman Federico Clariond Director General Director de Operaciones - 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/
binfmt-464c and 2.4.1
I've noticed this in my logfile: Feb 23 20:48:24 babylon modprobe: modprobe: Can't locate module binfmt-464c Although I've looked through the documentation, I can't find any reference to binfmt-464c. Can anyone point me in the right direction? -- Drew Bertola | Send a text message to my pager or cell ... | http://jpager.com/Drew - 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: Need help as a Linux newcomer
On Fri, 23 Feb 2001, Dwayne C. Litzenberger wrote: > I tried asking this before; never got an answer. > > I suggest you just spend 20 hours or so figuring out the basic structure of > the kernel sources. It's a long run, but you'll be happy once you do. OK, I hate to CC all these lists, but I guess it would be best to try and end this thread now ;) If you want to learn about the structure of the Linux kernel, you should probably go to: http://kernelnewbies.org/ and irc.openprojects.net #kernelnewbies You can also try the mailing list: echo subscribe kernelnewbies | mail [EMAIL PROTECTED] And please ... stop this thread on all the other mailing lists, move your discussions to a more suitable forum and limit it to that forum. regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - 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: Linux 2.4.1-ac15
On Fri, Feb 23, 2001 at 01:09:02PM -0800, Linus Torvalds wrote: > > > On Fri, 23 Feb 2001, Andrea Arcangeli wrote: > > > > I think that can't happen. Infact I think the whole section: > > > > pmd = pmd_offset(pgd, address); > > pmd_k = pmd_offset(pgd_k, address); > > > > if (pmd_present(*pmd) || !pmd_present(*pmd_k)) > > goto bad_area_nosemaphore; > > set_pmd(pmd, *pmd_k); > > return; > > > > is superflows. > > No. Think about the differences in PAE and non-PAE mode. > > > The middle pagetable is shared and the pmd_t entry is set by vmalloc itself (it > > just points to the as well shared pte), it's only the pgd that is setup lazily > > In non-PAE mode, the pgd entry doesn't exist. pgd_present() returns a > unconditional 1. Its' the pmd functions that kick in then. Woops, I see, I was thinking only PAE mode indeed 8), sorry. Thanks for the correction. All the rest still applies (and the patch still looks fine for PAE mode). I think I only need to rediff my patch after resurrecting the pmd thing inside the cli critical section in a #ifndef CONFIG_X86_PAE region. Andrea - 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] partitions/ibm.c
Reading patch-2.4.2 I met a strange amount of crap in
partitions/ibm.c. It is as if the author does not know
where the kernel keeps the starting offset of a partition,
and simulates a HDIO_GETGEO ioctl from user space.
I think the following patch does the same and removes a lot
of cruft. (Warning: (i) untested, uncompiled; (ii) pasted
from another window - tabs will have become spaces.)
Andries
-
diff -u --recursive --new-file ../linux-2.4.2/linux/fs/partitions/ibm.c ./linux/
fs/partitions/ibm.c
--- ../linux-2.4.2/linux/fs/partitions/ibm.cSat Feb 24 03:44:02 2001
+++ ./linux/fs/partitions/ibm.c Sat Feb 24 04:04:33 2001
@@ -60,56 +60,22 @@
}
int
-ibm_partition(struct gendisk *hd, kdev_t dev, unsigned long first_sector, int
-first_part_minor)
+ibm_partition(struct gendisk *hd, kdev_t dev, unsigned long first_sector,
+ int first_part_minor)
{
struct buffer_head *bh;
ibm_partition_t partition_type;
char type[5] = {0,};
char name[7] = {0,};
- struct hd_geometry geo;
- mm_segment_t old_fs;
int blocksize;
- struct file *filp = NULL;
- struct inode *inode = NULL;
- int offset, size;
+ int start, offset, size;
- blocksize = hardsect_size[MAJOR(dev)][MINOR(dev)];
- if ( blocksize <= 0 ) {
- return 0;
- }
+ blocksize = get_hardsect_size(dev);
set_blocksize(dev, blocksize); /* OUCH !! */
- /* find out offset of volume label (partn table) */
- inode = get_empty_inode();
- inode -> i_rdev = dev;
-#if (LINUX_VERSION_CODE > KERNEL_VERSION(2,3,98))
- inode -> i_bdev = bdget(kdev_t_to_nr(dev));
-#endif /* KERNEL_VERSION */
- filp = (struct file *)kmalloc (sizeof(struct file),GFP_KERNEL);
- if (!filp)
- return 0;
- memset(filp,0,sizeof(struct file));
- filp ->f_mode = 1; /* read only */
- blkdev_open(inode,filp);
- old_fs=get_fs();
- set_fs(KERNEL_DS);
-#if (LINUX_VERSION_CODE > KERNEL_VERSION(2,3,98))
- inode-> i_bdev -> bd_op->ioctl (inode, filp, HDIO_GETGEO, (unsigned long
)());
-#else
- filp->f_op->ioctl (inode, filp, HDIO_GETGEO, (unsigned long)());
-#endif /* KERNEL_VERSION */
- set_fs(old_fs);
-#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,0))
-blkdev_put(inode->i_bdev,BDEV_FILE);
-#elif (LINUX_VERSION_CODE > KERNEL_VERSION(2,3,98))
- blkdev_close(inode,filp);
-#else
- blkdev_release(inode);
-#endif /* LINUX_VERSION_CODE */
-
- size = hd -> sizes[MINOR(dev)]<<1;
- if ( ( bh = bread( dev, geo.start, blocksize) ) != NULL ) {
+ start = hd->part[MINOR(dev)].start_sect;
+ size = hd->sizes[MINOR(dev)] << 1;
+ if ( ( bh = bread( dev, start, blocksize) ) != NULL ) {
strncpy ( type,bh -> b_data, 4);
strncpy ( name,bh -> b_data + 4, 6);
} else {
@@ -120,7 +86,7 @@
}
switch ( partition_type = get_partition_type(type) ) {
case ibm_partition_lnx1:
- offset = (geo.start + 1);
+ offset = start + 1;
printk ( "(LNX1)/%6s:",name);
break;
case ibm_partition_vol1:
@@ -132,7 +98,7 @@
printk ( "(CMS1)/%6s:",name);
if (* (((long *)bh->b_data) + 13) == 0) {
/* disk holds a CMS filesystem */
- offset = (geo.start + 1);
+ offset = start + 1;
printk ("(CMS)");
} else {
/* disk is reserved minidisk */
@@ -148,22 +114,18 @@
break;
case ibm_partition_none:
printk ( "(nonl)/ :");
- offset = (geo.start+1);
+ offset = start+1;
break;
default:
offset = 0;
size = 0;
}
-#if (LINUX_VERSION_CODE > KERNEL_VERSION(2,3,98))
+
add_gd_partition( hd, MINOR(dev), 0,size);
add_gd_partition( hd, MINOR(dev) + 1, offset * (blocksize >> 9),
size-offset*(blocksize>>9));
-#else
- add_partition( hd, MINOR(dev), 0,size,0);
- add_partition( hd, MINOR(dev) + 1, offset * (blocksize >> 9),
- size-offset*(blocksize>>9) ,0 );
-#endif /* LINUX_VERSION */
+
printk ( "\n" );
bforget(bh);
return 1;
-
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: reiserfs: still problems with tail conversion
On Saturday 24 February 2001 06:19, Erik Mouw wrote: > I'll upgrade to linux-2.4.2 to see if it solves the problem. (was > running 2.4.2-pre4 + your patch) > > > Erik I'm running 2.4.2 and I get similar results using your test program. This is on an IBM 390 Laptop. P2-233, 96mb RAM, 3.2gb HDD. See program results below. I can supply more info (.config etc, & do testing) if needed. MG Creating 8192 files ... done Appending to the files ... done Checking files for null bytes ... reiser-00107.test contains null bytes reiser-00127.test contains null bytes reiser-00208.test contains null bytes reiser-00234.test contains null bytes reiser-00259.test contains null bytes reiser-00303.test contains null bytes reiser-00324.test contains null bytes reiser-00343.test contains null bytes reiser-00371.test contains null bytes reiser-00388.test contains null bytes reiser-00444.test contains null bytes reiser-00452.test contains null bytes reiser-00459.test contains null bytes reiser-00466.test contains null bytes reiser-00495.test contains null bytes reiser-00502.test contains null bytes reiser-00515.test contains null bytes reiser-00522.test contains null bytes reiser-00535.test contains null bytes reiser-00548.test contains null bytes reiser-00608.test contains null bytes reiser-00614.test contains null bytes reiser-00620.test contains null bytes reiser-00626.test contains null bytes reiser-00637.test contains null bytes reiser-00648.test contains null bytes reiser-00659.test contains null bytes reiser-00669.test contains null bytes reiser-00674.test contains null bytes reiser-00704.test contains null bytes reiser-00744.test contains null bytes reiser-00749.test contains null bytes reiser-00754.test contains null bytes reiser-00759.test contains null bytes reiser-00764.test contains null bytes reiser-00773.test contains null bytes reiser-00778.test contains null bytes reiser-00787.test contains null bytes reiser-00792.test contains null bytes reiser-00801.test contains null bytes reiser-00810.test contains null bytes reiser-00819.test contains null bytes reiser-00847.test contains null bytes reiser-00855.test contains null bytes reiser-00899.test contains null bytes reiser-00947.test contains null bytes reiser-00951.test contains null bytes reiser-00955.test contains null bytes reiser-00959.test contains null bytes reiser-00963.test contains null bytes reiser-00967.test contains null bytes reiser-00971.test contains null bytes reiser-00978.test contains null bytes reiser-00982.test contains null bytes reiser-00986.test contains null bytes reiser-00990.test contains null bytes reiser-00997.test contains null bytes reiser-01001.test contains null bytes reiser-01005.test contains null bytes reiser-01012.test contains null bytes reiser-01016.test contains null bytes Checking done - 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: [rfc] Near-constant time directory index for Ext2
Andries, > is very little interaction to start with. And the final AND that truncates > to the final size of the hash chain kills the high order bits. > No good. I didn't realise you were bit-masking down to the required size. Yes, it would be pretty useless in that case. Ralph. > > Andries > > > - 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: loop-6 patch and 2.4.2
Steven King wrote: > On Friday 23 February 2001 10:50, Mohammad A. Haque wrote: > > Is anyone else using 2.4.2 patched with loop-6? Does load goto about 1 > > and stay there even though mounting things via loop seem to work fine? > > Yes, and with 2 mounts the load avg goes ~2; after umounting, it goes back > to normal levels. You can observe with ps that each thread for each mounted loop device increases the load by 1; here's the output from "ps ax | fgrep loop" on my Dell Inspiron 5000e: 13 ?DW<0:28 [loop1] 115 ?DW<0:57 [loop0] 116 ?DW<0:58 [loop2] 2816 pts/4S 0:00 fgrep loop Since I have 3 image files mounted, that means my Inspiron 5000e has a load of 3 when it's idle... ;) -Barry K. Nathan <[EMAIL PROTECTED]> - 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: [ANOMALIES]: 2.4.2 - __alloc_pages: failed & mount hangingwithloop device issues
On Fri, 23 Feb 2001, Shawn Starr wrote: > Mike Galbraith wrote: > > [patch] Mike, this patch looks like a really good idea. regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - 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: VM balancing problems under 2.4.2-ac1
On 23 Feb 2001, Adam Sampson wrote: > The VM balancing updates in the recent ac kernels seem to have caused > some interesting performance problems on my desktop machine. I've got > 160Mb of RAM, and 2.4.2-ac1 appears to be using excessively large > amounts of it for buffers and cache while pushing stuff out to > swap. This means that Mozilla, for instance, runs significantly worse > than under 2.4.0, since bits of it are being swapped in and out. This is a known problem which I'll fix as soon as I have a solution. The problem is that we still have no good way to balance how much memory we take from the cache and how much memory we take from processes. This means that for some workloads we'll be evicting too much cache while for other workloads we'll be evicting too much process pages... If anybody as a good idea to make this code auto-balancing, please let me know. regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - 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: [2.4.1] system goes glacial, Reiser on /usr doesn't sync
I think Alan fixed it. I've been running 2.4.2-ac3 under heavy load for about a half-hour now under heavy disk usage (apt-get + 2 kernel builds + Netscape/X11), and it hasn't locked up yet. -- Dwayne C. Litzenberger - [EMAIL PROTECTED] - Please always Cc to me when replying to me on the lists. - See the mail headers for GPG/advertising/homepage information. PGP signature
Re: [ANOMALIES]: 2.4.2 - __alloc_pages: failed - Patch failed
Feb 23 21:17:47 coredump kernel: __alloc_pages: 3-order allocation failed.
Feb 23 21:17:47 coredump kernel: __alloc_pages: 2-order allocation failed.
Feb 23 21:17:47 coredump kernel: __alloc_pages: 1-order allocation failed.
Feb 23 21:17:47 coredump kernel: __alloc_pages: 3-order allocation failed.
Feb 23 21:17:47 coredump kernel: __alloc_pages: 3-order allocation failed.
Feb 23 21:17:47 coredump kernel: __alloc_pages: 2-order allocation failed.
Feb 23 21:17:47 coredump kernel: __alloc_pages: 1-order allocation failed.
didnt, work, still causing this..
Shawn Starr wrote:
> Ok apply patch and loop patch... I'll let you know what happens in my next
> email.
>
> Mike Galbraith wrote:
>
> > On Fri, 23 Feb 2001, Shawn Starr wrote:
> >
> > > Feb 23 03:31:18 coredump kernel: __alloc_pages: 3-order allocation
> > > failed.
> > > Feb 23 03:31:18 coredump kernel: __alloc_pages: 3-order allocation
> > > failed.
> > > Feb 23 03:31:18 coredump kernel: __alloc_pages: 2-order allocation
> > > failed.
> > > Feb 23 03:31:18 coredump kernel: __alloc_pages: 3-order allocation
> > > failed.
> > > Feb 23 03:31:18 coredump kernel: __alloc_pages: 3-order allocation
> > > failed.
> > > Feb 23 03:31:18 coredump kernel: __alloc_pages: 2-order allocation
> > > failed.
> > > Feb 23 03:31:18 coredump kernel: __alloc_pages: 3-order allocation
> > > failed.
> > >
> > > The use of mkisofs and xcdroster with cdrecord seems to cause this fault
> > > in kernel.log
> >
> > Hi,
> >
> > Can you try the below for the high order allocation problem? We don't
> > try very hard at all to service high order allocations under load. If
> > it helps, let me know and I'll submit it to Rik for consideration.
> >
> > (for loop troubles, you should try Jens' latest loop patch located in
> > your favorite kernel mirror under pub/linux/kernel/people/axboe)
> >
> > -Mike
> >
> > (patch was done against 2.4.1-ac20, but should go in ok)
> > --- mm/page_alloc.c.org Fri Feb 23 13:21:54 2001
> > +++ mm/page_alloc.c Fri Feb 23 13:28:33 2001
> > @@ -274,7 +274,7 @@
> > struct page * __alloc_pages(zonelist_t *zonelist, unsigned long order)
> > {
> > zone_t **zone;
> > - int direct_reclaim = 0;
> > + int direct_reclaim = 0, loop = 0;
> > unsigned int gfp_mask = zonelist->gfp_mask;
> > struct page * page;
> >
> > @@ -366,7 +366,7 @@
> > * able to free some memory we can't free ourselves
> > */
> > wakeup_kswapd();
> > - if (gfp_mask & __GFP_WAIT) {
> > + if (gfp_mask & __GFP_WAIT && loop) {
> > __set_current_state(TASK_RUNNING);
> > current->policy |= SCHED_YIELD;
> > schedule();
> > @@ -393,6 +393,7 @@
> > * --> try to free pages ourselves with page_launder
> > */
> > if (!(current->flags & PF_MEMALLOC)) {
> > + loop++;
> > /*
> > * Are we dealing with a higher order allocation?
> > *
> > @@ -440,7 +441,7 @@
> > memory_pressure++;
> > try_to_free_pages(gfp_mask);
> > wakeup_bdflush(0);
> > - if (!order)
> > + if (!order || loop < (1 << order))
> > goto try_again;
> > }
> > }
>
> -
> 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/
-
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: 2.2.18: weird eepro100 msgs
On Fri, 2 Feb 2001, Ivan Passos wrote: > > On Fri, 2 Feb 2001, Ion Badulescu wrote: > > > On Fri, 2 Feb 2001 15:01:05 -0800 (PST), Ivan Passos <[EMAIL PROTECTED]> wrote: > > > > > Sometimes when I reboot the system, as soon as the eepro100 module is > > > loaded, I start to get these msgs on the screen: > > > > > > eth0: card reports no resources. > > > eth0: card reports no RX buffers. > > > eth0: card reports no resources. > > > eth0: card reports no RX buffers. > > > eth0: card reports no resources. > > > eth0: card reports no RX buffers. > > > (...) > > > > Does the following patch, taken from 2.4.1, help? > > I'm currently testing. I'll get back to you soon (have to reboot the > system a lot to make sure it's really solved ... :)). Yes, the patch did solve the problem. Alan, could you please include this patch on your 2.2.19pre series (if it's not already included)?? Ion, thanks again for your help!! Later, Ivan --- linux-2.2.18/drivers/net/eepro100-old.c Fri Feb 2 15:30:23 2001 +++ linux-2.2.18/drivers/net/eepro100.c Fri Feb 2 15:33:19 2001 @@ -751,6 +751,7 @@ This takes less than 10usec and will easily finish before the next action. */ outl(PortReset, ioaddr + SCBPort); + inl(ioaddr + SCBPort); /* Honor PortReset timing. */ udelay(10); @@ -839,6 +840,7 @@ #endif /* kernel_bloat */ outl(PortReset, ioaddr + SCBPort); + inl(ioaddr + SCBPort); /* Honor PortReset timing. */ udelay(10); @@ -1062,6 +1064,9 @@ /* Set the segment registers to '0'. */ wait_for_cmd_done(ioaddr + SCBCmd); outl(0, ioaddr + SCBPointer); + /* impose a delay to avoid a bug */ + inl(ioaddr + SCBPointer); + udelay(10); outb(RxAddrLoad, ioaddr + SCBCmd); wait_for_cmd_done(ioaddr + SCBCmd); outb(CUCmdBase, ioaddr + SCBCmd); - 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: creation of sock
I found this condition only happens when the sock state is TCP_TIME_WAIT. I don't know if this helps. Sourav Ghosh wrote: > Hello, > > I'm using linux 2.2.15 kernel on redhat. > I have added some variables (pointers) on "sock" data structure. > I was initializing them to NULL in sk_alloc() function. > > But it seems some sock structures are allocated for TCP bypassing this > sk_alloc() and due to this my added pointers are not initialized to NULL > all the time. > > Can anyone tell me which function is being called for generating sock > for TCP connections ( I guess for a aprticular TCP packet type, not for > all, as I'm getting into this problem intermittently, esp., when I try > access some specified website from my PC) ? > > Thanks > -- > Sourav - 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/
2.4.2-ac3 and wavelan driver
Hi Alan (and the others)
A few notes related to you *-ac* patches, the IrDA stack and
the Wavelan driver.
First, IrDA :
> --- linux.vanilla/net/irda/irlap.cThu Feb 22 09:06:21 2001
> +++ linux.ac/net/irda/irlap.c Wed Feb 21 11:55:26 2001
> @@ -51,6 +51,7 @@
> hashbin_t *irlap = NULL;
> int sysctl_slot_timeout = SLOT_TIMEOUT * 1000 / HZ;
>
> +extern void irlap_queue_xmit(struct irlap_cb *self, struct sk_buff *skb);
> static void __irlap_close(struct irlap_cb *self);
>
> static char *lap_reasons[] = {
The above patch is unnecessary. The definition of
irlap_queue_xmit() has been added in irlap_frame.h as part of
2.4.2 (I've just checked). So, you can drop this snipset.
By the way, I'm updating the IrDA patches in the pipeline (USB
driver and co) and will send that to Dag soon.
> --- linux.vanilla/net/irda/irnet/Config.inSun Nov 12 02:11:23 2000
> +++ linux.ac/net/irda/irnet/Config.in Wed Jan 31 22:02:24 2001
> @@ -1 +1,4 @@
> -dep_tristate ' IrNET protocol' CONFIG_IRNET $CONFIG_IRDA
> +if [ "$CONFIG_NETDEVICES" != "n" ]; then
> + dep_tristate ' IrNET protocol' CONFIG_IRNET $CONFIG_IRDA $CONFIG_PPP
> +fi
> +
This one is good. As you have it, we won't resend it to Linus.
By the way, thanks to whoever spent time to correct my
spelling mistakes...
> 2.4.2-ac3
> o Remove dead wavelan prototype (Jeff Garzik)
I confirm again that I'm totally opposed to this patch of the
wavelan driver you have in your tree (see below).
Replacing a perfectly valid inline function with a ugly define
it totally backward. If you look closely, the initial code was correct
and clean. I don't know anyone with taste who could advocate such a
patch without remorse.
As we discussed earlier, this patch is only necessary because
gcc 2.96 miscompile the complex definition of udelay(). If gcc 2.96
miscompile the kernel, people should fix it or use a compiler that
works properly, not uglify my driver ;-)
On the other hand, thanks infinitely to Jeff for having
updated the wavelan_cs driver (I'm still using Pcmcia outside the
kernel).
> --- linux.vanilla/drivers/net/wavelan.c Thu Feb 22 09:05:59 2001
> +++ linux.ac/drivers/net/wavelan.cFri Feb 16 21:07:55 2001
> @@ -405,16 +405,13 @@
> * Wait for the frequency EEPROM to complete a command.
> * I hope this one will be optimally inlined.
> */
> -static inline void fee_wait(unsigned long ioaddr,/* I/O port of the card */
> - int delay, /* Base delay to wait for */
> - int number)
> -{/* Number of time to wait */
> - int count = 0; /* Wait only a limited time */
> -
> - while ((count++ < number) &&
> -(mmc_in(ioaddr, mmroff(0, mmr_fee_status)) &
> - MMR_FEE_STATUS_BUSY)) udelay(delay);
> -}
> +
> +#define fee_wait(ioaddr,delay,number) do { \
> + int count = 0; /* Wait only a limited time */ \
> + while ((count++ < number) &&\
> +(mmc_in(ioaddr, mmroff(0, mmr_fee_status)) & \
> + MMR_FEE_STATUS_BUSY)) udelay(delay);\
> + } while (0)
>
That's it, have a good week end...
Jean
-
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: Linux-2.4.2 && Minix SP
--- Adam <[EMAIL PROTECTED]> wrote: > > are those MINIX_SUBPARITIONS in 2.4.2 actually > supposed to copile? > in fs/partitions/msdos.c it refers to some MINIX > defines which do not > seems to be included in that path. Did not work for me either. Michel Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie - 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/
2.42 broke PCMCIA IDE
Hello, Just installed a custom Debian system using kernel 2.4.1 + ReiserFS (root running reiserfs) and it works just fine. Since kernel 2.4.2 has been released, when recompiling a new kernel (the 2.4.1 I used has been trimmed to fit my modified boot disks) I used that instead, after hearing about the multimode and reiserfs bugs. Kernel boots, and... pcmcia-cs starts with a high and low beep. Card detected as a 5V using cardctl status, but silly me, forgot to note the reading given by cardctl ident. Running Debian woody, 02/18 snapshot, using gcc 2.95.3. Hardware is the Sony Picturebook C1VE (Crusoe) Any idea? Cheers, Michel Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie - 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: 2.4.2 broke gcd (or, audio CD's won't play)
> After upgrading to 2.4.2, gcd or any audio CD player will work. The > attached chunk of dmesg is the messages produced by attempting to play > them. The player just loops through all tracks, playing nothing. > Ripping CD's a la cdparanoia still works. Xmcd works fine here. 2.4.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: 2.4.2 broke gcd (or, audio CD's won't play)
> After upgrading to 2.4.2, gcd or any audio CD player will work. The > attached chunk of dmesg is the messages produced by attempting to play > them. The player just loops through all tracks, playing nothing. > Ripping CD's a la cdparanoia still works. No dmesg chunk attached. ALso does 2.4.2ac3 work ? - 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: [OPPS] 2.2.18 + Scheduling in interrupt
> Aiee, killing interrupt handler > alloc_skb called nonatomically from interrupt c016468f > eth0: Tx request while isr active. > Scheduling in interrupt What ethernet card was this ? - 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: RFC: vmalloc improvements
> We have an application that makes extensive use of vmalloc (we need > lots of large virtual contiguous buffers. The buffers don't have to be > physically contiguous). So you could actually code around that. If you have them virtually contiguous for mmap for example then you can actually mmap arbitary page arrays > We would volounteer to improve vmalloc if there is any chance of > getting it into the main kernel tree. We also have an idea how we > Could do that (quite similar to the process address space management): Im not the one to call the shots, but it seems if you need an AVL for the vmalloc tables then vmalloc is possibly being overused, or people are not allocating buffers just occasionally as anticipated - 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: RFC: vmalloc improvements
In article <[EMAIL PROTECTED]>, Reto Baettig <[EMAIL PROTECTED]> wrote: > >We would volounteer to improve vmalloc if there is any chance of >getting it into the main kernel tree. We also have an idea how we >Could do that (quite similar to the process address space management): > >1. Create a generic avl-tree headerfile (similar to list.h) No thanks. Just use the process address space management as-is, and make the vmalloc address list be the same as any other address list: it would just be the "native" address list for "init_mm". You could probably even use "insert_vm_struct()" directly, and have that do the AVL tree stuff for you, no changes needed. >Is this something that makes sense to do and that could make it >into the 2.4 or the 2.5 kernel? It's definitely not a 2.4.x thing. Linus - 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/
[OPPS] 2.2.18 + Scheduling in interrupt
Hi this is the first opps i got from several i have attached the rest in a gzip file these were the messages i got Aiee, killing interrupt handler alloc_skb called nonatomically from interrupt c016468f eth0: Tx request while isr active. Scheduling in interrupt first opps Unable to handle kernel NULL pointer dereference at virtual address current->tss.cr3 = 00101000, %cr3 = 00101000 *pde = Oops: 0002 CPU:0 EIP:0010:[] EFLAGS: 00010286 eax: 0018 ebx: c1ef2000 ecx: 02fd edx: c799c000 esi: edi: c2b9e220 ebp: c1ef3bf8 esp: c1ef3be4 ds: 0018 es: 0018 ss: 0018 Process gnome-terminal (pid: 3950, process nr: 42, stackpage=c1ef3000) Stack: c1ef2000 c2b9e220 0296 c1ef2000 c2b9e220 0001 c0117081 c1ef3c68 c1ef2000 c000 c1ef3d08 0020 c1ef2000 c0109898 000b c1ef3c68 c01d9b76 c01db50e c010eb1c c01db50e c1ef3c68 c655 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: c7 05 00 00 00 00 00 00 00 00 8d 65 e8 5b 5e 5f 89 ec 5d c3 >>EIP; c0110b36<= Trace; c0117081 Trace; c0109898 Trace; c01d9b76 Trace; c01db50e Trace; c010eb1c Trace; c01db50e Trace; c017cea8 Trace; c0109485 Trace; c012043f Trace; c0110010 Trace; c0164ecc Trace; c01ca48b Trace; c0165031 <__kfree_skb+a1/a8> Trace; c01c9fbb Trace; c0164f82 Trace; c010a3fe Trace; c010a1c0 Trace; c010a520 Trace; c010a204 Trace; c0100018 Trace; c0117f19 Trace; c010a537 Trace; c010a204 Trace; c01137eb Trace; c010eab0 Trace; c01db48a Trace; c0109485 Trace; c012043f Trace; c0164ecc Trace; c016468f Trace; c0164903 Trace; c01878cc Trace; c01879b6 Trace; c01878cc Trace; c01b14b5 Trace; c0162ac0 Trace; c01878cc Trace; c01879b6 Trace; c01878cc Trace; c01b14b5 Trace; c0162ac0 Trace; c01878cc Trace; c0162cce Trace; c0124b47 Trace; c0162c3c Trace; c0109374 Code; c0110b36 <_EIP>: Code; c0110b36<= 0: c7 05 00 00 00 00 00 movl $0x0,0x0 <= Code; c0110b3d 7: 00 00 00 Code; c0110b40 a: 8d 65 e8 lea0xffe8(%ebp),%esp Code; c0110b43 d: 5bpop%ebx Code; c0110b44 e: 5epop%esi Code; c0110b45 f: 5fpop%edi Code; c0110b46 10: 89 ec mov%ebp,%esp Code; c0110b48 12: 5dpop%ebp Code; c0110b49 13: c3ret if anymore info is required mail me although i am not sure what was running at the time of the machine crashing thanks James -- - Check Out: http://stev.org E-Mail: [EMAIL PROTECTED] 12:50am up 22 days, 8:35, 4 users, load average: 0.00, 0.12, 0.41 opps.txt.gz
2.4.2 broke gcd (or, audio CD's won't play)
After upgrading to 2.4.2, gcd or any audio CD player will work. The attached chunk of dmesg is the messages produced by attempting to play them. The player just loops through all tracks, playing nothing. Ripping CD's a la cdparanoia still works. If its any consequence, my CD-ROM is now detected as a CD-ROM/DVD-ROM. Is this also a problem, or merely an optimization in the boot-detection routines? Thanks -- -Steven Never ask a geek why, just nod your head and slowly back away. - 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: reiserfs: still problems with tail conversion
On Fri, Feb 23, 2001 at 05:10:46PM -0500, Chris Mason wrote: > On Friday, February 23, 2001 10:18:56 PM +0100 Erik Mouw > <[EMAIL PROTECTED]> wrote: > > I am running linux-2.4.2-pre4 with Chris Mason's tailconversion bug fix > > applied, but I still have problems with null bytes in files. I wrote a > > little test program that clearly shows the problem: > Many thanks for sending along a test program for reproducing. But, it > doesn't seem to reproduce the problem here, how many times did you have to > run it to see the null bytes? Do you remove the files between runs? i cant reproduce the problem on my system runnig 2.4.2, too. no problem so far ;) reiserfs on an 46gb ibm ide hdd, 750mhz p3, 256mb ram yours, oliver teuber - 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: [Ext2-devel] [rfc] Near-constant time directory index for Ext2
Ted writes: > Note that in the long run, the fully comatible version should probably > have a COMPAT feature flag set so that you're forced to use a new enough > version of e2fsck. Otherwise an old e2fsck may end up not noticing > corruptions in an index block which might cause a new kernel to have > serious heartburn. Actually, having a COMPAT flag also helps in other ways: 1) Turning indexing on and off is not a mount option as it currently is (or automatically done) so it will quell Linus' fears about priniciple of least surprise (i.e. not converting a filesystem without user action). A superblock COMPAT flag is more in keeping with other ext2 features. 2) Running a new e2fsck on a COMPAT_INDEX filesystem could create the index for existing "large" directories that don't have the BTREE/INDEX flag set, so the kernel only ever has to deal with incremental indexing after the first block. The kernel would just do linear access on existing multi-block directories until e2fsck is run. 3) Clearing the COMPAT flag would make e2fsck remove the indexes, if the user so desires. I think this would be the behaviour of existing e2fsck anyways. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - 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: RFC: vmalloc improvements
On Fri, 23 Feb 2001, Reto Baettig wrote: > We have an application that makes extensive use of vmalloc (we need > lots of large virtual contiguous buffers. The buffers don't have to be > physically contiguous). question: what is this application, and why does it need so much virtual memory? vmalloc()-able memory is maximized to 128 MB right now, and increasing it conflicts with directly mapping RAM, so generally it's a good idea to avoid vmalloc() as much as possible. Ingo - 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: creation of sock
Jacob L E Blain Christen wrote: > looking further at > net/ipv4/tcp_ipv4.c:tcp_create_openreq_child() (for 2.2.16) > and > net/ipv4/tcp_minisocks.c:tcp_create_openreq_child() (for 2.4.x) > > immediately after the sk_alloc() call (if it successful) it calls > memcpy(newsk, sk, sizeof(*newsk)) > i suggest setting your NULL initial values immediately after this line. > > sorry for the premature email Didn't help. The problem persists. - 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: Linux device driver writing
a treasure trove of info on linux would be /usr/src/linux/Documentation/kernel-docs.txt -Prasanna On Fri, Feb 23, 2001 at 10:01:40AM +, Rahul wrote: > Hi friends, > > I am new to this field of writing device drivers. I > have done my course in Unix/C and presently working > for a company in india in embedded systems. I am > looking forward to write some device drivers in > Linux/Unix/QNX can any one suggest me any good book > which i can refer for my guidance. > > thx for your constant support. > bye > rahul > > > Do You Yahoo!? > Get your free @yahoo.co.in address at http://mail.yahoo.co.in > - > 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/ -- Prasanna Subash --- [EMAIL PROTECTED] --- TurboLinux, INC Linux, the choice | The idea of male and female are universal of a GNU generation -o) | constants. -- Kirk, "Metamorphosis", Kernel 2.4.0-test /\\ | stardate 3219.8 on a i686_\\_v | | PGP signature
Re: [2.4.1] system goes glacial, Reiser on /usr doesn't sync
I have the same problem with 2.4.1 (and 2.4.2). Two processes that are actively using the disk (multiple files) seem to deadlock the system. Killing the right process (SysRq-K) seems to fix things. I'm kind of new to kernel debugging. Anyone want to guide me through it? -- Dwayne C. Litzenberger - [EMAIL PROTECTED] - Please always Cc to me when replying to me on the lists. - See the mail headers for GPG/advertising/homepage information. PGP signature
Kernel 2.4.2 - kernel BUG at apic.c:220!
When running 2.4.2 on a pentium 4, I get the following during boot: (any typos are due to me typing this in manually, off of what I see on the monitor connected to the P4. I've made sure the addresses are correct, at least... note that this happens with noapic passed as an option to the kernel as well) CPU: After generic, caps: 3febf9ff CPU: Common caps: 3febf9ff CPU: Intel(R) Pentium(R) 4 CPU 1300MHz stepping 07 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX leaving PIC mode, enabling symmetric IO mode. kernel BUG at apic.c:220! invalid operand: CPU:0 EIP:0010:[] EFLAGS: 00010286 eax: 001a ebx: f000ae7e ecx: 0001 edx: c021a108 esi: 007e edi: c0105000 ebp: 0008e000 esp: c022ffc0 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c022f000) Stack: c01e4725 c01e4932 00dc ff87 0009b800 c0113873 c02308f6 c01deec0 ff87 ff87 ff87 ff87 ff87 c0267fc0 00010808 c0100191 Call Trace: [] [] Code: 0f 0b 83 c4 0c b8 ff ff ff ff 8b 0d cc 14 28 c0 a3 e0 e0 ff Kernel panic: Attempted to kill the idle task! In idle task - not syncing --- Unsolicited advertisments to this address are not welcome. - 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: UDP attack? How to suppress kernel msgs?
I have an MRTG chart of what happened during the attack and have attached it. Does anyone know why the bandwidth going OUT spiked up so high and just cratered? Green is incoming, blue is outgoing. Thanks, Vibol Hou -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Vibol Hou Sent: Friday, February 23, 2001 3:22 PM To: Linux-Kernel Subject: UDP attack? How to suppress kernel msgs? Hi, One of my servers running 2.4.1 was attacked earlier today. I have a strong feeling it went down because the kernel was logging too many messages to syslog. There's over 100,000 lines of the following in my syslog: Feb 23 12:28:25 omega kernel: UDP: bad checksum. From 202.96.140.146:20567 to 21 6.115.239.40:113 ulen 1472 Feb 23 12:28:25 omega kernel: UDP: bad checksum. From 209.249.213.145:36338 to 2 16.115.239.40:113 ulen 1472 Feb 23 12:28:25 omega kernel: UDP: bad checksum. From 194.225.45.233:33762 to 21 6.115.239.40:113 ulen 1472 Feb 23 12:28:25 omega kernel: UDP: bad checksum. From 211.54.39.161:14958 to 216 .115.239.40:113 ulen 1472 Feb 23 12:28:25 omega kernel: UDP: bad checksum. From 202.96.140.167:3467 to 216 .115.239.40:113 ulen 1472 How do I suppress these types of messages from hogging up all the CPU? Thanks, Vibol Hou - 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/ khmerconnection.com-day[1].png
UDP attack? How to suppress kernel msgs?
Hi, One of my servers running 2.4.1 was attacked earlier today. I have a strong feeling it went down because the kernel was logging too many messages to syslog. There's over 100,000 lines of the following in my syslog: Feb 23 12:28:25 omega kernel: UDP: bad checksum. From 202.96.140.146:20567 to 21 6.115.239.40:113 ulen 1472 Feb 23 12:28:25 omega kernel: UDP: bad checksum. From 209.249.213.145:36338 to 2 16.115.239.40:113 ulen 1472 Feb 23 12:28:25 omega kernel: UDP: bad checksum. From 194.225.45.233:33762 to 21 6.115.239.40:113 ulen 1472 Feb 23 12:28:25 omega kernel: UDP: bad checksum. From 211.54.39.161:14958 to 216 .115.239.40:113 ulen 1472 Feb 23 12:28:25 omega kernel: UDP: bad checksum. From 202.96.140.167:3467 to 216 .115.239.40:113 ulen 1472 How do I suppress these types of messages from hogging up all the CPU? Thanks, Vibol Hou - 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/
Linux-2.4.2 and hamradio as module
this was built from stock 2.4.2 kernel. gcc -D__KERNEL__ -I/usr/src/RPM/BUILD/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i586 -DMODULE -DMODVERSIONS -include /usr/src/RPM/BUILD/linux/include/linux/modversions.h -c -o mkiss.o mkiss.c gcc -D__KERNEL__ -I/usr/src/RPM/BUILD/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i586 -DMODULE -DMODVERSIONS -include /usr/src/RPM/BUILD/linux/include/linux/modversions.h -c -o 6pack.o 6pack.c 6pack.c: In function `sixpack_init_driver': 6pack.c:714: `KMALLOC_MAXSIZE' undeclared (first use in this function) 6pack.c:714: (Each undeclared identifier is reported only once 6pack.c:714: for each function it appears in.) make[2]: *** [6pack.o] Error 1 make[2]: Leaving directory `/usr/src/RPM/BUILD/linux/drivers/net/hamradio' make[1]: *** [_modsubdir_net/hamradio] Error 2 make[1]: Leaving directory `/usr/src/RPM/BUILD/linux/drivers' make: *** [_mod_drivers] Error 2 Thanks Jorg - 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/
Linux-2.4.2 && Minix SP
are those MINIX_SUBPARITIONS in 2.4.2 actually supposed to copile? in fs/partitions/msdos.c it refers to some MINIX defines which do not seems to be included in that path. - gcc -D__KERNEL__ -I/usr/src/Linux/24/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -march=i686-c -o msdos.o msdos.c msdos.c: In function `minix_partition': msdos.c:403: `MINIX_PARTITION' undeclared (first use in this function) msdos.c:403: (Each undeclared identifier is reported only once msdos.c:403: for each function it appears in.) msdos.c:406: `MINIX_NR_SUBPARTITIONS' undeclared (first use in this function) msdos.c: In function `msdos_partition': msdos.c:571: `MINIX_PARTITION' undeclared (first use in this function) make[3]: *** [msdos.o] Error 1 make[3]: Leaving directory `/usr/src/Linux/24/linux/fs/partitions' make[2]: *** [first_rule] Error 2 make[2]: Leaving directory `/usr/src/Linux/24/linux/fs/partitions' make[1]: *** [_subdir_partitions] Error 2 make[1]: Leaving directory `/usr/src/Linux/24/linux/fs' make: *** [_dir_fs] Error 2 - -- Adam http://www.eax.com The Supreme Headquarters of the 32 bit registers - 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/
Alpha compile error on 2.4.2-ac3 (irq_err_count)
hi...
Machine: DEC-Alpha XL300 (Alcor/XLT)
Kernel: 2.4.2-ac3
Compile-Error:
make[1]: Entering directory `/usr/src/linux-2.4.2-ac3/arch/alpha/kernel'
gcc -D__KERNEL__ -I/usr/src/linux-2.4.2-ac3/include -Wall
-Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe
-mno-fp-regs -ffixed-8 -Wa,-mev6-c -o irq_alpha.o irq_alpha.c
irq_alpha.c: In function `dummy_perf':
irq_alpha.c:33: `irq_err_count' undeclared (first use in this function)
irq_alpha.c:33: (Each undeclared identifier is reported only once
irq_alpha.c:33: for each function it appears in.)
irq_alpha.c: In function `do_entInt':
irq_alpha.c:54: `irq_err_count' undeclared (first use in this function)
irq_alpha.c: In function `process_mcheck_info':
irq_alpha.c:152: warning: unused variable `cpu'
make[1]: *** [irq_alpha.o] Error 1
make[1]: Leaving directory `/usr/src/linux-2.4.2-ac3/arch/alpha/kernel'
make: *** [_dir_arch/alpha/kernel] Error 2
Temporary fix to get it compiling again:
--- linux/include/asm-alpha/hw_irq.h~ Fri Feb 23 23:45:39 2001
+++ linux/include/asm-alpha/hw_irq.hFri Feb 23 23:59:51 2001
@@ -5,6 +5,8 @@
static inline void hw_resend_irq(struct hw_interrupt_type *h, unsigned int i) {}
+extern volatile unsigned long irq_err_count;
+
#ifdef CONFIG_ALPHA_GENERIC
#define ACTUAL_NR_IRQS alpha_mv.nr_irqs
#else
But the real bug seems to be that the changes to irq_err_count ("atomic_t"
instead of "volatile unsigned long", and moving it from linux/irq.h to
asm/hw_irq.h are done for i386 but not for the other architectures.
c'ya
sven
--
The Internet treats censorship as a routing problem, and routes around it.
(John Gilmore on http://www.cygnus.com/~gnu/)
-
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: possible bug x86 2.4.2 SMP in IP receive stack
=> From feldy Fri Feb 23 14:13:08 2001 => => Feb 23 12:42:30 rcc2 kernel: Warning: kfree_skb passed an skb still on a list (from c01f58dc). => => I'm going to pop out one processor on the receiver => and see if that makes the problem go away. Using a single processor on the receive side makes the problem go away. I see no problems on the receiver with one cpu removed. rcc2 29% netstat -i myri0 Kernel Interface table Iface MTU MetRX-OK RX-ERR RX-DRP RX-OVRTX-OK TX-ERR TX-DRP TX-OVR Flg eth0 1500 037857 0 0 036404 0 0 0 BRU lo16192 0 46 0 0 0 46 0 0 0 LRU myri0 9000 0 20564644 0 0 0 312 0 0 0 BRU - 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: [rfc] Near-constant time directory index for Ext2
On Sat, Feb 24, 2001 at 10:43:16AM +1300, Ralph Loader wrote:
> A while ago I did some experimentation with simple bit-op based string
> hash functions. I.e., no multiplications / divides in the hash loop.
>
> The best I found was:
>
> int hash_fn (char * p)
> {
> int hash = 0;
> while (*p) {
> hash = hash + *p;
> // Rotate a 31 bit field 7 bits:
> hash = ((hash << 7) | (hash >> 24)) & 0x7fff;
> }
> return hash;
> }
Hmm. This one goes in the "catastrophic" category.
For actual names:
N=557398, m=51 sz=2048, min 82, max 4002, av 272.17, stddev 45122.99
For generated names:
N=557398, m=51 sz=2048, min 0, max 44800, av 272.17, stddev 10208445.83
A very non-uniform distribution.
> The rotate is equivalent to a multiplication by x**7 in Z_2[P=0],
> where P is the polynomial x**31 - 1 (over Z_2).
> Presumably the "best" P would be irreducible - but that would have more
> bits set in the polynomial, making reduction harder. A compromise is to
> choose P in the form x**N - 1 but with relatively few factors.
> X**31 - 1 is such a P.
It has seven irreducible factors. Hardly "almost irreducible".
Shifting the 7-bit ASCII characters over 7 bits makes sure that there
is very little interaction to start with. And the final AND that truncates
to the final size of the hash chain kills the high order bits.
No good.
Andries
-
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/
2.4.2-ac1 and ide questions/problems
This machine started as a Redhat linux 6.1 install some time ago, with lots
of updates since then.
Prior to the kernel upgrade, I upgraded binutils to binutils-2.9.5.0.31-1,
modutils to modutils-2.4.2-1, e2fsprogs to e2fsprogs-1.19-0.
I've just installed kernel 2.4.2-ac1 from a clean build and I'm seeing the
following at boot time:
hda: WDC AC31600H, ATA DISK drive
hdb: Maxtor 91303D6, ATA DISK drive
hdc: ST36450A, ATA DISK drive
hdd: CDA66801I, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: Disabling (U)DMA for WDC AC31600H
hda: 3173184 sectors (1625 MB) w/128KiB Cache, CHS=787/64/63
hdb: 25450992 sectors (13031 MB) w/512KiB Cache, CHS=25249/16/63, (U)DMA
hdc: 12594960 sectors (6449 MB) w/448KiB Cache, CHS=13328/15/63, DMA
hdd: ATAPI 6X CD-ROM drive, 240kB Cache
Uniform CD-ROM driver Revision: 3.12
Partition check:
hda: hda1 hda2 hda3
hdb:hdb: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hdb: dma_intr: error=0x04 { DriveStatusError }
hdb1 hdb2 hdb3 hdb4
hdc: hdc1 hdc2 hdc3 hdc4
What does the disabling of DMA for the WDC drive mean, and can I re-enable it
with hdparm in a trouble free fashion?
What does this error during partition check mean and is it worriesome, or can
I ignore it?
hdb:hdb: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hdb: dma_intr: error=0x04 { DriveStatusError }
thanks,
-chuck
--
ACCEL Services, Inc.| Specialists in Gravity, Magnetics | 1(713)993-0671 ph.
1980 Post Oak Blvd. | and Integrated Interpretation | 1(713)960-1157 fax
Suite 2050 | |
Houston, TX, 77056 | Chuck Campbell | [EMAIL PROTECTED]
| President & Senior Geoscientist |
"Integration means more than having all the maps at the same scale!"
-
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: reiserfs: still problems with tail conversion
On Fri, Feb 23, 2001 at 05:10:46PM -0500, Chris Mason wrote: > Many thanks for sending along a test program for reproducing. But, it > doesn't seem to reproduce the problem here, how many times did you have to > run it to see the null bytes? Do you remove the files between runs? I got them immediately at the first run, which more or less was what I expected because reiserfs ate one of my mailfolders that way (only a CVS log folder, so nothing special was lost). You have to remove the files between runs, otherwise the same blocks seem to be allocated to the files. I'll upgrade to linux-2.4.2 to see if it solves the problem. (was running 2.4.2-pre4 + your patch) Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ - 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/
oops with : loop-6 / patch-int-2.4.0.3 and 2.4.2
Hi, While running this script: #/bin/bash losetup -d /dev/loop0 losetup -e serpent /dev/loop0 /dev/sda1 mount -t ext2 /dev/loop0 ./idisc1 one of two things have happened: 1) It worked but I was unable to write to the disk, even though I had file permissions 3) It oopsed : ksymoops 2.3.5 on i586 2.4.2. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.2/ (specified) -m /boot/System.map (specified) Warning (compare_maps): mismatch on symbol __module_description , sb says c1829080, /lib/modules/2.4.2/kernel/drivers/sound/sb.o says c182a240. Ignoring /lib/modules/2.4.2/kernel/drivers/sound/sb.o entry Warning (compare_maps): mismatch on symbol __module_parm_acer , sb says c1829106, /lib/modules/2.4.2/kernel/drivers/sound/sb.o says c182a2c6. Ignoring /lib/modules/2.4.2/kernel/drivers/sound/sb.o entry Warning (compare_maps): mismatch on symbol __module_parm_desc_acer , sb says c18295a0, /lib/modules/2.4.2/kernel/drivers/sound/sb.o says c182a760. Ignoring /lib/modules/2.4.2/kernel/drivers/sound/sb.o entry Warning (compare_maps): mismatch on symbol __module_parm_desc_dma , sb says c1829440, /lib/modules/2.4.2/kernel/drivers/sound/sb.o says c182a600. Ignoring /lib/modules/2.4.2/kernel/drivers/sound/sb.o entry Warning (compare_maps): mismatch on symbol __module_parm_desc_dma16 , sb says c1829480, /lib/modules/2.4.2/kernel/drivers/sound/sb.o says c182a640. Ignoring /lib/modules/2.4.2/kernel/drivers/sound/sb.o entry Warning (compare_maps): mismatch on symbol __module_parm_desc_esstype , sb says c1829580, /lib/modules/2.4.2/kernel/drivers/sound/sb.o says c182a740. Ignoring /lib/modules/2.4.2/kernel/drivers/sound/sb.o entry Warning (compare_maps): mismatch on symbol __module_parm_desc_io , sb says c18293c0, /lib/modules/2.4.2/kernel/drivers/sound/sb.o says c182a580. Ignoring /lib/modules/2.4.2/kernel/drivers/sound/sb.o entry Warning (compare_maps): mismatch on symbol __module_parm_desc_irq , sb says c1829405, /lib/modules/2.4.2/kernel/drivers/sound/sb.o says c182a5c5. Ignoring /lib/modules/2.4.2/kernel/drivers/sound/sb.o entry Warning (compare_maps): mismatch on symbol __module_parm_desc_isapnp , sb says c1829180, /lib/modules/2.4.2/kernel/drivers/sound/sb.o says c182a340. Ignoring /lib/modules/2.4.2/kernel/drivers/sound/sb.o entry Warning (compare_maps): mismatch on symbol __module_parm_desc_isapnpjump , sb says c18291e0, /lib/modules/2.4.2/kernel/drivers/sound/sb.o says c182a3a0. Ignoring /lib/modules/2.4.2/kernel/drivers/sound/sb.o entry Warning (compare_maps): mismatch on symbol __module_parm_desc_mpu_io , sb says c18294c0, /lib/modules/2.4.2/kernel/drivers/sound/sb.o says c182a680. Ignoring /lib/modules/2.4.2/kernel/drivers/sound/sb.o entry Warning (compare_maps): mismatch on symbol __module_parm_desc_multiple , sb says c1829240, /lib/modules/2.4.2/kernel/drivers/sound/sb.o says c182a400. Ignoring /lib/modules/2.4.2/kernel/drivers/sound/sb.o entry Warning (compare_maps): mismatch on symbol __module_parm_desc_pnplegacy , sb says c18292a0, /lib/modules/2.4.2/kernel/drivers/sound/sb.o says c182a460. Ignoring /lib/modules/2.4.2/kernel/drivers/sound/sb.o entry Warning (compare_maps): mismatch on symbol __module_parm_desc_reverse , sb says c1829300, /lib/modules/2.4.2/kernel/drivers/sound/sb.o says c182a4c0. Ignoring /lib/modules/2.4.2/kernel/drivers/sound/sb.o entry Warning (compare_maps): mismatch on symbol __module_parm_desc_sm_games , sb says c1829540, /lib/modules/2.4.2/kernel/drivers/sound/sb.o says c182a700. Ignoring /lib/modules/2.4.2/kernel/drivers/sound/sb.o entry Warning (compare_maps): mismatch on symbol __module_parm_desc_type , sb says c1829500, /lib/modules/2.4.2/kernel/drivers/sound/sb.o says c182a6c0. Ignoring /lib/modules/2.4.2/kernel/drivers/sound/sb.o entry Warning (compare_maps): mismatch on symbol __module_parm_desc_uart401 , sb says c1829360, /lib/modules/2.4.2/kernel/drivers/sound/sb.o says c182a520. Ignoring /lib/modules/2.4.2/kernel/drivers/sound/sb.o entry Warning (compare_maps): mismatch on symbol __module_parm_dma , sb says c18290b5, /lib/modules/2.4.2/kernel/drivers/sound/sb.o says c182a275. Ignoring /lib/modules/2.4.2/kernel/drivers/sound/sb.o entry Warning (compare_maps): mismatch on symbol __module_parm_dma16 , sb says c18290c0, /lib/modules/2.4.2/kernel/drivers/sound/sb.o says c182a280. Ignoring /lib/modules/2.4.2/kernel/drivers/sound/sb.o entry Warning (compare_maps): mismatch on symbol __module_parm_esstype , sb says c18290f7, /lib/modules/2.4.2/kernel/drivers/sound/sb.o says c182a2b7. Ignoring /lib/modules/2.4.2/kernel/drivers/sound/sb.o entry Warning (compare_maps): mismatch on symbol __module_parm_io , sb says c18290a0, /lib/modules/2.4.2/kernel/drivers/sound/sb.o says c182a260. Ignoring /lib/modules/2.4.2/kernel/drivers/sound/sb.o entry Warning (compare_maps): mismatch on symbol __module_parm_irq , sb says
Re: filesystem statistics
On Fri, Feb 23, 2001 at 11:54:28AM -0700, Andreas Dilger wrote: > Andries Brouwer writes: > > Here some statistics. > > Can you generate statistics on the number of files in each directory, > and the total size of each directory? > > This would also be helpful to determine how often indexing will be used > in an "average" system. Hmm - there is no way this is an average system. It is just a random system. For doing statistics on file names it is a valid example, I think. For doing statistics on file sizes or directory sizes it is worthless. Some people have few very large files, some have news spools or other things with lots of small files in a directory. (This particular system does not have a news spool.) Anyway, I can give you the stats. 127533 directories 2555633 regular files 946 other files Largest file: 678035456 bytes Largest directory: 1283 links Distribution of nlinks: 0 1 2 3 4 5 6 7 8 9 0: 0 0 98330 13901 4510223816241318877662 10: 668 490 519 307 308 226 157 140 10162 20: 130 116 73 78 54 26 59 41 36 33 30: 13 24 15 23 12 11 14 40 25 21 40: 21 9 10 20 10 4 6 10 2 1 50: 3 3 1 2 1 4 11 3 1 1 60: 2 3 0 2 6 6 6 1 1 1 70: 7 2 0 2 0 4 3 0 1 3 80: 1 5 0 1 0 0 1 0 0 0 90: 1 0 1 1 0 1 2 3 1 0 100:1 0 1 0 5 4 0 3 3 1 110:0 1 0 0 0 0 4 0 1 0 120:0 0 0 1 0 0 0 0 0 2 130:0 0 1 0 1 0 0 0 1 0 140:0 0 0 0 0 0 0 0 1 0 160:0 0 0 1 0 0 0 0 0 1 170:0 0 0 0 0 0 0 0 0 1 180:0 0 1 0 0 0 0 1 0 0 200:0 0 0 0 0 0 0 0 0 1 210:1 0 0 0 0 0 0 0 0 0 220:0 0 0 0 0 1 0 1 0 0 230:0 0 0 0 0 0 0 0 0 1 250:0 0 0 0 0 0 0 0 16 0 790:1 0 0 0 0 0 0 0 0 0 1150: 0 0 0 1 0 0 0 0 0 0 1280: 0 0 0 1 0 0 0 0 0 0 (Interesting - I never thought about that, but it looks as if most directories are empty.) Distribution of directory sizes (in 4kB blocks): 0 1 2 3 4 5 6 7 8 9 0: 3 126133 763 247 35 38 21 18 26 5 10: 10 16 102 3 8 9 4 2 10 1 20: 4 1 5 4 20 9 15 6 0 3 30: 0 3 3 0 0 0 0 3 1 1 40: 0 0 0 0 0 0 0 0 0 0 50: 0 0 0 0 1 0 0 0 0 0 - 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/
possible bug x86 2.4.2 SMP in IP receive stack
With dual x86 processors running 2.4.2, if I blast a UDP stream at the machine using netperf, I can easily cause the kernel to panic with the message below. Feb 23 12:42:30 rcc2 kernel: Warning: kfree_skb passed an skb still on a list (from c01f58dc). I'm going to pop out one processor on the receiver and see if that makes the problem go away. Note that this is using a Myrinet network that is able to get more than 1.5Gigabit/sec UDP transfers on single-processor x86 2.4.0 linux. Perhaps this is reproducible with good GigE cards with jumbo MTU turned on. I'm also upping the socket limits echo "1048576" > /proc/sys/net/core/rmem_max echo "1048576" > /proc/sys/net/core/wmem_max echo "1048576" > /proc/sys/net/core/wmem_default echo "1048576" > /proc/sys/net/core/rmem_default echo "1048576" > /proc/sys/net/core/optmem_max Feb 23 12:42:30 rcc2 kernel: Warning: kfree_skb passed an skb still on a list (from c01f58dc). Looking up the "from c01f58dc" in the ksyms shows that ip_rcv is the caller. c01f3d38 ip_route_input_Rsmp_0a99f032 c01f44f8 ip_route_output_key_Rsmp_4ce6fe49 c01f5170 inet_add_protocol_Rsmp_a27098bd c01f51f0 inet_del_protocol_Rsmp_0c8ae503 c01f5538 ip_rcv_Rsmp_587335e5 c01f58dc ERROR LOCATION (kfree_skb passed an skb still on a list (from c01f58dc)) c01f61dc ip_defrag_Rsmp_5532f3a2 c01f6b34 ip_options_compile_Rsmp_b8621391 c01f70ec ip_options_undo_Rsmp_9721f12f c01f8650 ip_fragment_Rsmp_41bc67d3 c01f8bb0 ip_send_check_Rsmp_a37b7441 c01f8bf8 ip_finish_output_Rsmp_5b565e28 On a different machine I have seen this. Feb 23 12:32:20 rcc kernel: KERNEL: assertion (del_timer(>timer) == 0) failed at ip_fragment.c(163):ip_frag_destroy CONFIG_X86=y CONFIG_ISA=y CONFIG_UID16=y CONFIG_EXPERIMENTAL=y CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y CONFIG_MPENTIUMIII=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_NOHIGHMEM=y CONFIG_SMP=y CONFIG_HAVE_DEC_LOCK=y CONFIG_NET=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_PCI=y CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y CONFIG_HOTPLUG=y CONFIG_SYSVIPC=y CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y CONFIG_PM=y CONFIG_ACPI=y CONFIG_PNP=y CONFIG_ISAPNP=y CONFIG_BLK_DEV_FD=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y CONFIG_BLK_DEV_IDEDISK=y CONFIG_BLK_DEV_IDECD=y CONFIG_BLK_DEV_CMD640=y CONFIG_BLK_DEV_RZ1000=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_IDE_MODES=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_PCI=y CONFIG_EEPRO100=y CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_SERIAL=y CONFIG_UNIX98_PTYS=y CONFIG_MOUSE=y CONFIG_PSMOUSE=y CONFIG_DRM=y CONFIG_DRM_TDFX=y CONFIG_AUTOFS_FS=y CONFIG_AUTOFS4_FS=y CONFIG_FAT_FS=y CONFIG_MSDOS_FS=y CONFIG_ISO9660_FS=y CONFIG_PROC_FS=y CONFIG_DEVPTS_FS=y CONFIG_EXT2_FS=y CONFIG_NFS_FS=y CONFIG_NFS_V3=y CONFIG_NFSD=y CONFIG_NFSD_V3=y CONFIG_SUNRPC=y CONFIG_LOCKD=y CONFIG_LOCKD_V4=y CONFIG_MSDOS_PARTITION=y CONFIG_NLS=y CONFIG_VGA_CONSOLE=y -- Bob Felderman (626) 821- Director of Software Development (626) 821-5316 fax Myricom Inc. [EMAIL PROTECTED] 325 N. Santa Anita Ave. http://www.myri.com Arcadia, CA 91006 -- - 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: creation of sock
looking further at net/ipv4/tcp_ipv4.c:tcp_create_openreq_child() (for 2.2.16) and net/ipv4/tcp_minisocks.c:tcp_create_openreq_child() (for 2.4.x) immediately after the sk_alloc() call (if it successful) it calls memcpy(newsk, sk, sizeof(*newsk)) i suggest setting your NULL initial values immediately after this line. sorry for the premature email - 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: reiserfs: still problems with tail conversion
On Friday, February 23, 2001 10:18:56 PM +0100 Erik Mouw <[EMAIL PROTECTED]> wrote: > Hi all, > > I am running linux-2.4.2-pre4 with Chris Mason's tailconversion bug fix > applied, but I still have problems with null bytes in files. I wrote a > little test program that clearly shows the problem: > Many thanks for sending along a test program for reproducing. But, it doesn't seem to reproduce the problem here, how many times did you have to run it to see the null bytes? Do you remove the files between runs? -chris - 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: DMA blues...System lockup on setting DMA mode using hdparam
On Fri, 23 Feb 2001, Jasmeet Sidhu wrote: > Also another question related to IDE: > Is there anyway we can see how good/bad the system performance is while > the system is working? that information (what the disk subsytem as a whole is doing) is collected in /proc/stat something like xosview can help you visualize it. > I am not talking about a benchmarking tool like > bonnie that simply tries to figure out how good a system can perform. I > would like to see something, maybe in /proc/ide/, that shows me the current > throughput of the ide subsystem. For example how many kb of data is going > in, how much coming out of each device. Any ideas on how to go about maybe > adding this? Where would be an ideal place to add such functionality? In > the ide code or maybe in the raid section? Or maybe these two should be > kept separate. Any thoughts guys? > > Any additional required information can be posted, let me know. > > Anybody else out there with a similar situation? Your thoughts on this > would be really appreciated. I actually have a similar situation although without hanging, with three controllers. the kernels detects the two devices on the third controller as udma rather than udma(100) with 2.4.1. hda: 30003120 sectors (15362 MB) w/1916KiB Cache, CHS=1867/255/63, UDMA(33) hdc: 30003120 sectors (15362 MB) w/1916KiB Cache, CHS=29765/16/63, UDMA(33) first two are on the server-works chipset controller hde: 150136560 sectors (76870 MB) w/1916KiB Cache, CHS=148945/16/63, UDMA(100) hdg: 150136560 sectors (76870 MB) w/1916KiB Cache, CHS=148945/16/63, UDMA(100) hdi: 150136560 sectors (76870 MB) w/1916KiB Cache, CHS=148945/16/63, UDMA(100) hdk: 150136560 sectors (76870 MB) w/1916KiB Cache, CHS=148945/16/63, UDMA(100) hdm: 30003120 sectors (15362 MB) w/1916KiB Cache, CHS=29765/16/63, (U)DMA hdo: 150136560 sectors (76870 MB) w/1916KiB Cache, CHS=148945/16/63, (U)DMA these 6 are on three promise contollers... all with 18" 80pin cable hdd: ATAPI 40X CD-ROM drive, 128kB Cache, UDMA(33) > Here's the setup: > > ide0 at 0x3800-0x3807,0x3402 on irq 11PDC20265 > ide1 at 0x3000-0x3007,0x2802 on irq 11 > ide2 at 0x5400-0x5407,0x5002 on irq 15PDC20267 > ide3 at 0x4800-0x4807,0x4402 on irq 15 > ide4 at 0x7000-0x7007,0x6802 on irq 11PDC20267 > ide5 at 0x6400-0x6407,0x6002 on irq 11 > ide6 at 0x8800-0x8807,0x8402 on irq 14PDC20267 > ide7 at 0x8000-0x8007,0x7802 on irq 14 > ide8 at 0xa400-0xa407,0xa002 on irq 10PDC20267 > ide9 at 0x9800-0x9807,0x9402 on irq 10 > > hda: 40188960 sectors (20577 MB) w/1916KiB Cache, CHS=39870/16/63, UDMA(100) > hdc: 150136560 sectors (76870 MB) w/1916KiB Cache, CHS=148945/16/63, UDMA(100) > hde: 150136560 sectors (76870 MB) w/1916KiB Cache, CHS=148945/16/63, UDMA(100) > hdg: 150136560 sectors (76870 MB) w/1916KiB Cache, CHS=148945/16/63, UDMA(100) > hdi: 150136560 sectors (76870 MB) w/1916KiB Cache, CHS=148945/16/63, UDMA(100) > hdk: 150136560 sectors (76870 MB) w/1916KiB Cache, CHS=148945/16/63, UDMA(100) > hdm: 150136560 sectors (76870 MB) w/1916KiB Cache, CHS=148945/16/63, UDMA(100) > hdo: 150136560 sectors (76870 MB) w/1916KiB Cache, CHS=148945/16/63, UDMA(100) > hdq: 150136560 sectors (76870 MB) w/1916KiB Cache, CHS=148945/16/63, UDMA(100) > hds: 150136560 sectors (76870 MB) w/1916KiB Cache, CHS=148945/16/63, UDMA(100) > > # Raid-5 configuration > # > raiddev /dev/md0 > raid-level5 > chunk-size4 > parity-algorithm left-symmetric > persistent-superblock 1 > nr-raid-disks 8 > nr-spare-disks1 > device/dev/hde1 > raid-disk 0 > device/dev/hdg1 > raid-disk 1 > device/dev/hdi1 > raid-disk 2 > device/dev/hdk1 > raid-disk 3 > device/dev/hdm1 > raid-disk 4 > device/dev/hdo1 > raid-disk 5 > device/dev/hdq1 > raid-disk 6 > device/dev/hds1 > raid-disk 7 > device/dev/hdc1 > spare-disk0 > > [root@bertha hdparm-3.9]# df -k > Filesystem 1k-blocks Used Available Use% Mounted on > /dev/hda3 19072868 3589612 14514392 20% / > /dev/hda1 198313 11667176392 7% /boot > /dev/md0 525461076 108657156 416803920 21% /raid > sj-f760-1:/vol/vol03/data01 > 142993408 140675648 2317760 99% /mnt/netapps > > - > 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/ > --
msdos ignored in 2.4.2, unless modules
Hi, compiled 2.4.2 this afternoon (fresh 2.4.0 tree, patched to 2.4.1 then 2.4.2). I'd selected 'Y' in menuconfig for fat, msdos, and vfat, but when I tried to mount a dos zip disk it told me the kernel didn't support fat. Recompiled with fat, msdos, vfat as modules and it runs fine. I imagine this is a problem in the lists controlling the Makefile, but I didn't understand fs/Makefile. The only thing perhaps unusual in the configuration is using msdos with reiserfs. .config follows Ken # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y # CONFIG_MODVERSIONS is not set CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set CONFIG_M586=y # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_USE_STRING_486=y CONFIG_X86_ALIGNMENT_16=y # CONFIG_TOSHIBA is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set # CONFIG_MTRR is not set # CONFIG_SMP is not set # CONFIG_X86_UP_IOAPIC is not set # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_EISA is not set # CONFIG_MCA is not set # CONFIG_HOTPLUG is not set # CONFIG_PCMCIA is not set CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m CONFIG_PM=y # CONFIG_ACPI is not set # CONFIG_APM is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=y CONFIG_PARPORT_PC=y # CONFIG_PARPORT_PC_FIFO is not set # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_AMIGA is not set # CONFIG_PARPORT_MFC3 is not set # CONFIG_PARPORT_ATARI is not set # CONFIG_PARPORT_SUNBPP is not set # CONFIG_PARPORT_OTHER is not set # CONFIG_PARPORT_1284 is not set # # Plug and Play configuration # CONFIG_PNP=y CONFIG_ISAPNP=y # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_LOOP is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_RAM is not set # CONFIG_BLK_DEV_INITRD is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # CONFIG_BLK_DEV_MD is not set # CONFIG_MD_LINEAR is not set # CONFIG_MD_RAID0 is not set # CONFIG_MD_RAID1 is not set # CONFIG_MD_RAID5 is not set # CONFIG_BLK_DEV_LVM is not set # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set # CONFIG_NETLINK is not set # CONFIG_NETFILTER is not set # CONFIG_FILTER is not set CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_IP_MROUTE is not set # CONFIG_INET_ECN is not set # CONFIG_SYN_COOKIES is not set # CONFIG_IPV6 is not set # CONFIG_KHTTPD is not set # CONFIG_ATM is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_LLC is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # Telephony Support # # CONFIG_PHONE is not set # CONFIG_PHONE_IXJ is not set # # ATA/IDE/MFM/RLL support # CONFIG_IDE=y # # IDE, ATA and ATAPI Block devices # CONFIG_BLK_DEV_IDE=y # CONFIG_BLK_DEV_HD_IDE is not set # CONFIG_BLK_DEV_HD is not set CONFIG_BLK_DEV_IDEDISK=y # CONFIG_IDEDISK_MULTI_MODE is not set # CONFIG_BLK_DEV_IDEDISK_VENDOR is not set # CONFIG_BLK_DEV_IDEDISK_FUJITSU is not set # CONFIG_BLK_DEV_IDEDISK_IBM is not set # CONFIG_BLK_DEV_IDEDISK_MAXTOR is not set # CONFIG_BLK_DEV_IDEDISK_QUANTUM is not set # CONFIG_BLK_DEV_IDEDISK_SEAGATE is not set # CONFIG_BLK_DEV_IDEDISK_WD is not set # CONFIG_BLK_DEV_COMMERIAL is not set # CONFIG_BLK_DEV_TIVO is not set # CONFIG_BLK_DEV_IDECS is not set CONFIG_BLK_DEV_IDECD=y # CONFIG_BLK_DEV_IDETAPE is not set
Re: CS4232 sound update
With the removal of the pnp selection, it worked, answered in another post to another topic, the 3c509 sb issue, almost as if isapnp is grabing the card its self and holding on in some way. Thank you Phil - 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] drivers/scsi/g_NCR5380.c, kernel 2.4.2
Hello
I found out that passing boot parameters to the g_NCR5380-driver didn't
work in the 2.4.x-series. It seems like other drivers might be affected,
too. I don't know if this has been discussed before, or if I'm doing
something completely wrong, but at least this patch of mine fixed the
problem. My solution is actually a simple modification of what I found
in aha152x.c. (It also fixes a very minor problem caused by using a
compile-time parameter, which is probably almost never used.)
I'm not subscribed to the list, so I'd be thankful for being personally
contacted with follow-up on this.
// Martin
--- linux/drivers/scsi/g_NCR5380.c.orig Thu Feb 22 19:11:42 2001
+++ linux/drivers/scsi/g_NCR5380.c Fri Feb 23 23:33:38 2001
@@ -139,7 +139,7 @@
int board; /* Use NCR53c400, Ricoh, etc. extensions ? */
} overrides
#ifdef GENERIC_NCR5380_OVERRIDE
-[] __initdata = GENERIC_NCR5380_OVERRIDE
+[] __initdata = GENERIC_NCR5380_OVERRIDE;
#else
[1] __initdata = {{0,},};
#endif
@@ -911,6 +911,53 @@
MODULE_PARM(ncr_53c400, "i");
MODULE_PARM(ncr_53c400a, "i");
MODULE_PARM(dtc_3181e, "i");
+
+#else
+
+static int __init do_NCR5380_setup(char *str)
+{
+int ints[10];
+
+get_options(str, sizeof(ints)/sizeof(int), ints);
+generic_NCR5380_setup(str,ints);
+
+return 1;
+}
+
+static int __init do_NCR53C400_setup(char *str)
+{
+int ints[10];
+
+get_options(str, sizeof(ints)/sizeof(int), ints);
+generic_NCR53C400_setup(str,ints);
+
+return 1;
+}
+
+static int __init do_NCR53C400A_setup(char *str)
+{
+int ints[10];
+
+get_options(str, sizeof(ints)/sizeof(int), ints);
+generic_NCR53C400A_setup(str,ints);
+
+return 1;
+}
+
+static int __init do_DTC3181E_setup(char *str)
+{
+int ints[10];
+
+get_options(str, sizeof(ints)/sizeof(int), ints);
+generic_DTC3181E_setup(str,ints);
+
+return 1;
+}
+
+__setup("ncr5380=", do_NCR5380_setup);
+__setup("ncr53c400=", do_NCR53C400_setup);
+__setup("ncr53c400a=", do_NCR53C400A_setup);
+__setup("dtc3181e=", do_DTC3181E_setup);
#endif
-
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: creation of sock
im a kernel newbie here so pardon "the blind leading the blind" ...
doing a quick search for all calls to sk_alloc in the entire kernel
sources
yields only one call that sets the "zero out the allocated struct"
boolean
to false and that is:
net/ipv4/tcp_minisocks.c:tcp_create_openreq_child().
this funtion in turn is only ever called from:
net/ipv[46]/tcp_ipv[46].c:tcp_v[46]_syn_recv_sock()
the comment above the ipv4 version is (verbatim):
/*
* The three way handshake has completed - we got a valid synack -
* now create the new socket.
*/
so if you need those experimental values of yours zeroed out on socket
creation i suggest replacing this snippet from
net/core/sock.c:sk_alloc()
if(sk && zero_it) {
memset(sk, 0, sizeof(struct sock));
sk->family = family;
sock_lock_init(sk);
}
with
if( sk ) {
/* set your NULL init values here */
if( zero_it ) {
memset(sk, 0, sizeof(struct sock));
sk->family = family;
sock_lock_init(sk);
}
}
doh! i just re-read your mail and realized youre using the 2.2.15
kernel.
my examples are from the 2.4.2 sources...
looking at the 2.2.16 source (i have only 2.2.1[46] and not 2.2.15 for
the
2.2 series) the (roughly) congruent if block of code is:
if(sk) {
if (zero_it)
memset(sk, 0, sizeof(struct sock));
sk->family = family;
}
and so if you're setting your init values to NULL under the "zero_it"
condition you would get the behavior that you reported.
hope that helps.
-
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: cpu_has_fxsr or cpu_has_xmm?
Quim K Holland wrote: > > DL> As to the correctness, the mxcsr register really only exists > DL> if you have xmm, so the xmm is the correct test. However,... > > DL> ... User space programmers should be checking for xmm > DL> capability themselves before ever paying attention to mxcsr > DL> anyway, so it's not an end of the world error. > > If that is the case, wouldn't it be simpler to always return > tsk->thread.i387.fxsave.mxcsr from this function, and initialize > that field to 0x1f80 (whatever that magic number means) when > the structure is built? > No, because the CPU *may* overwrite it when you do an FXSAVE. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - 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: [rfc] Near-constant time directory index for Ext2
Hi,
I while ago I did some experimentation with simple bit-op based string
hash
functions. I.e., no multiplications / divides in the hash loop.
The best I found was:
int hash_fn (char * p)
{
int hash = 0;
while (*p) {
hash = hash + *p;
// Rotate a 31 bit field 7 bits:
hash = ((hash << 7) | (hash >> 24)) & 0x7fff;
}
return hash;
}
[I haven't kept my test program / data set - if anyone compares the
above
to the others functions mentioned on the list, let me know.]
The 31 and 7 were determined experimentally. But the 31 has a
theoretical
explanation (which might even be valid):
The rotate is equivalent to a multiplication by x**7 in Z_2[P=0],
where P is the polynomial x**31 - 1 (over Z_2).
Presumably the "best" P would be irreducible - but that would have more
bits set in the polynomial, making reduction harder. A compromise is to
choose P in the form x**N - 1 but with relatively few factors.
X**31 - 1 is such a P.
Also, a 32 bit rotate (modulo X**32 - 1, which is equal
to (X - 1) ** 32 over Z_2), came out pretty badly.
One thing that shouldn't be forgotten about hashing for hash tables
is that you have to reduce the hash value to the required range - doing
that well greatly reduces the difference between various hash functions.
Ralph.
-
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.1-ac16: add CDROM_LOCKDOOR ioctl to IDE floppies
Francis, do I understand that you can remove the disk while it is
mounted? If so, there is a later version of ide-floppy.c (0.96) on
sourceforge.net which for some reason hasn't made it into the -ac kernels.
With 2.4.2 vanilla and ide-floppy 0.96 I don't get this problem, it also
removes some i/o error messages I was seeing.
Ken
On Mon, 19 Feb 2001, Francis Galiegue wrote:
> Patch below. It Work For Me(tm) with an IDE ZIP drive.
>
> --- drivers/ide/ide-floppy.c.oldMon Feb 19 13:39:55 2001
> +++ drivers/ide/ide-floppy.cMon Feb 19 13:48:53 2001
> @@ -1517,15 +1517,21 @@
> unsigned int cmd, unsigned long arg)
> {
> idefloppy_pc_t pc;
> + int prevent = (arg) ? 1 : 0;
>
> switch (cmd) {
> case CDROMEJECT:
> + prevent = 0;
> + /* fall through */
> + case CDROM_LOCKDOOR:
> if (drive->usage > 1)
> return -EBUSY;
> - idefloppy_create_prevent_cmd (, 0);
> - (void) idefloppy_queue_pc_tail (drive, );
> - idefloppy_create_start_stop_cmd (, 2);
> + idefloppy_create_prevent_cmd (, prevent);
> (void) idefloppy_queue_pc_tail (drive, );
> + if (cmd == CDROMEJECT) {
> + idefloppy_create_start_stop_cmd (, 2);
> + (void) idefloppy_queue_pc_tail (drive, );
> + }
> return 0;
> case IDEFLOPPY_IOCTL_FORMAT_SUPPORTED:
> return (0);
>
>
>
-
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/
reiserfs: still problems with tail conversion
Hi all,
I am running linux-2.4.2-pre4 with Chris Mason's tailconversion bug fix
applied, but I still have problems with null bytes in files. I wrote a
little test program that clearly shows the problem:
/* reisertest.c: test for tailconversion bug in reiserfs
*
* Compile with: gcc -O2 -o reisertest reisertest.c
*/
#include
#include
#include
#include
#include
#define MAXBYTES8192
int main(int argc, char *argv[])
{
int fd;
int i;
char name[32];
char buf[MAXBYTES];
char check[MAXBYTES];
memset(buf, 0x55, MAXBYTES);
fprintf(stderr, "Creating %d files ... ", MAXBYTES);
for(i = 0; i < MAXBYTES; i++) {
sprintf(name, "reiser-%05d.test", i);
fd = open(name, O_WRONLY | O_CREAT, 0644);
write(fd, buf, i);
close(fd);
}
fprintf(stderr, "done\n");
fprintf(stderr, "Appending to the files ... ");
for(i = 0; i < MAXBYTES; i++) {
sprintf(name, "reiser-%05d.test", i);
fd = open(name, O_WRONLY | O_APPEND);
write(fd, buf, MAXBYTES - i);
close(fd);
}
fprintf(stderr, "done\n");
fprintf(stderr, "Checking files for null bytes ...\n");
for(i = 0; i < MAXBYTES; i++) {
sprintf(name, "reiser-%05d.test", i);
fd = open(name, O_RDONLY);
read(fd, check, MAXBYTES);
if(memcmp(buf, check, MAXBYTES) != 0)
fprintf(stderr, " %s contains null bytes\n", name);
}
fprintf(stderr, "Checking done\n");
return 0;
}
When I run this on a reiserfs partition, I get output like this:
erik@arthur:~/reisertest/foo> ../reisertest
Creating 8192 files ... done
Appending to the files ... done
Checking files for null bytes ...
reiser-00193.test contains null bytes
reiser-00220.test contains null bytes
reiser-00256.test contains null bytes
reiser-00289.test contains null bytes
reiser-00329.test contains null bytes
reiser-00338.test contains null bytes
reiser-00374.test contains null bytes
reiser-00407.test contains null bytes
reiser-00415.test contains null bytes
reiser-00430.test contains null bytes
reiser-00438.test contains null bytes
reiser-00445.test contains null bytes
reiser-00459.test contains null bytes
reiser-00481.test contains null bytes
reiser-00501.test contains null bytes
reiser-00508.test contains null bytes
reiser-00521.test contains null bytes
reiser-00534.test contains null bytes
reiser-00558.test contains null bytes
reiser-00577.test contains null bytes
reiser-00583.test contains null bytes
reiser-00600.test contains null bytes
reiser-00606.test contains null bytes
reiser-00612.test contains null bytes
reiser-00623.test contains null bytes
reiser-00634.test contains null bytes
reiser-00645.test contains null bytes
reiser-00665.test contains null bytes
reiser-00685.test contains null bytes
reiser-00730.test contains null bytes
reiser-00735.test contains null bytes
reiser-00740.test contains null bytes
reiser-00745.test contains null bytes
reiser-00750.test contains null bytes
reiser-00759.test contains null bytes
reiser-00764.test contains null bytes
reiser-00773.test contains null bytes
reiser-00778.test contains null bytes
reiser-00787.test contains null bytes
reiser-00796.test contains null bytes
reiser-00805.test contains null bytes
reiser-00814.test contains null bytes
reiser-00866.test contains null bytes
reiser-00915.test contains null bytes
reiser-00930.test contains null bytes
reiser-00934.test contains null bytes
reiser-00938.test contains null bytes
reiser-00942.test contains null bytes
reiser-00946.test contains null bytes
reiser-00950.test contains null bytes
reiser-00954.test contains null bytes
reiser-00958.test contains null bytes
reiser-00965.test contains null bytes
reiser-00969.test contains null bytes
reiser-00973.test contains null bytes
reiser-00977.test contains null bytes
reiser-00984.test contains null bytes
reiser-00988.test contains null bytes
reiser-00995.test contains null bytes
reiser-00999.test contains null bytes
reiser-01006.test contains null bytes
reiser-01010.test contains null bytes
reiser-01017.test contains null bytes
Checking done
Running the test a couple of times doesn't really show a pattern,
sometimes the same files contains null bytes, sometimes others do. The
files with null bytes seem to be with index < 1024.
I did the same test with an ext2 filesystem, but didn't see any error.
System is SuSE 7.0, compiler gcc-2.95.2.
Erik
--
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands
Phone:
Re: [ANNOUNCE] Boot log for Linux PPC64 on POWER3 hardware
Peter Samuelson wrote: : Impressive. One question, though -- : : > starting cpu /cpus/PowerPC,[EMAIL PROTECTED] : > starting cpu /cpus/PowerPC,[EMAIL PROTECTED] : > starting cpu /cpus/PowerPC,[EMAIL PROTECTED] : : You have 4 CPUs? : : > OpenPIC Version 1.2 (8 CPUs and 32 IRQ sources) at e1002000 : > OpenPIC timer frequency is 0 MHz : : ...or is it 8 CPUs? : : > swamsauger:~ # uname -a : > Linux swamsauger 2.4.0-tg11 #188 Thu Feb 22 19:55:45 CST 2001 ppc64 unknown : > swamsauger:~ # : > swamsauger:~ # cat /proc/cpuinfo : > processor : 0 : : ...or just one CPU? Olaf pretty much answered all your questions. Yes we are running a non-SMP kernel at the moment, but even non-SMP kernels need to place an SMP's unused processors in a spin loop so they don't play havoc with the system. Peter -- Peter Bergner SLIC Optimizing Translator Development / Linux PPC64 Kernel Development IBM Rochester, MN [EMAIL PROTECTED] - 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: [ANOMALIES]: 2.4.2 - __alloc_pages: failed & mount hanging withloop device issues
Ok apply patch and loop patch... I'll let you know what happens in my next
email.
Mike Galbraith wrote:
> On Fri, 23 Feb 2001, Shawn Starr wrote:
>
> > Feb 23 03:31:18 coredump kernel: __alloc_pages: 3-order allocation
> > failed.
> > Feb 23 03:31:18 coredump kernel: __alloc_pages: 3-order allocation
> > failed.
> > Feb 23 03:31:18 coredump kernel: __alloc_pages: 2-order allocation
> > failed.
> > Feb 23 03:31:18 coredump kernel: __alloc_pages: 3-order allocation
> > failed.
> > Feb 23 03:31:18 coredump kernel: __alloc_pages: 3-order allocation
> > failed.
> > Feb 23 03:31:18 coredump kernel: __alloc_pages: 2-order allocation
> > failed.
> > Feb 23 03:31:18 coredump kernel: __alloc_pages: 3-order allocation
> > failed.
> >
> > The use of mkisofs and xcdroster with cdrecord seems to cause this fault
> > in kernel.log
>
> Hi,
>
> Can you try the below for the high order allocation problem? We don't
> try very hard at all to service high order allocations under load. If
> it helps, let me know and I'll submit it to Rik for consideration.
>
> (for loop troubles, you should try Jens' latest loop patch located in
> your favorite kernel mirror under pub/linux/kernel/people/axboe)
>
> -Mike
>
> (patch was done against 2.4.1-ac20, but should go in ok)
> --- mm/page_alloc.c.org Fri Feb 23 13:21:54 2001
> +++ mm/page_alloc.c Fri Feb 23 13:28:33 2001
> @@ -274,7 +274,7 @@
> struct page * __alloc_pages(zonelist_t *zonelist, unsigned long order)
> {
> zone_t **zone;
> - int direct_reclaim = 0;
> + int direct_reclaim = 0, loop = 0;
> unsigned int gfp_mask = zonelist->gfp_mask;
> struct page * page;
>
> @@ -366,7 +366,7 @@
> * able to free some memory we can't free ourselves
> */
> wakeup_kswapd();
> - if (gfp_mask & __GFP_WAIT) {
> + if (gfp_mask & __GFP_WAIT && loop) {
> __set_current_state(TASK_RUNNING);
> current->policy |= SCHED_YIELD;
> schedule();
> @@ -393,6 +393,7 @@
> * --> try to free pages ourselves with page_launder
> */
> if (!(current->flags & PF_MEMALLOC)) {
> + loop++;
> /*
> * Are we dealing with a higher order allocation?
> *
> @@ -440,7 +441,7 @@
> memory_pressure++;
> try_to_free_pages(gfp_mask);
> wakeup_bdflush(0);
> - if (!order)
> + if (!order || loop < (1 << order))
> goto try_again;
> }
> }
-
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: Linux 2.4.1-ac15
On Fri, 23 Feb 2001, Andrea Arcangeli wrote: > > I think that can't happen. Infact I think the whole section: > > pmd = pmd_offset(pgd, address); > pmd_k = pmd_offset(pgd_k, address); > > if (pmd_present(*pmd) || !pmd_present(*pmd_k)) > goto bad_area_nosemaphore; > set_pmd(pmd, *pmd_k); > return; > > is superflows. No. Think about the differences in PAE and non-PAE mode. > The middle pagetable is shared and the pmd_t entry is set by vmalloc itself (it > just points to the as well shared pte), it's only the pgd that is setup lazily In non-PAE mode, the pgd entry doesn't exist. pgd_present() returns a unconditional 1. Its' the pmd functions that kick in then. Linus - 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: cpu_has_fxsr or cpu_has_xmm?
> "DL" == Doug Ledford <[EMAIL PROTECTED]> writes:
>> > --- linux.vanilla/arch/i386/kernel/i387.c Thu Feb 22 09:05:35 2001
>> > +++ linux.ac/arch/i386/kernel/i387.cSun Feb 4 10:58:36 2001
>> > @@ -179,7 +179,7 @@
>> >
>> > unsigned short get_fpu_mxcsr( struct task_struct *tsk )
>> > {
>> > - if ( cpu_has_fxsr ) {
>> > + if ( cpu_has_xmm ) {
>> > return tsk->thread.i387.fxsave.mxcsr;
>> > } else {
>> > return 0x1f80;
>> >
DL> As to the correctness, the mxcsr register really only exists
DL> if you have xmm, so the xmm is the correct test. However,...
DL> ... User space programmers should be checking for xmm
DL> capability themselves before ever paying attention to mxcsr
DL> anyway, so it's not an end of the world error.
If that is the case, wouldn't it be simpler to always return
tsk->thread.i387.fxsave.mxcsr from this function, and initialize
that field to 0x1f80 (whatever that magic number means) when
the structure is built?
--== Sent via Deja.com ==--
http://www.deja.com/
-
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/
DMA blues...System lockup on setting DMA mode using hdparam
Hey guys, I have five Promise ATA100 controllers configured using kernel version 2.4.2-ac1 (using pdc202xx drivers of course) on ASUS A7V with a AMD Tbird 1GHz processor. Now for the most part this kernel is very stable. I have premium cables connected to the hard drives and all drives in the system are masters as you can probably tell by the drive device letters assigned. The cables are 80pin UDMA (100% Data Integrity). I have not seen any CRC errors, in fact the system has been up overnight and has almost transferred about 105GB of data in various file sizes. The problem: when trying to set the DMA mode on the drives, using "hdparm -X69 /dev/hda", it works fine. As a matter of fact, this command succeeds for the following devices: /dev/hda, /dev/hdc, /dev/hdm, /dev/hdo, /dev/hdq, /dev/hds However, the system locks up completely when I try the same exact command for *any* of the following devices: /dev/hde, /dev/hdg, /dev/hdi, /dev/hdk. *NOTE* the Raid5 array /dev/md0 is not running when I am trying to set the DMA modes. The raid is not mounted and is in stopped mode using raidstop /dev/md0. Also, when I try and use the -k and the -K switches (keep settings after reset), the programs says that it worked. However, after I restart the system, these "flags" are set to 0 again. Is this normal? In other words: hdparam -k /dev/hda keepsettings = 0 (off) # now lets set the -k option (keep settings after refresh). hdparam -k1 /dev/hda setting keep_settings to 1 (on) keepsettings = 1 (on) # noe lets restart the system and query again hdparam -k /dev/hda keepsettings = 0 (off) Is this normal? Also another question related to IDE: Is there anyway we can see how good/bad the system performance is while the system is working? I am not talking about a benchmarking tool like bonnie that simply tries to figure out how good a system can perform. I would like to see something, maybe in /proc/ide/, that shows me the current throughput of the ide subsystem. For example how many kb of data is going in, how much coming out of each device. Any ideas on how to go about maybe adding this? Where would be an ideal place to add such functionality? In the ide code or maybe in the raid section? Or maybe these two should be kept separate. Any thoughts guys? Any additional required information can be posted, let me know. Anybody else out there with a similar situation? Your thoughts on this would be really appreciated. Here's the setup: ide0 at 0x3800-0x3807,0x3402 on irq 11 PDC20265 ide1 at 0x3000-0x3007,0x2802 on irq 11 ide2 at 0x5400-0x5407,0x5002 on irq 15 PDC20267 ide3 at 0x4800-0x4807,0x4402 on irq 15 ide4 at 0x7000-0x7007,0x6802 on irq 11 PDC20267 ide5 at 0x6400-0x6407,0x6002 on irq 11 ide6 at 0x8800-0x8807,0x8402 on irq 14 PDC20267 ide7 at 0x8000-0x8007,0x7802 on irq 14 ide8 at 0xa400-0xa407,0xa002 on irq 10 PDC20267 ide9 at 0x9800-0x9807,0x9402 on irq 10 hda: 40188960 sectors (20577 MB) w/1916KiB Cache, CHS=39870/16/63, UDMA(100) hdc: 150136560 sectors (76870 MB) w/1916KiB Cache, CHS=148945/16/63, UDMA(100) hde: 150136560 sectors (76870 MB) w/1916KiB Cache, CHS=148945/16/63, UDMA(100) hdg: 150136560 sectors (76870 MB) w/1916KiB Cache, CHS=148945/16/63, UDMA(100) hdi: 150136560 sectors (76870 MB) w/1916KiB Cache, CHS=148945/16/63, UDMA(100) hdk: 150136560 sectors (76870 MB) w/1916KiB Cache, CHS=148945/16/63, UDMA(100) hdm: 150136560 sectors (76870 MB) w/1916KiB Cache, CHS=148945/16/63, UDMA(100) hdo: 150136560 sectors (76870 MB) w/1916KiB Cache, CHS=148945/16/63, UDMA(100) hdq: 150136560 sectors (76870 MB) w/1916KiB Cache, CHS=148945/16/63, UDMA(100) hds: 150136560 sectors (76870 MB) w/1916KiB Cache, CHS=148945/16/63, UDMA(100) # Raid-5 configuration # raiddev /dev/md0 raid-level 5 chunk-size 4 parity-algorithmleft-symmetric persistent-superblock 1 nr-raid-disks 8 nr-spare-disks 1 device /dev/hde1 raid-disk 0 device /dev/hdg1 raid-disk 1 device /dev/hdi1 raid-disk 2 device /dev/hdk1 raid-disk 3 device /dev/hdm1 raid-disk 4 device /dev/hdo1 raid-disk 5 device /dev/hdq1 raid-disk6 device /dev/hds1 raid-disk 7 device /dev/hdc1 spare-disk 0 [root@bertha hdparm-3.9]# df -k Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda3 19072868 3589612 14514392 20% / /dev/hda1 198313 11667176392 7% /boot /dev/md0 525461076 108657156 416803920 21% /raid sj-f760-1:/vol/vol03/data01
Re: Linux 2.4.2ac3
On 02.23 Alan Cox wrote: > > Handle with care.. Its possible the ioremap debugging change > might remove casts that hid older problems in a few drivers > > > ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ > > 2.4.2-ac3 make xconfig: /tkparse < ../arch/i386/config.in >> kconfig.tk drivers/scsi/pcmcia/Config.in: 20: unterminated 'if' condition Misses a backslash at EOL. if [ "$CONFIG_PCMCIA_QLOGIC" = "y" -o "$CONFIG_PCMCIA_AHA152X" = "y" -o \ "$CONFIG_PCMCIA_FDOMAIN" = "y" -o "$CONFIG_PCMCIA_APA1480" = "y" -o ^^^ "$CONFIG_PCMCIA_NINJA_SCSI" ]; then define_bool CONFIG_PCMCIA_SCSICARD y fi -- J.A. Magallon $> cd pub mailto:[EMAIL PROTECTED] $> more beer Linux werewolf 2.4.2-ac1 #2 SMP Fri Feb 23 02:34:42 CET 2001 i686 - 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: Linux 2.4.1-ac15
On Thu, Feb 22, 2001 at 10:29:58AM +, Alan Cox wrote:
> > >We can take page faults in interrupt handlers in 2.4 so I had to use a
> > >spinlock, but that sounds the same
> >
> > Umm? The above doesn't really make sense.
> >
> > We can take a page fault on the kernel region with the lazy page
> > directory filling, but that code will just set the PGD entry and exit
> > without taking any lock at all. So it basically ends up being an
> > "invisible" event.
>
> Its only normally invisible. Mark Hemment pointed out there is currently a
> race where if both cpus go to fill in the same entry the logic goes
>
> CPU1CPU2
>
> pgd present pgd present
> pmd not present
> load pmd
> pmd present
> Explode messily
>
I think that can't happen. Infact I think the whole section:
pmd = pmd_offset(pgd, address);
pmd_k = pmd_offset(pgd_k, address);
if (pmd_present(*pmd) || !pmd_present(*pmd_k))
goto bad_area_nosemaphore;
set_pmd(pmd, *pmd_k);
return;
is superflows.
The middle pagetable is shared and the pmd_t entry is set by vmalloc itself (it
just points to the as well shared pte), it's only the pgd that is setup lazily
to simplify the locking (locking is simplified of an order of magnitude because
for example in set_64bit we don't need the lock on the bus but we just need to
do the 64bit move in a single instruction so we can't be interrupted in the
middle by an irq and all sort of similar issues that now becomes serialized
inside the local CPU).
So in short unless I'm misreading something I think all the vmalloc faults will
be handled by the:
if (!pgd_present(*pgd)) {
if (!pgd_present(*pgd_k))
goto bad_area_nosemaphore;
set_pgd(pgd, *pgd_k);
return;
}
Said that there are a couple of other issues with the vmalloc pgd lazy handling
but nothing specific to SMP or threads.
1) we can triple fault (page_fault -> irq -> vmalloc fault -> irq -> vmalloc fault)
and I'm not sure if the cpu will reset after that because the three faults are
interleaved
with two irq exceptions, and it's not so easy to find the answer empirically, and
the documentation doesn't specify that apparently. If it resets (it shouldn't if the
cpu was well designed) then the whole vmalloc lazy design will be hardly fixable.
2) we could race with irqs locally to the CPU this way during the vmalloc handler:
irq handler
vmalloc_fault
nested irq_handler
vmalloc fault
pgd is not present
set_pgd
iret
pgd is present
enter the pmd business and find the pmd is just set
goto error
and I suspect this is actually the bug triggered by Mark.
3) offtopic with the vmalloc thing but I also noticed in some place during the
pgd/pmd/pte allocations we re-check that nobody mapped in the pagetable from
under us. But in 2.4 we don't hold the big lock so sleeping or not sleeping during
allocations is meaningless w.r.t. serialization, we rely only the semaphore
and on the fact other tasks can't play with our pagetables (one of the reason
dropping set_pgdir simplifys the locking).
So I did this patch that should be the correct cure for the vmalloc pgd irq race (2)
and that drops a few double checks that seems unnecessary (2) and hopefully (1)
is not an issue and the cpu is smart enough to understand it must not hard
reset:
diff -urN -X /home/andrea/bin/dontdiff 2.4.2/arch/i386/mm/fault.c
2.4.2aa/arch/i386/mm/fault.c
--- 2.4.2/arch/i386/mm/fault.c Thu Feb 22 03:44:53 2001
+++ 2.4.2aa/arch/i386/mm/fault.cFri Feb 23 21:15:53 2001
@@ -326,23 +326,19 @@
int offset = __pgd_offset(address);
pgd_t *pgd, *pgd_k;
pmd_t *pmd, *pmd_k;
+ unsigned long flags;
pgd = tsk->active_mm->pgd + offset;
pgd_k = init_mm.pgd + offset;
- if (!pgd_present(*pgd)) {
- if (!pgd_present(*pgd_k))
- goto bad_area_nosemaphore;
+ __save_flags(flags);
+ __cli();
+ if (!pgd_present(*pgd) && pgd_present(*pgd_k)) {
set_pgd(pgd, *pgd_k);
+ __restore_flags(flags);
return;
}
-
- pmd = pmd_offset(pgd, address);
- pmd_k = pmd_offset(pgd_k, address);
-
- if (pmd_present(*pmd) || !pmd_present(*pmd_k))
- goto bad_area_nosemaphore;
- set_pmd(pmd, *pmd_k);
- return;
+
Re: [Ext2-devel] [rfc] Near-constant time directory index for Ext2
From: Daniel Phillips <[EMAIL PROTECTED]> Date: Fri, 23 Feb 2001 00:04:02 +0100 I resolve not to take a position on this subject, and I will carry forward both a 'squeaky clean' backward-compatible version that sets an INCOMPAT flag, and a 'slightly tarnished' but very clever version that is both forward and backward-compatible, along the lines suggested by Ted. Both flavors have the desireable property that old versions of fsck with no knowledge of the new index structure can remove the indices automatically, with fsck -y. Note that in the long run, the fully comatible version should probably have a COMPAT feature flag set so that you're forced to use a new enough version of e2fsck. Otherwise an old e2fsck may end up not noticing corruptions in an index block which might cause a new kernel to have serious heartburn. - Ted - 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/
creation of sock
Hello, I'm using linux 2.2.15 kernel on redhat. I have added some variables (pointers) on "sock" data structure. I was initializing them to NULL in sk_alloc() function. But it seems some sock structures are allocated for TCP bypassing this sk_alloc() and due to this my added pointers are not initialized to NULL all the time. Can anyone tell me which function is being called for generating sock for TCP connections ( I guess for a aprticular TCP packet type, not for all, as I'm getting into this problem intermittently, esp., when I try access some specified website from my PC) ? Thanks -- Sourav - 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/
Testing EZMLM-alike tricks at this list..
For reasons seen earlier today, I implemented ways to produce individual SMTP-level MAIL FROM envelope addresses per recipient. Idea for it is partially from EZMLM, but details (location of the devil, as saying goes) are different. Because we really like the normal operation where each message thru a list gets expanded into *very few* internal messages, and thus consumes very little of local disk space, this EZMLM-alike method won't be kept running constantly. Consider, list gets email of 60 kB with some log, or large patch (a few each week). Our normal case expands it to 1-3 sub-files for 3000+ recipients total. Production of individual MAIL FROM- addresses mandates that we generate, route, and deliver 3000+ copies of the message. (Gee momma, who blew away 180 MB diskspace ?) Hmm.. Indeed I see a way to do things smarter, but the MAIL FROM mungling needs to be moved to SMTP speakers, which needs complicated signaling from list-expander thru the entire MTA to the SMTP output subsystem... Not quite trivial -- at least not tonight. After I have seen that this message goes thru with appropriate manglings, I turn things back into old mode. List-Owner(s) will have their tools for pathology hunting, if they choose to turn them on. /Matti Aarnio - co-postmaster of vger.kernel.org PS: If you care about the coding, it is: linux-kernel-owner+RCPTMUNGLE where the mungle has plain characters, and '=' characters following with two HEX digits, just like with Quoted-Printable encoding. Decode =HH parts, and you should see your own address. - 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: regular lockup on 2.4.2 (w/oops)
On Friday, 23 February 2001 at 19:50, Alan Cox wrote: > > I wonder if it's related to ACPI and/or IDE - I seem to get on > > occasion one ide_dmaproc: lost interrupt message during fsck - after a > > few seconds it recovers only to hang for good some 10-15 seconds > > later. > > Turn off ACPI and try that kernel. If that one also causes problems then it > helps a lot as it implies its not ACPI. If it works then its ACPI and most > of us will be happy (except Andrew of course) Preliminary results indicate ACPI was the culprit. I brought up my system a couple times and SysRq-S,B'd, forcing full fsck's of all my filesystems. With ACPI enabled I never got through all of them, now everything appears ok. Will let you know if the problem reoccurs. Thanks, Brendan - 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: TESTERS PLEASE - improvements to knfsd for 2.4.2
On Fri, 23 Feb 2001, Matthias Andree wrote: > On Thu, 22 Feb 2001, Henning P. Schmiedehausen wrote: > > > [EMAIL PROTECTED] (Neil Brown) writes: > > > > Oh, please not again a stable kernel series with NFS problems, we're > > locked in for ages. 2.2 was bad enough up to 2.2.18. We have ReiserFS > > in 2.4.1 (and not in 2.4.0), could we _please_ get NFS-exportable > > ReiserFS in 2.4.4 or 2.4.5? > > 2.2.18 is still broken, won't play NFSv3 games with FreeBSD clients. > Neil has posted a patch here which fixes this. > > And, ReiserFS messes NFSv3 up, I'm currently switching all my boxes back > to ext2, because I'm really pissed. And if these NFS annoyances > continue, it might be about time to try FreeBSD or NetBSD. Journalling > file systems which hide their files away for maintainer incompetence and > uncoordinated patching around don't buy us anything except continued > "don't use Linux as NFS server" reputation. If you need journaled file systems and NFS I have been using XFS and it seems to be fine when exported over NFS (Yes I know it isn't in the main kernel - hopefully that changes soon). James Rich [EMAIL PROTECTED] - 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/
VM balancing problems under 2.4.2-ac1
Hiya. The VM balancing updates in the recent ac kernels seem to have caused some interesting performance problems on my desktop machine. I've got 160Mb of RAM, and 2.4.2-ac1 appears to be using excessively large amounts of it for buffers and cache while pushing stuff out to swap. This means that Mozilla, for instance, runs significantly worse than under 2.4.0, since bits of it are being swapped in and out. After the machine had been sitting for a while not doing very much: procs memoryswap io system cpu r b w swpd free buff cache si sobibo in cs us sy id 1 0 0 97184 2116 12844 111768 5 61511 154 791 29 4 67 After some heavy reiserfs disk IO (deleting lots of small files): procs memoryswap io system cpu r b w swpd free buff cache si sobibo incs us sy id 1 0 0 102620 1796 85836 43880 100 025 0 190 587 12 3 85 -- Adam Sampson [EMAIL PROTECTED] - 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/
building 2.4.2 (with XFS) fails
When building 2.4.2 with XFS patches the build fails with errors that don't seem related to XFS (that's why the crosspost): gcc -V egcs-2.91.66 -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe -march=i686-c -o dec_and_lock.o dec_and_lock.c rm -f lib.a ar rcs lib.a checksum.o old-checksum.o delay.o usercopy.o getuser.o putuser.o iodebug.o memcpy.o dec_and_lock.o make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/arch/i386/lib' make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux/arch/i386/lib' make[1]: Entering directory `/usr/src/linux-2.4-xfs/linux' ld -m elf_i386 -T /usr/src/linux/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o --start-group arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o drivers/block/block.o drivers/char/char.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/parport/driver.o drivers/char/drm/drm.o drivers/ide/idedriver.o drivers/scsi/scsidrv.o drivers/cdrom/driver.o drivers/sound/sounddrivers.o drivers/pci/driver.o drivers/video/video.o drivers/i2c/i2c.o drivers/md/mddev.o net/network.o /usr/src/linux/arch/i386/lib/lib.a /usr/src/linux/lib/lib.a /usr/src/linux/arch/i386/lib/lib.a --end-group -o vmlinux drivers/char/char.o: In function `vt_ioctl': drivers/char/char.o(.text+0x96fb): undefined reference to `key_maps' drivers/char/char.o(.text+0x97cd): undefined reference to `key_maps' drivers/char/char.o(.text+0x97ed): undefined reference to `key_maps' drivers/char/char.o(.text+0x9808): undefined reference to `keymap_count' drivers/char/char.o(.text+0x9877): undefined reference to `key_maps' drivers/char/char.o(.text+0x9889): undefined reference to `keymap_count' drivers/char/char.o(.text+0x98df): undefined reference to `key_maps' drivers/char/char.o(.text+0x990a): undefined reference to `keymap_count' drivers/char/char.o(.text+0x9a2e): undefined reference to `func_table' drivers/char/char.o(.text+0x9ad7): undefined reference to `funcbufsize' drivers/char/char.o(.text+0x9ae5): undefined reference to `funcbufleft' drivers/char/char.o(.text+0x9afa): undefined reference to `funcbufptr' drivers/char/char.o(.text+0x9b09): undefined reference to `func_table' drivers/char/char.o(.text+0x9b22): undefined reference to `func_table' drivers/char/char.o(.text+0x9b46): undefined reference to `func_table' drivers/char/char.o(.text+0x9b57): undefined reference to `func_table' drivers/char/char.o(.text+0x9c0b): undefined reference to `func_table' drivers/char/char.o(.text+0x9c40): more undefined references to `func_table' follow drivers/char/char.o: In function `vt_ioctl': drivers/char/char.o(.text+0x9c4a): undefined reference to `funcbufleft' drivers/char/char.o(.text+0x9cc2): undefined reference to `func_table' drivers/char/char.o(.text+0x9cc8): undefined reference to `funcbufptr' drivers/char/char.o(.text+0x9d19): undefined reference to `funcbufptr' drivers/char/char.o(.text+0x9d25): undefined reference to `func_table' drivers/char/char.o(.text+0x9d69): undefined reference to `funcbufptr' drivers/char/char.o(.text+0x9dc0): undefined reference to `funcbufptr' drivers/char/char.o(.text+0x9dc9): undefined reference to `func_table' drivers/char/char.o(.text+0x9dfb): undefined reference to `funcbufptr' drivers/char/char.o(.text+0x9e01): undefined reference to `func_buf' drivers/char/char.o(.text+0x9e15): undefined reference to `funcbufptr' drivers/char/char.o(.text+0x9e1b): undefined reference to `funcbufleft' drivers/char/char.o(.text+0x9e29): undefined reference to `funcbufsize' drivers/char/char.o(.text+0x9e2f): undefined reference to `funcbufleft' drivers/char/char.o(.text+0x9e39): undefined reference to `funcbufsize' drivers/char/char.o(.text+0x9e43): undefined reference to `func_table' drivers/char/char.o(.text+0x9e76): undefined reference to `accent_table_size' drivers/char/char.o(.text+0x9e89): undefined reference to `accent_table_size' drivers/char/char.o(.text+0x9e92): undefined reference to `accent_table' drivers/char/char.o(.text+0x9edd): undefined reference to `accent_table_size' drivers/char/char.o(.text+0x9eea): undefined reference to `accent_table' drivers/char/char.o: In function `handle_scancode': drivers/char/char.o(.text+0x164c1): undefined reference to `key_maps' drivers/char/char.o(.text+0x1651a): undefined reference to `key_maps' drivers/char/char.o: In function `handle_diacr': drivers/char/char.o(.text+0x16c28): undefined reference to `accent_table_size' drivers/char/char.o(.text+0x16c49): undefined reference to `accent_table' drivers/char/char.o(.text+0x16c5b): undefined reference to `accent_table' drivers/char/char.o(.text+0x16ca7): undefined reference to `accent_table' drivers/char/char.o: In function `do_fn': drivers/char/char.o(.text+0x16d1f): undefined reference to `func_table' drivers/char/char.o: In function `compute_shiftstate': drivers/char/char.o(.text+0x16f99):
Re: Reiserfs, 3 Raid1 arrays, 2.4.1 machine locks up
As other posts have pointed out, if you have BAD HDMA cables, you will experience problems. One thing I would suggest is that you add kernel.*/dev/console to your /etc/syslog.conf so that you see any errors resulting from the kernel code. Also I would suggest that you open another virtual terminal and leave tail -f /var/log/messages and keep an eye on it when the system could possibly crash. This should help you out a little bit. At 09:36 PM 2/22/2001 +0100, Pavel Machek wrote: >Hi! > > > I partitioned the 2 drives (on 1st and 2nd controller, both 1.3 GB each) > > into 4 total partitions. 1st is swap and then the next 3, 1 primary, 2 > > extended are for raid 1 arrays. I've given 20 MB to /boot (md0), 650MB > > to / (md1) and the rest (400+MB) to /var (md2). I format md0 as ext2 > > and md1 and md2 as reiserfs. When I go to untar the image on the cd to > > /mnt/slash (which has md1 mounted on it), the system extracts about 30MB > > of data and then just stops responding. No kernel output, etc. I can > > change to the other virtual consoles, but no other keyboard input is > > accepted. After resetting the machine, the raid arrays rebuild ok, and > > reiserfs gives me no problems other than it usually replays 2 or 3 > > transactions. If I tell tar to pickup on the last directory I saw > > extracted, it gets about another 30MB of data and stops again. I've > > waited for the raid syncing to be finished or just started after the > > arrays are available and it doesn't matter. > >Try running sync; sync; sync; ... while untarring. > Pavel >-- >I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." >Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] >- >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/ - - - Jasmeet Sidhu Unix Systems Administrator ArrayComm, Inc. [EMAIL PROTECTED] www.arraycomm.com - 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: Trying to fix 3dfx.o + question about char drivers..
Michael Bacarella wrote:
> So, I upgrade to 2.4.0 and it's cool, except that I can't do
> anything neat with my voodoo3 anymore. I've been looking
> for a solution for weeks but to no avail. 3dfx's web site
> looks like it's gone and nothing on lk about it.
>
> The process calls ioctl() after opening /dev/3dfx. That ioctl() triggers
> an mmap() call, the driver gets addresses it's totally not expecting,
> and it returns -EPERM.
struct file_operations has changed in 2.4.0. The following patch for 3dfx
module fixes the structure initialization and makes it work just fine.
--- 3dfx_driver.c Sun Apr 9 03:44:10 2000
+++ 3dfx_driver.c Fri Feb 23 22:42:06 2001
@@ -707,25 +707,10 @@
#endif /* HAVE_MTRR */
static struct file_operations fops_3dfx = {
- NULL, /* llseek (2.1) / lseek (2.0) */
- NULL, /* read */
- NULL, /* write */
- NULL, /* readdir */
- NULL, /* poll (2.1) / select (2.0) */
- ioctl_3dfx, /* ioctl */
- mmap_3dfx, /* mmap */
- open_3dfx, /* open */
-#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 1, 118)
- NULL, /* flush (2.1.118+) */
-#endif
- release_3dfx, /* release */
- NULL, /* fsync */
- NULL, /* fasync */
- NULL, /* check_media_change */
- NULL, /* revalidate */
-#ifdef KERNEL_VER_2_1
- NULL/* lock (2.1) */
-#endif
+ ioctl: ioctl_3dfx,
+ mmap: mmap_3dfx,
+ open: open_3dfx,
+ release:release_3dfx
};
#ifdef MODULE
-
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: Via UDMA5 3/4/5 is not functional!
CRC errors are due to faulty cables. Go buy some cables that are
good. I've had this problem and the only fix is to use better
cables. Infact, If you get really bad cables, on lets say hdc which is on
the same controller as hda, then when the kernel resets the harddrive
giving crc errors hdc, hda will also hang and you will get DMA
timeouts. This will leave your machine in a frozen state, much like the
BSOD of the windows world...
Here is what happens when one of the drives has a bad cable...
In this setup, hdo and hdm are both master IBM DLTA drives connected to a
Promise ATA100 controller. Both drives are masters as there are no slave
drives configured in this setup. The promise controller has 2 ide channels,
ide0 would be /dev/hdm and /dev/hdn and ide1 would be then /dev/hdo and
/dev/hdp. As said above, only masters /dev/hdm and /dev/hdo are
used. When /dev/hdo has DMA problems, mainly CRC, the kernel will try to
fix the controller by sending a reset, which also takes /dev/hdm down with it.
Feb 20 22:37:29 bertha kernel: hdo: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Feb 20 22:37:29 bertha kernel: hdo: dma_intr: error=0x84 { DriveStatusError
BadCRC }
Feb 20 22:37:29 bertha kernel: hdo: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Feb 20 22:37:29 bertha kernel: hdo: dma_intr: error=0x84 { DriveStatusError
BadCRC }
Feb 20 22:37:29 bertha kernel: hdo: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Feb 20 22:37:29 bertha kernel: hdo: dma_intr: error=0x84 { DriveStatusError
BadCRC }
Feb 20 22:37:29 bertha kernel: hdo: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Feb 20 22:37:29 bertha kernel: hdo: dma_intr: error=0x84 { DriveStatusError
BadCRC }
Feb 20 22:37:29 bertha kernel: hdo: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Feb 20 22:37:29 bertha kernel: hdo: dma_intr: error=0x84 { DriveStatusError
BadCRC }
Feb 20 22:37:29 bertha kernel: hdo: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Feb 20 22:37:29 bertha kernel: hdo: dma_intr: error=0x84 { DriveStatusError
BadCRC }
Feb 20 22:37:29 bertha kernel: ide7: reset: success
Feb 20 22:37:49 bertha kernel: hdm: timeout waiting for DMA
Feb 20 22:37:49 bertha kernel: ide_dmaproc: chipset supported
ide_dma_timeout func only: 14
Feb 20 22:37:49 bertha kernel: hdm: irq timeout: status=0x52 { DriveReady
SeekComplete Index }
Feb 20 22:37:59 bertha kernel: hdm: timeout waiting for DMA
Feb 20 22:37:59 bertha kernel: ide_dmaproc: chipset supported
ide_dma_timeout func only: 14
Feb 20 22:37:59 bertha kernel: hdm: irq timeout: status=0x50 { DriveReady
SeekComplete }
Feb 20 22:38:19 bertha kernel: hdm: timeout waiting for DMA
Feb 20 22:38:19 bertha kernel: ide_dmaproc: chipset supported
ide_dma_timeout func only: 14
Feb 20 22:38:19 bertha kernel: hdm: irq timeout: status=0x50 { DriveReady
SeekComplete }
Feb 20 22:38:39 bertha kernel: hdm: timeout waiting for DMA
Feb 20 22:38:39 bertha kernel: ide_dmaproc: chipset supported
ide_dma_timeout func only: 14
Feb 20 22:38:39 bertha kernel: hdm: irq timeout: status=0x50 { DriveReady
SeekComplete }
Feb 20 22:38:39 bertha kernel: hdm: DMA disabled
Feb 20 22:38:39 bertha kernel: ide6: reset: success
At 04:38 PM 2/22/2001 +0100, Ricardo Galli wrote:
> > Then I tried kernel 2.4.1. I issued exactly the same hdparm command.
> > i got in syslog the message: "ide0: Speed warnings UDMA 3/4/5 is not
> > functional"!
>
>
>I had the same problem.
>
>Add
>append="ide0=ata66 ide1=ata66 ide0=autotune ide1=autotune hda=autotune
>hdb=autotune hdc=autotune"
>to lilo.conf.
>
>
>BTW, I am having now CRC errors in IDE1 on the VIA, IDE0 it's ok at udma5
>and 30MB/sec.
>
>Regards,
>
>--ricardo
>http://m3d.uib.es/~gallir/
>
>-
>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/
- - -
Jasmeet Sidhu
Unix Systems Administrator
ArrayComm, Inc.
[EMAIL PROTECTED]
www.arraycomm.com
-
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: EXT2-fs error
On Fri, 23 Feb 2001, Alan Cox wrote: > Date: Fri, 23 Feb 2001 19:26:17 + (GMT) > From: Alan Cox <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] > Subject: Re: EXT2-fs error > > > > Possibly the result of the 'silent' bug in 2.4.1? > > > > you are not the only one who found this bug. immediately after booting 2.4.2 i > > received dozens of these errors, resulting in _major_ filesystem corruption. > > after a half hour of fsck'ing i managed to bring the machine back into a usable > > Had you been running 2.4.1 before that ? I had, and received a bit different corruption involving inode and block bitmap errors rather than directories... ac19 seems so far to have solved it. > - > 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/ > - John Heil South Coast Software Custom systems software for UNIX and IBM MVS mainframes 1-714-774-6952 [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.sc-software.com - - 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: EXT2-fs error
On Fri, 23 Feb 2001, Ian Wehrman wrote: > Date: Fri, 23 Feb 2001 13:12:05 -0600 > From: Ian Wehrman <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] > Subject: Re: EXT2-fs error > > Mohammad A. Haque <[EMAIL PROTECTED]> wrote: > > I got the following after compiling/rebooting into 2.4.2 and forcing a > > fsck. > > > > EXT2-fs error (device ide0(3,3)): ext2_readdir: bad entry in directory > > #508411: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, > > name_len=0 > > EXT2-fs error (device ide0(3,3)): ext2_readdir: bad entry in directory > > #508411: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, > > name_len=0 > > > > Possibly the result of the 'silent' bug in 2.4.1? > > you are not the only one who found this bug. immediately after booting 2.4.2 i > received dozens of these errors, resulting in _major_ filesystem corruption. In contrast perhaps, 2.4.1-ac19 seems clean so far in this regard after having some different but equivalently bad corruption in 2.4.1-final. > after a half hour of fsck'ing i managed to bring the machine back into a usable > state, but there are still many files and directories around the fs that have > the wrong uid/gid associated with them, as well as incorrect file type, > permissions, etc. i'm not using any unusual hardware, and haven't had any > other recent issues like this. let me know if i can provide further information, > or test patches. > > thanks, > ian wehrman > - > 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/ > - John Heil South Coast Software Custom systems software for UNIX and IBM MVS mainframes 1-714-774-6952 [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.sc-software.com - - 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: regular lockup on 2.4.2 (w/oops)
> I wonder if it's related to ACPI and/or IDE - I seem to get on > occasion one ide_dmaproc: lost interrupt message during fsck - after a > few seconds it recovers only to hang for good some 10-15 seconds > later. Turn off ACPI and try that kernel. If that one also causes problems then it helps a lot as it implies its not ACPI. If it works then its ACPI and most of us will be happy (except Andrew of course) - 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/
Linux 2.4.2ac3
Handle with care.. Its possible the ioremap debugging change might remove casts that hid older problems in a few drivers ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ 2.4.2-ac3 o Add documentation for the fb interfaces (Brad Douglas) o Work around apic disable_irq hardware bugs (Maciej Rozycki) o Rage128 not "Rage 128" (Brad Douglas) o Make ioremap debugging conditional (J Magallon) o Merge Ninja pcmcia scsi driver (YOKOTA Hiroshi) o Update 8139too docs (Jeff Garzik) o Tulip updates, merge bits from 0.92 (Jeff Garzik, Don Becker) o Epic100 update (Jeff Garzik) o Clen up Ariadne driver (Jeff Garzik) o Remove dead wavelan prototype (Jeff Garzik) o Remove unused arlan variable(Jeff Garzik) o Clean up lance public symbols (Jeff Garzik) o Switch fmv18x to spinlocks, fix other bits (Jeff Garzik) o Clean up acenic global symbols (Jeff Garzik) o Fix IDE blocking kmalloc with irqs off (Arjan van de Ven) | I've redone the code a bit so it might be wrong again 8) 2.4.2-ac2 o Merge the loop device fixes (Jens Axboe) o Fix af_unix SYSCTL=n build failure (Russell King) o Adjust the throttling point for write (Jens Axboe) throttles o Fix sunhme ioremap (Andrey Panin) o Fix disk change handling with removable sd (Alex Davis) o Update/fix irq docs (Matthew Wilcox) o Update PPC gmac and ncr885e drivers (Cort Dougan) | bmac patch dropped as it loses other fixes o Kai Petzke has moved(Kai Petzke) o Fix starfire driver so pump doesnt kill it (Ion Badulescu) 2.4.2-ac1 o Merge Linus 2.4.2 tree | We now have disagreeing ymfpci fixes. I've kept the ones | I tested for now. o Back out sr.c change(me) o Fix moxa smartio driver (Tom Mraz) o Hugh Blemings change of address (Hugh Blemings) o Allow more i2o config time for slow calls o Aty128fb updates(Brad Douglas, Benjamin Herrenschmidt, Michel Danzer, Andreas Hundt) o Add "loop" name to the root dev names (Barry Nathan) o Further spelling cleanups (Dag Wieers) o Remove bogus warning emissions from aha1740 (Nick Holloway) o Remove surplus assignment in vmalloc(Francis Galiegue) o Remove unneeded ifdef in i386/kernel/irq.c (Francis Galiegue) o Add door locking ioctl to ide-floppy(Francis Galiegue) o Allow scsi disk opening O_NDELAY for removables (me) o Fix cosa compile warnings (me) o Clean up dumpable/setuid write ordering (me) o Hopefully fix the 3ware crashes (me) 2.4.1-ac20 o Update fusion drivers (Steve Ralston) o Further VM page launder balancing (Rik van Riel) o Hopefully fix ext2 block size checking (Andries Brouwer) o Update the i810 random number generator (Jeff Garzik) o Hopefully fix the bonding crash on down/reboot (Dave Miller) o Tulip update (add accton comets, clean up pm) (Jeff Garzik) o Merge wavelan_cs, pcnet_cs and fmvj18x_cs (Jeff Garzik) changes from Dave Hinds tree o Make awe32 behave in 2.4 like 2.2 if given an (Bill Nottingham) io o Fix alpha build problems in stallion, c101 (Andrzej Krzysztofowicz) synclink and wavfront drivers o Add isa_check_signature and missing ioctl ids (Andrzej Krzysztofowicz) for hayesesp o Fix math emulation bug (Martin Schwidefsky) o Disable APIC during APM to avoid suspend/resume (Mikael Pettersson) problems. o SMP kernel on UP hardware APIC fixes(Maciej Rozycki) o Code cleanups in nmi, reduce NMI rate to 1Hz(Mikael Pettersson) 2.4.1-ac19 o Fix second module/exception table race (me) | I hope ;) o Additional CPIA usb ident (Adam J Richter) o Add SA1100 udc and also stall recovery to (Oleg Drokin) usbnet o Limit smbfs to 2Gig/file(Urban Widmark) o
regular lockup on 2.4.2 (w/oops)
Hi,
Since running 2.4.2 I've been getting regular lockups, usually during
the boot process but occasionally during regular usage too. I've
copied down an oops by hand from the console (it seems to be always
the same oops, except ESI varies).
I wonder if it's related to ACPI and/or IDE - I seem to get on
occasion one ide_dmaproc: lost interrupt message during fsck - after a
few seconds it recovers only to hang for good some 10-15 seconds
later.
My system: dual PIII/550 on a 440 BX (Gigabyte 6bxds), 256 MB RAM.
The oops is generated after I do SysRq-S,U,B. If I don't try to reboot
with SysRq it just hangs indefinitely.
I've rolled back to 2.4.1, although I'm a bit afraid since I've heard
reports of FS corruption under it...?
Here's the oops report:
--
ksymoops 2.3.7 on i686 2.4.2. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.2/ (default)
-m /boot/System.map-2.4.2 (default)
Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.
NMI Watchdog detected LOCKUP on CPU0, registers:
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 0097
eax: ebx: ecx: 0001 edx: c031050c
esi: c1582000 edi: 0007 ebp: 0062 esp: c02dbec0
Process swapper (pid: 0 stackpage=c02db000)
Stack: c0325660 c0111f88 c02f83cd c0111fc8 c0111f88
0001 c01072de c0325660 c0193e91 c027e711
0030 270f c02d9000 c0192304 0062 c02dbfa8 c0325660
Call Trace: [] [] [] [] []
[] [] []
[] [] [] [] [] []
[] []
[] [] [] [] []
Code: 8b 44 24 0c 39 c8 75 f8 85 db 74 0c eb 02 89 f6 8b 44 24 10
>>EIP; c0111f50<=
Trace; c0111f88
Trace; c0111fc8
Trace; c0111f88
Trace; c01072de
Trace; c01072de
Trace; c0193e91
Trace; c0192634
Trace; c019378d
Trace; c0193818
Trace; c01096c1
Trace; c010a8a6
Trace; c0107170
Trace; c0107170
Trace; c010901c
Trace; c0107170
Trace; c0107170
Trace; c0100018
Trace; c0107196
Trace; c0107202
Trace; c0105000
Trace; c01001cf
Code; c0111f50
<_EIP>:
Code; c0111f50<=
0: 8b 44 24 0c mov0xc(%esp,1),%eax <=
Code; c0111f54
4: 39 c8 cmp%ecx,%eax
Code; c0111f56
6: 75 f8 jne0 <_EIP>
Code; c0111f58
8: 85 db test %ebx,%ebx
Code; c0111f5a
a: 74 0c je 18 <_EIP+0x18> c0111f68
Code; c0111f5c
c: eb 02 jmp10 <_EIP+0x10> c0111f60
Code; c0111f5e
e: 89 f6 mov%esi,%esi
Code; c0111f60
10: 8b 44 24 10 mov0x10(%esp,1),%eax
1 warning issued. Results may not be reliable.
-
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: Linux device driver writing
On Fri, Feb 23, 2001 at 03:06:13PM -0200, Marcus Ramos wrote: > For Linux you can use the good and complete "Linux Device Drivers" by > Alessandro Rubini, O'Reilly, 1998. For other flavors of Unix, I am aware only > of old text books of little interest for present systems. Good luck. Problem with that edition is quite old. Yes, it's good and the general guidelines still apply, but the details are obsoleted by the newer kernels. When I asked the O'Reilly at LWE NY, they told me that the second edition (which covers 2.4) will be released in May this year. Another good place to start is of course http://www.kernelnewbies.org/ Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ - 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: floppy linux installation
On Fri, Feb 23, 2001 at 12:19:05PM +0530, Srinivas Surabhi wrote: > I need help from somebody. > > Iwant to install Linux with just floppythrough FTP server. This is off topic for the linux kernel mailing list. > I am searching in net regarding How to make FTP installation floppy . > > can any body pls refer some web sites or procedure?. Quite a lot of linux distributions allow you to install linux with a couple of floppies and an FTP server. I know both Debian and SuSE can work that way because I tried it myself. See: http://www.debian.org/ http://www.suse.com/ or http://www.suse.de/en/ I'm quite sure the other distributions also support install via FTP. Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ - 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: problem with mount -o loop
Tim Tim wrote: > I made iso-image from cd with > dd if=/dev/hdd of=/image.iso > and mount it with > mount -o loop /image.iso /mnt/cdrom > under Linux-2.4.2-pre1 it is working > but under Linux-2.4.2 do not > Please help me to understand why If it was working it was by sheer luck - You need the loop patches available at ftp://ftp.kernel.org/pub/linux/kernel/people/axboe/patches jjs - 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: EXT2-fs error
> > Possibly the result of the 'silent' bug in 2.4.1? > > you are not the only one who found this bug. immediately after booting 2.4.2 i > received dozens of these errors, resulting in _major_ filesystem corruption. > after a half hour of fsck'ing i managed to bring the machine back into a usable Had you been running 2.4.1 before that ? - 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: loop-6 patch and 2.4.2
On Friday 23 February 2001 10:50, Mohammad A. Haque wrote: > Is anyone else using 2.4.2 patched with loop-6? Does load goto about 1 > and stay there even though mounting things via loop seem to work fine? Yes, and with 2 mounts the load avg goes ~2; after umounting, it goes back to normal levels. - 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/
[FAQ] pls add migrate 2.2 -> 2.4 Re: 3c509 + sb16 bug
Alan, You've mentioned this before. I emailed Steve directly since I had the same sort of problem with a trio of ethernet cards. Hardware detection goes wacky when mixing isapnp userspace tools with the CONFIG_ISAPNP support in the kernel. Steve told me: "I'm running debian sid, with isapnptools package version: 1.21-2" This should go into the FAQ at http://www.tux.org/lkml/ Here is Alan's quote: Fri, 16 Feb 2001 12:34:03 + (GMT) "Dont mix isapnp tools with a 2.4 kernel unless you disable ISA PnP support in the kernel. It needs to have one or the other do it, not both" If you use isapnp tools, make sure your config looks like this: # # Plug and Play configuration # CONFIG_PNP=y # CONFIG_ISAPNP is not set Rob On Fri, 23 Feb 2001, Alan Cox wrote: > > Perhaps it's cold comfort, but I found long ago that > > 3c509 and SB don't mix too well, at least in Linux. > > I've had them mixed ok before > > > ISA devices are somewhat dumb, switching one > > of the cards for a PCI version does the trick here. > > I think the problem here thought isnt the 3c509 and SB card, its the kernel > plug and play code. You might want to try building kernels with no PnP support > at all and see how they behave > - > 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/ - 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/
problem with mount -o loop
I made iso-image from cd with dd if=/dev/hdd of=/image.iso and mount it with mount -o loop /image.iso /mnt/cdrom under Linux-2.4.2-pre1 it is working but under Linux-2.4.2 do not Please help me to understand why __ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices! http://auctions.yahoo.com/ - 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: EXT2-fs error
Mohammad A. Haque <[EMAIL PROTECTED]> wrote: > I got the following after compiling/rebooting into 2.4.2 and forcing a > fsck. > > EXT2-fs error (device ide0(3,3)): ext2_readdir: bad entry in directory > #508411: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, > name_len=0 > EXT2-fs error (device ide0(3,3)): ext2_readdir: bad entry in directory > #508411: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, > name_len=0 > > Possibly the result of the 'silent' bug in 2.4.1? you are not the only one who found this bug. immediately after booting 2.4.2 i received dozens of these errors, resulting in _major_ filesystem corruption. after a half hour of fsck'ing i managed to bring the machine back into a usable state, but there are still many files and directories around the fs that have the wrong uid/gid associated with them, as well as incorrect file type, permissions, etc. i'm not using any unusual hardware, and haven't had any other recent issues like this. let me know if i can provide further information, or test patches. thanks, ian wehrman - 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: 3c509 + sb16 bug
> Perhaps it's cold comfort, but I found long ago that > 3c509 and SB don't mix too well, at least in Linux. I've had them mixed ok before > ISA devices are somewhat dumb, switching one > of the cards for a PCI version does the trick here. I think the problem here thought isnt the 3c509 and SB card, its the kernel plug and play code. You might want to try building kernels with no PnP support at all and see how they behave - 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: 3c509 + sb16 bug
Perhaps it's cold comfort, but I found long ago that 3c509 and SB don't mix too well, at least in Linux. ISA devices are somewhat dumb, switching one of the cards for a PCI version does the trick here. SB128, SBlive work fine, or you might want to go to a 10/100 pci ethernet card. Just my $.02 jjs Steve wrote: > The evidence really speaks for itself: > > firstly, I have been running a 2.2.18 kernel system, with a 3c509b and a > soundblaster 16 (and sundry other hardware). > > The soundblaster 16 is on 0x220, irq 5. Its a soundblaster 16 (vibra 16b, '94) > The 3c509 is pnp and detects under 2.2.18 as the following: > eth0: 3c509 at 0x300 tag 1, 10baseT port, address 00 a0 24 75 b7 28, IRQ 10. > > Both cards work perfectly, and autodetect without any arguments. > > Now: > > Here are the interesting bits of the boot of the 2.4.x kernel: > > PCI: PCI BIOS revision 2.10 entry at 0xfb4f0, > last bus=1 > PCI: Using configuration type 1 > PCI: Probing PCI hardware > Unknown bridge resource 0: assuming transparent > Unknown bridge resource 1: assuming transparent > Unknown bridge resource 2: assuming transparent > PCI: Using IRQ router ALI [10b9/1533] at 00:07.0 > isapnp: Scanning for Pnp cards... > isapnp: Card '3Com 3C509B EtherLink III' > isapnp: 1 Plug & Play card detected total > > eth0: 3c509 at 0x220, 10baseT port, address 00 20 24 75 b7 28, IRQ 5. > 3c509.c:1.16 (2.2) 2/3/98 [EMAIL PROTECTED] > > Soundblaster audio driver Copyright (C) by Hannu Savolainen 1993-1996 > sb: No ISAPnP cards found, trying standard ones... > sb: I/O, IRQ, and DMA are mandatory > > NB: PCI stuff was interesting, but I'm not sure if its connected to this > situation. > > After bootup, at a random time interval between 10 seconds and 5 minutes the > following error spams the screen: > eth0: infinite loop in interrupt, status 2001 > > I can only conclude that the kernel has mistaken an ethernet card for a > sound card. > > for convience, here is an lspci: > 00:00.0 Host bridge: Acer Laboratories Inc. [ALi] M1541 (rev 04) > 00:01.0 PCI bridge: Acer Laboratories Inc. [ALi] M5243 (rev 04) > 00:07.0 ISA bridge: Acer Laboratories Inc. [ALi] M1533 PCI to ISA Bridge > [Aladdin IV] (rev c3) > 00:08.0 VGA compatible controller: Matrox Graphics, Inc. MGA 2064W [Millennium] > (rev 01) > 00:0f.0 IDE interface: Acer Laboratories Inc. [ALi] M5229 IDE (rev c2) > > Stephen Thorne > > >Part 1.2Type: application/pgp-signature - 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: [rfc] Near-constant time directory index for Ext2
Jonathan Morton writes:
> Meanwhile, let's go back to Linus' comment on compatibility and so on. He
> has a *very* good point, which I'll expand on slightly here:
>
> Suppose some stone-age Linux user, running 2.0.35 or something equally old
> (which runs ext2), decides to finally bite the bullet and upgrade...
> ... 2.0.35's old ext2 code suddenly can't read the filesystem, which was
> modified by 2.6.1 before the boot process stalled.
One of the proposals on the table for the indexed directories is read AND
WRITE compatible with older kernels. For 1.0 through 2.4 kernels the read
compatibility is very safe (it will generate some errors on reads because
of "sparse" directory blocks, but the code will continue on correctly,
<= 1.2 won't even generate an error). For < 2.2 kernels deleting a file from
an indexed directory will work, but would leave the index out of date.
For < 2.2 kernels adding a new file to an indexed directory would always
overwrite the index, so it is also safe.
> I hope people understand this as well as I do - if a filesystem upgrade is
> desirable, let the user perform some *specific* action to upgrade it, when
> he has an otherwise-working setup *and* sufficient backups. I for one do
> not want to be caught out like the hypothetical user I mentioned above.
I am on the side of maintaining compatibility. There _may_ be a _small_
performance (more like capacity) impact on indexed directories for this
compatibility, but it is well worth it, IMHO.
> - Currently, it's a stable and universally-utilised filesystem which offers
> very good performance for most applications. I'm specifically drawing
> attention to certain benchmarks which place ext2's disk-based performance
> ahead of many commercial UNIX' ram-based filesystem performance.
Totally agree.
> - There are specific problems with performance when reading and/or
> modifying large directories. I haven't tested for this personally, but I
> have noticed slowness when using 'rm -rf' on a large *tree* of directories.
That is what the index change will address. Actually, "rm -r" may not
be speeded up very much, but "rm *" definitely would be ("rm -r" deletes
files in directory order, but "rm *" deletes each file individually in
alphabetical order).
> One of the current suggestions, if I've interpreted it correctly, is to
> introduce an extension to ext2 which essentially makes a "fast index" of a
> large directory, attaches it to the directory in some backwards-compatible
> manner, and uses it *in conjunction with* the regular directory structure.
Yes, this is essentially true. The on-disk directory entries are exactly
the same. The index itself (in the compatible layout) appears to simply
be empty directory blocks (at the cost of 8 bytes = 1 index entry per block).
> - How much overhead does the "fast index" introduce for modification of the
> directory? Large directories are the most likely to have stuff added and
> deleted, and it doesn't help if during an "rm *" operation the saving on
> the search is negated by the overhead on the unlink.
The index will improve the performance for file add, stat, and delete. For
all of these operations you need to find a directory entry (add needs to
check if a file of the same name already exists before a new file is added).
> - If the index gets out of sync with the directory, how is this detected
> and recovered from? Assuming the index merely points to the correct
> position in the regular directory, some simple sanity checks will suffice
> for most cases (is this entry in the directory the same as I asked for?),
> and if the entry is not in the index then a standard search of the real
> directory can be done. In either case, the index can be marked as invalid
> (and removed?) and rebuilt whenever necessary.
On an index-aware kernel, the index can obviously not get out of sync.
All 2.2+ kernels that don't understand indexing will clear the "has
index" flag if they modify that directory, and the index will disappear.
Since the index is "hidden" (in my proposal at least) inside a totally
normal directory block, it will simply be overwritten by new entries.
As I mentioned above, 1.x and 2.0 kernels will overwrite the index on
an add, but not on a delete, and will not clear the "has index" flag.
This means we need some extra magic at the start of the index to ensure
we have a valid index header.
> - At what threshold of directory size does the index come into play?
> (fairly obviously, the index is useless for tiny directories)
This remains to be seen. Definitely not for directories 1 block in size
(which is 85%? of all directories). It looks like directories with about
250-300 files or more are needed for indexing to be useful. The good
news is that since indexing is optional, it can be tuned to only improve
performance of directories.
> - What happens when an old kernel encounters a directory which has an index
> attached to it? Does it look like a virtual file,
Re: filesystem statistics
Andries Brouwer writes: > Now that people are discussing the right hash function to use, > and the amount of space taken by filenames in various schemes, > I wondered how these things are on a random machine. > Here some statistics. Can you generate statistics on the number of files in each directory, and the total size of each directory? For total directory size, it may be useful to have not only size in kB and/or disk blocks, but also the sum of raw dentry sizes as well, because directories always show full block sizes. This would also be helpful to determine how often indexing will be used in an "average" system. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - 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/
loop-6 patch and 2.4.2
Is anyone else using 2.4.2 patched with loop-6? Does load goto about 1 and stay there even though mounting things via loop seem to work fine? -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - 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: Very high bandwith packet based interface and performance problems
Hello! > > Yes its a SHOULD in RFC1122, but in any normal environment pretty much a > > must and I know of no stack significantly violating it. > > I didn't know there was such a thing as a normal environment :) Jokes apart, such "normal" environments are rare today. >From tcpdumps it is clear, that win2000 does not ack each other mss. It can ack once per window at high load. I have seen the same behaviour of solaris. freebsd-4.x surely does not ack each second mss (it is from source code), which is probably bug (at least, it stops to ack at all as soon as MSG_WAITALL is used. 8)) Acking each second mss is required to do slow start more or less fastly. As soon as window is full, they are useless, so that win2000 is fully right and, in fact, optimal. Alexey - 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: reiserfs problem
Chris Mason wrote: > > On Friday, February 23, 2001 05:03:40 PM + Patrick Mackinlay > <[EMAIL PROTECTED]> wrote: > > > When 2.4.1 was released I reported a kernel oops with reiserfs, I got no > > response. > > Hmmm, don't seem to have any other reiserfs mail from you. Sorry I missed > it. > > [ ...] > > > > kernel oops report: > >>> EIP; d2cf9db8 <[reiserfs]create_virtual_node+298/490> <= > > We've had a half dozen or so reports so far of this, almost every time it > has been resolved as a compiler issue, usually an unpatched gcc 2.96. One > user was using 2.95.3, but did not report back if switching to 2.95.2 or > egcs fixed the oops. > > Anyway, which compiler did you use to compile the kernel? > > -chris I didn't want to join the kernel mailing list (too much traffic) so I sent it to the email address suggested on the reiserfs home page. I guess it didn't get through. It seems I am in fact using a buggy compiler (damn RedHat 7, forgot I had upgraded on this machine) I will try re-compiling with another compiler and let you know if I still have problems. regards, Patrick -- Patrick Mackinlay[EMAIL PROTECTED] ICQ: 59277981tel: +44 7050699851 fax: +44 7050699852 SpaceSurfer Limited http://www.spacesurfer.com/ - 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/
