Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering

[Mark Atkinson-3]

The following reply was made to PR kern/124127; it has been noted by GNATS.

From: Mark Atkinson <atkin901@...>
To: bug-followup@...
Cc:  
Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering
Date: Mon, 19 Oct 2009 08:03:58 -0700 (PDT)

 I am also see this problem on the following, however this on -current
 built on Aug 25, 2009, so I'm updating to the latest to retest.
 
 watchdog timeout (missed Tx interrupts) -- recovering
 
 e1000phy0: <Marvell 88E1111 Gigabit PHY> PHY 0 on miibus0
 e1000phy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
 
 mskc0@pci0:2:0:0:       class=0x020000 card=0x81421043 chip=0x436211ab rev=0x15 hdr=0x00
     vendor     = 'Marvell Semiconductor (Was: Galileo Technology Ltd)'
     device     = 'Marvell Yukon 88E8053 PCI-E Gigabit Ethernet Controller (88E8053)'
     class      = network
     subclass   = ethernet
 
 
 This is an ASUS P5GD2 Deluxe.
 
 Mark Atkinson
 atkin901@...
 (!wired)?(coffee++):(wired);
 
 
 
       
_______________________________________________
freebsd-net@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@..."

[Mark Atkinson-3]

The following reply was made to PR kern/124127; it has been noted by GNATS.

From: Mark Atkinson <atkin901@...>
To: freebsd prs <bug-followup@...>
Cc:  
Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering
Date: Sun, 25 Oct 2009 12:55:38 -0700 (PDT)

 After a week on a Oct 19th 2009 built kernel, I got
 hit with the watchdog again, so I applied the patch.
 
 The msk interface was non functional (came up but was
 unable to pass traffic) after applying the
 patch, so I booted back to the unpatched kernel.
 
 
  Mark Atkinson
 atkin901@...
 (!wired)?(coffee++):(wired);
 
 
 
       
_______________________________________________
freebsd-net@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@..."

[Mark Atkinson-3]

The following reply was made to PR kern/124127; it has been noted by GNATS.

