From: Mariusz Kozlowski <[EMAIL PROTECTED]>
Date: Tue, 2 Jan 2007 00:55:51 +0100
> On error we should start freeing resources at [i-1] not [i-2].
>
> Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
Patch applied, thanks Mariusz.
> diff -upr linux-2.6.20-rc2-mm1-a/drivers/net/ifb.c
>
Hi,
if a driver returns an error in fill_read_buffer(), the buffer will be
marked as filled. Subsequent reads will return eof. But there is
no data because of an error, not because it has been read.
Not marking the buffer filled is the obvious fix.
Regards
Oliver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message
Hello!
The last kernel from Linus' tree[1] that boots for me is v2.6.19. And
before I take my first stab at git-bisect, I thought I'd ask here in
case it's just a PEBCAK.
What happens in kernels
In-Reply-To: <[EMAIL PROTECTED]>
On Mon, 1 Jan 2007 17:53:04 +0100, [EMAIL PROTECTED] wrote:
> I tried 2.6.20-rc3 with the new nf_nat stuff on my gateway machine with pppoe
> (ADSL) access to the internet. When I shut down my ppp0 interface the kernel
> panics.
> [ 336.467373] BUG: unable to
www.occasions-tunisie.com
Nous mettons a votre disposition une Webcam qui permet via Internet de
surveiller votre appartement,
votre garage, votre jardin, bref, ce que vous voulez., cliquez ici (voir
Webcam Demo)
www.sfaxachats.com/webcam-demo/[EMAIL PROTECTED]
Pour ne plus
Hi Jeff! Alan!
today I decided to put a (granted somewhat older)
RocketRAID 454 card (hpt374 as it seems) into an
Asus P5B (which already has some controllers using
libata quite happily), and it seems that the driver
support is not perfect yet :)
note: the older hpt366 (ide) driver works quite
On 1/2/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
The binary blob in question is several megabytes in size. Now, even
totally *ignoring* who knowingly licensed/stole/whatever IP from who,
that *still* leaves the problem of trying to write several megabytes of
code that doesn't infringe on
In-Reply-To: <[EMAIL PROTECTED]>
On Tue, 02 Jan 2007 04:22:19 +0100, Marcel Holtmann wrote:
> > This patch went into 2.6.18.6:
> > http://marc.theaimsgroup.com/?l=linux-kernel=116614741607528=2
> >
> > However it is not included in 2.6.19.x or 2.6.20-rc3. Was this solved in
> > mainline
On Mon, Jan 01, 2007 at 10:39:13PM +0100, Jean Delvare wrote:
> Hi Vivek,
>
> Sorry for the delay, I'm just back from vacation. I tried it all again
> with 2.6.20-rc3 just in case, but the problem I've hit is still present.
>
Hi Jean,
Problem in not fixed yet in -rc3. So testing -rc3 will not
Hi Linus,
Please consider pulling from:
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git
or
master.kernel.org:/pub/scm/linux/kernel/git/dtor/input.git
to receive updates for input subsystem. There is a new driver for GPIO
connected keys from handheld.org tree and an
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Date: Tue, 02 Jan 2007 16:09:14 +1100
> Probably. The question now is that if we want to somewhat converge, what
> to do... either change sparc habits or change powerpc habits :-) I'll
> let that fight happen between you and paulus and watch while
On Mon, 01 Jan 2007 23:46:58 +0100
Rene Herman <[EMAIL PROTECTED]> wrote:
> > Everything seems fine in the dmesg. Performance degradation is
> > probably some other issue in -rc kernel. I'm suspecting recently
> > fixed block layer bug. If it's still the same in the next -rc,
> > please
Hi Linus,
please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release
A couple of small self-explanatory patches,
they will will update the files shown below.
thanks!
-Len
ps. a plain patch is also available here:
On Mon, 2007-01-01 at 21:01 -0800, David Miller wrote:
> From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> Date: Tue, 02 Jan 2007 15:57:05 +1100
>
> > I like being able to have a simple way (ie. tar /proc/device-tree) to
> > tell user to send me their DT and have in the end an exact binary
> >
Using MMCONFIG for PCI config space access is simply an optimization, not
a requirement. Therefore, when it can't be used, there's no need for
KERN_ERR level message. This patch makes the message a KERN_INFO instead
to reduce some of the noise in a kernel boot with the 'quiet' option.
(Note that
On Mon, Jan 01, 2007 at 11:04:49PM -0500, [EMAIL PROTECTED] wrote:
> On Sun, 31 Dec 2006 23:03:27 +1000, Trent Waddington said:
> > Why don't you release source? To protect the intellectual property.
> > Well, duh! That's why everyone holds back source. So allow me to
> > translate..
> >
> >
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Date: Tue, 02 Jan 2007 15:57:05 +1100
> I like being able to have a simple way (ie. tar /proc/device-tree) to
> tell user to send me their DT and have in the end an exact binary
> representation so I can actually dig for problems, like a wrong
> I think there is high value in an OFW filesystem representation
> that gives you _EXACTLY_ what the OFW command line prompt does
> when you try to traverse the device tree from there, and that
> is what openpromfs tries to do.
Except that every OFW implementation I have here shows you
On Fri, Dec 29, 2006 at 08:42:47PM -0800, Andrew Morton wrote:
> On Fri, 29 Dec 2006 22:24:53 -0500
> "Theodore Ts'o" <[EMAIL PROTECTED]> wrote:
>
> > Print messages resulting from sysrq-m with a KERN_INFO instead of the
> > default KERN_WARNING priority
>
> hm, I wonder why. If someone does
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Date: Tue, 02 Jan 2007 15:05:59 +1100
> It has proved a good idea in general as I can easily get an exact
> device-tree dump from users by asking for a tarball of /proc/device-tree
> and in some case, the data in there -is- binary (For example, the
On Fri, Dec 29, 2006 at 11:19:49PM -0600, * * wrote:
> Was this patch tested?
>
> > static inline void show_node(struct zone *zone)
> > {
> >if (NUMA_BUILD)
> >- printk("Node %d ", zone_to_nid(zone));
> >+ printk(KERN_INFO, "Node %d ", zone_to_nid(zone));
>
>
> The filesystem bit is for groveling around and getting information
> from the shell prompt, or shell scripts. Text processing.
>
> If you want the binary bits, export it with something like
> /dev/openprom. We don't generally export binary representation
> files out of /proc or /sys, in fact
On Sun, 31 Dec 2006 23:03:27 +1000, Trent Waddington said:
> Why don't you release source? To protect the intellectual property.
> Well, duh! That's why everyone holds back source. So allow me to
> translate..
>
> Why don't you release source? Because we don't believe in freedom, we
> don't
On Sun, 2006-12-31 at 19:37 -0800, David Kahn wrote:
> Folks,
>
> If we reused the current code in fs/proc/proc_devtree.c
> and re-wrote the underlying of_* routines for i386 only,
> (in the hope of removing the complexity not needed for
> this implementation) would that be an acceptable
>
> This is a trivial implementation that suits it's purpose.
> It's simple. I'm not sure what more is needed for this
> project when it's pretty clear that i386 will never need
> any additional support for open firmware.
I don't agree. It's definitely not clear to me Especially as open
source
> The base interface function is callofw(), which is effectively identical
> to call_prom_ret() in arch/powerpc/kernel/prom_init.c . So it seems
> that PowerPC could use it. I suppose I could change the name of
> callofw() to call_prom_ret(), thus making the base interface identical
> to
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Date: Tue, 02 Jan 2007 14:45:31 +1100
> In addition, I haven't given on the idea one day of actually merging the
> powerpc and sparc implementation of a lot of that stuff. Mostly the
> device-tree accessors proper, the of_device/of_platform bits
> I would strongly suggest looking at things like
> arch/{sparc,sparc64,powerpc}/kernel/prom.c and
> include/asm-{sparc,sparc64,powerpc}/prom.h and
> arch/{sparc,sparc64,powerpc}/kernel/of_device.c and
> include/asm-{sparc,sparc64,powerpc}/of_device.h
> since we've already invested a lot of
> I'm incredibly surprised how much resistence there is from the
> i386 OFW folks to do this right. It would be like 80 lines of
> code to suck the device tree into kernel memory, or if they don't
> want to do that they can use inline function wrappers to provide
> the clean C-language interface
From: David Kahn <[EMAIL PROTECTED]>
Date: Mon, 01 Jan 2007 17:40:25 -0800
> If that doesn't fit the model of /sys or /proc,
> I suppose it could be done in a separate file
> system, but that's overkill, isn't it?
Or by a device driver, which is what OFW systems have
been doing for years, and we
From: Segher Boessenkool <[EMAIL PROTECTED]>
Date: Tue, 2 Jan 2007 00:52:36 +0100
> There is one big problem: text representation is useless
> (to scripts etc.) unless it can be transformed back to binary;
> i.e., it has to be possible to reliably detect _how_ some
> property is represented into
Hi Daniel,
> This patch went into 2.6.18.6:
> http://marc.theaimsgroup.com/?l=linux-kernel=116614741607528=2
>
> However it is not included in 2.6.19.x or 2.6.20-rc3. Was this solved in
> mainline another way, are there issues with the patch, or was this
> simply overlooked?
it is sitting in
Rafael J. Wysocki wrote:
Secondly, if you try and suspend manually it claims there is no swap
device available when there clearly is:
[EMAIL PROTECTED] rob]# cat /proc/swaps
FilenameTypeSizeUsed
Priority
/dev/mapper/VolGroup00-LogVol01
On Sun, 31 Dec 2006 17:09:43 GMT, Alan said:
> That IP story is for the most part not even credible. If they were worried
> about "software IP" they would release hardware docs and let us get on
> with writing drivers that may well not be as cool as theirs but would
> work. If they had real IPR
On Tue, 02 Jan 2007 02:52:33 +0100 Richard Knutsson wrote:
> Jeff Dike wrote:
> > Whitespace and style fixes.
> >
> > Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
> > --
> > arch/um/drivers/hostaudio_kern.c | 160
> > +--
> > 1 file changed, 73
I have a DVD combo drive and a CD in which the
"READ TRACK INFORMATION" command (implemented in the
cdrom_get_track_info() function) takes about 7 seconds to run.
The current implementation of cdrom_get_track_info() uses the
default timeout of 5 seconds. So here's a patch that increases
the
On Mon, Jan 01, 2007 at 03:34:53PM -0800, Linus Torvalds wrote:
>
>
> On Mon, 1 Jan 2007, Alan wrote:
> >
> > Want a fix Linus given Jeff is away ?
>
> Send it over, and please cc Alessandro and others that can test it. Things
> obviously aren't broken on _my_ machines ;)
Can I get a copy of
Jeff Garzik <[EMAIL PROTECTED]> wrote:
>
> e1000: Do not truncate TSO TCP header with 82544 workaround
This change obsoletes the following change.
> e1000: disable TSO on the 82544 with slab debugging
So the slab debugging patch should be reverted.
Thanks,
--
Visit Openswan at
Cyrill V. Gorcnov wrote:
On Monday 01 January 2007 04:19, you wrote:
|
| In order to not get in trouble with MADR ("Mothers Against Drunk
| Releases") I decided to cut the 2.6.20-rc3 release early rather than wait
| for midnight, because it's bound to be new years _somewhere_ out there.
On Mon, Jan 01, 2007 at 10:44:42PM +0100, Luca Tettamanti wrote:
> And - for an easier review - this is the diff between
> radeonfb-atom-2.6.19-v6a.diff from Solomon and my patch (whitespace-only
> changes not included).
It looks good in this quick once-over..
Thanks for the rebase!
Acked-by:
Jeff Dike wrote:
Whitespace and style fixes.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
arch/um/drivers/hostaudio_kern.c | 160 +--
1 file changed, 73 insertions(+), 87 deletions(-)
Index: linux-2.6.18-mm/arch/um/drivers/hostaudio_kern.c
David Miller wrote:
We have some extensive code in fs/openpromfs/inode.c that
determines whether a property is text or not. I can't
guarentee it works %100, but it's very context dependant
(only the driver "knows") but it works for all the cases
I've tried.
The problem with guessing, as
Hi,
This patch went into 2.6.18.6:
http://marc.theaimsgroup.com/?l=linux-kernel=116614741607528=2
However it is not included in 2.6.19.x or 2.6.20-rc3. Was this solved in
mainline another way, are there issues with the patch, or was this
simply overlooked?
Thanks,
Daniel
-
To unsubscribe
Jan Engelhardt wrote:
just for fun, i threw the following together to peruse the tree (or
any subdirectory) and look for stuff that violates the CodingStyle
guide. clearly, it's far from complete and very ad hoc, but it's
amusing. extra searches happily accepted.
I had a bunch of similar
On Sun, 31 Dec 2006 02:27:46 +0100 Pavel Pisa wrote:
> Simple increase of section TOC level generation significantly
> enhances navigation experience through generated kernel
> API documentation.
>
> This change restores back state from SGML tools time.
>
> Signed-off-by: Pavel Pisa <[EMAIL
On 1/2/07, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
On Mon, 2007-01-01 at 22:44 +0100, Luca Tettamanti wrote:
> Il Mon, Jan 01, 2007 at 10:25:51PM +0100, Luca Tettamanti ha scritto:
> > Hi Ben, Andrew,
> > I've rebased 'ATOM BIOS patch' from Solomon Peachy to apply to 2.6.20.
> > The
I have no idea now why this fragment was in the patch, and Olaf has
rightly questioned it.
Please apply.
Regards,
Nigel
diff --git a/drivers/macintosh/via-pmu.c b/drivers/macintosh/via-pmu.c
index c8558d4..e63ea1c 100644
--- a/drivers/macintosh/via-pmu.c
+++ b/drivers/macintosh/via-pmu.c
@@
Hello,
On error we should start freeing resources at [i-1] not [i-2].
Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
drivers/net/ifb.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff -upr linux-2.6.20-rc2-mm1-a/drivers/net/ifb.c
On Mon, 2007-01-01 at 22:44 +0100, Luca Tettamanti wrote:
> Il Mon, Jan 01, 2007 at 10:25:51PM +0100, Luca Tettamanti ha scritto:
> > Hi Ben, Andrew,
> > I've rebased 'ATOM BIOS patch' from Solomon Peachy to apply to 2.6.20.
> > The patch adds support for newer Radeon cards and is mainly based on
On Mon, 2007-01-01 at 22:25 +0100, Luca Tettamanti wrote:
> Hi Ben, Andrew,
> I've rebased 'ATOM BIOS patch' from Solomon Peachy to apply to 2.6.20.
> The patch adds support for newer Radeon cards and is mainly based on
> X.Org code.
>
> I've fixed a few things:
> - Port sharing in
Hello,
Without the patch below namelist[0] will not be freed in case
of kmalloc error.
Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
sound/usb/usbmixer.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -upr linux-2.6.20-rc2-mm1-a/sound/usb/usbmixer.c
On Mon, 2007-01-01 at 23:22 +0100, Arnd Bergmann wrote:
> There are multiple efforts in progress to get a jffs2 replacement. NAND
> flash in embedded devices has the same size as it has on MMC card
> potentially, so we will need one soon. David Woodhouse has pushed the
> limit that jffs2 can
Hello,
Add kmalloc failure check and fix the loop on error path. Without the
patch pool element at index [0] will not be freed.
Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
drivers/scsi/lpfc/lpfc_mem.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff -upr
On Mon, 1 Jan 2007, Jan Harkes wrote:
On Mon, Jan 01, 2007 at 11:47:06PM +0100, Mikulas Patocka wrote:
Anyway, cp -a is not the only application that wants to do hardlink
detection.
I tested programs for ino_t collision (I intentionally injected it) and
found that CP from coreutils 6.7 fails
If you *really* want (the option of) showing things as text
in the filesystem, you better make it so that there is a
one-to-one translation back to binary. For example, what
does this mean, is it a text string or two bytes:
01.02
Yes you as a user can guess, but scripts can't (reliably).
We
On Mon, Jan 01, 2007 at 11:47:06PM +0100, Mikulas Patocka wrote:
> >Anyway, cp -a is not the only application that wants to do hardlink
> >detection.
>
> I tested programs for ino_t collision (I intentionally injected it) and
> found that CP from coreutils 6.7 fails to copy directories but
Rene Herman wrote:
Tejun Heo wrote:
Everything seems fine in the dmesg. Performance degradation is
probably some other issue in -rc kernel. I'm suspecting recently
fixed block layer bug. If it's still the same in the next -rc,
please report.
In fact, it's CFQ. The PATA thing was a red
On Mon, Jan 01, 2007 at 11:15:04PM +0100, Miklos Szeredi wrote:
> > > > I'm willing to do that - and I guess this means we can probably do this
> > > > instead of walking the list of VMAs for the shared mapping, thereby
> > > > hitting both anonymous and shared mappings with the same code?
> > >
On Sunday, 31 December 2006 17:24, Rafael J. Wysocki wrote:
> On Sunday, 31 December 2006 14:27, Rafael J. Wysocki wrote:
> > On Sunday, 31 December 2006 09:15, Robert Hancock wrote:
> > > Having some suspend problems on 2.6.20-rc2-git1 with Fedora Core 6.
> > > First of all the normal user
On Mon, 1 Jan 2007, Alan wrote:
>
> Want a fix Linus given Jeff is away ?
Send it over, and please cc Alessandro and others that can test it. Things
obviously aren't broken on _my_ machines ;)
And if we end up having more problems related to this in -rc4, I'll just
revert both your fix and
On Mon, 1 Jan 2007, Rene Herman wrote:
> Rene Herman wrote:
>
> > In fact, it's CFQ. The PATA thing was a red herring. 2.6.20-rc2 and 3 give
> > me ~ 24 MB/s from "hdparm t /dev/hda" while 2.6.20-rc1 and below give me ~
> > 50 MB/s.
> >
> > Jens: this is due to "[PATCH] cfq-iosched: tighten
Hi Linus and Andrew,
Please apply below patch which exports invalidate_mapping_pages() to
modules. It makes no sense to me to export invalidate_inode_pages() and
not invalidate_mapping_pages() and I actually need
invalidate_mapping_pages() because of its range specification ability...
It
Hi,
On Monday, 1 January 2007 20:44, Andrey Borzenkov wrote:
> In *the same* configuration STD now fails with "Cannot find swap device". The
> reason is changes in kernel/power/swap.c. In 2.6.19 it did not require valid
> swsusp_resume_device at all - it took first available swap device and saved
Jon Smirl wrote:
I have the source code for a vendor written driver that is targeted at
2.6.9. It includes this and then proceeds to manipulate files from the
driver.
In future just kill the code in question, it's wrong and not needed.
It's already mostly disabled in the code, based on my
On Mon, 2007-01-01 at 15:04 -0800, David Miller wrote:
> I thought this was accepted and Ralf is using it on MIPS?
It partially is ... we're using it on parisc as well, but only as a
supplement to the current linux flushing APIs. There's still no
guarantee in the standard linux API that
> BTW. How does ReiserFS find that a given inode number (or object ID in
> ReiserFS terminology) is free before assigning it to new file/directory?
reiserfs v3 has an extent map of free object identifiers in
super-block.
Inode free space can have at most 2^31 extents --- if inode numbers
Hi!
> FYI, i have forward ported your MAX_ARG_PAGES limit removal patch to
> 2.6.20-rc2 and have included it in the -rt kernel. It's working great -
> i can now finally do a "ls -t patches/*.patch" in my patch repository -
> something i havent been able to do for years ;-)
>
> what is keeping
On Mon, Jan 01, 2007 at 03:01:52PM -0800, David Miller wrote:
> From: James Bottomley <[EMAIL PROTECTED]>
> Date: Mon, 01 Jan 2007 10:34:12 -0600
>
> > Erm, well the whole reason for the flush_anon_pages() was that you told
> > me not to do it in flush_dcache_page() ...
> >
> > Although this is
Hi Dave,
On Mon, Jan 01, 2007 at 12:06:19PM -0800, David Brownell wrote:
> > The concern I have with your current implementation is that I don't
> > see a way to flexibly add in support for additional gpio pins on a
> > machine by machine basis. The code does do a good job of abstracting
> >
From: Segher Boessenkool <[EMAIL PROTECTED]>
Date: Mon, 1 Jan 2007 18:48:33 +0100
> If you *really* want (the option of) showing things as text
> in the filesystem, you better make it so that there is a
> one-to-one translation back to binary. For example, what
> does this mean, is it a text
Mikulas Patocka writes:
[...]
>
> BTW. How does ReiserFS find that a given inode number (or object ID in
> ReiserFS terminology) is free before assigning it to new file/directory?
reiserfs v3 has an extent map of free object identifiers in
super-block. reiser4 used 64 bit object
From: James Bottomley <[EMAIL PROTECTED]>
Date: Mon, 01 Jan 2007 10:44:36 -0600
> Actually, this was proposed here:
>
> http://marc.theaimsgroup.com/?t=11540975413
>
> When I updated the interface to work for the combined VIPT/PIPT cache on
> the latest pariscs. However, there were no
From: James Bottomley <[EMAIL PROTECTED]>
Date: Mon, 01 Jan 2007 10:34:12 -0600
> Erm, well the whole reason for the flush_anon_pages() was that you told
> me not to do it in flush_dcache_page() ...
>
> Although this is perhaps part of the confusion over what
> flush_dcache_page() is actually
> The question is: why does the kernel contain iget5 function that looks up
> according to callback, if the filesystem cannot have more than 64-bit
> inode identifier?
Generally speaking, file system might have two different identifiers for
files:
- one that makes it easy to tell whether two
Rene Herman wrote:
In fact, it's CFQ. The PATA thing was a red herring. 2.6.20-rc2 and 3
give me ~ 24 MB/s from "hdparm t /dev/hda" while 2.6.20-rc1 and below
give me ~ 50 MB/s.
Jens: this is due to "[PATCH] cfq-iosched: tighten allow merge
criteria",
Tejun Heo wrote:
Everything seems fine in the dmesg. Performance degradation is
probably some other issue in -rc kernel. I'm suspecting recently
fixed block layer bug. If it's still the same in the next -rc,
please report.
In fact, it's CFQ. The PATA thing was a red herring. 2.6.20-rc2 and
Hi!
If user (or script) doesn't specify that flag, it
doesn't help. I think
the best solution for these filesystems would be
either to add new syscall
int is_hardlink(char *filename1, char *filename2)
(but I know adding syscall bloat may be objectionable)
it's also the wrong api; the
On Sunday 31 December 2006 13:32, Pierre Ossman wrote:
> Arnd Bergmann wrote:
>
> I'm a complete MTD noob, but what uses does the MTD layer have besides
> JFFS2. If it's none, than this advantage isn't that big of a deal.
>
> > * It becomes possible to use MMC cards with jffs2 even with
> > > I'm willing to do that - and I guess this means we can probably do this
> > > instead of walking the list of VMAs for the shared mapping, thereby
> > > hitting both anonymous and shared mappings with the same code?
> >
> > But for the get_user_pages() case there's no point, is there? The
Description: new KFREE() macro to set the variable NULL after freeing it.
Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]>
diff --git a/include/linux/slab.h b/include/linux/slab.h
index 1ef822e..28da74c 100644
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -75,6 +75,12 @@ void
Am Montag, 1. Januar 2007 21:56 schrieb Andrew Barr:
> I have a simple question perhaps someone can help me with here...
>
> I have one of those simple LED keyboard lamps that get their power from
> the USB port. Is there some way in Linux, using files under /sys I would
> imagine, to cut power
On Jan 1 2007 22:40, Ingo Oeser wrote:
>On Monday, 1. January 2007 17:25, Andreas Schwab wrote:
>> Ingo Oeser <[EMAIL PROTECTED]> writes:
>> > Then this works, because the side effect (+20) is evaluated only once.
>>
>> It's not a side effect, it's a non-lvalue, and you can't take the address
Il Mon, Jan 01, 2007 at 10:25:51PM +0100, Luca Tettamanti ha scritto:
> Hi Ben, Andrew,
> I've rebased 'ATOM BIOS patch' from Solomon Peachy to apply to 2.6.20.
> The patch adds support for newer Radeon cards and is mainly based on
> X.Org code.
And - for an easier review - this is the diff
On Monday, 1. January 2007 17:25, Andreas Schwab wrote:
> Ingo Oeser <[EMAIL PROTECTED]> writes:
> > Then this works, because the side effect (+20) is evaluated only once.
>
> It's not a side effect, it's a non-lvalue, and you can't take the address
> of a non-lvalue.
Just verified this. So If
Hi Vivek,
Sorry for the delay, I'm just back from vacation. I tried it all again
with 2.6.20-rc3 just in case, but the problem I've hit is still present.
On Fri, 22 Dec 2006 16:10:56 +0530, Vivek Goyal wrote:
> Can you please also upload boot/compressed/vmlinux.
I've shared the whole build tree
On Monday 01 January 2007 12:55 pm, Pavel Machek wrote:
> > Think of it as "cookies represented by integers" if you like.
>
> typedef int gpio_t would hurt, and would serve as a useful
> documentation hint.
Yes, I agree that such needless obfuscation hurts. ;)
Plus, such a typedef would
On 1/1/07, Amit Choudhary <[EMAIL PROTECTED]> wrote:
+#define KFREE(x) \
+ do {\
+ kfree(x); \
+ x = NULL; \
+ } while(0)
NAK until you have actual callers for it. CONFIG_SLAB_DEBUG already
catches use after
> * I was unable to argue against Alan's logic behind
> 368c73d4f689dae0807d0a2aa74c61fd2b9b075f but I just don't like it.
> Regardless of whether or not this truly reflects how the PCI device is
> wired, it makes pci_request_regions() and similar resource handling code
> behave differently.
On Mon, 1 Jan 2007 12:13:08 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> Jeff,
> what was the resolution to this one? Just revert the offending commit, or
> what?
If you revert the commit you end with all the PCI resource tree breakage
back
>
> We're about five weeks into the
I have a simple question perhaps someone can help me with here...
I have one of those simple LED keyboard lamps that get their power from
the USB port. Is there some way in Linux, using files under /sys I would
imagine, to cut power to the USB port into which this lamp is plugged? I
know I would
Hi!
> > Well. when you see (something) = gpio_number + 5 ... you most likely
> > have an error.
>
> One could surely apply that argument to hundreds of places throughout
> the kernel ... that doesn't make it a good one. One of the downfalls
> of many "object oriented programming" efforts was
Linus Torvalds wrote:
Jeff,
what was the resolution to this one? Just revert the offending commit, or
what?
We're about five weeks into the 2.6.20-rc series. I was hoping for a
two-month release rather than the usual dragged-out three months, so I'd
like to get these regressions to be
On Sunday 31 December 2006 11:11 am, Kevin O'Connor wrote:
> > Based on earlier discussion, I'm sending a refresh of the generic GPIO
> > patch, with several (ARM based) implementations in separate patches:
>
> Hi Dave,
>
> I'm very interested in seeing an abstraction for gpios.
Good! I
For the list archives: here's the latest version of this.
The signed-off-by discussion is offlist right now, so this
version has none; see what eventually merges.
From: Philipp Zabel <[EMAIL PROTECTED]>
Arch-neutral GPIO calls for PXA.
Index: pxa/include/asm-arm/arch-pxa/gpio.h
> This makes my Maple board very unhappy -- it triggers a WARN_ON() in
> kref_get() lots of times...
Maybe the refounting in prom.c is broken ? I'll have a look.
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
Jeff,
what was the resolution to this one? Just revert the offending commit, or
what?
We're about five weeks into the 2.6.20-rc series. I was hoping for a
two-month release rather than the usual dragged-out three months, so I'd
like to get these regressions to be actively fixed. By forcible
On Fri, Dec 29, 2006 at 03:48:02PM -0800, Randy Dunlap wrote:
> /*
> * Normally, ...
> if (
> (several of these)
Yeah, I'm working off the most blatant style violations at the moment.
Jeff
--
Work email - jdike at linux dot intel dot com
-
To
Locking fixes. Locking was totally lacking for the mconsole_devices,
which got a spin lock, and the unplugged pages data, which got a
mutex.
The locking of the mconsole console output code was confused. Now,
the console_lock (renamed to client_lock) protects the clients list.
Signed-off-by:
Kill a compilation warning.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
arch/um/kernel/exec.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.18-mm/arch/um/kernel/exec.c
===
---
Whitespace and style fixes.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
arch/um/drivers/port_kern.c | 46 +++
arch/um/drivers/port_user.c | 51 +---
2 files changed, 43 insertions(+), 54 deletions(-)
Index:
1 - 100 of 348 matches
Mail list logo
