RE: Binary Drivers

> Two of the specific arguments I've heard are (a) that the board (and > its hardware interfaces that the documentation would describe) involve > IP licensed from a third party, which the board manufacturer does not > have a legal right to disclose, If they can't disclose it, they can't sell it.

[PATCH] MAINTAINERS - email addr change for Eric Moore

Update to maintainers list. My employer has changed the domain from lsil to lsi. Eric diff -uarpN b/MAINTAINERS a/MAINTAINERS --- b/MAINTAINERS 2006-12-13 18:14:23.0 -0700 +++ a/MAINTAINERS 2006-12-22 23:00:21.0 -0700 @@ -1919,9 +1919,9 @@ S:Maintained

Re: Section mismatch on current git head

> WARNING: vmlinux - Section mismatch: reference to > .init.data:acpi_sci_flags from .text between 'acpi_sci_ioapic_setup' (at > offset 0xc010e020) and 'acpi_unmap_lsapic' > WARNING: vmlinux - Section mismatch: reference to > .init.data:acpi_sci_flags from .text between 'acpi_sci_ioapic_setup'

Re: [RFC] delayed allocation for ext4

On Fri, Dec 22, 2006 at 11:20:08PM +0300, Alex Tomas wrote: > > Good day, > > probably the previous set of patches (including mballoc/lg) > is too large. so, I reworked delayed allocation a bit so > that it can be used on top of regular balloc, though it > still can be used with extents-enabled

Re: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!

John A Chaves wrote: > I didn't need to run a specific test for this. The normal workload of the > machine approximates a continuous selftest for almost the last year. > > Large files (4-12GB is typical) are being continuously packed and unpacked > with gzip and bzip2. Statistical analysis of

Re: [ANNOUNCE] RAIF: Redundant Array of Independent Filesystems

> > 3. A known ideal solution for this problem is sharing of the cached pages > >between file systems. We attempted to do it for Tracefs but the > >resulting code is not beautiful and is potentially racy: > > > >

Re: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!

On Friday 22 December 2006 20:04, Christoph Anton Mitterer wrote: > This brings me to: > Chris Wedgwood wrote: > > Does anyone have an amd64 with an nforce4 chipset and >4GB that does > > NOT have this problem? If so it might be worth chasing the BIOS > > vendors to see what errata they are

Re: 2.6.19-rt14 slowdown compared to 2.6.19

