Re: Information about MMU
On Wed, Feb 06, 2008 at 10:31:05AM +0530, Pravin Nanaware wrote: > Hi, > > Can somebody point me where could I get the MMU(Memory management Unit) > details ? >From system programming manuals of the processor you are interested in, and in general, from any half-decent computer architecture book written after about 1980. > Regards, > Pravin > > -**Nihilent*** > " *** All information contained in this communication is confidential, .. Do make sure that in future emails to this list there is no longer any of those stupid boilerplate texts that are of dubious in legal status even in USA, and entirely ineffective in most other parts of the world. /Matti Aarnio -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Information about MMU
On Wed, Feb 06, 2008 at 10:31:05AM +0530, Pravin Nanaware wrote: Hi, Can somebody point me where could I get the MMU(Memory management Unit) details ? From system programming manuals of the processor you are interested in, and in general, from any half-decent computer architecture book written after about 1980. Regards, Pravin -**Nihilent*** *** All information contained in this communication is confidential, .. Do make sure that in future emails to this list there is no longer any of those stupid boilerplate texts that are of dubious in legal status even in USA, and entirely ineffective in most other parts of the world. /Matti Aarnio -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sending IOCTLs from 32-bit userland to 64-bit Kernel module
On Tue, Jan 29, 2008 at 02:13:26PM +0200, Yoav Artzi wrote:
> Hi,
>
>
> I have a 32-bit user land application which sends an IOCTL to a 64-bit
> Kernel module. I have a few different cmd codes that I can send through the
> IOCTL. For some reason I seem to always get the same IOCTL cmd from user
> land, no matter what the ioctl() call is given. This cmd code that I get
> has some bytes (W/R and the module code) that are OK, but the rest is just
> garbage or zeros. This was originally a 32-bit system, and we are no
> converting the Kernel module to 64-bit, so maybe there's something special
> for 32-64 communication that miss.
In x86_64 kernel there is an adaptation layer that translates 32-bit ioctl:s
to kernel internal 64-bit ones, when absolutely necessary.
If you do not need to pass pointers in your ioctl(), then typedef:in passed
parameters with explicite size may save you from lots of trouble:
struct cpioctl {
long var; /* definite trouble 32-bit vs. 64-bit */
uint32_t var2; /* no troubles... */
uint64_t var3;
};
After that, the only issue is that 32-bit user space ioctl() passes
a pointer that is valid in 32-bit space only, bit that is handled by
the common layer without need to make specific adaptation routine.
.. however if the structure has pointer to elsewere in memory, then
things get complicated really fast.
> I am working on Linux Kernel v2.6.18.
> Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Sending IOCTLs from 32-bit userland to 64-bit Kernel module
On Tue, Jan 29, 2008 at 02:13:26PM +0200, Yoav Artzi wrote:
Hi,
I have a 32-bit user land application which sends an IOCTL to a 64-bit
Kernel module. I have a few different cmd codes that I can send through the
IOCTL. For some reason I seem to always get the same IOCTL cmd from user
land, no matter what the ioctl() call is given. This cmd code that I get
has some bytes (W/R and the module code) that are OK, but the rest is just
garbage or zeros. This was originally a 32-bit system, and we are no
converting the Kernel module to 64-bit, so maybe there's something special
for 32-64 communication that miss.
In x86_64 kernel there is an adaptation layer that translates 32-bit ioctl:s
to kernel internal 64-bit ones, when absolutely necessary.
If you do not need to pass pointers in your ioctl(), then typedef:in passed
parameters with explicite size may save you from lots of trouble:
struct cpioctl {
long var; /* definite trouble 32-bit vs. 64-bit */
uint32_t var2; /* no troubles... */
uint64_t var3;
};
After that, the only issue is that 32-bit user space ioctl() passes
a pointer that is valid in 32-bit space only, bit that is handled by
the common layer without need to make specific adaptation routine.
.. however if the structure has pointer to elsewere in memory, then
things get complicated really fast.
I am working on Linux Kernel v2.6.18.
Thanks
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: NIC as RS232
On Tue, Jan 08, 2008 at 08:48:35AM +0200, Thanasis wrote: > Is there a kernel driver that would make a NIC's port work as a RS232 > port, using the serial cables that are RJ45 on one side and DB9 or DB25 > on the other? Maybe null modem cables of that type ? Or for example > those used by cisco as console port cables? > > (or may be I'm dreaming ;-) With a certain e.g. Freescale embedded communication processors that could be possible, as those have hardware that can do serial communication in many different bit patterns, and not being limited only on ethernets. However even they talk parallel MII protocol to Ethernet PHY, which then serializes the bitstream for transmit. Speeds are standard 10 and 100 Mbit/s, and electrical signals depend on wiring standard, probably isolated differential signals on twisted pairs. I don't think you can use any ethernet phy hardware for anything but ethernet frames. Even when you send bytes over MII, they are still just a bitstream needing MAC level processing to find correct alignments. You can, of course, talk ethernet protocol to remote serial port servers, but these days those systems talk TCP, which makes application programming all that much easier. Once upon a time I was talking to a group of telco engineers and said that "These Telco SDH ports are one of the reasons why bit communication is expensive. In the future things will go to optical ethernet interface, which is either carried over DWM lambdas for long hauls, or just dark fibers." Now it looks like I was right.. /Matti Aarnio -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NIC as RS232
On Tue, Jan 08, 2008 at 08:48:35AM +0200, Thanasis wrote: Is there a kernel driver that would make a NIC's port work as a RS232 port, using the serial cables that are RJ45 on one side and DB9 or DB25 on the other? Maybe null modem cables of that type ? Or for example those used by cisco as console port cables? (or may be I'm dreaming ;-) With a certain e.g. Freescale embedded communication processors that could be possible, as those have hardware that can do serial communication in many different bit patterns, and not being limited only on ethernets. However even they talk parallel MII protocol to Ethernet PHY, which then serializes the bitstream for transmit. Speeds are standard 10 and 100 Mbit/s, and electrical signals depend on wiring standard, probably isolated differential signals on twisted pairs. I don't think you can use any ethernet phy hardware for anything but ethernet frames. Even when you send bytes over MII, they are still just a bitstream needing MAC level processing to find correct alignments. You can, of course, talk ethernet protocol to remote serial port servers, but these days those systems talk TCP, which makes application programming all that much easier. Once upon a time I was talking to a group of telco engineers and said that These Telco SDH ports are one of the reasons why bit communication is expensive. In the future things will go to optical ethernet interface, which is either carried over DWM lambdas for long hauls, or just dark fibers. Now it looks like I was right.. /Matti Aarnio -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: More verizon problems
On Sun, Dec 23, 2007 at 02:30:50PM -0500, Gene Heskett wrote: > Date: Sun, 23 Dec 2007 14:30:50 -0500 > From: Gene Heskett <[EMAIL PROTECTED]> > Subject: More verizon problems > To: linux-kernel@vger.kernel.org > Content-type: text/plain; charset=iso-8859-1 > > Resend, with more odd data from fetchmail.log appended. Looking at that log.. > PS: From my fetchmail.log since I turned on the -v -v options an hour ago: > -- > fetchmail: 6.3.6 querying pop.gmail.com (protocol POP3) at Sun 23 Dec 2007 > 02:20:56 PM EST: poll started > fetchmail: Trying to connect to 209.85.133.109/995...connected. > fetchmail: Issuer Organization: Equifax > fetchmail: Unknown Issuer CommonName > fetchmail: Server CommonName: pop.gmail.com > fetchmail: pop.gmail.com key fingerprint: > 44:A8:E9:2C:FB:A9:7E:6D:F9:DB:F3:62:B2:9E:F1:A9 This looks like correct and genuine gmail service. > fetchmail: POP3< +OK Gpop ready for requests from 72.65.67.83 > b11pf2510187ana.0 > fetchmail: POP3> CAPA > fetchmail: POP3< +OK Capability list follows > fetchmail: POP3< USER > fetchmail: POP3< RESP-CODES > fetchmail: POP3< EXPIRE 0 > fetchmail: POP3< LOGIN-DELAY 300 > fetchmail: POP3< X-GOOGLE-VERHOEVEN > fetchmail: POP3< UIDL > fetchmail: POP3< . > fetchmail: POP3> USER gene.heskett > fetchmail: POP3< +OK send PASS > fetchmail: POP3> PASS * > fetchmail: POP3< +OK Welcome. > fetchmail: selecting or re-polling default folder > fetchmail: POP3> STAT > fetchmail: POP3< +OK 0 0 > fetchmail: No mail for gene.heskett at pop.gmail.com > fetchmail: POP3> QUIT > fetchmail: POP3< +OK Farewell. > fetchmail: 6.3.6 querying pop.gmail.com (protocol POP3) at Sun 23 Dec 2007 > 02:20:57 PM EST: poll completed > fetchmail: not swapping UID lists, no UIDs seen this query > fetchmail: Query status=1 (NOMAIL) > --- > > about 30 of those, there is never any mail for me at gmail. > > Has my subscription info gotten contaminated somehow? re-forward at gmail to verizon ? > sorry for the noise folks, but this is a classic case of me and road rage. I try to avoid that. Gives others an illusion of me being smarter than I am in reality... :-) > -- > Cheers, Gene /Matti Aarnio -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Morer verizon problems
On Sun, Dec 23, 2007 at 02:10:39PM -0500, Gene Heskett wrote: > Date: Sun, 23 Dec 2007 14:10:39 -0500 > From: Gene Heskett <[EMAIL PROTECTED]> > Subject: Morer verizon problems > To: linux-kernel@vger.kernel.org > > Just for a heads up, for about the last 8 hours, verizon, my ISP, has been > inserting themselves into the path between my gmail account and my local > fetchmail of this email subcription at pop.gmail.com. Gene, The Received: header data are telling something else. You read them from bottom-most up -- new one is always inserted on top of the existing headers. Received: by nz-out-0506.google.com with SMTP id x7so90741nzc.3 for <[EMAIL PROTECTED]>; Thu, 20 Dec 2007 18:08:08 -0800 (PST) It does look like you have a forwarding setting at gmail to your verizononline.net service. If you had chosen to pull email out of gmail, then perhaps you would not have had any verizon problems. While conspiracy mongering has its fun, I do think that you are in fact causing this all to yourself by trying to push the message flood to Verizon.. For what it matters - LKML has 3 subscribers on @verizon.net addresses. I do run my own mail-server, and my Linux mailboxes are at present over 1 GB/y. Gmail mailbox would be a bit larger - underlying database granularity is around 128 or 256 kB, as I recall having read about google technology. > Worse yet they are bouncing the messages in a way that makes it look as if I > sent them when they in fact originated at vger.kernel.org. Somehow they have > convinced themselves that any mailing list this busy must be spam and is to > be > bounced. Either that or they, verizon, since they sleep with M$, have taken > a > large under the table payment to screw with linux in any way they can. It > bears investigating. > > I called just now and screamed bloody murder at tech support, and in about 15 > minutes I started getting the list again, BUT they are still in the path > between vger and my fetchmail daemon as shown below. Yes, I would fetch directly from gmail, if I were you... /Matti Aarnio -- one of > Or at least that is how I am interpreting the incoming headers, which now > look > like this by the time they hit my inbox but with my SA headers clipped: > --- > Received: from incoming.verizon.net [206.46.232.10] > by coyote.coyote.den with POP3 (fetchmail-6.3.6) > for <[EMAIL PROTECTED]> (single-drop); Thu, 20 Dec 2007 21:10:08 > -0500 (EST) > Received: from mailbag1.bizmailsrvcs.net ([172.18.12.131]) > by vms051.mailsrvcs.net > (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) > with ESMTP id <[EMAIL PROTECTED]> for > [EMAIL PROTECTED]; Thu, 20 Dec 2007 20:08:11 -0600 (CST) > Received: from [64.233.162.238] (port= helo=nz-out-0506.google.com) > by mailbag1.bizmailsrvcs.net with esmtp (Exim 4.68) > (envelope-from <[EMAIL PROTECTED]>) > id 1J5XG9-00052G-Dufor [EMAIL PROTECTED]; Thu, > 20 Dec 2007 20:05:09 -0600 > Received: by nz-out-0506.google.com with SMTP id x7so90741nzc.3 for > <[EMAIL PROTECTED]>; Thu, 20 Dec 2007 18:08:08 -0800 (PST) > Received: by 10.142.132.2 with SMTP id f2mr436687wfd.221.1198202887677; Thu, > 20 Dec 2007 18:08:07 -0800 (PST) > Received: by 10.142.222.3 with SMTP id u3cs177296wfg; Thu, > 20 Dec 2007 18:08:07 -0800 (PST) > Received: by 10.100.202.9 with SMTP id z9mr1420295anf.42.1198202883749; Thu, > 20 Dec 2007 18:08:03 -0800 (PST) > Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) > by mx.google.com with ESMTP id q26si917844ele.6.2007.12.20.18.07.38; Thu, > 20 Dec 2007 18:08:03 -0800 (PST) > Received: ([EMAIL PROTECTED]) by vger.kernel.org via listexpand id > S1759056AbXLUCHP (ORCPT + 49 others); Thu, > 20 Dec 2007 21:07:15 -0500 > Received: ([EMAIL PROTECTED]) by vger.kernel.org id S1754373AbXLUB7V > (ORCPT ); Thu, 20 Dec 2007 20:59:21 -0500 > Received: from smtp.polymtl.ca > ([132.207.4.11]:53375 "EHLO smtp.polymtl.ca" rhost-flags-OK-OK-OK-OK) > by vger.kernel.org with ESMTP id S1761264AbXLUB7M > (ORCPT ); Thu, 20 Dec 2007 20:59:12 > -0500 > Received: from dijkstra.casi.polymtl.ca > (dijkstra.casi.polymtl.ca [132.207.72.10]) by smtp.polymtl.ca > (8.13.8/8.13.8) > with ESMTP id lBL1vVHB024689 > (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, > 20 Dec 2007 20:57:32 -0500 > Received: from compudj by dijkstra.casi.polymtl.ca with local (Exim 4.63) > (envelope-from <[EMAIL PROTECTED]>) id 1J5X8g-00040X-Gt; Thu, > 20 Dec 2007 20:57:26 -0500 > Date: Thu, 20 Dec 2007 20:54:50 -0500 > From: Mathieu Desnoyers <[EMAIL PROTECTED]> > Subject: [patch 12/24] Immediate Values -
Re: Morer verizon problems
On Sun, Dec 23, 2007 at 02:10:39PM -0500, Gene Heskett wrote: Date: Sun, 23 Dec 2007 14:10:39 -0500 From: Gene Heskett [EMAIL PROTECTED] Subject: Morer verizon problems To: linux-kernel@vger.kernel.org Just for a heads up, for about the last 8 hours, verizon, my ISP, has been inserting themselves into the path between my gmail account and my local fetchmail of this email subcription at pop.gmail.com. Gene, The Received: header data are telling something else. You read them from bottom-most up -- new one is always inserted on top of the existing headers. Received: by nz-out-0506.google.com with SMTP id x7so90741nzc.3 for [EMAIL PROTECTED]; Thu, 20 Dec 2007 18:08:08 -0800 (PST) It does look like you have a forwarding setting at gmail to your verizononline.net service. If you had chosen to pull email out of gmail, then perhaps you would not have had any verizon problems. While conspiracy mongering has its fun, I do think that you are in fact causing this all to yourself by trying to push the message flood to Verizon.. For what it matters - LKML has 3 subscribers on @verizon.net addresses. I do run my own mail-server, and my Linux mailboxes are at present over 1 GB/y. Gmail mailbox would be a bit larger - underlying database granularity is around 128 or 256 kB, as I recall having read about google technology. Worse yet they are bouncing the messages in a way that makes it look as if I sent them when they in fact originated at vger.kernel.org. Somehow they have convinced themselves that any mailing list this busy must be spam and is to be bounced. Either that or they, verizon, since they sleep with M$, have taken a large under the table payment to screw with linux in any way they can. It bears investigating. I called just now and screamed bloody murder at tech support, and in about 15 minutes I started getting the list again, BUT they are still in the path between vger and my fetchmail daemon as shown below. Yes, I would fetch directly from gmail, if I were you... /Matti Aarnio -- one of postmaster at vger.kernel.org Or at least that is how I am interpreting the incoming headers, which now look like this by the time they hit my inbox but with my SA headers clipped: --- Received: from incoming.verizon.net [206.46.232.10] by coyote.coyote.den with POP3 (fetchmail-6.3.6) for [EMAIL PROTECTED] (single-drop); Thu, 20 Dec 2007 21:10:08 -0500 (EST) Received: from mailbag1.bizmailsrvcs.net ([172.18.12.131]) by vms051.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTP id [EMAIL PROTECTED] for [EMAIL PROTECTED]; Thu, 20 Dec 2007 20:08:11 -0600 (CST) Received: from [64.233.162.238] (port= helo=nz-out-0506.google.com) by mailbag1.bizmailsrvcs.net with esmtp (Exim 4.68) (envelope-from [EMAIL PROTECTED]) id 1J5XG9-00052G-Dufor [EMAIL PROTECTED]; Thu, 20 Dec 2007 20:05:09 -0600 Received: by nz-out-0506.google.com with SMTP id x7so90741nzc.3 for [EMAIL PROTECTED]; Thu, 20 Dec 2007 18:08:08 -0800 (PST) Received: by 10.142.132.2 with SMTP id f2mr436687wfd.221.1198202887677; Thu, 20 Dec 2007 18:08:07 -0800 (PST) Received: by 10.142.222.3 with SMTP id u3cs177296wfg; Thu, 20 Dec 2007 18:08:07 -0800 (PST) Received: by 10.100.202.9 with SMTP id z9mr1420295anf.42.1198202883749; Thu, 20 Dec 2007 18:08:03 -0800 (PST) Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by mx.google.com with ESMTP id q26si917844ele.6.2007.12.20.18.07.38; Thu, 20 Dec 2007 18:08:03 -0800 (PST) Received: ([EMAIL PROTECTED]) by vger.kernel.org via listexpand id S1759056AbXLUCHP (ORCPT rfc822;[EMAIL PROTECTED] + 49 others); Thu, 20 Dec 2007 21:07:15 -0500 Received: ([EMAIL PROTECTED]) by vger.kernel.org id S1754373AbXLUB7V (ORCPT rfc822;linux-kernel-outgoing); Thu, 20 Dec 2007 20:59:21 -0500 Received: from smtp.polymtl.ca ([132.207.4.11]:53375 EHLO smtp.polymtl.ca rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1761264AbXLUB7M (ORCPT rfc822;linux-kernel@vger.kernel.org); Thu, 20 Dec 2007 20:59:12 -0500 Received: from dijkstra.casi.polymtl.ca (dijkstra.casi.polymtl.ca [132.207.72.10]) by smtp.polymtl.ca (8.13.8/8.13.8) with ESMTP id lBL1vVHB024689 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 20 Dec 2007 20:57:32 -0500 Received: from compudj by dijkstra.casi.polymtl.ca with local (Exim 4.63) (envelope-from [EMAIL PROTECTED]) id 1J5X8g-00040X-Gt; Thu, 20 Dec 2007 20:57:26 -0500 Date: Thu, 20 Dec 2007 20:54:50 -0500 From: Mathieu Desnoyers [EMAIL PROTECTED] Subject: [patch 12/24] Immediate Values - Architecture Independent Code X-Originating-IP: [172.18.12.131] Sender: [EMAIL PROTECTED] To: [EMAIL PROTECTED], Ingo Molnar [EMAIL PROTECTED], linux-kernel@vger.kernel.org Cc: Mathieu Desnoyers [EMAIL PROTECTED], Rusty Russell
Re: More verizon problems
On Sun, Dec 23, 2007 at 02:30:50PM -0500, Gene Heskett wrote: Date: Sun, 23 Dec 2007 14:30:50 -0500 From: Gene Heskett [EMAIL PROTECTED] Subject: More verizon problems To: linux-kernel@vger.kernel.org Content-type: text/plain; charset=iso-8859-1 Resend, with more odd data from fetchmail.log appended. Looking at that log.. PS: From my fetchmail.log since I turned on the -v -v options an hour ago: -- fetchmail: 6.3.6 querying pop.gmail.com (protocol POP3) at Sun 23 Dec 2007 02:20:56 PM EST: poll started fetchmail: Trying to connect to 209.85.133.109/995...connected. fetchmail: Issuer Organization: Equifax fetchmail: Unknown Issuer CommonName fetchmail: Server CommonName: pop.gmail.com fetchmail: pop.gmail.com key fingerprint: 44:A8:E9:2C:FB:A9:7E:6D:F9:DB:F3:62:B2:9E:F1:A9 This looks like correct and genuine gmail service. fetchmail: POP3 +OK Gpop ready for requests from 72.65.67.83 b11pf2510187ana.0 fetchmail: POP3 CAPA fetchmail: POP3 +OK Capability list follows fetchmail: POP3 USER fetchmail: POP3 RESP-CODES fetchmail: POP3 EXPIRE 0 fetchmail: POP3 LOGIN-DELAY 300 fetchmail: POP3 X-GOOGLE-VERHOEVEN fetchmail: POP3 UIDL fetchmail: POP3 . fetchmail: POP3 USER gene.heskett fetchmail: POP3 +OK send PASS fetchmail: POP3 PASS * fetchmail: POP3 +OK Welcome. fetchmail: selecting or re-polling default folder fetchmail: POP3 STAT fetchmail: POP3 +OK 0 0 fetchmail: No mail for gene.heskett at pop.gmail.com fetchmail: POP3 QUIT fetchmail: POP3 +OK Farewell. fetchmail: 6.3.6 querying pop.gmail.com (protocol POP3) at Sun 23 Dec 2007 02:20:57 PM EST: poll completed fetchmail: not swapping UID lists, no UIDs seen this query fetchmail: Query status=1 (NOMAIL) --- about 30 of those, there is never any mail for me at gmail. Has my subscription info gotten contaminated somehow? re-forward at gmail to verizon ? sorry for the noise folks, but this is a classic case of me and road rage. I try to avoid that. Gives others an illusion of me being smarter than I am in reality... :-) -- Cheers, Gene /Matti Aarnio -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Does vger.kernel.org automatically drop spams?
On Wed, Dec 05, 2007 at 10:45:15PM +0900, Tetsuo Handa wrote: > Hello. > > Matti Aarnio wrote: > > > Does vger.kernel.org have spam filter and automatically drop spams? > > > > Yes. Yes. And even worse: SILENTLY drop it. The reason was: > > > > global taboo header: m!OJFS! > > > > I don't recall why that was declared taboo, but it apparently bites > > on References: headers.. Entirely unintentional, I assure you. > > I see. Thank you. > > Well, may be my address was registered as a spammer. No. > What should I do to post my message? Wait a bit. > Should I use different From: address? > Should I stop sending to multiple lists? No, no. > > We (the postmasters) can approve your messages for posting, but it > > will take a few hours that I get off work, and have time to do it. > > (I need to do some additional setups, all those lists are not > > in my existing majordomo password database..) > > Should I wait for your approval? Please do, unless DaveM can do it quicker than me.. > Regards. /Matti Aarnio -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Does vger.kernel.org automatically drop spams?
On Wed, Dec 05, 2007 at 10:25:52PM +0900, Tetsuo Handa wrote: > Hello. > > I posted a message to [EMAIL PROTECTED], > [EMAIL PROTECTED] and [EMAIL PROTECTED] > 11 hours ago, but it seems to me my message has not delivered yet. > Usually it won't take 10 minutes to be delivered. > So, I'm thinking my messages was dropped. > > Does vger.kernel.org have spam filter and automatically drop spams? Yes. Yes. And even worse: SILENTLY drop it. The reason was: global taboo header: m!OJFS! I don't recall why that was declared taboo, but it apparently bites on References: headers.. Entirely unintentional, I assure you. We (the postmasters) can approve your messages for posting, but it will take a few hours that I get off work, and have time to do it. (I need to do some additional setups, all those lists are not in my existing majordomo password database..) > Regards. /Matti Aarnio -- one of <[EMAIL PROTECTED]> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Does vger.kernel.org automatically drop spams?
On Wed, Dec 05, 2007 at 10:25:52PM +0900, Tetsuo Handa wrote: Hello. I posted a message to [EMAIL PROTECTED], [EMAIL PROTECTED] and [EMAIL PROTECTED] 11 hours ago, but it seems to me my message has not delivered yet. Usually it won't take 10 minutes to be delivered. So, I'm thinking my messages was dropped. Does vger.kernel.org have spam filter and automatically drop spams? Yes. Yes. And even worse: SILENTLY drop it. The reason was: global taboo header: m!OJFS! I don't recall why that was declared taboo, but it apparently bites on References: headers.. Entirely unintentional, I assure you. We (the postmasters) can approve your messages for posting, but it will take a few hours that I get off work, and have time to do it. (I need to do some additional setups, all those lists are not in my existing majordomo password database..) Regards. /Matti Aarnio -- one of [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Does vger.kernel.org automatically drop spams?
On Wed, Dec 05, 2007 at 10:45:15PM +0900, Tetsuo Handa wrote: Hello. Matti Aarnio wrote: Does vger.kernel.org have spam filter and automatically drop spams? Yes. Yes. And even worse: SILENTLY drop it. The reason was: global taboo header: m!OJFS! I don't recall why that was declared taboo, but it apparently bites on References: headers.. Entirely unintentional, I assure you. I see. Thank you. Well, may be my address was registered as a spammer. No. What should I do to post my message? Wait a bit. Should I use different From: address? Should I stop sending to multiple lists? No, no. We (the postmasters) can approve your messages for posting, but it will take a few hours that I get off work, and have time to do it. (I need to do some additional setups, all those lists are not in my existing majordomo password database..) Should I wait for your approval? Please do, unless DaveM can do it quicker than me.. Regards. /Matti Aarnio -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Relax permissions for reading hard drive serial number?
On Thu, Nov 29, 2007 at 07:46:19AM -0800, Dan Kegel wrote:
> On Nov 29, 2007 7:37 AM, Xavier Bestel <[EMAIL PROTECTED]> wrote:
> > > One sticking point is that apps like Photoshop and probably
> > > Punkbuster want to retrieve the hard drive's serial number
> >
> > So they can't be installed on a network drive ?
>
> I think Adobe supports that, though perhaps not with the
> retail version. Big companies with network drives are
> probably an important revenue source for them.
>
> I haven't looked closely at what happens when you try installing
> onto network drives. If you are really interested, it's pretty easy to
> try yourself; just run the app under wine with
> WINEDEBUG=+cdrom,+disk and look in the log for calls like
> CreateFile(".\\PhysicalDrive0", ...).
> There's some chance the code always checks drive 0 instead
> of the drive you're installing onto.
This lack of having stable(*) unique system identifier available to
applications is one of the small details that make node locked
commercial software delivery challenging thing in UNIX environments..
*) "stable" as both stable data, and stable API to get it.
There is always the way of delivering such one with a physical serial
number device, but for purely selfish reasons I do compare _same_
software delivered for Windows and for Linux -- the Windows version
is available for free in a certain very usefull subset, while Linux
version costs a few thousand dollars, and is still less functional
than the free Windows subset.
One UNIX software licensor has resolved this in a way that prevents
successfull restore of the license file - possibly by storing stat(2)
st_ino data in the license data. Forcing the license file to have
any specific i-node number on UNIX filesystems is - a bit difficult.
Simple-ish solution here is, of course, to run part of the software
via a suid-root helper binary, which then accesses system serial
number informations - and does some other usefull and necessary
functionality, like find and open external USB device(s) that the
software suite drives - by passing opened device handle to the caller
program (**). Software installation would want to run in super-user
mode to create directory for software data ( /opt/XYZ/ ) and to
install the helper binaries, of course.
**) I am thinking of hardware programmer tools which highly likely
do not have drivers per se in Linux kernel, nor are they easy to
configure for hotplug to be assigned (device chowned) to any specific
user. Such suid-root tool would let non-privileged user to access
the device.
One fairly stable thing in UNIX systems are network card MAC addresses.
That data is available without super-user privileges, and even the
API to retrieve it has been stable for about whole time that Linux
has had network services. One can reset the device MAC address, so
it isn't as stable as license lockers would want to -- nor difficult
to fake. It has one nasty feature, tough: If you have same MAC on
multiple machines within same LAN, your network will all the sudden
work rather poorly.
Nevertheless it is *unique* data that is available to anybody wanting
to pick it up, thus I do think that it is hypocritical of making
all manners of other identifiers unavailable.
Now that I mentioned this, most paranoid of you would of course
want to make MAC address to be "privileged data", and thus change
existing API. Before you do that, check how IPv6 does its address
assignments, and what would it mean to system if programs can't
find out its own inbound nor outbound IPv6 addresses on connected
sockets ? ( -> getsockname() )
> - Dan
/Matti Aarnio
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Relax permissions for reading hard drive serial number?
On Thu, Nov 29, 2007 at 10:07:46PM +0100, Bartlomiej Zolnierkiewicz wrote:
> > There are people who, for privacy reasons, really don't like that "unique"
> > unchangeable serial numbers can be retrieved by untrusted users.
> >
> > You should probably chmod the file on the users system, if he is fine with
> > that, but not change the kernel default.
>
> Seconded.
>
> While on it, how's about exporting model/firmware/serial through
> sysfs so /proc/ide/hd*/identify don't have to be used?
Nice, except that while my home workstation running 2.6.23 kernel
does have 4 SATA disks in it, plus a compact flash memory card on
PATA (boot device, while SATA-disks are JBOD in SW RAID), it has
_no_ /sys/bus/ide/, nor /proc/ide/
All devices are under /sys/bus/scsi/
Simplest way for me to pick this data is to use "hdparm -I /dev/sdX"
command. Which of course must be run as root. All it does is to open
named device, and issue one ioctl().
That ioctl() can be embedded into a suid-root helper program, or it
can even (in case of Wine) be run separately to write a text file
storing these identifier data on some Wine config file, which the
"read from physical device X" then does receive.
In my case I don't want to report any of the hard-drive serial numbers,
but rather my boot-device - a flash drive. Hard-drives do break at
some point in time, a flash drive in read-only mode does last considerably
longer.
> [PATCH] ide: add /sys/bus/ide/devices/*/{model,firmware,serial} sysfs entries
...
/Matti Aarnio
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Relax permissions for reading hard drive serial number?
On Thu, Nov 29, 2007 at 10:07:46PM +0100, Bartlomiej Zolnierkiewicz wrote:
There are people who, for privacy reasons, really don't like that unique
unchangeable serial numbers can be retrieved by untrusted users.
You should probably chmod the file on the users system, if he is fine with
that, but not change the kernel default.
Seconded.
While on it, how's about exporting model/firmware/serial through
sysfs so /proc/ide/hd*/identify don't have to be used?
Nice, except that while my home workstation running 2.6.23 kernel
does have 4 SATA disks in it, plus a compact flash memory card on
PATA (boot device, while SATA-disks are JBOD in SW RAID), it has
_no_ /sys/bus/ide/, nor /proc/ide/
All devices are under /sys/bus/scsi/
Simplest way for me to pick this data is to use hdparm -I /dev/sdX
command. Which of course must be run as root. All it does is to open
named device, and issue one ioctl().
That ioctl() can be embedded into a suid-root helper program, or it
can even (in case of Wine) be run separately to write a text file
storing these identifier data on some Wine config file, which the
read from physical device X then does receive.
In my case I don't want to report any of the hard-drive serial numbers,
but rather my boot-device - a flash drive. Hard-drives do break at
some point in time, a flash drive in read-only mode does last considerably
longer.
[PATCH] ide: add /sys/bus/ide/devices/*/{model,firmware,serial} sysfs entries
...
/Matti Aarnio
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Relax permissions for reading hard drive serial number?
On Thu, Nov 29, 2007 at 07:46:19AM -0800, Dan Kegel wrote: On Nov 29, 2007 7:37 AM, Xavier Bestel [EMAIL PROTECTED] wrote: One sticking point is that apps like Photoshop and probably Punkbuster want to retrieve the hard drive's serial number So they can't be installed on a network drive ? I think Adobe supports that, though perhaps not with the retail version. Big companies with network drives are probably an important revenue source for them. I haven't looked closely at what happens when you try installing onto network drives. If you are really interested, it's pretty easy to try yourself; just run the app under wine with WINEDEBUG=+cdrom,+disk and look in the log for calls like CreateFile(.\\PhysicalDrive0, ...). There's some chance the code always checks drive 0 instead of the drive you're installing onto. This lack of having stable(*) unique system identifier available to applications is one of the small details that make node locked commercial software delivery challenging thing in UNIX environments.. *) stable as both stable data, and stable API to get it. There is always the way of delivering such one with a physical serial number device, but for purely selfish reasons I do compare _same_ software delivered for Windows and for Linux -- the Windows version is available for free in a certain very usefull subset, while Linux version costs a few thousand dollars, and is still less functional than the free Windows subset. One UNIX software licensor has resolved this in a way that prevents successfull restore of the license file - possibly by storing stat(2) st_ino data in the license data. Forcing the license file to have any specific i-node number on UNIX filesystems is - a bit difficult. Simple-ish solution here is, of course, to run part of the software via a suid-root helper binary, which then accesses system serial number informations - and does some other usefull and necessary functionality, like find and open external USB device(s) that the software suite drives - by passing opened device handle to the caller program (**). Software installation would want to run in super-user mode to create directory for software data ( /opt/XYZ/ ) and to install the helper binaries, of course. **) I am thinking of hardware programmer tools which highly likely do not have drivers per se in Linux kernel, nor are they easy to configure for hotplug to be assigned (device chowned) to any specific user. Such suid-root tool would let non-privileged user to access the device. One fairly stable thing in UNIX systems are network card MAC addresses. That data is available without super-user privileges, and even the API to retrieve it has been stable for about whole time that Linux has had network services. One can reset the device MAC address, so it isn't as stable as license lockers would want to -- nor difficult to fake. It has one nasty feature, tough: If you have same MAC on multiple machines within same LAN, your network will all the sudden work rather poorly. Nevertheless it is *unique* data that is available to anybody wanting to pick it up, thus I do think that it is hypocritical of making all manners of other identifiers unavailable. Now that I mentioned this, most paranoid of you would of course want to make MAC address to be privileged data, and thus change existing API. Before you do that, check how IPv6 does its address assignments, and what would it mean to system if programs can't find out its own inbound nor outbound IPv6 addresses on connected sockets ? ( - getsockname() ) - Dan /Matti Aarnio -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Development & Objective-C
On Thu, Nov 29, 2007 at 12:14:16PM +, Ben Crowhurst wrote: > Has Objective-C ever been considered for kernel development? > > regards, > BPC To my recall: Never. Some limited subset of C++ was tried, but was soon abandoned. Overall the kernel data structures are done in objectish-manner, although there are no strong type mechanisms being used. Could the kernel be written in a limited subset[*] of ObjC ? Very likely. Would it be worth the job ? Radical decrease in number of available programmers... *) Subset as enforcing the rule of not even indirectly using dynamic memory allocation, when operating in interrupt state. /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Development Objective-C
On Thu, Nov 29, 2007 at 12:14:16PM +, Ben Crowhurst wrote: Has Objective-C ever been considered for kernel development? regards, BPC To my recall: Never. Some limited subset of C++ was tried, but was soon abandoned. Overall the kernel data structures are done in objectish-manner, although there are no strong type mechanisms being used. Could the kernel be written in a limited subset[*] of ObjC ? Very likely. Would it be worth the job ? Radical decrease in number of available programmers... *) Subset as enforcing the rule of not even indirectly using dynamic memory allocation, when operating in interrupt state. /Matti Aarnio - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.23.2
On Fri, Nov 16, 2007 at 02:35:29PM -0500, Mark Lord wrote: > Greg Kroah-Hartman wrote: >> We (the -stable team) are announcing the release of the 2.6.23.2 kernel. >> It contains a number of bugfixes for the core kernel code. >> I'll also be replying to this message with a copy of the patch between >> 2.6.23.1 and 2.6.23.2 > .. >> Tsugikazu Shibata (1): >> HOWTO: update ja_JP/HOWTO with latest changes > .. > > So what is the magic command to apply this patch successfully? > It keeps rejecting the Documentation/ja_JP/HOWTO updates here. Hammer GIT coders into sensibility to add proper MIME headers on these patch post. Then, perhaps, things will just work. (and postmaster won't get tons of rejects..) /Matti Aarnio -- one of <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.23.2
On Fri, Nov 16, 2007 at 02:35:29PM -0500, Mark Lord wrote: Greg Kroah-Hartman wrote: We (the -stable team) are announcing the release of the 2.6.23.2 kernel. It contains a number of bugfixes for the core kernel code. I'll also be replying to this message with a copy of the patch between 2.6.23.1 and 2.6.23.2 .. Tsugikazu Shibata (1): HOWTO: update ja_JP/HOWTO with latest changes .. So what is the magic command to apply this patch successfully? It keeps rejecting the Documentation/ja_JP/HOWTO updates here. Hammer GIT coders into sensibility to add proper MIME headers on these patch post. Then, perhaps, things will just work. (and postmaster won't get tons of rejects..) /Matti Aarnio -- one of [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: your mail
Nope, wrong clues. The right clues are in the footer of this message after it travels thru the list. I supplied them to Nicholas already, but apparently others need to be reminded of them every now and then :-] That footer is in these list messages for a reason! /Matti Aarnio -- one of <[EMAIL PROTECTED]> PS: You want to contact VGER's email and list managers ? We use the internet email standard address "postmaster" On Wed, Oct 17, 2007 at 06:36:19PM +0200, Jan Engelhardt wrote: > Date: Wed, 17 Oct 2007 18:36:19 +0200 (CEST) > From: Jan Engelhardt <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > cc: linux-kernel@vger.kernel.org > Subject: Re: your mail > > On Oct 17 2007 16:30, [EMAIL PROTECTED] wrote: > >Date: Wed, 17 Oct 2007 16:30:24 + > >From: <[EMAIL PROTECTED]> > >To: > ^^ > > > >subscribe linux-alpha > ^ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: your mail
Nope, wrong clues. The right clues are in the footer of this message after it travels thru the list. I supplied them to Nicholas already, but apparently others need to be reminded of them every now and then :-] That footer is in these list messages for a reason! /Matti Aarnio -- one of [EMAIL PROTECTED] PS: You want to contact VGER's email and list managers ? We use the internet email standard address postmaster On Wed, Oct 17, 2007 at 06:36:19PM +0200, Jan Engelhardt wrote: Date: Wed, 17 Oct 2007 18:36:19 +0200 (CEST) From: Jan Engelhardt [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: linux-kernel@vger.kernel.org Subject: Re: your mail On Oct 17 2007 16:30, [EMAIL PROTECTED] wrote: Date: Wed, 17 Oct 2007 16:30:24 + From: [EMAIL PROTECTED] To: linux-kernel@vger.kernel.org ^^ subscribe linux-alpha ^ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Man page for revised timerfd API
On Wed, Oct 03, 2007 at 08:50:09AM +0200, Michael Kerrisk wrote:
> Davide Libenzi wrote:
> > On Thu, 27 Sep 2007, Michael Kerrisk wrote:
> >
> >> Davide,
> >>
> >> A further question: what is the expected behavior in the
> >> following scenario:
> >>
> >> 1. Create a timerfd and arm it.
> >> 2. Wait until M timer expirations have occurred
> >> 3. Modify the settings of the timer
> >> 4. Wait for N further timer expirations have occurred
> >> 5. read() from the timerfd
> >>
> >> Does the buffer returned by the read() contain the value
> >> N or (M+N)? In other words, should modifying the timer
> >> settings reset the expiration count to zero?
> >
> > Every timerfd_settime() zeroes the tick counter. So in your scenario it'll
> > return N.
>
> Thanks Davide.
>
> I modified the first para of the read description to make this clear:
>
>read(2)
> If the timer has already expired one or more times
> since its settings were last modified using
> timerfd_settime(), or since the last successful
> read(2), then the buffer given to read(2) returns
> an unsigned 8-byte integer (uint64_t) containing
> the number of expirations that have occurred.
When returning multi-byte long numeric values via read(2) as byte streams,
my default question is:
Can you explicitely state what is the byte order ?
It _probably_ is the host-byte-order as kernel- and userspaces can hardly
run with different ones and this does not sound like an API to be used
over the network, but nevertheless...
In the code-example:
for (tot_exp = 0; tot_exp < max_exp;) {
s = read(fd, , sizeof(uint64_t));
if (s != sizeof(uint64_t))
die("read");
tot_exp += exp;
print_elapsed_time();
printf("read: %llu; total=%d\\n", exp, tot_exp);
}
If I may suggest some alterations:
for (tot_exp = 0; tot_exp < max_exp;) {
s = read(fd, , sizeof(exp));
if (s < 0) {
/* add: EINTR etc. processing */
continue;
}
if (s != sizeof(exp))
die("read");
tot_exp += exp;
print_elapsed_time();
printf("read: %lu; total=%d\\n", (unsigned long) exp, tot_exp);
}
The "die if surprised" -strategy is not nice.
Somebody will take example out of that code.
Indeed defining all possible error modes may be impossible, but it may
be possible to define those errors that result in so severe dysfunction
that closing and re-creating the timer-handle may be your only choice.
(About the impossibility: Solaris STREAMS based network accept() does/did
yield all kinds of odd errors out from the STREAMS stack in addition to
those listed in the syscall man-page. Reacting on all unknown errors
by dying is not really a smart thing on a program.)
> (In the earlier version of the page the text talked about expirations
> "since the timer was created".)
>
> Cheers,
>
> Michael
> --
> Michael Kerrisk
> maintainer of Linux man pages Sections 2, 3, 4, 5, and 7
/Matti Aarnio <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Man page for revised timerfd API
On Wed, Oct 03, 2007 at 08:50:09AM +0200, Michael Kerrisk wrote:
Davide Libenzi wrote:
On Thu, 27 Sep 2007, Michael Kerrisk wrote:
Davide,
A further question: what is the expected behavior in the
following scenario:
1. Create a timerfd and arm it.
2. Wait until M timer expirations have occurred
3. Modify the settings of the timer
4. Wait for N further timer expirations have occurred
5. read() from the timerfd
Does the buffer returned by the read() contain the value
N or (M+N)? In other words, should modifying the timer
settings reset the expiration count to zero?
Every timerfd_settime() zeroes the tick counter. So in your scenario it'll
return N.
Thanks Davide.
I modified the first para of the read description to make this clear:
read(2)
If the timer has already expired one or more times
since its settings were last modified using
timerfd_settime(), or since the last successful
read(2), then the buffer given to read(2) returns
an unsigned 8-byte integer (uint64_t) containing
the number of expirations that have occurred.
When returning multi-byte long numeric values via read(2) as byte streams,
my default question is:
Can you explicitely state what is the byte order ?
It _probably_ is the host-byte-order as kernel- and userspaces can hardly
run with different ones and this does not sound like an API to be used
over the network, but nevertheless...
In the code-example:
for (tot_exp = 0; tot_exp max_exp;) {
s = read(fd, exp, sizeof(uint64_t));
if (s != sizeof(uint64_t))
die(read);
tot_exp += exp;
print_elapsed_time();
printf(read: %llu; total=%d\\n, exp, tot_exp);
}
If I may suggest some alterations:
for (tot_exp = 0; tot_exp max_exp;) {
s = read(fd, exp, sizeof(exp));
if (s 0) {
/* add: EINTR etc. processing */
continue;
}
if (s != sizeof(exp))
die(read);
tot_exp += exp;
print_elapsed_time();
printf(read: %lu; total=%d\\n, (unsigned long) exp, tot_exp);
}
The die if surprised -strategy is not nice.
Somebody will take example out of that code.
Indeed defining all possible error modes may be impossible, but it may
be possible to define those errors that result in so severe dysfunction
that closing and re-creating the timer-handle may be your only choice.
(About the impossibility: Solaris STREAMS based network accept() does/did
yield all kinds of odd errors out from the STREAMS stack in addition to
those listed in the syscall man-page. Reacting on all unknown errors
by dying is not really a smart thing on a program.)
(In the earlier version of the page the text talked about expirations
since the timer was created.)
Cheers,
Michael
--
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7
/Matti Aarnio [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: git-send-email creates duplicate Message-Id's
On Mon, Sep 17, 2007 at 01:22:05PM -0700, Junio C Hamano wrote:
> Adrian Bunk <[EMAIL PROTECTED]> writes:
>
> > The following might be a bug in git-send-email (git maintainers Cc'ed
> > and KVM list removed from Cc):
> >
> > Patch 54 got the same Message-Id as patch 61 and patch 89 got the same
> > Message-Id as patch 104.
> > ...
> > The emails are:
> > http://marc.info/?l=linux-kernel=119002061330270=2
> > http://marc.info/?l=linux-kernel=119002059626434=2
> > http://marc.info/?l=linux-kernel=119002060011801=2
> > http://marc.info/?l=linux-kernel=119002060318915=2
>
> The old code generated rand(4200) for each message and appended
> it to the timestamp. I do not know where the original author
> got 4200 from, but I think if you send many messages within a
> single second it is possible to get collisions.
>
> I guess something like this patch is an improvement? It
> generates a single prefix from timestamp and random, and appends
> a number that is incremented for each message.
Much better. You may also consider a possibility of
letting your local MTA do the Message-ID generation, unless
you are tracking something with it and thus need to know the
generated values. .. but apparently git much prefers sending
email by SMTP, where the message-id must be present, or one
really should block any such emails.. (except that systems
like qmail send error messages without message-id ...)
My own recipe is:
sprintf("%d-%d-%d", time , getpid, ++localsequence)
catenate on that your favourite domain name where that recipe
is likely to be valid, and you are all set.
/Matti Aarnio -- one of <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: git-send-email creates duplicate Message-Id's
On Mon, Sep 17, 2007 at 01:22:05PM -0700, Junio C Hamano wrote: Adrian Bunk [EMAIL PROTECTED] writes: The following might be a bug in git-send-email (git maintainers Cc'ed and KVM list removed from Cc): Patch 54 got the same Message-Id as patch 61 and patch 89 got the same Message-Id as patch 104. ... The emails are: http://marc.info/?l=linux-kernelm=119002061330270w=2 http://marc.info/?l=linux-kernelm=119002059626434w=2 http://marc.info/?l=linux-kernelm=119002060011801w=2 http://marc.info/?l=linux-kernelm=119002060318915w=2 The old code generated rand(4200) for each message and appended it to the timestamp. I do not know where the original author got 4200 from, but I think if you send many messages within a single second it is possible to get collisions. I guess something like this patch is an improvement? It generates a single prefix from timestamp and random, and appends a number that is incremented for each message. Much better. You may also consider a possibility of letting your local MTA do the Message-ID generation, unless you are tracking something with it and thus need to know the generated values. .. but apparently git much prefers sending email by SMTP, where the message-id must be present, or one really should block any such emails.. (except that systems like qmail send error messages without message-id ...) My own recipe is: sprintf(%d-%d-%d, time , getpid, ++localsequence) catenate on that your favourite domain name where that recipe is likely to be valid, and you are all set. /Matti Aarnio -- one of [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Noatime vs relatime
On Fri, Aug 10, 2007 at 07:26:46AM -0700, Vlad wrote: ... > "Warning: Atime will be disabled by default in future kernel versions, > but you will still be able to turn it on when configuring the kernel." > > This should give a heads-up to the 0.001% of people who still use > atime so that they know to customize this option or start using modern > file-monitoring techniques like inotify. NO for two reasons: - atime semantics are just fine in server environments - inotify IS NOT scalable to millions of files, nor to situations where we want to check alteration weeks or months after the fact In reality I would perhaps prefer mount-behaviour being altered from 'by default do atime' to 'by default do noatime. There MUST be an easy way to tell system that "yes, I want to track last accesstime." I did recently an embedded Linux PC system where the entire system disk is a single Compact Flash -card. I tried to play with noatime option, but the system still kept writing things, and thus I had to do full and somewhat drastic read-only. > Vlad /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Noatime vs relatime
On Fri, Aug 10, 2007 at 07:26:46AM -0700, Vlad wrote: ... Warning: Atime will be disabled by default in future kernel versions, but you will still be able to turn it on when configuring the kernel. This should give a heads-up to the 0.001% of people who still use atime so that they know to customize this option or start using modern file-monitoring techniques like inotify. NO for two reasons: - atime semantics are just fine in server environments - inotify IS NOT scalable to millions of files, nor to situations where we want to check alteration weeks or months after the fact In reality I would perhaps prefer mount-behaviour being altered from 'by default do atime' to 'by default do noatime. There MUST be an easy way to tell system that yes, I want to track last accesstime. I did recently an embedded Linux PC system where the entire system disk is a single Compact Flash -card. I tried to play with noatime option, but the system still kept writing things, and thus I had to do full and somewhat drastic read-only. Vlad /Matti Aarnio - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel doesn't recognize complete memory
On Fri, Jun 29, 2007 at 10:25:26PM +0200, Frank Fiene wrote: > Lenovo Z61p, Intel Core2 Duo T7200 > > I have 4GB RAM installed and BIOS recognize 4GB RAM. > Linux kernel (Ubuntu-7.04, 32bit-PAE and 64bit, openSUSE-10.2 32bit-PAE > and 64bit) tells me: only 3GB of RAM are installed. With AMD's Athlon64 the answer would be "look into BIOS settings, (re)map 3-4 GB memory above 4 GB address mark".. The PCI-bus and all IO devices in it needs memory space within the first 4 GB of physical address space. Some devices support 64-bit addresses in which case they can access whole physical memory, most probably don't, meaning that they can access only memory in lowest 4 GB part of the space. Original 8088 PC had 20 bit address space, and "huge" megabyte of address space. Then came 286 AT era with 24 bit addresses and "whopping" 16 megabyte address space.. then came 386 and finally true 32-bit addresses -- but ISA-space VGA aperture had to be in there still.. and to gain access to of that memory located "under" that VGA aperture, there was mapping... Now the VGA aperture mapping is no more, but the PCI has similar requirements - albeit with bigger apertures. So, what does your BIOS have hidden in "advanced" menus (most likely) ? Something about "remap (PCI?) memory above 4 GB" ? > Any other user with a 4GB Thinkpad? tytso? > > What can i do? Please help! > > Regards > Frank Regards, Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel doesn't recognize complete memory
On Fri, Jun 29, 2007 at 10:25:26PM +0200, Frank Fiene wrote: Lenovo Z61p, Intel Core2 Duo T7200 I have 4GB RAM installed and BIOS recognize 4GB RAM. Linux kernel (Ubuntu-7.04, 32bit-PAE and 64bit, openSUSE-10.2 32bit-PAE and 64bit) tells me: only 3GB of RAM are installed. With AMD's Athlon64 the answer would be look into BIOS settings, (re)map 3-4 GB memory above 4 GB address mark.. The PCI-bus and all IO devices in it needs memory space within the first 4 GB of physical address space. Some devices support 64-bit addresses in which case they can access whole physical memory, most probably don't, meaning that they can access only memory in lowest 4 GB part of the space. Original 8088 PC had 20 bit address space, and huge megabyte of address space. Then came 286 AT era with 24 bit addresses and whopping 16 megabyte address space.. then came 386 and finally true 32-bit addresses -- but ISA-space VGA aperture had to be in there still.. and to gain access to of that memory located under that VGA aperture, there was mapping... Now the VGA aperture mapping is no more, but the PCI has similar requirements - albeit with bigger apertures. So, what does your BIOS have hidden in advanced menus (most likely) ? Something about remap (PCI?) memory above 4 GB ? Any other user with a 4GB Thinkpad? tytso? What can i do? Please help! Regards Frank Regards, Matti Aarnio - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gmail is a bit too popular..
On Mon, Jun 04, 2007 at 11:55:32AM +0100, David Woodhouse wrote: > On Tue, 2007-05-08 at 08:43 +0200, Adrian Bunk wrote: > > BTW (not related to gmail): > > Are there any news regarding the buggy 451 handling in zmailer I'm > > reporting again and again that regularly results in every single > > linux-kernel message sent to me being delayed by up to 13 hours? > > Er, you're giving it a 451 response to _every_ message? Why? His secondary MX server: 220 mailrelay1.lrz-muenchen.de (IntraStore TurboSendmail) ESMTP Service ready yields at times "451-responses". (It suffers from occasional resource starvations and only way to get out of it is to temporarily give those replies.) Indeed there was queue timer bug at VGER in case remote replied with TEMPFAILs sufficiently many times, the whole destination queue to it got kicked back way too much. > -- > dwmw2 /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gmail is a bit too popular..
On Mon, Jun 04, 2007 at 11:55:32AM +0100, David Woodhouse wrote: On Tue, 2007-05-08 at 08:43 +0200, Adrian Bunk wrote: BTW (not related to gmail): Are there any news regarding the buggy 451 handling in zmailer I'm reporting again and again that regularly results in every single linux-kernel message sent to me being delayed by up to 13 hours? Er, you're giving it a 451 response to _every_ message? Why? His secondary MX server: 220 mailrelay1.lrz-muenchen.de (IntraStore TurboSendmail) ESMTP Service ready yields at times 451-responses. (It suffers from occasional resource starvations and only way to get out of it is to temporarily give those replies.) Indeed there was queue timer bug at VGER in case remote replied with TEMPFAILs sufficiently many times, the whole destination queue to it got kicked back way too much. -- dwmw2 /Matti Aarnio - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Google are using linux kernel - what do you know about the source?
On Wed, May 23, 2007 at 04:50:35PM +0200, Diego Calleja wrote: > El Wed, 23 May 2007 16:23:44 +0200, Gergo Szakal <[EMAIL PROTECTED]> escribió: > > > Greetings to all list-members! > > > > Recently I have read that Google are selling enterprise hardware that > > is running a modified version of the Linuk kernel [1]. I decided to ask > > them whether the source is available. I did this via the question form > > they offered. > > http://code.google.com/mirror/gsa.html Gerco, Please read the FAQ at http://www.tux.org/lkml/ There you will notice that use of Linux KERNEL does not mean that your must publish sources for your proprietary application, or to make it easy for somebody to make a distribution competeting with yours. People like Oracle have realized this a long ago, and are selling their commercial products also for Linux platform. Google has made available all parts of the system that they are obliged under GPL to make available. Perhaps person supplying the reply from Google didn't quite understand what the product is, and that it has lots of components where you can get sources for, although nothing exiting and special happens in them. A better reply from Google would have been: "The GSA is made of a branded PC hardware, Linux operating system (sources of components available) plus proprietary Google search engine suite." /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Google are using linux kernel - what do you know about the source?
On Wed, May 23, 2007 at 04:50:35PM +0200, Diego Calleja wrote: El Wed, 23 May 2007 16:23:44 +0200, Gergo Szakal [EMAIL PROTECTED] escribió: Greetings to all list-members! Recently I have read that Google are selling enterprise hardware that is running a modified version of the Linuk kernel [1]. I decided to ask them whether the source is available. I did this via the question form they offered. http://code.google.com/mirror/gsa.html Gerco, Please read the FAQ at http://www.tux.org/lkml/ There you will notice that use of Linux KERNEL does not mean that your must publish sources for your proprietary application, or to make it easy for somebody to make a distribution competeting with yours. People like Oracle have realized this a long ago, and are selling their commercial products also for Linux platform. Google has made available all parts of the system that they are obliged under GPL to make available. Perhaps person supplying the reply from Google didn't quite understand what the product is, and that it has lots of components where you can get sources for, although nothing exiting and special happens in them. A better reply from Google would have been: The GSA is made of a branded PC hardware, Linux operating system (sources of components available) plus proprietary Google search engine suite. /Matti Aarnio - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gmail is a bit too popular..
On Mon, May 07, 2007 at 10:18:21PM +0200, Willy Tarreau wrote: > On Mon, May 07, 2007 at 05:55:55PM +0300, Matti Aarnio wrote: ... > > The gmail is so popular, that with their somewhat rudimentary > > inbound MTA software this kind of recipient masses take horrible > > time to feed in... Mere 0.5-0.7 seconds per recipient, but.. > > > > So far we have tried to feed all recipients in one go per > > message - that is sending 2100 RCPT TO -lines in one swoop, > > and the system has taken some 15-25 minutes per message to > > feed it to gmail. We are running the delivery 20 streams in > > parallel, so it isn't quite as bad as it sounds.. > > > > I suspect they behave like that on purpose to fight spam. No. VGER is on the extreme outer edge of things, only very few legitimate systems have a need to send this much recipients for each and every message. Some small list with perhaps 10 subscribers at gmail notice nothing. Not even with 100 subscribers, but soon after that the sending list sysadmin may notice something... Comparing with spammers - message content analysis (ever so difficult thing anyway) is _easier_ per recipient when we are sending 100 recipients for each DATA-dot body. It is 1/100:th cost per recipient compared to "send one RCPT for each body". We could send all 2100 recipients if systems could negotiate such raised limit (there is no standardized way, just one private ad-hoc,) and do the recipient acceptance analysis fast enough so that PIPELINING-mode would really gain benefits. > If they implemented pipelining, it wouldn't help them. It would not hurt them either. Just help us very few who are at this extreme outer edge of things.. Lightspeed delay (ping) is about 160 ms, so there is still some 300-600 ms that the gmail system is munching somewhere per recipient.. Anyway, VGER is now tuned so that the delivery delay stays usually under about 1 hour per message to gmail. > Willy /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gmail is a bit too popular..
On Mon, May 07, 2007 at 11:03:54AM -0400, John Anthony Kazos Jr. wrote: > > In the linux-kernel -list subscribers domain popularity > > analysis I got following results: > > > >2101 gmail.com > > 49 googlemail.com > > 46 gmx.de > How about some elitism here? Dedicate a certain number of streams to > everything-except-gmail, so MTAs from the 21st century can get their mail > faster, and set the rest on gmail-only. Slows down gmail and speeds up the > rest? No need. gmail has done that slowing down all by themselves quite handily.. VGER has dedicated number of streams to gmail, and bigger pools to elsewere. The gmail parallelism-pool is configured so that daily message volume does usually make it thru in a day. I would prefer it going much faster... If you are interested to see VGER's queues and monitor gauges, they are viewable with tools at web-page: http://vger.kernel.org/z/ Most of what it tells is not easily understandable, and much needs deep internal system knowledge to be understood at all - but mostly the queue display is self-explanatory. /Matti Aarnio PS: Contact address for VGER's postmasters is: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
gmail is a bit too popular..
In the linux-kernel -list subscribers domain popularity analysis I got following results: 2101 gmail.com 49 googlemail.com 46 gmx.de 41 redhat.com 33 yahoo.com 23 suse.de 22 gmx.net 21 comcast.net The gmail is so popular, that with their somewhat rudimentary inbound MTA software this kind of recipient masses take horrible time to feed in... Mere 0.5-0.7 seconds per recipient, but.. So far we have tried to feed all recipients in one go per message - that is sending 2100 RCPT TO -lines in one swoop, and the system has taken some 15-25 minutes per message to feed it to gmail. We are running the delivery 20 streams in parallel, so it isn't quite as bad as it sounds.. I do have one thing that gmail could enable to speed up the message delivery (a lot!) from VGER and other list delivery sources. That single magic needed thing is called "PIPELINING" support at gmail's inbound MX servers. With suitably well behaving smtpserver it is really trivial to implement, all real difficult magic is at the sending side smtp client codes. Once upon a time I implemented that thing for a trans-atlantic SMTP fanout feed -- message delivery time became slashed from hundreds of RTT delays to mere few.. /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gmail is a bit too popular..
On Mon, May 07, 2007 at 10:18:21PM +0200, Willy Tarreau wrote: On Mon, May 07, 2007 at 05:55:55PM +0300, Matti Aarnio wrote: ... The gmail is so popular, that with their somewhat rudimentary inbound MTA software this kind of recipient masses take horrible time to feed in... Mere 0.5-0.7 seconds per recipient, but.. So far we have tried to feed all recipients in one go per message - that is sending 2100 RCPT TO -lines in one swoop, and the system has taken some 15-25 minutes per message to feed it to gmail. We are running the delivery 20 streams in parallel, so it isn't quite as bad as it sounds.. I suspect they behave like that on purpose to fight spam. No. VGER is on the extreme outer edge of things, only very few legitimate systems have a need to send this much recipients for each and every message. Some small list with perhaps 10 subscribers at gmail notice nothing. Not even with 100 subscribers, but soon after that the sending list sysadmin may notice something... Comparing with spammers - message content analysis (ever so difficult thing anyway) is _easier_ per recipient when we are sending 100 recipients for each DATA-dot body. It is 1/100:th cost per recipient compared to send one RCPT for each body. We could send all 2100 recipients if systems could negotiate such raised limit (there is no standardized way, just one private ad-hoc,) and do the recipient acceptance analysis fast enough so that PIPELINING-mode would really gain benefits. If they implemented pipelining, it wouldn't help them. It would not hurt them either. Just help us very few who are at this extreme outer edge of things.. Lightspeed delay (ping) is about 160 ms, so there is still some 300-600 ms that the gmail system is munching somewhere per recipient.. Anyway, VGER is now tuned so that the delivery delay stays usually under about 1 hour per message to gmail. Willy /Matti Aarnio - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
gmail is a bit too popular..
In the linux-kernel -list subscribers domain popularity analysis I got following results: 2101 gmail.com 49 googlemail.com 46 gmx.de 41 redhat.com 33 yahoo.com 23 suse.de 22 gmx.net 21 comcast.net The gmail is so popular, that with their somewhat rudimentary inbound MTA software this kind of recipient masses take horrible time to feed in... Mere 0.5-0.7 seconds per recipient, but.. So far we have tried to feed all recipients in one go per message - that is sending 2100 RCPT TO -lines in one swoop, and the system has taken some 15-25 minutes per message to feed it to gmail. We are running the delivery 20 streams in parallel, so it isn't quite as bad as it sounds.. I do have one thing that gmail could enable to speed up the message delivery (a lot!) from VGER and other list delivery sources. That single magic needed thing is called PIPELINING support at gmail's inbound MX servers. With suitably well behaving smtpserver it is really trivial to implement, all real difficult magic is at the sending side smtp client codes. Once upon a time I implemented that thing for a trans-atlantic SMTP fanout feed -- message delivery time became slashed from hundreds of RTT delays to mere few.. /Matti Aarnio - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gmail is a bit too popular..
On Mon, May 07, 2007 at 11:03:54AM -0400, John Anthony Kazos Jr. wrote: In the linux-kernel -list subscribers domain popularity analysis I got following results: 2101 gmail.com 49 googlemail.com 46 gmx.de How about some elitism here? Dedicate a certain number of streams to everything-except-gmail, so MTAs from the 21st century can get their mail faster, and set the rest on gmail-only. Slows down gmail and speeds up the rest? No need. gmail has done that slowing down all by themselves quite handily.. VGER has dedicated number of streams to gmail, and bigger pools to elsewere. The gmail parallelism-pool is configured so that daily message volume does usually make it thru in a day. I would prefer it going much faster... If you are interested to see VGER's queues and monitor gauges, they are viewable with tools at web-page: http://vger.kernel.org/z/ Most of what it tells is not easily understandable, and much needs deep internal system knowledge to be understood at all - but mostly the queue display is self-explanatory. /Matti Aarnio PS: Contact address for VGER's postmasters is: [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: more than 65535 outbound connections
On Fri, Mar 09, 2007 at 04:13:00PM +0530, Niklaus wrote: > yes now lets take 2 dest machines , source ip is fixed , source port (2^16 > - 1) > destip is fixed (a.a.a.a and b.b.b.b) ,dest port(2^16 -1) each , > > for a connection we have one port used , say connection 1 is > > source ip,port 1 , a.a.a.a port 1 > source ip,port 2 , a.a.a.a port 2 > . > . > . > source ip,port 65535 , a.a.a.a port 65535 You do have some sort of fixation of having same port numbers at both ends. In some rare applications that is done (e.g. with NTP server-server connections using UDP), but it is very rare and never done with TCP. Now if you have 65535 server ports at a.a.a.a, you can have very nearly 4000 million TCP streams in between them. > so total of 65535 connections (assume traffic is still going on, a > movie on a slow line dialup or 1kbps ) > > now if i try to open another connection (assume lots of file > descriptors are present) to a.a.a.a what happens > > to b.b.b.b what happens > > i think both will not get established as the OS doesn't have any free > source ports or am i wrong you are wrong. > >David Lang /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: more than 65535 outbound connections
On Fri, Mar 09, 2007 at 01:49:34PM +0530, Niklaus wrote: > Hi, > > I could be wrong in the below description or might have misunderstood > many of the concepts , please correct appropriately. > > 65535 ports can allowed . So on a machine namely C you can have max > 65535 outbound connections IP connections are quads (four-tuples), machine A and B IP addresses, plus 16 bit port numbers at both ends. You can have about 64 k * 3 G = 192 T connections out from a machine to any single port number out there to all existing IP addresses. If A.ip, B.ip, and B.port stay the same, A can setup up to some 10 - 50 thousand parallel connections. (Depending on allowed dynamic source IP port number space at machine A.) If either B.ip or B.port changes, A can reuse a port that is actively connected to something. Resulting four-tuple is different -> connection is different. Does Linux reuse port numbers in this way ? It most likely does, but I didn't verify. > What i was thinking was to send to another machines A and B from the > same port [X] and then when we get data from it to [X] we can the send > it to the correct application using stateful mapping or storing some > information . The machines A and B are unaware of this mapping from > the C machine. You want to make a "L4 switch" -- a "load balancer" ? That thing is a NAT-box, and is really not making buffered TCP flows, but rather mapping IP/TCP header rewriters to divert the flows to new destinations. > Can we increase it by anymeans in the kernel. Does we have patches for the > above > > i read on the web that terry lambert has got 1.6 million simultaneous > connection ? how is the way it is done. > > http://kerneltrap.org/node/277 With 50 thousand connections per single ( A.ip / B.ip / B.port ) set, one needs only 32 B.ports or A.ip:s or B.ip:s to do that 1.6 million parallel TCP streams. Such does eat up lots and lots system kernel memory... > Regs > Nik /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: more than 65535 outbound connections
On Fri, Mar 09, 2007 at 01:49:34PM +0530, Niklaus wrote: Hi, I could be wrong in the below description or might have misunderstood many of the concepts , please correct appropriately. 65535 ports can allowed . So on a machine namely C you can have max 65535 outbound connections IP connections are quads (four-tuples), machine A and B IP addresses, plus 16 bit port numbers at both ends. You can have about 64 k * 3 G = 192 T connections out from a machine to any single port number out there to all existing IP addresses. If A.ip, B.ip, and B.port stay the same, A can setup up to some 10 - 50 thousand parallel connections. (Depending on allowed dynamic source IP port number space at machine A.) If either B.ip or B.port changes, A can reuse a port that is actively connected to something. Resulting four-tuple is different - connection is different. Does Linux reuse port numbers in this way ? It most likely does, but I didn't verify. What i was thinking was to send to another machines A and B from the same port [X] and then when we get data from it to [X] we can the send it to the correct application using stateful mapping or storing some information . The machines A and B are unaware of this mapping from the C machine. You want to make a L4 switch -- a load balancer ? That thing is a NAT-box, and is really not making buffered TCP flows, but rather mapping IP/TCP header rewriters to divert the flows to new destinations. Can we increase it by anymeans in the kernel. Does we have patches for the above i read on the web that terry lambert has got 1.6 million simultaneous connection ? how is the way it is done. http://kerneltrap.org/node/277 With 50 thousand connections per single ( A.ip / B.ip / B.port ) set, one needs only 32 B.ports or A.ip:s or B.ip:s to do that 1.6 million parallel TCP streams. Such does eat up lots and lots system kernel memory... Regs Nik /Matti Aarnio - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: more than 65535 outbound connections
On Fri, Mar 09, 2007 at 04:13:00PM +0530, Niklaus wrote: yes now lets take 2 dest machines , source ip is fixed , source port (2^16 - 1) destip is fixed (a.a.a.a and b.b.b.b) ,dest port(2^16 -1) each , for a connection we have one port used , say connection 1 is source ip,port 1 , a.a.a.a port 1 source ip,port 2 , a.a.a.a port 2 . . . source ip,port 65535 , a.a.a.a port 65535 You do have some sort of fixation of having same port numbers at both ends. In some rare applications that is done (e.g. with NTP server-server connections using UDP), but it is very rare and never done with TCP. Now if you have 65535 server ports at a.a.a.a, you can have very nearly 4000 million TCP streams in between them. so total of 65535 connections (assume traffic is still going on, a movie on a slow line dialup or 1kbps ) now if i try to open another connection (assume lots of file descriptors are present) to a.a.a.a what happens to b.b.b.b what happens i think both will not get established as the OS doesn't have any free source ports or am i wrong you are wrong. David Lang /Matti Aarnio - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: More nVidia 4gb ram problems
On Thu, Mar 08, 2007 at 12:07:16PM -0800, Marc Perkel wrote: > Running FC6. When I try to format a Raid 1 device the > server locks up when it creates the journal. However > if I use just 2 gigs of ram then it doesn't lock up. > Asus motherboard. > > Please CC me as I'm not a list member. Took some digging out of your log.. AMD Athlon(tm)64 X2 Dual Core Processor 4800+ stepping 02 I have same CPU, though possibly a bit different board. I didn't have success with 4 GB RAM until couple months ago, when Asus did publish a new (beta) BIOS version that did correctly configure memory hoisting in the system. I don't override the pci= and iommu= options, they should work just fine -- if the BIOS isn't entirely rotten. I have used mem=3000M which lets system to work, but of course wastes a gigabyte of memory.. /Matti Aarnio > Linux version 2.6.19-1.2911.6.5.fc6 ([EMAIL PROTECTED]) (gcc version 4.1.1 > 20070105 (Red Hat 4.1.1-51)) #1 SMP Sun Mar 4 16:05:34 EST 2007 > Command line: ro root=LABEL=/ vga=1 pci=nommconf iommu=soft > BIOS-provided physical RAM map: > BIOS-e820: - 0009fc00 (usable) > BIOS-e820: 0009fc00 - 000a (reserved) > BIOS-e820: 000e5000 - 0010 (reserved) > BIOS-e820: 0010 - abfc (usable) > BIOS-e820: abfc - abfce000 (ACPI data) > BIOS-e820: abfce000 - abff (ACPI NVS) > BIOS-e820: abff - ac00 (reserved) > BIOS-e820: fec0 - fec01000 (reserved) > BIOS-e820: fee0 - fef0 (reserved) > BIOS-e820: ff78 - 0001 (reserved) > Entering add_active_range(0, 0, 159) 0 entries of 3200 used > Entering add_active_range(0, 256, 704448) 1 entries of 3200 used > end_pfn_map = 1048576 > DMI 2.3 present. > ACPI: RSDP (v002 ACPIAM) @ 0x000fb870 > ACPI: XSDT (v001 A M I OEMXSDT 0x04000619 MSFT 0x0097) @ > 0xabfc0100 > ACPI: FADT (v003 A M I OEMFACP 0x04000619 MSFT 0x0097) @ > 0xabfc0290 > ACPI: MADT (v001 A M I OEMAPIC 0x04000619 MSFT 0x0097) @ > 0xabfc0390 > ACPI: MCFG (v001 A M I OEMMCFG 0x04000619 MSFT 0x0097) @ > 0xabfc0400 > ACPI: OEMB (v001 A M I AMI_OEM 0x04000619 MSFT 0x0097) @ > 0xabfce040 > ACPI: DSDT (v001 A0368 A0368001 0x0001 INTL 0x02002026) @ > 0x > Scanning NUMA topology in Northbridge 24 > Number of nodes 1 > Node 0 MemBase Limit abfc > Entering add_active_range(0, 0, 159) 0 entries of 3200 used > Entering add_active_range(0, 256, 704448) 1 entries of 3200 used > NUMA: Using 63 for the hash shift. > Using node hash shift of 63 > Bootmem setup node 0 -abfc > Zone PFN ranges: > DMA 0 -> 4096 > DMA324096 -> 1048576 > Normal1048576 -> 1048576 > early_node_map[2] active PFN ranges > 0:0 -> 159 > 0: 256 -> 704448 > On node 0 totalpages: 704351 > DMA zone: 64 pages used for memmap > DMA zone: 1449 pages reserved > DMA zone: 2486 pages, LIFO batch:0 > DMA32 zone: 10943 pages used for memmap > DMA32 zone: 689409 pages, LIFO batch:31 > Normal zone: 0 pages used for memmap > Nvidia board detected. Ignoring ACPI timer override. > If you got timer trouble try acpi_use_timer_override .. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: More nVidia 4gb ram problems
On Thu, Mar 08, 2007 at 12:07:16PM -0800, Marc Perkel wrote: Running FC6. When I try to format a Raid 1 device the server locks up when it creates the journal. However if I use just 2 gigs of ram then it doesn't lock up. Asus motherboard. Please CC me as I'm not a list member. Took some digging out of your log.. AMD Athlon(tm)64 X2 Dual Core Processor 4800+ stepping 02 I have same CPU, though possibly a bit different board. I didn't have success with 4 GB RAM until couple months ago, when Asus did publish a new (beta) BIOS version that did correctly configure memory hoisting in the system. I don't override the pci= and iommu= options, they should work just fine -- if the BIOS isn't entirely rotten. I have used mem=3000M which lets system to work, but of course wastes a gigabyte of memory.. /Matti Aarnio Linux version 2.6.19-1.2911.6.5.fc6 ([EMAIL PROTECTED]) (gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)) #1 SMP Sun Mar 4 16:05:34 EST 2007 Command line: ro root=LABEL=/ vga=1 pci=nommconf iommu=soft BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e5000 - 0010 (reserved) BIOS-e820: 0010 - abfc (usable) BIOS-e820: abfc - abfce000 (ACPI data) BIOS-e820: abfce000 - abff (ACPI NVS) BIOS-e820: abff - ac00 (reserved) BIOS-e820: fec0 - fec01000 (reserved) BIOS-e820: fee0 - fef0 (reserved) BIOS-e820: ff78 - 0001 (reserved) Entering add_active_range(0, 0, 159) 0 entries of 3200 used Entering add_active_range(0, 256, 704448) 1 entries of 3200 used end_pfn_map = 1048576 DMI 2.3 present. ACPI: RSDP (v002 ACPIAM) @ 0x000fb870 ACPI: XSDT (v001 A M I OEMXSDT 0x04000619 MSFT 0x0097) @ 0xabfc0100 ACPI: FADT (v003 A M I OEMFACP 0x04000619 MSFT 0x0097) @ 0xabfc0290 ACPI: MADT (v001 A M I OEMAPIC 0x04000619 MSFT 0x0097) @ 0xabfc0390 ACPI: MCFG (v001 A M I OEMMCFG 0x04000619 MSFT 0x0097) @ 0xabfc0400 ACPI: OEMB (v001 A M I AMI_OEM 0x04000619 MSFT 0x0097) @ 0xabfce040 ACPI: DSDT (v001 A0368 A0368001 0x0001 INTL 0x02002026) @ 0x Scanning NUMA topology in Northbridge 24 Number of nodes 1 Node 0 MemBase Limit abfc Entering add_active_range(0, 0, 159) 0 entries of 3200 used Entering add_active_range(0, 256, 704448) 1 entries of 3200 used NUMA: Using 63 for the hash shift. Using node hash shift of 63 Bootmem setup node 0 -abfc Zone PFN ranges: DMA 0 - 4096 DMA324096 - 1048576 Normal1048576 - 1048576 early_node_map[2] active PFN ranges 0:0 - 159 0: 256 - 704448 On node 0 totalpages: 704351 DMA zone: 64 pages used for memmap DMA zone: 1449 pages reserved DMA zone: 2486 pages, LIFO batch:0 DMA32 zone: 10943 pages used for memmap DMA32 zone: 689409 pages, LIFO batch:31 Normal zone: 0 pages used for memmap Nvidia board detected. Ignoring ACPI timer override. If you got timer trouble try acpi_use_timer_override .. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: User tools for March 11
On Tue, Feb 13, 2007 at 04:19:59PM -0500, linux-os (Dick Johnson) wrote: > Hi! > In the United States, some idiots have decided that the year 2000 scare > wasn't enough so they changed the start date for daylight savings time > from the first Sunday in April to the second Sunday in March. > Does anybody know if there are new tools like `hwclock` and `date`? > Will new 'C' runtime libraries be necessary as well? Dick, UNIXes use UTC internally which has no DST, but for userspace there is "tzdata" package (with that name in Fedora, at least.) * Fri Jan 06 2006 Petr Machata <[EMAIL PROTECTED]> 2005r-2 - 2005r - Zones EST, MST, HST, EST5EDT, CST6CDT, MST7MDT, PST8PDT moved to northamerica to guard against old files with obsolete information being left in the time zone binary directory. - Changes for countries that are supposed to join 2007 US DST change. This includes most of Canada, however entries already in the database (Alberta, British Columbia, Newfoundland, Northwest Territories, and Yukon) were left alone for the time being. - Fixes in zdump.c (abbrok): conditions are chained, and the string is checked for emptiness. .. and many alterations since then. So.. you may already have it in your system. If not, just update that one package. > Cheers, > Dick Johnson /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: User tools for March 11
On Tue, Feb 13, 2007 at 04:19:59PM -0500, linux-os (Dick Johnson) wrote: Hi! In the United States, some idiots have decided that the year 2000 scare wasn't enough so they changed the start date for daylight savings time from the first Sunday in April to the second Sunday in March. Does anybody know if there are new tools like `hwclock` and `date`? Will new 'C' runtime libraries be necessary as well? Dick, UNIXes use UTC internally which has no DST, but for userspace there is tzdata package (with that name in Fedora, at least.) * Fri Jan 06 2006 Petr Machata [EMAIL PROTECTED] 2005r-2 - 2005r - Zones EST, MST, HST, EST5EDT, CST6CDT, MST7MDT, PST8PDT moved to northamerica to guard against old files with obsolete information being left in the time zone binary directory. - Changes for countries that are supposed to join 2007 US DST change. This includes most of Canada, however entries already in the database (Alberta, British Columbia, Newfoundland, Northwest Territories, and Yukon) were left alone for the time being. - Fixes in zdump.c (abbrok): conditions are chained, and the string is checked for emptiness. .. and many alterations since then. So.. you may already have it in your system. If not, just update that one package. Cheers, Dick Johnson /Matti Aarnio - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ntp
On Fri, Feb 02, 2007 at 04:47:26PM +0800, zhangxiliang wrote: > When i start the ntp service successful on server, the client must > ntpdate with the server after waiting a moment. > The moment may be 3~5 minutes, or it may be 10~15 minutes. I don't > know why it happens? The ntp server takes several external clock comparisons to know its local running environments (hosts) clock behaviour. Before it knows that, it has no real knowledge of what the time is, and it won't report anything out. In my environments I have couple local machines (usually doing something else too) assigned as network local NTP servers, and all other machines refer to them. > Regards > Zhang Xiliang > MAIL:[EMAIL PROTECTED] /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ntp
On Fri, Feb 02, 2007 at 04:47:26PM +0800, zhangxiliang wrote: When i start the ntp service successful on server, the client must ntpdate with the server after waiting a moment. The moment may be 3~5 minutes, or it may be 10~15 minutes. I don't know why it happens? The ntp server takes several external clock comparisons to know its local running environments (hosts) clock behaviour. Before it knows that, it has no real knowledge of what the time is, and it won't report anything out. In my environments I have couple local machines (usually doing something else too) assigned as network local NTP servers, and all other machines refer to them. Regards Zhang Xiliang MAIL:[EMAIL PROTECTED] /Matti Aarnio - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [KORG] Re: kernel.org lies about latest -mm kernel
On Sun, Dec 17, 2006 at 10:23:54AM -0800, Randy Dunlap wrote: > J.H. wrote: ... > >The root cause boils down to with git, gitweb and the normal mirroring > >on the frontend machines our basic working set no longer stays resident > >in memory, which is forcing more and more to actively go to disk causing > >a much higher I/O load. You have the added problem that one of the > >frontend machines is getting hit harder than the other due to several > >factors: various DNS servers not round robining, people explicitly > >hitting [git|mirrors|www|etc]1 instead of 2 for whatever reason and > >probably several other factors we aren't aware of. This has caused the > >average load on that machine to hover around 150-200 and if for whatever > >reason we have to take one of the machines down the load on the > >remaining machine will skyrocket to 2000+. Relaying on DNS and clients doing round-robin load-balancing is doomed. You really, REALLY, need external L4 load-balancer switches. (And installation help from somebody who really knows how to do this kind of services on a cluster.) Basic config features include, of course: - number of parallel active connections with each protocol - availability of each served protocol (e.g. one can shutdown rsync at one server, and new rsync connections get pushed elsewere) - running load-balance of each served protocol separately - server load monitoring and letting it bias new connections to nodes not so utterly loaded - allowing direct access to each server in addition to the access via cluster service - some sort of connection persistence, only for HTTP access ? (ftp and rsync can do nicely without) > >Since it's apparent not everyone is aware of what we are doing, I'll > >mention briefly some of the bigger points. ... > >- We've cut back on the number of ftp and rsync users to the machines. > >Basically we are cutting back where we can in an attempt to keep the > >load from spiraling out of control, this helped a bit when we recently > >had to take one of the machines down and instead of loads spiking into > >the 2000+ range we peaked at about 500-600 I believe. How about having filesystems mounted with "noatime" ? Or do you already do that ? > >So we know the problem is there, and we are working on it - we are > >getting e-mails about it if not daily than every other day or so. If > >there are suggestions we are willing to hear them - but the general > >feeling with the admins is that we are probably hitting the biggest > >problems already. /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [KORG] Re: kernel.org lies about latest -mm kernel
On Sun, Dec 17, 2006 at 10:23:54AM -0800, Randy Dunlap wrote: J.H. wrote: ... The root cause boils down to with git, gitweb and the normal mirroring on the frontend machines our basic working set no longer stays resident in memory, which is forcing more and more to actively go to disk causing a much higher I/O load. You have the added problem that one of the frontend machines is getting hit harder than the other due to several factors: various DNS servers not round robining, people explicitly hitting [git|mirrors|www|etc]1 instead of 2 for whatever reason and probably several other factors we aren't aware of. This has caused the average load on that machine to hover around 150-200 and if for whatever reason we have to take one of the machines down the load on the remaining machine will skyrocket to 2000+. Relaying on DNS and clients doing round-robin load-balancing is doomed. You really, REALLY, need external L4 load-balancer switches. (And installation help from somebody who really knows how to do this kind of services on a cluster.) Basic config features include, of course: - number of parallel active connections with each protocol - availability of each served protocol (e.g. one can shutdown rsync at one server, and new rsync connections get pushed elsewere) - running load-balance of each served protocol separately - server load monitoring and letting it bias new connections to nodes not so utterly loaded - allowing direct access to each server in addition to the access via cluster service - some sort of connection persistence, only for HTTP access ? (ftp and rsync can do nicely without) Since it's apparent not everyone is aware of what we are doing, I'll mention briefly some of the bigger points. ... - We've cut back on the number of ftp and rsync users to the machines. Basically we are cutting back where we can in an attempt to keep the load from spiraling out of control, this helped a bit when we recently had to take one of the machines down and instead of loads spiking into the 2000+ range we peaked at about 500-600 I believe. How about having filesystems mounted with noatime ? Or do you already do that ? So we know the problem is there, and we are working on it - we are getting e-mails about it if not daily than every other day or so. If there are suggestions we are willing to hear them - but the general feeling with the admins is that we are probably hitting the biggest problems already. /Matti Aarnio - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Postgrey experiment at VGER
Hello, I am running an experiment with Postgrey to delay (for 300 seconds minimum) incoming emails. If the clients don't retry after this delay, then the messages don't usually get in. The "postgrey" in question is the very same thing that exists for the Postfix MTA with various automatic whitelistings of repeatedly successfull senders, etc. I do already see spammers smart enough to retry addresses from the zombie machine, but that share is now below 10% of all emails. My prediction for next 200 days is that most spammers get the clue, but it gives us perhaps 3 months of less leaked junk. /Matti Aarnio -- one of - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Postgrey experiment at VGER
Hello, I am running an experiment with Postgrey to delay (for 300 seconds minimum) incoming emails. If the clients don't retry after this delay, then the messages don't usually get in. The postgrey in question is the very same thing that exists for the Postfix MTA with various automatic whitelistings of repeatedly successfull senders, etc. I do already see spammers smart enough to retry addresses from the zombie machine, but that share is now below 10% of all emails. My prediction for next 200 days is that most spammers get the clue, but it gives us perhaps 3 months of less leaked junk. /Matti Aarnio -- one of postmaster at vger.kernel.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux poll(2) functionality difference from Solaris (10)
I am coding first rounds usually on Linux, but I do try to verify everything on several other UNIXes. During this port debugging I realized that on Solaris the poll(2) result flags return POLLEOF without POLLIN on files that have EOF condition for reading. In same situation the Linux 2.6.15 returns POLLIN, but I don't know if there is also POLLEOF. (Same with 2.6.9 at vger.kernel.org) To track the issue, I did enter it also into Kernel Bugzilla: http://bugzilla.kernel.org/show_bug.cgi?id=7609 /Matti Aarnio -- Now VGER could run more than 1000 parallel outgoing SMTP sessions. (Not that it really needs to.) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux poll(2) functionality difference from Solaris (10)
I am coding first rounds usually on Linux, but I do try to verify everything on several other UNIXes. During this port debugging I realized that on Solaris the poll(2) result flags return POLLEOF without POLLIN on files that have EOF condition for reading. In same situation the Linux 2.6.15 returns POLLIN, but I don't know if there is also POLLEOF. (Same with 2.6.9 at vger.kernel.org) To track the issue, I did enter it also into Kernel Bugzilla: http://bugzilla.kernel.org/show_bug.cgi?id=7609 /Matti Aarnio -- Now VGER could run more than 1000 parallel outgoing SMTP sessions. (Not that it really needs to.) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how to create atm interface in linux
On Tue, Sep 06, 2005 at 02:43:35PM +0100, manomugdha biswas wrote: > Date: Tue, 6 Sep 2005 14:43:35 +0100 (BST) > From: manomugdha biswas <[EMAIL PROTECTED]> > Subject: how to create atm interface in linux > To: linux-kernel@vger.kernel.org > Cc: linux-net@vger.kernel.org > > Hi, > I want to create an ATM interface on linux. I can > create ethernet interface using alloc_etherdev() and > then registering this device. Can I use the same > function to create atm interface ? Or there is other > way to do this? Can you please give some light on this > issue? How about asking that at the Linux-ATM -list ? I can tell you only, that it isn't hosted at VGER. > Regards, > Mano > > Manomugdha Biswas /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how to create atm interface in linux
On Tue, Sep 06, 2005 at 02:43:35PM +0100, manomugdha biswas wrote: Date: Tue, 6 Sep 2005 14:43:35 +0100 (BST) From: manomugdha biswas [EMAIL PROTECTED] Subject: how to create atm interface in linux To: linux-kernel@vger.kernel.org Cc: linux-net@vger.kernel.org Hi, I want to create an ATM interface on linux. I can create ethernet interface using alloc_etherdev() and then registering this device. Can I use the same function to create atm interface ? Or there is other way to do this? Can you please give some light on this issue? How about asking that at the Linux-ATM -list ? I can tell you only, that it isn't hosted at VGER. Regards, Mano Manomugdha Biswas /Matti Aarnio - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Soft lockup in e100 driver ?
On Wed, Aug 10, 2005 at 08:32:45PM -0400, Stephen D. Williams wrote: > I just noticed that the Ubuntu setup says "GSI 20(level,low) -> IRQ 20" > whereas I remember my built kernels saying "No GSI.. IRQ 11". I'll > investigate what that means and how to enable it. Pointers appreciated. That is most likely unrelated, but I had similar experiences at times. It turned out that something done recently in APIC management code did break things, but lattest version is again working. For a while to have network card working I had to boot with "noapic" option in my home SMP box. In an UP box it is about same to boot as "noapic", but in SMP it does result in "one CPU does all interrupts" thingie. (In some rare cases it could be desirable, even.) /Matti Aarnio > sdw > > Stephen D. Williams wrote: > > >I have been working for days to get a recent kernel to work with these > >small-format UP Celeron 2Ghz (running at 1.33Ghz) motherboards that I > >am planning to use as thin clients. I'm doing a PXE boot, loading > >kernels, and trying to get networking to come up. > > > >I eventually realized that the problem is that the e100 driver loads > >but does not allow any packet traffic. The system isn't crashed, but > >I do get transmit timeouts. > > > >I've used kernels: 2.6.10, 2.6.11, and 2.6.12.4, stock with only the > >"squashfs" patch applied and compiled as 586/ > > > >The interesting thing is that Ubuntu 5.04, booted "Live" on the box, > >works just fine with the e100 driver with a kernel shown as: > >"2.6.10-5-386". I'm going to work on pulling this kernel and its > >modules off to use. > > > >Any help urgently appreciated. > > > >sdw - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Soft lockup in e100 driver ?
On Wed, Aug 10, 2005 at 08:32:45PM -0400, Stephen D. Williams wrote: I just noticed that the Ubuntu setup says GSI 20(level,low) - IRQ 20 whereas I remember my built kernels saying No GSI.. IRQ 11. I'll investigate what that means and how to enable it. Pointers appreciated. That is most likely unrelated, but I had similar experiences at times. It turned out that something done recently in APIC management code did break things, but lattest version is again working. For a while to have network card working I had to boot with noapic option in my home SMP box. In an UP box it is about same to boot as noapic, but in SMP it does result in one CPU does all interrupts thingie. (In some rare cases it could be desirable, even.) /Matti Aarnio sdw Stephen D. Williams wrote: I have been working for days to get a recent kernel to work with these small-format UP Celeron 2Ghz (running at 1.33Ghz) motherboards that I am planning to use as thin clients. I'm doing a PXE boot, loading kernels, and trying to get networking to come up. I eventually realized that the problem is that the e100 driver loads but does not allow any packet traffic. The system isn't crashed, but I do get transmit timeouts. I've used kernels: 2.6.10, 2.6.11, and 2.6.12.4, stock with only the squashfs patch applied and compiled as 586/ The interesting thing is that Ubuntu 5.04, booted Live on the box, works just fine with the e100 driver with a kernel shown as: 2.6.10-5-386. I'm going to work on pulling this kernel and its modules off to use. Any help urgently appreciated. sdw - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Soft lockup in e100 driver ?
On Tue, Aug 09, 2005 at 09:16:21AM -0700, Daniel Walker wrote:
> It looks like this might be an SMP race , it seem that both processors
> are in e100_down(). There is a while loop in e100_clean_cbs() that
> appears to have an unsafe looping condition .
>
> It looks like cbs_avail might jump over params.cbs.count , then you
> would have to wait for a rollover . Is this a PREEMPT_NONE kernel?
# CONFIG_PREEMPT is not set
# CONFIG_PREEMPT_BKL is not set
which is probably same as "NONE".
There is _one_ processor in down, but other may be in trying to send
some data out, or otherwise polling the card.
However... while real bugs in their own sense, none of these are
as important as original "card dies" thing, during a recovery of
which all this soft-lockup merryment happens.
Also, as it happens only once a week or so (except when it happens
right after another), testing code patches is rather slow.
I can guess which things make it more likely, but I can't make it
happen at will.
/Matti Aarnio
> This patch may help, but it's not a complete fix.
>
> --- linux-2.6.12.orig/drivers/net/e100.c2005-08-05 16:45:59.0
> +
> +++ linux-2.6.12/drivers/net/e100.c 2005-08-09 16:14:45.0 +
> @@ -1393,7 +1393,7 @@ static inline int e100_tx_clean(struct n
> static void e100_clean_cbs(struct nic *nic)
> {
> if(nic->cbs) {
> - while(nic->cbs_avail != nic->params.cbs.count) {
> + while(nic->cbs_avail < nic->params.cbs.count) {
> struct cb *cb = nic->cb_to_clean;
> if(cb->skb) {
> pci_unmap_single(nic->pdev,
>
>
>
> On Tue, 2005-08-09 at 16:36 +0300, Matti Aarnio wrote:
> > Running very recent Fedora Core Development kernel I can following
> > soft-oops.. ( 2.6.12-1.1455_FC5smp )
> >
> >
> > e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
> > BUG: soft lockup detected on CPU#0!
> >
> > Pid: 10743, comm: ifconfig
> > EIP: 0060:[] CPU: 0
> > EIP is at e100_clean_cbs+0x2f/0x12b [e100]
> > EFLAGS: 0293Not tainted (2.6.12-1.1455_FC5smp)
> > EAX: 495c7c2b EBX: 495c7c2b ECX: f6c311a0 EDX:
> > ESI: 0040 EDI: f6c3 EBP: f71a4b20 DS: 007b ES: 007b
> > CR0: 8005003b CR2: 0804a544 CR3: 01e9cd80 CR4: 06f0
> > [] e100_down+0x66/0x9a [e100]
> > [] e100_close+0xa/0xd [e100]
> > [] dev_close+0x40/0x7e
> > [] dev_change_flags+0x46/0xf5
> > [] devinet_ioctl+0x564/0x5df
> > [] sock_ioctl+0xc3/0x250
> > [] sock_ioctl+0x0/0x250
> > [] do_ioctl+0x1f/0x6d
> > [] vfs_ioctl+0x50/0x1c6
> > [] sys_ioctl+0x5d/0x6f
> > [] syscall_call+0x7/0xb
> > [] softlockup_tick+0x6f/0x80
> > [] timer_interrupt+0x2d/0x75
> > [] handle_IRQ_event+0x2e/0x5a
> > [] __do_IRQ+0xc2/0x127
> > [] do_IRQ+0x4e/0x86
> > ===
> > [] smp_apic_timer_interrupt+0xc1/0xca
> > [] common_interrupt+0x1a/0x20
> > [] e100_clean_cbs+0x2f/0x12b [e100]
> > [] e100_down+0x66/0x9a [e100]
> > [] e100_close+0xa/0xd [e100]
> > [] dev_close+0x40/0x7e
> > [] dev_change_flags+0x46/0xf5
> > [] devinet_ioctl+0x564/0x5df
> > [] sock_ioctl+0xc3/0x250
> > [] sock_ioctl+0x0/0x250
> > [] do_ioctl+0x1f/0x6d
> > [] vfs_ioctl+0x50/0x1c6
> > [] sys_ioctl+0x5d/0x6f
> > [] syscall_call+0x7/0xb
> >
> >
> >
> > Preconditions for this are:
> >
> > - E100 card stopped working for some reason (no idea why, it just
> > does sometimes at this oldish 2x P-III machine)
> > - There are active datastreams running in and out
> > (around 0.2 Mbps out, multiple megabits in.)
> > - Commanding then "ifconfig eth0 down" results in what feels like
> > system freezing, but it does recover in about 30-60 seconds
> > (it takes long enough for me to sweat bullets...)
> > - While in freeze state, keyboard can go crazy, but mouse does
> > respond, as well as tvtime shows bt848 captured live video.
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [EMAIL PROTECTED]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Soft lockup in e100 driver ?
On Tue, Aug 09, 2005 at 11:41:40AM -0400, Steven Rostedt wrote: > On Tue, 2005-08-09 at 17:37 +0300, Matti Aarnio wrote: > > On Tue, Aug 09, 2005 at 03:55:49PM +0200, Jesper Juhl wrote: > > > On 8/9/05, Matti Aarnio <[EMAIL PROTECTED]> wrote: > > > > Running very recent Fedora Core Development kernel I can following > > > > soft-oops.. ( 2.6.12-1.1455_FC5smp ) > > > > > > > Various patches to the e100 driver have been merged since 2.6.12.1 > > > (which is ~1.5months old), so it would make sense to try a more recent > > > kernel like 2.6.13-rc6, 2.6.13-rc6-git1 or 2.6.13-rc5-mm1 and see if > > > you can still reproduce the problem with those. > > > > The kernel in question is less than 3 days old RedHat Fedora Core > > Development kernel with baseline as: > > * Sun Aug 07 2005 Dave Jones <[EMAIL PROTECTED]> > > - 2.6.13-rc5-git4 > > > > Those merges have not helped. > > Matti, > > I believe Fedora must have added Ingo's soft lockup detect code. I've > made additions to this code as well. Could you point me to a link that I > could download this kernel source. No rpm's or packagemanagers please. > Just a tarball would be fine. The fundamental thing is, IT LOCKS UP (for a while), when I do "ifconfig eth0 down" and there is active traffic but the card DIES somehow. Apparently it requires marginal/unreliable hardware to happen as well. (Which for e100 is rather rare.) That is: at first the card dies, then I notice it, and do the ifconfig. Then things go _bad_, and recover. Then I do 'rmmod e100', and restart network (which reloads the driver module), and things work once again. Fedora kernel sources have this "softlockups" patch file: (size and date) 6159 May 12 04:50 linux-2.6.12-detect-softlockups.patch That file I can upload, if you want. Or send in email. Rest of the RPM-wrapper CPIO package I would prefer not to... > Thanks, > -- Steve /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VGER news
On Tue, Aug 09, 2005 at 04:39:24PM +0200, Erik Mouw wrote: > On Tue, Aug 09, 2005 at 04:33:47PM +0200, Jan Engelhardt wrote: > > > > >Folks at Dell have donated a new machine to be VGER, and > > >folks at RedHat have installed it into co-location facility > > >with 1000Mbps network connection into the machine. > > > > May 24 2004 on kernel.org: > > ISC has upgraded our outbound connection to 1000 Mbit/s. Thanks! > > That's www and ftp.kernel.org, the archive server. Different location, different services. > > So you have 2000 Mbps now? > > No, this time vger.kernel.org (the mailing list server) got > an 1000 Mbit/s connection. > > > >This update got considerable performance increase into the > > >machine for our list loads. In terms of Bogomips around 7-8, > > >but for actual loads nearly twice as much. > > > > Wow, that's a lot of bogomips. That's just a little faster than my 386 > > (running 2.6.13-rc1): http://jengelh.hopto.org/GFX0/proc386.jpg > > Matti is talking about an increase, which implies a difference. In "absolute" terms about 5600 BogoMips, although all bogos are not quite the same... (E.g. Coppermine -> Xeon gives a bit more difference than just bogos would imply.) > Erik /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VGER news
On Tue, Aug 09, 2005 at 04:31:30PM +0200, Petr Vandrovec wrote: > Matti Aarnio wrote: > > >We did system switchover last weekend, and nobody reacted trulu > >adversely.Probably nobody noticed it either. :-) > > Ah, that's the reason why commit messages are now sent from > [EMAIL PROTECTED] instead of from > [EMAIL PROTECTED] like they were until > Friday ? > Best regards, > Petr Vandrovec That is probably something else. Davem may have changed list name at this time as well. /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Soft lockup in e100 driver ?
On Tue, Aug 09, 2005 at 03:55:49PM +0200, Jesper Juhl wrote: > On 8/9/05, Matti Aarnio <[EMAIL PROTECTED]> wrote: > > Running very recent Fedora Core Development kernel I can following > > soft-oops.. ( 2.6.12-1.1455_FC5smp ) > > > Various patches to the e100 driver have been merged since 2.6.12.1 > (which is ~1.5months old), so it would make sense to try a more recent > kernel like 2.6.13-rc6, 2.6.13-rc6-git1 or 2.6.13-rc5-mm1 and see if > you can still reproduce the problem with those. The kernel in question is less than 3 days old RedHat Fedora Core Development kernel with baseline as: * Sun Aug 07 2005 Dave Jones <[EMAIL PROTECTED]> - 2.6.13-rc5-git4 Those merges have not helped. > -- > Jesper Juhl <[EMAIL PROTECTED]> /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Soft lockup in e100 driver ?
On Tue, Aug 09, 2005 at 03:55:49PM +0200, Jesper Juhl wrote: On 8/9/05, Matti Aarnio [EMAIL PROTECTED] wrote: Running very recent Fedora Core Development kernel I can following soft-oops.. ( 2.6.12-1.1455_FC5smp ) Various patches to the e100 driver have been merged since 2.6.12.1 (which is ~1.5months old), so it would make sense to try a more recent kernel like 2.6.13-rc6, 2.6.13-rc6-git1 or 2.6.13-rc5-mm1 and see if you can still reproduce the problem with those. The kernel in question is less than 3 days old RedHat Fedora Core Development kernel with baseline as: * Sun Aug 07 2005 Dave Jones [EMAIL PROTECTED] - 2.6.13-rc5-git4 Those merges have not helped. -- Jesper Juhl [EMAIL PROTECTED] /Matti Aarnio - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VGER news
On Tue, Aug 09, 2005 at 04:31:30PM +0200, Petr Vandrovec wrote: Matti Aarnio wrote: We did system switchover last weekend, and nobody reacted trulu adversely.Probably nobody noticed it either. :-) Ah, that's the reason why commit messages are now sent from [EMAIL PROTECTED] instead of from [EMAIL PROTECTED] like they were until Friday ? Best regards, Petr Vandrovec That is probably something else. Davem may have changed list name at this time as well. /Matti Aarnio - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VGER news
On Tue, Aug 09, 2005 at 04:39:24PM +0200, Erik Mouw wrote: On Tue, Aug 09, 2005 at 04:33:47PM +0200, Jan Engelhardt wrote: Folks at Dell have donated a new machine to be VGER, and folks at RedHat have installed it into co-location facility with 1000Mbps network connection into the machine. May 24 2004 on kernel.org: ISC has upgraded our outbound connection to 1000 Mbit/s. Thanks! That's www and ftp.kernel.org, the archive server. Different location, different services. So you have 2000 Mbps now? No, this time vger.kernel.org (the mailing list server) got an 1000 Mbit/s connection. This update got considerable performance increase into the machine for our list loads. In terms of Bogomips around 7-8, but for actual loads nearly twice as much. Wow, that's a lot of bogomips. That's just a little faster than my 386 (running 2.6.13-rc1): http://jengelh.hopto.org/GFX0/proc386.jpg Matti is talking about an increase, which implies a difference. In absolute terms about 5600 BogoMips, although all bogos are not quite the same... (E.g. Coppermine - Xeon gives a bit more difference than just bogos would imply.) Erik /Matti Aarnio - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Soft lockup in e100 driver ?
On Tue, Aug 09, 2005 at 11:41:40AM -0400, Steven Rostedt wrote: On Tue, 2005-08-09 at 17:37 +0300, Matti Aarnio wrote: On Tue, Aug 09, 2005 at 03:55:49PM +0200, Jesper Juhl wrote: On 8/9/05, Matti Aarnio [EMAIL PROTECTED] wrote: Running very recent Fedora Core Development kernel I can following soft-oops.. ( 2.6.12-1.1455_FC5smp ) Various patches to the e100 driver have been merged since 2.6.12.1 (which is ~1.5months old), so it would make sense to try a more recent kernel like 2.6.13-rc6, 2.6.13-rc6-git1 or 2.6.13-rc5-mm1 and see if you can still reproduce the problem with those. The kernel in question is less than 3 days old RedHat Fedora Core Development kernel with baseline as: * Sun Aug 07 2005 Dave Jones [EMAIL PROTECTED] - 2.6.13-rc5-git4 Those merges have not helped. Matti, I believe Fedora must have added Ingo's soft lockup detect code. I've made additions to this code as well. Could you point me to a link that I could download this kernel source. No rpm's or packagemanagers please. Just a tarball would be fine. The fundamental thing is, IT LOCKS UP (for a while), when I do ifconfig eth0 down and there is active traffic but the card DIES somehow. Apparently it requires marginal/unreliable hardware to happen as well. (Which for e100 is rather rare.) That is: at first the card dies, then I notice it, and do the ifconfig. Then things go _bad_, and recover. Then I do 'rmmod e100', and restart network (which reloads the driver module), and things work once again. Fedora kernel sources have this softlockups patch file: (size and date) 6159 May 12 04:50 linux-2.6.12-detect-softlockups.patch That file I can upload, if you want. Or send in email. Rest of the RPM-wrapper CPIO package I would prefer not to... Thanks, -- Steve /Matti Aarnio - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Soft lockup in e100 driver ?
On Tue, Aug 09, 2005 at 09:16:21AM -0700, Daniel Walker wrote:
It looks like this might be an SMP race , it seem that both processors
are in e100_down(). There is a while loop in e100_clean_cbs() that
appears to have an unsafe looping condition .
It looks like cbs_avail might jump over params.cbs.count , then you
would have to wait for a rollover . Is this a PREEMPT_NONE kernel?
# CONFIG_PREEMPT is not set
# CONFIG_PREEMPT_BKL is not set
which is probably same as NONE.
There is _one_ processor in down, but other may be in trying to send
some data out, or otherwise polling the card.
However... while real bugs in their own sense, none of these are
as important as original card dies thing, during a recovery of
which all this soft-lockup merryment happens.
Also, as it happens only once a week or so (except when it happens
right after another), testing code patches is rather slow.
I can guess which things make it more likely, but I can't make it
happen at will.
/Matti Aarnio
This patch may help, but it's not a complete fix.
--- linux-2.6.12.orig/drivers/net/e100.c2005-08-05 16:45:59.0
+
+++ linux-2.6.12/drivers/net/e100.c 2005-08-09 16:14:45.0 +
@@ -1393,7 +1393,7 @@ static inline int e100_tx_clean(struct n
static void e100_clean_cbs(struct nic *nic)
{
if(nic-cbs) {
- while(nic-cbs_avail != nic-params.cbs.count) {
+ while(nic-cbs_avail nic-params.cbs.count) {
struct cb *cb = nic-cb_to_clean;
if(cb-skb) {
pci_unmap_single(nic-pdev,
On Tue, 2005-08-09 at 16:36 +0300, Matti Aarnio wrote:
Running very recent Fedora Core Development kernel I can following
soft-oops.. ( 2.6.12-1.1455_FC5smp )
e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
BUG: soft lockup detected on CPU#0!
Pid: 10743, comm: ifconfig
EIP: 0060:[f88bf2f9] CPU: 0
EIP is at e100_clean_cbs+0x2f/0x12b [e100]
EFLAGS: 0293Not tainted (2.6.12-1.1455_FC5smp)
EAX: 495c7c2b EBX: 495c7c2b ECX: f6c311a0 EDX:
ESI: 0040 EDI: f6c3 EBP: f71a4b20 DS: 007b ES: 007b
CR0: 8005003b CR2: 0804a544 CR3: 01e9cd80 CR4: 06f0
[f88c0708] e100_down+0x66/0x9a [e100]
[f88c1623] e100_close+0xa/0xd [e100]
[c02b7adb] dev_close+0x40/0x7e
[c02b8f59] dev_change_flags+0x46/0xf5
[c02f76b3] devinet_ioctl+0x564/0x5df
[c02af22c] sock_ioctl+0xc3/0x250
[c02af169] sock_ioctl+0x0/0x250
[c01762ef] do_ioctl+0x1f/0x6d
[c017648f] vfs_ioctl+0x50/0x1c6
[c0176662] sys_ioctl+0x5d/0x6f
[c010394d] syscall_call+0x7/0xb
[c014473f] softlockup_tick+0x6f/0x80
[c01085b8] timer_interrupt+0x2d/0x75
[c01448dd] handle_IRQ_event+0x2e/0x5a
[c01449cb] __do_IRQ+0xc2/0x127
[c0105f7e] do_IRQ+0x4e/0x86
===
[c01160cc] smp_apic_timer_interrupt+0xc1/0xca
[c0104382] common_interrupt+0x1a/0x20
[f88bf2f9] e100_clean_cbs+0x2f/0x12b [e100]
[f88c0708] e100_down+0x66/0x9a [e100]
[f88c1623] e100_close+0xa/0xd [e100]
[c02b7adb] dev_close+0x40/0x7e
[c02b8f59] dev_change_flags+0x46/0xf5
[c02f76b3] devinet_ioctl+0x564/0x5df
[c02af22c] sock_ioctl+0xc3/0x250
[c02af169] sock_ioctl+0x0/0x250
[c01762ef] do_ioctl+0x1f/0x6d
[c017648f] vfs_ioctl+0x50/0x1c6
[c0176662] sys_ioctl+0x5d/0x6f
[c010394d] syscall_call+0x7/0xb
Preconditions for this are:
- E100 card stopped working for some reason (no idea why, it just
does sometimes at this oldish 2x P-III machine)
- There are active datastreams running in and out
(around 0.2 Mbps out, multiple megabits in.)
- Commanding then ifconfig eth0 down results in what feels like
system freezing, but it does recover in about 30-60 seconds
(it takes long enough for me to sweat bullets...)
- While in freeze state, keyboard can go crazy, but mouse does
respond, as well as tvtime shows bt848 captured live video.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Getting rid of SHMMAX/SHMALL ?
On Thu, Aug 04, 2005 at 03:23:38PM +0200, Andi Kleen wrote: > On Thu, Aug 04, 2005 at 02:19:21PM +0100, Hugh Dickins wrote: > > On Thu, 4 Aug 2005, Andi Kleen wrote: > > > > > I noticed that even 64bit architectures have a ridiculously low > > > max limit on shared memory segments by default: > > > > > > #define SHMMAX 0x200 /* max shared seg size (bytes) */ > > > #define SHMMNI 4096 /* max num of segs system wide */ > > > #define SHMALL (SHMMAX/PAGE_SIZE*(SHMMNI/16)) /* max shm system wide > > > (pages) */ > > > > > > Even on 32bit architectures it is far too small and doesn't > > > make much sense. Does anybody remember why we even have this limit? > > > > To be like the UNIXes. > > Ok, no other more fundamental reason ? :) > I cannot think of any at least. Those supply DEFAULT values for bootup time, and they can be adjusted with sysctl. Existence of the limits is good. Their easy tunability (even easier than at Solaris, where you tune them only with a reboot) is even better. SHM resources are non-swappable, thus I would not by default let user programs go and allocate very much SHM spaces at all. Such is usually spelled as: "denial-of-service-attack" For that reason I would not raise builtin defaults either. ... > > I think we should just get rid of the per process limit and keep > the global limit, but make it auto tuning based on available memory. Err... No thanks! I would prefer to have even finer grained control of how much SHM somebody can allocate. For normal user the value might be zero, but for users in a group "SHM1" there could be a level of N MB, etc. (Except that such mechanisms are rather complex...) For dedicated servers there is no problem of letting there be single global limit and its default value being in highish realms, but pick any machine with multiple users running their own programs Consider all of them hostile (clueless can do as much damage as any intentionally hostile.) Mmm... Apparently X (and/or other parts of the desktop) do ask for a number of shared memory segments. Default user allocation limit can't be zero. > That is still not very nice because that would likely keep it < available > memory/2, but I suspect databases usually want more than that. So > I would even make it bigger than tmpfs for reasonably big machines. > Let's say > > if (main memory >= 1GB) > maxmem = main memory - main memory/8 > else > maxmem = main memory / 2 > > possible increase the 4096 segments limit too, it seems quite low, > or also auto tune based on memory. > > One possible problem with getting rid of /proc/sys/kernel/shmmni > would be that some programs might read it and fail if it's not available. i > So I would probably keep it read only but always return LONG_MAX. > > > I don't think my opinion is worth much on this: > > what would the distro tuners like to see there? > > suse has shipped larger default limits for a long time. > And all the databases and some other software documents > increasing these values. If there were kernels that are optimized for database servers, then the hard-wired defaults might be risen, of course. On the other hand, sysadmin knows for the best, and we have adjustment tools that don't require kernel recompile, nor even reboot to be effective. > -Andi /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Getting rid of SHMMAX/SHMALL ?
On Thu, Aug 04, 2005 at 03:23:38PM +0200, Andi Kleen wrote: On Thu, Aug 04, 2005 at 02:19:21PM +0100, Hugh Dickins wrote: On Thu, 4 Aug 2005, Andi Kleen wrote: I noticed that even 64bit architectures have a ridiculously low max limit on shared memory segments by default: #define SHMMAX 0x200 /* max shared seg size (bytes) */ #define SHMMNI 4096 /* max num of segs system wide */ #define SHMALL (SHMMAX/PAGE_SIZE*(SHMMNI/16)) /* max shm system wide (pages) */ Even on 32bit architectures it is far too small and doesn't make much sense. Does anybody remember why we even have this limit? To be like the UNIXes. Ok, no other more fundamental reason ? :) I cannot think of any at least. Those supply DEFAULT values for bootup time, and they can be adjusted with sysctl. Existence of the limits is good. Their easy tunability (even easier than at Solaris, where you tune them only with a reboot) is even better. SHM resources are non-swappable, thus I would not by default let user programs go and allocate very much SHM spaces at all. Such is usually spelled as: denial-of-service-attack For that reason I would not raise builtin defaults either. ... I think we should just get rid of the per process limit and keep the global limit, but make it auto tuning based on available memory. Err... No thanks! I would prefer to have even finer grained control of how much SHM somebody can allocate. For normal user the value might be zero, but for users in a group SHM1 there could be a level of N MB, etc. (Except that such mechanisms are rather complex...) For dedicated servers there is no problem of letting there be single global limit and its default value being in highish realms, but pick any machine with multiple users running their own programs Consider all of them hostile (clueless can do as much damage as any intentionally hostile.) Mmm... Apparently X (and/or other parts of the desktop) do ask for a number of shared memory segments. Default user allocation limit can't be zero. That is still not very nice because that would likely keep it available memory/2, but I suspect databases usually want more than that. So I would even make it bigger than tmpfs for reasonably big machines. Let's say if (main memory = 1GB) maxmem = main memory - main memory/8 else maxmem = main memory / 2 possible increase the 4096 segments limit too, it seems quite low, or also auto tune based on memory. One possible problem with getting rid of /proc/sys/kernel/shmmni would be that some programs might read it and fail if it's not available. i So I would probably keep it read only but always return LONG_MAX. I don't think my opinion is worth much on this: what would the distro tuners like to see there? suse has shipped larger default limits for a long time. And all the databases and some other software documents increasing these values. If there were kernels that are optimized for database servers, then the hard-wired defaults might be risen, of course. On the other hand, sysadmin knows for the best, and we have adjustment tools that don't require kernel recompile, nor even reboot to be effective. -Andi /Matti Aarnio - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IBM Thinkpad T42 - Looking for a Developer.
Good morning, On Thu, Apr 14, 2005 at 10:20:08PM -0500, Alejandro Bonilla wrote: > Matti, > > Where do we stand here? Now that you have two of those outputs, so I > can have some hope... Do you think we can make the driver for this > hardware? > > How about the firmware that the documents mention? Could there be a > layer in the hardware itself that might prevents us from reading the > fingerprint image? The hardware exists for fingerprint reading. It is all a matter of understanding of how to talk to those BULK endpoints to do proper communication, and that is somewhat challening without that level of documentation. In USB documents that kind of document is known as "Device Class Definition" idVendor 0x0483 SGS Thomson Microelectronics idProduct 0x2016 iManufacturer 1 STMicroelectronics iProduct2 Biometric Coprocessor Interface Descriptor: bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 This "Vendor Specific Class" means it needs specific document, not only USB Implementers' Forum:s generic documents. Windows driver binary does implement it, and (at least in EU) it is perfectly legal to reverse engineer something in order to produce compatible products or to use something that isn't completely documented. Nevertheless I would prefer to have documents about actual communication messages that are exchanged over those endpoints. That would speed up driver writing considerably. > Will BioAPI help us at all, or the best approach here is not to make > dll wrapping? At least I prefer not to mess with (windows-)DLL-wrapping. Linux exists in quite a many platforms, and the BioAPI library does already exist for Linux in source form as well. That reference BioAPI implementation needs very least the backend driver of the actual reader. What else does it need, I can't say without doing experimentation and code reading. If the necessary document is deep NDA for some reason, we can negotiate with the vendor about how obfuscated version of the resulting driver source can be included in open source distributions. > Thanks for you all time, > - Alejandro /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IBM Thinkpad T42 - Looking for a Developer.
Good morning, On Thu, Apr 14, 2005 at 10:20:08PM -0500, Alejandro Bonilla wrote: Matti, Where do we stand here? Now that you have two of those outputs, so I can have some hope... Do you think we can make the driver for this hardware? How about the firmware that the documents mention? Could there be a layer in the hardware itself that might prevents us from reading the fingerprint image? The hardware exists for fingerprint reading. It is all a matter of understanding of how to talk to those BULK endpoints to do proper communication, and that is somewhat challening without that level of documentation. In USB documents that kind of document is known as Device Class Definition idVendor 0x0483 SGS Thomson Microelectronics idProduct 0x2016 iManufacturer 1 STMicroelectronics iProduct2 Biometric Coprocessor Interface Descriptor: bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 This Vendor Specific Class means it needs specific document, not only USB Implementers' Forum:s generic documents. Windows driver binary does implement it, and (at least in EU) it is perfectly legal to reverse engineer something in order to produce compatible products or to use something that isn't completely documented. Nevertheless I would prefer to have documents about actual communication messages that are exchanged over those endpoints. That would speed up driver writing considerably. Will BioAPI help us at all, or the best approach here is not to make dll wrapping? At least I prefer not to mess with (windows-)DLL-wrapping. Linux exists in quite a many platforms, and the BioAPI library does already exist for Linux in source form as well. That reference BioAPI implementation needs very least the backend driver of the actual reader. What else does it need, I can't say without doing experimentation and code reading. If the necessary document is deep NDA for some reason, we can negotiate with the vendor about how obfuscated version of the resulting driver source can be included in open source distributions. Thanks for you all time, - Alejandro /Matti Aarnio - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IBM Thinkpad T42 - Looking for a Developer.
On Thu, Apr 14, 2005 at 06:40:16PM -0400, abonilla wrote: > On Thu, 14 Apr 2005 23:20:19 +0200 (CEST), Jesper Juhl wrote > > > This is located in my home PC, Won't be the fastest downloads... > > > > > > http://wifitux.com/finger/ > > > > > Under what terms did you obtain these documents and from where? Are > > they completely freely distributable or are there strings attached? > > I emailed the guys and they told me, "Hey, here you go, let me know if you > want more information" Those documents and files are downloadable also from www.upek.com They are rather scattered out there, but still... In Linux environment we do need to define and implement our own interface to the the device. There is BioAPI (www.bioapi.org) interface specification, but that is rather high up in the application stack. (There exists also NIST written Linux version at that site, and it seems to be "BSD with advertisement clause" licensed...) My reading so far seems to indicate, that this is mostly doable in the application space without needing kernel space drivers. Implementing BioAPI interface library with device specific backends (much in the same manner as SANE works) is the way, I do think. To how large an extent the existing source code can be used in this is so far unknown. To be able to do the device specific backends, I do need to have the detailed USB interface protocol descriptions, not just a windows library binary wrapping them up into BioAPI. I can handle NDA documents as long as the resulting source code into Linux (and any other UNIX-like system capable to use it) can be published. > > -- > > Jesper /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IBM Thinkpad T42 - Looking for a Developer.
On Thu, Apr 14, 2005 at 06:40:16PM -0400, abonilla wrote: > On Thu, 14 Apr 2005 23:20:19 +0200 (CEST), Jesper Juhl wrote > > On Thu, 14 Apr 2005, Alejandro Bonilla wrote: ... > > > This is located in my home PC, Won't be the fastest downloads... > > > > > > http://wifitux.com/finger/ > > > > Under what terms did you obtain these documents and from where? Are > > they completely freely distributable or are there strings attached? > > I emailed the guys and they told me, "Hey, here you go, let me know if you > want more information" > > I guess it can't be more distributable. But as far as I got to read. The > documents don't have too much information like for us to do a great Job. I > think it also requires the making of a firmware. > > I don't want to dissapoint you, but I hope I'm lost and that a driver can be > done out of this. There were two PDF documents. The more useful one tells that there are two possible interfaces: - Async serial - USB Could you show what/sbin/lsusb -vv tells in your T42 ? Do that without external devices attached. > > -- > > Jesper /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IBM Thinkpad T42 - Looking for a Developer.
On Thu, Apr 14, 2005 at 06:40:16PM -0400, abonilla wrote: On Thu, 14 Apr 2005 23:20:19 +0200 (CEST), Jesper Juhl wrote On Thu, 14 Apr 2005, Alejandro Bonilla wrote: ... This is located in my home PC, Won't be the fastest downloads... http://wifitux.com/finger/ Under what terms did you obtain these documents and from where? Are they completely freely distributable or are there strings attached? I emailed the guys and they told me, Hey, here you go, let me know if you want more information I guess it can't be more distributable. But as far as I got to read. The documents don't have too much information like for us to do a great Job. I think it also requires the making of a firmware. I don't want to dissapoint you, but I hope I'm lost and that a driver can be done out of this. There were two PDF documents. The more useful one tells that there are two possible interfaces: - Async serial - USB Could you show what/sbin/lsusb -vvtells in your T42 ? Do that without external devices attached. -- Jesper /Matti Aarnio - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IBM Thinkpad T42 - Looking for a Developer.
On Thu, Apr 14, 2005 at 06:40:16PM -0400, abonilla wrote: On Thu, 14 Apr 2005 23:20:19 +0200 (CEST), Jesper Juhl wrote This is located in my home PC, Won't be the fastest downloads... http://wifitux.com/finger/ Under what terms did you obtain these documents and from where? Are they completely freely distributable or are there strings attached? I emailed the guys and they told me, Hey, here you go, let me know if you want more information Those documents and files are downloadable also from www.upek.com They are rather scattered out there, but still... In Linux environment we do need to define and implement our own interface to the the device. There is BioAPI (www.bioapi.org) interface specification, but that is rather high up in the application stack. (There exists also NIST written Linux version at that site, and it seems to be BSD with advertisement clause licensed...) My reading so far seems to indicate, that this is mostly doable in the application space without needing kernel space drivers. Implementing BioAPI interface library with device specific backends (much in the same manner as SANE works) is the way, I do think. To how large an extent the existing source code can be used in this is so far unknown. To be able to do the device specific backends, I do need to have the detailed USB interface protocol descriptions, not just a windows library binary wrapping them up into BioAPI. I can handle NDA documents as long as the resulting source code into Linux (and any other UNIX-like system capable to use it) can be published. -- Jesper /Matti Aarnio - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [bk tree] DRM add a version check.. for 2.6.12 (distro kernel maintainers + drm users plz read also...)
On Thu, Apr 07, 2005 at 02:00:07PM +0100, Dave Airlie wrote: > > My lattest runs were with 2 days old FC development (a.k.a. "bleeding edge") > > environment with xorg-11-** of same age. Then I noticed that these DRM > > patches didn't make it into kernel-smp-2.6.11-1.1226_FC4.i686.rpm, > > and I made 2.6.12-rc2 -- just in case it had fixed the problem... > > well these patches shouldn't really affect it.. :-( > > Could the card-lockups be recovered in a bit nicer way ? > > (And detected, too!) > > In theory yes, but there isn't really anything you can do except reboot, > as usually the CP (command processor) is hung, and you have to do a full > GPU reset, I can't imagine X or Linux consoles surviving it too well... > ATI have a VPU Recover in their windows driver which does it.. but they > know their cards a bit better than we do.. > > it might be worth turning Render acceleration off Option "RenderAccel" > "No" in xorg.conf and see if it gets any stabler... With that option set, the TuxRacer didn't hang anywhere in practice fields, but choosing "Credits" did hang the system in seconds. > Dave. > -- > David Airlie, Software Engineer > http://www.skynet.ie/~airlied / airlied at skynet.ie > Linux kernel - DRI, VAX / pam_smb / ILUG /Matti - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [bk tree] DRM add a version check.. for 2.6.12 (distro kernel maintainers + drm users plz read also...)
On Thu, Apr 07, 2005 at 02:00:07PM +0100, Dave Airlie wrote: My lattest runs were with 2 days old FC development (a.k.a. bleeding edge) environment with xorg-11-** of same age. Then I noticed that these DRM patches didn't make it into kernel-smp-2.6.11-1.1226_FC4.i686.rpm, and I made 2.6.12-rc2 -- just in case it had fixed the problem... well these patches shouldn't really affect it.. :-( Could the card-lockups be recovered in a bit nicer way ? (And detected, too!) In theory yes, but there isn't really anything you can do except reboot, as usually the CP (command processor) is hung, and you have to do a full GPU reset, I can't imagine X or Linux consoles surviving it too well... ATI have a VPU Recover in their windows driver which does it.. but they know their cards a bit better than we do.. it might be worth turning Render acceleration off Option RenderAccel No in xorg.conf and see if it gets any stabler... With that option set, the TuxRacer didn't hang anywhere in practice fields, but choosing Credits did hang the system in seconds. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG /Matti - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [bk tree] DRM add a version check.. for 2.6.12 (distro kernel maintainers + drm users plz read also...)
On Thu, Apr 07, 2005 at 01:38:52PM +0100, Dave Airlie wrote: > > I tried 2.6.12-rc2 which includes this patch, and I get DRM failures > > here, which causes application and X to hang. (I got failures with 2.6.11 > > also.) > > Does the FC-4 test kernel work? There was a bug in X6.8.2 but I think it > would be fixed in FC-4 test.. I run Xorg CVS on a 9200 with the latest > kernel and it seems fine... granted I've been able to crash it with > running a few wierd apps.. I've just had no chance to debug it yet but it > isn't the common case... maybe I should play tuxracer for a while.. > > the symptoms are typical of a card lockup, spinning in ioctl forever... > > Dave. My lattest runs were with 2 days old FC development (a.k.a. "bleeding edge") environment with xorg-11-** of same age. Then I noticed that these DRM patches didn't make it into kernel-smp-2.6.11-1.1226_FC4.i686.rpm, and I made 2.6.12-rc2 -- just in case it had fixed the problem... Could the card-lockups be recovered in a bit nicer way ? (And detected, too!) /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [bk tree] DRM add a version check.. for 2.6.12 (distro kernel maintainers + drm users plz read also...)
Dropping Linus off this list... On Mon, Mar 28, 2005 at 12:40:16PM +0100, Dave Airlie wrote: > Hi Linus, > > In order to stop someone loading a drm driver on a wrong core this patch > makes the driver pass in the version is was built against, this mainly > useful for people using the DRI snapshots for cards that aren't their > normal cards... > > Also for anyone who maintains a kernel for distros or builds their own > please build your kernels with CONFIG_DRM=m not =y, from 2.6.11 onwards.. > as if you build with =y then DRI snapshots will no longer work.. I tried 2.6.12-rc2 which includes this patch, and I get DRM failures here, which causes application and X to hang. (I got failures with 2.6.11 also.) When accessing the machine from network, I can see that either application, or X itself is running as close as possible to 100% CPU utilization. Symptom is such that the application, or X-server, is executing an ioctl() on a file-handle that has node: /dev/drm/card0open in r/w mode. Following is from memory: ioctl(5, something, something) -- Received ALARM(0) -- ioctl(5, something, something) -- Received ALARM(0) -- that repeats as fast as possible. I have now Radeon 9200SE card with 128 MB memory (I used to have Matrox MGA G400 AGP with 8 MB memory - no room for anything but pixel maps), but then I absolutely needed accelerated 3D, and had to go and get a "modern" card. System is running Fedora Core 4 Test-1 application space codes along with fresh baseline 2.6.11 + 2.6.12-rc2 patchset ( = "2.6.12-rc2" ). I observed that xscreensaver-demo running "GLForestFire" is reliably able to hangup the desktop within minutes, IF media-automounter is snooping around in /dev/cdrom and there is some disk. (I had FC4test1 rescue disk in there. ) With disk taken out, the system ran some 8 hours without a glitch. Nevertheless, I then tried some fun with TuxRacer, and was able to get the same drm hangup after an hour or so. ANY ideas ? /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [bk tree] DRM add a version check.. for 2.6.12 (distro kernel maintainers + drm users plz read also...)
Dropping Linus off this list... On Mon, Mar 28, 2005 at 12:40:16PM +0100, Dave Airlie wrote: Hi Linus, In order to stop someone loading a drm driver on a wrong core this patch makes the driver pass in the version is was built against, this mainly useful for people using the DRI snapshots for cards that aren't their normal cards... Also for anyone who maintains a kernel for distros or builds their own please build your kernels with CONFIG_DRM=m not =y, from 2.6.11 onwards.. as if you build with =y then DRI snapshots will no longer work.. I tried 2.6.12-rc2 which includes this patch, and I get DRM failures here, which causes application and X to hang. (I got failures with 2.6.11 also.) When accessing the machine from network, I can see that either application, or X itself is running as close as possible to 100% CPU utilization. Symptom is such that the application, or X-server, is executing an ioctl() on a file-handle that has node: /dev/drm/card0open in r/w mode. Following is from memory: ioctl(5, something, something) -- Received ALARM(0) -- ioctl(5, something, something) -- Received ALARM(0) -- that repeats as fast as possible. I have now Radeon 9200SE card with 128 MB memory (I used to have Matrox MGA G400 AGP with 8 MB memory - no room for anything but pixel maps), but then I absolutely needed accelerated 3D, and had to go and get a modern card. System is running Fedora Core 4 Test-1 application space codes along with fresh baseline 2.6.11 + 2.6.12-rc2 patchset ( = 2.6.12-rc2 ). I observed that xscreensaver-demo running GLForestFire is reliably able to hangup the desktop within minutes, IF media-automounter is snooping around in /dev/cdrom and there is some disk. (I had FC4test1 rescue disk in there. ) With disk taken out, the system ran some 8 hours without a glitch. Nevertheless, I then tried some fun with TuxRacer, and was able to get the same drm hangup after an hour or so. ANY ideas ? /Matti Aarnio - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [bk tree] DRM add a version check.. for 2.6.12 (distro kernel maintainers + drm users plz read also...)
On Thu, Apr 07, 2005 at 01:38:52PM +0100, Dave Airlie wrote: I tried 2.6.12-rc2 which includes this patch, and I get DRM failures here, which causes application and X to hang. (I got failures with 2.6.11 also.) Does the FC-4 test kernel work? There was a bug in X6.8.2 but I think it would be fixed in FC-4 test.. I run Xorg CVS on a 9200 with the latest kernel and it seems fine... granted I've been able to crash it with running a few wierd apps.. I've just had no chance to debug it yet but it isn't the common case... maybe I should play tuxracer for a while.. the symptoms are typical of a card lockup, spinning in ioctl forever... Dave. My lattest runs were with 2 days old FC development (a.k.a. bleeding edge) environment with xorg-11-** of same age. Then I noticed that these DRM patches didn't make it into kernel-smp-2.6.11-1.1226_FC4.i686.rpm, and I made 2.6.12-rc2 -- just in case it had fixed the problem... Could the card-lockups be recovered in a bit nicer way ? (And detected, too!) /Matti Aarnio - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: E-cards for You
On Thu, Feb 17, 2005 at 02:03:08PM -0800, Chuck Harding wrote: > Why can't the list owners apply spamassassin to the list's *incoming* > mail stream so we don't ever see this stuff? Nearly every one of the > lists hosted on vger.kernel.org get spammed on a regular basis because > there is no spam filtering before the messages get passed to majordomo. Perhaps because way too big a share of diffs do get blocked by people's SAs out there... CHICKENPOX indeed... Trust me to prefer erring on too liberal instead of blocking too much. > -- > Charles D. (Chuck) Harding <[EMAIL PROTECTED]> Voice: 925-423-8879 /Matti Aarnio - one of <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: E-cards for You
On Thu, Feb 17, 2005 at 02:03:08PM -0800, Chuck Harding wrote: Why can't the list owners apply spamassassin to the list's *incoming* mail stream so we don't ever see this stuff? Nearly every one of the lists hosted on vger.kernel.org get spammed on a regular basis because there is no spam filtering before the messages get passed to majordomo. Perhaps because way too big a share of diffs do get blocked by people's SAs out there... CHICKENPOX indeed... Trust me to prefer erring on too liberal instead of blocking too much. -- Charles D. (Chuck) Harding [EMAIL PROTECTED] Voice: 925-423-8879 /Matti Aarnio - one of [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please suggest me
On Fri, Jul 20, 2001 at 02:13:00PM -0400, Dipak Biswas wrote: > Hi All, > I'm quite new to linux world. I've a very awkard question for you. > That is: I'm writting an user process, where I need all outgoing > IP packets to be blocked and captured. First, is it really possible? If > yes, how? I don't want to make any kernel source code changes. A wild > guess: by configuration changes, is it possible to make IP process write > on to a particular FD which I can read when I require? Look at how tools like tcpdump and etherreal do it. It has been done over and over again -- in userspace tool. > Thanks, > dipak /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: patch to fs/proc/base.c
On Fri, Jul 20, 2001 at 05:59:51PM +0400, Nikita Danilov wrote: > Date: Fri, 20 Jul 2001 17:59:51 +0400 > From: Nikita Danilov <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: patch to fs/proc/base.c > > Hello, > > following patch cures oopses in 2.4.7-pre9 when > proc_pid_make_inode() is called on task with task->mm == NULL. > > Linus, please apply, if you haven't got a bunch of equivalent patches > already, which is doubtful. He won't. For two reasons: - There is better fix which Linus himself posted some hours ago - Linus does not read (directly) linux-kernel list. > Nikita. /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: patch to fs/proc/base.c
On Fri, Jul 20, 2001 at 05:59:51PM +0400, Nikita Danilov wrote: Date: Fri, 20 Jul 2001 17:59:51 +0400 From: Nikita Danilov [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: patch to fs/proc/base.c Hello, following patch cures oopses in 2.4.7-pre9 when proc_pid_make_inode() is called on task with task-mm == NULL. Linus, please apply, if you haven't got a bunch of equivalent patches already, which is doubtful. He won't. For two reasons: - There is better fix which Linus himself posted some hours ago - Linus does not read (directly) linux-kernel list. Nikita. /Matti Aarnio - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please suggest me
On Fri, Jul 20, 2001 at 02:13:00PM -0400, Dipak Biswas wrote: Hi All, I'm quite new to linux world. I've a very awkard question for you. That is: I'm writting an user process, where I need all outgoing IP packets to be blocked and captured. First, is it really possible? If yes, how? I don't want to make any kernel source code changes. A wild guess: by configuration changes, is it possible to make IP process write on to a particular FD which I can read when I require? Look at how tools like tcpdump and etherreal do it. It has been done over and over again -- in userspace tool. Thanks, dipak /Matti Aarnio - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: TCP/IP stack
Richard, should there be (is there?) linux-networking-faq, or can this be put into the linux-kernel faq ? On Thu, Jun 28, 2001 at 10:33:46AM -0400, Michael J Clark wrote: > hey guys, > > I have been reading through TCP/IP Illustrated Vol 2 and the linux > source. That book describes BSD implementation. Linux code has been written completely independently, and using fundamentally different base structure -- instead of PCBs containing chains of segments, Linux has SKBs with entire segment contiguous in it. Function, and structure names are different, naturally. > Mike /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: TCP/IP stack
Richard, should there be (is there?) linux-networking-faq, or can this be put into the linux-kernel faq ? On Thu, Jun 28, 2001 at 10:33:46AM -0400, Michael J Clark wrote: hey guys, I have been reading through TCP/IP Illustrated Vol 2 and the linux source. That book describes BSD implementation. Linux code has been written completely independently, and using fundamentally different base structure -- instead of PCBs containing chains of segments, Linux has SKBs with entire segment contiguous in it. Function, and structure names are different, naturally. Mike /Matti Aarnio - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BSD sockets with sys_socketcall
On Wed, Jun 27, 2001 at 12:23:27PM -0700, Prasad Koya wrote: > How does socket(), bind() and other BSD socket API > calls in user applications are handled by system > socketcall(). Does the compiler (say gcc) substitute > socket() in user app with socketcall(SYS_SOCKET,..)? You are using libc wrappers which translate the BSD API to Linux kernel ABI. > Thanks /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BSD sockets with sys_socketcall
On Wed, Jun 27, 2001 at 12:23:27PM -0700, Prasad Koya wrote: How does socket(), bind() and other BSD socket API calls in user applications are handled by system socketcall(). Does the compiler (say gcc) substitute socket() in user app with socketcall(SYS_SOCKET,..)? You are using libc wrappers which translate the BSD API to Linux kernel ABI. Thanks /Matti Aarnio - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Duplicate IP ??
On Tue, Jun 26, 2001 at 03:51:33PM -0400, Richard B. Johnson wrote:
> I just got a bunch of messages from vger.kernel.org, sent to
> [EMAIL PROTECTED], claiming a "local configuration error"
> and some kind of a loop.
Weird... I don't recall any bounces..
Logs show *one* bounce from chaos.analogic.com just
about an hour ago, and it went to linux-kernel-owner ..
There are also 121 successfull deliveries in 12 hours
collected in the log.
> There is no configuration that has changed on that machine for
> at least two years although our firewall got updated last week
> to fix the ECN bug.
>
> I checked with ns.uu.net to see if the machine address was still
> resolvable, it is.
>
> I can `telnet vger.kernel.org 25`. That connectivity works.
> So I don't get any mail from vger.kernel.org. What goes?
Where then those 121 messages went ?
The ECN connectivity problem is visible only when
connection originator (= vger) has the ECN bit on.
If incoming SYN doesn't have ECN bit on, reply to
SYN is sent without ECN. That is why people can
reach VGER, but VGER might not be able to reach
people's MTAs.
> Dick Johnson
/Matti Aarnio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Duplicate IP ??
On Tue, Jun 26, 2001 at 03:51:33PM -0400, Richard B. Johnson wrote: I just got a bunch of messages from vger.kernel.org, sent to [EMAIL PROTECTED], claiming a local configuration error and some kind of a loop. Weird... I don't recall any bounces.. Logs show *one* bounce from chaos.analogic.com just about an hour ago, and it went to linux-kernel-owner .. There are also 121 successfull deliveries in 12 hours collected in the log. There is no configuration that has changed on that machine for at least two years although our firewall got updated last week to fix the ECN bug. I checked with ns.uu.net to see if the machine address was still resolvable, it is. I can `telnet vger.kernel.org 25`. That connectivity works. So I don't get any mail from vger.kernel.org. What goes? Where then those 121 messages went ? The ECN connectivity problem is visible only when connection originator (= vger) has the ECN bit on. If incoming SYN doesn't have ECN bit on, reply to SYN is sent without ECN. That is why people can reach VGER, but VGER might not be able to reach people's MTAs. Dick Johnson /Matti Aarnio - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
I can understand the opinnions expressed by these quotes. Having seen how horribly certain CORBA monsters work, I am sure that the basic idea of threads is lost somewhere along the way... On Tue, Jun 19, 2001 at 09:09:56AM -0700, Larry McVoy wrote: > > > >-- > > > > "A Computer is a state machine. > > > > Threads are for people who can't program state machines." > > > > - Alan Cox > And one from me: > > ``Think of it this way: threads are like salt, not like pasta. You > like salt, I like salt, we all like salt. But we eat more pasta.'' > > Threads are a really bad idea. All you need are processes and either the > ability to not fork the VM (Linux' clone, Plan 9's rfork) or just good > old mmap(2). If you allow threads then all you are saying is that your > process model is so pathetic you had to invent another, supposedly lighter > weight, object to do the same thing. That is usually true. In rare cases I *do* want to use threads, or things just alike them. Pre-requisite are for wanting to share very large amounts of the VM of the processes and/or IO descriptors, have multiple processors in the system capable to execute my code, and wanting to parallellize (with lack of AIO) certain IO activities (disk related, mainly) which normal non-blocking IO can't handle. Threads are like salt, best used in moderation. They are resources, and hogging them will very rapidly cause the harms to exceed the benefits. (...that CORBA beast...) ... creates a thread for each incoming request without any sort of limit at how much there can be threads running in parallel. > Don't you think it is funny that Sun doesn't publish numbers comparing > their thread performance to process performance? Sure, you can find > context switch benchmarks where they have user level switching going on > but those are a red herring. The real numbers you want are the kernel > level context switches and those are just as expensive as the process > context switch numbers. If they weren't, I would be most amazed.. > -- > Larry McVoylm at bitmover.com http://www.bitmover.com/lm /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
I can understand the opinnions expressed by these quotes. Having seen how horribly certain CORBA monsters work, I am sure that the basic idea of threads is lost somewhere along the way... On Tue, Jun 19, 2001 at 09:09:56AM -0700, Larry McVoy wrote: -- A Computer is a state machine. Threads are for people who can't program state machines. - Alan Cox And one from me: ``Think of it this way: threads are like salt, not like pasta. You like salt, I like salt, we all like salt. But we eat more pasta.'' Threads are a really bad idea. All you need are processes and either the ability to not fork the VM (Linux' clone, Plan 9's rfork) or just good old mmap(2). If you allow threads then all you are saying is that your process model is so pathetic you had to invent another, supposedly lighter weight, object to do the same thing. That is usually true. In rare cases I *do* want to use threads, or things just alike them. Pre-requisite are for wanting to share very large amounts of the VM of the processes and/or IO descriptors, have multiple processors in the system capable to execute my code, and wanting to parallellize (with lack of AIO) certain IO activities (disk related, mainly) which normal non-blocking IO can't handle. Threads are like salt, best used in moderation. They are resources, and hogging them will very rapidly cause the harms to exceed the benefits. (...that CORBA beast...) ... creates a thread for each incoming request without any sort of limit at how much there can be threads running in parallel. Don't you think it is funny that Sun doesn't publish numbers comparing their thread performance to process performance? Sure, you can find context switch benchmarks where they have user level switching going on but those are a red herring. The real numbers you want are the kernel level context switches and those are just as expensive as the process context switch numbers. If they weren't, I would be most amazed.. -- Larry McVoylm at bitmover.com http://www.bitmover.com/lm /Matti Aarnio - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
