Commit-ID: df968c9329f6e5cf3596a0a54adb6f749747a746
Gitweb: http://git.kernel.org/tip/df968c9329f6e5cf3596a0a54adb6f749747a746
Author: Petr Vandrovec <p...@vandrovec.name>
AuthorDate: Fri, 15 Sep 2017 02:15:05 -0500
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Fri,
Commit-ID: df968c9329f6e5cf3596a0a54adb6f749747a746
Gitweb: http://git.kernel.org/tip/df968c9329f6e5cf3596a0a54adb6f749747a746
Author: Petr Vandrovec
AuthorDate: Fri, 15 Sep 2017 02:15:05 -0500
Committer: Ingo Molnar
CommitDate: Fri, 15 Sep 2017 11:31:50 +0200
objtool: Do not retrieve
Commit-ID: 7156b7141a037420a3cd99dbc1559e0235f57c07
Gitweb: http://git.kernel.org/tip/7156b7141a037420a3cd99dbc1559e0235f57c07
Author: Petr Vandrovec <p...@vandrovec.name>
AuthorDate: Fri, 15 Sep 2017 02:15:05 -0500
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Fri,
Commit-ID: 7156b7141a037420a3cd99dbc1559e0235f57c07
Gitweb: http://git.kernel.org/tip/7156b7141a037420a3cd99dbc1559e0235f57c07
Author: Petr Vandrovec
AuthorDate: Fri, 15 Sep 2017 02:15:05 -0500
Committer: Ingo Molnar
CommitDate: Fri, 15 Sep 2017 10:30:31 +0200
objtool: Do not retrieve
From: Petr Vandrovec <p...@vandrovec.name>
Binutils 2.29-9 in Debian return an error when elf_getdata is invoked
on empty section (.note.GNU-stack in all kernel files), causing
immediate failure of kernel build with:
elf_getdata: can't manipulate null section
As nothing is done with se
From: Petr Vandrovec
Binutils 2.29-9 in Debian return an error when elf_getdata is invoked
on empty section (.note.GNU-stack in all kernel files), causing
immediate failure of kernel build with:
elf_getdata: can't manipulate null section
As nothing is done with sections that have zero size
From: Petr Vandrovec <p...@vmware.com>
Change 3bb434 (vmw_vmci: switch to pci_irq_alloc_vectors) converted
vmw_vmci to use pci_irq_alloc_vectors. Unfortunately for the code
pci_irq_alloc_vectors returns number of allocated vectors on success,
rather than zero. So successful allo
From: Petr Vandrovec
Change 3bb434 (vmw_vmci: switch to pci_irq_alloc_vectors) converted
vmw_vmci to use pci_irq_alloc_vectors. Unfortunately for the code
pci_irq_alloc_vectors returns number of allocated vectors on success,
rather than zero. So successful allocation was always treated
On 10/14/2014 5:57 PM, Martin K. Petersen wrote:
"Petr" == Petr Vandrovec writes:
Petr,
Petr> Logic (from 2011, commit 8af1954d172a46a63e5e79dae523a6d74715e458)
Petr> says that EOPNOTSUPP is returned when DISCARD request failed, as
Petr> discarding is optional, and fai
On 10/14/2014 5:57 PM, Martin K. Petersen wrote:
Petr == Petr Vandrovec p...@vmware.com writes:
Petr,
Petr Logic (from 2011, commit 8af1954d172a46a63e5e79dae523a6d74715e458)
Petr says that EOPNOTSUPP is returned when DISCARD request failed, as
Petr discarding is optional, and failures can
On 10/11/2014 5:51 AM, Martin K. Petersen wrote:
"Petr" == Petr Vandrovec writes:
Petr> After investigating, problem seems to be in a way completion
Petr> handler for WRITE_SAME handles EOPNOTSUPP error, causing
Petr> all-but-first WRITE_SAME request on the LVM device
On 10/11/2014 5:51 AM, Martin K. Petersen wrote:
Petr == Petr Vandrovec p...@vmware.com writes:
Petr After investigating, problem seems to be in a way completion
Petr handler for WRITE_SAME handles EOPNOTSUPP error, causing
Petr all-but-first WRITE_SAME request on the LVM device to be silently
,
Petr Vandrovec
From: Petr Vandrovec
Subject: [PATCH] Do not silently discard WRITE_SAME requests
When device does not support WRITE_SAME, after first failure
block layer starts throwing away WRITE_SAME requests without
warning anybody, leading
,
Petr Vandrovec
From: Petr Vandrovec p...@vmware.com
Subject: [PATCH] Do not silently discard WRITE_SAME requests
When device does not support WRITE_SAME, after first failure
block layer starts throwing away WRITE_SAME requests without
warning
On Wed, Jun 5, 2013 at 1:20 PM, Dave Chiluk wrote:
> Petr do you still have commit rights to ncpfs? Can you please commit it
> to upstream or do I have to get Al to do that?
Hi,
only thing I can do is to add
Signed-off-by: Petr Vandrovec
on your patch and forward it to Al. Unfortu
On Wed, Jun 5, 2013 at 1:20 PM, Dave Chiluk chi...@canonical.com wrote:
Petr do you still have commit rights to ncpfs? Can you please commit it
to upstream or do I have to get Al to do that?
Hi,
only thing I can do is to add
Signed-off-by: Petr Vandrovec p...@vandrovec.name
on your patch
Jan Engelhardt wrote:
Hi,
sad to say, but f06e4ec... breaks booting the kernel in vmware
(bisected). Booting just stops after
Checking for 'hlt' instruction...
commit f06e4ec1c15691b0cfd2397ae32214fa36c90d71
Author: Ingo Molnar <[EMAIL PROTECTED]>
Date: Wed Jan 30 13:32:39 2008
Jan Engelhardt wrote:
Hi,
sad to say, but f06e4ec... breaks booting the kernel in vmware
(bisected). Booting just stops after
Checking for 'hlt' instruction...
commit f06e4ec1c15691b0cfd2397ae32214fa36c90d71
Author: Ingo Molnar [EMAIL PROTECTED]
Date: Wed Jan 30 13:32:39 2008
Stephen Hemminger wrote:
On Sat, 2 Feb 2008 11:52:43 +0100
Petr Vandrovec <[EMAIL PROTECTED]> wrote:
Hello,
since I synced my tree to Linus's one two days ago, sky2's packet receiption
dies almost instantly. Device still transmits packets, but no receive.
Fortunately fix is
Mailer on sf.net says that email address in udev's README is obsolete.
Oops...
Petr
Original Message
Subject: udevd induced deadlock in loading kernel modules?
Date: Sat, 2 Feb 2008 12:07:19 +0100
From: Petr Vandrovec <[EM
at all.
Signed-off-by: Petr Vandrovec <[EMAIL PROTECTED]>
diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
--- a/drivers/net/sky2.c
+++ b/drivers/net/sky2.c
@@ -1192,7 +1192,7 @@ static struct sk_buff *sky2_rx_alloc(struct sky2_port
*sky2)
struct sk_buff *skb;
Thanks,
Petr Vandrovec
usbcore: registered new interface driver usbserial
/usr/src/git/libata-pv/drivers/usb/serial/usb-serial.c: USB Serial support
registered for generic
usbcore: registered new interface driver usbserial_generic
/usr/src/git/libata-pv/drivers/usb/serial/usb-serial
,
Petr Vandrovec
usbcore: registered new interface driver usbserial
/usr/src/git/libata-pv/drivers/usb/serial/usb-serial.c: USB Serial support
registered for generic
usbcore: registered new interface driver usbserial_generic
/usr/src/git/libata-pv/drivers/usb/serial/usb-serial.c: USB Serial
buffers aligned, otherwise receiver hangs
almost instantly. They were aligned before, so let's start aligning
them again - a bit suboptimal networking is much better than no networking
at all.
Signed-off-by: Petr Vandrovec [EMAIL PROTECTED]
diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
Mailer on sf.net says that email address in udev's README is obsolete.
Oops...
Petr
Original Message
Subject: udevd induced deadlock in loading kernel modules?
Date: Sat, 2 Feb 2008 12:07:19 +0100
From: Petr Vandrovec [EMAIL
Stephen Hemminger wrote:
On Sat, 2 Feb 2008 11:52:43 +0100
Petr Vandrovec [EMAIL PROTECTED] wrote:
Hello,
since I synced my tree to Linus's one two days ago, sky2's packet receiption
dies almost instantly. Device still transmits packets, but no receive.
Fortunately fix is simple
Eric W. Biederman wrote:
Ultimately to implement /proc perfectly we need an implementation
of d_revalidate because files and directories can be removed behind
the back of the VFS, and d_revalidate is the only way we can let
the VFS know that this has happened.
So until we get a proper test for
Eric W. Biederman wrote:
Ultimately to implement /proc perfectly we need an implementation
of d_revalidate because files and directories can be removed behind
the back of the VFS, and d_revalidate is the only way we can let
the VFS know that this has happened.
So until we get a proper test for
Peter Zijlstra wrote:
On Sat, 2007-10-27 at 23:30 +0200, Peter Zijlstra wrote:
So in short, stick a struct backing_dev_info into whatever represents a
client, initialize it using bdi_init(), destroy using bdi_destroy().
Oh, and the most important point, make your fresh I_NEW inodes point to
Peter Zijlstra wrote:
On Sat, 2007-10-27 at 23:30 +0200, Peter Zijlstra wrote:
So in short, stick a struct backing_dev_info into whatever represents a
client, initialize it using bdi_init(), destroy using bdi_destroy().
Oh, and the most important point, make your fresh I_NEW inodes point to
dean gaudet wrote:
On Sun, 9 Sep 2007, Nick Piggin wrote:
I've also heard that string operations do not follow the normal ordering, but
that's just with respect to individual loads/stores in the one operation, I
hope? And they will still follow ordering rules WRT surrounding loads and
stores?
dean gaudet wrote:
On Sun, 9 Sep 2007, Nick Piggin wrote:
I've also heard that string operations do not follow the normal ordering, but
that's just with respect to individual loads/stores in the one operation, I
hope? And they will still follow ordering rules WRT surrounding loads and
stores?
Andi Kleen wrote:
On Sunday 12 August 2007 10:12, Petr Vandrovec wrote:
Hello,
after I upgraded kernel on my box to current git, only thing it did
was rebooting in a loop. After some digging I found that it is silly
to apply alternative to memcpy by using that every same memcpy...
Sorry
...
Petr
From: Petr Vandrovec <[EMAIL PROTECTED]>
Do not replace whole memcpy in apply alternatives
apply_alternatives uses memcpy() to apply alternatives. Which has
unfortunate effect that while applying memcpy alternative memcpy itself
it
...
Petr
From: Petr Vandrovec [EMAIL PROTECTED]
Do not replace whole memcpy in apply alternatives
apply_alternatives uses memcpy() to apply alternatives. Which has
unfortunate effect that while applying memcpy alternative memcpy itself
it tries
Andi Kleen wrote:
On Sunday 12 August 2007 10:12, Petr Vandrovec wrote:
Hello,
after I upgraded kernel on my box to current git, only thing it did
was rebooting in a loop. After some digging I found that it is silly
to apply alternative to memcpy by using that every same memcpy...
Sorry
James Bottomley wrote:
On Tue, 2007-07-31 at 20:24 +0200, Maarten Bressers wrote:
Hi Petr,
The patch you posted for the MPT Fusion driver regression with VMware
5.5.4 (http://lkml.org/lkml/2007/3/23/345) was used to fix a Gentoo
kernel bug (http://bugs.gentoo.org/show_bug.cgi?id=185272).
James Bottomley wrote:
On Tue, 2007-07-31 at 20:24 +0200, Maarten Bressers wrote:
Hi Petr,
The patch you posted for the MPT Fusion driver regression with VMware
5.5.4 (http://lkml.org/lkml/2007/3/23/345) was used to fix a Gentoo
kernel bug (http://bugs.gentoo.org/show_bug.cgi?id=185272).
-interlaced 1920x540, and apparently BIOS I have does not believe
that interlaced modes exist.
Thanks,
Petr Vandrovec
List VESA videomodes when vesafb is available
There is no CONFIG_VIDEO_VESA option, so code to retrieve VESA
-interlaced 1920x540, and apparently BIOS I have does not believe
that interlaced modes exist.
Thanks,
Petr Vandrovec
List VESA videomodes when vesafb is available
There is no CONFIG_VIDEO_VESA option, so code to retrieve VESA
Robert P. J. Day wrote:
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
Fine with me. Thanks.
Acked-by: Petr Vandrovec <[EMAIL PROTECTED]>
---
steve walks warily down the street with the brim pulled way down low
...
diff --git a/fs/ncpfs/ncplib_kernel.c b/fs/ncpfs/ncp
Robert P. J. Day wrote:
Signed-off-by: Robert P. J. Day [EMAIL PROTECTED]
Fine with me. Thanks.
Acked-by: Petr Vandrovec [EMAIL PROTECTED]
---
steve walks warily down the street with the brim pulled way down low
...
diff --git a/fs/ncpfs/ncplib_kernel.c b/fs/ncpfs/ncplib_kernel.c
Matt Sealey wrote:
Hello World,
I re-stumbled on this installing Gentoo on VMware today;
http://lkml.org/lkml/2007/3/23/312
It doesn't seem to be fixed in 2.6.22-rc7, but I might be mistaken
somehow. Has anyone done any work on this or looked at the problem
in more detail? The trail seems to
Matt Sealey wrote:
Hello World,
I re-stumbled on this installing Gentoo on VMware today;
http://lkml.org/lkml/2007/3/23/312
It doesn't seem to be fixed in 2.6.22-rc7, but I might be mistaken
somehow. Has anyone done any work on this or looked at the problem
in more detail? The trail seems to
, as expected.
Full output of test program and full kernel dmesg are at
http://buk.vc.cvut.cz/linux/rmap.
Thanks,
Petr Vandrovec
#include
#include
#include
#include
#define TRY_REGIONS 131072
int main(void
, as expected.
Full output of test program and full kernel dmesg are at
http://buk.vc.cvut.cz/linux/rmap.
Thanks,
Petr Vandrovec
#include sys/mman.h
#include stdio.h
#include unistd.h
#include fcntl.h
#define
James Morris wrote:
Convert LSM into a static interface, as the ability to unload a security
module is not required by in-tree users and potentially complicates the
overall security architecture.
Hello,
-module_param(debug, bool, 0600);
-MODULE_PARM_DESC(debug, "Debug enabled or not");
Robert Hancock wrote:
Tejun Heo wrote:
Petr Vandrovec wrote:
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index adfae9d..fbca8d8 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3803,6 +3803,7 @@ static const struct ata_blacklist_entry
Tejun Heo wrote:
Robert Hancock wrote:
Tejun Heo wrote:
Another member of HTS5416* family doing spurious NCQ completion.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Cc: Enrico Sardi <[EMAIL PROTECTED]>
---
drivers/ata/libata-core.c |1 +
1 file changed, 1 insertion(+)
diff --git
Tejun Heo wrote:
Robert Hancock wrote:
Tejun Heo wrote:
Another member of HTS5416* family doing spurious NCQ completion.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
Cc: Enrico Sardi [EMAIL PROTECTED]
---
drivers/ata/libata-core.c |1 +
1 file changed, 1 insertion(+)
diff --git
Robert Hancock wrote:
Tejun Heo wrote:
Petr Vandrovec wrote:
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index adfae9d..fbca8d8 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3803,6 +3803,7 @@ static const struct ata_blacklist_entry
James Morris wrote:
Convert LSM into a static interface, as the ability to unload a security
module is not required by in-tree users and potentially complicates the
overall security architecture.
Hello,
-module_param(debug, bool, 0600);
-MODULE_PARM_DESC(debug, Debug enabled or not);
Stefan Richter wrote:
On 7 May, Petr Vandrovec wrote:
This patch makes raw1394 in current Linux git tree (2.6.21-1570) usable to 32bit
applications running on 64bit kernel (tested on i386 app using x86_64 kernel).
[...]
With this in place I was able to run my test app and grab some mpegs, so
Stefan Richter wrote:
On 7 May, Petr Vandrovec wrote:
This patch makes raw1394 in current Linux git tree (2.6.21-1570) usable to 32bit
applications running on 64bit kernel (tested on i386 app using x86_64 kernel).
[...]
With this in place I was able to run my test app and grab some mpegs, so
rt got introduced).
Best regards,
Petr Vandrovec
-
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:/
introduced).
Best regards,
Petr Vandrovec
-
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
,
Petr Vandrovec
Signed-off-by: Petr Vandrovec <[EMAIL PROTECTED]>
diff -uprdN linux/drivers/ieee1394/raw1394.c linux/drivers/ieee1394/raw1394.c
--- linux/drivers/ieee1394/raw1394.c2007-05-06 17:45:47.0 -0700
+++ linux/drivers/ieee1394/raw1394.c
,
Petr Vandrovec
Signed-off-by: Petr Vandrovec [EMAIL PROTECTED]
diff -uprdN linux/drivers/ieee1394/raw1394.c linux/drivers/ieee1394/raw1394.c
--- linux/drivers/ieee1394/raw1394.c2007-05-06 17:45:47.0 -0700
+++ linux/drivers/ieee1394/raw1394.c2007-05
FIRST_EXTERNAL_VECTOR + 0x10
with
#define IRQ0_VECTORFIRST_EXTERNAL_VECTOR + 0x08
Then IRQ 0x38 will be skipped. Other option is move only IRQ8_VECTOR
somewhere else (into 0x21-0x2F range).
Petr Vandrovec
P.S.: Well
FIRST_EXTERNAL_VECTOR + 0x10
with
#define IRQ0_VECTORFIRST_EXTERNAL_VECTOR + 0x08
Then IRQ 0x38 will be skipped. Other option is move only IRQ8_VECTOR
somewhere else (into 0x21-0x2F range).
Petr Vandrovec
P.S.: Well
4, i386 or i8086 for port
8832). Otherwise gdb is going to die complaining it could not parse
remote reply.
Best regards,
Petr Vandrovec
P.S.: Yes, I'm associated with VMware.
-
To unsubscribe from this list: send the line &q
8832). Otherwise gdb is going to die complaining it could not parse
remote reply.
Best regards,
Petr Vandrovec
P.S.: Yes, I'm associated with VMware.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
ef could not be reserved
pnp: 00:0c: iomem range 0x-0x has been reserved
PCI: Bridge: :00:04.0
IO window: b000-bfff
Thanks,
Petr Vandrovec
Change PnP resource ha
not be reserved
pnp: 00:0c: iomem range 0x-0x has been reserved
PCI: Bridge: :00:04.0
IO window: b000-bfff
Thanks,
Petr Vandrovec
Change PnP resource handling code
Petr
If port reports that no devices are connected to it, assume that 16 devices
are there. Hopefully nobody will ever build device with port but no devices,
and even for them it should be safe as before code always probed 16 devices
regardless of MaxDevices reported by port fac
that 16 devices
are there. Hopefully nobody will ever build device with port but no devices,
and even for them it should be safe as before code always probed 16 devices
regardless of MaxDevices reported by port facts.
Signed-off-by: Petr Vandrovec [EMAIL PROTECTED]
--- linux/drivers/message/fusion
Jean Delvare wrote:
Hi Petr,
On Sat, 10 Mar 2007 09:00:03 +0100, Petr Vandrovec wrote:
Hello,
patch below adds support for nVidia's SMBus adapter present on Gateway's GT5414E
motherboard (ECS's MCP61 PM-AM). Patch is for current Linus's git tree.
We already have a patch doing exactly
Jean Delvare wrote:
Hi Petr,
On Sat, 10 Mar 2007 09:00:03 +0100, Petr Vandrovec wrote:
Hello,
patch below adds support for nVidia's SMBus adapter present on Gateway's GT5414E
motherboard (ECS's MCP61 PM-AM). Patch is for current Linus's git tree.
We already have a patch doing exactly
: Elitegroup Computer Systems Unknown device 2601
Flags: 66MHz, fast devsel, IRQ 10
I/O ports at fc00 [size=64]
I/O ports at 1c00 [size=64]
I/O ports at f400 [size=64]
Capabilities: [44] Power Management version 2
Signed-off-by: Petr Vandrovec <[EM
: Elitegroup Computer Systems Unknown device 2601
Flags: 66MHz, fast devsel, IRQ 10
I/O ports at fc00 [size=64]
I/O ports at 1c00 [size=64]
I/O ports at f400 [size=64]
Capabilities: [44] Power Management version 2
Signed-off-by: Petr Vandrovec [EMAIL
Ondrej Zary wrote:
On Saturday 24 February 2007 14:08, Chris Rankin wrote:
Hi,
I have just booted 2.6.20.1 on my Pentium 3 machine, which has a G400 MAX
graphics card. This machine uses the Matrox framebuffer and TV-OUT modules,
and I have found these warnings in the kernel log:
**WARNING**
Ondrej Zary wrote:
On Saturday 24 February 2007 14:08, Chris Rankin wrote:
Hi,
I have just booted 2.6.20.1 on my Pentium 3 machine, which has a G400 MAX
graphics card. This machine uses the Matrox framebuffer and TV-OUT modules,
and I have found these warnings in the kernel log:
**WARNING**
ler can be interrupted without having to abort the
entire ncp connection.
Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]>
Acked-by: Petr Vandrovec <[EMAIL PROTECTED]>
(modulo one thing below)
diff --git a/include/linux/ncp_fs_sb.h b/include/linux/ncp_fs_sb.h
index a503052..
having to abort the
entire ncp connection.
Signed-off-by: Pierre Ossman [EMAIL PROTECTED]
Acked-by: Petr Vandrovec [EMAIL PROTECTED]
(modulo one thing below)
diff --git a/include/linux/ncp_fs_sb.h b/include/linux/ncp_fs_sb.h
index a503052..d5e7ffc 100644
--- a/include/linux
Pierre Ossman wrote:
Petr Vandrovec wrote:
Problem is with these pointers - reply_buf & server->packet. Now code
will just read packet from server->packet, and write result to
reply_buf, most probably transmiting some random data to network, and
overwriting innocent memory on receip
Pierre Ossman wrote:
Petr Vandrovec wrote:
Problem is with these pointers - reply_buf server-packet. Now code
will just read packet from server-packet, and write result to
reply_buf, most probably transmiting some random data to network, and
overwriting innocent memory on receiption... I
Pierre Ossman wrote:
Ok... how about this baby instead. I've replaced the stack allocated
request structure by one allocated with kmalloc() and reference counted
using an atomic_t. I couldn't see anything else that was associated to
the process, so I believe this should suffice.
(This is just a
Pierre Ossman wrote:
Ok... how about this baby instead. I've replaced the stack allocated
request structure by one allocated with kmalloc() and reference counted
using an atomic_t. I couldn't see anything else that was associated to
the process, so I believe this should suffice.
(This is just a
Philippe Dhont (Sea-ro) wrote:
hello,
i downloaded latest kernel 2.6.19.2 and installed it and it works fine.
Now i am trying to install vmware and it asks the location of the
directory of the C header files.
So i pointed it to my download/install directory
Philippe Dhont (Sea-ro) wrote:
hello,
i downloaded latest kernel 2.6.19.2 and installed it and it works fine.
Now i am trying to install vmware and it asks the location of the
directory of the C header files.
So i pointed it to my download/install directory
Pierre Ossman wrote:
Petr Vandrovec wrote:
Hello,
create test scenario where first transmit of NCP request is lost by
network, and before resend you kill this process. So it stops
resending, but local sequence count is already incremented. Then when
next process tries to access ncpfs
Pierre Ossman wrote:
Petr Vandrovec wrote:
Hello,
create test scenario where first transmit of NCP request is lost by
network, and before resend you kill this process. So it stops
resending, but local sequence count is already incremented. Then when
next process tries to access ncpfs
Pierre Ossman wrote:
Sorry this took some time, I've been busy with other things.
Petr Vandrovec wrote:
Unfortunately NCP does not run on top of TCP stream, but on top of
IPX/UDP, and so dropping reply is not sufficient - you must continue
resending request (so you must buffer it somewhere
Pierre Ossman wrote:
Sorry this took some time, I've been busy with other things.
Petr Vandrovec wrote:
Unfortunately NCP does not run on top of TCP stream, but on top of
IPX/UDP, and so dropping reply is not sufficient - you must continue
resending request (so you must buffer it somewhere
Roland Dreier wrote:
> So my question is - what is real reason for disabling INTX when in MSI mode?
> According to PCI spec it should not be needed, and it hurts at least chips
> listed below:
>
> 00:13.0 0c03: 1002:4374 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller
Roland Dreier wrote:
So my question is - what is real reason for disabling INTX when in MSI mode?
According to PCI spec it should not be needed, and it hurts at least chips
listed below:
00:13.0 0c03: 1002:4374 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller
Pierre Ossman wrote:
Petr Vandrovec wrote:
Nobody is working on it (at least to my knowledge), and to me it is
feature - it always worked this way, like smbfs did back in the past -
if you send signal 9 to process using mount point, and there is some
transaction in progress, nobody can
handling for reply - as buffers
currently specified as reply buffers are owned by caller, so after
aborting request you cannot use them anymore.
Petr Vandrovec
-
To unsubscribe from this list: send the line "unsubscribe linux-k
handling for reply - as buffers
currently specified as reply buffers are owned by caller, so after
aborting request you cannot use them anymore.
Petr Vandrovec
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
Pierre Ossman wrote:
Petr Vandrovec wrote:
Nobody is working on it (at least to my knowledge), and to me it is
feature - it always worked this way, like smbfs did back in the past -
if you send signal 9 to process using mount point, and there is some
transaction in progress, nobody can
.
Thanks,
Petr Vandrovec
/proc/interrupts after patch. Before patch *hci_hcd:usb* were at zero, IRQ21
was
stuck with IRQ count at 1, and HCD complained about "Unlink after no-IRQ?".
CPU0
0: 140326 local-APIC-ed
.
Thanks,
Petr Vandrovec
/proc/interrupts after patch. Before patch *hci_hcd:usb* were at zero, IRQ21
was
stuck with IRQ count at 1, and HCD complained about Unlink after no-IRQ?.
CPU0
0: 140326 local-APIC-edge-fasteio
schönfeld / in-medias-res wrote:
Hi Petr,
the two servers is that the one with the problems does run a nagios nrpe
server and some plugins, e.g. to check disk space on the novell disk,
while the other server does not. Now i found that heavy operations on
the filesystem (e.g. stat'ing many small
schönfeld / in-medias-res wrote:
Hi Petr,
the two servers is that the one with the problems does run a nagios nrpe
server and some plugins, e.g. to check disk space on the novell disk,
while the other server does not. Now i found that heavy operations on
the filesystem (e.g. stat'ing many small
to match Linux driver expectations.
Petr Vandrovec
-
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/
hdog driver itself does
not touch GPIO2 pins at all.
Thanks,
Petr Vandrovec
Signed-off-by: Petr Vandrovec <[EMAIL PROTECTED]>
diff -urN linux-2.6.13-5bca.dist/drivers/hwmon/
.
...
0295-0296 : pnp 00:09
0295-0296 : w83627hf
...
Thanks,
Petr Vandrovec
Signed-off-by: Petr Vandrovec <[EMAIL PROTECTED]>
diff -urN linux-2.6.13-5bca.dist/drivers/hwmon/w83627hf.c
schönfeld / in-medias-res wrote:
Hi,
thanks for your answere.
Uhmm... then remains the question: Why should that happen on the first
machine but not on the second?
Enable displaying of connection watchdog logouts on the server. Do not
use 'intr' mount option. Do not send KILL signal to
schönfeld / in-medias-res wrote:
Hi,
thanks for your answere.
Uhmm... then remains the question: Why should that happen on the first
machine but not on the second?
Enable displaying of connection watchdog logouts on the server. Do not
use 'intr' mount option. Do not send KILL signal to
.
...
0295-0296 : pnp 00:09
0295-0296 : w83627hf
...
Thanks,
Petr Vandrovec
Signed-off-by: Petr Vandrovec [EMAIL PROTECTED]
diff -urN linux-2.6.13-5bca.dist/drivers/hwmon/w83627hf.c
linux-2.6.13
1 - 100 of 529 matches
Mail list logo
