powerpc allyesconfig fails on the following two drivers (iseries_defconfig
fails for the veth one):

drivers/net/ehea/ehea_main.c: In function 'ehea_driver_sysfs_add':
drivers/net/ehea/ehea_main.c:2812: error: 'struct device_driver' has no member named 'kobj'
drivers/net/ehea/ehea_main.c:2815: error: 'struct device_driver' has no member named 'kobj'
drivers/net/ehea/ehea_main.c:2818: error: 'struct device_driver' has no member named 'kobj'
drivers/net/ehea/ehea_main.c: In function 'ehea_driver_sysfs_remove':
drivers/net/ehea/ehea_main.c:2830: error: 'struct device_driver' has no member named 'kobj'
drivers/net/iseries_veth.c: In function 'veth_module_init':
drivers/net/iseries_veth.c:1714: error: 'struct device_driver' has no member named 'kobj'

I'm guessing it's some of Greg's kobj/driver patches that missed to
change this, but it's not obvious to me how it should be fixed.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Wed, Dec 05, 2007 at 03:15:15AM -0600, Olof Johansson wrote:
> powerpc allyesconfig fails on the following two drivers (iseries_defconfig
> fails for the veth one):
>
> drivers/net/ehea/ehea_main.c: In function 'ehea_driver_sysfs_add':
> drivers/net/ehea/ehea_main.c:2812: error: 'struct device_driver' has no member named 'kobj'
> drivers/net/ehea/ehea_main.c:2815: error: 'struct device_driver' has no member named 'kobj'
> drivers/net/ehea/ehea_main.c:2818: error: 'struct device_driver' has no member named 'kobj'
> drivers/net/ehea/ehea_main.c: In function 'ehea_driver_sysfs_remove':
> drivers/net/ehea/ehea_main.c:2830: error: 'struct device_driver' has no member named 'kobj'
> drivers/net/iseries_veth.c: In function 'veth_module_init':
> drivers/net/iseries_veth.c:1714: error: 'struct device_driver' has no member named 'kobj'
>
> I'm guessing it's some of Greg's kobj/driver patches that missed to
> change this, but it's not obvious to me how it should be fixed.
>
>
> -Olof
Hi,

Probably this patch should fix the build failure (The kobject related
structure have been moved to driver_private struct).

