True fsync() in Linux (on IDE)

True fsync() in Linux (on IDE)

[Peter Zaitsev]

Hello,

I'm wondering is there any way in Linux to do proper fsync(), which
makes sure data is written to the disk.

Currently on IDE devices one can see, fsync() only flushes data to the
drive cache which is not enough for ACID guaranties database server must
give. 

There is solution just to disable drive write cache, but it seems to
slowdown performance way to much.

I would be also happy enough with some global kernel option which would
enable drive cache flush on fsync :) 


Mac OS X also has this "optimization", but at least it provides an
alternative flush method for Database Servers:

fcntl(fd, F_FULLFSYNC, NULL)

can be used instead of fsync() to get true fsync() behavior. 

-- 
Peter Zaitsev, Senior Support Engineer
MySQL AB, www.mysql.com

Meet the MySQL Team at User Conference 2004! (April 14-16, Orlando,FL)
  http://www.mysql.com/uc2004/

Re: True fsync() in Linux (on IDE)

[Jens Axboe]

On Wed, Mar 17 2004, Peter Zaitsev wrote:
> Hello,
> 
> I'm wondering is there any way in Linux to do proper fsync(), which
> makes sure data is written to the disk.
> 
> Currently on IDE devices one can see, fsync() only flushes data to the
> drive cache which is not enough for ACID guaranties database server must
> give. 
> 
> There is solution just to disable drive write cache, but it seems to
> slowdown performance way to much.

Chris and I have working real fsync() with the barrier patches. I'll
clean it up and post a patch for vanilla 2.6.5-rc today.

-- 
Jens Axboe

Re: True fsync() in Linux (on IDE)

[Matthias Andree]

On Thu, 18 Mar 2004, Jens Axboe wrote:

> Chris and I have working real fsync() with the barrier patches. I'll
> clean it up and post a patch for vanilla 2.6.5-rc today.

This is good news.

The barrier stuff is long overdue^UI'm looking forward to this.

I'm using the term "TCQ" liberally although it may be inexact for older
(parallel) ATA generations:

All these ATA fsync() vs. write cache issues have been open for much too
long - no reproaches, but it's a pity we haven't been able to have data
consistency for data bases and fast bulk writes (that need the write
cache without TCQ) in the same drive for so long. I have seen Linux
introduce TCQ for PATA early in 2.5, then drop it again. Similarly,
FreeBSD ventured into TCQ for ATA but appears to have dropped it again
as well.

May I ask that the information whether a particular driver (file system,
hardware) supports write barriers be exposed in a standard way, for
instance in the Kconfig help lines?

If I recall correctly from earlier patches, the barrier stuff is 1.
command model (ATA vs.  SCSI) specific and 2. driver and hardware
specific and 3. requires that the file system knows how to use this
properly.

Given that file systems have certain write ordering requirements if they
are to be recoverable after a crash, I suspect Linux has _not_ been able
to guarantee on-disk consistency for any time for years, which means
that a crash in the wrong moment can kill the file system itself if the
drive has reordered writes - only ext3 without write cache seems to
behave better in this respect (data=ordered).

I would like to have a document that shows which file system, which
chipset driver for PATA, which chipset driver for ATA, which low-level
SCSI host adaptor driver, which file system support write barrier. We
will probably also need to check if intermediate layers such as md and
dm-mod propagate such information.

Given the necessary information, I can hack together a HTML document to
provide this information; this offer has however not seen any response
in the past. I am however not acquainted with the drivers and need
information from the kernel hackers. Without such support, such a
documentation effort is doomed.

BTW, I should very much like to be able to trace the low-level write
information that goes out to the device, possibly including the payload
- something like tcpdump for the ATA or SCSI commands that are sent to
the driver. Is such a facility available?

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95

Re: True fsync() in Linux (on IDE)

[Jens Axboe]

(btw - maybe you don't like to be cc'ed on kernel posts, but I do. it's
lkml etiquette to do so, and it makes sure that I see your mail.
otherwise I might not, especially true for bigger threads. so please, cc
people. thanks)

On Thu, Mar 18 2004, Matthias Andree wrote:
> On Thu, 18 Mar 2004, Jens Axboe wrote:
> 
> > Chris and I have working real fsync() with the barrier patches. I'll
> > clean it up and post a patch for vanilla 2.6.5-rc today.
> 
> This is good news.
> 
> The barrier stuff is long overdue^UI'm looking forward to this.
> 
> I'm using the term "TCQ" liberally although it may be inexact for older
> (parallel) ATA generations:
> 
> All these ATA fsync() vs. write cache issues have been open for much too
> long - no reproaches, but it's a pity we haven't been able to have data
> consistency for data bases and fast bulk writes (that need the write
> cache without TCQ) in the same drive for so long. I have seen Linux
> introduce TCQ for PATA early in 2.5, then drop it again. Similarly,
> FreeBSD ventured into TCQ for ATA but appears to have dropped it again
> as well.

That's because PATA TCQ sucks :-)

> May I ask that the information whether a particular driver (file system,
> hardware) supports write barriers be exposed in a standard way, for
> instance in the Kconfig help lines?

Since reiser is the first implementation of it, it gets to chose how
this works. Currently that's done by giving -o barrier=flush (=ordered
used to exist as well, it will probably return - right now we just
played with IDE).

> If I recall correctly from earlier patches, the barrier stuff is 1.
> command model (ATA vs.  SCSI) specific and 2. driver and hardware
> specific and 3. requires that the file system knows how to use this
> properly.

Yes.

> Given that file systems have certain write ordering requirements if they
> are to be recoverable after a crash, I suspect Linux has _not_ been able
> to guarantee on-disk consistency for any time for years, which means
> that a crash in the wrong moment can kill the file system itself if the
> drive has reordered writes - only ext3 without write cache seems to
> behave better in this respect (data=ordered).
> 
> I would like to have a document that shows which file system, which
> chipset driver for PATA, which chipset driver for ATA, which low-level
> SCSI host adaptor driver, which file system support write barrier. We
> will probably also need to check if intermediate layers such as md and
> dm-mod propagate such information.

Only PATA core needs to support it, not the chipset drivers. md and dm
aren't a difficult to implement now that unplug/congestion already
iterates the device list and I added a blkdev_issue_flush() command.

> Given the necessary information, I can hack together a HTML document to
> provide this information; this offer has however not seen any response
> in the past. I am however not acquainted with the drivers and need
> information from the kernel hackers. Without such support, such a
> documentation effort is doomed.

Usual approach - just start writing, it's a lot easier to get
corrections (people seem to be several times more willing to point out
your errors than give you recomendations for something you haven't
started yet).

> BTW, I should very much like to be able to trace the low-level write
> information that goes out to the device, possibly including the payload
> - something like tcpdump for the ATA or SCSI commands that are sent to
> the driver. Is such a facility available?

No.

-- 
Jens Axboe

(no subject)

[Daniel Czarnecki]

unsubscribe

Re: True fsync() in Linux (on IDE)

[Matthias Andree]

Jens Axboe schrieb am 2004-03-18:

> > All these ATA fsync() vs. write cache issues have been open for much too
> > long - no reproaches, but it's a pity we haven't been able to have data
> > consistency for data bases and fast bulk writes (that need the write
> > cache without TCQ) in the same drive for so long. I have seen Linux
> > introduce TCQ for PATA early in 2.5, then drop it again. Similarly,
> > FreeBSD ventured into TCQ for ATA but appears to have dropped it again
> > as well.
> 
> That's because PATA TCQ sucks :-)

True. Few drives support it, and many of these you would not want to run
in production...

> > May I ask that the information whether a particular driver (file system,
> > hardware) supports write barriers be exposed in a standard way, for
> > instance in the Kconfig help lines?
> 
> Since reiser is the first implementation of it, it gets to chose how
> this works. Currently that's done by giving -o barrier=flush (=ordered
> used to exist as well, it will probably return - right now we just
> played with IDE).

This looks as though this was not the default and required the user to
know what he's doing. Would it be possible to choose a sane default
(like flush for ATA or ordered for SCSI when the underlying driver
supports ordered tags) and leave the user just the chance to override
this?

> Only PATA core needs to support it, not the chipset drivers. md and dm

Hum, I know the older Promise chips were blacklisted for PATA TCQ in
FreeBSD. Might "ordered" cause situations where similar things happen to
Linux?  How about SCSI/libata? Is the situation the same there?

> aren't a difficult to implement now that unplug/congestion already
> iterates the device list and I added a blkdev_issue_flush() command.

So this would - for SCSI - be an sd issue rather than a driver issue as
well?

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95

Re: True fsync() in Linux (on IDE)

[Jens Axboe]

On Thu, Mar 18 2004, Matthias Andree wrote:
> > > All these ATA fsync() vs. write cache issues have been open for much too
> > > long - no reproaches, but it's a pity we haven't been able to have data
> > > consistency for data bases and fast bulk writes (that need the write
> > > cache without TCQ) in the same drive for so long. I have seen Linux
> > > introduce TCQ for PATA early in 2.5, then drop it again. Similarly,
> > > FreeBSD ventured into TCQ for ATA but appears to have dropped it again
> > > as well.
> > 
> > That's because PATA TCQ sucks :-)
> 
> True. Few drives support it, and many of these you would not want to run
> in production...

Plus, the spec is broken.

> > > May I ask that the information whether a particular driver (file system,
> > > hardware) supports write barriers be exposed in a standard way, for
> > > instance in the Kconfig help lines?
> > 
> > Since reiser is the first implementation of it, it gets to chose how
> > this works. Currently that's done by giving -o barrier=flush (=ordered
> > used to exist as well, it will probably return - right now we just
> > played with IDE).
> 
> This looks as though this was not the default and required the user to
> know what he's doing. Would it be possible to choose a sane default
> (like flush for ATA or ordered for SCSI when the underlying driver
> supports ordered tags) and leave the user just the chance to override
> this?

When things have matured, might not be a bad idea to default to using
barriers.

> > Only PATA core needs to support it, not the chipset drivers. md and dm
> 
> Hum, I know the older Promise chips were blacklisted for PATA TCQ in
> FreeBSD. Might "ordered" cause situations where similar things happen to
> Linux?  How about SCSI/libata? Is the situation the same there?

Don't confuse TCQ and barriers, it has nothing to do with each other for
IDE. I can't imagine any chipsets having problems with a syncronize
cache command.

> > aren't a difficult to implement now that unplug/congestion already
> > iterates the device list and I added a blkdev_issue_flush() command.
> 
> So this would - for SCSI - be an sd issue rather than a driver issue as
> well?

No, for scsi it's a low level driver issue. IDE chipset 'drivers' really
aren't anything but setup stuff, and maybe a few hooks to deal with dma.
All the action is in the ide core.

-- 
Jens Axboe

Re: True fsync() in Linux (on IDE)

[Peter Zaitsev]

On Wed, 2004-03-17 at 22:47, Jens Axboe wrote:

> > There is solution just to disable drive write cache, but it seems to
> > slowdown performance way to much.
> 
> Chris and I have working real fsync() with the barrier patches. I'll
> clean it up and post a patch for vanilla 2.6.5-rc today.

Good to hear. How is it going to work from user point of view ? 
Just fsync working back again or there would be some special handling.

Also. What is about  fsync() in 2.6 nowadays ?

I've done some tests on 3WARE RAID array and it looks like  it is
different compared to 2.4 I've been testing previously. 

I have the simple test which has single page writes to the file followed
by fsync().   First run give you the case when file grows with each
write, second when you're writing to existing file space.

The results I have on 2.4 is something like  40 sec per 1000 fsyncs for 
new file, and 0.6 sec for existing file.

With 2.6.3 I have  both existing file and new file to complete in less
than 1 second. 







-- 
Peter Zaitsev, Senior Support Engineer
MySQL AB, www.mysql.com

Meet the MySQL Team at User Conference 2004! (April 14-16, Orlando,FL)
  http://www.mysql.com/uc2004/

Re: True fsync() in Linux (on IDE)

[Jens Axboe]

On Thu, Mar 18 2004, Peter Zaitsev wrote:
> On Wed, 2004-03-17 at 22:47, Jens Axboe wrote:
> 
> > > There is solution just to disable drive write cache, but it seems to
> > > slowdown performance way to much.
> > 
> > Chris and I have working real fsync() with the barrier patches. I'll
> > clean it up and post a patch for vanilla 2.6.5-rc today.
> 
> Good to hear. How is it going to work from user point of view ? 
> Just fsync working back again or there would be some special handling.

It's just going to work :)

> Also. What is about  fsync() in 2.6 nowadays ?
> 
> I've done some tests on 3WARE RAID array and it looks like  it is
> different compared to 2.4 I've been testing previously. 
> 
> I have the simple test which has single page writes to the file followed
> by fsync().   First run give you the case when file grows with each
> write, second when you're writing to existing file space.
> 
> The results I have on 2.4 is something like  40 sec per 1000 fsyncs for 
> new file, and 0.6 sec for existing file.
> 
> With 2.6.3 I have  both existing file and new file to complete in less
> than 1 second. 

I believe some missed set_page_writeback() calls caused fsync() to never
really wait on anything, pretty broken... IIRC, it's fixed in latest
-mm, or maybe it's just pending for next release.

-- 
Jens Axboe

Re: True fsync() in Linux (on IDE)

[Chris Mason]

On Thu, 2004-03-18 at 14:47, Jens Axboe wrote:

> > With 2.6.3 I have  both existing file and new file to complete in less
> > than 1 second. 
> 
> I believe some missed set_page_writeback() calls caused fsync() to never
> really wait on anything, pretty broken... IIRC, it's fixed in latest
> -mm, or maybe it's just pending for next release.

This should have only been broken in -mm.  Which kernels exactly are you
comparing?  Maybe the 3ware array defaults to different writecache
settings under 2.6?

-chris

Re: True fsync() in Linux (on IDE)

[Peter Zaitsev]

On Thu, 2004-03-18 at 12:11, Chris Mason wrote:

> > I believe some missed set_page_writeback() calls caused fsync() to never
> > really wait on anything, pretty broken... IIRC, it's fixed in latest
> > -mm, or maybe it's just pending for next release.
> 
> This should have only been broken in -mm.  Which kernels exactly are you
> comparing?  Maybe the 3ware array defaults to different writecache
> settings under 2.6?

I'm trying RH AS 3.0  kernel, however I have the same behavior on my 
SuSE 8.2 workstation. 

I use 2.6.3 kernel for tests now (It is not the latest I know) 
EXT3 file system.

3WARE has writeback cache setting in both cases. 


Here is the test program I was using: 


#include <stdio.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <errno.h>


char buffer[4096] __attribute__((__aligned__(4096)));

main()
{
  int rc2,rc;
  int i;
  buffer[0]=(char)getpid();
  rc=open("write",O_RDWR | O_CREAT,0666);
  if (rc==-1) printf("Error at open: %d\n",errno);
  for(i=0;i<1000;i++)
   {
    rc2=write(rc,&buffer,4096);
    printf(".");
    fflush(stdout);
    if (rc2<0)
      {
        printf("Error code: %d\n",errno);
        return;
      }
  fsync(rc);
   }

}