From: Mark Atkinson <atkin901@...>
To: freebsd prs <bug-followup@...>
Cc:  
Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering
Date: Wed, 28 Oct 2009 17:03:52 -0700 (PDT)

 =0A=0AOn the unpatched -current kernel, built=0A=0AFreeBSD hellfire.filamen=
 t.org 9.0-CURRENT FreeBSD 9.0-CURRENT #14: Mon Oct 19 09:12:03 PDT 2009 =0A=
 =0AI recieved the following panic today related to this:=0A=0AFatal trap 12=
 : page fault while in kernel mode=0Acpuid =3D 0; apic id =3D 00=0Afault vir=
 tual address   =3D 0xdeadc10a=0Afault code              =3D supervisor read=
 , page not present=0Ainstruction pointer     =3D 0x20:0xc0987410=0Astack po=
 inter           =3D 0x28:0xd533dac0=0Aframe pointer           =3D 0x28:0xd5=
 33dae8=0Acode segment            =3D base 0x0, limit 0xfffff, type 0x1b=0A =
                        =3D DPL 0, pres 1, def32 1, gran 1=0Aprocessor eflag=
 s        =3D interrupt enabled, resume, IOPL =3D 0=0Acurrent process       =
   =3D 0 (mskc0 taskq)=0APhysical memory: 495 MB=0ADumping 132 MB: 117 101 8=
 5 69 53 37 21 5=0A=0AReading symbols from /boot/kernel/linux.ko...Reading s=
 ymbols from /boot/kernel/linux.ko.symbols...done.=0Adone.=0ALoaded symbols =
 for /boot/kernel/linux.ko=0A#0  0xc08907a9 in doadump () at /usr/src/sys/ke=
 rn/kern_shutdown.c:254=0A254     }=0A(kgdb) bt=0A#0  0xc08907a9 in doadump =
 () at /usr/src/sys/kern/kern_shutdown.c:254=0A#1  0xc04f7e37 in db_fncall (=
 dummy1=3D-1067299898, dummy2=3D0, dummy3=3D-718022488,=0A    dummy4=3D0xd53=
 3d898 "\200%t=C3") at /usr/src/sys/ddb/db_command.c:548=0A#2  0xc04f8214 in=
  db_command (last_cmdp=3D0xc0da059c, cmd_table=3D0x0, dopager=3D1)=0A    at=
  /usr/src/sys/ddb/db_command.c:445=0A#3  0xc04f8352 in db_command_loop () a=
 t /usr/src/sys/ddb/db_command.c:498=0A#4  0xc04fa05e in db_trap (type=3D12,=
  code=3D0) at /usr/src/sys/ddb/db_main.c:229=0A#5  0xc08bf2d2 in kdb_reente=
 r () at /usr/src/sys/kern/subr_kdb.c:398=0A#6  0xc0ba9b62 in trap_fatal (fr=
 ame=3D0x1, eva=3D3735929098)=0A    at /usr/src/sys/i386/i386/trap.c:938=0A#=
 7  0xc0baa483 in trap (frame=3D0xd533da80) at /usr/src/sys/i386/i386/trap.c=
 :339=0A#8  0xc0b8e4ab in Xlcall_syscall () at /usr/src/sys/i386/i386/except=
 ion.s:241=0A#9  0xc0987410 in in_lltable_lookup (llt=3D0xc39e1000, flags=3D=
 Variable "flags" is not available.=0A)=0A    at /usr/src/sys/netinet/in.c:1=
 380=0A#10 0xc0982470 in arpintr (m=3D0xc3baeb00) at /usr/src/sys/netinet/if=
 _ether.c:642=0A#11 0xc094227a in netisr_dispatch_src (proto=3D7, source=3D0=
 , m=3D0xc0de)=0A    at /usr/src/sys/net/netisr.c:932=0A#12 0xc09424dd in ne=
 tisr_unregister (nhp=3D0xc0de)=0A    at /usr/src/sys/net/netisr.c:583=0A#13=
  0xc093ac69 in ether_demux (ifp=3D0x0, m=3D0xc3baeb00)=0A    at /usr/src/sy=
 s/net/if_ethersubr.c:911=0A#14 0xc093b1ce in ether_output (ifp=3D0xc36ad400=
 , m=3D0xc3baeb00, dst=3D0xc0c55c27,=0A    ro=3D0x301010a) at /usr/src/sys/n=
 et/if_ethersubr.c:181=0A---Type <return> to continue, or q <return> to quit=
 ---=0A#15 0xc070b032 in msk_handle_events (sc=3D0xc3686c00)=0A    at /usr/s=
 rc/sys/dev/msk/if_msk.c:3048=0A#16 0xc070b828 in msk_int_task (arg=3D0xc368=
 6c00, pending=3D1)=0A    at /usr/src/sys/dev/msk/if_msk.c:3625=0A#17 0xc08c=
 ac8c in taskqueue_run (queue=3D0xc36bf380)=0A    at /usr/src/sys/kern/subr_=
 taskqueue.c:72=0A#18 0xc08cadcc in taskqueue_thread_loop (arg=3D0xc3686c8c)=
 =0A    at /usr/src/sys/kern/subr_taskqueue.c:90=0A#19 0xc0869271 in fork_ex=
 it (callout=3D0xc08cad67 <taskqueue_thread_loop+64>,=0A    arg=3D0xc3686c8c=
 , frame=3D0xd533dd38) at /usr/src/sys/kern/kern_fork.c:854=0A#20 0xc0b8e520=
  in Xatpic_intr0 () at atpic_vector.s:62=0A#21 0x00000000 in ?? ()=0A=0A=0A=
       
_______________________________________________
freebsd-net@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@..."

[Mark Atkinson-3]

Wow, not sure what to blame for that charset nightmare.  Apologies.
Here's the original message:

On the unpatched -current kernel, built

FreeBSD hellfire.filament.org 9.0-CURRENT FreeBSD 9.0-CURRENT #14: Mon
Oct 19 09:12:03 PDT 2009

I recieved the following panic today related to this:

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address  = 0xdeadc10a
fault code              = supervisor read, page not present
instruction pointer    = 0x20:0xc0987410
stack pointer          = 0x28:0xd533dac0
frame pointer          = 0x28:0xd533dae8
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process        = 0 (mskc0 taskq)
Physical memory: 495 MB
Dumping 132 MB: 117 101 85 69 53 37 21 5

