* Re: [PATCH] O_DIRECT with hardware blocksize alignment
From: Jens Axboe @ 2002-01-15 13:08 UTC (permalink / raw)
To: Andrea Arcangeli; +Cc: Joel Becker, Marcelo Tosatti, lkml
In-Reply-To: <20020115132026.F22791@athlon.random>
On Tue, Jan 15 2002, Andrea Arcangeli wrote:
> actually we could also forbid merging at the ll_rw_block layer if b_size
> is not equal, maybe that's the simpler solution to that problem after
> all, merging between kiovec I/O and buffered I/O probably doesn't
> matter.
Agreed, this is also what I suggested.
--- /opt/kernel/linux-2.4.18-pre3/drivers/block/ll_rw_blk.c Tue Jan 15 14:06:13 2002
+++ drivers/block/ll_rw_blk.c Tue Jan 15 14:07:23 2002
@@ -694,10 +694,11 @@
switch (el_ret) {
case ELEVATOR_BACK_MERGE:
- if (!q->back_merge_fn(q, req, bh, max_segments)) {
- insert_here = &req->queue;
+ insert_here = &req->queue;
+ if (!q->back_merge_fn(q, req, bh, max_segments))
+ break;
+ if (req->current_nr_sectors != (bh->b_size >> 9))
break;
- }
elevator->elevator_merge_cleanup_fn(q, req, count);
req->bhtail->b_reqnext = bh;
req->bhtail = bh;
@@ -708,10 +709,11 @@
goto out;
case ELEVATOR_FRONT_MERGE:
- if (!q->front_merge_fn(q, req, bh, max_segments)) {
- insert_here = req->queue.prev;
+ insert_here = req->queue.prev;
+ if (!q->front_merge_fn(q, req, bh, max_segments))
+ break;
+ if (req->current_nr_sectors != (bh->b_size >> 9))
break;
- }
elevator->elevator_merge_cleanup_fn(q, req, count);
bh->b_reqnext = req->bh;
req->bh = bh;
--
Jens Axboe
^ permalink raw reply
* Re: [BUG] symlink problem with knfsd and reiserfs
From: Nikita Danilov @ 2002-01-15 14:07 UTC (permalink / raw)
To: trond.myklebust
Cc: Neil Brown, Hans-Peter Jansen, linux-kernel, Reiserfs mail-list
In-Reply-To: <15428.6953.453942.415989@charged.uio.no>
Trond Myklebust writes:
> >>>>> " " == Hans-Peter Jansen <hpj@urpla.net> writes:
>
> > In syslog, this message appears: Jan 15 00:21:03 elfe kernel:
> > nfs_refresh_inode: inode 50066 mode changed, 0100664 to 0120777
>
> The error is basically telling you that ReiserFS filehandles are being
> reused by the server. Doesn't Reiser provide a generation count to
> guard against this sort of thing?
Yes, inode->i_generation is stored in the file handle:
fs/reiserfs/inode.c:reiserfs_dentry_to_fh().
Hans-Peter, what version of NFS are you using and have you remounted
clients after upgrading to the newer kernel?
>
> My 'fix' just solves the immediate problem of the wrong file mode. It
> does not solve the problems of data corruption that can occur when the
> client is incapable of distinguishing the 'old' and 'new' files that
> share the same filehandle.
This requires i_generation overflow (modulo bug in reiserfs).
>
> Cheers,
> Trond
Nikita.
^ permalink raw reply
* Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)
From: Giacomo Catenazzi @ 2002-01-15 13:00 UTC (permalink / raw)
To: T. A.; +Cc: Linux Kernel Mailing List, esr
In-Reply-To: <fa.hqe5uev.c60cjs@ifi.uio.no>
T. A. wrote:
> 1. Don't see any reason for the kernel hardware autoconfigurator to be
> included in the kernel.
Linus and Alan last year (end Dec 2000), told that it would nice to have
some kind of autoconfiguration.
The problem was the bug report about non running kernel, because of
false configuration (CPU configuration).
How many people try new kernel with the wrong CPU configuration?
(and mornally user know the name of own CPU, with netcards this is
more difficult).
[ We don't reduce trafic on lkml, because the fewer bug reports
are hidden by this huge flamewar]
>
> 2. Don't see any reason the kernel hardware autoconfigurator cannot be
> run as root. Actually see one very good reason why it shouldn't be able to
> be run as a regular user. Probing certain hardware is inherently dangerous.
> Machine can hang. Hardware could be probed to death. Heck a clever coder
> could even make use of the user level access required to allow user hardware
> autoconfiguration. Wiping disks, destroying flash roms, finding system
> backdoors, etc, etc.
Root will help, but AFAIK, not needed. Forget DMI.
Out detection is 'hang' free. (so a soft detection, but with some
tests, I can say that with this soft detection we can detect nearly
all, without the difficult to write hard probes).
>
> 3. ISA is pretty much dead outside of certain standard PC equipment.
> And of the remaining ISA out there, most in any machine than can still run a
> Linux kernel effectively is most likely PNP ISA. Plus there are a few
> fairly common ISA cards that can also be found easily. It seams that the
> vast majority of Aunt Tillies will be served with just PCI autoconfiguration
> and maybe PNP ISA configuration.
PCI, USB and ISAPNP detection works well.
ISA is a further step.
I will send Eric the new detections and database for new probes (for ISA
and others) drivers. So I hope also the ISA thread will end.
giacomo
^ permalink raw reply
* Re: Unable to compile 2.4.14 on alpha
From: J.A. Magallon @ 2002-01-15 10:32 UTC (permalink / raw)
To: Wakko Warner; +Cc: linux-kernel
In-Reply-To: <20020114212550.A17323@animx.eu.org>
On 20020115 Wakko Warner wrote:
>arch/alpha/kernel/kernel.o(.exitcall.exit+0x0): undefined reference to `local symbols in discarded section .text.exit'
Too bew binutils. .17 works again.
--
J.A. Magallon # Let the source be with you...
mailto:jamagallon@able.es
Mandrake Linux release 8.2 (Cooker) for i586
Linux werewolf 2.4.18-pre3-beo #5 SMP Sun Jan 13 02:14:04 CET 2002 i686
^ permalink raw reply
* Re: strange hang on boot
From: Pavel Machek @ 2002-01-15 12:56 UTC (permalink / raw)
To: Grover, Andrew; +Cc: acpi-devel-pyega4qmqnRoyOMFzWx49A
In-Reply-To: <EDC461A30AC4D511ADE10002A5072CAD0236DF57-OU+JdkIUtvd9zuciVAfUoVDQ4js95KgL@public.gmane.org>
Hi!
> What are some common things that could cause this? I was thinking this could
> be EC-related, but it still happens with no EC support...I thought it might
> be some disk-related IRQ weirdness. Does the IDE driver take interrupts when
> it probes, or only when it transfers data? If only the latter, then maybe a
> lack of IDE interrupts could be the cause?
I do not think so. IDE recovers well from
lost interrupts...
PavelEnd_of_mail_magic_2033
# New mail (delim 2185)
/usr/sbin/sendmail -oem -oi -N failure,delay -R full -- jan-JAsPCFd0eodBDgjK7y7TUQ@public.gmane.org andrew.grover@intel.com acpi-devel@sourceforge.net << End_of_mail_magic_2185
Date: Tue, 15 Jan 2002 08:23:36 -0500
From: Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>
To: Jan Rychter <jan-JAsPCFd0eodBDgjK7y7TUQ@public.gmane.org>
Cc: "Grover, Andrew" <andrew.grover-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>, acpi-devel@sourceforge.net
Subject: Re: [ACPI] Re: ACPI small patch update (20021024)
Message-ID: <20020115132324.GB2015@zaurus>
References: <EDC461A30AC4D511ADE10002A5072CAD04C7A467-OU+JdkIUtvd9zuciVAfUoVDQ4js95KgL@public.gmane.org> <m2wuo7tc0g.fsf@tnuctip.rychter.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <m2wuo7tc0g.fsf-dTJq59+VGzkkCw8IV3R6h0EOCMrvLtNR@public.gmane.org>
User-Agent: Mutt/1.3.27i
Hi!
> Andrew> As soon as Linus gets back, I'll be submitting all the
> Andrew> outstanding changes to him, and all the patchsets are on
> Andrew> linux-acpi.bkbits.net if anyone just wants to browse the most
> Andrew> recent changes.
>
> Not that I'm running this project, but I'd humbly suggest holding off
> those submissions until at least the recent regressions are fixed.
>
> 20021022 has blown off /proc/acpi/thermal and /proc/acpi/processor for
> me (and at least for one other person).
As these patches probably fix things for >1
person, too, I think holding them back is bad
idea. Remember, Linus likes small patches.End_of_mail_magic_2185
# New mail (delim 2338)
/usr/sbin/sendmail -oem -oi -N failure,delay -R full -- ak-l3A5Bk7waGM@public.gmane.org andrew@pimlott.net linux-kernel@vger.kernel.org << End_of_mail_magic_2338
Date: Tue, 15 Jan 2002 12:44:28 -0500
From: Pavel Machek <pavel-AlSwsSmVLrQ@public.gmane.org>
To: Andi Kleen <ak-l3A5Bk7waGM@public.gmane.org>
Cc: andrew-T1OfMDHbC/nR7s880joybQ@public.gmane.org, linux-kernel@vger.kernel.org
Subject: Re: The return of the return of crunch time (2.5 merge candidate list 1.6)
Message-ID: <20020115174416.GC2015@zaurus>
References: <200210251557.55202.landley-O/U8sLjX0KF0TjvJqrojQs21knjtCldOBscD18MNCCY1H/kThXSrnA@public.gmane.org> <p7365vptz49.fsf@oldwotan.suse.de> <20021026190906.GA20571@pimlott.net> <20021027080125.A14145@wotan.suse.de> <20021027152038.GA26297@pimlott.net> <20021028053004.C2558@wotan.suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20021028053004.C2558-B4tOwbsTzaBolqkO4TVVkw@public.gmane.org>
User-Agent: Mutt/1.3.27i
Hi!
> The point of my patchkit is to allow the file systems
> who support better resolution to handle it properly. Other filesystems
> are not worse than before when they flush inodes (and better off when
> they keep everything in ram for your build because then they will enjoy
> full time resolution)
What about always rounding down even when inode is
in memory? That is both simple and consistent.
> If you really wanted that I would recommend to change make.
> When all nanosecond parts are 0 it is reasonable for make to assume that
> the fs doesn't support finegrained resolution. But I'm not sure it's
> worth it.
Thats really ugly heuristics. What about filling
nanosecond part with ~0 when unavailable?
PsvelEnd_of_mail_magic_2338
# New mail (delim 2423)
/usr/sbin/sendmail -oem -oi -N failure,delay -R full -- pavel-+ZI9xUNit7I@public.gmane.org << End_of_mail_magic_2423
Date: Tue, 15 Jan 2002 14:31:14 -0500
From: Pavel Machek <pavel-AlSwsSmVLrQ@public.gmane.org>
To: pavel-+ZI9xUNit7I@public.gmane.org
Subject: [PATCH] Hotplug CPUs for i386 2.5.44 (fwd)
Message-ID: <20020115193101.GD2015@zaurus>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.27i
----- Forwarded message from Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org> -----
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: akpm-LJ1TwQYPT6cQrrorzV6ljw@public.gmane.org, mingo@redhat.com, mochel@osdl.org
Subject: [PATCH] Hotplug CPUs for i386 2.5.44
Doesn't apply to -mm5 because someone did wierd things with the CPU
placement in driverfs, which clashes with this patch which moves it to
kernel/cpu.c...
Usage:
1) Apply patch, and boot resulting kernel.
2) echo 0 > /devices/root/sys/cpu0/online
3) echo 1 > /devices/root/sys/cpu0/online
The CPU actually spins with interrupts off, doing cpu_relax() and
polling a variable. It's basically useful for testing the unplug
infrastructure and benchmarking.
http://www.kernel.org/pub/linux/kernel/people/rusty/patches/hotcpu-x86-28-10-2002.2.5.44.diff.gz
Cheers!
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
----- End forwarded message -----
End_of_mail_magic_2423
# New mail (delim 2439)
/usr/sbin/sendmail -oem -oi -N failure,delay -R full -- rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org linux-kernel@vger.kernel.org akpm@zip.com.au mingo@redhat.com mochel@osdl.org << End_of_mail_magic_2439
Date: Tue, 15 Jan 2002 14:34:02 -0500
From: Pavel Machek <pavel-AlSwsSmVLrQ@public.gmane.org>
To: Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, akpm@zip.com.au, mingo@redhat.com,
mochel-3NddpPZAyC0@public.gmane.org
Subject: Re: [PATCH] Hotplug CPUs for i386 2.5.44
Message-ID: <20020115193356.GE2015@zaurus>
References: <20021028080437.DE7112C0E3-w/Ol4Ecudpl8XjKLYN78aQ@public.gmane.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20021028080437.DE7112C0E3-w/Ol4Ecudpl8XjKLYN78aQ@public.gmane.org>
User-Agent: Mutt/1.3.27i
Hi!
> Usage:
> 1) Apply patch, and boot resulting kernel.
> 2) echo 0 > /devices/root/sys/cpu0/online
> 3) echo 1 > /devices/root/sys/cpu0/online
>
> The CPU actually spins with interrupts off, doing cpu_relax() and
> polling a variable. It's basically useful for testing the unplug
> infrastructure and benchmarking.
Hehe, with this swsusp should be doable on
an smp machine (turn it into UP and suspend;
during resume, turn it into UP, resume, and go
back SMP). I guess I schould get some SMP
to play with...
Pavel
End_of_mail_magic_2439
-------------------------------------------------------
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
^ permalink raw reply
* Re: Significant Slowdown Occuring in 2.2 starting with 19pre2
From: Andi Kleen @ 2002-01-15 12:55 UTC (permalink / raw)
To: David S. Miller; +Cc: ak, alan, linux-kernel, kern0201
In-Reply-To: <20020115.045244.64225720.davem@redhat.com>
On Tue, Jan 15, 2002 at 04:52:44AM -0800, David S. Miller wrote:
> From: Andi Kleen <ak@suse.de>
> Date: 15 Jan 2002 13:49:16 +0100
>
> Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> >
> > The only change in 2.2.19pre2 is the merge of Andrea Arcangeli's VM. Please
> > talk to Andrea and see if he can work out why
>
> Also the merge of blkdev-in-pagecache.
>
> Andi, 2.2.x not 2.4.x :-)
Oops. Thank you David.
-Andi
^ permalink raw reply
* Re: Significant Slowdown Occuring in 2.2 starting with 19pre2
From: David S. Miller @ 2002-01-15 12:52 UTC (permalink / raw)
To: ak; +Cc: alan, linux-kernel, kern0201
In-Reply-To: <p733d17kcdv.fsf@oldwotan.suse.de>
From: Andi Kleen <ak@suse.de>
Date: 15 Jan 2002 13:49:16 +0100
Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
>
> The only change in 2.2.19pre2 is the merge of Andrea Arcangeli's VM. Please
> talk to Andrea and see if he can work out why
Also the merge of blkdev-in-pagecache.
Andi, 2.2.x not 2.4.x :-)
^ permalink raw reply
* Re: 8240 booting:bootp time out and hd lost interrupt
From: Jerry Van Baren @ 2002-01-15 12:50 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <3C441AA9.9A982529@lvl7.com>
On the bootp time out, you appear to be sending ARP packets and not getting
a response. Is your BOOTP server properly configured? To be specific, is
it configured to be 192.168.10.1? Your etherdump trace (ARP with no
response and ICMP "unreachable" error packets) implies not. Ping it to
check, preferably from your custom MPC860P board.
Are you sniffing the ethernet from a different machine than your custom
MPC860P board? You should be: otherwise you don't know if the packet
actually gets transmitted on the ethernet. This could also cause the "no
ARP response" symptoms you show.
It probably isn't significant, and could just be my ignorance, but there
also appears to be a missmatch with the MAC address used: your bootp line
shows 0:e0:4c:45:56:af but your ARP request appears to be using
0:e0:4c:3b:f6:ca.
gvb
At 07:03 AM 1/15/2002 -0500, Neil Horman wrote:
>Hello-
> Not sure if these are going to be you're exact answers, but I've
>recently tackled both problems on a custom MPC860P based board:
[snip]
>2)
> >the other is why the bootp time out. i test the host dhcp configuration
> with >win98 as client.
> It looks to me as though you don't have your bootp server set up
>properly. Looking at your tcpdump, I see you sending out bootp requests
>(eth0 B 0.0.0.0 >....), but I see no responsees. The 192.168.10.13
>address appears multiple times in your tcpdump prior to your bootp
>requests being sent (even on the lo interface which is odd), so it looks
>like that may be a configuration error (perhaps something you passed in
>on the kernel command line?). The fact that you can boot a Win98 client
>with your DHCP server just means that it serves DHCP requests well,
>which are close to, but not bootp requests. I use the ISC DHCP server
>here under red hat 7.1, and to use it to serve bootp requires that I add
>a special bootp entry for every address I wish to serve, like this:
>host <name>:
>{
>hardware ethernet <MAC>;
>fixed address <IP>;
>};
>
>Hope that helps!
>Neil Horman
>
>
>
>
>×ÞÌÎ wrote:
> >
> > Hello:
> > I'm a newer to PowerPC. when i port linux to PowerPC 8240,i met some
> problem.anyone give me advices will be appreciate.
> > i use board sandpoint 3, the cpu board is mpc8240.
> > I mark the line i wish you pay attention to.i have two questions: one
> is why the hdc lost the interrupt. the other is why the bootp time out. i
> test the host dhcp configuration with win98 as client.
> > The dip switch on cpu board is set to : sw2 01111,sw3 11011 (1 means ON)
> > BTW,who could tell me every bit of the two dip switch mean? I
> couldn't find document about it.
> > The dip switch on main board is set to: sw1 11111010 ,sw2 11111111.
> > The type of main board is "ppceval-sp3 rev x3". the CPU board is
> > "m98ppmc8240 rev x2" .linux kernel is Mvista Hard Hat Linux 2.0 for
> > ppc 82xx. My hard disk type is "Quantum fireball 3.5series 30.0GB".
> > the following is bootup message:
> >
[snip]
> > loop: loaded (max 8 devices)
> > Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ
> SERIAL_PCI endttyS00 at 0x03f8 (irq = 4) is a 16550A
> > ttyS01 at 0x02f8 (irq = 3) is a 16550A
> > 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 2048)
> >
> /*******************************************************************************
> > Sending BOOTP requests.......<6>NETDEV WATCHDOG: eth0: transmit timed out
> > ....<6>NETDEV WATCHDOG: eth0: transmit timed out .. timed out!
> >
> ********************************************************************************/
> > IP-Config: No network devices available.
> > NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
> > Root-NFS: No NFS server available, giving up.
> > VFS: Unable to mount root fs via NFS, trying floppy.
> > request_module[block-major-2]: Root fs not mounted
> > VFS: Cannot open root device "" or 02:00
> > Please append a correct "root=" boot option
> > Kernel panic: VFS: Unable to mount root fs on 02:00
> >
> > and I use tcpdump to listen to the eth0, and receive something like
> that:
> >
> > 14:34:27.591370 eth0 B 0.0.0.0.bootpc >
> 255.255.255.255.bootps: xid:0xc6c3f016 secs:88 [|bootp] (DF)
> > 14:34:27.591925 eth0 > 192.168.10.13.bootps > 255.255.255.255.bootpc:
> xid:0xc6c3f016 secs:88 Y:192.168.10.100 S:192.168.10.13 ether
> 0:e0:4c:45:56:af [|bootp] (DF)
> > 14:34:27.595609 eth0 > arp who-has 192.168.10.1 tell 192.168.10.13
> (0:e0:4c:3b:f6:ca)
> > 14:34:28.591256 eth0 > arp who-has 192.168.10.1 tell 192.168.10.13
> (0:e0:4c:3b:f6:ca)
> > 14:34:29.591256 eth0 > arp who-has 192.168.10.1 tell 192.168.10.13
> (0:e0:4c:3b:f6:ca)
> > 14:34:30.591402 lo > 192.168.10.13 > 192.168.10.13: icmp: host
> 192.168.10.1 unreachable [tos 0xc0]
> > 14:34:30.591402 lo < 192.168.10.13 > 192.168.10.13: icmp: host
> 192.168.10.1 unreachable [tos 0xc0]
> > 14:34:32.601383 eth0 > arp who-has 192.168.10.1 tell 192.168.10.13
> (0:e0:4c:3b:f6:ca)
> > 14:34:33.601256 eth0 > arp who-has 192.168.10.1 tell 192.168.10.13
> (0:e0:4c:3b:f6:ca)
> > 14:34:34.601256 eth0 > arp who-has 192.168.10.1 tell 192.168.10.13
> (0:e0:4c:3b:f6:ca)
> > 14:34:35.601276 lo > 192.168.10.13 > 192.168.10.13: icmp: host
> 192.168.10.1 unreachable [tos 0xc0]
> > 14:34:35.601276 lo < 192.168.10.13 > 192.168.10.13: icmp: host
> 192.168.10.1 unreachable [tos 0xc0]
> > 14:34:37.612096 eth0 > arp who-has 192.168.10.1 tell 192.168.10.13
> (0:e0:4c:3b:f6:ca)
> > 14:34:38.611257 eth0 > arp who-has 192.168.10.1 tell 192.168.10.13
> (0:e0:4c:3b:f6:ca)
> > 14:34:39.611257 eth0 > arp who-has 192.168.10.1 tell 192.168.10.13
> (0:e0:4c:3b:f6:ca)
> > 14:34:40.611278 lo > 192.168.10.13 > 192.168.10.13: icmp: host
> 192.168.10.1 unreachable [tos 0xc0]
> > 14:34:40.611278 lo < 192.168.10.13 > 192.168.10.13: icmp: host
> 192.168.10.1 unreachable [tos 0xc0]
> > 14:34:42.621330 eth0 > arp who-has 192.168.10.1 tell 192.168.10.13
> (0:e0:4c:3b:f6:ca)
> > 14:34:43.621256 eth0 > arp who-has 192.168.10.1 tell 192.168.10.13
> (0:e0:4c:3b:f6:ca)
> > 14:34:44.621256 eth0 > arp who-has 192.168.10.1 tell 192.168.10.13
> (0:e0:4c:3b:f6:ca)
> > 14:34:45.621277 lo > 192.168.10.13 > 192.168.10.13: icmp: host
> 192.168.10.1 unreachable [tos 0xc0]
> > 14:34:45.621277 lo < 192.168.10.13 > 192.168.10.13: icmp: host
> 192.168.10.1 unreachable [tos 0xc0]
> > 14:34:47.633769 eth0 > arp who-has 192.168.10.1 tell 192.168.10.13
> (0:e0:4c:3b:f6:ca)
> > 14:34:48.631263 eth0 > arp who-has 192.168.10.1 tell 192.168.10.13
> (0:e0:4c:3b:f6:ca)
> > 14:34:49.631256 eth0 > arp who-has 192.168.10.1 tell 192.168.10.13
> (0:e0:4c:3b:f6:ca)
> > 14:34:50.631277 lo > 192.168.10.13 > 192.168.10.13: icmp: host
> 192.168.10.1 unreachable [tos 0xc0]
> > 14:34:50.631277 lo < 192.168.10.13 > 192.168.10.13: icmp: host
> 192.168.10.1 unreachable [tos 0xc0]
> > 14:34:52.641343 eth0 > arp who-has 192.168.10.1 tell 192.168.10.13
> (0:e0:4c:3b:f6:ca)
> > 14:34:53.641271 eth0 > arp who-has 192.168.10.1 tell 192.168.10.13
> (0:e0:4c:3b:f6:ca)
> > 14:34:54.641268 eth0 > arp who-has 192.168.10.1 tell 192.168.10.13
> (0:e0:4c:3b:f6:ca)
> > 14:34:55.641289 lo > 192.168.10.13 > 192.168.10.13: icmp: host
> 192.168.10.1 unreachable [tos 0xc0]
> > 14:34:55.641289 lo < 192.168.10.13 > 192.168.10.13: icmp: host
> 192.168.10.1 unreachable [tos 0xc0]
> > 14:34:55.711924 eth0 B 0.0.0.0.bootpc > 255.255.255.255.bootps:
> xid:0xc6c3f016 secs:117 [|bootp] (DF)
> > 14:34:55.712391 eth0 > 192.168.10.13.bootps > 255.255.255.255.bootpc:
> xid:0xc6c3f016 secs:117 Y:192.168.10.100 S:192.168.10.13 ether
> 0:e0:4c:45:56:af [|bootp] (DF)
> > 14:35:25.712515 eth0 B 0.0.0.0.bootpc > 255.255.255.255.bootps:
> xid:0xc6c3f016 secs:147 [|bootp] (DF)
> > 14:35:25.713052 eth0 > 192.168.10.13.bootps > 255.255.255.255.bootpc:
> xid:0xc6c3f016 secs:147 Y:192.168.10.100 S:192.168.10.13 ether
> 0:e0:4c:45:56:af [|bootp] (DF)
> >
> > It seems that the host ack the target's require, but target did't
> accept . So the target has no right IP address.
> >
> > regards.
> >
> stone
> >
> > ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡stone@pocketix.com
> > ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2002-01-15
> >
>
>--
>/***************************************
>*Neil Horman
>*Master of Software Feng Shui
>*Lvl7 Systems
>*(919)-865-2915
>***************************************/
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Significant Slowdown Occuring in 2.2 starting with 19pre2
From: Andi Kleen @ 2002-01-15 12:49 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel, kern0201
In-Reply-To: <E16QSuJ-0004y1-00@the-village.bc.nu.suse.lists.linux.kernel>
Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
>
> The only change in 2.2.19pre2 is the merge of Andrea Arcangeli's VM. Please
> talk to Andrea and see if he can work out why
Also the merge of blkdev-in-pagecache. If the magneto optical disk
has a weird blocksize < PAGE_CACHE_SIZE (doesn't it have 2k normally?)
then there could be problems.
-Andi
^ permalink raw reply
* Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)
From: Andrew Pimlott @ 2002-01-15 12:29 UTC (permalink / raw)
To: Bruce Harada; +Cc: esr, linux-kernel
In-Reply-To: <20020115080218.7709cef7.bruce@ask.ne.jp>
On Tue, Jan 15, 2002 at 08:02:18AM +0900, Bruce Harada wrote:
> On Mon, 14 Jan 2002 17:34:23 -0500
> "Eric S. Raymond" <esr@thyrsus.com> wrote:
>
> > Therefore I try to stay focused on Aunt Tillie even though I know
> > that you are objectively correct and her class of user is likely
> > not to build kernels regularly for some years yet.
>
> Change that last line to read "her class of user will never build
> kernels ever, and would be aggressively disinterested in the
> possibility of doing so", and you might be closer to the truth.
>
> Aunt Tillie just DOESN'T CARE, OK? She can talk to her vendor if she gets
> worried about whether her kernel supports the Flangelistic2000 SuperDoodad.
Ok, Grandpa Willie only cares about support for his doodad. Why do
you conclude that he should never build a kernel?
It's just as easy in principle to write a friendly front-end that
downloads sources and compiles them, as one that downloads binaries.
The obstacle is reliability, because there are more things that can
go wrong. But imagine for a moment that this is overcome. What
benefits might accrue from Willie compiling his own kernels (even if
he doesn't realize it)?
- It's easier for third-parties to provide kernel software in source
form than in binary form (because binaries must be in the correct
package format, and be compiled with the right config options, and
adhere to the particular distribution's conventionts; whereas
source is relatively neutral). Why should Willie be limited to
getting his kernels from his vendor? What if his vendor doesn't
support the Flangelistic2000 SuperDoodad yet, but there's a solid
driver available from a volunteer? What if he hears the hype
(sorry) about the low latency patch, and decides he wants to try
it (maybe his MP3's skip when Netscape thrashes)? Why take the
choice out of Willie's hands? And why keep a willing tester and a
developer apart? (If you claim that novice users don't want to
install random beta software--that contradicts my experience with
lots of Windows users!)
- It's a system that experts are likely to use as well, because
there's a lot of overlap between this system and what experts
want. A nice front-end to browse and manage kernel versions,
patches, and drivers; to download, configure, compile and install
them? I might use that. Such a system helps more people, and
thus attracts more developers. It's more likely to become common
infrastructure, instead of a distribution-specific one-off.
- It makes it easier for Willie's hacker grandson to help him.
Hackers know all about compiling kernels, but aren't as likely to
be familiar with the distribution's binary packaging. The more we
all do things the same way, the more we can help each other; when
different groups use different tools, the community is fragmented.
- It can support a graceful transition from beginner to expert.
Suppose one day, for whatever reason, Willie really does need to
change a compile-time option. Or, heaven forbid, he gets curious
about what his computer is doing when the status line says
"compiling". He's already got all the pieces he needs. Ideally,
he just needs to click on that scary "Advanced options" button.
- Building from source is good karma.
You might think these are trifles and < 1% cases. My intuition
tells me that they add up in the long run. At least it's worth
considering.
Andrew
^ permalink raw reply
* Re: Autoconfiguration: Original design scenario
From: Giacomo Catenazzi @ 2002-01-15 12:41 UTC (permalink / raw)
To: Russell King; +Cc: Linux Kernel List, Eric S. Raymond
In-Reply-To: <20020115105733.B994@flint.arm.linux.org.uk>
Russell King wrote:
> I really don't see why hisax couldn't say "oh, you have an ISDN card with
> IDs xxxx:xxxx, that's hisax type nn" and be done with it, rather than
> needing to be told "pci id xxxx:xxxx type nn". Have a look at
> drivers/isdn/hisax/config.c and wonder how the hell you take some random
> vendors PCI ISDN card and work out how to drive it under Linux.
>
> (For the record, the card was:
> 1397:2bd0 - Cologne Chip Designs GmbH - HFC-PCI 2BD0 ISDN
> and the driver requirements were: hisax type 35 proto 2)
>
> Realistically, I don't think any autoconfigurator will solve such cases
> until these areas can be fixed up reasonably.
Autoconfigure cannnot solve this.
The card is not in my database.
To help user, you should tell the driver maintainer to add our card
in the know pci devices. In this manner autoconfigure, hotplug and
modutils can take easy use your card.
This is also a problem of PCI design.
ISAPNP have the function type, USB have also the
function class, so that there exists few interfaces, and kernel
can ask only to specific interface and not to the specific card.
PCI also have the interface field, but not very used, and the
interfaces are also not so standardized.
giacomo
^ permalink raw reply
* Swap: an update on how my box is running now..
From: christian e @ 2002-01-15 12:43 UTC (permalink / raw)
To: linux kernel
Hi,all
Yesterday I downloaded 2.4.18pre2 patch and the 2.4.18pre2-aa2 patch.
Then did the echo 500 > /proc/sys/vm/vm_mapped_ratio
as François recommended..
So far looking good..Not nearly as swap happy now..Here's top output:
foo@bar:~$ top -bn 1|head -n 15
13:40:21 up 3:19, 5 users, load average: 0.57, 0.65, 0.70
113 processes: 108 sleeping, 5 running, 0 zombie, 0 stopped
CPU states: 11.6% user, 15.7% system, 0.0% nice, 72.6% idle
Mem: 514148K total, 508664K used, 5484K free, 9140K buffers
Swap: 248968K total, 8424K used, 240544K free, 281180K cached
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
2056 ce 17 0 1020 1016 772 R 13.5 0.1 0:00 top
1596 ce 1 0 210M 210M 210M R 12.7 41.9 27:23 vmware
1599 ce 20 -19 99972 97M 99380 S < 0.8 19.3 0:12 vmware
1 root 20 0 524 524 460 S 0.0 0.1 0:04 init
2 root 20 0 0 0 0 SW 0.0 0.0 0:00 keventd
3 root 20 0 0 0 0 SW 0.0 0.0 0:00 kapm-idled
Still I'm wondering why 'cached' is soo big.Can I tune it so that it
wont swap until cache+buffers are close to 0 ???
But anyway..I can finally use my Windows in Vmware..Great..
best regards
Christian
^ permalink raw reply
* Re: [2.4.17/18pre] VM and swap - it's really unusable
From: yodaiken @ 2002-01-15 12:39 UTC (permalink / raw)
To: george anzinger
Cc: Daniel Phillips, yodaiken, Momchil Velikov, Arjan van de Ven,
Roman Zippel, linux-kernel
In-Reply-To: <3C439D02.EBCD78C4@mvista.com>
On Mon, Jan 14, 2002 at 07:07:46PM -0800, george anzinger wrote:
> Daniel Phillips wrote:
> >
> > On January 14, 2002 10:09 am, yodaiken@fsmlabs.com wrote:
> > > UNIX generally tries to ensure liveness. So you know that
> > > cat lkarchive | grep feel | wc
> > > will complete and not just that, it will run pretty reasonably because
> > > for UNIX _every_ process is important and gets cpu and IO time.
> > > When you start trying to add special low latency tasks, you endanger
> > > liveness. And preempt is especially corrosive because one of the
> > > mechanisms UNIX uses to assure liveness is to make sure that once a
> > > process starts it can do a significant chunk of work.
> >
> If I read this right, your complaint is not with preemption but with
> scheduler policy. Clearly both are needed to "assure liveness".
You are right: I think however "preemption" is part of
a package of ideas about how the system should work.
So it would probably be better to separate these issues out
> Another way of looking at preemption is that is enables a more
> responsive and nimble scheduler policy (afterall it is the scheduler
> that decided that task A should give way to task B. All preemption does
> is to allow that to happen with greater dispatch.) Given that, we can
> then discuss what scheduler policy should be.
If you would write this as
Another way of looking at preemption is that it is intended
to enable a more responsive ...
then we would be off to a good start in narrowing the discussion.
My reservation about preemption as an implementation technique is that
it has costs, which seem to be not easily boundable, but not very
clear benefits.
> --
> George george@mvista.com
> High-res-timers: http://sourceforge.net/projects/high-res-timers/
> Real time sched: http://sourceforge.net/projects/rtsched/
--
---------------------------------------------------------
Victor Yodaiken
Finite State Machine Labs: The RTLinux Company.
www.fsmlabs.com www.rtlinux.com
^ permalink raw reply
* Re: Hardwired drivers are going away?
From: David S. Miller @ 2002-01-15 12:39 UTC (permalink / raw)
To: alan; +Cc: peter, linux-kernel
In-Reply-To: <E16QSxC-0004yp-00@the-village.bc.nu>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: Tue, 15 Jan 2002 12:44:38 +0000 (GMT)
If at boot time we keep a big chunk of ram free at the kernel end and just
load modules one after each other into that space until we get into real
paging that problem goes away
And we do have module_map/module_unmap interfaces already so it's
easy to toy with this.
I've always been meaning to do a "alloc 4MB page at boot, lock into
TLB, carve module pages out of that, vmalloc when that runs out" on
sparc64.
^ permalink raw reply
* Re: [2.4.17/18pre] VM and swap - it's really unusable
From: yodaiken @ 2002-01-15 12:31 UTC (permalink / raw)
To: Momchil Velikov
Cc: yodaiken, Alan Cox, Oliver.Neukum, Daniel Phillips,
Arjan van de Ven, Roman Zippel, linux-kernel
In-Reply-To: <876664vxm8.fsf@fadata.bg>
On Tue, Jan 15, 2002 at 10:15:11AM +0200, Momchil Velikov wrote:
> >>>>> "yodaiken" == yodaiken <yodaiken@fsmlabs.com> writes:
>
> yodaiken> On Tue, Jan 15, 2002 at 12:34:01AM +0200, Momchil Velikov wrote:
> >> One can consider a non-preemptible kernel as a special kind of
> >> priority inversion, preemptible kernel will eliminate _that_ case of
> >> priority inversion.
>
> yodaiken> The problem here is that priority means something very different in
> yodaiken> a time-shared system than in a hard real-time system. And even in real-time
> yodaiken> systems, as Walpole and colleagues have pointed out, priority doesn't
> yodaiken> really capture much of what is needed for good scheduling.
>
> Well, maybe there are other policies (notably static scheduling ;),
> which may be preferrable in one or other case, anyway, I personally
> tend to think rate-monotonic scheduling is quite adequate in practice.
That's not what we see in real RT applications.
> Of course, anyone is free to prove me wrong by implementing earliest
> deadline or slack time scheduler in the kernel.
My impression is that these are of limited use in applications.
>
> yodaiken> In a general purpose system, priorities are dynamic and "fair".
> yodaiken> The priority of even the lowliest process increases while it waits
> yodaiken> for time. In a raw real-time system, the low priority process can sit
> yodaiken> forever and should wait until no higher priority thread needs the
> yodaiken> processor.
>
> *nod*
>
> yodaiken> So it's absurd to talk of priority inversion in a non RT
> yodaiken> system. When a low priority process is delaying a higher priority task
> yodaiken> for reasons of fairness, increased throughput, or any other valid
> yodaiken> objective, that is not a scheduling error.
>
> What is a non real-time system? E.g. are a desktop playing ogg or a
> server serving multimedia content over ATM, real-time systems? The
> point is that one can view the system as real-time or not depending on
> the dominant _current_ load. A system may have real-time load now and
I don't think so, and certainly the straightforward priority based model
of traditional RT seems grossly wrong. What's the highest priority process -
is it the CD player or is it the niced sendmail that is running in the
background? The fact is we require that _both_ make progress. Therefore
at some time the sendmail process must have effectively higher priority
than the CD player. If we then factor in the many kernel threads that may
be running at any time, the calculation becomes even more problematic.
In RTLinux we have a much simpler environment and we can use the rule:
The highest priority runnable task should be the running task
within some T and the OS gets better as T goes to 0.
If something starves, that's the user problem - our users are programmers
who we want to provide with as much control as possible. We certainly
do not want to have a situation where the stop command to the robot arm
is delayed because the OS needs to run bdflush ...
For Linux, even Linux doing the critical work of playing DVDs, this is
not so simple. The target users are not programmers, liveness and
responsiveness remain important criteria ...
It's clear that much of the problem when people discuss this issue is
lack of clear goals. "Preemption" is a controversial implementation
technique, not a goal in itself - I hope. Even "low latency" doesn't
really capture the intended goal - "low latency" to do what? If it's
simply "low latency" switch to highest priority process, that's not
necesarily anything that is going to be useful in itself. The
"resource reservation" work at CMU seems to me to be way off the point
too. The OGI people have some interesting thoughts about this stuff, but
I don't think they've come close to working out a comprehensive model.
What I think we need is a kind of interval real-time scheduling.
Something like:
The system has a basic timing period of N milliseconds where
N is at lease 500 and probably more.
Over a N millisecond period each process gets a full scheduling quantum
and, if it requests, a full I/O quantum.
For a niced process there is some calculated interval greater than
N. An I/O quantum should correspond somehow to a rate of I/0.
RTLIMIT is used to set the max number of processes allowed to start
and this determines the computation length of "one quantum"
There is this cliche about RT that RT is about deadlines, not speed, but I think
that's only partially true. To say that every task will run during a 1 second period
with today's PC/Server technology is fundamentally different than to say that
every task will run during a 10 millisecond period.
> a non real-time one an hour later, both occasionally intermixed with
> tasks of the other class. It is unreasonable to say "This system is
> non-realtime so use that kernel and when you want to play vidoes,
> please reboot to something else, for example XX-Linux".
Yes, but it's not unreasonable to pop up a window and ask the user if
he/she wants to have the scheduling rates of other applications
stepped down to run the DVD player.
The Oracle logging server is designed to run at 1 second periods
increasing the responsiveness of your current process will
reduce that to a 2 second period.
Email delivery will be delayed up to 1 minute
...
YES NO
and so we can follow the most important OS design technique of all time:
push complexity to user space.
---------------------------------------------------------
Victor Yodaiken
Finite State Machine Labs: The RTLinux Company.
www.fsmlabs.com www.rtlinux.com
^ permalink raw reply
* Re: Hardwired drivers are going away?
From: Alan Cox @ 2002-01-15 12:44 UTC (permalink / raw)
To: peter; +Cc: linux-kernel
In-Reply-To: <20020115025840.11509.qmail@science.horizon.com>
> 1) The main kernel is contiguous in physical memory and is mapped with
> large (4 MB) pages. This reduces pressure on the TLB. Modules are
> 2) Space for module code is allocated in page units. Thus, each module
> wastes an average of 2K. If I'm going to have dozens of modules
> loaded, small machines are going to notice.
If at boot time we keep a big chunk of ram free at the kernel end and just
load modules one after each other into that space until we get into real
paging that problem goes away
^ permalink raw reply
* [BUG] 2.4.18.3, ide-patch, read_dev_sector hangs in read_cache_page
From: Norbert Preining @ 2002-01-15 12:29 UTC (permalink / raw)
To: linux-kernel; +Cc: andre
Hi list, hi Andre!
I already described the problem, now in more detail:
2.4.18-pre3
ide.2.4.18-pre2.12102001.patch
is booting but when checking the partition table of hdf on a hpt370
it hangs in read_cache_page in read_dev_sector from fs/partitions/check.c.
This is what I could find out.
Without the ide-patch it works without any problems.
Hardware:
Athlon TB1400
Epox 8kta+pro (via)
secondary ide controller hpt370 with the most recent bios from the hpt page.
hdf: IBM-DCAA-33610, ATA DISK drive
All other infos could be found in the dmesg output at the end of this email
Best wishes
Norbert
On Mon, 14 Jan 2002, preining wrote:
> Here is the end of a kernel boot WITH the ide patch:
> Partition check:
> hda: hda1 hda2
> hdb: hdb1 hdb2 hdb3 hdb4 < hdb5 hdb6 hdb7 hdb8 hdb9 hdb10 hdb11 hdb12 hdb13 >
> hde: hde1 hde2 hde3 hde4 < hde5 hde6 hde7 hde8 hde9 hde10 hde11 hde12 >
> hdf:
> And here it hangs, nothing more.
>
> I have the following config vars set concerning IDE:
> [/usr/src/linux] grep _IDE .config
> CONFIG_IDE=y
> CONFIG_BLK_DEV_IDE=y
> # CONFIG_BLK_DEV_HD_IDE is not set
> CONFIG_BLK_DEV_IDEDISK=y
> CONFIG_IDEDISK_MULTI_MODE=y
> # CONFIG_IDEDISK_STROKE is not set
> # CONFIG_BLK_DEV_IDEDISK_VENDOR is not set
> # CONFIG_BLK_DEV_IDEDISK_FUJITSU is not set
> # CONFIG_BLK_DEV_IDEDISK_IBM is not set
> # CONFIG_BLK_DEV_IDEDISK_MAXTOR is not set
> # CONFIG_BLK_DEV_IDEDISK_QUANTUM is not set
> # CONFIG_BLK_DEV_IDEDISK_SEAGATE is not set
> # CONFIG_BLK_DEV_IDEDISK_WD is not set
> # CONFIG_BLK_DEV_IDECS is not set
> CONFIG_BLK_DEV_IDECD=y
> # CONFIG_BLK_DEV_IDETAPE is not set
> CONFIG_BLK_DEV_IDEFLOPPY=m
> CONFIG_BLK_DEV_IDESCSI=y
> # CONFIG_IDE_TASK_IOCTL is not set
> CONFIG_IDE_TASKFILE_IO=y
> CONFIG_BLK_DEV_IDEPCI=y
> CONFIG_IDEPCI_SHARE_IRQ=y
> CONFIG_BLK_DEV_IDEDMA_PCI=y
> # CONFIG_BLK_DEV_IDEDMA_FORCED is not set
> CONFIG_IDEDMA_PCI_AUTO=y
> CONFIG_IDEDMA_ONLYDISK=y
> CONFIG_BLK_DEV_IDEDMA=y
> # CONFIG_IDEDMA_PCI_WIP is not set
> # CONFIG_BLK_DEV_IDEDMA_TIMEOUT is not set
> # CONFIG_IDEDMA_NEW_DRIVE_LISTINGS is not set
> # CONFIG_IDE_CHIPSETS is not set
> CONFIG_IDEDMA_AUTO=y
> CONFIG_IDEDMA_IVB=y
> CONFIG_BLK_DEV_IDE_MODES=y
> # CONFIG_CD_NO_IDESCSI is not set
>
>
> Here a dmesg of a boot from another kernel without ide-patches, but
> with the hpt patches FROM the ide patch, so ot must be something
> in another place of the ide patch:
>
> Linux version 2.4.18pre2-packet (root@mandala) (gcc version 2.95.2 19991024 (release)) #5 Wed Jan 9 09:32:03 CET 2002
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
> BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
> BIOS-e820: 0000000000100000 - 000000000fff0000 (usable)
> BIOS-e820: 000000000fff0000 - 000000000fff3000 (ACPI NVS)
> BIOS-e820: 000000000fff3000 - 0000000010000000 (ACPI data)
> BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
> On node 0 totalpages: 65520
> zone(0): 4096 pages.
> zone(1): 61424 pages.
> zone(2): 0 pages.
> Local APIC disabled by BIOS -- reenabling.
> Found and enabled local APIC!
> Kernel command line: BOOT_IMAGE=linux ro root=341 BOOT_FILE=/boot/image hdd=ide-scsi video=vesa:ypan
> ide_setup: hdd=ide-scsi
> Initializing CPU#0
> Detected 1400.087 MHz processor.
> Console: colour VGA+ 80x25
> Calibrating delay loop... 2791.83 BogoMIPS
> Memory: 255640k/262080k available (1153k kernel code, 6056k reserved, 325k data, 224k init, 0k highmem)
> Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes)
> Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
> Mount-cache hash table entries: 4096 (order: 3, 32768 bytes)
> Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
> Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
> CPU: Before vendor init, caps: 0183fbff c1c7fbff 00000000, vendor = 2
> CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
> CPU: L2 Cache: 256K (64 bytes/line)
> CPU: After vendor init, caps: 0183fbff c1c7fbff 00000000 00000000
> Intel machine check architecture supported.
> Intel machine check reporting enabled on CPU#0.
> CPU: After generic, caps: 0183fbff c1c7fbff 00000000 00000000
> CPU: Common caps: 0183fbff c1c7fbff 00000000 00000000
> CPU: AMD Athlon(tm) processor stepping 04
> Enabling fast FPU save and restore... done.
> Checking 'hlt' instruction... OK.
> POSIX conformance testing by UNIFIX
> enabled ExtINT on CPU#0
> ESR value before enabling vector: 00000000
> ESR value after enabling vector: 00000000
> Using local APIC timer interrupts.
> calibrating APIC timer ...
> ..... CPU clock speed is 1400.0716 MHz.
> ..... host bus clock speed is 266.6803 MHz.
> cpu: 0, clocks: 2666803, slice: 1333401
> CPU0<T0:2666800,T1:1333392,D:7,S:1333401,C:2666803>
> mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
> mtrr: detected mtrr type: Intel
> PCI: PCI BIOS revision 2.10 entry at 0xfb3f0, last bus=1
> PCI: Using configuration type 1
> PCI: Probing PCI hardware
> Unknown bridge resource 0: assuming transparent
> PCI: Using IRQ router VIA [1106/0686] at 00:07.0
> Applying VIA southbridge workaround.
> PCI: Disabling Via external APIC routing
> Linux NET4.0 for Linux 2.4
> Based upon Swansea University Computer Society NET3.039
> Initializing RT netlink socket
> apm: BIOS version 1.2 Flags 0x07 (Driver version 1.15)
> Starting kswapd
> VFS: Diskquotas version dquot_6.4.0 initialized
> Detected PS/2 Mouse Port.
> pty: 256 Unix98 ptys configured
> Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
> ttyS00 at 0x03f8 (irq = 4) is a 16550A
> ttyS01 at 0x02f8 (irq = 3) is a 16550A
> PCI: Found IRQ 5 for device 00:0c.0
> PCI: Sharing IRQ 5 with 00:0a.0
> Real Time Clock Driver v1.10e
> block: 128 slots per queue, batch=32
> Uniform Multi-Platform E-IDE driver Revision: 6.31
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> VP_IDE: IDE controller on PCI bus 00 dev 39
> VP_IDE: chipset revision 6
> VP_IDE: not 100% native mode: will probe irqs later
> VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:07.1
> ide0: BM-DMA at 0xa000-0xa007, BIOS settings: hda:DMA, hdb:DMA
> ide1: BM-DMA at 0xa008-0xa00f, BIOS settings: hdc:DMA, hdd:DMA
> HPT370A: IDE controller on PCI bus 00 dev 70
> PCI: Found IRQ 11 for device 00:0e.0
> PCI: Sharing IRQ 11 with 00:09.0
> HPT370A: chipset revision 4
> HPT370A: not 100% native mode: will probe irqs later
> HPT370: using 33MHz PCI clock
> ide2: BM-DMA at 0xe400-0xe407, BIOS settings: hde:DMA, hdf:DMA
> ide3: BM-DMA at 0xe408-0xe40f, BIOS settings: hdg:DMA, hdh:pio
> hda: IBM-DTTA-350840, ATA DISK drive
> hdb: Maxtor 52049H4, ATA DISK drive
> hdc: TOSHIBA DVD-ROM SD-M1402, ATAPI CD/DVD-ROM drive
> hdd: Hewlett-Packard CD-Writer Plus 9100, ATAPI CD/DVD-ROM drive
> hde: IC35L040AVER07-0, ATA DISK drive
> hdf: IBM-DCAA-33610, ATA DISK drive
> hdg: IC35L040AVER07-0, ATA DISK drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide1 at 0x170-0x177,0x376 on irq 15
> ide2 at 0xd400-0xd407,0xd802 on irq 11
> ide3 at 0xdc00-0xdc07,0xe002 on irq 11
> hda: 16514064 sectors (8455 MB) w/467KiB Cache, CHS=1027/255/63, UDMA(33)
> hdb: 40020624 sectors (20491 MB) w/2048KiB Cache, CHS=39703/16/63, UDMA(100)
> hde: 80418240 sectors (41174 MB) w/1916KiB Cache, CHS=79780/16/63, UDMA(44)
> hdf: 7056000 sectors (3613 MB) w/96KiB Cache, CHS=7000/16/63, DMA
> hdg: 80418240 sectors (41174 MB) w/1916KiB Cache, CHS=79780/16/63, UDMA(44)
> hdc: ATAPI 40X DVD-ROM drive, 128kB Cache, UDMA(33)
> Uniform CD-ROM driver Revision: 3.12
> Partition check:
> hda: hda1 hda2
> hdb: hdb1 hdb2 hdb3 hdb4 < hdb5 hdb6 hdb7 hdb8 hdb9 hdb10 hdb11 hdb12 hdb13 >
> hde: hde1 hde2 hde3 hde4 < hde5 hde6 hde7 hde8 hde9 hde10 hde11 hde12 >
> hdf: hdf1 hdf2
> ...
>
-----------------------------------------------------------------------
Norbert Preining <preining@logic.at>
University of Technology Vienna, Austria gpg DSA: 0x09C5B094
-----------------------------------------------------------------------
WIGAN (n.)
If, when talking to someone you know has only one leg, you're trying
to treat then perfectly casually and normally, but find to your horror
that your conversion is liberally studded with references to (a) Long
John Silver, (b) Hopalong Cassidy, (c) The Hockey Cokey, (d) 'putting
your foot in it', (e) 'the last leg of the UEFA competition', you are
said to have committed a wigan. The word is derived from the fact that
sub-editors at ITN used to manage to mention the name of either the
town Wigan, or Lord Wigg, in every fourth script that Reginald
Bosanquet was given to read.
--- Douglas Adams, The Meaning of Liff
^ permalink raw reply
* Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)
From: Marco Colombo @ 2002-01-15 12:31 UTC (permalink / raw)
To: Alan Cox; +Cc: esr, linux-kernel
In-Reply-To: <E16QGVZ-0003Ky-00@the-village.bc.nu>
On Mon, 14 Jan 2002, Alan Cox wrote:
> > > Because the GPL says he's entitled to them ?
> >
> > You miss my point. Sure he's entitled to them. But why should he
> > *have to have them*? They're extra state which, in the presence
> > of a proper autoconfigurator, he doesn't need.
>
> You have it backwards. The _autoconfigurator_ is extra state which in the
> presence of the config he doesn't need
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Alan, Eric (and others, too), please.
Of course the autoconfigurator is an useful piece of software.
And of course Eric is posting to the wrong list here. Kernel developers
don't need any autoconfigurator at all (yes, it's just "extra state").
Eric, Aunt Tillie doesn't need any custom-made, untested, probably not
working kernel. QA comes at a price. The lastest VM fix may take a while
to reach mainstream kernels. That's life.
Face it, you're under the wrong assumption that Alan's 2.2 or Marcelo's 2.4
vanilla kernels are "better" than their patched counterparts shipped by
distro vendors. This is far from the truth[*]. Only very recent 2.2 kernels
can be installed on a Red Hat 6.x with little pain. Call it Red Hat's fault,
or mine, for choosing RH, (it's not Alan's of course), but I wanted
RAID 0.90 from the beginning.
Maybe today you can upgrade most 2.4-based distros to the latest Marcelo's,
but I bet it's going to change as soon as vendors start patching their own
kernels with random backports from 2.5.
No matter how you put it, 99% of the times your autoconfigurator will
produce a previuosly untested configuration. We can discuss about release
policies forever, but Marcelo isn't expected to replicate all the QA job
vendors do before releasing a kernel. Now, the kernel is modular
enough not to turn the issue into a nightmare for the average developer.
Most of the time you DO keep your old .config around. And you know your HW.
And the vanilla kernel you've just compiled happens to work. But you'd
better do some testing before putting it on any production box.
And of course, I consider Aunt Tillie's PC definitely "production".
In the end, I think you're just pushing the right piece of software
on the wrong list. IMHO, endusers compiling the kernel it's not an l-k
issue, it's a distro one.
[*] That is, from Aunt Tillie's standpoint.
.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ Colombo@ESI.it
^ permalink raw reply
* Re: Significant Slowdown Occuring in 2.2 starting with 19pre2
From: Alan Cox @ 2002-01-15 12:41 UTC (permalink / raw)
To: Steve Sheftic; +Cc: linux-kernel
In-Reply-To: <200201150402.XAA08887@leros.siscom.net>
> I've tracked to 2.2.19pre2. I do backups to a SCSI magneto-optical disk.
> My /home backup creates a 700MB+ file (using BRU). When I was using
> 2.2.14, this took roughly a half hour. When I upgraded to 2.2.20, this
> 2.2.17 22 23 22 <--- notable improvement
> 2.2.18 34 40
> 2.2.19p1 30 44
> 2.2.19p2 161 165 <--- 4x to 5x longer
The only change in 2.2.19pre2 is the merge of Andrea Arcangeli's VM. Please
talk to Andrea and see if he can work out why
Alan
^ permalink raw reply
* Re: [CFT][PATCH] watchdog nowayout and timeout module parameters
From: Padraig Brady @ 2002-01-15 12:23 UTC (permalink / raw)
To: Matt_Domsch
Cc: alan, linux-kernel, nils, giometti, pb, chowes, gorgo, info,
lethal, woody, johnsonm
In-Reply-To: <71714C04806CD5119352009027289217022C4115@ausxmrr502.us.dell.com>
Matt_Domsch@Dell.com wrote:
>>Timeout has been moved to an ioctl more by other diffs so Im not sure
>>timeout= is too important
>>
>
> Of the seven drivers I added this parm to, six do not offer such a method
> via ioctl:
> eurotechwdt.c provides WDIOC_SETTIMEOUT.
And was the first to provide it:
http://marc.theaimsgroup.com/?l=linux-kernel&m=100619600900700&w=2
> acquirewdt.c, advantechwdt.c, ib700wdt.c, pcwd.c, wdt.c, wdt_pci.c do not
> provide a set timeout ioctl.
I think all should? As it would be nice/more consistent for all
>
> These already offer a timeout parm, but no set timeout ioctl:
> i810-tco.c, softdog.c, wdt285.o
>
> The other drivers I didn't add timeout parm to anyhow, but they don't have a
> set timeout ioctl either:
> machzwd.c, mixcomwd.c, shwdt.c, wdt977.c
new version of wdt977 in patch does provide WDIOC_SETTIMEOUT
>
> Unless there are strong objections or a push to make it an ioctl everywhere
> instead/also, I'd like to leave it in.
Personally I'm undecided whether param or ioctl is preferable.
I don't think many would need to change the timeout parameter
at runtime, but if you do it's a pain to reload the module,
so I vote for providing both interfaces?
>
>>Rest looks good
>>
>
> Thanks for reviewing and approving. 14 drivers modified, 5 drivers
> approved, one investigating, two email addresses invalid, leaving 6 to hear
> from.
>
> -Matt
What about the following though?
cpwatchdog.c
riowatchdog.c
sbc60xxwdt.c
Actually I think there should be a drivers/char/watchdog directory ?
(there are now around 18 seperate watchdog drivers).
Then the out of date watchdog.txt could be updated to point users
at this directory to see what's available, rather than the current
out of date list:
ICS WDT501-P
ICS WDT501-P (no fan tachometer)
ICS WDT500-P
Software Only
SA1100 Internal Watchdog
Berkshire Products PC Watchdog Revision A & C (by Ken Hollis)
ALso I've drivers here for {IBASE, Portwell} SBC watchdogs.
[Who] will I submit them to?
cheers,
Padraig.
^ permalink raw reply
* [BUG] cs46xx: sound distortion after hours of use
From: Denis Vlasenko @ 2002-01-15 16:24 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org
I have noticed that after hours of palying mp3s thru my onboard audio
(I use cs46xx module) sound becomes distorted (high-pitch noise).
Restarting xmms does not help.
rmmod cs46xx; modprobe cs46xx fixes it.
--
vda
^ permalink raw reply
* Re: [linux-lvm] Re: [RFLART] kdev_t in ioctls
From: Joe Thornber @ 2002-01-13 17:17 UTC (permalink / raw)
To: linux-lvm; +Cc: Alexander Viro, linux-kernel
In-Reply-To: <Pine.LNX.4.33.0201140957040.15128-100000@penguin.transmeta.com>
On Mon, Jan 14, 2002 at 10:01:25AM -0800, Linus Torvalds wrote:
> Consider that done. ANYTHING that exports kdev_t to user space is
> incredibly broken, and will not work in a few months when the actual bit
> representation (and size) will change.
The kdev_t's in the driver interface are just one of the *minor*
problems with the LVM driver.
I came to the conclusion last summer that a rewrite was in order, of
both the kernel driver and the userland tools. The new driver is
called 'device-mapper', and has been discussed briefly on this list.
It aims to support volume management in general, ie. not be LVM
specific.
The userland tools (known as LVM2), will go into beta this week.
Initially they will just replicate the functionality of LVM1, but we
do have a lot of extra features queued which will go in subsequent
releases.
Of course Sistina will continue to support the existing LVM1 driver
for the 2.4 series.
As far as the 2.5 series is concerned, I would much rather see people
embracing the new architecture (or telling me why it sucks). Rather
than trying to hack the LVM1 driver so it works. People have been
complaining for the last year about LVM, we weren't able to do much
about it since we were in a stable kernel and couldn't change any
interfaces. Now that 2.5 is finally here it is time for people to
address the real problems - kdev_t's only scratch the surface.
- Joe
^ permalink raw reply
* Re: [2.4.17/18pre] VM and swap - it's really unusable
From: Martin Knoblauch @ 2002-01-15 12:21 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org; +Cc: rml
> Re: [2.4.17/18pre] VM and swap - it's really unusable
>
> From: Robert Love (rml@tech9.net)
> Date: Mon Jan 14 2002 - 15:16:45 EST
>
>
> > > You're claiming that preemption by nature is not Unix-like?
> >
> > Kernel preemption is not traditionally part of UNIX.
>
> True original AT&T was non-preemptible, but it also didn't originally
> have paging. Today, Solaris, IRIX, latest BSD (via BSDng), etc. are all
> preemptible kernels.
>
He doesn't like IRIX, so ... :-)
Martin
--
------------------------------------------------------------------
Martin Knoblauch | email: Martin.Knoblauch@TeraPort.de
TeraPort GmbH | Phone: +49-89-510857-309
C+ITS | Fax: +49-89-510857-111
http://www.teraport.de | Mobile: +49-170-4904759
^ permalink raw reply
* Problems with linuxppc_2_4_devel
From: Kenneth Johansson @ 2002-01-15 12:21 UTC (permalink / raw)
To: linuxppc-dev@lists.linuxppc.org
I have some date problem BK think that we are at feb23 and that dose not look
right when running revtool. Do anyone else see this or is it my clone?
Also I get alot of "ERROR-cannot cd to linuxppc_2_4_devel" when running bk
pull
--
Kenneth Johansson
Ericsson Telecom AB Tel: +46 8 404 71 83
Viderögatan 3 Fax: +46 8 404 72 72
164 80 Stockholm kenneth.johansson@etx.ericsson.se
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: SCSI host numbers?
From: Itai Nahshon @ 2002-01-15 12:19 UTC (permalink / raw)
To: Richard Gooch; +Cc: Alan Cox, linux-kernel
In-Reply-To: <200201140636.g0E6a4b16527@vindaloo.ras.ucalgary.ca>
On Monday 14 January 2002 08:36 am, Richard Gooch wrote:
> So how about in scsi_host_no_init() we call alloc_unique_number() N
> times until we've allocated the required number of host numbers for
> manual control. These will never be freed. Then all other host
> allocations can be done dynamically. We would just need a flag in the
> host structure to disable deallocation of the number if it's one of
> the reserved numbers.
See that dynamic hosts are also added to the list and *never* removed
from it (even when the host is unregistered). With that behaviour your
unique number functions would be an overkill because we must never
free host nubers.
I suggest these changes:
max_scsi_host initialized in scsi_host_no_init.
max_scsi_host never decremented.
That would fix the problem that I reported.
Than (cosmetic):
rename next_scsi_host to count_scsi_hosts (or num_scsi_hosts)
because it actually just counts the number of registered scsi hosts.
The current name for that variable is confusing...
-- Itai
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.