On Fri, Jan 21, 2005 at 06:27:43PM +1100, Peter Williams wrote:
> Greg KH wrote:
> >On Fri, Jan 21, 2005 at 01:15:28PM +1100, Peter Williams wrote:
> >
> >>Perhaps the logical solution is to implement debugfs in terms of relayfs?
> >
> >
> >What do you mean by this statement?
>
> I mean that if,
> >
> > This one I meant to fix in the kernel fwiw; we can put that loop inside
> > the kernel easily I'm sure
>
> Yes, but it will increase the data size of the timer...
>
eh how?
the way I think it can be done is to just have multiple timers fire
until the total time is up. It's not a
* Con Kolivas <[EMAIL PROTECTED]> wrote:
> In terms of recommendation, the latency of non-preemptible codepaths
> will be fastest in ext3 in 2.6 due to the nature of it constantly
> being examined, addressed and updated. That does not mean it has the
> fastest performance by any stretch of the
On Thu, 2005-01-20 at 16:08 -0800, Greg KH wrote:
> Doh, sorry for missing this one. I've applied your patch to my trees,
> and will show up in the next -mm release.
Actually I think John's problem was that the usb core code has now
_stopped_ doing this byteswapping, and he has a lsusb which is
On Tue, 18 Jan 2005, chas williams - CONTRACTOR wrote:
the system keeps running right? the error is a 'warning' that the
fore200e is driver is sleeping when it should not (probably while holding
interrupts). the schedule() around like 1782 is not a good idea since
the fore200e_send() might not
On Thu, Jan 20 2005, Andrea Arcangeli wrote:
> On Thu, Jan 20, 2005 at 02:15:56PM +0100, Andries Brouwer wrote:
> > On Thu, Jan 20, 2005 at 01:34:06PM +0100, Jens Axboe wrote:
> >
> > > Using current BK on my x86-64 workstation, it went completely nuts today
> > > killing tasks left and right
Hello, i'm translating some Kconfig files to french for the kernelFR
project (http://kernelfr.traduc.org), and while i was reading
drivers/net/hamradio/Kconfig
The kernel is 2.6.10
In section : "Baycom ser12 halfduplex driver for AX.25" 9th section, in
the 3rdline, there is :
"The driver supports
Hello, i'm translating some Kconfig files to french for the kernelFR
project (http://kernelfr.traduc.org), and while i was reading
drivers/net/hamradio/Kconfig
The kernel is 2.6.10
In section : "Baycom ser12 halfduplex driver for AX.25" 9th section, in
the 3rdline, there is :
"The driver supports
Greg KH wrote:
On Fri, Jan 21, 2005 at 01:15:28PM +1100, Peter Williams wrote:
Perhaps the logical solution is to implement debugfs in terms of relayfs?
What do you mean by this statement?
I mean that if, as you say, debugfs is very similar to relayfs only more
restricted (i.e. a debugging
On Fri, Jan 21, 2005 at 08:08:21AM +0100, Andi Kleen wrote:
> So at least for GFP_DMA it seems to be definitely needed.
Indeed. Plus if you add pci32 zone, it'll be needed for it too on
x86-64, like for the normal zone on x86, since ptes will go in highmem
while pci32 allocations will not. So
On Fri, Jan 21, 2005 at 06:04:25PM +1100, Nick Piggin wrote:
> OK this is a fairly lame example... but the current code is more or
> less just lucky that ZONE_DMA doesn't usually fill up with pinned mem
> on machines that need explicit ZONE_DMA allocations.
Yep. For the DMA zone all slab cache
On Thu, Jan 20, 2005 at 11:00:16PM -0800, Andrew Morton wrote:
> Last time we dicsussed this you pointed out that reserving more lowmem from
> highmem-capable allocations may actually *help* things. (Tries to remember
> why) By reducing inode/dentry eviction rates? I asked Martin Bligh if he
>
> I really suggest to push this limit to 4k. My reason is that under UML I
> need to put a lot of stuff in command line and uml crash if I not extend
> this limit. Can we make it depend on arhitecture?
It's dependent on the architecture already. I would like to enable
it on i386/x86-64 because
On Thu, 2005-01-20 at 22:46 -0800, Andrew Morton wrote:
> Nick Piggin <[EMAIL PROTECTED]> wrote:
> > It does turn on lowmem protection by default. We never reached
> > an agreement about doing this though, but Andrea has shown that
> > it fixes trivial OOM cases.
> >
> > I think it should be
Andrew Morton <[EMAIL PROTECTED]> writes:
> Just that it throws away a bunch of potentially usable memory. In three
> years I've seen zero reports of any problems which would have been solved
> by increasing the protection ratio.
We ran into a big problem with this on x86-64. The SUSE installer
On Thu, Jan 20, 2005 at 10:46:45PM -0800, Andrew Morton wrote:
> Thus empirically, it appears that the number of machines which need a
> non-zero protection ratio is exceedingly small. Why change the setting on
> all machines for the benefit of the tiny few? Seems weird. Especially
> when this
Hi Andrew,
Following patch is against 2.6.11-rc1-mm2.
As mentioned by following note from Eric, crashdump code is currently
broken.
>
> The crashdump code is currently slightly broken. I have attempted to
> minimize the breakage so things can quick be made to work again.
We have started
On Thu, 20 Jan 2005, Andi Kleen wrote:
AOL:
- lilo 22.6.1
- CONFIG_EDD=y
- 2.6.10-mm1 and 2.6.11-rc1 did boot
- 2.6.11-rc1-mm1 and 2.6.11-rc1-mm2 didn't boot
- 2.6.11-rc1-mm2 with this ChangeSet reverted boots.
What I gather so far the problem seems to only happen with lilo
and EDID together.
Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
>
> Anyway if you leave it off by default I don't mind, with my new code
> forward ported stright from 2.4 mainline, it's possible for the first
> time to set it from userspace without having to embed knowledge on the
> kernel min_kbytes settings at
On Fri, Jan 21, 2005 at 01:15:28PM +1100, Peter Williams wrote:
>
> Perhaps the logical solution is to implement debugfs in terms of relayfs?
What do you mean by this statement?
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
On Thu, Jan 20, 2005 at 08:38:25PM -0500, Karim Yaghmour wrote:
>
> Greg KH wrote:
> > Hm, how about this idea for cutting about 500 more lines from the code:
> >
> > Why not drop the "fs" part of relayfs and just make the code a set of
> > struct file_operations. That way you could have
On Fri, Jan 21, 2005 at 05:36:14PM +1100, Nick Piggin wrote:
> I think it should be turned on by default. I can't recall what
I think it too, since the number of people that can be bitten by this is
certainly higher than the number of people who knows the VM internals
and for what kind of
Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> On Thu, 2005-01-20 at 22:20 -0800, Andrew Morton wrote:
> > Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
> > >
> > > This is the forward port to 2.6 of the lowmem_reserved algorithm I
> > > invented in 2.4.1*, merged in 2.4.2x already and needed to fix
Hi Nicolas,
> I confirm that 0x7f is full speed.
So at least the polarity bit is correct, and Gigabyte isn't to blame.
> > Once you know if the polarity is correct, you can try different
> > values of PWM between 0x00 and 0x7F and see how exactly your fan
> > reacts to them.
>
> That's where
On Thu, Jan 20, 2005 at 10:26:30PM -0800, Andrew Morton wrote:
> Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
> >
> > This needed highmem fix from Rik is still missing too, so please apply
> > along the other 5 (it's orthogonal so you can apply this one in any
> > order you want).
> >
> > From:
* Andi Kleen ([EMAIL PROTECTED]) wrote:
> On Thu, Jan 20, 2005 at 09:51:03PM -0800, Chris Wright wrote:
> > > If you add it make at least sure it's not EXPORT_SYMBOL()ed.
> >
> > It's certainly not, nor intended to be. Would a comment to that
> > affect alleviate your concern?
>
> Yes please.
On Thu, 2005-01-20 at 22:20 -0800, Andrew Morton wrote:
> Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
> >
> > This is the forward port to 2.6 of the lowmem_reserved algorithm I
> > invented in 2.4.1*, merged in 2.4.2x already and needed to fix workloads
> > like google (especially without swap)
* George Anzinger wrote:
> It seems to me that we need to either do the attached or to rewrite
> the timer front end code to just gather the offset info and defer to
> the timer irq thread to update jiffies and the offset stuff. In
> either case we really can not split the two and we do need
On Thu, Jan 20, 2005 at 10:20:56PM -0800, Andrew Morton wrote:
> Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
> >
> > This is the forward port to 2.6 of the lowmem_reserved algorithm I
> > invented in 2.4.1*, merged in 2.4.2x already and needed to fix workloads
> > like google (especially
On Thursday 20 January 2005 11:35 am, Pete Zaitcev wrote:
> On Wed, 19 Jan 2005 09:08:34 -0800, David Brownell <[EMAIL PROTECTED]> wrote:
> I do not like to refer to a dev because I do not quite understand where
> the necessary usb_dev_get/_put are now. But if you guarantee that the
> urb->dev is
Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
>
> This needed highmem fix from Rik is still missing too, so please apply
> along the other 5 (it's orthogonal so you can apply this one in any
> order you want).
>
> From: Rik van Riel <[EMAIL PROTECTED]>
> Subject: [PATCH][1/2] adjust dirty
Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
>
> This is the forward port to 2.6 of the lowmem_reserved algorithm I
> invented in 2.4.1*, merged in 2.4.2x already and needed to fix workloads
> like google (especially without swap) on x86 with >1G of ram, but it's
> needed in all sort of
OK, I finally come around to answering this ...
Roman Zippel wrote:
> Sorry, you missunderstood me. At the moment I'm only secondarily
> interested in the API details, primarily I want to work out the details of
> what exactly relayfs/ltt are supposed to do. One main question here I
> can't
Hi.
Every now and then (maybe twice a week) my server panics. This
is a dual Xeon system with 5Gb memory. I did my best to get the
full oops from the screen and doublechecked. Sorry, but I don't
understand anything from the ksymoops output.
Any help will be appreciated.
ksymoops 2.4.5 on i686
On Thu, Jan 20, 2005 at 09:51:03PM -0800, Chris Wright wrote:
> > If you add it make at least sure it's not EXPORT_SYMBOL()ed.
>
> It's certainly not, nor intended to be. Would a comment to that
> affect alleviate your concern?
Yes please.
-Andi
-
To unsubscribe from this list: send the line
On Thu, Jan 20, 2005 at 08:07:11PM -0800, Andrew Morton wrote:
> Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> > Next suspects would be:
> >
> > +cleanup-vc-array-access.patch
> > +remove-console_macrosh.patch
> > +merge-vt_struct-into-vc_data.patch
> >
> >
>
> Make that:
>
>
This needed highmem fix from Rik is still missing too, so please apply
along the other 5 (it's orthogonal so you can apply this one in any
order you want).
From: Rik van Riel <[EMAIL PROTECTED]>
Subject: [PATCH][1/2] adjust dirty threshold for lowmem-only mappings
Simply running "dd if=/dev/zero
* Andi Kleen ([EMAIL PROTECTED]) wrote:
> I'm not sure really adding vfs_ioctl is a good idea politically.
> I predict we'll see drivers starting to use it, which will cause quite
> broken design.
Yes, that'd be quite broken. I didn't have the same expectation.
> If you add it make at least
From: Andrea Arcangeli <[EMAIL PROTECTED]>
Subject: Convert the unsafe signed (16bit) used_math to a safe and optimal
PF_USED_MATH
On Sat, Dec 25, 2004 at 04:24:30AM +0100, Andrea Arcangeli wrote:
> Here it is the first part. This makes memdie a TIF_MEMDIE. It's
And here is the final
From: Andrea Arcangeli <[EMAIL PROTECTED]>
Subject: convert memdie to an atomic thread bitflag
On Sat, Dec 25, 2004 at 03:27:21AM +0100, Andrea Arcangeli wrote:
> So my current plan is to make used_math a PF_USED_MATH, and memdie a
> TIF_MEMDIE. And of course oomtaskadj an int (that one requires
From: Andrea Arcangeli <[EMAIL PROTECTED]>
Subject: fix several oom killer bugs, most important avoid spurious oom kills
badness algorithm tweaked by Thomas Gleixner to deal with fork bombs
This is the core of the oom-killer fixes I developed partly taking the
idea from Thomas's patches of
From: Andrea Arcangeli <[EMAIL PROTECTED]>
Subject: keep balance between different classzones
This is the forward port to 2.6 of the lowmem_reserved algorithm I
invented in 2.4.1*, merged in 2.4.2x already and needed to fix workloads
like google (especially without swap) on x86 with >1G of ram,
I'm sending 5 patches incremental with each other updated to the latest
bk snapshot I could find on kernel.org [kernel cvs is still unusable for
me, is it my mistake?]
From: [EMAIL PROTECTED]
Subject: protect-pids
This is protect-pids, a patch to allow the admin to tune the oom killer.
The tweak
--- [EMAIL PROTECTED] wrote:
> Possibility 1:
> Load them from an initrd image while booting. If
> you're already
> using an initrd, and this is "early enough", you
> just need to put the
> module into the initrd, and make sure the /linuxrc
> or whatever script
> does an insmod for it. This has
On Thu, Jan 20, 2005 at 05:26:56PM -0800, Chris Wright wrote:
> * Michael S. Tsirkin ([EMAIL PROTECTED]) wrote:
> > Security hook seems to be missing before compat_ioctl in mm2.
> > And, it would be nice to avoid calling it twice on some paths.
> >
> > Chris Wright's patch addressed this in the
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> Next suspects would be:
>
> +cleanup-vc-array-access.patch
> +remove-console_macrosh.patch
> +merge-vt_struct-into-vc_data.patch
>
>
Make that:
+cleanup-vc-array-access.patch
+remove-console_macrosh.patch
+merge-vt_struct-into-vc_data.patch
Matt Mackall <[EMAIL PROTECTED]> wrote:
>
> Here are the symptoms:
>
> mm2: corruption of Tux logo at boot, corruption of display at
> powerdown, lockup and LCD blooming on next warm boot when radeonfb
> starts. Ben suggested I try some radeonfb options, but none seemed to
> have any effect.
On Thu, Jan 20, 2005 at 04:01:23PM -0800, Andrew Morton wrote:
> Matt Mackall <[EMAIL PROTECTED]> wrote:
> >
> > > Which radeon driver? CONFIG_FB_RADEON_OLD or CONFIG_FB_RADEON?
> >
> > FB_RADEON.
>
> Ah, OK. Likely culprits are
>
> radeonfb-massive-update-of-pm-code.patch
>
--- linux-2.6.10.orig/mm/page_alloc.c 2004-12-25 05:33:51.0 +0800
+++ linux-2.6.10/mm/page_alloc.c2005-01-21 11:46:58.0 +0800
@@ -788,7 +788,22 @@
fastcall void __free_pages(struct page *page, unsigned int order)
{
- if (!PageReserved(page) &&
--- linux-2.6.10.orig/mm/page_alloc.c 2004-12-25 05:33:51.0 +0800
+++ linux-2.6.10/mm/page_alloc.c2005-01-21 11:43:44.0 +0800
@@ -788,7 +788,22 @@
fastcall void __free_pages(struct page *page, unsigned int order)
{
- if (!PageReserved(page) &&
On Thu, 20 Jan 2005 14:31:34 +, Russell King
<[EMAIL PROTECTED]> wrote:
> On Thu, Jan 20, 2005 at 09:34:17PM +0800, zhan rongkai wrote:
> > [PATCH]: fix the bug of __free_pages() of mm/page_alloc.c
> > =
> >
> > The buddy allocator's
Lennert Van Alboom <[EMAIL PROTECTED]> wrote:
>
> Possible memleak in 2.6.11-rc1?
Please wait for it to happen again and then send the contents of
/proc/meminfo and /proc/slabinfo.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
On Thu, Jan 20, 2005 at 05:46:22PM +0100, Marco Cipullo wrote:
> - if (agp_bridge->dev->device == PCI_DEVICE_ID_INTEL_82915G_HB)
> + if (agp_bridge->dev->device == PCI_DEVICE_ID_INTEL_82915G_HB ||
> + agp_bridge->dev->device == PCI_DEVICE_ID_INTEL_82915G_HB)
> gtt_entries = MB(48) -
Zach Brown wrote:
> Only briefly. They've always seemed more involved than the sort of
> thing I was after. I'll try and sit down and investigate in more detail.
There's definitely an opportunity for interfacing here. If nothing else,
this clearly shows the interest for the kind of things both
Hi Peter,
> I'm hoping that the CKRM folks will send me a patch to add their
> scheduler to plugsched :-)
They are planning to release a patch against 2.6.10. But their patch wont
stand alone against 2.6.10 and so it might be difficult for you to integrate
their code into a scheduler for
Linas Vepstas writes:
> > 2. I don't see why the device nodes for the PCI subtree being reset
> >would go away, and thus I don't see the need for your eeh_cfg_tree
> >struct.
>
> Its not the reset, its the hot-plug remove. The hot plug code assumes
> that you are going to physically
Marc E. Fiuczynski wrote:
Peter, thank you for maintaining Con's plugsched code in light of Linus' and
Ingo's prior objections to this idea. On the one hand, I partially agree
with Linus's prior views that when there is only one scheduler that the
rest of the world + dog will focus on making it
On Thu, Jan 20, 2005 at 10:46:37PM +0100, Rafael J. Wysocki wrote:
> On Thursday, 20 of January 2005 21:59, Pavel Machek wrote:
>
> Sure, but I think it's there for a reason.
>
> > Anyway, this is likely to clash with hugang's work; I'd prefer this not to
> > be applied.
>
> I am aware of
On Thu, Jan 20, 2005 at 03:43:58PM +0100, Pavel Machek wrote:
> It would be nice if you could make it "value-per-file". That way,
> it could become writable in future. If "max nice level" ever becomes rlimit,
> this would be very usefull.
Agreed, though write support present difficulties.
My
Karim Yaghmour wrote:
Greg KH wrote:
Hm, how about this idea for cutting about 500 more lines from the code:
Why not drop the "fs" part of relayfs and just make the code a set of
struct file_operations. That way you could have "relayfs-like" files in
any ram based file system that is being used.
Greg KH wrote:
> Hm, how about this idea for cutting about 500 more lines from the code:
>
> Why not drop the "fs" part of relayfs and just make the code a set of
> struct file_operations. That way you could have "relayfs-like" files in
> any ram based file system that is being used. Then, a
* Michael S. Tsirkin ([EMAIL PROTECTED]) wrote:
> Security hook seems to be missing before compat_ioctl in mm2.
> And, it would be nice to avoid calling it twice on some paths.
>
> Chris Wright's patch addressed this in the most elegant way I think,
> by adding vfs_ioctl.
The patch below is
> I'm totally not in a position to evaluate the completeness, desirability,
> interest-level, etc of this patch, I'm afraid. This is an opportunity for
> other stakeholders to weigh in..
Thanks Andrew!
First, Job can work as a standalone kernel module.
The current implementation provides the
On Friday 21 January 2005 00:05, Andreas Dilger wrote:
> [...]
> But as your patch stands it doesn't ever check if i_extra_isize is valid
> for the root or lost+found inode. It just always sets i_extra_isize = 0
(that's the in-memory i_extra_isize)
> and never uses it. Given that the
Hi all,
[Please cc me on any replies because I'm not subscribed to linux-aio or
linux-kernel.]
I was running a random system call generator against mainline the other
day and got this bug report about AIO in dmesg:
[ cut here ]
kernel BUG at fs/aio.c:1249!
invalid
This patch had fixed LTT build errors on MIPS.
Yoichi
Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]>
diff -urN -X dontdiff a-orig/arch/mips/kernel/irq.c a/arch/mips/kernel/irq.c
--- a-orig/arch/mips/kernel/irq.c Fri Jan 21 00:15:19 2005
+++ a/arch/mips/kernel/irq.cFri Jan 21 08:17:31
Peter Chubb <[EMAIL PROTECTED]> writes:
>> "Jack" == Jack O'Quin <[EMAIL PROTECTED]> writes:
>
> Jack> Looks like we need to do another study to determine which
> Jack> filesystem works best for multi-track audio recording and
> Jack> playback. XFS looks promising, but only if they get the
* jnf ([EMAIL PROTECTED]) wrote:
> I will read the paper before commenting on it further, however I cannot
> see what dangers it would really provide that a setuid program doesnt
> already have- other than the ability to give another non-root process root
> like abilities. However, the more I
> > > > I'm seeing radeonfb on my ThinkPad T30 go weird on reboot (lots of
> > > > horizontal lines) and require powercycling to fix. Worked fine with
> > > > 2.6.10.
> > >
> > > Which radeon driver? CONFIG_FB_RADEON_OLD or CONFIG_FB_RADEON?
> >
> > FB_RADEON.
> >
> > > (cc Ben, who is the
Hi Takashi,
The same applies for IBM T40/T41/R50p I have tested so far.
I had to disable "Headphone Jack Sense" and "Line Jack Sense" too.
So, what's the deal with these ?
What are they supposed to do ?
Should we report this as bug on alsa lists ?
Thanks,
Paul
On Thu, 20 Jan 2005 16:55:55
Hi,
On Friday, 21 of January 2005 00:06, Pavel Machek wrote:
> Hi!
>
> > > > The readability of code is also important, IMHO.
> > >
> > > It did not seem too much better to me.
> >
> > Well, the beauty is in the eye of the beholder. :-)
> >
> > Still, it shrinks the code (22 lines vs 37
On Thu, Jan 20, 2005 at 08:40:07AM +, David Woodhouse wrote:
> On Wed, 2005-01-19 at 15:39 -0800, John Mock wrote:
> > New to 2.6.11-rc1 is that 'lsusb' exhibits 'endian' problems on the
> > PowerMac.
>
> Is that really new to 2.6.11-rc1? The kernel byte-swaps the bcdUSB,
> idVendor,
On Thu, Jan 20, 2005 at 04:22:56PM +0100, Rogier Wolff wrote:
> On Thu, Jan 20, 2005 at 07:08:58AM -0800, Greg KH wrote:
> > On Thu, Jan 20, 2005 at 03:54:22PM +0100, Rogier Wolff wrote:
> > > Hi,
> > >
> > > When using custom baud rates, the code does:
> > >
> > >
> > >if
On Wed, Jan 19, 2005 at 06:49:00PM -0800, Matthew Dharm wrote:
> On Wed, Jan 19, 2005 at 02:07:07PM -0800, Greg KH wrote:
> > On Thu, Dec 23, 2004 at 03:40:31AM +0100, Adrian Bunk wrote:
> > > On Sun, Dec 19, 2004 at 04:31:46PM -0800, Greg KH wrote:
> > > > On Mon, Dec 20, 2004 at 01:16:44AM
* Michael S. Tsirkin ([EMAIL PROTECTED]) wrote:
> Hi!
> Security hook seems to be missing before compat_ioctl in mm2.
> And, it would be nice to avoid calling it twice on some paths.
>
> Chris Wright's patch addressed this in the most elegant way I think,
> by adding vfs_ioctl.
>
> Accordingly,
Hi!
Security hook seems to be missing before compat_ioctl in mm2.
And, it would be nice to avoid calling it twice on some paths.
Chris Wright's patch addressed this in the most elegant way I think,
by adding vfs_ioctl.
Accordingly, this change:
@@ -468,6 +496,11 @@ asmlinkage long
On Thu, 2005-01-20 at 15:48 -0800, Matt Mackall wrote:
> On Thu, Jan 20, 2005 at 03:39:21PM -0800, Andrew Morton wrote:
> > Matt Mackall <[EMAIL PROTECTED]> wrote:
> > >
> > > I'm seeing radeonfb on my ThinkPad T30 go weird on reboot (lots of
> > > horizontal lines) and require powercycling to
On Thu, 2005-01-20 at 15:39 -0800, Andrew Morton wrote:
> Matt Mackall <[EMAIL PROTECTED]> wrote:
> >
> > I'm seeing radeonfb on my ThinkPad T30 go weird on reboot (lots of
> > horizontal lines) and require powercycling to fix. Worked fine with 2.6.10.
>
> Which radeon driver?
Sorry about the confusion, but it appears the 'oops' is not specific to
the USB subsystem, as it seems also to occur with an ordinary SCSI module
as well under 2.6.10 (PPC). In this case, it's a ZIP drive connected via
'mac53c94' module, and in addition to, as noted before, the same problem
with
Jens, last December you observed there was bio code
duplicated in the dm drivers.
Here are a collection of patches that implements
support for local bio and bvec pools into bio.c and then
removes the duplicate bio code from the dm drivers.
It also replaces a call to alloc_bio() in dm.c with
a
It seems to me that we need to either do the attached or to rewrite the timer
front end code to just gather the offset info and defer to the timer irq thread
to update jiffies and the offset stuff. In either case we really can not split
the two and we do need the xtime_lock protection.
--
Matt Mackall <[EMAIL PROTECTED]> wrote:
>
> > Which radeon driver? CONFIG_FB_RADEON_OLD or CONFIG_FB_RADEON?
>
> FB_RADEON.
Ah, OK. Likely culprits are
radeonfb-massive-update-of-pm-code.patch
radeonfb-build-fix.patch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> On Sat, 15 Jan 2005 10:05:37 -0800 (PST), Linus Torvalds <[EMAIL
> PROTECTED]> said:
Linus> Hmm.. I don't think your patch is wrong per se, but I do
Linus> think it's a bit too subtle. I'd almost rather make
Linus> "jiffies_to_msecs()" just test for overflow instead, and that
On Thu, Jan 20, 2005 at 03:39:21PM -0800, Andrew Morton wrote:
> Matt Mackall <[EMAIL PROTECTED]> wrote:
> >
> > I'm seeing radeonfb on my ThinkPad T30 go weird on reboot (lots of
> > horizontal lines) and require powercycling to fix. Worked fine with 2.6.10.
>
> Which radeon driver?
Hi!
Here is the tested patch against modem_run and eciadsl hang since 2.4.28.
Longer discussion about it is in:
http://sourceforge.net/mailarchive/forum.php?thread_id=6054671_id=5398
and feedback from users is in:
http://www.mail-archive.com/speedtouch%40ml.free.fr/msg06848.html
The patch itself
Btw, I think I've now merged everything to bring us back to where we
wanted to be - can people verify that the architecture they care about has
all the right "read_can_lock()" etc infrastructure (and preferably that it
_works_ too ;), and that I've not missed of incorrectly ignored some
Matt Mackall <[EMAIL PROTECTED]> wrote:
>
> I'm seeing radeonfb on my ThinkPad T30 go weird on reboot (lots of
> horizontal lines) and require powercycling to fix. Worked fine with 2.6.10.
Which radeon driver? CONFIG_FB_RADEON_OLD or CONFIG_FB_RADEON?
(cc Ben, who is the likely cuprit ;)
Which
On Thu, 20 Jan 2005 15:52:34 -0500 (EST)
Rahul Jain <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have written a module that changes IP addrs and TCP port values. After
> changing these fields, I am able to recalculate the IP checksum within
> the module. To recalculate the TCP checksum, I wrote a new
On Thu, Jan 20, 2005 at 03:57:07PM -0600, Chris Friesen wrote:
> Andries Brouwer wrote:
>
> >But let me stress that I also consider the earlier situation
> >unacceptable. It is really bad to lose a few weeks of computation.
>
> Shouldn't the application be backing up intermediate results to disk
Karim Yaghmour wrote:
> Zach Brown wrote:
>
>>Thoughts? I, for one, am tired of writing throw-away per-cpu tracing
>>patches ;)
>
> Have you taken a look at relayfs and ltt?
Only briefly. They've always seemed more involved than the sort of
thing I was after. I'll try and sit down and
I'm seeing radeonfb on my ThinkPad T30 go weird on reboot (lots of
horizontal lines) and require powercycling to fix. Worked fine with 2.6.10.
--
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
[EMAIL PROTECTED] wrote:
On Thu, Jan 20, 2005 at 10:42:24AM -0500, Paul Davis wrote:
over on #ardour last week, we saw appalling performance from
reiserfs. a 120GB filesystem with 11GB of space failed to be able to
deliver enough read/write speed to keep up with a 16 track
session. When the
This patch had fixed following 2 conflicting type errors.
Yoichi
arch/mips/lib/csum_partial_copy.c:21: error: conflicting types for
`csum_partial_copy_nocheck'
include/asm/checksum.h:65: error: previous declaration of
`csum_partial_copy_nocheck'
arch/mips/lib/csum_partial_copy.c:38: error:
Hi
I reproducibly get the following Oops as soon as I start using inotify
with gamin and/or beagle. This happens with linux 2.6.10-as1 + inotify
0.18-rml-4 on multiple x86 machines.
Unable to handle kernel NULL pointer dereference at virtual address
printing eip:
c01d6d31
*pde =
Arjan van de Ven wrote:
On Wed, 2005-01-19 at 15:51 -0800, George Anzinger wrote:
Arjan van de Ven wrote:
On Sun, 2005-01-16 at 00:58 +, Alan Cox wrote:
On Sad, 2005-01-15 at 09:30, Andrew Morton wrote:
Matthias Lang <[EMAIL PROTECTED]> wrote:
These are things we probably cannot change now.
Tony Lindgren wrote:
* George Anzinger [050119 16:25]:
Tony Lindgren wrote:
* George Anzinger [050119 15:00]:
I don't think you will ever get good time if you EVER reprogramm the PIT.
That is why the VST patch on sourceforge does NOT touch the PIT, it only
turns off the interrupt by
Zach Brown wrote:
> Thoughts? I, for one, am tired of writing throw-away per-cpu tracing
> patches ;)
Have you taken a look at relayfs and ltt?
Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || [EMAIL
Hi!
> > > The readability of code is also important, IMHO.
> >
> > It did not seem too much better to me.
>
> Well, the beauty is in the eye of the beholder. :-)
>
> Still, it shrinks the code (22 lines vs 37 lines), it uses less GPRs (5 vs
> 7), it uses less
> SIB arithmetics (0 vs 4 times),
On Jan 20, 2005 14:29 +0100, Andreas Gruenbacher wrote:
> The ea-in-inode patch totally relies on getting all the available inode space
> cleared out by the kernel (or mke2fs, or e2fsck). If this is not the case for
> any inode we find, then i_extra_isize may contain a random number, and we've
Hi,
On Thursday, 20 of January 2005 23:06, Pavel Machek wrote:
> Hi!
>
> > > > The following patch speeds up the restoring of swsusp images on x86-64
> > > > and makes the assembly code more readable (tested and works on AMD64).
> > > > It's
> > > > against 2.6.11-rc1-mm1, but applies to
1 - 100 of 654 matches
Mail list logo