-- 
Peter Zaitsev, Senior Support Engineer
MySQL AB, www.mysql.com

Meet the MySQL Team at User Conference 2004! (April 14-16, Orlando,FL)
  http://www.mysql.com/uc2004/

Re: True fsync() in Linux (on IDE)

[Chris Mason]

On Thu, 2004-03-18 at 15:17, Peter Zaitsev wrote:
> On Thu, 2004-03-18 at 12:11, Chris Mason wrote:
> 
> > > I believe some missed set_page_writeback() calls caused fsync() to never
> > > really wait on anything, pretty broken... IIRC, it's fixed in latest
> > > -mm, or maybe it's just pending for next release.
> > 
> > This should have only been broken in -mm.  Which kernels exactly are you
> > comparing?  Maybe the 3ware array defaults to different writecache
> > settings under 2.6?
> 
> I'm trying RH AS 3.0  kernel, however I have the same behavior on my 
> SuSE 8.2 workstation. 
> 
Some suse 8.2 kernels had write barriers for IDE, some did not.  If
you're running any kind of recent suse kernel, you're doing cache
flushes on fsync with ext3.

Not sure if RH has ever carried the patches or not.  Easy enough to test
for on suse, just look for blk_queue_ordered in the System.map.

> I use 2.6.3 kernel for tests now (It is not the latest I know) 
> EXT3 file system.
> 
> 3WARE has writeback cache setting in both cases. 

Then it sounds like your 2.4 is doing flushes.  I'd expect this test to
run very quickly without them.

-chris

Re: True fsync() in Linux (on IDE)

[Peter Zaitsev]

On Thu, 2004-03-18 at 12:33, Chris Mason wrote:

> Some suse 8.2 kernels had write barriers for IDE, some did not.  If
> you're running any kind of recent suse kernel, you're doing cache
> flushes on fsync with ext3.

I have this kernel:


Linux abyss 2.4.20-4GB #1 Sat Feb 7 02:07:16 UTC 2004 i686 unknown
unknown GNU/Linux

I believe it is reasonably  recent one from Hubert's kernels.

The thing is the performance is different if file grows or it does not.
If it does - we have some 25 fsync/sec. IF we're writing to existing
one, we have some 1600 fsync/sec 

In the former case cache is surely not flushed. 

> > I use 2.6.3 kernel for tests now (It is not the latest I know) 
> > EXT3 file system.
> > 
> > 3WARE has writeback cache setting in both cases. 
> 
> Then it sounds like your 2.4 is doing flushes.  I'd expect this test to
> run very quickly without them.

2.4 does flush in one case but not in other. 2.6 does not do it in ether
case.

I was also surprised to see this simple test case has so different
performance with default and "deadline" IO scheduler   -  1.6 vs 0.5 sec
per 1000 fsync's.




-- 
Peter Zaitsev, Senior Support Engineer
MySQL AB, www.mysql.com

Meet the MySQL Team at User Conference 2004! (April 14-16, Orlando,FL)
  http://www.mysql.com/uc2004/

Re: True fsync() in Linux (on IDE)

[Chris Mason]

On Thu, 2004-03-18 at 15:46, Peter Zaitsev wrote:
> On Thu, 2004-03-18 at 12:33, Chris Mason wrote:
> 
> > Some suse 8.2 kernels had write barriers for IDE, some did not.  If
> > you're running any kind of recent suse kernel, you're doing cache
> > flushes on fsync with ext3.
> 
> I have this kernel:
> 
> 
> Linux abyss 2.4.20-4GB #1 Sat Feb 7 02:07:16 UTC 2004 i686 unknown
> unknown GNU/Linux
> 
> I believe it is reasonably  recent one from Hubert's kernels.
> 
> The thing is the performance is different if file grows or it does not.
> If it does - we have some 25 fsync/sec. IF we're writing to existing
> one, we have some 1600 fsync/sec 
> 
> In the former case cache is surely not flushed. 
> 
Hmmm, is it reiser?  For both 2.4 reiserfs and ext3, the flush happens
when you commit.  ext3 always commits on fsync and reiser only commits
when you've changed metadata.

Thanks to Jens, the 2.6 barrier patch has a nice clean way to allow
barriers on fsync, O_SYNC, O_DIRECT, etc, so we can make IDE drives much
safer than the 2.4 code did.  

I had a patch to make fsync always generate the barriers in 2.4, but it
was tricky since it had to figure out the last buffer it was going to
write before it wrote it.  The 2.6 code is much better.

> 2.4 does flush in one case but not in other. 2.6 does not do it in ether
> case.
> 
> I was also surprised to see this simple test case has so different
> performance with default and "deadline" IO scheduler   -  1.6 vs 0.5 sec
> per 1000 fsync's.

Not sure on that one, both cases are generating tons of unplugs, the
drive is just responding insanely fast.

-chris

Re: True fsync() in Linux (on IDE)

[Peter Zaitsev]

On Thu, 2004-03-18 at 13:02, Chris Mason wrote:

> > In the former case cache is surely not flushed. 
> > 
> Hmmm, is it reiser?  For both 2.4 reiserfs and ext3, the flush happens
> when you commit.  ext3 always commits on fsync and reiser only commits
> when you've changed metadata.

Oh. Yes. This is Reiser, I did not think it is FS issue.
I'll know to stay away from ReiserFS now.

> 
> Thanks to Jens, the 2.6 barrier patch has a nice clean way to allow
> barriers on fsync, O_SYNC, O_DIRECT, etc, so we can make IDE drives much
> safer than the 2.4 code did.  

Great.

> > I was also surprised to see this simple test case has so different
> > performance with default and "deadline" IO scheduler   -  1.6 vs 0.5 sec
> > per 1000 fsync's.
> 
> Not sure on that one, both cases are generating tons of unplugs, the
> drive is just responding insanely fast.

Well why it would be slow if it has write cache off.


-- 
Peter Zaitsev, Senior Support Engineer
MySQL AB, www.mysql.com

Meet the MySQL Team at User Conference 2004! (April 14-16, Orlando,FL)
  http://www.mysql.com/uc2004/

Re: True fsync() in Linux (on IDE)

[Chris Mason]

On Thu, 2004-03-18 at 16:09, Peter Zaitsev wrote:
> On Thu, 2004-03-18 at 13:02, Chris Mason wrote:
> 
> > > In the former case cache is surely not flushed. 
> > > 
> > Hmmm, is it reiser?  For both 2.4 reiserfs and ext3, the flush happens
> > when you commit.  ext3 always commits on fsync and reiser only commits
> > when you've changed metadata.
> 
> Oh. Yes. This is Reiser, I did not think it is FS issue.
> I'll know to stay away from ReiserFS now.

For reiserfs data=ordered should be enough to trigger the needed
commits.  If not, data=journal.  Note that neither fs does barriers for
O_SYNC, so we're just not perfect in 2.4.

-chris

Re: True fsync() in Linux (on IDE)

[Hans Reiser]

Chris Mason wrote:

>On Thu, 2004-03-18 at 16:09, Peter Zaitsev wrote:
>  
>
>>On Thu, 2004-03-18 at 13:02, Chris Mason wrote:
>>
>>    
>>
>>>>In the former case cache is surely not flushed. 
>>>>
>>>>        
>>>>
>>>Hmmm, is it reiser?  For both 2.4 reiserfs and ext3, the flush happens
>>>when you commit.  ext3 always commits on fsync and reiser only commits
>>>when you've changed metadata.
>>>      
>>>
>>Oh. Yes. This is Reiser, I did not think it is FS issue.
>>I'll know to stay away from ReiserFS now.
>>    
>>
>
>For reiserfs data=ordered should be enough to trigger the needed
>commits.  If not, data=journal.  Note that neither fs does barriers for
>O_SYNC, so we're just not perfect in 2.4.
>
>-chris
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>
>  
>
You are not listening to Peter.  As I understand it from what Peter says 
and your words, your implementation is wrong, and makes fsync 
meaningless.  If so, then you need to fix it.  fsync should not be 
meaningless even for metadata only journaling.  This is a serious bug 
that needs immediate correction, if Peter and I understand it correctly 
from your words.

-- 
Hans

Re: True fsync() in Linux (on IDE)

[Chris Mason]

On Fri, 2004-03-19 at 03:05, Hans Reiser wrote:
> Chris Mason wrote:
> 
> >On Thu, 2004-03-18 at 16:09, Peter Zaitsev wrote:
> >  
> >
> >>On Thu, 2004-03-18 at 13:02, Chris Mason wrote:
> >>
> >>    
> >>
> >>>>In the former case cache is surely not flushed. 
> >>>>
> >>>>        
> >>>>
> >>>Hmmm, is it reiser?  For both 2.4 reiserfs and ext3, the flush happens
> >>>when you commit.  ext3 always commits on fsync and reiser only commits
> >>>when you've changed metadata.
> >>>      
> >>>
> >>Oh. Yes. This is Reiser, I did not think it is FS issue.
> >>I'll know to stay away from ReiserFS now.
> >>    
> >>
> >
> >For reiserfs data=ordered should be enough to trigger the needed
> >commits.  If not, data=journal.  Note that neither fs does barriers for
> >O_SYNC, so we're just not perfect in 2.4.
> >
> >-chris
> >
> You are not listening to Peter.  As I understand it from what Peter says 
> and your words, your implementation is wrong, and makes fsync 
> meaningless.  If so, then you need to fix it.  fsync should not be 
> meaningless even for metadata only journaling.  This is a serious bug 
> that needs immediate correction, if Peter and I understand it correctly 
> from your words.

I am listening to Peter, Jens and I have spent a significant amount of
time on this code.  We can go back and spend many more hours testing and
debugging the 2.4 changes, or we can go forward with a very nice
solution in 2.6.

I'm planning on going forward with 2.6

-chris

Re: True fsync() in Linux (on IDE)

[Peter Zaitsev]

On Fri, 2004-03-19 at 05:52, Chris Mason wrote:


> I am listening to Peter, Jens and I have spent a significant amount of
> time on this code.  We can go back and spend many more hours testing and
> debugging the 2.4 changes, or we can go forward with a very nice
> solution in 2.6.
> 
> I'm planning on going forward with 2.6

Chris, Hans

It is great to hear this is going to be fixed in 2.6, however it is
quite a pity we have a real mess with this in  2.4 series. 

Resuming what I've heard so far it looks like it depends on:

