Re: Real-time rw-locks (Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-15)

[Ingo Molnar]

* Esben Nielsen <[EMAIL PROTECTED]> wrote:

> I noticed that you changed rw-locks to behave quite diferently under
> real-time preemption: They basicly works like normal locks now. I.e.
> there can only be one reader task within each region. This can can
> however lock the region recursively. [...]

correct.

> [...] I wanted to start looking at fixing that because it ought to
> hurt scalability quite a bit - and even on UP create a few unneeded
> task-switchs. [...]

no, it's not a big scalability problem. rwlocks are really a mistake -
if you want scalability and spinlocks/semaphores are not enough then one
should either use per-CPU locks or lockless structures. rwlocks/rwsems
will very unlikely help much.

> However, the more I think about it the bigger the problem:

yes, that complexity to get it perform in a deterministic manner is why
i introduced this (major!) simplification of locking. It turns out that
most of the time the actual use of rwlocks matches this simplified
'owner-recursive exclusive lock' semantics, so we are lucky.

look at what kind of worst-case scenarios there may already be with
multiple spinlocks (blocker.c). With rwlocks that just gets insane.

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 4/6 randomize the stack pointer

[Arjan van de Ven]

> I thought that this was the original purpose of the "stack randomization" 
> which is shipped for example by RedHat kernels, as the randomization is 
> quite small and easy to bruteforce, so it can't serve too much as a buffer 
> overflow protection.

correct; that was for the p4 hyperthreading case (that code fwiw is
still in the 2.6 mainline kernel and active; it randomizes over an 8k
region for this purpose)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/16] New set of input patches

[Dmitry Torokhov]

On Thursday 27 January 2005 11:15, Vojtech Pavlik wrote:
> > I think that the very first path ("while true; do xset led 3; xset
> > -led 3; done" makes keyboard miss release events and makes it
> > unusable) should go in 2.6.11 so please do:
> > 
> >         bk pull bk://dtor.bkbits.net/for-2.6.11
> 
> Pulled, pushed into my tree. I verified the patch, and it is indeed
> correct. Before we get an ACK for a command we sent, we still may
> receive normal data. After we got the ACK we know for sure that no more
> regular data will come, and can expect the command response.

Hi Vojtech,

I have another one that I think needs to be in 2.6.11 - in ps2_command
does not update timeout variable when waiting for the first byte of
response so even if command times out the code still goes and tries to
wait for more data. It actually causes problems with GETID command - we
end up reporting success even if we did not get any response (except for
initial ACK). 

Also, now taht wait_event_timeout is available we shoudl use it instead
of wait_event_interruptible_timeout.

-- 
Dmitry


===


[EMAIL PROTECTED], 2005-01-28 01:53:11-05:00, [EMAIL PROTECTED]
  Input: libps2 - fix timeout handling in ps2_command, switch to using
 wait_event_timeout instead of wait_event_interruptible_timeout
 now that first form is available.
  
  Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>


 libps2.c |   22 +++---
 1 files changed, 11 insertions(+), 11 deletions(-)


===



diff -Nru a/drivers/input/serio/libps2.c b/drivers/input/serio/libps2.c
--- a/drivers/input/serio/libps2.c  2005-01-28 02:12:06 -05:00
+++ b/drivers/input/serio/libps2.c  2005-01-28 02:12:06 -05:00
@@ -60,9 +60,9 @@
serio_continue_rx(ps2dev->serio);
 
if (serio_write(ps2dev->serio, byte) == 0)
-   wait_event_interruptible_timeout(ps2dev->wait,
-   !(ps2dev->flags & PS2_FLAG_ACK),
-   msecs_to_jiffies(timeout));
+   wait_event_timeout(ps2dev->wait,
+  !(ps2dev->flags & PS2_FLAG_ACK),
+  msecs_to_jiffies(timeout));
 
serio_pause_rx(ps2dev->serio);
ps2dev->flags &= ~PS2_FLAG_ACK;
@@ -115,8 +115,8 @@
 */
timeout = msecs_to_jiffies(command == PS2_CMD_RESET_BAT ? 4000 : 500);
 
-   wait_event_interruptible_timeout(ps2dev->wait,
-   !(ps2dev->flags & PS2_FLAG_CMD1), timeout);
+   timeout = wait_event_timeout(ps2dev->wait,
+!(ps2dev->flags & PS2_FLAG_CMD1), timeout);
 
if (ps2dev->cmdcnt && timeout > 0) {
 
@@ -147,8 +147,8 @@
serio_continue_rx(ps2dev->serio);
}
 
-   wait_event_interruptible_timeout(ps2dev->wait,
-   !(ps2dev->flags & PS2_FLAG_CMD), timeout);
+   wait_event_timeout(ps2dev->wait,
+  !(ps2dev->flags & PS2_FLAG_CMD), timeout);
}
 
if (param)
@@ -259,7 +259,7 @@
ps2dev->flags |= PS2_FLAG_CMD | PS2_FLAG_CMD1;
 
ps2dev->flags &= ~PS2_FLAG_ACK;
-   wake_up_interruptible(>wait);
+   wake_up(>wait);
 
if (data != PS2_RET_ACK)
ps2_handle_response(ps2dev, data);
@@ -281,12 +281,12 @@
if (ps2dev->flags & PS2_FLAG_CMD1) {
ps2dev->flags &= ~PS2_FLAG_CMD1;
if (ps2dev->cmdcnt)
-   wake_up_interruptible(>wait);
+   wake_up(>wait);
}
 
if (!ps2dev->cmdcnt) {
ps2dev->flags &= ~PS2_FLAG_CMD;
-   wake_up_interruptible(>wait);
+   wake_up(>wait);
}
 
return 1;
@@ -298,7 +298,7 @@
ps2dev->nak = 1;
 
if (ps2dev->flags & (PS2_FLAG_ACK | PS2_FLAG_CMD))
-   wake_up_interruptible(>wait);
+   wake_up(>wait);
 
ps2dev->flags = 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: Adding an async I2C interface

[Bukie Mabayoje]

> I will be glad to work with on this,  I have some exposure to the BMC. See 
> text below in blue.
>
> bukie
>
> Corey Minyard wrote:
>
>> Mark Studebaker wrote:
>>
>> > is there a way to do this solely in i2c-core without having to
>> > add support to all the drivers?
>>
>> Yes and no.  In order to support this async operation, the driver cannot
>> block and do things like msleep() or schedule().
>
> The Interface driver must be a user space driver.
>
>> It has to start the
>> operation, return, and either let polling or an interrupt drive the
>> continued operation.  Thus for async operations the driver has to be
>> modified.  However, if async operation is not required, the driver can
>> stay as is.
>>
>> I've been working on this and will probably have a patch tomorrow.  I've
>> modified the piix4 and the i801 drivers, I probably won't do any more
>> myself unless the need arises, since I can't test any others.  Note that
>> this still supports the old driver interface, so no drivers need to be
>> rewritten.  That way, they only need to be modified if something needs
>> the async interface.  So drivers that have an RTC on them or that
>> support IPMI BMCs could be rewritten, but nothing else needs to be done.
>>
>> I've also noticed a somewhat cavalier attitude in this code with respect
>> to return values.  I've cleaned some of that up so return values are not
>> just -1 on error, but are proper errno values.  However, I've only fixed
>> the core code and the drivers I've worked on.
>>
>> Thanks,
>>
>> -Corey
>>
>> >
>> > Corey Minyard wrote:
>> >
>> >> I have an IPMI interface driver that sits on top of the I2C code.  I'd
>> >> like to get it into the mainstream kernel, but I have a few problems
>> >> to solve first before I can do that.  The I2C code is synchronous and
>> >> must run from a task context.
>
> I am not sure what you mean that the I2C code is synchronous. I2C bus is 
> Asynchronous which means that the data clock is not included in the data. The 
> Sender and Receiver agrees on the timing parameters prior to the bus 
> transaction.
>
>> The IPMI driver has certain
>> >> operations that occur at panic time, including:
>> >>
>> >>   * Storing panic information in IPMI's system event log
>> >>   * Extending the watchdog timer so it doesn't go off during panic
>> >> operations (like kernel coredumps).
>> >>   * Powering the system off
>> >>
>
> Is this driver compliant with the IPMI spec? Because the above should be a 
> sensor that must be enable or disable. A driver should not make sure a 
> decision by itself.
>
>>
>> >> I can't really put the IPMI SMB interface into the kernel until I can
>> >> do those operations.  Also, I understand that some vendors put RTC
>> >> chips onto the I2C bus and this must be accessed outside task context,
>> >> too.
>
> What the vendor put on the board doesn't matter with respect to IPMI. What 
> matter is that you have access to the Master where the slave you talking to 
> is connect on the I2C bus.
>
>> I would really like add asynchronous interface to the I2C bus
>> >> drivers.
>
> Do you mean a  blocking and non blocking I/O?
>
>> I propose:
>> >>
>> >>   * Adding an async send interface to the busses that does a callback
>> >> when the operation is complete.
>
> Okay, you are doing a non-blocking I/O. So what happens when another process 
> tries to access the I2C bus before the bus transaction is completed. Some 
> thing (mainly the app) needs to tell the driver not to share the resource 
> while a transaction is in progress.
>
>>
>> >>   * Adding a poll interface to the busses.  The I2C core code could
>> >> call this if a synchronous call is made from task context (much
>> >> like all the current drivers do right now).  For asyncronous
>> >> operation, the I2C core code would call it from a timer
>> >> interrupt.  If the driver supported interrupts, polling from the
>> >> timer interrupt would not be necessary.
>
> I think this should be done in the Interface code because the Interface code 
> will be running in the user space and have access to the operating system 
> facility.
>
>>
>> >>   * Add async operations for the user to call, including access to the
>> >> polling code.
>
> The driver can make itself blocking  and non blocking
>
>>
>> >>   * If the driver didn't support an async send, it would work as it
>> >> does today and the async calls would return ENOSYS.
>
> Not needed, it will be addressed by the blocking and non-block implementation 
> of the driver.
>
>>
>> >>
>> >> This way, the bus drivers on I2C could be converted on a
>> >> driver-by-driver basis.  The IPMI code could query to see if the
>> >> driver supported async operations.  And the RTC code could use it,
>> >> too.
>> >>
>> >> Is this ok with the I2C community?  I would do the base work and
>> >> convert over a few drivers.
>> >>
>> >> Thanks,
>> >>
>> >> -Corey
>> >>
>> >>
>>
>> -
>> To unsubscribe from this list: send the line 

Re: 2.6.10-mm1-V0.7.34-01 ACPI err in dmesg

[Ingo Molnar]

* Gene Heskett <[EMAIL PROTECTED]> wrote:

>   Normal zone: 225280 pages, LIFO batch:16
>   HighMem zone: 32752 pages, LIFO batch:7
> DMI 2.2 present.
> __iounmap: bad address c00f  <-why?
> ACPI: RSDP (v000 Nvidia) @ 0x000f7220

I have no idea what is causing this. If it still occurs with recent
kernels then stick a WARN_ON(1) into __iounmap()'s error path, to get a
stack dump? It is almost certainly not related to -RT.

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Really annoying bug in the mouse driver

[Dmitry Torokhov]

On Saturday 15 January 2005 08:16, Victor Hahn wrote:
> Jan 15 13:33:36 vic kernel: psmouse.c: bad data from KBC - bad parity
> Jan 15 13:33:38 vic kernel: psmouse.c: Wheel Mouse at 
> isa0060/serio1/input0 lost
>  synchronization, throwing 3 bytes away.
> 
> Sometimes, only one of these messages appears; the number of bytes in 
> the second message varies, but mostly it is 3.
> 

Hi,

Could you please try the patch below?

Thanks!

-- 
Dmitry

= psmouse-base.c 1.88 vs edited =
--- 1.88/drivers/input/mouse/psmouse-base.c 2005-01-27 02:13:43 -05:00
+++ edited/psmouse-base.c   2005-01-28 00:05:08 -05:00
@@ -154,9 +154,19 @@
flags & SERIO_TIMEOUT ? " timeout" : "",
flags & SERIO_PARITY ? " bad parity" : "");
ps2_cmd_aborted(>ps2dev);
+   if (psmouse->resend || serio_write(serio, PSMOUSE_CMD_RESEND)) {
+   psmouse->resend = 0;
+   psmouse->state = PSMOUSE_IGNORE;
+   serio_reconnect(serio);
+   } else {
+   psmouse->pktcnt = 0;
+   psmouse->resend = 1;
+   }
goto out;
}
 
+   psmouse->resend = 0;
+
if (unlikely(psmouse->ps2dev.flags & PS2_FLAG_ACK))
if  (ps2_handle_ack(>ps2dev, data))
goto out;
@@ -173,6 +183,10 @@
printk(KERN_WARNING "psmouse.c: %s at %s lost synchronization, 
throwing %d bytes away.\n",
   psmouse->name, psmouse->phys, psmouse->pktcnt);
psmouse->pktcnt = 0;
+   if (serio_write(serio, PSMOUSE_CMD_RESEND) == 0) {
+   psmouse->resend = 1;
+   psmouse->last = jiffies;
+   }
}
 
psmouse->last = jiffies;
= psmouse.h 1.25 vs edited =
--- 1.25/drivers/input/mouse/psmouse.h  2004-10-16 06:15:31 -05:00
+++ edited/psmouse.h2005-01-28 00:04:47 -05:00
@@ -13,6 +13,7 @@
 #define PSMOUSE_CMD_ENABLE 0x00f4
 #define PSMOUSE_CMD_DISABLE0x00f5
 #define PSMOUSE_CMD_RESET_DIS  0x00f6
+#define PSMOUSE_CMD_RESEND 0x00fe
 #define PSMOUSE_CMD_RESET_BAT  0x02ff
 
 #define PSMOUSE_RET_BAT0xaa
@@ -45,6 +46,7 @@
unsigned char pktsize;
unsigned char type;
unsigned char model;
+   unsigned char resend;
unsigned long last;
unsigned long out_of_sync;
enum psmouse_state state;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/sata write barrier support

[Jens Axboe]

On Thu, Jan 27 2005, Doug Maxey wrote:
> 
> On Thu, 27 Jan 2005 13:02:48 +0100, Jens Axboe wrote:
> >Hi,
> >
> >For the longest time, only the old PATA drivers supported barrier writes
> >with journalled file systems. This patch adds support for the same type
> >of cache flushing barriers that PATA uses for SCSI, to be utilized with
> >libata. 
> 
> What, if any mechanism supports changing the underlying write cache?  
> 
> That is, assuming this is common across PATA and SCSI drives, and it is 
> possible to turn the cache off on the IDE drives, would switching the 
> cache underneath require completing the inflight IO?

Not sure what you mean, switching it off while the io is in flight? You
cannot do that, either the cache state will change right before starting
the io or right after. The cache state at the start of the barrier write
will determine the action taken.

-- 
Jens Axboe

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

Re: [PATCH] scsi/sata write barrier support

[Jens Axboe]

On Thu, Jan 27 2005, Jeff Garzik wrote:
> Doug Maxey wrote:
> >On Thu, 27 Jan 2005 13:02:48 +0100, Jens Axboe wrote:
> >
> >>Hi,
> >>
> >>For the longest time, only the old PATA drivers supported barrier writes
> >>with journalled file systems. This patch adds support for the same type
> >>of cache flushing barriers that PATA uses for SCSI, to be utilized with
> >>libata. 
> >
> >
> >What, if any mechanism supports changing the underlying write cache?  
> >
> >That is, assuming this is common across PATA and SCSI drives, and it is 
> >possible to turn the cache off on the IDE drives, would switching the 
> >cache underneath require completing the inflight IO?
> 
> [ignoring your question, but it made me think...]
> 
> 
> I am thinking the barrier support should know if the write cache is 
> disabled (some datacenters do this), and avoid flushing if so?

Ehm it does, read the code :)

-- 
Jens Axboe

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

Re: Bug in 2.4.26 in mm/filemap.c when using RLIMIT_RSS

[Ake]

On Fri, Jan 28, 2005 at 03:09:40PM +, Hugh Dickins wrote:
> > > BTW do you know if there is any plans for 2.6++ to actually use
> > > RLIMIT_RSS? I saw a hint in that direction in mm/thrash.c
> > > grab_swap_token but it is commented out and only skeleton code...
> > 
> > Nope, RLIMIT_RSS does not seem to be used at all in v2.6:
> > 
> > Its there for compatibility reasons, support for it might be added
> > in the future?
> 
> Rik had a patch implementing RLIMIT_RSS in 2.6-mm for a while.
> But I think there were a couple of problems with it, and no great
> demand for the feature, so Andrew dropped it until someone makes
> a better case for it.

Well, the use for it is for compute clusters where you really would like
to be able to limit this. Esp on smp boxes where there is multiple
compute jobs running simultaneously. Be it mpi or separate jobs you
really want to limit their RSS use so they don't steal memory from each
other.

-- 
Ake Sandgren, HPC2N, Umea University, S-90187 Umea, Sweden
Internet: [EMAIL PROTECTED] Phone: +46 90 7866134 Fax: +46 90 7866126
Mobile: +46 70 7716134 WWW: http://www.hpc2n.umu.se
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] sched: RLIMIT_RT_CPU_RATIO feature

[Ingo Molnar]

* Nick Piggin <[EMAIL PROTECTED]> wrote:

> But the important elements are lost. The standard provides a
> deterministic scheduling order, and a deterministic scheduling latency
> (of course this doesn't mean a great deal for Linux, but I think we're
> good enough for a lot of soft-rt applications now).
> 
> >  [1] http://www.opengroup.org/onlinepubs/007908799/xsh/realtime.html

no, the patch does not break POSIX. POSIX compliance means that there is
an environment that meets POSIX. Any default install of Linux 'breaks'
POSIX in a dozen ways, you have to take a number of steps to get a
strict, pristine POSIX environment. The only thing that changes is that
now you have to add "set RT_CPU ulimit to 0 or 100" to that (long) list
of things.

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: i8042 access timings

[Jaco Kroon]

Linus Torvalds wrote:
>
> On Fri, 28 Jan 2005, Jaco Kroon wrote:
>
ok, how would I try this?  Where can I find an example to code it 
from?
 Sorry, I should probably be grepping ...
>>>
>>>If the udelay() didn't work, then this one isn't worth worryign about
>>>either. Back to the drawing board.
>>
>>Yea.  But for interrests sake, what do you mean with a serializing IO
>>instruction?
> If you use "outb_p()" instead of an "outb()", the regular IO instruction
> will be followed by another out to another port on the motherboard: that
> will not only cause a delay, it should also force at least the host 
bridge
> to have no outstanding posted writes (the host bridge shouldn't post IO
> port writes anyway, but hey, it won't hurt to try to make even more sure
> of that).

No go.  Does not help at all.  Very nifty idea to force another 
character through the bus to cause a delay though.

>>I also tried increasing the total timeout value to about 5 seconds
>>(versus the default half second), still no success, so the device is
>>simply not sending back the requested values.
>
>
> If it was the other way around (that it works with ACPI _on_), I'd 
assume
> that ACPI just disables some broken BIOS SMM emulation code. But I just
> don't see ACPI _enabling_ SMM emulation. That would be just too strange,
> and against the whole point of the legacy keyboard emulation stuff - you
> want to do legacy keyboard emulation if the OS is old, not if it's new.

I don't see this notebook running any non-ACPI enabled OS.  It would 
just be too broken (consider the black screen of void if one boots with 
acpi=off).  Some very old legacy OSs would not even have USB1.1 support 
which will kill the keyboard.

>
> It may be that ACPI ends up enabling some silly power control SMM 
sequence
> that wakes up on keyboard accesses, and screws up the emulation. That
> sounds pretty strange too, I have to say - even if SMM/ACPI would like to
> trap keyboard command sequences, I'd have expected it to just pass them
> through after looking at them.

Why?  If it is going to make the screen dimmer/brighter after pressing 
the keys - what is the use of passing them through to the OS?  After 
all, the user has already seen the "effect" these keys caused and giving 
them to the OS to do something else with will end up being counter 
intuitive to the user.
>
> One option may be that SMM/ACPI traps the _received_ characters, and
> incorrectly eats the reply, because it thinks it's some special key
> sequence (and should cause SMM/ACPI to make the screen brighter or
> something silly like that).

Interresting idea.  The Fn+F6/F7 keys does indeed make the screen 
brighter and dimmer, and afaik these gets trapped by SMM/ACPI in the 
BIOS and never even gets to Linux.

