i might be completely wrong - but the sv_wait thing was once observed
as an gcc 2.95 problem - maybe this is the reason? (just an idea)
t
ananth@xxxxxxxxxxxx <pv@xxxxxxxxxxxxx> wrote:
> View Incident:
> http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800480
> Submitter: ananth Submitter Domain : engr
> Assigned Engineer : nb Assigned Domain : sgi.com
> Assigned Group : xfs-linux Category : software
> Customer Reported : F Priority : 2
> Project: xfs-linux Status : open
> Description:
> We have a semi-production build machine that is
> running XFS bits as of 8/23/00. I have seen
> things like "rm" getting into the following backtrace:
> ---------
> schedule+0x415
> _sv_wait+0xcd
> xlog_grant_log_space+0x139
> xfs_log_reserve+0x7b
> xfs_trans_reserve+0x76
> xfs_inactive+0x1ca
> vn_put+0x47
> linvfs_d_iput+0x1a
> d_delete+0x57
> vfs_unlink+0x18b
> sys_unlink+0x9b
> system_call+0x34
> -----------
> and wait for ever. Both the page_cleaner and pagebuf
> daemon had a normal backtrace (ie. both waiting on
> their respective timer/semaphore). No other
> suspicious looking backtraces in other processes.
> The machine was mostly alive except for commands
> that would touch the xfs filesystem.
> ananth.
--
thomas.graichen@xxxxxxxxxxxxx
technical director innominate AG
clustering & security networking people
tel: +49.30.308806-13 fax: -77 http://innominate.de
|