New :Cue:Cat driver v0.0.5
Hello all, New v0.0.5 has some minor corrections and a new userland utility. The driver is available at : http://oss.lineo.com/projects.html Have fun :) \ (@ @) --oOOo-(_)-oOOo--- Pierre-Philippe Coupard Software Engineer, Lineo, Inc. Email : [EMAIL PROTECTED] Phone : (801) 426-5001 x 208 -- In the eyes of my dog, I'm a man. -- Martin Mull
Bugfixes in the :Cue:Cat driver
Hello all, New v0.0.7 now has a correct initialization code for the timeout kernel thread. Also added a configuration option to enable the driver by default at boot time. The driver is available at : http://oss.lineo.com/projects.html Have fun :) \ (@ @) --oOOo-(_)-oOOo--- Pierre-Philippe Coupard Software Engineer, Lineo, Inc. Email : [EMAIL PROTECTED] Phone : (801) 426-5001 x 208 -- The only time a dog gets complimented is when he doesn't do anything. -- C. Schulz
Re: test10-pre5 won't boot on my Athlon machine (Irongate and Viper chip sets)
Miles Lane wrote:
> Perhaps this is related to the PCI issues that are being debated on the list now.
> Would someone look at my bus configuration and let me know what to test or what
>patch to apply to get my kernel booting?
My Athlon box has a MSI A6195KMS bios. The motherboard has the IronGate and the Viper
chipsets, and test10-pre5 works great on it.
One possible caveats :
- USB doesn't work too well, because of a bug in the Viper USB controller. You may
want to try to disable "PnP aware OS" in the bios. You may also try to download the
latest rev of the A6195KMS bios
available here :
http://www.amdzone.com/files/bios/msi/a6195kms173.zip
- Even when USB finally works, the ohci USB driver sends this kind of message all the
time :
usb-ohci.c: bogus NDP=64 for OHCI usb-00:07.4
usb-ohci.c: rereads as NDP=4
but it shouldn't kill your machine. In any doubt, just disable USB.
Otherwise, let me know if you want me to send you my .config and my BIOS settings, it
you think they can help you.
Take care !
--
__
_ / / | / ___/ _ /
/ /| / / / /
___ / / // __// /
__ / / // / / /
_ _/ _/ _/ _/ _/ /
\
(@ @)
----oOOo-(_)-oOOo-
Pierre-Philippe Coupard
Software Engineer, Lineo, Inc.
Email : [EMAIL PROTECTED]
Phone : (801) 426-5001 x 208
--
A door is what a dog is perpetually on the wrong side of.
-- Ogden Nash
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: eepro100: card reports no resources [was VM-global...]
Andrey Savochkin wrote: > > > Oct 26 16:38:01 ns29 kernel: eth0: card reports no resources. > > > > > let me guess: intel eepro100 or similar?? > > > 2.4.0-test9-pre3 it doesnt happen on my machine ... I run 2.4.0-test10-pre5 and it still does it. Trick : "ifconfig eth0 down" then "ifconfig eth0 up" stops the problem for me when it occurs. \ (@ @) oOOo-(_)-oOOo- Pierre-Philippe Coupard Software Engineer, Lineo, Inc. Email : [EMAIL PROTECTED] Phone : (801) 426-5001 x 208 -- Auribus teneo lupum. [I hold a wolf by the ears.] [Boy, it *sounds* good. But what does it *mean*?]
Re: [PATCH] sched/fair: use signed long when compute energy delta in eas
Hi, Hi On Wed, Apr 7, 2021 at 10:11 PM Pierre wrote: > > Hi, > > I test the patch, but the overflow still exists. > > In the "sched/fair: Use pd_cache to speed up find_energy_efficient_cpu()" > > I wonder why recompute the cpu util when cpu==dst_cpu in compute_energy(), > > when the dst_cpu's util change, it also would cause the overflow. > > The patches aim to cache the energy values for the CPUs whose > utilization is not modified (so we don't have to compute it multiple > times). The values cached are the 'base values' of the CPUs, i.e. when > the task is not placed on the CPU. When (cpu==dst_cpu) in > compute_energy(), it means the energy values need to be updated instead > of using the cached ones. > well, is it better to use the task_util(p) + cache values ? but in this case, the cache values may need more parameters. This patch-set is not significantly improving the execution time of feec(). The results we have so far are an improvement of 5-10% in execution time, with feec() being executed in < 10us. So the gain is not spectacular. > You are right, there is still a possibility to have a negative delta > with the patches at: > https://gitlab.arm.com/linux-arm/linux-power/-/commits/eas/next/integration-20210129 <https://gitlab.arm.com/linux-arm/linux-power/-/commits/eas/next/integration-20210129> > Adding a check before subtracting the values, and bailing out in such > case would avoid this, such as at: > https://gitlab.arm.com/linux-arm/linux-pg/-/commits/feec_bail_out/ <https://gitlab.arm.com/linux-arm/linux-pg/-/commits/feec_bail_out/> > In your patch, you bail out the case by "go to fail", that means you don't use eas in such case. However, in the actual scene, the case often occurr when select cpu for small task. As a result, the small task would not select cpu according to the eas, it may affect power consumption? With this patch (bailing out), the percentage of feec() returning due to a negative delta I get are: on a Juno-r2, with 2 big CPUs and 4 CPUs (capacity of 383), with a workload running during 5s with task having a period of 16 ms and: - 50 tasks at 1%: 0.14% - 30 tasks at 1%: 0.54% - 10 tasks at 1%: < 0.1% - 30 tasks at 5%: < 0.1% - 10 tasks at 5%: < 0.1% It doesn't happen so often to me.If we bail out of feec(), the task will still have another opportunity in the next call. However I agree this can lead to a bad placement when this happens. > I think a similar modification should be done in your patch. Even though > this is a good idea to group the calls to compute_energy() to reduce the > chances of having updates of utilization values in between the > compute_energy() calls, > there is still a chance to have updates. I think it happened when I > applied your patch. > > About changing the delta(s) from 'unsigned long' to 'long', I am not > sure of the meaning of having a negative delta. I thing it would be > better to check and fail before it happens instead. > > Regards >
Re: [PATCH] sched/fair: use signed long when compute energy delta in eas
Hi, I test the patch, but the overflow still exists. In the "sched/fair: Use pd_cache to speed up find_energy_efficient_cpu()" I wonder why recompute the cpu util when cpu==dst_cpu in compute_energy(), when the dst_cpu's util change, it also would cause the overflow. The patches aim to cache the energy values for the CPUs whose utilization is not modified (so we don't have to compute it multiple times). The values cached are the 'base values' of the CPUs, i.e. when the task is not placed on the CPU. When (cpu==dst_cpu) in compute_energy(), it means the energy values need to be updated instead of using the cached ones. You are right, there is still a possibility to have a negative delta with the patches at: https://gitlab.arm.com/linux-arm/linux-power/-/commits/eas/next/integration-20210129 Adding a check before subtracting the values, and bailing out in such case would avoid this, such as at: https://gitlab.arm.com/linux-arm/linux-pg/-/commits/feec_bail_out/ I think a similar modification should be done in your patch. Even though this is a good idea to group the calls to compute_energy() to reduce the chances of having updates of utilization values in between the compute_energy() calls, there is still a chance to have updates. I think it happened when I applied your patch. About changing the delta(s) from 'unsigned long' to 'long', I am not sure of the meaning of having a negative delta. I thing it would be better to check and fail before it happens instead. Regards
Re: [PATCH 2.6.24-rc8-mm1 09/15] (RFC) IPC: new kernel API to change an ID
Hi again, Thinking more about this, I think I must clarify why I choose this way. In fact, the idea of these patches is to provide the missing user APIs (or extend the existing ones) that allow to set or update _all_ properties of all IPCs, as needed in the case of the checkpoint/restart of an application (the current user API does not allow to specify an ID for a created IPC, for example). And this, without changing the existing API of course. And msgget(), semget() and shmget() does not have any parameter we can use to specify an ID. That's why I've decided to not change these routines and add a new control command, IP_SETID, with which we can can change the ID of an IPC. (that looks to me more straightforward and logical) Now, this patch is, in fact, only a preparation for the patch 10/15 which really complete the user API by adding this IPC_SETID command. (... continuing below ...) Alexey Dobriyan wrote: > On Tue, Jan 29, 2008 at 05:02:38PM +0100, [EMAIL PROTECTED] wrote: >> This patch provides three new API to change the ID of an existing >> System V IPCs. >> >> These APIs are: >> long msg_chid(struct ipc_namespace *ns, int id, int newid); >> long sem_chid(struct ipc_namespace *ns, int id, int newid); >> long shm_chid(struct ipc_namespace *ns, int id, int newid); >> >> They return 0 or an error code in case of failure. >> >> They may be useful for setting a specific ID for an IPC when preparing >> a restart operation. >> >> To be successful, the following rules must be respected: >> - the IPC exists (of course...) >> - the new ID must satisfy the ID computation rule. >> - the entry in the idr corresponding to the new ID must be free. > >> ipc/util.c | 48 >> ipc/util.h |1 + >> 8 files changed, 197 insertions(+) > > For the record, OpenVZ uses "create with predefined ID" method which > leads to less code. For example, change at the end is all we want from > ipc/util.c . And in fact, you do that from kernel space, you don't have the constraint to fit the existing user API. Again, this patch, even if it presents a new kernel API, is in fact a preparation for the next patch which introduces a new user API. Do you think that this could fit your need ? -- Pierre -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.24-rc8-mm1 14/15] (RFC) IPC/semaphores: prepare semundo code to work on another task than current
Serge E. Hallyn wrote:
> Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
>> From: Pierre Peiffer <[EMAIL PROTECTED]>
>>
>> In order to modify the semundo-list of a task from procfs, we must be able to
>> work on any target task.
>> But all the existing code playing with the semundo-list, currently works
>> only on the 'current' task, and does not allow to specify any target task.
>>
>> This patch changes all these routines to allow them to work on a specified
>> task, passed in parameter, instead of current.
>>
>> This is mainly a preparation for the semundo_write() operation, on the
>> /proc//semundo file, as provided in the next patch.
>>
>> Signed-off-by: Pierre Peiffer <[EMAIL PROTECTED]>
>> ---
>>
>> ipc/sem.c | 90
>> ++
>> 1 file changed, 68 insertions(+), 22 deletions(-)
>>
>> Index: b/ipc/sem.c
>> ===
>> --- a/ipc/sem.c
>> +++ b/ipc/sem.c
>> @@ -1017,8 +1017,9 @@ asmlinkage long sys_semctl (int semid, i
>> }
>>
>> /* If the task doesn't already have a undo_list, then allocate one
>> - * here. We guarantee there is only one thread using this undo list,
>> - * and current is THE ONE
>> + * here.
>> + * The target task (tsk) is current in the general case, except when
>> + * accessed from the procfs (ie when writting to /proc//semundo)
>> *
>> * If this allocation and assignment succeeds, but later
>> * portions of this code fail, there is no need to free the sem_undo_list.
>> @@ -1026,22 +1027,60 @@ asmlinkage long sys_semctl (int semid, i
>> * at exit time.
>> *
>> * This can block, so callers must hold no locks.
>> + *
>> + * Note: task_lock is used to synchronize 1. several possible concurrent
>> + * creations and 2. the free of the undo_list (done when the task using it
>> + * exits). In the second case, we check the PF_EXITING flag to not create
>> + * an undo_list for a task which has exited.
>> + * If there already is an undo_list for this task, there is no need
>> + * to held the task-lock to retrieve it, as the pointer can not change
>> + * afterwards.
>> */
>> -static inline int get_undo_list(struct sem_undo_list **undo_listp)
>> +static inline int get_undo_list(struct task_struct *tsk,
>> +struct sem_undo_list **ulp)
>> {
>> -struct sem_undo_list *undo_list;
>> +if (tsk->sysvsem.undo_list == NULL) {
>> +struct sem_undo_list *undo_list;
>
> Hmm, this is weird. If there was no undo_list and
> tsk!=current, you set the refcnt to 2. But if there was an
> undo list and tsk!=current, where do you inc the refcnt?
>
I inc it outside this function, as I don't call get_undo_list() if there is an
undo_list.
This appears most clearly in the next patch, in semundo_open() for example.
>> -undo_list = current->sysvsem.undo_list;
>> -if (!undo_list) {
>> -undo_list = kzalloc(sizeof(*undo_list), GFP_KERNEL);
>> +/* we must alloc a new one */
>> +undo_list = kmalloc(sizeof(*undo_list), GFP_KERNEL);
>> if (undo_list == NULL)
>> return -ENOMEM;
>> +
>> +task_lock(tsk);
>> +
>> +/* check again if there is an undo_list for this task */
>> +if (tsk->sysvsem.undo_list) {
>> +if (tsk != current)
>> +atomic_inc(&tsk->sysvsem.undo_list->refcnt);
>> +task_unlock(tsk);
>> +kfree(undo_list);
>> +goto out;
>> +}
>> +
>> spin_lock_init(&undo_list->lock);
>> -atomic_set(&undo_list->refcnt, 1);
>> -undo_list->ns = get_ipc_ns(current->nsproxy->ipc_ns);
>> -current->sysvsem.undo_list = undo_list;
>> +/*
>> + * If tsk is not current (meaning that current is creating
>> + * a semundo_list for a target task through procfs), and if
>> + * it's not being exited then refcnt must be 2: the target
>> + * task tsk + current.
>> + */
>> +if (tsk == current)
>> +atomic_set(&undo_list->refcnt, 1);
>> +else if (!(tsk->flags & PF_EXITING))
>> +atomic_set(&undo_list->refcnt, 2);
>&g
Re: [PATCH 2.6.24-rc8-mm1 12/15] (RFC) IPC/semaphores: make use of RCU to free the sem_undo_list
Serge E. Hallyn wrote:
> Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
>> From: Pierre Peiffer <[EMAIL PROTECTED]>
>>
>> Today, the sem_undo_list is freed when the last task using it exits.
>> There is no mechanism in place, that allows a safe concurrent access to
>> the sem_undo_list of a target task and protects efficiently against a
>> task-exit.
>>
>> That is okay for now as we don't need this.
>>
>> As I would like to provide a /proc interface to access this data, I need
>> such a safe access, without blocking the target task if possible.
>>
>> This patch proposes to introduce the use of RCU to delay the real free of
>> these sem_undo_list structures. They can then be accessed in a safe manner
>> by any tasks inside read critical section, this way:
>>
>> struct sem_undo_list *undo_list;
>> int ret;
>> ...
>> rcu_read_lock();
>> undo_list = rcu_dereference(task->sysvsem.undo_list);
>> if (undo_list)
>> ret = atomic_inc_not_zero(&undo_list->refcnt);
>> rcu_read_unlock();
>> ...
>> if (undo_list && ret) {
>> /* section where undo_list can be used quietly */
>> ...
>> }
>> ...
>
> And of course then
>
> if (atomic_dec_and_test(&undo_list->refcnt))
> free_semundo_list(undo_list);
>
> by that task.
>
I will precise this too.
>> Signed-off-by: Pierre Peiffer <[EMAIL PROTECTED]>
>
> Looks correct in terms of locking/refcounting.
>
> Signed-off-by: Serge Hallyn <[EMAIL PROTECTED]>
>
Thanks !
--
Pierre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.24-rc8-mm1 05/15] IPC/semaphores: remove one unused parameter from semctl_down()
Nadia Derbey wrote:
> [EMAIL PROTECTED] wrote:
>> From: Pierre Peiffer <[EMAIL PROTECTED]>
>>
>> semctl_down() takes one unused parameter: semnum.
>> This patch proposes to get rid of it.
>>
>> Signed-off-by: Pierre Peiffer <[EMAIL PROTECTED]>
>> Acked-by: Serge Hallyn <[EMAIL PROTECTED]>
>> ---
>> ipc/sem.c |6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> Index: b/ipc/sem.c
>> ===
>> --- a/ipc/sem.c
>> +++ b/ipc/sem.c
>> @@ -882,8 +882,8 @@ static inline unsigned long copy_semid_f
>> * to be held in write mode.
>> * NOTE: no locks must be held, the rw_mutex is taken inside this
>> function.
>> */
>> -static int semctl_down(struct ipc_namespace *ns, int semid, int semnum,
>> -int cmd, int version, union semun arg)
>> +static int semctl_down(struct ipc_namespace *ns, int semid,
>> + int cmd, int version, union semun arg)
>> {
>> struct sem_array *sma;
>> int err;
>> @@ -974,7 +974,7 @@ asmlinkage long sys_semctl (int semid, i
>> return err;
>> case IPC_RMID:
>> case IPC_SET:
>> -err = semctl_down(ns,semid,semnum,cmd,version,arg);
>> +err = semctl_down(ns, semid, cmd, version, arg);
>> return err;
>> default:
>> return -EINVAL;
>>
>
> Looks like semnum is only used in semctl_main(). Why not removing it
> from semctl_nolock() too?
Indeed.
In fact, I already fixed that in a previous patch, included in -mm since kernel
2.6.24.rc3-mm2 (patch named ipc-semaphores-consolidate-sem_stat-and.patch)
--
Pierre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.24-rc8-mm1 09/15] (RFC) IPC: new kernel API to change an ID
Kirill Korotaev wrote: > Why user space can need this API? for checkpointing only? I would say "at least for checkpointing"... ;) May be someone else may find an interest about this for something else. In fact, I'm sure that you have some interest in checkpointing; and thus, you have probably some ideas in mind; but whatever the solution you will propose, I'm pretty sure that I could say the same thing for your solution. And what I finally think is: even if it's for "checkpointing only", if many people are interested by this, it may be sufficient to push this ? > Then I would not consider it for inclusion until it is clear how to implement > checkpointing. > As for me personally - I'm against exporting such APIs, since they are not > needed in real-life user space applications and maintaining it forever for > compatibility doesn't worth it. Maintaining these patches is not a big deal, really, but this is not the main point; the "need in real life" (1) is in fact the main one, and then, the "is this solution the best one ?" (2) the second one. About (1), as said in my first mail, as the namespaces and containers are being integrated into the mainline kernel, checkpoint/restart is (or will be) the next need. About (2), my solution propose to do that, as much as possible from userspace, to minimize the kernel impact. Of course, this is subject to discussion. My opinion is that doing a full checkpoint/restart from kernel space will need lot of new specific and intrusive code; I'm not sure that this will be acceptable by the community. But this is my opinion only. Discusion is opened. > Also such APIs allow creation of non-GPL checkpointing in user-space, which > can be of concern as well. Honestly, I don't think this really a concern at all. I mean: I've never seen "this allows non-GPL binary and thus, this is bad" as an argument to reject a functionality, but I may be wrong, and thus, it can be discussed as well. I think the points (1) and (2) as stated above are the key ones. Pierre > Kirill > > > Pierre Peiffer wrote: >> Hi again, >> >> Thinking more about this, I think I must clarify why I choose this way. >> In fact, the idea of these patches is to provide the missing user APIs (or >> extend the existing ones) that allow to set or update _all_ properties of all >> IPCs, as needed in the case of the checkpoint/restart of an application (the >> current user API does not allow to specify an ID for a created IPC, for >> example). And this, without changing the existing API of course. >> >> And msgget(), semget() and shmget() does not have any parameter we can >> use to >> specify an ID. >> That's why I've decided to not change these routines and add a new >> control >> command, IP_SETID, with which we can can change the ID of an IPC. (that >> looks to >> me more straightforward and logical) >> >> Now, this patch is, in fact, only a preparation for the patch 10/15 >> which >> really complete the user API by adding this IPC_SETID command. >> >> (... continuing below ...) >> >> Alexey Dobriyan wrote: >>> On Tue, Jan 29, 2008 at 05:02:38PM +0100, [EMAIL PROTECTED] wrote: >>>> This patch provides three new API to change the ID of an existing >>>> System V IPCs. >>>> >>>> These APIs are: >>>>long msg_chid(struct ipc_namespace *ns, int id, int newid); >>>>long sem_chid(struct ipc_namespace *ns, int id, int newid); >>>>long shm_chid(struct ipc_namespace *ns, int id, int newid); >>>> >>>> They return 0 or an error code in case of failure. >>>> >>>> They may be useful for setting a specific ID for an IPC when preparing >>>> a restart operation. >>>> >>>> To be successful, the following rules must be respected: >>>> - the IPC exists (of course...) >>>> - the new ID must satisfy the ID computation rule. >>>> - the entry in the idr corresponding to the new ID must be free. >>>> ipc/util.c | 48 >>>> >>>> ipc/util.h |1 + >>>> 8 files changed, 197 insertions(+) >>> For the record, OpenVZ uses "create with predefined ID" method which >>> leads to less code. For example, change at the end is all we want from >>> ipc/util.c . >> And in fact, you do that from kernel space, you don't have the constraint to >> fit >> the existing user API. >> Again, this patch, even if it presents a new kernel API, is in fact a >> preparation for the next patch which introduces a new user API. >> >> Do you think that this could fit your need ? >> > > -- Pierre Peiffer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.24-rc8-mm1 14/15] (RFC) IPC/semaphores: prepare semundo code to work on another task than current
Serge E. Hallyn wrote:
> Quoting Pierre Peiffer ([EMAIL PROTECTED]):
>>
>> Serge E. Hallyn wrote:
>>> Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
>>>> From: Pierre Peiffer <[EMAIL PROTECTED]>
>>>>
>>>> In order to modify the semundo-list of a task from procfs, we must be able
>>>> to
>>>> work on any target task.
>>>> But all the existing code playing with the semundo-list, currently works
>>>> only on the 'current' task, and does not allow to specify any target task.
>>>>
>>>> This patch changes all these routines to allow them to work on a specified
>>>> task, passed in parameter, instead of current.
>>>>
>>>> This is mainly a preparation for the semundo_write() operation, on the
>>>> /proc//semundo file, as provided in the next patch.
>>>>
>>>> Signed-off-by: Pierre Peiffer <[EMAIL PROTECTED]>
>>>> ---
>>>>
>>>> ipc/sem.c | 90
>>>> ++
>>>> 1 file changed, 68 insertions(+), 22 deletions(-)
>>>>
>>>> Index: b/ipc/sem.c
>>>> ===
>>>> --- a/ipc/sem.c
>>>> +++ b/ipc/sem.c
>>>> @@ -1017,8 +1017,9 @@ asmlinkage long sys_semctl (int semid, i
>>>> }
>>>>
>>>> /* If the task doesn't already have a undo_list, then allocate one
>>>> - * here. We guarantee there is only one thread using this undo list,
>>>> - * and current is THE ONE
>>>> + * here.
>>>> + * The target task (tsk) is current in the general case, except when
>>>> + * accessed from the procfs (ie when writting to /proc//semundo)
>>>> *
>>>> * If this allocation and assignment succeeds, but later
>>>> * portions of this code fail, there is no need to free the sem_undo_list.
>>>> @@ -1026,22 +1027,60 @@ asmlinkage long sys_semctl (int semid, i
>>>> * at exit time.
>>>> *
>>>> * This can block, so callers must hold no locks.
>>>> + *
>>>> + * Note: task_lock is used to synchronize 1. several possible concurrent
>>>> + * creations and 2. the free of the undo_list (done when the task using it
>>>> + * exits). In the second case, we check the PF_EXITING flag to not create
>>>> + * an undo_list for a task which has exited.
>>>> + * If there already is an undo_list for this task, there is no need
>>>> + * to held the task-lock to retrieve it, as the pointer can not change
>>>> + * afterwards.
>>>> */
>>>> -static inline int get_undo_list(struct sem_undo_list **undo_listp)
>>>> +static inline int get_undo_list(struct task_struct *tsk,
>>>> + struct sem_undo_list **ulp)
>>>> {
>>>> - struct sem_undo_list *undo_list;
>>>> + if (tsk->sysvsem.undo_list == NULL) {
>>>> + struct sem_undo_list *undo_list;
>>> Hmm, this is weird. If there was no undo_list and
>>> tsk!=current, you set the refcnt to 2. But if there was an
>>> undo list and tsk!=current, where do you inc the refcnt?
>>>
>> I inc it outside this function, as I don't call get_undo_list() if there is
>> an
>> undo_list.
>> This appears most clearly in the next patch, in semundo_open() for example.
>
> Ok, so however unlikely, there is a flow that could cause you a problem:
> T2 calls semundo_open() for T1. T1 does not yet have a semundolist.
> T2.semundo_open() calls get_undo_list, just then T1 creats its own
> semundo_list. T2 comes to top of get_undo_list() and see
> tsk->sysvsem.undo_list != NULL, simply returns a pointer to the
> undo_list. Now you never increment the count.
>
Right.
And yesterday, with more testing in the corners, I've found another issue: if I
use /proc/self/semundo, I don't have tsk != current and the refcnt is wrong too.
Thanks for finding this !
P.
>>>> - undo_list = current->sysvsem.undo_list;
>>>> - if (!undo_list) {
>>>> - undo_list = kzalloc(sizeof(*undo_list), GFP_KERNEL);
>>>> + /* we must alloc a new one */
>>>> + undo_list = kmalloc(sizeof(*undo_list), GFP_KERNEL);
>>>>if (undo_list == NULL)
>>>>return -ENOMEM;
>>>> +
>>>> + task_lock(tsk);
>
Re: [PATCH 2.6.24-rc8-mm1 00/15] IPC: code rewrite + new functionalities
Pavel Machek wrote: > Hi! > >> * Patches 9 to 15 propose to add some functionalities, and thus are >> submitted here for RFC, about both the interest and their implementation. >> These functionalities are: >> - Two new control-commands: >> . IPC_SETID: to change an IPC's id. >> . IPC_SETALL: behaves as IPC_SET, except that it also sets all time >>and pid values) >> - add a /proc//semundo file to read and write the undo values of >> some semaphores for a given process. >> >> As the namespaces and the "containers" are being integrated in the >> kernel, these functionalities may be a first step to implement the >> checkpoint/restart of an application: in fact the existing API does not allow >> to specify or to change an ID when creating an IPC, when restarting an >> application, and the times/pids values of each IPCs are also altered. May be >> someone may find another interest about this ? >> >> So again, comments are welcome. > > Checkpoint/restart is nice, but... sysV ipc is broken by design, do we > really want to extend it? If we want to support all kind of applications, yes, we must also support SysVipc. We must support all kernel subsystems at the end. I've started with IPC, because it's relatively simple and isolated. -- Pierre -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.24-mm1] error compiling net driver NE2000/NE1000
Hi,
When I compile the kernel 2.6.24-mm1 with:
CONFIG_NET_ISA=y
CONFIG_NE2000=y
I have the following compile error:
...
GEN .version
CHK include/linux/compile.h
UPD include/linux/compile.h
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
drivers/built-in.o: In function `ne_block_output':
linux-2.6.24-mm1/drivers/net/ne.c:797: undefined reference to `NS8390_init'
drivers/built-in.o: In function `ne_drv_resume':
linux-2.6.24-mm1/drivers/net/ne.c:858: undefined reference to `NS8390_init'
drivers/built-in.o: In function `ne_probe1':
linux-2.6.24-mm1/drivers/net/ne.c:539: undefined reference to `NS8390_init'
make[1]: *** [.tmp_vmlinux1] Error 1
make: *** [sub-make] Error 2
As I saw that the file 8390p.c is compiled for this driver, but not the file
8390.c which contains this function NS8390_init(), I fixed this error with
the following patch.
As NS8390p_init() does the same thing than NS8390_init(), I suppose that this
is the right fix ?
Signed-off-by: Pierre Peiffer <[EMAIL PROTECTED]>
---
drivers/net/ne.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: b/drivers/net/ne.c
===
--- a/drivers/net/ne.c
+++ b/drivers/net/ne.c
@@ -536,7 +536,7 @@ static int __init ne_probe1(struct net_d
#ifdef CONFIG_NET_POLL_CONTROLLER
dev->poll_controller = eip_poll;
#endif
- NS8390_init(dev, 0);
+ NS8390p_init(dev, 0);
ret = register_netdev(dev);
if (ret)
@@ -794,7 +794,7 @@ retry:
if (time_after(jiffies, dma_start + 2*HZ/100)) {
/* 20ms */
printk(KERN_WARNING "%s: timeout waiting for Tx
RDC.\n", dev->name);
ne_reset_8390(dev);
- NS8390_init(dev,1);
+ NS8390p_init(dev,1);
break;
}
@@ -855,7 +855,7 @@ static int ne_drv_resume(struct platform
if (netif_running(dev)) {
ne_reset_8390(dev);
- NS8390_init(dev, 1);
+ NS8390p_init(dev, 1);
netif_device_attach(dev);
}
return 0;
--
Pierre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] at91_mci: minor cleanup
On Wed, 30 Jan 2008 17:45:48 +0100 Nicolas Ferre <[EMAIL PROTECTED]> wrote: > From: Marc Pignat <[EMAIL PROTECTED]> > > MMC_POWER_ON is a noop, no need to set the power pin again. > > Signed-off-by: Marc Pignat <[EMAIL PROTECTED]> > Signed-off-by: Nicolas Ferre <[EMAIL PROTECTED]> > --- Perhaps also a WARN_ON() or something in the default case to catch bad invokations? Rgds Pierre signature.asc Description: PGP signature
Re: Areca hardware RAID / first-ever SCSI bus reset: am I about to lose this disk controller?
Yes. When in degraded mode, timeout should be raised to five minutes or so. When in clean mode, timeout should be a tunable in milliseconds. Commercial RAIDs offer timeouts in ranges like 200ms - 2s. Plus a disk which was kicked that way should be scanned for and re-added if possible. With write-intent bitmaps, that would make RAIDs with aging disks or cables much more solid. Also, non-degraded mode: Skip loop resets. Skip all resets actually, if possible. Just kick the disk. Degraded mode: Perform loop resets as it is now. A hung-up controller would then cause an array to degrade, but won't hang indefinitely. Granted, always doing loop resets keeps the array non-degraded, but a crashed controller is rare whilst failing disks are common. linux-scsi and linux-raid should talk about this one day to make it happen. Requires a bit of interfacing between the layers. On 02.10.2012 00:53, Chris Murphy wrote: On Oct 1, 2012, at 3:33 PM, Pierre Beck wrote: It's particularly annoying when in RAID and the disk could've simply been kicked within few seconds. Something that needs improvement IMHO. Except that while this helps with faster recovery, you're now degraded. You wouldn't want this "fast recovery" behavior if you're at your critical number of disks remaining or you lose the array upon a few seconds worth of subsequent problems. So we kinda need context specific behavior. Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.24-mm1 8/8] (resend) IPC: consolidate all xxxctl_down() functions
semctl_down(), msgctl_down() and shmctl_down() are used to handle the same
set of commands for each kind of IPC. They all start to do the same job (they
retrieve the ipc and do some permission checks) before handling the commands
on their own.
This patch proposes to consolidate this by moving these same pieces of code
into one common function called ipcctl_pre_down().
It simplifies a little these xxxctl_down() functions and increases a little
the maintainability.
Signed-off-by: Pierre Peiffer <[EMAIL PROTECTED]>
Acked-by: Serge Hallyn <[EMAIL PROTECTED]>
---
ipc/msg.c | 48 +---
ipc/sem.c | 42 --
ipc/shm.c | 42 --
ipc/util.c | 51 +++
ipc/util.h |2 ++
5 files changed, 66 insertions(+), 119 deletions(-)
Index: b/ipc/sem.c
===
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -141,21 +141,6 @@ void __init sem_init (void)
}
/*
- * This routine is called in the paths where the rw_mutex is held to protect
- * access to the idr tree.
- */
-static inline struct sem_array *sem_lock_check_down(struct ipc_namespace *ns,
- int id)
-{
- struct kern_ipc_perm *ipcp = ipc_lock_check_down(&sem_ids(ns), id);
-
- if (IS_ERR(ipcp))
- return (struct sem_array *)ipcp;
-
- return container_of(ipcp, struct sem_array, sem_perm);
-}
-
-/*
* sem_lock_(check_) routines are called in the paths where the rw_mutex
* is not held.
*/
@@ -878,31 +863,12 @@ static int semctl_down(struct ipc_namesp
if (copy_semid_from_user(&semid64, arg.buf, version))
return -EFAULT;
}
- down_write(&sem_ids(ns).rw_mutex);
- sma = sem_lock_check_down(ns, semid);
- if (IS_ERR(sma)) {
- err = PTR_ERR(sma);
- goto out_up;
- }
-
- ipcp = &sma->sem_perm;
- err = audit_ipc_obj(ipcp);
- if (err)
- goto out_unlock;
+ ipcp = ipcctl_pre_down(&sem_ids(ns), semid, cmd, &semid64.sem_perm, 0);
+ if (IS_ERR(ipcp))
+ return PTR_ERR(ipcp);
- if (cmd == IPC_SET) {
- err = audit_ipc_set_perm(0, semid64.sem_perm.uid,
-semid64.sem_perm.gid,
-semid64.sem_perm.mode);
- if (err)
- goto out_unlock;
- }
- if (current->euid != ipcp->cuid &&
- current->euid != ipcp->uid && !capable(CAP_SYS_ADMIN)) {
- err=-EPERM;
- goto out_unlock;
- }
+ sma = container_of(ipcp, struct sem_array, sem_perm);
err = security_sem_semctl(sma, cmd);
if (err)
Index: b/ipc/util.c
===
--- a/ipc/util.c
+++ b/ipc/util.c
@@ -824,6 +824,57 @@ void ipc_update_perm(struct ipc64_perm *
| (in->mode & S_IRWXUGO);
}
+/**
+ * ipcctl_pre_down - retrieve an ipc and check permissions for some IPC_XXX cmd
+ * @ids: the table of ids where to look for the ipc
+ * @id: the id of the ipc to retrieve
+ * @cmd: the cmd to check
+ * @perm: the permission to set
+ * @extra_perm: one extra permission parameter used by msq
+ *
+ * This function does some common audit and permissions check for some IPC_XXX
+ * cmd and is called from semctl_down, shmctl_down and msgctl_down.
+ * It must be called without any lock held and
+ * - retrieves the ipc with the given id in the given table.
+ * - performs some audit and permission check, depending on the given cmd
+ * - returns the ipc with both ipc and rw_mutex locks held in case of success
+ *or an err-code without any lock held otherwise.
+ */
+struct kern_ipc_perm *ipcctl_pre_down(struct ipc_ids *ids, int id, int cmd,
+ struct ipc64_perm *perm, int extrat_perm)
+{
+ struct kern_ipc_perm *ipcp;
+ int err;
+
+ down_write(&ids->rw_mutex);
+ ipcp = ipc_lock_check_down(ids, id);
+ if (IS_ERR(ipcp)) {
+ err = PTR_ERR(ipcp);
+ goto out_up;
+ }
+
+ err = audit_ipc_obj(ipcp);
+ if (err)
+ goto out_unlock;
+
+ if (cmd == IPC_SET) {
+ err = audit_ipc_set_perm(extrat_perm, perm->uid,
+perm->gid, perm->mode);
+ if (err)
+ goto out_unlock;
+ }
+ if (current->euid == ipcp->cuid ||
+ current->euid == ipcp->uid || capable(CAP_SYS_ADMIN))
+ return ipcp;
+
+ err = -EPERM;
+out_unlock:
+ ipc_unlock(ipcp);
+out_up:
+ up_write(&ids-&
[PATCH 2.6.24-mm1 6/8] (resend) IPC: get rid of the use *_setbuf structure.
From: Pierre Peiffer <[EMAIL PROTECTED]>
All IPCs make use of an intermetiate *_setbuf structure to handle the
IPC_SET command. This is not really needed and, moreover, it complicates
a little bit the code.
This patch get rid of the use of it and uses directly the semid64_ds/
msgid64_ds/shmid64_ds structure.
In addition of removing one struture declaration, it also simplifies
and improves a little bit the common 64-bits path.
Signed-off-by: Pierre Peiffer <[EMAIL PROTECTED]>
Acked-by: Serge Hallyn <[EMAIL PROTECTED]>
---
ipc/msg.c | 51 ++-
ipc/sem.c | 40 ++--
ipc/shm.c | 41 ++---
3 files changed, 46 insertions(+), 86 deletions(-)
Index: b/ipc/msg.c
===
--- a/ipc/msg.c
+++ b/ipc/msg.c
@@ -388,31 +388,14 @@ copy_msqid_to_user(void __user *buf, str
}
}
-struct msq_setbuf {
- unsigned long qbytes;
- uid_t uid;
- gid_t gid;
- mode_t mode;
-};
-
static inline unsigned long
-copy_msqid_from_user(struct msq_setbuf *out, void __user *buf, int version)
+copy_msqid_from_user(struct msqid64_ds *out, void __user *buf, int version)
{
switch(version) {
case IPC_64:
- {
- struct msqid64_ds tbuf;
-
- if (copy_from_user(&tbuf, buf, sizeof(tbuf)))
+ if (copy_from_user(out, buf, sizeof(*out)))
return -EFAULT;
-
- out->qbytes = tbuf.msg_qbytes;
- out->uid= tbuf.msg_perm.uid;
- out->gid= tbuf.msg_perm.gid;
- out->mode = tbuf.msg_perm.mode;
-
return 0;
- }
case IPC_OLD:
{
struct msqid_ds tbuf_old;
@@ -420,14 +403,14 @@ copy_msqid_from_user(struct msq_setbuf *
if (copy_from_user(&tbuf_old, buf, sizeof(tbuf_old)))
return -EFAULT;
- out->uid= tbuf_old.msg_perm.uid;
- out->gid= tbuf_old.msg_perm.gid;
- out->mode = tbuf_old.msg_perm.mode;
+ out->msg_perm.uid = tbuf_old.msg_perm.uid;
+ out->msg_perm.gid = tbuf_old.msg_perm.gid;
+ out->msg_perm.mode = tbuf_old.msg_perm.mode;
if (tbuf_old.msg_qbytes == 0)
- out->qbytes = tbuf_old.msg_lqbytes;
+ out->msg_qbytes = tbuf_old.msg_lqbytes;
else
- out->qbytes = tbuf_old.msg_qbytes;
+ out->msg_qbytes = tbuf_old.msg_qbytes;
return 0;
}
@@ -445,12 +428,12 @@ static int msgctl_down(struct ipc_namesp
struct msqid_ds __user *buf, int version)
{
struct kern_ipc_perm *ipcp;
- struct msq_setbuf setbuf;
+ struct msqid64_ds msqid64;
struct msg_queue *msq;
int err;
if (cmd == IPC_SET) {
- if (copy_msqid_from_user(&setbuf, buf, version))
+ if (copy_msqid_from_user(&msqid64, buf, version))
return -EFAULT;
}
@@ -468,8 +451,10 @@ static int msgctl_down(struct ipc_namesp
goto out_unlock;
if (cmd == IPC_SET) {
- err = audit_ipc_set_perm(setbuf.qbytes, setbuf.uid, setbuf.gid,
-setbuf.mode);
+ err = audit_ipc_set_perm(msqid64.msg_qbytes,
+msqid64.msg_perm.uid,
+msqid64.msg_perm.gid,
+msqid64.msg_perm.mode);
if (err)
goto out_unlock;
}
@@ -491,18 +476,18 @@ static int msgctl_down(struct ipc_namesp
freeque(ns, ipcp);
goto out_up;
case IPC_SET:
- if (setbuf.qbytes > ns->msg_ctlmnb &&
+ if (msqid64.msg_qbytes > ns->msg_ctlmnb &&
!capable(CAP_SYS_RESOURCE)) {
err = -EPERM;
goto out_unlock;
}
- msq->q_qbytes = setbuf.qbytes;
+ msq->q_qbytes = msqid64.msg_qbytes;
- ipcp->uid = setbuf.uid;
- ipcp->gid = setbuf.gid;
+ ipcp->uid = msqid64.msg_perm.uid;
+ ipcp->gid = msqid64.msg_perm.gid;
ipcp->mode = (ipcp->mode & ~S_IRWXUGO) |
-(S_IRWXUGO & setbuf.mode);
+(S_IRWXUGO & msqid64.msg_perm.mode);
msq->
[PATCH 2.6.24-mm1 3/8] (resend) IPC/message queues: introduce msgctl_down
From: Pierre Peiffer <[EMAIL PROTECTED]>
Currently, sys_msgctl is not easy to read.
This patch tries to improve that by introducing the msgctl_down function
to handle all commands requiring the rwmutex to be taken in write mode
(ie IPC_SET and IPC_RMID for now). It is the equivalent function of
semctl_down for message queues.
This greatly changes the readability of sys_msgctl and also harmonizes
the way these commands are handled among all IPCs.
Signed-off-by: Pierre Peiffer <[EMAIL PROTECTED]>
Acked-by: Serge Hallyn <[EMAIL PROTECTED]>
---
ipc/msg.c | 162 ++
1 file changed, 89 insertions(+), 73 deletions(-)
Index: b/ipc/msg.c
===
--- a/ipc/msg.c
+++ b/ipc/msg.c
@@ -436,10 +436,95 @@ copy_msqid_from_user(struct msq_setbuf *
}
}
-asmlinkage long sys_msgctl(int msqid, int cmd, struct msqid_ds __user *buf)
+/*
+ * This function handles some msgctl commands which require the rw_mutex
+ * to be held in write mode.
+ * NOTE: no locks must be held, the rw_mutex is taken inside this function.
+ */
+static int msgctl_down(struct ipc_namespace *ns, int msqid, int cmd,
+ struct msqid_ds __user *buf, int version)
{
struct kern_ipc_perm *ipcp;
- struct msq_setbuf uninitialized_var(setbuf);
+ struct msq_setbuf setbuf;
+ struct msg_queue *msq;
+ int err;
+
+ if (cmd == IPC_SET) {
+ if (copy_msqid_from_user(&setbuf, buf, version))
+ return -EFAULT;
+ }
+
+ down_write(&msg_ids(ns).rw_mutex);
+ msq = msg_lock_check_down(ns, msqid);
+ if (IS_ERR(msq)) {
+ err = PTR_ERR(msq);
+ goto out_up;
+ }
+
+ ipcp = &msq->q_perm;
+
+ err = audit_ipc_obj(ipcp);
+ if (err)
+ goto out_unlock;
+
+ if (cmd == IPC_SET) {
+ err = audit_ipc_set_perm(setbuf.qbytes, setbuf.uid, setbuf.gid,
+setbuf.mode);
+ if (err)
+ goto out_unlock;
+ }
+
+ if (current->euid != ipcp->cuid &&
+ current->euid != ipcp->uid &&
+ !capable(CAP_SYS_ADMIN)) {
+ /* We _could_ check for CAP_CHOWN above, but we don't */
+ err = -EPERM;
+ goto out_unlock;
+ }
+
+ err = security_msg_queue_msgctl(msq, cmd);
+ if (err)
+ goto out_unlock;
+
+ switch (cmd) {
+ case IPC_RMID:
+ freeque(ns, ipcp);
+ goto out_up;
+ case IPC_SET:
+ if (setbuf.qbytes > ns->msg_ctlmnb &&
+ !capable(CAP_SYS_RESOURCE)) {
+ err = -EPERM;
+ goto out_unlock;
+ }
+
+ msq->q_qbytes = setbuf.qbytes;
+
+ ipcp->uid = setbuf.uid;
+ ipcp->gid = setbuf.gid;
+ ipcp->mode = (ipcp->mode & ~S_IRWXUGO) |
+(S_IRWXUGO & setbuf.mode);
+ msq->q_ctime = get_seconds();
+ /* sleeping receivers might be excluded by
+* stricter permissions.
+*/
+ expunge_all(msq, -EAGAIN);
+ /* sleeping senders might be able to send
+* due to a larger queue size.
+*/
+ ss_wakeup(&msq->q_senders, 0);
+ break;
+ default:
+ err = -EINVAL;
+ }
+out_unlock:
+ msg_unlock(msq);
+out_up:
+ up_write(&msg_ids(ns).rw_mutex);
+ return err;
+}
+
+asmlinkage long sys_msgctl(int msqid, int cmd, struct msqid_ds __user *buf)
+{
struct msg_queue *msq;
int err, version;
struct ipc_namespace *ns;
@@ -535,82 +620,13 @@ asmlinkage long sys_msgctl(int msqid, in
return success_return;
}
case IPC_SET:
- if (!buf)
- return -EFAULT;
- if (copy_msqid_from_user(&setbuf, buf, version))
- return -EFAULT;
- break;
case IPC_RMID:
- break;
+ err = msgctl_down(ns, msqid, cmd, buf, version);
+ return err;
default:
return -EINVAL;
}
- down_write(&msg_ids(ns).rw_mutex);
- msq = msg_lock_check_down(ns, msqid);
- if (IS_ERR(msq)) {
- err = PTR_ERR(msq);
- goto out_up;
- }
-
- ipcp = &msq->q_perm;
-
- err = audit_ipc_obj(ipcp);
- if (err)
- goto out_unlock_up;
- if (cmd == IPC_SET) {
- err = audit_ipc_set_perm(setbuf.qbytes, setbuf.uid, setbuf.gid,
-setbuf.mod
[PATCH 2.6.24-mm1 2/8] (resend) IPC/shared memory: introduce shmctl_down
From: Pierre Peiffer <[EMAIL PROTECTED]>
Currently, the way the different commands are handled in sys_shmctl
introduces some duplicated code.
This patch introduces the shmctl_down function to handle all the commands
requiring the rwmutex to be taken in write mode (ie IPC_SET and IPC_RMID
for now). It is the equivalent function of semctl_down for shared
memory.
This removes some duplicated code for handling these both commands
and harmonizes the way they are handled among all IPCs.
Signed-off-by: Pierre Peiffer <[EMAIL PROTECTED]>
Acked-by: Serge Hallyn <[EMAIL PROTECTED]>
---
ipc/shm.c | 160 +++---
1 file changed, 72 insertions(+), 88 deletions(-)
Index: b/ipc/shm.c
===
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -617,10 +617,78 @@ static void shm_get_stat(struct ipc_name
}
}
-asmlinkage long sys_shmctl (int shmid, int cmd, struct shmid_ds __user *buf)
+/*
+ * This function handles some shmctl commands which require the rw_mutex
+ * to be held in write mode.
+ * NOTE: no locks must be held, the rw_mutex is taken inside this function.
+ */
+static int shmctl_down(struct ipc_namespace *ns, int shmid, int cmd,
+ struct shmid_ds __user *buf, int version)
{
+ struct kern_ipc_perm *ipcp;
struct shm_setbuf setbuf;
struct shmid_kernel *shp;
+ int err;
+
+ if (cmd == IPC_SET) {
+ if (copy_shmid_from_user(&setbuf, buf, version))
+ return -EFAULT;
+ }
+
+ down_write(&shm_ids(ns).rw_mutex);
+ shp = shm_lock_check_down(ns, shmid);
+ if (IS_ERR(shp)) {
+ err = PTR_ERR(shp);
+ goto out_up;
+ }
+
+ ipcp = &shp->shm_perm;
+
+ err = audit_ipc_obj(ipcp);
+ if (err)
+ goto out_unlock;
+
+ if (cmd == IPC_SET) {
+ err = audit_ipc_set_perm(0, setbuf.uid,
+setbuf.gid, setbuf.mode);
+ if (err)
+ goto out_unlock;
+ }
+
+ if (current->euid != ipcp->uid &&
+ current->euid != ipcp->cuid &&
+ !capable(CAP_SYS_ADMIN)) {
+ err = -EPERM;
+ goto out_unlock;
+ }
+
+ err = security_shm_shmctl(shp, cmd);
+ if (err)
+ goto out_unlock;
+ switch (cmd) {
+ case IPC_RMID:
+ do_shm_rmid(ns, ipcp);
+ goto out_up;
+ case IPC_SET:
+ ipcp->uid = setbuf.uid;
+ ipcp->gid = setbuf.gid;
+ ipcp->mode = (ipcp->mode & ~S_IRWXUGO)
+ | (setbuf.mode & S_IRWXUGO);
+ shp->shm_ctim = get_seconds();
+ break;
+ default:
+ err = -EINVAL;
+ }
+out_unlock:
+ shm_unlock(shp);
+out_up:
+ up_write(&shm_ids(ns).rw_mutex);
+ return err;
+}
+
+asmlinkage long sys_shmctl(int shmid, int cmd, struct shmid_ds __user *buf)
+{
+ struct shmid_kernel *shp;
int err, version;
struct ipc_namespace *ns;
@@ -776,97 +844,13 @@ asmlinkage long sys_shmctl (int shmid, i
goto out;
}
case IPC_RMID:
- {
- /*
-* We cannot simply remove the file. The SVID states
-* that the block remains until the last person
-* detaches from it, then is deleted. A shmat() on
-* an RMID segment is legal in older Linux and if
-* we change it apps break...
-*
-* Instead we set a destroyed flag, and then blow
-* the name away when the usage hits zero.
-*/
- down_write(&shm_ids(ns).rw_mutex);
- shp = shm_lock_check_down(ns, shmid);
- if (IS_ERR(shp)) {
- err = PTR_ERR(shp);
- goto out_up;
- }
-
- err = audit_ipc_obj(&(shp->shm_perm));
- if (err)
- goto out_unlock_up;
-
- if (current->euid != shp->shm_perm.uid &&
- current->euid != shp->shm_perm.cuid &&
- !capable(CAP_SYS_ADMIN)) {
- err=-EPERM;
- goto out_unlock_up;
- }
-
- err = security_shm_shmctl(shp, cmd);
- if (err)
- goto out_unlock_up;
-
- do_shm_rmid(ns, &shp->shm_perm);
- up_write(&shm_ids(ns).rw_mutex);
- goto out;
- }
-
case IPC_SET:
- {
- if (!buf) {
- err = -EFAULT;
-
[PATCH 2.6.24-mm1 7/8] (resend) IPC: introduce ipc_update_perm()
From: Pierre Peiffer <[EMAIL PROTECTED]>
The IPC_SET command performs the same permission setting for all IPCs.
This patch introduces a common ipc_update_perm() function to update these
permissions and makes use of it for all IPCs.
Signed-off-by: Pierre Peiffer <[EMAIL PROTECTED]>
Acked-by: Serge Hallyn <[EMAIL PROTECTED]>
---
ipc/msg.c |5 +
ipc/sem.c |5 +
ipc/shm.c |5 +
ipc/util.c | 13 +
ipc/util.h |1 +
5 files changed, 17 insertions(+), 12 deletions(-)
Index: b/ipc/msg.c
===
--- a/ipc/msg.c
+++ b/ipc/msg.c
@@ -484,10 +484,7 @@ static int msgctl_down(struct ipc_namesp
msq->q_qbytes = msqid64.msg_qbytes;
- ipcp->uid = msqid64.msg_perm.uid;
- ipcp->gid = msqid64.msg_perm.gid;
- ipcp->mode = (ipcp->mode & ~S_IRWXUGO) |
-(S_IRWXUGO & msqid64.msg_perm.mode);
+ ipc_update_perm(&msqid64.msg_perm, ipcp);
msq->q_ctime = get_seconds();
/* sleeping receivers might be excluded by
* stricter permissions.
Index: b/ipc/sem.c
===
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -913,10 +913,7 @@ static int semctl_down(struct ipc_namesp
freeary(ns, ipcp);
goto out_up;
case IPC_SET:
- ipcp->uid = semid64.sem_perm.uid;
- ipcp->gid = semid64.sem_perm.gid;
- ipcp->mode = (ipcp->mode & ~S_IRWXUGO)
- | (semid64.sem_perm.mode & S_IRWXUGO);
+ ipc_update_perm(&semid64.sem_perm, ipcp);
sma->sem_ctime = get_seconds();
break;
default:
Index: b/ipc/shm.c
===
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -657,10 +657,7 @@ static int shmctl_down(struct ipc_namesp
do_shm_rmid(ns, ipcp);
goto out_up;
case IPC_SET:
- ipcp->uid = shmid64.shm_perm.uid;
- ipcp->gid = shmid64.shm_perm.gid;
- ipcp->mode = (ipcp->mode & ~S_IRWXUGO)
- | (shmid64.shm_perm.mode & S_IRWXUGO);
+ ipc_update_perm(&shmid64.shm_perm, ipcp);
shp->shm_ctim = get_seconds();
break;
default:
Index: b/ipc/util.c
===
--- a/ipc/util.c
+++ b/ipc/util.c
@@ -811,6 +811,19 @@ int ipcget(struct ipc_namespace *ns, str
return ipcget_public(ns, ids, ops, params);
}
+/**
+ * ipc_update_perm - update the permissions of an IPC.
+ * @in: the permission given as input.
+ * @out: the permission of the ipc to set.
+ */
+void ipc_update_perm(struct ipc64_perm *in, struct kern_ipc_perm *out)
+{
+ out->uid = in->uid;
+ out->gid = in->gid;
+ out->mode = (out->mode & ~S_IRWXUGO)
+ | (in->mode & S_IRWXUGO);
+}
+
#ifdef __ARCH_WANT_IPC_PARSE_VERSION
Index: b/ipc/util.h
===
--- a/ipc/util.h
+++ b/ipc/util.h
@@ -112,6 +112,7 @@ struct kern_ipc_perm *ipc_lock(struct ip
void kernel_to_ipc64_perm(struct kern_ipc_perm *in, struct ipc64_perm *out);
void ipc64_perm_to_ipc_perm(struct ipc64_perm *in, struct ipc_perm *out);
+void ipc_update_perm(struct ipc64_perm *in, struct kern_ipc_perm *out);
#if defined(__ia64__) || defined(__x86_64__) || defined(__hppa__) ||
defined(__XTENSA__)
/* On IA-64, we always use the "64-bit version" of the IPC structures. */
--
Pierre Peiffer
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.24-mm1 5/8] (resend) IPC/semaphores: remove one unused parameter from semctl_down()
From: Pierre Peiffer <[EMAIL PROTECTED]>
semctl_down() takes one unused parameter: semnum.
This patch proposes to get rid of it.
Signed-off-by: Pierre Peiffer <[EMAIL PROTECTED]>
Acked-by: Serge Hallyn <[EMAIL PROTECTED]>
---
ipc/sem.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: b/ipc/sem.c
===
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -880,8 +880,8 @@ static inline unsigned long copy_semid_f
* to be held in write mode.
* NOTE: no locks must be held, the rw_mutex is taken inside this function.
*/
-static int semctl_down(struct ipc_namespace *ns, int semid, int semnum,
- int cmd, int version, union semun arg)
+static int semctl_down(struct ipc_namespace *ns, int semid,
+ int cmd, int version, union semun arg)
{
struct sem_array *sma;
int err;
@@ -972,7 +972,7 @@ asmlinkage long sys_semctl (int semid, i
return err;
case IPC_RMID:
case IPC_SET:
- err = semctl_down(ns,semid,semnum,cmd,version,arg);
+ err = semctl_down(ns, semid, cmd, version, arg);
return err;
default:
return -EINVAL;
--
Pierre Peiffer
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.24-mm1 1/8] (resend) IPC/semaphores: code factorisation
From: Pierre Peiffer <[EMAIL PROTECTED]>
Trivial patch which adds some small locking functions and makes use of them
to factorize some part of the code and to make it cleaner.
Signed-off-by: Pierre Peiffer <[EMAIL PROTECTED]>
Acked-by: Serge Hallyn <[EMAIL PROTECTED]>
---
ipc/sem.c | 61 +++--
1 file changed, 31 insertions(+), 30 deletions(-)
Index: b/ipc/sem.c
===
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -180,6 +180,25 @@ static inline struct sem_array *sem_lock
return container_of(ipcp, struct sem_array, sem_perm);
}
+static inline void sem_lock_and_putref(struct sem_array *sma)
+{
+ ipc_lock_by_ptr(&sma->sem_perm);
+ ipc_rcu_putref(sma);
+}
+
+static inline void sem_getref_and_unlock(struct sem_array *sma)
+{
+ ipc_rcu_getref(sma);
+ ipc_unlock(&(sma)->sem_perm);
+}
+
+static inline void sem_putref(struct sem_array *sma)
+{
+ ipc_lock_by_ptr(&sma->sem_perm);
+ ipc_rcu_putref(sma);
+ ipc_unlock(&(sma)->sem_perm);
+}
+
static inline void sem_rmid(struct ipc_namespace *ns, struct sem_array *s)
{
ipc_rmid(&sem_ids(ns), &s->sem_perm);
@@ -698,19 +717,15 @@ static int semctl_main(struct ipc_namesp
int i;
if(nsems > SEMMSL_FAST) {
- ipc_rcu_getref(sma);
- sem_unlock(sma);
+ sem_getref_and_unlock(sma);
sem_io = ipc_alloc(sizeof(ushort)*nsems);
if(sem_io == NULL) {
- ipc_lock_by_ptr(&sma->sem_perm);
- ipc_rcu_putref(sma);
- sem_unlock(sma);
+ sem_putref(sma);
return -ENOMEM;
}
- ipc_lock_by_ptr(&sma->sem_perm);
- ipc_rcu_putref(sma);
+ sem_lock_and_putref(sma);
if (sma->sem_perm.deleted) {
sem_unlock(sma);
err = -EIDRM;
@@ -731,38 +746,30 @@ static int semctl_main(struct ipc_namesp
int i;
struct sem_undo *un;
- ipc_rcu_getref(sma);
- sem_unlock(sma);
+ sem_getref_and_unlock(sma);
if(nsems > SEMMSL_FAST) {
sem_io = ipc_alloc(sizeof(ushort)*nsems);
if(sem_io == NULL) {
- ipc_lock_by_ptr(&sma->sem_perm);
- ipc_rcu_putref(sma);
- sem_unlock(sma);
+ sem_putref(sma);
return -ENOMEM;
}
}
if (copy_from_user (sem_io, arg.array, nsems*sizeof(ushort))) {
- ipc_lock_by_ptr(&sma->sem_perm);
- ipc_rcu_putref(sma);
- sem_unlock(sma);
+ sem_putref(sma);
err = -EFAULT;
goto out_free;
}
for (i = 0; i < nsems; i++) {
if (sem_io[i] > SEMVMX) {
- ipc_lock_by_ptr(&sma->sem_perm);
- ipc_rcu_putref(sma);
- sem_unlock(sma);
+ sem_putref(sma);
err = -ERANGE;
goto out_free;
}
}
- ipc_lock_by_ptr(&sma->sem_perm);
- ipc_rcu_putref(sma);
+ sem_lock_and_putref(sma);
if (sma->sem_perm.deleted) {
sem_unlock(sma);
err = -EIDRM;
@@ -1042,14 +1049,11 @@ static struct sem_undo *find_undo(struct
return ERR_PTR(PTR_ERR(sma));
nsems = sma->sem_nsems;
- ipc_rcu_getref(sma);
- sem_unlock(sma);
+ sem_getref_and_unlock(sma);
new = kzalloc(sizeof(struct sem_undo) + sizeof(short)*nsems,
GFP_KERNEL);
if (!new) {
- ipc_lock_by_ptr(&sma->sem_perm);
- ipc_rcu_putref(sma);
- sem_unlock(sma);
+ sem_putref(sma);
return ERR_PTR(-ENOMEM);
}
new->semadj = (short *) &new[1];
@@ -1060,13 +1064,10 @@ static struct sem_undo *find_undo(struct
if (un) {
spin_unlock(&ulp->lock);
kfree(new);
- ipc_lock_by_ptr(&sma->sem_perm);
- ipc_rcu_putref(sma);
- sem_u
[PATCH 2.6.24-mm1 0/8] (resend) IPC: code rewrite
Hi Andrew, This is a resend of the first part of the patchset sent 2 weeks ago. This is the part about the IPC which (again) proposes to consolidate some part of the existing code. It does not change the behavior of the existing code, but improves it in term of readability and maintainability as it consolidates it a little. As there was no objection, I think you can include them in your -mm tree. The patchset applies on top of "2.6.24-mm1 + previous patches about IPC" sent the last days (ie Nadia's patches + mine). For information, here is the global diffstat: ipc/msg.c | 184 +++-- ipc/sem.c | 156 ++- ipc/shm.c | 176 ++ ipc/util.c | 64 + ipc/util.h |3 5 files changed, 249 insertions(+), 334 deletions(-) and the size of the resulting kernel: - without the patchset: $ size obj/vmlinux.ori textdata bss dec hex filename 1903257 175820 122880 2201957 219965 obj/vmlinux.ori - with the patchset: $ size obj/vmlinux textdata bss dec hex filename 1902917 175820 122880 2201617 219811 obj/vmlinux -- Pierre Peiffer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.24-mm1 4/8] (resend) IPC/semaphores: move the rwmutex handling inside semctl_down
From: Pierre Peiffer <[EMAIL PROTECTED]>
semctl_down is called with the rwmutex (the one which protects the
list of ipcs) taken in write mode.
This patch moves this rwmutex taken in write-mode inside semctl_down.
This has the advantages of reducing a little bit the window during
which this rwmutex is taken, clarifying sys_semctl, and finally of
having a coherent behaviour with [shm|msg]ctl_down
Signed-off-by: Pierre Peiffer <[EMAIL PROTECTED]>
Acked-by: Serge Hallyn <[EMAIL PROTECTED]>
---
ipc/sem.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
Index: b/ipc/sem.c
===
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -875,6 +875,11 @@ static inline unsigned long copy_semid_f
}
}
+/*
+ * This function handles some semctl commands which require the rw_mutex
+ * to be held in write mode.
+ * NOTE: no locks must be held, the rw_mutex is taken inside this function.
+ */
static int semctl_down(struct ipc_namespace *ns, int semid, int semnum,
int cmd, int version, union semun arg)
{
@@ -887,9 +892,12 @@ static int semctl_down(struct ipc_namesp
if(copy_semid_from_user (&setbuf, arg.buf, version))
return -EFAULT;
}
+ down_write(&sem_ids(ns).rw_mutex);
sma = sem_lock_check_down(ns, semid);
- if (IS_ERR(sma))
- return PTR_ERR(sma);
+ if (IS_ERR(sma)) {
+ err = PTR_ERR(sma);
+ goto out_up;
+ }
ipcp = &sma->sem_perm;
@@ -915,26 +923,22 @@ static int semctl_down(struct ipc_namesp
switch(cmd){
case IPC_RMID:
freeary(ns, ipcp);
- err = 0;
- break;
+ goto out_up;
case IPC_SET:
ipcp->uid = setbuf.uid;
ipcp->gid = setbuf.gid;
ipcp->mode = (ipcp->mode & ~S_IRWXUGO)
| (setbuf.mode & S_IRWXUGO);
sma->sem_ctime = get_seconds();
- sem_unlock(sma);
- err = 0;
break;
default:
- sem_unlock(sma);
err = -EINVAL;
- break;
}
- return err;
out_unlock:
sem_unlock(sma);
+out_up:
+ up_write(&sem_ids(ns).rw_mutex);
return err;
}
@@ -968,9 +972,7 @@ asmlinkage long sys_semctl (int semid, i
return err;
case IPC_RMID:
case IPC_SET:
- down_write(&sem_ids(ns).rw_mutex);
err = semctl_down(ns,semid,semnum,cmd,version,arg);
- up_write(&sem_ids(ns).rw_mutex);
return err;
default:
return -EINVAL;
--
Pierre Peiffer
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 v2 5/5] Atmel MCI: Driver for Atmel on-chip MMC controllers
On Tue, 29 Jan 2008 19:10:13 +0100
Haavard Skinnemoen <[EMAIL PROTECTED]> wrote:
> +
> +/* Those printks take an awful lot of time... */
> +#ifndef DEBUG
> +static unsigned int fmax = 1500U;
> +#else
> +static unsigned int fmax = 100U;
> +#endif
> +module_param(fmax, uint, 0444);
> +MODULE_PARM_DESC(fmax, "Max frequency in Hz of the MMC bus clock");
> +
I think this was meant to go away.
> +
> +static int req_dbg_open(struct inode *inode, struct file *file)
> +{
And this should go into the core.
> +
> +static int __exit atmci_remove(struct platform_device *pdev)
> +{
> + struct atmel_mci *host = platform_get_drvdata(pdev);
> +
> + platform_set_drvdata(pdev, NULL);
> +
> + if (host) {
> + atmci_cleanup_debugfs(host);
> +
> + if (host->detect_pin >= 0) {
> + free_irq(gpio_to_irq(host->detect_pin),host->mmc);
> + cancel_delayed_work(&host->mmc->detect);
I also pointed this out. mmc_remove_host() will synchronize this for
you.
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.24-mm1 1/8] (resend) IPC/semaphores: code factorisation
On Feb 13, 2008 9:07 PM, Alexey Dobriyan <[EMAIL PROTECTED]> wrote: > On Tue, Feb 12, 2008 at 05:13:41PM +0100, [EMAIL PROTECTED] wrote: > > Trivial patch which adds some small locking functions and makes use of them > > to factorize some part of the code and to make it cleaner. > > What's wrong with consolidation activity in general is that one need to > follow tags many times to realise what on earth function really does. Funny... What's right with consolidation in general is that it avoids the readers to read again and again the same piece of code and helps them to focus on what the code really does. -- Pierre -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.24-mm1 0/8] (resend) IPC: code rewrite
Andi Kleen wrote: > [EMAIL PROTECTED] writes: > >> This is a resend of the first part of the patchset sent 2 weeks >> ago. This is the part about the IPC which (again) proposes to consolidate >> some part of the existing code. >> >> It does not change the behavior of the existing code, but >> improves it in term of readability and maintainability as it consolidates it >> a little. As there was no objection, I think you can include them in your >> -mm tree. >> >> The patchset applies on top of "2.6.24-mm1 + previous patches about >> IPC" sent the last days (ie Nadia's patches + mine). > > While I have not read everything in detail from a quick overview > the whole patch series looks like a nice and valuable cleanup to me. > > I was a bit sceptical about all the interface enhancements your original > patchkit had, but this one looks just fine. > Thanks Andi for spending time on this review. All kind of comments (positive or negative) are always welcome to make progress, but of course, I particularly appreciate such positive feedbacks ;) -- Pierre -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.24-mm1] error compiling net driver NE2000/NE1000
Hi,
I don't know if I have to warn on this or not, but as I didn't find any
discussion, it's probably better to mention it: the compiling error reported
below (or here: http://lkml.org/lkml/2008/2/4/173 ) does not seem to be
corrected in 2.6.25-rc2.mm1... So, I don't know if a fix is going on somewhere
or if the bug has fallen in a black hole.
(In the original mail, I've proposed a patch as a quick fix, but I don't know if
it can be considered as a definitive correction or not)
Thanks,
P.
Andrew Morton wrote:
> On Mon, 4 Feb 2008 16:29:21 +0100
> Pierre Peiffer <[EMAIL PROTECTED]> wrote:
>
>> Hi,
>>
>> When I compile the kernel 2.6.24-mm1 with:
>> CONFIG_NET_ISA=y
>> CONFIG_NE2000=y
>>
>> I have the following compile error:
>> ...
>> GEN .version
>> CHK include/linux/compile.h
>> UPD include/linux/compile.h
>> CC init/version.o
>> LD init/built-in.o
>> LD .tmp_vmlinux1
>> drivers/built-in.o: In function `ne_block_output':
>> linux-2.6.24-mm1/drivers/net/ne.c:797: undefined reference to `NS8390_init'
>> drivers/built-in.o: In function `ne_drv_resume':
>> linux-2.6.24-mm1/drivers/net/ne.c:858: undefined reference to `NS8390_init'
>> drivers/built-in.o: In function `ne_probe1':
>> linux-2.6.24-mm1/drivers/net/ne.c:539: undefined reference to `NS8390_init'
>> make[1]: *** [.tmp_vmlinux1] Error 1
>> make: *** [sub-make] Error 2
>
> Thanks for reporting this.
>
>> As I saw that the file 8390p.c is compiled for this driver, but not the file
>> 8390.c which contains this function NS8390_init(), I fixed this error with
>> the following patch.
>
> Alan's
> 8390-split-8390-support-into-a-pausing-and-a-non-pausing-driver-core.patch
> would be a prime suspect. I assume this bug isn't present ing mainline or
> in 2.6.24?
>
>> As NS8390p_init() does the same thing than NS8390_init(), I suppose that
>> this is the right fix ?
>>
>> Signed-off-by: Pierre Peiffer <[EMAIL PROTECTED]>
>> ---
>> drivers/net/ne.c |6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> Index: b/drivers/net/ne.c
>> ===
>> --- a/drivers/net/ne.c
>> +++ b/drivers/net/ne.c
>> @@ -536,7 +536,7 @@ static int __init ne_probe1(struct net_d
>> #ifdef CONFIG_NET_POLL_CONTROLLER
>> dev->poll_controller = eip_poll;
>> #endif
>> -NS8390_init(dev, 0);
>> +NS8390p_init(dev, 0);
>>
>> ret = register_netdev(dev);
>> if (ret)
>> @@ -794,7 +794,7 @@ retry:
>> if (time_after(jiffies, dma_start + 2*HZ/100)) {
>> /* 20ms */
>> printk(KERN_WARNING "%s: timeout waiting for Tx
>> RDC.\n", dev->name);
>> ne_reset_8390(dev);
>> -NS8390_init(dev,1);
>> +NS8390p_init(dev,1);
>> break;
>> }
>>
>> @@ -855,7 +855,7 @@ static int ne_drv_resume(struct platform
>>
>> if (netif_running(dev)) {
>> ne_reset_8390(dev);
>> -NS8390_init(dev, 1);
>> +NS8390p_init(dev, 1);
>> netif_device_attach(dev);
>> }
>> return 0;
>
>
>
>
--
Pierre Peiffer
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
keyboard dead with 45b5035
The patch "[RTNETLINK]: Send a single notification on device state changes." kills (at least) the keyboard here. Everything seems to work fine in single user mode, but when init starts spawning of logins, the keyboard goes bye-bye. Even the power button is ignored. :/ I've tried just creating another vt with "chvt 2", but that is insufficient to trigger the bug. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: keyboard dead with 45b5035
On Mon, 18 Feb 2008 20:50:01 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > On Monday, 18 of February 2008, Pierre Ossman wrote: > > The patch "[RTNETLINK]: Send a single notification on device state > > changes." kills (at least) > > the keyboard here. Everything seems to work fine in single user mode, but > > when init starts > > spawning of logins, the keyboard goes bye-bye. Even the power button is > > ignored. :/ > > Please try with the patch from http://lkml.org/lkml/2008/2/18/331 . > That solved it. I wonder if that's also why modprobe tends to wedge up with the new USB announce thingy... Tomorrow's debugging will tell. -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: keyboard dead with 45b5035
On Mon, 18 Feb 2008 21:50:12 +0100 Pierre Ossman <[EMAIL PROTECTED]> wrote: > On Mon, 18 Feb 2008 20:50:01 +0100 > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > > > On Monday, 18 of February 2008, Pierre Ossman wrote: > > > The patch "[RTNETLINK]: Send a single notification on device state > > > changes." kills (at least) > > > the keyboard here. Everything seems to work fine in single user mode, but > > > when init starts > > > spawning of logins, the keyboard goes bye-bye. Even the power button is > > > ignored. :/ > > > > Please try with the patch from http://lkml.org/lkml/2008/2/18/331 . > > > > That solved it. > Perhaps not quite. When I returned to my laptop this morning, the keyboard was gone again. Did a hard reboot, and the machine locked up a few seconds after starting X. I'll see if it can be reproduced... Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
random wedges with 2.6.25-rc*
Somewhere post 2.6.24, the kernel started getting very temperamentful. I experience random hangs and wedges very often. Primarily, the udev startup locks up. If I abort it, it just locks up on more or less every action after that. Some quick debugging showed that I had a whole bunch of modprobe processes sitting around. The new CONFIG_USB_ANNOUNCE_NEW_DEVICES setting makes every startup of udev lock up consistently on at least two machines. It does not seem to be the root of the problem as disabling the option just makes the bug very unlikely. I've also seen a couple of lockups in X. Might be a different expression of the same bug, but the effect here is a complete wedge of the user interface. It seems the rest of the machine also locks up, but I haven't confirmed this. Anyone else seeing these problems? Someone should as I've seen the problem on both a Lenovo and a HP laptop here. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: random wedges with 2.6.25-rc*
On Tue, 19 Feb 2008 12:55:13 -0500 Jeff Garzik <[EMAIL PROTECTED]> wrote: > Pierre Ossman wrote: > > > > Anyone else seeing these problems? Someone should as I've seen the problem > > on both a Lenovo and a HP laptop here. > > > I'm definitely seeing lockups here too. 2.6.24 is fine, 2.6.24-rc1 or > -rc2 locks up a minute or so after a successful boot (either to console > or to X). > > Does the following shed any light? > > http://lkml.org/lkml/2008/2/17/78 > That would explain the lockups in X as the network has been active at those times. But it would be odd if it affects the startup of udev (most likely module loading). Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bug 10030] Suspend doesn't work when SD card is inserted
On Wed, 20 Feb 2008 11:42:56 -0500 (EST) Alan Stern <[EMAIL PROTECTED]> wrote: > > > > --- Comment #14 from [EMAIL PROTECTED] 2008-02-19 15:23 --- > > Thanks a lot for the debugging work! > > > > First, the patch triggers, which means that the problem discovered by Alan > > is > > troubling us. [Alan, do you have an idea how to fix that cleanly?] > > I suggest we ask the maintainer for the MMC subsystem. > > Pierre, you can find the details in the bugzilla entry. Briefly, > there's a pathway in the MMC core suspend routine (if the driver > doesn't implement a resume hook) which could lead to the host being > removed during a system suspend. This is an illegal operation and it > will deadlock. > > Do you have a suggestion for a way to fix it? > Not really. But you have some things confused. What it checks is if the mmc bus handler (not a proper driver model, just a way of separating the MMC, SD and SDIO stuff) has a resume function. And if it doesn't, it removes the card (since it cannot revive it at resume). So the only thing I can think of is to delay the removal until the resume routine, if that is safer. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bug 10030] Suspend doesn't work when SD card is inserted
On Wed, 20 Feb 2008 14:26:16 -0500 (EST) Alan Stern <[EMAIL PROTECTED]> wrote: > > Do I understand this correctly? You've got special handling for the > case where a bus handler doesn't have a resume routine, but no special > handling for the case where it doesn't have a suspend routine? Hmm... There should be checks for both, but the code seems to suggest otherwise. > Why bother to remove the device if neither routine exists (there won't be > any need to revive it since the bus never got suspended)? The bus always gets suspended. The checks are to determine if state is saved or not. If it isn't, then a suspend/resume is treated as a removal/insertion. > And why not simply fail the suspend if the resume routine doesn't exist > and the suspend routine does? Maybe with an error message in the > system log. For the asymmetric case, I guess that would do. But I still want to remove devices when the bus handler has no suspend handling. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] mmc: extend ricoh_mmc to support Ricoh RL5c476
On Mon, 4 Feb 2008 19:25:42 +0100
Frank Seidel <[EMAIL PROTECTED]> wrote:
> From: Frank Seidel <[EMAIL PROTECTED]>
>
> This patch (base on current linus git tree plus Philip Langdales
> suspend/resume patch) adds support for the Ricoh RL5c476 chip:
> with this the mmc adapter that needs this disabler (R5C843) can
> also be handled correctly when it sits on a RL5c476.
> (+ minor style changes (removed spaces between function names
> and open parenthesis .. checkpatch warned from previos patch))
>
> Signed-off-by: Frank Seidel <[EMAIL PROTECTED]>
I see you've guys have kept yourself busy in my absence. :)
As for the patch, it looks ok although I'm not really a fan of more voodoo
constants that noone knows what they mean. Could you add some comments
explaining some of them at least?
> + if (fw_dev->device == PCI_DEVICE_ID_RICOH_RL5C476) {
*snip*
> + } else {
> + /* via R5C832 */
Wouldn't it be prudent to have a check that this is indeed a R5C832, and a
failure mode if it's none of the two known devices?
Rgds
Pierre
signature.asc
Description: PGP signature
Re: [semi-solved] Re: [sdhci] mmc0: unrecognised SCR structure version 1
On Thu, 7 Feb 2008 00:10:16 +0100 Andreas Mohr <[EMAIL PROTECTED]> wrote: > > My Toshiba SD-512-T card (Toshiba-specific specs are available as > TOSHIBA_SD_Card_Specification.pdf) shows the same "SCR structure version 1" > error message with 2.6.24 on a Motorola E680 (PXAMCI), whereas > on 2.6.21 it did _NOT_ have it (and all SCR values there are a 1:1 match > with the values listed in the spec .pdf!). > > For me at least it turned out that while on 2.6.21, raw_scr had > 0x00a5 0x10011602 > on 2.6.24 raw_scr had > 0x10011602 0x > Ouch. That would explain more or less any SCR related bug. :) > IOW, the whole thing is simply shifted by one unsigned int, rendering any > SCR interpretation fatally wrong (which, I believe, could be a > _permanent_ error in the SD stack itself which randomly - > depending on the exact bit content of a card's SCR dump - > causes the SCR version check to trigger for various cards). > Is this unsigned int shifting due to a transfer setup issue in the > highlevel SD stack or do you think it is due to a setup issue in the > lower-level pxamci driver in my case? If so, what setting could have > distorted it? I'm not seeing it on any controller here, so right now I'd guess a driver problem. No idea why though. Are you seeing this effect on other cards? > Weak voltage settings are not to blame, I believe (removed some configs to > increase a bit from minimum supported voltage). > If you don't have any specific ideas yet, any hints on how to proceed > with tracking this down? There's always bisecting the issue until you find the offending commit. Time consuming, but it gets the job done. Other than that, try adding some printk() to pxamci's data transfer routines and dump the data when it is fresh. > > I'd advise at least adding dumping the raw_scr values > in the SCR version error to be able to track such error postings better > in the future. > It's definitely something to remember in future bug reports. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] mmc: extend ricoh_mmc to support Ricoh RL5c476
On Thu, 7 Feb 2008 09:20:38 +0100 Frank Seidel <[EMAIL PROTECTED]> wrote: > > > > Wouldn't it be prudent to have a check that this is indeed a R5C832, > > and a failure mode if it's none of the two known devices? > > Also thought about that, but as far as i can see this cannot happen since > we only probe for those two devices and deny to continue if anything else > /those two were not found in the beginning. > Can never be too careful though. :) I've applied the patch for now. Feel free to keep digging and finding some docs for those regs though. Rgds Pierre signature.asc Description: PGP signature
Re: SDIO driver not receiving responses
Don't hijack threads, it completely messes up everyone's mail box and makes your mail very difficult to find. On Thu, 31 Jan 2008 17:35:51 +1100 Farbod Nejati <[EMAIL PROTECTED]> wrote: > The mmc_send_io_op_cond() function call in core.c::mmc_rescan() is > returning with a -110 (a timeout error). I traced this deeper and > noticed that CMD5 is being sent out via sdhci.c::sdhci_send_command() (I > verified this using a logic analyser, the host *is* transmitting a CMD5 > [IO_SEND_OP_COND] packet in the correct format). However, when the > client responds with the IO_SEND_OP_COND Response R4 (SD mode), it does > not seem to be received by the host. Again, I verified using the logic > analyser that the response is as would be expected. An IRQ *is* > triggered, however it is 0x00018000 (SDHCI_INT_TIMEOUT|SDHCI_INT_ERROR). > I'm not too familiar with Linux kernel programming but I suspect that > whatever is waiting for a valid response is giving up instead and > triggering the above-mentioned interrupt instead. That would be the hardware. We don't do any software timeout handling. Have you checked the time from command to reply with the logic analyser? The chip might simply be out of spec. > > Why would the output of the above code differ from the one produced by > lspci -xxx. Could this have something to do with this issue??? > lspci shows you the PCI config space, not the device io space, which is what your code dumped. ;) > > I'm fresh out of ideas on this one and would greatly appreciate some > hints or assistance. I'm happy to provide any further information if needed. > I can only see one of two options here. Either there is some miscalculation of the timeout, or you have a hardware bug. And to determine that we need to check what is actually going over the wire. As you've checked the data contents, that isn't the problem. So the only remaining thing is checking the timing. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/18] MMC: OMAP: Introduce new multislot structure and change driver to use it
On Mon, 28 Jan 2008 15:07:23 -0400
Carlos Aguiar <[EMAIL PROTECTED]> wrote:
> From: Juha Yrjola <[EMAIL PROTECTED]>
>
> Introduce new MMC multislot structure and change driver to use it.
>
> Note that MMC clocking is now enabled in mmc_omap_select_slot()
> and disabled in mmc_omap_release_slot().
>
> Signed-off-by: Juha Yrjola <[EMAIL PROTECTED]>
> Signed-off-by: Jarkko Lavinen <[EMAIL PROTECTED]>
> Signed-off-by: Carlos Eduardo Aguiar <[EMAIL PROTECTED]>
> Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
> ---
I still think this muxed mmc host thing is a bad idea, but it's your
nightmare...
> +
> +/* Access to the R/O switch is required for production testing
> + * purposes. */
> +static ssize_t
> +mmc_omap_show_ro(struct device *dev, struct device_attribute *attr, char
> *buf)
> +{
> + struct mmc_host *mmc = container_of(dev, struct mmc_host, class_dev);
> + struct mmc_omap_slot *slot = mmc_priv(mmc);
> +
> + return sprintf(buf, "%d\n", slot->pdata->get_ro(mmc_dev(mmc),
> + slot->id));
> +}
> +
> +static DEVICE_ATTR(ro, S_IRUGO, mmc_omap_show_ro, NULL);
> +
This is unrelated to the slot stuff and should be in its own patch. Also, it
should probably be in the core, not a driver.
> +
> + mmc->caps = MMC_CAP_MULTIWRITE | MMC_CAP_MMC_HIGHSPEED |
> + MMC_CAP_SD_HIGHSPEED;
This is also unrelated. From what I've seen, the OMAP is a SD controller and
does not support high speed MMC. The fact that you also conditionally set the
max frequency later also suggests that this code is entirely incorrect.
> +
> + r = mmc_add_host(mmc);
> + if (r < 0)
> + return r;
> +
> + if (slot->pdata->name != NULL) {
> + r = device_create_file(&mmc->class_dev,
> + &dev_attr_slot_name);
> + if (r < 0)
> + goto err_remove_host;
> + }
> +
> + if (slot->pdata->get_ro != NULL) {
> + r = device_create_file(&mmc->class_dev,
> + &dev_attr_ro);
> + }
> +
You have a bit of a race here with userspace in case you use the uevent to
trigger things.
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] at91_mci: use generic GPIO calls
On Mon, 04 Feb 2008 18:12:48 +0100 Nicolas Ferre <[EMAIL PROTECTED]> wrote: > From: David Brownell <[EMAIL PROTECTED]> > > Update the AT91 MMC driver to use the generic GPIO calls instead of the > AT91-specific calls; and to request (and release) those GPIO signals. > > That required updating the probe() fault cleanup codepaths. Now there > is a single sequence for freeing resources, in reverse order of their > allocation. Also that code uses use dev_*() for messaging, and has less > abuse of KERN_ERR. > > Likewise with updating remove() cleanup. This had to free the GPIOs, > and while adding that code I noticed and fixed two other problems: it > was poking at a workqueue owned by the mmc core; and in one (rare) > case would try freeing an IRQ that it didn't allocate. > > Signed-off-by: David Brownell <[EMAIL PROTECTED]> > Signed-off-by: Nicolas Ferre <[EMAIL PROTECTED]> > --- Applied thanks. -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/18] MMC: OMAP: Include missing from previous merging
On Mon, 28 Jan 2008 15:07:06 -0400 Carlos Aguiar <[EMAIL PROTECTED]> wrote: > From: Carlos Eduardo Aguiar <[EMAIL PROTECTED]> > > This patch adds an include missing from previous merging > mainline tree into linux-omap tree. > > Signed-off-by: Carlos Eduardo Aguiar <[EMAIL PROTECTED]> > Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]> > --- NAK. This header should not be needed in host drivers. It's a clear sign you're doing something bad. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.24-rc8-mm1 09/15] (RFC) IPC: new kernel API to change an ID
Serge E. Hallyn wrote: > > But note that in either case we need to deal with a bunch of locking. > So getting back to Pierre's patchset, IIRC 1-8 are cleanups worth > doing no matter 1. 9-11 sound like they are contentuous until > we decide whether we want to go with a create_with_id() type approach > or a set_id(). 12 is IMO a good locking cleanup regardless. 13 and > 15 are contentous until we decide whether we want userspace-controlled > checkpoint or a one-shot fs. 14 IMO is useful for both c/r approaches. > > Is that pretty accurate? > Ok, so, so far, the discussion stays opened about the new functionalities for c/r. As there were no objection about the first patches, which rewrite/enhance the existing code, Andrew, could you consider them (ie patches 1 to 8 of this series) for inclusion in -mm ? (I mean, as soon as it is possible, as I guess you're pretty busy for now with the merge for 2.6.25) If you prefer, I can resend them separately ? Thanks, Pierre >> It isn't strictly necessary to export a new interface in order to >> support checkpoint/restart. **. Hence, I think that the speculation >> "we may need it in the future" is too abstract and isn't a good >> excuse to commit to a new, currently unneeded, interface. > > OTOH it did succeed in starting some conversation :) > >> Should the >> need arise in the future, it will be easy to design a new interface >> (also based on aggregated experience until then). > > What aggregated experience? We have to start somewhere... > >> ** In fact, the suggested interface may prove problematic (as noted >> earlier in this thread): if you first create the resource with some >> arbitrary identifier and then modify the identifier (in our case, >> IPC id), then the restart procedure is bound to execute sequentially, >> because of lack of atomicity. > > Hmm? Lack of atomicity wrt what? All the tasks being restarted were > checkpointed at the same time so there will be no conflict in the > requested IDs, so I don't know what you're referring to. > >> That said, I suggest the following method instead (this is the method >> we use in Zap to determine the desired resource identifier when a new >> resource is allocated; I recall that we had discussed it in the past, >> perhaps the mini-summit in september ?): >> >> 1) The process/thread tells the kernel that it wishes to pre-determine >> the resource identifier of a subsequent call (this can be done via a >> new syscall, or by writing to /proc/self/...). >> >> 2) Each system call that allocates a resource and assigns an identifier >> is modified to check this per-thread field first; if it is set then >> it will attempt to allocate that particular value (if already taken, >> return an error, eg. EBUSY). Otherwise it will proceed as it is today. > > But I thought you were just advocating a one-shot filesystem approach > for c/r, so we wouldn't be creating the resources piecemeal? > > The /proc/self approach is one way to go, it has been working for LSMs > this long. I'd agree that it would be nice if we could have a > consistent interface to the create_with_id()/set_id() problem. A first > shot addressing ipcs and pids would be a great start. > >> (I left out some details - eg. the kernel will keep the desire value >> on a per-thread field, when it will be reset, whether we want to also >> tag the field with its type and so on, but the idea is now clear). >> >> The main two advantages are that first, we don't need to devise a new >> method for every syscall that allocates said resources (sigh... just > > Agreed. > >> think of clone() nightmare to add a new argument); > > Yes, and then there will need to be the clone_with_pid() extension on > top of that. > >> second, the change >> is incremental: first code the mechanism to set the field, then add >> support in the IPC subsystem, later in the DEVPTS, then in clone and >> so forth. >> >> Oren. >> >> Pierre Peiffer wrote: >>> Kirill Korotaev wrote: >>>> Why user space can need this API? for checkpointing only? >>> I would say "at least for checkpointing"... ;) May be someone else may >>> find an >>> interest about this for something else. >>> In fact, I'm sure that you have some interest in checkpointing; and thus, >>> you >>> have probably some ideas in mind; but whatever the solution you will >>> propose, >>> I'm pretty sure that I could say the same thing for your solution. >>> And what I finally think is: even
[PATCH 2.6.24-mm1] IPC: use ipc_buildid() directly from ipc_addid()
Hi,
By continuing to consolidate a little the IPC code, each id can be built
directly in ipc_addid() instead of having it built from each callers of
ipc_addid()
And I also remove shm_addid() in order to have, as much as possible, the
same code for shm/sem/msg.
Signed-off-by: Pierre Peiffer <[EMAIL PROTECTED]>
---
ipc/msg.c |2 --
ipc/sem.c |2 --
ipc/shm.c | 10 +-
ipc/util.c |1 +
4 files changed, 2 insertions(+), 13 deletions(-)
Index: b/ipc/msg.c
===
--- a/ipc/msg.c
+++ b/ipc/msg.c
@@ -70,7 +70,6 @@ struct msg_sender {
#define msg_ids(ns)((ns)->ids[IPC_MSG_IDS])
#define msg_unlock(msq)ipc_unlock(&(msq)->q_perm)
-#define msg_buildid(id, seq) ipc_buildid(id, seq)
static void freeque(struct ipc_namespace *, struct kern_ipc_perm *);
static int newque(struct ipc_namespace *, struct ipc_params *);
@@ -186,7 +185,6 @@ static int newque(struct ipc_namespace *
return id;
}
- msq->q_perm.id = msg_buildid(id, msq->q_perm.seq);
msq->q_stime = msq->q_rtime = 0;
msq->q_ctime = get_seconds();
msq->q_cbytes = msq->q_qnum = 0;
Index: b/ipc/sem.c
===
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -91,7 +91,6 @@
#define sem_unlock(sma)ipc_unlock(&(sma)->sem_perm)
#define sem_checkid(sma, semid)ipc_checkid(&sma->sem_perm, semid)
-#define sem_buildid(id, seq) ipc_buildid(id, seq)
static int newary(struct ipc_namespace *, struct ipc_params *);
static void freeary(struct ipc_namespace *, struct kern_ipc_perm *);
@@ -268,7 +267,6 @@ static int newary(struct ipc_namespace *
}
ns->used_sems += nsems;
- sma->sem_perm.id = sem_buildid(id, sma->sem_perm.seq);
sma->sem_base = (struct sem *) &sma[1];
/* sma->sem_pending = NULL; */
sma->sem_pending_last = &sma->sem_pending;
Index: b/ipc/shm.c
===
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -60,7 +60,6 @@ static struct vm_operations_struct shm_v
#define shm_unlock(shp)\
ipc_unlock(&(shp)->shm_perm)
-#define shm_buildid(id, seq) ipc_buildid(id, seq)
static int newseg(struct ipc_namespace *, struct ipc_params *);
static void shm_open(struct vm_area_struct *vma);
@@ -169,12 +168,6 @@ static inline void shm_rmid(struct ipc_n
ipc_rmid(&shm_ids(ns), &s->shm_perm);
}
-static inline int shm_addid(struct ipc_namespace *ns, struct shmid_kernel *shp)
-{
- return ipc_addid(&shm_ids(ns), &shp->shm_perm, ns->shm_ctlmni);
-}
-
-
/* This is called by fork, once for every shm attach. */
static void shm_open(struct vm_area_struct *vma)
@@ -417,7 +410,7 @@ static int newseg(struct ipc_namespace *
if (IS_ERR(file))
goto no_file;
- id = shm_addid(ns, shp);
+ id = ipc_addid(&shm_ids(ns), &shp->shm_perm, ns->shm_ctlmni);
if (id < 0) {
error = id;
goto no_id;
@@ -429,7 +422,6 @@ static int newseg(struct ipc_namespace *
shp->shm_ctim = get_seconds();
shp->shm_segsz = size;
shp->shm_nattch = 0;
- shp->shm_perm.id = shm_buildid(id, shp->shm_perm.seq);
shp->shm_file = file;
/*
* shmid gets reported as "inode#" in /proc/pid/maps.
Index: b/ipc/util.c
===
--- a/ipc/util.c
+++ b/ipc/util.c
@@ -231,6 +231,7 @@ int ipc_addid(struct ipc_ids* ids, struc
if(ids->seq > ids->seq_max)
ids->seq = 0;
+ new->id = ipc_buildid(id, new->seq);
spin_lock_init(&new->lock);
new->deleted = 0;
rcu_read_lock();
--
Pierre Peiffer
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Tokyo Electron SDIO controller (Ellen) support
On Mon, 3 Dec 2007 14:39:26 + Ben Dooks <[EMAIL PROTECTED]> wrote: > On Mon, Dec 03, 2007 at 08:22:07AM -0600, Matt Porter wrote: > > > > What's the status of Ben's separation patches? I haven't seen a posting of > > those > > versus a recent kernel. I've got some SDHCI driver glue for the non-pci > > Arasan core > > running in an older kernel tree with those patches. It's just waiting for > > the separation > > patches to hit the mmc or mainline tree. > > I need to go back and try and sort out the last of Pierre's last > comments, and update to the latest kernel version. I was waiting > for 2.6.24-rc4 to re-start the effort to try and ensure there are > fewer changes due to fixes. > Any progress on this little project? Rgds Pierre signature.asc Description: PGP signature
[GIT PULL] MMC updates
Linus, please pull from git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git for-linus to receive the following updates: MAINTAINERS |3 - drivers/mmc/host/Kconfig |8 +- drivers/mmc/host/at91_mci.c | 114 +- drivers/mmc/host/ricoh_mmc.c | 162 ++--- drivers/mmc/host/sdhci.c | 13 +++- drivers/mmc/host/sdhci.h |1 + 6 files changed, 231 insertions(+), 70 deletions(-) David Brownell (1): at91_mci: use generic GPIO calls Feng Tang (1): sdhci: add num index for multi controllers case Frank Seidel (1): mmc: extend ricoh_mmc to support Ricoh RL5c476 Philip Langdale (1): mmc: Handle suspend/resume in Ricoh MMC disabler Pierre Ossman (2): mmc: remove sdhci and mmc_spi experimental markers MAINTAINERS: remove non-existant URLs -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
3.6-rc7 32-bit PAE miscalculates dirty page limits
Hi, there seems to be a bug in either ext4 or VM code triggered with 16 GB memory when compiled with 32-bit and PAE. dirty_background_ratio defaults to 10, dirty_ratio to 20. But in effect, dirty pages are strongly limited (zero or negative?). I observed extreme I/O wait states and slow disk access. A quick cure was to set dirty_bytes and dirty_background_bytes to sane values, overriding the ratios. An educated guess: the result of dirty_ratio calculation is stored as an unsigned 32-bit integer and overflows? Greetings, Pierre Beck -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BISECTED] snd-hda-intel audio distortion in Linus' current tree
Hi, I'd like to confirm this bug exists in 3.6-rc7 32-bit. It seems to occur only when opening the audio output, and not with every audio player. MP3 / Ogg playback with VLC via Pulseaudio triggers the noise. Xine, Totem don't. After about 20 to 40 seconds, it suddenly disappears. Greetings, Pierre Beck -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.6-rc7 32-bit PAE miscalculates dirty page limits
Hi, when I installed the original setup, there were no 64-bit PC CPUs. It's been kept up-to-date, changed hardware whenever necessary. But a shift from 32-bit to 64-bit isn't as simple as it seems. I tried 64-bit kernel with 32-bit userspace. It failed. The installed DVB-S tuner driver messed up the stream. I *guess* there's some little / big endian issue between userspace program (vdr, dvbhddevice) and driver (sff716x_ff which is still in experimental media stack), and it *may* be resolved by upgrading userspace to 64-bit as well. I do consider the option of upgrading to 64-bit userspace. My distribution Debian doesn't provide a clean way to do so in-place, though. There are HOWTOs on the topic with warnings varying between 'do not attempt, will eat your data' and 'worked for the author, YMMV'. That scared me off for now. Instead, a clean install and copying /etc will be my best option and with LVM in place I'm sure I will eventually upgrade sooner or later. Personally, I don't need a fix anyways, since I found the stated workaround and can live with that. But what about other folks who upgrade their PC? They won't know what hit them when their new PC crawls because disk is trashed. Greetings, Pierre Beck On 30.09.2012 20:52, H. Peter Anvin wrote: On 09/30/2012 02:38 AM, Pierre Beck wrote: Hi, there seems to be a bug in either ext4 or VM code triggered with 16 GB memory when compiled with 32-bit and PAE. dirty_background_ratio defaults to 10, dirty_ratio to 20. But in effect, dirty pages are strongly limited (zero or negative?). I observed extreme I/O wait states and slow disk access. A quick cure was to set dirty_bytes and dirty_background_bytes to sane values, overriding the ratios. An educated guess: the result of dirty_ratio calculation is stored as an unsigned 32-bit integer and overflows? Seriously, why are you running a 32-bit kernel on memory sizes this large? Yes, in theory it should work up to 64 GB but claims are that the kernel doesn't even boot if you try... -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Areca hardware RAID / first-ever SCSI bus reset: am I about to lose this disk controller?
Check the SMART values of the disks if possible. Watch for command timeouts and the usual bad sector stuff. I've had similar issues with Adaptec controllers. Bad disks seem to cause havoc. The outstanding operation isn't answered within [SCSI Timeout, default 30, /sys/block/sdX/device/timeout] seconds, so Linux performs a loop reset, eventually resetting the controller. That means between 60 and 120 seconds of zero I/O operation, varying between controllers and disk array sizes. It's particularly annoying when in RAID and the disk could've simply been kicked within few seconds. Something that needs improvement IMHO. On 23.09.2012 17:42, Nix wrote: On 19 Sep 2012, Chris Murphy outgrape: On Sep 19, 2012, at 12:52 PM, Nix wrote: So I have this x86-64 server running Linux 3.5.1 with a SATA-on-PCIe Areca 1210 hardware RAID-5 controller Did you find this? Same controller family. Weird that this just shows up now, but perhaps instead of it being "bad hardware" out the gate, something's happened to it and now it's failing as you suspect. Hm, it's possible I suppose. Just as possible that a disk is dying. It looks to have been a one-off transient -- no recurrence yet, touch wood :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MMC core debugfs support (was Re: [RFC v2 5/5] Atmel MCI: Driver for Atmel on-chip MMC controllers)
On Thu, 14 Feb 2008 15:00:05 +0100 Haavard Skinnemoen <[EMAIL PROTECTED]> wrote: > > I've started working on this, but I've run into a problem: The mmc core > structures don't seem to keep any references to the current request. So > I don't really have any information to put into the 'req' file after > moving it into the core. > > Any ideas on how to solve this? > The simple solution is just to add it. :) But is it needed though? Shouldn't a read block until there is an event, at which point you'll have access to the data structures long enough to output data. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MMC card detection
On Thu, 21 Feb 2008 19:46:20 +0100 Haavard Skinnemoen <[EMAIL PROTECTED]> wrote: > > When the card is reinserted, the MMC core will try to send a > SEND_STATUS command again. This time, the card won't respond because it > is in the "idle" state, and the MMC core will think the card is gone. > > In order to fix this problem, I think I need a way to tell the MMC core > that the card really is gone and that there's no point trying to > communicate with it. Is there any way I can do that? > As you found out, you can. But the MMC core doesn't treat it differently. What is really needed is that the core should make an extra pass and see if the card has been replaced by something else (and not just check if it is gone). It's on my todo, but I haven't had time to implement it. Rgds Pierre signature.asc Description: PGP signature
Re: Bugs in MMC [was: [Bug 10030] Suspend doesn't work when SD card is inserted]
On Sun, 24 Feb 2008 10:33:34 -0500 (EST) Alan Stern <[EMAIL PROTECTED]> wrote: > > Well, the patch itself isn't really adequate; it was just a first pass > intended to illustrate the nature of the problem. > > The problems in the MMC subsystem go deeper. > > The first is the way it uses flush_workqueue(). This is almost always > a bad function to call, because it introduces unnecessary dependencies. > cancel_delayed_work_sync() is much better. > > But even changing that won't solve the second issue, which is a genuine > bug. There is a race between detect events and suspend events. The > mmc_suspend_host() routine starts out by flushing the kmmcd workqueue > before calling the host's suspend routine. So what happens if another > detect event occurs in between? > The idea is that host drivers shouldn't do that. Once they've called mmc_suspend_host(), then they shouldn't be poking the MMC core in any other way. None of this is of course properly documented. :/ > This whole area of synchronization between card insertion, card > removal, suspend, and resume needs to be thought out better. > Especially keeping in mind that device registration or unregistration > during a system sleep is likely to block until the sleep is over. Trying to keep up with the PM changes is a full time job. For now I've mostly ignored it as I don't even have time for the other stuff. Patches welcome. > > Lastly, there are some other questions about confusing aspects of the > subsystem. What's the story with __mmc_claim_host()? Is it really > nothing more than an abortable mutex_lock()? Why does it ever need to > be aborted? Why is its second argument an atomic_t instead of a normal > int? > It got that way when SDIO got in. It was needed to make it abortable to solve a rather nasty deadlock situation. I don't remember the details right now, but it should be in the LKML archives. > Why are mmc_detect() and related routines described in comments as > "Card detection callback from host"? They don't handle card > _detection_ -- they handle card _removal_. They handle both. > > What's the purpose of the card-counting loop in > host/omap.c:mmc_omap_switch_handler()? It looks like dead code. > I'm not too familiar with that driver, but they've been playing around with multiplexing several cards into one controller. Might be bits and pieces of that. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bugs in MMC [was: [Bug 10030] Suspend doesn't work when SD card is inserted]
On Mon, 25 Feb 2008 12:58:30 -0500 (EST) Alan Stern <[EMAIL PROTECTED]> wrote: > Thanks for the explanations. > > On Mon, 25 Feb 2008, Pierre Ossman wrote: > > > Trying to keep up with the PM changes is a full time job. For now I've > > mostly ignored it as I don't even have time for the other stuff. > > Patches welcome. > > What do you think of the patch attached to comment #40 in the Bugzilla > entry? > Looks ok. As long as those two synchronization points are guaranteed, then I'm happy. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Still IRQ routing problems with VIA
Le 10-Apr-2001, Manuel A. McLure écrivait : > This may be the difference - I always set "Plug-n-Play OS: No" on all my > machines. Linux works fine and it doesn't seem to hurt Windows 98 any. I've been told it affects the way IRQs are assigned; With "PnP OS: No", some boards (seen on several Asus mainboards, ie Phoenix-Award BIOS) try to share IRQs as much as possible; It usually works, but the performance may suffer a bit. -- We are the dot in 0.2 Kb/s - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Odd network problems
Jon Eisenstein wrote: > Here is a partial list of sites that I have had problems with. Note that > once I find one of these sites, it is consistantly unreachable, even with > sites found months ago. i had a try with Linux-2.4.2 Mozilla 0.8 > www.codewarrioru.com time out answer (pingable however) > www.backwire.com connection refused with ECN. echo '0' > tcp_ecn makes it reachable. Mozilla sucks (CPU99%) and does not display the page in a reasonable time (maybe a problem i have with java and glibc-2.2.2) > www.counterpane.com no problem with this one. > www.zip2it.com un-resolved (could it be www.zip2.com) -- ---- Pierre Rousselet <[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: devfs and /proc/ide/hda
Glenn McGrath wrote: > Helge Hafting wrote: > >> Glenn McGrath wrote: >> >>> Im running kernel 2.4.1, I have entries like /proc/ide/hda, >>> /proc/ide/ide0/hda etc irrespective of wether im using devfs or >>> traditional device names. >>> >>> Is always using traditional device names for /proc/ide intentional, or >>> is it something nobody has gotten around to fixing yet? >> >> Using devfs changes the names in /dev. I don't think it >> is supposed to affect /proc in any way. And there are programs out >> that use the existing /proc - changing it won't be popular. >> > > > Well leaving it the way it is doesnt make much sense either really, it > refers to devices that dont exist. IMHO ide0 ide1... are naming plugs on the motherboard. They are not competing with special file names. It is a drawback of devfs to change the device name when you happen to use a hd as a removable media. hdd was disc0 and becomes disc1 when you plug in an hda... Pierre -- Pierre Rousselet <[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: [prepatches] removal of console_lock
Andrew Morton wrote: > This patch fixes it. Interrupts are enabled across all console operations. > > It's still somewhat a work-in-progress. The patch applies OK against 2.4.3-pre1 At the end of make bzImage I got kerne/kernel.o(.text+0xcd00): undefined reference to 'in_interrupt' PR -- ---- Pierre Rousselet <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.1-pre2/3 and Pentium-III not stable
Pentium-III 256Mo For testing, I try to compile glibc. The start is good. When the process PID reaches a value around 22000 (variable), all goes wrong. Make gives error messages such as : make[2]: *** No rule to make target `../sysdeps/wordsize-32/bits/wordsi:e.h' make[2]: *** No rule to make target `/usr/lib/g#c-lib/i686-pc-linux-gnu/2.95.2/include/stddef.h' make[2]: *** No rule to make target `../include/sys/cde&s.h' The machine doesn't freeze, it is just completely unstable. ---- Pierre Rousselet - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.1-pre2/3 and Pentium-III not stable
Andrzej Krzysztofowicz wrote: > > "Pierre Rousselet wrote:" > > Pentium-III 256Mo > > For testing, I try to compile glibc. The start is good. > > When the process PID reaches a value around 22000 > > (variable), all goes wrong. Make gives error messages > > such as : > > > > make[2]: *** No rule to make target > > `../sysdeps/wordsize-32/bits/wordsi:e.h' > > make[2]: *** No rule to make target > > `/usr/lib/g#c-lib/i686-pc-linux-gnu/2.95.2/include/stddef.h' > > As "z" / ":" and "c" / "#" differ only on a single bit > it looks like a bad memory problem. I got the attached kernlog in an other compiling test writing Kernel BUG at page_alloc.c and swap.c. The PID of as is then 26349. Pierre Rousselet <[EMAIL PROTECTED]> bug.gz
2.4.0-ac9 Pentium-III not stable
For testing, I try to bootstrap gcc. The problem looks to be in stdin piping operation. Jan 14 09:25:09 milou kernel: kernel BUG at page_alloc.c:73! Jan 14 09:25:09 milou kernel: invalid operand: Jan 14 09:25:09 milou kernel: CPU:0 Jan 14 09:25:09 milou kernel: EIP:0010:[__free_pages_ok+34/776] Jan 14 09:25:09 milou kernel: EFLAGS: 00010282 Jan 14 09:25:09 milou kernel: eax: 001f ebx: c142935c ecx: c8fdc000 edx: Jan 14 09:25:09 milou kernel: esi: 002b edi: c29da404 ebp: esp: c8fddefc Jan 14 09:25:09 milou kernel: ds: 0018 es: 0018 ss: 0018 Jan 14 09:25:09 milou kernel: Process sh (pid: 8518, stackpage=c8fdd000) Jan 14 09:25:09 milou kernel: Stack: c01b86d2 c01b8880 0049 c142935c 002b c29da404 c3c45084 c1044010 Jan 14 09:25:09 milou kernel:c01e0020 0206 084e c012a572 c012aa0a c142935c 002b Jan 14 09:25:09 milou kernel:c011fa09 c142935c c9d7a9a0 c1552bc0 40017000 00035000 00417000 40417000 Jan 14 09:25:09 milou kernel: Call Trace: [__free_pages+26/28] [free_page_and_swap_cache+166/172] [zap_page_range+421/564] [exit_mmap+186/276] [mmput+38/60] [do_exit+149/544] [sys_exit+14/16] Jan 14 09:25:09 milou kernel:[system_call+51/56] Jan 14 09:25:09 milou kernel: Jan 14 09:25:09 milou kernel: Code: 0f 0b 83 c4 0c 83 7b 08 00 74 16 6a 4b 68 80 88 1b c0 68 d2 -- Pierre Rousselet <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-x features ?
Pentium-III 256Mb BE6. 1) top (procps-2.0.7) gives me the messages : 'bad data in /proc/uptime' 'bad data in /proc/loadavg' cat /proc/uptime 1435.30 904.74 cat /proc/loadavg 0.01 0.21 0.29 1/17 19444 What is wrong ? 2) pppd (2.4.0b4) gives me the message : 'tdb_store failed : Success' 'tdb_store key failed : Success' What does that mean ? -- ---- Pierre Rousselet <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-x features ?
John Fremlin wrote: > > "Albert D. Cahalan" <[EMAIL PROTECTED]> writes: > > > > 1) top (procps-2.0.7) gives me the messages : > > > 'bad data in /proc/uptime' > > > 'bad data in /proc/loadavg' > > > cat /proc/uptime > > > 1435.30 904.74 > > > cat /proc/loadavg > > > 0.01 0.21 0.29 1/17 19444 > > > What is wrong ? > > You probably have locale settings where the decimal point is a comma > so scanf on /proc/loadavg etc. doesn't work. The following patch > (submitted to RedHat ages ago) fixes that for me. That's it. i persist in setting LANG=fr. Thank you for the tip. Pierre Rousselet <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-x features ?
"Albert D. Cahalan" wrote: > > Pierre Rousselet writes: > > > 1) top (procps-2.0.7) gives me the messages : > > 'bad data in /proc/uptime' > > 'bad data in /proc/loadavg' > > cat /proc/uptime > > 1435.30 904.74 > > cat /proc/loadavg > > 0.01 0.21 0.29 1/17 19444 > > What is wrong ? > > Which 2.4.0-x kernel, and how was procps compiled? > (the broken gcc again perhaps?) > > You might as well get procps-010114.tar.gz (new just yesterday!) and > compile it yourself. The top command seems to tolerate Red Hat's > fixed gcc, which you should get if you are using Red Hat 7. I did that. Compilation OK with gcc-2.95.2 top still doesn't work ( top > /dev/null tells you 'bad data in ...' just before the screen blanks). logout after commenting LC_ALL=fr and LANG=fr in /etc/profile login again : top works. It is a question of '.' and ',' Pierre Rousselet <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
PROBLEM: 2.4.1-pre9 does not compile on r128.c
result of the compilation :
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2
-march=i686 -DMODULE -DMODVERSIONS -include
/usr/src/linux/include/linux/modversions.h -DEXPORT_SYMTAB -c r128_drv.c
r128_drv.c:124: `DRM_IOCTL_R128_PACKET' undeclared here (not in a function)
r128_drv.c:124: nonconstant array index in initializer
r128_drv.c:124: (near initialization for `r128_ioctls')
{standard input}: Assembler messages:
{standard input}:8: Warning: Ignoring changed section attributes for .modinfo
make[3]: *** [r128_drv.o] Erreur 1
ver_linux :
Linux seyn 2.4.1-pre8 #3 dim jan 21 01:12:23 CET 2001 i686 unknown
Kernel modules 2.4.1
Gnu C 2.95.2
Gnu Make 3.79.1
Binutils 2.10.1.0.2
Linux C Library> libc.2.2
Dynamic linker ldd (GNU libc) 2.2
Procps 2.0.6
Mount 2.10q
Net-tools 2.05
Console-tools 0.2.3
Sh-utils 2.0.11
Modules Loaded ntfs nls_iso8859-15 nls_cp437 vfat fat emu10k1 soundcore
Congratulation for your job
--
Pierre CORCINOS <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
RE: Question on bdflush
Le 14-Nov-2000, Zhiruo Cao écrivait : > Why does bdflush (kupdated and kflushed) writes to disk periodically even > though the system is apparently idle. I think if no more new buffers > becomes dirty, kflushed show not write anything to disk. I'm working > on a notebook, and I found the periodic disk access is very annoying and > consuming a lot of power. Look for noflushd on Freshmeat... -- Linux blade.workgroup 2.4.0-test11 #1 Tue Nov 14 16:44:49 CET 2000 i686 unknown 10:38am up 17:34, 2 users, load average: 1.13, 1.17, 1.17 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0test8 masquerading code problems : turning into a trafic generator
Hi, There seem to be something weird in 2.4 compared to 2.2. The masquerading in 2.4 can apparently transform a router into an automatic trafic generator in some cases. Here is the logical network configuration I have, a simple masqueraded network : IFE I (bepc.paralline.i) : internal computer using masquerading (standard linux 2.2.16) F (external IP : maxwell.paralline.com, internal IP 192.168.2.1) : firewall doing the masquerading (2.4.0test8, PII/350 128MB, uptime 30 days) E : external network (cable modem) For switching from 2.2 to 2.4, I compiled the ipchains module and used the emulation method. Here are the firewall masquerading rules this problem appeared with : ipchains -P forward DENY ipchains -A forward -s 192.168.2.0/24 -j MASQ Exactly the same that what I used for 2.2 kernels... And here is a crazy log from tcpdump executed on the external interface of the firewall : 20:42:55.594209 maxwell.paralline.com.61642 > www.geologie.ens.fr.http: . ack 1 win 31856 (DF) 20:42:55.594877 www.geologie.ens.fr.http > bepc.paralline.i.4198: . ack 1 win 8760 (DF) 20:42:55.595405 maxwell.paralline.com.61642 > www.geologie.ens.fr.http: . ack 1 win 31856 (DF) 20:42:55.595879 www.geologie.ens.fr.http > bepc.paralline.i.4198: . ack 1 win 8760 (DF) 20:42:55.596212 maxwell.paralline.com.61642 > www.geologie.ens.fr.http: . ack 1 win 31856 (DF) 20:42:55.596729 www.geologie.ens.fr.http > bepc.paralline.i.4198: . ack 1 win 8760 (DF) 20:42:55.597403 maxwell.paralline.com.61642 > www.geologie.ens.fr.http: . ack 1 win 31856 (DF) 20:42:55.604912 www.geologie.ens.fr.http > bepc.paralline.i.4198: . ack 1 win 8760 (DF) 20:42:55.605259 maxwell.paralline.com.61642 > www.geologie.ens.fr.http: . ack 1 win 31856 (DF) 20:42:55.605495 www.geologie.ens.fr.http > bepc.paralline.i.4198: . ack 1 win 8760 (DF) 20:42:55.605806 maxwell.paralline.com.61642 > www.geologie.ens.fr.http: . ack 1 win 31856 (DF) 20:42:55.606113 www.geologie.ens.fr.http > bepc.paralline.i.4198: . ack 1 win 8760 (DF) 20:42:55.606654 maxwell.paralline.com.61642 > www.geologie.ens.fr.http: . ack 1 win 31856 (DF) 20:42:55.612966 www.geologie.ens.fr.http > bepc.paralline.i.4198: . ack 1 win 8760 (DF) 20:42:55.613309 maxwell.paralline.com.61642 > www.geologie.ens.fr.http: . ack 1 win 31856 (DF) Stopping the http browser didn't help. If I disconnect the external network ethernet cable during a few seconds and reconnect it, it stops generating trafic. This problem happens with various web servers being browsed (i.e. : different OS stacks). It did not appear before the 2.4 switch with the same internal computer and kernel. I checked the list archives and found nothing related to that kind of problems. I don't know this area of the kernel enough to track down the bug, but I will give all the help I can. I can add test code to the firewall, patch/recompile a kernel and provide new logs if needed. Hope it helps, Pierre BRUA -- PARALLINE ///Parallelism & Linux /// 71,av. des Vosges Phone:+33 388 141 740 mailto:[EMAIL PROTECTED] F-67000 STRASBOURG Fax:+33 388 141 741 http://www.paralline.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: ide/disk perf?
Le 30-Oct-2000, Mohammad A. Haque écrivait :
> Could someone who knows ide and drive inside and out (Andre?) please
> take a look at these figures? Am I forgetting to do something (or doing
> something I'm not suposed to) to get the best numbers? I thought I'd be
> able to get more than ~4MB/sec off the HPT366 and a UDMA66 drive.
It could be unrelated, but I had problems several times with Maxtor drives
recently; Their performances are usually high (some models give >20 Mb/s
both reads and writes), but under some conditions that I couldn't narrow down
yet, the read throughput is stuck to the floor (a few megabytes/sec) until
next reboot. The write performance is always ok.
I don't think it's a chipset problem, with a box filled with several Maxtor
drives and I observe the problem with some disk and not others at the same time.
I don't think it's a Linux problem either, since it can be observed with
Windows benchmarking tools too.
As a side note, I usually get better results tweaking disks using kernel
compiling options ("default to DMA", "autotune chipset", ...) than using hdparm
-d1 and friends, give it a try.
--
Linux blade.workgroup 2.4.0-test10 #1 Sat Oct 28 18:00:09 CEST 2000 i686 unknown
1:09pm up 1 day, 19:01, 2 users, load average: 1.04, 1.08, 1.09
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: ide/disk perf?
Le 30-Oct-2000, Mohammad Haque écrivait : > At the bottom is the IDE/ATA part of my .config. let me knwo if I am > missing something. Should I worry about the Multi_Mode configuration? I have it enabled, however I never used any HPT366 controller, so YMMV. The BX chipset is what I tested the most. ># ATA/IDE/MFM/RLL support ># > CONFIG_IDE=y > CONFIG_BLK_DEV_IDE=y > CONFIG_BLK_DEV_IDEDISK=y ># CONFIG_IDEDISK_MULTI_MODE is not set > CONFIG_BLK_DEV_IDECD=y > CONFIG_BLK_DEV_IDESCSI=m > CONFIG_BLK_DEV_IDEPCI=y > CONFIG_IDEPCI_SHARE_IRQ=y > CONFIG_BLK_DEV_IDEDMA_PCI=y > CONFIG_BLK_DEV_OFFBOARD=y > CONFIG_IDEDMA_PCI_AUTO=y > CONFIG_BLK_DEV_IDEDMA=y > CONFIG_BLK_DEV_HPT366=y > CONFIG_BLK_DEV_PIIX=y > CONFIG_PIIX_TUNING=y > CONFIG_IDEDMA_AUTO=y > CONFIG_BLK_DEV_IDE_MODES=y Looks very similar to my own settings CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y CONFIG_BLK_DEV_IDECD=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_IDEDMA_PCI=y CONFIG_IDEDMA_PCI_AUTO=y CONFIG_BLK_DEV_IDEDMA=y CONFIG_BLK_DEV_PIIX=y CONFIG_PIIX_TUNING=y CONFIG_IDEDMA_AUTO=y CONFIG_BLK_DEV_IDE_MODES=y But I only do hdparm -qu1c1k1 idedevice at boot time. Also, I've found append="ide0=autotune ide1=autotune" in my lilo.conf, left from earlier testing session. Remarks in ide.c say it only has influence on PIO modes, so unless the comment is obsolete I guess I could as well remove that line. Best regards, Pierre. -- Linux blade.workgroup 2.4.0-test10 #1 Mon Oct 30 15:30:15 CET 2000 i686 unknown 7:55pm up 4:12, 5 users, load average: 1.11, 1.20, 1.38 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RFC: /xproc -> /proc files in xml grammer?
hello, Would XML be considered human readable enough for /proc files? If not, how about a /xproc filesystem ( maybe as a kernel build option ), same as /proc but uses an xml grammer for reporting. I can see tons of uses for this, no more 'fuzzy' parsing for gui configuration tools, resource monitors, etc. ? just thinking aloud really, -Kervin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
PROBLEM: crash with linux 2.4.2
Hello, I ran 2.4.2 under heavy load since 2 days. I try to decrypt my /etc/passwd files with the program John the Ripper on a Pentium133. This process is very long ;-) I don't understand the error. Hope it will be useful. Pierre you can see the load average and the uptime after crash: 10:09am up 5 days, 21:02, 2 users, load average: 18.68, 18.07, 16.85 the output of dmesg command after crash : 5e58960 edx: 0004 esi: c0268a74 edi: 0001 ebp: esp: c1945d28 ds: 0018 es: 0018 ss: 0018 Process fvwm95 (pid: 7630, stackpage=c1945000) Stack: c0225aa5 c0225c33 00bf c0268a40 c0268cd4 0002 c0dda14f 0286 c0268a40 c0128872 c0268ccc c0268cd8 00b8 c01289bc c0268ccc 0002 0001 c1945df8 Call Trace: [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 0c 90 8b 03 8b 53 04 89 50 04 89 02 89 d8 2b 05 kernel BUG at page_alloc.c:191! invalid operand: CPU: 0 EIP: 0010:[] EFLAGS: 00010092 eax: 0020 ebx: c1041c78 ecx: c5e58960 edx: 0005 esi: c0268a74 edi: 0001 ebp: esp: c1d97e08 ds: 0018 es: 0018 ss: 0018 Process sh (pid: 7631, stackpage=c1d97000) Stack: c0225aa5 c0225c33 00bf c0268a40 c0268cd4 0002 06ab 0286 c0268a40 c0128872 c0268ccc c0268cd8 00b8 c01289bc c0268ccc 0002 0001 c11b2dd8 c51fa420 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 0c 90 8b 03 8b 53 04 89 50 04 89 02 89 d8 2b 05 kernel BUG at page_alloc.c:191! invalid operand: CPU: 0 EIP: 0010:[] EFLAGS: 00010086 eax: 0020 ebx: c1041c78 ecx: c5e58960 edx: 0005 esi: c0268a74 edi: 0001 ebp: esp: c1d97e1c ds: 0018 es: 0018 ss: 0018 Process sh (pid: 7632, stackpage=c1d97000) Stack: c0225aa5 c0225c33 00bf c0268a40 c0268cd4 0002 c0268ccc 0282 c0268a40 c0128872 c0268ccc c0268cd8 00b8 c01289bc c0268ccc 0002 0001 c0ec9be0 c5e58960 Call Trace: [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 0c 90 8b 03 8b 53 04 89 50 04 89 02 89 d8 2b 05 kernel BUG at page_alloc.c:191! invalid operand: CPU: 0 EIP: 0010:[] EFLAGS: 00010086 eax: 0020 ebx: c1041c78 ecx: c5e58b40 edx: 0005 esi: c0268a74 edi: 0001 ebp: esp: c215fd40 ds: 0018 es: 0018 ss: 0018 Process gdmlogin (pid: 7658, stackpage=c215f000) Stack: c0225aa5 c0225c33 00bf c0268a40 c0268cd4 0002 04ae 0286 c0268a40 c0128872 c0268ccc c0268cd8 00b8 c01289bc c0268ccc 0002 0001 c206ca60 c5e58b40 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 0c 90 8b 03 8b 53 04 89 50 04 89 02 89 d8 2b 05 kernel BUG at page_alloc.c:191! invalid operand: CPU: 0 EIP: 0010:[] EFLAGS: 00010086 eax: 0020 ebx: c1041c78 ecx: c5e58b40 edx: 0005 esi: c0268a74 edi: 0001 ebp: esp: c19c3d40 ds: 0018 es: 0018 ss: 0018 Process gdmlogin (pid: 7662, stackpage=c19c3000) Stack: c0225aa5 c0225c33 00bf c0268a40 c0268cd4 0002 04ae 0286 c0268a40 c0128872 c0268ccc c0268cd8 00b8 c01289bc c0268ccc 0002 0001 c0ec9f60 c5e58b40 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 0c 90 8b 03 8b 53 04 89 50 04 89 02 89 d8 2b 05 kernel BUG at page_alloc.c:191! invalid operand: CPU: 0 EIP: 0010:[] EFLAGS: 00010082 eax: 0020 ebx: c1041c78 ecx: c5e58960 edx: 0007 esi: c0268a74 edi: 0001 ebp: esp: c19c3e3c ds: 0018 es: 0018 ss: 0018 Process bash (pid: 7665, stackpage=c19c3000) Stack: c0225aa5 c0225c33 00bf c0268a40 c0268cd4 0002 0ff8 0282 c0268a40 c0128872 c0268ccc c0268cd8 00b8 c01289bc c0268ccc 0002 0001 c10682dc c5e58960 Call Trace: [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 0c 90 8b 03 8b 53 04 89 50 04 89 02 89 d8 2b 05 kernel BUG at page_alloc.c:191! invalid operand: CPU: 0 EIP: 0010:[] EFLAGS: 00010082 eax: 0020 ebx: c1041c78 ecx: c5e58b40 edx: 0008 esi: c0268a74 edi: 0001 ebp: esp: c1943e3c ds: 0018 es: 0018 ss: 0018 Process bash (pid: 7668, stackpage=c1943000) Stack: c0225aa5 c0225c33 00bf c0268a40 c0268cd4 0002 0ff8 0282 c0268a40 c0128872 c0268ccc c0268cd8 00b8 c01289bc c0268ccc 0002 0001 c106c148 c5e58b40 Call Trace: [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 0c 90 8b 03 8b 53 04 89 50 04 89 02 89 d8 2b 05 kernel BUG at page_alloc.c:191! invalid operand: CPU: 0 EIP: 0010:[] EFLAGS: 00010082 eax: 0020 ebx: c1041c78 ecx: c5e58b40 edx: 0007 esi: c0268a74 edi: 0001 ebp: esp: c0f97e3c ds: 0018 es: 0018 ss: 0018 Process bash (pid: 7672, stackpage=c0f97000) Stack: c0225aa5 c0225c33 00bf c0268a40 c0268cd4 0002 0011 0282 c02
PROBLEM: crash with linux 2.4.2
Hello, I ran 2.4.2 under heavy load since 2 days. I try to decrypt my /etc/passwd files with the program John the Ripper on a Pentium133. This process is very long ;-) I don't understand the error. Hope it will be useful. Pierre you can see the load average and the uptime after crash: 10:09am up 5 days, 21:02, 2 users, load average: 18.68, 18.07, 16.85 the output of dmesg command after crash : 5e58960 edx: 0004 esi: c0268a74 edi: 0001 ebp: esp: c1945d28 ds: 0018 es: 0018 ss: 0018 Process fvwm95 (pid: 7630, stackpage=c1945000) Stack: c0225aa5 c0225c33 00bf c0268a40 c0268cd4 0002 c0dda14f 0286 c0268a40 c0128872 c0268ccc c0268cd8 00b8 c01289bc c0268ccc 0002 0001 c1945df8 Call Trace: [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 0c 90 8b 03 8b 53 04 89 50 04 89 02 89 d8 2b 05 kernel BUG at page_alloc.c:191! invalid operand: CPU: 0 EIP: 0010:[] EFLAGS: 00010092 eax: 0020 ebx: c1041c78 ecx: c5e58960 edx: 0005 esi: c0268a74 edi: 0001 ebp: esp: c1d97e08 ds: 0018 es: 0018 ss: 0018 Process sh (pid: 7631, stackpage=c1d97000) Stack: c0225aa5 c0225c33 00bf c0268a40 c0268cd4 0002 06ab 0286 c0268a40 c0128872 c0268ccc c0268cd8 00b8 c01289bc c0268ccc 0002 0001 c11b2dd8 c51fa420 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 0c 90 8b 03 8b 53 04 89 50 04 89 02 89 d8 2b 05 kernel BUG at page_alloc.c:191! invalid operand: CPU: 0 EIP: 0010:[] EFLAGS: 00010086 eax: 0020 ebx: c1041c78 ecx: c5e58960 edx: 0005 esi: c0268a74 edi: 0001 ebp: esp: c1d97e1c ds: 0018 es: 0018 ss: 0018 Process sh (pid: 7632, stackpage=c1d97000) Stack: c0225aa5 c0225c33 00bf c0268a40 c0268cd4 0002 c0268ccc 0282 c0268a40 c0128872 c0268ccc c0268cd8 00b8 c01289bc c0268ccc 0002 0001 c0ec9be0 c5e58960 Call Trace: [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 0c 90 8b 03 8b 53 04 89 50 04 89 02 89 d8 2b 05 kernel BUG at page_alloc.c:191! invalid operand: CPU: 0 EIP: 0010:[] EFLAGS: 00010086 eax: 0020 ebx: c1041c78 ecx: c5e58b40 edx: 0005 esi: c0268a74 edi: 0001 ebp: esp: c215fd40 ds: 0018 es: 0018 ss: 0018 Process gdmlogin (pid: 7658, stackpage=c215f000) Stack: c0225aa5 c0225c33 00bf c0268a40 c0268cd4 0002 04ae 0286 c0268a40 c0128872 c0268ccc c0268cd8 00b8 c01289bc c0268ccc 0002 0001 c206ca60 c5e58b40 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 0c 90 8b 03 8b 53 04 89 50 04 89 02 89 d8 2b 05 kernel BUG at page_alloc.c:191! invalid operand: CPU: 0 EIP: 0010:[] EFLAGS: 00010086 eax: 0020 ebx: c1041c78 ecx: c5e58b40 edx: 0005 esi: c0268a74 edi: 0001 ebp: esp: c19c3d40 ds: 0018 es: 0018 ss: 0018 Process gdmlogin (pid: 7662, stackpage=c19c3000) Stack: c0225aa5 c0225c33 00bf c0268a40 c0268cd4 0002 04ae 0286 c0268a40 c0128872 c0268ccc c0268cd8 00b8 c01289bc c0268ccc 0002 0001 c0ec9f60 c5e58b40 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 0c 90 8b 03 8b 53 04 89 50 04 89 02 89 d8 2b 05 kernel BUG at page_alloc.c:191! invalid operand: CPU: 0 EIP: 0010:[] EFLAGS: 00010082 eax: 0020 ebx: c1041c78 ecx: c5e58960 edx: 0007 esi: c0268a74 edi: 0001 ebp: esp: c19c3e3c ds: 0018 es: 0018 ss: 0018 Process bash (pid: 7665, stackpage=c19c3000) Stack: c0225aa5 c0225c33 00bf c0268a40 c0268cd4 0002 0ff8 0282 c0268a40 c0128872 c0268ccc c0268cd8 00b8 c01289bc c0268ccc 0002 0001 c10682dc c5e58960 Call Trace: [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 0c 90 8b 03 8b 53 04 89 50 04 89 02 89 d8 2b 05 kernel BUG at page_alloc.c:191! invalid operand: CPU: 0 EIP: 0010:[] EFLAGS: 00010082 eax: 0020 ebx: c1041c78 ecx: c5e58b40 edx: 0008 esi: c0268a74 edi: 0001 ebp: esp: c1943e3c ds: 0018 es: 0018 ss: 0018 Process bash (pid: 7668, stackpage=c1943000) Stack: c0225aa5 c0225c33 00bf c0268a40 c0268cd4 0002 0ff8 0282 c0268a40 c0128872 c0268ccc c0268cd8 00b8 c01289bc c0268ccc 0002 0001 c106c148 c5e58b40 Call Trace: [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 0c 90 8b 03 8b 53 04 89 50 04 89 02 89 d8 2b 05 kernel BUG at page_alloc.c:191! invalid operand: CPU: 0 EIP: 0010:[] EFLAGS: 00010082 eax: 0020 ebx: c1041c78 ecx: c5e58b40 edx: 0007 esi: c0268a74 edi: 0001 ebp: esp: c0f97e3c ds: 0018 es: 0018 ss: 0018 Process bash (pid: 7672, stackpage=c0f97000) Stack: c0225aa5 c0225c33 00bf c0268a40 c0268cd4 0002 0011 0282 c02
kernel crash with 2.4.2
Hy, I post a kernel crash in this adress last week. (see [EMAIL PROTECTED] it's me!) Now that i had the crash another times, i used the program ksymoops to trace the problem. I use a 2.4.2 Linux kernel on a i586 (Pentium 133Mhz) Here is the /var/log/syslog trace: Mar 10 04:40:02 palerme kernel: Unable to handle kernel NULL pointer dereference at virtual address Mar 10 04:40:02 palerme kernel: *pde = Mar 11 04:40:02 palerme kernel: Unable to handle kernel NULL pointer dereference at virtual address Mar 11 04:40:02 palerme kernel: *pde = Mar 12 04:40:02 palerme kernel: Unable to handle kernel NULL pointer dereference at virtual address Mar 12 04:40:02 palerme kernel: *pde = I use a Slackware Linux distribution. With Slackware the crontab execute the command updatedb each day at 4:40 am. I used this command to generate the ksymoops output : dmesg > dmesg_output; ksymoops < dmesg_output There is no modules in the kernel. Hope it will be helpfull. Pierre ksymoops 2.3.7 on i586 2.4.2. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.2/ (default) -m /usr/src/linux/System.map (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. No modules in ksyms, skipping objects Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod file? Intel Pentium with F0 0F bug - workaround enabled. Uhhuh. NMI received. Dazed and confused, but trying to continue Uhhuh. NMI received for unknown reason 35. Unable to handle kernel NULL pointer dereference at virtual address c013f084 *pde = Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010203 eax: c11cac30 ebx: ffe8 ecx: 000e edx: c11c esi: 3af9f1c1 edi: c58d3f68 ebp: esp: c58d3f04 ds: 0018 es: 0018 ss: 0018 Process find (pid: 6064, stackpage=c58d3000) Stack: 3af9f1c1 c58d3f68 c1cc800b c11cac30 c1cc8000 3af9f1c1 000b c0137000 c0cbf8c0 c58d3f68 3af9f1c1 c01377f8 c0cbf8c0 c58d3f68 c1cc8000 c58d3fa4 b4e0 c58d2000 c0136e20 c58d2000 0008 Call Trace: [] [] [] [] [] [] [] Code: 8b 6d 00 8b 74 24 18 39 73 48 75 78 8b 74 24 24 39 73 0c 75 >>EIP; c013f084<= Trace; c0137000 Trace; c01377f8 Trace; c0136e20 Trace; c0137e34 <__user_walk+3c/58> Trace; c0134aee Trace; c012d1cf Trace; c0108e13 Code; c013f084 <_EIP>: Code; c013f084<= 0: 8b 6d 00 movl 0x0(%ebp),%ebp <= Code; c013f087 3: 8b 74 24 18 movl 0x18(%esp,1),%esi Code; c013f08b 7: 39 73 48 cmpl %esi,0x48(%ebx) Code; c013f08e a: 75 78 jne84 <_EIP+0x84> c013f108 Code; c013f090 c: 8b 74 24 24 movl 0x24(%esp,1),%esi Code; c013f094 10: 39 73 0c cmpl %esi,0xc(%ebx) Code; c013f097 13: 75 00 jne15 <_EIP+0x15> c013f099 Unable to handle kernel NULL pointer dereference at virtual address c013f084 *pde = Oops: CPU:0 EIP:0010:[] EFLAGS: 00010203 eax: c11cac30 ebx: ffe8 ecx: 000e edx: c11c esi: 3af9f1c1 edi: c1cb9f68 ebp: esp: c1cb9f04 ds: 0018 es: 0018 ss: 0018 Process find (pid: 6844, stackpage=c1cb9000) Stack: 3af9f1c1 c1cb9f68 c371400b c11cac30 c3714000 3af9f1c1 000b c0137000 c0cbf8c0 c1cb9f68 3af9f1c1 c01377f8 c0cbf8c0 c1cb9f68 c3714000 c1cb9fa4 b4e0 c1cb8000 c0136e20 c1cb8000 0008 Call Trace: [] [] [] [] [] [] [] Code: 8b 6d 00 8b 74 24 18 39 73 48 75 78 8b 74 24 24 39 73 0c 75 >>EIP; c013f084<= Trace; c0137000 Trace; c01377f8 Trace; c0136e20 Trace; c0137e34 <__user_walk+3c/58> Trace; c0134aee Trace; c012d1cf Trace; c0108e13 Code; c013f084 <_EIP>: Code; c013f084<= 0: 8b 6d 00 movl 0x0(%ebp),%ebp <= Code; c013f087 3: 8b 74 24 18 movl 0x18(%esp,1),%esi Code; c013f08b 7: 39 73 48 cmpl %esi,0x48(%ebx) Code; c013f08e a: 75 78 jne84 <_EIP+0x84> c013f108 Code; c013f090 c: 8b 74 24 24 movl 0x24(%esp,1),%esi Code; c013f094 10: 39 73 0c cmpl %esi,0xc(%ebx) Code; c013f097 13: 75 00 jne15 <_EIP+0x15> c013f099 Unable to handle kerne
RE: [PATCH] fix a bug in ioctl(CDROMREADAUDIO) in cdrom.c in 2.2
Le 14-Mar-2001, Jani Jaakkola écrivait : > > Using ioctl(CDROMREADAUDIO) with nframes argument being larger than 8 and > not divisible by 8 causes kernel to read and return more audio data than > was requested. This is bad since it clobbers up processes memory > (I noticed this when my patched cdparanoia segfaulted). Same thing for 2.4.2. Is my allocation loop "over engineering", or just plain bad thing to do ? Regards, Pierre. -- Linux blade.concept-micro.com 2.4.3-pre4 #1 Wed Mar 14 22:19:14 CET 2001 i686 unknown 2:04pm up 11:29, 4 users, load average: 2.66, 2.80, 2.26 myreadaudio.patch
Re: About DC-315U scsi driver
Le 13-Mar-2001, ³¯¤ý®i écrivait : >Today I try to recompiler a new kernel with integrated driver. And burn a > test > CDR. The errors are still alive. FYI, burning CDRs with this adapter seldom work under Windows too, Tekram adapters are usually fine, but those DC-315* & DC-395* really look like chip stuff... BR, Pierre. -- Linux blade.concept-micro.com 2.4.3-pre4 #1 Wed Mar 14 22:19:14 CET 2001 i686 unknown 7:30pm up 1 day, 16:12, 7 users, load average: 1.03, 1.07, 1.08 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] devfsd, compiling on glibc22x
David Ford wrote:
>
> This patch is simple, defines RTLD_NEXT if not previously defined.
>
> --- devfsd.c.orig Sat Jan 27 18:14:19 2001
> +++ devfsd.cSat Jan 27 18:15:46 2001
> @@ -165,6 +165,7 @@
> Last updated by Richard Gooch 3-JUL-2000: Added "-C
> /etc/modules.devfs"
>when calling modprobe(8). Fail if a configuration line has EXECUTE
> modprobe.
>
> +Updated by David Ford 27-JAN-2001: Added RTLD_NEXT define
>
> */
> #include
> @@ -221,6 +222,10 @@
> #define AC_MKNEWCOMPAT 8
> #define AC_RMOLDCOMPAT 9
> #define AC_RMNEWCOMPAT 10
> +
> +#ifndef RTLD_NEXT
> +# define RTLD_NEXT ((void *) -1l)
> +#endif
>
> struct permissions_type
> {
for me :
make CFLAGS='-O2 -I. -D_GNU_SOURCE'
compiles without any patch. is it correct ?
--
Pierre Rousselet <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Need for more ISO8859 codepages?
Rhys Jones wrote: > Any and all feedback appreciated. need for less codepages. Is 8859-1 still useful ? Why not moving to 8859-15 (and cp1252) ? -- ---- Pierre Rousselet <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Keyboard Scancode Problems
"Udo A. Steinberg" wrote: > keyboard: unrecognized scancode (70) - ignored > keyboard: unrecognized scancode (66) - ignored > keyboard: unknown scancode e0 71 > keyboard: unknown scancode e0 70 which key do you press to generate such scancodes ? #showkey -s -- ---- Pierre Rousselet <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.1 segfault when doing "ls /dev/"
Pierfrancesco Caci wrote: >48 ?S 0:00 /sbin/devfsd /dev on my box devfsd has pid 15, it comes just after the [kdaems] 1 ?S 0:04 init 2 ?SW 0:00 [keventd] 3 ?SW 0:00 [kapm-idled] 4 ?SW 0:00 [kswapd] 5 ?SW 0:00 [kreclaimd] 6 ?SW 0:00 [bdflush] 7 ?SW 0:00 [kupdate] 8 ?SW 0:00 [kreiserfsd] 15 ?S 0:00 devfsd /dev and it works with 2.4.x -- ---- Pierre Rousselet <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.1 segfault when doing "ls /dev/"
Pierfrancesco Caci wrote: > I can't see how this can affect performance/funtionality of > devfsd. Can you try to stop the daemon and restart it to see if > continues to work as before ? /dev is mounted at boot time by the kernel (CONFIG_DEVFS_MOUNT=y). The system boots and runs without devfsd. You just can't start any process calling for non-existing device under /dev and not created by devfsd. For instance pppd or mc won't start by lack of pseudo-tty esd needs /dev/dsp ... i was thinking the trouble may come from some programme launched by your boot scripts before devfsd is running. is your version of fileutils > 4.0.28 (ls --version) ? -- -------- Pierre Rousselet <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.1 segfault when doing "ls /dev/"
Pierfrancesco Caci wrote: > Yes I know this. Actually, booting with "devfs=nomount s" is the only > way to update the boot record with lilo and my existing lilo.conf. i can't do that on my box, /dev is only a mount point for devfs. assuming your /dev directory is dirty from something else than devfsd, could you try this while devfsd is running : #mkdir /devtest #mount none -t devfs /devtest #ls /devtest -- ---- Pierre Rousselet <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PS/2 Mouse/Keyboard conflict and lockup
Peter Horton wrote: > On Thu, Feb 08, 2001 at 03:35:00AM +0100, Udo A. Steinberg wrote: >> After upgrading my Asus A7V Bios from 1003 to 1005D > Similiar problems here after my upgrade to 1005D. you are not booting from a floppy, are you ? -- -------- Pierre Rousselet <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
tmpfs + sendfile bug ?
Hi all, I just found a problem GETting a file stored in tmpfs using proftpd; I always get a "426 Transfer aborted. Data connection closed." That could be a bug with tmpfs and sendfile in 2.4.5-pre4 : [...] read(8, "%PDF-1.4\r%\342\343\317\323\r\n870 0 obj\r<< \r/L"..., 8192) = 8192 shmat(11, 0x4cfe65, 0x3)= 0xb4d4 sendfile(11, 8, [0], 5045861) = -1 EINVAL (Invalid argument) [...] Any idea ? Best regards, Pierre. -- We are the dot in 0.2 Kb/s - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: tmpfs + sendfile bug ?
On 21-May-2001 David Schwartz wrote: > >> Any idea ? > > Looks like a bug in the program. If 'sendfile' returns 'EINVAL', that means > you can't use 'sendfile' to send this particular file, and should default to > read/write or mmap/write. If this program doesn't, it doesn't understand > Linux's 'sendfile' semantics. Agreed, I came up to the same conclusion. Applications shouldn't assume that sendfile will always work, and be ready to fall back to the traditional DIY way of sending data. I just downloaded more recent sources of proftpd (1.2.2rc2), and it looks fixed, already... Time to upgrade :) Regards, Pierre. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
disk-based fds in select/poll
Pardon me if some parts of this seem clueless. While I'm no newbie in userland, kernelspace I don't play in very often... It's fairly widely-known that select/poll returns immediately when testing a filesystem-based file descriptor for writability or readability. On top of this, even when in non-blocking mode, read() could block if the pages needed aren't in core. sendfile() behaves in a similar way. What would be needed to alleviate this? I am thinking that a read() (or sendfile()) that would block because the pages aren't in core should instead post a request for the pages to be loaded (some kind of readahead mecanism?) and return immediately (maybe having given some data that *was* in core). A subsequent read() could have the data available, but not necessarily (again, it should give whatever it has in core, but return immediately). sendfile() would be a lot more tricky to fix in that way I guess, but could still be possible (the destination fd would be unwritable for a while, until the transfer is finished). Also, the complexity would be higher (instead of simply causing readahead to happen (which might anyway), it would have to trigger the readahead, then get notification of when the pages are in core to send over, all the while preventing data from being written to the destination fd in some way). In the mean time, I was also wondering if issuing smaller read() requests in a row might give me a better chance of success. I *know* read() will block, but if I only ask for, say, a page of data (rather than asking for the full data and relying on the non-blocking to return EAGAIN (like it should, IMHO!)), it shouldn't take too long, and could possibly trigger some readahead to be done by the kernel, right? Or will the readahead be done "on my own time", read() only returning after the whole thing (my request + readahead) has been done? I remember seeing a suggestion by Linus for an event-based I/O interface, similar to kqueue on FreeBSD but much simpler. I'd just say "I want it too!", ok? :-) I know about the mincore() trick with mmap()'d files, but with small files, mmap()ing might not make sense (could be very often). SGI's AIO might be a solution here, does it use threads? I'm trying to avoid context switching as much as possible, to keep the CPU cache as warm as possible. Well, I might not have the choice to use threads, after all... (sorry if this message got in twice, I used an NNTP gateway the previous time, I don't think it got through) -- Pierre Phaneuf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: disk-based fds in select/poll
Alan Cox wrote: > > I am thinking that a read() (or sendfile()) that would block because the > > pages aren't in core should instead post a request for the pages to be > > loaded (some kind of readahead mecanism?) and return immediately (maybe > > having given some data that *was* in core). A subsequent read() could > > reads posts a readahead anyway so streaming reads tend not to block much Ok, so while knowing about select "lying" about readability of a file fd, if I would stick a file fd in my select-based loop anyway, but would only try to read a bit at a time (say, 4K or 8K) would trigger readahead, yet finish quickly enough that I can get back to processing other fds in my select loop? Wouldn't that cause too many syscalls to be done? Or if this is actually the way to go without an actual thread, how should I go determining an optimal block size? Was there anything new on the bind_event/get_events API idea that Linus proposed a while ago? That one had got me foaming at the mouth... :-) -- Pierre Phaneuf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: lowlatency 2.2.19
Le 05-Jun-2001, Andrew Morton écrivait : > Some video cards have a PCI cheat-mode in which they keep > the PCI bus busy until they are ready to accept new > commands, rather forcing a retry. Figures of up to > twenty milliseconds have been mentioned. Your X server > *may* support the `PCIRetry' config option which will > defeat this. Just FYI (I think it's S3 Virge specific, but maybe not), I solved my RX packets loss on my ADSL interface after I read the message http://www.xfree86.org/pipermail/xpert/2000-November/003402.html and used Section "Device" Identifier "Generic Video Card" Driver "s3virge" Option "fpm_vram" Option "fifo_aggressive" Option "pci_burst" "on" Option "pci_retry" "on" Option "XaaNoCPUToScreenColorExpandFill" EndSection in my XFConfig-4. (The whole thread seems to be worth a read.) Best regards, Pierre. -- We are the dot in 0.2 Kb/s - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] wbsd version bump
Version increase of the wbsd driver. Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]> Even though the changes are minor for the next release an increasing version number simplifies my support issues. Index: linux/drivers/mmc/wbsd.c === --- linux/drivers/mmc/wbsd.c (revision 151) +++ linux/drivers/mmc/wbsd.c (working copy) @@ -42,7 +42,7 @@ #include "wbsd.h" #define DRIVER_NAME "wbsd" -#define DRIVER_VERSION "1.2" +#define DRIVER_VERSION "1.3" #ifdef CONFIG_MMC_DEBUG #define DBG(x...) \
[PATCH] Fix whitespace in wbsd
Remove lots of trailing whitespace caused by not-so-great editor.
Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]>
--- linux/drivers/mmc/wbsd.c.orig 2005-07-11 14:26:40.0 +0200
+++ linux/drivers/mmc/wbsd.c 2005-07-11 14:27:02.0 +0200
@@ -93,7 +93,7 @@
static inline void wbsd_unlock_config(struct wbsd_host* host)
{
BUG_ON(host->config == 0);
-
+
outb(host->unlock_code, host->config);
outb(host->unlock_code, host->config);
}
@@ -101,14 +101,14 @@
static inline void wbsd_lock_config(struct wbsd_host* host)
{
BUG_ON(host->config == 0);
-
+
outb(LOCK_CODE, host->config);
}
static inline void wbsd_write_config(struct wbsd_host* host, u8 reg, u8 value)
{
BUG_ON(host->config == 0);
-
+
outb(reg, host->config);
outb(value, host->config + 1);
}
@@ -116,7 +116,7 @@
static inline u8 wbsd_read_config(struct wbsd_host* host, u8 reg)
{
BUG_ON(host->config == 0);
-
+
outb(reg, host->config);
return inb(host->config + 1);
}
@@ -140,21 +140,21 @@
static void wbsd_init_device(struct wbsd_host* host)
{
u8 setup, ier;
-
+
/*
* Reset chip (SD/MMC part) and fifo.
*/
setup = wbsd_read_index(host, WBSD_IDX_SETUP);
setup |= WBSD_FIFO_RESET | WBSD_SOFT_RESET;
wbsd_write_index(host, WBSD_IDX_SETUP, setup);
-
+
/*
* Set DAT3 to input
*/
setup &= ~WBSD_DAT3_H;
wbsd_write_index(host, WBSD_IDX_SETUP, setup);
host->flags &= ~WBSD_FIGNORE_DETECT;
-
+
/*
* Read back default clock.
*/
@@ -164,12 +164,12 @@
* Power down port.
*/
outb(WBSD_POWER_N, host->base + WBSD_CSR);
-
+
/*
* Set maximum timeout.
*/
wbsd_write_index(host, WBSD_IDX_TAAC, 0x7F);
-
+
/*
* Test for card presence
*/
@@ -177,7 +177,7 @@
host->flags |= WBSD_FCARD_PRESENT;
else
host->flags &= ~WBSD_FCARD_PRESENT;
-
+
/*
* Enable interesting interrupts.
*/
@@ -200,9 +200,9 @@
static void wbsd_reset(struct wbsd_host* host)
{
u8 setup;
-
+
printk(KERN_ERR DRIVER_NAME ": Resetting chip\n");
-
+
/*
* Soft reset of chip (SD/MMC part).
*/
@@ -214,9 +214,9 @@
static void wbsd_request_end(struct wbsd_host* host, struct mmc_request* mrq)
{
unsigned long dmaflags;
-
+
DBGF("Ending request, cmd (%x)\n", mrq->cmd->opcode);
-
+
if (host->dma >= 0)
{
/*
@@ -232,7 +232,7 @@
*/
wbsd_write_index(host, WBSD_IDX_DMA, 0);
}
-
+
host->mrq = NULL;
/*
@@ -275,7 +275,7 @@
host->offset = 0;
host->remain = host->cur_sg->length;
}
-
+
return host->num_sg;
}
@@ -297,12 +297,12 @@
struct scatterlist* sg;
char* dmabuf = host->dma_buffer;
char* sgbuf;
-
+
size = host->size;
-
+
sg = data->sg;
len = data->sg_len;
-
+
/*
* Just loop through all entries. Size might not
* be the entire list though so make sure that
@@ -317,23 +317,23 @@
memcpy(dmabuf, sgbuf, sg[i].length);
kunmap_atomic(sgbuf, KM_BIO_SRC_IRQ);
dmabuf += sg[i].length;
-
+
if (size < sg[i].length)
size = 0;
else
size -= sg[i].length;
-
+
if (size == 0)
break;
}
-
+
/*
* Check that we didn't get a request to transfer
* more data than can fit into the SG list.
*/
-
+
BUG_ON(size != 0);
-
+
host->size -= size;
}
@@ -343,12 +343,12 @@
struct scatterlist* sg;
char* dmabuf = host->dma_buffer;
char* sgbuf;
-
+
size = host->size;
-
+
sg = data->sg;
len = data->sg_len;
-
+
/*
* Just loop through all entries. Size might not
* be the entire list though so make sure that
@@ -363,30 +363,30 @@
memcpy(sgbuf, dmabuf, sg[i].length);
kunmap_atomic(sgbuf, KM_BIO_SRC_IRQ);
dmabuf += sg[i].length;
-
+
if (size < sg[i].length)
size = 0;
else
size -= sg[i].length;
-
+
if (size == 0)
break;
}
-
+
/*
* Check that we didn't get a request to transfer
* more data than can fit into the SG list.
*/
-
+
BUG_ON(size != 0);
-
+
host->size -= size;
}
/*
* Command handling
*/
-
+
static inline void wbsd_get_short_reply(struct wbsd_host* host,
struct mmc_command* cmd)
{
@@ -398,7 +398,7 @@
cmd->error = MMC_ERR_INVALID;
return;
}
-
+
cmd->resp[0] =
wbsd_read_index(host, WBSD_IDX_RESP12) << 24;
cmd->resp[0] |=
@@ -415,7 +415,7 @@
struct mmc_command* cmd)
{
int i;
-
+
/*
* Correct response type?
*/
@@ -424,7 +424,7 @@
cmd->error = MMC_ERR_INVALID;
return;
}
-
+
for (i = 0;i < 4;i++)
{
cmd->resp[i] =
@@ -442,7 +442,7 @@
{
int i;
u8 status, isr;
-
+
DBGF("Sending cmd (%x)\n", cmd->opcode);
/*
@@ -451,16 +451,16 @@
* transfer.
*/
host->isr = 0;
-
+
/*
* Send the command (CRC calculated by host).
*/
outb(cmd->opcode, host->base + WBSD_CMDR);
for (i = 3;i >= 0;i--)
outb((cmd->arg >> (i * 8)) & 0xf
[PATCH] MMC host class
Create a mmc_host class to allow enumeration of MMC host controllers
even though they have no card(s) inserted.
Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]>
(This will also allow cards to be enumerated by being able to find the
hosts.)
Index: linux-wbsd/drivers/mmc/mmc.h
===
--- linux-wbsd/drivers/mmc/mmc.h (revision 134)
+++ linux-wbsd/drivers/mmc/mmc.h (working copy)
@@ -13,4 +13,6 @@
void mmc_init_card(struct mmc_card *card, struct mmc_host *host);
int mmc_register_card(struct mmc_card *card);
void mmc_remove_card(struct mmc_card *card);
+int mmc_register_host(struct mmc_host *host);
+void mmc_unregister_host(struct mmc_host *host);
#endif
Index: linux-wbsd/drivers/mmc/mmc_sysfs.c
===
--- linux-wbsd/drivers/mmc/mmc_sysfs.c (revision 153)
+++ linux-wbsd/drivers/mmc/mmc_sysfs.c (working copy)
@@ -20,6 +20,7 @@
#define dev_to_mmc_card(d) container_of(d, struct mmc_card, dev)
#define to_mmc_driver(d) container_of(d, struct mmc_driver, drv)
+#define cls_to_mmc_host(d) container_of(d, struct mmc_host, class_dev)
#define MMC_ATTR(name, fmt, args...) \
static ssize_t mmc_##name##_show (struct device *dev, char *buf) \
@@ -224,14 +225,51 @@
put_device(&card->dev);
}
+static void mmc_host_class_dev_release(struct class_device *dev)
+{
+}
+
+static struct class mmc_host_class = {
+ .name = "mmc_host",
+ .release = &mmc_host_class_dev_release,
+};
+
+/*
+ * Internal function. Register a new MMC host with the MMC class.
+ */
+int mmc_register_host(struct mmc_host *host)
+{
+ host->class_dev.dev = host->dev;
+ host->class_dev.class = &mmc_host_class;
+ strlcpy(host->class_dev.class_id, host->host_name, BUS_ID_SIZE);
+
+ return class_device_register(&host->class_dev);
+}
+
+/*
+ * Internal function. Unregister a MMC host with the MMC class.
+ */
+void mmc_unregister_host(struct mmc_host *host)
+{
+ class_device_unregister(&host->class_dev);
+}
static int __init mmc_init(void)
{
- return bus_register(&mmc_bus_type);
+ int retval;
+
+ retval = bus_register(&mmc_bus_type);
+ if (retval)
+ return retval;
+ retval = class_register(&mmc_host_class);
+ if (retval)
+ return retval;
+ return 0;
}
static void __exit mmc_exit(void)
{
+ class_unregister(&mmc_host_class);
bus_unregister(&mmc_bus_type);
}
Index: linux-wbsd/drivers/mmc/mmc.c
===
--- linux-wbsd/drivers/mmc/mmc.c (revision 153)
+++ linux-wbsd/drivers/mmc/mmc.c (working copy)
@@ -1196,6 +1196,8 @@
snprintf(host->host_name, sizeof(host->host_name),
"mmc%d", host_num++);
+ mmc_register_host(host);
+
mmc_power_off(host);
mmc_detect_change(host);
@@ -1220,6 +1222,8 @@
mmc_remove_card(card);
}
+
+ mmc_unregister_host(host);
mmc_power_off(host);
}
Index: linux-wbsd/include/linux/mmc/host.h
===
--- linux-wbsd/include/linux/mmc/host.h (revision 153)
+++ linux-wbsd/include/linux/mmc/host.h (working copy)
@@ -69,6 +69,7 @@
struct mmc_host {
struct device *dev;
+ struct class_device class_dev;
struct mmc_host_ops *ops;
unsigned int f_min;
unsigned int f_max;
Re: [PATCH] MMC host class
Russell King wrote: >No no no no no. Repeat after me ten times. Empty or non-existant release >functions are bad and cause oopsen. I will not create code which does >this. > > Sorry. I thought it was a generic cleanup function and since nothing was allocated in the register function I didn't think it needed to do anything. I tried to find some documentation about how classes were handled but eventually had to resort to looking at other code. Perhaps I should look at the documentation about kernel objects instead? >What this means is that mmc_host itself becomes a refcounted sysfs >object which needs to follow the lifetime rules associated therewith. > >Luckily, I thought about this earlier on, so there's a core mmc function >to allocate the beast, register it, unregister it, and finally free it. > >The allocation function should initialise class_dev as much as possible. > > The name field cannot be initialised since it isn't generated until registration. And I avoided filling in the other stuff at allocation so that I could keep knowledge of mmc_host_class in mmc_sysfs.c. >The registration function should add the class device with the class >model. The unregistration should remove the class device from the class >model, but _not_ free it. The free function should drop the last >reference to the class device, which results in the remove function >(eventually) being called. Finally, the remove function can free the >mmc_host. > > With the remove function you mean the .release in the class struct? >Also note that since we have a class_dev, the mmc_host 'dev' field can >be removed. However, we'll probably have to update the host drivers >to do this, so it should be a separate patch. > > > I'll read up on kernel objects and sysfs and put together a new patch then. Rgds Pierre - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] MMC host class
Russell King wrote:
>The allocation function should initialise class_dev as much as possible.
>The registration function should add the class device with the class
>model. The unregistration should remove the class device from the class
>model, but _not_ free it. The free function should drop the last
>reference to the class device, which results in the remove function
>(eventually) being called. Finally, the remove function can free the
>mmc_host.
>
>
New patch according to above system. I've moved the naming a bit earlier
to avoid having a nameless kobj floating around.
>Also note that since we have a class_dev, the mmc_host 'dev' field can
>be removed. However, we'll probably have to update the host drivers
>to do this, so it should be a separate patch.
>
>
>
I believe there's a bit of abstraction to be gained from not poking
around inside the class_dev struct in too many places. It's not like
we're wasting any large amounts of memory.
Rgds
Pierre
Index: linux-wbsd/drivers/mmc/mmc.h
===
--- linux-wbsd/drivers/mmc/mmc.h (revision 134)
+++ linux-wbsd/drivers/mmc/mmc.h (working copy)
@@ -13,4 +13,7 @@
void mmc_init_card(struct mmc_card *card, struct mmc_host *host);
int mmc_register_card(struct mmc_card *card);
void mmc_remove_card(struct mmc_card *card);
+void mmc_init_host(struct mmc_host *host);
+int mmc_register_host(struct mmc_host *host);
+void mmc_unregister_host(struct mmc_host *host);
#endif
Index: linux-wbsd/drivers/mmc/mmc_sysfs.c
===
--- linux-wbsd/drivers/mmc/mmc_sysfs.c (revision 153)
+++ linux-wbsd/drivers/mmc/mmc_sysfs.c (working copy)
@@ -20,6 +20,7 @@
#define dev_to_mmc_card(d) container_of(d, struct mmc_card, dev)
#define to_mmc_driver(d) container_of(d, struct mmc_driver, drv)
+#define cls_dev_to_mmc_host(d) container_of(d, struct mmc_host, class_dev)
#define MMC_ATTR(name, fmt, args...) \
static ssize_t mmc_##name##_show (struct device *dev, char *buf) \
@@ -224,14 +225,64 @@
put_device(&card->dev);
}
+static void mmc_host_class_dev_release(struct class_device *dev)
+{
+ struct mmc_host *host = cls_dev_to_mmc_host(dev);
+ kfree(host);
+}
+
+static struct class mmc_host_class = {
+ .name = "mmc_host",
+ .release = &mmc_host_class_dev_release,
+};
+
+void mmc_init_host(struct mmc_host *host)
+{
+ static unsigned int host_num;
+
+ snprintf(host->host_name, sizeof(host->host_name),
+ "mmc%d", host_num++);
+
+ host->class_dev.dev = host->dev;
+ host->class_dev.class = &mmc_host_class;
+ strlcpy(host->class_dev.class_id, host->host_name, BUS_ID_SIZE);
+
+ class_device_initialize(&host->class_dev);
+ class_device_get(&host->class_dev);
+}
+
+/*
+ * Internal function. Register a new MMC host with the MMC class.
+ */
+int mmc_register_host(struct mmc_host *host)
+{
+ return class_device_add(&host->class_dev);
+}
+
+/*
+ * Internal function. Unregister a MMC host with the MMC class.
+ */
+void mmc_unregister_host(struct mmc_host *host)
+{
+ class_device_unregister(&host->class_dev);
+}
static int __init mmc_init(void)
{
- return bus_register(&mmc_bus_type);
+ int retval;
+
+ retval = bus_register(&mmc_bus_type);
+ if (retval)
+ return retval;
+ retval = class_register(&mmc_host_class);
+ if (retval)
+ return retval;
+ return 0;
}
static void __exit mmc_exit(void)
{
+ class_unregister(&mmc_host_class);
bus_unregister(&mmc_bus_type);
}
Index: linux-wbsd/drivers/mmc/mmc.c
===
--- linux-wbsd/drivers/mmc/mmc.c (revision 153)
+++ linux-wbsd/drivers/mmc/mmc.c (working copy)
@@ -1178,6 +1178,8 @@
host->max_phys_segs = 1;
host->max_sectors = 1 << (PAGE_CACHE_SHIFT - 9);
host->max_seg_size = PAGE_CACHE_SIZE;
+
+ mmc_init_host(host);
}
return host;
@@ -1191,10 +1193,7 @@
*/
int mmc_add_host(struct mmc_host *host)
{
- static unsigned int host_num;
-
- snprintf(host->host_name, sizeof(host->host_name),
- "mmc%d", host_num++);
+ mmc_register_host(host);
mmc_power_off(host);
mmc_detect_change(host);
@@ -1222,6 +1221,8 @@
}
mmc_power_off(host);
+
+ mmc_unregister_host(host);
}
EXPORT_SYMBOL(mmc_remove_host);
@@ -1235,7 +1236,8 @@
void mmc_free_host(struct mmc_host *host)
{
flush_scheduled_work();
- kfree(host);
+
+ class_device_put(&host->class_dev);
}
EXPORT_SYMBOL(mmc_free_host);
Index: linux-wbsd/include/linux/mmc/host.h
===
--- linux-wbsd/include/linux/mmc/host.h (revision 153)
+++ linux-wbsd/include/linux/mmc/host.h (working copy)
@@ -69,6 +69,7 @@
struct mmc_host {
struct device *dev;
+ struct class_device class_dev;
struct mmc_host_ops *ops;
unsigned int f_min;
unsigned int f_max;
Re: [PATCH] MMC host class
Russell King wrote: >On Fri, Jul 15, 2005 at 10:21:43PM +0200, Pierre Ossman wrote: > > >>Russell King wrote: >> >> >>>Also note that since we have a class_dev, the mmc_host 'dev' field can >>>be removed. However, we'll probably have to update the host drivers >>>to do this, so it should be a separate patch. >>> >>> >>I believe there's a bit of abstraction to be gained from not poking >>around inside the class_dev struct in too many places. It's not like >>we're wasting any large amounts of memory. >> >> > >I still don't like the needless duplication. How about doing it this >way (see the attached patch.) > > The mmc_hostname macro seems like a good solution. It'll keep the abstraction even if stuff needs to be moved around. I see a problem with waiting until mmc_add_host() until initialising the kobject though. If a driver calls mmc_alloc_host() and then mmc_free_host(), perhaps because of some error, then the structure won't be freed since we rely on release getting called. That's why I tried to get the kobject stuff set up with the allocation. Perhaps it is possible to test if a kobject is initialised and if not free the structure directly? Rgds Pierre - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
IRQ routing problem in 2.6.10-rc2
Sorry about reporting this error so late but the machine in question had gone some time without upgrades. The problem I'm seeing is that IRQs stop working for one of the IRQ slots on the machine. It's only that slot, not the entire IRQ, since the two slots (it's a small machine) both get routed to IRQ 10. I've included dmesg from 2.6.10-rc1 (which works) and 2.6.10-rc2 (which doesn't). I've also tried reverting the patches that modifies arch/i386/kernel/irq.c and arch/i386/pci/irq.c but it didn't solve the problem. So now I need some more input on which patches to try. Rgds Pierre Linux version 2.6.10-rc1 ([EMAIL PROTECTED]) (gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)) #3 Sun Jul 17 03:03:28 CEST 2005 BIOS-provided physical RAM map: BIOS-e820: - 000a (usable) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 0fffe000 (usable) BIOS-e820: 0fffe000 - 1000 (reserved) BIOS-e820: ffe0 - 0001 (reserved) 0MB HIGHMEM available. 255MB LOWMEM available. On node 0 totalpages: 65534 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 61438 pages, LIFO batch:14 HighMem zone: 0 pages, LIFO batch:1 DMI 2.2 present. ACPI: RSDP (v000 DELL ) @ 0x000fdf50 ACPI: RSDT (v001 DELLGX1 0x0002 ASL 0x0061) @ 0x000fdf64 ACPI: FADT (v001 DELLGX1 0x0002 ASL 0x0061) @ 0x000fdf8c ACPI: DSDT (v001 DELLdt_ex 0x1000 MSFT 0x010b) @ 0x ACPI: PM-Timer IO Port: 0x808 Built 1 zonelists Kernel command line: ro root=/dev/hda3 rhgb acpi=force Initializing CPU#0 PID hash table entries: 1024 (order: 10, 16384 bytes) Detected 598.602 MHz processor. Using pmtmr for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 255268k/262136k available (2408k kernel code, 6204k reserved, 620k data, 160k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay loop... 1187.84 BogoMIPS (lpj=593920) 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) CPU: After generic identify, caps: 0383f9ff CPU: After vendor identify, caps: 0383f9ff CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 512K CPU: After all inits, caps:0383f9ff 0040 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: Intel Pentium III (Katmai) stepping 03 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. ACPI: IRQ9 SCI: Edge set to Level Trigger. checking if image is initramfs...it isn't (no cpio magic); looks like an initrd Freeing initrd memory: 202k freed NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xfcaee, last bus=1 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20040816 ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 *10 11 12 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 11 12 15) *0, disabled. ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 *11 12 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 *11 12 15) Linux Plug and Play Support v0.97 (c) Adam Belay usbcore: registered new driver usbfs usbcore: registered new driver hub PCI: Using ACPI for IRQ routing ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11 ACPI: PCI interrupt :00:07.2[D] -> GSI 11 (level, low) -> IRQ 11 ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10 ACPI: PCI interrupt :00:0d.0[A] -> GSI 10 (level, low) -> IRQ 10 ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11 ACPI: PCI interrupt :00:0e.0[A] -> GSI 11 (level, low) -> IRQ 11 ACPI: PCI interrupt :00:11.0[A] -> GSI 11 (level, low) -> IRQ 11 ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 10 ACPI: PCI interrupt :01:00.0[A] -> GSI 10 (level, low) -> IRQ 10 apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac) apm: overridden by ACPI. audit: initializing netlink socket (disabled) audit(1121904612.812:0): initialized Total HugeTLB memory allocated, 0 VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) SELinux: Registering netfilter hooks Initializing Cryptographic API Limiting direct PCI/PCI transfers. pci_hotplug: PCI Hot Plug PCI Core
Re: IRQ routing problem in 2.6.10-rc2
Pierre Ossman wrote: > ** PCI interrupts are no longer routed automatically. If this > ** causes a device to stop working, it is probably because the > ** driver failed to call pci_enable_device(). As a temporary > ** workaround, the "pci=routeirq" argument restores the old > ** behavior. If this argument makes the device work again, > ** please email the output of "lspci" to [EMAIL PROTECTED] > ** so I can fix the driver. If I had just bothered to diff the dmesg:es properly I would have found the problem... Sorry for the noice. Bjorn, the 3c59x driver breaks on this system, but only in one specific slot. lspci -vv included. (The problem is still present on 2.6.12 so I haven't just tried 2.6.10.) Rgds Pierre 00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- 00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset- FastB2B+ 00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR-
Re: IRQ routing problem in 2.6.10-rc2
Jesper Juhl wrote: > >Have you tried the suggestion given "... As a temporary workaround, >the "pci=routeirq" argument..." ? >You could also try the pci=noacpi boot option to see if that changes anything. > > No, I missed that one. The machine works fine with either of those two options. I sent a comment with lspci to Bjorn Helgaas as suggested. >Also, that's a fairly old kernel you have there, could you try >2.6.13-rc3, 2.6.13-rc3-git6 or 2.6.13-rc3-mm1 ? > > > I discovered the problem running 2.6.12. I only tried these kernels to pinpoint where the problem began. Rgds Pierre - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Fix a bit/byte counting error in the MMC/SD code
Richard Purdie wrote: > This fixes what looks like a bit/byte counting error in the MMC/SD code > which was causing data corruption (in the -mm tree). > > Signed-off-by: Richard Purdie <[EMAIL PROTECTED]> Ooops... Must have been late in the evening. Sorry about that blunder. Rgds Pierre - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] MMC host class
Russell King wrote:
>
>I still don't like the needless duplication. How about doing it this
>way (see the attached patch.)
>
>Note: I also intend to move MMC over to using an IDR for the host
>numbers, which is why we need to setup the name at registration
>time, not allocation time.
>
>
>
This patch should cover the edge case of allocating but not registering
a host.
Rgds
Pierre
diff -uNp linux-2.6.13-rc6/drivers/mmc.orig/mmc.c linux-2.6.13-rc6/drivers/mmc/mmc.c
--- linux-2.6.13-rc6/drivers/mmc.orig/mmc.c 2005-08-08 13:29:53.0 +0200
+++ linux-2.6.13-rc6/drivers/mmc/mmc.c 2005-08-08 13:36:08.0 +0200
@@ -874,7 +874,11 @@ EXPORT_SYMBOL(mmc_remove_host);
void mmc_free_host(struct mmc_host *host)
{
flush_scheduled_work();
- mmc_free_host_sysfs(host);
+
+ if (host->class_dev.class != NULL)
+ mmc_free_host_sysfs(host);
+ else
+ kfree(host);
}
EXPORT_SYMBOL(mmc_free_host);
Re: 8139cp misses interrupts during resume
Pierre Ossman wrote: > Pierre Ossman wrote: > >>I'm having problem with the interrupt getting killed after suspend with >>my 8139cp controller. The problem only appears if the cable is connected >>during resume (before suspend is irrelevant) and the interface is down. >> >>Both suspend-to-disk and suspend-to-ram exhibit the error. dmesg from >>suspend-to-ram included. >> >>I find it a bit strange that 8139cp's interrupt handler isn't included >>when it dumps the handlers. Could this be related to the problem? >> > > > Anyone familiar with this driver that can give me some pointers on what > to look for? I'd prefer not to have to learn how the entire thing works > just to fix one bug. :) > I've gotten a bit close now at least. The problem is that the IRQ handler isn't registered until the device is opened (up:ed) but the hardware triggers interrupt even in a closed state. So either the hardware needs to be silenced or the handler needs to be installed earlier. Rgds Pierre - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
