Opened 15 years ago
Closed 15 years ago
#5473 closed bug (fixed)
PageWriteWrapper: Failed to write page 0x83948fa4: General system error
Reported by: | bga | Owned by: | bonefish |
---|---|---|---|
Priority: | high | Milestone: | R1/alpha2 |
Component: | System/Kernel | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
When running Firefox with GNash and playing a YoutTube video I got millions of messages like the one above in syslog. So much so that the syslog_daemon and page writer are the ones using most of my CPU. just to make it more complete, here is a bigger syslog snippet:
2010-02-24 15:11:38 KERN: PageWriteWrapper: Failed to write page 0x83948e18: General system error 2010-02-24 15:11:38 KERN: PageWriteWrapper: Failed to write page 0x83948e44: General system error 2010-02-24 15:11:38 KERN: PageWriteWrapper: Failed to write page 0x83948e70: General system error 2010-02-24 15:11:38 KERN: PageWriteWrapper: Failed to write page 0x83948e9c: General system error 2010-02-24 15:11:38 KERN: PageWriteWrapper: Failed to write page 0x83948ec8: General system error 2010-02-24 15:11:38 KERN: PageWriteWrapper: Failed to write page 0x83948dc0: General system error 2010-02-24 15:11:38 KERN: PageWriteWrapper: Failed to write page 0x83948dec: General system error 2010-02-24 15:11:38 KERN: PageWriteWrapper: Failed to write page 0x83948ef4: General system error 2010-02-24 15:11:38 KERN: PageWriteWrapper: Failed to write page 0x83948f20: General system error 2010-02-24 15:11:38 KERN: PageWriteWrapper: Failed to write page 0x83948f4c: General system error 2010-02-24 15:11:38 KERN: PageWriteWrapper: Failed to write page 0x83948f78: General system error 2010-02-24 15:11:38 KERN: PageWriteWrapper: Failed to write page 0x83948fa4: General system error
Note that the youtube video seems to play fine anyway.
This is with hrev35606.
Attachments (2)
Change History (10)
follow-up: 3 comment:1 by , 15 years ago
comment:2 by , 15 years ago
I need to toggle fullscreen button in youtube flash player to trigger the exact same behavior. But because of high cpu usage video starts to drop frames.
follow-up: 4 comment:3 by , 15 years ago
Replying to bonefish:
Some info on one or two of the concerned pages would be helpful, particularly what the "page" and "cache" debugger commands have to say (given the page respectively the page's cache).
Probably the effect of the problem pointed out in hrev35484. Though that should actually only happen in low memory situations.
Sorry for the delay to reply to this. Still catching up after a long trip. I will try to reproduce this again later today when I am back at home and will provide the requested information.
Considering that this did not result in a KDL, will the information still be relevant if I have to manually enter KDL and then run the page and cache commands?
comment:4 by , 15 years ago
Replying to bga:
Considering that this did not result in a KDL, will the information still be relevant if I have to manually enter KDL and then run the page and cache commands?
Absolutely. Assuming the failure to write the page to disk is a permanent one, it cannot be freed or removed from the cache, so the situation should be unchanged.
Come to think of it, the "page_stats" and "slabs" output (no parameters) could also be of interest. If, as I assume, the pages belong to the port heap, this means your system is actively paging, which only happens when the system runs low on free and cached pages.
comment:5 by , 15 years ago
Sorry for the delay. See attached images. The first one shows the page and cache outputs for one page that failed. the second one shows page_stats and slabs output (note it wraps around the screen).
In any case, I noticed that this only seem to be triggered when going to fullscreen mode, as reported by diver. in case it matters, it is the VESA driver.
by , 15 years ago
Attachment: | page-cache.jpg added |
---|
by , 15 years ago
comment:6 by , 15 years ago
Not at all what I thought. The page is still mmap()ped, but the mapped file has been truncated to size 0. We're apparently not handling this case correctly.
comment:7 by , 15 years ago
Milestone: | R1 → R1/alpha2 |
---|---|
Owner: | changed from | to
Status: | new → in-progress |
Looking into it.
comment:8 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | in-progress → closed |
I haven't tested with gnash, but hrev36374 fixes mmap_resize_test, which produced a similar situation. Please reopen, if it still occurs.
Some info on one or two of the concerned pages would be helpful, particularly what the "page" and "cache" debugger commands have to say (given the page respectively the page's cache).
Probably the effect of the problem pointed out in hrev35484. Though that should actually only happen in low memory situations.