Re: [Lse-tech] Re: A common layer for Accounting packages

[Kaigai Kohei]

Hello, everyone.
Andrew Morton wrote:
> Jay Lan <[EMAIL PROTECTED]> wrote:
>
>>Since the need of Linux system accounting has gone beyond what BSD
>>accounting provides, i think it is a good idea to create a thin layer
>>of common code for various accounting packages, such as BSD accounting,
>>CSA, ELSA, etc. The hook to do_exit() at exit.c was changed to invoke
>>a routine in the common code which would then invoke those accounting
>>packages that register to the acct_common to handle do_exit situation.
>
>
> This all seems to be heading in the wrong direction.  Do we really want to
> have lots of different system accounting packages all hooking into a
> generic we-cant-decide-what-to-do-so-we-added-some-pointless-overhead
> framework?
>
> Can't we get _one_ accounting system in there, get it right, avoid the
> framework?
I think there are two issues about system accounting framework.
Issue: 1) How to define the appropriate unit for accounting ?
Current BSD-accountiong make a collection per process accounting information.
CSA make additionally a collection per process-aggregation accounting.
It is appropriate to make the fork-exit event handling framework for definition
of the process-aggregation, such as PAGG.
This system-accounting per process-aggregation is quite useful,
thought I tried the SGI's implementation named 'job' in past days.
Issue: 2) What items should be collected for accounting information ?
BSD-accounting collects PID/UID/GID, User/Sys/Elapsed-Time, and # of
minor/major page faults. SGI's CSA collects VM/RSS size on exit time,
Integral-VM/RSS, and amount of block-I/O additionally.
I think it's hard to implement the accounting-engine as a kernel loadable
module using any kinds of framework. Because, we must put callback functions
into all around the kernel for this purpose.
Thus, I make a proposion as follows:
We should separate the process-aggregation functionality and collecting
accounting informations.
Something of framework to implement process-aggregation is necessary.
And, making a collection of accounting information should be merged
into BSD-accounting and implemented as a part of monolithic kernel
as Guillaume said.
Thanks.
--
Linux Promotion Center, NEC
KaiGai Kohei <[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: Merging fails reading /dev/uba1

[Jens Axboe]

On Sun, Feb 20 2005, Pete Zaitcev wrote:
> Hi, Jens:
> 
> I think this question belongs to your domain, but please let me know
> if I'm mistaken, so I can pursue this elsewhere.
> 
> I encountered a strange performance anomaly. I do the following:
> 
> <- Plug USB key
> [EMAIL PROTECTED] ~]# time dd if=/dev/uba of=/dev/null bs=10k count=10240
> 10240+0 records in
> 10240+0 records out
> 
> real0m22.731s
> user0m0.004s
> sys 0m0.345s
> [EMAIL PROTECTED] ~]#
> 
> <- Remove and replug the USB key
> [EMAIL PROTECTED] ~]# time dd if=/dev/uba1 of=/dev/null bs=10k count=10240
> 10240+0 records in
> 10240+0 records out
> 
> real1m42.622s
> user0m0.005s
> sys 0m1.518s
> [EMAIL PROTECTED] ~]#
> 
> So, reading from a partition of the same device is 5 times slower than
> reading from the device itself. The question is, why?
> 
> To the best of my knowledge, this does not occur with SCSI (usb-storage
> and sd or sr). This hints strongly that the ub is not doing something
> right, but what that can be?
> 
> The ub takes the request processing machinery from Carmel exactly. I am
> wondering if Carmel (sx8) exhibits any similar performance anomalies
> (cc-ing to Jeff)

I can't explain why the replugging slows it down, maybe you were lucky
to get contigious pages in the first case? As far as I can see, ub
effectively disables merging by setting max hw/phys segment limit of 1.

-- 
Jens Axboe

-
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: [RFC 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview II

[Ray Bryant]

Paul Jackson wrote:
You have to walk to full node mapping for each array, but
even with hundreds of nodes that should not be that costly

I presume if you knew that the job only had pages on certain nodes,
perhaps due to aggressive use of cpusets, that you would only have to
walk those nodes, right?
I don't think Andi was proposing you have to search all of the pages
on a node.  I think that the idea was that the (count, old_nodes, new_nodes)
parameters would have to be converted to a full node_map such as is done
in the patch (let's call it "sample code") that I sent out with the
overview that started this whole discussion.  node_map[] is MAX_NUMNODES
in length, and node_map[i] gives the node where pages on node i should be
migrated to, or is -1 if we are not migrating pages on this node.
Since we have extended the interface to support -1 as a possible value for
the old_nodes array [and it matches any old node], then in that case we
would make node_map[i]=new_node for all values of i.
--
Best Regards,
Ray
---
  Ray Bryant
512-453-9679 (work) 512-507-7807 (cell)
[EMAIL PROTECTED] [EMAIL PROTECTED]
The box said: "Requires Windows 98 or better",
   so I installed Linux.
---
-
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: [RFC 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview II

[Ray Bryant]

Andi Kleen wrote:
Do you have any better way to suggest, Andi, for a batch manager to
relocate a job?  The typical scenario, as Ray explained it to me, is

- Give the shared libraries and any other files a suitable policy
(by mapping them and applying mbind) 

- Then execute migrate_pages() for the anonymous pages with a suitable
old node -> new node mapping.

How would you recommend that the batch manager move that job to the
nodes that can run it?  The layout of allocated memory pages and tasks
for that job must be preserved in order to keep the same performance.
The migration method needs to scale to hundreds, or more, of nodes.

You have to walk to full node mapping for each array, but
even with hundreds of nodes that should not be that costly
(in the worst case you could create a small hash table for it
in the kernel, but I'm not sure it's worth it) 

-Andi
-
I'm going to assume that there have been some "crossed emails" here.
I don't think that this is the interface that you and I have been
converging on.  As I understood it, we were converging on the following:
(1)  extended attributes will be used to mark files as non-migratable
(2)  the page_migrate() system call will be defined as:
 page_migrate(pid, count, old_nodes, new_nodes);
 and it will migrate all pages that are either anonymous or part
 of mapped files that are not marked non-migratable.
(3)  The mbind() system call with MPOL_MF_STRICT will be hooked up
 to the migration code so that it actually causes a migration.
 Processes can use this interface to migrate a portion of their own
 address space containing a mapped file.
This is different than your reply above, which seems to imply that:
(A)  Step 1 is to migrate mapped files using mbind().  I don't understand
 how to do this in general, because:
 (a)  I don't know how to make a non-racy list of the mapped files to
  migrate without assuming that the process to be migrated is stopped
and  (b)  If the mapped file is associated with the DEFAULT memory policy,
  and page placement was done by first touch, then it is not clear
  how to use mbind() to cause the pages to be migrated, and still
  end up with the identical topological placement of pages after
  the migration.
(B)  Step 2 is to use page_migrate() to migrate just the anonymous pages.
 I don't like the restriction of this to just anonymous pages.
Fundamentally, I don't see why (A) is much different from allowing one
process to manipulate the physical storage for another process.  It's
just stated in terms of mmap'd objects instead of pid's.  So I don't
see why that is fundamentally different from a page_migration() call
with va_start and va_end arguments.
So I'm going to assume that the agreement was really (1)-(3) above.
The only problem I see with that is the following:  Suppose that a user
wants to migrate a portion of their own address space that is composed
of (at last partly) anonymous pages or pages mapped to a file associated
with the DEFAULT memory policy, and we want the pages to be toplogically
allocated the same way after the migration as they were before the
migration?
The only way I know how to do the latter is with a system call of the form:
page_migrate(pid, va_start, va_end, count, old_nodes, new_nodes);
where the permission model is that a pid can migrate any process that it
can send a signal to.  So a root pid can migrate any process, and a user
pid can migrate pages of any pid started by the user.
--
Best Regards,
Ray
---
  Ray Bryant
512-453-9679 (work) 512-507-7807 (cell)
[EMAIL PROTECTED] [EMAIL PROTECTED]
The box said: "Requires Windows 98 or better",
   so I installed Linux.
---
-
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: how to sequence reset of PCI hardware

[Jon Smirl]

Secondary video cards need to be reset before they will work. How can
we get the kernel to do this? I can not come up with a good solution
for triggering this from a device driver.

One sequence I tried:
modprobe driver
driver registers sysfs class and triggers hotplug
probe code fail because HW is not reset
user space hotplug reset app runs
when reset is finished poke a sysfs attribute
in attribute handler reprobe the card

The sequence needs to be tolerant of the user space hotplug app failing
It also has to handle a rmmod of the driver while the user space app is running

An alternative is to put a emu86 execution module into the kernel.
That will allow the reset to occur synchronously. The linuxbios people
have one that is about 40-50K in size.

Another solution would be to have the PCI subsystem track devices that
have not been reset yet. modprobe of a driver would trigger a hotplug
reset event and fail the modprobe. The user space reset app would tell
the PCI subsystem when the hardware was successfully reset. After that
the modprobe would be allow to procede like normal.

I haven't been able to come up with a reliable way to call a user
space reset program from a driver's probe function except with an
in-kernel emu86. Is there another way? I'd also like to try an find a
solution that doesn't need to modify the 73 existing framebuffer
drivers.

-- 
Jon Smirl
[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.6.11-rc4-RT-V0.7.39-02 crash out of nowhere

[Gene Heskett]

Greetings;

I just came back in here after a 2 hour nap, to find the box crashed,
100%.  Uptime was at least 2 days for 2.6.11-rc4-RT-V0.7.39-02, and
no hints of impending doom.  The .config is attached.

The system was quiet except for kmail's timed mail fetching runs, 
x-6.8.1 (built on site) was running, as was setiathome.  Nothing
in the crontabs covers this time frame as rsync was scheduled to
start half an hour later, with amdump following it at 1 am.  So
if anything triggered it, it might have been kmail.  This is kde
3.3.0, konstruct built, and much more stable than the rpms have
been so far.  I haven't ever seen 99% of the crashes and problems
reported on the kde mailing lists.
 
Here is the first of the crash, up and including a fraction of the
next full second of the log. I won't include any more except a
couple of lines at the bottom to show how long it looped before
totally dying as the full log is 107+ megabytes.

Feb 20 23:08:01 coyote kernel: move_wait_queue+0x43/0x60 (12)
Feb 20 23:08:01 coyote kernel:  [] remove_wait_queue+0x43/0x60 (24)
Feb 20 23:08:01 coyote kernel:  [] poll_freewait+0x24/0x50 (24)
Feb 20 23:08:01 coyote kernel:  [] do_select+0x1c9/0x2d0 (16)
Feb 20 23:08:01 coyote kernel:  [] __pollwait+0x0/0xd0 (84)
Feb 20 23:08:01 coyote kernel:  [] sys_select+0x2bf/0x4d0 (32)
Feb 20 23:08:01 coyote kernel:  [] up_mutex+0xbe/0x120 (16)
Feb 20 23:08:01 coyote kernel:  [] sysenter_past_esp+0x52/0x75 (76)
Feb 20 23:08:01 coyote kernel: X/28686: BUG in kfree at mm/slab.c:2604
Feb 20 23:08:01 coyote kernel:  [] kfree+0x135/0x140 (8)
Feb 20 23:08:01 coyote kernel:  [] sys_select+0x234/0x4d0 (44)
Feb 20 23:08:01 coyote kernel:  [] sysenter_past_esp+0x52/0x75 (92)
Feb 20 23:08:01 coyote kernel: X/28686: BUG in kfree at mm/slab.c:2608
Feb 20 23:08:01 coyote kernel:  [] sys_select+0x234/0x4d0 (8)
Feb 20 23:08:01 coyote kernel:  [] sysenter_past_esp+0x52/0x75 (92)
Feb 20 23:08:01 coyote kernel: Warning: kfree_skb on hard IRQ c0351eea
Feb 20 23:08:01 coyote kernel: X/28686: BUG in kfree at mm/slab.c:2604
Feb 20 23:08:01 coyote kernel:  [] kfree+0x135/0x140 (8)
Feb 20 23:08:01 coyote kernel:  [] kfree_skbmem+0x13/0x30 (44)
Feb 20 23:08:01 coyote kernel:  [] __kfree_skb+0x85/0x120 (16)
Feb 20 23:08:01 coyote kernel:  [] unix_stream_recvmsg+0x21a/0x480 (8)
Feb 20 23:08:01 coyote kernel:  [] unix_stream_recvmsg+0x21a/0x480 
(24)
Feb 20 23:08:01 coyote kernel:  [] sock_aio_read+0xf5/0x110 (116)
Feb 20 23:08:01 coyote kernel:  [] do_sync_read+0xbe/0xf0 (116)
Feb 20 23:08:01 coyote kernel:  [] __mod_timer+0xfe/0x170 (28)
Feb 20 23:08:01 coyote kernel:  [] _spin_lock+0x17/0x20 (36)
Feb 20 23:08:01 coyote kernel:  [] autoremove_wake_function+0x0/0x60 
(52)
Feb 20 23:08:02 coyote kernel:  [] vfs_read+0x13c/0x150 (48)
Feb 20 23:08:02 coyote kernel:  [] sys_read+0x51/0x80 (36)
Feb 20 23:08:02 coyote kernel:  [] sysenter_past_esp+0x52/0x75 (40)
Feb 20 23:08:02 coyote kernel: X/28686: BUG in kfree at mm/slab.c:2608
Feb 20 23:08:02 coyote kernel:  [] kfree_skbmem+0x13/0x30 (8)
Feb 20 23:08:02 coyote kernel:  [] __kfree_skb+0x85/0x120 (16)
Feb 20 23:08:02 coyote kernel:  [] unix_stream_recvmsg+0x21a/0x480 (8)
Feb 20 23:08:02 coyote kernel:  [] unix_stream_recvmsg+0x21a/0x480 
(24)
Feb 20 23:08:02 coyote kernel:  [] sock_aio_read+0xf5/0x110 (116)
Feb 20 23:08:02 coyote kernel:  [] do_sync_read+0xbe/0xf0 (116)
Feb 20 23:08:02 coyote kernel:  [] __mod_timer+0xfe/0x170 (28)
Feb 20 23:08:02 coyote kernel:  [] _spin_lock+0x17/0x20 (36)
Feb 20 23:08:02 coyote kernel:  [] autoremove_wake_function+0x0/0x60 
(52)
Feb 20 23:08:02 coyote kernel:  [] vfs_read+0x13c/0x150 (48)
Feb 20 23:08:02 coyote kernel:  [] sys_read+0x51/0x80 (36)
Feb 20 23:08:02 coyote kernel:  [] sysenter_past_esp+0x52/0x75 (40)
Feb 20 23:08:02 coyote kernel: X/28686: BUG in kmem_cache_free at mm/slab.c:2562
Feb 20 23:08:02 coyote kernel:  [] kmem_cache_free+0x11f/0x130 (8)
Feb 20 23:08:02 coyote kernel:  [] kfree_skbmem+0x24/0x30 (44)
Feb 20 23:08:02 coyote kernel:  [] __kfree_skb+0x85/0x120 (16)
Feb 20 23:08:02 coyote kernel:  [] unix_stream_recvmsg+0x21a/0x480 (8)
Feb 20 23:08:02 coyote kernel:  [] unix_stream_recvmsg+0x21a/0x480 
(24)
Feb 20 23:08:02 coyote kernel:  [] sock_aio_read+0xf5/0x110 (116)
Feb 20 23:08:02 coyote kernel:  [] do_sync_read+0xbe/0xf0 (116)
Feb 20 23:08:02 coyote kernel:  [] __mod_timer+0xfe/0x170 (28)
Feb 20 23:08:02 coyote kernel:  [] _spin_lock+0x17/0x20 (36)
Feb 20 23:08:02 coyote kernel:  [] autoremove_wake_function+0x0/0x60 
(52)
Feb 20 23:08:02 coyote kernel:  [] vfs_read+0x13c/0x150 (48)
Feb 20 23:08:02 coyote kernel:  [] sys_read+0x51/0x80 (36)
Feb 20 23:08:02 coyote kernel:  [] sysenter_past_esp+0x52/0x75 (40)
Feb 20 23:08:02 coyote kernel: X/28686: BUG in kmem_cache_free at mm/slab.c:2564
Feb 20 23:08:02 coyote kernel:  [] kfree_skbmem+0x24/0x30 (8)
Feb 20 23:08:02 coyote kernel:  [] __kfree_skb+0x85/0x120 (16)
Feb 20 23:08:02 coyote kernel:  [] unix_stream_recvmsg+0x21a/0x480 (8)
Feb 20 23:08:02 coyote kernel:  [] 

Re: [PATCH 2/2] page table iterators

[Benjamin Herrenschmidt]

On Sun, 2005-02-20 at 22:40 -0800, Andrew Morton wrote:
> Hugh Dickins <[EMAIL PROTECTED]> wrote:
> >
> > My opinion FWIW: I'm all for regularizing the pagetable loops to
> >  work the same way, changing their variables to use the same names,
> >  improving their efficiency; but I do like to see what a loop is up to.
> > 
> >  list_for_each and friends are very widely used, they're fine, and I'm
> >  quite glad to have their prefetching hidden away from me; but usually
> >  I groan, grin and bear it, each time someone devises a clever new
> >  for_each macro concealing half the details of some specialist loop.
> > 
> >  In a minority?
> 
> Of two.

Well, we basically have that bunch of loops that all do the same thing
to iterate the page tables. Only the inner part is different (that is
what is done on each PTE).

All of them are slightly differently implemented, some check overflow,
some don't, some have redudant checking, some aren't even consistent
between all 3/4 loops of a given walk routine set, and we have seen the
tendency to introduce subtle bugs in one of them when they all have to
be changed for some reason.

I'm all for turning them into something more consistent, and I like the
for_each_* idea...

It also allows to completely remove the code of the unused levels on 2
and 3 level page tables easily, regaining some of the perfs lost by the
move to 4 levels.

Now, we also need, in the long run, to improve perfs of walking the page
tables, especially PTEs, for things like tearing down processes or fork,
for example via a bitmap of used PGD entries etc... 

With proper iterators, such a thing could be implemented just by
modifying the iterator, and all loops would benefit from it.

I think that is enough to justify the move.

Ben.


-
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 2.6.11-rc3-mm2] connector: Add a fork connector

[Guillaume Thouvenin]

On Thu, 2005-02-17 at 18:50 +0300, Evgeniy Polyakov wrote:
> On Thu, 2005-02-17 at 15:55 +0100, Guillaume Thouvenin wrote:
> > It's a new patch that implements a fork connector in the
> > kernel/fork.c:do_fork() routine. The connector sends information about
> > parent PID and child PID over a netlink interface. It allows to several
> > user space applications to be alerted when a fork occurs in the kernel.
> > The main drawback is that even if nobody listens, a message is send. I
> > don't know how to avoid that. I added an option (FORK_CONNECTOR) to
> > enable the fork connector (or disable) when compiling the kernel. To
> > work, connector must be compiled as built-in (CONFIG_CONNECTOR=y). It
> > has been tested on a 2.6.11-rc3-mm2 kernel with two user space
> > applications connected. 
> > 
> > It is used by ELSA to manage group of processes in user space. In
> > conjunction with a per-process accounting information, like BSD or CSA,
> > ELSA provides a per-group of processes accounting.
> 
> I think people will complain here...
> ... [cut here] ...
> I still think that lsm with all calls logging is the best way to
> achieve this goal.

I agree with you. My first implementation was with LSM but Chris Wright
(I think it was him) notice that it's not the right framework (and it
seems true). So I looked for another solution. I though about kobject
but it was too "big" and finally, Greg KH spoke about connectors. It's
small and efficient.
 
> from the other side why only fork is monitored in this way?

The problem is the following: I have a user space daemon that manages
group of processes. The main idea is, if a parent belongs to a group
then its child belongs to the same group. To achieve this I need to know
when a fork occurs and which processes are involved. I don't see how to
do this without a hook in the do_fork() routine... Any ideas are
welcome.

Thank you Evgeniy for all your comments about the code, it helps and I
will modify the patch.

Regards,
Guillaume

-
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/

N/A

[Christof Dorner]

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

Re: [BK] upgrade will be needed

[Dmitry Torokhov]

On Monday 21 February 2005 00:43, Miles Bader wrote:
> "Theodore Ts'o" <[EMAIL PROTECTED]> writes:
> > The "cost" of using BK seems to be primarily more theoretical, and
> > ideological, than real.
> 
> I've never used BK (not allowed to), but some things I've read about it
> sound quite annoying.  For instance:
> 
>  * Every source tree contains your entire repository => massive disk usage

It's not too bad as you just hardlink most of the trees to their parent.
 
>  * Must "unlock" files before working on them ("bk edit"); I recall
>doing this with RCS, and it was, well, a real pain.

I think there is a setting to have them checked out for editing automatically.

-- 
Dmitry
-
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: A common layer for Accounting packages

[Guillaume Thouvenin]

On Fri, 2005-02-18 at 17:16 -0800, Andrew Morton wrote:
> Jay Lan <[EMAIL PROTECTED]> wrote:
> >
> > Since the need of Linux system accounting has gone beyond what BSD
> > accounting provides, i think it is a good idea to create a thin layer
> > of common code for various accounting packages, such as BSD accounting,
> > CSA, ELSA, etc. The hook to do_exit() at exit.c was changed to invoke
> > a routine in the common code which would then invoke those accounting
> > packages that register to the acct_common to handle do_exit situation.
> 
> This all seems to be heading in the wrong direction.  Do we really want to
> have lots of different system accounting packages all hooking into a
> generic we-cant-decide-what-to-do-so-we-added-some-pointless-overhead
> framework?
> 
> Can't we get _one_ accounting system in there, get it right, avoid the
> framework?

  Is it possible to just merge the BSD accounting and the CSA accounting
by adding in the current BSD per-process accounting structure some
missing fields like the mm integral provided by the CSA patch?

ELSA is just a user of the accounting data. We need a hook in the
do_fork() routine to manage group of processes, not to do accounting. 

Guillaume

-
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 2/2] page table iterators

[Andrew Morton]

Hugh Dickins <[EMAIL PROTECTED]> wrote:
>
> My opinion FWIW: I'm all for regularizing the pagetable loops to
>  work the same way, changing their variables to use the same names,
>  improving their efficiency; but I do like to see what a loop is up to.
> 
>  list_for_each and friends are very widely used, they're fine, and I'm
>  quite glad to have their prefetching hidden away from me; but usually
>  I groan, grin and bear it, each time someone devises a clever new
>  for_each macro concealing half the details of some specialist loop.
> 
>  In a minority?

Of two.

Let's see what they look like.  They'd need to be very good, IMO.
-
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 2/2] page table iterators

[Hugh Dickins]

On Sun, 20 Feb 2005, Nick Piggin wrote:
> Andi Kleen wrote:
> > 
> > The problem is just that these walker macros when they
> > do all the lazy walking stuff will be quite complicated.
> > And I don't really want another uaccess.h-like macro mess.
> > 
> > Yes currently they look simple, but that will change.
> 
> But even in that case, it will still be better to have the
> extra complexity once in the macro rather than throughout mm/
> 
> > Open coding is probably the smaller evil.
> > And they're really not changed that often.

My opinion FWIW: I'm all for regularizing the pagetable loops to
work the same way, changing their variables to use the same names,
improving their efficiency; but I do like to see what a loop is up to.

list_for_each and friends are very widely used, they're fine, and I'm
quite glad to have their prefetching hidden away from me; but usually
I groan, grin and bear it, each time someone devises a clever new
for_each macro concealing half the details of some specialist loop.

In a minority?
Hugh
-
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: Panic in 2.6.11-rc4

[Andrew Morton]

