Re: [patch] Re: alpha - generic_init_pit - why using RTC for calibration?
Richard, thanks. But please use calibrate_cc version which I've submited
as a patch - it gives more accuracy with maximum latch we can ever use and
has cc's type changed to 'unsigned int' to prevent problems when rpcc
overflows.
Oleg.
- Original Message -
From: "Richard Henderson" <[EMAIL PROTECTED]>
To: "Ivan Kokshaysky" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Cc: "Oleg I. Vdovikin" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, July 04, 2001 10:45 PM
Subject: [patch] Re: alpha - generic_init_pit - why using RTC for
calibration?
> On Fri, Jun 29, 2001 at 09:19:31PM +0400, Ivan Kokshaysky wrote:
> > Good idea. The patch below works reliably on my sx164.
>
> Reasonable. Here I've cleaned up time_init a tad as well.
>
>
> r~
>
>
>
> --- arch/alpha/kernel/time.c.orig Fri Jun 29 11:24:03 2001
> +++ arch/alpha/kernel/time.c Fri Jun 29 11:35:52 2001
> @@ -169,6 +169,77 @@ common_init_rtc(void)
> init_rtc_irq();
> }
>
> +/*
> + * Calibrate CPU clock using legacy 8254 timer/counter. Stolen from
> + * arch/i386/time.c.
> + */
> +
> +#define CALIBRATE_LATCH (52 * LATCH)
> +#define CALIBRATE_TIME (52 * 120 / HZ)
> +
> +static unsigned long __init
> +calibrate_cc_with_pic(void)
> +{
> + int cc;
> + unsigned long count = 0;
> +
> + /* Set the Gate high, disable speaker */
> + outb((inb(0x61) & ~0x02) | 0x01, 0x61);
> +
> + /*
> + * Now let's take care of CTC channel 2
> + *
> + * Set the Gate high, program CTC channel 2 for mode 0,
> + * (interrupt on terminal count mode), binary count,
> + * load 5 * LATCH count, (LSB and MSB) to begin countdown.
> + */
> + outb(0xb0, 0x43); /* binary, mode 0, LSB/MSB, Ch 2 */
> + outb(CALIBRATE_LATCH & 0xff, 0x42); /* LSB of count */
> + outb(CALIBRATE_LATCH >> 8, 0x42); /* MSB of count */
> +
> + cc = rpcc();
> + do {
> + count++;
> + } while ((inb(0x61) & 0x20) == 0);
> + cc = rpcc() - cc;
> +
> + /* Error: ECTCNEVERSET */
> + if (count <= 1)
> + goto bad_ctc;
> +
> + /* Error: ECPUTOOFAST */
> + if (count >> 32)
> + goto bad_ctc;
> +
> + /* Error: ECPUTOOSLOW */
> + if (cc <= CALIBRATE_TIME)
> + goto bad_ctc;
> +
> + return ((long)cc * 100) / CALIBRATE_TIME;
> +
> + /*
> + * The CTC wasn't reliable: we got a hit on the very first read,
> + * or the CPU was so fast/slow that the quotient wouldn't fit in
> + * 32 bits..
> + */
> + bad_ctc:
> + return 0;
> +}
> +
> +/* The Linux interpretation of the CMOS clock register contents:
> + When the Update-In-Progress (UIP) flag goes from 1 to 0, the
> + RTC registers show the second which has precisely just started.
> + Let's hope other operating systems interpret the RTC the same way. */
> +
> +static unsigned long __init
> +rpcc_after_update_in_progress(void)
> +{
> + do { } while (!(CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP));
> + do { } while (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP);
> +
> + return rpcc();
> +}
> +
> void __init
> time_init(void)
> {
> @@ -176,24 +247,15 @@ time_init(void)
> unsigned long cycle_freq, one_percent;
> long diff;
>
> - /*
> - * The Linux interpretation of the CMOS clock register contents:
> - * When the Update-In-Progress (UIP) flag goes from 1 to 0, the
> - * RTC registers show the second which has precisely just started.
> - * Let's hope other operating systems interpret the RTC the same way.
> - */
> - do { } while (!(CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP));
> - do { } while (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP);
> + /* Calibrate CPU clock -- attempt #1. */
> + if (!est_cycle_freq)
> + est_cycle_freq = calibrate_cc_with_pic();
>
> - /* Read cycle counter exactly on falling edge of update flag */
> - cc1 = rpcc();
> + cc1 = rpcc_after_update_in_progress();
>
> + /* Calibrate CPU clock -- attempt #2. */
> if (!est_cycle_freq) {
> - /* Sometimes the hwrpb->cycle_freq value is bogus.
> -Go another round to check up on it and see. */
> - do { } while (!(CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP));
> - do { } while (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP);
> - cc2 = rpcc();
> + cc2 = rpcc_after_update_in_progress();
> est_cycle_freq = cc2 - cc1;
> cc1 = cc2;
> }
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: >128 MB RAM stability problems (again)
On Wed, Jul 04, 2001 at 11:16:43PM -0400, Bill Pringlemeir wrote: > I also have had problems with a machine that had 128Mb + 64 Mb. I > discovered the following about 2.4.x. You _should_ have a swap file > that is double RAM. Mixing different SDRAM types is probably a bad > thing. So if you upgraded, then that might be problematic. And here's a counter claim: At home have 128 + 64, both of different speeds and brands. Of course, to run properly you have to force the pc100 to run at 66, but other than that they're happy (96MB swap) -- /| Ragnar Højland Freedom - Linux - OpenGL |Brainbench MVP \ o.O| PGP94C4B2F0D27DE025BE2302C104B78C56 B72F0822 | for Unix Programming =(_)= "Thou shalt not follow the NULL pointer for | (www.brainbench.com) U chaos and madness await thee at its end." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Suitable Athlon Motherboard for Linux
On Wed, 4 Jul 2001, Joseph Mathewson wrote: > Having heard the various horror stories about the VIA PCI data corruption > bugs, and watching one Via based machine destroy itself with a Mandrake 8.0 > 2.4.3, I was just wondering if anyone had a suggestion for an Athlon > motherboard that works reliably under Linux (I don't think all the issues > have been cleared up in the kernel yet?). There must be quite a few Linux > Athlon users out there - what boards are you using and with what success? > > I can't see much alternative to Via chipsets in the Ahtlon market, other > than all-in-one-graphics-sound-network jobbies that, from previous > experience (namely the i810), are also best avoided. > > Joe. Hi! I have an EPOX 8kta2 (www.eopx.com) and I'm very pleased with it. No lookups since I buy it! I use a Thunderbird @ 650MHz. > > +-+ > | Joseph Mathewson <[EMAIL PROTECTED]> | > +-+ > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > --- Catalin(ux) BOIE [EMAIL PROTECTED] A new Linux distribution: http://l13plus.deuroconsult.ro http://www2.deuroconsult.ro/~catab - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: >128 MB RAM stability problems (again)
On 04 Jul 2001 17:29:12 -0400, Chris Siebenmann wrote: > You write: > | I'm kind of astounded now, WHY can't linux-2.4.x run on ANY machine in > | my house with more than 128 MB RAM?!? Can someone please point out to me > | that he's actually running kernel-2.4.x on a machine with more than 128 > | MB RAM and that he's NOT having severe stability problems? > > Me. Two machines. (Both 2.4.5 high -ac kernels.) > > I strongly suggest getting memtest86 and running it on all of your > problematic machines. I ran memtest tonight on all machines It gave 0 errors on all of them. So this leads to the conclusion that the memory is okay, and that something else must be the problem Could it still be a failing power supply or something? It seems both computers have a 230 W power supply. Might be a problem, I guess, I can buy a 400 W thingy if that makes sense. Other solutions I heard: - antistatic wrist strap: already have one :-) - BIOS fiddling... What exactly should I look for? They are, as far as I can see, identical memory sticks, probably both from different suppliers, but besides that quite the same - are there different brands of memory of different quality and might that be a possible cause of the problems? And if so - what are good memory brands and what are the bad ones? - I mixed different types of SDRAM... Could be it My mainboard manual is not really clear about this And I have no clue what brand of memory I bought... they are all 133 MHz SDRAM sticks, some 64 MB, some 128 MB MB manual says it can handle all 64/128 MB sticks... - Anyway, thanks for any advice until now and thanks for listening again, hope to hear more solutions. -- Ronald Bultje - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [wip-PATCH] rfi: PAGE_CACHE_SIZE suppoort
On Thu, 5 Jul 2001, Ben LaHaise wrote: > > I attacked the PAGE_CACHE_SIZE support in the kernel for the last few days > in an attempt to get multipage PAGE_CACHE_SIZE support working and below > is what I've come up with. It currently boots to single user read only, > doesn't quite have write support fixed properly yet, but is going pretty > well. The reason for sending this out now is the question of what to do > about kmap() support. I suggest making kmap _always_ map the "biggest" chunk of physical memory that the kernel ever touches at a time. So I would _strongly_ suggest that you make the kmap granularity be at _least_ PAGE_CACHE_SIZE. For debugging reasons I would suggest you have a separate "PAGE_KMAP_SIZE" thing, so that you can get the kmap code working independently of the PAGE_CACHE_SIZE thing. Once you have the guarantee that "kmap(page)" will actually end up mapping the (power-of-two-aligned) power-of-two-sized PAGE_KMAP_SIZE around the page, the loops should all go away, and you should be able to use kmap() the same way you've always used it (whether the user actually cares about just one page or not ends up being a non-issue). > - filp->f_pos = (n << PAGE_CACHE_SHIFT) | offset; > + filp->f_pos = (n << PAGE_SHIFT) | offset; You're definitely doing something wrong here. You should _never_ care about PAGE_SHIFT, except in the case of a mmap() where you obviously end up mapping in "partial" page-cache pages. I suspect you're doing all this exactly because of the kmap issue, but you really shouldn't need to do it. The whole point with having a bigger page-cache-size is to be able to process bigger chunks at a time. Now, one thing you might actually want to look into is to make the dirty bit be a "dirty bitmap", so that you have the option of marking things dirty at a finer granularity. But that, I feel, is after you've gotten the basic stuff working with a PAGE_CACHE_SIZE dirty granularity. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix fbcon.c compiles error on 2.4.7pre2
It seems that some part is missing, In AC patch , it have that function.
dfbb
--- linux/drivers/video/fbcon.c.origThu Jul 5 13:09:55 2001
+++ linux/drivers/video/fbcon.c Thu Jul 5 13:33:32 2001
@@ -1150,13 +1150,11 @@
}
}
scr_writew(c, d);
- console_conditional_schedule();
s++;
d++;
} while (s < le);
if (s > start)
p->dispsw->putcs(conp, p, start, s - start, real_y(p, line), x);
- console_conditional_schedule();
if (offset > 0)
line++;
else {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: loop device corruption in 2.4.6
On Wed, Jul 04, 2001 at 05:14:02PM -0400, Mark Swanson wrote: > I get repeatable errors with 2.4.6 patched with the international encryption > patch patch-int-2.4.3.1.bz2 when building loop device filesystems on top of > Reiserfs. Well, exactly this happens here on 2.4.5 and earlier too... I can't verify this on 2.4.6 (plain) because the kernel hangs right after partition-check on my Thinkpad A21p. :( -- ciao - Stefan CONFIG_HANG_AFTER_PARTITION_CHECK=y - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sticky IO-APIC problem
"Randy.Dunlap" <[EMAIL PROTECTED]> wrote: >I can't find an Intel BN810E board at intel.com or by searching >at google.com. Are you sure that's the correct name/ID for it? >Do you have any web page references for it? Sorry, it was an Intel CA810E board. (http://www.intel.com/support/motherboards/desktop/ca810e/) -- Colin The CompNerd Network: http://www.compnerd.com/ Where a nerd can be a nerd. Get your free [EMAIL PROTECTED]! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: tcp stack tuning and Checkpoint FW1 & Legato Networker
On Wed, Jul 04, 2001 at 07:02:36PM -0700, George Bonser wrote: > > I want to set the tcp_keepalive timer to 60 seconds and understand > > possible implications for Linux. > > echo 60 >/proc/sys/net/ipv4/tcp_keepalive_time By default, this is only polled by the kernel every 75 seconds, so you would still lose. In 2.2, this is hard-coded. In 2.4, /proc/sys/net/ipv4/tcp_keepalive_intvl will probably help, but I haven't tried it. Andrew - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel HOWTO update?
Shawn Starr wrote: >Section: >7.6 You forgot to run LILO, or system doesn't boot at all > >You might want to update the following line: > >"Using LILO with big drives (more than 1024 cylinders) can cause problems. >See the LILO mini-HOWTO or documentation for help on that." > >This isn't true anymore unless your using an older version of LILO. > Or an old hard drive. -- :__o : -\<, : 0/ 0 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: >128 MB RAM stability problems (again)
>> I'm kind of astounded now, WHY can't linux-2.4.x run on ANY >> machine in my house with more than 128 MB RAM?!? Can someone >> please point out to me Alan> Can I suggest you change your memory vendor and/or get an Alan> antistatic wrist strap ? I also have had problems with a machine that had 128Mb + 64 Mb. I discovered the following about 2.4.x. You _should_ have a swap file that is double RAM. Mixing different SDRAM types is probably a bad thing. So if you upgraded, then that might be problematic. However, when I did have 196 Mb it completely trashed my file system. I also work with electronic components and these were handled in an ESD safe manner. It may be possible to set the SDRAM controller to handle disparate SDRAM chips...but it is probably very painful. I have done this on an MPC860 and a Coldfire chip. However, I haven't the faintest clue about PC controllers. Perhaps when I am feeling brave again, I will return to try additional memory. hth, Bill Pringlemeir. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kernel HOWTO update?
Section: 7.6 You forgot to run LILO, or system doesn't boot at all You might want to update the following line: "Using LILO with big drives (more than 1024 cylinders) can cause problems. See the LILO mini-HOWTO or documentation for help on that." This isn't true anymore unless your using an older version of LILO. Shawn. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why Plan 9 C compilers don't have asm("")
>Now, you could probably argue that instead of inline asms we should have >more flexibility in doing a per-callee calling convention. That would be >good too, no question about it. > >Linus > Today's flamebait has been postponed. Happy July 4th. Peace. Rick Hohensee www.clienux.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pcmcia lockup inserting or removing cards in 2.4.5-ac{13,22}
On Thu, Jul 05, 2001 at 12:41:15AM +, Trevor Hemsley wrote: > OK, I've done quite a lot more work on this. It isn't 2.4.5, I'd > compiled USB support in when I went to 2.4.5 and it's that that causes > the problems. I backed out all changes made between 2.4.2 and 2.4.5 in > drivers/pcmcia and that made no difference to the lockup so then I > went back to the .config file from 2.4.2 and that worked. Hmm, Cardbus and USB problems... you probably have both Cardbus and i82365 support in your kernel configuration. Your .config file should have this: # # PCMCIA/CardBus support # CONFIG_PCMCIA=y CONFIG_CARDBUS=y # CONFIG_I82365 is not set # CONFIG_TCIC is not set That fixed it for me for at least three laptops. Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.[56] kernel + xfree 4.1.0
After upgrading to xfree 4.1.0, after switching back to the console after starting X, suspending, and resuming, the text-mode terminals are corrupt (but look like they're in text mode). There were some messages in the XFree lists about X no longer restoring previous graphics state (since it has no real way of knowing what graphics state the console you're switching to is in), but I was hoping this was an Xserver bug with my graphics chipset (savage ix) writing someplace it shouldn't. I just compiled framebuffer support in, though, and when switching to a console, it's initially corrupt (similar pretty impressionistic graphics that look like they're in the correct video mode for the framebuffer/console), but within a half a second the framebuffer fixes itself. Also with framebuffer in use, after a suspend and resume from X 4.1.0, the mouse cursor is replaced by a large block. With regular text-mode consoles, this doesn't happen. Switching away and back to X restores the cursor properly. This may be completely X's fault though. Allegedly it's supposed to be bad to run non-framebuffer X-servers with framebuffer console, is this really not considered stable or am I mistaken? If X isn't going to restore previous graphics modes, it doesn't seem to matter what mode the console was in, framebuffer or not, it still needs to be fixed regardless. I'm presuming then that this is something the regular console driver needs to deal with? justin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re[2]: about kmap_high function
Hi, Tuesday, July 03, 2001, 5:38:09 PM, you wrote: SCT> kmap_high is intended to be called routinely for access to highmem SCT> pages. It is coded to be as fast as possible as a result. TLB SCT> flushes are expensive, especially on SMP, so kmap_high tries hard to SCT> avoid unnecessary flushes. SCT> The way it does it is to do only a single, complete TLB flush of the SCT> whole kmap VA range once every time the kmap address ring cycles. SCT> That's what flush_all_zero_pkmaps() does --- it evicts old, unused SCT> kmap mappings and flushes the whole TLB range, so that we are SCT> guaranteed that there is a TLB flush between any two different uses of SCT> any given kmap virtual address. SCT> That way, we can avoid the cost of having to flush the TLB for every SCT> single kmap mapping we create. Thank you very much for your kindly guide, and I have two question to ask you, One question is, Is kmap_high intended to be called merely in the user context, so the highmem pages are mapped into user process page table, so on SMP, other processes ( including kernel and user process) that running on another cpu doesn't need to get that kmap virtual address. Another question is, when kernel evicts old, unused kmap mapping and flushes the whole TLB range( call the flush_all_zero_pkmaps), the TLB won't keep those zero mappings, after that, when user process call kmap_high to get a new kmap mappings, and when the process access that virtual address, MMU component will get the page directory and page table from MEMORY instead of TLB to translate the virtual address into physical address. -- Best regards, Michael Chenmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: tcp stack tuning and Checkpoint FW1 & Legato Networker
> > I want to set the tcp_keepalive timer to 60 seconds and understand > possible implications for Linux. echo 60 >/proc/sys/net/ipv4/tcp_keepalive_time - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: >128 MB RAM stability problems (again)
> > Nobody has answered a basic concern: > Why does Win2k work while Linux does not? The answer could be as simple as the fact that Linux might be trying to write to the exact memory location that is bad but Win2k has not. It might also be that he in fact DOES have problems with win2k but is unaware of it, that location might be used for data storage rather than program execution. All I can say is this ... I have never used Windows on our production web farms and Linux 2.4 appears to work just fine will many different sizes of memory ... all greater than 128MB. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
tcp stack tuning and Checkpoint FW1 & Legato Networker
Hi, Can someone point me to a document that describes how to tune the tcp stack for Linux kernels 2.4.x and 2.2.x I want to set the tcp_keepalive timer to 60 seconds and understand possible implications for Linux. Simply I have a problem with Checkpoint FW1 and Legato Backup: When making a backup over a Checkpoint FW from Linux using Legato on a Solaris Server. When legoto starts to make a backup it opens a tcp connection from the backup client to the backup server with a standard tcp threeway handshake. When the backup is completed (this can take a while) the client sends 1 packet to close the connection and includes in this the result of the backup - success/failure. Problem is that checkpoint seem to have taken it upon themseleves to treat a tcp established session as "tcp_start" and not honour the state unless the connection has additional packets sent. the initial period after tcp establishment (3way handshake) with no payload defaults to 60 seconds. Once data has been sent this connection is moved to a state table and the connection will be honoured for 3600 seconds or whatever I choose to set it to. Because of the tcp_start timer in checkpoint any partition with a size sufficient to make the backup take > 60 secs will fail to receive the success/failure packet and therefore reported as Bad. If I set the tcp_keepalive timer to 60 seconds then keepalives will keep the connection established for the duration of the backup which could be 50 minutes for a large partition. I can set this under solaris with ndd tcp_keepalive_interval 6 (ms) Thanks Mark - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why Plan 9 C compilers don't have asm("")
> > On Tue, Jul 03, 2001 at 11:37:28PM -0400, Rick Hohensee wrote: > > That's with the GNU tools, without asm(), and without proper declaration > > of printf, as is my tendency. I don't actually return an int either, do I? > > LAAETTR. > > Under ISO C rules, this is illegal, since you must have a proper prototype in > scope when calling variable argument functions. In fact, I have worked on > several GCC ports, where the compiler uses a different calling sequence for > variable argument functions than it does for normal functions. For example, on > the Mips, if the first argument is floating point and the number of arguments > is not variable, it is passed in a FP register, instead of an integer > register. For variable argument functions, everything is passed in the integer > registers. > I didn't know that, but... You seem to be saying the use of assumptions about args passing is non-standard. I know. It's more standard than GNU extensions to C though, C_labels_in_asms in particular, and even in your examples it appears that the particular function abusing these tenets will know what it can expect from a particular compiler, since it knows what it's arguments are. It can't know what it can expect from any compiler. This perhaps is where #ifdef comes in, or similar. Well, it's not more standard than GNU, but the differences would be less detailed in the case of just dealing with various args passing schemes, and there may be some compiler-to-compiler overlap, where there won't be any with stuff like C_labels_in_asms. It's illegal to not declare main() as int. I don't know of a unix that actually passes anything but a byte to the calling process. I got flamed mightily for this in comp.unix.programmer until people ran some checks on thier big Real Unix(TM) boxes of various types. Linux won't pass void either, you have to get a 0 at least. Compliance is subjective. It's easier when things make sense. Rick Hohensee www.clienux.com > -- > Michael Meissner, Red Hat, Inc. (GCC group) > PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA > Work: [EMAIL PROTECTED] phone: +1 978-486-9304 > Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: >128 MB RAM stability problems (again)
Reza Roboubi <[EMAIL PROTECTED]> wrote: > Nobody has answered a basic concern: > Why does Win2k work while Linux does not? I did post a possible answer for this: different OSes excercise the memory subsystem very differently. This is why a box might run (say) Win95 apparently stably, but not be able to run Linux. The same reasoning applies to other OSes. I've seen this many times myself. Charles -- --- Charles Cazabon<[EMAIL PROTECTED]> GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VM Requirement Document - v0.0
> Getting the user's "interactive" programs loaded back > in afterwards is a separate, much more difficult problem > IMHO, but no doubt still has a reasonable solution. Possibly stupid suggestion... Maybe the interactive/GUI programs should wake up once in a while and touch a couple of their pages? Go too far with this and you'll just get in the way of performance, but I don't think it would hurt to have processes waking up every couple of minutes and touching glibc, libqt, libgtk, etc so they stay hot in memory... A very slow incremental "caress" of the address space could eliminate the "I-just-logged-in-this-morning-and-dammit-everything-has-been-paged-out" problem. Regards, Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: >128 MB RAM stability problems (again)
Nobody has answered a basic concern: Why does Win2k work while Linux does not? We already know that MiciSoft sometimes helps make stupid standards like P&P ISA cards and then writes drivers for them. Something that is hard to do for any _sane_ developers who did not help make the stupid "standard". Having said that, if anybody has a technical answer for Ronald please give it to him. He says: My systems ARE FINE BECAUSE Win2k runs on them. This deserves a direct technical answer if anybody has one. I'm a Linux user and proud of it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why Plan 9 C compilers don't have asm("")
On Tue, Jul 03, 2001 at 11:37:28PM -0400, Rick Hohensee wrote: > That's with the GNU tools, without asm(), and without proper declaration > of printf, as is my tendency. I don't actually return an int either, do I? > LAAETTR. Under ISO C rules, this is illegal, since you must have a proper prototype in scope when calling variable argument functions. In fact, I have worked on several GCC ports, where the compiler uses a different calling sequence for variable argument functions than it does for normal functions. For example, on the Mips, if the first argument is floating point and the number of arguments is not variable, it is passed in a FP register, instead of an integer register. For variable argument functions, everything is passed in the integer registers. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Random lockups with kernels 2.4.6-pre8+
Hi there, I have been experiencing seemingly random lock ups with kernels 2.4.6-pre8 and 2.4.6-final which didn't occur when running on 2.4.6-pre5. I am not yet able to reproduce this behaviour (I will look into this as soon as I get some more time) but when it occurs the symptoms are consistent (it happened three times so far): Some programs consistently hang while others seem to continue running. For example X and enlightenment run while top hangs (it has even segfaulted once) xdm runs partially it sets up a new X session when reset, backgroud colour and so forth, but the xdm-greeter does not appear. When trying to shut down the computer from this state it consistently hangs while trying to kill xfsft. SysReq works like a charm :-) I am running on a Fujitsu Lifbook B110 with Intel PIIX4 Chipset 32MB of RAM 64MB of swap APM enabled. As I have no clue what causes this erratic behaviour, I don't know what other information might be relevant but will gladly provide it if somebody asks. Just in case I'll attach the output of dmesg (running 2.4.6-pre5 BTW unlike this kernel 2.4.6-pre8 and final were compiled with gcc-2.95.3) I'll follow up when I'm able to reliably reproduce the lock ups. Bye Felix -- Linux version 2.4.6-pre5 (root@eressea) (gcc version 3.0) #15 Sun Jun 24 21:54:46 EDT 2001 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000f1000 - 0010 (reserved) BIOS-e820: 0010 - 01fec000 (usable) BIOS-e820: 01fec000 - 01ff (ACPI data) BIOS-e820: 01ff - 0200 (ACPI NVS) BIOS-e820: 1000 - 0001 (reserved) On node 0 totalpages: 8172 zone(0): 4096 pages. zone(1): 4076 pages. zone(2): 0 pages. Kernel command line: rw root=305 mem=32688K Initializing CPU#0 Detected 232.106 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 463.66 BogoMIPS Memory: 30328k/32688k available (884k kernel code, 1972k reserved, 189k data, 176k init, 0k highmem) Dentry-cache hash table entries: 4096 (order: 3, 32768 bytes) Inode-cache hash table entries: 2048 (order: 2, 16384 bytes) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 8192 (order: 3, 32768 bytes) CPU: Before vendor init, caps: 008001bf , vendor = 0 Intel Pentium with F0 0F bug - workaround enabled. Intel old style machine check architecture supported. Intel old style machine check reporting enabled on CPU#0. CPU: After vendor init, caps: 008001bf CPU: After generic, caps: 008001bf CPU: Common caps: 008001bf CPU: Intel Mobile Pentium MMX stepping 01 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX PCI: PCI BIOS revision 2.10 entry at 0xfda20, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Using IRQ router PIIX [8086/7110] at 00:01.0 got res[1000:1fff] for resource 0 of Ricoh Co Ltd RL5c475 Limiting direct PCI/PCI transfers. Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 apm: BIOS version 1.2 Flags 0x03 (Driver version 1.14) Starting kswapd v1.8 devfs: v0.106 (20010617) Richard Gooch ([EMAIL PROTECTED]) devfs: boot_options: 0x2 pty: 256 Unix98 ptys configured block: queued sectors max/low 20032kB/6677kB, 64 slots per queue Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx PIIX4: IDE controller on PCI bus 00 dev 09 PIIX4: chipset revision 1 PIIX4: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xf4f0-0xf4f7, BIOS settings: hda:DMA, hdb:pio hda: FUJITSU MHD2032AT, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hda: 6354432 sectors (3253 MB), CHS=788/128/63, UDMA(33) Partition check: /dev/ide/host0/bus0/target0/lun0: p1 p2 < p5 p6 p7 p8 p9 > NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 2048 bind 4096) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. fatfs: bogus logical sector size 5376 reiserfs: checking transaction log (device 03:05) ... Using r5 hash to sort names ReiserFS version 3.6.25 VFS: Mounted root (reiserfs filesystem). Mounted devfs on /dev Freeing unused kernel memory: 176k freed Adding Swap: 32220k swap-space (priority 0) Adding Swap: 32216k swap-space (priority 1) inserting floppy driver for 2.4.6-pre5 Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 reiserfs: checking transaction log (device 03:09) ... Using r5 hash to sort names ReiserFS version 3.6.25 reiserfs: checking transaction log (device 03:07) ... Using r5 hash to sort names ReiserFS version 3.6.25 Soundblaster audio driver Copyright (C)
Re: [PATCH] update for ALi Audio Driver
Sorry for my mistake. The patch I sent yesterday is wrong because it's not
edited from the current source. And here is new patch for ALi M5451 audio
driver.
Best regards,
Matt Wu
http://www.ali.com.tw
Information about update:
Updated files: trident.c trident.h
Location: drivers/sound
Driver Version: 0.14.8
Kernel Version: 2.4.X
patch file:
--- drivers/sound/trident.c.orig Tue Jul 3 13:41:23 2001
+++ drivers/sound/trident.c Thu Jul 5 05:54:48 2001
@@ -12,7 +12,6 @@
* Hacked up by:
* Aaron Holtzman <[EMAIL PROTECTED]>
* Ollie Lho <[EMAIL PROTECTED]> SiS 7018 Audio Core Support
- * Ching-Ling Lee <[EMAIL PROTECTED]> ALi 5451 Audio Core Support
* Matt Wu <[EMAIL PROTECTED]> ALi 5451 Audio Core Support
*
*
@@ -31,6 +30,13 @@
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*
* History
+ * v0.14.8
+ * Apr 30 2001 Matt Wu
+ * Set EBUF1 and EBUF2 to still mode
+ * Add dc97/ac97 reset function
+ * Fix power management: ali_restore_regs
+ * Mar 09 2001 Matt Wu
+ * Add cache for ac97 access
* v0.14.7
* Feb 06 2001 Matt Wu
* Fix ac97 initialization
@@ -135,7 +141,7 @@
#include
-#define DRIVER_VERSION "0.14.6"
+#define DRIVER_VERSION "0.14.8"
/* magic numbers to protect our data structures */
#define TRIDENT_CARD_MAGIC 0x5072696E /* "Prin" */
@@ -320,9 +326,9 @@
void (*free_pcm_channel)(struct trident_card *, unsigned int chan);
void (*address_interrupt)(struct trident_card *);
-/* Add by Matt Wu 01-05-2001 for spdif in */
-int multi_channel_use_count;
-int rec_channel_use_count;
+/* Added by Matt Wu 01-05-2001 for spdif in */
+int multi_channel_use_count;
+int rec_channel_use_count;
};
/* table to map from CHANNELMASK to channel attribute for SiS 7018 */
@@ -338,11 +344,16 @@
DSP_BIND_I2S, DSP_BIND_CENTER_LFE, DSP_BIND_SURR, DSP_BIND_SPDIF
};
-/* Add by Matt Wu 01-05-2001 for spdif in */
+/* Added by Matt Wu 01-05-2001 for spdif in */
static int ali_close_multi_channels(void);
static void ali_delay(struct trident_card *card,int interval);
static void ali_detect_spdif_rate(struct trident_card *card);
+u16 MixerRegs[64][NR_AC97];
+int bRegsReady = 0;
+
+static void ali_ac97_write(struct ac97_codec *codec, u8 reg, u16 val);
+static u16 ali_ac97_read(struct ac97_codec *codec, u8 reg);
static struct trident_card *devs;
static void trident_ac97_set(struct ac97_codec *codec, u8 reg, u16 val);
@@ -353,8 +364,8 @@
unsigned long arg);
static loff_t trident_llseek(struct file *file, loff_t offset, int origin);
-static void ali_ac97_set(struct ac97_codec *codec, u8 reg, u16 val);
-static u16 ali_ac97_get(struct ac97_codec *codec, u8 reg);
+static void ali_ac97_set(struct trident_card *card, int secondary, u8 reg, u16
val);
+static u16 ali_ac97_get(struct trident_card *card, int secondary, u8 reg);
static void ali_set_spdif_out_rate(struct trident_card *card, unsigned int
rate);
static void ali_enable_special_channel(struct trident_state *stat);
static struct trident_channel *ali_alloc_rec_pcm_channel(struct trident_card
*card);
@@ -607,6 +618,10 @@
continue;
outl(data[i], TRID_REG(card, CHANNEL_START + 4*i));
}
+if (card->pci_id == PCI_DEVICE_ID_ALI_5451) {
+ outl(ALI_EMOD_Still, TRID_REG(card, ALI_EBUF1));
+ outl(ALI_EMOD_Still, TRID_REG(card, ALI_EBUF2));
+}
return TRUE;
}
@@ -950,6 +965,7 @@
trident_disable_voice_irq(card, chan_num);
}
+
static void stop_dac(struct trident_state *state)
{
struct trident_card *card = state->card;
@@ -989,7 +1005,7 @@
static int alloc_dmabuf(struct trident_state *state)
{
struct dmabuf *dmabuf = &state->dmabuf;
-void *rawbuf=NULL;
+void *rawbuf = NULL;
int order;
struct page *page, *pend;
@@ -1221,7 +1237,7 @@
return -EBUSY;
}
- /* No matter how much data left in the buffer, we have to wait untill
+ /* No matter how much data left in the buffer, we have to wait until
CSO == ESO/2 or CSO == ESO when address engine interrupts */
if (state->card->pci_id == PCI_DEVICE_ID_ALI_5451)
{
@@ -1234,7 +1250,6 @@
tmo = (dmabuf->dmasize * HZ) / dmabuf->rate;
}
tmo >>= sample_shift[dmabuf->fmt];
-// printk("trident: diff=%d count= %d/%d total=%d tmo=%d hwptr=%d
swptr=%d
curptr=%d\n",diff,dmabuf->count,dmabuf->dmasize,dmabuf->total_bytes,tmo,dmabuf->hwptr,dmabuf->swptr,trident_get_dma_addr(state));
if (!schedule_timeout(tmo ? tmo : 1) && tmo){
break;
}
@@ -2098,6 +2113,17 @@
struct trident_state *state = NULL;
struct dmabuf *dmabuf = NULL;
+/* Added by Matt Wu 01-05-2001 */
+if(file->f_mode & FMODE_READ)
+{
+ if(card->pci_id == PCI_DEVICE_ID_ALI_5451) {{=%d
+ if (card->multi_channel_
Re: unable to read from IDE tape
Upgrade to mt-st version .5b or greater. Older mt versions had known bugs particularly with positioning. I suggest scsi emulation + scsi tape rather than ATAPI tape. rgds, tim. ... hdd: HP COLORADO 20GB, ATAPI TAPE drive ... scsi0 : SCSI host adapter emulation for IDE ATAPI devices scsi : 1 host. Vendor: HPModel: COLORADO 20GB Rev: 4.01 Type: Sequential-Access ANSI SCSI revision: 02 Detected scsi tape st0 at scsi0, channel 0, id 0, lun 0 ... [17:12] abit:/etc/dump > mt -v mt-st v. 0.5b [17:12] abit:/etc/dump > tar --version | head -1 tar (GNU tar) 1.13.17 [17:12] abit:/etc/dump > ls -l /dev/tape lrwxrwxrwx1 root root4 Jul 14 2000 /dev/tape -> nst0 [17:12] abit:/etc/dump > mt status SCSI 2 tape drive: File number=0, block number=0, partition=0. Tape block size 512 bytes. Density code 0x47 (unknown to this mt). Soft error count since last status=0 General status bits on (4101): BOT ONLINE IM_REP_EN [17:12] abit:/etc/dump > tar cvf /dev/tape /boot tar: Removing leading `/' from member names boot/ boot/kernel.h boot/vmlinuz-2.2.14-12 boot/vmlinuz.prev boot/System.map.prev boot/linux-2.2.14-12 boot/linux-prev boot/linux-2.2.20p6ai boot/module-info boot/boot.b boot/chain.b ... [17:12] abit:/etc/dump > mt status SCSI 2 tape drive: File number=1, block number=0, partition=0. Tape block size 512 bytes. Density code 0x47 (unknown to this mt). Soft error count since last status=0 General status bits on (8101): EOF ONLINE IM_REP_EN [17:12] abit:/etc/dump > mt tell At block 11421. [17:12] abit:/etc/dump > mt rewind [17:13] abit:/etc/dump > mt status SCSI 2 tape drive: File number=0, block number=0, partition=0. Tape block size 512 bytes. Density code 0x47 (unknown to this mt). Soft error count since last status=0 General status bits on (4101): BOT ONLINE IM_REP_EN [17:13] abit:/etc/dump > mt tell At block 0. [17:13] abit:/etc/dump > tar tvf /dev/tape drwxr-xr-x root/root 0 2001-06-25 22:21:52 boot/ -rw-r--r-- root/root 237 2001-05-03 23:04:36 boot/kernel.h -r--r--r-- root/root589225 2000-05-09 05:43:45 boot/vmlinuz-2.2.14-12 -rw-rw-r-- root/root606292 2001-06-25 18:08:21 boot/vmlinuz.prev -rw-rw-r-- root/root195903 2001-06-25 18:08:21 boot/System.map.prev lrwxrwxrwx root/root 0 2001-05-03 23:10:10 boot/linux-2.2.14-12 -> vmlinuz-2.2.14-12 lrwxrwxrwx root/root 0 2001-06-25 18:08:21 boot/linux-prev -> vmlinuz.prev lrwxrwxrwx root/root 0 2001-06-25 18:08:21 boot/linux-2.2.20p6ai -> vmlinuz-2.2.20p6ai-0625-18:08:09 lrwxrwxrwx root/root 0 2000-04-10 21:15:54 boot/module-info -> module-info-2.2.14-5.0 -rw-r--r-- root/root 4568 2000-02-02 14:03:10 boot/boot.b -rw-r--r-- root/root 612 2000-02-02 14:03:10 boot/chain.b ... [17:13] abit:/etc/dump > mt tell At block 11420. [17:14] abit:/etc/dump > mt status SCSI 2 tape drive: File number=0, block number=11420, partition=0. Tape block size 512 bytes. Density code 0x47 (unknown to this mt). Soft error count since last status=0 General status bits on (101): ONLINE IM_REP_EN [17:14] abit:/etc/dump > mt fsf 1 [17:14] abit:/etc/dump > mt tell At block 11421. [17:14] abit:/etc/dump > mt status SCSI 2 tape drive: File number=1, block number=0, partition=0. Tape block size 512 bytes. Density code 0x47 (unknown to this mt). Soft error count since last status=0 General status bits on (8101): EOF ONLINE IM_REP_EN -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PROBLEM: [2.4.6] kernel BUG at softirq.c:206!
Hi! I tried to install kernel 2.4.6 with same configuration as 2.4.5, but booting failed with: kernel BUG at softirq.c:206! invalid operand: CPU:0 EIP:0010:[] EFLAGS: 00010082 eax: 001d ebx: c025bf80 ecx: 0001 edx: c0206628 esi: c025bf80 edi: 0001 ebp: esp: c0213efc ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c0213000) Stack: c01d896c c01d8a08 00ce 0009 c02445c0 c02445c0 c0213f40 c0117d3f c02445c0 c0242900 c010818d c020b5e0 c0213f9f 03c7 c0205ba0 03c7 c0106d80 c020b5e0 03c7 c0213f9f 03c7 Call Trace: [] [] [] [] [] Code: 0f 0b 83 c4 0c 8b 43 08 85 c0 75 18 fb 8b 43 10 50 8b 43 0c Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing +++ Output of ver_linux: Linux marvin 2.4.5 #1 Tue May 29 03:56:38 CEST 2001 i686 unknown Gnu C 2.95.2 Gnu make 3.79.1 binutils 2.10.0.33 util-linux 2.10s mount 2.10s modutils 2.4.6 e2fsprogs 1.19 reiserfsprogs 3.x.0k-pre8 PPP2.4.1 Linux C Libraryx1 root root 1382179 Jan 19 07:14 /lib/libc.so.6 Dynamic linker (ldd) 2.2 Procps 2.0.7 Net-tools 1.57 Kbd1.02 Sh-utils 2.0 Modules Loaded sd_mod af_packet khttpd autofs4 unix 8139too ide-scsi aic7xxx scsi_mod +++ marvin:~ # cat /proc/cpuinfo processor : 0 vendor_id : CyrixInstead cpu family : 6 model : 2 model name : 6x86MX 2.5x Core/Bus Clock stepping: 6 cpu MHz : 167.047 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: yes fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu de tsc msr cx8 pge cmov mmx cyrix_arr bogomips: 333.41 +++ marvin:~ # cat /proc/ioports -001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 01f0-01f7 : ide0 0376-0376 : ide1 03c0-03df : vga+ 03f6-03f6 : ide0 0cf8-0cff : PCI conf1 6000-60ff : Adaptec AIC-7861 6500-65ff : Realtek Semiconductor Co., Ltd. RTL-8139 6500-65ff : 8139too f000-f00f : Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] f000-f007 : ide0 f008-f00f : ide1 +++ marvin:~ # cat /proc/iomem -0009fbff : System RAM 0009fc00-0009 : reserved 000a-000b : Video RAM area 000c-000c7fff : Video ROM 000cc000-000cc7ff : Extension ROM 000f-000f : System ROM 0010-07ff : System RAM 0010-001ccc23 : Kernel code 001ccc24-0020b153 : Kernel data e000-e1ff : nVidia Corporation Vanta [NV6] e200-e2ff : nVidia Corporation Vanta [NV6] e300-e3000fff : Adaptec AIC-7861 e300-e3000fff : aic7xxx e3001000-e30010ff : Realtek Semiconductor Co., Ltd. RTL-8139 e3001000-e30010ff : 8139too - : reserved +++ marvin:~ # lspci -vvv 00:00.0 Host bridge: Intel Corporation 430VX - 82437VX TVX [Triton VX] (rev 02) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- [disabled] [size=64K] 00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 10) Subsystem: Allied Telesyn International: Unknown device 2503 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- [disabled] [size=64K] Capabilities: [60] Power Management version 1 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- +++ marvin:~ # cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 01 Lun: 00 Vendor: TANDBERG Model: TDC 3600Rev: =08: Type: Sequential-AccessANSI SCSI revision: 02 Host: scsi0 Channel: 00 Id: 05 Lun: 00 Vendor: IOMEGA Model: ZIP 100 Rev: C.19 Type: Direct-AccessANSI SCSI revision: 02 Host: scsi0 Channel: 00 Id: 06 Lun: 00 Vendor: SCANNER Model: Rev: 1.01 Type: Scanner ANSI SCSI revision: 01 CCS Host: scsi1 Channel: 00 Id: 00 Lun: 00 Vendor: TEAC Model: CD-W54E Rev: 1.1Y Type: CD-ROM ANSI SCSI revision: 02 +++ .config: CONFIG_X86=y CONFIG_ISA=y CONFIG_UID16=y CONFIG_EXPERIMENTAL=y CONFIG_MODULES=y CONFIG_KMOD=y CONFIG_M586=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_L1_CACHE_SHIFT=5 CON
Re: pcmcia lockup inserting or removing cards in 2.4.5-ac{13,22}
On Tue, 3 Jul 2001 00:30:10, "Trevor Hemsley" <[EMAIL PROTECTED]> wrote: > Somewhere between 2.4.2 and 2.4.5-ac13, PCMCIA card insertion and > removal appears to have broken on my Toshiba Libretto. On 2.4.2 all was > fine. On both 2.4.5-ac13 and ac22 it's broken. The whole machine freezes > solid, no SAK-s, SAK-u, SAK-b, no Ctrl-Alt-Fn to switch VC's. No messages > are issued. Problem occurs when inserting/removing any of YE-Data PCMCIA > floppy, TDK Smartmedia adapter (ide_cs), or 3c589 ethernet card. [large snip] OK, I've done quite a lot more work on this. It isn't 2.4.5, I'd compiled USB support in when I went to 2.4.5 and it's that that causes the problems. I backed out all changes made between 2.4.2 and 2.4.5 in drivers/pcmcia and that made no difference to the lockup so then I went back to the .config file from 2.4.2 and that worked. My best guess is that the USB support is using IRQ 11 and that the PCMCIA card sockets are wired to use that as well. I have a bypass for now - if I set the Toshiba BIOS up to use the slots in PCIC mode then it assigns them IRQ 15. In cardbus mode they get assigned IRQ 11 in Win9x but dmesg reports Linux Kernel Card Services 3.1.22 options: [pci] [cardbus] [pm] PCI: No IRQ known for interrupt pin A of device 00:06.0. Please try using pci=biosirq. PCI: No IRQ known for interrupt pin B of device 00:06.1. Please try using pci=biosirq. and Yenta IRQ list 0eb8, PCI irq0 Socket status: 3007 Yenta IRQ list 0eb8, PCI irq0 Socket status: 3007 Using pci=biosirq makes no difference when in cardbus mode. Ah, got it, flipping the PCMCIA setup in the BIOS from "Auto-detect" to "Cardbus/16 bit" fixes it. lspci -vv now lists the cardbus ports as having IRQ 11 assigned (instead of 0 before). Everything (famous last words) appears to be working. -- Trevor Hemsley, Brighton, UK. [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ACPI in 2.4.6 detects power button twice
I just installed 2.4.6, and turned ACPI on (and APM off). On startup, APCI reports "Power button: found" twice. Also, in /proc/acpi/button there are two directories named "power". acpid is able to see the events properly, tho, and shutdown the computer. This is a Tyan 1598S motherboard running an AMD K6-II 500MHz. Will test code to help get this fixed. :) Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Somebody call an exorcist! -- Dust Puppy User Friendly, 5/16/1998 PGP signature
Re: >128 MB RAM stability problems (again)
Yes, I have an Athlon 700 on a Asus/K7V motherboard with 256 MB PC 133 RAM. Never had any problem with this configuration. Before that, however, there was an Pentium 120 with 64 MB RAM. This one used to crash during kernel-compiles due to an overheated processor. Really funny. Later I got kernel-panics during boot due to pagetable-corruption. This time it was bad RAM and went awayx after I changed one certain module. So I would almost certainly relate Your problem to hardware failure. Good success Peter B - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
framebuffer compile failure in 2.4.7-pre1
Presumably from the ac merge, console_conditional_schedule made it's way into pre1 fbcon.c, but neither the prototype from console.h nor the function from printk.c came with it. (perhaps this requires merging the console lock removal too?) justin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] small patch to ide-tape.c
Pete Zaitcev <[EMAIL PROTECTED]> wrote: > > This patch adds a missing semicolon that is noticed only if you define > > IDETAPE_DEBUG_LOG_VERBOSE: > > > > John Guthrie > > [EMAIL PROTECTED] > > It makes me curious, why do you need to define > IDETAPE_DEBUG_LOG_VERBOSE? > > I fixed some stuff with files not restoring properly > with last block corrupt. Talking with Andre and Gadi now. > What is your problem? I sent out some posts earlier on this. To summarize, I have an HP Colorado 5GB IDE tape drive. I have been able to use mt to move the tape forward, find out where the tape is positioned, rewind it, etc. I have also been able to use tar to write to the tape drive. When I try to use tar to read from the tape drive though, I get the following as output: tar: /dev/ht0: Cannot read: Input/output error tar: At beginning of tape, quitting now tar: Error is not recoverable: exiting now The following also appears in dmesg output when I try to run the tar command: ide-tape: Reached idetape_chrdev_open ide-tape: ht0: I/O error, pc = 8, key = 5, asc = 2c, ascq = 0 Willem Riede suggested to me that I try turning IDETAPE_DEBUG_LOG_VERBOSE on to help with debugging. That iswhen I ran into this line that as missing a semicolon. John Guthrie [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: unable to read from IDE tape
References: <[EMAIL PROTECTED]> Note: the following is my reply to a private reply to my initial post regarding my problem reading from my tape drive. I thought that this info might be helpful on the mailing list as well. Willem Riede <[EMAIL PROTECTED]> wrote: > John Guthrie wrote: > > > > Hi all, > > > > Lately, I have been having problems reading from from my HP Colorado IDE > > tape drive. I can use mt to get the status of the drive and to forward the > > drive to a different file. I can even use tar to write to the tape. > > But whenever I try to read the tar files that I have written to tape, I > > get an I/O error, and there doesn't even seem to be any attempt by the > > Can you be more specific, and post exactly what commands you issued after > inserting the tape, and what error you get when, including any log messages? First, I run mt rewind just to get the tape back to the beginning. (I think that I may have /dev/tape as asymlink to /dev/nht0, not /dev/ht0.) Then just as a test, I can do something like tar -cvf /dev/nht0 /boot This command actually runs fine with no errors. If I then run mt status I get the output SCSI 2 tape drive: File number=0, block number=16841, partition=0. Tape block size 512 bytes. Density code 0x0 (default). Soft error count since last status=0 General status bits on (0): At least the block number is non-zero as I should expect it to be since I did the tar to /dev/nht0. If I then run mt rewind; mt status I get the output SCSI 2 tape drive: File number=0, block number=0, partition=0. Tape block size 512 bytes. Density code 0x0 (default). Soft error count since last status=0 General status bits on (0): So now the block number is at 0, which is good since I did just rewind the thing. At this point, I would expect (perhaps mistakenly) that I should be able to run the following tar -tf /dev/ht0 The output of this command is tar: /dev/ht0: Cannot read: Input/output error tar: At beginning of tape, quitting now tar: Error is not recoverable: exiting now > > > driver to read the tape. This is currently happening under 2.4.5, and > > has been happening undeer at least 2.4.2 and 2.4.3, I think it was also > > happening under 2.4.1 as well. > > Can you verify that (by rebooting to previous kernels if you still have them)? > Does it happen with all your tapes? This is the same error that I have gotten from both 2.4.2 and 2.4.3. It definitely happens with all of my tapes including my new ones. (Due to circumstanes of my setup, I can't verify 2.4.1 this exact minute, but I can get back to you on that.) I am also getting the following lines of dmesg output: ide-tape: Reached idetape_chrdev_open ide-tape: ht0: I/O error, pc = 8, key = 5, asc = 2c, ascq = 0 I don't know if this helps. Apparently IDETAPE_DEBUG_LOG is set to 1 by default. Which actually results in a large number of copies of the first line. I only get the second line when I try to open the tape for reading. > Regards. Willem Riede. John Guthrie [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Mail list archives down
David Balazic <[EMAIL PROTECTED]> writes: > I noticed 4 out of 5 LKML web archives listed in the FAQ are down as > of today. I guess the FAQ needs updating. Here is one that seems to work: http://www.lib.uaa.alaska.edu/linux-kernel/ > -- Håvard Kvålen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.4.6-ac1 fix error in drivers/parport/parport_pc.c
I got this error building 2.4.6-ac1.
drivers/parport/driver.o: In function `parport_pc_find_ports':
drivers/parport/driver.o(.text.init+0x3f2): undefined reference to `init_pnp040x'
drivers/parport/driver.o(.text.init+0x400): undefined reference to
`pnpbios_find_device'
drivers/parport/driver.o(.text.init+0x412): undefined reference to `init_pnp040x'
drivers/parport/driver.o(.text.init+0x420): undefined reference to
`pnpbios_find_device'
make: *** [vmlinux] Error 1
My access to lkml archives is temporarily gone (marc.theaimsgroup.com is down
and other archive sites aren't very current), so please forgive me if someone else
has already posted this fix.
Here is a patch which may be correct. It worked for me.
Steven
--- linux-2.4.6-ac1/drivers/parport/parport_pc.c.original Wed Jul 4 15:22:28
2001
+++ linux/drivers/parport/parport_pc.c Wed Jul 4 15:26:03 2001
@@ -2828,12 +2828,14 @@
detect_and_report_smsc ();
#endif
+#if defined (CONFIG_PNPBIOS) || defined (CONFIG_PNPBIOS_MODULE)
dev=NULL;
while ((dev=pnpbios_find_device("PNP0400",dev)))
count+=init_pnp040x(dev);
dev=NULL;
while ((dev=pnpbios_find_device("PNP0401",dev)))
count+=init_pnp040x(dev);
+#endif
/* Onboard SuperIO chipsets that show themselves on the PCI bus. */
count += parport_pc_init_superio (autoirq, autodma);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: >128 MB RAM stability problems (again)
Ronald Bultje wrote: > > Hi, > > you might remember an e-mail from me (two weeks ago) with my problems > where linux would not boot up or be highly instable on a machine with > 256 MB RAM, while it was 100% stable with 128 MB RAM. Basically, I still > have this problem, so I am running with 128 MB RAM again. Some motherboards have ram requirements that might not be obvious without reading the m/b manual. For example, some m/b's require registered memory. Some don't work with ECC. Some require modules be installed in pairs (of exact type match). Some require that larger memory sticks be placed in earlier slots relative to smaller modules. And if you add a wait state in the bios a marginal ram module can become quite stable; the unstable version can behave differently under different circumstances (including temperature). Check the m/b manual and m/b web site for exact requirements, and make sure the ram matches; even if your memory is good, it might not be good in your circumstances. D. Stimits, [EMAIL PROTECTED] > > I've been running Mandrake 7.2 on another machine for some time - no > problem, until. I added another 64 MB RAM and tried to install > redhat (25 times (!!!)) and Mandrake 8.0... Both crash with memory > faults. Redhat just freezes or givesa a python warning, Mandrake > gives a segfault with a warning that "memory is missing" Both refuse > to complete installation... > > I'm kind of astounded now, WHY can't linux-2.4.x run on ANY machine in > my house with more than 128 MB RAM?!? Can someone please point out to me > that he's actually running kernel-2.4.x on a machine with more than 128 > MB RAM and that he's NOT having severe stability problems? > And can that same person PLEASE point out to me why 2.4.x is crashing on > me (or help me to find out...)? > > First machine is a Intel P-II 400 with 128 MB RAM (133 MHz SDRAM) and > crashing when I insert an additional 128 - it's running RH-7.0 with > kernel-2.4.4. Second machine is an AMD Duron 600 with 196 MB RAM (also > 133 MHz SDRAM), crashing during the installation of both Mandrake 8.0 > and Redhat 7.1 and which used to run stable with 128 MB RAM or 64 MB RAM > with Mandrake-7.2. Win2k runs stable on this machine in all > configurations. > > I'm getting desperate win2k is running stable and it's scary to see > linux crash while win2k runs stable and smooth. > > (ps I'm not subscribed to the list - please CC a copy to me when > replying) > > Thanks in advance for any help on this, > > -- > Ronald Bultje > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Suitable Athlon Motherboard for Linux
Well, I have an Acer AK73 Pro(A), with an Athlon 1.333 GHz (133 FSB). I have never had anuy lockup or data corruption problems. I do run this system as a dual-boot, usually under Win2K :( The system is as follows: Acer AK73 Pro(A) Athlon (C) 1.333 GHz IBM DTLA307060 60G IDE hard drive Creative labs RW1210E CD rewriter IOmega Zip250 Matrox G450 Creative SB Live Value 5.1 D-Link network card (RTL8139) Pretty much the exact equipment that everyone complains about, but I can recompile kernels (fast!), copy large files, play music, and drag windows around in X - without any problems. I haven't used this system under Linux too much, so I can't say for sure that it is much better than other Via-based systems, but it does seem to be better. I haven't done any tweaking to the stock RH7.1 install, except for building a 2.4.4 kernel (I'm on the Win2K boot now - I can't remember if I had Athlon optimizations on or not). There are several things that I did with this system: First, I got a big power supply - 400 watts. This is with 1 hard drive, and only 3 I/O cards. Second, I got one of the AMD retail CPU's. The difference in price was small (maybe 10%), and it includes a GUARANTEED good fan - plus it has a 3-year warrantee. Third, I didn't buy the cheapest motherboard on the market. I have had excellent experiences with Acer products (since the '486 days), and this is one more positive experience for me. Let me know if you would like my kernel .config for experimentation. (not that I have done anything great to it - it just seems to work :) - Steve Joseph Mathewson wrote: [snip] > I can't see much alternative to Via chipsets in the Ahtlon market, other > than all-in-one-graphics-sound-network jobbies that, from previous > experience (namely the i810), are also best avoided. > > Joe. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
loop device corruption in 2.4.6
Hello, I get repeatable errors with 2.4.6 patched with the international encryption patch patch-int-2.4.3.1.bz2 when building loop device filesystems on top of Reiserfs. All I have to do is: 1. dd if=/dev/zero of=testfs bs=1024 count=10 2. losetup -e aes /dev/loop0 ./testfs 3. mke2fs /dev/loop0 4. mount /dev/loop0 ./test 5. cd test ; touch m ; cd .. 6. umount ./test 7. losetup -d /dev/loop0 8. losetup -e aes /dev/loop0 ./testfs 9. e2fsck /dev/loop0 *** All heck breaks loose. The thing is, I can still mount previously created AES loopback filesystems but I can't e2fsck them. Well, if I do I get the following: e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 Group descriptors look bad... trying backup blocks... Inode count in superblock is 27112, should be 25064. Fix? yes Block bitmap for group 0 is not in group. (block 1569951131) Relocate? yes Inode bitmap for group 0 is not in group. (block 1258458187) Relocate? yes Inode table for group 0 is not in group. (block 865539952) WARNING: SEVERE DATA LOSS POSSIBLE. Relocate? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: >128 MB RAM stability problems (again)
On 04 Jul 2001 17:06:51 -0300, Alessandro Motter Ren wrote: > > Which filesystem are you using on this machine? > []s. ext2 -- Ronald - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: O_DIRECT! or O_DIRECT?
In article <[EMAIL PROTECTED]>, Stephen C. Tweedie <[EMAIL PROTECTED]> wrote: >Hi, > >On Wed, Jul 04, 2001 at 06:27:13PM +, Miquel van Smoorenburg wrote: >> >> Any chance of something like O_SEQUENTIAL (like madvise(MADV_SEQUENTIAL)) > >What for? The kernel already optimises readahead and writebehind for >sequential files. Yes, but I really do mean like in madvise(). >If you want to provide specific extra hints to the kernel, then things >like O_UNCACHE might be more appropriate to instruct the kernel to >explicitly remove the cached page after IO completes (to avoid the VM >overhead of maintaining useless cache). That would provide a definite >improvement over normal IO for large multimedia-style files or for >huge copies. But what part of the normal handling of sequential files >would O_SEQUENTIAL change? Good handling of sequential files should >be the default, not an explicitly-requested feature. exactly what I meant, since that is what MADV_SEQUENTIAL seems to do: linux/mm/filemap.c: * MADV_SEQUENTIAL - pages in the given range will probably be accessed * once, so they can be aggressively read ahead, and * can be freed soon after they are accessed. /* * Read-ahead and flush behind for MADV_SEQUENTIAL areas. Since we are * sure this is sequential access, we don't need a flexible read-ahead * window size -- we can always use a large fixed size window. */ static void nopage_sequential_readahead(struct vm_area_struct * vma, O_SEQUENTIAL perhaps is the wrong name. I'd like to see this so I can run tar to backup a machine during the day (if tar used this flag, ofcourse) without performance going down the drain because of cache pollution. Mike. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: >128 MB RAM stability problems (again)
> From: Alessandro Motter Ren [mailto:[EMAIL PROTECTED]] > > > Which filesystem are you using on this machine? > []s. > ext2fs on the production farm but I also have a pair of machines (SMB P-III 800) using reiserfs on mail spools. That pair of machines is not particularly busy, though. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: >128 MB RAM stability problems (again)
Which filesystem are you using on this machine? []s. -Original Message- From: George Bonser [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 04, 2001 5:06 PM To: Ronald Bultje; Linux Kernel Mailing List Subject: RE: >128 MB RAM stability problems (again) > I'm kind of astounded now, WHY can't linux-2.4.x run on ANY machine in > my house with more than 128 MB RAM?!? Can someone please point out to me > that he's actually running kernel-2.4.x on a machine with more than 128 > MB RAM and that he's NOT having severe stability problems? Running 2.4.6-pre and 2.4.6 proper on several machines. Quite busy and all have 256 to 512MB of RAM. As I type this, I am in the process of converting an entire production server farm over to 2.4.6 from 2.2.19 as the 2.4.6-pre series proved out well on a test machine in that farm. No stability problems at all. The only reboots were for patching up the kernel to the next -pre revision on that test box. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: >128 MB RAM stability problems (again)
On 4 Jul 2001, Ronald Bultje wrote: > Hi, > > you might remember an e-mail from me (two weeks ago) with my problems > where linux would not boot up or be highly instable on a machine with > 256 MB RAM, while it was 100% stable with 128 MB RAM. Basically, I still > have this problem, so I am running with 128 MB RAM again. I suggest you look into the memory settings in your BIOS, and change them to the most conservative available. Or, throw out your memory and buy some from a reputable manufacturer. Your problem is definitely hardware. There are racks full of linux machines with more than 128 MB RAM running kernel 2.4 all over the world. I personally installed a dozen. It always works fine. -jwb - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: >128 MB RAM stability problems (again)
> I'm kind of astounded now, WHY can't linux-2.4.x run on ANY machine in > my house with more than 128 MB RAM?!? Can someone please point out to me > that he's actually running kernel-2.4.x on a machine with more than 128 > MB RAM and that he's NOT having severe stability problems? Running 2.4.6-pre and 2.4.6 proper on several machines. Quite busy and all have 256 to 512MB of RAM. As I type this, I am in the process of converting an entire production server farm over to 2.4.6 from 2.2.19 as the 2.4.6-pre series proved out well on a test machine in that farm. No stability problems at all. The only reboots were for patching up the kernel to the next -pre revision on that test box. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ide-scsi problem in 2.4.6?!?
Hi folks, there seems to be a problem in the 2.4.6. kernel, but unluckily, I have no idea what it is. Seriously: Let me tell you the whole story: I tend to burn a lot of CDs using my IDE CD-writer. In order to accomplish that, I'm using cdrecord 1.11a04, of course in conjunction with the ide-scsi emulation in the kernel. Now, up to 2.4.5 this has always worked fine - with 2.4.5 alone, I have probably burned a few dozen CDs without any problems. Today I updated to 2.4.6. I did not update any other software on my computer, only the kernel. When I now try to burn a CD with cdrecord, it fails in about 80% of all cases (yes, I've already wasted about 5 CDs trying to figure out what's wrong). What happens is the following: The burn process starts fine, but then, suddenly, after about 24 MB have been written, the process suddenly stops, giving me a bunch of SCSI error messages on the screen, including one that tells me something about "Streaming lost..." Now, I'm not a hard-core programmer, but I've still tried to figure out where the problem lies. Obviously, since everything worked fine under 2.4.5, and since the problem only occured after updating to 2.4.6, while everything else on my machine remained the same, it seems as if the problem has something to do with the kernel. What comes to my mine first is, of course, the ide-scsi stuff. However, since I'm using a VIA-based Athlon system, I also wouldn't exclude the possibility of this being another manifestation of the VIA-bug. Currently, I seem to be able to work around the problem by turning the BURN-Proof feature of my CD-burner on. I've never used it before, and what I can see from the information cdrecord shows on the screen, the buffer is not nearly empty when the burn process suddenly stops, but still BURN-Proof seems to help. Just note that I never had any problems with kernels < 2.4.6 that required me to use BURN-Proof. I guess that if this is really a problem with the kernel (and it really seems to be), then others will also see this problem. If so, I'd be glad to hear about it. Again: I'm not a kernel-hacker, but I hope that if we're really facing a serious problem here, enough information can be gathered so that someone can fix it. Greetings Nils -- -- Nils Holland - [EMAIL PROTECTED] NightCastle Productions - Linux in Tiddische, Germany http://www.nightcastleproductions.org "Give the heavens above more than just a passing glance And when you get the choice to sit it out or dance - I hope you dance!" -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Suitable Athlon Motherboard for Linux
Hans-Christian Armingeon wrote: > On Wednesday, 4. July 2001 20:49, Joseph Mathewson wrote: > > Having heard the various horror stories about the VIA PCI data corruption > > bugs, and watching one Via based machine destroy itself with a Mandrake 8.0 > > 2.4.3, I was just wondering if anyone had a suggestion for an Athlon > > motherboard that works reliably under Linux (I don't think all the issues > > have been cleared up in the kernel yet?). There must be quite a few Linux > > Athlon users out there - what boards are you using and with what success? > > > > I can't see much alternative to Via chipsets in the Ahtlon market, other > > than all-in-one-graphics-sound-network jobbies that, from previous > > experience (namely the i810), are also best avoided. What about Ali chipsets, like in ASUS A7A266 ? > > > > > Joe. > > > I think the SIS chipset based mainboards will be at a very good performance, > even faster than VIA. I read it in the german c't magazine. > > Johnny > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: >128 MB RAM stability problems (again)
Ditto. One with 320, one with 256 and one with 192. All dual booting Win98 or Win2k and Mandrake 8.0 with 2.4.3. Scott - Original Message - From: "Alan Cox" <[EMAIL PROTECTED]> To: "Ronald Bultje" <[EMAIL PROTECTED]> Cc: "Linux Kernel Mailing List" <[EMAIL PROTECTED]> Sent: Wednesday, July 04, 2001 2:29 PM Subject: Re: >128 MB RAM stability problems (again) > > I'm kind of astounded now, WHY can't linux-2.4.x run on ANY machine in > > my house with more than 128 MB RAM?!? Can someone please point out to me > > Can I suggest you change your memory vendor and/or get an antistatic wrist > strap ? > > > that he's actually running kernel-2.4.x on a machine with more than 128 > > MB RAM and that he's NOT having severe stability problems? > > Multiple boxes, all solid with 256Mb > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: >128 MB RAM stability problems (again)
Asus K7V here, 800 MHz Athlon oc to 880 MHz, 256 Mb, occasional XFree86 lockups, otherwise stable with almost any of the v2.4.x series including -ac variants and the testing kernels. Right now 2.4.6-pre5, doing fine. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Suitable Athlon Motherboard for Linux
On Wednesday, 4. July 2001 20:49, Joseph Mathewson wrote: > Having heard the various horror stories about the VIA PCI data corruption > bugs, and watching one Via based machine destroy itself with a Mandrake 8.0 > 2.4.3, I was just wondering if anyone had a suggestion for an Athlon > motherboard that works reliably under Linux (I don't think all the issues > have been cleared up in the kernel yet?). There must be quite a few Linux > Athlon users out there - what boards are you using and with what success? > > I can't see much alternative to Via chipsets in the Ahtlon market, other > than all-in-one-graphics-sound-network jobbies that, from previous > experience (namely the i810), are also best avoided. > > Joe. > I think the SIS chipset based mainboards will be at a very good performance, even faster than VIA. I read it in the german c't magazine. Johnny - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: >128 MB RAM stability problems (again)
> I'm kind of astounded now, WHY can't linux-2.4.x run on ANY machine in > my house with more than 128 MB RAM?!? Can someone please point out to me Can I suggest you change your memory vendor and/or get an antistatic wrist strap ? > that he's actually running kernel-2.4.x on a machine with more than 128 > MB RAM and that he's NOT having severe stability problems? Multiple boxes, all solid with 256Mb - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: >128 MB RAM stability problems (again)
Ronald Bultje <[EMAIL PROTECTED]> wrote: > > you might remember an e-mail from me (two weeks ago) with my problems > where linux would not boot up or be highly instable on a machine with > 256 MB RAM, while it was 100% stable with 128 MB RAM. Basically, I still > have this problem, so I am running with 128 MB RAM again. [...] > I'm getting desperate win2k is running stable and it's scary to see > linux crash while win2k runs stable and smooth. It's likely hardware problems. Different OSes excercise the memory subsystems quite differently, so it's possible (and common) to see problems in one OS where another appears to run fine. Download memtest86 and test your system with 256MB in it -- if it reports any problems, it's definitely hardware. Charles -- --- Charles Cazabon<[EMAIL PROTECTED]> GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: >128 MB RAM stability problems (again)
Ronald Bultje wrote: > I'm kind of astounded now, WHY can't linux-2.4.x run on ANY machine in > my house with more than 128 MB RAM?!? Can someone please point out to me > that he's actually running kernel-2.4.x on a machine with more than 128 > MB RAM and that he's NOT having severe stability problems? I don't have the answer for your situation, but in answer to one of your questions I can happily enumerate the following boxes I installed, all of which are running 2.4.x kernels on Red Hat 7.1 with excellent stability and performance: "Name Brand" boxes: (3) Dell 2450s, Dual P3-1000, 512 MB RAM (2) HP Netservers, P3-700, 512 MB RAM Compaq 6500, Quad PPro 200, 1 GB RAM Self built clone boxes: AMD K6/2 450, 256 MB RAM, low end ASUS mb P3-933, 512 MB RAM, Intel i810 motherboard P3-866, 512 MB RAM, Aopen motherboard and more - These boxes either have an uptime dating from the initial 7.1 install (60+ days), or from the last kernel update - cu jjs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Suitable Athlon Motherboard for Linux
On Wed, 4 Jul 2001, Joseph Mathewson wrote: > Having heard the various horror stories about the VIA PCI data corruption > bugs, and watching one Via based machine destroy itself with a Mandrake 8.0 > 2.4.3, I was just wondering if anyone had a suggestion for an Athlon > motherboard that works reliably under Linux (I don't think all the issues > have been cleared up in the kernel yet?). There must be quite a few Linux > Athlon users out there - what boards are you using and with what success? > > I can't see much alternative to Via chipsets in the Ahtlon market, other > than all-in-one-graphics-sound-network jobbies that, from previous > experience (namely the i810), are also best avoided. > > Joe. I have a D-700 on an Asus A7V (VIA 82C686A) with BIOS revision 1007 running Red Hat 7.1 with kernel 2.4.3-12. Stability seems to be fairly good, with occasional lockups in XFree86. If you need more details, feel free to ask. -- Ignacio Vazquez-Abrams <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
>128 MB RAM stability problems (again)
Hi, you might remember an e-mail from me (two weeks ago) with my problems where linux would not boot up or be highly instable on a machine with 256 MB RAM, while it was 100% stable with 128 MB RAM. Basically, I still have this problem, so I am running with 128 MB RAM again. I've been running Mandrake 7.2 on another machine for some time - no problem, until. I added another 64 MB RAM and tried to install redhat (25 times (!!!)) and Mandrake 8.0... Both crash with memory faults. Redhat just freezes or givesa a python warning, Mandrake gives a segfault with a warning that "memory is missing" Both refuse to complete installation... I'm kind of astounded now, WHY can't linux-2.4.x run on ANY machine in my house with more than 128 MB RAM?!? Can someone please point out to me that he's actually running kernel-2.4.x on a machine with more than 128 MB RAM and that he's NOT having severe stability problems? And can that same person PLEASE point out to me why 2.4.x is crashing on me (or help me to find out...)? First machine is a Intel P-II 400 with 128 MB RAM (133 MHz SDRAM) and crashing when I insert an additional 128 - it's running RH-7.0 with kernel-2.4.4. Second machine is an AMD Duron 600 with 196 MB RAM (also 133 MHz SDRAM), crashing during the installation of both Mandrake 8.0 and Redhat 7.1 and which used to run stable with 128 MB RAM or 64 MB RAM with Mandrake-7.2. Win2k runs stable on this machine in all configurations. I'm getting desperate win2k is running stable and it's scary to see linux crash while win2k runs stable and smooth. (ps I'm not subscribed to the list - please CC a copy to me when replying) Thanks in advance for any help on this, -- Ronald Bultje - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] Re: alpha - generic_init_pit - why using RTC for calibration?
On Fri, Jun 29, 2001 at 09:19:31PM +0400, Ivan Kokshaysky wrote:
> Good idea. The patch below works reliably on my sx164.
Reasonable. Here I've cleaned up time_init a tad as well.
r~
--- arch/alpha/kernel/time.c.orig Fri Jun 29 11:24:03 2001
+++ arch/alpha/kernel/time.cFri Jun 29 11:35:52 2001
@@ -169,6 +169,77 @@ common_init_rtc(void)
init_rtc_irq();
}
+/*
+ * Calibrate CPU clock using legacy 8254 timer/counter. Stolen from
+ * arch/i386/time.c.
+ */
+
+#define CALIBRATE_LATCH(52 * LATCH)
+#define CALIBRATE_TIME (52 * 120 / HZ)
+
+static unsigned long __init
+calibrate_cc_with_pic(void)
+{
+ int cc;
+ unsigned long count = 0;
+
+ /* Set the Gate high, disable speaker */
+ outb((inb(0x61) & ~0x02) | 0x01, 0x61);
+
+ /*
+* Now let's take care of CTC channel 2
+*
+* Set the Gate high, program CTC channel 2 for mode 0,
+* (interrupt on terminal count mode), binary count,
+* load 5 * LATCH count, (LSB and MSB) to begin countdown.
+*/
+ outb(0xb0, 0x43); /* binary, mode 0, LSB/MSB, Ch 2 */
+ outb(CALIBRATE_LATCH & 0xff, 0x42); /* LSB of count */
+ outb(CALIBRATE_LATCH >> 8, 0x42); /* MSB of count */
+
+ cc = rpcc();
+ do {
+ count++;
+ } while ((inb(0x61) & 0x20) == 0);
+ cc = rpcc() - cc;
+
+ /* Error: ECTCNEVERSET */
+ if (count <= 1)
+ goto bad_ctc;
+
+ /* Error: ECPUTOOFAST */
+ if (count >> 32)
+ goto bad_ctc;
+
+ /* Error: ECPUTOOSLOW */
+ if (cc <= CALIBRATE_TIME)
+ goto bad_ctc;
+
+ return ((long)cc * 100) / CALIBRATE_TIME;
+
+ /*
+* The CTC wasn't reliable: we got a hit on the very first read,
+* or the CPU was so fast/slow that the quotient wouldn't fit in
+* 32 bits..
+*/
+ bad_ctc:
+ return 0;
+}
+
+/* The Linux interpretation of the CMOS clock register contents:
+ When the Update-In-Progress (UIP) flag goes from 1 to 0, the
+ RTC registers show the second which has precisely just started.
+ Let's hope other operating systems interpret the RTC the same way. */
+
+static unsigned long __init
+rpcc_after_update_in_progress(void)
+{
+ do { } while (!(CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP));
+ do { } while (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP);
+
+ return rpcc();
+}
+
void __init
time_init(void)
{
@@ -176,24 +247,15 @@ time_init(void)
unsigned long cycle_freq, one_percent;
long diff;
- /*
-* The Linux interpretation of the CMOS clock register contents:
-* When the Update-In-Progress (UIP) flag goes from 1 to 0, the
-* RTC registers show the second which has precisely just started.
-* Let's hope other operating systems interpret the RTC the same way.
-*/
- do { } while (!(CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP));
- do { } while (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP);
+ /* Calibrate CPU clock -- attempt #1. */
+ if (!est_cycle_freq)
+ est_cycle_freq = calibrate_cc_with_pic();
- /* Read cycle counter exactly on falling edge of update flag */
- cc1 = rpcc();
+ cc1 = rpcc_after_update_in_progress();
+ /* Calibrate CPU clock -- attempt #2. */
if (!est_cycle_freq) {
- /* Sometimes the hwrpb->cycle_freq value is bogus.
- Go another round to check up on it and see. */
- do { } while (!(CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP));
- do { } while (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP);
- cc2 = rpcc();
+ cc2 = rpcc_after_update_in_progress();
est_cycle_freq = cc2 - cc1;
cc1 = cc2;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[OT] Suitable Athlon Motherboard for Linux
Having heard the various horror stories about the VIA PCI data corruption bugs, and watching one Via based machine destroy itself with a Mandrake 8.0 2.4.3, I was just wondering if anyone had a suggestion for an Athlon motherboard that works reliably under Linux (I don't think all the issues have been cleared up in the kernel yet?). There must be quite a few Linux Athlon users out there - what boards are you using and with what success? I can't see much alternative to Via chipsets in the Ahtlon market, other than all-in-one-graphics-sound-network jobbies that, from previous experience (namely the i810), are also best avoided. Joe. +-+ | Joseph Mathewson <[EMAIL PROTECTED]> | +-+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: O_DIRECT! or O_DIRECT?
Hi, On Wed, Jul 04, 2001 at 06:27:13PM +, Miquel van Smoorenburg wrote: > In article <[EMAIL PROTECTED]>, > Stephen C. Tweedie <[EMAIL PROTECTED]> wrote: > >For these reasons, buffered IO is often faster than O_DIRECT for pure > >sequential access. The downside it its greater CPU cost and the fact > >that it pollutes the cache (which, in turn, causes even _more_ CPU > >overhead when the VM is forced to start reclaiming old cache data to > >make room for new blocks.) > > Any chance of something like O_SEQUENTIAL (like madvise(MADV_SEQUENTIAL)) What for? The kernel already optimises readahead and writebehind for sequential files. If you want to provide specific extra hints to the kernel, then things like O_UNCACHE might be more appropriate to instruct the kernel to explicitly remove the cached page after IO completes (to avoid the VM overhead of maintaining useless cache). That would provide a definite improvement over normal IO for large multimedia-style files or for huge copies. But what part of the normal handling of sequential files would O_SEQUENTIAL change? Good handling of sequential files should be the default, not an explicitly-requested feature. Cheers, Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: O_DIRECT! or O_DIRECT?
In article <[EMAIL PROTECTED]>, Stephen C. Tweedie <[EMAIL PROTECTED]> wrote: >For these reasons, buffered IO is often faster than O_DIRECT for pure >sequential access. The downside it its greater CPU cost and the fact >that it pollutes the cache (which, in turn, causes even _more_ CPU >overhead when the VM is forced to start reclaiming old cache data to >make room for new blocks.) Any chance of something like O_SEQUENTIAL (like madvise(MADV_SEQUENTIAL)) Mike. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: O_DIRECT! or O_DIRECT?
Hi, On Wed, Jul 04, 2001 at 12:34:35AM +0400, Samium Gromoff wrote: > > This is interesting, because one real advantage > of O_DIRECT are these greased weasel fast 15-20 Mb/s > file copies, which ones makes windoze users to look > on us as on lesser beings. Not true. O_DIRECT does not speed up sequential file accesses. If anything, it may well slow them down, especially for writes. What O_DIRECT does is twofold --- it guarantees physical IO to the disk (so that you know for sure that the data is on disk for writes, or that the data on disk is readable for reads); and it avoids the memory and CPU overhead of keeping any cached copy of the data. But because O_DIRECT is completely synchronous, it's not possible for the kernel to implement its normal readahead and writebehind IO clustering for direct IO. If you use the normal approach of writing 4k at a time to an O_DIRECT file, things may well be *massively* slower than usual because the kernel is sending individual 4k IOs to the disk, and because it is waiting for each IO to complete before the application provides the next one. On the contrary, buffered writes allow the kernel to batch those 4k writes into large disk IOs, perhaps 100k or more; and the kernel can maintain a queue of more than one such IO, so that once the first IO completes the next one is immediately ready to be sent out. For these reasons, buffered IO is often faster than O_DIRECT for pure sequential access. The downside it its greater CPU cost and the fact that it pollutes the cache (which, in turn, causes even _more_ CPU overhead when the VM is forced to start reclaiming old cache data to make room for new blocks.) O_DIRECT is great for cases like multimedia (where you want to maximise CPU available to the application and where you know in advance that the data is unlikely to fit in cache) and databases (where the application is caching things already and extra copies in memory are just a waste of memory). It is not an automatic win for all applications. Cheers, Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Mail list archives down
On Wed, Jul 04, 2001 at 07:17:08PM +0200, David Balazic wrote: > I noticed 4 out of 5 LKML web archives listed in the FAQ > are down as of today. Here is another one that updates in real time but doesn't support thread mode: http://www.geocrawler.com/lists/3/Linux/35/0/ . Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Don't feed the trooll [offtopic] Re: Why Plan 9 C compilers don'thave asm("")
Hey folks, Just a quick reminder: don't feed the troll. He's very hungry. -ben - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why Plan 9 C compilers don't have asm("")
In article <[EMAIL PROTECTED]>,
Cort Dougan <[EMAIL PROTECTED]> wrote:
>
>There isn't such a crippling difference between straight-line and code with
>unconditional branches in it with modern processors. In fact, there's very
>little measurable difference.
Oh, the small details get to you eventually.
And it's not just the "call" and "ret" instructions. They _do_ hurt,
even on modern CPU's, btw. They tend to break up the prefetching, and
often mean that you cannot do as good of a instruction mix.
But there's an even more serious problem: a function call in C is a
VERY heavy operation as far as the compiler is concerned. It's a major
sequence point, and the compiler doesn't know what memory locations are
potentially dead etc.
Which means that the compiler has to save everything that might be
relevant to memory, and depending on the calling convention has to
assume that registers are trashed. And when you come back, you have to
re-load everything again, on the assumption that the function might have
changed state.
You also often have issues like reloading the gp pointer on many 64-bit
architectures, where functions can be in different "domains", and
returning from an unknown function means that you have to do other nasty
setup in order to get at your global data.
And trust me, it's noticeable. On alpha, a fast function call _should_
be a a simple two-cycle thing - branch and return. But because of
practical linker issues, what the compiler ends up having to generate
for calls to targets that it doesn't know where they are is
- load a 64-bit address off the GP area that the linker will have fixed
up.
- do an indirect branch to that address
- the callee re-loads the GP with _its_ copy of the GP if it needs any
global data or needs to call anybody else.
- we return to the caller
- the caller reloads its GP.
Your theoretical two cycles that the CPU could follow in the front end
and speculate around turns into multiple loads, a indirect branch and
about 10 instructions. And that's without any of the other effects even
being taken into account. No matter _how_ good the CPU is, that's going
to be slower than not doing it.
[ And yes, I know there are optimizing linkers for the alpha around that
improve this and notice when they don't need to change GP and can do a
straight branch etc. I don't think GNU ld _still_ does that, but who
knows. Even the "good" Digital compilers tended to nop out unnecessary
instructions rather than remove them, causing more icache pressure on
a CPU that was already famous for needing tons of icache ]
Now, you could get around a bit of this by allowing for special calling
conventions. Gcc actually has this for some details - namely the
"register arguments" part, which actually makes for much more readable
code (that's my main personal use for it - never mind the fact that it
is probably faster _too_).
But gcc doesn't have a good "you can re-order this call wrt other stuff"
setup, and gcc lacks the ability to change the calling convention
on-the-fly ("this function will not clobber any registers").
Try it and see. There are good reasons for "inline asm", not the least
of which is that it often makes the produced code much more readable.
And if you never look at the produced assembler code, then you'll never
have a fast system. Really. Compilers can do only so much. People who
understand what the end result is makes for a difference.
Now, you could probably argue that instead of inline asms we should have
more flexibility in doing a per-callee calling convention. That would be
good too, no question about it.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Mail list archives down
I noticed 4 out of 5 LKML web archives listed in the FAQ are down as of today. They are listed in the LKML FAQ at http://www.tux.org/lkml/ : 1. http://www.uwsg.indiana.edu/hypermail/linux/kernel/index.html this is the only on that works for me. It is missing most of todays messages. I guess is is not updated in real time. 2. http://boudicca.tux.org/hypermail/linux-kernel/ This one is inaccessible for several days. ( gives a connection timeout ) 3. http://marc.theaimsgroup.com/?l=linux-kernel The site says : Due to another 3Ware-driver-related system crash, marc.theaimsgroup.com and lists.kde.org are down. 4. http://kernelnotes.org/lnxlists/linux-kernel/ Inaccessible site. ( gives a connection timeout ) 5. http://web.gnu.walfield.org/mail-archive/linux-kernel The site responds , but is empty. There are no messages archived. Conspiracy theories ? -- David Balazic -- "Be excellent to each other." - Bill & Ted - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus vs. AC kernels
The -ac and Linus tree merging is not remotely in order of -ac releases, That does make it more complex to classify - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Acpi] Re: ACPI fundamental locking problems
On Wed, 4 Jul 2001, Alan Cox wrote: > > > I argued this at the very beginning, but there was a very strong > > view that you needed to run most of the code before you had a user > > space to run it in. I've not followed things closely enough to > > That bit is clearly untrue. It's untrue only in the sense of "it is technically possible to do it", but it _is_ true that right now it's not very convenient to set up an easy initrd system. We migth want to just make initrd a built-in thing in the kernel, something that you simply cannot avoid. A lot of these things (ie dhcp for NFS root etc) are right now done in kernel space, simply because we don't want to depend on initrd, and people want to use old loaders. I don't like the current initrd very much myself, I have to admit. I'm not going to accept a "you have to have a ramdisk" approach - I think the ramdisks are really broken. But I've seen a "populate ramfs from a tar-file built into 'bzImage'" patch somewhere, and that would be a whole lot more palatable to me. If anybody were to send me a patch that just unconditionally does this, I would probably not be adverse to putting it into 2.5.x. We have all the infrastructure to make all this a lot cleaner than it used to be (ie the "pivot_root()" stuff etc means that we can _truly_ do things from user mode, with no magic kernel flags). But if we do this, then we should _truly_ get rid of all the root device etc setup crap (and the "search for init" etc stuff - it _is_ going to be there, and THAT process is the one that should then search for the real init once it has booted). That, together with reasonable interfaces to let ACPI set irq data for the kernel etc, might make moving ACPI back into user space possible in _practice_ and not just in theory. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus vs. AC kernels
Adam wrote: > yeah, read change logs.. Some samples. -pre9: - merge with Alan (including MIPS update) -pre6: - Alan Cox: merging, merging, merging - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus vs. AC kernels
On Wed, Jul 04, 2001 at 12:58:02PM -0400, John Weber wrote: > Is there any way to find out up to what ac# level has been merged with > the current kernel releases (including the pre kernels)? You can get a diff between two arbitrary patches against the same thing using interdiff from patchutils. For example: interdiff -h <(bzcat patch-2.4.6-pre5) <(bzcat patch-2.4.5-ac24.bz2) Tim. */ PGP signature
Re: 2.4.6: Machine Check Exception: 0x 106BE0 (type 0x 9).
> I stress that 2.4.4 still compiles and runs without a problem. Does this > make any sense for a hardware problem? Was there any new hardware (cpu) > check introduced in 2.4.5? I'd be very grateful for any tips, Yes. 2.4.5 reports MCE rather than praying the detected error or out of tolerance event did anything bad 2.4.6 has a "nomce" boot option too - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linus vs. AC kernels
Is there any way to find out up to what ac# level has been merged with the current kernel releases (including the pre kernels)? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
aty128fb code ac vs. linus
hi, i have a ati rage128 m3 and with the current (2.4.6) kernel X doesn't work together with the aty128fb framebuffer. (very strange effect, looks if only a very few amount of the memory is used and this is mapped!!) with the aty128fb code from 2.4.5-ac18 X works without any problems. at the moment i use the aty128fb code with 2.4.6 without problems. since alans looks newer and better, will it include in 2.4.7? greets philipp, and sorry for my bad engish ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.6: Machine Check Exception: 0x 106BE0 (type 0x 9).
Hello, I wrote to this list the other day about how I didn't get 2.4.5 to boot on my Compaq LTE 5200 laptop. This is a Pentium 120MHz, 72MB RAM with an OPTi Viper chipset. The strange thing is, all kernels up to 2.4.4 (inclusive) compile and run flawlessly on this machine. Only when I tried to upgrade to 2.4.5 did I get what looks like a hardware problem, and the machine does not boot. There is nothing wrong with the kernel configuration, and I tried gcc 2.95, 3.0, and, to be absolutely sure, 2.91.66 (the recommended compiler). I then had the same problem with a 2.4.6pre kernel, and, today, with the 2.4.6. The error message I'm getting now is: CPU#0: Machine Check Exception: 0x 106BE0 (type 0x 9). This line is repeated over and over again (with the spaces). There are some lines that fly by before that, though, and I went to some lengths trying to capture them the other day. (They scroll by too fast to be seen.) First I tried to set CONFIG_LP_CONSOLE and pass the appropriate line to lilo, but nothing came out of the printer. Then I tried lkcd (the kernel debugging patch/tool), but it seems that the machine hangs too early in the boot process for that tool to work. If the message above doesn't mean anything to anyone, I guess I'll have to rent a videocamera and tape my laptop trying to boot :) I stress that 2.4.4 still compiles and runs without a problem. Does this make any sense for a hardware problem? Was there any new hardware (cpu) check introduced in 2.4.5? I'd be very grateful for any tips, and could you please cc: them to me, as I don't subscribe to this list. Thanks! David Bragason, - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VM Requirement Document - v0.0
> Remember that the first message was about a laptop. At 4:00AM there's > no activity but the updatedb one (and the other cron jobs). Simply, > there's no 'accessed-often' data. Moreover, I'd bet that 90% of the > metadata touched by updatedb won't be accessed at all in the future. > Laptop users don't do find /usr/share/terminfo/ so often. Maybe, but I would think that most laptops get switched off at night. Then when turned on again in the morning, anacron realizes it missed the nightly cron jobs and then runs everything. This really does make an incredible difference to the system. If I remove the updatedb job from cron.daily, the machine won't touch swap all day and runs like charm. (That's with vmware, mozilla, openoffice, all applications that like big chunks of memory) Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.20pre7
Hi Alan. > Linux 2.2 is now firmly into maintainance state. Patches for > neat new ideas belong in 2.4. Generally new drivers belong in > 2.4 (possibly in 2.2 as well after 2.4 shows them stable). > Expect me to be very picky on changes to the core code now. Can I submit the attached patch for both 2.2 and 2.4 kernels? It adds a new script that lists all the configuration variables used, together with details of how many times each variable is used. Best wishes from Riley. scripts/varlist
Linux 2.2.20pre7
Linux 2.2 is now firmly into maintainance state. Patches for neat new ideas belong in 2.4. Generally new drivers belong in 2.4 (possibly in 2.2 as well after 2.4 shows them stable). Expect me to be very picky on changes to the core code now. 2.2.20pre7 o Merge rose buffr management fixes (Jean-Paul Roubelat) o Configure.help updates (Steven Cole) o Add Steven Cole to credits (Steven Cole) o Update kbuild list info (Michael Chastain) o Fix slab.c doc typo (Piotr Kasprzyk) o Lengthen parport probe timeout (Jean-Luc Coulon) o Fix vm86 cleanup(Stas Sergeev) o Fix 8139too build bug (Jürgen Zimmermann) o Fix slow 8139too performance(Oleg Makarenko) o Sparc64 exec fixes (Solar Designer) 2.2.20pre6 o Merge all the pending ISDN updates (Kai Germaschewski) | These are sizable changes and want a good testing o Fix sg deadlock bug as per 2.4 (Douglas Gilbert) o Count socket/pipe in quota inode use(Paul Menage) o Fix some missing configuration help texts (Steven Cole) o Fix Rik van Riel's credits entry(Rik van Riel) o Mark xtime as volatile in extern definition (various people) o Fix open error return checks(Andries Brouwer) 2.2.20pre5 o Fix a patch generation error, replaces 2.2.20pre4 which is wrong on ad1848 2.2.20pre4 o Fix small corruption bug in 82596 (Andries Brouwer) o Fix usb printer probing (Pete Zaitcev) o Fix swapon/procfs race (Paul Menage) o Handle ide dma bug in the CS5530(Mark Lord) o Backport 2.4 ipv6 neighbour discovery changes (Dave Miller) o FIx sock_wmalloc error handling (Dave Miller) o Enter quickack mode for out of window TCP data (Andi Kleen) o Fix Established v SYN-ACK TCP state error (Alexey Kuznetsov) o Sparc updates, ptrace changes etc (Dave Miller) o Fix wrong printk in vdolive masq(Keitaro Yosimura) o Fix core dump handling bugs in 2.2 (Al Viro) o Update hdlc and synclink drivers(Paul Fulghum) o Update netlink help texts (Magnus Damm) o Fix rtl8139 keeping files open (Andrew Morton) o Further sk98 driver updates. fix wrong license (Mirko Lindner) text in files o Jonathan Woithe has moved (Jonathan Woithe) o Update cpqarray driver (Charles White) o Update cciss driver (Charles White) o Don't delete directories on an fs that reports (Ingo Oeser) then 0 size when doing distclean o Add support for the 2.4 boot extensions to 2.2 (H Peter Anvin) o Fix nfs cache locking corruption on SMP (Craig Hagan) o Add missing check to cdrom readaudio ioctl (Jani Jaakkola) o Fix refclock build with newer gcc (Jari Ruusu) o koi8-r fixes(Andy Rysin) o Spelling fixes for documentation(Andries Brouwer) 2.2.20pre3 o FPU/ptrace corruption fixes (Victor Zandy) o Resync belkin usb serial with 2.4 (Greg Kroah-Hartmann) o Resync digiport usb serial with 2.4 (Greg Kroah-Hartmann) o Rsync empeg usb serial with 2.4 (Greg Kroah-Hartmann) o Resync ftdi_sio against 2.4 (Greg Kroah-Hartmann) o Bring keyscan usb back into line with 2.4 (Greg Kroah-Hartmann) o Resync keyspan_pda usb with 2.4 (Greg Kroah-Hartmann) o Resync omninet usb with 2.4.5 (Greg Kroah-Hartmann) o Resync usb-serial driver with 2.4.5 (Greg Kroah-Hartmann) o Resync visor usb driver with 2.4.5 (Greg Kroah-Hartmann) o Rsync whiteheat driver with 2.4.5 (Greg Kroah-Hartmann) o Add edgeport USB serial (Greg Kroah-Hartmann) o Add mct_u232 USB serial (Greg Kroah-Hartmann) o Update usb storage device list (Stas Bekman, Kaz Sasayma) o Bring usb acm driver into line with 2.4.5 (Greg Kroah-Hartmann) o Bring bluetooth driver into line with 2.4.5 (Greg Kroah-Hartmann) o Bring dabusb driver into line with 2.4.5(Greg Kroah-Hartmann) o Bring usb dc2xx driver into line with 2.4.5 (Greg Kroah-Hartmann) o Bring mdc800 usb driver into line with 2.4.5(Greg Kroah-Ha
Re: Problem with SMC Etherpower II + kernel newer 2.4.2
> Could you specify what you mean by "very high network traffic" in terms > of interrupt rate and Mb/s ? > Ftp on full CD content or gross ping -f doesn't kill it under 2.4 here. > autonegociation sucks sometimes. That's about what I did, except that I saved the data to a nfs mounted disk. > Different switch/cable/*motherboard* ? Probably not. I tried the drivers from http://www.scyld.com/network/ , and the problem disappeared (thanks to Jeff Garzik for the suggestion). I haven't tried 2.4.x again, but last time I did (2.4.6-pre6 or so), it didn't even finish importing my nfs shares on startup. In case you are interested, here is the output of the 2.2.18 drivers, when the card hangs: Jun 4 16:44:34 siechfried kernel: eth0: Transmit timeout using MII device, Tx status 0005. Jun 4 16:44:34 siechfried kernel: eth0: Restarting the EPIC chip, Rx 2026941/2026941 Tx 497569/497585. Jun 4 16:44:34 siechfried kernel: eth0: epic_restart() done, cmd status 000a, ctl 0512 interrupt 24. Jun 4 16:44:39 siechfried kernel: eth0: Transmit timeout using MII device, Tx status 0005. Jun 4 16:44:39 siechfried kernel: eth0: Restarting the EPIC chip, Rx 2026941/2026941 Tx 497569/497585. Jun 4 16:44:39 siechfried kernel: eth0: epic_restart() done, cmd status 000a, ctl 0512 interrupt 24. Jun 4 16:44:44 siechfried kernel: eth0: Transmit timeout using MII device, Tx status 0005. etc... The driver from scyld.com did also issue such a warning, but only once and everythings seems to be back to normal afterwards: Jul 4 15:13:06 siechfried kernel: eth0: Tx hung, 25721 vs. 25713. Jul 4 15:13:06 siechfried kernel: eth0: Transmit timeout using MII device, Tx status 0003. Jul 4 15:13:06 siechfried kernel: eth0: Restarting the EPIC chip, Rx 24507/24507 Tx 25713/25721. Jul 4 15:13:06 siechfried kernel: eth0: epic_restart() done, cmd status 000a, ctl 0512 interrupt 24. I hope this helps, Flo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VM Requirement Document - v0.0
On Wednesday 04 July 2001 11:41, Marco Colombo wrote: > On Tue, 3 Jul 2001, Daniel Phillips wrote: > > On Tuesday 03 July 2001 12:33, Marco Colombo wrote: > > > Oh, yes, since that PAGE_AGE_BG_INTERACTIVE_MINIMUM is applied only > > > when background aging, maybe it's not enough to keep processes like > > > updatedb from causing interactive pages to be evicted. > > > That's why I said we should have another way to detect that kind of > > > activity... well, the application could just let us know (no need to > > > embed an autotuning-genetic-page-replacement-optimizer into the > > > kernel). We should just drop all FS metadata accessed by updatedb, > > > since we know that's one-shot only, without raising pressure at all. > > > > Note that some of updatedb's metadata pages are of the accessed-often > > kind, e.g., directory blocks and inodes. A blanket low priority on all > > the pages updatedb touches just won't do. > > Remember that the first message was about a laptop. At 4:00AM there's > no activity but the updatedb one (and the other cron jobs). Simply, > there's no 'accessed-often' data. Moreover, I'd bet that 90% of the > metadata touched by updatedb won't be accessed at all in the future. > Laptop users don't do find /usr/share/terminfo/ so often. The problem is when you have a directory block, say, that has to stay around quite a few seconds before dropping into disuse. You sure don't want that block treated as 'accessed-once'. The goal here is to get through the updatedb as quickly as possible. Getting the user's "interactive" programs loaded back in afterwards is a separate, much more difficult problem IMHO, but no doubt still has a reasonable solution. I'm not that worried about it, my feeling is: if we fix up the MM so it doesn't bog down with a lot of pages in cache and, in addition, do better readahead, interactive performance will be just fine. > > > Just like > > > (not that I'm proposing it) putting those "one-shot" pages directly on > > > the inactive-clean list instead of the active list. How an application > > > could declare such a behaviour is an open question, of course. Maybe > > > it's even possible to detect it. And BTW that's really fine tuning. > > > Evicting an 8 hours old page may be a mistake sometime, but it's never > > > a *big* mistake. > > > > IMHO, updatedb *should* evict all the "interactive" pages that aren't > > actually doing anything[1]. That way it should run faster, provided of > > course its accessed-once pages are properly given low priority. > > So in the morning you find your Gnome session completely on swap, > and at the same time a lot of free mem. > > > I see three page priority levels: > > > > 0 - accessed-never/aged to zero > > 1 - accessed-once/just loaded > > 2 - accessed-often > > > > with these transitions: > > > > 0 -> 1, if a page is accessed > > 1 -> 2, if a page is accessed a second time > > 1 -> 0, if a page gets old > > 2 -> 0, if a page gets old > > > > The 0 and 1 level pages are on a fifo queue, the 2 level pages are > > scanned clock-wise, relying on the age computation[2]. Eviction > > candidates are taken from the cold end of the 0 level list, unless it is > > empty, in which case they are taken from the 1 level list. In > > desperation, eviction candidates are taken from the 2 level list, i.e., > > random eviction policy, as opposed to what we do now which is to initiate > > an emergency scan of the active list for new inactive candidates - rather > > like calling a quick board meeting when the building is on fire. > > Well, it's just aging faster when it's needed. Random evicting is not > good. It's better than getting bogged down in scanning latency just at the point you should be starting new writeouts. Obviously, it's a tradeoff. > List 2 is ordered by age, and there're always better candidates > at the end of the list than at the front. The higher the pressure, > the shorter is the time a page has to rest idle to get at the end of the > list. But the list *is* ordered. No, list 2 is randomly ordered. Pages move from the initial trial list to the active list with 0 temperature, and drop in just behind the one-hand scan pointer (which we actually implement as the head of the list). After that they get "aged" up or down as we do now. (New improved terminology: heated or cooled according to the referenced bit.) > > Note that the above is only a very slight departure from the current > > design. And by the way, this is just brainstorming, it hasn't reached the > > 'proposal' stage yet. > > > > [1] It would be nice to have a mechanism whereby the evicted > > 'interactive' pages are automatically reloaded when updatedb has finished > > its work. This is a case of scavenging unused disk bandwidth for > > something useful, i.e., improving the interactive experience. > > updatedb doesn't really need all the memory it takes. All it needs is > a small buffer to sequentially scan all the disk. So we s
Re: VM Requirement Document - v0.0
On Wednesday 04 July 2001 10:32, Marco Colombo wrote: > On Tue, 3 Jul 2001, Daniel Phillips wrote: > > On Monday 02 July 2001 20:42, Rik van Riel wrote: > > > On Thu, 28 Jun 2001, Marco Colombo wrote: > > > > I'm not sure that, in general, recent pages with only one access are > > > > still better eviction candidates compared to 8 hours old pages. Here > > > > we need either another way to detect one-shot activity (like the one > > > > performed by updatedb), > > > > > > Fully agreed, but there is one problem with this idea. > > > Suppose you have a maximum of 20% of your RAM for these > > > "one-shot" things, now how are you going to be able to > > > page in an application with a working set of, say, 25% > > > the size of RAM ? > > > > Easy. What's the definition of working set? Those pages that are > > frequently referenced. So as the application starts up some of its pages > > will get promoted from used-once to used-often. (On the other hand, the > > target behavior here conflicts with the goal of grouping together several > > temporally-related accesses to the same page together as one access, so > > there's a subtle distinction to be made here, see below.) > > [...] > > In Rik example, the ws is larger than available memory. Part of it > (the "hottest" one) will get double-accesses, but other pages will keep > condending the few available (physical) pages with no chance of being > accessed twice. But see my previous posting... But that's exactly what we want. Note that the idea of reserving a fixed amount of memory for "one-shot" pages wasn't mine. I see no reason to set a limit. There's only one critereon: does a page get referenced between the time it's created and when its probation period expires? Once a page makes it into the active (level 2) set it's on an equal footing with lots of others and it's up to our intrepid one-hand clock to warm it up or cool it down as appropriate. On the other hand, if the page gets sent to death row it still has a few chances to prove its worth before being cleaned up and sent to the aba^H^H^H^H^H^H^H^H reclaimed. (Apologies for the multiplying metaphors ;-) -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Ideas for TUX2
On Wednesday 04 July 2001 09:53, Ph. Marek wrote: > >> Well, my point was, that with several thousand inodes spread over the > >> disk it won't always be possible to update the inode AND the fbb in one > >> go. So I proposed the 2nd inode with generation counter! > > > >The cool thing is, it *is* possible, read how here: > > > > http://nl.linux.org/~phillips/tux2/phase.tree.tutorial.html > > Well, ok. Your split the inode "files" too. > > Hmmm... > That sound more complex than my version (at least now, until I've seen the > implementation - maybe it's easier because it has less special cases than > mine). Yes, it's more complex, but not horribly so. It's a lot more efficient, and that's the point. > And of course the memory usage on the harddisk is much less with your > version as you split your inode data and don't have it duplicated. Yep. > Well, I hope to see an implementation soon - I'd like to help, even if it's > only testing. See you on the list. By the way, if you want to help out right now, could you run some benchmarks my latest early flush patch? See "[RFC] Early Flush with Bandwidth Estimation". -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: What are rules for acpi_ex_enter_interpreter?
On Wed, Jul 04, 2001 at 03:38:07AM +0200, Petr Vandrovec wrote:
>
> I did NOT verified other callers of acpi_walk_namespace... And there
> is still some problem left, as although now S5 is listed as available,
> poweroff still does nothing instead of poweroff.
Replying to myself, after following change in additon to acpi_ex_...
poweroff on my machine works. It should probably map type 0 => 0, 3 => 1
and 7 => 2, but it is hard to decide without VIA datasheet, so change
below is minimal change needed to get poweroff through ACPI to work on my
ASUS A7V.
Best regards,
Petr Vandrovec
[EMAIL PROTECTED]
diff -urdN linux/drivers/acpi/hardware/hwsleep.c linux/drivers/acpi/hardware/hwsleep.c
--- linux/drivers/acpi/hardware/hwsleep.c Tue Jul 3 15:58:35 2001
+++ linux/drivers/acpi/hardware/hwsleep.c Wed Jul 4 16:07:47 2001
@@ -146,6 +146,13 @@
return status;
}
+ /* Broken ACPI table on ASUS A7V... it reports type 7, but poweroff is type
+2...
+ sleep is type 1 while ACPI reports type 3, but as I was not able to get
+ machine to wake from this state without unplugging power cord... */
+ if (type_a == 7 && type_b == 7 && sleep_state == ACPI_STATE_S5 &&
+!memcmp(acpi_gbl_DSDT->oem_id, "ASUS\0\0", 6)
+ && !memcmp(acpi_gbl_DSDT->oem_table_id, "A7V ", 8)) {
+ type_a = type_b = 2;
+ }
/* run the _PTS and _GTS methods */
MEMSET(&arg_list, 0, sizeof(arg_list));
> diff -urdN linux/drivers/acpi/namespace/nsinit.c
>linux/drivers/acpi/namespace/nsinit.c
> --- linux/drivers/acpi/namespace/nsinit.c Tue Jul 3 15:58:35 2001
> +++ linux/drivers/acpi/namespace/nsinit.c Wed Jul 4 02:20:49 2001
> @@ -27,6 +27,7 @@
> #include "acpi.h"
> #include "acnamesp.h"
> #include "acdispat.h"
> +#include "acinterp.h"
>
> #define _COMPONENT ACPI_NAMESPACE
>MODULE_NAME ("nsinit")
> @@ -62,10 +63,17 @@
>
> /* Walk entire namespace from the supplied root */
>
> + status = acpi_ex_enter_interpreter();
> + if (ACPI_FAILURE(status)) {
> + return status;
> + }
> +
> status = acpi_walk_namespace (ACPI_TYPE_ANY, ACPI_ROOT_OBJECT,
> ACPI_UINT32_MAX, acpi_ns_init_one_object,
> &info, NULL);
>
> + acpi_ex_exit_interpreter();
> +
> return (AE_OK);
> }
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: New FarSync T-Series driver
The Tue, Jul 03, 2001 at 06:28:03PM +0100, Robert J.Dunlop wrote : [...] > Sorry for the big post, but I posted URLs for an earlier version of this > a couple of months back and got very little feedback. I know sync card > drivers ain't sexy. Just my HO: * error_1, error_2... error_n labels are ugly; * ioremap may fail; * mix of spin_lock and FST_LOCK isn't nice (kill the latter ?); * +offset = BUF_OFFSET ( rxBuffer[pi][i]); [...] +card->mem + BUF_OFFSET ( rxBuffer[pi][rxp][0]), A bit of a macro abuse imho. * +if ( ++port->txpos >= NUM_TX_BUFFER ) +port->txpos = 0; Why not: port->txpos++; foo = port->txpos%NUM_TX_BUFFER; -- Ueimor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Intel SRCU3-1 RAID (I2O) and 2.4.5-ac18
> Function: Media Unlock > Error Code: Access Violation > User Info: > Disk Serial No is not set, just no data in the table field > Timestamps are somewhat strange - three erroror logs one after > another then about 3-4 minutes delay and again three messages What that means in the intel log I dont know. Media unlock is a command we issue when you unmount an array. It allows volume removal if the volume can be removed or errors otherwise (an error we happily ignore in that case) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Intel SRCU3-1 RAID (I2O) and 2.4.5-ac18
> modprobe i2o_config > may be needed Yes of course, why didn't I think about it... Anyway, the cgi tool doesn't seem to identify any problems with the controller before the freeze. Then it freezes together with the copying process. And after reboot I see errors in the controller's log - they are all exactly same: Function: Media Unlock Error Code: Access Violation User Info: Disk Serial No is not set, just no data in the table field Timestamps are somewhat strange - three erroror logs one after another then about 3-4 minutes delay and again three messages The RAID volume sometimes enters a state after reboot where all three disks are working and the cgi says the volume is initializing. Przemek Tomala - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Re: dev_get_by_name without dev_put
Em Wed, Jul 04, 2001 at 03:49:46PM +0200, [EMAIL PROTECTED] escreveu: > Every time dev_get_by_name is called, and it has returned a valid struct >net_device*, dev_put should be called afterwards, because otherwise the machine hangs >when the device is unregistered (since dev->refcnt > 1). However, it seems that some >drivers do > not call dev_put after dev_get_by_name: for example, drivers/net/pppoe.c at line 573 >and net/core/dv.c at line 168. Am I wrong? For pppoe (and one has to look at the set_item and see if delete_item is needed). - Arnaldo --- linux-2.4.5-ac24/drivers/net/pppoe.cTue Jul 3 18:45:41 2001 +++ linux-2.4.5-ac24.acme/drivers/net/pppoe.c Wed Jul 4 11:00:47 2001 @@ -567,17 +567,17 @@ if (!dev) goto end; + po->pppoe_dev = dev; + if( ! (dev->flags & IFF_UP) ) - goto end; + goto err_put; memcpy(&po->pppoe_pa, &sp->sa_addr.pppoe, sizeof(struct pppoe_addr)); error = set_item(po); if (error < 0) - goto end; - - po->pppoe_dev = dev; + goto err_put; po->chan.hdrlen = (sizeof(struct pppoe_hdr) + dev->hard_header_len); @@ -586,6 +586,8 @@ po->chan.ops = &pppoe_chan_ops; error = ppp_register_channel(&po->chan); + if (error) + goto err_put; sk->state = PPPOX_CONNECTED; } @@ -595,6 +597,10 @@ end: release_sock(sk); return error; +err_put: + dev_put(po->pppoe_dev); + po->pppoe_dev = NULL; + goto end; } - Arnaldo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
dev_get_by_name without dev_put
Every time dev_get_by_name is called, and it has returned a valid struct net_device*, dev_put should be called afterwards, because otherwise the machine hangs when the device is unregistered (since dev->refcnt > 1). However, it seems that some drivers do not call dev_put after dev_get_by_name: for example, drivers/net/pppoe.c at line 573 and net/core/dv.c at line 168. Am I wrong? - Fabrizio Gennari tel. +39 039 203 7816 Philips Research Monzafax. +39 039 203 7800 via G. Casati 23 [EMAIL PROTECTED] 20052 Monza (MI) Italyhttp://www.research.philips.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
problems with netfilter 2.4.6 with mark unclean.
HI, upgrading to new linux kernel 2.4.6, with FULL netfilter enabled and compiled statically inside of the kernel, a rule like iptables -A INPUT -m unclean -j DROP will put netfilter in condition to DROP every tcp packet it receives. That is not true with UDP or icmp, (NFS and all icmp work) but the kernel will DROP ALL tcp apckets. That was not happening with 2.4.5 kernel and older, so that i was able to use this rule against malformed packets. I tried bot compiling kernel with egcs, gcc 2.95.3 and gcc 3.0. System is PentiumIII 550 Mhz 128 Mbyte Ram 1 IDE disk 33Mhz intel MB vx 440 binutils 2.11.90.0.19 glibc 2.2.3 Bests Luigi Genoni - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with SMC Etherpower II + kernel newer 2.4.2
Juergen Wolf <[EMAIL PROTECTED]> ecrit : [...] Jul 2 13:06:59 localhost kernel: eth0: Too much work at interrupt, IntrStatus=0x008d0004. Receive Status Valid Receive Copy In Progress Transmit Idle Receive Queue Empty -> no more receive buffer available It looks like one waits too long before processing incoming data but I'm curious to know where they come from if nothing is plugged. [...] > Bus 1, device 0, function 0: > VGA compatible controller: nVidia Corporation NV11 (rev 161). > IRQ 10. > Master Capable. Latency=32. Min Gnt=5.Max Lat=1. > Non-prefetchable 32 bit memory at 0xdc00 [0xdcff]. > Prefetchable 32 bit memory at 0xd000 [0xd7ff]. Is X or something like a nvidia module enabled ? -- Ueimor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.5-ac24
On Tue, 3 Jul 2001, Alan Cox wrote:
> 2.4.5-ac24
> o Merge 2.4.6-pre9
> - Ignored ATI changes versus old atyfb codebase
drivers/video/aty/ in your tree is still for the ATI Mach64 family only. So you
should keep on merging aty128fb (for ATI Rage 128). The integration of the
support for Rage 128 and Radeon in the new atyfb has not been completed yet.
Here is a patch to bring the atyfb in your tree in sync with the atyfb in
Linus' tree. This does not include the changes to aty128fb, they can be copied
from Linus' tree directly.
--- linux-2.4.5-ac24/drivers/video/aty/atyfb_base.c Fri Jun 29 11:01:44 2001
+++ linux-atyfb-2.4.5-ac24/drivers/video/aty/atyfb_base.c Wed Jul 4 14:43:21
+2001
@@ -1430,7 +1430,7 @@
static void atyfb_save_palette(struct fb_info *fb, int enter)
{
struct fb_info_aty *info = (struct fb_info_aty *)fb;
- int i, tmp, scale;
+ int i, tmp;
for (i = 0; i < 256; i++) {
tmp = aty_ld_8(DAC_CNTL, info) & 0xfc;
@@ -1439,14 +1439,11 @@
aty_st_8(DAC_CNTL, tmp, info);
aty_st_8(DAC_MASK, 0xff, info);
- scale = (M64_HAS(INTEGRATED) &&
-info->current_par.crtc.bpp == 16) ? 3 : 0;
- writeb(i << scale, &info->aty_cmap_regs->rindex);
-
+ writeb(i, &info->aty_cmap_regs->rindex);
atyfb_save.r[enter][i] = readb(&info->aty_cmap_regs->lut);
atyfb_save.g[enter][i] = readb(&info->aty_cmap_regs->lut);
atyfb_save.b[enter][i] = readb(&info->aty_cmap_regs->lut);
- writeb(i << scale, &info->aty_cmap_regs->windex);
+ writeb(i, &info->aty_cmap_regs->windex);
writeb(atyfb_save.r[1-enter][i], &info->aty_cmap_regs->lut);
writeb(atyfb_save.g[1-enter][i], &info->aty_cmap_regs->lut);
writeb(atyfb_save.b[1-enter][i], &info->aty_cmap_regs->lut);
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: parport_pc tries to load parport_serial automatically
On Wed, Jul 04, 2001 at 01:38:13PM +0100, Alan Cox wrote: > Can hotplug handle this from a PCI id table ? There is a PCI id table in parport_serial, yes (if that's what you're asking). Tim. */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: parport_pc tries to load parport_serial automatically
> -#ifdef CONFIG_PARPORT_SERIAL_MODULE
> - if (!ret)
> - request_module ("parport_serial");
> -#endif
> -
> return ret;
> }
>
> --- linux/drivers/parport/ChangeLog.orig Wed Jul 4 13:30:32 2001
> +++ linux/drivers/parport/ChangeLog Wed Jul 4 13:32:01 2001
> @@ -0,0 +1,6 @@
> +2001-07-04 Tim Waugh <[EMAIL PROTECTED]>
> +
> + * parport_pc.c (init_module): Don't try to load parport_serial.
> + This means that the user needs to load it (or a hardware detection
> + program on their behalf) if necessary.
> +
Can hotplug handle this from a PCI id table ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: parport_pc tries to load parport_serial automatically
On Wed, Jun 27, 2001 at 07:32:42AM -0300, Marcelo Tosatti wrote:
> Could you remove the request_module() from parport_pc ?
Yes.
Here is a patch against 2.4.5-ac24.
Tim.
*/
2001-07-04 Tim Waugh <[EMAIL PROTECTED]>
* drivers/parport/parport_pc.c: Don't load parport_serial.
* drivers/parport/ChangeLog: Updated.
--- linux/drivers/parport/parport_pc.c.orig Wed Jul 4 13:30:01 2001
+++ linux/drivers/parport/parport_pc.c Wed Jul 4 13:30:26 2001
@@ -2931,11 +2931,6 @@
if (ret && registered_parport)
pci_unregister_driver (&parport_pc_pci_driver);
-#ifdef CONFIG_PARPORT_SERIAL_MODULE
- if (!ret)
- request_module ("parport_serial");
-#endif
-
return ret;
}
--- linux/drivers/parport/ChangeLog.origWed Jul 4 13:30:32 2001
+++ linux/drivers/parport/ChangeLog Wed Jul 4 13:32:01 2001
@@ -0,0 +1,6 @@
+2001-07-04 Tim Waugh <[EMAIL PROTECTED]>
+
+ * parport_pc.c (init_module): Don't try to load parport_serial.
+ This means that the user needs to load it (or a hardware detection
+ program on their behalf) if necessary.
+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fix typo in 2.4.6 for PPC
The patch below fixes a typo in the PowerPC code in 2.4.6. Without
this change, people attempting to compile up a kernel for a powermac
will get a compile error.
Paul.
diff -urN linux/arch/ppc/kernel/pmac_pci.c linuxppc_2_4/arch/ppc/kernel/pmac_pci.c
--- linux/arch/ppc/kernel/pmac_pci.cTue Jul 3 13:38:19 2001
+++ linuxppc_2_4/arch/ppc/kernel/pmac_pci.c Tue Jul 3 15:00:40 2001
@@ -249,7 +249,7 @@
out_le32(bp->cfg_addr, (1UL << BANDIT_DEVNUM) + PCI_VENDOR_ID);
udelay(2);
vendev = in_le32((volatile unsigned int *)bp->cfg_data);
- if (vendev == (PCI_VENDOR_ID_APPLE_BANDIT << 16) +
+ if (vendev == (PCI_DEVICE_ID_APPLE_BANDIT << 16) +
PCI_VENDOR_ID_APPLE) {
/* read the revision id */
out_le32(bp->cfg_addr,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: RPC: rpciod waiting on sync task!
> " " == Dima Brodsky <[EMAIL PROTECTED]> writes: > Hi, I modified the linux NFS client, kernel 2.4.5 and > 2.4.6-pre7, to send an extra SETATTR, with special values, > within nfs_open and nfs_release so that I would be able to > track file open and close. For the server I am using a > slightly modified linux user level nfs server. > What I noticed is that after this change I get: > RPC: rpciod waiting on sync task! That probably means that you've put this setattr code somewhere in the rpciod read,write or delete callbacks. You should never mix asynchronous and synchronous calls as this can cause the rpciod task to deadlock by waiting on itself... Cheers, Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: about kmap_high function
Stephen C. Tweedie writes: > On Tue, Jul 03, 2001 at 10:47:20PM +1000, Paul Mackerras wrote: > > On PPC it is a bit different. Flushing a single TLB entry is > > relatively cheap - the hardware broadcasts the TLB invalidation on the > > bus (in most implementations) so there are no cross-calls required. But > > flushing the whole TLB is expensive because we (strictly speaking) > > have to flush the whole of the MMU hash table as well. > > How much difference is there? Between flushing a single TLB entry and flushing the whole TLB, or between flushing a single entry and flushing a range? Flushing the whole TLB (including the MMU hash table) would be extremely expensive. Consider a machine with 1GB of RAM. The recommended MMU hash table size would be 16MB (1024MB/64), although we generally run with much less, maybe a quarter of that. That's still 4MB of memory we have to scan through in order to find and clear all the entries in the hash table, which is what would be required for flushing the whole hash table. What we do at present is (a) have a bit in the linux page tables which indicates whether there is a corresponding entry in the MMU hash table and (b) only flush the kernel portion of the address space (0xc000 - 0x) in flush_tlb_all(). We have a single page table tree for kernel addresses, shared between all processes. That all helps but we still have to scan through all the page table pages for kernel addresses to do a flush_tlb_all(). I just did some measurements on a 400MHz POWER3 machine with 1GB of RAM. This is a 64-bit machine but running a 32-bit kernel (so both the kernel and userspace run in 32-bit mode). It is a 1-cpu machine and I am running an SMP kernel with highmem enabled, with 512MB of lowmem and 512MB of highmem. The MMU hash table is 4MB. The time taken inside a single flush_tlb_page call depends on whether the linux PTE indicates that there is a hardware PTE in the hash table. If not, it takes about 110ns, if it does, it takes 1us (I measured 998.5ns but I rounded it :). A call to flush_tlb_range for 1024 pages from flush_all_zero_pkmaps (replacing the flush_tlb_all call) takes around 1080us, which is pretty much linear. The time for flush_tlb_page was measured inside the procedure whereas the time for flush_tlb_range was measured in the caller, so the flush_tlb_range number includes procedure call and loop overhead which the flush_tlb_page number doesn't. I expect that almost all the PTEs in the pkmap range would have a corresponding hash table entry, since we would almost always touch a page that we have kmap'd. > We only flush once per kmap sweep, and > we have 1024 entries in the global kmap pool, so the single tlb flush > would have to be more than a thousand times less expensive overall > than the global flush for that change to be worthwhile. The time for doing a flush_tlb_all call in flush_all_zero_pkmaps was 3280us. That is for the version which only flushes the kernel portion of the address space. Just doing a memset to 0 on the hash table takes over 11ms (the memset goes at around 360MB/s but there is 4MB to clear). Clearing out the hash table properly would take much longer since you are supposed to synchronize with the hardware when changing each entry in the hash table and the memset is certainly not doing that. So yes, the ratio is more than 1024 to 1. > If the page flush really is _that_ much faster, then sure, this > decision can easily be made per-architecture: the kmap_high code > already has all of the locking and refcounting to know when a per-page > tlb flush would be safe. My preference would be for architectures to be able to make this decision. I don't mind whether it is a flush call per page inside the loop in flush_all_zero_pkmaps or a flush_tlb_range call at the end of the loop. I counted the average number of pages needing to be flushed in the loop in flush_all_zero_pkmaps - it was 1023.9 for the workload I was using, which was a kernel compile. Using flush_tlb_range would be fine on PPC but as I noted before some architectures assume that flush_tlb_range is only used on user addresses at the moment. Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.6-final changelog entry
i summarized it for irc, so if it saves effort... jg's 2.4.6-final changelog: - minor config.in fixes - mtd nand/spia update - TI cardbus fix - u810 audio put_user fix - ialloc.c fix, mode, plus DQUOT_INIT - ELOOP in namei.c - if (!mm) return in proc/base.c - replace mm/mmap.c change: free += swapper_space.nrpages; -- Jeff Garzik | "I respect faith, but doubt is Building 1024| what gives you an education." MandrakeSoft | -- Wilson Mizner - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Acpi] Re: ACPI fundamental locking problems
> I argued this at the very beginning, but there was a very strong > view that you needed to run most of the code before you had a user > space to run it in. I've not followed things closely enough to That bit is clearly untrue. > My feeling has been that ACPI has violated the minimum privilege > concept from the beginning, although I think putting stuff in drivers > that could be at user level is not htat uncommon in Linux. It still seems to lack even basic checks that the writes AML does are into E820 NV or device space only - also while fixing it the ACPI guys might note that a write close to 0x will lead to a failed ioremap and a nasty mess because they ioremap a fixed sized window that will wrap - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [Acpi] Re: ACPI fundamental locking problems
> From: Alan Cox [SMTP:[EMAIL PROTECTED]] > > The goal isnt a technical nit, its to avoid loading 300Kbytes of crud > (which > should mostly be in user space anyway) on the 99.9% of machines where we > dont > need it. [DJW:] I argued this at the very beginning, but there was a very strong view that you needed to run most of the code before you had a user space to run it in. I've not followed things closely enough to know whether or not this is really true and whether or not it is inevitable, or just a flaw in the ACPI design. My feeling has been that ACPI has violated the minimum privilege concept from the beginning, although I think putting stuff in drivers that could be at user level is not htat uncommon in Linux. -- --- DISCLAIMER - Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of BTS. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
8139too driver update
Those who experienced problems with the 8139too driver are encouraged to try the driver found in 2.4.6 release kernel. Thanks, Jeff -- Jeff Garzik | "I respect faith, but doubt is Building 1024| what gives you an education." MandrakeSoft | -- Wilson Mizner - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why Plan 9 C compilers don't have asm("")
>> >Cort Dugan >> There isn't such a crippling difference between straight-line and code >>with> >> unconditional branches in it with modern processors. In fact, there's> >>very >> little measurable difference. >> >> If you're looking for something to blame hurd performance on I'd >>suggest >> the entire design of Mach, not inline asm vs procedure calls. Tossing >>a >> few context switches into calls is a lot more expensive. > hpa >That's not where the bulk of the penalty of a function call comes in >(and it's a call/return, not an unconditional branch.) The penalty >comes in because of the additional need to obey the calling >convention, and from the icache discontinuity. > call/return is two unconditional branches and a push and a pop (is that right?), which is I think what CD means, i.e. in terms of branch prediction. The push/pop is a hit on old CPUs, donno about >386. You're right though. The big hit is you can't lose the pushes to set up the args for a separately assembled function, or the frame drop that follows it. >Not to mention that certain things simply cannot be done that way. > Don't tell me that. Then I can't use my subroutine-threaded Forth variant, in which + is a subroutine call. ;o) Anyway, yes it's a performance hit to not inline asms. Is it worth the bletchery? It's worth asking that once in a while. I've looked at set_bit both ways. Now I'm curious how it does as straight C. Rick Hohensee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VM Requirement Document - v0.0
On Tue, 3 Jul 2001, Daniel Phillips wrote: > On Tuesday 03 July 2001 12:33, Marco Colombo wrote: > > Oh, yes, since that PAGE_AGE_BG_INTERACTIVE_MINIMUM is applied only > > when background aging, maybe it's not enough to keep processes like > > updatedb from causing interactive pages to be evicted. > > That's why I said we should have another way to detect that kind of > > activity... well, the application could just let us know (no need to > > embed an autotuning-genetic-page-replacement-optimizer into the kernel). > > We should just drop all FS metadata accessed by updatedb, since we > > know that's one-shot only, without raising pressure at all. > > Note that some of updatedb's metadata pages are of the accessed-often kind, > e.g., directory blocks and inodes. A blanket low priority on all the pages > updatedb touches just won't do. Remember that the first message was about a laptop. At 4:00AM there's no activity but the updatedb one (and the other cron jobs). Simply, there's no 'accessed-often' data. Moreover, I'd bet that 90% of the metadata touched by updatedb won't be accessed at all in the future. Laptop users don't do find /usr/share/terminfo/ so often. > > Just like > > (not that I'm proposing it) putting those "one-shot" pages directly on > > the inactive-clean list instead of the active list. How an application > > could declare such a behaviour is an open question, of course. Maybe it's > > even possible to detect it. And BTW that's really fine tuning. > > Evicting an 8 hours old page may be a mistake sometime, but it's never > > a *big* mistake. > > IMHO, updatedb *should* evict all the "interactive" pages that aren't > actually doing anything[1]. That way it should run faster, provided of > course its accessed-once pages are properly given low priority. So in the morning you find your Gnome session completely on swap, and at the same time a lot of free mem. > I see three page priority levels: > > 0 - accessed-never/aged to zero > 1 - accessed-once/just loaded > 2 - accessed-often > > with these transitions: > > 0 -> 1, if a page is accessed > 1 -> 2, if a page is accessed a second time > 1 -> 0, if a page gets old > 2 -> 0, if a page gets old > > The 0 and 1 level pages are on a fifo queue, the 2 level pages are scanned > clock-wise, relying on the age computation[2]. Eviction candidates are taken > from the cold end of the 0 level list, unless it is empty, in which case they > are taken from the 1 level list. In desperation, eviction candidates are > taken from the 2 level list, i.e., random eviction policy, as opposed to what > we do now which is to initiate an emergency scan of the active list for new > inactive candidates - rather like calling a quick board meeting when the > building is on fire. Well, it's just aging faster when it's needed. Random evicting is not good. List 2 is ordered by age, and there're always better candidates at the end of the list than at the front. The higher the pressure, the shorter is the time a page has to rest idle to get at the end of the list. But the list *is* ordered. > Note that the above is only a very slight departure from the current design. > And by the way, this is just brainstorming, it hasn't reached the 'proposal' > stage yet. > > [1] It would be nice to have a mechanism whereby the evicted 'interactive' > pages are automatically reloaded when updatedb has finished its work. This > is a case of scavenging unused disk bandwidth for something useful, i.e., > improving the interactive experience. updatedb doesn't really need all the memory it takes. All it needs is a small buffer to sequentially scan all the disk. So we should just drop all the pages it references, since we already know they won't be referenced again by noone else. > [2] I much prefer the hot/cold terminology over old/young. The latter gets > confusing because a 'high' age is 'young'. I'd rather think of a high value > as being 'hot'. True. s/page->age/page->temp/g B-) .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