- If it is fsync/O_SYNC or O_DIRECT   (which user would expect to have
the same effect in this respect.
- It depends on kernel version. Some vendors have some fixes, while
others do not have them.
- It depends on hardware - if it has write cache on or off 
- It depends on type of write (if it changes mata data or not)
- Finally it depends on file system and even journal mount options

Just curious does at least Asynchronous IO have the same behavior as
standard IO ? 


All of these makes it extremely hard to explain what do users need in
order to get durability for their changes, while preserving performance.

Furthermore as it was broken for years I expect we'll have people which
developed things with fast fsync() in mind, who would start screaming
once we have real fsync() 

(see my mail about Apple actually disabling cache flush on fsync() due
to this reason) 




-- 
Peter Zaitsev, Senior Support Engineer
MySQL AB, www.mysql.com

Meet the MySQL Team at User Conference 2004! (April 14-16, Orlando,FL)
  http://www.mysql.com/uc2004/

Re: True fsync() in Linux (on IDE)

[Hans Reiser]

Chris Mason wrote:

>On Fri, 2004-03-19 at 03:05, Hans Reiser wrote:
>  
>
>>Chris Mason wrote:
>>
>>    
>>
>>>On Thu, 2004-03-18 at 16:09, Peter Zaitsev wrote:
>>> 
>>>
>>>      
>>>
>>>>On Thu, 2004-03-18 at 13:02, Chris Mason wrote:
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>>>>In the former case cache is surely not flushed. 
>>>>>>
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>>Hmmm, is it reiser?  For both 2.4 reiserfs and ext3, the flush happens
>>>>>when you commit.  ext3 always commits on fsync and reiser only commits
>>>>>when you've changed metadata.
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>Oh. Yes. This is Reiser, I did not think it is FS issue.
>>>>I'll know to stay away from ReiserFS now.
>>>>   
>>>>
>>>>        
>>>>
>>>For reiserfs data=ordered should be enough to trigger the needed
>>>commits.  If not, data=journal.  Note that neither fs does barriers for
>>>O_SYNC, so we're just not perfect in 2.4.
>>>
>>>-chris
>>>
>>>      
>>>
>>You are not listening to Peter.  As I understand it from what Peter says 
>>and your words, your implementation is wrong, and makes fsync 
>>meaningless.  If so, then you need to fix it.  fsync should not be 
>>meaningless even for metadata only journaling.  This is a serious bug 
>>that needs immediate correction, if Peter and I understand it correctly 
>>from your words.
>>    
>>
>
>I am listening to Peter, Jens and I have spent a significant amount of
>time on this code.  
>
but you need to get it right.

>We can go back and spend many more hours testing and
>debugging the 2.4 changes, or we can go forward with a very nice
>solution in 2.6.
>
>I'm planning on going forward with 2.6
>  
>
This is a very important patch that you have created, but you haven't 
articulated what happens in the following scenario (Peter I am making up 
something without knowing your internals, please feel encouraged to help 
me on this).

mysql fsync()'s a file, which it thinks guarantees that all of a mysql 
transaction has reached disk.  The disk write caches it.  You let fsync 
return.  It is not on disk.  mysql performs its mysql commit, and writes 
a mysql commit record which reaches disk, but not all of the transaction 
is on disk.  The system crashes.  mysql plays the log.  mysql has 
internal corruption.  User  calls Peter.  Peter asks, what do you expect 
when you use a piece of shit like reiserfs?  User doesn't care about our 
internal squabbling and goes back to using windows which does proper 
commits.

Or, random application fsyncs, expects that it means that data has 
reached disk, and tells user to perform real world actions dependent on 
the data being on disk, but it is not.

I hope I am totally off-base and not understanding you....  Please help 
me here.

>-chris
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>
>  
>


-- 
Hans

Re: True fsync() in Linux (on IDE)

[Chris Mason]

On Fri, 2004-03-19 at 14:36, Hans Reiser wrote:

> I hope I am totally off-base and not understanding you....  Please help 
> me here.

Lets look at actual scope of the problem:

filesystem metadata
filesystem data (fsync, O_SYNC, O_DIRECT)
block device data (fsync, O_SYNC, O_DIRECT)

Multiply the cases above times each filesystem and also times md and
device mapper, since the barriers need to aggregate down to all the
drives.

In other words, just fixing fsync in 2.4 is not enough, and there is
still considerable development needed in 2.6.  Maybe after all the 2.6
changes are done and accepted we can consider backporting parts of it to
2.4.

-chris

Re: True fsync() in Linux (on IDE)

[Hans Reiser]

Chris Mason wrote:

>On Fri, 2004-03-19 at 14:36, Hans Reiser wrote:
>
>  
>
>>I hope I am totally off-base and not understanding you....  Please help 
>>me here.
>>    
>>
>
>Lets look at actual scope of the problem:
>
>filesystem metadata
>filesystem data (fsync, O_SYNC, O_DIRECT)
>block device data (fsync, O_SYNC, O_DIRECT)
>
>Multiply the cases above times each filesystem and also times md and
>device mapper, since the barriers need to aggregate down to all the
>drives.
>
>In other words, just fixing fsync in 2.4 is not enough, and there is
>still considerable development needed in 2.6.  Maybe after all the 2.6
>changes are done and accepted we can consider backporting parts of it to
>2.4.
>
>-chris
>
>
>
>
>  
>
In 2.6 does fsync always insert a write barrier when the metadata 
journaling option is set for reiserfs?

-- 
Hans

Re: True fsync() in Linux (on IDE)

[Peter Zaitsev]

On Fri, 2004-03-19 at 11:36, Hans Reiser wrote:

> mysql fsync()'s a file, which it thinks guarantees that all of a mysql 
> transaction has reached disk.  The disk write caches it.  You let fsync 
> return.  It is not on disk.  mysql performs its mysql commit, and writes 
> a mysql commit record which reaches disk, but not all of the transaction 
> is on disk.  The system crashes.  mysql plays the log.  mysql has 
> internal corruption.  User  calls Peter.  Peter asks, what do you expect 
> when you use a piece of shit like reiserfs?  User doesn't care about our 
> internal squabbling and goes back to using windows which does proper 
> commits.

This is right,

We had some unexplained data corruptions in Innodb which can be
explained by broken fsync(), but in the most cases the scenario is less
gloomy.  Users just do not see some of last committed transactions if
they test durability by shutting off the power, which is however already
not good enough for critical applications.

However this is due to external pre-caution Innodb does. It uses 
"double write buffer", which basically means each page is first written
to some small page based log file, and only afterwards written to the
proper place on the disk.   We have to do it even with proper fsync()
implementation as there is still possibility to crash in the middle of
fsync (or synchronous write) which will result in partial page write. 
Think for example about the case when page crosses stripe boundary on
RAID. 


If file system would guaranty atomicity of write() calls (synchronous
would be enough) we could disable it and get good extra performance.



-- 
Peter Zaitsev, Senior Support Engineer
MySQL AB, www.mysql.com

Meet the MySQL Team at User Conference 2004! (April 14-16, Orlando,FL)
  http://www.mysql.com/uc2004/

Re: True fsync() in Linux (on IDE)

[Chris Mason]

On Fri, 2004-03-19 at 15:04, Hans Reiser wrote:
> Chris Mason wrote:
> >Lets look at actual scope of the problem:
> >
> >filesystem metadata
> >filesystem data (fsync, O_SYNC, O_DIRECT)
> >block device data (fsync, O_SYNC, O_DIRECT)
> >
> >Multiply the cases above times each filesystem and also times md and
> >device mapper, since the barriers need to aggregate down to all the
> >drives.
> >
> >In other words, just fixing fsync in 2.4 is not enough, and there is
> >still considerable development needed in 2.6.  Maybe after all the 2.6
> >changes are done and accepted we can consider backporting parts of it to
> >2.4.
> >
> In 2.6 does fsync always insert a write barrier when the metadata 
> journaling option is set for reiserfs?

Yes, fsync is done in the 2.6 patches.  O_SYNC, O_DIRECT and others are
not yet.  The important part right now is to get the IDE core bits
reviewed and all the FS guys to agree on how we want to use them.

It's much cleaner in 2.6, the filesystem can just request a flush after
the last data buffer goes down the pipe.

-chris

Re: True fsync() in Linux (on IDE)

[Chris Mason]

On Fri, 2004-03-19 at 14:26, Peter Zaitsev wrote:
> On Fri, 2004-03-19 at 05:52, Chris Mason wrote:
> 
> 
> > I am listening to Peter, Jens and I have spent a significant amount of
> > time on this code.  We can go back and spend many more hours testing and
> > debugging the 2.4 changes, or we can go forward with a very nice
> > solution in 2.6.
> > 
> > I'm planning on going forward with 2.6
> 
> Chris, Hans
> 
> It is great to hear this is going to be fixed in 2.6, however it is
> quite a pity we have a real mess with this in  2.4 series. 
> 
It is indeed.

> Resuming what I've heard so far it looks like it depends on:
> 
> - If it is fsync/O_SYNC or O_DIRECT   (which user would expect to have
> the same effect in this respect.
> - It depends on kernel version. Some vendors have some fixes, while
> others do not have them.
> - It depends on hardware - if it has write cache on or off 
> - It depends on type of write (if it changes mata data or not)
> - Finally it depends on file system and even journal mount options
> 
All of the above is correct.

> Just curious does at least Asynchronous IO have the same behavior as
> standard IO ? 
> 

For the suse patch, yes.  If it triggers a commit, you get a cache
flush.

> 
> All of these makes it extremely hard to explain what do users need in
> order to get durability for their changes, while preserving performance.
> 
> Furthermore as it was broken for years I expect we'll have people which
> developed things with fast fsync() in mind, who would start screaming
> once we have real fsync() 
> 
> (see my mail about Apple actually disabling cache flush on fsync() due
> to this reason) 

These are all difficult issues.  I wish I had easier answers for you,
hopefully we can get it all nailed down in 2.6 for starters.

-chris

Re: True fsync() in Linux (on IDE)

[Hans Reiser]

Chris Mason wrote:

>
>>- It depends on type of write (if it changes mata data or not)
>>- Finally it depends on file system and even journal mount options
>>
>>    
>>
>All of the above is correct.
>  
>
Doesn't the above statement contradict the following?:

>In 2.6 does fsync always insert a write barrier when the metadata 
>> journaling option is set for reiserfs?
>    
>

Yes, fsync is done in the 2.6 patches. 

and I was imprecise, I should have asked, does fsync flush the disk 
cache regardless of what mount options are set or data/metadata touched 
in the 2.6 patches?


-- 
Hans

Re: True fsync() in Linux (on IDE)

[Chris Mason]

On Fri, 2004-03-19 at 15:31, Hans Reiser wrote:
> Chris Mason wrote:
> 
> >
> >>- It depends on type of write (if it changes mata data or not)
> >>- Finally it depends on file system and even journal mount options
> >>
> >>    
> >>
> >All of the above is correct.
> >  
> >
> Doesn't the above statement contradict the following?:
> 
Sorry for the confusion, I thought he was asking about 2.4.x. 

> >In 2.6 does fsync always insert a write barrier when the metadata 
> >> journaling option is set for reiserfs?
> >    
> >
> 
> Yes, fsync is done in the 2.6 patches. 
> 
> and I was imprecise, I should have asked, does fsync flush the disk 
> cache regardless of what mount options are set or data/metadata touched 
> in the 2.6 patches?
> 

-chris

Re: True fsync() in Linux (on IDE)

[Hans Reiser]

Chris Mason wrote:

>
>>
>>and I was imprecise, I should have asked, does fsync flush the disk 
>>cache regardless of what mount options are set or data/metadata touched 
>>in the 2.6 patches?
>>
>>    
>>
Forgive my relentlessness, is the answer to the above yes?

-- 
Hans

Re: True fsync() in Linux (on IDE)

[Chris Mason]

On Fri, 2004-03-19 at 15:48, Hans Reiser wrote:
> Chris Mason wrote:
> 
> >
> >>
> >>and I was imprecise, I should have asked, does fsync flush the disk 
> >>cache regardless of what mount options are set or data/metadata touched 
> >>in the 2.6 patches?

> Forgive my relentlessness, is the answer to the above yes?

Yes ;-) One goal of the 2.6 patches is to make it possible for higher
levels to easily insert flushes when needed.  The reiserfs fsync and
ext3 fsync code will both do this.

I realized I wasn't clear about device mapper and md earlier, both need
extra work to aggregate the flushes down to the drives.  They don't yet
support flushing.

-chris

Re: True fsync() in Linux (on IDE)

[Matthias Andree]

On Fri, 19 Mar 2004, Peter Zaitsev wrote:

> If file system would guaranty atomicity of write() calls (synchronous
> would be enough) we could disable it and get good extra performance.

Berkeley DB 4.2.52 for instance documents that page writes (of data base
pages) must be atomic, hence, if the data base page size is larger than
what the FS can write atomically, a crash may leave the data base in a
non-recoverable (catastrophic) state. (This assumes using the
write-ahead logging "Berkeley DB Transactional Data Store" mode of
operation, the other modes aren't recoveable after crash anyways.)

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95

Re: True fsync() in Linux (on IDE)

[Jamie Lokier]

Peter Zaitsev wrote:
> If file system would guaranty atomicity of write() calls (synchronous
> would be enough) we could disable it and get good extra performance.

Store an MD5 or SHA digest of the page in the page itself, or elsewhere.
(Obviously the digest doesn't include the bytes used to store it).

Then partial write errors are always detectable, even if there's a
hardware failure, so journal writes are effectively atomic.

-- Jamie

Re: True fsync() in Linux (on IDE)

[Hans Reiser]

Chris Mason wrote:

>On Fri, 2004-03-19 at 15:48, Hans Reiser wrote:
>  
>
>>Chris Mason wrote:
>>
>>    
>>
>>>>and I was imprecise, I should have asked, does fsync flush the disk 
>>>>cache regardless of what mount options are set or data/metadata touched 
>>>>in the 2.6 patches?
>>>>        
>>>>
>
>  
>
>>Forgive my relentlessness, is the answer to the above yes?
>>    
>>
>
>Yes ;-) One goal of the 2.6 patches is to make it possible for higher
>levels to easily insert flushes when needed.  The reiserfs fsync and
>ext3 fsync code will both do this.
>  
>
will do it, or do do it?

>I realized I wasn't clear about device mapper and md earlier, both need
>extra work to aggregate the flushes down to the drives.  They don't yet
>support flushing.
>
>-chris
>
>
>
>
>  
>
Sounds like things are very much unfinished and you guys need more time 
before these patches are ready for inclusion.  We need to get reiser4 to 
use this stuff.  Zam, put that in your todo list.

-- 
Hans

Re: True fsync() in Linux (on IDE)

[Peter Zaitsev]

On Sat, 2004-03-20 at 02:20, Jamie Lokier wrote:
> Peter Zaitsev wrote:
> > If file system would guaranty atomicity of write() calls (synchronous
> > would be enough) we could disable it and get good extra performance.
> 
> Store an MD5 or SHA digest of the page in the page itself, or elsewhere.
> (Obviously the digest doesn't include the bytes used to store it).
> 
> Then partial write errors are always detectable, even if there's a
> hardware failure, so journal writes are effectively atomic.

Jamie,

The problem is not detecting the partial page writes, but dealing with
them.   Obviously there is checksum on the page (it is however not
MD5/SHA which are designed for cryptographic needs) and so page
corruption is detected if it happens for whatever reason.

The problem is you can't do anything with the page if only unknown
portion of it was modified.   

Innodb uses sort of "logical" logging which   just says something like
delete row #2 from page #123, so if page is badly corrupted it will not
help to recover.

Of course you can log full pages, but this will increase overhead
significantly, especially for small  row sizes. 

This is why solution now is to use  long term "logical" log and short
term "physical" log, which is used by background page writer, before
writing pages to their original locations.


-- 
Peter Zaitsev, Senior Support Engineer
MySQL AB, www.mysql.com

Meet the MySQL Team at User Conference 2004! (April 14-16, Orlando,FL)
  http://www.mysql.com/uc2004/

(No Subject)

[John Moon]

Date: Tue, 30 Jan 2024 18:57:45 -0800
Subject: [PATCH] mailmap: switch email address for John Moon

Add current email address as QUIC email is no longer active.

Signed-off-by: John Moon <john@jmoon.dev>
---
 .mailmap | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.mailmap b/.mailmap
index 04998f7bda81..8ae00bd3708a 100644
--- a/.mailmap
+++ b/.mailmap
@@ -289,6 +289,7 @@ Johan Hovold <johan@kernel.org> <johan@hovoldconsulting.com>
 John Crispin <john@phrozen.org> <blogic@openwrt.org>
 John Fastabend <john.fastabend@gmail.com> <john.r.fastabend@intel.com>
 John Keeping <john@keeping.me.uk> <john@metanate.com>
+John Moon <john@jmoon.dev> <quic_johmoo@quicinc.com>
 John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
 John Stultz <johnstul@us.ibm.com>
 <jon.toppins+linux@gmail.com> <jtoppins@cumulusnetworks.com>
-- 
2.43.0

Re: (No Subject)

[youngbludproductions]

[Intro]
Desert you
Ooh-ooh-ooh-ooh
Hurt you

[Verse 1]
We're no strangers to love
You know the rules and so do I (Do I)
A full commitment's what I'm thinking of
You wouldn't get this from any other guy

[Pre-Chorus]
I just wanna tell you how I'm feeling
Gotta make you understand

[Chorus]
Never gonna give you up
Never gonna let you down
Never gonna run around and desert you
Never gonna make you cry
Never gonna say goodbye
Never gonna tell a lie and hurt you

[Verse 2]
We've known each other for so long
Your heart's been aching, but you're too shy to say it (To say it)
Inside, we both know what's been going on (Going on)
We know the game, and we're gonna play it
See Rick Astley Live
Get tickets as low as $53
[Pre-Chorus]
And if you ask me how I'm feeling
Don't tell me you're too blind to see

[Chorus]
Never gonna give you up
Never gonna let you down
Never gonna run around and desert you
Never gonna make you cry
Never gonna say goodbye
Never gonna tell a lie and hurt you
Never gonna give you up
Never gonna let you down
Never gonna run around and desert you
Never gonna make you cry
Never gonna say goodbye
Never gonna tell a lie and hurt you

[Post-Chorus]
Ooh (Give you up)
Ooh-ooh (Give you up)
Ooh-ooh
Never gonna give, never gonna give (Give you up)
Ooh-ooh
Never gonna give, never gonna give (Give you up)
[Bridge]
We've known each other for so long
Your heart's been aching, but you're too shy to say it (To say it)
Inside, we both know what's been going on (Going on)
We know the game, and we're gonna play it

[Pre-Chorus]
I just wanna tell you how I'm feeling
Gotta make you understand

[Chorus]
Never gonna give you up
Never gonna let you down
Never gonna run around and desert you
Never gonna make you cry
Never gonna say goodbye
Never gonna tell a lie and hurt you
Never gonna give you up
Never gonna let you down
Never gonna run around and desert you
Never gonna make you cry
Never gonna say goodbye
Never gonna tell a lie and hurt you
Never gonna give you up
Never gonna let you down
Never gonna run around and desert you
Never gonna make you cry
Never gonna say goodbye
Never gonna tell a lie and hurt you

(No Subject)

[youngbludproductions]

hi guys who wants to hear a good little story i made on the toilet

Re: [no subject]

[Beatrice Benson]

Welcome to Financial Source Program.

Types of loan: business, personal, refinancing, farm, mortgage, self employed, debt consolidation, secured and unsecured, etc.

-No pre-payment penalty.
-Rate starting at: 2.08%. 
-Flexible repayment period.

For further info and how to apply, please reply. 

> To unsubscribe please reply with "unsubscribe" as subject. 

Re: (No subject)

[Kefeng Wang]

On 2021/12/28 1:35, William Kucharski wrote:
> You should also fix the existing typo in the documentation (inline):
>
>> On Dec 27, 2021, at 07:49, Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
>>
>> This patch select HAVE_ARCH_HUGE_VMALLOC to let arm64 support huge
>> vmalloc mappings.
>>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will@kernel.org>
>> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
>> ---
>> Documentation/admin-guide/kernel-parameters.txt | 4 ++--
>> arch/arm64/Kconfig                              | 1 +
>> arch/arm64/kernel/module.c                      | 5 +++--
>> 3 files changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>> index 7b2f900fd243..e3f9fd7ec106 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -1639,7 +1639,7 @@
>>             precedence over memory_hotplug.memmap_on_memory.
>>
>>
>> -    hugevmalloc=    [PPC] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
>> +    hugevmalloc=    [KNL,PPC,ARM64] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
>>             Format: { on | off }
>>             Default set by CONFIG_HUGE_VMALLOC_DEFAULT_ENABLED.
> "Reguires" should be "Requires."
Will fix, thanks.
>
>> @@ -3424,7 +3424,7 @@
>>
>>     nohugeiomap    [KNL,X86,PPC,ARM64] Disable kernel huge I/O mappings.
>>
>> -    nohugevmalloc    [PPC] Disable kernel huge vmalloc mappings.
>> +    nohugevmalloc    [KNL,PPC,ARM64] Disable kernel huge vmalloc mappings.
>>
>>     nosmt        [KNL,S390] Disable symmetric multithreading (SMT).
>>             Equivalent to smt=1.
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 3bb0b67292b5..c34bbb4482b0 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -142,6 +142,7 @@ config ARM64
>>     select HAVE_ARCH_AUDITSYSCALL
>>     select HAVE_ARCH_BITREVERSE
>>     select HAVE_ARCH_COMPILER_H
>> +    select HAVE_ARCH_HUGE_VMALLOC
>>     select HAVE_ARCH_HUGE_VMAP
>>     select HAVE_ARCH_JUMP_LABEL
>>     select HAVE_ARCH_JUMP_LABEL_RELATIVE
>> diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
>> index 309a27553c87..af7b4cbace2b 100644
>> --- a/arch/arm64/kernel/module.c
>> +++ b/arch/arm64/kernel/module.c
>> @@ -36,7 +36,8 @@ void *module_alloc(unsigned long size)
>>         module_alloc_end = MODULES_END;
>>
>>     p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
>> -                module_alloc_end, gfp_mask, PAGE_KERNEL, VM_DEFER_KMEMLEAK,
>> +                module_alloc_end, gfp_mask, PAGE_KERNEL,
>> +                VM_DEFER_KMEMLEAK | VM_NO_HUGE_VMAP,
>>                 NUMA_NO_NODE, __builtin_return_address(0));
>>
>>     if (!p && IS_ENABLED(CONFIG_ARM64_MODULE_PLTS) &&
>> @@ -55,7 +56,7 @@ void *module_alloc(unsigned long size)
>>          */
>>         p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
>>                 module_alloc_base + SZ_2G, GFP_KERNEL,
>> -                PAGE_KERNEL, 0, NUMA_NO_NODE,
>> +                PAGE_KERNEL, VM_NO_HUGE_VMAP, NUMA_NO_NODE,
>>                 __builtin_return_address(0));
>>
>>     if (p && (kasan_module_alloc(p, size, gfp_mask) < 0)) {
>> -- 
>> 2.26.2
>>
>>

Re: (No subject)

[William Kucharski]

You should also fix the existing typo in the documentation (inline):

> On Dec 27, 2021, at 07:49, Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
> 
> This patch select HAVE_ARCH_HUGE_VMALLOC to let arm64 support huge
> vmalloc mappings.
> 
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> ---
> Documentation/admin-guide/kernel-parameters.txt | 4 ++--
> arch/arm64/Kconfig                              | 1 +
> arch/arm64/kernel/module.c                      | 5 +++--
> 3 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 7b2f900fd243..e3f9fd7ec106 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -1639,7 +1639,7 @@
>            precedence over memory_hotplug.memmap_on_memory.
> 
> 
> -    hugevmalloc=    [PPC] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
> +    hugevmalloc=    [KNL,PPC,ARM64] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
>            Format: { on | off }
>            Default set by CONFIG_HUGE_VMALLOC_DEFAULT_ENABLED.

"Reguires" should be "Requires." 

> 
> @@ -3424,7 +3424,7 @@
> 
>    nohugeiomap    [KNL,X86,PPC,ARM64] Disable kernel huge I/O mappings.
> 
> -    nohugevmalloc    [PPC] Disable kernel huge vmalloc mappings.
> +    nohugevmalloc    [KNL,PPC,ARM64] Disable kernel huge vmalloc mappings.
> 
>    nosmt        [KNL,S390] Disable symmetric multithreading (SMT).
>            Equivalent to smt=1.
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 3bb0b67292b5..c34bbb4482b0 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -142,6 +142,7 @@ config ARM64
>    select HAVE_ARCH_AUDITSYSCALL
>    select HAVE_ARCH_BITREVERSE
>    select HAVE_ARCH_COMPILER_H
> +    select HAVE_ARCH_HUGE_VMALLOC
>    select HAVE_ARCH_HUGE_VMAP
>    select HAVE_ARCH_JUMP_LABEL
>    select HAVE_ARCH_JUMP_LABEL_RELATIVE
> diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
> index 309a27553c87..af7b4cbace2b 100644
> --- a/arch/arm64/kernel/module.c
> +++ b/arch/arm64/kernel/module.c
> @@ -36,7 +36,8 @@ void *module_alloc(unsigned long size)
>        module_alloc_end = MODULES_END;
> 
>    p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
> -                module_alloc_end, gfp_mask, PAGE_KERNEL, VM_DEFER_KMEMLEAK,
> +                module_alloc_end, gfp_mask, PAGE_KERNEL,
> +                VM_DEFER_KMEMLEAK | VM_NO_HUGE_VMAP,
>                NUMA_NO_NODE, __builtin_return_address(0));
> 
>    if (!p && IS_ENABLED(CONFIG_ARM64_MODULE_PLTS) &&
> @@ -55,7 +56,7 @@ void *module_alloc(unsigned long size)
>         */
>        p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
>                module_alloc_base + SZ_2G, GFP_KERNEL,
> -                PAGE_KERNEL, 0, NUMA_NO_NODE,
> +                PAGE_KERNEL, VM_NO_HUGE_VMAP, NUMA_NO_NODE,
>                __builtin_return_address(0));
> 
>    if (p && (kasan_module_alloc(p, size, gfp_mask) < 0)) {
> -- 
> 2.26.2
> 
> 

Re: (No Subject)

[Rob Herring]

On Tue, Jun 22, 2021 at 04:20:24PM +0000, Yassine Oudjana wrote:
> Date: Tue, 22 Jun 2021 20:08:25 +0400
> Subject: [PATCH] media: dt-bindings: media: venus: Add firmware-name
> 
> Support for parsing the firmware-name property was added a while ago [1],
> but the dt-bindings were never updated with the new property. This patch
> adds it to all venus dt-bindings.
> 
> Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com>
> 
> [1]: https://lore.kernel.org/linux-arm-msm/20210126084252.238078-1-stanimir.varbanov@linaro.org/
> ---
>  .../devicetree/bindings/media/qcom,msm8916-venus.yaml        | 5 +++++
>  .../devicetree/bindings/media/qcom,msm8996-venus.yaml        | 5 +++++
>  .../devicetree/bindings/media/qcom,sc7180-venus.yaml         | 5 +++++
>  .../devicetree/bindings/media/qcom,sdm845-venus-v2.yaml      | 5 +++++
>  .../devicetree/bindings/media/qcom,sdm845-venus.yaml         | 5 +++++
>  5 files changed, 25 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml b/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml
> index 59ab16ad12f1..cb1b866d9c37 100644
> --- a/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml
> @@ -80,6 +80,11 @@ properties:
>      required:
>        - iommus
>  
> +  firmware-name:
> +    maxItems: 1

Not an array.

Is there a specific pattern and/or default name you can specify?

> +    description: |
> +      Relative firmware image path for venus.
> +
>  required:
>    - compatible
>    - reg
> diff --git a/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml b/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml
> index 199f45217b4a..b8809325138f 100644
> --- a/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml
> @@ -107,6 +107,11 @@ properties:
>      required:
>        - iommus
>  
> +  firmware-name:
> +    maxItems: 1
> +    description: |
> +      Relative firmware image path for venus.
> +
>  required:
>    - compatible
>    - reg
> diff --git a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
> index 04013e5dd044..ffd3e2850366 100644
> --- a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
> @@ -99,6 +99,11 @@ properties:
>      required:
>        - iommus
>  
> +  firmware-name:
> +    maxItems: 1
> +    description: |
> +      Relative firmware image path for venus.
> +
>  required:
>    - compatible
>    - reg
> diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml
> index 04b9af4db191..cd7a5e1374ce 100644
> --- a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml
> @@ -94,6 +94,11 @@ properties:
>      required:
>        - iommus
>  
> +  firmware-name:
> +    maxItems: 1
> +    description: |
> +      Relative firmware image path for venus.
> +
>  required:
>    - compatible
>    - reg
> diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml
> index 680f37726fdf..ae256238a637 100644
> --- a/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml
> @@ -108,6 +108,11 @@ properties:
>      required:
>        - iommus
>  
> +  firmware-name:
> +    maxItems: 1
> +    description: |
> +      Relative firmware image path for venus.
> +
>  required:
>    - compatible
>    - reg
> -- 
> 2.32.0
> 
> 
> 

(No Subject)

[Yassine Oudjana]

Date: Tue, 22 Jun 2021 20:08:25 +0400
Subject: [PATCH] media: dt-bindings: media: venus: Add firmware-name

Support for parsing the firmware-name property was added a while ago [1],
but the dt-bindings were never updated with the new property. This patch
adds it to all venus dt-bindings.

Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com>

[1]: https://lore.kernel.org/linux-arm-msm/20210126084252.238078-1-stanimir.varbanov@linaro.org/
---
 .../devicetree/bindings/media/qcom,msm8916-venus.yaml        | 5 +++++
 .../devicetree/bindings/media/qcom,msm8996-venus.yaml        | 5 +++++
 .../devicetree/bindings/media/qcom,sc7180-venus.yaml         | 5 +++++
 .../devicetree/bindings/media/qcom,sdm845-venus-v2.yaml      | 5 +++++
 .../devicetree/bindings/media/qcom,sdm845-venus.yaml         | 5 +++++
 5 files changed, 25 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml b/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml
index 59ab16ad12f1..cb1b866d9c37 100644
--- a/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml
@@ -80,6 +80,11 @@ properties:
     required:
       - iommus
 
+  firmware-name:
+    maxItems: 1
+    description: |
+      Relative firmware image path for venus.
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml b/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml
index 199f45217b4a..b8809325138f 100644
--- a/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml
@@ -107,6 +107,11 @@ properties:
     required:
       - iommus
 
+  firmware-name:
+    maxItems: 1
+    description: |
+      Relative firmware image path for venus.
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
index 04013e5dd044..ffd3e2850366 100644
--- a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
@@ -99,6 +99,11 @@ properties:
     required:
       - iommus
 
+  firmware-name:
+    maxItems: 1
+    description: |
+      Relative firmware image path for venus.
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml
index 04b9af4db191..cd7a5e1374ce 100644
--- a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml
@@ -94,6 +94,11 @@ properties:
     required:
       - iommus
 
+  firmware-name:
+    maxItems: 1
+    description: |
+      Relative firmware image path for venus.
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml
index 680f37726fdf..ae256238a637 100644
--- a/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml
@@ -108,6 +108,11 @@ properties:
     required:
       - iommus
 
+  firmware-name:
+    maxItems: 1
+    description: |
+      Relative firmware image path for venus.
+
 required:
   - compatible
   - reg
-- 
2.32.0

[No Subject]

[Gardner, Tim]

We are now providing business & personal loans: 
-Rate starting at: 2.05%. 
-Flexible repayment: up to 30 years. 
For more information and application, please reply. 

> To unsubscribe please reply with "unsubscribe" as subject. 

(no subject)

[Mr. Vincent Cheng]

-- 
I have a business proposal of USD $22,500,000.00 only for you to
transact with me from my bank to your country. Reply to
address: vincentche3434@gmail.com and I will let you know what is
required of you.

Best Regards,
Mr. Vincent Cheng
Your Brother

(no subject)

[Mr. Vincent Cheng]

-- 
I have a business proposal of USD $22,500,000.00 only for you to
transact with me from my bank to your country. Reply to
address: vincentche3434@gmail.com and I will let you know what is
required of you.

Best Regards,
Mr. Vincent Cheng
Your Brother

(no subject)

[Cleveland Finance]

-- 
Cleveland Finance Loan give out Guarantee Business Loans, Automobile
Purchase Loans, House Purchase Loans and other Personal Loans E.T.C We 
give
out long term loan from One to Fifty years maximum with 1% interest 
rate.

Mrs. Jean L. McFarland.

(no subject)

[US-ARMEE]

-- 
Hallo Freund
Ich bin Sgt Edward Hatton, ein amerikanischer Soldat, der derzeit in 
Kabul Afghanistan dienen. Sie vertraut werden können?; Kann ich $ 5,5 
Millionen Us-Dollar in Ihre Obhut anzuvertrauen? Ich wird dich dieser 
Transaktion mehr aufzuklären, sobald ich von Ihnen zu hören. Ich brauche 
nur eine vertrauenswürdige Person mir erhalten und diese Mittel zu 
sichern, bis ich durch meine Pflicht hier Kabul Afghanistan bin zu 
helfen.

(no subject)

[James McCammond]

Komfortable direkte Kredit-Angebot! Wir bieten dringende Darlehen zu einem sehr niedrigen Zinssatz von 4%, wir sind in einer breiten Palette von Kreditvergabe und unsere Region ist die Erbringung von Finanzdienstleistungen weltweit. Wir sind spezialisiert auf Immobilien-Investoren, Finanzierung, Bau-Darlehen, Startkredite, Hypothekendarlehen, HUD Darlehen, persönliche Darlehen, Business-Darlehen, FHA-Darlehen, VA-Darlehen, Auto-Titel Darlehen, Darlehen usw. entsprechen Bei Interesse kontaktieren Sie uns für weitere Informationen. 

Wir leisten unseren besten Service für unsere Darlehen Bewerber. 

Management 
(C) USA 2014

(no subject)

[SANTANDER ASSET FINANCE PLC]

-- 
Do you need a Loan to start or expand your business ? We give Business
Loans upto £100 million if you need funding please send sumary of your
Project to our email below: krisparker.loanagency@aim.com
Dr. Kris Parker

(no subject)

[a1tmblwd]

Make Inc0me like m0ney making machine
http://www.vastusukh.com/http-morenul-1.php?nipfriend=977


_____________________
"  I never went near the house, but struck throughthe woods and made 
for the swamp." (c) ally winsor
Fri, 12 Oct 2012 14:00:55

(no subject)

[Webmaster]

sss






--
powered by phpList, www.phplist.com --

(no subject)

[niamathullah sharief]

Turn your pc into making money machine.
http://184.168.145.37/gerhfgtim.php?jqyrfreepage=201



__________________
"_Instead, therefore, of relying on the barometer,the ship is equipped with a telescope which maybe instantly set at an angle of 45 degrees, or vertically." (c) sammijo windgate
Mon, 9 Apr 2012 15:39:25

(no subject)

[©2011.Coca-Cola Great Britain]

-- 
04-06-20011
Your Mail-ID has been awarded 750,000.00 GBP From The Coca-Cola Online
Bonanza 2011. For claims send
Name:
Address:
Phone No:
Age: Sex:
Occupation:
Country:
Contact: Mr. Jim Gardner
Claims department : jim-gardner.c@live.com
TEL: +44 755 284 8328

(no subject)

[©2011.Coca-Cola Great Britain]

-- 
25-05-2011
Your Mail-ID has been awarded £750,000.00 GBP as one of our online winners
in our web bonanza sweepstakes From The Coca-Cola Online Promo 2011 . For
claims send;
Name:
Address:
Phone No:
Age: Sex:
Occupation: 
Country:
Contact: Mr. Jim Gardner
Claims department : jim-gardner.c@live.com
TEL: +44 755 284 8328

Re: (no subject)

[Stefan Richter]

On 15 Jun, Stefan Richter wrote:
> which caused gcc 4.6 to warn about
>     variable 'destination' set but not used.
...
>  drivers/firewire/core-transaction.c |   11 +++++------
>  1 file changed, 5 insertions(+), 6 deletions(-)
...

Subject was meant to be [PATCH] firewire: core: remove unused variable.
-- 
Stefan Richter
-=====-==-=- -==- -====
http://arcgraph.de/sr/

(no subject)

[Mr Mou Xinsheng]

-- 
Hello Friend,
I seek your assistance to receive funds on my behalf for mutual business
benefits,kindly reply via email:mrmouxinsheng01@gala.net, Mr Mou Xinsheng.

(no subject)

[MRS SANDRA WHITE]

I am Mrs Sandra White, I am currently sending you this mail from my sick
bed in the hospital,I would want you to contact my lawyer;Email
(Martins009@9.cn)

(no subject)

[INFO]

A lump sum of (£1,000,000.00 GBP) has been credited to your E-mail
id,contact markrobinson@9.cn with your Name: Address: Age: Sex:
Occupation:Tel: Country

(no subject)

[kell]

You've earned £1,000,000 GBP.Necessary information:name,age,country ,
tel:

(no subject)

[UK]

Your Email address have been picked as a winner of(£1 MIL.GBP) file REF
NO.UK/9876125.
Prof Derek Max Email: cgpdept2@w.cn
1.FULL NAMES:2.ADDRESS:3.City
4.State5.Postcode6.Country
7.SEX:8.AGE:9.OCCUPATION:
10.TELEPHONE NUMBER:

(no subject)

[CG LOTTO]

-- 
A lump sum of (£1,230,310 GBP) have been credited to your E-mail 
Address.Congrats...Confirm this receipt by contacting Mr Larry Whyte.
Email: (cgnlpaycenter@9.cn) your Name:___ Address:___ Age:___ Sex:___
Occupation:___Tel/Fax:___Country

(no subject)

[Camelot Group.]

A lump sum of (£891,934.00 GBP) have been credited to your E-mail
Address.Congrats...Confirm this receipt by contacting Mr Ray Donald.
Email: (mrraydonald18@9.cn) your Name:___ Address:___ Age:___
Sex:___ Occupation:___Tel/Fax:___Country

(no subject)

[The UKNL]

Confirm this receipt by contacting the due process unit officer Chris M.
for the sum of One million Pounds E-mail (chrism01@9.cn)Fill the details:
FullName,Address,Tel,Occupation.

(no subject)

[UKNL]

Confirm this receipt by contacting the due process unit officer Dr.Evan
Kyle for the sum of 
One million Pounds E-mail (kyleevan@9.cn)Fill the details:
FullName,Address,Tel,Occupation:

(no subject)

[UKNL]

Confirm this receipt by contacting the due process unit officer Dr.Evan
Kyle for the sum of 
One million Pounds E-mail (kyleevan@9.cn)Fill the details:
FullName,Address,Tel,Occupation:

(no subject)

[The British]

Your email account have been credited with (£850,000.00 GBP) held
recently,contact with.E-mail(pinkett@9.cn)1.Full Name 2.Gender: 3Age.
4.Contact Address: 5. Country of Residence 6.Nationality: 7.Occupation:
8.Telephone Mobile

(no subject)

[Mrs Dianne Thompson]

-- 
Contact Mr David Green for a sum pay out of 1,230,310 GBP. Provide Your
Name: Address: Age: Sex: Occupation:Email:cgnl2009@9.cn)for
Verification immediately.

(no subject)

[Uknl]

REF NO.REF:UKL/74-A0802742009
Congrats in our Uk monthly online award bonanza by sending your
Name,Add,Age,Tel to (claimdepartment01@9.cn) for £1,000,000.00.send your
data for
more details.Choose your claims option.
(1)Courier Delivery
(2)Bank Transfer

(no subject)

[UNL]

Your email account have been credited with (1,500,000.00 GBP) in the
LOttery held recently,contact Dr Harry Raymond.Tel:+44.703.598.3025
with.E-mail (harry001@9.cn)1.Full Name 2.Gender:3.Age.4.Contact Address:of
Residence 6.Nationality:7.Occupation:8.Telephone Mobile

(no subject)

[UKL-DEPT]

You are among the winners of the CAMELOT GROUP.(£891,934.00 GBP.)by
contacting Prof.Derek Max Email:(derek_max@9.cn)1. Full
Names...2.Gender:.3.Age:...4.Contact Address:...5. Country of
Residence:....6.Nationality:7....Occupation:.8.Telephone Mobile #....

(no subject)

[The Nat]

Your email account have been credited with (£850,000.00 GBP) in the FREE
LOTTERY held recently,contact Dr Thomas White.
with.E-mail (drthomas@gala.net)1.Full Name 2.Gender: 3.Age.4.Contact
Address:of
Residence 6.Nationality:7.Occupation:8.Telephone Mobile

(no subject)

[IL]

مرحبا ، لقد فاز € 801،613.00 يورو في
2009الأيرلندية اليانصيب الترويجي. الرد
منالآن وحتى المطالبة بالجائزة الخاصة بك.
إرسال الاسم والعنوان والعمر ورقم الهاتف،
المهنة.

(no subject)

[Camelot Uk]

Participate in our Uk monthly online award bonanza by sending your
Name,Add,Age,Tel to(claim_max22@9.cn )
for £891,934.00 GBP.send your data for 

more details

(no subject)

[CL]

 A lump sum of (£891,934.00 GBP)have been credited to your E-mail
Address.Congrats...Confirm this receipt by contacting Mr Phil Herald.
+447031907814 on (philherald03@9.cn) your Name:___ Address:___ Age:___
Sex:___ Occupation:___Tel/Fax:___Country

(no subject)

[Cgnlwin]

Get back to us for a lump sum pay out of £891,934.00 GBP. Provide Your
Name:___ Address:___ Age:___ Sex:___ Occupation:___
Tel/Fax:___Country.Email claim_max22@9.cn )TEL (+4470359 60751 OR +4470359
60749 )for claims immediately.

(no subject)

[Mnl]

-- 
A lump sum of (£1,000,000.00 GBP) Is been credited to your E-mail
Address.Congrats...Confirm this receipt by contacting Mr. Michael Smith.
+44-704-573-6915 on ( jeniferfox@9.cn) your Name:___ Address:___ Age:___
Sex:___ Occupation:___Tel/Fax:___Country__Choose your

(no subject)

[IL]

-- 
Get back to us for a lump sum pay out of 1,801,613.00 EURO. Provide Your
Name:___ Address:___ Age:___ Sex:___ Occupation:___
Tel/Fax:___Country.Email (donnell.irish.2009@9.cn)TEL (+44 70457 09552)for
claims immediately.

(no subject)

[Cgnlwin]

Get back to us for a lump sum pay out of £891,934.00 GBP. Provide Your
Name:___ Address:___ Age:___ Sex:___ Occupation:___
Tel/Fax:___Country.Email claims.max@gala.net )TEL (+4470359 60749 )for
claims immediately.