Ben Greear <[EMAIL PROTECTED]> wrote:
>
>  SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
>  SCSI device sda: drive cache: write back
>  SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
>  SCSI device sda: drive cache: write back
>sda: sda1 sda2 sda3
>  Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
>  Unable to handle kernel paging request at virtual address e09a68e8
>printing eip:
>  c014976e
>  *pde = 0151f067
>  Oops:  [#1]
>  PREEMPT SMP
>  Modules linked in: ext3 jbd ata_piix libata sd_mod scsi_mod
>  CPU:1
>  EIP:0060:[]Not tainted VLI
>  EFLAGS: 00010006   (2.6.11-rc4)
>  EIP is at cache_alloc_refill+0x20e/0x240

I assume something has wrecked the slab caches.  Please enable
CONFIG_DEBUG_SLAB and CONFIG_DEBUG_PAGEALLOC.

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

Re: [BK] upgrade will be needed

[Miles Bader]

"Theodore Ts'o" <[EMAIL PROTECTED]> writes:
> The "cost" of using BK seems to be primarily more theoretical, and
> ideological, than real.

I've never used BK (not allowed to), but some things I've read about it
sound quite annoying.  For instance:

 * Every source tree contains your entire repository => massive disk usage

 * Must "unlock" files before working on them ("bk edit"); I recall
   doing this with RCS, and it was, well, a real pain.

-Miles
-- 
"Whatever you do will be insignificant, but it is very important that
 you do it."  Mahatma Ghandi
-
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: [darcs-users] Re: [BK] upgrade will be needed

[Miles Bader]

Dustin Sallings  writes:
> but the nicest thing about arch is that a given commit is immutable.
> There are no tools to modify it.  This is also why the crypto
> signature stuff was so easy to fit in.
>
> RCS and SCCS storage throws away most of those features.

Yeah, the basic way arch organizes its repository seems _far_ more sane
than the crazy way CVS (or BK) does, for a variety of reasons[*].  No
doubt there are certain usage patterns which stress it, but I think it
makes a lot more sense to use a layer of caching to take care of those,
rather than screwing up the underlying organization.

[*] (a) Immutability of repository files (_massively_ good idea)
(b) Deals with tree-changes "naturally" (CVS-style ,v files are a
complete mess for anything except file-content changes)
(c) Directly corresponds to traditional diff 'n' patch, easy to
think about, no surprises

-Miles
-- 
Saa, shall we dance?  (from a dance-class advertisement)
-
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: [autofs] automount does not close file descriptors at start

[Valdis . Kletnieks]

On Mon, 21 Feb 2005 12:57:22 +0800, Ian Kent said:

> This is the first time I've heard this and the first time I wrote a Unix
> daemon was fifteen years ago.
> 
> As far as I'm concerned redirecting stdin, stdout and stderr to the null 
> device, then closing it and setting the process to a be the group leader 
> (as autofs does) should be all that's needed to daemonize a process.
> 
> So are we saying that we don't trust the kernel to reliably duplicate the 
> state of file handles when we fork?

No, you have it 180 degrees off. ;)

We *do* trust the kernel to reliably duplicate the state of file handles.
So if we're about to do the whole double-fork thing and all that, we want to
loop around and close all the file descriptors we don't want leaking to
the double-forked daemon.  Yes, we do something reasonable with fd 0,1,2 -
but we probably also want to do something with that unclosed fd 3 that's still
open on /etc/mydaemon.cf, and any other file descriptors we've left dangling
in the breeze after initialization.

And yes, this sort of error happens in Real Live - I need to go and figure out
why the /sbin/lvm.static on my initrd is throwing 'File descriptor 3 left open'
messages... 



pgpwa9z1MK9uv.pgp
Description: PGP signature

Odd data corruption problem with LVM/ReiserFS

[Alex Adriaanse]

As of this morning I've experienced some very odd data corruption
problem on my server.  Let me post some background information first.

For the past few years I've been running this server under Linux 2.4.x
and Debian Woody.  It has two software RAID 1 partitions, one for the
ReiserFS root filesystem (md0), and one for LVM running on top of RAID
1 (md1).  Under LVM I have three logical volumes, one for /usr, one
for /var, and one for /home.  All of them run ReiserFS.  Also, during
daily backups I'd create a snapshot of /var and /home and back that
up.  I haven't experienced any problems with this, other than
occasional power outages which might've corruped some log files by
adding a bunch of NULs to it, but that's never caused problems for me.

A few weeks ago I decided to upgrade to Debian Sarge.  This was a
fairly smooth process, and haven't seen any problems with that (and I
don't think this is related to the problem I described below).  Also,
last week I decided to upgrade from the 2.4.22 kernel to 2.6.10-ac12. 
This has been a pretty smooth ride too (until this morning).  One
exception is that I might not have had swap turned on due to device
name changes, so yesterday I saw some big processes getting killed due
to out-of-memory conditions (my server has 256MB non-ECC RAM, normally
with 512MB of swap).  That swap issue had not been fixed until this
afternoon, after the crash/corruption.  Yesterday afternoon I also
updated the metadata of my LVM volume group from version 1 to version
2.  Before then I temporarily stopped taking snapshots once I upgraded
to 2.6.10-ac12 since it didn't like taking snapshots inside LVM1
volume groups.  This morning was the first time my backup script took
a snapshot since upgrading to 2.6.10-ac12 (yesterday I had taken a few
snapshots myself for testing purposes, this seemed to work fine).

This morning when I tried to login after the backup process (which
takes snapshots) had started I couldn't get in.  SSH would just hang
after I sent my username.  After a while I gave up waiting and tried
to reboot the server by attaching a keyboard and hitting Ctrl-Alt-Del,
which started the shutdown process.  I can't fully remember if that
successfully rebooted the server, but I believe I ended up having to
press the reset button because the shutdown process would hang at some
point.  The server came back up but some processes wouldn't start due
to some corrupted files in the /var partition.

I checked the logs, and saw a bunch of the messages below.  On a
sidenote, when my backup script isn't able to mount a snapshot, it
removes it, waits a minute, then tries creating/mounting the snapshot
again, supposedly up to 10 times, even though those messages, spaced
apart by one minute, occurred much more than 10 times, but that might
be a bug in my script.  This was due to occasional problems I had with
older kernels which sometimes failed to mount the snapshot, but were
successful when trying again later.

These are the messages I saw:

Feb 20 09:59:16 homer kernel: lvcreate: page allocation failure.
order:0, mode:0xd0
Feb 20 09:59:16 homer kernel:  [__alloc_pages+440/864] __alloc_pages+0x1b8/0x360
Feb 20 09:59:16 homer kernel:  [alloc_pl+51/96] alloc_pl+0x33/0x60
Feb 20 09:59:16 homer kernel:  [client_alloc_pages+28/96]
client_alloc_pages+0x1c/0x60
Feb 20 09:59:16 homer kernel:  [vmalloc+32/48] vmalloc+0x20/0x30
Feb 20 09:59:16 homer kernel:  [kcopyd_client_create+104/192]
kcopyd_client_create+0x68/0xc0
Feb 20 09:59:16 homer kernel:  [dm_create_persistent+199/320]
dm_create_persistent+0xc7/0x140
Feb 20 09:59:16 homer kernel:  [snapshot_ctr+680/880] snapshot_ctr+0x2a8/0x370
Feb 20 09:59:16 homer kernel:  [dm_table_add_target+262/432]
dm_table_add_target+0x106/0x1b0
Feb 20 09:59:16 homer kernel:  [populate_table+130/224] populate_table+0x82/0xe0
Feb 20 09:59:16 homer kernel:  [table_load+103/368] table_load+0x67/0x170
Feb 20 09:59:16 homer kernel:  [ctl_ioctl+241/336] ctl_ioctl+0xf1/0x150
Feb 20 09:59:16 homer kernel:  [table_load+0/368] table_load+0x0/0x170
Feb 20 09:59:16 homer kernel:  [sys_ioctl+173/528] sys_ioctl+0xad/0x210
Feb 20 09:59:16 homer kernel:  [syscall_call+7/11] syscall_call+0x7/0xb
Feb 20 09:59:16 homer kernel: device-mapper: error adding target to table
Feb 20 09:59:16 homer kernel: lvremove: page allocation failure.
order:0, mode:0xd0
Feb 20 09:59:16 homer kernel:  [__alloc_pages+440/864] __alloc_pages+0x1b8/0x360
Feb 20 09:59:16 homer kernel:  [alloc_pl+51/96] alloc_pl+0x33/0x60
Feb 20 09:59:16 homer kernel:  [client_alloc_pages+28/96]
client_alloc_pages+0x1c/0x60
Feb 20 09:59:16 homer kernel:  [vmalloc+32/48] vmalloc+0x20/0x30
Feb 20 09:59:16 homer kernel:  [kcopyd_client_create+104/192]
kcopyd_client_create+0x68/0xc0
Feb 20 09:59:16 homer kernel:  [dm_create_persistent+199/320]
dm_create_persistent+0xc7/0x140
Feb 20 09:59:16 homer kernel:  [snapshot_ctr+680/880] snapshot_ctr+0x2a8/0x370
Feb 20 09:59:16 homer kernel:  [dm_table_add_target+262/432]

Re: [patch] sched: auto-tuning task-migration

[Paul Jackson]

A long long time ago (Oct 2004) Ingo wrote:
> the following patch adds a new feature to the scheduler: during bootup
> it measures migration costs and sets up cache_hot value accordingly.

Ingo - what became of this patch?

I made a quick search for it in Linus's bk tree and Andrew's *-mm
patches, but didn't find it.  Perhaps I didn't know what to look for.

The metric it exposes looks like something I might want to expose to
userland, so the performance guys can begin optimizing the placement of
tasks on CPUs, depending on whether they would benefit from, or be
harmed by, sharing cache.  Would the two halves of a hyper threaded core
show up as particularly close on this metric?  I presume so.

It seems to me to be a good complement to the current cpu-memory
distance we have now in node_distance() exposing the ACPI 2.0 SLIT
table distances.

I view the two key numbers here as (1) how fast can a cpu get stuff out
of a memory node (an amalgam of bandwidth and latency), and (2) how much
cache and buses and such do two cpus share (which can be good or bad,
depending on whether the two tasks on those two cpus share much of their
cache footprint).

The SLIT table provides (1) just fine.  Your patch seems to compute a
sensible estimate of (2).

I had one worry - was there a potential O(N**2) cost in computing this
at boottime, where N is the number of nodes?  Us SGI folks are usually
amongst the first to notice such details, when they blow up on us ;).

I never actually saw the original patch -- perhaps if I had, some of
my questions above would have obvious answers.

Thanks.  (and thanks for cpus_allowed -- I've practically made a
profession out of building stuff on top of that one ... ;).

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
1.925.600.0401
-
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: -rc3 leaking NOT BIO [Was: Memory leak in 2.6.11-rc1?]

[Parag Warudkar]

On Thursday 17 February 2005 08:38 pm, Badari Pulavarty wrote:
> > On Wednesday 16 February 2005 06:52 pm, Andrew Morton wrote:
> > > So it's probably an ndiswrapper bug?
> >
> > Andrew,
> > It looks like it is a kernel bug triggered by NdisWrapper. Without
> > NdisWrapper, and with just 8139too plus some light network activity the
> > size-64 grew from ~ 1100 to 4500 overnight. Is this normal? I will keep
> > it running to see where it goes.

[OT]

Didn't wanted to keep this hanging - It turned out to be a strange ndiswrapper 
bug - It seems that the other OS in question allows the following without a 
leak ;) -
ptr =Allocate(...);
ptr = Allocate(...);
:
repeat this zillion times without ever fearing that 'ptr' will leak..

I sent a fix to ndiswrapper-general mailing list on sourceforge if any one is 
using ndiswrapper and having a similar problem.

Parag
-
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: [autofs] automount does not close file descriptors at start

[Ian Kent]

On Wed, 16 Feb 2005, Steinar H. Gunderson wrote:

> Hi,
> 
> My latest autofs package for Debian (4.1.3+4.1.4beta2-1) had problems
> installing, freezing after install; I've worked around this now
> (4.1.3+4.1.4beta2-2 is on its way up to the archive), but I've been told this
> is really a bug in automount. What I've been told is along the lines of:
> 
> "Any daemon going into the background should close all file descriptors from
> zero up to MAXFDS minus the ones it actually wants to have open."
> 
> In other words, one should probably have a for loop of sorts in
> become_daemon().

Steinar, I'm still wondering where this came from?

This is the first time I've heard this and the first time I wrote a Unix
daemon was fifteen years ago.

As far as I'm concerned redirecting stdin, stdout and stderr to the null 
device, then closing it and setting the process to a be the group leader 
(as autofs does) should be all that's needed to daemonize a process.

So are we saying that we don't trust the kernel to reliably duplicate the 
state of file handles when we fork?

If that's the case then the kernel is badly broken and needs fixing, not 
autofs!

Ian

-
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: Help - really messed up kernel

[Joshua Hudson]

Thinks for trying. I finally found the problem myself.
There is some incompatability between syslinux 2.10 and kernel 2.6.10
Using lilo on the first floppy fixed the problem

Oh, and no I am *not* using an initrd. I am using the old paramiters
that cause the kernel to load the ramdisk after it boots.

-
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] Re: slab corruption on 2.6.10-rc4-bk7

[Jeff Garzik]

Actually, here's a better fix.
Jeff

= drivers/scsi/libata-core.c 1.116 vs edited =
--- 1.116/drivers/scsi/libata-core.c	2005-02-01 20:23:51 -05:00
+++ edited/drivers/scsi/libata-core.c	2005-02-20 23:34:32 -05:00
@@ -2800,7 +2800,7 @@
 			return 1;
 
 		/* fall through */
-	
+
 	default:
 		return 0;
 	}
@@ -3743,16 +3743,13 @@
 	if (legacy_mode) {
 		if (legacy_mode & (1 << 0))
 			ata_device_add(probe_ent);
-		else
-			kfree(probe_ent);
 		if (legacy_mode & (1 << 1))
 			ata_device_add(probe_ent2);
-		else
-			kfree(probe_ent2);
-	} else {
+	} else
 		ata_device_add(probe_ent);
-	}
+
 	kfree(probe_ent);
+	kfree(probe_ent2);
 
 	return 0;
 

[PATCH] Re: slab corruption on 2.6.10-rc4-bk7

[Jeff Garzik]

Andrew Morton wrote:
Dave Jones <[EMAIL PROTECTED]> wrote:
(This has actually been there for a while, but I only
noticed it in dmesg this morning).
During boot on a dual em64t I see ..
scsi2 : ata_piix
isa bounce pool size: 16 pages
slab error in cache_free_debugcheck(): cache `size-2048': double free, or 
memory outside object was overwritten
Call Trace:{cache_free_debugcheck+392} 
{kfree+234}
  {:libata:ata_pci_init_one+937} 
{pci_bus_read_config_word+122}
  {:ata_piix:piix_init_one+498} 
{pci_device_probe+134}
  {driver_probe_device+77} 
{driver_attach+75}
  {bus_add_driver+169} 
{pci_register_driver+131}
  {:ata_piix:piix_init+16} 
{sys_init_module+344}
  {system_call+126}
81011e49f4a0: redzone 1: 0x5a2cf071, redzone 2: 0x5a2cf071.

It's plain to see how ata_pci_init_one() will free `probe_ent' twice.  Jeff
wanna fix that up please?  A naive fix would be
Here's the initial fix...  about to test with some other fixes here. 
Anybody who is seeing this wanna give it a try?

Jeff

= drivers/scsi/libata-core.c 1.116 vs edited =
--- 1.116/drivers/scsi/libata-core.c	2005-02-01 20:23:51 -05:00
+++ edited/drivers/scsi/libata-core.c	2005-02-20 23:25:52 -05:00
@@ -3751,8 +3751,8 @@
 			kfree(probe_ent2);
 	} else {
 		ata_device_add(probe_ent);
+		kfree(probe_ent);
 	}
-	kfree(probe_ent);
 
 	return 0;
 

Re: IBM Thinkpad G41 PCMCIA problems [Was: Yenta TI: ... no PCI interrupts. Fish. Please report.]

[Steven Rostedt]

On Sun, 2005-02-20 at 09:56 -0800, Linus Torvalds wrote:

> Steven, does this fix it without the need for any kernel command line (or
> any other patches, for that matter - ie revert all the transparency-
> changing ones)?
> 
>   Linus
> 

Hi Linus,

I just tried it out (after removing all my crap) and yes it works.  

Thanks,

-- Steve


-
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: [RFC 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview II

[Ray Bryant]

Andi Kleen wrote:
But we are least at the level of agreeing that the new system
call looks something like the following:
migrate_pages(pid, count, old_list, new_list);
right?

For the external case probably yes. For internal (process does this
on its own address space) it should be hooked into mbind() too.
-Andi
That makes sense.  I will agree to make that part work, too. as part
of this.  We will probably do the external case first, because we have
need for that.
--
Best Regards,
Ray
---
  Ray Bryant
512-453-9679 (work) 512-507-7807 (cell)
[EMAIL PROTECTED] [EMAIL PROTECTED]
The box said: "Requires Windows 98 or better",
   so I installed Linux.
---
-
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/

Merging fails reading /dev/uba1

[Pete Zaitcev]

Hi, Jens:

I think this question belongs to your domain, but please let me know
if I'm mistaken, so I can pursue this elsewhere.

I encountered a strange performance anomaly. I do the following:

<- Plug USB key
[EMAIL PROTECTED] ~]# time dd if=/dev/uba of=/dev/null bs=10k count=10240
10240+0 records in
10240+0 records out

real0m22.731s
user0m0.004s
sys 0m0.345s
[EMAIL PROTECTED] ~]#

<- Remove and replug the USB key
[EMAIL PROTECTED] ~]# time dd if=/dev/uba1 of=/dev/null bs=10k count=10240
10240+0 records in
10240+0 records out

real1m42.622s
user0m0.005s
sys 0m1.518s
[EMAIL PROTECTED] ~]#

So, reading from a partition of the same device is 5 times slower than
reading from the device itself. The question is, why?

To the best of my knowledge, this does not occur with SCSI (usb-storage
and sd or sr). This hints strongly that the ub is not doing something
right, but what that can be?

The ub takes the request processing machinery from Carmel exactly. I am
wondering if Carmel (sx8) exhibits any similar performance anomalies
(cc-ing to Jeff)

Additional information:

[EMAIL PROTECTED] ~]# cat /proc/version
Linux version 2.6.11-rc4-lem ([EMAIL PROTECTED]) (gcc version 3.4.2 20041017 
(Red Hat 3.4.2-6.fc3)) #1 Tue Feb 15 23:06:39 PST 2005
[EMAIL PROTECTED] ~]# cat /proc/partitions
major minor  #blocks  name

   3 0   39070080 hda
   3 15935986 hda1
   3 25936017 hda2
   3 3 554242 hda3
   3 4  1 hda4
   3 5   26643771 hda5
 180 01024000 uba
 180 11023983 uba1
[EMAIL PROTECTED] ~]#

Thanks,
-- 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: driver compile Parse error with gcc-3.4.3

[Randy.Dunlap]

Anil Kumar wrote:
Hi,
I am new to linux. I am trying to build one of my drivers for
2.6.9-5.EL, RHEL 4, I am getting compile parse errors as follows:
error: parse error before '(' token
Complete gcc output plus driver source file would help a lot.
#gcc -v
Configured with: ./configure --prefix=/usr/adaptec/build/gcc343-32bit
--enable-threads=posix --disable-checking --target=i386-redhat-linux
--host=i686-redhat-linux-gnu
--with-libs=/usr/adaptec/build/gcc343-32bit/lib
--with-headers=/usr/adaptec/build/gcc343-32bit/include
--enable-languages=c --disable-libunwind-exceptions --with-system-zlib
--enable-__cxa_atexit --enable-java-awt=gtk --enable-shared
--mandir=/usr/adaptec/build/gcc343-32bit/man
--infodir=/usr/adaptec/build/gcc343-32bit/info
Thread model: posix
gcc version 3.4.3
--
~Randy
-
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] /proc/kmalloc

[Baruch Even]

Matt Mackall wrote:
I've been sitting on this for over a year now, kicking it out in the
hopes that someone finds it useful. kernel.org was down when I was
tidying this up so it's against 2.6.10 which is what I had handy.
/proc/kmalloc allocation tracing
This quick hack adds accounting for kmalloc/kfree callers. This can
aid in tracking down memory leaks and large dynamic memory users. The
stock version use ~280k of memory for hash tables and can track 32k
active allocations.
One thing I've seen once that might be worth adding is the ability to 
mark generations and then ask "what allocations exist from generation x?".

So you do something like:
echo 5 > /proc/kmalloc_generation
run some tests
echo 6 > /proc/kmalloc_generation
Print all allocations from generation 5:
  echo 5 > /proc/kmalloc_print_generations
Now you get all buffers that were allocated in generation 5 and not 
released. Not all of these are leaks, but it's easier to wade through 
this list to see what is and what isn't a leak.

Sometimes it's better to summarize all allocations according to the 
caller who asked for the allocation, it makes it easier to see if there 
is an undue increase from certain callers.

Just some ideas.
Baruch
-
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: Help - really messed up kernel

[Pedro Venda]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joshua Hudson wrote:
| I am trying to install linux on a laptop that cannot boot from cdrom.
| I got a stripped-down kernel to boot from floppy, ran lspci to get
| the hardware information.
|
| I then reconfigured and rebuilt the kernel for the image.
|
| I built this kernel from stock 2.6.10 from www.kernel.org.
| This is the configuration file. I then installed it on a floppy disk
| with syslinux, then tried to boot it.
|
| boot: vmlinuz root=/dev/fd0 load_ramdisk=1 prompt_ramdisk=1
| (my ramdisk is the next flooppy, this kernel is 1.3mb)
| Did not load the ramdisk.
| I got an error about unable to open root on "" or device 22,6.
| Hmm. So, I ran rdev to set the kernel default root to /dev/fd0 and booted.
|
| Result: loaded the ramdisk, then complained about lack of a valid
| filesystem on /dev/fd0
you want to load your root filesystem into a ramdisk and use it from there.
your kernel command line is wrong. it should have root=/dev/rd/0 or
root=/dev/ram0 instead of root=/dev/fd0.
after loading the initrd, your root filesystem is on a ramdisk.
regards,
pedro venda.
- --
Pedro João Lopes Venda
email: pjvenda < at > arrakis.dhis.org
http://arrakis.dhis.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCGUajeRy7HWZxjWERAm2iAJ4yQIEXp8gB3ltotJ229PZhQUsCcwCgxXtI
AHa+nWqajS299v+v09DoWCY=
=cEN1
-END PGP SIGNATURE-
-
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/

driver compile Parse error with gcc-3.4.3

[Anil Kumar]

Hi,

I am new to linux. I am trying to build one of my drivers for
2.6.9-5.EL, RHEL 4, I am getting compile parse errors as follows:
error: parse error before '(' token

#gcc -v
Configured with: ./configure --prefix=/usr/adaptec/build/gcc343-32bit
--enable-threads=posix --disable-checking --target=i386-redhat-linux
--host=i686-redhat-linux-gnu
--with-libs=/usr/adaptec/build/gcc343-32bit/lib
--with-headers=/usr/adaptec/build/gcc343-32bit/include
--enable-languages=c --disable-libunwind-exceptions --with-system-zlib
--enable-__cxa_atexit --enable-java-awt=gtk --enable-shared
--mandir=/usr/adaptec/build/gcc343-32bit/man
--infodir=/usr/adaptec/build/gcc343-32bit/info
Thread model: posix
gcc version 3.4.3

regards,
 Anil
