NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: french mirror down this evening

On Thu, Nov 20, 2008 at 02:04:20PM +0100, Manuel Bouyer wrote:
> Hello,
> the french mirror {ftp,sup,www,rsync,anoncvs} will be
> down this evening, between 20h and 23h GMT, for OS upgrade (testing
> 5.0_BETA, yeah :). hopefully the downtime will be much less than 3h ...

It's up again, but running UP for now. I got deadlock with dual-CPU
that look related to raidframe (machine dead, no ping or whatever,
entered ddb via the cnmagic sequence):
fatal breakpoint trap in supervisor mode
trap type 1 code 0 eip c03aabec cs 8 eflags 202 cr2 bb504000 ilevel 8
Stopped in pid 0.4 (system) at  netbsd:breakpoint+0x4:  popl    %ebp
db{0}> tr
breakpoint(0,3f8,0,6,ca7953c0,cbd01900,cbb5beb0,c1540010,c1541000,7fa) at 
at netbsd:comintr+0x566
Xintr_ioapic_edge4() at netbsd:Xintr_ioapic_edge4+0xa9
--- interrupt ---
fatal page fault in supervisor mode
trap type 6 code 0 eip c03ad04f cs 8 eflags 10206 cr2 3e ilevel 8
kernel: supervisor trap page fault, code=0
Faulted in DDB; continuing...
db{0}> mach cpu 1
using CPU 1
db{0}> tr
cc5a2d20) at netbsd:__cpu_simple_lock+0x1c
rf_RaidIOThread(c1556000,0,c01002a7,0,c01002a7,0,0,0,0,0) at 

rf_RaidIOThread+0x7f is:
0xc01c533f is in rf_RaidIOThread 
858                     /* See what I/Os, if any, have arrived */
859                     while ((req = TAILQ_FIRST(&(raidPtr->iodone))) != NULL) 
860                             TAILQ_REMOVE(&(raidPtr->iodone), req, 
861                             simple_unlock(&(raidPtr->iodone_lock));
862                             rf_DiskIOComplete(req->queue, req, req->error);
863                             (req->CompleteFunc) (req->argument, req->error);
864                             simple_lock(&(raidPtr->iodone_lock));
865                     }

0xc01c5324 <rf_RaidIOThread+100>:       call   0xc010cd90 <__cpu_simple_unlock>
0xc01c5329 <rf_RaidIOThread+105>:       mov    0x70(%ebx),%eax
0xc01c532c <rf_RaidIOThread+108>:       mov    0x58(%ebx),%edx
0xc01c532f <rf_RaidIOThread+111>:       mov    %ebx,0x4(%esp)
0xc01c5333 <rf_RaidIOThread+115>:       mov    %eax,0x8(%esp)
0xc01c5337 <rf_RaidIOThread+119>:       mov    %edx,(%esp)
0xc01c533a <rf_RaidIOThread+122>:       call   0xc01c1780 <rf_DiskIOComplete>
0xc01c533f <rf_RaidIOThread+127>:       mov    0x2c(%ebx),%edx
0xc01c5342 <rf_RaidIOThread+130>:       mov    0x70(%ebx),%eax
0xc01c5345 <rf_RaidIOThread+133>:       mov    0x28(%ebx),%ecx
0xc01c5348 <rf_RaidIOThread+136>:       mov    %edx,(%esp)
0xc01c534b <rf_RaidIOThread+139>:       mov    %eax,0x4(%esp)
0xc01c534f <rf_RaidIOThread+143>:       call   *%ecx
0xc01c5351 <rf_RaidIOThread+145>:       mov    %esi,(%esp)
0xc01c5354 <rf_RaidIOThread+148>:       call   0xc010cd70 <__cpu_simple_lock>

I got 2 of theses, and ddb gave identical outputs.
If the system is stable with a UP kernel I'll send a bug report

Manuel Bouyer <>
     NetBSD: 26 ans d'experience feront toujours la difference

Home | Main Index | Thread Index | Old Index