Bug 123618 - pjones-rawhiden cdparanoia packages make kernel oops
Summary: pjones-rawhiden cdparanoia packages make kernel oops
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: cdparanoia
Version: 2
Hardware: athlon
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-05-19 17:58 UTC by Dams
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-10-08 21:21:05 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
kernel trace (bziped) (2.05 KB, application/octet-stream)
2004-05-19 17:58 UTC, Dams
no flags Details

Description Dams 2004-05-19 17:58:13 UTC
Description of problem:
On a dual athlon, i've been running stock fc2 grip, with
cdparanoia-libs (0:alpha9.8-20.1sgio) from
http://people.redhat.com/pjones/cdparanoia/ with an usb2 cdrom device,
and had some kernel oops. Please see attached file for trace.

Version-Release number of selected component: 2.6.5-1.358smp

Comment 1 Dams 2004-05-19 17:58:58 UTC
Created attachment 100353 [details]
kernel trace (bziped)

Comment 2 Peter Jones 2004-05-19 19:41:11 UTC
This is from cdparanoia asking for a large buffer, and the kernel not
having enough contiguous ram in ZONE_CRAPPY to allocate a bounce
buffer.  I'm writing a backoff algorithm in cdparanoia; you may still
get the warning, but it won't be fatal.

Comment 3 Peter Jones 2004-07-08 19:34:23 UTC
Dams, can you try the cdparanoia-alpha9.8-21sgio1.i386.rpm packages
for fc2 on people.redhat.com?

I don't know if they'll _fix_ your issue, but they may alleviate it
some.  In 20.*sgio, it sometimes will hit a codepath in the kernel
that gives -EIO, but it's expecting -ENOMEM for it.  This update makes
it avoid that case.

So this should at least cause it to get -ENOMEM, and try to
compensate, instead.  I still can't duplicate your issue exactly, so
it still might not work 100%, but there is at least some code to
handle what's going on this way.  It might work ;)

Comment 4 Dams 2004-07-11 14:52:21 UTC
As soon as I started to rip : 

grip: page allocation failure. order:5, mode:0xd0
 [<0213b2ad>] __alloc_pages+0x29d/0x2b7
 [<0213b2df>] __get_free_pages+0x18/0x24
 [<0213dd08>] kmem_getpages+0x1c/0xbf
 [<0213e7bf>] cache_grow+0x9f/0x1f3
 [<0213ea89>] cache_alloc_refill+0x176/0x1b0
 [<0213ef53>] __kmalloc+0x6f/0x81
 [<021f933e>] blk_rq_map_user+0x78/0x121
 [<021fc04c>] sg_io+0xb0/0x258
 [<0214fa0e>] rw_vm+0x242/0x26b
 [<0214fcc9>] get_user_size+0x2e/0x55
 [<021fc615>] scsi_cmd_ioctl+0x18e/0x385
 [<0213b2bd>] __alloc_pages+0x2ad/0x2b7
 [<02149180>] anon_vma_prepare+0x18/0x8f
 [<0214543f>] do_anonymous_page+0x1a7/0x1c2
 [<021454c3>] do_no_page+0x69/0x2da
 [<0222316f>] cdrom_ioctl+0x2b/0xa48
 [<02119d67>] do_page_fault+0x133/0x4f6
 [<02146acc>] vma_merge+0x155/0x165
 [<02146f06>] do_mmap_pgoff+0x383/0x5ef
 [<021fb046>] blkdev_ioctl+0x33e/0x352
 [<02158aea>] block_ioctl+0x11/0x13
 [<02160f52>] sys_ioctl+0x207/0x243

kernel is 2.6.6-1.435smp

Comment 5 Peter Jones 2004-10-08 21:21:05 UTC
This should be fixed.


Note You need to log in before you can comment on or make changes to this bug.