Potential workaround for e1000
authorBarret Rhoden <brho@cs.berkeley.edu>
Wed, 5 May 2010 00:00:50 +0000 (17:00 -0700)
committerKevin Klues <klueska@cs.berkeley.edu>
Thu, 3 Nov 2011 00:35:47 +0000 (17:35 -0700)
Not the right answer, but might work for OSDI.  Will at least help us
see the issue.  If we see a warning that isn't followed by the panic on
line 680, then there are more issues (and this fix might not be
helping).

kern/arch/i686/e1000.c

index 512e64d..deb2b10 100644 (file)
@@ -655,8 +655,20 @@ void e1000_handle_rx_packet() {
                status =  rx_des_kva[rx_des_loop_cur].status;
 
                if (status == 0x0) {
-                       //panic("ERROR: E1000: Packet owned by hardware has 0 status value\n");
+#ifndef __CONFIG_OSDI__
+                       panic("ERROR: E1000: Packet owned by hardware has 0 status value\n");
+#else /* OSDI */
                        warn("ERROR: E1000: Packet owned by hardware has 0 status value\n");
+                       /* It's possible we are processing a packet that is a fragment
+                        * before the entire packet arrives.  The code currently assumes
+                        * that all of the packets fragments are there, so it assumes the
+                        * next one is ready.  We'll spin until it shows up...  This could
+                        * deadlock, and sucks in general, but will help us diagnose the
+                        * driver's issues.  */
+                       while(rx_des_kva[rx_des_loop_cur].status == 0x0)
+                               cpu_relax();
+                       status = rx_des_kva[rx_des_loop_cur].status;
+#endif /* __CONFIG_OSDI__ */
                }
        
                fragment_size = rx_des_kva[rx_des_loop_cur].length;