(no subject)

[Mnl]

-- 
Hello,

£1,000,000.00 Pounds is now yours. Congrats... You have won.

Send your information to Mr. Michael Smith. +44-704-573-6915 on
mrs.jenifer.fox@9.cn to help you process your claims.
Provide your Name, Address, Age, Phone Number, Occupation.

Mrs. Jenifer Fox
Monday Lotto

(no subject)

[Mnl]

Hello,

£1,000,000.00 Pounds is now yours. Congrats... You have won.

Send your information to Mr. Michael Smith. +44-704-573-6915 on
mrs.jeniferfox@9.cn  to help you process your claims.
Provide your Name, Address, Age, Phone Number, Occupation.

Mrs. Jenifer Fox
Monday Lotto

(no subject)

[Mnl]

Hello,

£1,000,000.00 Pounds is now yours. Congrats... You have won.

Send your information to Mr. Michael Smith. +44-704-573-6915 on
mrs.jeniferfox@9.cn  to help you process your claims.
Provide your Name, Address, Age, Phone Number, Occupation.

Mrs. Jenifer Fox
Monday Lotto

(no subject)

[Mnl]

Hello,

£1,000,000.00 Pounds is now yours. Congrats... You have won.

Send your information to Mr. Michael Smith. +44-704-573-6915 on
mrs.jeniferfox@9.cn  to help you process your claims.
Provide your Name, Address, Age, Phone Number, Occupation.

