* Re: Linux 2.2.20-pre4
From: Luigi Genoni @ 2001-06-21 8:43 UTC (permalink / raw)
To: Eric Lammerts; +Cc: Alan Cox, linux-kernel
In-Reply-To: <Pine.LNX.4.33.0106202259290.21784-100000@ally.lammerts.org>
Tried this too, but i have the feeling the kernel compiled with this gcc
3.0 is somehow slower. context switch is slower....
no benchs (no time to make them) to sustain my feeling, just a feeling...
On Wed, 20 Jun 2001, Eric Lammerts wrote:
>
> On Tue, 19 Jun 2001, Alan Cox wrote:
> > > Is it mean now kernel 2.2 with prepatch is (or will be) gcc 3.0 ready ?
> > > If not what must be fixed/chenged to be ready ?
> >
> > It wont build with gcc 3.0 yet. To start with gcc 3.0 will assume it can
> > insert calls to 'memcpy'
>
> I tried it, but didn't run into problems (apart from the volatile
> xtime thing)
>
> Linux version 2.2.18 (eric@andredvb) (gcc version 3.0 (Debian))
> #1 Wed Jun 20 23:15:46 CEST 2001
>
> (Tons of warnings, though)
>
> Eric
>
> -
> 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/
>
^ permalink raw reply
* Re: The latest Microsoft FUD. This time from BillG, himself.
From: Henning P. Schmiedehausen @ 2001-06-21 8:37 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20010620153345.I3089@work.bitmover.com>
Larry McVoy <lm@bitmover.com> writes:
>What would be wrong with Microsoft/Linux? It would be:
Nothing, but...
> a) the Linux kernel
> b) the Microsoft API ported to X
> c) Microsoft apps
> d) Linux apps
>Since Microsoft is all about making money, it doesn't matter if they
>charge for the dll's or the OS, either one is fine, you can't run Word
>without them. If you don't need the Microsoft apps, you could strip
... I would bet, they will try to give you a binary-only kernel module
that must be loaded or else the M$ Word .NET for Linux will not
run. Because they can not license check or something...
>For the last 10 years, Unix has gotten the OS right and the apps wrong
>and Microsoft has gotten the apps right and the OS wrong. Seems like
>there is potential for a win-win.
3:1 that M$ thinks along the same ways. The (now probably called off)
split-up of M$ into an OS and an applications company would've
accelerated this move very much.
It's BTW, what I tell people around me since four years on a more or
less regular base... :-) (check older mails, you'll see that I got
lots of heat for thinking so).
I, personally, would love to see Office, Outlook and Quicken for
Linux. No, not clones. The real thing. Those are about the only
reasons I have to keep a blown up typewriter (aka NT Server) as a
pet. And getting these applications as competition, it would boost the
development and quality (!) of the free alternatives as well. I'd love
to see IE5.5 for Linux, too.
Devils' advocate position: If Linux would not be under GPL but under
BSD license, M$ may have already done so. But consider them porting
one of their monster applications and release it just to find out that
they've linked to GNU readline somewhere because of an QM oversight.
I'd guess, to them, the risk of having their core code base (their
source of revenue) "infected by the GNU virus" is just too high.
Hmmm. After all, they're already using FreeBSD. Maybe they will
release "Windows for FreeBSD" with Office. Now that would be an
interesting impact on Linux (I would be over there in seconds =:-) )
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
^ permalink raw reply
* Re: USB Device Support
From: mferrell @ 2001-06-21 8:34 UTC (permalink / raw)
To: David Woodhouse; +Cc: Darryl Dieckman, linux-mtd
In-Reply-To: <30891.993108683@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]
So far all the USB Storage interface devices I have played with, including
flash on USB, are all pretty much the same. The Linux USB Storage drivers
export the device as a SCSI device to user land. But then again, those are
still only the ones I have played with. Maybe someone wanted to do something
different? Would it even comply with USB spec if they did?
On Thu, Jun 21, 2001 at 08:31:23AM +0100, David Woodhouse wrote:
>
> ddieckma@cliftonlabs.com said:
> > I'm looking into the feasibility of developing a driver for a USB
> > FLASH storage device.
>
> Are you sure this USB device really looks like flash to the computer?
>
> I thought that USB devices, just like CompactFlash, had a kind of
> translation layer built in which does everything for you, including wear
> levelling. They just appear as a USB storage device, don't they?
>
> --
> dwmw2
>
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
--
Mark Ferrell <mferrell@mvista.com>
Monta Vista Software Inc. <http://www.mvista.com>
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply
* Re: [OT] Threads, inelegance, and Java
From: Henning P. Schmiedehausen @ 2001-06-21 8:12 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <3B310650.4050408@magenta-netlogic.com>
Tony Hoyle <tmh@magenta-netlogic.com> writes:
>'Win32'. They kept saying 'Cross platform' and 'Open standards' (the
>VM* has been submitted to ECMA apparently)....
Relax. That's their stunt at Sun. Once they killed the Java VM (that's
what they hope), they will not give a hoot about the "Standards" they
helped to create. Note that in all their "open" and "cross platform"
and "multi language" slides, the absence of Java screams loudly.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
^ permalink raw reply
* Re: Linux 2.4.5-ac15
From: Mike Galbraith @ 2001-06-21 8:10 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.21.0106210226330.14247-100000@freak.distro.conectiva>
On Thu, 21 Jun 2001, Marcelo Tosatti wrote:
> On Thu, 21 Jun 2001, Mike Galbraith wrote:
>
> > On Thu, 21 Jun 2001, Marcelo Tosatti wrote:
> >
> > > > 2 4 2 77084 1524 18396 66904 0 1876 108 2220 2464 66079 198 1
> > ^^^^^
> > > Ok, I suspect that GFP_BUFFER allocations are fucking up here (they can't
> > > block on IO, so they loop insanely).
> >
> > Why doesn't the VM hang the syncing of queued IO on these guys via
> > wait_event or such instead of trying to just let the allocation fail?
>
> Actually the VM should limit the amount of data being queued for _all_
> kind of allocations.
Limiting the amount of data being queued for IO will make things less
ragged, but you can't limit the IO.. pages returning to service upon
completion is the only thing keeping you alive. That's why I hate not
seeing my disk utterly saturated when things get hot and heavy. The
only thing that I can see that's possible is to let tasks proceed in
an ordered fashion as pages return.. take a number and wait. IMHO,
right now we try to maintain low latency way too long and end up with
the looping problem because of that. We need a more controlled latency
roll-down to the full disk speed wall. We hit it and go splat ;-)
> The problem is the lack of a mechanism which allows us to account the
> approximated amount of queued IO by the VM. (except for swap pages)
Ingo once mentioned an io thingy for vm, but I got kind of dizzy trying
to figure out exactly how I'd impliment, what with clustering and getting
information to seperate io threads and back ;-)
> You can see it this way: To get free memory we're "polling" instead of
> waiting on the IO completion of pages.
>
> > (which seems to me will only cause the allocation to be resubmitted,
> > effectively changing nothing but adding overhead)
>
> Yes.
(not that overhead really matters once you are well and truely iobound)
-Mike
^ permalink raw reply
* Re: aic7xxx oops with 2.4.5-ac13
From: Tachino Nobuhiro @ 2001-06-21 8:08 UTC (permalink / raw)
To: Trevor Hemsley; +Cc: linux-kernel
In-Reply-To: <20010621072142Z264883-17720+6265@vger.kernel.org>
Hello,
At Thu, 21 Jun 2001 08:15:10,
Trevor Hemsley wrote:
>
> On Thu, 21 Jun 2001 03:05:02, "Jeff V. Merkey"
> <jmerkey@vger.timpanogas.org> wrote:
>
> > Ditto. I am also seeing this oops calling the sg driver for a
> > robotic tape library, and it also seems to happen on 2.4.4.
>
> In my case it appears that it was the symptom of severe bus problems.
> About 5 minutes after I posted the initial report I discovered that
> the cable from the back of the Nikon to the MO drive had fallen off so
> the bus was running unterminated. Replugging it fixed teh bus error
> and the oops.
>
> Looks like error handling is all fscked up...
>
I saw this oops too. The following patch is working for me, but I don't
know this is a correct fix.
diff -r -N -u linux.org/drivers/scsi/aic7xxx/aic7xxx_linux.c linux/drivers/scsi/aic7xxx/aic7xxx_linux.c
--- linux.org/drivers/scsi/aic7xxx/aic7xxx_linux.c Fri Mar 16 13:47:01 2001
+++ linux/drivers/scsi/aic7xxx/aic7xxx_linux.c Fri Mar 16 13:54:34 2001
@@ -1872,7 +1872,9 @@
break;
case AC_BUS_RESET:
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,3,0)
- scsi_report_bus_reset(ahc->platform_data->host, channel - 'A');
+ if (ahc->platform_data->host) {
+ scsi_report_bus_reset(ahc->platform_data->host, channel - 'A');
+ }
#endif
break;
default:
^ permalink raw reply
* cproto use in the kernel source tree?
From: Urban Widmark @ 2001-06-21 8:04 UTC (permalink / raw)
To: linux-kernel
I would like to automate generating the prototype list for smbfs. The list
in include/linux/smb_fs.h is probably mostly correct ... or not.
Does anyone use this type of tool anywhere else in the kernel sources?
Any input on how to set it up right is appreciated.
Here is what I have right now. arch/i386/math-emu/Makefile has this rule
proto:
cproto -e -DMAKING_PROTO *.c >fpu_proto.h
If I do that in the smbfs Makefile, and run it as:
$ make TOPDIR=`pwd` -C fs/smbfs proto
I get heaps of errors (some of which I also get for the math-emu rule and
fpu_proto.h is definitly hand edited, so I wonder if it is really used).
For one thing it goes digging in "/usr/include/asm/" which isn't exactly
what I want. I can improve it by changing the rule to:
proto:
cproto -e -I$(TOPDIR)/include -D__KERNEL__ -DMAKING_PROTO *.c > proto.h
And that seems to sort of work.
The only thing is that I get wierd errors on some gcc header:
"/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h", line 43: parse
error at token '__builtin_va_list'
Expected: auto char define-name double extern inline register static ...
union
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.0)
$ rpm -qf `which gcc`
gcc-2.96-69
$ rpm -qf `which cproto`
cproto-4.6-5
I know it stops working (it misses some functions and complains more :)
after I apply some of my non-released patches. But that is probably
something I do wrong.
Is cproto even a good tool for doing this in the kernel tree?
/Urban
^ permalink raw reply
* Re: The latest Microsoft FUD. This time from BillG, himself.
From: Daniel Stone @ 2001-06-21 7:59 UTC (permalink / raw)
To: Wayne.Brown; +Cc: linux-kernel
In-Reply-To: <86256A71.007DEAD9.00@smtpnotes.altec.com>
On Wed, Jun 20, 2001 at 05:53:44PM -0500, Wayne.Brown@altec.com wrote:
> Not I. The slides for my last meeting were done as TIFF files and I used xv to
> display them. Plus, the most recent documentation I wrote for one of our
> mainframe applications was done with vi and LaTeX. "What, in addition to the
> printed copies, you want a copy of the Word document? There is no Word
> document. But I'll convert it to Rich Text for you and you can take it from
> there." If my employer didn't require me to use them occasionally, I'd delete
> every Microsoft product on my laptop. It's not that I have anything against
> proprietary software. It's just Microsoft that I despise.
I did the slides for my last LUG talk in MagicPoint (apt-get install mgp, or
on rpmfind.net, or wherever, maybe even with RH, I don't know). Very clean
format - see http://kabuki.sfarc.net/daniel/netfilter/netfilter.mgp
--
Daniel Stone <daniel@sfarc.net>
<Nuke> "can NE1 help me aim nuclear weaponz????? /MSG ME!!"
^ permalink raw reply
* 2.4.6pre iptables masquerading seems to kill eth0
From: Helge Hafting @ 2001-06-21 7:46 UTC (permalink / raw)
To: linux-kernel
I have a home network with two machines connected with
3c905B cards. The main machine also has a isdn dialup connection.
Networking works well except if I let the main machine masquerade
so the other can use the internet too. I use iptables for this.
It works for a day or so, then eth0 goes silent on the main machine.
(Rebooting it shows that the other one was fine all the time.)
The symptoms is that there is no contact between the two machines.
No ping or anything. "ifconfig" shows the interface is up
with the correct ip address, but all packets just disappear.
There are no error messages except from programs that time out.
Bringing the interface down and up
again with ifconfig does not help. It is compiled into the
kernel, so I can't try module reloading.
Is this some sort of known problem? Or is there something
I could do to find out more? I couldn't
find anything in the logfiles.
Helge Hafting.
^ permalink raw reply
* Re: [LARTC] RTNETLINK answers: Invalid argument
From: Michal Kolesar @ 2001-06-21 7:48 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-99294681530099@msgid-missing>
[-- Attachment #1: Type: text/plain, Size: 1936 bytes --]
Hello,
is here somebody who can help me?
Where is the best place (mailinglist) for tc troubleshoting?
Or if You need some another information tell me please.
iptables-1.2.2 - from original sources
ip utility, iproute2-ss991023 - from debian potato distribution
I am newbie I dont have experiences with tc.
What is wrong?
Thank You!
kolisko
----- Original Message -----
From: Michal Kolesar
To: lartc@mailman.ds9a.nl
Sent: Tuesday, June 19, 2001 12:38 PM
Subject: [LARTC] RTNETLINK answers: Invalid argument
Hi all,
I have installed 2.4.5 kernel, Debian Potato.
my tc script:
#!/bin/bash
tc qdisc add dev eth1 root handle 20: cbq bandwidth 10Mbit avpkt 1000
echo root
tc class add dev eth1 parent 20:0 classid 20:1 cbq bandwidth 10Mbit rate \
10Mbit allot 1514 weight 1Mbit prio 8 maxburst 20 avpkt 1000
echo class
tc class add dev eth1 parent 20:1 classid 20:100 cbq bandwidth 10Mbit rate \
5Mbit allot 1514 weight 500Kbit prio 5 maxburst 20 avpkt 1000 \
bounded
echo 100
tc class add dev eth1 parent 20:1 classid 20:200 cbq bandwidth 10Mbit rate \
5Mbit allot 1514 weight 500Kbit prio 5 maxburst 20 avpkt 1000 \
bounded
echo 200
tc qdisc add dev eth1 parent 20:100 sfq quantum 1514b perturb 15
echo sfq100
tc qdisc add dev eth1 parent 20:200 sfq quantum 1514b perturb 15
echo sfq200
tc filter add dev eth1 parent 20:0 prio 25 u32 match ip src 192.168.0.7 flowid 20:100
echo filter100
tc filter add dev eth1 parent 20:0 prio 50 u32 match ip src 192.168.0.0/24 flowid 20:100
echo filter200
after running my tc script:
0 root@gateway:/root# source /etc/init.d/tc
root
class
100
200
sfq100
sfq200
RTNETLINK answers: Invalid argument
filter100
RTNETLINK answers: Invalid argument
filter200
my kernel .config file is attached.
Thank you for help!
kolisko
[-- Attachment #2: Type: text/html, Size: 3776 bytes --]
^ permalink raw reply
* Re: [OT] Threads, inelegance, and Java
From: Albert D. Cahalan @ 2001-06-21 7:45 UTC (permalink / raw)
To: landley; +Cc: Martin Dalecki, Mike Harrold, linux-kernel
In-Reply-To: <01062013535909.00776@localhost.localdomain>
Rob Landley writes:
> On Wednesday 20 June 2001 15:53, Martin Dalecki wrote:
>> Mike Harrold wrote:
>> super computing, hmm what about some PowerPC CPU variant - they very
>> compettetiv in terms of cost and FPU performance! Transmeta isn't the
>> adequate choice here.
>
> You honestly think you can fit 142 PowerPC processors in a single 1U,
> air cooled?
That 142 would be what, a SHARC DSP system? It sure doesn't look
like Transmeta's Crueso. The best I found was 6 and 8 per 1U:
"RLX has managed to tuck 24 servers into a 3U enclosure" --> 8/U
"WebBunker units can hold 12 processors [in 2U]" --> 6/U
For PowerPC I found 32/U to 40/U, in increments of 9U.
See www.mc.com for an example. The processor gets you 4 (four!)
floating-point fused multiply-add operations per cycle, typically
at 400 MHz. Being optimistic, that's a teraflop in 9U.
> Liquid air cooled, maybe...
Nope, plain old air or conduction.
If you're going to rant about off-topic junk, at least try to
throw in a few useful references so people can check facts and
maybe take advantage of whatever it is you're ranting about.
(yeah, yeah, sorry about the VGA console thing)
^ permalink raw reply
* State changes for T/TCP
From: anpol @ 2001-06-21 14:39 UTC (permalink / raw)
To: linux-kernel
Hi everyone,
I am trying to implement T/TCP in linux 2.2.14. I am using a Linux box as a
client and a FreeBSD box as server. I have the following problem:
I send multiple data packets from the client, the sequence looks like this:
1. Client sends syn with data <SYN, PSH>
2. Client sends data <PSH>
3. Client sends data along with its fin <FIN, PSH>
4. Server sends synack <SYN, ACK>
....................................
5. Server sends his data and finishes <FIN, PSH, ACK>
6. Client acks the data <ACK>
7. Server sends fin again <FIN, ACK>
8. Client sends reset <RST>
My problem is in segment 8. In segment 5 the client is already in FIN_WAIT2
since the server acked his fin (client's fin in segment 3) in previous
segments (shown with dots), and when he gets the fin from the server he acks
(segment 6) it and gets in TIME_WAIT (tcp_time_wait() in 2.2.14). But in
tcp_time_wait() the original socket gets linked to another socket-like
structure and then gets closed (CLOSE). Now, when the segment 7 arrives it is
dropped by the client (since its socket is in CLOSE state) and a RST is send
back. But what should happen in T/TCP is that in segment 8 i should have an
ACK for the FIN in segment 7.
My question now (provided that all that i have mentioned before are correct)
is: Should i change the above behaviour of original TCP? If i leave the
socket in TIME_WAIT instead of CLOSE, would that require further changes?
Thank you all in advance
Tasos
p.s. please CC your e-mail to my address (anpol@intracom.gr)
^ permalink raw reply
* Re: USB Device Support
From: David Woodhouse @ 2001-06-21 7:31 UTC (permalink / raw)
To: Darryl Dieckman; +Cc: linux-mtd
In-Reply-To: <02b301c0f9f9$63009790$0201a8c0@dieckman.net>
ddieckma@cliftonlabs.com said:
> I'm looking into the feasibility of developing a driver for a USB
> FLASH storage device.
Are you sure this USB device really looks like flash to the computer?
I thought that USB devices, just like CompactFlash, had a kind of
translation layer built in which does everything for you, including wear
levelling. They just appear as a USB storage device, don't they?
--
dwmw2
^ permalink raw reply
* Re: temperature standard - global config option?
From: Kai Henningsen @ 2001-06-21 7:33 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <B7471019.F9CF%bootc@worldnet.fr>
bootc@worldnet.fr (Chris Boot) wrote on 08.06.01 in <B7471019.F9CF%bootc@worldnet.fr>:
> > Only the truly stupid would assume accuracy from decimal places.
>
> Well then, tell all the teachers in this world that they're stupid, and tell
> everyone who learnt from them as well.
*All*?
> I'm in high school (gd. 11, junior)
> and my physics teacher is always screaming at us for putting too many
> decimal places or having them inconsistent.
Ok, *yours*.
But yours is not all. I certainly don't remember ever seeing that attitude
in school.
And yes, this behaviour *is* stupid. Someone who thinks like that should
never be allowed to become a science teacher.
MfG Kai
^ permalink raw reply
* Re: aic7xxx oops with 2.4.5-ac13
From: Trevor Hemsley @ 2001-06-21 8:15 UTC (permalink / raw)
To: linux-kernel
On Thu, 21 Jun 2001 03:05:02, "Jeff V. Merkey"
<jmerkey@vger.timpanogas.org> wrote:
> Ditto. I am also seeing this oops calling the sg driver for a
> robotic tape library, and it also seems to happen on 2.4.4.
In my case it appears that it was the symptom of severe bus problems.
About 5 minutes after I posted the initial report I discovered that
the cable from the back of the Nikon to the MO drive had fallen off so
the bus was running unterminated. Replugging it fixed teh bus error
and the oops.
Looks like error handling is all fscked up...
--
Trevor Hemsley, Brighton, UK.
Trevor-Hemsley@dial.pipex.com
^ permalink raw reply
* Re: Linux 2.4.5-ac15
From: Marcelo Tosatti @ 2001-06-21 5:44 UTC (permalink / raw)
To: Mike Galbraith; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.33.0106210836340.1043-100000@mikeg.weiden.de>
On Thu, 21 Jun 2001, Mike Galbraith wrote:
> On Thu, 21 Jun 2001, Marcelo Tosatti wrote:
>
> > > 2 4 2 77084 1524 18396 66904 0 1876 108 2220 2464 66079 198 1
> ^^^^^
> > Ok, I suspect that GFP_BUFFER allocations are fucking up here (they can't
> > block on IO, so they loop insanely).
>
> Why doesn't the VM hang the syncing of queued IO on these guys via
> wait_event or such instead of trying to just let the allocation fail?
Actually the VM should limit the amount of data being queued for _all_
kind of allocations.
The problem is the lack of a mechanism which allows us to account the
approximated amount of queued IO by the VM. (except for swap pages)
You can see it this way: To get free memory we're "polling" instead of
waiting on the IO completion of pages.
> (which seems to me will only cause the allocation to be resubmitted,
> effectively changing nothing but adding overhead)
Yes.
> Does failing the allocation in fact accomplish more than what I'm
> (uhoh:) assuming?
No.
It sucks really badly.
^ permalink raw reply
* Cannot complie aic7xxx_mod.o
From: warren @ 2001-06-21 7:06 UTC (permalink / raw)
To: linux-kernel; +Cc: warren
Hi,
I get the source code of aic7xxx untar it in my Linux Kernel directory
and go to the directory "/usr/src/linux/drivers/scsi/aic7xxx" to make
aic7xxx_mod.o.
But i cannot make the modules. The error is as follows:
My Linux is RedHat 6.2 and kernel version is 2.2.14-5.0 .
Please give me some instructions to achieve it.
Best Regards
Warren
^ permalink raw reply
* Re: Linux 2.4.5-ac15
From: Mike Galbraith @ 2001-06-21 6:56 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.21.0106210127150.14247-100000@freak.distro.conectiva>
On Thu, 21 Jun 2001, Marcelo Tosatti wrote:
> > 2 4 2 77084 1524 18396 66904 0 1876 108 2220 2464 66079 198 1
^^^^^
> Ok, I suspect that GFP_BUFFER allocations are fucking up here (they can't
> block on IO, so they loop insanely).
Why doesn't the VM hang the syncing of queued IO on these guys via
wait_event or such instead of trying to just let the allocation fail?
(which seems to me will only cause the allocation to be resubmitted,
effectively changing nothing but adding overhead) Does failing the
allocation in fact accomplish more than what I'm (uhoh:) assuming?
-Mike
^ permalink raw reply
* Re: [LARTC] 150.150. addresses
From: Fredrik Björk @ 2001-06-21 6:42 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-99309192123806@msgid-missing>
At 22:24 2001-06-20 -0400, you wrote:
>Are 150.150.*.* adresses private or reserve addresses?
>My friend has a one, and I tried doing an nslookup, ping, and traceroute
>with no luck.
Private address space is defined in RFC1918 (see
http://www.faqs.org/rfcs/rfc1918.html):
3. Private Address Space
The Internet Assigned Numbers Authority (IANA) has reserved the
following three blocks of the IP address space for private internets:
10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
That is, all addresses beginning with 10., all beginning with 172.16.
through 172.31. and all beginning with 192.168. are private. You should
NEVER use other addresses in your private LAN since that can cause trouble
for you (and normally only you). A customer of mine had set up a private
LAN with addresses belonging to Pittsburgh board of electricity which would
cause their LAN to believe that requests to Pittsburgh were local so they
couldn't be routed out of their office. Not that a swedish company would
ever be interested in Pittsburgh board of electricity, but you never know
what problems could occur. (Say for instance that Pittsburgh board of
electricity hosts the DNS servers for a company that you really want to
contact...)
On the other hand you should be aware that these addresses won't be routed
on the Internet and can therefore be used alongside with your public IP
addresses for switches or other kinds of equipment that you don't need to
be globally, but only locally available.
/Fredrik
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/2.4Routing/
^ permalink raw reply
* Re: freeze with 2.4.5-ac16
From: Justin Guyett @ 2001-06-21 6:30 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.33.0106201842120.29004-200000@gw.soze.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 383 bytes --]
On Wed, 20 Jun 2001, Justin Guyett wrote:
> the offending process is memeat (allocates 192*1024*1024 bytes, then
> memsets it to 0, then sleeps forever, though apparently it never gets to
> that part). It has to be in memset(ptr, 0, 192*1024*1024).
> ksymoops from sysrq-m attached,
hmm, well here's the seperated-by-process ksymoops, decoded on the right
machine even!
justin
[-- Attachment #2: Type: TEXT/PLAIN, Size: 13122 bytes --]
free sibling
task PC stack pid father child younger older
init R current 0 1 0 1312 (NOTLB)
Call Trace: [<c01279a1>] [<c0127b06>] [<c012863a>] [<c01286dc>] [<c012588b>]
[<c0125a1f>] [<c0136ca9>] [<c0137bbd>] [<c0134d4e>] [<c0106aeb>]
keventd S FFFFFFFF 0 2 1 3 (L-TLB)
Call Trace: [<c011d2eb>] [<c010545c>]
kswapd R C1451FA8 0 3 1 4 2 (L-TLB)
Call Trace: [<c0110cbb>] [<c0110c00>] [<c011122a>] [<c0127aa1>] [<c010545c>]
kreclaimd S 00000286 0 4 1 5 3 (L-TLB)
Call Trace: [<c01111d5>] [<c0127b52>] [<c010545c>]
bdflush S 00000282 0 5 1 6 4 (L-TLB)
Call Trace: [<c01111d5>] [<c0131144>] [<c010545c>]
kupdated S C1479FC8 0 6 1 8 5 (L-TLB)
Call Trace: [<c0110cbb>] [<c0110c00>] [<c01311b9>] [<c010545c>]
kreiserfsd S CFAB9FB4 0 8 1 12 6 (L-TLB)
Call Trace: [<c0110cbb>] [<c0110c00>] [<c011122a>] [<c016b6f7>] [<c010545c>]
devfsd S CF706000 8 12 1 22 8 (NOTLB)
Call Trace: [<c015126c>] [<c015d890>] [<c015e145>] [<c0164cf7>] [<c016551f>]
[<c0194725>] [<c0165a22>] [<c0190948>] [<c01909a2>] [<c0157395>] [<c015758d>]
[<c0164b20>] [<c0157a79>] [<c0164cf7>] [<c016551f>] [<c013457c>] [<c012e040>]
[<c0158b16>] [<c0158f12>] [<c0164cf7>] [<c016551f>] [<d081a044>] [<c016c87a>]
[<c016cc09>] [<c016c256>] [<c0159073>] [<c0136e95>] [<c0134e14>] [<c012d7b6>]
[<c0106aeb>]
klogd S 7FFFFFFF 0 22 1 27 12 (NOTLB)
Call Trace: [<c0110c5f>] [<c01da0af>] [<c01da967>] [<c01a8345>] [<c01a856e>]
[<c012d87b>] [<c0106aeb>]
syslogd R 00000000 0 27 1 30 22 (NOTLB)
Call Trace: [<c012858c>] [<c01286dc>] [<c013ae57>] [<c01acdf0>] [<c01a874f>]
[<c013b036>] [<c013b490>] [<c0106aeb>]
kapm-idled S CF23FF94 0 30 1 53 27 (L-TLB)
Call Trace: [<c0110cbb>] [<c0110c00>] [<d090a9d7>] [<d090bcdc>] [<d090c08c>]
[<d090c08c>] [<d090b2e5>] [<c0105453>] [<c010545c>]
cardmgr S 7FFFFFFF 4812 53 1 72 30 (NOTLB)
Call Trace: [<c0110c5f>] [<c019ff9c>] [<c013b0f1>] [<c013b490>] [<c0106aeb>]
sshd S 7FFFFFFF 0 72 1 74 53 (NOTLB)
Call Trace: [<c0110c5f>] [<c013b0f1>] [<c013b490>] [<c0106aeb>]
xfs S CE65FF2C 0 74 1 78 72 (NOTLB)
Call Trace: [<c0110cbb>] [<c0110c00>] [<c013b0f1>] [<c013b490>] [<c0106aeb>]
zsh S CF94FFB0 0 78 1 1338 79 74 (NOTLB)
Call Trace: [<c0105cc7>] [<fffafefe>] [<c0106aeb>]
agetty S 7FFFFFFF 1172 79 1 81 78 (NOTLB)
Call Trace: [<c0110c5f>] [<c017754d>] [<c0173738>] [<c012d7b6>] [<c0106aeb>]
zsh S 7FFFFFFF 0 81 1 122 79 (NOTLB)
Call Trace: [<c0110c5f>] [<c017754d>] [<c0173738>] [<c012d7b6>] [<c0106aeb>]
zsh S CF1BDFB0 0 122 1 138 148 81 (NOTLB)
Call Trace: [<c0105cc7>] [<fffafefe>] [<c0106aeb>]
zsh S C30FFFB0 4708 138 122 150 (NOTLB)
Call Trace: [<c0105cc7>] [<fffafefe>] [<c0106aeb>]
gpm S C32D3F2C 4640 148 1 151 122 (NOTLB)
Call Trace: [<c0110cbb>] [<c0110c00>] [<c013b0f1>] [<c013b490>] [<c0106aeb>]
[<c010002b>]
ssh S 7FFFFFFF 0 150 138 (NOTLB)
Call Trace: [<c0110c5f>] [<c013b0f1>] [<c013b490>] [<c0106aeb>]
agetty S 7FFFFFFF 0 151 1 1312 148 (NOTLB)
Call Trace: [<c0110c5f>] [<c017754d>] [<c0173738>] [<c012d7b6>] [<c0106aeb>]
zsh S C9BCDFB0 24 1312 1 1431 151 (NOTLB)
Call Trace: [<c0105cc7>] [<fffafefe>] [<c0106aeb>]
zsh S C1AB2000 0 1319 78 1432 1338 (NOTLB)
Call Trace: [<c013614c>] [<c0136223>] [<c012d7b6>] [<c0106aeb>]
tail S CE86FF8C 24 1338 78 1319 (NOTLB)
Call Trace: [<c0110cbb>] [<c0110c00>] [<c0119a48>] [<c0106aeb>]
memeat R 00000000 376 1431 1312 (NOTLB)
Call Trace: [<c012858c>] [<c011f0be>] [<c011f14b>] [<c011f25b>] [<c0110374>]
[<c01104d4>] [<c0110374>] [<c01aae1b>] [<c01194f9>] [<c01193d7>] [<c01195c4>]
[<c010a9f8>] [<c0110f3c>] [<c0110374>] [<c0106c18>]
zsh R 00000000 4600 1432 1319 (NOTLB)
Call Trace: [<c012858c>] [<c011eba2>] [<c011f291>] [<c0110374>] [<c01104d4>]
[<c0110374>] [<c0128c75>] [<c012d47c>] [<c0106c18>]
Proc; init
>>EIP; 0000000c Before first symbol <=====
Trace; c01279a1 <do_try_to_free_pages+19/58>
Trace; c0127b06 <try_to_free_pages+22/2c>
Trace; c012863a <__alloc_pages+1b2/240>
Trace; c01286dc <__get_free_pages+14/20>
Trace; c012588b <kmem_cache_grow+af/1fc>
Trace; c0125a1f <kmem_cache_alloc+47/54>
Trace; c0136ca9 <getname+19/98>
Trace; c0137bbd <__user_walk+11/58>
Trace; c0134d4e <sys_stat64+16/78>
Trace; c0106aeb <system_call+33/38>
Proc; keventd
>>EIP; ffffffff <END_OF_CODE+2f6c28b3/????> <=====
Trace; c011d2eb <context_thread+ef/194>
Trace; c010545c <kernel_thread+28/38>
Proc; kswapd
>>EIP; c1451fa8 <_end+11a12fc/106593b4> <=====
Trace; c0110cbb <schedule_timeout+73/94>
Trace; c0110c00 <process_timeout+0/48>
Trace; c011122a <interruptible_sleep_on_timeout+42/5c>
Trace; c0127aa1 <kswapd+c1/e0>
Trace; c010545c <kernel_thread+28/38>
Proc; kreclaimd
>>EIP; 00000286 Before first symbol <=====
Trace; c01111d5 <interruptible_sleep_on+3d/50>
Trace; c0127b52 <kreclaimd+42/a0>
Trace; c010545c <kernel_thread+28/38>
Proc; bdflush
>>EIP; 00000282 Before first symbol <=====
Trace; c01111d5 <interruptible_sleep_on+3d/50>
Trace; c0131144 <bdflush+ac/b0>
Trace; c010545c <kernel_thread+28/38>
Proc; kupdated
>>EIP; c1479fc8 <_end+11c931c/106593b4> <=====
Trace; c0110cbb <schedule_timeout+73/94>
Trace; c0110c00 <process_timeout+0/48>
Trace; c01311b9 <kupdate+71/e8>
Trace; c010545c <kernel_thread+28/38>
Proc; kreiserfsd
>>EIP; cfab9fb4 <_end+f809308/106593b4> <=====
Trace; c0110cbb <schedule_timeout+73/94>
Trace; c0110c00 <process_timeout+0/48>
Trace; c011122a <interruptible_sleep_on_timeout+42/5c>
Trace; c016b6f7 <reiserfs_journal_commit_thread+8f/d4>
Trace; c010545c <kernel_thread+28/38>
Proc; devfsd
>>EIP; cf706000 <_end+f455354/106593b4> <=====
Trace; c015126c <devfsd_read+f4/3a8>
Trace; c015d890 <reiserfs_kfree+14/38>
Trace; c015e145 <unfix_nodes+155/160>
Trace; c0164cf7 <is_tree_node+37/54>
Trace; c016551f <search_by_key+80b/c64>
Trace; c0194725 <ide_dmaproc+13d/210>
Trace; c0165a22 <search_for_position_by_key+aa/380>
Trace; c0190948 <start_request+148/210>
Trace; c01909a2 <start_request+1a2/210>
Trace; c0157395 <make_cpu_key+39/40>
Trace; c015758d <_get_block_create_0+9d/5bc>
Trace; c0164b20 <pathrelse+1c/2c>
Trace; c0157a79 <_get_block_create_0+589/5bc>
Trace; c0164cf7 <is_tree_node+37/54>
Trace; c016551f <search_by_key+80b/c64>
Trace; c013457c <cdget+40/bc>
Trace; c012e040 <init_special_inode+44/d4>
Trace; c0158b16 <init_inode+1f2/1fc>
Trace; c0158f12 <reiserfs_read_inode2+be/c8>
Trace; c0164cf7 <is_tree_node+37/54>
Trace; c016551f <search_by_key+80b/c64>
Trace; d081a044 <_end+10569398/106593b4>
Trace; c016c87a <check_journal_end+20e/23c>
Trace; c016cc09 <do_journal_end+ad/a60>
Trace; c016c256 <journal_end+16/1c>
Trace; c0159073 <reiserfs_dirty_inode+4b/54>
Trace; c0136e95 <path_release+d/2c>
Trace; c0134e14 <sys_lstat64+64/70>
Trace; c012d7b6 <sys_read+96/cc>
Trace; c0106aeb <system_call+33/38>
Proc; klogd
>>EIP; 7fffffff Before first symbol <=====
Trace; c0110c5f <schedule_timeout+17/94>
Trace; c01da0af <unix_wait_for_peer+9b/c0>
Trace; c01da967 <unix_dgram_sendmsg+2c3/370>
Trace; c01a8345 <sock_sendmsg+69/88>
Trace; c01a856e <sock_write+b2/bc>
Trace; c012d87b <sys_write+8f/c4>
Trace; c0106aeb <system_call+33/38>
Proc; syslogd
>>EIP; 00000000 Before first symbol
Trace; c012858c <__alloc_pages+104/240>
Trace; c01286dc <__get_free_pages+14/20>
Trace; c013ae57 <__pollwait+33/8c>
Trace; c01acdf0 <datagram_poll+24/e4>
Trace; c01a874f <sock_poll+23/28>
Trace; c013b036 <do_select+e2/1dc>
Trace; c013b490 <sys_select+338/474>
Trace; c0106aeb <system_call+33/38>
Proc; kapm-idled
>>EIP; cf23ff94 <_end+ef8f2e8/106593b4> <=====
Trace; c0110cbb <schedule_timeout+73/94>
Trace; c0110c00 <process_timeout+0/48>
Trace; d090a9d7 <[apm]apm_mainloop+e3/100>
Trace; d090bcdc <[apm]error_table+4f8/85b>
Trace; d090c08c <[apm]apm_waitqueue+4/c>
Trace; d090c08c <[apm]apm_waitqueue+4/c>
Trace; d090b2e5 <[apm]apm+295/2a8>
Trace; c0105453 <kernel_thread+1f/38>
Trace; c010545c <kernel_thread+28/38>
Proc; cardmgr
>>EIP; 7fffffff Before first symbol <=====
Trace; c0110c5f <schedule_timeout+17/94>
Trace; c019ff9c <ds_poll+64/78>
Trace; c013b0f1 <do_select+19d/1dc>
Trace; c013b490 <sys_select+338/474>
Trace; c0106aeb <system_call+33/38>
Proc; sshd
>>EIP; 7fffffff Before first symbol <=====
Trace; c0110c5f <schedule_timeout+17/94>
Trace; c013b0f1 <do_select+19d/1dc>
Trace; c013b490 <sys_select+338/474>
Trace; c0106aeb <system_call+33/38>
Proc; xfs
>>EIP; ce65ff2c <_end+e3af280/106593b4> <=====
Trace; c0110cbb <schedule_timeout+73/94>
Trace; c0110c00 <process_timeout+0/48>
Trace; c013b0f1 <do_select+19d/1dc>
Trace; c013b490 <sys_select+338/474>
Trace; c0106aeb <system_call+33/38>
Proc; zsh
>>EIP; cf94ffb0 <_end+f69f304/106593b4> <=====
Trace; c0105cc7 <sys_rt_sigsuspend+e3/100>
Trace; fffafefe <END_OF_CODE+2f6727b2/????>
Trace; c0106aeb <system_call+33/38>
Proc; agetty
>>EIP; 7fffffff Before first symbol <=====
Trace; c0110c5f <schedule_timeout+17/94>
Trace; c017754d <read_chan+3a9/6f0>
Trace; c0173738 <tty_read+b0/d0>
Trace; c012d7b6 <sys_read+96/cc>
Trace; c0106aeb <system_call+33/38>
Proc; zsh
>>EIP; 7fffffff Before first symbol <=====
Trace; c0110c5f <schedule_timeout+17/94>
Trace; c017754d <read_chan+3a9/6f0>
Trace; c0173738 <tty_read+b0/d0>
Trace; c012d7b6 <sys_read+96/cc>
Trace; c0106aeb <system_call+33/38>
Proc; zsh
>>EIP; cf1bdfb0 <_end+ef0d304/106593b4> <=====
Trace; c0105cc7 <sys_rt_sigsuspend+e3/100>
Trace; fffafefe <END_OF_CODE+2f6727b2/????>
Trace; c0106aeb <system_call+33/38>
Proc; zsh
>>EIP; c30fffb0 <_end+2e4f304/106593b4> <=====
Trace; c0105cc7 <sys_rt_sigsuspend+e3/100>
Trace; fffafefe <END_OF_CODE+2f6727b2/????>
Trace; c0106aeb <system_call+33/38>
Proc; gpm
>>EIP; c32d3f2c <_end+3023280/106593b4> <=====
Trace; c0110cbb <schedule_timeout+73/94>
Trace; c0110c00 <process_timeout+0/48>
Trace; c013b0f1 <do_select+19d/1dc>
Trace; c013b490 <sys_select+338/474>
Trace; c0106aeb <system_call+33/38>
Trace; c010002b <startup_32+2b/a5>
Proc; ssh
>>EIP; 7fffffff Before first symbol <=====
Trace; c0110c5f <schedule_timeout+17/94>
Trace; c013b0f1 <do_select+19d/1dc>
Trace; c013b490 <sys_select+338/474>
Trace; c0106aeb <system_call+33/38>
Proc; agetty
>>EIP; 7fffffff Before first symbol <=====
Trace; c0110c5f <schedule_timeout+17/94>
Trace; c017754d <read_chan+3a9/6f0>
Trace; c0173738 <tty_read+b0/d0>
Trace; c012d7b6 <sys_read+96/cc>
Trace; c0106aeb <system_call+33/38>
Proc; zsh
>>EIP; c9bcdfb0 <_end+991d304/106593b4> <=====
Trace; c0105cc7 <sys_rt_sigsuspend+e3/100>
Trace; fffafefe <END_OF_CODE+2f6727b2/????>
Trace; c0106aeb <system_call+33/38>
Proc; zsh
>>EIP; c1ab2000 <_end+1801354/106593b4> <=====
Trace; c013614c <pipe_wait+7c/a4>
Trace; c0136223 <pipe_read+af/1f8>
Trace; c012d7b6 <sys_read+96/cc>
Trace; c0106aeb <system_call+33/38>
Proc; tail
>>EIP; ce86ff8c <_end+e5bf2e0/106593b4> <=====
Trace; c0110cbb <schedule_timeout+73/94>
Trace; c0110c00 <process_timeout+0/48>
Trace; c0119a48 <sys_nanosleep+108/180>
Trace; c0106aeb <system_call+33/38>
Proc; memeat
>>EIP; 00000000 Before first symbol
Trace; c012858c <__alloc_pages+104/240>
Trace; c011f0be <do_anonymous_page+32/90>
Trace; c011f14b <do_no_page+2f/e0>
Trace; c011f25b <handle_mm_fault+5f/cc>
Trace; c0110374 <do_page_fault+0/45c>
Trace; c01104d4 <do_page_fault+160/45c>
Trace; c0110374 <do_page_fault+0/45c>
Trace; c01aae1b <kfree_skbmem+b/54>
Trace; c01194f9 <update_process_times+1d/90>
Trace; c01193d7 <update_wall_time+b/3c>
Trace; c01195c4 <timer_bh+24/25c>
Trace; c010a9f8 <timer_interrupt+dc/158>
Trace; c0110f3c <schedule+250/370>
Trace; c0110374 <do_page_fault+0/45c>
Trace; c0106c18 <error_code+38/40>
Proc; zsh
>>EIP; 00000000 Before first symbol
Trace; c012858c <__alloc_pages+104/240>
Trace; c011eba2 <do_wp_page+166/244>
Trace; c011f291 <handle_mm_fault+95/cc>
Trace; c0110374 <do_page_fault+0/45c>
Trace; c01104d4 <do_page_fault+160/45c>
Trace; c0110374 <do_page_fault+0/45c>
Trace; c0128c75 <free_page_and_swap_cache+b5/b8>
Trace; c012d47c <filp_close+5c/64>
Trace; c0106c18 <error_code+38/40>
2 warnings issued. Results may not be reliable.
^ permalink raw reply
* Re: Linux 2.4.5-ac15
From: Marcelo Tosatti @ 2001-06-21 4:35 UTC (permalink / raw)
To: Walter Hofmann; +Cc: Alan Cox, lkml
In-Reply-To: <20010619232328.A19241@frodo.uni-erlangen.de>
On Tue, 19 Jun 2001, Walter Hofmann wrote:
> On Sun, 17 Jun 2001, Walter Hofmann wrote:
>
> > I had already two crashes with ac15. The system was still ping-able, but
> > login over the network didn't work anymore.
> >
> > The first crash happened after I started xosview and noticed that the
> > system almost used up the swap (for no apparent reason). The second
> > crash happened shortly after I started fsck on a crypto-loop device.
> >
> > This does not happen with ac14, even under heavy load.
> >
> > I noticed a second problem: Sometimes the system hangs completely for
> > approximately ten seconds, but continues just fine after that. I have
> > seen this with ac14 and ac15, but not with ac12.
>
> FWIW, here is the vmstat output for the second (short) hang. Taken with
> ac14, vmstat 1 was started (long) before the hang and interrupted about
> five seconds after it. The machine has 128MB RAM and 256MB swap.
>
>
> procs memory swap io system cpu
> r b w swpd free buff cache si so bi bo in cs us sy id
> 1 1 0 77332 1584 15632 67740 44 0 448 0 496 932 84 15 1
> 1 2 0 77456 1848 15944 66960 0 0 372 724 625 2296 62 20 18
> 3 0 1 77456 1780 16208 67044 72 0 336 80 584 1695 20 20 61
> 2 0 0 77404 1464 16672 66652 0 0 572 0 530 2649 26 19 55
> 3 1 0 77344 1464 17000 66480 124 0 656 0 419 879 12 16 72
> 0 3 0 77344 1468 17076 66388 184 0 1080 0 561 654 8 8 84
> 0 5 0 77892 1464 17184 66892 176 128 800 396 415 1050 14 11 74
> 0 5 0 77892 1600 17216 66868 16 0 68 1020 508 295 5 5 90
> 0 3 0 77892 1464 17316 66784 56 0 372 68 464 1287 22 14 64
> 2 3 0 77892 1464 17524 66828 76 0 440 0 398 987 8 12 79
> 1 3 0 77892 1464 17780 66680 32 0 512 0 367 1061 10 10 79
> 1 1 0 77880 1464 18020 66392 224 0 756 0 394 1579 43 12 44
> 2 1 0 77784 2172 18324 64820 16 0 992 0 529 1745 37 19 44
> 0 4 0 77936 1848 18428 65180 124 0 252 920 570 451 23 9 69
> 0 2 0 77888 1680 18564 65656 84 0 744 0 532 721 21 12 67
> 3 0 0 77876 1464 18700 65564 4 0 1176 0 487 804 26 16 58
> 0 3 1 77496 1468 18712 65700 424 100 1296 384 401 532 70 10 20
> 2 0 0 77920 1508 18804 65504 72 248 968 260 525 709 40 9 51
> 2 2 0 77908 1728 18788 65388 0 120 1000 568 568 608 41 8 51
> 0 4 0 77908 1620 18828 65548 0 0 172 356 545 420 22 8 69
> 1 1 0 77904 1712 18472 65464 36 0 1600 0 485 621 52 15 33
> procs memory swap io system cpu
> r b w swpd free buff cache si so bi bo in cs us sy id
> 2 1 0 78124 1528 18496 64940 116 20 884 288 545 604 54 16 30
> 4 0 0 78124 1468 18548 64260 4 0 468 0 449 663 49 6 46
> 3 0 0 77844 3416 18492 63932 100 0 304 0 431 1915 80 16 4
> 1 2 0 77844 2892 18536 64204 60 0 284 820 583 917 64 13 23
> 1 0 0 77844 2824 18544 64236 0 0 40 68 591 550 36 6 58
> 3 0 0 77844 2604 18568 64372 0 0 120 0 455 474 64 13 23
> 1 0 0 77844 2472 18572 64440 0 0 56 0 399 617 35 9 56
> 1 0 0 77844 2456 18572 64460 0 0 0 0 515 721 8 6 87
> 0 0 0 77844 2448 18572 64468 0 0 4 0 469 655 8 8 83
> 1 0 0 77844 2384 18572 64528 0 0 0 428 538 641 7 10 83
> 0 0 0 77844 2388 18572 64528 0 0 0 0 492 733 3 9 89
> 0 0 0 77844 2368 18572 64548 0 0 0 0 520 804 11 7 82
> 0 0 0 77844 2336 18572 64580 0 0 0 0 473 680 6 6 89
> 1 0 0 77844 2276 18584 64608 0 0 12 0 490 966 30 13 56
> 2 0 0 77844 2228 18584 64648 0 0 0 344 539 589 47 7 47
> 3 0 0 77844 2228 18588 64692 0 0 4 0 381 455 29 11 60
> 2 0 1 77844 2180 18588 64700 0 0 0 0 453 781 33 9 58
> 1 0 0 77844 2160 18604 64708 0 0 16 0 390 852 18 5 77
> 2 0 1 77844 1940 18616 64912 124 0 212 0 318 756 40 8 52
> 3 0 0 77844 1680 18620 65180 240 0 244 576 492 1632 87 13 0
> 2 0 1 77844 1528 18540 65540 584 0 592 0 352 2466 90 10 0
> procs memory swap io system cpu
> r b w swpd free buff cache si so bi bo in cs us sy id
> 2 0 0 77844 1800 18516 65588 40 0 40 0 357 675 89 11 0
> 3 5 2 77844 1464 18536 65916 1508 44 1660 264 435 852 37 16 47
> 1 0 0 77844 1484 18532 65968 864 0 936 0 386 667 89 7 5
> 1 0 1 77844 1464 18344 66220 1328 0 1416 280 416 519 54 5 41
> 1 0 0 78856 1464 18236 67776 4276 104 4276 228 528 743 25 12 63
> 2 0 1 78820 1540 18220 67748 588 24 1148 92 507 1816 72 11 16
> 1 0 1 78820 1500 18216 67664 0 0 4 0 319 327 92 8 0
> 1 0 0 78820 1484 18216 67684 0 0 0 0 391 308 94 6 0
> 0 0 0 78812 1468 18196 67716 636 0 996 488 578 1106 12 13 75
> 0 0 0 78808 1476 18196 67712 0 0 0 0 337 399 12 10 77
> 0 0 0 78808 1724 18196 67736 16 0 16 0 368 517 6 8 87
> 0 0 0 78808 1676 18220 67760 0 0 24 0 405 475 7 6 88
> 1 0 0 78752 1680 18232 67832 132 0 192 0 412 457 10 11 78
> 0 2 0 78752 1464 18244 67884 64 0 96 620 542 3293 8 27 66
> 5 0 0 77888 1464 18252 68060 896 0 1516 0 519 611 39 13 48
> 0 0 0 77000 2416 18276 67464 600 0 1516 280 592 764 19 8 73
> 2 0 0 77000 2556 18296 67500 4 0 28 268 595 1789 37 10 52
> 3 0 0 77000 1632 18320 67848 188 0 344 128 561 848 30 11 59
> 2 2 1 77000 1464 18404 67688 0 0 228 412 542 2434 42 18 39
> 1 0 0 77000 1464 18444 67324 8 0 152 224 386 1345 26 19 55
> 2 4 2 77084 1524 18396 66904 0 1876 108 2220 2464 66079 198 1
*************
> procs memory swap io system cpu
> r b w swpd free buff cache si so bi bo in cs us sy id
> 0 1 0 77076 1608 18500 66452 0 0 456 200 493 1175 21 11 68
> 1 0 0 77108 1464 18512 66124 0 0 688 0 286 509 10 6 85
Ok, I suspect that GFP_BUFFER allocations are fucking up here (they can't
block on IO, so they loop insanely).
Can you reproduce the problem with 2.4.6pre kernels ?
^ permalink raw reply
* Re: 2.2 PATCH: check return from copy_*_user in fs/pipe.c
From: Zack Weinberg @ 2001-06-21 6:10 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel, torvalds
In-Reply-To: <15153.28055.544280.527063@pizda.ninka.net>
On Wed, Jun 20, 2001 at 08:44:23PM -0700, David S. Miller wrote:
>
> Zack Weinberg writes:
> > Linus Torvalds wrote:
> > > And before you say "it has to return EFAULT", check the standards, and
> > > think about the case of libraries vs system calls - and how do you tell
> > > them apart?
> >
> > My reading of the standard is that it has to either return EFAULT or
> ^^
> > raise SIGSEGV. But I am not expert in XPG4-ese.
>
> Linus is trying to point out: "what is this 'it'?" Is it glibc or
> what the kernel gives you?
POSIX/XPG doesn't make a distinction between kernel and C library as
far as I see... which is why either a signal or an error return is
permitted by the standard; it depends on where the thing really is
implemented.
> > Whether or not the standard requires anything, I would much rather
> > that the kernel not silently discard error conditions.
>
> But only perhaps from a "quality of implementation" perspective not a
> "correctness" one.
Okay, I'll accept that.
zw
^ permalink raw reply
* ide-floppy fails on ApolloPro 133A-based MB
From: Jörg Ströttchen @ 2001-06-21 6:04 UTC (permalink / raw)
To: linux-kernel
hello,
a few days ago I replaced my old MB by a QDI Advance 10F-board (VT82C694X
+ VT82C686B). Since that time I am running into trouble when writing on my
IDE-Floppy (/dev/hdb), read-access is ok, all other IDE-devices are working
fine.
/var/log/messages reports:
cosanostra kernel: hdb: ATAPI reset complete
Jun 20 14:45:29 cosanostra kernel: hdb: lost interrupt
Jun 20 14:45:29 cosanostra kernel: ide-floppy: CoD != 0 in idefloppy_pc_intr
These problems occurr running 2.4.5-ac15 as well as W98. QDI seems to know
about this problem because they recommend to upgrade to the latest
VIA-chipset-drivers, which did not help (W98). At this point I am not sure
wether the "ide-floppy"-issue is MB-specific or chipset-related. Could anyone
familiar with the VIA-chipset-driver comment on that, maybe its a
development-aspect for the via-driver ?
Thanks in advance
J. Stroettchen
^ permalink raw reply
* Re: [linux-lvm] LVM 1.0 release schedule
From: Heinz J. Mauelshagen @ 2001-06-21 5:58 UTC (permalink / raw)
To: linux-lvm
In-Reply-To: <20010620225153.D1776@dardhal.mired.net>
On Wed, Jun 20, 2001 at 10:51:53PM +0000, Jos� Luis Domingo L�pez wrote:
> On Wednesday, 20 June 2001, at 17:20:13 +0200,
> Heinz J. Mauelshagen wrote:
>
> >
> > Because we are investigating a snapshot allocation offset bug,
> > we are planning to release LVM 1.0 on Friday.
> >
> Will this 1.0 release be integrated into the mainstream Linux kernel
> (2.4.6 I suppose) ?. Or will it be necessary to continue applying patches
> for a while ?
The Alan Cox -ac series is planned to be up to date around that.
Linus will get the update (hopefully) shortly after from Alan.
>
> Greetings, and good job !
Thanks a lot.
>
> --
> Jos� Luis Domingo L�pez
> Linux Registered User #189436 Debian GNU/Linux Potato (P166 64 MB RAM)
>
> jdomingo EN internautas PUNTO org => � Spam ? Atente a las consecuencias
> jdomingo AT internautas DOT org => Spam at your own risk
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
--
Regards,
Heinz -- The LVM Guy --
*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer Am Sonnenhang 11
56242 Marienrachdorf
Germany
Mauelshagen@Sistina.com +49 2626 141200
FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply
* Re: harddisk support
From: Bernd Eckenfels @ 2001-06-21 5:41 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <CA256A72.001BA0E4.00@d73mta01.au.ibm.com>
In article <CA256A72.001BA0E4.00@d73mta01.au.ibm.com> you wrote:
> How can I access more than 16 harddisks?
Create the Device File with:
cd /dev ; MAKEDEV sdq
-or-
cd /dev ; mknod sdq b 65 0
mknod sdq1 b 65 1
...
^ 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.