* Request for moderated posting
From: squid-dev-help-l63656HnnUMPKjDvHGQMeg @ 2004-01-27 3:35 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
This message has been passed onto the list moderators for
approval. This is because you are not a subscriber to this
list or the related squid-users list.
If you wish to avoid this in the future, please subscribe
to the squid-dev list by sending presentation of yourself
and which areas of Squid you are interested to help with
the development of Squid to squid-dev-l63656HnnUN5HvqHVlZymw@public.gmane.org
Or alternatively if you are not really interested in helping
with the development of Squid, subscribe to the squid-users
list.
When when you have introduced yourself and your intentions
to the developers, you may send a request to subscribe on
the list to by sending an email to
squid-dev-subscribe-l63656HnnUMPKjDvHGQMeg@public.gmane.org
with no subject or body.
If you would like to subscribe an alternate email address
from the one you are posting from, send an email
to
squid-dev-help-l63656HnnUMPKjDvHGQMeg@public.gmane.org
to get help on doing this.
Please remember that squid-dev is aimed at squid developers.
If you want to contribute ideas and code, this list is for
you. If you want to track development, please use the web
archives.
Thanks!
The Squid Developers
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Re: [PATCH] kgdb-x86_64-support.patch for 2.6.2-rc1-mm3
From: Andrew Morton @ 2004-01-27 3:28 UTC (permalink / raw)
To: jim.houston; +Cc: ak, george, amitkale, linux-kernel
In-Reply-To: <20040127030529.8F860C60FC@h00e098094f32.ne.client2.attbi.com>
Jim Houston <jim.houston@comcast.net> wrote:
>
> The attached patch updates my kgdb-x86_64-support.patch to work
> with linux-2.6.2-rc1-mm3.
Thanks. Why does it relocate the call to trap_init() in start_kernel()?
^ permalink raw reply
* Re: [RFC/PATCH] IMQ port to 2.6
From: jamal @ 2004-01-27 3:25 UTC (permalink / raw)
To: Vladimir B. Savkin; +Cc: netdev
In-Reply-To: <20040126174122.GB20001@usr.lcm.msu.ru>
On Mon, 2004-01-26 at 12:41, Vladimir B. Savkin wrote:
> On Mon, Jan 26, 2004 at 09:29:56AM -0500, jamal wrote:
[..]
>
> Over here every good networking engineer I have talked to knows this :)
This may be true but its like sticking a finger in the air
and saying the "wind blows south" ;-> Data my friend.
> > Thats what i was assuming. Shaping alone is insufficient as well.
>
> I don't quite understand what you mean here.
> Ultimately, any packet will land in some leaf qdisc,
> where there is a queue of some maximum size.
> If a sender does not reduce its rate, queue overflows, and we drop.
> But in my experience this rarely happens with TCP. I think that sender
> just see measured RTT increase and reduce its rate or shrinks
> its window. I don't know modern TCP implementations in detail,
> but I can see it works.
We are saying the same thing. And we are also digressing from the main
point. So lets drop this part if you dont mind.
> > So why cant you attach a ingress qdisc on eth1-2 and use policing to
> > mark excess traffic (not drop)? On eth0 all you do is based on the mark
>
> And where to drop then?
>
Look at the example i just typed.
In your case you dont need the patch i described; use the standard
ingress qdisc and mark with iptables.
> So, it's just like IMQ, but without that Q bit, only marking?
>
Exactly.
> But how would I calculate guaranteed rate for a client?
Note how i used index 1 for the meter in the example i posted.
index 1 is only for one client.
> Suppose I have 100 clients connected, then I can only
> guarantee a 1/100th of the pipe to each. But if only 5 of them
> are active, then each can get 1/5th of the pipe.
Look at the way i had index 200 and 300 one for sharing within a
device and another for the whole system.
You should also just be able to use marks and shape on egress.
> Round-robin mechanism such as wrr effectively adjusts rates in dynamic.
> I use two-layer hierarchy actually, by applying sfq to every wrr class,
> so a user can download a file and play Quake at the same time,
> with acceptable delays and no packet loss. At the same time,
> user that opens 1000 connections with some evil multithreaded downloader
> thing, has the same aggregate rate, but can't play Quake because
> of high latency. It works wonderfully.
>
> I suppose we can have a flavor of wrr that will not queue packets,
> only find over-active flows and mark or drop over-profile packets
> but 1) no such thing exist AFAIK and 2) it will not have separate
> queue for each user/flow, thus all flows will have same latency,
> only drop probabilities will differ.
>
> So, it seems to me that IMQ fits nicely when there're some artificial
> bandwidth limits (as opposed to bandwidth of some physical interface)
> and no single egress interface for all flows to be shaped.
Look at that sample and then lets discuss further. I spent a long time
typing it (and wanna catch up with other email). I think we may be
gettin close.
cheers,
jamal
^ permalink raw reply
* Mail delivery failed: returning message to sender
From: Mail Delivery System @ 2004-01-27 3:18 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
andrewm-bHIVYo8c//0QrrorzV6ljw@public.gmane.org
SMTP error from remote mailer after RCPT TO:<andrewm-bHIVYo8c//0QrrorzV6ljw@public.gmane.org>:
host sophos.its.uow.edu.au [130.130.68.49]: 550 5.1.1 <andrewm-bHIVYo8c//0QrrorzV6ljw@public.gmane.org>... User unknown
------ This is a copy of the message, including all the headers. ------
------ The body of the message is 31131 characters long; only the first
------ 8192 or so are included here.
Return-path: <acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
Received: from sendmail by chac.its.uow.edu.au with local (Exim 4.30)
id 1AlJjx-0002hE-TD
for andrewm-bHIVYo8c//0QrrorzV6ljw@public.gmane.org; Tue, 27 Jan 2004 14:18:13 +1100
Received: from lists.sourceforge.net ([209.76.255.94])
by chac.its.uow.edu.au (UWSMTPD 1.6)
with ESMTP id 1431663.10306;
Tuesday, 27 January 2004 14:18:07 +1100
From: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
To: andrewm-bHIVYo8c//0QrrorzV6ljw@public.gmane.org
Subject: Server Report
Date: Mon, 26 Jan 2004 19:20:59 -0800
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_0008_39266B6A.A0981059"
X-Priority: 3
X-MSMail-Priority: Normal
X-MessageID: 1431663.10306
X-EnvelopeFrom: <acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> 1431663.10306
X-EnvelopeTo: <andrewm-bHIVYo8c//0QrrorzV6ljw@public.gmane.org> 1431663.10306
Message-Id: <E1AlJjx-0002hE-TD-qWZka7NhzrzJUfT9Ylhh27pzq4S04n8Q@public.gmane.org>
This is a multi-part message in MIME format.
------=_NextPart_000_0008_39266B6A.A0981059
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: 7bit
The message cannot be represented in 7-bit ASCII encoding and has been sent as a binary attachment.
------=_NextPart_000_0008_39266B6A.A0981059
Content-Type: application/octet-stream;
name="ybkuwt.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="ybkuwt.zip"
UEsDBAoAAAAAAJ0aOzDKJx+eAFgAAABYAAAKAAAAeWJrdXd0LnNjck1akAADAAAABAAAAP//AAC4
AAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKgAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFBFAABMAQMAAAAAAAAAAAAAAAAA
4AAPAQsBBwAAUAAAABAAAABgAABgvgAAAHAAAADAAAAAAEoAABAAAAACAAAEAAAAAAAAAAQAAAAA
AAAAANAAAAAQAAAAAAAAAgAAAAAAEAAAEAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAA6MEAADAB
AAAAwAAA6AEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
VVBYMAAAAAAAYAAAABAAAAAAAAAABAAAAAAAAAAAAAAAAAAAgAAA4FVQWDEAAAAAAFAAAABwAAAA
UAAAAAQAAAAAAAAAAAAAAAAAAEAAAOAucnNyYwAAAAAQAAAAwAAAAAQAAABUAAAAAAAAAAAAAAAA
AABAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ADEuMjQAVVBYIQwJAglIfomP1DYcgSmWAABTTgAAAIAAACYBAMXuhwKSAFAmSgBAA/2yaZosEAT0
JegBAEvOaZpu2R/IKsADuLCopmmapqCYkIiAmqZpmnhwaGBYUM1gn2lIAEQHODA0TdN0AygkHBgQ
0yy71wgjA/gp8OhN0zRN4NjQyLy0NE3TNKyknJSMzjZN04h8cGgpb1ym6ZrBB1RMA0Q4mqZpmiwk
HBQMBGmazm38KH8D9OzkpmmaptzUzMi8mqZpmrSspKCYkGebpmmMgHhwKHto3mzTdQdcA1RMKP/7
C3a2++NADzQo9ywvA5qmGfkkKEocFAwEaZrO7Jv8JwPs6OCmaZqm2NTMyMCapmm6uCewrKigmGma
pmmUjIiEfKRpmqZ0bGRcVGmaphtMA0RAODCmaZqmKCAYEAiapnObAPgmzwPo4Nhnm85tVDRDA0A0
NNuK/////51a0Nrl9AYfM05sck7YApdfksgBPXy+Q0uW5DWJ4DqX//////dawCmVBHbrY95c3WHo
cv+PIrhR7Ywu03sm1A058Kpn/////yfqsHlFFOa7k25MLRH44s+/sqihnZyeo6u2xNXpABo3////
/1d6oMn1JFaLw/48fcEIUp/vQpjxTawOc9tGtCWZEIoH/////4cKkBmlpaj+8sPSqPgSLEprj7bg
DT1wpt8bWnzhJ1XJ/////xJgvhhl1TieF3PiVIlBvJrjP8ZQjW0Alk/LagyxQ3qy/////3MXzohH
BciKVyPyxJlxTC4L79bArZ2Qhg97enyRiZSi/////7PH3voVNVh+p8MCNHmh3Bpbj+Ywbc0gds8r
ivxRuSSS/////wN37mjlZehul4ODdoyVobDC1+8KKEltlL7rG06Evfk4/////3q/B1Kg8UVsllOz
GnzlUcAypx+aGJkdpC67S950DalI/////+qPN+KQQfWsZiPjpmw1AdCid08qCOnNtJ6Le25kXVlY
/////1pfZ3KAkaW81vMTNlyFseASR3+6+Dl9xA5bq/5UrQk9/////5p3pwJw4VXMBsNDxlzVYWFk
anN/jKC1zegGJ0tynMn5/////yxim1cWWH2wYCb+I3rUMZHkWsMvzhCF/XT2d/uADJkp/////7xS
64cmyG0VwG4fk4pE4ZTUEiHfroBVLRjmx6vyfGlZ/////05COzc4OD1FUF5vg5q00fEUOmPPvvDl
bLbkI1v3vGGo/////9A7ie5zPGP4meDFS5EXoSHeIrM/P1RIUXtvftbP2W6V/9/+/ykDI+mUCb/m
86VBEKZ8MmlrgCELLcdO0hCCbPn/////c6d33hSHBwf7UqoBYcAsm/cmlt2XnSJgD0aezf0sQH//
////k7LS8QkgWHZoY11QUlFTamR3ASzF71QwvFcRPM6dV27/////IOOtYNrRUhXOZl+3QcAU5GWT
n3j+cg2852qVe3sTdnb/////fRwNLfL29LDx0ed5+t1MZaP/J2yM3QvbjBupvXWHO0//////2xSC
QhQJRcyCD/pitylz+xWD5x6TfrQkaSn/vSjL6k7//+3/dw46sL/3VNTsc5gBTQad8qKvwmLz5V43
3wVxUv////8H+BtAflQ+p6lPLAJ9MMjnBtJUKhprTAGdBPZq+h3HBv+F///4HZAEq5YABgYQK++Z
1E7/F3gLk8b4dSGMpP////9f/8xya+tv/qX97NBByXiR2cSsJsfo4Km3Gl1v7CkQo/////+88+31
b1EhNY3WUxxIKRjjt1w/nbjN0FJV47VD6r5n4/////+goDLizkk6JC8wCo+uhOF1QKFimLL1MErg
4/+RgcEnB/////93iGePVLOFCOL+gkWrYY502rsqOK7wStQYnBeKSMK1vP////+e+x9W5m6Q4DtH
s6Aat9KqvMT3k0imAcAE/wYSi12p2P////+9lDH4H+haYz7f1grKQtUMXmBJcvX0rvRTF/wWFfKO
mv////9zcDyCseKON1tTFqInlFRYrLE1Nz6qdWWVIW7rGoSBav/////mChg/OpWfgYLjc6RHPQkC
1i6IwqfVP4pc6p9WO189Sv/S///DeV9DCbjwq5rOHrKF2UvB1Dtez9/2R/lK9//////Y+y20imdi
/1itEYwi91vLWN+F/KzgZdrrl5TiYAjvP/////884+x/EI5gft1Nm+SdBRuXetvMs/s3jyXxOR2y
fBr1Hf////8fvZ/pxurp6z7ZlnD9O9pFJfbzpOfWBCFMOf5bpIeJkv///wud07BbjSo2QhvK0eQ0
UKzDHMXhZopsWzNRQv/////tPiOrYtfulPQ0sunVSaxeJq68bXlnlVs3hqSCPa6Hw/////+HsIC2
30Pfu4uAZS8eqDLLtSqTN0N54mI0WrrtaVxsIv////+sGNVz4evIhi9aSU/xQ/M3y282GD1nLaHx
mEISuA3Byv+3//9rCmv4BY2NB56X6IhQtrK42fMygV/afl/30B0N/////0obAzp9Dz8LTxjxK+GI
tTck99QHHzdvzWuQXUKWl5+i/////5+dLyZWQIb3G6y1WrwnOySknYnTyKVPNvpoAL4+XRnW/9v/
//XJFMnw5I4sNokL4Ibr0QsKM9OzNoaS5L2KMKD/////x7levNDeq8HISteCv13loJ6TkCXYQC8x
oAmmszABodj/////X62RaLwYcjn1LKFjYYseGkEmNxtHqtnwu8XmMeBMLGk3/v//6PoRxnD3Q/tH
otqg1fcoxb+1lXDRBPXwTWkb/P///5Y9kwalLLo5eAzbnQIjw5lVloRbh0I8/////zM0gDX2HfMk
pl7G7zja3KqH39hyLz/E5PaWNo9ENUf1/////0HVkSZpZ8oT2iwybQkpEXNaQVYLOj3wUh2sL6Ya
8Lf6//9L/zEUJpeSD7SkLL5e0AzPz7cAa9N6kVQ4iJKx/zdo/+UK5+CVJZrIztaCA6XOe/G08x02
//9f+LAM0X+RjyX+Uoo2dWvv28HZI8YPPnUVpMD9/////7y6wzwIWudzhm7VsFdwOg9+pNxQ1UI/
D46vP6vgQHPj////G8Jcf4kUsvntAxgi/guPKpSVHU1h+iZvYRODv/D///4dwgw9++Z/Pyg0niuv
Is0poutnXLhoSX5mS3+D/8CqqtMqy3VooCinSN/bpxo9Jf////8kBdfl7ODt4vj5DmeXVpG79FzN
19+Rurc/uZpdiKxdOf8W///scWuX7CvALghoxZ1ZGwkL7xm2U1mVWQ//////Enb5m9SRr06wQUig
7ocopmefDsc/T8i2AsWZXLVkcw6/xP//mwC2QVQU6wmD6sUA+Y5lXmhhFPbj4VKT/8L//9rIX5t3
xqKJytLk2yLxH48cya7VQHi4TNx8//////HJs26AaqCFK4S54KvN53F/t5sxWrWR0gg0cE6MJqNp
v/T/bzUIm12byItb/UCW3EBYzBDq/LCLxW3/////i7LfHfd0EdwmqRAgSn4yQb7lYUvpcn8nvAZD
k1L5Exv/////9l2+QJzCD5kAxous9YbX4IKed4v61OZOEMIYSz4o7fn/xv/2fAp/R8NqdrmZ/l2u
bFrNThvriXGO/Bv9///x9gZ8eVwTsU8h9VT1K2J9pGNwtapiSpH/////NcaYZoAiWI9VLHjYQbE6
LHIQcNvvrGWSeeQf9fFKfWj//7/9a/DmwnRtA/4QUD3FQNqbogkIiH0B+TLGpQd0Gf////8s886o
INbejbWmfm/llFZHQdjM7uuf9k8K4SbuOlm0Wv////8DRXH3nwiDNaCSVqL/Em5agE/9LvZoK6H3
ozr8Mzy9R////xY+SNiGVd8rwmwLhB+G2BfPBenU/evl2vX/////oa28Y04+A/OGhB4e59Kee0Oh
vjuxnzTqilnbWWOvMqz/f+P/UMW+KcXlBOpf/gE8fcp288FLi388G1gLZIH/l/7/zDVEcN3wEDJH
SYS62NSArAHoCGs5EX0R7+P//8b/9z2wtBhHMTGfjKaN64hStOPPO6YXEspnD63/b5T+d0e0zR44
vOJoQZgBCQMPAbgRtL2F/v//OQ11YCEb7WEUu4iyZlWUzYJVz6FuGa9SG/3//7dSpCoQS7DvKZAv
72JQKWmvdKWWbadVD/D//9vSfeg2mRbgbKcMvEZXguXrNqSWfKDpYo////9vITkyKEN+q8OpjiHA
+SJDI1py/CRPQij6WYDOxP////90Icue7lWYFE/sT9EipSixBbk6mBN6f1HJaHmdjrHC7P////8W
JF6DVibzUEyneDR11QV1tQ5OvQl3+THhH2D7dNZV0f////9I3WnpcByarVvw+YZGy61G8bM6Ya2g
Zsrzsa/5tpQFzW9V4P+mjH5OU68wuWb44RQvQER4/////36KtuavqE5c3tYtqqytryuFym8V2Csj
UTvs3cnPSkKT/V/6/+6sqi/wbyF6jO9QRSEFcz0jBggp5bqpUP/tS7y50mNuS+7NKKqhkjh7TgMJ
83v//////6G/NrQ1uUDKF+WFEKlF5IYr034sXe1sCr5wx47QnWx/o//WXq16vvvk7tmY6PVVOAsd
9pOeX6jB/4ynRx76iOjTI1R5IvWqhQ7//9/ga40Sh5rwSH5xYUAtHeKB4LPzn965m56I+v9/+/SL
GIz1qIoaYJMKZOY7F5gJHj/5tLK6cTO/dKEXOTbTcWOXfbrUUDBCBYv///9bEkxrr77b2wB7Mhl1
wMR8S7q0U+cWQ6MIwP///3+RDTjIf/GMMieTG3YGIsYIoTBaIO579h/Fr5IOYdf//wL/cj91DzwF
Qn2HfADSYjG70GqBu1bu7GFZ//+/9UyExLTCAUtYMtqTHPjH82O4nX//TBuvVXOm//9/idxR1/7/
Y6uPvh3LTd755dO39hzsPp/6sfv///8xZXpCOlu2J40AUMvgDP3tEJXmZ/aF/vSNWaP9xgn//y1+
Jcp6CHtJxuy1sbFB5zwN0BZrcH5La/////8bPtpOMKrrC5up6NIT0bREBuu8NojQKbqlXlH9JJ4S
W/9/6/9qo6S6On/GIA+HyVBMXvxkznl/rbV6eSgpuf////81SarqyAzDLUpiTzTfRjZ4W5HRvkZQ
MYbVjtVKU7n1J/////9GqhotlUoL/JvmI6JrNwbYrYVgPh8D6tTBsaSak4+OkP9f+P+Vnai2x9vy
DClJbJK7L0h9tfAub7P6RJHhNP+XfqmKtZ4AZc04J4sCfPl5/IILl5f/Qv//mqCptcTW6wMePF2B
qNL/LwHRDUyO0xtm/////7QFWbAKZ8cqkPll1Ea7M64srTG4Qs9f8oghvVz+o0v2/1v8/6RVCcB6
N/e6gEkV5LaL4xz94ciyn4+CeP////9xbWxuc3uGlKW50OoHJ0pwmcX0JluTzgxNkdgib78SaH/j
///BHXzeQ6sWhPVp4FrXV9pg6XV1woeTorTJ4f//v8X8GtaGsN0NQHav6ypssflEkuM3juhFpQj/
/1v8btdDsiSZygqLD5YgrT3QZv+bOtyBKdSC/////zPnnlgV1ZheJ/PClGlBHPrbv6aQfW1gVk9L
SkxRWWRy//+N/oOXrsjlBSiCo9IEOXGs6itvtgBNnfBGn///f4n7/iGJ9GLTR744tTW4PsdTU1Zc
ZXGAkqf/////v9r4GT1kjrvrHlSNyQhKj9cicMEVbMYjg+ZMtSGQAnfG////72roae10/osbrkTd
eRi6XweyYBHFfDbzs3ZzpRf4/9Ggckcf+ti5nYRuW8I0LSmf/////y83QlBhdYymw+MGLFWBsOIX
T4rICU2U3it7ziR92Tia/N/6//9n0kCxJZwWkxOWHKXONDpDxz5whfnY1qn//1uiQmyZyfwya6fm
KG0gYE6fgyqk3f//X2jELP9u4FXNSMZHaTLcaYHsIrtX9pg9+i/0/+WQPu+jWhTRPDQa41RQJf3Y
tpd7Yvh/6ResKRwSCwftDRUgLj/rCoShB4T///+30F+OwPX7CKbnK3K8Cb3MAlu3FnjdVbAeDwN6
//////RxujGozUpDISoPaXACYzrS4pSpaXlFib58JYWRVQ7B+Lf+/+0eU7VE7t9o8Ucyln+MHVvI
Jal81Saz//9btIDStQRigm4ciuRMot0AUbml6S7/f4vGS3CHVzwnaXtoiZWigJ3m6/OJ/9/4239t
WwwL+YPoESOe3wtGhGgxUJrnN4r//w3+4DmV9Fa7I9pt4VjST89S2GHt7fD2/wsa//8v/SxBWXSS
s5koVYW47idjouQpcbwKW68
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* eccentric
From: Brenton Godfrey @ 2004-01-27 3:17 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 189 bytes --]
insubstantial organometallic delphic pluto
boastful cedric rotogravure applied casein mayonnaise
inconvertible painful bun phyla ferromagnetism impression hays inherit glassine flexural
[-- Attachment #2: Type: text/html, Size: 3441 bytes --]
^ permalink raw reply
* [linux-lvm] Re: LVM2 + Linux 2.6.1 questions
From: Måns Rullgård @ 2004-01-27 3:17 UTC (permalink / raw)
To: linux-lvm
In-Reply-To: <20040127001252.A21930@cs.mcgill.ca>
Navindra Umanee <navindra@cs.mcgill.ca> writes:
> Måns Rullgård <mru@kth.se> wrote:
>> > 2) Why do I see, for example, a /dev/mapper/v01-home entry,
>> > instead of /dev/v01/home, when running 'df' and 'mount'? I
>> > see that /dev/mapper/v01/home symlinks to
>> > /dev/mapper/v01-home, which must account for this, though I
>> > thought that because I'd specified /dev/v01/home, that it'd
>> > appear as such? Not that this really matters I suppose ;-)
>>
>> I see the /dev/vg/link name.
>
> Mine shows /dev/mapper/vg-link too. I would definitely prefer
> /dev/vg/link because at least it's not implementation dependent... but
> I guess it's mostly an aesthetic thing.
>
> Any idea why yours is different? Different version of mount maybe?
> Using mount-2.11z here...
Same version here. It struck me that my /etc/mtab is a symlink to
/proc/mounts. Maybe that makes a difference.
--
Måns Rullgård
mru@kth.se
^ permalink raw reply
* Separate Boot Partition
From: Peter @ 2004-01-27 3:15 UTC (permalink / raw)
To: linux-newbie
Hi,
Presently my boot folder resides under root as /boot. If I decide to make a
separate boot partition on my hard drive are then the following steps the
right way?
-- Make a partition on the hard drive of 50 MB and format it.
-- in fstab put "/dev/hda3 /boot ext3 defaults 0 0
-- move /boot to /tmp/boot
-- mount /boot
-- move files of /tmp/boot to /boot
If so do i have to make a new mkbootdisk?
Thanks & regards
--
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs
^ permalink raw reply
* Re: [RFC/PATCH] IMQ port to 2.6
From: jamal @ 2004-01-27 3:14 UTC (permalink / raw)
To: Tomas Szepe; +Cc: Vladimir B. Savkin, netdev
In-Reply-To: <20040126152409.GA10053@louise.pinerecords.com>
On Mon, 2004-01-26 at 10:24, Tomas Szepe wrote:
[..]
> Actually, this is very much like what we're using IMQ for:
>
> +-----------+ eth1 --- \
> | shaper + eth2 ---
> Internet --- eth0 + in bridge + . --- ... WAN (10 C's of customer IPs)
> | setup + . ---
> +-----------+ ethN --- /
>
> We're shaping single IPs and groups of IPs, applying tariff rates
> on the sum of inbound and outbound flow (this last point, I'm told,
> is the primary reason for our use of IMQ).]
This does not IMQ. I am going to type an example at the end of the
email.
> The machine also does
> IP accounting (through custom userland software based on libpcap)
> and has to be an ethernet bridge so that it can be replaced by
> a piece of wire should it fail and there was no backup hardware left.
>
Ok, now you are throwing an extra wrench ;->
As i mentioned earlier current dependency of ingress on netfilter
is the wrong abstraction (this also applies to IMQ). And for
this reason it must go. If you are running 2.4.x i can give you a patch
that fixes this and will get things working for you even when you use
bridging. Infact i will give example based on this patch.
BTW, how are you going to do SNAT with bridging?
The example below tries to show many things. Example sharing of
policers across many flows within a device, and across devices.
Also shows how to do it so that inbound and outbound are summed up.
I spent about 30 minutes coming up with this; i hope it illustrates
the potential
cheers,
jamal
---- start untested script here -------------------
#
#
# lets take example flow1 10.0.0.21 sits behind eth1 packets
#
#
# the idea is to have 10.0.0.21/32 first try to use bandwith
# guaranteed to it (index 1) if exceeds that it gets demoted to mark 2
# and it tries to use bandwidth that is shared by all flows
# behind eth1; (index 100)
# if that fails it gets demoted even more to mark 3 and it tries to use
# from a pool of bandwith available to every flow on every device
# index 300 if that fails then drop the packet etc
#
# on egress use the marks to select different priority queues.
# Give better treatment to mark 1 than 2 than 3 ..
#
# On the return path from internet to eth1, packets from
# internet to 10.0.0.21 are forced to use policer index 1
# and therefore ensuring that the bandwidth is allocated
# is the sum of inbound and outbound for that flow ..
#
#
#add ingress qdisc
tc qdisc add dev eth1 ingress
#
tc filter add dev eth1 parent ffff: protocol ip prio 1 \
u32 match ip src 10.0.0.21/32 flowid 1:15 \
# first give it a mark of 1
action ipt -j mark --set-mark 1 index 2 \
# ensure policer index 1 is used
action police index 1 rate 1kbit burst 9k pipe \
# exceeded flows bound rate ..
action ipt -j mark --set-mark 2 \
#
action police index 200 mtu 5000 rate 1kbit burst 10k pipe \
action ipt -j mark --set-mark 3 \
action police index 300 mtu 5000 rate 1kbit burst 90k drop
#
#
# do something on eth0 with these firewall marks
# example use them to send packets to different classes/queue
# give priority to marks 1 then 2 then 3
#
.
.
.
# now the return path to 10.0.0.21 ...
tc qdisc add dev eth1 handle 1:0 root prio
#
# note how exactly the same policer is used ("index 1")
tc filter add dev eth1 parent 1:0 protocol ip prio 1 \
u32 match ip dst 10.0.0.21/32 flowid 1:25 \
action police index 1 rate 1kbit burst 9k pipe
.
.
.
look at the stats with "tc -s filter show parent ffff: dev eth1"
.
A sample would look like:
------------
jroot# tc -s filter show parent ffff: dev eth0
filter protocol ip pref 1 u32
filter protocol ip pref 1 u32 fh 800: ht divisor 1
filter protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1
5
match 0a000015/ffffffff at 12
.
.
action order 2: police 1 action pipe rate 1Kbit burst 9Kb mtu 2Kb
Sent 188832 bytes 2248 pkts (dropped 0, overlimits 2122)
.
.
-------------
^ permalink raw reply
* Re: RE: preparing toshiba_acpi driver release
From: Karol Kozimor @ 2004-01-27 3:12 UTC (permalink / raw)
To: Brown, Len
Cc: Ducrot Bruno, John Belmonte,
acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <BF1FE1855350A0479097B3A0D2A80EE0CC8A54-N2PTB0HCzHJF3Yvz3xaN/VDQ4js95KgL@public.gmane.org>
Thus wrote Brown, Len:
> I was thinking about ergonomics rather than power-savings -- though
> probably brightness control has some power savings benefits too -- maybe
> somebody on the list has numbers for screen power consumption?
Last time I checked it was about 6 W for my 15" display (100% brightness,
power consumption goes down linearly).
What I consider more important, is the ability to switch the LCD on / off
by demand -- unfortunately, DPMS is mostly unsupported on modern machines
and a generic approach (provided it works) could make a difference here.
Once I update the acpi4asus driver, I'll take a look on how those generic
methods to manipulate video work here and see where it gets me.
Best regards,
--
Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* udevinfo query
From: Jon Smirl @ 2004-01-27 3:05 UTC (permalink / raw)
To: linux-hotplug
It would be nice to be able to query for the full path to the node. This would
make it easier to script things. Instead of "udevinfo -r" and "udevinfo -p
/class/dri/card0 -q name", I could just do something like "udevinfo -p
/class/dri/card0 -q fullname" and get back /udev/dri/card0
I tried "udevinfo -p /class/dri/card0 -q name" without udev running. It gives
the error "device not found in database". udevinfo -r returns "/udev/".
Shouldn't these messages be changed to indicate that udev is not mounted and
running?
==Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* Re: [uml-devel] Swapping directly to host swap area?
From: Dan Shearer @ 2004-01-27 3:01 UTC (permalink / raw)
To: William Stearns; +Cc: ML-uml-devel
In-Reply-To: <Pine.LNX.4.44.0401251827030.2766-100000@sparrow>
On Sun, Jan 25, 2004 at 06:34:12PM -0500, William Stearns wrote:
>
> When a VM needs to swap out, is there some way the UML kernel
> could send that sector directly to the host swap area instead of running
> its own swap?
But that would involve making it possible for an ordinary userspace
process (for example, /bin/ls) to affect what the VM is doing on the
host.
Jeff's /dev/anon and ubd=mmap is all about addressing your problem from
the point of view of memory utilisation. See
http://user-mode-linux.sourceforge.net/devanon.html
--
Dan Shearer
dan@shearer.org
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
^ permalink raw reply
* Re: FIX
From: Arnaldo Carvalho de Melo @ 2004-01-27 2:57 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / ?$B5HF#1QL@; +Cc: davem, erik, netdev
In-Reply-To: <20040127.070142.93371828.yoshfuji@linux-ipv6.org>
Em Tue, Jan 27, 2004 at 07:01:42AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ escreveu:
> In article <20040126.123042.104046496.davem@redhat.com> (at Mon, 26 Jan 2004 12:30:42 -0800 (PST)), "David S. Miller" <davem@redhat.com> says:
>
> >
> > Ok, I've figured out the bug. Arnaldo only fixed one of the
> > two incorrect calls to sk_add_node() which should both be
> > __sk_add_node().
>
> Thanks you!
Great! Thanks!
- Arnaldo
^ permalink raw reply
* Re: Squid only on eth1
From: James Turnbull @ 2004-01-27 2:50 UTC (permalink / raw)
To: linux-newbie
In-Reply-To: <4011C8740000069B@mail-bcm02.alestra.net.mx>
> Hi:
>
> I have 2 eth devices in my Linux box, I want that all squid traffic go
throw
> eth1 an not eth0, how do I configure it?
>
If they have seperate IP addresses you can force squid to use a specific IP
address in the squid.conf file. Look at the http_port config option and
specify an IP, i.e. http_port 10.0.0.5:3128
Regards
James
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs
^ permalink raw reply
* Re: [Kernel-janitors] reviewing KJ patches
From: Arnaldo Carvalho de Melo @ 2004-01-27 2:43 UTC (permalink / raw)
To: kernel-janitors
In-Reply-To: <20040126163021.45208acc.rddunlap@osdl.org>
Em Mon, Jan 26, 2004 at 04:30:21PM -0800, Randy.Dunlap escreveu:
>
> It sure would help if someone other than me was reviewing some
> kernel-janitors patches .... :(
>
> Yes, there is an occasional comment, usually about style.
> And those are fine, but patches often affect correctness also,
> and I don't see many comments about those.
Randy, I'm kinda busy lately with our upcoming Conectiva Linux 10 distro,
but I'll do my best to find time to help you, thank you for keeping up so
far!
- Arnaldo
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply
* Synaptics problems with kernel 2.6.x
From: Richard Kuryk @ 2004-01-27 2:42 UTC (permalink / raw)
To: linux-kernel
I have tried compiling two different kernel versions 2.6.1-mm5 and
2.6.2_rc1-love1 and both produce errors like:
Synaptics driver lost sync at byte X
psmouse.c: bad data from KBC - timeout
Synaptics driver resynced.
My machine is a :
Compaq presario 1692 - AMD k6-2 433mhz
ALi Corp. M1533 PCI to ISA Bridge
Output from dmesg:
Intel ISA PCIC probe: not found.
mice: PS/2 mouse device common for all mice
Failed to disable AUX port, but continuing anyway... Is this a SiS?
If AUX port is really absent please use the 'i8042.noaux' option.
serio: i8042 AUX port at 0x60,0x64 irq 12
Synaptics Touchpad, model: 1
Firmware: 4.6
Sensor: 15
new absolute packet format
Touchpad has extended capability bits
-> four buttons
-> multifinger detection
-> palm detection
input: SynPS/2 Synaptics TouchPad on isa0060/serio1
serio: i8042 KBD port at 0x60,0x64 irq 1
input: AT Translated Set 2 keyboard on isa0060/serio0
I have been reading prior messages so I know there are issues with power
management and ACPI and I have tried them on/off it doesn't really
help. I have also tried enabled the HPET Timer but I don't think my
machine has one. So far I have not been able to use X windows without
the mouse jumping every time I try and use the pad. 2.6.1-mm5 produced
a tad better results but still unusable.
I hope I included all the important info, but if you need additional
details please let me know what you need. Please CC me.
Thanks,
Rich
^ permalink raw reply
* Re: p4_clockmod or speedstep_ich | acpi?
From: Marcus Grando @ 2004-01-27 2:41 UTC (permalink / raw)
To: Ducrot Bruno; +Cc: cpufreq
In-Reply-To: <20040124060321.GP25416@poupinou.org>
Hi,
But why my kernel show this messages, if celeron not support speedstep-ich?
cpufreq: P4/Xeon(TM) CPU On-Demand Clock Modulation available
cpufreq: Warning: Pentium 4-M detected. The speedstep-ich or acpi cpufreq
cpufreq: modules offers voltage scaling in addition of frequency
scaling. You
cpufreq: should use either one instead of p4-clockmod, if possible.
Regards
Ducrot Bruno wrote:
> On Sat, Jan 24, 2004 at 01:53:57AM -0200, Marcus Grando wrote:
>
>>Hi,
>>
>>I have a toshiba satellite a10 127, and use p4 clockmod in cpufreq. I
>>look this kernel messages:
>>
>>cpufreq: P4/Xeon(TM) CPU On-Demand Clock Modulation available
>>cpufreq: Warning: Pentium 4-M detected. The speedstep-ich or acpi cpufreq
>>cpufreq: modules offers voltage scaling in addition of frequency
>>scaling. You
>>cpufreq: should use either one instead of p4-clockmod, if possible.
>>
>
>
> ...
>
>>CPU: After generic identify, caps: bfebf9ff 00000000 00000000 00000000
>>CPU: After vendor identify, caps: bfebf9ff 00000000 00000000 00000000
>>CPU: Trace cache: 12K uops, L1 D cache: 8K
>>CPU: L2 cache: 256K
>>CPU: After all inits, caps: bfebf9ff 00000000 00000000 00000080
>>CPU: Intel Mobile Intel(R) Celeron(R) CPU 2.00GHz stepping 09
>
> ^^^^^^^
> A celeron is not speedstep capable.
>
> Cheers,
>
--
Marcus Grando
Grupos Internet S/A
marcus(at)corp.grupos.com.br
^ permalink raw reply
* Re: New NUMA scheduler and hotplug CPU
From: Nick Piggin @ 2004-01-27 2:40 UTC (permalink / raw)
To: habanero; +Cc: Martin J. Bligh, Rusty Russell, linux-kernel
In-Reply-To: <200401262021.45885.habanero@us.ibm.com>
Andrew Theurer wrote:
>On Monday 26 January 2004 18:07, Nick Piggin wrote:
>
>>>>Well OK, this would require a per architecture function to handle
>>>>CPU hotplug. It could possibly just default to arch_init_sched_domains,
>>>>and just completely reinitialise everything which would be the simplest.
>>>>
>>>Call me crazy, but why not let the topology be determined via userspace at
>>>a more appropriate time? When you hotplug, you tell it where in the
>>>scheduler to plug it. Have structures in the scheduler which represent
>>>the nodes-runqueues-cpus topology (in the past I tried a node/rq/cpu
>>>structs with simple pointers), but let the topology be built based on
>>>user's desires thru hotplug.
>>>
>>Well isn't userspace's idea of topology just what the kernel tells it?
>>I'm not sure what it would buy you... but I guess it wouldn't be too
>>much harder than doing it in kernel, just a matter of making the userspace
>>API.
>>
>
>Sort of, the cpus to node is pretty much what the kernel says it is, but the
>cpu to runqueue mapping IMO is not a clear cut thing.
>
>
But userspace still can't know more than the kernel tells it.
Apart from that, the SMT stuff in the sched domains patch means
SMT CPUs need not share runqueues.
^ permalink raw reply
* Re: New NUMA scheduler and hotplug CPU
From: Rusty Russell @ 2004-01-27 2:36 UTC (permalink / raw)
To: Martin J. Bligh; +Cc: Nick Piggin, linux-kernel
In-Reply-To: <31860000.1075159471@flay>
In message <31860000.1075159471@flay> you write:
> > I think it mostly does a good job at making sure to only take
> > online cpus into account. If there are places where it doesn't
> > then it shouldn't be too hard to fix.
>
> It'd make the code a damned sight simpler and cleaner if you dropped
> all that stuff, and updated the structures when you hotplugged a CPU,
> which is really the only sensible way to do it anyway ...
No, actually, it wouldn't. Take it from someone who has actually
looked at the code with an eye to doing this.
Replacing static structures by dynamic ones for an architecture which
doesn't yet exist is NOT a good idea.
> For instance, if I remove cpu X, then bring back a new CPU on another node
> (or in another HT sibling pair) as CPU X, then you'll need to update all
> that stuff anyway. CPUs aren't fixed position in that map - the ordering
> handed out is arbitrary.
Sure, if they were stupid they'd do it this way.
If (when) an architecture has hotpluggable CPUs and NUMA
characteristics, they probably will have fixed CPU *slots*, and number
CPUs based on what slot they are in. Since the slots don't move, all
your fancy dynamic logic will be wasted.
When someone really has dynamic hotplug CPU capability with variable
attributes, *they* can code up the dynamic hierarchy. Because *they*
can actually test it!
> > I guess so, but you'd still need NR_CPUS to be >= that arbitrary
> > number.
>
> Yup ... but you don't have to enumerate all possible positions that way.
> See Linus' arguement re dynamic device numbers and ISCSI disks, etc.
> Same thing applies.
Crap. When all the fixed per-cpu arrays have been removed from the
kernel, come back and talk about instantiation and location of
arbitrary CPUS.
You're way overdesigning: have you been sharing food with the AIX guys?
Cheers!
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
^ permalink raw reply
* Re: Firewall four nics, two separate routes
From: Alexis @ 2004-01-27 2:37 UTC (permalink / raw)
To: netfilter
In-Reply-To: <002f01c3e47a$7a6f3f80$0200000a@heretic>
its too late at night, i drive so many kms today, i cant write.
this is the real message
think lan1 lan2 wan1 wan2
the firewall box, must have NO default route
ip rule add from lan1 lookup table 5
ip rule add from lan2 lookup table 6
ip route add default via wan1 table 5
ip route add default via wan2 table 6
sorry
----- Original Message -----
From: "Alexis" <alexis@attla.net.ar>
To: "netfilter" <netfilter@lists.netfilter.org>
Sent: Monday, January 26, 2004 11:08 PM
Subject: Re: Firewall four nics, two separate routes
> think lan1 lan2 wan1 wan2
>
> the firewall box, must have NO defaul route
>
> ip rule add from lan1 lookup table 5
> ip rule add from lan2 lookup table 6
> ip route add default via wan1 table 5
> ip route add default via wan1 table 6
>
> thats it.
>
>
>
> ----- Original Message -----
> From: "Ryan Johnson" <rjohnson@espgroup.net>
> To: <netfilter@lists.netfilter.org>
> Sent: Monday, January 26, 2004 2:49 PM
> Subject: Firewall four nics, two separate routes
>
>
> Hi all,
>
> I have a firewall with four nics, two external nics with two public ips
and
> two internal nics with private ips (two different networks). What I would
> like to do is force all traffic from each internal network to its
> corresponding external nic. I believe the only solution to this is to use
> iproute2, but I have had to luck. So traffic from internal net1 will be
> routed out external nic1, then the other side, internal net2 will be
routed
> out the external nic2. Internal net1 traffic should never go out external
> nic2 and internal net2 traffic should never go out external nic1.
>
>
> Thank you in advance,
> Ryan
>
> Ryan Johnson
> Security Architect
> ESP Group
>
>
>
>
>
>
^ permalink raw reply
* C99 doesn't allow local scope variables?
From: tabris @ 2004-01-27 2:30 UTC (permalink / raw)
To: linux-c-programming
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
simple C program
#include <stdlib.h>
#include <stdio.h>
int main(void)
{
for (int i=0; i < 2; i++)
printf("crap\n");
};
[tabris@tabriel tmp]$ gcc test.c -o test
test.c: In function `main':
test.c:6: error: `for' loop initial declaration used outside C99 mode
What does that mean, and why am I not allowed to make a local scope variable
for a for{;;} loop?
works fine if i declare the variable outside the loop. But I swear I used to
do this with gcc 2.95.
- --
tabris
- -
Body by Nautilus, Brain by Mattel.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQFAFc1J1U5ZaPMbKQcRAiJyAJ4namXjJa9zd6Y/VGbR+Y5pyHVjUwCcCy4s
dW251Zxh2o3I97eabiisOMg=
=21yl
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: Linux v2.6.2-rc2
From: Clemens Schwaighofer @ 2004-01-27 2:25 UTC (permalink / raw)
To: Linus Torvalds, Linux Kernel ML
In-Reply-To: <Pine.LNX.4.58.0401251844440.32583@home.osdl.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Linus Torvalds wrote:
| It's being uploaded right now, and the BK trees should already
| be uptodate.
|
| There's a x86-64 update and IRDA updates here, and a number of USB storage
| fixes. The rest is pretty small. Full changelog from -rc1 appended.
| Tom Rini:
| o Elvis^H^H^H^H^HPaul has left the building
so, he left with the "I can enter The Plug & Play Setup" ;)
bad thing:
* Device Drivers >> Plug & Play Setup is no longer accessible [was in -rc1]
good thing:
my | \ on my japanese 106 key PS/2 keyboard works... without loading my
setkeys file. magic? santa?
- --
Clemens Schwaighofer - IT Engineer & System Administration
==========================================================
Tequila Japan, 6-17-2 Ginza Chuo-ku, Tokyo 104-8167, JAPAN
Tel: +81-(0)3-3545-7703 Fax: +81-(0)3-3545-7343
http://www.tequila.jp
==========================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFAFcwYjBz/yQjBxz8RAm90AKDkwcIHaydiP2ZWMQqZZ98Uf9rI/gCgqQxr
eD6/9RcY9fUJwVIx4X20Tyw=
=jYIq
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: Squid only on eth1
From: Juan Facundo Suárez @ 2004-01-27 2:23 UTC (permalink / raw)
To: linux-newbie list
In-Reply-To: <4011C8740000069B@mail-bcm02.alestra.net.mx>
i don't remember exactly how, but, i know that you can setup squid to
"listen" on specifics ips/ip-ranges/subnets. Many times i used webmin to
setup squid, if you need to set it up quick, it is a good choice.
have luck !
--
Facundo Suárez
Neuquén - Argentina
FDSoft
mail y jabber: faco@fdsoft.com.ar
facundo.suarez@ensi.com.ar
----- Original Message -----
From: <rgomez@bancomer.com>
To: "linux-newbie" <linux-newbie@vger.kernel.org>
Sent: Monday, January 26, 2004 3:01 PM
Subject: Squid only on eth1
| Hi:
|
| I have 2 eth devices in my Linux box, I want that all squid traffic go
throw
| eth1 an not eth0, how do I configure it?
|
| tks for your time...
|
| -
| To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs
|
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs
^ permalink raw reply
* Re: New NUMA scheduler and hotplug CPU
From: Andrew Theurer @ 2004-01-27 2:21 UTC (permalink / raw)
To: Nick Piggin; +Cc: Martin J. Bligh, Rusty Russell, linux-kernel
In-Reply-To: <4015ABA8.3090202@cyberone.com.au>
On Monday 26 January 2004 18:07, Nick Piggin wrote:
> >>Well OK, this would require a per architecture function to handle
> >>CPU hotplug. It could possibly just default to arch_init_sched_domains,
> >>and just completely reinitialise everything which would be the simplest.
> >
> >Call me crazy, but why not let the topology be determined via userspace at
> > a more appropriate time? When you hotplug, you tell it where in the
> > scheduler to plug it. Have structures in the scheduler which represent
> > the nodes-runqueues-cpus topology (in the past I tried a node/rq/cpu
> > structs with simple pointers), but let the topology be built based on
> > user's desires thru hotplug.
>
> Well isn't userspace's idea of topology just what the kernel tells it?
> I'm not sure what it would buy you... but I guess it wouldn't be too
> much harder than doing it in kernel, just a matter of making the userspace
> API.
Sort of, the cpus to node is pretty much what the kernel says it is, but the
cpu to runqueue mapping IMO is not a clear cut thing.
^ permalink raw reply
* Re: New NUMA scheduler and hotplug CPU
From: Andrew Theurer @ 2004-01-27 2:19 UTC (permalink / raw)
To: Martin J. Bligh, Nick Piggin; +Cc: Rusty Russell, linux-kernel
In-Reply-To: <35060000.1075162177@flay>
On Monday 26 January 2004 18:09, Martin J. Bligh wrote:
> > For example, you boot on just the boot cpu, which by default is in the
> > first node on the first runqueue. All other cpus, whether being "booted"
> > for the for the first time or hotplugged (maybe now there's really no
> > difference), the hotplugging tells where the cpu should be, in what node
> > and what runqueue. HT cpus work even better, because you can hotplug
> > siblings, once at a time if you wanted, to the same runqueue. Or you
> > have cpus sharing a die, same thing, lots of choices here. This removes
> > any per-arch updates to the kernel for things like scheduler topology,
> > and lets them go somewhere else more easily changes, like userspace.
>
> Ummm ... but *none* of that is dictated as policy stuff - it's all just
> the hardware layout of the machine. You cannot "decide" as the sysadmin
> which node a CPU is in, or which HT sibling it has. It's just there ;-)
> The only thing you could possibly dictate is the CPU number you want
> assigned to the new CPU, which frankly, I think is pointless - they're
> arbitrary tags, and always have been.
How many cpus share a runqueue IMO could be a policy thing. Some HT cpus may
be better sharing a runqueue where others (lots and lots of siblings in one
core) may not.
^ permalink raw reply
* udev dri directory rule
From: Jon Smirl @ 2004-01-27 2:16 UTC (permalink / raw)
To: linux-hotplug
Would this line:
KERNEL="card*", NAME="dri/card%n"
be better written as:
KERNEL="card*", NAME="dri/%k"
I noticed everything else is using %k
==Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ 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.