Re: 2.4 VM & swap question

[Rik van Riel]

On Tue, 19 Jun 2001, Mike Galbraith wrote:
> On Mon, 18 Jun 2001, root wrote:
>
> > Regarding to the discussion on the swap size,
> >
> > Recently, Rick van Riel posted a message that there is a bug
> > related to "reclaiming" the swap, and said that it is on his
> > TODO list.
>
> That's fixed.

It's not. We don't reclaim swap space when we run low on
free swap space (by freeing up the space in swap of stuff
which is in RAM).

regards,

Rik
--
Executive summary of a recent Microsoft press release:
   "we are concerned about the GNU General Public License (GPL)"


http://www.surriel.com/
http://www.conectiva.com/   http://distro.conectiva.com/

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

Re: Simple example of using slab allocator?

[Matthew Dharm]

Well, if it's really that simple

Another aspect of this, tho, is that I'd like to be able to profile my
memory usage.  Does the SA have any ability to report (easily) the number
of pages allocated and how full each one is?

Matt Dharm

On Mon, Jun 18, 2001 at 10:56:36AM -0600, Andreas Dilger wrote:
> Matthew Dharm writes:
> > For 2.5, I'm planning on switching my driver over to the slab allocator,
> > for a variety of reasons.  Does anyone have a _dead_ simple example of how
> > to use such a beast?  I've seen the various web pages and document
> > explaining the API, but I love to see working examples for reference (and
> > to fill in the blanks).
> 
> The slab allocator IS dead simple to use, basically:
> 
> - driver global variable:
> 
> kmem_cache_t *usb_mass_cachep;
>   
> - in the driver init function:
> 
>   usb_mass_cachep = kmem_cache_create("usb_mass_cache",
>   sizeof(struct whatever),
>   0, SLAB_HWCACHE_ALIGN,
>   NULL, NULL);
>   (check for NULL usb_mass_slab)
> 
> - in the driver cleanup function:
> 
>   if (usb_mass_cachep && kmem_cache_destroy(usb_mass_cachep))
>   printk(KERN_ERR "usb_mass_cache: not all structures freed\n");
> 
> - wherever you need an item from the slab cache:
> 
>   whateverp = kmem_cache_alloc(usb_mass_cachep, GFP_KERNEL);
>   (check for NULL whateverp)
> 
> - when you are done with it:
> 
>   kmem_cache_free(usb_mass_cachep, whateverp);
> 
> Notes:
> - if you have a slab leak and you don't free all of the items (hence the slab
>   cache is not removed), you will probably get an oops when you reload the
>   driver.  You can only have one slab cache per name ("usb_mass_cache" here).
> - You may need different alignment (SLAB_HWCACHE_ALIGN), or not
> - You may need different allocation policy (GFP_KERNEL), or not
> 
> Cheers, Andreas
> -- 
> Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
>  \  would they cancel out, leaving him still hungry?"
> http://www-mddsp.enel.ucalgary.ca/People/adilger/   -- Dogbert

-- 
Matthew Dharm  Home: [EMAIL PROTECTED] 
Maintainer, Linux USB Mass Storage Driver

God, root, what is difference?
-- Pitr
User Friendly, 11/11/1999

 PGP signature

Re: Linux 2.4.6-pre3 breaks ReiserFS mount on boot

[Jeff Mahoney]

On Tue, Jun 19, 2001 at 03:31:06PM +1000, Neil Brown wrote:
> On Tuesday June 19, [EMAIL PROTECTED] wrote:
> > On Mon, Jun 18, 2001 at 11:57:16PM -0400, Shawn Starr wrote:
> > > 
> > > read_super_block: can't find a reiserfs filesystem on dev 03:42
> > > read_old_super_block: try to find super block in old location
> > > read_old_super_block: can't find a reiserfs filesystem on dev 03:42
> > > Kernel Panic: VFS: Unable to mount root fs on 03:42
> > > 
> > > my super block broke somewhere?
> > 
> > Out of curiousity, what device are you trying to boot from? 03:42, at least
> > according to linux/Documentation/devices.txt, corresponds to /dev/hda42.
> 
> or, noting that kdevname used hexadecimal, 
>   /dev/hdb2

Ugh. Ignore me, I should've known that.

-Jeff

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

Re: ipchains autoload

[Harald Welte]

On Fri, Jun 08, 2001 at 07:17:22AM +0200, Nico Schottelius wrote:
> Hello!
> 
> I don't really know howto specify that kmod
> should autoload the ipchains module, when I am
> using ipchains.
> 
> Anyone any idea howto tell kmod to load it then ?

there is no way to do that.

The problem is, that ipfwadm / ipchains and iptables use the same 
setsockopt() / getsockopt() based communication between kernel and 
userspace - so the kernel can never know which one of the three you want 
to load.

> Nico

-- 
Live long and prosper
- Harald Welte / [EMAIL PROTECTED]   http://www.gnumonks.org/

GCS/E/IT d- s-: a-- C+++ UL$ P+++ L$ E--- W- N++ o? K- w--- O- M- 
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.4.6-pre3 breaks ReiserFS mount on boot

[Neil Brown]

On Tuesday June 19, [EMAIL PROTECTED] wrote:
> On Mon, Jun 18, 2001 at 11:57:16PM -0400, Shawn Starr wrote:
> > 
> > read_super_block: can't find a reiserfs filesystem on dev 03:42
> > read_old_super_block: try to find super block in old location
> > read_old_super_block: can't find a reiserfs filesystem on dev 03:42
> > Kernel Panic: VFS: Unable to mount root fs on 03:42
> > 
> > my super block broke somewhere?
> 
> Out of curiousity, what device are you trying to boot from? 03:42, at least
> according to linux/Documentation/devices.txt, corresponds to /dev/hda42.

or, noting that kdevname used hexadecimal, 
  /dev/hdb2

NeilBrown

> 
> Is that really the disk you're trying to mount? I'm not familiar with how
> some IDE RAID controllers present disks, but it was the first thing I
> noticed.
> 
> -Jeff
> 
> -- 
> Jeff Mahoney
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4 VM & swap question

[Mike Galbraith]

On Mon, 18 Jun 2001, root wrote:

> Regarding to the discussion on the swap size,
>
> Recently, Rick van Riel posted a message that there is a bug
> related to "reclaiming" the swap, and said that it is on his
> TODO list.

That's fixed.

> If I believe it, the current trouble we have regarding to the swap
> size is not because we do not have a sufficient size for the swap,
> but because there is a bug, although Linus advised us to assign
> 2 times the physical memory for the swap.

Please try 2.4.6.pre3.  (folks with various load types should do this
and report results.. even if it generates a brief spurt of traffic).

-Mike

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

Re: Strange behaviour of swap under 2.4.5-ac15

[Mike Galbraith]

On Mon, 18 Jun 2001, Andrea Arcangeli wrote:

> On Mon, Jun 18, 2001 at 10:37:21AM -0300, Rik van Riel wrote:
> > Yes, this is expected behaviour with -ac14, -pre3 and newer.
>
> If that means anything that doesn't happen here based on pre3.

It doesn't happen here either.  Even with (ever so slightly modified)
fair background aging change.

-Mike

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

Re: Linux 2.4.6-pre3 breaks ReiserFS mount on boot

[Jeff Mahoney]

On Mon, Jun 18, 2001 at 11:57:16PM -0400, Shawn Starr wrote:
> 
> read_super_block: can't find a reiserfs filesystem on dev 03:42
> read_old_super_block: try to find super block in old location
> read_old_super_block: can't find a reiserfs filesystem on dev 03:42
> Kernel Panic: VFS: Unable to mount root fs on 03:42
> 
> my super block broke somewhere?

Out of curiousity, what device are you trying to boot from? 03:42, at least
according to linux/Documentation/devices.txt, corresponds to /dev/hda42.

Is that really the disk you're trying to mount? I'm not familiar with how
some IDE RAID controllers present disks, but it was the first thing I
noticed.

-Jeff

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

Re: Linux 2.4.6-pre3 breaks ReiserFS mount on boot

[Chris Mason]

On Monday, June 18, 2001 11:57:16 PM -0400 Shawn Starr <[EMAIL PROTECTED]>
wrote:

> 
> read_super_block: can't find a reiserfs filesystem on dev 03:42
> read_old_super_block: try to find super block in old location
> read_old_super_block: can't find a reiserfs filesystem on dev 03:42
> Kernel Panic: VFS: Unable to mount root fs on 03:42
> 
> my super block broke somewhere?

Well, this one is usually due to massive corruption or a configuration 
error. Are the correct drives and controllers found during boot?

-chris

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

Re: getrusage vs /proc/pid/stat?

[J . A . Magallon]

On 20010618 Dan Kegel wrote:
>Pete Wyckoff wrote:
>> 
>> [EMAIL PROTECTED] said:
>> > I'd like to monitor CPU, memory, and I/O utilization in a
>> > long-running multithreaded daemon under kernels 2.2, 2.4,
>> > and possibly also Solaris (#ifdefs are ok).
>> 
>> getrusage() isn't really the system call you want for this.
>
>I'll buy that.  Looks like a lot of unices don't implement that
>call fully, and Linux is one of them.
>
>What is the proper way to measure total CPU time used by a multithreaded program?

I have just the same problem. getrusage() did not catch the CPU time for
children, even if the man page said that. Now I am using times(2), that
seems to work in Solaris, but gives nothing in Linux.

I you look at time(1) manpage, it says time is implemented over the times(2)
system call. But if I include that call, it gives me only zero.

This is the output on Solaris:

den:~/ask/tst/cbox0> time box @options
Rendering box.jpg: 64x64

Wall Time::00:00.241
User Time::00:00.600
Sys  Time::00:00.000

real0m0.59s
user0m0.76s
sys 0m0.07s

(user is greater, cause it uses 4 cpus and times is cumulative)

And this is the output on Linux (2.4.5-ac15, glibc2.2.3)

werewolf:~/ask/tst/cbox0> time -p box @options
Rendering box.jpg: 64x64

Wall Time::00:01.299
User Time::00:00.000
Sys  Time::00:00.000
real 1.43
user 2.63
sys 0.02

? time gives good results for summed CPU time, but my own call
to times(2) fails ???

If they can help you (and if you see any error) here is my Timer:

timer.h:

#ifndef AST_TIMER_H
#define AST_TIMER_H

#include 

class __apit Timer
{
protected:
double  wstart,wlast,wnow;
double  ustart,ulast,unow;
double  sstart,slast,snow;
public:
static char*format(double t);
Timer();

void reset();
void update();

double wall();
double user();
double system();

double ewall();
double euser();
double esystem();
};

#endif // AST_TIMER_H 

timer.cc:

#include 
#include 
#include 
#include 
#include 

#ifdef __UNX__
#include 
#include 
#include 
#include 
#endif

//#define USE_GETRUSAGE

char *Timer::format(double t)
{
int h  = int(t/3600);
int m  = int((t-h*3600)/60);
int s  = int(t-h*3600-m*60);
int ms = int(1000*(t-h*3600-m*60-s));

char* str = new char[64];
ostrstream ss(str,64,ios::trunc);
ss << setfill('0');
ss << setw(4) << h;
ss << ":" << setw(2) << m;
ss << ":" << setw(2) << s;
ss << "." << setw(3) << ms;
ss << ends;

return str;
}

Timer::Timer()
{
reset();
}

void Timer::reset()
{
update();

wstart = wnow;
ustart = unow;
sstart = snow;
}

void Timer::update()
{
// Wall clock time
#ifdef __UNX__
struct timeval tv;

gettimeofday(,NULL);
wnow = 1000*tv.tv_sec+1e-3*tv.tv_usec;
#endif
#ifdef __WIN__
wnow = ::time(NULL)*1000;
#endif
#ifdef __MAC__
wnow = ::time(NULL)*1000;
#endif

// CPU User and System times
#ifdef __UNX__
#ifdef USE_GETRUSAGE
struct rusage rus,ruc;
getrusage(RUSAGE_SELF,);
getrusage(RUSAGE_CHILDREN,);

double s,u;

s = rus.ru_utime.tv_sec+ruc.ru_utime.tv_sec;
u = rus.ru_utime.tv_usec+ruc.ru_utime.tv_usec;
unow = 1000*s+1e-3*u;

s = rus.ru_stime.tv_sec+ruc.ru_stime.tv_sec;
u = rus.ru_stime.tv_usec+ruc.ru_stime.tv_usec;
snow = 1000*s+1e-3*u;
#else
struct tms t;
times();

double s;

s = t.tms_utime+t.tms_cutime;
#ifdef __linux__
unow = double(1000*s)/double(sysconf(_SC_CLK_TCK));
#else
unow = double(1000*s)/double(CLK_TCK);
#endif

s = t.tms_stime+t.tms_cstime;
#ifdef __linux__
snow = double(1000*s)/double(sysconf(_SC_CLK_TCK));
#else
snow = double(1000*s)/double(CLK_TCK);
#endif

#endif
#endif
#ifdef __WIN__
unow = ::time(NULL)*1000;
snow = 0;
#endif
#ifdef __MAC__
unow = ::time(NULL)*1000;
snow = 0;
#endif

wlast = wnow;
ulast = unow;
slast = snow;
}

double Timer::wall()
{
update();
return 0.001*(wnow-wstart);
}

double Timer::user()
{
update();
return 0.001*(unow-ustart);
}

double Timer::system()
{
update();
return 0.001*(snow-sstart);
}

double Timer::ewall()
{
double last = wlast;
update();
return 0.001*(wnow-last);
}

double Timer::euser()
{
double last = ulast;
update();
return 0.001*(unow-last);
}

double Timer::esystem()
{
d

Re: spindown [was Re: 2.4.6-pre2, pre3 VM Behavior]

[Mike Galbraith]

On Mon, 18 Jun 2001, Daniel Phillips wrote:

> On Sunday 17 June 2001 12:05, Mike Galbraith wrote:
> > It _juuust_ so happens that I was tinkering... what do you think of
> > something like the below?  (and boy do I ever wonder what a certain
> > box doing slrn stuff thinks of it.. hint hint;)
>
> It's too subtle for me ;-)  (Not shy about sying that because this part of
> the kernel is probably subtle for everyone.)

No subtltry (hammer), it just draws a line that doesn't move around
in unpredictable ways.  For example, nr_free_buffer_pages() adds in
free pages to the line it draws.  You may have a large volume of dirty
data, decide it would be prudent to flush, then someone frees a nice
chunk of memory...  (send morse code messages via malloc/free?:)

Anyway it's crude, but it seems to have gotten results from the slrn
load.  I received logs for ac15 and ac15+patch.  ac15 took 265 seconds
to do the job whereas with the patch it took 227 seconds.  I haven't
poured over the logs yet, but there seems to be throughput to be had.

If anyone is interested in the logs, they're much smaller than expected
-rw-r--r--   1 mikegusers   11993 Jun 19 05:58 ac15_mike.log
-rw-r--r--   1 mikegusers   13015 Jun 19 05:58 ac15_org.log

> The question I'm tackling right now is how the system behaves when the load
> goes away, or doesn't get heavy.  Your patch doesn't measure the load
> directly - it may attempt to predict it as a function of memory pressure, but
> that's a little more loosely coupled than what I had in mind.

It doesn't attempt to predict, it reacts to the existing situation.

> I'm now in the midst of hatching a patch. [1] The first thing I had to do is
> go explore the block driver code, yum yum.  I found that it already computes
> the statistic I'm interested in, namely queued_sectors, which is used to pace
> the IO on block devices.  It's a little crude - we really want this to be
> per-queue and have one queue per "spindle" - but even in its current form
> it's workable.
>
> The idea is that when queued_sectors drops below some threshold we have
> 'unused disk bandwidth' so it would be nice to do something useful with it:

(that's much more subtle/clever:)

>   1) Do an early 'sync_old_buffers'
>   2) Do some preemptive pageout
>
> The benefit of (1) is that it lets disks go idle a few seconds earlier, and
> (2) should improve the system's latency in response to load surges.  There
> are drawbacks too, which have been pointed out to me privately, but they tend
> to be pretty minor, for example: on a flash disk you'd do a few extra writes
> and wear it out ever-so-slightly sooner.  All the same, such special devices
> can be dealt easily once we progress a little further in improving the
> kernel's 'per spindle' intelligence.
>
> Now how to implement this.  I considered putting a (newly minted)
> wakeup_kflush in blk_finished_io, conditional on a loaded-to-unloaded
> transition, and that's fine except it doesn't do the whole job: we also need
> to have the early flush for any write to a disk file while the disks are
> lightly loaded, i.e., there is no convenient loaded-to-unloaded transition to
> trigger it.  The missing trigger could be inserted into __mark_dirty, but
> that would penalize the loaded state (a little, but that's still too much).
> Furthermore, it's probably desirable to maintain a small delay between the
> dirty and the flush.  So what I'll try first is just running kflush's timer
> faster, and make its reschedule period vary with disk load, i.e., when there
> are fewer queued_sectors, kflush looks at the dirty buffer list more often.
>
> The rest of what has to happen in kflush is pretty straightforward.  It just
> uses queued_sectors to determine how far to walk the dirty buffer list, which
> is maintained in time-since-dirtied order.  If queued_sectors is below some
> threshold the entire list is flushed.  Note that we want to change the sense
> of b_flushtime to b_timedirtied.  It's more efficient to do it this way
> anyway.
>
> I haven't done anything about preemptive pageout yet, but similar ideas apply.

Preemptive pageout could be simply walk the dirty list looking for swap
pages and writing them out.  With the fair aging change that's already
in, there will be some.  If the fair aging change to background aging
works out, there will be more (don't want too many more though;).  The
only problem I can see with that simle method is that once written, the
page lands on the inactive_clean list.  That list is short and does get
consumed.. might turn fake pageout into a real one unintentionally.

> [1] This is an experiment, do not worry, it will not show up in your tree any
> time soon.  IOW, constructive criticism appreciated, flames copied to
> /dev/null.

Look forward to seeing it.

-Mike

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  

Re: Linux 2.4.6-pre3 breaks ReiserFS mount on boot

[Shawn Starr]

read_super_block: can't find a reiserfs filesystem on dev 03:42
read_old_super_block: try to find super block in old location
read_old_super_block: can't find a reiserfs filesystem on dev 03:42
Kernel Panic: VFS: Unable to mount root fs on 03:42

my super block broke somewhere?

Shawn.

On Mon, 18 Jun 2001, Shawn Starr wrote:

>
> Two things:
>
> 1) It broke apparently with gcc 2.95.3 when patching from 2.4.6-pre2 ->
> 2.4.6pre3
>
> 2) I tried building it with gcc 3.00 and had same result.
>
> 3) I now have gcc 3.00 and going to rebuild 2.4.6-pre2 and see if reiserfs
> panics if it doesn't there's an issue with the new pre3 modifications.
>
> I hope ReiserFS *MAINTAINS* compatability from slightly older revisions,
> or even migrates systems over to handle new issues.
>
> Shawn.
>
> On Mon, 18 Jun 2001, Olivier Galibert wrote:
>
> > On Mon, Jun 18, 2001 at 10:58:57PM -0400, Shawn Starr wrote:
> > > When diffing 2.4.6-pre2 & pre3 I noticed some reiserfs code was changed.
> > > This seems to cause VFS to panic via reiserfs.
> > >
> > > Anyone else notice this?
> >
> > I don't, and I boot on reiserfs.
> >
> >   OG.
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [EMAIL PROTECTED]
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> >
> >
>
>

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

Re: Linux 2.4.6-pre3 breaks ReiserFS mount on boot

[Chris Mason]

On Monday, June 18, 2001 10:58:57 PM -0400 Shawn Starr
<[EMAIL PROTECTED]> wrote:

> 
> When diffing 2.4.6-pre2 & pre3 I noticed some reiserfs code was
> changed. This seems to cause VFS to panic via reiserfs.
> 
> Anyone else notice this?

What is the panic message?

-chris



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

Re: Linux 2.4.6-pre3 breaks ReiserFS mount on boot

[Shawn Starr]

Two things:

1) It broke apparently with gcc 2.95.3 when patching from 2.4.6-pre2 ->
2.4.6pre3

2) I tried building it with gcc 3.00 and had same result.

3) I now have gcc 3.00 and going to rebuild 2.4.6-pre2 and see if reiserfs
panics if it doesn't there's an issue with the new pre3 modifications.

I hope ReiserFS *MAINTAINS* compatability from slightly older revisions,
or even migrates systems over to handle new issues.

Shawn.

On Mon, 18 Jun 2001, Olivier Galibert wrote:

> On Mon, Jun 18, 2001 at 10:58:57PM -0400, Shawn Starr wrote:
> > When diffing 2.4.6-pre2 & pre3 I noticed some reiserfs code was changed.
> > This seems to cause VFS to panic via reiserfs.
> >
> > Anyone else notice this?
>
> I don't, and I boot on reiserfs.
>
>   OG.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>

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

Re: Linux 2.4.6-pre3 breaks ReiserFS mount on boot

[Olivier Galibert]

On Mon, Jun 18, 2001 at 10:58:57PM -0400, Shawn Starr wrote:
> When diffing 2.4.6-pre2 & pre3 I noticed some reiserfs code was changed.
> This seems to cause VFS to panic via reiserfs.
> 
> Anyone else notice this?

I don't, and I boot on reiserfs.

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

Re: 2.4.5 data corruption

[Stefan Traby]

On Thu, Jun 14, 2001 at 07:20:06PM +0100, Alan Cox wrote:
> > Folks, I believe I have a reproducible test case which corrupts data in
> > 2.4.5.
> 
> 2.4.5 has an out of date 3ware driver that is short

> +   1.02.00.007 - Fix possible null pointer dereferences in tw_ioctl().
> + Remove check for invalid done function pointer from
> + tw_scsi_queue().

hehe, this one keeps the 3dmd from running here at all.

> That might be a first thing to check

Well, I do not understand how the driver is distributed.
The actual 3ware stuff won't compile on 2.4.x, and the stuff in kernel
is always different from 3ware releases.

I use two 8-port cards (8 disks each) and I see different but
fatal problems on both systems.

Is anyone here using an actual firmware and raid-5 ?
Does it work up to some level on 6800 ?

Anyway, a useful proc-interface would be really cool
(like DAC); I guess that many people would love to get rid
of the - sorry - fucking closed sourced and totally broken 3dmd
which makes an extremly nice product totally useless (you can't
trust it; not only because it's closed source, it simply doesn't
work (except that it wastes memory, that works fine. tested.))

-- 

  ciao - 
Stefan

" destroy-your-data-by-3dmd-no-need-for-hammer-anymore CNAME www.3ware.com. "
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Linux 2.4.6-pre3 breaks ReiserFS mount on boot

[Shawn Starr]

When diffing 2.4.6-pre2 & pre3 I noticed some reiserfs code was changed.
This seems to cause VFS to panic via reiserfs.

Anyone else notice this?

Shawn.

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

Re: gnu asm help...

[Rick Hohensee]

The C-names-in-asms stuff is explained in (g?)as.info. The explanation is
a bit strained, but after the third or fourth read it becomes fairly
sensible.


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

Re: Client receives TCP packets but does not ACK

[dean gaudet]

On Tue, 19 Jun 2001, Jonathan Morton wrote:

> >  > >  > Btw: can the aplication somehow ask the tcp/ip stack what was
> >>  >actualy acked?
> >>  >>  (ie. how many bytes were acked).
> >>  >
> >>  >no, but it's not necessarily a useful number anyhow -- because it's
> >>  >possible that the remote end ACKd bytes but the ACK never arrives.  so you
> >>  >can get into a situation where the remote application has the entire
> >>  >message but the local application doesn't know.  the only way to solve
> >>  >this is above the TCP layer.  (message duplicate elimination using an
> >>  >unique id.)
> >>
> >>  No, because if the ACK doesn't reach the sending machine, the sender
> >>  will retry the data until it does get an ACK.
> >
> >if the network goes down in between, the sender may never get the ACK.
> >the sender will see a timeout eventually.  the receiver may already be
> >done with the connection and closed it and never see the error.  if it
> >were a protocol such as SMTP then the sender would retry later, and the
> >result would be a duplicate message.  (which you can eliminate above the
> >TCP layer using unique ids.)
>
> But, if the sender does not attempt to close the socket until the ACK
> returns, then the receiver will see an unfinished connection and
> (hopefully) realise that the message is unsafe and not attempt to
> send it.

suppose the network goes away and doesn't come back.  the ACK never gets
through.

> With SMTP, the last piece of data is a QUIT anyway, which occurs
> after the end-of-message marker - once the QUIT is sent and/or
> received, both ends know that the connection is finished with and
> will close the socket independently of each other.  If the network
> disappears before the QUIT comes along, the receiver should be
> discarding messages and the sender retrying later.

QUIT is the last step of a session which can include multiple messages. a
single message begins with the "MAIL FROM:" and ends with the . that
terminates the DATA section.  after that the smtp server sends back the
"250 OK".  the smtp client is now free to sit on the connection "forever",
possibly beginning another "MAIL FROM:".  (i.e. connection caching in
sendmail.)

but in the meanwhile, the smtp server has moved the message into its next
phase of delivery as soon as it sends back the "250 OK", which could
include having forwarded it off the box, or to a mailing list, etc.

so in this example where you want to consider network failure is after the
smtp client has sent the trailing "." closing the DATA section, and that
data has been received by the smtp server.  then the network fails before
the ACK (and "250 OK") returns to the smtp client.

in this case the client has no choice but to resend later.  (both sides
should get an error eventually assuming the implementors don't suck,
unlike in some other protocols such as HTTP/0.9 and HTTP/1.0 where the
protocol itself is flawed.)  the result is probably a message duplicate.

so what you were asking about was, what if the smtp server in this case
could find out that the "250 OK" was never ACKd.  in that case just move
the network failure a little later in the series of events... and also
consider cases where the TCP stack ACKs but the application never gets to
read() the data (system failures).

basically these transactional semantics have to occur above TCP/IP itself.
this is where QUIT comes in.  and to some extent, message-IDs for
duplicate elimination.  (in HTTP/1.1 the introduction of chunked transfer
encoding to handle variable length dynamic responses in the face of
network failures... but folks building web forms still need to put
unique-ids into the forms to handle the duplicate message problem.)

i guess knowing the number of ACK'd bytes might be a useful debugging aid,
but i'd fear it being misused by app writers.

-dean

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

Re: Why can't I flush /dev/ram0?

[Kelledin Tane]

> > When I mount the filesystem to check it out, nothing appears to have
> > anything open on the filesystem.  So why am I not able to flush it
> > clean?
>
> Because of a bug present in Linus tree. Try this patch:

Thanks, that seems to have fixed it.  There's something else I'm curious about
though...

Before, when I was having this problem, I would check mem usage, and there would
be about 5MB of physical memory marked for "buffers" (I assume 4MB for ram0).

Now, using an identical kernel configuration, an identical module set loaded,
and a roughly identical process table, there's about 18MB of memory marked for
"buffers!"

Sorry to be a bother, but I can't help wondering if this patch might have gotten
rid of one problem and replaced it with another?  Or maybe I'm missing some
other detail here...

Kelledin

bash-2.05 $ kill -9 1
init: Just what do you think you're doing, Dave?

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

Re: i810 audio problem

[Michael]

"Delio Brignoli" <[EMAIL PROTECTED]> writes:
> Switching from 2.4.2 to 2.4.5 breaks i810_audio on my intel MX440 based notebook:
> 
> After some (in fact a few) seconds of playback it gets stuck until the app closes 
>and reopens /dev/dsp. (I do NOT use esd)
[..] 
> It goes on until I kill the app, then it says:
> 
> Jun 18 13:59:42 argo kernel: i810_audio: drain_dac, dma timeout?
> 
> Any idea(s), suggestions ...

What a co-incidence. I just hit this problem a few days ago.

The problem here is that:
1.  the dma buffer drains to zero.
2.  interrupt handler set LVI to CIV.
3.  app write more than a buffer size of data to dma buffer.
4.  LVI is un-changed!

There's a kludgey work-around I used, (never use more than
31 segments of the DMA buffer). (I.e. never use the last
dmabuf->fragsize of the dma buffer). This cures the hang
but it isn't an optimal solutions.

--- i810_audio.c.oldTue Jun 19 11:22:56 2001
+++ i810_audio.cTue Jun 19 11:24:02 2001
@@ -1194,6 +1194,10 @@
cnt = dmabuf->dmasize - swptr;
if(cnt > (dmabuf->dmasize - dmabuf->count))
cnt = dmabuf->dmasize - dmabuf->count;
+   
+   if (cnt >= dmabuf->fragsize && (dmabuf->count + cnt) >= 
+dmabuf->dmasize)
+   cnt -= dmabuf->fragsize; 
+   
spin_unlock_irqrestore(>card->lock, flags);

if (cnt > count)


A better fix _may_ be to set CIV to LVI instead of the other way
around. (This assumes CIV is writeable). No testing at all;
may not be a fix. 

Something like:

diff -u i810_audio.c.old i810_audio.c
--- i810_audio.c.oldTue Jun 19 11:22:56 2001
+++ i810_audio.cTue Jun 19 11:26:14 2001
@@ -807,11 +807,11 @@
 * means no data on read, handle appropriately
 */
if(!rec && dmabuf->count == 0) {
-   outb(inb(port+OFF_CIV),port+OFF_LVI);
+   outb(inb(port+OFF_LVI),port+OFF_CIV);
return;
}
if(rec && dmabuf->count == dmabuf->dmasize) {
-   outb(inb(port+OFF_CIV),port+OFF_LVI);
+   outb(inb(port+OFF_LVI),port+OFF_CIV);
return;
}
/* swptr - 1 is the tail of our transfer */

but with testing and a glance at the docs. :)


Michael.



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

Re: Client receives TCP packets but does not ACK

[Jonathan Morton]

>  > >  > Btw: can the aplication somehow ask the tcp/ip stack what was
>>  >actualy acked?
>>  >>  (ie. how many bytes were acked).
>>  >
>>  >no, but it's not necessarily a useful number anyhow -- because it's
>>  >possible that the remote end ACKd bytes but the ACK never arrives.  so you
>>  >can get into a situation where the remote application has the entire
>>  >message but the local application doesn't know.  the only way to solve
>>  >this is above the TCP layer.  (message duplicate elimination using an
>>  >unique id.)
>>
>>  No, because if the ACK doesn't reach the sending machine, the sender
>>  will retry the data until it does get an ACK.
>
>if the network goes down in between, the sender may never get the ACK.
>the sender will see a timeout eventually.  the receiver may already be
>done with the connection and closed it and never see the error.  if it
>were a protocol such as SMTP then the sender would retry later, and the
>result would be a duplicate message.  (which you can eliminate above the
>TCP layer using unique ids.)

But, if the sender does not attempt to close the socket until the ACK 
returns, then the receiver will see an unfinished connection and 
(hopefully) realise that the message is unsafe and not attempt to 
send it.

With SMTP, the last piece of data is a QUIT anyway, which occurs 
after the end-of-message marker - once the QUIT is sent and/or 
received, both ends know that the connection is finished with and 
will close the socket independently of each other.  If the network 
disappears before the QUIT comes along, the receiver should be 
discarding messages and the sender retrying later.
-- 
--
from: Jonathan "Chromatix" Morton
mail: [EMAIL PROTECTED]  (not for attachments)
website:  http://www.chromatix.uklinux.net/vnc/
geekcode: GCS$/E dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$
   V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
tagline:  The key to knowledge is not to rely on people to teach you it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: What happened to lookup_dentry?

[Alexander Viro]

On Mon, 18 Jun 2001, Timur Tabi wrote:

> I'm porting a driver from 2.2 to 2.4, and this driver calls lookup_dentry,
> which doesn't exist in 2.4.  I've read through the source code and searched the
> web and newsgroups, and I can't find any explanation as to why lookup_dentry no
> longer exists or how I'm supposed to change code that uses it.  Can anyone help
> me?

It depends on what kind of use 2.2 code had for it. There are several
situations in which it used to be called and proper replacements depend
on the context. Details, please... (alternatively, send an URL of patch
and I'll see what to do with the thing)

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

Re: gnu asm help...

[Petr Vandrovec]

On 18 Jun 01 at 18:20, Timur Tabi wrote:
> You want to return the variable?  Try this:
> 
> static __inline__ unsigned long atomic_inc(atomic_t *v)
> {
> __asm__ __volatile__(
> LOCK "incl %0"
> :"=m" (v->counter)
> :"m" (v->counter));
> 
> return v->counter;
> }

No. Another CPU might increment value between LOCK INCL and
fetching v->counter. On ia32 architecture you are almost out of
luck. You can either try building atomic_inc around CMPXCHG,
using it as conditional store (but CMPXCHG is not available 
on i386), or you can just guard your atomic variable with 
spinlock - but in that case there is no reason for using atomic_t 
at all. 
Best regards,
Petr Vandrovec
[EMAIL PROTECTED]

P.S.: Why you need to know that value? You can either rewrite
your code with atomic_dec_and_test/atomic_inc_and_test, or
you overlooked some race, or you have really strange problem.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: any good diff merging utility?

[Riley Williams]

Hi Ivan.

 >>> I like to build kernels with a bunch of patches on top to test
 >>> new stuff. The problem is that it takes a lot of effort to fix
 >>> all the failed hunks during patching that really wouldn't have
 >>> to be failed if only patch was a little more inteligent and
 >>> could merge several patches into one ( if possible) or if could
 >>> take into account already applied patches.

 >> The basic problem here is that the "failed hunks" are usually there
 >> because of conflicts between the two patches in question, and as a
 >> result, they are not as easy to merge automagically as one might at
 >> first assume.

 > Very often the case is that they indeed can be merged automagically.
 > For example two patches inserting few lines right after the #include
 > lines.

 > patch1:
 > @@ 10,1 10,2 @@
 >  #include 
 > +#include <1.h>

 > patch2:
 > @@ 10,1 10,2 @@
 >  #include 
 > +#include <2.h>

 > The patch will fail to patch :-). But there is no real conflict
 > between the patches.

True, but how about the following (from one I had to merge recently):

 Q> patch1:
 Q> @@ 137,3 142,5
 Q>  for( ptr=head; *ptr; ptr=ptr->next ) {
 Q> +   ctr += ptr->qty;
 Q> table[ctr] += ptr->qty;
 Q> +   total += table[ctr];
 Q>  }

 Q> patch2:
 Q> @@ 137,2 146,3
 Q>  for( ptr=head; *ptr; ptr=ptr->next ) {
 Q> +   total += table[ctr];
 Q> table[ctr] += ptr->qty;

How would you merge those two patches?

 >>> Well, are there any utilities to merge diffs? I couldn't find
 >>> any on freshmeat. So what are you using to stack many patches
 >>> onto the kernel tree? Just manualy modify the diff? I'll try to
 >>> write something more automatic if nothing comes up.

 >> I once came across a utility called "diff3" that was designed to
 >> take a patch for one version of a package and create an
 >> equivalent patch for another version of the same package, but I
 >> haven't been able to find it again since my hard drive crashed.

 > diff3 comes from gnu diffutils
 > . But all
 > it does is comparing three FILES for differencies.

If it does that, then it does all you need. Assume, for example, that
you have two patches to ORIGINAL.DOC that overlap each other, these
being PATCH1.DIFF and PATCH2.DIFF respectively...

 Q> gzip -9 < ORIGINAL.DOC > ORIGINAL.DOC.GZ
 Q> patch < PATCH1.DIFF
 Q> mv ORIGINAL.DOC ORIGINAL.DOC.V1
 Q> gunzip < ORIGINAL.DOC.GZ > ORIGINAL.DOC
 Q> patch < PATCH2.DIFF
 Q> mv ORIGINAL.DOC ORIGINAL.DOC.V2

At this point, you have copies of the patched versions of that file as
produced by the two patches separately. If my memory's right (I don't
have diff3 to hand) you then do...

 Q> diff3 ORIGINAL.DOC.V1 ORIGINAL.DOC.V2 REVISED.DOC

...and end up with REVISED.DOC being the result of taking ORIGINAL.DOC
and applying both PATCH1.DIFF and PATCH2.DIFF in parallel. You can
then do...

 Q> gunzip < ORIGINAL.DOC.GZ > ORIGINAL.DOC
 Q> diff -u ORIGINAL.DOC REVISED.DOC

...to get a consolidated diff that applies both patches.

Best wishes from Riley.

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

Iptables ipt_unclean bug?

[Kajtár Zsolt]

Hi all!

I think it's possible to hang the kernel useing isic 0.05
(www.packetfactory.net/Projects/ISIC/), when there's a unclean match in
iptables rules.

Example:

(somewhere on target:)
iptables -A INPUT -m unclean --match unclean -j DROP

(on local machine:)
# isic -s rand -d target.ip

After <10 seconds the kernel hangs on the target machine, no console
switch/input, no oops/panic, sysrq only prints messages, but only B
works...

This is 100% reproductible on 2.4.5-ac13 and 2.4.5-ac15.

[EMAIL PROTECTED] IS NOT A VALID E-MAIL ADDRESS, PLEASE DO NOT
CC! (I read the archives...)

Some info of this machine:

Kernel: 2.4.5 +ac15 +dvorak sysrq +int2.4.31 +badmem2.4.4

Linux version 2.4.5-ac15 ([EMAIL PROTECTED]) (gcc version 2.95.4 20010604 
(Debian prerelease)) #2 Mon Jun 18 21:04:13 CEST 2001
BIOS-provided physical RAM map:
 BIOS-e820:  - 000a (usable)
 BIOS-e820: 000f - 0010 (reserved)
 BIOS-e820: 0010 - 0a00 (usable)
 BIOS-e820:  - 0001 (reserved)
On node 0 totalpages: 40960
zone(0): 4096 pages.
zone(1): 36864 pages.
zone(2): 0 pages.
Kernel command line: auto BOOT_IMAGE=Linux ro root=307 reboot=warm hdb=none idebus=42 
badmem=0x04db0bfc,0x
ide_setup: hdb=none
ide_setup: idebus=42
Initializing CPU#0
Detected 225.002 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 448.92 BogoMIPS
Memory: 159284k/163836k available (769k kernel code, 4168k reserved, 205k data, 72k 
init, 0k highmem, 4k badram)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
CPU: Before vendor init, caps: 0080a135  , vendor = 1
CPU: After vendor init, caps: 0080a135   0004
CPU: After generic, caps: 0080a135   0004
CPU: Common caps: 0080a135   0004
CPU: Cyrix M II 3x Core/Bus Clock stepping 08
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router PIIX [8086/7110] at 00:07.0
Limiting direct PCI/PCI transfers.
isapnp: Scanning for PnP cards...
isapnp: Card 'ESS ES1869 Plug and Play AudioDrive'
isapnp: 1 Plug & Play card detected total
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Starting kswapd v1.8
devfs: v0.102 (2622) Richard Gooch ([EMAIL PROTECTED])
devfs: boot_options: 0x0
pty: 256 Unix98 ptys configured
Serial driver version 5.05b (2001-05-03) with MANY_PORTS SHARE_IRQ SERIAL_PCI ISAPNP 
enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
block: queued sectors max/low 105621kB/35207kB, 320 slots per queue
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 42MHz system bus speed for PIO modes
PIIX4: IDE controller on PCI bus 00 dev 39
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio
hda: QUANTUM FIREBALL CX6.4A, ATA DISK drive
hdc: Seagate Technology 1275MB - ST31276A, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 12594960 sectors (6449 MB) w/418KiB Cache, CHS=784/255/63, UDMA(33)
hdc: 2502308 sectors (1281 MB), CHS=2482/16/63, DMA
Partition check:
 /dev/ide/host0/bus0/target0/lun0: p1 < p5 p6 p7 p8 p9 > p2 p3 p4
 /dev/ide/host0/bus1/target0/lun0: p1
ne2k-pci.c:v1.02 10/19/2000 D. Becker/P. Gortmaker
  http://www.scyld.com/network/ne2k-pci.html
PCI: Found IRQ 11 for device 00:11.0
PCI: The same IRQ used for device 00:07.2
eth0: KTI ET32P2 found at 0x6800, IRQ 11, xx:xx:xx:xx:xx:xx.
Soundblaster audio driver Copyright (C) by Hannu Savolainen 1993-1996
sb: ESS ES1869 Plug and Play AudioDrive detected
sb: ISAPnP reports 'ESS ES1869 Plug and Play AudioDrive' at i/o 0x220, irq 5, dma 1, 3
ESS chip ES1869 detected
sb: 1 Soundblaster PnP card(s) found.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 1024 buckets, 8Kbytes
TCP: Hash tables configured (established 16384 bind 16384)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (ext2 filesystem) readonly.
Mounted devfs on /dev
Freeing unused kernel memory: 72k freed
Adding Swap: 64252k swap-space (priority -1)
loop: loaded (max 8 devices)
reiserfs: checking transaction log (device 03:06) ...
reiserfs: replayed 5 transactions in 1 seconds
Using r5 hash to sort names
ReiserFS version 3.6.25
reiserfs: checking transaction log (device 03:08) ...
reiserfs: replayed 4 transactions in 1 seconds
Using r5 hash to sort names
ReiserFS version 3.6.25

Re: gnu asm help...

[Timur Tabi]

** Reply to message from "Raj, Ashok" <[EMAIL PROTECTED]> on Mon, 18 Jun 2001
15:56:50 -0700


> also if there is any reference to the gnu asm symtax, please send me a
> pointer.. 

There's lots

> i can understand what the LOCK "incl %0 means.. but not sure what the rest
> is for.

LOCK just means the x86 "lock" prefix.

incl is the 32-bit version of "inc" (incremement)

You want to return the variable?  Try this:

static __inline__ unsigned long atomic_inc(atomic_t *v)
{
__asm__ __volatile__(
LOCK "incl %0"
:"=m" (v->counter)
:"m" (v->counter));

return v->counter;
}


-- 
Timur Tabi - [EMAIL PROTECTED]
Interactive Silicon - http://www.interactivesi.com

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

[SMP] 2.4.5-ac13 deadlocked?

[Bob Glamm]

I've got a strange situation, and I'm looking for a little direction.
Quick summary: I get sporadic lockups running 2.4.5-ac13 on a
ServerWorks HE-SL board (SuperMicro 370DE6), 2 800MHz Coppermine CPUs,
512M RAM, 512M+ swap.  Machine has 8 active disks, two as RAID 1,
6 as RAID 5.  Swap is on RAID 1.  Machine also has a 100Mbit Netgear
FA310TX and an Intel 82559-based 100Mbit card.  SCSI controllers
are AIC-7899 (2) and AIC-7895 (1).  RAM is PC-133 ECC RAM; two
identical machines display these problems.

I've seen three variations of symptoms:

  1) Almost complete lockout - machine responds to interrupts (indeed,
 it can even complete a TCP connection) but no userspace code gets
 executed.  Alt-SysRq-* still works, console scrollback does not;
  2) Partial lockout - lock_kernel() seems to be getting called without
 a corresponding unlock_kernel().  This manifested as programs such
 as 'ps' and 'top' getting stuck in kernel space;
  3) Unkillable programs - a test program that allocates 512M of memory
 and touches every page; running two copies of this simultaneously
 repeatedly results in at least one of the copies getting stuck
 in 'raid1_alloc_r1bh'.

Symptom number 1 was present in 2.4.2-ac20 as well; symptoms 2 and 3
were observed under 2.4.5-ac13 only.  I never get any PANICs, only
these variety of deadlocks.  A reboot is the only way to resolve the
problem.

There seem to be two ways to manifest the problem.  As alluded to in
(3), running two copies of the memory eater simultaneously along with
calls to 'ps' and 'top' trigger the bug fairly quickly (within a minute
or two).  Another method to manifest the problem is to run multiple
copies of this script (I run 10 simultaneous copies):

  #!/bin/sh

  while /bin/true; do
ssh remote-machine 'sleep 1'
  done

This script causes (1) in about a day or two.

If anyone has any suggestions about how to proceed to figure out what
the problem is (or if there is already a fix), please let me know.
I would be more than willing to provide a wide range of cooperation on
this problem.  I don't have a feel for where to go from here, and I'm
hoping that someone with more experience can give me some
assistance..

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

Re: gnu asm help...

[Erik Mouw]

On Mon, Jun 18, 2001 at 03:56:50PM -0700, Raj, Ashok wrote:
> i can understand what the LOCK "incl %0 means.. but not sure what the rest
> is for.
> 
> thanks
> ashokr
> 
> static __inline__ void atomic_inc(atomic_t *v)
> {
> __asm__ __volatile__(
> LOCK "incl %0"
> :"=m" (v->counter)
> :"m" (v->counter));
> }

I also don't know the exact meaning, but here are two nice tutorials
about inline assembly:

http://www-106.ibm.com/developerworks/linux/library/l-ia.html
http://www.uwsg.indiana.edu/hypermail/linux/kernel/9804.2/0953.html



Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: [EMAIL PROTECTED]
WWW: http://www-ict.its.tudelft.nl/~erik/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

gnu asm help...

[Raj, Ashok]

Hello asm gurus..

I need a simple (??) change to atomic_inc() functionality. so that i can
increment and return the 
value of the variable.

current implementation in linux/include/asm/atomic.h does not do this job.

any help would be greatly appreciated.

ashokr


from atomic.h

also if there is any reference to the gnu asm symtax, please send me a
pointer.. 
i can understand what the LOCK "incl %0 means.. but not sure what the rest
is for.

thanks
ashokr

static __inline__ void atomic_inc(atomic_t *v)
{
__asm__ __volatile__(
LOCK "incl %0"
:"=m" (v->counter)
:"m" (v->counter));
}



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

Re: Client receives TCP packets but does not ACK

[dean gaudet]

On Mon, 18 Jun 2001, Jonathan Morton wrote:

> >  > Btw: can the aplication somehow ask the tcp/ip stack what was
> >actualy acked?
> >>  (ie. how many bytes were acked).
> >
> >no, but it's not necessarily a useful number anyhow -- because it's
> >possible that the remote end ACKd bytes but the ACK never arrives.  so you
> >can get into a situation where the remote application has the entire
> >message but the local application doesn't know.  the only way to solve
> >this is above the TCP layer.  (message duplicate elimination using an
> >unique id.)
>
> No, because if the ACK doesn't reach the sending machine, the sender
> will retry the data until it does get an ACK.

if the network goes down in between, the sender may never get the ACK.
the sender will see a timeout eventually.  the receiver may already be
done with the connection and closed it and never see the error.  if it
were a protocol such as SMTP then the sender would retry later, and the
result would be a duplicate message.  (which you can eliminate above the
TCP layer using unique ids.)

-dean

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

Re: Why can't I flush /dev/ram0? (fwd)

[Scott Murray]

Linus,

Any chance you can finally merge this fix or suggest what better one you
are looking for?  When this bug bit me in early April, an investigation
showed that this particular fix has been in the ac kernels since last
November.

Thanks,

Scott


-- 
Scott Murray
SOMA Networks, Inc.
Toronto, Ontario
e-mail: [EMAIL PROTECTED]

-- Forwarded message --
Date: Mon, 18 Jun 2001 23:55:37 +0200
From: Jan Rekorajski <[EMAIL PROTECTED]>
To: Kelledin Tane <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: Re: Why can't I flush /dev/ram0?

On Mon, 18 Jun 2001, Kelledin Tane wrote:

> At this point, I'm trying to get an initrd working properly.  So far, it
> works, the system boots, etc. etc., but whenever I try to do a "blockdev
> --flushbufs /dev/ram0", I get "device or resource busy"
>
> When I mount the filesystem to check it out, nothing appears to have
> anything open on the filesystem.  So why am I not able to flush it
> clean?

Because of a bug present in Linus tree. Try this patch:

--- linux.orig/drivers/block/rd.c   Mon Nov 20 02:07:47 2000
+++ linux/drivers/block/rd.cMon Nov 20 04:03:42 2000
@@ -690,6 +690,7 @@
 done:
if (infile.f_op->release)
infile.f_op->release(inode, );
+   blkdev_put(out_inode->i_bdev, BDEV_FILE);
set_fs(fs);
return;
 free_inodes: /* free inodes on error */

BTW, it's fixed in -ac patches.

Jan
-- 
Jan Rêkorajski|  ALL SUSPECTS ARE GUILTY. PERIOD!
bagginsmimuw.edu.pl   |  OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY?
BOFH, MANIAC  |   -- TROOPS by Kevin Rubio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

Re: sis630 - help needed debugging in the kernel

[Paul Mundt]

On Mon, Jun 18, 2001 at 02:58:17PM -0700, James Simmons wrote:
> > Yep, in fbmem.c the name entry is "sisfb" as opposed to just "sis". 
> 
> Agh!!! That needs to be fixed. 
> 
I've already fixed it in ruby..

Regards,

-- 
Paul Mundt <[EMAIL PROTECTED]>

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

Re: sis630 - help needed debugging in the kernel

[James Simmons]

> > Is there another way to tell the fb driver what mode to use??
> > 
> Yep, in fbmem.c the name entry is "sisfb" as opposed to just "sis". 

Agh!!! That needs to be fixed. 

> Also, the
> driver requires that the mode is passed video a "mode:" argument as is
> outlined in the sisfb_setup(). Take a look at drivers/video/sis/sis_main.h,
> specifically sisbios_mode[] for a list of supported modes.

Broken. It should be using modedb. When I get the time I will send a fix.

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

Re: Why can't I flush /dev/ram0?

[Jan Rekorajski]

On Mon, 18 Jun 2001, Kelledin Tane wrote:

> At this point, I'm trying to get an initrd working properly.  So far, it
> works, the system boots, etc. etc., but whenever I try to do a "blockdev
> --flushbufs /dev/ram0", I get "device or resource busy"
> 
> When I mount the filesystem to check it out, nothing appears to have
> anything open on the filesystem.  So why am I not able to flush it
> clean?

Because of a bug present in Linus tree. Try this patch:

--- linux.orig/drivers/block/rd.c   Mon Nov 20 02:07:47 2000
+++ linux/drivers/block/rd.cMon Nov 20 04:03:42 2000
@@ -690,6 +690,7 @@
 done:
if (infile.f_op->release)
infile.f_op->release(inode, );
+   blkdev_put(out_inode->i_bdev, BDEV_FILE);
set_fs(fs);
return;
 free_inodes: /* free inodes on error */ 

BTW, it's fixed in -ac patches.

Jan
-- 
Jan Rkorajski|  ALL SUSPECTS ARE GUILTY. PERIOD!
bagginsmimuw.edu.pl   |  OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY?
BOFH, MANIAC  |   -- TROOPS by Kevin Rubio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

What happened to lookup_dentry?

[Timur Tabi]

I'm porting a driver from 2.2 to 2.4, and this driver calls lookup_dentry,
which doesn't exist in 2.4.  I've read through the source code and searched the
web and newsgroups, and I can't find any explanation as to why lookup_dentry no
longer exists or how I'm supposed to change code that uses it.  Can anyone help
me?


-- 
Timur Tabi - [EMAIL PROTECTED]
Interactive Silicon - http://www.interactivesi.com

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

Re: Why can't I flush /dev/ram0?

[Kelledin Tane]

> If you have a directory called /initrd, in your root file-system,
> you may find that the old initrd is still mounted:
>
> Script started on Mon Jun 18 17:22:20 2001
> # ls /initrd
> bin  dev  etc  lib  linuxrc  sbin
> # umount /initrd
> # ls /initrd
> # exit
> exit
> Script done on Mon Jun 18 17:22:44 2001
>
> Unmount it first.

I actually had something to that effect in my rc.sysinit file.  It unmounted
/initrd, removed it, and attempted to flush ram0.  I started trying it
manually when that didn't work =(

Funny thing though (not entirely unexpected)--/initrd's not in /etc/mtab.
I can see why.  Also, /proc/sys/kernel/real-root-dev is still 0x0100
(/dev/ram0).  Changing it to 0x0301 (/dev/hda1) doesn't help, but it might be
a clue for those who know this stuff better than I do.

Kelledin

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

Re: Why can't I flush /dev/ram0?

[Richard B. Johnson]

On Mon, 18 Jun 2001, Kelledin Tane wrote:

> At this point, I'm trying to get an initrd working properly.  So far, it
> works, the system boots, etc. etc., but whenever I try to do a "blockdev
> --flushbufs /dev/ram0", I get "device or resource busy"
> 
> When I mount the filesystem to check it out, nothing appears to have
> anything open on the filesystem.  So why am I not able to flush it
> clean?
> 
> This is kernel 2.4.5 stock, btw.
> 
> Kelledin
> 

If you have a directory called /initrd, in your root file-system,
you may find that the old initrd is still mounted:

Script started on Mon Jun 18 17:22:20 2001
# ls /initrd
bin  dev  etc  lib  linuxrc  sbin
# umount /initrd
# ls /initrd
# exit
exit
Script done on Mon Jun 18 17:22:44 2001

Unmount it first.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


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

Re: Linux/VAX booting to a shell.

[Aaron Lehmann]

On Sun, Jun 17, 2001 at 11:11:29PM +0200, Pavel Machek wrote:
> Congratulations. (This is pretty big machine, for the VAX, no? When
> was it build? How much power does it take?)

Nah, it's a VAXstation.

http://www.mcmanis.com/chuck/computers/vaxen/buildvax.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: getrusage vs /proc/pid/stat?

[Dan Kegel]

Pete Wyckoff wrote:
> 
> [EMAIL PROTECTED] said:
> > I'd like to monitor CPU, memory, and I/O utilization in a
> > long-running multithreaded daemon under kernels 2.2, 2.4,
> > and possibly also Solaris (#ifdefs are ok).
> 
> getrusage() isn't really the system call you want for this.

I'll buy that.  Looks like a lot of unices don't implement that
call fully, and Linux is one of them.

What is the proper way to measure total CPU time used by a multithreaded program?
The only way I can figure to do it is to sum /proc/pid/stat across
the threads of interest (see below).  Is this the easiest way, 
or am I missing something?  (Forgive the C++.  I'd recode this in C
if it were for general use.)

= LinuxTimes.h ==
#include 
#include 

/*--
 Source and test case at http://www.kegel.com/lt.tar.gz

 Monitor the CPU usage of a bunch of threads in the same process.
 This is a simulation of the system call times() 
 providing traditional semantics under LinuxThreads.
 On e.g. Solaris, you don't need this; you just call the standard times().
--*/
class LinuxTimes {
const static int MAXTHREADS = 100;

/// number of threads being monitored
int m_nthreads;

/// fd open to /proc/pid/stat for each thread
int m_proc_pid_stat_fd[MAXTHREADS];

/// make addSelf threadsafe
pthread_mutex_t m_lock;

public:

LinuxTimes() { m_nthreads = 0; pthread_mutex_init(_lock, NULL); }

/**
 New threads call this to add themselves to the group.
 Threadsafe.
 @return 0 on success, Unix error code on failure
 */
int addSelf();

/**
 Calculate user and system time accumulated by all threads in group.
 Return result in tms_utime and tms_stime fields of given struct tms.
 Similar to 'man 2 times' on Solaris (where all CPU time of all threads
 is counted as CPU time towards the process).
 @return 0 on success, Unix error code on failure
 */
int times(struct tms *buf);
};

= LinuxTimes.cc ==

#include "LinuxTimes.h"
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include   

/**
 New threads call this to add themselves to the group.
 Threadsafe.
 @return 0 on success, Unix error code on failure
 */
int LinuxTimes::addSelf()
{
int fd;
char fname[256];
int err = 0;

if (pthread_mutex_lock(_lock))
return EINVAL;

if (m_nthreads >= MAXTHREADS) {
err = E2BIG;
} else {
// Under LinuxThreads, each thread has its own pid
sprintf(fname, "/proc/%d/stat", getpid());
fd = open(fname, O_RDONLY);
if (fd == -1) 
err = errno;
else {
m_proc_pid_stat_fd[m_nthreads++] = fd;
}
}

if (pthread_mutex_unlock(_lock))
return EINVAL;

return err;
}

/* Skip to char after nth whitespace.  Returns NULL on failure. */
static const char *skipNspace(const char *p, int n)
{
while (*++p)
if (isspace(*p) && ! --n) 
return p+1;
return NULL;
}

/**
 Calculate user and system time accumulated by all threads in group.
 Return result in tms_utime and tms_stime fields of given struct tms.
 Similar to 'man 2 times' on Solaris (where all CPU time of all threads
 is counted as CPU time towards the process).
 @return 0 on success, Unix error code on failure
 */
int LinuxTimes::times(struct tms *buf)
{
int i;
int nread;

buf->tms_utime = 0;
buf->tms_stime = 0;
for (i=0; itms_utime += atoi(p);

// Skip to stime field
p = skipNspace(p, 1);
if (!p) return EINVAL;
buf->tms_stime += atoi(p);
}

return 0;
}

==

Thanks,
Dan

-- 
"A computer is a state machine.
 Threads are for people who can't program state machines."
 - Alan Cox
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Why can't I flush /dev/ram0?

[Kelledin Tane]

At this point, I'm trying to get an initrd working properly.  So far, it
works, the system boots, etc. etc., but whenever I try to do a "blockdev
--flushbufs /dev/ram0", I get "device or resource busy"

When I mount the filesystem to check it out, nothing appears to have
anything open on the filesystem.  So why am I not able to flush it
clean?

This is kernel 2.4.5 stock, btw.

Kelledin

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

Re: sis630 - help needed debugging in the kernel

[René Rebe]

On Mon, 18 Jun 2001 12:28:00 -0700
Paul Mundt <[EMAIL PROTECTED]> wrote:

[...]

> Yep, in fbmem.c the name entry is "sisfb" as opposed to just "sis". Also, the
> driver requires that the mode is passed video a "mode:" argument as is
> outlined in the sisfb_setup(). Take a look at drivers/video/sis/sis_main.h,
> specifically sisbios_mode[] for a list of supported modes.
> 
> Something like:
> 
> video=sisfb:mode:640x480x32
> 
> should do the job.

It crashed, too.

Full boot-up messages:

Kernel command line: root=/dev/discs/disc0/part2 video=sisfb:mode:640x480x32 
console=ttyS0,9600 console=tty0  mem=131008K
Initializing CPU#0
Detected 631.427 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 1258.29 BogoMIPS
Memory: 126484k/131008k available (1159k kernel code, 4136k reserved, 325k data, 204k 
init, 0k highmem)
Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes)
Inode-cache hash table entries: 8192 (order: 4, 65536 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 32768 (order: 5, 131072 bytes)
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 128K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: Intel Celeron (Coppermine) stepping 03
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.40 (20010327) Richard Gooch ([EMAIL PROTECTED])
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xfda38, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router SIS [1039/0008] at 00:01.0
PCI: Found IRQ 10 for device 00:03.0
PCI: The same IRQ used for device 00:01.4
PCI: The same IRQ used for device 00:01.6
  got res[1000:1fff] for resource 0 of O2 Micro, Inc. OZ6812 Cardbus Controller
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
PnP: PNP BIOS installation structure at 0xc00f70b0
PnP: PNP BIOS version 1.0, entry at f:5f34, dseg at f
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd v1.8
VFS: Diskquotas version dquot_6.5.0 initialized
devfs: v0.102 (2622) Richard Gooch ([EMAIL PROTECTED])
devfs: boot_options: 0x0
sisfb: framebuffer at 0xe000, mapped to 0xc880, size 65536k
sisfb: MMIO at 0xefce, mapped to 0xcc801000, size 128k
sisfb: encountered LCD
sisfb: fall back to 1024x768
sisfb: mode is 640x480x32, linelength=2560
sisfb: before sisfb_pre_setmod
sisfb: before SISSetMode
sisfb: before sisfb_post_setmode
sisfb: before sisfb_crtc_to_var
sisfb: before sisfb_set_disp
sisfb: before sisfb_heap_init
sisfb: before vc_resize_con
sisfb: before register_framebuffer
Unable to handle kernel paging request at virtual address cc800600
 printing eip:
c01ba5c0
*pde = 07f82067
*pte = 
Oops: 0002
CPU:0
EIP:0010:[]
EFLAGS: 00010246
eax:    ebx:    ecx: cc800600   edx: c02dc400
esi:    edi: c026d527   ebp:    esp: c123de58
ds: 0018   es: 0018   ss: 0018
Process swapper (pid: 1, stackpage=c123d000)
Stack: c02c23e0 c02dc4c0 06e4  0a00 0008 cc7fc000 c01ac77c 
   c1221000 c02dc4c0 c123f344 0001 0666  c123f342 c123f344 
   0001 06e4 c018150c c1221000 c123f342 0001 06e4  
Call Trace: [] [] [] [] [] 
   [] [] [] [] [] 

Code: 89 01 88 d0 c0 e8 06 83 e0 01 f7 d8 21 d8 31 f0 89 41 04 88 
 <0>Kernel panic: Attempted to kill init!

ksymoops output:

ksymoops 2.3.7 on i686 2.4.4-ac5.  Options used
 -V (specified)
 -K (specified)
 -L (specified)
 -O (specified)
 -m /mnt/net/portable/usr/src/linux/System.map (specified)

Unable to handle kernel paging request at virtual address cc800180
c01b8f61
*pde = 0af2d067
Oops: 0002
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010206
eax: 0f0f0f0f   ebx: c026e51c   ecx: 0003   edx: 
esi: cc800180   edi: c026f460   ebp: 0f0f0f0f   esp: c12fde50
ds: 0018   es: 0018   ss: 0018
Process swapper (pid: 1, stackpage=c12fd000)
Stack: c02c23e0 c02dc4c0 0593  cc7fdc08   0320 
   cc7fdc00 c01ac77c c12ee000 c02dc4c0 c12fe342 0001 051e  
   c12fe340 c12fe342 0001 0593 c018150c c12ee000 c12fe340 0001 
Call Trace: [] [] [] [] [] 
   [] [] [] [] [] [] 
Code: 89 06 8a 03 24 0f 0f b6 d0 8b 44 24 18 23 04 97 31 e8 89 46 

>>EIP; c01b8f61<=
Trace; cc7fdc08 
Trace; cc7fdc00 
Trace; c01ac77c 
Trace; c018150c 
Trace; c0181584 
Trace; c01adede 
Trace; c0181f04 
Trace; c01856f9 
Trace; c01aaeb9 
Trace; c0105013 
Trace; c010542c 
Code;  c01b8f61 
 <_EIP>:
Code;  c01b8f61<=
   0:   89 06 mov%eax,(%esi)   <=
Code;  c01b8f63 
   2:   8a 03 mov(%ebx),%al
Code;  c01b8f65 
   4: 

Re: Linux/VAX booting to a shell.

[Pavel Machek]

Hi!

> Hi all, (mind crossposts on follow ups..)
> 
> attached below is a bootlog from the Linux/VAX port, booting up, loading
> up busybox/uClibc sh and cat /proc/cpuinfo, from my VAXStation 3100m38,
> 
> Thanks to the other two members of the core VAX porting team, Andy
> Phillips and Kenn Humborg and others on the linux-vax list who've given
> their help, this is the second major milestone for the project, (gcc
> porting was the first) now to get it working on a few other systems and
> move into userspace...

Congratulations. (This is pretty big machine, for the VAX, no? When
was it build? How much power does it take?)
Pavel
-- 
I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [OT] Re: ipchains

[Ted Gervais]

On Mon, 18 Jun 2001, J Sloan wrote:

> > I just ran into something odd. To me anyways, it was odd.
> > I just installed and brought up kernel 2.4.5 and my ipchains failed.
> > So I upgraded to the latest (that I could find) ipchains-1.3.10, and
> > that also fails.
> >
> > Has anyone got any version of ipchains to work with the new(er) kernels?
> 
> For what it's worth, Red Hat 7.1 ships iptables
> with ipchains emulation, which works out of the
> box on their 2.4.2 kernel

Yup!  But I am running Slackware7.1 here.
Thanks anyways..
---
Doubt is not a pleasant condition, but certainty is absurd.
-- Voltaire

Ted Gervais <[EMAIL PROTECTED]>
44.135.34.201 linux.ve1drg.ampr.org


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

Re: eepro100 problems with 2.2.19 _and_ 2.4.0

[Andrey Savochkin]

On Sun, Jun 17, 2001 at 12:40:34AM -0300, Christian Robottom Reis wrote:
> 
> I am _very_ willing to devote some time to getting this fixed in both the
> kernel and Donald's drivers if anyone is interested in tracking down the
> problem. I'm not very familiar with the hardware, but I have a test box I
> can use freely, a bit of time spare, and I can reproduce the problem
> easily. I'd hate to see somebody else go through what I have just had to,
> so it would be nice to see this fixed or documented in an official-ese
> place.

I'm obviously interested in tracking it down.
I'll contact you with what we can test on you comp a couple of days later,
I'm quite busy right now, ok?

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

Re: Strange behaviour of swap under 2.4.5-ac15

[German Gomez Garcia]

On Mon, 18 Jun 2001, Andrea Arcangeli wrote:

> On Mon, Jun 18, 2001 at 05:35:54PM +0200, German Gomez Garcia wrote:
> > On Mon, 18 Jun 2001, Andrea Arcangeli wrote:
> >
> > > On Mon, Jun 18, 2001 at 04:41:02PM +0200, German Gomez Garcia wrote:
> > > > so, if there is another way to get that info (maybe some file in /proc?)
> > >
> > > did you compiled with highmem?
> >
> > No,
>
> ok then with 512mbyte on an x86 my patch couldn't help. I thought it was
> it because the sympthom was the same (constant kswapd activity and
> constant swap grow) but it obviously is something else. Then try
> 2.4.6pre3aa1 (it is certainly stable).

You were right, with 2.4.6pre3aa1 it works in the expected way (at
least the way it was expected before :-). I'm now at home so if you need
more info on it, I'll do my best.

Regards,

- german

-
German Gomez Garcia | "This isn't right.  This isn't even wrong."
<[EMAIL PROTECTED]> | -- Wolfgang Pauli

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

Re: sis630 - help needed debugging in the kernel

[Paul Mundt]

On Mon, Jun 18, 2001 at 08:32:03PM +0200, René Rebe wrote:
> > Try booting at 640x480 with a color depth of 32. Then
> > try booting at a different resolution (1024x768) at the default color
> > depth. I want to see if its a error with the resolution setting or if it
> > is a error with setting up the data relating to the color depth handling. 
> > The results should give me some clue.
> 
> I can't set the videomode for the driver ...? I tried:
> 
> video=sis:vesa:0x112
> video=sis:xres:640,yres:480,depth:32
> video=sis,xres:640,yres:480,depth:32
> 
> Is there another way to tell the fb driver what mode to use??
> 
Yep, in fbmem.c the name entry is "sisfb" as opposed to just "sis". Also, the
driver requires that the mode is passed video a "mode:" argument as is
outlined in the sisfb_setup(). Take a look at drivers/video/sis/sis_main.h,
specifically sisbios_mode[] for a list of supported modes.

Something like:

video=sisfb:mode:640x480x32

should do the job.

Regards,

-- 
Paul Mundt <[EMAIL PROTECTED]>

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

2.4.5-ac15 -- Unresolved symbols "gameport_register_port" and"gameport_unregister_port" in char/joystick/[cs461x.o, emu10k1-gp.o,lightning.o, ns558.o, pcigame.o]

[Miles Lane]

I don't know if this is due to symbols not being exported or due
to some failed dependency structuring in "make menuconfig".

find kernel -path '*/pcmcia/*' -name '*.o' | xargs -i -r ln -sf ../{}
pcmcia
if [ -r System.map ]; then /sbin/depmod -ae -F System.map  2.4.5-ac15;
fi
depmod: *** Unresolved symbols in
/lib/modules/2.4.5-ac15/kernel/drivers/char/joystick/cs461x.o
depmod: gameport_register_port
depmod: gameport_unregister_port
depmod: *** Unresolved symbols in
/lib/modules/2.4.5-ac15/kernel/drivers/char/joystick/emu10k1-gp.o
depmod: gameport_register_port
depmod: gameport_unregister_port
depmod: *** Unresolved symbols in
/lib/modules/2.4.5-ac15/kernel/drivers/char/joystick/lightning.o
depmod: gameport_register_port
depmod: gameport_unregister_port
depmod: *** Unresolved symbols in
/lib/modules/2.4.5-ac15/kernel/drivers/char/joystick/ns558.o
depmod: gameport_register_port
depmod: gameport_unregister_port
depmod: *** Unresolved symbols in
/lib/modules/2.4.5-ac15/kernel/drivers/char/joystick/pcigame.o
depmod: gameport_register_port
depmod: gameport_unregister_port

Here are the relevant .config bits:

CONFIG_INPUT_GAMEPORT=y
CONFIG_INPUT_NS558=m
CONFIG_INPUT_LIGHTNING=m
CONFIG_INPUT_PCIGAME=m
CONFIG_INPUT_CS461X=m
CONFIG_INPUT_EMU10K1=m
CONFIG_INPUT_SERIO=m
CONFIG_INPUT_SERPORT=m
# CONFIG_INPUT_ANALOG is not set
# CONFIG_INPUT_A3D is not set
# CONFIG_INPUT_ADI is not set
# CONFIG_INPUT_COBRA is not set
# CONFIG_INPUT_GF2K is not set
# CONFIG_INPUT_GRIP is not set
# CONFIG_INPUT_INTERACT is not set
# CONFIG_INPUT_TMDC is not set
# CONFIG_INPUT_SIDEWINDER is not set
# CONFIG_INPUT_IFORCE_USB is not set
# CONFIG_INPUT_IFORCE_232 is not set
# CONFIG_INPUT_WARRIOR is not set
# CONFIG_INPUT_MAGELLAN is not set
# CONFIG_INPUT_SPACEORB is not set
# CONFIG_INPUT_SPACEBALL is not set
# CONFIG_INPUT_STINGER is not set
# CONFIG_INPUT_DB9 is not set
# CONFIG_INPUT_GAMECON is not set
# CONFIG_INPUT_TURBOGRAFX is not set
# CONFIG_QIC02_TAPE is not set


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

Re: very strange (semi-)lockups in 2.4.5

[Pozsar Balazs]

First I thought this was an X-issue, but now I'm 100% sure that it isn't,
as I met the desscribed hangup while working on the console too.

The NMI card would be interesting, if anyone tells me how to make one, and
how to patch the kernel to show useable information i'm looking forward to
do it, and send reports.


regards
Balazs Pozsar.

On Mon, 18 Jun 2001, Albert D. Cahalan wrote:

> Pozsar Balazs writes:
>
> > I'm having ~2 lockups a day. The following happens:
> >  If I was under X, i only can use the magic-key, but no other keyboard (eg
> > numlock) or mouse response, the screen freezes, processes stop.
> >  If i was using textmode:
> >   numlock still works
> >   cursor blinks
> >   processess stop (eg, gpm doesn't work, outputs freeze)
> >   i can still switch vt's.
> >   BUT, i can only type into a few vt's, last time into 3,5,6,7,8, but not
> > into 1,2 or 4!
> >
> > I cannot give you any traces, as i dont have any.
> >
> > Also note that magic-key works, and it says that it umounts filesystems if
> > i press magic-u, but next time at mount i see that reiserfs is replaying
> > transactions.
> >
> >
> > Any ideas?
> >
> > The machine is a P3-750, 512M ram, abit vp6 mb. No overclocking, and it
> > passes memtest86.
>
> I think I'm getting the same thing, but I don't have the magic-key
> compiled in. I'm going to hook up a VT510 to the serial port, in case
> this is just XFree86 crashing. For anyone collecting statistics:
>
> kernels 2.4.4-pre6 (?) and now 2.4.6-pre3
> plain Pentium MMX @ 200 MHz
> Intel motherboard -- see below
> stable since 1996, on a UPS, dust-free, and the fan works
> one lockup per day with desktop usage
>
> In case the serial console doesn't work, could someone post plans
> for a safe NMI board? (both ISA and PCI) The best I found:
> http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/02/msg00425.html
> http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/02/msg00391.html
> (for PCI you're supposed to assert SERR# on the clock -- how?)
>
> 00:00.0 Host bridge: Intel Corporation 430TX - 82439TX MTXC (rev 01)
> 00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 01)
> 00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01)
> 00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01)
> 00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 01)
> 00:11.0 Ethernet controller: Digital Equipment Corporation DECchip 21040 [Tulip] 
>(rev 23)
> 00:13.0 Ethernet controller: Lite-On Communications Inc LNE100TX Fast Ethernet 
>Adapter (rev 25)
> 00:14.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro 215GP (rev 5c)
>


-- 


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

[OT] Re: ipchains

[J Sloan]

Ted Gervais wrote:

> I just ran into something odd. To me anyways, it was odd.
> I just installed and brought up kernel 2.4.5 and my ipchains failed.
> So I upgraded to the latest (that I could find) ipchains-1.3.10, and
> that also fails.
>
> Has anyone got any version of ipchains to work with the new(er) kernels?

For what it's worth, Red Hat 7.1 ships iptables
with ipchains emulation, which works out of the
box on their 2.4.2 kernel

cu

jjs

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

[patch] smbfs-2.4.6-pre3 - win95 flush & NetApp lastname

[Urban Widmark]

Hej

A less painful workaround than what I added during 2.4.5-pre for the
win9x-lies-about-filesizes-on-open-files problem. Replaces constant
flush'es with seek to end, and only when necessary.

