On Fri, 2005-08-05 at 02:11 -0700, [EMAIL PROTECTED] wrote:
> +//
> +#if defined __KERNEL__
this looks wrong; __KERNEL__ is always set
> +#include
> +#if defined( CONFIG_MODVERSIONS ) && ! defined( MODVERSIONS )
> +#define MODVERSIONS
> +#endif
> + /*
On Fri, 2005-08-05 at 11:37 +0200, Roman Zippel wrote:
> Hi,
>
> On Thu, 4 Aug 2005, Andrew Morton wrote:
>
> > > +static inline void *kzalloc(size_t size, unsigned int __nocast flags)
> > > +{
> > > + return kcalloc(1, size, flags);
> > > +}
> > > +
> >
> > That'll generate just as much code
>> Note that this HPA is a good place to store a bootloader too, in fact
>> I like to think of it as the big floppy drive of the PC which no more
>> have any floppy drive: create a FAT filesystem of 64 Mbytes there and
>> copy all the floppy you used to have there. Your bootloader, if it
>> is
Hi,
I've been trying to upgrade kernel to 2.6.13-rc5. The server boots
normally w/o errors, but after while (from 5 minutes up to 2 hours) the
Kernel hangs (no keyboard input possible). As I am a newbie I cannot
figure out who will be concerned with this error.
Here ist the ksymoops output
On Iau, 2005-08-04 at 13:25 -0700, Andrew Morton wrote:
> OK, that's the driver which Alan played with. I don't expect we'll be able
> to get all this fixed up for 2.6.13.
>
> Please check 2.6.13-rc6 when it's out - this might fix the IRQ problem. If
> any bugs remain, please raise entries for
On Fri, 2005-08-05 at 11:37 +0200, Roman Zippel wrote:
> BTW we already have 420 "kcalloc(1, ...)" user and 41 without the 1
> argument, most of them are in sound, which introduced it in first place.
> Can we please deprecate that function before it spreads any further?
Arjan van de Ven
On Thu, Aug 04, 2005 at 10:32:14AM -0700, Roland Dreier wrote:
> I would like to get people's reactions to moving the InfiniBand .h
> files from their current location in drivers/infiniband/include/ to
> include/linux/rdma/. If we agree that this is a good idea then I'll
> push this change as
On Fri, Aug 05 2005, Arjan van de Ven wrote:
> > +
> > + while (1) {
> > + int64_t span4G, length0;
> > + PSG64ENTRY pdma_sg = (PSG64ENTRY) psge;
> > +
> > + span4G =
> >
Hi,
On Fri, 5 Aug 2005, Arjan van de Ven wrote:
> kcalloc does have value, in that it's a nice api to avoid multiplication
> overflows. Just for "1" it's indeed not the most useful API.
This would imply a similiar kmalloc() would be useful as well.
Second, how relevant is it for the kernel? Is
On Fri, 5 August 2005 17:44:52 +0800, David Teigland wrote:
>
> linux/lib/crc32table.h : crc32table_le[] is the same as our crc_32_tab[].
> This looks like a standard that's not going to change, as you've said, so
> including crc32table.h and getting rid of our own table would work fine.
>
> Do
20" LCD TV MONITOR
SLEEK DESIGN
SLEEKER PRICE US$299
A mix of performance and style.
For those who demand only the best.
For those who desire high style combined with high technology.
The sleek ultra-thin metallic-on-black design complements any décor, without
sacrificing
On Fri, 2005-08-05 at 12:07 +0200, Roman Zippel wrote:
> Hi,
>
> On Fri, 5 Aug 2005, Arjan van de Ven wrote:
>
> > kcalloc does have value, in that it's a nice api to avoid multiplication
> > overflows. Just for "1" it's indeed not the most useful API.
>
> This would imply a similiar kmalloc()
On Fri, 5 Aug 2005, Arjan van de Ven wrote:
> kcalloc does have value, in that it's a nice api to avoid multiplication
> overflows. Just for "1" it's indeed not the most useful API.
Roman Zippel writes:
This would imply a similiar kmalloc() would be useful as well.
Second, how relevant is it
> If I want to upgrade my IDE Hard drive by my self, how can I
> restore that kind of data on other diferent PC?
So the content of the HPA should be limited to program which are
special: a boot loader is position dependant and you do not want
to copy it blindly to another hard disk with maybe
Andrew Morton wrote:
>
> Status of subsystem trees:
>
> 3190002git-acpi.patch
> 68299 git-alsa.patch
What are these numbers?
David Vrabel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Fri, Aug 05, 2005 at 12:07:50PM +0200, J?rn Engel wrote:
> On Fri, 5 August 2005 17:44:52 +0800, David Teigland wrote:
> > Do we go a step beyond this and use say the crc32() function from
> > linux/crc32.h? Is this _function_ as standard and unchanging as the table
> > of crcs? In my tests
Cal Peake wrote:
> On Thu, 4 Aug 2005, Andrew Morton wrote:
>
>
>>Michal Schmidt <[EMAIL PROTECTED]> wrote:
>>
>>>Does resuming from swsuspend work for anyone with amd64-agp loaded?
>>
>>It would seem not ;)
>
>
> Must have missed the OP. Yes I can resume fine from swsusp with amd64-agp.
>
>
Hi,
On Fri, 5 Aug 2005, Arjan van de Ven wrote:
> > This would imply a similiar kmalloc() would be useful as well.
> > Second, how relevant is it for the kernel?
>
> we've had a non-negliable amount of security holes because of this
So why don't we have a similiar kmalloc()?
> > Is that
2.6.13-rc5 seemed to kill a scsi disk (sdb) for me, where 2.6.13-rc4-mm1
have no problems with the same disk.
Machine: opteron running a x86-64 kernel, with built-in SATA as well as
a symbios scsi controller. Two videocards running independent xservers.
The sdb disk is on the symbios controller.
David Vrabel <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton wrote:
> >
> > Status of subsystem trees:
> >
> > 3190002git-acpi.patch
> > 68299 git-alsa.patch
>
> What are these numbers?
>
File size in bytes.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Fri, 2005-08-05 at 12:32 +0200, Roman Zippel wrote:
> Hi,
>
> On Fri, 5 Aug 2005, Arjan van de Ven wrote:
>
> > > This would imply a similiar kmalloc() would be useful as well.
> > > Second, how relevant is it for the kernel?
> >
> > we've had a non-negliable amount of security holes
Hi Andrew,
> But it's not possible to say that the system has really leaked pages
>unless you first put a lot of memory reclaim pressure on the machine
>to try to reclaim those oddball pages.
I tried putting a memory pressure on the machine, then unused pages on
the page LRU could be
On Thu, 4 Aug 2005 23:07:33 -0500
Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
> It requests BIOS to hand off control of USB which disables USB legacy
> emulation
> and all troubles associated with it. We could start with -mm...
This also fixes an issue I encountered while doing power
Hello David,
By the way, looking at the comments to the last version of
the pselect()/ppoll()patch, I see that the treatment of
the timeout argument is made dependent on the personality.
http://marc.theaimsgroup.com/?l=linux-kernel=111883591220436=2
I'm not sure that this is a good idea; my
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> I think Ingo was planning on coming up with some infrastructure which
> would allow us to debug this further.
yeah. I've done this today and have split it out of the -RT tree, see
the patch below. After some exposure in -mm i'd like this feature to
Hi,
On Fri, 5 Aug 2005, Arjan van de Ven wrote:
> > > we've had a non-negliable amount of security holes because of this
> >
> > So why don't we have a similiar kmalloc()?
>
> nope kmalloc is not an array allocator
>
> > > it makes it easy and safe. Of course you can and should check it in
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> Ingo,
>
> This was my final version of the softlockup patch. Do you have any
> comments on it? I wasn't sure if you were waiting for any more debate
> on this patch or not.
ok, looks good - i've applied it and released the -52-14 PREEMPT_RT
At KS I asked after a gcapatch command for git..
I've got two trees drm-2.6 and linux-2.6, linux-2.6 is latest Linus, so of
course a tree diff gives me all the new patches in linux-2.6 that aren't
in drm-2.6 which isn't what I want.. I want gcapatch
I'm sure someone has one and I don't
Richard Purdie wrote:
> This fixes what looks like a bit/byte counting error in the MMC/SD code
> which was causing data corruption (in the -mm tree).
>
> Signed-off-by: Richard Purdie <[EMAIL PROTECTED]>
Ooops... Must have been late in the evening. Sorry about that blunder.
Rgds
Pierre
-
To
On Fri, 2005-08-05 at 12:56 +0200, Roman Zippel wrote:
> Hi,
>
> On Fri, 5 Aug 2005, Arjan van de Ven wrote:
>
> > > > we've had a non-negliable amount of security holes because of this
> > >
> > > So why don't we have a similiar kmalloc()?
> >
> > nope kmalloc is not an array allocator
> >
>
On Friday 05 August 2005 12:48, Ingo Molnar wrote:
> * Andrew Morton <[EMAIL PROTECTED]> wrote:
> > I think Ingo was planning on coming up with some infrastructure which
> > would allow us to debug this further.
>
> yeah. I've done this today and have split it out of the -RT tree, see
> the patch
John Bäckstrand <[EMAIL PROTECTED]> writes:
> I've been trying to hunt down a hard lockup issue with some hardware
> of mine, but I've possibly hit a kernel bug instead. When using
> netconsole on my e1000, if I unplug the cable and then re-plug it, the
> machine locks up hard. It manages to
> From: David Woodhouse <[EMAIL PROTECTED]>
> Subject: Re: Add pselect, ppoll system calls.
> Date: Wed, 15 Jun 2005 12:36:54 +0100
>
> On Mon, 2005-06-13 at 08:38 -0700, Ulrich Drepper wrote:
> > > Eep -- I hadn't noticed that difference. Will update patch
> > accordingly.
> >
> > And change
Hello Andrew,
Andrew Morton wrote:
Michael, I'm assuming that a) this problem remains in those -mm kernels
which include git-acpi.patch and that b) the problems are not present in
2.6.13-rc5 or 2.6.13-rc6, yes?
a.) I don't have any problems in 2.6.13-rc5-git[1-3] and 2.6.13-rc4-mm1
they
On Fri, Aug 05, 2005 at 02:07:29AM -0700, Andrew Morton wrote:
>...
> Open bugs:
>
> This is based on my reading of what's real and of what's worth
> attending to. Quite a few things get culled up-front.
>
> There are several emailed bug reports which are probably live bugs but
> they
Hi.
I finally found some time to finish this off. I don't really like the
end result - the macros looked clearer to me - but here goes. If it
looks okay, I'll seek sign offs from each of the affected driver
maintainers and from Ingo. Anyone else?
Regards,
Nigel
drivers/acpi/osl.c |
On Mon, Aug 01, 2005 at 05:06:33AM -0400, Sonny Rao wrote:
> Hi,
>
> I have a system based on the Nforce2 chipset which uses the amd7xx
> driver for it's IDE support, and I noticed that one of the drives was
> performing very slowly. I looked into it a bit more and it seems the
> drive was
Richard Purdie wrote:
On Fri, 2005-08-05 at 00:18 -0700, [EMAIL PROTECTED] wrote:
The patch titled
platform-device driver for MQ11xx graphics chip
has been added to the -mm tree. Its filename is
platform-device-driver-for-mq11xx-graphics-chip.patch
On Wed, Aug 03, 2005 at 06:05:28AM +, Con Kolivas wrote:
> This is the dynamic ticks patch for i386 as written by Tony Lindgen
> <[EMAIL PROTECTED]> and Tuukka Tikkanen <[EMAIL PROTECTED]>.
> Patch for 2.6.13-rc5
>
> There were a couple of things that I wanted to change so here is an
Hi,
> --
> Jens Axboe
>
Thanks for your corrections. Here we have a new version.
Daniel Petrini
--
10LE - Linux
INdT - Manaus - Brazil
diff -uprN linux-2.6.12-orig/kernel/Makefile linux-dyn-tick/kernel/Makefile
--- linux-2.6.12-orig/kernel/Makefile 2005-08-03 23:50:26.0 -0400
+++
Andi Kleen wrote:
The patch was for 2.6.12, did a quick untested port to 2.6.13rc5.
-Andi
Only try a limited number to send packets in netpoll
Thanks, worked nicely!
---
John Bäckstrand
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Hello.
When sunrpc is as module, sysctl adds to proc fs proc/sys/sunrpc, adds 1
to number of proc/sys link (see later), but when it's ls-ed, there is
still old count.
I.e.
my proc/sys before modprobe-ing sunrpc:
# ls -la /proc/sys
celkem 0
dr-xr-xr-x9 root root 0 srp 5 12:43 .
dr-xr-xr-x
when linux kernel receives a packet from the netcard and the forwards it .
the process can be viewed as a kernel process ?
and if this process can be interrupted ?
thanks a lot!!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
On Fri, 5 Aug 2005 22:37, Srivatsa Vaddagiri wrote:
> On Wed, Aug 03, 2005 at 06:05:28AM +, Con Kolivas wrote:
> > This is the dynamic ticks patch for i386 as written by Tony Lindgen
> > <[EMAIL PROTECTED]> and Tuukka Tikkanen <[EMAIL PROTECTED]>.
> > Patch for 2.6.13-rc5
> >
> > There were a
Hello,
Could you please explain me, why we need to wake up somebody right
before freeing an inode? It seems for me, if somebody really wait on
this inode, then they have a good chance to access already freed memory.
Thank you,
Vasily Averin
diff --git a/fs/inode.c b/fs/inode.c
---
On 1/1/02, Pavel Machek <[EMAIL PROTECTED]> wrote:
> Hi!
>
> > > > New, simplified version of the sysfs whitespace strip patch...
> > >
> > > Could you tell me why you don't just fail the operation if malformed
> > > input is supplied?
> >
> > Leading/trailing white space should be allowed. For
On Fri, Aug 05, 2005 at 12:18:03AM -0700, [EMAIL PROTECTED] wrote:
> From: Jamey Hicks <[EMAIL PROTECTED]>
>
> This patch adds platform_device driver for MQ11xx system-on-chip graphics
> chip. This chip is used in several non-PCI ARM and MIPS platforms such as
> the iPAQ H5550. Two subsequent
> Could you please explain me, why we need to wake up somebody right
> before freeing an inode? It seems for me, if somebody really wait on
> this inode, then they have a good chance to access already freed memory.
find_inode() needs to be woken up (__wait_on_freeing_inode) when an
inode being
On 8/2/05, Athul Acharya <[EMAIL PROTECTED]> wrote:
> That is, I want to know whether the current cpu I (kernel code) am
> executing on is hyperthreaded, and if so, which logical cpu represents
> the other thread on chip.
Trying again, as it seems like a simple thing that really should exist
--
Hello Linus,
can you apply patch below?
Since beginning of July my Opteron box was randomly crashing and being rebooted
by hardware watchdog. Today it finally did it in front of me, and this patch
will hopefully fix it.
Problem is that at the end of June (28th, commit
Hi,
Here we have a new version that includes Jens Axboe's corrections and
Con Kolivas tweaks.
Thanks,
Daniel
--
10LE - Linux
INdT - Manaus - Brazil
diff -uprN linux-2.6.12-orig/kernel/Makefile linux-dyn-tick/kernel/Makefile
--- linux-2.6.12-orig/kernel/Makefile 2005-08-05 09:33:24.0
> When sunrpc is as module, sysctl adds to proc fs proc/sys/sunrpc, adds 1
> to number of proc/sys link (see later), but when it's ls-ed, there is
> still old count.
Does this patch solve it?
Index: linux/fs/proc/generic.c
===
---
On Fri, 2005-08-05 at 13:45 +0200, Andi Kleen wrote:
> John Bäckstrand <[EMAIL PROTECTED]> writes:
>
> > I've been trying to hunt down a hard lockup issue with some hardware
> > of mine, but I've possibly hit a kernel bug instead. When using
> > netconsole on my e1000, if I unplug the cable and
> This is fixing the symptom and is not the cure. Unfortunately I don't
> have a e1000 card so I can't try a fix. But I did have a e100 card that
> would lock up the same way. The problem was that netpoll_poll calls the
> cards netpoll routine (in e1000_main.c e1000_netpoll). In the e100
>
On Fri, 5 Aug 2005, Petr Vandrovec wrote:
> Hello Linus,
> can you apply patch below?
>
> Since beginning of July my Opteron box was randomly crashing and being
> rebooted
> by hardware watchdog. Today it finally did it in front of me, and this patch
> will hopefully fix it.
>
> Problem is
On Thu, Aug 04, 2005 at 09:20:22PM -0600, George Van Tuyl wrote:
>
> To: linux-kernel@vger.kernel.org
>
>
>
> [1.] One line summary of the problem:
>
> make modules failed Segfault (program cpp0)
>
> [2.] Full description of the problem/report:
>
> gcc: Internal error: Segmentation fault
On Fri, Aug 05, 2005 at 08:23:18AM +0200, Jan Engelhardt wrote:
>
> >> Gnu C 2.96
> >
> > Seriously, it seems like your machine is flaky.
> > And even if it were a kernel source problem,
> > gcc should never have an internal error.
> > But gcc-2.96 is so old that it's not
On Friday 05 August 2005 12:48, Ingo Molnar wrote:
> * Andrew Morton <[EMAIL PROTECTED]> wrote:
> > I think Ingo was planning on coming up with some infrastructure which
> > would allow us to debug this further.
>
> yeah. I've done this today and have split it out of the -RT tree, see
> the patch
On Fri, 5 Aug 2005, antoine wrote:
After using it for a good few hours, I launched a shell script in a terminal
and got the traces below.
I hope this helps (if not, please let me know how to make it helpful or I'll
just stop testing -rc kernels and save myself some time)
[ 4788.218951]
linux-os (Dick Johnson) wrote:
On Fri, 5 Aug 2005, Petr Vandrovec wrote:
Hello Linus,
can you apply patch below?
Since beginning of July my Opteron box was randomly crashing and being rebooted
by hardware watchdog. Today it finally did it in front of me, and this patch
will hopefully fix
Resending dell_rbu driver after making a few more improvements and also
using the new request_firmware_nowait kernel API sent in the firmware_class.c
patch.
This patch has been tested on i386 and x86-64 systems along with the
firmware_class.c patch and it works fine.
Signed-off-by: Abhay
On Thu, Aug 04 2005, Tom Zanussi wrote:
> At the kernel summit, there was some discussion of relayfs and the
> consensus was that it didn't make sense for relayfs to not implement
> read(). So here's a read implementation...
It needs a few fixes to actually compile without errors. This works for
Oh!!Please ignore the earlier firmware_calss.c patch sent a worng one by
mistake :-(
This is the correct patch :-).
Reseending the patch for firmware_class.c submitted earlier ,the patch
upgrades the request_firmware_nowait function to not start the hotplug
action on a firmware update.
This
Reseending the patch for firmware_class.c submitted earlier ,the patch
upgrades the request_firmware_nowait function to not start the hotplug
action on a firmware update.
This patch is tested along with dell_rbu driver on i386 and x86-64 systems.
Andrew, could you please add this patch to the
This patchkit converts kcalloc(1, ...) to the new kzalloc(). Andrew, please
let me know if you don't want to pick up some of these. I will feed them to
subsystem maintainers once kzalloc() hits Linus' tree.
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
arch/ia64/sn/kernel/io_init.c
This patch converts kcalloc(1, ...) calls to use the new kzalloc() function.
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
kernel/io_init.c |2 +-
kernel/tiocx.c |2 +-
pci/tioca_provider.c |8
3 files changed, 6 insertions(+), 6 deletions(-)
Index:
On Fri, 5 Aug 2005, Andi Kleen wrote:
> > a clean way. It cannot even deliver the functionality it was designed to
> > deliver (see BIND).
>
> That seems like a unfair description to me. While things are not
> perfect they are definitely not as bad as you're trying to paint them.
Sorry this
This patch converts kcalloc(1, ...) calls to use the new kzalloc() function.
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
block/aoe/aoedev.c |2 +-
char/mbcs.c |2 +-
i2c/chips/isp1301_omap.c |2 +-
infiniband/core/sysfs.c |2 +-
scsi/sata_qstor.c
Michael Kerrisk wrote:
> Please consider making Linux pselect() conform to POSIX on this
> point.
There is no question the implementation will conform. But this not
dependent on changing the syscall interface. We deliberately decided to
not require the kernel interface to be different from
On Fri, 5 Aug 2005, Petr Vandrovec wrote:
> linux-os (Dick Johnson) wrote:
>> On Fri, 5 Aug 2005, Petr Vandrovec wrote:
>>
>>
>>> Hello Linus,
>>> can you apply patch below?
>>>
>>> Since beginning of July my Opteron box was randomly crashing and being
>>> rebooted
>>> by hardware watchdog.
Jens Axboe writes:
> On Thu, Aug 04 2005, Tom Zanussi wrote:
> > At the kernel summit, there was some discussion of relayfs and the
> > consensus was that it didn't make sense for relayfs to not implement
> > read(). So here's a read implementation...
>
> It needs a few fixes to actually
On Fri, 2005-08-05 at 15:55 +0200, Andi Kleen wrote:
> > This is fixing the symptom and is not the cure. Unfortunately I don't
> > have a e1000 card so I can't try a fix. But I did have a e100 card that
> > would lock up the same way. The problem was that netpoll_poll calls the
> > cards netpoll
On Fri, Aug 05, 2005 at 10:10:13AM -0400, Steven Rostedt wrote:
> On Fri, 2005-08-05 at 15:55 +0200, Andi Kleen wrote:
> > > This is fixing the symptom and is not the cure. Unfortunately I don't
> > > have a e1000 card so I can't try a fix. But I did have a e100 card that
> > > would lock up the
On Fri, 2005-08-05 at 16:14 +0200, Andi Kleen wrote:
> On Fri, Aug 05, 2005 at 10:10:13AM -0400, Steven Rostedt wrote:
> > On Fri, 2005-08-05 at 15:55 +0200, Andi Kleen wrote:
> > > > This is fixing the symptom and is not the cure. Unfortunately I don't
> > > > have a e1000 card so I can't try a
From: Steven Rostedt <[EMAIL PROTECTED]>
Date: Fri, 05 Aug 2005 10:27:06 -0400
> Darn it, since this should really be reported. Yes, the core netpoll
> should bail out, but it is also a problem with the driver and should be
> fixed.
I don't get how you can even remotely claim this to
be a
Looking at the netpoll routines, I noticed that the find_skb could
lockup if the memory is low. This is because the allocations are called
with GFP_ATOMIC (since this is in interrupt context) and if it fails, it
will continue to fail. This is just by observing the code, I didn't have
this
> Date: Sun, 31 Jul 2005 19:02:09 -0700
> From: [EMAIL PROTECTED]
>
> > Date: Sun, 31 Jul 2005 16:02:44 -0700
> > From: Greg KH <[EMAIL PROTECTED]>
> >
> > On Sun, Jul 31, 2005 at 11:25:10AM -0700, [EMAIL PROTECTED] wrote:
> > > I think that "continuing" codepath came from someone at Phoenix,
On Thu, 2005-08-04 at 23:39 -0700, Andrew Morton wrote:
> James, could some of the scsi core rework have caused this?
Well, I don't think so. The error below:
> > sdc: Unit Not Ready, sense:
> > : Current: sense key=0x0
> > ASC=0x0 ASCQ=0x0
> > target0:0:10: FAST-40 WIDE SCSI 80.0 MB/s DT
--James Bottomley <[EMAIL PROTECTED]> wrote (on Friday, August 05, 2005
09:24:52 -0500):
> On Thu, 2005-08-04 at 23:39 -0700, Andrew Morton wrote:
>> James, could some of the scsi core rework have caused this?
>
> Well, I don't think so. The error below:
>
>> > sdc: Unit Not Ready, sense:
* Dominik Karall <[EMAIL PROTECTED]> wrote:
> > yeah. I've done this today and have split it out of the -RT tree, see
> > the patch below. After some exposure in -mm i'd like this feature to go
> > upstream too.
> >
> > the patch is against recent Linus trees, 2.6.13-rc4 or later should all
> >
Bjorn Helgaas wrote:
Maybe the third time's the charm :-) Added a bugfix
(pcibios_penalize_isa_irq()) and a workaround for HP
HPET firmware description since last time. The workaround
accepts stuff that is illegal according to the spec,
so speak up if you think this is a problem. It seems
On Thu, 4 Aug 2005, Richard Purdie wrote:
> I'm at a disadvantage here as the linux mm system is one area I've
> avoided getting too deeply involved with so far. My knowledge is
> therefore limited and I won't know what correct or incorrect behaviour
> would look like.
>
> We know the the
On Fri, 2005-08-05 at 21:02 +0800, lab liscs wrote:
> when linux kernel receives a packet from the netcard and the forwards it .
>
> the process can be viewed as a kernel process ?
>
> and if this process can be interrupted ?
>
> thanks a lot!!
When a packet is received from the kernel, this
* Dominik Karall <[EMAIL PROTECTED]> wrote:
> BUG: mono[10011] exited with nonzero preempt_count 1!
> ---
> | preempt count: 0001 ]
> | 1 level deep critical section nesting:
>
> .. [] _spin_lock+0xe/0x70
>
On 8/5/05, Pekka Enberg <[EMAIL PROTECTED]> wrote:
> This patch converts kcalloc(1, ...) calls to use the new kzalloc() function.
>
Hi,
Have you seen the following in include/sound/core?
...
#define kmalloc(size, flags) snd_hidden_kmalloc(size, flags)
#define kcalloc(n, size, flags)
Below is a patch to implement demand faulting for huge pages. The main
motivation for changing from prefaulting to demand faulting is so that
huge page allocations can follow the NUMA API. Currently, huge pages
are allocated round-robin from all NUMA nodes.
The default behavior in SLES9 for
On Friday 05 August 2005 9:17 am, matthieu castet wrote:
> Bjorn Helgaas wrote:
> > The workaround
> > accepts stuff that is illegal according to the spec,
> > so speak up if you think this is a problem.
> >
> May be print some warnings if the acpi is broken...
Yes, I thought about that, and in
This patch converts kcalloc(1, ...) calls to use the new kzalloc() function.
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
atm/usbatm.c |2 +-
core/hcd.c |2 +-
host/ehci-sched.c |2 +-
host/isp116x-hcd.c |2 +-
host/sl811-hcd.c |2 +-
input/acecad.c
Problem resolved by BIOS and BCM Firmware update.
Martin
-
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/
This patch converts kcalloc(1, ...) calls to use the new kzalloc() function.
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
hotplug/sgi_hotplug.c |2 +-
pci-sysfs.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
Index: 2.6/drivers/pci/hotplug/sgi_hotplug.c
Gerd Knorr wrote:
On Thu, Aug 04, 2005 at 03:02:51PM -0700, Andrew Morton wrote:
Roland McGrath <[EMAIL PROTECTED]> wrote:
That's wrong. It has to be done only by the last thread in the group to go.
Just revert Ingo's change.
OK..
+++ 25-akpm/kernel/exit.c Thu Aug 4 15:01:06 2005
description:
audit return code of create_proc_* function is a entry in janitors
TODO list. Audit this return and printk() when it fails, can spam a lot
system without compiled proc support. So this patch can audit return
code by means of procfs_failure().
Signed-off-by: Christophe Lucas <[EMAIL
description:
audit return code of create_proc_* function is a entry in janitors
TODO list. Audit this return and printk() when it fails, can spam a lot
system without compiled proc support. So this patch can audit return
code by means of procfs_failure().
Signed-off-by: Christophe Lucas <[EMAIL
On Fri, 2005-08-05 at 07:36 -0700, David S. Miller wrote:
> From: Steven Rostedt <[EMAIL PROTECTED]>
> Date: Fri, 05 Aug 2005 10:27:06 -0400
>
> > Darn it, since this should really be reported. Yes, the core netpoll
> > should bail out, but it is also a problem with the driver and should be
> >
On Fri, 5 Aug 2005, Andi Kleen wrote:
> > Address space migration? That is something new in this discussion. So
> > could you explain what you mean by that? I have looked at page migration
> > in a variety of contexts and could not see much difference.
>
> MCE page migration just puts a
On Wed, 3 Aug 2005 [EMAIL PROTECTED] wrote:
> The attached patch implements your idea on top of my previous patchset.
> Following is performance data on a 16-way ppc. dbench and tbench were
> run 50 times, kernbench and reaim 10 times each; results are mean +/-
> 95% confidence half-interval.
On Fri, Aug 05 2005, Tom Zanussi wrote:
> Jens Axboe writes:
> > On Thu, Aug 04 2005, Tom Zanussi wrote:
> > > At the kernel summit, there was some discussion of relayfs and the
> > > consensus was that it didn't make sense for relayfs to not implement
> > > read(). So here's a read
On Fri, Aug 05, 2005 at 10:21:38AM -0500, Adam Litke wrote:
> Below is a patch to implement demand faulting for huge pages. The main
> motivation for changing from prefaulting to demand faulting is so that
> huge page allocations can follow the NUMA API. Currently, huge pages
> are allocated
Hi everybody,
For quite some time now I have got a problem mounting my usb-stick (MP3 FUN256
from DNT) with linux. This stick worked back in the 2.4.x days, though it
needed one of the later versions (I switched to 2.6.x as soon about when it
was released, so I didnt test the newest versions.)
This patch converts kcalloc(1, ...) calls to use the new kzalloc() function.
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
pSeries_reconfig.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Index: 2.6/arch/ppc64/kernel/pSeries_reconfig.c
401 - 500 of 701 matches
Mail list logo
