Werner Almesberger <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
> > Something like that.I have yet to see a even a proof of concept
> > of the idea of passing device information, to clean up probes.
>
> Yes, the kexec-based boot loader first, then this. For a
> kexec-based boot
This patch allows to use floppy drive in non-DMA mode on PegasosPPC machines.
To use it:
1. Do not build floppy driver as a module, link it statically. Transferring
parameters to it from insmod is still problematic, at least it doesn't work
properly on my system. May be i'll clean it up in
On Mon, 2005-02-14 at 06:28 +0100, Willy Tarreau wrote:
> Hello Josh,
>
> On Sun, Feb 13, 2005 at 06:23:15PM -0600, Josh Aas wrote:
> > Hello,
> >
> > I have written an introduction to the Linux 2.6.8.1 CPU scheduler
> > implementation. It should help people to understand what is going on in
>
On Sun, 13 Feb 2005, Matthew Jacob wrote:
I'm curious why you'd have a non-compete for 1 year for just using BK.
Larry likes to participate in flamewars on LKML ? :-)
That would make BK more or less unique amongst packages, no?
-
To unsubscribe from this list: send the line "unsubscribe
On Fri, 21 Jan 2005, Catalin(ux aka Dino) BOIE wrote:
I really suggest to push this limit to 4k. My reason is that under UML I need
to put a lot of stuff in command line and uml crash if I not extend this
limit. Can we make it depend on arhitecture?
another nice feature would be the kernel
I'm curious why you'd have a non-compete for 1 year for just using BK.
That would make BK more or less unique amongst packages, no?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Hi all,
Can anyone explain that, how can (void)*reg_addr; generate a read cycle
on the bus.
And Is there any source which clearly explains about setup of DMA and
How to do DMA transfers.
Regards,
Krishna Chaitanya
/*
* The codec register read operation requires 3 read cycles on PXA250 in
order
Eric W. Biederman wrote:
> For detecting devices especially in the case that takes
> a while that isn't something we need to do early
> in the boot process.
Yes, but I'd rather have a generic mechanism that works in all
reasonable cases. Things have a tendency of growing in the oddest
directions.
Hello Josh,
On Sun, Feb 13, 2005 at 06:23:15PM -0600, Josh Aas wrote:
> Hello,
>
> I have written an introduction to the Linux 2.6.8.1 CPU scheduler
> implementation. It should help people to understand what is going on in
> the scheduler code faster than they would be able to by just reading
Ingo Molnar wrote:
> the pro applications will always want to have a 100% guarantee (it
> really sucks to generate a nasty audio click during a live performance)
... and the "generic kernels" distributions use will follow just
as swiftly, as soon as the feature appears stable enough. It even
On Fri, Jan 07, 2005 at 06:39:02PM -0500, Joe Krahn wrote:
> There are apparently several devices that return bad data
> for the REPORT_LUNS query, but do not return an error.
> The newer kernels only do sequential LUN scans if REPORT_LUNS
> fails. There may need to be a kernel option to force
On Thu, 2005-02-10 at 17:16 -0800, Greg KH wrote:
> All distros are trying to reduce boot time.
They certainly aren't all trying very hard. Debian and Fedora (last
time I checked) do not even run the init scripts in parallel.
Lee
-
To unsubscribe from this list: send the line "unsubscribe
Hi Nathan
I can also confirm that this patch resolves an issue I am seeing
with re-aim-7 writing to xfs fs mounted on ramdisk, I was also
getting EAGAIN.
Thanks
Darren
On Thu, 10 Feb 2005, Nathan Scott wrote:
> On Wed, Feb 09, 2005 at 05:44:54PM +0300, Alexander Y. Fomichev wrote:
> > On
This is a heads up that the BK tree for the kernel is currently at 59,000
changesets give or take a few. The BK that you are using uses unsigned
shorts for the internal names of each delta which means you folks are
about 100 days away from things no longer working.
The good news is that the
Currently, in almost every PCI driver, if pci_request_regions() fails --
indicating another driver is using the hardware -- then
pci_disable_device() is called on the error path, disabling a device
that another driver is using
To call this "rather rude" is an understatement :)
Fortunately, the
Konstantin V. Gavrilenko <[EMAIL PROTECTED]> wrote:
> Whoops happened when tried to do
> #ip route del blackhole to xxx.xxx.xxx.xxx
>
> output of dmesg, and lsmod
> EIP is at fib_release_info+0x8b/0xf0
This was fixed in 2.6.10.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu
On Sunday 13 February 2005 19:32, Stephen Evanchik wrote:
> Here is the latest IBM TrackPoint patch. I believe I made all of the
> necessary changes in this release including the removal of the
> middle-to-scroll functionality. One item I didn't address was a
> comment about checking the return
On Sun, Feb 13, 2005 at 07:55:35PM -0500, Lee Revell wrote:
> On Sun, 2005-02-13 at 14:30 +0100, Ingo Molnar wrote:
> > * Philippe Elie <[EMAIL PROTECTED]> wrote:
> >
> > > oprofile_ops.cpu_type == NULL, this has been fixed 3 weeks ago, can
> > > you retry with -rc4 ?
> >
> > i've
On Sun, 2005-02-13 at 14:30 +0100, Ingo Molnar wrote:
> * Philippe Elie <[EMAIL PROTECTED]> wrote:
>
> > oprofile_ops.cpu_type == NULL, this has been fixed 3 weeks ago, can
> > you retry with -rc4 ?
>
> i've uploaded an -rc4 port of the -RT tree half an hour ago (-39-00).
>
OK, I will test
Here is the latest IBM TrackPoint patch. I believe I made all of the
necessary changes in this release including the removal of the
middle-to-scroll functionality. One item I didn't address was a
comment about checking the return code of ps2_command ..
I looked at other usages and it wasn't clear
Whoops happened when tried to do
#ip route del blackhole to xxx.xxx.xxx.xxx
output of dmesg, and lsmod
Unable to handle kernel NULL pointer dereference at virtual address
printing eip:
c031ce3b
*pde =
Oops: 0002 [#1]
PREEMPT
Modules linked in: sch_sfq sch_htb cls_u32 sch_ingress
Hi,
When I run
modprobe parport_pc io=0x378 irq=7
and found
parport_pc: Ignoring new-style parameters in presence of obsolete ones
in dmesg output and of course my paralel port does not use irq.
Have no way to tell parport_pc to use IRQ? With 2.6.8 the above command is fine.
Search the
Hello,
I have written an introduction to the Linux 2.6.8.1 CPU scheduler
implementation. It should help people to understand what is going on in
the scheduler code faster than they would be able to by just reading
through the code. The paper can be downloaded in PDF or LyX form from here:
On Sunday 13 February 2005 14:13, Stephen Evanchik wrote:
> On Thu, 3 Feb 2005 22:52:44 -0500, Dmitry Torokhov
> <[EMAIL PROTECTED]> wrote:
> > OK, I have read the code once again, and saw that you have special
> > handling within PS/2 protocol based on model constant. Please set
> > psmouse type
Jeff Garzik wrote:
Marcelo Tosatti wrote:
On Wed, Feb 09, 2005 at 11:23:42PM -0500, Todd Shetter wrote:
Marcelo Tosatti wrote:
On Wed, Feb 09, 2005 at 03:47:28PM -0500, Todd Shetter wrote:
Running slackware 10 and 10.1, with kernels 2.4.26, 2.4.27,
2.4.28, 2.4.29 with highmem 4GB, and highmem
(null)
-
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 Sat, Feb 12, 2005 at 04:50:23PM +, Christian Heim wrote:
> Well, i have to setup ISDN here at home, and wanted to use both channels.
> I am able to add the second channel, but then the kernel (at least i think)
> starts to complain.
>
> >17:36:22 kraftwerk Badness in local_bh_enable at
Hi,
Having CONFIG_RTC=y, I tried on x86 the rtctest program found in
linux-2.6.10/Documentation/rtc.txt. However, it failed at:
ioctl(fd, RTC_UIE_ON, 0);
with:
ioctl: Inappropriate ioctl for device
Did I miss something? Maybe something else conflicts with CONFIG_RTC?
Cheers.
signature.asc
Hi!
Is there a reason why "PCI access mode" config option isn't available for
x86_64? Due to this, PCIE config options aren't available either.
Piotr Kaczuba
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
From: Kurt Garloff <[EMAIL PROTECTED]>
Subject: Test security_enabled var rather than security_ops pointer
References: 40217, 39439
Rather than doing a pointer comparison, test an integer var
for being null. Should be slightly faster.
I consider this patch as optional.
Note that it does not
From: Kurt Garloff <[EMAIL PROTECTED]>
Subject: Consider the capability case the likely one
References: 40217, 39439
The case that security_ops points to the default capability_
security_ops is the fast path and arguably the more likely one
on most systems. So mark it likely to tell the compiler
From: Kurt Garloff <[EMAIL PROTECTED]>
Subject: Clean LSM stub file
References: 40217, 39439
Rather than having every LSM hook twice, once for the case with
CONFIG_SECURITY enabled and once for the disabled case, put
everything in one inline function. This reduces the chance of
the two to go out
From: Kurt Garloff <[EMAIL PROTECTED]>
Subject: Replace indirect calls by a branch
References: 40217, 39439
In the LSM stub collection, rather do a branch than an indirect
call. Many of the functions called do only return 0 or do nothing
for the default (capability) case.
This is a fast-path
From: Kurt Garloff <[EMAIL PROTECTED]>
Subject: Default to capability rather than dummy if no LSM is loaded
References: 40217, 39439
If a kernel is compiled with CONFIG_SECURITY to enable LSM, the
default behaviour changes unless a user load capability.
This is undesirable. This patch makes
On niedziela 13 luty 2005 17:38, Nix wrote:
---snip---
Applied, thanks. Though I believe CCing such mails to lkml is kind of
pointless.
--
In the year eighty five ten
God is gonna shake his mighty head
He'll either say,
"I'm pleased where man has been"
Or tear it down, and start again
-
To
Hi,
this goes back to a discussion in August last year:
http://www.ussg.iu.edu/hypermail/linux/kernel/0408.1/0623.html
The following patchset addresses three issues of the security.h stub
collection:
* All the functions are implemented twice, once for
CONFIG_SECURITY enabled and once for
See attached for list of changes, BK info, and patch URL.
Recent changes:
* posted patch against 2.6.11-rc4 (see attached)
* incorporated ieee80211 lib code into the wireless-2.6 sub-tree, which
is included in this queue. This code will form the basis of the "Linux
wireless stack". Wireless
A minor update since the last post. Recent changes:
* updated to 2.6.11-rc4, posted patch (see attached).
* turned on ATAPI by default. If you got an S/ATAPI DVD burner for
Christmas, you'll like this.
WARNING DANGER WARNING: Some drivers such as sata_promise and ahci have
not yet been
On Sun, 13 Feb 2005 20:31:49 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
>
> You're right. The IBM trackpoints unfortunately don't have a 'native'
> mode, they always do full processing and send classic PS/2 packets.
>
> I think we shouldn't need a handler, since we can use the PS/2 protocol
Il Sun, Feb 13, 2005 at 06:28:38PM +0100, Marcel Sebek ha scritto:
> > @@ -1164,13 +1164,22 @@
> > current_read_size, *poffset,
> > _read, _read_data);
> >
> > + if (rc == -EAGAIN)
> > +
There was a vmalloc tuning patch made back in September 2004 that reserved
a larger amount of memory for vmalloc. Unfortunately, the patch does not
work properly for modified kernels where the kernel's virtual address
space has been reduced to 512MB or less.
More specifically, if __PAGE_OFFSET
* Seth, Rohit <[EMAIL PROTECTED]> wrote:
> On a little different note, while running the 4G-4G kernel on our
> machine, we saw occasional hangs. Those are root caused to the fact
> that this kernel was first chaging the stack pointer from virtual
> stack to kernel and then changing the CR3 to
Hi all,
The Toshiba Satellite A40 laptop hides its SMBus device, much like a
number of Asus boards reputedly do. This prevents access to the LM90
hardware monitoring chip. This simple patch extends the PCI quirk used
for the Asus and HP systems to this Toshiba laptop.
Please consider for merge
On Sun, Feb 13, 2005 at 02:13:15PM -0500, Stephen Evanchik wrote:
> On Thu, 3 Feb 2005 22:52:44 -0500, Dmitry Torokhov
> <[EMAIL PROTECTED]> wrote:
> > OK, I have read the code once again, and saw that you have special
> > handling within PS/2 protocol based on model constant. Please set
> >
On Sun, Feb 06, 2005 at 08:51:11PM +0100, Frank van Maarseveen wrote:
> While executing
> iptables -t nat -D OUTPUT -d 80.126.170.174 -p tcp --dport https -j DNAT --to
> 192.168.0.1
> iptables -t nat -D OUTPUT -d 80.126.170.174 -p tcp --dport http -j DNAT --to
> 192.168.0.1
still present in
On Thu, 3 Feb 2005 22:52:44 -0500, Dmitry Torokhov
<[EMAIL PROTECTED]> wrote:
> OK, I have read the code once again, and saw that you have special
> handling within PS/2 protocol based on model constant. Please set
> psmouse type to PSMOUSE_TRACKPOINT instead of model and provide full
> protocol
On Sun, Feb 13, 2005 at 02:07:39PM -0500, Stephen Evanchik wrote:
> > > Perhaps this should be done in userspace? It is probably usable on
> > > non-trackpoint devices, too...
> >
> > For a big part it's not possible to do in userspace, because the
> > touchpoint doesn't give the pressure
On Mon, 7 Feb 2005 11:14:17 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> > Perhaps this should be done in userspace? It is probably usable on
> > non-trackpoint devices, too...
>
> For a big part it's not possible to do in userspace, because the
> touchpoint doesn't give the pressure
On Sun, Feb 13, 2005 at 07:14:44PM +0100, Kenan Esau wrote:
> Am Sonntag, den 13.02.2005, 13:01 +0100 schrieb Vojtech Pavlik:
> > On Sun, Feb 13, 2005 at 11:05:00AM +0100, Kenan Esau wrote:
> >
> > > > > This
> > > > > sequence does not always work and there is not something like a "magic
> > >
Hi, William.
On Feb 12 2005, William Park wrote:
> Your 'dmesg' says
> Warning: Secondary channel requires an 80-pin cable for operation.
> I assume it is.
Well, I just finished compiling the 2.6.11-rc4 kernel and the problem
persisted. This time, I enabled ACPI debugging and it indeed
Marcelo Tosatti wrote:
On Wed, Feb 09, 2005 at 11:23:42PM -0500, Todd Shetter wrote:
Marcelo Tosatti wrote:
On Wed, Feb 09, 2005 at 03:47:28PM -0500, Todd Shetter wrote:
Running slackware 10 and 10.1, with kernels 2.4.26, 2.4.27, 2.4.28,
2.4.29 with highmem 4GB, and highmem i/o support enabled,
Am Sonntag, den 13.02.2005, 13:01 +0100 schrieb Vojtech Pavlik:
> On Sun, Feb 13, 2005 at 11:05:00AM +0100, Kenan Esau wrote:
>
> > > > This
> > > > sequence does not always work and there is not something like a "magic
> > > > knock sequence".
> > >
> > > You mean that the only needed bit is
[EMAIL PROTECTED] said:
> Err... FWIW, aforementioned patch lacks e.g. vmlinux.lds.S.
Yeah, I have that fixed locally. I just haven't pushed out the new stuff yet.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Wed, Feb 09, 2005 at 10:40:53AM +, Russell King wrote:
> On Tue, Feb 08, 2005 at 08:05:01PM +, Russell King wrote:
> > On Tue, Feb 08, 2005 at 08:42:43PM +0100, Sam Ravnborg wrote:
> > > On Mon, Feb 07, 2005 at 11:43:59AM +, Russell King wrote:
> > > >
> > > > Maybe we need an
On Sun, Feb 13, 2005 at 04:44:16PM +0100, Luca wrote:
> Linus Torvalds <[EMAIL PROTECTED]> ha scritto:
> > this is hopefully the last -rc kernel before the real 2.6.11, so please
> > give it a whirl, and complain loudly about anything broken.
>
> The following patch against 2.6.11-rc4 fixes this
fix two typos.
Signed-off-by: Olaf Hering <[EMAIL PROTECTED]>
diff -purNx tags ../linux-2.6.11-rc4.orig/Makefile ./Makefile
--- ../linux-2.6.11-rc4.orig/Makefile 2005-02-13 04:06:56.0 +0100
+++ ./Makefile 2005-02-13 16:48:22.0 +0100
@@ -539,7 +539,7 @@ CFLAGS += $(call
On Feb 12 2005, William Park wrote:
> Do you have MSI on by any chance? (CONFIG_PCI_MSI) If so, try kernel
> without it. My motherboard exhibits runaway IRQ with it.
Ok, now I've just downloaded the -rc4 patch and while selecting the options
to compile, I saw what MSI means. No, I didn't have
On Sun, Feb 13, 2005 at 01:12:54PM -0500, Jeff Dike wrote:
> [EMAIL PROTECTED] said:
> > 1. To support a separate build tree for the um/i386 architecture the
> > following changes have been done:
>
> Have a look at
>
>
In iproute2, ip/iptunnel.c says:
#include
#include
#include
#include
Now the original Linux kernel includes byteorder.h as a side-effect of
including netdevice.h, which it does inside a __KERNEL__ ifdef when
if_arp.h is included.
I think it makes more sense to include it in those headers
On Feb 12 2005, William Park wrote:
> On Sat, Feb 12, 2005 at 09:50:43PM -0200, Rog?rio Brito wrote:
> > To prevent the matters of loosing track of what is being done, I only
> > changed one option at a time. I put the dmesg logs of all my attempts
> > at
On Sun, Feb 13, 2005 at 09:22:46AM +0100, Vojtech Pavlik wrote:
> And I suppose it was running just fine without the patch as well?
Correct.
> The question was whether the patch helps, or whether it is not needed.
If you look again at the patch I posted, it only borrowed a few lines
of the
Hi Enrico,
> It is possible to include the SIS5595 chip driver to the final
> release?
No, sorry. It's not even in -mm yet (in fact it's even not in Greg's
bk-i2c tree yet). It needs to spend some time (and get some testing) in
-mm before it can go to Linus.
You are still welcome to get the
Resubmit because of no feedback nor inclusion in the latest changelogs.
I'm not sure wether this patch qualifies for the patch monkey, so I still
omit it.
Changed to apply with -p1 instead of -p0 after reading a unrelated hint on
LKML (maybe this should be mentioned in the SubmittingPatches?)
[EMAIL PROTECTED] said:
> 1. To support a separate build tree for the um/i386 architecture the
> following changes have been done:
Have a look at
http://user-mode-linux.sourceforge.net/work/current/2.6/2.6.11-rc3-mm2/patches/cross-build
That's Al Viro's take on the same problem, plus
Linus Torvalds <[EMAIL PROTECTED]> ha scritto:
> this is hopefully the last -rc kernel before the real 2.6.11, so please
> give it a whirl, and complain loudly about anything broken.
The following patch against 2.6.11-rc4 fixes this compile time warning:
CC [M] fs/cifs/file.o
fs/cifs/file.c:
Linus Torvalds <[EMAIL PROTECTED]> ha scritto:
> this is hopefully the last -rc kernel before the real 2.6.11, so please
> give it a whirl, and complain loudly about anything broken.
The following patch against 2.6.11-rc4 fixes this compile time warning:
fs/cifs/cifssmb.c: In function
On Sun, 2005-02-13 at 13:59 +0100, Ingo Molnar wrote:
> yeah - it's "M" already in fs/proc/array.c, but i missed the sched.c
> case.
>
You also missed the kernel/rt.c case :-)
-- Steve
Index: kernel/rt.c
===
--- kernel/rt.c
Droebbel wrote:
> On recent kernels, writing to DVD-RAM is much slower than to be
> expected. A 3x Writer should do about 1.9MB/s including automatic
> verify. This is what I get with 2.6.7 up to bk7. However, from 2.6.7-bk8
> to 2.6.10 write speed is as low as 600 to 1000 kB/s. The drive's head
>
1. To support a separate build tree for the um/i386 architecture
the following changes have been done:
- fix makefiles to generate new files and to create symlinks in the
'' only
- in particular, to solve the issue of 'arch/um/include/sysdep-',
the same technique as for 'include/asm' has been
On recent kernels, writing to DVD-RAM is much slower than to be
expected. A 3x Writer should do about 1.9MB/s including automatic
verify. This is what I get with 2.6.7 up to bk7. However, from 2.6.7-bk8
to 2.6.10 write speed is as low as 600 to 1000 kB/s. The drive's head
jumps a lot more with
* Philippe Elie <[EMAIL PROTECTED]> wrote:
> oprofile_ops.cpu_type == NULL, this has been fixed 3 weeks ago, can
> you retry with -rc4 ?
i've uploaded an -rc4 port of the -RT tree half an hour ago (-39-00).
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
Linus Torvalds <[EMAIL PROTECTED]> :
[...]
> this is hopefully the last -rc kernel before the real 2.6.11, so please
> give it a whirl, and complain loudly about anything broken.
- dscc4 (patch in Jeff's -netdev)
Apart the fact that the driver crashes on module insertion and is
unusable,
On Sun, 2005-02-13 at 14:16 +0100, Ingo Molnar wrote:
> * Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
> > PS. Ingo: Any plans to move the RT tree to -mm again (would save me
> > time patching; does keep me practised though)?
>
> not at the moment - but you might want to make your port available
* Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> PS. Ingo: Any plans to move the RT tree to -mm again (would save me
> time patching; does keep me practised though)?
not at the moment - but you might want to make your port available to
others?
Ingo
-
To unsubscribe from this list: send
On Sun, 2005-02-13 at 01:07 -0500, Lee Revell wrote:
> Are there any known incompatibilities with oprofile and the RT preempt patch?
non so far for me, I use that combo quite a lot at work. However I do
use the -mm series which might contain oprofile updates not found in
plain -rc.
Kind regards,
* Lee Revell <[EMAIL PROTECTED]> wrote:
> Are there any known incompatibilities with oprofile and the RT preempt
> patch?
not that i know of. Does the same thing work fine with !PREEMPT_RT? (or
the patch unapplied?)
Ingo
-
To unsubscribe from this list: send the line "unsubscribe
On Sun, 13 Feb 2005 at 01:07 +, Lee Revell wrote:
> Are there any known incompatibilities with oprofile and the RT preempt patch?
>
> Lee
>
> Oops: [#1]
> PREEMPT
> alloc
> CPU:0
> EIP:0060:[oprofilefs_str_to_user+21/64]Not tainted VLI
> EFLAGS: 00010246
Hello,
It is possible to include the SIS5595 chip driver to the final release?
EnricoB
-
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
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> Ingo,
>
> Here's a trivial patch to help others from freaking out when they see
> on a show_trace that most of their processes are TASK_UNINTERRUPTIBLE.
thanks, applied it to -39-00.
> - static const char *stat_nam[] = { "R", "S", "D", "T",
On Sun, Feb 13, 2005 at 11:05:00AM +0100, Kenan Esau wrote:
> > > This
> > > sequence does not always work and there is not something like a "magic
> > > knock sequence".
> >
> > You mean that the only needed bit is setting the resolution to '7'?
>
> The lifebook touchscreen has some
On Sun, Feb 13, 2005 at 10:39:46AM +0100, Kenan Esau wrote:
> Am Samstag, den 12.02.2005, 12:46 -0500 schrieb Arjan van de Ven:
> > On Sat, 2005-02-12 at 18:01 +0100, Kenan Esau wrote:
> >
> > > Second thing is that I am not shure that it is a good idea to integrate
> > > the lbtouch-support into
I've just conducted a binary search to see when the SIS drm stopped
working... and it was 2.6.9-rc1-bk1 from looking at it the new virtual
memory layout is the most likely patch to have broken things... I haven't
confirmed it is this particular patch yet, tomorrow I'll get some time to
do it ..
Am Samstag, den 12.02.2005, 12:46 -0500 schrieb Arjan van de Ven:
> On Sat, 2005-02-12 at 18:01 +0100, Kenan Esau wrote:
>
> > Second thing is that I am not shure that it is a good idea to integrate
> > the lbtouch-support into the psmouse-driver since there is no real way
> > of deciding if the
Am Samstag, den 12.02.2005, 19:34 +0100 schrieb Vojtech Pavlik:
> On Sat, Feb 12, 2005 at 06:01:19PM +0100, Kenan Esau wrote:
> > Am Freitag, den 11.02.2005, 21:10 +0100 schrieb Vojtech Pavlik:
> > > Hi!
[...]
> > As far as I can see the
> > init-sequence is the one from Haralds xfree
Hi Maciej,
> Is there any specific reason for the PIIX4 SMBus driver to be
> disabled on 64-bit platforms?
No idea.
> If not, then please apply the following change.
> The MIPS Technologies Malta development board has the 82371EB chip
> and supports 64-bit configurations. I've verified the
Dave Jones wrote:
Was there any differnces in the devices at 00:00.0 and 00:01.0 ?
(host & pci bridges)
Only the Host bridge line c0:
With AGPGART:
00:00.0 Host bridge: nVidia Corporation: Unknown device 00e1 (rev a1)
Subsystem: Micro-Star International Co., Ltd.: Unknown device 0300
On Sun, Feb 13, 2005 at 01:49:10AM -0500, Dmitry Torokhov wrote:
> On Friday 11 February 2005 15:10, Vojtech Pavlik wrote:
> > + if (set_properties) {
> > + psmouse->vendor = "Fujitsu Lifebook";
> > + psmouse->name = "TouchScreen";
> > + }
> > +
> > +
For the m32r architecture, is there a reason not to use the generic bug.h
definition?
Signed-off-by: Daniel Dickman <[EMAIL PROTECTED]>
--- linux-2.6.11-rc4/include/asm-m32r/bug.h 2004-12-24 16:34:01.0
-0500
+++ linux/include/asm-m32r/bug.h2005-02-13 03:39:39.775236000 -0500
On Sat, Feb 12, 2005 at 07:16:59PM -0500, Bill Rugolsky Jr. wrote:
> Sorry for the long delay in replying; the HiNote needed some effort to get
> the thing up and running again. [Various bits of hardware are broken;
> the power switch, floppy, and CD-ROM are busted/flakey.] I've now got
>
On Sat, Feb 12, 2005 at 07:16:59PM -0500, Bill Rugolsky Jr. wrote:
Sorry for the long delay in replying; the HiNote needed some effort to get
the thing up and running again. [Various bits of hardware are broken;
the power switch, floppy, and CD-ROM are busted/flakey.] I've now got
Fedora
For the m32r architecture, is there a reason not to use the generic bug.h
definition?
Signed-off-by: Daniel Dickman [EMAIL PROTECTED]
--- linux-2.6.11-rc4/include/asm-m32r/bug.h 2004-12-24 16:34:01.0
-0500
+++ linux/include/asm-m32r/bug.h2005-02-13 03:39:39.775236000 -0500
@@
On Sun, Feb 13, 2005 at 01:49:10AM -0500, Dmitry Torokhov wrote:
On Friday 11 February 2005 15:10, Vojtech Pavlik wrote:
+ if (set_properties) {
+ psmouse-vendor = Fujitsu Lifebook;
+ psmouse-name = TouchScreen;
+ }
+
+
Dave Jones wrote:
Was there any differnces in the devices at 00:00.0 and 00:01.0 ?
(host pci bridges)
Only the Host bridge line c0:
With AGPGART:
00:00.0 Host bridge: nVidia Corporation: Unknown device 00e1 (rev a1)
Subsystem: Micro-Star International Co., Ltd.: Unknown device 0300
Hi Maciej,
Is there any specific reason for the PIIX4 SMBus driver to be
disabled on 64-bit platforms?
No idea.
If not, then please apply the following change.
The MIPS Technologies Malta development board has the 82371EB chip
and supports 64-bit configurations. I've verified the driver
Am Samstag, den 12.02.2005, 19:34 +0100 schrieb Vojtech Pavlik:
On Sat, Feb 12, 2005 at 06:01:19PM +0100, Kenan Esau wrote:
Am Freitag, den 11.02.2005, 21:10 +0100 schrieb Vojtech Pavlik:
Hi!
[...]
As far as I can see the
init-sequence is the one from Haralds xfree 3.3.6-driver. There
Am Samstag, den 12.02.2005, 12:46 -0500 schrieb Arjan van de Ven:
On Sat, 2005-02-12 at 18:01 +0100, Kenan Esau wrote:
Second thing is that I am not shure that it is a good idea to integrate
the lbtouch-support into the psmouse-driver since there is no real way
of deciding if the device
I've just conducted a binary search to see when the SIS drm stopped
working... and it was 2.6.9-rc1-bk1 from looking at it the new virtual
memory layout is the most likely patch to have broken things... I haven't
confirmed it is this particular patch yet, tomorrow I'll get some time to
do it ..
On Sun, Feb 13, 2005 at 10:39:46AM +0100, Kenan Esau wrote:
Am Samstag, den 12.02.2005, 12:46 -0500 schrieb Arjan van de Ven:
On Sat, 2005-02-12 at 18:01 +0100, Kenan Esau wrote:
Second thing is that I am not shure that it is a good idea to integrate
the lbtouch-support into the
On Sun, Feb 13, 2005 at 11:05:00AM +0100, Kenan Esau wrote:
This
sequence does not always work and there is not something like a magic
knock sequence.
You mean that the only needed bit is setting the resolution to '7'?
The lifebook touchscreen has some extensions to the standard
* Steven Rostedt [EMAIL PROTECTED] wrote:
Ingo,
Here's a trivial patch to help others from freaking out when they see
on a show_trace that most of their processes are TASK_UNINTERRUPTIBLE.
thanks, applied it to -39-00.
- static const char *stat_nam[] = { R, S, D, T, t, Z, X };
+
1 - 100 of 177 matches
Mail list logo