by Adrian Bunk

2007-01-07 00:29:35

Hello,

> On Fri, 5 Jan 2007, Mariusz Kozlowski wrote:
>
> > Doesn't build on my iMac G3 based garage jukebox ;-)
> >
> > arch/powerpc/kernel/of_platform.c:479: error: unknown field 'multithread_probe' specified in initializer
> > arch/powerpc/kernel/of_platform.c:479: warning: initialization makes pointer from integer without a cast
> > make[1]: *** [arch/powerpc/kernel/of_platform.o] Blad 1
> > make: *** [arch/powerpc/kernel] Blad 2
>
> Can you please post your .config?

Sure. Please find it attached.

processor : 0
cpu : 740/750
temperature : 28-31 C (uncalibrated)
clock : 400MHz
revision : 2.2 (pvr 0008 0202)
bogomips : 796.67
machine : PowerMac2,1
motherboard : PowerMac2,1 MacRISC2 MacRISC Power Macintosh
detected as : 66 (iMac FireWire)
pmac flags : 00000005
L2 cache : 512K unified
memory : 256MB
pmac-generation : NewWorld

Gnu C 4.1.2
Gnu make 3.81
binutils 2.17
util-linux 2.12r
mount 2.12r
module-init-tools 3.3-pre2
e2fsprogs 1.40-WIP
Linux C Library 2.3.6
Dynamic linker (ldd) 2.3.6
Procps 3.2.7
Net-tools 1.60
Console-tools 0.2.3
Sh-utils 5.97
Modules Loaded ipv6 af_packet tsdev eth1394 tulip crc32 ohci1394 ieee1394 uninorth_agp agpgart dm_snapshot dm_mirror dm_mod snd_powermac snd_pcm_oss snd_pcm snd_page_alloc snd_mixer_oss snd_seq_oss snd_seq_device snd_seq_midi_event snd_seq snd_timer snd soundcore ide_cd cdrom joydev evdev ext3 jbd mbcache usbhid uhci_hcd ohci_hcd usbcore ide_disk unix

--
Regards,

Mariusz Kozlowski

Attachments:

(No filename) (1.67 kB)
config (69.15 kB)
Download all attachments

2007-01-08 19:32:48

by Cornelia Huck

[permalink] [raw]

Subject: Re: 2.6.20-rc3-mm1

On Sat, 06 Jan 2007 08:24:44 +1100,
Benjamin Herrenschmidt <[email protected]> wrote:

> > http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc3/2.6.20-rc3-mm1/broken-out/driver-core-per-subsystem-multithreaded-probing.patch
>
> Hrm. I disagree with this change. I have a few cases where drivers
> actually want to explicitely do that. I suppose they can always fire off
> a thread themselves from probe() but I don't see the reason to move it
> to the bus type...

The idea behind this is to have a probing thread for each device that
does the actual work (call probe for the matching drivers) so that
multiple devices can be probed in parallel. The decision to do this can
only be made at the bus level.

Previously, the code made it possible to have a probing thread for each
matching driver for the same device in parallel. I didn't see any
benefit in that, but maybe I'm just dense...

--
Cornelia Huck
Linux for zSeries Developer
Tel.: +49-7031-16-4837, Mail: [email protected]

2007-01-08 21:19:45

by Benjamin Herrenschmidt

[permalink] [raw]

Subject: Re: 2.6.20-rc3-mm1

> The idea behind this is to have a probing thread for each device that
> does the actual work (call probe for the matching drivers) so that
> multiple devices can be probed in parallel. The decision to do this can
> only be made at the bus level.
>
> Previously, the code made it possible to have a probing thread for each
> matching driver for the same device in parallel. I didn't see any
> benefit in that, but maybe I'm just dense...

Hrm... I see. Well, I was using it from the driver because I have a
driver that needs to wait in it's probe() routing for another driver to
show up for another device (they are linked in some ways, but that is
not expressed via bus bindings).

I suppose I'll just have probe() fire off a kthread instead.

Cheers,
Ben.

2007-01-09 14:40:53

On Mon, 08 Jan 2007 09:55:24 +0100, Jens Axboe said:
> On Sat, Jan 06 2007, [email protected] wrote:
> > On Thu, 04 Jan 2007 22:02:00 PST, Andrew Morton said:
> >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc
3/2.6.20-rc3-mm1/
> >
> > With git-block.patch applied, my system locks up *hard* at system
> > shutdown time - even alt-sysrq doesn't do anything. Need to do the
> > "power button for 5" stunt to get the system back.
>
> Does this change anything?
>
> diff --git a/block/ll_rw_blk.c b/block/ll_rw_blk.c
> index ec40e44..bae57e0 100644
> --- a/block/ll_rw_blk.c
> +++ b/block/ll_rw_blk.c
> @@ -1542,7 +1542,7 @@ static inline void queue_sync_plugs(request_queue_t *q)
> * If the current process is plugged and has barriers submitted,
> * we will livelock if we don't unplug first.
> */
> - blk_unplug_current();
> + blk_replug_current_nested();
>
> synchronize_qrcu(&q->qrcu);
> }

