[PATCH] powerpc/eeh: Quieten EEH message when no adapters are found
From: Anton Blanchard
No real need for this to be pr_warn(), reduce it to pr_info().
Signed-off-by: Anton Blanchard
---
arch/powerpc/kernel/eeh.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index c9bc78e..3f0ca80 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -1044,7 +1044,7 @@ int eeh_init(void)
if (eeh_enabled())
pr_info("EEH: PCI Enhanced I/O Error Handling Enabled\n");
else
- pr_warn("EEH: No capable adapters found\n");
+ pr_info("EEH: No capable adapters found\n");
return ret;
}
--
2.7.4
UBSAN: Undefined behaviour in /home/mathieu/tmp/linux-4.6.4/drivers/scsi/scsi_devinfo.c:458:21
Hi, Anyone seen this before (PowerMac G4/MacMini): [1.397164] ata1.00: ATA-8: WDC WD800BEVE-00A0HT0, 11.01A11, max UDMA/100 [1.401313] ata1.00: 156301488 sectors, multi 16: LBA48 [1.405525] ata1.01: ATAPI: MATSHITADVD-R UJ-845C, DPP9, max UDMA/66 [1.414606] ata1.00: configured for UDMA/100 [1.423655] ata1.01: configured for UDMA/66 [1.431116] scsi 0:0:0:0: Direct-Access ATA WDC WD800BEVE-00 1A11 PQ: 0 ANSI: 5 [1.435987] device: 'target0:0:0': device_add [1.436030] bus: 'scsi': add device target0:0:0 [1.436133] PM: Adding info for scsi:target0:0:0 [1.436184] device: '0:0:0:0': device_add [1.436410] bus: 'scsi': add device 0:0:0:0 [1.436501] PM: Adding info for scsi:0:0:0:0 [1.436526] device: '0:0:0:0': device_add [1.436654] PM: Adding info for No Bus:0:0:0:0 [1.436695] device: '0:0:0:0': device_add [1.436819] PM: Adding info for No Bus:0:0:0:0 [1.438276] [1.443124] UBSAN: Undefined behaviour in /home/mathieu/tmp/linux-4.6.4/drivers/scsi/scsi_devinfo.c:458:21 [1.453129] index 8 is out of range for type 'char [8]' [1.458352] CPU: 0 PID: 6 Comm: kworker/u2:0 Not tainted 4.6.0-1-powerpc #5 [1.463771] Workqueue: events_unbound async_run_entry_fn [1.469284] Call Trace: [1.474816] [df54bb80] [c071a9f4] ubsan_epilogue+0x18/0x4c (unreliable) [1.480614] [df54bb90] [c071b114] __ubsan_handle_out_of_bounds+0x7c/0x90 [1.486313] [df54bbd0] [c09fe084] scsi_dev_info_list_find+0x2e0/0x3a4 [1.491880] [df54bc20] [c09fe6a0] scsi_get_device_flags_keyed+0x40/0x11c [1.497397] [df54bc40] [c09f4ec8] scsi_probe_and_add_lun+0x458/0x1ce4 [1.502836] [df54bd00] [c09f6b04] __scsi_add_device+0x170/0x1cc [1.508207] [df54bd40] [c0a30064] ata_scsi_scan_host+0x214/0x3f8 [1.513578] [df54bda0] [c00d78b4] async_run_entry_fn+0x90/0x3c4 [1.518944] [df54be00] [c00c20a0] process_one_work+0x2dc/0xd44 [1.524270] [df54be70] [c00c2dc0] worker_thread+0x2b8/0xbf4 [1.529596] [df54bee0] [c00d1618] kthread+0x124/0x1b0 [1.534914] [df54bf40] [c00244b0] ret_from_kernel_thread+0x5c/0x64 [1.540229] [1.546530] scsi 0:0:1:0: CD-ROMMATSHITA DVD-R UJ-845C DPP9 PQ: 0 ANSI: 5 [1.559176] device: 'target0:0:1': device_add [1.559217] bus: 'scsi': add device target0:0:1 [1.559307] PM: Adding info for scsi:target0:0:1 [1.559356] device: '0:0:1:0': device_add [1.559566] bus: 'scsi': add device 0:0:1:0
Fwd: Rational for having CONFIG_FB_RADEON=m
Hi Ben,
On Tue, Jun 14, 2016 at 1:15 PM, Benjamin Herrenschmidt
wrote:
> On Tue, 2016-06-14 at 13:26 +1000, Michael Ellerman wrote:
>> On Mon, 2016-06-13 at 17:46 +0200, Mathieu Malaterre wrote:
>>
>> > 2. Try to fix `radeonfb` so that it is able to kick offb out of the
>> > way. Eg: https://lists.freedesktop.org/archives/dri-devel/2010-Augu
>> > st/002907.html
>> >
>> > From my understanding it would make sense to go for (2), since it
>> > would allow for proper support for CONFIG_FB_RADEON=m on PowerMac.
>> > In
>> > this case, would such patch be accepted ?
>>
>> Sounds like the right fix to me. Ben's patch above was merged, so
>> it's supposed
>> to kick out offb AFAICS, the fact that it can't seems like a
>
> Make sure you have CONFIG_VT_HW_CONSOLE_BINDING=y
Thanks I do have it.
What I was trying to say in my broken fr-english is that I would like
to patch `drivers/video/fbdev/aty/radeon_base.c` the same way you did
`drivers/gpu/drm/radeon/radeon_drv.c` a long time ago.
So that there is no possible confusion, I am attaching my WIP. I know
you must be very busy, but I would really appreciate if you could
review this patch and give me some clue(s) as to why
`pci_request_region` still fails even if the call to
`radeon_kick_out_firmware_fb` succeeds in kicking out `offb` (I am
left with an empty /proc/fb).
In this case dmesg properly reveals that OFfb was kicked out but still
the `radeonfb` could not succeed:
[...]
bus: 'pci': add driver radeonfb
bus: 'pci': driver_probe_device: matched device :00:10.0 with
driver radeonfb
bus: 'pci': really_probe: probing driver radeonfb with device :00:10.0
devices_kset: Moving :00:10.0 to end of list
radeonfb_pci_register BEGIN
checking generic (9c008000 96000) vs hw (9800 800)
fb: switching to radeonfb from OFfb ATY,RockHo
Console: switching to colour dummy device 80x25
device: 'fb0': device_unregister
PM: Removing info for No Bus:fb0
device: 'fb0': device_create_release
radeonfb :00:10.0: enabling device (0006 -> 0007)
device: 'vtcon1': device_unregister
PM: Removing info for No Bus:vtcon1
device: 'vtcon1': device_create_release
radeonfb :00:10.0: BAR 0: can't reserve [mem 0x9800-0x9fff pref]
radeonfb (:00:10.0): cannot request region 0.
radeonfb: probe of :00:10.0 failed with error -16
[...]
The only way I found to load `radeonfb` is to use offb:off in yaboot.
Regards and thanks for your time,
diff --git a/drivers/video/fbdev/aty/radeon_base.c b/drivers/video/fbdev/aty/radeon_base.c
index 218339a..1a91feb 100644
--- a/drivers/video/fbdev/aty/radeon_base.c
+++ b/drivers/video/fbdev/aty/radeon_base.c
@@ -2259,6 +2259,22 @@ static struct bin_attribute edid2_attr = {
.read = radeon_show_edid2,
};
+static int radeon_kick_out_firmware_fb(struct pci_dev *pdev)
+{
+ struct apertures_struct *ap;
+
+ ap = alloc_apertures(1);
+ if (!ap)
+ return -ENOMEM;
+
+ ap->ranges[0].base = pci_resource_start(pdev, 0);
+ ap->ranges[0].size = pci_resource_len(pdev, 0);
+
+ remove_conflicting_framebuffers(ap, KBUILD_MODNAME, false);
+ kfree(ap);
+
+ return 0;
+}
static int radeonfb_pci_register(struct pci_dev *pdev,
const struct pci_device_id *ent)
@@ -2314,6 +2330,10 @@ static int radeonfb_pci_register(struct pci_dev *pdev,
rinfo->fb_base_phys = pci_resource_start (pdev, 0);
rinfo->mmio_base_phys = pci_resource_start (pdev, 2);
+ ret = radeon_kick_out_firmware_fb(pdev);
+ if (ret)
+ return ret;
+
/* request the mem regions */
ret = pci_request_region(pdev, 0, "radeonfb framebuffer");
if (ret < 0) {
[PATCH] powerpc/pseries: Use H_CLEAR_HPT to clear MMU hash table during kexec
From: Anton Blanchard
An hcall was recently added that does exactly what we need
during kexec - it clears the entire MMU hash table, ignoring any
VRMA mappings.
Try it and fall back to the old method if we get a failure.
On a POWER8 box with 5TB of memory, this reduces the time it takes to
kexec a new kernel from from 4 minutes to 1 minute.
Signed-off-by: Anton Blanchard
---
arch/powerpc/include/asm/hvcall.h | 3 ++-
arch/powerpc/platforms/pseries/lpar.c | 14 +-
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/hvcall.h
b/arch/powerpc/include/asm/hvcall.h
index 708edeb..489748e 100644
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
@@ -275,7 +275,8 @@
#define H_COP 0x304
#define H_GET_MPP_X0x314
#define H_SET_MODE 0x31C
-#define MAX_HCALL_OPCODE H_SET_MODE
+#define H_CLEAR_HPT0x358
+#define MAX_HCALL_OPCODE H_CLEAR_HPT
/* H_VIOCTL functions */
#define H_GET_VIOA_DUMP_SIZE 0x01
diff --git a/arch/powerpc/platforms/pseries/lpar.c
b/arch/powerpc/platforms/pseries/lpar.c
index 86707e6..03884a8 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -221,7 +221,7 @@ static long pSeries_lpar_hpte_remove(unsigned long
hpte_group)
return -1;
}
-static void pSeries_lpar_hptab_clear(void)
+static void __pSeries_lpar_clear_hpt(void)
{
unsigned long size_bytes = 1UL << ppc64_pft_size;
unsigned long hpte_count = size_bytes >> 4;
@@ -249,6 +249,18 @@ static void pSeries_lpar_hptab_clear(void)
&(ptes[j].pteh), &(ptes[j].ptel));
}
}
+}
+
+static void pSeries_lpar_hptab_clear(void)
+{
+ int rc;
+
+ do {
+ rc = plpar_hcall_norets(H_CLEAR_HPT);
+ } while (rc == H_CONTINUE);
+
+ if (rc != H_SUCCESS)
+ __pSeries_lpar_clear_hpt();
#ifdef __LITTLE_ENDIAN__
/*
--
2.7.4