> Does anybody know/remember what the keycode 0xA5 means?
>>I still stand with the theory that it is sending back the value we want
>>for the first request on the second one (managed to get this one by
>>explicitly turning i8042_debug on and off in the code):
>>
>>i8042_init()
>>ACPI: PS/2 Keyboard Controller [KBC0] at I/O 0x60, 0x64, irq 1
>>ACPI: PS/2 Mouse Controller [MSE0] at irq 12
>>i8042_controller_init()
>>i8042_flush()
>>drivers/input/serio/i8042.c: 20 -> i8042 (command) [4]
>>drivers/input/serio/i8042.c: 47 <- i8042 (return) [4]
>>drivers/input/serio/i8042.c: 60 -> i8042 (command) [5]
>>drivers/input/serio/i8042.c: 56 -> i8042 (parameter) [5]
>>i8042_check_aux()
>>drivers/input/serio/i8042.c: Interrupt 12, without any data [9]
>>i8042_flush()
>>drivers/input/serio/i8042.c: d3 -> i8042 (command) [13]
>>drivers/input/serio/i8042.c: 5a -> i8042 (parameter) [13]
>>drivers/input/serio/i8042.c:  -- i8042 (timeout) [875]
>>i8042_check_aux: param_in=0x5a, command=AUX_LOOP, param_out=5a <= -1
>>drivers/input/serio/i8042.c: a9 -> i8042 (command) [879]
>>drivers/input/serio/i8042.c: a5 <- i8042 (return) [879]
>>i8042_check_aux: param_in=??, command=AUX_TEST, param_out=a5 <= 0
>>
>>I've rebooted a couple of times and that interrupt is in exactly the
>>same place every time.  And int 12 is indeed the AUX device, could this
>>be a clue?
>
> Does it change if you change the initial value of "param" (0x5a) to
> something else?
I've changed the initial input to 0xbb and the output from the second 
command changed to 0x44.  So it does indeed look like my theory might be 
workable.  Just a thought, the acpi_driver i8042_acpi_aux_driver struct 
has an .add option, that gets called when ACPI detects the AUX device. 
ic8042_acpi_aux_add() gets called *before* we attempt 
initialisation/detectiong of the device.  Shouln't this be sufficient to 
say yes, there is such a device, this is it's port and irq numbers?  As 
such, do we still need to go through the AUX_LOOP and AUX_TEST process 
to determine whether the device is installed or not?  On the other hand, 
why would asking ACPI what the correct interrupt is break it?

In i8042_platform_init() (i8042-x86ia64io.h) there is a commented 

Re: [patch, 2.6.10-rc2] sched: fix ->nr_uninterruptible handling bugs

[Andi Kleen]

Ingo Molnar <[EMAIL PROTECTED]> writes:
>
> interestingly, the x86 spinlock implementation uses a LOCK-ed
> instruction only on acquire - it uses a simple atomic write (and
> implicit barrier assumption) on the way out:
>
>  #define spin_unlock_string \
>  "movb $1,%0" \
>  :"=m" (lock->slock) : : "memory"
>
> no LOCK prefix. Due to this spinlocks can sometimes be _cheaper_ than
> doing the same via atomic inc/dec.

Unfortunately kernels are often compiled for PPro and on those
an LOCK prefix is used anyways to work around some bugs in early 
steppings. This makes spinlocks considerably slower (there are some
lock intensive not even so micro benchmarks that show the difference clearly)

It uses then

#define spin_unlock_string \
"xchgb %b0, %1" \
:"=q" (oldval), "=m" (lock->lock) \
:"0" (oldval) : "memory"


which has an implicit LOCK and is equally slow.

I looked some time ago at patching it at runtime using alternative(),
but it would have bloated the patch tables a lot. Another way would
be a CONFIG_PPRO_BUT_UP_ON_BUGGY_ONES, but it is hard to find the exact
steppings with the problems.

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

Re: Patch 4/6 randomize the stack pointer

[Ingo Molnar]

* Jirka Kosina <[EMAIL PROTECTED]> wrote:

> Also, besides security implications of stack randomization, there is
> one more aspect that should not be forgotten - stack randomization
> (even for quite small range) could be useful to distribute a pressure
> on cache (which may not be fully associative in all cases), so if
> everyone runs with stack on the same address, it could impose quite
> noticeable stress on some cachelines (those representing stack
> addresses), while other will be idling unused.
> 
> I thought that this was the original purpose of the "stack
> randomization" which is shipped for example by RedHat kernels, as the
> randomization is quite small and easy to bruteforce, so it can't serve
> too much as a buffer overflow protection.

Fedora kernels have 2MB of stack randomization. If 2MB is easy to
brute-force then 256MB is easy to brute-force nearly as much. But the
difference between _zero_ randomisation and 2MB randomisation is much
bigger than the difference between 2MB and 256MB of randomisation.

example: if there is no randomisation and e.g. there's an up to 100
bytes buffer-overflow in a UDP based service, then a single-packet
remote attack may become possible, and an automated worm has an easy
'vector to spread'. (worms these days are mainly limited by bandwidth,
so the number of packets it needs to spread is crutial. Also,
detection/prevention of a worm is easier if the attacker has to send
multiple packets in a row.)

some quick calculations about how the economics of attack look like if
there is randomisation in place:

If the hole has a possibility to inject a 'padding invariant' into the
attack (either NOPs into the shell code, so that a jump address can be
'fuzzy', or e.g. "././././" padding into a pathname/URL attack string),
so that the attack can use a 'fuzzy' address accurate only to the size
of padding, then the brute-forcing can be reduced to ~2MB/100bytes==20
thousand tries. If there is randomisation then a single-packet remote
attack needs to become a ~20-thousand packets brute-force attack. The
box is by no means in the clear against attacks, but worms become
uneconomic.

if the attack needs a specific address (or offset) to the stack and
there is no invariant then 2MB of of randomisation requires 2 million
tries to do the brute-force-attack.

with 256MB of randomisation and the possibility of an invariant, the
same attack would become a 2 million packets brute-force attack. A site
that didnt notice a 10-thousand packets attack probably wont notice a 2
million packets attack either. Plus the site is still vulnerable: 2
million packets (which with a 100 bytes attack size takes ~20 minutes
over broadband) and it's gone.

with no invariant and 256 million packets needed for an attack, it will
take over a day (over broadband) to brute-force a box - and security
purists would still consider the box vulnerable.

conclusion: stack randomisation (and other VM randomisations) are not a
tool against local attacks (which are much easier and faster to
brute-force) or against targeted remote attacks, but mainly a tool to
degrade the economy of automated remote attacks.

256 MB of stack randomisation negatively impacts the VM layout and
creates all sorts of problems, so it's really impractical. If your only
goal is to maximize security, then clearly, the more randomisation, the
better. If you have other goals as well (e.g. my goal is to make
security as painless as possible, so that _other_ people who dont
usually care about security end up using our stuff too) then you will
settle for somewhere inbetween. We started with 8MB in Fedora but that
already caused some problems so we decreased it to 2MB and that worked
pretty well on 32-bit systems. 64K is probably too low but is still a
good start and much better than nothing.

Note that 64-bit systems are different, there we can do a pretty good
grade of randomisation as VM space is plenty.

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: don't let mmap allocate down to zero

[William Lee Irwin III]

On Thu, 27 Jan 2005, William Lee Irwin III wrote:
>> The intention was to disallow vmas starting at 0 categorically. i.e. it
>> is very intentional to deny the MREMAP_FIXED to 0 case of mremap().
>> It was also the intention to deny the MAP_FIXED to 0 case of mmap(),
>> though I didn't actually sweep that much (if at all).

On Thu, Jan 27, 2005 at 04:28:19PM -0500, Rik van Riel wrote:
> We can't do that, look at line 944 of fs/binfmt_elf.c:
> if (current->personality & MMAP_PAGE_ZERO) {
> /* Why this, you ask???  Well SVr4 maps page 0 as read-only,
>and some applications "depend" upon this behavior.
>Since we do not have the power to recompile these, we
>emulate the SVr4 behavior.  Sigh.  */
> down_write(>mm->mmap_sem);
> error = do_mmap(NULL, 0, PAGE_SIZE, PROT_READ | PROT_EXEC,
> MAP_FIXED | MAP_PRIVATE, 0);
> up_write(>mm->mmap_sem);
> }

You seem to be on about something else, e.g. only forbidding the vma
allocator to return a vma starting at 0 when not specifically requested.
In that case vma->vm_start < mm->brk and similar are all fine.


-- wli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: crypto algoritms failing?

[Nigel Cunningham]

Hi.

On Fri, 2005-01-28 at 13:25, James Morris wrote:
> On Fri, 28 Jan 2005, Nigel Cunningham wrote:
> 
> > You normally test cryptoapi functionality while booting?
> 
> This happens if you link tcrypt statically into the kernel.

Yes, but why would you? Oh well. Doesn't matter ;>

Nigel
-- 
Nigel Cunningham
Software Engineer
Cyclades Corporation

http://cyclades.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: [ANN] removal of certain net drivers coming soon: eepro100, xircom_tulip_cb, iph5526

[David S. Miller]

On Thu, 27 Jan 2005 17:58:37 -0800
Scott Feldman <[EMAIL PROTECTED]> wrote:

> eepro100 does a copy if pkt_len < rx_copybreak, otherwise it send up the
> skb and allocates and links a new one in it's place (see
> speedo_rx_link).

My bad, you're right.  So I wonder too what the difference
is that makes it work on ARM et al.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.10-rc2] sched: fix ->nr_uninterruptible handling bugs

[Paul Jackson]

Ingo wrote:
> if by 'some CPUs' you mean x86 then it's the LOCK prefixed ops ...

Yup - that's the one.  Thanks.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Advice sought on how to lock multiple pages in ->prepare_write and ->writepage

[Nathan Scott]

Hi Anton,

On Thu, Jan 27, 2005 at 04:58:22PM -0800, Andrew Morton wrote:
> Anton Altaparmakov <[EMAIL PROTECTED]> wrote:
> >
> > What would you propose can I do to perform the required zeroing in a
> > deadlock safe manner whilst also ensuring that it cannot happen that a
> > concurrent ->readpage() will cause me to miss a page and thus end up
> > with non-initialized/random data on disk for that page?
> 
> The only thing I can think of is to lock all the pages.  There's no other
> place in the kernel above you which locks multiple pagecache pages, but we
> can certainly adopt the convention that multiple-page-locking must proceed
> in ascending file offset order.
> 
> ...
> 
> Not very pretty though.
> 

Just putting up my hand to say "yeah, us too" - we could also make
use of that functionality, so we can grok existing XFS filesystems
that have blocksizes larger than the page size.

Were you looking at using an i_blkbits value larger than pageshift,
Anton?  There's many places where generic code does 1 << i_blkbits
that'll need careful auditing, I think.  A lock-in-page-index-order
approach seems the simplest way to prevent page deadlocks as Andrew
suggested, and always starting to lock pages at the lowest block-
aligned file offset (rather than taking a page lock, dropping it,
locking earlier pages, reaquiring the later one, etc) - that can't
really be done inside the filesystems though..

So it's probably something that should be handled in generic page
cache code such that the locking is done in common places for all
filesystems using large i_blkbits values, and such that locking is
done before the filesystem-specific read/writepage(s) routines are
called, so that they don't have to be changed to do page locking
any differently.

cheers.

-- 
Nathan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Adding an async I2C interface

[Corey Minyard]

Mark Studebaker wrote:
is there a way to do this solely in i2c-core without having to
add support to all the drivers?
Yes and no.  In order to support this async operation, the driver cannot 
block and do things like msleep() or schedule().  It has to start the 
operation, return, and either let polling or an interrupt drive the 
continued operation.  Thus for async operations the driver has to be 
modified.  However, if async operation is not required, the driver can 
stay as is.

I've been working on this and will probably have a patch tomorrow.  I've 
modified the piix4 and the i801 drivers, I probably won't do any more 
myself unless the need arises, since I can't test any others.  Note that 
this still supports the old driver interface, so no drivers need to be 
rewritten.  That way, they only need to be modified if something needs 
the async interface.  So drivers that have an RTC on them or that 
support IPMI BMCs could be rewritten, but nothing else needs to be done.

I've also noticed a somewhat cavalier attitude in this code with respect 
to return values.  I've cleaned some of that up so return values are not 
just -1 on error, but are proper errno values.  However, I've only fixed 
the core code and the drivers I've worked on.

Thanks,
-Corey
Corey Minyard wrote:
I have an IPMI interface driver that sits on top of the I2C code.  I'd
like to get it into the mainstream kernel, but I have a few problems
to solve first before I can do that.  The I2C code is synchronous and
must run from a task context.  The IPMI driver has certain
operations that occur at panic time, including:
  * Storing panic information in IPMI's system event log
  * Extending the watchdog timer so it doesn't go off during panic
operations (like kernel coredumps).
  * Powering the system off
I can't really put the IPMI SMB interface into the kernel until I can
do those operations.  Also, I understand that some vendors put RTC
chips onto the I2C bus and this must be accessed outside task context,
too.  I would really like add asynchronous interface to the I2C bus
drivers.  I propose:
  * Adding an async send interface to the busses that does a callback
when the operation is complete.
  * Adding a poll interface to the busses.  The I2C core code could
call this if a synchronous call is made from task context (much
like all the current drivers do right now).  For asyncronous
operation, the I2C core code would call it from a timer
interrupt.  If the driver supported interrupts, polling from the
timer interrupt would not be necessary.
  * Add async operations for the user to call, including access to the
polling code.
  * If the driver didn't support an async send, it would work as it
does today and the async calls would return ENOSYS.
This way, the bus drivers on I2C could be converted on a
driver-by-driver basis.  The IPMI code could query to see if the
driver supported async operations.  And the RTC code could use it,
too.
Is this ok with the I2C community?  I would do the base work and
convert over a few drivers.
Thanks,
-Corey

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: High resolution timers and BH processing on -RT

[Ingo Molnar]

* Thomas Gleixner <[EMAIL PROTECTED]> wrote:

> Some numbers to make this more transparent.
> 
> Machine: PIII Celeron 333MHz
> RT - T0: 1ms cyclic
> RT - T1: 2ms cyclic
> 
> 
> Load average is ~4.0 for all tests. The numbers are maximum deviation
> from the timeline in microseconds. Test time was ~60 minutes for each
> szenario.
> 
> Running all timers in high resolution mode (ksoftirqd) results in:
> [T0  Prio:  60]  2123
> [T1  Prio:  59]  2556
> [T2  Prio:  58]  2882
> [T3  Prio:  57]  2993
> [T4  Prio:  56]  2888
> 
> Running all timers in high resolution mode (seperated timer softirqd
> PRIO=70) results in:
> [T0  Prio:  60]  423
> [T1  Prio:  59]  372
> [T2  Prio:  58]  756
> [T3  Prio:  57]  802
> [T4  Prio:  56]  1208

is this due to algorithmic/PIT-programming overhead, or due to the noise
introduced by other, non-hard-RT timers? I'd guess the later from the
looks of it, but did your test introduce such noise (via networking and
application workloads?).

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] to fix xtime lock for in the RT kernel patch

[Ingo Molnar]

* George Anzinger  wrote:

> Ingo, I have been looking at the code being proposed by John Stultz. 
> It looks like it handles all the issues I am talking about here.  I
> think it would be best to leave the RT patch as it is WRT this issue
> and work on getting John's patch ready for prime time as any work I
> would do here will just get tossed when his patch hits the steet.
> 
> Meanwhile, I will (already have) get HRT working on RT and make that
> available in the next few days.

sure, fine with me. You might want to sync up with Thomas Gleixner,
who's working on some of the HRT issues too.

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.10-rc2] sched: fix ->nr_uninterruptible handling bugs

[Ingo Molnar]

* Paul Jackson <[EMAIL PROTECTED]> wrote:

> A long time ago, Linus wrote:
> > An atomic op is pretty much as expensive as a spinlock/unlock pair on x86.  
> > Not _quite_, but it's pretty close.
> 
> Are both read and modify atomic ops relatively expensive on some CPUs,
> or is it just modify atomic ops?
> 
> (Ignoring for this question the possibility that a mix of read and
> modify ops could heat up a cache line on multiprocessor systems, and
> focusing for the moment just on the CPU internals ...)