Nope, still hangs exactly the same way. Maybe I need to get the watchdog
timer stuff working, and see if that can kick the system in a way that
produces a backtrace....

Attachments:

(No filename) (226.00 B)

2007-01-09 20:50:25

Frederik Deweerdt napisał(a):
> On Tue, Jan 09, 2007 at 09:50:20PM +0100, Maciej Rutecki wrote:
>> Frederik Deweerdt napisał(a):
>>
>>> See:
>>> http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc3/2.6.20-rc3-mm1/hot-fixes/
>>> This should fix it.
>>> Regards,
>>> Frederik
>> I don't use reiser4 or cpufreq, see my .config.
> The generic_sync_sb_inodes() function which gets fixed by the
> reiser4-sb_sync_inodes-fix patch isn't only used by reiser4. The
> spinlock unbalance is most likely responsible for the preempt_count
> mismatch.
>
> Regards,
> Frederik

After add reiser4-sb_sync_inodes-fix.patch all works fine. Thanks for help.

--
Maciej Rutecki <[email protected]>
http://www.unixy.pl
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

Attachments:

smime.p7s (3.19 kB)
S/MIME Cryptographic Signature

2007-01-11 18:31:01

by Frederik Deweerdt

[permalink] [raw]

Subject: [-mm patch] remove tcp header from tcp_v4_check

On Thu, Jan 04, 2007 at 10:02:00PM -0800, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc3/2.6.20-rc3-mm1/
>
The tcphdr struct passed to tcp_v4_check is not used, the following patch
removes it from the parameter list.

Regards,
Frederik

Signed-off-by: Frederik Deweerdt <[email protected]>

