Bug 197805 - 4.14.0-rc8 - Oops - EIP: __blk_rq_unmap_user - unable to handle kernel paging request
Summary: 4.14.0-rc8 - Oops - EIP: __blk_rq_unmap_user - unable to handle kernel paging...
Status: NEW
Alias: None
Product: IO/Storage
Classification: Unclassified
Component: Serial ATA (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Tejun Heo
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-11-07 18:35 UTC by alertesmails
Modified: 2017-12-30 10:49 UTC (History)
0 users

See Also:
Kernel Version: 4.14.0-rc8
Tree: Mainline
Regression: No


Attachments
lspci (1.34 KB, text/plain)
2017-11-07 18:35 UTC, alertesmails
Details
syslog trace (4.90 KB, text/plain)
2017-11-07 18:37 UTC, alertesmails
Details

Description alertesmails 2017-11-07 18:35:41 UTC
Created attachment 260541 [details]
lspci

cpu : Skylake i3 6100H
Distribution : slackware 14.2 32 bits

I attach :
- lspci
- syslog trace
Comment 1 alertesmails 2017-11-07 18:37:08 UTC
Created attachment 260543 [details]
syslog trace
Comment 2 alertesmails 2017-11-30 20:20:42 UTC
Idem with all next kernels. And now with 4.14.3.

The problem occurs often when I do "lilo -v" after compiling a kernel.

Maybe important :a script does the following at start (powertop advice) :
echo "sata power management"
echo 'min_power' > '/sys/class/scsi_host/host0/link_power_management_policy';
echo 'min_power' > '/sys/class/scsi_host/host1/link_power_management_policy';
echo 'min_power' > '/sys/class/scsi_host/host2/link_power_management_policy';
echo 'min_power' > '/sys/class/scsi_host/host3/link_power_management_policy';
Comment 3 alertesmails 2017-12-07 07:40:16 UTC
Idem on 4.14.4

It is always the same address 6b6b6b7b. 
 BUG: unable to handle kernel paging request at 6b6b6b7b
Comment 4 alertesmails 2017-12-30 10:49:32 UTC
surprising to still see this so old and reproducible bug...

It occurs again when doing lilo -v after compiling 4.14.10

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