[00:16] <frop> ping nbd
[00:16] <frop> http://paste.anbcs.com/4631
[00:19] <nbd> which module?
[00:20] <nbd> frop: uhm... why is madwifi included in the image?
[00:20] <frop> nooo
[00:20] <frop> really?
[00:20] <frop> ohh shit
[00:21] <frop> rebuilding
[00:23] <frop> mmmh
[00:23] <frop> i've not cleaned, shit
[03:56] <Bartman007> Kaloz: I just won the auction for those xscale routers
[04:06] <Bartman007> payment sent, since it's being shipped from within my state, it should arrive fairly quickly
[08:49] <[florian]> nbd: have you made some other tests with different gcc versions ?
[09:01] <[florian]> nbd: I think this problem will only appear with bcm6348 where the CPU speed is calculated, and not hardcoded
[09:42] <CIA-17> florian * r4657 / (2 files in 2 dirs): Update quagga to 0.98.6 for -ng, and fix MD5SUM in whiterussian :)
[09:44] <[florian]> no one here ?
[10:36] <nbd> re
[10:37] <nbd> [florian]: no, the cpu speed is calculated correctly
[10:39] <[florian]> nbd: ok, then what may be wrong ?
[10:40] <nbd> i have no idea
[10:40] <[florian]> neither have I
[10:40] <nbd> but if we don't fix this particular problem, we can't continue with the rest
[10:40] <[florian]> precisely
[10:41] <[florian]> and this seems quite hard to solve
[10:41] <[florian]> has not brainslayer noticed this too ?
[10:41] <nbd> yes, he has
[10:42] <[florian]> and I supposed he has not fixed this ?
[10:45] <nbd> no
[10:46] <[mbm]> what's the bogomips showing as?
[10:47] Action: [mbm] guesses something like "3"
[10:47] <[florian]> [mbm]: 4.12 actually for me
[10:48] <[mbm]> heh
[10:48] <[florian]> I really don't understand what is the problem with #694
[10:49] <[mbm]> seen that before, can't remember what the problem was
[10:49] <[mbm]> it's in the irc logs somewhere
[10:49] <[florian]> [mbm]: bogomips or #694 ?
[10:49] <[mbm]> 694
[10:50] <[florian]> ok
[10:50] <[florian]> I really wonder if it is not his windows clients that have the problem
[10:50] <[florian]> dnsmasq has always been working for months for me
[10:53] <[mbm]> tryig to find the logs .. it was joebush complaining of dns issues
[10:55] <[mbm]> look at openwrt.log.20060327 and 28
[10:55] <[florian]> ok
[10:58] <[florian]> actually, I don't want to hurt anybody, but it looks like the previous dnsmasq usage : let the user configure it, was causing less bugs, and opened tickets
[10:59] <[florian]> I personnaly always replace the default behaviour by my own configuration
[11:00] <[florian]> nevermind
[11:03] <[florian]> should not we also produce an ELF image for x86 boards ?
[11:05] <nbd> [mbm]: the same bogomips problem happens on some hardware with gcc 3.4.6 in brcm-2.4
[11:06] <[florian]> nbd: how could it be related to gcc ?
[11:06] <[mbm]> right, I remember that was one of the reasons we didn't use gcc 4.x
[11:06] <[mbm]> [florian]: different versions of gcc produce slightly different assembly output
[11:07] <nbd> i read on a web page somewhere that it may be cache writeback related
[11:07] <[florian]> [mbm]: so this portion of code is really sensitive to gcc ?
[11:09] <[mbm]> [florian]: seems like it
[11:09] <[florian]> by the way, the right word is sensitive and not sensible right ?
[11:09] <nbd> right
[11:10] <[mbm]> sensible means something like "common sense"
[11:10] <[florian]> thanks, I always make the confusion between these two words,
[11:10] <nbd> btw. i've tried gcc 3.4.4, 3.4.6 and 4.1.1
[11:11] <nbd> same problem on all of them
[11:11] <[florian]> what about the provided toolchain ?
[11:12] <nbd> haven't tried that one yet
[11:13] <[florian]> groz: it should fix #676 : http://pastebin.ca/148651 right ?
[11:15] <[mbm]> isn't it just $(KDIR)/bzImage
[11:15] Action: [mbm] looks
[11:16] <[mbm]> hmm guess you're right boot/bzImage
[11:16] <[florian]> I will have a look too, because I am not sure the bzImage it not outputed by the kernel-build template
[11:16] <[florian]> sorry, is outputed
[11:18] <[florian]> [mbm]: ok to commit ? or should I change the template itself ?
[11:18] <nbd> i asked in #mipslinux, let's see if anybody answers
[11:19] <[florian]> nbd: good idea right
[11:19] <[mbm]> nbd: in cases like self modifying code you have to flush the icache .. haven't looked at any of this code though
[11:20] <nbd> [mbm]: it's not self modifying
[11:20] <[mbm]> I know we had to flush the caches to get the lzma bootloader to work
[11:20] <nbd> [mbm]: it simply enables the timer interrupt and starts to loop
[11:20] <nbd> [mbm]: and checks the jiffy counter while doing that
[11:20] <[mbm]> ok, and you're sure the timer is running correctly?
[11:20] <nbd> yes
[11:21] <nbd> i even cleaned it up and made it use the generic code
[11:21] <nbd> and when i changed the timer interrupt stuff, bogomips only changed by 0.05 max.
[11:21] <[mbm]> hmm
[11:22] <nbd> if it's timer interrupt related, then the interrupt would have to be firing way too often
[11:23] <nbd> either that, or the loop is way too slow
[11:24] <[mbm]> I take it the loop is in assembly?
[11:24] <nbd> no
[11:25] <[mbm]> hmm was going to suggest a .set noreorder to keep gcc from messing with it
[11:25] <nbd> and the weird thing is that on bcm47xx with gcc 3.4.6 the same binary works well on some hardware and breaks on others
[11:26] <nbd> and it even breaks on some of the newer processors
[11:26] <[mbm]> hmm
[11:26] <nbd> so it's not related to the old cache bug
[11:27] <[mbm]> well, I can see where if caching wasn't enabled you'd end up with some low numbers
[11:28] <CIA-17> florian * r4658 /branches/buildroot-ng/openwrt/target/image/x86/Makefile: Override kernel template and output bzImage, not the binary file, closes #676 and #714
[11:28] <nbd> yeah
[11:30] <[florian]> nbd: does bcm63xx also use silicon backplane ?
[11:31] <nbd> i don't think so
[11:31] <nbd> it looks like it really is different stuff
[11:31] <[florian]> so nothing generic we could use between 47xx and 63xx :-
[11:46] <[florian]> looks like nobody has a clue in #mipslinux :-
[11:51] <nbd> [mbm]: if i run the bogomips calibrate in an endless loop, it doesn't change significantly over time
[11:54] <[mbm]> nor should it
[11:54] <nbd> yeah
[11:54] <nbd> what i meant was that it isn't something that 'accidentally' happens at this specific point in tome
[11:54] <nbd> time
[12:16] <[mbm]> you might want to check function alignment
[12:17] <[mbm]> although this being a mips everything should have the same instruction length and that should be irrelevent
[12:18] <nbd> right now, i'm building trunk with gcc 3.4.6 to compare the calibrate function with one built by 3.4.4
[12:18] <nbd> (linux 2.4)
[12:19] <[mbm]> ah
[12:19] <nbd> on bcm47xx
[12:19] <nbd> to see what made the difference there
[12:19] Action: [mbm] is having tons of fun chasing down bugs in the nvidia video drivers
[12:20] <nbd> the binary ones?
[12:20] <[mbm]> running Xv at 1920x1080i locks the video card
[12:21] <[mbm]> (glx works fine at that res though)
[12:45] <nbd> [mbm]: no differences in the calibrate function between 3.4.4 and 3.4.6
[12:53] <Kaloz> err
[12:53] <Kaloz> afaik that wasn't gcc dependent
[12:53] <Kaloz> it was binutils dependent
[12:53] <nbd> it was gcc dependent
[13:03] <[florian]> nbd: if the code produced are the same, what could be the problem ?
[13:05] <nbd> no idea
[13:06] <[florian]> humm, it is not really cool :(
[13:07] <nbd> [florian]: see #mipslinux
[13:12] <CIA-17> florian * r4659 /packages/net/pptpd/Makefile: Clean up pptpd makefile and add support for broadcast relay option, closes #724
[14:14] <CIA-17> florian * r4660 /packages/net/pptpd/Makefile: Remove empty lines, definitively closes #724
[14:16] <CIA-17> florian * r4661 /packages/net/pptpd/Makefile: Remove executable bit from the Makefile, also definitively closes #724
[14:38] <nbd> [mbm]: about the bogomips stuff: the timer interrupt is definitely working correctly, i just did an experiment to verify that
[15:01] <CIA-17> florian * r4662 /packages/net/samba/ (10 files in 4 dirs): Port samba to -ng, add enhanced attributes patch, closes #674
[15:04] <CIA-17> florian * r4663 /packages/net/vpnc/Makefile: Add missing kmod-tun dependency
[15:16] <nbd> [florian]: i'll commit my initial cleanup in a minute
[15:18] <[florian]> nbd: no pb, I will have a test on the livebox tonight
[15:18] <[florian]> nbd: do it go farther with uncached ?
[15:19] <nbd> it still dies on flash init
[15:19] <[florian]> nbd: yes, that's normal because you have CFE
[15:20] <[florian]> do you want me to post the inventel physmap code that is supposed to manage both bootloaders ? so that you could have a try at it ?
[15:20] <nbd> yeah
[15:22] <[florian]> http://f.fainelli.free.fr/physmap.c
[15:24] <CIA-17> florian * r4665 /packages/net/vtun/ (. Config.in Config.in Makefile Makefile ipkg/): Port vtun to -ng
[15:24] <nbd> btw. it's crashing in cfi_probe
[15:24] <nbd> uh, cfi_probe_chip
[15:24] <[florian]> I had this when we did not supply a valid flash map address
[15:25] <nbd> you mean for the flash memory mapping?
[15:25] <[florian]> from what I could see in the patches, there are special and weird initializations to be done when it's CFE
[15:25] <[florian]> nbd: yes
[15:26] <nbd> well, i eliminated all the broadcom flash access code
[15:26] <nbd> i removed it from the source tree completely
[15:26] <[florian]> ok
[15:26] <[florian]> I also don't think it is mandatory
[15:27] <[florian]> but you may have to tune a bit the flash map driver to act differently for CFE
[15:30] <[florian]> nbd: do you agree if I split webif languages into distinct packages ?
[15:31] <CIA-17> florian * r4666 /packages/net/wrt-radauth/ (. Config.in Makefile Makefile ipkg/): Port wrt-radauth to -ng
[15:35] <CIA-17> florian * r4667 /packages/net/wknock/ (. Config.in Makefile ipkg/): Port wknock to -ng
[15:40] <nbd> [florian]: why?
[15:41] <malbon> [florian]: I'm going to add hostap modules to au1000 to make the build work, ok?
[15:42] <nbd> interesting how the linkspammers are trying to hide
[15:51] <nbd> [florian]: i'll try a build with initramfs and without mtd now
[15:51] <nbd> reduced the size of the system code patch to 350k
[15:51] <malbon> nbd: what CFE device are you using? dg834gt?
[15:52] <[florian]> nbd: hu, well done !
[15:52] <nbd> malbon: it's a 3com board, don't know which one
[15:52] <malbon> ah ok.
[15:53] <nbd> [florian]: redboot based stuff is not using any of the nvram crap, right?
[15:53] <nbd> [florian]: because i ripped it all out
[15:53] <malbon> no redboot doesn't. ;)
[15:55] <[florian]> nbd: cfe might
[15:55] <malbon> nbd: in the last block you have two sections, the flash directory and the fconfig area. The fconfig area is where you define your addresses for the nics, serial speed etc.
[15:56] <[florian]> malbon: I may need your help for the redboot user-space configurator, can we discuss tonight if you are online ?
[15:57] <malbon> [florian]: I'm not sure if I'll be online, but sure, I'd like to have a useful tool for that.
[15:57] <[florian]> ok, thanks :)
[16:02] <CIA-17> nbd * r4668 /branches/buildroot-ng/openwrt/target/linux/brcm63xx-2.6/ (config patches/001-bcm963xx.patch): more cleanups
[16:02] <nbd> [florian]: without mtd it's booting me into user space
[16:03] <nbd> [florian]: serial is also working properly (i merged some stuff from brianslayer, but not without cleaning it up a lot)
[16:20] <[florian]> ok, thanks nbd !
[16:20] <[florian]> nbd: with networking enabled and so on ?
[16:21] <[florian]> nbd: can you try loading binary drivers :p ?
[16:21] <nbd> haven't tried networking yet
[16:21] <[florian]> ok, but it is enabled in the kernel config ?
[16:22] <[florian]> it seems so
[16:27] <frop> http://paste.anbcs.com/4632
[16:28] <frop> what's VLYNQ?
[16:29] <frop> VLYNQ is a serial communications interface
[16:33] <nbd> [florian]: hmm... i get BCM63xx_ENET board id not set
[16:44] <[florian]> nbd: what do you mean ?
[16:44] <[florian]> ah while loading the bcm_enet driver ?
[16:45] <nbd> yes
[16:45] <nbd> maybe i picked one that needs nvram
[16:45] <[florian]> nbd: try bcm_usb maybe
[16:46] <nbd> do you have a binary from inventel?/
[16:46] <[florian]> inventel is 2.4
[16:46] <nbd> oh
[16:46] <nbd> crap
[16:47] <nbd> is there any redboot based device with a 2.6 tree?
[16:47] <[florian]> not any I know
[16:47] <nbd> or maybe i can emulate this nvram shit
[16:47] <nbd> it doesn't seem to be calling the nvram functions directly
[16:47] <nbd> otherwise i'd have gotten an unresolved symbol error
[16:47] <[florian]> I will be home in 1h30 approx, so that I can test
[16:47] <[florian]> that's right
[16:48] <[florian]> maybe it just wants to have something defined in the kernel config
[16:50] <[florian]> what about dsl sutff ?
[16:51] <nbd> no idea
[16:51] <nbd> let's get ethernet up and running first
[16:51] <[florian]> that's right
[16:51] <nbd> ah, the board_params stuff needs to be initialized
[16:52] <nbd> somebody really needs to punish linksys for their built-in.o crap
[16:53] <nbd> ah, i figured out what's wrong
[16:53] <nbd> i need to call BpSetBoardId
[16:53] <[florian]> ah ah
[16:54] <nbd> i'll hardcode it first for testing
[16:54] <nbd> later we need to add detection
[16:54] <[florian]> nbd: what about other 63xx boards ? there seems to be a lot of board specific includes in the kernel
[16:56] <nbd> most of the stuff doesn't look so hard
[16:56] <nbd> i think we can fix it to get proper run time detection
[16:56] <[florian]> ok
[16:57] <nbd> null pointer dereference
[16:58] <nbd> now the 'fun' of tracing down abi incompatibilities begins
[16:59] <BrainSlayer2> nice to see that slowly somthing happends with the brcm63xx problem
[17:01] <[florian]> have to go, see you later :)
[17:01] <BrainSlayer2> cu
[17:05] <nbd> BrainSlayer2: you were experiencing the same oops with a config change in 2.6.8.1, right?
[17:05] <nbd> or at least a very similar one
[17:53] <BrainSlayer2> yes
[17:53] <BrainSlayer2> ping will result in a kernel oops
[17:54] <BrainSlayer2> so far i activate some additional features like bridge filtering or imq
[18:03] <nbd> [florian]: making that ethernet driver compatible is a piece of work, but i think i can do it
[18:09] <[florian]> re
[18:10] <[florian]> nbd: you mean it is quite hard to make it work right ?
[18:10] <nbd> yeah
[18:10] <[florian]> ah, not cool
[18:11] <[florian]> what about trying to make bcm43xx work on it, and use it in sta as a replacement to debug ethernet ?
[18:12] <BrainSlayer2> nbd's bcm63xx unit has a atheros card on board
[18:12] <[florian]> ah
[18:12] <[florian]> mine is a bcm4306
[18:12] <[florian]> I also have to see if we can the VoIP chipset sepcs
[18:12] <[florian]> specs
[18:13] <[florian]> BrainSlayer2: which bcm63xx unit do you have ?
[18:17] <[florian]> BrainSlayer2: dead ?
[18:32] <nbd> i hate binary modules ... :)
[18:33] <h3sp4wn> nbd: Does that mean you are working on rewriting ath_hal ?
[18:33] <nbd> no
[18:34] <[florian]> h3sp4wn: there is ath-driver for that
[18:34] <h3sp4wn> That is a binary module though ?
[18:34] <Bartman007> h3sp4wn: there are many binary modules
[18:34] <[florian]> we are talking about the bcm63xx ethernet driver
[18:35] <h3sp4wn> ah (It just seemed to me as if he had undertaken a personal crusade to rid openwrt of all binary modules - forget it)
[18:35] <[florian]> well, ideally, we would :)
[18:35] <nbd> unfortunately i don't have the resources for something like that
[18:36] <[florian]> it's one of the most painful thing of the world :)
[18:36] <Bartman007> h3sp4wn: he'd start on broadcom's wlan drivers first :-P
[18:37] <[florian]> some people already did that ;)
[18:39] <Bartman007> sshhh.
[18:41] <[florian]> he he
[18:53] <[mbm]> did anyone look into the devfs bug yet?
[18:57] <nbd> not yet
[18:58] <[mbm]> hmm looks like I'll be doing that later today :/
[19:03] <[mbm]> and there's the main source of the problem, include/linux/devfs_fs_kernel.h is almost completely wiped out
[19:16] <[florian]> nbd: did you change something in the flash map driver ? I can't boot on the flash now :(
[19:17] <[florian]> maybe I should try ramdisk to begin
[19:19] <nbd> [florian]: what happens when you try to boot?
[19:21] <[florian]> here it is : http://pastebin.ca/149239
[19:21] <nbd> that's the same one that i get
[19:22] <nbd> maybe it'll work when i fix up the flash stuff for my board
[19:22] <nbd> it's probably broken because i ripped out that stupid broadcom flash code
[19:22] <nbd> i didn't change the flash map itsef
[19:23] <[florian]> nbd: I don't remember seeing that redboot calls broadcom flash code actually
[19:23] <[florian]> let me resentence
[19:23] <[florian]> I don't remember seeing that once the bootloader is detected as redboot it should use any of the broadcom code
[19:23] <nbd> hmm
[19:24] <nbd> need to look into that flash map driver again
[19:24] <[florian]> probably
[19:24] <nbd> but i want to get ethernet up and running now
[19:25] <[florian]> sure, I see that you have disabled the bcm963xx flash map in the kernel config ?
[19:25] <[florian]> and you use physmap instead ?
[19:26] <nbd> i haven't changed the mtd stuff
[19:28] <[florian]> ok
[19:28] <nbd> made some progress with the driver:
[19:28] <nbd> Broadcom BCM6348A2 Ethernet Network Device v0.3 Aug 9 2006 22:40:44
[19:28] <nbd> Config Ethernet Switch Through SPI Slave Select 1
[19:28] <nbd> eth0: MAC Address: 00:07:3A:FF:FF:FF
[19:29] <[florian]> well done
[19:29] <nbd> then it locks up
[19:29] <[florian]> :(
[19:29] <frop> ...my pppoe still doens't work...with recent revision
[19:35] <[florian]> nbd: new crashes on this redboot device : http://pastebin.ca/149262
[19:39] <[mbm]> ah.
[19:40] <[mbm]> b/drivers/scsi/scsi_scan.c:
[19:40] <[mbm]> - sprintf(sdev->devfs_name, "scsi/host%d/bus%d/target%d/lun%d",
[19:40] <[mbm]> ...
[19:40] <[florian]> I think we are going to have a lot of headaches with this device ;)
[19:40] <[mbm]> there's a problem
[19:41] <[mbm]> annoying thing is that devfs_name got removed in several places
[20:04] <[mbm]> *mumble* tedious work going throught he whole damned patch-2.6.17 looking for where gregkh nuked devfs support
[20:05] <nbd> can't you take gregkh's patches and reverse them?
[20:05] <[mbm]> he didn't post em
[20:05] <[mbm]> http://www.kernel.org/pub/linux/kernel/people/gregkh/devfs/2.6/2.6.17 seems to be post-2.6.17
[20:06] <nbd> hmm
[20:06] <[mbm]> so now I'm trimming patch-2.6.17 into a nice devfs reverse patch
[20:14] <[florian]> nbd: I don't manage to get the assoclist, where I could get any of the other ioctl's : revinfo (uses structure), phytype
[20:15] <nbd> what's the problem with the assoclist?
[20:15] <[florian]> I have tried using the wl_assoc_mac structure documented in utils.h, and I don't see anything
[20:16] <[florian]> I also tried with a 8192 long buffer, nothing
[20:16] <[florian]> now I have just tried with a pointer to a wl_assoc_mac structure, nothing
[20:16] <[florian]> so I think it returns something that may not be documented actually
[20:17] <nbd> did you use memset on the buffer before sending it to the driver?
[20:17] <[florian]> no, I use a statically allocated buffer
[20:17] <nbd> use memset
[20:17] <[florian]> ah, you are right, I may need to use memset
[20:20] <[florian]> nbd: same effect, nothing :(
[20:20] <[florian]> I wonder if it does not return a list of mac address
[20:23] <nbd> [florian]: save the buffer to a file and view it with hexdump
[20:23] <[florian]> yup
[20:23] <CIA-17> mbm * r4669 /branches/buildroot-ng/openwrt/target/linux/generic-2.6/patches/000-reenable_devfs.patch: update devfs patches
[20:23] <[mbm]> :)
[20:24] <[mbm]> groz: that should fix your devfs_mk_dir errors
[20:24] Action: [mbm] hasn't yet confirmed
[20:24] <groz> it'll be a couple hours till i can try
[20:25] Action: groz just getting started on the day here, still working on wakeup coffee and catching up on phone calls
[20:25] <[mbm]> nod.
[20:29] <CIA-17> mbm * r4670 /branches/buildroot-ng/openwrt/target/linux/aruba-2.6/config: update config
[20:31] <[florian]> nbd: does not change anything, buffer still empty
[20:32] <[florian]> nbd: could wl compat debug, and wl assoclist help find out the type of data passed to the buffer ?
[20:33] <nbd> yes
[20:34] <[florian]> here is what I get : http://pastebin.ca/149309
[20:35] <[florian]> the first byte indicates the number of associated macs
[20:35] <[florian]> and then the associated macs
[20:36] <[florian]> ok, I found the structure :)
[20:36] <nbd> ok, when preparing the buffer, give it 0x545 in the first dword
[20:36] <nbd> :)
[20:38] <[florian]> why ?
[20:38] <[florian]> because you see it, yes :)
[20:38] <nbd> i think that's the maximum number of entries or something like that
[20:38] <[florian]> probably
[21:02] Action: Bartman007 wonders why #openwrt has turned into a flamewar
[21:05] <[florian]> probably because J4k3 is there ;)
[21:26] <[florian]> nbd: to set up the buffer, memset(buffer, 0x545, 2) should do the trick right ?
[21:31] <nbd> [florian]: don't use memset for writing in that byte
[21:31] <nbd> [florian]: first use memset to clear the whole buffer
[21:32] <nbd> [florian]: then you can cast the buffer pointer to an u32 pointer, dereference it and throw in the value
[21:37] <[florian]> ok
[22:17] <CIA-17> malbon * r4671 /branches/buildroot-ng/openwrt/target/linux/au1000-2.6/config: Make the build work properly by including Hostap modules.
[22:27] <[florian]> malbon: thanks !
[22:27] <[florian]> by the way malbon do you have any au1000 device ?
[22:45] <[mbm]> yay! /dev/scsi/host0/bus0/target0/lun0/part1 ;)
[22:46] <crazy_imp> cdromsupport now?
[22:47] <[mbm]> no, just working usb drive support (again)
[22:47] <[mbm]> groz: patch worked
[22:49] <groz> great thanks, i haven't had a chance to grab and build it yet
[22:49] Action: groz dealking with fires at a client site today
[22:49] <groz> literally dealing with fires
[22:49] <[mbm]> I had to have working usb support for one of my projects
[22:50] <groz> i guess a sprinkler system went off last nite
[22:50] <groz> and a few puters got wet
[22:50] <[mbm]> last known working usb was 2.6.16.7 .. had to dig through the patch-2.6.17 by hand and revert the usb changes
[22:50] <[mbm]> seems happy now
[22:50] <groz> well, i was looking at some of those on that page of greg's patches the other day
[22:51] <groz> and i didn't find anything that seemed to actually be source of the problem
[22:51] <[mbm]> those are the fun we have to look for post 2.6.17
[22:51] <[mbm]> turns out greg had quietly removed devfs_name from several key drivers
[22:51] <groz> there will reach a point, where we ask what the benefit of pissing upwind is :)
[22:51] <[mbm]> which means that everything ended up as <NULL>/part1
[22:52] <[mbm]> and devfs_mk_dir puked at the fact the string was apparnetly null
[22:52] <groz> but, i'd like to take somebody quietly out back over that whole issue
[22:52] Action: groz has a 12 guage needs some exercise
[22:52] <[mbm]> :)
[22:53] <groz> scattergun is an awful slow and painful way to go
[22:54] <[mbm]> http://pastebin.ca/149447 .. might be useful to someone
[22:55] <[mbm]> it mostly shows how you cna automatically figure out the name of any inserted usb disk
[22:59] <dragorn> thats handy
[22:59] <dragorn> considering i have to figure out just that soon :)
[22:59] <dragorn> My friend wants to have a system w/ a multicard usb reader at his wedding where people can plug in a disk and it'll copy all the files off automatically.
[23:07] <groz> I'd say the auto copy off a multi card is a dumb idea, but, it's nowhere near as dumb as the idea of having a wedding
[23:07] <groz> :)
[23:09] <dragorn> why is it a dumb idea?
[23:09] <dragorn> it's to let everyone w/ digicams contribute to his wedding album
[23:09] <dragorn> not like it's a security system (or even networked)
[23:09] <groz> cuz i've been there, and done that, and a wedding is the dumbest thing you can ever do
[23:10] <groz> the fastest way to turn a good friend into a very expensive mortal enemy
[23:20] <malbon> [florian]: Nope. I don't have any au1000 devices. :)
[23:38] <frop> ehi, there's a way to set the "macdsl" for tiatm instead of 00:00:02:03:04:05?
[23:39] <frop> cause "insmod tiatm"
[23:39] <frop> meka this
[23:39] <frop> Itf Type ESI/"MAC"addr AAL(TX,err,RX,err,drop) ... [refcnt]
[23:39] <frop> 0 avsar 000002030405 0 ( 0 0 0 0 0 ) 5 ( 0 0 0 0 0 ) [1]
[23:39] <frop> also, changing nas0 mac, doesn't change value in /proc/net/atm/devices
[23:53] <CIA-17> kaloz * r4672 /branches/buildroot-ng/openwrt/ (21 files in 12 dirs): add basic support for the Magicbox boards
[00:00] --- Sat Aug 26 2006
[00:16] <frop> http://paste.anbcs.com/4631
[00:19] <nbd> which module?
[00:20] <nbd> frop: uhm... why is madwifi included in the image?
[00:20] <frop> nooo
[00:20] <frop> really?
[00:20] <frop> ohh shit
[00:21] <frop> rebuilding
[00:23] <frop> mmmh
[00:23] <frop> i've not cleaned, shit
[03:56] <Bartman007> Kaloz: I just won the auction for those xscale routers
[04:06] <Bartman007> payment sent, since it's being shipped from within my state, it should arrive fairly quickly
[08:49] <[florian]> nbd: have you made some other tests with different gcc versions ?
[09:01] <[florian]> nbd: I think this problem will only appear with bcm6348 where the CPU speed is calculated, and not hardcoded
[09:42] <CIA-17> florian * r4657 / (2 files in 2 dirs): Update quagga to 0.98.6 for -ng, and fix MD5SUM in whiterussian :)
[09:44] <[florian]> no one here ?
[10:36] <nbd> re
[10:37] <nbd> [florian]: no, the cpu speed is calculated correctly
[10:39] <[florian]> nbd: ok, then what may be wrong ?
[10:40] <nbd> i have no idea
[10:40] <[florian]> neither have I
[10:40] <nbd> but if we don't fix this particular problem, we can't continue with the rest
[10:40] <[florian]> precisely
[10:41] <[florian]> and this seems quite hard to solve
[10:41] <[florian]> has not brainslayer noticed this too ?
[10:41] <nbd> yes, he has
[10:42] <[florian]> and I supposed he has not fixed this ?
[10:45] <nbd> no
[10:46] <[mbm]> what's the bogomips showing as?
[10:47] Action: [mbm] guesses something like "3"
[10:47] <[florian]> [mbm]: 4.12 actually for me
[10:48] <[mbm]> heh
[10:48] <[florian]> I really don't understand what is the problem with #694
[10:49] <[mbm]> seen that before, can't remember what the problem was
[10:49] <[mbm]> it's in the irc logs somewhere
[10:49] <[florian]> [mbm]: bogomips or #694 ?
[10:49] <[mbm]> 694
[10:50] <[florian]> ok
[10:50] <[florian]> I really wonder if it is not his windows clients that have the problem
[10:50] <[florian]> dnsmasq has always been working for months for me
[10:53] <[mbm]> tryig to find the logs .. it was joebush complaining of dns issues
[10:55] <[mbm]> look at openwrt.log.20060327 and 28
[10:55] <[florian]> ok
[10:58] <[florian]> actually, I don't want to hurt anybody, but it looks like the previous dnsmasq usage : let the user configure it, was causing less bugs, and opened tickets
[10:59] <[florian]> I personnaly always replace the default behaviour by my own configuration
[11:00] <[florian]> nevermind
[11:03] <[florian]> should not we also produce an ELF image for x86 boards ?
[11:05] <nbd> [mbm]: the same bogomips problem happens on some hardware with gcc 3.4.6 in brcm-2.4
[11:06] <[florian]> nbd: how could it be related to gcc ?
[11:06] <[mbm]> right, I remember that was one of the reasons we didn't use gcc 4.x
[11:06] <[mbm]> [florian]: different versions of gcc produce slightly different assembly output
[11:07] <nbd> i read on a web page somewhere that it may be cache writeback related
[11:07] <[florian]> [mbm]: so this portion of code is really sensitive to gcc ?
[11:09] <[mbm]> [florian]: seems like it
[11:09] <[florian]> by the way, the right word is sensitive and not sensible right ?
[11:09] <nbd> right
[11:10] <[mbm]> sensible means something like "common sense"
[11:10] <[florian]> thanks, I always make the confusion between these two words,
[11:10] <nbd> btw. i've tried gcc 3.4.4, 3.4.6 and 4.1.1
[11:11] <nbd> same problem on all of them
[11:11] <[florian]> what about the provided toolchain ?
[11:12] <nbd> haven't tried that one yet
[11:13] <[florian]> groz: it should fix #676 : http://pastebin.ca/148651 right ?
[11:15] <[mbm]> isn't it just $(KDIR)/bzImage
[11:15] Action: [mbm] looks
[11:16] <[mbm]> hmm guess you're right boot/bzImage
[11:16] <[florian]> I will have a look too, because I am not sure the bzImage it not outputed by the kernel-build template
[11:16] <[florian]> sorry, is outputed
[11:18] <[florian]> [mbm]: ok to commit ? or should I change the template itself ?
[11:18] <nbd> i asked in #mipslinux, let's see if anybody answers
[11:19] <[florian]> nbd: good idea right
[11:19] <[mbm]> nbd: in cases like self modifying code you have to flush the icache .. haven't looked at any of this code though
[11:20] <nbd> [mbm]: it's not self modifying
[11:20] <[mbm]> I know we had to flush the caches to get the lzma bootloader to work
[11:20] <nbd> [mbm]: it simply enables the timer interrupt and starts to loop
[11:20] <nbd> [mbm]: and checks the jiffy counter while doing that
[11:20] <[mbm]> ok, and you're sure the timer is running correctly?
[11:20] <nbd> yes
[11:21] <nbd> i even cleaned it up and made it use the generic code
[11:21] <nbd> and when i changed the timer interrupt stuff, bogomips only changed by 0.05 max.
[11:21] <[mbm]> hmm
[11:22] <nbd> if it's timer interrupt related, then the interrupt would have to be firing way too often
[11:23] <nbd> either that, or the loop is way too slow
[11:24] <[mbm]> I take it the loop is in assembly?
[11:24] <nbd> no
[11:25] <[mbm]> hmm was going to suggest a .set noreorder to keep gcc from messing with it
[11:25] <nbd> and the weird thing is that on bcm47xx with gcc 3.4.6 the same binary works well on some hardware and breaks on others
[11:26] <nbd> and it even breaks on some of the newer processors
[11:26] <[mbm]> hmm
[11:26] <nbd> so it's not related to the old cache bug
[11:27] <[mbm]> well, I can see where if caching wasn't enabled you'd end up with some low numbers
[11:28] <CIA-17> florian * r4658 /branches/buildroot-ng/openwrt/target/image/x86/Makefile: Override kernel template and output bzImage, not the binary file, closes #676 and #714
[11:28] <nbd> yeah
[11:30] <[florian]> nbd: does bcm63xx also use silicon backplane ?
[11:31] <nbd> i don't think so
[11:31] <nbd> it looks like it really is different stuff
[11:31] <[florian]> so nothing generic we could use between 47xx and 63xx :-
[11:46] <[florian]> looks like nobody has a clue in #mipslinux :-
[11:51] <nbd> [mbm]: if i run the bogomips calibrate in an endless loop, it doesn't change significantly over time
[11:54] <[mbm]> nor should it
[11:54] <nbd> yeah
[11:54] <nbd> what i meant was that it isn't something that 'accidentally' happens at this specific point in tome
[11:54] <nbd> time
[12:16] <[mbm]> you might want to check function alignment
[12:17] <[mbm]> although this being a mips everything should have the same instruction length and that should be irrelevent
[12:18] <nbd> right now, i'm building trunk with gcc 3.4.6 to compare the calibrate function with one built by 3.4.4
[12:18] <nbd> (linux 2.4)
[12:19] <[mbm]> ah
[12:19] <nbd> on bcm47xx
[12:19] <nbd> to see what made the difference there
[12:19] Action: [mbm] is having tons of fun chasing down bugs in the nvidia video drivers
[12:20] <nbd> the binary ones?
[12:20] <[mbm]> running Xv at 1920x1080i locks the video card
[12:21] <[mbm]> (glx works fine at that res though)
[12:45] <nbd> [mbm]: no differences in the calibrate function between 3.4.4 and 3.4.6
[12:53] <Kaloz> err
[12:53] <Kaloz> afaik that wasn't gcc dependent
[12:53] <Kaloz> it was binutils dependent
[12:53] <nbd> it was gcc dependent
[13:03] <[florian]> nbd: if the code produced are the same, what could be the problem ?
[13:05] <nbd> no idea
[13:06] <[florian]> humm, it is not really cool :(
[13:07] <nbd> [florian]: see #mipslinux
[13:12] <CIA-17> florian * r4659 /packages/net/pptpd/Makefile: Clean up pptpd makefile and add support for broadcast relay option, closes #724
[14:14] <CIA-17> florian * r4660 /packages/net/pptpd/Makefile: Remove empty lines, definitively closes #724
[14:16] <CIA-17> florian * r4661 /packages/net/pptpd/Makefile: Remove executable bit from the Makefile, also definitively closes #724
[14:38] <nbd> [mbm]: about the bogomips stuff: the timer interrupt is definitely working correctly, i just did an experiment to verify that
[15:01] <CIA-17> florian * r4662 /packages/net/samba/ (10 files in 4 dirs): Port samba to -ng, add enhanced attributes patch, closes #674
[15:04] <CIA-17> florian * r4663 /packages/net/vpnc/Makefile: Add missing kmod-tun dependency
[15:16] <nbd> [florian]: i'll commit my initial cleanup in a minute
[15:18] <[florian]> nbd: no pb, I will have a test on the livebox tonight
[15:18] <[florian]> nbd: do it go farther with uncached ?
[15:19] <nbd> it still dies on flash init
[15:19] <[florian]> nbd: yes, that's normal because you have CFE
[15:20] <[florian]> do you want me to post the inventel physmap code that is supposed to manage both bootloaders ? so that you could have a try at it ?
[15:20] <nbd> yeah
[15:22] <[florian]> http://f.fainelli.free.fr/physmap.c
[15:24] <CIA-17> florian * r4665 /packages/net/vtun/ (. Config.in Config.in Makefile Makefile ipkg/): Port vtun to -ng
[15:24] <nbd> btw. it's crashing in cfi_probe
[15:24] <nbd> uh, cfi_probe_chip
[15:24] <[florian]> I had this when we did not supply a valid flash map address
[15:25] <nbd> you mean for the flash memory mapping?
[15:25] <[florian]> from what I could see in the patches, there are special and weird initializations to be done when it's CFE
[15:25] <[florian]> nbd: yes
[15:26] <nbd> well, i eliminated all the broadcom flash access code
[15:26] <nbd> i removed it from the source tree completely
[15:26] <[florian]> ok
[15:26] <[florian]> I also don't think it is mandatory
[15:27] <[florian]> but you may have to tune a bit the flash map driver to act differently for CFE
[15:30] <[florian]> nbd: do you agree if I split webif languages into distinct packages ?
[15:31] <CIA-17> florian * r4666 /packages/net/wrt-radauth/ (. Config.in Makefile Makefile ipkg/): Port wrt-radauth to -ng
[15:35] <CIA-17> florian * r4667 /packages/net/wknock/ (. Config.in Makefile ipkg/): Port wknock to -ng
[15:40] <nbd> [florian]: why?
[15:41] <malbon> [florian]: I'm going to add hostap modules to au1000 to make the build work, ok?
[15:42] <nbd> interesting how the linkspammers are trying to hide
[15:51] <nbd> [florian]: i'll try a build with initramfs and without mtd now
[15:51] <nbd> reduced the size of the system code patch to 350k
[15:51] <malbon> nbd: what CFE device are you using? dg834gt?
[15:52] <[florian]> nbd: hu, well done !
[15:52] <nbd> malbon: it's a 3com board, don't know which one
[15:52] <malbon> ah ok.
[15:53] <nbd> [florian]: redboot based stuff is not using any of the nvram crap, right?
[15:53] <nbd> [florian]: because i ripped it all out
[15:53] <malbon> no redboot doesn't. ;)
[15:55] <[florian]> nbd: cfe might
[15:55] <malbon> nbd: in the last block you have two sections, the flash directory and the fconfig area. The fconfig area is where you define your addresses for the nics, serial speed etc.
[15:56] <[florian]> malbon: I may need your help for the redboot user-space configurator, can we discuss tonight if you are online ?
[15:57] <malbon> [florian]: I'm not sure if I'll be online, but sure, I'd like to have a useful tool for that.
[15:57] <[florian]> ok, thanks :)
[16:02] <CIA-17> nbd * r4668 /branches/buildroot-ng/openwrt/target/linux/brcm63xx-2.6/ (config patches/001-bcm963xx.patch): more cleanups
[16:02] <nbd> [florian]: without mtd it's booting me into user space
[16:03] <nbd> [florian]: serial is also working properly (i merged some stuff from brianslayer, but not without cleaning it up a lot)
[16:20] <[florian]> ok, thanks nbd !
[16:20] <[florian]> nbd: with networking enabled and so on ?
[16:21] <[florian]> nbd: can you try loading binary drivers :p ?
[16:21] <nbd> haven't tried networking yet
[16:21] <[florian]> ok, but it is enabled in the kernel config ?
[16:22] <[florian]> it seems so
[16:27] <frop> http://paste.anbcs.com/4632
[16:28] <frop> what's VLYNQ?
[16:29] <frop> VLYNQ is a serial communications interface
[16:33] <nbd> [florian]: hmm... i get BCM63xx_ENET board id not set
[16:44] <[florian]> nbd: what do you mean ?
[16:44] <[florian]> ah while loading the bcm_enet driver ?
[16:45] <nbd> yes
[16:45] <nbd> maybe i picked one that needs nvram
[16:45] <[florian]> nbd: try bcm_usb maybe
[16:46] <nbd> do you have a binary from inventel?/
[16:46] <[florian]> inventel is 2.4
[16:46] <nbd> oh
[16:46] <nbd> crap
[16:47] <nbd> is there any redboot based device with a 2.6 tree?
[16:47] <[florian]> not any I know
[16:47] <nbd> or maybe i can emulate this nvram shit
[16:47] <nbd> it doesn't seem to be calling the nvram functions directly
[16:47] <nbd> otherwise i'd have gotten an unresolved symbol error
[16:47] <[florian]> I will be home in 1h30 approx, so that I can test
[16:47] <[florian]> that's right
[16:48] <[florian]> maybe it just wants to have something defined in the kernel config
[16:50] <[florian]> what about dsl sutff ?
[16:51] <nbd> no idea
[16:51] <nbd> let's get ethernet up and running first
[16:51] <[florian]> that's right
[16:51] <nbd> ah, the board_params stuff needs to be initialized
[16:52] <nbd> somebody really needs to punish linksys for their built-in.o crap
[16:53] <nbd> ah, i figured out what's wrong
[16:53] <nbd> i need to call BpSetBoardId
[16:53] <[florian]> ah ah
[16:54] <nbd> i'll hardcode it first for testing
[16:54] <nbd> later we need to add detection
[16:54] <[florian]> nbd: what about other 63xx boards ? there seems to be a lot of board specific includes in the kernel
[16:56] <nbd> most of the stuff doesn't look so hard
[16:56] <nbd> i think we can fix it to get proper run time detection
[16:56] <[florian]> ok
[16:57] <nbd> null pointer dereference
[16:58] <nbd> now the 'fun' of tracing down abi incompatibilities begins
[16:59] <BrainSlayer2> nice to see that slowly somthing happends with the brcm63xx problem
[17:01] <[florian]> have to go, see you later :)
[17:01] <BrainSlayer2> cu
[17:05] <nbd> BrainSlayer2: you were experiencing the same oops with a config change in 2.6.8.1, right?
[17:05] <nbd> or at least a very similar one
[17:53] <BrainSlayer2> yes
[17:53] <BrainSlayer2> ping will result in a kernel oops
[17:54] <BrainSlayer2> so far i activate some additional features like bridge filtering or imq
[18:03] <nbd> [florian]: making that ethernet driver compatible is a piece of work, but i think i can do it
[18:09] <[florian]> re
[18:10] <[florian]> nbd: you mean it is quite hard to make it work right ?
[18:10] <nbd> yeah
[18:10] <[florian]> ah, not cool
[18:11] <[florian]> what about trying to make bcm43xx work on it, and use it in sta as a replacement to debug ethernet ?
[18:12] <BrainSlayer2> nbd's bcm63xx unit has a atheros card on board
[18:12] <[florian]> ah
[18:12] <[florian]> mine is a bcm4306
[18:12] <[florian]> I also have to see if we can the VoIP chipset sepcs
[18:12] <[florian]> specs
[18:13] <[florian]> BrainSlayer2: which bcm63xx unit do you have ?
[18:17] <[florian]> BrainSlayer2: dead ?
[18:32] <nbd> i hate binary modules ... :)
[18:33] <h3sp4wn> nbd: Does that mean you are working on rewriting ath_hal ?
[18:33] <nbd> no
[18:34] <[florian]> h3sp4wn: there is ath-driver for that
[18:34] <h3sp4wn> That is a binary module though ?
[18:34] <Bartman007> h3sp4wn: there are many binary modules
[18:34] <[florian]> we are talking about the bcm63xx ethernet driver
[18:35] <h3sp4wn> ah (It just seemed to me as if he had undertaken a personal crusade to rid openwrt of all binary modules - forget it)
[18:35] <[florian]> well, ideally, we would :)
[18:35] <nbd> unfortunately i don't have the resources for something like that
[18:36] <[florian]> it's one of the most painful thing of the world :)
[18:36] <Bartman007> h3sp4wn: he'd start on broadcom's wlan drivers first :-P
[18:37] <[florian]> some people already did that ;)
[18:39] <Bartman007> sshhh.
[18:41] <[florian]> he he
[18:53] <[mbm]> did anyone look into the devfs bug yet?
[18:57] <nbd> not yet
[18:58] <[mbm]> hmm looks like I'll be doing that later today :/
[19:03] <[mbm]> and there's the main source of the problem, include/linux/devfs_fs_kernel.h is almost completely wiped out
[19:16] <[florian]> nbd: did you change something in the flash map driver ? I can't boot on the flash now :(
[19:17] <[florian]> maybe I should try ramdisk to begin
[19:19] <nbd> [florian]: what happens when you try to boot?
[19:21] <[florian]> here it is : http://pastebin.ca/149239
[19:21] <nbd> that's the same one that i get
[19:22] <nbd> maybe it'll work when i fix up the flash stuff for my board
[19:22] <nbd> it's probably broken because i ripped out that stupid broadcom flash code
[19:22] <nbd> i didn't change the flash map itsef
[19:23] <[florian]> nbd: I don't remember seeing that redboot calls broadcom flash code actually
[19:23] <[florian]> let me resentence
[19:23] <[florian]> I don't remember seeing that once the bootloader is detected as redboot it should use any of the broadcom code
[19:23] <nbd> hmm
[19:24] <nbd> need to look into that flash map driver again
[19:24] <[florian]> probably
[19:24] <nbd> but i want to get ethernet up and running now
[19:25] <[florian]> sure, I see that you have disabled the bcm963xx flash map in the kernel config ?
[19:25] <[florian]> and you use physmap instead ?
[19:26] <nbd> i haven't changed the mtd stuff
[19:28] <[florian]> ok
[19:28] <nbd> made some progress with the driver:
[19:28] <nbd> Broadcom BCM6348A2 Ethernet Network Device v0.3 Aug 9 2006 22:40:44
[19:28] <nbd> Config Ethernet Switch Through SPI Slave Select 1
[19:28] <nbd> eth0: MAC Address: 00:07:3A:FF:FF:FF
[19:29] <[florian]> well done
[19:29] <nbd> then it locks up
[19:29] <[florian]> :(
[19:29] <frop> ...my pppoe still doens't work...with recent revision
[19:35] <[florian]> nbd: new crashes on this redboot device : http://pastebin.ca/149262
[19:39] <[mbm]> ah.
[19:40] <[mbm]> b/drivers/scsi/scsi_scan.c:
[19:40] <[mbm]> - sprintf(sdev->devfs_name, "scsi/host%d/bus%d/target%d/lun%d",
[19:40] <[mbm]> ...
[19:40] <[florian]> I think we are going to have a lot of headaches with this device ;)
[19:40] <[mbm]> there's a problem
[19:41] <[mbm]> annoying thing is that devfs_name got removed in several places
[20:04] <[mbm]> *mumble* tedious work going throught he whole damned patch-2.6.17 looking for where gregkh nuked devfs support
[20:05] <nbd> can't you take gregkh's patches and reverse them?
[20:05] <[mbm]> he didn't post em
[20:05] <[mbm]> http://www.kernel.org/pub/linux/kernel/people/gregkh/devfs/2.6/2.6.17 seems to be post-2.6.17
[20:06] <nbd> hmm
[20:06] <[mbm]> so now I'm trimming patch-2.6.17 into a nice devfs reverse patch
[20:14] <[florian]> nbd: I don't manage to get the assoclist, where I could get any of the other ioctl's : revinfo (uses structure), phytype
[20:15] <nbd> what's the problem with the assoclist?
[20:15] <[florian]> I have tried using the wl_assoc_mac structure documented in utils.h, and I don't see anything
[20:16] <[florian]> I also tried with a 8192 long buffer, nothing
[20:16] <[florian]> now I have just tried with a pointer to a wl_assoc_mac structure, nothing
[20:16] <[florian]> so I think it returns something that may not be documented actually
[20:17] <nbd> did you use memset on the buffer before sending it to the driver?
[20:17] <[florian]> no, I use a statically allocated buffer
[20:17] <nbd> use memset
[20:17] <[florian]> ah, you are right, I may need to use memset
[20:20] <[florian]> nbd: same effect, nothing :(
[20:20] <[florian]> I wonder if it does not return a list of mac address
[20:23] <nbd> [florian]: save the buffer to a file and view it with hexdump
[20:23] <[florian]> yup
[20:23] <CIA-17> mbm * r4669 /branches/buildroot-ng/openwrt/target/linux/generic-2.6/patches/000-reenable_devfs.patch: update devfs patches
[20:23] <[mbm]> :)
[20:24] <[mbm]> groz: that should fix your devfs_mk_dir errors
[20:24] Action: [mbm] hasn't yet confirmed
[20:24] <groz> it'll be a couple hours till i can try
[20:25] Action: groz just getting started on the day here, still working on wakeup coffee and catching up on phone calls
[20:25] <[mbm]> nod.
[20:29] <CIA-17> mbm * r4670 /branches/buildroot-ng/openwrt/target/linux/aruba-2.6/config: update config
[20:31] <[florian]> nbd: does not change anything, buffer still empty
[20:32] <[florian]> nbd: could wl compat debug, and wl assoclist help find out the type of data passed to the buffer ?
[20:33] <nbd> yes
[20:34] <[florian]> here is what I get : http://pastebin.ca/149309
[20:35] <[florian]> the first byte indicates the number of associated macs
[20:35] <[florian]> and then the associated macs
[20:36] <[florian]> ok, I found the structure :)
[20:36] <nbd> ok, when preparing the buffer, give it 0x545 in the first dword
[20:36] <nbd> :)
[20:38] <[florian]> why ?
[20:38] <[florian]> because you see it, yes :)
[20:38] <nbd> i think that's the maximum number of entries or something like that
[20:38] <[florian]> probably
[21:02] Action: Bartman007 wonders why #openwrt has turned into a flamewar
[21:05] <[florian]> probably because J4k3 is there ;)
[21:26] <[florian]> nbd: to set up the buffer, memset(buffer, 0x545, 2) should do the trick right ?
[21:31] <nbd> [florian]: don't use memset for writing in that byte
[21:31] <nbd> [florian]: first use memset to clear the whole buffer
[21:32] <nbd> [florian]: then you can cast the buffer pointer to an u32 pointer, dereference it and throw in the value
[21:37] <[florian]> ok
[22:17] <CIA-17> malbon * r4671 /branches/buildroot-ng/openwrt/target/linux/au1000-2.6/config: Make the build work properly by including Hostap modules.
[22:27] <[florian]> malbon: thanks !
[22:27] <[florian]> by the way malbon do you have any au1000 device ?
[22:45] <[mbm]> yay! /dev/scsi/host0/bus0/target0/lun0/part1 ;)
[22:46] <crazy_imp> cdromsupport now?
[22:47] <[mbm]> no, just working usb drive support (again)
[22:47] <[mbm]> groz: patch worked
[22:49] <groz> great thanks, i haven't had a chance to grab and build it yet
[22:49] Action: groz dealking with fires at a client site today
[22:49] <groz> literally dealing with fires
[22:49] <[mbm]> I had to have working usb support for one of my projects
[22:50] <groz> i guess a sprinkler system went off last nite
[22:50] <groz> and a few puters got wet
[22:50] <[mbm]> last known working usb was 2.6.16.7 .. had to dig through the patch-2.6.17 by hand and revert the usb changes
[22:50] <[mbm]> seems happy now
[22:50] <groz> well, i was looking at some of those on that page of greg's patches the other day
[22:51] <groz> and i didn't find anything that seemed to actually be source of the problem
[22:51] <[mbm]> those are the fun we have to look for post 2.6.17
[22:51] <[mbm]> turns out greg had quietly removed devfs_name from several key drivers
[22:51] <groz> there will reach a point, where we ask what the benefit of pissing upwind is :)
[22:51] <[mbm]> which means that everything ended up as <NULL>/part1
[22:52] <[mbm]> and devfs_mk_dir puked at the fact the string was apparnetly null
[22:52] <groz> but, i'd like to take somebody quietly out back over that whole issue
[22:52] Action: groz has a 12 guage needs some exercise
[22:52] <[mbm]> :)
[22:53] <groz> scattergun is an awful slow and painful way to go
[22:54] <[mbm]> http://pastebin.ca/149447 .. might be useful to someone
[22:55] <[mbm]> it mostly shows how you cna automatically figure out the name of any inserted usb disk
[22:59] <dragorn> thats handy
[22:59] <dragorn> considering i have to figure out just that soon :)
[22:59] <dragorn> My friend wants to have a system w/ a multicard usb reader at his wedding where people can plug in a disk and it'll copy all the files off automatically.
[23:07] <groz> I'd say the auto copy off a multi card is a dumb idea, but, it's nowhere near as dumb as the idea of having a wedding
[23:07] <groz> :)
[23:09] <dragorn> why is it a dumb idea?
[23:09] <dragorn> it's to let everyone w/ digicams contribute to his wedding album
[23:09] <dragorn> not like it's a security system (or even networked)
[23:09] <groz> cuz i've been there, and done that, and a wedding is the dumbest thing you can ever do
[23:10] <groz> the fastest way to turn a good friend into a very expensive mortal enemy
[23:20] <malbon> [florian]: Nope. I don't have any au1000 devices. :)
[23:38] <frop> ehi, there's a way to set the "macdsl" for tiatm instead of 00:00:02:03:04:05?
[23:39] <frop> cause "insmod tiatm"
[23:39] <frop> meka this
[23:39] <frop> Itf Type ESI/"MAC"addr AAL(TX,err,RX,err,drop) ... [refcnt]
[23:39] <frop> 0 avsar 000002030405 0 ( 0 0 0 0 0 ) 5 ( 0 0 0 0 0 ) [1]
[23:39] <frop> also, changing nas0 mac, doesn't change value in /proc/net/atm/devices
[23:53] <CIA-17> kaloz * r4672 /branches/buildroot-ng/openwrt/ (21 files in 12 dirs): add basic support for the Magicbox boards
[00:00] --- Sat Aug 26 2006