Reading symbols from /boot/kernel/linux.ko...Reading symbols from
/boot/kernel/linux.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/linux.ko
#0  0xc08907a9 in doadump () at /usr/src/sys/kern/kern_shutdown.c:254
254    }
(kgdb) bt
#0  0xc08907a9 in doadump () at /usr/src/sys/kern/kern_shutdown.c:254
#1  0xc04f7e37 in db_fncall (dummy1=-1067299898, dummy2=0,
dummy3=-718022488,
    dummy4=0xd533d898 "\200%tÃ") at /usr/src/sys/ddb/db_command.c:548
#2  0xc04f8214 in db_command (last_cmdp=0xc0da059c, cmd_table=0x0,
dopager=1)
    at /usr/src/sys/ddb/db_command.c:445
#3  0xc04f8352 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498
#4  0xc04fa05e in db_trap (type=12, code=0) at
/usr/src/sys/ddb/db_main.c:229
#5  0xc08bf2d2 in kdb_reenter () at /usr/src/sys/kern/subr_kdb.c:398
#6  0xc0ba9b62 in trap_fatal (frame=0x1, eva=3735929098)
    at /usr/src/sys/i386/i386/trap.c:938
#7  0xc0baa483 in trap (frame=0xd533da80) at
/usr/src/sys/i386/i386/trap.c:339
#8  0xc0b8e4ab in Xlcall_syscall () at
/usr/src/sys/i386/i386/exception.s:241
#9  0xc0987410 in in_lltable_lookup (llt=0xc39e1000, flags=Variable
"flags" is not available.
)
    at /usr/src/sys/netinet/in.c:1380
#10 0xc0982470 in arpintr (m=0xc3baeb00) at
/usr/src/sys/netinet/if_ether.c:642
#11 0xc094227a in netisr_dispatch_src (proto=7, source=0, m=0xc0de)
    at /usr/src/sys/net/netisr.c:932
#12 0xc09424dd in netisr_unregister (nhp=0xc0de)
    at /usr/src/sys/net/netisr.c:583
#13 0xc093ac69 in ether_demux (ifp=0x0, m=0xc3baeb00)
    at /usr/src/sys/net/if_ethersubr.c:911
#14 0xc093b1ce in ether_output (ifp=0xc36ad400, m=0xc3baeb00,
dst=0xc0c55c27,
    ro=0x301010a) at /usr/src/sys/net/if_ethersubr.c:181
---Type <return> to continue, or q <return> to quit---
#15 0xc070b032 in msk_handle_events (sc=0xc3686c00)
    at /usr/src/sys/dev/msk/if_msk.c:3048
#16 0xc070b828 in msk_int_task (arg=0xc3686c00, pending=1)
    at /usr/src/sys/dev/msk/if_msk.c:3625
#17 0xc08cac8c in taskqueue_run (queue=0xc36bf380)
    at /usr/src/sys/kern/subr_taskqueue.c:72
#18 0xc08cadcc in taskqueue_thread_loop (arg=0xc3686c8c)
    at /usr/src/sys/kern/subr_taskqueue.c:90
#19 0xc0869271 in fork_exit (callout=0xc08cad67 <taskqueue_thread_loop+64>,
    arg=0xc3686c8c, frame=0xd533dd38) at /usr/src/sys/kern/kern_fork.c:854
#20 0xc0b8e520 in Xatpic_intr0 () at atpic_vector.s:62
#21 0x00000000 in ?? ()




Mark Atkinson wrote:
> The following reply was made to PR kern/124127; it has been noted by GNATS.
>
> From: Mark Atkinson <atkin901@...>
> To: freebsd prs <bug-followup@...>
> Cc:  
> Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering
> Date: Wed, 28 Oct 2009 17:03:52 -0700 (PDT)

_______________________________________________
freebsd-net@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@..."

[Pyun YongHyeon]

On Thu, Oct 29, 2009 at 06:52:34AM -0700, Mark Atkinson wrote:

> Wow, not sure what to blame for that charset nightmare.  Apologies.
> Here's the original message:
>
> On the unpatched -current kernel, built
>
> FreeBSD hellfire.filament.org 9.0-CURRENT FreeBSD 9.0-CURRENT #14: Mon
> Oct 19 09:12:03 PDT 2009
>
> I recieved the following panic today related to this:
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address  = 0xdeadc10a
> fault code              = supervisor read, page not present
> instruction pointer    = 0x20:0xc0987410
> stack pointer          = 0x28:0xd533dac0
> frame pointer          = 0x28:0xd533dae8
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, def32 1, gran 1
> processor eflags        = interrupt enabled, resume, IOPL = 0
> current process        = 0 (mskc0 taskq)
> Physical memory: 495 MB
> Dumping 132 MB: 117 101 85 69 53 37 21 5
>
> Reading symbols from /boot/kernel/linux.ko...Reading symbols from
> /boot/kernel/linux.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/linux.ko
> #0  0xc08907a9 in doadump () at /usr/src/sys/kern/kern_shutdown.c:254
> 254    }
> (kgdb) bt
> #0  0xc08907a9 in doadump () at /usr/src/sys/kern/kern_shutdown.c:254
> #1  0xc04f7e37 in db_fncall (dummy1=-1067299898, dummy2=0,
> dummy3=-718022488,
>     dummy4=0xd533d898 "\200%t?") at /usr/src/sys/ddb/db_command.c:548
> #2  0xc04f8214 in db_command (last_cmdp=0xc0da059c, cmd_table=0x0,
> dopager=1)
>     at /usr/src/sys/ddb/db_command.c:445
> #3  0xc04f8352 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498
> #4  0xc04fa05e in db_trap (type=12, code=0) at
> /usr/src/sys/ddb/db_main.c:229
> #5  0xc08bf2d2 in kdb_reenter () at /usr/src/sys/kern/subr_kdb.c:398
> #6  0xc0ba9b62 in trap_fatal (frame=0x1, eva=3735929098)
>     at /usr/src/sys/i386/i386/trap.c:938
> #7  0xc0baa483 in trap (frame=0xd533da80) at
> /usr/src/sys/i386/i386/trap.c:339
> #8  0xc0b8e4ab in Xlcall_syscall () at
> /usr/src/sys/i386/i386/exception.s:241
> #9  0xc0987410 in in_lltable_lookup (llt=0xc39e1000, flags=Variable
> "flags" is not available.
> )
>     at /usr/src/sys/netinet/in.c:1380
> #10 0xc0982470 in arpintr (m=0xc3baeb00) at
> /usr/src/sys/netinet/if_ether.c:642
> #11 0xc094227a in netisr_dispatch_src (proto=7, source=0, m=0xc0de)
>     at /usr/src/sys/net/netisr.c:932
> #12 0xc09424dd in netisr_unregister (nhp=0xc0de)
>     at /usr/src/sys/net/netisr.c:583
> #13 0xc093ac69 in ether_demux (ifp=0x0, m=0xc3baeb00)
>     at /usr/src/sys/net/if_ethersubr.c:911
> #14 0xc093b1ce in ether_output (ifp=0xc36ad400, m=0xc3baeb00,
> dst=0xc0c55c27,
>     ro=0x301010a) at /usr/src/sys/net/if_ethersubr.c:181
> ---Type <return> to continue, or q <return> to quit---
> #15 0xc070b032 in msk_handle_events (sc=0xc3686c00)
>     at /usr/src/sys/dev/msk/if_msk.c:3048
> #16 0xc070b828 in msk_int_task (arg=0xc3686c00, pending=1)
>     at /usr/src/sys/dev/msk/if_msk.c:3625
> #17 0xc08cac8c in taskqueue_run (queue=0xc36bf380)
>     at /usr/src/sys/kern/subr_taskqueue.c:72
> #18 0xc08cadcc in taskqueue_thread_loop (arg=0xc3686c8c)
>     at /usr/src/sys/kern/subr_taskqueue.c:90
> #19 0xc0869271 in fork_exit (callout=0xc08cad67 <taskqueue_thread_loop+64>,
>     arg=0xc3686c8c, frame=0xd533dd38) at /usr/src/sys/kern/kern_fork.c:854
> #20 0xc0b8e520 in Xatpic_intr0 () at atpic_vector.s:62
> #21 0x00000000 in ?? ()
>

