On Wed, 3 Jan 2007, Andrew Morton wrote:
> On Sun, 31 Dec 2006 15:55:22 -0500 (EST)
> "Robert P. J. Day" <[EMAIL PROTECTED]> wrote:
>
> > --- a/net/ipv4/netfilter/nf_nat_core.c
> > +++ b/net/ipv4/netfilter/nf_nat_core.c
> > @@ -168,7 +168,7 @@ find_appropriate_src(const struct nf_conntrack_tuple
Arnd Bergmann wrote:
>
> One promising effort for a replacement is Jörn's logfs
> (http://wiki.laptop.org/go/Logfs), which should scale well to many
> gigabytes. A driver based on MMC would be a nice development tool
> for that, since it enables regular PCs as a debugging machine
> instead of
Philip Langdale wrote:
> Pierre Ossman wrote:
>
>> Amen to that. All hw vendors that implement this particular form of
>> brain damage should be dragged out and shot.
>>
>> I'll fix a patch for this later on.
>>
>
> See my updated Take 3 patch. I've implemented a uniqueness fix by
> adding
On 12/31/06, Mitchell Blank Jr <[EMAIL PROTECTED]> wrote:
Looking at aligned_kmalloc() it seems to be pretty badly broken -- its fallback
if it gets a non-aligned buffer is to just try a larger size which doesn't
necessarily fix the problem. It looks like explicitly aligning the buffer
is a
Andrew Morton wrote:
On Wed, 03 Jan 2007 22:56:07 -0800 (PST)
David Miller <[EMAIL PROTECTED]> wrote:
Anyway that leaves us with the question of why Andrea's database is getting
corrupted. Hopefully he can give us a minimal test-case.
It'd odd that stories of pre-2.6.19 BerkeleyDB
Linus Torvalds writes:
[probably Mikael Pettersson] writes:
The suggestions I've had so far which I have not yet tried:
- Select a different x86 CPU in the config.
- Unfortunately the C3-2 flags seem to simply tell GCC to
schedule for ppro (like i686) and enabled MMX and SSE
-
On Wed, 03 Jan 2007 22:56:07 -0800 (PST)
David Miller <[EMAIL PROTECTED]> wrote:
> From: Andrew Morton <[EMAIL PROTECTED]>
> Date: Wed, 3 Jan 2007 22:12:20 -0800
>
> > On Thu, 04 Jan 2007 17:03:43 +1100
> > Nick Piggin <[EMAIL PROTECTED]> wrote:
> >
> > > > That bug was introduced in 2.6.19,
most architectures (pretty much everyone but like x86/x86_64/s390)
export empty asm/page.h headers ... considering how useless these are,
why bother exporting them at all ? clearly userspace is unable to
rely on it across architectures, so by making it available to the two
most common
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Wed, 3 Jan 2007 22:12:20 -0800
> On Thu, 04 Jan 2007 17:03:43 +1100
> Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > > That bug was introduced in 2.6.19, with the dirty page tracking patches.
> > >
> > > 2.6.18 and earlier used ->private_lock coverage
Christoph Hellwig wrote:
On Thu, Dec 28, 2006 at 08:17:17PM +0530, Suparna Bhattacharya wrote:
I am really bad with names :( I tried using the _wq suffixes earlier and
that seemed confusing to some, but if no one else objects I'm happy to use
that. I thought aio_lock_page() might be
Suparna Bhattacharya wrote:
On Thu, Jan 04, 2007 at 04:51:58PM +1100, Nick Piggin wrote:
So long as AIO threads do the same, there would be no problem (plugging
is optional, of course).
Yup, the AIO threads run the same code as for regular IO, i.e in the rare
situations where they actually
Pierre Ossman wrote:
>
> Amen to that. All hw vendors that implement this particular form of
> brain damage should be dragged out and shot.
>
> I'll fix a patch for this later on.
See my updated Take 3 patch. I've implemented a uniqueness fix by
adding additional RSP flags do make R6 and R7
Thanks to the generous donation of an SDHC card by John Gilmore, and the
surprisingly enlightened decision by the SD Card Association to publish
useful specs, I've been able to bash out support for SDHC. The changes
are not too profound:
i) Add a card flag indicating the card uses block level
On Wednesday 03 January 2007 2:51 pm, Voipio Riku wrote:
>
> > Yes, the patch you sent (switching to "method 3" to work around the
> > evident bug in the i2c-ixp3xx driver) works on the platform I was
> > using too (after unrelated tweaks).
>
> > Here's an updated patch, using "method 3". If it
On Thu, Jan 04, 2007 at 04:51:58PM +1100, Nick Piggin wrote:
> Suparna Bhattacharya wrote:
> >On Wed, Jan 03, 2007 at 02:15:56PM -0800, Andrew Morton wrote:
>
> >>Plus Jens's unplugging changes add more reliance upon context inside
> >>*current, for the plugging and unplugging operations. I
On Thu, 04 Jan 2007 17:03:43 +1100
Nick Piggin <[EMAIL PROTECTED]> wrote:
> > That bug was introduced in 2.6.19, with the dirty page tracking patches.
> >
> > 2.6.18 and earlier used ->private_lock coverage in try_to_free_buffers() to
> > prevent it.
>
> Ohh, right you are, I was looking at
Andrew Morton wrote:
On Wed, 3 Jan 2007 20:44:36 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
Actually, I think 2.6.18 may have a subtle variation on it.
In particular, I look back at the try_to_free_buffers() thing that I hated
so much, and it makes me wonder.. It used to do:
Philip Langdale wrote:
> This is a bug. The MMC_RSP_R? #defines do not fully characterise the
> responses (specically, the way that the response is parsed is not
> characterised) and consequently there is no guarantee of uniqueness.
> Given this reality - the way that the tifm_sd driver works is
Suparna Bhattacharya wrote:
On Wed, Jan 03, 2007 at 02:15:56PM -0800, Andrew Morton wrote:
Plus Jens's unplugging changes add more reliance upon context inside
*current, for the plugging and unplugging operations. I expect that the
fsaio patches will need to be aware of the protocol which
On Wed, Jan 03, 2007 at 05:29:16PM -0800, Stephen Hemminger wrote:
> On Wed, 3 Jan 2007 16:56:00 -0800
> Greg KH <[EMAIL PROTECTED]> wrote:
>
> > On Wed, Jan 03, 2007 at 04:50:20PM -0800, Stephen Hemminger wrote:
> > > Is there some missing magic (udev rule?) that keeps i2c device modules
> > >
Greetings all;
I bought a Belkin Wireless G card, a pci 802-11 radio of some sort.
The main chip on it wears the label "RTL8185L"
Is there any support for making this a wireless server in the kernel at
the present time?
I have visions of sticking it in the last pci slot of a box running
On Wed, 3 Jan 2007 20:44:36 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Actually, I think 2.6.18 may have a subtle variation on it.
>
> In particular, I look back at the try_to_free_buffers() thing that I hated
> so much, and it makes me wonder.. It used to do:
>
>
On Wednesday 27 September 2006 07:51, [EMAIL PROTECTED] wrote:
> >> > Will sony_acpi ever make it to the mainline? Its very useful for new
> > Nope, not as it is. Useful != supportable.
> >
> > 1. It must not create any files under /proc/acpi
> > This is creating a machine-specific API,
Andrew Morton wrote:
> On Mon, 01 Jan 2007 07:29:55 -0800
> Philip Langdale <[EMAIL PROTECTED]> wrote:
>
>> #define MMC_RSP_R1B
>> (MMC_RSP_PRESENT|MMC_RSP_CRC|MMC_RSP_OPCODE|MMC_RSP_BUSY)
>> #define MMC_RSP_R2 (MMC_RSP_PRESENT|MMC_RSP_136|MMC_RSP_CRC)
>> #define MMC_RSP_R3
> If you think I should not add the udata parameter to the req_notify_cq()
> provider verb, then I can rework the chelsio driver:
>
> 1) at cq creation time, pass the virtual address of the u32 used by the
> library to track the current cq index. That way the chelsio kernel
> driver can save the
Linus Torvalds wrote:
On Thu, 4 Jan 2007, Nick Piggin wrote:
Yhat's when the bug was introduced -- 2.6.19. 2.6.18 does not have
this bug, so it cannot be years old.
Actually, I think 2.6.18 may have a subtle variation on it.
In particular, I look back at the try_to_free_buffers() thing
Pablo Sebastian Greco wrote:
> By crash I mean the whole system going down, having to reset the entire
> machine.
> I'm sending you 4 files:
> dmesg: current boot dmesg, just a boot, because no errors appeared after
> last crash, since the server is out of production right now (errors
> usually
Adrian Bunk wrote:
This patch contains the scheduled find_trylock_page() removal.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
I guess I don't have a problem with this going into -mm and making its way
upstream sometime after the next release.
I would normally say it is OK to stay for
On Wed, Jan 03, 2007 at 02:15:56PM -0800, Andrew Morton wrote:
> On Thu, 28 Dec 2006 13:53:08 +0530
> Suparna Bhattacharya <[EMAIL PROTECTED]> wrote:
>
> > This patchset implements changes to make filesystem AIO read
> > and write asynchronous for the non O_DIRECT case.
>
> Unfortunately the
* Bill Huey <[EMAIL PROTECTED]> wrote:
> > - Documentation/CodingStyle compliance - the code is not ugly per se
> >but still looks a bit 'alien' - please try to make it look Linuxish,
> >if i apply this we'll probably stick with it forever. This is the
> >major reason i havent
On Thu, 4 Jan 2007, Nick Piggin wrote:
>
> Yhat's when the bug was introduced -- 2.6.19. 2.6.18 does not have
> this bug, so it cannot be years old.
Actually, I think 2.6.18 may have a subtle variation on it.
In particular, I look back at the try_to_free_buffers() thing that I hated
so
Trivial. Newlines missing on the SOCK_DEBUG's for X.25 facility negotiation.
Signed-off-by: Andrew Hendry <[EMAIL PROTECTED]>
--- linux-2.6.19-vanilla/net/x25/x25_facilities.c 2006-12-31
22:31:07.0 +1100
+++ linux-2.6.19/net/x25/x25_facilities.c 2007-01-01
Jens Axboe wrote:
Nick writes:
This is a patch to perform block device plugging explicitly in the submitting
process context rather than implicitly by the block device.
Hi Jens,
Hey thanks for doing so much hard work with this, I couldn't have fixed
all the block layer stuff myself. QRCU
On Wed, Jan 03, 2007 at 08:26:57PM +0300, Oleg Nesterov wrote:
>
> I thought that these patches don't depend on each other, flush_work/workueue
> don't care where cpu-hotplug takes workqueue_mutex, in CPU_LOCK_ACQUIRE or in
> CPU_UP_PREPARE case (or CPU_DEAD/CPU_LOCK_RELEASE for unlock).
>
>
Andrea Gelmini wrote:
On Sun, Dec 31, 2006 at 02:55:58PM +1100, Nick Piggin wrote:
This bug was only introduced in 2.6.19, due to a change that caused pte
no, Linus said that with 2.6.19 it's easier to trigger this bug...
Yhat's when the bug was introduced -- 2.6.19. 2.6.18 does not have
View the active forwarded call list
cat /proc/net/x25/forward
Signed-off-by: Andrew Hendry <[EMAIL PROTECTED]>
--- linux-2.6.19-vanilla/net/x25/x25_proc.c 2006-12-31 22:31:07.0
+1100
+++ linux-2.6.19/net/x25/x25_proc.c 2007-01-01 19:16:56.0 +1100
@@ -165,6 +165,75 @@
Adds call forwarding to X.25, allowing it to operate like an X.25 router.
Useful if one needs to manipulate X.25 traffic with tools like tc.
This is an update/cleanup based off a patch submitted by Daniel Ferenci a few
years ago.
Worked ok with Cisco XoT, linux X.25 back to back, and some old
On Thursday 04 January 2007 01:50, Ed Sweetman wrote:
> Not sure what went on between 2.6.19-rc5-mm2 and 2.6.20-rc2-mm2 in
> libata land but SMART is no longer available on my hdds. I'm assuming
> this is not the intended behavior.
>
> In case this is chipset specific, IDE interface: nVidia
On Wed, Jan 03, 2007 at 01:22:32PM -0800, Andrew Morton wrote:
> It's nice to always have a comment explaining the use of open-coded
> barriers. Because often the reader is left wondered what on earth it's
> barriering against what on earth else.
>
Ok, here it is...
Andrew asked that the
Andrew Lyon wrote:
> Is there anything more I can do to assist? I plan to upgrade to
> 2.6.19/latest at the weekend, let me know if there is anything more i
> can do.
WD740ADFD-00 is blacklisted for NCQ in .20-rcX kernels, so you won't see
the problem anymore there. If you're gonna use 2.6.19,
bbee wrote:
> Sorry, I thought you meant you would need to update it *further*. I
> applied the patch you gave to Andrew with this result so far:
>
> $ dmesg | grep -A1 "spurious interrupt"
> ata1: spurious interrupt (irq_stat 0x8 active_tag 0xfafbfcfd sactive 0x0)
> ata1: issue=0x0 SAct=0x0
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Linus Torvalds
> Sent: 2007年1月4日 0:04
> To: Grzegorz Kulewski
> Cc: Alan; Mikael Pettersson; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
>
From: Adrian Bunk <[EMAIL PROTECTED]>
Date: Thu, 4 Jan 2007 00:09:28 +0100
> This patch adds a proper prototype for x25_init_timers() in
> include/net/x25.h
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Applied, thanks Adrian.
-
To unsubscribe from this list: send the line "unsubscribe
From: Amit Choudhary <[EMAIL PROTECTED]>
Date: Sat, 30 Dec 2006 18:26:03 -0800
> Description: Fix infinite recursion when alignment passed is 0 in function
> aligned_kmalloc(), in file drivers/atm/firestream.c. Also, a negative value
> for alignment does not make sense. Check for negative value
Bill Huey (hui) wrote:
> This should have the fix.
>
>
http://mmlinux.sf.net/public/patch-2.6.20-rc2-rt2.3.lock_stat.patch
>
> If you can rerun it and post the results, it'll hopefully show the
> behavior of that lock acquisition better.
>
Here's the run with fix to produce correct statistics.
From: Segher Boessenkool <[EMAIL PROTECTED]>
Date: Wed, 3 Jan 2007 16:23:53 +0100
> >>> therefore you can't let multiple CPUs call
> >>> into OFW at one time. You must use some kind of locking mechanism,
> >>> and that locking mechanism is not simple because it has to not just
> >>> stop the
The first open hardware docs for the Promise SX4 (sata_sx4) series are
now available:
http://gkernel.sourceforge.net/specs/promise/pdc20621-pguide-dimm-1.6.pdf.bz2
http://gkernel.sourceforge.net/specs/promise/pdc20621-pguide-pll-ata-timing-1.2.pdf.bz2
These are only small, ancillary guides; the
Not sure what went on between 2.6.19-rc5-mm2 and 2.6.20-rc2-mm2 in
libata land but SMART is no longer available on my hdds. I'm assuming
this is not the intended behavior.
In case this is chipset specific, IDE interface: nVidia Corporation
CK804 Serial ATA Controller (rev f3)
I'm using
On Wed, 3 Jan 2007 16:56:00 -0800
Greg KH <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 03, 2007 at 04:50:20PM -0800, Stephen Hemminger wrote:
> > Is there some missing magic (udev rule?) that keeps i2c device modules
> > from loading? For example: the Intel i2c-i801 module ought to get loaded
> >
On Wed, Jan 03, 2007 at 05:11:04PM -0800, Chen, Tim C wrote:
> Bill Huey (hui) wrote:
> >
> > Thanks, the numbers look a bit weird in that the first column should
> > have a bigger number of events than that second column since it is a
> > special case subset. Looking at the lock_stat_note() code
just a simple test I did...
xfs_freeze -f /mnt/newtest
cp /etc/fstab /mnt/newtest
xfs_freeze -u /mnt/newtest
2007-01-04 01:44:30.341979500 <4>BUG: warning at
kernel/mutex-debug.c:80/debug_mutex_unlock()
2007-01-04 01:44:30.385771500 <4> [] dump_trace+0x215/0x21a
2007-01-04 01:44:30.385774500 <4>
Bill Huey (hui) wrote:
>
> Thanks, the numbers look a bit weird in that the first column should
> have a bigger number of events than that second column since it is a
> special case subset. Looking at the lock_stat_note() code should show
> that to be the case. Did you make a change to the output
This patch adds a proper prototype for x25_init_timers() in
include/net/x25.h
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
include/net/x25.h |1 +
net/x25/af_x25.c |2 --
2 files changed, 1 insertion(+), 2 deletions(-)
--- linux-2.6.20-rc2-mm1/include/net/x25.h.old 2007-01-03
On Wed, Jan 03, 2007 at 05:00:49PM -0800, Bill Huey wrote:
> On Wed, Jan 03, 2007 at 04:46:37PM -0800, Chen, Tim C wrote:
> > @contention events = 247149
> > @failure_events = 146
> > @lookup_failed_scope = 175
> > @lookup_failed_static = 43
> > @static_found = 16
> > [1, 113, 77 -- 32768, 0]
On 1/3/07, bbee <[EMAIL PROTECTED]> wrote:
On Wed, 3 Jan 2007, Tejun Heo wrote:
> bbee wrote:
>>> Yeap, I have major issues with SDB FISes which contains spurious
>>> completions but most other spurious interrupts shouldn't be dangerous
>>> and I haven't seen spurious completions for quite some
On Wed, Jan 03, 2007 at 04:46:37PM -0800, Chen, Tim C wrote:
> Bill Huey (hui) wrote:
> > Can you sort the output ("sort -n" what ever..) and post it without
> > the zeroed entries ?
> >
> > I'm curious about how that statistical spike compares to the rest of
> > the system activity. I'm sure
On Wed, Jan 03, 2007 at 04:50:20PM -0800, Stephen Hemminger wrote:
> Is there some missing magic (udev rule?) that keeps i2c device modules
> from loading? For example: the Intel i2c-i801 module ought to get loaded
> automatically on boot up since it has a set of PCI id's that generate
> the
Is there some missing magic (udev rule?) that keeps i2c device modules
from loading? For example: the Intel i2c-i801 module ought to get loaded
automatically on boot up since it has a set of PCI id's that generate
the necessary module aliases. It would be better if I2C device's autoloaded
like
On Sun, 31 Dec 2006 15:55:22 -0500 (EST)
"Robert P. J. Day" <[EMAIL PROTECTED]> wrote:
> --- a/net/ipv4/netfilter/nf_nat_core.c
> +++ b/net/ipv4/netfilter/nf_nat_core.c
> @@ -168,7 +168,7 @@ find_appropriate_src(const struct nf_conntrack_tuple
> *tuple,
>
> read_lock_bh(_nat_lock);
>
> On Tue, 02 Jan 2007 15:01:56 PST, David Schwartz said:
> > There is simply no way you can argue that McDonald's failed to
> > warn people
> > about the risks. The cup says "hot" on it,
> Actually, the "HOT" on the cup and the sticker in the drive-through that
> says "Warning: Coffee is served
Bill Huey (hui) wrote:
> Can you sort the output ("sort -n" what ever..) and post it without
> the zeroed entries ?
>
> I'm curious about how that statistical spike compares to the rest of
> the system activity. I'm sure that'll get the attention of Peter as
> well and maybe he'll do something
On Wed, 2007-01-03 at 14:35 +0200, Benny Halevy wrote:
> Believe it or not, but server companies like Panasas try to follow the
> standard
> when designing and implementing their products while relying on client vendors
> to do the same.
I personally have never given a rats arse about
On 1/3/07, Bauke Jan Douma <[EMAIL PROTECTED]> wrote:
Not a big deal (I just discovered 'make gconfig'), but I'm experiencing
a reproducible segfault in 'make xconfig', i.e. qconf.
I was wondering if anyone else can reproduce this:
1. QTDIR=/usr/local/lib/qt make xconfig
mine by default
On Wed, Jan 03, 2007 at 04:25:46PM -0800, Chen, Tim C wrote:
> Earlier I used latency_trace and figured that there was read contention
> on mm->mmap_sem during call to _rt_down_read by java threads
> when I was running volanomark. That caused the slowdown of the rt
> kernel
> compared to non-rt
On Wed, 03 Jan 2007 17:46:00 -0600
Eric Sandeen <[EMAIL PROTECTED]> wrote:
> Take 2... all in one file. I suppose I really did know better than
> to create that new header. ;-)
>
> Better?
>
> ---
>
> CVE-2006-5753 is for a case where an inode can be marked bad, switching
> the ops to
Bill Huey (hui) wrote:
>
> Good to know that. What did the output reveal ?
>
> What's your intended use again summarized ? futex contention ? I'll
> read the first posting again.
>
Earlier I used latency_trace and figured that there was read contention
on mm->mmap_sem during call to
Thoughts from Jeff & company on merging the patch below into libata-dev?
This has been in the -mm tree for over a month now, I haven't heard any
complaints about regressions..
---
From: Robert Hancock <[EMAIL PROTECTED]>
This patch adds the necessary callbacks to support suspend/resume
On Wed, Jan 03, 2007 at 03:59:28PM -0800, Chen, Tim C wrote:
> Bill Huey (hui) wrote:
> http://mmlinux.sourceforge.net/public/patch-2.6.20-rc2-rt2.2.lock_stat.patch
>
> This version is much better and ran stablely.
>
> If I'm reading the output correctly, the locks are listed by
> their
On Thu, Jan 04, 2007 at 12:43:20AM +0100, Mikulas Patocka wrote:
> On Wed, 3 Jan 2007, Frank van Maarseveen wrote:
> >Currently, large file support is already necessary to handle dvd and
> >video. It's also useful for images for virtualization. So the failing
> >stat()
> >calls should already be
Bill Huey (hui) wrote:
>
> Patch here:
>
>
http://mmlinux.sourceforge.net/public/patch-2.6.20-rc2-rt2.2.lock_stat.p
atch
>
> bill
This version is much better and ran stablely.
If I'm reading the output correctly, the locks are listed by
their initialization point (function, file and line #
On Tue, 2 Jan 2007 16:13:36 -0800 (PST) Doug Thompson wrote:
> from: Brian Pomerantz <[EMAIL PROTECTED]>
>
> Description:
> The fatal vs. non-fatal mask for the sysbus FERR status is
> incorrect
> according to the E7520 datasheet. This patch corrects the mask to
> correctly
> handle
Take 2... all in one file. I suppose I really did know better than
to create that new header. ;-)
Better?
---
CVE-2006-5753 is for a case where an inode can be marked bad, switching
the ops to bad_inode_ops, which are all connected as:
static int return_EIO(void)
{
return -EIO;
}
On Wed, 3 Jan 2007, Frank van Maarseveen wrote:
On Wed, Jan 03, 2007 at 01:09:41PM -0800, Bryan Henderson wrote:
On any decent filesystem st_ino should uniquely identify an object and
reliably provide hardlink information. The UNIX world has relied upon
this
for decades. A filesystem with
Christoph Anton Mitterer wrote:
Hi.
Perhaps some of you have read my older two threads:
http://marc.theaimsgroup.com/?t=11631244001=1=2 and the even
older http://marc.theaimsgroup.com/?t=11629131451=1=2
The issue was basically the following:
I found a severe bug mainly by fortune
See my comments below.
Regards
///jon
Jarek Poplawski wrote:
..
Maybe I misinterpret this but, IMHO lockdep
complains about locks acquired in different
order: tipc_ref_acquire() gets ref_table_lock
and then tipc_ret_table.entries[index]->lock,
but tipc_deleteport() inversely (with:
Stephen Rothwell wrote:
> Hi Eric,
>
> On Wed, 03 Jan 2007 12:42:47 -0600 Eric Sandeen <[EMAIL PROTECTED]> wrote:
>> So here's the first stab at fixing it. I'm sure there are style points
>> to be hashed out. Putting all the functions as static inlines in a header
>> was just to avoid hundreds
Hi Eric,
On Wed, 03 Jan 2007 12:42:47 -0600 Eric Sandeen <[EMAIL PROTECTED]> wrote:
>
> So here's the first stab at fixing it. I'm sure there are style points
> to be hashed out. Putting all the functions as static inlines in a header
> was just to avoid hundreds of lines of simple function
Hi David,
> Yes, the patch you sent (switching to "method 3" to work around the
> evident bug in the i2c-ixp3xx driver) works on the platform I was
> using too (after unrelated tweaks).
> Here's an updated patch, using "method 3". If it still behaves
> for you, it'd seem ready to merge...
This patch makes the following needlessly global functions static:
- libata-core.c: ata_qc_complete_internal()
- libata-scsi.c: ata_scsi_qc_new()
- libata-scsi.c: ata_dump_status()
- libata-scsi.c: ata_to_sense_error()
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
Every file should include the headers containing the prototypes for
it's global functions.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.20-rc2-mm1/arch/i386/kernel/alternative.c.old 2007-01-03
23:13:18.0 +0100
+++ linux-2.6.20-rc2-mm1/arch/i386/kernel/alternative.c
This atch adds a proper prototype for tosh_smm() to
include/linux/toshiba.h
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/video/neofb.c |1 -
include/linux/toshiba.h |2 ++
2 files changed, 2 insertions(+), 1 deletion(-)
---
This patch adds proper prototypes in a header file for global code under
drivers/isdn/sc/.
Since the GNU C compiler is now able do tell us that caller and callee
disagreed about the number of arguments of setup_buffers(), this patch
also fixes this bug.
Signed-off-by: Adrian Bunk <[EMAIL
On Mon, 01 Jan 2007 07:29:55 -0800
Philip Langdale <[EMAIL PROTECTED]> wrote:
> #define MMC_RSP_R1B
> (MMC_RSP_PRESENT|MMC_RSP_CRC|MMC_RSP_OPCODE|MMC_RSP_BUSY)
> #define MMC_RSP_R2 (MMC_RSP_PRESENT|MMC_RSP_136|MMC_RSP_CRC)
> #define MMC_RSP_R3 (MMC_RSP_PRESENT)
> -#define MMC_RSP_R6
On Wed, Jan 03, 2007 at 05:20:15AM -0800, Stephane Eranian wrote:
> Adrian,
>
> On Sat, Dec 23, 2006 at 12:40:15PM +0100, Adrian Bunk wrote:
> > >
> > > If you look at the perfmon-new-base patch, you'll see a base.diff patch
> > > which
> > > includes this one. I am slowly getting rid of this
On Wed, 03 Jan 2007 23:30:05 +0100
Guillaume Chazarain <[EMAIL PROTECTED]> wrote:
> Unfortunately, with your patch and not mine, the problem is still
> present: msync()
> does not return the error. Both pieces of code (yours and mine) are
> called for the
> same mapping though, albeit yours
On 1/3/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
On Wed, Jan 03, 2007 at 10:14:43PM +0100, Pelle Svensson wrote:
> Hi Sam,
>
> You misunderstand me I think, I already using a separate output directory.
> What I like to do is a separate 'source tree' with only valid files
> for my
Jens Axboe wrote on Wednesday, January 03, 2007 2:30 PM
> > We are having some trouble with the patch set that some of our fiber channel
> > host controller doesn't initialize properly anymore and thus lost whole
> > bunch of disks (somewhere around 200 disks out of 900) at boot time.
> >
Hi!
> >Sure it is. Numerous popular POSIX filesystems do that. There is a lot of
> >inode number space in 64 bit (of course it is a matter of time for it to
> >jump to 128 bit and more)
>
> If the filesystem was designed by someone not from Unix world (FAT, SMB,
> ...), then not. And users
On Wed, 2007-01-03 at 08:03 -0800, Linus Torvalds wrote:
> and assuming the branch is AT ALL predictable (and 95+% of all branches
> are), the branch-over will actually be a LOT better for a CPU.
IF... Counterexample: Add-Compare-Select in a Viterbi Decoder. If the
compare can be predicted, you
Andrew Morton a écrit :
@@ -365,7 +366,8 @@ sync_sb_inodes(struct super_block *sb, s
BUG_ON(inode->i_state & I_FREEING);
__iget(inode);
pages_skipped = wbc->pages_skipped;
- __writeback_single_inode(inode, wbc);
+ ret =
On Wed, 2007-01-03 at 14:23 -0800, Andrew Morton wrote:
> > drivers/scsi/lpfc/lpfc_init.c: In function 'lpfc_pci_probe_one':
> > drivers/scsi/lpfc/lpfc_init.c:1418: warning: implicit declaration of
> > function 'pci_select_bars'
> > drivers/scsi/lpfc/lpfc_init.c:1422: warning: implicit
On Wed, Jan 03 2007, Chen, Kenneth W wrote:
> Jens Axboe wrote on Wednesday, January 03, 2007 12:22 AM
> > > Do you have any benchmarks which got faster with these changes?
> >
> > On the hardware I have immediately available, I see no regressions wrt
> > performance. With instrumentation it's
On Wed, 03 Jan 2007 16:06:48 -0600
James Bottomley <[EMAIL PROTECTED]> wrote:
> On Wed, 2006-11-22 at 10:44 -0500, James Smart wrote:
> > ACK :)
> >
> > (I thought this had already gone in a while ago)
>
> Actually, there seems to be missing infrastructure for this:
>
> CC [M]
On Wed, 3 Jan 2007, Denis Vlasenko wrote:
>
> IOW: yet another slot in instruction opcode matrix and thousands of
> transistors in instruction decoders are wasted because of this
> "clever invention", eh?
Well, in all fairness, it can probably help more on certain
microarchitectures. Intel is
On Thu, 28 Dec 2006 13:53:08 +0530
Suparna Bhattacharya <[EMAIL PROTECTED]> wrote:
> This patchset implements changes to make filesystem AIO read
> and write asynchronous for the non O_DIRECT case.
Unfortunately the unplugging changes in Jen's block tree have trashed these
patches to a degree
On 1/2/07, Eric Piel <[EMAIL PROTECTED]> wrote:
Hi, I've been using e100 for years with no problem, however more by
curiosity than necessity I'd like to know how will be handled the
devices which are (supposedly) supported by eepro100 and not by e100?
According to "modinfo eepro100" and
On Tue, Jan 02, 2007 at 07:09:30PM -0200, Glauber de Oliveira Costa wrote:
> Unlike x86, x86_64 already passes arguments in registers.
>...
Nitpick:
In 2.6.20-rc: s/x86/UML on x86/
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There
On Wed, 3 Jan 2007, Thomas Sailer wrote:
>
> IF... Counterexample: Add-Compare-Select in a Viterbi Decoder.
Yes. [De]compression stuff tends to be (a) totally unpredictable and (b) a
situation where people care about performance. It's fairly rare in many
other situations.
That said, any
> Is there a list of cards this adds support for? I'm waiting on support
> for the X1600
This is not supported, neither by radeonfb (patches or not) nor by
X.org. X1xxx cards have a new display engine and ATI refuses to provide
any specs for it.
Note: I wonder how much of that is related to
On Wed, 2006-11-22 at 10:44 -0500, James Smart wrote:
> ACK :)
>
> (I thought this had already gone in a while ago)
Actually, there seems to be missing infrastructure for this:
CC [M] drivers/scsi/lpfc/lpfc_init.o
drivers/scsi/lpfc/lpfc_init.c: In function 'lpfc_pci_probe_one':
1 - 100 of 556 matches
Mail list logo
