Greetings,
Few days ago I compiled 241 random configurations of 2.6.13-rc3, today
I finally got around to parsing the results, top 40, sorted by name.
Percentage is error_builds / total_builds.
build script similar to:
count=0
while [ $((++count)) -le $limit ]; do
trial=$(printf %003d
On Fri, 22 Jul 2005 19:46:00 +,
Sam Ravnborg <[EMAIL PROTECTED]> wrote:
>On Thu, Jul 21, 2005 at 11:06:21PM -0400, Chuck Ebbert wrote:
>>
>> I have this in my .config file for 2.6.13-rc3:
>>
>>
>> #
>> # Multimedia devices
>> #
>> # CONFIG_VIDEO_DEV is not set
>>
>> #
>> # Digital Video Br
On Sat, 23 Jul 2005 08:53:00 +0200,
Stefan Smietanowski <[EMAIL PROTECTED]> wrote:
>Pavel Machek wrote:
>> Well, we have debugged with beeps, but... It would be cool if someone
>> got usb debug mode working but... and there are hardware debuggers.
>
>If kdb is your thing then SGI has gotten kdb wo
Patrick McHardy wrote:
Andrew McDonald wrote:
Take account of whether a socket is bound to a particular device when
selecting an IPv6 raw socket to receive a packet. Also perform this
check when receiving IPv6 packets with router alert options.
I guess this one makes sense on top.
[IPV4/6]:
I should underline that patch deal with the alternative which timer to
use for task priority calculation when both TSC and PMT function.
You writes
> it will need some additional documentation and its likely you don't
want
> to use the cycles_2_ns() functions.
It is not need any addition
>> currently, i'm using the ondemand governor. My CPU supports the
>> frequencies 800, 1800 and 2000 MHz (AMD Athlon64 Desktop with
>> Cool&Quiet). The simple bash commands
>>
>
> In my case, I have a Pentium M 1.8ghz 400 FSB. In powersave, it goes to
> 1.19ghz, in conservative, it goes to 1.20GH
Sven Köhler wrote:
Hi,
currently, i'm using the ondemand governor. My CPU supports the
frequencies 800, 1800 and 2000 MHz (AMD Athlon64 Desktop with
Cool&Quiet). The simple bash commands
In my case, I have a Pentium M 1.8ghz 400 FSB. In powersave, it goes to
1.19ghz, in conservative, it go
On 7/23/05, Trond Myklebust <[EMAIL PROTECTED]> wrote:
> I beg to disagree. A lot of these VPN solutions are unfriendly to MTU
> path discovery over UDP. Sun uses TCP by default when mounting NFS
> partitions. Have you tried this on your Linux box?
I changed the protocol to TCP and changed rsize
If the automount daemon receives a signal which causes it to sumarily
terminate the autofs4 module leaks dentries. The same problem exists with
detached mount requests without the warning.
This patch cleans these dentries at umount.
Signed-off-by: Ian Kent <[EMAIL PROTECTED]>
diff -Nurp linux
On Sat, 23 Jul 2005, Oliver Neukum wrote:
> Am Freitag, 22. Juli 2005 18:38 schrieb Lasse Kärkkäinen / Tronic:
> > > Supermount is obsolete there are other tools in userspace that do the
> > > job perfectly.
> > > e.g ivman which uses hal and dbus.
> >
> > They cannot mount on demand, thus cannot
On Sat, 23 Jul 2005, Lasse K??rkk??inen / Tronic wrote:
> > To mount on demand use autofs. Unmounting and dealing with media removal
> > is the problem.
>
> Granted, that can get pretty close. However, having to use /auto/*
> instead of mounting directly where required often limits using it quite
It is with distinct lack of pride that I release version 0.1 of diskstat
'Geeks in Black Thorn', a tool that allows you to generate the kinds of
graphs as presented in my OLS talk 'On faster application startup times:
Cache stuffing, seek profiling, adaptive preloading'. The lack of pride is
becaus
On Mon, 11 Jul 2005, Theodore Ts'o wrote:
>
> According to the Single Unix Specification V3, all functions that
> return EINTR are supposed to restart if a process receives a signal
> where signal handler has been installed with the SA_RESTART flag.
That can't be right.
Some operations, like
Andrew McDonald wrote:
Take account of whether a socket is bound to a particular device when
selecting an IPv6 raw socket to receive a packet. Also perform this
check when receiving IPv6 packets with router alert options.
I guess this one makes sense on top.
[IPV4/6]: Check if packet was actua
This patch moves #define from cx88-dvb.c and saa7134-dvb.c into Makefile
as CFLAGS, allowing code compatability with video4linux cvs.
Signed-off-by: Michael Krufky <[EMAIL PROTECTED]>
linux/drivers/media/video/cx88/Makefile | 12
linux/drivers/media/video/cx88/cx88-dvb.c
This patch adds a missing #ifdef to saa7134-dvb.c
(thanks to Mauro Carvalho Chehab)
and changes #if to #ifdef in both files.
Signed-off-by: Michael Krufky <[EMAIL PROTECTED]>
linux/drivers/media/video/cx88/cx88-dvb.c | 24
linux/drivers/media/video/saa7134/saa7134-dvb.
On 7/24/05, randy_dunlap <[EMAIL PROTECTED]> wrote:
> On Fri, 15 Jul 2005 05:46:44 +0200 Jesper Juhl wrote:
>
> > +static int __init jiffies_increment_setup(char *str)
> > +{
> > + printk(KERN_NOTICE "setting up jiffies_increment : ");
> > + if (str) {
> > + printk("kernel_hz =
On Fri, 15 Jul 2005 05:46:44 +0200 Jesper Juhl wrote:
> +static int __init jiffies_increment_setup(char *str)
> +{
> + printk(KERN_NOTICE "setting up jiffies_increment : ");
> + if (str) {
> + printk("kernel_hz = %s, ", str);
> + } else {
> + printk("kernel_hz i
hi
the patch is wrong. yenta_request_irq() registers the wrong handler.
plus yenta_probe_cb_irq() has nothing to do with suspend/resume
(besides it frees the irq in the very same function). correct patch below.
somebody cares to explain me why the free_irq() is necessary before
a suspend?
rgds
-
On Sat, 16 Jul 2005 23:55:17 -0400 Lee Revell wrote:
> On Sat, 2005-07-16 at 19:35 -0700, Nish Aravamudan wrote:
> > As you've seen, I think it depends on the timesource: for the PIT, it
> > would be arch/i386/kernel/timers/timer_pit.c::setup_pit_timer().
>
> That one looks pretty straightforwar
Neil,
The best way I can think to do that is take a look at /proc/slabinfo. That will
likely give you a pointer to which area of code is eating up your memory.
OK. I will monitor the /proc/slabinfo file.
Based on the sysrq-m info you posted it looks like due to fragmentation the
largest c
.
> >
> > What if some other driver is sharing the IRQ, and requires IRQs to be
> > enabled for the resume to complete?
All drivers re-enable IRQs on their way back up in their resume code,
they shouldn't be doing anything before that point..
> This certainly is the case on many laptops.
Well at
>
> For Intel at least the recommendation is to use the BIOS "save
> mode"/"restore mode" interface.
I'm going to see about implementing that on my PC when I get back to
home, it doesn't seem like too bad an idea either...
We are also going to provide some hooks out to userspace as well.. but
I'
This patch adds alternative_output() for altinstructions that
have output. Only one output is allowed.
It also cleans up the comments for alternative_input().
With this patch in place, I cleaned up the i387 save/restore in
my local copy so it now looks like this:
==
CONFIG_DEBUG_FS=y and CONFIG_SYSFS=n results in the following compile
error:
<-- snip -->
...
LD vmlinux
fs/built-in.o: In function `debugfs_init':
inode.c:(.init.text+0x31be): undefined reference to `kernel_subsys'
make: *** [vmlinux] Error 1
<-- snip -->
Signed-off-by: Adrian Bun
Hi, Jesper,
RE:
> > 2. how can one tune it (for 2.6.*)?
>
> For some archs the page size can be set at compile-time with
> CONFIG_PAGE_SIZE_4KB, CONFIG_PAGE_SIZE_8KB etc - mips is an example of
> such an arch (also take a look at CONFIG_HUGETLB_PAGE and friends).
OK, now i figured it out. On AMD
This patch contains the most trivial from Rusty's trivial patches:
- spelling fixes
- remove duplicate includes
I don't see a reason why they shouldn't be merged now.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
Documentation/mono.txt |2 +-
Documentation/pci.txt
CONFIG_FB_INTEL=y and CONFIG_HW_CONSOLE results in the following compile
error:
<-- snip -->
...
LD vmlinux
drivers/built-in.o: In function `intelfb_pci_register':
intelfbdrv.c:(.text+0x171960): undefined reference to `color_table'
intelfbdrv.c:(.text+0x171971): undefined reference to `
CONFIG_SECURITY=y and CONFIG_SYSFS=n results in the following compile
error:
<-- snip -->
...
LD vmlinux
security/built-in.o: In function `securityfs_init':
inode.c:(.init.text+0x1c2): undefined reference to `kernel_subsys'
make: *** [vmlinux] Error 1
<-- snip -->
Signed-off-by: Ad
This patch contains the following possible cleanups:
- make needlessly global code static
- #if 0 the following unused global function:
- xfrm4_state.c: xfrm4_state_fini
- remove the following unneeded EXPORT_SYMBOL's:
- ip_output.c: ip_finish_output
- ip_output.c: sysctl_ip_default_ttl
- f
CONFIG_DLM=y and CONFIG_SYSFS=n results in the following compile error:
<-- snip -->
...
LD vmlinux
drivers/built-in.o:(.data+0x271e80): undefined reference to `kernel_subsys'
make: *** [vmlinux] Error 1
<-- snip -->
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.13-r
I submit that sparse switch jump table's are not an "unusual" construct in
the Linux kernel/drivers. GCC only creates a table large enough to cover
the largest of the sparse values - it doesn't have to be 0...255. 0...60
with 10 values sparsely scattered would generate a 61 element jump table.
T
Hi,
currently, i'm using the ondemand governor. My CPU supports the
frequencies 800, 1800 and 2000 MHz (AMD Athlon64 Desktop with
Cool&Quiet). The simple bash commands
while true
do
true
done
cause 100% CPU usage, and the CPU immediatly switched from 800 to 2000MHz.
Using the conserva
On 22 Jul, Adrian Bunk wrote:
> drivers/ieee1394/sbp2.c:202:5: warning: "CONFIG_IEEE1394_SBP2_DEBUG" is not
> defined
> drivers/ieee1394/sbp2.c:207:7: warning: "CONFIG_IEEE1394_SBP2_DEBUG" is not
> defined
> drivers/ieee1394/sbp2.c:2053:6: warning: "CONFIG_IEEE1394_SBP2_DEBUG" is not
> defined
>
On Sat, Jul 23 2005, Peter Osterlund wrote:
> Jens Axboe <[EMAIL PROTECTED]> writes:
>
> > Dunno why I didn't notice before, but ->bi_set is totally unnecessary
> > bloat of struct bio. Just define a proper destructor for the bio and it
> > already knows what bio_set it belongs too.
>
> This caus
Hi,
On Sat, 23 Jul 2005, Nishanth Aravamudan wrote:
> > What's wrong with just:
> >
> >
> > schedule_timeout_{,un}interruptible(msecs_to_jiffies(some_constant_msecs));
>
> Nothing, I suppose. I just prefer directly using msecs. I understand
> your point more now, I think. You are worried a
Hi,
On Sat, 23 Jul 2005, Nishanth Aravamudan wrote:
> > Jiffies are the basic time unit for kernel timers, hiding that fact gives
> > users only wrong expectations about them.
>
> We already have msleep() and msleep_interruptible(), which hide jiffies
> in milliseconds. These interfaces are the
Hi,
> When a driver calls pcmcia_request_irq with IRQ_HANDLE_PRESENT unset, it looks
> for an open IRQ by request_irq()ing with a dummy handler and NULL dev_info.
> free_irq uses dev_info as a key for identifying the handler to free among
> those
> sharing an IRQ, so request_irq returns -EINVAL i
On Mon, Jul 18, 2005 at 01:42:16PM -0600, Grant Grundler wrote:
> On Tue, Jul 12, 2005 at 12:21:38AM +0200, Dominik Brodowski wrote:
> > In yenta_socket, we default to using the resource setting of the CardBus
> > bridge. However, this is a PCI-bus-centric view of resources and thus
> > needs to be
I'm currently creating a list of OSS drivers where all the hardware
supported by them is also supported by ALSA. The goal is to schedule
them for removal (except someone tells that for one or more of them ALSA
support is inferior).
The OSS trident driver has 5 different pci_device_id entries.
Jens Axboe <[EMAIL PROTECTED]> writes:
> Dunno why I didn't notice before, but ->bi_set is totally unnecessary
> bloat of struct bio. Just define a proper destructor for the bio and it
> already knows what bio_set it belongs too.
This causes crashes on my computer.
> +void bio_free(struct bio *b
I've posted the original mail to [EMAIL PROTECTED], too.
-
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/
On Sad, 2005-07-23 at 00:17 +0100, Matthew Garrett wrote:
> Dave Airlie <[EMAIL PROTECTED]> wrote:
>
> > At OLS at lot of people were giving out about cards not resuming,
> > so using a patch from Michael Marineau and help from lots of people
> > sitting around in a circle at OLS I've gotten a
On Sad, 2005-07-23 at 14:28 +1200, mdew wrote:
> I'm unable to mount an ext2 drive using the hpt370A raid card.
>
> upon mounting the drive, dmesg will spew these errors..I've tried
> different cables and drive is fine.
> Jul 23 01:30:21 localhost kernel: hdf: dma timeout error: status=0x25
> { D
On Sad, 2005-07-23 at 02:30 -0400, [EMAIL PROTECTED] wrote:
> Larger does not always mean slower. If it did, nobody would implement a
> loop unrolling optimization.
Generally speaking nowdays it does. Almost all loop unrolls are a loss
on PIV.
> ex. Look at how GCC generates jump tables for swit
On Gwe, 2005-07-22 at 22:47 -0400, Bartlomiej Zolnierkiewicz wrote:
> Hi,
>
> Does vanilla kernel 2.6.12 work for you?
> It doesn't contain hpt366 driver update.
Its nothing to do with the driver. Read the trace Bartlomiej
> > Jul 23 01:30:21 localhost kernel: hdf: dma timeout error: status=0x25
Hello,
the tulip driver isn't work out for my ULi M5263 network adapter.
The driver loads and the interface receives packets but it won't
transmit any. Running a packet capture on it shows no outbound packets,
so I guess the driver thinks the card is screwed up and can't transmit.
I have a 939 AX8
Mark Burton <[EMAIL PROTECTED]> writes:
> Hi,
> I'm getting similar results to Nick Warne, in that when my ethernet is
> stressed at all (for instance by NFS), I end up with
> nfs: server. not responding, still trying
> nfs: server OK
>
> With a realtec card, I get errors in /var/spool/me
On 23.07.2005 [19:01:57 +0200], Roman Zippel wrote:
> Hi,
>
> On Sat, 23 Jul 2005, Nishanth Aravamudan wrote:
>
> > set_current_state(TASK_{,UN}INTERRUPTIBLE);
> > schedule_timeout(msecs_to_jiffies(some_constant_msecs));
> >
> > just have an interface that allows
> >
> > schedule_ti
On 23.07.2005 [19:17:37 +0200], Roman Zippel wrote:
> Hi,
>
> On Sat, 23 Jul 2005, Nishanth Aravamudan wrote:
>
> > > Keep the thing as simple as possible and jiffies _are_ simple. Please
> > > show
> > > me the problem, that needs to be fixed.
> >
> > I am not sure why jiffies are any simpler
On Fri, Jul 22, 2005 at 10:33:21PM +0200, bert hubert wrote:
> On Fri, Jul 22, 2005 at 01:01:32PM -0700, Paul Jackson wrote:
> > Another vote in favor of relayfs here ...
>
> At OLS the 'SystemTAP' idea was presented, which has been partially
> implemented already, and it builds on relayfs as well
On Fri, Jul 22, 2005 at 01:01:32PM -0700, Paul Jackson wrote:
> Another vote in favor of relayfs here ...
>
> I am reminded by my good colleagues at SGI that relayfs is a key
> to the Linux Trace Toolkit (LTT), which is in turn an important
> technology for some product(s) on which SGI is working.
On Fri, Jul 22, 2005 at 08:23:19PM -0300, Márcio Oliveira wrote:
> >
> Roger, thanks for the information.
>
> I'm using Update 4 kernels (2.4.21-27.ELsmp - This kernel have some
> mm / oom fixes) and don't have big problems when create large files,
> plus the server is a 32-bit machine.
>
>
On Sat, 23 Jul 2005, Arjan van de Ven wrote:
>
> For the kernel the runtime measurement is obviously tricky (kgprof
> anyone?)
Ehh, doesn't "opgprof" do that already?
Anyway, judging by real life, people just don't _do_ profile runs. Any
build automation that depends on the user profiling the
Take account of whether a socket is bound to a particular device when
selecting an IPv6 raw socket to receive a packet. Also perform this
check when receiving IPv6 packets with router alert options.
Signed-off-by: Andrew McDonald <[EMAIL PROTECTED]>
diff -uprN linux-2.6.13-rc3.orig/include/net/ra
On Sat, 2005-07-23 at 10:38 -0700, Linus Torvalds wrote:
> So maybe a few hints to the binutils people might just make them go: "try
> this patch/cmdline flag", and solve many more problems. They likely have a
> lot of this kind of code _already_, or have at least been thinking about
> it.
>
>
On Sat, 23 Jul 2005, Chuck Ebbert wrote:
>
> This patch (may not apply cleanly to unpatched -rc3) drops overhead
> a few more percent:
That really is pretty ugly.
I'd rather hope for something like function-sections to just make games
like this be unnecessary. The linker really should be able
> To mount on demand use autofs. Unmounting and dealing with media removal
> is the problem.
Granted, that can get pretty close. However, having to use /auto/*
instead of mounting directly where required often limits using it quite
a bit. Thus, I don't see it as a real alternative.
- Tronic -
s
On Sat, 23 Jul 2005, Chuck Ebbert wrote:
>
>Probably a very minor point, but shouldn't it be
>
> "m" ((tsk)->thread.i387.fxsave))
>
> because that's the largest possible operand that could end up being read?
Yes, I ended up fixing that already (along with handling
Lee Revell wrote:
> On Sat, 2005-07-23 at 13:42 +0200, Andreas Steinmetz wrote:
>
>>RLIMIT_RTPRIO is supposed to grant non privileged users the right to use
>>SCHED_FIFO/SCHED_RR scheduling policies with priorites bounded by the
>>RLIMIT_RTPRIO value via sched_setscheduler(). This is usually used
Hi,
On Thursday, 21 of July 2005 21:20, Pavel Machek wrote:
> hi!
>
> > >>I'd like to get this tested under as many configurations as
> > >>possible. With this, your hdd should no longer do "yoyo" (spindown,
> > >>spinup, spindown) during suspend...
> > >
> > >
> > >It looks like the patch is now
Hi,
On Sat, 23 Jul 2005, Nishanth Aravamudan wrote:
> > Keep the thing as simple as possible and jiffies _are_ simple. Please show
> > me the problem, that needs to be fixed.
>
> I am not sure why jiffies are any simpler than milliseconds. In the
> millisecond case, conversion happens in common
On Sat, 2005-07-23 at 13:42 +0200, Andreas Steinmetz wrote:
> RLIMIT_RTPRIO is supposed to grant non privileged users the right to use
> SCHED_FIFO/SCHED_RR scheduling policies with priorites bounded by the
> RLIMIT_RTPRIO value via sched_setscheduler(). This is usually used by
> audio users.
>
> U
This patch fixes the following compile error with CONFIG_PROC_FS=n:
<-- snip -->
...
CC sound/core/memalloc.o
sound/core/memalloc.c: In function 'snd_mem_exit':
sound/core/memalloc.c:657: error: 'snd_mem_proc' undeclared (first use in this
function)
sound/core/memalloc.c:657: error: (Ea
On Sun, Jun 26, 2005 at 07:00:13PM -0400, Jeff Garzik wrote:
> randy_dunlap wrote:
> >On Sun, 26 Jun 2005 18:26:49 -0400 Jeff Garzik wrote:
> >
> >| Adrian Bunk wrote:
> >| > This patch contains the following cleanups:
> >| > - dmascc.c: remove the unused global function dmascc_setup
> >|
> >| Bet
Hi,
On Sat, 23 Jul 2005, Nishanth Aravamudan wrote:
> set_current_state(TASK_{,UN}INTERRUPTIBLE);
> schedule_timeout(msecs_to_jiffies(some_constant_msecs));
>
> just have an interface that allows
>
> schedule_timeout_msecs_{,un}interruptible(some_constant_msecs);
>
> and push
On Tue, Jul 19, 2005 at 10:50:53PM +0200, Bodo Eggert wrote:
> On Tue, 19 Jul 2005, Adrian Bunk wrote:
> > On Sun, Jul 17, 2005 at 05:07:48PM +0200, Bodo Eggert wrote:
>
> > > In sound/isa/Kconfig, select ISAPNP and depend on ISAPNP are intermixed,
> > > resulting in funny behaviour. (Soundcarts
On Sat, 2005-07-23 at 19:05 +1000, Con Kolivas wrote:
> Indeed, and the purpose of the benchmark is to quantify something rather than
> leave it to subjective feeling. Fortunately if I was to quantify the current
> kernel's situation I would say everything is fine.
Agreed. Unfortunately everyth
On 23.07.2005 [15:29:42 +0200], Roman Zippel wrote:
> Hi,
>
> On Sat, 23 Jul 2005, Arjan van de Ven wrote:
>
> > jiffies/HZ is the more powerful API. The msec one which also sets
> > current to (un)interruptible is the simplified wrapper on top.
>
> So why do you want to hide it? Make the jiffie
On 23.07.2005 [15:04:44 +0200], Roman Zippel wrote:
> Hi,
>
> On Sat, 23 Jul 2005, Arjan van de Ven wrote:
>
> > > > > What's wrong with using jiffies?
> > > >
> > > > A lot of the (driver) users want a wallclock based timeout. For that,
> > > > miliseconds is a more obvious API with less chanc
On 23.07.2005 [13:55:58 +0200], Roman Zippel wrote:
> Hi,
>
> On Sat, 23 Jul 2005, Arjan van de Ven wrote:
>
> > > What's wrong with using jiffies?
> >
> > A lot of the (driver) users want a wallclock based timeout. For that,
> > miliseconds is a more obvious API with less chance to get the jif
On 23.07.2005 [12:50:45 +0200], Roman Zippel wrote:
> Hi,
>
> On Fri, 22 Jul 2005, Arjan van de Ven wrote:
>
> > Also I'd rather not add the non-msec ones... either you're raw and use
> > HZ, or you are "cooked" and use the msec variant.. I dont' see the point
> > of adding an "in the middle" one
On 23.07.2005 [12:30:00 +1000], Andrew Morton wrote:
> Nishanth Aravamudan <[EMAIL PROTECTED]> wrote:
> >
> >
> > +/*
> > + * schedule_timeout_msecs - sleep until timeout
> > + * @timeout_msecs: timeout value in milliseconds
> > + *
> > + * A human-time (but otherwise identical) alternative to
> >
Francois Pepin <[EMAIL PROTECTED]> writes:
> Hi,
>
> I am getting pseudo-random kernel oops on my Opteron box (Tyan Thunder
> K8W) with 4Gb RAM. I am running RedHad FC3 with kernel
> 2.6.11-1.35_FC3smp.
>
> It runs well with default BIOS settings, but only 3.5Gb RAM are visible.
> Using the "Sof
on den 20.07.2005 Klokka 18:56 (-0400) skreiv Timothy Miller:
> My research suggests that NFS client mounting is kernel-based, so
> that's why I'm posting here. If there's a more appropriate list to
> post to, I apologise, but I am not a list member.
>
> I'm having a bit of a problem doing simple
On Sat, Jul 23, 2005 at 11:30:07AM +0530, Amit S. Kale wrote:
>
> We started it from 2.6.7 last year and then it was sitting idle for several
> months for lack of resources. We'll go back to that version and generate a
> diff that's easier to read.
>
> Yes, changing the name has made the task o
Hi,
On Sat, 23 Jul 2005, Arjan van de Ven wrote:
> > > jiffies/HZ is the more powerful API. The msec one which also sets
> > > current to (un)interruptible is the simplified wrapper on top.
> >
> > So why do you want to hide it?
>
> I don't want to hide it at all. I want to provide a simpler v
hi
since i'm the one that put that code there in the first place i guess
i have to comment on it :)
the attached patch should also fix your problem. and it cleans up the
magic numbers a bit.
rgds
-daniel
-
[PATCH] disable read prefetch/write burst on old O2Micro bridges
older O2Mi
On 7/23/05, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> On 7/23/05, cengizkirli <[EMAIL PROTECTED]> wrote:
> > distro: Debian Unstable
> > kernels tested with: 2.6.13-rc3, 2.6.13-rc3-git5, 2.6.13-rc3-mm1
> > compiler used: Debian gcc-4.0.1-2
> > Xorg: Debian xorg-6.8.2-4
> > ASUS P4C800 Deluxe BIOS: 1
> > if CKRM is just extensions, I think it should be an external patch.
> > if it provides a path towards unifying the many disparate RM mechanisms
> > already in the kernel, great!
>
> OK, so if it provides a path towards unifying these, what should happen
> to the old interfaces when they confli
On Sat, 23 Jul 2005, [koi8-r] ? ? wrote:
> The letter itself is in an attached file.
Run memtest, it sounds like you have failing hardware.
On Sat, 23 Jul 2005, Russell King wrote:
> On Sat, Jul 23, 2005 at 02:29:24AM +0200, Pavel Machek wrote:
> > > Is it necessary to do free_irq for suspend? Shouldn't disable_irq
> > > be enough?
> >
> > Due to recent changes in ACPI, yes, it is neccessary.
>
> What if some other driver is sharing
On 7/23/05, cengizkirli <[EMAIL PROTECTED]> wrote:
> distro: Debian Unstable
> kernels tested with: 2.6.13-rc3, 2.6.13-rc3-git5, 2.6.13-rc3-mm1
> compiler used: Debian gcc-4.0.1-2
> Xorg: Debian xorg-6.8.2-4
> ASUS P4C800 Deluxe BIOS: 1019 (2005-11-08)
>
> with or wihout ACPI enabled (acpi=off or
Andrew Morton <[EMAIL PROTECTED]> writes:
>
> We do have the `used_math' optimisation in there which attempts to avoid
> doing the FP save/restore if the app isn't actually using math. But
> there's code in glibc startup which always does a
> bit of float, so that optimisation is always defeated
christos gentsis skrev:
so if i want to play with and see what happens i have to change it
manually in each make file... good i may create a kernel like that to
see what will happens (just for test) ;)
thanks
Chris
Just edit the top level Makefile and add your custom CFLAGS there. But
you
Hi!
> > This adds support for touchscreen on Sharp Zaurus sl-5500. Vojtech,
> > please apply,
>
> I have couple more commnets...
Sorry, I never really worked with kthreads. Applied all those,
> > +static int ucb1x00_ts_open(struct input_dev *idev)
> > +{
> > + struct ucb1x00_ts *ts = (struct
On Sat, 2005-07-23 at 15:29 +0200, Roman Zippel wrote:
> Hi,
>
> On Sat, 23 Jul 2005, Arjan van de Ven wrote:
>
> > jiffies/HZ is the more powerful API. The msec one which also sets
> > current to (un)interruptible is the simplified wrapper on top.
>
> So why do you want to hide it?
I don't wa
Hi,
On Sat, 23 Jul 2005, Arjan van de Ven wrote:
> jiffies/HZ is the more powerful API. The msec one which also sets
> current to (un)interruptible is the simplified wrapper on top.
So why do you want to hide it? Make the jiffies based API the primary one
and add some convenience functions, whe
This adds support for touchscreen on Sharp Zaurus sl-5500. Please
apply,
Pavel
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
diff --git a/drivers/input/touchscreen/Kconfig
b/drivers/input/touchscreen/Kconfig
--- a/drivers/input/touchscre
On Sat, 2005-07-23 at 15:04 +0200, Roman Zippel wrote:
> Hi,
>
> On Sat, 23 Jul 2005, Arjan van de Ven wrote:
>
> > > > > What's wrong with using jiffies?
> > > >
> > > > A lot of the (driver) users want a wallclock based timeout. For that,
> > > > miliseconds is a more obvious API with less ch
Hi,
On Sat, 23 Jul 2005, Arjan van de Ven wrote:
> > > > What's wrong with using jiffies?
> > >
> > > A lot of the (driver) users want a wallclock based timeout. For that,
> > > miliseconds is a more obvious API with less chance to get the jiffies/HZ
> > > conversion wrong by the driver writer.
On Sat, 2005-07-23 at 13:55 +0200, Roman Zippel wrote:
> Hi,
>
> On Sat, 23 Jul 2005, Arjan van de Ven wrote:
>
> > > What's wrong with using jiffies?
> >
> > A lot of the (driver) users want a wallclock based timeout. For that,
> > miliseconds is a more obvious API with less chance to get the
On Saturday 23 July 2005 14:35, Jan De Luyck wrote:
> Hello,
>
> I recently tried out dyntick 050610-1 against 2.6.12.3, works great, it
> actually makes a noticeable difference on my laptop's battery life. I don't
> have hard numbers, lets just say that instead of the usual ~3 hours i get
> out of
Hello,
I recently tried out dyntick 050610-1 against 2.6.12.3, works great, it
actually makes a noticeable difference on my laptop's battery life. I don't
have hard numbers, lets just say that instead of the usual ~3 hours i get out
of it, i was ~4 before it started nagging, usual use pattern a
On Saturday 23 July 2005 00:43, John Pearson wrote:
> Wouldn't having (practically) all your memory used for cache slow down
> starting a new program? First it would have to free up that space, and then
> put stuff in that space, taking potentially twice as long. I think there
> should be a system
On Sat, Jul 23, 2005 at 11:50:43PM +1200, mdew wrote:
> looks like 2.6.12 does the same sort of thing..
>
As a data-point, my dual HPT374 controllers are fine with
2.6.13-rc3-mm1. One onboard, one in a pci-slot in an Epox 4PCA3+ (socket
478, i875 chipset) motherboard.
Linux adsl-gate 2.6.13-rc3-m
Hi,
On Sat, 23 Jul 2005, Arjan van de Ven wrote:
> > What's wrong with using jiffies?
>
> A lot of the (driver) users want a wallclock based timeout. For that,
> miliseconds is a more obvious API with less chance to get the jiffies/HZ
> conversion wrong by the driver writer.
We have helper fun
looks like 2.6.12 does the same sort of thing..
On 7/23/05, Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Does vanilla kernel 2.6.12 work for you?
> It doesn't contain hpt366 driver update.
>
> Bartlomiej
>
> On 7/22/05, mdew <[EMAIL PROTECTED]> wrote:
> > I'm unable to mount
RLIMIT_RTPRIO is supposed to grant non privileged users the right to use
SCHED_FIFO/SCHED_RR scheduling policies with priorites bounded by the
RLIMIT_RTPRIO value via sched_setscheduler(). This is usually used by
audio users.
Unfortunately this is broken in 2.6.13rc3 as you can see in the excerpt
On Sat, 2005-07-23 at 12:50 +0200, Roman Zippel wrote:
> Hi,
>
> On Fri, 22 Jul 2005, Arjan van de Ven wrote:
>
> > Also I'd rather not add the non-msec ones... either you're raw and use
> > HZ, or you are "cooked" and use the msec variant.. I dont' see the point
> > of adding an "in the middle"
1 - 100 of 115 matches
Mail list logo
