Steve, I noticed that below two sentances:Your first test:
==> /[EMAIL PROTECTED],0/pci8086,[EMAIL PROTECTED]/[EMAIL PROTECTED],[EMAIL PROTECTED]/[EMAIL PROTECTED],0 That meas target0 lun0 of [EMAIL PROTECTED],[EMAIL PROTECTED] is a disk, so the following command sequence issued by sd driver. But second time, ==> ses0 is /[EMAIL PROTECTED],0/pci8086,[EMAIL PROTECTED]/pci1103,[EMAIL PROTECTED]/[EMAIL PROTECTED],0 That means target0 lun0 of *pci1103,[EMAIL PROTECTED] is a enclosure device. The following command sequence issued by ses driver. As I said before, solaris configuration is a multi-threading, so the any of your two instances(two channel) can be configured firstly. Actually, the squence of configuring two instances([EMAIL PROTECTED],[EMAIL PROTECTED] , *pci1103,[EMAIL PROTECTED]) is random. I don't see any problem here. Javen Steve Chang 写道: > Javen, > Here is a question - > Two disks are connected on HBA channels(channel 0 & 1) and > run two times (reboot system and start the test) but got > two different results. > > case I: kernel processes ID0 first then ID1 scanning > ID0 cmd flow ==> 12 -12 -00 -5a -46 -46 -1b -25 -25 -00 -1b -00 -1a > -5e > ==> sd1 at hptiop0 > ==> /[EMAIL PROTECTED],0/pci8086,[EMAIL > PROTECTED]/[EMAIL PROTECTED],[EMAIL PROTECTED]/[EMAIL PROTECTED],0 > Then ID1 cmd flow ==> 12 -12 -00 -5a -46 -46 -1b -25 -25 -00 -1b -00 -1a > -5e > ==> sd2 at hptiop0 > ==> /[EMAIL PROTECTED],0/pci8086,[EMAIL > PROTECTED]/[EMAIL PROTECTED],[EMAIL PROTECTED]/[EMAIL PROTECTED],0 > > > Case II: kernel processes ID0, ID1 ,, ID15 then back to ID0 again > Cmd flow [cmd(id)] ==> 12(0) --12(1) --12(2) ... -12(15) > Then cmd(id) ==> 12(0) --12(0) --1c(0) > ==> ses 0 at hptiop0:target0/lun0 > ==> ses0 is /[EMAIL PROTECTED],0/pci8086,[EMAIL > PROTECTED]/pci1103,[EMAIL PROTECTED]/[EMAIL PROTECTED],0 > > > Q: Why same procedure but can't get a consistent result during test? > Does it mean the return value of inquiry(0x12) incorrect? > > > Regards, > 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
