* [parisc-linux] 2.4.20-paxx Config problem?
From: jsoe0708 @ 2002-12-19 18:06 UTC (permalink / raw)
To: parisc-linux
Hi all,
Let me first wish you and your families a Merry Christmas and a Happy New=
Year.
Also thanks you all for relevant help.
I need again help because I used a .config file of my own and I obtain a
kernel 2.4.20-paxx operational on my b2k.
I also try to test the one suggested in arch/parisc/debian-configs/32.
But this one make hung the kernel at "search devices..." step and the gre=
en
led on the ide cdrom stay light.
Here is the diff between mine and the suggested:
--- config-2.4.20-pa14 2002-12-19 17:36:14.000000000 +0100
+++ 32 2002-12-18 14:27:04.000000000 +0100
@@ -101,32 +101,33 @@
#
CONFIG_MD=3Dy
CONFIG_BLK_DEV_MD=3Dy
-# CONFIG_MD_LINEAR is not set
-# CONFIG_MD_RAID0 is not set
+CONFIG_MD_LINEAR=3Dy
+CONFIG_MD_RAID0=3Dy
CONFIG_MD_RAID1=3Dy
-# CONFIG_MD_RAID5 is not set
+CONFIG_MD_RAID5=3Dy
# CONFIG_MD_MULTIPATH is not set
-CONFIG_BLK_DEV_LVM=3Dy
+# CONFIG_BLK_DEV_LVM is not set
#
# Networking options
#
CONFIG_PACKET=3Dy
-# CONFIG_PACKET_MMAP is not set
-# CONFIG_NETLINK_DEV is not set
+CONFIG_PACKET_MMAP=3Dy
+CONFIG_NETLINK_DEV=3Dy
CONFIG_NETFILTER=3Dy
CONFIG_NETFILTER_DEBUG=3Dy
CONFIG_FILTER=3Dy
CONFIG_UNIX=3Dy
CONFIG_INET=3Dy
-# CONFIG_IP_MULTICAST is not set
+CONFIG_IP_MULTICAST=3Dy
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_PNP=3Dy
# CONFIG_IP_PNP_DHCP is not set
-# CONFIG_IP_PNP_BOOTP is not set
+CONFIG_IP_PNP_BOOTP=3Dy
# CONFIG_IP_PNP_RARP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
+# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
# CONFIG_INET_ECN is not set
# CONFIG_SYN_COOKIES is not set
@@ -147,7 +148,7 @@
CONFIG_IP_NF_MATCH_TOS=3Dm
# CONFIG_IP_NF_MATCH_ECN is not set
# CONFIG_IP_NF_MATCH_DSCP is not set
-# CONFIG_IP_NF_MATCH_AH_ESP is not set
+CONFIG_IP_NF_MATCH_AH_ESP=3Dm
# CONFIG_IP_NF_MATCH_LENGTH is not set
# CONFIG_IP_NF_MATCH_TTL is not set
CONFIG_IP_NF_MATCH_TCPMSS=3Dm
@@ -172,7 +173,7 @@
# CONFIG_IP_NF_TARGET_DSCP is not set
CONFIG_IP_NF_TARGET_MARK=3Dm
CONFIG_IP_NF_TARGET_LOG=3Dm
-# CONFIG_IP_NF_TARGET_ULOG is not set
+CONFIG_IP_NF_TARGET_ULOG=3Dm
CONFIG_IP_NF_TARGET_TCPMSS=3Dm
# CONFIG_IP_NF_ARPTABLES is not set
CONFIG_IP_NF_COMPAT_IPCHAINS=3Dm
@@ -310,12 +311,12 @@
#
CONFIG_BLK_DEV_SD=3Dy
CONFIG_SD_EXTRA_DEVS=3D40
-CONFIG_CHR_DEV_ST=3Dm
+CONFIG_CHR_DEV_ST=3Dy
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=3Dy
# CONFIG_BLK_DEV_SR_VENDOR is not set
CONFIG_SR_EXTRA_DEVS=3D2
-CONFIG_CHR_DEV_SG=3Dm
+CONFIG_CHR_DEV_SG=3Dy
#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
@@ -370,7 +371,7 @@
CONFIG_53C700_USE_CONSISTENT=3Dy
# CONFIG_SCSI_NCR53C7xx is not set
CONFIG_SCSI_SYM53C8XX_2=3Dy
-CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=3D0
+CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=3D1
CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=3D16
CONFIG_SCSI_SYM53C8XX_MAX_TAGS=3D64
# CONFIG_SCSI_SYM53C8XX_IOMAPPED is not set
@@ -381,7 +382,7 @@
CONFIG_ASK_ZALON=3Dy
CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=3D8
CONFIG_SCSI_NCR53C8XX_MAX_TAGS=3D32
-CONFIG_SCSI_NCR53C8XX_SYNC=3D80
+CONFIG_SCSI_NCR53C8XX_SYNC=3D20
# CONFIG_SCSI_NCR53C8XX_PROFILE is not set
# CONFIG_SCSI_NCR53C8XX_IOMAPPED is not set
# CONFIG_SCSI_NCR53C8XX_SYMBIOS_COMPAT is not set
@@ -444,7 +445,7 @@
# CONFIG_HP100 is not set
# CONFIG_NET_ISA is not set
CONFIG_NET_PCI=3Dy
-# CONFIG_PCNET32 is not set
+CONFIG_PCNET32=3Dm
CONFIG_ADAPTEC_STARFIRE=3Dm
# CONFIG_AC3200 is not set
# CONFIG_APRICOT is not set
@@ -483,7 +484,7 @@
#
# Ethernet (1000 Mbit)
#
-CONFIG_ACENIC=3Dm
+# CONFIG_ACENIC is not set
# CONFIG_ACENIC_OMIT_TIGON_I is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
@@ -492,7 +493,7 @@
CONFIG_HAMACHI=3Dm
CONFIG_YELLOWFIN=3Dm
CONFIG_SK98LIN=3Dm
-# CONFIG_TIGON3 is not set
+CONFIG_TIGON3=3Dm
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
@@ -533,8 +534,8 @@
# Input core support
#
CONFIG_INPUT=3Dy
-CONFIG_INPUT_KEYBDEV=3Dm
-CONFIG_INPUT_MOUSEDEV=3Dm
+CONFIG_INPUT_KEYBDEV=3Dy
+CONFIG_INPUT_MOUSEDEV=3Dy
CONFIG_INPUT_MOUSEDEV_SCREEN_X=3D1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=3D768
# CONFIG_INPUT_JOYDEV is not set
@@ -550,7 +551,25 @@
CONFIG_SERIAL_CONSOLE=3Dy
CONFIG_SERIAL_GSC=3Dy
# CONFIG_SERIAL_EXTENDED is not set
-# CONFIG_SERIAL_NONSTANDARD is not set
+CONFIG_SERIAL_NONSTANDARD=3Dy
+# CONFIG_COMPUTONE is not set
+# CONFIG_ROCKETPORT is not set
+# CONFIG_CYCLADES is not set
+# CONFIG_DIGIEPCA is not set
+# CONFIG_DIGI is not set
+# CONFIG_ESPSERIAL is not set
+# CONFIG_MOXA_INTELLIO is not set
+# CONFIG_MOXA_SMARTIO is not set
+# CONFIG_ISI is not set
+# CONFIG_SYNCLINK is not set
+# CONFIG_SYNCLINKMP is not set
+# CONFIG_N_HDLC is not set
+# CONFIG_RISCOM8 is not set
+# CONFIG_SPECIALIX is not set
+# CONFIG_SX is not set
+# CONFIG_RIO is not set
+# CONFIG_STALDRV is not set
+CONFIG_PDC_CONSOLE=3Dy
CONFIG_UNIX98_PTYS=3Dy
CONFIG_UNIX98_PTY_COUNT=3D256
CONFIG_PRINTER=3Dy
@@ -581,7 +600,7 @@
# CONFIG_INPUT_PCIGAME is not set
# CONFIG_INPUT_CS461X is not set
# CONFIG_INPUT_EMU10K1 is not set
-# CONFIG_INPUT_SERIO is not set
+CONFIG_INPUT_SERIO=3Dy
# CONFIG_INPUT_SERPORT is not set
#
@@ -644,15 +663,14 @@
#
CONFIG_HP_SDC=3Dy
# CONFIG_HP_SDC_RTC is not set
-# CONFIG_HIL_MLC is not set
-
-#
-# Serial IO support needed for HIL keyboard and mouse support
-#
+CONFIG_HIL_MLC=3Dy
+CONFIG_HP_SDC_MLC=3Dy
#
# HIL device driver
#
+CONFIG_HIL_KBD=3Dy
+CONFIG_HIL_PTR=3Dy
#
# Multimedia devices
@@ -677,7 +695,7 @@
# CONFIG_BFS_FS is not set
CONFIG_EXT3_FS=3Dy
CONFIG_JBD=3Dy
-CONFIG_JBD_DEBUG=3Dy
+# CONFIG_JBD_DEBUG is not set
CONFIG_FAT_FS=3Dm
CONFIG_MSDOS_FS=3Dm
# CONFIG_UMSDOS_FS is not set
@@ -691,7 +709,7 @@
CONFIG_ISO9660_FS=3Dy
CONFIG_JOLIET=3Dy
# CONFIG_ZISOFS is not set
-CONFIG_JFS_FS=3Dy
+# CONFIG_JFS_FS is not set
# CONFIG_JFS_DEBUG is not set
# CONFIG_JFS_STATISTICS is not set
CONFIG_MINIX_FS=3Dm
@@ -962,7 +980,7 @@
# Kernel hacking
#
CONFIG_MAGIC_SYSRQ=3Dy
-# CONFIG_DEBUG_SPINLOCK is not set
+CONFIG_DEBUG_SPINLOCK=3Dy
#
# Library routines
Is somebody see what could be wrong (It would also help me for 2.5 with
which met the same pb a time ago)?
See you next year.
Thanks again ,
Joel
*************************************************************************=
*******
Controlez mieux votre consommation Internet...surfez Tiscali Complete...h=
ttp://tiscali.complete.be
^ permalink raw reply
* Re: mremap use-after-free [was Re: 2.5.52-mm2]
From: Andrew Morton @ 2002-12-19 18:18 UTC (permalink / raw)
To: Hugh Dickins; +Cc: lkml, linux-mm
In-Reply-To: <Pine.LNX.4.44.0212191602190.1893-100000@localhost.localdomain>
Hugh Dickins wrote:
>
> ...
> I doubt that (but may be wrong, I haven't time right now to think as
> twistedly as mremap demands).
Maybe, maybe not. Think about it - because VM_LOCKED is cleared
by slab poisoning, the chances of anyone noticing it are very small.
> The code (patently!) expects new_vma
> to be good at the end, it certainly wasn't intending to unmap it;
> but 2.5 split_vma has been through a couple of convulsions, either
> of which might have resulted in the potential for new_vma to be
> freed where before it was guaranteed to remain.
I see no "guarantees" around do_munmap() at all. The whole thing
is foul; no wonder it keeps blowing up.
It died partway into kde startup. It was in fact the first mremap
call.
> Do you know the vmas before and after, and the mremap which did this?
Breakpoint 1, move_vma (vma=0xcf1ed734, addr=1077805056, old_len=36864, new_len=204800, new_addr=1078050816) at mm/mremap.c:176
176 {
(gdb) n
183 next = find_vma_prev(mm, new_addr, &prev);
(gdb)
177 struct mm_struct * mm = vma->vm_mm;
(gdb)
180 int split = 0;
(gdb)
182 new_vma = NULL;
(gdb)
183 next = find_vma_prev(mm, new_addr, &prev);
(gdb)
184 if (next) {
(gdb) p/x next
$1 = 0xce3bee84
(gdb) p/x *next
$2 = {vm_mm = 0xcf7cc624, vm_start = 0xbffcd000, vm_end = 0xc0000000, vm_next = 0x0, vm_page_prot = {pgprot = 0x25},
vm_flags = 0x100177, vm_rb = {rb_parent = 0xcf1ed74c, rb_color = 0x1, rb_right = 0x0, rb_left = 0x0}, shared = {next = 0xce3beeac,
prev = 0xce3beeac}, vm_ops = 0x0, vm_pgoff = 0xffffffce, vm_file = 0x0, vm_private_data = 0x0}
(gdb) p prev
$3 = (struct vm_area_struct *) 0xcf1ed734
(gdb) p/x *prev
$4 = {vm_mm = 0xcf7cc624, vm_start = 0x403e0000, vm_end = 0x4041c000, vm_next = 0xce3bee84, vm_page_prot = {pgprot = 0x25},
vm_flags = 0x100073, vm_rb = {rb_parent = 0xce3be4c4, rb_color = 0x0, rb_right = 0xce3bee9c, rb_left = 0xce3be1ac}, shared = {
next = 0xcf1ed75c, prev = 0xcf1ed75c}, vm_ops = 0x0, vm_pgoff = 0x0, vm_file = 0x0, vm_private_data = 0x0}
> ...
>
> Hmmm. Am I right to suppose that all the changes above are "cleanup"
> which you couldn't resist making while you looked through this code,
> but entirely irrelevant to the bug in question?
to make the code readable so I could work on the bug, it then "accidentally"
got left in.
> If those mods above
> were right, they should be the subject of a separate patch.
well yes it would be nice to clean that code up. Like, documenting
it and working out what the locking rules are.
What does this do?
spin_lock(&mm->page_table_lock);
prev->vm_end = new_addr + new_len;
spin_unlock(&mm->page_table_lock);
and this?
spin_lock(&mm->page_table_lock);
next->vm_start = new_addr;
spin_unlock(&mm->page_table_lock);
clearly nothing. OK, but is this effectively-unlocked code safe?
> There's certainly room for cleanup there, but my preference would be
> to remove "can_vma_merge" completely, or at least its use in mremap.c,
> using its explicit tests instead. It looks like it was originally
> quite appropriate for a use or two in mmap.c, but obscurely unhelpful
> here - because in itself it is testing a bizarre asymmetric subset of
> what's needed (that subset which remained to be tested in its original
> use in mmap.c).
yes
> The problem with your changes above is, you've removed the !vma->vm_file
> tests, presumably because you noticed that can_vma_merge already tests
> !vma->vm_file. But "vma" within can_vma_merge is "prev" or "next" here:
> they are distinct tests, and you're now liable to merge an anonymous
> mapping with a private file mapping - nice if it's from /dev/zero,
> but otherwise not. Please just cut those hunks out.
ok
> ...
> > - do_munmap(current->mm, addr, old_len);
> > -
>
> Anguished cry! There was careful manipulation of VM_ACCOUNT before and
> after do_munmap, now you've for no reason moved do_munmap down outside.
How do we know that *vma was not altered by the do_munmap() call?
With this change, nobody will touch any locally-cached vma*'s from
the do_munmap() right through to syscall exit.
^ permalink raw reply
* Re: 'D' processes on a healthy system?
From: martin f krafft @ 2002-12-19 18:23 UTC (permalink / raw)
To: Alan Cox; +Cc: Linux Kernel Mailing List
In-Reply-To: <1040319832.28973.4.camel@irongate.swansea.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 2820 bytes --]
[please continue to CC me]
Thank you for your reply:
also sprach Alan Cox <alan@lxorguk.ukuu.org.uk> [2002.12.19.1843 +0100]:
> Your disk is too slow for the work being asked of it, thats all.
> Eventually it'll get there
Alan, I am in no position to doubt what you say, but I can't imagine
that. Sure, maybe the 5,400 RPM one, but not the 7,200 RPM one.
The reason why I am saying this is twofold and empirical:
- When the above occurs, the system in question might not be doing
anything. My example with /usr/sbin/sendmail in a while loop is
hardcore stresstesting. I have had the problem with no users on
the system, no requests being served by the servers (ifconfig
down), just two ssh connections, one displaying top, the other
opening a Maildir folder of 1,000 messages with mutt. I really
don't (want to) believe that a system with these specs can't
handle that.
- I have another system with exactly the same specs (AMD K6 Duron
1.2 GHz, 512 MB, 7,200 HDD) that is happy doing all of the
following at the same time
* compiling a kernel
* streaming local MP3s to three other computers
* being used intensely through X (it's my main computer).
In fact, to verify this, I told the system to also check and
update tripwire while I was additionally running the slocate
updater. Other than the interactive use, these activities are
very tough on the disk, and yet I see no 'D' processes.
In any case, loading up mutt on a Maildir folder of 1,000 messages
should not take seven Minutes. If it does, there must be heavy usage
of the disk from another source. If top doesn't show anything, what
other tool could I use to see what processes are accessing the
harddrive? Is there something like a disk monitor for Linux, which
registers every request to the HDD like there is for Windoze
(http://www.sysinternals.com/ntw2k/freeware/diskmon.shtml)?
> > My laptop, which is running Debian testing/unstable is not showing
> > this behaviour, and its load goes far higher at times. I also run
> > various other servers, partially on P5-120 systems, vanilla 2.4.xx
> > kernels and Debian testing, and there are no such problems there.
>
> sendmail tuning ?
postfix... but no. All my machines have identical postfix
configurations, and, as mentioned above, the problem is not only
triggered when postfix is active...
Thank you for your time!
[please continue to CC me]
--
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, admin, and user
`. `'`
`- Debian - when you have better things to do than fixing a system
NOTE: The pgp.net keyservers and their mirrors are broken!
Get my key here: http://people.debian.org/~madduck/gpg/330c4a75.asc
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Support for Arctic platform (405LP based))
From: Tom Rini @ 2002-12-19 18:17 UTC (permalink / raw)
To: Cort Dougan; +Cc: Paul Mackerras, linuxppc-embedded
In-Reply-To: <20021219180609.GD1048@host109.name>
On Thu, Dec 19, 2002 at 11:06:09AM -0700, Cort Dougan wrote:
> } But regardless of all of that, there's nothing related to this being a
> } 'marcelo' tree or not as you can't pick and choose bk csets without
> } everything preceeding it. Ideally we can get to the point of not really
> } needing a seperate tree like 2.2 is (which could go if someone wants to
> } sit down and think about the LongTrail-specific changes in there).
>
> There's a great advantage to it being based on Marcelo's tree. I can pull
> in several projects that I need along with the PPC changes I need into my
> own tree. I think that would help a lot of people out.
>
> In fact, it should help merging with Marcelo a great deal. You can easily
> pull in main-line changes.
I'll conceed the first part since I know there's at least a few external
projects using BK, and a few that aren't, and so on.
I'm not convinced about merging main-line changes as that only works if
everyonce consistently uses a seperate tree and merges into that. Just
like we don't have Linus pulling directly from linuxppc-2.5, Marcelo
wouldn't pull from linuxppc-2.4, and right now Paul ends up having to
pick and move things around (even I've fallen out of the habit of having
another 'working' tree for more direct movement, bad me).
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: mremap use-after-free [was Re: 2.5.52-mm2]
From: Andrew Morton @ 2002-12-19 18:18 UTC (permalink / raw)
To: Hugh Dickins; +Cc: lkml, linux-mm
In-Reply-To: <Pine.LNX.4.44.0212191602190.1893-100000@localhost.localdomain>
Hugh Dickins wrote:
>
> ...
> I doubt that (but may be wrong, I haven't time right now to think as
> twistedly as mremap demands).
Maybe, maybe not. Think about it - because VM_LOCKED is cleared
by slab poisoning, the chances of anyone noticing it are very small.
> The code (patently!) expects new_vma
> to be good at the end, it certainly wasn't intending to unmap it;
> but 2.5 split_vma has been through a couple of convulsions, either
> of which might have resulted in the potential for new_vma to be
> freed where before it was guaranteed to remain.
I see no "guarantees" around do_munmap() at all. The whole thing
is foul; no wonder it keeps blowing up.
It died partway into kde startup. It was in fact the first mremap
call.
> Do you know the vmas before and after, and the mremap which did this?
Breakpoint 1, move_vma (vma=0xcf1ed734, addr=1077805056, old_len=36864, new_len=204800, new_addr=1078050816) at mm/mremap.c:176
176 {
(gdb) n
183 next = find_vma_prev(mm, new_addr, &prev);
(gdb)
177 struct mm_struct * mm = vma->vm_mm;
(gdb)
180 int split = 0;
(gdb)
182 new_vma = NULL;
(gdb)
183 next = find_vma_prev(mm, new_addr, &prev);
(gdb)
184 if (next) {
(gdb) p/x next
$1 = 0xce3bee84
(gdb) p/x *next
$2 = {vm_mm = 0xcf7cc624, vm_start = 0xbffcd000, vm_end = 0xc0000000, vm_next = 0x0, vm_page_prot = {pgprot = 0x25},
vm_flags = 0x100177, vm_rb = {rb_parent = 0xcf1ed74c, rb_color = 0x1, rb_right = 0x0, rb_left = 0x0}, shared = {next = 0xce3beeac,
prev = 0xce3beeac}, vm_ops = 0x0, vm_pgoff = 0xffffffce, vm_file = 0x0, vm_private_data = 0x0}
(gdb) p prev
$3 = (struct vm_area_struct *) 0xcf1ed734
(gdb) p/x *prev
$4 = {vm_mm = 0xcf7cc624, vm_start = 0x403e0000, vm_end = 0x4041c000, vm_next = 0xce3bee84, vm_page_prot = {pgprot = 0x25},
vm_flags = 0x100073, vm_rb = {rb_parent = 0xce3be4c4, rb_color = 0x0, rb_right = 0xce3bee9c, rb_left = 0xce3be1ac}, shared = {
next = 0xcf1ed75c, prev = 0xcf1ed75c}, vm_ops = 0x0, vm_pgoff = 0x0, vm_file = 0x0, vm_private_data = 0x0}
> ...
>
> Hmmm. Am I right to suppose that all the changes above are "cleanup"
> which you couldn't resist making while you looked through this code,
> but entirely irrelevant to the bug in question?
to make the code readable so I could work on the bug, it then "accidentally"
got left in.
> If those mods above
> were right, they should be the subject of a separate patch.
well yes it would be nice to clean that code up. Like, documenting
it and working out what the locking rules are.
What does this do?
spin_lock(&mm->page_table_lock);
prev->vm_end = new_addr + new_len;
spin_unlock(&mm->page_table_lock);
and this?
spin_lock(&mm->page_table_lock);
next->vm_start = new_addr;
spin_unlock(&mm->page_table_lock);
clearly nothing. OK, but is this effectively-unlocked code safe?
> There's certainly room for cleanup there, but my preference would be
> to remove "can_vma_merge" completely, or at least its use in mremap.c,
> using its explicit tests instead. It looks like it was originally
> quite appropriate for a use or two in mmap.c, but obscurely unhelpful
> here - because in itself it is testing a bizarre asymmetric subset of
> what's needed (that subset which remained to be tested in its original
> use in mmap.c).
yes
> The problem with your changes above is, you've removed the !vma->vm_file
> tests, presumably because you noticed that can_vma_merge already tests
> !vma->vm_file. But "vma" within can_vma_merge is "prev" or "next" here:
> they are distinct tests, and you're now liable to merge an anonymous
> mapping with a private file mapping - nice if it's from /dev/zero,
> but otherwise not. Please just cut those hunks out.
ok
> ...
> > - do_munmap(current->mm, addr, old_len);
> > -
>
> Anguished cry! There was careful manipulation of VM_ACCOUNT before and
> after do_munmap, now you've for no reason moved do_munmap down outside.
How do we know that *vma was not altered by the do_munmap() call?
With this change, nobody will touch any locally-cached vma*'s from
the do_munmap() right through to syscall exit.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply
* Re: [PATCH/RFC] New module refcounting for net_proto_family
From: Max Krasnyansky @ 2002-12-19 16:05 UTC (permalink / raw)
To: linux-kernel; +Cc: davem
In-Reply-To: <1040225146.1873.21.camel@localhost>
Hmm, no replies. Nobody is interested in this or what ?
I want to get this fixed otherwise I can't fix Bluetooth module
refcounting.
Max
On Wed, 2002-12-18 at 07:25, Max Krasnyansky wrote:
> Hi Folks,
>
> It seems that new module code is going to stay with us at least for a
> while :).
> So it's probably time to start fixing old interfaces to use new
> refcounting scheme.
>
> Here is a patch for sock_create() and stuff that uses net_proto_family
> interface. Tested with modified af_bluetooth.c and seems to work fine.
> Other families are unaffected for now because their owner field == NULL.
>
> If people are ok with this aproach I will also fix af_unix and other
> families and push all fixes into my BK tree.
>
> (URL in case if my mailer messed up spaces
> http://bluez.sourceforge.net/patches/npf_refcnt_patch-2.5.52.gz)
>
>
> # This is a BitKeeper generated patch for the following project:
> # Project Name: Linux kernel tree
> # This patch format is intended for GNU patch command version 2.5 or
> higher.
> # This patch includes the following deltas:
> # ChangeSet 1.888 -> 1.889
> # net/socket.c 1.39 -> 1.40
> # include/linux/net.h 1.7 -> 1.8
> #
> # The following is the BitKeeper ChangeSet Log
> # --------------------------------------------
> # 02/12/17 maxk@qualcomm.com 1.889
> # Convert generic socket code to new module refcounting.
> # --------------------------------------------
> #
> diff -Nru a/include/linux/net.h b/include/linux/net.h
> --- a/include/linux/net.h Tue Dec 17 20:02:04 2002
> +++ b/include/linux/net.h Tue Dec 17 20:02:04 2002
> @@ -76,6 +76,8 @@
>
> short type;
> unsigned char passcred;
> +
> + struct module *owner;
> };
>
> struct scm_cookie;
> @@ -124,6 +126,8 @@
> short authentication;
> short encryption;
> short encrypt_net;
> +
> + struct module *owner;
> };
>
> struct net_proto
> diff -Nru a/net/socket.c b/net/socket.c
> --- a/net/socket.c Tue Dec 17 20:02:04 2002
> +++ b/net/socket.c Tue Dec 17 20:02:04 2002
> @@ -470,6 +470,8 @@
>
> sock = SOCKET_I(inode);
>
> + sock->owner = NULL;
> +
> inode->i_mode = S_IFSOCK|S_IRWXUGO;
> inode->i_sock = 1;
> inode->i_uid = current->fsuid;
> @@ -517,6 +519,8 @@
> return;
> }
> sock->file=NULL;
> +
> + module_put(sock->owner);
> }
>
> static int __sock_sendmsg(struct kiocb *iocb, struct socket *sock,
> struct msghdr *msg, int size)
> @@ -964,8 +968,9 @@
>
> int sock_create(int family, int type, int protocol, struct socket
> **res)
> {
> - int i;
> + struct net_proto_family *npf;
> struct socket *sock;
> + int err;
>
> /*
> * Check protocol is in range
> @@ -990,14 +995,8 @@
> }
>
> #if defined(CONFIG_KMOD) && defined(CONFIG_NET)
> - /* Attempt to load a protocol module if the find failed.
> - *
> - * 12/09/1996 Marcin: But! this makes REALLY only sense, if the user
> - * requested real, full-featured networking support upon
> configuration.
> - * Otherwise module support will break!
> - */
> - if (net_families[family]==NULL)
> - {
> + /* Attempt to load a protocol module if the find failed. */
> + if (net_families[family]==NULL) {
> char module_name[30];
> sprintf(module_name,"net-pf-%d",family);
> request_module(module_name);
> @@ -1005,29 +1004,31 @@
> #endif
>
> net_family_read_lock();
> - if (net_families[family] == NULL) {
> - i = -EAFNOSUPPORT;
> +
> + npf = net_families[family];
> + if (!npf || !try_module_get(npf->owner)) {
> + err = -EAFNOSUPPORT;
> goto out;
> }
> +
> + /*
> + * Allocate the socket and allow the family to set things up. if
> + * the protocol is 0, the family is instructed to select an
> appropriate
> + * default.
> + */
>
> -/*
> - * Allocate the socket and allow the family to set things up. if
> - * the protocol is 0, the family is instructed to select an appropriate
> - * default.
> - */
> -
> - if (!(sock = sock_alloc()))
> - {
> + sock = sock_alloc();
> + if (!sock) {
> printk(KERN_WARNING "socket: no more sockets\n");
> - i = -ENFILE; /* Not exactly a match, but its the
> + err = -ENFILE; /* Not exactly a match, but its the
> closest posix thing */
> goto out;
> }
>
> sock->type = type;
> + sock->owner = npf->owner;
>
> - if ((i = net_families[family]->create(sock, protocol)) < 0)
> - {
> + if ((err = npf->create(sock, protocol)) < 0) {
> sock_release(sock);
> goto out;
> }
> @@ -1036,7 +1037,7 @@
>
> out:
> net_family_read_unlock();
> - return i;
> + return err;
> }
>
> asmlinkage long sys_socket(int family, int type, int protocol)
> @@ -1201,6 +1202,9 @@
> newsock->type = sock->type;
> newsock->ops = sock->ops;
>
> + try_module_get(sock->owner);
> + newsock->owner = sock->owner;
> +
> err = sock->ops->accept(sock, newsock, sock->file->f_flags);
> if (err < 0)
> goto out_release;
--
Max Krasnyansky <maxk@qualcomm.com>
Qualcomm
^ permalink raw reply
* Linux kernel multimedia experiments
From: Miguel Freitas @ 2002-12-19 18:35 UTC (permalink / raw)
To: xine-dev; +Cc: linux-kernel
Hi folks,
This is cross post on xine-devel and linux-kernel lists.
Some xine guys are aware of my experiments comparing multimedia
performance in latest kernels (2.4.x and 2.5.x), so instead of preparing
a lengthy email i've just put a page with it.
At this text i present a dummy multimedia simulator which pretends to be
a video player and measures the number of frames that would be dropped
(and also the mean latency). I used ConTest script to generate the
background loads and take some interesting results.
I hope this will be useful not only to improve xine but also kernel
support in general for any other multimedia player.
http://cambuca.ldhs.cetuc.puc-rio.br/~miguel/multimedia_sim/
Any comments, flames, etc are apreciated (that is, not the flames :)
l-k people, please cc me, i'm not subscribed.
regards,
Miguel Freitas
^ permalink raw reply
* Re: mapping back to 36 bit physical
From: Tom Rini @ 2002-12-19 18:30 UTC (permalink / raw)
To: Claudia Salzberg; +Cc: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.33.0212181358270.23138-100000@grandmaster.protagonist.org>
On Wed, Dec 18, 2002 at 02:07:45PM +0600, Claudia Salzberg wrote:
> Greetings.
> How does one go about aquiring the 36-bit physical address on a 440XX if
> you have the corresponding va from an ioremap (when your driver is not
> the one that did the ioremap so that you don't have the pa saved)? ?I see
> that ioremap does support 36-bit I/O mapping but _va and _pa only play
> with unsigned long's. ?So does iopa. ?So do the virt_to_* 's I was able
> to find. ?Also, does anyone have plans for incorporating memory access
> hooks above 4GB address space?
Erm. Have you looked at the code in the linuxppc_2_4_devel tree? I
believe all of these issues have already been addressed.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [PATCH] An O1, nonrecursive ID allocator for Posix timers
From: george anzinger @ 2002-12-19 18:38 UTC (permalink / raw)
To: Joe Korty; +Cc: akpm, torvalds, jim.houston, linux-kernel
In-Reply-To: <200212191408.OAA07548@rudolph.ccur.com>
Joe Korty wrote:
>
> >> This is a drop-in replacement for the ID allocator that Jim Houston
> >> wrote to support posix timers. [...]
> >
> > A few comments:
> >
> > I have found that the locking needs on lookup require that
> > the object be locked before the id-look-up is unlocked.
> > With out this it is possible to find an object and have it
> > "removed" by another prior to getting it locked. This is
> > why, in my version, the lock is exported.
>
> Hi George,
> Ouch. I completely missed this API flaw. Good catch.
>
> Some ideas: rather than exporting the lock, we could replace
>
> int id2ptr_lookup(...)
>
> with a
>
> int id2ptr_get(...)
> void id2ptr_put(...)
>
> pair. id2ptr_get() would do the old id2ptr_lookup semantics plus
> bump a use-count on the ID. id2ptr_put() would decrement the
> use-count and delete the ID if the use-count became zero.
> id2ptr_new() and id2ptr_remove() would need similar use-count
> adjustments.
>
> Or, a callback capability could be added to the API. The callback
> function would be registered by a new argument to id2ptr_init() and
> called by id2ptr_lookup() before it dropped the lock. In this case,
> we would change id2ptr_init to look like:
>
> void id2ptr_init(struct id *id, int min_wrap, void (*func)(void *data));
>
> where the callback function is defined to take one argument, the
> (void *) value attached to the ID. You (&Jim) would use this
> callback mechanism to provide a function that would lock down the
> data structure represented by the (void *) passed-in argument.
This might work, but consider this: How might one remove an
ID and what it points at. It needs to disappear atomically
or some cpu will end up with a valid ID that points at a
structure that has been returned. One way of doing this
would be to do the id look up to get the structure and then,
under the same lock, do the id_remove.
The way I do it in the posix_timers is to look up, under the
look up, lock the structure, unlock the look up, flag the
structure as "gone" and then go about removing it. This
way, another cpu will still find it but will also find a
"gone" flag, which must be checked on each lookup. As I
write this, I realize that I would prefer the first way of
doing things.
Why not remove all locking from the id2ptr code and let the
user take care of it? You might have to export one
additional function which "prepares to allocate an id" so
you can call the slab code without being locked.
>
> > Another issue with locking is the irq required or not thing. Irq
> > locking is VERY expensive and getting more so as cpu speeds go up and
> > I/O speeds stay the same. If it is not needed, it is best not to use
> > it. Again, exporting the locking to the caller seems the best answer.
>
> IIRC, it is the spin_lock_* part that is expensive, not the *_irq part.
> Interrupt locking is merely setting/clearing a bit in the EFLAGS
> register, which (if the i386 follows the PowerPC pattern, the CPU I
> am most familiar with), is slower than setting/clearing a bit in a
> general purpose register but not that much slower.
I don't believe this is so. The interrupt on/off change
needs to sync with the I/O system, to avoid in-flight stuff,
and so introduces stalls. I suspect that sometimes it also
needs to flush the pipeline, but I am not that up on those
sorts of details. I have, however, seen the results of some
timing studies done on the run_timer_list code which showed
that the whole of the run_timer_list function was shorter
that the interrupt off instruction. I think this was on a
1.3GHZ PIII. I know this was an issue on the PARISC (the
last machine I worked on) also, so I think it is common to
all modern machines that run the cpu faster and async to the
I/O bus.
>
> On the other hand, the bus locking of spin_lock_* stops all other cpus
> and dma traffic from accessing the bus for the interval of the lock,
No, this is not true. The lock is only for the access time
of the spinlock byte. If spinning, the lock will be taken
quite often, but even then there are other unlocked
instructions in the loop.
> this can be devastating on systems with large numbers of cpus and/or
> high IO traffic. However, this is not a problem on all architectures.
> The PowerPC, for one, provides a pair of instructions which one can
> implement spin_lock without utilizing a bus lock. I look forward to
> the day Intel adds a similiar pair of instructions to their ISA.
>
> In any case, all of the ID user interfaces have exactly one lock and
> one unlock along their most commonly executed patch. One can't get
> any better than that without resorting to architecture tricks like
> assuming reads and writes go out to memory in a certain order.
>
> > I would much prefer to return memory on release. In my code
> > I currently only return the leaf nodes, but I consider this
> > something to be fixed rather than a feature.
>
> I have an adjustment in mind which would allow the O(1) ID allocator
> to return excess memory. Each ID block would do its own little free
> list and those lists in turn would be chained together. That way it
> would be easy to kfree() an ID block once it became completely full
> of freed IDs.
>
> > While the code is order 1 it does do a divide which, as I
> > understand it, is rather expensive (risc machines do them
> > with subroutines). It is rather easy to eliminate the
> > recursion in an radix-tree AND avoid the div at the same
> > time.
>
> I will make this change. Thanks.
>
> > I would consider moving the "ctr" member to the root of the
> > tree and using the same one for all allocations. I may be
> > wrong here, but I think it gives a better cycle time for the
> > bits used.
>
> A random value works just as well (actually a little better) than a
> counter that is not unique to each ID data structure. I may go the
> (pseudo) random route & eliminate the ctr altogether. Or I may be
> able to find some unused bits in the ID data structure where I can
> pack it in.
I have not looked at random number generators, but I assumed
a counter would be faster. I could be wrong here...
>
> Thanks for your feedback,
> Joe
--
George Anzinger george@mvista.com
High-res-timers:
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml
^ permalink raw reply
* Re: 'D' processes on a healthy system?
From: Alan Cox @ 2002-12-19 19:27 UTC (permalink / raw)
To: martin f krafft; +Cc: Linux Kernel Mailing List
In-Reply-To: <20021219182359.GA29366@fishbowl.madduck.net>
On Thu, 2002-12-19 at 18:23, martin f krafft wrote:
> [please continue to CC me]
>
> Thank you for your reply:
>
> also sprach Alan Cox <alan@lxorguk.ukuu.org.uk> [2002.12.19.1843 +0100]:
> > Your disk is too slow for the work being asked of it, thats all.
> > Eventually it'll get there
>
> Alan, I am in no position to doubt what you say, but I can't imagine
> that. Sure, maybe the 5,400 RPM one, but not the 7,200 RPM one.
Its more to do with the controller and configuration. Eg if your disk
isnt in DMA mode it'll certainly show up
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: billyrose @ 2002-12-19 18:46 UTC (permalink / raw)
To: bart; +Cc: root, linux-kernel
> Not true. A ret(urn) is (sort of) equivalent to 'pop %eip'. The above
> code would actually jump to address 0xfffff000, but probably be slow
> since it confuses the branch prediction.
>
>
>Bart
that being the case, then the original code that Linus put forth:
pushl $0xfffff000
call *(%esp)
add $4,%esp
would be the way to go as it is highly readable. actually, the code at
0xfffff000 could issue a ret $4 and eliminate the add after the call.
^ permalink raw reply
* Re: [PATCH/RFC] New module refcounting for net_proto_family
From: Alan Cox @ 2002-12-19 19:28 UTC (permalink / raw)
To: Max Krasnyansky; +Cc: Linux Kernel Mailing List, davem
In-Reply-To: <1040313919.2650.31.camel@localhost>
On Thu, 2002-12-19 at 16:05, Max Krasnyansky wrote:
> Hmm, no replies. Nobody is interested in this or what ?
> I want to get this fixed otherwise I can't fix Bluetooth module
> refcounting.
Looks good to me, but its christmas so I wouldnt expect much to happen
till the new year
^ permalink raw reply
* Re: difference between 8139D and 8139d(l)?
From: Jeff Garzik @ 2002-12-19 18:46 UTC (permalink / raw)
To: Samium Gromoff; +Cc: linux-kernel
In-Reply-To: <200212191204.gBJC4A8Q001384@ibe.miee.ru>
Samium Gromoff wrote:
> Is there any major difference between both?
Linux's perspective? Not really...
^ permalink raw reply
* Re: Dedicated kernel bug database
From: Dave Jones @ 2002-12-19 18:49 UTC (permalink / raw)
To: Eli Carter
Cc: John Bradford, linux-kernel, alan, lm, lm, torvalds, vonbrand,
akpm
In-Reply-To: <3E020660.9020507@inet.com>
On Thu, Dec 19, 2002 at 11:48:16AM -0600, Eli Carter wrote:
> >Also, we could have a non-web interface, (telnet or gopher to the bug
> >DB, or control it by E-Mail).
> Can you interface with bugzilla's database backend maybe? It seems like
> refactoring bugzilla might be better?
It's an annoyance to me that the current bugzilla we use can only
do 1 way email. Ie, I receive email when things change, but I can't
reply to that mail and have my comments auto-added.
Other bugzillas can do this, so I think either some switch needs
to be enabled, or theres some extension not present.
(I'm a complete bugzilla weenie, and no nothing about how its set up).
> >It could warn the user if they attach an un-decoded oops that their
> >bug report isn't as useful as it could be, and if they mention a
> >distribution kernel version, that it's not a tree that the developers
> >will necessarily be familiar with
> Perhaps a more generalized hook into bugzilla for 'validating' a bug
> report, then code specific validators for kernel work?
Its a nice idea, but I think it's a lot of effort to get it right,
when a human can look at the dump, realise its not decoded, and
send a request back in hardly any time at all.
I also don't trust things like this where if something goes wrong,
we could lose the bug report. People are also more likely to ping-pong
,argue or "how do I..." with a human than they are with an automated robot.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
^ permalink raw reply
* Re: 'D' processes on a healthy system?
From: martin f krafft @ 2002-12-19 18:51 UTC (permalink / raw)
To: Alan Cox; +Cc: Linux Kernel Mailing List
In-Reply-To: <1040326031.28973.23.camel@irongate.swansea.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 691 bytes --]
also sprach Alan Cox <alan@lxorguk.ukuu.org.uk> [2002.12.19.2027 +0100]:
> Its more to do with the controller and configuration. Eg if your disk
> isnt in DMA mode it'll certainly show up
Interesting. The 500 MHz system wasn't in DMA mode (and I though I had
it there). I'll continue monitoring it now that I turned it on.
Thank you for your help so far, Alan!
--
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, admin, and user
`. `'`
`- Debian - when you have better things to do than fixing a system
NOTE: The pgp.net keyservers and their mirrors are broken!
Get my key here: http://people.debian.org/~madduck/gpg/330c4a75.asc
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2.4] : donauboe IrDA driver (resend)
From: Jean Tourrilhes @ 2002-12-19 18:56 UTC (permalink / raw)
To: Dumitru Ciobarcianu, James McKenzie, Christian Gennerat,
Martin Lucina
Cc: Marcelo Tosatti, Linux kernel mailing list
In-Reply-To: <1040310314.1225.9.camel@localhost.localdomain>
On Thu, Dec 19, 2002 at 05:05:16PM +0200, Dumitru Ciobarcianu wrote:
>
> Hello,
>
> This module does not load all the time for me.
> If I do an "modprobe donauboe" it gives something like:
>
[...]
>
> If I try a few more times it will finally load...
>
> The kernel is 2.4.20.0.pp.9 (RH rawhide kernel - 2.4.20-ac1 based) +
> acpi20021205 . I don't know why lspci shows "Toshiba Tecra 8100". The
> machine is an Toshiba Satellite Pro 4320.
As I don't have this hardware, I fully depend on people trying
the code to know if it works or not. This driver has been for 6 months
in kernel 2.5.X and on my web page (and advertised on the IrDA mailing
list), and it's only today that I get the first negative bug report.
I really wonder what I do wrong. Maybe I should throw untested
code straight in 2.4.X, like other people do, that may bring the bug
report faster.
From my casual look at the driver code, it looks like the
hardware self test is failing. There is a way to disable this self
test via module parameter "do_probe". Maybe you want to check that.
Also, would you mind sending this bug report to all three
maintainers of the driver ? Also : would you mind sending the log
output of the old toshoboe driver (assuming it works - does it ?).
Have fun...
Jean
P.S. : Full e-mail is at :
http://marc.theaimsgroup.com/?l=linux-kernel&m=104031025012364&w=2
^ permalink raw reply
* Re: Problem with IP-Pools
From: Markus Schaber @ 2002-12-19 18:48 UTC (permalink / raw)
To: netfilter-devel; +Cc: gandalf
In-Reply-To: <20021219162444.45febd6d.markus.schaber@student.uni-ulm.de>
[-- Attachment #1: Type: text/plain, Size: 26503 bytes --]
Hi,
Sorry, it seems that I attached the wrong error message, the correct one
follows below:
make -C kernel CFLAGS="-D__KERNEL__
-I/usr/src/pool/linux-2.4.20/include -Wall -Wstrict-prototypes
-Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer
-pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS
-include /usr/src/pool/linux-2.4.20/include/linux/modversions.h"
MAKING_MODULES=1 modules
make[1]: Entering directory `/usr/src/pool/linux-2.4.20/kernel'
make[1]: Für das Target »modules« gibt es nichts zu tun.
make[1]: Leaving directory `/usr/src/pool/linux-2.4.20/kernel'
make -C drivers CFLAGS="-D__KERNEL__
-I/usr/src/pool/linux-2.4.20/include -Wall -Wstrict-prototypes
-Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer
-pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS
-include /usr/src/pool/linux-2.4.20/include/linux/modversions.h"
MAKING_MODULES=1 modules
make[1]: Entering directory `/usr/src/pool/linux-2.4.20/drivers'
make -C block modules
make[2]: Entering directory `/usr/src/pool/linux-2.4.20/drivers/block'
make[2]: Für das Target »modules« gibt es nichts zu tun.
make[2]: Leaving directory `/usr/src/pool/linux-2.4.20/drivers/block'
make -C cdrom modules
make[2]: Entering directory `/usr/src/pool/linux-2.4.20/drivers/cdrom'
make[2]: Für das Target »modules« gibt es nichts zu tun.
make[2]: Leaving directory `/usr/src/pool/linux-2.4.20/drivers/cdrom'
make -C char modules
make[2]: Entering directory `/usr/src/pool/linux-2.4.20/drivers/char'
make -C drm modules
make[3]: Entering directory
`/usr/src/pool/linux-2.4.20/drivers/char/drm'
make[3]: Für das Target »modules« gibt es nichts zu tun.
make[3]: Leaving directory `/usr/src/pool/linux-2.4.20/drivers/char/drm'
make[2]: Leaving directory `/usr/src/pool/linux-2.4.20/drivers/char'
make -C hotplug modules
make[2]: Entering directory `/usr/src/pool/linux-2.4.20/drivers/hotplug'
make[2]: Für das Target »modules« gibt es nichts zu tun.
make[2]: Leaving directory `/usr/src/pool/linux-2.4.20/drivers/hotplug'
make -C ide modules
make[2]: Entering directory `/usr/src/pool/linux-2.4.20/drivers/ide'
make[2]: Für das Target »modules« gibt es nichts zu tun.
make[2]: Leaving directory `/usr/src/pool/linux-2.4.20/drivers/ide'
make -C media modules
make[2]: Entering directory `/usr/src/pool/linux-2.4.20/drivers/media'
make -C radio modules
make[3]: Entering directory
`/usr/src/pool/linux-2.4.20/drivers/media/radio'
make[3]: Für das Target »modules« gibt es nichts zu tun.
make[3]: Leaving directory
`/usr/src/pool/linux-2.4.20/drivers/media/radio'
make -C video modules
make[3]: Entering directory
`/usr/src/pool/linux-2.4.20/drivers/media/video'
make[3]: Für das Target »modules« gibt es nichts zu tun.
make[3]: Leaving directory
`/usr/src/pool/linux-2.4.20/drivers/media/video'
make[2]: Leaving directory `/usr/src/pool/linux-2.4.20/drivers/media'
make -C misc modules
make[2]: Entering directory `/usr/src/pool/linux-2.4.20/drivers/misc'
make[2]: Für das Target »modules« gibt es nichts zu tun.
make[2]: Leaving directory `/usr/src/pool/linux-2.4.20/drivers/misc'
make -C net modules
make[2]: Entering directory `/usr/src/pool/linux-2.4.20/drivers/net'
make[2]: Für das Target »modules« gibt es nichts zu tun.
make[2]: Leaving directory `/usr/src/pool/linux-2.4.20/drivers/net'
make -C parport modules
make[2]: Entering directory `/usr/src/pool/linux-2.4.20/drivers/parport'
make[2]: Für das Target »modules« gibt es nichts zu tun.
make[2]: Leaving directory `/usr/src/pool/linux-2.4.20/drivers/parport'
make -C scsi modules
make[2]: Entering directory `/usr/src/pool/linux-2.4.20/drivers/scsi'
make[2]: Für das Target »modules« gibt es nichts zu tun.
make[2]: Leaving directory `/usr/src/pool/linux-2.4.20/drivers/scsi'
make -C sound modules
make[2]: Entering directory `/usr/src/pool/linux-2.4.20/drivers/sound'
make[2]: Für das Target »modules« gibt es nichts zu tun.
make[2]: Leaving directory `/usr/src/pool/linux-2.4.20/drivers/sound'
make -C usb modules
make[2]: Entering directory `/usr/src/pool/linux-2.4.20/drivers/usb'
make[2]: Für das Target »modules« gibt es nichts zu tun.
make[2]: Leaving directory `/usr/src/pool/linux-2.4.20/drivers/usb'
make -C video modules
make[2]: Entering directory `/usr/src/pool/linux-2.4.20/drivers/video'
make[2]: Für das Target »modules« gibt es nichts zu tun.
make[2]: Leaving directory `/usr/src/pool/linux-2.4.20/drivers/video'
make[1]: Leaving directory `/usr/src/pool/linux-2.4.20/drivers'
make -C mm CFLAGS="-D__KERNEL__ -I/usr/src/pool/linux-2.4.20/include
-Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing
-fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2
-march=i686 -DMODULE -DMODVERSIONS -include
/usr/src/pool/linux-2.4.20/include/linux/modversions.h" MAKING_MODULES=1
modules
make[1]: Entering directory `/usr/src/pool/linux-2.4.20/mm'
make[1]: Für das Target »modules« gibt es nichts zu tun.
make[1]: Leaving directory `/usr/src/pool/linux-2.4.20/mm'
make -C fs CFLAGS="-D__KERNEL__ -I/usr/src/pool/linux-2.4.20/include
-Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing
-fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2
-march=i686 -DMODULE -DMODVERSIONS -include
/usr/src/pool/linux-2.4.20/include/linux/modversions.h" MAKING_MODULES=1
modules
make[1]: Entering directory `/usr/src/pool/linux-2.4.20/fs'
make[1]: Für das Target »modules« gibt es nichts zu tun.
make[1]: Leaving directory `/usr/src/pool/linux-2.4.20/fs'
make -C net CFLAGS="-D__KERNEL__ -I/usr/src/pool/linux-2.4.20/include
-Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing
-fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2
-march=i686 -DMODULE -DMODVERSIONS -include
/usr/src/pool/linux-2.4.20/include/linux/modversions.h" MAKING_MODULES=1
modules
make[1]: Entering directory `/usr/src/pool/linux-2.4.20/net'
make -C core modules
make[2]: Entering directory `/usr/src/pool/linux-2.4.20/net/core'
make[2]: Für das Target »modules« gibt es nichts zu tun.
make[2]: Leaving directory `/usr/src/pool/linux-2.4.20/net/core'
make -C ipv4 modules
make[2]: Entering directory `/usr/src/pool/linux-2.4.20/net/ipv4'
make[2]: Für das Target »modules« gibt es nichts zu tun.
make[2]: Leaving directory `/usr/src/pool/linux-2.4.20/net/ipv4'
make -C ipv4/netfilter modules
make[2]: Entering directory
`/usr/src/pool/linux-2.4.20/net/ipv4/netfilter'
make[2]: Zirkuläre Datei
/usr/src/pool/linux-2.4.20/include/linux/netfilter_ipv4/ip_conntrack_he
lper.h <-
/usr/src/pool/linux-2.4.20/include/linux/netfilter_ipv4/ip_conntrack.h
Abhängigkeit wird nicht verwendet.
ld -m elf_i386 -r -o ip_conntrack.o ip_conntrack_standalone.o
ip_conntrack_core.o ip_conntrack_proto_generic.o
ip_conntrack_proto_tcp.o ip_conntrack_proto_udp.o
ip_conntrack_proto_icmp.o
ld -m elf_i386 -r -o iptable_nat.o ip_nat_standalone.o ip_nat_rule.o
ip_nat_core.o ip_nat_helper.o ip_nat_proto_unknown.o ip_nat_proto_tcp.o
ip_nat_proto_udp.o ip_nat_proto_icmp.o
gcc -D__KERNEL__ -I/usr/src/pool/linux-2.4.20/include -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common
-fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686
-DMODULE -DMODVERSIONS -include
/usr/src/pool/linux-2.4.20/include/linux/modversions.h -nostdinc
-iwithprefix include -DKBUILD_BASENAME=ip_pool -DEXPORT_SYMTAB -c
ip_pool.c
ip_pool.c:40: linux/netfilter_ipv4/ip_pool.h: No such file or directory
ip_pool.c:65: warning: `struct ip_pool' declared inside parameter list
ip_pool.c:65: warning: its scope is only this definition or declaration,
which is probably not what you want.
ip_pool.c: In function `ip_pool_testip_R706d4544':
ip_pool.c:69: dereferencing pointer to incomplete type
ip_pool.c:70: dereferencing pointer to incomplete type
ip_pool.c:67: warning: `res' might be used uninitialized in this
function
ip_pool.c: At top level:
ip_pool.c:85: warning: `struct ip_pool' declared inside parameter list
ip_pool.c: In function `ip_pool_addip_kernel_R7faca846':
ip_pool.c:87: dereferencing pointer to incomplete type
ip_pool.c:92: dereferencing pointer to incomplete type
ip_pool.c: At top level:
ip_pool.c:98: warning: `struct ip_pool' declared inside parameter list
ip_pool.c: In function `ip_pool_delip_kernel_R6a55fd62':
ip_pool.c:100: dereferencing pointer to incomplete type
ip_pool.c:101: dereferencing pointer to incomplete type
ip_pool.c:102: dereferencing pointer to incomplete type
ip_pool.c: At top level:
ip_pool.c:108: warning: `struct ip_pool' declared inside parameter list
ip_pool.c: In function `ip_pool_addip':
ip_pool.c:112: dereferencing pointer to incomplete type
ip_pool.c:113: dereferencing pointer to incomplete type
ip_pool.c:116: dereferencing pointer to incomplete type
ip_pool.c:110: warning: `res' might be used uninitialized in this
function
ip_pool.c: At top level:
ip_pool.c:123: warning: `struct ip_pool' declared inside parameter list
ip_pool.c: In function `ip_pool_delip':
ip_pool.c:127: dereferencing pointer to incomplete type
ip_pool.c:128: dereferencing pointer to incomplete type
ip_pool.c:130: dereferencing pointer to incomplete type
ip_pool.c:125: warning: `res' might be used uninitialized in this
function
ip_pool.c: At top level:
ip_pool.c:137: warning: `struct ip_pool' declared inside parameter list
ip_pool.c: In function `ip_pool_flushpool':
ip_pool.c:139: dereferencing pointer to incomplete type
ip_pool.c:140: dereferencing pointer to incomplete type
ip_pool.c:141: dereferencing pointer to incomplete type
ip_pool.c: At top level:
ip_pool.c:146: warning: `struct ip_pool' declared inside parameter list
ip_pool.c:152: warning: `struct ip_pool' declared inside parameter list
ip_pool.c: In function `poolname_equal':
ip_pool.c:154: warning: implicit declaration of function `DP'
ip_pool.c:154: dereferencing pointer to incomplete type
ip_pool.c:155: dereferencing pointer to incomplete type
ip_pool.c:155: `IP_POOL_MAXNAMELEN' undeclared (first use in this
function)
ip_pool.c:155: (Each undeclared identifier is reported only once
ip_pool.c:155: for each function it appears in.)
ip_pool.c: At top level:
ip_pool.c:161: warning: `struct ip_pool_type' declared inside parameter
list
ip_pool.c: In function `pooltype_equal':
ip_pool.c:162: dereferencing pointer to incomplete type
ip_pool.c:163: dereferencing pointer to incomplete type
ip_pool.c:163: `IP_POOL_MAXNAMELEN' undeclared (first use in this
function)
ip_pool.c: At top level:
ip_pool.c:170: `IP_POOL_MAXNAMELEN' undeclared here (not in a function)
ip_pool.c:171: parameter `name' has incomplete type
ip_pool.c: In function `find_pooltype':
ip_pool.c:173: warning: passing arg 1 of `pooltype_equal' from
incompatible pointer type
ip_pool.c: In function `ip_pool_register_pooltype_Rb2dab173':
ip_pool.c:179: dereferencing pointer to incomplete type
ip_pool.c:179: `IP_POOL_PROTOCOL_VERSION' undeclared (first use in this
function)
ip_pool.c:184: dereferencing pointer to incomplete type
ip_pool.c:184: type of formal parameter 1 is incomplete
ip_pool.c:188: dereferencing pointer to incomplete type
ip_pool.c:194: warning: implicit declaration of function
`ip_pool_printk'
ip_pool.c:194: dereferencing pointer to incomplete type
ip_pool.c:199: dereferencing pointer to incomplete type
ip_pool.c:200: dereferencing pointer to incomplete type
ip_pool.c: In function `ip_pool_unregister_pooltype_Rea435b0a':
ip_pool.c:208: dereferencing pointer to incomplete type
ip_pool.c:208: type of formal parameter 1 is incomplete
ip_pool.c:209: dereferencing pointer to incomplete type
ip_pool.c:217: dereferencing pointer to incomplete type
ip_pool.c: At top level:
ip_pool.c:221: `IP_POOL_MAXNAMELEN' undeclared here (not in a function)
ip_pool.c:222: `IP_POOL_MAXNAMELEN' undeclared here (not in a function)
ip_pool.c:225: parameter `name' has incomplete type
ip_pool.c:225: parameter `typename' has incomplete type
ip_pool.c: In function `ip_pool_createpool':
ip_pool.c:233: sizeof applied to an incomplete type
ip_pool.c:236: dereferencing pointer to incomplete type
ip_pool.c:237: dereferencing pointer to incomplete type
ip_pool.c:237: `IP_POOL_MAXNAMELEN' undeclared (first use in this
function)
ip_pool.c:238: dereferencing pointer to incomplete type
ip_pool.c:239: dereferencing pointer to incomplete type
ip_pool.c:240: dereferencing pointer to incomplete type
ip_pool.c:241: dereferencing pointer to incomplete type
ip_pool.c:242: dereferencing pointer to incomplete type
ip_pool.c:243: dereferencing pointer to incomplete type
ip_pool.c:254: dereferencing pointer to incomplete type
ip_pool.c:255: warning: passing arg 1 of `pooltype_equal' from
incompatible pointer type
ip_pool.c:256: dereferencing pointer to incomplete type
ip_pool.c:263: dereferencing pointer to incomplete type
ip_pool.c:263: dereferencing pointer to incomplete type
ip_pool.c:263: warning: value computed is not used
ip_pool.c:269: dereferencing pointer to incomplete type
ip_pool.c:271: dereferencing pointer to incomplete type
ip_pool.c:271: dereferencing pointer to incomplete type
ip_pool.c:271: warning: value computed is not used
ip_pool.c:283: dereferencing pointer to incomplete type
ip_pool.c:283: warning: passing arg 1 of `poolname_equal' from
incompatible pointer type
ip_pool.c:284: dereferencing pointer to incomplete type
ip_pool.c:285: dereferencing pointer to incomplete type
ip_pool.c:285: dereferencing pointer to incomplete type
ip_pool.c:285: warning: value computed is not used
ip_pool.c: At top level:
ip_pool.c:300: warning: `struct ip_pool' declared inside parameter list
ip_pool.c: In function `ip_pool_destroypool':
ip_pool.c:310: dereferencing pointer to incomplete type
ip_pool.c:310: dereferencing pointer to incomplete type
ip_pool.c:315: dereferencing pointer to incomplete type
ip_pool.c:316: dereferencing pointer to incomplete type
ip_pool.c:316: dereferencing pointer to incomplete type
ip_pool.c:316: warning: value computed is not used
ip_pool.c: At top level:
ip_pool.c:325: warning: `struct ip_pool' declared inside parameter list
ip_pool.c: In function `ip_pool_renamepool':
ip_pool.c:331: warning: passing arg 1 of `poolname_equal' from
incompatible pointer type
ip_pool.c:339: dereferencing pointer to incomplete type
ip_pool.c:339: `IP_POOL_MAXNAMELEN' undeclared (first use in this
function)
ip_pool.c:340: dereferencing pointer to incomplete type
ip_pool.c: At top level:
ip_pool.c:347: warning: `struct ip_pool' declared inside parameter list
ip_pool.c:359: parse error before `ip_pool_ip_t'
ip_pool.c:359: warning: `struct ip_pool' declared inside parameter list
ip_pool.c:360: warning: function declaration isn't a prototype
ip_pool.c: In function `ip_pool_userspacetestip':
ip_pool.c:363: `pool' undeclared (first use in this function)
ip_pool.c:364: `ip' undeclared (first use in this function)
ip_pool.c:361: warning: `res' might be used uninitialized in this
function
ip_pool.c: At top level:
ip_pool.c:385: `IP_POOL_MAXNAMELEN' undeclared here (not in a function)
ip_pool.c:386: parameter `name' has incomplete type
ip_pool.c: In function `ip_pool_get_by_name_Rdeb5ac67':
ip_pool.c:390: warning: passing arg 1 of `poolname_equal' from
incompatible pointer type
ip_pool.c:392: dereferencing pointer to incomplete type
ip_pool.c: In function `ip_pool_get_by_addr_R01f1793e':
ip_pool.c:408: warning: passing arg 1 of `addr_equal' from incompatible
pointer type
ip_pool.c:408: warning: passing arg 2 of `addr_equal' from incompatible
pointer type
ip_pool.c:410: dereferencing pointer to incomplete type
ip_pool.c: In function `ip_pool_put_R0077b403':
ip_pool.c:426: warning: passing arg 1 of `addr_equal' from incompatible
pointer type
ip_pool.c:426: warning: passing arg 2 of `addr_equal' from incompatible
pointer type
ip_pool.c:428: dereferencing pointer to incomplete type
ip_pool.c: In function `ip_pool_list_headers_size':
ip_pool.c:445: sizeof applied to an incomplete type
ip_pool.c:447: dereferencing pointer to incomplete type
ip_pool.c:448: dereferencing pointer to incomplete type
ip_pool.c: In function `ip_pool_list_headers':
ip_pool.c:475: sizeof applied to an incomplete type
ip_pool.c:477: sizeof applied to an incomplete type
ip_pool.c:480: dereferencing pointer to incomplete type
ip_pool.c:483: dereferencing pointer to incomplete type
ip_pool.c:483: dereferencing pointer to incomplete type
ip_pool.c:484: dereferencing pointer to incomplete type
ip_pool.c:490: dereferencing pointer to incomplete type
ip_pool.c:490: dereferencing pointer to incomplete type
ip_pool.c:490: `IP_POOL_MAXNAMELEN' undeclared (first use in this
function)
ip_pool.c:491: dereferencing pointer to incomplete type
ip_pool.c:491: dereferencing pointer to incomplete type
ip_pool.c:492: dereferencing pointer to incomplete type
ip_pool.c:492: dereferencing pointer to incomplete type
ip_pool.c:493: dereferencing pointer to incomplete type
ip_pool.c:493: dereferencing pointer to incomplete type
ip_pool.c:494: dereferencing pointer to incomplete type
ip_pool.c:494: dereferencing pointer to incomplete type
ip_pool.c:495: dereferencing pointer to incomplete type
ip_pool.c:495: dereferencing pointer to incomplete type
ip_pool.c:498: dereferencing pointer to incomplete type
ip_pool.c:500: dereferencing pointer to incomplete type
ip_pool.c: In function `ip_pool_list_poolmembers_size':
ip_pool.c:524: dereferencing pointer to incomplete type
ip_pool.c:525: dereferencing pointer to incomplete type
ip_pool.c:522: warning: `size' might be used uninitialized in this
function
ip_pool.c: In function `ip_pool_list_poolmembers':
ip_pool.c:537: dereferencing pointer to incomplete type
ip_pool.c:539: dereferencing pointer to incomplete type
ip_pool.c:544: dereferencing pointer to incomplete type
ip_pool.c:535: warning: `need' might be used uninitialized in this
function
ip_pool.c: In function `setpool':
ip_pool.c:642: `SO_IP_POOL' undeclared (first use in this function)
ip_pool.c:644: sizeof applied to an incomplete type
ip_pool.c:646: sizeof applied to an incomplete type
ip_pool.c:662: dereferencing pointer to incomplete type
ip_pool.c:662: `IP_POOL_MAXNAMELEN' undeclared (first use in this
function)
ip_pool.c:666: dereferencing pointer to incomplete type
ip_pool.c:666: `IP_POOL_OP_CREATE_POOL' undeclared (first use in this
function)
ip_pool.c:669: sizeof applied to an incomplete type
ip_pool.c:672: sizeof applied to an incomplete type
ip_pool.c:675: dereferencing pointer to incomplete type
ip_pool.c:677: dereferencing pointer to incomplete type
ip_pool.c:678: dereferencing pointer to incomplete type
ip_pool.c:679: sizeof applied to an incomplete type
ip_pool.c:680: sizeof applied to an incomplete type
ip_pool.c:680: type of formal parameter 1 is incomplete
ip_pool.c:680: type of formal parameter 2 is incomplete
ip_pool.c:689: dereferencing pointer to incomplete type
ip_pool.c:689: type of formal parameter 1 is incomplete
ip_pool.c:695: dereferencing pointer to incomplete type
ip_pool.c:696: `IP_POOL_OP_ADD_IP' undeclared (first use in this
function)
ip_pool.c:698: sizeof applied to an incomplete type
ip_pool.c:699: sizeof applied to an incomplete type
ip_pool.c:699: warning: passing arg 1 of `ip_pool_addip' from
incompatible pointer type
ip_pool.c:702: `IP_POOL_OP_DEL_IP' undeclared (first use in this
function)
ip_pool.c:704: sizeof applied to an incomplete type
ip_pool.c:705: sizeof applied to an incomplete type
ip_pool.c:705: warning: passing arg 1 of `ip_pool_delip' from
incompatible pointer type
ip_pool.c:708: `IP_POOL_OP_DESTROY_POOL' undeclared (first use in this
function)
ip_pool.c:709: warning: passing arg 1 of `ip_pool_destroypool' from
incompatible pointer type
ip_pool.c:713: `IP_POOL_OP_FLUSH_POOL' undeclared (first use in this
function)
ip_pool.c:714: warning: passing arg 1 of `ip_pool_flushpool' from
incompatible pointer type
ip_pool.c:718: `IP_POOL_OP_RENAME_POOL' undeclared (first use in this
function)
ip_pool.c:721: sizeof applied to an incomplete type
ip_pool.c:724: sizeof applied to an incomplete type
ip_pool.c:728: dereferencing pointer to incomplete type
ip_pool.c:729: dereferencing pointer to incomplete type
ip_pool.c:729: warning: passing arg 1 of `ip_pool_renamepool' from
incompatible pointer type
ip_pool.c:732: `IP_POOL_OP_SETCOUNTER_POOL' undeclared (first use in
this function)
ip_pool.c:735: sizeof applied to an incomplete type
ip_pool.c:738: sizeof applied to an incomplete type
ip_pool.c:742: dereferencing pointer to incomplete type
ip_pool.c:742: dereferencing pointer to incomplete type
ip_pool.c:742: warning: passing arg 1 of `ip_pool_counterpool' from
incompatible pointer type
ip_pool.c:697: warning: unreachable code at beginning of switch
statement
ip_pool.c:747: dereferencing pointer to incomplete type
ip_pool.c: In function `getpool':
ip_pool.c:772: `SO_IP_POOL' undeclared (first use in this function)
ip_pool.c:774: sizeof applied to an incomplete type
ip_pool.c:776: sizeof applied to an incomplete type
ip_pool.c:792: dereferencing pointer to incomplete type
ip_pool.c:792: `IP_POOL_MAXNAMELEN' undeclared (first use in this
function)
ip_pool.c:794: dereferencing pointer to incomplete type
ip_pool.c:794: dereferencing pointer to incomplete type
ip_pool.c:796: dereferencing pointer to incomplete type
ip_pool.c:797: `IP_POOL_OP_TEST_IP' undeclared (first use in this
function)
ip_pool.c:801: sizeof applied to an incomplete type
ip_pool.c:803: sizeof applied to an incomplete type
ip_pool.c:806: dereferencing pointer to incomplete type
ip_pool.c:806: type of formal parameter 1 is incomplete
ip_pool.c:811: dereferencing pointer to incomplete type
ip_pool.c:811: dereferencing pointer to incomplete type
ip_pool.c:811: dereferencing pointer to incomplete type
ip_pool.c:813: sizeof applied to an incomplete type
ip_pool.c:813: sizeof applied to an incomplete type
ip_pool.c:813: sizeof applied to an incomplete type
ip_pool.c:816: `IP_POOL_OP_VERSION' undeclared (first use in this
function)
ip_pool.c:819: sizeof applied to an incomplete type
ip_pool.c:821: sizeof applied to an incomplete type
ip_pool.c:825: dereferencing pointer to incomplete type
ip_pool.c:825: `IP_POOL_PROTOCOL_VERSION' undeclared (first use in this
function)
ip_pool.c:827: sizeof applied to an incomplete type
ip_pool.c:827: sizeof applied to an incomplete type
ip_pool.c:827: sizeof applied to an incomplete type
ip_pool.c:830: `IP_POOL_OP_GETPOOL_BYNAME' undeclared (first use in this
function)
ip_pool.c:833: sizeof applied to an incomplete type
ip_pool.c:835: sizeof applied to an incomplete type
ip_pool.c:838: dereferencing pointer to incomplete type
ip_pool.c:838: dereferencing pointer to incomplete type
ip_pool.c:838: type of formal parameter 1 is incomplete
ip_pool.c:839: dereferencing pointer to incomplete type
ip_pool.c:843: dereferencing pointer to incomplete type
ip_pool.c:844: sizeof applied to an incomplete type
ip_pool.c:844: sizeof applied to an incomplete type
ip_pool.c:844: sizeof applied to an incomplete type
ip_pool.c:847: `IP_POOL_OP_GETPOOL_BYADDR' undeclared (first use in this
function)
ip_pool.c:850: sizeof applied to an incomplete type
ip_pool.c:852: sizeof applied to an incomplete type
ip_pool.c:856: dereferencing pointer to incomplete type
ip_pool.c:856: dereferencing pointer to incomplete type
ip_pool.c:857: dereferencing pointer to incomplete type
ip_pool.c:861: dereferencing pointer to incomplete type
ip_pool.c:862: dereferencing pointer to incomplete type
ip_pool.c:862: dereferencing pointer to incomplete type
ip_pool.c:864: dereferencing pointer to incomplete type
ip_pool.c:865: sizeof applied to an incomplete type
ip_pool.c:865: sizeof applied to an incomplete type
ip_pool.c:865: sizeof applied to an incomplete type
ip_pool.c:870: `IP_POOL_OP_LISTHEADERS_SIZE' undeclared (first use in
this function)
ip_pool.c:876: sizeof applied to an incomplete type
ip_pool.c:878: sizeof applied to an incomplete type
ip_pool.c:882: dereferencing pointer to incomplete type
ip_pool.c:884: dereferencing pointer to incomplete type
ip_pool.c:886: sizeof applied to an incomplete type
ip_pool.c:886: sizeof applied to an incomplete type
ip_pool.c:886: sizeof applied to an incomplete type
ip_pool.c:889: `IP_POOL_OP_LISTMEMBERS_SIZE' undeclared (first use in
this function)
ip_pool.c:894: sizeof applied to an incomplete type
ip_pool.c:896: sizeof applied to an incomplete type
ip_pool.c:900: dereferencing pointer to incomplete type
ip_pool.c:900: type of formal parameter 1 is incomplete
ip_pool.c:905: dereferencing pointer to incomplete type
ip_pool.c:907: sizeof applied to an incomplete type
ip_pool.c:907: sizeof applied to an incomplete type
ip_pool.c:907: sizeof applied to an incomplete type
ip_pool.c:911: `IP_POOL_OP_LISTHEADERS' undeclared (first use in this
function)
ip_pool.c:921: `IP_POOL_OP_LISTMEMBERS' undeclared (first use in this
function)
ip_pool.c:926: dereferencing pointer to incomplete type
ip_pool.c:926: type of formal parameter 1 is incomplete
ip_pool.c:798: warning: unreachable code at beginning of switch
statement
ip_pool.c:950: dereferencing pointer to incomplete type
ip_pool.c: At top level:
ip_pool.c:963: `SO_IP_POOL' undeclared here (not in a function)
ip_pool.c:963: initializer element is not constant
ip_pool.c:963: (near initialization for `so_pool.set_optmin')
ip_pool.c:963: `SO_IP_POOL' undeclared here (not in a function)
ip_pool.c:963: initializer element is not constant
ip_pool.c:963: (near initialization for `so_pool.set_optmax')
ip_pool.c:964: `SO_IP_POOL' undeclared here (not in a function)
ip_pool.c:964: initializer element is not constant
ip_pool.c:964: (near initialization for `so_pool.get_optmin')
ip_pool.c:964: `SO_IP_POOL' undeclared here (not in a function)
ip_pool.c:964: initializer element is not constant
ip_pool.c:964: (near initialization for `so_pool.get_optmax')
make[2]: *** [ip_pool.o] Fehler 1
make[2]: Leaving directory
`/usr/src/pool/linux-2.4.20/net/ipv4/netfilter'
make[1]: *** [_modsubdir_ipv4/netfilter] Fehler 2
make[1]: Leaving directory `/usr/src/pool/linux-2.4.20/net'
make: *** [_mod_net] Fehler 2
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* NAT of Cisco Voice-Over-IP with Skinny protocol and CallManager
From: Michael J. Tubby B.Sc. (Hons) G8TIC @ 2002-12-19 18:49 UTC (permalink / raw)
To: netfilter
All,
I have acquired access to a Cisco CallManager (on the internet)
and a pile of Cisco VIP-30 VOIP phones. I have got everything
up and working when they are directly connected to the 'net but
now I want to put some of the phones at friend's houses behind
the Linux boxen that I've built as NAT/firewalls for their cable
modem and ADSL connections...
I'm using RedHat 7.3 but with own compiled 2.4.20 kernel and
iptables 1.2.7a.
Problem is that the phone gets it's directory number and connects
just fine using the Skinny protocol on and TCP:2000 and TFTP on
UDP:69, however the called party can hear me but the return UDPs
don't get back in.
A bit of tcpdump-ing shows that there's no obvious/direct relationship
between the outgoing UDP port numbers on the voice stream and
the incomming reply packets, and hence netfilter/nat has no way
to know what do do unless there's a helper.
Searching on google reveals only a posting from back in the summer
by Fred N. van Kempen about the subject/problem:
http://lists.netfilter.org/pipermail/netfilter-devel/2002-July/008844.html
Does anyone know if there's a fix for this? Is there a helper (connection
tracking) module that can prime the netfilter/DNAT to get the packets
back in by watching the connection set up?
Any help appreciated.
Mike
^ permalink raw reply
* RE: [PATCH 2.5.52] Use __set_current_state() instead of current-> state = (take 1)
From: Perez-Gonzalez, Inaky @ 2002-12-19 19:04 UTC (permalink / raw)
To: 'Robert Love'; +Cc: linux-kernel
> > And that would now really work when CONFIG_X86_OOSTORE=1 is required
> > [after all, it is a write, so it'd need the equivalent of a wmb() or
> > xchg()].
>
> Is this a hint that your employer may have an x86 chip in the future
> with weak ordering? :)
Hmmm ... taking into account that there are some many thousands of
employees in my company and that I know less than one hundred ...
and that they are all software ... well, I don't think I am into
the rumour mill :]
Inaky Perez-Gonzalez -- Not speaking for Intel - opinions are my own [or my
fault]
^ permalink raw reply
* Re: scsi_scan.c complaints...
From: Doug Ledford @ 2002-12-19 18:56 UTC (permalink / raw)
To: Justin T. Gibbs; +Cc: Christoph Hellwig, James Bottomley, linux-scsi
In-Reply-To: <4011340000.1039908562@aslan.scsiguy.com>
[-- Attachment #1: Type: text/plain, Size: 775 bytes --]
OK, so I've been working on that patch. I've got it close to done, but it
oopses on me at bootup (somewhere I think there is a single init that I'm
missing that causes the first command we insert into the request queue to
oops). So, I've got to go up to the office to get any further on this
since I need my test machine and serial console setup. But, in case
people were curious what I did about the problem, I've attached the
current form of the patch to this email. If anyone sees an obvious
oversight that is causing the problem, feel free to clue me in, otherwise
I'll be working on it some more later today ;-)
--
Doug Ledford <dledford@redhat.com> 919-754-3700 x44233
Red Hat, Inc.
1801 Varsity Dr.
Raleigh, NC 27606
[-- Attachment #2: scsi_scan-test.patch.gz --]
[-- Type: application/x-gzip, Size: 8841 bytes --]
^ permalink raw reply
* RE: MPC8265/6 and PCI support
From: Dayton, Dean @ 2002-12-19 18:58 UTC (permalink / raw)
To: 'linuxppc-embedded@lists.linuxppc.org'
I've got PCI support running on an MPC8266ADS as well as a proprietary 8265
board. I am running a 2.4.18-pre3 kernel (with several other modifications).
I'd be happy to share, but it may be difficult to give you patches that you
can use directly. What kernel are you using?
Dean Dayton
deand@aiinet.com
> -----Original Message-----
> From: None Atall [mailto:linux_meis@yahoo.com]
> Sent: Tuesday, December 17, 2002 11:04 AM
> To: linuxppc-embedded@lists.linuxppc.org
> Subject: MPC8265/6 and PCI support
>
>
>
> Hello everybody!
> I have started writting a PCI driver for Motorola's
> MPC8265/6 processors (about 45% complete, untested).
> This code will be open source, since this is developed
> in my free time :)
> Is there anybody out there developing such a code?
> Is he/she willing to help?
>
> c ya,
> Dimitris.
>
> ----------------------
> Dimitrios Meidanis
> Hardware/Software Engineer
> http://www.csd.uoc.gr/~meidanis
>
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Dell OEM Soundblaster Live 5.1 with different PCI ID
From: Jeffrey Kent Ridenour @ 2002-12-19 19:02 UTC (permalink / raw)
To: alsa-devel
Hi folks,
I was having the exact same problem, so I tried changing the source using
the diff file provided by Takashi, thanks a lot! This did make progress
for me, since before, the i couldn't get the driver to modprobe.
The driver now loads and I can now give gmix/alsamixer to open (couldn't
before). However, I'm still not getting sound. when I turn the volume up
and mess with the sliders, I do hear changes in the signal level (i.e. the
noise floor goes up and down), but I haven't been able to get any sounds
or CD's to play.
Is this because the driver really doesn't work? Or is there something
else that i haven't configured properly? Any suggestions or response from
anyone would be much appreciated. (I have a deadline I'm working with,
and I need to decide soon whether I should buy a different soundcard or
not)
jeff
>At Thu, 19 Dec 2002 10:45:22 +0100,
>elchhome@gmx.de wrote:
>> > Hello Friends,
>> > Dell ships since a month an OEM Soundblaster Live 5.1 (sb0200) with a
>> different PCI ID
>> > for original sblive you got 1102:0002
>> the Dell version has 1102:0006
>> > I got no sound with the actual version of the sound driver.
>> Could anyone be so kind to incorporate this into the source code?
>
>please try the attached patch.
>this will add the entry as emu10k1 (sb live!). it seems that the chip
>is emu10k1, not audigy.
>if it works, please let me know. i'll commit it to cvs.
>thanks,
>Takashi
-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now! Before the Holidays pass you by.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
^ permalink raw reply
* Re: [PATCH/RFC] New module refcounting for net_proto_family
From: David S. Miller @ 2002-12-19 19:12 UTC (permalink / raw)
To: alan; +Cc: maxk, linux-kernel
In-Reply-To: <1040326115.28973.25.camel@irongate.swansea.linux.org.uk>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: 19 Dec 2002 19:28:35 +0000
On Thu, 2002-12-19 at 16:05, Max Krasnyansky wrote:
> Hmm, no replies. Nobody is interested in this or what ?
> I want to get this fixed otherwise I can't fix Bluetooth module
> refcounting.
Looks good to me, but its christmas so I wouldnt expect much to happen
till the new year
I just got back from a long snowboarding trip, I'll look at this
over the weekend before I disappear for another similar trip :)
^ permalink raw reply
* [LARTC] [RELEASE] Iptables tutorial 1.1.16
From: Oskar Andreasson @ 2002-12-19 19:10 UTC (permalink / raw)
To: lartc
Hi all,
This is a rather late notification about the fact that the iptables
tutorial was released in version 1.1.16 three days ago. No big changes
from 1.1.15, except tons of internal fixes since I moved from Red Hat to
Debian on my main workstation. This caused a hole lot of problems for
mirrors etc, but it should now be fixed again.
As always, available at http://iptables-tutorial.frozentux.net
Thanks, and sorry for disturbing all threads.
--
----
Oskar Andreasson
http://www.frozentux.net
http://iptables-tutorial.frozentux.net
http://ipsysctl-tutorial.frozentux.net
mailto:blueflux@koffein.net
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* [RELEASE] Iptables tutorial 1.1.16
From: Oskar Andreasson @ 2002-12-19 19:10 UTC (permalink / raw)
To: lartc, netfilter
Hi all,
This is a rather late notification about the fact that the iptables
tutorial was released in version 1.1.16 three days ago. No big changes
from 1.1.15, except tons of internal fixes since I moved from Red Hat to
Debian on my main workstation. This caused a hole lot of problems for
mirrors etc, but it should now be fixed again.
As always, available at http://iptables-tutorial.frozentux.net
Thanks, and sorry for disturbing all threads.
--
----
Oskar Andreasson
http://www.frozentux.net
http://iptables-tutorial.frozentux.net
http://ipsysctl-tutorial.frozentux.net
mailto:blueflux@koffein.net
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.