On Fri, 2005-01-28 at 23:12 +0100, Lorenzo Hernndez Garca-Hierro
wrote:
El vie, 28-01-2005 a las 21:47 +0100, Arjan van de Ven escribi:
as for obsd_get_random_long().. would it be possible to use the
get_random_int() function from the patches I posted the other day? They
use the existing
On Fri, 2005-01-28 at 23:12 +0100, Lorenzo Hernndez Garca-Hierro
wrote:
El vie, 28-01-2005 a las 21:47 +0100, Arjan van de Ven escribi:
as for obsd_get_random_long().. would it be possible to use the
get_random_int() function from the patches I posted the other day? They
use the existing
Tom Zanussi [EMAIL PROTECTED] writes:
Hi,
This patch is the result of the latest round of liposuction on relayfs
- the patch size is now 44K, down from 110K and the 200K before that.
I'm posting it as a patch against 2.6.10 rather than -mm in order to
make it easier to review, but will
I actually just tried to paxtest a fresh Fedora Core 3, unadultered,
that I installed, and it FAILED every test. After a while, spender
reminded me about PT_GNU_STACK. It failed everything but the Executable
Stack test after execstack -c *. The randomization tests gave
13(heap-etexec),
It is nice to know all that. I guess I did not know much about
the other 64 bit systems. I will update and resend my patch.
Thanks!
Chris
On Fri, Jan 28, 2005 at 09:45:38PM -0800, Roland Dreier wrote:
Christopher This patch is for the case that running 32 bit
Christopher application
On Thu, Jan 27, 2005 at 03:45:40PM -0500, Jeff Garzik wrote:
(GregKH cc'd for his deprecated list)
It's a file in the Documentation/ directory, feel free to just patch it,
adding entries for these drivers.
thanks,
greg k-h
-
To unsubscribe from this list: send the line unsubscribe
On Fri, Jan 28, 2005 at 01:38:22PM -0600, Tom Zanussi wrote:
+extern void * alloc_rchan_buf(unsigned long size,
+ struct page ***page_array,
+ int *page_count);
+extern void free_rchan_buf(void *buf,
+struct page
On Sat, Jan 29, 2005 at 07:33:31AM +0100, Andi Kleen wrote:
Looks reasonable from a first look.
Issues:
- Should use CONFIG_COMPAT, not x86-64 specific symbols
Agree.
- Why can't you set URB_COMPAT transparently in the emulation
layer? Then existing applications would hopefully work
On Fri, Jan 28, 2005 at 11:55:13AM -0500, Pavel Roskin wrote:
Hello!
make menuconfig for x86_64 looks somewhat funky:
[ ] Provide RTC interrupt (NEW)
I will move that thanks.
Code maturity level options ---
General setup ---
...
I believe all x86_64 specific options for
On Fri, 28 Jan 2005 21:47:45 +0100, Arjan van de Ven said:
as for obsd_get_random_long().. would it be possible to use the
get_random_int() function from the patches I posted the other day? They
use the existing random.c infrastructure instead of making a copy...
I still don't understand
[ Reading just long long thread (actually from
gmane.comp.emulators.wine.devel) ]
[EMAIL PROTECTED]
Linus Torvalds [EMAIL PROTECTED]:
+
+ /*
+ * Was the TF flag set by a debugger? If so, clear it now,
+ * so that register information is correct.
+
On Sat, Jan 29, 2005 at 07:33:31AM +0100, Andi Kleen wrote:
Issues:
- Should use CONFIG_COMPAT, not x86-64 specific symbols
Fixed.
- Why can't you set URB_COMPAT transparently in the emulation
layer? Then existing applications would hopefully work without
changes, right?
Now I see it. That
There is no point in setting ra-prev_page before 'goto out',
it will be overwritten anyway.
Signed-off-by: Oleg Nesterov [EMAIL PROTECTED]
--- 2.6.11-rc2/mm/readahead.c~ Wed Jan 12 11:44:55 2005
+++ 2.6.11-rc2/mm/readahead.c Mon Jan 24 20:19:38 2005
@@ -432,7 +432,6 @@
get_next_ra_size() can get all info from file_ra_state.
Signed-off-by: Oleg Nesterov [EMAIL PROTECTED]
--- 2.6.11-rc2/mm/readahead.c~ 2005-01-26 19:29:49.0 +0300
+++ 2.6.11-rc2/mm/readahead.c 2005-01-27 22:14:39.0 +0300
@@ -85,14 +85,16 @@ static unsigned long
This patch introduces make_ahead_window() function for
simplification of page_cache_readahead.
Signed-off-by: Oleg Nesterov [EMAIL PROTECTED]
--- 2.6.11-rc2/mm/readahead.c~ 2005-01-27 22:14:39.0 +0300
+++ 2.6.11-rc2/mm/readahead.c 2005-01-29 15:51:04.0 +0300
@@ -406,6 +406,37
On Sat, Jan 29, 2005 at 07:46:05AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
In article [EMAIL PROTECTED] (at Sat, 29 Jan 2005 09:19:49 +1100), Herbert
Xu [EMAIL PROTECTED] says:
IMHO you need to give the user a way to specify which table they want
to operate on. If they don't
I think that do_page_cache_readahead() can be inlined
in blockable_page_cache_readahead(), this makes the
code a bit more readable in my opinion.
Also makes check_ra_success() static inline.
Signed-off-by: Oleg Nesterov [EMAIL PROTECTED]
--- 2.6.11-rc2/mm/readahead.c~ 2005-01-29
This patch introduces make_ahead_window() function for
simplification of page_cache_readahead.
If you will count this patch acceptable, I'll rediff it against
next mm iteration.
For your convenience here is the code with the patch applied.
int make_ahead_window(mapping, filp, ra, int force)
{
Hi Marcelo, hi all,
I have a number of I2C updates for 2.4.29 waiting. All of them are
rather small and independent, gathered during the 2.4.28 cycle and
already applied to i2c CVS.
Individual patches follow, please apply.
Thanks.
--
Jean Delvare
http://khali.linux-fr.org/
-
To unsubscribe
Original reports and discussion:
http://archives.andrew.net.au/lm-sensors/msg28512.html
http://archives.andrew.net.au/lm-sensors/msg28581.html
Bottom line:
The bit and pcf i2c algorithms should declare themselves fully I2C
capable, but do not.
Credits go to Ian Campbell for noticing and
Hi Neil,
Given that the purpose of this order-5 allocation is to provide
storage for 1024 struct svc_cacherep structs, it would seem that a
better approach would be to just do 1024 kmallocs.
I'll try to knock a patch together in next week sometime.
That works for me.
Anton
-
To
While editing i2c-algo-bit.c and i2c-algo-pcf.c (see 1/3 of this patch
set), I noticed that both files include header files they do not need at
all (namely linux/ioport.h and asm/uaccess.h). The following patch
cleans this, additionally bringing the files in line with what we have
in i2c CVS (thus
On Tue, Jan 11, 2005 at 04:07:09PM -0800, Linus Torvalds wrote:
On Tue, 11 Jan 2005, Russell King wrote:
Any responses on this? Didn't get any last time I mailed this out.
I don't have any real objections. I'd like it verified that gcc can
compile away all the overhead on the architectures
Original discussion:
http://archives.andrew.net.au/lm-sensors/msg29038.html
http://archives.andrew.net.au/lm-sensors/msg29041.html
Bottom line:
The id member of the i2c_client structure was discarded in Linux 2.6
due to a lack of consistent use and overall need. While we of course
won't backport
On Fri, 28 Jan 2005 15:57:13 -0800, Stephen Hemminger wrote:
Note: on 2.6.10
/dev/dri/card0 crw-rw-rw-
on 2.6.11-rc2
/dev/dri/card0 crw-rw
/dev/dri/card1 crw-rw
Changing permissions seems to fix (it for startup), will try more and see
if udev remembers not to
Hi,
On Fri, 28 Jan 2005, Vojtech Pavlik wrote:
I'm very sorry about the locking, but the thing grew up in times of
kernel 2.0, which didn't require any locking. There are a few possible
races with device registration/unregistration, and it's on my list to
fix that, however under normal
In article [EMAIL PROTECTED] you wrote:
stat64(/dev/dri/card14, 0xbff9c8bc) = -1 ENOENT (No such file or
directory)
What is at fault? Certainly oo shouldn't just seg-fault, but should the
permissions on /dev/dri/card* be crw-rw or crw-rw-rw-?
it is not a permission thing, it tells
On Sat, 29 Jan 2005 12:49:16 +, Richard Hughes wrote:
Note, that strace glxgears gives exactly the same output, going from 0 to
14 and then seg-faulting, so it's *not just a oo problem*.
I know it's bad to answer your own post, but here goes.
I changed my
This patch contains the following cleanups:
- make the needlessly global struct aoe_fops static
- #if 0 the unused global function aoechr_hdump
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/block/aoe/aoechr.c |6 +-
1 files changed, 5 insertions(+), 1 deletion(-)
---
This patch makes some needlessly global code static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
--- linux-2.6.11-rc2-mm1-full/drivers/block/cfq-iosched.c.old 2005-01-29
14:05:30.0 +0100
+++ linux-2.6.11-rc2-mm1-full/drivers/block/cfq-iosched.c 2005-01-29
14:05:49.0
The patch below does the following cleanups in each if the five changed
C files:
- #ifndef MODULE: remove unused setup function
- make a needlessly global struct static
- pf.c: pf_init_units can be static and __init
After this cleanup, setup.h is completely unuse and therefore removed.
This patch makes a needlessly global struct static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
--- linux-2.6.11-rc2-mm1-full/drivers/block/deadline-iosched.c.old
2005-01-29 14:07:00.0 +0100
+++ linux-2.6.11-rc2-mm1-full/drivers/block/deadline-iosched.c 2005-01-29
Pierre Ossman wrote:
Geert Uytterhoeven wrote:
MMC_WBSD depends on ISA (needs isa_virt_to_bus())
Thanks. Shouldn't have missed something so obvious :)
Russell, can you fix this in your next merge?
Russell, please undo this patch. isa_virt_to_bus() is not dependent on
CONFIG_ISA. It causes
This patch contains the following cleanups:
- make some needlesly global code static
- cciss_scsi.c: remove the unused global function cciss_scsi_info
- cciss.c:
- init_cciss_module - cciss_init
- cleanup_cciss_module - cciss_cleanup
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
On Sat, Jan 29, 2005 at 02:37:39PM +0100, Pierre Ossman wrote:
Pierre Ossman wrote:
Geert Uytterhoeven wrote:
MMC_WBSD depends on ISA (needs isa_virt_to_bus())
Thanks. Shouldn't have missed something so obvious :)
Russell, can you fix this in your next merge?
Russell, please
On Fri, Jan 28, 2005 at 12:06:19PM -0700, Zwane Mwaikambo wrote:
= drivers/oprofile/oprofile_files.c 1.7 vs edited =
--- 1.7/drivers/oprofile/oprofile_files.c 2005-01-04 19:48:23 -07:00
+++ edited/drivers/oprofile/oprofile_files.c 2005-01-28 11:36:25 -07:00
@@ -63,7 +63,9 @@
Hi,
I would like to know how many groups of system calls are there at Linux
2.4 and 2.6? Where can I find these informations in the Kernel?
Best Regards,
Rodrigo Ramos
www.triforsec.com.br
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
On Sat, 2005-01-29 at 11:37 +, Russell King wrote:
Thanks for the response. However, apart from Ralph, Paul and yourself,
it seems none of the other architecture maintainers care about this
patch - the original mail was BCC'd to the architecture list. Maybe
that's an implicit acceptance
-Original Message-
From: Andrew Morton [mailto:[EMAIL PROTECTED]
Subject: Re: [Discuss][i386] Platform SMIs and their
interferance with tsc based delay calibration
Please don't send emails which contain 500-column lines?
Sorry. Something got messed up during cut and paste onto my
-Original Message-
From: Andi Kleen [mailto:[EMAIL PROTECTED]
Sent: Friday, January 28, 2005 10:24 PM
To: Pallipadi, Venkatesh
Cc: Seth, Rohit; Mallick, Asit K;
linux-kernel@vger.kernel.org; [EMAIL PROTECTED]
Subject: Re: [Discuss][i386] Platform SMIs and their
interferance with tsc
I wouldn't have noticed this at all since you didn't send it to the scsi
list, but fortunately, Al Viro drew it politely to my attention as
another example of SCSI refcounting problems.
The issue seems to be that we have a spurious scsi_cd_put() on the error
path of sr_open(). The sr_block_..()
Christoph, did you mean to add anything?
On Sat, Jan 29, 2005 at 01:57:14PM +, Christoph Hellwig wrote:
On Sat, Jan 29, 2005 at 02:37:39PM +0100, Pierre Ossman wrote:
Pierre Ossman wrote:
Geert Uytterhoeven wrote:
MMC_WBSD depends on ISA (needs isa_virt_to_bus())
Thanks.
On Sat, Jan 29, 2005 at 02:54:17PM +, Russell King wrote:
Christoph, did you mean to add anything?
Yes, this somehow got lost:
-
Russell, please undo this patch. isa_virt_to_bus() is not dependent on
CONFIG_ISA. It causes problems on x86_64 platforms which cannot enable
ISA
On Sat, Jan 29, 2005 at 03:00:23PM +, Christoph Hellwig wrote:
Either way a new driver shouldn't use isa_virt_to_bus at all but rather
use the proper DMA API and all those problems go away.
One thing which comes up in this instance is: what struct device should
be used.
With ISA devices
On Sat, Jan 29, 2005 at 03:13:46PM +, Russell King wrote:
One thing which comes up in this instance is: what struct device should
be used.
Current convention is to use a NULL device, it's from pre-generic
DMA times were only the pci_* types existed.
-
To unsubscribe from this list: send
Christoph Hellwig wrote:
Russell, please undo this patch. isa_virt_to_bus() is not dependent on
CONFIG_ISA. It causes problems on x86_64 platforms which cannot enable
ISA support.
Actually it is, x86_64 just refuses to set CONFIG_ISA despite having
isa-like devices.
Either way a new
On Wed, Jan 26, 2005 at 08:11:41PM -0800, Andrew Morton wrote:
Yes, me too. generic_shutdown_super() takes lock_super(). And udf uses
lock_super for protecting its block allocation data strutures. Trivial
deadlock on unmount.
Filesystems really shouldn't be using lock_super() for internal
Hi,
I get on serial console only this:
# dmesg
radeonfb_pci_register BEGIN
radeonfb: ref_clk=2700, ref_div=60, xclk=15500 from BIOS
radeonfb: probed SDR SGRAM 65536k videoram
radeon_get_moninfo: bios 4 scratch = 202
Unable to handle kernel paging request at virtual address 083d5020
On Wed, Jan 26, Linux Kernel Mailing List wrote:
ChangeSet 1.2046, 2005/01/25 20:33:08-08:00, [EMAIL PROTECTED]
[PATCH] ppc32: Add support for Pegasos machines
This patch, mostly from Sven Luther and reworked by me, adds support for
Pegasos machines to the ppc32
On Sat, Jan 29, 2005 at 04:31:16PM +0100, Pierre Ossman wrote:
The problem was that the DMA API didn't work for x86_64 when I wrote the
driver. I see now that it has been fixed.
isa_virt_to_bus still works even though CONFIG_ISA is not configured. So
It may not exist at all.
-
To
Christoph Hellwig wrote:
On Sat, Jan 29, 2005 at 04:31:16PM +0100, Pierre Ossman wrote:
The problem was that the DMA API didn't work for x86_64 when I wrote the
driver. I see now that it has been fixed.
isa_virt_to_bus still works even though CONFIG_ISA is not configured. So
It may not
On Sat, Jan 29, 2005 at 05:08:32PM +0100, Pierre Ossman wrote:
For i386 and x86_64 it's defined as virt_to_phys in asm/io.h without any
#ifdef:s protecting it.
Not all the world is a PC
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
Christoph Hellwig wrote:
On Sat, Jan 29, 2005 at 05:08:32PM +0100, Pierre Ossman wrote:
For i386 and x86_64 it's defined as virt_to_phys in asm/io.h without any
#ifdef:s protecting it.
Not all the world is a PC
Then the dependency should in that case be on architectures. It is
On Sat, 2005-01-29 at 11:21 -0500, John Richard Moser wrote:
-BEGIN PGP SIGNED MESSAGE-
These are the only places mprotect() is mentioned; a visual scan
confirms no trickery:
if( fork() == 0 ) {
/* Perform a dirty (but not unrealistic) trick to circumvent
On Sat, 29 Jan 2005, John Levon wrote:
On Fri, Jan 28, 2005 at 12:06:19PM -0700, Zwane Mwaikambo wrote:
= drivers/oprofile/oprofile_files.c 1.7 vs edited =
--- 1.7/drivers/oprofile/oprofile_files.c 2005-01-04 19:48:23 -07:00
+++ edited/drivers/oprofile/oprofile_files.c
On Sat, 2005-01-29 at 11:21 -0500, John Richard Moser wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arjan van de Ven wrote:
I actually just tried to paxtest a fresh Fedora Core 3, unadultered,
that I installed, and it FAILED every test. After a while, spender
reminded me about
John Richard Moser wrote:
So what's the layout of that top 1G? What's it all used for? Is there
some obscene restriction of 1G of shared memory or something that gets
mapped up there?
How much does it need, and why? What, if anything, is variable and
likely to do more than 10 or 15 megs of
On Sat, Jan 29, 2005 at 08:29:22AM -0600, James Bottomley wrote:
On Sat, 2005-01-29 at 11:37 +, Russell King wrote:
Thanks for the response. However, apart from Ralph, Paul and yourself,
Who are you talking about ;-)
it seems none of the other architecture maintainers care about this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arjan van de Ven wrote:
On Sat, 2005-01-29 at 11:21 -0500, John Richard Moser wrote:
-BEGIN PGP SIGNED MESSAGE-
These are the only places mprotect() is mentioned; a visual scan
confirms no trickery:
if( fork() == 0 ) {
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arjan van de Ven wrote:
On Sat, 2005-01-29 at 11:21 -0500, John Richard Moser wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arjan van de Ven wrote:
I actually just tried to paxtest a fresh Fedora Core 3, unadultered,
that I installed,
The mcd driver drives only very old hardware (some single and double
speed CD drives that were connected either via the soundcard or a
special ISA card), and the mcdx driver offers more functionality for the
same hardware.
My plan is to mark MCD as broken in 2.6.11 and if noone complains
This patch makes the needlessly global function isp16_init static.
As a result, it turned out that both this function and some other code
are only required #ifdef MODULE.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/cdrom/isp16.c | 13 -
drivers/cdrom/isp16.h |1
Hi Adrian,
The mcd driver drives only very old hardware (some single and double
speed CD drives that were connected either via the soundcard or a
special ISA card), and the mcdx driver offers more functionality for
the same hardware.
My plan is to mark MCD as broken in 2.6.11 and if
On Sat, Jan 29, 2005 at 01:31:46AM -0500, John Richard Moser wrote:
Finally, although an NX stack is nice, you should probably take into
account IBM's stack smash protector, ProPolice. Any attack that can
evade SSP reliably can evade an NX stack; but ProPolice protects from
other overflows.
On Sat, 29 Jan 2005 13:02:51 +, Richard Hughes [EMAIL PROTECTED] wrote:
On Sat, 29 Jan 2005 12:49:16 +, Richard Hughes wrote:
Note, that strace glxgears gives exactly the same output, going from 0 to
14 and then seg-faulting, so it's *not just a oo problem*.
I know it's bad to
On Fri, 28 Jan 2005, Venkatesh Pallipadi wrote:
Current tsc based delay_calibration can result in significant errors in
loops_per_jiffy count when the platform events like SMIs (System
Management Interrupts that are non-maskable) are present. This could
lead to potential kernel panic().
On Sat, 2005-01-29 at 10:53 -0300, Rodrigo Ramos wrote:
I would like to know how many groups of system calls are there at Linux
2.4 and 2.6? Where can I find these informations in the Kernel?
I don't know what you mean by groups (a nonempty set G with binary
operation * s.t. G is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jakub Jelinek wrote:
On Sat, Jan 29, 2005 at 01:31:46AM -0500, John Richard Moser wrote:
Finally, although an NX stack is nice, you should probably take into
account IBM's stack smash protector, ProPolice. Any attack that can
evade SSP reliably
Hi,
On Sat, 29 Jan 2005 18:11:08 +0100, Adrian Bunk [EMAIL PROTECTED] wrote:
This patch makes the needlessly global function isp16_init static.
As a result, it turned out that both this function and some other code
are only required #ifdef MODULE.
Your patch is correct but it is wrong. ;)
Am Samstag, 29. Januar 2005 15:46 schrieb James Bottomley:
I wouldn't have noticed this at all since you didn't send it to the scsi
list, but fortunately, Al Viro drew it politely to my attention as
another example of SCSI refcounting problems.
Sorry, it happening in cdrom_release fooled me
On Sat, Jan 29, 2005 at 12:49:05PM -0500, John Richard Moser wrote:
The ideas in IBM's ProPolice changes are good and worth
implementing, but the current implementation is bad.
Lies. I've read the paper on the current implementation, it's
definitely good. It only operates on C/C++
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christoph Hellwig wrote:
On Sat, Jan 29, 2005 at 12:49:05PM -0500, John Richard Moser wrote:
The ideas in IBM's ProPolice changes are good and worth
implementing, but the current implementation is bad.
Lies. I've read the paper on the current
On Sat, 29 Jan 2005, John Richard Moser wrote:
Did I miss the target? *Aims in the other direction then?*
Depends. If you aimed to kick your own arse, you did pretty well.
--
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as
On Tue, 2005-01-25 at 10:52 -0500, James Morris wrote:
On Mon, 24 Jan 2005, Andrew Morton wrote:
These patches clash badly with Michael Ludvig's work:
On Sat, Jan 29, 2005 at 01:10:54PM -0500, John Richard Moser wrote:
Yeah, I guess your extensive compiler internals experience and knowledge
of gcc internals weights a lot more than the opinion of the gcc team..
I read implementation as the way it's implemented, not as the
quality of
On Sat, Jan 29, 2005 at 12:47:38PM -0500, Robert Love wrote:
System calls are prefixed by sys_. Thus, read(2) is implemented in
the kernel as sys_read().
Now that you say this - of course you know that the actual
situation is much more messy. Sometimes I wonder whether
it would be useful to
* Lorenzo Hernández García-Hierro:
As it's impact is minimal (in performance and development/maintenance
terms), I recommend to merge it, as it gives a basic prevention for the
so-called system fingerprinting (which is used most by kids to know
how old and insecure could be a target system,
Fruhwirth Clemens [EMAIL PROTECTED] wrote:
My advise is, drop Michaels patches
for now, merge scatterwalker and add an ability to change the stepsize
dynamically in the run. Then I will finish my port and post it.
If we can agree on this agenda, I'll shift my focus to scatterwalker
Hi!
The nasty part there is that it can affect completely unrelated
data too (on a traditional disk you normally only lose the data
that is currently being written) because of of the relationship
between stripes on different disks.
Well, you could set stripe size to 512B; that way,
Well, you could set stripe size to 512B; that way, RAID-5 would be
*very* slow, but it should have same characteristics as normal disc
w.r.t. crash. Unrelated data would not be lost, and you'd either get
old data or new data...
When you lose a disk during recovery you can still lose
unrelated
Hi!
Well, you could set stripe size to 512B; that way, RAID-5 would be
*very* slow, but it should have same characteristics as normal disc
w.r.t. crash. Unrelated data would not be lost, and you'd either get
old data or new data...
When you lose a disk during recovery you can still
On Fri, Jan 28, 2005 at 02:27:20PM -0500, Dmitry Torokhov wrote:
On Fri, 28 Jan 2005 20:22:32 +0100, Wiktor [EMAIL PROTECTED] wrote:
Hi,
This dmesg looks like the keyboard works perfectly OK. Do new lines
appear in dmesg when you press keys while the system is running?
On Fri, Jan 28, 2005 at 08:22:32PM +0100, Wiktor wrote:
Hi,
This dmesg looks like the keyboard works perfectly OK. Do new lines
appear in dmesg when you press keys while the system is running?
.no? no, they don't. i've new dmesg for you - it reports
timeouts while trying to
On Fri, Jan 28, 2005 at 08:49:03PM +0100, Wiktor wrote:
Hi,
Could you please try editing drivers/input/serio/i8042.c and add
udelay(20) before and after calls to i8042_write_data() in
i8042_kbd_write() and i8042_command().
of course i could, will it make kernel not detect smoked AUX port?
You can pull this changeset from:
bk://kernel.bkbits.net/vojtech/for-linus
===
[EMAIL PROTECTED], 2005-01-28 21:11:52+01:00, [EMAIL PROTECTED]
input: Fix MUX mode disabling.
Signed-off-by: Vojtech Pavlik [EMAIL
On Fri, Jan 28, 2005 at 04:20:58PM +0200, Jaco Kroon wrote:
Vojtech Pavlik wrote:
On Thu, Jan 27, 2005 at 09:29:47PM +0100, Andries Brouwer wrote:
So what _might_ happen is that we write the command, and then
i8042_wait_write() thinks that there is space to write the data
immediately,
You can pull this changeset from:
bk://kernel.bkbits.net/vojtech/for-linus
===
[EMAIL PROTECTED], 2005-01-29 12:27:56+01:00, [EMAIL PROTECTED]
input: Document the atkbd.softraw module parameter.
From: Andries Brouwer
Where is the 2.6.10-ac11 announcement?
--
Ralf Hildebrandt (i.A. des IT-Zentrum) [EMAIL PROTECTED]
Charite - Universitätsmedizin BerlinTel. +49 (0)30-450 570-155
Gemeinsame Einrichtung von FU- und HU-BerlinFax. +49 (0)30-450 570-962
IT-Zentrum Standort CBF
Hi there,
unfortunately, I'm everything else but a developer, so please be a bit
patient with me.
As indicated by the subject, I got annoyed by the error message
mentioned flooding my log files. Comparing ftdi_sio.c to some of the
other usb-serial converter drivers, I decided to apply the
Hi,
I'm trying to list all of the tasks and their
children. (Im using a 2.6.5-7 kernel)
The code below does not list all of the pids as
compared to the /proc entries.
Why does the following code not list all of the
active pids in the system?
please cc this id.
---
On Fri, Jan 28, 2005 at 09:22:20PM +0100, Wiktor wrote:
Hi,
We do test AUX port and your port appears to be perfectly functional
from the kernel point of view - it porperly responds to AUX_LOOP
commands, does not claim to support MUX mode and KBC properly sets
status register when asked to
You can pull this changeset from:
bk://kernel.bkbits.net/vojtech/for-linus
===
[EMAIL PROTECTED], 2005-01-29 13:09:24+01:00, [EMAIL PROTECTED]
input: Ignore non-LED events in hid-input hidinput_event(). This gets rid
Al Viro wrote:
On Sat, Jan 29, 2005 at 03:45:42AM +0100, Rene Scharfe wrote:
The patch is inspired by the /proc restriction parts of the
GrSecurity patch. The main difference is the ability to configure
the restrictions dynamically. You can change the umask setting by
running
# mount -o
On Sat, 29 Jan 2005 13:02:51 +, Richard Hughes [EMAIL PROTECTED] wrote:
On Sat, 29 Jan 2005 12:49:16 +, Richard Hughes wrote:
Note, that strace glxgears gives exactly the same output, going from 0 to
14 and then seg-faulting, so it's *not just a oo problem*.
I know it's bad to
Hi!
The previous set introduced one bug, mostly harmless, but pretty
annoying - the hid-input driver fills the logs with the 'event field not
found' message. I'm sorry for that, I just tested that the patch does
what it should and didn't check the logs.
The last of these three patches fixes
On Thu, Jan 27, 2005 at 01:18:55PM -0500, Dmitry Torokhov wrote:
On Thu, 27 Jan 2005 17:36:05 +0100, Vojtech Pavlik [EMAIL PROTECTED] wrote:
On Thu, Jan 27, 2005 at 05:15:18PM +0100, Vojtech Pavlik wrote:
OK. I'll go through them, and apply as appropriate. I still need to wrap
my mind
On Fri, Jan 28, 2005 at 10:59:39PM +0100, Andries Brouwer wrote:
On Fri, Jan 28, 2005 at 12:10:05PM +0100, Vojtech Pavlik wrote:
And, btw, raw mode in 2.6 is not badly broken. It works as it is
intended to. If you want the 2.4 behavior on x86, you just need to
specify atkbd.softraw=0 on
On Fri, Jan 28, 2005 at 08:39:42PM +0100, Wiktor wrote:
Hi, IT WORKED!
Please try i8042.noaux=1. You say you're using a serial mouse in your
other e-mail, so the system may not have an AUX port yet the kernel
thinks it does. This may cause the keyboard to stop responding.
command line
On Sat, Jan 29, 2005 at 01:11:08PM +0100, Roman Zippel wrote:
I'm very sorry about the locking, but the thing grew up in times of
kernel 2.0, which didn't require any locking. There are a few possible
races with device registration/unregistration, and it's on my list to
fix that, however
On Fri, Jan 28, 2005 at 11:02:52PM -0500, Jon Smirl wrote:
Something changed in the Linus BK kernel in the last few days so that
I get drivers/usb/input/hid-input.c: event field not found in dmesg
everytime I move my MS Wheel mouse. Any ideas on how to get rid of
this?
The events are
1 - 100 of 365 matches
Mail list logo
