Bug 1559088
| Summary: | broadcom tigon tg3 taints kernel? | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | lejeczek <peljasz> |
| Component: | kernel | Assignee: | Jonathan Toppins <jtoppins> |
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 27 | CC: | airlied, bskeggs, ewk, hdegoede, ichavero, itamar, jarodwilson, jforbes, jglisse, john.j5live, jonathan, josef, jtoppins, kernel-maint, linville, mchehab, mjg59, nhorman, steved, victor.andreasson |
| Target Milestone: | --- | Flags: | jforbes:
needinfo?
|
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-08-29 15:13:13 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
lejeczek
2018-03-21 16:42:11 UTC
The taint here is because this isn't the first warning. It is there because something happened earlier, and it is possible that whatever happened there could be causing further (possibly different) issues. It is best if you can find the first trace after a boot (it would not be tainted). So it seem like my other 1322761 bug report. I find these: ... [ 0.104486] WARNING: CPU: 1 PID: 1 at drivers/i2c/busses/i2c-designware-common.c:184 i2c_dw_clk_rate +0x16/0x20 [ 0.104488] Modules linked in: [ 0.104492] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.16.0-0.rc4.git0.1.fc28.x86_64 #1 [ 0.104494] Hardware name: HP HP EliteBook 745 G3/807E, BIOS N73 Ver. 01.22 12/11/2017 [ 0.104496] RIP: 0010:i2c_dw_clk_rate+0x16/0x20 [ 0.104497] RSP: 0018:ffffb9a90006fc80 EFLAGS: 00010246 [ 0.104498] RAX: 0000000000000000 RBX: ffff8d112c44d828 RCX: 0000000000000000 [ 0.104499] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8d112c44d828 [ 0.104499] RBP: 0000000000000000 R08: 00000000000250a0 R09: ffffffff85510049 [ 0.104500] R10: fffff497d0b10900 R11: 0000000000000e80 R12: 000000000000012c [ 0.104501] R13: 000000000000012c R14: 0000000000000000 R15: ffff8d112cbac810 [ 0.104502] FS: 0000000000000000(0000) GS:ffff8d113ec80000(0000) knlGS:0000000000000000 [ 0.104503] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.104504] CR2: ffffb9a901a84000 CR3: 000000032a20a000 CR4: 00000000001406e0 [ 0.104505] Call Trace: [ 0.104551] i2c_dw_init_master+0x20b/0x3f0 [ 0.104556] i2c_dw_probe+0x51/0x270 [ 0.104558] dw_i2c_plat_probe+0x324/0x720 [ 0.104563] platform_drv_probe+0x38/0x90 [ 0.104567] driver_probe_device+0x2b9/0x460 [ 0.104570] ? __driver_attach+0xb6/0xe0 [ 0.104572] ? driver_probe_device+0x460/0x460 [ 0.104581] ? bus_for_each_dev+0x76/0xc0 [ 0.104585] ? klist_add_tail+0x3b/0x60 [ 0.104587] ? bus_add_driver+0x152/0x230 [ 0.104591] ? do_early_param+0x8e/0x8e [ 0.104593] ? driver_register+0x6b/0xb0 [ 0.104597] ? trace_event_define_fields_smbus_read+0x10e/0x10e [ 0.104601] ? do_one_initcall+0x48/0x13b [ 0.104603] ? do_early_param+0x8e/0x8e [ 0.104605] ? kernel_init_freeable+0x18d/0x231 [ 0.104609] ? rest_init+0xaa/0xaa [ 0.104611] ? kernel_init+0xa/0x100 [ 0.104627] ? ret_from_fork+0x22/0x40 [ 0.104629] Code: c7 c6 c1 df 13 86 41 5c 48 0f 44 d0 41 5d e9 12 5c ed ff 66 90 0f 1f 44 00 00 48 8 b 47 48 48 85 c0 74 08 e8 4d 89 53 00 89 c0 c3 <0f> 0b c3 0f 1f 80 00 00 00 00 0f 1f 44 00 00 48 8b 87 50 05 00 [ 0.104663] ---[ end trace 12e58f5fcd730097 ]--- many thanks, L. I thought I should add - would be great if someone could look into it. This has been harassing use for several years, these random taints with wired connections go down. Many thanks, L. This isn't a taint from a wired connection, its the result of a warning issued by your i2c controller indicating that a method to retrieve the bus clock rate was never assigned. That appears to be a sign that something failed silently during the i2c bus initialization. It likely has nothing to do with your tg3 issue, but you likely want to file an upstream bug so the maintainers of the designware i2c driver can look at it. The tg3 issue is a queue timeout, which means that the hardware stopped processing tx packets, and eventually the kernels send queue for that device backed up to the point that we noticed it. thats usually indicative of a firmware issue, as the tg3 driver is pretty mature. Have you confirmed that you have the latest firmware on that NIC? I know I've flashed BIOS to the latest. I'll investigate firmware but "upstream" - how do I do that? Where do I go? Do they have a linux tool to flash a firmware? I'm sroogling but cannot find anything, ogh. (In reply to lejeczek from comment #5) > I know I've flashed BIOS to the latest. I'll investigate firmware but > "upstream" - how do I do that? Where do I go? https://www.kernel.org/doc/html/v4.10/admin-guide/reporting-bugs.html (In reply to lejeczek from comment #6) > Do they have a linux tool to flash a firmware? > I'm sroogling but cannot find anything, ogh. tigon devices get their firmware from the linux-firmware[1] package. The latest firmware can be found here[2]. [1] https://apps.fedoraproject.org/packages/linux-firmware [2] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/tigon *********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 27 kernel bugs. Fedora 27 has now been rebased to 4.17.7-100.fc27. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 28, and are still experiencing this issue, please change the version to Fedora 28. If you experience different issues, please open a new bug report for those. *********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 5 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously. |