Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, 8 Apr 2005, Evgeniy Polyakov wrote: > > > Sure, but seems I need to ask again: What is the exact reason not to > > > implement > > > the muticast message multiplexing/subscription part of the connector as a > > > generic part of netlink? That would be nice to have and useful for other > > > subsystems too as an option to the current broadcast. > > > > This is a good point, in general, consider generically extending Netlink > > itself instead of creating these separate things. > > Connector requires it's own registration technique for > 1. hide all transport [netlink] layer from higher protocols which use > connector Why? > 2. create different group appointment for the given connector's ID > [it was different, now new group which is eqal to idx field is appointed > to > the new callback] I don't understand. > 3. provide more generic set of ids What do you mean by "ids"? - 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] 'is_enabled' flag should be set/cleared when the device is actually enabled/disabled
Hi,
(B
(BI think 'is_enabled' flag in pci_dev structure should be set/cleared
(Bwhen the device actually enabled/disabled. Especially about
(Bpci_enable_device(), it can be failed. By this change, we will also
(Bget the possibility of refering 'is_enabled' flag from the functions
(Bcalled through pci_enable_device()/pci_disable_device().
(B
(BSigned-off-by: Kenji Kaneshige <[EMAIL PROTECTED]>
(B
(B
(B---
(B
(B linux-2.6.12-rc2-kanesige/drivers/pci/pci.c |7 +++
(B 1 files changed, 3 insertions(+), 4 deletions(-)
(B
(Bdiff -puN drivers/pci/pci.c~fix_update_is_enabled drivers/pci/pci.c
(B--- linux-2.6.12-rc2/drivers/pci/pci.c~fix_update_is_enabled2005-04-07
(B18:59:47.058814755 +0900
(B+++ linux-2.6.12-rc2-kanesige/drivers/pci/pci.c 2005-04-07 19:02:25.843969060
(B+0900
(B@@ -398,10 +398,10 @@ pci_enable_device(struct pci_dev *dev)
(B {
(Bint err;
(B
(B- dev->is_enabled = 1;
(Bif ((err = pci_enable_device_bars(dev, (1 << PCI_NUM_RESOURCES) - 1)))
(Breturn err;
(Bpci_fixup_device(pci_fixup_enable, dev);
(B+ dev->is_enabled = 1;
(Breturn 0;
(B }
(B
(B@@ -427,16 +427,15 @@ pci_disable_device(struct pci_dev *dev)
(B {
(Bu16 pci_command;
(B
(B- dev->is_enabled = 0;
(B- dev->is_busmaster = 0;
(B-
(Bpci_read_config_word(dev, PCI_COMMAND, _command);
(Bif (pci_command & PCI_COMMAND_MASTER) {
(Bpci_command &= ~PCI_COMMAND_MASTER;
(Bpci_write_config_word(dev, PCI_COMMAND, pci_command);
(B}
(B+ dev->is_busmaster = 0;
(B
(Bpcibios_disable_device(dev);
(B+ dev->is_enabled = 0;
(B }
(B
(B /**
(B
(B_
(B-
(BTo unsubscribe from this list: send the line "unsubscribe linux-kernel" in
(Bthe body of a message to [EMAIL PROTECTED]
(BMore majordomo info at http://vger.kernel.org/majordomo-info.html
(BPlease read the FAQ at http://www.tux.org/lkml/
Re: VST and Sched Load Balance
On Thu, Apr 07, 2005 at 05:10:24PM +0200, Ingo Molnar wrote: > Interaction with VST is not a big issue right now because this only matters > on SMP boxes which is a rare (but not unprecedented) target for embedded > platforms. Well, I don't think VST is targetting just power management in embedded platforms. Even (virtualized) servers will benefit from this patch, by making use of the (virtual) CPU resources more efficiently. -- Thanks and Regards, Srivatsa Vaddagiri, Linux Technology Center, IBM Software Labs, Bangalore, INDIA - 560017 - 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 SCM saga..
Followup to: <[EMAIL PROTECTED]> By author:Chris Wedgwood <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > On Thu, Apr 07, 2005 at 09:42:04PM -0700, Linus Torvalds wrote: > > > Yes. The silly thing is, at least in my local tests it doesn't > > actually seem to be _doing_ anything while it's slow (there are no > > system calls except for a few memory allocations and > > de-allocations). It seems to have some exponential function on the > > number of pathnames involved etc. > > I see lots of brk calls changing the heap size, up, down, up, down, > over and over. > > This smells a bit like c++ new/delete behavior to me. > Hmmm... can glibc be clued in to do some hysteresis on the memory allocation? -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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, 2005-04-08 at 15:08 +1000, Herbert Xu wrote: > On Fri, Apr 08, 2005 at 09:11:56AM +0400, Evgeniy Polyakov wrote: > > > > > Yes but what will go wrong on uni-processor MIPS when you don't do the > > > sync in atomic_sub_return? > > > > Sync synchornizes cached mamory access, > > without it new value may be stored only into cache, > > but not into memory. > > I know, the same thing holds for most architectures, including i386. > However, this is not an issue for uni-processor kernels anywhere else, > so what's so special about MIPS? Does i386 or ppc has cached and uncached memory? No, i386, ppc and others do not require sync on uncached memory access, and only instruction not data cache sync on SMP. > Cheers, -- Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski signature.asc Description: This is a digitally signed message part
Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, Apr 08, 2005 at 09:11:56AM +0400, Evgeniy Polyakov wrote:
>
> > Yes but what will go wrong on uni-processor MIPS when you don't do the
> > sync in atomic_sub_return?
>
> Sync synchornizes cached mamory access,
> without it new value may be stored only into cache,
> but not into memory.
I know, the same thing holds for most architectures, including i386.
However, this is not an issue for uni-processor kernels anywhere else,
so what's so special about MIPS?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, 2005-04-08 at 14:53 +1000, Herbert Xu wrote: > On Fri, Apr 08, 2005 at 08:55:27AM +0400, Evgeniy Polyakov wrote: > > > > > > Unfortunately not, that sync is required exactly for return value store. > > > > > > On UP? > > > > Yes, some quotes: > > Yes but what will go wrong on uni-processor MIPS when you don't do the > sync in atomic_sub_return? Sync synchornizes cached mamory access, without it new value may be stored only into cache, but not into memory. > Cheers, -- Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski signature.asc Description: This is a digitally signed message part
Re: Kernel SCM saga..
On Thu, Apr 07, 2005 at 09:42:04PM -0700, Linus Torvalds wrote: > Yes. The silly thing is, at least in my local tests it doesn't > actually seem to be _doing_ anything while it's slow (there are no > system calls except for a few memory allocations and > de-allocations). It seems to have some exponential function on the > number of pathnames involved etc. I see lots of brk calls changing the heap size, up, down, up, down, over and over. This smells a bit like c++ new/delete behavior to me. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, 8 Apr 2005 14:53:02 +1000 Herbert Xu <[EMAIL PROTECTED]> wrote: > Yes but what will go wrong on uni-processor MIPS when you don't do the > sync in atomic_sub_return? Indeed. I see nothing in those quotes which indicate that the SYNC is needed on uniprocessor. It's only saying things such as "SYNC only affects load and store instructions" and "LL/SC can only be performed on cacheable memory". Stuff like that. - 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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, Apr 08, 2005 at 08:55:27AM +0400, Evgeniy Polyakov wrote:
>
> > > Unfortunately not, that sync is required exactly for return value store.
> >
> > On UP?
>
> Yes, some quotes:
Yes but what will go wrong on uni-processor MIPS when you don't do the
sync in atomic_sub_return?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 1/1] reiserfs: make resize option auto-get new device size
Cc: <[EMAIL PROTECTED]>, , <[EMAIL PROTECTED]>
It's trivial for the resize option to auto-get the underlying device size, while
it's harder for the user. I've copied the code from jfs.
Since of the different reiserfs option parser (which does not use the superior
match_token used by almost every other filesystem), I've had to use the
"resize=auto" and not "resize" option to specify this behaviour. Changing the
option parser to the kernel one wouldn't be bad but I've no time to do this
cleanup in this moment.
Btw, the mount(8) man page should be updated to include this option. Cc the
relevant people, please (I hope I cc'ed the right people).
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
---
linux-2.6.11-paolo/fs/reiserfs/super.c | 21 ++---
1 files changed, 14 insertions(+), 7 deletions(-)
diff -puN fs/reiserfs/super.c~reiserfs-resize-option-like-jfs-auto-get
fs/reiserfs/super.c
--- linux-2.6.11/fs/reiserfs/super.c~reiserfs-resize-option-like-jfs-auto-get
2005-04-07 20:37:58.0 +0200
+++ linux-2.6.11-paolo/fs/reiserfs/super.c 2005-04-08 01:01:18.0
+0200
@@ -889,12 +889,18 @@ static int reiserfs_parse_options (struc
char * p;
p = NULL;
- /* "resize=NNN" */
- *blocks = simple_strtoul (arg, , 0);
- if (*p != '\0') {
- /* NNN does not look like a number */
- reiserfs_warning (s, "reiserfs_parse_options: bad value %s",
arg);
- return 0;
+ /* "resize=NNN" or "resize=auto" */
+
+ if (!strcmp(arg, "auto")) {
+ /* From JFS code, to auto-get the size.*/
+ *blocks = s->s_bdev->bd_inode->i_size >>
s->s_blocksize_bits;
+ } else {
+ *blocks = simple_strtoul (arg, , 0);
+ if (*p != '\0') {
+ /* NNN does not look like a number */
+ reiserfs_warning (s, "reiserfs_parse_options: bad value
%s", arg);
+ return 0;
+ }
}
}
@@ -903,7 +909,8 @@ static int reiserfs_parse_options (struc
unsigned long val = simple_strtoul (arg, , 0);
/* commit=NNN (time in seconds) */
if ( *p != '\0' || val >= (unsigned int)-1) {
- reiserfs_warning (s, "reiserfs_parse_options: bad value
%s", arg); return 0;
+ reiserfs_warning (s, "reiserfs_parse_options: bad value
%s", arg);
+ return 0;
}
*commit_max_age = (unsigned int)val;
}
_
-
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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, 2005-04-08 at 14:17 +1000, Herbert Xu wrote: > On Fri, Apr 08, 2005 at 08:21:28AM +0400, Evgeniy Polyakov wrote: > > > > > > On UP do not. > > > > > > Shouldn't we should be fixing the MIPS implementation of > > > atomic_sub_return to not do the sync on UP then? > > > > Unfortunately not, that sync is required exactly for return value store. > > On UP? Yes, some quotes: The memory access type of a location affects the behavior of I-fetch, load, store, and prefetch operations to the location. In addition, memory access types affect some instruction descriptions. Load linked (LL, LLD) and store conditional (SC, SCD) have defined operation only for locations with cached memory access type. SYNC affects only load and stores made to locations with uncached or cached coherent memory access types. 3. The SC [comment: store conditional] stores a new value into the memory word, unless the new value has been modified. If the word has not been modified, the store succeeds and a 1 is stored in the destination register. Otherwise the Store Conditional fails, memory is not modified, and a 0 is loaded into the destination register. Since the instruction format has only a single field to select a data register (rt), this destination register is the same as the register which was stored. Load Linked and Store Conditional instructions (LL, LLD, SC, and SCD) do not implicitly perform SYNC operations in the R1 processor. -- Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski signature.asc Description: This is a digitally signed message part
Re: Kernel SCM saga..
On Thu, 7 Apr 2005, Chris Wedgwood wrote: > > I'm playing with monotone right now. Superficially it looks like it > has tons of gee-whiz neato stuff... however, it's *agonizingly* slow. > I mean glacial. A heavily sedated sloth with no legs is probably > faster. Yes. The silly thing is, at least in my local tests it doesn't actually seem to be _doing_ anything while it's slow (there are no system calls except for a few memory allocations and de-allocations). It seems to have some exponential function on the number of pathnames involved etc. I'm hoping they can fix it, though. The basic notions do not sound wrong. In the meantime (and because monotone really _is_ that slow), here's a quick challenge for you, and any crazy hacker out there: if you want to play with something _really_ nasty (but also very _very_ fast), take a look at kernel.org:/pub/linux/kernel/people/torvalds/. First one to send me the changelog tree of sparse-git (and a tool to commit and push/pull further changes) gets a gold star, and an honorable mention. I've put a hell of a lot of clues in there (*). I've worked on it (and little else) for the last two days. Time for somebody else to tell me I'm crazy. Linus (*) It should be easier than it sounds. The database is designed so that you can do the equivalent of a nonmerging (ie pure superset) push/pull with just plain rsync, so replication really should be that easy (if somewhat bandwidth-intensive due to the whole-file format). Never mind merging. It's not an SCM, it's a distribution and archival mechanism. I bet you could make a reasonable SCM on top of it, though. Another way of looking at it is to say that it's really a content- addressable filesystem, used to track directory trees. - 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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, 08 Apr 2005 07:52:34 +0400 Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > sparc64 has 32->64 conversation on exit. It's extremely cheap, the conversion instruction pairs with the retl instruction so it's essentially free. Talking about an arithmetic instruction over is complete nonsense when the atomic CAS instruction itself takes a minimum of 32 processor cycles :-) - 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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, 8 Apr 2005 14:17:24 +1000 Herbert Xu <[EMAIL PROTECTED]> wrote: > On UP? I think the barrier can be eliminated on MIPS on UP. - 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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, Apr 08, 2005 at 08:21:28AM +0400, Evgeniy Polyakov wrote:
>
> > > On UP do not.
> >
> > Shouldn't we should be fixing the MIPS implementation of
> > atomic_sub_return to not do the sync on UP then?
>
> Unfortunately not, that sync is required exactly for return value store.
On UP?
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, 2005-04-08 at 14:02 +1000, Herbert Xu wrote: > On Fri, Apr 08, 2005 at 08:02:49AM +0400, Evgeniy Polyakov wrote: > > > > > > mips has additional sync. > > > > > > But atomic_dec + 2 barries is going to do the sync as well, no? > > > > On UP do not. > > Shouldn't we should be fixing the MIPS implementation of > atomic_sub_return to not do the sync on UP then? Unfortunately not, that sync is required exactly for return value store. -- Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski signature.asc Description: This is a digitally signed message part
Re: Kernel SCM saga..
On Wed, Apr 06, 2005 at 08:42:08AM -0700, Linus Torvalds wrote: > PS. Don't bother telling me about subversion. If you must, start reading > up on "monotone". That seems to be the most viable alternative, but don't > pester the developers so much that they don't get any work done. They are > already aware of my problems ;) I'm playing with monotone right now. Superficially it looks like it has tons of gee-whiz neato stuff... however, it's *agonizingly* slow. I mean glacial. A heavily sedated sloth with no legs is probably faster. Using monotone to pull itself too over 2 hours wall-time and 71 minutes of CPU time. Arguably brand-new CPUs are probably about 2x the speed of what I have now and there might have been networking funnies --- but that's still 35 monutes to get ~40MB of data. The kernel is ten times larger, so does that mean to do a clean pull of the kernel we are looking at (71/2*10) ~ 355 minutes or 6 hours of CPU time? - 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Thu, Apr 07, 2005 at 08:05:31PM -0700, David Schwartz wrote: > I think we have a real problem, however, in cases where the source > file that holds only the firmware data contains a GPL notice. Sure: the GPL notice isn't completely valid. But I think people have already decided that this is an issue that needs to be fixed. And, I think most of the approach for fixing these is fairly clear. That said... perhaps it's worth going over a hierarchy of copyright issues: First, there's the issue of whether or not work is protected by copyright. I think we're talking about stuff that's protected by copyright. If it is protected by copyright, there's the question of whether the things being done with that work are regulated by copyright law. I think we're talking about activities (making copies of linux and distributing it) which are regulated by copyright law. If both hold, the next question is whether or not the copyright license allows this use. As you've indicated, we do have some real issues here. Finally, if you're dealing with regulated activity and the license doesn't allow it, it's up to the copyright holder to decide whether or not to prosecute. So far, the copyright holders haven't said much about these issues. We probably have some issues where what we're doing is only by the good graces of the copyright holder(s). We should fix those things, of course, but currently there aren't any deadlines we have to meet. -- Raul - 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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, Apr 08, 2005 at 08:02:49AM +0400, Evgeniy Polyakov wrote:
>
> > > mips has additional sync.
> >
> > But atomic_dec + 2 barries is going to do the sync as well, no?
>
> On UP do not.
Shouldn't we should be fixing the MIPS implementation of
atomic_sub_return to not do the sync on UP then?
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, 2005-04-08 at 13:50 +1000, Herbert Xu wrote: > On Fri, Apr 08, 2005 at 07:52:34AM +0400, Evgeniy Polyakov wrote: > > On Fri, 2005-04-08 at 13:32 +1000, Herbert Xu wrote: > > > On Fri, Apr 08, 2005 at 07:33:58AM +0400, Evgeniy Polyakov wrote: > > > > On Fri, 2005-04-08 at 12:59 +1000, Herbert Xu wrote: > > > > > Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > atomic_dec_and_test() is more expensive than 2 barriers + > > > > > > atomic_dec(), > > > > > > but in case of connector I think the price is not so high. > > > > > > > > > > Can you list the platforms on which this is true? > > > > > > > > sparc64, some mips [at least in UP]. > > > > > > Are you sure? The implementations of atomic_sub and atomic_sub_return > > > (which correspond to atomic_dec and atomic_dec_and_test) seem to be > > > comparable in cost on those two architectures. > > > > mips has additional sync. > > But atomic_dec + 2 barries is going to do the sync as well, no? On UP do not. > Cheers, -- Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski signature.asc Description: This is a digitally signed message part
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Scripsit "David Schwartz" <[EMAIL PROTECTED]> [quoting me] >> No, it is completely wrong to say that the object file is merely an >> aggregation. The two components are being coupled much more tightly >> than in the situation that the GPL discribes as "mere aggregation". > Would you maintain this position even if the firmware is identical > across operating systems and the Linux driver is identical across different > firmware builds for different hardware implementations? Yes I would. Linking forms a tighter coupling than just placing the two parts side by side on a filesystem designed for general storage of byte streams. There is more to say about the situation than the naked fact that that they are aggreated on the same medium; ergo the sutiation does not constitute *only* aggregation, and the "mere aggregation" language of the GPL does not apply. In particular, the end of GPL #2 does not provide a blanket exception for all forms of aggregation; it specifically speaks about aggregation "on a volume of a storage or distribution medium". > Note that the issue is not whether the GPL describes this as "mere > aggregation" because the GPL doesn't get to set its own scope. The scope of the copyright of the original work includes situation where part of that original work is being copied (excluding fair use and other jurisdiction-specific exceptions). In order to do such copying, you need permission from the copyright holder of the original work. If all the permission you have is the GPL, the copyihg you are doing had better fall into the class of copying that the GPL provides a permission for. It *is*, therefore, relevant, whether the GPL's special conditions for works "that in whole or in part contains the Program" apply to the linked object files. > The issue is whether the resulting binary is a single work (that is > derivative of the GPL'd driver) or whether it's two works with a > license boundary between them. A reasonable person can disagree about whether the word "work" in GPL #2(b) is meant to exclude non-trivial aggregations that do not add creative choice to that already expressed in the components. However, I don't think a reasonable person can argue that even if 2(b) had said "byte stream" instead of "work" it would not have been legally potent to demand GPL-compatible licensing of the firmware as a condition for the permission to copy the GPL-covered part of the byte stream. > It would not be obviously unreasonable to argue that the NE2000 API > constitutes a license boundary between the two works, each of which stays on > its own side of that API. No, it wouldn't be obviously unreasonable for a license to recognize such a "license boundary". However, as I see it the GPL happens not to do this. > Lacking clear court guidance, I see it as a threshold issue. One > primary issue (I think) is to what extent that firmware and the driver have > been customized for each other. A work that is carefully designed to mesh > tightly with another work is analogous to a sequel, which is a derivative > work. I think the "derivative work" angle is a red herring. I do not think that either of the two parts that are being linked together (i.e. the driver and the firmware) are derivates of the other. The relevant point is that distribution of the linked _result_ is nevertheless subject to the condition in GPL #2, which is in general the only source we have for a permission to distribute a non-verbatim-source form of the driver. -- Henning Makholm "... and that Greek, Thucydides" - 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] x86-64: i386 vDSO: add PT_NOTE segment
Assuming my previous patch goes into the native i386 vDSO, this patch makes the x86_64's 32-bit vDSO match it. Thanks, Roland Signed-off-by: Roland McGrath <[EMAIL PROTECTED]> --- linux-2.6/arch/x86_64/ia32/vsyscall-sigreturn.S +++ linux-2.6/arch/x86_64/ia32/vsyscall-sigreturn.S @@ -118,3 +118,6 @@ __kernel_rt_sigreturn: .align 4 .LENDFDE3: + +#include "../../i386/kernel/vsyscall-note.S" + - 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
> > Also, "mere aggregation" is a term from the GPL. You can read what > > it says there yourself. But basically it's there so that people make > > a distinction between the program itself and other stuff that isn't > > the program. On Thu, Apr 07, 2005 at 04:20:50PM -0700, David Schwartz wrote: > It's also there because the GPL can only apply to either works > placed under it by their authors and works that are legally classified > as derivative. If you merely aggregate two works, there is no > derivation. The GPL is making clear that it's not trying to exceed the > scope of its authority (which is copyright law). The issue of whether or not the combined work is a derivative under copyright law is a copyright law issue. The GPL does concern itself with that issue, but not in the "mere aggregation" clause. The "mere aggregation" clause holds regardless of whether or not the combined work is a derivative under copyright law. [P.S. I've set the Reply-To: header on this message because I think this thread has drifted away from kernel issues.] -- Raul - 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] i386 vDSO: add PT_NOTE segment
This patch adds an ELF note to the vDSO giving the LINUX_VERSION_CODE
value. Having this in the vDSO lets the dynamic linker avoid the `uname'
syscall it now always does at startup to ascertain the kernel ABI available.
Thanks,
Roland
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
--- linux-2.6/arch/i386/kernel/Makefile
+++ linux-2.6/arch/i386/kernel/Makefile
@@ -56,7 +56,8 @@ SYSCFLAGS_vsyscall-sysenter.so= $(vsysc
SYSCFLAGS_vsyscall-int80.so= $(vsyscall-flags)
$(obj)/vsyscall-int80.so $(obj)/vsyscall-sysenter.so: \
-$(obj)/vsyscall-%.so: $(src)/vsyscall.lds $(obj)/vsyscall-%.o FORCE
+$(obj)/vsyscall-%.so: $(src)/vsyscall.lds \
+ $(obj)/vsyscall-%.o $(obj)/vsyscall-note.o FORCE
$(call if_changed,syscall)
# We also create a special relocatable object that should mirror the symbol
@@ -67,5 +68,6 @@ $(obj)/built-in.o: $(obj)/vsyscall-syms.
$(obj)/built-in.o: ld_flags += -R $(obj)/vsyscall-syms.o
SYSCFLAGS_vsyscall-syms.o = -r
-$(obj)/vsyscall-syms.o: $(src)/vsyscall.lds $(obj)/vsyscall-sysenter.o FORCE
+$(obj)/vsyscall-syms.o: $(src)/vsyscall.lds \
+ $(obj)/vsyscall-sysenter.o $(obj)/vsyscall-note.o FORCE
$(call if_changed,syscall)
--- linux-2.6/arch/i386/kernel/vsyscall.lds.S
+++ linux-2.6/arch/i386/kernel/vsyscall.lds.S
@@ -23,7 +23,7 @@ SECTIONS
. = VSYSCALL_BASE + 0x400;
.text : { *(.text) } :text =0x90909090
-
+ .note : { *(.note.*) } :text :note
.eh_frame_hdr : { *(.eh_frame_hdr) } :text :eh_frame_hdr
.eh_frame : { KEEP (*(.eh_frame)) }:text
.dynamic: { *(.dynamic) }:text :dynamic
@@ -43,6 +43,7 @@ PHDRS
{
text PT_LOAD FILEHDR PHDRS FLAGS(5); /* PF_R|PF_X */
dynamic PT_DYNAMIC FLAGS(4); /* PF_R */
+ note PT_NOTE FLAGS(4); /* PF_R */
eh_frame_hdr 0x6474e550; /* PT_GNU_EH_FRAME, but ld doesn't match the name */
}
--- linux-2.6/arch/i386/kernel/vsyscall-note.S
+++ linux-2.6/arch/i386/kernel/vsyscall-note.S
@@ -0,0 +1,25 @@
+/*
+ * This supplies .note.* sections to go into the PT_NOTE inside the vDSO text.
+ * Here we can supply some information useful to userland.
+ */
+
+#include
+#include
+
+#define ASM_ELF_NOTE_BEGIN(name, flags, vendor, type)\
+ .section name, flags; \
+ .balign 4;\
+ .long 1f - 0f; /* name length */ \
+ .long 3f - 2f; /* data length */ \
+ .long type; /* note type */ \
+0: .asciz vendor; /* vendor name */ \
+1: .balign 4;\
+2:
+
+#define ASM_ELF_NOTE_END \
+3: .balign 4; /* pad out section */ \
+ .previous
+
+ ASM_ELF_NOTE_BEGIN(".note.kernel-version", "a", UTS_SYSNAME, 0)
+ .long LINUX_VERSION_CODE
+ ASM_ELF_NOTE_END
-
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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, Apr 08, 2005 at 07:52:34AM +0400, Evgeniy Polyakov wrote:
> On Fri, 2005-04-08 at 13:32 +1000, Herbert Xu wrote:
> > On Fri, Apr 08, 2005 at 07:33:58AM +0400, Evgeniy Polyakov wrote:
> > > On Fri, 2005-04-08 at 12:59 +1000, Herbert Xu wrote:
> > > > Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > atomic_dec_and_test() is more expensive than 2 barriers +
> > > > > atomic_dec(),
> > > > > but in case of connector I think the price is not so high.
> > > >
> > > > Can you list the platforms on which this is true?
> > >
> > > sparc64, some mips [at least in UP].
> >
> > Are you sure? The implementations of atomic_sub and atomic_sub_return
> > (which correspond to atomic_dec and atomic_dec_and_test) seem to be
> > comparable in cost on those two architectures.
>
> mips has additional sync.
But atomic_dec + 2 barries is going to do the sync as well, no?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Sven Luther <[EMAIL PROTECTED]> writes: > > It sounds like you are now looking at the question of are the > > huge string of hex characters the preferred form for making > > modifications to firmware. Personally I would be surprised > > but those hunks are small enough it could have been written > > in machine code. > > Yep, i also think it is in broadcom's best interest to modify the licencing > text accordyingly, since i suppose someone could technicaly come after them > legally to obtain said source code to this firmware. Unprobable though. Possibly. It sounds like that is what you want to do. > > So I currently have no reason to believe that anything has been > > done improperly with that code. > > Well, it all depends if you consider this firmware blob as software, which i > feel it is without doubt, or we have not the same definition of software, > i.e., the program which runs on the hardware, or not. We cannot claim this is > data, > > since there should be at least some kind of executable code in it, > independenlty of the fact that we claim that data is also software. Do you have any evidence that ``software'' was not written directly in machine code? Software is written directly in machine code when a programmer looks at the instruction set and writes down the binary representation of the instructions. I know ISC dhcpd has packet filter code that was written in that manner, so it is not a lost art. And it is done often enough when an assembler will not cooperate, and generate the correct instruction. Without evidence that we don't have the preferred form of the software for making modifications I don't see how you can complain. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, 2005-04-08 at 13:32 +1000, Herbert Xu wrote: > On Fri, Apr 08, 2005 at 07:33:58AM +0400, Evgeniy Polyakov wrote: > > On Fri, 2005-04-08 at 12:59 +1000, Herbert Xu wrote: > > > Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > > > > > > > > atomic_dec_and_test() is more expensive than 2 barriers + atomic_dec(), > > > > but in case of connector I think the price is not so high. > > > > > > Can you list the platforms on which this is true? > > > > sparc64, some mips [at least in UP]. > > Are you sure? The implementations of atomic_sub and atomic_sub_return > (which correspond to atomic_dec and atomic_dec_and_test) seem to be > comparable in cost on those two architectures. mips has additional sync. sparc64 has 32->64 conversation on exit. > Perhaps Dave can clarify for us about sparc64? Dave? > Cheers, -- Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski signature.asc Description: This is a digitally signed message part
Re: Kernel SCM saga..
Linus Torvalds wrote: In other words, this cherry-picking can generally be scripted and done "outside" the SCM (you can trivially have a script that takes a revision from one tree and applies it to the other). I don't believe that the SCM needs to support it in any fundamentally inherent manner. After all, why should it, when it really boilds down to (cd old-tree ; scm export-as-patch-plus-comments) | (cd new-tree ; scm import-patch-plus-comments) where the "patch-plus-comments" part is just basically an extended patch (including rename information etc, not just the comments). Not that it matters anymore, but that's precisely what the script Documentation/BK-usage/cpcset did, for BitKeeper. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/6] freepgt2: sys_mincore ignore FIRST_USER_PGD_NR
On Fri, 8 Apr 2005, Nick Piggin wrote: > David Howells wrote: > > Hugh Dickins <[EMAIL PROTECTED]> wrote: > > > > > Remove use of FIRST_USER_PGD_NR from sys_mincore: it's inconsistent > > > (no > > > other syscall refers to it), unnecessary (sys_mincore loops over vmas > > > further down) and incorrect (misses user addresses in ARM's first > > > pgd). > > > > You should make it use FIRST_USER_ADDRESS instead. This check allows NULL > > pointers and suchlike to be weeded out before having to take the > > semaphore. > > I'm not sure whether it is worth keeping the singular special > case here to slightly speed up what would probably be a bug in > a userspace program. Well put - though you're more diffident about it than I would be! Furthermore, it only allows NULL pointers and suchlike to be weeded out on the ARM (and ARM26) architecture, no other. I'm not averse to optimizing ARM and ARM26, but it's much too insignificant an optimization to warrant reference to such an architectural detail. And it breaks the (peculiar) sys_mincore convention of doing all the work while returning -ENOMEM, if there were any holes in the address range. David's check stops it from doing any work in that case. FIRST_USER_ADDRESS should be used in the very few places it is necessary, and not spread around beyond them. Hugh - 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/
Maximum data read/writes per SCSI Command
Hi, I wanted to increase the number of sectors that could be requested/Written per SCSI READ(10)/WRITE command , and varying MAX_SECTORS in blkdev.h helped me to do it. However I could not request more than 256 sectors and could not write more than 1632 inspite of changing MAX_SECTORS to higher numbers. (request_bufflen stands still at 835584 for every command) Why is that? There is probably some other variable that should be varied. Please let me know. I am working on the UNH iSCSI initiator driver , and am on kernel 2.4.29 . Sai __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Thu, 2005-04-07 at 11:47 -0400, James Morris wrote: > On Thu, 7 Apr 2005, Kay Sievers wrote: > > > Sure, but seems I need to ask again: What is the exact reason not to > > implement > > the muticast message multiplexing/subscription part of the connector as a > > generic part of netlink? That would be nice to have and useful for other > > subsystems too as an option to the current broadcast. > > This is a good point, in general, consider generically extending Netlink > itself instead of creating these separate things. I just do not understand, what does netlink multicasting means and how it is different from what we have now. Currently we have group registratin in bind(), and then send data to the bound socket if it has appropriate group. Or should some error be propagated to the caller, if there is no appropriate listener? Connector requires it's own registration technique for 1. hide all transport [netlink] layer from higher protocols which use connector 2. create different group appointment for the given connector's ID [it was different, now new group which is eqal to idx field is appointed to the new callback] 3. provide more generic set of ids > > - James -- Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski signature.asc Description: This is a digitally signed message part
Re: Kernel SCM saga..
Linus Torvalds wrote: On Thu, 7 Apr 2005, Daniel Phillips wrote: In that case, a nice refinement is to put the sequence number at the end of the subject line so patch sequences don't interleave: No. That makes it unsortable, and also much harder to pick put which part of the subject line is the explanation, and which part is just metadata for me. So my prefernce is _overwhelmingly_ for the format that Andrew uses (which is partly explained by the fact that I am used to it, but also by the fact that I've asked for Andrew to make trivial changes to match my usage). That canonical format is: Subject: [PATCH 001/123] [:] together with the first line of the body being a From: Original Author <[EMAIL PROTECTED]> Nod. For future reference, people can refer to http://linux.yyz.us/patch-format.html and/or http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt 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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, Apr 08, 2005 at 07:33:58AM +0400, Evgeniy Polyakov wrote:
> On Fri, 2005-04-08 at 12:59 +1000, Herbert Xu wrote:
> > Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> > >
> > > atomic_dec_and_test() is more expensive than 2 barriers + atomic_dec(),
> > > but in case of connector I think the price is not so high.
> >
> > Can you list the platforms on which this is true?
>
> sparc64, some mips [at least in UP].
Are you sure? The implementations of atomic_sub and atomic_sub_return
(which correspond to atomic_dec and atomic_dec_and_test) seem to be
comparable in cost on those two architectures.
Perhaps Dave can clarify for us about sparc64?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, 2005-04-08 at 12:59 +1000, Herbert Xu wrote: > Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > > > > atomic_dec_and_test() is more expensive than 2 barriers + atomic_dec(), > > but in case of connector I think the price is not so high. > > Can you list the platforms on which this is true? sparc64, some mips [at least in UP]. I do not know about others, but I think that any arch, where atomic operations are serialized, has sync/isync in atomic_dec_and_test() and does not for atomic_dec(). > Thanks, -- Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski signature.asc Description: This is a digitally signed message part
RE: non-free firmware in kernel modules, aggregation and unclear copyright notice.
> > No-one is saying that the linker "merely aggregates" object > > code for the driver; what *is* being said is: in the case of > > firmware, especially if the firmware is neither a derivative > > work on the kernel (see above) nor the firmware includes part > > of the kernel (duh), it is *fairly* *safe* to consider the > > intermixing of firmware bytes with kernel binary image bytes > > in an ELF object file as mere aggregation. > No, it is completely wrong to say that the object file is merely an > aggregation. The two components are being coupled much more tightly > than in the situation that the GPL discribes as "mere aggregation". Would you maintain this position even if the firmware is identical across operating systems and the Linux driver is identical across different firmware builds for different hardware implementations? Say, for example, Intel comes out with a new super-smart and sophisticated network card. They also offer firmware that makes it look just like an NE2000. They don't create this firmware for Linux, they create it for any set of operating systems that don't have specific drivers for this card. Similarly, the NE2000 driver wasn't specifically designed to use this firmware. Both the firmware and the driver were independently developed to implement the same de facto standard. Now, someone combines the firmware and the driver into a package that checks what card you are using, and if it has the appropriate firmware to make the card work with the driver, uploads it. Note that the issue is not whether the GPL describes this as "mere aggregation" because the GPL doesn't get to set its own scope. The issue is whether the resulting binary is a single work (that is derivative of the GPL'd driver) or whether it's two works with a license boundary between them. It would not be obviously unreasonable to argue that the NE2000 API constitutes a license boundary between the two works, each of which stays on its own side of that API. Lacking clear court guidance, I see it as a threshold issue. One primary issue (I think) is to what extent that firmware and the driver have been customized for each other. A work that is carefully designed to mesh tightly with another work is analogous to a sequel, which is a derivative work. I think we have a real problem, however, in cases where the source file that holds only the firmware data contains a GPL notice. DS - 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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> atomic_dec_and_test() is more expensive than 2 barriers + atomic_dec(),
> but in case of connector I think the price is not so high.
Can you list the platforms on which this is true?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] i386: Use loaddebug macro consistently
This moves the macro loaddebug from asm-i386/suspend.h to asm-i386/processor.h,
which is the place that makes sense for it to be defined, removes the
extra copy of the same macro in arch/i386/kernel/process.c, and makes
arch/i386/kernel/signal.c use the macro in place of its expansion.
This is a purely cosmetic cleanup for the normal i386 kernel.
However, it is handy for Xen to be able to just redefine the loaddebug
macro once instead of also changing the signal.c code.
Thanks,
Roland
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
--- linux-2.6/arch/i386/kernel/signal.c
+++ linux-2.6/arch/i386/kernel/signal.c
@@ -618,7 +618,7 @@ int fastcall do_signal(struct pt_regs *r
* inside the kernel.
*/
if (unlikely(current->thread.debugreg[7])) {
- __asm__("movl %0,%%db7" : : "r"
(current->thread.debugreg[7]));
+ loaddebug(>thread, 7);
}
/* Whee! Actually deliver the signal. */
--- linux-2.6/arch/i386/kernel/process.c
+++ linux-2.6/arch/i386/kernel/process.c
@@ -548,13 +548,6 @@ handle_io_bitmap(struct thread_struct *n
*/
tss->io_bitmap_base = INVALID_IO_BITMAP_OFFSET_LAZY;
}
-/*
- * This special macro can be used to load a debugging register
- */
-#define loaddebug(thread,register) \
- __asm__("movl %0,%%db" #register \
- : /* no output */ \
- :"r" (thread->debugreg[register]))
/*
* switch_to(x,yn) should switch tasks from x to y.
--- linux-2.6/include/asm-i386/processor.h
+++ linux-2.6/include/asm-i386/processor.h
@@ -499,6 +499,14 @@ static inline void load_esp0(struct tss_
regs->esp = new_esp;\
} while (0)
+/*
+ * This special macro can be used to load a debugging register
+ */
+#define loaddebug(thread,register) \
+ __asm__("movl %0,%%db" #register \
+ : /* no output */ \
+ :"r" ((thread)->debugreg[register]))
+
/* Forward declaration, a strange C thing */
struct task_struct;
struct mm_struct;
--- linux-2.6/include/asm-i386/suspend.h
+++ linux-2.6/include/asm-i386/suspend.h
@@ -36,11 +36,6 @@ struct saved_context {
unsigned long return_address;
} __attribute__((packed));
-#define loaddebug(thread,register) \
- __asm__("movl %0,%%db" #register \
- : /* no output */ \
- :"r" ((thread)->debugreg[register]))
-
#ifdef CONFIG_ACPI_SLEEP
extern unsigned long saved_eip;
extern unsigned long saved_esp;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.6.11-ck4
These are patches designed to improve system responsiveness. It is configurable to any workload but the default ck* patch is aimed at the desktop and ck*-server is available with more emphasis on serverspace. Apply to 2.6.11: http://ck.kolivas.org/patches/2.6/2.6.11/2.6.11-ck4/patch-2.6.11-ck4.bz2 http://ck.kolivas.org/patches/2.6/2.6.11/2.6.11-ck4/patch-2.6.11-ck4-server.bz2 web: http://kernel.kolivas.org all patches: http://ck.kolivas.org/patches/ Split patches available. Changes since 2.6.11-ck2 (last public announcement): Changed: ~schediso2.12.diff Small policy fix to ensure real time tasks without privileges get dropped to SCHED_ISO Added: +cfq-ts21-fix1.diff +cfq-ts21-fix2.diff Two small cfq bugfixes +s10.6_s10.7.diff Micro-optimisations for staircase cpu scheduler +patch-2.6.11.7 Latest stable version +2611ck4-version.diff Version Removed: -nvidia_6111-6629_compat2.diff Nvidia compatibility no longer required with new nvidia driver -patch-2.6.11.1 -patch-2.6.11.2 -2611ck2-version.diff obvious Full patchlist: 2.6.11_to_staircase10.5.diff s10.5_s10.6.diff s10.6_s10.7.diff Latest version of the staircase O(1) single priority array foreground-background cpu scheduler schedrange.diff Eases addition of scheduling policies schedbatch2.7.diff Idle cpu scheduling schediso2.12.diff Unprivileged low latency cpu scheduling mapped_watermark3.diff Lighter memory scanning under light loads and far less swapping 1g_lowmem1_i386.diff Support 1GB of memory without enabling HIGHMEM cddvd-cmdfilter-drop.patch Support normal user burning of cds cfq-ts-21.diff cfq-ts21-fix.diff cfq-ts21-fix1.diff cfq-ts21-fix2.diff Complete fair queueing timeslice i/o scheduler v21 defaultcfq.diff Enable the cfq I/O scheduler by default (-ck) default_deadline.diff Enable the deadline I/O scheduler by default (-server) isobatch_ionice2.diff Support for i/o priorities suitable for SCHED_ISO and SCHED_BATCH tasks rt_ionice.diff Support for i/o priority suitable for real time tasks patch-2.6.11.7 The latest stable tree. 2611ck4-version.diff Version and available separately in the patches/ dir as an addon: supermount-ng208-2611.diff Simplest way to automount removable media And don't forget to pour one of these before booting this kernel: http://ck.kolivas.org/patches/2.6/2.6.11/cognac.JPG Cheers, Con pgp05SgPDKeKS.pgp Description: PGP signature
Re: init process freezed after run_init_process
Apply these rules: 1.) If you do provide an initrd= thing, the initrd is being looked for /linuxrc. I have add /linuxrc, /init and /bin/init, all link to /sbin/init. It just refuses to work ... :( Only VIA IDE chipset maybe, but you don't usually need that for just-initrd. You'd need that for the harddisks... My harddisk works fine without initrd. Make your own initrd and put a bash into it. Then start that, e.g. (for our linux live cd), initrd=initrd.sqfs root=/dev/ram0 init=/bin/bash I have tried these kernel parameters: init=/bin/bash init=/linuxrc init=/init init=/sbin/init None works. Also, after some google, I found that the format of initrd has changed. I also tried a new initrd with cpio format. The kernel recognized it: Boot Logs: 1) checking if image is initramfs... it is Freeing initrd memory: 17583k freed 2) loading drivers 3) Freeing unused kernel memory: 128k freed After the kernel start, I add breakpoints at cpu_idle and do_schedule. cpu_idle never reached, only do_schedule did. Is that strange? - 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.12-rc2-mm1
On Thu, 2005-04-07 at 18:08 -0700, Siddha, Suresh B wrote: > On Thu, Apr 07, 2005 at 03:11:12AM +1000, Nick Piggin wrote: > > Using the attached patch, a puny dual PIII-650 with ~400MB RAM swapped > > itself to death after 2 infinite loop tasks had been pinned to one > > of the CPUs. See how you go. > > Its goes well beyond the initial 7000 number I mentioned. Thanks. > OK, good thanks for testing that. I'll send it to Andrew. > One side-effect of this patch is: for example we have only two processes > running on a cpu and both are pinned to that cpu. If someone comes and > changes the affinity of one of these processes to all cpu's in the system, > then it might take MAX_PINNED_INTERVAL before this process moves to an idle > cpu. > Yeah, that is true. OTOH it is a bit of a special case, and our multiprocessor scheduling in general practically shuts down when we have a situation with a single queue with a lot of pinned tasks. What did I have for MAX_PINNED_INTERVAL? ~1second. I guess that could come down a bit - maybe 1/4 or 1/2 a second? I think it is a "good enough for now" kind of situation. -- SUSE Labs, Novell Inc. - 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] sched: auto-tune migration costs [was: Re: Industry db benchmark result on recent 2.6 kernels]
Ingo Molnar wrote on Tuesday, April 05, 2005 11:46 PM
> ok, the delay of 16 secs is alot better. Could you send me the full
> detection log, how stable is the curve?
Full log attached.
begin 666 boot.log
M0F]O="!PF5D($E40R!W:71H($-052 P("AL87-T(&1I9F8@,R!C>6-L97,L(>&5R
M@I#86QI8G)A=
M9R!D96QA>2!L;V]P+BXN(#(R-#$N,#@@0F]G;TU)4%,@*:CTQ,#DS-C,R
M*0I#4%4@,CH@F5D($E40R!W:71H($-052 P("AL87-T(&1I
M9F8@,R!C>6-L97,L(>&5R@I#86QI8G)A=!D96QA>2!L;V]P+BXN(#(R-#$N,#@@0F]G
M;TU)4%,@*:CTQ,#DS-C,R*0I#4%4@,SH@F5D($E40R!W
M:71H($-052 P("AL87-T(&1I9F8@,R!C>6-L97,L(>&5R@I#86QI8G)A=!D96QA>2!L
M;V]P+BXN(#(R-#$N,#@@0F]G;TU)4%,@*:CTQ,#DS-C,R*0I"%]C86-H95]S:7IE.B Y-#,W,[EMAIL
PROTECTED]"!C<'4Z
M("TQ($U(>BDZ"BTM+2TM+2TM+2TM+2TM+2TM+2TM+0H@(" @(" @(" @6S P
M72 @("!;,#%=(" @(%LP,ET@(" @6S S70I;,#!=.B @(" @+2 @(" @.2XS
M*# I(" Y+C,H,"D@(#DN,[EMAIL PROTECTED];,#%=.B @(#DN,[EMAIL PROTECTED] @(" M("
@(" Y
M+C,H,"D@(#DN,[EMAIL PROTECTED];,#)=.B @(#DN,[EMAIL PROTECTED] @.2XS*# I("
@("T@(" @
M(#DN,[EMAIL PROTECTED];,#-=.B @(#DN,[EMAIL PROTECTED] @.2XS*# I(" Y+C,H,"D@("
@+2 @
M( HM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+0I\(&-A8VAE9FQU
Mhttp://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Scripsit Humberto Massa <[EMAIL PROTECTED]> > After a *lot* of discussion, it was deliberated on d-l that > this is not that tricky at all, and that the "mere > aggregation" clause applies to the combination, for various > reasons, with a great degree of safety. When was this alleged conclusion reached? I remember nothing like that. > No-one is saying that the linker "merely aggregates" object > code for the driver; what *is* being said is: in the case of > firmware, especially if the firmware is neither a derivative > work on the kernel (see above) nor the firmware includes part > of the kernel (duh), it is *fairly* *safe* to consider the > intermixing of firmware bytes with kernel binary image bytes > in an ELF object file as mere aggregation. No, it is completely wrong to say that the object file is merely an aggregation. The two components are being coupled much more tightly than in the situation that the GPL discribes as "mere aggregation". -- Henning Makholm "Hør, hvad er det egentlig der ikke kan blive ved med at gå?" - 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] inotify for 2.6.11
On Thu, 2005-04-07 at 18:37 -0700, Rusty Lynch wrote: > Looking into this a little more I realized that the lack of /proc > notifications (for processes coming and going) is a common problem anytime > a file is modified without going through the VFS. Other examples are > remote file changes on a mounted NFS partition, remote file changes on a > mounted cluster filesystem (like ocfs or gfs), and just about any virtual > file system where the kernel is adding/deleting/modifying files from below > the VFS. Indeed it is. But none of those are anything that we care about (except maybe /proc). The problem of changes on remote filesystems is solved by FAM. Robert Love - 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: alsa es1371's joystick functionality broken in 2.6.11-mm4
On Thursday 07 April 2005 03:52 pm, Ian Pilcher wrote: > Any chance the joystick is just broken? Nope. What works: 1) _Both_ joysticks (one that uses the analog driver, the other that uses the sidewinder driver) work fine under Win2k. 2) Sound works under both Linux and Win2k. 3) The analog joystick (I didn't have the sidewinder yet) use to work at some point in the past on this system with a 2.6 kernel. What doesn't work: 1) Either the analog or sidewinder joysticks using any kernel I've tested so far, loading snd_ens1371 using either joystick=1 or joystick_port=1 (I test both out of habit). (Loaded in the order of snd_ens1371 (which loads gameport), joydev, and then analog or sidewinder. Putting joydev or gameport or both before snd_ens1371 doesn't improve the situation.) -- Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED] "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989 pgpnzCb9kXSAy.pgp Description: PGP signature
Re: [PATCH] radeonfb: (#2) Implement proper workarounds for PLL accesses
On Fri, 2005-04-08 at 01:58 +0200, Andreas Schwab wrote:
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
>
> > Yes, that's very extreme, I suspect somebody is banging on set_par or
> > something like that.
>
> fb_setcolreg is it.
Ok, what about that patch:
---
This patch adds to the fbdev interface a set_cmap callback that allow
the driver to "batch" palette changes. This is useful for drivers like
radeonfb which might require lenghtly workarounds on palette accesses,
thus allowing to factor out those workarounds efficiently.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Index: linux-work/include/linux/fb.h
===
--- linux-work.orig/include/linux/fb.h 2005-04-01 09:04:19.0 +1000
+++ linux-work/include/linux/fb.h 2005-04-08 10:24:56.0 +1000
@@ -563,6 +563,9 @@
int (*fb_setcolreg)(unsigned regno, unsigned red, unsigned green,
unsigned blue, unsigned transp, struct fb_info
*info);
+ /* set color registers in batch */
+ int (*fb_setcmap)(struct fb_cmap *cmap, struct fb_info *info);
+
/* blank display */
int (*fb_blank)(int blank, struct fb_info *info);
Index: linux-work/drivers/video/aty/radeon_base.c
===
--- linux-work.orig/drivers/video/aty/radeon_base.c 2005-04-01
09:04:18.0 +1000
+++ linux-work/drivers/video/aty/radeon_base.c 2005-04-08 11:15:13.0
+1000
@@ -1057,13 +1057,14 @@
return radeon_screen_blank(rinfo, blank, 0);
}
-static int radeonfb_setcolreg (unsigned regno, unsigned red, unsigned green,
- unsigned blue, unsigned transp, struct fb_info
*info)
+static int radeon_setcolreg (unsigned regno, unsigned red, unsigned green,
+ unsigned blue, unsigned transp,
+struct radeonfb_info *rinfo)
{
-struct radeonfb_info *rinfo = info->par;
u32 pindex;
unsigned int i;
-
+
+
if (regno > 255)
return 1;
@@ -1078,20 +1079,7 @@
pindex = regno;
if (!rinfo->asleep) {
- u32 dac_cntl2, vclk_cntl = 0;
-
radeon_fifo_wait(9);
- if (rinfo->is_mobility) {
- vclk_cntl = INPLL(VCLK_ECP_CNTL);
- OUTPLL(VCLK_ECP_CNTL, vclk_cntl &
~PIXCLK_DAC_ALWAYS_ONb);
- }
-
- /* Make sure we are on first palette */
- if (rinfo->has_CRTC2) {
- dac_cntl2 = INREG(DAC_CNTL2);
- dac_cntl2 &= ~DAC2_PALETTE_ACCESS_CNTL;
- OUTREG(DAC_CNTL2, dac_cntl2);
- }
if (rinfo->bpp == 16) {
pindex = regno * 8;
@@ -1101,24 +1089,27 @@
if (rinfo->depth == 15 && regno > 31)
return 1;
- /* For 565, the green component is mixed one order
below */
+ /* For 565, the green component is mixed one order
+* below
+*/
if (rinfo->depth == 16) {
OUTREG(PALETTE_INDEX, pindex>>1);
- OUTREG(PALETTE_DATA,
(rinfo->palette[regno>>1].red << 16) |
- (green << 8) |
(rinfo->palette[regno>>1].blue));
+ OUTREG(PALETTE_DATA,
+ (rinfo->palette[regno>>1].red << 16) |
+ (green << 8) |
+ (rinfo->palette[regno>>1].blue));
green = rinfo->palette[regno<<1].green;
}
}
if (rinfo->depth != 16 || regno < 32) {
OUTREG(PALETTE_INDEX, pindex);
- OUTREG(PALETTE_DATA, (red << 16) | (green << 8) | blue);
+ OUTREG(PALETTE_DATA, (red << 16) |
+ (green << 8) | blue);
}
- if (rinfo->is_mobility)
- OUTPLL(VCLK_ECP_CNTL, vclk_cntl);
}
if (regno < 16) {
- u32 *pal = info->pseudo_palette;
+ u32 *pal = rinfo->info->pseudo_palette;
switch (rinfo->depth) {
case 15:
pal[regno] = (regno << 10) | (regno << 5) | regno;
@@ -1138,6 +1129,84 @@
return 0;
}
+static int radeonfb_setcolreg (unsigned regno, unsigned red, unsigned green,
+ unsigned blue, unsigned transp,
+ struct fb_info *info)
+{
+struct radeonfb_info *rinfo = info->par;
+ u32 dac_cntl2, vclk_cntl = 0;
+ int rc;
+
+if
Re: [RFC,PATCH 3/4] Change synchronize_kernel to _rcu and _sched
On Fri, Apr 08, 2005 at 01:16:53AM +0200, Francois Romieu wrote: > Paul E. McKenney <[EMAIL PROTECTED]> : > > This patch changes calls to synchronize_kernel(), deprecated in the > > earlier "Deprecate synchronize_kernel, GPL replacement" patch to > > instead call the new synchronize_rcu() and synchronize_sched() APIs. > [...] > > diff -urpN -X dontdiff linux-2.6.12-rc1/drivers/net/r8169.c > > linux-2.6.12-rc1-bettersk/drivers/net/r8169.c > > --- linux-2.6.12-rc1/drivers/net/r8169.cThu Mar 31 09:53:08 2005 > > +++ linux-2.6.12-rc1-bettersk/drivers/net/r8169.c Fri Apr 1 21:41:38 2005 > > @@ -2385,7 +2385,7 @@ core_down: > > } > > > > /* Give a racing hard_start_xmit a few cycles to complete. */ > > - synchronize_kernel(); > > + synchronize_sched(); /* FIXME: should this be synchronize_irq()? */ > > > > /* > > * And now for the 50k$ question: are IRQ disabled or not ? > > (answering the FIXME) > > The race with the irq is handled somewhere else. As the comment suggests, > this part is racing with the hard_start_xmit() handler. If I read correctly > net/core/dev.c::dev_queue_xmit, the code above simply needs the new > synchronize_rcu(). That would be good! In your reading of the code, did you verify that all instances of calls to hard_start_xmit() are in fact under either rcu_read_lock() or rcu_read_lock_bh()? Thanx, Paul - 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.12-rc2-mm1
On Thu, Apr 07, 2005 at 03:11:12AM +1000, Nick Piggin wrote: > Using the attached patch, a puny dual PIII-650 with ~400MB RAM swapped > itself to death after 2 infinite loop tasks had been pinned to one > of the CPUs. See how you go. Its goes well beyond the initial 7000 number I mentioned. Thanks. One side-effect of this patch is: for example we have only two processes running on a cpu and both are pinned to that cpu. If someone comes and changes the affinity of one of these processes to all cpu's in the system, then it might take MAX_PINNED_INTERVAL before this process moves to an idle cpu. thanks, suresh - 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 SCM saga..
On Thursday, April 7, 2005 9:40 am, Rik van Riel wrote: > Larry, thanks for the help you have given us by making > bitkeeper available for all these years. A big thank you from me too, I've really enjoyed using BK and I think it's made me much more productive than I would have been otherwise. I don't envy you having to put up with the frequent flamefests... Jesse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga..
On Wed, Apr 06, 2005 at 08:42:08AM -0700, Linus Torvalds wrote: > If you must, start reading up on "monotone". One slightly annoying thing is that monotone doesn't appear to have a web interface. I used to use the bk one a lot when tracking down bugs, because it was really fast to have a web browser window open and click through the revisions of a file reading checkin comments, etc. Does anyone know if one is being worked on? bazaar-ng at least mention this is important in their design docs and arch has one in development too. -i [EMAIL PROTECTED] http://www.gelato.unsw.edu.au signature.asc Description: Digital signature
VRRP multiple VIP VMAC problem
Hi, I am working on VRRP and want to set multiple VIP <==> VMAC on a single interface, is it possible The mailing list had one thread long time back which was taking about a kernel patch for this, but I don't if this is done or not. What options do I have for doing the above? Thanks, Kalyanjeet Gogoi - 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] mtime attribute is not being updated on client
Hi Trond,
The acregmin (default=3) and acregmax (default=60) NFS attributes that
control the min and max attribute cache lifetimes don't appear to be
working after the first few timeouts. Using a test program that loops
on the following sequence:
- write to a file on an NFS3 mounted filesystem from the client
- sleep for one second
- stat the file to get the mtime
you see the mtime change once after ~56 seconds, but no further mtime
changes are detected by the test.
nfs_refresh_inode() currently bypasses the inode vs fattr mtime comparison
if data_unstable is true. At the end of nfs_refresh_inode(), it resets the
attribute timer. Since nfs_refresh_inode() is being called after every
write to the server (which occurs more often than the attribute timer is
set to expire), the attribute timer never expires again for this file past
the ~56 sec point.
In nfs_refresh_inode() I believe the mtime comparison should be moved outside
the check for data_unstable. The server might already have a newer value for
mtime than the value on the client. With this change, the test sees the mtime
change after each write completes on the server.
Regards,
Linda
The following patch is for 2.6.12-rc2:
diff -Nura base/fs/nfs/inode.c new/fs/nfs/inode.c
--- base/fs/nfs/inode.c 2005-04-07 16:04:40.933611205 -0400
+++ new/fs/nfs/inode.c 2005-04-07 16:12:34.484299540 -0400
@@ -1176,9 +1176,11 @@
}
/* Verify a few of the more important attributes */
+ if (!timespec_equal(>i_mtime, >mtime))
+ nfsi->flags |= NFS_INO_INVALID_ATTR;
+
if (!data_unstable) {
- if (!timespec_equal(>i_mtime, >mtime)
- || cur_size != new_isize)
+ if (cur_size != new_isize)
nfsi->flags |= NFS_INO_INVALID_ATTR;
} else if (S_ISREG(inode->i_mode) && new_isize > cur_size)
nfsi->flags |= NFS_INO_INVALID_ATTR;
-
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 6/6] mm/bootmem.c: use generic round_up_pow2() macro
From: Nick Wilson <[EMAIL PROTECTED]>
Use the generic round_up_pow2() instead of a custom rounding method.
Signed-off-by: Nick Wilson <[EMAIL PROTECTED]>
---
bootmem.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
Index: linux/mm/bootmem.c
===
--- linux.orig/mm/bootmem.c 2005-04-07 15:13:56.0 -0700
+++ linux/mm/bootmem.c 2005-04-07 15:46:41.0 -0700
@@ -57,7 +57,7 @@ static unsigned long __init init_bootmem
pgdat->pgdat_next = pgdat_list;
pgdat_list = pgdat;
- mapsize = (mapsize + (sizeof(long) - 1UL)) & ~(sizeof(long) - 1UL);
+ mapsize = round_up_pow2(mapsize, sizeof(long));
bdata->node_bootmem_map = phys_to_virt(mapstart << PAGE_SHIFT);
bdata->node_boot_start = (start << PAGE_SHIFT);
bdata->node_low_pfn = end;
@@ -178,7 +178,7 @@ __alloc_bootmem_core(struct bootmem_data
} else
preferred = 0;
- preferred = ((preferred + align - 1) & ~(align - 1)) >> PAGE_SHIFT;
+ preferred = round_up_pow2(preferred, align) >> PAGE_SHIFT;
preferred += offset;
areasize = (size+PAGE_SIZE-1)/PAGE_SIZE;
incr = align >> PAGE_SHIFT ? : 1;
@@ -219,7 +219,7 @@ found:
*/
if (align < PAGE_SIZE &&
bdata->last_offset && bdata->last_pos+1 == start) {
- offset = (bdata->last_offset+align-1) & ~(align-1);
+ offset = round_up_pow2(bdata->last_offset, align);
BUG_ON(offset > PAGE_SIZE);
remaining_size = PAGE_SIZE-offset;
if (size < remaining_size) {
_
-
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 5/6] lib/bitmap.c: use generic round_up_pow2() macro
From: Nick Wilson <[EMAIL PROTECTED]>
Use the generic round_up_pow2() instead of a custom rounding method.
Signed-off-by: Nick Wilson <[EMAIL PROTECTED]>
---
bitmap.c |3 +--
1 files changed, 1 insertion(+), 2 deletions(-)
Index: linux/lib/bitmap.c
===
--- linux.orig/lib/bitmap.c 2005-04-07 15:13:56.0 -0700
+++ linux/lib/bitmap.c 2005-04-07 15:46:15.0 -0700
@@ -289,7 +289,6 @@ EXPORT_SYMBOL(__bitmap_weight);
#define CHUNKSZ32
#define nbits_to_hold_value(val) fls(val)
-#define roundup_power2(val,modulus)(((val) + (modulus) - 1) & ~((modulus)
- 1))
#define unhex(c) (isdigit(c) ? (c - '0') : (toupper(c) -
'A' + 10))
#define BASEDEC 10 /* fancier cpuset lists input in decimal */
@@ -316,7 +315,7 @@ int bitmap_scnprintf(char *buf, unsigned
if (chunksz == 0)
chunksz = CHUNKSZ;
- i = roundup_power2(nmaskbits, CHUNKSZ) - CHUNKSZ;
+ i = round_up_pow2(nmaskbits, CHUNKSZ) - CHUNKSZ;
for (; i >= 0; i -= CHUNKSZ) {
chunkmask = ((1ULL << chunksz) - 1);
word = i / BITS_PER_LONG;
_
-
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/6] add generic round_up_pow2() macro
Nick Wilson <[EMAIL PROTECTED]> wrote: > > The first patch adds a generic round_up_pow2() macro to kernel.h. The > remaining patches modify a few files to make use of the new macro. We already have ALIGN() and roundup_pow_of_two(). - 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 4/6] kernel/resource.c: use generic round_up_pow2() macro
From: Nick Wilson <[EMAIL PROTECTED]>
Use the generic round_up_pow2() instead of a custom rounding method.
Signed-off-by: Nick Wilson <[EMAIL PROTECTED]>
---
resource.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Index: linux/kernel/resource.c
===
--- linux.orig/kernel/resource.c2005-04-07 15:13:56.0 -0700
+++ linux/kernel/resource.c 2005-04-07 15:45:57.0 -0700
@@ -263,7 +263,7 @@ static int find_resource(struct resource
new->start = min;
if (new->end > max)
new->end = max;
- new->start = (new->start + align - 1) & ~(align - 1);
+ new->start = round_up_pow2(new->start, align);
if (alignf)
alignf(alignf_data, new, size, align);
if (new->start < new->end && new->end - new->start + 1 >= size)
{
_
-
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/6] include/linux/a.out.h: use generic round_up_pow2() macro
From: Nick Wilson <[EMAIL PROTECTED]>
Use the generic round_up_pow2() instead of a custom rounding method.
Signed-off-by: Nick Wilson <[EMAIL PROTECTED]>
---
a.out.h |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Index: linux/include/linux/a.out.h
===
--- linux.orig/include/linux/a.out.h2005-04-07 15:37:22.0 -0700
+++ linux/include/linux/a.out.h 2005-04-07 15:45:34.0 -0700
@@ -138,7 +138,7 @@ enum machine_type {
#endif
#endif
-#define _N_SEGMENT_ROUND(x) (((x) + SEGMENT_SIZE - 1) & ~(SEGMENT_SIZE - 1))
+#define _N_SEGMENT_ROUND(x) round_up_pow2(x, SEGMENT_SIZE)
#define _N_TXTENDADDR(x) (N_TXTADDR(x)+(x).a_text)
_
-
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/6] include/linux/kernel.h: use generic round_up_pow2() macro
From: Nick Wilson <[EMAIL PROTECTED]>
Add a generic macro to kernel.h to round up to the next multiple of n.
Signed-off-by: Nick Wilson <[EMAIL PROTECTED]>
---
kernel.h |5 +
1 files changed, 5 insertions(+)
Index: linux/include/linux/kernel.h
===
--- linux.orig/include/linux/kernel.h 2005-04-07 15:13:56.0 -0700
+++ linux/include/linux/kernel.h2005-04-07 15:47:15.0 -0700
@@ -246,6 +246,11 @@ extern void dump_stack(void);
#define max_t(type,x,y) \
({ type __x = (x); type __y = (y); __x > __y ? __x: __y; })
+/*
+ * Round x up to the next multiple of n.
+ * n must be a power of 2.
+ */
+#define round_up_pow2(x,n) (((x) + (n) - 1) & ~((n) - 1))
/**
* container_of - cast a member of a structure out to the containing structure
_
-
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/6] include/linux/kernel.h: use generic round_up_pow2() macro
From: Nick Wilson <[EMAIL PROTECTED]> Use the generic round_up_pow2() instead of a custom rounding method. Signed-off-by: Nick Wilson <[EMAIL PROTECTED]> --- kernel.h |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) Index: linux/include/linux/kernel.h === --- linux.orig/include/linux/kernel.h 2005-04-07 15:44:05.0 -0700 +++ linux/include/linux/kernel.h2005-04-07 15:44:53.0 -0700 @@ -28,7 +28,7 @@ extern const char linux_banner[]; #define STACK_MAGIC0xdeadbeef #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0])) -#define ALIGN(x,a) (((x)+(a)-1)&~((a)-1)) +#define ALIGN round_up_pow2 #defineKERN_EMERG "<0>" /* system is unusable */ #defineKERN_ALERT "<1>" /* action must be taken immediately */ _ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.12-rc2
On Apr 7, 2005 3:45 PM, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > On Thu, 2005-04-07 at 11:54 -0700, Nish Aravamudan wrote: > > On Apr 7, 2005 10:50 AM, Moritz Muehlenhoff <[EMAIL PROTECTED]> wrote: > > > Benjamin Herrenschmidt wrote: > > > > > 1. When resuming from S3 suspend and having switched off the backlight > > > > > with radeontool the backlight isn't switched back on any more. > > > > > > > > I'm not sure what's up here, it's a nasty issue with backlight. Can > > > > radeontool bring it back ? > > > > > > Before suspending I power down the backlight with "radeontool light off" > > > and with 2.6.11 the display is properly restored. With 2.6.12rc2 the > > > backlight remains switched off and if I switch it on with radeontool it > > > becomes lighter, but there's still no text from the fbcon, just the blank > > > screen. > > > > FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2, > > except that neither returns from suspend-to-ram with video restored on > > the LCD. I believe I was able to get video restored on an external CRT > > in either 2.6.12-rc2 or 2.6.12-rc2-mm1, but the LCD still didn't > > restore (can verify later today, if you'd like). I had dumped out the > > radeontool regs values before & after the sleep, in case they help. > > They are attached. > > > > I posted these problems in the "Call for help S3" thread, but no one > > responded. > > I would say the different value in LVDS_GEN_CNTL explains it. I'll see > if I can force radeonfb to save/restore this. Great! That seemed odd to me, as well. I'll be more than happy to try any patches (I'll take a look at the code tonight myself). Thanks, Nish - 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/6] add generic round_up_pow2() macro
Randy.Dunlap wrote: > >+#define ALIGN_DATA_SIZE(size) ((size + PAGE_SIZE - 1) & ~(PAGE_SIZE - > >1)) > > > ISTM that we need a generic round_up() function or macro in kernel.h. > > > > a.out.h, reiserfs_fs.h, and ufs_fs.h all have their own round-up > > macros. > I've found many more places in the kernel that use their own functions for doing this. These patches are the beginning of an attempt to clean these up. The first patch adds a generic round_up_pow2() macro to kernel.h. The remaining patches modify a few files to make use of the new macro. Comments welcome. Thanks, Nick - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PMTU, MSS and "fragmentation needed" problem with linux?
Thanks for the hints Florian, but still there are open questions: Florian Attenberger [Thu, Apr 07, 2005 at 07:33:09PM +0200]: > [...] > # [From the kernel help: > # > #This option adds a `TCPMSS' target, which allows you to alter the > #MSS value of TCP SYN packets, to control the maximum size for that > #connection (usually limiting it to your outgoing interface's MTU > #minus 40). The MTU is 1460 or 1492 in tested cases. This means on ppp0, TCPMSS should be 1420 or maximum of 1452. Why do I see 1460 on the interface? > #This is used to overcome criminally braindead ISPs or servers which > #block ICMP Fragmentation Needed packets. That's clear to me, there are sites out there, debatting that problem. But: - Should not _my_ Linux-router tell _my_ client that the mtu choosen is too big? - On the tested connections _all_ icmp types were allowed (disabled iptables) - As far as I can see, the routers between the two hosts don't drop the generated icmp-packets The first of the questions was the reason I choosed this ML, because I was wondering why my client does not get the DF-Bit-set, but frag-needed icmp-message from the linux-router. Or did I unterstand the technique wrong? Greetings, Nico -- Keep it simple & stupid, use what's available. Please use pgp encryption: 8D0E 27A4 is my id. http://nico.schotteli.us | http://linux.schottelius.org pgpne4MqVk060.pgp Description: PGP signature
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Thu, Apr 07, 2005 at 11:05:05PM +0200, Sven Luther wrote: > On Thu, Apr 07, 2005 at 10:56:47PM +0200, Adrian Bunk wrote: >... > > If your statement was true that Debian must take more care regarding > > legal risks than commercial distributions, can you explain why Debian > > exposes the legal risks of distributing software capable of decoding > > MP3's to all of it's mirrors? > > I don't know and don't really care. I don't maintain any mp3 player (err, > actually i do, i package quark, but use it mostly to play .oggs, maybe i > should think twice about this now that you made me aware of it), but in any > case, i am part of the debian kernel maintainer team, and as such have a > responsability to get those packages uploaded and past the screening of the > ftp-masters. I believe the planned solution is vastly superior to the current > one of simply removing said firmware blobs from the drivers, which caused more > harm than helped, which is why we are set to clarifying this for the > post-sarge kernels. Debian doesn't seem to care much about the possible legal problems of patents. The firmware issues are an urgent real problem? Debian should define how much legal risk they are willing to impose on their mirrors and distributors and should act accordingly in all areas. But ignoring some areas while being more religious than RMS in other areas is simply silly. > That said, i was under the understanding that after the SCO disaster, > clarification of licencing issues and copyright attributions was a welcome > thing here, but maybe i misunderstood those whole issues. "SCO disaster"? It is a disaster for SCO. > Friendly, > > Sven Luther cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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 compile
Hi Should not be a problem as the compilation doesn't use any part of the running kernel. As long as you have the required components Alex On Thu, Apr 07, 2005 at 07:09:18PM -0400, Allison wrote: > Hi, > > Is it possible to compile a 2.4.20 kernel on a 2.6 system ? > And use the new image successfully ? > > thanks, > Allison > - > 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/ > signature.asc Description: Digital signature
Re: fix stale PCI pm docs
On Tue, Apr 05, 2005 at 11:49:49PM +0200, Pavel Machek wrote: > Hi! > > This fixes u32 vs. pm_message_t confusion in documentation, and > removes references to no-longer-existing (*save_state), too. With > exception of USB (I hope David will fix/apply my patch), this should > fix last piece of this confusion... famous last words. Applied, thanks. greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: fix u32 vs. pm_message_t in PCI, PCIE
On Sat, Apr 02, 2005 at 11:23:19PM +0200, Pavel Machek wrote: > Hi! > > This fixes drivers/pci (mostly pcie stuff). [These patches are > independend and change no object code; therefore not numbered]. > > Please apply, Applied, thanks. greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] fix sound/oss/nm256_audio.c with gcc 4.0
Rearrange sound/oss/nm256_audio.c and to drop nm256_debug from nm256.h since it confuses gcc 4.0 (this problem was my fault). Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- This patch was already sent on: - 29 Mar 2005 --- linux-2.6.12-rc1-mm3-full/sound/oss/nm256.h.old 2005-03-28 23:49:39.0 +0200 +++ linux-2.6.12-rc1-mm3-full/sound/oss/nm256.h 2005-03-28 23:51:33.0 +0200 @@ -128,9 +128,6 @@ struct nm256_info *next_card; }; -/* Debug flag--bigger numbers mean more output. */ -extern int nm256_debug; - /* The BIOS signature. */ #define NM_SIGNATURE 0x4e4d /* Signature mask. */ --- linux-2.6.12-rc1-mm3-full/sound/oss/nm256_audio.c.old 2005-03-28 23:51:53.0 +0200 +++ linux-2.6.12-rc1-mm3-full/sound/oss/nm256_audio.c 2005-03-28 23:52:19.0 +0200 @@ -28,12 +28,13 @@ #include #include #include "sound_config.h" -#include "nm256.h" -#include "nm256_coeff.h" static int nm256_debug; static int force_load; +#include "nm256.h" +#include "nm256_coeff.h" + /* * The size of the playback reserve. When the playback buffer has less * than NM256_PLAY_WMARK_SIZE bytes to output, we request a new - 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: [RESEND PATCH 2.6.11.2 1/1] PCI Allow OutOfRange PIRQ table address
On Mon, Mar 28, 2005 at 06:19:55AM -0800, [EMAIL PROTECTED] wrote: > Hi Greg, PCI folk, > > Resending this patch. Is it okay now? Sorry for the delay, I've added to my trees now. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ds1337 1/4
On Fri, Apr 08, 2005 at 01:17:58AM +0200, Ladislav Michl wrote: > On Thu, Apr 07, 2005 at 02:18:39PM -0700, Greg KH wrote: > > Jean's point is that you should send an individual patch for each type > > of individual change. It's ok to say "patch 3 requires you to have > > applied patches 1 and 2" and so on. Please split this up better. > > Here it is... > > Use i2c_transfer to send message, so we get proper bus locking. Oops, you forgot to add a Signed-off-by: line for every patch, as per Documentation/SubmittingPatches. Care to redo them? thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PCI Hotplug: remove code duplication in drivers/pci/hotplug/ibmphp_pci.c
On Sat, Apr 02, 2005 at 02:20:11PM +0200, Rolf Eike Beer wrote: > Greg KH wrote: > > ChangeSet 1.2181.16.9, 2005/03/17 13:54:33-08:00, [EMAIL PROTECTED] > > > > [PATCH] PCI Hotplug: remove code duplication in > > drivers/pci/hotplug/ibmphp_pci.c > > > > This patch removes some code duplication where if and else have the > > same code at the beginning and the end of the branch. > > Greg, as you correctly pointed out this patch if broken. It could never reach > the if branch and always uses the else branch. Please drop this one and > review the patch I sent on March 21th to pcihp-discuss for inclusion. It > removes much more duplication and handles this case correctly. Sorry, it > looks like I forgot to CC you. I'll bounce this mail to you. Hm, care to send me a patch that backs the old one out? Or just one that fixes it properly, I can't really revert the old patch, now that I'm not using bitkeeper :) thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11] aoe [7/12]: support configuration of AOE_PARTITIONS from Kconfig
On Thu, Apr 07, 2005 at 02:56:39PM -0400, Ed L Cashin wrote: > Greg KH <[EMAIL PROTECTED]> writes: > > ... > > So, which one of the aoe patches listed at: > > > > http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/driver/ > > do you want me to drop? This one: > > > > http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/driver/aoe-AOE_PARTITIONS.patch > > ? > > Or some other one too? > > Just aoe-AOE_PARTITIONS.patch, the seventh of the twelve, should be > dropped. Ok, dropped. > Then later I'll send a batch of patches that will include a change to > make aoe disks non-partitionable by default. That's fine. Mind if I forward the other aoe patches in that directory to Linus soon? thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][26.5/27] Add MT25204 PCI IDs
On Fri, Apr 01, 2005 at 02:06:50PM -0800, Roland Dreier wrote: > Ugh, this patch is required to build support for the new Mellanox > HCAs. Greg K-H applied it to his tree a while ago but it hasn't made > it to Linus yet. > > Sorry, > Roland > > Add PCI device IDs for new Mellanox MT25204 "Sinai" InfiniHost III Lx HCA. > > Signed-off-by: Roland Dreier <[EMAIL PROTECTED]> Already in 2.6.12-rc2. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] radeonfb: (#2) Implement proper workarounds for PLL accesses
On Fri, 2005-04-08 at 01:58 +0200, Andreas Schwab wrote: > Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes: > > > Yes, that's very extreme, I suspect somebody is banging on set_par or > > something like that. > > fb_setcolreg is it. Ahhh... interesting. I'll see if I can find a way to work around that one. Best would be to "cache" the current PLL register index in fact, but I'm afraid that may not work terribly well with userland apps hacking it ... 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: iomapping a big endian area
On Monday, April 4, 2005 7:25 am, James Bottomley wrote: > On Mon, 2005-04-04 at 15:16 +0100, Christoph Hellwig wrote: > > The IOC4 device that provides IDE, serial ports and external interrupts > > on Altix systems has a big endian register layour, and the PCI-X bridge > > in those Altix systems can do the swapping if a special bit is set. > > > > In older kernels that bit was set from the driver through a special API, > > but it seems the firmware does that automatically now. > > We already have some unusual code in drivers to support other altix > design ... features ... do you regard this as something that's likely to > be replicated on other platforms, or is it more in the category of a one > off mistake that can be corrected in firmware? The whole line of altix pci bridges can do byteswapping, so it's more than just one product that could benefit (however slightly). Not sure about other bridges though. Jesse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] radeonfb: (#2) Implement proper workarounds for PLL accesses
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes: > Yes, that's very extreme, I suspect somebody is banging on set_par or > something like that. fb_setcolreg is it. kernel: radeonfb_set_par kernel: radeon_write_pll_regs: radeon_pll_errata_after_data kernel: radeon_write_pll_regs: radeon_pll_errata_after_data kernel: radeon_write_mode: radeon_pll_errata_after_data kernel: radeonfb_engine_reset: radeon_pll_errata_after_data last message repeated 2 times kernel: radeonfb_setcolreg: radeon_pll_errata_after_data last message repeated 767 times kernel: radeonfb_set_par kernel: radeon_write_pll_regs: radeon_pll_errata_after_data kernel: radeon_write_pll_regs: radeon_pll_errata_after_data kernel: radeon_write_mode: radeon_pll_errata_after_data kernel: radeonfb_engine_reset: radeon_pll_errata_after_data last message repeated 2 times kernel: radeonfb_setcolreg: radeon_pll_errata_after_data last message repeated 911 times kernel: radeonfb_set_par kernel: radeon_write_pll_regs: radeon_pll_errata_after_data kernel: radeon_write_pll_regs: radeon_pll_errata_after_data kernel: radeon_write_mode: radeon_pll_errata_after_data kernel: radeonfb_engine_reset: radeon_pll_errata_after_data last message repeated 2 times kernel: radeonfb_setcolreg: radeon_pll_errata_after_data last message repeated 193 times kernel: agpgart: Putting AGP V2 device at :00:0b.0 into 1x mode kernel: agpgart: Putting AGP V2 device at :00:10.0 into 1x mode kernel: radeonfb_setcolreg: radeon_pll_errata_after_data last message repeated 191 times Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." - 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: turn kmalloc+memset(,0,) into kcalloc
On Apr 06, 2005, at 11:50, Paulo Marques wrote: kzalloc it is, then. [...] So we gain 8kB on the uncompressed image and 1347 bytes on the compressed one. This was just a dumb test and actual results might be better due to smarter human cleanups. Not a spectacular gain per se, but the increase in code readability is still worth it, IMHO. Perhaps this could eventually be modified to draw from a prezeroed block of memory, similar to the current code for doing the same thing for userspace. It probably wouldn't give much performance gain, especially since it's not used for large blocks or large numbers of small objects (As you would use a slabcache for those), but it might help a bit. Of course, the code would need to fall back quickly if such an allocation would be messy or expensive for any reason. Cheers, Kyle Moffett -BEGIN GEEK CODE BLOCK- Version: 3.12 GCM/CS/IT/U d- s++: a18 C>$ UB/L/X/*(+)>$ P+++()>$ L(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+ PGP+++ t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e->$ h!*()>++$ r !y?(-) --END GEEK CODE BLOCK-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: non-free firmware in kernel modules, aggregation and unclear copyright notice.
> On Thu, Apr 07, 2005 at 01:26:17AM -0700, David Schwartz wrote: > > If you believe the linker "merely aggregates" the object code for the > > driver with the data for the firmware, I can't see how you can argue > > that any linking is anything but mere aggregation. In neither case can > > you separate the linked work into the two separate works and in both > > cases the linker provides one work direct access to the other. > You can indeed separate the firmware and the kernel into two separate > works. That's what people have been proposing as the solution to this > problem. > Also, "mere aggregation" is a term from the GPL. You can read what > it says there yourself. But basically it's there so that people make > a distinction between the program itself and other stuff that isn't > the program. It's also there because the GPL can only apply to either works placed under it by their authors and works that are legally classified as derivative. If you merely aggregate two works, there is no derivation. The GPL is making clear that it's not trying to exceed the scope of its authority (which is copyright law). > Without that mere aggregation clause, people might be claiming that > text on a disk has to be GPLed because of emacs, or that postscript > files have to be GPLed because of ghostscript, or more generally that > arbitrary object FOO has to be GPLed because of gpled program BAR. They could, but they would still be wrong. Because if you "merely aggregate" two works, the result is still two works that can each be under their own license. The GPL is only making clear what is outside its authority, but it does not set the scope of its own authority anyway. > Put another way, what the linker does or doesn't do isn't really the > issue. Well it is. The question is whether you can link two object files together and distribute the result under the license of each independent file, treating it like a disk with two files on it, rather than as a single work. > People like to think that the linker is somehow special for copyright, > but it's not. Either the stuff being linked is protected by copyright > even when it's not linked or it's not protected by copyright after it is > linked. If the license says something about linking then that matters, > but only for cases where the code was protected by copyright even before > it was linked. And then linking only matters in the specific way that > that license says it matters. Regardless of what the GPL says, there is a genuine question of whether linking together file A and file B results in a file C that contains the two separate works or is a single work that is derivative of both A and B. This is important because of aspects of copyright law that the GPL acknowledges explicitly but does not get to decide. DS - 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: ext3 allocate-with-reservation latencies
On Thu, 2005-04-07 at 14:08 +0100, Stephen C. Tweedie wrote: > Hi, > > On Thu, 2005-04-07 at 09:14, Ingo Molnar wrote: > > > doesnt the first option also allow searches to be in parallel? > > In terms of CPU usage, yes. But either we use large windows, in which > case we *can't* search remotely near areas of the disk in parallel; or > we use small windows, in which case failure to find a free bit becomes > disproportionately expensive (we have to do an rbtree link and unlink > for each window we search.) Actually, we do not have to do an rbtree link and unlink for every window we search. If the reserved window(old) has no free bit and the new reservable window's is right after the old one, no need to unlink the old window from the rbtree and then link the new window, just update the start and end of the old one. That's in the current designed already, to reduce the cost of rbtree link and unlink. Mingming - 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] ds1337 1/4
On Thu, Apr 07, 2005 at 02:18:39PM -0700, Greg KH wrote:
> Jean's point is that you should send an individual patch for each type
> of individual change. It's ok to say "patch 3 requires you to have
> applied patches 1 and 2" and so on. Please split this up better.
Here it is...
Use i2c_transfer to send message, so we get proper bus locking.
= drivers/i2c/chips/ds1337.c 1.1 vs edited =
--- 1.1/drivers/i2c/chips/ds1337.c 2005-03-31 22:58:08 +02:00
+++ edited/drivers/i2c/chips/ds1337.c 2005-04-08 00:18:45 +02:00
@@ -3,7 +3,7 @@
*
* Copyright (C) 2005 James Chapman <[EMAIL PROTECTED]>
*
- * based on linux/drivers/acron/char/pcf8583.c
+ * based on linux/drivers/acorn/char/pcf8583.c
* Copyright (C) 2000 Russell King
*
* This program is free software; you can redistribute it and/or modify
@@ -119,8 +119,7 @@
msg[1].len = sizeof(buf);
msg[1].buf = [0];
- result = client->adapter->algo->master_xfer(client->adapter,
- [0], 2);
+ result = i2c_transfer(client->adapter, msg, 2);
dev_dbg(>adapter->dev,
"%s: [%d] %02x %02x %02x %02x %02x %02x %02x\n",
@@ -194,8 +193,7 @@
msg[0].len = sizeof(buf);
msg[0].buf = [0];
- result = client->adapter->algo->master_xfer(client->adapter,
- [0], 1);
+ result = i2c_transfer(client->adapter, msg, 1);
if (result < 0) {
dev_err(>adapter->dev, "ds1337[%d]: error "
"writing data! %d\n", data->id, result);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC,PATCH 3/4] Change synchronize_kernel to _rcu and _sched
Paul E. McKenney <[EMAIL PROTECTED]> : > This patch changes calls to synchronize_kernel(), deprecated in the > earlier "Deprecate synchronize_kernel, GPL replacement" patch to > instead call the new synchronize_rcu() and synchronize_sched() APIs. [...] > diff -urpN -X dontdiff linux-2.6.12-rc1/drivers/net/r8169.c > linux-2.6.12-rc1-bettersk/drivers/net/r8169.c > --- linux-2.6.12-rc1/drivers/net/r8169.c Thu Mar 31 09:53:08 2005 > +++ linux-2.6.12-rc1-bettersk/drivers/net/r8169.c Fri Apr 1 21:41:38 2005 > @@ -2385,7 +2385,7 @@ core_down: > } > > /* Give a racing hard_start_xmit a few cycles to complete. */ > - synchronize_kernel(); > + synchronize_sched(); /* FIXME: should this be synchronize_irq()? */ > > /* >* And now for the 50k$ question: are IRQ disabled or not ? (answering the FIXME) The race with the irq is handled somewhere else. As the comment suggests, this part is racing with the hard_start_xmit() handler. If I read correctly net/core/dev.c::dev_queue_xmit, the code above simply needs the new synchronize_rcu(). -- Ueimor - 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 SCM saga..
On Thu, 7 Apr 2005, Martin Pool wrote: > > Importing the first snapshot (2004-01-01) took 41.77s user, 1:23.79 > total. Each subsequent day takes about 10s user, 30s elapsed to commit > into bzr. The speeds are comparable to CVS or a bit faster, and may be > faster than other distributed systems. (This on a laptop with a 5400rpm > disk.) Pulling out a complete copy of the tree as it was on a previous > date takes about 14 user, 60s elapsed. If you have an exportable tree, can you just make it pseudo-public, tell me where to get a buildable system that works well enough, point me to some documentation, and maybe I can get some feel for it? 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: Kernel SCM saga..
> > Are you happy with processing patches + descriptions, one per mail? > > Yes. That's going to be my interim, I was just hoping that with 2.6.12-rc2 > out the door, and us in a "calming down" period, I could afford to not > even do that for a while. > > The real problem with the email thing is that it ends up piling up: what > BK did in this respect was that anythign that piled up in a BK repository > ended up still being there, and a single "bk pull" got it anyway - so if > somebody got ignored because I was busy with something else, it didn't add > any overhead. The queue didn't get "congested". > > And that's a big thing. It comes from the "Linus pulls" model where people > just told me that they were ready, instead of the "everybody pushes to > Linus" model, where the destination gets congested at times. Something I think we'll miss is bkbits.net in the long run, being able to just push all patches for Linus to a tree and then forget about that tree until Linus pulled from it was invaluable.. the fact that this tree was online the whole time and you didn't queue up huge mails for Linus's INBOX to be missed, meant a lot to me compared to pre-bk workings.. Maybe now that kernel.org has been 'pimped out' we could set some sort of system up where maintainers can drop a big load of patchsets or even one big patch into some sort of public area and say this is my diffs for Linus for his next pull and let Linus pull it at his lesuire... some kinda rsync'y type thing comes to mind ... so I can mail Linus and say hey Linus please grab rsync://pimpedout.kernel.org/airlied/drm-linus and you grab everything in there and I get notified perhaps or just a log like the bkbits stats page, and Andrew can grab the patchsets the same as he does for bk-drm now ... and I can have airlied/drm-2.6 where I can queue stuff for -mm then just re-generate the patches for drm-linus later on.. Dave. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] radeonfb: (#2) Implement proper workarounds for PLL accesses
On Fri, 2005-04-08 at 01:13 +0200, Andreas Schwab wrote: > Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes: > > > Can you cound how many times radeonfb_set_par is called and dump your > > "counter" at the beginning and end of each of these calls ? > > Switch from X to console: > > kernel: radeonfb_set_par > kernel: radeon_pll_errata_after_data > last message repeated 774 times > kernel: radeonfb_set_par > kernel: radeon_pll_errata_after_data > last message repeated 918 times Ok, so somebody is calling set_par twice ... I suppose I know why but it's not a very nice thing to do. Still, it doesn't explain why there are so many calls to the errata. Please read my other email and try to figure out where those big numbers come from... 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/
[PATCH] ds1337 4/4
Add support for DS1339. The only difference against DS1337 is Trickle
Charge register at address 10h, which is used to enable battery or gold
cap charging. Please note that value may vary for different batteries,
so it should be made module parameter. 0xaa is sane default and also
matches my board ;-)
--- linux-omap/drivers/i2c/chips/ds1337.c.orig 2005-04-08 00:47:15.655878832
+0200
+++ linux-omap/drivers/i2c/chips/ds1337.c 2005-04-08 01:10:41.662133392
+0200
@@ -31,6 +31,7 @@
#define DS1337_REG_MONTH 5
#define DS1337_REG_CONTROL 14
#define DS1337_REG_STATUS 15
+#define DS1339_REG_CHARGE 16
/* FIXME - how do we export these interface constants? */
#define DS1337_GET_DATE0
@@ -42,7 +43,7 @@
static unsigned short normal_i2c[] = { 0x68, I2C_CLIENT_END };
static unsigned int normal_isa[] = { I2C_CLIENT_ISA_END };
-SENSORS_INSMOD_1(ds1337);
+SENSORS_INSMOD_2(ds1337, ds1339);
static int ds1337_attach_adapter(struct i2c_adapter *adapter);
static int ds1337_detect(struct i2c_adapter *adapter, int address, int kind);
@@ -78,6 +79,8 @@ struct ds1337_data {
static int ds1337_id;
static LIST_HEAD(ds1337_clients);
+static int ds1339_charge = 0xaa;
+
static inline int ds1337_read(struct i2c_client *client, u8 reg, u8 *value)
{
s32 tmp = i2c_smbus_read_byte_data(client, reg);
@@ -90,6 +93,37 @@ static inline int ds1337_read(struct i2c
return 0;
}
+/*
+ * DS1339 has Trickle Charge register at address 10h. During a multibyte
+ * access, when the address pointer reaches the end of the register space,
+ * it wraps around to location 00h.
+ * We read 17 bytes from device and compare first and last one. If they are
+ * same it is most likely DS1337 chip.
+ */
+static int ds1337_is_ds1339(struct i2c_client *client)
+{
+ char buf[17], addr = 0;
+ struct i2c_msg msg[2];
+ int result;
+
+ msg[0].addr = client->addr;
+ msg[0].flags = 0;
+ msg[0].len = 1;
+ msg[0].buf =
+
+ msg[1].addr = client->addr;
+ msg[1].flags = I2C_M_RD;
+ msg[1].len = sizeof(buf);
+ msg[1].buf = buf;
+
+ result = i2c_transfer(client->adapter, msg, 2);
+ if (result < 0) {
+ dev_err(>dev, "error reading data! %d\n", result);
+ return 0;
+ } else
+ return (buf[0] == buf[16]) ? 0 : 1;
+}
+
/*
* Chip access functions
*/
@@ -246,7 +280,7 @@ static int ds1337_detect(struct i2c_adap
struct i2c_client *new_client;
struct ds1337_data *data;
int err = 0;
- const char *name = "";
+ const char *name;
if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA |
I2C_FUNC_I2C))
@@ -318,11 +352,24 @@ static int ds1337_detect(struct i2c_adap
(data & 0x60))
goto exit_free;
- kind = ds1337;
+ /* Check whenever we have DS1339 */
+ if (ds1337_is_ds1339(new_client))
+ kind = ds1339;
+ else
+ kind = ds1337;
+
}
- if (kind == ds1337)
+ switch (kind) {
+ case ds1337:
name = "ds1337";
+ break;
+ case ds1339:
+ name = "ds1339";
+ break;
+ default:
+ name = "";
+ }
/* We can fill in the remaining client fields */
strlcpy(new_client->name, name, I2C_NAME_SIZE);
@@ -334,6 +381,15 @@ static int ds1337_detect(struct i2c_adap
/* Initialize the DS1337 chip */
ds1337_init_client(new_client);
+ /* Be nice to battery */
+ if (kind == ds1339 && ds1339_charge) {
+ char buf[] = { DS1339_REG_CHARGE, ds1339_charge };
+
+ if (i2c_master_send(new_client, buf, 2) != 2)
+ dev_err(_client->dev,
+ "failed to enable trickle charge.\n");
+ }
+
/* Add client to local list */
data->id = ds1337_id++;
list_add(>list, _clients);
-
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] ds1337 2/4
Use correct macros to convert between bdc and bin. See linux/bcd.h
--- linux-omap/drivers/i2c/chips/ds1337.c.orig 2005-04-08 00:32:45.234203040
+0200
+++ linux-omap/drivers/i2c/chips/ds1337.c 2005-04-08 00:34:58.457949952
+0200
@@ -127,15 +127,15 @@
buf[4], buf[5], buf[6]);
if (result >= 0) {
- dt->tm_sec = BCD_TO_BIN(buf[0]);
- dt->tm_min = BCD_TO_BIN(buf[1]);
+ dt->tm_sec = BCD2BIN(buf[0]);
+ dt->tm_min = BCD2BIN(buf[1]);
val = buf[2] & 0x3f;
- dt->tm_hour = BCD_TO_BIN(val);
- dt->tm_wday = BCD_TO_BIN(buf[3]) - 1;
- dt->tm_mday = BCD_TO_BIN(buf[4]);
+ dt->tm_hour = BCD2BIN(val);
+ dt->tm_wday = BCD2BIN(buf[3]) - 1;
+ dt->tm_mday = BCD2BIN(buf[4]);
val = buf[5] & 0x7f;
- dt->tm_mon = BCD_TO_BIN(val);
- dt->tm_year = 1900 + BCD_TO_BIN(buf[6]);
+ dt->tm_mon = BCD2BIN(val);
+ dt->tm_year = 1900 + BCD2BIN(buf[6]);
if (buf[5] & 0x80)
dt->tm_year += 100;
@@ -174,19 +174,19 @@
dt->tm_mday, dt->tm_mon, dt->tm_year, dt->tm_wday);
buf[0] = 0; /* reg offset */
- buf[1] = BIN_TO_BCD(dt->tm_sec);
- buf[2] = BIN_TO_BCD(dt->tm_min);
- buf[3] = BIN_TO_BCD(dt->tm_hour) | (1 << 6);
- buf[4] = BIN_TO_BCD(dt->tm_wday) + 1;
- buf[5] = BIN_TO_BCD(dt->tm_mday);
- buf[6] = BIN_TO_BCD(dt->tm_mon);
+ buf[1] = BIN2BCD(dt->tm_sec);
+ buf[2] = BIN2BCD(dt->tm_min);
+ buf[3] = BIN2BCD(dt->tm_hour) | (1 << 6);
+ buf[4] = BIN2BCD(dt->tm_wday) + 1;
+ buf[5] = BIN2BCD(dt->tm_mday);
+ buf[6] = BIN2BCD(dt->tm_mon);
if (dt->tm_year >= 2000) {
val = dt->tm_year - 2000;
buf[6] |= (1 << 7);
} else {
val = dt->tm_year - 1900;
}
- buf[7] = BIN_TO_BCD(val);
+ buf[7] = BIN2BCD(val);
msg[0].addr = client->addr;
msg[0].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/
[PATCH] ds1337 3/4
dev_{dbg,err} functions should print client's device name. data->id can
be dropped from message, because device is determined by bus it hangs on
(it has fixed address).
--- linux-omap/drivers/i2c/chips/ds1337.c.orig 2005-04-08 00:36:15.072302800
+0200
+++ linux-omap/drivers/i2c/chips/ds1337.c 2005-04-08 00:44:44.130914128
+0200
@@ -95,7 +95,6 @@ static inline int ds1337_read(struct i2c
*/
static int ds1337_get_datetime(struct i2c_client *client, struct rtc_time *dt)
{
- struct ds1337_data *data = i2c_get_clientdata(client);
int result;
u8 buf[7];
u8 val;
@@ -103,9 +102,7 @@ static int ds1337_get_datetime(struct i2
u8 offs = 0;
if (!dt) {
- dev_dbg(>adapter->dev, "%s: EINVAL: dt=NULL\n",
- __FUNCTION__);
-
+ dev_dbg(>dev, "%s: EINVAL: dt=NULL\n", __FUNCTION__);
return -EINVAL;
}
@@ -121,8 +118,7 @@ static int ds1337_get_datetime(struct i2
result = i2c_transfer(client->adapter, msg, 2);
- dev_dbg(>adapter->dev,
- "%s: [%d] %02x %02x %02x %02x %02x %02x %02x\n",
+ dev_dbg(>dev, "%s: [%d] %02x %02x %02x %02x %02x %02x %02x\n",
__FUNCTION__, result, buf[0], buf[1], buf[2], buf[3],
buf[4], buf[5], buf[6]);
@@ -139,14 +135,13 @@ static int ds1337_get_datetime(struct i2
if (buf[5] & 0x80)
dt->tm_year += 100;
- dev_dbg(>adapter->dev, "%s: secs=%d, mins=%d, "
+ dev_dbg(>dev, "%s: secs=%d, mins=%d, "
"hours=%d, mday=%d, mon=%d, year=%d, wday=%d\n",
__FUNCTION__, dt->tm_sec, dt->tm_min,
dt->tm_hour, dt->tm_mday,
dt->tm_mon, dt->tm_year, dt->tm_wday);
} else {
- dev_err(>adapter->dev, "ds1337[%d]: error reading "
- "data! %d\n", data->id, result);
+ dev_err(>dev, "error reading data! %d\n", result);
result = -EIO;
}
@@ -155,20 +150,17 @@ static int ds1337_get_datetime(struct i2
static int ds1337_set_datetime(struct i2c_client *client, struct rtc_time *dt)
{
- struct ds1337_data *data = i2c_get_clientdata(client);
int result;
u8 buf[8];
u8 val;
struct i2c_msg msg[1];
if (!dt) {
- dev_dbg(>adapter->dev, "%s: EINVAL: dt=NULL\n",
- __FUNCTION__);
-
+ dev_dbg(>dev, "%s: EINVAL: dt=NULL\n", __FUNCTION__);
return -EINVAL;
}
- dev_dbg(>adapter->dev, "%s: secs=%d, mins=%d, hours=%d, "
+ dev_dbg(>dev, "%s: secs=%d, mins=%d, hours=%d, "
"mday=%d, mon=%d, year=%d, wday=%d\n", __FUNCTION__,
dt->tm_sec, dt->tm_min, dt->tm_hour,
dt->tm_mday, dt->tm_mon, dt->tm_year, dt->tm_wday);
@@ -195,8 +187,7 @@ static int ds1337_set_datetime(struct i2
result = i2c_transfer(client->adapter, msg, 1);
if (result < 0) {
- dev_err(>adapter->dev, "ds1337[%d]: error "
- "writing data! %d\n", data->id, result);
+ dev_err(>dev, "error writing data! %d\n", result);
result = -EIO;
} else {
result = 0;
@@ -208,7 +199,7 @@ static int ds1337_set_datetime(struct i2
static int ds1337_command(struct i2c_client *client, unsigned int cmd,
void *arg)
{
- dev_dbg(>adapter->dev, "%s: cmd=%d\n", __FUNCTION__, cmd);
+ dev_dbg(>dev, "%s: cmd=%d\n", __FUNCTION__, cmd);
switch (cmd) {
case DS1337_GET_DATE:
-
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: [SCSI] Driver Broken in 2.6.x (attemp 2)
Hi, Just wamted to ask if anyone has some will into it, or if this driver shoudl be removed from the kernel as broken. -- pozdrawiam |"Help me master, I felt the burning twilight behind [EMAIL PROTECTED]|those gates of stell..." --Perihelion, Prophecy Sequence - 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] i2c: new driver for ds1337 RTC
Jean,
I'll comment your mail first and then send separate patches (somehow
I can't sleep this night :))
On Thu, Apr 07, 2005 at 11:29:08PM +0200, Jean Delvare wrote:
> > * Move NULL argument checking from get/set date functions to
> > ds1337_command function, so it is only at one place. Note that other
> > drivers do not this checking at all and I think it is pointess,
> > because you have to know that you are passing struct rtc_time
> > anyway.
>
> I am not certain these are the right things to do (moving the check or
> removing it). I am not a specialist of ioctl, but it looks to me that
> ds1337_command acts as a dispatcher, branching to various functions
> depending on the value of cmd. I can imagine that some functions take an
> argument, and some don't, so checking for NULL pointer in the dispatcher
> doesn't make much sense. Now it is correct that for now all (two)
> functions need a parameter, but what if later a function is added, which
> takes no parameter? You'd have to undo your change and move the check in
> each function again.
>
> As for the check itself, the pointer somehow comes from user-space as I
> understand it, so you can't tell whether it's NULL or not - so checking
> makes full sense to me. If you take a look at the rtc8564 driver you'll
> see it *does* check for NULL pointers too.
You can't tell if memory it points to is valid. Okay, probably better
than nothing.
> > @@ -95,60 +96,38 @@
> > */
> > static int ds1337_get_datetime(struct i2c_client *client, struct
> > rtc_time *dt) {
> > - struct ds1337_data *data = i2c_get_clientdata(client);
> > - int result;
> > - u8 buf[7];
> > - u8 val;
> > - struct i2c_msg msg[2];
> > - u8 offs = 0;
> > -
> > - if (!dt) {
> > - dev_dbg(>adapter->dev, "%s: EINVAL: dt=NULL\n",
> > - __FUNCTION__);
> > -
> > - return -EINVAL;
> > - }
> > -
> > - msg[0].addr = client->addr;
> > - msg[0].flags = 0;
> > - msg[0].len = 1;
> > - msg[0].buf =
> > -
> > - msg[1].addr = client->addr;
> > - msg[1].flags = I2C_M_RD;
> > - msg[1].len = sizeof(buf);
> > - msg[1].buf = [0];
> > + unsigned char buf[7] = { 0, }, addr[1] = { 0 };
> > + struct i2c_msg msgs[2] = {
> > + { client->addr, 0,1, addr },
> > + { client->addr, I2C_M_RD, 7, buf }
> > + };
> > + int result = i2c_transfer(client->adapter, msgs, 2);
> >
> > - result = client->adapter->algo->master_xfer(client->adapter,
> > - [0], 2);
>
> You are doing much more than just using i2c_transfer instead of
> master_xfer. You are also rewriting the way the message data is
> initialized. I see no reason to do that, as the previous code was
> correct as far as I can see.
Right, I just made it shorter. One more point for you, my way is not
struct i2c_msg change proof. I'll drop it.
> > - if (result >= 0) {
> (...)
> > + if (result < 0) {
>
> By changing this you are making your patch much bigger and harder to
> review. Why do you do that?
Here you need to look at patched code. Now conditions in both
ds1337_get_datetime and ds1337_set_datetime look similar, so code is
IHMO easily readable. I'm fine with droping this change.
> > - val = buf[2] & 0x3f;
> > - dt->tm_hour = BCD_TO_BIN(val);
> (...)
> > + dt->tm_hour = BCD2BIN(buf[2] & 0x3f);
>
> No, James is correct. BCD2BIN (or BCD_TO_BIN for that matter) is a
> macro which evaluates its argument more than once. Using a temporary
> variable makes sense.
Agree.
> > + unsigned char buf[8];
> > int result;
> > - u8 buf[8];
>
> Wow, what a useful change. Please please please... Focus on making your
> patch compact, have it do just the thing it is supposed (and advertised)
> to do. You know, I'll repeat it until you get it. No matter how many
> tries it takes.
Save your time I got it. buf is supposed to be char, that's what function
expects. I wrongly made it unsigned. u8, u16 etc. are used in case
when you for example need to generate say 8 bit bus access or need same
width on all architectures. Neither is case here and using u8 makes no
sense. Anyway, will drop change.
> > if (dt->tm_year >= 2000) {
> > - val = dt->tm_year - 2000;
> > buf[6] |= (1 << 7);
> > - } else {
> > - val = dt->tm_year - 1900;
> > - }
> > - buf[7] = BIN_TO_BCD(val);
> > + buf[7] = BIN2BCD(dt->tm_year - 2000);
> > + } else
> > + buf[7] = BIN2BCD(dt->tm_year - 1900);
>
> Same as before, the use of a temporary variable makes full sense, don't
> change that. And you're again adding noise by dropping a pair of curly
> braces.
That's only because I read mail by jgarzik suggesting to remove such
braces few hours ago :) Also, i'll drop this change.
Best regards,
ladis
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Re: [PATCH] radeonfb: (#2) Implement proper workarounds for PLL accesses
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes: > Can you cound how many times radeonfb_set_par is called and dump your > "counter" at the beginning and end of each of these calls ? Switch from X to console: kernel: radeonfb_set_par kernel: radeon_pll_errata_after_data last message repeated 774 times kernel: radeonfb_set_par kernel: radeon_pll_errata_after_data last message repeated 918 times Switch from console to X: kernel: radeonfb_set_par kernel: radeon_pll_errata_after_data last message repeated 200 times kernel: agpgart: Putting AGP V2 device at :00:0b.0 into 1x mode kernel: agpgart: Putting AGP V2 device at :00:10.0 into 1x mode kernel: radeon_pll_errata_after_data last message repeated 191 times Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." - 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 compile
Hi, Is it possible to compile a 2.4.20 kernel on a 2.6 system ? And use the new image successfully ? thanks, Allison - 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] radeonfb: (#2) Implement proper workarounds for PLL accesses
On Fri, 2005-04-08 at 07:22 +1000, Dave Airlie wrote: > > There are 1694 calls to radeon_pll_errata_after_data during a switch from > > X to the console and 393 calls the other way. > > Wow... Ben that seems a bit extreme... there's not even close to 393 plls :-) Yes, that's very extreme, I suspect somebody is banging on set_par or something like that. Let me count a normal set_par operation: - blank. That can do INPLL, OUTPLLP and OUTPLL on MT_LCD, that is 4 calls to the errata (OUTPLLP has two). - write_pll_regs which does * on mobility chips: 2x INPLL to test the PLL value, and if it matches, just writes the PLL selector with a call to the errata, that is only 3 calls to the errata. Can you check we actually get in that case ? Normally, on the internal LCD, we should never change the PLL registers, or only one (they should stay the same all the time after that) and thus we should get into this case. If not (CRT), indeed, we end up doing more accesses: * OUTPLLP (2), OUTPLLP (2), manual errata (1), OUTPLLP (2), OUTPLLP (2), OUTPLLP (2), an INPLL loop (hrm...), OUTPLLP (2), another INPLL loop, OUTPLL (1), OUTPLLP (2), OUTPLLP (2). That is 18 calls to the errata plus the 2 INPLL loops. It would be useful to instrument those loops and see what happens there, but I don't see why they would have any impact unless something wrong is going on there with the PLL locking... * One last call to OUTPLLP (2). - reset the engine, that is 3 calls to the errata So that means that one call to raeonfb_set_par() should be in the normal internal flat panel case about 12 calls to the errata, and in the case where we actually write the PLL registers, about 29, plus the ones called by the INPLL loops waiting for the PLL to lock. As you can see, we are far below the measured counts. So I would need more instrumentation of the driver to figure out what's going on there. 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: [PATCH] radeonfb: (#2) Implement proper workarounds for PLL accesses
On Thu, 2005-04-07 at 22:21 +0200, Andreas Schwab wrote: > Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes: > > > It is weird tho. Could you try adding a printk or something to figure > > out how much this is called during a typical swich ? > > There are 1694 calls to radeon_pll_errata_after_data during a switch from > X to the console and 393 calls the other way. Wow ! That is plain wrong ! Can you cound how many times radeonfb_set_par is called and dump your "counter" at the beginning and end of each of these calls ? 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: [patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
BTW, when it happened last time, my program listening to the socket complained about duplicate messages received. Unmatched seq. Rcvd=1824062, expected=1824061 <=== Unmatched seq. Rcvd=1824062, expected=1824063 <=== Unmatched seq. Rcvd=1824348, expected=1824307 When my program received 1824062 while expecting 1824061 it adjusted itself to expect the next one being 1824063. But instead the message of 1824062 arrived the second time. - jay Jay Lan wrote: Hi Evgeniy, Should i be concerned about this bugcheck? I have seen this happening a number of times, all with the same signature in my testing. I ran a mix of AIM7, ubench, fork-test (continuously fork new processes), and another program reading from the fork connector socket. Thanks, - jay cqueue/1[656]: bugcheck! 0 [1] Modules linked in: nfs lockd sunrpc sg st sr_mod ipv6 usbcore Pid: 656, CPU 1, comm: cqueue/1 psr : 1010085a6010 ifs : 8289 ip : []Not tainted ip is at __kfree_skb+0x1b0/0x220 unat: pfs : 0289 rsc : 0003 rnat: bsps: pr : 9641 ldrs: ccv : fpsr: 0009804c8a70433f csd : ssd : b0 : a001005cee50 b6 : a001e7e0 b7 : a001003ae440 f6 : 0fffbc8c0 f7 : 0ffdaa200 f8 : 18000 f9 : 10002a000 f10 : 0fffcc8c0 f11 : 1003e r1 : a00100c0ec00 r2 : 4000 r3 : 4000 r8 : 0028 r9 : a001008eaac8 r10 : 0004 r11 : 0028 r12 : e0307a99fd60 r13 : e0307a998000 r14 : a00100887c00 r15 : a00100a24b18 r16 : a00100a22e18 r17 : r18 : a00100887bec r19 : a00100a9080f r20 : 3517 r21 : 000f r22 : 0034 r23 : 0034 r24 : a00100a90810 r25 : 3518 r26 : 3518 r27 : 0010085a6010 r28 : a00100a90811 r29 : 3519 r30 : r31 : a00100a24ae8 Call Trace: [] show_stack+0x80/0xa0 sp=e0307a99f920 bsp=e0307a999078 [] show_regs+0x840/0x880 sp=e0307a99faf0 bsp=e0307a999018 [] die+0x150/0x1c0 sp=e0307a99fb00 bsp=e0307a998fd0 [] die_if_kernel+0x40/0x60 sp=e0307a99fb00 bsp=e0307a998fa0 [] ia64_bad_break+0x300/0x380 sp=e0307a99fb00 bsp=e0307a998f78 [] ia64_leave_kernel+0x0/0x280 sp=e0307a99fb90 bsp=e0307a998f78 [] __kfree_skb+0x1b0/0x220 sp=e0307a99fd60 bsp=e0307a998f30 [] kfree_skb+0x50/0xa0 sp=e0307a99fd60 bsp=e0307a998f10 [] cn_queue_wrapper+0xe0/0x100 sp=e0307a99fd60 bsp=e0307a998ee8 [] worker_thread+0x3e0/0x520 sp=e0307a99fd60 bsp=e0307a998e60 [] kthread+0x290/0x300 sp=e0307a99fdd0 bsp=e0307a998e20 [] kernel_thread_helper+0xe0/0x100 sp=e0307a99fe30 bsp=e0307a998df0 [] start_kernel_thread+0x20/0x40 sp=e0307a99fe30 bsp=e0307a998df0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.12-rc2
On Thu, 2005-04-07 at 11:54 -0700, Nish Aravamudan wrote: > On Apr 7, 2005 10:50 AM, Moritz Muehlenhoff <[EMAIL PROTECTED]> wrote: > > Benjamin Herrenschmidt wrote: > > > > 1. When resuming from S3 suspend and having switched off the backlight > > > > with radeontool the backlight isn't switched back on any more. > > > > > > I'm not sure what's up here, it's a nasty issue with backlight. Can > > > radeontool bring it back ? > > > > Before suspending I power down the backlight with "radeontool light off" > > and with 2.6.11 the display is properly restored. With 2.6.12rc2 the > > backlight remains switched off and if I switch it on with radeontool it > > becomes lighter, but there's still no text from the fbcon, just the blank > > screen. > > FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2, > except that neither returns from suspend-to-ram with video restored on > the LCD. I believe I was able to get video restored on an external CRT > in either 2.6.12-rc2 or 2.6.12-rc2-mm1, but the LCD still didn't > restore (can verify later today, if you'd like). I had dumped out the > radeontool regs values before & after the sleep, in case they help. > They are attached. > > I posted these problems in the "Call for help S3" thread, but no one > responded. I would say the different value in LVDS_GEN_CNTL explains it. I'll see if I can force radeonfb to save/restore this. 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: Linux 2.6.12-rc2
On Thu, 2005-04-07 at 19:50 +0200, Moritz Muehlenhoff wrote: > Benjamin Herrenschmidt wrote: > > > 1. When resuming from S3 suspend and having switched off the backlight > > > with radeontool the backlight isn't switched back on any more. > > > > I'm not sure what's up here, it's a nasty issue with backlight. Can > > radeontool bring it back ? > > Before suspending I power down the backlight with "radeontool light off" > and with 2.6.11 the display is properly restored. With 2.6.12rc2 the > backlight remains switched off and if I switch it on with radeontool it > becomes lighter, but there's still no text from the fbcon, just the blank > screen. > > > > 2. I'm using fbcon as my primary work environment, but tty switching has > > > become _very_ sloppy, it's at least a second now, while with 2.6.11 it > > > was as fast as a few ms. Is this caused by the "proper PLL accesses"? > > > > Yes. Unfortunately. It's surprised it is that slow though, there > > shouldn't be more than 5 or 6 PLL accesses on a normal mode switch, with > > 5ms pause for each, that should still be very reasonable. It looks like > > we are doing a lot more accesses which I don't completely understand. > > Can you tell me which function you have in mind, so that I can insert > some printks to see how often it's called? radeon_pll_errata_after_data() calls radeon_msleep() (it's in radeonfb.h) 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: [patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
Hi Evgeniy, Should i be concerned about this bugcheck? I have seen this happening a number of times, all with the same signature in my testing. I ran a mix of AIM7, ubench, fork-test (continuously fork new processes), and another program reading from the fork connector socket. Thanks, - jay cqueue/1[656]: bugcheck! 0 [1] Modules linked in: nfs lockd sunrpc sg st sr_mod ipv6 usbcore Pid: 656, CPU 1, comm: cqueue/1 psr : 1010085a6010 ifs : 8289 ip : []Not tainted ip is at __kfree_skb+0x1b0/0x220 unat: pfs : 0289 rsc : 0003 rnat: bsps: pr : 9641 ldrs: ccv : fpsr: 0009804c8a70433f csd : ssd : b0 : a001005cee50 b6 : a001e7e0 b7 : a001003ae440 f6 : 0fffbc8c0 f7 : 0ffdaa200 f8 : 18000 f9 : 10002a000 f10 : 0fffcc8c0 f11 : 1003e r1 : a00100c0ec00 r2 : 4000 r3 : 4000 r8 : 0028 r9 : a001008eaac8 r10 : 0004 r11 : 0028 r12 : e0307a99fd60 r13 : e0307a998000 r14 : a00100887c00 r15 : a00100a24b18 r16 : a00100a22e18 r17 : r18 : a00100887bec r19 : a00100a9080f r20 : 3517 r21 : 000f r22 : 0034 r23 : 0034 r24 : a00100a90810 r25 : 3518 r26 : 3518 r27 : 0010085a6010 r28 : a00100a90811 r29 : 3519 r30 : r31 : a00100a24ae8 Call Trace: [] show_stack+0x80/0xa0 sp=e0307a99f920 bsp=e0307a999078 [] show_regs+0x840/0x880 sp=e0307a99faf0 bsp=e0307a999018 [] die+0x150/0x1c0 sp=e0307a99fb00 bsp=e0307a998fd0 [] die_if_kernel+0x40/0x60 sp=e0307a99fb00 bsp=e0307a998fa0 [] ia64_bad_break+0x300/0x380 sp=e0307a99fb00 bsp=e0307a998f78 [] ia64_leave_kernel+0x0/0x280 sp=e0307a99fb90 bsp=e0307a998f78 [] __kfree_skb+0x1b0/0x220 sp=e0307a99fd60 bsp=e0307a998f30 [] kfree_skb+0x50/0xa0 sp=e0307a99fd60 bsp=e0307a998f10 [] cn_queue_wrapper+0xe0/0x100 sp=e0307a99fd60 bsp=e0307a998ee8 [] worker_thread+0x3e0/0x520 sp=e0307a99fd60 bsp=e0307a998e60 [] kthread+0x290/0x300 sp=e0307a99fdd0 bsp=e0307a998e20 [] kernel_thread_helper+0xe0/0x100 sp=e0307a99fe30 bsp=e0307a998df0 [] start_kernel_thread+0x20/0x40 sp=e0307a99fe30 bsp=e0307a998df0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Add dontdiff file
On Thu, 7 Apr 2005 15:37:51 -0700 Matt Mackall wrote: | On Tue, Apr 05, 2005 at 08:10:27PM -0700, Randy.Dunlap wrote: | > There is a fairly up-to-date dontdiff file available at | > http://developer.osdl.org/rddunlap/doc/dontdiff-osdl | | Can we stash a copy in Documentation? certainly. Add a current 'dontdiff' file for use with 'diff -X dontdiff'. Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> diffstat:= Documentation/dontdiff | 137 + 1 files changed, 137 insertions(+) diff -Naurp ./Documentation/dontdiff~add_dontdiff ./Documentation/dontdiff --- ./Documentation/dontdiff~add_dontdiff 2005-04-07 15:39:51.0 -0700 +++ ./Documentation/dontdiff2005-03-01 16:07:56.0 -0800 @@ -0,0 +1,137 @@ +.* +*~ +53c8xx_d.h* +*.a +aic7*reg.h* +aic7*seq.h* +aic7*reg_print.c* +53c700_d.h +aicasm +aicdb.h* +asm +asm_offsets.* +autoconf.h* +*.aux +bbootsect +*.bin +bin2c +binkernel.spec +BitKeeper +bootsect +bsetup +btfixupprep +build +bvmlinux +bzImage* +ChangeSet +classlist.h* +compile.h* +comp*.log +config +config-* +config_data.h* +conmakehash +consolemap_deftbl.c* +COPYING +CREDITS +.cscope +*cscope* +cscope.* +*.out +*.css +CVS +defkeymap.c* +devlist.h* +docproc +dummy_sym.c* +*.dvi +*.eps +filelist +fixdep +fore200e_mkfirm +fore200e_pca_fw.c* +gen-devlist +gen_init_cpio +gen_crc32table +crc32table.h* +*.cpio +gen-kdb_cmds.c* +gentbl +genksyms +*.gif +*.gz +*.html +ikconfig.h* +initramfs_list +*.jpeg +kconfig +kconfig.tk +Kerntypes +keywords.c* +ksym.c* +ksym.h* +kallsyms +mk_elfconfig +elfconfig.h* +modpost +pnmtologo +logo_*.c +*.log +lex.c* +logo_*_clut224.c +logo_*_mono.c +lxdialog +make_times_h +map +mkdep +*_MODULES +MODS.txt +modversions.h* +Module.symvers +*.mod.c +*.o +*.ko +*.orig +*.lst +*.grp +*.grep +oui.c* +mktables +raid6tables.c +raid6int*.c +raid6altivec*.c +wanxlfw.inc +maui_boot.h +pss_boot.h +trix_boot.h +*.pdf +parse.c* +parse.h* +PENDING +ppc_defs.h* +promcon_tbl.c* +*.png +*.ps +*.rej +SCCS +setup +*.s +*.so +*.sgml +sim710_d.h* +sm_tbl* +split-include +System.map* +tags +TAGS +*.tex +times.h* +tkparse +*.ver +version.h* +*_vga16.c +vmlinux +vmlinux.lds +vmlinux-* +vsyscall.lds +zImage --- - 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] kernel 2.6.11.6 - I2C adaptor for ColdFire 5282 CPU
On Tue, Apr 05, 2005 at 08:10:27PM -0700, Randy.Dunlap wrote: > There is a fairly up-to-date dontdiff file available at > http://developer.osdl.org/rddunlap/doc/dontdiff-osdl Can we stash a copy in Documentation? -- Mathematics is the supreme nostalgia of our time. - 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/
set keyboard repeat rate: EVIOCGREP and EVIOCSREP
I was wondering if anyone knows how to change the repeatrate on a USB keyboard with a 2.4 kernel. The system is a legacy free system (no ps2 port), so kbdrate does nothing. With evdev loaded, the keyboard and mouse (both USB devices) get registered with the event system and show up as /dev/input/event[01]. I know the event subsystem does software key repeating and was wondering how to change that. I poked around and found the EVIOCGREP and EVIOCSREP ioctls, but when I tried using them, the ioctl returned invalid parameter. Upon further investigation, I found that the ioctl definitions (located in the linux/input.h header file) are not used in kernel land. That would explain why it failed, but that just means I ran into a dead end. Were those definitions legacy code from 2.2 or is it something that never got implemented, only defined? I also noticed that the defines are gone in 2.6. So how _does_ one go about changing the repeat rate on a keyboard input device in 2.4? Thanks in advance for your help. --Vernon Mauery - 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: A problem with kswapd
On Mon, Apr 04, 2005 at 09:42:39AM +0200, Jose Ángel De Bustos Pérez wrote: > Hi, > > I have a problem with kswapd and I didn't find anything in the > archives of the list (I hope not having missed someone). > > kswapd is using 100% of CPU in a suse sles8 with kernel 2.4.241. This > machine has its FS under LVM and ResiserFS, except for /boot which is > in ext2. > > Any idea? Thanks in advance. If your kernel is a kernel that came with SuSE, please contact SuSE support. If your kernel is a vanilla ftp.kernel.org kernel, please try whether 2.4.30 already fixes this issue. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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/
