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: [email protected]
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: [email protected]
>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: [email protected]
>>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
[email protected]
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
