lkml.org 
[lkml]   [2010]   [Jan]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] af_packet: Don't use skb after dev_queue_xmit()
On Thu, Jan 07, 2010 at 06:11:34PM -0500, Michael Breuer wrote:
> Results:
> * no MMAP, mtu=1500, neither alternative patch loaded: adapter crashed:
> Jan 7 15:44:23 mail kernel: DRHD: handling fault status reg 2
> Jan 7 15:44:23 mail kernel: DMAR:[DMA Read] Request device [06:00.0]
> fault addr fffb7bffe000
> Jan 7 15:44:23 mail kernel: DMAR:[fault reason 06] PTE Read access is
> not set
> Jan 7 15:44:23 mail kernel: sky2 0000:06:00.0: error interrupt
> status=0x80000000
> Jan 7 15:44:23 mail kernel: sky2 0000:06:00.0: PCI hardware error (0x2010)
> Jan 7 15:44:24 mail smbd[6572]: [2010/01/07 15:44:24, 0]
> lib/util_sock.c:539(read_fd_with_timeout)
> Jan 7 15:44:24 mail smbd[6572]: [2010/01/07 15:44:24, 0]
> lib/util_sock.c:1491(get_peer_addr_internal)
> Jan 7 15:44:24 mail smbd[6572]: getpeername failed. Error was
> Transport endpoint is not connected
> Jan 7 15:44:24 mail smbd[6572]: read_fd_with_timeout: client 0.0.0.0
> read error = Connection timed out.
> Jan 7 15:44:44 mail kernel: ------------[ cut here ]------------
> Jan 7 15:44:44 mail kernel: WARNING: at net/sched/sch_generic.c:261
> dev_watchdog+0xf3/0x164()
> Jan 7 15:44:44 mail kernel: Hardware name: System Product Name
> Jan 7 15:44:44 mail kernel: NETDEV WATCHDOG: eth0 (sky2): transmit
> queue 0 timed out
> Jan 7 15:44:44 mail kernel: Modules linked in: ip6table_filter
> ip6table_mangle ip6_tables ipt_MASQUERADE iptable_nat nf_nat
> iptable_mangle iptable_raw bridge stp appletalk psnap llc nfsd lockd
> nfs_acl auth_rpcgss exportfs hwmon_vid coretemp sunrpc acpi_cpufreq sit
> tunnel4 ipt_LOG nf_conntrack_netbios_ns nf_conntrack_ftp xt_DSCP xt_dscp
> xt_MARK nf_conntrack_ipv6 xt_multiport ipv6 dm_multipath kvm_intel kvm
> snd_hda_codec_analog snd_ens1371 gameport snd_rawmidi snd_ac97_codec
> snd_hda_intel snd_hda_codec ac97_bus snd_hwdep snd_seq snd_seq_device
> snd_pcm gspca_spca505 gspca_main firewire_ohci videodev v4l1_compat
> firewire_core pcspkr v4l2_compat_ioctl32 snd_timer iTCO_wdt i2c_i801
> crc_itu_t iTCO_vendor_support snd soundcore snd_page_alloc sky2 wmi
> asus_atk0110 hwmon fbcon tileblit font bitblit softcursor raid456
> async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx
> raid1 ata_generic pata_acpi pata_marvell nouveau ttm drm_kms_helper drm
> agpgart fb i2c_algo_bit cfbcopyarea i2c_core cfbimgblt cfbfil
> Jan 7 15:44:44 mail kernel: lrect [last unloaded: microcode]
> Jan 7 15:44:44 mail kernel: Pid: 0, comm: swapper Tainted: G W

BTW, was there any other oops saved before this one?

...
> --- adapter dead after this --- rebooted.
> * no MMAP; alternative 1 patch, mtu=1500; no errors; sustained transfer
> rates about 25% lower than what I saw with mmap enabled...(before MMAP
> enabled crashed).

?? Read below...

> * no MMAP mtu=9000; ran ok at low transfer rates - when high rates
> kicked in, got the sky2 interrupt error & things went south:
> Jan 7 15:09:28 mail kernel: sky2 0000:06:00.0: error interrupt
> status=0x40000008
> Jan 7 15:09:28 mail kernel: sky2 0000:06:00.0: error interrupt
> status=0x40000008
> After this, remote connections broke and I rebooted... decided to rerun
> w/o MMAP again before going back to MMAP and trying those other sky2
> options...
> * Retest of no MMAP + Alternative 1 - just to confirm consistency.
> Worked - no errors. Only version so far that allows the win7 backup to
> complete.

??? Hmm... Alternative 1 or 2 doesn't even compile into when no MMAP,
so it definitely needs re-retesting ;-)

> * MMAP + NO DMAR + disable_msi=1... also works w/o errors... leaving
> this one running for a while - also completed a backup successfully.
> Fastest of the lot... about 3x faster than any other version, working or
> not.

Very interesting. It would be nice to give it a really long try, and
if still true, try MMAP + NO DMAR only.

>
> I'm leaving this one running for now. Not retesting jumbo for now. Be
> happy to help dig further.
>
> Tentative recommendations:
>
> 1) The af alternative patch seems rather necessary. First alternative
> seems to be working, I'd suggest that be submitted and backported to
> 2.6.32.
> 2) Steven's pskb_may_pull patch also ought to be included and backported.
> 3) Jumbo frame support for yukon2 should probably be disabled until/if
> fixed.
> 4) When possible I'll test dmar and disable_msi, and no dmar and no
> disable_msi. When I first hit issues, I was running without DMAR, but
> also without the above patches. I suppose the non-working permutations
> need to be either fixed or invalidated (or well documented).
> 5) It would be nice if someone with comparable hardware could reproduce
> these issues. FWIW, I can only recreate the crash running windows backup
> to a cifs share. Copying large files doesn't seem to do it. Could also
> be some other interaction going on here that perhaps others aren't
> running - would be happy to compare notes.
>
> Notes:
> This *could* be coincidental, but maybe not...
> With MMAP+NO DMAR + disable_msi there are far fewer ... actually almost
> no... bind error reports... and no bind format error messages. With
> NOMMAP and alternative one there are a few more bind error messages and
> one format error message during the several hours that version was up.
> All other configurations going back perhaps for two weeks have
> significantly more bind error reports - and all versions show increasing
> frequency of bind format errors (IPV6 only) in the roughly 10-15 minutes
> preceding the lockup/crash/interrupt error messages. There are none
> immediately preceding any crash, but perhaps there is some correlation
> between the network errors and bind ipv6 packets.

OK, for now let's make sure this MMAP + NO DMAR + disable_msi is
really really working.

Thanks,
Jarek P.


\
 
 \ /
  Last update: 2010-01-08 08:49    [W:0.237 / U:3.904 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site