**** BEGIN LOGGING AT Wed Apr 18 02:59:56 2007
Apr 18 03:41:39 <RobNC> anyone running debian LE (i.e., cyrius install)? Can someone run a test for me?
Apr 18 03:41:50 <RobNC> type (as root) "swapoff /dev/sda2; apt-get install memtester" then "free", then do "memtest 32M 1". assuming /dev/sda2 is your swap partition.
Apr 18 05:36:07 <bkero_> Hello all.  I seem to be getting a funny error when compiling stuff, I was wondering if someone could help me out.  This is what I'm getting: root@Pan:~# gcc test.c
Apr 18 05:36:07 <bkero_> gcc: Internal error: Segmentation fault (program cc1)
Apr 18 05:50:22 <eno> bkero_: 1) try "gcc --version" to verify it's the correct binary; 2) make sure you have enough RAM + swap
Apr 18 05:51:29 <bkero_> 512mb of swap
Apr 18 05:51:40 <bkero_> and gcc 3.4.4, is that correct?
Apr 18 05:59:08 <bkero_> strace: http://pastebin.osuosl.org/1195
Apr 18 06:07:41 <bkero_> Got it down more: open("/etc/ld.so.preload", O_RDONLY)    = 3
Apr 18 06:07:41 <bkero_> fstat64(3, {st_mode=S_IFREG|0777, st_size=0, ...}) = 0
Apr 18 06:07:41 <bkero_> close(3)                                = 0
Apr 18 06:07:41 <bkero_> --- SIGSEGV (Segmentation fault) @ 0 (0) ---
Apr 18 06:14:08 <eno> which firmware and how did you get that gcc?
Apr 18 06:14:25 <bkero_> openslug 3.10 beta, and ipkg install gcc
Apr 18 06:37:48 <bkero_> Anything? :/
Apr 18 08:37:42 <NSLU2-IRC> join #nslu2-general
Apr 18 08:37:48 <NSLU2-IRC> sorry
Apr 18 14:19:12 <[g2]> RobNC, hey this week has been a little busier than anticipated
Apr 18 16:04:39 <CIA-5> 03bzhou * r5944 10optware/trunk/make/libnxml.mk: libnxml: 0.17.1 -> 0.17.2
Apr 18 16:08:56 <CIA-5> 03bzhou * r5945 10optware/trunk/make/snort.mk: snort: 2.6.1.2 -> 2.6.1.4
Apr 18 19:41:16 <shattered> is the right place to ask about Synology DS101j ?
Apr 18 19:41:38 <shattered> I'm trying to debug someone's else problem with smartmontools on this hardware
Apr 18 19:47:31 <NAiL> I assume you're running optware?
Apr 18 19:47:53 <NAiL> I started ds101-linux a long time ago. I don't have a synology any longer though..
Apr 18 19:52:42 <shattered> I don't have access to synology
Apr 18 19:52:55 <shattered> but can ask the owner to do things :)
Apr 18 19:53:12 <NAiL> what appears to be the problem?
Apr 18 19:53:55 <shattered> the problem is: smartmontools uses HDIO_DRIVE_CMD to issue SMART commands to hard disk
Apr 18 19:54:13 <shattered> and returned data is in wrong byte order
Apr 18 19:55:02 <shattered> in detail:
Apr 18 19:55:28 <shattered> first, IDENTIFY DEVICE command is sent
Apr 18 19:55:50 <shattered> it returns 1 sector (512 bytes) of data
Apr 18 19:56:10 <shattered> these data are to be treated as 16-bit words
Apr 18 19:56:20 <NAiL> aha
Apr 18 19:56:34 <NAiL> so you've basically identified the fault, and need it fixed ;)
Apr 18 19:56:44 <NAiL> eno: ping? Got an idea on the above?
Apr 18 19:56:44 <shattered> I'm not sure where the fault is, actually
Apr 18 19:57:25 <shattered> There are multiple reports of this problem from owners of Synology 
Apr 18 19:57:49 <NAiL> ok
Apr 18 19:57:54 <shattered> all appear to use binary packages from 'optware', which are cross-compiled
Apr 18 19:57:58 <NAiL> yup
Apr 18 19:58:10 <NAiL> the master of optware is eno ;)
Apr 18 19:58:21 <shattered> there is 1 report from armv5l-...-linux, which is fine
Apr 18 19:58:33 <NAiL> yeah, that's little-endian
Apr 18 19:58:37 <shattered> all others are from armv5b-..., which fail
Apr 18 19:59:01 <shattered> I'm not sure what was that armv5l- hardware.
Apr 18 20:00:12 <shattered> ah, a 'Thecus n2100'
Apr 18 20:00:22 <NAiL> ah
Apr 18 20:00:29 <NAiL> I've got one of those
Apr 18 20:00:33 <NAiL> brilliant hardware ;)
Apr 18 20:02:02 <shattered> smartmontools code assumes that IDENTIFY data are to be treated as LE words
Apr 18 20:02:33 <shattered> so it checks for big-endian platform at runtime and then swaps everything it needs
Apr 18 20:02:43 <HopsNBarley> as i recall, this is fixed in a later version of smartmontools.
Apr 18 20:03:18 <shattered> no
Apr 18 20:03:45 <shattered> there were fixes for NetBSD, wheren IDENTIFY data is specially treated by kernel (always returned in host order)
Apr 18 20:04:32 <shattered> but I could not find any info on Linux...  
Apr 18 20:04:48 <shattered> so the s..s code could very well be wrong
Apr 18 20:07:55 <shattered> http://pastebin.ca/447023 <- debug output
Apr 18 20:27:45 <eno> shattered: do you have optware cross build env?
Apr 18 20:29:27 <eno> there're two places in smartmontools code with "ifndef __NetBSD__"
Apr 18 20:30:15 <eno> the logic seems to be: if not netbsd, detect endian at runtime, swap bytes if big-endian
Apr 18 20:32:33 <eno> a good experiment is to change "#ifndef __NetBSD__" to "#if 0"
Apr 18 20:32:37 <shattered> no, no cross env
Apr 18 20:33:45 <shattered> I know the NetBSD part well (wrote os_netbsd.*), but Linux code puzzles me
Apr 18 20:34:07 <eno> the problem should be reproducible on unslung or slugosbe as well, right?
Apr 18 20:34:22 <shattered> if Linux indeed returns IDENTIFY data in host order, then I'll change #ifdef 
Apr 18 20:35:28 <shattered> eno: can't say, I'm trying to debug this w/o access to actual hardware :)
Apr 18 20:35:32 <eno> ok, so the key is to find out "if *Linux* returns IDENTIFY data in host order"
Apr 18 20:35:39 <shattered> right
Apr 18 20:36:22 <shattered> I looked around in linux source (using lxr)
Apr 18 20:36:32 <shattered> but couldn't definitely answer this question
Apr 18 20:37:01 <shattered> this could even be a port- or ucLinux-specific problem
Apr 18 20:38:24 <shattered> on NetBSD, I can easily see when driver receives data from device in host order, or receieves a byte stream
Apr 18 20:39:27 <eno> sorry, i'm not a linux kernel guy at all
Apr 18 20:41:31 <mwester_> So what command would one issue to dump information that might determine if this problem exists or not?
Apr 18 20:41:49 <mwester_> (smartmontools seems to work fine for my purposes on SlugOS/BE)
Apr 18 20:42:04 <shattered> smartctl -r ioctl,2 -i /dev/...
Apr 18 20:42:41 <shattered> 496-511: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ae a5
Apr 18 20:42:41 <shattered> ===== [IDENTIFY DEVICE] DATA END (512 Bytes) =====
Apr 18 20:42:57 <shattered> if last byte if 0xa5, you've got BE data already
Apr 18 20:44:24 <shattered> 496-511: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a5 e2
Apr 18 20:44:44 <shattered> this is LE, on netbsd/i386
Apr 18 20:48:46 <mwester_> I get many pages of data, I presume you mean the last line of the several that match the pattern?
Apr 18 20:48:57 <mwester_> 496-511: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e3
Apr 18 20:49:09 <shattered> no, from the first block of data
Apr 18 20:50:25 <mwester_> 496-511: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a5 96
Apr 18 20:50:42 <mwester_> That's from the "IDENTIFY DEVICE" data block then
Apr 18 20:50:42 <shattered> interesting
Apr 18 20:50:52 <shattered> that's LE.
Apr 18 20:51:44 <shattered> mwester_: please post last 5 lines of 'smartctl -V' output
Apr 18 20:53:14 <mwester_> http://pastebin.ca/447114
Apr 18 20:54:51 <shattered> ви
Apr 18 20:54:53 <shattered> hm.
Apr 18 20:55:15 <shattered> you have armeb-..., they have armv5b-...
Apr 18 21:22:03 <eno> mwester_ is using smartmontools from slugosbe feed, not optware/slugosbe
Apr 18 21:24:28 <shattered> plot thickens ;-)
Apr 18 21:29:44 <eno> shattered: am I supposed to use /dev/sda on slug?
Apr 18 21:30:46 <eno> when i use /dev/sda, both slugosbe and unslung said "Device does not support SMART [unsupported field in scsi command]
Apr 18 21:31:14 <shattered> that's SATA disk?
Apr 18 21:31:31 <shattered> pass '-d ata' option then
Apr 18 21:31:46 <eno> no, ATA external connected to USB
Apr 18 21:31:51 <shattered> oh
Apr 18 21:32:12 <shattered> there's slight chance that '-d sat' will work
Apr 18 21:32:45 <shattered> but generally, usb<>ata bridges don't pass SMART commands
Apr 18 21:34:39 <eno> no, neither -d ata nor -d sat works, data all 00
Apr 18 21:57:47 <CIA-5> 03bzhou * r5946 10optware/trunk/make/git-core.mk: git: 1.5.0.7 -> 1.5.1.1
Apr 18 22:23:42 <CoreDump|home> hi
**** ENDING LOGGING AT Thu Apr 19 02:59:56 2007