linux-kernel - Re: [bisected] 2.6.31 regression sis5513 PIO Mode 0 hang

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20091006040644.GB32331@spacedout.fries.net>
Date:	Mon, 5 Oct 2009 23:06:45 -0500
From:	David Fries <david@...es.net>
To:	David Miller <davem@...emloft.net>
Cc:	hancockrwd@...il.com, linux-kernel@...r.kernel.org,
	d.stussy@...oo.com, joao.ramos@...v.pt, torvalds@...l.org,
	rjw@...k.pl, vojtech@...e.cz
Subject: Re: [bisected] 2.6.31 regression sis5513 PIO Mode 0 hang

On Sun, Oct 04, 2009 at 08:58:48PM -0700, David Miller wrote:
> From: David Fries <david@...es.net>
> Date: Sun, 4 Oct 2009 21:55:50 -0500
> 
> > First, if I'm going to do much debugging, how would I force the
> > ethernet device to come up first so I have netconsole?
> > 
> > How is the problem patch,
> > +       ide_port_for_each_dev(i, drive, hwif) {
> > +               if (port_ops && port_ops->set_pio_mode)
> > +                       port_ops->set_pio_mode(drive, 0);
> > +       }
> > 
> > Different from using hdparm to set the mode?  I do this,
> > hdparm -p 0 /dev/hda
> > hdparm -X pio0 /dev/hda
> > and the benchmarks give me about what I would expect 7MB/s instead of
> > the normal 40MB/s.
> > 
> > Then I can re-enable with,
> > hdparm -p 4 /dev/hda
> > hdparm -X udma5 /dev/hda
> > hdparm -d 1 /dev/hda
> > hda: UDMA/100 mode selected
> > and the drive is back up to speed, and obviously the kernel didn't
> > freeze.  Should there be anything different between what the patch
> > tried, and and hdparm's doing, other than kernel initiated and start
> > and a user program later on?
> 
> >From your original hang trace I can only guess that the problematic
> sequence is putting your CDROM into PIO0, then putting it into
> PIO4, and then immediately reading the TOC.

You are correct, it is in ide_cd_read_toc, down in the ide_transfer_pc
and output_data calls, but it isn't time dependent.  I put a five
second sleep at the start of ide_cd_read_toc, so I don't think it is a
race condition.

> This is what the ide-cd.c code does right about where you get the
> hang.
> 
> Debugging this further is really totally pointless for a subsystem
> that should be in deep maintainence mode, so I'm just going to
> revert.

Works for me, thanks.

> Thanks.


Uniform CD-ROM driver Revision: 3.20
ide_cd_read_toc: enter
cdrom_check_status: enter
ide_cd_queue_pc
ide_cd_do_request
ide_cd_do_request: dev hdc: type=a, flags=108a440
  sector 18446744073709551615, nr/cnr 0/0
cdrom_do_block_pc: rq->cmd[0]: 0x0, rq->cmd_type: 0xa
cdrom_do_block_pc: leave
calling ide_prep_sense
ide_prep_sense returned
calling ide_issue_pc
calling ide_dma_prepare if 0
ide_dma_prepare returned
calling ide_init_packet_cmd
ide_init_packet_cmd returned
calling do_rw_taskfile
do_rw_taskfile returned
calling ide_execute_command
ide_execute_command returned
calling ide_transfer_pc
calling hwif->tp_ops->output_data

-- 
David Fries <david@...es.net>
http://fries.net/~david/ (PGP encryption key available)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/