Hey Kashyap, works for me (against 3.2.1). -andre On 17.01.2012 10:26, Nandigama, Nagalakshmi wrote: > Andre, > Request you to apply the attached patch to 3.2 kernel and test. > > Regards, > Nagalakshmi > > > -----Original Message----- > From: André-Sebastian Liebe [mailto:andre@xxxxxxxxx] > Sent: Monday, January 16, 2012 1:36 PM > To: Desai, Kashyap > Cc: linux-scsi@xxxxxxxxxxxxxxx; Nandigama, Nagalakshmi; Thakkar, Vishal > Subject: Re: [PATCH] mpt2sas: New feature - Fast Load Support - scsi_mod.scan=sync drops drive > > Hi guys, > > sorry for the late reply, I haven't had the chance to reboot the system earlier. But here are the logs for both scan types. > > -andre > > On 12.01.2012 07:30, Desai, Kashyap wrote: >> Andre, >> >> Can you enable mpt2sas driver log level to 0x38c and re-send the >> driver logs in case of "scsi_mod.scan=sync" >> >> You need to pass boot time parameter mpt2sas.logging_level=0x38c >> >> ` Kashyap >> >>> -----Original Message----- >>> From: André-Sebastian Liebe [mailto:andre@xxxxxxxxx] >>> Sent: Wednesday, January 11, 2012 2:17 PM >>> To: Desai, Kashyap >>> Cc: linux-scsi@xxxxxxxxxxxxxxx >>> Subject: Re: [PATCH] mpt2sas: New feature - Fast Load Support - >>> scsi_mod.scan=sync drops drive >>> >>> Tanks for your suggestion Kashyap! >>> >>> I've tried it out but ran directly into an other problem. With >>> scsi_mod.scan=sync the hba reported all 4 drives correctly but >>> dropped one of it instantaneously. So I'm either stuck with kernel >>> 3.1 and all booting up correctly or using 3.2 and manually mounting >>> the drives behind the hba and starting the services depending on them thereafter. >>> >>> I've attached parts of the kernel log with scsi_mod.sync parameter >>> set to sync/async >>> >>> -andre >>> >>> >>> On 10.01.2012 11:53, Desai, Kashyap wrote: >>>> There is a some scsi_mod parameter called "scan". >>>> If you pass those parameter at boot time you can change the behavior. >>>> (see below description) >>>> >>>> scsi_mod.scan= [SCSI] sync (default) scans SCSI busses as they >>> are >>>> discovered. Async scans them in kernel threads, allowing >>> boot to proceed. >>>> none ignores them, expecting user space to do the scan. >>>> >>>> ~ Kashyap >>>> >>>>> -----Original Message----- >>>>> From: linux-scsi-owner@xxxxxxxxxxxxxxx [mailto:linux-scsi- >>>>> owner@xxxxxxxxxxxxxxx] On Behalf Of André-Sebastian Liebe >>>>> Sent: Tuesday, January 10, 2012 2:18 PM >>>>> To: linux-scsi@xxxxxxxxxxxxxxx >>>>> Subject: Re: [PATCH] mpt2sas: New feature - Fast Load Support >>>>> >>>> Hi guys, >>>> >>>> I've run into problems with the all new shiny 3.2 kernel. My system >>>> broke badly as it's depending on some devices which are attached to >>>> my LSI SAS 2008 hba. >>>> The mount scripts of my gentoo/openrc setup get triggered right >>>> after udev has settled. But with the new fast load support udev >>>> settles before my drives appear to the system, so mount fails for >>>> all those drives and of cause all subsequent services depending on them. >>>> Is there any switch to revert back to the old behavior of blocking >>>> until all ports scans are done? >>>> >>>> Thanks in advance >>>> André-Sebastian Liebe >>>> >>>>> -- >>>>> To unsubscribe from this list: send the line "unsubscribe linux-scsi" >>>>> in the body of a message to majordomo@xxxxxxxxxxxxxxx More >>>>> majordomo info at http://vger.kernel.org/majordomo-info.html >>> >>> -- >>> gpg key AA1E1F66 @ gpg-keyserver.de: André-Sebastian Liebe >>> <andre@xxxxxxxxx> Key fingerprint = 5436 5358 172C EB7D E414 C6DE >>> 6664 89BF AA1E 1F66 > > > -- > gpg key AA1E1F66 @ gpg-keyserver.de: André-Sebastian Liebe <andre@xxxxxxxxx> Key fingerprint = 5436 5358 172C EB7D E414 C6DE 6664 89BF AA1E 1F66 -- gpg key AA1E1F66 @ gpg-keyserver.de: André-Sebastian Liebe <andre@xxxxxxxxx> Key fingerprint = 5436 5358 172C EB7D E414 C6DE 6664 89BF AA1E 1F66
Attachment:
mpt2sas_patched.txt.tar.gz
Description: GNU Zip compressed data