Also, a fix where smbfs doesn't follow protocol and fails to return
'lastname' for all "infolevels", which breaks with NetApps.

Patch vs -pre1, but is fine vs -pre3. Please apply.

/Urban


diff -urN -X exclude linux-2.4.6-pre1-orig/fs/smbfs/ChangeLog 
linux-2.4.6-pre1-smbfs/fs/smbfs/ChangeLog
--- linux-2.4.6-pre1-orig/fs/smbfs/ChangeLogWed May 30 21:57:15 2001
+++ linux-2.4.6-pre1-smbfs/fs/smbfs/ChangeLog   Tue Jun 12 20:34:32 2001
@@ -1,5 +1,10 @@
 ChangeLog for smbfs.
 
+2001-06-12 Urban Widmark <[EMAIL PROTECTED]>
+
+   * proc.c: replace the win95-flush fix with smb_seek, when needed.
+   * proc.c: readdir 'lastname' bug (NetApp dir listing fix)
+
 2001-05-08 Urban Widmark <[EMAIL PROTECTED]>
 
* inode.c: Fix for changes on the server side not being detected
diff -urN -X exclude linux-2.4.6-pre1-orig/fs/smbfs/file.c 
linux-2.4.6-pre1-smbfs/fs/smbfs/file.c
--- linux-2.4.6-pre1-orig/fs/smbfs/file.c   Wed May 30 21:57:15 2001
+++ linux-2.4.6-pre1-smbfs/fs/smbfs/file.c  Wed Jun  6 23:00:02 2001
@@ -151,6 +151,7 @@
 * Update the inode now rather than waiting for a refresh.
 */
inode->i_mtime = inode->i_atime = CURRENT_TIME;
+   inode->u.smbfs_i.flags |= SMB_F_LOCALWRITE;
if (offset > inode->i_size)
inode->i_size = offset;
} while (count);
diff -urN -X exclude linux-2.4.6-pre1-orig/fs/smbfs/inode.c 
linux-2.4.6-pre1-smbfs/fs/smbfs/inode.c
--- linux-2.4.6-pre1-orig/fs/smbfs/inode.c  Wed May 30 21:57:15 2001
+++ linux-2.4.6-pre1-smbfs/fs/smbfs/inode.c Wed Jun  6 23:00:02 2001
@@ -141,8 +141,8 @@
inode->u.smbfs_i.oldmtime = jiffies;
 
if (inode->i_mtime != last_time || inode->i_size != last_sz) {
-   VERBOSE("%s/%s changed, old=%ld, new=%ld, oz=%ld, nz=%ld\n",
-   DENTRY_PATH(dentry),
+   VERBOSE("%ld changed, old=%ld, new=%ld, oz=%ld, nz=%ld\n",
+   inode->i_ino,
(long) last_time, (long) inode->i_mtime,
(long) last_sz, (long) inode->i_size);
 
diff -urN -X exclude linux-2.4.6-pre1-orig/fs/smbfs/proc.c 
linux-2.4.6-pre1-smbfs/fs/smbfs/proc.c
--- linux-2.4.6-pre1-orig/fs/smbfs/proc.c   Wed May 30 21:57:15 2001
+++ linux-2.4.6-pre1-smbfs/fs/smbfs/proc.c  Thu Jun  7 21:20:59 2001
@@ -919,6 +919,31 @@
 }
 
 /*
+ * Called with the server locked
+ */
+static int
+smb_proc_seek(struct smb_sb_info *server, __u16 fileid,
+ __u16 mode, off_t offset)
+{
+   int result;
+
+   smb_setup_header(server, SMBlseek, 4, 0);
+   WSET(server->packet, smb_vwv0, fileid);
+   WSET(server->packet, smb_vwv1, mode);
+   DSET(server->packet, smb_vwv2, offset);
+
+   result = smb_request_ok(server, SMBlseek, 2, 0);
+   if (result < 0) {
+   result = 0;
+   goto out;
+   }
+
+   result = DVAL(server->packet, smb_vwv0);
+out:
+   return result;
+}
+
+/*
  * We're called with the server locked, and we leave it that way.
  */
 static int
@@ -1210,11 +1235,6 @@
if (result >= 0)
result = WVAL(server->packet, smb_vwv0);
 
-   /* flush to disk, to trigger win9x to update its filesize */
-   /* FIXME: this will be rather costly, won't it? */
-   if (server->mnt->flags & SMB_MOUNT_WIN95)
-   smb_proc_flush(server, fileid);
-
smb_unlock_server(server);
return result;
 }
@@ -1858,6 +1878,7 @@
result = mask_len;
goto unlock_return;
}
+   mask_len--; /* mask_len is strlen, not #bytes */
first = 1;
VERBOSE("starting mask_len=%d, mask=%s\n", mask_len, mask);
 
@@ -1946,18 +1967,28 @@
 * Note that some servers (win95?) point to the filename and
 * others (NT4, Samba using NT1) to the dir entry. We assume
 * here that those who do not point to a filename do not need
-* this info to continue the listing. OS/2 needs this, but it
-* talks "infolevel 1"
+* this info to continue the listing.
+*
+* OS/2 needs this and talks infolevel 1
+* NetApps want lastname with infolevel 260
+*
+* Both are happy if we return the data they point to. So we do.
 */
