**** BEGIN LOGGING AT Sat Oct 08 02:59:56 2005
Oct 08 05:01:27 <CIA-8> 03rpurdie 07org.openembedded.dev * rf70bd0ba... 10/packages/linux/linux-openzaurus.inc: linux-oz-2.6: Correct kernel size error message
Oct 08 05:01:30 <CIA-8> 03rpurdie 07org.openembedded.dev * re0152948... 10/packages/linux/ (6 files in 3 dirs): linux-oz-2.6: Update kernels after ipaq-pxa-2.6 -> ipaq-pxa270 machine name change
Oct 08 05:01:32 <CIA-8> 03rpurdie 07org.openembedded.dev * r6839f827... 10/packages/linux/ (7 files in 3 dirs): linux-oz-2.6: Add joint defconfig handling for cxx00 models
Oct 08 08:17:18 <cheef_daniel> Palm / LCD-display / USB2Serial MP3-Player working
Oct 08 08:26:40 <dwery-zzz> cheef_daniel: jo!
Oct 08 08:44:39 <cheef_daniel> this was no question
Oct 08 08:50:12 <[g2]> cheef_daniel is that stuff with the slug or a PDA or are the connected together or something ?
Oct 08 08:50:51 <cheef_daniel> I have connected my very old Palm via USB2Serial to the slug
Oct 08 08:51:19 <cheef_daniel> now I can use it as LCD-Display for showning information, and I can use the palm as keyboard
Oct 08 08:52:02 <cheef_daniel> (I mean the LCD-Display of the PALM)
Oct 08 08:52:06 <dwery> cheef_daniel: did you tested the keyboard part?
Oct 08 08:52:12 <cheef_daniel> yes
Oct 08 08:52:59 <cheef_daniel> the letters come to the slug, but now I need some script that do something with these letters
Oct 08 08:53:18 <cheef_daniel> lcdproc shows that the letters come in
Oct 08 08:53:29 <dwery> how do they come to the slug? directly in lcdrpco or simulating the keyboard?
Oct 08 08:54:07 <cheef_daniel> lcdproc watches for inputs on /dev/ttyUSB0
Oct 08 08:55:05 <[g2]> cheef_daniel sounds fun
Oct 08 08:55:37 <[g2]> I've got an old V that's got a serial hookup base too
Oct 08 08:55:45 <cheef_daniel> its the same
Oct 08 08:55:56 <cheef_daniel> mine is called Palm Pilot 5000
Oct 08 08:56:03 <[g2]> oh...you're running a V
Oct 08 08:56:36 <cheef_daniel> why 'oh'?
Oct 08 08:57:19 <[g2]> I hookup tons of stuff but I _never_ considered hooking a Palm up
Oct 08 08:57:26 <cheef_daniel> it's this palm http://cgi.ebay.de/G232-Palm-Pilot-5000_W0QQitemZ5815900973QQcategoryZ38331QQssPageNameZWDVWQQrdZ1QQcmdZViewItem
Oct 08 08:57:43 <[g2]> I've considered reflashing Palms a zillion times, but just not hooking it up to a slug
Oct 08 08:57:53 <[g2]> it's a neat idea 
Oct 08 08:58:04 <cheef_daniel> I have found a project in the web, for using a Palm as LCD-Display, so I thought would be cool if I get it work on the slug
Oct 08 08:58:24 <cheef_daniel> the project is called palmorb
Oct 08 08:58:38 <cheef_daniel> http://palmorb.sourceforge.net/
Oct 08 08:59:09 <cheef_daniel> it is for PalmOS 2.0 and above
Oct 08 08:59:28 <[g2]> cool
Oct 08 09:01:24 <cheef_daniel> and instead of the palm you could connect a LCD
Oct 08 09:01:45 <cheef_daniel> but the palm pilot 5000 is very old so you can get 
Oct 08 09:01:49 <cheef_daniel> it for low
Oct 08 09:20:20 <dwery> rwhitby-away: ping
Oct 08 09:20:52 <dwery> jbowler-zzz: ping
Oct 08 09:34:36 <dwery> rwhitby-away, jbowler-zzz: I'd be happy if you can comment on the mail I want to send to l-a-k: http://rafb.net/paste/results/12gyCK56.html
Oct 08 10:35:16 <jbowler-zzz> dwery: with the attachment currently in CVS (i.e. 10-ixp4xx-copy-from.patch) this looks good.  Check the spelling of philosophical (I think).  Add a signed-off by me if you think that's appropriate.
Oct 08 10:35:34 <dwery> yep, I just used dict to chak that :)
Oct 08 10:35:49 <dwery> check!
Oct 08 10:35:51 <dwery> :)
Oct 08 10:36:15 <dwery> btw, I tested your patch both with and w/o the pci le patch
Oct 08 10:36:41 <dwery> it works both ways!
Oct 08 10:36:50 <dwery> did you expected this behaviour?
Oct 08 10:37:11 <jbowler-zzz> Yes - I believe you will find the USB doesn't work without pci-le but nothing else goes wrong.
Oct 08 10:37:37 <dwery> jbowler-zzz: exactly, the only problem is usb
Oct 08 10:38:06 <dwery> is the usb chip connected to the PCI or the AHB?
Oct 08 10:38:12 <jbowler-zzz> So Lennert's original comments on l-a-k (about it affecting the whole AHB) seem incorrect.
Oct 08 10:38:27 <jbowler-zzz> USB->PCI->AHB (if I understand this correctly)
Oct 08 10:40:03 <dwery> given that the both OHCI and EHCI are recognized, I think the communication is mostly ok
Oct 08 10:41:01 <jbowler-zzz> What happens without the patch?  Are they still recognised?
Oct 08 10:41:11 <dwery> yes. 
Oct 08 10:41:19 <dwery> i'll post the dmsg, gimme a sec
Oct 08 10:42:09 <dwery> http://rafb.net/paste/results/8RRd8o81.html
Oct 08 10:42:20 <dwery> this is the dmesg w/o the 90-pci-le.patch
Oct 08 10:42:28 <jbowler-zzz> If I understood Andrew correctly the problem arises with recognising devices on the USB
Oct 08 10:43:20 <jbowler-zzz> SDRAM controller and PCI controller are peers, both connected to the AHB (the 133MHz bus), I can't see why that setting would affect anything other than the PCI controller.
Oct 08 10:43:57 <jbowler-zzz> Lines 22+ of that dmesg are the problem
Oct 08 10:44:26 <dwery> i don;t know. It seems the chips are detected correctly. the internal hubs are also detected correctly
Oct 08 10:44:43 <dwery> it's just the exchanged data that is wrong probably
Oct 08 10:44:58 <jbowler-zzz> Then the USB mass storage device fails - that doesn't happen on my builds (which have the patch)
Oct 08 10:45:44 <dwery> I wonder if there's something that should be set in the chip
Oct 08 10:49:07 <jbowler-zzz> The weird thins is that the Intel product brief has the USB controller hanging off the APB (the slow, 60MHz, bus)
Oct 08 10:49:37 <jbowler-zzz> Did LinkSys put a USB2.0 controller on the PCI bus maybe?  (The XScale one is supposedly USB 1.1)
Oct 08 10:50:15 <dwery> i think so.. i'mm be back in a few.
Oct 08 10:53:04 <jbowler-zzz> We get: PCI: enabling device 0000:00:01.2 (0140 -> 0142)
Oct 08 10:53:26 <jbowler-zzz> Then: ehci_hcd 0000:00:01.2: EHCI Host Controller
Oct 08 10:53:31 <jbowler-zzz> Likewise for OHCI
Oct 08 10:54:57 <cheef_daniel> [g2]: got terminal on palm
Oct 08 10:55:10 <jbowler-zzz> Well, never mind - the patch works and the objections on l-a-k seem invalid and were answered on the ML
Oct 08 11:02:31 <dwery> jbowler-away: the patch works. but it would be better if we can explain them why :D
Oct 08 11:04:08 <dwery> Jacmet: ping
Oct 08 12:11:24 <[g2]> BTW jbowler-away, dwery interestingly enought the Loft with a different USB controller (a Philips) has exactly the same no_irq issue
Oct 08 12:11:48 <[g2]> that's a PCI/USB contorller like the NEC
Oct 08 12:12:07 <dwery> [g2]: so what do you think about this pci/le matter?
Oct 08 12:13:09 <[g2]> dwery I haven't followed it detail
Oct 08 12:13:54 <[g2]> I know you guys are trying to understand the stuff in detail as it effects LE
Oct 08 12:14:19 <dwery> yes. the flash now works both with and w/o the pci le patch. 
Oct 08 12:14:22 <dwery> so
Oct 08 12:14:37 <[g2]> well Flash is off the EXP bus
Oct 08 12:14:48 <dwery> while the usb controller
Oct 08 12:14:51 <dwery> does not
Oct 08 12:15:06 <[g2]> I'd guess it's because it's off the PCI bus
Oct 08 12:15:22 <dwery> isn't tje usb controller on the pci?
Oct 08 12:15:37 <[g2]> yes, but flash isn't
Oct 08 12:15:46 <dwery> ok, understood.
Oct 08 12:15:51 <dwery> now. the usb chip
Oct 08 12:15:58 <dwery> is detected regardless of the patch.
Oct 08 12:16:43 <[g2]> my limited understanding of PCI is there are 3 areas: Config, IO, and Memory
Oct 08 12:17:02 <[g2]> i think the Config regs may need to be LE
Oct 08 12:17:24 <[g2]> A PC legacy issue
Oct 08 12:17:36 <[g2]> I haven't read the spec though
Oct 08 12:18:10 <dwery> i thought most of pci was le
Oct 08 12:18:15 <[g2]> it's quite easy do dump the config area though
Oct 08 12:18:56 <[g2]> I don't have a pci bus analyzer
Oct 08 12:19:01 <dwery> nor I :-D
Oct 08 12:19:25 <[g2]> otherwise, it'd be pretty straight forward to hookup to the bus and watch the transactions in both cases
Oct 08 12:20:31 <[g2]> if I can I'm gonna try and get my board vendor to record the PCI bus errors with the no IRQ debug
Oct 08 12:20:45 <[g2]> s/no_irq error/
Oct 08 12:20:55 <dwery> what exactly the PCI_CSR_ABE flag does?
Oct 08 12:22:35 <[g2]> this looks interesting http://www.cygwin.com/ml/ecos-patches/2003-04/msg00040.html
Oct 08 12:23:23 <cheef_daniel> <--standalone-mp3-player works 
Oct 08 12:24:12 <[g2]> dwery have you seen this thread ? http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2004-April/021700.html
Oct 08 12:24:33 <dwery> [g2]: i;m checking the other link :)
Oct 08 12:26:29 <[g2]> dwery I'm guessing you guys went over the Intel LE/BE app note right ?
Oct 08 12:26:30 <dwery> mm.. Deepak is suggesting that we must always do ABE?
Oct 08 12:30:41 <[g2]> dwery I don't know I haven't checked out the threads
Oct 08 12:30:45 <jbowler-away> Yes, and the other flags too - i.e. the setting is not endianness dependent.  Ok, we need to try that too (cos the patch just sets ABE, not the other stuff.)
Oct 08 12:31:17 <dwery> jbowler-away: i can test it right now. shall I?
Oct 08 12:31:18 <[g2]> hey jbowler :)
Oct 08 12:31:25 <jbowler-away> Assuming it works then there's not going to be a problem pushing it upstream, if, indeed, Deepak hasn't already integrated it.
Oct 08 12:31:35 <jbowler-away> dwery: yes, that would be goo.
Oct 08 12:31:39 <jbowler-away> hi [g2]
Oct 08 12:31:39 <dwery> ok
Oct 08 12:32:22 <[g2]> you know we can also talk to the Intel support reps too
Oct 08 12:33:12 <[g2]> we should get a dialog going with some of the chip support guys
Oct 08 12:34:02 <[g2]> or find out they are just totally in bed with MV and then Deepak is the gatekeeper :)
Oct 08 12:34:30 <[g2]> did I say that aloud ? :)
Oct 08 12:34:49 <jbowler-away> The main Intel thing IMO is to find some what to persuade them to release at least part of the IXP library under an MIT (or similar) license.
Oct 08 12:35:16 <dwery> *PCI_CSR = PCI_CSR_IC | PCI_CSR_ABE | PCI_CSR_PDS | PCI_CSR_ADS; does NOT work
Oct 08 12:36:18 <jbowler-away> Hum...  so Deepak was wrong, but that message was from 2004.  We know +ABE (alone) does work... I guess it's time to read the documentation again ;-)
Oct 08 12:36:22 <jbowler-away> bbl - lunch
Oct 08 12:36:42 <[g2]> cheers -- bon ap.
Oct 08 12:37:25 <[g2]> jbowler-away that may have been with the A0 steppings also
Oct 08 12:41:16 <dwery> [g2]: can you pint me to any relevant documentation?
Oct 08 12:43:23 <[g2]> That's the LE/BE appnote http://www.intel.com/design/network/applnots/25423701.pdf
Oct 08 12:44:02 <dwery> going to read
Oct 08 12:45:47 <[g2]> enjoy :)
Oct 08 12:46:05 <[g2]> and you've got the link to the developers manual right ?
Oct 08 12:57:42 <dwery> AHB [see ARM Ltd., AMBA Specification, Rev. 2.0, May 1999] bus itself supports both
Oct 08 12:57:42 <dwery> endians. It is not clear in industry, which mode is used more often. The IXP425 uses AHB in
Oct 08 12:57:42 <dwery> big-endian mode, which is set by the way the memory controller hardware is connected to the
Oct 08 12:57:42 <dwery> AHB bus.
Oct 08 12:58:13 <dwery> Although not specifically claimed in its specification (except in its configuration space) [see
Oct 08 12:58:13 <dwery> PCI Local Bus Specification, Draft, Revision 2.2, June 8, 1998], PCI is de facto a little-endianonly
Oct 08 12:58:13 <dwery> bus because it is always used in the little-endian mode. All devices on a PCI bus will
Oct 08 12:58:13 <dwery> appear as little endian devices.
Oct 08 12:59:29 <[g2]> dwery the second paragraph concurs with my understanding
Oct 08 12:59:36 <dwery> yep
Oct 08 13:01:19 <[g2]> it'd be cosmically ironic if the LE actually runs faster then BE for both DISK/NET (PCI transactions) and NPE cause they've got enough HP to swap away
Oct 08 13:01:30 <[g2]> s/then/than
Oct 08 13:02:52 <[g2]> Initial indications are the Loft's PCI/USB/DISK access appears faster than the NEC, but it could be just from a Clock increase to 533
Oct 08 13:04:05 <dwery> please read page 19 of the le/be app
Oct 08 13:04:47 <dwery> it says ABE should be 1
Oct 08 13:04:57 <dwery> if I've understood correctly.
Oct 08 13:05:05 <[g2]> section 4.1
Oct 08 13:07:07 <dwery> that should be enough to have our patch accepted?
Oct 08 13:11:33 <[g2]> dwery the patch hs pci_csr_ads=0, pci_csr_pds=0 and pci_csr_abe=1 ?
Oct 08 13:11:40 <dwery> yes
Oct 08 13:11:45 <[g2]> and it works
Oct 08 13:11:48 <dwery> yes
Oct 08 13:12:08 <[g2]> for csr 1.4,1.5 and 2.0 ?
Oct 08 13:12:49 <dwery> I'm only testing with the buil-in USB controller
Oct 08 13:12:52 <dwery> no CSR tests
Oct 08 13:13:16 <[g2]> ok... you're running the OHCI controller in 1.1
Oct 08 13:13:49 <dwery> EHCI and OHCI
Oct 08 13:14:03 <[g2]> kinda
Oct 08 13:14:20 <[g2]> it's a non high-speed EHCI
Oct 08 13:14:26 <[g2]> non 480
Oct 08 13:14:35 <[g2]> it does 12Mbs right
Oct 08 13:15:14 <dwery> ok
Oct 08 13:15:50 <[g2]> it's also an on-chip resource that doesn't utilize the PCI bus correct ?
Oct 08 13:16:26 <dwery> i think the USB controller is connected to the pci bus
Oct 08 13:16:41 <[g2]> could be
Oct 08 13:16:55 <[g2]> just internally
Oct 08 13:17:31 <dwery> if I activate pci byte swapping (pds and ads), the usb controller doesn;t work anymore. So i suppose it's connected to the pcibus
Oct 08 13:17:31 <[g2]> so my concerns are 
Oct 08 13:17:48 <[g2]> 1) Proven working sw (cause the proof of the pudding is in the tasting)
Oct 08 13:18:23 <dwery> we  have it.
Oct 08 13:18:41 <[g2]> 2) There is a pci_csr_abe setting and while the 12/03 APP note says its always 1, things to change in time (possibly new microcode)
Oct 08 13:19:05 <dwery> it's 1 in our patch also
Oct 08 13:19:18 <[g2]> 3) How does it work with the 1.4 (our CSR legacy), 1.5 and 2.0 LE and BE for compatibilty
Oct 08 13:19:53 <[g2]> right I think it's set that way now and probably should be set that way as specificied in the app note
Oct 08 13:19:55 <dwery> i've tested csr 2 on this le system and it worked. 
Oct 08 13:20:21 <[g2]> that's a good thing (tm)
Oct 08 13:20:38 <dwery> it has also been tested in be and worked too
Oct 08 13:20:39 <[g2]> so CSR 2.0 in LE mode or BE mode or both ?
Oct 08 13:21:30 <dwery> both
Oct 08 13:21:39 <dwery> and both with abe=1
Oct 08 13:22:12 <[g2]> ok.. so that would leave the 1.5 and 1.4 (1.4 probably already works in BE mode)
Oct 08 13:22:52 <[g2]> and there may be no change from that APP note in which case there's probably no reason not to push that change (except for 46x)
Oct 08 13:23:03 <[g2]> or 45x
Oct 08 13:23:18 <dwery> well, i think I'll send the patch upstream then.
Oct 08 13:24:45 <[g2]> you may want to reference the app note
Oct 08 13:25:15 <dwery> yes
Oct 08 13:25:22 <[g2]> I'd just pitch it like from what I can interpret....
Oct 08 13:41:19 <snotling> hey guys, how can I edit properly the defconfig of the openslug kernel ?
Oct 08 13:42:15 <[g2]> snotling search the wiki for "kernel tweaks"
Oct 08 13:42:25 <[g2]> you'll find the wiki page I wrote
Oct 08 13:51:10 <snotling> [g2]: well, but that doesn't tell me of to edit the defconfig... :-)
Oct 08 13:53:17 <[g2]> snotling for building changes you can follow what the wiki says
Oct 08 13:53:49 <[g2]> once you have your changes you just replace the defconfg in the given kernel directory and bump the PR number
Oct 08 13:54:36 <[g2]> now things are a little different since the 2.6.11+ kernels but I think the defconfig is there for all kernels 
Oct 08 13:54:39 <[g2]> clear ?
Oct 08 13:55:23 <snotling> [g2] : are you talking about <http://www.nslu2-linux.org/wiki/HowTo/TweakKernelOrPackagesInOE> ?
Oct 08 13:56:21 <[g2]> snotling that's the jist of it.
Oct 08 13:57:23 <[g2]> are you testing kernel modules or is a really simple change ?
Oct 08 13:57:28 <snotling> yes but my question is how can I produce a valid defconfig ?
Oct 08 13:57:51 <snotling> if I do a make menuconfig it goes back to i386 by default...
Oct 08 13:58:09 <[g2]> right because it's the wrong arch
Oct 08 13:58:21 <[g2]> you need a make ARCH=arm menuconfig with the proper tools
Oct 08 13:58:45 <snotling> thanks
Oct 08 13:59:20 <[g2]> export CROSS_COMPILE to point to the OE tools
Oct 08 13:59:52 <snotling> well, I use biybake to compile, I just needed the 'ARCH=' tip :-)
Oct 08 14:00:39 <[g2]> you can go directly into the directory and just
Oct 08 14:01:26 <[g2]> export CROSS_COMPILE=..../tmp/openslug/cross/bin/armeb-linux-
Oct 08 14:01:39 <[g2]> where the .... is your local path stuff
Oct 08 14:02:02 <[g2]> then it's a make ARCH=arm menuconfig
Oct 08 14:02:13 <dwery> [g2]: http://rafb.net/paste/results/70GNHK14.html . Please comment :)
Oct 08 14:02:13 <[g2]> and make ARCH=arm zImage 
Oct 08 14:03:11 <[g2]> dwery, is that page 11 or page 19
Oct 08 14:03:46 <dwery> definitions on 11, setting on 19
Oct 08 14:04:35 <[g2]> ok.. line for spelling of endianness
Oct 08 14:06:46 <eFfeM> hi, found this in my log, anyone any idea what it means or what I should do to cure it?
Oct 08 14:06:49 <eFfeM> Oct  9 02:51:00 (none) user.warn kernel: Warning: bad configuration page, trying to continue
Oct 08 14:06:58 <dwery> ok. i'm sending it, let's see if we get any complain :)
Oct 08 14:07:04 <dwery> eFfeM: i've been told it's normal.
Oct 08 14:07:12 <eFfeM> ah ok, tnx
Oct 08 14:07:45 <eFfeM> apparently every reboot my clock gets 2 hrs ahead, and I was browsing through the log to see if I could find something
Oct 08 14:08:10 <eFfeM> (2hrs is my timezone diff with GMT)
Oct 08 14:09:20 <dwery> eFfeM: there bust be a timezone/utc setting in /etc / grep for UTC and/or TZ
Oct 08 14:09:25 <dwery> s/bust/must/
Oct 08 14:10:45 <eFfeM> yeah, I know, the odd thing is that apparently the hw clock is set with a the localtime on a reboot and next time it thinks that time is gmt, so it adds 2; now rebooting again to see if this indeed is the case
Oct 08 14:11:04 <eFfeM> yup, it is now 5 am
Oct 08 14:11:08 <eFfeM> :-)
Oct 08 14:14:46 <dwery> I suggest to set the hw clock to UTC and instruct the system that it's set this way.
Oct 08 14:16:53 <eFfeM> yeah, seems a good idea.
Oct 08 14:17:09 <eFfeM> however I found this: rcS.d/S08hwclock.sh
Oct 08 14:17:21 <dwery> which distro are you using?
Oct 08 14:17:40 <eFfeM> openslu
Oct 08 14:17:42 <eFfeM> openslug
Oct 08 14:18:15 <eFfeM> this one writes back the clock upon shutdown
Oct 08 14:18:45 <dwery> the command that writes the clock must be instructed to write it in utc
Oct 08 14:19:26 <dwery> usually there's a configuration in /etc/default/rcS
Oct 08 14:19:46 <dwery> (well.. on Debian at least)
Oct 08 14:20:10 <eFfeM> there is
Oct 08 14:20:33 <eFfeM> it says UTC=yet
Oct 08 14:20:35 <eFfeM> it says UTC=yes
Oct 08 14:21:05 <eFfeM> set it to no, now rebooting
Oct 08 14:22:22 <eFfeM> argh now it is 7 am
Oct 08 14:23:34 <dwery> [g2]: Lennert approved the patch :)
Oct 08 14:23:42 <dwery> one less.
Oct 08 14:23:58 <eFfeM> dwery, i'm a little bit lost, apparently I got four hwclock scripts
Oct 08 14:24:00 <eFfeM> init.d/hwclock.sh    rc6.d/S45hwclock.sh
Oct 08 14:24:00 <eFfeM> rc0.d/S45hwclock.sh  rcS.d/S08hwclock.sh
Oct 08 14:24:40 <dwery> eFfeM: it's ok.
Oct 08 14:26:29 <eFfeM> yeah, they are all symlinks to the init.d one
Oct 08 14:26:50 <dwery> eFfeM: set UTC=yes, check your timezone settings, adjust the software clock with the correct time in your timezone and reboot.
Oct 08 14:27:30 <eFfeM> ok, one sec
Oct 08 14:29:16 <eFfeM> rebooting, stay tuned
Oct 08 14:29:47 <dwery> eFfeM: if it doesn't work you'll have to ask someone which is more experienced than me on openslug
Oct 08 14:31:11 <eFfeM> 2 hrs off it is
Oct 08 14:31:30 <eFfeM> i think I keep the clock on gmt and just change it 2 hrs
Oct 08 14:32:22 <dwery> please do an hwclock --show
Oct 08 14:32:29 <dwery> or cat /proc/driver/rtc
Oct 08 14:32:53 <eFfeM> Sat Oct  8 23:31:27 2005  0.000000 seconds
Oct 08 14:33:11 <eFfeM> just removed /etc/localtime
Oct 08 14:33:27 <eFfeM> rebooting again....
Oct 08 14:33:47 <dwery> the clock seems correct.
Oct 08 14:34:28 <eFfeM> yeah, but it seems to be kept in gmt, and then it is corrected for my tz making it 2 hrs off
Oct 08 14:34:44 <eFfeM> upon going down it scribbles this value to the device 
Oct 08 14:35:05 <dwery> you may want to check if --utc is passed to the program that writes the clock oin shutdown
Oct 08 14:35:05 <eFfeM> the script seems to take the TZ env var into account but not /etc/localtime
Oct 08 14:36:28 <eFfeM> it does not pass -utc. however after removing /etc/localtime it gives the right time. 
Oct 08 14:36:58 <eFfeM> probably I'll have to correct for dst every half year (or use ntp, even better, but I did not get to that)
Oct 08 14:37:04 <eFfeM> dwery, thanks for your help
Oct 08 14:37:08 <dwery> eFfeM: np
Oct 08 16:47:29 <rwhitby-away> For those interested, the debian architecture requalification discussion happens on #debian-tech on irc.oftc.net in 15 minutes time.
Oct 08 16:50:25 <dwery> rwhitby-away: will you track it?
Oct 08 16:50:55 <rwhitby-away> quite a few of the core team are there
Oct 08 16:51:07 <dwery> i'll try to follow it but it's quite late...
Oct 08 16:54:06 <dwery> rwhitby-away: a couple of patches are on l-a-k, the first one got lennert;s approvation.
Oct 08 17:00:46 <rwhitby-away> dwery: nice work on the patches.
Oct 08 17:01:24 <dwery> it's a bit harder with the x1205.. the maintainer is dissecting and commenting line-by-line :)
Oct 08 17:01:41 <rwhitby-away> I'd say wait at least a day between patches to l-a-k, to allow people to respond without getting swamped
Oct 08 17:01:58 <rwhitby-away> dwery: re x1205 - that's better than being ignored :-)
Oct 08 17:02:40 <dwery> I had to convince him.. it seems is quite busy.. I told the whole story about the nslu2 project
Oct 08 17:04:18 <dwery> it's getting harder to have patches in the kernel.. it wasn;t this way years ago.. and I've the feeling this is not good at all.. to many good things may be lost...
Oct 08 17:11:50 <CIA-8> 03bzhou * 10unslung/make/py-roundup.mk: upstream upgrade from 0.8.4 to 0.8.5
Oct 08 17:45:38 <cheef_daniel> how can I load USB related modules during boot? modules.conf didn't work or I am doing sth. wrong
Oct 08 17:46:09 <cheef_daniel> (openslug 2.7beta)
Oct 09 01:34:22 <[o]izo> hello 
Oct 09 01:46:11 <[o]izo> i'm trying to install nslu2 on a ds101g+ (firmware 240) 
Oct 09 01:49:29 <rwhitby-away> that's not possible
Oct 09 01:49:38 <[o]izo> why ? 
Oct 09 01:49:49 <rwhitby-away> are you perhaps trying to install optware to the ds101g+?
Oct 09 01:50:07 <[o]izo> i'm on this page http://www.nslu2-linux.org/wiki/DS101/HomePage 
Oct 09 01:50:41 <[o]izo> actualy i'm trying to enable telnet without the php tips
Oct 09 01:51:10 <rwhitby-away> ok, you want #ds101-linux - the guys doing that hang out there.
Oct 09 01:51:50 <rwhitby-away> in particular, mcdmx-away and NAiL and rss_
Oct 09 01:52:19 <[o]izo> thx 
Oct 09 01:52:34 <[o]izo> what a small chan ... :) 
Oct 09 02:30:35 <dwery> rwhitby-away: anythig interesting in last night debian discussion?
Oct 09 02:49:03 <rwhitby-away> dwery: I can send you the log if you like....
Oct 09 02:49:14 <dwery> yes, thanks
Oct 09 02:50:45 <rwhitby-away> http://people.debian.org/~vorlon/20051009-releasequalification.log
Oct 09 02:51:02 <dwery> thanks
Oct 09 02:52:27 <cheef_daniel> hi, why are some kernel-modules not loaded at start, only when I replug my USB-HUB/devices they get loaded?
Oct 09 02:53:05 <dwery> cheef_daniel: hotplug does the trick.
Oct 09 02:53:16 <dwery> cheef_daniel: use /etc/modules eventually
**** ENDING LOGGING AT Sun Oct 09 02:59:56 2005