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] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 24 Jul 2015 14:56:26 +1200
From:	Michael Schmitz <schmitzmic@...il.com>
To:	Finn Thain <fthain@...egraphics.com.au>,
	Michael Schmitz <schmitzmic@...il.com>,
	Andreas Schwab <schwab@...ux-m68k.org>,
	Linux Kernel Development <linux-kernel@...r.kernel.org>,
	"Linux/m68k" <linux-m68k@...r.kernel.org>,
	linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Arnd Bergmann <arnd@...db.de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [RFC v4 03/25] m68k/atari: Move Atari-specific code out of drivers/char/nvram.c

Hi Christian,

here's what Finn asked me to run as tests:

# dmesg | grep this_id > nvram.out
# cat /proc/driver/nvram >> nvram.out
# hexdump -C /dev/nvram >> nvram.out
# cp /dev/nvram /tmp/nvram
# cp /tmp/nvram /dev/nvram
# md5sum /dev/nvram /tmp/nvram >> nvram.out

What you sent so far looks OK. I've tested the change of SCSI ID
(using EmuTOS) along with a trivial patch to atari_scsi.c (replace
offset 14 by 16) and the driver now uses the stored ID properly. I'll
sent kernels to test Finn's NVRAM patch for regression ASAP.

Thanks for your offer of help!

Cheers,

  Michael


On Thu, Jul 23, 2015 at 9:21 PM, Christian T. Steigies <cts@...ian.org> wrote:
> On Wed, Jul 22, 2015 at 02:22:21PM +1000, Finn Thain wrote:
>>
>> Anyone with a suitable Atari, i.e. ATARIHW_PRESENT(TT_CLK), who can boot
>> both TOS and Linux could resolve the question. (Perhaps with an emulator?)
>>
>> Any old kernel binary would do, since atari_scsi should print either
>> "HOSTID=n" or "this_id n" at startup.
>>
>> If n doesn't agree with what TOS says about the host's SCSI ID, then I
>> think a trivial patch is safe enough. Especially if cat /proc/driver/nvram
>> produces a "SCSI host ID : m" that does agree with TOS.
>
> root@...kin:~>cat /proc/hardware
> Model:          Atari Falcon
> System Memory:  522752K
>         510 MB at 0x01000000 (alternate RAM)
> Detected hardware:
>         Falcon Shifter
>         Programmable Sound Generator
>         PCM 8 Bit Sound
>         CODEC Sound
>         SCSI Controller NCR5380 (Falcon style)
>         IDE Interface
>         8/16 Mhz Switch for FDC
>         Multi Function Peripheral MFP 68901
>         Serial Communications Controller SCC 8530
>         Paddle Interface
>         DMA Controller for SCC
>         Clock Chip MC146818A
>         Blitter
>         DSP56001 processor
>
> root@...kin:~>dmesg |grep SCSI
> [    0.000000] Atari hardware found: VIDEL STDMA-SCSI ST_MFP YM2149 PCM CODEC DSP56K SCC_DMA SCC ANALOG_JOY BLITTER IDE TT_CLK FDC_SPEED
> [    0.410000] SCSI subsystem initialized
> [    0.850000] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
> [    4.230000] Atari SCSI: resetting the SCSI bus... done
> [    6.750000] scsi host0: Atari native SCSI, io_port 0x0, n_io_port 0, base 0x0, irq 15, can_queue 8, cmd_per_lun 1, sg_tablesize 0, this_id 7, flags { }, options { REAL_DMA SUPPORT_TAGS }
>
> root@...kin:~>cat /proc/driver/nvram
> Checksum status  : not valid
> Boot preference  : 0xff (undefined)
> SCSI arbitration : on
> SCSI host ID     : 7
> OS language      : 255 (undefined)
> Keyboard language: 255 (undefined)
> Date format      : 7 (undefined), 24h clock
> Boot delay       : 255s
> Video mode       : 4 colors, 40 columns, TV NTSC monitor
>                    no overscan, compat. mode off
>
>
> Let me know if you need more info.
>
> Christian
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