Bug 14319

Summary: /dev/sdb not detected anymore?
Product: IO/Storage Reporter: Peter Teoh (htmldeveloper)
Component: Serial ATAAssignee: Jeff Garzik (jgarzik)
Status: CLOSED DOCUMENTED    
Severity: high CC: htmldeveloper, rjw, tj
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.32-rc2 Subsystem:
Regression: Yes Bisected commit-id:
Bug Depends on:    
Bug Blocks: 14230    
Attachments: diff between dmesg that worked and that don't - focusing on the libata area.

Description Peter Teoh 2009-10-04 01:50:50 UTC 
I just built my 2.6.32-rc2 (from linus-git), and repeated over last few days (4 Oct 2009), starting from "make mrproper", and consistently both
version cannot detect my /dev/sdb, which is the second SATA harddisk.
 The first SATA is detected as follows in dmesg:

   742 [    4.595949] scsi 2:0:0:0: Direct-Access     ATA
ST3500630AS      3.AA PQ: 0 ANSI: 5
   743 [    4.596116] sd 2:0:0:0: [sda] 976773168 512-byte logical
blocks: (500 GB/465 GiB)
   744 [    4.596213] sd 2:0:0:0: [sda] Write Protect is off
   745 [    4.596216] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
   746 [    4.596258] sd 2:0:0:0: [sda] Write cache: enabled, read
cache: enabled, doesn't support DPO or FUA
   747 [    4.596467]  sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 sda8 sda9 >
   748 [    4.674607] sd 2:0:0:0: [sda] Attached SCSI disk

And from sg_inq:

standard INQUIRY:
 PQual=0  Device_type=0  RMB=0  version=0x05  [SPC-3]
 [AERC=0]  [TrmTsk=0]  NormACA=0  HiSUP=0  Resp_data_format=2
 SCCS=0  ACC=0  TPGS=0  3PC=0  Protect=0  BQue=0
 EncServ=0  MultiP=0  [MChngr=0]  [ACKREQQ=0]  Addr16=0
 [RelAdr=0]  WBus16=0  Sync=0  Linked=0  [TranDis=0]  CmdQue=0
 [SPI: Clocking=0x0  QAS=0  IUS=0]
   length=96 (0x60)   Peripheral device type: disk
 Vendor identification: ATA
 Product identification: ST3500630AS
 Product revision level: 3.AA
 Unit serial number:             9QG14T5Z

But the second SATA (identical in type/model) is not detectable.
Upon rebooting to my previous 2.6.31 kernel version (eg, 2.6.31 jeremy-xen git tree), it became detected and usable - absolutely nothing else is touch.   So what is it in the latest kernel which is giving the problem?

Can someone help me out?

THank you very much :-).
Comment 1 Peter Teoh 2009-10-04 02:01:00 UTC 
Created attachment 23255 [details]
diff between dmesg that worked and that don't - focusing on the libata area.
Comment 2 Tejun Heo 2009-10-04 02:10:17 UTC 
Can you please post full boot log from the working and broken setups?  Also, the output of "lspci -nn".
Comment 3 Rafael J. Wysocki 2009-10-04 13:14:42 UTC 
Notify-Also : linux-ide@vger.kernel.org
Comment 4 Peter Teoh 2009-10-05 14:18:23 UTC 
The problem is resolved.   It is because the main rootfs is 100% full, so as a result (***I suspect***) during startup while udev is loading/initializing all the devices, somehow it did not succeed in doing so.   Now after the rootfs is cleared of 100% filesystem full problem, all the SATA harddisk got detected during startup, and is full working now.   Nothing changes in the kernel side.   Just a toggle between 100% full vs not full. 

Sorry for the trouble caused.   Thanks again!!!   Long live Linux!!!