Chen, Tim C wrote: > Ingo, > > We did some benchmarking on 2.6.19-rt14, compared it with 2.6.19 > kernel and noticed several slowdowns. The test machine is a 2 socket > woodcrest machine with your default configuration. > > Netperf TCP Streaming was slower by 40% ( 1 server and 1 client >

Re: 2.6.19-rt14 slowdown compared to 2.6.19

Chen, Tim C wrote: > Ingo, > > We did some benchmarking on 2.6.19-rt14, compared it with 2.6.19 > kernel and noticed several slowdowns. The test machine is a 2 socket > woodcrest machine with your default configuration. > > Netperf TCP Streaming was slower by 40% ( 1 server and 1 client >

Re: [GIT PATCH] ACPI patches for 2.6.20-rc1

On Thursday 21 December 2006 02:58, Linus Torvalds wrote: > > On Wed, 20 Dec 2006, Len Brown wrote: > > > > please pull from: > > Is this really all obvious bug-fixes? There seems to be a lot of > development there that simply isn't appropriate after an -rc1 any more. > > I want 2.6.20 to be

Re: [RFC] [PATCH] Fix kmalloc flags used in ext3 with an active journal handle

Jan Kara wrote: On Tue, 19 Dec 2006 18:22:03 -0800 Suzuki <[EMAIL PROTECTED]> wrote: Andrew Morton wrote: On Tue, 19 Dec 2006 17:58:12 -0800 Suzuki <[EMAIL PROTECTED]> wrote: * Fix the kmalloc flags used from within ext3, when we have an active journal handle If we do a

Re: [BUG KERNEL 2.6.20-rc1] ftp: get or put stops during file-transfer

> > On kernel 2.6.20-rc1, ftp (get or put) stops > > during file-transfer. > > > > Client: ftp-0.17-33.fc6 (192.168.1.1) > > Server: vsftpd-2.0.5-8 (192.168.1.3) > > This problem happens on kernel-2.6.19-git4 or later. but does _not_ happen on kernel-2.6.19-git3. So this problem is

Re: [patch] change WARN_ON back to "BUG: at ..."

On Fri, 2006-12-22 at 12:04 -0800, Andrew Morton wrote: > I've always felt that it is wrong (or at least misleading) that WARN_ON > prints "BUG". It would have been better if it had said "WARNING", and only > BUG_ON says "BUG". > > But lots of people have now written downstream log-parsing tools

Re: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!

Hi my friends It became a little bit silent about this issue... any new ideas or results? Karsten Weiss wrote: > BTW: Did someone already open an official bug at > http://bugzilla.kernel.org ? Karsten, did you already file a bug? I told the whole issue to the Debian people which are

Re: moxa serial driver testing

[EMAIL PROTECTED] wrote: > Hi Jiri, > > I've figured out that both old and new mxser drivers have two similar > problems: > > 1. When there are data coming to a port, sometimes opening of the port >entirely locks the box. This is quite reproducible. Any idea what's >wrong and how can I

Re: [BUG] CIFS won't link

On Sat, 23 Dec 2006 14:21:48 +1300 Ian McDonald wrote: > In commit fba2591bf4e418b6c3f9f8794c9dd8fe40ae7bd9 > test_clear_page_dirty was removed a couple of days ago. > > Now when I try and build I get this: > WARNING: "test_clear_page_dirty" [fs/cifs/cifs.ko] undefined! > > This is caused by

[BUG] CIFS won't link

In commit fba2591bf4e418b6c3f9f8794c9dd8fe40ae7bd9 test_clear_page_dirty was removed a couple of days ago. Now when I try and build I get this: WARNING: "test_clear_page_dirty" [fs/cifs/cifs.ko] undefined! This is caused by line 1248 of fs/cifs/file.c if

[PATCH] arch/i386/pci/mmconfig.c tlb flush fix

We use the fixmap for accessing pci config space in pci_mmcfg_read/write(). The problem is in pci_exp_set_dev_base(). It is caching a last accessed address to avoid calling set_fixmap_nocache() whenever pci_mmcfg_read/write() is used. static inline void pci_exp_set_dev_base(int bus, int devfn) {

[PATCH -mm] MMCONFIG: Fix x86_64 ioremap base_address

Current -mm's mmconfig has some problems of remapped range. a) In the case of broken MCFG tables on Asus etc., we need to remap 256M range, but currently only remap 1M. b) The base address always corresponds to bus number 0, but currently we are assuming it corresponds to start bus number. This

Re: moxa serial driver testing

Jiri Slaby wrote: > [EMAIL PROTECTED] wrote: >> Hi Jiri, >> >> I've figured out that both old and new mxser drivers have two similar >> problems: >> >> 1. When there are data coming to a port, sometimes opening of the port >>entirely locks the box. This is quite reproducible. Any idea what's

Re: 2.6.19-rt14 slowdown compared to 2.6.19

On Fri, 2006-12-22 at 13:39 -0800, Chen, Tim C wrote: > Wonder if you have any suggestions on what could cause the slowdown. > We've tried disabling CONFIG_NO_HZ and it didn't help much. Did you compare PREEMPT_RT with vanilla PREEMPT ? Or one version of PREEMPT_RT vs. another ? Daniel - To

Re: WARNING: "test_clear_page_dirty" [fs/cifs/cifs.ko] undefined!

On Fri, 22 Dec 2006, Jean Delvare wrote: > > The approach seems quite broken to me, the users should have been fixed > _before_ removing the function, so as to avoid compilation failures. > These are a pain for testers, and break git bisect too. Grmbl. This needed to be fixed, and quite

Re: [NFS] Kernel BUG

Peter Zijlstra wrote: On Fri, 2006-12-22 at 12:59 +0100, Rudy Zijlstra wrote: Hi, I have a system where whenever i trigger a ongoing consistent NFS load i get the following kernel BUG: -- kernel BUG at mm/truncate.c:311! Lotsa changes there: try these:

Re: [PATCH] Rename FIELD_SIZEOF to MEMBER_SIZE and use in source tree.

On Friday 22 December 2006 18:21, Jan Engelhardt wrote: >> Rename the macro FIELD_SIZEOF() in include/linux/kernel.h to >>MEMBER_SIZE(), and make a number of replacements in the source tree >>where that macro simplified the code. > >Looks sane. (Random thought: SIZEOF_MEMBER()) > Lets not go

Re: [RFC][PATCH] Rewrite unnecessary duplicated code to use FIELD_SIZEOF().

On Dec 22 2006 09:43, Robert P. J. Day wrote: > >that's the name as it *already* existed in kernel.h. however, since >no one was actually using it yet, it's a piece of cake to give it a >better name. either FIELD_SIZE or MEMBER_SIZE would work just fine. I 'd go for MEMBER_SIZE. (Compare the

Re: [PATCH] Rename FIELD_SIZEOF to MEMBER_SIZE and use in source tree.

> > Rename the macro FIELD_SIZEOF() in include/linux/kernel.h to >MEMBER_SIZE(), and make a number of replacements in the source tree >where that macro simplified the code. Looks sane. (Random thought: SIZEOF_MEMBER()) -`J' -- - To unsubscribe from this list: send the line

Re: Binary Drivers

Robert Hancock wrote: Nikolaos D. Bougalis wrote: Manufacturers design product as they see fit and offer it on the market; I don't see nVidia or ATI thugs twisting your arm behind you as you walk down the aisle of Fry's Electronics saying "buy this nice card we made or I'll break your

[PATCH 3/3] Char: mxser_new, remove useless spinlock

mxser_new, remove useless spinlock gm_lock is useless, since ISA is configured at init time and there it's serialized. Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]> --- commit 5f93193574c932263132e3262853be671e9d1642 tree 94693e221836fd7234e290b9911757357889a580 parent

[PATCH 2/3] Char: mxser_new, mark init functions

mxser_new, mark init functions Mark some funcions with __init and __devinit. Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]> --- commit 04a4dbf03a9fdc4c53282ab7e1db146389140c3b tree 916cdef3d0f3acb58de8b96db6e83c11c3f0613c parent e3a36e41f423af467a95221598fd5754a8fb4032 author Jiri Slaby <[EMAIL

[PATCH 1/3] Char: mxser, fix oops when removing opened

mxser, fix oops when removing opened tty_driver->owner is not set, so if somebody remove mxser_module, it might oops (and doesn't tell the user: no way, it's in use). Set the .owner value. Cc: <[EMAIL PROTECTED]> Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]> --- commit

Re: Patch "i386: Relocatable kernel support" causes instant reboot

Jean Delvare <[EMAIL PROTECTED]> writes: > Hi Vivek, > > On Fri, 22 Dec 2006 16:10:56 +0530, Vivek Goyal wrote: >> Another odd thing is that "file vmlinux.bin" shows following. >> >> vmlinux.bin: Sendmail frozen configuration - version >

Re: Patch "i386: Relocatable kernel support" causes instant reboot

Hi Vivek, On Fri, 22 Dec 2006 16:10:56 +0530, Vivek Goyal wrote: > Another odd thing is that "file vmlinux.bin" shows following. > > vmlinux.bin: Sendmail frozen configuration - version > \015\024\322\216\356\222X\2306\032H\220\303\270\006\007\003 > > I am not sure what does it mean. I had

Re: Binary Drivers

On 12/22/06, Wolfgang Draxinger <[EMAIL PROTECTED]> wrote: Am Freitag, 22. Dezember 2006 20:22 schrieb Rok Markovic: > Hi! > > Maybe this does not belong to this thread, but I am wondering why > manufactorers doesn't want to release specifications about drivers You're not alone, I think

Re: [patch 2.6.20-rc1 3/6] input: ads7846 more compatible with hwmon

On Friday 22 December 2006 12:26 pm, Dmitry Torokhov wrote: > On 12/22/06, David Brownell <[EMAIL PROTECTED]> wrote: > > Be more compatible with the hwmon framework: > > > > - Hook up to hwmon > > * show sensor attrubites only if hwmon is present > > * otherwise be just a touchscreen > >

Re: Binary Drivers

Am Freitag, 22. Dezember 2006 20:22 schrieb Rok Markovic: > Hi! > > Maybe this does not belong to this thread, but I am wondering why > manufactorers doesn't want to release specifications about drivers. > They have decided to develop some hardware for, let say 3D > accelaration. Now they are

Re: [PATCH 1/5] Update Documentation/pci.txt

> On Mon, 18 Dec 2006 00:11:33 -0700 Grant Grundler wrote: ... >> +4.1 Stop IRQs on the device >> +~~~ >> +How to do this is chip/device specific. If it's not done, it opens >> +the possibility of a "screaming interrupt" if (and only if) >> +the IRQ is shared with another

[PATCH] pci/probe: fix macro that confuses kernel-doc

From: Randy Dunlap <[EMAIL PROTECTED]> Don't have macros between a function's kernel-doc block and the function definition. This is not valid for kernel-doc. Warning(/var/linsrc/linux-2.6.20-rc1-git8//drivers/pci/probe.c:653): No description found for parameter 'IORESOURCE_PCI_FIXED'

Re: omap compilation fixes

Hi! > > This is not yet complete set. set_map() is missing in latest kernels. > > > > Fix DECLARE_WORK()-change-related compilation problems. Please apply, > > > > --- a/drivers/mmc/omap.c > > +++ b/drivers/mmc/omap.c > > @@ -2,7 +2,7 @@ > > * linux/drivers/media/mmc/omap.c > > * > > *

Re: [PATCH] Fix some ARM builds due to HID brokenness

On Fri, 22 Dec 2006, Russell King wrote: > The new location for HID is extremely annoying: Hi Russell, well, the location itself was a subject to various discussions. At the end, drivers/hid won against drivers/input/hid, because, as Marcel correctly pointed out, in case of embedded systems

2.6.19-rt14 slowdown compared to 2.6.19

Ingo, We did some benchmarking on 2.6.19-rt14, compared it with 2.6.19 kernel and noticed several slowdowns. The test machine is a 2 socket woodcrest machine with your default configuration. Netperf TCP Streaming was slower by 40% ( 1 server and 1 client each bound to separate cpu cores on

evading ulimits

I've set up some stuff on my box where /etc/security/limits.conf contains the following: @users softnproc 3072 @users hardnproc 4096 I'm in group users, and a simple fork bomb is easily quashed by this: [EMAIL PROTECTED]:~$ :(){ :|:; };: bash: fork:

Re: WARNING: "test_clear_page_dirty" [fs/cifs/cifs.ko] undefined!

On Fri, 22 Dec 2006 15:28:45 +0100, Thomas Meyer wrote: > Again current git head: > > I guess this should be fixed by someone! > > WARNING: "test_clear_page_dirty" [fs/cifs/cifs.ko] undefined! > make[1]: *** [__modpost] Fehler 1 > make: *** [modules] Fehler 2 This is caused by this commit:

Re: Binary Drivers

Nikolaos D. Bougalis wrote: Manufacturers design product as they see fit and offer it on the market; I don't see nVidia or ATI thugs twisting your arm behind you as you walk down the aisle of Fry's Electronics saying "buy this nice card we made or I'll break your arm." If you need

Re: omap compilation fixes

* Pavel Machek <[EMAIL PROTECTED]> [061222 02:55]: > Hi! > > This is not yet complete set. set_map() is missing in latest kernels. > > Fix DECLARE_WORK()-change-related compilation problems. Please apply, > > --- a/drivers/mmc/omap.c > +++ b/drivers/mmc/omap.c > @@ -2,7 +2,7 @@ > *

[RFC] ext4-block-reservation.patch

Index: linux-2.6.20-rc1/include/linux/ext4_fs.h === --- linux-2.6.20-rc1.orig/include/linux/ext4_fs.h 2006-12-14 04:14:23.0 +0300 +++ linux-2.6.20-rc1/include/linux/ext4_fs.h2006-12-22 20:21:12.0 +0300 @@

[RFC] ext4-delayed-allocation.patch

Index: linux-2.6.20-rc1/include/linux/ext4_fs_i.h === --- linux-2.6.20-rc1.orig/include/linux/ext4_fs_i.h 2006-12-14 04:14:23.0 +0300 +++ linux-2.6.20-rc1/include/linux/ext4_fs_i.h 2006-12-22 22:56:04.0 +0300

[RFC] booked-page-flag.patch

Index: linux-2.6.20-rc1/include/linux/page-flags.h === --- linux-2.6.20-rc1.orig/include/linux/page-flags.h2006-12-14 04:14:23.0 +0300 +++ linux-2.6.20-rc1/include/linux/page-flags.h 2006-12-22 20:05:31.0 +0300

[RFC] delayed allocation for ext4

Good day, probably the previous set of patches (including mballoc/lg) is too large. so, I reworked delayed allocation a bit so that it can be used on top of regular balloc, though it still can be used with extents-enabled files only. this time series contains just 3 patches: -

Re: parse-boot-parameter-error.patch breaks UML

On Fri, 22 Dec 2006 15:53:38 -0500 Jeff Dike <[EMAIL PROTECTED]> wrote: > >From the changelog: > > Say a boot parameter is "xxx", if you give a string "xxxy", then the > boot parameter's corresponding function is executed. > > UML has parameters such as "ubda=" which are matched by

Re: [PATCH 2.6.20-rc1] xfrm: Algorithm lookup using .compat name

On Fri, Dec 22, 2006 at 05:26:43PM +0100, Martin Willi wrote: > Installing an IPsec SA using old algorithm names (.compat) does not work > if the algorithm is not already loaded. When not using the PF_KEY > interface, algorithms are not preloaded in xfrm_probe_algs() and > installing a IPsec SA

Re: two architectures,same source tree

On Fri, 22 Dec 2006 21:45:26 +0100 Bodo Eggert wrote: > Jörn Engel <[EMAIL PROTECTED]> wrote: > > On Wed, 20 December 2006 20:32:20 +0200, Yakov Lerner wrote: > > >> Is it easily possible to build two architectures in > >> the same source tree (so that intermediate fles > >> and resut files do

parse-boot-parameter-error.patch breaks UML

>From the changelog: Say a boot parameter is "xxx", if you give a string "xxxy", then the boot parameter's corresponding function is executed. UML has parameters such as "ubda=" which are matched by __setup("ubd", ubd_setup), which hits the "error" case this patch now outlaws.

Re: two architectures,same source tree

Jörn Engel <[EMAIL PROTECTED]> wrote: > On Wed, 20 December 2006 20:32:20 +0200, Yakov Lerner wrote: >> Is it easily possible to build two architectures in >> the same source tree (so that intermediate fles >> and resut files do not interfere ) ? > > I'd try something like this: > make O=../foo

Re: Possible race condition in usb-serial.c

> No, this is a fundamental problem. You don't > refcount > a pointer, you refcount a data structure. > But this is insufficient. We need to make > sure the pointer points to valid memory. I understand. But a typical definition of ref-count requires the count in the data structure to be equal

Re: [patch 2.6.20-rc1 6/6] input: ads7846 directly senses PENUP state

On Friday 22 December 2006 12:35 pm, Dmitry Torokhov wrote: > On 12/22/06, David Brownell <[EMAIL PROTECTED]> wrote: > > > > +static void ads7846_report_pen_state(struct ads7846 *ts, int down) > > +{ > > + struct input_dev*input_dev = ts->input; > > + > > +

Re: [patch 2.6.20-rc1 6/6] input: ads7846 directly senses PENUP state

On 12/22/06, David Brownell <[EMAIL PROTECTED]> wrote: +static void ads7846_report_pen_state(struct ads7846 *ts, int down) +{ + struct input_dev*input_dev = ts->input; + + input_report_key(input_dev, BTN_TOUCH, down); + if (!down) +

Re: [patch 2.6.20-rc1 3/6] input: ads7846 more compatible with hwmon

On 12/22/06, David Brownell <[EMAIL PROTECTED]> wrote: Be more compatible with the hwmon framework: - Hook up to hwmon * show sensor attrubites only if hwmon is present * otherwise be just a touchscreen - Report voltages per hwmon convention * measure in millivolts * voltages

Re: [PATCH] input/spi: add ads7843 support to ads7846 touchscreen driver

On 12/22/06, David Brownell <[EMAIL PROTECTED]> wrote: On Thursday 21 December 2006 5:08 am, Nicolas Ferre wrote: > > Let me try to sort out the mess with those updates, and ask you to refresh > > this ads7843 support against that more-current ads7846 code. > > Ok, let me know when you have a

Re: [PATCH] input/spi: add ads7843 support to ads7846 touchscreen driver

On Thursday 21 December 2006 6:40 am, Nicolas Ferre wrote: > Nicolas Ferre a écrit : > >>> As the SPI underlying code behaves quite differently from a > >>> controller driver to another whan not having a tx_buf filled, > >>> I have add a zerroed buffer to give to the spi layer while > >>>

Re: [patch] change WARN_ON back to "BUG: at ..."

I've always felt that it is wrong (or at least misleading) that WARN_ON prints "BUG". It would have been better if it had said "WARNING", and only BUG_ON says "BUG". But lots of people have now written downstream log-parsing tools which might break due to this change, so I'm inclined to go with

Re: [PATCH] Relay CPU Hotplug support

On Fri, Dec 22, 2006 at 02:44:58AM -0800, Andrew Morton wrote: > On Fri, 22 Dec 2006 16:07:24 +0530 > Gautham R Shenoy <[EMAIL PROTECTED]> wrote: > > > While we are at this per-subsystem cpuhotplug "locking", here's a > > proposal that might put an end to the workqueue deadlock woes. > > Oleg is

Re: Possible race condition in usb-serial.c

Am Freitag, 22. Dezember 2006 20:08 schrieb J: > > This problem will need some deeper surgery probably > > involving > > removal of the refcounting. > > Refcounting may be OK if used consistently. > It is not OK when some pointers are ref-counted, > but other (in serial_table) are not (like it

Re: omap compilation fixes

Hi, * Russell King <[EMAIL PROTECTED]> [061222 03:51]: > On Fri, Dec 22, 2006 at 01:35:31PM +0200, Komal Shah wrote: > > On 12/22/06, Pavel Machek <[EMAIL PROTECTED]> wrote: > > >Hi! > > > > > >This is not yet complete set. set_map() is missing in latest kernels. > > > > > >Fix

Re: moxa serial driver testing

[EMAIL PROTECTED] wrote: > Hi Jiri, > > I've figured out that both old and new mxser drivers have two similar > problems: > > 1. When there are data coming to a port, sometimes opening of the port >entirely locks the box. This is quite reproducible. Any idea what's >wrong and how can I

Re: Binary Drivers

Hi! Maybe this does not belong to this thread, but I am wondering why manufactorers doesn't want to release specifications about drivers. They have decided to develop some hardware for, let say 3D accelaration. Now they are selling hardware and users are buying hardware. Users are not buying

Re: [dm-devel] Re: [RFC PATCH 2/8] rqbased-dm: add block layer hook

Hi Mike, On Fri, 22 Dec 2006 01:18:44 -0600, Mike Christie <[EMAIL PROTECTED]> wrote: > > In addition to the suggested approach, what do you think about > > adding a new flag to req->cmd_flags which lets the end_io() handler > > not to return bio to upper layer? > > It will be useful for

Re: [PATCH 1/5] Update Documentation/pci.txt

On Mon, 18 Dec 2006 00:11:33 -0700 Grant Grundler wrote: > Full version of pci.txt (v6 is 677 lines): > http://www.parisc-linux.org/~grundler/Documentation/pci.txt-06 > > I've appended patch v6 (823 lines!) and commit log entry is below. > > > > diff --git a/Documentation/pci.txt

Re: [Bug 7505] Linux-2.6.18 fails to boot on AMD64 machine

> I am pretty sure the i386 tree has the same problem but I haven't checked yet. > Anyway: the panic is just a way of noticing. The bug is that irq's are enabled > before the irq controller is set up. A very similar i386 linux installation works fine on my laptop, but that i386 kernel never had

Re: [PATCH] input/spi: add ads7843 support to ads7846 touchscreen driver

On Thursday 21 December 2006 5:08 am, Nicolas Ferre wrote: > > Let me try to sort out the mess with those updates, and ask you to refresh > > this ads7843 support against that more-current ads7846 code. > > Ok, let me know when you have a newer code. I will try to adapt my > ads7843 support

[patch 2.6.20-rc1 5/6] input: ads7846 forces SPI mode 1

From: Imre Deak <[EMAIL PROTECTED]> Date: Fri May 26 16:30:10 2006 -0700 Input: ads7846: select correct SPI mode Talk to ADS7846 chip using SPI mode 1, which is what the chip supports: writes on falling clock edge, reads on rising. Signed-off-by: Imre Deak <[EMAIL PROTECTED]>

[patch 2.6.20-rc1 4/6] input: ads7836 users hrtimer

From: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: Mon Jul 3 21:34:16 2006 +0300 Input: ads7846: switch to hrtimer Use hrtimer instead of the normal timer, since it provides better sampling resolution. This will: - avoid a problem where we have a 1 jiffy poll period and dynamic tick on -

[patch 2.6.20-rc1 3/6] input: ads7846 more compatible with hwmon

Be more compatible with the hwmon framework: - Hook up to hwmon * show sensor attrubites only if hwmon is present * otherwise be just a touchscreen - Report voltages per hwmon convention * measure in millivolts * voltages are named in[0-8]_input (ugh) * for 7846 chips,

[patch 2.6.20-rc1 1/6] input: ads7846 pluggable conditioning filters

From: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: Mon Jul 3 21:36:53 2006 +0300 Input: ads7846: pluggable filtering logic Some LCDs like the LS041Y3 require a customized filtering logic for reliable readings, so make the filtering function replacable through platform specific hooks.

[patch 2.6.20-rc1 2/6] input: ads7846 optionally leaves vREF on

From: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: Mon Jul 3 21:40:10 2006 +0300 Input ads7846: optionally leave Vref on during differential measurements On some LCDs leaving the Vref on provides much better readings. Signed-off-by: Jarkko Oikarinen <[EMAIL PROTECTED]> Signed-off-by: Imre Deak

Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)

* Peter Zijlstra <[EMAIL PROTECTED]> [2006-12-22 14:25]: > > and it failed. > Since you are on ARM you might want to try with the page_mkclean_one > cleanup patch too. I've already tried it and it didn't work. I just tried it again together with Linus' patch and the two from Andrew and it

[patch 2.6.20-rc1 0/6] input: ads7846 touchscreen driver updates

Following this are six patches that bring the ads7846 driver up to date with respect to the patches in the Linux-OMAP tree. There was some unfortunate divergence, but the need for that is gone (now that issues with the omap_uwire SPI controller driver are resolved). - allow pluggable

2.6.20-rc1-git8 fails to build - another "clear_page_dirty' problem

The latest git pull from Linus's git tree fails to build. The error message is fs/built-in.o: In function `reiserfs_cut_from_item': : undefined reference to `clear_page_dirty' make: *** [.tmp_vmlinux1] Error 1 It seems that reiserfs needs to be updated to match the changes in dirty page

Re: [Bug 7505] Linux-2.6.18 fails to boot on AMD64 machine

On Fri, 22 Dec 2006 15:16:55 +0100 Ard -kwaak- van Breemen <[EMAIL PROTECTED]> wrote: > On Fri, Dec 22, 2006 at 03:00:59PM +0100, Ard -kwaak- van Breemen wrote: > > 262 if (!irqs_disabled()) printk(__FILE__ "%s(): blaat: > > interrupts were enabled [EMAIL

Re: Possible race condition in usb-serial.c

> This problem will need some deeper surgery probably > involving > removal of the refcounting. Refcounting may be OK if used consistently. It is not OK when some pointers are ref-counted, but other (in serial_table) are not (like it is in the current version). As for the deeper surgery, what

Re: [PATCH 2.6.19] mmc: Add support for SDHC cards

Philip Langdale wrote: > Hi all, > > Thanks to the generous donation of an SDHC card by John Gilmore, and the > surprisingly enlightened decision by the SD Card Association to publish > useful specs, I've been able to bash out support for SDHC. The changes > are not too profound: So I sent that

Re: [powerpc] Fix bogus BUG_ON() in in hugetlb_get_unmapped_area()

+ if (len > TASK_SIZE) + return -ENOMEM; Shouldn't that be addr+len instead? The check looks incomplete otherwise. And you meant ">=" I guess? No. Have a look at the other hugetlb_get_unmapped_area() implementations. Because this is in the get_unmapped_area() path,

[PATCH 2.6.19] mmc: Add support for SDHC cards

Hi all, Thanks to the generous donation of an SDHC card by John Gilmore, and the surprisingly enlightened decision by the SD Card Association to publish useful specs, I've been able to bash out support for SDHC. The changes are not too profound: i) Add a card flag indicating the card uses block

Re: [Bug 7505] Linux-2.6.18 fails to boot on AMD64 machine

Hello, On Thu, Dec 21, 2006 at 04:04:04PM +0800, Zhang, Yanmin wrote: > I couldn't reproduce it on my EM64T machine. I instrumented function > start_kernel and > didn't find irq was enabled before calling init_IRQ. It'll be better if the > reporter could > instrument function start_kernel to

Re: [RFC][PATCH -mm 0/5] proposal for dynamic configurable netconsole

On Fri, 22 Dec 2006 21:01:09 +0900 Keiichi KII <[EMAIL PROTECTED]> wrote: > From: Keiichi KII <[EMAIL PROTECTED]> > > The netconsole is a very useful module for collecting kernel message under > certain circumstances(e.g. disk logging fails, serial port is unavailable). > > But current

[PATCH]: x86-64 system crashes when no memory populating Node 0

I have a 4 socket AMD Operton system. The 2.6.18 kernel I have crashes when there is no memory in node0. --James diff -uNr linux-2.6.18-orig/arch/x86_64/kernel/aperture.c linux-2.6.18-new/arch/x86_64/kernel/aperture.c --- linux-2.6.18-orig/arch/x86_64/kernel/aperture.c 2006-09-19

Re: Possible race condition in usb-serial.c

Am Mittwoch, 20. Dezember 2006 23:24 schrieb J: > > Could you test the attached patch against 2.6? > > Alas, I only have an old 2.4 right now. > May be I will install 2.6 later (in few weeks). > Currently I am just trying to read 2.6 code with my > eyes. > > I studied the patch, which you sent.

[PATCH] interrupt endpoint support for keyspan USB-to-serial

From: Rainer Weikusat <[EMAIL PROTECTED]> At least the Keyspan USA-19HS USB-to-serial converter supports two different configurations, one where the input endpoints have interrupt transfer type and one where they are bulk endpoints. The default configuration uses the interrupt input endpoints.

Re: [patch 1/2] acpi: Remove procfs from bay

On Fri, 22 Dec 2006 11:43:55 + Pavel Machek <[EMAIL PROTECTED]> wrote: > Hi! > > > Remove the procfs related code from the bay driver. > > > > Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]> > > This changes userland interface... how many apps will it break? > >

Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)

On Fri, 22 Dec 2006, Peter Zijlstra wrote: > > fix page_mkclean_one() > > - add flush_cache_page() for all those virtual indexed cache >architectures. I think the flush_cache_page() should be after we've actually flushed it from the TLB and re-inserted it (this is one reason why I did

[PATCH 1/1] - Altix: ACPI _PRT support

Provide ACPI _PRT support for SN Altix systems. The SN Altix platform does not conform to the IOSAPIC IRQ routing model, so a new acpi_irq_model (ACPI_IRQ_MODEL_PLATFORM) has been defined. The SN platform specific code sets acpi_irq_model to this new value, and keys off of it in

Re: Section mismatch on current git head

On Fri, 22 Dec 2006 15:24:41 +0100 Thomas Meyer wrote: > Hello. > > What kind of problem is this: > 1.) the one that should be fixed, but also can be ignored or > 2.) the one that have to be fixed and ignorance is a bad idea? > Is this with CONFIG_RELOCATABLE=y? There were some patches posted

