Bug 344821
| Summary: | Kernel 2.6.23.1-10 panics randomly after install | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Gilbert Sebenste <sebenste> |
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | low | ||
| Version: | 7 | CC: | ron |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-01-15 19:56:01 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Gilbert Sebenste
2007-10-22 02:09:52 UTC
c10622b4 <sync_page>:
c10622b4: 89 c1 mov %eax,%ecx
c10622b6: f0 83 04 24 00 lock addl $0x0,(%esp)
c10622bb: 8b 50 10 mov 0x10(%eax),%edx
c10622be: 8b 00 mov (%eax),%eax
c10622c0: 66 85 c0 test %ax,%ax
c10622c3: 79 07 jns c10622cc <sync_page+0x18>
c10622c5: ba 40 fd 2f c1 mov $0xc12ffd40,%edx
c10622c6: R_386_32 swapper_space
c10622ca: eb 0f jmp c10622db <sync_page+0x27>
c10622cc: 8b 01 mov (%ecx),%eax
c10622ce: 84 c0 test %al,%al
c10622d0: 78 1b js c10622ed <sync_page+0x39>
c10622d2: f6 c2 01 test $0x1,%dl
c10622d5: 75 16 jne c10622ed <sync_page+0x39>
c10622d7: 85 d2 test %edx,%edx
c10622d9: 74 12 je c10622ed <sync_page+0x39>
c10622db: 8b 42 38 mov 0x38(%edx),%eax
c10622de: 85 c0 test %eax,%eax
c10622e0: 74 0b je c10622ed <sync_page+0x39>
c10622e2: 8b 50 08 mov 0x8(%eax),%edx
c10622e5: 85 d2 test %edx,%edx
c10622e7: 74 04 je c10622ed <sync_page+0x39>
c10622e9: 89 c8 mov %ecx,%eax
c10622eb: ff d2 call *%edx
c10622ed: e8 0e 93 1b 00 call c121b600 <io_schedule>
c10622ee: R_386_PC32 io_schedule
c10622f2: 31 c0 xor %eax,%eax
c10622f4: c3 ret
(To actually find the right address, you need to subtract 0x400000 from and add
0x1000000 to the reported one.)
static int sync_page(void *word)
{
struct address_space *mapping;
struct page *page;
page = container_of((unsigned long *)word, struct page, flags);
smp_mb();
mapping = page_mapping(page);
if (mapping && mapping->a_ops && mapping->a_ops->sync_page)
mapping->a_ops->sync_page(page);
io_schedule();
return 0;
}
The mapping for page <c2be0fa0> is gone.
Is there anything unusual about what the running program is doing? What kind of
filesystem is its data on?
Not that I am aware of. It's a program called "McIDAS", which I use to make weather maps. It kicks off a script every 60 seconds, so there are lots of xinetd messages about it in the log file. Here's my /var/log/messages file so far this week. I attempted to take out the McIDAS messages, but I don't have xemacs to access right now, and pico wasn't cutting it. http://weather.niu.edu/crap This continues with the 2.6.23.1-21 kernel as well. This did *not* happen under 2.6.23.1-8. What changed between -8 and -10? (In reply to comment #4) > This continues with the 2.6.23.1-21 kernel as well. This did *not* happen > under 2.6.23.1-8. What changed between -8 and -10? Very little, and nothing that should cause this. Is the program memory-mapping files on local ext3 filesystems? Yes. -rw-rw-r-- 1 (username) users 203886592 2007-11-04 11:50 ldm.pq -rw-rw-r-- 1 (username) users 30834688 2007-11-04 11:51 pqsurf.pq It uses the LDM weather data manager; if you do a search on Google with LDM Memory Mapping it gives you an idea of how it works. basically, it shoves an hour's woth of weather data into those two files, with "pqsurf.pq" just current hourly airport readings, with the ldm.pq containing everything else from satellite and radar binary data, to weather balloon data, etc. |