On Wed, Aug 31, 2005 at 01:10:39PM -0700, Tom Rini wrote:
> On Wed, Aug 31, 2005 at 01:38:52PM -0600, Bjorn Helgaas wrote:
> > On Monday 29 August 2005 10:09 am, Tom Rini wrote:
> > > linux-2.6.13-trini/drivers/serial/kgdb_8250.c | 594
> > > +
> >
> > The existing stuff in
Hi Andrew
I would like to ask for the inclusion of the general timeout
specification API in the -mm tree, looking forward it to bubble
up to mainline.
For more context, please visit:
http://groups.google.com/group/linux.kernel/browse_frm/thread/a426e5b0d0
On Wed, 31 Aug 2005, Dr. David Alan Gilbert wrote:
* Holger Kiehl ([EMAIL PROTECTED]) wrote:
On Wed, 31 Aug 2005, Jens Axboe wrote:
Full vmstat session can be found under:
Have you got iostat? iostat -x 10 might be interesting to see
for a period while it is going.
The following is the
>Each of the first three large parts starts with this sequence of bytes
Actually, the byte structure of the first 0x100 bytes
of each section seems to be very similar.
Some kind of header.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Wed, Aug 31, 2005 at 08:53:19PM +0100, Russell King wrote:
> On Wed, Aug 31, 2005 at 12:55:12PM -0400, Mark Lord wrote:
> > I'll try loading the works into another ARM
> > system I have here, and see (1) if it runs as-is,
> > and (2) what the disassembly shows.
>
> You can identify ARM code
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Allen Akin wrote:
> I believe we're doing well with layered implementation strategies like
> Xgl and Glitz. Where we might do better is in (1) extending OpenGL to
> provide missing functionality, rather than creating peer low-level APIs;
> (2)
On Wed, Aug 31, 2005 at 01:38:52PM -0600, Bjorn Helgaas wrote:
> On Monday 29 August 2005 10:09 am, Tom Rini wrote:
> > linux-2.6.13-trini/drivers/serial/kgdb_8250.c | 594 +
>
> The existing stuff in drivers/serial is named "8250_*"; is
> there a reason you're using
Yes.
Linux yavanna 2.6.13-ckx1 #1 Tue Aug 30 04:03:25 EST 2005 x86_64 AMD
Athlon(tm) 64 FX-53 Processor AuthenticAMD GNU/Linux
On Wednesday 31 August 2005 14:49, Rodney Gordon II wrote:
> On Mon, Aug 29, 2005 at 05:03:24PM +1000, Con Kolivas wrote:
> > These are patches designed to improve
On Thu, 25 Aug 2005, Todd Poynor wrote:
> In case it's getting lost in all these details, the main point of all
> this is to pose the question: "are arbitrary power parameters arranged
> into a set with mutually consistent values (called here an operating
> point) a good low-level abstraction
On Wed, Aug 31, 2005 at 11:29:30AM -0700, Keith Packard wrote:
| The real goal is to provide a good programming environment for 2D
| applications, not to push some particular low-level graphics library.
I think that's a reasonable goal.
My red flag goes up at the point where the 2D programming
Sorry everybody, forgot the most important Cc: :)
-Nish
Hi Andrew,
In looking at Bug 5132 and sys_poll(), I think there is a flaw in the
current code.
The @timeout parameter to sys_poll() is in milliseconds but we compare
it to (MAX_SCHEDULE_TIMEOUT / HZ), which is jiffies/jiffies-per-sec or
On Wed, Aug 31, 2005 at 12:55:12PM -0400, Mark Lord wrote:
> I'll try loading the works into another ARM
> system I have here, and see (1) if it runs as-is,
> and (2) what the disassembly shows.
You can identify ARM code quite readily - look for a large number of
32-bit words naturally aligned
Use of die_notifiers is a debugging feature that is only used if
CONFIG_DEBUG_KERNEL is set. For a kernel without debugging there is no
need of die notifiers. This will generate no code for notify_die if
debugging is not on. Seems that there is an expectation that future distro
releases will
On Mon, Aug 29, 2005 at 05:03:24PM +1000, Con Kolivas wrote:
> These are patches designed to improve system responsiveness and
> interactivity.
> It is configurable to any workload but the default ck* patch is aimed at the
> desktop and ck*-server is available with more emphasis on serverspace.
The special case for s_pitch == 2 saves about 270 ms system time (2120 ->
1850ms)
with a 16x30 font.
Compared to what? How much is the function call overhead?
Your version of the inline code inserted after an if (idx==2) in
bit_putcs against my version of the
inline code.
cu,
knut
On Wed, Aug 31, 2005 at 12:14:23PM -0700, [EMAIL PROTECTED] wrote:
> Do you want to try to handle version skew ? All kernels built
> from GIT trees look like 2.6.13 until Linus releases 2.6.14-rc1.
> Possible approaches (requiring changes to the kernel Makefile).
> 1) Use the SHA1 of HEAD to
Andrew,
Got some feedback on this one from David Howells
> Looks okay to me.
>
> David
so I'm resending it in the hope that you'll drop it into -mm (or NACK it
if you don't like it) :-)
-- Forwarded Message --
Subject: [PATCH] remove EXPORT_SYMBOL(strtok) from
On Monday 29 August 2005 10:09 am, Tom Rini wrote:
> linux-2.6.13-trini/drivers/serial/kgdb_8250.c | 594 +
The existing stuff in drivers/serial is named "8250_*"; is
there a reason you're using "kgdb_8250" rather than "8250_kgdb"?
> + * serial8250_unregister_by_port -
Hi,
On Wed, 31 Aug 2005, Knut Petersen wrote:
> I added the multiply back because gcc (v. 3.3.4) does generate the fastest
> code
> if I write it this way.
The multiply is not generally faster, so your version may be the fastest,
but in other situations it will be a lot slower. My version is
Hi Roman!
+static inline void __fb_pad_aligned_buffer(u8 *dst, u32 d_pitch, u8 *src, +
u32 s_pitch, u32 height)
+{
+ int i, j;
+
+ if (likely(s_pitch==1))
+ for(i=0; i < height; i++)
+ dst[d_pitch*i] = src[i];
I added the multiply back
Arjan van de Ven wrote:
The GPL terms that require GPL conversion of any code that runs on Linux
is not supported by US Law. Many would
disagree, but that's OK. In short, it's just like any other proprietary
app running on Linux. If it uses no Linux code (which
it does not), then the GPL does
Do you want to try to handle version skew ? All kernels built
from GIT trees look like 2.6.13 until Linus releases 2.6.14-rc1.
Possible approaches (requiring changes to the kernel Makefile).
1) Use the SHA1 of HEAD to provide a precise identification.
2) Use $(git-rev-tree linus
Well, I'm sure you'll keep us honest... ;-).
- Jim
On Wed, 2005-08-31 at 12:06 -0700, Allen Akin wrote:
> On Wed, Aug 31, 2005 at 01:48:11PM -0400, Jim Gettys wrote:
> | Certainly replicating OpenGL 2.0's programmability through Render makes
> | no sense at all to me (or most
On Wed, Aug 31, 2005 at 01:48:11PM -0400, Jim Gettys wrote:
| Certainly replicating OpenGL 2.0's programmability through Render makes
| no sense at all to me (or most others, I believe/hope). If you want to
| use full use of the GPU, I'm happy to say you should be using OpenGL.
When expressed
> As noticed by Dmitry Torokhov, write() can not return ENOMEM
It turns out that Linux is ok here returning ENOMEM (even from a strict
POSIX perspective) so the patch is not needed.
I consulted our longstanding POSIX workgroup representative to see what
he could find out about this topic, and
Adrian Bunk wrote:
On Wed, Aug 31, 2005 at 06:59:07PM +0200, Johannes Stezenbach wrote:
I also added this to linuxtv.org CVS. But I'm not sure it
is critical enough to put it in stable.
If I were a -stable maintainer, I'd include both patches after they were
included in Linus' tree
On Wed, 31 Aug 2005, Jens Axboe wrote:
On Wed, Aug 31 2005, Holger Kiehl wrote:
# ./oread /dev/sdX
and it will read 128k chunks direct from that device. Run on the same
drives as above, reply with the vmstat info again.
Using kernel 2.6.12.5 again, here the results:
[snip]
Ok, reads as
Hi Dave,
> drivers/char/watchdog/pcwd.c does this if it detects
> a temperature out of range..
>
> if (temp_panic) {
> printk (KERN_INFO PFX "Temperature overheat trip!\n");
> machine_power_off();
> }
>
> Two problems here are..
>
> 1.
> The GPL terms that require GPL conversion of any code that runs on Linux
> is not supported by US Law. Many would
> disagree, but that's OK. In short, it's just like any other proprietary
> app running on Linux. If it uses no Linux code (which
> it does not), then the GPL does not apply to it
forgot to attach lspci output.
it is a 133MB PCI-X card but only run at 66MHZ.
quick question, where I can check if it is running at 64bit?
66MHZ * 32Bit /8 * 80% bus utilization ~= 211MB/s then match the upper
speed I meet now...
Ming
02:01.0 SCSI storage controller: Marvell MV88SX5081
join the party. ;)
8 400GB SATA disk on same Marvel 8 port PCIX-133 card. P4 CPU.
Supermicro SCT board.
# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid5] [multipath] [raid6]
[raid10] [faulty]
md0 : active raid0 sdh[7] sdg[6] sdf[5] sde[4] sdd[3] sdc[2] sdb[1] sda
[0]
Rik van Riel wrote:
On Wed, 31 Aug 2005, Jeff V. Merkey wrote:
The Core File System code is a separate proprietary module and is not
released under the GPL
Are you going to post an analysis on the legality of this
on merkeylaw.com ? ;)
I am very open to discussions of this.
On Wed, 31 Aug 2005, Jeff V. Merkey wrote:
> The Core File System code is a separate proprietary module and is not
> released under the GPL
Are you going to post an analysis on the legality of this
on merkeylaw.com ? ;)
--
All Rights Reversed
-
To unsubscribe from this list: send the line
On Tue, 2005-08-30 at 23:33 -0700, Allen Akin wrote:
> On Tue, Aug 30, 2005 at 01:26:53PM -0400, David Reveman wrote:
> | On Tue, 2005-08-30 at 12:03 -0400, Jon Smirl wrote:
> | > In general, the whole concept of programmable graphics hardware is
> | > not addressed in APIs like xlib and Cairo.
On 8/31/05, Jim Gettys <[EMAIL PROTECTED]> wrote:
> Certainly replicating OpenGL 2.0's programmability through Render makes
> no sense at all to me (or most others, I believe/hope). If you want to
> use full use of the GPU, I'm happy to say you should be using OpenGL.
>
I do not even have IDE Taskfile Access enabled, so how is the kernel
printing these error messages before it freezes?
linux-2.6.13/drivers/ide/ide-taskfile.c:printk(KERN_ERR
"%s: no DRQ after issuing %sWRITE%s\n",
lqqq ATA/ATAPI/MFM/RLL support
Holger Kiehl wrote:
> On Wed, 31 Aug 2005, Jens Axboe wrote:
>
>> On Wed, Aug 31 2005, Holger Kiehl wrote:
>>
[]
>>> I used the following command reading from all 8 disks in parallel:
>>>
>>>dd if=/dev/sd?1 of=/dev/null bs=256k count=78125
>>>
>>> Here vmstat output (I just cut something out
Certainly replicating OpenGL 2.0's programmability through Render makes
no sense at all to me (or most others, I believe/hope). If you want to
use full use of the GPU, I'm happy to say you should be using OpenGL.
- Jim
On Tue, 2005-08-30 at 23:33 -0700, Allen
The Solera Networks DS File System kernel patches have been posted at
ftp.soleranetworks.com
and can be downloaded via anonymous ftp access.
These patches are for the 2.4.29, and 2.6.9 kernels. These patches
includes all kernel changes
made to the Linux kernel and GPL code that allows
Srivatsa Vaddagiri wrote:
On Mon, Aug 29, 2005 at 10:43:45PM +, Christopher Friesen wrote:
Last time I got interested in this, the management of the event queues
was still a fairly major performance hit.
Hmm ..I dont see any event queues being managed by dyn-tick patch.
Are you referring
On Mon, Aug 29, 2005 at 10:43:45PM +, Christopher Friesen wrote:
> Last time I got interested in this, the management of the event queues
> was still a fairly major performance hit.
>
> Has this overhead been brought down to reasonable levels?
Hmm ..I dont see any event queues being managed
All,
I am trying to get everyone together on this to hopefully solve a serious
bug that I have seen on multiple machines with:
a) A Promise ATA/133 controller (ATA/100 works OK)
b) Kernel 2.6.12 or 2.6.13 (2.6.13-rc7 appears to be OK)
The drive is a Seagate 7200.8 400GB 7200RPM 8MB cache
On 8/31/05, Alan Cox <[EMAIL PROTECTED]> wrote:
> On Mer, 2005-08-31 at 21:20 +0530, Nilesh Agrawal wrote:
> > mdacon: MDA with 8K of memory detected.
> > Console: switching consoles 1-16 to mono MDA-2 80x25
>
> You've compiled in the MDA driver, probably not what you want to load on
> that
On Wed, Aug 31 2005, Holger Kiehl wrote:
> ># ./oread /dev/sdX
> >
> >and it will read 128k chunks direct from that device. Run on the same
> >drives as above, reply with the vmstat info again.
> >
> Using kernel 2.6.12.5 again, here the results:
[snip]
Ok, reads as expected, like the buffered
On Wed, Aug 31, 2005 at 10:28:43PM +0530, Srivatsa Vaddagiri wrote:
> Following patches related to dynamic tick are posted in separate mails,
> for convenience of review. The first patch probably applies w/o dynamic
> tick consideration also.
>
> Patch 2/3 -> Dyn-tick cleanups
This patch cleans
On Wed, Aug 31 2005, jmerkey wrote:
>
> 512 is not enough. It has to be larger. I just tried 512 and it still
> limits the data rates.
Please don't top post.
512 wasn't the point, setting it properly is the point. If you need more
than 512, go ahead. This isn't Holger's problem, though, the
On Wed, Aug 31, 2005 at 10:28:43PM +0530, Srivatsa Vaddagiri wrote:
> Following patches related to dynamic tick are posted in separate mails,
> for convenience of review. The first patch probably applies w/o dynamic
> tick consideration also.
>
> Patch 3/3 -> Use lost tick information in
* Paulo Marques ([EMAIL PROTECTED]) wrote:
|> Jim McCloskey wrote:
|> >When I try to compile 2.6.13, using a complete tarball from
|> >kernel.org, the compilation fails with:
|> >
|> >---
|> > SYSMAP System.map
|> >
On Wed, Aug 31, 2005 at 10:28:43PM +0530, Srivatsa Vaddagiri wrote:
> Following patches related to dynamic tick are posted in separate mails,
> for convenience of review. The first patch probably applies w/o dynamic
> tick consideration also.
>
> Patch 1/3 -> Fixup lost tick calculation in
Holger Kiehl wrote:
meminfo.dump:
MemTotal: 8124172 kB
MemFree: 23564 kB
Buffers: 7825944 kB
Cached: 19216 kB
SwapCached: 0 kB
Active: 25708 kB
Inactive: 7835548 kB
HighTotal: 0 kB
HighFree:0 kB
On Tue, 2005-08-30 at 23:33 -0700, Allen Akin wrote:
> On Tue, Aug 30, 2005 at 01:26:53PM -0400, David Reveman wrote:
> | On Tue, 2005-08-30 at 12:03 -0400, Jon Smirl wrote:
> | > In general, the whole concept of programmable graphics hardware is
> | > not addressed in APIs like xlib and Cairo.
Hi,
On Wed, 31 Aug 2005, Knut Petersen wrote:
> +static inline void __fb_pad_aligned_buffer(u8 *dst, u32 d_pitch, u8 *src, +
> u32 s_pitch, u32 height)
> +{
> + int i, j;
> +
> + if (likely(s_pitch==1))
> + for(i=0; i < height; i++)
> + dst[d_pitch*i] =
512 is not enough. It has to be larger. I just tried 512 and it still
limits the data rates.
Jeff
Jens Axboe wrote:
On Wed, Aug 31 2005, jmerkey wrote:
I have seen an 80GB/sec limitation in the kernel unless this value is
changed in the SCSI I/O layer
for 3Ware and other controllers
On Wed, Aug 31 2005, jmerkey wrote:
>
>
> I have seen an 80GB/sec limitation in the kernel unless this value is
> changed in the SCSI I/O layer
> for 3Ware and other controllers during testing of 2.6.X series kernels.
>
> Change these values in include/linux/blkdev.h and performance goes from
On Wed, Aug 31, 2005 at 06:59:07PM +0200, Johannes Stezenbach wrote:
> On Wed, Aug 31, 2005 Adrian Bunk wrote:
> >
> > Add missing select's to DVB_BUDGET_AV fixing the following compile
> > error:
> >
> > <-- snip -->
> >
> > ...
> > LD .tmp_vmlinux1
> > drivers/built-in.o: In
On Wed, Aug 31, 2005 at 12:55:12PM -0400, Mark Lord wrote:
> Mmm.. curious sequence in the first 512 bytes of
> the DWL-G730AP firmware binary. It has this
> sequence of bytes repeated several times:
>
> 81 40 20 10 08 04 02 81 40 20 10 08 04 02 ...
>
> That should be recognizable to
I'll try this approach as well. On 2.4.X kernels, I had to change
nr_requests to achieve performance, but
I noticed it didn't seem to work as well on 2.6.X. I'll retry the
change with nr_requests on 2.6.X.
Thanks
Jeff
Tom Callahan wrote:
From linux-kernel mailing list.
Don't do
>From linux-kernel mailing list.
Don't do this. BLKDEV_MIN_RQ sets the size of the mempool reserved
requests and will only get slightly used in low memory conditions, so
most memory will probably be wasted.
Change /sys/block/xxx/queue/nr_requests
Tom Callahan
TESSCO Technologies
On Wed, Aug 31, 2005 Adrian Bunk wrote:
>
> Add missing select's to DVB_BUDGET_AV fixing the following compile
> error:
>
> <-- snip -->
>
> ...
> LD .tmp_vmlinux1
> drivers/built-in.o: In function `frontend_init':
> budget-av.c:(.text+0xb9448): undefined reference to
Mmm.. curious sequence in the first 512 bytes of
the DWL-G730AP firmware binary. It has this
sequence of bytes repeated several times:
81 40 20 10 08 04 02 81 40 20 10 08 04 02 ...
That should be recognizable to somebody, I think.
I'll try loading the works into another ARM
system I have
On Wed, 31 Aug 2005, Jens Axboe wrote:
On Wed, Aug 31 2005, Holger Kiehl wrote:
On Wed, 31 Aug 2005, Jens Axboe wrote:
Nothing sticks out here either. There's plenty of idle time. It smells
like a driver issue. Can you try the same dd test, but read from the
drives instead? Use a bigger
"Machida, Hiroyuki" <[EMAIL PROTECTED]> writes:
> Right, it looks like TLB, which holds cache "Physical addres"
> correponding to "Logical address". In this case, PID and file name
> to be looked up, perform role of "Logical address".
But, there is the big difference between hint table and TLB.
--On Wednesday, August 31, 2005 12:44:24 +0100 Hugh Dickins
<[EMAIL PROTECTED]> wrote:
> So you don't have Nick's test at the start of copy_page_range():
> if (!(vma->vm_flags & (VM_HUGETLB|VM_NONLINEAR|VM_RESERVED))) {
> if (!vma->anon_vma)
> return 0;
I have seen an 80GB/sec limitation in the kernel unless this value is
changed in the SCSI I/O layer
for 3Ware and other controllers during testing of 2.6.X series kernels.
Change these values in include/linux/blkdev.h and performance goes from
80MB/S to over 670MB/S on the 3Ware controller.
On Mer, 2005-08-31 at 21:20 +0530, Nilesh Agrawal wrote:
> mdacon: MDA with 8K of memory detected.
> Console: switching consoles 1-16 to mono MDA-2 80x25
You've compiled in the MDA driver, probably not what you want to load on
that hardware
-
To unsubscribe from this list: send the line
On Wed, 31 Aug 2005, Nick Piggin wrote:
Holger Kiehl wrote:
3236497 total 1.4547
2507913 default_idle 52248.1875
158752 shrink_zone 43.3275
121584 copy_user_generic_c 3199.5789
On Wed, Aug 31 2005, Holger Kiehl wrote:
> On Wed, 31 Aug 2005, Jens Axboe wrote:
>
> >Nothing sticks out here either. There's plenty of idle time. It smells
> >like a driver issue. Can you try the same dd test, but read from the
> >drives instead? Use a bigger blocksize here, 128 or 256k.
> >
>
Did anything critical change from -rc7 to 2.6.13?
I had -rc7 running on three machines for:
> 1 week
> 3 days
> 2 days
Respectively...
I upgraded to 2.6.13 this morning and only in less than 6 hours the machine
locked up, I am not home at the moment so I cannot verify what happened; but
nobody
hi
On Wednesday 31 August 2005 14.12, Marc Ballarin wrote:
> Hi,
>
> -rc6-mm2 breaks USB unplug for me. Happens with every USB device,
> gcc-3.3.5 and gcc-3.4.4 as well as preempt and non-preempt and is 100%
> reproducible.
> -rc6-mm1 seems fine.
>
> Reverting the following part of
>
On Tuesday 30 August 2005 15:31, Jesper Juhl wrote:
> On 8/31/05, Mark Gross <[EMAIL PROTECTED]> wrote:
> > On Tuesday 30 August 2005 14:19, Jesper Juhl wrote:
> > > On 8/30/05, Mark Gross <[EMAIL PROTECTED]> wrote:
> > > > On Tuesday 30 August 2005 13:31, Mark Gross wrote:
> > > > > On Tuesday 30
Jim MacBaine <[EMAIL PROTECTED]> writes:
> Hello,
>
> Using aoe on a sparc64 system gives strange results:
>
...
> The log says:
>
> Aug 31 15:18:49 sunny kernel: devfs_mk_dir: invalid argument.<6>
> etherd/e0.0: unknown partition table
> Aug 31 15:18:49 sunny kernel: aoe: 0011d8xx e0.0 v4000
Hi,
On Wed, 31 Aug 2005, Antonino A. Daplas wrote:
> Roman, okay if you have a 'Signed-off-by' line?
Okay.
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
>
> Please send more info --- output of dmesg, kernel config, hardware desription.
> Tony
I am compiling a 2.6.12 kernel, trying to have all relevant drivers
in-built (no modules).
Hardware details:
Intel Motherboard, P4 2.0 GHz
VideoCard: 82845 Chipset graphics controller
IDE/ATA controller:
On Wed, 31 Aug 2005 07:08:08 -0500
"Jack O'Quin" <[EMAIL PROTECTED]> wrote:
> JACK sources already include a CHECK_PREEMPTION() macro which expands
> to Ingo's special gettimeofday() calls. The trace is turned on and
> then off automatically before and after the realtime critical section
> in
On Wed, Aug 31 2005, Brian King wrote:
> diff -puN drivers/block/cfq-iosched.c~cfq_refcnt_fix
> drivers/block/cfq-iosched.c
> --- linux-2.6/drivers/block/cfq-iosched.c~cfq_refcnt_fix 2005-08-30
> 17:26:55.0 -0500
> +++ linux-2.6-bjking1/drivers/block/cfq-iosched.c 2005-08-31
>
1. 2.6.13 crash on sparc64 in sunsu_kbd_ms_interrupt
2. I'm running 2.6.13/sparc64 on a diskless Sun Ultra 5 workstation.
After an uptime between 5 and 20 minutes after start, the kernel
crashes, system stalls.
3. sparc64 sun keyboard sunsu_kbd_ms_interrupt
4. vanilla 2.6.13
5. Last working
On Tue, Aug 30, 2005 at 03:47:14PM -0400, Michael Krufky wrote:
> I wish I had seen this before 2.6.13 was released... I guess this only
> goes to show that there haven't been any testers using saa7134-hybrid
> dvb/v4l boards that depend on the tda1004x module, during the 2.6.13-rc
> series
>> They're incompatible, but you could be left to choose one or the other
>> via config option.
>
> Wouldn't need config option: there's /proc/sys/kernel/randomize_va_space
> for the whole running system, compatibility check on the ELFs run, and
> the infinite stack rlimit: enough ways to
Hi all,
I experience a rather strange bug that the same kernel (binary) sometimes does
recognize the disk correctly and sometimes not.
When loaded via Grub from CD it works fine:
hda: 156301488 sectors (80026 MB), CHS=65535/16/63, UDMA(33)
after installation of this kernel binary and the
Em Ter, 2005-08-30 às 23:20 +0200, Jean Delvare escreveu:
> Hi Mauro,
>
> > (...) it would be nice not to have a different I2C
> > API for every single 2.6 version :-) It would be nice to change I2C
> > API once and keep it stable for a while.
> The Linux 2.6 development model is designed around
No problem .. There are some other tests in there though .. I've been
using them for stress testing .. Apparently you don't need HRT on to use
them either.
Daniel
On Wed, 2005-08-31 at 11:19 -0400, Steven Rostedt wrote:
> On Wed, 2005-08-31 at 08:13 -0700, Daniel Walker wrote:
> > Sorry, that's
On Wed, 2005-08-31 at 08:12 -0700, Daniel Walker wrote:
> There is already a suite HRT of tests they include a nanosleep jitter
> test with 8 or 9 other tests..
>
> find them inside the hrt-support patch at http://high-res-timer.sf.net
Wow, they are hidden nicely :-)
I was looking for a tar
I think this is all that is needed for Mwave.
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
--- ../linux.vanilla-2.6.13-rc6-mm2/drivers/char/mwave/mwavedd.c
2005-08-25 17:04:20.0 +0100
+++ drivers/char/mwave/mwavedd.c2005-08-31 16:16:29.128028248 +0100
@@ -57,6 +57,7 @@
On Mer, 2005-08-31 at 20:36 +0530, Nilesh Agrawal wrote:
> Booting in single user mode, the same problem persists. I cant see
> anything after the screen gets filled.
> Does anyone know where is the problem??
What sort of machine - a very old Cyrix system with built in video
perhaps ?
-
To
On Wed, Aug 31, 2005 at 07:29:44AM -0700, Tom Rini wrote:
> On Wed, Aug 31, 2005 at 09:20:17AM +0200, Ingo Molnar wrote:
> >
> > * Daniel Walker <[EMAIL PROTECTED]> wrote:
> >
> > > Ingo,
> > > This patch adds a vermagic hook so PREEMPT_RT modules can be
> > > distinguished from
On Wed, 2005-08-31 at 08:13 -0700, Daniel Walker wrote:
> Sorry, that's http://high-res-timers.sf.net/
Thanks,
But I always seem to prefer to rewrite the wheel than to use one that
already exists. ;-) Probably explains why my cars are always in the
shop!
-- Steve
-
To unsubscribe from this
Sorry, that's http://high-res-timers.sf.net/
Daniel
On Wed, 2005-08-31 at 11:01 -0400, Steven Rostedt wrote:
> Thomas,
>
> I just was wondering how the HR Timers were in the latest -rtX patch and
> wrote my own little jitter test using nanosleep. Here's the results:
>
> On vanilla
Nilesh Agrawal wrote:
> Hi all,
>
> I have a peculiar problem with the kernel messages being printed during
> startup.
> During startup the messages are printed only uptill the monitor
> (screen) gets filled, the screen doesnt scroll down and no further
> messages are printed. However the
There is already a suite HRT of tests they include a nanosleep jitter
test with 8 or 9 other tests..
find them inside the hrt-support patch at http://high-res-timer.sf.net
Daniel
On Wed, 2005-08-31 at 11:01 -0400, Steven Rostedt wrote:
> Thomas,
>
> I just was wondering how the HR Timers were
* Greg KH ([EMAIL PROTECTED]) wrote:
> On Wed, Aug 24, 2005 at 06:20:33PM -0700, Chris Wright wrote:
> > Now that capability functions are default, rootplug no longer needs to
> > manually add them to its security_ops.
> >
> > Cc: Greg Kroah <[EMAIL PROTECTED]>
> > Signed-off-by: Chris Wright
On Wed, 2005-08-31 at 00:35, Ingo Molnar wrote:
> * Fernando Lopez-Lezcano <[EMAIL PROTECTED]> wrote:
>
> > Do a "tar cvf usr.tar /usr" just to read/write a lot to disk (this
> > within the same SATA disk). Watch memory being used in a system
> > monitor applet up to 100%. After a while, hard
On Wed, 31 Aug 2005, Martin J. Bligh wrote:
> --Hugh Dickins <[EMAIL PROTECTED]> wrote (on Wednesday, August 31, 2005
> 14:42:38 +0100):
> >
> > Which is indeed a further disincentive against shared page tables.
>
> Or shared pagetables a disincentive to randomizing the mmap space ;-)
Fair
Thomas,
I just was wondering how the HR Timers were in the latest -rtX patch and
wrote my own little jitter test using nanosleep. Here's the results:
On vanilla 2.6.13-rc7-git1 (Yes I need to get over to 2.6.13)
# ./jitter
starting calibrate
finished calibrate: 2133.9060MHz 2133906034
time
We have noticed when changing from kernel 2.4.23 to 2.6.8 that
timestamps of files are not changed if opened for a write and nothing is
written. When using 2.4.23 timestamps are changed. When using a local
filesystem (reiserfs) with either kernel, timestamps are changed.
Symptoms vary with the
[ Putting everyone cc again and leaving maciej's reply intact for
reference ]
Maciej W. Rozycki wrote:
The ID is 0x14 for Intel. But that is wrong for AMD CPUs. The actual Dual-Core
Why can't hw designers ever get such things right? Sigh...
Athlon CPUs we have report an APIC version
> > Which is indeed a further disincentive against shared page tables.
>
> Or shared pagetables a disincentive to randomizing the mmap space ;-)
> They're incompatible, but you could be left to choose one or the other
> via config option.
>
> 3% on "a certain industry-standard database
On Wednesday 31 August 2005 15:13, Martin Wilck wrote:
> In other words: What would be broken if we just used an APIC ID mask of
> 0xFF everywhere?
Nothing I think. It's more historical reasons. The physflat subarchitecture
patch essentially removed it, but it needs some rework and merging
with
On Mon, Aug 29, 2005 at 11:23:39PM +0200, Andi Kleen wrote:
> Tom Rini <[EMAIL PROTECTED]> writes:
>
> > This adds hardware breakpoint support for i386. This is not as well tested
> > as
> > software breakpoints, but in some minimal testing appears to be functional.
>
> This really would need
Jim McCloskey wrote:
When I try to compile 2.6.13, using a complete tarball from
kernel.org, the compilation fails with:
---
SYSMAP System.map
SYSMAP .tmp_System.map
Inconsistent kallsyms data
Try setting CONFIG_KALLSYMS_EXTRA_PASS
On Wed, 31 Aug 2005, Alan Cox wrote:
Registering means to create an ID for the system? Something out of
timestamp plus your PCI IDs and CPU info and so on?
Or have the other end issue you some kind of secure cookie, which was my
thought. Generating it locally as you suggest would be even
101 - 200 of 616 matches
Mail list logo
