**** BEGIN LOGGING AT Thu May 19 23:59:56 2005
May 20 03:26:18 <dyoung> morning sunshine
May 20 03:26:27 <[g2]> morning dyoung
May 20 03:27:06 <[g2]> ntpdc> peers
May 20 03:27:06 <[g2]>      remote           local      st poll reach  delay   offset    disp
May 20 03:27:06 <[g2]> =======================================================================
May 20 03:27:08 <[g2]> =otc2.psu.edu    192.168.123.2    2 1024  377 0.05080  0.040910 0.01485
May 20 03:27:10 <[g2]> =ntp-4.cns.vt.ed 192.168.123.2    2 1024  377 0.04562  0.016204 0.01483
May 20 03:27:12 <[g2]> =bob.greenwood.w 192.168.123.2    2 1024  377 0.33946 -0.005444 0.01485
May 20 03:27:14 <[g2]> *ns3.oit.unc.edu 192.168.123.2    2 1024  377 0.01413  0.002585 0.01483
May 20 03:27:16 <[g2]> dyoung, does that look good ?
May 20 03:27:38 <dyoung> Looks god to me.
May 20 03:27:52 <dyoung> your offset is within "spec".
May 20 03:28:06 <[g2]> what is the "spec"
May 20 03:28:35 <[g2]> cat /etc/ntp.drift
May 20 03:28:35 <[g2]> 11.699
May 20 03:30:04 <dyoung> I consider "spec" to be > 1s
May 20 03:30:37 <dyoung> I think that drift value is similar to what others have had, but I'd have to look it up
May 20 04:26:26 <[g2]> dyoung, ping
May 20 04:28:44 <dyoung> hi
May 20 04:30:49 <[g2]> my mind is cloudy, but isn't the wlan-ng just for 2.4 ?
May 20 04:31:06 <[g2]> I thought hostap replaced taht
May 20 04:31:10 <[g2]> I thought hostap replaced that
May 20 04:31:40 <dyoung> I thought hostap was if you really wanted to run a hostap?
May 20 04:31:52 <dyoung> while wlan-ng is simply a client driver?
May 20 04:32:12 <[g2]> no they are competing drivers 
May 20 04:32:38 <[g2]> with slightly different functionality
May 20 04:34:20 <jacques> you just answered your own question
May 20 04:34:34 <jacques> they are competing with different functionality - one does not replace the other
May 20 04:34:36 <dyoung> took a quick look at the faq, looks like wlan-ng still maintained, verified to 2.6.10.
May 20 04:35:45 <dyoung> Well, in any case, its all a rouse for someone to send me a USB Wireless Dongle. :-)
May 20 04:36:00 <jacques> is hostap being developed again? I was using it a few years ago when some of my cards weren't supported well enough by wlan-ng, but then it stagnated and wlan-ng leap-frogged hostap
May 20 04:37:06 <[g2]> about 12-18 months ago the guys in gentoo-laptop were hating wlan-ng and recommending hostap
May 20 04:37:18 <jacques> and I do recall one of them supported USB and the other not, tho that may well have changed by now
May 20 04:37:21 <[g2]> Topic for #gentoo-laptop is 2.4 PCMCIA: Disable all kernel pcmcia, enable wireless support but no drivers, emerge pcmcia-cs || 2.6 PCMCIA: Enable any kernel pcmcia drivers needed, emerge pcmcia-cs
May 20 04:37:47 <[g2]> that's from today's topic
May 20 04:38:06 <dyoung> hostap README says its supposed to work with 2.6
May 20 04:38:37 <[g2]> I remember playing with the patchset needed for wlan-ng and pcmcia-cs
May 20 04:38:38 <jacques> heh, pcmcia is a mess
May 20 04:38:49 <dyoung> I had a link to a table that someone made notating which USB dongles were supported and which not.
May 20 04:39:00 <dyoung> whered it go.....
May 20 04:39:28 <[g2]> hmmmm....... pci->usb->pcmcia-> ....
May 20 04:39:57 <[g2]> does it just show up as a pci device ?
May 20 04:40:18 <[g2]> or more likely a usb device
May 20 04:40:45 * dyoung dunnos
May 20 04:40:56 <jacques> usb
May 20 04:41:15 <dyoung> All I know for sure is my El Cheepo Netgear isnt reconized by any linux.  
May 20 04:41:25 <jacques> i have some microsoft branded ones that I like - I've used them on linux fine
May 20 04:41:35 <jacques> with wlan-ng
May 20 04:42:37 <jacques> (they are older 802.11b ones - are you looking for g?)
May 20 04:43:04 <dyoung> I th ink [g2] brought it up because I replied to a yahoo ml post.
May 20 04:43:12 <dyoung> I dunno what that guy wants.
May 20 04:43:18 <[g2]> madwifi support the atheros drivers right ?
May 20 04:43:39 <[g2]> dyoung, pezactly
May 20 04:44:01 <jacques> yeah that sounds right
May 20 04:44:25 <jacques> Multiband Atheros Driver for WiFi (MADWIFI): Linux driver for 802.11a/b/g universal NIC cards - Cardbus, PCI, or miniPCI - using Atheros chip sets.
May 20 04:44:47 <dyoung> The point of my post is that it ought to be cake to copy/paste/steal/borrow stuff from other .bb files to bend it to his will.
May 20 04:46:46 <dyoung> waitaminnut.
May 20 04:46:58 <dyoung> jacques, you just said something that made me go Hmm...
May 20 04:47:25 <dyoung> This WG111 that isnt reconized by anything I plug it into is sold by Tivo.
May 20 04:47:49 <dyoung> so I guess I'm just not lickin it right.
May 20 04:48:32 <jacques> sometimes you gotta add the usb ids to something
May 20 04:48:49 <jacques> because the manufacturers/rebranders change them
May 20 04:49:25 * dyoung bah humbugs.
May 20 04:49:39 <dyoung> Its not that important.
May 20 04:49:50 <dyoung> I'll look at it later. :-)
May 20 06:10:05 <VoodooZ_Work> morning.
May 20 06:10:11 <VoodooZ_Work> hey dyoung
May 20 06:13:57 <dyoung> morning.
May 20 06:14:26 <dyoung> time for bed though.
May 20 06:23:17 <CIA-1> 03jp30 * 10unslung/Makefile: use gcc -E for TARGET_CPP on slug
May 20 06:55:27 <barrym> Anyone else notice that on the Unslung 4.20 Linksys Administration -> Advanced -> Upgrade page, the Maintenance Mode push-button at the bottom of the page is always in "Exit Maintenance Mode"?  I've tried hitting it a couple of times and it doesn't change state.
May 20 06:57:37 <barrym> Is the Maintenance Mode concept no longer used in 4.20?
May 20 07:07:43 <visitest> who
May 20 07:21:27 <ka6sox> barrym post that comment about the maintainence mode to the ML?
May 20 07:21:54 <ka6sox> maybe others have seen it too.
May 20 07:21:58 <ka6sox> (or will look)
May 20 14:33:34 <jbowler> ~ping [g2]
May 20 14:33:36 <jbot> pong [g2]
May 20 14:36:06 <jbowler> ~seen [g2]
May 20 14:36:08 <jbot> [g2] is currently on #openjtag (11h 12m 1s) #nslu2-linux (11h 12m 1s) #oe (11h 12m 1s).  Has said a total of 28 messages.  Is idling for 3h 58m 9s
May 20 14:38:55 <[g2]> jbowler, pong
May 20 14:39:22 <jbowler> hi; I think pulling the RTC stuff is fine, the fact that it loses 1 month every reboot makes it useless...
May 20 14:39:38 <jbowler> What happens if you run 'hwclock' with the change?
May 20 14:39:56 <[g2]> the 1 month is a 0 versus 1 thing that dyoung had identified but had not fully fixed
May 20 14:40:20 <[g2]> but I'm more interested in a stable reliable NTP
May 20 14:41:19 <jacques> yeah that one month thing is very annoying
May 20 14:42:21 <jbowler> So the main thing that worries me is if executing hwclock does something bad (like a panic)...
May 20 14:44:06 <[g2]> I can try executing hwclock
May 20 14:44:37 <[g2]> hwclock -r 
May 20 14:44:39 <jbowler> That would be good.
May 20 14:44:44 <[g2]> should I try that ?
May 20 14:45:09 <[g2]> DOH!
May 20 14:45:11 <jbowler> Try 'hwclock' (no args) 'hwclock --systorc' and 'hwclock --rctosys'
May 20 14:45:22 <[g2]> just kidding :
May 20 14:45:25 <[g2]> just kidding :)
May 20 14:45:33 <[g2]> hwclock -r
May 20 14:45:33 <[g2]> hwclock: Could not access RTC: No such file or directory
May 20 14:45:42 <[g2]> I had pulled the sensor stuff too
May 20 14:45:57 <jbowler> What's the sensor stuff?
May 20 14:46:32 <[g2]> well the X1205 was read by the spi ?
May 20 14:47:22 <jbowler> I don't know the code...
May 20 14:47:52 <[g2]> Ok... I've got the busybox hwclock and all the options just return the error message about can't access the hw clock
May 20 14:48:05 <[g2]> hwclock: Could not access RTC: No such file or directory
May 20 14:48:09 <jbowler> Sounds good.
May 20 14:48:27 <[g2]> THX for letting me know about that it was a good idea to check
May 20 14:49:01 <[g2]> Oh.. Power down doesn't work right now and needs to be bolted back in
May 20 14:49:34 <[g2]> and a little support for changing the LED
May 20 14:49:52 <[g2]> hey jbowler 
May 20 14:50:12 <[g2]> my drift has been around 12 ppm is that good or not ?
May 20 14:50:46 <[g2]> it's been slowly creeping up
May 20 14:51:08 <[g2]> ntptime
May 20 14:51:08 <[g2]> ntp_gettime() returns code 0 (OK)
May 20 14:51:08 <[g2]>   time c638da3d.81409000  Fri, May 20 2005 21:50:53.504, (.504891),
May 20 14:51:08 <[g2]>   maximum error 536612 us, estimated error 27961 us
May 20 14:51:08 <[g2]> ntp_adjtime() returns code 0 (OK)
May 20 14:51:10 <[g2]>   modes 0x0 (),
May 20 14:51:12 <[g2]>   offset 3775.000 us, frequency 12.556 ppm, interval 4 s,
May 20 14:51:12 <jbowler> 12 is good - the adjustment to the tick value is drift/100, so any value >-100 <100 means the tick is as close as it can be.
May 20 14:51:14 <[g2]>   maximum error 536612 us, estimated error 27961 us,
May 20 14:51:16 <[g2]>   status 0x1 (PLL),
May 20 14:51:18 <[g2]>   time constant 6, precision 1.000 us, tolerance 512 ppm,
May 20 14:51:20 <[g2]>   pps frequency 0.000 ppm, stability 512.000 ppm, jitter 200.000 us,
May 20 14:51:22 <[g2]>   intervals 0, jitter exceeded 0, stability exceeded 0, errors 0.
May 20 14:51:46 <[g2]> That sounds good
May 20 14:51:57 <[g2]> tickadj
May 20 14:51:57 <[g2]> tick = 10101
May 20 14:52:44 <[g2]> ntpq -c rv
May 20 14:52:44 <[g2]> status=0684 leap_none, sync_ntp, 8 events, event_peer/strat_chg,
May 20 14:52:44 <[g2]> version="ntpd 4.2.0@1.1161-r Tue May 10 12:39:37 EDT 2005 (1)",
May 20 14:52:44 <[g2]> processor="armv5teb", system="Linux/2.6.11.2", leap=00, stratum=3,
May 20 14:52:44 <[g2]> precision=-16, rootdelay=28.167, rootdispersion=100.945, peer=37341,
May 20 14:52:45 <[g2]> refid=152.2.21.1,
May 20 14:52:52 <jbowler> Yes, the initial error will be very high without the RTC, but the first thing is to reset the clock to the server, that still leaves a potentially large error - that's probably where the 0.5s max comes from.
May 20 14:52:56 <[g2]> eftime=c638d700.f4f301ea  Fri, May 20 2005 21:37:04.956, poll=10,
May 20 14:52:56 <[g2]> clock=c638da9b.64f29d40  Fri, May 20 2005 21:52:27.394, state=4,
May 20 14:52:56 <[g2]> offset=4.623, frequency=12.556, jitter=27.962, stability=0.034
May 20 14:53:51 <jbowler> You're bound to a stratum 3 server, which is fine, but they can drift a lot too.
May 20 14:54:17 <[g2]> is that what the clear values command is to get a fresh start ?
May 20 14:54:22 <[g2]> in ntpq
May 20 14:54:32 * [g2] is an NTP idiot
May 20 14:54:56 <[g2]> fully got the concepts, but the practice needs more work :)
May 20 14:55:36 <jbowler> clear values: I'm not sure ;-)  I just kept typing commands until something work...
May 20 14:56:41 <[g2]> it's either reset values or clear values ... g2 goes to check
May 20 14:57:00 <[g2]> clearvars
May 20 14:57:42 <jbowler> Hum, if the power button doesn't work, do the LEDs?
May 20 14:58:09 <[g2]> No... The LEDS don't work either.. It stays amber
May 20 14:59:34 <[g2]> Hmmmm.... I wonder if it's the SPI code that's bit banging access to the RTC thats buggy and not the RTC code ?
May 20 15:00:02 <[g2]> that'll be a good test later
May 20 15:02:48 <jbowler> Where's the SPI code?
May 20 15:04:14 <[g2]> Ok... it's the I2C
May 20 15:04:45 <[g2]> My bad :(
May 20 15:05:49 <[g2]> I've got SPI on the brain from that 512MB SD hack to the wrt54g that jacques pointed out the other day
May 20 15:06:17 <[g2]> I was reading that earlier today 
May 20 15:06:38 <dyoung-zzzz> Yeah, its neat.
May 20 15:07:18 <[g2]> it made be think about hacks for the NSLU2 and it's brothers and sisters
May 20 15:07:39 <dyoung-zzzz> like a i2c LCD Display?
May 20 15:07:57 <[g2]> funny you should mention that ....
May 20 15:08:02 <jbowler> [g2]: What I don't understand is what you pulled - the PB/LEDs just go through the GPIO bits, it's the RTC which seems to use I2C
May 20 15:08:09 <dyoung-zzzz> I've had that on the brain for a while now.
May 20 15:08:27 <dyoung-zzzz> I identified a i2c register glue part that should have enough bits to make it all work.
May 20 15:09:09 <[g2]> jbowler, I pulled the nslu2-io
May 20 15:09:38 <[g2]> and x1205-rtc.c
May 20 15:09:44 <jbowler> So x1205-rtc.c is still in there?
May 20 15:09:47 <[g2]> and the defconfig changes to match
May 20 15:09:53 <[g2]> no it's now
May 20 15:09:54 <[g2]> no it's not
May 20 15:11:34 <[g2]> jbowler, it's a tiny 50-60 line patchset I can email you the changes if you like
May 20 15:12:00 <jbowler> Isn't it the case that just changing the defconfig line for CONFIG_SENSORS_X1205 will be enough to remove the RTC, and leave the LEDs intact?
May 20 15:12:00 <[g2]> plus a couple lines more the .bb file
May 20 15:13:12 <[g2]> jbowler, possibly.. However, the timers are hooked up by the nslu2-io code.  That allowed for the buzzer iirc. I wanted to remove the timers
May 20 15:14:24 <[g2]> It just so happens that the same code hooks up the power button, its GPIO, the reset button and the LEDs
May 20 15:16:25 <jbowler> Right, nslu2-io is just doing read/write from the GPIO bits.  The GPIO can be pulled by setting I2C_IXP4XX to false.
May 20 15:17:23 <jbowler> The timers are always absent (deleted) unless an LED is flashing or the buzzer is sounding.
May 20 15:19:49 <[g2]> jbowler, If I understand you, you are saying the next test should be just removing the X1205-rtc.c code and adding back the nslu2-io.c code
May 20 15:21:31 <[g2]> rwhitby-treo, welecome
May 20 15:21:35 <jbowler> [g2]: yes, in fact I think just defconfig the X1205 out.  I just looked at the buzzer code, it doesn't use a timer, so no timers were every added?
May 20 15:22:19 <rwhitby-sydney> hey g2
May 20 15:22:32 <rwhitby-sydney> ipkg problem sorted out?
May 20 15:22:33 <[g2]> howdy rwhitby-sydney WB 
May 20 15:22:39 * rwhitby-sydney just landed
May 20 15:22:46 <[g2]> rwhitby-sydney, I think so... 
May 20 15:23:01 <[g2]> there was a e-mail on the ml
May 20 15:23:24 * rwhitby-sydney goes to check gmail with treo ...
May 20 15:23:30 <rwhitby-sydney> back in a bit
May 20 15:24:29 <[g2]> I think rwhitby is a robot or a team of people working together
May 20 15:27:50 <dyoung-zzzz> he is a robot.
May 20 15:27:57 <dyoung-zzzz> it boggles my mind.
May 20 15:28:14 <[g2]> he's not the MAN, he's the MACHINE
May 20 15:28:16 <[g2]> :)
May 20 15:39:00 <jbowler> [g2]: I suspect tm_mon may be negative.
May 20 15:41:36 <jbowler> Yep, struct rtc_time, tm_mon is an 'int', in line 344 of x1205-rtc.c checks it for >11, but not <0, line 347 uses it as an index into a static.  The fault address is no where near any of the register values, the fault is 80 bytes into x1205_validate_tm.
May 20 15:43:26 <jbowler> How about this:
May 20 15:43:28 <jbowler> -       if ((tm->tm_mon > 11) || (tm->tm_mday == 0))
May 20 15:43:28 <jbowler> +       if ((tm->tm_mon > 11) || tm_mon < 0 || (tm->tm_mday == 0))
May 20 15:45:11 <jbowler> Actually, the whole dang function is assuming unsigned values when they are all signed, but never mind...  See how unlikely this is - if x1205_command is passed garbage for the void* tm (uninitialized) it will be fine most of the time because something will be out of range or tm_mon will not be so bad as to cause a crash, but once in a while...
May 20 15:46:29 <jbowler> Should probably be a kernel printf in there too, but I think it's worth trying just the above patch - NAiL and I were seeing consistent crashes over a 24 hour period, so it's not un-reproducible.
May 20 15:48:42 <dyoung-zzzz> jbowler, I dont have exclusive thought/opinion/control over x1205-rtc.c, so if you see the problem, feel free to fix!  if you do a history on the file, you can see I changed one line to modify the behaviour for months (0-11 vs 1-12) but I dont remember the specific change offhand.
May 20 15:49:36 <dyoung-zzzz> (back later)
May 20 15:57:14 <jbowler> [g2]: I'm going to try running NTP with that one line change, though probably not for a few days because I'm playing with the boot sequence (so I don't think I can currently build a bootable system...)
May 20 15:59:01 <rwhitby-treo> I didn't see a specific message on the ML advising people how to recover from the bad ipkg upgrade - did that go out?  I only saw a message about how to make the incorrectly installed on work, not how to roll back to the same as everyone else.
May 20 16:04:03 <rwhitby-treo> hmm - no one around to confirm or deny ...
May 20 16:22:07 <jeanfabrice> I sincerely apologize for the trouble I made putting ipkg in the CROSS_PACKAGES_READY_FOR_TESTING target, not being able to appreciate the impact it could have on unslung
May 20 16:26:01 <[g2]> jeanfabrice, don't sweat it -- it was an accident
May 20 16:27:56 <jeanfabrice> a big one :/
May 20 16:29:11 <[g2]> I sense that you feel really bad. We've got a great community with lots of great users
May 20 16:29:28 <[g2]> it's all thanks to us all working together
May 20 16:30:01 <[g2]> it's a very fast paced community working to make things the best they can be
May 20 16:33:35 <jeanfabrice> yep, and I appreciate that very very much. That's why it makes me feel bad having done such BIG error, as I'm just here for a very short time...
May 20 16:36:01 <jeanfabrice> will have to discuss with jp30 on how to sync on new optwares without updating each other's READY_FOR TESTING
May 20 16:38:06 <jeanfabrice> good night all. sorry again.
May 20 18:34:05 <dyoung-hbd> [g2] around?
May 20 18:37:01 <dyoung-hbd> so I was poking around the Tivo series2 USB posts/lists.
May 20 18:37:47 <dyoung-hbd> "Log2 of default interrupt delay, in microframes. The default value is 0, indicating 1 microframe (125 usec). Maximum value is 6, indicating 2^6 = 64 microframes
May 20 18:38:01 <dyoung-hbd> controls how often the EHCI controller can issue interrupts."
May 20 18:39:25 <dyoung-hbd> And then there is a recommendation of setting log2_irq_thresh=4 to greatly improve the USB2 throughput.
May 20 18:40:56 <ByronT> dyoung-hdb, is poking around thoses lists a wise thing to do?
May 20 18:41:52 <dyoung-hbd> I dunno, is there something inherently wrong with reading stuff?
May 20 18:42:49 <ByronT> it was a rhetorical question (with a small failed attempt at humor).... ;)
May 20 18:47:12 <ka6sox-office> dyoung-hbd : ping
May 20 18:47:26 <dyoung-hbd> hi
May 20 18:47:38 <ka6sox-office> hi there...what does hbd stand for?
May 20 18:47:59 <ka6sox-office> ah! HBD!!!!!
May 20 18:48:19 <ByronT> happy birthday!
May 20 18:48:24 <dyoung-bday> Thanks.
May 20 18:49:30 <ByronT> dyoung-bday, what is the biggest problem with using flash sticks below 256MB - you run out of room, right?
May 20 18:49:44 <dyoung-bday> No, you cant format them.
May 20 18:49:48 <dyoung-bday> using the linksys interfac.e
May 20 18:49:59 <ByronT> ah... that's right
May 20 18:50:07 <dyoung-bday> If you manually format and stuff, you cna probably make it work.
May 20 18:50:16 <dyoung-bday> transplanting .dongle and all that good stuff.
May 20 18:51:12 <kergoth> is everyone here aware of the fact that current OE trees now require current bitbake?
May 20 18:51:42 <ByronT> I believe jbowler made a mailing list announcment - as well as announcing in channel
May 20 18:51:51 <kergoth> good
May 20 18:51:53 <kergoth> just making sure
May 20 19:02:25 <kergoth> i dunno if anyone here is interested in the bitbake work, but anyone that is should read the recent threads at https://lists.berlios.de/pipermail/bitbake-dev/2005-May/thread.html
May 20 19:04:50 <dyoung-bday> thanks for the link, was trying to keep up in #oe, but fell behind.
May 20 19:05:09 <kergoth> np
May 20 19:05:33 <kergoth> actually, you should probably read all the threads in may
May 20 19:05:37 <kergoth> :)
May 20 19:08:40 * kergoth submits btibake-dev to gmane
May 20 19:23:47 <MoonPie2000> has anyone had trouble wtih slug not booting when drives are attached - boots fine wiht none attached? 
May 20 20:12:52 <[g2]> dyoung-bday, hey
**** BEGIN LOGGING AT Fri May 20 21:22:35 2005
May 20 23:22:03 <CIA-1> 03bzhou * 10unslung/ (3 files in 2 dirs): clips cross compiled
**** ENDING LOGGING AT Fri May 20 23:59:56 2005