Steve Chang wrote: >Javen, >But will SD driver and SES driver handle the same >way since my HBA is for hard disk? > No. sd(7D)/ses(7D) handle disk and enclosure device in different way. You can take a look at sdattach() and ses_attach() which do different thing, so that's why you see different command sequence. Oh? I don't think your HBA driver only support hard disk. I remembered you mentioned your HBA accept SCSI CDB. So you just bypass the SPC/SBC/SSC/SMC command to HBA through your driver. So you can see your HBA driver detects a SES and attached successfully.
> Or I don't need >to care about it? > > For your HBA driver, so far you don't need care the different type of SCSI devices. Your HBA driver just bypass SCSI CDB regardless what kind of command and target device is. Javen > >Steve > > >-----Original Message----- >From: Javen Wu [mailto:[EMAIL PROTECTED] >Sent: Tuesday, April 01, 2008 5:30 PM >To: Steve Chang >Cc: driver-discuss@opensolaris.org >Subject: Re: [driver-discuss] SCSI HBA driver debugging questions > >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
