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.
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)?
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]
