Mike Ford Ditto wrote:
> Is this panic a known problem? I just tried to use a Sun Ray for the
> first time since I upgraded from snv_62 to snv_91 and I get this panic
> within a few minutes every time I log in to a Sun Ray. I don't know if
> this is a bug in SRSS or OpenSolaris but I thought I'd mention it here
> in case it's something that should be fixed.
SRSS doesn't have any in-kernel networking components. All of
its network traffic comes through sockets from user-level
processes. So it's hard to see how SRSS could be the cause of
this panic.
> The server is running SXCE snv_91 (amd64), Masayuki Murayama's vfe
> driver, and SRSS 3.1. Sun Rays were working fine when I was running
> snv_62. I just tried upgrading the vfe driver from 2.3.1 to 2.6.2a, but
> still get the panics.
>
> Maybe SRSS 3.1 is just buggy on newer Nevada builds (post-Clearview,
> perhaps)?
SRSS 4.0 was released last month and would be a better choice on
Nevada, but I wouldn't expect it to behave any differently as far
as a networking panic is concerned.
Mike.
--
[EMAIL PROTECTED]
> panic[cpu1]/thread=ffffff000447ac80:
> BAD TRAP: type=e (#pf Page fault) rp=ffffff000447a6d0 addr=0 occurred in
> module "vfe" due to a NULL pointer dereference
>
>> $c
> gem_send_common+0x192()
> gem_gld_send+0x47()
> gld_start+0x25e(ffffff01476e9e40, ffffff014ec88ee0, 0, 0)
> gld_wput+0xf8(ffffff01476e9e40, ffffff014ec88ee0)
> putnext+0x22b(ffffff0148a90e20, ffffff014ec88ee0)
> softmac_m_tx+0xb3(ffffff014c967200, ffffff014ec88ee0)
> dls_tx+0x1d(ffffff0141149d20, ffffff014ec88ee0)
> dld_wsrv+0xb7(ffffff0149cfab50)
> runservice+0x42(ffffff0149cfab50)
> queue_service+0x42(ffffff0149cfab50)
> stream_service+0x73(ffffff014cf03838)
> taskq_d_thread+0xbb(ffffff014bbe9a50)
> thread_start+8()
>> ::modinfo ! grep vfe
> 165 fffffffff7d79000 d860 1 vfe (via rhine nic driver v2.6.2)
>> gem_send_common+141,10?ia
> gem_send_common+0x141:movl -0x48(%rbp),%r12d ; nmblk
> gem_send_common+0x145: movq +0x3b7cd5c(%rip),%r11 <_pageoffset>
> gem_send_common+0x14c: movl +0x3b7cd11(%rip),%r10d <_pageshift>
> gem_send_common+0x153: addl 0x110(%r13),%r14d
> gem_send_common+0x15a: movl 0x288(%r13),%r15d
> gem_send_common+0x161: decl %r15d
> gem_send_common+0x164: andl %r15d,%r14d
> gem_send_common+0x167: imulq $0x130,%r14,%r15
> gem_send_common+0x16e: addq 0x108(%r13),%r15
> gem_send_common+0x175: movl %r12d,-0x4c(%rbp) ; i
> gem_send_common+0x179: movq %r11,-0xa0(%rbp)
> gem_send_common+0x180: movl %r10d,-0xa4(%rbp)
> gem_send_common+0x187: movq -0x40(%rbp),%r13 ; mp_head
> gem_send_common+0x18b: movq %r13,-0xb0(%rbp) ; mp
> gem_send_common+0x192: movq 0x0(%r13),%rdx ; mp_head->b_next
> gem_send_common+0x196: movq %rdx,-0x40(%rbp) ; mp_head
> gem_send_common+0x19a:
>> <rbp-0x48/D
> 0xffffff000447a848: 47
>> <rbp-0x4C/D
> 0xffffff000447a844: 7
>
> The panic is here in the vfe driver:
>
> mblk_t *
> gem_send_common(struct gem_dev *dp, mblk_t *mp_head, uint32_t flags)
> {
> ...
> mp = mp_head;
> nmblk = 1;
> while ((mp = mp->b_next) != NULL) {
> nmblk++;
> }
> ...
> i = nmblk;
> do {
> ...
> mp = mp_head;
> mp_head = mp_head->b_next, !! TRAP HERE, mp_head is zero !!
> mp->b_next = NULL;
> ...
> } while (--i > 0);
>
> And apparently, nmblk = 47 and i = 7 at the time of the panic. It looks
> like somebody handed a long chain of packets to vfe and then munged the
> pointers while vfe was processing it.
>
> The first packet in the chain can still be seen as an argument to
> gld_start, and it is a packet from the sunray server to a sunray.
>
>> ffffff014ec88ee0::print -t mblk_t
> {
> struct msgb *b_next = 0
> struct msgb *b_prev = 0
> struct msgb *b_cont = 0
> unsigned char *b_rptr = 0xffffff014ed0c082
> unsigned char *b_wptr = 0xffffff014ed0c53c
> struct datab *b_datap = 0xffffff014ed0c000
> unsigned char b_band = 0
> unsigned char b_tag = 0
> unsigned short b_flag = 0x2
> queue_t *b_queue = 0
> }
>> 0xffffff014ed0c082,40::dump
> 0 1\/ 3 4 5 6 7 8 9 a b c d e f 01v3456789abcdef
> ffffff014ed0c080: feca0003 bab00f1a 00301b41 db910800 .........0.A....
> ffffff014ed0c090: 450004ac 68434000 ff118cd5 c0a88001 [EMAIL PROTECTED]
> ffffff014ed0c0a0: c0a880d5 9c42d22d 049826df de4d0000 .....B.-..&..M..
> ffffff014ed0c0b0: 66810000 085200c8 01000908 a600b239 f....R.........9
> ffffff014ed0c0c0: 048c022d 007c0001 c8b9b6c9 b9b3caba ...-.|..........
>> ffffff014ed0c090::iphdr
> IPv4 header
> SRC DST
> HLEN TOS LEN ID OFFSET TTL PROTO CHKSUM EXP-CSUM FLGS
> 192.168.128.1 192.168.128.213
> 20 0 1196 26691 0 255 17 54668 54668 <DF>
>
>
>
> -=] Mike [=-
> _______________________________________________
> networking-discuss mailing list
> [email protected]
_______________________________________________
networking-discuss mailing list
[email protected]