I think it's not a bug of msk(4). Qin Li fixed the bug in arp code.
See r198301.

For watchdog timeout issues on 88E8053 controller, did you ever try
disabling MSI? msk(4) was changed a lot since 7.0-RELEASE to
support newer controllers and added several workarounds to address
silicon bugs. So don't blindly apply experimental patches to your
controller. 88E8053 also has a couple of hardware bugs but I guess
msk(4) already incorporated required workarounds. So if you can
reliably reproduce watchdog timeouts please let me know.
_______________________________________________
freebsd-net@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@..."

[Pyun YongHyeon]

The following reply was made to PR kern/124127; it has been noted by GNATS.

From: Pyun YongHyeon <pyunyh@...>
To: Mark Atkinson <atkin901@...>
Cc: freebsd-net@..., bug-followup@...
Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering
Date: Thu, 29 Oct 2009 09:49:09 -0700

 On Thu, Oct 29, 2009 at 06:52:34AM -0700, Mark Atkinson wrote:
 > Wow, not sure what to blame for that charset nightmare.  Apologies.
 > Here's the original message:
 >
 > On the unpatched -current kernel, built
 >
 > FreeBSD hellfire.filament.org 9.0-CURRENT FreeBSD 9.0-CURRENT #14: Mon
 > Oct 19 09:12:03 PDT 2009
 >
 > I recieved the following panic today related to this:
 >
 > Fatal trap 12: page fault while in kernel mode
 > cpuid = 0; apic id = 00
 > fault virtual address  = 0xdeadc10a
 > fault code              = supervisor read, page not present
 > instruction pointer    = 0x20:0xc0987410
 > stack pointer          = 0x28:0xd533dac0
 > frame pointer          = 0x28:0xd533dae8
 > code segment            = base 0x0, limit 0xfffff, type 0x1b
 >                         = DPL 0, pres 1, def32 1, gran 1
 > processor eflags        = interrupt enabled, resume, IOPL = 0
 > current process        = 0 (mskc0 taskq)
 > Physical memory: 495 MB
 > Dumping 132 MB: 117 101 85 69 53 37 21 5
 >
 > Reading symbols from /boot/kernel/linux.ko...Reading symbols from
 > /boot/kernel/linux.ko.symbols...done.
 > done.
 > Loaded symbols for /boot/kernel/linux.ko
 > #0  0xc08907a9 in doadump () at /usr/src/sys/kern/kern_shutdown.c:254
 > 254    }
 > (kgdb) bt
 > #0  0xc08907a9 in doadump () at /usr/src/sys/kern/kern_shutdown.c:254
 > #1  0xc04f7e37 in db_fncall (dummy1=-1067299898, dummy2=0,
 > dummy3=-718022488,
 >     dummy4=0xd533d898 "\200%t?") at /usr/src/sys/ddb/db_command.c:548
 > #2  0xc04f8214 in db_command (last_cmdp=0xc0da059c, cmd_table=0x0,
 > dopager=1)
 >     at /usr/src/sys/ddb/db_command.c:445
 > #3  0xc04f8352 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498
 > #4  0xc04fa05e in db_trap (type=12, code=0) at
 > /usr/src/sys/ddb/db_main.c:229
 > #5  0xc08bf2d2 in kdb_reenter () at /usr/src/sys/kern/subr_kdb.c:398
 > #6  0xc0ba9b62 in trap_fatal (frame=0x1, eva=3735929098)
 >     at /usr/src/sys/i386/i386/trap.c:938
 > #7  0xc0baa483 in trap (frame=0xd533da80) at
 > /usr/src/sys/i386/i386/trap.c:339
 > #8  0xc0b8e4ab in Xlcall_syscall () at
 > /usr/src/sys/i386/i386/exception.s:241
 > #9  0xc0987410 in in_lltable_lookup (llt=0xc39e1000, flags=Variable
 > "flags" is not available.
 > )
 >     at /usr/src/sys/netinet/in.c:1380
 > #10 0xc0982470 in arpintr (m=0xc3baeb00) at
 > /usr/src/sys/netinet/if_ether.c:642
 > #11 0xc094227a in netisr_dispatch_src (proto=7, source=0, m=0xc0de)
 >     at /usr/src/sys/net/netisr.c:932
 > #12 0xc09424dd in netisr_unregister (nhp=0xc0de)
 >     at /usr/src/sys/net/netisr.c:583
 > #13 0xc093ac69 in ether_demux (ifp=0x0, m=0xc3baeb00)
 >     at /usr/src/sys/net/if_ethersubr.c:911
 > #14 0xc093b1ce in ether_output (ifp=0xc36ad400, m=0xc3baeb00,
 > dst=0xc0c55c27,
 >     ro=0x301010a) at /usr/src/sys/net/if_ethersubr.c:181
 > ---Type <return> to continue, or q <return> to quit---
 > #15 0xc070b032 in msk_handle_events (sc=0xc3686c00)
 >     at /usr/src/sys/dev/msk/if_msk.c:3048
 > #16 0xc070b828 in msk_int_task (arg=0xc3686c00, pending=1)
 >     at /usr/src/sys/dev/msk/if_msk.c:3625
 > #17 0xc08cac8c in taskqueue_run (queue=0xc36bf380)
 >     at /usr/src/sys/kern/subr_taskqueue.c:72
 > #18 0xc08cadcc in taskqueue_thread_loop (arg=0xc3686c8c)
 >     at /usr/src/sys/kern/subr_taskqueue.c:90
 > #19 0xc0869271 in fork_exit (callout=0xc08cad67 <taskqueue_thread_loop+64>,
 >     arg=0xc3686c8c, frame=0xd533dd38) at /usr/src/sys/kern/kern_fork.c:854
 > #20 0xc0b8e520 in Xatpic_intr0 () at atpic_vector.s:62
 > #21 0x00000000 in ?? ()
 >
 
 I think it's not a bug of msk(4). Qin Li fixed the bug in arp code.
 See r198301.
 
 For watchdog timeout issues on 88E8053 controller, did you ever try
 disabling MSI? msk(4) was changed a lot since 7.0-RELEASE to
 support newer controllers and added several workarounds to address
 silicon bugs. So don't blindly apply experimental patches to your
 controller. 88E8053 also has a couple of hardware bugs but I guess
 msk(4) already incorporated required workarounds. So if you can
 reliably reproduce watchdog timeouts please let me know.