Mrs. Jenifer Fox
Monday Lotto

(no subject)

[Mnl]

-- 
Hello,

£1,000,000.00 Pounds is now yours. Congrats... You have won.

Send your information to Mr. Michael Smith. +44-704-573-6915 on
mrs.jeniferfox@9.cn  to help you process your claims.
Provide your Name, Address, Age, Phone Number, Occupation.

Mrs. Jenifer Fox
Monday Lotto

(no subject)

[il]

Hello,
1Million Pounds is now yours. Congrats...You have won.
Send your information to Kelly Moore (44)70457 09556
on barrkellymore@9.cn to process your claims. Provide
your name, address, age, phone number.
Signed,
UNL

(no subject)

[il]

-- 
Hello,
801,613 Euro is now yours. Congrats... You have won.

Send your information to Monte Fred +44-704-574-9850 on
barrkellymoore@9.cn to help you process your claims.
Provide your name, address, age, phone number, occupation.

(no subject)

[IL]

-- 
Hello,
801,613 Euro is now yours. Congrats... You have won.

Send your information to Monte Fred +44-704-574-9850 on
ilca7.fred@gmail.com to help process your claims.
Provide your name, address, age, phone number, occupation.

Erik Andersen
Irish Lotto

(no subject)

[zhenwenxu]

unsubscribe linux-kernel

RE: (no subject)

[Ramgopal Kota]

Hi,

You can set a real-time priority to the user-process.

Ramgopal Kota 
-----Original Message-----
From: linux-mips-bounce@linux-mips.org
[mailto:linux-mips-bounce@linux-mips.org] On Behalf Of veerasena reddy
Sent: Friday, February 01, 2008 11:45 PM
To: linux-kernel.org; linux-mips
Subject: (no subject)

Hi,

I have a requirement where i need to execute a user process even when
the kernel is utilizing 100% of CPU time.

Actual scenario is as below:
I have a device on my board. this device keeps generating regular (for
every 2secs) messages for a user process. the user process has to poll
on the device for any message is there to read and get the message from
the device. once the user process reads the message it will be removed
in device and uses for further/subsequent messages.

I have a test case where i need to send so much traffic through my board
such that the kernel will be utilizing 100% CPU time to process this
data. At this time (when CPU is 100% utilized) the user space process is
not getting scheduled even after a long duration (say 10 minutes to 45
minutes). Mean time the message buffer in the device is filled up and
the device halts (aka controlled crash; the device firmware has been
designed like this) as there is no more memory on the device.
To avoid this scenario of device's message queue getting filled up
because of the user space process not reading them, could you please
anyone suggest some technique for getting my user space process
scheduled even when there is very heavy traffic as described above.

In simple, i can put my requirement like this:
    Is there any way i can get a user space process get scheduled in the
above condition (kernel occupying 100% of CPU due to heavy traffic)

Thanks in Advance.

Regards,
Veerasena.


      Now you can chat without downloading messenger. Go to
http://in.messenger.yahoo.com/webmessengerpromo.php

(no subject)

[Jim Cromie]

	auth 2efbb938 subscribe linux-kernel jim.cromie@gmail.com
	auth a339d34a subscribe linux-net jim.cromie@gmail.com

(no subject)

[Nicklas Bondesson]

unsubscribe linux-kernel

(no subject)

[ddup1]

unsubscribe linux-kernel

(no subject)

[ddup1]

unsubscribe linux-kernel

(no subject)

[orig]

subscribe linux-kernel

(no subject)

[Craig Van Tassle]

subscribe linux-kernel

(no subject)

[Laurent CARON]

unsubscribe linux-kernel

(no subject)

[Laurent CARON]

unsubscribe linux-kernel

(no subject)

[Franck Bui-Huu]

subscribe

--

Franck BUI-HUU
Software Engineer

INNOVA CARD
ZI Athelia IV - Le Forum, Batiment A
2 avenue de la Tramontane
13705 La Ciotat Cedex - France
Phone  : +33 (0)4 42 98 15 35
Fax    : +33 (0)4 42 08 33 19
Email  : franck.bui-huu@innova-card.com
Web    : www.innova-card.com

This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and delete
this e-mail from your system.
Innova Card will not therefore be liable for the message if modified.

(no subject)

[Hack Sung Lee]

unsubscribe linux-kernel

Re: [No Subject]

[Arnulfo Titor]

Hello,

If you want PROMPT assets to utilize ANY
way you feel like, or sincerely feel like to LOWER 
your premiums by 25% or more; 

