ChangeSet@1.1570, 2004-09-28 08:12:07-03:00, Achim_Leubner@adaptec.com
[PATCH] gdth update
I'm the maintainer of the driver "gdth" for the ICP vortex and Intel
RAID controllers. We released the new driver 3.04 with some important
changes. I send you the patch against kernel 2.4.25. Could you please
include the patch for the next kernel release?
The driver patch includes some important bug fixes.
ChangeSet@1.1569, 2004-09-28 08:11:17-03:00, marcelo@logos.cnet
Cset exclude: Achim_Leubner@adaptec.com|ChangeSet|20040928105422|00490
ChangeSet@1.1568, 2004-09-28 07:54:22-03:00, Achim_Leubner@adaptec.com
[PATCH] gdth update
I'm the maintainer of the driver "gdth" for the ICP vortex and Intel
RAID controllers. We released the new driver 3.04 with some important
changes. I send you the patch against kernel 2.4.25. Could you please
include the patch for the next kernel release?
The driver patch includes some important bug fixes.
ChangeSet@1.1567, 2004-09-20 13:54:51-03:00, lesanti@sinectis.com.ar
[PATCH] fix dcache nr_dentry race
Hi Marcelo,
The dentry_stat.nr_dentry counter isn't being properly protected against
concurrent access. We've been observing a drift of about 8000 units per
day on some large MP Maildir++ mailstore nodes.
The following (trivial) patch is pretty much a backport from 2.6.
ChangeSet@1.1566, 2004-09-20 13:36:46-03:00, joshk@triplehelix.org
[PATCH] hotplug: Don't build cpqphp_proc.o if !PROC_FS
This simple patch to drivers/hotplug/Makefile eliminates a build failure
for cpqphp if CONFIG_PROC_FS is disabled. Herbert Xu originally wrote
this patch.
Marcelo, please apply.
(Note: does not apply to 2.6 because stuff seems to have switched to
sysfs there.)
Signed-off-by: Joshua Kwan <joshk@triplehelix.org>
--
Joshua Kwan
# origin: Debian (herbert)
# cset: n/a
# inclusion: not submitted
# description: don't build cpqphp_proc.o if !PROC_FS
# revision date: 2004-09-05
ChangeSet@1.1565, 2004-09-20 13:35:24-03:00, joshk@triplehelix.org
[PATCH] radeonfb: Fix module unload and red/blue typo
Hello,
This patch fixes a blue -> red typo in radeonfb. For free, there's also
a one line hunk that sets the correct owner for the framebuffer. Herbert
Xu originally wrote this patch.
# origin: Debian (herbert)
# cset: n/a
# inclusion: not submitted
# description: set owner for radeonfb module, fix red/blue typo
# revision date: 2004-09-04
Hello,
This patch fixes a blue -> red typo in radeonfb. For free, there's also
a one line hunk that sets the correct owner for the framebuffer. Herbert
Xu originally wrote this patch.
Marcelo, please apply.
Signed-off-by: Joshua Kwan <joshk@triplehelix.org>
ChangeSet@1.1564, 2004-09-18 12:12:06-03:00, dledford@redhat.com
[PATCH] RAID1 error handling locking fix
OK, basic problem is that if you use mdadm to fail a device in a raid1
array and then immediately remove that device, you can end up triggering
a race condition in the raid1 code. This only shows up on SMP systems
(and the one I have here which is a 2 physical, 4 logical processor
system shows it very easily, but for some reason nmi_watchdog didn't
ever help and the system always just locked hard and refused to do
anything, so I didn't have an oops to work from, just a hardlock).
In the raid1 code, we keep an array of devices that are part of the
raid1 array. Each of these devices can have multiple states, but for
the most part we check the operational bit of a device before deciding
to use it. If we decide to use that device, then we grab the device
number from the array (kdev_t, aka this is the device's major/minor and
is what we are going to pass to generic_make_request in order to pass
the buffer head on to the underlying device).
When we fail a device, we set that operational bit to 0. When we remove
a device, we also set the dev item in the struct to MKDEV(0,0).
There is no locking whatsoever between the failing of a device (setting
the operational bit to 0) and the make_request functions in the raid1
code. So, even though it's safe to fail a device without this locking,
before we can safely remove the device we need to know that every
possible context that might be checking that operational bit has in fact
seen the failed operational bit. If not, then we can end up setting the
dev to 0, then the other context grabs it and tries to pass that off to
generic_make_request, unnice things ensue.
So, this patch does these things:
1. Whenever we are calling mark_disk_bad(), hold the
conf->device_lock
2. Whenever we are walking the device array looking for an
operational device, always grab the conf->device_lock first and
hold it until after we have gotten not only the operational bit
but also the dev number for the device
3. Correct an accounting problem in the superblock. If we fail a
device and it's currently counted as a spare device instead of
an active device, then we failed to decrement the superblocks
spare disk count. This accounting error is preserved across
shutdown and restart of the array, and although it doesn't oops
the kernel (the kernel will refuse to try and read beyond disk
26 even if the spare count indicates it should, although I'm not
sure it doesn't try and write past 26 so this could be a disk
corruptor when the spare count + active counts exceeds the
amount of space available in the on disk superblock format) it
does in fact cause mdadm to segfault on trying to read the
superblock.
So, that's the description. Testing. Well, without this patch, my test
machine dies on the following command *very* quickly:
while true; do mdadm /dev/md0 -f /dev/sdc1 -r /dev/sdc1 -a /dev/sdc1;
sleep 1; done
In addition, without the patch you can watch the superblock's spare
count go up with every single invocation of that command.
With my patch, the same machine survived the above command running over
the weekend, and in addition I mounted the raid1 array and ran a
continuous loop of bonnie++ sessions to generate as much load as
possible. I've verified that the spare count stays consistent when
failing a spare device, and I've verfied that once a device is synced up
then the spare count is also decremented as the device is switched to
being accounted as an active device.
ChangeSet@1.1563, 2004-09-18 12:05:11-03:00, vda@port.imtp.ilyichevsk.odessa.ua
[PATCH] trivial patch for 2.4: always inline __constant_*
Of these, at least the following were intended to be always inlined:
12 __constant_c_and_count_memset
6 __constant_memcpy
Prolly #include <linux/compiler.h> is missing in some files,
or included too late to have desired effect.
Let's find them:
find -name '*.o' | xargs grep -lF '__constant_c_and_count_memset'
find -name '*.o' | xargs grep -lF '__constant_memcpy'
} | sort | uniq
Redoing this with allyesconfig revealed some more files.
Most of them can be fixed with a single #include <compiler.h>
in <string.h>. Along the way, I fixed some non-compilation buglets.
I will submit those patches as replies now.
ChangeSet@1.1536.1.5, 2004-09-14 22:13:08-07:00, davem@nuts.davemloft.net
[TG3]: Update driver version and reldate.
ChangeSet@1.1536.1.4, 2004-09-14 22:12:20-07:00, davem@nuts.davemloft.net
[TG3]: Recognize all onboard Sun variants, not just 5704.
Based upon a report from Matthias Merz.
Signed-off-by: David S. Miller <davem@davemloft.net>
ChangeSet@1.1536.1.3, 2004-09-14 22:06:21-07:00, michael.waychison@sun.com
[TG3]: Fix thinko in 5704 fibre hw autoneg code.
Signed-off-by: Mike Waychison <michael.waychison@sun.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
ChangeSet@1.1543.1.7, 2004-09-14 22:40:21-04:00, ananth@broadcom.com
[libata sata_svw] race condition fix, new device support
* address race condition WRT order of DMA-start and ATA command issue
(see code comment for more details)
* Add support for Frodo 4/8
ChangeSet@1.1543.1.6, 2004-09-14 22:40:04-04:00, jgarzik@pobox.com
[libata] minor comment updates, preparing for iomap merge
ChangeSet@1.1560, 2004-09-14 16:01:44-03:00, khali@linux-fr.org
[PATCH] Update Documentation/i2c/writing-clients
Hi Marcelo,
This is a quick update to the Documentation/i2c/writing-clients file. A
similar change was accepted by Greg KH in 2.6 and was also applied to
the i2c CVS repository.
The changes are about i2c client driver IDs. It used to say that chip
driver writers should ask for a unique ID. It now explains that such an
ID is not required and they can go without it. The patch additionally
features CodingStyle updates.
Fell free to apply it if you want,
thanks.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
ChangeSet@1.1559, 2004-09-14 16:01:13-03:00, mikpe@csd.uu.se
[PATCH] matrox framebuffer driver gcc-3.4 fix
This patch fixes gcc-3.4 cast-as-lvalue warnings in the 2.4.28-pre3
kernel's matrox framebuffer driver. The changes are backports from
the 2.6 kernel. The warnings don't appear for x86, but they do appear
for ppc32.
/Mikael
ChangeSet@1.1558, 2004-09-14 16:00:45-03:00, mikpe@csd.uu.se
[PATCH] PPC32 PReP residual data gcc-3.4 fix
This patch fixes a gcc-3.4 cast-as-lvalue warning in the 2.4.28-pre3
kernel's arch/ppc/platform/residual.c. The change is a backport from
the 2.6 kernel.
/Mikael
ChangeSet@1.1557, 2004-09-14 16:00:25-03:00, mikpe@csd.uu.se
[PATCH] E100 driver gcc-3.4 fixes
This patch fixes gcc-3.4 "`__packed__' attribute ignored" warnings
in the 2.4.28-pre3 kernel's E100 ethernet driver. The changes are
new since the 2.6 E100 driver is different.
/Mikael
ChangeSet@1.1556, 2004-09-14 15:59:43-03:00, mikpe@csd.uu.se
[PATCH] RIVA driver gcc-3.4 fix
This patch fixes a gcc-3.4 cast-as-lvalue warning in the 2.4.28-pre3
kernel's RIVA video driver. The change is new since the 2.6 code is
different.
/Mikael
ChangeSet@1.1555, 2004-09-14 15:26:04-03:00, mikpe@csd.uu.se
[PATCH] MTD drivers gcc-3.4 fixes
This patch fixes gcc-3.4 cast-as-lvalue warnings in the 2.4.28-pre3
kernel's MTD drivers. The elan-104nc.c and sbc_gxx.c changes are
backports from the 2.6 kernel. The cfi_cmdset_0001.c and cfi_cmdset_0020.c
changes are new since the 2.6 code is different.
/Mikael
ChangeSet@1.1554, 2004-09-14 15:24:16-03:00, zaitcev@redhat.com
[PATCH] USB drivers gcc-3.4 fixes
ChangeSet@1.1553, 2004-09-14 15:21:26-03:00, mikpe@csd.uu.se
[PATCH] ISDN drivers gcc-3.4 fixes
This patch fixes gcc-3.4 cast-as-lvalue warnings in the 2.4.28-pre3
kernel's ISDN drivers. With the exception of eicon_idi.c, which
doesn't seem to be in the 2.6 kernel, the changes are all backports
from the 2.6 kernel.
/Mikael
ChangeSet@1.1552, 2004-09-14 15:06:34-03:00, mikpe@csd.uu.se
[PATCH] IBM PCI hotplug controller driver gcc-3.4 fixes
This patch fixes gcc-3.4 cast-as-lvalue warnings in the 2.4.28-pre3
kernel's IBM PCI hotplug controller driver. The changes are all
backports from the 2.6 kernel.
/Mikael
ChangeSet@1.1551, 2004-09-14 15:01:22-03:00, mikpe@csd.uu.se
[PATCH] ATM drivers gcc-3.4 fixes
This patch fixes gcc-3.4 cast-as-lvalue warnings in the 2.4.28-pre3
kernel's ATM drivers. The changes are backports from the 2.6 kernel.
Where the 2.4 and 2.6 kernels differ (->dev_data or ->phy_data for
private data), I have chosen to preserve 2.4's behaviour.
/Mikael
ChangeSet@1.1550, 2004-09-14 14:55:33-03:00, mikpe@csd.uu.se
[PATCH] pcmcia mem_op.h gcc-3.4 fixes
This patch fixes gcc-3.4 cast-as-lvalue warnings in the 2.4.28-pre3
kernel caused by include/pcmcia/mem_op.h. The changes are all
backports from the 2.6 kernel.
/Mikael
ChangeSet@1.1549, 2004-09-14 14:46:24-03:00, mikpe@csd.uu.se
[PATCH] 53c700 scsi driver gcc-3.4 fixes
This patch fixes gcc-3.4 cast-as-lvalue warnings in the 2.4.28-pre3
kernel's drivers/scsi/53c700.h. With the exception of NCR_700_set_SXFER(),
the changes are all backports from the 2.6 kernel.
/Mikael
ChangeSet@1.1548, 2004-09-14 14:20:22-03:00, Jack_Hammer@adaptec.com
[PATCH] broken ips update
This patch replaces the patch I submitted ( and then rescinded ) earlier
today. It fixes the compilation problem in 2.4.28 and includes the
changes recommended by Arjan on my earlier proposal for this.
ChangeSet@1.1543.1.5, 2004-09-13 23:31:21-04:00, jgarzik@pobox.com
[libata] consolidate legacy/native mode init code into helpers
Eliminates duplicate code in sata_nv, sata_sis, and sata_via.
ChangeSet@1.1543.1.4, 2004-09-13 22:35:25-04:00, jgarzik@pobox.com
[libata] remove distinction between MMIO/PIO helper functions
Prepare for use of new generic iomap API.
ChangeSet@1.1543.1.3, 2004-09-13 22:15:08-04:00, jgarzik@pobox.com
[libata] resync with 2.6.x
Only whitespace changes.
ChangeSet@1.1543.1.2, 2004-09-13 21:47:35-04:00, jgarzik@pobox.com
linux/compiler.h: dummy __iomem macro (an sparse annotation)
ChangeSet@1.1543.1.1, 2004-09-13 21:46:53-04:00, torvalds@ppc970.osdl.org
libata: initial PCI memory annotations
ChangeSet@1.1536.1.2, 2004-09-13 16:09:23-07:00, martin.wilck@fujitsu-siemens.com
[TG3]: Fix pause handling, we had duplicate flags for the same thing.
Signed-off-by: David S. Miller <davem@davemloft.net>
ChangeSet@1.1547, 2004-09-10 15:55:20-03:00, marcelo@logos.cnet
Changed EXTRAVERSION to -pre3
TAG: v2.4.28-pre3