Javen,
I use ddi_intr_add_handler() to attached ISR and in my detach routine,
the ddi_intr_remove_handler() is set also. The question are
(1) when "#rem_drv mydriver" is run, there is no call to my detach routine
(2) I run "#rem_drv mydriver", then reboot system and run "#add_drv -i
'"pci1103,0"' -c scsi mydriver". Then this problem occurs immediately.
Any advice?
Steve
-----Original Message-----
From: Javen Wu [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 27, 2008 6:45 PM
To: Steve Chang
Cc: driver-discuss@opensolaris.org
Subject: Re: [driver-discuss] SCSI HBA driver debugging questions
The question is whether you remove the interrupt in your detach routine?
I don't know which ddi interface you used.
If you used ddi_intr_add_handler() in your attach routine, did you call
ddi_intr_remove_handler() in your detach routine?
Javen
Steve Chang wrote:
>Javen,
>During debugging, I found some issue not related to my driver
>
>(1) use the following to remove previous attached driver
> #rem_drv mydriver
>(2) Then use the following to add driver immediately
> #add_drv -i '"pci1103,0"' -c scsi mydriver
> (Where pci1103,0 is HBA PCI ID)
>
> The kernel go panic immediately, and from the trace, kernel just
> dispatches the interrupt to my ISR which is a NULL pointer so
> kernel panic. How come kernel doestn't start from _init() procedure
> and still remember my ISR entry point?
>
> Does it mean that "#rem_drv mydriver" can't clean up attached
> Driver?
>
>
>Thanks
>Steve
>
>
>
>-----Original Message-----
>From: Javen Wu [mailto:[EMAIL PROTECTED]
>Sent: Thursday, March 27, 2008 1:35 AM
>To: Steve Chang
>Cc: driver-discuss@opensolaris.org
>Subject: Re: [driver-discuss] SCSI HBA driver debugging questions
>
>Setup serial console:
>
>1. connect the serial ports between host and client(the system with your
>debug version driver).
>2. change client side:
>change /boot/solaris/bootenv.rc: change the console from 'text' to 'ttya'
>example:
>setprop console 'ttya'
>I assume you connect ttya of the client.
>
>3. change host side: /etc/remote, and add one existing line or add a
>line. below is a example:
>hardwire:\
> :dv=/dev/term/a:br#9600:el=^C^S^Q^U^D:ie=%$:oe=^D:
>
>4. change grub menulist of client to redirect GRUB:
>add below two sentence to your /boot/grub/menu.lst:
>
> serial --unit=0 --speed=9600
> terminal serial
>
>
>Above /dev/term/a means I connect to ttya of host side.
>5. on your host terminal run: "tip hardwire".
>
>you can enable kmdb by default by add -k option to your grub menulist like:
>#---------- ADDED BY BOOTADM - DO NOT EDIT ----------
>title Solaris Express Community Edition snv_84 X86
>kernel$ /platform/i86pc/kernel/$ISADIR/unix -k
>module$ /platform/i86pc/$ISADIR/boot_archive
>#---------------------END BOOTADM--------------------
>
>
>Good luck!
>Javen
>
>Steve Chang wrote:
>
>
>
>>Javen,
>>Can you instruct me how to set up kmdb and serial connection?
>>I can't figure out the instruction in doc "Writing Device Driver"
>>
>>My platform is "x86pc"
>>(1) During booting, I select "e" and change 1st item to boot
>> with Kmdb with "-k" but the system boot up maintenance
>> mode. How to configure it as you said?
>>
>>(2) As for setting serial port, on host side, I add "ttya -debug"
>> And enable it with "tip debug". On target side, I use "eeprom
>> Output-device=ttya" but no response with reboot or after panic
>> To get output on "host system"
>>
>>Thanks
>>
>>Steve
>>
>>
>>
>>-----Original Message-----
>>From: Javen Wu [mailto:[EMAIL PROTECTED]
>>Sent: Monday, March 24, 2008 2:16 AM
>>To: Steve Chang
>>Cc: driver-discuss@opensolaris.org
>>Subject: Re: [driver-discuss] SCSI HBA driver debugging questions
>>
>>Steve,
>>
>>Firstly, I saw several panic in your attached sys-log. The panics were
>>caused most likely by your driver.
>>
>>I cannot understand what's your meaning about "kernel stop" "Locks-up"?
>>Did you mean "Panic" and "Hang"?
>>
>>From your syslog, I cannot give any comments. But I can give you some
>>suggestion for debugging your HBA driver.
>>
>>1. Before your driver get stable, please don't copy you debug version
>>driver to /kernel/drv or /usr/kernel/drv
>>because once your driver is with panic bug, you will panic again and
>>again which prevent you booting up system successfully.
>>So please just create a link under /kernel/drv/ or /usr/kernel/drv/
>>which point to a binary locates at /tmp. Before you load your driver,
>>copy your binary to /tmp. The contents under directory "/tmp" cannot
>>across reboot, that means once panic causes reboot, the link points to a
>>NULL file locates /tmp after reboot, you can boot your system
successfully.
>>
>>2. Please enable kmdb during debug. you can use -k option to boot your
>>system. Once meet panic, the system would freeze and you can do live
>>analyze or save core dump for post-analyze.
>>
>>3. In case a hang problem, you can try break the system enter into kmdb
>>mode or login to the machine by ssh from another machine and run "mdb
>>-KF". Then force save a core dump or do live debugging to check current
>>thread list and see where the system hang. "$threadlist" is very helpful
>>to show threads and stack of the threads.
>>
>>Hope it helps your debugging.
>>
>>Cheers
>>Javen
>>
>>
>>
>>Steve Chang wrote:
>>
>>
>>
>>
>>
>>>Dear Javen,
>>>I've struggled on debugging for a while. Can you point out what's wrong
>>>through the
>>>attached file(through var/adm/messages)?
>>>
>>>My target system is a dual Intel Xeon server board platform and install a
>>>Solaris Developer Extension version (09/07). During debugging,
>>>(1) I put mydriver to /usr/kernel/drv/amd64 and mydriver.conf to
>>>/usr/kernel/drv
>>>(2) Use "prtconf" to check the HBA PCI id which I found our HBA
>>>
>>>
>"pci1103,0"
>
>
>>> (driver not attached)
>>>(3) Install driver (as a superuser)
>>> #add_drv -i '"pci1103,0"' -c scsi mydriver
>>>(4) Then system locks up
>>>(5) Fix the kernel and check /var/adm/messages
>>>
>>>There are two text files in this attached which run the same procedures
>>>
>>>
>two
>
>
>>>times
>>>But get the different result.
>>>1. DEB - the 1st time running
>>> Kerenl stops after ID=9 scsi_hba_probe() return ??
>>>2. DEB - fix the system and run the same procedure again
>>> Kernel send ID=14 directly and locks up after ID=15
>>>scsi_hba_probe() return ??
>>>
>>>What's wrong of the kernel? Is it caused by bad kernel or my code? If I
>>>
>>>
>>>
>>>
>>keep
>>
>>
>>
>>
>>>fixing the
>>>kernel and retry again, I'll get the different result lock-up again. It
is
>>>bothering me
>>>since I cannot debug my driver. How to make it more stable to run the
>>>debugging?
>>>
>>>Thanks
>>>
>>>Steve Chang
>>>HighPoint Technologies, Inc.
>>>408-240-6115
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
_______________________________________________
driver-discuss mailing list
driver-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