Re: [PATCH] Rename FIELD_SIZEOF to MEMBER_SIZE and use in source tree.

On Fri, 22 Dec 2006, Randy Dunlap wrote: > On Fri, 22 Dec 2006 10:34:09 -0500 (EST) Robert P. J. Day wrote: > > > > > Rename the macro FIELD_SIZEOF() in include/linux/kernel.h to > > MEMBER_SIZE(), and make a number of replacements in the source tree > > where that macro simplified the code. >

bcm43xx from 2.6.20-rc1-mm1 on HPC nx6325 (x86_64)

I'm trying to make the bcm43xx driver out of the 2.6.20-rc1-mm1 kernel work on an HPC nx6325, with no luck, so far, although I'm using a firmware that has been reported to work with these boxes (http://gentoo-wiki.com/HARDWARE_Gentoo_on_HP_Compaq_nx6325#Onboard_Wireless_.28802.11.29). The driver

Re: 2.6.19 file content corruption on ext3

On Mon, 18 Dec 2006, Gene Heskett wrote: > > What about the mm/rmap.c one liner, in or out? The one that just removes the "pte_mkclean()"? That's definitely out, it was just a test-patch to verify that the pte dirty bits seemed to matter at all (and they do). Linus - To

Re: [RFC PATCH 1/8] rqbased-dm: allow blk_get_request() to be called from interrupt context

On Fri, Dec 22 2006, Christoph Hellwig wrote: > On Wed, Dec 20, 2006 at 12:50:02PM -0500, Kiyoshi Ueda wrote: > > Because I'd like to use blk_get_request() in q->request_fn() > > which can be called from interrupt context like below: > > scsi_io_completion -> scsi_end_request ->

Re: [PATCH] Rename FIELD_SIZEOF to MEMBER_SIZE and use in source tree.

On Fri, 22 Dec 2006 10:34:09 -0500 (EST) Robert P. J. Day wrote: > > Rename the macro FIELD_SIZEOF() in include/linux/kernel.h to > MEMBER_SIZE(), and make a number of replacements in the source tree > where that macro simplified the code. Hi, Your CodingStyle ch. 17 additions also need to

Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)

* Gordon Farquharson <[EMAIL PROTECTED]> [2006-12-22 08:30]: > Based on the kernel gurus current knowledge of the problem, would > you expect the corruption to occur at the same point in a file, or > is it possible that the corruption could occur at different points > on successive Debian

Question about the io_context of I/O scheduler

Hi, I'm currently tracing the I/O path of the kernel (2.6.19 release) for the I/O scheduler, as far I as know, io_context is currently based on per-process basis. so, when an user process issued an I/O, the request generated in the kernel will be associated to the io_context of the "current"

[PATCH] Fix some ARM builds due to HID brokenness

The new location for HID is extremely annoying: 1. the help text implies that you need to enable it for any keyboard or mouse attached to the system. This is not correct. 2. it defaults to 'y'. When you have input deselected, this causes the kernel to fail to link:

Re: 2.6.19 file content corruption on ext3

On Sat, Dec 16, 2006 at 06:43:10PM +, Martin Michlmayr wrote: > * Marc Haber <[EMAIL PROTECTED]> [2006-12-09 10:26]: > > Unfortunately, I am lacking the knowledge needed to do this in an > > informed way. I am neither familiar enough with git nor do I possess > > the necessary C powers. > > I

  1   2   3   4   >