On Wednesday February 14, [EMAIL PROTECTED] wrote:
> You don't get it do you. Our source code is meaningless to the Open
> Source community at large. It is only useful to our tiny set of
> competitors that have nothing to do with Linux. The Embedded space is
> very specific. We are only _using_
On 2/15/07, Neil Brown <[EMAIL PROTECTED]> wrote:
[..] then it is less clear what people believe
Another area where it is less clear what people believe is if you are
distributing the module separately to the kernel, but, as I understand
it, vj says he is not.
But of course the person who's
Nadia Derbey <[EMAIL PROTECTED]> writes:
> But, what do you do with Oracle that's asking maxfiles to be set to 0x1,
> while the default value might be enough for a system that's not running
> Oracle.
> I'm afraid that giving boot time values to the max_* tunables we will loose
> all
> the
On Wednesday February 14, [EMAIL PROTECTED] wrote:
> On 2/14/07, Randy Dunlap <[EMAIL PROTECTED]> wrote:
> > We seem to have different definitions of open and closed.
>
> Open = 3rd party Linux drivers can be loaded. Closed = No third party
> Linux drivers can be loaded.
Loading a driver is not
Ben Nizette wrote:
v j wrote:
This is in reference to the following thread:
http://lkml.org/lkml/2006/12/14/63
I am not sure if this is ever addressed in LKML, but linux is _very_
popular in the embedded space. We (an embedded vendor) chose Linux 3
years back because of its lack of royalty
On Wed, 2007-02-14 at 21:16 -0800, v j wrote:
> This is in reference to the following thread:
>
> http://lkml.org/lkml/2006/12/14/63
>
> I am not sure if this is ever addressed in LKML, but linux is _very_
> popular in the embedded space. We (an embedded vendor) chose Linux 3
> years back
On Wed, Feb 14, 2007 at 10:46:13PM -0800, v j wrote:
> You don't get it do you. Our source code is meaningless to the Open
> Source community at large.
Linux supports entire _architectures_ of which there are single figures
of people using it. What makes your hardware special ?
> We are
After running SetPageUptodate, preceeding stores to the page contents to
actually bring it uptodate may not be ordered with the store to set the page
uptodate.
Therefore, another CPU which checks PageUptodate is true, then reads the
page contents can get stale data.
Fix this by ensuring
please ack if O.K.
-Kame
--
bind_zonelist() can create zero-length zonelist if there is a
memory-less-node. This patch checks the length of zonelist.
If length is 0, returns -EINVAL.
Changelog: v3 -> v4:
- changes a name of a temporal void* variable as "error_code"
Changelog: v2 -> v3
-
__block_write_full_page is calling SetPageUptodate without the page locked.
This is unusual, but not incorrect, as PG_writeback is still set.
However the next patch will require that SetPageUptodate always be called
with the page locked. Simply don't bother setting the page uptodate in this
case
On Wednesday February 14, [EMAIL PROTECTED] wrote:
> I am well aware of what Greg KHs position is, in fact he is the reason
> I started the whole rant. This is only a plea to the "higher
> authorities". Linus, please save Linux!
Linus is not in any position to do anything. The die is cast.
You
Ensure pages are uptodate after returning from read_cache_page, which allows
us to cut out most of the filesystem-internal PageUptodate calls.
I didn't have a great look down the call chains, but this appears to fixes 7
possible use-before uptodate in hfs, 2 in hfsplus, 1 in jfs, a few in
Various little cleanups and commenting fixes. Fixed up the patchset so
each one, incrementally, should give a properly compiling and running
kernel.
I'd still like Hugh to ack the anon/swap changes when he can find the time.
It would be desirable to get at least one ack as to the overall problem
On 2/14/07, Randy Dunlap <[EMAIL PROTECTED]> wrote:
At least one of us is confused about that an embedded User is.
It seems to me that you are an embedded developer, not User.
I doubt that most Embedded Users care what their OS is,
or even know what an OS is.
I am not sure what the difference
On Wed, Feb 14, 2007 at 10:27:10PM -0800, v j wrote:
> Not everybody has to be a contributor. The reason Linux is popular is
> because of its openness. Take that away and see where it goes.
please expand on this openness.
Especially wrt your add-ons.
Dave
--
On Sun, 11 Feb 2007 15:03:24 -0500 Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> Linux Kernel Markers, architecture independant code.
>
> Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
>
> ...
>
> +
> +#ifndef MARK
> +#define MARK GEN_MARK
> +#define MARK_ENABLE_TYPE GEN_MARK_ENABLE_TYPE
* Andrew Morton ([EMAIL PROTECTED]) wrote:
> On Sun, 11 Feb 2007 14:18:12 -0500 Mathieu Desnoyers <[EMAIL PROTECTED]>
> wrote:
>
> > local_t : powerpc extension
>
> This diff contains changes which are also present in "[PATCH 07/10]
> atomic.h : Add atomic64 cmpxchg, xchg and add_unless to
On 2/15/07, v j <[EMAIL PROTECTED]> wrote:
I am well aware of what Greg KHs position is, in fact he is the reason
I started the whole rant. This is only a plea to the "higher
authorities". Linus, please save Linux!
Oh boy. Guess what?
$ head -3 Documentation/ABI/testing/sysfs-class
What:
On Sun, 11 Feb 2007 15:03:27 -0500 Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> Linux Kernel Markers, non optimized architectures
>
> This patch also includes marker code for non optimized architectures.
I think once we've done this we can nuke
CONFIG_MARKERS_ENABLE_OPTIMIZATION? (Please,
On Wed, 14 Feb 2007 22:27:10 -0800 v j wrote:
> On 2/14/07, Dave Jones <[EMAIL PROTECTED]> wrote:
> > On Wed, Feb 14, 2007 at 09:16:28PM -0800, v j wrote:
> >
> > Welcome to three months ago.
> > Here in the future, this was deemed a non-issue.
> > However this does highlight another problem.
> >
On Sun, 11 Feb 2007 15:03:22 -0500 Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> You will find, in the following posts, the latest revision of the Linux Kernel
> Markers.
And what can I do with these markers?
And once I've done it, are there any userspace applications I can use to
get the
I am well aware of what Greg KHs position is, in fact he is the reason
I started the whole rant. This is only a plea to the "higher
authorities". Linus, please save Linux!
vj
On 2/14/07, Trent Waddington <[EMAIL PROTECTED]> wrote:
On 2/15/07, v j <[EMAIL PROTECTED]> wrote:
> If adding closed
Eric W. Biederman wrote:
Nadia Derbey <[EMAIL PROTECTED]> writes:
So, should I understand from this that automatic tuning and the AKT framework
itself would make sense, given that I find the rigth tunables it should be
applied to?
Sort of. The concept of things tuning themselves
On 2/15/07, v j <[EMAIL PROTECTED]> wrote:
If adding closed drivers to Linux is illegal, I am perfectly fine with
that. Just say so. I am not at a dead-end yet, until you make that
statement. Once you make that statement, then all bets are off. I am
betting that most companies will not even
On 2/15/07, v j <[EMAIL PROTECTED]> wrote:
You don't get it do you.
I think everyone on the list was thinking the same thing about you.
We are only _using_ Linux.
Yes, I think we all can see that.
Using our source code would not benefit anybody but our competitors.
Without knowing what
On Sun, 11 Feb 2007 14:18:12 -0500 Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> local_t : powerpc extension
This diff contains changes which are also present in "[PATCH 07/10]
atomic.h : Add atomic64 cmpxchg, xchg and add_unless to powerpc", resulting
in rather a mess.
I dropped the
On 2/14/07, Neil Brown <[EMAIL PROTECTED]> wrote:
> Not everybody has to be a contributor. The reason Linux is popular is
> because of its openness. Take that away and see where it goes.
So tell us? where does it go?
You seem to have the experience already. You took an open linux,
added some
On Thursday 15 February 2007, Neil Brown wrote:
>On Wednesday February 14, [EMAIL PROTECTED] wrote:
>> However we have a worrying trend here. If at some point it becomes
>> illegal to load our modules into the linux kernel, then it is
>> unacceptable to us. We would have been better off choosing
You don't get it do you. Our source code is meaningless to the Open
Source community at large. It is only useful to our tiny set of
competitors that have nothing to do with Linux. The Embedded space is
very specific. We are only _using_ Linux. Just as we could have used
VxWorks or OSE. Using our
On Wednesday February 14, [EMAIL PROTECTED] wrote:
> You are right. I have not contributed anything to Linux. Except one
> small patch to the MTD code. However, I don't think that is the point
> here. I am perfectly willing to live with the way Linux is today. I am
> telling you as a user that if
On Wed, 07 Feb 2007 13:07:40 -0800 Sriram Chidambaram <[EMAIL PROTECTED]> wrote:
> This patch provides the Fabric7 VIOC driver source code.
> This git mbox patch is built against
> git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
>
> The patch can be pulled from
On 2/15/07, v j <[EMAIL PROTECTED]> wrote:
This has nothing to do with politics. I am not a Linux contributor.
Here-in lies the problem. I am one of the few people willing to state
openly that I wish those who can, would use their legal claims to stop
people like you from writing proprietary
On Wed, Feb 14, 2007 at 10:43:35PM +0100, Rafael J. Wysocki wrote:
> Hi,
>
> On Wednesday, 14 February 2007 15:40, Gautham R Shenoy wrote:
> > Hello Everybody,
> >
> > This is an experiment towards process_freezer based implementation
> > of cpu-hotplug. This is mainly based on ideas of Andrew
Im trying to port some drivers between 2.6.14 and 2.6.19
I find that irqdesc has changed completely. how do i port
the drivers between 2.6.14 and 2.6.19?
is there a porting guide available to port the drivers
which use irqdesc?.
my drivers use variables triggered, ... which dont exist in
On 2/13/07, Conke Hu <[EMAIL PROTECTED]> wrote:
On 2/2/07, Conke Hu <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-02-07 at 07:40 -0500, Jeff Garzik wrote:
> > Conke Hu wrote:
> > > Hi,
> > >TEST_UNIT_READY in get_capabilities (drivers/scsi/sr.c line 743, or
> > > see below) always returns error.
On 2/14/07, Dave Jones <[EMAIL PROTECTED]> wrote:
On Wed, Feb 14, 2007 at 09:16:28PM -0800, v j wrote:
Welcome to three months ago.
Here in the future, this was deemed a non-issue.
However this does highlight another problem.
End-users who take linux for use in embedded systems (especially)
Linus,
Please pull 'master' from:
git://git.kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git
master
Basically, this series adds support for a bunch of newer cards and newer
drivers, do some relevant cleanups on cx88 (improving source code
readability and reducing binary code
v j wrote:
This is in reference to the following thread:
http://lkml.org/lkml/2006/12/14/63
I am not sure if this is ever addressed in LKML, but linux is _very_
popular in the embedded space. We (an embedded vendor) chose Linux 3
years back because of its lack of royalty model, robustness and
On Wed, Feb 14, 2007 at 10:14:53PM -0800, Andreas Gruenbacher wrote:
> On Wednesday 14 February 2007 21:45, Dave Jones wrote:
> > well, the situation for external modules is no worse than usual.
> > They still work, they just aren't signed. Which from a distributor point
> > of view, is
On 2/14/07, v j <[EMAIL PROTECTED]> wrote:
This has nothing to do with politics. I am not a Linux contributor. I realize
that people who have contributed to the Linux Kernel have very valid points. It
is their sweat and blood. They have a right to protect what they have worked
on. I am purely
On Wednesday February 14, [EMAIL PROTECTED] wrote:
>
> However we have a worrying trend here. If at some point it becomes
> illegal to load our modules into the linux kernel, then it is
> unacceptable to us. We would have been better off choosing VxWorks or
> OSE 3 years ago when we made an OS
On Wednesday 14 February 2007 21:45, Dave Jones wrote:
> well, the situation for external modules is no worse than usual.
> They still work, they just aren't signed. Which from a distributor point
> of view, is actually a nice thing, as they stick out like a sore thumb
> in oops reports with (U)
On Wed, Feb 14, 2007 at 09:16:28PM -0800, v j wrote:
> This is in reference to the following thread:
>
> http://lkml.org/lkml/2006/12/14/63
>
> I am not sure if this is ever addressed in LKML, but linux is _very_
> popular in the embedded space. We (an embedded vendor) chose Linux 3
>
On Thu, 15 Feb 2007 04:43:41 +0100 Blaisorblade <[EMAIL PROTECTED]> wrote:
> > I sent an equivalent patch in earlier today:
> Doh! Interesting this timing...
>
> > Index: linux-2.6/arch/x86_64/ia32/ptrace32.c
> > ===
> > ---
Eugene Ilkov wrote:
> I have I/O errors with Transcend SD highspeed card 2GB/150x when it's
> mounted in r/w mode (cardreader on sharp sl-c1000)
> It works well if I reverse mmcv4 patch commited to 2.6.19-git2
> (http://lkml.org/lkml/2006/10/4/27)
That patch is not the same as you are
On 2/15/07, v j <[EMAIL PROTECTED]> wrote:
The drivers which we have written over the last three years are suddenly
under threat.
[..]
The fact that Linux is becoming more and more closed is very very alarming.
Sigh. Someone remind me of the rules against "politics" on the list
before I get
On Wed, Feb 14, 2007 at 09:35:40PM -0800, Andreas Gruenbacher wrote:
> On Wednesday 14 February 2007 20:13, Dave Jones wrote:
> > I've not investigated it, but I hear rumours that suse has something
> > similar.
>
> Actually, no. We don't belive that module signing adds significant value,
No its not. It wasn't common knowledge 3 years ago when we chose Linux
as an embedded platform. If it indeed is common knowledge that
loadable modules in Linux have to be open-source then it is very
probable that we wouldn't have chosen Linux as the platform of choice.
If this indeed is the case
On Wednesday 14 February 2007 20:13, Dave Jones wrote:
> I've not investigated it, but I hear rumours that suse has something
> similar.
Actually, no. We don't belive that module signing adds significant value, and
it also doesn't work well with external modules. (The external modules we
really
> Please, tell us what problem this is fixing so that we can look into
> alternative solutions.
This patch fixes a kernel panic "Kernel BUG at fs/aio.c:509"
http://marc.theaimsgroup.com/?l=linux-kernel=117031052517746=2
First of all it was found that the kernel panic happens after
IO error
Jakub Narebski <[EMAIL PROTECTED]> wrote:
> Junio C Hamano wrote:
>
> > - git-blame learned a new option, --incremental, that tells it
> > to output the blames as they are assigned. A sample script
> > to use it is also included as contrib/blameview.
>
> And there are example GUI
This is in reference to the following thread:
http://lkml.org/lkml/2006/12/14/63
I am not sure if this is ever addressed in LKML, but linux is _very_
popular in the embedded space. We (an embedded vendor) chose Linux 3
years back because of its lack of royalty model, robustness and
availability
On Wed, 14 Feb 2007 21:42:26 + Ralf Baechle <[EMAIL PROTECTED]> wrote:
> Time for a little bit of dead horse flogging.
>
> On Mon, Mar 06, 2006 at 05:05:52PM -0800, Andrew Morton wrote:
>
> > > --- a/include/asm-generic/unaligned.h
> > > +++ b/include/asm-generic/unaligned.h
> > > @@ -78,7
While testing out some libata FUA changes I was working on, I was
inadvertently able to reproduce the kind of NCQ command timeouts in
sata_nv that a few people have reported. I since verified that the FUA
stuff had nothing to do with it as it still happens even with FUA
disabled. However I'm
Hi Andrew,
This problem was identified and fixed some time ago by Jeff Moyer
but it fell through the cracks somehow.
It is possible that a user space application could remove and
re-create a directory during a request. To avoid returning a
failure from lookup incorrectly when our current dentry
On Thu, 15 Feb 2007 15:05:56 +1100 Paul Mackerras <[EMAIL PROTECTED]> wrote:
> Andrew Morton writes:
>
> > This is all fairly unpleasant.
> >
> > What architecture is preventing us from using DIE_NMI_POST on all
> > architectures which support ipmi? ia64?
> >
> > It would be better to simply
Hi Andrew,
Jeff Moyer has identified a race between mount and expire.
What happens is that during an expire the situation can arise
that a directory is removed and another lookup is done before
the expire issues a completion status to the kernel module.
In this case, since the the lookup gets a
On Wed, Feb 14, 2007 at 07:41:12PM -0800, Andrew Morton wrote:
> 77 files changed, 9681 insertions(+), 10 deletions(-)
>
> just to be able to sign modules.
>
> Normally I'd collapse writhing in laughter, but..
>
> > These patches have been in use by RHEL and Fedora kernels for years,
Andrew Morton writes:
> This is all fairly unpleasant.
>
> What architecture is preventing us from using DIE_NMI_POST on all
> architectures which support ipmi? ia64?
>
> It would be better to simply require that all ipmi-using architectures
> implement notify_die(DIE_NMI_POST, ...).
We're
On Wed, 14 Feb 2007 14:12:57 -0600 Corey Minyard <[EMAIL PROTECTED]> wrote:
>
> Convert over to the new NMI handling for getting IPMI watchdog
> timeouts via an NMI. This add config options to know if there
> is the ability to receive NMIs and if it has an NMI post processing
> call. Then it
Hi Andrew,
The current header file definitions for autofs version 5 have
caused a couple of problems for application builds downstream.
This fixes the problem by separating the definitions.
Signed-off-by: Ian Kent <[EMAIL PROTECTED]>
Ian
---
---
On Thursday 15 February 2007 03:54, Jeff Dike wrote:
> On Thu, Feb 15, 2007 at 03:34:23AM +0100, Paolo 'Blaisorblade' Giarrusso
wrote:
> > Index: linux-2.6.git/arch/x86_64/ia32/ptrace32.c
> > ===
> > ---
On Wed, 14 Feb 2007 19:09:38 + David Howells <[EMAIL PROTECTED]> wrote:
> These patches provide a GPG-based kernel module signing facility. Their use
> is
> not fully automated within the confines of the kernel build process because it
> needs provision of keys from outside of the kernel
On Wed, 14 Feb 2007 20:51:33 +0300 "Ananiev, Leonid I" <[EMAIL PROTECTED]>
wrote:
> Fix kernel bug when IO page is temporally busy:
> invalidate_inode_pages2_range() returns EIOCBRETRY but not EIO.
> invalidate_inode_pages2() returns EIO as earlier.
>
> Signed-off-by: Leonid Ananiev <[EMAIL
On Wednesday 14 February 2007 14:57, Andreas Gruenbacher wrote:
> [1] Always make disconnected paths relative:
>
> From all these choices, I actually like [1] best, together with hiding
> unreachable mount points in /proc/$pid/mounts and /proc/$pid/mountstats:
> there is no real point in
On Thu, Feb 15, 2007 at 03:34:23AM +0100, Paolo 'Blaisorblade' Giarrusso wrote:
> Index: linux-2.6.git/arch/x86_64/ia32/ptrace32.c
> ===
> --- linux-2.6.git.orig/arch/x86_64/ia32/ptrace32.c
> +++
But the whole point is that the notion of a "register" is wrong in
the
first place. [...]
forget about it then. The thing we "register" is dead-simple:
struct async_head_user {
struct syslet_uatom __user **completion_ring;
unsigned long
I'm finally back from my travel and conference hiatus.. you guys have
been busy! :)
On Feb 13, 2007, at 6:20 AM, Ingo Molnar wrote:
I'm pleased to announce the first release of the "Syslet" kernel
feature
and kernel subsystem, which provides generic asynchrous system call
support:
On Sunday 04 February 2007 16:15, Neil Brown wrote:
> The behaviour in the face of a lazy unmount should be clarified in
> this comment.
Done.
> If sys_getcwd is called on a directory that is no longer
> connected to the root, it isn't clear to me that it should return
> without an error.
>
Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> I'm pretty certain we explicitly drop the weird GNU note that
>> is automatically generated by gcc and specifies something informational.
>>
> But that's something else again, since it appears as a PT_GNU_STACK phdr.
Also PTRACE_OLDSETOPTIONS should be accepted, as done by kernel/ptrace.c and
forced by binary compatibility. UML/32bit breaks because of this - since it is
wise
enough to use PTRACE_OLDSETOPTIONS to be binary compatible with 2.4 host
kernels.
Until 2.6.17 (commit
Hello, Ingo!
Many thanks for the lockdep validator! It has helped me immensely.
However, lockdep-design.txt has been pretty hard to read for me.
It would be great if you find an opportunity to clarify two things in
the documentation.
1) What is a lock dependency? What does "L1 -> L2" mean?
Eric W. Biederman wrote:
> I'm pretty certain we explicitly drop the weird GNU note that
> is automatically generated by gcc and specifies something informational.
>
But that's something else again, since it appears as a PT_GNU_STACK phdr.
> I don't think anything we are doing is wrong but ld
Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> Reasonable and it's probably worth letting the binutils developer know.
>> I do agree that it is weird. It might be that something in binutils
>> doesn't like us dropping some of the notes.
>>
>
> What do you mean
From: Jay Cliburn <[EMAIL PROTECTED]>
Bump the version number.
Signed-off-by: Jay Cliburn <[EMAIL PROTECTED]>
---
drivers/net/atl1/atl1_main.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/atl1/atl1_main.c b/drivers/net/atl1/atl1_main.c
index
From: Chris Snook <[EMAIL PROTECTED]>
Add device id for the Attansic L1 chip to pci_ids.h, then use it.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
Signed-off-by: Jay Cliburn <[EMAIL PROTECTED]>
---
drivers/net/atl1/atl1_main.c |2 +-
include/linux/pci_ids.h |1 +
2 files
From: Chris Snook <[EMAIL PROTECTED]>
Remove unused define from atl1_main.c.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
Signed-off-by: Jay Cliburn <[EMAIL PROTECTED]>
---
drivers/net/atl1/atl1_main.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git
Update version and author information.
Signed-off-by: Sumant Patro <[EMAIL PROTECTED]>
---
drivers/scsi/megaraid/megaraid_sas.c |8 +---
drivers/scsi/megaraid/megaraid_sas.h |6 +++---
2 files changed, 8 insertions(+), 6 deletions(-)
diff -uprN
From: Jay Cliburn <[EMAIL PROTECTED]>
On some Asus motherboards containing the L1 NIC, the MAC address is
written by the BIOS directly to the MAC register during POST, and is
not stored in eeprom. If we don't succeed in fetching the MAC address
from eeprom or spi, try reading it directly from
From: Al Viro <[EMAIL PROTECTED]>
An ioread32 statement reads the wrong address. Fix it.
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
Signed-off-by: Jay Cliburn <[EMAIL PROTECTED]>
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
---
drivers/net/atl1/atl1_hw.c |2 +-
1 files changed, 1
From: Jay Cliburn <[EMAIL PROTECTED]>
The atl1 driver doesn't need NET_PCI. Remove it from Kconfig.
Noticed by Chad Sprouse.
Signed-off-by: Jay Cliburn <[EMAIL PROTECTED]>
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
---
drivers/net/Kconfig |2 +-
1 files changed, 1 insertions(+), 1
Jeff,
Please accept the following patchset for the atl1 network device driver.
* Drop unnecessary NET_PCI config
* Fix incorrect hash table address
* Read MAC address from register
* Remove unused define
* Add Attansic L1 device id to pci_ids
* Bump version number
This patchset contains changes
FW does not support SYNCHRONIZE_CACHE cmd. FW flush cache on its own.
So, we just return success from the megasas_queue_command.
Signed-off-by: Sumant Patro <[EMAIL PROTECTED]>
---
drivers/scsi/megaraid/megaraid_sas.c | 12
1 files changed, 12 insertions(+)
diff -uprN
On Wed, 14 Feb 2007, Jeremy Fitzhardinge wrote:
> Davide Libenzi wrote:
> >> Would this work?
> >>
> >
> > Hopefully the API will simplify enough so that emulation will becomes
> > easier.
> >
>
> The big question in my mind is how all this stuff interacts with
> signals. Can a blocked
Replaced pci_alloc_consistent with dma_alloc_coherent from the ioctl path.
This is to avoid situations where ioctl fails for lack of memory
(when system under heavy stress).
Signed-off-by: Sumant Patro <[EMAIL PROTECTED]>
---
drivers/scsi/megaraid/megaraid_sas.c | 12 ++--
1 files
Checks added in megasas_queue_command to know if FW is able to process
commands within the timeout period. If number of retries is 2 or more,
the driver stops sending cmd to FW. IO is resumed when pending cmd count
reduces to 16 or 10 seconds has elapsed from the time cmds were last
sent to FW.
Junio C Hamano wrote:
> - git-blame learned a new option, --incremental, that tells it
> to output the blames as they are assigned. A sample script
> to use it is also included as contrib/blameview.
And there are example GUI blameview (Perk GTK2), and example Emacs module
for incremental
Eric W. Biederman wrote:
> Reasonable and it's probably worth letting the binutils developer know.
> I do agree that it is weird. It might be that something in binutils
> doesn't like us dropping some of the notes.
>
What do you mean by "dropping some of the notes"? I think the only
notes
Added bios_param in scsi_host_template to return disk geometry.
Signed-off-by: Sumant Patro <[EMAIL PROTECTED]>
---
drivers/scsi/megaraid/megaraid_sas.c | 45 +
1 files changed, 45 insertions(+)
Resubmitting with following changes : ulong -> unsigned long, removed
Checks if hw_crit_error is set.
If it is set, we donot process commands.
Checks added in megasas_queue_command and command completion routines.
Signed-off-by: Sumant Patro <[EMAIL PROTECTED]>
---
drivers/scsi/megaraid/megaraid_sas.c | 13 -
1 files changed, 12 insertions(+), 1
Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> Ok. If that is all this may be a difference that makes no difference.
>> binutils has a bad habit of looking at sections (which are fully
>> optional) instead of segments on ET_EXEC and ET_DYN objects. Only
>> ET_REL
nobh_prepare_write leaks data similarly to how simple_prepare_write did. Fix
by not marking the page uptodate until nobh_commit_write time. Again, this
could break weird use-cases, but none appear to exist in the tree.
We can safely remove the set_page_dirty, because as the comment says,
On 2/14/07, Benjamin LaHaise <[EMAIL PROTECTED]> wrote:
My opinion of this whole thread is that it implies that our thread creation
and/or context switch is too slow. If that is the case, improve those
elements first. At least some of those optimizations have to be done in
hardware on x86,
simple_prepare_write leaks uninitialised kernel data. This happens because the
it leaves an uninitialised "hole" over the part of the page that the write is
expected to go to. This is fine, but it then marks the page uptodate, which
means a concurrent read can come in and copy the uninitialised
On Wed, 14 Feb 2007, Davide Libenzi wrote:
> On Wed, 14 Feb 2007, Ingo Molnar wrote:
>
> > yeah, that's another key thing. I do plan to provide a sys_upcall()
> > syscall as well which calls a 5-parameter user-space function with a
> > special stack. (it's like a lightweight signal/event
Hey all,
I am having troubles connecting and interfacing to a device called a
USRP via USB which is used with GNU Radio. At one time, the setup
worked perfectly fine with no errors. Then i tried to give a regular
user permission to the USB device and everything went downhill.
Now,
On 2/13/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
Well, we already bump up reference count in fork() w/o grabbing those
mutexes don't we? Also if rmdir() sees container->count to be zero, then
it means no task is attached to the container. How will then a function
like bc_file_charge()
David Miller wrote:
From: Pete Clements <[EMAIL PROTECTED]>
Date: Mon, 12 Feb 2007 20:10:13 -0500 (EST)
2.6.20-git8 fails compile:
CHK include/linux/compile.h
UPD include/linux/compile.h
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
net/built-in.o: In
On Wed, 14 Feb 2007, Ingo Molnar wrote:
> yeah, that's another key thing. I do plan to provide a sys_upcall()
> syscall as well which calls a 5-parameter user-space function with a
> special stack. (it's like a lightweight signal/event handler, without
> any of the signal handler legacies and
I agree with Christoph -- the use of wait_for_completion() in a loop
makes no sense. When you send a new copy of this patch without
whitespace damage, please fix that up too...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
1 - 100 of 746 matches
Mail list logo
