Modify

Opened 6 years ago

Closed 6 years ago

Last modified 4 years ago

#11020 closed defect (fixed)

alix2 - trace messages in dmesg on bootup

Reported by: openwrt@… Owned by: developers
Priority: normal Milestone: Barrier Breaker 14.07
Component: base system Version: Trunk
Keywords: Cc:

Description

I have a handful of Alix 2D13 platforms I've been running trunk images on for a while now. I noticed that it was recently kicked up to kernel 3.2.2. When it boots up now there's a number of traces from insmod. Attached is the complete output of the boot sequence.

The image was built clean, in a clean pull of trunk, using the default alix2 target. I've seen this on multiple alix boards, on images built on two completely separate build servers so I don't think its related to how I'm building the image.

If I rebuild the image, again, cleanly, but with "CONFIG_KERNEL_KALLSYMS=y " enabled, the trace errors go away.

This is 100% reproducible on three different alix boards with images from two different build machines.

Attachments (1)

alix-bootup.txt (44.8 KB) - added by openwrt@… 6 years ago.
dmesg output of boot captured via console cable

Download all attachments as: .zip

Change History (9)

Changed 6 years ago by openwrt@…

dmesg output of boot captured via console cable

comment:1 Changed 6 years ago by openwrt@…

Confirmed, this issue first appears when the kernel was bumped to 3.2.1 in this change set:
https://dev.openwrt.org/changeset/29981/trunk

29980, which still uses 2.6.39.4 works fine. 29981, which moves to 3.2.1 has the above mentioned traces in dmesg on boot up. Any suggestions on how to resolve?

comment:2 Changed 6 years ago by openwrt@…

I've been doing some more tests. This also happens on the generic x86 target if I bump the LINUX_VERSION up to 3.2.1 or 3.2.2, so it isn't alix specific. I tried decoding the Call Trace using the System.map file, however, the traces are coming from insmod / kernel modules which don't have addresses in System.map. At this point, I'm stuck and can't debug further without additional input / suggestions.

comment:3 Changed 6 years ago by openwrt@…

Built a test image on Fedora Core 16 today, in a brand new VM. Issue remains the same, Call Traces in dmesg on boot up. Problem is not specific to the alix2 target as originally thought. The generic x86 target has the same issue when using kernel version 3.2.2.

comment:4 follow-up: Changed 6 years ago by Ted Hess <thess@…>

Happened upon this problem a couple of days ago. I was glad to see here that it just wasn't my particular config. Anyway, I did conclude it was a toolchain problem and current have things working OK by using GCC 4.6.2 (non-linaro version), Binutils 2.22 and uClibc 0.9.33.

Toolchaing config located under "Advanced configuration options --> Toolchain Options"

comment:5 in reply to: ↑ 4 Changed 6 years ago by Ted Hess <thess@…>

Replying to Ted Hess <thess@…>:
Spoke too soon - I DID have "CONFIG_KERNEL_KALLSYMS=y" defined too. Maybe I'll try Binutils 2.21 ?

comment:6 Changed 6 years ago by openwrt@…

I haven't tried any toolchain changes beyond testing egblic, which didn't help. I did recently try kernel version up to 3.2.5 and found the problem still exists. Testing kernels 3.2.6 or higher will require refreshing the patches.

comment:7 Changed 6 years ago by nbd

  • Resolution set to fixed
  • Status changed from new to closed

fixed in r30813, make sure you run make target/linux/clean after updating.

comment:8 Changed 4 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.