-
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: Panic in 2.6.11-rc4

[Ben Greear]

Matthias-Christian Ott wrote:
Hi!
The first one is allocation error (linuxrc wants to get/read memory, but 
the allocation fails?). The other errors are _maybe_ caused by the first 
error (the scheduler schedules while a atomic operation is in progress). 
Is your Kernel configuration different to the configuration of the 
Fedora Kernel? If so: What did you change?
Not a whole lot, I think.  It's attached.
It's strange that you can't change you Bios settings. Is the write 
protection jumper set to 1 (TRUE/ENABLED)? Is your Bios up2date?
BIOS was up to date, and didn't notice any jumpers that I could play
with.  I was later able to boot this kernel on a similar machine
with no problem, so I think that the problem might be some flaky
hardware...
Thanks,
Ben
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc  http://www.candelatech.com
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.9
# Mon Nov 22 17:39:58 2004
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_SYSCTL=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_LOG_BUF_SHIFT=17
CONFIG_HOTPLUG=y
# CONFIG_IKCONFIG is not set
CONFIG_EMBEDDED=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SHMEM=y
# CONFIG_TINY_SHMEM is not set

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
# CONFIG_MODVERSIONS is not set
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y

#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
CONFIG_MPENTIUM4=y
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
CONFIG_X86_GENERIC=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_SMP=y
CONFIG_NR_CPUS=8
CONFIG_SCHED_SMT=y
CONFIG_PREEMPT=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
# CONFIG_X86_MCE_NONFATAL is not set
CONFIG_X86_MCE_P4THERMAL=y
CONFIG_TOSHIBA=m
CONFIG_I8K=m
CONFIG_MICROCODE=m
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m

#
# Firmware Drivers
#
CONFIG_EDD=m
# CONFIG_NOHIGHMEM is not set
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
CONFIG_HIGHMEM=y
CONFIG_HIGHPTE=y
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
CONFIG_IRQBALANCE=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_REGPARM=y

#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
CONFIG_SOFTWARE_SUSPEND=y
CONFIG_PM_STD_PARTITION=""

#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
CONFIG_ACPI_AC=m
CONFIG_ACPI_BATTERY=m
CONFIG_ACPI_BUTTON=m
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
CONFIG_ACPI_ASUS=m
CONFIG_ACPI_TOSHIBA=m
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_BUS=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y

#
# APM (Advanced Power Management) BIOS Support
#
CONFIG_APM=y
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
# CONFIG_APM_DO_ENABLE is not set
CONFIG_APM_CPU_IDLE=y
# CONFIG_APM_DISPLAY_BLANK is not set
CONFIG_APM_RTC_IS_GMT=y
# CONFIG_APM_ALLOW_INTS is not set
# CONFIG_APM_REAL_MODE_POWER_OFF is not set

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
# CONFIG_CPU_FREQ_PROC_INTF is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=m
CONFIG_CPU_FREQ_GOV_USERSPACE=y
# CONFIG_CPU_FREQ_GOV_ONDEMAND is not set
# CONFIG_CPU_FREQ_24_API is not set
CONFIG_CPU_FREQ_TABLE=y

#

Re: Bootsplash for 2.6.11-rc4

[Marcos D. Marado Torres]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, 20 Feb 2005, Michal Januszewski wrote:
On Sun, Feb 20, 2005 at 12:25:19AM +0100, Pavel Machek wrote:
How many distros do use some variant of bootsplash? SuSE does, from
above url I guess gentoo does, too... Does RedHat do something
similar? [Or do they just set log-level to very high giving them clean
look?] What about Debian?
As far as I know: SuSE uses bootsplash, Gentoo and PLD use fbsplash,
RedHat uses rhgb (100% userspace solution, based on xvesa, doesn't
provide graphical backgrounds on vt's - for that a kernel patch like
bootsplash or fbsplash is necessary). I don't know about Debian - they
probably have some (possibly unofficial) support for both bootsplash
and fbsplash.
Indeed, there is bootsplash and fbsplash for Debian, but only unofficial
packages.
Marcos Marado
- -- 
/* *** */
   Marcos Daniel Marado Torres	 AKA	Mind Booster Noori
   http://student.dei.uc.pt/~marado   -	  [EMAIL PROTECTED]
   () Join the ASCII ribbon campaign against html email, Microsoft
   /\ attachments and Software patents.   They endanger the World.
   Sign a petition against patents:  http://petition.eurolinux.org
/* *** */
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Made with pgp4pine 1.76

iD8DBQFCGUFmmNlq8m+oD34RAtbqAJ43WanT3YNwRy8bkUIbrIqCl8u1mgCggy6R
4jZqOJQoO3vCeBe/fE/WUhk=
=CFlt
-END PGP SIGNATURE-
-
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: [RFC 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview II

[Paul Jackson]

> - Give the shared libraries and any other files a suitable policy
> (by mapping them and applying mbind) 

Ah - I think you've said this before, and I'm being a bit retarded.

You're saying that one could horse around with the physical placement of
existing files mapped into another tasks space by mapping them into ones
own space and using mbind, (once mbind is hooked up to page migration,
to quote one of your earlier posts ;).  Ok.

How well does this work with a mapped file if the pages of that file
have been placed (allocated on nodes) using some intricate first-touch
pattern that is only encoded in some inscrutable initialization code of
the application, and that is heavily fragmented, with few contiguous
pages on the same node?

It seems to me that you can't migrate such regions efficiently using the
above explicit mbind'ing -- it could require a vma per page in the
limit.  And you can't migrate such regions using a migrate_pages() for
all anonymous pages in a tasks space, because these aren't anon pages.

Do you have in mind being able to tag such mapped files with an
attribute that causes their pages to be migrated along with the
anon pages on the migrate_pages() call?  That might work ...


> > How would you recommend that the batch manager move that job to the
> > nodes that can run it?   ...
> 
> You have to walk to full node mapping for each array, but
> even with hundreds of nodes that should not be that costly

I presume if you knew that the job only had pages on certain nodes,
perhaps due to aggressive use of cpusets, that you would only have to
walk those nodes, right?

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
1.925.600.0401
-
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.6 patch] drivers/net/appletalk/: make firmware static

[Jeff Garzik]

Adrian Bunk wrote:
This patch makes some needlessly global firmware static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
 drivers/net/appletalk/cops_ffdrv.h |2 +-
 drivers/net/appletalk/cops_ltdrv.h |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.11-rc3-mm2-full/drivers/net/appletalk/cops_ffdrv.h.old	2005-02-16 15:15:32.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/appletalk/cops_ffdrv.h	2005-02-16 15:15:41.0 +0100
@@ -28,7 +28,7 @@
 
 #ifdef CONFIG_COPS_DAYNA
 
-unsigned char ffdrv_code[] = {
+static unsigned char ffdrv_code[] = {
 	58,3,0,50,228,149,33,255,255,34,226,149,
 	249,17,40,152,33,202,154,183,237,82,77,68,
 	11,107,98,19,54,0,237,176,175,50,80,0,
--- linux-2.6.11-rc3-mm2-full/drivers/net/appletalk/cops_ltdrv.h.old	2005-02-16 15:15:50.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/appletalk/cops_ltdrv.h	2005-02-16 15:15:58.0 +0100
@@ -27,7 +27,7 @@
 
 #ifdef CONFIG_COPS_TANGENT
 
-unsigned char ltdrv_code[] = {
+static unsigned char ltdrv_code[] = {
const
-
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.6 patch] drivers/net/lp486e.c: make some code static

[Jeff Garzik]

Adrian Bunk wrote:
This patch makes some needlessly global code static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
 drivers/net/lp486e.c |8 +---
 1 files changed, 5 insertions(+), 3 deletions(-)
--- linux-2.6.11-rc3-mm2-full/drivers/net/lp486e.c.old	2005-02-16 16:08:34.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/lp486e.c	2005-02-16 16:15:33.0 +0100
@@ -112,8 +112,10 @@
 	CmdDiagnose = 7
 };
 
-char *CUcmdnames[8] = { "NOP", "IASetup", "Configure", "MulticastList",
-			"Tx", "TDR", "Dump", "Diagnose" };
+#if 0
+static char *CUcmdnames[8] = { "NOP", "IASetup", "Configure", "MulticastList",
+			   "Tx", "TDR", "Dump", "Diagnose" };
+#endif
Need const.
Jeff

-
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.6 patch] drivers/net/ne3210.c: cleanups

[Jeff Garzik]

Adrian Bunk wrote:
-   if (ei_debug > 0)
-   printk(version);

I agree the version variable is outdated, but I disagree that the driver 
intro banner should be removed completely.

Jeff
-
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.6 patch] drivers/net/sb1000.c: make some variables static

[Jeff Garzik]

this patch eats formfeeds
-
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.6 patch] drivers/net/seeq8005.c: cleanups

[Jeff Garzik]

this patch needlessly eats formfeeds
-
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.6 patch] drivers/net/smc-mca.c: cleanups

[Jeff Garzik]

Adrian Bunk wrote:
This patch contains the following cleanups:
- make a needlessly global function static
- make three needlessly global structs static
Since after moving the now-static stucts to smc-mca.c the file smc-mca.h 
was empty except for two #define's, I've also killed the rest of 
smc-mca.h .

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
 drivers/net/smc-mca.c |   60 +++--
 drivers/net/smc-mca.h |   61 --
 2 files changed, 58 insertions(+), 63 deletions(-)
--- linux-2.6.11-rc3-mm2-full/drivers/net/smc-mca.h	2004-12-24 22:35:23.0 +0100
+++ /dev/null	2004-11-25 03:16:25.0 +0100
@@ -1,61 +0,0 @@
-/*
- * djweis [EMAIL PROTECTED]
- * most of this file was taken from ps2esdi.h
- */
-
-struct {
-  unsigned int base_addr;
-} addr_table[] = {
-{ 0x0800 },
-{ 0x1800 },
-{ 0x2800 },
-{ 0x3800 },
-{ 0x4800 },
-{ 0x5800 },
-{ 0x6800 },
-{ 0x7800 },
-{ 0x8800 },
-{ 0x9800 },
-{ 0xa800 },
-{ 0xb800 },
-{ 0xc800 },
-{ 0xd800 },
-{ 0xe800 },
-{ 0xf800 }
-};
-
-#define MEM_MASK 64
-
-struct {
-  unsigned char mem_index;
-  unsigned long mem_start;
-  unsigned char num_pages;
-} mem_table[] = {
-{ 16, 0x0c, 40 },
-{ 18, 0x0c4000, 40 },
-{ 20, 0x0c8000, 40 },
-{ 22, 0x0cc000, 40 },
-{ 24, 0x0d, 40 },
-{ 26, 0x0d4000, 40 },
-{ 28, 0x0d8000, 40 },
-{ 30, 0x0dc000, 40 },
-{144, 0xfc, 40 },
-{148, 0xfc8000, 40 },
-{154, 0xfd, 40 },
-{156, 0xfd8000, 40 },
-{  0, 0x0c, 20 },
-{  1, 0x0c2000, 20 },
-{  2, 0x0c4000, 20 },
-{  3, 0x0c6000, 20 }
-};
-
-#define IRQ_MASK 243
-struct {
-   unsigned char new_irq;
-   unsigned char old_irq;
-} irq_table[] = {
-   {  3,  3 },
-   {  4,  4 },
-   { 10, 10 },
-   { 14, 15 }
-};
--- linux-2.6.11-rc3-mm2-full/drivers/net/smc-mca.c.old	2005-02-16 18:44:29.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/smc-mca.c	2005-02-16 18:47:24.0 +0100
@@ -49,7 +49,6 @@
 #include 
 
 #include "8390.h"
-#include "smc-mca.h"
 
 #define DRV_NAME "smc-mca"
 
@@ -100,6 +99,63 @@
 MODULE_PARM_DESC(ultra_io, "SMC Ultra/EtherEZ MCA I/O base address(es)");
 MODULE_PARM_DESC(ultra_irq, "SMC Ultra/EtherEZ MCA IRQ number(s)");
 
+static struct {
+  unsigned int base_addr;
+} addr_table[] = {
+{ 0x0800 },
+{ 0x1800 },
+{ 0x2800 },
+{ 0x3800 },
+{ 0x4800 },
+{ 0x5800 },
+{ 0x6800 },
+{ 0x7800 },
+{ 0x8800 },
+{ 0x9800 },
+{ 0xa800 },
+{ 0xb800 },
+{ 0xc800 },
+{ 0xd800 },
+{ 0xe800 },
+{ 0xf800 }
+};
+
+#define MEM_MASK 64
+
+static struct {
+  unsigned char mem_index;
+  unsigned long mem_start;
+  unsigned char num_pages;
+} mem_table[] = {
+{ 16, 0x0c, 40 },
+{ 18, 0x0c4000, 40 },
+{ 20, 0x0c8000, 40 },
+{ 22, 0x0cc000, 40 },
+{ 24, 0x0d, 40 },
+{ 26, 0x0d4000, 40 },
+{ 28, 0x0d8000, 40 },
+{ 30, 0x0dc000, 40 },
+{144, 0xfc, 40 },
+{148, 0xfc8000, 40 },
+{154, 0xfd, 40 },
+{156, 0xfd8000, 40 },
+{  0, 0x0c, 20 },
+{  1, 0x0c2000, 20 },
+{  2, 0x0c4000, 20 },
+{  3, 0x0c6000, 20 }
+};
+
+#define IRQ_MASK 243
+static struct {
these tables should be const-ified
-
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: Should kirqd work on HT?

[Jeff Garzik]

Martin J. Bligh wrote:
--Jeff Garzik <[EMAIL PROTECTED]> wrote (on Saturday, February 19, 2005 
11:30:53 -0500):

Pallipadi, Venkatesh wrote:
You are right. Kernel balancer doesn't move around the irqs, unless it
has too many interrupts. The logic is moving around interrupts all the
time will not be good on caches. So, there is a threshold above which
the balancer start moving things around.
You should see them moving around if you do 'ping -f' or a big 'dd' from
the disk.
If kirqd is moving NIC interrupts, it's broken.
(and another reason why irqbalanced is preferable)

Why is it broken to move NIC interrupts? Obviously you don't want to
rotate them around a lot, but in the interests of fairness to other 
processes, it seems reasonable to migrate them occasionally (IIRC, kirqd
rate limits to once a second or something).
This has been explained to you before, search your email archives...
The main problem that has been seen in the field SMP packet ordering, 
but a secondary problem observed is cache misses.  Just NAPI mitigates 
this somewhat (no pun intended).

Overall, kirqd should be avoided except in special situations.  It 
doesn't know about such policy things as network-specific or 
storage-specific irq balancing (and shouldn't).

Jeff
-
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: Help - really messed up kernel

[Joshua Hudson]

On Sun, 20 Feb 2005, Brian Beattie wrote:

> On Sun, 2005-02-20 at 15:22 -0800, Joshua Hudson wrote:
> > I am trying to install linux on a laptop that cannot boot from cdrom.
> I handled this by putting smart-boot http://btmgr.webframe.org/ in the
> hard drive MBR from a dos floppy,  smart-boot can boot from a cdrom.
> Then as long as you don't wipe out your MBR you can still boot from a
> cdrom.
>
Ah yes, that crashes. Spotted it in Slackware 10 install CD, but it
doesn't work on this system. Too bad.
> --
> Brian Beattie   LFS12947 | "Honor isn't about making the right choices.
> [EMAIL PROTECTED] | It's about dealing with the consequences."
> www.beattie-home.net | -- Midori Koto
>
>
>

-
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: Help - really messed up kernel

[Brian Beattie]

On Sun, 2005-02-20 at 15:22 -0800, Joshua Hudson wrote:
> I am trying to install linux on a laptop that cannot boot from cdrom.
I handled this by putting smart-boot http://btmgr.webframe.org/ in the
hard drive MBR from a dos floppy,  smart-boot can boot from a cdrom.
Then as long as you don't wipe out your MBR you can still boot from a
cdrom.

-- 
Brian Beattie   LFS12947 | "Honor isn't about making the right choices.
[EMAIL PROTECTED] | It's about dealing with the consequences."
www.beattie-home.net | -- Midori Koto


-
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: [RFC] pdirops: vfs patch

[Alex Tomas]

> Jan Blunck (JB) writes:

 JB> With luck you have s_pdirops_size (or 1024) different renames altering
 JB> concurrently one directory inode. Therefore you need a lock protecting
 JB> your filesystem data. This is basically the job done by i_sem. So in
 JB> my opinion you only move "The Problem" from the VFS to the lowlevel
 JB> filesystems. But then there is no need for i_sem or your
 JB> s_pdirops_sems anymore.

1) i_sem protects dcache too
2) tmpfs has no "own" data, so we can use it this way (see 2nd patch)
3) I have pdirops patch for ext3, but it needs some cleaning ...

thanks, 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: PROBLEM: agpgart-via: probe fails with error -22

[Dave Jones]

On Sun, Feb 20, 2005 at 01:57:22PM -0500, Kenton Groombridge wrote:
 > [1.]  PROBLEM: agpgart-via: probe fails with error -22
 > 
 > [2.]  When loading agpgart/agpgart-via the following occurs:
 > 
 > Linux agpgart interface v0.100 (c) Dave Jones
 > agpgart: Detected VIA KT400/KT400A/KT600 chipset
 > agpgart: Maximum main memory to use for agp memory: 816M
 > agpgart: unable to determine aperture size.
 > agpgart: agp_backend_initialize() failed.
 > agpgart-via: probe of :00:00.0 failed with error -22

Can you send me the output of (as root)  lspci -xxx
Also, is there a setting in your BIOS for 'aperture size' ?
If so, what is it set to ?

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: [RFC] pdirops: vfs patch

[Jan Blunck]

Alex Tomas wrote:
+static inline struct semaphore * lock_sem(struct inode *dir, struct qstr *name)
+{
+   if (IS_PDIROPS(dir)) {
+   struct super_block *sb;
+   /* name->hash expected to be already calculated */
+   sb = dir->i_sb;
+   BUG_ON(sb->s_pdirops_sems == NULL);
+   return sb->s_pdirops_sems + name->hash % sb->s_pdirops_size;
+   }
+   return >i_sem;
+}
+
+static inline void lock_dir(struct inode *dir, struct qstr *name)
+{
+   down(lock_sem(dir, name));
+}
+

@@ -1182,12 +1204,26 @@
 /*
  * p1 and p2 should be directories on the same fs.
  */
-struct dentry *lock_rename(struct dentry *p1, struct dentry *p2)
+struct dentry *lock_rename(struct dentry *p1, struct qstr *n1,
+struct dentry *p2, struct qstr *n2)
 {
 	struct dentry *p;
 
 	if (p1 == p2) {
-		down(>d_inode->i_sem);
+		if (IS_PDIROPS(p1->d_inode)) {
+			unsigned int h1, h2;
+			h1 = n1->hash % p1->d_inode->i_sb->s_pdirops_size;
+			h2 = n2->hash % p2->d_inode->i_sb->s_pdirops_size;
+			if (h1 < h2) {
+lock_dir(p1->d_inode, n1);
+lock_dir(p2->d_inode, n2);
+			} else if (h1 > h2) {
+lock_dir(p2->d_inode, n2);
+lock_dir(p1->d_inode, n1);
+			} else
+lock_dir(p1->d_inode, n1);
+		} else
+			down(>d_inode->i_sem);
 		return NULL;
 	}
 
@@ -1195,31 +1231,35 @@
 
 	for (p = p1; p->d_parent != p; p = p->d_parent) {
 		if (p->d_parent == p2) {
-			down(>d_inode->i_sem);
-			down(>d_inode->i_sem);
+			lock_dir(p2->d_inode, n2);
+			lock_dir(p1->d_inode, n1);
 			return p;
 		}
 	}
 
 	for (p = p2; p->d_parent != p; p = p->d_parent) {
 		if (p->d_parent == p1) {
-			down(>d_inode->i_sem);
-			down(>d_inode->i_sem);
+			lock_dir(p1->d_inode, n1);
+			lock_dir(p2->d_inode, n2);
 			return p;
 		}
 	}
 
-	down(>d_inode->i_sem);
-	down(>d_inode->i_sem);
+	lock_dir(p1->d_inode, n1);
+	lock_dir(p2->d_inode, n2);
 	return NULL;
 }
With luck you have s_pdirops_size (or 1024) different renames altering 
concurrently one directory inode. Therefore you need a lock protecting 
your filesystem data. This is basically the job done by i_sem. So in my 
opinion you only move "The Problem" from the VFS to the lowlevel 
filesystems. But then there is no need for i_sem or your s_pdirops_sems 
anymore.

Regards,
Jan
-
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/

Help - really messed up kernel

[Joshua Hudson]

I am trying to install linux on a laptop that cannot boot from cdrom.
I got a stripped-down kernel to boot from floppy, ran lspci to get
the hardware information.

I then reconfigured and rebuilt the kernel for the image.

I built this kernel from stock 2.6.10 from www.kernel.org.
This is the configuration file. I then installed it on a floppy disk
with syslinux, then tried to boot it.

boot: vmlinuz root=/dev/fd0 load_ramdisk=1 prompt_ramdisk=1
(my ramdisk is the next flooppy, this kernel is 1.3mb)
Did not load the ramdisk.
I got an error about unable to open root on "" or device 22,6.
Hmm. So, I ran rdev to set the kernel default root to /dev/fd0 and booted.

Result: loaded the ramdisk, then complained about lack of a valid
filesystem on /dev/fd0

Hmm. I've never seen anything like this before.
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.10
# Sun Feb 20 14:07:04 2005
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_LOG_BUF_SHIFT=14
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
# CONFIG_IKCONFIG is not set
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_FUTEX=y
CONFIG_EPOLL=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y

#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
CONFIG_M586=y
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_PPRO_FENCE=y
CONFIG_X86_F00F_BUG=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_ALIGNMENT_16=y
# CONFIG_HPET_TIMER is not set
# CONFIG_SMP is not set
CONFIG_PREEMPT=y
# CONFIG_X86_UP_APIC is not set
# CONFIG_X86_MCE is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set

#
# Firmware Drivers
#
# CONFIG_EDD is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
CONFIG_HAVE_DEC_LOCK=y
# CONFIG_REGPARM is not set

#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
CONFIG_SOFTWARE_SUSPEND=y
CONFIG_PM_STD_PARTITION="/dev/hda2"

#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_IBM is not set
# CONFIG_ACPI_TOSHIBA is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_BUS=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y

#
# APM (Advanced Power Management) BIOS Support
#
CONFIG_APM=y
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
# CONFIG_APM_DO_ENABLE is not set
# CONFIG_APM_CPU_IDLE is not set
# CONFIG_APM_DISPLAY_BLANK is not set
# CONFIG_APM_RTC_IS_GMT is not set
# CONFIG_APM_ALLOW_INTS is not set
# CONFIG_APM_REAL_MODE_POWER_OFF is not set

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y

cifs connection loss hangs

[Cameron Harris]

Being a wireless user i experience the occasional connection loss due
to walking out of range or something, recently after starting to use
cifs mounts instead of smbfs, I've noticed that stuff tends to break
if i lose connection.
I first noticed this when my bootscript brought down the wireless
before it umounted the cifs share, and it hung the shutdown. Recently
i was copying some files over with a nautilus window open. I lost
connection and the nautilus window & the cp process froze. ps said
that they were stuck in D (Uninterruptible Sleep). I read it's a
kernel problem if something gets stuck in it. umounting the cifs
filesystem didn't even wake up the process, I had to reboot (which
didn't work right because something was stuck with a file open).
Anyone got any ideas on how this could be fixed? 
Thanks
-- 
Cameron Harris
-
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: ASUS P2B-DS

[Tim Schmielau]