if by 'some CPUs' you mean x86 then it's the LOCK prefixed ops that are
expensive. I.e. all the LOCK-prefixed RMW variants of instructions:

 atomic.h:   LOCK "addl %1,%0"
 atomic.h:   LOCK "subl %1,%0"
 atomic.h:   LOCK "subl %2,%0; sete %1"
 atomic.h:   LOCK "incl %0"
 atomic.h:   LOCK "decl %0"
 atomic.h:   LOCK "decl %0; sete %1"
 atomic.h:   LOCK "incl %0; sete %1"
 atomic.h:   LOCK "addl %2,%0; sets %1"
 atomic.h:   LOCK "xaddl %0, %1;"
 atomic.h:__asm__ __volatile__(LOCK "andl %0,%1" \
 atomic.h:__asm__ __volatile__(LOCK "orl %0,%1" \

pure reads/writes are architecturally guaranteed to be atomic (so
atomic.h uses them, not some fancy instruction) and they are (/better
be) fast.

interestingly, the x86 spinlock implementation uses a LOCK-ed
instruction only on acquire - it uses a simple atomic write (and
implicit barrier assumption) on the way out:

 #define spin_unlock_string \
 "movb $1,%0" \
 :"=m" (lock->slock) : : "memory"

no LOCK prefix. Due to this spinlocks can sometimes be _cheaper_ than
doing the same via atomic inc/dec.

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: AT-Keyboard probing too strict in current bk?

[Dmitry Torokhov]

On Thursday 27 January 2005 11:47, Michael Gernoth wrote:
> Hi,
> 
> since the introduction of libps2 in the mainline 2.6 kernel I had the
> issue that my keyboard[1] was no longer recognized.
> The cause of this is that my "keyboard" responds to all commands with
> an acknowledgement (0xFA), even if the command is not implemented. One
> of those not implemented commands is 0xF2 (ATKBD_GETID_CMD).
> 
> In drivers/input/keyboard/atkbd.c ATKBD_GETID_CMD is used to probe
> for the keyboard, and if this fails, another method of detecting
> the keyboard is used. It seems that in 2.6.10 atkbd_command
> indicated that my keyboard did not successfully execute the command,
> but in the current bk-version ps2_command is used, which indicates
> a successfull execution, leaving behind invalid keyboard-ids.
> This leads to the kernel ignoring my keyboard.
> 

Hi, 

Thanks for noticing this. The following patch should fix timeout
handling in libps2 and restore previous behavior:


= drivers/input/serio/libps2.c 1.4 vs edited =
--- 1.4/drivers/input/serio/libps2.c2005-01-27 02:13:43 -05:00
+++ edited/drivers/input/serio/libps2.c 2005-01-27 22:52:36 -05:00
@@ -115,8 +115,8 @@
 */
timeout = msecs_to_jiffies(command == PS2_CMD_RESET_BAT ? 4000 : 500);
 
-   wait_event_interruptible_timeout(ps2dev->wait,
-   !(ps2dev->flags & PS2_FLAG_CMD1), timeout);
+   timeout = wait_event_interruptible_timeout(ps2dev->wait,
+   !(ps2dev->flags & PS2_FLAG_CMD1), timeout);
 
if (ps2dev->cmdcnt && timeout > 0) {
 


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

[patch] net/tulip: Modify a bug for ULi M526X(kernel 2.6.10)

[Clear . Zhang]

Hi, Jeff

There is a bug about ULi M526X. It cannot deal with the dummy descriptor.

For example:
Des0:0x8000
Des1:0
Des2:0
Des3:pointer to next descriptor

This patch is applied to kernel 2.6.10. Please apply to new kernels. Thanks
a lot.

Signed-off-by: Clear Zhang <[EMAIL PROTECTED]>


BRs,
Clear


diff -uprN linux-2.6.10-vanilla/drivers/net/tulip/media.c
linux-2.6.10/drivers/net/tulip/media.c
--- linux-2.6.10-vanilla/drivers/net/tulip/media.c2004-12-25
05:34:27.0 +0800
+++ linux-2.6.10/drivers/net/tulip/media.c  2005-01-28
10:57:13.0 +0800
@@ -81,6 +81,25 @@ int tulip_mdio_read(struct net_device *d
return retval & 0x;
  }

+ if(tp->chip_id == ULI526X && tp->revision >= 0x40) {
+   int value;
+   int i = 1000;
+
+   value = ioread32(ioaddr + CSR9);
+   iowrite32(value & 0xFFEF, ioaddr + CSR9);
+
+   value = (phy_id << 21) | (location << 16) | 0x800;
+   iowrite32(value, ioaddr + CSR10);
+
+   while(--i > 0) {
+ mdio_delay();
+ if(ioread32(ioaddr + CSR10) & 0x1000)
+   break;
+   }
+   retval = ioread32(ioaddr + CSR10);
+   spin_unlock_irqrestore(>mii_lock, flags);
+   return retval & 0x;
+ }
  /* Establish sync by sending at least 32 logic ones. */
  for (i = 32; i >= 0; i--) {
iowrite32(MDIO_ENB | MDIO_DATA_WRITE1, mdio_addr);
@@ -140,7 +159,24 @@ void tulip_mdio_write(struct net_device
spin_unlock_irqrestore(>mii_lock, flags);
return;
  }
-
+
+ if (tp->chip_id == ULI526X && tp->revision >= 0x40) {
+   int value;
+   int i = 1000;
+
+   value = ioread32(ioaddr + CSR9);
+   iowrite32(value & 0xFFEF, ioaddr + CSR9);
+
+   value = (phy_id << 21) | (location << 16) | 0x400 | (val &
0x);
+   iowrite32(value, ioaddr + CSR10);
+
+   while(--i > 0) {
+ if (ioread32(ioaddr + CSR10) & 0x1000)
+   break;
+   }
+   spin_unlock_irqrestore(>mii_lock, flags);
+ }
+
  /* Establish sync by sending 32 logic ones. */
  for (i = 32; i >= 0; i--) {
iowrite32(MDIO_ENB | MDIO_DATA_WRITE1, mdio_addr);
diff -uprN linux-2.6.10-vanilla/drivers/net/tulip/timer.c
linux-2.6.10/drivers/net/tulip/timer.c
--- linux-2.6.10-vanilla/drivers/net/tulip/timer.c2004-12-25
05:33:47.0 +0800
+++ linux-2.6.10/drivers/net/tulip/timer.c  2005-01-28
10:57:14.0 +0800
@@ -39,6 +39,7 @@ void tulip_timer(unsigned long data)
  case MX98713:
  case COMPEX9881:
  case DM910X:
+ case ULI526X:
  default: {
struct medialeaf *mleaf;
unsigned char *p;
diff -uprN linux-2.6.10-vanilla/drivers/net/tulip/tulip_core.c
linux-2.6.10/drivers/net/tulip/tulip_core.c
--- linux-2.6.10-vanilla/drivers/net/tulip/tulip_core.c 2004-12-25
05:34:58.0 +0800
+++ linux-2.6.10/drivers/net/tulip/tulip_core.c 2005-01-28
10:57:14.0 +0800
@@ -197,6 +197,10 @@ struct tulip_chip_table tulip_tbl[] = {
   /* RS7112 */
   { "Conexant LANfinity", 256, 0x0001ebef,
  HAS_MII | HAS_ACPI, tulip_timer },
+
+  /* ULi526X */
+  { "ULi M5261/M5263", 128, 0x0001ebef,
+HAS_MII | HAS_MEDIA_TABLE | CSR12_IN_SROM | HAS_ACPI, tulip_timer
},
 };


@@ -233,7 +237,8 @@ static struct pci_device_id tulip_pci_tb
  { 0x1737, 0xAB09, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
  { 0x1737, 0xAB08, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
  { 0x17B3, 0xAB08, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
- { 0x10b9, 0x5261, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X },   /* ALi
1563 integrated ethernet */
+ { 0x10b9, 0x5261, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ULI526X },  /* ALi
1563 integrated ethernet */
+ { 0x10b9, 0x5263, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ULI526X },  /* ALi
1563 integrated ethernet */
  { 0x10b7, 0x9300, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET }, /* 3Com
3CSOHO100B-TX */
  { } /* terminate list */
 };
@@ -514,7 +519,7 @@ static void tulip_tx_timeout(struct net_
   dev->name);
  } else if (tp->chip_id == DC21140 || tp->chip_id == DC21142
 || tp->chip_id == MX98713 || tp->chip_id == COMPEX9881
-|| tp->chip_id == DM910X) {
+|| tp->chip_id == DM910X || tp->chip_id == ULI526X) {
printk(KERN_WARNING "%s: 21140 transmit timed out, status
%8.8x, "
 "SIA %8.8x %8.8x %8.8x %8.8x, resetting...\n",
 dev->name, ioread32(ioaddr + CSR5), ioread32(ioaddr +
CSR12),
@@ -1094,6 +1099,8 @@ static void set_rx_mode(struct net_devic

  entry = tp->cur_tx++ % TX_RING_SIZE;

+ if( !(tp->chip_id==ULI526X && (tp->revision == 0x40 ||
tp->revision == 0x50)) )
+ {
  if (entry != 0) {
/* Avoid a chip 

Re: Kernel OOPS with i915 DRM Driver - 2.6.10

[Dave Airlie]

your .config can't match that kernel...

all the debugging is from the i830 drm module, so somehow that is
getting loaded at some stage... if you are using X 6.8.0 you need the
i915 (like the config has...)

you might have an i830 module somewhere on your system that is getting loaded..

Dave.

> drm:i830_dma_initialize] *ERROR* can not find dma buffer map!
> [drm:i830_irq_emit] *ERROR* i830_irq_emit called without lock held
> Unable to handle kernel paging request at virtual address f000e829
>  printing eip:
> c02793c1
> *pde = 
> Oops:  [#1]
> PREEMPT SMP
> Modules linked in:
> CPU:1
> EIP:0060:[]Not tainted VLI
> EFLAGS: 00013296   (2.6.10-gentoo-r6)
> EIP is at i830_kernel_lost_context+0x11/0x70
> eax: f000e819   ebx:    ecx: 000c   edx: 3282
> esi: c05a99a0   edi:    ebp:    esp: db26fecc
> ds: 007b   es: 007b   ss: 0068
> Process X (pid: 8049, threadinfo=db26f000 task=de4d3020)
> Stack:  c027b4a7 c05a99a0 3282 c01270d7 c027bed0 c05a99a0 c027bedf
>c05a99a0 c0274fd4 c05a99a0 c05aa0d8 c05aa0e0   
> 0001 000a  de4d3020 c01187e0  
> Call Trace:
>  [] i830_dma_quiescent+0x17/0xb0
>  [] block_all_signals+0x37/0x80
>  [] i830_driver_dma_quiescent+0x0/0x20
>  [] i830_driver_dma_quiescent+0xf/0x20
>  [] i830_lock+0x264/0x310
>  [] default_wake_function+0x0/0x20
>  [] default_wake_function+0x0/0x20
>  [] dput+0x33/0x1d0
>  [] i830_ioctl+0xe5/0x160
>  [] fget+0x49/0x60
>  [] sys_ioctl+0xca/0x230
>  [] syscall_call+0x7/0xb
> Code: b9 8b 53 0c 01 d0 89 43 1c e9 60 ff ff ff 8d b6 00 00 00 00 8d
> bf 00 00 00 00 53 8b 44 24 08 8b 98 34 07 00 00 8b 43 04 8d 4b 0c <8b>
> 40 10 8b 90 34 20 00 00 81 e2 fc ff 1f 00 89 51 14 8b 43 04
> 
> # CONFIG_AGP_EFFICEON is not set
> CONFIG_DRM=y
> # CONFIG_DRM_TDFX is not set
> # CONFIG_DRM_R128 is not set
> # CONFIG_DRM_RADEON is not set
> # CONFIG_DRM_I810 is not set
> # CONFIG_DRM_I830 is not set
> CONFIG_DRM_I915=y
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Patch 4/6 randomize the stack pointer

[Horst von Brand]

Julien TINNES <[EMAIL PROTECTED]> said:
> Not very important but ((get_random_int() % 4096) << 4) could be 
> optimized into get_random_int() & 0xFFF0.

Check first if the compiler doesn't do it by itself.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: I need a hardware wizard... I have been beating my head on the wall..

[David Sims]

On Thu, 27 Jan 2005, Jeff Garzik wrote:

> David Sims wrote:
> > Hi,
> > 
> >   I have posted a couple of times in the past to no avail... I have an
> > Intel 31244 SATA controller that is supposed to work with the sata_vsc
> > driver module... It does in fact, almost
> > 
> >   You can insert the module in a running kernel and after barking as
> > follows (once for each disk attached) it runs just fine.
> 
> Basically nobody has ever had hardware to test sata_vsc with that 
> hardware.  We should probably remove the PCI ID until an engineer can 
> fix it...
> 
>   Jeff
> 
> 

Hi again,

  I am willing to make this hardware available to any engineer that wants
to help me solve this problem and I will do whatever I can to make it
an easy job... Please help me...

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/

Correct way to release get_user_pages()?

[Roland Dreier]

Reading through the tree, I see that some callers of get_user_pages()
release the pages that they got via put_page(), and some callers use
page_cache_release().  Of course  has

#define page_cache_release(page)  put_page(page)

so this is really not much of a difference, but I'd like to know which
is considered better style.  Any opinions?

Thanks,
  Roland

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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-rc2 TCP ignores PMTU ICMP (Re: Linux 2.6.11-rc2)

[Rusty Russell]

On Fri, 2005-01-28 at 02:33 +0100, Patrick McHardy wrote:
> David S. Miller wrote:
> 
> >I've forwarded this to netfilter-devel for inspection.
> >Thanks for collecting all the data points so well.
> >
> Here is the fix for everyone. Please report back if it doesn't
> solve the problem. Thanks.

Verified by nfsim (the ICMP tests used UDP, I've just added TCP and
ICMP, and will do SCTP).

Thanks,
Rusty.
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Applications segfault on evo n620c with 2.6.10

[hugang]

On Thu, Jan 27, 2005 at 07:43:34PM +0100, Pavel Machek wrote:
> Hi!
> 
> It happened for 3rd in a week now...
> 
> When problem happens, processes start to segfault, usually right
> during startup. Programs that were loaded prior to problem usualy
> works, and can be restarted. I also seen sendmail exec failing with
> "no such file or directory" when it clearly was there. Reboot corrects
> things, and filesystem (ext3) is not damaged.
> 
> Unfortunately I do not know how to reproduce it. I tried
> parallel-building kernels for few hours and that worked okay. Swsusp
> is not involved (but usb, bluetooth, acpi and sound may be).
> 
> Does anyone else see something similar?

I got the same thing in my computer. 

Maybe this can reproduce it.
 1: add this in boot loader 
"init=/bin/sh"
 2: after system boot, then active swap space, then do suspend.
 3: after system resume, the sh will crash like. 
that can 100% reproduce it my in X86, X86_64, PPC32.

The Software suspend2 has not that problem. 
 
-- 
Hu Gang   .-.
  /v\
 // \\ 
Linux User  /(   )\  [204016]
GPG Key ID   ^^-^^   http://soulinfo.com/~hugang/hugang.asc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Bug 4081] New: OpenOffice crashes while starting due to a threading error

[Trever L. Adams]

I didn't look at the trace. My only problem is in saving new files. I
can copy an old one, rename it and start, empty it and save fine. I just
can't save new ones.

Anyway, I hope this gets fixed. I am running pure rawhide Fedora Core,
just so you know... latest of everything.

Trever

On Thu, 2005-01-27 at 18:49 -0500, Parag Warudkar wrote:
>  From strace output which Trever sent, OO.o seems to be getting many 
> -EINTRs (Interrupted System Call) which are attempted to be restarted 
> but again recieve EINTR when restarted. (futex, accept and poll are the 
> ones which get EINTR).
> 
> Whereas, when OO.o successfully starts up on my machine, I get no EINTRs 
> at all.
> 
> Stephen - Is it possible for you to post strace from your machine ? If 
> you see the same symptoms we can look at what changed in that area.
> 
> Thanks
> Parag
> 
> Stephen Hemminger wrote:
> 
> >On my laptop with Fedora Core 3, OpenOffice 1.0.1, 1.0.4 and the pre 2.0 
> >version
> >all work fine running 2.6.10-FCxx kernel but get a SEGV when running on 
> >2.6.11-rc1 or 2.6.11-rc2
> >
> >Any hints?
> >
> >
> >  
> >
> 
> 
--
"There are two races of people - men and women - no matter what women's
libbers would have you pretend. The male is motivated by toys and
science because men are born with no purpose in the universe except to
procreate. there is lots of time to kill beyond that...Women, however,
are born with a center. They can create the universe, mother it, teach
it, nurture it. Men read science fiction to build the future. Women
don't need to read it. They are the future." -- Ray Bradbury

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: netdev-2.6 queue updated

[Jeff Garzik]

Andy Isaacson wrote:
On Thu, Jan 27, 2005 at 07:00:32PM -0500, Jeff Garzik wrote:
The attached changelog describes what I just pushed out to BitKeeper 
(and what should be appearing in the next -mm release from Andrew).

Note to BK users:  please re-clone netdev-2.6, don't just 'bk pull'.

It's much more efficient to do
% bk undo -a`bk repogca`

Well, by "re-clone" I mean recreate.  It's probably better to do what I 
do, clone the latest linux-2.5 repo and the pull netdev-2.6 into that. 
Far less messy than 'bk undo'.

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: crypto algoritms failing?

[James Morris]

On Fri, 28 Jan 2005, Nigel Cunningham wrote:

> You normally test cryptoapi functionality while booting?

This happens if you link tcrypt statically into the kernel.


- James
-- 
James Morris
<[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: netdev-2.6 queue updated

[Andy Isaacson]

On Thu, Jan 27, 2005 at 07:00:32PM -0500, Jeff Garzik wrote:
> The attached changelog describes what I just pushed out to BitKeeper 
> (and what should be appearing in the next -mm release from Andrew).
> 
> Note to BK users:  please re-clone netdev-2.6, don't just 'bk pull'.

It's much more efficient to do
% bk undo -a`bk repogca`
(which deletes everything in the local repo that's not in the parent)
rather than pulling the entire repo over the wire again. [1]

You can check what would be deleted by this command with "bk changes -L"
similar to how you can "bk changes -R" to figure out what would be
pulled.

[1] Well, actually, it isn't *quite* that simple; in certain cases,
repogca will delete more than it needs to.  But it's still more
efficient than a re-pull.

-andy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.10-rc2] sched: fix ->nr_uninterruptible handling bugs

[Paul Jackson]

True - thanks - including the part about the cost of locking bugs.

My question was poorly phrased - the code speaks the answer to the
real question I had:

  $ grep define.atomic_ include/asm-ia64/atomic.h | head -2
  #define atomic_read(v)  ((v)->counter)
  #define atomic_set(v,i) (((v)->counter) = (i))

An atomic_read() of a one word counter on ia64 is just a load, and an
atomic_set() is just a store.  This is unlike the more difficult
atomic_inc, atomic_dec, atomic_add, atomic_mutilate, ... calls that
require something fancier, and I presume more painful for that CPUs
innards.

Good.  Thanks.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Kernel OOPS with i915 DRM Driver - 2.6.10

[James Lamanna]

Noticed this oops today when setting up a box with a i865G chipset:
I'm using Xorg 6.8.0.
I also experience virtual terminal corruption when I switch to any of
them after X starts up.

Thanks.
-- James Lamanna

drm:i830_dma_initialize] *ERROR* can not find dma buffer map!
[drm:i830_irq_emit] *ERROR* i830_irq_emit called without lock held
Unable to handle kernel paging request at virtual address f000e829
 printing eip:
c02793c1
*pde = 
Oops:  [#1]
PREEMPT SMP
Modules linked in:
CPU:1
EIP:0060:[]Not tainted VLI
EFLAGS: 00013296   (2.6.10-gentoo-r6)
EIP is at i830_kernel_lost_context+0x11/0x70
eax: f000e819   ebx:    ecx: 000c   edx: 3282
esi: c05a99a0   edi:    ebp:    esp: db26fecc
ds: 007b   es: 007b   ss: 0068
Process X (pid: 8049, threadinfo=db26f000 task=de4d3020)
Stack:  c027b4a7 c05a99a0 3282 c01270d7 c027bed0 c05a99a0 c027bedf
   c05a99a0 c0274fd4 c05a99a0 c05aa0d8 c05aa0e0   
    0001 000a  de4d3020 c01187e0  
Call Trace:
 [] i830_dma_quiescent+0x17/0xb0
 [] block_all_signals+0x37/0x80
 [] i830_driver_dma_quiescent+0x0/0x20
 [] i830_driver_dma_quiescent+0xf/0x20
 [] i830_lock+0x264/0x310
 [] default_wake_function+0x0/0x20
 [] default_wake_function+0x0/0x20
 [] dput+0x33/0x1d0
 [] i830_ioctl+0xe5/0x160
 [] fget+0x49/0x60
 [] sys_ioctl+0xca/0x230
 [] syscall_call+0x7/0xb
Code: b9 8b 53 0c 01 d0 89 43 1c e9 60 ff ff ff 8d b6 00 00 00 00 8d
bf 00 00 00 00 53 8b 44 24 08 8b 98 34 07 00 00 8b 43 04 8d 4b 0c <8b>
40 10 8b 90 34 20 00 00 81 e2 fc ff 1f 00 89 51 14 8b 43 04

relevant parts of .config:

# Automatically generated make config: don't edit
# Linux kernel version: 2.6.10-gentoo-r6
# Mon Jan 24 17:30:52 2005
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

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

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

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

#
# Processor type and features
#
CONFIG_X86_PC=y
CONFIG_MPENTIUM4=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
# CONFIG_HPET_TIMER is not set
CONFIG_SMP=y
CONFIG_NR_CPUS=8
CONFIG_SCHED_SMT=y
CONFIG_PREEMPT=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=y
CONFIG_X86_MCE_P4THERMAL=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set

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


CONFIG_AGP=y
# CONFIG_AGP_ALI is not set
# CONFIG_AGP_ATI is not set
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_AMD64 is not set
CONFIG_AGP_INTEL=y
CONFIG_AGP_INTEL_MCH=y
# CONFIG_AGP_NVIDIA is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_SWORKS is not set
# CONFIG_AGP_VIA is not set
# CONFIG_AGP_EFFICEON is not set
CONFIG_DRM=y
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
# CONFIG_DRM_RADEON is not set
# CONFIG_DRM_I810 is not set
# CONFIG_DRM_I830 is not set
CONFIG_DRM_I915=y

CONFIG_FB=y
CONFIG_FB_MODE_HELPERS=y
# CONFIG_FB_TILEBLITTING is not set
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
CONFIG_FB_VESA=y
# CONFIG_FB_VESA_STD is not set
CONFIG_FB_VESA_TNG=y
CONFIG_FB_VESA_DEFAULT_MODE="[EMAIL PROTECTED]"
# CONFIG_VIDEO_SELECT is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_I810 is not set
# CONFIG_FB_INTEL is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON_OLD is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_SAVAGE is not set
# 

Re: [ANN] removal of certain net drivers coming soon: eepro100, xircom_tulip_cb, iph5526

[Scott Feldman]

On Thu, 2005-01-27 at 16:48, David S. Miller wrote:
> On Fri, 28 Jan 2005 00:14:30 +
> Russell King <[EMAIL PROTECTED]> wrote:
> 
> > The fact of the matter is that eepro100.c works on ARM, e100.c doesn't.
> > There's a message from me back on 30th June 2004 at about 10:30 BST on
> > this very list which generated almost no interest from anyone...
> 
> I see.  Since eepro100 just uses a fixed set of RX buffers in the
> ring (ie. the DMA links are never changed) it works.

eepro100 does a copy if pkt_len < rx_copybreak, otherwise it send up the
skb and allocates and links a new one in it's place (see
speedo_rx_link).

So I would say e100 and eepro100 are the same for >= rx_copybreak.  Why
does one work and not the other?  Is it because the RFD is aligned in
eepro100?

Russell, what happens with modprobe eepro100 rx_copybreak=0?

-scott

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: I need a hardware wizard... I have been beating my head on the wall..

[Jeff Garzik]

David Sims wrote:
Hi,
  I have posted a couple of times in the past to no avail... I have an
Intel 31244 SATA controller that is supposed to work with the sata_vsc
driver module... It does in fact, almost
  You can insert the module in a running kernel and after barking as
follows (once for each disk attached) it runs just fine.
Basically nobody has ever had hardware to test sata_vsc with that 
hardware.  We should probably remove the PCI ID until an engineer can 
fix it...

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: crypto algoritms failing?

[Nigel Cunningham]

Hi.

You normally test cryptoapi functionality while booting?

Anyway, I can confirm that if suspend2 touches anything remotely related
to this, it's unintentional and I'll fix it :>

Nigel

On Fri, 2005-01-28 at 10:30, Jasper Spaans wrote:
> Hi List,
> 
> When booting I see this in dmesg:
> 
> testing tea ECB encryption 
> test 1 (128 bit key):
> 0a3aea4140a9ba94
> fail
> test 2 (128 bit key):
> 775d2a6af6ce9209
> fail
> test 3 (128 bit key):
> be7abb81952d1f1edd89a1250421df95
> fail
> test 4 (128 bit key):
> e04d5d3cb78c364794189591a9fc49f844d12dc299b8082a078973c24592c690
> fail
> [..]
> testing xtea ECB encryption 
> test 1 (128 bit key):
> aa2296e56c61f345
> fail
> test 2 (128 bit key):
> 823eeb35dcddd9c3
> fail
> test 3 (128 bit key):
> e204dbf289859eea6135aaedb5cb712c
> fail
> test 4 (128 bit key):
> 0b03cd8abe95fdb1c144910ba5c91bb4a9da1e9eb13e2a8feaa56a85d1f4a8a5
> fail
> 
> CPU in that machine is an athlon xp, cpu flags according to /proc/cpuinfo
> flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
> cmov pat pse36 mmx fxsr sse pni syscall mmxext 3dnowext 3dnow
> 
> Compiler: gcc 3.3.5 (debian package 1:3.3.5-6)
> 
> Is this supposed to happen?
> 
> 
> Jasper
-- 
Nigel Cunningham
Software Engineer
Cyclades Corporation

http://cyclades.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/

I need a hardware wizard... I have been beating my head on the wall..

[David Sims]

Hi,

  I have posted a couple of times in the past to no avail... I have an
Intel 31244 SATA controller that is supposed to work with the sata_vsc
driver module... It does in fact, almost

  You can insert the module in a running kernel and after barking as
follows (once for each disk attached) it runs just fine.

Jan 24 13:55:37 linux kernel: irq 3: nobody cared!
Jan 24 13:55:37 linux kernel: [] __report_bad_irq+0x22/0x90
Jan 24 13:55:37 linux kernel: [] note_interrupt+0x58/0x90
Jan 24 13:55:37 linux kernel: [] __do_IRQ+0xd8/0xe0
Jan 24 13:55:37 linux kernel: [] do_IRQ+0x1a/0x30
Jan 24 13:55:37 linux kernel: [] common_interrupt+0x1a/0x20
Jan 24 13:55:37 linux kernel: [] __do_softirq+0x30/0x90
Jan 24 13:55:37 linux kernel: [] do_softirq+0x35/0x40
Jan 24 13:55:37 linux kernel: [] do_IRQ+0x1f/0x30
Jan 24 13:55:37 linux kernel: [] common_interrupt+0x1a/0x20
Jan 24 13:55:37 linux kernel: [] default_idle+0x0/0x40
Jan 24 13:55:37 linux kernel: [] default_idle+0x24/0x40
Jan 24 13:55:37 linux kernel: [] cpu_idle+0x2e/0x40
Jan 24 13:55:37 linux kernel: [] start_kernel+0x15b/0x190

Jan 24 13:55:37 linux kernel: handlers:
Jan 24 13:55:37 linux kernel: [] (ide_intr+0x0/0x120)
Jan 24 13:55:37 linux kernel: [] (ide_intr+0x0/0x120)
Jan 24 13:55:37 linux kernel: [] (vsc_sata_interrupt+0x0/0xa0
[sata_vsc])
Jan 24 13:55:37 linux kernel: Disabling IRQ #3


  The problem is that when you insert the module at boot time, the machine
just hangs while trying to enumerate the first disk Same when booting
with the module builtin to a monolithic kernel

  To facilitate helping me, I have gathered the requisite stuff and posted
it on my website as follows:

   http://www.dpsims.com/~dpsims/31244/

  If someone would be so kind as to help me, I would be willing to provide
access to the machine in question for testing, etc... I believe the
problem is caused by the Intel 31244 having multiple ways of sending
interrupts... The Intel documentation is located at:

   http://www.dpsims.com/~dpsims/31244/31244_developers_guide.pdf

and I draw your attention to section 5.8 and 5.9 The code for the
sata_vsc.c from kernel 2.6.10 can be found at

   http://www.dpsims.com/~dpsims/31244/sata_vsc.c

I would make this work myself if I had the required skill sets... but I
don't Thus I am reduced to pleading ;)

Please help me. I will try to contribute whatever I can... quickly
test /etc...

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: crypto algoritms failing?

[James Morris]

On Fri, 28 Jan 2005, Jasper Spaans wrote:

> On Thu, Jan 27, 2005 at 07:38:43PM -0500, James Morris wrote:
> > > Is this supposed to happen?
> > 
> > No.  What is your kernel version?
> 
> Current bitkeeper + latest swsusp2 patches and hostap driver, however, those
> two don't come near touching the crypto stuff[1] so they're not really on my
> suspect shortlist, but I'll see if I can find time to build a vanilla one
> tomorrow (that is, without swsusp/hostap).. right now, it's time to sleep in
> my local timezone..

Looks like a cleanup broke the test vectors:
http://linux.bkbits.net:8080/linux-2.5/[EMAIL PROTECTED]

Patch below, please apply.

Signed-off-by: James Morris <[EMAIL PROTECTED]>


---

diff -purN -X dontdiff linux-2.6.11-rc1-mm1.o/crypto/tcrypt.h 
linux-2.6.11-rc1-mm1.w/crypto/tcrypt.h
--- linux-2.6.11-rc1-mm1.o/crypto/tcrypt.h  2005-01-19 09:30:32.0 
-0500
+++ linux-2.6.11-rc1-mm1.w/crypto/tcrypt.h  2005-01-27 20:28:23.312918312 
-0500
@@ -1986,7 +1986,7 @@ static struct cipher_testvec arc4_dec_tv
 #define TEA_ENC_TEST_VECTORS   4
 #define TEA_DEC_TEST_VECTORS   4
 
-static struct cipher_testvec xtea_enc_tv_template[] =
+static struct cipher_testvec tea_enc_tv_template[] =
 {
{
.key= { [0 ... 15] = 0x00 },
@@ -2080,7 +2080,7 @@ static struct cipher_testvec tea_dec_tv_
 #define XTEA_ENC_TEST_VECTORS  4
 #define XTEA_DEC_TEST_VECTORS  4
 
-static struct cipher_testvec tea_enc_tv_template[] =
+static struct cipher_testvec xtea_enc_tv_template[] =
 {
{
.key= { [0 ... 15] = 0x00 },




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Memory leak in 2.6.11-rc1?

[Phil Oester]

On Fri, Jan 28, 2005 at 12:17:01AM +, Russell King wrote:
> On Thu, Jan 27, 2005 at 12:33:26PM -0800, David S. Miller wrote:
> > So they won't be listed in /proc/net/rt_cache (since they've been
> > removed from the lookup table) but they will be accounted for in
> > /proc/net/stat/rt_cache until the final release is done on the
> > routing cache object and it can be completely freed up.
> > 
> > Do you happen to be using IPV6 in any way by chance?
> 
> Yes.  Someone suggested this evening that there may have been a recent
> change to do with some IPv6 refcounting which may have caused this
> problem.  Is that something you can confirm?

FWIW, I do not use IPv6, and it is not compiled into the kernel.

Phil
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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-rc2 TCP ignores PMTU ICMP (Re: Linux 2.6.11-rc2)

[Patrick McHardy]

David S. Miller wrote:
I've forwarded this to netfilter-devel for inspection.
Thanks for collecting all the data points so well.
Here is the fix for everyone. Please report back if it doesn't
solve the problem. Thanks.

= net/ipv4/netfilter/ip_nat_proto_tcp.c 1.10 vs edited =
--- 1.10/net/ipv4/netfilter/ip_nat_proto_tcp.c  2005-01-17 23:00:55 +01:00
+++ edited/net/ipv4/netfilter/ip_nat_proto_tcp.c2005-01-28 02:13:06 
+01:00
@@ -105,7 +105,7 @@
return 0;
 
iph = (struct iphdr *)((*pskb)->data + iphdroff);
-   hdr = (struct tcphdr *)((*pskb)->data + iph->ihl*4);
+   hdr = (struct tcphdr *)((*pskb)->data + hdroff);
 
if (maniptype == IP_NAT_MANIP_SRC) {
/* Get rid of src ip and src pt */

Re: [PATCH] Fix kallsyms/insmod/rmmod race [try #2]

[Rusty Russell]

On Thu, 2005-01-27 at 14:08 +, David Howells wrote:
> Signed-Off-By: David Howells <[EMAIL PROTECTED]>

Excellent.  Thanks David!

Rusty.
-- 

A bad analogy is like a leaky screwdriver -- Richard Braakman

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 4/6 randomize the stack pointer

[H. Peter Anvin]

Roland Dreier wrote:
Julien> Not very important but ((get_random_int() % 4096) << 4)
Julien> could be optimized into get_random_int() & 0xFFF0.
HPA> .. and gcc knows that.
HPA>8:   25 ff 0f 00 00  and$0xfff,%eax
HPA>d:   83 c4 0cadd$0xc,%esp
HPA>   10:   c1 e0 04shl$0x4,%eax
Actually gcc isn't quite that smart (since it obviously can't
understand the semantics of get_random int()).  The original point was
that the "shl $0x4" can be avoided by directly &'ing with 0xfff0, not
that "% 4096" can be strength reduced to "& 0xfff".
Oh, right.  D'oh!  :)
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.10-rc2] sched: fix ->nr_uninterruptible handling bugs

[Linus Torvalds]

On Thu, 27 Jan 2005, Paul Jackson wrote:
>
> A long time ago, Linus wrote:
> > An atomic op is pretty much as expensive as a spinlock/unlock pair on x86.  
> > Not _quite_, but it's pretty close.
> 
> Are both read and modify atomic ops relatively expensive on some CPUs,
> or is it just modify atomic ops?

Linux pretty much assumes that any naturally aligned read or write of the
basic word-size (actually "int"/"long"/pointer) are always atomic.  
That's true on all architectures that do SMP today. In fact, it's hard
seeing it ever be not true, although specialized architectures with
out-of-band locking bits might have different assumptions (and return
"invalid" for a memory location that is "in flux").

So if you just do a regular read or write, that's basically always cheap.

HOWEVER. In the absense of locking, you usually can't just do a regular
read or write. You'd have memory barriers etc, which quite easily bring
the cost up to similar as locking (modulo cacheline bounces, which would
happen on the actual access, not the barrier).

Also, "bigger" accesses are not atomic, ie a 64-bit read on a 32-bit 
platform usually requires a lock (or equivalent data structures, like 
sequence numbers with memory barriers).

The _real_ cost of not locking also often ends up being the inevitable 
bugs. Doing clever things with memory barriers is almost always a bug 
waiting to happen. It's just _really_ hard to wrap your head around all 
the things that can happen on ten different architectures with different
memory ordering, and a single missing barrier.

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

Re: Advice sought on how to lock multiple pages in ->prepare_write and ->writepage

[Andrew Morton]

Anton Altaparmakov <[EMAIL PROTECTED]> wrote:
>
> What would you propose can I do to perform the required zeroing in a
> deadlock safe manner whilst also ensuring that it cannot happen that a
> concurrent ->readpage() will cause me to miss a page and thus end up
> with non-initialized/random data on disk for that page?

The only thing I can think of is to lock all the pages.  There's no other
place in the kernel above you which locks multiple pagecache pages, but we
can certainly adopt the convention that multiple-page-locking must proceed
in ascending file offset order.

Which means that you'll need to drop and reacquire the page lock in
->prepare_write and in ->writepage, which could get unpleasant.

For ->prepare_write it should be OK: the caller has a ref on the inode and
you can check ->mapping after locking the page to see if a truncate flew
past (OK, you have i_sem, but writepage will need to do this check).

For writepage() or writepages() with for_reclaim=0 you're OK: the caller
has a ref on the inode and has taken sb->s_umount, so you can safely drop
and retake the page lock.

For ->writepage with for_reclaim=1 the problem is that the inode can
disappear on you altogether: you have no inode ref and if you let go of
that page lock, truncate+reclaim or truncate+umount can zap the inode.

So hrm.  I guess your ->writepage(for_reclaim=1) could do a trylock on
s_umount and fail the writepage if that didn't work out.

That leaves the problem of preventing truncate+reclaim from zapping the
inode when you've dropped the page lock.  I don't think you'll want to take
a ref on the inode because the subsequent iput() can cause a storm of
activity and I have vague memories that iput() inside
->writepage(for_reclaim=1) is a bad deal.  Maybe do a trylock on i_sem and
fail the writepage if that doesn't work out?

That way, once you have i_sem and s_umount you can unlock the target page
then populate+lock all the pages in the 64k segment.

Not very pretty though.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [ANN] removal of certain net drivers coming soon: eepro100, xircom_tulip_cb, iph5526

[David S. Miller]

On Fri, 28 Jan 2005 00:14:30 +
Russell King <[EMAIL PROTECTED]> wrote:

> The fact of the matter is that eepro100.c works on ARM, e100.c doesn't.
> There's a message from me back on 30th June 2004 at about 10:30 BST on
> this very list which generated almost no interest from anyone...

I see.  Since eepro100 just uses a fixed set of RX buffers in the
ring (ie. the DMA links are never changed) it works.

This adapter was definitely developed for a system that has to have
PCI device DMA and CPU cached data accesses in the same coherency
space in order to use their weird RX chaining thing.

So essentially, e100 needs to have it's RX logic rewritten so that
it uses a static RX descriptor set of buffers and skb_copy()'s them
to push the packets into the stack.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: crypto algoritms failing?

[Jasper Spaans]

On Thu, Jan 27, 2005 at 07:38:43PM -0500, James Morris wrote:
> > Is this supposed to happen?
> 
> No.  What is your kernel version?

Current bitkeeper + latest swsusp2 patches and hostap driver, however, those
two don't come near touching the crypto stuff[1] so they're not really on my
suspect shortlist, but I'll see if I can find time to build a vanilla one
tomorrow (that is, without swsusp/hostap).. right now, it's time to sleep in
my local timezone..


Groet,
-- 
Jasper Spaans   http://jsp.vs19.net/
 01:40:46 up 10207 days, 17:27, 0 users, load average: 6.00 6.00 6.12

[1] hostap however does use some crypto algoritms, if I'm not mistaken, but
its modules are not loaded in that stage of booting


signature.asc
Description: Digital signature

Re: [patch, 2.6.10-rc2] sched: fix ->nr_uninterruptible handling bugs

[Paul Jackson]

A long time ago, Linus wrote:
> An atomic op is pretty much as expensive as a spinlock/unlock pair on x86.  
> Not _quite_, but it's pretty close.

Are both read and modify atomic ops relatively expensive on some CPUs,
or is it just modify atomic ops?

(Ignoring for this question the possibility that a mix of read and
modify ops could heat up a cache line on multiprocessor systems, and
focusing for the moment just on the CPU internals ...)

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANN] removal of certain net drivers coming soon: eepro100, xircom_tulip_cb, iph5526

[Lennert Buytenhek]

On Fri, Jan 28, 2005 at 12:14:30AM +, Russell King wrote:

> The fact of the matter is that eepro100.c works on ARM, e100.c doesn't.

Hmmm, I recall e100 working fine on a Radisys ENP-2611, which has a
IXP2400 (xscale) in big-endian mode, running 2.6.  This particular
board had its root fs NFS-mounted and pumped several hundreds of
gigabytes through the NIC during a period of at least a few months,
and I never saw any problems.

Something tells me that the next time I try it, it won't work at all.


--L
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 1/8] pcxx: Remove reference in MAINTAINERS

[James Nelson]

This patch removes references to the pcxx driver in MAINTAINERS.

Signed-off-by: James Nelson <[EMAIL PROTECTED]>

diff -urN --exclude='*~' linux-2.6.11-rc2-mm1-original/MAINTAINERS 
linux-2.6.11-rc2-mm1/MAINTAINERS
--- linux-2.6.11-rc2-mm1-original/MAINTAINERS   2005-01-24 17:16:10.0 
-0500
+++ linux-2.6.11-rc2-mm1/MAINTAINERS2005-01-27 16:51:18.0 -0500
@@ -708,13 +708,6 @@
 W: http://www.digi.com
 S: Orphaned
 
-DIGIBOARD PC/XE AND PC/XI DRIVER
-P: Christoph Lameter
-M: [EMAIL PROTECTED]
-W: http://www.digi.com
-L: [EMAIL PROTECTED]
-S: Obsolete
-
 DIRECTORY NOTIFICATION
 P: Stephen Rothwell
 M: [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: Possible bug in keyboard.c (2.6.10)

[Roman Zippel]

Hi,

On Thu, 27 Jan 2005, Andries Brouwer wrote:

> In short - raw mode in 2.6 is badly broken.

I think not just that. The whole keyboard input layer needs some serious 
review. Just the complete lack of any locking is frightening, I'd really 
like to know how the input layer could become the standard. I tried to 
find a few times to find any discussion about the input layer design, but 
I couldn't find anything.

Some of my favourites in the input layer:
- the keyboard sound/led handling: the keyboard driver basically fakes 
events for the device and input_event() is "clever" enough to also tell 
the device about it. This is quite an abuse of event system for general 
device/driver communication.
- a single input device structure for all types: this structure is quite 
big, where most of its contents is irrelevant for most devices.
- fine grained matching/filtering: I have no idea why the input layer has 
to do this down to the single event instead of just the event type.

Vojtech, could you please explain a bit the reason for the above and what 
are your plans to e.g. fix the locking?

bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Memory leak in 2.6.11-rc1?

[David S. Miller]

On Fri, 28 Jan 2005 00:17:01 +
Russell King <[EMAIL PROTECTED]> wrote:

> Yes.  Someone suggested this evening that there may have been a recent
> change to do with some IPv6 refcounting which may have caused this
> problem.  Is that something you can confirm?

Yep, it would be this change below.  Try backing it out and see
if that makes your leak go away.

# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2005/01/14 20:41:55-08:00 [EMAIL PROTECTED] 
#   [IPV6]: Fix locking in ip6_dst_lookup().
#   
#   The caller does not necessarily have the socket locked
#   (udpv6sendmsg() is one such case) so we have to use
#   sk_dst_check() instead of __sk_dst_check().
#   
#   Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
#   Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
# 
# net/ipv6/ip6_output.c
#   2005/01/14 20:41:34-08:00 [EMAIL PROTECTED] +3 -3
#   [IPV6]: Fix locking in ip6_dst_lookup().
#   
#   The caller does not necessarily have the socket locked
#   (udpv6sendmsg() is one such case) so we have to use
#   sk_dst_check() instead of __sk_dst_check().
#   
#   Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
#   Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
# 
diff -Nru a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
--- a/net/ipv6/ip6_output.c 2005-01-27 16:07:21 -08:00
+++ b/net/ipv6/ip6_output.c 2005-01-27 16:07:21 -08:00
@@ -745,7 +745,7 @@
if (sk) {
struct ipv6_pinfo *np = inet6_sk(sk);

-   *dst = __sk_dst_check(sk, np->dst_cookie);
+   *dst = sk_dst_check(sk, np->dst_cookie);
if (*dst) {
struct rt6_info *rt = (struct rt6_info*)*dst;

@@ -772,9 +772,9 @@
 && (np->daddr_cache == NULL ||
 !ipv6_addr_equal(>fl6_dst, 
np->daddr_cache)))
|| (fl->oif && fl->oif != (*dst)->dev->ifindex)) {
+   dst_release(*dst);
*dst = NULL;
-   } else
-   dst_hold(*dst);
+   }
}
}
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: crypto algoritms failing?

[James Morris]

On Fri, 28 Jan 2005, Jasper Spaans wrote:

> Is this supposed to happen?

No.  What is your kernel version?


- James
-- 
James Morris
<[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/

[PATCH 0/8] pcxx: Remove obsolete driver

[James Nelson]

This series of patches is to remove the pcxx driver.  It is obsoleted by the 
epca
driver.

These patches go together.

Diffstat:
 MAINTAINERS  |7
 drivers/char/Kconfig |   17
 drivers/char/Makefile|1
 drivers/char/digi_bios.h |  177 ---
 drivers/char/digi_fep.h  |  517 --
 drivers/char/fep.h   |  168 ---
 drivers/char/pcxx.c  | 2353 ---
 drivers/char/pcxx.h  |  128 --
 8 files changed, 3368 deletions(-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: User space out of memory approach

[Andrew Morton]

Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
>
> And they had not necessairly hardware access. They "might" have hardware
> access.

On x86 we could perhaps test for non-nullness of tsk->thread->io_bitmap_ptr?

> I thought I could wait the other patches
> to be merged to avoid confusion before making more changes (since it'd
> be a pretty self contained feature), but I can do that now if you
> prefer.

I'll send your current stuff off to Linus in the next few days - we can let
that sit for a while, use that as a base for further work.

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

Re: [RFC: 2.6 patch] drivers/acpi/: possible cleanups

[Dmitry Torokhov]

On Thursday 27 January 2005 18:04, Len Brown wrote:
> Thanks for the patch Adrian.
> 
> I agree that this is the right direction to go -- enforcing APIs with
> the use of static reduces the possibility of programming errors --
> particularly with many cooks in the kitchen. ÂIndeed, just on Monday we
> discussed a patch from Alexey Starikovskiy to do the same thing.
> 
> The problem is one of logistics.
> As I've described before, the files with "R. Byron Moore" at the top are
> dual-licensed so Intel can distribute the core interpreter both as GPL
> to Linux and also to FreeBSD, HP-UX etc


Well, I can not speak for Adrian but if I were to submit a patch and state
that it is also dual licensed you should have no troubles applying it even
to the core files, right?
  
-- 
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/

High resolution timers and BH processing on -RT

[Thomas Gleixner]

Hi,

some thoughts and observations. 

I'm running -RT + a port of UTIME (the grandfather of HRT, IIRC) on a
couple of machines (x86,ppc,arm - all UP) here.

One part of the problem is the gettimeofday() issue, which seems to be
already addressed by John Stulz's patches.

The more interresting question in terms of realtime is the processing of
the timer queue(s) and the reprogramming of the timer for the next
event.

With -RT enabled the timer queue is solely processed by ksoftirqd, which
handles all the other bottom halfs too. So pushing the priority of
ksoftirqd up is not a solution. 
If I understood the HRT code correctly then this applies here too.
Please correct me if I'm wrong.

This makes the timer queue dependend on a variety of other softirq
clients, so you can not predict which of those clients are active and
what's the computation time they consume.

One possibility to solve this is seperating the softirqs into different
threads. We have done this already and it seems to be an interesting
approach in terms of scalability of bottom half processing.

Another approach is splitting realtime timers and normal timers, which
introduces the ugliness of different timer queues, but it has the
advantage that the rare realtime queue users can be handled in the
(threaded) top half for accuracy sake and the "normal" users are still
running on the jiffy bound vanilla linux timer queue, which is handled
in the non predictible path of the ksoftirqd thread.

I know that this topic was discussed various times already, but the -RT
view adds a different dimension. The modifications for the splitted
queues are minimal invasive in kernel/timer.c, but still introduce the
same amount of noise in nanosleep, itimer and posix_timer code.

Even if we agree that most of the timers are removed from the queue
before the expiry - especially those of the networking code - moving all
timers into high resolution mode results in non trivial noise injection
due to the short reprogramming intervals. 

Some numbers to make this more transparent.

Machine: PIII Celeron 333MHz
RT - T0: 1ms cyclic
RT - T1: 2ms cyclic


Load average is ~4.0 for all tests. The numbers are maximum deviation
from the timeline in microseconds. Test time was ~60 minutes for each
szenario.

Running all timers in high resolution mode (ksoftirqd) results in:
[T0  Prio:  60]  2123
[T1  Prio:  59]  2556
[T2  Prio:  58]  2882
[T3  Prio:  57]  2993
[T4  Prio:  56]  2888

Running all timers in high resolution mode (seperated timer softirqd
PRIO=70) results in:
[T0  Prio:  60]  423
[T1  Prio:  59]  372
[T2  Prio:  58]  756
[T3  Prio:  57]  802
[T4  Prio:  56]  1208

Seperating realtime process related timers into the threaded top half
queue (TIMER IRQ PRIO = 90) and running all other timers inside of
ksoftirqd results in:
[T0  Prio:  60]  84
[T1  Prio:  59]  114
[T2  Prio:  58]  120
[T3  Prio:  57]  117
[T4  Prio:  56]  158

I think that these numbers are significant for low power machines. This
area is my main concern - not the highend SMP szenario - as the main
users of realtime systems can be met in the embedded world.

Offtopic, but related question:

I discovered that the USB subsystem introduces 2-5 ms random chaos when
a device is pluged/unplugged. I had not time to track the culprit down
yet. Any pointers ???

tglx


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: User space out of memory approach

[Andrea Arcangeli]

On Thu, Jan 27, 2005 at 03:35:35PM -0800, Andrew Morton wrote:
> On x86 we could perhaps test for non-nullness of tsk->thread->io_bitmap_ptr?

yes for ioports. But I'm afraid I was too optimistic about eflags for
iopl, that's not in the per-task tss, it's only stored at the very top
of the kernel stack and inherit during fork/clone. So we probably need
to check esp0 and read the top of the stack to see if a task has eflags
set. esp0 is definitely stored in the thread struct when the task is
rescheduled, and it cannot change for each given task, so we can access
it even while the task is runnable and it shouldn't be corrupted by
iret. But the problem is sysenter is optimized not to save eflags on the
kernel stack, so the top of the stack - 12bytes would not contain eflags
if sysenter is in use.

So basically we'd need to change iopl to propagate the info to the task
struct synchronously somehow, because we can't read it reliably from the
kernel stack.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2.4] lcd: Add checks to CAP_SYS_ADMIN to potentially dangerous ioctl's

[James Nelson]

This patch adds CAP_SYS_ADMIN checks to the potentially dangerous ioctls 
FLASH_Erase and FLASH_Burn
in the Cobalt LCD interface driver.

Signed-off-by: James Nelson <[EMAIL PROTECTED]>

diff -purN --exclude='*~' linux-2.4.29-original/drivers/char/lcd.c 
linux-2.4.29/drivers/char/lcd.c
--- linux-2.4.29-original/drivers/char/lcd.c2005-01-27 18:46:42.085690494 
-0500
+++ linux-2.4.29/drivers/char/lcd.c 2005-01-27 18:54:00.902766505 -0500
@@ -386,6 +386,8 @@ static int lcd_ioctl(struct inode *inode
 
int ctr=0;
 
+   if (!capable(CAP_SYS_ADMIN)) return -EPERM;
+
// Chip Erase Sequence
WRITE_FLASH( kFlash_Addr1, kFlash_Data1 );
WRITE_FLASH( kFlash_Addr2, kFlash_Data2 );
@@ -422,6 +424,8 @@ static int lcd_ioctl(struct inode *inode
 
 struct lcd_display display;
 
+   if (!capable(CAP_SYS_ADMIN)) return -EPERM;
+
 if(copy_from_user(, (struct lcd_display*)arg, 
sizeof(struct lcd_display)))
  return -EFAULT;
rom = (unsigned char *) kmalloc((128),GFP_ATOMIC);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2.4] lcd: fix memory leak in lcd_ioctl()

[James Nelson]

This patch fixes a memory leak in the FLASH_Burn ioctl for the Cobalt LCD 
interface driver.

Signed-off-by: James Nelson <[EMAIL PROTECTED]>

diff -purN --exclude='*~' linux-2.4.29-original/drivers/char/lcd.c 
linux-2.4.29/drivers/char/lcd.c
--- linux-2.4.29-original/drivers/char/lcd.c2005-01-27 18:46:42.085690494 
-0500
+++ linux-2.4.29/drivers/char/lcd.c 2005-01-27 18:49:38.011310971 -0500
@@ -434,8 +434,10 @@ static int lcd_ioctl(struct inode *inode
save_flags(flags);
for (i=0; ihttp://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: thoughts on kernel security issues

[linux-os]

On Thu, 27 Jan 2005, John Richard Moser wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bill Davidsen wrote:
On Thu, 27 Jan 2005, Zan Lynx wrote:

On Thu, 2005-01-27 at 10:37 -0600, Jesse Pollard wrote:
On Wednesday 26 January 2005 13:56, Bill Davidsen wrote:
On Wed, 26 Jan 2005, Jesse Pollard wrote:
On Tuesday 25 January 2005 15:05, linux-os wrote:
This isn't relavent [Stuff about the navy][...]
The Navy [...]
[...]Physical network topology[...]
[...]sneakernet[...]

[...]path[...]
[...]internet[...]
[...]hahaha[...]
[...]NSA[...]

[...]security clearance[...]
I'll ask again
How the [EMAIL PROTECTED] did the navy get involved in this discussion?
That's where the love-you virus was (supposed to have been)
introduced into a secure system. It's probably, with I would
guess a probable 89-90 percent probability, some BS.
You spelled [EMAIL PROTECTED] wrong. The 'u' is ahead of the 'c'. You
dyslexic or something?

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
 98.36% of all statistics are fiction.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 4/6 randomize the stack pointer

[Roland Dreier]

Julien> Not very important but ((get_random_int() % 4096) << 4)
Julien> could be optimized into get_random_int() & 0xFFF0.

HPA> .. and gcc knows that.

HPA>8:   25 ff 0f 00 00  and$0xfff,%eax
HPA>d:   83 c4 0cadd$0xc,%esp
HPA>   10:   c1 e0 04shl$0x4,%eax

Actually gcc isn't quite that smart (since it obviously can't
understand the semantics of get_random int()).  The original point was
that the "shl $0x4" can be avoided by directly &'ing with 0xfff0, not
that "% 4096" can be strength reduced to "& 0xfff".

 - R.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Memory leak in 2.6.11-rc1?

[Russell King]

On Thu, Jan 27, 2005 at 12:33:26PM -0800, David S. Miller wrote:
> So they won't be listed in /proc/net/rt_cache (since they've been
> removed from the lookup table) but they will be accounted for in
> /proc/net/stat/rt_cache until the final release is done on the
> routing cache object and it can be completely freed up.
> 
> Do you happen to be using IPV6 in any way by chance?

Yes.  Someone suggested this evening that there may have been a recent
change to do with some IPv6 refcounting which may have caused this
problem.  Is that something you can confirm?

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA  - http://pcmcia.arm.linux.org.uk/
 2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Adding an async I2C interface

[Mark Studebaker]

is there a way to do this solely in i2c-core without having to
add support to all the drivers?
Corey Minyard wrote:
I have an IPMI interface driver that sits on top of the I2C code.  I'd
like to get it into the mainstream kernel, but I have a few problems
to solve first before I can do that.  The I2C code is synchronous and
must run from a task context.  The IPMI driver has certain
operations that occur at panic time, including:
  * Storing panic information in IPMI's system event log
  * Extending the watchdog timer so it doesn't go off during panic
operations (like kernel coredumps).
  * Powering the system off
I can't really put the IPMI SMB interface into the kernel until I can
do those operations.  Also, I understand that some vendors put RTC
chips onto the I2C bus and this must be accessed outside task context,
too.  I would really like add asynchronous interface to the I2C bus
drivers.  I propose:
  * Adding an async send interface to the busses that does a callback
when the operation is complete.
  * Adding a poll interface to the busses.  The I2C core code could
call this if a synchronous call is made from task context (much
like all the current drivers do right now).  For asyncronous
operation, the I2C core code would call it from a timer
interrupt.  If the driver supported interrupts, polling from the
timer interrupt would not be necessary.
  * Add async operations for the user to call, including access to the
polling code.
  * If the driver didn't support an async send, it would work as it
does today and the async calls would return ENOSYS.
This way, the bus drivers on I2C could be converted on a
driver-by-driver basis.  The IPMI code could query to see if the
driver supported async operations.  And the RTC code could use it,
too.
Is this ok with the I2C community?  I would do the base work and
convert over a few drivers.
Thanks,
-Corey

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [ANN] removal of certain net drivers coming soon: eepro100, xircom_tulip_cb, iph5526

[Russell King]

On Thu, Jan 27, 2005 at 03:31:14PM -0800, David S. Miller wrote:
> Therefore the only missing sync would be of the new RX descriptor
> when linking things in like that, ie. at the end of e100_rx_alloc_skb()
> if rx->prev->skb is non-NULL.

And that is inherently unsafe, since the chip may be modifying the RFD
while the CPU is accessing it.  Adding extra sync calls does not fix
it because as far as I can see, there's nothing to tell the chip "don't
write to this RFD because any changes the CPU is making right now will
overwrite the chips own changes."

The fact of the matter is that eepro100.c works on ARM, e100.c doesn't.
There's a message from me back on 30th June 2004 at about 10:30 BST on
this very list which generated almost no interest from anyone...

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA  - http://pcmcia.arm.linux.org.uk/
 2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: thoughts on kernel security issues

[Krzysztof Halasa]

Zan Lynx <[EMAIL PROTECTED]> writes:

> In the reality I'm familiar with, the defense contractor's secure
> projects building had one entrance, guarded by security guards who were
> not cheap $10/hr guys, with strict instructions.  No computers or
> computer media were allowed to leave the building except with written
> authorization of a corporate officer.

Wow, nice. How do they check for, say, Compact Flashes or, for example,
even smaller XD-picture cards?
-- 
Krzysztof Halasa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

netdev-2.6 queue updated

[Jeff Garzik]

The attached changelog describes what I just pushed out to BitKeeper 
(and what should be appearing in the next -mm release from Andrew).

Note to BK users:  please re-clone netdev-2.6, don't just 'bk pull'.
Most of this is simply stuff that is "hanging out for a while" in 
netdev-2.6 while it -- hopefully -- gets testing and review.  All of 
these changes are bound for upstream eventually.

Note on wireless:  HostAP and Vladmir's effort to make 802.11 a "real" 
Linux network protocol both seem to have stagnated a bit.  I'm still 
hoping that
* Intel will appear with a patch that merges their drivers
* some magical engineering force will start using the HostAP code as 
common library code in other drivers (notably Intel)
* Vladmir or someone will continue Vladmir's work to integrate wireless 
more closely with the Linux network stack

Jeff

BK users:

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

This will update the following files:

 Documentation/networking/ixgb.txt   |9 
 MAINTAINERS |7 
 drivers/net/3c503.c |   67 
 drivers/net/3c515.c |   32 
 drivers/net/8139cp.c|  100 
 drivers/net/8139too.c   |  291 -
 drivers/net/Kconfig |   12 
 drivers/net/Makefile|1 
 drivers/net/arcnet/arc-rawmode.c|4 
 drivers/net/arcnet/arc-rimi.c   |   14 
 drivers/net/arcnet/arcnet.c |   30 
 drivers/net/arcnet/com20020.c   |6 
 drivers/net/arcnet/com90io.c|4 
 drivers/net/arcnet/com90xx.c|8 
 drivers/net/arcnet/rfc1051.c|8 
 drivers/net/arcnet/rfc1201.c|   12 
 drivers/net/b44.h   |   14 
 drivers/net/cs89x0.c|4 
 drivers/net/es3210.c|   32 
 drivers/net/ewrk3.c |   87 
 drivers/net/fealnx.c|  275 -
 drivers/net/ibmlana.c   |   99 
 drivers/net/ibmlana.h   |1 
 drivers/net/irda/act200l-sir.c  |3 
 drivers/net/irda/irtty-sir.c|4 
 drivers/net/irda/ma600-sir.c|   12 
 drivers/net/irda/sir_dev.c  |4 
 drivers/net/irda/tekram-sir.c   |3 
 drivers/net/mv643xx_eth.c   | 2398 +-
 drivers/net/mv643xx_eth.h   |  603 --
 drivers/net/ni65.c  |3 
 drivers/net/ns83820.c   |3 
 drivers/net/pcmcia/ibmtr_cs.c   |7 
 drivers/net/pcmcia/xirc2ps_cs.c |   23 
 drivers/net/pcnet32.c   |   47 
 drivers/net/sis900.c|  195 
 drivers/net/sk_mca.c|  126 
 drivers/net/sk_mca.h|   19 
 drivers/net/skge.c  | 3334 ++
 drivers/net/skge.h  | 3005 
 drivers/net/smc-mca.c   |   37 
 drivers/net/smc-ultra.c |   34 
 drivers/net/smc-ultra32.c   |   30 
 drivers/net/smc91x.c|   37 
 drivers/net/smc91x.h|   20 
 drivers/net/tg3.h   |   14 
 drivers/net/tokenring/ibmtr.c   |  158 
 drivers/net/typhoon-firmware.h  | 5568 ++--
 drivers/net/typhoon.c   |  244 -
 drivers/net/wan/cosa.c  |7 
 drivers/net/wan/dscc4.c |  117 
 drivers/net/wd.c|   36 
 drivers/net/wireless/Kconfig|2 
 drivers/net/wireless/Makefile   |2 
 drivers/net/wireless/airo.c |   25 
 drivers/net/wireless/airport.c  |5 
 drivers/net/wireless/arlan.h|4 
 drivers/net/wireless/atmel_cs.c |3 
 drivers/net/wireless/hermes.c   |   43 
 drivers/net/wireless/hermes.h   |   62 
 drivers/net/wireless/hostap/Kconfig |  104 
 drivers/net/wireless/hostap/Makefile|8 
 drivers/net/wireless/hostap/hostap.c| 1205 +
 drivers/net/wireless/hostap/hostap.h|   57 
 drivers/net/wireless/hostap/hostap_80211.h  |  107 
 drivers/net/wireless/hostap/hostap_80211_rx.c   | 1080 
 drivers/net/wireless/hostap/hostap_80211_tx.c   |  522 ++
 drivers/net/wireless/hostap/hostap_ap.c | 3259 ++
 drivers/net/wireless/hostap/hostap_ap.h |  272 +
 

crypto algoritms failing?

[Jasper Spaans]

Hi List,

When booting I see this in dmesg:

testing tea ECB encryption 
test 1 (128 bit key):
0a3aea4140a9ba94
fail
test 2 (128 bit key):
775d2a6af6ce9209
fail
test 3 (128 bit key):
be7abb81952d1f1edd89a1250421df95
fail
test 4 (128 bit key):
e04d5d3cb78c364794189591a9fc49f844d12dc299b8082a078973c24592c690
fail
[..]
testing xtea ECB encryption 
test 1 (128 bit key):
aa2296e56c61f345
fail
test 2 (128 bit key):
823eeb35dcddd9c3
fail
test 3 (128 bit key):
e204dbf289859eea6135aaedb5cb712c
fail
test 4 (128 bit key):
0b03cd8abe95fdb1c144910ba5c91bb4a9da1e9eb13e2a8feaa56a85d1f4a8a5
fail

CPU in that machine is an athlon xp, cpu flags according to /proc/cpuinfo
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 mmx fxsr sse pni syscall mmxext 3dnowext 3dnow

Compiler: gcc 3.3.5 (debian package 1:3.3.5-6)

Is this supposed to happen?


Jasper
-- 
Jasper Spaans   http://jsp.vs19.net/
 00:24:05 up 10207 days, 16:11, 0 users, load average: 6.29 6.03 6.13
 There already is an object oriented version of COBOL.
 It's called "ADD ONE TO COBOL GIVING COBOL."


signature.asc
Description: Digital signature

Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage

[Bill Davidsen]

On Thu, 27 Jan 2005, Evgeniy Polyakov wrote:

> On Thu, 27 Jan 2005 10:19:51 -0500
> Bill Davidsen <[EMAIL PROTECTED]> wrote:
> 
> > Evgeniy Polyakov wrote:
> > > On Mon, 24 Jan 2005 18:54:49 +0100
> > > Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > > 
> > > 
> > >>It seems noone who reviewed the SuperIO patches noticed that there are 
> > >>now two modules "scx200" in the kernel...
> > > 
> > > 
> > > They are almost mutually exlusive(SuperIO contains more advanced), 
> > > so I do not see any problem here.
> > > Only one of them can be loaded in a time.
> > > 
> > > So what does exactly bother you?
> > >
> > That I don't know how to select loading between modules with the same 
> > name. What's the trick?
> 
> Use full path.
> Please see discussion in this thread related to module names.

Ah-ha! I looked at the man page instead of the code. It's not obvious the
"modulename" can be a full path, but the (possibly old) man page I have
for modprobe.conf could be out of date. I'll go look at the code.

Thanks.

-- 
bill davidsen <[EMAIL PROTECTED]>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 4/6 randomize the stack pointer

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:Julien TINNES <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> Not very important but ((get_random_int() % 4096) << 4) could be 
> optimized into get_random_int() & 0xFFF0. Because 4096 is a power of 2 
> you won't loose any entropy by doing  & 0xFFF instead of %4096
> 

.. and gcc knows that.

: tazenda 8 ; cat testme.c
extern unsigned int get_random_int(void);

unsigned int test(void)
{
  return (get_random_int() % 4096) << 4;
}
: tazenda 9 ; objdump -dr testme.o

testme.o: file format elf64-x86-64

Disassembly of section .text:

 :
   0:   48 83 ec 08 sub$0x8,%rsp
   4:   e8 00 00 00 00  callq  9 
5: R_X86_64_PC32
   get_random_int+0xfffc
   9:   25 ff 0f 00 00  and$0xfff,%eax
   e:   48 83 c4 08 add$0x8,%rsp
  12:   c1 e0 04shl$0x4,%eax
  15:   c3  retq
: tazenda 10 ; gcc -m32 -O2 -fomit-frame-pointer -g -c testme.c
: tazenda 11 ; objdump -dr testme.o

testme.o: file format elf32-i386

Disassembly of section .text:

 :
   0:   83 ec 0csub$0xc,%esp
   3:   e8 fc ff ff ff  call   4 
4: R_386_PC32   get_random_int
   8:   25 ff 0f 00 00  and$0xfff,%eax
   d:   83 c4 0cadd$0xc,%esp
  10:   c1 e0 04shl$0x4,%eax
  13:   c3  ret
: tazenda 12 ;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: kernel oops!

[Linus Torvalds]

On Fri, 28 Jan 2005, ierdnah wrote:
> 
> is this patch better? should i test this too?

You probably should. The patch you've tested is really ugly, and not a fix 
at all - it's really just depending on the compiler generating a specific 
code sequence that will hide the race.  As such, it's a patch I would only 
accept in the standard kernel as an absolute last resort.

In contrast, the second patch I tested may actually _fix_ the race. 

The fact that the first patch makes the oops go away is a good thing, 
though: it shows that your oops really was due to that small race window, 
and as such it helps validate that it wasn't anything else.

Thanks,

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

Re: [ANN] removal of certain net drivers coming soon: eepro100, xircom_tulip_cb, iph5526

[David S. Miller]

On Thu, 27 Jan 2005 22:57:25 +
Russell King <[EMAIL PROTECTED]> wrote:

> Has e100 actually been fixed to use the PCI DMA API correctly yet?

It seems to be doing the right thing.  I see the DMA sync calls
(properly using cpu vs. device syncing variants) at the right
spots, and the only thing the chip really relies upon is ordering
of visibility and this is achieved via a combination of cpu memory
barriers and the correct DMA sync calls.

For example, a pci_dma_sync_single_for_cpu() is always performed before
peeking at the descriptors at RX interrupt time (see e100_rx_indicate).

When new descriptors are written to, then linked into the chain it
memory barriers the cpu writes then DMA syncs the previous descriptor
to the device.  This is occuring in e100_alloc_skb().

Therefore the only missing sync would be of the new RX descriptor
when linking things in like that, ie. at the end of e100_rx_alloc_skb()
if rx->prev->skb is non-NULL.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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-rc2 TCP ignores PMTU ICMP (Re: Linux 2.6.11-rc2)

[David S. Miller]

I've forwarded this to netfilter-devel for inspection.
Thanks for collecting all the data points so well.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: thoughts on kernel security issues

[Bill Davidsen]

On Thu, 27 Jan 2005, Zan Lynx wrote:

> On Thu, 2005-01-27 at 10:37 -0600, Jesse Pollard wrote:
> > On Wednesday 26 January 2005 13:56, Bill Davidsen wrote:
> > > On Wed, 26 Jan 2005, Jesse Pollard wrote:
> > > > On Tuesday 25 January 2005 15:05, linux-os wrote:
> > > > > This isn't relevant at all. The Navy doesn't have any secure
> > > > > systems connected to a network to which any hackers could connect.
> > > > > The TDRS communications satellites provide secure channels
> > > > > that are disassembled on-board. Some ATM-slot, after decryption
> > > > > is fed to a LAN so the sailors can have an Internet connection
> > > > > for their lap-tops. The data took the same paths, but it's
> > > > > completely independent and can't get mixed up no matter how
> > > > > hard a hacker tries.
> > > >
> > > > Obviously you didn't hear about the secure network being hit by the "I
> > > > love you" virus.
> > > >
> > > > The Navy doesn't INTEND to have any secure systems connected to a 
> > > > network
> > > > to which any hackers could connect.
> > >
> > > What's hard about that? Matter of physical network topology, absolutely no
> > > physical connection, no machines with a 2nd NIC, no access to/from I'net.
> > > Yes, it's a PITA, add logging to a physical printer which can't be erased
> > > if you want to make your CSO happy (corporate security officer).
> > 
> > And you are ASSUMING the connection was authorized. I can assure you that 
> > there are about 200 (more or less) connections from the secure net to the
> > internet expressly for the purpose of transferring data from the internet
> > to the secure net for analysis. And not ALL of these connections are 
> > authorized. Some are done via sneakernet, others by running a cable ("I need
> > the data NOW... I'll just disconnect afterward..."), and are not visible
> > for very long. Other connections are by picking up a system and carrying it
> > from one connection to another (a version of sneakernet, though here it
> > sometimes needs a hand cart).
> > 
> > > > Unfortunately, there will ALWAYS be a path, either direct, or indirect
> > > > between the secure net and the internet.
> > >
> > > Other than letting people use secure computers after they have seen the
> > > Internet, a good setup has no indirect paths.
> > 
> > Ha. Hahaha...
> > 
> > Reality bites.
> 
> In the reality I'm familiar with, the defense contractor's secure
> projects building had one entrance, guarded by security guards who were
> not cheap $10/hr guys, with strict instructions.  No computers or
> computer media were allowed to leave the building except with written
> authorization of a corporate officer.  The building was shielded against
> Tempest attacks and verified by the NSA.  Any computer hardware or media
> brought into the building for the project was physically destroyed at
> the end.

That sounds familiar... Doing any of the things mentioned above would (if
detected) result in firing on the spot, loss of security clearance, and a
stunningly bad reference if anyone did an employment check.

Not to mention possible civil or criminal prosecution in some cases.

-- 
bill davidsen <[EMAIL PROTECTED]>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.


signature.asc
Description: This is a digitally signed message part

Re: thoughts on kernel security issues

[John Richard Moser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Bill Davidsen wrote:
> On Thu, 27 Jan 2005, Zan Lynx wrote:
> 
> 
>>On Thu, 2005-01-27 at 10:37 -0600, Jesse Pollard wrote:
>>
>>>On Wednesday 26 January 2005 13:56, Bill Davidsen wrote:
>>>
On Wed, 26 Jan 2005, Jesse Pollard wrote:

>On Tuesday 25 January 2005 15:05, linux-os wrote:
>
>>This isn't relavent [Stuff about the navy][...]
>
>The Navy [...]

[...]Physical network topology[...]
>>>
>>>[...]sneakernet[...]
>>>
>>>
>[...]path[...]

[...]internet[...]
>>>
>>>[...]hahaha[...]
>>
>>[...]NSA[...]
> 
> 
> [...]security clearance[...]
> 

I'll ask again

How the [EMAIL PROTECTED] did the navy get involved in this discussion?

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

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

iD8DBQFB+XrshDd4aOud5P8RAlYQAKCIoi9N6fsNcmjHrT+S5nVptw8sdACfQuZ6
cpAXu20BIaitjRvuqwJq/K4=
=zbim
-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: patches to 2.6.9 and 2.6.10 - make menuconfig shows "v2.6.8.1"

[Viktor Horvath]

On Thu, 2005-01-27 at 22:45 +0100, Timo Kamph wrote:
> I guess you did somthing like this:
> 
> 2.6.7 -patch-> 2.6.8 -patch-> 2.6.8.1 -patch-> 2.6.9 -patch-> 2.6.10.
> 
> And you didn't noticed that the 2.6.9 patch failed, because it is diffed 
> against 2.6.8 and not 2.6.8.1!

You're perfectly right. I thought "patch" would stop and ask me
something, but the error was silently buried under lots of "patching
file" lines.

> If you do the patching without the 2.6.8.1 patch everything should be fine.

It is! Thanks a lot!

Viktor.


signature.asc
Description: This is a digitally signed message part

Re: i8042 access timings

[Dmitry Torokhov]

On Thursday 27 January 2005 17:36, Linus Torvalds wrote:
> > I also tried increasing the total timeout value to about 5 seconds 
> > (versus the default half second), still no success, so the device is 
> > simply not sending back the requested values.
> 
> If it was the other way around (that it works with ACPI _on_), I'd assume 
> that ACPI just disables some broken BIOS SMM emulation code. But I just 
> don't see ACPI _enabling_ SMM emulation. That would be just too strange, 
> and against the whole point of the legacy keyboard emulation stuff - you 
> want to do legacy keyboard emulation if the OS is old, not if it's new.

It is my understanding that ACPI and legacy emulation are to a certain
degree tangent to each other. You can work in ACPI mode and still use USB
legacy emulation and you could be in legacy mode but with USB loaded and
USB legacy emulation turned off.
 
-- 
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: [Bug 4081] New: OpenOffice crashes while starting due to a threading error

[Parag Warudkar]

From strace output which Trever sent, OO.o seems to be getting many 
-EINTRs (Interrupted System Call) which are attempted to be restarted 
but again recieve EINTR when restarted. (futex, accept and poll are the 
ones which get EINTR).

Whereas, when OO.o successfully starts up on my machine, I get no EINTRs 
at all.

Stephen - Is it possible for you to post strace from your machine ? If 
you see the same symptoms we can look at what changed in that area.

Thanks
Parag
Stephen Hemminger wrote:
On my laptop with Fedora Core 3, OpenOffice 1.0.1, 1.0.4 and the pre 2.0 version
all work fine running 2.6.10-FCxx kernel but get a SEGV when running on 
2.6.11-rc1 or 2.6.11-rc2
Any hints?
 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 7/8] pcxx: Remove drivers/char/fep.h

[James Nelson]

This patch removes drivers/char/fep.h

It depends on the previous patches.

Signed-off-by: James Nelson <[EMAIL PROTECTED]>

diff -urN --exclude='*~' linux-2.6.11-rc2-mm1-original/drivers/char/fep.h 
linux-2.6.11-rc2-mm1/drivers/char/fep.h
--- linux-2.6.11-rc2-mm1-original/drivers/char/fep.h2005-01-24 
17:15:56.0 -0500
+++ linux-2.6.11-rc2-mm1/drivers/char/fep.h 1969-12-31 19:00:00.0 
-0500
@@ -1,168 +0,0 @@
-
-#define CSTART   0x400L
-#define CMAX 0x800L
-#define ISTART   0x800L
-#define IMAX 0xC00L
-#define CIN  0xD10L
-#define GLOBAL   0xD10L
-#define EIN  0xD18L
-#define FEPSTAT  0xD20L
-#define CHANSTRUCT   0x1000L
-#define RXTXBUF  0x4000L
-
-
-struct global_data {
-   volatile ushort cin;
-   volatile ushort cout;
-   volatile ushort cstart;
-   volatile ushort cmax;
-   volatile ushort ein;
-   volatile ushort eout;
-   volatile ushort istart;
-   volatile ushort imax;
-};
-
-
-struct board_chan {
-   int filler1; 
-   int filler2;
-   volatile ushort tseg;
-   volatile ushort tin;
-   volatile ushort tout;
-   volatile ushort tmax;
-   
-   volatile ushort rseg;
-   volatile ushort rin;
-   volatile ushort rout;
-   volatile ushort rmax;
-   
-   volatile ushort tlow;
-   volatile ushort rlow;
-   volatile ushort rhigh;
-   volatile ushort incr;
-   
-   volatile ushort etime;
-   volatile ushort edelay;
-   volatile unchar *dev;
-   
-   volatile ushort iflag;
-   volatile ushort oflag;
-   volatile ushort cflag;
-   volatile ushort gmask;
-   
-   volatile ushort col;
-   volatile ushort delay;
-   volatile ushort imask;
-   volatile ushort tflush;
-
-   int filler3;
-   int filler4;
-   int filler5;
-   int filler6;
-   
-   volatile unchar num;
-   volatile unchar ract;
-   volatile unchar bstat;
-   volatile unchar tbusy;
-   volatile unchar iempty;
-   volatile unchar ilow;
-   volatile unchar idata;
-   volatile unchar eflag;
-   
-   volatile unchar tflag;
-   volatile unchar rflag;
-   volatile unchar xmask;
-   volatile unchar xval;
-   volatile unchar mstat;
-   volatile unchar mchange;
-   volatile unchar mint;
-   volatile unchar lstat;
-
-   volatile unchar mtran;
-   volatile unchar orun;
-   volatile unchar startca;
-   volatile unchar stopca;
-   volatile unchar startc;
-   volatile unchar stopc;
-   volatile unchar vnext;
-   volatile unchar hflow;
-
-   volatile unchar fillc;
-   volatile unchar ochar;
-   volatile unchar omask;
-
-   unchar filler7;
-   unchar filler8[28];
-}; 
-
-
-#define SRXLWATER  0xE0
-#define SRXHWATER  0xE1
-#define STOUT  0xE2
-#define PAUSETX0xE3
-#define RESUMETX   0xE4
-#define SAUXONOFFC 0xE6
-#define SENDBREAK  0xE8
-#define SETMODEM   0xE9
-#define SETIFLAGS  0xEA
-#define SONOFFC0xEB
-#define STXLWATER  0xEC
-#define PAUSERX0xEE
-#define RESUMERX   0xEF
-#define SETBUFFER  0xF2
-#define SETCOOKED  0xF3
-#define SETHFLOW   0xF4
-#define SETCTRLFLAGS   0xF5
-#define SETVNEXT   0xF6
-
-
-#define BREAK_IND0x01
-#define LOWTX_IND0x02
-#define EMPTYTX_IND  0x04
-#define DATA_IND 0x08
-#define MODEMCHG_IND 0x20
-
-
-#define RTS   0x02
-#define CD0x08
-#define DSR   0x10
-#define CTS   0x20
-#define RI0x40
-#define DTR   0x80
-
-   /* These are termios bits as the FEP understands them */
-
-/* c_cflag bit meaning */
-#define FEP_CBAUD  017
-#define  FEP_B0000 /* hang up */
-#define  FEP_B50   001
-#define  FEP_B75   002
-#define  FEP_B110  003
-#define  FEP_B134  004
-#define  FEP_B150  005
-#define  FEP_B200  006
-#define  FEP_B300  007
-#define  FEP_B600  010
-#define  FEP_B1200 011
-#define  FEP_B1800 012
-#define  FEP_B2400 013
-#define  FEP_B4800 014
-#define  FEP_B9600 015
-#define  FEP_B19200016
-#define  FEP_B38400017
-#define FEP_EXTA FEP_B19200
-#define FEP_EXTB FEP_B38400
-#define FEP_CSIZE  060
-#define   FEP_CS5  000
-#define   FEP_CS6  020
-#define   FEP_CS7  040
-#define   FEP_CS8  060
-#define FEP_CSTOPB 100
-#define FEP_CREAD  200
-#define FEP_PARENB 400
-#define FEP_PARODD 0001000
-#define FEP_HUPCL  0002000
-#define FEP_CLOCAL 0004000
-#define FEP_CIBAUD 0360/* input baud rate (not used) */
-#define FEP_CRTSCTS  0200  /* flow control */
-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info 

[PATCH 8/8] pcxx: Remove drivers/char/digi_bios.h

[James Nelson]

This patch removes drivers/char/digi_bios.h

It depends on the previous patches.

Signed-off-by: James Nelson <[EMAIL PROTECTED]>

diff -urN --exclude='*~' linux-2.6.11-rc2-mm1-original/drivers/char/digi_bios.h 
linux-2.6.11-rc2-mm1/drivers/char/digi_bios.h
--- linux-2.6.11-rc2-mm1-original/drivers/char/digi_bios.h  2005-01-24 
17:15:56.0 -0500
+++ linux-2.6.11-rc2-mm1/drivers/char/digi_bios.h   1969-12-31 
19:00:00.0 -0500
@@ -1,177 +0,0 @@
-/* DigiBoard PCXX Bios */
-
-static unsigned char pcxx_bios[] __initdata = {
-  0x28,0x43,0x29,0x20,0x43,0x6f,0x70,0x79,0x72,0x69,0x67,0x68,
-  0x74,0x20,0x31,0x39,0x39,0x34,0x2c,0x20,0x44,0x69,0x67,0x69,
-  0x42,0x6f,0x61,0x72,0x64,0x20,0x49,0x6e,0x63,0x2e,0x00,0x00,
-  0x8a,0xf8,0x8a,0xf8,0x15,0xf9,0x8a,0xf8,0x8a,0xf8,0x8a,0xf8,
-  0x8a,0xf8,0x8a,0xf8,0xbc,0xf8,0x8a,0xf8,0x96,0xf8,0x96,0xf8,
-  0x96,0xf8,0x96,0xf8,0x96,0xf8,0x96,0xf8,0x8a,0xf8,0x8a,0xf8,
-  0x96,0xf8,0x96,0xf8,0x8a,0xf8,0xad,0xf8,0xb0,0xf8,0x8a,0xf8,
-  0x8a,0xf8,0x8a,0xf8,0x8a,0xf8,0x8a,0xf8,0x8a,0xf8,0x8a,0xf8,
-  0x8a,0xf8,0x8a,0xf8,0x8a,0xf8,0x04,0x02,0x00,0x02,0x14,0x02,
-  0x10,0x02,0x24,0x02,0x20,0x02,0x34,0x02,0x30,0x02,0x44,0x02,
-  0x40,0x02,0x54,0x02,0x50,0x02,0x64,0x02,0x60,0x02,0x74,0x02,
-  0x70,0x02,0x04,0x01,0x00,0x01,0x1e,0x2e,0x8e,0x1e,0x22,0xf8,
-  0xfe,0x06,0x70,0x00,0x1f,0xcf,0x1e,0x50,0x52,0x2e,0x8e,0x1e,
-  0x22,0xf8,0xfe,0x06,0x71,0x00,0xb8,0x00,0x80,0xba,0x22,0xff,
-  0xef,0x5a,0x58,0x1f,0xcf,0xb4,0x80,0xcf,0x1e,0x2e,0x8e,0x1e,
-  0x22,0xf8,0xfe,0x06,0x2b,0x00,0x1f,0xcf,0x1e,0x52,0x50,0x2e,
-  0x8e,0x1e,0x22,0xf8,0xcd,0x16,0xfe,0x06,0x2a,0x00,0x80,0x3e,
-  0x2a,0x00,0x12,0x72,0x39,0xc6,0x06,0x2a,0x00,0x00,0xfe,0x06,
-  0x29,0x00,0x80,0x3e,0x29,0x00,0x3c,0x72,0x29,0xc6,0x06,0x29,
-  0x00,0x00,0xfe,0x06,0x28,0x00,0x80,0x3e,0x28,0x00,0x3c,0x72,
-  0x19,0xc6,0x06,0x28,0x00,0x00,0xfe,0x06,0x27,0x00,0x80,0x3e,
-  0x27,0x00,0x18,0x72,0x09,0xc6,0x06,0x27,0x00,0x00,0xff,0x06,
-  0x25,0x00,0xba,0x22,0xff,0xb8,0x00,0x80,0xef,0x58,0x5a,0x1f,
-  0xcf,0x60,0x1e,0x06,0xfc,0x2e,0x8e,0x06,0x22,0xf8,0x2e,0x8e,
-  0x1e,0x22,0xf8,0x8d,0x36,0x40,0x00,0xad,0x3c,0x3f,0x7f,0x22,
-  0x3c,0x1f,0x7f,0x22,0x32,0xe4,0xd1,0xe0,0x3d,0x16,0x00,0x90,
-  0x73,0x14,0xbb,0x56,0xf9,0x03,0xd8,0x2e,0xff,0x17,0x8d,0x36,
-  0x40,0x00,0xb0,0x00,0x89,0x04,0x07,0x1f,0x61,0xcf,0xb4,0x80,
-  0xeb,0xf0,0xcd,0x15,0xeb,0xec,0x6c,0xf9,0x79,0xf9,0xb9,0xf9,
-  0xd3,0xf9,0xd8,0xf9,0xe1,0xf9,0xe9,0xf9,0xf2,0xf9,0xfa,0xf9,
-  0xfd,0xf9,0x2a,0xfa,0xe4,0x00,0x24,0xf7,0xe6,0x00,0x0c,0x08,
-  0xe6,0x00,0xb4,0x00,0xc3,0x1e,0xad,0x8b,0xd8,0xad,0x8e,0xdb,
-  0x8b,0xf0,0x33,0xdb,0x8b,0x07,0x3d,0x4f,0x53,0x75,0x2a,0x8a,
-  0x47,0x02,0x32,0xe4,0x86,0xc4,0x8b,0xc8,0x32,0xc0,0x02,0x07,
-  0x43,0xe2,0xfb,0x0a,0xc0,0x75,0x16,0x8c,0xd9,0x1f,0x89,0x0e,
-  0x2e,0x00,0x89,0x36,0x2c,0x00,0x8d,0x1e,0x02,0x00,0xc7,0x07,
-  0x45,0x4d,0x32,0xe4,0xc3,0x1f,0xb4,0x80,0xc3,0xad,0x8b,0xd8,
-  0xad,0x8b,0xd0,0xad,0x8e,0xc0,0xad,0x8b,0xf8,0xad,0x8b,0xc8,
-  0x8b,0xf2,0x1e,0x8e,0xdb,0xf3,0xa4,0x1f,0x32,0xe4,0xc3,0xea,
-  0xf0,0xff,0x00,0xf0,0xad,0x8b,0xd0,0xec,0x88,0x04,0x32,0xe4,
-  0xc3,0xad,0x8b,0xd0,0xac,0xee,0x32,0xe4,0xc3,0xad,0x8b,0xd0,
-  0xed,0x89,0x04,0x32,0xe4,0xc3,0xad,0x8b,0xd0,0xad,0xef,0x32,
-  0xe4,0xc3,0xb4,0x80,0xc3,0xac,0x3c,0x12,0x7f,0x25,0xfe,0xc8,
-  0x32,0xe4,0xd1,0xe0,0x8d,0x1e,0x66,0xf8,0x03,0xd8,0x2e,0x8b,
-  0x17,0xec,0xac,0x3c,0x0f,0x7f,0x10,0x3c,0x00,0x74,0x03,0xee,
-  0x90,0x90,0xec,0x8b,0xfe,0x1e,0x07,0xaa,0x32,0xe4,0xc3,0xb4,
-  0x80,0xc3,0xac,0x3c,0x12,0x7f,0x1f,0xfe,0xc8,0x32,0xe4,0xd1,
-  0xe0,0x8d,0x1e,0x66,0xf8,0x03,0xd8,0x2e,0x8b,0x17,0xec,0xac,
-  0x3c,0x0f,0x7f,0x0a,0x3c,0x00,0x74,0x01,0xee,0xac,0xee,0x32,
-  0xe4,0xc3,0xb4,0x80,0xc3,0xfc,0x8e,0xc0,0xb8,0xff,0xff,0x8b,
-  0xcb,0x33,0xff,0xf3,0xab,0x8b,0xcb,0x33,0xff,0xf3,0xaf,0xe3,
-  0x01,0xc3,0x8b,0xcb,0xbf,0x00,0x00,0x26,0x89,0x3d,0x83,0xc7,
-  0x02,0xe2,0xf8,0xbe,0x00,0x00,0x8b,0xcb,0x26,0x8b,0x3c,0x3b,
-  0xfe,0x74,0x01,0xc3,0x83,0xc6,0x02,0x83,0xc7,0x02,0xe2,0xf0,
-  0x33,0xc0,0x8b,0xcb,0x33,0xff,0xf3,0xab,0x8b,0xcb,0x33,0xff,
-  0xf3,0xaf,0xc3,0x32,0xc0,0x26,0x80,0x3e,0x23,0x00,0x00,0x74,
-  0x02,0x0c,0x01,0x26,0xf7,0x06,0x20,0x00,0x0f,0x00,0x74,0x02,
-  0x0c,0x02,0x26,0xf7,0x06,0x20,0x00,0xf0,0x00,0x74,0x02,0x0c,
-  0x04,0x26,0xf7,0x06,0x20,0x00,0x00,0xff,0x74,0x02,0x0c,0x08,
-  0x26,0xa2,0x24,0x00,0xb8,0x00,0x40,0xba,0x5e,0xff,0xef,0xba,
-  0x66,0xff,0xef,0xba,0x52,0xff,0xb8,0x63,0x0e,0xef,0xba,0x56,
-  0xff,0xb8,0x05,0xe0,0xef,0xba,0x28,0xff,0xb8,0xfc,0x00,0xef,
-  0xb8,0x00,0x02,0x26,0xa3,0x2e,0x00,0xb8,0x04,0x00,0x26,0xa3,
-  0x2c,0x00,0xb0,0xc3,0xe6,0x08,0x8a,0xd8,0xe4,0x08,0x3a,0xc3,
-  0x75,0x06,0x26,0xc6,0x06,0xb4,0x00,0x01,0xb0,0x00,0xe6,0x00,
-  0xfc,0x8d,0x3e,0x00,0x00,0xb8,0x47,0x44,0xab,0xb8,0xff,0xff,
-  0xab,0xab,0xab,0xb8,0x42,0x49,0xab,0xb8,0x4f,0x53,0xab,0xb8,
-  0x58,0x69,0x26,0x80,0x3e,0x10,0x00,0x04,0x74,0x0e,0xb8,0x58,
-  0x65,0x26,0x80,0x3e,0x10,0x00,0x03,0x74,0x03,0xb8,0x58,0x74,
-  

[PATCH 6/8] pcxx: Remove drivers/char/digi_fep.h

[James Nelson]

This patch removes drivers/char/digi_fep.h

It depends on the previous patches.

Signed-off-by: James Nelson <[EMAIL PROTECTED]>

diff -urN --exclude='*~' linux-2.6.11-rc2-mm1-original/drivers/char/digi_fep.h 
linux-2.6.11-rc2-mm1/drivers/char/digi_fep.h
--- linux-2.6.11-rc2-mm1-original/drivers/char/digi_fep.h   2005-01-24 
17:15:56.0 -0500
+++ linux-2.6.11-rc2-mm1/drivers/char/digi_fep.h1969-12-31 
19:00:00.0 -0500
@@ -1,517 +0,0 @@
-/* DigiBoard PCXX Bios */
-
-static unsigned char pcxx_cook[] __initdata = {
-  0x4f,0x53,0x18,0x80,0xe9,0xbf,0x15,0x00,0x40,0x28,0x23,0x29,
-  0x46,0x45,0x50,0x4f,0x53,0x20,0x37,0x2e,0x30,0x38,0x20,0x34,
-  0x2f,0x32,0x30,0x2f,0x39,0x35,0x00,0x40,0x28,0x23,0x29,0x28,
-  0x43,0x29,0x43,0x6f,0x70,0x79,0x72,0x69,0x67,0x68,0x74,0x20,
-  0x31,0x39,0x38,0x39,0x2d,0x31,0x39,0x39,0x35,0x20,0x44,0x69,
-  0x67,0x69,0x42,0x6f,0x61,0x72,0x64,0x20,0x49,0x6e,0x63,0x2e,
-  0x00,0xcb,0x0c,0xcb,0x0c,0xe2,0x0c,0xcb,0x0c,0xcb,0x0c,0xcb,
-  0x0c,0xcb,0x0c,0xcb,0x0c,0x57,0x0c,0xcb,0x0c,0xcb,0x0c,0xcb,
-  0x0c,0x53,0x0b,0xcb,0x0c,0xcb,0x0c,0x42,0x0b,0xcb,0x0c,0xcb,
-  0x0c,0x12,0x0d,0xcb,0x0c,0xcb,0x0c,0xcb,0x0c,0xcb,0x0c,0xcb,
-  0x0c,0xcb,0x0c,0xcb,0x0c,0xcb,0x0c,0xcb,0x0c,0xcb,0x0c,0xcb,
-  0x0c,0xcb,0x0c,0xcb,0x0c,0x00,0x10,0x80,0x10,0x00,0x11,0x80,
-  0x11,0x00,0x12,0x80,0x12,0x00,0x13,0x80,0x13,0x00,0x14,0x80,
-  0x14,0x00,0x15,0x80,0x15,0x00,0x16,0x80,0x16,0x00,0x17,0x80,
-  0x17,0x78,0x0b,0xb9,0x0b,0x50,0x0c,0xb9,0x0b,0x8d,0x0b,0x8d,
-  0x0b,0x8d,0x0b,0x8d,0x0b,0xc0,0x0b,0xc0,0x0b,0xc0,0x0b,0xc0,
-  0x0b,0x8d,0x0b,0x8d,0x0b,0x8d,0x0b,0x8d,0x0b,0x50,0x0c,0xb9,
-  0x0b,0x50,0x0c,0xb9,0x0b,0x8d,0x0b,0x8d,0x0b,0x8d,0x0b,0x8d,
-  0x0b,0xc0,0x0b,0xc0,0x0b,0xc0,0x0b,0xc0,0x0b,0x8d,0x0b,0x8d,
-  0x0b,0x8d,0x0b,0x8d,0x0b,0x94,0x0b,0x94,0x0b,0x94,0x0b,0x94,
-  0x0b,0x94,0x0b,0x94,0x0b,0x94,0x0b,0x94,0x0b,0x94,0x0b,0x94,
-  0x0b,0x94,0x0b,0x94,0x0b,0x94,0x0b,0x94,0x0b,0x94,0x0b,0x94,
-  0x0b,0x94,0x0b,0x94,0x0b,0x94,0x0b,0x94,0x0b,0x94,0x0b,0x94,
-  0x0b,0x94,0x0b,0x94,0x0b,0x94,0x0b,0x94,0x0b,0x94,0x0b,0x94,
-  0x0b,0x94,0x0b,0x94,0x0b,0x94,0x0b,0x94,0x0b,0x16,0x00,0xfe,
-  0x11,0xfe,0x0b,0x2c,0x08,0xb5,0x06,0xfe,0x05,0x7e,0x04,0xfe,
-  0x02,0x7e,0x01,0xbe,0x00,0x7e,0x00,0x5e,0x00,0x2e,0x00,0x16,
-  0x00,0x0a,0x00,0x04,0x00,0x16,0x00,0x02,0x00,0x01,0x00,0x00,
-  0x00,0x0e,0x00,0x06,0x00,0x7e,0x04,0xfe,0x02,0x7e,0x01,0xbe,
-  0x00,0x7e,0x00,0x5e,0x00,0x2e,0x00,0x16,0x00,0x0a,0x00,0x04,
-  0x00,0x18,0x00,0x86,0x13,0x03,0x0d,0xdf,0x08,0x41,0x07,0x81,
-  0x06,0xe0,0x04,0x3f,0x03,0x9f,0x01,0xce,0x00,0x89,0x00,0x66,
-  0x00,0x32,0x00,0x18,0x00,0x0b,0x00,0x0b,0x00,0x18,0x00,0x0b,
-  0x00,0x0b,0x00,0x0b,0x00,0x41,0x07,0x81,0x06,0xe0,0x04,0x3f,
-  0x03,0x9f,0x01,0xce,0x00,0x89,0x00,0x66,0x00,0x32,0x00,0x18,
-  0x00,0x0b,0x00,0x0b,0x00,0x00,0x80,0x40,0xc0,0x1f,0x3f,0x7f,
-  0xff,0x00,0x04,0x02,0x06,0x08,0x0c,0x0a,0x0e,0x00,0x04,0x02,
-  0x06,0x08,0x0c,0x0a,0x0e,0xa0,0x08,0xa0,0x08,0xa0,0x08,0xa0,
-  0x08,0xa0,0x08,0xa0,0x08,0xa0,0x08,0xa0,0x08,0x1e,0x06,0x3e,
-  0x06,0xef,0x06,0xf8,0x05,0x0e,0x06,0x55,0x07,0xa0,0x08,0xa0,
-  0x08,0xa0,0x08,0xa0,0x08,0xa0,0x08,0xa0,0x08,0xa0,0x08,0xa0,
-  0x08,0xa0,0x08,0xa0,0x08,0xa0,0x08,0xa0,0x08,0xa0,0x08,0xa0,
-  0x08,0xa0,0x08,0xa0,0x08,0xa0,0x08,0xa0,0x08,0x9d,0x08,0x9d,
-  0x08,0x9d,0x08,0x9d,0x08,0x9d,0x08,0x9d,0x08,0x9d,0x08,0x9d,
-  0x08,0x9d,0x08,0x9d,0x08,0x9d,0x08,0x9d,0x08,0x9d,0x08,0x9d,
-  0x08,0x9d,0x08,0x9d,0x08,0x9d,0x08,0x9d,0x08,0x9d,0x08,0x9d,
-  0x08,0x9d,0x08,0x9d,0x08,0x9d,0x08,0x9d,0x08,0x9d,0x08,0x9d,
-  0x08,0x9d,0x08,0x9d,0x08,0x9d,0x08,0x9d,0x08,0x9d,0x08,0x9d,
-  0x08,0x9d,0x08,0xa1,0x05,0xa1,0x05,0xa1,0x05,0xa1,0x05,0xa1,
-  0x05,0xa1,0x05,0xa1,0x05,0xa1,0x05,0xa1,0x05,0xa1,0x05,0xa1,
-  0x05,0xa1,0x05,0xa1,0x05,0xa1,0x05,0xa1,0x05,0xa1,0x05,0xa1,
-  0x05,0xa1,0x05,0xa1,0x05,0xa1,0x05,0xa1,0x05,0xa1,0x05,0xa1,
-  0x05,0xa1,0x05,0xa1,0x05,0xa1,0x05,0x9d,0x08,0x9d,0x08,0x9d,
-  0x08,0x9d,0x08,0x9d,0x08,0x5b,0x05,0xea,0x05,0xea,0x05,0xea,
-  0x05,0xea,0x05,0xea,0x05,0xea,0x05,0xea,0x05,0xea,0x05,0xea,
-  0x05,0xea,0x05,0xea,0x05,0xea,0x05,0xea,0x05,0xea,0x05,0xea,
-  0x05,0xea,0x05,0xea,0x05,0xea,0x05,0xea,0x05,0xea,0x05,0xea,
-  0x05,0xea,0x05,0xea,0x05,0xea,0x05,0xea,0x05,0xea,0x05,0x69,
-  0x05,0x77,0x05,0x85,0x05,0x93,0x05,0xa0,0x08,0xa0,0x08,0xa0,
-  0x08,0xa0,0x08,0xa0,0x08,0xa0,0x08,0xa0,0x08,0xa0,0x08,0xa0,
-  0x08,0xa0,0x08,0xa0,0x08,0xa0,0x08,0xa0,0x08,0xa0,0x08,0xa0,
-  0x08,0xa0,0x08,0xa0,0x08,0xa0,0x08,0xa0,0x08,0xa0,0x08,0xa0,
-  0x08,0xa0,0x08,0xa0,0x08,0xa0,0x08,0xa0,0x08,0xa0,0x08,0xa0,
-  0x08,0xa0,0x08,0xa0,0x08,0xa0,0x08,0xa0,0x08,0xa0,0x08,0xa0,
-  0x08,0x9d,0x08,0x9d,0x08,0x9d,0x08,0x9d,0x08,0x9d,0x08,0x9d,
-  0x08,0x9d,0x08,0x9d,0x08,0x9d,0x08,0x9d,0x08,0x9d,0x08,0x9d,
-  0x08,0x9d,0x08,0x9d,0x08,0x9d,0x08,0x9d,0x08,0x9d,0x08,0x9d,
-  0x08,0x9d,0x08,0x9d,0x08,0x9d,0x08,0x9d,0x08,0x9d,0x08,0x9d,
-  0x08,0x9d,0x08,0x9d,0x08,0x9d,0x08,0x9d,0x08,0x9d,0x08,0x9d,
-  

[PATCH 5/8] pcxx: Remove drivers/char/pcxx.h

[James Nelson]

This patch removes drivers/char/pcxx.h

It depends on the previous patches.

Signed-off-by: James Nelson <[EMAIL PROTECTED]>

diff -urN --exclude='*~' linux-2.6.11-rc2-mm1-original/drivers/char/pcxx.h 
linux-2.6.11-rc2-mm1/drivers/char/pcxx.h
--- linux-2.6.11-rc2-mm1-original/drivers/char/pcxx.h   2005-01-24 
17:15:55.0 -0500
+++ linux-2.6.11-rc2-mm1/drivers/char/pcxx.h1969-12-31 19:00:00.0 
-0500
@@ -1,128 +0,0 @@
-#define FEPCODESEG  0x0200L
-#define FEPCODE 0x2000L
-#define BIOSCODE0xf800L
-
-#define MISCGLOBAL  0x0C00L
-#define NPORT   0x0C22L
-#define MBOX0x0C40L
-#define PORTBASE0x0C90L
-
-#define FEPCLR  0x00
-#define FEPMEM  0x02
-#define FEPRST  0x04
-#define FEPINT  0x08
-#defineFEPMASK 0x0e
-#defineFEPWIN  0x80
-
-/* Maximum Number of Boards supported */
-#define MAX_DIGI_BOARDS 4
-
-#define PCXX_NUM_TYPES 4
-
-#define PCXI   0
-#define PCXE   1
-#definePCXEVE  2
-#define PCXEM  3
-
-static char *board_desc[] = {
-   "PC/Xi",
-   "PC/Xe",
-   "PC/Xeve",
-   "PC/Xem",
-};
-
-static char *board_mem[] = {
-   "64k",
-   "64k",
-   "8k",
-   "32k",
-};
-#define STARTC  021
-#define STOPC   023
-#define IAIXON  0x2000
-
-
-struct board_info  {
-   unchar status;
-   unchar type;
-   unchar altpin;
-   ushort numports;
-   ushort port;
-   ulong  membase;
-   ulong  memsize;
-   ushort first_minor;
-   void *region;
-};
-
-
-#define TXSTOPPED   0x01
-#define LOWWAIT0x02
-#define EMPTYWAIT  0x04
-#define RXSTOPPED  0x08
-#define TXBUSY 0x10
-
-#define DISABLED   0
-#define ENABLED1
-#define OFF0
-#define ON 1
-
-#define FEPTIMEOUT 20  
-#define SERIAL_TYPE_NORMAL 1
-#define PCXE_EVENT_HANGUP   1
-#define PCXX_MAGIC 0x5c6df104L
-
-struct channel {
-   /* - 
Board/channel information -- */
-   longmagic;
-   unchar  boardnum;
-   unchar  channelnum;
-   uintdev;
-   struct tty_struct   *tty;
-   struct board_info   *board;
-   volatile struct board_chan  *brdchan;
-   volatile struct global_data *mailbox;
-   int asyncflags;
-   int count;
-   int blocked_open;
-   int close_delay;
-   unsigned long   event;
-   wait_queue_head_t   open_wait;
-   wait_queue_head_t   close_wait;
-   struct work_struct  tqueue;
-   /*  Async 
control data - */
-   unchar  modemfake;  /* 
Modem values to be forced */
-   unchar  modem;  /* 
Force values */
-   ulong   statusflags;
-   unchar  omodem; /* FEP 
output modem status */
-   unchar  imodem; /* FEP 
input modem status */
-   unchar  hflow;
-   unchar  dsr;
-   unchar  dcd;
-   unchar  stopc;
-   unchar  startc;
-   unchar  stopca;
-   unchar  startca;
-   unchar  fepstopc;
-   unchar  fepstartc;
-   unchar  fepstopca;
-   unchar  fepstartca;
-   ushort  fepiflag;
-   ushort  fepcflag;
-   ushort  fepoflag;
-   /* -- 
Transmit/receive system -- */
-   unchar  txwin;
-   unchar  rxwin;
-   ushort  txbufsize;
-   ushort  rxbufsize;
-   unchar  *txptr;
- 

[PATCH 4/8] pcxx: Remove drivers/char/pcxx.c

[James Nelson]

This patch removes drivers/char/pcxx.c

It depends on the previous patches.

Signed-off-by: James Nelson <[EMAIL PROTECTED]>

diff -urN --exclude='*~' linux-2.6.11-rc2-mm1-original/drivers/char/pcxx.c 
linux-2.6.11-rc2-mm1/drivers/char/pcxx.c
--- linux-2.6.11-rc2-mm1-original/drivers/char/pcxx.c   2005-01-24 
17:15:56.0 -0500
+++ linux-2.6.11-rc2-mm1/drivers/char/pcxx.c1969-12-31 19:00:00.0 
-0500
@@ -1,2353 +0,0 @@
-/*
- *  linux/drivers/char/pcxx.c
- * 
- *  Written by Troy De Jongh, November, 1994
- *
- *  Copyright (C) 1994,1995 Troy De Jongh
- *  This software may be used and distributed according to the terms 
- *  of the GNU General Public License.
- *
- *  This driver is for the DigiBoard PC/Xe and PC/Xi line of products.
- *
- *  This driver does NOT support DigiBoard's fastcook FEP option and
- *  does not support the transparent print (i.e. digiprint) option.
- *
- * This Driver is currently maintained by Christoph Lameter ([EMAIL PROTECTED])
- *
- * Please contact digi for support issues at [EMAIL PROTECTED]
- * Some more information can be found at
- * http://lameter.com/digi.
- *
- *  1.5.2 Fall 1995 Bug fixes by David Nugent
- *  1.5.3 March 9, 1996 Christoph Lameter: Fixed 115.2K Support. Memory
- * allocation harmonized with 1.3.X Series.
- *  1.5.4 March 30, 1996 Christoph Lameter: Fixup for 1.3.81. Use init_bh
- * instead of direct assignment to kernel arrays.
- *  1.5.5 April 5, 1996 Major device numbers corrected.
- *  Mike McLagan<[EMAIL PROTECTED]>: Add setup
- *  variable handling, instead of using the old pcxxconfig.h
- *  1.5.6 April 16, 1996 Christoph Lameter: Pointer cleanup, macro cleanup.
- * Call out devices changed to /dev/cudxx.
- *  1.5.7 July 22, 1996 Martin Mares: CLOCAL fix, pcxe_table clearing.
- * David Nugent: Bug in pcxe_open.
- * Brian J. Murrell: Modem Control fixes, Majors correctly assigned
- *  1.6.1 April 6, 1997 Bernhard Kaindl: fixed virtual memory access for 2.1
- *  i386-kernels and use on other archtitectures, Allowing use
- *  as module, added module parameters, added switch to enable
- *  verbose messages to assist user during card configuration.
- *  Currently only tested on a PC/Xi card, but should work on Xe
- *  and Xeve also.
- *  1.6.2 August, 7, 2000: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
- * get rid of panics, release previously allocated resources
- *  1.6.3 August, 23, 2000: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
- * cleaned up wrt verify_area.
- *  Christoph Lameter: Update documentation, email addresses
- *  and URLs. Remove some obsolete code.
- *
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#ifndef MODULE
-#include  /* We only need it for parsing the "digi="-line */
-#endif
-
-#include 
-#include 
-#include 
-#include 
-
-#define VERSION"1.6.3"
-
-#include "digi.h"
-#include "fep.h"
-#include "pcxx.h"
-#include "digi_fep.h"
-#include "digi_bios.h"
-
-/*
- * Define one default setting if no digi= config line is used.
- * Default is altpin = disabled, 16 ports, I/O 200h, Memory 0Dh
- */
-static struct board_info boards[MAX_DIGI_BOARDS] = { {
-/* Board is enabled   */   ENABLED,
-/* Type is auto-detected  */   0,
-/* altping is disabled*/DISABLED,
-/* number of ports = 16   */   16,
-/* io address is 0x200*/   0x200,
-/* card memory at 0xd */   0xd,
-/* first minor device no. */   0
-} };
- 
-static int verbose = 0;
-static int debug   = 0;
-
-#ifdef MODULE
-/* Variables for insmod */
-static int io[]   = {0, 0, 0, 0};
-static int membase[]  = {0, 0, 0, 0};
-static int memsize[]  = {0, 0, 0, 0};
-static int altpin[]   = {0, 0, 0, 0};
-static int numports[] = {0, 0, 0, 0};
-
-MODULE_AUTHOR("Bernhard Kaindl");
-MODULE_DESCRIPTION("Digiboard PC/X{i,e,eve} driver");
-MODULE_LICENSE("GPL");
-module_param(verbose, bool, 0644);
-module_param(debug,   bool, 0644);
-module_param_array(io,  int, NULL, 0);
-module_param_array(membase, int, NULL, 0);
-module_param_array(memsize, int, NULL, 0);
-module_param_array(altpin,  int, NULL, 0);
-module_param_array(numports,int, NULL, 0);
-
-#endif /* MODULE */
-
-static int numcards = 1;
-static int nbdevs = 0;
- 
-static struct channel*digi_channels;
- 
-int pcxx_ncook=sizeof(pcxx_cook);
-int pcxx_nbios=sizeof(pcxx_bios);
-
-#define pcxxassert(x, msg)  if(!(x)) pcxx_error(__LINE__, msg)
-
-#define FEPTIMEOUT 20  
-#define SERIAL_TYPE_NORMAL 1
-#define PCXE_EVENT_HANGUP   1
-
-static struct tty_driver *pcxe_driver;
-
-static struct timer_list pcxx_timer;
-
-static void pcxxpoll(unsigned long dummy);
-static 

[PATCH 2/8] pcxx: Remove reference in drivers/char/Kconfig

[James Nelson]

This patch removes references to the pcxx driver in drivers/char/Kconfig

It depends on the previous patch.

Signed-off-by: James Nelson <[EMAIL PROTECTED]>

diff -urN --exclude='*~' linux-2.6.11-rc2-mm1-original/drivers/char/Kconfig 
linux-2.6.11-rc2-mm1/drivers/char/Kconfig
--- linux-2.6.11-rc2-mm1-original/drivers/char/Kconfig  2005-01-24 
17:15:55.0 -0500
+++ linux-2.6.11-rc2-mm1/drivers/char/Kconfig   2005-01-27 16:27:32.0 
-0500
@@ -161,26 +161,9 @@
  you have a card like this, say Y here and read the file
  .
 
- NOTE: There is another, separate driver for the Digiboard PC boards:
- "Digiboard PC/Xx Support" below. You should (and can) only select
- one of the two drivers.
-
  To compile this driver as a module, choose M here: the
  module will be called epca.
 
-config DIGI
-   tristate "Digiboard PC/Xx Support"
-   depends on SERIAL_NONSTANDARD && DIGIEPCA=n && BROKEN_ON_SMP
-   help
- This is a driver for the Digiboard PC/Xe, PC/Xi, and PC/Xeve cards
- that give you many serial ports. You would need something like this
- to connect more than two modems to your Linux box, for instance in
- order to become a dial-in server. If you have a card like that, say
- Y here and read the file .
-
- To compile this driver as a module, choose M here: the
- module will be called pcxx.
-
 config ESPSERIAL
tristate "Hayes ESP serial port support"
depends on SERIAL_NONSTANDARD && ISA && BROKEN_ON_SMP
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 3/8] pcxx: Remove reference in drivers/char/Makefile

[James Nelson]

This patch removes references to the pcxx driver drivers/char/Makefile

It depends on the previous patches.

Signed-off-by: James Nelson <[EMAIL PROTECTED]>

diff -urN --exclude='*~' linux-2.6.11-rc2-mm1-original/drivers/char/Makefile 
linux-2.6.11-rc2-mm1/drivers/char/Makefile
--- linux-2.6.11-rc2-mm1-original/drivers/char/Makefile 2005-01-24 
17:15:56.0 -0500
+++ linux-2.6.11-rc2-mm1/drivers/char/Makefile  2005-01-27 16:27:03.0 
-0500
@@ -28,7 +28,6 @@
 obj-$(CONFIG_CYCLADES) += cyclades.o
 obj-$(CONFIG_STALLION) += stallion.o
 obj-$(CONFIG_ISTALLION)+= istallion.o
-obj-$(CONFIG_DIGI) += pcxx.o
 obj-$(CONFIG_DIGIEPCA) += epca.o
 obj-$(CONFIG_SPECIALIX)+= specialix.o
 obj-$(CONFIG_MOXA_INTELLIO)+= moxa.o
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: i8042 access timings

[Andries Brouwer]

> > Only the ready flag was lost.

> No, note that if there was valid data we would see 0xa5 instead of
> 0x5a that was in the buffer - because in i8042_command we invert data
> coming from AUX port.

We misunderstand each other.

Let me repeat. The following happens:
We wait, then write d3, wait, then write 5a, wait for input, timeout.
We wait, then write a9, wait for input, read 5a from AUXB.
(That 5a is inverted to a5 to signal that it came from AUXB.)

Of course, that 5a is the result of the 5a that we sent via the d3 command.
But why does that command time out? For some reason the information
that there is a byte ready to be read was not transmitted to the status
register. But as soon as we gave another command, a9 in this case,
this system remembered that something was ready, and set the appropriate
status bit.

One might experiment a little - see for example whether other commands
than a9 suffice in "waking the kbd controller".

All is fine, only the flag was lost, nobody knows why.
Maybe just because the d3 implementation is buggy.
That has been seen more often.

But there is another part that we must think about - the fragment

i8042_check_aux()
drivers/input/serio/i8042.c: Interrupt 12, without any data [9]
i8042_flush()


Andries


By the way, we should remove this silly response byte inversion
and just store a separate bit.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 bus association

[Randy.Dunlap]

Pierre Ossman wrote:
I recently tried out adding PNP support to my driver to remove the 
hassle of finding the correct parameters for it. This, however, causes 
it to show up under the pnp bus, where as it previously was located 
under the platform bus.

Is the idea that PNP devices should only reside on the PNP bus or is 
there some magic available to get the device to appear on several buses? 
It's a bit of a hassle to search in two different places in sysfs 
depending on if PNP is used or not.

Also, the PNP bus doesn't really say that much about where the device is 
physically connected. The other bus types usually give a hint about this.
Not to take away from your question, but:
Is there "the PNP bus"?  I've seen an ISA bus that (sort of)
supports PNP, PCI PNP, NuBus PNP, USB PNP, IEEE 1394 PNP, etc.
--
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Applications segfault on evo n620c with 2.6.10

[Nigel Cunningham]

Hi.

On Fri, 2005-01-28 at 10:01, Pavel Machek wrote:
> Yes, it happened even in cases when machine was not ever suspended. I
> guess I should also add that kernel is "tainted: pavel", (that means I
> have my own patches in; but I really believe that my changes are not
> responsible).

I often believe that too ;>

Nigel
-- 
Nigel Cunningham
Software Engineer
Cyclades Corporation

http://cyclades.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/

Logitech Cordeless Desktop Keyboard fails to report class descriptor

[Nico Huber]

The receiver of my Logitech Cordeless Desktop fails to report the 
keyboard's class  descriptor most times I insert the usb-hid module 
since I changed to linux 2.6. The modell of the receiver is C-BD9-DUAL 
REV C.
The request seems not to fail but the count of received characters is zero.

As I said it only fails most times, I worked around making the following 
changes in drivers/usb/input/hid-core.c from linux-2.6.11-rc2:

Following the good example of drivers/usb/core/message.c line 575, I 
initialized the buffer in hid_get_class_descriptor() to zero.
In the loop of hid_get_class_descriptor() not waiting for any result but 
waiting for a result wich is lower the requested size of the class 
descriptor (line 1290).
usb_hid_configure() should not try to parse the expected length but the 
received (line 1653).

attached is a patch to linux-2.6.11-rc2 with these changes
Nico Huber
.
--- a/drivers/usb/input/hid-core.c  2005-01-27 23:59:52.0 +0100
+++ b/drivers/usb/input/hid-core.c  2005-01-28 00:06:31.0 +0100
@@ -1282,12 +1282,15 @@
unsigned char type, void *buf, int size)
 {
int result, retries = 4;
+
+   memset(buf,0,size); // Make sure we parse really received data
+
do {
result = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
USB_REQ_GET_DESCRIPTOR, USB_RECIP_INTERFACE | 
USB_DIR_IN,
(type << 8), ifnum, buf, size, HZ * 
USB_CTRL_GET_TIMEOUT);
retries--;
-   } while (result < 0 && retries);
+   } while (result < size && retries);
return result;
 }
 
@@ -1650,7 +1653,7 @@
printk("\n");
 #endif
 
-   if (!(hid = hid_parse_report(rdesc, rsize))) {
+   if (!(hid = hid_parse_report(rdesc, n))) {
dbg("parsing report descriptor failed");
kfree(rdesc);
return NULL;

Re: [PATCH 1/1] pci: Block config access during BIST (resend)

[Benjamin Herrenschmidt]

On Thu, 2005-01-27 at 15:53 +, Alan Cox wrote:
> On Mer, 2005-01-26 at 22:10, Benjamin Herrenschmidt wrote:
> > On Wed, 2005-01-26 at 10:34 -0600, Brian King wrote:
> > Well, I honestly think that this is unnecessary burden. I think that
> > just dropping writes & returning data from the cache on reads is enough,
> > blocking userspace isn't necessary, but then, I may be wrong ;)
> 
> Providing the BARs, cmd register and bridge VGA_EN are cached then I
> think you
> are right.

There might be one problem with dropping of writes tho, which has to
do with userland like X doing VGA flip-flip (VGA_EN on bridges and
CMD_IO on devices). But I think that's a non-issues because:

 - For now, nobody is using this interface to hide a VGA device or a
bridge, and I don't see that happening in the near future

 - Eventually, the control of who owns VGA is to be moved to a kernel
driver doing proper arbitration as we discussed previously on several
lists. (BTW. Alan, I've been a bit out of touch with that and Jon is too
busy lately, do you know if there  have been progress or at least
prototype code one could take over from for that ?)

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 patch] #ifdef ACPI_FUTURE_USAGE acpi_ut_create_pkg_state_and_push

[Len Brown]

Applied.

thanks,
-Len

On Thu, 2005-01-27 at 06:04, Adrian Bunk wrote:
> The prototype of the unused global function
> acpi_ut_create_pkg_state_and_push was already #ifdef
> ACPI_FUTURE_USAGE'd, but the actual function wasn't.
> 
> Most likely this was a bug in my patch that added
> ACPI_FUTURE_USAGE.
> 
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> 
> ---
> linux-2.6.11-rc2-mm1-full/drivers/acpi/utilities/utmisc.c.old  
> 2005-01-26 22:31:11.0 +0100
> +++ linux-2.6.11-rc2-mm1-full/drivers/acpi/utilities/utmisc.c  
> 2005-01-26 22:40:40.0 +0100
> @@ -872,7 +885,7 @@
>   * DESCRIPTION: Create a new state and push it
>   *
>  
> **/
> -
> +#ifdef ACPI_FUTURE_USAGE
>  acpi_status
>  acpi_ut_create_pkg_state_and_push (
> void*internal_object,
> @@ -894,7 +907,7 @@
> acpi_ut_push_generic_state (state_list, state);
> return (AE_OK);
>  }
> -
> +#endif  /*  ACPI_FUTURE_USAGE  */
> 
>  
> /***
>   *
> 
> 
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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-rc2-mm1: kernel bad access while booting diskless client

[Albert Herranz]

 --- Andreas Gruenbacher <[EMAIL PROTECTED]> escribió: 
> Hello again,
> 
> this looks like a good candidate. Could you please
> try if it fixes the
> problem?

The Oops went away with this one.

> Thanks,

Your welcome.

Cheers,
Albert




__ 
Renovamos el Correo Yahoo!: ¡250 MB GRATIS! 
Nuevos servicios, más seguridad 
http://correo.yahoo.es
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: patches to 2.6.9 and 2.6.10 - make menuconfig shows "v2.6.8.1"

[Ken Moffat]

On Thu, 27 Jan 2005, Viktor Horvath wrote:

> Hello everybody,
>
> today I patched myself up from 2.6.7 vanilla to 2.6.10 vanilla, but
> after all patches succeeded, "make menuconfig" shows "v2.6.8.1
> Configuration". Even worse, a compiled kernel calls in his bootlog
> himself "2.6.8.1". When installing the whole kernel package, this
> behaviour doesn't show up.
>

 Looks like you went 2.6.7, 2.6.8, 2.6.8.1 - you didn't *need* 2.6.8.1,
2.6.9 is against 2.6.8 not 2.6.8.1.  So, when you applied 2.6.9 you got
rejections (at a minimum, the top level Makefile, but the other stuff
from 2.6.8.1 should have rejected because it had already been applied).
>From there onwards, the top level Makefile still contains the 2.6.8.1
version info and doesn't match what the next patch is looking to change.

 Whenever you apply patches, you need to make sure there are no errors!
e.g. use 'find' to look for '*.rej' files.

Ken
-- 
 das eine Mal als Tragödie, das andere Mal als Farce

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

Re: [RFC: 2.6 patch] drivers/acpi/: possible cleanups

[Len Brown]

On Thu, 2005-01-27 at 06:01, Adrian Bunk wrote:
> Before I'm getting flamed to death:
> This patch isn't meant for being immediately applied.
> 
> This patch makes all needlessly global code under drivers/acpi/
> static.
> Please review this patch.

Thanks for the patch Adrian.

I agree that this is the right direction to go -- enforcing APIs with
the use of static reduces the possibility of programming errors --
particularly with many cooks in the kitchen.  Indeed, just on Monday we
discussed a patch from Alexey Starikovskiy to do the same thing.

The problem is one of logistics.
As I've described before, the files with "R. Byron Moore" at the top are
dual-licensed so Intel can distribute the core interpreter both as GPL
to Linux and also to FreeBSD, HP-UX etc.

Yes, GPL is GPL and that gives the Linux community the right to do
whatever is needed to those files.  But patches accepted to the core
interpreter under GPL can not be applied to the upstream interpreter --
so they're effectively a fork that code.

We've forked in other areas, the largest is your FUTURE_USAGE patch
which I accepted.  But forks have a non-zero cost on me, and I have a
big enough task trying to make Linux/ACPI the best implementation
possible without getting sidetracked by avoidable logisital challenges. 
So here is what I propose.

I've already asked Bob Moore to migrate to the use of static in the
interpreter.  There are some somewhat urgent functional issues he needs
to focus on first, but static is on the list.  If we allow him to do it
upstream (w/o looking at your patch), then we can avoid a fork in the
core interpreter code.

At the same time, the non "R. Byron Moore" files, such as those in
drivers/acpi, but not in the lower sub-directories, are straight GPL and
I'll be happy to accept patches to those files immediately.  Note that
there are 4 straight GPL files in include/acpi as well -- so like the
drivers/acpi/* files, we can modify them any time when cleanups are
appropriate in the Linux release cycle.

thanks,
-Len


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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-rc2 TCP ignores PMTU ICMP (Re: Linux 2.6.11-rc2)

[David Brownell]

I just got an interesting "I see these problems too" report.  It
may provide a useful clue.  According to "Art Haas" <[EMAIL PROTECTED]>:

> I'm running the current BK kernel now, and I'm not seeing the problems
> right now because, I found, I do not have some of the IP masquerading
> modules installed on my machine. When these modules get installed then
> the cvs/rsync problems appear. 
 
I do have CONFIG_IP_NF_TARGET_MASQUERADE=y on the system where I'm
seeing this, though it's not doing anything just now.  Haven't yet
made time to see if disabling it improves things ... but if that's
a factor, it could explain why more people aren't suffering with
this problem.

- 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-rc2-mm1: kernel bad access while booting diskless client

[Andreas Gruenbacher]

Hello again,

this looks like a good candidate. Could you please try if it fixes the
problem?

Thanks,
-- 
Andreas Gruenbacher <[EMAIL PROTECTED]>
SUSE Labs, SUSE LINUX GMBH
--- Begin Message ---
This pattern from 2.4 times doesn't work very well anymore :(

Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>

Index: linux-2.6.11-latest/fs/nfs/inode.c
===
--- linux-2.6.11-latest.orig/fs/nfs/inode.c
+++ linux-2.6.11-latest/fs/nfs/inode.c
@@ -688,7 +688,7 @@ nfs_init_locked(struct inode *inode, voi
 #define NFS_LIMIT_READDIRPLUS (8*PAGE_SIZE)
 
 #ifdef CONFIG_NFS_ACL
-static struct inode_operations nfs_special_inode_operations[] = {{
+static struct inode_operations nfs_special_inode_operations = {
.permission =   nfs_permission,
.getattr =  nfs_getattr,
.setattr =  nfs_setattr,
@@ -696,9 +696,7 @@ static struct inode_operations nfs_speci
.getxattr = nfs_getxattr,
.setxattr = nfs_setxattr,
.removexattr =  nfs_removexattr,
-}};
-#else
-#define nfs_special_inode_operations NULL
+};
 #endif  /* CONFIG_NFS_ACL */
 
 /*
@@ -755,7 +753,9 @@ nfs_fhget(struct super_block *sb, struct
} else if (S_ISLNK(inode->i_mode))
inode->i_op = _symlink_inode_operations;
else {
-   inode->i_op = nfs_special_inode_operations;
+#ifdef CONFIG_NFS_ACL
+   inode->i_op = _special_inode_operations;
+#endif
init_special_inode(inode, inode->i_mode, fattr->rdev);
}
 
--- End Message ---

Re: Applications segfault on evo n620c with 2.6.10

[Pavel Machek]

Hi!

> > Unfortunately I do not know how to reproduce it. I tried
> > parallel-building kernels for few hours and that worked okay. Swsusp
> > is not involved (but usb, bluetooth, acpi and sound may be).
> 
> I take it you're sure suspending is not involved because it happens
> before you've ever suspended? If you hadn't said that, I'd say it sounds
> very much like something suspend related.

Yes, it happened even in cases when machine was not ever suspended. I
guess I should also add that kernel is "tainted: pavel", (that means I
have my own patches in; but I really believe that my changes are not
responsible).
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] scsi/sata write barrier support

[Jeff Garzik]

Doug Maxey wrote:
On Thu, 27 Jan 2005 13:02:48 +0100, Jens Axboe wrote:
Hi,
For the longest time, only the old PATA drivers supported barrier writes
with journalled file systems. This patch adds support for the same type
of cache flushing barriers that PATA uses for SCSI, to be utilized with
libata. 

What, if any mechanism supports changing the underlying write cache?  

That is, assuming this is common across PATA and SCSI drives, and it is 
possible to turn the cache off on the IDE drives, would switching the 
cache underneath require completing the inflight IO?
[ignoring your question, but it made me think...]
I am thinking the barrier support should know if the write cache is 
disabled (some datacenters do this), and avoid flushing if so?

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/