[PATCH] module-init-tools: generate modules.seriomap

[Dmitry Torokhov]

Hi Rusty,

I have converted serio bus to use ID matching and changed serio drivers
to use MODULE_DEVICE_TABLE. Now that Vojtech pulled the changes into his
tree it would be nice if official module-init-tools generated the module
map so that hotplug scripts could automatically load proper drivers.

Please consider applying the patch below.

Thanks!

-- 
Dmitry

diff -urN module-init-tools-3.1-pre5/depmod.c module-init-tools/depmod.c
--- module-init-tools-3.1-pre5/depmod.c 2004-06-30 23:24:40.0 -0500
+++ module-init-tools/depmod.c  2005-01-23 01:16:04.0 -0500
@@ -683,6 +683,7 @@
{ "modules.ieee1394map", output_ieee1394_table },
{ "modules.isapnpmap", output_isapnp_table },
{ "modules.inputmap", output_input_table },
+   { "modules.seriomap", output_serio_table },
{ "modules.alias", output_aliases },
{ "modules.symbols", output_symbols },
 };
diff -urN module-init-tools-3.1-pre5/depmod.h module-init-tools/depmod.h
--- module-init-tools-3.1-pre5/depmod.h 2003-12-23 21:10:57.0 -0500
+++ module-init-tools/depmod.h  2005-01-23 01:17:17.0 -0500
@@ -47,6 +47,8 @@
void *pnp_card_table;
unsigned int input_size;
void *input_table;
+   unsigned int serio_size;
+   void *serio_table;
 
/* File contents and length. */
void *data;
diff -urN module-init-tools-3.1-pre5/moduleops_core.c 
module-init-tools/moduleops_core.c
--- module-init-tools-3.1-pre5/moduleops_core.c 2004-05-23 22:01:48.0 
-0500
+++ module-init-tools/moduleops_core.c  2005-01-23 01:43:21.0 -0500
@@ -196,6 +196,10 @@
module->input_size = PERBIT(INPUT_DEVICE_SIZE);
module->input_table = PERBIT(deref_sym)(module->data,
"__mod_input_device_table");
+
+   module->serio_size = PERBIT(SERIO_DEVICE_SIZE);
+   module->serio_table = PERBIT(deref_sym)(module->data,
+   "__mod_serio_device_table");
 }
 
 struct module_ops PERBIT(mod_ops) = {
diff -urN module-init-tools-3.1-pre5/tables.c module-init-tools/tables.c
--- module-init-tools-3.1-pre5/tables.c 2003-12-24 00:23:38.0 -0500
+++ module-init-tools/tables.c  2005-01-23 01:13:24.0 -0500
@@ -340,3 +340,36 @@
}
}
 }
+
+static void output_serio_entry(struct serio_device_id *serio, char *name, FILE 
*out)
+{
+   fprintf(out,
+   "%-20s 0x%02x 0x%02x  0x%02x 0x%02x\n",
+   name,
+   serio->type,
+   serio->extra,
+   serio->id,
+   serio->proto);
+}
+
+
+void output_serio_table(struct module *modules, FILE *out)
+{
+   struct module *i;
+
+   fprintf(out, "# serio module   type extra id   proto\n");
+
+   for (i = modules; i; i = i->next) {
+   struct serio_device_id *e;
+   char shortname[strlen(i->pathname) + 1];
+
+   if (!i->serio_table)
+   continue;
+
+   make_shortname(shortname, i->pathname);
+   for (e = i->serio_table; e->type || e->proto; e = (void *)e + 
i->serio_size)
+   output_serio_entry(e, shortname, out);
+   }
+}
+
+
diff -urN module-init-tools-3.1-pre5/tables.h module-init-tools/tables.h
--- module-init-tools-3.1-pre5/tables.h 2003-12-24 00:18:54.0 -0500
+++ module-init-tools/tables.h  2005-01-23 01:21:48.0 -0500
@@ -116,6 +116,15 @@
 #define INPUT_DEVICE_SIZE32 (4 + 4 * 2 + 4 + 16 * 4 + 4 + 2 * 4 + 4 + 4 + 4 + 
4 * 4 + 4)
 #define INPUT_DEVICE_SIZE64 (8 + 4 * 2 + 8 + 8 * 8 + 8 + 8 + 8 + 8 + 8 + 2 * 8 
+ 8)
 
+struct serio_device_id {
+   unsigned char type;
+   unsigned char extra;
+   unsigned char id;
+   unsigned char proto;
+};
+#define SERIO_DEVICE_SIZE32 (4 * 1)
+#define SERIO_DEVICE_SIZE64 (4 * 1 + 4)
+
 /* Functions provided by tables.c */
 struct module;
 void output_usb_table(struct module *modules, FILE *out);
@@ -124,5 +133,6 @@
 void output_ccw_table(struct module *modules, FILE *out);
 void output_isapnp_table(struct module *modules, FILE *out);
 void output_input_table(struct module *modules, FILE *out);
+void output_serio_table(struct module *modules, FILE *out);
 
 #endif /* MODINITTOOLS_TABLES_H */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] fix wait_task_inactive race (was Re: Race condition in ptrace)

[Nick Piggin]

Nick Piggin wrote:
Ingo Molnar wrote:
* Nick Piggin <[EMAIL PROTECTED]> wrote:

When a task is put to sleep, it is dequeued from the runqueue
while it is still running. The problem is that the runqueue
lock can be dropped and retaken in schedule() before the task
actually schedules off, and wait_task_inactive did not account
for this.

ugh. This has been the Nth time we got bitten by the fundamental
unrobustness of non-atomic scheduling on some architectures ...
(And i'll say the N+1th time that this is not good.)
This is actually due to wake_sleeping_dependent and
dependent_sleeper dropping the runqueue lock.
Hmph, *and* unlocked context switch architectures as you say.
In fact, I'm surprised those haven't been bitten by this problem
earlier.
So that makes us each half right! :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Add resume support to serio bus.

[Dmitry Torokhov]

Hi,

This patch adds resume support to serio_bus based on serio reconnect
framework so now not only i8042 ports will be re-initialized at resume.
It also removes serio_reconnect calls from i8042 as they no longer
needed.

Tested on S4 (swsusp) with Synaptics touchpad.

-- 
Dmitry


===


[EMAIL PROTECTED], 2005-02-06 02:39:30-05:00, [EMAIL PROTECTED]
  Input: add resume method to serio bus so ports are properly
 set up at resume time. Remove calls to serio_reconnect
 from i8042 as they should now be reconnected in course
 of regular resume process.
  
  Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>


 i8042.c |8 
 serio.c |   17 +
 2 files changed, 21 insertions(+), 4 deletions(-)


===



diff -Nru a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
--- a/drivers/input/serio/i8042.c   2005-02-06 02:40:01 -05:00
+++ b/drivers/input/serio/i8042.c   2005-02-06 02:40:01 -05:00
@@ -899,7 +899,7 @@
  * Here we try to restore the original BIOS settings
  */
 
-static int i8042_suspend(struct device *dev, u32 state, u32 level)
+static int i8042_suspend(struct device *dev, pm_message_t state, u32 level)
 {
if (level == SUSPEND_DISABLE) {
del_timer_sync(_timer);
@@ -932,12 +932,12 @@
}
 
 /*
- * Reconnect anything that was connected to the ports.
+ * Activate all ports.
  */
 
for (i = 0; i < I8042_NUM_PORTS; i++)
-   if (i8042_activate_port(_ports[i]) == 0)
-   serio_reconnect(i8042_ports[i].serio);
+   i8042_activate_port(_ports[i]);
+
 /*
  * Restart timer (for polling "stuck" data)
  */
diff -Nru a/drivers/input/serio/serio.c b/drivers/input/serio/serio.c
--- a/drivers/input/serio/serio.c   2005-02-06 02:40:01 -05:00
+++ b/drivers/input/serio/serio.c   2005-02-06 02:40:01 -05:00
@@ -774,6 +774,22 @@
 
 #endif /* CONFIG_HOTPLUG */
 
+static int serio_resume(struct device *dev)
+{
+   struct serio *serio = to_serio_port(dev);
+
+   if (!serio->drv || !serio->drv->reconnect || 
serio->drv->reconnect(serio)) {
+   serio_disconnect_port(serio);
+   /*
+* Driver re-probing can take a while, so better let kseriod
+* deal with it.
+*/
+   serio_rescan(serio);
+   }
+
+   return 0;
+}
+
 /* called from serio_driver->connect/disconnect methods under serio_sem */
 int serio_open(struct serio *serio, struct serio_driver *drv)
 {
@@ -826,6 +842,7 @@
serio_bus.drv_attrs = serio_driver_attrs;
serio_bus.match = serio_bus_match;
serio_bus.hotplug = serio_hotplug;
+   serio_bus.resume = serio_resume;
bus_register(_bus);
 
return 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PATCH: SysV semaphore race vs SIGSTOP

[Ove Kaaven]

lør, 05,.02.2005 kl. 09.37 +0100, skrev Manfred Spraul:
> Hi Ove,
> 
> >As I mentioned in an earlier mail, there is a race when SIGSTOP-ing a
> >process waiting for a SysV semaphore, where if a process holding a
> >semaphore suspends another process waiting on the semaphore and then
> >releases the semaphore, 
> >
> Your patch looks correct (for 2.4 - 2.6 uses a different approach), but 

Actually I myself don't think the patch I sent is 100% correct. The most
glaring problem is of course that it only handles SIGSTOP and nothing
else, but I wasn't sure how to handle anything else. Also, I've since
found that the "continue" in there made it impossible to attach
debuggers or the like to a process blocked in semop. Finally, it would
occasionally continue to loop after the condition is satisfied, e.g.
when the semop is 0.

So, the if check in my patch is more correct as

+   if (is_stopping(current) && queue.status == 1)
+   /* Could either EINTR out or continue.
+* I suppose EINTR is the robust choice. */
+   queue.status = -EINTR;

but that still doesn't handle all signals. I'm thinking that if the
SIGSTOP problem can be solved simply by returning EINTR (and let the
userspace code deal with that by retrying), then perhaps that can be
done for all signals.

Summarily, my "perfect" patch for 2.4 might simply look like this
(assuming signal_pending does the right thing, which I haven't
verified):

--- ipc/sem.c.original  2005-01-31 18:17:17.0 -0500
+++ ipc/sem.c   2005-02-06 01:52:01.0 -0500
@@ -961,6 +961,9 @@
error = -EIDRM;
goto out_free;
}
+   if (signal_pending(current) && queue.status == 1)
+   queue.status = -EINTR;
+
/*
 * If queue.status == 1 we where woken up and
 * have to retry else we simply return.


As for 2.6, yes, the 2.6 code does seem to be harder to make a simple
patch for. Then again, we're thinking of using futexes instead of
semaphores if a 2.6 kernel is detected, so if futexes don't have this
problem, I guess we can use them to work around this semaphore flaw.

> I'm not certain that it's needed:
> You assume that signals have an immediate effect.

I don't necessarily need it to have an "immediate" effect. Only that
pending signals are taken into consideration when the process returns
from certain blocking system calls dealing with atomic synchronization
primitives such as semaphores. I want to be able to think that
synchronization primitives are there to *protect* me against the effects
of implementation details such as delayed signal delivery, not that they
have their own synchronization issues. After all, the man page for
"semop" states that

* The calling process catches a signal: the value of semzcnt is
decremented and semop() fails, with errno set to EINTR.

and I want to be able to expect this to always actually happen. Because
semop is supposed to be an *atomic* operation, I don't expect it to
*both* catch a signal *and* succeed within the same semop system call
(knowing that the signal *must* have been sent by the time the semaphore
condition was fulfilled). See where I'm coming from?

> Linux ignores that - it delays signal processing under some 
> circumstances. If a syscall can be completed without blocking, then the 
> syscall is handled, regardless of any pending signals. The signal is 
> handled at the syscall return, i.e. after completing the syscall.
> That's not just in SysV semaphore - at least pipes are identical:

Perhaps. But at least read() doesn't claim to be an atomic
synchronization primitive like semop() does. Though I suppose it's
occasionally used that way...

> pipe_read first check if there is data. If there is some, then it 
> returns the data. Signals are only checked if there is no pending data.
> I'm not sure if this is a bug. But if it's one, then far more than just 
> sysv sem must be updated.

I'd probably only concern myself with things that are supposed to be
atomic, really.

Anyway, thanks a lot for answering.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 wait_task_inactive race (was Re: Race condition in ptrace)

[Nick Piggin]

Ingo Molnar wrote:
* Nick Piggin <[EMAIL PROTECTED]> wrote:

When a task is put to sleep, it is dequeued from the runqueue
while it is still running. The problem is that the runqueue
lock can be dropped and retaken in schedule() before the task
actually schedules off, and wait_task_inactive did not account
for this.

ugh. This has been the Nth time we got bitten by the fundamental
unrobustness of non-atomic scheduling on some architectures ...
(And i'll say the N+1th time that this is not good.)
This is actually due to wake_sleeping_dependent and
dependent_sleeper dropping the runqueue lock.
Actually idle_balance can (in rare cases) drop the lock as well,
which I didn't notice earlier, so it is something that we
have been doing forever. The smtnice locking has just exposed
the problem for us, so I wrongfully bashed it earlier *blush*.

+static int task_onqueue(runqueue_t *rq, task_t *p)
+{
+   return (p->array || task_running(rq, p));
+}

the fix looks good, but i'd go for the simplified oneliner patch below. 
I dont like the name 'task_onqueue()', a because a task is 'on the
queue' when it has p->array != NULL. The task is running when it's
task_running().  On architectures with nonatomic scheduling a task may
be running while not on the queue and external observers with the
runqueue lock might notice this - and wait_task_inactive() has to take
care of this case. I'm not sure how introducing a function named
"task_onqueue()" will make the situation any clearer.

ok?
Well just because there is a specific condition that both callsites
require. That is, the task is neither running nor on the runqueue.
While task_onqueue is technically wrong if you're looking down into
the fine details of the priority queue management, I think it is OK
to go up a level of abstraction and say that the task is
"on the runqueue" if it is either running or waiting to run.
It is really the one condition that is made un-intuitive due to the
locking in schedule(), so I thought formalising it would be better.
Suggestions for a better name welcome? ;)
Your one liner would fix the problem too, of course. The important
thing at this stage is that it gets fixed for 2.6.11.
Thanks,
Nick

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

Re: Intel AGP support attaching to wrong PCI IDs

[Kyle Moffett]

On Feb 06, 2005, at 01:49, Jon Smirl wrote:
X on GL is already written and is part of the xserver project. This
will run on the standalone OpenGL stack. Combine this with Cairo/Glitz
and we have a graphics system that can compete with Windows Longhorn.
Why compete with vaporware (mostly)? If you really want to see a 
complete
modern graphics system, check out OS X.  See the below screenshots for
one example.

http://tjhsst.edu/~kmoffett/2k4-1.png
http://tjhsst.edu/~kmoffett/2k4-2.png
The rendered window from 2k4 has been distorted by the windowing system
post-processing using a mesh transform.  It runs just as quickly this
way as it does full screen normally, at least as far as I can tell
while playing. :-D A truely well-performing graphics system should be
able to handle multiple applications processing to generate a single
output stream without effort.  I also ran some informal and simple
end-user-style tests a while back where I rapidly switched between and
moved around the following windows (each distorted in the same way):
1)  A UT2k4 window playing a demo
2)  A couple translucent terminal windows continuously scrolling
text
3)  A DVD player window playing The Matrix
4)  A couple Quicktime player windows with movies running
The best part was: ~60 FPS on everything, despite the distortions,
translucency, rapid movement, DVD playing, etc.  I hope that when the
new linux graphics and Soft-RT stuff is done it will be able to achieve
similar performance. If my coding skills were a little more up to
snuff, I would try to help out, but as it is, I fear I'd just muddy
the waters :-\.
Cheers,
Kyle Moffett
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCM/CS/IT/U d- s++: a18 C>$ UB/L/X/*(+)>$ P+++()>$
L(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e->$ h!*()>++$ r  
!y?(-)
--END GEEK CODE BLOCK--

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

Re: Please open sysfs symbols to proprietary modules

[Lee Revell]

On Wed, 2005-02-02 at 21:50 -0500, Kyle Moffett wrote:
> It's not like somebody will have
> some innate commercial advantage over you because they have your
> driver source code.

For a hardware vendor that's not a very compelling argument.  Especially
compared to what their IP lawyers are telling them.

Got anything to back it up?

Lee

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/RFT] Better handling of bad xfers/interrupt delays in psmouse

[Dmitry Torokhov]

On Sunday 06 February 2005 00:29, Dmitry Torokhov wrote:
> On Saturday 05 February 2005 16:11, Vojtech Pavlik wrote:
> > On Sat, Feb 05, 2005 at 02:48:56PM -0500, Dmitry Torokhov wrote:
> > > Hi,
> > > 
> > > The patch below attempts to better handle situation when psmouse interrupt
> > > is delayed for more than 0.5 sec by requesting a resend. This will allow
> > > properly synchronize with the beginning of the packet as mouse is supposed
> > > to resend entire package.
> > 
> > Have you actually tested the mouse is really sending the whole packet?
> > I'd suspect it could just resend the last byte. :I Maybe using the
> 
> Well, I did test and my touchpad behaved properly. But then I tried 2 external
> mice and they are both sending ACK (and they should not) and then the last 
> byte
> only. So I guess we'll have to scrap using 0xfe idea...
> 
> > GET_PACKET command would be more useful in this case.
> >
> 
> Are you talking about 0xeb? We could also try sending "set stream" mode as a
> sync marker...
> 

Ok, here is the patch using PSMOUSE_CMD_POLL. Seems to work fine with 2
external mice that I have and my touchpad in PS/2 compatibility mode.

Unfortunately POLL command kicks Synaptics out of absolute mode so I
disabled all time-based sync checks for Synaptics altogether. This should
be OK since Synaptics have pretty strict protocol rules and usually
can resync on their own. I wonder what POLL does to ALPS?

Again, 2.6.10 version can be found here:

http://www.geocities.com/dt_or/input/2_6_10/

Comments/testing is appreciated.

-- 
Dmitry


===


[EMAIL PROTECTED], 2005-02-06 01:58:47-05:00, [EMAIL PROTECTED]
  Input: psmouse - better handle bad transfers and interrupt delays
 by using POLL command to synchtonize on beginning of a
 packet so we don't need to guess whether received byte is
 remainder of the last packet or beginning of a new one.
  
  Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>


 psmouse-base.c |   83 +
 psmouse.h  |1 
 2 files changed, 73 insertions(+), 11 deletions(-)


===



diff -Nru a/drivers/input/mouse/psmouse-base.c 
b/drivers/input/mouse/psmouse-base.c
--- a/drivers/input/mouse/psmouse-base.c2005-02-06 02:15:18 -05:00
+++ b/drivers/input/mouse/psmouse-base.c2005-02-06 02:15:18 -05:00
@@ -134,6 +134,49 @@
return PSMOUSE_FULL_PACKET;
 }
 
+static void psmouse_schedule_reconnect(struct psmouse *psmouse)
+{
+   psmouse->state = PSMOUSE_IGNORE;
+   printk(KERN_NOTICE "psmouse.c: issuing reconnect request\n");
+   serio_reconnect(psmouse->ps2dev.serio);
+}
+
+static void psmouse_handle_bad_xfer(struct psmouse *psmouse, unsigned int 
flags)
+{
+   if (psmouse->state == PSMOUSE_ACTIVATED)
+   printk(KERN_WARNING "psmouse.c: bad data from KBC -%s%s\n",
+   flags & SERIO_TIMEOUT ? " timeout" : "",
+   flags & SERIO_PARITY ? " bad parity" : "");
+
+   if (!psmouse->resend) {
+   /*
+* This is first error. Try to request resend but not if we
+* got a timeout and we in initialize phase - there most
+* likely no mouse at all. Also skip Synaptics as they don't
+* like POLL command and pass-through ports since we can't
+* use their serio_write in interrupt context.
+*/
+   if ((psmouse->state > PSMOUSE_INITIALIZING || (~flags & 
SERIO_TIMEOUT)) &&
+   psmouse->type != PSMOUSE_SYNAPTICS && 
!psmouse->ps2dev.serio->parent) {
+   if (serio_write(psmouse->ps2dev.serio, PSMOUSE_CMD_POLL 
& 0xff) == 0) {
+   psmouse->resend = 1;
+   psmouse->pktcnt = 0;
+   }
+   }
+   } else {
+   /*
+* This is second error in a row. If mouse was itialized - 
attempt
+* to rconnect, otherwise just signal failure.
+*/
+   psmouse->resend = 0;
+   if (psmouse->state > PSMOUSE_INITIALIZING)
+   psmouse_schedule_reconnect(psmouse);
+   }
+
+   if (!psmouse->resend)
+   ps2_cmd_aborted(>ps2dev);
+}
+
 /*
  * psmouse_interrupt() handles incoming characters, either gathering them into
  * packets or passing them to the command routine as command output.
@@ -149,11 +192,14 @@
goto out;
 
if (flags & (SERIO_PARITY|SERIO_TIMEOUT)) {
-   if (psmouse->state == PSMOUSE_ACTIVATED)
-   printk(KERN_WARNING "psmouse.c: bad data from KBC 
-%s%s\n",
-   flags & SERIO_TIMEOUT ? " timeout" : "",
-   flags & SERIO_PARITY ? " bad parity" : 

Re: [PATCH] fix wait_task_inactive race (was Re: Race condition in ptrace)

[Ingo Molnar]

* Nick Piggin <[EMAIL PROTECTED]> wrote:

> When a task is put to sleep, it is dequeued from the runqueue
> while it is still running. The problem is that the runqueue
> lock can be dropped and retaken in schedule() before the task
> actually schedules off, and wait_task_inactive did not account
> for this.

ugh. This has been the Nth time we got bitten by the fundamental
unrobustness of non-atomic scheduling on some architectures ...
(And i'll say the N+1th time that this is not good.)

> +static int task_onqueue(runqueue_t *rq, task_t *p)
> +{
> + return (p->array || task_running(rq, p));
> +}

the fix looks good, but i'd go for the simplified oneliner patch below. 
I dont like the name 'task_onqueue()', a because a task is 'on the
queue' when it has p->array != NULL. The task is running when it's
task_running().  On architectures with nonatomic scheduling a task may
be running while not on the queue and external observers with the
runqueue lock might notice this - and wait_task_inactive() has to take
care of this case. I'm not sure how introducing a function named
"task_onqueue()" will make the situation any clearer.

ok?

Ingo

--
When a task is put to sleep, it is dequeued from the runqueue
while it is still running. The problem is that one some arches
that has non-atomic scheduling, the runqueue lock can be
dropped and retaken in schedule() before the task actually
schedules off, and wait_task_inactive did not account for this.

Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>

---

 linux/kernel/sched.c |2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

--- linux/kernel/sched.c.orig
+++ linux/kernel/sched.c
@@ -867,7 +875,7 @@ void wait_task_inactive(task_t * p)
 repeat:
rq = task_rq_lock(p, );
/* Must be off runqueue entirely, not preempted. */
-   if (unlikely(p->array)) {
+   if (unlikely(p->array || task_running(rq, p))) {
/* If it's preempted, we yield.  It could be a while. */
preempted = !task_running(rq, p);
task_rq_unlock(rq, );

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] scsi/libata: correct bug for ULi M5281

[Jeff Garzik]

[EMAIL PROTECTED] wrote:
> Hi,Jeff:
> We didn't add the ULi-specific code to libata-core,just export some
> functions of it,is it ok?
> The problem is ULi-specific,so the reset procedures must be in sata_uli.c.

OK, thanks for explaining.

We still have the problem that code is duplicated from libata-scsi.c,
unless I am missing the latest patch from ULi?

Jeff



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

Re: msdos/vfat defaults are annoying

[Christoph Hellwig]

On Sun, Feb 06, 2005 at 12:33:43AM -0500, John Richard Moser wrote:
> I dunno.  I can never understand the innards of the kernel devs' minds.

filesystem detection isn't handled at the kerne level.

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

Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0)

