Linux 2.6.14
Linus Torvalds
Ok, it's finally there.
2.6.14 was delayed twice due to some last-minute bug-reports, some of
which ended up being false alarms (hey, I should be happy, but it was a
bit frustrating)
But hey, the delays - even when perhaps unnecessary - got us to look at
the code and fix some other bugs instead. So it's all good.
So special thanks go to Oleg Nesterov and Roland McGrath for doing some
code inspection and fixing and just making the otherwise frustrating wait
for bug resolution more productive ;^p.
Let's try the 2-week merge window thing again, I think it worked pretty
well despite the delays, and hopefully it will work even better this time
around.
The actual changes from 2.6.14-rc5 are a number of mostly one-liners, with
the ShortLog appended (full log from 2.6.13 on the normal sites together
with the release itself). The only slightly bigger ones (ie more than a
handful of lines) is a kernel parameter doc update, and the PIIX4 PCI
quirk printouts, and the cleanups/fixes for the posix cpu timers.
(In fact, according to diffstat, about half the diff is that one
documentation update, and most of that is whitespace cleanups)
Linus
----
Alan Stern:
[SCSI] Fix leak of Scsi_Cmnds
Andrew Morton:
inotify/idr leak fix
alpha: atomic dependency fix
qlogic lockup fix
export cpu_online_map
svcsock timestamp fix
Ben Dooks:
[ARM] 3026/1: S3C2410 - avoid possible overflow in pll calculations
[ARM] 3027/1: BAST - reduce NAND timings slightly
[ARM] 3028/1: S3C2410 - add DCLK mask definitions
Benjamin Herrenschmidt:
ppc64: Fix pages marked dirty abusively
ppc64: Fix wrong register mapping in mpic driver
Bjorn Helgaas:
[SERIAL] support the Exsys EX-4055 4S four-port card
Chris Wright:
typo fix in last cpufreq powernow patch
Christoph Hellwig:
[SCSI] mptsas: fix phy identifiers
Dave Airlie:
drm: another mga bug
Dave Jones:
cpufreq: fix pending powernow timer stuck condition
cpufreq: SMP fix for conservative governor
Davi Arnaut:
SELinux: handle sel_make_bools() failure in selinuxfs
David Gibson:
ppc64: Fix typo bug in iSeries hash code
Eric Moore:
mptsas: fix phy identifiers
Herbert Xu:
[DCCP]: Use skb_set_owner_w in dccp_transmit_skb when skb->sk is NULL
[DCCP]: Make dccp_write_xmit always free the packet
[DCCP]: Clear the IPCB area
[TCP] Allow len == skb->len in tcp_fragment
[NEIGH] Print stack trace in neigh_add_timer
[NEIGH] Fix add_timer race in neigh_add_timer
[NEIGH] Fix timer leak in neigh_changeaddr
[TCP]: Clear stale pred_flags when snd_wnd changes
Hugh Dickins:
Fix handling spurious page fault for hugetlb region
Ian Campbell:
[ARM] 3032/1: sparse: complains about generic_fls() prototype in asm-arm/bitops.h
Ivan Kokshaysky:
alpha: additional smp barriers
fix radeon_cp_init_ring_buffer()
James Simmons:
Return the line length via sysfs for fbdev
James...@Emulex.Com:
[SCSI] FW: for Deadlock in transport_fc
Jeff Garzik:
kill massive wireless-related log spam
Jochen Friedrich:
[TR]: Preserve RIF flag even for 2 byte RIF fields.
[LLC]: Strip RIF flag from source MAC address
Julian Anastasov:
[SK_BUFF]: ipvs_property field must be copied
Justin Chen:
[SERIAL] new hp diva console port
Karl Magnus Kolstoe:
[SCSI] 2.6.13.3; add Pioneer DRM-624x to drivers/scsi/scsi_devinfo.c
Kostik Belousov:
aio syscalls are not checked by lsm
Linus Torvalds:
Revert "Fix cpu timers exit deadlock and races"
Posix timers: limit number of timers firing at once
cardbus: limit IO windows to 256 bytes
PCI: be more verbose about resource quirks
posix cpu timers: fix timer ordering
Revert "remove false BUG_ON() from run_posix_cpu_timers()"
Revert "x86-64: Avoid unnecessary double bouncing for swiotlb"
Linux v2.6.14
Magnus Damm:
NUMA: broken per cpu pageset counters
Matt Reimer:
[ARM] 3025/1: Add I2S platform device for PXA
Mike Krufky:
Kconfig: saa7134-dvb should not select cx22702
Miklos Szeredi:
uml: fix compile failure for TT mode
NeilBrown:
md: make sure mdthreads will always respond to kthread_stop
Oleg Nesterov:
posix-timers: fix cleanup_timers() and run_posix_cpu_timers() races
posix-timers: remove false BUG_ON() from run_posix_cpu_timers()
posix-timers: exit path cleanup
posix-timers: fix posix_cpu_timer_set() vs run_posix_cpu_timers() race
Fix cpu timers expiration time
Paul Mackerras:
ppc64: Fix typo in time calculations
Pavel Machek:
[ARM] fix sharp zaurus c-3000 compile failure without CONFIG_FB_PXA
Peter Wainwright:
Fix HFS+ to free up the space when a file is deleted.
Ralf Baechle:
[AX.25]: Fix signed char bug
Randy Dunlap:
[SCSI] NCR5380: fix undefined preprocessor identifier
kernel-parameters cleanup
Roland Dreier:
ib: mthca: Always re-arm EQs in mthca_tavor_interrupt()
Roland McGrath:
Call exit_itimers from do_exit, not __exit_signal
Yet more posix-cpu-timer fixes
Russell King:
[ARM] Fix Integrator IM/PD-1 support
Salyzyn, Mark:
[SCSI] Fix aacraid regression
Stephen Smalley:
selinux: Fix NULL deref in policydb_destroy
Steven Rostedt:
[SCSI] scsi_error thread exits in TASK_INTERRUPTIBLE state.
Takashi Iwai:
ALSA: Fix Oops of suspend/resume with generic drivers
Yan Zheng:
[IPV6]: Fix refcnt of struct ip6_flowlabel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Nigel Cunningham
Linus Torvalds
On Fri, 28 Oct 2005, Nigel Cunningham wrote:
>
> Could you please push the tag to kernel.org too? Thanks!
Sorry, forgot. Done,
Linus
Jean Delvare
Fix the following warning when ext3 fs is compiled without quota
support:
fs/ext3/super.c: In function `ext3_show_options':
fs/ext3/super.c:516: warning: unused variable `sbi'
Signed-off-by: Jean Delvare <kh...@linux-fr.org>
---
fs/ext3/super.c | 2 ++
1 file changed, 2 insertions(+)
--- linux-2.6.14.orig/fs/ext3/super.c 2005-10-28 18:25:56.000000000 +0200
+++ linux-2.6.14/fs/ext3/super.c 2005-10-28 18:38:36.000000000 +0200
@@ -513,7 +513,9 @@
static int ext3_show_options(struct seq_file *seq, struct vfsmount *vfs)
{
struct super_block *sb = vfs->mnt_sb;
+#ifdef CONFIG_QUOTA
struct ext3_sb_info *sbi = EXT3_SB(sb);
+#endif
if (test_opt(sb, DATA_FLAGS) == EXT3_MOUNT_JOURNAL_DATA)
seq_puts(seq, ",data=journal");
--
Jean Delvare
Ravikiran G Thirumalai
>
> Revert "x86-64: Avoid unnecessary double bouncing for swiotlb"
Well, Andi's patch here wasn't just a small optimization as the changelog
suggests. It helped EM64T boxes a great deal. Just to make sure, I
reran 2.6.14 with the attached patch and got about 45% better performance
with iozone Initial write. This was on a 2 cpu 4 thread SMP Xeon with 8G ram,
with 2 processes performing io to 4G files on a IDE drive.
Maybe it wouldn't have caused breakage on some AMD boxes if the following
additional check for swiotlb was added. Can this go into 2.6.15 please?
Thanks,
Kiran
Originally by Andi Kleen. Patch prevents the block layer from bouncing if
a hard or soft iommu is present.
Signed-off-by: Ravikiran Thirumalai <ki...@scalex86.org>
Index: linux-2.6.14/include/asm-x86_64/pci.h
===================================================================
--- linux-2.6.14.orig/include/asm-x86_64/pci.h 2005-10-27 17:02:08.000000000 -0700
+++ linux-2.6.14/include/asm-x86_64/pci.h 2005-10-27 21:42:41.000000000 -0700
@@ -51,9 +51,9 @@
* this boolean for bounce buffer decisions
*
* On AMD64 it mostly equals, but we set it to zero to tell some subsystems
- * that an IOMMU is available.
+ * that a hard or soft IOMMU is available.
*/
-#define PCI_DMA_BUS_IS_PHYS (no_iommu ? 1 : 0)
+#define PCI_DMA_BUS_IS_PHYS ((no_iommu && !swiotlb) ? 1 : 0)
/*
* x86-64 always supports DAC, but sometimes it is useful to force
Andi Kleen
> On Thu, Oct 27, 2005 at 05:28:50PM -0700, Linus Torvalds wrote:
> > Revert "x86-64: Avoid unnecessary double bouncing for swiotlb"
>
> (http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=com
>mitdiff;h=79b95a454bb5c1d9b7287d1016a70885ba3f346c)
>
> Well, Andi's patch here wasn't just a small optimization as the changelog
First to be honest swiotlb performance is not very high on the priority list.
It will always be bad. If you care about performance you should use devices
that can address all your memory.
EM64T server boxes shouldn't have big problems with that because they usually
support AHCI for IDE, and firewire/usb2/sound is not that critical. And the
EM64T boxes with other chipsets typically don't support >4G phys because they
only support the lowerend Intel CPUs. Summit might be an exception, but those
normally only use IDE for CDROMs, which are also not a big issue.
> Just to make sure, I
> reran 2.6.14 with the attached patch and got about 45% better performance
> with iozone Initial write. This was on a 2 cpu 4 thread SMP Xeon with 8G
> ram, with 2 processes performing io to 4G files on a IDE drive.
> Maybe it wouldn't have caused breakage on some AMD boxes if the following
> additional check for swiotlb was added. Can this go into 2.6.15 please?
Not in this form no. Problem first needs to be understood fully and
then no_iommu should be set properly.
> * On AMD64 it mostly equals, but we set it to zero to tell some
> subsystems - * that an IOMMU is available.
> + * that a hard or soft IOMMU is available.
> */
> -#define PCI_DMA_BUS_IS_PHYS (no_iommu ? 1 : 0)
> +#define PCI_DMA_BUS_IS_PHYS ((no_iommu && !swiotlb) ? 1 : 0)
That is ugly and I don't like it. Need to track down the real problem
-Andi
Borislav Petkov
>
the ehci usb host controller saying:
<snip>
...
[4294691.834000] usb usb3: Product: UHCI Host Controller
[4294691.840000] usb usb3: Manufacturer: Linux 2.6.14 uhci_hcd
[4294691.847000] usb usb3: SerialNumber: 0000:00:1d.2
[4294691.880000] hub 3-0:1.0: USB hub found
[4294691.885000] hub 3-0:1.0: 2 ports detected
[4294694.855000] ACPI: PCI Interrupt 0000:00:1d.7[D] -> GSI 23 (level,
low) -> IRQ 20
[4294694.864000] ehci_hcd 0000:00:1d.7: EHCI Host Controller
[4294694.870000] ehci_hcd 0000:00:1d.7: debug port 1
</snip>
and dies. This bug is actually in there since 2.6.14-rc4 (see:
http://bugzilla.kernel.org/show_bug.cgi?id=5428) and David Brownell
supplied a patch which turned out to be useless eventually since _rebooting_
the kernel with the 'usb-handoff' (and without the patch) solved the problem.
As it turns out, it actually solves the problem only for the reboot case.
My machine still hangs on an initial boot with and without 'usb-handoff'.
.config attached.
Regards,
Boris.
Aleksey Gorelov
Boris,
While running with 'usb-handoff' turned on, do you see something like
"EHCI early BIOS handoff failed" (in power on or reboot cases) ?
Aleks.
>
>Regards,
> Boris.
Ravikiran G Thirumalai
> On Saturday 29 October 2005 00:58, Ravikiran G Thirumalai wrote:
> > On Thu, Oct 27, 2005 at 05:28:50PM -0700, Linus Torvalds wrote:
> > > Revert "x86-64: Avoid unnecessary double bouncing for swiotlb"
> >
> > (http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=com
> >mitdiff;h=79b95a454bb5c1d9b7287d1016a70885ba3f346c)
> >
> > Well, Andi's patch here wasn't just a small optimization as the changelog
> > suggests. It helped EM64T boxes a great deal. \
>
> First to be honest swiotlb performance is not very high on the priority list.
> It will always be bad. If you care about performance you should use devices
> that can address all your memory.
I realise swiotlb will have bad performance. But with the revert, swiotlb
is not going to be used at all!!. PCI_DMA_BUS_IS_PHYS is used by the block
subsystem to check if any kind of iommu (soft or hard) is available. If none
is present, block layer uses the ISA pool for bounce buffering bringing down
performance.
>
> EM64T server boxes shouldn't have big problems with that because they usually
> support AHCI for IDE, and firewire/usb2/sound is not that critical.
But you have to use SATA disks to use AHCI right?. IDE disks will work with
32bit dma addresses only (please correct me if I am wrong). And I belive
there are 1U racks/blades out there with IDE disks on these server boards with
more than 4G memory (I am told it saves them $$ to use IDE disks over SATA
when you deploy large numbers).
Whatever the reasons might be, IMHO, it is not correct to assume no one is
going to use 32 bit capable only devices on 64bit boxes. swiotlb code need
not have been in the kernel otherwise. This one line revert is just force
turning off swiotlb on x86_64 boxes with no option whatsover :(
> EM64T boxes with other chipsets typically don't support >4G phys because they
> only support the lowerend Intel CPUs. Summit might be an exception, but those
> normally only use IDE for CDROMs, which are also not a big issue.
>
> > Just to make sure, I
> > reran 2.6.14 with the attached patch and got about 45% better performance
> > with iozone Initial write. This was on a 2 cpu 4 thread SMP Xeon with 8G
> > ram, with 2 processes performing io to 4G files on a IDE drive.
> > Maybe it wouldn't have caused breakage on some AMD boxes if the following
> > additional check for swiotlb was added. Can this go into 2.6.15 please?
>
> Not in this form no. Problem first needs to be understood fully and
> then no_iommu should be set properly.
>
> > * On AMD64 it mostly equals, but we set it to zero to tell some
> > subsystems - * that an IOMMU is available.
> > + * that a hard or soft IOMMU is available.
> > */
> > -#define PCI_DMA_BUS_IS_PHYS (no_iommu ? 1 : 0)
> > +#define PCI_DMA_BUS_IS_PHYS ((no_iommu && !swiotlb) ? 1 : 0)
>
> That is ugly and I don't like it. Need to track down the real problem
I agree it is ugly. But it atleast shows and does what the comment says.
Is reverting a bug-fix to mask another bug (probably due to a broken bios or
user not setting the IOMMU in the bios) any cleaner? Yes it doesn't show
though ;)
Seriously, are there plans to fix the broken AMD boxes for 2.6.15? Will
swiotlb be forced off even for 2.6.15? Linus, Andrew?
Thanks,
Kiran
Borislav Petkov
nothing of the like in the serial console log.
Regards,
Boris.
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
David Brownell
> > >and dies. This bug is actually in there since 2.6.14-rc4 (see:
> > >http://bugzilla.kernel.org/show_bug.cgi?id=5428) and David Brownell
> > >supplied a patch which turned out to be useless eventually
> > >since _rebooting_
> > >the kernel with the 'usb-handoff' (and without the patch)
> > >solved the problem.
In current GIT kernels (2.6.14+) that patch is now merged, and
also usb-handoff is the default.
> > >As it turns out, it actually solves the problem only for the
> > >reboot case.
> > >My machine still hangs on an initial boot with and without
> > >'usb-handoff'.
Huh? That's not what you'd reported before. What changed?
You're saying that _with_ that patch, and usb-handoff, it fails?
> > While running with 'usb-handoff' turned on, do you see something like
> > "EHCI early BIOS handoff failed" (in power on or reboot cases) ?
>
> Nope, nothing of the like in the serial console log.
If the problem was IRQs getting somehow enabled after the handoff,
that patch would probably be a very useful thing. If that does
help, I'll suggest that be merged into 2.6.14.x ... it'd have been
good to merge for 2.6.14.0 but quick merges seem mostly to be a
thing of the past any more.
- Dave
Borislav Petkov
> On Monday 31 October 2005 2:15 pm, Borislav Petkov wrote:
> > > >and dies. This bug is actually in there since 2.6.14-rc4 (see:
> > > >http://bugzilla.kernel.org/show_bug.cgi?id=5428) and David Brownell
> > > >supplied a patch which turned out to be useless eventually
> > > >since _rebooting_
> > > >the kernel with the 'usb-handoff' (and without the patch)
> > > >solved the problem.
>
> In current GIT kernels (2.6.14+) that patch is now merged, and
> also usb-handoff is the default.
the same point in the boot process.
>
>
> > > >As it turns out, it actually solves the problem only for the
> > > >reboot case.
> > > >My machine still hangs on an initial boot with and without
> > > >'usb-handoff'.
>
> Huh? That's not what you'd reported before. What changed?
> You're saying that _with_ that patch, and usb-handoff, it fails?
First, we did some testing with 2.6.14-rc4, _with_ the patch and the
'handoff' cmd option and it worked. Then, several boots later, I noticed
that it started hanging itself again at the same position not while rebooting
but at _initial_ boot in the morning. Then, you told me on bugzilla that
in my case the patch shouldn't be needed since i'm using 'usb-handoff'
but, unfortunately, without the patch and with usb-handoff it hangs itself too.
2.6.14 shows the same behavior and the git kernel i compiled this morning hangs
itself too, as i said above.
To sum up, IMHO, the patch helps partially only while rebooting. Initial
boots still remain hanging so there's got to be something else that
kills the machine. maybe some IRQs or something? The thing is that not
even sysrq is functional, I don't get any BUG() traces or anything -
the hang is pretty tough. 2.6.13, in contrast, boots just fine. Hope
that helps,
Boris.
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
David Brownell
> Yeah, the symptoms are really weird. Let me rehash the whole history:
> First, we did some testing with 2.6.14-rc4, _with_ the patch and the
> 'handoff' cmd option and it worked. Then, several boots later, I noticed
> that it started hanging itself again at the same position not while rebooting
So you're saying your hardware doesn't act consistently.
Is there a BIOS update you can try? The failure sure seems
to be board-specific.
> ... 2.6.13, in contrast, boots just fine. Hope
> that helps,
Well that's news, and not mentioned in the bug report; in fact, you
said explicitly that it _never_ worked on earlier kernels (see your
comment #2).
This means you could use "git bisect" to point a finger at a patch that,
if it doesn't actually cause the problem, at least surfaces a latent bug
in other code. Could you please try that?
I'm starting to suspect some IRQ setup problem here; those are classically
issues in ACPI code, even when the breakage shows only with USB.
- Dave
Borislav Petkov
> On Tuesday 01 November 2005 3:23 am, Borislav Petkov wrote:
> > Yeah, the symptoms are really weird. Let me rehash the whole history:
> > First, we did some testing with 2.6.14-rc4, _with_ the patch and the
> > 'handoff' cmd option and it worked. Then, several boots later, I noticed
> > that it started hanging itself again at the same position not while rebooting
> > but at _initial_ boot in the morning. ...
>
> So you're saying your hardware doesn't act consistently.
> Is there a BIOS update you can try? The failure sure seems
> to be board-specific.
just fine.
>
>
> > ... 2.6.13, in contrast, boots just fine. Hope
> > that helps,
>
> Well that's news, and not mentioned in the bug report; in fact, you
> said explicitly that it _never_ worked on earlier kernels (see your
> comment #2).
where..", sorry.
> This means you could use "git bisect" to point a finger at a patch that,
> if it doesn't actually cause the problem, at least surfaces a latent bug
> in other code. Could you please try that?
>
> I'm starting to suspect some IRQ setup problem here; those are classically
> issues in ACPI code, even when the breakage shows only with USB.
This is superfluous, I guess, now that 2.6.14 boots.
Thanks for your help.
Regards,
Boris.
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
Andi Kleen
> I agree it is ugly. But it atleast shows and does what the comment says.
> Is reverting a bug-fix to mask another bug (probably due to a broken bios
> or user not setting the IOMMU in the bios) any cleaner? Yes it doesn't
> show though ;)
I don't believe the problem is the AMD boxes here.
Anyways, with the dma_ops patch we can probably separate it cleanly
and avoid the problem.
-Andi
Muli Ben-Yehuda
> Anyways, with the dma_ops patch we can probably separate it cleanly
> and avoid the problem.
Hi Andi, Kiran, would something like:
#define PCI_DMA_BUS_IS_PHYS (mapping_ops->bus_is_phys)
do the job, where mapping_ops->bus_is_phys is set to 0 for gart and
swiotlb, and 1 for nommu?
Cheers,
Muli
--
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/
Jens Axboe
> Hi Jens,
>
> I just hit a badness (actually, tons of badness like this) in as-iosched
> while ripping
> an audio CD with ripperX (with cdparanoia as a backend).
> I was using 2.6.14 on an IBM Thinkpad R52. The kernel has been compiled with
> gcc-4.0.2-2 (Debian testing).
>
> The first badness in dmesg is:
>
> cdrom: dropping to single frame dma
> arq->state: 4
> Badness in as_insert_request at drivers/block/as-iosched.c:1519
> [<c0237410>] as_insert_request+0x70/0x1d0
> [<c022dc25>] __elv_add_request+0xa5/0xe0
> [<c022dc8b>] elv_add_request+0x2b/0x40
> [<c0230fe6>] blk_execute_rq_nowait+0x46/0x60
> [<c023107a>] blk_execute_rq+0x7a/0xe0
> [<c0231310>] blk_end_sync_rq+0x0/0x30
> [<c0160b77>] bio_phys_segments+0x27/0x30
> [<c0232610>] blk_rq_bio_prep+0x40/0xb0
> [<c0230dc7>] blk_rq_map_user+0xb7/0xf0
> [<c026bc32>] cdrom_read_cdda_bpc+0x182/0x210
> [<c026bd1b>] cdrom_read_cdda+0x5b/0xc0
Similar case was posted yesterday (I realize yours is older, just missed
it the first time around), see my explanation here:
http://lkml.org/lkml/2005/11/20/119
And work-around below.
diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
index 1539603..7540d27 100644
--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
@@ -2089,7 +2089,7 @@ static int cdrom_read_cdda_bpc(struct cd
int lba, int nframes)
{
request_queue_t *q = cdi->disk->queue;
- struct request *rq;
+ struct request *rq = NULL;
struct bio *bio;
unsigned int len;
int nr, ret = 0;
@@ -2097,13 +2097,13 @@ static int cdrom_read_cdda_bpc(struct cd
if (!q)
return -ENXIO;
- rq = blk_get_request(q, READ, GFP_KERNEL);
- if (!rq)
- return -ENOMEM;
-
cdi->last_sense = 0;
while (nframes) {
+ rq = blk_get_request(q, READ, GFP_KERNEL);
+ if (!rq)
+ return -ENOMEM;
+
nr = nframes;
if (cdi->cdda_method == CDDA_BPC_SINGLE)
nr = 1;
@@ -2151,9 +2151,13 @@ static int cdrom_read_cdda_bpc(struct cd
nframes -= nr;
lba += nr;
ubuf += len;
+ blk_put_request(rq);
+ rq = NULL;
}
- blk_put_request(rq);
+ if (rq)
+ blk_put_request(rq);
+
return ret;
}
--
Jens Axboe
Jens Axboe
> Is this patch going to -stable ?
Probably just killing the 'as' printk is a lot better for -stable.
Signed-off-by: Jens Axboe <ax...@suse.de>
--- linux-2.6.14/drivers/block/as-iosched.c~ 2005-11-21 16:38:36.000000000 +0100
+++ linux-2.6.14/drivers/block/as-iosched.c 2005-11-21 16:39:07.000000000 +0100
@@ -1513,13 +1513,8 @@
struct as_data *ad = q->elevator->elevator_data;
struct as_rq *arq = RQ_DATA(rq);
- if (arq) {
- if (arq->state != AS_RQ_PRESCHED) {
- printk("arq->state: %d\n", arq->state);
- WARN_ON(1);
- }
+ if (arq)
arq->state = AS_RQ_NEW;
- }
/* barriers must flush the reorder queue */
if (unlikely(rq->flags & (REQ_SOFTBARRIER | REQ_HARDBARRIER)
Brice Goglin
Thank you very much, Jens.
Is this patch going to -stable ?
Brice Goglin