Re: [PATCH 16/22] dvb-usb: Replace comments with C99 initializers

[Larry Finger]

On 3/26/22 14:51, Joe Perches wrote:

On Sat, 2022-03-26 at 19:27 +0100, Mauro Carvalho Chehab wrote:

Em Sat, 26 Mar 2022 19:24:54 +0100
Mauro Carvalho Chehab  escreveu:


Em Sat, 26 Mar 2022 17:59:03 +0100
Benjamin Stürz  escreveu:


This replaces comments with C99's designated
initializers because the kernel supports them now.

Signed-off-by: Benjamin Stürz 
---
  drivers/media/usb/dvb-usb/dibusb-mb.c | 62 +--
  drivers/media/usb/dvb-usb/dibusb-mc.c | 34 +++
  2 files changed, 48 insertions(+), 48 deletions(-)

diff --git a/drivers/media/usb/dvb-usb/dibusb-mb.c 
b/drivers/media/usb/dvb-usb/dibusb-mb.c
index e9dc27f73970..f188e07f518b 100644
--- a/drivers/media/usb/dvb-usb/dibusb-mb.c
+++ b/drivers/media/usb/dvb-usb/dibusb-mb.c
@@ -122,40 +122,40 @@ static int dibusb_probe(struct usb_interface *intf,
  
  /* do not change the order of the ID table */

  static struct usb_device_id dibusb_dib3000mb_table [] = {
-/* 00 */   { USB_DEVICE(USB_VID_WIDEVIEW,  
USB_PID_AVERMEDIA_DVBT_USB_COLD) },
-/* 01 */   { USB_DEVICE(USB_VID_WIDEVIEW,  
USB_PID_AVERMEDIA_DVBT_USB_WARM) },
-/* 02 */   { USB_DEVICE(USB_VID_COMPRO,
USB_PID_COMPRO_DVBU2000_COLD) },
-/* 03 */   { USB_DEVICE(USB_VID_COMPRO,
USB_PID_COMPRO_DVBU2000_WARM) },
-/* 04 */   { USB_DEVICE(USB_VID_COMPRO_UNK,
USB_PID_COMPRO_DVBU2000_UNK_COLD) },
-/* 05 */   { USB_DEVICE(USB_VID_DIBCOM,
USB_PID_DIBCOM_MOD3000_COLD) },
-/* 06 */   { USB_DEVICE(USB_VID_DIBCOM,
USB_PID_DIBCOM_MOD3000_WARM) },
-/* 07 */   { USB_DEVICE(USB_VID_EMPIA, 
USB_PID_KWORLD_VSTREAM_COLD) },
-/* 08 */   { USB_DEVICE(USB_VID_EMPIA, 
USB_PID_KWORLD_VSTREAM_WARM) },
-/* 09 */   { USB_DEVICE(USB_VID_GRANDTEC,  
USB_PID_GRANDTEC_DVBT_USB_COLD) },
-/* 10 */   { USB_DEVICE(USB_VID_GRANDTEC,  
USB_PID_GRANDTEC_DVBT_USB_WARM) },
-/* 11 */   { USB_DEVICE(USB_VID_GRANDTEC,  
USB_PID_DIBCOM_MOD3000_COLD) },
-/* 12 */   { USB_DEVICE(USB_VID_GRANDTEC,  
USB_PID_DIBCOM_MOD3000_WARM) },
-/* 13 */   { USB_DEVICE(USB_VID_HYPER_PALTEK,  
USB_PID_UNK_HYPER_PALTEK_COLD) },
-/* 14 */   { USB_DEVICE(USB_VID_HYPER_PALTEK,  
USB_PID_UNK_HYPER_PALTEK_WARM) },
-/* 15 */   { USB_DEVICE(USB_VID_VISIONPLUS,
USB_PID_TWINHAN_VP7041_COLD) },
-/* 16 */   { USB_DEVICE(USB_VID_VISIONPLUS,
USB_PID_TWINHAN_VP7041_WARM) },
-/* 17 */   { USB_DEVICE(USB_VID_TWINHAN,   
USB_PID_TWINHAN_VP7041_COLD) },
-/* 18 */   { USB_DEVICE(USB_VID_TWINHAN,   
USB_PID_TWINHAN_VP7041_WARM) },
-/* 19 */   { USB_DEVICE(USB_VID_ULTIMA_ELECTRONIC, 
USB_PID_ULTIMA_TVBOX_COLD) },
-/* 20 */   { USB_DEVICE(USB_VID_ULTIMA_ELECTRONIC, 
USB_PID_ULTIMA_TVBOX_WARM) },
-/* 21 */   { USB_DEVICE(USB_VID_ULTIMA_ELECTRONIC, 
USB_PID_ULTIMA_TVBOX_AN2235_COLD) },
-/* 22 */   { USB_DEVICE(USB_VID_ULTIMA_ELECTRONIC, 
USB_PID_ULTIMA_TVBOX_AN2235_WARM) },
-/* 23 */   { USB_DEVICE(USB_VID_ADSTECH,   
USB_PID_ADSTECH_USB2_COLD) },
+[0]  = { USB_DEVICE(USB_VID_WIDEVIEW,  
USB_PID_AVERMEDIA_DVBT_USB_COLD) },
+[1]  = { USB_DEVICE(USB_VID_WIDEVIEW,  
USB_PID_AVERMEDIA_DVBT_USB_WARM) },


While here, please properly indent this table, and respect the 80-columns limit,
e. g.:

static struct usb_device_id dibusb_dib3000mb_table [] = {
[0] = { USB_DEVICE(USB_VID_WIDEVIEW
   USB_PID_AVERMEDIA_DVBT_USB_COLD)
},
[1]  =  { USB_DEVICE(USB_VID_WIDEVIEW,
 USB_PID_AVERMEDIA_DVBT_USB_WARM)
},
...


Err something went wrong with my space bar and I ended hitting send to
soon... I meant:

static struct usb_device_id dibusb_dib3000mb_table [] = {
[0] = { USB_DEVICE(USB_VID_WIDEVIEW
   USB_PID_AVERMEDIA_DVBT_USB_COLD)
},
[1] = { USB_DEVICE(USB_VID_WIDEVIEW,
   USB_PID_AVERMEDIA_DVBT_USB_WARM)
},
...
};


maybe static const too

and

maybe

#define DIB_DEVICE(vid, pid)\
{ USB_DEVICE(USB_VID_ ## vid, USB_PID_ ## pid) }

so maybe

static const struct usb_device_id dibusb_dib3000mb_table[] = {
[0] = DIB_DEVICE(WIDEVIEW, AVERMEDIA_DVBT_USB_COLD),
[1] = DIB_DEVICE(WIDEVIEW, AVERMEDIA_DVBT_USB_WARM),
...
};

though I _really_ doubt the value of the specific indexing.

I think this isn't really worth changing at all.


I agree. For the drivers that I maintain, I try to keep the vendor and device 
ids in numerical order. As this table does not require a special order, adding a 
new one in the middle would require redoing all of then after that point. That 
would be pointless work!


Larry

Re: [PATCH 21/22] rtw89: Replace comments with C99 initializers

[Larry Finger]

On 3/26/22 11:59, Benjamin Stürz wrote:

This replaces comments with C99's designated
initializers because the kernel supports them now.

Signed-off-by: Benjamin Stürz 
---
  drivers/net/wireless/realtek/rtw89/coex.c | 40 +++
  1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtw89/coex.c 
b/drivers/net/wireless/realtek/rtw89/coex.c
index 684583955511..3c83a0bfb120 100644
--- a/drivers/net/wireless/realtek/rtw89/coex.c
+++ b/drivers/net/wireless/realtek/rtw89/coex.c
@@ -97,26 +97,26 @@ static const struct rtw89_btc_fbtc_slot s_def[] = {
  };
  
  static const u32 cxtbl[] = {

-   0x, /* 0 */
-   0x, /* 1 */
-   0x, /* 2 */
-   0x6655, /* 3 */
-   0x66556655, /* 4 */
-   0x5a5a5a5a, /* 5 */
-   0x5a5a5aaa, /* 6 */
-   0xaa5a5a5a, /* 7 */
-   0x6a5a5a5a, /* 8 */
-   0x6a5a5aaa, /* 9 */
-   0x6a5a6a5a, /* 10 */
-   0x6a5a6aaa, /* 11 */
-   0x6afa5afa, /* 12 */
-   0x5aaa, /* 13 */
-   0xaaaa, /* 14 */
-   0xaaaa, /* 15 */
-   0xfafafafa, /* 16 */
-   0xddff, /* 17 */
-   0xdaffdaff, /* 18 */
-   0xfafadafa  /* 19 */
+   [0]  = 0x,
+   [1]  = 0x,
+   [2]  = 0x,
+   [3]  = 0x6655,
+   [4]  = 0x66556655,
+   [5]  = 0x5a5a5a5a,
+   [6]  = 0x5a5a5aaa,
+   [7]  = 0xaa5a5a5a,
+   [8]  = 0x6a5a5a5a,
+   [9]  = 0x6a5a5aaa,
+   [10] = 0x6a5a6a5a,
+   [11] = 0x6a5a6aaa,
+   [12] = 0x6afa5afa,
+   [13] = 0x5aaa,
+   [14] = 0xaaaa,
+   [15] = 0xaaaa,
+   [16] = 0xfafafafa,
+   [17] = 0xddff,
+   [18] = 0xdaffdaff,
+   [19] = 0xfafadafa
  };
  
  struct rtw89_btc_btf_tlv {



Is this change really necessary? Yes, the entries must be ordered; however, the 
comment carries that information at very few extra characters. To me, this patch 
looks like unneeded source churn. One other concern is that this driver is 
backported to older kernels and older compilers by several distros. Will this 
change require adding extra conditional statements to the source used in these 
applications?


Larry

Regression for 32-bit ppc on PowerBook G4 Aluminum (bisected to commit d0e3fc69d00d)

[Larry Finger]

I tested 5.11.0-rc1 and it booted OK. My problem is fixed.

Thanks,

Larry

Regression for 32-bit ppc on PowerBook G4 Aluminum (bisected to commit d0e3fc69d00d)

[Larry Finger]

Beginning with commit d0e3fc69d00d ("powerpc/vdso: Provide 
__kernel_clock_gettime64() on vdso32"), my PowerBook G4 Aluminum fails to boot. 
It stops pretty early in the boot.


I will be happy to test any patches, or provide any additional information.

Larry

Re: Kernel bug in 5.7 for PPC32 on PowerBook G4 - bisected to commit 697ece7

[Larry Finger]

On 5/23/20 12:30 PM, Christophe Leroy wrote:

Hi Larry,

Le 23/05/2020 à 19:24, Larry Finger a écrit :

Hi Christophe,

Although kernel 5.7.0-rc2 appeared to boot cleanly, it failed on my G4 when I 
tried to generate a new kernel. The following BUG message is logged:




[...]



This problem was bisected to commit 697ece7 ("powerpc/32s: reorder Linux PTE 
bits to better match Hash PTE bits").


Being reversed in new -rc , see 
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/87sgfsf4hs@mpe.ellerman.id.au/ 


Christophe,

Thanks for the update.

Larry

Kernel bug in 5.7 for PPC32 on PowerBook G4 - bisected to commit 697ece7

[Larry Finger]

Hi Christophe,

Although kernel 5.7.0-rc2 appeared to boot cleanly, it failed on my G4 when I 
tried to generate a new kernel. The following BUG message is logged:


[  336.148935] [ cut here ]
[  336.148950] kernel BUG at ./include/linux/swapops.h:195!
[  336.148971] Oops: Exception in kernel mode, sig: 5 [#1]
[  336.148975] BE PAGE_SIZE=4K MMU=Hash PowerMac
[  336.148978] Modules linked in: cpufreq_ondemand fuse ctr ccm b43 mac80211 
sha256_generic libsha256 cfg80211 hid_apple hid_generic joydev rfkill libarc4 
rng_core cordic uinput radeon evdev
ttm drm_kms_helper usbhid hid appletouch drm rack_meter ehci_pci ehci_hcd 
drm_panel_orientation_quirks ssb fb_sys_fops yenta_socket sysimgblt sysfillrect 
pcmcia_rsrc syscopyarea pcmcia pcmcia
_core i2c_powermac therm_adt746x loop ohci_pci ohci_hcd usbcore sungem 
sungem_phy usb_common

[  336.149052] CPU: 0 PID: 8346 Comm: ld Not tainted 5.6.0-rc2-00086-g36b7840 
#249
[  336.149056] NIP:  c0166624 LR: c016661c CTR: 
[  336.149062] REGS: f42ddb08 TRAP: 0700   Not tainted  
(5.6.0-rc2-00086-g36b7840)
[  336.149064] MSR:  00029032   CR: 24000424  XER: 
[  336.149072]
[  336.149072] GPR00:  f42ddbc0 c24fcb80 0001 ef438f00 c1957b1c 
f42ddc4c 0004
[  336.149072] GPR08: 0050 0100  edb9d000  100cba68 
10051b10 10051b08
[  336.149072] GPR16: 01be ee68c078 105a   c1957b1c 
 
[  336.149072] GPR24: ec5d2540  7c002bf8 c1957ae0  ec5d2540 
ef438f00 ef438f00

[  336.149107] NIP [c0166624] _einittext+0x3f9d38a8/0x3fe4a284
[  336.149111] LR [c016661c] _einittext+0x3f9d38a0/0x3fe4a284
[  336.149114] Call Trace:
[  336.149118] [f42ddbc0] [c07b9b60] 0xc07b9b60 (unreliable)
[  336.149123] [f42ddbd0] [c013ff64] _einittext+0x3f9ad1e8/0x3fe4a284
[  336.149128] [f42ddc10] [c0140d4c] _einittext+0x3f9adfd0/0x3fe4a284
[  336.149133] [f42ddc90] [c002aadc] _einittext+0x3f897d60/0x3fe4a284
[  336.149137] [f42ddce0] [c00153a4] _einittext+0x3f882628/0x3fe4a284
[  336.149144] --- interrupt: 301 at _einittext+0x3fb52a50/0x3fe4a284
[  336.149144] LR = _einittext+0x3fb52a4c/0x3fe4a284
[  336.149148] [f42ddda8] [c02e56c0] _einittext+0x3fb52944/0x3fe4a284 
(unreliable)
[  336.149153] [f42ddde8] [c011644c] _einittext+0x3f9836d0/0x3fe4a284
[  336.149158] [f42dde38] [c01f5950] _einittext+0x3fa62bd4/0x3fe4a284
[  336.149163] [f42dde58] [c016b98c] _einittext+0x3f9d8c10/0x3fe4a284
[  336.149167] [f42ddec8] [c016ba60] _einittext+0x3f9d8ce4/0x3fe4a284
[  336.149172] [f42ddef8] [c016bd00] _einittext+0x3f9d8f84/0x3fe4a284
[  336.149177] [f42ddf38] [c0015174] _einittext+0x3f8823f8/0x3fe4a284
[  336.149182] --- interrupt: c01 at 0xfdf99fc
[  336.149182] LR = 0xfd9cce0
[  336.149184] Instruction dump:
[  336.149189] 40be0018 4bffe359 3c80c06a 3884e48f 4bfd4c9d 0fe0 4bffe345 
7c641b78
[  336.149196] 3860 4bffe045 7c630034 5463d97e <0f03> 3940 393f001c 
3961

[  336.149208] ---[ end trace d08833cae9c66ce3 ]---
[  336.149210]
[  336.193729] [ cut here ]

This problem was bisected to commit 697ece7 ("powerpc/32s: reorder Linux PTE 
bits to better match Hash PTE bits").


If I had done more rigorous tests earlier, I would have found the bug with more 
time to fix it before release of 5.7, but every other problem I have found 
happened at boot, not when the machine had to swap.


Thanks,

Larry

Re: RESEND: Re: Problem booting a PowerBook G4 Aluminum after commit cd08f109 with CONFIG_VMAP_STACK=y

[Larry Finger]

Christophe,

On 2/14/20 1:35 PM, Christophe Leroy wrote:

--- a/arch/powerpc/kernel/head_32.S
+++ b/arch/powerpc/kernel/head_32.S
@@ -270,6 +270,9 @@ __secondary_hold_acknowledge:
   * pointer when we take an exception from supervisor mode.)
   *    -- paulus.
   */
+#ifdef CONFIG_PPC_CHRP
+1:    b    machine_check_in_rtas
+#endif
  . = 0x200
  DO_KVM  0x200
  MachineCheck:
@@ -290,12 +293,9 @@ MachineCheck:
  7:    EXCEPTION_PROLOG_2
  addi    r3,r1,STACK_FRAME_OVERHEAD
  #ifdef CONFIG_PPC_CHRP
-    bne    cr1,1f
+    bne    cr1,1b
  #endif
  EXC_XFER_STD(0x200, machine_check_exception)
-#ifdef CONFIG_PPC_CHRP
-1:    b    machine_check_in_rtas
-#endif

  /* Data access exception. */
  . = 0x300


With the above changes and all the other patches applied, the machine finally 
boots. It is so bloody slow that it takes a long time to do anything, but you 
finally got all the places that needed patches. I really lost track of how many 
bugs were fixed in the process, but I can now put that old box aside until time 
for v5.7.0-rc1. As you can tell, it only gets used to verify that PPC32 is 
working on real G4 hardware. It has no real value for any other function.


Thanks for the help,

Larry

Re: RESEND: Re: Problem booting a PowerBook G4 Aluminum after commit cd08f109 with CONFIG_VMAP_STACK=y

[Larry Finger]

On 2/14/20 12:24 AM, Christophe Leroy wrote:


Did you try with the patch at https://patchwork.ozlabs.org/patch/1237387/ ?


Christophe,

When I apply that patch, there is an error at

--- a/arch/powerpc/kernel/head_32.S
+++ b/arch/powerpc/kernel/head_32.S
@@ -301,6 +301,39 @@  MachineCheck:
. = 0x300
DO_KVM  0x300
 DataAccess:

It complains about "an attempt to move .org backwards".

When I change the 0x300 to 0x310 in two places, it builds OK. Is that OK?

Larry

Re: RESEND: Re: Problem booting a PowerBook G4 Aluminum after commit cd08f109 with CONFIG_VMAP_STACK=y

[Larry Finger]

On 2/14/20 12:24 AM, Christophe Leroy wrote:


Did you try with the patch at https://patchwork.ozlabs.org/patch/1237387/ ?


Christophe,

When I apply that patch, there is an error at

--- a/arch/powerpc/kernel/head_32.S
+++ b/arch/powerpc/kernel/head_32.S
@@ -301,6 +301,39 @@  MachineCheck:
. = 0x300
DO_KVM  0x300
 DataAccess:

It complains about "an attempt to move .org backwards".

Larry

Re: Problem booting a PowerBook G4 Aluminum after commit cd08f109 with CONFIG_VMAP_STACK=y

[Larry Finger]

On 2/11/20 12:55 AM, Christophe Leroy wrote:



Le 10/02/2020 à 13:55, Larry Finger a écrit :

On 2/9/20 12:19 PM, Christophe Leroy wrote:

Do you have CONFIG_TRACE_IRQFLAGS in your config ?
If so, can you try the patch below ?

https://patchwork.ozlabs.org/patch/1235081/

Otherwise, can you send me your .config and tell me exactly where it stops 
during the boot.


Christophe,

That patch did not work. My .config is attached.

It does boot if CONFIG_VMAP_STACK is not set.

The console display ends with the "DMA ranges" output. A screen shot is also 
appended.


Larry



Hi,

I tried your config under QEMU, it works.

In fact your console display is looping on itself, it ends at "printk: 
bootconsole [udbg0] disabled".


Looks like you get stuck at the time of switching to graphic mode. Need to 
understand why.


I'm not surprised that a real G4 differs from QEMU. For one thing, the real 
hardware uses i2c to connect to the graphics hardware.


I realized that the screen was not scrolling and output was missing. To see what 
was missed, I added a call to btext_clearscreen(). As you noted, it ends at the 
bootconsole disabled statement.


As I could not find any console output after that point, I then turned off the 
bootconsole disable. I realize this action may cause a different problem, but in 
this configuration, the computer hit a BUG Unable to handle kernel data access 
at 0x007a84fc. The faulting instruction address was 0x00013674. Those addresses 
look like physical, not virtual, addresses.


I then added pr_info statements to bracket the failure. In file 
drivers/video/fbdev/core/fb_ddc.c, the code reaches line 66, which is

algo_data->setsda(algo_data->data, 1);
Both pointers seem OK with algo_data = 0xeedfb4bc, and algo_data->data = 
0xeedb25c. The code faults before returning. I then annotated that callback 
routine radeon_gpio_setsda(), and found that execution is OK to the end of the 
routine, but the fault happens on the return from this routine as though the 
stack were corrupted.


I will be busy for about 8 hours, but if you can think of any debugging I can do 
on this routine, please let me know.


Thanks,

Larry

Re: [PATCH] powerpc: enable a 30-bit ZONE_DMA for 32-bit pmac

[Larry Finger]

On 6/14/19 2:15 PM, Aaro Koskinen wrote:

Hi,

On Fri, Jun 14, 2019 at 09:24:16AM +0200, Mathieu Malaterre wrote:

On Thu, Jun 13, 2019 at 10:27 AM Christoph Hellwig  wrote:

With the strict dma mask checking introduced with the switch to
the generic DMA direct code common wifi chips on 32-bit powerbooks
stopped working.  Add a 30-bit ZONE_DMA to the 32-bit pmac builds
to allow them to reliably allocate dma coherent memory.

Fixes: 65a21b71f948 ("powerpc/dma: remove dma_nommu_dma_supported")
Reported-by: Aaro Koskinen 
Signed-off-by: Christoph Hellwig 
---
  arch/powerpc/include/asm/page.h | 7 +++
  arch/powerpc/mm/mem.c   | 3 ++-
  arch/powerpc/platforms/powermac/Kconfig | 1 +
  3 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index b8286a2013b4..0d52f57fca04 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -319,6 +319,13 @@ struct vm_area_struct;
  #endif /* __ASSEMBLY__ */
  #include 

+/*
+ * Allow 30-bit DMA for very limited Broadcom wifi chips on many powerbooks.


nit: would it be possible to mention explicit reference to b43-legacy.
Using b43 on my macmini g4 never showed those symptoms (using
5.2.0-rc2+)


According to Wikipedia Mac mini G4 is limited to 1 GB RAM, so that's
why you don't see the issue.


He wouldn't see it with b43. Those cards have 32-bit DMA.

Larry

Re: [PATCH] powerpc: enable a 30-bit ZONE_DMA for 32-bit pmac

[Larry Finger]

On 6/13/19 3:24 AM, Christoph Hellwig wrote:

With the strict dma mask checking introduced with the switch to
the generic DMA direct code common wifi chips on 32-bit powerbooks
stopped working.  Add a 30-bit ZONE_DMA to the 32-bit pmac builds
to allow them to reliably allocate dma coherent memory.

Fixes: 65a21b71f948 ("powerpc/dma: remove dma_nommu_dma_supported")
Reported-by: Aaro Koskinen 
Signed-off-by: Christoph Hellwig 


As expected, it works. The patch needs
Cc: Stable  # v5.1+

Tested-by: Larry Finger 
Acked-by: Larry Finger 

Thanks for the help, and the patience with my debugging problems with u64 
variables.

Larry

Re: [BISECTED REGRESSION] b43legacy broken on G4 PowerBook

[Larry Finger]

On 6/12/19 1:55 AM, Christoph Hellwig wrote:


Ooops, yes.  But I think we could just enable ZONE_DMA on 32-bit
powerpc.  Crude enablement hack below:

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 8c1c636308c8..1dd71a98b70c 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -372,7 +372,7 @@ config PPC_ADV_DEBUG_DAC_RANGE
  
  config ZONE_DMA

bool
-   default y if PPC_BOOK3E_64
+   default y
  
  config PGTABLE_LEVELS

int



With the patch for Kconfig above, and the original patch setting 
ARCH_ZONE_DMA_BITS to 30, everything works.


Do you have any ideas on what should trigger the change in ARCH_ZONE_BITS? 
Should it be CONFIG_PPC32 defined, or perhaps CONFIG_G4_CPU defined?


Larry

Re: [BISECTED REGRESSION] b43legacy broken on G4 PowerBook

[Larry Finger]

On 6/11/19 5:46 PM, Aaro Koskinen wrote:

Hi,

On Tue, Jun 11, 2019 at 05:20:12PM -0500, Larry Finger wrote:

It is obvious that the case of a mask smaller than min_mask should be
handled by the IOMMU. In my system, CONFIG_IOMMU_SUPPORT is selected. All
other CONFIG variables containing IOMMU are not selected. When
dma_direct_supported() fails, should the system not try for an IOMMU
solution? Is the driver asking for the wrong type of memory? It is doing a
dma_and_set_mask_coherent() call.


I don't think we have IOMMU on G4. On G5 it should work (I remember fixing
b43 issue on G5, see 4c374af5fdee, unfortunately all my G5 Macs with b43
are dead and waiting for re-capping).


You are right. My configuration has CONFIG_IOMMU_SUPPORT=y, but there is no 
mention of an IOMMU in the log.


Larry

Re: [BISECTED REGRESSION] b43legacy broken on G4 PowerBook

[Larry Finger]

On 6/11/19 5:46 PM, Benjamin Herrenschmidt wrote:

On Tue, 2019-06-11 at 17:20 -0500, Larry Finger wrote:

b43-pci-bridge 0001:11:00.0: dma_direct_supported: failed (mask =
0x3fff,
min_mask = 0x5000/0x5000, dma bits = 0x1f


Ugh ? A mask with holes in it ? That's very wrong... That min_mask is
bogus.


I agree, but that is not likely serious as most systems will have enough memory 
that the max_pfn term will be much larger than the initial min_mask, and 
min_mask will be unchanged by the min function. In addition, min_mask is not 
used beyond this routine, and then only to decide if direct dma is supported. 
The following patch generates masks with no holes, but I cannot see that it is 
needed.


diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 2c2772e9702a..e3edd4f29e80 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -384,7 +384,8 @@ int dma_direct_supported(struct device *dev, u64 mask)
else
min_mask = DMA_BIT_MASK(32);

-   min_mask = min_t(u64, min_mask, (max_pfn - 1) << PAGE_SHIFT);
+   min_mask = min_t(u64, min_mask, ((max_pfn - 1) << PAGE_SHIFT) |
+DMA_BIT_MASK(PAGE_SHIFT));

/*
 * This check needs to be against the actual bit mask value, so


Larry

Re: [BISECTED REGRESSION] b43legacy broken on G4 PowerBook

[Larry Finger]

On 6/11/19 1:05 AM, Christoph Hellwig wrote:

On Mon, Jun 10, 2019 at 11:09:47AM -0500, Larry Finger wrote:

What might be confusing in your output is that dev->dma_mask is a pointer,
and we are setting it in dma_set_mask.  That is before we only check
if the pointer is set, and later we override it.  Of course this doesn't
actually explain the failure.  But what is even more strange to me
is that you get a return value from dma_supported() that isn't 0 or 1,
as that function is supposed to return a boolean, and I really can't see
how mask >= __phys_to_dma(dev, min_mask), would return anything but 0
or 1.  Does the output change if you use the correct printk specifiers?

i.e. with a debug patch like this:


diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 2c2772e9702a..9e5b30b12b10 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -378,6 +378,7 @@ EXPORT_SYMBOL(dma_direct_map_resource);
  int dma_direct_supported(struct device *dev, u64 mask)
  {
u64 min_mask;
+   bool ret;
  
  	if (IS_ENABLED(CONFIG_ZONE_DMA))

min_mask = DMA_BIT_MASK(ARCH_ZONE_DMA_BITS);
@@ -391,7 +392,12 @@ int dma_direct_supported(struct device *dev, u64 mask)
 * use __phys_to_dma() here so that the SME encryption mask isn't
 * part of the check.
 */
-   return mask >= __phys_to_dma(dev, min_mask);
+   ret = (mask >= __phys_to_dma(dev, min_mask));
+   if (!ret)
+   dev_info(dev,
+   "%s: failed (mask = 0x%llx, min_mask = 0x%llx/0x%llx, dma 
bits = %d\n",
+   __func__, mask, min_mask, __phys_to_dma(dev, min_mask), 
ARCH_ZONE_DMA_BITS);
+   return ret;
  }
  
  size_t dma_direct_max_mapping_size(struct device *dev)

diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index f7afdadb6770..6c57ccdee2ae 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -317,8 +317,14 @@ void arch_dma_set_mask(struct device *dev, u64 mask);
  
  int dma_set_mask(struct device *dev, u64 mask)

  {
-   if (!dev->dma_mask || !dma_supported(dev, mask))
+   if (!dev->dma_mask) {
+   dev_info(dev, "no DMA mask set!\n");
return -EIO;
+   }
+   if (!dma_supported(dev, mask)) {
+   printk("DMA not supported\n");
+   return -EIO;
+   }
  
  	arch_dma_set_mask(dev, mask);

dma_check_mask(dev, mask);



After I got the correct formatting, the output with this patch only gives the 
following in dmesg:


b43-pci-bridge 0001:11:00.0: dma_direct_supported: failed (mask = 0x3fff, 
min_mask = 0x5000/0x5000, dma bits = 0x1f

DMA not supported
b43legacy-phy0 ERROR: The machine/kernel does not support the required 30-bit 
DMA mask


Your first patch did not work as the configuration does not have 
CONFIG_ZONE_DMA. As a result, the initial value of min_mask always starts at 32 
bits and is taken down to 31 with the maximum pfn minimization. When I forced 
the initial value of min_mask to 30 bits, the device worked.


It is obvious that the case of a mask smaller than min_mask should be handled by 
the IOMMU. In my system, CONFIG_IOMMU_SUPPORT is selected. All other CONFIG 
variables containing IOMMU are not selected. When dma_direct_supported() fails, 
should the system not try for an IOMMU solution? Is the driver asking for the 
wrong type of memory? It is doing a dma_and_set_mask_coherent() call.


Larry

Re: [BISECTED REGRESSION] b43legacy broken on G4 PowerBook

[Larry Finger]

On 6/10/19 3:18 AM, Christoph Hellwig wrote:

On Sat, Jun 08, 2019 at 04:52:24PM -0500, Larry Finger wrote:

On 6/7/19 12:29 PM, Christoph Hellwig wrote:

I don't think we should work around this in the driver, we need to fix
it in the core.  I'm curious why my previous patch didn't work.  Can
you throw in a few printks what failed?  I.e. did dma_direct_supported
return false?  Did the actual allocation fail?


Routine dma_direct_supported() returns true.

The failure is in routine dma_set_mask() in the following if test:

 if (!dev->dma_mask || !dma_supported(dev, mask))
 return -EIO;

For b43legacy, dev->dma_mask is 0xc2656848.
 dma_supported(dev, mask) is 0xc08b, mask is 0x3fff, and
the routine returns -EIO.

For b43,   dev->dma_mask is 0xc26568480001,
 dma_supported(dev, mask) is 0xc08b, mask is 0x, and
the routine returns 0.


I don't fully understand what values the above map to.  Can you send
me your actual debugging patch as well?


I do not understand why the if statement returns true as neither of the values 
is zero. After seeing the x86 output shown below, I also do not understand all 
the trailing zeros.


My entire patch is attached. That output came from this section:

diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index f7afdad..ba2489d 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -317,9 +317,12 @@ int dma_supported(struct device *dev, u64 mask)

 int dma_set_mask(struct device *dev, u64 mask)
 {
+   pr_info("mask 0x%llx, dma_mask 0x%llx, dma_supported 0x%llx\n", mask, 
dev->dma_mask,

+   dma_supported(dev, mask));
if (!dev->dma_mask || !dma_supported(dev, mask))
return -EIO;

+   pr_info("Continuing in dma_set_mask()\n");
arch_dma_set_mask(dev, mask);
dma_check_mask(dev, mask);
*dev->dma_mask = mask;

On a 32-bit x86 computer with 1GB of RAM, that same output was

For b43legacy, dev->dma_mask is 0x01f4029044.
dma_supported(dev, mask) is 0x1ef37f7000, mask is 0x3fff, and
the routine returns 0. 30-bit DMA works.

For b43,   dev->dma_mask is 0x01f4029044,
dma_supported(dev, mask) is 0x1ef37f7000, mask is 0x, and
 the routine also returns 0. This card supports 32-bit DMA.

Larry
diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index b8286a2..7a367ce 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -319,6 +319,10 @@ extern void copy_user_page(void *to, void *from, unsigned 
long vaddr,
 #endif /* __ASSEMBLY__ */
 #include 
 
+#if 1 /* XXX: pmac?  dynamic discovery? */
+#define ARCH_ZONE_DMA_BITS 30
+#else
 #define ARCH_ZONE_DMA_BITS 31
+#endif
 
 #endif /* _ASM_POWERPC_PAGE_H */
diff --git a/arch/powerpc/kernel/dma-iommu.c b/arch/powerpc/kernel/dma-iommu.c
index 09231ef..761d951 100644
--- a/arch/powerpc/kernel/dma-iommu.c
+++ b/arch/powerpc/kernel/dma-iommu.c
@@ -20,6 +20,8 @@
  */
 static inline bool dma_iommu_alloc_bypass(struct device *dev)
 {
+   pr_info("dev->archdata.iommu_bypass %d, !iommu_fixed_is_weak %d\n",
+   dev->archdata.iommu_bypass, !iommu_fixed_is_weak)   
return dev->archdata.iommu_bypass && !iommu_fixed_is_weak &&
dma_direct_supported(dev, dev->coherent_dma_mask);
 }
@@ -27,6 +29,8 @@ static inline bool dma_iommu_alloc_bypass(struct device *dev)
 static inline bool dma_iommu_map_bypass(struct device *dev,
unsigned long attrs)
 {
+   pr_info("(attrs & DMA_ATTR_WEAK_ORDERING) %d\n",
+   (attrs & DMA_ATTR_WEAK_ORDERING));
return dev->archdata.iommu_bypass &&
(!iommu_fixed_is_weak || (attrs & DMA_ATTR_WEAK_ORDERING));
 }
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index cba2913..2540d3b 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -248,7 +248,8 @@ void __init paging_init(void)
   (long int)((top_of_ram - total_ram) >> 20));
 
 #ifdef CONFIG_ZONE_DMA
-   max_zone_pfns[ZONE_DMA] = min(max_low_pfn, 0x7fffUL >> PAGE_SHIFT);
+   max_zone_pfns[ZONE_DMA] = min(max_low_pfn,
+   ((1UL << ARCH_ZONE_DMA_BITS) - 1) >> PAGE_SHIFT);
 #endif
max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
 #ifdef CONFIG_HIGHMEM
diff --git a/drivers/net/wireless/broadcom/b43/dma.c 
b/drivers/net/wireless/broadcom/b43/dma.c
index 806406a..e0270da 100644
--- a/drivers/net/wireless/broadcom/b43/dma.c
+++ b/drivers/net/wireless/broadcom/b43/dma.c
@@ -1053,6 +1053,7 @@ static int b43_dma_set_mask(struct b43_wldev *dev, u64 
mask)
 * lower mask, as we can always also support a lower one. */
while (1) {
err = dma_set_mask_and_coherent(dev->dev->dma_dev, mask);
+   pr_i

Re: [BISECTED REGRESSION] b43legacy broken on G4 PowerBook

[Larry Finger]

On 6/7/19 12:29 PM, Christoph Hellwig wrote:

I don't think we should work around this in the driver, we need to fix
it in the core.  I'm curious why my previous patch didn't work.  Can
you throw in a few printks what failed?  I.e. did dma_direct_supported
return false?  Did the actual allocation fail?


Routine dma_direct_supported() returns true.

The failure is in routine dma_set_mask() in the following if test:

if (!dev->dma_mask || !dma_supported(dev, mask))
return -EIO;

For b43legacy, dev->dma_mask is 0xc2656848.
dma_supported(dev, mask) is 0xc08b, mask is 0x3fff, and the 
routine returns -EIO.


For b43,   dev->dma_mask is 0xc26568480001,
dma_supported(dev, mask) is 0xc08b, mask is 0x, and the 
routine returns 0.


Thus far I have not found what sets the low-order bit of dev->dma_mask. 
Suggestions are welcome.


These tests have all been with your patch that sets ARCH_ZONE_DMA_BITS to 30.

Larry

Re: [BISECTED REGRESSION] b43legacy broken on G4 PowerBook

[Larry Finger]

On 6/7/19 12:29 PM, Christoph Hellwig wrote:

I don't think we should work around this in the driver, we need to fix
it in the core.  I'm curious why my previous patch didn't work.  Can
you throw in a few printks what failed?  I.e. did dma_direct_supported
return false?  Did the actual allocation fail?


I agree that that patch should not be sent upstream. I posted it only so that 
anyone running into the problem would have a work around.


I will try to see why your patch failed.

Larry

Re: [BISECTED REGRESSION] b43legacy broken on G4 PowerBook

[Larry Finger]

On 6/5/19 5:50 PM, Aaro Koskinen wrote:

Hi,

When upgrading from v5.0 -> v5.1 on G4 PowerBook, I noticed WLAN does
not work anymore:

[   42.004303] b43legacy-phy0: Loading firmware version 0x127, patch level 14 
(2005-04-18 02:36:27)
[   42.184837] b43legacy-phy0 debug: Chip initialized
[   42.184873] b43legacy-phy0 ERROR: The machine/kernel does not support the 
required 30-bit DMA mask

The same happens with the current mainline.

Bisected to:

commit 65a21b71f948406201e4f62e41f06513350ca390
Author: Christoph Hellwig 
Date:   Wed Feb 13 08:01:26 2019 +0100

powerpc/dma: remove dma_nommu_dma_supported

This function is largely identical to the generic version used
everywhere else.  Replace it with the generic version.

Signed-off-by: Christoph Hellwig 
Tested-by: Christian Zigotzky 
Signed-off-by: Michael Ellerman 


Aaro,

Please try the attached patch. I'm not really pleased with it and I will 
continue to determine why the fallback to a 30-bit mask fails, but at least this 
one works for me.


Larry


>From 25e2f50273e785598b6bd9a8aee28cf825d3fe9f Mon Sep 17 00:00:00 2001
From: Larry Finger 
Date: Fri, 7 Jun 2019 12:04:16 -0500
Subject: [PATCH] b43legacy: Fix DMA breakage from commit commit 65a21b71f948
To: kv...@codeaurora.org
Cc: linux-wirel...@vger.kernel.org,
pks...@realtek.com

Following commit 65a21b71f948 ("powerpc/dma: remove dma_nommu_dma_supported"),
this driver errors with a message that "The machine/kernel does not
support the required 30-bit DMA mask." Indeed, the hardware only allows
31-bit masks. This solution is to change the fallback mask from 30-
to 31-bits for 32-bit PPC systems.

Fixes: 65a21b71f948 ("powerpc/dma: remove dma_nommu_dma_supported")
Reported-by: Aaro Koskinen 
Cc: Christoph Hellwig 
Cc: Aaro Koskinen 
Signed-off-by: Larry Finger 
---
 drivers/net/wireless/broadcom/b43legacy/dma.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/broadcom/b43legacy/dma.c b/drivers/net/wireless/broadcom/b43legacy/dma.c
index 1cc25f44dd9a..75613f516e50 100644
--- a/drivers/net/wireless/broadcom/b43legacy/dma.c
+++ b/drivers/net/wireless/broadcom/b43legacy/dma.c
@@ -27,6 +27,15 @@
 #include 
 #include 
 
+/* Special handling for PPC32 - The maximum DMA mask is 31 bits, and
+ * the fallback to 30 bits fails. Set the fallback at 31.
+ */
+#ifdef CONFIG_PPC32
+#define FB_DMA	31
+#else
+#define FB_DMA	30
+#endif
+
 /* 32bit DMA ops. */
 static
 struct b43legacy_dmadesc32 *op32_idx2desc(struct b43legacy_dmaring *ring,
@@ -418,7 +427,7 @@ static bool b43legacy_dma_mapping_error(struct b43legacy_dmaring *ring,
 
 	switch (ring->type) {
 	case B43legacy_DMA_30BIT:
-		if ((u64)addr + buffersize > (1ULL << 30))
+		if ((u64)addr + buffersize > (1ULL << FB_DMA))
 			goto address_error;
 		break;
 	case B43legacy_DMA_32BIT:
@@ -617,12 +626,12 @@ static u64 supported_dma_mask(struct b43legacy_wldev *dev)
 	if (tmp & B43legacy_DMA32_TXADDREXT_MASK)
 		return DMA_BIT_MASK(32);
 
-	return DMA_BIT_MASK(30);
+	return DMA_BIT_MASK(FB_DMA);
 }
 
 static enum b43legacy_dmatype dma_mask_to_engine_type(u64 dmamask)
 {
-	if (dmamask == DMA_BIT_MASK(30))
+	if (dmamask == DMA_BIT_MASK(FB_DMA))
 		return B43legacy_DMA_30BIT;
 	if (dmamask == DMA_BIT_MASK(32))
 		return B43legacy_DMA_32BIT;
@@ -802,7 +811,7 @@ static int b43legacy_dma_set_mask(struct b43legacy_wldev *dev, u64 mask)
 			continue;
 		}
 		if (mask == DMA_BIT_MASK(32)) {
-			mask = DMA_BIT_MASK(30);
+			mask = DMA_BIT_MASK(FB_DMA);
 			fallback = true;
 			continue;
 		}
-- 
2.21.0

Re: [BISECTED REGRESSION] b43legacy broken on G4 PowerBook

[Larry Finger]

On 6/6/19 6:43 AM, Christoph Hellwig wrote:

On Thu, Jun 06, 2019 at 08:57:49PM +1000, Benjamin Herrenschmidt wrote:

Wow... that's an odd amount. One thing we could possibly do is add code
to limit the amount of RAM when we detect that device


Sent too quickly... I mean that *or* force swiotlb at 30-bits on those systems 
based
on detecting the presence of that device in the device-tree.


swiotlb doesn't really help you, as these days swiotlb on matters for
the dma_map* case.  What would help is a ZONE_DMA that covers these
devices.  No need to do the 24-bit x86 does, but 30-bit would do it.

WIP patch for testing below:

diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index b8286a2013b4..7a367ce87c41 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -319,6 +319,10 @@ struct vm_area_struct;
  #endif /* __ASSEMBLY__ */
  #include 
  
+#if 1 /* XXX: pmac?  dynamic discovery? */

+#define ARCH_ZONE_DMA_BITS 30
+#else
  #define ARCH_ZONE_DMA_BITS 31
+#endif
  
  #endif /* _ASM_POWERPC_PAGE_H */

diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index cba29131bccc..2540d3b2588c 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -248,7 +248,8 @@ void __init paging_init(void)
   (long int)((top_of_ram - total_ram) >> 20));
  
  #ifdef CONFIG_ZONE_DMA

-   max_zone_pfns[ZONE_DMA] = min(max_low_pfn, 0x7fffUL >> PAGE_SHIFT);
+   max_zone_pfns[ZONE_DMA] = min(max_low_pfn,
+   ((1UL << ARCH_ZONE_DMA_BITS) - 1) >> PAGE_SHIFT);
  #endif
max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
  #ifdef CONFIG_HIGHMEM



This trial patch failed.

Larry

Re: [BISECTED REGRESSION] b43legacy broken on G4 PowerBook

[Larry Finger]

On 6/6/19 6:43 AM, Christoph Hellwig wrote:

On Thu, Jun 06, 2019 at 08:57:49PM +1000, Benjamin Herrenschmidt wrote:

Wow... that's an odd amount. One thing we could possibly do is add code
to limit the amount of RAM when we detect that device


Sent too quickly... I mean that *or* force swiotlb at 30-bits on those systems 
based
on detecting the presence of that device in the device-tree.


swiotlb doesn't really help you, as these days swiotlb on matters for
the dma_map* case.  What would help is a ZONE_DMA that covers these
devices.  No need to do the 24-bit x86 does, but 30-bit would do it.

WIP patch for testing below:

diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index b8286a2013b4..7a367ce87c41 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -319,6 +319,10 @@ struct vm_area_struct;
  #endif /* __ASSEMBLY__ */
  #include 
  
+#if 1 /* XXX: pmac?  dynamic discovery? */

+#define ARCH_ZONE_DMA_BITS 30
+#else
  #define ARCH_ZONE_DMA_BITS 31
+#endif
  
  #endif /* _ASM_POWERPC_PAGE_H */

diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index cba29131bccc..2540d3b2588c 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -248,7 +248,8 @@ void __init paging_init(void)
   (long int)((top_of_ram - total_ram) >> 20));
  
  #ifdef CONFIG_ZONE_DMA

-   max_zone_pfns[ZONE_DMA] = min(max_low_pfn, 0x7fffUL >> PAGE_SHIFT);
+   max_zone_pfns[ZONE_DMA] = min(max_low_pfn,
+   ((1UL << ARCH_ZONE_DMA_BITS) - 1) >> PAGE_SHIFT);
  #endif
max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
  #ifdef CONFIG_HIGHMEM



I am generating a test kernel with this patch.

FYI, the "free" command on my machine shows 1.5+ G of memory. That likely means 
I have 2G installed.


I have tested a patched kernel in which b43legacy falls back to a 31-bit DMA 
mask when the 32-bit one failed. That worked, but would likely kill the x86 
version. Let me know if think a fix in the driver rather than the kernel would 
be better. I still need to understand why the same setup works in b43 and fails 
in b43legacy. :(


Larry

Re: [BISECTED REGRESSION] b43legacy broken on G4 PowerBook

[Larry Finger]

On 6/5/19 5:50 PM, Aaro Koskinen wrote:

Hi,

When upgrading from v5.0 -> v5.1 on G4 PowerBook, I noticed WLAN does
not work anymore:

[   42.004303] b43legacy-phy0: Loading firmware version 0x127, patch level 14 
(2005-04-18 02:36:27)
[   42.184837] b43legacy-phy0 debug: Chip initialized
[   42.184873] b43legacy-phy0 ERROR: The machine/kernel does not support the 
required 30-bit DMA mask

The same happens with the current mainline.

Bisected to:

commit 65a21b71f948406201e4f62e41f06513350ca390
Author: Christoph Hellwig 
Date:   Wed Feb 13 08:01:26 2019 +0100

powerpc/dma: remove dma_nommu_dma_supported

This function is largely identical to the generic version used
everywhere else.  Replace it with the generic version.

Signed-off-by: Christoph Hellwig 
Tested-by: Christian Zigotzky 
Signed-off-by: Michael Ellerman 


Aaro,

First of all, you have my sympathy for the laborious bisection on a PowerBook 
G4. I have done several myself. Thank you.


I confirm your results.

The ppc code has a maximum DMA size of 31 bits, thus a 32-bit request will fail. 
Why the 30-bit fallback fails in b43legacy fails while it works in b43 is a mystery.


Although dma_nommu_dma_supported() may be "largely identical" to 
dma_direct_supported(), they obviously differ. Routine dma_nommu_dma_supported() 
returns 1 for 32-bit systems, but I do not know what dma_direct_supported() returns.


I am trying to find a patch.

Larry

Re: Regression in 5.1.0-rc2: PowerBook G4 Aluminum fails to boot - bisected to commit 0df977eafc792

[Larry Finger]

On 3/25/19 3:46 AM, Christophe Leroy wrote:



Le 25/03/2019 à 01:49, Larry Finger a écrit :
A build of kernel 5.1.0-rc2 resulted in a failure to boot on my PowerBook G4 
Aluminum. The bootstrap loads the initial kernel and issues the appropriate 
start, but the machine hangs at that point.


The problem does not depend on the choice of PPC32 processor type. This 
machine has a 7447A according to /proc/cpuinfo.


The problem was bisected to the following:

commit 0df977eafc792a5365a7f81d8d5920132e03afad
Author: Christophe Leroy 
Date:   Thu Feb 21 10:37:54 2019 +

 powerpc/6xx: Don't use SPRN_SPRG2 for storing stack pointer while in RTAS

 When calling RTAS, the stack pointer is stored in SPRN_SPRG2
 in order to be able to restore it in case of machine check in RTAS.

 As machine check is not a perfomance critical path, this patch
 frees SPRN_SPRG2 by using a field in thread struct instead.

 Signed-off-by: Christophe Leroy 
 Signed-off-by: Michael Ellerman 

I reverted this patch and found that the system began execution, and then 
failed, likely due to the reassignment of SPRN_SPRG2.


I had found this problem with 5.1.0-rc1, but -rc2 was out by the time I 
finished the bisection. Unfortunately, none of the changes in -rc2 fixed the 
problem.


I think I identified the issue, see https://patchwork.ozlabs.org/patch/1063962/

It is now booting properly under QEMU with your .config

Could you please test it on your target ?


Thanks. That patch fixes the issue.

Larry

Re: [PATCH] powerpc/rtas: fix early boot failure.

[Larry Finger]

On 3/25/19 3:43 AM, Christophe Leroy wrote:

Commit 0df977eafc79 ("powerpc/6xx: Don't use SPRN_SPRG2 for storing
stack pointer while in RTAS") changes the code to use a field in
thread struct to store the stack pointer while in RTAS instead of
using SPRN_SPRG2. It therefore converts all places which were
manipulating SPRN_SPRG2 to use that field. During early startup,
the zeroing of SPRN_SPRG2 has been replaced by a zeroing of that
field in thread struct. But at least in start_here, that's done
wrongly because it used the physical address of the fields while
MMU is on at that time.

So the virtual address of the field should be used instead, but in
the meantime, thread struct has already been zeroised and initialised
so we can just drop this initialisation.

Reported-by: Larry Finger 
Fixes: 0df977eafc79 ("powerpc/6xx: Don't use SPRN_SPRG2 for storing stack pointer 
while in RTAS")
Signed-off-by: Christophe Leroy 


Tested-by: Larry Finger 

My PPC box now boots OK.

Larry

Re: Regression in 5.1.0-rc2: PowerBook G4 Aluminum fails to boot - bisected to commit 0df977eafc792

[Larry Finger]

On 3/25/19 1:53 AM, Christophe Leroy wrote:



Le 25/03/2019 à 01:49, Larry Finger a écrit :
A build of kernel 5.1.0-rc2 resulted in a failure to boot on my PowerBook G4 
Aluminum. The bootstrap loads the initial kernel and issues the appropriate 
start, but the machine hangs at that point.


Can you please be more explicit ? What do you mean by "issues the appropriate 
start" ? What is "that point" ? Any messages on the console ?


Sorry to be unclear. The bootstrap code prints a line saying "Booting Linux via 
__start() @ 0x00c0" and then hangs.


Your idea of confusion between physical and virtual address sounds right. I am 
building a kernel with that patch applied now. As it seems to be going quickly, 
I should have the answer fairly quickly.


Thanks,

Larry

Regression in 5.1.0-rc2: PowerBook G4 Aluminum fails to boot - bisected to commit 0df977eafc792

[Larry Finger]

A build of kernel 5.1.0-rc2 resulted in a failure to boot on my PowerBook G4 
Aluminum. The bootstrap loads the initial kernel and issues the appropriate 
start, but the machine hangs at that point.


The problem does not depend on the choice of PPC32 processor type. This machine 
has a 7447A according to /proc/cpuinfo.


The problem was bisected to the following:

commit 0df977eafc792a5365a7f81d8d5920132e03afad
Author: Christophe Leroy 
Date:   Thu Feb 21 10:37:54 2019 +

powerpc/6xx: Don't use SPRN_SPRG2 for storing stack pointer while in RTAS

When calling RTAS, the stack pointer is stored in SPRN_SPRG2
in order to be able to restore it in case of machine check in RTAS.

As machine check is not a perfomance critical path, this patch
frees SPRN_SPRG2 by using a field in thread struct instead.

Signed-off-by: Christophe Leroy 
Signed-off-by: Michael Ellerman 

I reverted this patch and found that the system began execution, and then 
failed, likely due to the reassignment of SPRN_SPRG2.


I had found this problem with 5.1.0-rc1, but -rc2 was out by the time I finished 
the bisection. Unfortunately, none of the changes in -rc2 fixed the problem.


Attached is the .config that I used.

Thanks,

Larry
#
# Automatically generated file; DO NOT EDIT.
# Linux/powerpc 5.1.0-rc2 Kernel Configuration
#

#
# Compiler: gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
#
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=40603
CONFIG_CLANG_VERSION=0
CONFIG_CC_HAS_ASM_GOTO=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_BUILD_SALT=""
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_XZ is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_SHOW_LEVEL=y
CONFIG_IRQ_DOMAIN=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
# CONFIG_GENERIC_IRQ_DEBUGFS is not set
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_NATIVE is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
# CONFIG_PSI is not set

#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
CONFIG_TINY_SRCU=y
CONFIG_BUILD_BIN2C=y
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=20
CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13
CONFIG_CGROUPS=y
# CONFIG_MEMCG is not set
CONFIG_BLK_CGROUP=y
# CONFIG_DEBUG_BLK_CGROUP is not set
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_CFS_BANDWIDTH is not set
# CONFIG_RT_GROUP_SCHED is not set
# CONFIG_CGROUP_PIDS is not set
# CONFIG_CGROUP_RDMA is not set
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_CGROUP_PERF=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_USER_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
# CONFIG_CHECKPOINT_RESTORE is not set
CONFIG_SCHED_AUTOGROUP=y
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
CONFIG_RD_LZ4=y
# CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_HAVE_LD_DEAD_CODE_DATA_ELIMINATION=y
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_BPF=y
# CONFIG_EXPERT is not set
CONFIG_MULTIUSER=y
CONFIG_SGETMASK_SYSCALL=y
CONFIG_SYSFS_SYSCALL=y
CONFIG_FHANDLE=y
CONFIG_POSIX_TIMERS=y
CONFIG_PRINTK=y
CONFIG_PRINTK_NMI=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_FUTEX_PI=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_IO_URING=y
CONFIG_ADVISE_SYSCALLS=y
CONFIG_MEMBARRIER=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
CONFIG_KALLSYMS_BASE_RELATIVE=y
# CONFIG_BPF_SYSCALL is not set
# CONFIG_USERFAULTFD is not set
CONFIG_ARCH_HAS_MEMBARRIER_CALLBACKS=y
CONFIG_RSEQ=y
# CONFIG_EMBEDDED is not set
CONFIG_HAVE_PERF_EVENTS=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
CONFIG_VM_EVENT_COUNTERS=y
# 

Re: [Update] Regression in 4.18 - 32-bit PowerPC crashes on boot - bisected to commit 1d40a5ea01d5

[Larry Finger]

On 07/01/2018 11:16 PM, Michael Ellerman wrote:

Linus Torvalds  writes:

On Fri, Jun 29, 2018 at 1:42 PM Larry Finger  wrote:


I have more information regarding this BUG. Line 700 of page-flags.h is the
macro PAGE_TYPE_OPS(Table, table). For further debugging, I manually expanded
the macro, and found that the bug line is VM_BUG_ON_PAGE(!PageTable(page), page)
in routine __ClearPageTable(), which is called from pgtable_page_dtor() in
include/linux/mm.h. I also added a printk call to PageTable() that logs
page->page_type. The routine was called twice. The first had page_type of
0xfbff, which would have been expected for a . The second call had
0x, which led to the BUG.


So it looks to me like the tear-down of the page tables first found a
page that is indeed a page table, and cleared the page table bit
(well, it set it - the bits are reversed).

...


That said, can some ppc person who knows the 32-bit ppc code and maybe
knows what that "interrupt: 700" means talk about that oddity in the
trace, please?


I think everyone else answered your questions here, and it should be
fixed now in your tree.

Larry let me know if you're still seeing a crash with 4.18-rc3.


The problem is fixed in 4.18-rc3. Thanks to all that helped.

Larry

Re: [Update] Regression in 4.18 - 32-bit PowerPC crashes on boot - bisected to commit 1d40a5ea01d5

[Larry Finger]

On 06/30/2018 04:31 AM, christophe leroy wrote:



Le 29/06/2018 à 22:42, Larry Finger a écrit :
My PowerBook G4 Aluminum crashes on boot with 4.18-rcX kernels with a kernel 
BUG at include/linux/page-flags.h:700! The problem was bisected to commit 
1d40a5ea01d5 ("mm: mark pages in use for page tables"). It is not possible to 
capture the bug with anything other than a camera. The first few lines of the 
traceback are as follows:


free_pgd_range+0x19c/0x30c (unreliable)
free_pgtables_0xa0/0xb0
exit_pmap+0xf4/0x16c
mmput+0x64/0xf0
do_exit+0x33c/0x89c
oops_end+0x13c/0x144
_exception_pkey+0x58/0x128
ret_from_except_full+0x0/0x4
--- interrupt: 700 at free_pgd_range+0x19c/0x30c
 LR = free_pgd_range+0x19c/0x30c
free_pgtables+0xa/0xb
exit_mnap+0xf4/0x16c
mmput+0x64/0xf0
flush_old_exec+0x490/0x550

I have more information regarding this BUG. Line 700 of page-flags.h is the 
macro PAGE_TYPE_OPS(Table, table). For further debugging, I manually expanded 
the macro, and found that the bug line is VM_BUG_ON_PAGE(!PageTable(page), 
page) in routine __ClearPageTable(), which is called from pgtable_page_dtor() 
in include/linux/mm.h. I also added a printk call to PageTable() that logs 
page->page_type. The routine was called twice. The first had page_type of 
0xfbff, which would have been expected for a . The second call had 
0x, which led to the BUG.




Oh, seems to be the one I noticed and told Aneesh about 
(https://patchwork.ozlabs.org/patch/922771/)


Aneesh provided the patch https://patchwork.ozlabs.org/patch/934111/ for it, 
does it help ?


Yes, those changes fix the problem.

Larry

[Update] Regression in 4.18 - 32-bit PowerPC crashes on boot - bisected to commit 1d40a5ea01d5

[Larry Finger]

My PowerBook G4 Aluminum crashes on boot with 4.18-rcX kernels with a kernel BUG 
at include/linux/page-flags.h:700! The problem was bisected to commit 
1d40a5ea01d5 ("mm: mark pages in use for page tables"). It is not possible to 
capture the bug with anything other than a camera. The first few lines of the 
traceback are as follows:


free_pgd_range+0x19c/0x30c (unreliable)
free_pgtables_0xa0/0xb0
exit_pmap+0xf4/0x16c
mmput+0x64/0xf0
do_exit+0x33c/0x89c
oops_end+0x13c/0x144
_exception_pkey+0x58/0x128
ret_from_except_full+0x0/0x4
--- interrupt: 700 at free_pgd_range+0x19c/0x30c
LR = free_pgd_range+0x19c/0x30c
free_pgtables+0xa/0xb
exit_mnap+0xf4/0x16c
mmput+0x64/0xf0
flush_old_exec+0x490/0x550

I have more information regarding this BUG. Line 700 of page-flags.h is the 
macro PAGE_TYPE_OPS(Table, table). For further debugging, I manually expanded 
the macro, and found that the bug line is VM_BUG_ON_PAGE(!PageTable(page), page) 
in routine __ClearPageTable(), which is called from pgtable_page_dtor() in 
include/linux/mm.h. I also added a printk call to PageTable() that logs 
page->page_type. The routine was called twice. The first had page_type of 
0xfbff, which would have been expected for a . The second call had 
0x, which led to the BUG.


Larry

Regression in 4.18 - 32-bit PowerPC crashes on boot - bisected to commit 1d40a5ea01d5

[Larry Finger]

My PowerBook G4 Aluminum crashes on boot with 4.18-rcX kernels with a kernel BUG 
at include/linux/page-flags.h:700! The problem was bisected to commit 
1d40a5ea01d5 ("mm: mark pages in use for page tables"). It is not possible to 
capture the bug with anything other than a camera. The first few lines of the 
traceback are as follows:


free_pgd_range+0x19c/0x30c (unreliable)
free_pgtables_0xa0/0xb0
exit_pmap+0xf4/0x16c
mmput+0x64/0xf0
do_exit+0x33c/0x89c
oops_end+0x13c/0x144
_exception_pkey+0x58/0x128
ret_from_except_full+0x0/0x4
--- interrupt: 700 at free_pgd_range+0x19c/0x30c
LR = free_pgd_range+0x19c/0x30c
free_pgtables+0xa/0xb
exit_mnap+0xf4/0x16c
mmput+0x64/0xf0
flush_old_exec+0x490/0x550

I have a PDF of the complete dump, but I hesitate to send this to the entire 
group.

Thanks,

Larry

[PATCH v2] macintosh: Add module license to ans-lcd

[Larry Finger]

In kernel 4.15, the modprobe step on my PowerBook G4 started complaining that
there was no module license for ans-lcd.

Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
---
v2 - fixed typo in commit message
---
 drivers/macintosh/ans-lcd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/macintosh/ans-lcd.c b/drivers/macintosh/ans-lcd.c
index 1de81d922d8a..c8e078b911c7 100644
--- a/drivers/macintosh/ans-lcd.c
+++ b/drivers/macintosh/ans-lcd.c
@@ -201,3 +201,4 @@ anslcd_exit(void)
 
 module_init(anslcd_init);
 module_exit(anslcd_exit);
+MODULE_LICENSE("GPL v2");
-- 
2.16.1

Re: [PATCH] macintosh: Add module license to ans-lcd

[Larry Finger]

On 01/29/2018 04:49 PM, Gabriel Paubert wrote:

On Mon, Jan 29, 2018 at 01:33:08PM -0600, Larry Finger wrote:

In kernel 4.15, the modprobe step on my PowerBook G5 started complaining that
 
PowerBook G5? Really, could you send a pic! :-)


That was a typo. It is a G4 Aluminum.

Larry

[PATCH] macintosh: Add module license to ans-lcd

[Larry Finger]

In kernel 4.15, the modprobe step on my PowerBook G5 started complaining that
there was no module license for ans-lcd.

Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
---
 drivers/macintosh/ans-lcd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/macintosh/ans-lcd.c b/drivers/macintosh/ans-lcd.c
index 1de81d922d8a..c8e078b911c7 100644
--- a/drivers/macintosh/ans-lcd.c
+++ b/drivers/macintosh/ans-lcd.c
@@ -201,3 +201,4 @@ anslcd_exit(void)
 
 module_init(anslcd_init);
 module_exit(anslcd_exit);
+MODULE_LICENSE("GPL v2");
-- 
2.16.1

Re: Regression for Power PC in 4.14-rc0 - bisected to commit 31bfdb036f12

[Larry Finger]

On 09/13/2017 07:37 PM, Andrew Donnellan wrote:

On 14/09/17 10:07, Larry Finger wrote:
When booting my PowerBook Aluminum G4, I get a pop-up screen that says "The 
system is running in low-graphics  mode. Your screen, graphics card, and input 
device settings could not be detected correctly. You will need to configure 
these yourself." This is a big-endian 74xx CPU. The lscpu command says it is a 
PowerBook5,6 model.


This problem has been bisected to commit 31bfdb036f12 ("powerpc: Use 
instruction emulation infrastructure to handle alignment faults"). I am 
confident of the accuracy of the bisection.


Attached is the configuration.


Try with https://patchwork.ozlabs.org/patch/813153/

(A selftest for the instruction emulation will make its way upstream 
eventually...)


That patch does fix my problem. Thanks for the quick response.

Larry

Regression for Power PC in 4.14-rc0 - bisected to commit 31bfdb036f12

[Larry Finger]

When booting my PowerBook Aluminum G4, I get a pop-up screen that says "The 
system is running in low-graphics  mode. Your screen, graphics card, and input 
device settings could not be detected correctly. You will need to configure 
these yourself." This is a big-endian 74xx CPU. The lscpu command says it is a 
PowerBook5,6 model.


This problem has been bisected to commit 31bfdb036f12 ("powerpc: Use instruction 
emulation infrastructure to handle alignment faults"). I am confident of the 
accuracy of the bisection.


Attached is the configuration.

Thanks,

Larry



#
# Automatically generated file; DO NOT EDIT.
# Linux/powerpc 4.13.0-rc2 Kernel Configuration
#
# CONFIG_PPC64 is not set

#
# Processor support
#
CONFIG_PPC_BOOK3S_32=y
# CONFIG_PPC_85xx is not set
# CONFIG_PPC_8xx is not set
# CONFIG_40x is not set
# CONFIG_44x is not set
# CONFIG_E200 is not set
CONFIG_PPC_BOOK3S=y
CONFIG_6xx=y
CONFIG_PPC_FPU=y
CONFIG_ALTIVEC=y
CONFIG_PPC_STD_MMU=y
CONFIG_PPC_STD_MMU_32=y
# CONFIG_PPC_MM_SLICES is not set
CONFIG_PPC_HAVE_PMU_SUPPORT=y
CONFIG_PPC_PERF_CTRS=y
# CONFIG_FORCE_SMP is not set
# CONFIG_SMP is not set
# CONFIG_PPC_DOORBELL is not set
CONFIG_VDSO32=y
CONFIG_CPU_BIG_ENDIAN=y
CONFIG_PPC32=y
CONFIG_32BIT=y
# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
# CONFIG_ARCH_DMA_ADDR_T_64BIT is not set
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MAX=17
CONFIG_ARCH_MMAP_RND_BITS_MIN=11
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=17
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=11
# CONFIG_HAVE_SETUP_PER_CPU_AREA is not set
# CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK is not set
CONFIG_NR_IRQS=512
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_HAS_DMA_SET_COHERENT_MASK=y
CONFIG_PPC=y
# CONFIG_GENERIC_CSUM is not set
CONFIG_EARLY_PRINTK=y
CONFIG_PANIC_TIMEOUT=180
CONFIG_GENERIC_NVRAM=y
CONFIG_SCHED_OMIT_FRAME_POINTER=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_PPC_UDBG_16550=y
# CONFIG_GENERIC_TBSYNC is not set
CONFIG_AUDIT_ARCH=y
CONFIG_GENERIC_BUG=y
# CONFIG_EPAPR_BOOT is not set
# CONFIG_DEFAULT_UIMAGE is not set
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
# CONFIG_PPC_DCR_NATIVE is not set
# CONFIG_PPC_DCR_MMIO is not set
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_KERNEL_GZIP=y
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_SHOW_LEVEL=y
CONFIG_IRQ_DOMAIN=y
CONFIG_GENERIC_MSI_IRQ=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
# CONFIG_GENERIC_IRQ_DEBUGFS is not set
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_NATIVE is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y

#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
CONFIG_TINY_SRCU=y
# CONFIG_TASKS_RCU is not set
# CONFIG_RCU_STALL_COMMON is not set
# CONFIG_RCU_NEED_SEGCBLIST is not set
CONFIG_BUILD_BIN2C=y
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=20
CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13
CONFIG_CGROUPS=y
# CONFIG_MEMCG is not set
CONFIG_BLK_CGROUP=y
# CONFIG_DEBUG_BLK_CGROUP is not set
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_CFS_BANDWIDTH is not set
# CONFIG_RT_GROUP_SCHED is not set
# CONFIG_CGROUP_PIDS is not set
# CONFIG_CGROUP_RDMA is not set
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_CGROUP_PERF=y
# CONFIG_CGROUP_DEBUG is not set
# CONFIG_SOCK_CGROUP_DATA is not set
# CONFIG_CHECKPOINT_RESTORE is not set
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_USER_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
CONFIG_SCHED_AUTOGROUP=y
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
CONFIG_RD_LZ4=y
# CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE is not set

Re: Regression in kernel 4.12-rc1 for Powerpc 32 - bisected to commit 3448890c32c3

[Larry Finger]

On 06/23/2017 03:29 PM, Al Viro wrote:

On Fri, Jun 23, 2017 at 01:49:16PM -0500, Larry Finger wrote:


BTW, could you try to check what happens if you kill the
if (__builtin_constant_p(n) && (n <= 8))
bits in raw_copy_{to,from}_user()?  The usefulness of those (in 
__copy_from_user()
originally) had always been dubious and the things are simpler without them.
If _that_ turns out to cure breakage, I would be very surprised, though.


Sorry I was gone so long. Installing jessie on this box resulted in a crash
on boot. Lubuntu 14.04 yielded a desktop with a functioning cursor, but
nothing else. Finally, Ubuntu 12.04 resulted in a working system. I hate
Unity, but I guess I'm stuck for now.


Ho-hum...  Jessie is 3.16, so whatever is crashing there, it's something
different...  Ubuntu 12.04 is what, 3.2?


I know how easy it is to screw up a long bisection by booting the wrong
kernel. To help that problem and to work around the yaconf/yboot nonsense on
the MAC, my /etc/yaconf has always had generic kernel stanzas with only
default, old, and original kernels mentioned. From there I use a local
script to finish a kernel installation by moving the default links to the
old ones and creating the new default links pointing to the current kernel.
With those long-tested scripts, I'm sure that I am booting the one I want.

With the new installation, kernel 4.12-rc6 failed, as did 3448890c with the
backported 46f401c4 added.

Replacing "if (__builtin_constant_p(n) && (n <= 8))" with "if (0)" had no 
effect.


OK, that simplifies things a bit.  Just to make sure we are on the same page:

* f2ed8bebee69 + cherry-pick of 46f401c4 boots (Ubuntu 12.04 userland)
* 3448890c32c3 + cherry-pick of 46f401c4 fails (Ubuntu 12.04 userland), ditto
   with removal of constant-size bits in raw_copy_..._user().  Failure appears
   to be on udev getting EFAULT on some syscalls.
* straight Ubuntu 12.04 works
* jessie crashes on boot.


I made a break through. If I turn off inline copy to/from users for 32-bit ppc 
with the following patch, then the system boots:


diff --git a/arch/powerpc/include/asm/uaccess.h 
b/arch/powerpc/include/asm/uaccess.h
index 5c0d8a8cdae5..1e6a8723f497 100644
--- a/arch/powerpc/include/asm/uaccess.h
+++ b/arch/powerpc/include/asm/uaccess.h
@@ -267,12 +267,7 @@ do { 
   \

 extern unsigned long __copy_tofrom_user(void __user *to,
const void __user *from, unsigned long size);

-#ifndef __powerpc64__
-
-#define INLINE_COPY_FROM_USER
-#define INLINE_COPY_TO_USE
-
-#else /* __powerpc64__ */
+#ifdef __powerpc64__

 static inline unsigned long
 raw_copy_in_user(void __user *to, const void __user *from, unsigned long n)

It seems whatever problem I am seeing is in the inline version of 
_copy_to_user() and _copy_from_user() on the 32-bit ppc. The only other 
difference between the two versions is the placement of the __user macro, which 
looks to be wrong in the non-inlined version of _copy_to_user() in 
lib/usercopy.c, but that is the one that works.


To me, this looks like a compiler error. On the PowerBook, 'gcc --version' 
reports "gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3".


I will prepare a proper patch that I will send to you privately. If you agree 
with it, it can be send through normal channels in time for the release of 4.12.


Larry

[PATCH] powerpc: Fix crash introduced with commit 5657933dbb6e

[Larry Finger]

Code inserted during the code merged between kernels 4.10 and 4.11-rc1
caused an early panic quickly followed by a complete shutdown for
PowerPC. The traceback was not displayed long enough to read or
photograph, thus it is not reproduced here.

The problem was bisected to commit 5657933dbb6e ("treewide: Move dma_ops
from struct dev_archdata into struct device"). The problem was a missing
copy of critical information from struct dev_archdata into struct device,
leading to the dereference of a null pointer.

This fix was suggested by Benjamin Herrenschmidt.

Fixes: commit 5657933dbb6e ("treewide: Move dma_ops from struct dev_archdata 
into struct device")
Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org>
Cc: regressi...@leemhuis.info <regressi...@leemhuis.info>

 drivers/macintosh/macio_asic.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/macintosh/macio_asic.c b/drivers/macintosh/macio_asic.c
index 3f041b1..f757cef2 100644
--- a/drivers/macintosh/macio_asic.c
+++ b/drivers/macintosh/macio_asic.c
@@ -392,6 +392,7 @@ static struct macio_dev * macio_add_one_device(struct 
macio_chip *chip,
 * To get all the fields, copy all archdata
 */
dev->ofdev.dev.archdata = chip->lbus.pdev->dev.archdata;
+   dev->ofdev.dev.dma_ops = chip->lbus.pdev->dev.dma_ops;
 #endif /* CONFIG_PCI */
 
 #ifdef DEBUG
-- 
2.10.2

[PATCH] powerpc: Fix build warning on 32-bit PPC - bisected to commit 989cea5c14be

[Larry Finger]

I am getting the following warning when I build kernel 4.9-git on my
PowerBook G4 with a 32-bit PPC processor:

  AS  arch/powerpc/kernel/misc_32.o
arch/powerpc/kernel/misc_32.S:299:7: warning: "CONFIG_FSL_BOOKE" is not defined 
[-Wundef]

This problem is evident after commit 989cea5c14be ("kbuild: prevent
lib-ksyms.o rebuilds"); however, this change in kbuild only exposes an
error that has been in the code since 2005 when this source file was
created. That was with commit 9994a33865f4 ("powerpc: Introduce
entry_{32,64}.S, misc_{32,64}.S, systbl.S"). The offending line is
way does not make a lot of sense. This error does not seem to cause any
errors in the executable, thus I am not recommending that it be applied
to any stable versions.

Thanks to Nicholas Piggin for suggesting this solution.

Fixes: 9994a33865f4 ("powerpc: Introduce entry_{32,64}.S, misc_{32,64}.S, 
systbl.S")
Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
Cc: Nicholas Piggin <npig...@gmail.com>
Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org>
Cc: Paul Mackerras <pau...@samba.org>
Cc: Michael Ellerman <m...@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
---
 arch/powerpc/kernel/misc_32.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S
index 1863324..84db14e 100644
--- a/arch/powerpc/kernel/misc_32.S
+++ b/arch/powerpc/kernel/misc_32.S
@@ -296,7 +296,7 @@ _GLOBAL(flush_instruction_cache)
lis r3, KERNELBASE@h
iccci   0,r3
 #endif
-#elif CONFIG_FSL_BOOKE
+#elif defined(CONFIG_FSL_BOOKE)
 BEGIN_FTR_SECTION
mfspr   r3,SPRN_L1CSR0
ori r3,r3,L1CSR0_CFI|L1CSR0_CLFC
-- 
2.10.2

Re: Build warning on 32-bit PPC - bisected to commit 989cea5c14be

[Larry Finger]

On 12/21/2016 08:02 PM, Nicholas Piggin wrote:

Hi Larry,

This is strange you've bisected it there, I can't see how that patch would
trigger it. That said, powerpc has had a few small build system glitches.

It looks like this warning could be fixed by changing #elif CONFIG_FSL_BOOKE
to #elif defined (CONFIG_FSL_BOOKE). Want to send a patch (if it works)?


Nick,

I agree that the "bad" commit does not look likely to be the problem, but I 
verified it by checking out the previous commit, which does not show the 
problem. I'm quite sure that PowerPC has a lot of quirks and glitches beyond 
those caused by the Apple hardware.


I have tested the change and I will submit the patch.

Thanks,

Larry

Re: [PATCH v3] console: use first console if stdout-path device doesn't appear

[Larry Finger]

On 11/07/2016 11:21 AM, Paul Burton wrote:

Hi Larry,

On Monday, 7 November 2016 09:26:37 GMT Larry Finger wrote:

A revert was already submitted by Hans de Goede & is being discussed over
here:

https://marc.info/?l=linux-kernel=147826151427455=2


I am a little surprised that I was not CCd on that thread.


Hans started that thread without copying you just as you started your thread
without copying Andreas, who reported issues first.


My searching had failed to find his report.


To reiterate, my
PowerBook G4 with a PPC32 processor CRASHES on boot. That is a lot more
serious than the console output disappearing.


Crashes as in init dies due to lack of a console, right?


It gets a kernel panic because of an attempt to kill process 1 (init). It then 
waits 120 seconds and tries to reboot.



As it seems unlikely that this regression will be fixed in the current
cycle, I recommend that the reversion of commit 05fd007e4629 until a proper
fix is available.


I agree that reverting is probably the best option for now, and have replied
with that in the other thread too.


Good.

Larry

Re: [PATCH v3] console: use first console if stdout-path device doesn't appear

[Larry Finger]

On 11/07/2016 03:18 AM, Paul Burton wrote:

On Monday, 7 November 2016 19:27:32 GMT Michael Ellerman wrote:

Paul Burton  writes:

If a device tree specified a preferred device for kernel console output
via the stdout-path or linux,stdout-path chosen node properties there's
no guarantee that it will have specified a device for which we have a
driver. It may also be the case that we do have a driver but it doesn't
call of_console_check() to register as a preferred console (eg. offb
driver as used on powermac systems).

In these cases try to ensure that we provide some console output by
enabling the first usable registered console, which we keep track of
with the of_fallback_console variable. Affected systems will enable
their console later than they did prior to commit 05fd007e4629
("console: don't prefer first registered if DT specifies stdout-path")
but should otherwise produce the same output.

Tested in QEMU with a PowerPC pseries_defconfig kernel.


Hi Paul,

This does "work", as in it boots and I get a console. But the delay in
getting output on the VGA is not workable. I get pretty much no output
until the machine is booted entirely to userspace, meaning any crash
prior to that will be undebuggable.

I also note Andreas reports it doesn't work at all on PowerMac.

Please send a revert and we can try again next cycle.

cheers


Hi Michael,

A revert was already submitted by Hans de Goede & is being discussed over
here:

https://marc.info/?l=linux-kernel=147826151427455=2


I am a little surprised that I was not CCd on that thread. To reiterate, my 
PowerBook G4 with a PPC32 processor CRASHES on boot. That is a lot more serious 
than the console output disappearing.


As it seems unlikely that this regression will be fixed in the current cycle, I 
recommend that the reversion of commit 05fd007e4629 until a proper fix is available.


Larry

Re: [PATCH v2] console: use first console if stdout-path device doesn't appear

[Larry Finger]

On 10/31/2016 06:09 PM, Sergey Senozhatsky wrote:

Hi,

On (10/31/16 15:50), Paul Burton wrote:
[..]

Actually whilst this fixes the output in QEMU it has other problems. I'm still
digging...


I propose a revert of '05fd007e46296', so you guys can find the
problem and fix it, not being under 'rc3' pressure.


If we were at -rc4 or -rc5, then I would agree; however, I think there is still 
time to fix the problem.


Larry

Re: [PATCH v2] console: use first console if stdout-path device doesn't appear

[Larry Finger]

On 10/31/2016 10:50 AM, Paul Burton wrote:

On Monday, 31 October 2016 12:14:55 GMT Paul Burton wrote:

If a device tree specified a preferred device for kernel console output
via the stdout-path or linux,stdout-path chosen node properties there's
no guarantee that it will have specified a device for which we have a
driver. It may also be the case that we do have a driver but it doesn't
call of_console_check() to register as a preferred console (eg. offb
driver as used on powermac systems). In these cases try to ensure that
we provide some console output by enabling the first usable registered
console, which we keep track of with the of_fallback_console variable.

Tested in QEMU with a PowerPC pseries_defconfig kernel.


Actually whilst this fixes the output in QEMU it has other problems. I'm still
digging...


As expected, it does n ot work with 4.9-rc3 on the real PowerPC.

Larry

Re: [PATCH v2] console: use first console if stdout-path device doesn't appear

[Larry Finger]

On 10/31/2016 07:14 AM, Paul Burton wrote:

If a device tree specified a preferred device for kernel console output
via the stdout-path or linux,stdout-path chosen node properties there's
no guarantee that it will have specified a device for which we have a
driver. It may also be the case that we do have a driver but it doesn't
call of_console_check() to register as a preferred console (eg. offb
driver as used on powermac systems). In these cases try to ensure that
we provide some console output by enabling the first usable registered
console, which we keep track of with the of_fallback_console variable.

Tested in QEMU with a PowerPC pseries_defconfig kernel.


The patch fails to fix my real PowerPC. I still get a kernel panic for an 
attempt to kill init. This first test was done with 4.9-rc2. I am in the process 
of updating to -rc3 to see if that changes anything. Later today when that build 
finishes, I will report those results.


Larry

Re: [PATCH] tty/serial/pmac_zilog: Fix nobody cared IRQ message

[Larry Finger]

On 04/29/2012 04:05 AM, Gabriel Paubert wrote:

On Sat, Apr 28, 2012 at 06:53:49PM -0500, Larry Finger wrote:

Hmm, I'm not a native english speaker, but I have the feeling that
it would be more grammatically correct to use opened instead of open.

Of course if the message never triggers, it's less of concern :-)


English is my native language, but that might not help. :)

I would say the device has not been opened, but it is not open. More 
generally, to me opened denotes past tense, and open is used in the present.


Even with the other bug, the message never triggered as I did not have debugging 
enabled. Given the relative rarity of PPC-based boxes running Linux, the message 
may never print.


Thanks for the comment.

Larry

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] tty/serial/pmac_zilog: Fix nobody cared IRQ message

[Larry Finger]

On 04/29/2012 07:23 PM, Benjamin Herrenschmidt wrote:

On Sat, 2012-04-28 at 18:53 -0500, Larry Finger wrote:



Index: wireless-testing/drivers/tty/serial/pmac_zilog.c
===
--- wireless-testing.orig/drivers/tty/serial/pmac_zilog.c   2012-04-28
15:51:38.843723074 -0500
+++ wireless-testing/drivers/tty/serial/pmac_zilog.c2012-04-28
18:34:34.053900600 -0500


Patch seems to be wrapped... I'll apply manually this time around but
check your mailer settings :-)


Sorry about that. I don't usually send patches that way, and forgot to check for 
wrapping.


Larry


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Regression in 32-bit ppc kernel

[Larry Finger]

On 04/27/2012 07:42 PM, Benjamin Herrenschmidt wrote:


Ok, so you do have a serial port, probably two even :-) One of them is
connected to the infra red transceiver and the other one is probably
connected to the internal modem.

(The modem itself might not use it, some of these machines use an
i2s/i2c modem, some use a usb modem, but the serial port is wired to the
connector regardless).


I have done a little more debugging. The problem is definitely coming from 
drivers/tty/serial/pmac_zilog.c. I am getting ChanB interrupts while open, which 
causes the following code segment to return IRQ_NONE:


   if (r3  (CHBEXT | CHBTxIP | CHBRxIP)) {
   if (!ZS_IS_OPEN(uap_a)) {
   pmz_debug(ChanB interrupt while open !\n);
   goto skip_b;
   }
   write_zsreg(uap_b, R0, RES_H_IUS);
   zssync(uap_b);
   if (r3  CHBEXT)

When this section is entered, r3 == 0x2 (CHBTxIP).

Larry
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Regression in 32-bit ppc kernel

[Larry Finger]

On 04/28/2012 05:48 PM, Benjamin Herrenschmidt wrote:

On Sat, 2012-04-28 at 20:23 +0200, Andreas Schwab wrote:

Larry Fingerlarry.fin...@lwfinger.net  writes:


I have done a little more debugging. The problem is definitely coming from
drivers/tty/serial/pmac_zilog.c. I am getting ChanB interrupts while open,
which causes the following code segment to return IRQ_NONE:

if (r3  (CHBEXT | CHBTxIP | CHBRxIP)) {
if (!ZS_IS_OPEN(uap_a)) {


s/uap_a/uap_b/?


Good catch... Let's see if that fixes it for Larry...


Yes, good catch by Andreas. That change does fix the problem.

Ben - Do you want to fix the typos for open/not open with the same patch?

Larry

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Regression in 32-bit ppc kernel

[Larry Finger]

On 04/28/2012 06:23 PM, Benjamin Herrenschmidt wrote:

On Sat, 2012-04-28 at 18:17 -0500, Larry Finger wrote:

Yes, good catch by Andreas. That change does fix the problem.

Ben - Do you want to fix the typos for open/not open with the same
patch?


Sure, if you're going to do a proper patch, by all means please fix
those too :-)

Does it fix all the occurrences of the problem for you ?


Yes. After the patch is applied, no more nobody cared IRQ messages.

I will prepare the patch and send it to you.

Larry



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] tty/serial/pmac_zilog: Fix nobody cared IRQ message

[Larry Finger]

Following commit a79dd5a titled tty/serial/pmac_zilog: Fix suspend  resume,
my Powerbook G4 Titanium showed the following stack dump:

[   36.878225] irq 23: nobody cared (try booting with the irqpoll option)
[   36.878251] Call Trace:
[   36.878291] [dfff3f00] [c000984c] show_stack+0x7c/0x194 (unreliable)
[   36.878322] [dfff3f40] [c00a6868] __report_bad_irq+0x44/0xf4
[   36.878339] [dfff3f60] [c00a6b04] note_interrupt+0x1ec/0x2ac
[   36.878356] [dfff3f80] [c00a48d0] handle_irq_event_percpu+0x250/0x2b8
[   36.878372] [dfff3fd0] [c00a496c] handle_irq_event+0x34/0x54
[   36.878389] [dfff3fe0] [c00a753c] handle_fasteoi_irq+0xb4/0x124
[   36.878412] [dfff3ff0] [c000f5bc] call_handle_irq+0x18/0x28
[   36.878428] [deef1f10] [c000719c] do_IRQ+0x114/0x1cc
[   36.878446] [deef1f40] [c0015868] ret_from_except+0x0/0x1c
[   36.878484] --- Exception: 501 at 0xf497610
[   36.878489] LR = 0xfdc3dd0
[   36.878497] handlers:
[   36.878510] [c02b7424] pmz_interrupt
[   36.878520] Disabling IRQ #23

From an E-mail exchange about this problem, Andreas Schwab noticed a typo
that resulted in the wrong condition being tested.

The patch also corrects 2 typos that incorrectly report why an error branch
is being taken.

Signed-off-by: Larry Finger larry.fin...@lwfinger.net
---

Ben,

Any changes you wish to make in the commit message are OK with me.

Larry
---

Index: wireless-testing/drivers/tty/serial/pmac_zilog.c
===
--- wireless-testing.orig/drivers/tty/serial/pmac_zilog.c	2012-04-28 
15:51:38.843723074 -0500
+++ wireless-testing/drivers/tty/serial/pmac_zilog.c	2012-04-28 
18:34:34.053900600 -0500

@@ -469,7 +469,7 @@
tty = NULL;
if (r3  (CHAEXT | CHATxIP | CHARxIP)) {
if (!ZS_IS_OPEN(uap_a)) {
-   pmz_debug(ChanA interrupt while open !\n);
+   pmz_debug(ChanA interrupt while not open !\n);
goto skip_a;
}
write_zsreg(uap_a, R0, RES_H_IUS);
@@ -493,8 +493,8 @@
spin_lock(uap_b-port.lock);
tty = NULL;
if (r3  (CHBEXT | CHBTxIP | CHBRxIP)) {
-   if (!ZS_IS_OPEN(uap_a)) {
-   pmz_debug(ChanB interrupt while open !\n);
+   if (!ZS_IS_OPEN(uap_b)) {
+   pmz_debug(ChanB interrupt while not open !\n);
goto skip_b;
}
write_zsreg(uap_b, R0, RES_H_IUS);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Regression in 32-bit ppc kernel

[Larry Finger]

On 04/25/2012 04:44 PM, Benjamin Herrenschmidt wrote:


Do we know what the bad interrupt maps to ? Also what is the value of
NR_IRQ and do you have SPARSE_IRQ enabled ? Can you try with the latter
disabled and NR_IRQ set to something large, such as 128 ?

(You may be able to check the interrupt mapping in debugfs)


Sorry, I was unable to find anything in debugfs to help me learn about interrupt 
mapping. The value of CONFIG_NR_IRQS is already 512. I have not tried reducing 
it to 128. The setting for CONFIG_SPARSE_IRQ was on, and changing it to off did 
not make any difference.


I finished the bisection, which led to

commit a79dd5ae5a8f49688d65b89a859f2b98a7ee5538
Author: Benjamin Herrenschmidt b...@kernel.crashing.org
Date:   Thu Dec 15 11:13:03 2011 +1100

tty/serial/pmac_zilog: Fix suspend  resume

As this seemed to be an improbable result, I did the full test by checking out 
the previous commit (43ca5d3). That resulted in a good result. Then I used 
quilt to add commit a79dd5a as a patch and the fault returned. I then noticed 
that you said in the commit message that I removed some code for handling 
unexpected interrupt which should never be hit It appears that my box does 
indeed hit such an unexpected interrupt.


I could always get rid of the fault by disabling CONFIG_SERIAL_PMACZILOG, but I 
would like to fix the problem if possible.


Thanks,

Larry

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Regression in 32-bit ppc kernel

[Larry Finger]

On 04/27/2012 05:26 PM, Benjamin Herrenschmidt wrote:

On Fri, 2012-04-27 at 10:38 -0500, Larry Finger wrote:


Sorry, I was unable to find anything in debugfs to help me learn about interrupt
mapping. The value of CONFIG_NR_IRQS is already 512. I have not tried reducing
it to 128. The setting for CONFIG_SPARSE_IRQ was on, and changing it to off did
not make any difference.

I finished the bisection, which led to

commit a79dd5ae5a8f49688d65b89a859f2b98a7ee5538
Author: Benjamin Herrenschmidtb...@kernel.crashing.org
Date:   Thu Dec 15 11:13:03 2011 +1100

  tty/serial/pmac_zilog: Fix suspend  resume

As this seemed to be an improbable result, I did the full test by checking out
the previous commit (43ca5d3). That resulted in a good result. Then I used
quilt to add commit a79dd5a as a patch and the fault returned. I then noticed
that you said in the commit message that I removed some code for handling
unexpected interrupt which should never be hit It appears that my box does
indeed hit such an unexpected interrupt.

I could always get rid of the fault by disabling CONFIG_SERIAL_PMACZILOG, but I
would like to fix the problem if possible.


Right, it should be fixed. I need to understand where the unexpected
interrupt comes from. Can you tell me (or remind me) what specific
machine model you are using ? Are you putting the console on the serial
port ?


It is a 15 Powerbook G4. I think they call it a Titanium. The console is not on 
a serial port. In fact, the reason that I did not think this patch was a problem 
is because the serial port does not appear to be connected to an external port. 
I was unaware that there was a serial port on the motherboard. There is a modem 
jack, but no 9 or 25-pin connectors that would indicate a standard serial port.


There are two stack dumps with the same trace. I posted the first, but the 
second is preceded by the lines


[c02adca0] pmz_interrupt
Disabling IRQ #23
ttyPZ1: IrDA setup for 57600 bps, dongle version: 4
ttyPZ1: IrDA setup for 115200 bps, dongle version: 4
irq23: nobody cared (try booting with the irqpoll option

As I am not sure how to put options in with yaboot, I have not tried that.

Larry


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Regression in 32-bit ppc kernel

[Larry Finger]

On 04/24/2012 11:11 PM, Benjamin Herrenschmidt wrote:

On Tue, 2012-04-24 at 21:37 -0500, Larry Finger wrote:

Somewhere between v3.2 and v3.3, the kernel in my Powerbook G4

started issuing

the following traceback on bootup:


Does it continue working afterward or not at all ?

Are you using the old IDE driver or the newer libata based

pata_macio ?

Yes, it finishes the boot, and appears to work correctly. If a device
is
missing, I do not know what it is.

I think I am using the old IDE driver.


Interesting. Does it make a difference if you switch to pata_macio ?


After a few tries, I managed to change over to pata_macio. Fortunately, most of 
the system used dev-by-id or UUID, thus most of the process was getting all the 
kernel pieces built in.


Unfortunately, the original problem remains. I have resumed the bisecting - only 
11 steps to go. I should have it by Friday! :)


Larry
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Regression in 32-bit ppc kernel

[Larry Finger]

Hi,

Somewhere between v3.2 and v3.3, the kernel in my Powerbook G4 started issuing 
the following traceback on bootup:


[   40.264006] irq 23: nobody cared (try booting with the irqpoll option)
[   40.264031] Call Trace:
[   40.264070] [dfff3f00] [c000984c] show_stack+0x7c/0x194 (unreliable)
[   40.264102] [dfff3f40] [c00a6840] __report_bad_irq+0x44/0xf4
[   40.264119] [dfff3f60] [c00a6adc] note_interrupt+0x1ec/0x2ac
[   40.264135] [dfff3f80] [c00a48a8] handle_irq_event_percpu+0x250/0x2b8
[   40.264152] [dfff3fd0] [c00a4944] handle_irq_event+0x34/0x54
[   40.264169] [dfff3fe0] [c00a7514] handle_fasteoi_irq+0xb4/0x124
[   40.264192] [dfff3ff0] [c000f5bc] call_handle_irq+0x18/0x28
[   40.264208] [dec85ce0] [c000719c] do_IRQ+0x114/0x1cc
[   40.264226] [dec85d10] [c0015868] ret_from_except+0x0/0x1c
[   40.264254] --- Exception: 501 at find_vma+0x10/0x80
[   40.264259] LR = do_page_fault+0x26c/0x6ac
[   40.264272] [dec85dd0] [c03f0128] do_page_fault+0x25c/0x6ac (unreliable)
[   40.264289] [dec85f40] [c00155e4] handle_page_fault+0xc/0x80
[   40.264327] --- Exception: 301 at 0x4800a174

The problem still exists in v3.4-rc3. I am currently doing a bisection of this 
problem, but it will take a long time to complete.


Note: IRQ 23 is not active in v3.2.

Thanks,

Larry

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Regression in 32-bit ppc kernel

[Larry Finger]

On 04/24/2012 06:53 PM, Benjamin Herrenschmidt wrote:

On Tue, 2012-04-24 at 17:58 -0500, Larry Finger wrote:

Hi,

Somewhere between v3.2 and v3.3, the kernel in my Powerbook G4 started issuing
the following traceback on bootup:


Does it continue working afterward or not at all ?

Are you using the old IDE driver or the newer libata based pata_macio ?


Yes, it finishes the boot, and appears to work correctly. If a device is 
missing, I do not know what it is.


I think I am using the old IDE driver.

Larry


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] ssb: pci: implement serdes workaround

[Larry Finger]

On 05/31/2011 04:37 AM, Andreas Schwab wrote:



Rafał Miłeckizajec5-re5jqeeqqe8avxtiumw...@public.gmane.org  writes:


+/**
+ * Workarounds.
+ **/
+
+static u8 ssb_pcicore_polarity_workaround(struct ssb_pcicore *pc)
+{
+   return (ssb_pcie_read(pc, 0x204)  0x10) ? 0xC0 : 0x80;
+}
+
+static void ssb_pcicore_serdes_workaround(struct ssb_pcicore *pc)
+{
+   const u8 serdes_pll_device = 0x1D;
+   const u8 serdes_rx_device = 0x1F;
+   u16 tmp;
+
+   ssb_pcie_mdio_write(pc, serdes_rx_device, 1 /* Control */,
+   ssb_pcicore_polarity_workaround(pc));
+   tmp = ssb_pcie_mdio_read(pc, serdes_pll_device, 1 /* Control */);
+   if (tmp  0x4000)
+   ssb_pcie_mdio_write(pc, serdes_pll_device, 1, tmp  ~0x4000);
+}


b43-pci-bridge 0001:10:12.0: enabling device (0004 -  0006)
ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x0D, vendor 0x4243)
ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x09, vendor 0x4243)
ssb: Core 2 found: PCI (cc 0x804, rev 0x0C, vendor 0x4243)
ssb: Core 3 found: PCMCIA (cc 0x80D, rev 0x07, vendor 0x4243)
Machine check in kernel mode.
Caused by (from SRR1=149030): Transfer error ack signal
Oops: Machine check, sig: 7 [#1]
PowerMac
Modules linked in: crc_itu_t ssb(+) snd_aoa_soundbus sungem sungem_phy
NIP: c0013324 LR: f2143e84 CTR: c001331c
REGS: c2ca5b80 TRAP: 0200   Not tainted  (3.0.0-rc1)
MSR: 00149030EE,ME,IR,DR   CR: 22004422  XER: 2000
TASK = ef9cef90[285] 'modprobe' THREAD: c2ca4000
GPR00: c2d1f87c c2ca5c30 ef9cef90 2381 0134 0204 0080 c2ca5bc8
GPR08: 04773e80 c2d1f87c  c001331c  1002833c f2141968 f214821c
GPR16: f21478b7 f2148250 f21478c0 f2147894 00100100 00200200 1310 c2d1fb2c
GPR24: f2147ee8    f2148204 c2d1f800 0134 c2d1f800
NIP [c0013324] ioread32+0x8/0x14
LR [f2143e84] ssb_pci_read32+0x4c/0x5c [ssb]
Call Trace:
[c2ca5c30] [c2d1f800] 0xc2d1f800 (unreliable)
[c2ca5c40] [f2146244] ssb_pcie_read+0x4c/0x54 [ssb]
[c2ca5c50] [f2146440] ssb_pcicore_serdes_workaround+0x1c/0x170 [ssb]
[c2ca5c70] [f2141c24] ssb_attach_queued_buses+0x94/0x288 [ssb]
[c2ca5cd0] [f2142078] ssb_bus_register+0xe4/0x160 [ssb]
[c2ca5cf0] [f2142134] ssb_bus_pcibus_register+0x40/0x80 [ssb]
[c2ca5d00] [f2144a60] ssb_pcihost_probe+0xd8/0x114 [ssb]
[c2ca5d30] [c018f6ac] local_pci_probe+0x28/0x38
[c2ca5d40] [c0190690] pci_device_probe+0x68/0x94
[c2ca5d70] [c02bc8a4] driver_probe_device+0xc8/0x170
[c2ca5d90] [c02bc9bc] __driver_attach+0x70/0x98
[c2ca5db0] [c02bb9ec] bus_for_each_dev+0x60/0x90
[c2ca5de0] [c02bc538] driver_attach+0x24/0x34
[c2ca5df0] [c02bc11c] bus_add_driver+0xbc/0x23c
[c2ca5e10] [c02bcfc8] driver_register+0xb8/0x144
[c2ca5e30] [c01908c8] __pci_register_driver+0x4c/0xc8
[c2ca5e50] [f214486c] ssb_pcihost_register+0x50/0x60 [ssb]
[c2ca5e60] [f214c094] b43_pci_ssb_bridge_init+0x18/0xbc [ssb]
[c2ca5e70] [f214c05c] ssb_modinit+0x5c/0x7c [ssb]
[c2ca5e80] [c00049d8] do_one_initcall+0xe0/0x1c0
[c2ca5eb0] [c005f7b0] sys_init_module+0x164c/0x1850
[c2ca5f40] [c0010cd8] ret_from_syscall+0x0/0x40
--- Exception: c01 at 0xff0b714
 LR = 0x100050f0
Instruction dump:
0c03 4c00012c 5463043e 4e800020 7c0004ac a063 0c03 4c00012c
5463043e 4e800020 7c0004ac 7c601c2c0c03  4c00012c 4e800020 7c0004ac
---[ end trace 9824f03a7724930b ]---


We get a PPC machine check if we try to read a non-existent register, whereas 
x86 returns all 1's on reads.


Obviously, this section needs to be conditionalized depending on revision info. 
From the traceback, it must be the serdes_pll_device read that failed. The 
specs say that should be a valid register for PCIe and PCI core rev 3 - 5. As 
the PCI core in this device is 0xc, should we be in this routine? See 
http://bcm-v4.sipsolutions.net/PCI-E.


Larry
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] ssb: pci: implement serdes workaround

[Larry Finger]

On 05/31/2011 10:54 AM, Andreas Schwab wrote:

Larry Fingerlarry.fin...@lwfinger.net  writes:


 From the traceback, it must be the serdes_pll_device read that failed.


Why not ssb_pcicore_polarity_workaround (note r4 == 0x134)?


Mainly because the last two steps in the traceback are

[c2ca5c40] [f2146244] ssb_pcie_read+0x4c/0x54 [ssb]
[c2ca5c50] [f2146440] ssb_pcicore_serdes_workaround+0x1c/0x170 [ssb]

Larry



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev