Re: KINDLY HELP : error while kldloading a pci,character driver
On Wednesday 21 September 2005 15:38, rashmi ns wrote: > Amazing, Thanks a lot it really works . > Now i have to read what D_VERSION does :-) It's just there to mark what cdevsw API version the module was compiled with so if it changes it will prevent you loading modules than won't fit the cdevsw framework. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgp2xhsNiLI8e.pgp Description: PGP signature
Re: KINDLY HELP : error while kldloading a pci,character driver
Hi, Amazing, Thanks a lot it really works . Now i have to read what D_VERSION does :-) Thanks , Rashmi.N.S ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: KINDLY HELP : error while kldloading a pci,character driver
On Wednesday 21 September 2005 15:09, rashmi ns wrote: > .d_name = "hdlc_cdev", > .d_maj = CDEV_MAJOR, /*251*/ > .d_open = hdlc_open, > .d_read = hdlc_read, > but why do i get this error You need .d_version = D_VERSION, in your cdevsw. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpGfjT3McFTL.pgp Description: PGP signature
KINDLY HELP : error while kldloading a pci,character driver
Hi All,
This is the output of dmesg i get when i kldload my module
*
mem 0x4030-0x40300fff irq 11 at device
11.0 on pci1
WARNING: Device driver "hdlc_cdev" has wrong version and is disabled.
Recompile KLD module.
*
In attach function of pci driver i'll try to create character device
interface i just register this like this
sc->hdlc_cdev = make_dev (&hdlc_cdevsw,0, UID_ROOT,
GID_WHEEL, 0600, "hdlc_cdev");
where
static struct cdevsw hdlc_cdevsw = {
.d_name = "hdlc_cdev",
.d_maj = CDEV_MAJOR, /*251*/
.d_open = hdlc_open,
.d_read = hdlc_read,
};
in read and write functions i just have some printf statements inorder to test .
when i do
ls -l /dev/hdlc_cdev
crw--- 1 root wheel 251, 0 Sep 20 19:38 /dev/hdlc_cdev
cat /dev/hdlc_cdev
cat: /dev/hdlc_cdev: Device not configured
but why do i get this error
Thanks in Advance ,
Rashmi.N.S
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HP DL140g2 with serial ata hangs at ata0-master identifying
On Tue, Sep 20, 2005 at 02:59:23PM -0700, Ulf Zimmermann wrote: > I am trying to install 5.4-REL on a HP DL140g2 which has serial > ata inside, but also pata interfaces (for like the cdrom) but no > option to disable the said pata ports. And 5.4-rel install boot only > cd is hanging at ata0-master identify. Is there a way to tell the > kernel not to probe ata0? It hasn't even gone through it to find > the sata controller. Ok I looked a bit closer, the ata0-master identify timeouts are actually the serial drive. It finds the ICH5 controller, but then fails at the sata drive (160GB Maxtor). Anyone have an idea what else to look for? System boots RedHat EL3 fine. -- Regards, Ulf. - Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 You can find my resume at: http://seven.Alameda.net/~ulf/resume.html ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
HP DL140g2 with serial ata hangs at ata0-master identifying
I am trying to install 5.4-REL on a HP DL140g2 which has serial ata inside, but also pata interfaces (for like the cdrom) but no option to disable the said pata ports. And 5.4-rel install boot only cd is hanging at ata0-master identify. Is there a way to tell the kernel not to probe ata0? It hasn't even gone through it to find the sata controller. -- Regards, Ulf. - Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 You can find my resume at: http://seven.Alameda.net/~ulf/resume.html ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic in propagate_priority w/ postgresql under heavy load
On Monday 19 September 2005 03:35 pm, Koen Martens wrote: > Vinod Kashyap wrote: > > You seem to be booting off of a 9000 (twa) controller and not 7000/8000 > > (twe). > > It could be because of a 9000 firmware bug that you are not being able > > to > > get the dump. The firmware wrongly interprets physical address 0x0 as > > invalid > > during dumps, and fails the operations. This bug will be fixed in > > future > > firmware releases. > > Ok, it's been a while, here is an update on this. > > I ran a heavily instrumented kernel for two weeks on the server, it > did not crash in that time. I then took out the witness and kdb/ddb > stuff, because the decreased performance was a bit of a nuisance, > however i retained the ability to obtain a crash dump. I had to > limit physical memory, put it on 1.8GB in loader.conf:hw.physmem > because swap and physmem are both 2GB. Tested with 'reboot -d' gave > me a core dump. > > Without the debug stuff in the kernel, it crashed within 2 days, > same story: postgresql process, function propagate_priority. > However, no dump was written to disk :( > > Furthermore, i've been seeing the same crash (in propagate_priority) > on another box in mysql processes. Both servers seem to panic every > 2-3 days. I have another server of the exact same hardware > configuration, but it is mainly idling most of the time. Haven't > seen that one crash yet. > > I am thinking now that it is a bug in the twa driver, so i'll have > to dig in to that. Furthermore, it seems to have to do with some > sort of concurrency issue or otherwise timing-sensitive issue, > because slowing the kernel down with debug code seems to avoid the > panic. But, as i am completely new to the freebsd kernel and don't > even know what turnstiles are, i imagine i will have a hard time. So > if anyone can offer some help, please :) > > Ok, thanks for your attention, This panic usually happens either because a thread went to sleep while holding a mutex (WITNESS will warn you about this when it happens, but as you noted, it slows things down). It can also happen perhaps if a thread exits while holding a lock or if a thread is blocked on a mutex that is destroyed after it blocks on it. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Filesystem access from a KLD causes "vrele: negative ref cnt" panic
Hello, When the following kernel code has been run : struct thread *td = curthread; struct nameidata nd; int flags, resid; struct vattr vat; /* Some threads don't have a current working directory, set this to avoid a page fault on vn_open() call */ if(td->td_proc->p_fd->fd_rdir == NULL) td->td_proc->p_fd->fd_rdir = rootvnode; if(td->td_proc->p_fd->fd_cdir == NULL) td->td_proc->p_fd->fd_cdir = rootvnode; NDINIT(&nd, LOOKUP, FOLLOW, UIO_SYSSPACE, &filename[0], td); flags = FREAD; vn_open(&nd, &flags, 0, -1); NDFREE(&nd, NDF_ONLY_PNBUF); /* Get the file size. */ VOP_GETATTR(nd.ni_vp, &vat, td->td_ucred, td); VOP_UNLOCK(nd.ni_vp, 0, td); vn_rdwr(UIO_READ, nd.ni_vp, buf, vat.va_size, 0, UIO_SYSSPACE, IO_NODELOCKED, td->td_ucred, NOCRED, &resid, td); vn_close(nd.ni_vp, FREAD, td->td_ucred, td); I have a random panic "vrele: negative ref cnt" when I shutdown the system. Am I double-freeing something in my code ? The fact that the panic is caused randomly suggests there is a synchronization problem - but the above code is always running under the protection of the Giant mutex. Regards, Sebastien PS: This was previously posted on freebsd-fs, but got no answers. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic in propagate_priority w/ postgresql under heavy load
On Mon, 19 Sep 2005, Koen Martens wrote: Without the debug stuff in the kernel, it crashed within 2 days, same story: postgresql process, function propagate_priority. However, no dump was written to disk :( Furthermore, i've been seeing the same crash (in propagate_priority) on another box in mysql processes. Both servers seem to panic every 2-3 days. I have another server of the exact same hardware configuration, but it is mainly idling most of the time. Haven't seen that one crash yet. I am thinking now that it is a bug in the twa driver, so i'll have to dig in to that. Furthermore, it seems to have to do with some sort of concurrency issue or otherwise timing-sensitive issue, because slowing the kernel down with debug code seems to avoid the panic. But, as i am completely new to the freebsd kernel and don't even know what turnstiles are, i imagine i will have a hard time. So if anyone can offer some help, please :) Ok, thanks for your attention, I can't speak to the problem with the core dumps, as it sounds like that is device/firmware related. However, I probably can lend a hand in debugging the problems you're seeing. First off, propagate_priority() is part of the priority propagation mechanism associated with mutexes, which are a locking primitive in the FreeBSD kernel. Most panic in propagate_priority() are actually the result of a corrupted mutex, and when the mutex code goes to perform priority propagation, it trips over bad pointers and panics in some form of another. Often, this means the actual panic or failure has not occurred in the thread that prints out the panic you see, but another panic. So the first task on hitting a propagate_priority() panic is to identify the thread that actually had the problem. Usually, I do this from DDB, rather than a core dump, because I find that DDB's tools for inspect running state are a little easier to use. First, I identify what code called into the mutex call that resulted in propagate_priority() being called. The reason to do this is that what you want to do next is use "ps" and "trace" to identify other processes/threads in the same code, and hence likely to have caused a problem with the mutex storage in memory. Generally, you're looking for a panic in another thread, so once you identify a set of threads that might be to blame, you can trace them to find one that is in panic(). Usually, that thread will be in the RUN state, or on an SMP box, possibly running on another CPU. If you're running 6.x, the thread that panicked was likely preempted as it had problems, perhaps due to an untimely interrupt. If you want to do this by e-mail so we can lend a hand, you probably want to hook up a serial console so you can copy and paste the debugging session. Compile DDB into the kernel (this should have no performance overhead), and when the system panics, you'll (ideally) get a db> prompt. The panic message and any related context (such as trap information) is useful. I usually then use "show percpu" to see what CPU I'm running on, the thread that's running, etc. I'll then use "trace" with no argument to see the stack of the thread. If I'm trying to find another thread that may have been preempted, I'll use "ps" to show the running processes and threads, then "trace " to trace the main thread of processes that look interesting. Generally, those in the RUN state, because the thread will be runnable. If you're running on an SMP system, you may occasionally find that information to inspect the stacks of threads currently running on other processors may not be consistently in memory -- i.e., cached, the stack frame is partially written, or whatever. There's a kernel option, KDB_STOP_NMI, which when combined with a sysctl, will cause the debugger to deliver an NMI IPI instead of a debug IPI, which may help kick those processors into the debugger if they are stuck in spin locks. However, the chances are fairly good this isn't the case so you're probably fine without it. Robert N M Watson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
real time prio
Hi I'm having a combination of linux and freebsd OSes running a reltime system. On linux I use the sched_setscheduler together with raised priority to get realtime characteristics. I see that the same system calls are implemented in freebsd can I use the same approach or should the rtprio(1) wrapper be used. Mats ___ This e-mail communication (and any attachment/s) may contain confidential or privileged information and is intended only for the individual(s) or entity named above and to others who have been specifically authorized to receive it. If you are not the intended recipient, please do not read, copy, use or disclose the contents of this communication to others. Please notify the sender that you have received this e-mail in error by reply e-mail, and delete the e-mail subsequently. Thank you. _ Ce message (ainsi que le(s) fichier/s), transmis par courriel, peut contenir des renseignements confidentiels ou protégés et est destiné à l’usage exclusif du destinataire ci-dessus. Toute autre personne est par les présentes avisée qu’il est strictement interdit de le diffuser, le distribuer ou le reproduire. Si vous l’avez reçu par inadvertance, veuillez nous en aviser et détruire ce message. Merci. _ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