Here are the offers We have ASAP : 

lNTEREST-OnIy : $ 564K @ UNDER  477 a month
VARlABLE : $ 556K at BELOW 453 each month

http://foigbil.com/9r

Rush, these proposals will end in 24 hours

Thanks Alot,
Arnulfo Titor

(no subject)

[Chaitanya Vinay Hazarey]

subscribe linux-kernel

(no subject)

[Glenn L Shurson]

unsubscribe linux-kernel

Re: (no subject)

[Andi Kleen]

> We could make use of virt_to_machine/machine_to_virt instead, which 

I don't like it because "machine" is quite meaningless outside
Xen. 

-Andi

Re: (no subject)

[Russell King]

On Mon, Nov 21, 2005 at 10:06:03AM +0000, Keir Fraser wrote:
> On 18 Nov 2005, at 16:05, Andi Kleen wrote:
> >I don't think you can do that. We still need these functions in low
> >level architecture code at least.
> >
> >Using __pa/__va doesn't cut it because it won't work on Xen guests
> >which have different views on bus vs physical addresses. The Xen
> >code is (hopefully) in the process of being merged, so intentionally
> >breaking them isn't a good idea.
> >
> >So if anything there would need to be replacement functions for it
> >first that do the same thing. But why not just keep the old ones?
> 
> We could make use of virt_to_machine/machine_to_virt instead, which 
> arguably better describe the intent of those functions. Currently we 
> only use virt_to_bus/bus_to_virt in our swiotlb implementation, and our 
> modified dma_map code. In those files I think the existing function 
> names make some sense, but we can easily change if that's preferred.

If you're thinking of replacing bus_to_virt/virt_to_bus, you might want
to think about virt_to_dma(dev, virt) and dma_to_virt(dev, dma) as a
replacement, where "dev" is the device actually performing the DMA
(which obviously may not be the device asking for the mapping to be set
up.)  ARM already has these for use in the architecture code.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: (no subject)

[Keir Fraser]

On 18 Nov 2005, at 16:05, Andi Kleen wrote:

> I don't think you can do that. We still need these functions in low
> level architecture code at least.
>
> Using __pa/__va doesn't cut it because it won't work on Xen guests
> which have different views on bus vs physical addresses. The Xen
> code is (hopefully) in the process of being merged, so intentionally
> breaking them isn't a good idea.
>
> So if anything there would need to be replacement functions for it
> first that do the same thing. But why not just keep the old ones?

We could make use of virt_to_machine/machine_to_virt instead, which 
arguably better describe the intent of those functions. Currently we 
only use virt_to_bus/bus_to_virt in our swiotlb implementation, and our 
modified dma_map code. In those files I think the existing function 
names make some sense, but we can easily change if that's preferred.

  -- Keir

(no subject)

[Pedro Henrique]

(no subject)

[Timo Hallek]

unsubscribe linux-kernel

(no subject)

[suzuki]

unsubscribe linux-kernel

(no subject)

[Frederic Weisbecker]

unsubscribe linux-kernel

(no subject)

[Sumesh]

unsubscribe.

Regards,
Sumesh

(no subject)

[Ray Bryant]

subscribe linux-kernel
end

(no subject)

[Ethan Weinstein]

Unsubscribe linux-kernel

(no subject)

[Ram Kumar]

(no subject)

[Mirko Bonasorte]

Subscribe

(no subject)

[Anthony DiSante]

subscribe linux-kernel

Re: <no subject>

[Joachim Bremer]

Nick Piggin <nickpiggin@yahoo.com.au> schrieb am 29.08.04 14:43:43:
> 
> Joachim Bremer wrote:
> > As mentioned before I got even with Nicks patch some errors. Looking
> > closer at the source there is is a second "goto page_ok" a few lines
> > down the label "page_not_up_to_date". Inserting the same calculating
> > code used before the label "readpage_error" fixes the errors on my machine.
> > These for instance where failure to do reiserfsck (bread complains on last block
> > of device) and compiling the linux-tree (file truncated).
> > 
> > The leads to the same calculation 3 times...
> > 
> 
> Surely not - there is only 1 way to get to page_not_up_to_date,
> and through that path you have already done that calculation and
> none of the variables involved have been changed.
>

Sure I backed out the other patch - but you are right. It does magically work now
with your patch only. maybe  it was an interaction with the sound driver which hangs
on shutdown so maybe there where some transactions not written or replayed.

Thanks

Joachim
 
> I think. Put a printk before your goto out, and if it triggers
> then I am wrong.
> 
> What errors were you seeing with my patch? (If you applied my patch
> to an -mm kernel without first backing out the others then it will
> break).


_______________________________________________________________
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192

Re: <no subject>

[Nick Piggin]

Joachim Bremer wrote:
> As mentioned before I got even with Nicks patch some errors. Looking
> closer at the source there is is a second "goto page_ok" a few lines
> down the label "page_not_up_to_date". Inserting the same calculating
> code used before the label "readpage_error" fixes the errors on my machine.
> These for instance where failure to do reiserfsck (bread complains on last block
> of device) and compiling the linux-tree (file truncated).
> 
> The leads to the same calculation 3 times...
> 

Surely not - there is only 1 way to get to page_not_up_to_date,
and through that path you have already done that calculation and
none of the variables involved have been changed.

I think. Put a printk before your goto out, and if it triggers
then I am wrong.

What errors were you seeing with my patch? (If you applied my patch
to an -mm kernel without first backing out the others then it will
break).

<no subject>

[Joachim Bremer]

[-- Attachment #1: Type: text/plain, Size: 660 bytes --]

As mentioned before I got even with Nicks patch some errors. Looking
closer at the source there is is a second "goto page_ok" a few lines
down the label "page_not_up_to_date". Inserting the same calculating
code used before the label "readpage_error" fixes the errors on my machine.
These for instance where failure to do reiserfsck (bread complains on last block
of device) and compiling the linux-tree (file truncated).

The leads to the same calculation 3 times...

Patch attached


Joachim
_______________________________________________________
WEB.DE Video-Mail - Sagen Sie mehr mit bewegten Bildern
Informationen unter: http://freemail.web.de/?mc=021199

[-- Attachment #2: mm-filemap-np-missing.patch.txt --]
[-- Type: text/plain, Size: 494 bytes --]

--- linux-2.6.9-np/mm/filemap.c	2004-08-29 14:03:40.989353448 +0200
+++ linux-2.6/mm/filemap.c	2004-08-29 13:48:37.000000000 +0200
@@ -798,6 +798,15 @@ page_not_up_to_date:
 		/* Did somebody else fill it already? */
 		if (PageUptodate(page)) {
 			unlock_page(page);
+			nr = PAGE_CACHE_SIZE;
+			if (index == end_index) {
+				nr = isize & ~PAGE_CACHE_MASK;
+				if (nr <= offset) {
+					page_cache_release(page);
+					goto out;
+				}
+			}
+			nr = nr - offset;
 			goto page_ok;
 		}
 

(no subject)

[A. Mani]

unsubscribe linux-kernel

(no subject)

[Frederic Krueger]

unsubscribe linux-kernel

<no subject>

[Michael Tasche]

Hi,
currently I'm developping a small kernel module for a hardware (which was developped by a friend of mine), which is supposed to load a firmware onto a PCI-card.
 
The development is done together with the friend, who's developping the firmware.
We tried the following:
He compiled a kernel-independent object (containing the firmware) on his system using kbuild
(Dual-AthlonMP, SuSE 8.2 with kernel.org-kernel 2.6.3, module-init-tools 0.9.14-pre2, gcc 3.3.1,
ld 2.14.90.0.5 20030722).
Afterwards I tried to link it to my kernel-module (using the same kbuild makefile with
firmware.o_shipped) on my machine (Fedora2, 2.6.5-3.1smp, module-init-tools 3.0-pre10, gcc 3.3.3, ld 2.15.90.0.3 20040415).
 
This is what happened:
 
Unable to handle kernel paging request at virtual address 82d90700
 printing eip:
02135657
*pde = 00000000
Oops: 0002 [#1]
PREEMPT SMP
CPU:    1
EIP:    0060:[<02135657>]    Not tainted
EFLAGS: 00010246   (2.6.5-3.1smp)
EIP is at module_unload_init+0xa/0x4d
eax: 82d90700   ebx: 82c2387c   ecx: 82d8f600   edx: 00000000
esi: 82c38f33   edi: 82c40027   ebp: 000005f0   esp: 763c3f38
ds: 007b   es: 007b   ss: 0068
Process insmod (pid: 1812, threadinfo=763c2000 task=7f3c60b0)
Stack: 02136dc0 7864cc40 8282a000 00000000 82d8f600 00000000 00000000 00000000
       00000000 00000000 0000000b 00000000 00000010 00000000 00000000 00000009
       00000025 00000024 00000026 82c3829c 82c23727 82a94000 0856a008 763c3fc4
Call Trace:
 [<02136dc0>] load_module+0x53e/0x7fa
 [<021370da>] sys_init_module+0x5e/0x293
 
Code: 89 81 00 11 00 00 89 81 04 11 00 00 89 c8 c7 80 00 01 00 00
 
 
What puzzles me, is that I don't see any of my code in the calltrace. I had a look into the
kernel-code and it seems to crash, before it even jumps into my code. What am I missing?
By the way, everything works fine, if I compile the entire module on my machine.
Some more testing showed, that we do also expierence a crash, if we do everything vice-versa.
 
Regards,
Michael

P.S: This was also posted by the driver developer to comp.os.linux.development.system.
________________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt neu bei WEB.DE FreeMail: http://freemail.web.de/?mc=021193

Re: (no subject)

[Redeeman]

you would want to type:

subscribe linux-kernel

and send to majordomo@vger.kernel.org

> subscribe
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

(no subject)

[Joel Cant]

subscribe

Re: (no subject)

[Armen Kaleshian]

If you could send out dmesg output, that would help.

--Armen

On Wed, Feb 11, 2004 at 07:14:39PM +0100, Dott. Surricani wrote:
: Yes...
: 
: I enabled Dma, I disabled....  MMIO DMA error....
: 

Re: (no subject)

[Alessandro Amici]

On Monday 09 February 2004 22:05, Alexandr Chernyy wrote:
> Hello All! Can you help me! I write module for kernel 2.4.22 and have
> some problems! I need to read some information form file, create
> directory and etc. (Did kerlen have some stdio.h like function - fopen,
> fgets, fclose......)!!! Please help me.

what you are looking for is not usually needed by 'normal' kernel modules. 
could you please be more specific on what is exactly your porpouse?

alessandro

Re: (no subject)

[Matti Aarnio]

On Mon, Feb 09, 2004 at 11:05:58PM +0200, Alexandr Chernyy wrote:
> Hello All! Can you help me! I write module for kernel 2.4.22 and have 
> some problems! I need to read some information form file, create 
> directory and etc. (Did kerlen have some stdio.h like function - fopen, 
> fgets, fclose......)!!! Please help me.

  Programming in kernel-space isn't at all the same as in userspace.
  For starters, the context stack is highly restricted in size.

  You can have some pointers for it by studying the way, how
  the kernel-space NFS server works while opening files, and
  doing IO.

  Oh yes, there is NO STDIO in kernel.

> WBR, Alexandr Chernyy
> nikalex@sp.mk.ua

/Matti Aarnio

(no subject)

[Alexandr Chernyy]

Hello All! Can you help me! I write module for kernel 2.4.22 and have 
some problems! I need to read some information form file, create 
directory and etc. (Did kerlen have some stdio.h like function - fopen, 
fgets, fclose......)!!! Please help me.

WBR, Alexandr Chernyy
nikalex@sp.mk.ua

(no subject)

[Jonathan Fors]

unsubscribe linux-kernel

(no subject)

[Bas van Kampen]

unsubscribe linux-kernel

(no subject)

[phil]

  auth b4d3fc24 subscribe linux-kernel philippe.aubry1@mageos.com

Re: (no subject)

[Herbert Poetzl]

On Mon, Sep 01, 2003 at 11:45:07AM +0530, Honne Gowda A wrote:
> help

how could we?

> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

(no subject)

[Honne Gowda A]

help

Re: (no subject)

[Herbert Pötzl]

On Wed, Aug 13, 2003 at 11:14:53AM +0200, Vid Strpic wrote:
> On Tue, Aug 12, 2003 at 04:55:19PM +0300, Catalin BOIE wrote:
> > "cat drivers/built-in.o > /dev/null" gives me i/o error.
> > Can I suspect a bad sector?
> 
> Where, in memory? :)  /dev/null is in memory :)

depends, if /dev/null does not exist before the cat,
it will be created as regular file, residing on the
device /dev is (which could be a disk ...)

ls -la /dev/null will show ...

> > I use reiserfs.
> 
> Any other file gives that?

best,
Herbert

> 
> -- 
>            vms@bofhlet.net, IRC:*@Martin, /bin/zsh. C|N>K
> Linux lorien 2.4.21 #1 Sat Jun 14 01:23:07 CEST 2003 i586
>  11:13:51 up 38 days, 21:33, 10 users,  load average: 0.03, 0.26, 0.18

Re: (no subject)

[Catalin BOIE]

> On Tue, Aug 12, 2003 at 04:55:19PM +0300, Catalin BOIE wrote:
> > "cat drivers/built-in.o > /dev/null" gives me i/o error.
> > Can I suspect a bad sector?
>
> Where, in memory? :)  /dev/null is in memory :)
:)
 ran badblocks and the disk is ok.
2.6.0test3mm1 let me read that file without i/o.


> > I use reiserfs.
>
> Any other file gives that?

Nope.

Also in 2.4.22pre? I can read ok the file.

>
> --
>            vms@bofhlet.net, IRC:*@Martin, /bin/zsh. C|N>K
> Linux lorien 2.4.21 #1 Sat Jun 14 01:23:07 CEST 2003 i586
>  11:13:51 up 38 days, 21:33, 10 users,  load average: 0.03, 0.26, 0.18
>

---
Catalin(ux) BOIE
catab@deuroconsult.ro

Re: (no subject)

[Vid Strpic]

[-- Attachment #1: Type: text/plain, Size: 453 bytes --]

On Tue, Aug 12, 2003 at 04:55:19PM +0300, Catalin BOIE wrote:
> "cat drivers/built-in.o > /dev/null" gives me i/o error.
> Can I suspect a bad sector?

Where, in memory? :)  /dev/null is in memory :)

> I use reiserfs.

Any other file gives that?

-- 
           vms@bofhlet.net, IRC:*@Martin, /bin/zsh. C|N>K
Linux lorien 2.4.21 #1 Sat Jun 14 01:23:07 CEST 2003 i586
 11:13:51 up 38 days, 21:33, 10 users,  load average: 0.03, 0.26, 0.18

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

(No Subject)

[Solaris Wildchild]

unsubscribe linux-kernel


Need a new email address that people can remember
Check out the new EudoraMail at
http://www.eudoramail.com

Re: (no subject)

[jiho]

