Description of problem: Booting Fedora-20110825-ppc64-netinst-respin.iso and using the following options boot: linux vnc=1 selinux=0 systemd.log_target=kmsg systemd.log_level=debug rd.break to get to a shell. Then configure and start the network manually. Once the network is up an running, I see the following error when I ssh into the box. [ 208.374103] ibmveth 30000004: DMA-API: device driver frees DMA memory with wrong function [device address=0x0000000003a901a6] [size=850 bytes] [mapped as single] [unmapped as page] [ 208.374148] ------------[ cut here ]------------ [ 208.374154] WARNING: at lib/dma-debug.c:829 [ 208.374159] Modules linked in: squashfs nls_utf8 ibmvscsic scsi_transport_srp ibmveth scsi_tgt [ 208.374180] NIP: c000000000343fb0 LR: c000000000343fac CTR: c000000000068324 [ 208.374189] REGS: c000000271d36a00 TRAP: 0700 Not tainted (3.0.1-5.fc16.kh.ppc64) [ 208.374197] MSR: 8000000000029032 <EE,ME,CE,IR,DR> CR: 48222482 XER: 00000009 [ 208.374216] TASK = c0000002715bce80[877] 'sshd' THREAD: c000000271d34000 CPU: 17 [ 208.374225] GPR00: c000000000343fac c000000271d36c80 c00000000141a7b8 00000000000000bb [ 208.374239] GPR04: 0000000000000001 c0000000000ac328 0000000000000000 0000000000000002 [ 208.374253] GPR08: 0000000000000000 c0000002715bce80 0000000000021638 0000000000000001 [ 208.374267] GPR12: 0000000084222482 c00000000ee5bf80 0000000000000000 c000000272bd1a60 [ 208.374281] GPR16: 0000000000000000 0000000000000001 0000000003a901a6 0000000000000020 [ 208.374294] GPR20: 0000000000000e00 0000000000000000 c00000040800a9a0 0000000003a901a6 [ 208.374308] GPR24: 0000000000000352 0000000000000000 0000000000000001 c00000000204a100 [ 208.374323] GPR28: c00000027604cf78 c000000271d36db0 c000000001399b88 c000000271d36c80 [ 208.374343] NIP [c000000000343fb0] .check_unmap+0x3dc/0x77c [ 208.374350] LR [c000000000343fac] .check_unmap+0x3d8/0x77c [ 208.374355] Call Trace: [ 208.374360] [c000000271d36c80] [c000000000343fac] .check_unmap+0x3d8/0x77c (unreliable) [ 208.374371] [c000000271d36d40] [c0000000003445a4] .debug_dma_unmap_page+0x78/0x80 [ 208.374384] [c000000271d36e80] [d0000000048ce194] .ibmveth_start_xmit+0x53c/0x67c [ibmveth] [ 208.374395] [c000000271d36fb0] [c0000000005854fc] .dev_hard_start_xmit+0x5a8/0x7e8 [ 208.374405] [c000000271d370b0] [c0000000005a6104] .sch_direct_xmit+0x7c/0x278 [ 208.374414] [c000000271d37160] [c000000000585e84] .dev_queue_xmit+0x748/0xa48 [ 208.374423] [c000000271d37220] [c000000000591d84] .neigh_resolve_output+0x434/0x498 [ 208.374433] [c000000271d372e0] [c0000000005c7674] .ip_finish_output+0x480/0x4bc [ 208.374442] [c000000271d37390] [c0000000005c8288] .ip_output+0x118/0x120 [ 208.374451] [c000000271d37420] [c0000000005c7838] .ip_local_out+0xa0/0xac [ 208.374459] [c000000271d374b0] [c0000000005c7c40] .ip_queue_xmit+0x3fc/0x480 [ 208.374469] [c000000271d37560] [c0000000005e0b34] .tcp_transmit_skb+0xb3c/0xb84 [ 208.374478] [c000000271d37650] [c0000000005e1a70] .tcp_write_xmit+0x8bc/0x9d8 [ 208.374488] [c000000271d37750] [c0000000005e1c40] .__tcp_push_pending_frames+0x4c/0xdc [ 208.374497] [c000000271d377f0] [c0000000005d2cbc] .tcp_sendmsg+0xaf4/0xcb0 [ 208.374506] [c000000271d37940] [c0000000005fa954] .inet_sendmsg+0x168/0x17c [ 208.374516] [c000000271d37a00] [c000000000569168] .sock_aio_write+0x138/0x150 [ 208.374527] [c000000271d37b40] [c0000000001cf95c] .do_sync_write+0xa8/0xe4 [ 208.374536] [c000000271d37cc0] [c0000000001d00cc] .vfs_write+0xe4/0x188 [ 208.374545] [c000000271d37d70] [c0000000001d03d8] .SyS_write+0x58/0x88 [ 208.374555] [c000000271d37e30] [c000000000009928] syscall_exit+0x0/0x40 [ 208.374562] Instruction dump: [ 208.374567] e97c001a e93e8048 e87e80e0 e8dd0028 e81d001a e8fd0030 796b1f24 78001f24 [ 208.374584] 7d09582a 7d29002a 4835d5b9 60000000 <0fe00000> 480000c4 2f800003 409e0100 [ 208.374601] ---[ end trace 2f6eefb6891385e8 ]--- [ 208.374607] Mapped at: [ 208.374610] [<c000000000344b90>] .debug_dma_map_page+0x9c/0x1c0 [ 208.374618] [<d0000000048cdf18>] .ibmveth_start_xmit+0x2c0/0x67c [ibmveth] [ 208.374627] [<c0000000005854fc>] .dev_hard_start_xmit+0x5a8/0x7e8 [ 208.374635] [<c0000000005a6104>] .sch_direct_xmit+0x7c/0x278 [ 208.374643] [<c000000000585e84>] .dev_queue_xmit+0x748/0xa48 [ 208.390554] systemd[1]: Received SIGCHLD from PID 877 (sshd). [ 208.390701] systemd[1]: Got SIGCHLD for process 877 (sshd) [ 208.390930] systemd[1]: Child 877 died (code=exited, status=255/n/a)
------- Comment From brking.com 2011-09-13 11:55 EDT------- A patch was sent upstream recently to address this: http://www.spinics.net/lists/netdev/msg174318.html
(In reply to comment #1) > ------- Comment From brking.com 2011-09-13 11:55 EDT------- > A patch was sent upstream recently to address this: > > http://www.spinics.net/lists/netdev/msg174318.html That's one in a set of 4. Are all 4 needed (arguably only the 1st three since Anton said 4/4 needs more review), or just the first?
------- Comment From brking.com 2011-09-14 12:01 EDT------- (In reply to comment #4) > (In reply to comment #1) > > A patch was sent upstream recently to address this: > > > > http://www.spinics.net/lists/netdev/msg174318.html > That's one in a set of 4. Are all 4 needed (arguably only the 1st three since > Anton said 4/4 needs more review), or just the first? Only the first one in the series is needed to fix this particular bug. However, the first three should all be good to pull in.
(In reply to comment #3) > ------- Comment From brking.com 2011-09-14 12:01 EDT------- > (In reply to comment #4) > > (In reply to comment #1) > > > A patch was sent upstream recently to address this: > > > > > > http://www.spinics.net/lists/netdev/msg174318.html > > That's one in a set of 4. Are all 4 needed (arguably only the 1st three since > > Anton said 4/4 needs more review), or just the first? > > Only the first one in the series is needed to fix this particular bug. However, > the first three should all be good to pull in. I've added the first three to the kernel. Will be in the next build.
Is this going to be in the 3.0.x tree? We are currently using kernel-3.0.1-5.fc16.kh.ppc64.
(In reply to comment #5) > Is this going to be in the 3.0.x tree? We are currently using > kernel-3.0.1-5.fc16.kh.ppc64. No. You're only using that kernel because of some of the other issues. F16 primary is shipping with 3.1, which is what the kernel package is currently at (3.1-rc6 to be exact) and ppc64 should follow suit soon as far as I understand things. I can't commit those to a 3.0 kernel on F16 anyway, since the F16 branch is well past that point now.
kernel-3.1.0-0.rc6.git0.3.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/kernel-3.1.0-0.rc6.git0.3.fc16
Package kernel-3.1.0-0.rc6.git0.3.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kernel-3.1.0-0.rc6.git0.3.fc16' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/kernel-3.1.0-0.rc6.git0.3.fc16 then log in and leave karma (feedback).
kernel-3.1.0-0.rc6.git0.3.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.