* Andrew Morton <[EMAIL PROTECTED]> wrote:
> > However, the first step is to do this manually from user space.
>
> Yup. The thing is, lots of people want this feature for various
> reasons. Not just numerical-computing-users-on-NUMA. We should get
> it right for them too.
>
> Especially kern
Hello,
While browsing linux source code what i found
that if function is defined as
asmlinkage long sys_open(const char * filename, int
flags, int mode)
then its not exported to kenrel and thus not seen in
/proc/ksyms. But if function in kernel source is not
defined with asmlinkage then it is
On Tue, Feb 22, 2005 at 12:44:30AM +0100, Andre Tomt wrote:
> really bensoo_at_soo_dot_com wrote:
> >i'm crashing my box twice a day running 2.6.11-rc4
> >when i turn on the Athlon-XP CPU bus disconnect.
[...]
>
> Bus disconnect have never been reliable on my Athlon XP 1800+,
> regardless of oper
On Mon, Feb 21 2005, Greg Stark wrote:
>
> Jens Axboe <[EMAIL PROTECTED]> writes:
>
> > For the longest time, only the old PATA drivers supported barrier writes
> > with journalled file systems.
>
> What about for fsync(2)? One of the most frequent sources of data loss on the
> postgres mailing
On Tue, 2005-02-22 at 01:52 -0500, Jon Smirl wrote:
> Does the kernel need to keep a bit that says the device has been
> posted, don't do it again?
No. The kernel have no idea about what POSTing means in fact. That is
also driver specific.
> Should removing/inserting a driver cause a repost?
The
Does the kernel need to keep a bit that says the device has been
posted, don't do it again? Should removing/inserting a driver cause a
repost? I was going to add bit in pci_dev that tracks the reset status
so that it will persist across unloads. Do we have code to tell if
hardware needs a reset wit
Andi,
Oops. It's late. The pargraph below in my previous note confused
cpus and nodes. It should have read as follows:
Let's suppose that nodes 0-1 of a 64 node [was: CPU] system have graphics
pipes. To keep it simple, we will assume that there are 2 cpus
per node like an Altix [128 CPUS in thi
On Tue, 22 Feb 2005 17:32:40 +1100, Benjamin Herrenschmidt
<[EMAIL PROTECTED]> wrote:
> And even if we did, then we could have the vga "legacy" driver use the
> firmware loader to "boot" them. And again, you seem to dismiss all my
> other arguments...
I'm not dismissing them, I'm in agreement with
Andi,
I went back and did some digging on one the issues that has dropped
off the list here: the case where the set of old nodes and new
nodes overlap in some way. No one could provide me with a specific
example, but the thread was that "This did happen in certain scenarios".
Part of these scenari
On Tue, 2005-02-22 at 01:05 -0500, Jon Smirl wrote:
> On Tue, 22 Feb 2005 16:13:36 +1100, Benjamin Herrenschmidt
> <[EMAIL PROTECTED]> wrote:
> > What we can/should provide, is a ncie helper to do the job once the
> > driver decides to have a go at it. I think userspace is the right
> > solution, s
On Tue, 2005-02-22 at 01:03 -0500, Jon Smirl wrote:
> On Tue, 22 Feb 2005 16:13:36 +1100, Benjamin Herrenschmidt
> <[EMAIL PROTECTED]> wrote:
> > On Mon, 2005-02-21 at 23:56 -0500, Alex Deucher wrote:
> > I think that the driver is the "chief" here and the one to know what to
> > do with the cards
On Tue, 22 Feb 2005 16:13:36 +1100, Benjamin Herrenschmidt
<[EMAIL PROTECTED]> wrote:
> What we can/should provide, is a ncie helper to do the job once the
> driver decides to have a go at it. I think userspace is the right
> solution, similar to the firmware loader helpers, as I wrote earlier.
> T
On Tue, 22 Feb 2005 16:13:36 +1100, Benjamin Herrenschmidt
<[EMAIL PROTECTED]> wrote:
> On Mon, 2005-02-21 at 23:56 -0500, Alex Deucher wrote:
> I think that the driver is the "chief" here and the one to know what to
> do with the cards it drives. It can detect a non-POSTed card and deal
> with it.
On Tue, 22 Feb 2005 05:13:07 + (GMT), James Simmons
<[EMAIL PROTECTED]> wrote:
> > > 4. Which comes to the next point. The code is not modular enough. Take
> > >drm_bufs.c. Everything is a ioctl function. This has a few
> > > disadvantages.
> > >One is the fbdev layer couldn't just lin
On Tue, 22 Feb 2005 15:46:03 +1100, Dave Airlie <[EMAIL PROTECTED]> wrote:
> >
> > 1. Lots of work that would take lots of time. To my knowledge all fbdev
> >developers work in there spare free time. No one does this for a
> >living.
>
> So do most of the drm developers, I know I do and Jo
On Mon, 2005-02-21 at 23:56 -0500, Alex Deucher wrote:
> another advantage of the emulator would be that "PC" vga cards could
> be used in non-x86 platforms, which I'm sure would be quite popular...
That's implied indeed... though Jon approach would require the common
code to "know" that we are o
> > 1. Lots of work that would take lots of time. To my knowledge all fbdev
> >developers work in there spare free time. No one does this for a
> >living.
>
> So do most of the drm developers, I know I do and Jon Smirl does, and
> Eric Anholt does and I think us three have been the larges
On Mon, 2005-02-21 at 23:42 -0500, Jon Smirl wrote:
> On Tue, 22 Feb 2005 14:12:48 +1100, Benjamin Herrenschmidt
> <[EMAIL PROTECTED]> wrote:
> > It's up to each driver to detect wether it's card need to be POSTed or
> > not. Anything else would mean infinite breakage.
>
> Your approach is that it
On Tue, 22 Feb 2005 14:12:48 +1100, Benjamin Herrenschmidt
<[EMAIL PROTECTED]> wrote:
>
> > Ben, since I'm not getting any help on LKML maybe you can answer this.
> > Secondary cards needs reset. After looking at a bunch of fbdev drivers
> > their code assumes the card has been reset when their pr
>
> 1. Lots of work that would take lots of time. To my knowledge all fbdev
>developers work in there spare free time. No one does this for a
>living.
So do most of the drm developers, I know I do and Jon Smirl does, and
Eric Anholt does and I think us three have been the largest
contribu
Jens Axboe <[EMAIL PROTECTED]> writes:
> For the longest time, only the old PATA drivers supported barrier writes
> with journalled file systems.
What about for fsync(2)? One of the most frequent sources of data loss on the
postgres mailing list has to do with users with IDE drives where fsync
On Tue, 22 Feb 2005 14:12:48 +1100, Benjamin Herrenschmidt
<[EMAIL PROTECTED]> wrote:
> It's up to each driver to detect wether it's card need to be POSTed or
> not. Anything else would mean infinite breakage.
Your approach is that it is a per driver problem. I was taking a
different tack and look
> > Do you see any other solution to this then?
>
> You could build this inside of the DRM framework which already
> supports DMA and memory management. DRM doesn't really know anything
> about 3D, it just knows how to send commands to the graphics hardware.
> It's the mesa layer in user space th
I found out some interesting things tonight. I removed my /var and
/home snapshots, and all the corruption, with the exception of files I
had changed while /var and /home were in their corrupted state, had
disappeared!
I overwrote several files on /var that were corrupt with clean copies
from my
> Ben, since I'm not getting any help on LKML maybe you can answer this.
> Secondary cards needs reset. After looking at a bunch of fbdev drivers
> their code assumes the card has been reset when their probe() function
> runs. So this means that we have to run the VBIOS reset before probe
> is cal
Parag Warudkar wrote:
On Sunday 20 February 2005 05:58 am, [EMAIL PROTECTED] wrote:
9859138.6083 vmlinux mark_offset_tsc
5844735.1032 libc-2.3.2.sogetc
What makes you think mark_offset_tsc is slow? Do you have any comparative
numbers? It might just be that
> "John" == John Stoffel <[EMAIL PROTECTED]> writes:
me> Kernel: 2.6.9, 2.6.10 (i cant remember from which one is attached log).
me> Distribution: Gentoo.
John> Try upgrading to 2.6.11-rc2-mm2 or newer, I've found that usb-storage
John> works a bit better here, though I haven't confirmed this
On Mon, 21 Feb 2005 11:02:24 +0100
Asier Llano Palacios <[EMAIL PROTECTED]> wrote:
> I think that implementing a GPIO interface is a must-have. And I also
> think that your proposal is awesome. I work with GPIOs a lot, and I hate
> not doing it in a cross-platform way.
>
> I generally agree with
On Mon, 21 Feb 2005, Pete Zaitcev wrote:
>
> I am surprised too. Jens says "ub effectively disables merging by setting
> max hw/phys segment limit of 1." But surely this ought not to be a problem
> for reads within the same page.
Hmm.. Why does it do that anyway? Jens - will merging take place
On Mon, 21 Feb 2005, David Roundy wrote:
I just scanned the comparison of various source-code management
schemes at
http://zooko.com/revision_control_quick_ref.html
and found myself wishing for a similar review of bk (which was
excluded, not being open-source).
Would you (or anyone else) be
On Mon, 21 Feb 2005 12:00:48 -0800 (PST), Linus Torvalds <[EMAIL PROTECTED]>
wrote:
> That said, I'm surprised that the difference in performance is _that_
> large. Regardless of whether the disk blocksize is 512 bytes or 4096
> bytes, you should be getting IO merging - it might use more CPU ti
Hi,
I've created a tracing tool several years ago for my master's thesis
against the 2.2 kernel and onto the 2.4 kernel. I'm currently using this
in the 2.6 kernel to debug some customizations against Ingo's RT kernel.
What this is, is basically a device that allocates a large number of
single pa
On Mon, 21 Feb 2005 19:06:23 EST, Anthony DiSante said:
> The driver code for my devices has "been given" to me as part of the kernel.
> Any of a handful of USB devices has caused permanent D states, as has a
> CDROM and a NIC. I guess I'll need to start debugging all of these drivers.
> W
On Mon, 21 Feb 2005 19:01:54 -0500, Brandy Chin <[EMAIL PROTECTED]> wrote:
> Hello All,
>
> I'm having some trouble in getting the number of disk blocks
> read/written per second. I found the link on /proc/diskstats but I
> don't see that parameter somewhere. If there's a way to get the
> number
Chris Friesen wrote:
It's indisputable that there will always be driver bugs and faulty
hardware. Of course these should be fixed, but if it's possible for
the kernel to gracefully deal with the bugs until they get fixed, then
why shouldn't it do so?
Think of the overhead required to track ever
Hello All,
I'm having some trouble in getting the number of disk blocks
read/written per second. I found the link on /proc/diskstats but I
don't see that parameter somewhere. If there's a way to get the
number, it'd be great. Otherwise some cursory advice, pointer to more
links would be fine.
me> The device is: USB2.0 to IDE 3.5" hard disk enclosure.
me> Producer: Seven.
me> Part of /var/log/messages with USB debug enabled in kernel is
me> attached to this email.
me> Kernel: 2.6.9, 2.6.10 (i cant remember from which one is attached log).
me> Distribution: Gentoo.
Try upgrading to 2.
Andrew wrote:
> Yes, I ... [clarifies pj's various confusions]
Yup - all sounds good - thanks.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373,
1.925.600.0401
-
To unsubscr
Martin MOKREJ© <[EMAIL PROTECTED]> writes:
> Hi,
> I have received no answer to my former question
> (see http://marc.theaimsgroup.com/?l=linux-kernel&m=110827143716215&w=2).
That's because it's a BIOS problem.
There are limits on how much Linux can work around BIOS breakage.
> Although I'
really bensoo_at_soo_dot_com wrote:
Hi;
i'm crashing my box twice a day running 2.6.11-rc4
when i turn on the Athlon-XP CPU bus disconnect.
When network activity is up over maybe 120KB/s and
i'm playing a video file at the same time, then
chances are good i'll lock up the box.
Box runs a Chaintech
Hi;
i'm crashing my box twice a day running 2.6.11-rc4
when i turn on the Athlon-XP CPU bus disconnect.
When network activity is up over maybe 120KB/s and
i'm playing a video file at the same time, then
chances are good i'll lock up the box.
Box runs a Chaintech Summit 7NIF2 with 1G RAM and
an A
Pavel Machek wrote:
Hi!
Any thoughts on this one? We should come back from resume in 30-row mode,
shouldn't we?
Well, current state of video resume is "we are happy to see anything
at all".
HW info
Using vga=0xf07, default8x16 font, display has 30 lines
On powerup from S3 console has only 25
Pavel Machek wrote:
Hi!
Any thoughts on this one? We should come back from resume in 30-row mode,
shouldn't we?
Well, current state of video resume is "we are happy to see anything
at all".
HW info
Using vga=0xf07, default8x16 font, display has 30 lines
On powerup from S3 console has only 25
On Mon, 21 Feb 2005 17:44:32 -0500, Anthony DiSante
<[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > See the thread rooted here:
> >
> > Date: Wed, 03 Nov 2004 07:51:39 -0500
> > From: Gene Heskett <[EMAIL PROTECTED]>
> > Subject: is killing zombies possible w/o a reboot?
> > Sender: [EMAI
Andrew Morton wrote:
Ray Bryant <[EMAIL PROTECTED]> wrote:
We did it this way because it was easier to get it into SLES9 that way.
But there is no particular reason that we couldn't use a system call.
It's just that we figured adding system calls is hard.
aarggh. This is why you should target ke
Previously James Simmons wrote:
> DBUS isthe future. I just wish they had programing howto for the average
> joe to write apps for it.
The docs are good enough in my experience, there just seems to be a gap
between the docs and the code. Strangely enough in this case there are
documented API bit
Previously Nigel Cunningham wrote:
> Looks like some work has already been done on getting kernel events out
> to dbus, too. Found this email:
> http://mail.gnome.org/archives/utopia-list/2004-July/msg00031.html
Or http://lists.freedesktop.org/archives/dbus/2005-February/002170.html
or one of the
> > > > Checkout DBUS. Its very nice.
> > >
> > > D-BUS is already userspace. netlink however is a nice transport system
> > > and there are several existing tools that pass messages from netlink
> > > onto D-BUS.
> >
> > That is what I mean. We already have a userspace component.
>
> I like t
On Tue, 2005-02-22 at 08:37, James Simmons wrote:
> > Previously James Simmons wrote:
> > > Checkout DBUS. Its very nice.
> >
> > D-BUS is already userspace. netlink however is a nice transport system
> > and there are several existing tools that pass messages from netlink
> > onto D-BUS.
>
> Th
[EMAIL PROTECTED] wrote:
See the thread rooted here:
Date: Wed, 03 Nov 2004 07:51:39 -0500
From: Gene Heskett <[EMAIL PROTECTED]>
Subject: is killing zombies possible w/o a reboot?
Sender: [EMAIL PROTECTED]
To: linux-kernel@vger.kernel.org
Reply-to: [EMAIL PROTECTED]
Message-id: <[EMAIL PROTECTED
Anthony DiSante wrote:
It's indisputable that there will always be driver bugs and faulty
hardware. Of course these should be fixed, but if it's possible for the
kernel to gracefully deal with the bugs until they get fixed, then why
shouldn't it do so?
Think of the overhead required to track ev
Ray Bryant <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton wrote:
> > Martin Hicks <[EMAIL PROTECTED]> wrote:
> >
> >>This patch introduces a new sysctl for NUMA systems that tries to drop
> >> as much of the page cache as possible from a set of nodes. The
> >> motivation for this patch is for setti
Paul Jackson <[EMAIL PROTECTED]> wrote:
>
> Andrew wrote:
> > sys_free_node_memory(long node_id, long pages_to_make_free, long
> > what_to_free)
> > ...
> > - To make the syscall more general, we should be able to reclaim mapped
> > pagecache and anonymous memory as well.
>
> sys_free_node_memo
Fixes double-kfree that caused slab corruption.
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
= drivers/scsi/libata-core.c 1.116 vs edited =
--- 1.116/drivers/scsi/libata-core.c2005-02-01 20:23:51 -05:00
+++ edited/drivers/scsi/libata-core.c 2005-02-20 23:34:32 -05:00
@@ -2800,7 +280
Andrew Morton wrote:
Martin Hicks <[EMAIL PROTECTED]> wrote:
This patch introduces a new sysctl for NUMA systems that tries to drop
as much of the page cache as possible from a set of nodes. The
motivation for this patch is for setting up High Performance Computing
jobs, where initial memory place
[EMAIL PROTECTED] wrote:
See the thread rooted here:
Date: Wed, 03 Nov 2004 07:51:39 -0500
From: Gene Heskett <[EMAIL PROTECTED]>
Subject: is killing zombies possible w/o a reboot?
Sender: [EMAIL PROTECTED]
To: linux-kernel@vger.kernel.org
Reply-to: [EMAIL PROTECTED]
Message-id: <[EMAIL PROTECTED
Andrew wrote:
> sys_free_node_memory(long node_id, long pages_to_make_free, long what_to_free)
> ...
> - To make the syscall more general, we should be able to reclaim mapped
> pagecache and anonymous memory as well.
sys_free_node_memory() - nice.
Does it make sense to also have it be able to f
On Monday 21 February 2005 13:29, Wichert Akkerman wrote:
>Previously Gene Heskett wrote:
>> Thats what I was afraid of, which makes using it for a motion
>> detected burgular alarm source considerably less than practical
>> since the machine must be able to do other things too.
>
>Dependin on the
Jon Smirl ([EMAIL PROTECTED]) said:
> Is there a specific reason why they are blocked?
>
> For example I'm looking at making changes to DRM such that DRM will
> require the corresponding framebuffer driver to be loaded. If you back
> up further this is part of fixing X so that it won't mess with
On Mon, 21 Feb 2005 14:27:21 -0500, Martin Hicks
<[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I've made a bunch of changes that Paul suggested. I've also responded
> to his concerns further down. Paul correctly pointed out that this
> patch uses some helper functions that are part of the cpusets patc
Previously Jeff Garzik wrote:
> These are _duplicate_ messages. The To/CC doesn't vary in my
> experience. Therefore, sorting on To/CC always guarantees my messages
> go into the correct folder.
It depends highly on how you filter. It do not use To/Cc headers
to choose the mailbox to deliver a
Martin Hicks <[EMAIL PROTECTED]> wrote:
>
> This patch introduces a new sysctl for NUMA systems that tries to drop
> as much of the page cache as possible from a set of nodes. The
> motivation for this patch is for setting up High Performance Computing
> jobs, where initial memory placement is
> Previously James Simmons wrote:
> > Checkout DBUS. Its very nice.
>
> D-BUS is already userspace. netlink however is a nice transport system
> and there are several existing tools that pass messages from netlink
> onto D-BUS.
That is what I mean. We already have a userspace component.
-
To u
Alasdair,
Thanks for the tips. Do you think it's possible DM's snapshots
could've caused this corruption, or do you think the problem lies
elsewhere?
Alex
On Mon, 21 Feb 2005 15:18:52 +, Alasdair G Kergon <[EMAIL PROTECTED]> wrote:
> On Sun, Feb 20, 2005 at 11:25:37PM -0600, Alex Adriaanse
On Mon, 21 Feb 2005 15:24:21 EST, Anthony DiSante said:
> Or maybe it SHOULD have killed your process, in some "proper" way that
> prevents any outstanding I/O requests from coming in days later and breaking
> things. Again, I'm no kernel hacker, but if an I/O request takes *3 days*,
> isn't th
Adrian Bunk wrote:
@@ -197,7 +194,7 @@
ei_status.priv = phys_mem;
if (ei_debug > 0)
- printk(version);
+ printk("ne3210 driver");
missing newline. Do something like "ns3210 __DATE__ loaded.\n"
Ditto for seeq8002.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe lin
Wichert Akkerman wrote:
Previously Jeff Garzik wrote:
You should add this to your procmailrc :)
# Nuke duplicate messages
:0 Wh: msgid.lock
| $FORMAIL -D 32768 msgid.cache
That has the nasty side-effect of spreading messages for a single
discussion amongst many different mailboxes depending on whi
[EMAIL PROTECTED] said:
> On Mon, Feb 21, 2005 at 04:53:06PM +0100, Andrea Arcangeli wrote:
[...]
> > AFIK all other SCM except arch and darcs always modify the repo, I never
> > heard complains about it, as long as incremental backups are possible
> > and they definitely are possible.
> Well, a
[EMAIL PROTECTED] wrote:
It seems like this problem is always going to exist, because some hardware
and some drivers will always be buggy. So shouldn't we have some sort of
watchdog higher up in the kernel, that watches for hung processes like this
and kills them?
And said watchdog would clean
To try to figure out some buffering problems my network application is having,
I wrote 2 tiny utilities
- pwrite connects to a socket and floods it with data until it sleeps
- pread accepts an incoming connection but never actually reads data.
It just lets it pile up until the read buffer
On Mon, 21 Feb 2005, Russell King wrote:
>
> In cs.c, alloc_io_space(), find the line:
>
> if (*base & ~(align-1)) {
>
> delete the ~ and rebuild. This may resolve your problem.
Unlikely. The code is too broken for words.
First off, setting align to zero makes no sense. An alignment can
On Mon, 21 Feb 2005 09:35:44 -0600, Steve French <[EMAIL PROTECTED]> wrote:
>
> >Being a wireless user i experience the occasional connection loss due
> >to walking out of range or something, recently after starting to use
> >cifs mounts instead of smbfs, I've noticed that stuff tends to break
On Mon, 21 Feb 2005, Pete Zaitcev wrote:
>
> Contiguous pages have nothing to do with it either. I forgot to mention
> that in the first case (whole device), all reads are done with length of
> 4KB, while in the second case (partition), all reads are 512 bytes long.
That's because your partitio
On Mon, Feb 21, 2005 at 04:53:06PM +0100, Andrea Arcangeli wrote:
> Hello Miles,
>
> On Mon, Feb 21, 2005 at 02:39:05PM +0900, Miles Bader wrote:
> > Yeah, the basic way arch organizes its repository seems _far_ more sane
> > than the crazy way CVS (or BK) does, for a variety of reasons[*]. No
>
On Mon, 21 Feb 2005 14:18:44 EST, Anthony DiSante said:
> It seems like this problem is always going to exist, because some hardware
> and some drivers will always be buggy. So shouldn't we have some sort of
> watchdog higher up in the kernel, that watches for hung processes like this
> and ki
Previously Jeff Garzik wrote:
> You should add this to your procmailrc :)
>
> # Nuke duplicate messages
> :0 Wh: msgid.lock
> | $FORMAIL -D 32768 msgid.cache
That has the nasty side-effect of spreading messages for a single
discussion amongst many different mailboxes depending on which path
happe
Andreas Jellinghaus dungeon.inka.de> writes:
> it looks like yaird does use pivot_root.
> however pivot_root and initramfs cause a kernel crash
> (once you unmount /initrd in the real system).
> use run-init from klibc instead and you are fine.
You're right: pivot_root and initramfs don't mix, so
Gene Heskett wrote:
On Monday 21 February 2005 12:58, Oliver Neukum wrote:
[...]
A video stream over usb1.1 must be compressed due to bandwidth
available. Decompression needs cpu.
Thats what I was afraid of, which makes using it for a motion detected
burgular alarm source considerably less than pr
Hi,
I've made a bunch of changes that Paul suggested. I've also responded
to his concerns further down. Paul correctly pointed out that this
patch uses some helper functions that are part of the cpusets patch. I
should have mentioned this before.
The major changes are:
- Cleanup proc_dobitma
Hi Adam,
> I've been recently trying to get my lmsensors working under
> 2.6.9, and i've found this:
>
> http://seclists.org/lists/linux-kernel/2005/Feb/2856.html
> http://lkml.org/lkml/2005/2/11/90
>
> kernel patch for gl520 chip, but after applying it kernel refused to
> compile. So I've fixed
Processes that get permanently stuck in "uninterruptible sleep" (the D state
as indicated by "ps aux") are such a pain. Of course they've always
existed, but at least on the 3 systems that I administer, they are far more
frequent with udev than they ever were before. I'm constantly upgrading
On Feb 21 2005, Bartlomiej Zolnierkiewicz wrote:
> On Sunday 20 February 2005 19:05, Rogério Brito wrote:
> > I have already tried contacting the linux-ide mailing list as a CC to my
> > earlier messages, but I got no response. I am including some details in
> > this e-mail. I included Bartlomiej i
Bartlomiej Zolnierkiewicz wrote:
On Sunday 20 February 2005 19:05, Rogério Brito wrote:
On Feb 20 2005, Matthias-Christian Ott wrote:
Rogério Brito wrote:
I am willing to test any patch and configuration (let's call me a
"guinea pig"), but I don't know what I should do. I have, OTOH,
reported my pr
On Sunday 20 February 2005 19:05, Rogério Brito wrote:
> On Feb 20 2005, Matthias-Christian Ott wrote:
> > Rogério Brito wrote:
> > >I am willing to test any patch and configuration (let's call me a
> > >"guinea pig"), but I don't know what I should do. I have, OTOH,
> > >reported my problem many
Am Montag, 21. Februar 2005 19:25 schrieb Gene Heskett:
> Thats what I was afraid of, which makes using it for a motion detected
> burgular alarm source considerably less than practical since the
> machine must be able to do other things too. Darn. And its usb1.1
> even when plugged into a 2.0
On Mon, Feb 21, 2005 at 07:41:54AM -0500, David Roundy wrote:
> The catch is that then we'd have to implement a smart server to keep users
> from having to download the entire history with each update. That's not a
> fundamentally hard issue, but it would definitely degrade darcs' ease of
> use,
Previously James Simmons wrote:
> Checkout DBUS. Its very nice.
D-BUS is already userspace. netlink however is a nice transport system
and there are several existing tools that pass messages from netlink
onto D-BUS.
Wichert.
--
Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make thing
Previously Gene Heskett wrote:
> Thats what I was afraid of, which makes using it for a motion detected
> burgular alarm source considerably less than practical since the
> machine must be able to do other things too.
Dependin on the type of compression used you might be able to detect
motion by
On Monday 21 February 2005 12:58, Oliver Neukum wrote:
>Am Montag, 21. Februar 2005 18:16 schrieb Gene Heskett:
>> Greetings;
>>
>> Motherboard is a biostar with nforce2 chipset, 2800xp cpu, gig of
>> ram.
>>
>> I've recently made the observation that while I can view 30fps
>> video from my firewir
On Mon, 21 Feb 2005 08:51:32 +0100, Jens Axboe <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] ~]# time dd if=/dev/uba of=/dev/null bs=10k count=10240
> > real0m22.731s
> > [EMAIL PROTECTED] ~]# time dd if=/dev/uba1 of=/dev/null bs=10k count=10240
> > real1m42.622s
> > So, reading from
> > What is the benefit of splitting the flow of information so?
>
> It's split already. You get some from input (power and sleep keys on
> keyboards, sound volume keys and display brightness on some notebooks),
> some from ACPI events (power keys on notebooks and desktop cases, sound
> volume, d
On Sat, 2005-02-19 at 17:03 +1100, Nigel Cunningham wrote:
> > The mem_maps are per-pgdat or per-node with discontig, but I have a
> > patch in the pipeline to take them out of there and make one for every
> > 128MB or 256MB, etc... area of memory (for memory hotplug). So, hanging
> > them off the
> > I think we need a generic way of delivering system status changes to
> > userspace. Something like acpid but bigger than that, something not
> > so heavily oriented on ACPI. I wonder if that kernel connector patch
> > should be looked at.
>
> Absolutely. I've been thinking about this too, but
Alex Adriaanse wrote:
The weird thing is I did not see any I/O errors in my logs, and
running find on /var worked without a problem. By the way, did you
take any DM snapshots when you experienced that corruption?
No, no snapshots. Just working find on a large dataset (source tree,
about 16GB). Th
Am Montag, 21. Februar 2005 18:16 schrieb Gene Heskett:
> Greetings;
>
> Motherboard is a biostar with nforce2 chipset, 2800xp cpu, gig of ram.
>
> I've recently made the observation that while I can view 30fps video
> from my firewire equipt movie camera with a minimal cpu hit of 2-3%,
> but v
Guillaume wrote:
>
> I understand your point of view but I'm using netlink interface
> because it's already in the kernel so my choice is to use something that
> is already in the kernel instead of adding dozens of new instructions
> and also to do things in user space.
All else equal, yes it is
--- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]>
wrote:
> > There are cases where Linux DAC and MAC cannot
> live happily together,
> > because Linux DAC is too limited.
>
> Agreed.
OKay, I'll bite. MAC and DAC are seperate.
How is it that (the limited nature of) the DAC
behavior makes
On Mon, 21 Feb 2005, Bartlomiej Zolnierkiewicz wrote:
> Speaking about ide-scsi, it will be undeprecated after I fix the locking.
> Rationale is that ide-scsi is _much_ simpler than ide-{cd,tape}.
> [ although it doesn't support all the hardware that ide-{cd,tape} do ]
Good to read that. I've alw
<><>
<><><>Hello.
Russell King wrote:
Known bug, just nobody has bothered to fix it. Please send the fix to
Linus so it gets into 2.6.11
The fix was submitted to and accepted by Linus on Feb 8th. Therefore,
there's nothing to "bother" with.
I've seen that fix in the latest -mm
patch released short
On Llu, 2005-02-21 at 15:25, Bartlomiej Zolnierkiewicz wrote:
> I haven't looked closely but I've noticed that these fixes are accessing
> rq->bio
> directly which is a layering violation. Could you de-bio and submit them?
> [ AFAIR they are already splitted out in RHEL4 ]
Not in the near future
1 - 100 of 187 matches
Mail list logo
