Steve Wise wrote:
Jeff Garzik wrote:
Steve Wise wrote:
I was about to post v2 of my patch to avoid port space collisions
with the native stack. Can we get that 2.6.24? It is high priority
IMO. I've tried to solicit review on it, but I think folks are
reluctant... ;-)
Well, if it involves
Jon Ivar Rykkelid wrote:
Prakash Punnoor wrote:
I don't think it will matter, as adma doesn't affect MCP51, but only
nforce4. So I'd look for other trouble makers.
Robert told me. (And you're correct - It didn't help).
Yes, it was already in slow-and-safe mode.
I'm going to test another
Jon Ivar Rykkelid wrote:
It is NOT the PSU, nor is it cables, as all the drives work well using
the same cables + PSU (in the same box) if I connect them to my other
two controllers (in that same box).
It's sometimes the combination that matters most. You cannot really
make that
Stefan Richter wrote:
Signed-off-by: Stefan Richter [EMAIL PROTECTED]
---
Applicable to 2.6.23-rc6 and to scsi-misc.
drivers/scsi/Kconfig | 32
1 file changed, 20 insertions(+), 12 deletions(-)
ACK
-
To unsubscribe from this list: send the line
Dan Williams wrote:
WTF? why would the default be to _not_ propagate carrier state? Are
there some mitigating circumstances that require this driver to not
notify the stack of carrier on/off? Userspace stuff really should know
about the carrier state, and this disables it by default.
The
Evgeniy Polyakov wrote:
Hi.
I'm pleased to announce fourth release of the distributed storage
subsystem, which allows to form a storage on top of remote and local
nodes, which in turn can be exported to another storage as a node to
form tree-like storages.
This release includes new
J. Bruce Fields wrote:
On Fri, Sep 14, 2007 at 03:07:46PM -0400, Jeff Garzik wrote:
I've been waiting for years for a smart person to come along and write a
POSIX-only distributed filesystem.
What exactly do you mean by POSIX-only?
Don't bother supporting attributes, file modes, and other
J. Bruce Fields wrote:
On Fri, Sep 14, 2007 at 05:14:53PM -0400, Jeff Garzik wrote:
J. Bruce Fields wrote:
On Fri, Sep 14, 2007 at 03:07:46PM -0400, Jeff Garzik wrote:
I've been waiting for years for a smart person to come along and write a
POSIX-only distributed filesystem.
What exactly do
J. Bruce Fields wrote:
On Fri, Sep 14, 2007 at 06:32:11PM -0400, Jeff Garzik wrote:
J. Bruce Fields wrote:
On Fri, Sep 14, 2007 at 05:14:53PM -0400, Jeff Garzik wrote:
NFSv4.1 adds to the fun, by throwing interoperability completely out the
window.
What parts are you worried about
Robin Humble wrote:
On Fri, Sep 14, 2007 at 03:07:46PM -0400, Jeff Garzik wrote:
It is my hope that you will put your skills towards a distributed
filesystem :) Of the current solutions, GFS (currently in kernel)
scales poorly, and NFS v4.1 is amazingly bloated and overly complex.
I've been
Stefan Richter wrote:
Adrian Bunk wrote:
On Sat, Sep 15, 2007 at 04:11:45PM +0200, Stefan Richter wrote:
Perfect is in the eye of the beholder. You would consequently have to
add such options into all menus which contain scsi low-level providers.
Kconfig is a user interface, so perfect is
Bartlomiej Zolnierkiewicz wrote:
On Saturday 15 September 2007, Adrian Bunk wrote:
On Sat, Sep 15, 2007 at 11:44:59AM -0400, Jeff Garzik wrote:
Stefan Richter wrote:
Adrian Bunk wrote:
On Sat, Sep 15, 2007 at 04:11:45PM +0200, Stefan Richter wrote:
Perfect is in the eye of the beholder
Just checked this in locally...
The hooks -self_test_count() and -get_stats_count() are now unused
in the main tree.
(based off of latest davem/net-2.6.24.git)
drivers/net/3c59x.c | 11 +++-
drivers/net/8139cp.c| 11 +++-
drivers/net/8139too.c
Sam Ravnborg wrote:
Hi Jeff.
You wrote:
The hooks -self_test_count() and -get_stats_count() are now unused
in the main tree.
So I'm suprised to see more lines added than deleted:
35 files changed, 346 insertions(+), 246 deletions(-)
Puzzled - may need a bit more coffee (morning here)..
Mark Lord wrote:
Jeff Garzik wrote:
Mark Lord wrote:
Ditto for selecting transfer modes.
Waiting on one thing AFAICS:
ability to drain/idle all ports +
issue a command on one port +
resume normal parallel port operation
SET FEATURES - XFER MODE is special in that it requires
J.C. Roberts wrote:
http://marc.info/?l=linux-wirelessm=118857712529898w=2
Link with outdated info.
http://madwifi.org/browser/branches/ath5k
Link with outdated info.
I suggest actually taking the time to get the facts before making
completely baseless statements. When you make
That's the wonderful thing about open development: our mistakes, and
the corrections made to fix mistakes, are out in the open for all to
see. And we wouldn't have it any other way.
Jeff
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
Can E. Acar wrote:
There have been complete silence from the leaders of their own
community (Linux Kernel developers, FSF, ...) all perhaps used your
Regarding Linux Kernel developers, false. _I_ have posted. ath5k,
wireless, and net driver maintainers have all sent emails. License and
Daniel Hazelton wrote:
If the OpenBSD developers want to attack the Linux Kernel community over
patches that were *NEVER* *ACCEPTED* by said community, it should be just as
fair for the Linux Kernel community to complain about those (unspecified)
times where OpenBSD replaced the GPL on code
[EMAIL PROTECTED] wrote:
you claim that it's unethical for the linux community to use the code,
but brag about NetApp useing the code. what makes NetApp ok and Linux
evil? many people honestly don't understand the logic behind this.
please explain it.
There are two highly relevant angles to
Can E. Acar wrote:
Furthermore, since it is compatible with the binary HAL from
Atheros, the interface is fixed and the same both in Linux and
*BSD.
Hardly. It is software; the interface most definitely can and will change.
Jeff
-
To unsubscribe from this list: send the line
Tejun Heo wrote:
[cc'ing Albert and linux-ide]
Alan Cox wrote:
/from the media. */
+ if (qc-nbytes 2048)
+ return -EOPNOTSUPP;
+
/* No ATAPI DMA in smart mode */
if (itdev-smart)
return -EOPNOTSUPP;
This looks like a gross hack. Aren't you supposed to
Can E. Acar wrote:
As long as it is not a derived work, Reyk gets to decide who is in the
copyright. Even if it is a derived work, it is polite to ask.
Additional work went in, thus additional copyrights were added.
I am really disappointed by all this. I would have expected that once
such
Linus Torvalds wrote:
Why do people insist on
using the old interfaces (and matching them with the new setup)?
readl/writel is [slightly] faster, and possibility of using even-write
__raw_writel() exists, in the old interface...
...but pci_iomap() is a bus-friendly wrapper that handles a
Linus Torvalds wrote:
The old situation with SATA drivers that had
if (iomem)
writel(..)
else
outl(..)
in the cases that needed it (and used hardcoded writel/outl in the cases
that didn't) was an example of code that in theory is faster. But
Bryan Wu wrote:
From 157dfddae50708a716c2a42a314eccb9621d8793 Mon Sep 17 00:00:00 2001
From: Alex Landau [EMAIL PROTECTED]
Date: Sun, 5 Aug 2007 15:58:03 +0800
Subject: [PATCH] Blackfin Ethernet MAC driver: add function to change the MAC
address
Alex Landau writes in the forums:
Previously,
Benjamin Herrenschmidt wrote:
To be more precise, a platform has every right to return some kind of
token from ioport_map/pci_iomap that encodes the type of address, and
that is -different- from what a normal ioremap does. In which case, you
will -not- be able to use readb/writeb cie on such a
Benjamin Herrenschmidt wrote:
On Tue, 2007-09-18 at 16:21 -0400, Jeff Garzik wrote:
A new pci_mmio_map() helper, to be used with 100% MMIO hardware, might
help eliminate confusion.
Maybe not the best name in theory but at least would show that it
relates to existing ioremap would
Maciej W. Rozycki wrote:
Remove typedefs, volatiles and convert kmalloc()/memset() pairs to
kcalloc(). Also reformat the surrounding clutter.
Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
---
On Thu, 13 Sep 2007, Jeff Garzik wrote:
Net driver patches should apply on top of netdev-2.6
applied
-
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/
applied
-
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/
Maciej W. Rozycki wrote:
Rename NET_SB1250_MAC to SB1250_MAC to follow the convention.
Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
---
The NET prefix seems to be used mainly for device groups (NET_ISA,
NET_VENDOR_*, etc.) rather than single drivers and adds no information. I
suggest
Vitaly Bordug wrote:
Signed-off-by: Vitaly Bordug [EMAIL PROTECTED]
---
drivers/net/fs_enet/fs_enet-main.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
applied 1-2, after hand-editing the subject line to remove brackets from
around [FS_ENET]
everything within [ and ]
driver: add a select for the PHYLIB of this driver
David Gibson (1):
Device tree aware EMAC driver
Dhananjay Phadke (1):
netxen: ethtool fixes
Jeff Garzik (1):
[netdrvr] Stop using legacy hooks -self_test_count, -get_stats_count
Maciej W. Rozycki (3):
sb1250-mac.c: Fix
Maciej W. Rozycki wrote:
On Thu, 20 Sep 2007, Jeff Garzik wrote:
You may be pleased (or less so) to hear that the version of sb1250-mac.c in
your tree does not even build (because of
42d53d6be113f974d8152979c88e1061b953bd12) and the patch below does not
address it. I ran out of time
This includes the sky2 update that you and sch discussed.
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
drivers/net/myri10ge/myri10ge.c |3 +
drivers/net/phy/phy.c
Alan Cox wrote:
On Thu, 8 Nov 2007 22:46:22 -0500
Jeff Garzik [EMAIL PROTECTED] wrote:
On Thu, Nov 08, 2007 at 10:29:37PM -0500, Mark Lord wrote:
And I might even privately patch my own kernels to map the ACHI BAR
in the cases where the BIOS didn't...
The inability to do this in the general
Matthias Schniedermeyer wrote:
And on the topic of broken BIOSes. I have a little empathy for the MB
manufactures as non-RAID AHCI royaly screws Windos, so not supporting it
reduces their support costs enough to overlook screwing the non-windos
faction.
non-RAID AHCI works just fine on
Sam Ravnborg wrote:
This is the patch that get rid of ARCH=i386 and ARCH=x86_64
and introduce ARCH=x86.
It touches several files but the changes are all one or two-liners.
x86: drop backward compatibility symlinks to i386/boot and x86_64/boot
kbuild: sanity check the specified arch
Maciej W. Rozycki wrote:
On Sun, 4 Nov 2007, Alberto Gonzalez wrote:
The problem comes from a very high rate of load/unload cycles of the heads
that reaches the 300.000-600.000 limit in 2-3 years (with smartmontools it
can checked it with smartctl -A /dev/sda) . There are reports of HDD
Theodore Tso wrote:
On Fri, Nov 09, 2007 at 10:05:05PM -0500, Jeff Garzik wrote:
By forcing AHCI, your PATA devices will be inaccessible, in a common
configuration. It also means shuffling users from one driver to another,
which induces breakage.
I was speaking wishfully. Real life
peer chen wrote:
Yes, link - http://lkml.org/lkml/2007/10/8/93 add the AHCI legacy
support to sata_nv when IDE/RAID mode been set in SBIOS and Device IDs
are not in ahci.c at this moment. To do so, when a new chipset come
out and DIDs haven't been submited to LKML,user still can use ahci
driver
Brian Gerst wrote:
Jeff Garzik wrote:
Sam Ravnborg wrote:
This is the patch that get rid of ARCH=i386 and ARCH=x86_64
and introduce ARCH=x86.
It touches several files but the changes are all one or two-liners.
x86: drop backward compatibility symlinks to i386/boot and
x86_64/boot
Jeff Garzik wrote:
The proposed sata_nv patch does the opposite -- guarantees we must
support the continually problematic legacy IDE interface ad infinitum.
Such patches are OK for the test lab, but in this specific case users
/suffer/ when not running AHCI mode.
Just to reinforce
Matthew Garrett wrote:
Experience suggests that the _GTF method may be bad. We currently fail
device revalidation in that case, which seems excessive.
Signed-off-by: Matthew Garrett [EMAIL PROTECTED]
applied
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
Sam Ravnborg wrote:
Keeping ARCH=i386 and ARCH=x86_64 around is just a way to pretend
this is two diffrent architectures which is no longer the case.
They _are_ different in the real world... that's why
make ARCH=i386
is so often used.
Do we need a way to say build a kernel that
Paul Mundt wrote:
This is one of the things I've been wondering about with an sh/sh64
unification, as we have no option but having completely different
toolchains, and CONFIG_64BIT=y won't work there when they are both
using a 32-bit ABI.
IMO it seems like you ought to be able to do
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/ata_piix.c |7 +++
drivers/ata/libata-acpi.c | 10 +---
drivers/ata/libata-core.c | 78
Allen Martin wrote:
At least for NVIDIA controllers, loading the AHCI driver when the BIOS
is set to IDE mode is not recommended by NVIDIA. Any AHCI workarounds
in the BIOS are likely to be disabled when set to IDE mode. In practice
What workarounds, if any, are needed?
We need those in the
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
MAINTAINERS | 10 ++-
drivers/net/Kconfig |2 +-
Alan Cox wrote:
ata9.00: qc timeout (cmd 0xa0)
ata9.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata9.00: cmd a0/00:00:00:02:00/00:00:00:00:00/a0 tag 0 cdb 0x5a data 2
in
res 51/54:03:00:02:00/00:00:00:00:00/a0 Emask 0x5 (timeout)
ata9.00: status: { DRDY ERR }
Could be
Will Trives wrote:
Hello,
Motherboard: Gigabyte GA-P35-DS4 (rev. 1.1)
Chipset: Intel P35 + ICH9R
PATA port runs off JMicron controller
CD/DVD Device: BENQ DW1640 16X
I cannot access my dvd burner under 2.6.24-rc2, I have no problems under
2.6.23. Basically the drive is detected OK,
I'm about to disappear (virtually) through Friday for vacation.
David Miller has agreed to collect net driver bug fix patches in my
absence, with Stephen and Francois (and others, hopefully) helping out
with patch review.
David -- note that my 2.6.25 was opened a little while ago. If you
I'm about to disappear (virtually) through Friday for vacation.
Tejun Heo has agreed to collect libata bug fix patches in my absence.
Thanks!
Jeff
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
the interface usage
consistent, which in turn enables the possibility of directly
referencing Scsi_Host from all NCR5380_intr() invocations.
Signed-off-by: Jeff Garzik [EMAIL PROTECTED]
---
Resend #1. Originally sent on Oct 26.
Please send upstream for 2.6.24-rc in some form, this fixes obvious
free_irq
Nick Piggin wrote:
Index: linux-2.6/sound/oss/via82cxxx_audio.c
===
--- linux-2.6.orig/sound/oss/via82cxxx_audio.c
+++ linux-2.6/sound/oss/via82cxxx_audio.c
@@ -2099,8 +2099,7 @@ static void via_dsp_cleanup (struct via_
}
Andrew Gallatin wrote:
Remove the bogus netif_running() check from myri10ge_poll().
This eliminates any chance that myri10ge_poll() can trigger
an oops by calling netif_rx_complete() and returning
with work_done == budget.
Signed-off-by: Andrew Gallatin [EMAIL PROTECTED]
holding onto this
Jochen Friedrich wrote:
This patch adds support to use the fixed-link property
of an ethernet node to fs_enet for the
CONFIG_PPC_CPM_NEW_BINDING case.
Signed-off-by: Jochen Friedrich [EMAIL PROTECTED]
---
drivers/net/fs_enet/fs_enet-main.c |9 -
1 files changed, 8 insertions(+), 1
Mark Lord wrote:
Improve the existing boot/load time warnings from sata_mv
for Highpoint RocketRAID 23xx cards, based on new knowledge
about where the BIOS likes to overwrite sectors with metadata.
Harmless to us, but very useful for end users.
Signed-off-by: Mark Lord [EMAIL PROTECTED]
---
In 2.6.24, we turned on ACPI support in libata. This is needed in order
to support suspend/resume and BIOS passworded drives, but it inevitably
brought with it a host of new regressions -- which is what happens
anytime you blindly accept ATA commands the BIOS has decided to toss
your way. :)
A couple serious fixes (wireless, e100, sky2) and a bevy of minor ones.
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
MAINTAINERS|6 ++
Divy Le Ray wrote:
From: Divy Le Ray [EMAIL PROTECTED]
Add parity initialization for T3C adapters.
Signed-off-by: Divy Le Ray [EMAIL PROTECTED]
applied 1-2 to #upstream
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
Andrew Morton wrote:
On Mon, 17 Dec 2007 20:48:03 -0800 Joe Perches [EMAIL PROTECTED] wrote:
Back to Adam Fritzler...
...
diff --git a/CREDITS b/CREDITS
index ee909f2..449ec7f 100644
--- a/CREDITS
+++ b/CREDITS
@@ -1124,6 +1124,9 @@ S: 1150 Ringwood Court
S: San Jose, California 95131
S:
Arjan van de Ven wrote:
Hi,
Linus really wants the extended (4Kb) PCI configuration space (using MCFG acpi
table etc) to be opt-in, since there's many issues with it and most drivers
don't even use/need it. The idea behind opt-in is that if you don't use it, you
don't get to suffer the
Greg KH wrote:
But it is that device, and the driver that controls this device that
cares about the extended config space. So it's fair to push this onto
the driver if needed, instead of forcing the pci core to just blindly
guess for all devices, and getting it wrong...
Nothing is being
Linus Torvalds wrote:
On Sat, 22 Dec 2007, Arjan van de Ven wrote:
On Sat, 22 Dec 2007 09:20:06 -0500
Jeff Garzik [EMAIL PROTECTED] wrote:
Yuck. And, Linus is just being silly. Wait a year then turn on
MMCONFIG :) It took PCI MSI a while to mature, but is finally
getting
Arjan van de Ven wrote:
On Sat, 22 Dec 2007 20:30:58 +0100
Martin Mares [EMAIL PROTECTED] wrote:
Hello!
Just make it so. The name is fine, the concept is unavoidable. The
people who complain are whiners that haven't ever had to deal with
the fact that there are broken machines around.
I
Arjan van de Ven wrote:
On Sat, 22 Dec 2007 09:20:06 -0500
Jeff Garzik [EMAIL PROTECTED] wrote:
Arjan van de Ven wrote:
Hi,
Linus really wants the extended (4Kb) PCI configuration space
(using MCFG acpi table etc) to be opt-in, since there's many issues
with it and most drivers don't even
Linus Torvalds wrote:
The problem is that it isn't enough that it works on common machines with
good hardware. The problem is that we end up chasing insane bugs, wasting
peoples valuable time and effort, on those *few* - out of *millions* - of
machines that then surprisingly don't work.
And
Linus Torvalds wrote:
On Sat, 22 Dec 2007, Jeff Garzik wrote:
Regardless of whether a driver is loaded or not, you may NEED to see extended
capabilities. The system may NEED to see those capabilities just to parse
them for sane operation.
And that's just not true.
I don't know why you even
Jeff Garzik wrote:
Maybe that day will never come, but it is nonetheless quite possible
without today's PCI Express spec for this to happen.
er, s/without/within/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
Linus Torvalds wrote:
On Sat, 22 Dec 2007, Jeff Garzik wrote:
My core assertion: the present situation -- turning off MMCONFIG aggressively
-- is greatly preferable to adding pci_enable_mmconfig_accesses(pdev).
Well, you do realize that right now we have to have _users_ just doing
pci
Linus Torvalds wrote:
I want to limit that downside. Right now, the easiest way to limit it
seems to be to say that those (very very few) drivers that actually care
could enable it. That way, we automatically limit it to only those
machines that have hardware that cares.
Then let's do it
Linus Torvalds wrote:
On Sat, 22 Dec 2007, Jeff Garzik wrote:
But regardless of problems, enabling should be done globally, not per
device...
I'm ok with trying the globally idea, but it has to be globally but
only if absolutely required.
And quite frankly, how do you tell whether it's
Linus Torvalds wrote:
On Sun, 23 Dec 2007, Jeff Garzik wrote:
And yes, if you want the capability following to notice automatically when
capabilities really do go into the 0x100+ range, that's fine. I suspect
Yes, we /must/ do this checking, if we don't already.
Hell no. If the user asked
Loic Prylli wrote:
Supporting extended-conf-space is independant of the issue of using
mmconf for legacy conf-space.
True.
There is no real reason to use the same
method to access both. I have seen several arguments used that were
implying that, and they all seem really bogus to me. Not
Al Viro wrote:
On Sun, Dec 23, 2007 at 12:33:14AM -0500, Jeff Garzik wrote:
A couple [minorly] notable wireless bug fixes, and plenty of viro fixes
for obscure issues :)
Heh... FWIW, forcedeth patch (sent your way about two weeks ago) also
belongs in the same set. If you need a resend
Another year, another update! :)
The kernel hacker's guide to git has received some updates:
http://linux.yyz.us/git-howto.html
This includes all the input sent to me in the past several months, as
well as a few new tips and tricks I use on a regular basis.
In general, this
Robert P. J. Day wrote:
On Sun, 23 Dec 2007, Jeff Garzik wrote:
Another year, another update! :)
The kernel hacker's guide to git has received some updates:
http://linux.yyz.us/git-howto.html
This includes all the input sent to me in the past several months,
as well as a few new
Arjan van de Ven wrote:
3) mmconfig might or might not be enabled, depending on which driver
is loaded, whether it called an API or not.
Even LESS testing by hw vendors than #2. Maybe even never
Inconsistent (config access depends on device)
the depends on device is even
Ivan Kokshaysky wrote:
On Sun, Dec 23, 2007 at 12:44:30AM -0500, Jeff Garzik wrote:
Failures are more predictable and more consistent with an all-or-none
scenario. The all-or-none solutions are the least complex on the software
side, and far more widely tested than any mixed config access
Linus Torvalds wrote:
(For example: I have three machines that I know have working MMCONF. On
only one of theose does Linux actually even enable MMCONF accesses,
because on the two other ones the BIOSes do the crazy put it in some
space that is reserved by PnP crap later, so we actually refuse
Arjan van de Ven wrote:
I can see the point of having a sysfs attribute to enable MMCONF from
userspace, so
that userland diagnostics tools can turn it on if they really really want to.
(I'd make that printk a nice warning application XYZ is enabling extended config
space for devize ABC so
David Sterba wrote:
Hi,
I'm submitting driver for IPWireless PC Card, used for 4G
internet connection.
The driver has been in -mm series as ipwireless_cs.git tree for
some time, is actively used and there are currently no
outstanding bugs.
I'd like to let the driver pass through LKML and then
Divy Le Ray wrote:
From: Divy Le Ray [EMAIL PROTECTED]
The patch ensures that a GSO skb has enough headroom
to push an encapsulating cpl_tx_pkt_lso header.
Signed-off-by: Divy Le Ray [EMAIL PROTECTED]
---
applied 1-3
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
Vitaly Bordug wrote:
With that patch fixed.c now fully emulates MDIO bus, thus no need
to duplicate PHY layer functionality. That, in turn, drastically
simplifies the code, and drops down line count.
As an additional bonus, now there is no need to register MDIO bus
for each PHY, all emulated
sonic zhang wrote:
UDMA Mode - Frequency compatibility
UDMA5 - 100 MB/s - SCLK = 133 MHz
UDMA4 - 66 MB/s- SCLK = 80 MHz
UDMA3 - 44.4 MB/s - SCLK = 50 MHz
UDMA2 - 33 MB/s- SCLK = 40 MHz
Signed-off-by: Sonic Zhang [EMAIL PROTECTED]
---
drivers/ata/pata_bf54x.c |7 +++
1
Alan Cox wrote:
On Fri, 30 Nov 2007 14:34:11 +0200 (EET)
Meelis Roos [EMAIL PROTECTED] wrote:
Can you stick a stack trace in at that point ? That would help diagnose
it a great deal quicker.
Finally done - found out hard way that BUG() is too bad and
dump_st5ack() suits me better.
Thanks.
Kristen Carlson Accardi wrote:
Enclosure Management via LED
This patch implements Enclosure Management via the LED protocol as specified
in AHCI specification.
Signed-off-by: Kristen Carlson Accardi [EMAIL PROTECTED]
---
This revision makes the change to the comment requested by Mark Lord,
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/ata_piix.c| 28 +++
drivers/ata/libata-core.c |8 +++--
drivers/ata/libata-eh.c | 42
Mark Lord wrote:
Mark Lord wrote:
Mark Lord wrote:
I've only just recently tried running 2.6.24 on my main machine.
And it appears that I'll have to go back to 2.6.23,
because the USB mouse is not working correctly.
Single-clicking on things with 2.6.24 very frequently gives a
double-click.
]
Acked-by: Alan Cox [EMAIL PROTECTED]
Cc: Jeff Garzik [EMAIL PROTECTED]
Cc: Tejun Heo [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
I'll add this to the queue. Sorry for missing it.
Jeff
--
To unsubscribe
Neil Brown wrote:
I've been looking at use BIO_RW_FAILFAST in md/raid to improve
handling of some error cases.
This is particularly significant for the DASD driver (s390 specific).
I believe it uses optic fibre to connect to the drives. When one of
these paths is unplugged, IO requests will
Nicolas Pitre wrote:
On Mon, 3 Dec 2007, Linus Torvalds wrote:
That said, none of the changes are really _exciting_ or really scary. And
we should have fixed a number of regressions, although more certainly
remain.
Any reason for this:
mode change 100644 = 100755
Robert Hancock wrote:
We need to run any DMA command with result taskfile requested in ADMA mode
when the port is in ADMA mode, otherwise it may try to use the legacy DMA engine
in ADMA mode which is not allowed. Enforce this with BUG_ON() since data
corruption could potentially result if this
peerchen wrote:
Add the device IDs of legacy mode of MCP79 AHCI controller to ahci.c
The patch base on kernel 2.6.24-rc3
Signed-off-by: Peer Chen [EMAIL PROTECTED]
applied #upstream-fixes
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
-by: Thomas Lindroth [EMAIL PROTECTED]
Acked-by: Alan Cox [EMAIL PROTECTED]
Cc: Jeff Garzik [EMAIL PROTECTED]
Cc: Tejun Heo [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
applied #upstream-fixes
--
To unsubscribe from this list
Divy Le Ray wrote:
From: Divy Le Ray [EMAIL PROTECTED]
revert inavertant file mode changes
Signed-off-by: Divy Le Ray [EMAIL PROTECTED]
---
drivers/net/chelsio/cxgb2.c |0
drivers/net/chelsio/pm3393.c |0
drivers/net/chelsio/sge.c|0
drivers/net/chelsio/sge.h|0
Vitaly Bordug wrote:
With that patch fixed.c now fully emulates MDIO bus, thus no need
to duplicate PHY layer functionality. That, in turn, drastically
simplifies the code, and drops down line count.
As an additional bonus, now there is no need to register MDIO bus
for each PHY, all emulated
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/ahci.c |4
drivers/ata/pata_amd.c |5 +++--
drivers/ata/pata_via.c |4 ++--
drivers/ata/sata_mv.c |
1101 - 1200 of 7471 matches
Mail list logo
