Bug 79501 - BUG: unable to handle kernel paging request at 48d8ff05 - AMD Dual-Core E350
Summary: BUG: unable to handle kernel paging request at 48d8ff05 - AMD Dual-Core E350
Status: CLOSED DUPLICATE of bug 87971
Alias: None
Product: ACPI
Classification: Unclassified
Component: Power-Video (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: Lv Zheng
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-04 22:18 UTC by Paul Menzel
Modified: 2015-05-18 02:15 UTC (History)
5 users (show)

See Also:
Kernel Version: 3.14.9
Tree: Mainline
Regression: Yes


Attachments
`sudo acpidump -o 20140708--acpidump--vendor-bios-p180.txt (56.25 KB, text/plain)
2014-07-08 07:04 UTC, Paul Menzel
Details
sudo acpidump -o 20140708--asrock-e350m1-vendor-bios-p180--superiotool-deV.log (18.00 KB, text/plain)
2014-07-08 21:26 UTC, Paul Menzel
Details
`sudo acpidump -o 20140708--acpidump--vendor-bios-p180.txt (137.18 KB, text/plain)
2014-07-08 21:28 UTC, Paul Menzel
Details
Linux message from ring buffer acquired with `dmesg` (115.50 KB, text/plain)
2014-07-09 20:01 UTC, Paul Menzel
Details
[DBG PATCH] ACPI/OSL: Catch memory mappings for acpi_map (610 bytes, patch)
2014-09-19 07:36 UTC, Lv Zheng
Details | Diff
`journalctl --dmesg -a` with vendor firmware P1.80 and Linux 3.16.5 x86_64 (258.68 KB, text/plain)
2014-10-25 09:19 UTC, Paul Menzel
Details
`sudo acpidump -o 20141025--acpidump--vendor-firmware-p180--Linux-3.16.5-x86_64.txt` (137.18 KB, text/plain)
2014-10-25 09:23 UTC, Paul Menzel
Details
journalctl -k -b (165.83 KB, text/plain)
2014-12-31 08:51 UTC, Paul Menzel
Details
journalctl -k -b # debug patch and fix applied on top of 3.16.7 (206.90 KB, text/plain)
2015-01-10 20:33 UTC, Paul Menzel
Details

Description Paul Menzel 2014-07-04 22:18:39 UTC
Using the ASRock E350M1 [1] and Debian GNU/Linux Sid/unstable, starting the system with the internal graphics device, KMS did not work and only the console was shown (low resolution) and as a result of the KMS failure X did not start either.

$ uname -a
Linux myhostname 3.14-1-686-pae #1 SMP Debian 3.14.9-1 (2014-06-30) i686 GNU/Linux
$ more /var/log/syslog
[…]
[   53.530560] [Firmware Bug]: ACPI: No _BQC method, cannot determine initial brightness
[   53.530714] BUG: unable to handle kernel paging request at 48d8ff05
[   53.537149] IP: [<c129d5ad>] acpi_ex_system_memory_space_handler+0x1b3/0x1ee
[   53.544309] *pdpt = 0000000036c8d001 *pde = 0000000000000000 
[   53.550202] Oops: 0002 [#1] SMP 
[   53.553583] Modules linked in: video(+) button thermal_sys ext4 crc16 mbcache jbd2 crc32c btrfs xor raid6_pq sha256_generic cbc dm_crypt hid_generic usbhid hid dm_mod raid1 md_mod sg sd_mod crc_t10dif crct10dif_generic crct10dif_common ata_generic ohci_pci r8169 mii pata_atiixp sp5100_tco ahci libahci libata ohci_hcd scsi_mod ehci_pci ehci_hcd usbcore usb_common
[   53.587828] CPU: 0 PID: 427 Comm: udevd Not tainted 3.14-1-686-pae #1 Debian 3.14.9-1
[   53.595711] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./E350M1, BIOS P1.80 12/21/2012
[   53.605063] task: f774fa90 ti: f6b58000 task.ti: f6b58000
[   53.610507] EIP: 0060:[<c129d5ad>] EFLAGS: 00010246 CPU: 0
[   53.616037] EIP is at acpi_ex_system_memory_space_handler+0x1b3/0x1ee
[   53.622517] EAX: 00000001 EBX: 00000008 ECX: 000000fb EDX: 00000008
[   53.628827] ESI: f6d16260 EDI: 48d8ff05 EBP: f6b59a4c ESP: f6b59944
[   53.635136]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[   53.640578] CR0: 80050033 CR2: 48d8ff05 CR3: 36890000 CR4: 000007f0
[   53.646889] Stack:
[   53.648948]  00000014 c108bdfb 00000246 000080d0 000080d0 c12aa973 000000fb 00000000
[   53.657147]  00000001 00000000 00000000 f7428df8 f7437b88 f7433828 c129d3fa c1297758
[   53.665345]  f6b59a4c 00000000 f6d16260 5d8072f5 e410ea65 288d1c25 00000000 f742a768
[   53.673545] Call Trace:
[   53.676039]  [<c108bdfb>] ? up+0xb/0x40
[   53.679919]  [<c12aa973>] ? acpi_ut_release_mutex+0x61/0x70
[   53.685534]  [<c129d3fa>] ? acpi_ex_do_logical_op+0x16c/0x16c
[   53.691324]  [<c1297758>] ? acpi_ev_address_space_dispatch+0x197/0x1e6
[   53.697893]  [<c129a583>] ? acpi_ex_access_region+0x1e0/0x26b
[   53.703684]  [<c129aa0d>] ? acpi_ex_field_datum_io+0x102/0x1cc
[   53.709559]  [<c129abc9>] ? acpi_ex_write_with_update_rule+0xf2/0xf9
[   53.715955]  [<c129a8f2>] ? acpi_ex_insert_into_field+0x2e4/0x2fd
[   53.722092]  [<c129a380>] ? acpi_ex_write_data_to_field+0x187/0x1aa
[   53.728399]  [<c12a0117>] ? acpi_ns_lookup+0x1fb/0x324
[   53.733582]  [<c129e28a>] ? acpi_ex_store_object_to_node+0x9d/0xb0
[   53.739805]  [<c129e34f>] ? acpi_ex_store+0xb2/0x211
[   53.744814]  [<c129ba9d>] ? acpi_ex_opcode_1A_1T_1R+0x44b/0x565
[   53.750778]  [<c129ded9>] ? acpi_ex_resolve_operands+0x1dd/0x4c5
[   53.756825]  [<c1294a93>] ? acpi_ds_exec_end_op+0xbf/0x39f
[   53.762356]  [<c12a4596>] ? acpi_ps_get_next_arg+0x2e1/0x341
[   53.768058]  [<c12877c7>] ? acpi_os_release_object+0x5/0x8
[   53.773588]  [<c12a56b6>] ? acpi_ps_append_arg+0x16/0x76
[   53.778942]  [<c12a4a96>] ? acpi_ps_parse_loop+0x4a0/0x4de
[   53.784473]  [<c12a5396>] ? acpi_ps_parse_aml+0x7d/0x229
[   53.789829]  [<c12a5a2c>] ? acpi_ps_execute_method+0x196/0x234
[   53.795705]  [<c12a0e23>] ? acpi_ns_evaluate+0x1b0/0x23a
[   53.801060]  [<c12a32f7>] ? acpi_evaluate_object+0x112/0x1f3
[   53.806763]  [<c108bdfb>] ? up+0xb/0x40
[   53.810646]  [<c1287751>] ? acpi_os_signal_semaphore+0x17/0x23
[   53.816523]  [<c12a9085>] ? acpi_ut_copy_iobject_to_eobject+0x54/0x71
[   53.823004]  [<c1287b8b>] ? acpi_execute_simple_method+0x4f/0x56
[   53.829057]  [<f840c2e6>] ? acpi_video_device_lcd_set_level+0x26/0xa6 [video]
[   53.836231]  [<f840d5ed>] ? acpi_video_bus_add+0x8ed/0xbf9 [video]
[   53.842453]  [<c11aa860>] ? kernfs_create_link+0x50/0x80
[   53.847809]  [<c11a7b98>] ? sysfs_do_create_link_sd.isra.2+0x48/0x80
[   53.854204]  [<c128a450>] ? acpi_device_probe+0x28/0xbb
[   53.859475]  [<c1301aa8>] ? driver_probe_device+0x68/0x210
[   53.865004]  [<c128a35e>] ? __acpi_match_device+0x21/0x3f
[   53.870446]  [<c1301c80>] ? __device_attach+0x30/0x30
[   53.875542]  [<c1301cf1>] ? __driver_attach+0x71/0x80
[   53.880637]  [<c13003ef>] ? bus_for_each_dev+0x3f/0x70
[   53.885821]  [<c1301696>] ? driver_attach+0x16/0x20
[   53.890743]  [<c1301c80>] ? __device_attach+0x30/0x30
[   53.895839]  [<c130138f>] ? bus_add_driver+0x12f/0x1e0
[   53.901021]  [<c1302201>] ? driver_register+0x51/0xd0
[   53.906119]  [<f840c2a7>] ? acpi_video_register+0x3e/0x57 [video]
[   53.912256]  [<f8412094>] ? acpi_video_init+0x7d/0xfe9 [video]
[   53.918130]  [<f8412017>] ? video_set_use_native_backlight+0xa/0xa [video]
[   53.925046]  [<c10020b1>] ? do_one_initcall+0x51/0x120
[   53.930228]  [<f8412017>] ? video_set_use_native_backlight+0xa/0xa [video]
[   53.937146]  [<c1048828>] ? set_memory_nx+0x58/0x60
[   53.942068]  [<c10b4f6b>] ? load_module+0x185b/0x20b0
[   53.947168]  [<c10b58bc>] ? SyS_finit_module+0x5c/0x70
[   53.952350]  [<c142ec06>] ? sysenter_do_call+0x12/0x16
[   53.957525] Code: 04 89 45 00 89 55 04 eb 53 0f b7 07 eb 02 8b 07 89 45 00 c7 45 04 00 00 00 00 eb 40 83 fb 10 74 25 77 0c 83 fb 08 75 34 8b 45 00 <88> 07 eb 2d 83 fb 20 74 1a 83 fb 40 75 23 8b 45 00 8b 55 04 89
[   53.979705] EIP: [<c129d5ad>] acpi_ex_system_memory_space_handler+0x1b3/0x1ee SS:ESP 0068:f6b59944
[   53.988814] CR2: 0000000048d8ff05
[   53.992240] ---[ end trace cf5c709a5460b48c ]---
[…]
Comment 1 Paul Menzel 2014-07-05 21:38:12 UTC
This happens during every start with the internal graphics.

It does not happen when using the firmware alternative coreboot [1].

[1] http://www.coreboot.org/
Comment 2 Zhang Rui 2014-07-07 05:43:02 UTC
please attach the acpidump of this machine.
Comment 3 Lv Zheng 2014-07-08 04:02:53 UTC
This looks like a video issue.
ACPI video is trying to access a system memory region that is not available.
Comment 4 Paul Menzel 2014-07-08 07:04:34 UTC
Created attachment 142411 [details]
`sudo acpidump -o 20140708--acpidump--vendor-bios-p180.txt

(In reply to Zhang Rui from comment #2)
> please attach the acpidump of this machine.

I’ll attach the output captured with the version below.

    $ acpidump -v

    Intel ACPI Component Architecture
    ACPI Binary Table Dump Utility version 20140424-32 [May  7 2014]
    Copyright (c) 2000 - 2014 Intel Corporation
Comment 5 Paul Menzel 2014-07-08 07:05:16 UTC
Note that the system also does not shut down properly and just hangs in the shutdown process.
Comment 6 Lv Zheng 2014-07-08 08:25:34 UTC
(In reply to Paul Menzel from comment #4)
> Created attachment 142411 [details]
> `sudo acpidump -o 20140708--acpidump--vendor-bios-p180.txt
> 
> (In reply to Zhang Rui from comment #2)
> > please attach the acpidump of this machine.
> 
> I’ll attach the output captured with the version below.
> 
>     $ acpidump -v
> 
>     Intel ACPI Component Architecture
>     ACPI Binary Table Dump Utility version 20140424-32 [May  7 2014]
>     Copyright (c) 2000 - 2014 Intel Corporation

This seems to be a .config file...
Could you please check and upload a correct dump file?

Thanks in advance.
Comment 7 Zhang Rui 2014-07-08 14:16:48 UTC
right. please just run "acpidump > acpidump.out"
Comment 8 Paul Menzel 2014-07-08 21:26:54 UTC
Created attachment 142531 [details]
sudo acpidump -o 20140708--asrock-e350m1-vendor-bios-p180--superiotool-deV.log

(In reply to Lv Zheng from comment #6)
> (In reply to Paul Menzel from comment #4)
> > Created attachment 142411 [details]
> > `sudo acpidump -o 20140708--acpidump--vendor-bios-p180.txt
> > 
> > (In reply to Zhang Rui from comment #2)
> > > please attach the acpidump of this machine.
> > 
> > I’ll attach the output captured with the version below.
> > 
> >     $ acpidump -v
> > 
> >     Intel ACPI Component Architecture
> >     ACPI Binary Table Dump Utility version 20140424-32 [May  7 2014]
> >     Copyright (c) 2000 - 2014 Intel Corporation
> 
> This seems to be a .config file...
> Could you please check and upload a correct dump file?
> 
> Thanks in advance.

No idea what happened. It looks like clicked on the wrong file in the file upload chooser.
Comment 9 Paul Menzel 2014-07-08 21:28:21 UTC
Created attachment 142541 [details]
`sudo acpidump -o 20140708--acpidump--vendor-bios-p180.txt

(In reply to Paul Menzel from comment #8)
> Created attachment 142531 [details]
> sudo acpidump -o
> 20140708--asrock-e350m1-vendor-bios-p180--superiotool-deV.log
> 
> (In reply to Lv Zheng from comment #6)
> > (In reply to Paul Menzel from comment #4)
> > > Created attachment 142411 [details]
> > > `sudo acpidump -o 20140708--acpidump--vendor-bios-p180.txt
> > > 
> > > (In reply to Zhang Rui from comment #2)
> > > > please attach the acpidump of this machine.
> > > 
> > > I’ll attach the output captured with the version below.
> > > 
> > >     $ acpidump -v
> > > 
> > >     Intel ACPI Component Architecture
> > >     ACPI Binary Table Dump Utility version 20140424-32 [May  7 2014]
> > >     Copyright (c) 2000 - 2014 Intel Corporation
> > 
> > This seems to be a .config file...
> > Could you please check and upload a correct dump file?
> > 
> > Thanks in advance.
> 
> No idea what happened. It looks like clicked on the wrong file in the file
> upload chooser.

Too late here. Sorry for the noise.
Comment 10 Zhang Rui 2014-07-09 02:37:30 UTC
(In reply to Lv Zheng from comment #3)
> This looks like a video issue.
> ACPI video is trying to access a system memory region that is not available.

No, this is an ACPICA issue or BIOS issue.
acpi_video_device_lcd_set_level() will invoke _BCM method. And here is the related AML for _BCL method.

    Scope (_SB.PCI0.SMBS)
    {
        Mutex (PSMX, 0x00)
    }
                OperationRegion (SMIP, SystemIO, SMIO, One)
                Field (SMIP, ByteAcc, NoLock, Preserve)
                {
                    SMIC,   8
                }

                    OperationRegion (ATFB, SystemMemory, 0xFFFFFF00, 0x0105)
                    Field (ATFB, AnyAcc, NoLock, Preserve)
                    {
                        BCMD,   8,
                        DID,    32,
                        INFO,   2048
                    }
                    Field (ATFB, AnyAcc, NoLock, Preserve)
                    {
                        Offset (0x05),
                        INF0,   8,
                        INF1,   8,
                        INF2,   8,
                        INF3,   8,
                        INF4,   8,
                        INF5,   8,
                        INF6,   8,
                        INF7,   8
                    }
                    Method (_BCM, 1, NotSerialized)  // _BCM: Brightness Control Method
                    {
                        Acquire (^^^SMBS.PSMX, 0xFFFF)
                        Store (One, INF0)
                        Store (Arg0, INF1)
                        Store (0x8A, BCMD)
                        Store (ATIS, ^^^SBRG.SMIC)
                        Release (^^^SMBS.PSMX)
                    }

I don't find anything unusual, Lv, can you please check what the problem is.
can we test the AML in acpiexec?
Comment 11 Zhang Rui 2014-07-09 02:37:55 UTC
BTW, Paul, can you please attach the dmesg output after boot?
Comment 12 Paul Menzel 2014-07-09 20:01:19 UTC
Created attachment 142611 [details]
Linux message from ring buffer acquired with `dmesg`

(In reply to Zhang Rui from comment #11)
> BTW, Paul, can you please attach the dmesg output after boot?

Sorry for forgetting that. Please find it attached.

By the way, this is no laptop, so I am unsure what to make of the message below.

    [Firmware Bug]: ACPI: No _BQC method, cannot determine initial brightness
Comment 13 Zhang Rui 2014-07-10 06:59:52 UTC
                    OperationRegion (ATFB, SystemMemory, 0xFFFFFF00, 0x0105)
                    Field (ATFB, AnyAcc, NoLock, Preserve)
                    {
                        BCMD,   8,
                        DID,    32,
                        INFO,   2048
                    }

This looks suspicious, is this memory address 0xFFFFFF00 available?
Comment 14 Paul Menzel 2014-07-11 06:08:29 UTC
(In reply to Zhang Rui from comment #13)
>                     OperationRegion (ATFB, SystemMemory, 0xFFFFFF00, 0x0105)
>                     Field (ATFB, AnyAcc, NoLock, Preserve)
>                     {
>                         BCMD,   8,
>                         DID,    32,
>                         INFO,   2048
>                     }
> 
> This looks suspicious, is this memory address 0xFFFFFF00 available?

How do I check if that is available? The system has two 8 GB RAM modules, so in total 16 GB RAM.
Comment 15 Lv Zheng 2014-09-10 02:15:23 UTC
(In reply to Zhang Rui from comment #10)
> (In reply to Lv Zheng from comment #3)
> I don't find anything unusual, Lv, can you please check what the problem is.
> can we test the AML in acpiexec?

I didn't find anything unusual by back porting Linux code to acpiexec and executing them in this simulation environment. There is no such crash in the simulation environment.

But acpiexec wouldn't do real system memory accessing, and there might be some system memory region field mapped to 0xFFFFFF00.

Do we have ACPI OSL mapping debugging facility for this? If we haven't, I can help to write a procfs entry to debug this issue.
Comment 16 Lv Zheng 2014-09-19 07:36:08 UTC
Created attachment 150891 [details]
[DBG PATCH] ACPI/OSL: Catch memory mappings for acpi_map

Hi,

I was noted that you were using a 32-bit PAE kernel.
Please apply this patch and try again.
Please upload the crash dmesg log and your kernel .config file here.

Thanks in advance
-Lv
Comment 17 Lv Zheng 2014-09-23 02:55:27 UTC
Hi,

Also please provide /proc/iomem output.

Thanks
-Lv
Comment 18 Aaron Lu 2014-10-16 08:15:55 UTC
Hi Lv,
What's the next step once you get the iomem? BTW, it doesn't seem to be related to video driver.

Hi Paul,
Please provide the info.
Comment 19 Lv Zheng 2014-10-17 00:29:56 UTC
Hi,

The attachment 150891 [details] can help to dump the values passed to the acpi_map operations. And /proc/iomem can help to determine which mapping facility (kmap or ioremap) is used in acpi_map.

I have no further idea currently. We may find some clues after seeing the debugging output.

Thanks and best regards
-Lv
Comment 20 Paul Menzel 2014-10-25 09:10:40 UTC
I am sorry for the late reply. Using the 64-bit variant (x86_64) and Linux 3.16.5-1, there is no crash. I’ll attach the Linux kernel messages and acpidump output from that boot.

Unfortunately building a patched Linux kernel is not possible on this system currently. If you could provide an image, that’d be great. Otherwise I try to build a Linux kernel as soon as possible. But that’ll take a while. Sorry for that.
Comment 21 Paul Menzel 2014-10-25 09:19:46 UTC
Created attachment 154891 [details]
`journalctl --dmesg -a` with vendor firmware P1.80 and Linux 3.16.5 x86_64

Linux messages with Linux 3.16.5 x86_64. (No crash.)
Comment 22 Paul Menzel 2014-10-25 09:23:50 UTC
Created attachment 154901 [details]
`sudo acpidump -o 20141025--acpidump--vendor-firmware-p180--Linux-3.16.5-x86_64.txt`

Dump of ACPI tables with Linux 3.16.5 x86_64 on vendor firmware P1.80 (no crash).
Comment 23 Len Brown 2014-10-28 04:24:59 UTC
> By the way, this is no laptop,
> so I am unsure what to make of the message below.
>
>   [Firmware Bug]: ACPI: No _BQC method, cannot determine initial brightness

http://www.asrock.com/mb/amd/e350m1/

"Graphics Output Options: D-Sub, DVI-D and HDMI"

What? why does this BIOS have a _BCM in the first place?  It has no LCD!
Comment 24 Paul Menzel 2014-10-28 07:51:32 UTC
(In reply to Len Brown from comment #23)
> > By the way, this is no laptop,
> > so I am unsure what to make of the message below.
> >
> >   [Firmware Bug]: ACPI: No _BQC method, cannot determine initial brightness
> 
> http://www.asrock.com/mb/amd/e350m1/
> 
> "Graphics Output Options: D-Sub, DVI-D and HDMI"
> 
> What? why does this BIOS have a _BCM in the first place?  It has no LCD!

Sorry, no idea. Maybe that chipset can be used in laptops too and ASRock did not remove that ACPI method? The board is still on sale after five years. Should I contact ASRock about that?
Comment 25 Aaron Lu 2014-10-28 08:44:16 UTC
My desktop ACPI table also has the _BCM and so an acpi_video interface, which is useless of course. I agree with Paul that those ASL code are just same for the chipset, no matter if it is a desktop or a laptop.
We have a bug report for this: https://bugzilla.kernel.org/show_bug.cgi?id=84101, but I have no idea how to fix it.
Comment 26 Lv Zheng 2014-11-03 04:26:46 UTC
(In reply to Paul Menzel from comment #20)
> I am sorry for the late reply. Using the 64-bit variant (x86_64) and Linux
> 3.16.5-1, there is no crash. I’ll attach the Linux kernel messages and
> acpidump output from that boot.
> 
> Unfortunately building a patched Linux kernel is not possible on this system
> currently. If you could provide an image, that’d be great. Otherwise I try
> to build a Linux kernel as soon as possible. But that’ll take a while. Sorry
> for that.

Hi, Paul

I'm going to close it.
If you are able to provide information again, you can re-open it.

Thanks
Comment 27 Paul Menzel 2014-12-31 08:51:59 UTC
Created attachment 162161 [details]
journalctl -k -b

I finally was able to get back to this issue and applied the debugging patch (with the disabled if statement) to Linux 3.16.7.
Comment 28 Paul Menzel 2014-12-31 08:53:03 UTC
Unfortunately Bugzilla does not allow to change the meta information when adding an attachment. Doing so now.
Comment 29 Lv Zheng 2015-01-05 00:27:51 UTC
Hi, Paul

According to the log, acpi_map() is not called for the invalid address.
We have another bug which is very similar to this one.
https://bugzilla.kernel.org/show_bug.cgi?id=87971

Could you take a look and give this fix a try:
attachment 162371 [details]

Thanks
-Lv
Comment 30 Paul Menzel 2015-01-10 20:33:40 UTC
Created attachment 163081 [details]
journalctl -k -b # debug patch and fix applied on top of 3.16.7

(In reply to Lv Zheng from comment #29)

> According to the log, acpi_map() is not called for the invalid address.
> We have another bug which is very similar to this one.
> https://bugzilla.kernel.org/show_bug.cgi?id=87971
> 
> Could you take a look and give this fix a try:
> attachment 162371 [details]

Applying that fix on top of Linux 3.16.7 and your debug patch, it indeed boots correctly now. Thanks!

How to continue? Will you merge the tickets and send a proper patch in for review with `Cc: stable@vger.kernel.org`? At least Linux 3.14 was affected.
Comment 31 Lv Zheng 2015-01-12 04:50:44 UTC
Hi,

(In reply to Paul Menzel from comment #30)
> Created attachment 163081 [details]
> journalctl -k -b # debug patch and fix applied on top of 3.16.7
> 
> (In reply to Lv Zheng from comment #29)
> 
> > According to the log, acpi_map() is not called for the invalid address.
> > We have another bug which is very similar to this one.
> > https://bugzilla.kernel.org/show_bug.cgi?id=87971
> > 
> > Could you take a look and give this fix a try:
> > attachment 162371 [details]
> 
> Applying that fix on top of Linux 3.16.7 and your debug patch, it indeed
> boots correctly now. Thanks!

Masking this as resolved...

> 
> How to continue? Will you merge the tickets and send a proper patch in for
> review with `Cc: stable@vger.kernel.org`? At least Linux 3.14 was affected.

We will send this patch to ACPICA upstream, and when it is merged by the Linux during ACPICA release, it will be marked as stable and detected by the stable maintainers.

This might be be a regression.
A very old big patch "merging all table address/ virtual address/ physical address" is upstreamed several years ago for 2.6 kernels by Alexey which might have made something wrong to cause this regression.

Thanks and best regards
-Lv
Comment 32 Paul Menzel 2015-01-13 22:36:38 UTC
Dear Lv,


(In reply to Lv Zheng from comment #31)

> (In reply to Paul Menzel from comment #30)

[…]

> > How to continue? Will you merge the tickets and send a proper patch in for
> > review with `Cc: stable@vger.kernel.org`? At least Linux 3.14 was affected.
> 
> We will send this patch to ACPICA upstream, and when it is merged by the
> Linux during ACPICA release, it will be marked as stable and detected by the
> stable maintainers.

Please put me in Cc and add my `Tested-by` line.

> This might be a regression.
> A very old big patch "merging all table address/ virtual address/ physical
> address" is upstreamed several years ago for 2.6 kernels by Alexey which
> might have made something wrong to cause this regression.

I’ll try Linux 3.2 later this week.


Thanks,

Paul
Comment 33 Lv Zheng 2015-01-14 02:26:27 UTC
Hi, Paul

(In reply to Paul Menzel from comment #32)
> > > How to continue? Will you merge the tickets and send a proper patch in
> for
> > > review with `Cc: stable@vger.kernel.org`? At least Linux 3.14 was
> affected.
> > 
> > We will send this patch to ACPICA upstream, and when it is merged by the
> > Linux during ACPICA release, it will be marked as stable and detected by
> the
> > stable maintainers.
> 
> Please put me in Cc and add my `Tested-by` line.

I generated the final version here:
attachment 163281 [details]
Your name is already in the patch. :)
Could you help to confirm if it is working?

Thanks
-Lv
Comment 34 Paul Menzel 2015-01-15 23:28:17 UTC
Dear Lv,


(In reply to Lv Zheng from comment #33)

> (In reply to Paul Menzel from comment #32)
> > > > How to continue? Will you merge the tickets and send a proper patch in
> for
> > > > review with `Cc: stable@vger.kernel.org`? At least Linux 3.14 was
> affected.
> > > 
> > > We will send this patch to ACPICA upstream, and when it is merged by the
> > > Linux during ACPICA release, it will be marked as stable and detected by
> the
> > > stable maintainers.
> > 
> > Please put me in Cc and add my `Tested-by` line.
> 
> I generated the final version here:
> attachment 163281 [details]
> Your name is already in the patch. :)
> Could you help to confirm if it is working?

I’ll test the patch again over the weekend!

By the way, why don’t you mark this ticket as a duplicate of bug #87971?
Comment 35 Lv Zheng 2015-01-16 00:07:09 UTC
Marking this as duplicate.

Thanks
-Lv

*** This bug has been marked as a duplicate of bug 87971 ***
Comment 36 Lv Zheng 2015-05-18 02:15:46 UTC
Patch upstreamed:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2b87601

Closing...

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