Yes, this is known. I have spoken with the squashfs developer and he is looking into it.

For the record though, there are no "hacks" to get it to build. Every kernel module is buildable outside the kernel proper, and, in fact, squashfs itself is developed outside the kernel.

This may be fixed with squashfs 3.2 (in testing).
I need to wait some time to test though.

Just tried it with 2.6.19 kernel (with appropriate changes to PKGBUILD) - segfault.
Could it have something to do with the the failed patching of init/do_mounts_rd.c, which doesn't exist in the already built kernel?

No. That portion of the patch is related to mounting a squashfs ramdisk for initrd/initramfs. It's useless to us (at this point). I really have no idea where to look anymore. Perhaps an email to the author (for the third time) asking what kernel config options MUST be present...

As far as I know, this is built MOSTLY the same as debian does it....
/me shrugs

Can it really be a problem with kernel config options? When built within the kernel using standard Arch options it works fine - the problem only arises with the attempt to build it outside of the kernel.

Ok, 3.2-r2 is in CVS (not in testing), and I changed some of the build options, so we'll see if that helps. Can someone try building and testing this?

i686 2.6.19-ARCH: segmentation fault ...

modprobe squashfs
dmesg
...
kmem_cache_create: Early error in slab U���$
------------[ cut here ]------------
kernel BUG at mm/slab.c:2130!
invalid opcode: 0000 [#1]
PREEMPT SMP
Modules linked in: squashfs zlib_inflate radeon drm ipv6 reiserfs ppdev snd_seq_oss snd_seq_midi_event snd_seq lp rtc analog snd_pcm_oss snd_mixer_oss sata_via libata snd_via82xx i2c_viapro gameport snd_ac97_codec ac97_bus snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device shpchp pci_hotplug parport_pc parport tsdev via_rhine i2c_core snd ppp_generic via_agp agpgart soundcore slhc ehci_hcd evdev pcspkr uhci_hcd usbnet mii usbcore ext3 jbd mbcache ide_cd cdrom ide_disk via82cxxx generic ide_core
CPU: 1
EIP: 0060:[<c016d372>] Not tainted VLI
EFLAGS: 00210282 (2.6.20-ARCH #1)
EIP is at kmem_cache_create+0x122/0x530
eax: 00000036 ebx: dfdf163c ecx: 00200002 edx: 00200000
esi: e0ca6080 edi: c034990f ebp: e0ca4d6c esp: d4c6de50
ds: 007b es: 007b ss: 0068
Process modprobe (pid: 3639, ti=d4c6c000 task=de73c570 task.ti=d4c6c000)
Stack: c0391444 c034990f e0a84000 00000001 e0ca6080 e0ca6080 e0a84000 00000001
de73c570 c033fb55 00000001 e0ca60c8 00200202 dfdf163c e0ca6080 dfdf1674
d4c6dec0 e0a8403b e0ca4d6c 000001a8 00000000 00022000 e0c9c488 00000000
Call Trace:
[<e0a84000>] init_squashfs_fs+0x0/0x78 [squashfs]
[<e0a84000>] init_squashfs_fs+0x0/0x78 [squashfs]
[<c033fb55>] __mutex_lock_slowpath+0x115/0x280
[<e0a8403b>] init_squashfs_fs+0x3b/0x78 [squashfs]
[<e0c9c488>] init_once+0x0/0x21 [squashfs]
[<c0143e20>] __link_module+0x0/0x20
[<c0144d9f>] sys_init_module+0x15f/0x1ad0
[<c0225d8f>] prio_tree_insert+0x1f/0x250
[<c0103200>] sysenter_past_esp+0x5d/0x81
=======================
Code: 8b 41 08 a8 08 74 92 e8 1d 17 1d 00 eb 8b 8b 44 24 18 bf 0f 99 34 c0 89 7c 24 04 c7 04 24 44 14 39 c0 89 44 24 08 e8 ce a0 fb ff <0f> 0b eb fe 8b 4c 24 18 c7 04 24 90 14 39 c0 89 4c 24 04 e8 b6
EIP: [<c016d372>] kmem_cache_create+0x122/0x530 SS:ESP 0068:d4c6de50

Yup, same error each time. Patching the kernel seems like the only plausible solution. Assigning to our kernel maintainer.

added to kernel closing now