Re: new openbsd 4.0 server, panic on ufsdirhash
[snip] OK, now I'm clueless why this happens. I didn't see in your verbose dmesg at all any obvious PCI busses or devices. Yet the normal dmesg lists your PCI devices. I could be reading the devices wrong, but I read in your verbose dmesg that it found: 1: Audio 2: Realtek Ethernet (probably a PCI device??) 3: isa0 bus 4: Keyboard/mouse ports (which I really think they are attached on the ISA bus, internally on the motherboard) 5: speaker (again, same as #4, on the ISA bus in the motherboard) 6: parallel (ditto) 7: npx0 (I think this is your coprocessor, and I don't know what bus it is on) 8: COM/Serial ports (ditto as #4) 9: Floppy drive (I would think this is on the ISA bus, but I am not sure) Aside from #2, the realtek ethernet, I am not seeing any signs of PCI detection. But how can it boot off the drive, which is on pciide0 (from original, normal dmesg in digest #783). That device sure looks like it's on the PCI bus. I'm lost on this one, I totally expected to see anything, SOMETHING about the pci bus (wouldn't it be pci0?). I think we are missing the top of the dmesg (notice how you don't see the copyright notice) This must be because all the verbosity overflow the 4k buffer for the dmesg. Aside from that, I'm sorry I can't help much. John did state he has another version, and if *THIS* thing fails horribly bad on trying to get more information, I would try the other version. I'm not sure if the 4.1-RELEASE (at least the sparc32 one) was done correctly, I have a simple 64MB sparcstation5 that after I came home from work one day, the box was at the 4th prompt (for ya i386 folks, that's similar to the BIOS/SETUP program). A day or two later the same box, same config, same everything was waiting on a ddb prompt with what seemed to be a runaway application (smbd, ddb's ps command just kept endlessly returning smbd as processes running on the box). The only change to this box was an addon SBUS 4-port ethernet board. Anyway, I got sidetracked in the basic statement that there may be something wrong with the comp41.tgz set? bad press? bad release process on OpenBSD? I can't pin it down, but I didn't have *ANY* problem with 4.0, in any of it's platforms. The above paragraph may start flaming, and I want to defuse it right now. The problem I have above may not at all be related to John's original problem, but I've also seen other people having trouble installing 4.1 on this mailing list and wonder if it has something related/linked that we can use. Heck, my 4.1 i386 CD I burned locks up my keyboard/kvm so bad that I have to push the buttons on the front to reboot. It gets to the "install, upgrade, shell" and then locks up. John, please try 4.0 and then doing a source upgrade to 4.1, if this verbose dmesg doesn't help anybody. Sorry for bringing it up :( Good luck. If opportunity doesn't knock, build a door. "I can" is a way of life. More and Bigger is not always Better. The road to success is always uphill.
Re: new openbsd 4.0 server, panic on ufsdirhash
--- John Mendenhall <[EMAIL PROTECTED]> wrote: > > OK, now I'm clueless why this happens. I didn't see in your > verbose > > dmesg at all any obvious PCI busses or devices. Yet the normal > dmesg > > lists your PCI devices. I could be reading the devices wrong, but > I > > read in your verbose dmesg that it found: > > 1: Audio > > 2: Realtek Ethernet (probably a PCI device??) > > 3: isa0 bus > > 4: Keyboard/mouse ports (which I really think they are attached on > the > > ISA bus, internally on the motherboard) > > 5: speaker (again, same as #4, on the ISA bus in the motherboard) > > 6: parallel (ditto) > > 7: npx0 (I think this is your coprocessor, and I don't know what > bus it > > is on) > > 8: COM/Serial ports (ditto as #4) > > 9: Floppy drive (I would think this is on the ISA bus, but I am not > > sure) > > > > Aside from #2, the realtek ethernet, I am not seeing any signs of > PCI > > detection. But how can it boot off the drive, which is on pciide0 > > (from original, normal dmesg in digest #783). That device sure > looks > > like it's on the PCI bus. I'm lost on this one, I totally expected > to > > see anything, SOMETHING about the pci bus (wouldn't it be pci0?). > > I have no idea why that is happening. Strange. > > > John did state he has another version, and if *THIS* thing fails > > horribly bad on trying to get more information, I would try the > other > > version. ... > > > > John, please try 4.0 and then doing a source upgrade to 4.1, if > this > > verbose dmesg doesn't help anybody. Sorry for bringing it up :( > > This is the 4.0 release. I usually run a release behind. And, I > have > not ordered a 4.1 yet. I will in the next week or two. > > I do have v3.9 and earlier releases available. Whatever you have onhand that you know has worked in the past. 3.9 isn't "supported" anymore, but using 3.9 to update to 4.0 or 4.1 would probably work as documented by the fabulous documentation! Let us know! > JohnM > > -- > john mendenhall > [EMAIL PROTECTED] > surf utopia > internet services > If opportunity doesn't knock, build a door. "I can" is a way of life. More and Bigger is not always Better. The road to success is always uphill. Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A. http://answers.yahoo.com/dir/?link=list&sid=396545367
Re: new openbsd 4.0 server, panic on ufsdirhash
--- John Mendenhall <[EMAIL PROTECTED]> wrote: > > The comp set isn't required to RUN OpenBSD. Install the minimal > > (kernel, base, etc) and I think that will get the system running. > Then > > you can alter the booting mechanism (verbose) and make tweaks > before > > loading comp. > > OK. I have installed the bare sets to get it working. > It is up and running now. I rebooted and was able to access > the UKC and requested verbose boot. The verbose boot log > is at the bottom of the message. > > > I'm hitting Google with your pciide0 string and for the 2 minutes > of > > searching, all I see are various people having problems. Maybe > because > > people won't complain or give this kind of information normally if > > things are working well. I'll continue to search... could > you/would > > you install the minimal and work from there? Maybe it's corrupt on > the > > source! CD pressed/burned badly. Older OpenBSD release working? > > I have not tried any other os installation. > I have earlier versions which I could try, if > we want to check that. That would not be a > problem. > > JohnM > > > - > dmesg w/verbose OK, now I'm clueless why this happens. I didn't see in your verbose dmesg at all any obvious PCI busses or devices. Yet the normal dmesg lists your PCI devices. I could be reading the devices wrong, but I read in your verbose dmesg that it found: 1: Audio 2: Realtek Ethernet (probably a PCI device??) 3: isa0 bus 4: Keyboard/mouse ports (which I really think they are attached on the ISA bus, internally on the motherboard) 5: speaker (again, same as #4, on the ISA bus in the motherboard) 6: parallel (ditto) 7: npx0 (I think this is your coprocessor, and I don't know what bus it is on) 8: COM/Serial ports (ditto as #4) 9: Floppy drive (I would think this is on the ISA bus, but I am not sure) Aside from #2, the realtek ethernet, I am not seeing any signs of PCI detection. But how can it boot off the drive, which is on pciide0 (from original, normal dmesg in digest #783). That device sure looks like it's on the PCI bus. I'm lost on this one, I totally expected to see anything, SOMETHING about the pci bus (wouldn't it be pci0?). John did state he has another version, and if *THIS* thing fails horribly bad on trying to get more information, I would try the other version. I'm not sure if the 4.1-RELEASE (at least the sparc32 one) was done correctly, I have a simple 64MB sparcstation5 that after I came home from work one day, the box was at the 4th prompt (for ya i386 folks, that's similar to the BIOS/SETUP program). A day or two later the same box, same config, same everything was waiting on a ddb prompt with what seemed to be a runaway application (smbd, ddb's ps command just kept endlessly returning smbd as processes running on the box). The only change to this box was an addon SBUS 4-port ethernet board. Anyway, I got sidetracked in the basic statement that there may be something wrong with the comp41.tgz set? bad press? bad release process on OpenBSD? I can't pin it down, but I didn't have *ANY* problem with 4.0, in any of it's platforms. The above paragraph may start flaming, and I want to defuse it right now. The problem I have above may not at all be related to John's original problem, but I've also seen other people having trouble installing 4.1 on this mailing list and wonder if it has something related/linked that we can use. Heck, my 4.1 i386 CD I burned locks up my keyboard/kvm so bad that I have to push the buttons on the front to reboot. It gets to the "install, upgrade, shell" and then locks up. John, please try 4.0 and then doing a source upgrade to 4.1, if this verbose dmesg doesn't help anybody. Sorry for bringing it up :( Good luck. If opportunity doesn't knock, build a door. "I can" is a way of life. More and Bigger is not always Better. The road to success is always uphill.
Re: new openbsd 4.0 server, panic on ufsdirhash
> OK, now I'm clueless why this happens. I didn't see in your verbose > dmesg at all any obvious PCI busses or devices. Yet the normal dmesg > lists your PCI devices. I could be reading the devices wrong, but I > read in your verbose dmesg that it found: > 1: Audio > 2: Realtek Ethernet (probably a PCI device??) > 3: isa0 bus > 4: Keyboard/mouse ports (which I really think they are attached on the > ISA bus, internally on the motherboard) > 5: speaker (again, same as #4, on the ISA bus in the motherboard) > 6: parallel (ditto) > 7: npx0 (I think this is your coprocessor, and I don't know what bus it > is on) > 8: COM/Serial ports (ditto as #4) > 9: Floppy drive (I would think this is on the ISA bus, but I am not > sure) > > Aside from #2, the realtek ethernet, I am not seeing any signs of PCI > detection. But how can it boot off the drive, which is on pciide0 > (from original, normal dmesg in digest #783). That device sure looks > like it's on the PCI bus. I'm lost on this one, I totally expected to > see anything, SOMETHING about the pci bus (wouldn't it be pci0?). I have no idea why that is happening. Strange. > John did state he has another version, and if *THIS* thing fails > horribly bad on trying to get more information, I would try the other > version. ... > > John, please try 4.0 and then doing a source upgrade to 4.1, if this > verbose dmesg doesn't help anybody. Sorry for bringing it up :( This is the 4.0 release. I usually run a release behind. And, I have not ordered a 4.1 yet. I will in the next week or two. I do have v3.9 and earlier releases available. JohnM -- john mendenhall [EMAIL PROTECTED] surf utopia internet services
Re: new openbsd 4.0 server, panic on ufsdirhash
> The comp set isn't required to RUN OpenBSD. Install the minimal > (kernel, base, etc) and I think that will get the system running. Then > you can alter the booting mechanism (verbose) and make tweaks before > loading comp. OK. I have installed the bare sets to get it working. It is up and running now. I rebooted and was able to access the UKC and requested verbose boot. The verbose boot log is at the bottom of the message. > I'm hitting Google with your pciide0 string and for the 2 minutes of > searching, all I see are various people having problems. Maybe because > people won't complain or give this kind of information normally if > things are working well. I'll continue to search... could you/would > you install the minimal and work from there? Maybe it's corrupt on the > source! CD pressed/burned badly. Older OpenBSD release working? I have not tried any other os installation. I have earlier versions which I could try, if we want to check that. That would not be a problem. JohnM - dmesg w/verbose - % dmesg >> probing for gdt* >>> gdt probe returned 0 >>> probing for cac* >>> cac probe returned 0 >>> probing for ciss* >>> ciss probe returned 0 >>> probing for isp* >>> isp probe returned 0 >>> probing for mpi* >>> mpi probe returned 0 >>> probing for de* >>> de probe returned 0 >>> probing for ep0 >>> ep probe returned 0 >>> probing for ep* >>> ep probe returned 0 >>> probing for fpa* >>> fpa probe returned 0 >>> probing for pcn* >>> pcn probe returned 0 >>> probing for siop* >>> siop probe returned 0 >>> probing for neo* >>> neo probe returned 0 >>> probing for pciide* >>> pciide probe returned 0 >>> probing for ppb* >>> ppb probe returned 0 >>> probing for cy* >>> cy probe returned 0 >>> probing for lmc* >>> lmc probe returned 0 >>> probing for mtd* >>> mtd probe returned 0 >>> probing for rl* >>> rl probe returned 0 >>> probing for re* >>> re probe returned 0 >>> probing for vr* >>> vr probe returned 0 >>> probing for tl* >>> tl probe returned 0 >>> probing for txp* >>> txp probe returned 0 >>> probing for sv* >>> sv probe returned 0 >>> probing for bktr0 >>> bktr probe returned 0 >>> probing for xl* >>> xl probe returned 0 >>> probing for fxp* >>> fxp probe returned 0 >>> probing for em* >>> em probe returned 0 >>> probing for ixgb* >>> ixgb probe returned 0 >>> probing for xge* >>> xge probe returned 0 >>> probing for dc* >>> dc probe returned 0 >>> probing for epic* >>> epic probe returned 0 >>> probing for ti* >>> ti probe returned 0 >>> probing for ne* >>> ne probe returned 0 >>> probing for lofn* >>> lofn probe returned 0 >>> probing for hifn* >>> hifn probe returned 0 >>> probing for nofn* >>> nofn probe returned 0 >>> probing for ubsec* >>> ubsec probe returned 0 >>> probing for safe* >>> safe probe returned 0 >>> probing for wb* >>> wb probe returned 0 >>> probing for sf* >>> sf probe returned 0 >>> probing for sis* >>> sis probe returned 0 >>> probing for ste* >>> ste probe returned 0 >>> probing for wdt0 >>> wdt probe returned 0 >>> probing for uhci* >>> uhci probe returned 0 >>> probing for ohci* >>> ohci probe returned 0 >>> probing for ehci* >>> ehci probe returned 0 >>> probing for cbb* >>> cbb probe returned 0 >>> probing for skc* >>> skc probe returned 0 >>> probing for mskc* >>> mskc probe returned 0 >>> probing for puc* >>> puc probe returned 0 >>> probing for wi* >>> wi probe returned 0 >>> probing for an* >>> an probe returned 0 >>> probing for ipw* >>> ipw probe returned 0 >>> probing for iwi* >>> iwi probe returned 0 >>> probing for wpi* >>> wpi probe returned 0 >>> probing for cmpci* >>> cmpci probe returned 0 >>> probing for iha* >>> iha probe returned 0 >>> probing for trm* >>> trm probe returned 0 >>> probing for pcscp* >>> pcscp probe returned 0 >>> probing for nge* >>> nge probe returned 0 >>> probing for lge* >>> lge probe returned 0 >>> probing for bge* >>> bge probe returned 0 >>> probing for bnx* >>> bnx probe returned 0 >>> probing for vge* >>> vge probe returned 0 >>> probing for stge* >>> stge probe returned 0 >>> probing for nfe* >>> nfe probe returned 0 >>> probing for amdpm* >>> amdpm probe returned 0 >>> probing for viaenv* >>> viaenv probe returned 0 >>> probing for bce* >>> bce probe returned 0 >>> probing for ath* >>> ath probe returned 0 >>> probing for atw* >>> atw probe returned 0 >>> probing for rtw* >>> rtw probe returned 0 >>> probing for ral* >>> ral probe returned 0 >>> probing for acx* >>> acx probe returned 0 >>> probing for pgt* >>> pgt probe returned 0 >>> probing for san* >>> san probe returned 0 >>> probing for piixpm* >>> piixpm probe returned 0 >>> probing for musycc* >>> musycc probe returned 0 >>> probing for ichiic* >>> ichiic probe returned 0 >>> probing for alipm* >>> alipm probe returned 0 >>> probing for viapm* >>> viapm probe returned 0 >>> probing for amdiic* >>> amdiic probe returned 0 >>> probing for nviic* >>> nviic probe returned 0 >>> probing for sdhc* >>> sdhc probe returned 0 >>> probing for pchb* >>>
Re: new openbsd 4.0 server, panic on ufsdirhash
On Wed, May 16, 2007 at 07:44:14PM -0700, John Mendenhall wrote: > Well, I posted the dmesg at the beginning of this thread. Sorry, I'd forgotten it was in your first post. :( > > Use UKC (boot -c), and the "verbose" command. See boot_config(8). > > Is this supported when booting from cd? I can only boot from the > cd right now. Once it starts copying data, it crashes in the comp > set. Yes, you can use this technique when booting from CD. On i386, at the "boot>" prompt, type in "-c" and press the Enter key. The kernel will load, but before doing any hardware discovery will issue a UKC prompt. If you type "verbose" and press Enter, then type "quit" and press Enter, you will get more detailed kernel probe output.
Re: new openbsd 4.0 server, panic on ufsdirhash
--- John Mendenhall <[EMAIL PROTECTED]> wrote: > > On Wed, May 16, 2007 at 09:30:44AM -0700, John Mendenhall wrote: > > > If anyone knows of a tool I can use to determine the ATA > > > controller, or any other hw things I need to find out, > > > please post any pointers. > > > > dmesg(8) > > Well, I posted the dmesg at the beginning of this thread. > Here is an excerpt with the ide/ata hardware: > > - > pciide0 at pci0 dev 7 function 1 "VIA VT82C571 IDE" rev 0x06: ATA100, > channel > 0 configured to compatibility, channel 1 configured to compatibility > wd0 at pciide0 channel 0 drive 0: > wd0: 16-sector PIO, LBA48, 117800MB, 241254720 sectors > wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 > wd1 at pciide0 channel 1 drive 0: > wd1: 16-sector PIO, LBA48, 114473MB, 234441648 sectors > - > > There may be more. > Please let me know if I need to repost it. > > > > Anyone know how to boot with more messages? > > > man boot doesn't show any verbose options. > > > > Use UKC (boot -c), and the "verbose" command. See boot_config(8). > > Is this supported when booting from cd? I can only boot from the > cd right now. Once it starts copying data, it crashes in the comp > set. The comp set isn't required to RUN OpenBSD. Install the minimal (kernel, base, etc) and I think that will get the system running. Then you can alter the booting mechanism (verbose) and make tweaks before loading comp. I'm hitting Google with your pciide0 string and for the 2 minutes of searching, all I see are various people having problems. Maybe because people won't complain or give this kind of information normally if things are working well. I'll continue to search... could you/would you install the minimal and work from there? Maybe it's corrupt on the source! CD pressed/burned badly. Older OpenBSD release working? couple of things to try... i'll look when I get a second or two. > JohnM > > -- > john mendenhall > [EMAIL PROTECTED] > surf utopia > internet services > If opportunity doesn't knock, build a door. "I can" is a way of life. More and Bigger is not always Better. The road to success is always uphill. Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz
Re: new openbsd 4.0 server, panic on ufsdirhash
> On Wed, May 16, 2007 at 09:30:44AM -0700, John Mendenhall wrote: > > If anyone knows of a tool I can use to determine the ATA > > controller, or any other hw things I need to find out, > > please post any pointers. > > dmesg(8) Well, I posted the dmesg at the beginning of this thread. Here is an excerpt with the ide/ata hardware: - pciide0 at pci0 dev 7 function 1 "VIA VT82C571 IDE" rev 0x06: ATA100, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: wd0: 16-sector PIO, LBA48, 117800MB, 241254720 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 wd1 at pciide0 channel 1 drive 0: wd1: 16-sector PIO, LBA48, 114473MB, 234441648 sectors - There may be more. Please let me know if I need to repost it. > > Anyone know how to boot with more messages? > > man boot doesn't show any verbose options. > > Use UKC (boot -c), and the "verbose" command. See boot_config(8). Is this supported when booting from cd? I can only boot from the cd right now. Once it starts copying data, it crashes in the comp set. JohnM -- john mendenhall [EMAIL PROTECTED] surf utopia internet services
Re: new openbsd 4.0 server, panic on ufsdirhash
On Wed, May 16, 2007 at 09:30:44AM -0700, John Mendenhall wrote: > If anyone knows of a tool I can use to determine the ATA > controller, or any other hw things I need to find out, > please post any pointers. dmesg(8) > Anyone know how to boot with more messages? > man boot doesn't show any verbose options. Use UKC (boot -c), and the "verbose" command. See boot_config(8).
Re: new openbsd 4.0 server, panic on ufsdirhash
> I don't know if Open would have any of those tools built in. I don't > have a "ready" openbsd box right now. If anyone knows of a tool I can use to determine the ATA controller, or any other hw things I need to find out, please post any pointers. > Google search for "thunderboot ultimate boot cd" doesn't reveal > anything. it suggested a spelling correction, for thunderboom, which > didn't easily reveal any bootable cd. A link to the ISO and I'd offer > what I can for diagnostics and probing solutions. The ultimate boot cd is something I got off ebay. Not a brand name, but lots of the tools we need for mem testing. > Is there a way to get the kernel to more verbosely announce what it's > probing and configuring, like what FreeBSD's boot loader's "-v" option > will do? Haven't tried, haven't looked anything up. Anyone know how to boot with more messages? man boot doesn't show any verbose options. > We are definately narrowing down the culprit, and I just hope we come > to a solid conclusion. Amen. Thanks! JohnM -- john mendenhall [EMAIL PROTECTED] surf utopia internet services
Re: new openbsd 4.0 server, panic on ufsdirhash
Linux OS'en (IIRC) use lspci like what pciconf is for FreeBSD. I don't know if Open would have any of those tools built in. I don't have a "ready" openbsd box right now. Google search for "thunderboot ultimate boot cd" doesn't reveal anything. it suggested a spelling correction, for thunderboom, which didn't easily reveal any bootable cd. A link to the ISO and I'd offer what I can for diagnostics and probing solutions. Is there a way to get the kernel to more verbosely announce what it's probing and configuring, like what FreeBSD's boot loader's "-v" option will do? Haven't tried, haven't looked anything up. We are definately narrowing down the culprit, and I just hope we come to a solid conclusion. --- John Mendenhall <[EMAIL PROTECTED]> wrote: > Tim, > > > John, since you were able to boot the ultimate boot cd and run both > > drives completely, I don't think any hardware is the culprit. Your > CD > > drive, Hard Drive(s), memory, etc all work under that OS. > > > > My mindset is now leading to some bug that OpenBSD is doing > (probably) > > with the ATA controller. Probe from the ultimate boot cd to see > what > > ATA controller it is using, and then find what OpenBSD is finding > the > > ATA controller to be. A minor model difference could be the > culprit > > (model 1234 versus model 1234a, for example). > > I am using the thunderboot ultimate boot cd. > Any hints on which tool could get the ata controller the box is > using? > I can see the ATA-# supported (6,5,4,3,2). Lots of other > information. > I don't see a model/version number yet. > > I will keep checking all the tools on here. > > JohnM > > -- > john mendenhall > [EMAIL PROTECTED] > surf utopia > internet services > If opportunity doesn't knock, build a door. "I can" is a way of life. More and Bigger is not always Better. The road to success is always uphill. You snooze, you lose. Get messages ASAP with AutoCheck in the all-new Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/newmail_html.html
Re: new openbsd 4.0 server, panic on ufsdirhash
Tim, > John, since you were able to boot the ultimate boot cd and run both > drives completely, I don't think any hardware is the culprit. Your CD > drive, Hard Drive(s), memory, etc all work under that OS. > > My mindset is now leading to some bug that OpenBSD is doing (probably) > with the ATA controller. Probe from the ultimate boot cd to see what > ATA controller it is using, and then find what OpenBSD is finding the > ATA controller to be. A minor model difference could be the culprit > (model 1234 versus model 1234a, for example). I am using the thunderboot ultimate boot cd. Any hints on which tool could get the ata controller the box is using? I can see the ATA-# supported (6,5,4,3,2). Lots of other information. I don't see a model/version number yet. I will keep checking all the tools on here. JohnM -- john mendenhall [EMAIL PROTECTED] surf utopia internet services
Re: new openbsd 4.0 server, panic on ufsdirhash
I (still) receive the digest, copied message without quoting characters - QUOTE: We have done a low level disk format using an ultimate boot cd. Didn't output any errors. Did this on both drives in the system. Took a very long time. Then, tried to install the OS. Received a panic on installing the comp set, ffs_valloc dup alloc. Reconfigured to have all install go to one drive. Same error, different inode. Tried all on other drive, same error, different inode. Kept trying it over and over. Always panicked on comp set. Always same error of ffs_valloc dup alloc. Always a different inode. I am unable to copy in the actual error. I just have this on a monitor in the room. No console capability. Same dmesg as before in this thread. I can post again if needed. My question is, to debug this, or fix it, do I need to start swapping out cables, hard disks, motherboard, etc? Any hints or suggestions are appreciated. Thanks in advance! JohnM /QUOTE John, since you were able to boot the ultimate boot cd and run both drives completely, I don't think any hardware is the culprit. Your CD drive, Hard Drive(s), memory, etc all work under that OS. My mindset is now leading to some bug that OpenBSD is doing (probably) with the ATA controller. Probe from the ultimate boot cd to see what ATA controller it is using, and then find what OpenBSD is finding the ATA controller to be. A minor model difference could be the culprit (model 1234 versus model 1234a, for example). Bug may not be the right word, but it's what's coming to mind. Not to steer away from OpenBSD, but if the three big BSDs all have trouble, we might be able to limit what might be the problem. FreeBSD operating system runs on a live CD either with their disc1 (install disk, look for the "fixit" option and then select "CD/DVD") start running things like dd and etc to run data on the drive. Nothing valuable there now anyway, is there? Maybe using a *rand device under /dev NetBSD doesn't have (AFAIK) a live-cd, but i'm pretty sure you can escape to shell from their installer. Run similar/same tools. get dmesg from both Free and Net while you're on it. save it to external medium (usb stick, floppy). Compare the findings to OpenBSD's dmesg. Basically, it boils down to the fact that one OS ran for several hours with CONSTANT hdd activity with no errors. I think it's a software problem, including drivers into the software category. Thanks! If opportunity doesn't knock, build a door. "I can" is a way of life. More and Bigger is not always Better. The road to success is always uphill. Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/
Re: new openbsd 4.0 server, panic on ufsdirhash
On Mon, 14 May 2007, Joachim Schipper wrote: > > We have done a low level disk format using an ultimate > > boot cd. Didn't output any errors. Did this on both > > drives in the system. Took a very long time. > > > > Then, tried to install the OS. Received a panic on > > installing the comp set, ffs_valloc dup alloc. > > Reconfigured to have all install go to one drive. > > Same error, different inode. Tried all on other drive, > > same error, different inode. Kept trying it over and > > over. Always panicked on comp set. Always same error > > of ffs_valloc dup alloc. Always a different inode. > > > > I am unable to copy in the actual error. I just have > > this on a monitor in the room. No console capability. > > > > Same dmesg as before in this thread. I can post again > > if needed. > > > > My question is, to debug this, or fix it, do I need > > to start swapping out cables, hard disks, motherboard, > > etc? Any hints or suggestions are appreciated. > > Running memtest86 is pretty painless, so that's usually a good first > step. Already done that. No errors. See previous thread, subject 'openbsd 4.0 server, new setup, getting panics', dated 5/1-5/3. JohnM -- john mendenhall [EMAIL PROTECTED] surf utopia internet services
Re: new openbsd 4.0 server, panic on ufsdirhash
On Mon, May 14, 2007 at 12:41:33PM -0700, John Mendenhall wrote: > > Or, perhaps, the drive is just going bad. I would have > > expected errors on installing the os if that were the > > case. > > We have done a low level disk format using an ultimate > boot cd. Didn't output any errors. Did this on both > drives in the system. Took a very long time. > > Then, tried to install the OS. Received a panic on > installing the comp set, ffs_valloc dup alloc. > Reconfigured to have all install go to one drive. > Same error, different inode. Tried all on other drive, > same error, different inode. Kept trying it over and > over. Always panicked on comp set. Always same error > of ffs_valloc dup alloc. Always a different inode. > > I am unable to copy in the actual error. I just have > this on a monitor in the room. No console capability. > > Same dmesg as before in this thread. I can post again > if needed. > > My question is, to debug this, or fix it, do I need > to start swapping out cables, hard disks, motherboard, > etc? Any hints or suggestions are appreciated. Running memtest86 is pretty painless, so that's usually a good first step. Joachim -- TFMotD: enc2xs (1) - Perl Encode Module Generator
Re: new openbsd 4.0 server, panic on ufsdirhash
> Or, perhaps, the drive is just going bad. I would have > expected errors on installing the os if that were the > case. We have done a low level disk format using an ultimate boot cd. Didn't output any errors. Did this on both drives in the system. Took a very long time. Then, tried to install the OS. Received a panic on installing the comp set, ffs_valloc dup alloc. Reconfigured to have all install go to one drive. Same error, different inode. Tried all on other drive, same error, different inode. Kept trying it over and over. Always panicked on comp set. Always same error of ffs_valloc dup alloc. Always a different inode. I am unable to copy in the actual error. I just have this on a monitor in the room. No console capability. Same dmesg as before in this thread. I can post again if needed. My question is, to debug this, or fix it, do I need to start swapping out cables, hard disks, motherboard, etc? Any hints or suggestions are appreciated. Thanks in advance! JohnM -- john mendenhall [EMAIL PROTECTED] surf utopia internet services
Re: new openbsd 4.0 server, panic on ufsdirhash
Tim, > > > - Quote -- > > > Date: Mon, 7 May 2007 10:29:50 -0700 > > > From: "John Mendenhall" <[EMAIL PROTECTED]> > > > To: "Artur Grabowski" <[EMAIL PROTECTED]> > > > CC: misc@openbsd.org > > > Subject: Re: new openbsd 4.0 server, panic on ufsdirhash > > > > > > Artur, > > > > > > We have done a forced fsck on the partition with the > > > error. The problem is, there is no data other than > > > the openbsd install. All I was trying to do was load > > > the source from the openbsd cd into /usr/src. > > > > > > I don't need to restore since this is a new machine. > > > I have not done anything to it. > > > > > > I'll just reinstall the entire thing. Unless someone > > > wants me to try something else. > > > > > > Thanks! > > > > > > JohnM > > > --- /QUOTE > > > > > > John, > > > I've heard, and seen, a lot of odd problems that can't be > > duplicated > > > with the same error when there's either of the following true. > > > > > > 1) overclocked hardware > > > 2) bad system memory > > > > > > I'm doubting your system memory, but I'm curious about your > > > overclocking. > > > > > > I don't think I've followed very carefully what you've already > > tried, > > > and wonder if the mindset has ever drifted away from Hard Drives > > and > > > ATA controllers. > > > > > > Another thread suggested catting /dev/ad0s1 >/dev/null and seeing > > how > > > many errors you get. If you get errors, it might point to what > > can't > > > be read (and maybe can't be written then). You might have to use > > > another tool, but you should get the jist of what I'm trying to > > > suggest. > > > > All hardware is as received, no overclocking is being done. > > > > The system memory was the first issue we had. I have set > > the bios such that the system memory gives no errors on very > > long memtest runs. > > > > Currently, we are running a low level format of the two disks. > > No errors yet, but will run another day or so. > > > > Then, we'll reinstall the os and see how it goes. > > 'cat'ting the drive is simply reading data from the surface and sending > it to the bitbucket, so we can see if we can read the surface of the > drive without errors. > > A low-level format is an interesting twist, and I would like to see if > that helps. I've witnessed myself a drive "with bad blocks" dissapear > after a high-level format. It was the oddest of things, the FS itself > was corrupted and a disk check didn't help the situation. Maybe it was > a glitch, I don't know. I put that drive back into rotation. We'll see how it goes. If I still get errors, I'll try to cat the drive to devnull and see what happens. It would be nice to get disk errors instead of a panic, though. Perhaps anything in a log file, or a console message. But, panic just stops everything and it's difficult to tell what actually happened. Or, perhaps, the drive is just going bad. I would have expected errors on installing the os if that were the case. Thanks! JohnM -- john mendenhall [EMAIL PROTECTED] surf utopia internet services
Re: new openbsd 4.0 server, panic on ufsdirhash
Replies interspersed. --- John Mendenhall <[EMAIL PROTECTED]> wrote: > Tim, > > On Tue, 08 May 2007, Tim Judd wrote: > > > - Quote -- > > Date: Mon, 7 May 2007 10:29:50 -0700 > > From: "John Mendenhall" <[EMAIL PROTECTED]> > > To: "Artur Grabowski" <[EMAIL PROTECTED]> > > CC: misc@openbsd.org > > Subject:Re: new openbsd 4.0 server, panic on ufsdirhash > > > > Artur, > > > > We have done a forced fsck on the partition with the > > error. The problem is, there is no data other than > > the openbsd install. All I was trying to do was load > > the source from the openbsd cd into /usr/src. > > > > I don't need to restore since this is a new machine. > > I have not done anything to it. > > > > I'll just reinstall the entire thing. Unless someone > > wants me to try something else. > > > > Thanks! > > > > JohnM > > --- /QUOTE > > > > John, > > I've heard, and seen, a lot of odd problems that can't be > duplicated > > with the same error when there's either of the following true. > > > > 1) overclocked hardware > > 2) bad system memory > > > > I'm doubting your system memory, but I'm curious about your > > overclocking. > > > > I don't think I've followed very carefully what you've already > tried, > > and wonder if the mindset has ever drifted away from Hard Drives > and > > ATA controllers. > > > > Another thread suggested catting /dev/ad0s1 >/dev/null and seeing > how > > many errors you get. If you get errors, it might point to what > can't > > be read (and maybe can't be written then). You might have to use > > another tool, but you should get the jist of what I'm trying to > > suggest. > > All hardware is as received, no overclocking is being done. > > The system memory was the first issue we had. I have set > the bios such that the system memory gives no errors on very > long memtest runs. > > Currently, we are running a low level format of the two disks. > No errors yet, but will run another day or so. > > Then, we'll reinstall the os and see how it goes. > > Why would I want to cat /dev/ad0s1? > Or, are you referring to the actual drive, which is /dev/wd0? I'm sorry, I switch between FreeBSD and OpenBSD so often, I don't catch myself often enough stating the right device name. This is the OpenBSD mailing list and I should have thought. I did mean OpenBSD's drive name, which would be wd0. 'cat'ting the drive is simply reading data from the surface and sending it to the bitbucket, so we can see if we can read the surface of the drive without errors. A low-level format is an interesting twist, and I would like to see if that helps. I've witnessed myself a drive "with bad blocks" dissapear after a high-level format. It was the oddest of things, the FS itself was corrupted and a disk check didn't help the situation. Maybe it was a glitch, I don't know. I put that drive back into rotation. > > Good luck. > > Thanks! You're welcome! > JohnM > > -- > john mendenhall > [EMAIL PROTECTED] > surf utopia > internet services > If opportunity doesn't knock, build a door. "I can" is a way of life. More and Bigger is not always Better. The road to success is always uphill. Don't get soaked. Take a quick peak at the forecast with the Yahoo! Search weather shortcut. http://tools.search.yahoo.com/shortcuts/#loc_weather
Re: new openbsd 4.0 server, panic on ufsdirhash
Tim, On Tue, 08 May 2007, Tim Judd wrote: > - Quote -- > Date: Mon, 7 May 2007 10:29:50 -0700 > From: "John Mendenhall" <[EMAIL PROTECTED]> > To: "Artur Grabowski" <[EMAIL PROTECTED]> > CC: misc@openbsd.org > Subject: Re: new openbsd 4.0 server, panic on ufsdirhash > > Artur, > > We have done a forced fsck on the partition with the > error. The problem is, there is no data other than > the openbsd install. All I was trying to do was load > the source from the openbsd cd into /usr/src. > > I don't need to restore since this is a new machine. > I have not done anything to it. > > I'll just reinstall the entire thing. Unless someone > wants me to try something else. > > Thanks! > > JohnM > --- /QUOTE > > John, > I've heard, and seen, a lot of odd problems that can't be duplicated > with the same error when there's either of the following true. > > 1) overclocked hardware > 2) bad system memory > > I'm doubting your system memory, but I'm curious about your > overclocking. > > I don't think I've followed very carefully what you've already tried, > and wonder if the mindset has ever drifted away from Hard Drives and > ATA controllers. > > Another thread suggested catting /dev/ad0s1 >/dev/null and seeing how > many errors you get. If you get errors, it might point to what can't > be read (and maybe can't be written then). You might have to use > another tool, but you should get the jist of what I'm trying to > suggest. All hardware is as received, no overclocking is being done. The system memory was the first issue we had. I have set the bios such that the system memory gives no errors on very long memtest runs. Currently, we are running a low level format of the two disks. No errors yet, but will run another day or so. Then, we'll reinstall the os and see how it goes. Why would I want to cat /dev/ad0s1? Or, are you referring to the actual drive, which is /dev/wd0? > Good luck. Thanks! JohnM -- john mendenhall [EMAIL PROTECTED] surf utopia internet services
Re: new openbsd 4.0 server, panic on ufsdirhash
I subscribe to the digest, so I've copied the message and excluded the quoting characters (>) - Quote -- Received:from a.mx.surfutopia.net (a.mx.surfutopia.net [69.63.196.98]) by shear.ucar.edu (8.14.1/8.13.6) with ESMTP id l47HTpuJ013519 for ; Mon, 7 May 2007 11:29:52 -0600 (MDT) Received: by a.mx.surfutopia.net (Postfix, from userid 1000) id 5B2B9F23B; Mon, 7 May 2007 10:29:50 -0700 (PDT) Date: Mon, 7 May 2007 10:29:50 -0700 From: "John Mendenhall" <[EMAIL PROTECTED]> To: "Artur Grabowski" <[EMAIL PROTECTED]> CC: misc@openbsd.org Subject: Re: new openbsd 4.0 server, panic on ufsdirhash Message-ID: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To:<[EMAIL PROTECTED]> User-Agent: Mutt/1.5.6i X-Archive-Number: 200705/407 X-Sequence-Number: 49945 Artur, > Have you done forced fsck of the partitions? This sounds like a > problem with the data you have on disk. It would be even nicer if you > could update to a newer fsck because it has been updated to deal with > many new strange corner cases we've been seeing. Although, that might > or might not require a fully -current system, I'm not fully aware of > everything that has been going in fsck, but some of the ffs2 support > might have messed things up. > > We've seen one of those panics recently on an important OpenBSD > infrastructure machine and that led to a lot of fsck work (since > fsck didn't catch the particular problem). But on production > machines we deal with filesystem corruption by simply dumping the > filesystem and restoring it from scratch. You might want to try > that as well. We have done a forced fsck on the partition with the error. The problem is, there is no data other than the openbsd install. All I was trying to do was load the source from the openbsd cd into /usr/src. I don't need to restore since this is a new machine. I have not done anything to it. I'll just reinstall the entire thing. Unless someone wants me to try something else. Thanks! JohnM -- john mendenhall [EMAIL PROTECTED] surf utopia internet services --- /QUOTE John, I've heard, and seen, a lot of odd problems that can't be duplicated with the same error when there's either of the following true. 1) overclocked hardware 2) bad system memory I'm doubting your system memory, but I'm curious about your overclocking. I don't think I've followed very carefully what you've already tried, and wonder if the mindset has ever drifted away from Hard Drives and ATA controllers. Another thread suggested catting /dev/ad0s1 >/dev/null and seeing how many errors you get. If you get errors, it might point to what can't be read (and maybe can't be written then). You might have to use another tool, but you should get the jist of what I'm trying to suggest. Good luck. If opportunity doesn't knock, build a door. "I can" is a way of life. More and Bigger is not always Better. The road to success is always uphill. Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: new openbsd 4.0 server, panic on ufsdirhash
Artur, > Have you done forced fsck of the partitions? This sounds like a > problem with the data you have on disk. It would be even nicer if you > could update to a newer fsck because it has been updated to deal with > many new strange corner cases we've been seeing. Although, that might > or might not require a fully -current system, I'm not fully aware of > everything that has been going in fsck, but some of the ffs2 support > might have messed things up. > > We've seen one of those panics recently on an important OpenBSD > infrastructure machine and that led to a lot of fsck work (since > fsck didn't catch the particular problem). But on production > machines we deal with filesystem corruption by simply dumping the > filesystem and restoring it from scratch. You might want to try > that as well. We have done a forced fsck on the partition with the error. The problem is, there is no data other than the openbsd install. All I was trying to do was load the source from the openbsd cd into /usr/src. I don't need to restore since this is a new machine. I have not done anything to it. I'll just reinstall the entire thing. Unless someone wants me to try something else. Thanks! JohnM -- john mendenhall [EMAIL PROTECTED] surf utopia internet services
Re: new openbsd 4.0 server, panic on ufsdirhash
I have yet to receive any response to the panics I have been experiencing. Is there something else I need to provide that will get me pointed in the right direction? Are there tools available to test the connection to the hard drive, or to test the hard drive itself? I used format when administering a sun box, which did a halfway decent job of running through the whole disk in analysis mode, which could test without destrying data, and could test while destroying data. What is available for openbsd? Or, can I just use something like the ultimate boot cd and run tests on the hard disks? Thanks in advance! JohnM On Fri, 04 May 2007, John Mendenhall wrote: > > Does this indicate I have a bad drive? Or, does it > > just need fsck run on it? I just installed openbsd 4.0 > > on this box a few days ago. It rebuilt the file systems > > from scratch. Do I need to redo everything? > > > > Or, do I need to start looking at hardware problems with > > the drive or the motherboard? > > > > Please let me know the next step to run that will help > > me get to a stable system. > > I tried viewing the file in error. I could run ls, but > not ls -l. > I went into single user mode and fscked the file system. > I removed the file. I did not get the inode or anything else > before removing it. > > I tried running the copy source command. > cd /usr/src; tar xzf /mnt/src.tar.gz > Another panic. > > panic #3: > - > mode = 0100644, inum = 106368, fs = /usr > panic: ffs_valloc: dup alloc > Stopped at Debugger+0x4: leave > RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC! > DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION! > ddb> > Debugger(d0716864,5080,e9e21b40,d6bb671c,d1265000) at Debugger+0x4 > panic(d06736fc,81a4,19f80,d12650d4,d1267e00) at panic+0x63 > ffs_inode_alloc(d6ab69dc,81a4,d6c141e0,e9e21b94) at ffs_inode_alloc+0x11b > ufs_makeinode(81a4,d6ab8ea0,e9e21e28,e9e21e3c) at ufs_makeinode+0x78 > ufs_create(e9e21d08,d6ab8ea0,d6b33710,d6c141e0,d07171c0) at ufs_create+0x26 > VOP_CREATE(d6ab8ea0,e9e21e28,e9e21e3c,e9e21d58) at VOP_CREATE+0x34 > vn_open(e9e21e18,e02,1a4,d6b33710) at vn_open+0xdf > sys_open(d6b33710,e9e21f68,e9e21f58,0,0) at sys_open+0xdb > syscall() at syscall+0x2ea > --- syscall (number 5) --- > 0x1c00e3e1: > ddb> >PID PPID PGRPUID S FLAGS WAIT COMMAND > 15475 20392 20392 0 3 0x4086 pipewr gzip > *20392 2075 20392 0 7 0x4006 tar > 20997 15943 20997 1000 3 0x4086 ttyin csh > 15943 9609 9609 1000 3 0x184 select sshd > 9609 14206 9609 0 3 0x4084 netio sshd > 14658 1 14658 0 3 0x4086 ttyin getty > 4737 1 4737 0 3 0x4086 ttyin getty > 13556 1 13556 0 3 0x4086 ttyin getty > 30631 1 30631 0 3 0x4086 ttyin getty > 2075 1 2075 1000 3 0x4086 pause csh > 6223 1 6223 0 30x84 select cron > 14206 1 14206 0 30x84 select sshd > 14369 24346 24346 83 3 0x184 poll ntpd > 24346 1 24346 0 30x84 poll ntpd > 1115 7685 7685 73 2 0x184 syslogd > 7685 1 7685 0 30x8c netio syslogd > 13 0 0 0 30x100204 crypto_wa crypto > 12 0 0 0 30x100204 aiodoned aiodoned > 11 0 0 0 30x100204 syncer update > 10 0 0 0 30x100204 cleanercleaner > 9 0 0 0 30x100204 reaper reaper > 8 0 0 0 30x100204 pgdaemon pagedaemon > 7 0 0 0 30x100204 pftm pfpurge > 6 0 0 0 30x100204 wait wskbd_hotkey > 5 0 0 0 30x100204 usbtsk usbtask > 4 0 0 0 30x100204 usbevt usb0 > 3 0 0 0 30x100204 apmev apm0 > 2 0 0 0 30x100204 kmallockmthread > 1 0 1 0 3 0x4084 wait init > 0 -1 0 0 3 0x80204 scheduler swapper > ddb> > - > > So, back to my real question. > Does this indicate a bad drive? > Does this indicate a bad cable? > Do I need to start swapping out parts to see where the problem is? > Or, is there somewhere else I should be looking? > > Thanks in advance for any pointers. > > JohnM > > > > > > > panic #1: > > - > > panic: kernel diagnostic assertion "(dirblo
Re: new openbsd 4.0 server, panic on ufsdirhash
> Does this indicate I have a bad drive? Or, does it
> just need fsck run on it? I just installed openbsd 4.0
> on this box a few days ago. It rebuilt the file systems
> from scratch. Do I need to redo everything?
>
> Or, do I need to start looking at hardware problems with
> the drive or the motherboard?
>
> Please let me know the next step to run that will help
> me get to a stable system.
I tried viewing the file in error. I could run ls, but
not ls -l.
I went into single user mode and fscked the file system.
I removed the file. I did not get the inode or anything else
before removing it.
I tried running the copy source command.
cd /usr/src; tar xzf /mnt/src.tar.gz
Another panic.
panic #3:
-
mode = 0100644, inum = 106368, fs = /usr
panic: ffs_valloc: dup alloc
Stopped at Debugger+0x4: leave
RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
ddb>
Debugger(d0716864,5080,e9e21b40,d6bb671c,d1265000) at Debugger+0x4
panic(d06736fc,81a4,19f80,d12650d4,d1267e00) at panic+0x63
ffs_inode_alloc(d6ab69dc,81a4,d6c141e0,e9e21b94) at ffs_inode_alloc+0x11b
ufs_makeinode(81a4,d6ab8ea0,e9e21e28,e9e21e3c) at ufs_makeinode+0x78
ufs_create(e9e21d08,d6ab8ea0,d6b33710,d6c141e0,d07171c0) at ufs_create+0x26
VOP_CREATE(d6ab8ea0,e9e21e28,e9e21e3c,e9e21d58) at VOP_CREATE+0x34
vn_open(e9e21e18,e02,1a4,d6b33710) at vn_open+0xdf
sys_open(d6b33710,e9e21f68,e9e21f58,0,0) at sys_open+0xdb
syscall() at syscall+0x2ea
--- syscall (number 5) ---
0x1c00e3e1:
ddb>
PID PPID PGRPUID S FLAGS WAIT COMMAND
15475 20392 20392 0 3 0x4086 pipewr gzip
*20392 2075 20392 0 7 0x4006 tar
20997 15943 20997 1000 3 0x4086 ttyin csh
15943 9609 9609 1000 3 0x184 select sshd
9609 14206 9609 0 3 0x4084 netio sshd
14658 1 14658 0 3 0x4086 ttyin getty
4737 1 4737 0 3 0x4086 ttyin getty
13556 1 13556 0 3 0x4086 ttyin getty
30631 1 30631 0 3 0x4086 ttyin getty
2075 1 2075 1000 3 0x4086 pause csh
6223 1 6223 0 30x84 select cron
14206 1 14206 0 30x84 select sshd
14369 24346 24346 83 3 0x184 poll ntpd
24346 1 24346 0 30x84 poll ntpd
1115 7685 7685 73 2 0x184 syslogd
7685 1 7685 0 30x8c netio syslogd
13 0 0 0 30x100204 crypto_wa crypto
12 0 0 0 30x100204 aiodoned aiodoned
11 0 0 0 30x100204 syncer update
10 0 0 0 30x100204 cleanercleaner
9 0 0 0 30x100204 reaper reaper
8 0 0 0 30x100204 pgdaemon pagedaemon
7 0 0 0 30x100204 pftm pfpurge
6 0 0 0 30x100204 wait wskbd_hotkey
5 0 0 0 30x100204 usbtsk usbtask
4 0 0 0 30x100204 usbevt usb0
3 0 0 0 30x100204 apmev apm0
2 0 0 0 30x100204 kmallockmthread
1 0 1 0 3 0x4084 wait init
0 -1 0 0 3 0x80204 scheduler swapper
ddb>
-
So, back to my real question.
Does this indicate a bad drive?
Does this indicate a bad cable?
Do I need to start swapping out parts to see where the problem is?
Or, is there somewhere else I should be looking?
Thanks in advance for any pointers.
JohnM
> panic #1:
> -
> panic: kernel diagnostic assertion "(dirblock < dh->dh_nblk &&
> dh->dh_blkfree[dirblock] >= (((slotneeded) + ((4) - 1)) / (4)))" failed: file
> "/usr/src/sys/ufs/ufs/ufs_dirhash.c", line 510
> panic #2:
> -
> panic: ufsdirhash_findslot: 'crash66.C' not found
> dmesg:
> -
> OpenBSD 4.0 (GENERIC) #1107: Sat Sep 16 19:15:58 MDT 2006
> [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
> cpu0: AMD Duron(tm) Processor ("AuthenticAMD" 686-class, 64KB L2 cache) 1.21
> GHz
> cpu0:
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,S
> SE
> real mem = 528052224 (515676K)
> avail mem = 473726976 (462624K)
> using 4256 buffers containing 26505216 bytes (25884K) of memory
> mainbus0 (root)
> bios0 at mainbus0: AT/286+(00) BIOS, date 02/08/02, BIOS32 rev. 0 @ 0xfdb30,
> SMBIOS rev. 2.3 @ 0xf0630 (24 entries)
> bios0: ECS M821LR
> apm0 at bios0: Power
new openbsd 4.0 server, panic on ufsdirhash
I am attempting to get the source copied from the cd to /usr/src. I ran the tar command to extract the source from the cd. The system panicked after a minute or two. After this, I rebooted. When it came up, I went to the src dir to see what was there. I tried removing the partial set of files. It panicked after just a short time. The dmesg is at the bottom. Does this indicate I have a bad drive? Or, does it just need fsck run on it? I just installed openbsd 4.0 on this box a few days ago. It rebuilt the file systems from scratch. Do I need to redo everything? Or, do I need to start looking at hardware problems with the drive or the motherboard? Please let me know the next step to run that will help me get to a stable system. Thanks! JohnM panic #1: - panic: kernel diagnostic assertion "(dirblock < dh->dh_nblk && dh->dh_blkfree[dirblock] >= (((slotneeded) + ((4) - 1)) / (4)))" failed: file "/usr/src/sys/ufs/ufs/ufs_dirhash.c", line 510 Stopped at Debugger+0x4: leave RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC! DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION! ddb> Debugger(40,e9e27b88,e9e27b70,3,d6a8d690) at Debugger+0x4 panic(d0660c40,d06305f7,d0675ea0,d0675e20,1fe) at panic+0x63 tablefull(d06305f7,d0675e20,1fe,d0675ea0,d07172c0) at tablefull ufsdirhash_findfree(d6a8d690,18,e9e27c3c,e9e27e3c) at ufsdirhash_findfree+0x94 ufs_lookup(e9e27c68,e9e27e3c,e9e27c80,d035162e,d0717180) at ufs_lookup+0x18e VOP_LOOKUP(d6a8c444,e9e27e28,e9e27e3c,20) at VOP_LOOKUP+0x2e lookup(e9e27e18,d6c02c00,400,e9e27e30) at lookup+0x1d0 namei(e9e27e18,d1167310,e9e27d60,1e4940) at namei+0x180 vn_open(e9e27e18,e02,1a4,d6b2bcb0) at vn_open+0x7b sys_open(d6b2bcb0,e9e27f68,e9e27f58,0,0) at sys_open+0xdb syscall() at syscall+0x2ea --- syscall (number 5) --- 0x1c00e3e1: ddb>PID PPID PGRPUID S FLAGS WAIT COMMAND 30524 14560 14560 0 3 0x4086 pipewr gzip *14560 16456 14560 0 7 0x4006 tar 16456 14200 16456 1000 3 0x4086 pause csh 14200 14618 14618 1000 3 0x184 select sshd 14618 19009 14618 0 3 0x4084 netio sshd 4633 1 4633 0 3 0x4086 ttyin getty 11447 1 11447 0 3 0x4086 ttyin getty 18246 1 18246 0 3 0x4086 ttyin getty 22102 1 22102 0 3 0x4086 ttyin getty 11015 1 11015 0 3 0x4086 ttyin getty 27803 1 27803 0 30x84 select cron 26298 1 26298 0 3 0x40184 select sendmail 19009 1 19009 0 30x84 select sshd 12832 1 12832 0 3 0x184 select inetd 10395 26437 26437 83 3 0x184 poll ntpd 26437 1 26437 0 30x84 poll ntpd 1666 2020 2020 73 3 0x184 poll syslogd 2020 1 2020 0 30x8c netio syslogd 13 0 0 0 30x100204 crypto_wa crypto 12 0 0 0 30x100204 aiodoned aiodoned 11 0 0 0 30x100204 syncer update 10 0 0 0 30x100204 cleanercleaner 9 0 0 0 30x100204 reaper reaper 8 0 0 0 30x100204 pgdaemon pagedaemon 7 0 0 0 30x100204 pftm pfpurge 6 0 0 0 30x100204 wait wskbd_hotkey 5 0 0 0 30x100204 usbtsk usbtask 4 0 0 0 30x100204 usbevt usb0 3 0 0 0 30x100204 apmev apm0 2 0 0 0 30x100204 kmallockmthread 1 0 1 0 3 0x4084 wait init 0 -1 0 0 3 0x80204 scheduler swapper - panic #2: - WARNING: / was not properly unmounted panic: ufsdirhash_findslot: 'crash66.C' not found Stopped at Debugger+0x4: leave RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC! DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION! ddb> Debugger(d6c53118,0,2000,d12e4220,400) at Debugger+0x4 panic(d0676280,9,ddafa748,d12e4220,7ff) at panic+0x63 ufsdirhash_delslot(d12e5c00,ddafa748,9,740,d6b99b38) at ufsdirhash_delslot ufsdirhash_remove(d6b99d30,ddafa740,740,d12e5c00) at ufsdirhash_remove+0x3c ufs_dirremove(d6b9f1d4,d6b99b38,800c,0) at ufs_dirremove+0x6b ufs_remove(e9e27e88,d6b9f30c,d6b309e0,d6c141e0,d0717580) at ufs_remove+0x9b VOP_REMOVE(d6b9f1d4,d6b9f30c,e9e27edc,2) at VOP_REMOVE+0x2e sys_unlink(d6b309e0,e9e27f68,e9e27f58,b,252) at sys_unlink+0x80 syscall() at syscall+0x2ea --- syscall (number 10) --- 0x1c007f95: ddb> syncing disks... 31 28 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 giving up rebooting... - dmesg: - OpenBSD 4.0 (GENERIC) #1107: Sat Sep 16 19:15:58 MDT 2006 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENER
