Interbench is a benchmarking application designed to emulate the CPU
scheduling behavior of interactive tasks and measure their scheduling latency
and jitter. It does this first with the tasks on their own and then in the
presence of various background loads.
Homepage:
http://interbench.kolivas
On Tuesday 19 July 2005 22:40, Stephen Evanchik wrote:
> Dimitry,
>
> I have been receiving a lot of complaints that TrackPoints on
> Synaptics pass-thru ports stopped working with 2.6.12. I retested
> 2.6.9 and 2.6.11-rc3 successfully, I believe 2.6.11.7 may also work
> but that is unconfirmed at
2.6.13-rc3 + kdb (which does not touch udev/hotplug) on IA64 (Altix).
gcc version 3.3.3 (SuSE Linux). Compiled with DEBUG_SLAB,
DEBUG_PREEMPT, DEBUG_SPINLOCK, DEBUG_SPINLOCK_SLEEP, DEBUG_KOBJECT.
There is a use after free somewhere above class_device_attr_show.
<7>fill_kobj_path: path = '/class/
On Tuesday, July 19, 2005 9:12 PM, Matt Domsch wrote:
What you illustrated above is not going to work.
If your doing #ifndef around a function, such as scsi_device_online, it's
not going to compile
when scsi_device_online is already implemented in the kernel tree.
The routine scsi_device_online i
On Wed, 2005-07-20 at 08:16 +1000, Con Kolivas wrote:
> As a data point I went back to a 2.6.10 kernel which predates some
> latency fixes that went into mainline.
>
I think most of the important ones had already gone in by then. It
would be more interesting to compare it with 2.6.8.
Lee
-
To
On Tue, Jul 19, 2005 at 11:48:43PM +0200, Jean Delvare wrote:
> Convert i2c-isa from a dumb i2c_adapter into a pseudo i2c-core for ISA
> hardware monitoring drivers. The isa i2c_adapter is no more registered
> with i2c-core, drivers have to explicitely connect to it using the new
> i2c_isa_{add,del
On Tue, Jul 19, 2005 at 11:45:40PM +0200, Jean Delvare wrote:
> +/* Next four are needed by i2c-isa */
> +EXPORT_SYMBOL(i2c_adapter_dev_release);
> +EXPORT_SYMBOL(i2c_adapter_driver);
> +EXPORT_SYMBOL(i2c_adapter_class);
> +EXPORT_SYMBOL(i2c_bus_type);
EXPORT_SYMBOL_GPL() instead? As these were,
On Sun, Jul 17, 2005 at 02:20:21PM +0200, Andreas Steinmetz wrote:
> from include/linux/kernel.h:
>
> #define ALIGN(x,a) (((x)+(a)-1)&~((a)-1))
>
> from crypto/cipher.c:
>
> unsigned int alignmask = ...
> u8 *src = (u8 *)ALIGN((unsigned long)buffer, alignmask + 1);
The type foolery you suggeste
On Wed, 20 Jul 2005 12:46 pm, Gabriel Devenyi wrote:
> I've been using the the -ck patchset for a very long time, and I recently
> switched to a amd64 arch. I found that while my throughput improved, my
> system responsiveness has "felt" much lower than it did on my old x86
> machine.
>
> Now that
On Tue, 19 Jul 2005 22:12:49 -0500 Matt Domsch <[EMAIL PROTECTED]> wrote:
>
> Sure it does, function names are defined symbols.
>
> I'm doing exactly this in my backport of the openipmi drivers to RHEL4
> and SLES9.
I missed the smiley, right :-)
--
Cheers,
Stephen Rothwell[
On Tue, Jul 19, 2005 at 05:48:26PM -0700, Mark Fasheh wrote:
> For OCFS2 that would mean that an ocfs2_nodemanager would still exist,
> but as a much smaller module sitting on top of 'nodemanager'.
Yep, factoring out the common bits.
> So no port attribute. The OCFS2 network code normally takes p
On Jul 13, 2005, at 21:12:08, [EMAIL PROTECTED] wrote:
I don't think there's a strict 80 column rule anymore. It's 2005...
Think again. There are a lot of people who use 80 column windows so
that we can see two code windows side-by-side.
Agreed. If you're having trouble with width, it's a
Dimitry,
I have been receiving a lot of complaints that TrackPoints on
Synaptics pass-thru ports stopped working with 2.6.12. I retested
2.6.9 and 2.6.11-rc3 successfully, I believe 2.6.11.7 may also work
but that is unconfirmed at this point.
The behavior is always the same .. after sending the
On Tue, Jul 19, 2005 at 05:52:14PM +0200, Lars Marowsky-Bree wrote:
> The nodeid, I thought, was relative to a given DLM namespace, no? This
> concept seems to be missing here, or are you suggesting the nodeid to be
> global across namespaces?
I'm not sure I understand what you mean. A node woul
Clarify the KALLSYMS_ALL help text slightly.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
init/Kconfig |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.13-rc3-mm1-orig/init/Kconfig 2005-07-17 04:40:00.0
+0200
+++ linux-2.6.13-rc3-mm1/init/Kconfig
On Tue, Jul 19, 2005 at 06:07:41PM -0600, Moore, Eric Dean wrote:
> On Tuesday, July 12, 2005 8:17 PM, Matt Domsch wrote:
> > In general, this construct:
> >
> > > > -#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,6))
> > > > -static int inline scsi_device_online(struct scsi_device *sdev)
> > > > -{
The problem in a nutshell is that the tristate `config SCSI_QLA2XXX' does not
have a name and thus does not show up in menuconfig and similar. This coupled
with the fact that it defaults to `y' when config PCI and config SCSI is
selected results in people (like me) who need PCI and SCSI support
I've been using the the -ck patchset for a very long time, and I recently
switched to a amd64 arch. I found that while my throughput improved, my
system responsiveness has "felt" much lower than it did on my old x86
machine.
Now that interbench is around, I have some quantitative results. Attac
Hi.
On Tue, 2005-07-19 at 23:54, Pavel Machek wrote:
> Hi!
>
> > This patch removes the few remaining direct invocations of the
> > refrigerator in 2.6.13-rc3. In drivers/media/video/msp3400.c, it also
> > shifts the call to after the remove_wait_queue; this seems to be the
> > more appropriate p
On Wed, 20 Jul 2005 11:31 am, Jesper Juhl wrote:
> On 7/20/05, Daniel Walker <[EMAIL PROTECTED]> wrote:
> > On Wed, 2005-07-20 at 11:04 +1000, Con Kolivas wrote:
> > > On Wed, 20 Jul 2005 10:23 am, Daniel Walker wrote:
> > > > On Wed, 2005-07-20 at 00:32 +0200, Ingo Molnar wrote:
> > > > > - netwo
On 7/20/05, Daniel Walker <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-07-20 at 11:04 +1000, Con Kolivas wrote:
> > On Wed, 20 Jul 2005 10:23 am, Daniel Walker wrote:
> > > On Wed, 2005-07-20 at 00:32 +0200, Ingo Molnar wrote:
> > > > - networking is another frequent source of latencies - it might ma
On Wed, 2005-07-20 at 11:04 +1000, Con Kolivas wrote:
> On Wed, 20 Jul 2005 10:23 am, Daniel Walker wrote:
> > On Wed, 2005-07-20 at 00:32 +0200, Ingo Molnar wrote:
> > > - networking is another frequent source of latencies - it might make
> > >sense to add a workload doing lots of socket IO.
On Wed, 20 Jul 2005 10:23 am, Daniel Walker wrote:
> On Wed, 2005-07-20 at 00:32 +0200, Ingo Molnar wrote:
> > - networking is another frequent source of latencies - it might make
> >sense to add a workload doing lots of socket IO. (localhost might be
> >enough, but not for everything)
>
>
Hi David,
On Mon, Jul 18, 2005 at 02:15:53PM +0800, David Teigland wrote:
> Some of the comments about the dlm concerned how it's configured (from
> user space.) In particular, there was interest in seeing the dlm and
> ocfs2 use common methods for their configuration.
>
> The first area I'm loo
On 7/19/05, Brian O'Mahoney <[EMAIL PROTECTED]> wrote:
>
> To: unlisted-recipients:; (no To-header on input)
^^^
That's a bad habbit - makes it impossible to send a
proper reply back to all the recipients. LKML is a public list, please
use To: and CC: so it's possible t
On Wed, 2005-07-20 at 00:32 +0200, Ingo Molnar wrote:
>
> - networking is another frequent source of latencies - it might make
>sense to add a workload doing lots of socket IO. (localhost might be
>enough, but not for everything)
The Gnutella test?
Daniel
-
To unsubscribe from this
On Wed, 2005-07-20 at 08:16 +1000, Con Kolivas wrote:
> Interestingly the average latencies are slightly higher (in the miniscule
> <2us
> range), but the maximum latencies are excellently bound to 25us.
>
> The results are quite reproducible.
I would guess that the average latencies are tunab
On Tuesday, July 12, 2005 8:17 PM, Matt Domsch wrote:
> In general, this construct:
>
> > > -#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,6))
> > > -static int inline scsi_device_online(struct scsi_device *sdev)
> > > -{
> > > - return sdev->online;
> > > -}
> > > -#endif
>
> is better tested as:
On 7/19/05, Brian O'Mahoney <[EMAIL PROTECTED]> wrote:
>
> sacrifical system, and, for example NFS mount everything, on
> it from your main box, otherwise use a cheap local disk just
> for your fs stuff
>
> then when you blow it there is no FS damage and you don't need
> to wait for FSCK, or Jour
Am Dienstag, 19. Juli 2005 17:19 schrieb Gene Heskett:
> On Tuesday 19 July 2005 09:57, Ingo Molnar wrote:
> >* Karsten Wiese <[EMAIL PROTECTED]> wrote:
> >> > Found another error:
> >> > the ioapic cache isn't fully initialized in -51-31's
> >> > ioapic_cache_init().
> >>
> >> and another: some N
Move the definitions of i2c_is_isa_client and i2c_is_isa_adapter from
i2c.h to i2c-isa.h. Only hybrid drivers still need them.
include/linux/i2c-isa.h |7 +++
include/linux/i2c.h |7 ---
2 files changed, 7 insertions(+), 7 deletions(-)
--- linux-2.6.13-rc3.orig/include/linux/
there's one problem with the patch: it breaks things that need the low
1MB executable (e.g. APM bios32 calls). It would at a minimum be needed
to exclude the BIOS area in 0xd-0xf.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mes
Kill all uses of i2c_is_isa_adapter except for the hybrid drivers (it87,
lm78, w83781d). The i2c-isa adapter not being registered with the i2c
core anymore, drivers don't have to fear being erroneously attached to
it.
Documentation/i2c/writing-clients | 11 +--
drivers/hwmon/adm1021.c
Kill normal_isa in header files, documentation and all chip drivers, as
it is no more used.
normal_i2c could be renamed to normal, but I decided not to do so at the
moment, so as to limit the number of changes. This might be done later
as part of the i2c_probe/i2c_detect merge.
Documentation/i2c
Kill all isa-related stuff from i2c_detect, it's not used anymore.
This is one major step in the directiom of merging i2c_probe and
i2c_detect. The last obstacle I can think of is the different way forced
addresses work between sensors and non-sensors i2c drivers. I'll deal
with that in a later pa
Call the ISA chip drivers detection function directly instead of relying
on i2c_detect. The net effect is that address lists won't be handled
anymore, but they were mostly useless in the ISA case anyway (pc87360,
smsc47m1, smsc47b397 had already dropped them).
We don't need to handle multiple devi
All ISA hardware monitoring drivers (including hybrid drivers) now have
a hard dependency on i2c-isa, so they must select I2C_ISA. As a result,
CONFIG_I2C_ISA doesn't need to be left visible to the user. The good
thing here is that users will stop complaining that some driver doesn't
work just beca
Etienne Lorrain <[EMAIL PROTECTED]> wrote:
> > I'd like to have a discussion about FAT robustness.
> > Please give your thought, comments and related issues.
> What I would like is to treat completely differently writing to
> FAT (writing to a removeable drive) which need a complete "mount",
>
Jesper Juhl wrote: ...
much useful advice, almost all of which I agree with _BUT_
please do NOT debug kernel mods on your 'main-box', where your
filesystems live. unless you like to live dangerously and make
perfect backups you don't mind spending lots of hours restoring,
unless you want to spe
Convert the 10 ISA hardware monitoring drivers (it87, lm78, pc87360,
sis5595, smsc47b397, smsc47m1, via686a, w83627hf, w83627ehf, w83781d) to
explicitely register with i2c-isa. For hybrid drivers (it87, lm78,
w83781d), we now have two separate instances of i2c_driver, one for the
I2C interface of t
Convert i2c-isa from a dumb i2c_adapter into a pseudo i2c-core for ISA
hardware monitoring drivers. The isa i2c_adapter is no more registered
with i2c-core, drivers have to explicitely connect to it using the new
i2c_isa_{add,del}_driver interface.
At this point, all ISA chip drivers are useless,
Temporarily export a few structures and functions from i2c-core, because
we will soon need them in i2c-isa.
drivers/i2c/i2c-core.c | 14 ++
include/linux/i2c.h|7 +++
2 files changed, 17 insertions(+), 4 deletions(-)
--- linux-2.6.13-rc3.orig/drivers/i2c/i2c-core.c
Hi all,
This is a set of patches for review and comments. The aim is to start
separating a number of hardware monitoring drivers from the i2c
subsystem. Hardware monitoring (or sensors) have a long history of being
registered with the i2c subsystem even when they are not I2C (nor SMBus)
devices. T
randy_dunlap wrote:
Hi,
Someone asked me about a tool like this and I didn't know of one,
so I made this little script.
'patchview' merges a patch file and a source tree to a set of
temporary modified files. This enables better patch (re)viewing
and more viewable context. (hopefully)
Are the
Andreas Steinmetz wrote:
Michal Schmidt wrote:
Does resuming from swsuspend work for anyone with amd64-agp loaded?
On my system when I suspend with amd64-agp loaded, I get a spontaneous
reboot on resume. It reboots immediately after reading the saved image
from disk.
This is 100% reproducible.
Andi Kleen wrote:
> I personally wouldn't like doing this NX cleanup very late like you did but
> instead directly after the early NX setup.
I've thought about it more, and come up with another patch. All it does is
sets up the PTEs correctly from the beginning, breaking up large pages if
neces
From: Adrian Bunk <[EMAIL PROTECTED]>
Date: Tue, 19 Jul 2005 20:29:19 +0200
> NETCONSOLE=y and INET=n results in the following compile error:
Also applied, thanks Adrian.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More m
Michal Schmidt wrote:
> Hello,
>
> Does resuming from swsuspend work for anyone with amd64-agp loaded?
>
> On my system when I suspend with amd64-agp loaded, I get a spontaneous
> reboot on resume. It reboots immediately after reading the saved image
> from disk.
> This is 100% reproducible.
>
>
From: Adrian Bunk <[EMAIL PROTECTED]>
Date: Tue, 19 Jul 2005 15:55:29 +0200
> BRIDGE_EBT_ARPREPLY=y and INET=n results in the following compile error:
Applied, thanks Adrian.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Mo
Hello,
Does resuming from swsuspend work for anyone with amd64-agp loaded?
On my system when I suspend with amd64-agp loaded, I get a spontaneous
reboot on resume. It reboots immediately after reading the saved image
from disk.
This is 100% reproducible.
Athlon 64 FX-53, Asus A8V Deluxe, Lin
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 get selectable if other
> > soundcards are selected).
> >
> > This pa
On Tue, Jul 19, 2005 at 04:16:55PM -0400, Lee Revell wrote:
> On Tue, 2005-07-19 at 15:29 -0400, Greg KH wrote:
> > Ugh, you have a bad device or power supply, or aren't giving it enough
> > power to drive the thing. Nothing we can do in Linux for that, sorry.
> > Buy a wall-powered usb hub, that
On Tue, 2005-07-19 at 21:21 +0200, Pavel Machek wrote:
> Hi!
>
> > ...and that's well known; but now I did some back tracking, and
> > 2.6.12-rc1 works, 2.6.12-rc2 does *not* and 2.6.12-rc2 with arm
> > changes reverted works. I'll play a bit more.
>
> This fixes at least one break-the-boot bug i
>Hi,
>
>Someone asked me about a tool like this and I didn't know of one,
>so I made this little script.
>
>'patchview' merges a patch file and a source tree to a set of
>temporary modified files. This enables better patch (re)viewing
>and more viewable context. (hopefully)
>
>Are there already o
On Tue, 2005-07-19 at 22:15 +0200, Jan Engelhardt wrote:
> >AFAIK it's not possible to use SSE and MME in kernel mode, since these
> >registers aren't preserved (it would be expensive).
>
> Floating point is anyway a no-no in the kernel.
However, there are a few exceptions like mmx_memcpy.
Lee
On Tue, 2005-07-19 at 15:29 -0400, Greg KH wrote:
> Ugh, you have a bad device or power supply, or aren't giving it enough
> power to drive the thing. Nothing we can do in Linux for that, sorry.
> Buy a wall-powered usb hub, that usually helps.
>
I get the same messages on boot from a bus with n
>AFAIK it's not possible to use SSE and MME in kernel mode, since these
>registers aren't preserved (it would be expensive).
Floating point is anyway a no-no in the kernel.
Jan Engelhardt
--
| Alphagate Systems, http://alphagate.hopto.org/
-
To unsubscribe from this list: send the line "unsu
Ivan Yosifov <[EMAIL PROTECTED]> wrote:
> -march implies -mtune and also implies thing like -msse2 for the
> instruction set where applicable.
> I think -march=pentium4 is equivalent to -mmmx -msse -msse2
> -mtune=pentium4 ( if I have not fogotten anything ).
> Pentium4 supports things like sse2 a
Hi,
On 7/12/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > OK, please let us know how it goes.
>
> It went very well. I could find no problems at all.
> I've updated my script to use the new method, so please merge smaps :)
> http://www.pixelbeat.org/scripts/ps_mem.py
On Tue, Jul 19, 2005 at 11:51:03AM -0700, randy_dunlap wrote:
>
> Hi,
>
> Someone asked me about a tool like this and I didn't know of one,
> so I made this little script.
>
> 'patchview' merges a patch file and a source tree to a set of
> temporary modified files. This enables better patch (re
This patch fixes the following compile error with CONFIG_PCI=n:
<-- snip -->
...
CC drivers/pnp/pnpbios/rsparser.o
drivers/pnp/pnpbios/rsparser.c: In function
'pnpbios_parse_allocated_irqresource':
drivers/pnp/pnpbios/rsparser.c:67: error: too many arguments to function
'pcibios_penali
On Tue, Jul 19, 2005 at 03:27:18PM -0400, Karim Yaghmour wrote:
>
> That being said, shouldn't there be a way for the kernel to refuse to
> use this hd if it's not getting enough power. I don't know enough about
> USB to say, but isn't there something more elegant that could be done in
> software?
Greg KH wrote:
> Ugh, you have a bad device or power supply, or aren't giving it enough
> power to drive the thing. Nothing we can do in Linux for that, sorry.
> Buy a wall-powered usb hub, that usually helps.
I have one. I naively thought I could just plug the drive directly to the
laptop witho
On Tue, Jul 19, 2005 at 12:47:32PM -0400, Karim Yaghmour wrote:
>
> I have a usb-attached HD that I use from time to time. When it's connected
> to my desktop through a hub it works flawlessly. When connected to my Dell
> D600 Laptop, however, it sometimes randomly exhibits a loud click (as if the
Hallo, Linux folks!
(first post here)
I am trying to find out whether I can start using dual-core cpus with a
2.4 kernel (Red Hat EL 3).
Three questions below - please answer if you have any insight.
- The first update to EL 4 announced "support" for dual core cpus both
from AMD and Intel, bu
On Tue, 19 Jul 2005 18:24:25 +0200, DervishD <[EMAIL PROTECTED]> wrote:
> I have a new MP3 player, and when I disconnect it from the USB
> port, my logs says:
>
> <30>Jul 19 18:11:05 kernel: usb.c: USB disconnect on device 00:07.3-1
> address 2
> <27>Jul 19 18:11:06 kernel: hub.c: co
Hi!
> ...and that's well known; but now I did some back tracking, and
> 2.6.12-rc1 works, 2.6.12-rc2 does *not* and 2.6.12-rc2 with arm
> changes reverted works. I'll play a bit more.
This fixes at least one break-the-boot bug in -rc2...
Pa
On Mon, Jul 18, 2005 at 02:16:37PM -0700, Pete Zaitcev wrote:
> I think this patch is rather obvious, so maybe I should ask Andrew to
> apply it to -mm for now, to get some testing. Would that help to verify
> it for acceptance?
Your patch is perfectly OK, my NULL check was indeed completely wron
On Tue, Jul 19, 2005 at 09:14:04PM +0200, Jan Blunck wrote:
> >So you can seek to m*+ to access an offset into
> >something at depth m?
> >
>
> Yes.
Hos does that work if offset >= m?
> I disagree. Where is the information value of i_size if we always
> could return 0?
Directories clearly can't
Chris Wedgwood wrote:
So the size you want to reflect is n* i take it? Where
in this case n is 20?
So you can seek to m*+ to access an offset into
something at depth m?
Yes.
The i_size of a directory isn't covered by the POSIX standard. IMO,
it should be possible to seek in the range of i
I am using RHEL4.0-U1 as the distro. Here is the info on gcc version is
3.4.3-22.1
Thanks for your feed-back.
Ananda Krishnan
On Tue, 2005-07-19 at 22:47 +0400, Alexey Dobriyan wrote:
> On Tue, Jul 19, 2005 at 12:53:20PM -0500, V. ANANDA KRISHNAN wrote:
> > This patch takes care of (1) compiler w
On Tue, Jul 19, 2005 at 12:53:20PM -0500, V. ANANDA KRISHNAN wrote:
> This patch takes care of (1) compiler warnings which displays the mixing
> of declarations and code
With what gcc version and what CFLAGS?
> (2) dynamic allocation of major device number
> instead of the static number 253 (3) t
On Tue, 2005-07-19 at 19:52 +0200, Jan Engelhardt wrote:
> >Hello,
> >
> >If I set the CPU type to be amd64 in kernel config, the kernel is built
> >with -march=k8. If I set it to be k6, the kernel is built with
> >-march=k6. If I set the CPU type to be Pentium4, the kernel is built
> >with -march=
On Tue, Jul 19, 2005 at 08:22:26PM +0200, Jan Blunck wrote:
> Since these "arranged" values are also used as the offsets in the
> return dirent IMO it is quite clean.
So the size you want to reflect is n* i take it? Where
in this case n is 20?
So you can seek to m*+ to access an offset into
som
NETCONSOLE=y and INET=n results in the following compile error:
<-- snip -->
...
LD .tmp_vmlinux1
net/built-in.o: In function `netpoll_parse_options':
: undefined reference to `in_aton'
net/built-in.o: In function `netpoll_parse_options':
: undefined reference to `in_aton'
make: *** [.tm
Chris Wedgwood wrote:
I'm using the i_size of directories in my patches. When reading
from a union directory, I'm using the i_size to seek to the right
offset in the union stack.
Ick. That'a a bit of a hack.
Don't think so:
1st dir: [X]
f_pos=0
Hi!
...and that's well known; but now I did some back tracking, and
2.6.12-rc1 works, 2.6.12-rc2 does *not* and 2.6.12-rc2 with arm
changes reverted works. I'll play a bit more.
Pavel
--
Boycott Kodak -- for their patent abuse against Java.
Hi all,
I'm having little hangs while booting with kernels 2.6.12 and 2.6.13-rc1, rc2
and rc3.
It is strange that 2.6.12-rc1 booted ok without hangs.
I saw a post of Alan Cox on rc-1 release notes:
"Old ISA/VESA systems sometimes put tertiary IDE controllers at addresses
0x1e8, 0x168, 0x1
Hi All,
Here is a patch to the jsm driver in the Linux (drivers/serial/jsm).
This patch takes care of (1) compiler warnings which displays the mixing
of declarations and code (2) dynamic allocation of major device number
instead of the static number 253 (3) the version update to reflect the
chang
>Hello,
>
>If I set the CPU type to be amd64 in kernel config, the kernel is built
>with -march=k8. If I set it to be k6, the kernel is built with
>-march=k6. If I set the CPU type to be Pentium4, the kernel is built
>with -march=i686 -mtune=pentium4. Why is not the for-P4 kernel built
>with -march
> I noticed that files_lock is only protected with spin_lock()
> (file_list_lock(),
> include/linux/fs.h). Is it possible that this should be changed to
> spin_lock_irq()) or spin_lock_irqsave()? Or am I misssing something obvious?
I'm probably stabbing in the dark, but I've seen ipt_owner of ne
>Hi All,
>
> I would like to know whether the usage of 253 as major (device) number
>in serial port drivers is restricted in 2.6.x kernels. I am asking this
>question, though the documentation tells the driver developers that 253
>is a reserved major number, 2.6.x Linux kernels can accommodate mo
>http://lkml.org/lkml/2003/5/18/64 (the problem we are having)
>on it's way out. Try running with 'noapic' to see if it's the IOAPIC or
>local APICs (my bet is on the IOAPIC which would be on your motherboard
>chipset)"
I have the same problem, throughout 2.6.11 to 2.6.13-rc1, maybe before.
I
Precise name of the product: PQI mPack P800
The firmware uses a modified version of the Sigma Designs uClinux 2.4.17-uc0
kernel (available here:
http://www.uclinux.org/pub/uClinux/ports/arm/EM8500/). In my previous
encounters with similar devices, they have kept the portions of code that dealt
On Monday 18 July 2005 16:15, David Teigland wrote:
> I've taken a stab at generalizing ocfs2_nodemanager so the dlm could use
> it (removing ocfs-specific stuff). It still needs some work, but I'd
> like to know if this appeals to the ocfs group and to others who were
> interested in seeing some
Hello,
If I set the CPU type to be amd64 in kernel config, the kernel is built
with -march=k8. If I set it to be k6, the kernel is built with
-march=k6. If I set the CPU type to be Pentium4, the kernel is built
with -march=i686 -mtune=pentium4. Why is not the for-P4 kernel built
with -march=pentiu
> I'd like to have a discussion about FAT robustness.
> Please give your thought, comments and related issues.
What I would like is to treat completely differently writing to
FAT (writing to a removeable drive) which need a complete "mount",
and just reading quickly a file (a standard use of r
I have a usb-attached HD that I use from time to time. When it's connected
to my desktop through a hub it works flawlessly. When connected to my Dell
D600 Laptop, however, it sometimes randomly exhibits a loud click (as if the
heads went berzerk) and the device goes unrecognized (i.e. the USB laye
Here's a patch to linux kernel to enable fork() support for
infiniband uverbs (userspace i/o initiator).
Please Cc me with comments.
---
This patch adds PROT_DONTCOPY to mmap and mprotect, to set VM_DONTCOPY on vma.
This is needed for infiniband userspace i/o, where we need to protect against
-
Hello,
I apologize in advance if this is a dummy question. My web search turned
up nothing, so I'm trying it here.
We came across the following error message:
Kernelpanic - not syncing: fs/proc/
Generic.c:521: spin_lock(fs/file_table.c:80420280)
Already locked by fs/file_table.c/204
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 get selectable if other
> soundcards are selected).
>
> This patch changes the "depend on ISAPNP"s to select.
>...
Folgende Nachricht wurde fuer Sie hinterlassen:
Please find below a message for you:
Escibi a [EMAIL PROTECTED] , esta direccion esta en desuso.
Saludos Mariano
--
+++ GMX - die erste Adresse für Mail, Message, More +++
e-mail und supergünstige DSL-Tarife unter http://www.gmx.net
-
To unsubscribe
On 2005-07-18T14:15:53, David Teigland <[EMAIL PROTECTED]> wrote:
> Some of the comments about the dlm concerned how it's configured (from
> user space.) In particular, there was interest in seeing the dlm and
> ocfs2 use common methods for their configuration.
>
> The first area I'm looking at
Am Dienstag, 19. Juli 2005 17:44 schrieb Jiri Slaby:
>Rolf Eike Beer napsal(a):
>>Jiri Slaby wrote:
>>>Kernel version: 2.6.13-rc3-git4
>>>
>>>* This patch removes from kernel tree pci_find_device and changes
>>>it with pci_get_device. Next, it adds pci_dev_put, to decrease reference
>>>count of the
On Tuesday, 19 July 2005, at 04:41:26 -0600,
Eric W. Biederman wrote:
> Thanks. Before I forget I want to ack this. I think you are correct
> and I have a hunch on what might be done to fix this but I haven't found
> the couple of hours needed to handle that.
>
ACK. Just for the record, there s
On Tue, Jul 19, 2005 at 11:28:10AM +0200, Jan Blunck wrote:
> I'm using the i_size of directories in my patches. When reading
> from a union directory, I'm using the i_size to seek to the right
> offset in the union stack.
Ick. That'a a bit of a hack.
> Therefore I need values of dirent->d_off
Rolf Eike Beer napsal(a):
Jiri Slaby wrote:
Kernel version: 2.6.13-rc3-git4
* This patch removes from kernel tree pci_find_device and changes
it with pci_get_device. Next, it adds pci_dev_put, to decrease reference
count of the variable.
* Next, there are some (about 10 or so) gcc warning p
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/messages along the
lines of:
Jul 3 14:31:13 localho
Hi again,
On Fri, 15 Jul 2005 13:09:33 +1000 Stephen Rothwell <[EMAIL PROTECTED]> wrote:
>
> We (Anton Blanchard and others) have been trying to figure out the best
> (or any) way to allow for IOMMU bypass when setting up DMA mappings on
> particular devices. Our current idea is to hang a structu
Hi again,
I have scanned IHC errata for this Rocky stuff.
First, lspi -vvv said that Rocky has 82820.
Hmm... I have a phy look at the card and see 82801.
OK.
I went to the Intel site, and downloaded the spec updates
for it.
http://www.intel.com/design/chipsets/mobile/documentation845.htm#specup
1 - 100 of 151 matches
Mail list logo