[Herbert Xu]

On Sun, Feb 06, 2005 at 02:50:07PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
> 
> Which means in addrconf_notiry(), if the dev == _dev,
> call addrconf_ifdown for every device like this:

This should fix the reported issue.  However, I'm not sure if it's
a good idea to stop all IP traffic when lo goes down.  We don't do
that for IPv4.

Besides, we'll still need to fix the rt6i_idev GC issue since the
same bug can occur when eth0 goes down and some appliation is holding
a dst to a local address route.  It can become a dead-lock if the
said application then invokes a syscall that takes the RTNL.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0)

[Herbert Xu]

On Sun, Feb 06, 2005 at 02:31:07PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
> 
> Here, lo is going down.
> rt->rt6i_dev = lo and rt->rt6i_idev = ethX.
> I think we already see dst->dev == dev (==lo)  now.
> So, I doubt that fix the problem.
> 
> The source of problem is entry (*) which still on routing entry,
> not on gc list. And, the owner of entry is not routing table but
> unicast/anycast address structure(s).
> We need to "kill" active address on the other interfaces.
> 
> *: rt->rt6i_dev = lo and rt->rt6i_idev = ethX

Sorry I don't think this is right.  Although lo going down is
required to cause those symptoms, it is not the trigger.

The problem only occurs when eth0 itself is unregistered.
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] scsi/ahci: Add support for ULi M5287

[Jeff Garzik]

[EMAIL PROTECTED] wrote:
> Hi,Jeff:
> I think you are not necessary add the m5287 support to ahci.c now, the code
> I add is to
> correct the two bugs of our controller, now we have designed a new AHCI
> controller name M5288(device id is 0x5288),
> it work perfectly with the linux ahci driver only add the PCI ID to ahci.c.

Thanks, I will add this PCI ID to ahci.c.


> Another question,if the SATA SCSI driver and AHCI driver both support the
> same controller, which driver
> has the priority in linux.

Two answers:

a) For the upstream kernel -- when the drivers are built into the kernel
-- the order in which the drivers are listed in drivers/scsi/Makefile
affects the probe order (priority).  When the drivers are built as
kernel modules, the contents of /etc/modprobe.conf (or /etc/modules.conf
for kernel 2.4.x) determines which driver to load.

b) For distributors (Red Hat, SuSE, Mandrake, etc.), the installer
engineers at each company choose which driver to load.

To simplify matters, it is recommended to avoid situations where
multiple drivers have the same PCI ID listed.  The "more advanced"
driver (AHCI) is preferred of course ;-)

Regards,

Jeff


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

Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0)

[Herbert Xu]

On Sat, Feb 05, 2005 at 08:10:44PM -0800, David S. Miller wrote:
> 
> > Alternatively we can
> > remove the dst->dev == dev check in dst_dev_event and dst_ifdown
> > and move that test down to the individual ifdown functions.
> 
> I think there is a hole in this idea maybe.
> 
> If the idea is to scan dst_garbage_list down in ipv6 specific code,
> you can't do that since 'dst' objects from every pool in the kernel
> get put onto the dst_garbage_list.   It is generic.

The idea is to move the check into dst->ops->ifdown.  By definition
ipv6_dst_ifdown will only see rt6_info entries.  So dst_dev_event
will become

for (dst = dst_garbage_list; dst; dst = dst->next) {
dst_ifdown(dst, event != NETDEV_DOWN);
}

dst_ifdown will become

...

do {
if (dst->dev == dev && unregister) {
...
}

dst->ops->ifdown(dst, dev, unregister);
} while ((dst = dst->child) && dst->flags & DST_NOHASH);

...

Note the extra dev argument to ifdown.  ipv6_dst_ifdown will be

static void ip6_dst_ifdown(struct dst_entry *dst, struct net_device *dev,
   int how)
{
struct rt6_info *rt = (struct rt6_info *)dst;
struct inet6_dev *idev = rt->rt6i_idev;

if (idev != NULL && idev->dev != _dev && idev->dev == dev) {
struct inet6_dev *loopback_idev = in6_dev_get(_dev);
if (loopback_idev != NULL) {
rt->rt6i_idev = loopback_idev;
in6_dev_put(idev);
}
}
}

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0)

[Herbert Xu]

On Sat, Feb 05, 2005 at 09:04:11PM -0800, David S. Miller wrote:
> 
> Oh I see.  That would work, and it seems the simplest, and
> lowest risk fix for this problem.
> 
> Herbert, what do you think?

Yes I agree.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Intel AGP support attaching to wrong PCI IDs

[Jon Smirl]

On Sun, 6 Feb 2005 01:08:40 -0500, Dave Jones <[EMAIL PROTECTED]> wrote:
> Why exactly are you trying to write host bridge drivers anyway ?
> Confused.

We're trying to add sysfs attributes for identifying and controlling
legacy address spaces. Desktop x86 has just a single legacy IO/mem
address space but more advanced systems like the IA64 support multiple
ones.  See Documentation/filesystems/sysfs-pci.txt. All architectures
need to provide a consistent API to make it easier to write the user
space app (like video reset). If IA64 is the example then x86 needs to
add legacy_io/mem attributes to the host bus bridge which just passes
the accesses on without change.

Another part of this is VGA control. When there are multiple VGA
devices the bridges have to be set to route VGA appropriately. This is
a different feature than multiple legacy address spaces on the IA64.

> Another way forward (somewhat hacky in one sense, but a lot cleaner in 
> another)
> would be to change the PCI code so that it'll load and init
> multiple drivers that claim to support the same PCI ID.
> This may cause issues for some other drivers however where
> we have an old and a new driver with ID overlap.

This problem already exits in DRM/fbdev. DRM loads like a normal
driver and binds to the PCI IDs. But if it loads and finds fbdev
already bound to the PCI IDs it goes into stealth mode and runs
without binding to the ID.

I would prefer that we stick with the one driver per ID rule and
instead sort out DRM/fbdev to coordinate more. The legacy_io/mem
support can probably be added some place in common AGP code since the
attributes need to be created on all x86 boxes.

> What are you up to?

Putting together a foundation for X on GL.  That involves reworking
video support in Linux so that X can remove all the horrible code that
plays with bridge chips and PCI config space from a user space app.
Right now the foundation is not there to allow X to remove the code.

Several things are needed:
1) Secondary card reset at boot
2) Mode setting on secondary heads - fbdev does not have this
3) A way to set modes without being root
4) Memory management coordination between fbdev/DRM when multiple scan
buffers are active
5) Mouse cursor support in fbdev
6) Fix video reset when resuming from suspend

Something that isn't required but would be nice it to fix things so
that an OOPs will be visible even if X is running.

Once DRM/fbdev is fixed mesa-solo will run on it with full features
(it already runs on fbdev/DRM with limited features).  This will bring
up a standalone OpenGL stack.

X on GL is already written and is part of the xserver project. This
will run on the standalone OpenGL stack. Combine this with Cairo/Glitz
and we have a graphics system that can compete with Windows Longhorn.

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

Re: 2.4.x oops with X

[Andreas Hartmann]

Andreas Hartmann wrote:
> Andreas Hartmann wrote:
> [...]
>> But now, the question is:
>> Why does X crash running kernel 2.4.x with glibc 2.3.4 and not with kernel
>> 2.6.10? Why does X run fine using kernel 2.4 and 2.6 with glibc 2.3.3?
>> 
>> --
>>  |   glibc
>>  |   2.3.3   2.3.4
>> --|-
>> kernel|
>> 2.4  |   X okX segfaults
>> 2.6  |   X okX ok
> 
> 
> Meanwhile, I could find where X crashes using glibc 2.3.4 with kernel 2.4.
> It's this piece of code in linux_vm86.c:267
> 
> static int
> vm86_rep(struct vm86_struct *ptr)
> {
> int __res;
> 
> #ifdef __PIC__
> /* When compiling with -fPIC, we can't use asm constraint "b" because
>%ebx is already taken by gcc. */
> __asm__ __volatile__("pushl %%ebx\n\t"
>  "movl %2,%%ebx\n\t"
>  "movl %1,%%eax\n\t"
>  "int $0x80\n\t"
>  "popl %%ebx"
>  :"=a" (__res)
>  :"n" ((int)113), "r" ((struct vm86_struct *)ptr));
> #else
> __asm__ __volatile__("int $0x80\n\t"
>  :"=a" (__res):"a" ((int)113),
>  "b" ((struct vm86_struct *)ptr));
> #endif
> 
> if (__res < 0) {
> errno = -__res;
> __res = -1;
> }
> else errno = 0;
> return __res;
> }
> 
> 
> The function ExecX86int10 (vbe.c) calls do_vm86 (linux_vm86.c), which
> calls vm86_rep (linux_vm86.c).
> 
> 
> I don't understand, why this piece of assembler code works fine with glibc
> 2.3.3, but not with glibc 2.3.4, running kernel 2.4.x. It works fine again
> with kernel 2.6.

Solution for this problem can be found meanwhile at
https://bugs.freedesktop.org/show_bug.cgi?id=2431


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

Re: 2.6.11-rc3-mm1 : mount UDF CDRW stuck in D state

[Andrew Morton]

Peter Osterlund <[EMAIL PROTECTED]> wrote:
>
> Peter Osterlund <[EMAIL PROTECTED]> writes:
> 
> > Laurent Riffard <[EMAIL PROTECTED]> writes:
> > 
> > > This is kernel 2.6.11-rc3-mm1. I can't mount an UDF-formatted cdrw
> > > in packet-writing mode. Mount process gets stuck in D state.
> > > 
> > > Mounting and writing this media in packet-writing mode works fine
> > > with kernel 2.6.11-rc2-mm2.
> > 
> > I tried to repeat the problem, but I didn't get far, because I get a
> > kernel panic right after init is started:
> 
> I got around that by disabling preempt, radeon framebuffer, HPET
> timer, APIC. Don't know which one caused the panic, will track it down
> later.

Please do - the above combo works for me (as usual).  I don't recall anyone
else reporting it.

> Anyway, mount hangs for me too if I use an IDE drive, both with native
> ide and ide-scsi emulation. It doesn't hang with a USB drive though. I
> verified that 2.6.11-rc3 does not have this problem. Reverting
> bk-ide-dev does *not* fix the problem.

Bah.  sysrq-T output would be helpful.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Intel AGP support attaching to wrong PCI IDs

[Dave Jones]

On Sun, Feb 06, 2005 at 12:58:46AM -0500, Jon Smirl wrote:
 > On Sat, 5 Feb 2005 23:05:26 -0500, Dave Jones <[EMAIL PROTECTED]> wrote:
 > > Take a peek at 'lspci -vv' output. You'll notice that the AGP
 > > capabilities are attached to the host bridge.
 > 
 > I see that now, why is it on the host bridge instead of the AGP
 > bridge? 

Not sure. Maybe its partly due to the host bridge having all the
smarts to deal with the memory controller.

 > So that means if we add drivers for the host bridges we have
 > to add the code to the AGP drivers. It also implies that we have to
 > load them.

Why exactly are you trying to write host bridge drivers anyway ?
Confused.

If there's a sensible reason for such drivers, we could at some
stage have the bridge drivers check for AGP capabilities, and
if found, start up the initialisation of the relevant AGP chipset
driver. (and then rip out the whole PCI detection stuff in agpgart).
This is quite a lot of work though, so unless there's a really
compelling reason, I don't think its worth doing.

Another way forward (somewhat hacky in one sense, but a lot cleaner in another)
would be to change the PCI code so that it'll load and init
multiple drivers that claim to support the same PCI ID.
This may cause issues for some other drivers however where
we have an old and a new driver with ID overlap.

So,.. what are you up to?

Dave

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

Re: Intel AGP support attaching to wrong PCI IDs

[Jon Smirl]

On Sat, 5 Feb 2005 23:05:26 -0500, Dave Jones <[EMAIL PROTECTED]> wrote:
> Take a peek at 'lspci -vv' output. You'll notice that the AGP
> capabilities are attached to the host bridge.

I see that now, why is it on the host bridge instead of the AGP
bridge? So that means if we add drivers for the host bridges we have
to add the code to the AGP drivers. It also implies that we have to
load them.

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

Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0)

