Re: Microsoft and Xenix.
Kai Henningsen wrote: > No. GEM, I believe, originally came from CP/M. Most popular as the > windowing system of the Atari ST; given that someone did a quick-hack MS- > DOS clone to support it on the 68K, it seems fairly obvious that by that > time, it had already been ported to MS-DOS. (GEM-DOS is the only os I know > of that was actually worse than MS-DOS.) And ATARI goofed by not including more than GEM in the ST(e). Should have used the whole system like the TT and Falcon did. > Friends of mine (Gereon Steffens and Stefan Eissing) wrote a command-line If you see them, tell them an old STe user thanks them for there work. Without them I might never have headed to Unix :) Vielen Dank Herren. > shell and desktop replacement for the Atari that was fairly successful > shareware for a while ... now how was it called? The CLI was Mupfel > (German for shell is Muschel, and there was a kid's TV character who > pronounced Muschel as Mupfel), and I think the desktop was Gemini. Another I still have Gemini on a Disk for my STe. The SCSI adaptor died, so I don't know if the data is still good though. Then I tried the Minix port MinT (Mint is not TOS :) and was hooked on Unix. If I could get my SCSI adaptor fixed/replaced I'd still have my STe running, maybe even get a memory card (for > 4Meg) and a CPU upgrade (68000 is slow, get 68030 or 40 like the Falcon) Then I could run Linux on it (it need that math co-proc) -Thomas - 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: Microsoft and Xenix.
Kai Henningsen wrote: No. GEM, I believe, originally came from CP/M. Most popular as the windowing system of the Atari ST; given that someone did a quick-hack MS- DOS clone to support it on the 68K, it seems fairly obvious that by that time, it had already been ported to MS-DOS. (GEM-DOS is the only os I know of that was actually worse than MS-DOS.) And ATARI goofed by not including more than GEM in the ST(e). Should have used the whole system like the TT and Falcon did. Friends of mine (Gereon Steffens and Stefan Eissing) wrote a command-line If you see them, tell them an old STe user thanks them for there work. Without them I might never have headed to Unix :) Vielen Dank Herren. shell and desktop replacement for the Atari that was fairly successful shareware for a while ... now how was it called? The CLI was Mupfel (German for shell is Muschel, and there was a kid's TV character who pronounced Muschel as Mupfel), and I think the desktop was Gemini. Another I still have Gemini on a Disk for my STe. The SCSI adaptor died, so I don't know if the data is still good though. Then I tried the Minix port MinT (Mint is not TOS :) and was hooked on Unix. If I could get my SCSI adaptor fixed/replaced I'd still have my STe running, maybe even get a memory card (for 4Meg) and a CPU upgrade (68000 is slow, get 68030 or 40 like the Falcon) Then I could run Linux on it (it need that math co-proc) -Thomas - 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.4-ac14
David Weinehall wrote: > > We don't provide the binutils or gcc with the kernel either. The 6502 > > is a rather well known processor. Try plonking "6502 assembler" in > > google and you'll have a lot of choice. > > Me likee, finally asm in the kernel I can grok. Someone else who has trouble with x86 asm, but rembers 6502 almost as well as their native language:) Of course the M68K and RISC code isn't too bad, but 6502 is still where I'm most comfortable. -Thomas - 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] include/linux/coda.h
Ryan Cumming wrote: > When compiling the kernel under FreeBSD, __KERNEL__ is defined, but > __linux__ is not. I think this is an error on the part of the header file, > because on non-Linux build environments, which would otherwise compile the > Linux kernel correctly, do not have __linux__ defined. > > However, not many people will probably find much use in compiling the > kernel on other platforms, so if you think this isn't worth inclusion, I hmmm... building for: SPARC under Solaris PPC under BeOS PA-RISC under HP-UX M68k under HP-UX I'd really like the last one. I have a HP, M68k box I'd like to run linux on and I've not seen a M68K distro yet. But I haven't had time to try it yet either. -Thomas - 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] include/linux/coda.h
Ryan Cumming wrote: When compiling the kernel under FreeBSD, __KERNEL__ is defined, but __linux__ is not. I think this is an error on the part of the header file, because on non-Linux build environments, which would otherwise compile the Linux kernel correctly, do not have __linux__ defined. However, not many people will probably find much use in compiling the kernel on other platforms, so if you think this isn't worth inclusion, I hmmm... building for: SPARC under Solaris PPC under BeOS PA-RISC under HP-UX M68k under HP-UX I'd really like the last one. I have a HP, M68k box I'd like to run linux on and I've not seen a M68K distro yet. But I haven't had time to try it yet either. -Thomas - 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.4-ac14
David Weinehall wrote: We don't provide the binutils or gcc with the kernel either. The 6502 is a rather well known processor. Try plonking 6502 assembler in google and you'll have a lot of choice. Me likee, finally asm in the kernel I can grok. Someone else who has trouble with x86 asm, but rembers 6502 almost as well as their native language:) Of course the M68K and RISC code isn't too bad, but 6502 is still where I'm most comfortable. -Thomas - 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 and 2GB swap partition limit
Rik van Riel wrote: > > On Fri, 27 Apr 2001, LA Walsh wrote: > > > An interesting option (though with less-than-stellar performance > > characteristics) would be a dynamically expanding swapfile. If you're > > going to be hit with swap penalties, it may be useful to not have to > > pre-reserve something you only hit once in a great while. > > This makes amazingly little sense since you'd still need to > pre-reserve the disk space the swapfile grows into. > > A dynamically growing swap file can only save you if you > reserve enough free space on your filesystem for the thing > to grow... I seams to work for M$, not that they are a good example. But in /proc/sys/vm or /proc/sys/swapfile having min_swap, max_swap, min_free_space and the filename to use. This could then be set by init scripts like sysctl. It never grows larger than max(swapfile.max_swap, free_space - min_free_space). so if you have free space on the filesystem it can be used, but if you don't have space the current behavior remains. Sure it would be slow, but that would only be a problem if you run out of swap space and need to allocate more. Any time this routine allocates a larger file than syapfile.min_swap or frees space you send a WARN message. Now the user will know why the performance dropped and can either add RAM, or increase swap with by partition, file, or increase swapfile.min_swap. Those with enough RAM/swap will never even know it's there. -Thomas - 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_misc on 2.4.3-ac14
[EMAIL PROTECTED] wrote: > > <[EMAIL PROTECTED]> wrote: > >is it going to become the default in future kernel releases? > It's been that way in the -ac kernels for a while now, but Linus hasn't put it > into his kernels yet. Perhaps he's waiting until work begins on 2.5, rather > than break an existing interface in 2.4. Anyway, it's entirely up to Linus, so > I'm just guessing here. :-) It's in the 2.4 kernels from RedHat (like the one shipped with SeaWolf) So if you update you distro you'll see it for a while. I thought the plan was to move this out of /proc and to say /etc where config info like this "belongs". Did this change? -Thomas - 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 and 2GB swap partition limit
Rik van Riel wrote: On Fri, 27 Apr 2001, LA Walsh wrote: An interesting option (though with less-than-stellar performance characteristics) would be a dynamically expanding swapfile. If you're going to be hit with swap penalties, it may be useful to not have to pre-reserve something you only hit once in a great while. This makes amazingly little sense since you'd still need to pre-reserve the disk space the swapfile grows into. A dynamically growing swap file can only save you if you reserve enough free space on your filesystem for the thing to grow... I seams to work for M$, not that they are a good example. But in /proc/sys/vm or /proc/sys/swapfile having min_swap, max_swap, min_free_space and the filename to use. This could then be set by init scripts like sysctl. It never grows larger than max(swapfile.max_swap, free_space - min_free_space). so if you have free space on the filesystem it can be used, but if you don't have space the current behavior remains. Sure it would be slow, but that would only be a problem if you run out of swap space and need to allocate more. Any time this routine allocates a larger file than syapfile.min_swap or frees space you send a WARN message. Now the user will know why the performance dropped and can either add RAM, or increase swap with by partition, file, or increase swapfile.min_swap. Those with enough RAM/swap will never even know it's there. -Thomas - 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: Current status of NTFS support
[EMAIL PROTECTED] wrote: > > partition. The upgrade, though, will involve wiping the hard drive, allocating > the whole drive to a single NTFS partition, and reinstalling Notes after > installing Windows 2000 . That means bye-bye FAT32 partition and hello NTFS. I > can't mount it read-only because I'll still have to update my Notes databases > from Linux. So how risky is this? Why? Just us FAT32 instead of NTFS.Also, Why the repartition? Just reformat the old FAT32 partition and install over that. > Also, I'll have to recreate my Linux partitions after the upgrade. Does anyone Oll you should need is a boot floppy to get back into linux and fix the MBR (rerun lilo?) after the Windows install. Don't try to write to and NTFS partition from linux. You probably don't want to mount the Win2k version of NTFS in linux either. At one point that could damage the filesystem too. -Thomas - 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: Current status of NTFS support
[EMAIL PROTECTED] wrote: partition. The upgrade, though, will involve wiping the hard drive, allocating the whole drive to a single NTFS partition, and reinstalling Notes after installing Windows 2000 . That means bye-bye FAT32 partition and hello NTFS. I can't mount it read-only because I'll still have to update my Notes databases from Linux. So how risky is this? Why? Just us FAT32 instead of NTFS.Also, Why the repartition? Just reformat the old FAT32 partition and install over that. Also, I'll have to recreate my Linux partitions after the upgrade. Does anyone Oll you should need is a boot floppy to get back into linux and fix the MBR (rerun lilo?) after the Windows install. Don't try to write to and NTFS partition from linux. You probably don't want to mount the Win2k version of NTFS in linux either. At one point that could damage the filesystem too. -Thomas - 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: Config printk buffer size
Alan Cox wrote:
>
> Looks ok to me but given the ability of the average kernel hacker to read
> help texts I;d rather it was a choice menu of say
OK, I guess I gave too much credit :)
This gives 4 options, 4K, 8K, 16K, and 32K.
4K is for the embedded guys, but they might want even less.
32K is enought for 9 RAID1 and RAID0 volumes.
64K seams like overkill too me. But if anyone wants/needs it,
I'll add it in. Same for smaller buffers.
Now to work on using a boot param, and reducing after
booting with dmesg. That'll take me a while I'm sure.
-Thomas
diff -u --new-file --recursive linux-2.4.3-ac2.orig/Documentation/Configure.help
linux-2.4.3-ac2/Documentation/Configure.help
--- linux-2.4.3-ac2.orig/Documentation/Configure.help Wed Apr 4 15:22:43 2001
+++ linux-2.4.3-ac2/Documentation/Configure.helpThu Apr 5 14:12:00 2001
@@ -15192,6 +15192,14 @@
keys are documented in Documentation/sysrq.txt. Don't say Y unless
you really know what this hack does.
+Printk buffer size
+CONFIG_PRINTK_BUF_LEN_4K
+ Printk buffer size in K bytes.
+ The 2.2.x kernels used a default of 8. The 2.4.x kernels
+ use a default of 16. Systems with many Software-RAID volumes
+ should increase since the md.o drivers have a lot of printk
+ output during boot.
+
ISDN subsystem
CONFIG_ISDN
ISDN ("Integrated Services Digital Networks", called RNIS in France)
diff -u --new-file --recursive linux-2.4.3-ac2.orig/arch/alpha/config.in
linux-2.4.3-ac2/arch/alpha/config.in
--- linux-2.4.3-ac2.orig/arch/alpha/config.in Wed Apr 4 15:22:44 2001
+++ linux-2.4.3-ac2/arch/alpha/config.inThu Apr 5 10:53:07 2001
@@ -361,7 +361,11 @@
fi
bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
-
bool 'Legacy kernel start address' CONFIG_ALPHA_LEGACY_START_ADDRESS
+choice 'Printk buffer size (in K bytes)' \
+ "4K CONFIG_PRINTK_BUF_LEN_4K \
+8K CONFIG_PRINTK_BUF_LEN_8K \
+16KCONFIG_PRINTK_BUF_LEN_16K \
+32KCONFIG_PRINTK_BUF_LEN_32K" 16K
endmenu
diff -u --new-file --recursive linux-2.4.3-ac2.orig/arch/alpha/defconfig
linux-2.4.3-ac2/arch/alpha/defconfig
--- linux-2.4.3-ac2.orig/arch/alpha/defconfig Wed Apr 4 15:12:44 2001
+++ linux-2.4.3-ac2/arch/alpha/defconfigThu Apr 5 10:58:14 2001
@@ -635,3 +635,7 @@
CONFIG_MATHEMU=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_ALPHA_LEGACY_START_ADDRESS=y
+# CONFIG_PRINTK_BUF_LEN_4K is not set
+# CONFIG_PRINTK_BUF_LEN_8K is not set
+CONFIG_PRINTK_BUF_LEN_16K=y
+# CONFIG_PRINTK_BUF_LEN_32K is not set
diff -u --new-file --recursive linux-2.4.3-ac2.orig/arch/arm/config.in
linux-2.4.3-ac2/arch/arm/config.in
--- linux-2.4.3-ac2.orig/arch/arm/config.in Wed Apr 4 15:22:44 2001
+++ linux-2.4.3-ac2/arch/arm/config.in Thu Apr 5 10:53:20 2001
@@ -414,6 +414,7 @@
bool 'Verbose user fault messages' CONFIG_DEBUG_USER
bool 'Include debugging information in kernel binary' CONFIG_DEBUG_INFO
bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+
if [ "$CONFIG_CPU_26" = "y" ]; then
bool 'Disable pgtable cache' CONFIG_NO_PGT_CACHE
fi
@@ -427,4 +428,10 @@
fi
fi
fi
+
+choice 'Printk buffer size (in K bytes)' \
+ "4K CONFIG_PRINTK_BUF_LEN_4K \
+8K CONFIG_PRINTK_BUF_LEN_8K \
+16KCONFIG_PRINTK_BUF_LEN_16K \
+32KCONFIG_PRINTK_BUF_LEN_32K" 16K
endmenu
diff -u --new-file --recursive linux-2.4.3-ac2.orig/arch/arm/def-configs/a5k
linux-2.4.3-ac2/arch/arm/def-configs/a5k
--- linux-2.4.3-ac2.orig/arch/arm/def-configs/a5k Mon Nov 27 19:07:59 2000
+++ linux-2.4.3-ac2/arch/arm/def-configs/a5kThu Apr 5 11:09:28 2001
@@ -534,3 +534,7 @@
CONFIG_MAGIC_SYSRQ=y
CONFIG_NO_PGT_CACHE=y
CONFIG_DEBUG_LL=y
+# CONFIG_PRINTK_BUF_LEN_4K is not set
+# CONFIG_PRINTK_BUF_LEN_8K is not set
+CONFIG_PRINTK_BUF_LEN_16K=y
+# CONFIG_PRINTK_BUF_LEN_32K is not set
diff -u --new-file --recursive linux-2.4.3-ac2.orig/arch/arm/def-configs/assabet
linux-2.4.3-ac2/arch/arm/def-configs/assabet
--- linux-2.4.3-ac2.orig/arch/arm/def-configs/assabet Mon Nov 27 19:07:59 2000
+++ linux-2.4.3-ac2/arch/arm/def-configs/assabetThu Apr 5 11:09:02 2001
@@ -567,3 +567,7 @@
# CONFIG_DEBUG_INFO is not set
# CONFIG_MAGIC_SYSRQ is not set
# CONFIG_DEBUG_LL is not set
+# CONFIG_PRINTK_BUF_LEN_4K is not set
+# CONFIG_PRINTK_BUF_LEN_8K is not set
+CONFIG_PRINTK_BUF_LEN_16K=y
+# CONFIG_PRINTK_BUF_LEN_32K is not set
diff -u --new-file --recursive linux-2.4.3-ac2.orig/arch/arm/def-configs/brutus
linux-2.4.3-ac2/arch/arm/def-configs/brutus
--- linux-2.4.3-ac2.orig/arch/arm/def-configs/brutusMon Nov 27 19:07:59 2000
+++ linux-2.4.3-ac2/arch/arm/def-configs/brutus Thu Apr 5 11:08:49 2001
@@ -294,3 +294,7 @@
CONFIG_DEBUG_INFO=y
# CONFIG_MAGIC_SYSRQ is not set
# CONFIG_DEBUG_LL is not set
+# CONFIG_PRINTK_BUF_LEN_4K is not set
+# CONFIG_PRINTK_BUF_LEN_8K is not set
+CONFIG_PRINTK_BUF_LEN_16K=y
Re: Contacts within AMD? AMD-756 USB host-controller blacklisted dueto
Alan Cox wrote:
>
> Since we expect to get errata docs very soon Im not that worried. As an
> implementation I'd rather a module option of 'ignore_blacklist' or similar
> so that it is runtime
This seamed to work here.
-Thomas
diff -u --new-file --recursive linux-2.4.3-ac2.orig/drivers/usb/usb-ohci.c
linux-2.4.3-ac2/drivers/usb/usb-ohci.c
--- linux-2.4.3-ac2.orig/drivers/usb/usb-ohci.c Wed Apr 4 15:23:15 2001
+++ linux-2.4.3-ac2/drivers/usb/usb-ohci.c Thu Apr 5 14:02:08 2001
@@ -92,6 +92,10 @@
static LIST_HEAD (ohci_hcd_list);
static spinlock_t usb_ed_lock = SPIN_LOCK_UNLOCKED;
+static int overrideBlacklist = 0;
+MODULE_PARM(overrideBlacklist, "i");
+MODULE_PARM_DESC(overrideBlacklist, " override blacklisted controlers");
+
/*-*
* URB support functions
*-*/
@@ -2333,12 +2337,13 @@
void *mem_base;
/* blacklisted hardware? */
- if (id->driver_data) {
- info ("%s (%s): %s", dev->slot_name,
+ if (overrideBlacklist != 1){
+ if (id->driver_data) {
+ info ("%s (%s): %s", dev->slot_name,
dev->name, (char *) id->driver_data);
return -ENODEV;
+ }
}
-
if (pci_enable_device(dev) < 0)
return -ENODEV;
Re: Config printk buffer size
Andrzej Krzysztofowicz wrote: > > IMO, it would be nice to add a test here whether the CONFIG_PRINTK_BUF_LEN > value is really set as a power of two, eg.: > > #if (LOG_BUF_LEN & LOG_BUF_MASK) > #error CONFIG_PRINTK_BUF_LEN must be a power of two > #endif I couldn't figure out how to do it in the config, forgot about preprocessing. But Alan wants a menu option instead. Anyone who uses the embedded systems want a different default? Let me know and I'll put it in the default config files. I'm sure a small hand held with fixed devices doesn't need even a 8K buffer. Just don't know which ones. -Thomas - 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: Config printk buffer size
Andrzej Krzysztofowicz wrote: IMO, it would be nice to add a test here whether the CONFIG_PRINTK_BUF_LEN value is really set as a power of two, eg.: #if (LOG_BUF_LEN LOG_BUF_MASK) #error CONFIG_PRINTK_BUF_LEN must be a power of two #endif I couldn't figure out how to do it in the config, forgot about preprocessing. But Alan wants a menu option instead. Anyone who uses the embedded systems want a different default? Let me know and I'll put it in the default config files. I'm sure a small hand held with fixed devices doesn't need even a 8K buffer. Just don't know which ones. -Thomas - 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: Contacts within AMD? AMD-756 USB host-controller blacklisted dueto
Alan Cox wrote:
Since we expect to get errata docs very soon Im not that worried. As an
implementation I'd rather a module option of 'ignore_blacklist' or similar
so that it is runtime
This seamed to work here.
-Thomas
diff -u --new-file --recursive linux-2.4.3-ac2.orig/drivers/usb/usb-ohci.c
linux-2.4.3-ac2/drivers/usb/usb-ohci.c
--- linux-2.4.3-ac2.orig/drivers/usb/usb-ohci.c Wed Apr 4 15:23:15 2001
+++ linux-2.4.3-ac2/drivers/usb/usb-ohci.c Thu Apr 5 14:02:08 2001
@@ -92,6 +92,10 @@
static LIST_HEAD (ohci_hcd_list);
static spinlock_t usb_ed_lock = SPIN_LOCK_UNLOCKED;
+static int overrideBlacklist = 0;
+MODULE_PARM(overrideBlacklist, "i");
+MODULE_PARM_DESC(overrideBlacklist, " override blacklisted controlers");
+
/*-*
* URB support functions
*-*/
@@ -2333,12 +2337,13 @@
void *mem_base;
/* blacklisted hardware? */
- if (id-driver_data) {
- info ("%s (%s): %s", dev-slot_name,
+ if (overrideBlacklist != 1){
+ if (id-driver_data) {
+ info ("%s (%s): %s", dev-slot_name,
dev-name, (char *) id-driver_data);
return -ENODEV;
+ }
}
-
if (pci_enable_device(dev) 0)
return -ENODEV;
Re: Config printk buffer size
Alan Cox wrote:
Looks ok to me but given the ability of the average kernel hacker to read
help texts I;d rather it was a choice menu of say
OK, I guess I gave too much credit :)
This gives 4 options, 4K, 8K, 16K, and 32K.
4K is for the embedded guys, but they might want even less.
32K is enought for 9 RAID1 and RAID0 volumes.
64K seams like overkill too me. But if anyone wants/needs it,
I'll add it in. Same for smaller buffers.
Now to work on using a boot param, and reducing after
booting with dmesg. That'll take me a while I'm sure.
-Thomas
diff -u --new-file --recursive linux-2.4.3-ac2.orig/Documentation/Configure.help
linux-2.4.3-ac2/Documentation/Configure.help
--- linux-2.4.3-ac2.orig/Documentation/Configure.help Wed Apr 4 15:22:43 2001
+++ linux-2.4.3-ac2/Documentation/Configure.helpThu Apr 5 14:12:00 2001
@@ -15192,6 +15192,14 @@
keys are documented in Documentation/sysrq.txt. Don't say Y unless
you really know what this hack does.
+Printk buffer size
+CONFIG_PRINTK_BUF_LEN_4K
+ Printk buffer size in K bytes.
+ The 2.2.x kernels used a default of 8. The 2.4.x kernels
+ use a default of 16. Systems with many Software-RAID volumes
+ should increase since the md.o drivers have a lot of printk
+ output during boot.
+
ISDN subsystem
CONFIG_ISDN
ISDN ("Integrated Services Digital Networks", called RNIS in France)
diff -u --new-file --recursive linux-2.4.3-ac2.orig/arch/alpha/config.in
linux-2.4.3-ac2/arch/alpha/config.in
--- linux-2.4.3-ac2.orig/arch/alpha/config.in Wed Apr 4 15:22:44 2001
+++ linux-2.4.3-ac2/arch/alpha/config.inThu Apr 5 10:53:07 2001
@@ -361,7 +361,11 @@
fi
bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
-
bool 'Legacy kernel start address' CONFIG_ALPHA_LEGACY_START_ADDRESS
+choice 'Printk buffer size (in K bytes)' \
+ "4K CONFIG_PRINTK_BUF_LEN_4K \
+8K CONFIG_PRINTK_BUF_LEN_8K \
+16KCONFIG_PRINTK_BUF_LEN_16K \
+32KCONFIG_PRINTK_BUF_LEN_32K" 16K
endmenu
diff -u --new-file --recursive linux-2.4.3-ac2.orig/arch/alpha/defconfig
linux-2.4.3-ac2/arch/alpha/defconfig
--- linux-2.4.3-ac2.orig/arch/alpha/defconfig Wed Apr 4 15:12:44 2001
+++ linux-2.4.3-ac2/arch/alpha/defconfigThu Apr 5 10:58:14 2001
@@ -635,3 +635,7 @@
CONFIG_MATHEMU=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_ALPHA_LEGACY_START_ADDRESS=y
+# CONFIG_PRINTK_BUF_LEN_4K is not set
+# CONFIG_PRINTK_BUF_LEN_8K is not set
+CONFIG_PRINTK_BUF_LEN_16K=y
+# CONFIG_PRINTK_BUF_LEN_32K is not set
diff -u --new-file --recursive linux-2.4.3-ac2.orig/arch/arm/config.in
linux-2.4.3-ac2/arch/arm/config.in
--- linux-2.4.3-ac2.orig/arch/arm/config.in Wed Apr 4 15:22:44 2001
+++ linux-2.4.3-ac2/arch/arm/config.in Thu Apr 5 10:53:20 2001
@@ -414,6 +414,7 @@
bool 'Verbose user fault messages' CONFIG_DEBUG_USER
bool 'Include debugging information in kernel binary' CONFIG_DEBUG_INFO
bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+
if [ "$CONFIG_CPU_26" = "y" ]; then
bool 'Disable pgtable cache' CONFIG_NO_PGT_CACHE
fi
@@ -427,4 +428,10 @@
fi
fi
fi
+
+choice 'Printk buffer size (in K bytes)' \
+ "4K CONFIG_PRINTK_BUF_LEN_4K \
+8K CONFIG_PRINTK_BUF_LEN_8K \
+16KCONFIG_PRINTK_BUF_LEN_16K \
+32KCONFIG_PRINTK_BUF_LEN_32K" 16K
endmenu
diff -u --new-file --recursive linux-2.4.3-ac2.orig/arch/arm/def-configs/a5k
linux-2.4.3-ac2/arch/arm/def-configs/a5k
--- linux-2.4.3-ac2.orig/arch/arm/def-configs/a5k Mon Nov 27 19:07:59 2000
+++ linux-2.4.3-ac2/arch/arm/def-configs/a5kThu Apr 5 11:09:28 2001
@@ -534,3 +534,7 @@
CONFIG_MAGIC_SYSRQ=y
CONFIG_NO_PGT_CACHE=y
CONFIG_DEBUG_LL=y
+# CONFIG_PRINTK_BUF_LEN_4K is not set
+# CONFIG_PRINTK_BUF_LEN_8K is not set
+CONFIG_PRINTK_BUF_LEN_16K=y
+# CONFIG_PRINTK_BUF_LEN_32K is not set
diff -u --new-file --recursive linux-2.4.3-ac2.orig/arch/arm/def-configs/assabet
linux-2.4.3-ac2/arch/arm/def-configs/assabet
--- linux-2.4.3-ac2.orig/arch/arm/def-configs/assabet Mon Nov 27 19:07:59 2000
+++ linux-2.4.3-ac2/arch/arm/def-configs/assabetThu Apr 5 11:09:02 2001
@@ -567,3 +567,7 @@
# CONFIG_DEBUG_INFO is not set
# CONFIG_MAGIC_SYSRQ is not set
# CONFIG_DEBUG_LL is not set
+# CONFIG_PRINTK_BUF_LEN_4K is not set
+# CONFIG_PRINTK_BUF_LEN_8K is not set
+CONFIG_PRINTK_BUF_LEN_16K=y
+# CONFIG_PRINTK_BUF_LEN_32K is not set
diff -u --new-file --recursive linux-2.4.3-ac2.orig/arch/arm/def-configs/brutus
linux-2.4.3-ac2/arch/arm/def-configs/brutus
--- linux-2.4.3-ac2.orig/arch/arm/def-configs/brutusMon Nov 27 19:07:59 2000
+++ linux-2.4.3-ac2/arch/arm/def-configs/brutus Thu Apr 5 11:08:49 2001
@@ -294,3 +294,7 @@
CONFIG_DEBUG_INFO=y
# CONFIG_MAGIC_SYSRQ is not set
# CONFIG_DEBUG_LL is not set
+# CONFIG_PRINTK_BUF_LEN_4K is not set
+# CONFIG_PRINTK_BUF_LEN_8K is not set
+CONFIG_PRINTK_BUF_LEN_16K=y
+#
Config printk buffer size
This should allow the printk buffer to be sized during config.
The default size is still 16K. It could use some checking to
insure power-of-2, but CML1 doesn't have a way to
do it that I see. All the architectures should be
covered, and all the default files also have it.
It gets added in the kernel hacking section.
Having 8 software raid volumes most of the kernel hardware
detection messages get lost. Having to edit kernel/printk.c
before/after every kernel change is a mess and easy to forget.
I'm gouing to work on a resizing buffer, that drops to 4K or
8K after dmesg is called with the right switch.
Patch against 2.4.3-ac2 since it has more arch supported.
The embedded systems like arm, might want to change
the default size to something smaller for their arch,
whiuch is easier with this patch.
-Thomas
diff -u --new-file --recursive linux-2.4.3-ac2.orig/Documentation/Configure.help
linux-2.4.3-ac2/Documentation/Configure.help
--- linux-2.4.3-ac2.orig/Documentation/Configure.help Wed Apr 4 15:22:43 2001
+++ linux-2.4.3-ac2/Documentation/Configure.helpWed Apr 4 16:06:09 2001
@@ -15191,7 +15191,13 @@
send a BREAK and then within 5 seconds a command keypress. The
keys are documented in Documentation/sysrq.txt. Don't say Y unless
you really know what this hack does.
-
+Printk buffer size
+CONFIG_PRINTK_BUF_LEN
+ Printk buffer size in K bytes. This should be a power of 2.
+ The 2.2.x kernels used a default of 8. The 2.4.x kernels
+ use a default of 16. Systems with many Software-RAID volumes
+ should increase since the md.o drivers have a lot of printk
+ output during boot.
ISDN subsystem
CONFIG_ISDN
ISDN ("Integrated Services Digital Networks", called RNIS in France)
diff -u --new-file --recursive linux-2.4.3-ac2.orig/arch/alpha/config.in
linux-2.4.3-ac2/arch/alpha/config.in
--- linux-2.4.3-ac2.orig/arch/alpha/config.in Wed Apr 4 15:22:44 2001
+++ linux-2.4.3-ac2/arch/alpha/config.inWed Apr 4 16:06:39 2001
@@ -361,6 +361,7 @@
fi
bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+int 'Printk buffer size (in K bytes)' CONFIG_PRINTK_BUF_LEN 16
bool 'Legacy kernel start address' CONFIG_ALPHA_LEGACY_START_ADDRESS
diff -u --new-file --recursive linux-2.4.3-ac2.orig/arch/alpha/defconfig
linux-2.4.3-ac2/arch/alpha/defconfig
--- linux-2.4.3-ac2.orig/arch/alpha/defconfig Wed Apr 4 15:12:44 2001
+++ linux-2.4.3-ac2/arch/alpha/defconfigWed Apr 4 15:36:53 2001
@@ -634,4 +634,5 @@
#
CONFIG_MATHEMU=y
CONFIG_MAGIC_SYSRQ=y
+CONFIG_PRINTK_BUF_LEN=16
CONFIG_ALPHA_LEGACY_START_ADDRESS=y
diff -u --new-file --recursive linux-2.4.3-ac2.orig/arch/arm/config.in
linux-2.4.3-ac2/arch/arm/config.in
--- linux-2.4.3-ac2.orig/arch/arm/config.in Wed Apr 4 15:22:44 2001
+++ linux-2.4.3-ac2/arch/arm/config.in Wed Apr 4 16:06:57 2001
@@ -414,6 +414,7 @@
bool 'Verbose user fault messages' CONFIG_DEBUG_USER
bool 'Include debugging information in kernel binary' CONFIG_DEBUG_INFO
bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+int 'Printk buffer size (in K bytes)' CONFIG_PRINTK_BUF_LEN 16
if [ "$CONFIG_CPU_26" = "y" ]; then
bool 'Disable pgtable cache' CONFIG_NO_PGT_CACHE
fi
diff -u --new-file --recursive linux-2.4.3-ac2.orig/arch/arm/def-configs/a5k
linux-2.4.3-ac2/arch/arm/def-configs/a5k
--- linux-2.4.3-ac2.orig/arch/arm/def-configs/a5k Mon Nov 27 19:07:59 2000
+++ linux-2.4.3-ac2/arch/arm/def-configs/a5kWed Apr 4 15:40:00 2001
@@ -532,5 +532,6 @@
CONFIG_DEBUG_USER=y
# CONFIG_DEBUG_INFO is not set
CONFIG_MAGIC_SYSRQ=y
+CONFIG_PRINTK_BUF_LEN=16
CONFIG_NO_PGT_CACHE=y
CONFIG_DEBUG_LL=y
diff -u --new-file --recursive linux-2.4.3-ac2.orig/arch/arm/def-configs/assabet
linux-2.4.3-ac2/arch/arm/def-configs/assabet
--- linux-2.4.3-ac2.orig/arch/arm/def-configs/assabet Mon Nov 27 19:07:59 2000
+++ linux-2.4.3-ac2/arch/arm/def-configs/assabetWed Apr 4 15:40:15 2001
@@ -566,4 +566,5 @@
CONFIG_DEBUG_USER=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_MAGIC_SYSRQ is not set
+CONFIG_PRINTK_BUF_LEN=16
# CONFIG_DEBUG_LL is not set
diff -u --new-file --recursive linux-2.4.3-ac2.orig/arch/arm/def-configs/brutus
linux-2.4.3-ac2/arch/arm/def-configs/brutus
--- linux-2.4.3-ac2.orig/arch/arm/def-configs/brutusMon Nov 27 19:07:59 2000
+++ linux-2.4.3-ac2/arch/arm/def-configs/brutus Wed Apr 4 15:40:25 2001
@@ -293,4 +293,5 @@
CONFIG_DEBUG_USER=y
CONFIG_DEBUG_INFO=y
# CONFIG_MAGIC_SYSRQ is not set
+CONFIG_PRINTK_BUF_LEN=16
# CONFIG_DEBUG_LL is not set
diff -u --new-file --recursive linux-2.4.3-ac2.orig/arch/arm/def-configs/cerf
linux-2.4.3-ac2/arch/arm/def-configs/cerf
--- linux-2.4.3-ac2.orig/arch/arm/def-configs/cerf Mon Nov 27 19:07:59 2000
+++ linux-2.4.3-ac2/arch/arm/def-configs/cerf Wed Apr 4 15:40:35 2001
@@ -431,4 +431,5 @@
CONFIG_DEBUG_USER=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_MAGIC_SYSRQ is not set
+CONFIG_PRINTK_BUF_LEN=16
# CONFIG_DEBUG_LL is not set
diff -u --new-file --recursive
Re: Contacts within AMD? AMD-756 USB host-controller blacklisted dueto
David Brownell wrote:
> > please correct me if i'm wrong i only don't want to blacklist complete
> > chipset-series
>
> Then feel free to develop and submit a better fix. That'd
> be more practical if AMD's workaround were public. As I
> understand it, the bulk of the production chips have this
> erratum. More power to RedHat getting info from AMD.
> Meanwhile, this patch improves robustness.
Comprimise?
This patch make it a config option to enable the AMD-756.
It's marked DANGEROUS and EXPERIMENTAL, and is only
available if CONFIG_EXPERIMENTAL is set.
This makes the default to blacklist the AMD-756
but it can be used if one wants to try.
-Thomas
diff -u --new-file --recursive linux-2.4.3-ac2.orig/drivers/usb/Config.in
linux-2.4.3-ac2/drivers/usb/Config.in
--- linux-2.4.3-ac2.orig/drivers/usb/Config.in Wed Apr 4 15:23:13 2001
+++ linux-2.4.3-ac2/drivers/usb/Config.in Wed Apr 4 16:13:52 2001
@@ -24,6 +24,9 @@
dep_tristate ' UHCI Alternate Driver (JE) support' CONFIG_USB_UHCI_ALT
$CONFIG_USB
fi
dep_tristate ' OHCI (Compaq, iMacs, OPTi, SiS, ALi, ...) support' CONFIG_USB_OHCI
$CONFIG_USB
+ if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
+ bool ' AMD-756 OHCI support (DANGEROUS)(EXPERIMENTAL)' CONFIG_AMD_OHCI_OK
+ fi
comment 'USB Device Class drivers'
dep_tristate ' USB Audio support' CONFIG_USB_AUDIO $CONFIG_USB $CONFIG_SOUND
diff -u --new-file --recursive linux-2.4.3-ac2.orig/drivers/usb/usb-ohci.c
linux-2.4.3-ac2/drivers/usb/usb-ohci.c
--- linux-2.4.3-ac2.orig/drivers/usb/usb-ohci.c Wed Apr 4 15:23:15 2001
+++ linux-2.4.3-ac2/drivers/usb/usb-ohci.c Wed Apr 4 16:18:01 2001
@@ -2332,13 +2332,14 @@
unsigned long mem_resource, mem_len;
void *mem_base;
+#ifndef CONFIG_AMD_OHCI_OK
/* blacklisted hardware? */
if (id->driver_data) {
info ("%s (%s): %s", dev->slot_name,
dev->name, (char *) id->driver_data);
return -ENODEV;
}
-
+#endif
if (pci_enable_device(dev) < 0)
return -ENODEV;
@@ -2508,6 +2509,7 @@
* AMD-756 [Viper] USB has a serious erratum when used with
* lowspeed devices like mice; oopses have been seen. The
* vendor workaround needs an NDA ... for now, blacklist it.
+* Use CONFIG_AMD_OHCI_OK to try anyway.
*/
vendor: 0x1022,
device: 0x740c,
Re: Contacts within AMD? AMD-756 USB host-controller blacklisted due to
Alan Cox wrote: > > > David Brownell recently added this check to the usb-ohci driver > > since noone has gotten information from AMD for the workaround, > > which is rumored to exist, for this bug. > > > > Do any of you have contacts within AMD who might be able to > > get an explanation of the workaround to David Brownell? > > We are working on that currently via the Red Hat contact. > > > value given varies. Rereading NDP seems to give a valid value. > > I am not really clear why we don't simply read the value twice > > whenever the host-controller is detected to be an AMD-756. > > because we dont know the full scope of the problem yet. Exactly how many bug reports has this caused? What kind of problems? I know I had trouble onece, but it was a CONFIG problem with the 2.4.2ac series and the extra DEBUG options. -Thomas - 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: Contacts within AMD? AMD-756 USB host-controller blacklisted due to
Alan Cox wrote: David Brownell recently added this check to the usb-ohci driver since noone has gotten information from AMD for the workaround, which is rumored to exist, for this bug. Do any of you have contacts within AMD who might be able to get an explanation of the workaround to David Brownell? We are working on that currently via the Red Hat contact. value given varies. Rereading NDP seems to give a valid value. I am not really clear why we don't simply read the value twice whenever the host-controller is detected to be an AMD-756. because we dont know the full scope of the problem yet. Exactly how many bug reports has this caused? What kind of problems? I know I had trouble onece, but it was a CONFIG problem with the 2.4.2ac series and the extra DEBUG options. -Thomas - 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: Contacts within AMD? AMD-756 USB host-controller blacklisted dueto
David Brownell wrote:
please correct me if i'm wrong i only don't want to blacklist complete
chipset-series
Then feel free to develop and submit a better fix. That'd
be more practical if AMD's workaround were public. As I
understand it, the bulk of the production chips have this
erratum. More power to RedHat getting info from AMD.
Meanwhile, this patch improves robustness.
Comprimise?
This patch make it a config option to enable the AMD-756.
It's marked DANGEROUS and EXPERIMENTAL, and is only
available if CONFIG_EXPERIMENTAL is set.
This makes the default to blacklist the AMD-756
but it can be used if one wants to try.
-Thomas
diff -u --new-file --recursive linux-2.4.3-ac2.orig/drivers/usb/Config.in
linux-2.4.3-ac2/drivers/usb/Config.in
--- linux-2.4.3-ac2.orig/drivers/usb/Config.in Wed Apr 4 15:23:13 2001
+++ linux-2.4.3-ac2/drivers/usb/Config.in Wed Apr 4 16:13:52 2001
@@ -24,6 +24,9 @@
dep_tristate ' UHCI Alternate Driver (JE) support' CONFIG_USB_UHCI_ALT
$CONFIG_USB
fi
dep_tristate ' OHCI (Compaq, iMacs, OPTi, SiS, ALi, ...) support' CONFIG_USB_OHCI
$CONFIG_USB
+ if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
+ bool ' AMD-756 OHCI support (DANGEROUS)(EXPERIMENTAL)' CONFIG_AMD_OHCI_OK
+ fi
comment 'USB Device Class drivers'
dep_tristate ' USB Audio support' CONFIG_USB_AUDIO $CONFIG_USB $CONFIG_SOUND
diff -u --new-file --recursive linux-2.4.3-ac2.orig/drivers/usb/usb-ohci.c
linux-2.4.3-ac2/drivers/usb/usb-ohci.c
--- linux-2.4.3-ac2.orig/drivers/usb/usb-ohci.c Wed Apr 4 15:23:15 2001
+++ linux-2.4.3-ac2/drivers/usb/usb-ohci.c Wed Apr 4 16:18:01 2001
@@ -2332,13 +2332,14 @@
unsigned long mem_resource, mem_len;
void *mem_base;
+#ifndef CONFIG_AMD_OHCI_OK
/* blacklisted hardware? */
if (id-driver_data) {
info ("%s (%s): %s", dev-slot_name,
dev-name, (char *) id-driver_data);
return -ENODEV;
}
-
+#endif
if (pci_enable_device(dev) 0)
return -ENODEV;
@@ -2508,6 +2509,7 @@
* AMD-756 [Viper] USB has a serious erratum when used with
* lowspeed devices like mice; oopses have been seen. The
* vendor workaround needs an NDA ... for now, blacklist it.
+* Use CONFIG_AMD_OHCI_OK to try anyway.
*/
vendor: 0x1022,
device: 0x740c,
Config printk buffer size
This should allow the printk buffer to be sized during config.
The default size is still 16K. It could use some checking to
insure power-of-2, but CML1 doesn't have a way to
do it that I see. All the architectures should be
covered, and all the default files also have it.
It gets added in the kernel hacking section.
Having 8 software raid volumes most of the kernel hardware
detection messages get lost. Having to edit kernel/printk.c
before/after every kernel change is a mess and easy to forget.
I'm gouing to work on a resizing buffer, that drops to 4K or
8K after dmesg is called with the right switch.
Patch against 2.4.3-ac2 since it has more arch supported.
The embedded systems like arm, might want to change
the default size to something smaller for their arch,
whiuch is easier with this patch.
-Thomas
diff -u --new-file --recursive linux-2.4.3-ac2.orig/Documentation/Configure.help
linux-2.4.3-ac2/Documentation/Configure.help
--- linux-2.4.3-ac2.orig/Documentation/Configure.help Wed Apr 4 15:22:43 2001
+++ linux-2.4.3-ac2/Documentation/Configure.helpWed Apr 4 16:06:09 2001
@@ -15191,7 +15191,13 @@
send a BREAK and then within 5 seconds a command keypress. The
keys are documented in Documentation/sysrq.txt. Don't say Y unless
you really know what this hack does.
-
+Printk buffer size
+CONFIG_PRINTK_BUF_LEN
+ Printk buffer size in K bytes. This should be a power of 2.
+ The 2.2.x kernels used a default of 8. The 2.4.x kernels
+ use a default of 16. Systems with many Software-RAID volumes
+ should increase since the md.o drivers have a lot of printk
+ output during boot.
ISDN subsystem
CONFIG_ISDN
ISDN ("Integrated Services Digital Networks", called RNIS in France)
diff -u --new-file --recursive linux-2.4.3-ac2.orig/arch/alpha/config.in
linux-2.4.3-ac2/arch/alpha/config.in
--- linux-2.4.3-ac2.orig/arch/alpha/config.in Wed Apr 4 15:22:44 2001
+++ linux-2.4.3-ac2/arch/alpha/config.inWed Apr 4 16:06:39 2001
@@ -361,6 +361,7 @@
fi
bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+int 'Printk buffer size (in K bytes)' CONFIG_PRINTK_BUF_LEN 16
bool 'Legacy kernel start address' CONFIG_ALPHA_LEGACY_START_ADDRESS
diff -u --new-file --recursive linux-2.4.3-ac2.orig/arch/alpha/defconfig
linux-2.4.3-ac2/arch/alpha/defconfig
--- linux-2.4.3-ac2.orig/arch/alpha/defconfig Wed Apr 4 15:12:44 2001
+++ linux-2.4.3-ac2/arch/alpha/defconfigWed Apr 4 15:36:53 2001
@@ -634,4 +634,5 @@
#
CONFIG_MATHEMU=y
CONFIG_MAGIC_SYSRQ=y
+CONFIG_PRINTK_BUF_LEN=16
CONFIG_ALPHA_LEGACY_START_ADDRESS=y
diff -u --new-file --recursive linux-2.4.3-ac2.orig/arch/arm/config.in
linux-2.4.3-ac2/arch/arm/config.in
--- linux-2.4.3-ac2.orig/arch/arm/config.in Wed Apr 4 15:22:44 2001
+++ linux-2.4.3-ac2/arch/arm/config.in Wed Apr 4 16:06:57 2001
@@ -414,6 +414,7 @@
bool 'Verbose user fault messages' CONFIG_DEBUG_USER
bool 'Include debugging information in kernel binary' CONFIG_DEBUG_INFO
bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+int 'Printk buffer size (in K bytes)' CONFIG_PRINTK_BUF_LEN 16
if [ "$CONFIG_CPU_26" = "y" ]; then
bool 'Disable pgtable cache' CONFIG_NO_PGT_CACHE
fi
diff -u --new-file --recursive linux-2.4.3-ac2.orig/arch/arm/def-configs/a5k
linux-2.4.3-ac2/arch/arm/def-configs/a5k
--- linux-2.4.3-ac2.orig/arch/arm/def-configs/a5k Mon Nov 27 19:07:59 2000
+++ linux-2.4.3-ac2/arch/arm/def-configs/a5kWed Apr 4 15:40:00 2001
@@ -532,5 +532,6 @@
CONFIG_DEBUG_USER=y
# CONFIG_DEBUG_INFO is not set
CONFIG_MAGIC_SYSRQ=y
+CONFIG_PRINTK_BUF_LEN=16
CONFIG_NO_PGT_CACHE=y
CONFIG_DEBUG_LL=y
diff -u --new-file --recursive linux-2.4.3-ac2.orig/arch/arm/def-configs/assabet
linux-2.4.3-ac2/arch/arm/def-configs/assabet
--- linux-2.4.3-ac2.orig/arch/arm/def-configs/assabet Mon Nov 27 19:07:59 2000
+++ linux-2.4.3-ac2/arch/arm/def-configs/assabetWed Apr 4 15:40:15 2001
@@ -566,4 +566,5 @@
CONFIG_DEBUG_USER=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_MAGIC_SYSRQ is not set
+CONFIG_PRINTK_BUF_LEN=16
# CONFIG_DEBUG_LL is not set
diff -u --new-file --recursive linux-2.4.3-ac2.orig/arch/arm/def-configs/brutus
linux-2.4.3-ac2/arch/arm/def-configs/brutus
--- linux-2.4.3-ac2.orig/arch/arm/def-configs/brutusMon Nov 27 19:07:59 2000
+++ linux-2.4.3-ac2/arch/arm/def-configs/brutus Wed Apr 4 15:40:25 2001
@@ -293,4 +293,5 @@
CONFIG_DEBUG_USER=y
CONFIG_DEBUG_INFO=y
# CONFIG_MAGIC_SYSRQ is not set
+CONFIG_PRINTK_BUF_LEN=16
# CONFIG_DEBUG_LL is not set
diff -u --new-file --recursive linux-2.4.3-ac2.orig/arch/arm/def-configs/cerf
linux-2.4.3-ac2/arch/arm/def-configs/cerf
--- linux-2.4.3-ac2.orig/arch/arm/def-configs/cerf Mon Nov 27 19:07:59 2000
+++ linux-2.4.3-ac2/arch/arm/def-configs/cerf Wed Apr 4 15:40:35 2001
@@ -431,4 +431,5 @@
CONFIG_DEBUG_USER=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_MAGIC_SYSRQ is not set
+CONFIG_PRINTK_BUF_LEN=16
# CONFIG_DEBUG_LL is not set
diff -u --new-file --recursive
Re: USB oops Linux 2.4.2ac6
Peter Zaitcev wrote: > > > > 2.4.2-ac6 > > > o USB hub kmalloc wrong size corruption fix (Peter Zaitcev) > > > The first line of the oops is > > > > > > kernel BUG at slab.c:1398! > > > > Any other ideas to try? > > -Thomas > > I did not break it, honest! I will be looking in a USB mouse > problem though. If you need an immediate resolution, nice > folks at [EMAIL PROTECTED] may be able to help. > Or may be not :) I found the problem. CONFIG_DEBUG_SLAB "Debug memory allocation" in the 2.4.2-ac series doesn't work with USB. 2.4.2-ac5 just booted and found the mouse correctly. On to ac-21 now... Did David Brownell's patch to disable OHCI loading on the AMD-756 make it into the source trees? -Thomas - 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: USB oops Linux 2.4.2ac6
Peter Zaitcev wrote: 2.4.2-ac6 o USB hub kmalloc wrong size corruption fix (Peter Zaitcev) The first line of the oops is kernel BUG at slab.c:1398! Any other ideas to try? -Thomas I did not break it, honest! I will be looking in a USB mouse problem though. If you need an immediate resolution, nice folks at [EMAIL PROTECTED] may be able to help. Or may be not :) I found the problem. CONFIG_DEBUG_SLAB "Debug memory allocation" in the 2.4.2-ac series doesn't work with USB. 2.4.2-ac5 just booted and found the mouse correctly. On to ac-21 now... Did David Brownell's patch to disable OHCI loading on the AMD-756 make it into the source trees? -Thomas - 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: How to mount /proc/sys/fs/binfmt_misc ?
[EMAIL PROTECTED] wrote: > > > which makes sense, I guess, because proc isn't a "real" filesystem. So how do I > get binfmt_misc mounted? mount it somewhere else, say, /dev/binfmt_mount instead of in /proc until the proc entry is fixed. What should creat /proc/sys/fs/binfmt_misc ? -Thomas - 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: How to mount /proc/sys/fs/binfmt_misc ?
[EMAIL PROTECTED] wrote: which makes sense, I guess, because proc isn't a "real" filesystem. So how do I get binfmt_misc mounted? mount it somewhere else, say, /dev/binfmt_mount instead of in /proc until the proc entry is fixed. What should creat /proc/sys/fs/binfmt_misc ? -Thomas - 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: State of RAID (and the infamous FastTrak100 card)
Wilfried Weissmann wrote: > > Jakob Østergaard wrote: > > > So... am I just begging for pain if I try to install, say, a stock RH7 > > > on a machine with the FastTrak100 doing it's little RAID0/JBOD thing? > > > If it requires this machine to always boot from a floppy because the driver > > > cannot be linked into the kernel, well, I'm okay with that. > > > > I don't know about the state of the FastTrak100 IDE drivers - but if you can > > get that running, putting software RAID on top of that should be a simple > > matter. > > I do not think that would work. These IDE RAID use a slightly different layout that >someone would > expect. This means that you cannot map it 1:1 to any RAID personality, therefore you >cannot boot > from it. > > (Free)BSD supports this IDE RAID controller with the RAID functionality. Maybe you >want to check it > out. Jakob ment the kernel software-RAID, md.0, raid0.o, raid1.o, raid5.o, and linear.o Not the Promise RAID software. -Thomas - 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: State of RAID (and the infamous FastTrak100 card)
Wilfried Weissmann wrote: Jakob stergaard wrote: So... am I just begging for pain if I try to install, say, a stock RH7 on a machine with the FastTrak100 doing it's little RAID0/JBOD thing? If it requires this machine to always boot from a floppy because the driver cannot be linked into the kernel, well, I'm okay with that. I don't know about the state of the FastTrak100 IDE drivers - but if you can get that running, putting software RAID on top of that should be a simple matter. I do not think that would work. These IDE RAID use a slightly different layout that someone would expect. This means that you cannot map it 1:1 to any RAID personality, therefore you cannot boot from it. (Free)BSD supports this IDE RAID controller with the RAID functionality. Maybe you want to check it out. Jakob ment the kernel software-RAID, md.0, raid0.o, raid1.o, raid5.o, and linear.o Not the Promise RAID software. -Thomas - 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: new generic content schemes popping up everywhere...
Andre Hedrick wrote: > >From siliconvalley.com's GMSV column today: >self-destruct if it's tampered with. The utility is enabled >with 11 layers of security defenses, all of which must be >successfully navigated to disable the system. These layers >range from a series of forced reboots designed to thwart >automated hacking tools to something called "the white screen >of death" which destroys the software and all files stored >inside it. Infraworks CEO George Friedman says the >application's system-level control is possible largely because >it is firmly anchored into users' C drives during >installation. "We're fairly deep in the operating system," Not much help if you put the disk in another box without their system installed (or mount in linux/BSD/MacOS) to break the encryption/controls. Once that's done, A floppy based OS and tool could break open the files on a disk, when their apps aren't running. If it can be decrypted "legally" it can be done "illegally" too. -Thomas - 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: new generic content schemes popping up everywhere...
Andre Hedrick wrote: From siliconvalley.com's GMSV column today: self-destruct if it's tampered with. The utility is enabled with 11 layers of security defenses, all of which must be successfully navigated to disable the system. These layers range from a series of forced reboots designed to thwart automated hacking tools to something called "the white screen of death" which destroys the software and all files stored inside it. Infraworks CEO George Friedman says the application's system-level control is possible largely because it is firmly anchored into users' C drives during installation. "We're fairly deep in the operating system," Not much help if you put the disk in another box without their system installed (or mount in linux/BSD/MacOS) to break the encryption/controls. Once that's done, A floppy based OS and tool could break open the files on a disk, when their apps aren't running. If it can be decrypted "legally" it can be done "illegally" too. -Thomas - 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 on a AMD7409 controller with kernel 2.4.2
> On Thu, 1 Mar 2001, Hylke van der Schaaf wrote: > > > With kernet 2.2.18 DMA mode for my harddisks worked just fine, > > getting IDE DMA working on an AMD7409 controller with kernel 2.4.2 is a problem. > > > > questions: > > Why is DMA disabled on revision < C4? > > How can I gat DMA working again? > > in 2.2.18 I get: > > hylke:/home/hylke# hdparm -tT /dev/hda > > > > /dev/hda: > > Timing buffer-cache reads: 128 MB in 0.89 seconds =143.82 MB/sec > > Timing buffered disk reads: 64 MB in 2.85 seconds = 22.46 MB/sec > > > > > > All was fine. > > I compiled 2.4.2, with: > > CONFIG_AMD7409_OVERRIDE=y I'm not using this, since my drives are not UDMA66 or UDMA100 > > hylke:/home/hylke# hdparm -v /dev/hda > > > > /dev/hda: > > multcount= 16 (on) > > I/O support = 1 (32-bit) > > unmaskirq= 1 (on) > > using_dma= 0 (off) > > keepsettings = 0 (off) > > nowerr = 0 (off) > > readonly = 0 (off) > > readahead= 8 (on) > > geometry = 2495/255/63, sectors = 40088160, start = 0 > > hylke:/home/hylke# hdparm -tT /dev/hda > > > > /dev/hda: > > Timing buffer-cache reads: 128 MB in 0.90 seconds =142.22 MB/sec > > Timing buffered disk reads: 64 MB in 12.59 seconds = 5.08 MB/sec I get 148.8 and 12 MB/sec on my IBM-DTTA-351010 drives. I get the same message about no single word DMA due to chip revision. # hdparm -v /dev/hda /dev/hda: multcount= 16 (on) I/O support = 3 (32-bit w/sync) unmaskirq= 0 (off) using_dma= 1 (on) keepsettings = 0 (off) nowerr = 0 (off) readonly = 0 (off) readahead= 8 (on) geometry = 19650/16/63, sectors = 19807200, start = 0 What does /proc/ide/hda/settings show? What about /proc/ide/amd74xx ? -Thomas - 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 on a AMD7409 controller with kernel 2.4.2
On Thu, 1 Mar 2001, Hylke van der Schaaf wrote: With kernet 2.2.18 DMA mode for my harddisks worked just fine, getting IDE DMA working on an AMD7409 controller with kernel 2.4.2 is a problem. questions: Why is DMA disabled on revision C4? How can I gat DMA working again? in 2.2.18 I get: hylke:/home/hylke# hdparm -tT /dev/hda /dev/hda: Timing buffer-cache reads: 128 MB in 0.89 seconds =143.82 MB/sec Timing buffered disk reads: 64 MB in 2.85 seconds = 22.46 MB/sec All was fine. I compiled 2.4.2, with: CONFIG_AMD7409_OVERRIDE=y I'm not using this, since my drives are not UDMA66 or UDMA100 hylke:/home/hylke# hdparm -v /dev/hda /dev/hda: multcount= 16 (on) I/O support = 1 (32-bit) unmaskirq= 1 (on) using_dma= 0 (off) keepsettings = 0 (off) nowerr = 0 (off) readonly = 0 (off) readahead= 8 (on) geometry = 2495/255/63, sectors = 40088160, start = 0 hylke:/home/hylke# hdparm -tT /dev/hda /dev/hda: Timing buffer-cache reads: 128 MB in 0.90 seconds =142.22 MB/sec Timing buffered disk reads: 64 MB in 12.59 seconds = 5.08 MB/sec I get 148.8 and 12 MB/sec on my IBM-DTTA-351010 drives. I get the same message about no single word DMA due to chip revision. # hdparm -v /dev/hda /dev/hda: multcount= 16 (on) I/O support = 3 (32-bit w/sync) unmaskirq= 0 (off) using_dma= 1 (on) keepsettings = 0 (off) nowerr = 0 (off) readonly = 0 (off) readahead= 8 (on) geometry = 19650/16/63, sectors = 19807200, start = 0 What does /proc/ide/hda/settings show? What about /proc/ide/amd74xx ? -Thomas - 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/
USB oops Linux 2.4.2ac6
2.4.2-ac3 was fine. These are the only USB changes I see since then. > 2.4.2-ac6 > o USB hub kmalloc wrong size corruption fix (Peter Zaitcev) > > 2.4.2-ac5 > o Fix busy loop in usb storage(Arjan van de Ven) > o Fix USB thread wakeup scheduling(Arjan van de Ven) Tbird-700 on MSI-6167 (Viper based) board. from dmesg - usb.c: registered new driver usbdevfs usb.c: registered new driver hub usb-ohci.c: USB OHCI at membase 0xd3874000, IRQ 11 usb-ohci.c: usb-00:07.4, Advanced Micro Devices [AMD] AMD-756 [Viper] USB usb.c: new USB bus registered, assigned bus number 1 usb.c: kmalloc IF c14aabc0, numif 1 usb.c: new device strings: Mfr=0, Product=2, SerialNumber=1 usb.c: USB device number 1 default language ID 0x0 Product: USB OHCI Root Hub SerialNumber: d3874000 hub.c: USB hub found hub.c: 4 ports detected hub.c: standalone hub hub.c: ganged power switching hub.c: global over-current protection hub.c: TT requires at most 8 FS bit times hub.c: Port indicators are not supported hub.c: power on to power good time: 0ms hub.c: hub controller current requirement: 255mA hub.c: port removable status: hub.c: local power source is good hub.c: no over-current condition exists hub.c: enabling power on all ports usb.c: hub driver claimed interface c14aabc0 usb.c: kusbd: /sbin/hotplug add 1 -- If I boot with my mouse plugged in, or plug it in after the system is up, I get an oops. While I was buildong the kernel I got a message from the kernel Feb 28 10:03:07 tedpc kernel: usb-ohci.c: bogus NDP=242 for OHCI usb-00:07.4 Feb 28 10:03:07 tedpc kernel: usb-ohci.c: rereads as NDP=4 - Every thing continued OK, but I wasn't using the mouse. I rebooted with the new kernel and got an oops when the init scripts started looking for usb devices. In 2.4.2-ac3 booting with the mouse shows this in the old log - Feb 20 12:34:05 tedpc kernel: usb.c: registered new driver usbdevfs Feb 20 12:34:05 tedpc kernel: usb.c: registered new driver hub Feb 20 12:34:05 tedpc kernel: usb-ohci.c: USB OHCI at membase 0xd3874000, IRQ 11 Feb 20 12:34:05 tedpc kernel: usb-ohci.c: usb-00:07.4, Advanced Micro Devices [AMD] AMD-756 [Viper] USB Feb 20 12:34:05 tedpc kernel: usb.c: new USB bus registered, assigned bus number 1 Feb 20 12:34:05 tedpc kernel: Product: USB OHCI Root Hub Feb 20 12:34:05 tedpc kernel: SerialNumber: d3874000 Feb 20 12:34:05 tedpc kernel: hub.c: USB hub found Feb 20 12:34:05 tedpc kernel: hub.c: 4 ports detected Feb 20 12:34:05 tedpc kernel: hub.c: USB new device connect on bus1/2, assigned device number 2 Feb 20 12:34:05 tedpc kernel: usb.c: USB device 2 (vend/prod 0x4b4/0x1) is not claimed by any active driver. Feb 20 12:34:05 tedpc kernel: Length = 18 Feb 20 12:34:05 tedpc kernel: DescriptorType = 01 Feb 20 12:34:05 tedpc kernel: USB version = 1.00 Feb 20 12:34:05 tedpc kernel: Vendor:Product = 04b4:0001 Feb 20 12:34:05 tedpc kernel: MaxPacketSize0 = 8 Feb 20 12:34:05 tedpc kernel: NumConfigurations = 1 Feb 20 12:34:05 tedpc kernel: Device version = 0.00 Feb 20 12:34:05 tedpc kernel: Device Class:SubClass:Protocol = 00:00:00 Feb 20 12:34:05 tedpc kernel: Per-interface classes Feb 20 12:34:05 tedpc kernel: Configuration: Feb 20 12:34:05 tedpc kernel: bLength =9 Feb 20 12:34:05 tedpc kernel: bDescriptorType = 02 Feb 20 12:34:05 tedpc kernel: wTotalLength= 0022 Feb 20 12:34:05 tedpc kernel: bNumInterfaces = 01 Feb 20 12:34:05 tedpc kernel: bConfigurationValue = 01 Feb 20 12:34:05 tedpc kernel: iConfiguration = 00 Feb 20 12:34:06 tedpc kernel: bmAttributes= 80 Feb 20 12:34:06 tedpc kernel: MaxPower= 100mA Feb 20 12:34:06 tedpc kernel: Feb 20 12:34:06 tedpc kernel: Interface: 0 Feb 20 12:34:06 tedpc kernel: Alternate Setting: 0 Feb 20 12:34:06 tedpc kernel: bLength =9 Feb 20 12:34:06 tedpc kernel: bDescriptorType = 04 Feb 20 12:34:06 tedpc kernel: bInterfaceNumber= 00 Feb 20 12:34:06 tedpc kernel: bAlternateSetting = 00 Feb 20 12:34:06 tedpc kernel: bNumEndpoints = 01 Feb 20 12:34:06 tedpc kernel: bInterface Class:SubClass:Protocol = 03:01:02 Feb 20 12:34:06 tedpc kernel: iInterface = 00 Feb 20 12:34:06 tedpc kernel: Endpoint: Feb 20 12:34:06 tedpc kernel: bLength =7 Feb 20 12:34:06 tedpc kernel: bDescriptorType = 05 Feb 20 12:34:06 tedpc kernel: bEndpointAddress= 81 (in) Feb 20 12:34:06 tedpc kernel: bmAttributes= 03 (Interrupt) Feb 20 12:34:06 tedpc kernel: wMaxPacketSize = 0003 Feb 20 12:34:06 tedpc kernel: bInterval = 0a Feb 20 12:34:06 tedpc kernel: usb.c: registered new driver hid Feb 20 12:34:06 tedpc kernel: input0: USB HID v1.00 Mouse [04b4:0001] on usb1:2.0 Feb 20 12:34:06 tedpc kernel:
USB oops Linux 2.4.2ac6
2.4.2-ac3 was fine. These are the only USB changes I see since then. 2.4.2-ac6 o USB hub kmalloc wrong size corruption fix (Peter Zaitcev) 2.4.2-ac5 o Fix busy loop in usb storage(Arjan van de Ven) o Fix USB thread wakeup scheduling(Arjan van de Ven) Tbird-700 on MSI-6167 (Viper based) board. from dmesg - usb.c: registered new driver usbdevfs usb.c: registered new driver hub usb-ohci.c: USB OHCI at membase 0xd3874000, IRQ 11 usb-ohci.c: usb-00:07.4, Advanced Micro Devices [AMD] AMD-756 [Viper] USB usb.c: new USB bus registered, assigned bus number 1 usb.c: kmalloc IF c14aabc0, numif 1 usb.c: new device strings: Mfr=0, Product=2, SerialNumber=1 usb.c: USB device number 1 default language ID 0x0 Product: USB OHCI Root Hub SerialNumber: d3874000 hub.c: USB hub found hub.c: 4 ports detected hub.c: standalone hub hub.c: ganged power switching hub.c: global over-current protection hub.c: TT requires at most 8 FS bit times hub.c: Port indicators are not supported hub.c: power on to power good time: 0ms hub.c: hub controller current requirement: 255mA hub.c: port removable status: hub.c: local power source is good hub.c: no over-current condition exists hub.c: enabling power on all ports usb.c: hub driver claimed interface c14aabc0 usb.c: kusbd: /sbin/hotplug add 1 -- If I boot with my mouse plugged in, or plug it in after the system is up, I get an oops. While I was buildong the kernel I got a message from the kernel Feb 28 10:03:07 tedpc kernel: usb-ohci.c: bogus NDP=242 for OHCI usb-00:07.4 Feb 28 10:03:07 tedpc kernel: usb-ohci.c: rereads as NDP=4 - Every thing continued OK, but I wasn't using the mouse. I rebooted with the new kernel and got an oops when the init scripts started looking for usb devices. In 2.4.2-ac3 booting with the mouse shows this in the old log - Feb 20 12:34:05 tedpc kernel: usb.c: registered new driver usbdevfs Feb 20 12:34:05 tedpc kernel: usb.c: registered new driver hub Feb 20 12:34:05 tedpc kernel: usb-ohci.c: USB OHCI at membase 0xd3874000, IRQ 11 Feb 20 12:34:05 tedpc kernel: usb-ohci.c: usb-00:07.4, Advanced Micro Devices [AMD] AMD-756 [Viper] USB Feb 20 12:34:05 tedpc kernel: usb.c: new USB bus registered, assigned bus number 1 Feb 20 12:34:05 tedpc kernel: Product: USB OHCI Root Hub Feb 20 12:34:05 tedpc kernel: SerialNumber: d3874000 Feb 20 12:34:05 tedpc kernel: hub.c: USB hub found Feb 20 12:34:05 tedpc kernel: hub.c: 4 ports detected Feb 20 12:34:05 tedpc kernel: hub.c: USB new device connect on bus1/2, assigned device number 2 Feb 20 12:34:05 tedpc kernel: usb.c: USB device 2 (vend/prod 0x4b4/0x1) is not claimed by any active driver. Feb 20 12:34:05 tedpc kernel: Length = 18 Feb 20 12:34:05 tedpc kernel: DescriptorType = 01 Feb 20 12:34:05 tedpc kernel: USB version = 1.00 Feb 20 12:34:05 tedpc kernel: Vendor:Product = 04b4:0001 Feb 20 12:34:05 tedpc kernel: MaxPacketSize0 = 8 Feb 20 12:34:05 tedpc kernel: NumConfigurations = 1 Feb 20 12:34:05 tedpc kernel: Device version = 0.00 Feb 20 12:34:05 tedpc kernel: Device Class:SubClass:Protocol = 00:00:00 Feb 20 12:34:05 tedpc kernel: Per-interface classes Feb 20 12:34:05 tedpc kernel: Configuration: Feb 20 12:34:05 tedpc kernel: bLength =9 Feb 20 12:34:05 tedpc kernel: bDescriptorType = 02 Feb 20 12:34:05 tedpc kernel: wTotalLength= 0022 Feb 20 12:34:05 tedpc kernel: bNumInterfaces = 01 Feb 20 12:34:05 tedpc kernel: bConfigurationValue = 01 Feb 20 12:34:05 tedpc kernel: iConfiguration = 00 Feb 20 12:34:06 tedpc kernel: bmAttributes= 80 Feb 20 12:34:06 tedpc kernel: MaxPower= 100mA Feb 20 12:34:06 tedpc kernel: Feb 20 12:34:06 tedpc kernel: Interface: 0 Feb 20 12:34:06 tedpc kernel: Alternate Setting: 0 Feb 20 12:34:06 tedpc kernel: bLength =9 Feb 20 12:34:06 tedpc kernel: bDescriptorType = 04 Feb 20 12:34:06 tedpc kernel: bInterfaceNumber= 00 Feb 20 12:34:06 tedpc kernel: bAlternateSetting = 00 Feb 20 12:34:06 tedpc kernel: bNumEndpoints = 01 Feb 20 12:34:06 tedpc kernel: bInterface Class:SubClass:Protocol = 03:01:02 Feb 20 12:34:06 tedpc kernel: iInterface = 00 Feb 20 12:34:06 tedpc kernel: Endpoint: Feb 20 12:34:06 tedpc kernel: bLength =7 Feb 20 12:34:06 tedpc kernel: bDescriptorType = 05 Feb 20 12:34:06 tedpc kernel: bEndpointAddress= 81 (in) Feb 20 12:34:06 tedpc kernel: bmAttributes= 03 (Interrupt) Feb 20 12:34:06 tedpc kernel: wMaxPacketSize = 0003 Feb 20 12:34:06 tedpc kernel: bInterval = 0a Feb 20 12:34:06 tedpc kernel: usb.c: registered new driver hid Feb 20 12:34:06 tedpc kernel: input0: USB HID v1.00 Mouse [04b4:0001] on usb1:2.0 Feb 20 12:34:06 tedpc kernel:
Re: [PATCH] use correct include dir for build tools
Mike Castle wrote: > (libc does usually take care to be able to build against a later kernel > version than you're running on, and determine at run time what features may > or may not be there, so one could have a 2.4.2 kernel handy to build libc > against while still running a 2.2.18 kernel. Theoretically.) Red Hat did that for glibc-2.1.9 and glibc-2.2 in RHL-7.0. Hundreds have complaind about /usr/include/linux not being a sym link to /usr/src/linux/include/linux. The kernel headers for glibc are form a pre 2.4.0 kernel and should probably be updated along with a new glibc built against the new headers. I've had no problems with it so far, been running since the pinstripe beta release. -Thomas - 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] use correct include dir for build tools
Mike Castle wrote: (libc does usually take care to be able to build against a later kernel version than you're running on, and determine at run time what features may or may not be there, so one could have a 2.4.2 kernel handy to build libc against while still running a 2.2.18 kernel. Theoretically.) Red Hat did that for glibc-2.1.9 and glibc-2.2 in RHL-7.0. Hundreds have complaind about /usr/include/linux not being a sym link to /usr/src/linux/include/linux. The kernel headers for glibc are form a pre 2.4.0 kernel and should probably be updated along with a new glibc built against the new headers. I've had no problems with it so far, been running since the pinstripe beta release. -Thomas - 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] Re: kernel/printk.c: increasing the buffer size to capture devfsd debug messages.
Thomas Dodd wrote: > > Robert Read wrote: > > > > Ok, here is a simple patch to add a config option, I'm compiling it > > now, so it's not tested yet. One question: what is the best way to > > force this option to be a power of 2? > > Why not just make the config option in Kbytes. > and do: > > #define LOG_BUF_LEN (CONFIG_PRINTK_BUF_LEN * 1024) > > since the config option has a default option and will > always be defined, is the #ifdef check really needed? Oops... It's not needed if all arch's have the config option added. Only parisc uses a different file, config.common instead of config.in Would this break any thing? -Thomas - 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] Re: kernel/printk.c: increasing the buffer size to capture devfsd debug messages.
Robert Read wrote: > > On Tue, Feb 20, 2001 at 01:37:16PM -0600, Thomas Dodd wrote: > > Robert Read wrote: > > > > > > On Wed, Feb 21, 2001 at 02:30:08AM +0900, Ishikawa wrote: > > > > > > > > Has anyone tried 128K buffer size in kernel/printk.c > > > > and still have the kernel boot (without > > > > hard to notice memory corruption problems and other subtle bugs)? > > > > Any hints and tips will be appreciated. > > > > > > I have used 128k and larger buffer sizes, and I just noticed this > > > fragment in the RedHat Tux Webserver patch. It creates a 2MB buffer: > > > > I think this should be a config option. > > Ok, here is a simple patch to add a config option, I'm compiling it > now, so it's not tested yet. One question: what is the best way to > force this option to be a power of 2? Why not just make the config option in Kbytes. and do: #define LOG_BUF_LEN (CONFIG_PRINTK_BUF_LEN * 1024) since the config option has a default option and will always be defined, is the #ifdef check really needed? -Thomas - 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: kernel/printk.c: increasing the buffer size to capture devfsd debug messages.
Robert Read wrote: > > On Wed, Feb 21, 2001 at 02:30:08AM +0900, Ishikawa wrote: > > > > Has anyone tried 128K buffer size in kernel/printk.c > > and still have the kernel boot (without > > hard to notice memory corruption problems and other subtle bugs)? > > Any hints and tips will be appreciated. > > I have used 128k and larger buffer sizes, and I just noticed this > fragment in the RedHat Tux Webserver patch. It creates a 2MB buffer: I think this should be a config option. I use software RADI (md.o) and with 9 md devices, the 16k buffer overflows, and I get md6-md0 in the logs, but nothing prior to md6 being detected/started. I bumbed it upo to 32K and checked the size ofter boot and it's ~26K right now. If I add more partitions/disks to the arrays, or more arrays, that'll be too small. A dynamic size would be even better. Start with 1M or so and add a dmesg hook to rezize it to 8-16K and frre up the rest, so init scripts can save the boot buffer, then keep a smaller buffer during normal use. If you have problems you can change the dmesg call to not change the buffer, and keep the bigger buffer or perhaps make it even bigger. Has anyone tried this before? -Thomas - 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: kernel/printk.c: increasing the buffer size to capture devfsd debug messages.
Robert Read wrote: On Wed, Feb 21, 2001 at 02:30:08AM +0900, Ishikawa wrote: Has anyone tried 128K buffer size in kernel/printk.c and still have the kernel boot (without hard to notice memory corruption problems and other subtle bugs)? Any hints and tips will be appreciated. I have used 128k and larger buffer sizes, and I just noticed this fragment in the RedHat Tux Webserver patch. It creates a 2MB buffer: I think this should be a config option. I use software RADI (md.o) and with 9 md devices, the 16k buffer overflows, and I get md6-md0 in the logs, but nothing prior to md6 being detected/started. I bumbed it upo to 32K and checked the size ofter boot and it's ~26K right now. If I add more partitions/disks to the arrays, or more arrays, that'll be too small. A dynamic size would be even better. Start with 1M or so and add a dmesg hook to rezize it to 8-16K and frre up the rest, so init scripts can save the boot buffer, then keep a smaller buffer during normal use. If you have problems you can change the dmesg call to not change the buffer, and keep the bigger buffer or perhaps make it even bigger. Has anyone tried this before? -Thomas - 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] Re: kernel/printk.c: increasing the buffer size to capture devfsd debug messages.
Robert Read wrote: On Tue, Feb 20, 2001 at 01:37:16PM -0600, Thomas Dodd wrote: Robert Read wrote: On Wed, Feb 21, 2001 at 02:30:08AM +0900, Ishikawa wrote: Has anyone tried 128K buffer size in kernel/printk.c and still have the kernel boot (without hard to notice memory corruption problems and other subtle bugs)? Any hints and tips will be appreciated. I have used 128k and larger buffer sizes, and I just noticed this fragment in the RedHat Tux Webserver patch. It creates a 2MB buffer: I think this should be a config option. Ok, here is a simple patch to add a config option, I'm compiling it now, so it's not tested yet. One question: what is the best way to force this option to be a power of 2? Why not just make the config option in Kbytes. and do: #define LOG_BUF_LEN (CONFIG_PRINTK_BUF_LEN * 1024) since the config option has a default option and will always be defined, is the #ifdef check really needed? -Thomas - 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] Re: kernel/printk.c: increasing the buffer size to capture devfsd debug messages.
Thomas Dodd wrote: Robert Read wrote: Ok, here is a simple patch to add a config option, I'm compiling it now, so it's not tested yet. One question: what is the best way to force this option to be a power of 2? Why not just make the config option in Kbytes. and do: #define LOG_BUF_LEN (CONFIG_PRINTK_BUF_LEN * 1024) since the config option has a default option and will always be defined, is the #ifdef check really needed? Oops... It's not needed if all arch's have the config option added. Only parisc uses a different file, config.common instead of config.in Would this break any thing? -Thomas - 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.1-ac14 won't boot
2.4.1-ac8 worked great, 2.4.1-ac13 and ac14 oops
in IDE initialization. All 3 have ide.2.4.1-p8.all.01172001.patch
applied too. I'll try it without the ide patch today.
-Thomas
---kernel messages---
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
AMD7409: IDE controller on PCI bus 00 dev 39
: chipset revision 3
: not 100% native mode: will probe irqs later
AMD7409: disabling single-word DMA support (revision < C4)
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
hda: IBM-DTTA-351010, ATA DISK drive
hdb: IBM-DTTA-351010, ATA DISK drive
hdc: WDC AC24300L, ATA DISK drive
hdd: ATAPI CDROM, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: status error: status=0x50 { DriveReady SeekComplete }
hda: no DRQ after issuing WRITE
hda:19807200 sectors (10141 MB) w/466KiB Cache, CHS=19650/16/63,
UDMA(33)
hda:ide_intr: hwgroup->busy was 0 ??
Inable to handle kernel NULL pointer dereference at virtual address
0040
printing eip:
c0192e86
*pde =
Oops:
CPU:0
EIP:0010:[]
EFLAGS: 00010046
eax: ebx: c02cf820 ecx: c1461098 edx: 01f7
esi: c02cf820 edi: 0282 ebp: c02cf7e0 esp: c145fe28
ds: 0018 es: 0018 ss: 0018
Process swaper (pid:1, stackpage=c145f000)
stack: c02cf820 c1461080 c018fce0 c02cf820 c0192e70 c1449440 0401
000e
c145fe90 c010a349 000e c1461080 c145fe90 c145fe90 000e
c029fc80
c1449440 c010a4b8 000e c145fe90 c1449440 0380 0212
c029fc80
Call Trace: [] [] [] []
[] [] []
[] [] [] [] []
[] [] []
[] []
Code: 8b 58 40 ec e6 80 0f b6 c8 fb 89 c8 24 c9 3c 40 74 18 0f b6
Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing
spurious 8259A interrupt: IRQ7.
---run ksymoops
ksymoops 2.3.4 on i686 2.4.0-ac12. Options used
-v ./vmlinux (specified)
-K (specified)
-L (specified)
-o /lib/modules/2.4.1-ac14/ (specified)
-m ./System.map (specified)
No modules in ksyms, skipping objects
c0192e86
*pde =
Oops:
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010046
eax: ebx: c02cf820 ecx: c1461098 edx: 01f7
esi: c02cf820 edi: 0282 ebp: c02cf7e0 esp: c145fe28
ds: 0018 es: 0018 ss: 0018
Process swaper (pid:1, stackpage=c145f000)
stack: c02cf820 c1461080 c018fce0 c02cf820 c0192e70 c1449440 0401
000e
c145fe90 c010a349 000e c1461080 c145fe90 c145fe90 000e
c029fc80
c1449440 c010a4b8 000e c145fe90 c1449440 0380 0212
c029fc80
Call Trace: [] [] [] []
[] [] []
[] [] [] [] []
[] [] []
[] []
Code: 8b 58 40 ec e6 80 0f b6 c8 fb 89 c8 24 c9 3c 40 74 18 0f b6
>>EIP; c0192e86<=
Trace; c018fce0
Trace; c0192e70
Trace; c010a349
Trace; c010a4b8
Trace; c0109120
Trace; c010a444
Trace; c0192ba6
Trace; c01949b3
Trace; c0194c3a
Trace; c0194ce4
Trace; c0192353
Trace; c019e56d
Trace; c0105000
Trace; c01070e9
Trace; c0105000
Trace; c01075e6
Trace; c01070e0
Code; c0192e86
<_EIP>:
Code; c0192e86<=
0: 8b 58 40 mov0x40(%eax),%ebx <=
Code; c0192e89
3: ecin (%dx),%al
Code; c0192e8a
4: e6 80 out%al,$0x80
Code; c0192e8c
6: 0f b6 c8 movzbl %al,%ecx
Code; c0192e8f
9: fbsti
Code; c0192e90
a: 89 c8 mov%ecx,%eax
Code; c0192e92
c: 24 c9 and$0xc9,%al
Code; c0192e94
e: 3c 40 cmp$0x40,%al
Code; c0192e96
10: 74 18 je 2a <_EIP+0x2a> c0192eb0
Code; c0192e98
12: 0f b6 00 movzbl (%eax),%eax
Kernel panic: Aiee, killing interrupt handler!
config file-
#
# 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=y
CONFIG_KMOD=y
#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# 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=y
# 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=6
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_USE_3DNOW=y
CONFIG_X86_PGE=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
#
2.4.1-ac14 won't boot
2.4.1-ac8 worked great, 2.4.1-ac13 and ac14 oops
in IDE initialization. All 3 have ide.2.4.1-p8.all.01172001.patch
applied too. I'll try it without the ide patch today.
-Thomas
---kernel messages---
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
AMD7409: IDE controller on PCI bus 00 dev 39
: chipset revision 3
: not 100% native mode: will probe irqs later
AMD7409: disabling single-word DMA support (revision C4)
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
hda: IBM-DTTA-351010, ATA DISK drive
hdb: IBM-DTTA-351010, ATA DISK drive
hdc: WDC AC24300L, ATA DISK drive
hdd: ATAPI CDROM, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: status error: status=0x50 { DriveReady SeekComplete }
hda: no DRQ after issuing WRITE
hda:19807200 sectors (10141 MB) w/466KiB Cache, CHS=19650/16/63,
UDMA(33)
hda:ide_intr: hwgroup-busy was 0 ??
Inable to handle kernel NULL pointer dereference at virtual address
0040
printing eip:
c0192e86
*pde =
Oops:
CPU:0
EIP:0010:[c0192e86]
EFLAGS: 00010046
eax: ebx: c02cf820 ecx: c1461098 edx: 01f7
esi: c02cf820 edi: 0282 ebp: c02cf7e0 esp: c145fe28
ds: 0018 es: 0018 ss: 0018
Process swaper (pid:1, stackpage=c145f000)
stack: c02cf820 c1461080 c018fce0 c02cf820 c0192e70 c1449440 0401
000e
c145fe90 c010a349 000e c1461080 c145fe90 c145fe90 000e
c029fc80
c1449440 c010a4b8 000e c145fe90 c1449440 0380 0212
c029fc80
Call Trace: [c018fce0] [c0192e70] [c010a349] [c010a4b8]
[c0109120] [c010a444] [c0192ba6]
[c01949b3] [c0194c3a] [c0194ce4] [c0192353] [c019e56d]
[c0105000] [c01070e9] [c0105000]
[c01075e6] [c01070e0]
Code: 8b 58 40 ec e6 80 0f b6 c8 fb 89 c8 24 c9 3c 40 74 18 0f b6
Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing
spurious 8259A interrupt: IRQ7.
---run ksymoops
ksymoops 2.3.4 on i686 2.4.0-ac12. Options used
-v ./vmlinux (specified)
-K (specified)
-L (specified)
-o /lib/modules/2.4.1-ac14/ (specified)
-m ./System.map (specified)
No modules in ksyms, skipping objects
c0192e86
*pde =
Oops:
CPU:0
EIP:0010:[c0192e86]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010046
eax: ebx: c02cf820 ecx: c1461098 edx: 01f7
esi: c02cf820 edi: 0282 ebp: c02cf7e0 esp: c145fe28
ds: 0018 es: 0018 ss: 0018
Process swaper (pid:1, stackpage=c145f000)
stack: c02cf820 c1461080 c018fce0 c02cf820 c0192e70 c1449440 0401
000e
c145fe90 c010a349 000e c1461080 c145fe90 c145fe90 000e
c029fc80
c1449440 c010a4b8 000e c145fe90 c1449440 0380 0212
c029fc80
Call Trace: [c018fce0] [c0192e70] [c010a349] [c010a4b8]
[c0109120] [c010a444] [c0192ba6]
[c01949b3] [c0194c3a] [c0194ce4] [c0192353] [c019e56d]
[c0105000] [c01070e9] [c0105000]
[c01075e6] [c01070e0]
Code: 8b 58 40 ec e6 80 0f b6 c8 fb 89 c8 24 c9 3c 40 74 18 0f b6
EIP; c0192e86 task_no_data_intr+16/70 =
Trace; c018fce0 ide_intr+f0/140
Trace; c0192e70 task_no_data_intr+0/70
Trace; c010a349 handle_IRQ_event+39/60
Trace; c010a4b8 do_IRQ+68/b0
Trace; c0109120 ret_from_intr+0/20
Trace; c010a444 enable_irq+74/80
Trace; c0192ba6 ide_config_drive_speed+1c6/3a0
Trace; c01949b3 amd74xx_tune_chipset+283/2a0
Trace; c0194c3a config_chipset_for_dma+ca/100
Trace; c0194ce4 config_drive_xfer_rate+74/130
Trace; c0192353 ide_register_subdriver+93/100
Trace; c019e56d idedisk_init+1d/b0
Trace; c0105000 empty_bad_page+0/1000
Trace; c01070e9 init+9/140
Trace; c0105000 empty_bad_page+0/1000
Trace; c01075e6 kernel_thread+26/30
Trace; c01070e0 init+0/140
Code; c0192e86 task_no_data_intr+16/70
_EIP:
Code; c0192e86 task_no_data_intr+16/70 =
0: 8b 58 40 mov0x40(%eax),%ebx =
Code; c0192e89 task_no_data_intr+19/70
3: ecin (%dx),%al
Code; c0192e8a task_no_data_intr+1a/70
4: e6 80 out%al,$0x80
Code; c0192e8c task_no_data_intr+1c/70
6: 0f b6 c8 movzbl %al,%ecx
Code; c0192e8f task_no_data_intr+1f/70
9: fbsti
Code; c0192e90 task_no_data_intr+20/70
a: 89 c8 mov%ecx,%eax
Code; c0192e92 task_no_data_intr+22/70
c: 24 c9 and$0xc9,%al
Code; c0192e94 task_no_data_intr+24/70
e: 3c 40 cmp$0x40,%al
Code; c0192e96 task_no_data_intr+26/70
10: 74 18 je 2a _EIP+0x2a c0192eb0
task_no_data_intr+40/70
Code; c0192e98 task_no_data_intr+28/70
12: 0f b6 00 movzbl (%eax),%eax
Kernel panic: Aiee, killing interrupt handler!
config file-
#
Re: IDE DMA Problems...system hangs
Jasmeet Sidhu wrote: > > Hey guys, > > I am attaching my previous email for additional info. Now I am using > kernel 2.4.1-ac12 and these problems have not gone away. > > Anybody else having these problems with a ide raid 5? > > The Raid 5 performance should also be questioned..here are some number > returned by hdparam > > /dev/hda -IBM DLTA 20GB (ext2) > /dev/md0 - 8 IBM DLTA 45GB (Reiserfs) > > [root@bertha hdparm-3.9]# ./hdparm -t /dev/hda > /dev/hda: > Timing buffered disk reads: 64 MB in 2.36 seconds = 27.12 MB/sec > > [root@bertha hdparm-3.9]# ./hdparm -t /dev/md0 > /dev/md0: > Timing buffered disk reads: 64 MB in 22.16 seconds = 2.89 MB/sec > > Is this to be expected? This much performance loss? Anybody else using > IDE raid, I would really appreciate your input on this setup. md2 = RAID0 ext2 hda = hdb = IBM DTTA-351010 (10GB, 5400RPM, UDMA33) # hdparm -tT /dev/hda /dev/md2 /dev/hda: Timing buffered disk reads: 64 MB in 5.27 seconds = 12.14 MB/sec Timing buffer-cache reads: 128 MB in 0.82 seconds =156.10 MB/sec /dev/md2: Timing buffered disk reads: 64 MB in 3.34 seconds = 19.16 MB/sec Timing buffer-cache reads: 128 MB in 0.80 seconds =160.00 MB/sec On AMD K7 w/ 7409 (Viper) chipset, DMA66 mode w/ 80-pin cable. kernel = 2.4.1-ac8, no errors in kernel log. So I get a 58% increase. You should almost max out the bus. You probably have a bad cable. Try hdparam on each disk and see if any of them have errors/ cause the lockup. -Thomas - 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: IDE DMA Problems...system hangs
Jasmeet Sidhu wrote: Hey guys, I am attaching my previous email for additional info. Now I am using kernel 2.4.1-ac12 and these problems have not gone away. Anybody else having these problems with a ide raid 5? The Raid 5 performance should also be questioned..here are some number returned by hdparam /dev/hda -IBM DLTA 20GB (ext2) /dev/md0 - 8 IBM DLTA 45GB (Reiserfs) [root@bertha hdparm-3.9]# ./hdparm -t /dev/hda /dev/hda: Timing buffered disk reads: 64 MB in 2.36 seconds = 27.12 MB/sec [root@bertha hdparm-3.9]# ./hdparm -t /dev/md0 /dev/md0: Timing buffered disk reads: 64 MB in 22.16 seconds = 2.89 MB/sec Is this to be expected? This much performance loss? Anybody else using IDE raid, I would really appreciate your input on this setup. md2 = RAID0 ext2 hda = hdb = IBM DTTA-351010 (10GB, 5400RPM, UDMA33) # hdparm -tT /dev/hda /dev/md2 /dev/hda: Timing buffered disk reads: 64 MB in 5.27 seconds = 12.14 MB/sec Timing buffer-cache reads: 128 MB in 0.82 seconds =156.10 MB/sec /dev/md2: Timing buffered disk reads: 64 MB in 3.34 seconds = 19.16 MB/sec Timing buffer-cache reads: 128 MB in 0.80 seconds =160.00 MB/sec On AMD K7 w/ 7409 (Viper) chipset, DMA66 mode w/ 80-pin cable. kernel = 2.4.1-ac8, no errors in kernel log. So I get a 58% increase. You should almost max out the bus. You probably have a bad cable. Try hdparam on each disk and see if any of them have errors/ cause the lockup. -Thomas - 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: spelling of disc (disk) in /devfs
Peter Samuelson wrote: > > [Jeremy M. Dolan] > > Disk is spelled 'disk' except for Compact Disc and Digital Versatile > > Disc. If it wasn't 3:30 in the morning, a patch would be attached. > > It wouldn't do any good. Many months ago, Ted Ts'o pleaded with > Richard Gooch (devfs author, from Australia) to switch to the American > spelling of the word, for consistency with the rest of the kernel, and > nothing came of it. At this point you may as well consider > '/dev/discs' an "interface set in stone". (Come on, do *you* want to > explain to thousands of people why their /etc/fstab suddenly broke?) Better still, follow the lead from other Solaris and HP-UX. /dev/dsk/* block access for hard drives /dev/rdsk/* char access for hard drives /dev/diskette block access for floppy drives /dev/rdiskette char access for floppy drives /dev/rscsi/* char access for raw scsi (replace /dev/sg* ) Since linux currently doesn't have char access to drives, rdsk/rdiskette would be ignored untill it is implemented and needed. My $0.02 -Thomas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: spelling of disc (disk) in /devfs
Peter Samuelson wrote: [Jeremy M. Dolan] Disk is spelled 'disk' except for Compact Disc and Digital Versatile Disc. If it wasn't 3:30 in the morning, a patch would be attached. It wouldn't do any good. Many months ago, Ted Ts'o pleaded with Richard Gooch (devfs author, from Australia) to switch to the American spelling of the word, for consistency with the rest of the kernel, and nothing came of it. At this point you may as well consider '/dev/discs' an "interface set in stone". (Come on, do *you* want to explain to thousands of people why their /etc/fstab suddenly broke?) Better still, follow the lead from other Solaris and HP-UX. /dev/dsk/* block access for hard drives /dev/rdsk/* char access for hard drives /dev/diskette block access for floppy drives /dev/rdiskette char access for floppy drives /dev/rscsi/* char access for raw scsi (replace /dev/sg* ) Since linux currently doesn't have char access to drives, rdsk/rdiskette would be ignored untill it is implemented and needed. My $0.02 -Thomas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: need help raid and 2.4.0
david wrote: > > hi i am moving from 2.2.18 to 2.4.0 i have a ide raid set but can not > get it to run under 2.4.0 > i user mdadd / mdrun to config it. in raid-tools 0.42 but it dose not > come up under 2.4.0 it just says unknow devices /dev/hda3 & /dev/hdc3 > but thay are thear and when i try to compile raid-tools .53 undir 2.4.0 > i get a lot of error in string.h (i am runing debian 2.2r2) > i configured the kernel First, did the IDE driver detect the disks/partitions listed? what does /proc/partitions, /proc/modules, and /proc/ioports show in 2.4.0? I switched from 2.2.x -> 2.4.0 with IDE RAID disks fine. Using the RedHat7.0 default of raidtool-0.90 Try building the newer raidtools and make sure to use the correct kernel headers (the ones for 2.4.0) -Thomas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: need help raid and 2.4.0
david wrote: hi i am moving from 2.2.18 to 2.4.0 i have a ide raid set but can not get it to run under 2.4.0 i user mdadd / mdrun to config it. in raid-tools 0.42 but it dose not come up under 2.4.0 it just says unknow devices /dev/hda3 /dev/hdc3 but thay are thear and when i try to compile raid-tools .53 undir 2.4.0 i get a lot of error in string.h (i am runing debian 2.2r2) i configured the kernel First, did the IDE driver detect the disks/partitions listed? what does /proc/partitions, /proc/modules, and /proc/ioports show in 2.4.0? I switched from 2.2.x - 2.4.0 with IDE RAID disks fine. Using the RedHat7.0 default of raidtool-0.90 Try building the newer raidtools and make sure to use the correct kernel headers (the ones for 2.4.0) -Thomas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
Andrea Arcangeli wrote:
>
> On Fri, Dec 15, 2000 at 05:55:08PM -0200, Rik van Riel wrote:
> > On Fri, 15 Dec 2000, Andrea Arcangeli wrote:
> >
> > > x()
> > > {
> > >
> > > switch (1) {
> > > case 0:
> > > case 1:
> > > case 2:
> > > case 3:
> > > ;
> > > }
> > > }
> > >
> > > Why am I required to put a `;' only in the last case and not in
> > > all the previous ones?
> >
> > That `;' above is NOT in just the last one. In your above
> > example, all the labels will execute the same `;' statement.
> >
> > In fact, the default behaviour of the switch() operation is
> > to fall through to the next defined label and you have to put
> > in an explicit `break;' if you want to prevent `case 0:' from
> > reaching the `;' below the `case 3:'...
>
> Are you kidding me?
Absolutely NOT.
switch (x) {
case 0:
case 1:
printf ("%d\n", x);
break;
case 2:
printf ("%d\n",x*x);
case 3:
printf ("%d\n", x*x*x);
}
if x==0 or 1, prints x (the 0 or one),
if x==2 , it prints 4 and 8 since no break statement exits the switch,
if x==3, it prints only 27,
any othe value of x, and nothing is printed.
Every C compile I have ever used does this.
Sun's C and C++, HP's C, Microsoft's VC++, Borland's C, and all versions
of gcc and g++.
Grab any C programming book, and find the switch statement.
-Thomas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
Andrea Arcangeli wrote:
On Fri, Dec 15, 2000 at 05:55:08PM -0200, Rik van Riel wrote:
On Fri, 15 Dec 2000, Andrea Arcangeli wrote:
x()
{
switch (1) {
case 0:
case 1:
case 2:
case 3:
;
}
}
Why am I required to put a `;' only in the last case and not in
all the previous ones?
That `;' above is NOT in just the last one. In your above
example, all the labels will execute the same `;' statement.
In fact, the default behaviour of the switch() operation is
to fall through to the next defined label and you have to put
in an explicit `break;' if you want to prevent `case 0:' from
reaching the `;' below the `case 3:'...
Are you kidding me?
Absolutely NOT.
switch (x) {
case 0:
case 1:
printf ("%d\n", x);
break;
case 2:
printf ("%d\n",x*x);
case 3:
printf ("%d\n", x*x*x);
}
if x==0 or 1, prints x (the 0 or one),
if x==2 , it prints 4 and 8 since no break statement exits the switch,
if x==3, it prints only 27,
any othe value of x, and nothing is printed.
Every C compile I have ever used does this.
Sun's C and C++, HP's C, Microsoft's VC++, Borland's C, and all versions
of gcc and g++.
Grab any C programming book, and find the switch statement.
-Thomas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm settings: Can they be permanent?
"Mike A. Harris" wrote: > > On Thu, 5 Oct 2000, Harald Welte wrote: > > >Some distributions already have the hdparm initscript. > > I'm not sure about that one for RH.. I use my own script, but > there might be one now.. rc.sysinit looks at /etc/sysconfig/harddisks in pinstripe and guinness. harddisks comes from the hdparm RPM. -Thomas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm settings: Can they be permanent?
"Mike A. Harris" wrote: On Thu, 5 Oct 2000, Harald Welte wrote: Some distributions already have the hdparm initscript. I'm not sure about that one for RH.. I use my own script, but there might be one now.. rc.sysinit looks at /etc/sysconfig/harddisks in pinstripe and guinness. harddisks comes from the hdparm RPM. -Thomas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