> Hi Vise People,
> 
> 
> ASUS P2B-DS board seems NOT work very well with default kernel in FED
> Core 3.  smp-kernel hangs booting at various stages. I am goig to try
> 2.6.10 today. non-smp-kernel boots fine. This is my first time I try to
> test with smp-kernels so I don't know what I could try. Could someone
> give me some directions what to test?
> 
> If someone already know this is doomed motherboard might say so I
> wouldn't waste time with it. Thanks.

P2B-DS is a great, robust mainboard. This mail is written on one, and we 
have some more in production. Never had any problems with them.

Try deleting the OSS sound drivers under /lib/modules/*/kernel/sound/oss/ .

While I don't run fedora, I had similar problems with SuSE 9.1 and 9.2.
These boiled down to a problem with the el cheapo fm801 soundcard I 
plugged into the board.
The default installation installed an OSS driver that is not SMP-safe. 
After removing the driver, the correct ALSA driver got selected and 
everything was fine.

Hope this helps
Tim
-
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: [RFC 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview II

[Andi Kleen]

> Do you have any better way to suggest, Andi, for a batch manager to
> relocate a job?  The typical scenario, as Ray explained it to me, is

- Give the shared libraries and any other files a suitable policy
(by mapping them and applying mbind) 

- Then execute migrate_pages() for the anonymous pages with a suitable
old node -> new node mapping.

> How would you recommend that the batch manager move that job to the
> nodes that can run it?  The layout of allocated memory pages and tasks
> for that job must be preserved in order to keep the same performance.
> The migration method needs to scale to hundreds, or more, of nodes.

You have to walk to full node mapping for each array, but
even with hundreds of nodes that should not be that costly
(in the worst case you could create a small hash table for it
in the kernel, but I'm not sure it's worth it) 

-Andi
-
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: [RFC 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview II

[Paul Jackson]

Andi wrote:
> I still think it's fundamentally unclean and racy. External processes
> shouldn't mess with virtual addresses of other processes.

It's not really messing with (changing) the virtual addresses of
another process.  It's messing with the physical placement.  It's
using the virtual addresses to help choose which pages to move.

Do you have any better way to suggest, Andi, for a batch manager to
relocate a job?  The typical scenario, as Ray explained it to me, is
thus.  A lower priority job, after running a while, is displaced by a
higher priority job that needs a large number of nodes.  Later on enough
nodes to run the lower priority job become available elsewhere.  The
lower priority job can either continue to wait for its original nodes to
come free (after the high priority job finishes) or it can be relocated
to the nodes available now.

How would you recommend that the batch manager move that job to the
nodes that can run it?  The layout of allocated memory pages and tasks
for that job must be preserved in order to keep the same performance.
The migration method needs to scale to hundreds, or more, of nodes.

(I'm starting to have visions of vma's having externally visible id's,
in a per-task namespace.)

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
1.925.600.0401
-
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: proc path_walk glitch ?

[Bodo Eggert]

Der Herr Hofrat <[EMAIL PROTECTED]> wrote:

> cd /proc/8655
> kill -9 8655
> ls
> /usr/bin/ls: .: Stale NFS file handle

Seems to be fixed in 2.6.10-ac9 or earlier
-
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] /proc/kmalloc

[Arnd Bergmann]

On Sünndag 20 Februar 2005 21:47, Matt Mackall wrote:
> I've been sitting on this for over a year now, kicking it out in the
> hopes that someone finds it useful. kernel.org was down when I was
> tidying this up so it's against 2.6.10 which is what I had handy.
>
> /proc/kmalloc allocation tracing

Nice. I have done something similar for the buddy allocator but never
got around to sending it.

> This quick hack adds accounting for kmalloc/kfree callers. This can
> aid in tracking down memory leaks and large dynamic memory users. The
> stock version use ~280k of memory for hash tables and can track 32k
> active allocations.
> 
> Here's some sample output from my laptop:
> 
> total bytes allocated: 47118848   
> slack bytes allocated:  8717262
> net bytes allocated:2825920
> number of allocs:132796
> number of frees: 122629
> number of callers:  325
> lost callers: 0
> lost allocs:  0
> unknown frees:0
> 
>totalslack  net alloc/free  caller
>2457600 3/3 copy_thread+0x1ad

The format is not really easy to parse, it probably makes sense to
split the two parts into separate files. I also think that debugfs
would be a more appropriate place to put this in than procfs.

> +void __kmalloc_account(const void *caller, const void *addr, int size, int 
> req)
> +{
> + int i, hasha, hashc;
> + unsigned long flags;
> +
> + spin_lock_irqsave(_lock, flags);
> + if(req >= 0) /* kmalloc */
> + {
> + /* find callers slot */
> + hashc = kma_hash(caller, MAX_CALLER_TABLE);
> + for (i = 0; i < MAX_CALLER_TABLE; i++) {
> + if (!kma_caller[hashc].caller ||
> + kma_caller[hashc].caller == caller)
> + break;
> + hashc = (hashc + 1) % MAX_CALLER_TABLE;
> + }

The housekeeping that is needed for the hash implementation is rather
complicated. The code that I wrote did a static allocation from inside
a macro, like

#define kmalloc(_size, _gfp) \
({ \
static struct kma_caller _caller \
__attribute__((section(".kmalloc.data"))) = { \
.func = __FUNCTION__, \
.line = __LINE__, \
}; \
_caller.count++; \
_caller.size += (_size); \
__kmalloc((_size), (_gfp)); \
})

Then I could simply print out all allocations by walking through the
special linker section. OTOH, your implementation has the advantage
that it can directly match kmalloc/kfree pairs and that it does not
rely on special linker magic.

Arnd <><


pgp01ROXTHZ22.pgp
Description: signature

Re: 2.6.11-rc3-mm2: lockup in sys_timer_settime

[Alexander Nyberg]

> When running a Posix conformance test (from posixtestsuite), the kernel
> locks up with:
> 
> BUG: soft lockup detected on CPU#0
> 
> Pid:  1873, comm: 10-1.test
> EIP: 0060:[] CPU: 0
> EIP is at sys_timer_settime+0xfa+0x1f0
>  EFLAGS: 0282  Not tainted (2.6.11-rc3-mm2)
> EAX: 0282 EBX: 0001 ECX:  EDX: 
> ESI:  EDI:  EBP: f17eafbc DS: 007b ES: 007b
> CR0: 8005003b CR2: b7fac1f0 CR3: 311b3000 CR4: 06d0
> 
> in test conformance/interfaces/timer_create/10-1.c (attached).
> 
> It doesn't lockup with 2.6.11-rc4; I notice the rc3-mm2 has a lot of
> Posix-timer related changes.

Hi Roland

The problem arises from code touching the union in alloc_posix_timer() 
which makes firing go non-zero. When firing is checked in posix_cpu_timer_set()
it will be positive causing an infinite loop.

So either the below fix or preferably move the INIT_LIST_HEAD(x) from 
alloc_posix_timer()
to somewhere later where it doesn't disturb the other union members.


Index: linux-2.6.10/kernel/posix-cpu-timers.c
===
--- linux-2.6.10.orig/kernel/posix-cpu-timers.c 2005-02-20 22:23:30.0 
+0100
+++ linux-2.6.10/kernel/posix-cpu-timers.c  2005-02-20 22:27:03.0 
+0100
@@ -323,6 +323,7 @@
INIT_LIST_HEAD(_timer->it.cpu.entry);
new_timer->it.cpu.incr.sched = 0;
new_timer->it.cpu.expires.sched = 0;
+   new_timer->it.cpu.firing = 0;
 
read_lock(_lock);
if (CPUCLOCK_PERTHREAD(new_timer->it_clock)) {


-
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: [RFC 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview II

[Andi Kleen]

> >Perhaps node masks would be better and teaching the kernel to handle
> >relative distances inside the masks transparently while migrating?
> >Not sure how complicated this would be to implement though.
> >
> >Supporting interleaving on the new nodes may be also useful, that would
> >need a policy argument at least too and masks.
> >
> 
> The worry I have about using node masks is that it is not as general as
> old_node,new_node mappings (or preferably, the original proposal I made
> of old_node_list, new_node_list).  One can't differentiate between the

I agree that the node arrays are better for this case.

> >>and the majority of the memory is shared, then we only need to make
> >>one system call and one page table scan.  (We just "migrate" the
> >>shared object once.) So the time to do the page table scans disappears
> >
> >
> >I don't like this because it makes it much more complicated
> >to use for user space. And you can set separate policies for
> >shared objects anyways.
> 
> Yes, but only programs that care have to use the va_start and
> va_end.  Programs who want to move everything can specify
> 0 and MAX_INT there and they are done.

I still think it's fundamentally unclean and racy. External processes
shouldn't mess with virtual addresses of other processes.

> >-Andi
> 
> But we are least at the level of agreeing that the new system
> call looks something like the following:
> 
> migrate_pages(pid, count, old_list, new_list);
> 
> right?

For the external case probably yes. For internal (process does this
on its own address space) it should be hooked into mbind() too.

-Andi
-
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] typo in include/linux/compiler.h

[Olaf Hering]

small nitpick, __KERNEL__ is the inner ifdef.


Signed-off-by: Olaf Hering <[EMAIL PROTECTED]>

diff -purN linux-2.6.11-rc4.orig/include/linux/compiler.h 
linux-2.6.11-rc4-klibc/include/linux/compiler.h
--- linux-2.6.11-rc4.orig/include/linux/compiler.h  2005-02-13 
04:06:55.0 +0100
+++ linux-2.6.11-rc4-klibc/include/linux/compiler.h 2005-02-20 
17:16:47.340324407 +0100
@@ -72,10 +72,10 @@ extern void __chk_io_ptr(void __iomem *)
 (typeof(ptr)) (__ptr + (off)); })
 #endif
 
-#endif /* __ASSEMBLY__ */
-
 #endif /* __KERNEL__ */
 
+#endif /* __ASSEMBLY__ */
+
 /*
  * Allow us to mark functions as 'deprecated' and have gcc emit a nice
  * warning for each use, in hopes of speeding the functions removal.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: IBM Thinkpad G41 PCMCIA problems [Was: Yenta TI: ... no PCI

[David Härdeman]

On Sun, 20 Feb 2005, Linus Torvalds wrote:
Russell, what do your eagle-eyes think of a patch like this?
Steven, does this fix it without the need for any kernel command line (or
any other patches, for that matter - ie revert all the transparency-
changing ones)?
		Linus
I tried the patch on my G40 with 1Gb RAM (previous thread about it is at 
http://marc.theaimsgroup.com/?t=11088915341=1=2), and it works 
great, PCI resources are now located at 0x4000 and no further 
tricks/patches are necessary.

Re,
David
-
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: proc path_walk glitch ?

[Matthias-Christian Ott]

Der Herr Hofrat wrote:
HI !
I noticed a slight proc filesystem strangness in the 2.4.2X and 2.6.X 
(atleast up to 2.6.8).  Assuming that process 8655 exists and is running 
long enough (ls -lR / or so)

cd /proc/8655
kill -9 8655
ls
/usr/bin/ls: .: Stale NFS file handle
open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 ESTALE (Stale NFS file 
handle)  from  fs/namei.c -> link_path_walk :
int fastcall link_path_walk(const char * name, struct nameidata *nd)
{
struct dentry *dentry;
struct inode *inode;
int err;
unsigned int lookup_flags = nd->flags;
while (*name=='/')
name++;
if (!*name)
goto return_reval;
...
return_reval:
/*
 * We bypassed the ordinary revalidation routines.
 * Check the cached dentry for staleness.
 */
dentry = nd->dentry;
if (dentry && dentry->d_op && dentry->d_op->d_revalidate) {
err = -ESTALE;
if (!dentry->d_op->d_revalidate(dentry, 0)) {
d_invalidate(dentry);
break;
}
}
Why does return_reval return -ESTALE instead of -ENOENT here - might need an
extra check on what filesystem this is working on ?
/usr/bin/ls: .: no such file or directory
would seem more meaningfull to me when I find it in a logfile.
thx !
hofrat
-
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/
 

Does it happen in 2.6.10 or are you sing 2.6.8?
Matthias-Christian Ott
-
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: Panic in 2.6.11-rc4

[Matthias-Christian Ott]

Ben Greear wrote:
I see this panic when booting 2.6.11-rc4 (plus some of my own 
patches...but my modules
have not loaded at the point of the crash).

The system is a Shuttle system with the FB65 motherboard.  CPU is 
3.0Ghz P4 with
1MB cache and hyperthreading.  HD is an 80GB SATA disk.  NVIDIA card 
is installed
(but I have not installed the NVIDIA drivers).

The system boots the latest FC2 kernel (2.6.10-1-something) fine, and 
other
FC2 kernels too.  The system hangs trying to discover hardware
when I try to boot a 2.6.9 kernel I compiled...

Also, the system will not save it's BIOS settings.  I'm not sure exactly
what that indicates, other than potentially flaky hardware of some 
sort...

Any ideas are welcome!
Thanks,
Ben
Linux version 2.6.11-rc4 ([EMAIL PROTECTED]) (gcc version 3.3.3 
20040412 (Red Hat Linux 3.3.3-7)5BIOS-provided physical RAM map:
 BIOS-e820:  - 0009f800 (usable)
 BIOS-e820: 0009f800 - 000a (reserved)
 BIOS-e820: 000f - 0010 (reserved)
 BIOS-e820: 0010 - 1fff (usable)
 BIOS-e820: 1fff - 1fff3000 (ACPI NVS)
 BIOS-e820: 1fff3000 - 2000 (ACPI data)
 BIOS-e820: fec0 - 0001 (reserved)
0MB HIGHMEM available.
511MB LOWMEM available.
found SMP MP-table at 000f52c0
DMI 2.2 present.
ACPI: PM-Timer IO Port: 0x408
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 15:4 APIC version 20
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1 15:4 APIC version 20
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Built 1 zonelists
Kernel command line: ro root=LABEL=/ console=ttyS0,38400 console=tty0
Initializing CPU#0
PID hash table entries: 2048 (order: 11, 32768 bytes)
Detected 3008.737 MHz processor.
Using pmtmr for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 514532k/524224k available (2124k kernel code, 9052k reserved, 
838k data, 232k init, 0k hi)Checking if this processor honours the WP 
bit even in supervisor mode... Ok.
Security Framework v1.0.0 initialized
SELinux:  Initializing.
SELinux:  Starting in permissive mode
selinux_register_security:  Registering secondary module capability
Capability LSM initialized as secondary
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
monitor/mwait feature present.
using mwait in idle threads.
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 1024K
CPU: Physical Processor ID: 0
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
CPU0: Thermal monitoring enabled
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
CPU0: Intel(R) Pentium(R) 4 CPU 3.00GHz stepping 01
per-CPU timeslice cutoff: 2926.21 usecs.
task migration cache decay timeout: 3 msecs.
Booting processor 1/1 eip 3000
Initializing CPU#1
monitor/mwait feature present.
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 1024K
CPU: Physical Processor ID: 0
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
CPU1: Intel P4/Xeon Extended MCE MSRs (12) available
CPU1: Thermal monitoring enabled
CPU1: Intel(R) Pentium(R) 4 CPU 3.00GHz stepping 01
Total of 2 processors activated (11960.32 BogoMIPS).
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 pin1=2 pin2=-1
checking TSC synchronization across 2 CPUs: passed.
Brought up 2 CPUs
checking if image is initramfs...it isn't (no cpio magic); looks like 
an initrd
Freeing initrd memory: 293k freed
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfb460, last bus=3
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20050125
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
PCI: Ignoring BAR0-3 of IDE controller :00:1f.2
PCI: Transparent bridge - :00:1e.0
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 9 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs *3 4 5 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 *5 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 7 9 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNK0] (IRQs 3 4 5 7 *9 10 

[PATCH] /proc/kmalloc

[Matt Mackall]

I've been sitting on this for over a year now, kicking it out in the
hopes that someone finds it useful. kernel.org was down when I was
tidying this up so it's against 2.6.10 which is what I had handy.

/proc/kmalloc allocation tracing

This quick hack adds accounting for kmalloc/kfree callers. This can
aid in tracking down memory leaks and large dynamic memory users. The
stock version use ~280k of memory for hash tables and can track 32k
active allocations.

Here's some sample output from my laptop:

total bytes allocated: 47118848   
slack bytes allocated:  8717262
net bytes allocated:2825920
number of allocs:132796
number of frees: 122629
number of callers:  325
lost callers: 0
lost allocs:  0
unknown frees:0

   totalslack  net alloc/free  caller
   2457600 3/3 copy_thread+0x1ad
 192   56  192 1/0 fbcon_startup+0xc9
   32768032768 1/0 fbcon_startup+0x267
   18720 9360   32   585/584   bit_cursor+0x1a1
81920 8192 1/0 sys_ioperm+0x6c
81920 8192 1/0 register_framebuffer+0x10b
 5120  512 1/0 fb_alloc_cmap+0x42
 5120  512 1/0 fb_alloc_cmap+0x55
8192 3192 8192 1/0 framebuffer_alloc+0x36
 5120  512 1/0 fb_alloc_cmap+0x68
  640   64 1/0 fb_add_videomode+0x52
10334976  45215520 80742/80742 soft_cursor+0x67
  320   32 1/0 mtrr_file_add+0x8c
 128   36  128 1/0 create_driver+0x20
168427520   212992  4112/4060  dup_task_struct+0x3d
15360012/12radeon_do_probe_i2c_edid+0x5f
 672  336  67221/0 acpi_os_create_semaphore+0x17
  32   32   32 1/0 acpi_os_create_lock+0xd
 448   280 7/7 acpi_os_queue_for_execution+0x2a
2016  252 118463/26__request_region+0x20
 768  480  76824/0 register_sysctl_table+0x24
  328   32 1/0 radeon_agp_alloc+0x6b
 128   52  128 1/0 radeon_agp_init+0x3f
 224   56  224 7/0 radeon_addmap+0x2b
 224  140  224 7/0 radeon_addmap+0x11f
4096 1792 4096 1/0 radeon_addbufs_agp+0x197
1024  896 102432/0 radeon_addbufs_agp+0x273
2880  720 172815/6 groups_alloc+0x35
  32   280 1/1 radeon_ctxbitmap_next+0xfd
40960 4096 1/0 radeon_ctxbitmap_init+0x26
2048  732 2048 1/0 radeon_dma_setup+0x1a
  32   16   32 1/0 radeon_addctx+0x77
 7680  768 6/0 __create_workqueue+0x3b
  32   20   32 1/0 radeon_setup+0x97
  32   16   32 1/0 radeon_setup+0xd7
  64   24   64 2/0 inter_module_register+0x1f
 128   320 1/1 sock_kmalloc+0x3d
  64   16   64 1/0 radeon_open_helper+0x51
 5347584  2076992  1048576  3520/3264  alloc_skb+0x34
4160 1392 416028/0 param_sysfs_setup+0x4c
  514304   2147840  1008/1008  pskb_expand_head+0x4c
  32   22   32 1/0 radeon_setunique+0x73
  32   15   32 1/0 radeon_setunique+0xca
 160   24  160 2/0 radeon_realloc+0x21
 576  360  19218/12radeon_vm_open+0x32
 1920  192 1/0 radeon_stub_getminor+0xa4
   19200 51600   112/112   acpi_ut_initialize_buffer+0x24
  269344   111231   195008  5588/1890  acpi_ut_callocate+0x37
   24416174610   761/761   acpi_ut_allocate+0x38
 512  248  512 1/0 radeon_do_init_cp+0x2b
 320  266  32010/0 net_sysctl_strdup+0x2a
  64   40   64 2/0 use_module+0x8c
...



Index: km/init/Kconfig
===
--- km.orig/init/Kconfig2004-12-24 13:35:24.0 -0800
+++ km/init/Kconfig 2005-02-20 10:51:49.0 -0800
@@ -287,6 +287,13 @@ config KALLSYMS_EXTRA_PASS
   reported.  KALLSYMS_EXTRA_PASS is only a temporary workaround while
   you wait for kallsyms to be fixed.
 
+config KMALLOC_ACCOUNTING
+   default n
+   bool "Enabled accounting of kmalloc/kfree allocations" if EMBEDDED
+   help
+ This option records kmalloc and kfree activity and reports it via
+ /proc/kmalloc.
+
 config FUTEX
bool "Enable futex support" if EMBEDDED
default y
Index: km/mm/slab.c
===
--- km.orig/mm/slab.c   2004-12-24 13:35:59.0 -0800
+++ km/mm/slab.c2005-02-20 10:50:15.0 -0800
@@ -2427,6 +2427,7 @@ 

ASUS P2B-DS

[Kari Laine]

Hi Vise People,


ASUS P2B-DS board seems NOT work very well with default kernel in FED
Core 3.  smp-kernel hangs booting at various stages. I am goig to try
2.6.10 today. non-smp-kernel boots fine. This is my first time I try to
test with smp-kernels so I don't know what I could try. Could someone
give me some directions what to test?

If someone already know this is doomed motherboard might say so I
wouldn't waste time with it. Thanks.

Best Regards
Kari Laine


-
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/

6300ESB watchdog driver

[David Härdeman]

Hi
I wrote earlier to the list[1] asking for a driver for the watchdog 
included in the 6300ESB chipset. I got a 2.4 driver via private email 
from Ross Biro which I've changed into what I hope resembles a 2.6 
driver (which was done by looking a lot at the watchdog drivers already 
in the 2.6 tree).

I've attached the result, and I'm hoping to get some feedback on the 
coding as a first step. I can't actually test it on the hardware right 
now as I won't have physical access until April. So my own tests have 
been limited to "compiles-without-warnings" and 
"can-be-insmodded-in-other-machine-without-oops".

As I said, it's the first thing I've ever written, so I'm guessing it 
has a few rough edges. Feedback welcome :-)