Signed-off-by: Kamalesh Babulal
--
--- linux-2.6.24-rc4/drivers/net/ehea/ehea_main.c 2007-12-04 09:56:10.000000000 +0530
+++ linux-2.6.24-rc4/drivers/net/ehea/~ehea_main.c 2007-12-05 18:01:31.000000000 +0530
@@ -2809,7 +2809,7 @@ static int ehea_driver_sysfs_add(struct
{
int ret;

- ret = sysfs_create_link(&driver->kobj, &dev->kobj,
+ ret = sysfs_create_link(&driver->driver_private->kobj, &dev->kobj,
kobject_name(&dev->kobj));
if (ret == 0) {
ret = sysfs_create_link(&dev->kobj, &driver->kobj,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Hi Andrew,

The 2.6.24-rc4-mm1 kernel build fails with build failure,

CC drivers/char/hvcs.o
drivers/char/hvcs.c: In function ‘hvcs_open’:
drivers/char/hvcs.c:1180: error: wrong type argument to unary exclamation mark
make[2]: *** [drivers/char/hvcs.o] Error 1
make[1]: *** [drivers/char] Error 2
make: *** [drivers] Error 2

The kref_get begin void return type, check for the kobject return type
as in the previous kobject_get()

if (!kref_get(&hvcsd->kref)) {
spin_unlock_irqrestore(&hvcsd->lock, flags);
printk(KERN_ERR "HVCS: Kobject of open"
" hvcs doesn't exist.\n");
return -EFAULT; /* Is this the right return value? */
}

I have tested for the build failure only.

Signed-off-by: Kamalesh Babulal
--
--- linux-2.6.24-rc4/drivers/char/hvcs.c 2007-12-05 12:17:37.000000000 +0530
+++ linux-2.6.24-rc4/drivers/char/~hvcs.c 2007-12-05 19:17:12.000000000 +0530
@@ -1177,12 +1177,8 @@ fast_open:
hvcsd = tty->driver_data;

spin_lock_irqsave(&hvcsd->lock, flags);
- if (!kref_get(&hvcsd->kref)) {
- spin_unlock_irqrestore(&hvcsd->lock, flags);
- printk(KERN_ERR "HVCS: Kobject of open"
- " hvcs doesn't exist.\n");
- return -EFAULT; /* Is this the right return value? */
- }
+ kref_get(&hvcsd->kref);
+ spin_unlock_irqrestore(&hvcsd->lock, flags);

hvcsd->open_count++;

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Wed, Dec 05, 2007 at 07:42:02PM +0530, Kamalesh Babulal wrote:
> Hi Andrew,
>
> The 2.6.24-rc4-mm1 kernel build fails with build failure,
>
> CC drivers/char/hvcs.o
> drivers/char/hvcs.c: In function ‘hvcs_open’:
> drivers/char/hvcs.c:1180: error: wrong type argument to unary exclamation mark
> make[2]: *** [drivers/char/hvcs.o] Error 1
> make[1]: *** [drivers/char] Error 2
> make: *** [drivers] Error 2

Oops, sorry about that, my fault. I'll merge your fix in with my
original patch, thanks for it.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Wed, Dec 05, 2007 at 06:41:40PM +0530, Kamalesh Babulal wrote:
> On Wed, Dec 05, 2007 at 03:15:15AM -0600, Olof Johansson wrote:
> > powerpc allyesconfig fails on the following two drivers (iseries_defconfig
> > fails for the veth one):
> >
> > drivers/net/ehea/ehea_main.c: In function 'ehea_driver_sysfs_add':
> > drivers/net/ehea/ehea_main.c:2812: error: 'struct device_driver' has no member named 'kobj'
> > drivers/net/ehea/ehea_main.c:2815: error: 'struct device_driver' has no member named 'kobj'
> > drivers/net/ehea/ehea_main.c:2818: error: 'struct device_driver' has no member named 'kobj'
> > drivers/net/ehea/ehea_main.c: In function 'ehea_driver_sysfs_remove':
> > drivers/net/ehea/ehea_main.c:2830: error: 'struct device_driver' has no member named 'kobj'
> > drivers/net/iseries_veth.c: In function 'veth_module_init':
> > drivers/net/iseries_veth.c:1714: error: 'struct device_driver' has no member named 'kobj'
> >
> > I'm guessing it's some of Greg's kobj/driver patches that missed to
> > change this, but it's not obvious to me how it should be fixed.
> >
> >
> > -Olof
> Hi,
>
> Probably this patch should fix the build failure (The kobject related
> structure have been moved to driver_private struct).

Yes, but as driver_private is not known by any driver, I don't think
this patch will work at all.

> Signed-off-by: Kamalesh Babulal
> --
> --- linux-2.6.24-rc4/drivers/net/ehea/ehea_main.c 2007-12-04 09:56:10.000000000 +0530
> +++ linux-2.6.24-rc4/drivers/net/ehea/~ehea_main.c 2007-12-05 18:01:31.000000000 +0530
> @@ -2809,7 +2809,7 @@ static int ehea_driver_sysfs_add(struct
> {
> int ret;
>
> - ret = sysfs_create_link(&driver->kobj, &dev->kobj,
> + ret = sysfs_create_link(&driver->driver_private->kobj, &dev->kobj,
> kobject_name(&dev->kobj));

What are you trying to do here? The driver core already sets up this
symlink for you automatically, why are you createing yet-another-link
with a different name? This should just be removed entirely, it's not
needed at all.

So, to fix the build properly, just delete the sysfs_create_link() call
entirely.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

> git-scsi-misc.patch

Apologies for not looking into the problem earlier. See
http://marc.info/?t=119628022300005&r=1&w=2
"2.6.24-rc3-mm2: Result: hostbyte=0x01 driverbyte=0x00\nend_request: I/O error"
for previous installment.

I've bisected it to the following patch in git-scsi-misc branch.
Revert on top of 2.6.24-rc4-mm1 also helps.

commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0
Author: Hannes Reinecke
Date: Tue Nov 6 09:23:40 2007 +0100

[SCSI] Do not requeue requests if REQ_FAILFAST is set

Any requests with the REQ_FAILFAST flag set should not be requeued
to the requeust queue, but rather terminated directly.
Otherwise the multipath failover will stall until the command
timeout triggers.

Signed-off-by: Hannes Reinecke
Signed-off-by: James Bottomley

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 0f44bdb..0da0dd0 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1286,6 +1286,11 @@ int scsi_prep_state_check(struct scsi_device *sdev, struct request *req)
*/
if (!(req->cmd_flags & REQ_PREEMPT))
ret = BLKPREP_DEFER;
+ /*
+ * Return failfast requests immediately
+ */
+ if (req->cmd_flags & REQ_FAILFAST)
+ ret = BLKPREP_KILL;
break;
default:
/*
@@ -1414,6 +1419,17 @@ static inline int scsi_host_queue_ready(struct request_queue *q,
return 1;
}

+static void __scsi_kill_request(struct request *req)
+{
+ struct scsi_cmnd *cmd = req->special;
+ struct scsi_device *sdev = cmd->device;
+
+ cmd->result = DID_NO_CONNECT << 16;
+ atomic_inc(&cmd->device->iorequest_cnt);
+ sdev->device_busy--;
+ __scsi_done(cmd);
+}
+
/*
* Kill a request for a dead device
*/
@@ -1527,8 +1543,16 @@ static void scsi_request_fn(struct request_queue *q)
* accept it.
*/
req = elv_next_request(q);
- if (!req || !scsi_dev_queue_ready(q, sdev))
+ if (!req)
+ break;
+
+ if (!scsi_dev_queue_ready(q, sdev)) {
+ if (req->cmd_flags & REQ_FAILFAST) {
+ scsi_kill_request(req, q);
+ continue;
+ }
break;
+ }

if (unlikely(!scsi_device_online(sdev))) {
sdev_printk(KERN_ERR, sdev,
@@ -1609,8 +1633,12 @@ static void scsi_request_fn(struct request_queue *q)
* later time.
*/
spin_lock_irq(q->queue_lock);
- blk_requeue_request(q, req);
- sdev->device_busy--;
+ if (unlikely(req->cmd_flags & REQ_FAILFAST))
+ __scsi_kill_request(req);
+ else {
+ blk_requeue_request(q, req);
+ sdev->device_busy--;
+ }
if(sdev->device_busy == 0)
blk_plug_device(q);
out:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Hi Andrew,

The 2.6.24-rc4-mm1 kernel build fails on s390x,

CC arch/s390/kernel/traps.o
In file included from include/asm/thread_info.h:39,
from include/linux/thread_info.h:21,
from include/linux/preempt.h:9,
from include/linux/spinlock.h:49,
from include/linux/seqlock.h:29,
from include/linux/time.h:8,
from include/linux/timex.h:57,
from include/linux/sched.h:53,
from arch/s390/kernel/traps.c:17:
include/asm/processor.h:191: warning: "struct seq_file" declared inside parameter list
include/asm/processor.h:191: warning: its scope is only this definition or declaration, which is probably not what you want
arch/s390/kernel/traps.c: In function `task_show_regs':
arch/s390/kernel/traps.c:226: error: implicit declaration of function `seq_printf'
make[1]: *** [arch/s390/kernel/traps.o] Error 1
make: *** [arch/s390/kernel] Error 2

--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On 5/12/2007 4:17 PM, Andrew Morton wrote:
> Temporarily at
>
> http://userweb.kernel.org/~akpm/2.6.24-rc4-mm1/
>
> Will appear later at
>
> ftp://ftp.kernel.org/pub/linux/kerne....6.24-rc4-mm1/
>
>
> - Lots of device IDs have been removed from the e1000 driver and moved over
> to e1000e. So if your e1000 stops working, you forgot to set CONFIG_E1000E.

This non fatal oops which I have just noticed may be related to this change then
- certainly looks networking related.

WARNING: at net/ipv4/tcp_input.c:2518 tcp_fastretrans_alert()
Pid: 0, comm: swapper Not tainted 2.6.24-rc4-mm1 #1

Call Trace:
[] tcp_fastretrans_alert+0x229/0xe63
[] tcp_ack+0xa3f/0x127d
[] tcp_rcv_established+0x55f/0x7f8
[] tcp_v4_do_rcv+0xdb/0x3a7
[] :nf_conntrack:nf_ct_deliver_cached_events+0x75/0x99
[] :nf_conntrack_ipv4:ipv4_confirm+0x29/0x51
[] tcp_v4_rcv+0x9be/0xaed
[] nf_hook_slow+0x60/0xdf
[] ip_local_deliver_finish+0xd3/0x253
[] ip_local_deliver+0x3b/0x85
[] ip_rcv_finish+0x119/0x3b8
[] ip_rcv+0x231/0x30c
[] netif_receive_skb+0x215/0x299
[] :e1000e:e1000_receive_skb+0x4d/0x1db
[] :e1000e:e1000_clean_rx_irq+0x12c/0x341
[] :e1000e:e1000_clean+0x306/0x58f
[] rebalance_domains+0xec/0x423
[] handle_edge_irq+0x97/0x13b
[] net_rx_action+0xb8/0x11d
[] __do_softirq+0x71/0xdd
[] call_softirq+0x1c/0x30
[] do_softirq+0x3d/0x8d
[] irq_exit+0x84/0x86
[] do_IRQ+0x7e/0xe4
[] mwait_idle+0x0/0x58
[] default_idle+0x0/0x43
[] ret_from_intr+0x0/0xa
[] mwait_idle+0x48/0x58
[] enter_idle+0x22/0x24
[] cpu_idle+0x63/0x88
[] rest_init+0x55/0x60
[] start_kernel+0x2a4/0x32a
[] _sinittext+0x10b/0x120

tornado home #

I have posted a full dmesg up as well as my .config and an lcpci at
http://www.reub.net/files/kernel/2.6.24-rc4-mm1/ .

Thanks,
Reuben
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

From: Reuben Farrelly
Date: Thu, 06 Dec 2007 17:59:37 +1100

> On 5/12/2007 4:17 PM, Andrew Morton wrote:
> > - Lots of device IDs have been removed from the e1000 driver and moved over
> > to e1000e. So if your e1000 stops working, you forgot to set CONFIG_E1000E.
>
> This non fatal oops which I have just noticed may be related to this change then
> - certainly looks networking related.
>
> WARNING: at net/ipv4/tcp_input.c:2518 tcp_fastretrans_alert()
> Pid: 0, comm: swapper Not tainted 2.6.24-rc4-mm1 #1
>
> Call Trace:
> [] tcp_fastretrans_alert+0x229/0xe63
> [] tcp_ack+0xa3f/0x127d
> [] tcp_rcv_established+0x55f/0x7f8
> [] tcp_v4_do_rcv+0xdb/0x3a7
> [] :nf_conntrack:nf_ct_deliver_cached_events+0x75/0x99

No, it's from TCP assertions and changes added by Ilpo to the
net-2.6.25 tree recently.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Thu, 06 Dec 2007 08:45:37 +0530 Kamalesh Babulal wrote:

> Hi Andrew,
>
> The 2.6.24-rc4-mm1 kernel build fails on s390x,
>
> CC arch/s390/kernel/traps.o
> In file included from include/asm/thread_info.h:39,
> from include/linux/thread_info.h:21,
> from include/linux/preempt.h:9,
> from include/linux/spinlock.h:49,
> from include/linux/seqlock.h:29,
> from include/linux/time.h:8,
> from include/linux/timex.h:57,
> from include/linux/sched.h:53,
> from arch/s390/kernel/traps.c:17:
> include/asm/processor.h:191: warning: "struct seq_file" declared inside parameter list
> include/asm/processor.h:191: warning: its scope is only this definition or declaration, which is probably not what you want
> arch/s390/kernel/traps.c: In function `task_show_regs':
> arch/s390/kernel/traps.c:226: error: implicit declaration of function `seq_printf'
> make[1]: *** [arch/s390/kernel/traps.o] Error 1
> make: *** [arch/s390/kernel] Error 2

thanks.

--- a/arch/s390/kernel/traps.c~proc-seqfile-convert-proc_pid_status-to-properly-handle-pid-namespaces-fix-2
+++ a/arch/s390/kernel/traps.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
#include
diff -puN include/asm-s390/processor.h~proc-seqfile-convert-proc_pid_status-to-properly-handle-pid-namespaces-fix-2 include/asm-s390/processor.h
--- a/include/asm-s390/processor.h~proc-seqfile-convert-proc_pid_status-to-properly-handle-pid-namespaces-fix-2
+++ a/include/asm-s390/processor.h
@@ -165,6 +165,7 @@ struct stack_frame {
/* Forward declaration, a strange C thing */
struct task_struct;
struct mm_struct;
+struct seq_file;

/* Free all resources held by a thread. */
extern void release_thread(struct task_struct *);
_


Unfortunately the current greg-versus-git-s390 snafu means that I'm not
cross-building s390.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Thu, 06 Dec 2007 17:59:37 +1100 Reuben Farrelly wrote:

> On 5/12/2007 4:17 PM, Andrew Morton wrote:
> > Temporarily at
> >
> > http://userweb.kernel.org/~akpm/2.6.24-rc4-mm1/
> >
> > Will appear later at
> >
> > ftp://ftp.kernel.org/pub/linux/kerne....6.24-rc4-mm1/
> >
> >
> > - Lots of device IDs have been removed from the e1000 driver and moved over
> > to e1000e. So if your e1000 stops working, you forgot to set CONFIG_E1000E.
>
> This non fatal oops which I have just noticed may be related to this change then
> - certainly looks networking related.

yep, but it isn't e1000. It's core TCP.

> WARNING: at net/ipv4/tcp_input.c:2518 tcp_fastretrans_alert()
> Pid: 0, comm: swapper Not tainted 2.6.24-rc4-mm1 #1
>
> Call Trace:
> [] tcp_fastretrans_alert+0x229/0xe63
> [] tcp_ack+0xa3f/0x127d
> [] tcp_rcv_established+0x55f/0x7f8
> [] tcp_v4_do_rcv+0xdb/0x3a7
> [] :nf_conntrack:nf_ct_deliver_cached_events+0x75/0x99
> [] :nf_conntrack_ipv4:ipv4_confirm+0x29/0x51
> [] tcp_v4_rcv+0x9be/0xaed
> [] nf_hook_slow+0x60/0xdf
> [] ip_local_deliver_finish+0xd3/0x253
> [] ip_local_deliver+0x3b/0x85
> [] ip_rcv_finish+0x119/0x3b8
> [] ip_rcv+0x231/0x30c
> [] netif_receive_skb+0x215/0x299
> [] :e1000e:e1000_receive_skb+0x4d/0x1db
> [] :e1000e:e1000_clean_rx_irq+0x12c/0x341
> [] :e1000e:e1000_clean+0x306/0x58f
> [] rebalance_domains+0xec/0x423
> [] handle_edge_irq+0x97/0x13b
> [] net_rx_action+0xb8/0x11d
> [] __do_softirq+0x71/0xdd
> [] call_softirq+0x1c/0x30
> [] do_softirq+0x3d/0x8d
> [] irq_exit+0x84/0x86
> [] do_IRQ+0x7e/0xe4
> [] mwait_idle+0x0/0x58
> [] default_idle+0x0/0x43
> [] ret_from_intr+0x0/0xa
> [] mwait_idle+0x48/0x58
> [] enter_idle+0x22/0x24
> [] cpu_idle+0x63/0x88
> [] rest_init+0x55/0x60
> [] start_kernel+0x2a4/0x32a
> [] _sinittext+0x10b/0x120
>
> tornado home #
>
> I have posted a full dmesg up as well as my .config and an lcpci at
> http://www.reub.net/files/kernel/2.6.24-rc4-mm1/ .
>

Ilpo, Reuben's kernel is talking to you

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Alexey Dobriyan wrote:
>> git-scsi-misc.patch
>
> Apologies for not looking into the problem earlier. See
> http://marc.info/?t=119628022300005&r=1&w=2
> "2.6.24-rc3-mm2: Result: hostbyte=0x01 driverbyte=0x00\nend_request: I/O error"
> for previous installment.
>
> I've bisected it to the following patch in git-scsi-misc branch.
> Revert on top of 2.6.24-rc4-mm1 also helps.
>
> commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0
> Author: Hannes Reinecke
> Date: Tue Nov 6 09:23:40 2007 +0100
>
> [SCSI] Do not requeue requests if REQ_FAILFAST is set
>
> Any requests with the REQ_FAILFAST flag set should not be requeued
> to the requeust queue, but rather terminated directly.
> Otherwise the multipath failover will stall until the command
> timeout triggers.
>
> Signed-off-by: Hannes Reinecke
> Signed-off-by: James Bottomley
>
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 0f44bdb..0da0dd0 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -1286,6 +1286,11 @@ int scsi_prep_state_check(struct scsi_device *sdev, struct request *req)
> */
> if (!(req->cmd_flags & REQ_PREEMPT))
> ret = BLKPREP_DEFER;
> + /*
> + * Return failfast requests immediately
> + */
> + if (req->cmd_flags & REQ_FAILFAST)
> + ret = BLKPREP_KILL;
> break;
> default:
> /*
> @@ -1414,6 +1419,17 @@ static inline int scsi_host_queue_ready(struct request_queue *q,
> return 1;
> }
>
> +static void __scsi_kill_request(struct request *req)
> +{
> + struct scsi_cmnd *cmd = req->special;
> + struct scsi_device *sdev = cmd->device;
> +
> + cmd->result = DID_NO_CONNECT << 16;
> + atomic_inc(&cmd->device->iorequest_cnt);
> + sdev->device_busy--;
> + __scsi_done(cmd);
> +}
> +
> /*
> * Kill a request for a dead device
> */
> @@ -1527,8 +1543,16 @@ static void scsi_request_fn(struct request_queue *q)
> * accept it.
> */
> req = elv_next_request(q);
> - if (!req || !scsi_dev_queue_ready(q, sdev))
> + if (!req)
> + break;
> +
> + if (!scsi_dev_queue_ready(q, sdev)) {
> + if (req->cmd_flags & REQ_FAILFAST) {
> + scsi_kill_request(req, q);
> + continue;
> + }
> break;
> + }
>
> if (unlikely(!scsi_device_online(sdev))) {
> sdev_printk(KERN_ERR, sdev,
> @@ -1609,8 +1633,12 @@ static void scsi_request_fn(struct request_queue *q)
> * later time.
> */
> spin_lock_irq(q->queue_lock);
> - blk_requeue_request(q, req);
> - sdev->device_busy--;
> + if (unlikely(req->cmd_flags & REQ_FAILFAST))
> + __scsi_kill_request(req);
> + else {
> + blk_requeue_request(q, req);
> + sdev->device_busy--;
> + }
> if(sdev->device_busy == 0)
> blk_plug_device(q);
> out:
Yeah, sorry. That patch was bad. Please use the attached one instead.
Andrew, can you replace them?

Cheers,

Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 13e7e09..9ec1566 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1284,13 +1284,15 @@ int scsi_prep_state_check(struct scsi_device *sdev, struct request *req)
/*
* If the devices is blocked we defer normal commands.
*/
- if (!(req->cmd_flags & REQ_PREEMPT))
- ret = BLKPREP_DEFER;
- /*
- * Return failfast requests immediately
- */
- if (req->cmd_flags & REQ_FAILFAST)
- ret = BLKPREP_KILL;
+ if (!(req->cmd_flags & REQ_PREEMPT)) {
+ /*
+ * Return failfast requests immediately
+ */
+ if (req->cmd_flags & REQ_FAILFAST)
+ ret = BLKPREP_KILL;
+ else
+ ret = BLKPREP_DEFER;
+ }
break;
default:
/*

On Tue, 04 Dec 2007 21:17:01 PST, Andrew Morton said:
> ftp://ftp.kernel.org/pub/linux/kerne....6.24-rc4-mm1/

Something in here broke LVM support - an initrd that has worked fine for
quite some time suddenly couldn't mount /dev/VolGroup00/root so we get the
infamous "Kernel panic - not syncing: Attempted to kill init!" when we
fall off the end of the initrd and haven't pivoted to the real disk.

It finds the disk OK:

[ 81.202310] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 81.214466] sd 0:0:0:0: [sda] Write Protect is off
[ 81.226467] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 81.238436] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 81.250780] sda: sda1 sda2
[ 75.396119] sd 0:0:0:0: [sda] Attached SCSI disk

but then the lvm command says it can't find the volume group VolGroup00 (which
is actually sda2 - sda1 is a small /boot partition, rest of disk is LVM).

A quick look at the rc4-mm1 announcement doesn't have any obviously tempting
patch names to start at, so it looks like it's time to play mm-bisect. It may
take me a day or two, as I have some time management issues this week...



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFHV+HEcC3lWbTT17ARAlofAJ4gzgbt+6ChWgiDyo/HBqIpGt+EwwCfU8lX
aUTYCzJmgOLCxw0LZ6BmqtU=
=qNrK
-----END PGP SIGNATURE-----

On Thu, 06 Dec 2007 06:49:24 -0500 Valdis.Kletnieks@vt.edu wrote:

> On Tue, 04 Dec 2007 21:17:01 PST, Andrew Morton said:
> > ftp://ftp.kernel.org/pub/linux/kerne....6.24-rc4-mm1/
>
> Something in here broke LVM support - an initrd that has worked fine for
> quite some time suddenly couldn't mount /dev/VolGroup00/root so we get the
> infamous "Kernel panic - not syncing: Attempted to kill init!" when we
> fall off the end of the initrd and haven't pivoted to the real disk.
>
> It finds the disk OK:
>
> [ 81.202310] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
> [ 81.214466] sd 0:0:0:0: [sda] Write Protect is off
> [ 81.226467] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
> [ 81.238436] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> [ 81.250780] sda: sda1 sda2
> [ 75.396119] sd 0:0:0:0: [sda] Attached SCSI disk
>
> but then the lvm command says it can't find the volume group VolGroup00 (which
> is actually sda2 - sda1 is a small /boot partition, rest of disk is LVM).
>
> A quick look at the rc4-mm1 announcement doesn't have any obviously tempting
> patch names to start at, so it looks like it's time to play mm-bisect. It may
> take me a day or two, as I have some time management issues this week...
>

OK, thanks.

First step would be to eliminate rewrite-rd.patch: maybe the ramdisk driver
in which that initrd resides is bust.

After that, agk-dm-dm-*.patch are of course the ones to look at.

Please keep dm-devel@redhat.com cc'ed.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Thu, Dec 06 2007, Hannes Reinecke wrote:
> Alexey Dobriyan wrote:
> >> git-scsi-misc.patch
> >
> > Apologies for not looking into the problem earlier. See
> > http://marc.info/?t=119628022300005&r=1&w=2
> > "2.6.24-rc3-mm2: Result: hostbyte=0x01 driverbyte=0x00\nend_request: I/O error"
> > for previous installment.
> >
> > I've bisected it to the following patch in git-scsi-misc branch.
> > Revert on top of 2.6.24-rc4-mm1 also helps.
> >
> > commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0
> > Author: Hannes Reinecke
> > Date: Tue Nov 6 09:23:40 2007 +0100
> >
> > [SCSI] Do not requeue requests if REQ_FAILFAST is set
> >
> > Any requests with the REQ_FAILFAST flag set should not be requeued
> > to the requeust queue, but rather terminated directly.
> > Otherwise the multipath failover will stall until the command
> > timeout triggers.
> >
> > Signed-off-by: Hannes Reinecke
> > Signed-off-by: James Bottomley
> >
> > diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> > index 0f44bdb..0da0dd0 100644
> > --- a/drivers/scsi/scsi_lib.c
> > +++ b/drivers/scsi/scsi_lib.c
> > @@ -1286,6 +1286,11 @@ int scsi_prep_state_check(struct scsi_device *sdev, struct request *req)
> > */
> > if (!(req->cmd_flags & REQ_PREEMPT))
> > ret = BLKPREP_DEFER;
> > + /*
> > + * Return failfast requests immediately
> > + */
> > + if (req->cmd_flags & REQ_FAILFAST)
> > + ret = BLKPREP_KILL;
> > break;
> > default:
> > /*
> > @@ -1414,6 +1419,17 @@ static inline int scsi_host_queue_ready(struct request_queue *q,
> > return 1;
> > }
> >
> > +static void __scsi_kill_request(struct request *req)
> > +{
> > + struct scsi_cmnd *cmd = req->special;
> > + struct scsi_device *sdev = cmd->device;
> > +
> > + cmd->result = DID_NO_CONNECT << 16;
> > + atomic_inc(&cmd->device->iorequest_cnt);
> > + sdev->device_busy--;
> > + __scsi_done(cmd);
> > +}
> > +
> > /*
> > * Kill a request for a dead device
> > */
> > @@ -1527,8 +1543,16 @@ static void scsi_request_fn(struct request_queue *q)
> > * accept it.
> > */
> > req = elv_next_request(q);
> > - if (!req || !scsi_dev_queue_ready(q, sdev))
> > + if (!req)
> > + break;
> > +
> > + if (!scsi_dev_queue_ready(q, sdev)) {
> > + if (req->cmd_flags & REQ_FAILFAST) {
> > + scsi_kill_request(req, q);
> > + continue;
> > + }
> > break;
> > + }
> >
> > if (unlikely(!scsi_device_online(sdev))) {
> > sdev_printk(KERN_ERR, sdev,
> > @@ -1609,8 +1633,12 @@ static void scsi_request_fn(struct request_queue *q)
> > * later time.
> > */
> > spin_lock_irq(q->queue_lock);
> > - blk_requeue_request(q, req);
> > - sdev->device_busy--;
> > + if (unlikely(req->cmd_flags & REQ_FAILFAST))
> > + __scsi_kill_request(req);
> > + else {
> > + blk_requeue_request(q, req);
> > + sdev->device_busy--;
> > + }
> > if(sdev->device_busy == 0)
> > blk_plug_device(q);
> > out:
> Yeah, sorry. That patch was bad. Please use the attached one instead.
> Andrew, can you replace them?
>
> Cheers,
>
> Hannes
> --
> Dr. Hannes Reinecke zSeries & Storage
> hare@suse.de +49 911 74053 688
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
> GF: Markus Rex, HRB 16746 (AG Nürnberg)

> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 13e7e09..9ec1566 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -1284,13 +1284,15 @@ int scsi_prep_state_check(struct scsi_device *sdev, struct request *req)
> /*
> * If the devices is blocked we defer normal commands.
> */
> - if (!(req->cmd_flags & REQ_PREEMPT))
> - ret = BLKPREP_DEFER;
> - /*
> - * Return failfast requests immediately
> - */
> - if (req->cmd_flags & REQ_FAILFAST)
> - ret = BLKPREP_KILL;
> + if (!(req->cmd_flags & REQ_PREEMPT)) {
> + /*
> + * Return failfast requests immediately
> + */
> + if (req->cmd_flags & REQ_FAILFAST)
> + ret = BLKPREP_KILL;
> + else
> + ret = BLKPREP_DEFER;
> + }
> break;
> default:
> /*

can we please stick to using blk_noretry_request() consistently, instead
of thwrowing REQ_FAILFAST tests in there?


--
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Kamalesh Babulal wrote:
> Hi Andrew,
>
> The 2.6.24-rc4-mm1 kernel build fails with build failure,
>
> CC drivers/char/hvcs.o
> drivers/char/hvcs.c: In function ‘hvcs_open’:
> drivers/char/hvcs.c:1180: error: wrong type argument to unary exclamation mark
> make[2]: *** [drivers/char/hvcs.o] Error 1
> make[1]: *** [drivers/char] Error 2
> make: *** [drivers] Error 2
>
> The kref_get begin void return type, check for the kobject return type
> as in the previous kobject_get()
>
> if (!kref_get(&hvcsd->kref)) {
> spin_unlock_irqrestore(&hvcsd->lock, flags);
> printk(KERN_ERR "HVCS: Kobject of open"
> " hvcs doesn't exist.\n");
> return -EFAULT; /* Is this the right return value? */
> }
>
> I have tested for the build failure only.
>
> Signed-off-by: Kamalesh Babulal
> --
> --- linux-2.6.24-rc4/drivers/char/hvcs.c 2007-12-05 12:17:37.000000000 +0530
> +++ linux-2.6.24-rc4/drivers/char/~hvcs.c 2007-12-05 19:17:12.000000000 +0530
> @@ -1177,12 +1177,8 @@ fast_open:
> hvcsd = tty->driver_data;
>
> spin_lock_irqsave(&hvcsd->lock, flags);
> - if (!kref_get(&hvcsd->kref)) {
> - spin_unlock_irqrestore(&hvcsd->lock, flags);
> - printk(KERN_ERR "HVCS: Kobject of open"
> - " hvcs doesn't exist.\n");
> - return -EFAULT; /* Is this the right return value? */
> - }
> + kref_get(&hvcsd->kref);
> + spin_unlock_irqrestore(&hvcsd->lock, flags);
>

Why release the spinlock here? It's done after the count is incremented.
This patch does not seem correct.

> hvcsd->open_count++;
>


--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Greg KH wrote:
> On Thu, Dec 06, 2007 at 11:49:59PM +0530, Balbir Singh wrote:
>> Kamalesh Babulal wrote:
>>> Hi Andrew,
>>>
>>> The 2.6.24-rc4-mm1 kernel build fails with build failure,
>>>
>>> CC drivers/char/hvcs.o
>>> drivers/char/hvcs.c: In function ‘hvcs_open’:
>>> drivers/char/hvcs.c:1180: error: wrong type argument to unary exclamation mark
>>> make[2]: *** [drivers/char/hvcs.o] Error 1
>>> make[1]: *** [drivers/char] Error 2
>>> make: *** [drivers] Error 2
>>>
>>> The kref_get begin void return type, check for the kobject return type
>>> as in the previous kobject_get()
>>>
>>> if (!kref_get(&hvcsd->kref)) {
>>> spin_unlock_irqrestore(&hvcsd->lock, flags);
>>> printk(KERN_ERR "HVCS: Kobject of open"
>>> " hvcs doesn't exist.\n");
>>> return -EFAULT; /* Is this the right return value? */
>>> }
>>>
>>> I have tested for the build failure only.
>>>
>>> Signed-off-by: Kamalesh Babulal
>>> --
>>> --- linux-2.6.24-rc4/drivers/char/hvcs.c 2007-12-05 12:17:37.000000000 +0530
>>> +++ linux-2.6.24-rc4/drivers/char/~hvcs.c 2007-12-05 19:17:12.000000000 +0530
>>> @@ -1177,12 +1177,8 @@ fast_open:
>>> hvcsd = tty->driver_data;
>>>
>>> spin_lock_irqsave(&hvcsd->lock, flags);
>>> - if (!kref_get(&hvcsd->kref)) {
>>> - spin_unlock_irqrestore(&hvcsd->lock, flags);
>>> - printk(KERN_ERR "HVCS: Kobject of open"
>>> - " hvcs doesn't exist.\n");
>>> - return -EFAULT; /* Is this the right return value? */
>>> - }
>>> + kref_get(&hvcsd->kref);
>>> + spin_unlock_irqrestore(&hvcsd->lock, flags);
>>>
>> Why release the spinlock here? It's done after the count is incremented.
>> This patch does not seem correct.
>
> Doh, you are correct, I'll make sure that I fix this up before applying
> it.
>
> thanks,
>
> greg k-h

Sorry, my fault for overlooking that, thanks greg.

--
Thanks & Regards,
Kamalesh Babulal,

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Greg KH wrote:

>> Why release the spinlock here? It's done after the count is incremented.
>> This patch does not seem correct.
>
> Doh, you are correct, I'll make sure that I fix this up before applying
> it.
>
> thanks,
>
> greg k-h

Hi, Greg,

I ran some tests with the fixed up version of this patch and the system
fails to come up.

I see the WARN_ON in lib/kref.c:33 and the system fails to boot beyond
that point. I have not yet found time to debug it though.

--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Thu, 06 Dec 2007 04:04:20 PST, Andrew Morton said:

> > > ftp://ftp.kernel.org/pub/linux/kerne....6.24-rc4-mm1/
> >
> > Something in here broke LVM support - an initrd that has worked fine for
> > quite some time suddenly couldn't mount /dev/VolGroup00/root so we get the
> > infamous "Kernel panic - not syncing: Attempted to kill init!" when we
> > fall off the end of the initrd and haven't pivoted to the real disk.
> >
> > It finds the disk OK:
> >
> > [ 81.202310] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
> > [ 81.214466] sd 0:0:0:0: [sda] Write Protect is off
> > [ 81.226467] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
> > [ 81.238436] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> > [ 81.250780] sda: sda1 sda2
> > [ 75.396119] sd 0:0:0:0: [sda] Attached SCSI disk
> >
> > but then the lvm command says it can't find the volume group VolGroup00 (which
> > is actually sda2 - sda1 is a small /boot partition, rest of disk is LVM).
> >
> > A quick look at the rc4-mm1 announcement doesn't have any obviously tempting
> > patch names to start at, so it looks like it's time to play mm-bisect. It may
> > take me a day or two, as I have some time management issues this week...
> >
>
> OK, thanks.
>
> First step would be to eliminate rewrite-rd.patch: maybe the ramdisk driver
> in which that initrd resides is bust.
>
> After that, agk-dm-dm-*.patch are of course the ones to look at.

How did I not notice them? Yeah, those guys would be on the suspicious list...

> Please keep dm-devel@redhat.com cc'ed.

I've gotten it down to about 128 patches, but it's interesting what ended
up bracketed by GOOD/BAD:

powerpc-invalid-size-for-swapper_pg_dir-with-config_pte_64bit=y.patch GOOD
#GREGKH-DRIVER-START
gregkh-driver-nozomi.patch
gregkh-moby-patch-tree....
unbork-gregkh-driver-kset-convert-sys-devices-to-use-kset_create-vioc.patch BAD

Would I be remiss in hypothesising that something in gregkh-driver-kobject-*
changed something, and now we need a agk-dm-dm-kobject-fixupage.patch?

The actual bug is probably elsewhere, but it *manifests* due to gregkh-driver
tree. Will probably be tomorrow before I get it down further...


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFHWErwcC3lWbTT17ARAsngAJwLlTr9tXk1Zkr+aQHNE8 LugdDNcQCg9P3D
t0sh0PbMYAA20nTc/mO2/0g=
=FDNe
-----END PGP SIGNATURE-----