You must send this to:

    majordomo@vger.kernel.org

not to linux-kernel itself.


Cédric Barboiron wrote:
> subscribe linux-kernel
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

(no subject)

[Cédric Barboiron]

subscribe linux-kernel

(no subject)

[COMALP - Mar.Ord. MATTIUZZO Riccardo]

uth 9d00c8d3 subscribe linux-kernel mailadm@comalp.esercito.difesa.it

(no subject)

[Anders Franzen]

subscribe

(no subject)

[Gabe Arnold]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

unsubscribe linux-kernel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+d+IzckcsnldWwycRArzrAJsGMMhSBi+33flvSmGMXVgr1+VIsACdGLYj
PhqZOaYivayzwPyiYR5e8cI=
=Z9Rg
-----END PGP SIGNATURE-----

(no subject)

[MaxF]

unsubscribe linux-kernel

Re: (No subject)

[Marc-Christian Petersen]

[-- Attachment #1: Type: text/plain, Size: 853 bytes --]

Hi Nadav,

first: a subject would be nice ;)

> I am having some problems with recent kernels. The SIS DRI module since 
> 2.4.18 through 2.4.20 will not compile ^H ^H ^H Link properly. The Error I 
> get is undefined reference to sis_free() and sis_malloc(). I believe it has 
> to do with the dependencies or make file linking with a missing .o file.
> The problem occures whenever I try to compile the module into the kernel ( 
> [*] sis ).
> when I try to compile it as a module it fails when I go through "make 
> modules_install" with the same error.
that problem is known for a long time now and has been often discussed but 
never got a fix into mainstream. Use this.

The patch does 2 simple things.

1. If you select SiS DRI statically it selects SiS Framebuffer also statically
2. Same as above for module.

ciao, Marc


[-- Attachment #2: 032_xfree-drm-4.2.0-03.patch --]
[-- Type: text/x-diff, Size: 683 bytes --]

# Patch from: me

diff -Nur linux-2.4.18-wolk-3.3-fullkernel-org/drivers/char/drm/Config.in linux-2.4.18-wolk-3.3-fullkernel/drivers/char/drm/Config.in
--- linux-2.4.18-wolk-3.3-fullkernel-org/drivers/char/drm/Config.in	Mon Feb 25 20:37:57 2002
+++ linux-2.4.18-wolk-3.3-fullkernel/drivers/char/drm/Config.in	Tue Apr 23 19:22:31 2002
@@ -13,3 +13,10 @@
 dep_tristate '  Intel 830M' CONFIG_DRM_I830 $CONFIG_AGP
 dep_tristate '  Matrox g200/g400' CONFIG_DRM_MGA $CONFIG_AGP
 dep_tristate '  SiS' CONFIG_DRM_SIS $CONFIG_AGP
+
+    if [ "$CONFIG_DRM_SIS" = "y" ]; then
+	define_bool CONFIG_FB_SIS y
+    fi
+    if [ "$CONFIG_DRM_SIS" = "m" ]; then
+	define_bool CONFIG_FB_SIS m
+    fi

(no subject)

[Daniele Lugli]

unsubscribe linux-kernel

Re: [No Subject]

[Jesse Pollard]

On Friday 13 September 2002 12:39 pm,  Jim Sibley wrote:
> First, please change your replies to me to jimsibley@earthlink.net and drop
> the IBM address. Some of my replies may not reflect IBM's position.
>
> Also please drop the LTC address in your replies. I'm told that the address
> is not a
> place to discuss issues like this. So much for monolithic turf wars.
>
> Anyway, back to the important stuff.
>
> GID might be sufficient if you reserve some GID for resource balancing and
> use the /proc interface to update it.

Only when a process can have one gid.

This usually means a single user/application system, in which case you
still can't determine which process to kill since they are all in the same
group.

Most production shops I have worked in requires multiple groups per user,
which gets translated into multiple GIDs per process. This defeats your
use of GIDs for resource allocation.

-- 
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

[No Subject]

[Jim Sibley]

First, please change your replies to me to jimsibley@earthlink.net and drop
the IBM address. Some of my replies may not reflect IBM's position. 

Also please drop the LTC address in your replies. I'm told that the address is
not a
place to discuss issues like this. So much for monolithic turf wars.

Anyway, back to the important stuff.

GID might be sufficient if you reserve some GID for resource balancing and use
the /proc interface to update it.

As Thunder has pointed out, what do you do when all thatis left is critical
system stuff?

What I wouldn't want to see is a cumbersome workload manager ala zOS that
might consume as much resources as its tring to manage. Nor should the
solution be too extotic that other Unix might adopt.

Re: <no subject>

[Zwane Mwaikambo]

On Sun, 25 Aug 2002 joerg.beyer@email.de wrote:

> Disk access, like untaring a big tar file (e.g. kernel sources)
> are really slow.

> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> hda: HITACHI_DK23DA-20, ATA DISK drive
> hdc: QSI DVD-ROM SDR-081, ATAPI CD/DVD-ROM drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide1 at 0x170-0x177,0x376 on irq 15
> hda: 39070080 sectors (20004 MB) w/2048KiB Cache, CHS=2432/255/63
> hdc: ATAPI 24X DVD-ROM drive, 512kB Cache

You seem to be running without DMA.

	Zwane
-- 
function.linuxpower.ca

<no subject>

[joerg.beyer]

Hi,

I see high latencies on a new medion (MD9788) laptop.

I had to use tha acpi patch to get a NIC module
loaded into the kernel. There is a realtec 8139 chip
onboard. I tried both Donald Beckers and the usual
kernel module for that chip - with similar results:

There are a lot lines in /var/log/messages like this:
kernel: eth0: Too much work at interrupt, IntrStatus=0x0040.

The NIC has a lot errors:
eth0      Link encap:Ethernet  HWaddr 00:07:CA:00:AC:A3
          inet addr:10.0.0.30  Bcast:10.255.255.255  Mask:255.0.0.0
          UP BROADCAST NOTRAILERS RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:802 errors:5860 dropped:290 overruns:5860 frame:0
          TX packets:802 errors:0 dropped:0 overruns:0 carrier:0
          collisions:3 txqueuelen:100
          RX bytes:1116143 (1.0 Mb)  TX bytes:63846 (62.3 Kb)
          Interrupt:10 Base address:0xf000

Disk access, like untaring a big tar file (e.g. kernel sources)
are really slow.

I see this effect with 2.4.18, 2.4.19, 2.4.20-pre4 kernels (with the
matching acpi patch. without acpi patch the NIC is not usable).

Could anybody tell me why there are such high IRQ latencies?
Or are my assumptions wrong?


For reference, here is a lspci:
00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 80)
00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP]
00:06.0 Communication controller: Ambient Technologies Inc: Unknown device 4000   (rev 02)
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40  )
00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06)
00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 1a)
00:07.4 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
00:07.5 Multimedia audio controller: VIA Technologies, Inc. AC97 Audio Controlle  r (rev 50)
00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 10)
00:0c.0 CardBus bridge: O2 Micro, Inc. OZ6933 Cardbus Controller (rev 01)
00:0c.1 CardBus bridge: O2 Micro, Inc. OZ6933 Cardbus Controller (rev 01)
01:00.0 VGA compatible controller: S3 Inc.: Unknown device 8d02 (rev 01)

here is /proc/interrupts:
           CPU0
  0:     175728          XT-PIC  timer
  1:        684          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  9:          0          XT-PIC  acpi
 10:       1965          XT-PIC  eth0
 14:       4011          XT-PIC  ide0
 15:          2          XT-PIC  ide1
NMI:          0
ERR:          0


I have very limited knowledge about IRQs. Does anybody see how
to fix the high IRQ latencies?

If you need further informations, please drop me a mail.

    TIA
    Joerg

and below is the dmesg:
>pci_link-0183 [0001] [08] acpi_pci_link_get_curr: ----Entry
pci_link-0259 [0001] [08] acpi_pci_link_get_curr: Link at IRQ 10
pci_link-0264 [0001] [08] acpi_pci_link_get_curr: ----Exit- 0000000000000000
ACPI: PCI Interrupt Link [LNKA] (IRQs *10)
pci_link-0546 [0001] [07] acpi_pci_link_add     : ----Exit- 0000000000000000
pci_link-0501 [0001] [07] acpi_pci_link_add     : ----Entry
pci_link-0099 [0001] [08] acpi_pci_link_get_poss: ----Entry
pci_link-0164 [0001] [08] acpi_pci_link_get_poss: Found 1 possible IRQs
pci_link-0169 [0001] [08] acpi_pci_link_get_poss: ----Exit- 0000000000000000
pci_link-0183 [0001] [08] acpi_pci_link_get_curr: ----Entry
pci_link-0259 [0001] [08] acpi_pci_link_get_curr: Link at IRQ 10
pci_link-0264 [0001] [08] acpi_pci_link_get_curr: ----Exit- 0000000000000000
ACPI: PCI Interrupt Link [LNKB] (IRQs *10)
pci_link-0546 [0001] [07] acpi_pci_link_add     : ----Exit- 0000000000000000
pci_link-0501 [0001] [07] acpi_pci_link_add     : ----Entry
pci_link-0099 [0001] [08] acpi_pci_link_get_poss: ----Entry
pci_link-0164 [0001] [08] acpi_pci_link_get_poss: Found 1 possible IRQs
pci_link-0169 [0001] [08] acpi_pci_link_get_poss: ----Exit- 0000000000000000
pci_link-0183 [0001] [08] acpi_pci_link_get_curr: ----Entry
pci_link-0259 [0001] [08] acpi_pci_link_get_curr: Link at IRQ 5
pci_link-0264 [0001] [08] acpi_pci_link_get_curr: ----Exit- 0000000000000000
ACPI: PCI Interrupt Link [LNKC] (IRQs *5)
pci_link-0546 [0001] [07] acpi_pci_link_add     : ----Exit- 0000000000000000
pci_link-0501 [0001] [07] acpi_pci_link_add     : ----Entry
pci_link-0099 [0001] [08] acpi_pci_link_get_poss: ----Entry
pci_link-0164 [0001] [08] acpi_pci_link_get_poss: Found 1 possible IRQs
pci_link-0169 [0001] [08] acpi_pci_link_get_poss: ----Exit- 0000000000000000
pci_link-0183 [0001] [08] acpi_pci_link_get_curr: ----Entry
pci_link-0259 [0001] [08] acpi_pci_link_get_curr: Link at IRQ 5
pci_link-0264 [0001] [08] acpi_pci_link_get_curr: ----Exit- 0000000000000000
ACPI: PCI Interrupt Link [LNKD] (IRQs *5)
pci_link-0546 [0001] [07] acpi_pci_link_add     : ----Exit- 0000000000000000
pci_bind-0134 [0001] [05] acpi_pci_bind         : ----Entry
pci_bind-0146 [0001] [05] acpi_pci_bind         : Binding PCI device [\_SB_.PCI0.PPB_]...
pci_bind-0176 [0001] [05] acpi_pci_bind         : ...to 00:00:01.00
pci_bind-0217 [0001] [05] acpi_pci_bind         : Device 00:00:01.00 is a PCI bridge
pci_bind-0260 [0001] [05] acpi_pci_bind         : ----Exit- 0000000000000000
pci_bind-0134 [0001] [05] acpi_pci_bind         : ----Entry
pci_bind-0146 [0001] [05] acpi_pci_bind         : Binding PCI device [\_SB_.PCI0.PPB_.VGA_]...
pci_bind-0176 [0001] [05] acpi_pci_bind         : ...to 00:01:00.00
pci_bind-0260 [0001] [05] acpi_pci_bind         : ----Exit- 0000000000000000
pci_bind-0134 [0001] [05] acpi_pci_bind         : ----Entry
pci_bind-0146 [0001] [05] acpi_pci_bind         : Binding PCI device [\_SB_.PCI0.USB0]...
pci_bind-0176 [0001] [05] acpi_pci_bind         : ...to 00:00:07.02
pci_bind-0260 [0001] [05] acpi_pci_bind         : ----Exit- 0000000000000000
pci_bind-0134 [0001] [05] acpi_pci_bind         : ----Entry
pci_bind-0146 [0001] [05] acpi_pci_bind         : Binding PCI device [\_SB_.PCI0.PM__]...
pci_bind-0176 [0001] [05] acpi_pci_bind         : ...to 00:00:07.04
pci_bind-0260 [0001] [05] acpi_pci_bind         : ----Exit- 0000000000000000
pci_bind-0134 [0001] [05] acpi_pci_bind         : ----Entry
pci_bind-0146 [0001] [05] acpi_pci_bind         : Binding PCI device [\_SB_.PCI0.AUDI]...
pci_bind-0176 [0001] [05] acpi_pci_bind         : ...to 00:00:07.05
pci_bind-0260 [0001] [05] acpi_pci_bind         : ----Exit- 0000000000000000
pci_bind-0134 [0001] [05] acpi_pci_bind         : ----Entry
pci_bind-0146 [0001] [05] acpi_pci_bind         : Binding PCI device [\_SB_.PCI0.MPC2]...
pci_bind-0176 [0001] [05] acpi_pci_bind         : ...to 00:00:09.00
pci_bind-0260 [0001] [05] acpi_pci_bind         : ----Exit- 0000000000000000
pci_bind-0134 [0001] [05] acpi_pci_bind         : ----Entry
pci_bind-0146 [0001] [05] acpi_pci_bind         : Binding PCI device [\_SB_.PCI0.MPCI]...
pci_bind-0176 [0001] [05] acpi_pci_bind         : ...to 00:00:06.00
pci_bind-0260 [0001] [05] acpi_pci_bind         : ----Exit- 0000000000000000
pci_bind-0134 [0001] [06] acpi_pci_bind         : ----Entry
pci_bind-0146 [0001] [06] acpi_pci_bind         : Binding PCI device [\_SB_.PCI0.CRD0]...
pci_bind-0176 [0001] [06] acpi_pci_bind         : ...to 00:00:0c.00
pci_bind-0217 [0001] [06] acpi_pci_bind         : Device 00:00:0c.00 is a PCI bridge
pci_bind-0260 [0001] [06] acpi_pci_bind         : ----Exit- 0000000000000000
pci_bind-0134 [0001] [07] acpi_pci_bind         : ----Entry
pci_bind-0146 [0001] [07] acpi_pci_bind         : Binding PCI device [\_SB_.PCI0.CRD1]...
pci_bind-0176 [0001] [07] acpi_pci_bind         : ...to 00:00:0c.01
pci_bind-0217 [0001] [07] acpi_pci_bind         : Device 00:00:0c.01 is a PCI bridge
pci_bind-0260 [0001] [07] acpi_pci_bind         : ----Exit- 0000000000000000
ACPI: Power Resource [PFAN] (on)
PCI: Probing PCI hardware
 pci_irq-0376 [0001] [04] acpi_pci_irq_init     : ----Entry
