|Summary:||/dev/sdb not detected anymore?|
|Product:||IO/Storage||Reporter:||Peter Teoh (htmldeveloper)|
|Component:||Serial ATA||Assignee:||Jeff Garzik (jgarzik)|
|Severity:||high||CC:||htmldeveloper, rjw, tj|
|Bug Depends on:|
|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 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!!!