[YOSHIFUJI Hideaki / $B5HF#1QL@(B]

In article <[EMAIL PROTECTED]> (at Sun, 06 Feb 2005 14:31:07 +0900 (JST)), 
(BYOSHIFUJI Hideaki / [EMAIL PROTECTED](B <[EMAIL PROTECTED]> says:
(B
(B> The source of problem is entry (*) which still on routing entry,
(B> not on gc list. And, the owner of entry is not routing table but
(B> unicast/anycast address structure(s).
(B> We need to "kill" active address on the other interfaces.
(B
(BWhich means in addrconf_notiry(), if the dev == _dev,
(Bcall addrconf_ifdown for every device like this:
(B
(BSigned-off-by: Hideaki YOSHIFUJI <[EMAIL PROTECTED]>
(B
(B= net/ipv6/addrconf.c 1.129 vs edited =
(B--- 1.129/net/ipv6/addrconf.c   2005-01-18 06:13:31 +09:00
(B+++ edited/net/ipv6/addrconf.c  2005-02-06 14:48:25 +09:00
(B@@ -1961,6 +1961,20 @@
(Bcase NETDEV_DOWN:
(Bcase NETDEV_UNREGISTER:
(B/*
(B+* If lo is doing down we need to kill
(B+* all addresses on the host because it owns
(B+* route on lo. --yoshfuji
(B+*/
(B+   if (dev == _dev) {
(B+   struct net_device *dev1;
(B+   for (dev1 = dev_base; dev1; dev1 = dev->next) {
(B+   if (dev1 == _dev ||
(B+   __in6_dev_get(dev1) == NULL)
(B+   continue;
(B+   addrconf_ifdown(dev1, event != NETDEV_DOWN);
(B+   }
(B+   }
(B+   /*
(B *  Remove all addresses from this interface.
(B */
(Baddrconf_ifdown(dev, event != NETDEV_DOWN);
(B
(B
(B-- 
(BHideaki YOSHIFUJI @ USAGI Project <[EMAIL PROTECTED]>
(BGPG FP: 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA
(B-
(BTo unsubscribe from this list: send the line "unsubscribe linux-kernel" in
(Bthe body of a message to [EMAIL PROTECTED]
(BMore majordomo info at  http://vger.kernel.org/majordomo-info.html
(BPlease read the FAQ at  http://www.tux.org/lkml/

[RFT #2] libata (SATA) driver fixes

[Jeff Garzik]

See attached changelog and patch, for review and testing.
This includes some fixes for some ugly probe-related bugs, rarely hit 
thankfully.  It also includes new "future nvidia SATA" support and 
Promise SATAII TX2/4 support.

Note that this patch changes the interrupt-acknowledgement code in 
sata_promise.c for all Promise controllers, not just the new SATAII 
ones.  This should be safe and indeed desirable, but warrants special 
mention (and testing).

This is going to Linus/Andrew for 2.6.11 real soon now.
Jeff

BK users:

bk pull bk://gkernel.bkbits.net/libata-2.6

This will update the following files:

 drivers/scsi/libata-core.c  |  187 
 drivers/scsi/libata-scsi.c  |   35 
 drivers/scsi/sata_nv.c  |   45 --
 drivers/scsi/sata_promise.c |   14 ++-
 drivers/scsi/sata_sil.c |1 
 include/linux/ata.h |2 
 include/linux/libata.h  |2 
 7 files changed, 207 insertions(+), 79 deletions(-)

through these ChangeSets:

:
  o [libata sata_promise] add PCI ID for new SATAII TX2 card

:
  o libata: fix ata_piix on ICH6R in RAID mode

:
  o [libata sata_sil] add another Seagate drive to blacklist

Albert Lee:
  o [libata] SCSI-to-ATA translation fixes

Andrew Chew:
  o sata_nv: enable generic class support for future NVIDIA SATA

Brett Russ:
  o [libata scsi] verify cmd bug fixes/support

Jeff Garzik:
  o [libata sata_promise] support Promise SATAII TX2/TX4 cards
  o [libata] Remove CDROM drive from PATA DMA blacklist
  o [libata] add DMA blacklist

Pete Zaitcev:
  o [libata] fix probe object allocation bugs

diff -Nru a/drivers/scsi/libata-core.c b/drivers/scsi/libata-core.c
--- a/drivers/scsi/libata-core.c2005-02-06 00:34:30 -05:00
+++ b/drivers/scsi/libata-core.c2005-02-06 00:34:30 -05:00
@@ -1700,6 +1700,69 @@
DPRINTK("EXIT\n");
 }
 
+static void ata_pr_blacklisted(struct ata_port *ap, struct ata_device *dev)
+{
+   printk(KERN_WARNING "ata%u: dev %u is on DMA blacklist, disabling 
DMA\n",
+   ap->id, dev->devno);
+}
+
+static const char * ata_dma_blacklist [] = {
+   "WDC AC11000H",
+   "WDC AC22100H",
+   "WDC AC32500H",
+   "WDC AC33100H",
+   "WDC AC31600H",
+   "WDC AC32100H",
+   "WDC AC23200L",
+   "Compaq CRD-8241B",
+   "CRD-8400B",
+   "CRD-8480B",
+   "CRD-8482B",
+   "CRD-84",
+   "SanDisk SDP3B",
+   "SanDisk SDP3B-64",
+   "SANYO CD-ROM CRD",
+   "HITACHI CDR-8",
+   "HITACHI CDR-8335",
+   "HITACHI CDR-8435",
+   "Toshiba CD-ROM XM-6202B",
+   "CD-532E-A",
+   "E-IDE CD-ROM CR-840",
+   "CD-ROM Drive/F5A",
+   "WPI CDD-820",
+   "SAMSUNG CD-ROM SC-148C",
+   "SAMSUNG CD-ROM SC",
+   "SanDisk SDP3B-64",
+   "SAMSUNG CD-ROM SN-124",
+   "ATAPI CD-ROM DRIVE 40X MAXIMUM",
+   "_NEC DV5800A",
+};
+
+static int ata_dma_blacklisted(struct ata_port *ap, struct ata_device *dev)
+{
+   unsigned char model_num[40];
+   char *s;
+   unsigned int len;
+   int i;
+
+   ata_dev_id_string(dev->id, model_num, ATA_ID_PROD_OFS,
+ sizeof(model_num));
+   s = _num[0];
+   len = strnlen(s, sizeof(model_num));
+
+   /* ATAPI specifies that empty space is blank-filled; remove blanks */
+   while ((len > 0) && (s[len - 1] == ' ')) {
+   len--;
+   s[len] = 0;
+   }
+
+   for (i = 0; i < ARRAY_SIZE(ata_dma_blacklist); i++)
+   if (!strncmp(ata_dma_blacklist[i], s, len))
+   return 1;
+
+   return 0;
+}
+
 static unsigned int ata_get_mode_mask(struct ata_port *ap, int shift)
 {
struct ata_device *master, *slave;
@@ -1712,17 +1775,37 @@
 
if (shift == ATA_SHIFT_UDMA) {
mask = ap->udma_mask;
-   if (ata_dev_present(master))
+   if (ata_dev_present(master)) {
mask &= (master->id[ATA_ID_UDMA_MODES] & 0xff);
-   if (ata_dev_present(slave))
+   if (ata_dma_blacklisted(ap, master)) {
+   mask = 0;
+   ata_pr_blacklisted(ap, master);
+   }
+   }
+   if (ata_dev_present(slave)) {
mask &= (slave->id[ATA_ID_UDMA_MODES] & 0xff);
+   if (ata_dma_blacklisted(ap, slave)) {
+   mask = 0;
+   ata_pr_blacklisted(ap, slave);
+   }
+   }
}
else if (shift == ATA_SHIFT_MWDMA) {
mask = ap->mwdma_mask;
-   if (ata_dev_present(master))
+   if (ata_dev_present(master)) {
mask &= (master->id[ATA_ID_MWDMA_MODES] & 0x07);
-   if (ata_dev_present(slave))
+   if (ata_dma_blacklisted(ap, master)) {
+  

msdos/vfat defaults are annoying

[John Richard Moser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

So I've noticed, again, much annoyed, that if I rely on -t auto,
horrible horrible things happen.

I have had floppies and compact flash cards that I've done mkfs.vfat to
make fat32 filesystems on (not fat16), and mounting them brings the
thing on as msdos by default (autodetect).  Furthermore, I build msdos
out, and mount says the msdos FS isn't supported.  In either case I need
to use -t vfat.

Vfat is much more common and should be backwards compatible with msdos.
  When there's a ton of foo~1 files around after mounting, something's
wrong.

Shouldn't vfat be the automatic default?  Or at least, if only vfat and
not msdos is available, use vfat.  For that matter, can msdos and vfat
be collapsed?  As I recall, the difference is that vfat makes more
inodes to store long file names, one for each 13 characters (in reverse?)

I dunno.  I can never understand the innards of the kernel devs' minds.

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

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

Re: [RFC/RFT] Better handling of bad xfers/interrupt delays in psmouse

[Dmitry Torokhov]

On Saturday 05 February 2005 16:11, Vojtech Pavlik wrote:
> On Sat, Feb 05, 2005 at 02:48:56PM -0500, Dmitry Torokhov wrote:
> > Hi,
> > 
> > The patch below attempts to better handle situation when psmouse interrupt
> > is delayed for more than 0.5 sec by requesting a resend. This will allow
> > properly synchronize with the beginning of the packet as mouse is supposed
> > to resend entire package.
> 
> Have you actually tested the mouse is really sending the whole packet?
> I'd suspect it could just resend the last byte. :I Maybe using the

Well, I did test and my touchpad behaved properly. But then I tried 2 external
mice and they are both sending ACK (and they should not) and then the last byte
only. So I guess we'll have to scrap using 0xfe idea...

> GET_PACKET command would be more useful in this case.
>

Are you talking about 0xeb? We could also try sending "set stream" mode as a
sync marker...

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

Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0)

[YOSHIFUJI Hideaki / $B5HF#1QL@(B]

In article <[EMAIL PROTECTED]> (at Sat, 5 Feb 2005 21:04:11 -0800), "David S. 
Miller" <[EMAIL PROTECTED]> says:

> On Sun, 06 Feb 2005 13:37:23 +0900 (JST)
> YOSHIFUJI Hideaki / [EMAIL PROTECTED](B <[EMAIL PROTECTED]> wrote:
> 
> > How about making dst->ops->dev_check() like this:
> > 
> > static int inline dst_dev_check(struct dst_entry *dst, struct net_device 
> > *dev)
> > {
> > if (dst->ops->dev_check)
> > return dst->ops->dev_check(dst, dev)
> > else
> > return dst->dev == dev;
> > }
> 
> Oh I see.  That would work, and it seems the simplest, and
> lowest risk fix for this problem.

Well...

Here, lo is going down.
rt->rt6i_dev = lo and rt->rt6i_idev = ethX.
I think we already see dst->dev == dev (==lo)  now.
So, I doubt that fix the problem.

The source of problem is entry (*) which still on routing entry,
not on gc list. And, the owner of entry is not routing table but
unicast/anycast address structure(s).
We need to "kill" active address on the other interfaces.

*: rt->rt6i_dev = lo and rt->rt6i_idev = ethX


BTW, I wish we could shut down eth0 during lo is pending...

--yoshfuji


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

2.6: USB Storage hangs machine on bootup for ~2 minutes

[Parag Warudkar]

I am running FC3 on a AMD64 laptop. The laptop has 3 USB ports. If I
attach any usb-storage device (Sandisk Cruiser usb drive, iPod, Maxtor
external drive etc.) the kernel hangs while booting. The hang occurs
shortly after the usb-storage module is loaded. The machine does not
respond to anything other than the power button. This hang lasts for
about 2 minutes after which boot resumes and goes on fine. 

When it is hung, the usb storage devices are not being accessed - the
iPOD for e.g does not show the Do not Disconnect sign when it is hung -
it shows that after the boot resumes. Might have something to do with
the recent "Waiting for device to settle" change in usb-storage?


A 

The boot goes on without a hang if there are no usb-storage devices
attached to the system. (USB mouse is fine for example, so the hang
happens only in case of usb-storage devices.)

PS - This bug was also reported to Redhat Bugzilla some time ago - I
haven't got any feedback so far.

Parag



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

Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0)

[David S. Miller]

On Sun, 06 Feb 2005 13:37:23 +0900 (JST)
YOSHIFUJI Hideaki / [EMAIL PROTECTED](B <[EMAIL PROTECTED]> wrote:

> How about making dst->ops->dev_check() like this:
> 
> static int inline dst_dev_check(struct dst_entry *dst, struct net_device *dev)
> {
>   if (dst->ops->dev_check)
>   return dst->ops->dev_check(dst, dev)
>   else
>   return dst->dev == dev;
> }

Oh I see.  That would work, and it seems the simplest, and
lowest risk fix for this problem.

Herbert, what do you think?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.4.29] libata: fix ata_piix on ICH6R in RAID mode

[Jeff Garzik]

Martins Krikis wrote:
--- linux-2.4.29/drivers/scsi/libata-core.c	2005-01-25 20:55:41.0 -0500
+++ linux-2.4.29-iswraid/drivers/scsi/libata-core.c	2005-02-01 20:23:51.0 -0500
@@ -3597,7 +3597,8 @@ int ata_pci_init_one (struct pci_dev *pd
 	else
 		port[1] = port[0];
 
-	if ((port[0]->host_flags & ATA_FLAG_NO_LEGACY) == 0) {
+	if ((port[0]->host_flags & ATA_FLAG_NO_LEGACY) == 0
+	&& (pdev->class >> 8) == PCI_CLASS_STORAGE_IDE) {
 		/* TODO: support transitioning to native mode? */
 		pci_read_config_byte(pdev, PCI_CLASS_PROG, );
 		mask = (1 << 2) | (1 << 0);
applied
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0)

[YOSHIFUJI Hideaki / $B5HF#1QL@(B]

In article <[EMAIL PROTECTED]> (at Sat, 5 Feb 2005 20:02:42 -0800), "David S. 
Miller" <[EMAIL PROTECTED]> says:

> > Yes, IPv6 needs "split device" semantics
> > (for per-device statistics such as Ip6InDelivers etc),
> > and I like later solution.
> 
> Ok.  I never read whether ipv6, like ipv4, is specified to support
> a model of host based ownership of addresses.  Does anyone know?

I'm not sure it is explicitly specified, but there're some hints:

1. we need to allow multiple addresses on multiple interfaces.
   e.g. link-local address

2. if a packet has come from A to link-local address on the other side B,
   we should not receive it.
 +---+
>|A B|
 +---+

   Currently, it does not happen in usual because ndisc does NOT handle
   addresses on other device.

3. mib document states that we should take statistics on interface which 
   the address belongs to; not the interface where the packet has come
   from:

cited from RFC2011bis:
Local (*) packets on the input side are counted on the interface
associated with their destination address, which may not be the
interface on which they were received.  This requirement is caused by
the possibility of losing the original interface during processing,
especially re-assembly.

(*): here it means incoming, but not forwarding.


BTW, BSD has similar reference to interface structure in routeing entry.

-- 
Hideaki YOSHIFUJI @ USAGI Project <[EMAIL PROTECTED]>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] scsi/ahci: Add support for ULi M5287

[Jeff Garzik]

[EMAIL PROTECTED] wrote:
Hi,Jeff
We add the support for ULi's AHCI controller M5287 in drivers/scsi/ahci.c,
This patch is applied to kernel 2.6.10-rc3. Please apply to new kernels.
Ideally I would like to eliminate vendor-specific code, where possible.
Does the AHCI driver work at all, with simply the addition of the PCI ID?
Detailed comments below.

--- linux-2.6.10-rc3/drivers/scsi/ahci.c.orig   2004-12-11
03:14:17.170955840 +0800
+++ linux-2.6.10-rc3/drivers/scsi/ahci.c  2004-12-11 03:31:40.979272856
+0800
@@ -241,6 +241,8 @@ static struct pci_device_id ahci_pci_tbl
board_ahci },
  { PCI_VENDOR_ID_INTEL, 0x2653, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
board_ahci },
+ { PCI_VENDOR_ID_AL, 0x5287, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+   board_ahci },
  { }   /* terminate list */
 };
OK

@@ -555,7 +557,6 @@ static void ahci_intr_error(struct ata_p
writel(0x300, port_mmio + PORT_SCR_CTL);
readl(port_mmio + PORT_SCR_CTL); /* flush */
  }
-
  /* re-start DMA */
  tmp = readl(port_mmio + PORT_CMD);
  tmp |= PORT_CMD_START | PORT_CMD_FIS_RX;
@@ -711,12 +712,29 @@ static int ahci_host_init(struct ata_pro
  unsigned int i, j, using_dac;
  int rc;
  void __iomem *port_mmio;
+ u8 rev_id;//peer add for m5287 rev 02h
+ pci_read_config_byte(pdev, PCI_REVISION_ID, _id);
  cap_save = readl(mmio + HOST_CAP);
  cap_save &= ( (1<<28) | (1<<17) );
  cap_save |= (1 << 27);
  /* global controller reset */
+//peer add for m5287 rev 02h
+ if(pdev->vendor==PCI_VENDOR_ID_AL && pdev->device==0x5287 && rev_id
==0x02)
+ {
+   tmp = readl(mmio + HOST_CTL);
+   writel(tmp & ~HOST_RESET, mmio + HOST_CTL);
+   readl(mmio + HOST_CTL); /* flush */
+   writel(tmp | HOST_RESET, mmio + HOST_CTL);
+   readl(mmio + HOST_CTL); /* flush */
+   writel(tmp & ~HOST_RESET, mmio + HOST_CTL);
+   readl(mmio + HOST_CTL); /* flush */
+
+ }
+//peer add end
+ else
+ {
  tmp = readl(mmio + HOST_CTL);
  if ((tmp & HOST_RESET) == 0) {
writel(tmp | HOST_RESET, mmio + HOST_CTL);
@@ -735,6 +753,7 @@ static int ahci_host_init(struct ata_pro
return -EIO;
  }
+ }
  writel(HOST_AHCI_EN, mmio + HOST_CTL);
  (void) readl(mmio + HOST_CTL);  /* flush */
  writel(cap_save, mmio + HOST_CAP);
My conclusion from this change is that you are simply impatient with the 
1-second delay for host reset ;-)

That is a fair criticism.  I confess that the reason for the 1-second 
delay is pure laziness.  However, my suggestion would be:

1) eliminate the ULi-specific code
2) rewrite the host reset code so that it
a) performs the host reset as you (ULi) have written
b) polls host reset register for completion, as described
   in AHCI specification
This will perform a very rapid reset, and eliminate the annoying delay.

@@ -796,6 +815,18 @@ static int ahci_host_init(struct ata_pro
/* make sure port is not active */
tmp = readl(port_mmio + PORT_CMD);
VPRINTK("PORT_CMD 0x%x\n", tmp);
+//peer add for m5287 rev 02h
+   if(pdev->vendor==PCI_VENDOR_ID_AL && pdev->device==0x5287 &&
rev_id==0x02)
+   {
+ //set start bit then issue comreset when initialize
+ writel((tmp|PORT_CMD_START), port_mmio + PORT_CMD);
+ writel(0x01, port_mmio + PORT_SCR_CTL);
+ readl(port_mmio + PORT_SCR_CTL); /* flush */
+ msleep(1);
+ writel(0x0, port_mmio + PORT_SCR_CTL);
+ readl(port_mmio + PORT_SCR_CTL); /* flush */
+   }
+//peer add end
3) should we do this for all AHCI controllers?
4) performing host reset should perform COMRESET, until staggered spinup 
is select.  So the COMRESET portion of your code appears incorrect 
W.R.T. the AHCI specification.

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

Re: [patch] scsi/libata: correct bug for ULi M5281

[Jeff Garzik]

[EMAIL PROTECTED] wrote:
> Hi Jeff,
> 
> I've correct the patch according to your suggestion.
> But we need libata-core.c to export some functions.
> Here is the patch. Please check it and apply it to new kernels.
> Thanks a lot.


I'm afraid I cannot accept even the updated version of your patch.

Your second patch updates libata-core, and adds ULi-specific code to it.

What we need to do is

1) determine if your problem is ULi-specific, or applies to other
controllers

2a) If the problem is not ULi-specific, simply update libata to new
behavior.

2b) If the problem is ULi-specific, libata must be modified such that
all ULi-specific reset procedures are in sata_uli.c, and _no code is
duplicated from libata_.  This may require that we change the libata
API.  In Linux, it is OK to change the driver API when there is a problem :)

Regards,

Jeff


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

Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0)

[YOSHIFUJI Hideaki / $B5HF#1QL@(B]

In article <[EMAIL PROTECTED]> (at Sat, 5 Feb 2005 20:10:44 -0800), "David S. 
Miller" <[EMAIL PROTECTED]> says:

> > Alternatively we can
> > remove the dst->dev == dev check in dst_dev_event and dst_ifdown
> > and move that test down to the individual ifdown functions.
> 
> I think there is a hole in this idea maybe.
> 
> If the idea is to scan dst_garbage_list down in ipv6 specific code,
> you can't do that since 'dst' objects from every pool in the kernel
> get put onto the dst_garbage_list.   It is generic.

How about making dst->ops->dev_check() like this:

static int inline dst_dev_check(struct dst_entry *dst, struct net_device *dev)
{
if (dst->ops->dev_check)
return dst->ops->dev_check(dst, dev)
else
return dst->dev == dev;
}

--yoshfuji
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Drive performance bottleneck

[Nuno Silva]

Andrew Morton wrote:
Lincoln Dale <[EMAIL PROTECTED]> wrote:
sg_dd uses a window into a kernel DMA window.  as such, two of the four 
memory acccesses are cut out (1. DMA from HBA to RAM, 2. userspace 
accessing data).
1.6Gbps / 2 = 800MB/s -- or roughly what Ian was seeing with sg_dd.

Right.  That's a fancy way of saying "cheating" ;)
But from the oprofile output it appears to me that there is plenty of CPU
capacity left over.  Maybe I'm misreading it due to oprofile adding in the
SMP factor (25% CPU on a 4-way means we've exhausted CPU capacity).
sg_dd is lying or /dev/sg* is broken. Try to do that sg_dd test in any 
single drive and you'll get 20 times the performance you're supposed to 
achieve:

puma:/tmp/dd# time sg_dd if=/dev/sg1 of=/dev/null bs=64k count=100 
time=1
Reducing read to 64 blocks per loop
time to transfer data was 69.784784 secs, 939.12 MB/sec
100+0 records in
100+0 records out

This is a single sata drive. I'm lucky, am I not?  ;-)
Regards,
Nuno Silva
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01

[Valdis . Kletnieks]

On Fri, 04 Feb 2005 11:03:47 +0100, Ingo Molnar said:
> 
> i have released the -V0.7.38-01 Real-Time Preemption patch, which can be

Building with:

# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT_DESKTOP=y
# CONFIG_PREEMPT_RT is not set

  CC  kernel/sched.o
kernel/sched.c:314:1: warning: "_finish_arch_switch" redefined
kernel/sched.c:306:1: warning: this is the location of the previous definition

caused by this part of the patch:

@@ -288,12 +295,20 @@ static DEFINE_PER_CPU(struct runqueue, r
 #define task_rq(p) cpu_rq(task_cpu(p))
 #define cpu_curr(cpu)  (cpu_rq(cpu)->curr)
 
+#ifdef CONFIG_PREEMPT_RT
+# ifdef prepare_arch_switch
+#   error FIXME
+# endif
+#else  
+# define _finish_arch_switch finish_arch_switch
+#endif 
+   
 /* 
  * Default context-switch locking:
  */
 #ifndef prepare_arch_switch
 # define prepare_arch_switch(rq, next) do { } while (0)
-# define finish_arch_switch(rq, next)  spin_unlock_irq(&(rq)->lock)
+# define _finish_arch_switch(rq, next) spin_unlock(&(rq)->lock)
 # define task_running(rq, p)   ((rq)->curr == (p))
 #endif
  

What was intended for non-RT builds?


pgpNiQEEkGs83.pgp
Description: PGP signature

Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0)

[David S. Miller]

On Sat, 5 Feb 2005 17:46:43 +1100
Herbert Xu <[EMAIL PROTECTED]> wrote:

> This doesn't work because net/core/dst.c can only search based
> on dst->dev.  For the split device case, dst->dev is set to
> loopback_dev while rt6i_idev is set to the real device.

Indeed.  I didn't catch that.

> If we wanted to preserve the split device semantics, then we
> can create a local GC list in IPv6 so that it can search based
> on rt6i_idev as well as the other keys.

Ok, so this would entail changing each ipv6 dst_free() call
into one to ip6_dst_free(), which would:

ip6_garbage_add(dst);
dst_free(dst);

It would mean that dst_run_gc() would need to have some callback
like dst->ops->gc_destroy() or similar, which would allow ipv6
to delete the dst from it's local garbage list.

> Alternatively we can
> remove the dst->dev == dev check in dst_dev_event and dst_ifdown
> and move that test down to the individual ifdown functions.

I think there is a hole in this idea maybe.

If the idea is to scan dst_garbage_list down in ipv6 specific code,
you can't do that since 'dst' objects from every pool in the kernel
get put onto the dst_garbage_list.   It is generic.

They have no identity, so it's illegal to treat any member of that
list as an rt_entry, rt6_entry or any specific higher level dst
type.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0)

[David S. Miller]

On Sat, 05 Feb 2005 19:50:39 +0900 (JST)
YOSHIFUJI Hideaki / [EMAIL PROTECTED](B <[EMAIL PROTECTED]> wrote:

> In article <[EMAIL PROTECTED]> (at Sat, 5 Feb 2005 17:46:43 +1100), Herbert 
> Xu <[EMAIL PROTECTED]> says:
> 
> > If we wanted to preserve the split device semantics, then we
> > can create a local GC list in IPv6 so that it can search based
> > on rt6i_idev as well as the other keys.  Alternatively we can
> > remove the dst->dev == dev check in dst_dev_event and dst_ifdown
> > and move that test down to the individual ifdown functions.
> 
> Yes, IPv6 needs "split device" semantics
> (for per-device statistics such as Ip6InDelivers etc),
> and I like later solution.

Ok.  I never read whether ipv6, like ipv4, is specified to support
a model of host based ownership of addresses.  Does anyone know?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [OT] Re: Why is debugging under Linux such a pain

[Tomasz Rola]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, 5 Feb 2005, Kyle Moffett wrote:

> You could also try Xnest, which runs a second X-server within a window 
> of
> the primary X-server,

Yes, this is a good idea...

> except without most of the extra overhead of VNC 

...but I'm not sure if this overhead is noticeable in normal case. I have
just tried to watch film on xvncviewer (same computer, i.e. no network
except localhost) and it was watchable in full screen (800x550 emulated in
window) and even more so when I switched mplayer to window mode. Quake2
also was running quite nicely in 640x400.

BTW, I am using TightVNC and my cpu is Athlon underclocked down to 900
MHz (well, I've decided full 1.8 GHz scared me a lot and besides,
who needs it to run so fast? and why they don't make 7.14 MHz computers
anymore?).

Of course, in terms of cpu cycles, mplayer and Xvnc together took about
35% of CPU in top, while mplayer on real X took only about 3-5% due to the
gfx card doing all the work (seemingly). So the overhead is indeed quite
big.

For a "simple app with few menus", the choice probably doesn't matter
anyway.

> Cheers,
> Kyle Moffett

Regards,
Tomasz Rola

- --
** A C programmer asked whether computer had Buddha's nature.  **
** As the answer, master did "rm -rif" on the programmer's home**
** directory. And then the C programmer became enlightened...  **
** **
** Tomasz Rola  mailto:[EMAIL PROTECTED] **

-BEGIN PGP SIGNATURE-
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv

iQA/AwUBQgWX2RETUsyL9vbiEQKLVACgsZeOt11+VUICCITjMBQX9ZTrCQQAoPHa
58IkuL68hTKtZTrQdi70DYV9
=FIkn
-END PGP SIGNATURE-


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

Re: Intel AGP support attaching to wrong PCI IDs

[Dave Jones]

On Sat, Feb 05, 2005 at 08:45:19PM -0500, Jon Smirl wrote:
 > I have an i875 chipset with these two devices:
 > 
 > 8086:2578 - 00:00.0 Host bridge: Intel Corp. 82875P/E7210 Memory
 > Controller Hub (rev 02)
 > 8086:2579 - 00:01.0 PCI bridge: Intel Corp. 82875P Processor to AGP
 > Controller (rev 02)
 > 
 > In the legacy io space thread we are talking about making a device
 > driver for host bridges.  The Intel AGP drivers (in my case
 > agpgart-intel-mch) are attaching to the PCI IDs of the host bus device
 > instead of the AGP bridge. This blocks us from making a host bridge
 > driver.
 > PCI_DEVICE_ID_INTEL_82875_HB 0x2578
 > 
 > Shouldn't they be attaching to device 0x2579? It looks like all of the
 > drivers have this problem and are attaching to the host bus PCI IDs
 > instead of the AGP bridge ID.

Take a peek at 'lspci -vv' output. You'll notice that the AGP
capabilities are attached to the host bridge.

Dave

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

Re: [PATCH] Dynamic tick, version 050127-1

[Tony Lindgren]

* Tony Lindgren <[EMAIL PROTECTED]> [050205 18:39]:
> * Pavel Machek <[EMAIL PROTECTED]> [050205 15:08]:
> > 
> > Ok, works slightly better: time no longer runs 2x too fast. When TSC
> > is used, I get same behaviour  as before ("sleepy machine"). With
> > "notsc", machine seems to work okay, but I still get 1000 timer
> > interrupts a second.

...

> 
> Sounds like your system is not running with the dyn-tick... I'll try
> to fix that TSC bug.

The following patch fixes TSC timer with dyn-tick, and local APIC
timer on UP system with CONFIG_SMP.

Tony
diff -Nru a/arch/i386/Kconfig b/arch/i386/Kconfig
--- a/arch/i386/Kconfig 2005-02-05 19:46:47 -08:00
+++ b/arch/i386/Kconfig 2005-02-05 19:46:47 -08:00
@@ -452,6 +452,16 @@
bool "Provide RTC interrupt"
depends on HPET_TIMER && RTC=y
 
+config NO_IDLE_HZ
+   bool "Dynamic Tick Timer - Skip timer ticks during idle"
+   help
+ This option enables support for skipping timer ticks when the
+ processor is idle. During system load, timer is continuous.
+ This option saves power, as it allows the system to stay in
+ idle mode longer. Currently supported timers are ACPI PM
+ timer, local APIC timer, and TSC timer. HPET timer is currently
+ not supported.
+
 config SMP
bool "Symmetric multi-processing support"
---help---
diff -Nru a/arch/i386/kernel/apic.c b/arch/i386/kernel/apic.c
--- a/arch/i386/kernel/apic.c   2005-02-05 19:46:47 -08:00
+++ b/arch/i386/kernel/apic.c   2005-02-05 19:46:47 -08:00
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -909,6 +910,8 @@
 
 #define APIC_DIVISOR 16
 
+static u32 apic_timer_val;
+
 void __setup_APIC_LVTT(unsigned int clocks)
 {
unsigned int lvtt_value, tmp_value, ver;
@@ -927,7 +930,15 @@
& ~(APIC_TDR_DIV_1 | APIC_TDR_DIV_TMBASE))
| APIC_TDR_DIV_16);
 
-   apic_write_around(APIC_TMICT, clocks/APIC_DIVISOR);
+   apic_timer_val = clocks/APIC_DIVISOR;
+
+#ifdef CONFIG_NO_IDLE_HZ
+   /* Local APIC timer is 24-bit */
+   if (apic_timer_val)
+   dyn_tick->max_skip = 0xff / apic_timer_val;
+#endif
+
+   apic_write_around(APIC_TMICT, apic_timer_val);
 }
 
 static void setup_APIC_timer(unsigned int clocks)
@@ -1040,6 +1051,13 @@
 */
setup_APIC_timer(calibration_result);
 
+#ifdef CONFIG_NO_IDLE_HZ
+   if (calibration_result)
+   dyn_tick->state |= DYN_TICK_USE_APIC;
+   else
+   printk(KERN_INFO "dyn-tick: Cannot use local APIC\n");
+#endif
+
local_irq_enable();
 }
 
@@ -1068,6 +1086,18 @@
}
 }
 
+#if defined(CONFIG_NO_IDLE_HZ)
+void reprogram_apic_timer(unsigned int count)
+{
+   unsigned long flags;
+
+   count *= apic_timer_val;
+   local_irq_save(flags);
+   apic_write_around(APIC_TMICT, count);
+   local_irq_restore(flags);
+}
+#endif
+
 /*
  * the frequency of the profiling timer can be changed
  * by writing a multiplier value into /proc/profile.
@@ -1160,6 +1190,7 @@
 
 fastcall void smp_apic_timer_interrupt(struct pt_regs *regs)
 {
+   unsigned long seq;
int cpu = smp_processor_id();
 
/*
@@ -1178,6 +1209,23 @@
 * interrupt lock, which is the WrongThing (tm) to do.
 */
irq_enter();
+
+#ifdef CONFIG_NO_IDLE_HZ
+   /*
+* Check if we need to wake up PIT interrupt handler.
+* Otherwise just wake up local APIC timer.
+*/
+   do {
+   seq = read_seqbegin(_lock);
+   if (dyn_tick->state & (DYN_TICK_ENABLED | DYN_TICK_SKIPPING)) {
+   if (dyn_tick->skip_cpu == cpu && dyn_tick->skip > 
DYN_TICK_MIN_SKIP)
+   dyn_tick->interrupt(99, NULL, regs);
+   else
+   reprogram_apic_timer(1);
+   }
+   } while (read_seqretry(_lock, seq));
+#endif
+
smp_local_timer_interrupt(regs);
irq_exit();
 }
diff -Nru a/arch/i386/kernel/irq.c b/arch/i386/kernel/irq.c
--- a/arch/i386/kernel/irq.c2005-02-05 19:46:47 -08:00
+++ b/arch/i386/kernel/irq.c2005-02-05 19:46:47 -08:00
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifndef CONFIG_X86_LOCAL_APIC
 /*
@@ -100,6 +101,11 @@
} else
 #endif
__do_IRQ(irq, regs);
+
+#ifdef CONFIG_NO_IDLE_HZ
+   if (dyn_tick->state & (DYN_TICK_ENABLED | DYN_TICK_SKIPPING) && irq != 
0)
+   dyn_tick->interrupt(irq, NULL, regs);
+#endif
 
irq_exit();
 
diff -Nru a/arch/i386/kernel/time.c b/arch/i386/kernel/time.c
--- a/arch/i386/kernel/time.c   2005-02-05 19:46:47 -08:00
+++ b/arch/i386/kernel/time.c   2005-02-05 19:46:47 -08:00
@@ -46,6 +46,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -301,6 +302,60 @@
return IRQ_HANDLED;
 }
 
+#ifdef CONFIG_NO_IDLE_HZ
+static unsigned long long 

Re: Problem with trackpad and 2.6.11-rc[23], but not -rc1

[Dmitry Torokhov]

On Saturday 05 February 2005 21:14, Joseph Pingenot wrote:
> Hello.
> 
> I just tried (again) to get the most recent kernel version working on my
>   laptop.  All is clear except for one small detail: the trackpad and mouse
>   buttons don't work.  When using the eraser mouse, it moves around fine.
>   When using the trackpad, the cursour jumps around as though it were using
>   the wrong protocol.  Additionally, the mousebuttons either have no effect
>   or cause the mouse to suddenly jump left.  The kernel log has tons of error
>   messages (attached).
> This behavior started occurring in 2.6.11-rc2; it works fine in 2.6.11-rc1.
>   The behaviour here was listed with software suspend 2, but when I was
>   testing it with -rc2, no software suspend patches were applied and I still
>   saw the behavior.

What kind of touchpad? What does /proc/bus/input/devices show?

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

Re: [PATCH] PPC/PPC64: Abstract cpu_feature checks.

[Olof Johansson]

Doh, forgot to do a final refpatch after fixing build error. I blame it
on lack of morning coffee. Here's a proper version:



 
Abstract most manual mask checks of cpu_features with cpu_has_feature()
 
 
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>

---

 linux-2.5-olof/arch/ppc/kernel/ppc_htab.c|8 +++---
 linux-2.5-olof/arch/ppc/kernel/setup.c   |4 +--
 linux-2.5-olof/arch/ppc/kernel/temp.c|2 -
 linux-2.5-olof/arch/ppc/mm/mmu_decl.h|2 -
 linux-2.5-olof/arch/ppc/mm/ppc_mmu.c |4 +--
 linux-2.5-olof/arch/ppc/platforms/pmac_cpufreq.c |2 -
 linux-2.5-olof/arch/ppc/platforms/pmac_setup.c   |2 -
 linux-2.5-olof/arch/ppc/platforms/pmac_smp.c |4 +--
 linux-2.5-olof/arch/ppc/platforms/sandpoint.c|6 ++---
 linux-2.5-olof/arch/ppc64/kernel/align.c |2 -
 linux-2.5-olof/arch/ppc64/kernel/iSeries_setup.c |2 -
 linux-2.5-olof/arch/ppc64/kernel/pSeries_lpar.c  |2 -
 linux-2.5-olof/arch/ppc64/kernel/process.c   |4 +--
 linux-2.5-olof/arch/ppc64/kernel/setup.c |6 ++---
 linux-2.5-olof/arch/ppc64/kernel/smp.c   |2 -
 linux-2.5-olof/arch/ppc64/kernel/sysfs.c |   22 +--
 linux-2.5-olof/arch/ppc64/mm/hash_native.c   |   14 ++--
 linux-2.5-olof/arch/ppc64/mm/hash_utils.c|2 -
 linux-2.5-olof/arch/ppc64/mm/hugetlbpage.c   |2 -
 linux-2.5-olof/arch/ppc64/mm/init.c  |   10 
 linux-2.5-olof/arch/ppc64/mm/slb.c   |4 +--
 linux-2.5-olof/arch/ppc64/mm/stab.c  |2 -
 linux-2.5-olof/arch/ppc64/oprofile/op_model_power4.c |2 -
 linux-2.5-olof/arch/ppc64/oprofile/op_model_rs64.c   |2 -
 linux-2.5-olof/arch/ppc64/xmon/xmon.c|8 +++---
 linux-2.5-olof/drivers/macintosh/via-pmu.c   |2 -
 linux-2.5-olof/drivers/md/raid6altivec.uc|2 -
 linux-2.5-olof/include/asm-ppc/cputable.h|5 
 linux-2.5-olof/include/asm-ppc64/cacheflush.h|2 -
 linux-2.5-olof/include/asm-ppc64/cputable.h  |5 
 linux-2.5-olof/include/asm-ppc64/mmu_context.h   |4 +--
 linux-2.5-olof/include/asm-ppc64/page.h  |2 -
 32 files changed, 76 insertions(+), 66 deletions(-)

diff -puN include/asm-ppc64/cputable.h~cpu-has-feature 
include/asm-ppc64/cputable.h
--- linux-2.5/include/asm-ppc64/cputable.h~cpu-has-feature  2005-02-05 
11:11:03.478617416 -0600
+++ linux-2.5-olof/include/asm-ppc64/cputable.h 2005-02-05 21:14:05.873057376 
-0600
@@ -66,6 +66,11 @@ struct cpu_spec {
 extern struct cpu_spec cpu_specs[];
 extern struct cpu_spec *cur_cpu_spec;
 
+static inline unsigned long cpu_has_feature(unsigned long feature)
+{
+   return cur_cpu_spec->cpu_features & feature;
+}
+
 
 /* firmware feature bitmask values */
 #define FIRMWARE_MAX_FEATURES 63
diff -puN arch/ppc64/kernel/align.c~cpu-has-feature arch/ppc64/kernel/align.c
--- linux-2.5/arch/ppc64/kernel/align.c~cpu-has-feature 2005-02-05 
11:11:03.521610880 -0600
+++ linux-2.5-olof/arch/ppc64/kernel/align.c2005-02-05 11:11:04.117520288 
-0600
@@ -238,7 +238,7 @@ fix_alignment(struct pt_regs *regs)
 
dsisr = regs->dsisr;
 
-   if (cur_cpu_spec->cpu_features & CPU_FTR_NODSISRALIGN) {
+   if (cpu_has_feature(CPU_FTR_NODSISRALIGN)) {
unsigned int real_instr;
if (__get_user(real_instr, (unsigned int __user *)regs->nip))
return 0;
diff -puN arch/ppc64/kernel/iSeries_setup.c~cpu-has-feature 
arch/ppc64/kernel/iSeries_setup.c
--- linux-2.5/arch/ppc64/kernel/iSeries_setup.c~cpu-has-feature 2005-02-05 
11:11:03.525610272 -0600
+++ linux-2.5-olof/arch/ppc64/kernel/iSeries_setup.c2005-02-05 
11:11:04.118520136 -0600
@@ -267,7 +267,7 @@ unsigned long iSeries_process_mainstore_
unsigned long i;
unsigned long mem_blocks = 0;
 
-   if (cur_cpu_spec->cpu_features & CPU_FTR_SLB)
+   if (cpu_has_feature(CPU_FTR_SLB))
mem_blocks = iSeries_process_Regatta_mainstore_vpd(mb_array,
max_entries);
else
diff -puN arch/ppc64/kernel/idle.c~cpu-has-feature arch/ppc64/kernel/idle.c
diff -puN arch/ppc64/kernel/process.c~cpu-has-feature 
arch/ppc64/kernel/process.c
--- linux-2.5/arch/ppc64/kernel/process.c~cpu-has-feature   2005-02-05 
11:11:03.600598872 -0600
+++ linux-2.5-olof/arch/ppc64/kernel/process.c  2005-02-05 11:11:04.119519984 
-0600
@@ -388,12 +388,12 @@ copy_thread(int nr, unsigned long clone_
kregs = (struct pt_regs *) sp;
sp -= STACK_FRAME_OVERHEAD;
p->thread.ksp = sp;
-   if (cur_cpu_spec->cpu_features & CPU_FTR_SLB) {
+   if (cpu_has_feature(CPU_FTR_SLB)) {
unsigned long sp_vsid = get_kernel_vsid(sp);
 
sp_vsid <<= SLB_VSID_SHIFT;
sp_vsid 

Re: [PATCH 2.6.11-rc2] ide: merge do_rw_taskfile() and flagged_taskfile() into do_taskfile()

[Tejun Heo]

Hello,
Bartlomiej Zolnierkiewicz wrote:
On Sun, 6 Feb 2005 11:13:31 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote:
Hello, Bartlomiej.

Hi,

This is a new version of ide_do_taskfile.patch.  Compared to the
original do_rw_task(), only one more 'if' is used in the hot path, so
I think the performance issue can be ignored now.  Also, there's no
userland visible change with this patch.  Everything should work just
as it did with do_rw_taskfile()/flagged_taskfile().
do_taskfile() is different from do_rw_taskfile() in that

Is there any gain in changing name to do_taskfile()?
 
 Well, I was just thinking
 do_rw_taskfile + (do_)flagged_taskfile -> do_taskfile.
 If you like do_rw_taskfile better, I guess that's okay too. :-)

- It uses task->data_phase to determine whether it's a DMA command
  or not.

this is user-space visible change
(it is right thing to do, I just wanted to point the fact)
 Oops, I forgot that.  Still, it was kind of weird before.  If any of 
tf_{in|out}_flags is set, flagged_taskfile() is called and ->data_phase 
was used, but, if none of the flags was set, do_rw_taskfile() was called 
and the command is used to determine the same thing.  But, yeah, it's 
user-visible.


do_taskfile() is different from flagged_taskfile() in that
- No (TASKFILE_MULTI_IN && !mult_count) check.  ide_taskfile_ioctl()
  checks the same thing, so it doesn't change anything.

The check may be needed.  AFAIR drive->mult_count may change
before our taskfile request is started.
 Okay, I'll resurrect that test.

- No task->tf_out_flags handling.  ide_end_drive_cmd() ignores it
  anyway, so, again, it doesn't change anything.

I guess you mean ->tf_in_flags?
 Yes.

So, what do you think?

This patch looks much better but could you move writing taskfile
registers to separate helpers (one for non-flagged and one for flagged)?
Probably splitting non-flagged taskfile load helper off do_rw_taskfile()
should be done in separate patch.  We can then use this helper in
ide-disk.c for __ide_do_rw_taskfile() (we can't do direct conversion
to do_rw_taskfile() yet for various reasons).
 Sure, I'll do it now.
 Thanks.
--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] fix wait_task_inactive race (was Re: Race condition in ptrace)

[Nick Piggin]

Nick Piggin wrote:
Something like the following (untested) extension of Bodo's work
could be the minimal fix for 2.6.11. As I've said though, I'd
consider it a hack and prefer to do something about the locking.
That could be done after 2.6.11 though. Depends how you feel.
I think this is the right fix.
When a task is put to sleep, it is dequeued from the runqueue
while it is still running. The problem is that the runqueue
lock can be dropped and retaken in schedule() before the task
actually schedules off, and wait_task_inactive did not account
for this.
I introduced a new function to resolve this state, fixed
wait_task_inactive, and converted over an open coded test.
I did a quick audit of sched.c, and nothing else seems to have
made the same mistake.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
Question: why does wait_task_inactive have different semantics
for UP && PREEMPT than SMP && PREEMPT? I can see that the kthread
caler probably isn't used in the UP case, but technically it is
relying on behaviour that it doesn't get with UP and PREEMPT.
Looks like the ptrace.c caller won't care.
But still, can we either fix it or put a nice comment there?
Preferably fix, if this isn't a very performance critical path?



---

 linux-2.6-npiggin/kernel/sched.c |   12 ++--
 1 files changed, 10 insertions(+), 2 deletions(-)

diff -puN kernel/sched.c~sched-fixup-races kernel/sched.c
--- linux-2.6/kernel/sched.c~sched-fixup-races  2005-02-06 14:03:53.0 
+1100
+++ linux-2.6-npiggin/kernel/sched.c2005-02-06 14:06:43.0 +1100
@@ -298,6 +298,14 @@ static DEFINE_PER_CPU(struct runqueue, r
 #endif
 
 /*
+ * Is the task currently running or on the runqueue
+ */
+static int task_onqueue(runqueue_t *rq, task_t *p)
+{
+   return (p->array || task_running(rq, p));
+}
+
+/*
  * task_rq_lock - lock the runqueue a given task resides on and disable
  * interrupts.  Note the ordering: we can safely lookup the task_rq without
  * explicitly disabling preemption.
@@ -836,7 +844,7 @@ static int migrate_task(task_t *p, int d
 * If the task is not on a runqueue (and not running), then
 * it is sufficient to simply update the task's cpu field.
 */
-   if (!p->array && !task_running(rq, p)) {
+   if (!task_onqueue(rq, p)) {
set_task_cpu(p, dest_cpu);
return 0;
}
@@ -867,7 +875,7 @@ void wait_task_inactive(task_t * p)
 repeat:
rq = task_rq_lock(p, );
/* Must be off runqueue entirely, not preempted. */
-   if (unlikely(p->array)) {
+   if (unlikely(task_onqueue(rq, p))) {
/* If it's preempted, we yield.  It could be a while. */
preempted = !task_running(rq, p);
task_rq_unlock(rq, );

_

Re: [PATCH 2.6.11-rc2] ide: merge do_rw_taskfile() and flagged_taskfile() into do_taskfile()

[Bartlomiej Zolnierkiewicz]

On Sun, 6 Feb 2005 11:13:31 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote:
>  Hello, Bartlomiej.

Hi,

>  This is a new version of ide_do_taskfile.patch.  Compared to the
> original do_rw_task(), only one more 'if' is used in the hot path, so
> I think the performance issue can be ignored now.  Also, there's no
> userland visible change with this patch.  Everything should work just
> as it did with do_rw_taskfile()/flagged_taskfile().
> 
>  do_taskfile() is different from do_rw_taskfile() in that

Is there any gain in changing name to do_taskfile()?
 
>  - It uses task->data_phase to determine whether it's a DMA command
>or not.

this is user-space visible change
(it is right thing to do, I just wanted to point the fact)

>  do_taskfile() is different from flagged_taskfile() in that
> 
>  - No (TASKFILE_MULTI_IN && !mult_count) check.  ide_taskfile_ioctl()
>checks the same thing, so it doesn't change anything.

The check may be needed.  AFAIR drive->mult_count may change
before our taskfile request is started.

>  - No task->tf_out_flags handling.  ide_end_drive_cmd() ignores it
>anyway, so, again, it doesn't change anything.

I guess you mean ->tf_in_flags?

>  So, what do you think?

This patch looks much better but could you move writing taskfile
registers to separate helpers (one for non-flagged and one for flagged)?

Probably splitting non-flagged taskfile load helper off do_rw_taskfile()
should be done in separate patch.  We can then use this helper in
ide-disk.c for __ide_do_rw_taskfile() (we can't do direct conversion
to do_rw_taskfile() yet for various reasons).

Thanks,
Bartlomiej
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [ANNOUNCE] "iswraid" (ICHxR ataraid sub-driver) for 2.4.29

[Jeff Garzik]

Martins Krikis wrote:
Version 0.1.5 of the Intel Sofware RAID driver (iswraid) is now
available for the 2.4 series kernels at
http://prdownloads.sourceforge.net/iswraid/2.4.29-iswraid.patch.gz?download
ACK from me
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)

[William Park]

On Sat, Feb 05, 2005 at 08:45:58PM -0200, Rog?rio Brito wrote:
> Dear developers,
> 
> For some kernel versions (say, since 2.6.10 proper, all the 2.6.11-rc's,
> some -mm trees and also -ac) I have been getting the message "irq 10:
> nobody cared!".
> 
> The message says that I should pass the irqpoll option to the kernel and
> even if I do, I still get the stack trace and the "irq 10: nobody cared!"
> message. :-(
> 
> The message seems to be related to the Promise PDC20265 driver and it
> appeared right after I moved my HDs from my motherboard's VIA controllers
> to the Promise controllers. I have an Asus A7V board, with 2 VIA 686a
> controllers and 2 Promise PDC20265 controllers.
> 
> I already tried enabling and disabling ACPI, but it seems that the problem
> just doesn't go away. :-(
> 
> I am including the dmesg log of my system with this message. I am CC'ing
> the linux-ide list, but I'm only subscribed to linux-kernel. I would
> appreciate CC's, if possible.
> 
> 
> Thank you very much for any help, Rog?rio.
> 
> P.S.: I am, right now, re-compiling 2.6.11-rc3-mm1 with the extra pass of
> kallsyms to see if the problem persists with this release.

Try 'acpi=noirq'.  It did it for me (Abit VP6 dual-p3, Via VT82C694X,
Via VT82C686B).

-- 
William Park <[EMAIL PROTECTED]>, Toronto, Canada
Slackware Linux -- because I can type.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Dynamic tick, version 050127-1

[Tony Lindgren]

* Pavel Machek <[EMAIL PROTECTED]> [050205 15:08]:
> Hi!
> 
> > > > > It could also be that the reprogamming of PIT timer does not work on
> > > > > your machine. I chopped off the udelays there... Can you try
> > > > > something like this:
> > > > 
> > > > I added the udelays, but behaviour did not change.
> > > 
> > > Yeah, and if the first patch was working better, that means the PIT
> > > interrupts work. I'll do another version of the patch where PIT
> > > interrupts work again without local APIC needed, let's see what
> > > happens with that.
> > 
> > I think something broke TSC timer after the first patch, but I could
> > not figure out yet what. So the bad combo might be local APIC + TSC.
> > At least I'm seeing similar problems with local APIC + TSC timer.
> > 
> > Attached is a slightly improved patch, but the patch does not fix
> > the TSC problem. It just fixes compile without local APIC, and
> > booting SMP kernel on uniprocessor machine.
> > 
> > Currently the suggested combo is local APIC + ACPI PM timer...
> 
> Ok, works slightly better: time no longer runs 2x too fast. When TSC
> is used, I get same behaviour  as before ("sleepy machine"). With
> "notsc", machine seems to work okay, but I still get 1000 timer
> interrupts a second.

Sounds like dyn-tick did not get enabled then, maybe you don't have
CONFIG_X86_PM_TIMER, or don't have ACPI PM timer on your board?

After modifying I8042_POLL_PERIOD and leaving out CONFIG_NETFILTER
I'm getting roughly 6HZ timer rate when idle :)

$ dmesg | grep -i "time\|tick\|apic"
ACPI: PM-Timer IO Port: 0x1008
Kernel command line: root=/dev/nfs ip=dhcp ro console=ttyS0,115200
lapic init=/bin/minit
Local APIC disabled by BIOS -- reenabling.
Found and enabled local APIC!
mapped APIC to d000 (fee0)
Using pmtmr for high-res timesource
dyn-tick: Registering dynamic tick timer
per-CPU timeslice cutoff: 365.35 usecs.
task migration cache decay timeout: 1 msecs.
Machine check exception polling timer started.
Real Time Clock Driver v1.12
dyn-tick: Maximum ticks to skip limited to 2678
dyn-tick: Timer using dynamic tick

$ cat /proc/interrupts | grep timer && sleep 10 && cat /proc/interrupts | grep 
timer
  0:  10689  XT-PIC  timer
  0:  10745  XT-PIC  timer

> > And if that works, changing the I8042_POLL_PERIOD from HZ/20 in
> > drivers/input/serio/i8042.h to something like HZ increases the
> > sleep interval quite a bit. I think I had lots of polling also in
> > CONFIG_NETFILTER, but I haven't verified that.
> 
> Okay, I set POLL_PERIOD to 5*HZ, and disabled USB. Perhaps it will
> sleep better now?

Sounds like your system is not running with the dyn-tick... I'll try
to fix that TSC bug.

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

Re: [PATCH 2.6.11-rc2 10/14] ide_pci: Removes SPLIT_BYTE macro from pdc202xx_old

[Bartlomiej Zolnierkiewicz]

On Fri,  4 Feb 2005 16:13:19 +0900 (KST), Tejun Heo <[EMAIL PROTECTED]> wrote:
> 
> 10_ide_pci_pdc202xx_old_cleanup.patch
> 
> Removes SPLIT_BYTE macro from ide/pci/pdc202xx_old driver.
> 
> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>

applied
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: SATA in 2.4 at PE750

[Jeff Garzik]

Pete Zaitcev wrote:
Jeff, you're allocating a block of two probe entries with a signle kmalloc
then freeing halfs of it with two kfrees.
fix applied to 2.4 and 2.6
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Problem with trackpad and 2.6.11-rc[23], but not -rc1

[Joseph Pingenot]

Hello.

I just tried (again) to get the most recent kernel version working on my
  laptop.  All is clear except for one small detail: the trackpad and mouse
  buttons don't work.  When using the eraser mouse, it moves around fine.
  When using the trackpad, the cursour jumps around as though it were using
  the wrong protocol.  Additionally, the mousebuttons either have no effect
  or cause the mouse to suddenly jump left.  The kernel log has tons of error
  messages (attached).
This behavior started occurring in 2.6.11-rc2; it works fine in 2.6.11-rc1.
  The behaviour here was listed with software suspend 2, but when I was
  testing it with -rc2, no software suspend patches were applied and I still
  saw the behavior.
Pertinent log data and config attached.
Thanks!

-Joseph
-- 
[EMAIL PROTECTED]
  Graduate Student in Physics, Freelance Free Software Developer


outfile.gz
Description: application/gunzip


config.gz
Description: application/gunzip

[PATCH 2.6.11-rc2] ide: merge do_rw_taskfile() and flagged_taskfile() into do_taskfile()

[Tejun Heo]

 Hello, Bartlomiej.

 This is a new version of ide_do_taskfile.patch.  Compared to the
original do_rw_task(), only one more 'if' is used in the hot path, so
I think the performance issue can be ignored now.  Also, there's no
userland visible change with this patch.  Everything should work just
as it did with do_rw_taskfile()/flagged_taskfile().

 do_taskfile() is different from do_rw_taskfile() in that

 - It uses task->data_phase to determine whether it's a DMA command
   or not.

 do_taskfile() is different from flagged_taskfile() in that

 - No (TASKFILE_MULTI_IN && !mult_count) check.  ide_taskfile_ioctl()
   checks the same thing, so it doesn't change anything.
 - No task->tf_out_flags handling.  ide_end_drive_cmd() ignores it
   anyway, so, again, it doesn't change anything.

 So, what do you think?


 Signed-off-by: Tejun Heo ([EMAIL PROTECTED])


Index: linux-ide-series3-export/drivers/ide/ide-disk.c
===
--- linux-ide-series3-export.orig/drivers/ide/ide-disk.c2005-02-06 
10:58:27.478337364 +0900
+++ linux-ide-series3-export/drivers/ide/ide-disk.c 2005-02-06 
11:01:11.673688441 +0900
@@ -535,7 +535,7 @@ static ide_startstop_t idedisk_special (
args.tfRegister[IDE_COMMAND_OFFSET] = WIN_SPECIFY;
args.command_type = IDE_DRIVE_TASK_NO_DATA;
args.handler  = _geometry_intr;
-   do_rw_taskfile(drive, );
+   do_taskfile(drive, );
}
} else if (s->b.recalibrate) {
s->b.recalibrate = 0;
@@ -546,7 +546,7 @@ static ide_startstop_t idedisk_special (
args.tfRegister[IDE_COMMAND_OFFSET] = WIN_RESTORE;
args.command_type = IDE_DRIVE_TASK_NO_DATA;
args.handler  = _intr;
-   do_rw_taskfile(drive, );
+   do_taskfile(drive, );
}
} else if (s->b.set_multmode) {
s->b.set_multmode = 0;
@@ -559,7 +559,7 @@ static ide_startstop_t idedisk_special (
args.tfRegister[IDE_COMMAND_OFFSET] = WIN_SETMULT;
args.command_type = IDE_DRIVE_TASK_NO_DATA;
args.handler  = _multmode_intr;
-   do_rw_taskfile(drive, );
+   do_taskfile(drive, );
}
} else if (s->all) {
int special = s->all;
@@ -898,19 +898,19 @@ static ide_startstop_t idedisk_start_pow
args->tfRegister[IDE_COMMAND_OFFSET] = WIN_FLUSH_CACHE;
args->command_type = IDE_DRIVE_TASK_NO_DATA;
args->handler  = _no_data_intr;
-   return do_rw_taskfile(drive, args);
+   return do_taskfile(drive, args);
 
case idedisk_pm_standby:/* Suspend step 2 (standby) */
args->tfRegister[IDE_COMMAND_OFFSET] = WIN_STANDBYNOW1;
args->command_type = IDE_DRIVE_TASK_NO_DATA;
args->handler  = _no_data_intr;
-   return do_rw_taskfile(drive, args);
+   return do_taskfile(drive, args);
 
case idedisk_pm_idle:   /* Resume step 1 (idle) */
args->tfRegister[IDE_COMMAND_OFFSET] = WIN_IDLEIMMEDIATE;
args->command_type = IDE_DRIVE_TASK_NO_DATA;
args->handler = task_no_data_intr;
-   return do_rw_taskfile(drive, args);
+   return do_taskfile(drive, args);
 
case idedisk_pm_restore_dma:/* Resume step 2 (restore DMA) */
/*
Index: linux-ide-series3-export/drivers/ide/ide-io.c
===
--- linux-ide-series3-export.orig/drivers/ide/ide-io.c  2005-02-06 
10:58:27.478337364 +0900
+++ linux-ide-series3-export/drivers/ide/ide-io.c   2005-02-06 
11:01:11.675688117 +0900
@@ -682,9 +682,7 @@ static ide_startstop_t execute_drive_tas
break;
}
 
-   if (args->tf_out_flags.all != 0) 
-   return flagged_taskfile(drive, args);
-   return do_rw_taskfile(drive, args);
+   return do_taskfile(drive, args);
 }
 
 /**
Index: linux-ide-series3-export/drivers/ide/ide-taskfile.c
===
--- linux-ide-series3-export.orig/drivers/ide/ide-taskfile.c2005-02-06 
10:58:27.479337202 +0900
+++ linux-ide-series3-export/drivers/ide/ide-taskfile.c 2005-02-06 
11:01:11.676687955 +0900
@@ -96,35 +96,86 @@ int taskfile_lib_get_identify (ide_drive
return ide_raw_taskfile(drive, , buf);
 }
 
-ide_startstop_t do_rw_taskfile (ide_drive_t *drive, ide_task_t *task)
+ide_startstop_t do_taskfile(ide_drive_t *drive, ide_task_t *task)
 {
ide_hwif_t *hwif= HWIF(drive);
task_struct_t *taskfile = (task_struct_t *) task->tfRegister;

Re: [PATCH 2.6.11-rc2 09/14] ide_pci: Merges pdc202xx_new.h into pdc202xx_new.c

[Bartlomiej Zolnierkiewicz]

On Fri,  4 Feb 2005 16:13:18 +0900 (KST), Tejun Heo <[EMAIL PROTECTED]> wrote:
> 
> 09_ide_pci_pdc202xx_new_merge.patch
> 
> Merges ide/pci/pdc202xx_new.h into pdc202xx_new.c.
> 
> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>

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

Re: [linux-usb-devel] 2.6.11-rc[23]: swsusp & usb regression

[Alan Stern]

On Sat, 5 Feb 2005, Pavel Machek wrote:

> Hi!
> 
> In 2.6.11-rc[23], I get problems after swsusp resume:
> 
> Feb  4 23:54:39 amd kernel: Restarting tasks...<3>hub 3-0:1.0:
> over-current change on port 1
> Feb  4 23:54:39 amd kernel:  done
> Feb  4 23:54:39 amd kernel: hub 3-0:1.0: connect-debounce failed, port
> 1 disabled
> Feb  4 23:54:39 amd kernel: hub 3-0:1.0: over-current change on port 2
> Feb  4 23:54:39 amd kernel: usb 3-2: USB disconnect, address 2
> 
> After unplugging usb bluetooth key, machine hung. Sysrq still
> responded with help but I could not get any usefull output.

> I tried deselecting CONFIG_USB_EHCI_HCD, and got repeating stream of
>
> Feb  5 00:21:17 amd kernel: Restarting tasks... done
> Feb  5 00:21:17 amd kernel: hub 3-0:1.0: over-current change on port 1
> Feb  5 00:21:18 amd kernel: hub 3-0:1.0: connect-debounce failed, port 1 
> disabled
> Feb  5 00:21:18 amd kernel: hub 3-0:1.0: over-current change on port 2
> Feb  5 00:21:20 amd kernel: hub 3-0:1.0: connect-debounce failed, port 2 
> disabled

Considering all the known problems in uhci-hcd's suspend support, I'm not 
sure it's worth pursuing this.  On the other hand, all those "over-current 
change" messages you kept getting might indicate a more serious kind of 
failure.

Does setting CONFIG_USB_SUSPEND help at all?

Alan Stern

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

Re: [PATCH 2.6.11-rc2 08/14] ide_pci: Merges opti621.h into opti621.c

[Bartlomiej Zolnierkiewicz]

On Fri,  4 Feb 2005 16:13:18 +0900 (KST), Tejun Heo <[EMAIL PROTECTED]> wrote:
> 
> 08_ide_pci_opti621_merge.patch
> 
> Merges ide/pci/opti621.h into opti621.c.
> 
> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>

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

Re: [PATCH 2.6.11-rc2 07/14] ide_pci: Merges it8172.h into it8172.c

[Bartlomiej Zolnierkiewicz]

On Fri,  4 Feb 2005 16:13:18 +0900 (KST), Tejun Heo <[EMAIL PROTECTED]> wrote:
> 
> 07_ide_pci_it8172_merge.patch
> 
> Merges ide/pci/it8172.h into it8172.c.
> 
> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>

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

Re: 2.6.11-rc3-mm1 - broken bttv ?

[jjluza]

Eyal Lebedinsky wrote
>
> I am having bttv problems with vanilla -rc3. Does it work for you?

I don't know, as I said I didn't test kernel between 2.6.10 and 
2.6.11-rc3-mm1.
Sorry.
If I have time enough later, I can test 2.6.11-rc3.
Since I don't really know if it's the good place to talk about that, I decided 
to report this bug on bugzilla too. Maybe you can post your problem here :
http://bugzilla.kernel.org/show_bug.cgi?id=4171

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

Re: [PATCH 2.6.11-rc2 06/14] ide_pci: Merges hpt366.h into hpt366.c

[Bartlomiej Zolnierkiewicz]

On Fri,  4 Feb 2005 16:13:18 +0900 (KST), Tejun Heo <[EMAIL PROTECTED]> wrote:
> 
> 06_ide_pci_hpt366_merge.patch
> 
> Merges ide/pci/hpt366.h into hpt366.c.
> 
> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>

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

Re: 2.6.11-rc3-mm1 : mount UDF CDRW stuck in D state

[Peter Osterlund]

Peter Osterlund <[EMAIL PROTECTED]> writes:

> Laurent Riffard <[EMAIL PROTECTED]> writes:
> 
> > This is kernel 2.6.11-rc3-mm1. I can't mount an UDF-formatted cdrw
> > in packet-writing mode. Mount process gets stuck in D state.
> > 
> > Mounting and writing this media in packet-writing mode works fine
> > with kernel 2.6.11-rc2-mm2.
> 
> I tried to repeat the problem, but I didn't get far, because I get a
> kernel panic right after init is started:

I got around that by disabling preempt, radeon framebuffer, HPET
timer, APIC. Don't know which one caused the panic, will track it down
later.

Anyway, mount hangs for me too if I use an IDE drive, both with native
ide and ide-scsi emulation. It doesn't hang with a USB drive though. I
verified that 2.6.11-rc3 does not have this problem. Reverting
bk-ide-dev does *not* fix the problem.

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

Intel AGP support attaching to wrong PCI IDs

[Jon Smirl]

I have an i875 chipset with these two devices:

8086:2578 - 00:00.0 Host bridge: Intel Corp. 82875P/E7210 Memory
Controller Hub (rev 02)
8086:2579 - 00:01.0 PCI bridge: Intel Corp. 82875P Processor to AGP
Controller (rev 02)

In the legacy io space thread we are talking about making a device
driver for host bridges.  The Intel AGP drivers (in my case
agpgart-intel-mch) are attaching to the PCI IDs of the host bus device
instead of the AGP bridge. This blocks us from making a host bridge
driver.
PCI_DEVICE_ID_INTEL_82875_HB 0x2578

Shouldn't they be attaching to device 0x2579? It looks like all of the
drivers have this problem and are attaching to the host bus PCI IDs
instead of the AGP bridge ID.

[EMAIL PROTECTED] pci]# cat devices
808625780   ec08   
   
  0400    
agpgart-intel-mch
0008808625790      
   
      


Am I correct in thinking that in all cases there has to be two PCI
IDs, one for the host bridge and one for the APG bridge?

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

Re: [PATCH] arp_queue: serializing unlink + kfree_skb

[David S. Miller]

On Fri, 4 Feb 2005 12:55:39 +1100
Herbert Xu <[EMAIL PROTECTED]> wrote:

> OK, here is the patch to do that.  Let's get rid of kfree_skb_fast
> while we're at it since it's no longer used.
> 
> Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>

I've queued this up for 2.6.x and 2.4.x, thanks everyone.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.11-rc2 05/14] ide_pci: Merges generic.h into generic.c

[Bartlomiej Zolnierkiewicz]

On Fri,  4 Feb 2005 16:13:18 +0900 (KST), Tejun Heo <[EMAIL PROTECTED]> wrote:
> 
> 05_ide_pci_generic_merge.patch
> 
> Merges ide/pci/generic.h into generic.c.
> 
> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>

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

[2.6 patch] add compiler-gcc4.h

[Adrian Bunk]

On Sat, Feb 05, 2005 at 11:52:00AM -0800, H. Peter Anvin wrote:
> Adrian Bunk wrote:
> >
> >It doesn't seem to be logical for everyone whether compiler-gcc+.h or 
> >compiler-gcc3.h is used for gcc 4.0 ...
> >
> >Perhaps compiler-gcc+.h (which wasn't always updated when 
> >compiler-gcc3.h was updated) should be removed?
> >
> 
> That would make more sense.  After all, gcc5+ can use the gcc4 file 
> until a gcc5 file proper is created.

The compiler-gcc*.h files check only for __GNUC_MINOR__ but not for 
__GNUC__ .

Is the patch below OK?

>   -hpa

cu
Adrian


<--  snip  -->

With the release of gcc 4.0 being only a few months away and people 
already tring compiling with it, it's time for adding a compiler-gcc4.h .

This patch contains the following changes:
- remove compiler-gcc+.h
- compiler-gcc4.h: new file based on a corrected compiler-gcc+.h
- compiler.h: include compiler-gcc4.h for gcc 4
- compiler.h: #error for gcc > 4
- compiler-gcc3.h: remove __compiler_offsetof (there will never be a
   gcc 3.5)
   small indention corrections

I've tested the compilation with both gcc 3.4.4 and a recent gcc 4.0 
snapshot from Debian experimental.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 include/linux/compiler-gcc+.h |3 +++
 include/linux/compiler-gcc3.h |   10 --
 include/linux/compiler-gcc4.h |   16 
 include/linux/compiler.h  |6 --
 4 files changed, 27 insertions(+), 8 deletions(-)

--- linux-2.6.11-rc2-mm2-full/include/linux/compiler.h.old  2005-01-30 
09:59:28.0 +0100
+++ linux-2.6.11-rc2-mm2-full/include/linux/compiler.h  2005-01-30 
10:00:15.0 +0100
@@ -34,8 +34,10 @@
 
 #ifdef __KERNEL__
 
-#if __GNUC__ > 3
-# include   /* catch-all for GCC 4, 5, etc. */
+#if __GNUC__ > 4
+#error no compiler-gcc.h file for this gcc version
+#elif __GNUC__ == 4
+# include 
 #elif __GNUC__ == 3
 # include 
 #elif __GNUC__ == 2
--- linux-2.6.11-rc2-mm2-full/include/linux/compiler-gcc3.h.old 2005-01-30 
10:05:16.0 +0100
+++ linux-2.6.11-rc2-mm2-full/include/linux/compiler-gcc3.h 2005-01-30 
10:08:38.0 +0100
@@ -10,7 +10,7 @@
 #endif
 
 #if __GNUC_MINOR__ > 0
-# define __deprecated  __attribute__((deprecated))
+# define __deprecated  __attribute__((deprecated))
 #endif
 
 #if __GNUC_MINOR__ >= 3
@@ -23,12 +23,10 @@
 #define __attribute_const____attribute__((__const__))
 
 #if __GNUC_MINOR__ >= 1
-#define  noinline __attribute__((noinline))
+#define  noinline  __attribute__((noinline))
 #endif
+
 #if __GNUC_MINOR__ >= 4
-#define __must_check __attribute__((warn_unused_result))
+#define __must_check   __attribute__((warn_unused_result))
 #endif
 
-#if __GNUC_MINOR__ >= 5
-#define __compiler_offsetof(a,b) __builtin_offsetof(a,b)
-#endif
--- /dev/null   2004-11-25 03:16:25.0 +0100
+++ linux-2.6.11-rc2-mm2-full/include/linux/compiler-gcc4.h 2005-01-30 
10:09:08.0 +0100
@@ -0,0 +1,16 @@
+/* Never include this file directly.  Include  instead.  */
+
+/* These definitions are for GCC v4.x.  */
+#include 
+
+#define inline inline  __attribute__((always_inline))
+#define __inline__ __inline__  __attribute__((always_inline))
+#define __inline   __inline__attribute__((always_inline))
+#define __deprecated   __attribute__((deprecated))
+#define __attribute_used__ __attribute__((__used__))
+#define __attribute_pure__ __attribute__((pure))
+#define __attribute_const____attribute__((__const__))
+#define  noinline  __attribute__((noinline))
+#define __must_check   __attribute__((warn_unused_result))
+#define __compiler_offsetof(a,b) __builtin_offsetof(a,b)
+
--- linux-2.6.11-rc3-mm1-full/include/linux/compiler-gcc+.h 2004-12-24 
22:35:39.0 +0100
+++ /dev/null   2004-11-25 03:16:25.0 +0100
@@ -1,16 +0,0 @@
-/* Never include this file directly.  Include  instead.  */
-
-/*
- * These definitions are for Ueber-GCC: always newer than the latest
- * version and hence sporting everything plus a kitchen-sink.
- */
-#include 
-
-#define inline inline  __attribute__((always_inline))
-#define __inline__ __inline__  __attribute__((always_inline))
-#define __inline   __inline__attribute__((always_inline))
-#define __deprecated   __attribute__((deprecated))
-#define __attribute_used__ __attribute__((__used__))
-#define __attribute_pure__ __attribute__((pure))
-#define __attribute_const____attribute__((__const__))
-#define __must_check   __attribute__((warn_unused_result))

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

[OT] Re: Why is debugging under Linux such a pain

[Kyle Moffett]

On Feb 05, 2005, at 19:23, Tomasz Rola wrote:
On Sat, 5 Feb 2005, Marko Macek wrote:
[...]
It would be nice if display lock programs used a separate X display
(some kind of "virtual" display support might be nice to have, mainly
for performance).
I would try VNC for this, at least for debugging. But I don't really 
know
if it would have worked. My distro (Debian) has VNC packed nicely
(vncserver and xvncviewer packages), others should have it too. So the
trial should be rather quick if you use such Linux flavor.
You could also try Xnest, which runs a second X-server within a window 
of
the primary X-server, except without most of the extra overhead of VNC 
or
other image-based solutions. Xnest can even handle different bit-depths
than the primary display, and only slightly modifies most X calls, 
except
for the ones that affect global state, which it processes internally.

Cheers,
Kyle Moffett
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCM/CS/IT/U d- s++: a18 C>$ UB/L/X/*(+)>$ P+++()>$
L(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e->$ h!*()>++$ r  
!y?(-)
--END GEEK CODE BLOCK--

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

[RFC][PATCH-2.6] Clean up and merge compiler-*.h

[Kyle Moffett]

I set up a sample patch to clean up and merge the compiler.h files, on 
the
basis that it's generally easier to manage all implementations of a 
single
compiler feature in the same file right next to each other, instead of
spread across 3 files.  This also cleans it up and puts the __KERNEL__
stuff in a single small section at the bottom, so as not to pollute the
user-space namespace.  This is also a precursor to several other patches
I'm working on to clean up and split out user-space available ABI from
the kernel headers in include/linux to include/linux-abi.

A sample new GCC feature test:
/*
 * __attribute__((__someattr__))			[GCC 3.3 or later]
 *   This will force the specified function to be inlined, or throw an
 *   error if inlining is impossible.  This is designed to be used
 *   where inlining is critical.  In the kernel, we want basically
 *   everything marked "inline" to be forced to inline, because 
otherwise
 *   the code is just plain wrong.
 */
#if (__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 3)
# define __attribute_someattr__ __attribute__((__someattr__))
#else
# define __attribute_someattr__ /* unimplemented */
#endif

Signed-off-by: Kyle Moffett <[EMAIL PROTECTED]>
Index: linux-2.5/include/linux/compiler-gcc+.h
diff -u linux-2.5/include/linux/compiler-gcc+.h:1.5 
linux-2.5/include/linux/compiler-gcc+.h:removed
--- linux-2.5/include/linux/compiler-gcc+.h:1.5	Mon Aug 23 15:45:33 2004
+++ linux-2.5/include/linux/compiler-gcc+.h	Sat Feb  5 19:07:42 2005
@@ -1,16 +0,0 @@
-/* Never include this file directly.  Include  
instead.  */
-
-/*
- * These definitions are for Ueber-GCC: always newer than the latest
- * version and hence sporting everything plus a kitchen-sink.
- */
-#include 
-
-#define inline			inline		__attribute__((always_inline))
-#define __inline__		__inline__	__attribute__((always_inline))
-#define __inline		__inline	__attribute__((always_inline))
-#define __deprecated		__attribute__((deprecated))
-#define __attribute_used__	__attribute__((__used__))
-#define __attribute_pure__	__attribute__((pure))
-#define __attribute_const__	__attribute__((__const__))
-#define __must_check 		__attribute__((warn_unused_result))
Index: linux-2.5/include/linux/compiler-gcc.h
diff -u linux-2.5/include/linux/compiler-gcc.h:1.2 
linux-2.5/include/linux/compiler-gcc.h:removed
--- linux-2.5/include/linux/compiler-gcc.h:1.2	Sun Sep 21 18:36:53 2003
+++ linux-2.5/include/linux/compiler-gcc.h	Sat Feb  5 19:08:02 2005
@@ -1,17 +0,0 @@
-/* Never include this file directly.  Include  
instead.  */
-
-/*
- * Common definitions for all gcc versions go here.
- */
-
-
-/* Optimization barrier */
-/* The "volatile" is due to gcc bugs */
-#define barrier() __asm__ __volatile__("": : :"memory")
-
-/* This macro obfuscates arithmetic on a variable address so that gcc
-   shouldn't recognize the original var, and make assumptions about it 
*/
-#define RELOC_HIDE(ptr, off)	\
-  ({ unsigned long __ptr;	\
-__asm__ ("" : "=g"(__ptr) : "0"(ptr));		\
-(typeof(ptr)) (__ptr + (off)); })
Index: linux-2.5/include/linux/compiler-gcc2.h
diff -u linux-2.5/include/linux/compiler-gcc2.h:1.3 
linux-2.5/include/linux/compiler-gcc2.h:removed
--- linux-2.5/include/linux/compiler-gcc2.h:1.3	Mon Jan 19 13:43:54 2004
+++ linux-2.5/include/linux/compiler-gcc2.h	Sat Feb  5 19:08:12 2005
@@ -1,24 +0,0 @@
-/* Never include this file directly.  Include  
instead.  */
-
-/* These definitions are for GCC v2.x.  */
-
-/* Somewhere in the middle of the GCC 2.96 development cycle, we 
implemented
-   a mechanism by which the user can annotate likely branch directions 
and
-   expect the blocks to be reordered appropriately.  Define 
__builtin_expect
-   to nothing for earlier compilers.  */
-#include 
-
-#if __GNUC_MINOR__ < 96
-# define __builtin_expect(x, expected_value) (x)
-#endif
-
-#define __attribute_used__	__attribute__((__unused__))
-
-/*
- * The attribute `pure' is not implemented in GCC versions earlier
- * than 2.96.
- */
-#if __GNUC_MINOR__ >= 96
-# define __attribute_pure__	__attribute__((pure))
-# define __attribute_const__	__attribute__((__const__))
-#endif
Index: linux-2.5/include/linux/compiler-gcc3.h
diff -u linux-2.5/include/linux/compiler-gcc3.h:1.10 
linux-2.5/include/linux/compiler-gcc3.h:removed
--- linux-2.5/include/linux/compiler-gcc3.h:1.10	Wed Sep  8 11:00:28 
2004
+++ linux-2.5/include/linux/compiler-gcc3.h	Sat Feb  5 19:08:25 2005
@@ -1,34 +0,0 @@
-/* Never include this file directly.  Include  
instead.  */
-
-/* These definitions are for GCC v3.x.  */
-#include 
-
-#if __GNUC_MINOR__ >= 1
-# define inline		inline		__attribute__((always_inline))
-# define __inline__	__inline__	__attribute__((always_inline))
-# define __inline	__inline	__attribute__((always_inline))
-#endif
-
-#if __GNUC_MINOR__ > 0
-# define __deprecated	__attribute__((deprecated))
-#endif
-
-#if __GNUC_MINOR__ >= 3
-# define __attribute_used__	__attribute__((__used__))
-#else
-# define __attribute_used__	

Re: 2.6.11-rc3-mm1 : mount UDF CDRW stuck in D state

[Peter Osterlund]

Laurent Riffard <[EMAIL PROTECTED]> writes:

> This is kernel 2.6.11-rc3-mm1. I can't mount an UDF-formatted cdrw
> in packet-writing mode. Mount process gets stuck in D state.
> 
> Mounting and writing this media in packet-writing mode works fine
> with kernel 2.6.11-rc2-mm2.

I tried to repeat the problem, but I didn't get far, because I get a
kernel panic right after init is started:

Unable to handle kernel NULL pointer dereference at virtual address 
...
PREEMPT
...
EIP is a strncpy_from_user+0x33/0x47
...
Call Trace:
 getname+0x69/0xa5
 sys_open+0x12/0xc6
 sysenter_past_esp+0x52/0x75
...
Kernel panic - not syncing: Attempted to kill init!

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

[2.6 patch] drivers/isdn/divert/isdn_divert.c: make 5 functions static

[Adrian Bunk]

This patch makes five needlessly global functions static.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 drivers/isdn/divert/isdn_divert.c |   10 +-
 1 files changed, 5 insertions(+), 5 deletions(-)

--- linux-2.6.11-rc3-mm1-full/drivers/isdn/divert/isdn_divert.c.old 
2005-02-05 15:39:15.0 +0100
+++ linux-2.6.11-rc3-mm1-full/drivers/isdn/divert/isdn_divert.c 2005-02-05 
15:39:52.0 +0100
@@ -383,7 +383,7 @@
 /*/
 /* called from common module on an incoming call */
 /*/
-int isdn_divert_icall(isdn_ctrl *ic)
+static int isdn_divert_icall(isdn_ctrl *ic)
 { int retval = 0;
   unsigned long flags;
   struct call_struc *cs = NULL; 
@@ -552,7 +552,7 @@
 //
 /* put a address including address type into buffer */
 //
-int put_address(char *st, u_char *p, int len)
+static int put_address(char *st, u_char *p, int len)
 { u_char retval = 0;
   u_char adr_typ = 0; /* network standard */
 
@@ -595,7 +595,7 @@
 /*/
 /* report a succesfull interrogation */
 /*/
-int interrogate_success(isdn_ctrl *ic, struct call_struc *cs)
+static int interrogate_success(isdn_ctrl *ic, struct call_struc *cs)
 { char *src = ic->parm.dss1_io.data;
   int restlen = ic->parm.dss1_io.datalen;
   int cnt = 1;
@@ -689,7 +689,7 @@
 /*/
 /* callback for protocol specific extensions */
 /*/
-int prot_stat_callback(isdn_ctrl *ic)
+static int prot_stat_callback(isdn_ctrl *ic)
 { struct call_struc *cs, *cs1;
   int i;
   unsigned long flags;
@@ -781,7 +781,7 @@
 /***/
 /* status callback from HL */
 /***/
-int isdn_divert_stat_callback(isdn_ctrl *ic)
+static int isdn_divert_stat_callback(isdn_ctrl *ic)
 { struct call_struc *cs, *cs1;
   unsigned long flags;
   int retval;

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

Re: [PATCH 2.6.11-rc2 04/14] ide_pci: Merges cy82c693.h into cy82c693.c

[Bartlomiej Zolnierkiewicz]

On Fri,  4 Feb 2005 16:13:18 +0900 (KST), Tejun Heo <[EMAIL PROTECTED]> wrote:
> 
> 04_ide_pci_cy82c693_merge.patch
> 
> Merges ide/pci/cy82c693.h into cy82c693.c.
> 
> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>

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

[2.6 patch] drivers/isdn/hardware/eicon/: misc possible cleanups

[Adrian Bunk]

This patch contains the following possible cleanups:
- make some needlessly global code static
- dadapter.h: remoe the unused #define OLD_MAX_DESCRIPTORS
- remove the following unused functions:
  - di.c: pr_test_int
  - di.c: pr_clear_int
  - di.c: scom_out
  - di.c: scom_ready
  - di.c: scom_dpc
  - di.c: quadro_clear_int
  - io.c: outp_words_from_buffer
  - io.c: inp_words_to_buffer
- message.c: #if 0 some unused functions

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 drivers/isdn/hardware/eicon/capifunc.c  |2 
 drivers/isdn/hardware/eicon/dadapter.c  |6 
 drivers/isdn/hardware/eicon/dadapter.h  |7 
 drivers/isdn/hardware/eicon/di.c|  201 
 drivers/isdn/hardware/eicon/di.h|5 
 drivers/isdn/hardware/eicon/diva_didd.c |2 
 drivers/isdn/hardware/eicon/divamnt.c   |4 
 drivers/isdn/hardware/eicon/io.c|   32 ---
 drivers/isdn/hardware/eicon/io.h|5 
 drivers/isdn/hardware/eicon/message.c   |   64 ---
 drivers/isdn/hardware/eicon/os_4bri.c   |4 
 11 files changed, 55 insertions(+), 277 deletions(-)

--- linux-2.6.11-rc3-mm1-full/drivers/isdn/hardware/eicon/capifunc.c.old
2005-02-05 15:45:40.0 +0100
+++ linux-2.6.11-rc3-mm1-full/drivers/isdn/hardware/eicon/capifunc.c
2005-02-05 15:45:56.0 +0100
@@ -64,7 +64,7 @@
  */
 static void no_printf(unsigned char *, ...);
 #include "debuglib.c"
-void xlog(char *x, ...)
+static void xlog(char *x, ...)
 {
 #ifndef DIVA_NO_DEBUGLIB
va_list ap;
--- linux-2.6.11-rc3-mm1-full/drivers/isdn/hardware/eicon/dadapter.h.old
2005-02-05 15:46:38.0 +0100
+++ linux-2.6.11-rc3-mm1-full/drivers/isdn/hardware/eicon/dadapter.h
2005-02-05 15:47:56.0 +0100
@@ -25,11 +25,10 @@
  */
 #ifndef __DIVA_DIDD_DADAPTER_INC__
 #define __DIVA_DIDD_DADAPTER_INC__
+
 void diva_didd_load_time_init (void);
 void diva_didd_load_time_finit (void);
-int diva_didd_add_descriptor (DESCRIPTOR* d);
-int diva_didd_remove_descriptor (IDI_CALL request);
-int diva_didd_read_adapter_array (DESCRIPTOR* buffer, int length);
-#define OLD_MAX_DESCRIPTORS 16
+
 #define NEW_MAX_DESCRIPTORS 64
+
 #endif
--- linux-2.6.11-rc3-mm1-full/drivers/isdn/hardware/eicon/dadapter.c.old
2005-02-05 15:48:17.0 +0100
+++ linux-2.6.11-rc3-mm1-full/drivers/isdn/hardware/eicon/dadapter.c
2005-02-05 15:48:46.0 +0100
@@ -106,7 +106,7 @@
   return adapter handle (> 0) on success
   return -1 adapter array overflow
   -- */
-int diva_didd_add_descriptor (DESCRIPTOR* d) {
+static int diva_didd_add_descriptor (DESCRIPTOR* d) {
  diva_os_spin_lock_magic_t  irql;
  int i;
  if (d->type == IDI_DIMAINT) {
@@ -143,7 +143,7 @@
   return adapter handle (> 0) on success
   return 0 on success
   -- */
-int diva_didd_remove_descriptor (IDI_CALL request) {
+static int diva_didd_remove_descriptor (IDI_CALL request) {
  diva_os_spin_lock_magic_t  irql;
  int i;
  if (request == MAdapter.request) {
@@ -171,7 +171,7 @@
   Read adapter array
   return 1 if not enough space to save all available adapters
-- 
*/
-int diva_didd_read_adapter_array (DESCRIPTOR* buffer, int length) {
+static int diva_didd_read_adapter_array (DESCRIPTOR* buffer, int length) {
  diva_os_spin_lock_magic_t  irql;
  int src, dst;
  memset (buffer, 0x00, length);
--- linux-2.6.11-rc3-mm1-full/drivers/isdn/hardware/eicon/di.h.old  
2005-02-05 15:55:28.0 +0100
+++ linux-2.6.11-rc3-mm1-full/drivers/isdn/hardware/eicon/di.h  2005-02-05 
15:57:24.0 +0100
@@ -81,13 +81,8 @@
 /*--*/
 void pr_out(ADAPTER * a);
 byte pr_dpc(ADAPTER * a);
-byte pr_test_int(ADAPTER * a);
-void pr_clear_int(ADAPTER * a);
-void scom_out(ADAPTER * a);
-byte scom_dpc(ADAPTER * a);
 byte scom_test_int(ADAPTER * a);
 void scom_clear_int(ADAPTER * a);
-void quadro_clear_int(ADAPTER * a);
 /*--*/
 /* OS specific functions used by IDI common code*/
 /*--*/
--- linux-2.6.11-rc3-mm1-full/drivers/isdn/hardware/eicon/di.c.old  
2005-02-05 15:55:47.0 +0100
+++ linux-2.6.11-rc3-mm1-full/drivers/isdn/hardware/eicon/di.c  2005-02-05 
17:42:51.0 +0100
@@ -42,10 +42,7 @@
 /*--*/
 void pr_out(ADAPTER * a);
 byte pr_dpc(ADAPTER * a);
-void scom_out(ADAPTER * a);
-byte scom_dpc(ADAPTER * a);
 static byte pr_ready(ADAPTER * a);
-static byte scom_ready(ADAPTER * a);
 static byte isdn_rc(ADAPTER *, byte, byte, byte, word, dword, dword);
 static byte isdn_ind(ADAPTER *, byte, byte, byte, PBUFFER *, byte, 

Re: [linux-usb-devel] 2.6.11-rc[23]: swsusp & usb regression

[Pavel Machek]

Hi!

> > > Your logs don't indicate which host controller driver is bound to each of 
> > > your hubs.  /proc/bus/usb/devices will contain that information.  Without 
> > > it, it's hard to diagnose what happened.
> > 
> > I do not think I have any hubs... no external hubs anyway. And I do
> > not have /proc/bus/usb/devices file :-(. There's something in
> > /sys/bus/usb/devices/.
> 
> So what does "lspci -v|grep HCI" say then?

:00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 
Controller (rev 80) (prog-if 00 [UHCI])
:00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 
Controller (rev 80) (prog-if 00 [UHCI])
:00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 
Controller (rev 80) (prog-if 00 [UHCI])
:00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82) (prog-if 
20 [EHCI])
:00:13.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host 
Controller (rev 80) (prog-if 10 [OHCI])

> You could try "mount -t usbfs on /proc/bus/usb" ... ;)

T:  Bus=04 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor= ProdID= Rev= 2.06
S:  Manufacturer=Linux 2.6.11-rc3 uhci_hcd
S:  Product=VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (#3)
S:  SerialNumber=:00:10.2
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

T:  Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc= 23/900 us ( 3%), #Int=  1, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor= ProdID= Rev= 2.06
S:  Manufacturer=Linux 2.6.11-rc3 uhci_hcd
S:  Product=VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (#2)
S:  SerialNumber=:00:10.1
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

T:  Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=e0(unk. ) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0db0 ProdID=1967 Rev= 5.25
C:* #Ifs= 3 Cfg#= 1 Atr=80 MxPwr=250mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=(none)
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=(none)
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=(none)
E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=(none)
E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=(none)
E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=(none)
E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
I:  If#= 2 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=00 Driver=(none)

T:  Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor= ProdID= Rev= 2.06
S:  Manufacturer=Linux 2.6.11-rc3 uhci_hcd
S:  Product=VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller
S:  SerialNumber=:00:10.0
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=480 MxCh= 6
B:  Alloc=  0/800 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=01 MxPS= 8 #Cfgs=  1
P:  Vendor= ProdID= Rev= 2.06
S:  Manufacturer=Linux 2.6.11-rc3 ehci_hcd
S:  Product=VIA Technologies, Inc. USB 2.0
S:  SerialNumber=:00:10.3
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=256ms

Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[2.6 patch] drivers/isdn/capi/: make some code static

[Adrian Bunk]

This patch makes some needlessly global code static.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 drivers/isdn/capi/capi.c   |   10 +-
 drivers/isdn/capi/kcapi_proc.c |   10 +-
 2 files changed, 10 insertions(+), 10 deletions(-)

--- linux-2.6.11-rc3-mm1-full/drivers/isdn/capi/capi.c.old  2005-02-05 
15:34:35.0 +0100
+++ linux-2.6.11-rc3-mm1-full/drivers/isdn/capi/capi.c  2005-02-05 
15:35:37.0 +0100
@@ -60,12 +60,12 @@
 
 static struct class_simple *capi_class;
 
-int capi_major = 68;   /* allocated */
+static int capi_major = 68;/* allocated */
 #ifdef CONFIG_ISDN_CAPI_MIDDLEWARE
 #define CAPINC_NR_PORTS32
 #define CAPINC_MAX_PORTS   256
-int capi_ttymajor = 191;
-int capi_ttyminors = CAPINC_NR_PORTS;
+static int capi_ttymajor = 191;
+static int capi_ttyminors = CAPINC_NR_PORTS;
 #endif /* CONFIG_ISDN_CAPI_MIDDLEWARE */
 
 module_param_named(major, capi_major, uint, 0);
@@ -268,7 +268,7 @@
kfree(mp);
 }
 
-struct capiminor *capiminor_find(unsigned int minor)
+static struct capiminor *capiminor_find(unsigned int minor)
 {
struct list_head *l;
struct capiminor *p = NULL;
@@ -1166,7 +1166,7 @@
return room;
 }
 
-int capinc_tty_chars_in_buffer(struct tty_struct *tty)
+static int capinc_tty_chars_in_buffer(struct tty_struct *tty)
 {
struct capiminor *mp = (struct capiminor *)tty->driver_data;
if (!mp || !mp->nccip) {
--- linux-2.6.11-rc3-mm1-full/drivers/isdn/capi/kcapi_proc.c.old
2005-02-05 15:36:10.0 +0100
+++ linux-2.6.11-rc3-mm1-full/drivers/isdn/capi/kcapi_proc.c2005-02-05 
15:36:43.0 +0100
@@ -89,14 +89,14 @@
return 0;
 }
 
-struct seq_operations seq_controller_ops = {
+static struct seq_operations seq_controller_ops = {
.start  = controller_start,
.next   = controller_next,
.stop   = controller_stop,
.show   = controller_show,
 };
 
-struct seq_operations seq_contrstats_ops = {
+static struct seq_operations seq_contrstats_ops = {
.start  = controller_start,
.next   = controller_next,
.stop   = controller_stop,
@@ -192,14 +192,14 @@
return 0;
 }
 
-struct seq_operations seq_applications_ops = {
+static struct seq_operations seq_applications_ops = {
.start  = applications_start,
.next   = applications_next,
.stop   = applications_stop,
.show   = applications_show,
 };
 
-struct seq_operations seq_applstats_ops = {
+static struct seq_operations seq_applstats_ops = {
.start  = applications_start,
.next   = applications_next,
.stop   = applications_stop,
@@ -287,7 +287,7 @@
return 0;
 }
 
-struct seq_operations seq_capi_driver_ops = {
+static struct seq_operations seq_capi_driver_ops = {
.start  = capi_driver_start,
.next   = capi_driver_next,
.stop   = capi_driver_stop,

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

[2.6 patch] drivers/isdn/act2000/capi.c: #if 0 an unused function

[Adrian Bunk]

This patch #if 0's an unused function.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 drivers/isdn/act2000/capi.c |2 ++
 drivers/isdn/act2000/capi.h |1 -
 2 files changed, 2 insertions(+), 1 deletion(-)

--- linux-2.6.11-rc3-mm1-full/drivers/isdn/act2000/capi.h.old   2005-02-05 
15:07:29.0 +0100
+++ linux-2.6.11-rc3-mm1-full/drivers/isdn/act2000/capi.h   2005-02-05 
15:07:35.0 +0100
@@ -350,7 +350,6 @@
 extern int actcapi_chkhdr(act2000_card *, actcapi_msghdr *);
 extern int actcapi_listen_req(act2000_card *);
 extern int actcapi_manufacturer_req_net(act2000_card *);
-extern int actcapi_manufacturer_req_v42(act2000_card *, ulong);
 extern int actcapi_manufacturer_req_errh(act2000_card *);
 extern int actcapi_manufacturer_req_msn(act2000_card *);
 extern int actcapi_connect_req(act2000_card *, act2000_chan *, char *, char, 
int, int);
--- linux-2.6.11-rc3-mm1-full/drivers/isdn/act2000/capi.c.old   2005-02-05 
15:07:42.0 +0100
+++ linux-2.6.11-rc3-mm1-full/drivers/isdn/act2000/capi.c   2005-02-05 
15:08:02.0 +0100
@@ -224,6 +224,7 @@
 /*
  * Switch V.42 on or off
  */
+#if 0
 int
 actcapi_manufacturer_req_v42(act2000_card *card, ulong arg)
 {
@@ -242,6 +243,7 @@
ACTCAPI_QUEUE_TX;
 return 0;
 }
+#endif  /*  0  */
 
 /*
  * Set error-handler

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

[2.6 patch] drivers/isdn/hardware/avm/: misc cleanups

[Adrian Bunk]

This patch makes the following cleanups:
- make some needlessly global functions static
- b1dma.c __init/__exit the functions b1dma_{init,exit}

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 drivers/isdn/hardware/avm/b1dma.c |4 ++--
 drivers/isdn/hardware/avm/c4.c|6 +++---
 drivers/isdn/hardware/avm/t1isa.c |2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

--- linux-2.6.11-rc3-mm1-full/drivers/isdn/hardware/avm/b1dma.c.old 
2005-02-05 15:40:43.0 +0100
+++ linux-2.6.11-rc3-mm1-full/drivers/isdn/hardware/avm/b1dma.c 2005-02-05 
15:42:32.0 +0100
@@ -955,7 +955,7 @@
 EXPORT_SYMBOL(b1dma_send_message);
 EXPORT_SYMBOL(b1dmactl_read_proc);
 
-int b1dma_init(void)
+static int __init b1dma_init(void)
 {
char *p;
char rev[32];
@@ -972,7 +972,7 @@
return 0;
 }
 
-void b1dma_exit(void)
+static void __exit b1dma_exit(void)
 {
 }
 
--- linux-2.6.11-rc3-mm1-full/drivers/isdn/hardware/avm/c4.c.old
2005-02-05 15:42:47.0 +0100
+++ linux-2.6.11-rc3-mm1-full/drivers/isdn/hardware/avm/c4.c2005-02-05 
15:43:16.0 +0100
@@ -885,7 +885,7 @@
 }
 
 
-void c4_reset_ctr(struct capi_ctr *ctrl)
+static void c4_reset_ctr(struct capi_ctr *ctrl)
 {
avmcard *card = ((avmctrl_info *)(ctrl->driverdata))->card;
avmctrl_info *cinfo;
@@ -933,7 +933,7 @@
 /* - */
 
 
-void c4_register_appl(struct capi_ctr *ctrl,
+static void c4_register_appl(struct capi_ctr *ctrl,
u16 appl,
capi_register_params *rp)
 {
@@ -978,7 +978,7 @@
 
 /* - */
 
-void c4_release_appl(struct capi_ctr *ctrl, u16 appl)
+static void c4_release_appl(struct capi_ctr *ctrl, u16 appl)
 {
avmctrl_info *cinfo = (avmctrl_info *)(ctrl->driverdata);
avmcard *card = cinfo->card;
--- linux-2.6.11-rc3-mm1-full/drivers/isdn/hardware/avm/t1isa.c.old 
2005-02-05 15:43:33.0 +0100
+++ linux-2.6.11-rc3-mm1-full/drivers/isdn/hardware/avm/t1isa.c 2005-02-05 
15:43:41.0 +0100
@@ -328,7 +328,7 @@
return 0;
 }
 
-void t1isa_reset_ctr(struct capi_ctr *ctrl)
+static void t1isa_reset_ctr(struct capi_ctr *ctrl)
 {
avmctrl_info *cinfo = (avmctrl_info *)(ctrl->driverdata);
avmcard *card = cinfo->card;

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Legacy IO spaces (was Re: [RFC] Reliable video POSTing on resume)

[Jesse Barnes]

On Saturday, February 05, 2005 4:07 pm, Jon Smirl wrote:
> After thinking about this for a while I believe the solution is for
> bridges that implement a legacy space to export legacy_io/mem in
> sysfs. So in the ia64 world, all bridges would export these attributes
> since each bridge creates a unique legacy space.

Except some ia64 platforms don't have one legacy space per host bus like sn2 
does.

> Some questions...
> 1) Does the IA64 have child bridges that don't implement legacy space?

Yes, on sn2 each host<->pci bridge has two busses hanging off it, and each of 
them has its own legacy space.  Child bridges under that bus are routed 
according to the child bridge, which may not route legacy accesses.

> If so then they need to support VGA routing. What about Cardbus?

No ia64 boxes that I know of support cardbus.

> 2) Does an IA64 bridge supporting different legacy spaces alter the
> VGA io request to remove the offset and then send it out onto the bus?

Pretty much, yes.

> 3) How does all of this work with Opteron and Hypertransport?

Don't know, Andi probably does.

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

Re: Why is debugging under Linux such a pain

[Tomasz Rola]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, 5 Feb 2005, Marko Macek wrote:

[...]
> It would be nice if display lock programs used a separate X display 
> (some kind of "virtual" display support might be nice to have, mainly 
> for performance).

I would try VNC for this, at least for debugging. But I don't really know
if it would have worked. My distro (Debian) has VNC packed nicely
(vncserver and xvncviewer packages), others should have it too. So the
trial should be rather quick if you use such Linux flavor.

I mean, open debugged app on a VNC display and have gdb on real one. You
can also view your VNC display with a viewer in a window and it should not
mess your real X session. But I may be wrong, never tried VNC for such
kind of work even though I use it very often.

One can also do similar thing with simply having two X sessions on two
consoles, I suppose. However, frequent switching between them may not be
very healthy for hardware.

Well, I'm just thinking loudly.

Regards,
Tomasz Rola

- --
** A C programmer asked whether computer had Buddha's nature.  **
** As the answer, master did "rm -rif" on the programmer's home**
** directory. And then the C programmer became enlightened...  **
** **
** Tomasz Rola  mailto:[EMAIL PROTECTED] **

-BEGIN PGP SIGNATURE-
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv

iQA/AwUBQgVjjBETUsyL9vbiEQLKIQCfb0g29u44eOiRWSC2t8/I27KvJuwAoLun
pWXajzIauR1ebxYX17Xyinos
=Fkjv
-END PGP SIGNATURE-


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

Re: [PATCH 2.6.11-rc2 03/14] ide_pci: Merges cmd64x.h into cmd64x.c

[Bartlomiej Zolnierkiewicz]

On Fri,  4 Feb 2005 16:13:17 +0900 (KST), Tejun Heo <[EMAIL PROTECTED]> wrote:
> 
> 03_ide_pci_cmd64x_merge.patch
> 
> Merges ide/pci/cmd64x.h into cmd64x.c.
> 
> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>

applied
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [ACPI] Re: Legacy IO spaces (was Re: [RFC] Reliable video POSTing on resume)

[Jon Smirl]

On Sun, 06 Feb 2005 09:42:32 +1100, Benjamin Herrenschmidt
<[EMAIL PROTECTED]> wrote:
>  I think it could be as simple as an additional sysfs entry
> "legacy_enabled" added to all "VGA" devices in the system at the PCI
> layer level. Toggling it triggers the "untoggling" of all others,
> including VGA forwarding on bridges, and enables the path to that
> device. For in-kernel users, a pci_* API would work.
> 
> The problem I see though is that it should all be synchronous &
> spinlocked since the vgacon could want to grab at interrupt time (unless
> it's locked by userland, in which case, vgacon should cache & trigger an
> update later).

This is my current code it adds a vga entry to all VGA devices in the system.
http://kerneltrap.org/mailarchive/1/message/15974/flat

Instead of toggle there are four states:
1) off
2) on - make sure everything else is off
3) turn off all VGA devices and remember the active one
4) restore the active one

States 3 and 4 and used for running the reset program. Set state 3 to
remember the active device and turn it off, reset the card which will
enable it's VGA, disable it, set state 4 to restore the saved device.

This thread is active too:
Reliable video POSTing on resume

Restart video after resume is the same problem as posting it in the first place.

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

Re: [PATCH 2.6.11-rc2 02/14] ide_pci: Merges aec62xx.h into aec62xx.c

[Bartlomiej Zolnierkiewicz]

On Fri,  4 Feb 2005 16:13:17 +0900 (KST), Tejun Heo <[EMAIL PROTECTED]> wrote:
> 
> 02_ide_pci_aec62xx_merge.patch
> 
> Merges ide/pci/aec62xx.h into aec62xx.c.
> 
> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>

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

Re: [linux-usb-devel] 2.6.11-rc[23]: swsusp & usb regression

[David Brownell]

On Saturday 05 February 2005 3:14 pm, Pavel Machek wrote:
> Hi!
> 
> > Your logs don't indicate which host controller driver is bound to each of 
> > your hubs.  /proc/bus/usb/devices will contain that information.  Without 
> > it, it's hard to diagnose what happened.
> 
> I do not think I have any hubs... no external hubs anyway. And I do
> not have /proc/bus/usb/devices file :-(. There's something in
> /sys/bus/usb/devices/.

So what does "lspci -v|grep HCI" say then?

You could try "mount -t usbfs on /proc/bus/usb" ... ;)

Periodically I think that it'd be useful to have the hub driver messages
report the HCD involved, somehow, instead of just "hub", at least when
root hub ports are involved.  It could improve the utility of some bug
reports by a significant amount.

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

Re: 2.6.11-rc3-mm1 - broken bttv ?

[Eyal Lebedinsky]

jjluza wrote:
I have a problem with my bttv card, I get these error messages when I try to 
access the TV device (and of course I can't watch TV) :
I am having bttv problems with vanilla -rc3. Does it work for you?
--
Eyal Lebedinsky ([EMAIL PROTECTED]) 
attach .zip as .dat
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Legacy IO spaces (was Re: [RFC] Reliable video POSTing on resume)

[Jon Smirl]

After thinking about this for a while I believe the solution is for
bridges that implement a legacy space to export legacy_io/mem in
sysfs. So in the ia64 world, all bridges would export these attributes
since each bridge creates a unique legacy space.

In the x86 and I believe the ppc world, only host bridges create
legacy spaces and should have the legacy_io/mem attributes. All child
bridges should not export them.

This may be best handled by implementing bridge drivers. In my case I
need these:

Host needs to export a legacy io/mem space
8086:2578 - Host bridge: Intel Corp. 82875P/E7210 Memory Controller Hub

Child bridges do not export legacy space but implement VGA routing
8086:2579 - PCI bridge: Intel Corp. 82875P Processor to AGP Controller
8086:244e - PCI bridge: Intel Corp. 82801 PCI Bridge

I also have this..
8086:24d0 - ISA bridge: Intel Corp. 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge
But this is implementing the devices in the legacy space, it's the
host bridge that is creating the space.

Some questions...
1) Does the IA64 have child bridges that don't implement legacy space?
If so then they need to support VGA routing. What about Cardbus?
2) Does an IA64 bridge supporting different legacy spaces alter the
VGA io request to remove the offset and then send it out onto the bus?
3) How does all of this work with Opteron and Hypertransport?


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

Re: [PATCH 2.6.11-rc2 01/14] ide_pci: Remove lousy macros from aec62xx.

[Bartlomiej Zolnierkiewicz]

On Fri,  4 Feb 2005 16:13:17 +0900 (KST), Tejun Heo <[EMAIL PROTECTED]> wrote:
> 
> 01_ide_pci_aec62xx_cleanup.patch
> 
> Removes SPLIT_BYTE, MAKE_WORD and BUSCLOCK macros which are
> just better off directly coded from ide/pci/aec62xx driver.
> 
> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>

applied but I left BUSCLOCK() alone for now
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Linux Kernel Subversion Howto

[Larry McVoy]

On Sat, Feb 05, 2005 at 08:38:48PM +0100, Stelian Pop wrote:
> > Nope: he digs the bk-commit mailing list archives.
> > 
> Interesting, I fergot about those commit mails, thanks for remining
> me.
> 
> I think those emails could provide the missing piece of the puzzle
> and we could generate the missing branches based on them. 

Does that mean you don't need anything from us?
-- 
---
Larry McVoylm at bitmover.com   http://www.bitkeeper.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Configure MTU via kernel DHCP

[Eric W. Biederman]

Hans-Peter Jansen <[EMAIL PROTECTED]> writes:

> Hi Shane,
> 

> Difference: 181 Bytes (padding ignored)
> 
> The whole module takes about 9K, compared to dhcp in initrd, which 
> takes a few hundred K! Hmm.

And the kinit from the klibc package (A static executable that
does everything the kernel currently does for mounting root
including handling what ipconfig handles it in only 35K (uncompressed).

> That's an interesting question. Please keep me informed on any new 
> perceptions in this respect.
> 
> May the linux gods indulge on this topic one day or remove the 
> ipconfig module completely.

Well that actually is the goal.  A major problem is that there
are enough policy issues that the kernel simply cannot get it right,
for all users.

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

Re: [linux-usb-devel] 2.6.11-rc[23]: swsusp & usb regression

[Pavel Machek]

Hi!

> > In 2.6.11-rc[23], I get problems after swsusp resume:
> > 
> > Feb  4 23:54:39 amd kernel: Restarting tasks...<3>hub 3-0:1.0:
> > over-current change on port 1
> > Feb  4 23:54:39 amd kernel:  done
> > Feb  4 23:54:39 amd kernel: hub 3-0:1.0: connect-debounce failed, port
> > 1 disabled
> > Feb  4 23:54:39 amd kernel: hub 3-0:1.0: over-current change on port 2
> > Feb  4 23:54:39 amd kernel: usb 3-2: USB disconnect, address 2
> > 
> > After unplugging usb bluetooth key, machine hung. Sysrq still
> > responded with help but I could not get any usefull output.
> 
> Your logs don't indicate which host controller driver is bound to each of 
> your hubs.  /proc/bus/usb/devices will contain that information.  Without 
> it, it's hard to diagnose what happened.

I do not think I have any hubs... no external hubs anyway. And I do
not have /proc/bus/usb/devices file :-(. There's something in
/sys/bus/usb/devices/.

> As things stand now, however, there's likely to be lots of problems in the 
> coordination of suspend/resume activities among the HCDs, the glue layer, 
> and the hub driver.  One thing you could try is to turn on 
> CONFIG_USB_SUSPEND.  It's likely to change things, although not 
> necessarily for the better.  :-)

:-).
Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Dynamic tick, version 050127-1

[Pavel Machek]

Hi!

> > > > It could also be that the reprogamming of PIT timer does not work on
> > > > your machine. I chopped off the udelays there... Can you try
> > > > something like this:
> > > 
> > > I added the udelays, but behaviour did not change.
> > 
> > Yeah, and if the first patch was working better, that means the PIT
> > interrupts work. I'll do another version of the patch where PIT
> > interrupts work again without local APIC needed, let's see what
> > happens with that.
> 
> I think something broke TSC timer after the first patch, but I could
> not figure out yet what. So the bad combo might be local APIC + TSC.
> At least I'm seeing similar problems with local APIC + TSC timer.
> 
> Attached is a slightly improved patch, but the patch does not fix
> the TSC problem. It just fixes compile without local APIC, and
> booting SMP kernel on uniprocessor machine.
> 
> Currently the suggested combo is local APIC + ACPI PM timer...

Ok, works slightly better: time no longer runs 2x too fast. When TSC
is used, I get same behaviour  as before ("sleepy machine"). With
"notsc", machine seems to work okay, but I still get 1000 timer
interrupts a second.

> And if that works, changing the I8042_POLL_PERIOD from HZ/20 in
> drivers/input/serio/i8042.h to something like HZ increases the
> sleep interval quite a bit. I think I had lots of polling also in
> CONFIG_NETFILTER, but I haven't verified that.

Okay, I set POLL_PERIOD to 5*HZ, and disabled USB. Perhaps it will
sleep better now?
Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] adding the ICS MK712 touchscreen driver to 2.6

[Dmitry Torokhov]

On Saturday 05 February 2005 16:02, Vojtech Pavlik wrote:
v> On Wed, Jan 19, 2005 at 04:18:49PM -0500, Richard Koch wrote:
> > Please include the patch below to bring the ICS MK712 touchscreen controller
> > support, which is in kernel 2.4, in to kernel 2.6.
> > 
> > This patch was constructed and applied to kernel version 2.6.10 and tested
> > successfully on several Gateway AOL Connected Touchpad computers.
> > 
> > This was based on the mk712.c 2.4.28 version. No functional changes applied 
> > only minor
> > changes to conform to the 2.6 build structure. I choose to place the driver 
> > under
> > input/touchscreen as this seemed most appropriate.
> > 
> > By making a contribution to this project, I certify that:
> > 
> > The contribution is based upon previous work that, to the best
> > of my knowledge, is covered under an appropriate open source
> > license and I have the right under that license to submit that
> > work with modifications, whether created in whole or in part
> > by me, under the same open source license (unless I am
> > permitted to submit under a different license), as indicated
> > in the file.
> > 
> > Signed-off-by: Rick Koch <[EMAIL PROTECTED]>
> > 
> > patch also available at: http://home.comcast.net/~n1gp/mk712_2.6_patch
> 
> I converted it to a proper input driver for you. ;) Can you check it if
> it still works?
> 
> +static irqreturn_t mk712_interrupt(int irq, void *dev_id, struct pt_regs 
> *regs)
> +{
> +unsigned char status;
> +static int debounce = 1;
> + static unsigned short last_x;
> + static unsigned short last_y;
> +
> + input_regs(_dev, regs);
> +
> +status = inb(mk712_io + MK712_STATUS);
> +
> + if (~status & MK712_CONVERSION_COMPLETE) {
> +debounce = 1;
> + goto end;
> + }
> +
> + if (~status & MK712_STATUS_TOUCH)
> + {
> +debounce = 1;
> + input_report_key(_dev, BTN_TOUCH, 0);
> + goto end;
> + }
> +
> +if (debounce)
> +{
> + debounce = 0;
> + goto end;
> +}
> +
> + input_report_key(_dev, BTN_TOUCH, 1);
> + input_report_abs(_dev, ABS_X, last_x);
> + input_report_abs(_dev, ABS_Y, last_y);

Severe TAB vs. space damage...

> +static int mk712_open(struct input_dev *dev)
> +{
> + 
> + if (mk712_used++)
> + return 0;
> +
> + outb(0, mk712_io + MK712_CONTROL); /* Reset */
> +

We really should stop ignoring races and locking issues. Atomic perhaps?


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

Re: irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)

[Rogério Brito]

On Feb 05 2005, Rogério Brito wrote:
> I am including the dmesg log of my system with this message.
(...)

Ooops! Forgot to include the dmesg in the previous message. :-(


Thanks again, Rogério.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Linux version 2.6.11-rc3-1 ([EMAIL PROTECTED]) (gcc version 3.3.5 (Debian 
1:3.3.5-5)) #1 Thu Feb 3 01:41:08 BRST 2005
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009e800 (usable)
 BIOS-e820: 0009e800 - 000a (reserved)
 BIOS-e820: 000f - 0010 (reserved)
 BIOS-e820: 0010 - 0ffec000 (usable)
 BIOS-e820: 0ffec000 - 0ffef000 (ACPI data)
 BIOS-e820: 0ffef000 - 0000 (reserved)
 BIOS-e820: 0000 - 1000 (ACPI NVS)
 BIOS-e820:  - 0001 (reserved)
255MB LOWMEM available.
On node 0 totalpages: 65516
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 61420 pages, LIFO batch:14
  HighMem zone: 0 pages, LIFO batch:1
DMI 2.3 present.
ACPI: RSDP (v000 ASUS  ) @ 0x000f6a90
ACPI: RSDT (v001 ASUS   A7V  0x30303031 MSFT 0x31313031) @ 0x0ffec000
ACPI: FADT (v001 ASUS   A7V  0x30303031 MSFT 0x31313031) @ 0x0ffec080
ACPI: BOOT (v001 ASUS   A7V  0x30303031 MSFT 0x31313031) @ 0x0ffec040
ACPI: DSDT (v001   ASUS A7V  0x1000 MSFT 0x010b) @ 0x
ACPI: PM-Timer IO Port: 0xe408
Built 1 zonelists
Kernel command line: BOOT_IMAGE=Linux root=2103 irqpoll
Local APIC disabled by BIOS -- you can enable it with "lapic"
mapped APIC to d000 (01201000)
Initializing CPU#0
PID hash table entries: 1024 (order: 10, 16384 bytes)
Detected 605.655 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: 256196k/262064k available (1674k kernel code, 5308k reserved, 728k 
data, 140k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 1196.03 BogoMIPS (lpj=598016)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: After generic identify, caps: 0183f9ff c1c7f9ff    
 
CPU: After vendor identify, caps: 0183f9ff c1c7f9ff    
 
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 64K (64 bytes/line)
CPU: After all inits, caps: 0183f9ff c1c7f9ff  0020  
 
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: AMD Duron(tm) Processor stepping 00
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
ACPI: setting ELCR to 0200 (from 0e20)
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xf1180, last bus=1
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20050125
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
PCI: Via IRQ fixup
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 13 devices
PCI: Using ACPI for IRQ routing
** 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.
TC classifier action (bugs to netdev@oss.sgi.com cc [EMAIL PROTECTED])
pnp: 00:02: ioport range 0xe400-0xe47f could not be reserved
pnp: 00:02: ioport range 0xe800-0xe80f has been reserved
Simple Boot Flag at 0x3a set to 0x1
Machine check exception polling timer started.
IA-32 Microcode Update Driver: v1.14 <[EMAIL PROTECTED]>
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac)
apm: overridden by ACPI.
Initializing Cryptographic API
PCI: Disabling Via external APIC routing
ACPI: Power Button (FF) [PWRF]
ACPI: CPU0 (power states: C1[C1] C2[C2])
ACPI: Processor [CPU0] (supports 16 throttling states)
lp: driver loaded but no devices found
Real Time Clock Driver v1.12
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected VIA Twister-K/KT133x/KM133 chipset
agpgart: Maximum main 

irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)

[Rogério Brito]

Dear developers,

For some kernel versions (say, since 2.6.10 proper, all the 2.6.11-rc's,
some -mm trees and also -ac) I have been getting the message "irq 10:
nobody cared!".

The message says that I should pass the irqpoll option to the kernel and
even if I do, I still get the stack trace and the "irq 10: nobody cared!"
message. :-(

The message seems to be related to the Promise PDC20265 driver and it
appeared right after I moved my HDs from my motherboard's VIA controllers
to the Promise controllers. I have an Asus A7V board, with 2 VIA 686a
controllers and 2 Promise PDC20265 controllers.

I already tried enabling and disabling ACPI, but it seems that the problem
just doesn't go away. :-(

I am including the dmesg log of my system with this message. I am CC'ing
the linux-ide list, but I'm only subscribed to linux-kernel. I would
appreciate CC's, if possible.


Thank you very much for any help, Rogério.

P.S.: I am, right now, re-compiling 2.6.11-rc3-mm1 with the extra pass of
kallsyms to see if the problem persists with this release.
-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ACPI] Re: Legacy IO spaces (was Re: [RFC] Reliable video POSTing on resume)

[Benjamin Herrenschmidt]

> If they all point to the same space, I can't tell whether I have three
> legacy spaces or one. I need to know how many legacy spaces there are
> in order to know how many VGA cards can simultaneously be enabled.

You don't need to care about this, at least in userland. All you need
is proper primitives for locking/unlocking access to a given device.
Wether you have another one to arbitrate with on the same PCI bus or not
is almost irrelevant. That is, it is the job of the kernel driver that
ultimately will do this arbitration (we really need that), and we can
prefectly well survive a long time with a very simple implementation
taht always disable all other VGA devies in the system, not caring about
"simultaneous" access. That implementation can be then improved on
later.

My point is what we really need to define is the in-kernel and userland
API to do this basic VGA access arbitration in the first place. I though
you did something like that a while ago Jon, didn't you ?

I think it could be as simple as an additional sysfs entry
"legacy_enabled" added to all "VGA" devices in the system at the PCI
layer level. Toggling it triggers the "untoggling" of all others,
including VGA forwarding on bridges, and enables the path to that
device. For in-kernel users, a pci_* API would work.

The problem I see though is that it should all be synchronous &
spinlocked since the vgacon could want to grab at interrupt time (unless
it's locked by userland, in which case, vgacon should cache & trigger an
update later).

Ben.


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

Re: 2.6.11-rc3-mm1

[Benjamin Herrenschmidt]

On Sat, 2005-02-05 at 10:48 +, Sean Neakums wrote:
> Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> writes:
> 
> > On Sat, 05 Feb 2005 11:16:49 +1100, Benjamin Herrenschmidt
> > <[EMAIL PROTECTED]> wrote:
> >> 
> >> > I tried it two or three times, same result each time.  I'll give it a
> >> > lash with USB disabled.
> >> 
> >> Also, can you try editing arch/ppc/syslib/open_pic.c, in function
> >> openpic_resume(), comment out the call to openpic_reset() and let me
> >> know if that helps...
> >
> > Well, maybe I'm to blame this time...
> >
> > I've introduced bug in ATAPI Power Management handling,
> > idedisk_pm_idle shouldn't be done for ATAPI devices.
> >
> > Sorry for that, fix attached.
> 
> With this patch alone and with USB configured out, suspend/resume works.

Confirmation from paulus, there is indeed a problem with IDE that is
fixed by Bart's patch.

There are still issues with USB though... this one, and paul's one, I've
forwarded Sean report to David, we'll see what we can find...

Ben.


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

Re: 2.6.11-rc3-mm1

[Rogério Brito]

On Feb 05 2005, Jurriaan wrote:
> From: Rogério Brito <[EMAIL PROTECTED]>
> Date: Sat, Feb 05, 2005 at 04:10:18PM -0200
> > Inconsistent kallsyms data
> > Try setting CONFIG_KALLSYMS_EXTRA_PASS
> > make[1]: *** [vmlinux] Error 1
> > make[1]: Leaving directory `/usr/local/media/progs/linux/kernel/linux'
> > make: *** [stamp-build] Error 2
> 
> Read what it says, and enable CONFIG_KALLSYMS_EXTRA_PASS, then try
> again.

Taken straight from the help option for CONFIG_KALLSYMS_EXTRA_PASS:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Always say N here unless you find a bug in kallsyms, which must be
reported.  KALLSYMS_EXTRA_PASS is only a temporary workaround while
you wait for kallsyms to be fixed.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

I received, BTW, a message from Frank Denis saying that this is fixed in
his -jedi1 patch.

I will try it and report back the results that I come up with.


Thanks for the feedback anyway, Rogério.

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

Re: 2.6.11-rc3-bk1: ide1: failed to initialize IDE interface

[Jean Delvare]

Hi again Bartlomiej, all,

> > Notice how ide1, which happens to have no device attached, is listed
> > twice. I can reproduce this on my second system as well (i386 too,
> > but otherwise completely different). I guess it doesn't cause any
> > trouble, but looks suboptimal.
> 
> CONFIG_IDE_GENERIC is enabled
> 
> > While we're at it, I also wonder why ide2-ide5 are probed, when
> > neither of my systems has them.
> 
> CONFIG_IDE_GENERIC again

You got it. Disabling CONFIG_IDE_GENERIC let me get rid of these
duplicate/additional probes. Thanks for the hint :)

A real help text attached to this configuration option would certainly
have helped here. And the label misses its leading capital.

> Alan has a patch in -ac to not probe for legacy ports if system
> has PCI but it needs testing and is limited to x86 currently.
> Also it not a full solution as legacy ports logic needs to be
> moved to ide_generic anyway...

Maybe the option should be relabelled from "generic/default IDE chipset
support" to "Non-PCI IDE chipset support" or "Legacy IDE ports support"?
I think it should express the fact that people with modern systems do
not need it, providing this is actually the case - not sure I exactly
understand what it is.

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

Re: 2.6.11-rc3: intel8x0 alsa outputs no sound

[Narayan Desai]

Try muting the headphone jack sense control with alsamixer. I had the
same problem with rc2 on my t41p, and that solved it.
 -nld
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: PNP and suspend/resumt

[Adam Belay]

On Sat, Feb 05, 2005 at 05:23:58PM +0100, Pierre Ossman wrote:
> How is suspend/resume handled with PNP devices? There are no 
> suspend/resume functions registered for the pnp bus type.
> 
> Rgds
> Pierre

PnP isn't a physical abstraction, so for now if you want to set the values
in "struct device_driver" directly, go for it.

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

Re: Strange device init

[Adam Belay]

On Sat, Feb 05, 2005 at 06:10:02PM +0100, Pierre Ossman wrote:
> I'm having problem with a card reader on a laptop (Acer Aspire 1501). 
> The device doesn't get its resources configured properly.
> 
> The reader is connected to the LPC bus so there is no standardised way 
> to configure the device. On other laptops the configuration is done via 
> ACPI (_STA & co. in the DSDT). On this laptop these functions don't do a 
> damn thing.
> In Windows this device gets configured through some other means. It's 
> not in the driver (I've disected it to confirm this). But under Linux 
> the device is left unconfigured.
> 
> So my question is if anyone has any ideas on how this device gets 
> configured by Windows and possibly how we can get this to work on Linux.
> 
> The reason this is an issue is that one cannot detect all the quirks of 
> the hardware so a PNP solution is prefered. In those cases the 
> manufacturer has chosen resources that work ok.
> 
> For some context: I am the maintainer of the driver for this hardware. I 
> have a laptop where the DSDT properly sets up the hardware. The Acer 
> belongs to some of my users but they are not familiar with the kernel so 
> I'm trying to fix this for them.
> 
> Rgds
> Pierre

So the device is not listed in the DSDT, or _SRS doesn't work?  Does _STA
succeed?  Finally have you checked if PnPBIOS detects the device?  Any
additional information you could provide would be appreciated.

Thanks,
Adam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: L1_CACHE

[Dave Jones]

On Sat, Feb 05, 2005 at 11:45:22AM +, Axel Schmalowsky wrote:
 > Hey,
 > 
 > Can anyone tell me if it is destruktive or does it cause lose of 
 > performance if I set up
 > L1_CACHE_SHIFT_MAX as well as CONFIG_X86_L1_CACHE_SHIFT to the value of 10?

This makes no sense. This define is for the cacheline size, not
the total size of the cache.

Dave

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

Re: [PATCH 0/7] driver core: export MAJOR/MINOR to the hotplug env

[Kay Sievers]

On Fri, Feb 04, 2005 at 10:16:36PM -0800, Greg KH wrote:
> On Wed, Feb 02, 2005 at 01:48:12AM +0100, Kay Sievers wrote:
> > On Tue, Feb 01, 2005 at 02:56:25PM -0800, Greg KH wrote:
> > > Hm, that class_simple interface is looking like the way we should move
> > > toward, as it's "simple" to use, instead of the more complex class code.
> > > I'll have to look at migrating more code to use it over time, or move
> > > that interface back into the class code itself...
> > 
> > Nice idea! What about keeping a list of devices belonging to a
> > specific class in an own list in 'struct class' and maintaining that list
> > with class_device_add(), class_device_del()?
> 
> What would that help out with?
> 
> > A class driver may use that list to keep track of its own devices if
> > wanted and class_simple would not be needed anymore as everything
> > would be available in the core.
> 
> I must be tired, but I don't see how class_simple could be dropped if
> that was done.  Care to explain it with pseudo-code or something?

Sure, here is a patch for illustration. The needed class_simple logic
is moved to the core. It uses the class's children list to keep track of
the created devices. The tty and the input layer are changed to use the
new interface.

With this change, a driver still has the convenient class support without
the need to care about allocation and release functions. But it uses the
same data structures like a full featured class implementation.

Thanks,
Kay


= drivers/base/class.c 1.58 vs edited =
--- 1.58/drivers/base/class.c   2005-02-05 19:35:12 +01:00
+++ edited/drivers/base/class.c 2005-02-05 22:23:45 +01:00
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "base.h"
 
 #define to_class_attr(_attr) container_of(_attr, struct class_attribute, attr)
@@ -161,6 +162,52 @@ void class_unregister(struct class * cls
subsystem_unregister(>subsys);
 }
 
+static void class_create_release(struct class *cls)
+{
+   kfree(cls);
+}
+
+static void class_device_create_release(struct class_device *class_dev)
+{
+   kfree(class_dev);
+}
+
+struct class *class_create(char *name)
+{
+   struct class *cls;
+   int retval;
+
+   cls = kmalloc(sizeof(struct class), GFP_KERNEL);
+   if (!cls) {
+   retval = -ENOMEM;
+   goto error;
+   }
+   memset(cls, 0x00, sizeof(struct class));
+
+   cls->name = name;
+   cls->class_release = class_create_release;
+   cls->release = class_device_create_release;
+
+   retval = class_register(cls);
+   if (retval)
+   goto error;
+
+   return cls;
+
+error:
+   kfree(cls);
+   return ERR_PTR(retval);
+}
+EXPORT_SYMBOL_GPL(class_create);
+
+void class_destroy(struct class *cls)
+{
+   if ((cls == NULL) || (IS_ERR(cls)))
+   return;
+
+   class_unregister(cls);
+}
+EXPORT_SYMBOL_GPL(class_destroy);
 
 /* Class Device Stuff */
 
@@ -468,6 +515,42 @@ int class_device_register(struct class_d
return class_device_add(class_dev);
 }
 
+struct class_device *class_device_create(struct class *cls, dev_t devt,
+struct device *device, char *fmt, ...)
+{
+   va_list args;
+   struct class_device *class_dev;
+   int retval;
+
+   if (cls == NULL || IS_ERR(cls))
+   return ERR_PTR(-ENODEV);
+
+   class_dev = kmalloc(sizeof(struct class_device), GFP_KERNEL);
+   if (!class_dev) {
+   retval = -ENOMEM;
+   goto error;
+   }
+   memset(class_dev, 0x00, sizeof(struct class_device));
+
+   class_dev->devt = devt;
+   class_dev->dev = device;
+   class_dev->class = cls;
+
+   va_start(args, fmt);
+   vsnprintf(class_dev->class_id, BUS_ID_SIZE, fmt, args);
+   va_end(args);
+   retval = class_device_register(class_dev);
+   if (retval)
+   goto error;
+
+   return 0;
+
+error:
+   kfree(class_dev);
+   return ERR_PTR(retval);
+}
+EXPORT_SYMBOL_GPL(class_device_create);
+
 void class_device_del(struct class_device *class_dev)
 {
struct class * parent = class_dev->class;
@@ -499,6 +582,25 @@ void class_device_unregister(struct clas
class_device_del(class_dev);
class_device_put(class_dev);
 }
+
+void class_device_destroy(struct class *cls, dev_t devt)
+{
+   struct class_device *class_dev = NULL;
+   struct class_device *class_dev_tmp;
+
+   down_write(>subsys.rwsem);
+   list_for_each_entry(class_dev_tmp, >children, node) {
+   if (class_dev_tmp->devt == devt) {
+   class_dev = class_dev_tmp;
+   break;
+   }
+   }
+   up_write(>subsys.rwsem);
+
+   if (class_dev)
+   class_device_unregister(class_dev);
+}
+EXPORT_SYMBOL_GPL(class_device_destroy);
 
 int class_device_rename(struct class_device *class_dev, char *new_name)
 {
= drivers/char/tty_io.c 1.159 vs 

Re: rtl8139 (8139too) net problem in linux 2.6.10

[OGAWA Hirofumi]

OGAWA Hirofumi <[EMAIL PROTECTED]> writes:

> Umm... Bit strange...
>
> I couldn't find the PCI4510 in yenta_table. Did you add the PCI4510 to
> yenta_table? Could you send "lspci -n" (what vendor-id and device-id)?

Grr... Ok, probably that was processed as default bridge.

Could you please try the following patch for debug?

Signed-off-by: OGAWA Hirofumi <[EMAIL PROTECTED]>
---

 drivers/pcmcia/yenta_socket.c |2 ++
 1 files changed, 2 insertions(+)

diff -puN drivers/pcmcia/yenta_socket.c~yenta-pci4510-debug 
drivers/pcmcia/yenta_socket.c
--- linux-2.6.11-rc3/drivers/pcmcia/yenta_socket.c~yenta-pci4510-debug  
2005-02-06 06:30:41.0 +0900
+++ linux-2.6.11-rc3-hirofumi/drivers/pcmcia/yenta_socket.c 2005-02-06 
06:32:13.0 +0900
@@ -1105,6 +1105,8 @@ static struct pci_device_id yenta_table 
CB_ID(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_4410, TI12XX),
CB_ID(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_4450, TI12XX),
CB_ID(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_4451, TI12XX),
+#define PCI_DEVICE_ID_TI_4510  0xac44
+   CB_ID(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_4510, TI12XX),
CB_ID(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_4520, TI12XX),
 
CB_ID(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_1250, TI1250),
_

-- 
OGAWA Hirofumi <[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/

question re usage of interruptible_sleep_on( ) function call in cpm_iic_tryaddress( ) function (in i2c-algo-8xx.c)

[Povolotsky, Alexander]

> Hello,
>  
> I have MPC880 microprocessor based board with single 24C02 I2C EEPROM,
> connected to the I2C bus.
> 
Yes, it is embedded, yes it is not INTEL arch ... but PLEASE - READ ON ! ;-)
>  
> Currently booting of the board hangs in the I2C driver after invocation of
> interruptible_sleep_on( )
>  function call  in cpm_iic_tryaddress( ) function (in i2c-algo-8xx.c
> file).
> 
> Is it appropriate to use the interruptible_sleep_on( ) function at the
> kernel booting stage ?
>  (I personally do not think so - since such usage prevents further kernel
> booting - as observed).
> What should be done in this code to avoid sleeping  forever - how to put
> time out on this sleep ?
> 
> I presume that the usage of the interruptible_sleep_on( ) function would
> be appropriate if the 
> I2C would be configured as a module (after the kernel booting is
> completed) ?
> Follow up question:  is it really expected to do I2C initialization ONLY
> as a module after the kernel booting ?
> (is it documented anyplace ?) 
> 
> The (end of) log buffer shows following:
> 
> <6>i2c /dev entries driver.
> <7>device class 'i2c-dev': registering.
> <7>bus i2c:add driver dev_driver.
> <7>i2c-core: driver dev_driver registered
> <6>i2c-rpx: i2c MPC8xx driver.
> <7>DEV: registering device: ID ='i2c-0'.
> <7>CLASS: registering class device: ID= 'i2c-0'.
> <7>i2c_adapter i2c-0:Registered as minor 0.
> <7>CLASS:registering class device: ID = 'i2c-0'
> <7>i2c_adapter i2c-0: registered as adapter #0.
> <4>cpm_iic_init() - iip=fa203c80.
> <4>cpm_iic_init[132] Install ISR for IRQ 16.
> <6>CPM interrupt c0105d90 replacing c01f7a8c.
> <3>request_irq() returned -22  for CPM vector 32.
> <6> i2c-algo-8xx.o: scanning bus m8xx
> <4>cpm_iic_tryaddress(cpm=c019b9f8,addr=0).
> <4>iip fa203c80, dp_addr 0x800.
> <4>iic_tbase 2048, r_tbase 2048
> <4>about to sleep
> .ABOVE LINE IS THE LAST ENTRY IN THE LOG BUFFER - THE BOOT HANGS
> THEREAFTER ... 
> 
> Here is the fragment of the cpm_iic_tryaddress( ) function in
> i2c-algo-8xx.c,
> where the problem takes place:
>  
> //  save_flags(flags); cli();
> i2c->i2c_i2cer = 0xff;
> i2c->i2c_i2cmr = 0x13;  /* Enable some interupts */
> i2c->i2c_i2mod = 1; /* Enable */
> i2c->i2c_i2com = 0x81;  /* Start master */
> //  restore_flags(flags);
> 
> if (cpm_debug > 1) printk("about to sleep\n");
> 
> /* wait for IIC transfer */
> interruptible_sleep_on(_wait);
> if (signal_pending(current))
> return -EIO;
> 
> if (cpm_debug > 1) printk("back from sleep\n");
> 
> if (tbdf->cbd_sc & BD_SC_NAK) {
> if (cpm_debug > 1) printk("IIC try; no ack\n");
> return 0;
> }
> 
> if (tbdf->cbd_sc & BD_SC_READY) {
> printk("IIC try; complete but tbuf ready\n");
> }
> 
> return 1;
> 
> 
> Thanks,
> Best Regards,
> Alex 
> 
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/