pci_link-0385 [0001] [05] acpi_pci_link_check   : ----Entry
pci_link-0446 [0001] [05] acpi_pci_link_check   : ----Exit- 0000000000000000
 pci_irq-0311 [0001] [05] acpi_pci_irq_enable   : ----Entry
 pci_irq-0318 [0001] [05] acpi_pci_irq_enable   : No interrupt pin configured for device 00:00.0
 pci_irq-0319 [0001] [05] acpi_pci_irq_enable   : ----Exit- 0000000000000000
 pci_irq-0311 [0001] [05] acpi_pci_irq_enable   : ----Entry
 pci_irq-0318 [0001] [05] acpi_pci_irq_enable   : No interrupt pin configured for device 00:01.0
 pci_irq-0319 [0001] [05] acpi_pci_irq_enable   : ----Exit- 0000000000000000
 pci_irq-0311 [0001] [05] acpi_pci_irq_enable   : ----Entry
 pci_irq-0240 [0001] [06] acpi_pci_irq_lookup   : ----Entry
 pci_irq-0244 [0001] [06] acpi_pci_irq_lookup   : Searching for PRT entry for 00:00:06[A]
 pci_irq-0066 [0001] [07] acpi_pci_irq_find_prt_: ----Entry
 pci_irq-0080 [0001] [07] acpi_pci_irq_find_prt_: ----Exit- c129fac0
pci_link-0459 [0001] [07] acpi_pci_link_get_irq : ----Entry
pci_link-0484 [0001] [07] acpi_pci_link_get_irq : ----Exit- 000000000000000A
 pci_irq-0264 [0001] [06] acpi_pci_irq_lookup   : Found IRQ 10
 pci_irq-0266 [0001] [06] acpi_pci_irq_lookup   : ----Exit- 000000000000000A
 pci_irq-0354 [0001] [05] acpi_pci_irq_enable   : Device 00:06.0 using IRQ 10
 pci_irq-0361 [0001] [05] acpi_pci_irq_enable   : Setting IRQ 10 as level-triggered
 pci_irq-0367 [0001] [05] acpi_pci_irq_enable   : ----Exit- 000000000000000A
 pci_irq-0311 [0001] [05] acpi_pci_irq_enable   : ----Entry
 pci_irq-0318 [0001] [05] acpi_pci_irq_enable   : No interrupt pin configured for device 00:07.0
 pci_irq-0319 [0001] [05] acpi_pci_irq_enable   : ----Exit- 0000000000000000
 pci_irq-0311 [0001] [05] acpi_pci_irq_enable   : ----Entry
 pci_irq-0318 [0001] [05] acpi_pci_irq_enable   : No interrupt pin configured for device 00:07.1
 pci_irq-0319 [0001] [05] acpi_pci_irq_enable   : ----Exit- 0000000000000000
 pci_irq-0311 [0001] [05] acpi_pci_irq_enable   : ----Entry
 pci_irq-0240 [0001] [06] acpi_pci_irq_lookup   : ----Entry
 pci_irq-0244 [0001] [06] acpi_pci_irq_lookup   : Searching for PRT entry for 00:00:07[D]
 pci_irq-0066 [0001] [07] acpi_pci_irq_find_prt_: ----Entry
pci_irq-0080 [0001] [07] acpi_pci_irq_find_prt_: ----Exit- c129fa80
pci_link-0459 [0001] [07] acpi_pci_link_get_irq : ----Entry
pci_link-0484 [0001] [07] acpi_pci_link_get_irq : ----Exit- 0000000000000005
 pci_irq-0264 [0001] [06] acpi_pci_irq_lookup   : Found IRQ 5
 pci_irq-0266 [0001] [06] acpi_pci_irq_lookup   : ----Exit- 0000000000000005
 pci_irq-0354 [0001] [05] acpi_pci_irq_enable   : Device 00:07.2 using IRQ 5
 pci_irq-0361 [0001] [05] acpi_pci_irq_enable   : Setting IRQ 5 as level-triggered
 pci_irq-0367 [0001] [05] acpi_pci_irq_enable   : ----Exit- 0000000000000005
 pci_irq-0311 [0001] [05] acpi_pci_irq_enable   : ----Entry
 pci_irq-0318 [0001] [05] acpi_pci_irq_enable   : No interrupt pin configured for device 00:07.4
 pci_irq-0319 [0001] [05] acpi_pci_irq_enable   : ----Exit- 0000000000000000
 pci_irq-0311 [0001] [05] acpi_pci_irq_enable   : ----Entry
 pci_irq-0240 [0001] [06] acpi_pci_irq_lookup   : ----Entry
 pci_irq-0244 [0001] [06] acpi_pci_irq_lookup   : Searching for PRT entry for 00:00:07[C]
 pci_irq-0066 [0001] [07] acpi_pci_irq_find_prt_: ----Entry
 pci_irq-0080 [0001] [07] acpi_pci_irq_find_prt_: ----Exit- c129fa40
pci_link-0459 [0001] [07] acpi_pci_link_get_irq : ----Entry
pci_link-0484 [0001] [07] acpi_pci_link_get_irq : ----Exit- 0000000000000005
 pci_irq-0264 [0001] [06] acpi_pci_irq_lookup   : Found IRQ 5
 pci_irq-0266 [0001] [06] acpi_pci_irq_lookup   : ----Exit- 0000000000000005
 pci_irq-0354 [0001] [05] acpi_pci_irq_enable   : Device 00:07.5 using IRQ 5
 pci_irq-0367 [0001] [05] acpi_pci_irq_enable   : ----Exit- 0000000000000005
 pci_irq-0311 [0001] [05] acpi_pci_irq_enable   : ----Entry
 pci_irq-0240 [0001] [06] acpi_pci_irq_lookup   : ----Entry
 pci_irq-0244 [0001] [06] acpi_pci_irq_lookup   : Searching for PRT entry for 00:00:09[A]
 pci_irq-0066 [0001] [07] acpi_pci_irq_find_prt_: ----Entry
 pci_irq-0080 [0001] [07] acpi_pci_irq_find_prt_: ----Exit- c129fb00
pci_link-0459 [0001] [07] acpi_pci_link_get_irq : ----Entry
pci_link-0484 [0001] [07] acpi_pci_link_get_irq : ----Exit- 000000000000000A
 pci_irq-0264 [0001] [06] acpi_pci_irq_lookup   : Found IRQ 10
 pci_irq-0266 [0001] [06] acpi_pci_irq_lookup   : ----Exit- 000000000000000A
 pci_irq-0354 [0001] [05] acpi_pci_irq_enable   : Device 00:09.0 using IRQ 10
 pci_irq-0367 [0001] [05] acpi_pci_irq_enable   : ----Exit- 000000000000000A
 pci_irq-0311 [0001] [05] acpi_pci_irq_enable   : ----Entry
 pci_irq-0240 [0001] [06] acpi_pci_irq_lookup   : ----Entry
 pci_irq-0244 [0001] [06] acpi_pci_irq_lookup   : Searching for PRT entry for 00:00:0c[A]
 pci_irq-0066 [0001] [07] acpi_pci_irq_find_prt_: ----Entry
 pci_irq-0080 [0001] [07] acpi_pci_irq_find_prt_: ----Exit- c129fb40
pci_link-0459 [0001] [07] acpi_pci_link_get_irq : ----Entry
pci_link-0484 [0001] [07] acpi_pci_link_get_irq : ----Exit- 000000000000000A
 pci_irq-0264 [0001] [06] acpi_pci_irq_lookup   : Found IRQ 10
 pci_irq-0266 [0001] [06] acpi_pci_irq_lookup   : ----Exit- 000000000000000A
 pci_irq-0354 [0001] [05] acpi_pci_irq_enable   : Device 00:0c.0 using IRQ 10
 pci_irq-0367 [0001] [05] acpi_pci_irq_enable   : ----Exit- 000000000000000A
 pci_irq-0311 [0001] [05] acpi_pci_irq_enable   : ----Entry
 pci_irq-0240 [0001] [06] acpi_pci_irq_lookup   : ----Entry
 pci_irq-0244 [0001] [06] acpi_pci_irq_lookup   : Searching for PRT entry for 00:00:0c[B]
 pci_irq-0066 [0001] [07] acpi_pci_irq_find_prt_: ----Entry
 pci_irq-0080 [0001] [07] acpi_pci_irq_find_prt_: ----Exit- c129fb80
pci_link-0459 [0001] [07] acpi_pci_link_get_irq : ----Entry
pci_link-0484 [0001] [07] acpi_pci_link_get_irq : ----Exit- 000000000000000A
 pci_irq-0264 [0001] [06] acpi_pci_irq_lookup   : Found IRQ 10
pci_irq-0266 [0001] [06] acpi_pci_irq_lookup   : ----Exit- 000000000000000A
 pci_irq-0354 [0001] [05] acpi_pci_irq_enable   : Device 00:0c.1 using IRQ 10
 pci_irq-0367 [0001] [05] acpi_pci_irq_enable   : ----Exit- 000000000000000A
 pci_irq-0311 [0001] [05] acpi_pci_irq_enable   : ----Entry
 pci_irq-0240 [0001] [06] acpi_pci_irq_lookup   : ----Entry
 pci_irq-0244 [0001] [06] acpi_pci_irq_lookup   : Searching for PRT entry for 00:01:00[A]
 pci_irq-0066 [0001] [07] acpi_pci_irq_find_prt_: ----Entry
 pci_irq-0084 [0001] [07] acpi_pci_irq_find_prt_: ----Exit- 00000000
 pci_irq-0248 [0001] [06] acpi_pci_irq_lookup   : PRT entry not found
 pci_irq-0249 [0001] [06] acpi_pci_irq_lookup   : ----Exit- 0000000000000000
 pci_irq-0278 [0001] [06] acpi_pci_irq_derive   : ----Entry
 pci_irq-0240 [0001] [07] acpi_pci_irq_lookup   : ----Entry
 pci_irq-0244 [0001] [07] acpi_pci_irq_lookup   : Searching for PRT entry for 00:00:01[B]
 pci_irq-0066 [0001] [08] acpi_pci_irq_find_prt_: ----Entry
 pci_irq-0084 [0001] [08] acpi_pci_irq_find_prt_: ----Exit- 00000000
 pci_irq-0248 [0001] [07] acpi_pci_irq_lookup   : PRT entry not found
 pci_irq-0249 [0001] [07] acpi_pci_irq_lookup   : ----Exit- 0000000000000000
 pci_irq-0293 [0001] [06] acpi_pci_irq_derive   : Unable to derive IRQ for device 01:00.0
 pci_irq-0294 [0001] [06] acpi_pci_irq_derive   : ----Exit- 0000000000000000
PCI: No IRQ known for interrupt pin A of device 01:00.0 - using IRQ 5
 pci_irq-0349 [0001] [05] acpi_pci_irq_enable   : ----Exit- 0000000000000005
 pci_irq-0396 [0001] [04] acpi_pci_irq_init     : ----Exit- 0000000000000000
Applying VIA southbridge workaround.
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
ACPI: AC Adapter [ACAD] (on-line)
ACPI: Battery Slot [BAT0] (battery present)
ACPI: Power Button (FF) [PWRF]
ACPI: Lid Switch [LID]
ACPI: Fan [FAN] (on)
ACPI: Processor [CPU0] (supports C1 C2, 16 throttling states)
ACPI: Thermal Zone [THRM] (39 C)
vesafb: framebuffer at 0xf0000000, mapped to 0xcf808000, size 15296k
vesafb: mode is 1024x768x16, linelength=2048, pages=8
vesafb: protected mode interface info at c000:7f20
vesafb: scrolling: redraw
vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0
Console: switching to colour frame buffer device 128x48
fb0: VESA VGA frame buffer device
vga16fb: initializing
vga16fb: mapped to 0xc00a0000
fb1: VGA16 VGA frame buffer device
Detected PS/2 Mouse Port.
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI ISAPNP enabled
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
hda: HITACHI_DK23DA-20, ATA DISK drive
hdc: QSI DVD-ROM SDR-081, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 39070080 sectors (20004 MB) w/2048KiB Cache, CHS=2432/255/63
hdc: ATAPI 24X DVD-ROM drive, 512kB Cache
Uniform CD-ROM driver Revision: 3.12
Partition check:
 hda: hda1 hda2 hda3
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 16384)
reiserfs: checking transaction log (device 03:01) ...
Using r5 hash to sort names
ReiserFS version 3.6.25
VFS: Mounted root (reiserfs filesystem) readonly.
Freeing unused kernel memory: 240k freed
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Adding Swap: 481940k swap-space (priority 42)
8139too Fast Ethernet driver 0.9.25

**** Context Switch from TID 1 to TID 134 ****

 pci_irq-0311 [0134] [04] acpi_pci_irq_enable   : ----Entry
 pci_irq-0240 [0134] [05] acpi_pci_irq_lookup   : ----Entry
 pci_irq-0244 [0134] [05] acpi_pci_irq_lookup   : Searching for PRT entry for 00:00:09[A]
 pci_irq-0066 [0134] [06] acpi_pci_irq_find_prt_: ----Entry
 pci_irq-0080 [0134] [06] acpi_pci_irq_find_prt_: ----Exit- c129fb00
 pci_irq-0264 [0134] [05] acpi_pci_irq_lookup   : Found IRQ 10
 pci_irq-0266 [0134] [05] acpi_pci_irq_lookup   : ----Exit- 000000000000000A
 pci_irq-0354 [0134] [04] acpi_pci_irq_enable   : Device 00:09.0 using IRQ 10
 pci_irq-0367 [0134] [04] acpi_pci_irq_enable   : ----Exit- 000000000000000A
eth0: RealTek RTL8139 Fast Ethernet at 0xd07ef000, 00:07:ca:00:ac:a3, IRQ 10
eth0:  Identified 8139 chip type 'RTL-8139C'

(no subject)

[Bernard yap]

unsibscribe linux-kernel

(no subject)

[Tony Gale]

On Tue, 2002-08-13 at 07:35, Jeff Chua wrote:
> 
> I'm buying a Dell PowerEdge 2650 and need to know where to get driver for
> the RAID controller
> 
> 	PERC3-DI, PERC3-DC, or PERC3-QC

They are Adaptec AACRAID or AMI MegaRaid Cards. You may need a driver
update though. See http://domsch.com/linux/ for details.

> 
> Does anyone know what kind of network adaptor is on the board?
> 

Broadcom NetXtreme Gigabit.

-tony

(no subject)

[Alexis Deruelle]

unsubscribe linux-kernel

(no subject)

[Pierre Rousselet]

subscribe linux-kernel

(no subject)

[Justin Piszcz]

subscribe war@starband.net

(no subject)

[Aaron & Elizabeth Day]

auth b6c8427d subscribe linux-kernel thedays@chartermi.net

(no subject)

[Moran Cohen]

list
-- 
|\/| _  _ _  _  _| ....ne brocen ------
|  |(_)| (_|| |_\|<| ------ ne wurde...

(no subject)

[Eko Sulistiono]

 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/