Skip to content

build of rpi-5.4.y (5.4.58) fails on 32 bit #3788

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ncopa opened this issue Aug 13, 2020 · 3 comments
Closed

build of rpi-5.4.y (5.4.58) fails on 32 bit #3788

ncopa opened this issue Aug 13, 2020 · 3 comments

Comments

@ncopa
Copy link
Contributor

ncopa commented Aug 13, 2020

Describe the bug
Build rpi-5.4.y (commit a682509) with 32bit config fails.

To reproduce
build the rpi-5.4.y kernel with either bcmrpi_defconfig bcm2709_defconfig or bcm2711_defconfig (not sure exactly which one triggered it)

Expected behaviour
build success

Actual behaviour
build fails:

/home/ncopa/aports/main/linux-rpi/src/linux-5.4/drivers/net/wireless/ath/ath9k/hif_usb.c: In function 'ath9k_hif_usb_reg
_in_cb':                                                    
/home/ncopa/aports/main/linux-rpi/src/linux-5.4/drivers/net/wireless/ath/ath9k/hif_usb.c:735:3: error: 'rx_buf' undeclar
ed (first use in this function); did you mean 'tx_buf'?
  735 |   rx_buf->skb = nskb;                               
      |   ^~~~~~                                            
      |   tx_buf                                            
/home/ncopa/aports/main/linux-rpi/src/linux-5.4/drivers/net/wireless/ath/ath9k/hif_usb.c:735:3: note: each undeclared id
entifier is reported only once for each function it appears in

System
Copy and paste the results of the raspinfo command in to this section. Alternatively, copy and paste a pastebin link, or add answers to the following questions:

  • Which model of Raspberry Pi? e.g. Pi3B+, PiZeroW
  • Which OS and version (cat /etc/rpi-issue)?
  • Which firmware version (vcgencmd version)?
  • Which kernel version (uname -a)?

This build happens on an arm server from packet net. (but its irrelevant)

$ uname -a
Linux ncopa-edge-armv7 5.4.34-0-lts #1-Alpine SMP Wed, 22 Apr 2020 19:26:07 UTC armv8l Linux

Logs

/home/ncopa/aports/main/linux-rpi/src/linux-5.4/drivers/net/wireless/ath/ath9k/hif_usb.c: In function 'ath9k_hif_usb_reg
_in_cb':                                                    
/home/ncopa/aports/main/linux-rpi/src/linux-5.4/drivers/net/wireless/ath/ath9k/hif_usb.c:735:3: error: 'rx_buf' undeclar
ed (first use in this function); did you mean 'tx_buf'?
  735 |   rx_buf->skb = nskb;                               
      |   ^~~~~~                                            
      |   tx_buf                                            
/home/ncopa/aports/main/linux-rpi/src/linux-5.4/drivers/net/wireless/ath/ath9k/hif_usb.c:735:3: note: each undeclared id
entifier is reported only once for each function it appears in
  LD [M]  drivers/media/usb/gspca/gspca_finepix.o

Additional context
I believe commit e6eb815 needs to be cherry-picked to rpi-5.4.y.

What happened upstream in linux-5.4.y was:

  • commit b5c8896 Fix general protection fault in ath9k_hif_usb_rx_cb
  • this apparently caused problems so it got reverted in 5a046d7
  • a fix those problems was made so the problematic commit was re-applied in e6eb815.
  • The fix for the problems was applied on top in commit c15d59b ath9k: Fix regression with Atheros 9271

I think the rpi branch has both the revert commit (5a046d7) and the fix (c15d59b ath9k: Fix regression with Atheros 9271) for the reverted commit but not the re-applied e6eb815.

To get a clear view of the history:

git log origin/linux-5.4.y -- drivers/net/wireless/ath/ath9k/hif_usb.
@pelwell
Copy link
Contributor

pelwell commented Aug 13, 2020

Duplicate of #3786.

@pelwell pelwell closed this as completed Aug 13, 2020
@ncopa
Copy link
Contributor Author

ncopa commented Aug 13, 2020

Duplicate of #3786.

The second problem (with lan78xx.c which i have delete now) was a duplicate, but the original problem with drivers/net/wireless/ath/ath9k/hif_usb.c is not mentioned in #3786. They will bump into the ath9k error (this issue) once they solve the lan78xx.c problem.

@pelwell
Copy link
Contributor

pelwell commented Aug 13, 2020

They're both trivial problems - there's almost more work updating the issues, so I'd rather only do it once.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants