Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Tuesday 11 May 2004 11:21, Philipp Reisner wrote: > On Tuesday 11 May 2004 11:03, Eugene Crosser wrote: > > On Tue, 2004-05-11 at 12:28, Lars Ellenberg wrote: > > > > As with today the only open issue is that it currently does > > > > not work with XFS. (Earlier releases already worked with XFS, > > > > it must be something on the surface..., not a desing bug...) > > > > > > note that in my 2.6.5 uml setup, xfs *seems* to work at first. > > > it hangs every now and then in some strange code path seemingly > > > unrelated to DRBD, though. (it does so on plain DM, too, when not that > > > often as on top of DRBD; so this might be an issue with my UML > > > kernel)... > > > > I'd like to add that 2.6 kernel is *known* to have issue(s) with ext3, > > causing deadlocks, unrelated to DRBD. That is for sure when quota is > > enabled, but as far as I could figure from the developers' comments, > > they might show without quota too. So, there is *some* possibility that > > xfs might have similar issues. > > My issue with XFS here is: > > Trying to fix it up, but a reboot is needed > Bad page state at free_hot_cold_page (in process 'drbd0_receiver', page > c117e350 > flags:0x20000084 mapping:00000000 mapped:0 count:0 > Backtrace: > Call Trace: > [<c01424e2>] bad_page+0x56/0x7c > [<c0142cbb>] free_hot_cold_page+0x63/0xf0 > [<c0142d4f>] free_hot_page+0x7/0x8 > [<c0148731>] __page_cache_release+0xfd/0x104 > [<c02a8682>] skb_release_data+0x62/0x94 > [<c02a86bf>] kfree_skbmem+0xb/0x1c > [<c02a87cc>] __kfree_skb+0xfc/0x104 > [<c02d5451>] tcp_clean_rtx_queue+0x151/0x330 > [<c02d5caa>] tcp_ack+0x176/0x398 > [<c02d817d>] tcp_rcv_established+0xcd/0x680 > [<c02e10c5>] tcp_v4_do_rcv+0x21/0x120 > [<c02a7d14>] __release_sock+0x84/0xbc > [<c02a83ad>] release_sock+0x55/0xc0 > [<c02d0797>] tcp_data_wait+0x6f/0xb4 > [<c0121ad4>] autoremove_wake_function+0x0/0x38 > [<c0121ad4>] autoremove_wake_function+0x0/0x38 > [<c02d0dcf>] tcp_recvmsg+0x3cb/0x70c > [<c02f0adf>] inet_recvmsg+0x43/0x5c > [<c02a4b0f>] sock_recvmsg+0x8f/0xac > [<c011ef18>] default_wake_function+0x0/0x1c > [<ce895fd7>] drbd_recv+0x157/0x220 [drbd] > [<ce896713>] drbd_recv_header+0x13/0x98 [drbd] > [<ce898c7e>] drbdd+0xae/0xbc [drbd] > [<ce8993bb>] drbdd_init+0x43/0x15c [drbd] > [<ce88eb9c>] drbd_thread_setup+0x94/0x108 [drbd] > [<ce88eb08>] drbd_thread_setup+0x0/0x108 [drbd] > [<c0107255>] kernel_thread_helper+0x5/0xc > > > I just started to look into this... > Hmmm, The free_pages_check() from page_alloc.c causes this stacktrace, because the PG_slab bit is set. flags:0x20000084 => ... | PG_slab | PG_referenced The code from free_pages_check(): if ( page_mapped(page) || page->mapping != NULL || page_count(page) != 0 || (page->flags & ( 1 << PG_lru | 1 << PG_private | 1 << PG_locked | 1 << PG_active | 1 << PG_reclaim | 1 << PG_slab | 1 << PG_writeback ))) bad_page(function, page); I can not believe that it is DRBD's fault that PG_slab is set on this page... -Philipp -- : Dipl-Ing Philipp Reisner Tel +43-1-8178292-50 : : LINBIT Information Technologies GmbH Fax +43-1-8178292-82 : : Schönbrunnerstr 244, 1120 Vienna, Austria http://www.linbit.com :