mask_len = 0;
-   if (info_level == 1 && ff_lastname > 0 &&
-   ff_lastname < resp_data_len) {
+   if (ff_lastname > 0 && ff_lastname < resp_data_len) {
lastname = resp_data + ff_lastname;
 
-   /* lastname points to a length byte */
-   

Re: [PATCH] devfs v181 available

[Richard Gooch]

Alexander Viro writes:
> 
> 
> On Mon, 18 Jun 2001, Richard Gooch wrote:
> 
> > > Irrelevant. BKL provides an exclusion only on non-blocking areas.
> > 
> > Yeah, I know all that.
> 
> So what the hell are you talking about?

Never mind. We seem to be talking at cross purposes. We both know how
the BKL works and the implications, so there's not much point beating
our heads trying to communicate redundant information :-)

> > > _Moved_ them there from the callers of these functions. And AFAICS
> > > you do need BKL for get_devfs_entry_...(); otherwise relocation of
> > > the table will be able to screw you inside of that function. Now, it
> > > will merrily screw you anyway in a lot of places, but that's another
> > > story.
> > 
> > OK, so it was another global change.
> 
> Moving BKL into the ->readlink() and ->follow_link()? Sure, it was a global
> change. About a year ago.
> 
> > Question: assuming data fed to vfs_follow_link() is "safe", does it
> 
> > need the BKL? I can see that vfs_readlink() obviously doesn't need
> > it. From reading Documentation/filesystems/Locking I suspect it
> > doesn't need the BKL, but the way I read it says "follow_link() method
> > does not *have* the BKL already". But that doesn't explicitely say
> > whether vfs_follow_link() needs it.
> 
> vfs_follow_link() doesn't need it. Moreover, if data fed to it is
> unsafe without BKL, you are screwed even if you take BKL. So
> assumption above is bogus - you _never_ need BKL on that call.

OK, you didn't see what I was driving at. If I had said "if my data is
protected by a semaphore, do I still need the BKL for
vfs_follow_link()" I guess it would have been clearer. Anyway, you've
answered my question, thanks.

Regards,

Richard
Permanent: [EMAIL PROTECTED]
Current:   [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

HTFS (SCO OpenServer 5) filesystem support

[Andrzej Dereszowski]

Hello

If someone wants to mount HTFS (SCO Open Server 5) filesystem
(read-only), here is a module to allow this:

http://deresz.dhs.org/~deresz/filesystems/htfs_fs/htfs_fs-0.01alpha.tar.bz2

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

Re: sis630 - help needed debugging in the kernel

[René Rebe]

On Sun, 17 Jun 2001 07:03:55 -0700 (PDT)
James Simmons <[EMAIL PROTECTED]> wrote:

[...]

> Yes. It oops in fbcon_cfb8_putc. I haven't figured out yet what exactly
> caused it. I don't have this card to play with :-( Did you run the other
> test I suggested.

Never arrived here :-(. (Pleas cc me, since I'm not on this lists ...)

> Try booting at 640x480 with a color depth of 32. Then
> try booting at a different resolution (1024x768) at the default color
> depth. I want to see if its a error with the resolution setting or if it
> is a error with setting up the data relating to the color depth handling. 
> The results should give me some clue.

I can't set the videomode for the driver ...? I tried:

video=sis:vesa:0x112
video=sis:xres:640,yres:480,depth:32
video=sis,xres:640,yres:480,depth:32

Is there another way to tell the fb driver what mode to use??

I set the shared memory size from 16MB to 64 MB: results:
  sisfb: framebuffer at 0xe000, mapped to 0xc880, size 65536k
  sisfb: MMIO at 0xefce, mapped to 0xcc801000, size 128k
  Unable to handle kernel paging request at virtual address cc8002e0

old results:
  sisfb: framebuffer at 0xe000, mapped to 0xcb80, size 16384k
  sisfb: MMIO at 0xefce, mapped to 0xcc801000, size 128k
  Unable to handle kernel paging request at virtual address cc800180

(Maybe some typo somewhere ??)

PS: I have more free time the next days -> shorter latency and more kernel
source read time ...

k33p h4ck1n6 René

-- 
René Rebe (Registered Linux user: #127875)
http://www.rene.rebe.myokay.net/
-Germany-

Anyone sending unwanted advertising e-mail to this address will be charged
$25 for network traffic and computing time. By extracting my address from
this message or its header, you agree to these terms.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] 2.4.4 PCI FBB

[Grant Grundler]

Hi Ivan, Jeff,

Appended is the 2.4.4 patch for PCI Fast Back-Back (FBB) support.
Could you please review/comment on it?

Some caveats/notes:
o Since I'm on the road (visiting relatives in Germany mostly, currently
  in Zurich), I'm only able to verify it boots on my Omnibook 800.
  PA-RISC port is still based on 2.4.0 so I can't test there.
  My lxr8000 (in Cupertino) doesn't reboot remotely reliably.
  Consider this a first cut.

o I've added logic to pull the secondary PCI bus out of reset properly
  in case the PCI-PCI bridge not been initialized by BIOS.
  This was implicitly happening before in pci_setup_bridge().
  The OB800 has a *broken* VLSI PCI-PCI bridge onboard with respect
  to the BUS_RESET bit - see the "KLUGE ALERT".

o "lspci" segfaults on the OB800. I don't know why.
  I don't think it's related to any changes I've made. I'm running
  debian "unstable" and haven't been able to update in several weeks.
  If it persists after an update, then I'll chase it.

o Ivan proposed pcibios_set_bridge_ctl(); I used "pcibios_init_bus()".
  The calling location in pci_do_scan_bus() seemed like a per-bus
  initialization point rather than a narrow/specific task.
  I'd like to make use of pcibios_init_bus() in the parisc port.
  I've only modified arch/i386 to provide pcibios_init_bus().

o For each secondary bus, pci_setup_bridge() gets called before
  pcibios_init_bus().  The former handles generic PCI-PCI bridge and the
  later deals with arch specific (eg Host-PCI bridge) stuff. However
  the difference is on the primary bus - only pcibios_init_bus() is called.
  FWIW, PA-RISC host-PCI bridges support FBB and I would like to add support
  to enable FBB on the primary busses (yes - plural!).

o I intentionally put all FBB support in pci_setup_bridge() (arch common).
  FBB could also live in the arch specific location (pcibios_init_bus())
  but then that gets replicated for each arch. Not sure if that's a
  problem or not. The trade off is how arch code interacts with common
  code for FBB support on the primary bus(ses).

thanks!
grant



--- 2.4.4-orig/arch/i386/kernel/pci-i386.c  Mon Aug  7 14:31:40 2000
+++ 2.4.4/arch/i386/kernel/pci-i386.c   Sun Jun 17 02:30:29 2001
@@ -324,6 +324,11 @@ int pcibios_enable_resources(struct pci_
}
if (dev->resource[PCI_ROM_RESOURCE].start)
cmd |= PCI_COMMAND_MEMORY;
+
+   /* If bridge/bus controller has FBB enabled, child must too. */
+   if (dev->bus->bridge_ctl & PCI_BRIDGE_CTL_FAST_BACK)
+   cmd |= PCI_COMMAND_FAST_BACK;
+
if (cmd != old_cmd) {
printk("PCI: Enabling device %s (%04x -> %04x)\n", dev->slot_name, 
old_cmd, cmd);
pci_write_config_word(dev, PCI_COMMAND, cmd);
--- 2.4.4-orig/arch/i386/kernel/pci-pc.cThu Apr 19 22:57:06 2001
+++ 2.4.4/arch/i386/kernel/pci-pc.c Sun Jun 17 02:46:26 2001
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1015,6 +1016,29 @@ struct pci_fixup pcibios_fixups[] = {
 };
 
 /*
+ * Called before each bus is probed. Allows us to tweak struct pci_bus *.
+ */
+void __init pcibios_init_bus(struct pci_bus *b)
+{
+   struct pci_dev *dev = b->self;
+
+   /* If host PCI bridge supports FBB, could add support here and
+   ** in pcibios_fixup_bus(). For the moment, hope the BIOS is
+   ** smart enough to take advantage of FBB.
+   */
+
+   /* don't forward all "ISA" IO addresses */
+   if (dev && (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE)
+   && ((dev->class >> 8) == PCI_CLASS_BRIDGE_PCI)
+   && !(b->bridge_ctl | PCI_BRIDGE_CTL_NO_ISA) )
+   {
+   b->bridge_ctl |= PCI_BRIDGE_CTL_NO_ISA;
+   pci_write_config_word(dev, PCI_BRIDGE_CONTROL, b->bridge_ctl);
+   }
+}
+
+
+/*
  *  Called after each bus is probed, but before its children
  *  are examined.
  */
@@ -1023,6 +1047,11 @@ void __init pcibios_fixup_bus(struct pci
 {
pcibios_fixup_ghosts(b);
pci_read_bridge_bases(b);
+
+   /* if any i386 PCI host bus adapters support FBB, test FBB bit
+   ** in b->bridge_ctl (dis-) enable FBB in the host bus adapter.
+   ** Also look at comments in pcibios_init_bus().
+   */
 }
 
 /*
--- 2.4.4-orig/drivers/pci/pci.cThu Apr 19 08:38:48 2001
+++ 2.4.4/drivers/pci/pci.c Sun Jun 17 03:06:58 2001
@@ -36,6 +36,7 @@
 
 LIST_HEAD(pci_root_buses);
 LIST_HEAD(pci_devices);
+unsigned int pci_post_reset_delay = 50;/* spec says 1sec but this works */
 
 /**
  * pci_find_slot - locate PCI device from a given PCI slot
@@ -978,9 +979,17 @@ static int __init pci_scan_bridge(struct
}
} else {
/*
-* We need to assign a number to this bus which we always
-* do in the second pass. We also keep all address decoders
-* on the bridge disabled during scanning.  FIXME: Why?
+* Assign a number to 

Re: getrusage vs /proc/pid/stat?

[Pete Wyckoff]

[EMAIL PROTECTED] said:
> I'd like to monitor CPU, memory, and I/O utilization in a 
> long-running multithreaded daemon under kernels 2.2, 2.4,
> and possibly also Solaris (#ifdefs are ok).
> 
> getrusage() looked promising, and might even work for CPU utilization.
> Dunno if it returns info for all child threads yet, haven't tried it.
> In Linux, though, getrusage() doesn't return any info about RAM.
> 
> I know I can get the RSS and VSIZE under Linux by parsing /proc/pid/stat,
> but was hoping for a faster interface (although I suppose a seek,
> a read, and an ascii parse isn't *that* slow).  Is /proc/pid/stat
> the only way to go under Linux to monitor RSS?

getrusage() isn't really the system call you want for this.

There is a max RSS value, which linux could support but doesn't, but
you seem to want to see the current RSS over time.  Search the archive
for various patches/complaints about getrusage.

For vsize, most OSes offer time-integral averages of text, data, and
stack sizes via getrusage().  Again, more of an aggregate than a current
snapshot, and again, linux returns zero for these currently.

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

Re: Looking for ifenslave.c

[Thomas Davis]

PALFFY Daniel wrote:
> 
> On Thu, 14 Jun 2001, Thomas Davis wrote:
> 
> > Guus, there isn't a really official version of it..
> >
> > At http://pdsf.nersc.gov/linux/ifenslave.c is the last version I
> > produced, that works with bonding in v2.2 and v2.4 kernels.
> 
> > Guus Sliepen wrote:
> > >
> > > Hello,
> > >
> > > The Ethernet bonding module is useless without ifenslave.c. I'm making a Debian
> > > package for it, and I have tried to find the "offical" distribution of this
> > > small program. I could not find an authorative source, instead a lot of copies
> > > and patched versions are scattered around the Internet (I maintain a patched
> > > version myself too).
> > >
> > > I would like to combine all the useful extra features and patches into this
> > > Debian package, so if you know of a patched version or maintain one yourself,
> > > please send it to me.
> 
> The only bonding driver and ifenslave that worked for me was the patched
> version from http://sourceforge.net/projects/bonding . It runs fine over a
> quad starfire card, with vlans over it (ben's patch). You might consider
> packaging the ifenslave from that patch, and packaging the bonding driver
> as a kernel patch...
> 

Yea, and that ifenslave won't work with redhat's network setup files,
which has been in place for years.  Notice I'm not on that page?  I
considered it a forked version.  It also does things I talked to becker
about, that is not nice to the system (MII polling as often it does is
bad.)

When I created the first 2.2 bonding patch, I didn't want to have to
rewrite redhat's already in place ifenslave support (from the 2.0.xx
kernel patch).  The ifenslave listed on that page is broken in that
regard.

The original ifenslave bonded a device to a master that was already up
and running;  the master device was used also a xmit device  (so it
routed packets, and sometimes transmitted them).  So, if the master
device died, the slave(s) died with it.  Not good.  Redhat config files
assumed the master was up and running, and you can add a slave to it
without any problems.  The slave device also picks up it's mac address
from the master device.

The version I created, the master device does nothing but route packets
to slaves.  This has a simple problem - no known mac hardware address. 
(ie, it's 0:0:0:0:0:0:0:0) That's bad.  To set a hardware mac address,
you need to down, change the hw mac, and re-up the device.  But,
redhat's scripts already assume the master is up and running, and
downing the master to setup the mac hw means all IP routing information
is lost.  So I added the BOND_SETHWADDR, which allows ifenslave to add a
mac address to the bond master without killing any IP routing
information.  But that's not totally correct either, since adding a mac
hw address can screw up the arp tables (it appears not to, but that's
just plain lucky).

So, in summary, bonding is hack, I strongly dis-agree with what is at
http://sourceforge.net/projects/bonding, but my hands are currently tied
on doing much about it (I could, but I could suffer from consequences)

-- 
+--
Thomas Davis| ASG Cluster guy
[EMAIL PROTECTED] | 
(510) 486-4524  | "80 nodes and chugging Captain!"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: very strange (semi-)lockups in 2.4.5

[Albert D. Cahalan]

Pozsar Balazs writes:

> I'm having ~2 lockups a day. The following happens:
>  If I was under X, i only can use the magic-key, but no other keyboard (eg
> numlock) or mouse response, the screen freezes, processes stop.
>  If i was using textmode:
>   numlock still works
>   cursor blinks
>   processess stop (eg, gpm doesn't work, outputs freeze)
>   i can still switch vt's.
>   BUT, i can only type into a few vt's, last time into 3,5,6,7,8, but not
> into 1,2 or 4!
> 
> I cannot give you any traces, as i dont have any.
> 
> Also note that magic-key works, and it says that it umounts filesystems if
> i press magic-u, but next time at mount i see that reiserfs is replaying
> transactions.
> 
> 
> Any ideas?
> 
> The machine is a P3-750, 512M ram, abit vp6 mb. No overclocking, and it
> passes memtest86.

I think I'm getting the same thing, but I don't have the magic-key
compiled in. I'm going to hook up a VT510 to the serial port, in case
this is just XFree86 crashing. For anyone collecting statistics:

kernels 2.4.4-pre6 (?) and now 2.4.6-pre3
plain Pentium MMX @ 200 MHz
Intel motherboard -- see below
stable since 1996, on a UPS, dust-free, and the fan works
one lockup per day with desktop usage

In case the serial console doesn't work, could someone post plans
for a safe NMI board? (both ISA and PCI) The best I found:
http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/02/msg00425.html
http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/02/msg00391.html
(for PCI you're supposed to assert SERR# on the clock -- how?)

00:00.0 Host bridge: Intel Corporation 430TX - 82439TX MTXC (rev 01)
00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 01)
00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01)
00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01)
00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 01)
00:11.0 Ethernet controller: Digital Equipment Corporation DECchip 21040 [Tulip] (rev 
23)
00:13.0 Ethernet controller: Lite-On Communications Inc LNE100TX Fast Ethernet Adapter 
(rev 25)
00:14.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro 215GP (rev 5c)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.2.20pre3aa1

[Andrea Arcangeli]

Diff between 2.2.20pre2aa1 and 2.2.20pre3aa1 (besides moving on top of
2.2.20pre3 that notably fixes the ptrace local DoS races):


Only in 2.2.20pre2aa1: 00_andi-mark_bh-1

Merged in 2.2.20pre3.

Only in 2.2.20pre3aa1: 00_alpha-pci-compile-1

Fix alpha pci_controller_num.

(recommended)

Only in 2.2.20pre3aa1: 00_newboot-2.2.20-pre2-1.diff.gz

Support new boot protocol in sync with 2.4 for new bootloaders.

(nice to have)

Only in 2.2.20pre3aa1: 00_nfs-lseek-1

Make SEEK_CUR offset 0 to return the current vfs file offset on nfs to
cure userspace. Fix from Andi.

(recommended)

Only in 2.2.20pre2aa1: 00_parent-timeslice-loss-fix-3
Only in 2.2.20pre3aa1: 00_parent-timeslice-loss-fix-4

Rebuild the asm_offsets.h for sparc and sparc64 after the ptrace fix
and fixup the trivial reject generated by the ptrace DoS fixes.

(recommended)

Only in 2.2.20pre3aa1: 00_tcp-syn-during-established-1

Reject any duplicate syn carrying payload, process the syn
during established after checking if rst is set in the incoming
packet (that's a faster path) and send ack back after a duplicate
valid syn. From Andi.

(recommended)

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

Re: ipchains

[D. Stimits]

Ted Gervais wrote:
> 
> I just ran into something odd. To me anyways, it was odd.
> I just installed and brought up kernel 2.4.5 and my ipchains failed.
> So I upgraded to the latest (that I could find) ipchains-1.3.10, and
> that also fails.
> 
> Has anyone got any version of ipchains to work with the new(er) kernels?
> 
> ---
> Doubt is not a pleasant condition, but certainty is absurd.
> -- Voltaire
> 
> Ted Gervais <[EMAIL PROTECTED]>
> 44.135.34.201 linux.ve1drg.ampr.org
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

It works, but you can't load iptables modules at the same time as
ipchains. Be sure ipchains is the only module you are loading. rmmod any
iptables items before modprobe of ipchains. If you are running redhat,
also do not believe the script in /etc/rc.d/init.d/ipchains as to
whether or not ipchains is actually running, it is broken (does not
check return values), and lies and does not tell you when ipchains
startup fails (as root manually do something like ipchains -L -n).

D. Stimits, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Strange behaviour of swap under 2.4.5-ac15

[Andrea Arcangeli]

On Mon, Jun 18, 2001 at 01:44:29PM -0300, Rik van Riel wrote:
> On Mon, 18 Jun 2001, Andrea Arcangeli wrote:
> > On Mon, Jun 18, 2001 at 11:54:09AM -0300, Rik van Riel wrote:
> > > YOUR PATCH fixes a real bug, true.  But that wasn't
> > > what German was complaining about ;)
> >
> > How did you know that before he made his first reply to my email?
> 
> Because he started the thread and I read his first email? ;)

from his first email it sounded like it was such bug, or at least it
wasn't possible to say it wasn't.

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

Re: Simple example of using slab allocator?

[Andreas Dilger]

Matthew Dharm writes:
> For 2.5, I'm planning on switching my driver over to the slab allocator,
> for a variety of reasons.  Does anyone have a _dead_ simple example of how
> to use such a beast?  I've seen the various web pages and document
> explaining the API, but I love to see working examples for reference (and
> to fill in the blanks).

The slab allocator IS dead simple to use, basically:

- driver global variable:

kmem_cache_t *usb_mass_cachep;

- in the driver init function:

usb_mass_cachep = kmem_cache_create("usb_mass_cache",
sizeof(struct whatever),
0, SLAB_HWCACHE_ALIGN,
NULL, NULL);
(check for NULL usb_mass_slab)

- in the driver cleanup function:

if (usb_mass_cachep && kmem_cache_destroy(usb_mass_cachep))
printk(KERN_ERR "usb_mass_cache: not all structures freed\n");

- wherever you need an item from the slab cache:

whateverp = kmem_cache_alloc(usb_mass_cachep, GFP_KERNEL);
(check for NULL whateverp)

- when you are done with it:

kmem_cache_free(usb_mass_cachep, whateverp);

Notes:
- if you have a slab leak and you don't free all of the items (hence the slab
  cache is not removed), you will probably get an oops when you reload the
  driver.  You can only have one slab cache per name ("usb_mass_cache" here).
- You may need different alignment (SLAB_HWCACHE_ALIGN), or not
- You may need different allocation policy (GFP_KERNEL), or not

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/   -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] devfs v181 available

[Alexander Viro]

On Mon, 18 Jun 2001, Richard Gooch wrote:

> > Irrelevant. BKL provides an exclusion only on non-blocking areas.
> 
> Yeah, I know all that.

So what the hell are you talking about?

> > _Moved_ them there from the callers of these functions. And AFAICS
> > you do need BKL for get_devfs_entry_...(); otherwise relocation of
> > the table will be able to screw you inside of that function. Now, it
> > will merrily screw you anyway in a lot of places, but that's another
> > story.
> 
> OK, so it was another global change.

Moving BKL into the ->readlink() and ->follow_link()? Sure, it was a global
change. About a year ago.

> Question: assuming data fed to vfs_follow_link() is "safe", does it

> need the BKL? I can see that vfs_readlink() obviously doesn't need
> it. From reading Documentation/filesystems/Locking I suspect it
> doesn't need the BKL, but the way I read it says "follow_link() method
> does not *have* the BKL already". But that doesn't explicitely say
> whether vfs_follow_link() needs it.

vfs_follow_link() doesn't need it. Moreover, if data fed to it is unsafe
without BKL, you are screwed even if you take BKL. So assumption above
is bogus - you _never_ need BKL on that call.

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

Re: Client receives TCP packets but does not ACK

[Jonathan Morton]

>  > Btw: can the aplication somehow ask the tcp/ip stack what was 
>actualy acked?
>>  (ie. how many bytes were acked).
>
>no, but it's not necessarily a useful number anyhow -- because it's
>possible that the remote end ACKd bytes but the ACK never arrives.  so you
>can get into a situation where the remote application has the entire
>message but the local application doesn't know.  the only way to solve
>this is above the TCP layer.  (message duplicate elimination using an
>unique id.)

No, because if the ACK doesn't reach the sending machine, the sender 
will retry the data until it does get an ACK.  So the sender always 
has information about some amount of data which is guaranteed to have 
arrived at the other end.  The receiver might know about this sooner, 
but that's simply a function of network latency.

The fundamental problem, if I understand right, is that some stacks 
allow packets indicating closing of a connection (FIN) to arrive 
before the actual data at the end of the connection does.  The only 
workaround I can think of for this is for the closing stack to wait 
until all sent data has been ACKed before sending the FIN.  The ACK 
may, of course, never arrive, but that's what round-trip timeouts are 
for.
-- 
--
from: Jonathan "Chromatix" Morton
mail: [EMAIL PROTECTED]  (not for attachments)
website:  http://www.chromatix.uklinux.net/vnc/
geekcode: GCS$/E dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$
   V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
tagline:  The key to knowledge is not to rely on people to teach you it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ps2 keyboard filter hook

[Dan Streetman]

>I find it very odd indeed with IBM's big voice of open source
>praise, yada yada, and what Lou has said in the past, that there
>would be any question at all of wether it would be open source or
>not.  Isn't big blue behind open source?  Or is it just for
>publicity?  Makes me wonder now...

Yes, IBM is definately behind OSS, but that doesn't mean everything is suddenly
opened...and for many people, it's still got to have a 'business' (or legal)
reason to be made open (apart from the technical benefits of OSS)...

IBM is one of the biggest companies around, and obviously everyone can't do a
mental 180 in a short period of time...;-)

Although I just got here a year ago, so I don't really know what it was like in
the 'old days' :)

>Must be some real good rocket science in that interface that
>theres no way on earth someone else could come up with it for it
>to be important IP to protect.  Makes me wonder what's hiding
>behind it...

I actually think that in this case (and possibly many others) it's not a case
of wanting to 'protect' amazing code or design, but more that people are used to
working a certain way (closed), and it's hard to change.  They still have a
'reflex' that tells them to keep it closed, and need a good business (or legal)
reason to open it...instead of asking 'why not?' they ask 'why?'.

In this specific case, the obvious benefits like peer review, increased user and
developer base, etc. were ignored; they thought the user and/or developer base
(any retail company or ISV) was too specific and/or small.

--
Dan Streetman
[EMAIL PROTECTED]
--
186,282 miles per second:
It isn't just a good idea, it's the law!




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

Re: Strange behaviour of swap under 2.4.5-ac15

[Rik van Riel]

On Mon, 18 Jun 2001, Andrea Arcangeli wrote:
> On Mon, Jun 18, 2001 at 11:54:09AM -0300, Rik van Riel wrote:
> > YOUR PATCH fixes a real bug, true.  But that wasn't
> > what German was complaining about ;)
>
> How did you know that before he made his first reply to my email?

Because he started the thread and I read his first email? ;)

Rik
--
Executive summary of a recent Microsoft press release:
   "we are concerned about the GNU General Public License (GPL)"


http://www.surriel.com/
http://www.conectiva.com/   http://distro.conectiva.com/

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

Re: ipchains

[Fabian Arias]

ronto:~# uname -r
2.4.5-ac15
ronto:~# ipchains --version
ipchains 1.3.10, 1-Sep-2000
ronto:~# ipchains -L
Chain input (policy ACCEPT):
target prot opt sourcedestination   ports
DENY   all  l-  pD951B780.dip.t-dialin.net anywhere
n/a
DENY   all  l-  CM-46-30.chello.cl   anywhere  n/a
DENY   all  l-  199.103.178.1anywhere  n/a
..

Are you shure you get it right into the kernel?.

On Mon, 18 Jun 2001, Ted Gervais wrote:

> I just ran into something odd. To me anyways, it was odd.
> I just installed and brought up kernel 2.4.5 and my ipchains failed.
> So I upgraded to the latest (that I could find) ipchains-1.3.10, and
> that also fails.
> 
> Has anyone got any version of ipchains to work with the new(er) kernels?
> 
> ---
> Doubt is not a pleasant condition, but certainty is absurd.
> -- Voltaire
> 
> Ted Gervais <[EMAIL PROTECTED]>
> 44.135.34.201 linux.ve1drg.ampr.org
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

 ---
 Fabian Arias Mu~oz | Debian GNU/Linux Sid
 Facultad de Cs. Economicas y   |  Kernel 2.4.5ac15 - ReiserFS
 Administrativas.   | "aka" dewback en
 Universidad de Concepcion   -  Chile   | #linuxhelp IRC.CHILE

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

Re: Client receives TCP packets but does not ACK

[dean gaudet]

On Mon, 18 Jun 2001, Jan Hudec wrote:

> Btw: can the aplication somehow ask the tcp/ip stack what was actualy acked?
> (ie. how many bytes were acked).

no, but it's not necessarily a useful number anyhow -- because it's
possible that the remote end ACKd bytes but the ACK never arrives.  so you
can get into a situation where the remote application has the entire
message but the local application doesn't know.  the only way to solve
this is above the TCP layer.  (message duplicate elimination using an
unique id.)

if the #bytes ack'd was available it would probably fool people into
implementing buggy code (which of course they do anyhow :)

-dean

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

Re: Error in documentation?

[Steven Walter]

It does appear that the documentation regarding this is out of date.
However, you can still install modules to a given location by:

INSTALL_MOD_PATH="/path/to/modules" make modules_install

Had to dig through the Makefile for that, though it may actually be
documented somewhere.

On Mon, Jun 18, 2001 at 11:15:11AM -0400, Geoffrey Gallaway wrote:
> linux/Documentation/modules.txt says that I should find my modules in
> "linux/modules" after running "make modules". However, this is
> apparently not true as I see no modules directory. 
> 
> I am trying to compile a kernel with lots of modules for a machine
> without a network connection. To move the kernel, I simply copy it to
> floppy and move it over to the other machine. However, for the modules,
> is my only choice appears to be "make modules-install" then tar up
> /lib/modules/kernel-release/ and then remove the directory. Is there a 
> cleaner way to handle this?
-- 
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
-- George Orwell
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

ipchains

[Ted Gervais]

I just ran into something odd. To me anyways, it was odd.
I just installed and brought up kernel 2.4.5 and my ipchains failed.
So I upgraded to the latest (that I could find) ipchains-1.3.10, and
that also fails.

Has anyone got any version of ipchains to work with the new(er) kernels?

---
Doubt is not a pleasant condition, but certainty is absurd.
-- Voltaire

Ted Gervais <[EMAIL PROTECTED]>
44.135.34.201 linux.ve1drg.ampr.org


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

[PATCH] Support for SRM environment variables through procfs

[Jan-Benedict Glaw]

Hi!

I've found a patch on Compaq's Jumpstart-CD which provides access to
SRM'S environment variables. I've ported that patch to 2.4.x and
here's the patch. Please test it. However, I've not got an Alpha
system booting via SRM handy so this patch is untested:-(

MfG, JBG

-- 
Fehler eingestehen, Größe zeigen: Nehmt die Rechtschreibreform zurück!!!
/* Jan-Benedict Glaw <[EMAIL PROTECTED]> -- +49-172-7608481 */
keyID=0x8399E1BB fingerprint=250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB
 "insmod vi.o and there we go..." (Alexander Viro on linux-kernel)


diff -Nur linux-2.4.6-pre1/Documentation/Configure.help 
linux-2.4.6-pre1-srm/Documentation/Configure.help
--- linux-2.4.6-pre1/Documentation/Configure.help   Tue Jun  5 11:24:47 2001
+++ linux-2.4.6-pre1-srm/Documentation/Configure.help   Tue Jun  5 12:15:29 2001
@@ -17311,6 +17311,16 @@
 
   If you're not sure, say N.
 
+SRM environment variables in procfs
+CONFIG_SRM_ENV
+  If you enable this option, a subdirectory called srm_environment
+  will give you access to the most important SRM environment
+  variables. If you've got an Alpha style system supporting
+  SRC, then it is a good idea to say Yes or Module to this driver.
+
+  This driver is also available as a module and will be called
+  srm_env.o if you build it as a module.
+  
 Footbridge internal watchdog
 CONFIG_21285_WATCHDOG
   The Intel Footbridge chip contains a builtin watchdog circuit. Say Y 
diff -Nur linux-2.4.6-pre1/arch/alpha/config.in 
linux-2.4.6-pre1-srm/arch/alpha/config.in
--- linux-2.4.6-pre1/arch/alpha/config.in   Tue Jun  5 11:22:08 2001
+++ linux-2.4.6-pre1-srm/arch/alpha/config.in   Tue Jun  5 12:15:29 2001
@@ -179,7 +179,7 @@
-o "$CONFIG_ALPHA_TAKARA" = "y" -o "$CONFIG_ALPHA_EB164" = "y" \
-o "$CONFIG_ALPHA_ALCOR" = "y"  -o "$CONFIG_ALPHA_MIATA" = "y" \
-o "$CONFIG_ALPHA_LX164" = "y"  -o "$CONFIG_ALPHA_SX164" = "y" \
-   -o "$CONFIG_ALPHA_NAUTILUS" = "y" ]
+   -o "$CONFIG_ALPHA_NAUTILUS" = "y" -o "$CONFIG_ALPHA_NONAME" = "y" ]
 then
   bool 'Use SRM as bootloader' CONFIG_ALPHA_SRM
 fi
@@ -235,6 +235,10 @@
"ELFCONFIG_KCORE_ELF\
 A.OUT  CONFIG_KCORE_AOUT" ELF
 fi
+if [ "$CONFIG_PROC_FS" != "n" -a CONFIG_ALPHA_SRM = "y" ]; then
+   tristate 'SRM environment through procfs' CONFIG_SRM_ENV
+fi
+ 
 tristate 'Kernel support for a.out (ECOFF) binaries' CONFIG_BINFMT_AOUT
 tristate 'Kernel support for ELF binaries' CONFIG_BINFMT_ELF
 tristate 'Kernel support for MISC binaries' CONFIG_BINFMT_MISC
diff -Nur linux-2.4.6-pre1/arch/alpha/kernel/Makefile 
linux-2.4.6-pre1-srm/arch/alpha/kernel/Makefile
--- linux-2.4.6-pre1/arch/alpha/kernel/Makefile Tue Jun  5 11:07:28 2001
+++ linux-2.4.6-pre1-srm/arch/alpha/kernel/Makefile Tue Jun  5 12:15:29 2001
@@ -32,6 +32,7 @@
 
 obj-$(CONFIG_SMP)+= smp.o irq_smp.o
 obj-$(CONFIG_PCI)+= pci.o pci_iommu.o
+obj-$(CONFIG_SRM_ENV)  += srm_env.o
 
 ifdef CONFIG_ALPHA_GENERIC
 
diff -Nur linux-2.4.6-pre1/arch/alpha/kernel/alpha_ksyms.c 
linux-2.4.6-pre1-srm/arch/alpha/kernel/alpha_ksyms.c
--- linux-2.4.6-pre1/arch/alpha/kernel/alpha_ksyms.cTue Jun  5 11:22:08 2001
+++ linux-2.4.6-pre1-srm/arch/alpha/kernel/alpha_ksyms.cTue Jun  5 12:16:35 
+2001
@@ -18,6 +18,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -56,6 +57,11 @@
 EXPORT_SYMBOL(probe_irq_mask);
 EXPORT_SYMBOL(screen_info);
 EXPORT_SYMBOL(perf_irq);
+#ifdef CONFIG_ALPHA_SRM
+EXPORT_SYMBOL(callback_getenv);
+EXPORT_SYMBOL(callback_setenv);
+EXPORT_SYMBOL(callback_save_env);
+#endif /* CONFIG_ALPHA_SRM */
 
 /* platform dependent support */
 EXPORT_SYMBOL(_inb);
diff -Nur linux-2.4.6-pre1/arch/alpha/kernel/srm_env.c 
linux-2.4.6-pre1-srm/arch/alpha/kernel/srm_env.c
--- linux-2.4.6-pre1/arch/alpha/kernel/srm_env.cThu Jan  1 01:00:00 1970
+++ linux-2.4.6-pre1-srm/arch/alpha/kernel/srm_env.cTue Jun  5 12:15:29 2001
@@ -0,0 +1,219 @@
+/*
+ * srm_env.c - Access to SRC environment variables through
+ * the linux procfs
+ *
+ * (C)2001, Jan-Benedict Glaw <[EMAIL PROTECTED]>
+ *
+ * This driver is at all a modified version of Erik Mouw's
+ * ./linux/Documentation/DocBook/procfs_example.c, so: thanky
+ * you, erik! He can be reached via email at
+ * <[EMAIL PROTECTED]>. It is based on an idea
+ * provided by DEC^WCompaq's "Jumpstart" CD. They included
+ * a patch like this as well. Thanks for idea!
+ *
+ *
+ * This software has been developed while working on the LART
+ * computing board (http://www.lart.tudelft.nl/). The
+ * development has been sponsored by the Mobile Multi-media
+ * Communications (http://www.mmc.tudelft.nl/) and Ubiquitous
+ * Communications (http://www.ubicom.tudelft.nl/) projects.
+ *
+ * This program is free software; you can redistribute
+ * it and/or modify it under the terms of the GNU General
+ * Public License as published by the Free Software
+ * Foundation version 2.
+ *
+ * This program is distributed in the hope 

Re: problem with write() to a socket and EPIPE

[Richard B. Johnson]

On Mon, 18 Jun 2001 [EMAIL PROTECTED] wrote:

> Hello,
> 
> I've the following problem.
> If the peer has closed its socket connection the second write to this 
> socket should return -1 and errno should be set to EPIPE (if SIGPIPE is 
> set  
> to be ignored). This never happens with my code. Why?
> 

So what errno does it return? Writing to a closed socket can
return several things, based upon what was detected first. I
don't think you can count on a specific errno value. Successful
socket handlers use the following heuristics:

If the returned value was -1, the error is temporary, try again.
If the returned value was 0, the error is permanent.

The first write to a closed socket may return -1, with an errno
of something representative of local buffers being full. It takes
some time for a FIN or a RST to show up as the reason why there
is so much data queued. So, if you follow the above heuristic,
the last reason why you got the previous errors will likely be
what you expect.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


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

Re: Unresolved symbol do_softirq in 2.4.6-pre3

[Jeff Chua]

On Mon, 18 Jun 2001, Mohammad A. Haque wrote:

> On Mon, 18 Jun 2001, Anuradha Ratnaweera wrote:
>
> > I started running 2.4.6-pre3 using the same configuration file as 2.4.5.
> > Diff shows no effective differences between two config files.
> >
> > depmod complains unresolved symbols (do_softirq) in ppp_generic, ppp_async
> > and sunrpc.
> >
>
> Please check the list archives. A possible solution was posted by Keith
> owens
> .

Try this ...

Jeff.


--- include/asm-i386/softirq.h  Thu Jun 14 17:10:34 2001
+++ include/asm-i386/softirq.h.new  Thu Jun 14 17:17:15 2001
@@ -36,13 +36,13 @@
\
".section .text.lock,\"ax\";"   \
"2: pushl %%eax; pushl %%ecx; pushl %%edx;" \
-   "call do_softirq;"  \
+   "call %c1;" \
"popl %%edx; popl %%ecx; popl %%eax;"   \
"jmp 1b;"   \
".previous;"\
\
: /* no output */   \
-   : "r" (ptr) \
+   : "r" (ptr), "i" (do_softirq)   \
/* no registers clobbered */ ); \
 } while (0)


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

Re: [PATCH] devfs v181 available

[Richard Gooch]

Alexander Viro writes:
> On Mon, 18 Jun 2001, Richard Gooch wrote:
> > Alexander Viro writes:
> > > On Mon, 18 Jun 2001, Richard Gooch wrote:
> > > > - Widened locking in  and 
> > > 
> > > No, you hadn't. Both vfs_readlink() and vfs_follow_link() are blocking
> > > functions, so BKL is worthless there.
> > 
> > Huh? The BKL will protect against other operations which might cause
> > the devfs entry to be unregistered, where those other operations also
> > grab the BKL. So, it's an improvement.
> 
> BKL is released as soon as you block. You _do_ regain it when you get
> the next timeslice, but in the meanwhile anything could happen.
> 
> > Sure, some operations may cause unregistration without grabbing the
> 
> Irrelevant. BKL provides an exclusion only on non-blocking areas.

Yeah, I know all that.

> > BKL, but that's orthogonal (and requires more extensive changes). If
> > this "widening" is of no use, then what use are the existing grabs of
> > the BKL in those functions? You're the one who added them in the first
> > place.
> 
> _Moved_ them there from the callers of these functions. And AFAICS
> you do need BKL for get_devfs_entry_...(); otherwise relocation of
> the table will be able to screw you inside of that function. Now, it
> will merrily screw you anyway in a lot of places, but that's another
> story.

OK, so it was another global change.

> BTW, free advice: when you are checking some condition treat the
> result as something that can expire. And don't rely on it past the
> moment when it might expired. E.g. in case of de->registered result
> expires as soon as you do unlock_kernel() _or_ do anything that
> might block.

Yeah, I know. Fear not: I'll be adding proper locks (spinlocks and
semaphores) to the code, continuing the work I started this weekend. I
don't like the BKL anyway (too coarse grained), and hope to see it
removed entirely one day.

Question: assuming data fed to vfs_follow_link() is "safe", does it
need the BKL? I can see that vfs_readlink() obviously doesn't need
it. From reading Documentation/filesystems/Locking I suspect it
doesn't need the BKL, but the way I read it says "follow_link() method
does not *have* the BKL already". But that doesn't explicitely say
whether vfs_follow_link() needs it.

Regards,

Richard
Permanent: [EMAIL PROTECTED]
Current:   [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Error in documentation?

[Geoffrey Gallaway]

linux/Documentation/modules.txt says that I should find my modules in
"linux/modules" after running "make modules". However, this is
apparently not true as I see no modules directory. 

I am trying to compile a kernel with lots of modules for a machine
without a network connection. To move the kernel, I simply copy it to
floppy and move it over to the other machine. However, for the modules,
is my only choice appears to be "make modules-install" then tar up
/lib/modules/kernel-release/ and then remove the directory. Is there a 
cleaner way to handle this?

Geoffeg

-- 
Geoffrey Gallaway || 
[EMAIL PROTECTED] || Clones are people two.
D e v o r z h u n ||
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Strange behaviour of swap under 2.4.5-ac15

[Andrea Arcangeli]

On Mon, Jun 18, 2001 at 11:54:09AM -0300, Rik van Riel wrote:
> YOUR PATCH fixes a real bug, true.  But that wasn't
> what German was complaining about ;)

How did you know that before he made his first reply to my email?

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

Re: Strange behaviour of swap under 2.4.5-ac15

[Rik van Riel]

On Mon, 18 Jun 2001, Andrea Arcangeli wrote:

> > which is now a lot closer to being balanced. It's not a bug,
>
> wrong, that was a core showstopper bug and it renders any
> machine with a zone empty unusable. (it has nothing to do with
> beauty or stats)

YOUR PATCH fixes a real bug, true.  But that wasn't
what German was complaining about ;)

Rik
--
Executive summary of a recent Microsoft press release:
   "we are concerned about the GNU General Public License (GPL)"


http://www.surriel.com/
http://www.conectiva.com/   http://distro.conectiva.com/

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

problem with write() to a socket and EPIPE

[oliver . kowalke]

Hello,

I've the following problem.
If the peer has closed its socket connection the second write to this 
socket should return -1 and errno should be set to EPIPE (if SIGPIPE is 
set  
to be ignored). This never happens with my code. Why?

OS: Linux (Debian 2.2r3)
kernel: 2.4.4
compiler: gcc-2.95.2
c-lib: libc-2.1.3

with best regards,
Oliver

(writen() is a member function of my socket C++-class)

ssize_t
sock::writen( const void * vptr, size_t n)
{
size_t  nleft;
ssize_t nwritten;
const char  *ptr;

ptr = static_cast< char * >( vptr);
nleft = n;

struct sigaction new_sa;
struct sigaction old_sa;

new_sa.sa_handler = SIG_IGN;
::sigemptyset( & new_sa.sa_mask);
new_sa.sa_flags = 0;
::sigaction( SIGPIPE, & new_sa, & old_sa);  

while ( nleft > 0)
{
if ( ( nwritten = ::write( m_handle, ptr, nleft) ) <= 
0) 
{
if ( errno == EINTR)

nwritten = 0;   /* and call 
write() again */ 

else if ( errno == EPIPE)

return EOF; /* write to 
socket with no readers */ 

else

throw net_io_ex( ::strerror( errno), 
"writen()", __FILE__); /* error */ 

}

nleft -= nwritten;
ptr   += nwritten;
}
/* set to its previous action */
::sigaction( SIGPIPE, & old_sa, 0);

return n;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Unresolved symbol do_softirq in 2.4.6-pre3

[Mohammad A. Haque]

On Mon, 18 Jun 2001, Anuradha Ratnaweera wrote:

> I started running 2.4.6-pre3 using the same configuration file as 2.4.5.
> Diff shows no effective differences between two config files.
>
> depmod complains unresolved symbols (do_softirq) in ppp_generic, ppp_async
> and sunrpc.
>

Please check the list archives. A possible solution was posted by Keith
owens
.

-- 

=
Mohammad A. Haque  http://www.haque.net/
   [EMAIL PROTECTED]

  "Alcohol and calculus don't mix. Project Lead
   Don't drink and derive." --Unknown  http://wm.themes.org/
   [EMAIL PROTECTED]
=

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

Re: spindown [was Re: 2.4.6-pre2, pre3 VM Behavior]

[Daniel Phillips]

On Sunday 17 June 2001 12:05, Mike Galbraith wrote:
> It _juuust_ so happens that I was tinkering... what do you think of
> something like the below?  (and boy do I ever wonder what a certain
> box doing slrn stuff thinks of it.. hint hint;)

It's too subtle for me ;-)  (Not shy about sying that because this part of 
the kernel is probably subtle for everyone.)

The question I'm tackling right now is how the system behaves when the load 
goes away, or doesn't get heavy.  Your patch doesn't measure the load 
directly - it may attempt to predict it as a function of memory pressure, but 
that's a little more loosely coupled than what I had in mind.

I'm now in the midst of hatching a patch. [1] The first thing I had to do is 
go explore the block driver code, yum yum.  I found that it already computes 
the statistic I'm interested in, namely queued_sectors, which is used to pace 
the IO on block devices.  It's a little crude - we really want this to be 
per-queue and have one queue per "spindle" - but even in its current form 
it's workable.

The idea is that when queued_sectors drops below some threshold we have 
'unused disk bandwidth' so it would be nice to do something useful with it:

  1) Do an early 'sync_old_buffers'
  2) Do some preemptive pageout

The benefit of (1) is that it lets disks go idle a few seconds earlier, and 
(2) should improve the system's latency in response to load surges.  There 
are drawbacks too, which have been pointed out to me privately, but they tend 
to be pretty minor, for example: on a flash disk you'd do a few extra writes 
and wear it out ever-so-slightly sooner.  All the same, such special devices 
can be dealt easily once we progress a little further in improving the 
kernel's 'per spindle' intelligence.

Now how to implement this.  I considered putting a (newly minted) 
wakeup_kflush in blk_finished_io, conditional on a loaded-to-unloaded 
transition, and that's fine except it doesn't do the whole job: we also need 
to have the early flush for any write to a disk file while the disks are 
lightly loaded, i.e., there is no convenient loaded-to-unloaded transition to 
trigger it.  The missing trigger could be inserted into __mark_dirty, but 
that would penalize the loaded state (a little, but that's still too much).  
Furthermore, it's probably desirable to maintain a small delay between the 
dirty and the flush.  So what I'll try first is just running kflush's timer 
faster, and make its reschedule period vary with disk load, i.e., when there 
are fewer queued_sectors, kflush looks at the dirty buffer list more often.

The rest of what has to happen in kflush is pretty straightforward.  It just 
uses queued_sectors to determine how far to walk the dirty buffer list, which 
is maintained in time-since-dirtied order.  If queued_sectors is below some 
threshold the entire list is flushed.  Note that we want to change the sense 
of b_flushtime to b_timedirtied.  It's more efficient to do it this way 
anyway.

I haven't done anything about preemptive pageout yet, but similar ideas apply.

[1] This is an experiment, do not worry, it will not show up in your tree any 
time soon.  IOW, constructive criticism appreciated, flames copied to 
/dev/null.

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

Re: Strange behaviour of swap under 2.4.5-ac15

[Andrea Arcangeli]

On Mon, Jun 18, 2001 at 10:43:14AM -0300, Rik van Riel wrote:
> On Mon, 18 Jun 2001, Andrea Arcangeli wrote:
> 
> > either apply this patch to 2.4.5ac15:
> > 
> > 
>ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.5aa3/00_fix-unusable-vm-on-alpha-1
> 
> That one has already been fixed in -pre3 and I think also

wrong, I merged it with Linus in pre2 not pre3.

> in -ac14+ kernels (haven't verified the -ac kernels, though).

wrong -ac15 is still missing it.

> which is now a lot closer to being balanced. It's not a bug,

wrong, that was a core showstopper bug and it renders any machine with a
zone empty unusable. (it has nothing to do with beauty or stats)

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

Re: your mail

[Jan Hudec]

> So it seems that PnP finds the card, but the connections (or even the
> forced values) to the sb module fail.  Back when this was a single
> processor machine, but still running 2.4 kernel, a windoze
> installation found the SB at the listed interface parameters.
> 
> 
> Anyone have a solution?
> 
> Same problem without modules.conf settings, valid version of mod
> utilities, a web search did not help,...

I had a similar problem with different card (Gravi Usltrasound PnP).
The solution turned out to be to avoid dma 1 channel. May be some BIOSes
or ISA chipsets got the 8-bit dma channels handling wrong, but I really
don't know. Btw: for me 2.2.x autodetected right, 2.4.x need explicit setting.


- Jan Hudec `Bulb' <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: pivot_root from non-interactive script

[Andreas Schwab]

Ralph Jones <[EMAIL PROTECTED]> writes:

|> I have followed the instructions given in Documentation/initrd.txt with regard to 
|pivot_root, but am unable to unmount the filesystem, when everything is called from a 
|non-interactive script. 
|> 
|> ie. When I set a link from linuxrc to /bin/ash and then manually go through the 
|commands in the shell script, I am able to unmount the old initrd filesystem.  
|However, when linuxrc is a shell script containing the same commands, I am unable to 
|umount the old initrd fs.  I get instead: "Device or resource busy".

Perhaps the shell didn't close the filedescriptor on the script.

Andreas.

-- 
Andreas Schwab  "And now for something
SuSE Labscompletely different."
[EMAIL PROTECTED]
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Strange behaviour of swap under 2.4.5-ac15

[Andrea Arcangeli]

On Mon, Jun 18, 2001 at 10:37:21AM -0300, Rik van Riel wrote:
> Yes, this is expected behaviour with -ac14, -pre3 and newer.

If that means anything that doesn't happen here based on pre3.

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

Re: APM, ACPI, and Wake on LAN - the bane of my existance

[Alex Deucher]

Pavel Machek wrote:
> 
> Hi!
> 
> > anything.  So I removed the three pin cross connect that connects the
> > card to the WOL header on the motherboard.  That fixed it for a few
> > days, but now it's doing it again, even without the cable installed.
> > the only fix is to unplug the ethernet cable when I turn it off.
> 
> So turn it off by unplugging AC cord. If it comes up *without* AC plugged
> in Welll... Call GhostBusters.
> Pavel

True, but I'd like to have work without having to unplug the power
everyday :)


> PS: I is possible that machine comes up after powerfail. This might be
> your proble. Without 3pin cable installed, it really should not come up
> itself.

Actually apparently it is possible with PCI 2.2 compliant cards and
motherboards.  The 3 pin wire is for backwards compatiblity with old
cards.


> --
> Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
> details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.


Thanks for you input,

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

Re: Strange behaviour of swap under 2.4.5-ac15

[Andrea Arcangeli]

On Mon, Jun 18, 2001 at 03:34:43PM +0200, Luigi Genoni wrote:
> Maybe there could be some HW related reason because of which it fixed for

yes, most probably he didn't had any zone empty so the fix couldn't make
a difference for him. German, can you confirm? (if you don't know what
it means just show me a SYSRQ+M and I'll find out myself :)

Since the fix didn't helped it sounds like the memory balancing in -ac
is not working properly for other reasons too.

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

Re: Strange behaviour of swap under 2.4.5-ac15

[Rik van Riel]

On Mon, 18 Jun 2001, Andrea Arcangeli wrote:

> either apply this patch to 2.4.5ac15:
> 
>   
>ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.5aa3/00_fix-unusable-vm-on-alpha-1

That one has already been fixed in -pre3 and I think also
in -ac14+ kernels (haven't verified the -ac kernels, though).

The "bug" exists because of a change in refill_inactive(),
which is now a lot closer to being balanced. It's not a bug,
but with the way the statistics are generated it sure look
funny ;)

regards,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/ http://distro.conectiva.com/

Send all your spam to [EMAIL PROTECTED] (spam digging piggy)

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

Re: Strange behaviour of swap under 2.4.5-ac15

[Rik van Riel]

On Mon, 18 Jun 2001, German Gomez Garcia wrote:

>   I've running 2.4.5-ac15 for almost a day (22 hours) and I found
> some strange behaviour of the kswap, at least it was not present in
> 2.4.5-ac9. The swap memory increase with time as the cache dedicated
> memory also increase, that is swapping process at a very fast rate, even
> when no program is getting more memory. Is that the expected behaviour?

Yes, this is expected behaviour with -ac14, -pre3 and newer.

Note that the memory isn't actually swapped out. It's still
sitting in RAM, being counted as swap cache (and because of
this showing up as "cache" in top).

regards,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/ http://distro.conectiva.com/

Send all your spam to [EMAIL PROTECTED] (spam digging piggy)

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

Re: [docPATCH] mm.h documentation

[Pete Wyckoff]

[EMAIL PROTECTED] said:
>  typedef struct page {
[..]
> + unsigned long index;/* Our offset within mapping. */

[..]
> + * A page may belong to an inode's memory mapping. In this case,
> + * page->mapping is the pointer to the inode, and page->offset is the
> + * file offset of the page (not necessarily a multiple of PAGE_SIZE).

Minor nit.

The field offset was renamed to index some time ago, but I can't
figure out if the usage changed.  Can you fix the comment and educate
us?

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

Re: Strange behaviour of swap under 2.4.5-ac15

[Luigi Genoni]

On Mon, 18 Jun 2001, German Gomez Garcia wrote:

> On Mon, 18 Jun 2001, Andrea Arcangeli wrote:
>
> > On Mon, Jun 18, 2001 at 12:14:01PM +0200, German Gomez Garcia wrote:
> > >   Hello,
> > >
> > >   I've running 2.4.5-ac15 for almost a day (22 hours) and I found
> > > some strange behaviour of the kswap, at least it was not present in
> > > 2.4.5-ac9. The swap memory increase with time as the cache dedicated
> > > memory also increase, that is swapping process at a very fast rate, even
> > > when no program is getting more memory. Is that the expected behaviour?
> > >   An example, with no process running (just the usual daemons and
> > > none of them getting extra memory) the command:
> > >
> > >   free ; sleep 60; free
> > >
> > >  total   used   free sharedbuffers cached
> > > Mem:513416 393184 120232364  63276 254576
> > > -/+ buffers/cache:  75332 438084
> > > Swap:   530104  14228 515876
> > >
> > >  total   used   free sharedbuffers cached
> > > Mem:513416 393192 120224364  63276 258412
> > > -/+ buffers/cache:  71504 441912
> > > Swap:   530104  18064 512040
> > >
> > >   Any idea?
> >
> > either apply this patch to 2.4.5ac15:
> >
> > 
>ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.5aa3/00_fix-unusable-vm-on-alpha-1
> >
> > (note it is not an alpha specific bug, it's just that I was triggering
> > all the time on alpha so I called the patch that way)
>
>   It doesn't fix it, swapped memory and cache memory increase at a
> rate of about 40K/s, swapping process very fast, even the "agetty"
> processes get 64 out of 68 K swapped one or two minutes after booting.
> This rate gets lower as nothing but the essential (4K of "agetty", etc) is
> left in the physical memory.
>
I was having similar problems with a sun 3500 with 4 GB of RAM
running 2.4.5 (no problems of this kind with 2.4.4), and this
patch fixed my problems under eavy stress.

I was having the most of memory free and a lot of swap allocated,
and system swapping to dead.

Now it works, with other problems, but when i have time and
permission to try to debug them. :).

Maybe there could be some HW related reason because of which it fixed for
my sun and not for you...

Luigi


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

Re: New Linux Drivers - Configure question

[Chakir Ettayebi]

yes 


On Mon, 18 Jun 2001, Modular Forms Boy wrote:

> 
> I am working on a new framebuffer driver for an LCD controller that's
> custom to the PowerPC embedded world.  As such, it's architecture
> dependent.  Where should I place the driver in the tree, and how should I
> set up the proper Configure options?  Where do I put checks for #ifdef
> CONFIGURE_blah_blah_blah?
> 
> Yours truly,
> David Eger
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

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

Re: Can't free the ramdisk (initrd, pivot_root)

[Ralph Jones]

On Sun Apr 15 2001 - 15:57:52, EST Amit D Chaudhary ([EMAIL PROTECTED]) wrote:

>  On the same topic, I have not found any change in free memory reported before 
>  and after the ioctl call. Though umount /initrd does free around 2 MB. 

I have found the same thing - that umount /initrd seems to free the memory and that 
freeramdisk (with the patch to rd.c) does not appear to do anything.  

I have not found any more correspondance about this topic and was wondering if this 
behaviour was ok.  Specifically I would like to know if I need to apply the rd.c patch 
and then to run freeramdisk, or if I can just leave this out.  

Ralph Jones

Find the best deals on the web at AltaVista Shopping!
http://www.shopping.altavista.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Unresolved symbol do_softirq in 2.4.6-pre3

[Anuradha Ratnaweera]

Hi all,

I started running 2.4.6-pre3 using the same configuration file as 2.4.5.
Diff shows no effective differences between two config files.

depmod complains unresolved symbols (do_softirq) in ppp_generic, ppp_async
and sunrpc.

do_softirq is listed in System.map-2.4.6-pre3.

I started with a new source tree and built the kernel with Debian kernel
package.

Any comment? Thanks in advance.

Regards,

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

Re: Strange behaviour of swap under 2.4.5-ac15

[German Gomez Garcia]

On Mon, 18 Jun 2001, Andrea Arcangeli wrote:

> On Mon, Jun 18, 2001 at 12:14:01PM +0200, German Gomez Garcia wrote:
> > Hello,
> >
> > I've running 2.4.5-ac15 for almost a day (22 hours) and I found
> > some strange behaviour of the kswap, at least it was not present in
> > 2.4.5-ac9. The swap memory increase with time as the cache dedicated
> > memory also increase, that is swapping process at a very fast rate, even
> > when no program is getting more memory. Is that the expected behaviour?
> > An example, with no process running (just the usual daemons and
> > none of them getting extra memory) the command:
> >
> > free ; sleep 60; free
> >
> >  total   used   free sharedbuffers cached
> > Mem:513416 393184 120232364  63276 254576
> > -/+ buffers/cache:  75332 438084
> > Swap:   530104  14228 515876
> >
> >  total   used   free sharedbuffers cached
> > Mem:513416 393192 120224364  63276 258412
> > -/+ buffers/cache:  71504 441912
> > Swap:   530104  18064 512040
> >
> > Any idea?
>
> either apply this patch to 2.4.5ac15:
>
>   
>ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.5aa3/00_fix-unusable-vm-on-alpha-1
>
> (note it is not an alpha specific bug, it's just that I was triggering
> all the time on alpha so I called the patch that way)

It doesn't fix it, swapped memory and cache memory increase at a
rate of about 40K/s, swapping process very fast, even the "agetty"
processes get 64 out of 68 K swapped one or two minutes after booting.
This rate gets lower as nothing but the essential (4K of "agetty", etc) is
left in the physical memory.

> or better use 2.4.6pre3aa1:
>
>   
>ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.6pre3aa1.bz2

I'll test this later as I cannot reboot the machine right now.
Just one question, is this kernel 'stable', I was running 2.4.5-ac9 for
a week without problems, even when 'stress-testing' the emu10k1 and the
mga modules.

Regards,

- german

PS: swapoff -a fixes the problem :-)
-
German Gomez Garcia | "This isn't right.  This isn't even wrong."
<[EMAIL PROTECTED]> | -- Wolfgang Pauli

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

Re: Linux/PPC maintainer changing

[Paul Mackerras]

Cort has put in an enormous amount of time and effort into maintaining
the PowerPC port of Linux over the past 5 or 6 years, and I for one
would like to acknowledge that publicly and thank him for that.  It
has not always been an easy task, I know, because there are a wide
range of opinions within the PPC/Linux camp and Cort has been the man
on the spot to sort out the balance between the competing interests.
And I for one will miss the time, effort and resources he has put into
the infrastructure things such as the repository, web pages, ftp site
etc.

I would also like to thank FSM Labs for contributing the space and
bandwidth for the PPC/Linux repository over the last couple of years.

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

pivot_root from non-interactive script

[Ralph Jones]

Greetings,

I have followed the instructions given in Documentation/initrd.txt with regard to 
pivot_root, but am unable to unmount the filesystem, when everything is called from a 
non-interactive script. 

ie. When I set a link from linuxrc to /bin/ash and then manually go through the 
commands in the shell script, I am able to unmount the old initrd filesystem.  
However, when linuxrc is a shell script containing the same commands, I am unable to 
umount the old initrd fs.  I get instead: "Device or resource busy".

The contents of my linuxrc script are as follows:

#!/bin/ash
export PATH=/bin:/sbin:/usr/bin:/usr/sbin
 
cd /
mkdir /new
mount -t shm /dev/shm /new
cp -pdR * new
 
cd new
pivot_root . initrd
 
cd /
exec chroot . /bin/ash  dev/console 2>&1
-
ash is a static binary.  chroot, mount and pivot_root are from busybox.  

- Ralph Jones

Find the best deals on the web at AltaVista Shopping!
http://www.shopping.altavista.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

New Linux Drivers - Configure question

[Modular Forms Boy]

I am working on a new framebuffer driver for an LCD controller that's
custom to the PowerPC embedded world.  As such, it's architecture
dependent.  Where should I place the driver in the tree, and how should I
set up the proper Configure options?  Where do I put checks for #ifdef
CONFIGURE_blah_blah_blah?

Yours truly,
David Eger

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

Re: Strange behaviour of swap under 2.4.5-ac15

[Andrea Arcangeli]

On Mon, Jun 18, 2001 at 12:14:01PM +0200, German Gomez Garcia wrote:
>   Hello,
> 
>   I've running 2.4.5-ac15 for almost a day (22 hours) and I found
> some strange behaviour of the kswap, at least it was not present in
> 2.4.5-ac9. The swap memory increase with time as the cache dedicated
> memory also increase, that is swapping process at a very fast rate, even
> when no program is getting more memory. Is that the expected behaviour?
>   An example, with no process running (just the usual daemons and
> none of them getting extra memory) the command:
> 
>   free ; sleep 60; free
> 
>  total   used   free sharedbuffers cached
> Mem:513416 393184 120232364  63276 254576
> -/+ buffers/cache:  75332 438084
> Swap:   530104  14228 515876
> 
>  total   used   free sharedbuffers cached
> Mem:513416 393192 120224364  63276 258412
> -/+ buffers/cache:  71504 441912
> Swap:   530104  18064 512040
> 
>   Any idea?

either apply this patch to 2.4.5ac15:


ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.5aa3/00_fix-unusable-vm-on-alpha-1

(note it is not an alpha specific bug, it's just that I was triggering
all the time on alpha so I called the patch that way)

or better use 2.4.6pre3aa1:


ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.6pre3aa1.bz2

If the problem persists let me know thanks.

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

i810 audio problem

[Delio Brignoli]

Switching from 2.4.2 to 2.4.5 breaks i810_audio on my intel MX440 based notebook:

After some (in fact a few) seconds of playback it gets stuck until the app closes and 
reopens /dev/dsp. (I do NOT use esd)

I tried 2.4.4 and 2.4.5 (and the ac patches on both) but it does't work anyway.

Jun 18 13:45:50 argo kernel: Intel 810 + AC97 Audio, version 0.03, 13:40:09 Jun 18 2001
Jun 18 13:45:50 argo kernel: PCI: Setting latency timer of device 00:00.1 to 64
Jun 18 13:45:50 argo kernel: i810: Intel 440MX found at IO 0x1500 and 0x1600, IRQ 5
Jun 18 13:45:50 argo kernel: ac97_codec: AC97 Audio codec, id: 0x4352:0x5934 (Cirrus 
Logic CS4299 rev D)
Jun 18 13:45:50 argo kernel: i810_audio: called i810_set_dac_rate : rate = 48000/48000
Jun 18 13:45:50 argo kernel: i810_audio: allocated 65536 (order = 4) bytes at cb66
Jun 18 13:45:50 argo kernel: i810_audio: prog_dmabuf, sample rate = 48000, format = 3,
Jun 18 13:45:50 argo kernel: ^Inumfrag = 32, fragsize = 2048 dmasize = 65536
Jun 18 13:45:50 argo kernel: i810_audio: 17768 bytes in 50 milliseconds
Jun 18 13:45:50 argo kernel: i810_audio: setting clocking to 25934
Jun 18 13:58:06 argo kernel: i810_audio: called i810_set_dac_rate : rate = 14806/8000

[snip]

Here starts the playback

Jun 18 13:58:06 argo kernel: i810_audio: i810_ioctl, arg=0x0, cmd=SNDCTL_DSP_RESET
Jun 18 13:58:06 argo kernel: i810_audio: i810_ioctl, arg=0x2c, 
cmd=SNDCTL_DSP_SETFRAGMENT 0x1, 4096, 16
Jun 18 13:58:06 argo kernel: i810_audio: i810_ioctl, arg=0x10, cmd=SNDCTL_DSP_SETFMT
Jun 18 13:58:06 argo kernel: i810_audio: i810_ioctl, arg=0x10, cmd=SNDCTL_DSP_SETFMT
Jun 18 13:58:06 argo kernel: i810_audio: i810_ioctl, arg=0x1, cmd=SNDCTL_DSP_STEREO
Jun 18 13:58:06 argo kernel: i810_audio: i810_ioctl, arg=0xac44, cmd=SNDCTL_DSP_SPEED
Jun 18 13:58:06 argo kernel: i810_audio: called i810_set_dac_rate : rate = 40811/22050
Jun 18 13:58:06 argo kernel: i810_audio: i810_ioctl, arg=0x0, cmd=i810_audio: 
allocated 65536 (order = 4) bytes at c788
Jun 18 13:58:06 argo kernel: i810_audio: prog_dmabuf, sample rate = 40811, format = 3,
Jun 18 13:58:06 argo kernel: ^Inumfrag = 32, fragsize = 2048 dmasize = 65536
Jun 18 13:58:06 argo kernel: SNDCTL_DSP_GETBLKSIZE 4096
Jun 18 13:58:07 argo kernel: i810_audio: i810_write called, count = 3788
Jun 18 13:58:07 argo kernel: i810_audio: i810_ioctl, arg=0x0, cmd=SNDCTL_DSP_GETOSPACE 
61748, 4096, 15, 16
Jun 18 13:58:07 argo kernel: i810_audio: i810_write called, count = 3788
Jun 18 13:58:07 argo kernel: i810_audio: i810_ioctl, arg=0xf, cmd=SNDCTL_DSP_GETOSPACE 
60080, 4096, 14, 16
Jun 18 13:58:07 argo kernel: i810_audio: i810_write called, count = 3788
Jun 18 13:58:07 argo kernel: i810_audio: i810_ioctl, arg=0xe, cmd=SNDCTL_DSP_GETOSPACE 
56340, 4096, 13, 16

[snip]

Jun 18 13:58:07 argo kernel: i810_audio: i810_write called, count = 3788
Jun 18 13:58:07 argo kernel: i810_audio: i810_ioctl, arg=0x1, cmd=SNDCTL_DSP_GETOSPACE 
3732, 4096, 0, 16
Jun 18 13:58:07 argo kernel: i810_audio: i810_write called, count = 3788
Jun 18 13:58:07 argo kernel: i810_audio: i810_ioctl, arg=0x0, cmd=SNDCTL_DSP_GETOSPACE 
4074, 4096, 0, 16
Jun 18 13:58:07 argo kernel: i810_audio: i810_write called, count = 3788
Jun 18 13:58:07 argo kernel: i810_audio: i810_ioctl, arg=0x0, cmd=SNDCTL_DSP_GETOSPACE 
286, 4096, 0, 16
Jun 18 13:58:07 argo kernel: i810_audio: i810_write called, count = 3788
Jun 18 13:58:07 argo kernel: i810_audio: playback schedule timeout, dmasz 65536 fragsz 
2048 count 65536 hwptr 4294842946 swptr 6722
Jun 18 13:58:38 argo last message repeated 77 times
Jun 18 13:59:39 argo last message repeated 152 times
Jun 18 13:59:40 argo last message repeated 4 times

It goes on until I kill the app, then it says:

Jun 18 13:59:42 argo kernel: i810_audio: drain_dac, dma timeout?

Any idea(s), suggestions ...

Thank you

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

Re: Client receives TCP packets but does not ACK

[Jan Hudec]

> > TCP is NOT a guaranteed protocol -- you can't just blast data from one
> port
> > to another and expect it to work.
> 
> Isn't it? Are you really sure about that? I thought UDP was the
> not-guaranteed-one and TCP was the one guaranting that all data reaches the
> other end in order and all. Please enlighten me.

It's "hlaf guaranteed." It guarantees, that if data are delivered to the
reciever, all data sent before already arived and in correct order. But it's
not guaranteed that data succesuly writen on 1 end actualy arived unless the
connection was correctly shutdown and closed. 

Btw: can the aplication somehow ask the tcp/ip stack what was actualy acked?
(ie. how many bytes were acked).


- Jan Hudec `Bulb' <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/