Re: Macvlan WARNiNGS about duplicate sysfs filenames (Was [GIT] Networking)
On Wed, Sep 10, 2014 at 3:55 AM, Andres Freund wrote:
> On 2014-09-10 01:48:06 +0200, Andres Freund wrote:
>> On 2014-09-09 15:43:55 -0700, Cong Wang wrote:
>> > On Mon, Sep 8, 2014 at 2:25 PM, Andres Freund wrote:
>> > > Hi,
>> > >
>> > > (don't have netdev archived, thus answering here, sorry)
>> > >
>> > > On 2014-09-07 16:41:09 -0700, David Miller wrote:
>> > >> Alexander Y. Fomichev (1):
>> > >> net: prevent of emerging cross-namespace symlinks
>> > >
>> >
>> > Since you are quoting this change, are you saying it causes
>> > the following kernel warning?
>>
>> I thought it might be a likely candidate; but I'm not sure at all. I'll
>> verify it as soon as I can reboot the machine a couple of times (end of
>> week-ish).
>>
>> > > I'm seeing WARNINGs like:
>> > > [ 1005.269134] [ cut here ]
>> > > [ 1005.269148] WARNING: CPU: 6 PID: 4213 at fs/sysfs/dir.c:31
>> > > sysfs_warn_dup+0x64/0x80()
>> > > [ 1005.269150] sysfs: cannot create duplicate filename
>> > > '/devices/pci:00/:00:1c.4/:03:00.0/net/eth0/upper_mv-eth0'
>> >
>> >
>> > Is there a network device named upper_mv-eth0 existed in your system
>> > before you created macvlan?
>>
>> No, there wasn't any. Afaics, the sequence is:
>> 1) macvlan mv-eth0 is created in global namespace
>> 2) mv-eth0 is moved (by systemd-nsspawn) into a new network
>>namespace. Leaving a dangling symlink in the host namespace
>> /devices/pci:00/:00:1c.4/:03:00.0/net/eth0/upper_mv-eth0
>> pointing toward
>> ../mv-eth0
>> which doesn't exist in the external namespace. The new namespace seems
>> to have broken 'lower_bond0' symlink as well
>>
>> This seems to be the case (and probably the actual root cause) in
>> slightly earlier kernels as well.
>> What changed seems to be that:
>> 3) macvlan mv-eth0 is destroyed in the namespace (potentially while
>>tearing it down)
>> 4) Now there's a broken symlink that doesn't make sense in any namespace
>> 5) mv-eth0 can't be created anew
>>
>> It seems that 3-5 didn't happen that way on older kernels. The most
>> recent where it's not persistently broken is 3.16.0-rc7-7 -
>> 31dab719f. The oldest where I know it's reproducible is
>> 3.17.0-rc4-andres-00135-g35af256.
>
> I've reproduced the problem on another machine where it's perfectly
> reproducible (except being about mv-bond0).
did you mean this is a macvlan which has bond as a real device?
hmm... current implementation of bonding unconditionally
refuses to switch ns due to NETIF_F_NETNS_LOCAL flag afaik,
macvlan steals flags from lowerdev so it should behave the same.
just to clarify: custom patches?
btw, could i ask you to try attached patch?
in short, my initial assumption we don't need check ns
in __netdev_adjacent_dev_insert was incorrect, I do really forgot (at
least) this :(
/* When creating macvlans or macvtaps on top of other macvlans - use
* the real device as the lowerdev.
so we can create broken links playing with macvlan in container.
diff --git a/net/core/dev.c b/net/core/dev.c
index ab9a165..12f496f 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4841,7 +4841,9 @@ static int __netdev_adjacent_dev_insert(struct
net_device *dev,
pr_debug("dev_hold for %s, because of link added from %s to %s\n",
adj_dev->name, dev->name, adj_dev->name);
- if (netdev_adjacent_is_neigh_list(dev, dev_list)) {
+ if (netdev_adjacent_is_neigh_list(dev, dev_list) &&
+ net_eq(dev_net(dev),dev_net(adj_dev))) {
+
ret = netdev_adjacent_sysfs_add(dev, adj_dev, dev_list);
if (ret)
goto free_adj;
@@ -4862,7 +4864,8 @@ static int __netdev_adjacent_dev_insert(struct
net_device *dev,
return 0;
remove_symlinks:
- if (netdev_adjacent_is_neigh_list(dev, dev_list))
+ if (netdev_adjacent_is_neigh_list(dev, dev_list) &&
+ net_eq(dev_net(dev),dev_net(adj_dev)))
netdev_adjacent_sysfs_del(dev, adj_dev->name, dev_list);
free_adj:
kfree(adj);
> After reverting only the
> aforementioned 4c75431ac352063 it works again.
> As I said above, I'm not sure whether 4c75431ac352063 is the actual
> culprit, but it certainly made the problem visible. How are these
> upper_$if/lower_$if supposed to behave when the macvlan and the
> underlying device are in differing namespaces?
>
> Greetings,
>
> Andres Freund
--
Best regards.
Alexander Y. Fomichev
netdev_adjacent_dev_insert.patch
Description: application/download
Re: Macvlan WARNiNGS about duplicate sysfs filenames (Was [GIT] Networking)
On Wed, Sep 10, 2014 at 3:55 AM, Andres Freund wrote: > On 2014-09-10 01:48:06 +0200, Andres Freund wrote: >> On 2014-09-09 15:43:55 -0700, Cong Wang wrote: >> > On Mon, Sep 8, 2014 at 2:25 PM, Andres Freund wrote: >> > > Hi, >> > > >> > > (don't have netdev archived, thus answering here, sorry) >> > > >> > > On 2014-09-07 16:41:09 -0700, David Miller wrote: >> > >> Alexander Y. Fomichev (1): >> > >> net: prevent of emerging cross-namespace symlinks >> > > >> > >> > Since you are quoting this change, are you saying it causes >> > the following kernel warning? >> >> I thought it might be a likely candidate; but I'm not sure at all. I'll >> verify it as soon as I can reboot the machine a couple of times (end of >> week-ish). >> >> > > I'm seeing WARNINGs like: >> > > [ 1005.269134] [ cut here ] >> > > [ 1005.269148] WARNING: CPU: 6 PID: 4213 at fs/sysfs/dir.c:31 >> > > sysfs_warn_dup+0x64/0x80() >> > > [ 1005.269150] sysfs: cannot create duplicate filename >> > > '/devices/pci:00/:00:1c.4/:03:00.0/net/eth0/upper_mv-eth0' >> > >> > >> > Is there a network device named upper_mv-eth0 existed in your system >> > before you created macvlan? >> >> No, there wasn't any. Afaics, the sequence is: >> 1) macvlan mv-eth0 is created in global namespace >> 2) mv-eth0 is moved (by systemd-nsspawn) into a new network >>namespace. Leaving a dangling symlink in the host namespace >> /devices/pci:00/:00:1c.4/:03:00.0/net/eth0/upper_mv-eth0 >> pointing toward >> ../mv-eth0 >> which doesn't exist in the external namespace. The new namespace seems >> to have broken 'lower_bond0' symlink as well >> >> This seems to be the case (and probably the actual root cause) in >> slightly earlier kernels as well. >> What changed seems to be that: >> 3) macvlan mv-eth0 is destroyed in the namespace (potentially while >>tearing it down) >> 4) Now there's a broken symlink that doesn't make sense in any namespace >> 5) mv-eth0 can't be created anew >> >> It seems that 3-5 didn't happen that way on older kernels. The most >> recent where it's not persistently broken is 3.16.0-rc7-7 - >> 31dab719f. The oldest where I know it's reproducible is >> 3.17.0-rc4-andres-00135-g35af256. > > I've reproduced the problem on another machine where it's perfectly > reproducible (except being about mv-bond0). After reverting only the > aforementioned 4c75431ac352063 it works again. > As I said above, I'm not sure whether 4c75431ac352063 is the actual > culprit, but it certainly made the problem visible. How are these > upper_$if/lower_$if supposed to behave when the macvlan and the > underlying device are in differing namespaces? supposed to be destroyed before moving device into new net_ns and created just after but only if both lower/upper devices has the same netns. whether i understood you correctly that you see lowar_/upper_ links just after new container is up? > Greetings, > > Andres Freund -- Best regards. Alexander Y. Fomichev -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net bridge: add null pointer check, fix panic
On Thu, Jun 20, 2013 at 11:29 AM, Eric Dumazet wrote:
> On Thu, 2013-06-20 at 15:00 +0800, xiaoming gao wrote:
>
>> HI Eric
>> the problem is as follow:
>> br_del_if()-->del_nbp():
>>
>> list_del_rcu(&p->list);
>> dev->priv_flags &= ~IFF_BRIDGE_PORT;
>>
>> -->at this point, the nic be deleting still have rx_handler , so , may
>> in br_handle_frame()
>> -->br_port_exists() will return false,so br_get_port_rcu() will return
>> NULL
>> -->so in br_handle_frame , there will be a null panic.
>>
>> netdev_rx_handler_unregister(dev);
>> synchronize_net();
>
> This code is no longer like that in current tree.
> Check commit 4a0b5ec12f0ffc3024616e6dc62cf8a04c54edcd
> ("bridge: remove a redundant synchronize_net()")
>
>>
>>
>> i have checked commit 00cfec37484761a44, i think it didn't fix this bug..
>
> I claim adding NULL tests is not needed in the fast path, it was clearly
> stated in the changelog.
>
> I would change the dismantle path to make sure br_get_port_rcu() does
> not return NULL in the fast path, and remove the test on FF_BRIDGE_PORT
> Try something like that :
>
> diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
> index 1b8b8b8..2edfb80 100644
> --- a/net/bridge/br_input.c
> +++ b/net/bridge/br_input.c
> @@ -60,7 +60,7 @@ static int br_pass_frame_up(struct sk_buff *skb)
> int br_handle_frame_finish(struct sk_buff *skb)
> {
> const unsigned char *dest = eth_hdr(skb)->h_dest;
> - struct net_bridge_port *p = br_port_get_rcu(skb->dev);
> + struct net_bridge_port *p = __br_port_get_rcu(skb->dev);
> struct net_bridge *br;
> struct net_bridge_fdb_entry *dst;
> struct net_bridge_mdb_entry *mdst;
> @@ -68,7 +68,7 @@ int br_handle_frame_finish(struct sk_buff *skb)
> bool unicast = true;
> u16 vid = 0;
>
> - if (!p || p->state == BR_STATE_DISABLED)
> + if (p->state == BR_STATE_DISABLED)
> goto drop;
>
> if (!br_allowed_ingress(p->br, nbp_get_vlan_info(p), skb, &vid))
> @@ -142,7 +142,7 @@ drop:
> /* note: already called with rcu_read_lock */
> static int br_handle_local_finish(struct sk_buff *skb)
> {
> - struct net_bridge_port *p = br_port_get_rcu(skb->dev);
> + struct net_bridge_port *p = __br_port_get_rcu(skb->dev);
> u16 vid = 0;
>
> br_vlan_get_tag(skb, &vid);
> @@ -172,7 +172,7 @@ rx_handler_result_t br_handle_frame(struct sk_buff **pskb)
> if (!skb)
> return RX_HANDLER_CONSUMED;
>
> - p = br_port_get_rcu(skb->dev);
> + p = __br_port_get_rcu(skb->dev);
>
> if (unlikely(is_link_local_ether_addr(dest))) {
> /*
> diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
> index 3be89b3..9fdd467 100644
> --- a/net/bridge/br_private.h
> +++ b/net/bridge/br_private.h
> @@ -184,6 +184,11 @@ struct net_bridge_port
>
> #define br_port_exists(dev) (dev->priv_flags & IFF_BRIDGE_PORT)
>
> +static inline struct net_bridge_port *__br_port_get_rcu(const struct
> net_device *dev)
> +{
> + return rcu_dereference(dev->rx_handler_data);
> +}
> +
> static inline struct net_bridge_port *br_port_get_rcu(const struct
> net_device *dev)
> {
> struct net_bridge_port *port =
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
> I claim adding NULL tests is not needed in the fast path, it was clearly
> stated in the changelog.
Hello,
This commit makes trouble for current STP.
Two days ago i tried to switch to 3.10.18 and i've caught "bad magic"
on uninitialized br->lock:
./net/bridge/br_stp_bpdu.c +158 in br_stp_rcv (trace attached):
p = br_port_get_rcu(dev);
br = p->br;
spin_lock(&br->lock); <- here
---
Bisect pointed to this commit
(linux-stable: 960b8e5018a552f62cfbc0dfe94be7b6ba178f13)
(mainline 716ec052d2280d511e10e90ad54a86f5b5d4dcc2)
As far as i can see this happens when:
a) bridge module had been loaded but there was no bridge interface,
br->lock had not been initialized.
b) interface had been in promiscuous mod (tcpdump)
c) stp broadcasts 01:80:c2:00:00:00 coming to this iface
(llc_rcv drops PACKET_OTHERHOST to protect us in promiscuous mode
but seems like not a broadcasts)
d) and finally rx_handler_data had been initialised for this interface
( by macvlan in my case)
It seems like STP needs its own IFF_BRIDGE_PORT check.
probably an easiest option to check it in br_stp_rcv as before (or
probably in llc_rcv)...
--
Best regards.
Alexander Y. Fomichev
br_stp_rcv-spin_lock.trace
Description: Binary data
fix_stp_bridge_uninitialized.patch
Description: application/download
Re: kernel BUG at arch/x86_64/mm/../../i386/mm/hugetlbpage.c:140!
On Saturday 03 March 2007, Bill Irwin wrote: > On Fri, Mar 02, 2007 at 04:51:15PM +0300, Alexander Y. Fomichev wrote: > > I'm hit a bug on 2.6.21-rc1 at startup of mysql with 'large-pages' flag > > set. (at this point mysql trying to allocate pages from hugetlb pool by > > sysv shm syscalls). Seems like it could be triggered by previous badness > > and probably hugetlb itself is not related. Anyway i couldn't reproduce > > it by now with 2.6.21-rc2 git commit > > 562aa1d4c6a874373f9a48ac184f662fbbb06a04. Very likely it has been fixed > > somwhere between 2.6.21-rc1 and -rc2, but i couldn't find something > > related by git log so any comments are welcome. > > If you have a known-working kernel version, git-bisect might help you > track down where it was introduced. Given the messages prior to the > hugetlbpage.c BUG_ON I'd say that this is something else besides the > specific code listed by line number, Nop, seems like it is hugetlb bug fixed by Adam commit 516dffdcd8827a40532798602830dfcfc672294c [PATCH] Fix get_unmapped_area and fsync for hugetlb shm segments I've disregard it thoughtlessly so Adam marks it specific for powerpc/ia64. (hmm.. i donno realy why, huge pages should be alined anyway and if i understend it correctly it may not be if is_file_hugepages() fails) As of "junk" just before the BUG this again IIUC because o-direct staff catches this issue before hugetlb. > though I wouldn't rule out hugetlb > having tripped over itself before the actual BUG. > Yep, it is. > -- wli -- Best regards. Alexander Y. Fomichev <[EMAIL PROTECTED]> Public PGP key: http://sysadminday.org.ru/gluk.asc - 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/
Re: kernel BUG at arch/x86_64/mm/../../i386/mm/hugetlbpage.c:140!
On Saturday 03 March 2007, Nish Aravamudan wrote: > On 3/2/07, Alexander Y. Fomichev <[EMAIL PROTECTED]> wrote: > > G'day > > > > I'm hit a bug on 2.6.21-rc1 at startup of mysql with 'large-pages' flag > > set. (at this point mysql trying to allocate pages from hugetlb pool by > > sysv shm syscalls). Seems like it could be triggered by previous badness > > and probably hugetlb itself is not related. Anyway i couldn't reproduce > > it by now with 2.6.21-rc2 git commit > > 562aa1d4c6a874373f9a48ac184f662fbbb06a04. Very likely it has been fixed > > somwhere between 2.6.21-rc1 and -rc2, but i couldn't find something > > related by git log so any comments are welcome. > > Adam Litke posted a bug fix for hugetlb shm: > http://lkml.org/lkml/2007/3/1/381. > > Does that help fix your problem too? > > Thanks, > Nish Yep, it is, though Adam address this patch powerpc and ia64 issue but x86_64 (and probably i386) affected too. -- Best regards. Alexander Y. Fomichev <[EMAIL PROTECTED]> Public PGP key: http://sysadminday.org.ru/gluk.asc - 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/
kernel BUG at arch/x86_64/mm/../../i386/mm/hugetlbpage.c:140!
6 [422123.381237] [] autoremove_wake_function+0x0/0x38 [422123.381241] [] vfs_read+0xcc/0x155 [422123.381246] [] sys_pread64+0x55/0x76 [422123.381250] [] system_call+0x7e/0x83 [422123.381253] [422123.381338] [ cut here ] [422123.386310] kernel BUG at arch/x86_64/mm/../../i386/mm/hugetlbpage.c:140! [422123.393559] invalid opcode: [1] SMP [422123.397918] CPU 1 [422123.400168] Modules linked in: xt_state ipt_REJECT iptable_filter [422123.406736] Pid: 7904, comm: mysqld Tainted: GB 2.6.21-rc1 #2 [422123.413353] RIP: 0010:[] [] huge_pte_alloc+0x364/0x377 [422123.422281] RSP: :8100f5015cc8 EFLAGS: 00010202 [422123.427982] RAX: 8100f5527560 RBX: 8100ed9462b8 RCX: [422123.435604] RDX: f40bc067 RSI: 2b8295964004 RDI: 8100f4c99800 [422123.443243] RBP: 8100f5015d58 R08: 2b8294ee28c8 R09: 0001c000 [422123.450864] R10: 8100f5015e38 R11: 0202 R12: 2b8295964004 [422123.458494] R13: 0560 R14: 2b8295964004 R15: 810005f89088 [422123.466125] FS: 2b8284792ae0() GS:81010406eec0() knlGS: [422123.474774] CS: 0010 DS: ES: CR0: 8005003b [422123.480917] CR2: 2b8295964004 CR3: ed946000 CR4: 06e0 [422123.488565] Process mysqld (pid: 7904, threadinfo 8100f5014000, task 8100f5ba7180) [422123.497370] Stack: 0002 8100f4c99800 8100f2814050 8028b978 [422123.506022] 8100f5015d08 80302dda 4000 810004cb0a40 [422123.514007] 8100f5015d18 8025d857 8100f5015d48 802076cf [422123.521774] Call Trace: [422123.524692] [] up_read+0x9/0xb [422123.529745] [] xfs_iunlock+0x33/0x79 [422123.535341] [] _read_unlock_irq+0x9/0xc [422123.541206] [] find_get_page+0x50/0x5b [422123.546987] [] hugetlb_fault+0x28/0xc6 [422123.552756] [] __handle_mm_fault+0x60/0xc24 [422123.559003] [] do_page_fault+0x457/0x803 [422123.564971] [] _spin_unlock_irq+0x9/0xc [422123.570838] [] thread_return+0x5e/0xf5 [422123.576624] [] _spin_unlock+0x9/0xb [422123.582135] [] error_exit+0x0/0x84 [422123.587540] [422123.589218] [422123.589218] Code: 0f 0b eb fe 48 83 c4 68 5b 41 5c 41 5d 41 5e 41 5f c9 c3 55 [422123.599079] RIP [] huge_pte_alloc+0x364/0x377 [422123.605508] RSP full dmesg attached. -- Best regards. Alexander Y. Fomichev <[EMAIL PROTECTED]> Public PGP key: http://sysadminday.org.ru/gluk.asc [0.00] Linux version 2.6.21-rc1 ([EMAIL PROTECTED]) (gcc version 4.1.1 (Gentoo 4.1.1-r3)) #2 SMP Thu Feb 22 14:10:40 Local time zone must be set--see zic [0.00] Command line: root=/dev/sda2 console=ttyS0,115200 console=tty0 idle=pool profile=2 panic=30 [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009fc00 (usable) [0.00] BIOS-e820: 0009fc00 - 000a (reserved) [0.00] BIOS-e820: 000e - 0010 (reserved) [0.00] BIOS-e820: 0010 - f6ff (usable) [0.00] BIOS-e820: f6ff - f6fff000 (ACPI data) [0.00] BIOS-e820: f6fff000 - f700 (ACPI NVS) [0.00] BIOS-e820: ff7c - 0001 (reserved) [0.00] BIOS-e820: 0001 - 0002 (usable) [0.00] Entering add_active_range(0, 0, 159) 0 entries of 3200 used [0.00] Entering add_active_range(0, 256, 1011696) 1 entries of 3200 used [0.00] Entering add_active_range(0, 1048576, 2097152) 2 entries of 3200 used [0.00] end_pfn_map = 2097152 [0.00] DMI 2.3 present. [0.00] ACPI: RSDP 000F6A80, 0014 (r0 ACPIAM) [0.00] ACPI: RSDT F6FF, 0034 (r1 A M I OEMRSDT 4000430 MSFT 97) [0.00] ACPI: FACP F6FF0200, 0081 (r1 A M I OEMFACP 4000430 MSFT 97) [0.00] ACPI: DSDT F6FF0450, 2F29 (r1 1ABTX 1ABTX0000 INTL 2002026) [0.00] ACPI: FACS F6FFF000, 0040 [0.00] ACPI: APIC F6FF0380, 0074 (r1 A M I OEMAPIC 4000430 MSFT 97) [0.00] ACPI: OEMB F6FFF040, 0041 (r1 A M I OEMBIOS 4000430 MSFT 97) [0.00] ACPI: SRAT F6FF3380, 00F0 (r1 A M I OEMSRAT 4000430 MSFT 97) [0.00] SRAT: PXM 0 -> APIC 0 -> Node 0 [0.00] SRAT: PXM 1 -> APIC 1 -> Node 1 [0.00] SRAT: Node 0 PXM 0 10-f700 [0.00] Entering add_active_range(0, 256, 1011696) 0 entries of 3200 used [0.00] SRAT: Node 1 PXM 1 1-2 [0.00] Entering add_active_range(1, 1048576, 2097152) 1 entries of 3200 used [0.00] SRAT: Node 0 PXM 0 0-f700 [0.00] Entering add_active_range(0, 0, 159) 2 entries of 3200 used [0.00] Entering add_active_range(0, 256, 1011696) 3 entries of 3200 used [0.00] NUMA: Using 32 for the hash shift. [0.00] Bo
Re: 2.6.12 hangs on boot
On Friday 29 July 2005 09:09, Andrew Morton wrote: > "Alexander Y. Fomichev" <[EMAIL PROTECTED]> wrote: > > G' day > > > > I've been trying to switch from 2.6.12-rc3 to 2.6.12 on Dual EM64T 2.8 > > GHz [ MoBo: Intel E7520, intel 82801 ] > > but kernel hangs on boot right after records: > > > > Booting processor 2/1 rip 6000 rsp 8100023dbf58 > > Initializing CPU#2 > > > > ( below is a link to full boot trace, actually -git3 but no differences) > > http://sysadminday.org.ru/2.6.12-hang-on-boot/2.6.12-git3-hang > > > > An attempt to enable debug: > > +CONFIG_ACPI_DEBUG=y > > +CONFIG_DEBUG_SLAB=y > > +CONFIG_DEBUG_PREEMPT=y > > +CONFIG_DEBUG_SPINLOCK=y > > +CONFIG_DEBUG_SPINLOCK_SLEEP=y > > +CONFIG_DEBUG_KOBJECT=y > > +CONFIG_DEBUG_INFO=y > > +CONFIG_INIT_DEBUG=y > > gives rather strange result, kernel boots successfully ( with a lot of > > debuging messages of course but i couldn't find something suspicious ) > > http://sysadminday.org.ru/2.6.12-hang-on-boot/2.6.12-git3-debug > > > > config for 2.6.12 have been taken from previous one, only > > 'make oldconfig' has been made. > > http://sysadminday.org.ru/2.6.12-hang-on-boot/2.6.12-git3.config > > > > Hang 100% reproducible on at least two of my EM64T hosts. > > ( actualy the same configuration as of MoBo/CPU ) > > Is this still happening in 2.6.13-rc4? > > If so, could you please test 2.6.13-rc4 plus the below fix? > > Thanks. > > > From: [EMAIL PROTECTED] (Eric W. Biederman) > > sync_tsc was using smp_call_function to ask the boot processor to report > it's tsc value. smp_call_function performs an IPI_send_allbutself which is > a broadcast ipi. There is a window during processor startup during which > the target cpu has started and before it has initialized it's interrupt > vectors so it can properly process an interrupt. Receveing an interrupt > during that window will triple fault the cpu and do other nasty things. > > Why cli does not protect us from that is beyond me. > > The simple fix is to match ia64 and provide a smp_call_function_single. > Which avoids the broadcast and is more efficient. > > This certainly fixes the problem of getting stuck on boot which was very > easy to trigger on my SMP Hyperthreaded Xeon, and I think it fixes it for > the right reasons. > > I believe this patch suffers from apicid versus logical cpu number > confusion. I copied the basic logic from smp_send_reschedule and I can't > find where that translates from the logical cpuid to apicid. So it isn't > quite correct yet. It should be close enough that it shouldn't be too hard > to finish it up. > > More bug fixes after I have slept but I figured I needed to get this > one out for review. > > Signed-off-by: Eric ic W. Biederman <[EMAIL PROTECTED]> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > --- [skip] I've not tried 2.6.13-rc4 itself because i notice changes has been commited into Linus git tree under id: 3d483f47579461a4715db33c68ef8752e5a97a2d http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3d483f47579461a4715db33c68ef8752e5a97a2d and this tree works well for me though previous one [94d2ac66c12397e2ca7988dbf59f24a966d275cb] -- hangs. So i guess it is exactly problem this patch solve. Thank you and for your help. -- Best regards. Alexander Y. Fomichev <[EMAIL PROTECTED]> Public PGP key: http://sysadminday.org.ru/gluk.asc - 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/
Re: 2.6.12 hangs on boot
On Monday 18 July 2005 16:58, Andi Kleen wrote:
> Can you please test if this patch fixes it?
>
> -Andi
>
>
> Don't compare linux processor index with APICID
>
> Fixes boot up lockups on some machines where CPU apic ids
> don't start with 0
>
> Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
>
> Index: linux/arch/x86_64/kernel/smpboot.c
> ===
> --- linux.orig/arch/x86_64/kernel/smpboot.c
> +++ linux/arch/x86_64/kernel/smpboot.c
> @@ -211,7 +211,7 @@ static __cpuinit void sync_master(void *
> {
> unsigned long flags, i;
>
> - if (smp_processor_id() != boot_cpu_id)
> + if (smp_processor_id() != 0)
> return;
>
> go[MASTER] = 0;
No, sorry, the same result -- hangs just after:
Booting processor 2/1 rip 6000 rsp 8100dff7df58
Initializing CPU#2
(hmm... as i can see one string above [and if i understand correctly]
boot_cpu_id == 0 in my case:
CPU 1: Syncing TSC to CPU 0 )
--
Best regards.
Alexander Y. Fomichev <[EMAIL PROTECTED]>
Public PGP key: http://sysadminday.org.ru/gluk.asc
-
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/
Re: 2.6.12 hangs on boot
On Saturday 25 June 2005 02:20, Linus Torvalds wrote:
> On Wed, 22 Jun 2005, Alexander Y. Fomichev wrote:
> > I've been trying to switch from 2.6.12-rc3 to 2.6.12 on Dual EM64T 2.8
> > GHz [ MoBo: Intel E7520, intel 82801 ]
> > but kernel hangs on boot right after records:
> >
> > Booting processor 2/1 rip 6000 rsp 8100023dbf58
> > Initializing CPU#2
>
> Hmm.. Since you seem to be a git user, maybe you could try the git
> "bisect" thing to help narrow down exactly where this happened (and help
> test that thing too ;).
[skiped]
Ok, as i can see [and as Andi guessed
http://bugme.osdl.org/show_bug.cgi?id=4792]
issue have been introduced by new TSC sync algorithm
git id: dda50e716dc9451f40eebfb2902c260e4f62cf34.
And, yes, seems like it depends of timings...
In my case kludge with insertion of low delay (e.g. printk) between
cpu_set/mb and tsc_sync_wait() makes kernel bootable.
diff -urN b/arch/x86_64/kernel/smpboot.c a/arch/x86_64/kernel/smpboot.c
--- b/arch/x86_64/kernel/smpboot.c 2005-07-17 21:55:55.0 +0400
+++ a/arch/x86_64/kernel/smpboot.c 2005-07-17 21:57:56.0 +0400
@@ -451,6 +451,7 @@
cpu_set(smp_processor_id(), cpu_online_map);
mb();
+ printk(KERN_INFO "We're still here!\n");
/* Wait for TSC sync to not schedule things before.
We still process interrupts, which could see an inconsistent
time in that window unfortunately. */
--
Best regards.
Alexander Y. Fomichev <[EMAIL PROTECTED]>
Public PGP key: http://sysadminday.org.ru/gluk.asc
-
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/
Re: 2.6.12 hangs on boot
On Saturday 25 June 2005 02:20, Linus Torvalds wrote:
> On Wed, 22 Jun 2005, Alexander Y. Fomichev wrote:
> > I've been trying to switch from 2.6.12-rc3 to 2.6.12 on Dual EM64T 2.8
> > GHz [ MoBo: Intel E7520, intel 82801 ]
> > but kernel hangs on boot right after records:
> >
> > Booting processor 2/1 rip 6000 rsp 8100023dbf58
> > Initializing CPU#2
>
> Hmm.. Since you seem to be a git user, maybe you could try the git
> "bisect" thing to help narrow down exactly where this happened (and help
> test that thing too ;).
>
> You can basically use git to find the half-way point between a set of
> "known good" points and a "known bad" point ("bisecting" the set of
> commits), and doing just a few of those should give us a much better view
> of where things started going wrong.
>
> For example, since you know that 2.6.12-rc3 is good, and 2.6.12 is bad,
> you'd do
>
> git-rev-list --bisect v2.6.12 ^v2.6.12-rc3
>
> where the "v2.6.12 ^v2.6.12-rc3" thing basically means "everything in
> v2.6.12 but _not_ in v2.6.12-rc3" (that's what the ^ marks), and the
> "--bisect" flag just asks git-rev-list to list the middle-most commit,
> rather than all the commits in between those kernel versions.
>
> You should get the answer "0e6ef3e02b6f07e37ba1c1abc059f8bee4e0847f", but
> before you go any further, just make sure your git index is all clean:
>
> git status
>
> should not print anything else than "nothing to commit". If so, then
> you're ready to try the new "mid-point" head:
>
> git-rev-list --bisect v2.6.12 ^v2.6.12-rc3 > .git/refs/heads/try1
> git checkout try1
>
> which will create a new branch called "try1", where the head is that
> "mid-point", and it will switch to that branch (this requires a fairly
> recent "git", btw, so make sure you update your git first).
>
> Then, compile that kernel, and try it out.
>
> Now, there are two possibilities: either "try1" ends up being good, or it
> still shows the bug. If it is a buggy kernel, then you now have a new
> "bad" point, and you do
>
> git-rev-list --bisect try1 ^v2.6.12-rc3 > .git/refs/heads/try2
> git checkout try2
>
> which is all the same thing as you did before, except now we use "try1" as
> the known bad one rather than v2.6.12 (and we call the new branch "try2"
> of course).
>
> However, if that "try1" is _good_, and doesn't show the bug, then you
> shouldn't replace the other "known good" case, but instead you should add
> it to the list of good commits (aka commits we don't want to know about):
>
> git-rev-list --bisect v2.6.12 ^v2.6.12-rc3 ^try1 > .git/refs/heads/try2
> git checkout try2
>
> ie notice how we now say: want to get the bisection of the commits in
> v2.6.12 (known bad) but _not_ in either of v2.6.12-rc3 or the 'try1'
> branch (which are known good).
>
> After compiling and testing a few kernels, you will have narrowed the
> range down a _lot_, and at some point you can just say
>
> git-rev-list --pretty try4 ^v2.6.12-rc3 ^try1 ^try3
>
> (or however the "success/failure" pattern ends up being - the above
> example line assumes that "try1" didn't have the bug, but "try2" did, and
> then "try3" was ok again but "try4" was buggy), and you'll get a fairly
> small list of commits that are the potential "bad" ones.
>
> After the above four tries, you'd have limited it down to a list of 95
> changes (from the original 1520), so it would really be best to try six or
> seven different kernels, but at that point you'd have it down to less than
> 20 commits and then pinpointing the bug is usually much easier.
>
> And when you're done, you can just do
>
> git checkout master
>
> and you're back to where you started.
>
> Linus
> -
> 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/
Thank you for your answer, i've been on vacations last two weeks,
and i didn't have an access to my mail account.
Hmmm... it seems that 'bisect' method not applicable to this host, this
is production server, not so critical to one or two reboots but 'bisect' will
require much more, i suspect. I've another host, nearly the same as of
hardware and non-critical where such tests could be done , but i haven't a
serial console on it as now. It takes some time to link console because both
of this are remote hosts.
--
Best regards.
Alexander Y. Fomichev <[EMAIL PROTECTED]>
Public PGP key: http://sysadminday.org.ru/gluk.asc
-
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/
Re: 2.6.11: spend too many time in miragtion thread
On Friday 25 March 2005 18:46, Alexander Y. Fomichev wrote: > Yesterday i faced strange behaviour of 2.6.11 on > one of my Dual PIII Gentoo servers. > ( 2xPIII 1400, 2G RAM, Mylex 352, 2x Ethernet Pro 100, DL2k Gigabit Here .config. (sorry, i forgot to send it in previous message.) CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_LOCK_KERNEL=y CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_LOG_BUF_SHIFT=15 CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_KALLSYMS=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_X86_PC=y CONFIG_MPENTIUMIII=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_SMP=y CONFIG_NR_CPUS=32 CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y CONFIG_MICROCODE=m CONFIG_X86_MSR=m CONFIG_X86_CPUID=m CONFIG_EDD=m CONFIG_HIGHMEM4G=y CONFIG_HIGHMEM=y CONFIG_MTRR=y CONFIG_IRQBALANCE=y CONFIG_HAVE_DEC_LOCK=y CONFIG_REGPARM=y CONFIG_PM=y CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_BLACKLIST_YEAR=0 CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y CONFIG_APM=m CONFIG_PCI=y CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y CONFIG_PCI_NAMES=y CONFIG_HOTPLUG_PCI=m CONFIG_HOTPLUG_PCI_ACPI=m CONFIG_BINFMT_ELF=y CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_BLK_DEV_DAC960=y CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_INITRAMFS_SOURCE="" CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_SYN_COOKIES=y CONFIG_IP_TCPDIAG=y CONFIG_NETFILTER=y CONFIG_IP_NF_CONNTRACK=m CONFIG_IP_NF_CT_ACCT=y CONFIG_IP_NF_FTP=m CONFIG_IP_NF_IRC=m CONFIG_IP_NF_TFTP=m CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_LIMIT=m CONFIG_IP_NF_MATCH_IPRANGE=m CONFIG_IP_NF_MATCH_MAC=m CONFIG_IP_NF_MATCH_PKTTYPE=m CONFIG_IP_NF_MATCH_MARK=m CONFIG_IP_NF_MATCH_MULTIPORT=m CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_RECENT=m CONFIG_IP_NF_MATCH_ECN=m CONFIG_IP_NF_MATCH_DSCP=m CONFIG_IP_NF_MATCH_AH_ESP=m CONFIG_IP_NF_MATCH_LENGTH=m CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_MATCH_TCPMSS=m CONFIG_IP_NF_MATCH_HELPER=m CONFIG_IP_NF_MATCH_STATE=m CONFIG_IP_NF_MATCH_CONNTRACK=m CONFIG_IP_NF_MATCH_OWNER=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_IP_NF_TARGET_TCPMSS=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_DSCP=m CONFIG_IP_NF_TARGET_MARK=m CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m CONFIG_NETPOLL=y CONFIG_NET_POLL_CONTROLLER=y CONFIG_NETDEVICES=y CONFIG_DUMMY=m CONFIG_ARCNET=m CONFIG_ARCNET_1201=m CONFIG_ARCNET_1051=m CONFIG_ARCNET_RAW=m CONFIG_ARCNET_COM90xx=m CONFIG_ARCNET_COM90xxIO=m CONFIG_ARCNET_RIM_I=m CONFIG_ARCNET_COM20020=m CONFIG_ARCNET_COM20020_PCI=m CONFIG_NET_ETHERNET=y CONFIG_MII=y CONFIG_NET_PCI=y CONFIG_E100=y CONFIG_E100_NAPI=y CONFIG_DL2K=y CONFIG_NETCONSOLE=y CONFIG_INPUT=y CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 CONFIG_SOUND_GAMEPORT=y CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_LIBPS2=y CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y CONFIG_SERIAL_NONSTANDARD=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 CONFIG_NVRAM=m CONFIG_I2C=m CONFIG_I2C_ALGOBIT=m CONFIG_I2C_ALGOPCF=m CONFIG_SCx200_ACB=m CONFIG_VGA_CONSOLE=y CONFIG_DUMMY_CONSOLE=y CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_EXT2_FS=m CONFIG_REISERFS_FS=y CONFIG_FS_POSIX_ACL=y CONFIG_DNOTIFY=y CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_SYSFS=y CONFIG_TMPFS=y CONFIG_RAMFS=y CONFIG_NFS_FS=y CONFIG_NFS_V3=y CONFIG_NFS_V4=y CONFIG_NFSD=y CONFIG_NFSD_V3=y CONFIG_NFSD_V4=y CONFIG_NFSD_TCP=y CONFIG_LOCKD=y CONFIG_LOCKD_V4=y CONFIG_EXPORTFS=y CONFIG_SUNRPC=y CONFIG_SUNRPC_GSS=y CONFIG_RPCSEC_GSS_KRB5=y CONFIG_MSDOS_PARTITION=y CONFIG_NLS=y CONFIG_NLS_DEFAULT=&quo
2.6.11: spend too many time in miragtion thread
Yesterday i faced strange behaviour of 2.6.11 on one of my Dual PIII Gentoo servers. ( 2xPIII 1400, 2G RAM, Mylex 352, 2x Ethernet Pro 100, DL2k Gigabit Ethernet CONFIG_NFS_FS=y CONFIG_NFSD=y but actually only used as nfs server ) Description: At some moment i've found out that kernel spend ~2/3 (60-70% actually, accoring to vmstat&top) time in miragtion/1, and most of other time in idle ( although it have tasks to run [ps out attached] ) kerneltop shows get_stats and poll_idle on the top permanently: Linux s3.ir.ru 2.6.11 #1 SMP Sat Mar 5 16:22:27 MSK 2005 i686 GNU/Linux Sampling_step: 4 | Address range: 0xc0100294 - 0xc02db797 address function .. 2005-03-24/20:28:44 .. ticks ( 1916) c0266530 get_stats953 c01006c0 poll_idle674 c0265ba0 rio_interrupt 68 c0202b00 __copy_user_intel 5 c013a010 __mod_page_state 2 c0114a40 sub_preempt_count 1 c0139620 buffered_rmqueue 1 c013da40 kmem_cache_free1 c013db00 kfree 1 c01446f0 do_anonymous_page 1 c016d2e0 lookup_mnt 1 c0202c60 __copy_to_user_ll 1 c0202cd0 __copy_from_user_ll1 c028d350 ip_route_output_slow 1 c02921d0 ip_queue_xmit 1 c02a2250 tcp_transmit_skb 1 s3:/var/tmp/kerneltop-0.8# Sorry, but at that time i've had no idea what get_stats related to and i have no interfaces status now, only two pieces of "SysRq-t" ( dmesg too long to 32k buffer and i couldn't get more then ~10k by netconsole, [both attached] ) Another thing, for a long time i observe sun/rpc messages in the kernel log: svc: unknown version (0) svc: unknown version (0) svc: unknown version (0) svc: unknown version (0) svc: unknown version (0) ... but i've no problem with nfsd up to now. -- Best regards. Alexander Y. Fomichev <[EMAIL PROTECTED]> Public PGP key: http://sysadminday.org.ru/gluk.asc SysRq : Changing Loglevel Loglevel set to 6 SysRq : Mem-info: DMA per-cpu:Show Memory cpu 0 hot: low 2, high 6, batch 1 cpu 0 cold: low 0, high 2, batch 1 cpu 1 hot: low 2, high 6, batch 1 cpu 1 cold: low 0, high 2, batch 1 Normal per-cpu: cpu 0 hot: low 32, high 96, batch 16 cpu 1 hot: low 32, high 96, batch 16 cpu 0 cold: low 0, high 32, batch 16 cpu 1 cold: low 0, high 32, batch 16 HighMem per-cpu: cpu 0 hot: low 32, high 96, batch 16 cpu 0 cold: low 0, high 32, batch 16 cpu 1 hot: low 32, high 96, batch 16 cpu 1 cold: low 0, high 32, batch 16 Free pages: 108724kB (4928kB HighMem) Active:67801 inactive:399855 dirty:2500 writeback:0 unstable:0 free:27181 slab:20675 mapped:6550 pagetables:242 DMA free:11220kB min:68kB low:84kB high:100kB active:276kB inactive:24kB present:16384kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 880 2031Normal free:92576kB min:3756kB low:4692kB high:5632kB active:154188kB inactive:543608kB present:901120kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 9215 HighMem free:4928kB min:512kB low:640kB high:768kB active:116740kB inactive:1055788kB present:1179584kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0DMA: 255*4kB 0 0 64*32kB 21*64kB 143*8kB 106*16kB 1*128kB 1*512kB 1*1024kB 1*256kB 1*2048kB 0*4096kB = 11220kB Normal: 5870*4kB 3193*8kB 2242*16kB 96*32kB 0*64kB 0*128kB 0*256kB 1*512kB 0*1024kB Total swap = 497972kB 524272 pages of RAM 294896 pages of HIGHMEM 5964 reserved pages 375189 pages shared 0 pages swap cached SysRq : Show Regs SysRq : Show State sibling 0001 task PC pid father child younger older init S (NOTLB) 0 1 0 c23f4ea8 0082 c01396d9 2f6ca56c0 c1436880 00d0 c01391a5 0001 c0332580 3ef9225c 0005d6ed c0169e41 f6c5aa40 0005d6ed c23f3c0c f6cec560 c200ff60 2ae7 3efa1562 620230db c23f4ebc prep_new_page+0x55/0x60 000b Call Trace: [] [] [] buffered_rmqueue+0xb9/0x1e0 __d_lookup+0x91/0x140 [] schedule_timeout+0x6f/0xd0 [] link_path_walk+0xa00/0xd20 [] process_timeout+0x0/0x10 [] pipe_poll+0x32/0xb0 [] []migration/1[] [] [] [] [] autoremove_wake_function+0x0/0x50 [] ret_from_fork+0x6/0x14 [] autoremove_wake_function+0x0/0x50 [] serio_thread+0x0/0x140 [] kernel_thread_helper+0x5/0x10 0020 kirqd S []portmap[]c16d1280 _spin_unlock+0xd/0x30 1000 c037e320 [] worker_thread+0x215/0x240 [] schedule_timeout+0x6f/0xd0 __alloc_pages+0x294/0x3b0 [] []
Re: 2.6.11-rc3-bk5: XFS: fcron: could not write() buf to disk: Resource temporarily unavailable
On Thursday 10 February 2005 07:54, Nathan Scott wrote: > On Wed, Feb 09, 2005 at 05:44:54PM +0300, Alexander Y. Fomichev wrote: > > On Wednesday 09 February 2005 04:29, Nathan Scott wrote: > > > Is that an O_SYNC write, do you know? Or a write to an inode > > > with the sync flag set? > > > > Yes, it is O_SYNC, as i can see from fcron sources, and, no, kernel > > OK, thanks. > > > > I'm chasing down a problem similar to this atm, so far looks like > > > something in the generic VM code below sync_page_range is giving > > > back EAGAIN, and that is getting passed back out to userspace by > > > XFS. Not sure where/why/how its been caused yet though ... I'll > > > let you know once I have a fix or have found the culprit change. > > Turns out it was actually XFS giving back this EAGAIN, indirectly - > and some of the generic VM routines have been tweaked recently to > propogate more sync write errors out to userspace. Try this patch, > it will fix your problem - we're still discussing if this is the > ideal fix, so something else may be merged in the end. > > cheers. Yes, it works. Thank you for quick patch. -- Best regards. Alexander Y. Fomichev <[EMAIL PROTECTED]> Public PGP key: http://sysadminday.org.ru/gluk.asc - 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/
Re: 2.6.11-rc3-bk5: XFS: fcron: could not write() buf to disk: Resource temporarily unavailable
On Wednesday 09 February 2005 04:29, Nathan Scott wrote: > On Tue, Feb 08, 2005 at 08:51:36PM +0300, Alexander Y. Fomichev wrote: > > G' day > > > > It looks like XFS broken somewhere in 2.6.11-rc1, > > sadly i can't sand "right" bugreport, some facts only. > > Upgrade to 2.6.11-rc2 makes fcron non-working for me in case of > > crontabs directory is placed on XFS partition. > > When i try to install new crontab fcrontab die with error: > > "could not write() buf to disk: Resource temporarily unavailable" > > Is that an O_SYNC write, do you know? Or a write to an inode > with the sync flag set? Yes, it is O_SYNC, as i can see from fcron sources, and, no, kernel have been compiled without xattrs support (if i understand your question correctly) > > > The same time it works with 2.6.10. > > I'm chasing down a problem similar to this atm, so far looks like > something in the generic VM code below sync_page_range is giving > back EAGAIN, and that is getting passed back out to userspace by > XFS. Not sure where/why/how its been caused yet though ... I'll > let you know once I have a fix or have found the culprit change. > > cheers. Tnx for quick answer. PS: i forgot to mention last time i tested 2.6.11-rc3-bk5 with the same results. -- Best regards. Alexander Y. Fomichev <[EMAIL PROTECTED]> Public PGP key: http://sysadminday.org.ru/gluk.asc - 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/
2.6.11-rc3-bk5: XFS: fcron: could not write() buf to disk: Resource temporarily unavailable
G' day It looks like XFS broken somewhere in 2.6.11-rc1, sadly i can't sand "right" bugreport, some facts only. Upgrade to 2.6.11-rc2 makes fcron non-working for me in case of crontabs directory is placed on XFS partition. When i try to install new crontab fcrontab die with error: "could not write() buf to disk: Resource temporarily unavailable" [EMAIL PROTECTED] gluk $ crontab test 20:10:57 installing file /home/gluk/test for user gluk 20:10:57 could not write() buf to disk: Resource temporarily unavailable 20:10:57 Since fcrontab has not been able to save new.gluk's file, it will keep the previous version (if any) of new.gluk. 20:10:57 Error while copying file. Aborting. The same time it works with 2.6.10. Some trick like mount -o bind from non-xfs (reiserfs in my case) partition helps too. some googling shows that similar problem took plase for 2.6.11-rc1 and postfix: http://www.webservertalk.com/message879262.html -- Best regards. Alexander Y. Fomichev <[EMAIL PROTECTED]> Public PGP key: http://sysadminday.org.ru/gluk.asc - 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/
