[01:39] <common> Bartman007: i have had success withmy xscale device
[01:39] <common> patched in the intel drivers, and it really works
[01:57] <Bartman007> common: is that the patch you want committed?
[02:00] <common> no
[02:00] <common> the patch to support the xscale features is 'little larger'
[02:01] <common> and some things don't work, f.e. i have no idea how to add kmod's
[02:01] <common> and nobody was so kind to assist me
[02:01] <common> but it works
[02:02] <Bartman007> I take it you've read the Kernel Module Creation section of the docs?
[02:03] <common> updated to buildroot ng?
[02:04] <common> the modules are compiled and work
[02:04] <common> but i was unable to make a kmod of them
[02:52] <common> and for me ipkg is really broken
[02:52] <common> it can't even install ipkg files downloaded
[08:32] Action: Bartman007 goes to see if this ipsec-tools compilation failure is a known issue
[08:36] <Bartman007> err, I can't read, ipset
[09:40] <CIA-17> groz * r4566 /branches/buildroot-ng/openwrt/package/kernel/modules.mk: Fix up kmod-mppe for 2.6 kernels too
[09:41] <CIA-17> groz * r4567 /branches/buildroot-ng/openwrt/ (include/image.mk target/linux/uml-2.6/config): Make ext2 image larger for uml, update uml kernel config
[09:51] <CIA-17> groz * r4568 /branches/buildroot-ng/openwrt/target/linux/x86-2.6/config: Generalize the x86 kernel config for more generic processor options
[10:16] <CIA-17> groz * r4569 /branches/buildroot-ng/openwrt/ (8 files in 4 dirs): Move a bunch of ethernet hardware drivers to new kernel module packageing
[10:21] <groz> nico ping
[11:46] <malbon> groz: Nico is in the UK I think.
[14:49] <common> nbd: how shall i diff the intel ixp patches?
[14:51] <Kaloz> common: the access library won't go in, we will have a free driver instead
[14:51] <Kaloz> damn, i have to run, bbl
[14:53] <common> Kaloz: which?
[19:26] <common> from what i know there is no free driver
[21:40] <groz> is anybody here really familiar with 2.6 and usb key flash disks ?
[21:42] <[mbm]> define 'really familiar'
[21:42] <groz> root@OpenWrt:/# usb 2-1: new full speed USB device using uhci_hcd and address 2
[21:42] <groz> usb 2-1: configuration #1 chosen from 1 choice
[21:42] <groz> scsi0 : SCSI emulation for USB Mass Storage devices
[21:42] <groz> Vendor: POWERDAT Model: POWERDATA Rev: 1.00
[21:42] <groz> Type: Direct-Access ANSI SCSI revision: 00
[21:42] <groz> SCSI device sda: 260448 512-byte hdwr sectors (133 MB)
[21:42] <groz> sda: Write Protect is off
[21:43] <groz> sda: assuming drive cache: write through
[21:43] <groz> devfs_mk_dir: invalid argument.<5>SCSI device sda: 260448 512-byte hdwr sectors
[21:43] <groz> (133 MB)
[21:43] <groz> sda: Write Protect is off
[21:43] <groz> sda: assuming drive cache: write through
[21:43] <groz> sda: unknown partition table
[21:43] <groz> sd 0:0:0:0: Attached scsi removable disk sda
[21:43] <groz> note the devfs_mk_dir error
[21:43] <groz> i cannot figure out how to mount this thing, and not sure if this is a module issue, am i missing something
[21:43] <groz> or what
[21:43] <[mbm]> well, devfs got pulled from the 2.6 ekrnels so what you're seeing is probably a side effect of that
[21:43] <groz> this is a 2.6 kernel booted with initramfs netbooted
[21:44] <groz> well, if I remove devfs
[21:44] <groz> it doesn't even get me to a prompt anymore
[21:44] <[mbm]> the disk should show up under /dev/scsi or /dev/sd* depending on which naming scheme is used
[21:44] <groz> that's just it
[21:44] <groz> it doesn't show up as /dev/anything
[21:45] <[mbm]> from the looks of the above you should have a /dev/sda
[21:45] <groz> i should, but i dont
[21:45] <[mbm]> you might have to look at the code and see where that devfs error is
[21:45] <groz> this is the x86 tree built with nothing fancy
[21:45] <groz> initramfs
[21:46] <groz> the only fancy thing, i'm netbooting the resultant kernel
[21:46] <groz> till i can figure out how to make it read/write that usb thingy
[21:46] <[mbm]> it's an openwrt kernel right?
[21:46] <groz> yes, exactly what i committed last nite
[21:46] <[mbm]> and it's a 2.6.17 kernel, right?
[21:46] <groz> yup
[21:46] <groz> i've been playing with kernel configs regarding devfs and the scsi stuff
[21:46] <[mbm]> we patched devfs support back in, but it appears not everything got patched
[21:46] <groz> trying to figure out if i'm misssing something
[21:47] <groz> ahhh, ok
[21:47] <groz> so what i'm looking for then is the missing bit in the scsi stuff
[21:47] <[mbm]> yep; there must have been a change in 2.6.17 that removed more "dead" devfs code
[21:47] <groz> ok, that's the clue i was looking for
[21:48] <groz> yah, there was a bunch of it, i saw some notes on kerneltrap regarding that
[21:48] <groz> ok, i'll go hunting for the piece i'm missing
[21:48] <groz> but this will bring up a question
[21:49] <murb> [mbm]: any longer term plans?
[21:49] <[mbm]> murb: ?
[21:49] <groz> are we pissing upwind trying to stick with using devfs ?
[21:49] <murb> [mbm]: what to do about devfs
[21:49] <groz> should we just let it go, and make this all work without it ?
[21:49] <groz> but i cannot say i'm fond of that myself
[21:49] <[mbm]> I'm terribly annoyed with udev
[21:50] <[mbm]> with devs I create an empty /dev and tell it to mount devfs on boot
[21:50] <murb> yes udev is more work.
[21:50] <[mbm]> with anything else I need a populated /dev to boot from, then create a tmpfs ontop of that and run some userspace crap
[21:50] <murb> [mbm]: except you don't have to create a tmpfs
[21:51] <[mbm]> or ship with a fully populated /dev and screw all the automated stuff
[21:51] <murb> it works fine on the raw disk
[21:51] <murb> s/disk/filesystem/
[21:51] <[mbm]> murb: I really don't want it writing to the flash
[21:51] <groz> not if your filesystem is not writeable it doesn't
[21:51] <murb> :p
[21:51] Action: [mbm] thinks the whole devfs thing was a pissing contest between some of the kernel developers
[21:52] <groz> what i dont get is why 'rip it out'
[21:52] <[mbm]> religious wars
[21:52] <groz> why not just leave it , and if you really dont want it, make defaults 'not configured'
[21:52] <murb> nobody was maintaining it.
[21:52] <[mbm]> some people think that the kernel should to the absolute minimum
[21:52] <[mbm]> and everything should be moved to userspace
[21:52] <murb> the philsophy is if you cand o it in userspace you should
[21:52] <murb> see the earlyuserspace stuff as well.
[21:52] <[mbm]> others like to offload things to the kernel
[21:53] <murb> they want to get rid of partition reading code from the kernel and things like that as well.
[21:53] <[mbm]> murb: the ironic thing that linux started with the opposite argument claiming monolithic was better than microkernel
[21:53] <groz> well, i do agree with the microkernel arguements 'to a point'
[21:53] <groz> but
[21:53] <[mbm]> it's the new kernel maintainers that are trying to drag things back towards micro
[21:54] <murb> [mbm]: and khttpd was written :-)
[21:54] <groz> in our case, we are building mimial little devices
[21:54] <groz> optimum configuration, monolithic
[21:54] <[mbm]> murb: ktux, but yes, and it got ripped out
[21:54] <groz> actually include your final application into the kernel as well
[21:54] <murb> [mbm]: redhat still patch it back in :-)
[21:54] <murb> tux never actually went in offically.
[21:54] <[mbm]> murb: and I really don't blame them
[21:55] <murb> [mbm]: well they employ those responsible that it would never get in, in the first place.
[21:56] <[mbm]> what really annoys me is that despite all the posturing that linux is multiplatform, the standard linux kernel is only guaranteed to work on an x86 .. most of the embeded archs don't even compile or get frequently broken
[21:57] <[mbm]> there's countless projects like linux-mips that maintain their own forks
[21:57] <[mbm]> not patch sets but complete forks of the kernel
[21:57] <groz> umm, u mean like openwrt, patching the kernel to no end
[21:57] <murb> like that.
[21:57] <[mbm]> what we do is tame
[21:57] <[mbm]> we take a standard kernel and apply a few patches to get it to boot
[21:58] <[mbm]> try diffing a linux-mips kernel with the identical linus version
[21:58] <[mbm]> the /arch folders have been completely rewritten
[22:00] <groz> ok, now you got me thinking on this stupid problem, debating just going back a few revs from .17, and see if it works there, then just diff the working from non working in the scsi modules
[22:01] <[mbm]> I know it was working in 15 .. haven't kept track of when it broke
[22:01] <groz> ok, then i'll just diff .15 and .17 see what i come up with
[22:02] <murb> or you could just pull the changeset where it was taken out.
[22:02] <[mbm]> I'd start by chasing down that error message and looking at that section of the code
[22:03] Action: groz starts by making a fresh pot of coffee
[22:03] Action: [mbm] feels like beating a few kernel devs senseless
[22:03] <murb> http://www.kernel.org/pub/linux/kernel/people/gregkh/devfs/2.6/2.6.17/
[22:04] <[mbm]> probably devfs-remove-genhd-devfs_name.patch
[22:04] <[mbm]> revert that
[22:04] <groz> yah, just going to look now
[22:04] <groz> soon as i got fresh coffee
[22:05] <Bartman007> coffee: don't code without it :-)
[22:05] <groz> but that does look like it
[22:09] <[mbm]> there's some stuff about devfs on lmkl if you digg it up
[22:09] <[mbm]> gregkh basically says that the only people that have complained are people doing embeded systems, and apparently they don't matter
[22:10] <groz> ofc not, it makes sense to ignore your largest user base doesn't it ?
[22:10] <groz> if it's 'different' than what you are doing yourself
[22:10] <groz> ther'es probably a thousaned embedded linux systems out there for every linux desktop
[22:11] <groz> or more
[22:13] <[mbm]> between that and the gpl v3 changes, I'm really not found of linux's future
[22:13] <dragorn> udev angers me
[22:15] <[mbm]> I suppose the other annoying change is that they're slowly removing support to have initrd as a filesystem image
[22:15] <[mbm]> and making it into a gzipped cpio
[22:15] <[mbm]> which takes much longer to boot
[22:15] <[mbm]> & uses more ram
[22:24] <murb> part of the early userspace stuff along with klibc.
[22:25] <[mbm]> yeah I know, I just think removing it was another bad choice
[00:00] --- Tue Aug 15 2006
[01:39] <common> patched in the intel drivers, and it really works
[01:57] <Bartman007> common: is that the patch you want committed?
[02:00] <common> no
[02:00] <common> the patch to support the xscale features is 'little larger'
[02:01] <common> and some things don't work, f.e. i have no idea how to add kmod's
[02:01] <common> and nobody was so kind to assist me
[02:01] <common> but it works
[02:02] <Bartman007> I take it you've read the Kernel Module Creation section of the docs?
[02:03] <common> updated to buildroot ng?
[02:04] <common> the modules are compiled and work
[02:04] <common> but i was unable to make a kmod of them
[02:52] <common> and for me ipkg is really broken
[02:52] <common> it can't even install ipkg files downloaded
[08:32] Action: Bartman007 goes to see if this ipsec-tools compilation failure is a known issue
[08:36] <Bartman007> err, I can't read, ipset
[09:40] <CIA-17> groz * r4566 /branches/buildroot-ng/openwrt/package/kernel/modules.mk: Fix up kmod-mppe for 2.6 kernels too
[09:41] <CIA-17> groz * r4567 /branches/buildroot-ng/openwrt/ (include/image.mk target/linux/uml-2.6/config): Make ext2 image larger for uml, update uml kernel config
[09:51] <CIA-17> groz * r4568 /branches/buildroot-ng/openwrt/target/linux/x86-2.6/config: Generalize the x86 kernel config for more generic processor options
[10:16] <CIA-17> groz * r4569 /branches/buildroot-ng/openwrt/ (8 files in 4 dirs): Move a bunch of ethernet hardware drivers to new kernel module packageing
[10:21] <groz> nico ping
[11:46] <malbon> groz: Nico is in the UK I think.
[14:49] <common> nbd: how shall i diff the intel ixp patches?
[14:51] <Kaloz> common: the access library won't go in, we will have a free driver instead
[14:51] <Kaloz> damn, i have to run, bbl
[14:53] <common> Kaloz: which?
[19:26] <common> from what i know there is no free driver
[21:40] <groz> is anybody here really familiar with 2.6 and usb key flash disks ?
[21:42] <[mbm]> define 'really familiar'
[21:42] <groz> root@OpenWrt:/# usb 2-1: new full speed USB device using uhci_hcd and address 2
[21:42] <groz> usb 2-1: configuration #1 chosen from 1 choice
[21:42] <groz> scsi0 : SCSI emulation for USB Mass Storage devices
[21:42] <groz> Vendor: POWERDAT Model: POWERDATA Rev: 1.00
[21:42] <groz> Type: Direct-Access ANSI SCSI revision: 00
[21:42] <groz> SCSI device sda: 260448 512-byte hdwr sectors (133 MB)
[21:42] <groz> sda: Write Protect is off
[21:43] <groz> sda: assuming drive cache: write through
[21:43] <groz> devfs_mk_dir: invalid argument.<5>SCSI device sda: 260448 512-byte hdwr sectors
[21:43] <groz> (133 MB)
[21:43] <groz> sda: Write Protect is off
[21:43] <groz> sda: assuming drive cache: write through
[21:43] <groz> sda: unknown partition table
[21:43] <groz> sd 0:0:0:0: Attached scsi removable disk sda
[21:43] <groz> note the devfs_mk_dir error
[21:43] <groz> i cannot figure out how to mount this thing, and not sure if this is a module issue, am i missing something
[21:43] <groz> or what
[21:43] <[mbm]> well, devfs got pulled from the 2.6 ekrnels so what you're seeing is probably a side effect of that
[21:43] <groz> this is a 2.6 kernel booted with initramfs netbooted
[21:44] <groz> well, if I remove devfs
[21:44] <groz> it doesn't even get me to a prompt anymore
[21:44] <[mbm]> the disk should show up under /dev/scsi or /dev/sd* depending on which naming scheme is used
[21:44] <groz> that's just it
[21:44] <groz> it doesn't show up as /dev/anything
[21:45] <[mbm]> from the looks of the above you should have a /dev/sda
[21:45] <groz> i should, but i dont
[21:45] <[mbm]> you might have to look at the code and see where that devfs error is
[21:45] <groz> this is the x86 tree built with nothing fancy
[21:45] <groz> initramfs
[21:46] <groz> the only fancy thing, i'm netbooting the resultant kernel
[21:46] <groz> till i can figure out how to make it read/write that usb thingy
[21:46] <[mbm]> it's an openwrt kernel right?
[21:46] <groz> yes, exactly what i committed last nite
[21:46] <[mbm]> and it's a 2.6.17 kernel, right?
[21:46] <groz> yup
[21:46] <groz> i've been playing with kernel configs regarding devfs and the scsi stuff
[21:46] <[mbm]> we patched devfs support back in, but it appears not everything got patched
[21:46] <groz> trying to figure out if i'm misssing something
[21:47] <groz> ahhh, ok
[21:47] <groz> so what i'm looking for then is the missing bit in the scsi stuff
[21:47] <[mbm]> yep; there must have been a change in 2.6.17 that removed more "dead" devfs code
[21:47] <groz> ok, that's the clue i was looking for
[21:48] <groz> yah, there was a bunch of it, i saw some notes on kerneltrap regarding that
[21:48] <groz> ok, i'll go hunting for the piece i'm missing
[21:48] <groz> but this will bring up a question
[21:49] <murb> [mbm]: any longer term plans?
[21:49] <[mbm]> murb: ?
[21:49] <groz> are we pissing upwind trying to stick with using devfs ?
[21:49] <murb> [mbm]: what to do about devfs
[21:49] <groz> should we just let it go, and make this all work without it ?
[21:49] <groz> but i cannot say i'm fond of that myself
[21:49] <[mbm]> I'm terribly annoyed with udev
[21:50] <[mbm]> with devs I create an empty /dev and tell it to mount devfs on boot
[21:50] <murb> yes udev is more work.
[21:50] <[mbm]> with anything else I need a populated /dev to boot from, then create a tmpfs ontop of that and run some userspace crap
[21:50] <murb> [mbm]: except you don't have to create a tmpfs
[21:51] <[mbm]> or ship with a fully populated /dev and screw all the automated stuff
[21:51] <murb> it works fine on the raw disk
[21:51] <murb> s/disk/filesystem/
[21:51] <[mbm]> murb: I really don't want it writing to the flash
[21:51] <groz> not if your filesystem is not writeable it doesn't
[21:51] <murb> :p
[21:51] Action: [mbm] thinks the whole devfs thing was a pissing contest between some of the kernel developers
[21:52] <groz> what i dont get is why 'rip it out'
[21:52] <[mbm]> religious wars
[21:52] <groz> why not just leave it , and if you really dont want it, make defaults 'not configured'
[21:52] <murb> nobody was maintaining it.
[21:52] <[mbm]> some people think that the kernel should to the absolute minimum
[21:52] <[mbm]> and everything should be moved to userspace
[21:52] <murb> the philsophy is if you cand o it in userspace you should
[21:52] <murb> see the earlyuserspace stuff as well.
[21:52] <[mbm]> others like to offload things to the kernel
[21:53] <murb> they want to get rid of partition reading code from the kernel and things like that as well.
[21:53] <[mbm]> murb: the ironic thing that linux started with the opposite argument claiming monolithic was better than microkernel
[21:53] <groz> well, i do agree with the microkernel arguements 'to a point'
[21:53] <groz> but
[21:53] <[mbm]> it's the new kernel maintainers that are trying to drag things back towards micro
[21:54] <murb> [mbm]: and khttpd was written :-)
[21:54] <groz> in our case, we are building mimial little devices
[21:54] <groz> optimum configuration, monolithic
[21:54] <[mbm]> murb: ktux, but yes, and it got ripped out
[21:54] <groz> actually include your final application into the kernel as well
[21:54] <murb> [mbm]: redhat still patch it back in :-)
[21:54] <murb> tux never actually went in offically.
[21:54] <[mbm]> murb: and I really don't blame them
[21:55] <murb> [mbm]: well they employ those responsible that it would never get in, in the first place.
[21:56] <[mbm]> what really annoys me is that despite all the posturing that linux is multiplatform, the standard linux kernel is only guaranteed to work on an x86 .. most of the embeded archs don't even compile or get frequently broken
[21:57] <[mbm]> there's countless projects like linux-mips that maintain their own forks
[21:57] <[mbm]> not patch sets but complete forks of the kernel
[21:57] <groz> umm, u mean like openwrt, patching the kernel to no end
[21:57] <murb> like that.
[21:57] <[mbm]> what we do is tame
[21:57] <[mbm]> we take a standard kernel and apply a few patches to get it to boot
[21:58] <[mbm]> try diffing a linux-mips kernel with the identical linus version
[21:58] <[mbm]> the /arch folders have been completely rewritten
[22:00] <groz> ok, now you got me thinking on this stupid problem, debating just going back a few revs from .17, and see if it works there, then just diff the working from non working in the scsi modules
[22:01] <[mbm]> I know it was working in 15 .. haven't kept track of when it broke
[22:01] <groz> ok, then i'll just diff .15 and .17 see what i come up with
[22:02] <murb> or you could just pull the changeset where it was taken out.
[22:02] <[mbm]> I'd start by chasing down that error message and looking at that section of the code
[22:03] Action: groz starts by making a fresh pot of coffee
[22:03] Action: [mbm] feels like beating a few kernel devs senseless
[22:03] <murb> http://www.kernel.org/pub/linux/kernel/people/gregkh/devfs/2.6/2.6.17/
[22:04] <[mbm]> probably devfs-remove-genhd-devfs_name.patch
[22:04] <[mbm]> revert that
[22:04] <groz> yah, just going to look now
[22:04] <groz> soon as i got fresh coffee
[22:05] <Bartman007> coffee: don't code without it :-)
[22:05] <groz> but that does look like it
[22:09] <[mbm]> there's some stuff about devfs on lmkl if you digg it up
[22:09] <[mbm]> gregkh basically says that the only people that have complained are people doing embeded systems, and apparently they don't matter
[22:10] <groz> ofc not, it makes sense to ignore your largest user base doesn't it ?
[22:10] <groz> if it's 'different' than what you are doing yourself
[22:10] <groz> ther'es probably a thousaned embedded linux systems out there for every linux desktop
[22:11] <groz> or more
[22:13] <[mbm]> between that and the gpl v3 changes, I'm really not found of linux's future
[22:13] <dragorn> udev angers me
[22:15] <[mbm]> I suppose the other annoying change is that they're slowly removing support to have initrd as a filesystem image
[22:15] <[mbm]> and making it into a gzipped cpio
[22:15] <[mbm]> which takes much longer to boot
[22:15] <[mbm]> & uses more ram
[22:24] <murb> part of the early userspace stuff along with klibc.
[22:25] <[mbm]> yeah I know, I just think removing it was another bad choice
[00:00] --- Tue Aug 15 2006