Index: 2.6.20-rc3-mm1/include/net/tcp.h
===================================================================
--- 2.6.20-rc3-mm1.orig/include/net/tcp.h
+++ 2.6.20-rc3-mm1/include/net/tcp.h
@@ -802,9 +802,8 @@ static inline void tcp_update_wl(struct
/*
* Calculate(/check) TCP checksum
*/
-static inline __sum16 tcp_v4_check(struct tcphdr *th, int len,
- __be32 saddr, __be32 daddr,
- __wsum base)
+static inline __sum16 tcp_v4_check(int len, __be32 saddr,
+ __be32 daddr, __wsum base)
{
return csum_tcpudp_magic(saddr,daddr,len,IPPROTO_TCP,base);
}
Index: 2.6.20-rc3-mm1/net/ipv4/netfilter/ipt_REJECT.c
===================================================================
--- 2.6.20-rc3-mm1.orig/net/ipv4/netfilter/ipt_REJECT.c
+++ 2.6.20-rc3-mm1/net/ipv4/netfilter/ipt_REJECT.c
@@ -116,7 +116,7 @@ static void send_reset(struct sk_buff *o

/* Adjust TCP checksum */
tcph->check = 0;
- tcph->check = tcp_v4_check(tcph, sizeof(struct tcphdr),
+ tcph->check = tcp_v4_check(sizeof(struct tcphdr),
nskb->nh.iph->saddr,
nskb->nh.iph->daddr,
csum_partial((char *)tcph,
Index: 2.6.20-rc3-mm1/net/ipv4/tcp_ipv4.c
===================================================================
--- 2.6.20-rc3-mm1.orig/net/ipv4/tcp_ipv4.c
+++ 2.6.20-rc3-mm1/net/ipv4/tcp_ipv4.c
@@ -502,14 +502,13 @@ void tcp_v4_send_check(struct sock *sk,
struct tcphdr *th = skb->h.th;

if (skb->ip_summed == CHECKSUM_PARTIAL) {
- th->check = ~tcp_v4_check(th, len,
- inet->saddr, inet->daddr, 0);
+ th->check = ~tcp_v4_check(len, inet->saddr,
+ inet->daddr, 0);
skb->csum_offset = offsetof(struct tcphdr, check);
} else {
- th->check = tcp_v4_check(th, len, inet->saddr, inet->daddr,
+ th->check = tcp_v4_check(len, inet->saddr, inet->daddr,
csum_partial((char *)th,
- th->doff << 2,
- skb->csum));
+ th->doff << 2, skb->csum));
}
}

@@ -525,7 +524,7 @@ int tcp_v4_gso_send_check(struct sk_buff
th = skb->h.th;

th->check = 0;
- th->check = ~tcp_v4_check(th, skb->len, iph->saddr, iph->daddr, 0);
+ th->check = ~tcp_v4_check(skb->len, iph->saddr, iph->daddr, 0);
skb->csum_offset = offsetof(struct tcphdr, check);
skb->ip_summed = CHECKSUM_PARTIAL;
return 0;
@@ -747,7 +746,7 @@ static int tcp_v4_send_synack(struct soc
if (skb) {
struct tcphdr *th = skb->h.th;

- th->check = tcp_v4_check(th, skb->len,
+ th->check = tcp_v4_check(skb->len,
ireq->loc_addr,
ireq->rmt_addr,
csum_partial((char *)th, skb->len,
@@ -1514,7 +1513,7 @@ static struct sock *tcp_v4_hnd_req(struc
static __sum16 tcp_v4_checksum_init(struct sk_buff *skb)
{
if (skb->ip_summed == CHECKSUM_COMPLETE) {
- if (!tcp_v4_check(skb->h.th, skb->len, skb->nh.iph->saddr,
+ if (!tcp_v4_check(skb->len, skb->nh.iph->saddr,
skb->nh.iph->daddr, skb->csum)) {
skb->ip_summed = CHECKSUM_UNNECESSARY;
return 0;

2007-01-12 22:56:52

by Laurent Riffard

[permalink] [raw]

Subject: Re: 2.6.20-rc3-mm1: umount reiser4 FS stuck in D state

Le 06.01.2007 19:58, Vladimir V. Saveliev a ?crit :
> Hello
>
> On Saturday 06 January 2007 13:58, Laurent Riffard wrote:
>> Hello,
>>
>> got this with 2.6.20-rc3-mm1:
>>
>> =======================
>> SysRq : Show Blocked State
>>
>> free sibling
>> task PC stack pid father child younger older
>> umount D C013135E 6044 1168 1150 (NOTLB)
>> de591ae4 00000086 de591abc c013135e dff979c8 c012a6fe 00000046 00000007
>> dfd94ac0 128d3000 00000026 00000000 dfd94bcc dff979c8 de591ae4 dffda038
>> 00000002 dff979c0 dff979bc dff979c8 de591b10 c012d600 dff979f8 00000000
>> Call Trace:
>> [<c012d600>] synchronize_qrcu+0x70/0x8c
>> [<c01bede4>] __make_request+0x4c/0x29b
>> [<c01bd24b>] generic_make_request+0x1b0/0x1de
>> [<c01bf354>] submit_bio+0xda/0xe2
>> [<e12674bd>] write_jnodes_to_disk_extent+0x920/0x974 [reiser4]
>> [<e12678dd>] update_journal_footer+0x29f/0x2b7 [reiser4]
>> [<e1268b65>] write_tx_back+0x149/0x185 [reiser4]
>> [<e126a8e7>] reiser4_write_logs+0xea4/0xfd2 [reiser4]
>> [<e125626a>] try_commit_txnh+0x7e6/0xa4f [reiser4]
>> [<e125661b>] reiser4_txn_end+0x148/0x3cf [reiser4]
>> [<e12568ad>] reiser4_txn_restart+0xb/0x1a [reiser4]
>> [<e125692f>] reiser4_txn_restart_current+0x73/0x75 [reiser4]
>> [<e1256b89>] force_commit_atom+0x258/0x261 [reiser4]
>> [<e1257703>] txnmgr_force_commit_all+0x406/0x697 [reiser4]
>> [<e12e5e08>] release_format40+0x10c/0x193 [reiser4]
>> [<e1279922>] reiser4_put_super+0x134/0x16a [reiser4]
>> [<c015c930>] generic_shutdown_super+0x55/0xd8
>> [<c015c9d3>] kill_block_super+0x20/0x32
>> [<c015ca75>] deactivate_super+0x3f/0x51
>> [<c016d903>] mntput_no_expire+0x42/0x5f
>> [<c0160f37>] path_release_on_umount+0x15/0x18
>> [<c016df77>] sys_umount+0x1a3/0x1cb
>> [<c016dfb8>] sys_oldumount+0x19/0x1b
>> [<c0103ed2>] sysenter_past_esp+0x5f/0x99
>> =======================
>>
>> Scenario:
>> - umount a reiser4 FS (no need to write something before)
>
> Hmm, I can not reproduce this with 2.6.20-rc3-mm1. Probably I need to config the kernel more close to your system.
>
>> Earlier kernels were OK.

This still happens with 2.6.20-rc4-mm1...

Should I open a bug report at http://bugzilla.kernel.org?

--
laurent

2007-01-13 02:00:35

Le 01.02.2007 22:52, Edward Shishkin a ?crit :
> Laurent Riffard wrote:
>>
>> Le 01.02.2007 21:04, Edward Shishkin a ?crit :
>>>
>>> Laurent, would you please try 2.6.20-rc6-mm3 + this patch:
>>> http://lkml.org/lkml/diff/2007/2/1/195/1
>>
>>
>> Reiser4 works fine with 2.6.20-rc6-mm2 or 2.6.20-rc6-mm3 without any
>> additional patch (it was broken in rc6-mm1).
>>
>> FWIW, Andrew removed git-block.patch from 2.6.20-rc6-mm2, and he
>> restored git-block.patch without some problematic CFQ updates in
>> 2.6.20-rc6-mm3.
>>
>> In this case, does this patch need testing in rc6-mm3 ?
>
> Yes. This is against git-block patch to prevent endless waiting for IO
> completion.
> I have reproduced it by ./iozone -B -a -n 524288 -f /mnt/foo
> on x86 box with 512M RAM available.

OK, applied yesterday. I have been using it a few hours with a normal
workload and I didn't notice any problem.

Thanks
--
laurent