* S3 with pata_via fails to resume, ide_via82Cxxx works
@ 2008-12-30 17:50 Bruno Prémont
2008-12-30 20:59 ` Bruno Prémont
0 siblings, 1 reply; 7+ messages in thread
From: Bruno Prémont @ 2008-12-30 17:50 UTC (permalink / raw)
To: linux-ide; +Cc: Linux Kernel, linux-scsi
Hi,
On a system (Commell LE365) with VIA CX700M chipset I experience
varying resume results:
When built with IDE subsystem and VIA82CXXX driver the system suspends
and resumes properly [2.6.28].
-----
CONFIG_HAVE_IDE=y
CONFIG_IDE=y
CONFIG_IDE_TIMINGS=y
CONFIG_IDE_GD=y
CONFIG_IDE_GD_ATA=y
CONFIG_BLK_DEV_IDEACPI=y
CONFIG_BLK_DEV_IDEDMA_SFF=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_BLK_DEV_VIA82CXXX=y
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_ATA is not set
-----
When built with ATA subsystem and PATA_VIA driver the system suspends
but hangs during resume (HDD LED remains active) [2.6.28] though it
manages to resume when the CompactFlash card is disconnected [2.6.27].
-----
# CONFIG_IDE is not set
CONFIG_ATA=y
CONFIG_ATA_ACPI=y
CONFIG_SATA_AHCI=y
CONFIG_ATA_SFF=y
CONFIG_SATA_VIA=y
CONFIG_PATA_VIA=y
-----
Is there some known bigger difference between behavior of both drivers?
I might start comparing behavior of both drivers and try to adjust
PATA_VIA to successfully resume the system, though any hint/suggestion
is welcome!
- SATA HDD with system partition [seen as IDE Primary master]
- CompactFlash card [seen as IDE Secondary slave]
lspci output:
00:00.0 Host bridge [0600]: VIA Technologies, Inc. CX700 Host Bridge [1106:0324] (rev 03)
00:00.1 Host bridge [0600]: VIA Technologies, Inc. CX700 Host Bridge [1106:1324]
00:00.2 Host bridge [0600]: VIA Technologies, Inc. CX700 Host Bridge [1106:2324]
00:00.3 Host bridge [0600]: VIA Technologies, Inc. CX700 Host Bridge [1106:3324]
00:00.4 Host bridge [0600]: VIA Technologies, Inc. CX700 Host Bridge [1106:4324]
00:00.7 Host bridge [0600]: VIA Technologies, Inc. CX700 Host Bridge [1106:7324]
00:01.0 PCI bridge [0604]: VIA Technologies, Inc. VT8237 PCI Bridge [1106:b198]
00:0f.0 IDE interface [0101]: VIA Technologies, Inc. Device [1106:0581]
00:10.0 USB Controller [0c03]: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller [1106:3038] (rev 90)
00:10.1 USB Controller [0c03]: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller [1106:3038] (rev 90)
00:10.2 USB Controller [0c03]: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller [1106:3038] (rev 90)
00:10.4 USB Controller [0c03]: VIA Technologies, Inc. USB 2.0 [1106:3104] (rev 90)
00:11.0 ISA bridge [0601]: VIA Technologies, Inc. CX700 PCI to ISA Bridge [1106:8324]
00:11.7 Host bridge [0600]: VIA Technologies, Inc. CX700 Internal Module Bus [1106:324e]
00:13.0 Host bridge [0600]: VIA Technologies, Inc. CX700 Host Bridge [1106:324b]
00:13.1 PCI bridge [0604]: VIA Technologies, Inc. CX700 PCI to PCI Bridge [1106:324a]
01:00.0 VGA compatible controller [0300]: VIA Technologies, Inc. CX700M2 UniChrome PRO II Graphics [1106:3157] (rev 03)
02:08.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet [10ec:8169] (rev 10)
80:01.0 Audio device [0403]: VIA Technologies, Inc. VIA High Definition Audio Controller [1106:3288] (rev 10)
Secondary note, with ATA subsystem it is possible to discover hot-plugged
second SATA drive with issuing
echo '- - -' > host0/scsi_host/host0/scan
though the same action causes the access to first SATA drive to fail after
removing second drive. (unfortunately BIOS does only allows configuring
the chipset in IDE mode - so not possible to use SATA_VIA or AHCI).
I guess this is caused by some incorrect detection of speed settings.
What is the way to ask driver to rescan with IDE driver?
Bruno
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: S3 with pata_via fails to resume, ide_via82Cxxx works
2008-12-30 17:50 S3 with pata_via fails to resume, ide_via82Cxxx works Bruno Prémont
@ 2008-12-30 20:59 ` Bruno Prémont
2008-12-31 18:19 ` Bartlomiej Zolnierkiewicz
0 siblings, 1 reply; 7+ messages in thread
From: Bruno Prémont @ 2008-12-30 20:59 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: linux-ide, Linux Kernel, linux-scsi
On Tue, 30 December 2008 Bruno Prémont wrote:
> Secondary note, with ATA subsystem it is possible to discover
> hot-plugged second SATA drive with issuing
> echo '- - -' > host0/scsi_host/host0/scan
> though the same action causes the access to first SATA drive to fail
> after removing second drive. (unfortunately BIOS does only allows
> configuring the chipset in IDE mode - so not possible to use SATA_VIA
> or AHCI). I guess this is caused by some incorrect detection of speed
> settings.
>
> What is the way to ask driver to rescan with IDE driver?
I found:
Documentation/ide/warm-plug-howto.txt
Doing just:
echo -n "1" > /sys/class/ide_port/idex/scan
causes the following BUG():
<<<< during boot
Dec 30 18:19:50 venus [ 3.909946] Uniform Multi-Platform E-IDE driver
Dec 30 18:19:50 venus [ 3.913075] via82cxxx 0000:00:0f.0: VIA cx700 (rev 00) IDE UDMA133
Dec 30 18:19:50 venus [ 3.916069] via82cxxx 0000:00:0f.0: IDE controller (0x1106:0x0581 rev 0x00)
Dec 30 18:19:50 venus [ 3.919138] via82cxxx 0000:00:0f.0: not 100% native mode: will probe irqs later
Dec 30 18:19:50 venus [ 3.924945] ide0: BM-DMA at 0xff00-0xff07
Dec 30 18:19:50 venus [ 3.927990] ide1: BM-DMA at 0xff08-0xff0f
Dec 30 18:19:50 venus [ 3.930901] Probing IDE interface ide0...
Dec 30 18:19:50 venus [ 4.050047] Marking TSC unstable due to cpufreq changes
Dec 30 18:19:50 venus [ 4.370099] hda: FUJITSU MHY2250BH, ATA DISK drive
Dec 30 18:19:50 venus [ 4.390026] Clocksource tsc unstable (delta = -215834270 ns)
Dec 30 18:19:50 venus [ 4.730309] hda: host max PIO5 wanted PIO255(auto-tune) selected PIO4
Dec 30 18:19:50 venus [ 4.730462] hda: UDMA/100 mode selected
Dec 30 18:19:50 venus [ 4.735541] Probing IDE interface ide1...
Dec 30 18:19:50 venus [ 5.420127] hdd: , ATA DISK drive
Dec 30 18:19:50 venus [ 5.480288] hdd: host max PIO5 wanted PIO255(auto-tune) selected PIO2
Dec 30 18:19:50 venus [ 5.480330] hdd: UDMA/66 mode selected
Dec 30 18:19:50 venus [ 5.485099] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Dec 30 18:19:50 venus [ 5.565605] ide1 at 0x170-0x177,0x376 on irq 15
Dec 30 18:19:50 venus [ 5.573072] ide-gd driver 1.18
Dec 30 18:19:50 venus [ 5.577684] hda: max request size: 512KiB
Dec 30 18:19:50 venus [ 5.582339] hda: 488397168 sectors (250059 MB) w/8192KiB Cache, CHS=30401/255/63
Dec 30 18:19:50 venus [ 5.592346] hda: cache flushes supported
Dec 30 18:19:50 venus [ 5.597500] hda: hda1 hda2 hda3 hda4 hda5 hda6
Dec 30 18:19:50 venus [ 5.646208] hdd: max request size: 128KiB
Dec 30 18:19:50 venus [ 5.651361] hdd: 8043840 sectors (4118 MB) w/1KiB Cache, CHS=7980/16/63
Dec 30 18:19:50 venus [ 5.656901] hdd: hdd1
-- snip --
<<<< some time later, triggering the scan
Dec 30 21:35:55 venus [ 7866.335247] Probing IDE interface ide0...
Dec 30 21:35:55 venus [ 7866.650105] hda: FUJITSU MHY2250BH, ATA DISK drive
Dec 30 21:35:56 venus [ 7867.370055] hda: host max PIO5 wanted PIO255(auto-tune) selected PIO4
Dec 30 21:35:56 venus [ 7867.370221] hda: UDMA/100 mode selected
Dec 30 21:35:56 venus [ 7867.370375] BUG: unable to handle kernel NULL pointer dereference at 0000000c
Dec 30 21:35:56 venus [ 7867.370400] IP: [<c0248bf6>] elv_may_queue+0x6/0x20
Dec 30 21:35:56 venus [ 7867.370440] *pde = 00000000
Dec 30 21:35:56 venus [ 7867.370459] Oops: 0000 [#1]
Dec 30 21:35:56 venus [ 7867.375572] last sysfs file: /sys/devices/pci0000:00/0000:00:0f.0/ide0/ide_port/ide0/scan
Dec 30 21:35:56 venus [ 7867.380014] Modules linked in: snd_hda_intel snd_pcm snd_timer snd soundcore snd_page_alloc via_agp agpgart
Dec 30 21:35:56 venus [ 7867.380014]
Dec 30 21:35:56 venus [ 7867.380014] Pid: 1855, comm: bash Not tainted (2.6.28-ide #3) CX700+W697HG
Dec 30 21:35:56 venus [ 7867.380014] EIP: 0060:[<c0248bf6>] EFLAGS: 00010046 CPU: 0
Dec 30 21:35:56 venus [ 7867.380014] EIP is at elv_may_queue+0x6/0x20
Dec 30 21:35:56 venus [ 7867.380014] EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000
Dec 30 21:35:56 venus [ 7867.380014] ESI: 00000000 EDI: 00000010 EBP: f6bb3e28 ESP: f6bb3e24
Dec 30 21:35:56 venus [ 7867.380014] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
Dec 30 21:35:56 venus [ 7867.380014] Process bash (pid: 1855, ti=f6bb3000 task=f7110d80 task.ti=f6bb3000)
Dec 30 21:35:56 venus [ 7867.380014] Stack:
Dec 30 21:35:56 venus [ 7867.380014] 00000000 f6bb3e50 c024b40b 00000000 000000e1 f7005890 00000078 00000282
Dec 30 21:35:56 venus [ 7867.380014] 00000000 f73d0020 00000000 f6bb3e80 c024b82c 00000010 00000000 f6bb3e7c
Dec 30 21:35:56 venus [ 7867.380014] 00000282 00000001 000000e1 000000e1 00000001 f73d0020 f6bb3ee4 f6bb3e8c
Dec 30 21:35:56 venus [ 7867.380014] Call Trace:
Dec 30 21:35:56 venus [ 7867.380014] [<c024b40b>] ? get_request+0x1b/0x240
Dec 30 21:35:56 venus [ 7867.380014] [<c024b82c>] ? get_request_wait+0x1c/0xd0
Dec 30 21:35:56 venus [ 7867.380014] [<c024bc48>] ? blk_get_request+0x18/0x30
Dec 30 21:35:56 venus [ 7867.380014] [<c02e2d3a>] ? ide_raw_taskfile+0x2a/0x90
Dec 30 21:35:56 venus [ 7867.380014] [<c02e2e21>] ? taskfile_lib_get_identify+0x61/0x70
Dec 30 21:35:56 venus [ 7867.380014] [<c02e5ff0>] ? ide_acpi_port_init_devices+0x90/0xe0
Dec 30 21:35:56 venus [ 7867.380014] [<c02e2379>] ? ide_port_scan+0x39/0x50
Dec 30 21:35:56 venus [ 7867.380014] [<c02e23d1>] ? store_scan+0x41/0x60
Dec 30 21:35:56 venus [ 7867.380014] [<c02e2390>] ? store_scan+0x0/0x60
Dec 30 21:35:56 venus [ 7867.380014] [<c02cc03c>] ? dev_attr_store+0x2c/0x40
Dec 30 21:35:56 venus [ 7867.380014] [<c01a468d>] ? sysfs_write_file+0x9d/0x100
Dec 30 21:35:56 venus [ 7867.380014] [<c016b215>] ? vfs_write+0x95/0x120
Dec 30 21:35:56 venus [ 7867.380014] [<c01a45f0>] ? sysfs_write_file+0x0/0x100
Dec 30 21:35:56 venus [ 7867.380014] [<c016b34d>] ? sys_write+0x3d/0x70
Dec 30 21:35:56 venus [ 7867.380014] [<c0103b01>] ? sysenter_do_call+0x12/0x25
Dec 30 21:35:56 venus [ 7867.380014] Code: bf 00 00 00 00 55 8b 40 0c 89 e5 8b 00 8b 48 34 85 c9 74 04 89 d0 ff d1 5d c3 8d 74 26 00 8d bc 27 00 00 00 00 55 89 e5 53 89 c3 <8b> 40 0c 8b 00 8b 48 38 31 c0 85 c9 74 04 89 d8 ff d1 5b 5d c3
Dec 30 21:35:56 venus [ 7867.380014] EIP: [<c0248bf6>] elv_may_queue+0x6/0x20 SS:ESP 0068:f6bb3e24
Dec 30 21:35:56 venus [ 7867.380014] ---[ end trace b966cf347b1167e4 ]---
Dec 30 21:36:15 venus [ 7886.330025] ide_timer_expiry: hwgroup->drive was NULL
Dec 30 21:36:29 venus [ 7899.770239] Buffer I/O error on device hda3, logical block 115511
Dec 30 21:36:29 venus [ 7899.777078] lost page write due to I/O error on hda3
Dec 30 21:36:29 venus [ 7899.783856] Buffer I/O error on device hda3, logical block 115512
Dec 30 21:36:29 venus [ 7899.790570] lost page write due to I/O error on hda3
Same effect with:
cd /sys/class/ide_port/ide0/
sync; sleep 1; echo -n 1 > delete_devices; sleep 1; echo -n 1 > scan
Bruno
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: S3 with pata_via fails to resume, ide_via82Cxxx works
2008-12-30 20:59 ` Bruno Prémont
@ 2008-12-31 18:19 ` Bartlomiej Zolnierkiewicz
2008-12-31 19:15 ` Bruno Prémont
0 siblings, 1 reply; 7+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2008-12-31 18:19 UTC (permalink / raw)
To: Bruno Prémont; +Cc: linux-ide, Linux Kernel, linux-scsi
On Tuesday 30 December 2008, Bruno Prémont wrote:
> On Tue, 30 December 2008 Bruno Prémont wrote:
> > Secondary note, with ATA subsystem it is possible to discover
> > hot-plugged second SATA drive with issuing
> > echo '- - -' > host0/scsi_host/host0/scan
> > though the same action causes the access to first SATA drive to fail
> > after removing second drive. (unfortunately BIOS does only allows
> > configuring the chipset in IDE mode - so not possible to use SATA_VIA
> > or AHCI). I guess this is caused by some incorrect detection of speed
> > settings.
> >
> > What is the way to ask driver to rescan with IDE driver?
> I found:
> Documentation/ide/warm-plug-howto.txt
>
>
> Doing just:
> echo -n "1" > /sys/class/ide_port/idex/scan
> causes the following BUG():
> <<<< during boot
> Dec 30 18:19:50 venus [ 3.909946] Uniform Multi-Platform E-IDE driver
> Dec 30 18:19:50 venus [ 3.913075] via82cxxx 0000:00:0f.0: VIA cx700 (rev 00) IDE UDMA133
> Dec 30 18:19:50 venus [ 3.916069] via82cxxx 0000:00:0f.0: IDE controller (0x1106:0x0581 rev 0x00)
> Dec 30 18:19:50 venus [ 3.919138] via82cxxx 0000:00:0f.0: not 100% native mode: will probe irqs later
> Dec 30 18:19:50 venus [ 3.924945] ide0: BM-DMA at 0xff00-0xff07
> Dec 30 18:19:50 venus [ 3.927990] ide1: BM-DMA at 0xff08-0xff0f
> Dec 30 18:19:50 venus [ 3.930901] Probing IDE interface ide0...
> Dec 30 18:19:50 venus [ 4.050047] Marking TSC unstable due to cpufreq changes
> Dec 30 18:19:50 venus [ 4.370099] hda: FUJITSU MHY2250BH, ATA DISK drive
> Dec 30 18:19:50 venus [ 4.390026] Clocksource tsc unstable (delta = -215834270 ns)
> Dec 30 18:19:50 venus [ 4.730309] hda: host max PIO5 wanted PIO255(auto-tune) selected PIO4
> Dec 30 18:19:50 venus [ 4.730462] hda: UDMA/100 mode selected
> Dec 30 18:19:50 venus [ 4.735541] Probing IDE interface ide1...
> Dec 30 18:19:50 venus [ 5.420127] hdd: , ATA DISK drive
> Dec 30 18:19:50 venus [ 5.480288] hdd: host max PIO5 wanted PIO255(auto-tune) selected PIO2
> Dec 30 18:19:50 venus [ 5.480330] hdd: UDMA/66 mode selected
> Dec 30 18:19:50 venus [ 5.485099] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> Dec 30 18:19:50 venus [ 5.565605] ide1 at 0x170-0x177,0x376 on irq 15
> Dec 30 18:19:50 venus [ 5.573072] ide-gd driver 1.18
> Dec 30 18:19:50 venus [ 5.577684] hda: max request size: 512KiB
> Dec 30 18:19:50 venus [ 5.582339] hda: 488397168 sectors (250059 MB) w/8192KiB Cache, CHS=30401/255/63
> Dec 30 18:19:50 venus [ 5.592346] hda: cache flushes supported
> Dec 30 18:19:50 venus [ 5.597500] hda: hda1 hda2 hda3 hda4 hda5 hda6
> Dec 30 18:19:50 venus [ 5.646208] hdd: max request size: 128KiB
> Dec 30 18:19:50 venus [ 5.651361] hdd: 8043840 sectors (4118 MB) w/1KiB Cache, CHS=7980/16/63
> Dec 30 18:19:50 venus [ 5.656901] hdd: hdd1
> -- snip --
> <<<< some time later, triggering the scan
> Dec 30 21:35:55 venus [ 7866.335247] Probing IDE interface ide0...
> Dec 30 21:35:55 venus [ 7866.650105] hda: FUJITSU MHY2250BH, ATA DISK drive
> Dec 30 21:35:56 venus [ 7867.370055] hda: host max PIO5 wanted PIO255(auto-tune) selected PIO4
> Dec 30 21:35:56 venus [ 7867.370221] hda: UDMA/100 mode selected
> Dec 30 21:35:56 venus [ 7867.370375] BUG: unable to handle kernel NULL pointer dereference at 0000000c
> Dec 30 21:35:56 venus [ 7867.370400] IP: [<c0248bf6>] elv_may_queue+0x6/0x20
> Dec 30 21:35:56 venus [ 7867.370440] *pde = 00000000
> Dec 30 21:35:56 venus [ 7867.370459] Oops: 0000 [#1]
> Dec 30 21:35:56 venus [ 7867.375572] last sysfs file: /sys/devices/pci0000:00/0000:00:0f.0/ide0/ide_port/ide0/scan
> Dec 30 21:35:56 venus [ 7867.380014] Modules linked in: snd_hda_intel snd_pcm snd_timer snd soundcore snd_page_alloc via_agp agpgart
> Dec 30 21:35:56 venus [ 7867.380014]
> Dec 30 21:35:56 venus [ 7867.380014] Pid: 1855, comm: bash Not tainted (2.6.28-ide #3) CX700+W697HG
> Dec 30 21:35:56 venus [ 7867.380014] EIP: 0060:[<c0248bf6>] EFLAGS: 00010046 CPU: 0
> Dec 30 21:35:56 venus [ 7867.380014] EIP is at elv_may_queue+0x6/0x20
> Dec 30 21:35:56 venus [ 7867.380014] EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000
> Dec 30 21:35:56 venus [ 7867.380014] ESI: 00000000 EDI: 00000010 EBP: f6bb3e28 ESP: f6bb3e24
> Dec 30 21:35:56 venus [ 7867.380014] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
> Dec 30 21:35:56 venus [ 7867.380014] Process bash (pid: 1855, ti=f6bb3000 task=f7110d80 task.ti=f6bb3000)
> Dec 30 21:35:56 venus [ 7867.380014] Stack:
> Dec 30 21:35:56 venus [ 7867.380014] 00000000 f6bb3e50 c024b40b 00000000 000000e1 f7005890 00000078 00000282
> Dec 30 21:35:56 venus [ 7867.380014] 00000000 f73d0020 00000000 f6bb3e80 c024b82c 00000010 00000000 f6bb3e7c
> Dec 30 21:35:56 venus [ 7867.380014] 00000282 00000001 000000e1 000000e1 00000001 f73d0020 f6bb3ee4 f6bb3e8c
> Dec 30 21:35:56 venus [ 7867.380014] Call Trace:
> Dec 30 21:35:56 venus [ 7867.380014] [<c024b40b>] ? get_request+0x1b/0x240
> Dec 30 21:35:56 venus [ 7867.380014] [<c024b82c>] ? get_request_wait+0x1c/0xd0
> Dec 30 21:35:56 venus [ 7867.380014] [<c024bc48>] ? blk_get_request+0x18/0x30
> Dec 30 21:35:56 venus [ 7867.380014] [<c02e2d3a>] ? ide_raw_taskfile+0x2a/0x90
> Dec 30 21:35:56 venus [ 7867.380014] [<c02e2e21>] ? taskfile_lib_get_identify+0x61/0x70
> Dec 30 21:35:56 venus [ 7867.380014] [<c02e5ff0>] ? ide_acpi_port_init_devices+0x90/0xe0
> Dec 30 21:35:56 venus [ 7867.380014] [<c02e2379>] ? ide_port_scan+0x39/0x50
> Dec 30 21:35:56 venus [ 7867.380014] [<c02e23d1>] ? store_scan+0x41/0x60
> Dec 30 21:35:56 venus [ 7867.380014] [<c02e2390>] ? store_scan+0x0/0x60
> Dec 30 21:35:56 venus [ 7867.380014] [<c02cc03c>] ? dev_attr_store+0x2c/0x40
> Dec 30 21:35:56 venus [ 7867.380014] [<c01a468d>] ? sysfs_write_file+0x9d/0x100
> Dec 30 21:35:56 venus [ 7867.380014] [<c016b215>] ? vfs_write+0x95/0x120
> Dec 30 21:35:56 venus [ 7867.380014] [<c01a45f0>] ? sysfs_write_file+0x0/0x100
> Dec 30 21:35:56 venus [ 7867.380014] [<c016b34d>] ? sys_write+0x3d/0x70
> Dec 30 21:35:56 venus [ 7867.380014] [<c0103b01>] ? sysenter_do_call+0x12/0x25
> Dec 30 21:35:56 venus [ 7867.380014] Code: bf 00 00 00 00 55 8b 40 0c 89 e5 8b 00 8b 48 34 85 c9 74 04 89 d0 ff d1 5d c3 8d 74 26 00 8d bc 27 00 00 00 00 55 89 e5 53 89 c3 <8b> 40 0c 8b 00 8b 48 38 31 c0 85 c9 74 04 89 d8 ff d1 5b 5d c3
> Dec 30 21:35:56 venus [ 7867.380014] EIP: [<c0248bf6>] elv_may_queue+0x6/0x20 SS:ESP 0068:f6bb3e24
> Dec 30 21:35:56 venus [ 7867.380014] ---[ end trace b966cf347b1167e4 ]---
> Dec 30 21:36:15 venus [ 7886.330025] ide_timer_expiry: hwgroup->drive was NULL
> Dec 30 21:36:29 venus [ 7899.770239] Buffer I/O error on device hda3, logical block 115511
> Dec 30 21:36:29 venus [ 7899.777078] lost page write due to I/O error on hda3
> Dec 30 21:36:29 venus [ 7899.783856] Buffer I/O error on device hda3, logical block 115512
> Dec 30 21:36:29 venus [ 7899.790570] lost page write due to I/O error on hda3
>
> Same effect with:
> cd /sys/class/ide_port/ide0/
> sync; sleep 1; echo -n 1 > delete_devices; sleep 1; echo -n 1 > scan
Thanks for the report, the following patch fixes the OOPS for me:
From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] ide: fix ide_port_scan() to do ACPI setup after initializing request queues
This makes ide_port_scan()'s behavior match ide_host_register()'s
one and fixes OOPS in elv_may_queue() during port re-scan.
Reported-by: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
drivers/ide/ide-probe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/ide/ide-probe.c
===================================================================
--- a/drivers/ide/ide-probe.c
+++ b/drivers/ide/ide-probe.c
@@ -1694,8 +1694,8 @@ void ide_port_scan(ide_hwif_t *hwif)
hwif->present = 1;
ide_port_tune_devices(hwif);
- ide_acpi_port_init_devices(hwif);
ide_port_setup_devices(hwif);
+ ide_acpi_port_init_devices(hwif);
hwif_register_devices(hwif);
ide_proc_port_register_devices(hwif);
}
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: S3 with pata_via fails to resume, ide_via82Cxxx works
2008-12-31 18:19 ` Bartlomiej Zolnierkiewicz
@ 2008-12-31 19:15 ` Bruno Prémont
2008-12-31 22:24 ` Bruno Prémont
0 siblings, 1 reply; 7+ messages in thread
From: Bruno Prémont @ 2008-12-31 19:15 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: linux-ide, Linux Kernel, linux-scsi
Thanks for the patch, it fixes the oops for me too.
Unfortunately the re-discovery of the drive causes at least XFS to
error and shutdown its mounts :(
Is it possible to block any access to the devices on the scanned port
until the scan has completed? Otherwise this renders rescanning
on port with mounted (e.g. /) partition to suicide...
I also wonder why it took so long and there is that complaint about
lost interrupt + failure. Was there some operation in progress that
got "killed" by the scan?
Bruno
Dec 31 19:58:26 venus [ 83.716209] Probing IDE interface ide0...
Dec 31 19:58:27 venus [ 84.030107] hda: FUJITSU MHY2250BH, ATA DISK drive
Dec 31 19:58:27 venus [ 84.390048] hda: host max PIO5 wanted PIO255(auto-tune) selected PIO4
Dec 31 19:58:27 venus [ 84.390205] hda: UDMA/100 mode selected
Dec 31 19:58:39 venus [ 96.640225] I/O error in filesystem ("hda3") meta-data dev hda3 block 0x202f14 ("xlog_iodone") error 5 buf count 1024
Dec 31 19:58:39 venus [ 96.640274] xfs_force_shutdown(hda3,0x2) called from line 1062 of file /usr/src/linux-2.6.28/fs/xfs/xfs_log.c. Return address = 0xc021418a
Dec 31 19:58:39 venus [ 96.640331] Filesystem "hda3": Log I/O Error Detected. Shutting down filesystem: hda3
Dec 31 19:58:39 venus [ 96.640359] Please umount the filesystem, and rectify the problem(s)
Dec 31 18:58:46 venus [ 103.710105] hda: dma_timer_expiry: DMA status (0x20)
Dec 31 18:58:46 venus [ 103.710128] hda: lost interrupt
Dec 31 18:58:46 venus [ 103.710148] hda: ide_dma_intr: bad DMA status (0x30)
Dec 31 18:58:46 venus [ 103.710168] hda: dma_intr: status=0x50 { DriveReady SeekComplete }
Dec 31 18:58:46 venus [ 103.710192] ide: failed opcode was: unknown
Dec 31 18:58:47 venus [ 104.063206] hda: max request size: 512KiB
Dec 31 18:58:47 venus [ 104.063230] hda: 488397168 sectors (250059 MB) w/8192KiB Cache, CHS=30401/255/63
Dec 31 18:58:47 venus [ 104.063450] hda: cache flushes supported
Dec 31 18:59:09 venus [ 126.640091] Filesystem "hda3": xfs_log_force: error 5 returned.
Dec 31 18:59:39 venus [ 156.640109] Filesystem "hda3": xfs_log_force: error 5 returned.
Dec 31 19:00:09 venus [ 186.640093] Filesystem "hda3": xfs_log_force: error 5 returned.
On Wed, 31 December 2008 Bartlomiej Zolnierkiewicz wrote:
> Thanks for the report, the following patch fixes the OOPS for me:
>
> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Subject: [PATCH] ide: fix ide_port_scan() to do ACPI setup after
> initializing request queues
>
> This makes ide_port_scan()'s behavior match ide_host_register()'s
> one and fixes OOPS in elv_may_queue() during port re-scan.
>
> Reported-by: Bruno Prémont <bonbons@linux-vserver.org>
> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> ---
> drivers/ide/ide-probe.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: b/drivers/ide/ide-probe.c
> ===================================================================
> --- a/drivers/ide/ide-probe.c
> +++ b/drivers/ide/ide-probe.c
> @@ -1694,8 +1694,8 @@ void ide_port_scan(ide_hwif_t *hwif)
> hwif->present = 1;
>
> ide_port_tune_devices(hwif);
> - ide_acpi_port_init_devices(hwif);
> ide_port_setup_devices(hwif);
> + ide_acpi_port_init_devices(hwif);
> hwif_register_devices(hwif);
> ide_proc_port_register_devices(hwif);
> }
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: S3 with pata_via fails to resume, ide_via82Cxxx works
2008-12-31 19:15 ` Bruno Prémont
@ 2008-12-31 22:24 ` Bruno Prémont
2009-01-02 21:13 ` Bartlomiej Zolnierkiewicz
0 siblings, 1 reply; 7+ messages in thread
From: Bruno Prémont @ 2008-12-31 22:24 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: linux-ide, Linux Kernel, linux-scsi
On Wed, 31 December 2008 Bruno Prémont wrote:
> Unfortunately the re-discovery of the drive causes at least XFS to
> error and shutdown its mounts :(
>
> Is it possible to block any access to the devices on the scanned port
> until the scan has completed? Otherwise this renders rescanning
> on port with mounted (e.g. /) partition to suicide...
>
> I also wonder why it took so long and there is that complaint about
> lost interrupt + failure. Was there some operation in progress that
> got "killed" by the scan?
In addition after a second/third attempt with reboot in between as /
is no more accessible I ended up with garbage in first sectors of the
disc!
That time I did:
cd /sys/class/ide_port/ide0/
sync; sleep 1; echo -n 1 > delete_devices; sleep 1; echo -n 1 > scan
caused:
I/O error for sleep (unknown which one but my guess is it would be
the second).
Previously I just did which only made XFS panic:
echo -n 1 > scan
Matching kernel logs:
Dec 31 20:21:59 venus [ 246.114799] Probing IDE interface ide0...
Dec 31 20:21:59 venus [ 246.420137] hda: FUJITSU MHY2250BH, ATA DISK drive
Dec 31 20:22:00 venus [ 246.780071] hda: host max PIO5 wanted PIO255(auto-tune) selected PIO4
Dec 31 20:22:00 venus [ 246.780621] hda: UDMA/100 mode selected
Dec 31 20:22:19 venus [ 266.100064] hda: dma_timer_expiry: DMA status (0x20)
Dec 31 20:22:19 venus [ 266.100388] hda: lost interrupt
Dec 31 20:22:19 venus [ 266.100588] hda: ide_dma_intr: bad DMA status (0x30)
Dec 31 20:22:19 venus [ 266.100886] hda: dma_intr: status=0x50 { DriveReady SeekComplete }
Dec 31 20:22:19 venus [ 266.101298] ide: failed opcode was: unknown
Dec 31 20:22:19 venus [ 266.454984] hda: max request size: 512KiB
Dec 31 20:22:19 venus [ 266.455254] hda: 488397168 sectors (250059 MB) w/8192KiB Cache, CHS=30401/255/63
Dec 31 20:22:19 venus [ 266.455972] hda: cache flushes supported
Dec 31 20:22:19 venus [ 266.493825] request_module: runaway loop modprobe binfmt-0000
Dec 31 20:22:19 venus [ 266.494218] request_module: runaway loop modprobe binfmt-0000
Dec 31 20:22:19 venus [ 266.494933] request_module: runaway loop modprobe binfmt-0000
Dec 31 20:22:19 venus [ 266.495294] request_module: runaway loop modprobe binfmt-0000
Dec 31 20:22:19 venus [ 266.496303] request_module: runaway loop modprobe binfmt-0000
Dec 31 20:25:07 venus [ 432.720055] INFO: task udevd:630 blocked for more than 120 seconds.
Dec 31 20:25:07 venus [ 432.720308] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Dec 31 20:25:07 venus [ 432.720637] udevd D c0249ea0 2572 630 1
Dec 31 20:25:07 venus [ 432.720867] f6903e18 00000086 c024b74d c0249ea0 f6903e04 f70c2d80 f6903e0c c0249e9c
Dec 31 20:25:07 venus [ 432.721233] f6903e50 f6d79818 f6903e58 f6903e20 c03e675e f6903e28 c01487d5 f6903e44
Dec 31 20:25:07 venus [ 432.721580] c03e6a7f c01487a0 c17821b0 f6903e50 f6d79818 00000000 f6903e70 c01477b8
Dec 31 20:25:07 venus [ 432.721928] Call Trace:
Dec 31 20:25:07 venus [ 432.722036] [<c024b74d>] ? __generic_unplug_device+0x1d/0x30
Dec 31 20:25:07 venus [ 432.722245] [<c0249ea0>] ? blk_backing_dev_unplug+0x0/0x10
Dec 31 20:25:07 venus [ 432.722446] [<c0249e9c>] ? blk_unplug+0xc/0x10
Dec 31 20:25:07 venus [ 432.722619] [<c03e675e>] io_schedule+0xe/0x20
Dec 31 20:25:07 venus [ 432.722788] [<c01487d5>] sync_page+0x35/0x40
Dec 31 20:25:07 venus [ 432.722949] [<c03e6a7f>] __wait_on_bit_lock+0x3f/0x70
Dec 31 20:25:07 venus [ 432.723135] [<c01487a0>] ? sync_page+0x0/0x40
Dec 31 20:25:07 venus [ 432.723299] [<c01477b8>] __lock_page+0x68/0x70
Dec 31 20:25:07 venus [ 432.730742] [<c01315e0>] ? wake_bit_function+0x0/0x60
Dec 31 20:25:07 venus [ 432.738085] [<c014783b>] find_lock_page+0x4b/0x60
Dec 31 20:25:07 venus [ 432.745577] [<c0148b17>] filemap_fault+0x297/0x3a0
Dec 31 20:25:07 venus [ 432.753061] [<c025437e>] ? prio_tree_insert+0x1e/0x240
Dec 31 20:25:07 venus [ 432.760556] [<c015548b>] __do_fault+0x3b/0x390
Dec 31 20:25:07 venus [ 432.767962] [<c0152502>] ? vma_prio_tree_insert+0x22/0x40
Dec 31 20:25:07 venus [ 432.775508] [<c015907d>] ? vma_link+0x3d/0x50
Dec 31 20:25:07 venus [ 432.782967] [<c0155eb5>] handle_mm_fault+0xe5/0x570
Dec 31 20:25:07 venus [ 432.790448] [<c0116ac0>] ? do_page_fault+0x0/0x670
Dec 31 20:25:07 venus [ 432.797882] [<c0116d2c>] do_page_fault+0x26c/0x670
Dec 31 20:25:07 venus [ 432.805292] [<c0258985>] ? copy_to_user+0x35/0x50
Dec 31 20:25:07 venus [ 432.812644] [<c0116ac0>] ? do_page_fault+0x0/0x670
Dec 31 20:25:07 venus [ 432.819910] [<c03e7a7a>] error_code+0x6a/0x70
Dec 31 20:25:07 venus [ 432.827132] INFO: task bash:1918 blocked for more than 120 seconds.
Dec 31 20:25:07 venus [ 432.834416] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Dec 31 20:25:07 venus [ 432.841880] bash D f70081fc 2504 1918 1863
Dec 31 20:25:07 venus [ 432.849416] f730ae4c 00000086 f7033fac f70081fc 00000000 f711db00 c011c3ab f730ae50
Dec 31 20:25:07 venus [ 432.857217] 7fffffff f730aed4 00000002 f730ae94 c03e68a5 c011bede 00000000 00000001
Dec 31 20:25:07 venus [ 432.865082] 00000003 f7008208 00000000 00000082 f700a0a0 f730ae8c 00000082 00000000
Dec 31 20:25:07 venus [ 432.873032] Call Trace:
Dec 31 20:25:07 venus [ 432.880908] [<c011c3ab>] ? default_wake_function+0xb/0x10
Dec 31 20:25:07 venus [ 432.889004] [<c03e68a5>] schedule_timeout+0x75/0xc0
Dec 31 20:25:07 venus [ 432.897171] [<c011bede>] ? __wake_up_common+0x3e/0x70
Dec 31 20:25:07 venus [ 432.905391] [<c03e63a3>] wait_for_common+0x93/0x110
Dec 31 20:25:07 venus [ 432.913587] [<c011c3a0>] ? default_wake_function+0x0/0x10
Dec 31 20:25:07 venus [ 432.921818] [<c03e64b2>] wait_for_completion+0x12/0x20
Dec 31 20:25:07 venus [ 432.930167] [<c012de8b>] call_usermodehelper_exec+0xab/0xc0
Dec 31 20:25:07 venus [ 432.938491] [<c012e0ce>] request_module+0x9e/0xe0
Dec 31 20:25:07 venus [ 432.946793] [<c016e462>] search_binary_handler+0x192/0x1f0
Dec 31 20:25:07 venus [ 432.955084] [<c016f613>] do_execve+0x163/0x1b0
Dec 31 20:25:07 venus [ 432.963311] [<c010261e>] sys_execve+0x2e/0x60
Dec 31 20:25:07 venus [ 432.971452] [<c0103b01>] sysenter_do_call+0x12/0x25
I guess the binfmt-0000 is cause by XFS reading at wrong location on disc
and kernel seeing random data as bin format signature.
On reboot no more bootloader.
hexdump with rescue system showed XFS magic in very first sector of the
disc, (rescuing the GPT worked - I assume parted used copy at end
of disc) though the first partition also got corrupted.
This looks like the scan is pretty dangerous in case anything has a
reference to a disc/partition on the scanned channel :(
Bruno
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: S3 with pata_via fails to resume, ide_via82Cxxx works
2008-12-31 22:24 ` Bruno Prémont
@ 2009-01-02 21:13 ` Bartlomiej Zolnierkiewicz
2009-01-02 22:50 ` Bruno Prémont
0 siblings, 1 reply; 7+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2009-01-02 21:13 UTC (permalink / raw)
To: Bruno Prémont; +Cc: linux-ide, Linux Kernel, linux-scsi
On Wednesday 31 December 2008, Bruno Prémont wrote:
> On Wed, 31 December 2008 Bruno Prémont wrote:
> > Unfortunately the re-discovery of the drive causes at least XFS to
> > error and shutdown its mounts :(
> >
> > Is it possible to block any access to the devices on the scanned port
> > until the scan has completed? Otherwise this renders rescanning
> > on port with mounted (e.g. /) partition to suicide...
> >
> > I also wonder why it took so long and there is that complaint about
> > lost interrupt + failure. Was there some operation in progress that
> > got "killed" by the scan?
>
> In addition after a second/third attempt with reboot in between as /
> is no more accessible I ended up with garbage in first sectors of the
> disc!
>
> That time I did:
> cd /sys/class/ide_port/ide0/
> sync; sleep 1; echo -n 1 > delete_devices; sleep 1; echo -n 1 > scan
> caused:
> I/O error for sleep (unknown which one but my guess is it would be
> the second).
> Previously I just did which only made XFS panic:
> echo -n 1 > scan
>
> Matching kernel logs:
> Dec 31 20:21:59 venus [ 246.114799] Probing IDE interface ide0...
> Dec 31 20:21:59 venus [ 246.420137] hda: FUJITSU MHY2250BH, ATA DISK drive
> Dec 31 20:22:00 venus [ 246.780071] hda: host max PIO5 wanted PIO255(auto-tune) selected PIO4
> Dec 31 20:22:00 venus [ 246.780621] hda: UDMA/100 mode selected
> Dec 31 20:22:19 venus [ 266.100064] hda: dma_timer_expiry: DMA status (0x20)
> Dec 31 20:22:19 venus [ 266.100388] hda: lost interrupt
> Dec 31 20:22:19 venus [ 266.100588] hda: ide_dma_intr: bad DMA status (0x30)
> Dec 31 20:22:19 venus [ 266.100886] hda: dma_intr: status=0x50 { DriveReady SeekComplete }
> Dec 31 20:22:19 venus [ 266.101298] ide: failed opcode was: unknown
> Dec 31 20:22:19 venus [ 266.454984] hda: max request size: 512KiB
> Dec 31 20:22:19 venus [ 266.455254] hda: 488397168 sectors (250059 MB) w/8192KiB Cache, CHS=30401/255/63
> Dec 31 20:22:19 venus [ 266.455972] hda: cache flushes supported
> Dec 31 20:22:19 venus [ 266.493825] request_module: runaway loop modprobe binfmt-0000
> Dec 31 20:22:19 venus [ 266.494218] request_module: runaway loop modprobe binfmt-0000
> Dec 31 20:22:19 venus [ 266.494933] request_module: runaway loop modprobe binfmt-0000
> Dec 31 20:22:19 venus [ 266.495294] request_module: runaway loop modprobe binfmt-0000
> Dec 31 20:22:19 venus [ 266.496303] request_module: runaway loop modprobe binfmt-0000
> Dec 31 20:25:07 venus [ 432.720055] INFO: task udevd:630 blocked for more than 120 seconds.
> Dec 31 20:25:07 venus [ 432.720308] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> Dec 31 20:25:07 venus [ 432.720637] udevd D c0249ea0 2572 630 1
> Dec 31 20:25:07 venus [ 432.720867] f6903e18 00000086 c024b74d c0249ea0 f6903e04 f70c2d80 f6903e0c c0249e9c
> Dec 31 20:25:07 venus [ 432.721233] f6903e50 f6d79818 f6903e58 f6903e20 c03e675e f6903e28 c01487d5 f6903e44
> Dec 31 20:25:07 venus [ 432.721580] c03e6a7f c01487a0 c17821b0 f6903e50 f6d79818 00000000 f6903e70 c01477b8
> Dec 31 20:25:07 venus [ 432.721928] Call Trace:
> Dec 31 20:25:07 venus [ 432.722036] [<c024b74d>] ? __generic_unplug_device+0x1d/0x30
> Dec 31 20:25:07 venus [ 432.722245] [<c0249ea0>] ? blk_backing_dev_unplug+0x0/0x10
> Dec 31 20:25:07 venus [ 432.722446] [<c0249e9c>] ? blk_unplug+0xc/0x10
> Dec 31 20:25:07 venus [ 432.722619] [<c03e675e>] io_schedule+0xe/0x20
> Dec 31 20:25:07 venus [ 432.722788] [<c01487d5>] sync_page+0x35/0x40
> Dec 31 20:25:07 venus [ 432.722949] [<c03e6a7f>] __wait_on_bit_lock+0x3f/0x70
> Dec 31 20:25:07 venus [ 432.723135] [<c01487a0>] ? sync_page+0x0/0x40
> Dec 31 20:25:07 venus [ 432.723299] [<c01477b8>] __lock_page+0x68/0x70
> Dec 31 20:25:07 venus [ 432.730742] [<c01315e0>] ? wake_bit_function+0x0/0x60
> Dec 31 20:25:07 venus [ 432.738085] [<c014783b>] find_lock_page+0x4b/0x60
> Dec 31 20:25:07 venus [ 432.745577] [<c0148b17>] filemap_fault+0x297/0x3a0
> Dec 31 20:25:07 venus [ 432.753061] [<c025437e>] ? prio_tree_insert+0x1e/0x240
> Dec 31 20:25:07 venus [ 432.760556] [<c015548b>] __do_fault+0x3b/0x390
> Dec 31 20:25:07 venus [ 432.767962] [<c0152502>] ? vma_prio_tree_insert+0x22/0x40
> Dec 31 20:25:07 venus [ 432.775508] [<c015907d>] ? vma_link+0x3d/0x50
> Dec 31 20:25:07 venus [ 432.782967] [<c0155eb5>] handle_mm_fault+0xe5/0x570
> Dec 31 20:25:07 venus [ 432.790448] [<c0116ac0>] ? do_page_fault+0x0/0x670
> Dec 31 20:25:07 venus [ 432.797882] [<c0116d2c>] do_page_fault+0x26c/0x670
> Dec 31 20:25:07 venus [ 432.805292] [<c0258985>] ? copy_to_user+0x35/0x50
> Dec 31 20:25:07 venus [ 432.812644] [<c0116ac0>] ? do_page_fault+0x0/0x670
> Dec 31 20:25:07 venus [ 432.819910] [<c03e7a7a>] error_code+0x6a/0x70
> Dec 31 20:25:07 venus [ 432.827132] INFO: task bash:1918 blocked for more than 120 seconds.
> Dec 31 20:25:07 venus [ 432.834416] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> Dec 31 20:25:07 venus [ 432.841880] bash D f70081fc 2504 1918 1863
> Dec 31 20:25:07 venus [ 432.849416] f730ae4c 00000086 f7033fac f70081fc 00000000 f711db00 c011c3ab f730ae50
> Dec 31 20:25:07 venus [ 432.857217] 7fffffff f730aed4 00000002 f730ae94 c03e68a5 c011bede 00000000 00000001
> Dec 31 20:25:07 venus [ 432.865082] 00000003 f7008208 00000000 00000082 f700a0a0 f730ae8c 00000082 00000000
> Dec 31 20:25:07 venus [ 432.873032] Call Trace:
> Dec 31 20:25:07 venus [ 432.880908] [<c011c3ab>] ? default_wake_function+0xb/0x10
> Dec 31 20:25:07 venus [ 432.889004] [<c03e68a5>] schedule_timeout+0x75/0xc0
> Dec 31 20:25:07 venus [ 432.897171] [<c011bede>] ? __wake_up_common+0x3e/0x70
> Dec 31 20:25:07 venus [ 432.905391] [<c03e63a3>] wait_for_common+0x93/0x110
> Dec 31 20:25:07 venus [ 432.913587] [<c011c3a0>] ? default_wake_function+0x0/0x10
> Dec 31 20:25:07 venus [ 432.921818] [<c03e64b2>] wait_for_completion+0x12/0x20
> Dec 31 20:25:07 venus [ 432.930167] [<c012de8b>] call_usermodehelper_exec+0xab/0xc0
> Dec 31 20:25:07 venus [ 432.938491] [<c012e0ce>] request_module+0x9e/0xe0
> Dec 31 20:25:07 venus [ 432.946793] [<c016e462>] search_binary_handler+0x192/0x1f0
> Dec 31 20:25:07 venus [ 432.955084] [<c016f613>] do_execve+0x163/0x1b0
> Dec 31 20:25:07 venus [ 432.963311] [<c010261e>] sys_execve+0x2e/0x60
> Dec 31 20:25:07 venus [ 432.971452] [<c0103b01>] sysenter_do_call+0x12/0x25
>
> I guess the binfmt-0000 is cause by XFS reading at wrong location on disc
> and kernel seeing random data as bin format signature.
>
>
> On reboot no more bootloader.
> hexdump with rescue system showed XFS magic in very first sector of the
> disc, (rescuing the GPT worked - I assume parted used copy at end
> of disc) though the first partition also got corrupted.
>
> This looks like the scan is pretty dangerous in case anything has a
> reference to a disc/partition on the scanned channel :(
I'm really sorry to hear it but "delete_devices" / "scan" interfaces are
currently not ready for use on actively used devices (there are still some
locking issues with the core code that need to be addressed before this
can be allowed).
Even though HOWTO only mentions use for replacing devices (not rescaning)
I admit that it should be more clear about the above:
From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] ide: update warm-plug HOWTO
Reported-by: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
Documentation/ide/warm-plug-howto.txt | 5 +++++
1 file changed, 5 insertions(+)
Index: b/Documentation/ide/warm-plug-howto.txt
===================================================================
--- a/Documentation/ide/warm-plug-howto.txt
+++ b/Documentation/ide/warm-plug-howto.txt
@@ -11,3 +11,8 @@ unplug old device(s) and plug new device
# echo -n "1" > /sys/class/ide_port/idex/scan
done
+
+NOTE: please make sure that partitions are unmounted and that there are
+no other active references to devices before doing "delete_devices" step,
+also do not attempt "scan" step on devices currently in use -- otherwise
+results may be unpredictable and lead to data loss if you're unlucky
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: S3 with pata_via fails to resume, ide_via82Cxxx works
2009-01-02 21:13 ` Bartlomiej Zolnierkiewicz
@ 2009-01-02 22:50 ` Bruno Prémont
0 siblings, 0 replies; 7+ messages in thread
From: Bruno Prémont @ 2009-01-02 22:50 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: linux-ide, Linux Kernel, linux-scsi
On Fri, 02 January 2009 Bartlomiej Zolnierkiewicz wrote:
-snip-
> >
> > I guess the binfmt-0000 is cause by XFS reading at wrong location
> > on disc and kernel seeing random data as bin format signature.
> >
> >
> > On reboot no more bootloader.
> > hexdump with rescue system showed XFS magic in very first sector of
> > the disc, (rescuing the GPT worked - I assume parted used copy at
> > end of disc) though the first partition also got corrupted.
> >
> > This looks like the scan is pretty dangerous in case anything has a
> > reference to a disc/partition on the scanned channel :(
That's fine with me - eventually it would even be worth adding a
printk() as reminder on code path for "scan" and "delete_devices"
triggered when there exists an active user of the bus/device being
probed.
This way there is at least a notice in case something goes wrong (and
when the locking is fixed a reminder to adjust the documentation)
> I'm really sorry to hear it but "delete_devices" / "scan" interfaces
> are currently not ready for use on actively used devices (there are
> still some locking issues with the core code that need to be
> addressed before this can be allowed).
>
> Even though HOWTO only mentions use for replacing devices (not
> rescaning) I admit that it should be more clear about the above:
>
> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Subject: [PATCH] ide: update warm-plug HOWTO
>
> Reported-by: Bruno Prémont <bonbons@linux-vserver.org>
> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> ---
> Documentation/ide/warm-plug-howto.txt | 5 +++++
> 1 file changed, 5 insertions(+)
>
> Index: b/Documentation/ide/warm-plug-howto.txt
> ===================================================================
> --- a/Documentation/ide/warm-plug-howto.txt
> +++ b/Documentation/ide/warm-plug-howto.txt
> @@ -11,3 +11,8 @@ unplug old device(s) and plug new device
> # echo -n "1" > /sys/class/ide_port/idex/scan
>
> done
> +
> +NOTE: please make sure that partitions are unmounted and that there
> are +no other active references to devices before doing
> "delete_devices" step, +also do not attempt "scan" step on devices
> currently in use -- otherwise +results may be unpredictable and lead
> to data loss if you're unlucky
>
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2009-01-02 22:56 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-12-30 17:50 S3 with pata_via fails to resume, ide_via82Cxxx works Bruno Prémont
2008-12-30 20:59 ` Bruno Prémont
2008-12-31 18:19 ` Bartlomiej Zolnierkiewicz
2008-12-31 19:15 ` Bruno Prémont
2008-12-31 22:24 ` Bruno Prémont
2009-01-02 21:13 ` Bartlomiej Zolnierkiewicz
2009-01-02 22:50 ` Bruno Prémont
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).