Bug 35354

Summary: 4.4/4.5 FreeBSD causes hard lock after 20+ hours of uptime
Product: Base System Reporter: Nick Toomey <ntoomey>
Component: kernAssignee: Andre Oppermann <andre>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   

Description Nick Toomey 2002-02-26 21:20:00 UTC
After upgrading from version 4.3 to 4.4 or 4.5 the machine hard locks after close to 24 hours of uptime.  No Kernel panic errors, or anything printed to the console before the sudden freeze.

Fix: 

Install a 4.3 Kernel.
How-To-Repeat: Let the machine run for 24 hours without a reboot.
Comment 1 silby freebsd_committer freebsd_triage 2002-02-27 01:07:20 UTC
State Changed
From-To: open->feedback

Nick, we need a lot more information than that to even start diagnosing. 
To begin with, compile a kernel with DDB, then try to ctrl-alt-esc into 
the debugger and run a trace to see what the system is doing.
Comment 2 stevemcn 2002-03-19 02:45:32 UTC
I Was Having The Same Problem After Upgrading From 4.3-STABLE To 4.5-STABLE.
When The Uptime Would Near 24 Hours I Would Get A Kernel Panic And A Reboot.
It Seems To Be inet6 Related. When I Compile The Kernel Without "options
inet6" Everthing
Returns To Normal.
I Have 2 3Com 3c905B-TX Nics Installed.
Here's What I Got From The Dump.
If You Need More Info Let Me Know.

SMP 2 cpus
IdlePTD at phsyical address 0x00439000
initial pcb at physical address 0x0037f2c0
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
mp_lock = 00000002; cpuid = 0; lapic.id = 01000000
fault virtual address   = 0x6210ccc2
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xc01bf049
stack pointer           = 0x10:0xff807f34
frame pointer           = 0x10:0xff807f3c
code segment            = base rx0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = Idle
interrupt mask          =  <- SMP: XXX
trap number             = 12
panic: page fault
mp_lock = 00000002; cpuid = 0; lapic.id = 01000000
boot() called on cpu#0

syncing disks... 44 38 33 30 27 25 23 20 18 14 11 7 6 3 2 1
done
Uptime: 23h55m33s

dumping to dev #da/0x20001, offset 1327128
dump 351 350 349 348 347 346 345 344 343 342 341 340 339 338 337 336 335 
334 333 332 331 330 329 328 327 326 325 324 323 322 321 320 319 318 317 316
315 
314 313 312 311 310 309 308 307 306 305 304 303 302 301 300 299 298 297 296
295 
294 293 292 291 290 289 288 287 286 285 284 283 282 281 280 279 278 277 276
275 
274 273 272 271 270 269 268 267 266 265 264 263 262 261 260 259 258 257 256
255 
254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236
235 
234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216
215 
214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196
195 
194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176
175 
174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156
155 
154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136
135 
134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116
115 
114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95
94 93 
92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68
67 66 65
 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40
39 38 37 
36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12
11 10 9 8 
7 6 5 4 3 2 1 0
---
#0  dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
487             if (dumping++) {
(kgdb) where
#0  dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
#1  0xc01730a3 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:316
#2  0xc0173515 in panic (fmt=0xc032ebf9 "%s")
    at /usr/src/sys/kern/kern_shutdown.c:595
#3  0xc02d8ec1 in trap_fatal (frame=0xff807ef4, eva=1645268162)
    at /usr/src/sys/i386/i386/trap.c:966
#4  0xc02d8b2d in trap_pfault (frame=0xff807ef4, usermode=0, eva=1645268162)
    at /usr/src/sys/i386/i386/trap.c:859
#5  0xc02d865b in trap (frame={tf_fs = -955187176, tf_es = 1645215760,
      tf_ds = 16, tf_edi = 1645268128, tf_esi = 1645268128, tf_ebp = -8356036,
      tf_isp = -8356064, tf_ebx = -1070059486, tf_edx = 5, tf_ecx = 4,
      tf_eax = 65, tf_trapno = 12, tf_err = 0, tf_eip = -1071910839,
      tf_cs = 8, tf_eflags = 2163206, tf_esp = -955164672, tf_ss =
-955164672})
    at /usr/src/sys/i386/i386/trap.c:458
#6  0xc01bf049 in if_name (ifp=0x6210cca0) at /usr/src/sys/net/net_osdep.c:62
#7  0xc01e0d15 in in6_purgeaddr (ifa=0xc7115800)
    at /usr/src/sys/netinet6/in6.c:1185
#8  0xc01ee9a8 in nd6_timer (ignored_arg=0x0)
    at /usr/src/sys/netinet6/nd6.c:580
#9  0xc0179091 in softclock () at /usr/src/sys/kern/kern_timeout.c:131


Steve McNelly
stevemcn@snics.com
Comment 3 Giorgos Keramidas freebsd_committer freebsd_triage 2002-08-22 00:15:34 UTC
On 2002-02-26 13:16 +0000, Nick Toomey wrote:
> I Was Having The Same Problem After Upgrading From 4.3-STABLE To
> 4.5-STABLE.  When The Uptime Would Near 24 Hours I Would Get A
> Kernel Panic And A Reboot.  It Seems To Be inet6 Related. When I
> Compile The Kernel Without "options inet6" Everthing Returns To
> Normal. [...]

Nick,
Does this problem still trouble you
with 4.6-RELEASE or 4.6.2-RELEASE?

- Giorgos
Comment 4 Nick Toomey 2002-08-22 04:03:56 UTC
Haven't attempted 4.6 yet, the bug is on a production machine that I don't
currently have a replacement for.

Nick
SMI

On Thu, 22 Aug 2002, Giorgos Keramidas wrote:

> On 2002-02-26 13:16 +0000, Nick Toomey wrote:
> > I Was Having The Same Problem After Upgrading From 4.3-STABLE To
> > 4.5-STABLE.  When The Uptime Would Near 24 Hours I Would Get A
> > Kernel Panic And A Reboot.  It Seems To Be inet6 Related. When I
> > Compile The Kernel Without "options inet6" Everthing Returns To
> > Normal. [...]
>
> Nick,
> Does this problem still trouble you
> with 4.6-RELEASE or 4.6.2-RELEASE?
>
> - Giorgos
>
Comment 5 KAREN THODE 2002-12-24 19:54:44 UTC
Why is the author of osdep.c trying to cram two strings into a one-dimensional array?

Lucas
Comment 6 Andre Oppermann freebsd_committer freebsd_triage 2003-12-22 20:35:52 UTC
Responsible Changed
From-To: freebsd-bugs->andre

Asked Originator whether problems persists.
Comment 7 oppermann 2003-12-22 20:37:45 UTC
Nick,

do you still experience the problem described in your problem report 
with 4.9 or 5.2?

Thanks
-- 
Andre
Comment 8 Andre Oppermann freebsd_committer freebsd_triage 2004-01-15 12:45:12 UTC
State Changed
From-To: feedback->closed

No response from Originator.  According to the backtrace the 
problem happend in IPv6.  There have been many changes to it 
since 4.5.  Judging from the lack of other problem reports 
and discussion this has been fixed.