_______________________________________________
freebsd-net@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@..."

[Mark Atkinson-3]

The following reply was made to PR kern/124127; it has been noted by GNATS.

From: Mark Atkinson <atkin901@...>
To: pyunyh@...
Cc: bug-followup@...
Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering
Date: Thu, 29 Oct 2009 10:47:47 -0700 (PDT)

 ----- Original Message ----
 
 From: Pyun YongHyeon <pyunyh@...>
 Sent: Thu, October 29, 2009 9:49:09 AM
 Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering
 
 >I think it's not a bug of msk(4). Qin Li fixed the bug in arp code.
 >See r198301.
 
 Thanks I saw the intr call in the trace and assumed wrong, the 'lltable'
 should have tipped me off.
 
 >For watchdog timeout issues on 88E8053 controller, did you ever try
 >disabling MSI?
 
 I haven't tried that lately in -current, last time I did that msk did
 not work at all.  Will retry and report back.
 
 > msk(4) was changed a lot since 7.0-RELEASE to
 >support newer controllers and added several workarounds to address
 >silicon bugs. So don't blindly apply experimental patches to your
 >controller.
 
 Yes, this box runs -current constantly, only recently did I have to
 give up my dual Intel adapter and go back to using the on-board
 pci-e yukon, and thus re-experiencing this issue.
 
 > 88E8053 also has a couple of hardware bugs but I guess
 >msk(4) already incorporated required workarounds. So if you can
 >reliably reproduce watchdog timeouts please let me know.
 
 It still repros on -current, hence me trying out the experimental
 patches in the PR and reporting back.   As I reported in this PR
 earlier I could still hit the watchdog after a week of runtime, but
 as of now I don't have a reliable repro.
 
 BTW thanks for all your hard work on hardware NIC support.  Very
 much appreciated.
 
 
 
       
_______________________________________________
freebsd-net@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@..."