But the only effect of returning EINVAL is a printk (for this particular
driver):
/* PCI Memory-Write-Invalidate cycle support is optional (uncommon) */
retval = pci_set_mwi(pdev);
if (!retval)
ehci_dbg(ehci, MWI active\n);
Erm, I've lost context
On Sun, Oct 15, 2006 at 12:08:09AM -0700, David Brownell wrote:
But the only effect of returning EINVAL is a printk (for this particular
driver):
/* PCI Memory-Write-Invalidate cycle support is optional (uncommon)
*/
retval = pci_set_mwi(pdev);
if (!retval)
Ar Sul, 2006-10-15 am 00:08 -0700, ysgrifennodd David Brownell:
Since it's not an error, there should be no such printk ... which
is exactly how it's coded above.
The underlying bug is that someone marked pci_set_mwi must-check, that's
wrong for most of the drivers that use it. If you remove
On Sat, Oct 14, 2006 at 11:53:59PM -0700, Andrew Morton wrote:
It seems to have stopped happening. I don't know why.
Argh. Possibly a mistake during the bisect procedure?
gregkh-pci-pci-prevent-user-config-space-access-during-power-state-transitions.patch
still breaks suspend though:
On Sun, Oct 15, 2006 at 03:21:22PM +0100, Alan Cox wrote:
Ar Sul, 2006-10-15 am 00:08 -0700, ysgrifennodd David Brownell:
Since it's not an error, there should be no such printk ... which
is exactly how it's coded above.
The underlying bug is that someone marked pci_set_mwi must-check,
Joan Raventos wrote:
Hello,
In order to use PF_PACKET/SOCK_RAW with PACKET_RX_RING
one would possibly do (as described in
Documentation/networking/packet_mmap.txt):
1. setup PF_PACKET socket via socket call.
2. use setsockopt to change the PF_PACKET socket into
PACKET_RX_RING mode and
Hi Dave,
here are my pending bugfixes for the 2.6.19 kernel. They should resolve
various Bugzilla reports and other issues reported over the last couple
of weeks. Please forward them to Linus as soon as possible.
Regards
Marcel
Please pull from
Hi,
I'd be thankful for your opinions about that idea. Please forgive me any
nuances that I didn't know about.
diff --git a/Documentation/networking/ccrypt.txt
b/Documentation/networking/ccrypt.txt
new file mode 100644
index 000..8e46f1e
--- /dev/null
+++
On Sun, 15 Oct 2006 07:57:56 -0600
Matthew Wilcox [EMAIL PROTECTED] wrote:
On Sun, Oct 15, 2006 at 03:21:22PM +0100, Alan Cox wrote:
Ar Sul, 2006-10-15 am 00:08 -0700, ysgrifennodd David Brownell:
Since it's not an error, there should be no such printk ... which
is exactly how it's coded
On Sun, 15 Oct 2006 07:54:41 -0600
Matthew Wilcox [EMAIL PROTECTED] wrote:
On Sat, Oct 14, 2006 at 11:53:59PM -0700, Andrew Morton wrote:
It seems to have stopped happening. I don't know why.
Argh. Possibly a mistake during the bisect procedure?
I don't think so - I spent a lot of time
Hi Patrick,
Thx for your prompt reply! Plz see some comments inline.
Is this a bug in PF_PACKET? Should the socket queue be
emptied by packet_set_ring (called via setsockopt when
PACKET_RX_RING is used) so the above cannot happen?
Should the user-space app drain the socket queue with
This patch correctly initializes the force_unicast_rateidx
and max_ratectrl_rateidx. This was not done previously
and caused a bug in rf80211_simple where when
rate_control_simple_get_rate() was called, the incorrect
rate was selected from the list.
Signed-off-by Modestas Vainius [EMAIL
(From Alan Cox:)
The underlying bug is that someone marked pci_set_mwi must-check, that's
wrong for most of the drivers that use it. If you remove the must check
annotation from it then the problem and a thousand other spurious
warnings go away.
Yes, there seems to be abuse of this new
On Sun, 15 Oct 2006 12:16:31 -0700
David Brownell [EMAIL PROTECTED] wrote:
(From Alan Cox:)
The underlying bug is that someone marked pci_set_mwi must-check, that's
wrong for most of the drivers that use it. If you remove the must check
annotation from it then the problem and a thousand
Ar Sul, 2006-10-15 am 10:45 -0700, ysgrifennodd Andrew Morton:
If the drivers doesn't care and if it makes no difference to performance
then just delete the call to pci_set_mwi().
But if MWI _does_ make a difference to performance then we should tell
someone that it isn't working rather than
On Sat, 2006-10-14 at 15:55 -0400, Jesse Huang wrote:
From: Jesse Huang [EMAIL PROTECTED]
Change Logs:
For patent issue need to remove TxStartThresh and RxEarlyThresh. This patent
is cut-through patent. If use this function, Tx will start to transmit after
few data be move in to Tx FIFO.
On Sun, 15 Oct 2006, Dawid Ciezarkiewicz wrote:
Hi,
I'd be thankful for your opinions about that idea. Please forgive me any
nuances that I didn't know about.
This limits the system to only talking to one other system on the same
link. I guess you could have per-MAC keys and associate the
On Sunday, 15 October 2006 23:35, you wrote:
Hi,
I'd be thankful for your opinions about that idea. Please forgive me any
nuances that I didn't know about.
This limits the system to only talking to one other system on the same
link. I guess you could have per-MAC keys and associate
Ar Llu, 2006-10-16 am 07:26 +1000, ysgrifennodd Benjamin Herrenschmidt:
On Sat, 2006-10-14 at 15:55 -0400, Jesse Huang wrote:
From: Jesse Huang [EMAIL PROTECTED]
Change Logs:
For patent issue need to remove TxStartThresh and RxEarlyThresh. This
patent
is cut-through patent. If use
Most drivers should be able to say enable MWI if possible, but
don't worry if it's not possible. Only a few controllers need
additional setup to make MWI actually work ... if they couldn't
do that setup, that'd be worth a warning before they backed off
to run in a non-MWI mode.
So
Evgeniy Polyakov wrote:
In context you have cut, one updated signal mask between calls to event
delivery mechanism (using for example signal()), so it has exactly the
same price.
No, it does not. If the signal mask is recomputed by the program for
each new wait call then you have a lot more
On Sun, 15 Oct 2006 15:45:58 -0700
David Brownell [EMAIL PROTECTED] wrote:
In that case its interface is misdesigned, because it doesn't discriminate
between yes-it-does/no-it-doesn't (which we don't want to report, because
either is expected and legitimate) and something screwed up, which
Evgeniy Polyakov wrote:
Existing design does not allow overflow.
And I've pointed out a number of times that this is not practical at
best. There are event sources which can create events which cannot be
coalesced into one single event as it would be required with your design.
Signals are
Ar Sul, 2006-10-15 am 16:18 -0700, ysgrifennodd Andrew Morton:
No. If pci_set_mwi() detects an unexpected error then the driver should
take some action: report it, recover from it, fail to load, etc. If the
driver fails to do any of this then it's a buggy driver.
Wrong and there are several
On Mon, 16 Oct 2006 01:02:40 +0100
Alan Cox [EMAIL PROTECTED] wrote:
Ar Sul, 2006-10-15 am 16:18 -0700, ysgrifennodd Andrew Morton:
No. If pci_set_mwi() detects an unexpected error then the driver should
take some action: report it, recover from it, fail to load, etc. If the
driver fails
Andrew Morton writes:
If the drivers doesn't care and if it makes no difference to performance
then just delete the call to pci_set_mwi().
But if MWI _does_ make a difference to performance then we should tell
someone that it isn't working rather than silently misbehaving?
That sounds like
On Mon, 16 Oct 2006 10:00:25 +1000 Paul Mackerras [EMAIL PROTECTED] wrote:
Andrew Morton writes:
If the drivers doesn't care and if it makes no difference to performance
then just delete the call to pci_set_mwi().
But if MWI _does_ make a difference to performance then we should tell
I agree that set_mwo() should set MWI if possible, and fail cleanly
if it couldn't (for whatever reason). Thing is, choosing to treat
that as an error must be the _driver's_ choice ... it'd be wrong to force
that policy into the _interface_ by forcing must_check etc.
No. If
If the drivers doesn't care and if it makes no difference to performance
then just delete the call to pci_set_mwi().
But if MWI _does_ make a difference to performance then we should tell
someone that it isn't working rather than silently misbehaving?
To repeat: it's not misbehaving
On Sun, 15 Oct 2006 17:16:35 -0700
David Brownell [EMAIL PROTECTED] wrote:
You, the driver author _do not know_ what pci_set_mwi() does at present, on
all platforms, nor do you know what it does in the future.
I know that it enables MWI accesses ... or fails. Beyond that, there
should
Andrew Morton writes:
Let me restore the words from my earlier email which you removed so that
you could say that:
For you the driver author to make assumptions about what's happening
inside pci_set_mwi() is a layering violation. Maybe the bridge got
hot-unplugged. Maybe the
On Mon, 16 Oct 2006 10:44:30 +1000
Paul Mackerras [EMAIL PROTECTED] wrote:
Andrew Morton writes:
Let me restore the words from my earlier email which you removed so that
you could say that:
For you the driver author to make assumptions about what's happening
inside pci_set_mwi()
On Mon, 16 Oct 2006 07:26:37 +1000, Benjamin Herrenschmidt said:
Somebody patented FIFO thresholds ? Gack ?
The US PTO is fundamentally busticated.
http://www.engadget.com/2006/10/14/cisco-patents-the-triple-play/
Cisco got a patent on the concept of delivering voice, internet, and
cable TV
On Sunday 15 October 2006 6:10 pm, Andrew Morton wrote:
- A printk if something went bad
Where bad would I hope exclude cases where the device
doesn't support MWI ... that is, the go faster if you can
advice from the driver, where it isn't an error to run into
the common case of _this_
From: Stefano Brivio [EMAIL PROTECTED]
The current bcm43xx driver does not contain code to handle PCI-E interfaces
such as the BCM4311 and BCM4312. This patch, originally written by Stefano
Brivio adds the necessary code to enable these interfaces.
Signed-off-by: Stefano Brivio [EMAIL
(plesae provide updates via reply-to-all email, not via the bugzilla
interface)
Looks like a netfilter regression.
On Sun, 15 Oct 2006 14:00:33 -0700
[EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=7366
Summary: BUG: unable to handle kernel paging request at
Andrew Morton wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=7366
___
Oct 15 17:38:40 test kernel: BUG: unable to handle kernel paging request at
virtual address d0cb03e0
Oct 15 17:38:40 test kernel: printing eip:
Oct 15 17:38:40 test kernel: d08fc19b
Oct 15
37 matches
Mail list logo
