Re: 2.2.14 SMP 3com905: transmit timed out: Odd lost irq and ip-stack lockup
On Fri, 13 Oct 2000, Andrew Morton wrote: > > Oct 9 17:29:02 fwintern kernel: eth0: Interrupt posted but not > > delivered -- IRQ blocked by another device? > > This is the infamous APIC bug. I have about ten reports of this over a > four-month period. Mark Hemment mentioned it just yesterday. > > This is not a 3c59x problem. It is due to the APIC forgetting how to > generate interrupts for a particular IRQ. It happens mostly for NICs > because they generate a lot of interrupts. I've had it happen just > once. In that case, _nothing_ would make the interrupt come back > (including a driver unload/reload). > > This gets reported a lot by 3c59x users because this driver specifically > detects and reports on the problem. Hmm, that's interesting. It would be worthwhile to see a dump of APICs' state when this happens -- maybe an EOI message gets lost for some reason or an erratum is biting us. There are functions for such kind of diagnostics already available; they are print_IO_APIC() and print_all_local_APICs() and may be called on demand by a tiny module, for example. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - 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: Updated 2.4 TODO List
> On Wed, 11 Oct 2000 18:10:40 -0400,
> [EMAIL PROTECTED] wrote:
> >Are you sure it was compiled with the correct CPU? If you configure the
> >CPU incorrectly (686 when you only have a 586, etc.) the kernel *will*
> >refuse to boot.
> >
> >Maybe we should have the kernel print the CPU information it was
> >compiled with before it does anything else. It'll make it easier to
> >catch what may be a fairly common set of PEBCAK case
>
> Unfortunately any code like this
> if (a)
> b = 99;
> generates conditional move (cmove) instructions on 686. In vsprintf.c
> there are several of these constructs, in particular strnlen generates
> it. So printk("%s", text) tends to fault as well. Some people have
> argued that critical routines should always be compiled with -i386,
> unfortunately that includes all of printk and all console handling
> (both serial and screen), not really an option.
>
> If anything is going to detect the mismatch and complain, it has to be
> the boot loader, after uncompressing and before entering the kernel
> proper.
But the kernel should be able to write directly to the screen, even if it's
extremely minimal information. Something like how LILO does it: test the
common hang-on-boot conditions (like wrong CPU type) and print a single
character after each test.
chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Problem with include/linux/fs.h vs. glibc
Hi ! Sorry if this have already been the cause of a flamewar on the list, but... I need to compile an app with the 2.4 kernel headers & glibc (our stable glibc on PPC is based on 2.1.3). However, the compiler is barking on a change done in 2.4 version of include/linux/fs.h: The 2.2.x version didn't include and all was fine. The 2.4.x version does include and this is causing gcc to bark because of conflicts with glibc headers (glibc seems to #define some of the prototypes defined in linux/string.h, causing various parse errors). So what is the solution ? - removing the #include from linux/fs.h ? - moving it in a #ifdef __KERNEL__ part of the file ? - protect linux/string.h itself with #ifdef __KERNEL__ ? - fix glibc ? (how ? I mean, it's legal to include linux/fs.h from userland, but linux/string.h is obviously not meant to be exported out of the kernel) Regards, Ben. - 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.14 SMP 3com905: transmit timed out: Odd lost irq and ip-stack lockup
"Dr. Michael Weller" wrote: > > Dear list, > > I run a Compaq Proliant 1500 (dual Pentium 75.200) with hardware raid > (Smart2) with two ethernet cards 3com905 (b or c, I can't tell you right > now) as a firewall and web/mail virus scanner which (needless to say) > needs to be up 7d/24h. > > Recently, during a pretty fast download the machine (ethernet technically, > you could login on the console, even ping the ethernet ip address) locked > up with the following error log: > > Oct 9 17:29:02 fwintern kernel: eth0: transmit timed out, tx_status > 00 status e681. Here is your problem: > Oct 9 17:29:02 fwintern kernel: eth0: Interrupt posted but not > delivered -- IRQ blocked by another device? This is the infamous APIC bug. I have about ten reports of this over a four-month period. Mark Hemment mentioned it just yesterday. This is not a 3c59x problem. It is due to the APIC forgetting how to generate interrupts for a particular IRQ. It happens mostly for NICs because they generate a lot of interrupts. I've had it happen just once. In that case, _nothing_ would make the interrupt come back (including a driver unload/reload). This gets reported a lot by 3c59x users because this driver specifically detects and reports on the problem. Donald Becker says that this is a software bug (I don't know why he thinks this). He says that he _always_ boots linux with the `noapic' option to prevent it happening. > The problem was reproducible (several times) with the same download (a > 300MB file) after a reboot. Interesting. So you had a stable 2.2.14 machine which suddenly started repeatedly exhibiting this problem? Is it still reproducible? - 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: IRQ affinity vs. MTRRs, was Re: 36 bit MTRRs, Re: test10-pre1 problems on 4-way SuperServer8050
Boszormenyi Zoltan <[EMAIL PROTECTED]> writes: > The idea is that when it is sure that _only one_ (or some) CPU will access > a PCI card's mmio area then only that CPU's (those CPUs') MTRRs needs to > contain an entry for that area. > > Although there are (must be) common MTRR entries for the main memory > and the commonly accessed mmio register areas. > > The idea came because fiddling with MTRRs quickly revaled that > only 8 variable ones exist. I see. I think there is a more straightforward solution: PAT does the same thing as MTRRs, but has no such "number of ranges" limitation --- it lets you set the memory type on a page-by-page basis. If the number of MTRRs becomes a problem (anyone know how many the P4 has?), then the real solution is to implement PAT support. IIRC, only the PPro, the first PII model (Klamath?), and the first Celeron model have MTRR but not PAT (Athlon has PAT, but /proc/cpuinfo misreports it as "fcmov", at least in 2.2.14; Xeons always had PAT). David - 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: want tool to open RPM package on Window 95
Igmar Palsenberg <[EMAIL PROTECTED]> writes: > On Wed, 11 Oct 2000 [EMAIL PROTECTED] wrote: > > > Can anyone tell me which tool can open RPM package on Window 95 and where to >download it? > > There isn't, and it serves no use anyway. I can think of a number of uses for such a tool. For example, to read the documentation of a package before installing it on a different (Linux-based) system; or to unpack a source-rpm in order to build it with Cygwin. > Second, I'm glad there isn't. Saves tons of bugus bug reports. Bug reports for whom? - Ruud de Rooij. -- ruud de rooij | *@spam.ruud.org | http://ruud.org - 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: calling system call from kernel module
On Thu, 12 Oct 2000 [EMAIL PROTECTED] wrote: > hi, > Is there any way to call system call from a kernel module??? yes, just call it. system calls are just functions (mostly exported and when otherwise, use sys_call_table[] which is exported, but it won't work on __mips__) so you can just call them. Regards, Tigran - 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/
calling system call from kernel module
hi, Is there any way to call system call from a kernel module??? - 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: Updated Linux 2.4 Status/TODO List (from the ALS show)
"[EMAIL PROTECTED] wrote:" > * Use PCI DMA by default in IDE is unsafe (must not do so on via >VPx, x < 3) (Vojtech Pavlik --- requires chipset tuning to be >enabled according to Andre Hedrick --- we need to turn this on by >default, if it is safe -- TYT) Using PCI DMA is also generally broken for modular IDE. Unloading/reloading the ide-probe-mod module still causes an oops when accessing disks (NULL pointer dereference / Aiee, killing the interrupt handler / Panic) and you are left with a dead system :( I observe it with alim15xx, but probably problem is more general and appears somewhere in IDE initialization by ide-probe-mod (IMHO). I observe similar (but not exactly the same) problem in 2.2.17+ide. I think that getting rid of the ide-probe-mod module (and linking it into ide-mod) should solve the problem. What do you think of it Andre ? Andrzej -- === Andrzej M. Krzysztofowicz [EMAIL PROTECTED] phone (48)(58) 347 14 61 Faculty of Applied Phys. & Math., Technical University of Gdansk - 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: want tool to open RPM package on Window 95
On Wed, 11 Oct 2000 [EMAIL PROTECTED] wrote: > Can anyone tell me which tool can open RPM package on Window 95 and where to >download it? There isn't, and it serves no use anyway. Second, I'm glad there isn't. Saves tons of bugus bug reports. Igmar - 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: BIG problem with BusLogic SCSI and/or something else
> Note that the sync-rate of target 6, the device I added, has been > turned down to try to eliminate any hardware problems. Also note > that the entire drive has been read/written with the BusLogic BIOS > diagnostic setup utility. That BIOS setup tool might just use asynchronous I/O for anything, so this may not be an indicator in any way. Did you check your cable length and termination? You need exactly two terminators, one at each end of the cable. None in between. Note that the host adaptor does not get terminated if you connect two cables to it. > No. There are no logs after the "Aborting" messages. There is nothing > written to any hard disks as a record even of the first message. The > only messages on the console are the "aborted" messages, not even a > "timeout" or any other such. Further, the messages run so fast that > I had to take a scope camera photo at 1/1000th sec to figure out what > they said. Do you have a different machine with null-modem or something? You could copy your syslog/klog output there, or you could send it to a different host in your LAN. -- Matthias Andree - 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: Updated Linux 2.4 Status/TODO List (from the ALS show)
>10. To Do But Non Showstopper > > * Go through as 2.4pre kicks in and figure what we should mark > obsolete for the final 2.4 (i.e. XT hard disk support?) > * Union mount (Al Viro) ^^^ Anyone know the status of this? I have seen postings saying it's likely a 2.5 thingy, but it's continually on the 2.4 TODO lists. I am willing to help if it's needed/wanted. Thanks, Phil Philip Auld Dept. of Computer Science College of William and Mary - 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: Updated 2.4 TODO List -- new addition WAS(test9 PCI
Cort Dougan <[EMAIL PROTECTED]> said: > Horst von Brand on Wed, Oct 11, 2000 at 11:21:06PM -0400 said: [...] > } Oh, come on. The kernel (or glibc for that matter) is not about "inline > } asm()" at all! That is a tiny fraction of each. The kernel is different in > } that it has lots of hardware-dependent code, which leads to some rather > } strange contortions in C in order to be able to _avoid_ asm. The kernel > } also moves forward a lot faster than glibc, and grows a lot. A bug in glibc > } means an application goes down or screws up, a bug in the kernel can mean > } masive data loss in no time at all. > I don't think I understand your point. Are you saying that gcc cannot be > expected to keep up with the ways in which the kernel uses it? My argument > is that providing a compiler that actually regresses (old version compiles > kernel, redhat 7.0 included one does not) is not a good choice. What I'm stating is just the fact that the kernel isn't keeping up with the compiler. -- Dr. Horst H. von Brand mailto:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - 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: IRQ affinity vs. MTRRs, was Re: 36 bit MTRRs, Re: test10-pre1problems on 4-way SuperServer8050
On 12 Oct 2000, David Wragg wrote: > Boszormenyi Zoltan <[EMAIL PROTECTED]> writes: > > I came up with an idea. The MTRRs are per-cpu things. > > Ingo Molnar's IRQ affinity code helps binding certain > > IRQ sources to certain CPUs. > > They are implemented as per-cpu things but the Intel manuals say that > all cpus should have the same MTRR settings. They also give > pseudo-code for how to update them on an SMP system, which mtrr.c > follows. > > If the BIOS has set them up differently at boot time, mtrr.c will > complain and copy the MTRR settings of CPU0 to the others. Yes, I read the Intel manuals and I know how the mtrr driver works. The idea is that when it is sure that _only one_ (or some) CPU will access a PCI card's mmio area then only that CPU's (those CPUs') MTRRs needs to contain an entry for that area. Although there are (must be) common MTRR entries for the main memory and the commonly accessed mmio register areas. The idea came because fiddling with MTRRs quickly revaled that only 8 variable ones exist. Regards, Zoltan Boszormenyi - 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/
[success!] Re: test10-pre1 problems on 4-way SuperServer8050
On Thu, 12 Oct 2000, Tigran Aivazian wrote: > On 12 Oct 2000, David Wragg wrote: > > Ok. I'll wait for feedback from Tigran, and if I don't get anything > > negative I'll submit to Linus. The 2.2 version of my patch fixes > > problems for other people, VA Linux have included it in their kernel > > for a while with no problems that have been reported back to me), and > > it's silly that it isn't in 2.4testX. I should have addressed this a > > while ago, but I have my own distractions from kernel hacking. > > > > Later on, you can send a mtrr.c maintenance patch, if you like. > > > > I've just caught up on this whole thread, and I don't have any > > objections in principle to Zoltan's patch being used instead of mine, > > though I'd like to take a look at it first. > > David, sorry I didn't know that your patch is fundamentally different from > Zoltan's. I will now re-test with your patch and see if it makes my > eepro100 "instabilities" go away. > > The performance problems went away as I said earlier, by fiddling with > cache settings in the BIOS. (with and without Zoltan's patch my machine is > now as fast as it can be) > hmmm, very interesting... It looks like your patch fixed all the remaining problems. I.e. not only my 6G is now fast (it was without your patch) but all the eepro100 interfaces now _always_ (tried 4 reboots) come up functioning. Your patch is now a permanent part of my tree, thank you! :) Thanks, Tigran - 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: RAID setup
> Hi, > I want to setup RAID. > I am working on kernel version 2.2.12. > I am using RAID patches available. > > I create a RAID configuring file called > /etc/raidtab > > #mkraid /dev/md0/*md0 is the device I am > selecting*/ > > After this when I check /proc/mdstat , I find that > /dev/md0 is not running. > The /proc/mdstat gives message: > device md0:inactive. > > Where am I wrong? > should I be doing something else before & after > mkraid? > > I am not able to post messages to linu-raid group. > May I know what is the correct mail id for this > group? Upgrade your kernel and RTFM. This is all in the docs that come with the RAID tools. Igmar - 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/
[PATCH 2.3.x] struct console init
Hi Linus,
This patch converts all initializations of `struct console' objects to new
style initialization constructs.
--- linux-2.4.0-test10-pre1/drivers/char/console.c Fri Aug 11 13:53:24 2000
+++ geert-console-2.4.0-test10-pre1/drivers/char/console.c Thu Oct 12 15:27:04
+2000
@@ -2147,17 +2147,13 @@
}
struct console vt_console_driver = {
- "tty",
- vt_console_print,
- NULL,
- vt_console_device,
- keyboard_wait_for_keypress,
- unblank_screen,
- NULL,
- CON_PRINTBUFFER,
- -1,
- 0,
- NULL
+ name: "tty",
+ write: vt_console_print,
+ device: vt_console_device,
+ wait_key: keyboard_wait_for_keypress,
+ unblank:unblank_screen,
+ flags: CON_PRINTBUFFER,
+ index: -1,
};
#endif
--- linux-2.4.0-test10-pre1/drivers/char/dz.c Tue Jul 18 14:07:06 2000
+++ geert-console-2.4.0-test10-pre1/drivers/char/dz.c Thu Oct 12 15:27:11 2000
@@ -1553,17 +1553,13 @@
}
static struct console dz_sercons = {
- "ttyS",
- dz_console_print,
- NULL,
- dz_console_device,
- dz_console_wait_key,
- NULL,
- dz_console_setup,
- CON_CONSDEV | CON_PRINTBUFFER,
- CONSOLE_LINE,
- 0,
- NULL
+ name: "ttyS",
+ write: dz_console_print,
+ device: dz_console_device,
+ wait_key: dz_console_wait_key,
+ setup: dz_console_setup,
+ flags: CON_CONSDEV | CON_PRINTBUFFER,
+ index: CONSOLE_LINE,
};
void __init dz_serial_console_init(void)
--- linux-2.4.0-test10-pre1/drivers/char/lp.c Wed Oct 4 19:53:03 2000
+++ geert-console-2.4.0-test10-pre1/drivers/char/lp.c Thu Oct 12 15:27:17 2000
@@ -603,17 +603,10 @@
}
static struct console lpcons = {
- "lp",
- lp_console_write,
- NULL,
- lp_console_device,
- NULL,
- NULL,
- NULL,
- CON_PRINTBUFFER,
- 0,
- 0,
- NULL
+ name: "lp",
+ write: lp_console_write,
+ device: lp_console_device,
+ flags: CON_PRINTBUFFER,
};
#endif /* console on line printer */
--- linux-2.4.0-test10-pre1/drivers/char/serial.c Sat Sep 23 17:31:15 2000
+++ geert-console-2.4.0-test10-pre1/drivers/char/serial.c Thu Oct 12 15:27:24
+2000
@@ -5666,17 +5666,13 @@
}
static struct console sercons = {
- "ttyS",
- serial_console_write,
- NULL,
- serial_console_device,
- serial_console_wait_key,
- NULL,
- serial_console_setup,
- CON_PRINTBUFFER,
- -1,
- 0,
- NULL
+ name: "ttyS",
+ write: serial_console_write,
+ device: serial_console_device,
+ wait_key: serial_console_wait_key,
+ setup: serial_console_setup,
+ flags: CON_PRINTBUFFER,
+ index: -1,
};
/*
--- linux-2.4.0-test10-pre1/drivers/char/serial167.cMon Jul 17 15:20:00 2000
+++ geert-console-2.4.0-test10-pre1/drivers/char/serial167.cThu Oct 12 15:27:31
+2000
@@ -2858,17 +2858,13 @@
static struct console sercons = {
- "ttyS",
- serial167_console_write,
- NULL,
- serial167_console_device,
- serial167_console_wait_key,
- NULL,
- serial167_console_setup,
- CON_PRINTBUFFER,
- -1,
- 0,
- NULL
+ name: "ttyS",
+ write: serial167_console_write,
+ device: serial167_console_device,
+ wait_key: serial167_console_wait_key,
+ setup: serial167_console_setup,
+ flags: CON_PRINTBUFFER,
+ index: -1,
};
--- linux-2.4.0-test10-pre1/drivers/char/serial_21285.c Tue Aug 15 19:00:27 2000
+++ geert-console-2.4.0-test10-pre1/drivers/char/serial_21285.c Thu Oct 12 15:27:39
+2000
@@ -490,17 +490,13 @@
static struct console rs285_cons =
{
- SERIAL_21285_NAME,
- rs285_console_write,
- NULL,
- rs285_console_device,
- rs285_console_wait_key,
- NULL,
- rs285_console_setup,
- CON_PRINTBUFFER,
- -1,
- 0,
- NULL
+ name: SERIAL_21285_NAME,
+ write: rs285_console_write,
+ device: rs285_console_device,
+ wait_key: rs285_console_wait_key,
+ setup: rs285_console_setup,
+ flags: CON_PRINTBUFFER,
+ index: -1,
};
void __init rs285_console_init(void)
--- linux-2.4.0-test10-pre1/drivers/char/serial_amba.c Wed Sep 20 13:19:42 2000
+++ geert-console-2.4.0-test10-pre1/drivers/char/serial_amba.c Thu Oct 12 15:27:49
+2000
@@ -2016,7 +2016,6 @@
#endif
device: ambauart_console_device,
wait_key: ambauart_console_wait_key,
- unblank:NULL,
setup: ambaua
Re: Announce: Via audio driver update
On Thu, 12 Oct 2000, Jeff Garzik wrote: > Please test if you have Via hardware, and report any bugs found. > Feedback, comments, questions, and patches welcome. Preliminary report after using 1.1.9: On Module load: Via 686a audio driver 1.1.9 ac97_codec: AC97 Audio codec, vendor id1: 0x4943, id2: 0x4511 (Unknown) via82cxxx: board #1 at 0xDC00, IRQ 5 This is on an Epox Mobo, with a AMD Duron. Whenever I start playback, the following gets dumped into syslog, although audio is fine: Assertion failed! chan->slop_len > 0,via82cxxx_audio.c,via_chan_flush_frag,line=963 Assertion failed! wait != NULL,via82cxxx_audio.c,via_dsp_poll,line=2056 Assertion failed! chan->slop_len > 0,via82cxxx_audio.c,via_chan_flush_frag,line=963 Assertion failed! wait != NULL,via82cxxx_audio.c,via_dsp_poll,line=2056 Assertion failed! chan->slop_len > 0,via82cxxx_audio.c,via_chan_flush_frag,line=963 Also, the problem I previouly described still exists: Whenever I try to skip through a song, the output gets distorted immensely. You can still hear the song playing, but overlayed on it is very harsh noise. If it helps, the noise sounds different on 1.1.9 than 1.1.8 :) Nothing in syslog, though. Using esd avoids this problem, as well as just stopping playback and restarting it. I'd appreciate any comments! Dewet - 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: 36 bit MTRRs, Re: test10-pre1 problems on 4-waySuperServer8050
On Thu, 12 Oct 2000, Tigran Aivazian wrote:
> ok, doing it from the bottom up was fine (didn't lockup) but reaching the
> last (first in your list) entry was refused by mtrr:
>
> mtrr: 0x0,0x1 overlaps existing 0xfeafe000,0x2000
Try the attached patch, and the driver will accept some cases
where areas overlap and the types (cache/no cache) differ.
These were tested.
Here are some info:
BIOS-provided physical RAM map:
BIOS-e820: 0009fc00 @ (usable)
BIOS-e820: 0400 @ 0009fc00 (reserved)
BIOS-e820: 0001 @ 000f (reserved)
BIOS-e820: 07efd000 @ 0010 (usable)
BIOS-e820: 2000 @ 07ffd000 (ACPI data)
BIOS-e820: 1000 @ 07fff000 (ACPI NVS)
BIOS-e820: 1000 @ fec0 (reserved)
BIOS-e820: 1000 @ fee0 (reserved)
BIOS-e820: 0001 @ (reserved)
[root@localhost /root]# cd /proc
[root@localhost /proc]# cat mtrr
reg00: base=0x ( 0MB), size= 128MB: write-back, count=1
reg05: base=0xe200 (3616MB), size= 32MB: write-combining, count=1
[root@localhost /proc]# echo "disable=5" >mtrr
[root@localhost /proc]# echo "disable=0" >mtrr
[root@localhost /proc]# echo "base=0x size=0x1 type=uncachable" >mtrr
[root@localhost /proc]# echo "base=0xfee0 size=0x1000 type=uncachable" >mtrr
[root@localhost /proc]# echo "base=0xfec0 size=0x1000 type=uncachable" >mtrr
[root@localhost /proc]# echo "base=0xde00 size=0x200 type=uncachable" >mtrr
[root@localhost /proc]# echo "base=0xe200 size=0x200 type=uncachable" >mtrr
[root@localhost /proc]# echo "base=0 size=0x1 type=write-back" >mtrr
[root@localhost /proc]# cat mtrr
reg00: base=0x (4095MB), size= 64kB: uncachable, count=1
reg01: base=0xfee0 (4078MB), size= 4kB: uncachable, count=1
reg02: base=0xfec0 (4076MB), size= 4kB: uncachable, count=1
reg03: base=0xde00 (3552MB), size= 32MB: uncachable, count=1
reg04: base=0xe200 (3616MB), size= 32MB: uncachable, count=1
reg05: base=0x ( 0MB), size=4096MB: write-back, count=1
It works, the system is fast, and X comes up. If I do not set the
videocard's areas, then X does not work, it locks up the machine.
(Expected behaviour, write-back caching does no good on mmio registers.)
The patch contains a typo fix which corrects the lines:
reg00: base=0xfeafe000 (4074MB), size= 0kB: uncachable, count=1
reg01: base=0xfe9ee000 (4073MB), size= 0kB: uncachable, count=1
reg02: base=0xfe9ed000 (4073MB), size= 0kB: uncachable, count=1
It did not affect anything, only the kB sized entries were
written incorrectly.
Regards,
Zoltan Boszormenyi
--- linux/arch/i386/kernel/mtrr.c.old1 Wed Oct 11 16:49:07 2000
+++ linux/arch/i386/kernel/mtrr.c Thu Oct 12 15:26:48 2000
@@ -1320,6 +1320,13 @@
/* At this point we know there is some kind of overlap/enclosure */
if ( (base < lbase) || (base + size > lbase + lsize) )
{
+ /* Allow overlap in some (tested) cases */
+ if (
+ ( ( type == MTRR_TYPE_WRBACK || type == MTRR_TYPE_WRTHROUGH || type ==
+MTRR_TYPE_WRCOMB) && ltype == MTRR_TYPE_UNCACHABLE )
+ ||
+ ( ( type == MTRR_TYPE_WRBACK || type == MTRR_TYPE_WRTHROUGH ) && ltype
+== MTRR_TYPE_WRCOMB )
+ )
+ continue;
up(&main_lock);
printk ("mtrr: 0x%lx%s,0x%lx%s overlaps existing 0x%lx%s,0x%lx%s\n",
base, base_suffix, size, size_suffix,
@@ -1701,7 +1708,7 @@
{
/* 1MB */
factor = 'k';
- size >>= 2;
+ size <<= 2;
}
else
{
Re: tty_[un]register_devfs putting 3K structures on the stack
> If the problem only impacts User-mode Linux, it's hard for me to > justify > hanging the "critical" label on it. However I'm willing to look at > the > patch, bless it, and send it on to Linus (who as you know sometimes is > a > softy about such things. :-) I wasn't considering it a possible critical bug because it hurts UML. I was more considering it a potentially very nasty bug that UML happened to uncover. Jeff - 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/
invalidate buffers is not guaranteed to invalidate
Searching for the cause of some strange corruption of the MBR I noticed that invalidate_buffers is not guaranteed to invalidate the buffers - very unfortunate. (Indeed, bh is removed only when bh->b_count is zero. This means that one will get disk corruption if one changes disks while some buffer heads still have nonzero count.) In this particular case the problem was caused by fs/partitions/atari.c that did a bread() without corresponding brelse(). [patch sent to Linus] Andries P.S. imm.c contains the amusing comment /* Aimmrently the ... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9 + Winchip2/2A processor family == hang on boot
[EMAIL PROTECTED] wrote: > > Sounds like you got caught by the conditional move instruction that is > > generated for 686. It causes oops on 586, and somewhere in the oops or > > printk code you hit another cmove. Double fault, kernel hang. > > Ah yes, it all comes back to me now :) > Also explains why my printk's weren't working during tests. > > I'm amazed it took this long for someone to notice. :) > I'll have to start running devel kernels on all the > funky hardware like Winchip. Mine has been running 2.2 > (where this isn't an issue) for a long time. Maybe it wouldn't be a bad idea to emulate cmov specifically so this sort of thing generates a reasonable diagnostic. cmov is a very simple instruction, very easy to emulate. -- Jamie - 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: IRQ affinity vs. MTRRs, was Re: 36 bit MTRRs, Re: test10-pre1 problems on 4-way SuperServer8050
Boszormenyi Zoltan <[EMAIL PROTECTED]> writes: > I came up with an idea. The MTRRs are per-cpu things. > Ingo Molnar's IRQ affinity code helps binding certain > IRQ sources to certain CPUs. They are implemented as per-cpu things but the Intel manuals say that all cpus should have the same MTRR settings. They also give pseudo-code for how to update them on an SMP system, which mtrr.c follows. If the BIOS has set them up differently at boot time, mtrr.c will complain and copy the MTRR settings of CPU0 to the others. Regards, David Wragg - 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: test10-pre1 problems on 4-way SuperServer8050
On 12 Oct 2000, David Wragg wrote: > Ok. I'll wait for feedback from Tigran, and if I don't get anything > negative I'll submit to Linus. The 2.2 version of my patch fixes > problems for other people, VA Linux have included it in their kernel > for a while with no problems that have been reported back to me), and > it's silly that it isn't in 2.4testX. I should have addressed this a > while ago, but I have my own distractions from kernel hacking. > > Later on, you can send a mtrr.c maintenance patch, if you like. > > I've just caught up on this whole thread, and I don't have any > objections in principle to Zoltan's patch being used instead of mine, > though I'd like to take a look at it first. David, sorry I didn't know that your patch is fundamentally different from Zoltan's. I will now re-test with your patch and see if it makes my eepro100 "instabilities" go away. The performance problems went away as I said earlier, by fiddling with cache settings in the BIOS. (with and without Zoltan's patch my machine is now as fast as it can be) Regards, Tigran - 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: BIG problem with BusLogic SCSI and/or something else
On Thu, 12 Oct 2000, Guest section DW wrote: > On Wed, Oct 11, 2000 at 05:11:39PM -0400, Richard B. Johnson wrote: > > > Linux version 2.2.17 > > I tried to add a new Hard disk. It's s Seagate ST39102LW 8.1 Gb. > > Hmm. Your C/H/S multiplies out to 9.1 GB. > On the other hand, Seagate ST39102LW has 9105018880 bytes, > so probably the 8 was a typo (and you are wasting 7859200 bytes). > The device reports 8.7 Gb. scsi: * BusLogic SCSI Driver Version 2.1.15 of 17 August 1998 * scsi: Copyright 1995-1998 by Leonard N. Zubkoff <[EMAIL PROTECTED]> scsi0: Configuring BusLogic Model BT-958 PCI Wide Ultra SCSI Host Adapter scsi0: Firmware Version: 5.06J, I/O Address: 0xB800, IRQ Channel: 11/Level scsi0: PCI Bus: 0, Device: 12, Address: 0xDF00, Host Adapter SCSI ID: 7 scsi0: Parity Checking: Enabled, Extended Translation: Enabled scsi0: Synchronous Negotiation: UUF#, Wide Negotiation: Enabled scsi0: Disconnect/Reconnect: Enabled, Tagged Queuing: Enabled scsi0: Scatter/Gather Limit: 128 of 8192 segments, Mailboxes: 211 scsi0: Driver Queue Depth: 211, Host Adapter Queue Depth: 192 scsi0: Tagged Queue Depth: Automatic, Untagged Queue Depth: 3 scsi0: Error Recovery Strategy: Default, SCSI Bus Reset: Enabled scsi0: SCSI Bus Termination: Both Disabled, SCAM: Disabled scsi0: *** BusLogic BT-958 Initialized Successfully *** scsi0 : BusLogic BT-958 scsi : 1 host. Vendor: SEAGATE Model: ST32171W Rev: 0484 Type: Direct-Access ANSI SCSI revision: 02 Vendor: Quantum Model: XP32150W Rev: L912 Type: Direct-Access ANSI SCSI revision: 02 Vendor: SEAGATE Model: ST34573W Rev: 5698 Type: Direct-Access ANSI SCSI revision: 02 Vendor: EXABYTE Model: EXB-82058VQANXR1 Rev: 07T0 Type: Sequential-Access ANSI SCSI revision: 02 Vendor: YAMAHAModel: CRW6416S Rev: 1.0b Type: CD-ROM ANSI SCSI revision: 02 Vendor: SEAGATE Model: ST39102LW Rev: 0005 Type: Direct-Access ANSI SCSI revision: 02 scsi0: Target 0: Queue Depth 28, Wide Synchronous at 40.0 MB/sec, offset 15 scsi0: Target 1: Queue Depth 28, Wide Synchronous at 20.0 MB/sec, offset 15 scsi0: Target 2: Queue Depth 28, Wide Synchronous at 40.0 MB/sec, offset 15 scsi0: Target 3: Queue Depth 3, Synchronous at 5.00 MB/sec, offset 11 scsi0: Target 4: Queue Depth 3, Synchronous at 10.0 MB/sec, offset 15 scsi0: Target 6: Queue Depth 28, Wide Synchronous at 20.0 MB/sec, offset 15 Detected scsi disk sda at scsi0, channel 0, id 0, lun 0 Detected scsi disk sdb at scsi0, channel 0, id 1, lun 0 Detected scsi disk sdc at scsi0, channel 0, id 2, lun 0 Detected scsi disk sdd at scsi0, channel 0, id 6, lun 0 SCSI device sda: hdwr sector= 512 bytes. Sectors= 4194057 [2047 MB] [2.0 GB] Partition check: sda: sda1 sda2 < sda5 > SCSI device sdb: hdwr sector= 512 bytes. Sectors= 4406960 [2151 MB] [2.2 GB] sdb: sdb1 sdb2 SCSI device sdc: hdwr sector= 512 bytes. Sectors= 924 [4340 MB] [4.3 GB] sdc: sdc1 sdc2 sdc3 SCSI device sdd: hdwr sector= 512 bytes. Sectors= 17783240 [8683 MB] [8.7 GB] sdd: sdd1 sdd2 sdd3 Note that the sync-rate of target 6, the device I added, has been turned down to try to eliminate any hardware problems. Also note that the entire drive has been read/written with the BusLogic BIOS diagnostic setup utility. > > In the BIOS setup of the BusLogic adapter, I was able to format > > and verify the disk with no problems whatsoever. > > > > fdisk seemed to work okay. I made partitions. > > mke2fs would fail (hang the system) while writing inodes. > > The BusLogic driver would complain about "Aborting SCSI host 0 channel 0, > > pid 84446". > > > > This can't be a pid --anyway. > > A SCSI one, not a Unix one. > > But you omit the interesting part. > SCSI drivers tend to give a reason, say timeout, or medium error, whatever. > What was the precise error message? > No. There are no logs after the "Aborting" messages. There is nothing written to any hard disks as a record even of the first message. The only messages on the console are the "aborted" messages, not even a "timeout" or any other such. Further, the messages run so fast that I had to take a scope camera photo at 1/1000th sec to figure out what they said. > In such cases what fdisk or fsck or so say is hardly of any interest. > One wants the kernel messages. Literally. > Says who? Some versions are incompatible with kernel changes. > > When the BusLogic driver was going through its hour-long fits of > > resetting the bus, > > Yes, Linux SCSI error recovery behaviour is not a pleasure to behold. > Some aspects of it are better in 2.4, however. > - Cheers, Dick Johnson Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual e
Re: test10-pre1 problems on 4-way SuperServer8050
Richard Gooch <[EMAIL PROTECTED]> writes: > David Wragg writes: > > mtrr.c is broken for machines with >=4GB of memory (or less than 4GB, > > if the chipset reserves an addresses range below 4GB for PCI). > > > > The patch against 2.4.0-test9 to fix this is below. > > > > Richard: Is there a reason you haven't passed this on to Linus, or do > > you want me to do it? > > Partly because I haven't had time to look at it, partly because I'm > not sure if it's needed (why, exactly?) Because mtrr.c throws away the top 4 bits of 36-bit physical addresses, it gives misleading /proc/mtrr output on machines with >=4GB of memory, which I think requires a fix on its own. But worse, if it tries to make MTRR changes on such a machine, you can get bogus MTRR settings. This can ruin a machine's performance (if real memory ends up write combined or uncached) or give hardware instabilities (if a device's MMIO area gets the wrong memory type). So far, this probably hasn't bitten too many people, since relatively few Linux x86 users have >=4GB memory, and /proc/mtrr hasn't usually been altered without explicit intervention. But with XFree86-4 finally "out there" and more kernel drivers using MTRRs, this can only get worse. (Whether Tigran's performance problems are actually down to the mtrr.c issue, I don't know. It's not worth hypothesizing until we have accurate /proc/mtrr output.) When I checked the 2.2 version of my patch, it didn't involve a significant increase in code size. > and partly because I've > recently moved house and (STILL!) don't have IP access at home (not > even dialup) so I can't really look at stuff yet Ok. I'll wait for feedback from Tigran, and if I don't get anything negative I'll submit to Linus. The 2.2 version of my patch fixes problems for other people, VA Linux have included it in their kernel for a while with no problems that have been reported back to me), and it's silly that it isn't in 2.4testX. I should have addressed this a while ago, but I have my own distractions from kernel hacking. Later on, you can send a mtrr.c maintenance patch, if you like. I've just caught up on this whole thread, and I don't have any objections in principle to Zoltan's patch being used instead of mine, though I'd like to take a look at it first. Regards, David - 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: [fixed (well, it works)]Re: test10-pre1 problems on 4-waySuperServer8050
Hi, Having done a few more reboots I got more info -- one of the eepro100 interfaces is dead only in 4 out 5 cases. So, sometimes, doing ifdown eth0 ; ifup eth0 does help. So, the latest status: all 6G of RAM work fast but the onboard eepro100 interface, often, doesn't work. This starts to look like eepro100-driver related so I copied Andrey Savochkin. Btw, one of my colleagues also reported a similar situation on his quad Xeon with 6G RAM whereby one of the eepro100 interfaces was dead until one restarts it. Starting to fiddle with eepro100.c now... Regards, Tigran - 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: Updated 2.4 TODO List -- new addition WAS(test9 PCI
On Thu, Oct 12, 2000 at 06:26:57AM -0400, Horst von Brand wrote: > [EMAIL PROTECTED] said: > > Foolhardy as it may be, people do _use_ the operating system to run > > important applications and an "application goes down or screws up" can be > > quite serious. > > Yes. But "the kernel screws up and crashes" is more serious, as it takes > _all_ applications with it. And if it is "screws up and scribbles on de > disks" the losses are even much more serious. Really? More serious than a multithreaded data base failing to synchronize as promised? Get real. You can't do this type of ranking. If the compiler is bad, the entire system is a joke. Users don't care whether the accounting system fails and the telephone stops working because of a compiler error or a kernel crash. > -- > Horst von Brand [EMAIL PROTECTED] > Casilla 9G, Vin~a del Mar, Chile +56 32 672616 -- - Victor Yodaiken Finite State Machine Labs: The RTLinux Company. www.fsmlabs.com www.rtlinux.com - 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: Updated 2.4 TODO List - more on PCI resources...]
Linus Torvalds wrote: > > On Wed, 11 Oct 2000, Dag B wrote: > > [snip] > > Expansion ROM at 1800 [disabled] [size=32M] > > Capabilities: [dc] Power Management version 1 > > There's something really wrong going on with your ethernet controller. It > seems to try to take up all available space. > > Please add a debug printk() to drivers/pci/setup-res.c to the very end of Linus, I realized there was one more test to do before deeming the hardware sane. PCMCIA (16-bit) in my laptop is tested and works fine with three different types of cards. Another Xircom card behaved just the same (non-functional) in my latop. My Xircom card was tested in another laptop and found working. Today I took my card *and* disk and tested it in an identical laptop. It works. So it appears that the *cardbus* logic is broken on my machine. Plain, old hardware defect. And I have been wasting your time. Sorry about that. In any case, debug output follows for both the non-working and the working case. Feel free to pin-point the hw-bug or flat out ignore it. Thanks, Dag B Non-working case: [] PCI: Using configuration type 1 PCI: Probing PCI hardware Scanning bus 00 Found 00:00 [8086/7190] 000600 00 Found 00:08 [8086/7191] 000604 01 Found 00:18 [104c/ac1c] 000607 02 Found 00:19 [104c/ac1c] 000607 02 Found 00:38 [8086/7110] 000680 00 Found 00:39 [8086/7111] 000101 00 PCI: IDE base address fixup for 00:07.1 Found 00:3a [8086/7112] 000c03 00 Found 00:3b [8086/7113] 000680 00 Found 00:68 [10b7/9050] 000200 00 Fixups for bus 00 PCI: Scanning for ghost devices on bus 0 Scanning behind PCI bridge 00:01.0, config 010100, pass 0 Scanning bus 01 Found 01:00 [10c8/0005] 000300 00 Found 01:01 [10c8/8005] 000401 00 Fixups for bus 01 PCI: Scanning for ghost devices on bus 1 Bus scan for 01 returning with max=01 Scanning behind PCI bridge 00:03.0, config 00, pass 0 Scanning behind PCI bridge 00:03.1, config 00, pass 0 Scanning behind PCI bridge 00:01.0, config 010100, pass 1 Scanning behind PCI bridge 00:03.0, config 00, pass 1 Scanning behind PCI bridge 00:03.1, config 00, pass 1 Bus scan for 00 returning with max=09 PCI: IRQ init PCI: Interrupt Routing Table found at 0xc00fbda0 00:07 slot=00 0:00/ 1:00/ 2:00/ 3:63/def8 01:00 slot=00 0:60/def8 1:61/def8 2:00/ 3:00/ 00:03 slot=00 0:63/def8 1:63/def8 2:00/ 3:00/ 00:0d slot=00 0:62/def8 1:00/ 2:00/ 3:00/ 00:11 slot=00 0:62/def8 1:62/def8 2:62/def8 3:62/def8 PCI: Bus 01 already known PCI: Using IRQ router default [8086/1234] at 00:07.0 PCI: IRQ fixup PCI: Allocating resources PCI: Resource f400-f7ff (f=1208, d=0, p=0) PCI: Resource 0860-086f (f=101, d=0, p=0) PCI: Resource ece0-ecff (f=101, d=0, p=0) PCI: Resource ec80-ecbf (f=101, d=0, p=0) PCI: Resource f900-f9ff (f=1208, d=0, p=0) PCI: Resource fdc0-fdff (f=200, d=0, p=0) PCI: Resource fdb0-fdbf (f=200, d=0, p=0) PCI: Resource f8c0-f8ff (f=1208, d=0, p=0) PCI: Resource fda0-fdaf (f=200, d=0, p=0) bus res 0 100 - bus res 1 200 - bus res 0 100 - bus res 1 200 - bus res 0 100 - bus res 1 200 - device 3Com Corporation 3c905 100BaseTX [Boomerang] resource 6 size 0001 bus res 0 100 - bus res 1 200 - Limiting direct PCI/PCI transfers. [] cs: cb_alloc(bus 6): vendor 0x115d, device 0x0003 Found 06:00 [115d/0003] 000200 00 bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 2 100 1800-18ff bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 2 100 1800-18ff bus res 3 100 1c00-1cff device PCI device 115d:0003 resource 1 size 04000800 PCI: Failed to allocate resource 1 for PCI device 115d:0003 bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 2 100 1800-18ff bus res 3 100 1c00-1cff device PCI device 115d:0003 resource 2 size 04000800 PCI: Failed to allocate resource 2 for PCI device 115d:0003 bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 2 100 1800-18ff bus res 3 100 1c00-1cff device PCI device 115d:0003 resource 6 size 04004000 bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 2 100 1800-18ff bus res 3 100 1c00-1cff device PCI device 115d:0003 resource 6 size 04004000 PCI: Failed to allocate resource 6 for PCI device 115d:0003 PCI: Enabling device 06:00.0 ( -> 0003) Found 06:01 [115d/0103] 000300 00 bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 2 100 1800-18ff bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 2 100 1800-18ff bus res 3 100 1c00-1cff device PCI device 115d:0103 resource 1 size 04000800 PCI: Failed to allocate resource 1 for PCI device 115d:0103 bus res 0 1200 1c00-1fff bus res 1
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
On Thu, 12 Oct 2000 [EMAIL PROTECTED] wrote: > * DMFE is not SMP safe (Frank Davis patch exists, but hasn't gotten >much commens yet) Can anyone tell me where to get this patch? I've got a DM9102A card in a SMP machine currently on which it can be tested. David Huen - 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: Updated Linux 2.4 Status/TODO List (from the ALS show)
On Thu, Oct 12 2000, [EMAIL PROTECTED] wrote: > 8. Fix Exists But Isnt Merged > * TLAN nic appears to be adding a timer twice (2.4.0test8pre6, Arjan >ve de Ven) (Fixed, but patch not sent to Linus yet -- Torben >Mathiasen) > * Loading the qlogicfc driver in 2.4.0-test8 causes the kernel to >loop forver reporting SCSI disks that aren't present (Paul >Hubbard, Torben Mathiasen has a potential patch, sent to Linus, >need to very with Paul) These two have been merged. -- Torben Mathiasen <[EMAIL PROTECTED]> Linux ThunderLAN maintainer http://tlan.kernel.dk - 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.17 Crash
On Thu, 12 Oct 2000, Andrea Arcangeli wrote: > On Wed, Oct 11, 2000 at 03:35:40PM -0200, Marcelo Tosatti wrote: > > Now I'm not sure if this can be caused by a memory problem. > > It can. Ok, thanks. Mike, could you try to run memtest86 (you can find it at freshmeat) to find out if your problem is memory? - 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/
[fixed (well, it works)]Re: test10-pre1 problems on 4-way SuperServer8050
Hello, Ok, I despaired a bit about mtrrs on the Linux side and went into BIOS and started playing with the cache settings there. The change that fixed the problem was to disable all "area CXXX-> : cached". Now, I have a really fast quad Xeon 6G RAM with consistently failing eepro100 interface. Downing/upping the interface does not help. I suppose in this state it is easier to debug because everything else is fully functional -- let's just find out why this particular eepro100 doesn't work. Kernel compiles in 54-60 seconds -- very impressive (I am talking about full make -j4 bzImage after make clean) Now, this is with and without Zoltan's big-mtrr patch, just verified a minute ago. Regards, Tigran - 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/
Updated Linux 2.4 Status/TODO List (from the ALS show)
OK, here's an updated Linux 2.4 TODO list. It's actually somewhat up
to date as for test10-pre1, but there a bunch of test10-pre1 bug reports
that defied easy categoricalization (i.e., real bug vs. PEBCAK) so I've
left the offical page as saying that it's hopefully up-to-date as of
pre9. Certainly it's much more uptodate than the one posted earlier
this week, especially as far as the "USB:" items are concerned (thanks
Randy Dunlap and all of the other folks on the USB development list for
updating me with a list of USB bugs).
- Ted
Linux 2.4 Status/TODO Page
This list is almost always out of date, by definition, since kernel
development moves so quickly. I try to keep it as up to date as
possible, though. Please send updates to [EMAIL PROTECTED]
Every few days or so, I periodically send updated versions of this
list to the linux-kernel list, but you should consult
http://linux24.sourceforge.net to get the latest information.
If you're curious to see what has changed recently, check out
http://linux24.sourceforge.net/status-changes.html. The previous set
of changes can be found here. Also, this html file is managed under
CVS at SourceForge.
I try to keep e-mail addresses out of this document, since I don't
want to make life easy for bottom-feeder spam artists. If you are a
developer and want to contact the person who originally reported the
problem, or want to see the e-mail message which prompted me to
include a bug/issue in this list, contact me. I keep an mail archive
which will have that information assuming it was an item added since I
took over the list from Alan.
Last modified: [tytso:20001012.0802EDT]
Hopefully up to date as of: test9
1. Should Be Fixed (Confirmation Wanted)
* Fbcon races (cursor problems when running continual streaming
output mixed with printk + races when switching from X while doing
continuous rapid printing --- Alan)
* USB: hotplug (PNP) and module autoloader support (currently being
tested)
* USB: OHCI root-hub-timer does not restart on resume {CRITICAL}
(Paul Mackerras)
* USB: add bandwidth allocation support to usb-uhci HCD
* USB: usb-ohci needs to null urb->dev to avoid various
reboots/hangs/oopses {CRITICAL} (David Brownell)
* USB: speed up device enumeration (hub driver has large delays in
it)
2. Capable Of Corrupting Your FS/data
* Use PCI DMA by default in IDE is unsafe (must not do so on via
VPx, x < 3) (Vojtech Pavlik --- requires chipset tuning to be
enabled according to Andre Hedrick --- we need to turn this on by
default, if it is safe -- TYT)
* Non-atomic page-map operations can cause loss of dirty bit on
pages (sct, alan, Ben LaHaise has fix, not yet merged)
* USB: Problems with USB storage drives (ORB, maybe Zip) during APM
sleep/suspend
3. Security
* Fix module remove race bug (still to be done: TTY, ldisc, I2C,
video_device - Al Viro) (Rogier Wolff will handle ATM)
4. Boot Time Failures
* Use PCI DMA 'lost interrupt' problem with PIIXn tuning enabled
will hang laptop requiring physical power loss to restart (NEC
Versa LX, 2.3.x to 2.4.0-test8-pre6, David Ford) (Vojtech Pavlik
is looking at this)
* Crashes on boot on some Compaqs ? (may be fixed)
* Various Alpha's don't boot under 2.4.0-test9 (PCI resource
allocation problem? Michal Jaegermann; Richard Henderson may have
an idea what's failing.)
* Palmax PD1100 hangs during boot since 2.4.0-test9 (Alan Cox)
* Compaq proliant 7000 (with Compaq Smart Array-3100ES) hangs during
2.4.0-test9. Likely related to the Raid driver given where it hung
in the boot messages (chonga at isoft)
5. Compile errors
6. In Progress
* Restore O_SYNC functionality (Stephen) - core code and ext2 done
* Fix all remaining PCI code to use pci_enable_device (mostly done)
* Finish the audit/code review of the code dealing with descriptor
tables. (Al Viro)
* DMFE is not SMP safe (Frank Davis patch exists, but hasn't gotten
much commens yet)
* Audit all char and block drivers to ensure they are safe with the
2.3 locking - a lot of them are not especially on the
read()/write() path. (Frank Davis --- moving slowly; if someone
wants to help, contact Frank)
* Fixing autofs4 to deal with VFS changes (Jeremy Fitzhardinge)
7. Obvious Projects For People (well if you have the hardware..)
* Make syncppp use new ppp code
* Fix SPX socket code
8. Fix Exists But Isnt Merged
* Update SGI VisWS to new-style IRQ handling (Ingo)
* Support MP table above 1Gig (Ingo)
* Dont panic on boot when meeting HP boxes with wacked APIC table
numbering (AC)
* Scheduler bugs in RT (Dimitris)
* AIC7xxx does
Re: test10-pre1 problems on 4-way SuperServer8050
On Thu, 12 Oct 2000 12:56:09 +0100 (BST), Tigran Aivazian <[EMAIL PROTECTED]> wrote: >one correction -- it was "down and up the interface" that did the trick >and not deleting the 64M mtrr entry. I.e. the eepro100 problem is better >formulated as "when highmem is enabled one or both eepro100 interfaces >sometimes do not work from boot but downing/upping the interface usually >helps". When highmem is disabled, so far, _both_ eepro100 interfaces >_always_ work on boot. That may only be coincidence. We have intermittent problems with eepro100 under 2.4.0-testx, both ix86 and ia64. The symptoms are "card reports no resources" messages; down and up the interface and it usually works. - 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: test10-pre1 problems on 4-way SuperServer8050
On Thu, 12 Oct 2000, Tigran Aivazian wrote: > On Thu, 12 Oct 2000, Tigran Aivazian wrote: > > > On Wed, 11 Oct 2000, Linus Torvalds wrote: > > > What happens if MTRR support is entirely disabled? > > > > If MTRR support is disabled then both eepro100 interfaces work fine but > > the system is still 40x slower. This is the entire bootlog of > > 2.4.0-test10-pre1 + lspci-vvx + /proc/interrupts + /proc/iomem + ifconfig > > output > > one more finding -- deleting the strange 64M mtrr entry enabled the second > eepro100 interface! > > # cat /proc/mtrr > reg00: base=0x001 (4096MB), size=2048MB: write-combining, > count=1 > reg02: base=0xfc00 (4032MB), size= 64MB: uncachable, count=1 > # > # echo "disable=2" > /proc/mtrr > # cat /proc/mtrr > reg00: base=0x001 (4096MB), size=2048MB: write-combining, > count=1 > > (now down and up the interface and it works. Both eepro100 work) one correction -- it was "down and up the interface" that did the trick and not deleting the 64M mtrr entry. I.e. the eepro100 problem is better formulated as "when highmem is enabled one or both eepro100 interfaces sometimes do not work from boot but downing/upping the interface usually helps". When highmem is disabled, so far, _both_ eepro100 interfaces _always_ work on boot. Regards, Tigran - 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: 36 bit MTRRs, Re: test10-pre1 problems on 4-way SuperServer8050
On Thu, 12 Oct 2000, Boszormenyi Zoltan wrote: > On Thu, 12 Oct 2000, Boszormenyi Zoltan wrote: > > > echo "base=0 size=0x1 type=write-back" >/proc/mtrr > > echo "base=0x1 size=0x8000 type=write-back" >/proc/mtrr > > echo "base=0xfe00 size=0x80 type=write-combining" >/proc/mtrr > > echo "base=0xfde0 size=0x10 type=uncached" >/proc/mtrr > > echo "base=0xfe80 size=0x10 type=uncached" >/proc/mtrr > > echo "base=0xfe9ed000 size=0x1000 type=uncached" >/proc/mtrr > > echo "base=0xfe9ee000 size=0x2000 type=uncached" >/proc/mtrr > > echo "base=0xfeafe000 size=0x2000 type=uncached" >/proc/mtrr > > Sorry, use 'uncachable' instead of 'uncached'. :-( ok, doing it from the bottom up was fine (didn't lockup) but reaching the last (first in your list) entry was refused by mtrr: mtrr: 0x0,0x1 overlaps existing 0xfeafe000,0x2000 # cat /proc/mtrr reg00: base=0xfeafe000 (4074MB), size= 0kB: uncachable, count=1 reg01: base=0xfe9ee000 (4073MB), size= 0kB: uncachable, count=1 reg02: base=0xfe9ed000 (4073MB), size= 0kB: uncachable, count=1 reg03: base=0xfe80 (4072MB), size= 1MB: uncachable, count=1 reg04: base=0xfde0 (4062MB), size= 1MB: uncachable, count=1 reg05: base=0xfe00 (4064MB), size= 8MB: write-combining, count=1 reg06: base=0x001 (4096MB), size=2048MB: write-back, count=1 and machine is still slow. So, what is the correct way to cover the 6G by some mtrrs? I will now try to disable or change strategy of L2 caching in BIOS and see if it makes things worse. Regards, Tigran - 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: 0 size files in linux-2.2.17.tar.gz
On Thu, Oct 12, 2000 at 03:58:21AM -0700, Amit D Chaudhary wrote: > Hi, > > When trying to create a patch with linux 2.2.17 sources, I found the > following files to be of size 0 in linux-2.2.17.tar.gz. > linux/include/linux/dasd.h > linux/include/linux/coda_opstats.h > > Since the file is the most latest in the kernel/v2.2 directory, thought > should point this out. Your kernel was probably patched te become a 2.2.17. The "problem" is diff. It can - add lines - remove lines - add files but it *cannot remove files. The only way to "remove" a file is to delete all ist contents, but the (empty) file remains... MfG, JBG -- Fehler eingestehen, Größe zeigen: Nehmt die Rechtschreibreform zurück!!! /* Jan-Benedict Glaw <[EMAIL PROTECTED]> -- +49-177-5601720 */ keyID=0x8399E1BB fingerprint=250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB "insmod vi.o and there we go..." (Alexander Viro on linux-kernel) PGP signature
Re: [RFC] atomic pte updates for x86 smp
On Thu, 12 Oct 2000, Ingo Molnar wrote: > [...] pgd_clear() should stay a 64-bit operation [...] even this isnt strictly necessery - pgds and pmds are allocated in 'low memory', and thus a simple 32-bit write to the lower 32 bits of the pgd entry is enough to clear a PAE pgd. But it still must be a special case due to the pgd present-bit restriction. Ingo - 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: 0 size files in linux-2.2.17.tar.gz
Hi, When trying to create a patch with linux 2.2.17 sources, I found the following files to be of size 0 in linux-2.2.17.tar.gz. linux/include/linux/dasd.h linux/include/linux/coda_opstats.h Since the file is the most latest in the kernel/v2.2 directory, thought should point this out. Amit - 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/
No Subject
Hi,
This patch will make the sx card work again. Somehow the added line was
removed in the last patch.
Patrick
diff -u -r --new-file linux-2.2.18-15.clean/drivers/char/sx.c
linux-2.2.18-15.sx/drivers/char/sx.c
--- linux-2.2.18-15.clean/drivers/char/sx.c Thu Oct 12 10:39:33 2000
+++ linux-2.2.18-15.sx/drivers/char/sx.cThu Oct 12 10:47:12 2000
@@ -2523,6 +2523,7 @@
else
pci_read_config_dword(pdev, PCI_BASE_ADDRESS_2,
&tint);
+ board->hw_base = tint & PCI_BASE_ADDRESS_MEM_MASK;
board->base2 =
board->base = (ulong) ioremap(board->hw_base, WINDOW_LEN
(board));
if (!board->base) {
-
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: want tool to open RPM package on Window 95
Michal Jaegermann writes:
> > Somewhere floating around there is a perl version of rpm2cpio.
>
> This is what I wrote one day a long time ago:
>
> #!/usr/bin/perl -w
> use strict;
>
> my ($buffer, $pos, $gzmagic);
> $gzmagic = "\037\213";
> open OUT, "| gunzip" or die "cannot find gunzip; $!\n";
> while(1) {
> exit 1 unless defined($pos = read STDIN, $buffer, 8192) and $pos > 0;
> next unless ($pos = index $buffer, $gzmagic) >= 0;
> print OUT substr $buffer, $pos;
> last;
> }
> print OUT ;
> exit 0;
>
> Yes, I know that I should not mix 'read' with stdio but it worked
> every time I tried the above. :-)
The good news is that "read" does use stdio (along with seek and print).
The syscall ones are sys{read,write,seek}. The less good news is that
your "print OUT " sucks up all the RPM file into memory before
dumping it out again which is inelegant and leads those who copy the
idiom without understanding it to run into problems when they use
similar code on large files. One way of doing it a bit differently is
#!/usr/bin/perl
die "Usage: rpm2cpio foo.rpm | cpio ...\n" unless @ARGV == 1;
open(RPM, $ARGV[0]) or die "$ARGV[0]: $!\n";
open(STDOUT, "| gunzip") or die "cannot find gunzip: $!\n";
while (read(RPM, $_, 8192)) {
if (!$found_gzmagic) {
s/^.*?(?=\037\213)//s or next;
$found_gzmagic = 1;
}
print;
}
> Can we go back now to kernel issues?
Oops, yes, we now return you to your regularly scheduled kgcc wars.
--Malcolm
--
Malcolm Beattie <[EMAIL PROTECTED]>
Unix Systems Programmer
Oxford University Computing Services
-
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: Updated 2.4 TODO List -- new addition WAS(test9 PCI
[EMAIL PROTECTED] said: > On Wed, Oct 11, 2000 at 11:21:06PM -0400, Horst von Brand wrote: > > also moves forward a lot faster than glibc, and grows a lot. A bug in glibc > > means an application goes down or screws up, a bug in the kernel can mean > > masive data loss in no time at all. > Foolhardy as it may be, people do _use_ the operating system to run > important applications and an "application goes down or screws up" can be > quite serious. Yes. But "the kernel screws up and crashes" is more serious, as it takes _all_ applications with it. And if it is "screws up and scribbles on de disks" the losses are even much more serious. -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9 + Winchip2/2A processor family == hang on boot
On Thu, 12 Oct 2000, Keith Owens wrote: > Sounds like you got caught by the conditional move instruction that is > generated for 686. It causes oops on 586, and somewhere in the oops or > printk code you hit another cmove. Double fault, kernel hang. Ah yes, it all comes back to me now :) Also explains why my printk's weren't working during tests. I'm amazed it took this long for someone to notice. :) I'll have to start running devel kernels on all the funky hardware like Winchip. Mine has been running 2.2 (where this isn't an issue) for a long time. regards, d. -- | Dave Jones <[EMAIL PROTECTED]> http://www.suse.de/~davej | SuSE Labs - 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: 36 bit MTRRs, Re: test10-pre1 problems on 4-waySuperServer8050
On Thu, 12 Oct 2000, Tigran Aivazian wrote: > > On Thu, 12 Oct 2000, Boszormenyi Zoltan wrote: > > > > > echo "base=0 size=0x1 type=write-back" >/proc/mtrr > > this line immediately locks up the machine. But I want to understand where We just shared an experience. :-( This is what I wrote some lines later. Will you please set the uncached areas first? And do not forget the last echo line I wrote. > did you get base=0 and size=0x1 from? Shouldn't it be > base=0x10 and size=0xfccf according to this entry from e820: > > BIOS-e820: fccf @ 0010 (usable) Yes, this is (4GB - whatever MB) starting at 1MB: upper 15MB of zone(0) + zone(1) + lower ~3GB of zone(2). The mtrr driver correctly complains when you try to set it exactly this way because the MTRRs base must be on size boundary. That's why I collected the real memory areas and the should-be-uncached PCI areas. Regards, Zoltan Boszormenyi - 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: IRQ affinity vs. MTRRs, was Re: 36 bit MTRRs, Re: test10-pre1 problems on 4-way SuperServer8050
On Thu, Oct 12, 2000 at 12:12:19PM +0200, Boszormenyi Zoltan wrote: > I came up with an idea. The MTRRs are per-cpu things. > Ingo Molnar's IRQ affinity code helps binding certain > IRQ sources to certain CPUs. > > What if the MTRR driver allows per-CPU settings, maybe only on > uncached areas? Of course the real memory should be cached in > every CPU to avoid slowdowns. So that if you set that eth0's > IRQ will be handled by CPU1, the MTRRs of CPU1 will be set > accordingly, and the other CPUs will not care about eth0, > so they do not need eth0's MTRR settings. A little question. Why do we want to bind irq of eth0 to a single CPU ? imho it will casue slowdown of some situation. Why don't we leave scheduler to select CPU for processing IRQ ? - Gabor - 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/
IRQ affinity vs. MTRRs, was Re: 36 bit MTRRs, Re: test10-pre1problems on 4-way SuperServer8050
I came up with an idea. The MTRRs are per-cpu things. Ingo Molnar's IRQ affinity code helps binding certain IRQ sources to certain CPUs. What if the MTRR driver allows per-CPU settings, maybe only on uncached areas? Of course the real memory should be cached in every CPU to avoid slowdowns. So that if you set that eth0's IRQ will be handled by CPU1, the MTRRs of CPU1 will be set accordingly, and the other CPUs will not care about eth0, so they do not need eth0's MTRR settings. Tell me if this is a highly stupid idea. :-) Regards, Zoltan Boszormenyi - 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: BIG problem with BusLogic SCSI and/or something else
On Thu, 12 Oct 2000 00:24:51 +0200, Guest section DW blurted forth: > On Wed, Oct 11, 2000 at 05:11:39PM -0400, Richard B. Johnson wrote: > > > In the BIOS setup of the BusLogic adapter, I was able to format > > and verify the disk with no problems whatsoever. > > > > fdisk seemed to work okay. I made partitions. > > mke2fs would fail (hang the system) while writing inodes. > > The BusLogic driver would complain about "Aborting SCSI host 0 channel 0, > > pid 84446". > > > > This can't be a pid --anyway. > > A SCSI one, not a Unix one. Which buslogic/mylex card is it? if it is a Flashpoint card, you might want to make sure you are NOT omitting flashpoint support in the config... just a small thought, sometimes the littlest things get in the way. :) -- .oO gnea at rochester dot rr dot com Oo. .oO url: http://garson.org/~gnea Oo. "You can tune a filesystem, but you can't tuna fish" -unknown - 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: 36 bit MTRRs, Re: test10-pre1 problems on 4-way SuperServer8050
> On Thu, 12 Oct 2000, Boszormenyi Zoltan wrote: > > > echo "base=0 size=0x1 type=write-back" >/proc/mtrr this line immediately locks up the machine. But I want to understand where did you get base=0 and size=0x1 from? Shouldn't it be base=0x10 and size=0xfccf according to this entry from e820: BIOS-e820: fccf @ 0010 (usable) Regards, Tigran - 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: [RFC] atomic pte updates for x86 smp
On Thu, 12 Oct 2000, David S. Miller wrote: >clear neither user-space pgds, nor user-space pmds in PAE mode > > Eh? > > munmap() --> clear_page_tables() --> free_one_pgd() --> pgd_clear you are right, i was focused too much on the swapping case. I dont think munmap() is a problem in the PAE case. pgd_clear() should stay a 64-bit operation (like in Ben's patch) because we could get a legitimate TLB flush between two 32-bit writes. (the 4 pgd entries are otherwise cached in the CPU core, only TLB flushes reload them.) Ingo - 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: test10-pre1 problems on 4-way SuperServer8050
On Thu, 12 Oct 2000 10:45:11 +0100 (BST), Tigran Aivazian <[EMAIL PROTECTED]> wrote: >It would be nice if /proc/mtrr showed eip of >the caller who set up the entry :) How? If you compile with egcs-2.91.66 without frame pointers on ix86 then __builtin_return_address() yields garbage. Does anybody have a generic solution to this problem, other than "compile with frame pointers"? Or is it fixed in newer versions of gcc? - 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: Updated 2.4 TODO List -- new addition WAS(test9 PCI
On Wed, 11 Oct 2000, Nathan Paul Simons wrote: > On Wed, Oct 11, 2000 at 10:55:17PM +0100, Alan Cox wrote: > > Hardly. In fact the idea of distributing a different compiler for kernels > > comes from debian and the kgcc naming convention from Conectiva. > > What different compiler? If you're talking about the kernel-package > package of Debian, that's only scripts to generate a Debian kernel package > from custom source. % dpkg-awk Package:gcc272 Package: gcc272 Status: install ok installed Priority: optional Section: devel Installed-Size: 1588 Maintainer: Debian GCC maintainers <[EMAIL PROTECTED]> Version: 2.7.2.3-15 Replaces: gcc (<= 2.7.2.3-7), cpp (<= 2.7.2.3-7) Provides: c-compiler Depends: libc6, binutils (>= 2.8-1) Recommends: libc-dev Suggests: gcc272-docs Conflicts: libc5-dev, gcc (<= 2.7.2.3-7), cpp (<= 2.7.2.3-7) Description: The GNU C compiler. This is the old version of the GNU C compiler's C part. It should only be used for backward compatibility purposes. . The GNU C compiler is a fairly portable optimizing compiler that supports multiple languages. It includes (runtime) support for C. The g++ and ObjC compilers are not longer part of the current Debian release. Get the packages from the Debian 2.1 (slink) release. % dpkg -l gcc gcc272 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii gcc2.95.2-13 The GNU C compiler. ii gcc272 2.7.2.3-15 The GNU C compiler. % Grep debian-devel for gcc272 - switching default gcc to egcs (early unstable for potato, March '99 IIRC) required that because quite a few things didn't build correctly with 2.91 (and later 2.95). OTOH C++ side sucked badly and newer versions were clearly better in that area. - 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: 36 bit MTRRs, Re: test10-pre1 problems on 4-waySuperServer8050
On Thu, 12 Oct 2000, Boszormenyi Zoltan wrote: > echo "base=0 size=0x1 type=write-back" >/proc/mtrr > echo "base=0x1 size=0x8000 type=write-back" >/proc/mtrr > echo "base=0xfe00 size=0x80 type=write-combining" >/proc/mtrr > echo "base=0xfde0 size=0x10 type=uncached" >/proc/mtrr > echo "base=0xfe80 size=0x10 type=uncached" >/proc/mtrr > echo "base=0xfe9ed000 size=0x1000 type=uncached" >/proc/mtrr > echo "base=0xfe9ee000 size=0x2000 type=uncached" >/proc/mtrr > echo "base=0xfeafe000 size=0x2000 type=uncached" >/proc/mtrr Sorry, use 'uncachable' instead of 'uncached'. :-( Regards, Zoltan Boszormenyi - 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: 36 bit MTRRs, Re: test10-pre1 problems on 4-waySuperServer8050
On Thu, 12 Oct 2000, Tigran Aivazian wrote: > suggestions? I looked at what you sent (e820 map and lspci output) and came up with this. Cover 6 GB with write-back, the VGA memory with write-combining, and all the other PCI areas as uncached. echo "base=0 size=0x1 type=write-back" >/proc/mtrr echo "base=0x1 size=0x8000 type=write-back" >/proc/mtrr echo "base=0xfe00 size=0x80 type=write-combining" >/proc/mtrr echo "base=0xfde0 size=0x10 type=uncached" >/proc/mtrr echo "base=0xfe80 size=0x10 type=uncached" >/proc/mtrr echo "base=0xfe9ed000 size=0x1000 type=uncached" >/proc/mtrr echo "base=0xfe9ee000 size=0x2000 type=uncached" >/proc/mtrr echo "base=0xfeafe000 size=0x2000 type=uncached" >/proc/mtrr Do not be bothered about the 640K-1MB area because this is handled by the so called fixed MTRRs, they are invisible in /proc/mtrr. It is possible that the above causes an (almost) immediate lockup because of this line: BIOS-e820: 0008 @ fff8 (reserved) These are most likely memory mapped registers of the mainboard chipset and I successfully locked up my home machine (ABit BP6, a BX mainboard) with covering all 4GB with either write-back or write-combining. (I do not remember which type it was.) Uncaching this area helped. So experiment with leaving out the VGA memory from the above lines and maybe the two 1MB areas (ethernet controllers' onboard memory?) and uncaching this area: echo "base=0xfff8 size=0x8 type=uncached" >/proc/mtrr Regards, Zoltan Boszormenyi - 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: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
[EMAIL PROTECTED] said: > The genuine Linux kernel distribution contains its own documentation > on how to build and configure it. Indeed it does. Documentation/Changes says: GCC --- You will need at least gcc 2.7.2 to compile the kernel. You currently have several options for gcc-derived compilers: gcc 2.7.2.3, various versions of egcs, the new gcc 2.95 and upcoming gcc 3.0, and experimental compilers like pgcc. For absolute stability, it is still recommended that gcc 2.7.2.3 be used to compile your kernel. egcs 1.1.2 should also work. gcc 2.95 is known to have problems, and using pgcc for your kernel is just asking for trouble. > The kgcc story looks to me like a lie from RedHat. In my opinion, they > just don't want to recognize that they have been loose. $ kgcc -v Reading specs from /usr/lib/gcc-lib/i386-glibc21-linux/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) Looks true to me. -- dwmw2 - 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: test10-pre1 problems on 4-way SuperServer8050
On Thu, 12 Oct 2000, Tigran Aivazian wrote: > On Wed, 11 Oct 2000, Linus Torvalds wrote: > > What happens if MTRR support is entirely disabled? > > If MTRR support is disabled then both eepro100 interfaces work fine but > the system is still 40x slower. This is the entire bootlog of > 2.4.0-test10-pre1 + lspci-vvx + /proc/interrupts + /proc/iomem + ifconfig > output one more finding -- deleting the strange 64M mtrr entry enabled the second eepro100 interface! # cat /proc/mtrr reg00: base=0x001 (4096MB), size=2048MB: write-combining, count=1 reg02: base=0xfc00 (4032MB), size= 64MB: uncachable, count=1 # # echo "disable=2" > /proc/mtrr # cat /proc/mtrr reg00: base=0x001 (4096MB), size=2048MB: write-combining, count=1 (now down and up the interface and it works. Both eepro100 work) but the machine is still intolerably slow. Where did this 64M entry come from? (I don't have agp or drm support enabled or anything like that, I don't even have an agp bus!) It would be nice if /proc/mtrr showed eip of the caller who set up the entry :) Regards, Tigran - 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: [RFC] atomic pte updates for x86 smp
Date:Thu, 12 Oct 2000 10:13:48 +0200 (CEST) From: Ingo Molnar <[EMAIL PROTECTED]> the PAE pgd 'anomaly' should not affect this case, because we never clear neither user-space pgds, nor user-space pmds in PAE mode Eh? munmap() --> clear_page_tables() --> free_one_pgd() --> pgd_clear Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
cs46xx only works as a module - only outputs sound when pcm/dspis in use.
[Dan Aloni] > --- linux/drivers/sound/cs46xx.c Sat Oct 7 11:49:18 2000 > +++ linux/drivers/sound/cs46xx.c Wed Oct 11 07:41:02 2000 [...] > +#define DEBUG > + Note that for trivial, temporary cases like this it may be simpler to use a compiler flag: make modules CFLAGS_cs46xx.o=-DDEBUG Peter - 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/
UDP functions...
Hello, I'm a new entry in this kernel mailing list. I'm working on udp functions (those in ipv4/udp.c) and I'm focusing on "udp_sendmsg(..)" and "udp_recvmsg". I'm trying to understand what is the duty, what these next functions(used by udp_sendmsg and/or udp_recvmsg) really do: ip_cmsg_send ip_options_get ip_options_compile ip_route_output ip_route_output_slow ip_build_xmit I presume that they are IP functions (quite silly!) but I don't know what they do, what functions they use and if they are necessary for my purposes. I must get an udp packet from an input using directly udp_.. functions. My problem now is to try to understand how the engine works. I'm quite new to linux kernel programming. Many thanx to every one helps me. Mau Get your FREE web-based e-mail and newsgroup access at: http://MailAndNews.com Create a new mailbox, or access your existing IMAP4 or POP3 mailbox from anywhere with just a web browser. - 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: 36 bit MTRRs, Re: test10-pre1 problems on 4-way SuperServer8050
On Thu, 12 Oct 2000, Boszormenyi Zoltan wrote: > Look at the e820 map in the boot log, mark those areas > as write-back and tell me what happens. Here is e820 map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: 0002 @ 000e (reserved) BIOS-e820: fccf @ 0010 (usable) BIOS-e820: f000 @ fcdf (ACPI data) BIOS-e820: 1000 @ fcdff000 (ACPI NVS) BIOS-e820: 1000 @ fec0 (reserved) BIOS-e820: 1000 @ fee0 (reserved) BIOS-e820: 0008 @ fff8 (reserved) BIOS-e820: 8000 @ 0001 (usable) I can easily setup the mtrr entry for the top 2G: BIOS-e820: 8000 @ 0001 (usable) # cat /proc/mtrr reg00: base=0x001 (4096MB), size=2048MB: write-combining, count=1 reg02: base=0xfc00 (4032MB), size= 64MB: uncachable, count=1 but trying to do the same for the low 4G: BIOS-e820: fccf @ 0010 (usable) mtrr complains: # echo "base=0x10 size=0xfccf type=write-combining" > /proc/mtrr mtrr: base(0x10) is not aligned on a size(0xfccf) boundary suggestions? Regards, Tigran - 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: test10-pre1 problems on 4-way SuperServer8050
Hi, someone looked at the XEON errata already, perhaps one can find the problem there? Just in case. G16 seems to have something to do with it ... But there are others also. I´ll boot linux and look into the sources ... Cheers Markus Tigran Aivazian wrote: > On Wed, 11 Oct 2000, Linus Torvalds wrote: > > What happens if MTRR support is entirely disabled? > > If MTRR support is disabled then both eepro100 interfaces work fine but > the system is still 40x slower. This is the entire bootlog of > 2.4.0-test10-pre1 + lspci-vvx + /proc/interrupts + /proc/iomem + ifconfig > output > > Two currently active ideas (from Mark, Linus and Zoltan): > > a) one needs to use big-mtrr patch from Zoltan, look at e820 map and > manually set up mtrrs to cover all 6G. > > b) this is an L2 cache-tag issue and there is just not enough bits in the > tag to cover such high addresses so nothing will help, save removing the > extra 2G or so out of the machine (or using them as MTD devices : I > hope this is _not_ the case... > > another idea (in parallel) is that eepro100 stops working because its PCI > memory space is marked as cacheable. > > All should become clear soon -- I will spend the whole day on this, slowly > trying to understand what's going on. > > Regards, > Tigran > > Linux version 2.4.0-test9 (root@hilbert) (gcc version egcs-2.91.66 19990314/Linux >(egcs-1.1.2 release)) #15 SMP Wed Oct 11 19:23:15 BST 2000 > BIOS-provided physical RAM map: > BIOS-e820: 0009fc00 @ (usable) > BIOS-e820: 0400 @ 0009fc00 (reserved) > BIOS-e820: 0002 @ 000e (reserved) > BIOS-e820: fccf @ 0010 (usable) > BIOS-e820: f000 @ fcdf (ACPI data) > BIOS-e820: 1000 @ fcdff000 (ACPI NVS) > BIOS-e820: 1000 @ fec0 (reserved) > BIOS-e820: 1000 @ fee0 (reserved) > BIOS-e820: 0008 @ fff8 (reserved) > BIOS-e820: 8000 @ 0001 (usable) > 5248MB HIGHMEM available. > Scan SMP from c000 for 1024 bytes. > Scan SMP from c009fc00 for 1024 bytes. > Scan SMP from c00f for 65536 bytes. > found SMP MP-table at 000fb4d0 > hm, page 000fb000 reserved twice. > hm, page 000fc000 reserved twice. > hm, page 000f5000 reserved twice. > hm, page 000f6000 reserved twice. > On node 0 totalpages: 1572864 > zone(0): 4096 pages. > zone(1): 225280 pages. > zone(2): 1343488 pages. > Intel MultiProcessor Specification v1.1 > Virtual Wire compatibility mode. > OEM ID: AMI Product ID: CNB20HE APIC at: 0xFEE0 > Processor #0 Pentium(tm) Pro APIC version 17 > Floating point unit present. > Machine Exception supported. > 64 bit compare & exchange supported. > Internal APIC present. > Bootup CPU > Processor #1 Pentium(tm) Pro APIC version 17 > Floating point unit present. > Machine Exception supported. > 64 bit compare & exchange supported. > Internal APIC present. > Processor #2 Pentium(tm) Pro APIC version 17 > Floating point unit present. > Machine Exception supported. > 64 bit compare & exchange supported. > Internal APIC present. > Processor #3 Pentium(tm) Pro APIC version 17 > Floating point unit present. > Machine Exception supported. > 64 bit compare & exchange supported. > Internal APIC present. > Bus #0 is PCI > Bus #1 is PCI > Bus #2 is PCI > Bus #3 is ISA > I/O APIC #4 Version 17 at 0xFEC0. > I/O APIC #5 Version 17 at 0xFEC01000. > Int: type 0, pol 3, trig 3, bus 0, IRQ 04, APIC ID 5, APIC INT 0a > Int: type 0, pol 3, trig 3, bus 0, IRQ 08, APIC ID 5, APIC INT 0b > Int: type 0, pol 3, trig 3, bus 0, IRQ 0c, APIC ID 5, APIC INT 0f > Int: type 0, pol 3, trig 3, bus 0, IRQ 3c, APIC ID 4, APIC INT 0a > Int: type 0, pol 3, trig 3, bus 1, IRQ 15, APIC ID 5, APIC INT 01 > Int: type 0, pol 3, trig 3, bus 1, IRQ 14, APIC ID 5, APIC INT 00 > Int: type 3, pol 1, trig 1, bus 3, IRQ 00, APIC ID 4, APIC INT 00 > Int: type 0, pol 1, trig 1, bus 3, IRQ 01, APIC ID 4, APIC INT 01 > Int: type 0, pol 1, trig 1, bus 3, IRQ 00, APIC ID 4, APIC INT 02 > Int: type 0, pol 1, trig 1, bus 3, IRQ 03, APIC ID 4, APIC INT 03 > Int: type 0, pol 1, trig 1, bus 3, IRQ 04, APIC ID 4, APIC INT 04 > Int: type 0, pol 1, trig 1, bus 3, IRQ 06, APIC ID 4, APIC INT 06 > Int: type 0, pol 1, trig 1, bus 3, IRQ 07, APIC ID 4, APIC INT 07 > Int: type 0, pol 1, trig 1, bus 3, IRQ 08, APIC ID 4, APIC INT 08 > Int: type 0, pol 1, trig 1, bus 3, IRQ 0c, APIC ID 4, APIC INT 0c > Int: type 0, pol 1, trig 1, bus 3, IRQ 0d, APIC ID 4, APIC INT 0d > Int: type 0, pol 1, trig 1, bus 3, IRQ 0e, APIC ID 4, APIC INT 0e > Int: type 0, pol 1, trig 1, bus 3, IRQ 0f, APIC ID 4, APIC INT 0f > Lint: type 3, pol 1, trig 1, bus 3, IRQ 00, APIC ID ff, APIC LINT 00 > Lint: type 1, pol 1, trig 1, bus 0, IRQ 00, APIC ID ff, APIC LINT 01 > Processors: 4 > mapped APIC to e000 (fee0) > mapped IOAPI
Re: Still problems with append eth1 in lilo
> had been resolved. On my machine that is not true (dual ppro with > supermicro mobo). I have a 3c509 and a netgear fa 310tx. With the above > line in my lilo.conf the 3com should get eth1, but doesn't. Wasn't this > labeled as fixed? ether= isnt applied to PCI devices . They don't need io and irq lines and haven't ever honoured them. - 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: ioremap of pci base addresses
The Thu, Oct 12, 2000 at 11:02:50AM +0530, [EMAIL PROTECTED] wrote :
> once i have got the pci_dev structure( by calling pci_find*), do i
> explicitly need to call ioremap for remapping mmio.
> i think pci_enable_device does this. correct me if i am wrong..
ioremap does not only remap mmio but returns a token that should be
used if you want to further access the mmapped area (readl(token) and
writel(some_data, token) for example).
Part of 'foo' code could look like this :
static struct pci_driver foo_driver = {
name: "foo",
id_table: foo_pci_tbl,
probe: foo_init_one,
remove: foo_remove_one,
};
static int __init foo_init_one (struct pci_dev *pdev,
struct pci_device_id *ent)
{
u32 token;
if (pci_enable_device(pdev))
goto err_out;
/*
* Some area (non pci-configuration registers or other) one wants to
* mmap. Ask 'foo' manual for the description of the Base Address
* Register in foo's pci configuration space.
*/
if (!request_mem_region(pci_resource_start(pdev, 0),
pci_resource_len(pdev, 0), "mmaped registers")) {
printk(KERN_ERR "foo: can't reserve MMIO region\n");
goto err_out;
}
token = = (unsigned long)ioremap(pci_resource_start(pdev, 0),
pci_resource_len(pdev, 0));
/*
* The following will happen if one forgets to balance ioremap
* and iounmap at insmod/rmmod time for example.
*/
if (!token) {
printk(KERN_ERR "foo: cannot remap MMIO region %lx @ %lx\n",
pci_resource_len(pdev, 0), pci_resource_start(pdev, 0));
goto err_out_free_mmio_region;
}
[more stuff that may fail and should go at least to label err_out_iounmap]
return 0;
err_out_iounmap:
iounmap ((void *)token);
err_out_free_mmio_region:
release_mem_region(pci_resource_start(pdev, 0),
pci_resource_len(pdev, 0));
err_out:
return -ENODEV;
}
static void foo_remove_one (struct pci_dev *pdev)
{
[some stuff]
iounmap((void *)some_safe_structure->token);
[kfree may appear...]
release_mem_region(pci_resource_start(pdev, 0),
pci_resource_len(pdev, 0));
}
--
Ueimor
-
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: test10-pre1 problems on 4-way SuperServer8050
Hi! I reported this BUG on a few days ago but got no response - happens on UP with only 32M ram, too. (see below). Also note the second BUG at vmscan.c:538 which I believe never saw reported again. Richard. On Wed, 11 Oct 2000, Tigran Aivazian wrote: > On Wed, 11 Oct 2000, Rik van Riel wrote: > > Could you send me the backtrace of one of the cases where > > you hit the bug ? > > here you are: > > Oct 11 16:05:26 hilbert36 kernel: kernel BUG at page_alloc.c:221! [snipped] -- Richard Guenther <[EMAIL PROTECTED]> WWW: http://www.anatom.uni-tuebingen.de/~richi/ The GLAME Project: http://www.glame.de/ Oct 7 11:50:47 localhost kernel: kernel BUG at page_alloc.c:91! Oct 7 11:50:47 localhost kernel: invalid operand: Oct 7 11:50:47 localhost kernel: CPU:0 Oct 7 11:50:47 localhost kernel: EIP:0010:[__free_pages_ok+73/892] Oct 7 11:50:47 localhost kernel: EFLAGS: 00010286 Oct 7 11:50:47 localhost kernel: eax: 001f ebx: c1002a90 ecx: c10a4000 edx: Oct 7 11:50:47 localhost kernel: esi: c1002aac edi: ebp: 002c esp: c10a5f64 Oct 7 11:50:47 localhost kernel: ds: 0018 es: 0018 ss: 0018 Oct 7 11:50:47 localhost kernel: Process kswapd (pid: 2, stackpage=c10a5000) Oct 7 11:50:47 localhost kernel: Stack: c01d4877 c01d4a65 005b c1002a90 c1002aac 00ce 002c 00ce Oct 7 11:50:47 localhost kernel:002b 0003 c0126042 c01278cb c0126229 0004 Oct 7 11:50:47 localhost kernel: 0004 c0126870 0004 Oct 7 11:50:47 localhost kernel: Call Trace: [tvecs+8671/55752] [tvecs+9165/55752] [page_launder+674/1888] [__free_pages+19/20] [page_launder+1161/1888] [do_try_to_free_pages+52/128] [tvecs+7999/55752] Oct 7 11:50:47 localhost kernel:[kswapd+115/288] [kernel_thread+40/56] Oct 7 11:50:47 localhost kernel: Code: 0f 0b 83 c4 0c 89 f6 89 da 2b 15 f8 89 26 c0 89 d0 c1 e0 04 Oct 7 11:50:51 localhost kernel: kernel BUG at vmscan.c:538! Oct 7 11:50:51 localhost kernel: invalid operand: Oct 7 11:50:51 localhost kernel: CPU:0 Oct 7 11:50:51 localhost kernel: EIP:0010:[reclaim_page+897/980] Oct 7 11:50:51 localhost kernel: EFLAGS: 00010282 Oct 7 11:50:51 localhost kernel: eax: 001c ebx: c1002aac ecx: c1636000 edx: 0010 Oct 7 11:50:51 localhost kernel: esi: c1002a90 edi: ebp: 0040 esp: c1637e3c Oct 7 11:50:51 localhost kernel: ds: 0018 es: 0018 ss: 0018 Oct 7 11:50:51 localhost kernel: Process cc1 (pid: 2614, stackpage=c1637000) Oct 7 11:50:51 localhost kernel: Stack: c01d4277 c01d4456 021a c020bb20 c020bdb4 c0127548 Oct 7 11:50:51 localhost kernel:c020bb20 c020bdb8 0001 c0127702 c020bdac Oct 7 11:50:51 localhost kernel: 0001 1000 c03a7d60 0001 c04fe080 0007a746 0005 Oct 7 11:50:51 localhost kernel: Call Trace: [tvecs+7135/55752] [tvecs+7614/55752] [__alloc_pages_limit+124/172] [__alloc_pages+394/756] [do_anonymous_page+57/160] [do_no_page+48/192] [handle_mm_fault+232/340] Oct 7 11:50:51 localhost kernel:[do_page_fault+299/976] [merge_segments+324/364] [do_brk+267/316] [sys_brk+180/216] [error_code+44/64] Oct 7 11:50:51 localhost kernel: Code: 0f 0b 83 c4 0c 31 c0 0f b3 46 18 8d 4e 28 8d 46 2c 39 46 2c - 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: Updated 2.4 TODO List -- new addition WAS(test9 PCI
> I don't think I understand your point. Are you saying that gcc cannot be > expected to keep up with the ways in which the kernel uses it? My argument > is that providing a compiler that actually regresses (old version compiles > kernel, redhat 7.0 included one does not) is not a good choice. The bugs are as far as I can tell in the kernel sources not in gcc. The code optimising has improved and that gets us little suprises. - 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: Updated 2.4 TODO List -- new addition WAS(test9 PCI
> What different compiler? If you're talking about the kernel-package > package of Debian, that's only scripts to generate a Debian kernel package > from custom source. The gcc272 package - 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: test10-pre1 problems on 4-way SuperServer8050
On Thu, 12 Oct 2000, Matti Aarnio wrote: > > CPU0: Intel Pentium III (Cascades) stepping 01 > > CPU1: Intel Pentium III (Cascades) stepping 01 > > CPU2: Intel Pentium III (Cascades) stepping 01 > > CPU3: Intel Pentium III (Cascades) stepping 01 > > Total of 4 processors activated (5606.60 BogoMIPS). > > Hmm.. More marketing names, what is "Cascades" in the scale > of "cheap bastards" versus "all bells and whistless" ? > (Celeron vs. XEON, that is.) It is a Xeon 700MHz with 1M cache, at least we paid for it as such! :) here is a sample from /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 10 model name : Pentium III (Cascades) stepping: 1 cpu MHz : 701.000611 cache size : 1024 KB fdiv_bug: no hlt_bug : no sep_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr xmm bogomips: 1399.19 the other 3 look the same. Tigran - 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: test10-pre1 problems on 4-way SuperServer8050
On Thu, Oct 12, 2000 at 09:21:00AM +0100, Tigran Aivazian wrote: > If MTRR support is disabled then both eepro100 interfaces work fine but > the system is still 40x slower. This is the entire bootlog of > 2.4.0-test10-pre1 + lspci-vvx + /proc/interrupts + /proc/iomem + ifconfig > output > > Two currently active ideas (from Mark, Linus and Zoltan): > > b) this is an L2 cache-tag issue and there is just not enough bits in the > tag to cover such high addresses so nothing will help, save removing the > extra 2G or so out of the machine (or using them as MTD devices : I > hope this is _not_ the case... Reminds me of the difference in between Celeron and XEON variants of Pentium II -- Celerons can cache only the low 4 GB of address space, XEONs can cache whole 36 bits. (Propably other differences exist also, but that is primary one concerning memory cacheability --> apparent speed.) > CPU0: Intel Pentium III (Cascades) stepping 01 > CPU1: Intel Pentium III (Cascades) stepping 01 > CPU2: Intel Pentium III (Cascades) stepping 01 > CPU3: Intel Pentium III (Cascades) stepping 01 > Total of 4 processors activated (5606.60 BogoMIPS). Hmm.. More marketing names, what is "Cascades" in the scale of "cheap bastards" versus "all bells and whistless" ? (Celeron vs. XEON, that is.) /Matti Aarnio - 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: test10-pre1 problems on 4-way SuperServer8050
On Wed, 11 Oct 2000, Linus Torvalds wrote: > What happens if MTRR support is entirely disabled? If MTRR support is disabled then both eepro100 interfaces work fine but the system is still 40x slower. This is the entire bootlog of 2.4.0-test10-pre1 + lspci-vvx + /proc/interrupts + /proc/iomem + ifconfig output Two currently active ideas (from Mark, Linus and Zoltan): a) one needs to use big-mtrr patch from Zoltan, look at e820 map and manually set up mtrrs to cover all 6G. b) this is an L2 cache-tag issue and there is just not enough bits in the tag to cover such high addresses so nothing will help, save removing the extra 2G or so out of the machine (or using them as MTD devices : I hope this is _not_ the case... another idea (in parallel) is that eepro100 stops working because its PCI memory space is marked as cacheable. All should become clear soon -- I will spend the whole day on this, slowly trying to understand what's going on. Regards, Tigran Linux version 2.4.0-test9 (root@hilbert) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #15 SMP Wed Oct 11 19:23:15 BST 2000 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: 0002 @ 000e (reserved) BIOS-e820: fccf @ 0010 (usable) BIOS-e820: f000 @ fcdf (ACPI data) BIOS-e820: 1000 @ fcdff000 (ACPI NVS) BIOS-e820: 1000 @ fec0 (reserved) BIOS-e820: 1000 @ fee0 (reserved) BIOS-e820: 0008 @ fff8 (reserved) BIOS-e820: 8000 @ 0001 (usable) 5248MB HIGHMEM available. Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. found SMP MP-table at 000fb4d0 hm, page 000fb000 reserved twice. hm, page 000fc000 reserved twice. hm, page 000f5000 reserved twice. hm, page 000f6000 reserved twice. On node 0 totalpages: 1572864 zone(0): 4096 pages. zone(1): 225280 pages. zone(2): 1343488 pages. Intel MultiProcessor Specification v1.1 Virtual Wire compatibility mode. OEM ID: AMI Product ID: CNB20HE APIC at: 0xFEE0 Processor #0 Pentium(tm) Pro APIC version 17 Floating point unit present. Machine Exception supported. 64 bit compare & exchange supported. Internal APIC present. Bootup CPU Processor #1 Pentium(tm) Pro APIC version 17 Floating point unit present. Machine Exception supported. 64 bit compare & exchange supported. Internal APIC present. Processor #2 Pentium(tm) Pro APIC version 17 Floating point unit present. Machine Exception supported. 64 bit compare & exchange supported. Internal APIC present. Processor #3 Pentium(tm) Pro APIC version 17 Floating point unit present. Machine Exception supported. 64 bit compare & exchange supported. Internal APIC present. Bus #0 is PCI Bus #1 is PCI Bus #2 is PCI Bus #3 is ISA I/O APIC #4 Version 17 at 0xFEC0. I/O APIC #5 Version 17 at 0xFEC01000. Int: type 0, pol 3, trig 3, bus 0, IRQ 04, APIC ID 5, APIC INT 0a Int: type 0, pol 3, trig 3, bus 0, IRQ 08, APIC ID 5, APIC INT 0b Int: type 0, pol 3, trig 3, bus 0, IRQ 0c, APIC ID 5, APIC INT 0f Int: type 0, pol 3, trig 3, bus 0, IRQ 3c, APIC ID 4, APIC INT 0a Int: type 0, pol 3, trig 3, bus 1, IRQ 15, APIC ID 5, APIC INT 01 Int: type 0, pol 3, trig 3, bus 1, IRQ 14, APIC ID 5, APIC INT 00 Int: type 3, pol 1, trig 1, bus 3, IRQ 00, APIC ID 4, APIC INT 00 Int: type 0, pol 1, trig 1, bus 3, IRQ 01, APIC ID 4, APIC INT 01 Int: type 0, pol 1, trig 1, bus 3, IRQ 00, APIC ID 4, APIC INT 02 Int: type 0, pol 1, trig 1, bus 3, IRQ 03, APIC ID 4, APIC INT 03 Int: type 0, pol 1, trig 1, bus 3, IRQ 04, APIC ID 4, APIC INT 04 Int: type 0, pol 1, trig 1, bus 3, IRQ 06, APIC ID 4, APIC INT 06 Int: type 0, pol 1, trig 1, bus 3, IRQ 07, APIC ID 4, APIC INT 07 Int: type 0, pol 1, trig 1, bus 3, IRQ 08, APIC ID 4, APIC INT 08 Int: type 0, pol 1, trig 1, bus 3, IRQ 0c, APIC ID 4, APIC INT 0c Int: type 0, pol 1, trig 1, bus 3, IRQ 0d, APIC ID 4, APIC INT 0d Int: type 0, pol 1, trig 1, bus 3, IRQ 0e, APIC ID 4, APIC INT 0e Int: type 0, pol 1, trig 1, bus 3, IRQ 0f, APIC ID 4, APIC INT 0f Lint: type 3, pol 1, trig 1, bus 3, IRQ 00, APIC ID ff, APIC LINT 00 Lint: type 1, pol 1, trig 1, bus 0, IRQ 00, APIC ID ff, APIC LINT 01 Processors: 4 mapped APIC to e000 (fee0) mapped IOAPIC to d000 (fec0) mapped IOAPIC to c000 (fec01000) Kernel command line: auto BOOT_IMAGE=240-test10 ro root=805 BOOT_FILE=/boot/vmlinuz-2.4.0-test10 console=ttyS0,9600 console=tty0 Initializing CPU#0 Detected 701.611 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1399.19 BogoMIPS Memory: 6132848k/6291456k available (1531k kernel code, 106956k reserved, 88k data, 188k init, 5322688k highmem) Dentry-cache hash table ent
Re: [RFC] atomic pte updates for x86 smp
On Wed, 11 Oct 2000, Linus Torvalds wrote: > (Instead of doing an atomic 64-bit memory write, we would be doing the > atomic "pte_xchg_clear()" followed by two _non_atomic 32-bit writes where > the second write would set the present bit. Although maybe the erratum > about the PAE pgd entry not honoring the P bit correctly makes this be > unworkable). > > Ingo? I'd really like you to take a long look at this patch for sanity, > especially wrt PAE. the PAE pgd 'anomaly' should not affect this case, because we never clear neither user-space pgds, nor user-space pmds in PAE mode. Unless we start swapping pagetables i dont think this will ever happen in the future. The PAE anomaly only affects the four top-level pgds, so even if we started swapping pagetables, we'll never have to swap the pgds themselves. i completely agree with the need to clean the pte-setting atomicity interface up. And getting rid of cmpxch8b will be a definite performance (and GCC-optimization) improvement. > After this patch, are there any cases where we do a "set_pte()" where > the PTE wasn't clear before? That might be a good sanity-test to add, > just to make sure. And I'd really like to speed up the PAE set_pte() - > as far as I can tell both set_pte and set_pmd really should be safe > without the atomic 64-bit crap with your changes. yep, the two 32-bit writes idea is very nice - this should be safe - and there isnt even any need for any barriers (except optimization barrier), given that writes are strongly ordered on x86. my gut feeling is that all these things will only benefit PAE support, and the risk of those changes is low, none of those should bite us in the future, design-wise. And it's also a nice speedup. And after this we could finally get rid of the 'unsigned long long' as well and just define two 32-bit fields in pte. Ingo - 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: nfs on a 2.4.0
> " " == johna <[EMAIL PROTECTED]> writes: > Rootfs works fine, but attempting to mount other directories > via nfs causes problems. Error messages like : RPC: sendmsg > returned error 101, nfs warning: mount version is older than The 'sendmsg' error means you're trying to mount with NLM locking enabled before having started the portmapper. That's a no-no: always has been, and always will be. It 'worked' (not) in 2.2.x due to a hack. If you don't need locking, mount using the 'nolock' option. If you do, make sure that your startup scripts fire up portmap and rpc.statd before you mount your extra disks. As for the necessary 'mount' changes; they have already gone into the standard util-linux package. Just pick up the latest version from your nearest mirror site, or from Andries' master site: ftp://ftp.win.tue.nl/pub/linux/utils/util-linux/ Cheers, Trond - 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/
