Messages in this thread | | | Date | Sun, 17 Jan 2010 23:17:46 +0100 | From | Jarek Poplawski <> | Subject | Re: [PATCH] af_packet: Don't use skb after dev_queue_xmit() |
| |
On Sun, Jan 17, 2010 at 11:26:46AM -0500, Michael Breuer wrote: > On 01/13/2010 04:16 PM, Michael Breuer wrote: > >On 1/13/2010 4:09 PM, Jarek Poplawski wrote: > >>On Wed, Jan 13, 2010 at 03:39:37PM -0500, Michael Breuer wrote: > >>>Just an FYI - 2.6.32.3 with alt 3 af_packet patch& sky2 > >>>pskb_may_pull runs OK with DMAR (re)enabled and msi enabled. > >>Hmm... What a pity! It was such a useful debugging tool for > >>networking ;-) BTW, I'm not sure if "runs OK" means with or without > >>those DHCP drops& large packets you described. > >> > >>Thanks, > >>Jarek P. > >As of now, no errors even when blasting traffic & forcing dhcp > >packets as before. I haven't tried putting mtu back to 9k yet. OK > >means that there are no obvious differences in behavior with or > >without DMAR all else being equal. > > > >There were some updates made to stable that could have fixed this > >- I'd guess intel_iommu fixes helped. > > > >If it helps, I'm still getting one error without DMAR enabled - at > >startup, there's a DMA sync oops - mismatch of 72 bytes coming > >from sky2. That oops was posted previously - with DMAR (re) > >enabled, there's no related oops. > Update: after leaving the system up for a few days, I hit the DMAR > error again.
My proposal is to send some summary as a new thread, with dmar in the subject, and cc-ed dmar maintainers.
> This happened during a scheduled backup from my win7 > box. A reboot was required to re-enable eth0. After the error, eth0 > was receiving, but was unable to transmit. For example, the log > reported arp bogons; DHCPINFORM/ACK sequences (where the ACK that > was logged was not transmitted), etc. The log was filled with sky2 > eth0: tx timeout messages; as well as disable/enable of eth0. > > I attempted to get things up again without a reboot, but failed. > Even rmmod & insmod did not fix whatever was broken on the TX side. > > Note that this is similar to the earlier sky2 errors I had under > load with the variety of patches, and with or without DMAR enabled. > Just took way longer this time. Note that eth1 remained functional. > > Unfortunately, with the latest set of patches installed, this is no > longer reproducible at will. I'd guess therefore that the patches > narrowed some hole, but didn't close it.
It would be nice to name those patches each time. Anyway, try this again without DMAR.
Thanks, Jarek P.
> > Relevant log portions: > > Jan 17 05:29:49 mail dhcpd: DHCPREQUEST for 10.0.0.32 from > 00:26:bb:aa:15:10 (mbitouch) via eth0 > Jan 17 05:29:49 mail dhcpd: DHCPACK on 10.0.0.32 to > 00:26:bb:aa:15:10 (mbitouch) via eth0 > Jan 17 05:36:49 mail kernel: DRHD: handling fault status reg 2 > Jan 17 05:36:49 mail kernel: DMAR:[DMA Read] Request device > [06:00.0] fault addr ffe7957fe000 > Jan 17 05:36:49 mail kernel: DMAR:[fault reason 06] PTE Read access > is not set > Jan 17 05:36:49 mail kernel: sky2 0000:06:00.0: error interrupt > status=0xc0000000 > Jan 17 05:36:49 mail kernel: sky2 0000:06:00.0: PCI hardware error (0x2010) ...
| |