Re,
David
[1] http://marc.theaimsgroup.com/?l=linux-kernel=110711079825794=2
[2] http://marc.theaimsgroup.com/?l=linux-kernel=110711973917746=2
diff -Nur linux-2.6.10.orig/drivers/char/watchdog/i6300esb.c 
linux-2.6.10/drivers/char/watchdog/i6300esb.c
--- linux-2.6.10.orig/drivers/char/watchdog/i6300esb.c  1970-01-01 
01:00:00.0 +0100
+++ linux-2.6.10/drivers/char/watchdog/i6300esb.c   2005-02-07 
23:27:08.0 +0100
@@ -0,0 +1,508 @@
+/*
+ * i6300esb 0.03:  Watchdog timer driver for Intel 6300ESB chipset
+ *
+ * (c) Copyright 2004 Google Inc. 
+ *
+ * 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; either version
+ * 2 of the License, or (at your option) any later version.
+ * 
+ *  based on i810-tco.c which is
+ *
+ * (c) Copyright 2000  kernel concepts <[EMAIL PROTECTED]>
+ * developed for
+ *  Jentro AG, Haar/Munich (Germany)
+ *
+ * which is in turn based on softdog.c by Alan Cox <[EMAIL PROTECTED]>
+ *
+ * The timer is implemented in the following I/O controller hubs:
+ * (See the intel documentation on http://developer.intel.com.)
+ * 6300ESB chip : document number 300641-003
+ * 
+ *  2004YYZZ Ross Biro
+ * Initial version 0.01
+ *  2004YYZZ Ross Biro
+ * Version 0.02
+ *  20050210 David Härdeman <[EMAIL PROTECTED]>
+ *  Ported driver to kernel 2.6
+ */
+
+/*
+ *  Includes, defines, variables, module parameters, ...
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "i6300esb.h"
+
+/* Module and version information */
+#define ESB_VERSION "0.03"
+#define ESB_MODULE_NAME "i6300ESB timer"
+#define ESB_DRIVER_NAME ESB_MODULE_NAME ", v" ESB_VERSION
+#define PFX ESB_MODULE_NAME ": "
+
+/* internal variables */
+static void __iomem *BASEADDR;
+static spinlock_t esb_lock; /* Guards the hardware */
+static unsigned long timer_alive;
+static struct pci_dev *esb_pci;
+static unsigned short triggered; /* The status of the watchdog upon boot */
+static char esb_expect_close;
+
+/* module parameters */
+#define WATCHDOG_HEARTBEAT 30   /* 30 sec default heartbeat 
(1 (2 * 0x03ff))
+   return -EINVAL;
+   
+   spin_lock(_lock);
+   
+   /* We shift by 9, so if we are passed a value of 1 sec,
+* val will be 1 << 9 = 512, then write that to two
+* timers => 2 * 512 = 1024 (which is decremented at 1KHz)
+*/
+   val = time << 9;
+   
+   /* Write timer 1 */
+   esb_unlock_registers();
+   writel(val, ESB_TIMER1_REG);
+   
+   /* Write timer 2 */
+   esb_unlock_registers();
+writel(val, ESB_TIMER2_REG);
+   
+/* Reload */
+   esb_unlock_registers();
+   writew(0x10, ESB_RELOAD_REG);
+
+   /* FIXME: Do we need to flush everything out? */
+   
+   /* Done */
+   heartbeat = time;
+   spin_unlock(_lock);
+   return 0;
+}
+
+static int esb_timer_read (void)
+{
+   u32 count;
+
+   /* This isn't documented, and doesn't take into
+ * acount which stage is running, but it looks
+ * like a 20 bit count down, so we might as well report it.
+ */
+pci_read_config_dword(esb_pci, 0x64, );
+return (int)count;
+}
+
+/*
+ * /dev/watchdog handling
+ */
+
+static int esb_open (struct inode *inode, struct file *file)
+{
+/* /dev/watchdog can only be opened once */
+if (test_and_set_bit(0, _alive))
+return -EBUSY;
+
+/* Reload and activate timer */
+esb_timer_keepalive ();
+esb_timer_start ();
+
+   return nonseekable_open(inode, file);
+}
+
+static int esb_release (struct inode *inode, struct file *file)
+{
+/* Shut off the timer. */
+if (esb_expect_close == 42) {
+esb_timer_stop ();
+} else {
+printk(KERN_CRIT PFX "Unexpected close, not stopping 
watchdog!\n");
+esb_timer_keepalive ();
+   

Re: Wake-on-LAN/PCI Linux support

[Piotr Rzezniczak]

> Does Linux currently support Wake-on-LAN/PCI? I have a 3Com
> 3c905 TX-M NIC which supports wake-on-LAN and wake-on-PCI.
> On Windows XP, I have configured the system so that I can use
> "ether-wake" to wake up mysystem from standby/hibernation
> remotely through the network.  
(cut) 
> However, when I shut down linux by using "init 0", the system
> gets totally shut down, including the NIC. The switch port for
> the NIC shows the card is not mantaining the link and thus,
> "ether-wake" is totally useless. 

I found the following solution for the same problem:
- use standard 3c59x driver from kernel sources (even for 3c90x cards)
- load this driver as a kernel module
- add the following entry in /etc/modules:
  cut 
 3c59x options=0x408
  cut 

Wake-on-lan works properly now with 3com 905cx-tx-m card (3c905c) on my 
Debian 3.1 (unstable) and 2.6.10 kernel

greetings
Piotr (djv) Rzezniczak
-
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: Panic in 2.6.11-rc4

[Ben Greear]

Ben Greear wrote:
I see this panic when booting 2.6.11-rc4 (plus some of my own 
patches...but my modules
have not loaded at the point of the crash).
Same things happens with a kernel built w/out any of my patches, by the 
way...
Ben
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc  http://www.candelatech.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/

proc path_walk glitch ?

[Der Herr Hofrat]

HI !

 I noticed a slight proc filesystem strangness in the 2.4.2X and 2.6.X 
 (atleast up to 2.6.8).  Assuming that process 8655 exists and is running 
 long enough (ls -lR / or so)

cd /proc/8655
kill -9 8655
ls
/usr/bin/ls: .: Stale NFS file handle

open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 ESTALE (Stale NFS 
file handle)  from  fs/namei.c -> link_path_walk :

int fastcall link_path_walk(const char * name, struct nameidata *nd)
{
struct dentry *dentry;
struct inode *inode;
int err;
unsigned int lookup_flags = nd->flags;

while (*name=='/')
name++;
if (!*name)
goto return_reval;
...

return_reval:
/*
 * We bypassed the ordinary revalidation routines.
 * Check the cached dentry for staleness.
 */
dentry = nd->dentry;
if (dentry && dentry->d_op && dentry->d_op->d_revalidate) {
err = -ESTALE;
if (!dentry->d_op->d_revalidate(dentry, 0)) {
d_invalidate(dentry);
break;
}
}


 Why does return_reval return -ESTALE instead of -ENOENT here - might need an
extra check on what filesystem this is working on ?

/usr/bin/ls: .: no such file or directory

 would seem more meaningfull to me when I find it in a logfile.

thx !
hofrat
-
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.6.11rc4: irq 5, nobody cared

[Matthias-Christian Ott]

Rogério Brito wrote:
On Feb 20 2005, Matthias-Christian Ott wrote:
 

Rogério Brito wrote:
   

I am willing to test any patch and configuration (let's call me a
"guinea pig"), but I don't know what I should do. I have, OTOH,
reported my problem many times in the past few days. :-(
I will retry sending my message to the list once again, with the
details (in my case, the message I get is "irq 10: nobody cared!"
and it is regarding my primary HD on my secondary Promise PDC20265
controller).
 

First of all, Matthias-Christian, thank you very much for your kind
answer.
I have already tried contacting the linux-ide mailing list as a CC to my
earlier messages, but I got no response. I am including some details in
this e-mail. I included Bartlomiej in the CC, as he is listed as general
IDE maintainer in the MAINTAINERS file.
 

Report it to http://bugzilla.kernel.org/. Maybe you'll get help there.
   

Thanks. I will try filing a bug on that system as soon as I get the
reply to create my account there.
(...)
 

You see it's very difficult to fix such irq problems because some factors
can cause such an error.
   

Yes, I understand that.
 

Maybe contacting specific malinglists (e.g. for "broken" pci cards
the pci mailinglist, etc.), maintainers or developers would be more
efficient (cc the lkml) and solve your problem (faster), because
this people are specialists are this type of hardware (e.g. pci).
What hardware is connect through irq 5?
   

In my case, my problem is not with irq 5, but with irq 10, as I
mentioned earlier.
The situation is this: I have an Asus A7V motherboard with 2 VIA
vt82c686a controllers and 2 Promise PDC20265 controllers.
I recently bought myself a new DVD recorder and since Alan Cox told
me[*] that the Promise controllers had problems with ATAPI devices, I
decided to arrange my system this way:
/dev/hda: the DVD recorder (VIA controller, master)
/dev/hdc: an old CD recorder (VIA controller, master)
/dev/hde: my first HD (Promise controller, master)
/dev/hdg: my second HD (Promise controller, master)
The Promise controller is able to control the HDs (which now have
exclusive 80-pin cables) at their maximum, but I get the following
stack trace if I have /dev/hdg turned on:
- - - - - - - - - - - - - - - - - - - - - - -  - - - - - - - - - - - -
ACPI: PCI interrupt :00:11.0[A] -> GSI 10 (level, low) -> IRQ 10
PDC20265: chipset revision 2
PDC20265: 100% native mode on irq 10
PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
   ide2: BM-DMA at 0x7400-0x7407, BIOS settings: hde:pio, hdf:pio
   ide3: BM-DMA at 0x7408-0x740f, BIOS settings: hdg:pio, hdh:pio
Probing IDE interface ide2...
hde: QUANTUM FIREBALL CX13.0A, ATA DISK drive
ide2 at 0x8800-0x8807,0x8402 on irq 10
Probing IDE interface ide3...
hdg: QUANTUM FIREBALLlct15 30, ATA DISK drive
irq 10: nobody cared!
[] __report_bad_irq+0x31/0x77
[] note_interrupt+0x4c/0x71
[] __do_IRQ+0x93/0xbd
[] do_IRQ+0x19/0x24
[] common_interrupt+0x1a/0x20
[] __do_softirq+0x2c/0x7d
[] do_softirq+0x22/0x26
[] do_IRQ+0x1e/0x24
[] common_interrupt+0x1a/0x20
[] enable_irq+0x88/0x8d
[] probe_hwif+0x2da/0x366
[] ata_attach+0xa3/0xbd
[] probe_hwif_init_with_fixup+0x10/0x74
[] ide_setup_pci_device+0x72/0x7f
[] pdc202xx_init_one+0x15/0x18
[] ide_scan_pcidev+0x34/0x59
[] ide_scan_pcibus+0x1c/0x88
[] probe_for_hwifs+0xb/0xd
[] ide_init+0x44/0x59
[] do_initcalls+0x4b/0x99
[] init+0x0/0xce
[] init+0x27/0xce
[] kernel_thread_helper+0x5/0xb
handlers:
[] (ide_intr+0x0/0xee)
Disabling IRQ #10
irq 10: nobody cared!
- - - - - - - - - - - - - - - - - - - - - - -  - - - - - - - - - - - -
This is just an excerpt of the messages. I can provide much more
details if I know what is relevant.
I had already posted some old dmesg logs at my site
, but this was before I
got myself a second 80-ribbon cable (I expected that the problem would
go away, but it didn't).
Any other comments are more than welcome.
Thanks in advance, Rogério Brito.
[*] http://infocenter.guardiandigital.com/archive/linux-kernel/2004/Dec/2663.html
 

Hi!
I'm not IDE specialist, but what about operating systems? Did you try a 
Windows or BSD CD (try it with a Windows 2000/XP CD, if you have one, 
else burn a NetBSD or FreeBSD/DragonflyBSD CD -- this is important to 
see if it's a linux bug or acpi bug)? Anyway this is very strange.

Good luck!
Matthias-Christian Ott
-
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/

Panic in 2.6.11-rc4

[Ben Greear]

I see this panic when booting 2.6.11-rc4 (plus some of my own patches...but my 
modules
have not loaded at the point of the crash).
The system is a Shuttle system with the FB65 motherboard.  CPU is 3.0Ghz P4 with
1MB cache and hyperthreading.  HD is an 80GB SATA disk.  NVIDIA card is 
installed
(but I have not installed the NVIDIA drivers).
The system boots the latest FC2 kernel (2.6.10-1-something) fine, and other
FC2 kernels too.  The system hangs trying to discover hardware
when I try to boot a 2.6.9 kernel I compiled...
Also, the system will not save it's BIOS settings.  I'm not sure exactly
what that indicates, other than potentially flaky hardware of some sort...
Any ideas are welcome!
Thanks,
Ben
Linux version 2.6.11-rc4 ([EMAIL PROTECTED]) (gcc version 3.3.3 20040412 
(Red Hat Linux 3.3.3-7)5BIOS-provided physical RAM map:
 BIOS-e820:  - 0009f800 (usable)
 BIOS-e820: 0009f800 - 000a (reserved)
 BIOS-e820: 000f - 0010 (reserved)
 BIOS-e820: 0010 - 1fff (usable)
 BIOS-e820: 1fff - 1fff3000 (ACPI NVS)
 BIOS-e820: 1fff3000 - 2000 (ACPI data)
 BIOS-e820: fec0 - 0001 (reserved)
0MB HIGHMEM available.
511MB LOWMEM available.
found SMP MP-table at 000f52c0
DMI 2.2 present.
ACPI: PM-Timer IO Port: 0x408
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 15:4 APIC version 20
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1 15:4 APIC version 20
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Built 1 zonelists
Kernel command line: ro root=LABEL=/ console=ttyS0,38400 console=tty0
Initializing CPU#0
PID hash table entries: 2048 (order: 11, 32768 bytes)
Detected 3008.737 MHz processor.
Using pmtmr for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 514532k/524224k available (2124k kernel code, 9052k reserved, 838k 
data, 232k init, 0k hi)Checking if this processor honours the WP bit even in 
supervisor mode... Ok.
Security Framework v1.0.0 initialized
SELinux:  Initializing.
SELinux:  Starting in permissive mode
selinux_register_security:  Registering secondary module capability
Capability LSM initialized as secondary
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
monitor/mwait feature present.
using mwait in idle threads.
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 1024K
CPU: Physical Processor ID: 0
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
CPU0: Thermal monitoring enabled
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
CPU0: Intel(R) Pentium(R) 4 CPU 3.00GHz stepping 01
per-CPU timeslice cutoff: 2926.21 usecs.
task migration cache decay timeout: 3 msecs.
Booting processor 1/1 eip 3000
Initializing CPU#1
monitor/mwait feature present.
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 1024K
CPU: Physical Processor ID: 0
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
CPU1: Intel P4/Xeon Extended MCE MSRs (12) available
CPU1: Thermal monitoring enabled
CPU1: Intel(R) Pentium(R) 4 CPU 3.00GHz stepping 01
Total of 2 processors activated (11960.32 BogoMIPS).
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 pin1=2 pin2=-1
checking TSC synchronization across 2 CPUs: passed.
Brought up 2 CPUs
checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
Freeing initrd memory: 293k freed
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfb460, last bus=3
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20050125
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
PCI: Ignoring BAR0-3 of IDE controller :00:1f.2
PCI: Transparent bridge - :00:1e.0
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 9 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs *3 4 5 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 *5 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 7 9 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNK0] (IRQs 3 4 5 7 *9 10 11 12 14 15)
ACPI: PCI 

[PATCH][2.4] Fix timer override on nforce

[Zwane Mwaikambo]

Per our discussion, i've ported the 2.6 nforce skip timer override (and 
early PCI access) code to 2.4. This fixes an issue whereupon nforce 
systems have incorrect override values for irq0. Architectures affected 
are i386 and x86_64

Signed-off-by: Zwane Mwaikambo <[EMAIL PROTECTED]>

# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2005/02/18 07:53:21-07:00 [EMAIL PROTECTED] 
#   ACPI skip_timer_override backport from 2.6 including early PCI bridge 
detection.
# 
# include/asm-x86_64/acpi.h
#   2005/02/18 07:53:18-07:00 [EMAIL PROTECTED] +1 -0
#   ACPI skip_timer_override backport from 2.6 including early PCI bridge 
detection.
# 
# include/asm-i386/pci-direct.h
#   2005/02/18 07:53:18-07:00 [EMAIL PROTECTED] +1 -0
#   ACPI skip_timer_override backport from 2.6 including early PCI bridge 
detection.
# 
# include/asm-i386/acpi.h
#   2005/02/18 07:53:18-07:00 [EMAIL PROTECTED] +2 -0
#   ACPI skip_timer_override backport from 2.6 including early PCI bridge 
detection.
# 
# arch/x86_64/kernel/io_apic.c
#   2005/02/18 07:53:18-07:00 [EMAIL PROTECTED] +7 -3
#   ACPI skip_timer_override backport from 2.6 including early PCI bridge 
detection.
# 
# arch/x86_64/kernel/acpi.c
#   2005/02/18 07:53:18-07:00 [EMAIL PROTECTED] +7 -0
#   ACPI skip_timer_override backport from 2.6 including early PCI bridge 
detection.
# 
# arch/i386/kernel/earlyquirk.c
#   2005/02/18 07:53:18-07:00 [EMAIL PROTECTED] +53 -0
#   ACPI skip_timer_override backport from 2.6 including early PCI bridge 
detection.
# 
# arch/i386/kernel/acpi.c
#   2005/02/18 07:53:18-07:00 [EMAIL PROTECTED] +9 -0
#   ACPI skip_timer_override backport from 2.6 including early PCI bridge 
detection.
# 
# arch/i386/kernel/Makefile
#   2005/02/18 07:53:18-07:00 [EMAIL PROTECTED] +1 -1
#   ACPI skip_timer_override backport from 2.6 including early PCI bridge 
detection.
# 
diff -Nru a/arch/i386/kernel/Makefile b/arch/i386/kernel/Makefile
--- a/arch/i386/kernel/Makefile 2005-02-18 07:53:58 -07:00
+++ b/arch/i386/kernel/Makefile 2005-02-18 07:53:58 -07:00
@@ -40,7 +40,7 @@
 obj-$(CONFIG_ACPI_SLEEP)   += acpi_wakeup.o
 obj-$(CONFIG_SMP)  += smp.o smpboot.o trampoline.o
 obj-$(CONFIG_X86_LOCAL_APIC)   += mpparse.o apic.o nmi.o
-obj-$(CONFIG_X86_IO_APIC)  += io_apic.o
+obj-$(CONFIG_X86_IO_APIC)  += io_apic.o earlyquirk.o
 obj-$(CONFIG_X86_VISWS_APIC)   += visws_apic.o
 obj-$(CONFIG_EDD)  += edd.o
 
diff -Nru a/arch/i386/kernel/acpi.c b/arch/i386/kernel/acpi.c
--- a/arch/i386/kernel/acpi.c   2005-02-18 07:53:58 -07:00
+++ b/arch/i386/kernel/acpi.c   2005-02-18 07:53:58 -07:00
@@ -55,6 +55,7 @@
 
 acpi_interrupt_flags acpi_sci_flags __initdata;
 int acpi_sci_override_gsi __initdata;
+int acpi_skip_timer_override __initdata;
 /* --
   Boot-time Configuration
-- 
*/
@@ -320,6 +321,12 @@
return 0;
}
 
+   if (acpi_skip_timer_override &&
+   intsrc->bus_irq == 0 && intsrc->global_irq == 2) {
+   printk(PREFIX "BIOS IRQ0 pin2 override ignored.\n");
+   return 0;
+   }
+
mp_override_legacy_irq (
intsrc->bus_irq,
intsrc->flags.polarity,
@@ -433,6 +440,8 @@
return result;
}
 
+   check_acpi_pci();
+   
result = acpi_blacklisted();
if (result) {
printk(KERN_NOTICE PREFIX "BIOS listed in blacklist, disabling 
ACPI support\n");
diff -Nru a/arch/i386/kernel/earlyquirk.c b/arch/i386/kernel/earlyquirk.c
--- a/arch/i386/kernel/earlyquirk.c 2005-02-18 07:53:58 -07:00
+++ b/arch/i386/kernel/earlyquirk.c 2005-02-18 07:53:58 -07:00
@@ -0,0 +1,53 @@
+/* 
+ * Do early PCI probing for bug detection when the main PCI subsystem is 
+ * not up yet.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifdef CONFIG_ACPI
+static int __init check_bridge(int vendor, int device) 
+{
+   /* According to Nvidia all timer overrides are bogus. Just ignore
+  them all. */
+   if (vendor == PCI_VENDOR_ID_NVIDIA) { 
+   acpi_skip_timer_override = 1;   
+   }
+   return 0;
+}
+   
+void __init check_acpi_pci(void) 
+{ 
+   int num,slot,func; 
+
+   /* Assume the machine supports type 1. If not it will 
+  always read  and should not have any side effect. */
+
+   /* Poor man's PCI discovery */
+   for (num = 0; num < 32; num++) { 
+   for (slot = 0; slot < 32; slot++) { 
+   for (func = 0; func < 8; func++) { 
+   u32 class;
+   u32 vendor;
+   class = read_pci_config(num,slot,func,
+   PCI_CLASS_REVISION);
+   if (class 

Re: http://kernel.org down

[Randy.Dunlap]

Stephen R. Bordeleau wrote:
I get time-outs when trying to access kernel.org but the ftp works. Is 
this scheduled?
thanks.  should be ok now.
--
~Randy
-
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: agpgart-via: probe fails with error -22

[Kenton Groombridge]

[1.]  PROBLEM: agpgart-via: probe fails with error -22
[2.]  When loading agpgart/agpgart-via the following occurs:
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected VIA KT400/KT400A/KT600 chipset
agpgart: Maximum main memory to use for agp memory: 816M
agpgart: unable to determine aperture size.
agpgart: agp_backend_initialize() failed.
agpgart-via: probe of :00:00.0 failed with error -22
[3.] Keywords: agpgart-via
[4.] Linux version 2.6.10 ([EMAIL PROTECTED]) (gcc version 3.4.1 
(Mandrakelinux 10.1 3.4.1-4mdk)) #1 Fri Feb 18 10:36:35 EST 2005

[5.]
agpgart: unable to determine aperture size.
agpgart: agp_backend_initialize() failed.
agpgart-via: probe of :00:00.0 failed with error -22
[6.] N/A
[7.]
LESSKEY=/etc/.less
LC_PAPER=en_US
LC_ADDRESS=en_US
LC_MONETARY=en_US
HOSTNAME=blossom
SHELL=/bin/bash
TERM=xterm
LC_SOURCED=1
HISTSIZE=1000
TMPDIR=/root/tmp
LC_NUMERIC=en_US
QTDIR=/usr/lib/qt3/
USER=root
LS_COLORS=no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:ex=01;32:*.cmd=01;32:*.exe=01;32:*.com=01;32:*.btm=01;32:*.bat=01;32:*.sh=01;32:*.csh=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.gz=01;31:*.bz2=01;31:*.bz=01;31:*.tz=01;31:*.rpm=01;31:*.cpio=01;31:*.jpg=01;35:*.gif=01;35:*.bmp=01;35:*.xbm=01;35:*.xpm=01;35:*.png=01;35:*.tif=01;35:
LC_TELEPHONE=en_US
ENV=/root/.bashrc
USERNAME=root
NLSPATH=/usr/share/locale/%l/%N
MAIL=/var/spool/mail/root
PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin
LC_MESSAGES=en_US
SECURE_LEVEL=2
LC_IDENTIFICATION=en_US
LC_COLLATE=en_US
INPUTRC=/etc/inputrc
PWD=/root
LANG=en_US
PYTHONSTARTUP=/etc/pythonrc.py
LC_MEASUREMENT=en_US
[EMAIL PROTECTED] \W]\$
HISTCONTROL=ignoredups
SHLVL=1
HOME=/root
LANGUAGE=en_US:en
GCONF_TMPDIR=/tmp
TMP=/root/tmp
LESS=-MM
LOGNAME=root
LC_CTYPE=en_US
LESSOPEN=|/usr/bin/lesspipe.sh %s
DISPLAY=:0.0
LC_TIME=en_US
G_BROKEN_FILENAMES=1
LC_NAME=en_US
XAUTHORITY=/root/.xauthqHycKh
_=/bin/env
[7.1.]
Linux blossom 2.6.10 #1 Fri Feb 18 10:36:35 EST 2005 i686 AMD Athlon(tm) 
XP 2900+ unknown GNU/Linux

Gnu C  3.4.1
Gnu make   3.80
binutils   2.15.90.0.3
util-linux 2.12a
mount  2.12a
module-init-tools  3.0
e2fsprogs  1.35
reiserfsprogs  line
reiser4progs   line
nfs-utils  1.0.6
Linux C Library2.3.3
Dynamic linker (ldd)   2.3.3
Procps 3.2.3
Net-tools  1.60
Console-tools  0.2.3
Sh-utils   5.2.1
Modules Loaded snd_seq_oss snd_seq_midi_event snd_seq 
snd_pcm_oss snd_mixer_oss snd_emu10k1 snd_rawmidi snd_seq_device 
snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd_util_mem snd_hwdep 
snd soundcore loop nls_iso8859_1 ntfs nvidia ehci_hcd uhci_hcd button rtc

[7.2.]
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 6
model   : 10
model name  : AMD Athlon(tm) XP 2900+
stepping: 0
cpu MHz : 1999.874
cache size  : 512 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca cmov pat pse36 mmx fxsr sse pni syscall mmxext 3dnowext 3dnow
bogomips: 3940.35

[7.3.]
snd_seq_oss 32320 0 - Live 0xf898b000
snd_seq_midi_event 6336 1 snd_seq_oss, Live 0xf892
snd_seq 50064 4 snd_seq_oss,snd_seq_midi_event, Live 0xf8a41000
snd_pcm_oss 50532 0 - Live 0xf8a33000
snd_mixer_oss 17920 1 snd_pcm_oss, Live 0xf8947000
snd_emu10k1 93764 1 - Live 0xf8996000
snd_rawmidi 20704 1 snd_emu10k1, Live 0xf894
snd_seq_device 6796 4 snd_seq_oss,snd_seq,snd_emu10k1,snd_rawmidi, Live 
0xf891d000
snd_ac97_codec 72352 1 snd_emu10k1, Live 0xf8967000
snd_pcm 84232 3 snd_pcm_oss,snd_emu10k1,snd_ac97_codec, Live 0xf8951000
snd_timer 22084 2 snd_seq,snd_pcm, Live 0xf8931000
snd_page_alloc 7428 2 snd_emu10k1,snd_pcm, Live 0xf8818000
snd_util_mem 3264 1 snd_emu10k1, Live 0xf881b000
snd_hwdep 7364 1 snd_emu10k1, Live 0xf8916000
snd 44772 13 
snd_seq_oss,snd_seq,snd_pcm_oss,snd_mixer_oss,snd_emu10k1,snd_rawmidi,snd_seq_device,snd_ac97_codec,snd_pcm,snd_timer,snd_hwdep, 
Live 0xf8925000
soundcore 7456 1 snd, Live 0xf880e000
loop 12936 0 - Live 0xf8911000
nls_iso8859_1 3776 1 - Live 0xf8816000
ntfs 178192 1 - Live 0xf88e4000
nvidia 3462844 12 - Live 0xf8c69000
ehci_hcd 27076 0 - Live 0xf8827000
uhci_hcd 29520 0 - Live 0xf881e000
button 4816 0 - Live 0xf8811000
rtc 10488 0 - Live 0xf8804000

[7.4.]
-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-006f : keyboard
0070-0077 : rtc
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0376-0376 : ide1
03c0-03df : vga+
03f6-03f6 : ide0
0cf8-0cff : PCI conf1
4000-4003 : PM1a_EVT_BLK
4004-4005 : 

http://kernel.org down

[Stephen R. Bordeleau]

I get time-outs when trying to access kernel.org but the ftp works. Is 
this scheduled?


smime.p7s
Description: S/MIME Cryptographic Signature

Re: 2.6.11rc4: irq 5, nobody cared

[Rogério Brito]

On Feb 20 2005, Matthias-Christian Ott wrote:
> Rogério Brito wrote:
> >I am willing to test any patch and configuration (let's call me a
> >"guinea pig"), but I don't know what I should do. I have, OTOH,
> >reported my problem many times in the past few days. :-(
> >
> >I will retry sending my message to the list once again, with the
> >details (in my case, the message I get is "irq 10: nobody cared!"
> >and it is regarding my primary HD on my secondary Promise PDC20265
> >controller).

First of all, Matthias-Christian, thank you very much for your kind
answer.

I have already tried contacting the linux-ide mailing list as a CC to my
earlier messages, but I got no response. I am including some details in
this e-mail. I included Bartlomiej in the CC, as he is listed as general
IDE maintainer in the MAINTAINERS file.

> Report it to http://bugzilla.kernel.org/. Maybe you'll get help there.

Thanks. I will try filing a bug on that system as soon as I get the
reply to create my account there.

(...)
> You see it's very difficult to fix such irq problems because some factors
> can cause such an error.

Yes, I understand that.

> Maybe contacting specific malinglists (e.g. for "broken" pci cards
> the pci mailinglist, etc.), maintainers or developers would be more
> efficient (cc the lkml) and solve your problem (faster), because
> this people are specialists are this type of hardware (e.g. pci).
> 
> What hardware is connect through irq 5?

In my case, my problem is not with irq 5, but with irq 10, as I
mentioned earlier.

The situation is this: I have an Asus A7V motherboard with 2 VIA
vt82c686a controllers and 2 Promise PDC20265 controllers.

I recently bought myself a new DVD recorder and since Alan Cox told
me[*] that the Promise controllers had problems with ATAPI devices, I
decided to arrange my system this way:

/dev/hda: the DVD recorder (VIA controller, master)
/dev/hdc: an old CD recorder (VIA controller, master)
/dev/hde: my first HD (Promise controller, master)
/dev/hdg: my second HD (Promise controller, master)

The Promise controller is able to control the HDs (which now have
exclusive 80-pin cables) at their maximum, but I get the following
stack trace if I have /dev/hdg turned on:

- - - - - - - - - - - - - - - - - - - - - - -  - - - - - - - - - - - -
ACPI: PCI interrupt :00:11.0[A] -> GSI 10 (level, low) -> IRQ 10
PDC20265: chipset revision 2
PDC20265: 100% native mode on irq 10
PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
ide2: BM-DMA at 0x7400-0x7407, BIOS settings: hde:pio, hdf:pio
ide3: BM-DMA at 0x7408-0x740f, BIOS settings: hdg:pio, hdh:pio
Probing IDE interface ide2...
hde: QUANTUM FIREBALL CX13.0A, ATA DISK drive
ide2 at 0x8800-0x8807,0x8402 on irq 10
Probing IDE interface ide3...
hdg: QUANTUM FIREBALLlct15 30, ATA DISK drive
irq 10: nobody cared!
 [] __report_bad_irq+0x31/0x77
 [] note_interrupt+0x4c/0x71
 [] __do_IRQ+0x93/0xbd
 [] do_IRQ+0x19/0x24
 [] common_interrupt+0x1a/0x20
 [] __do_softirq+0x2c/0x7d
 [] do_softirq+0x22/0x26
 [] do_IRQ+0x1e/0x24
 [] common_interrupt+0x1a/0x20
 [] enable_irq+0x88/0x8d
 [] probe_hwif+0x2da/0x366
 [] ata_attach+0xa3/0xbd
 [] probe_hwif_init_with_fixup+0x10/0x74
 [] ide_setup_pci_device+0x72/0x7f
 [] pdc202xx_init_one+0x15/0x18
 [] ide_scan_pcidev+0x34/0x59
 [] ide_scan_pcibus+0x1c/0x88
 [] probe_for_hwifs+0xb/0xd
 [] ide_init+0x44/0x59
 [] do_initcalls+0x4b/0x99
 [] init+0x0/0xce
 [] init+0x27/0xce
 [] kernel_thread_helper+0x5/0xb
handlers:
[] (ide_intr+0x0/0xee)
Disabling IRQ #10
irq 10: nobody cared!
- - - - - - - - - - - - - - - - - - - - - - -  - - - - - - - - - - - -

This is just an excerpt of the messages. I can provide much more
details if I know what is relevant.

I had already posted some old dmesg logs at my site
, but this was before I
got myself a second 80-ribbon cable (I expected that the problem would
go away, but it didn't).

Any other comments are more than welcome.


Thanks in advance, Rogério Brito.

[*] 
http://infocenter.guardiandigital.com/archive/linux-kernel/2004/Dec/2663.html
-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: IBM Thinkpad G41 PCMCIA problems [Was: Yenta TI: ... no PCI interrupts. Fish. Please report.]

[Linus Torvalds]

On Sun, 20 Feb 2005, Linus Torvalds wrote:
> 
> But the PCI allocations are not at all limited by MAXMEM - they want to be 
> in the low 4GB, but that's the only real limit. So using "max_low_pfn" to 
> determine where to start PCI allocations is pretty bogus.
> 
> I'll try to write something that actually looks at the e820 memory map 
> properly.

Russell, what do your eagle-eyes think of a patch like this?

Steven, does this fix it without the need for any kernel command line (or
any other patches, for that matter - ie revert all the transparency-
changing ones)?

Linus


# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2005/02/20 09:43:19-08:00 [EMAIL PROTECTED] 
#   Use e820 memory map to determine PCI allocation area.
#   
#   Don't use the VM numbers (max_low_pfn and friends), since they depend
#   on the partial kernel linear mapping and only partially on the actual
#   physical memory layout.
# 
# arch/i386/kernel/setup.c
#   2005/02/20 09:43:12-08:00 [EMAIL PROTECTED] +19 -6
#   Use e820 memory map to determine PCI allocation area.
#   
#   Don't use the VM numbers (max_low_pfn and friends), since they depend
#   on the partial kernel linear mapping and only partially on the actual
#   physical memory layout.
# 
diff -Nru a/arch/i386/kernel/setup.c b/arch/i386/kernel/setup.c
--- a/arch/i386/kernel/setup.c  2005-02-20 09:54:35 -08:00
+++ b/arch/i386/kernel/setup.c  2005-02-20 09:54:35 -08:00
@@ -1166,9 +1166,10 @@
 /*
  * Request address space for all standard resources
  */
-static void __init register_memory(unsigned long max_low_pfn)
+static void __init register_memory(void)
 {
-   unsigned long low_mem_size;
+   long long gapsize;
+   unsigned long long last;
int   i;
 
if (efi_enabled)
@@ -1184,9 +1185,21 @@
request_resource(_resource, _io_resources[i]);
 
/* Tell the PCI layer not to allocate too close to the RAM area.. */
-   low_mem_size = ((max_low_pfn << PAGE_SHIFT) + 0xf) & ~0xf;
-   if (low_mem_size > pci_mem_start)
-   pci_mem_start = low_mem_size;
+   last = 0x1ull;
+   gapsize = 0x40;
+   i = e820.nr_map;
+   while (--i >= 0) {
+   unsigned long long start = e820.map[i].addr;
+   unsigned long long end = start + e820.map[i].size;
+   long long gap = last - end;
+
+   if (gap > gapsize) {
+   gapsize = gap;
+   pci_mem_start = ((unsigned long) end + 0xf) & 
~0xf;
+   }
+   last = start;
+   }
+   printk("Allocating PCI resources starting at %08lx\n", pci_mem_start);
 }
 
 /* Use inline assembly to define this because the nops are defined 
@@ -1432,7 +1445,7 @@
get_smp_config();
 #endif
 
-   register_memory(max_low_pfn);
+   register_memory();
 
 #ifdef CONFIG_VT
 #if defined(CONFIG_VGA_CONSOLE)
-
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/

USB Storage problem (usb hangs)

[me]

Hi.

The device is: USB2.0 to IDE 3.5" hard disk enclosure.
Producer: Seven.

Part of /var/log/messages with USB debug enabled in kernel is
attached to this email.

Kernel: 2.6.9, 2.6.10 (i cant remember from which one is attached log).
Distribution: Gentoo.

I'm not subscribed to the list, pleas CC me.

-- 
Regards
Sebastian Fabrycki
[EMAIL PROTECTED]

--
Sprawdz NOWE parametry hostingu!
>> http://link.interia.pl/f1857 << 
Jan 10 23:34:30 globtel usb-storage: USB Mass Storage device detected
Jan 10 23:34:30 globtel usb-storage: -- associate_dev
Jan 10 23:34:30 globtel usb-storage: Vendor: 0x05e3, Product: 0x0702, Revision: 
0x0002
Jan 10 23:34:30 globtel usb-storage: Interface Subclass: 0x06, Protocol: 0x50
Jan 10 23:34:30 globtel usb-storage: Vendor: Genesys Logic,  Product: USB TO IDE
Jan 10 23:34:30 globtel usb-storage: Transport: Bulk
Jan 10 23:34:30 globtel usb-storage: Protocol: Transparent SCSI
Jan 10 23:34:30 globtel usb-storage: usb_stor_control_msg: rq=fe rqtype=a1 
value= index=00 len=1
Jan 10 23:34:30 globtel usb-storage: GetMaxLUN command result is 1, data is 0
Jan 10 23:34:30 globtel usb-storage: *** thread sleeping.
Jan 10 23:34:30 globtel scsi0 : SCSI emulation for USB Mass Storage devices
Jan 10 23:34:30 globtel usb-storage: queuecommand called
Jan 10 23:34:30 globtel usb-storage: *** thread awakened.
Jan 10 23:34:30 globtel usb-storage: Faking INQUIRY command
Jan 10 23:34:30 globtel usb-storage: scsi cmd done, result=0x0
Jan 10 23:34:30 globtel usb-storage: *** thread sleeping.
Jan 10 23:34:30 globtel Vendor: Genesys   Model: USB to IDE Disk   Rev: 0002
Jan 10 23:34:30 globtel Type:   Direct-Access  ANSI SCSI 
revision: 02
Jan 10 23:34:30 globtel usb-storage: queuecommand called
Jan 10 23:34:30 globtel usb-storage: *** thread awakened.
Jan 10 23:34:30 globtel usb-storage: Command TEST_UNIT_READY (6 bytes)
Jan 10 23:34:30 globtel usb-storage:  00 00 00 00 00 00
Jan 10 23:34:30 globtel usb-storage: Bulk Command S 0x43425355 T 0x2 L 0 F 0 
Trg 0 LUN 0 CL 6
Jan 10 23:34:30 globtel usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
Jan 10 23:34:30 globtel usb-storage: Status code 0; transferred 31/31
Jan 10 23:34:30 globtel usb-storage: -- transfer complete
Jan 10 23:34:30 globtel usb-storage: Bulk command transfer result=0
Jan 10 23:34:30 globtel usb-storage: Attempting to get CSW...
Jan 10 23:34:30 globtel usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
Jan 10 23:34:40 globtel scsi.agent[7459]: Attribute 
/sys/devices/pci:00/:00:1d.7/usb1/1-4/1-4:1.0/host0/0:0:0:0/type does 
not exist
Jan 10 23:35:00 globtel usb-storage: command_abort called
Jan 10 23:35:00 globtel usb-storage: usb_stor_stop_transport called
Jan 10 23:35:00 globtel usb-storage: -- cancelling URB
Jan 10 23:35:00 globtel usb-storage: Status code -104; transferred 0/13
Jan 10 23:35:00 globtel usb-storage: -- transfer cancelled
Jan 10 23:35:00 globtel usb-storage: Bulk status result = 4
Jan 10 23:35:00 globtel usb-storage: -- command was aborted
Jan 10 23:35:00 globtel usb-storage: usb_stor_Bulk_reset called
Jan 10 23:35:00 globtel usb-storage: usb_stor_control_msg: rq=ff rqtype=21 
value= index=00 len=0
Jan 10 23:35:20 globtel usb-storage: Timeout -- cancelling URB
Jan 10 23:35:20 globtel usb-storage: Soft reset failed: -104
Jan 10 23:35:20 globtel usb-storage: scsi command aborted
Jan 10 23:35:20 globtel usb-storage: *** thread sleeping.
Jan 10 23:35:20 globtel usb-storage: queuecommand called
Jan 10 23:35:20 globtel usb-storage: *** thread awakened.
Jan 10 23:35:20 globtel usb-storage: Command TEST_UNIT_READY (6 bytes)
Jan 10 23:35:20 globtel usb-storage:  00 00 00 00 00 00
Jan 10 23:35:20 globtel usb-storage: Bulk Command S 0x43425355 T 0x2 L 0 F 0 
Trg 0 LUN 0 CL 6
Jan 10 23:35:20 globtel usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
Jan 10 23:35:20 globtel usb-storage: Status code 0; transferred 31/31
Jan 10 23:35:20 globtel usb-storage: -- transfer complete
Jan 10 23:35:20 globtel usb-storage: Bulk command transfer result=0
Jan 10 23:35:20 globtel usb-storage: Attempting to get CSW...
Jan 10 23:35:20 globtel usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
Jan 10 23:35:30 globtel usb-storage: command_abort called
Jan 10 23:35:30 globtel usb-storage: usb_stor_stop_transport called
Jan 10 23:35:30 globtel usb-storage: -- cancelling URB
Jan 10 23:35:30 globtel usb-storage: Status code -104; transferred 0/13
Jan 10 23:35:30 globtel usb-storage: -- transfer cancelled
Jan 10 23:35:30 globtel usb-storage: Bulk status result = 4
Jan 10 23:35:30 globtel usb-storage: -- command was aborted
Jan 10 23:35:30 globtel usb-storage: usb_stor_Bulk_reset called
Jan 10 23:35:30 globtel usb-storage: usb_stor_control_msg: rq=ff rqtype=21 
value= index=00 len=0
Jan 10 23:35:50 globtel usb-storage: Timeout -- cancelling URB
Jan 10 23:35:50 globtel usb-storage: Soft reset failed: -104
Jan 10 23:35:50 globtel 

Re: IBM Thinkpad G41 PCMCIA problems [Was: Yenta TI: ... no PCI interrupts. Fish. Please report.]

[Linus Torvalds]

On Sun, 20 Feb 2005, Russell King wrote:
> On Sat, Feb 19, 2005 at 08:36:12PM -0500, Steven Rostedt wrote:
> >  BIOS-e820:  - 0009f000 (usable)
> >  BIOS-e820: 0009f000 - 000a (reserved)
> >  BIOS-e820: 000d - 000d4000 (reserved)
> >  BIOS-e820: 000dc000 - 0010 (reserved)
> >  BIOS-e820: 0010 - 0f6f (usable)
> >  BIOS-e820: 0f6f - 0f70 (reserved)
> >  BIOS-e820: 0f70 - 3fef (usable)
> >  BIOS-e820: 3fef - 3fef8000 (ACPI data)
> >  BIOS-e820: 3fef8000 - 3fefa000 (ACPI NVS)
> >  BIOS-e820: 3ff0 - 4000 (reserved)
> 
> Your BIOS is broken.  You probably have 1GB of RAM which extends from
> 0x to 0x4000.  However, there's a hole in the ACPI map
> between 0x3fefa000 and 0x3ff0.

Good point. And dammit, we've had that problem too many times before.

And I think the reason for that bug is that we use "max_low_pfn" to 
determine where we should start allocating PCI memory. We actually round 
it up to the next megabyte, which _should_ have made us not allocate in 
that small region (the last usable page is 0x3fef, rounded up to the 
nearest megabyte is 0x3ff0, which is marked as "reserved", so we 
_should_ have allocated above that quite nicely).

However, we are screwed by the fact that "max_low_pfn" is actually limited
by MAXMEM_PFN, which is the kernel _mappable_ memory, so MAXMEM is
actually much less than one megabyte (it's one megabyte minus
"VMALLOC_RESERVE", which defaults to 128MB).

But the PCI allocations are not at all limited by MAXMEM - they want to be 
in the low 4GB, but that's the only real limit. So using "max_low_pfn" to 
determine where to start PCI allocations is pretty bogus.

I'll try to write something that actually looks at the e820 memory map 
properly.

Linus
-
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.6.11rc4: irq 5, nobody cared

[Matthias-Christian Ott]

Rogério Brito wrote:
On Feb 20 2005, Folkert van Heusden wrote:
 

My linux laptop says:
irq 5: nobody cared!
   

(...)
 

Does anyone care? :-)
   

Well, I'm getting similar stack traces with my system and those are sure
scary, but it seems that my e-mails to the list are simply ignored,
unfortunately.
I am willing to test any patch and configuration (let's call me a "guinea
pig"), but I don't know what I should do. I have, OTOH, reported my problem
many times in the past few days. :-(
I will retry sending my message to the list once again, with the details
(in my case, the message I get is "irq 10: nobody cared!" and it is
regarding my primary HD on my secondary Promise PDC20265 controller).
Thanks for any help, Rogério.
P.S.: I have already bought an 80-pin cable just for this drive in the hope
that the message would go away, but it didn't.
 

Report it to http://bugzilla.kernel.org/. Maybe you'll get help there. 
But "bugs" are _very_ hardware specific, so just a few people will have 
a similar problem and most of this people are just "normal" users -- not 
Linux Kernel developers. The developer (people who are familiar with the 
kernel code and who are maybe able to fix this problem) aren't able to 
reproduce this error and test code to get it working. So they're maybe 
(without knowing anything about the hardware (maybe it's broken 
hardware?)) not able to say something specific about the hardware -- 
they can just guess.
You see it's very difficult to fix such irq problems because some 
factors can cause such an error.
Maybe contacting specific malinglists (e.g. for "broken" pci cards the 
pci mailinglist, etc.), maintainers or developers would be more 
efficient (cc the lkml) and solve your problem (faster), because this 
people are specialists are this type of hardware (e.g. pci).

What hardware is connect through irq 5?
Matthias-Christian Ott
-
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.6.11rc4: irq 5, nobody cared

[Arjan van de Ven]

> [] (ndis_irq_th+0x0/0xf0 [ndiswrapper])
> Disabling IRQ #5
> 
> Does anyone care? :-)

doubt 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: 2.6.11rc4: irq 5, nobody cared

[Rogério Brito]

On Feb 20 2005, Folkert van Heusden wrote:
> My linux laptop says:
> irq 5: nobody cared!
(...)
> Does anyone care? :-)

Well, I'm getting similar stack traces with my system and those are sure
scary, but it seems that my e-mails to the list are simply ignored,
unfortunately.

I am willing to test any patch and configuration (let's call me a "guinea
pig"), but I don't know what I should do. I have, OTOH, reported my problem
many times in the past few days. :-(

I will retry sending my message to the list once again, with the details
(in my case, the message I get is "irq 10: nobody cared!" and it is
regarding my primary HD on my secondary Promise PDC20265 controller).


Thanks for any help, Rogério.

P.S.: I have already bought an 80-pin cable just for this drive in the hope
that the message would go away, but it didn't.
-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-
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.6.11rc4: irq 5, nobody cared

[Folkert van Heusden]

Hi,

My linux laptop says:
irq 5: nobody cared!
 [] __report_bad_irq+0x24/0x90
 [] note_interrupt+0x61/0x90
 [] __do_IRQ+0x13b/0x150
 [] do_IRQ+0x23/0x40
 [] common_interrupt+0x1a/0x20
 [] __do_softirq+0x2e/0x80
 [] do_softirq+0x27/0x30
 [] irq_exit+0x35/0x40
 [] do_IRQ+0x28/0x40
 [] common_interrupt+0x1a/0x20
 [] del_timer+0x0/0xb0
 [] schedule_timeout+0x69/0xc0
 [] __get_free_pages+0x1f/0x40
 [] process_timeout+0x0/0x10
 [] do_select+0x195/0x2f0
 [] __pollwait+0x0/0xc0
 [] autoremove_wake_function+0x0/0x50
 [] sys_select+0x2be/0x4b0
 [] sys_gettimeofday+0x2c/0x70
 [] syscall_call+0x7/0xb
handlers:
[] (usb_hcd_irq+0x0/0x60 [usbcore])
[] (ndis_irq_th+0x0/0xf0 [ndiswrapper])
Disabling IRQ #5

Does anyone care? :-)


Folkert van Heusden

Op zoek naar een IT of Finance baan? Mail me voor de mogelijkheden!
+--+
|UNIX admin? Then give MultiTail (http://vanheusden.com/multitail/)|
|a try, it brings monitoring logfiles to a different level! See|
|http://vanheusden.com/multitail/features.html for a feature list. |
+--= www.unixsoftware.nl =-+
Phone: +31-6-41278122, PGP-key: 1F28D8AE
-
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: Needed faster implementation of do_gettimeofday()

[Parag Warudkar]

On Sunday 20 February 2005 05:58 am, [EMAIL PROTECTED] wrote:
> 985913    8.6083  vmlinux                  mark_offset_tsc
> 584473    5.1032  libc-2.3.2.so            getc

What makes you think mark_offset_tsc is slow? Do you have any comparative 
numbers?  It might just be that the workload you are throwing at it justifies 
it. (For e.g. if your workload does a zillion system calls, system_call will 
show up as a hot spot in oprofile - doesn't necessarily mean it is slow - 
it's just overused.) Can you post the relevant code?

Parag
-
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] i2c.h: Fix another gcc 4.0 compile failure

[Mickey Stein]

Greg KH wrote:
On Sat, Feb 19, 2005 at 08:58:48AM -0800, Mickey Stein wrote:
 

From: Mickey Stein
Versions:   linux-2.6.11-rc4-bk7, gcc4 (GCC) 4.0.0 20050217 (latest fc 
rawhide from 19Feb DL)

gcc4 cvs seems to dislike "include/linux/i2c.h file":
Error msg:   include/linux/i2c.h:{55,194} error: array type has 
incomplete element type

A. Daplas has recently done a workaround for this on another header 
file. A thread discussing this
can be found by following the link below:

http://gcc.gnu.org/ml/gcc/2005-02/msg00053.html
The patch changes the array declaration from "struct x y[]" format to 
"struct x *y".
I realize its only a workaround, but the gcc guys seem to be aware of 
this.
** Note: I'm a noob at this, so feel free to make chopped liver out of 
this if its incorrect.
patch below is also attached since I'm not sure formatting survives 
the cut
   

The patch looks sane, but before I apply it, care to also fix up all of
the function pointers that are affected by this patch?  Also the
i2c_transfer() function itself should be changed (not just the header
file.)
thanks,
greg k-h
 

Greg,
I took a look for other references similar to those in my first take at 
this and found a couple more files.
Attached is another patch that hopefully addresses the all the similar 
cases.  I tried it on today's (-bk8) kernel,
with all i2c switches enabled.

From: Mickey Stein
Versions:   linux-2.6.11-rc4-bk8, gcc4 (GCC) 4.0.0 20050217 (latest fc 
rawhide from 19Feb DL)

gcc4 cvs seems to dislike "include/linux/i2c.h, i2c-core.c files".
I also tweaked the Documentation/i2c/writing-clients file.
Error msg:   include/linux/i2c.h:{55,194} error: array type has 
incomplete element type

A. Daplas has recently done a workaround for this on another header 
file. A thread discussing this
can be found by following the link below:

http://gcc.gnu.org/ml/gcc/2005-02/msg00053.html
The patch changes the i2c-transfer code in i2c.h  from "struct x y[]" 
format to "struct x *y".
It also changes the associated i2c-transfer declarations in i2c-core.c.
It tweaks the Documentation/i2c/writing-clients file to reconcile 
i2c-transfer docs.

I realize its only a workaround, but the gcc guys seem to be aware of 
this.

Thanks very much,
Mickey Stein
Signed-off-by: Mickey Stein <[EMAIL PROTECTED]>

--- ./include/linux/i2c.h.sav   2005-02-20 07:03:41.0 -0800
+++ ./include/linux/i2c.h   2005-02-20 07:14:26.0 -0800
@@ -55,7 +55,7 @@
 
 /* Transfer num messages.
  */
-extern int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg msg[],int 
num);
+extern int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msg,int num);
 
 /*
  * Some adapter types (i.e. PCF 8584 based ones) may support slave behaviuor. 
@@ -194,7 +194,7 @@
   to NULL. If an adapter algorithm can do SMBus access, set 
   smbus_xfer. If set to NULL, the SMBus protocol is simulated
   using common I2C messages */
-   int (*master_xfer)(struct i2c_adapter *adap,struct i2c_msg msgs[], 
+   int (*master_xfer)(struct i2c_adapter *adap,struct i2c_msg *msgs, 
   int num);
int (*smbus_xfer) (struct i2c_adapter *adap, u16 addr, 
   unsigned short flags, char read_write,
--- ./drivers/i2c/i2c-core.c.sav2005-02-20 07:03:53.0 -0800
+++ ./drivers/i2c/i2c-core.c2005-02-20 07:11:46.0 -0800
@@ -583,7 +583,7 @@
  * 
  */
 
-int i2c_transfer(struct i2c_adapter * adap, struct i2c_msg msgs[],int num)
+int i2c_transfer(struct i2c_adapter * adap, struct i2c_msg *msgs,int num)
 {
int ret;
 
--- ./Documentation/i2c/writing-clients.sav 2005-02-20 07:05:12.0 
-0800
+++ ./Documentation/i2c/writing-clients 2005-02-20 07:08:29.0 -0800
@@ -642,7 +642,7 @@
 parameter contains the bytes the read/write, the third the length of the
 buffer. Returned is the actual number of bytes read/written.
   
-  extern int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg msg[],
+  extern int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msg,
   int num);
 
 This sends a series of messages. Each message can be a read or write,

GL520SM Sensor Chip driver fix

[Adam 'dredzik' Kuczynski]

Hi,
I've been recently trying to get my lmsensors working under
2.6.9, and i've found this:

http://seclists.org/lists/linux-kernel/2005/Feb/2856.html
http://lkml.org/lkml/2005/2/11/90

kernel patch for gl520 chip, but after applying it kernel refused to
compile. So I've fixed it using gl518sm module source code and I want to
share the results of my work with you. I hope that it will be useful.

I've tested this on my machine and it works fine.

Bye

PS: I hope i'm writting to good list.

-- 
  .$   .,_   .$   [ Adam 'dredzik' Kuczynski ]
 gP""Y:$ g. ,gP ,P" _,P gP""Y:$   [ http://dredzik.ekg2.org/ ]
 Y.  ,Y: `$,P   Y$  Y.  ,Y:   [ mailto: [EMAIL PROTECTED] ]
  `""  `b.`Y'`"--`""  `b. [ JID:  [EMAIL PROTECTED] ]
--- linux-2.6.9/drivers/i2c/chips/gl520sm.c.orig2005-02-20 
15:20:38.0 +0100
+++ linux-2.6.9/drivers/i2c/chips/gl520sm.c 2005-02-20 15:41:25.0 
+0100
@@ -37,6 +37,9 @@
 static unsigned short normal_i2c[] = { 0x2c, 0x2d, I2C_CLIENT_END };
 static unsigned int normal_isa[] = { I2C_CLIENT_ISA_END };
 
+static unsigned short normal_i2c_range[] = { I2C_CLIENT_END };
+static unsigned int normal_isa_range[] = { I2C_CLIENT_ISA_END };
+
 /* Insmod parameters */
 SENSORS_INSMOD_1(gl520sm);
 
@@ -500,13 +503,25 @@
 
 static int gl520_attach_adapter(struct i2c_adapter *adapter)
 {
- if (!(adapter->clRD_DATA))
- goto exit;
+ if (!(adapter->class & I2C_CLASS_HWMON))
+ return 0;
+ return i2c_detect(adapter, _data, gl520_detect);
+}
 
+static int gl520_detect(struct i2c_adapter *adapter, int address, int kind)
+{
+ struct i2c_client *new_client;
+ struct gl520_data *data;
+ int err = 0;
+ 
+ if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA |
+ I2C_FUNC_SMBUS_WORD_DATA))
+ goto exit;
+
  /* OK. For now, we presume we have a valid client. We now create the
  client structure, even though we cannot fill it completely yet.
  But it allows us to access gl520_{read,write}_value. */
-
+ 
  if (!(data = kmalloc(sizeof(struct gl520_data), GFP_KERNEL))) {
  err = -ENOMEM;
  goto exit;


signature.asc
Description: Digital signature

[PATCH][2.6.11-rc3-mm2] perfctr-2.7.10 API update 4/4: ppc32

[Mikael Pettersson]

perfctr-2.7.10 update, 4/4:
- Update ppc32 syscall table for perfctr-2.7.10 API changes.

Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]>

 arch/ppc/kernel/misc.S   |5 ++---
 include/asm-ppc/unistd.h |7 +++
 2 files changed, 5 insertions(+), 7 deletions(-)

diff -rupN linux-2.6.11-rc3-mm2/arch/ppc/kernel/misc.S 
linux-2.6.11-rc3-mm2.perfctr-2.7.10-ppc32-syscalls-update/arch/ppc/kernel/misc.S
--- linux-2.6.11-rc3-mm2/arch/ppc/kernel/misc.S 2005-02-20 12:39:29.0 
+0100
+++ 
linux-2.6.11-rc3-mm2.perfctr-2.7.10-ppc32-syscalls-update/arch/ppc/kernel/misc.S
2005-02-20 13:10:06.0 +0100
@@ -1452,6 +1452,5 @@ _GLOBAL(sys_call_table)
.long sys_keyctl
.long sys_vperfctr_open
.long sys_vperfctr_control
-   .long sys_vperfctr_unlink
-   .long sys_vperfctr_iresume  /* 275 */
-   .long sys_vperfctr_read
+   .long sys_vperfctr_write
+   .long sys_vperfctr_read /* 275 */
diff -rupN linux-2.6.11-rc3-mm2/include/asm-ppc/unistd.h 
linux-2.6.11-rc3-mm2.perfctr-2.7.10-ppc32-syscalls-update/include/asm-ppc/unistd.h
--- linux-2.6.11-rc3-mm2/include/asm-ppc/unistd.h   2005-02-20 
12:39:30.0 +0100
+++ 
linux-2.6.11-rc3-mm2.perfctr-2.7.10-ppc32-syscalls-update/include/asm-ppc/unistd.h
  2005-02-20 13:10:06.0 +0100
@@ -278,11 +278,10 @@
 #define __NR_keyctl271
 #define __NR_vperfctr_open 272
 #define __NR_vperfctr_control  (__NR_vperfctr_open+1)
-#define __NR_vperfctr_unlink   (__NR_vperfctr_open+2)
-#define __NR_vperfctr_iresume  (__NR_vperfctr_open+3)
-#define __NR_vperfctr_read (__NR_vperfctr_open+4)
+#define __NR_vperfctr_write(__NR_vperfctr_open+2)
+#define __NR_vperfctr_read (__NR_vperfctr_open+3)
 
-#define __NR_syscalls  277
+#define __NR_syscalls  276
 
 #define __NR(n)#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/

Frequent Oops on Shutdown 2.6.10

[AndyLiebman]

Hi, 
I compiled the 2.6.10 kernel with HyperThreading optimization (I'm  running a 
3.06 Ghz single Xeon processor with HT enabled). More or less, I'm  running 
Mandrake 10 Official, but with my own kernel. Can anybody help explain  why I'm 
getting this Oops on shutdown? It doesn't happen all the time -- about  50 
percent of the time. Never happens with the 2.6.6 kernel. I configured the  
2.6.10 kernel with mostly the same settings -- saying "no" to everything new,  
except optimizing for P4/Xeon processor, enabling HT optimization, and NOT  
enabling lots of "ham radio" and "ISDN" stuff that seemed to be enabled in the  
Mandrake kernel. 
 
Some relevant things about the machine: 
Single Xeon 3.06 processor
2 GB ECC RAM
2x 3ware 9500S-8 SATA RAID Cards
16 SATA drives
2 built-in GigE ports on motherboard
2 Intel 1000 MT Server Adapters on each of the two 133 Mhz  PCI-X slots
 
Here's the output from the Oops


*pde = 
Oops:   [#1]
SMP
Modules linked in: raid) appletalk xfs sd_mod sg sr_mod  3w_9xxx scsi_mod 
nfsd exportfs ipv6 af_packet raw ide_floppy ide_tape ide_cd  cdrom e1000 
uhci_hcd 
usbcore rtc ext3 jbd
CPU: 1
EIP:  0060:[] Not tainted VLI
EFLAGS: 00010246  (2.6.10es-feb06)
EIP is at remove_proc_entry+0x2a/0x166
eax:  ebx:  f66a4e00 ecx:  edx: f6da1300
esi: f7cfb000 edi: 0005 ebp:  c2183eb4 esp: c2183e94
ds: 007b es: 007b ss: 0068
Process swapper (pid: 0,  threadinfo=c2182000 task=c214e520)
Stack: c043402c c043402c  c2024980  0005 f66a4e00 f7cfb000 
 c2183ec8 f8c4f051 0005 f6da1300 f66a4e00  c2183ee8 f8c2cc7b 
f66a4e00 
c2024980 0002  f6da7e80 f6da6080 c2183f04  c0289967 f66a4e00
Call Trace: 
[]  show_stack+0xaf/0xb7
[]  show_registers+0x15f/0x1d2
[]  die+0xfa/0x180
[]  do_page_fault+0x464/0x646
[]  error_code+0x2b/0x30
[] snmp6_unregister_dev+0x41/0x57  [ipv6]
[] in6_dev_finish_destroy+0x35/0xb6  [ipv6]
[] dst_destroy+0xa2/0xcd
[]  dst_run_gc+0x72/0xfb
[]  run_timer_softirq+0xc4/0x185
[]  __do_softirq+0x65/0xd3
[]  do_softirq+0x31/0x33
[]  apic_timer_interrupt+0x1c/0x24
[]  cpu_idle+0x31/0x3f
[<>] 0x0
[]  0xc2183fbc
Code: e2 55 89 ef 83 ec 20 8b 55 0c 8b 4d 08 89 5d f4 85 d2 89 75  f8 89 7d 
fc 89 4d f0 0f 84 b0 00 00 00 8b 7d f0 31 c0 b9 ff ff ff ff   ae f7 d1 49 
8b 42 34 8d 5a 34 85 c0 89 ce 0f 84 84 00 00 00 
<0>Kernel  panic â not syncing: Fatal exception in interrupt
 
-
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.6.11-rc3-mm2] perfctr-2.7.10 API update 3/4: x86_64

[Mikael Pettersson]

perfctr-2.7.10 update, 3/4:
- Update x86_64 syscall table for perfctr-2.7.10 API changes.

Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]>

 include/asm-x86_64/unistd.h |8 +++-
 1 files changed, 3 insertions(+), 5 deletions(-)

diff -rupN linux-2.6.11-rc3-mm2/include/asm-x86_64/unistd.h 
linux-2.6.11-rc3-mm2.perfctr-2.7.10-x86_64-syscalls-update/include/asm-x86_64/unistd.h
--- linux-2.6.11-rc3-mm2/include/asm-x86_64/unistd.h2005-02-20 
12:39:30.0 +0100
+++ 
linux-2.6.11-rc3-mm2.perfctr-2.7.10-x86_64-syscalls-update/include/asm-x86_64/unistd.h
  2005-02-20 13:15:32.0 +0100
@@ -567,11 +567,9 @@ __SYSCALL(__NR_keyctl, sys_keyctl)
 __SYSCALL(__NR_vperfctr_open, sys_vperfctr_open)
 #define __NR_vperfctr_control  (__NR_vperfctr_open+1)
 __SYSCALL(__NR_vperfctr_control, sys_vperfctr_control)
-#define __NR_vperfctr_unlink   (__NR_vperfctr_open+2)
-__SYSCALL(__NR_vperfctr_unlink, sys_vperfctr_unlink)
-#define __NR_vperfctr_iresume  (__NR_vperfctr_open+3)
-__SYSCALL(__NR_vperfctr_iresume, sys_vperfctr_iresume)
-#define __NR_vperfctr_read (__NR_vperfctr_open+4)
+#define __NR_vperfctr_write(__NR_vperfctr_open+2)
+__SYSCALL(__NR_vperfctr_write, sys_vperfctr_write)
+#define __NR_vperfctr_read (__NR_vperfctr_open+3)
 __SYSCALL(__NR_vperfctr_read, sys_vperfctr_read)
 
 #define __NR_syscall_max __NR_vperfctr_read
-
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.6.11-rc3-mm2] perfctr-2.7.10 API update 1/4: common

[Mikael Pettersson]

Andrew,

This set of patches form the first half of a major perfctr API update.
The goal is to change the upload-new-control-data system call to be
much more generic and independent of struct layouts. To this end the
upload-new-control-data syscall will become
ret = sys_vperfctr_write(fd, namespace, data, datalen)
where namespace determines how data is to be interpreted. Initially
there will probably be one namespace for perfctr's software state,
and one CPU-specific namespace for pure hardware state; the latter
will probably be expressed generically as a  array.

This API change will however require that the write() operation doesn't
imply a (re)start of the context, since usually more than one write will
be needed to upload all control data. Therefore this first set of patches
alter the API so that control data uploads and parameterless state changes
are performed by different system calls. The current control() call becomes
a light-weight write() call, but still using the old control data layout.
A new unified control() call is introduced for state changes, replacing and
extending the current unlink() and iresume() calls.

perfctr-2.7.10 update, 1/4:
- Added new sys_vperfctr_control(), with UNLINK, SUSPEND,
  RESUME, and CLEAR sub-commands. Deleted sys_vperfctr_unlink()
  and sys_vperfctr_iresume(). Changed sys_vperfctr_write()
  to only update control data and not reenable the context.
  RESUME now works both for resuming after overflow interrupts
  and for restarting after changing control data.
- Renamed old sys_vperfctr_control() to sys_vperfctr_write().

Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]>

 drivers/perfctr/version.h |2 
 drivers/perfctr/virtual.c |  233 --
 include/linux/perfctr.h   |   19 ++-
 kernel/sys_ni.c   |3 
 4 files changed, 159 insertions(+), 98 deletions(-)

diff -rupN linux-2.6.11-rc3-mm2/drivers/perfctr/version.h 
linux-2.6.11-rc3-mm2.perfctr-2.7.10-common-update/drivers/perfctr/version.h
--- linux-2.6.11-rc3-mm2/drivers/perfctr/version.h  2005-02-20 
12:39:29.0 +0100
+++ linux-2.6.11-rc3-mm2.perfctr-2.7.10-common-update/drivers/perfctr/version.h 
2005-02-20 13:17:43.0 +0100
@@ -1 +1 @@
-#define VERSION "2.7.9"
+#define VERSION "2.7.10"
diff -rupN linux-2.6.11-rc3-mm2/drivers/perfctr/virtual.c 
linux-2.6.11-rc3-mm2.perfctr-2.7.10-common-update/drivers/perfctr/virtual.c
--- linux-2.6.11-rc3-mm2/drivers/perfctr/virtual.c  2005-02-20 
12:39:29.0 +0100
+++ linux-2.6.11-rc3-mm2.perfctr-2.7.10-common-update/drivers/perfctr/virtual.c 
2005-02-20 13:17:43.0 +0100
@@ -1,7 +1,7 @@
-/* $Id: virtual.c,v 1.110 2004/11/24 00:38:30 mikpe Exp $
+/* $Id: virtual.c,v 1.111 2005/02/20 11:56:44 mikpe Exp $
  * Virtual per-process performance counters.
  *
- * Copyright (C) 1999-2004  Mikael Pettersson
+ * Copyright (C) 1999-2005  Mikael Pettersson
  */
 #include 
 #include 
@@ -39,8 +39,10 @@ struct vperfctr {
 #ifdef CONFIG_PERFCTR_CPUS_FORBIDDEN_MASK
atomic_t bad_cpus_allowed;
 #endif
+   unsigned int preserve;
+   unsigned int resume_cstatus;
 #ifdef CONFIG_PERFCTR_INTERRUPT_SUPPORT
-   unsigned int iresume_cstatus;
+   unsigned int ireload_needed; /* only valid if resume_cstatus != 0 */
 #endif
/* children_lock protects inheritance_id and children,
   when parent is not the one doing release_task() */
@@ -64,14 +66,8 @@ static inline void vperfctr_set_ihandler
perfctr_cpu_set_ihandler(vperfctr_ihandler);
 }
 
-static inline void vperfctr_clear_iresume_cstatus(struct vperfctr *perfctr)
-{
-   perfctr->iresume_cstatus = 0;
-}
-
 #else
 static inline void vperfctr_set_ihandler(void) { }
-static inline void vperfctr_clear_iresume_cstatus(struct vperfctr *perfctr) { }
 #endif
 
 #ifdef CONFIG_PERFCTR_CPUS_FORBIDDEN_MASK
@@ -280,10 +276,11 @@ static void vperfctr_handle_overflow(str
   __FUNCTION__, tsk->pid);
return;
}
+   perfctr->ireload_needed = 1;
/* suspend a-mode and i-mode PMCs, leaving only TSC on */
/* XXX: some people also want to suspend the TSC */
-   perfctr->iresume_cstatus = perfctr->cpu_state.cstatus;
-   if (perfctr_cstatus_has_tsc(perfctr->iresume_cstatus)) {
+   perfctr->resume_cstatus = perfctr->cpu_state.cstatus;
+   if (perfctr_cstatus_has_tsc(perfctr->resume_cstatus)) {
perfctr->cpu_state.cstatus = perfctr_mk_cstatus(1, 0, 0);
vperfctr_resume(perfctr);
} else
@@ -387,7 +384,7 @@ static void vperfctr_unlink(struct task_
task_unlock(owner);
 
perfctr->cpu_state.cstatus = 0;
-   vperfctr_clear_iresume_cstatus(perfctr);
+   perfctr->resume_cstatus = 0;
if (do_unlink)
put_vperfctr(perfctr);
 }
@@ -486,7 +483,7 @@ void __vperfctr_resume(struct vperfctr *
if (unlikely(atomic_read(>bad_cpus_allowed)) &&

[PATCH][2.6.11-rc3-mm2] perfctr-2.7.10 API update 2/4: i386

[Mikael Pettersson]

perfctr-2.7.10 update, 2/4:
- Update i386 syscall table for perfctr-2.7.10 API changes.

Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]>

 arch/i386/kernel/entry.S |3 +--
 arch/x86_64/ia32/ia32entry.S |3 +--
 include/asm-i386/unistd.h|7 +++
 include/asm-x86_64/ia32_unistd.h |7 +++
 4 files changed, 8 insertions(+), 12 deletions(-)

diff -rupN linux-2.6.11-rc3-mm2/arch/i386/kernel/entry.S 
linux-2.6.11-rc3-mm2.perfctr-2.7.10-i386-syscalls-update/arch/i386/kernel/entry.S
--- linux-2.6.11-rc3-mm2/arch/i386/kernel/entry.S   2005-02-20 
12:39:29.0 +0100
+++ 
linux-2.6.11-rc3-mm2.perfctr-2.7.10-i386-syscalls-update/arch/i386/kernel/entry.S
   2005-02-20 13:13:13.0 +0100
@@ -901,8 +901,7 @@ ENTRY(sys_call_table)
.long sys_keyctl
.long sys_vperfctr_open
.long sys_vperfctr_control  /* 290 */
-   .long sys_vperfctr_unlink
-   .long sys_vperfctr_iresume
+   .long sys_vperfctr_write
.long sys_vperfctr_read
 
 syscall_table_size=(.-sys_call_table)
diff -rupN linux-2.6.11-rc3-mm2/arch/x86_64/ia32/ia32entry.S 
linux-2.6.11-rc3-mm2.perfctr-2.7.10-i386-syscalls-update/arch/x86_64/ia32/ia32entry.S
--- linux-2.6.11-rc3-mm2/arch/x86_64/ia32/ia32entry.S   2005-02-20 
12:39:29.0 +0100
+++ 
linux-2.6.11-rc3-mm2.perfctr-2.7.10-i386-syscalls-update/arch/x86_64/ia32/ia32entry.S
   2005-02-20 13:13:13.0 +0100
@@ -597,8 +597,7 @@ ia32_sys_call_table:
.quad sys_keyctl
.quad sys_vperfctr_open
.quad sys_vperfctr_control  /* 290 */
-   .quad sys_vperfctr_unlink
-   .quad sys_vperfctr_iresume
+   .quad sys_vperfctr_write
.quad sys_vperfctr_read
/* don't forget to change IA32_NR_syscalls */
 ia32_syscall_end:  
diff -rupN linux-2.6.11-rc3-mm2/include/asm-i386/unistd.h 
linux-2.6.11-rc3-mm2.perfctr-2.7.10-i386-syscalls-update/include/asm-i386/unistd.h
--- linux-2.6.11-rc3-mm2/include/asm-i386/unistd.h  2005-02-20 
12:39:30.0 +0100
+++ 
linux-2.6.11-rc3-mm2.perfctr-2.7.10-i386-syscalls-update/include/asm-i386/unistd.h
  2005-02-20 13:13:13.0 +0100
@@ -296,11 +296,10 @@
 #define __NR_keyctl288
 #define __NR_vperfctr_open 289
 #define __NR_vperfctr_control  (__NR_vperfctr_open+1)
-#define __NR_vperfctr_unlink   (__NR_vperfctr_open+2)
-#define __NR_vperfctr_iresume  (__NR_vperfctr_open+3)
-#define __NR_vperfctr_read (__NR_vperfctr_open+4)
+#define __NR_vperfctr_write(__NR_vperfctr_open+2)
+#define __NR_vperfctr_read (__NR_vperfctr_open+3)
 
-#define NR_syscalls 294
+#define NR_syscalls 293
 
 /*
  * user-visible error numbers are in the range -1 - -128: see
diff -rupN linux-2.6.11-rc3-mm2/include/asm-x86_64/ia32_unistd.h 
linux-2.6.11-rc3-mm2.perfctr-2.7.10-i386-syscalls-update/include/asm-x86_64/ia32_unistd.h
--- linux-2.6.11-rc3-mm2/include/asm-x86_64/ia32_unistd.h   2005-02-20 
12:39:30.0 +0100
+++ 
linux-2.6.11-rc3-mm2.perfctr-2.7.10-i386-syscalls-update/include/asm-x86_64/ia32_unistd.h
   2005-02-20 13:13:13.0 +0100
@@ -296,10 +296,9 @@
 #define __NR_ia32_keyctl   288
 #define __NR_ia32_vperfctr_open289
 #define __NR_ia32_vperfctr_control (__NR_ia32_vperfctr_open+1)
-#define __NR_ia32_vperfctr_unlink  (__NR_ia32_vperfctr_open+2)
-#define __NR_ia32_vperfctr_iresume (__NR_ia32_vperfctr_open+3)
-#define __NR_ia32_vperfctr_read(__NR_ia32_vperfctr_open+4)
+#define __NR_ia32_vperfctr_write   (__NR_ia32_vperfctr_open+2)
+#define __NR_ia32_vperfctr_read(__NR_ia32_vperfctr_open+3)
 
-#define IA32_NR_syscalls 294   /* must be > than biggest syscall! */
+#define IA32_NR_syscalls 293   /* must be > than biggest syscall! */
 
 #endif /* _ASM_X86_64_IA32_UNISTD_H_ */
-
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: Should kirqd work on HT?

[Martin J. Bligh]

> I've noticed this problem for a while, but only now decided to ask.
> Interrupt balancing doesn't do anything on my system.
> 
>CPU0   CPU1
>   0:   31931808  0IO-APIC-edge  timer
>   1:  76595  0IO-APIC-edge  i8042
>   8:  1  0IO-APIC-edge  rtc
>   9:  1  0   IO-APIC-level  acpi
>  14:122  1IO-APIC-edge  ide0
>  16:4074456  0   IO-APIC-level  uhci_hcd, uhci_hcd, [EMAIL 
> PROTECTED]:1:0:0
>  17:4295132  0   IO-APIC-level  Intel ICH5
>  18:2070933  0   IO-APIC-level  libata, uhci_hcd, eth0
>  19: 887311  0   IO-APIC-level  uhci_hcd
>  22: 572530  0   IO-APIC-level  ath0
> NMI:   31931749   31931636 (I've since disabled the nmi_watchdog)
> LOC:   31931252   31931251
> ERR:  0
> MIS:  0
> 
> I enabled the debugging and found that it doesn't think it's worth the
> effort. Is that correct? Not a complaint, just curious!

I think it's nothing to do with HT, just the rate you're sending intterrupts
at isn't high enough to bother rotating.

M.

-
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: Should kirqd work on HT?

[Martin J. Bligh]

--Jeff Garzik <[EMAIL PROTECTED]> wrote (on Saturday, February 19, 2005 
11:30:53 -0500):

> Pallipadi, Venkatesh wrote:
>> You are right. Kernel balancer doesn't move around the irqs, unless it
>> has too many interrupts. The logic is moving around interrupts all the
>> time will not be good on caches. So, there is a threshold above which
>> the balancer start moving things around.
>> 
>> You should see them moving around if you do 'ping -f' or a big 'dd' from
>> the disk.
> 
> If kirqd is moving NIC interrupts, it's broken.
> 
> (and another reason why irqbalanced is preferable)

Why is it broken to move NIC interrupts? Obviously you don't want to
rotate them around a lot, but in the interests of fairness to other 
processes, it seems reasonable to migrate them occasionally (IIRC, kirqd
rate limits to once a second or something).

M.

-
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: Question on CONFIG_IRQBALANCE / 2.6.x

[Martin J. Bligh]

>> > there's something I don't understand:  With IRQBALANCE *enabled* almost
>> > all interrupts are processed on CPU0.  This changed in an unexpected way
>> > after disabling IRQBALANCE: now all interrupts are distributed uniformly
>> > to both CPUs.  Maybe it's intentional, but it's not what I expect when a
>> > config option named IRQBALANCE is *disabled*.
>> > 
>> > Can anybody comment on this?
>> 
>> If you have a Pentium 3 based system, by default they'll round robin.
>> If you turn on IRQbalance, they won't move until the traffic gets high
>> enough load to matter. That's presumably what you're seeing.
> 
> It's an Athlon box that propably has the same behaviour.  Just another
> question on this topic:  with IRQBALANCE enabled, almost all interupts
> are routet to CPU0.  Lately irq 0 runs on CPU1 and never returns to CPU0
> - is there any obvious reason for that?

If it's not getting interrupts at 1010 per second or so, it won't rotate
them, on the grounds it's not worthwhile.

M.

-
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/

[BK PATCHES] ide-2.6 update

[Bartlomiej Zolnierkiewicz]

Hi,

Please do a

bk pull bk://bart.bkbits.net/ide-2.6

This will update the following files:

 drivers/ide/Kconfig  |2 +-
 drivers/ide/ide-io.c |5 +++--
 drivers/ide/ide.c|4 
 3 files changed, 8 insertions(+), 3 deletions(-)

through these ChangeSets:

<[EMAIL PROTECTED]> (05/02/20 1.2130)
   [ide] Kconfig for VR1000 machine driver selection

   Fix the use of CONFIG_MACH_VR1000, which was missing an
   trailing zero from the configuration variable, so never
   being shown if only the VR1000 was selected

   Signed-off-by: Ben Dooks <[EMAIL PROTECTED]>
   Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>

<[EMAIL PROTECTED]> (05/02/20 1.2129)
   [ide] small compile fix to ide.c with !CONFIG_PCI

   Small patch to fix following warning with CONFIG_IDE && !CONFIG_PCI:

 CC drivers/ide/ide.o
   drivers/ide/ide.c: In function 'ide_system_bus_speed':
   drivers/ide/ide.c:338: warning: unused variable 'pci_default'

   I decided to save some bytes by #ifdef:ing the struct in question.
   CC:ing Hanna because she did the change (and just to say hi ;-).

   Signed-off-by: Mika Kukkonen <[EMAIL PROTECTED]>
   Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>

<[EMAIL PROTECTED](none)> (05/02/19 1.2128)
   [ide] fix ide_get_error_location() for LBA28

   Higher bits (16-23) of the address were ignored.

   Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>

diff -Nru a/drivers/ide/Kconfig b/drivers/ide/Kconfig
--- a/drivers/ide/Kconfig   2005-02-20 15:08:56 +01:00
+++ b/drivers/ide/Kconfig   2005-02-20 15:08:56 +01:00
@@ -812,7 +812,7 @@

 config BLK_DEV_IDE_BAST
tristate "Simtec BAST / Thorcom VR1000 IDE support"
-   depends on ARM && (ARCH_BAST || MACH_VR100)
+   depends on ARM && (ARCH_BAST || MACH_VR1000)
help
  Say Y here if you want to support the onboard IDE channels on the
  Simtec BAST or the Thorcom VR1000
diff -Nru a/drivers/ide/ide-io.c b/drivers/ide/ide-io.c
--- a/drivers/ide/ide-io.c  2005-02-20 15:08:56 +01:00
+++ b/drivers/ide/ide-io.c  2005-02-20 15:08:56 +01:00
@@ -238,9 +238,10 @@
high = ide_read_24(drive);
} else {
u8 cur = HWIF(drive)->INB(IDE_SELECT_REG);
-   if (cur & 0x40)
+   if (cur & 0x40) {
+   high = cur & 0xf;
low = (hcyl << 16) | (lcyl << 8) | sect;
-   else {
+   } else {
low = hcyl * drive->head * drive->sect;
low += lcyl * drive->sect;
low += sect - 1;
diff -Nru a/drivers/ide/ide.c b/drivers/ide/ide.c
--- a/drivers/ide/ide.c 2005-02-20 15:08:56 +01:00
+++ b/drivers/ide/ide.c 2005-02-20 15:08:56 +01:00
@@ -335,10 +335,14 @@

 static int ide_system_bus_speed(void)
 {
+#ifdef CONFIG_PCI
static struct pci_device_id pci_default[] = {
{ PCI_DEVICE(PCI_ANY_ID, PCI_ANY_ID) },
{ }
};
+#else
+#define pci_default 0
+#endif /* CONFIG_PCI */

if (!system_bus_speed) {
if (idebus_parameter) {
-
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/

Intel Gigabit NIC (2.6.5 -> 2.6.10) Bug(?) Found

[Justin Piszcz]

What is this e-mail about?
Something in the kernel changed regarding the Intel e1000 driver from 
2.6.5 to 2.6.10. The change resulted in thousands of errors when the NIC 
is receiving data. For the past two weeks I have thought about this and 
tried everything I could think of, it had really been pestering me. 
Normally, I never really looked at my ifconfig eth0, eth1 etc because I 
looked at it a long time ago and noticed it was just fine, this was with 
earlier kernels.  I guess I should check my NIC statistics more often. I 
have tried the following to figure out why I get so many dropped packets 
and errors on an interface:

1] New Intel [same model] NIC.
2] Different ports in the switch.
3] New cable.
4] Switched PCI slots for the Intel Gigabit Card.
5] Switched BIOS settings/parameters to exact settings as other, identical
   machine.
None of these fixed the problem. There are two machines (same model) here 
with GigE nics, on one there are  very few (1-3) if any errors on the nic 
ever.  The test that I used that reproduces the problem the quickest is dd 
if=/dev/zero of=/nfsv3/udp/file.img where the dd is on another box sending 
to the box that gets the RX errors on the NIC.  Generally, there would be 
about 100 errors every 10 seconds.  There are two identical machines on 
the network here, both with this same Intel Gigabit NIC (82541GI/PI).  So 
one machine is running 2.6.5, the other 2.6.10, I figured it had to 
something in the kernel that was causing this.  Therefore I grabbed 
ethtool and installed it and did a basic query for network setting 
parameters, immediately I noticed a difference, which is shown below:

* Box with no problems.
# ethtool -a eth0
Pause parameters for eth0:
Autonegotiate:  on
RX: on
TX: on
* Box with NIC that generates errors, dropped packets and overrun errors.
# ethtool -a eth0
Pause parameters for eth0:
Autonegotiate:  on
RX: off
TX: off
According to the manpage:
   -A change the pause parameters of the specified ethernet 
device.

   rx on|off
  Specify if RX pause is enabled.
   tx on|off
  Specify if TX pause is enabled.
# ethtool -A eth0 rx on
# ethtool -A eth0 tx on
My machine now:
# ethtool -a eth0
Pause parameters for eth0:
Autonegotiate:  on
RX: on
TX: on
Then, I re-run the dd command mentioned earlier and let it run for about 
ten minutes, long and behold not a single dropped packet, overrun or frame
error reported!

  RX packets:6157606 errors:0 dropped:0 overruns:0 frame:0
Previously, this is what I would get after only a minute of running that 
dd command (I also get the errors copying files etc, dd command just 
speeds things up):

  RX packets:6374096 errors:1419 dropped:1419 overruns:1419 frame:0
Afterwards, I no longer have any errors:
To the Intel/Kernel guys:
Question, these are identical machines for the most part, even the same 
nics are used in each box, why in 2.6.5 are the settings set differently 
than that in 2.6.10?  I do not believe that it is a distribution specific 
error as I did not even have ethtool installed before I checked this nor 
do I see it any boot scripts?  For now, I will just have it set the 
proper settings -A tx on and -A rx on but is there another way to do this 
or did it change in the kernel at some point?

Further investigation reveals on my main machine with an onboard Intel/PRO 
1000 built-in NIC which runs on the CSA bus (A-Bit IC7-G) the pause 
feature is also off; HOWEVER, (2.6GHZ w/HT) this machine does not exhibit 
any errors!

  RX packets:2471666 errors:0 dropped:0 overruns:0 frame:0
  TX packets:56413066 errors:0 dropped:0 overruns:0 carrier:0
Is it a bug that it defaults to off in the newer kernel versions, as it 
causes MASSIVE errors on the RX side of the fence?  Or should people who 
run gigabit interfaces on slower machines just add the ethool commands to 
their startup scripts to avoid the errors/etc?

There may be some parallel between speed_OF_CPU and whether it can 
handle it with the pause option on or off.  If anyone has any idea of what 
the pause option is about and why it changed from 2.6.5 to 2.6.10, I'd 
like to know!

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

[PATCH] Replaces (2 * HZ) with DATA_TIMEOUT in /drivers/usb/atm/speedtch.c

[Telemaque Ndizihiwe]

This Patch replaces "(2 * HZ)" with "DATA_TIMEOUT" which is defined as
#define DATA_TIMEOUT (2 * HZ)
in /drivers/usb/atm/speedtch.c in kernel 2.6.10.

Signed-off-by: Telemaque Ndizihiwe <[EMAIL PROTECTED]>

--- linux-2.6.10/drivers/usb/atm/speedtch.c.orig2005-02-20
12:44:22.235267848 +
+++ linux-2.6.10/drivers/usb/atm/speedtch.c 2005-02-20
12:50:52.205983288 +
@@ -494,7 +494,7 @@ static void speedtch_upload_firmware(str
/* URB 7 */
if (dl_512_first) { /* some modems need a read before writing the
firmware */
ret = usb_bulk_msg(usb_dev, usb_rcvbulkpipe(usb_dev,
SPEEDTCH_ENDPOINT_FIRMWARE),
-  buffer, 0x200, _length, 2 * HZ);
+  buffer, 0x200, _length, DATA_TIMEOUT);
 
if (ret < 0 && ret != -ETIMEDOUT)
dbg("speedtch_upload_firmware: read BLOCK0 from modem 
failed (%d)!",
ret);



-
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/

Kernel 2.4.29 (Sparc64) and iproute

[BERTRAND Joël]

Hello,

I'm trying to use iproute (20041019) with 2.4.29 official kernel on
a UltraSparc 1E. I have marked all packets that come from an
intranet server (192.168.0.130:3000 / tcp) like this :

Chain PREROUTING (policy ACCEPT 13344 packets, 1830K bytes)
 pkts bytes target prot opt in out source
destination 
   89  5340 MARK   tcp  --  *  *   192.168.0.130
0.0.0.0/0   tcp spts:3000:3001 MARK set 0x1 

And I have logged the result of iptables. All packets are marked.
So, I have written a new rule with iproute :

Root kant:[/var/log] > ip rule show
0:  from all lookup local 
100:from 192.168.1.1 lookup intranet 
101:from all fwmark 0x1 lookup intranet 
32766:  from all lookup main 
32767:  from all lookup default 
Root kant:[/var/log] > ip route show table intranet
default via 192.168.1.254 dev eth2 
Root kant:[/var/log] > 

My intranet table is ignored. But I can use the second interface. If
I replace "from all fwmark 0x1 lookup intranet" by ""from
192.168.0.130 lookup intranet", all packets coming from my intranet
server all redirected conforming to intranet table. Any idea ? Is
iproute broken with 2.4.29 ?

Thanks in advance,

JKB
-
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: Bootsplash for 2.6.11-rc4

[Michal Januszewski]

On Sun, Feb 20, 2005 at 12:25:19AM +0100, Pavel Machek wrote:

Hi,
 
> Yes, I agree, almost anything is more sane than code I posted :-(. My
> only requirement is that it works with radeonfb and similar low-level
> drivers (so that I can get suspend-to-ram to work) and that it gets
> past our branding people...   

I don't know about the branding people, but suspend-to-ram and radeonfb
shouldn't be a problem for fbsplash :)
 
> How many distros do use some variant of bootsplash? SuSE does, from
> above url I guess gentoo does, too... Does RedHat do something
> similar? [Or do they just set log-level to very high giving them clean
> look?] What about Debian?

As far as I know: SuSE uses bootsplash, Gentoo and PLD use fbsplash,
RedHat uses rhgb (100% userspace solution, based on xvesa, doesn't
provide graphical backgrounds on vt's - for that a kernel patch like
bootsplash or fbsplash is necessary). I don't know about Debian - they
probably have some (possibly unofficial) support for both bootsplash
and fbsplash.

Live long and prosper.
-- 
Michal 'Spock' JanuszewskiGentoo Linux Developer
cell: +48504917690 http://dev.gentoo.org/~spock/
JID: [EMAIL PROTECTED]   freenode: #gentoo-dev, #gentoo-pl



pgpagHh0Xoksi.pgp
Description: PGP signature

Re: Bootsplash for 2.6.11-rc4

[Michal Januszewski]

On Sat, Feb 19, 2005 at 03:03:26PM -0800, Greg KH wrote:

> Pavel, I agree with Michal, take a look at this version of the code
> instead of the version that you posted.  It's a _whole_ lot more sane,
> and possibly even mergable.
> 
> Michal, any thoughts on submitting it for inclusion?  It seems pretty
> stable now.

It is pretty stable indeed, I haven't had any major bug reports for 
quite some time now. It's probably as ready as it's ever going to be.
So the question is: what should I do with it? Who do I send it to?

Also, if anyone has comments about the code, bug reports, etc. - feel
free to contact me. If there are any issues remaining, I'd like to fix
them ASAP.

Live long and prosper.
-- 
Michal 'Spock' JanuszewskiGentoo Linux Developer
cell: +48504917690 http://dev.gentoo.org/~spock/
JID: [EMAIL PROTECTED]   freenode: #gentoo-dev, #gentoo-pl



pgpK8g0ADzaui.pgp
Description: PGP signature

Re: Why does printk helps PCMCIA card to initialise?

[Russell King]

On Sun, Feb 20, 2005 at 12:44:25PM +0100, Martin Drohmann wrote:
>  #ifdef CONFIG_PCI
> if (s->cb_dev) {
> ret = pci_bus_alloc_resource(s->cb_dev->bus, res, num, 1,
>  min, 0, pcmcia_align, );
> } else
>  #endif
> -printk("This line will never be printed, but it helps!!!");

If you added this, you've done much more than just adding it.  Look 
two lines above and realise that you've just changed what the "else"
clause conditionalises.

> ret = allocate_resource(_resource, res, num, min, 
> ~0UL,
> 1, pcmcia_align, );

So, with your printk in place, we try pci_bus_alloc_resource.  If that
succeeds or fails, we completely stomp on that with allocate_resource.
Bad.  Very bad.

The first thing that needs solving is why you're getting the "odd IO
request" crap.  That may explain why the resource can't be allocated.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA  - http://pcmcia.arm.linux.org.uk/
 2.6 Serial core
-
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 2/2] page table iterators

[Nick Piggin]

Andi Kleen wrote:
On Thu, Feb 17, 2005 at 03:30:31PM -0800, David S. Miller wrote:
On Fri, 18 Feb 2005 00:03:42 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:

And to be honest we only have about 6 or 7 of these walkers
in the whole kernel. And 90% of them are in memory.c
While doing 4level I think I changed all of them around several
times and it wasn't that big an issue.  So it's not that we
have a big pressing problem here... 
It's super error prone.  A regression added by your edit of these

Actually it was in Nick's code (PUD layer ;-).  But I won't argue
that my code didn't have bugs too...

I won't look back to see where the error came from :) But
yeah it is equally (if not more) likely to have come from
me. And it probably did happen because all the code is
slightly different and hard to understand.
walkers for the 4level changes was only discovered and fixed
yesterday by the ppc folks.
I absolutely support any change which consolidates these things.

The problem is just that these walker macros when they
do all the lazy walking stuff will be quite complicated.
And I don't really want another uaccess.h-like macro mess.
Yes currently they look simple, but that will change.
But even in that case, it will still be better to have the
extra complexity once in the macro rather than throughout mm/
Open coding is probably the smaller evil.
And they're really not changed that often.
It is not so much a matter of changing, so much as having 10
slightly different implementations.
I think it should be easier to go from the iterators patch to
perhaps more complex iterators, or some open coding, etc etc.
rather than try to put a big complex pt walker on top of these
10 different open coded implementations.
But perhaps I'm missing something you're not - I'd need to see
the lazy walking code I guess.
Nick
-
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 does printk helps PCMCIA card to initialise?

[Vicente Feito]

Hello

On Sunday 20 February 2005 11:44 am, you wrote:
>  
> diff -u -U 7 /linux-2.6.11-rc4.changed/drivers/pcmcia/rsrc_nonstatic.c 
> ../linux-2.6.11-rc4/drivers/pcmcia/rsrc_nonstatic.c
> --- /linux-2.6.11-rc4.changed/drivers/pcmcia/rsrc_nonstatic.c 
> 2005-02-20 11:37:39.0 +0100
> +++ ../linux-2.6.11-rc4/drivers/pcmcia/rsrc_nonstatic.c 2005-02-20 
> 02:16:48.0 +0100
> @@ -623,15 +623,14 @@
> down(_sem);
>  #ifdef CONFIG_PCI
> if (s->cb_dev) {
> ret = pci_bus_alloc_resource(s->cb_dev->bus, res, num, 1,
>  min, 0, pcmcia_align, );
> } else
>  #endif
> -printk("This line will never be printed, but it helps!!!");
> ret = allocate_resource(_resource, res, num, min, 
What you're doing is forcing the execution of allocate_resource ( );
Cause adding the printk you're adding it's changing this:
else 
 ret = allocate_resource(...);
up(...);

by this:

else
 printk(...);
/*This is not executing inside the else clause no more,
 *so doesn't matter if s->cb_dev it's true or not, you're going with this*/
ret = allocate_resource(...); 
up(...);

You're changing the block inside the else clause.
It's not about upsetting the sem afaik.
I could be wrong though, and that'll be a terrible tragedy.
Of course this is as long as CONFIG_PCI it's evaluating true, is it?

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

Re: IBM Thinkpad G41 PCMCIA problems [Was: Yenta TI: ... no PCI interrupts. Fish. Please report.]

[Steven Rostedt]

On Sun, 2005-02-20 at 10:20 +, Russell King wrote:

> BTW, try passing:
> 
>   reserve=0x3fefa000,0x6000
> 
> to the kernel - this will mark the "hole" reserved and should reallocate
> the resources which are clashing with the RAM.
> 
I just  tried this on 2.6.9 (with no patches) and it worked. So I think
Russ is right.

I guess the problem arises when you have an IBM G41 Thinkpad with a Gig
of RAM.

Linus,

How much RAM is on your machine?

-- Steve



-
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/