Bug 14319 - /dev/sdb not detected anymore?
/dev/sdb not detected anymore?
Product: IO/Storage
Classification: Unclassified
Component: Serial ATA
All Linux
: P1 high
Assigned To: Jeff Garzik
Depends on:
Blocks: 14230
  Show dependency treegraph
Reported: 2009-10-04 01:50 UTC by Peter Teoh
Modified: 2009-10-05 19:20 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.32-rc2
Tree: Mainline
Regression: Yes

diff between dmesg that worked and that don't - focusing on the libata area. (3.76 KB, application/octet-stream)
2009-10-04 02:01 UTC, Peter Teoh

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!!!

Note You need to log in before you can comment on or make changes to this bug.