* Re: Home web server using front firewall
From: Antony Stone @ 2003-12-17 22:48 UTC (permalink / raw)
To: Netfilter
In-Reply-To: <HFEBJMKNPOCPPMGFHDMCAEJBCDAA.esanz@minorplanetusa.com>
On Wednesday 17 December 2003 9:30 pm, Erick Sanz wrote:
> Antony,
>
> This are the entries I had to add to make it work:
>
> iptables -P INPUT DROP
> iptables -P OUTPUT DROP
> iptables -P FORWARD DROP
>
> iptables -t nat -A PREROUTING -p tcp -d 172.16.1.33 --dport 80 \
> -j DNAT --to 10.10.1.240
>
> iptables -A POSTROUTING -t nat -o eth0 -j MASQUERADE
>
> iptables -A INPUT -i eth0 -p tcp -d 172.16.1.33 --dport 80 -m state \
> --state NEW,ESTABLISHED,RELATED -j ACCEPT
>
> iptables -A INPUT -i eth1 -p tcp -s 10.10.1.240 --sport 80 -m state \
> --state ESTABLISHED,RELATED -j ACCEPT
Packets being routed through a firewall from one side to the other do not go
through the INPUT chain.
The only packets which go through rules in the INPUT chain are those addressed
to the firewall itself, and not being routed any further.
I do not believe you need the above two rules in the INPUT chain.
> I have read the FAQ on forwarding; however, I can still not understand
> the 3 forwarding statements needed; one of them is for input on eth0
> (172.16.1.33) to 10.10.1.240. The other one is for data received from
> eth1 (10.10.1.240); however, I don't understand the third forward (can't
> be taken out as it won't work then)... I see the difference as -i to
> -o ... Is there a newby explanation on why?
You need to understand the difference between putting a rule in the INPUT
chain (which is for packets addressed to the firewall itself), compared to
specifying -i in a rule in the FORWARD chain (which is for packets being
routed through the firewall, where you want to specify which interface they
entered the machine through).
Here's a suggestion:
Allow your firewall to pass some of the traffic that you want (now that you've
got it working), and then type:
iptables -L -n -v -x
You will see each of the rules in the INPUT, FORWARD and OUTPUT rules, with
byte and packet counts at the beginning.
Any rule which has a zero packet / byte count has not seen any traffic, and is
therefore not contributing to your firewall working.
Hopefully this helps to explain things a bit more so you understand what is
needed and what is not.
Antony.
--
This is not a rehearsal.
This is Real Life.
^ permalink raw reply
* Re: cciss updates for 2.4.24-pre1, 1 of 2
From: Jens Axboe @ 2003-12-17 22:49 UTC (permalink / raw)
To: mikem; +Cc: marcelo.tosatti, linux-kernel, mike.miller, scott.benesh
In-Reply-To: <Pine.LNX.4.58.0312161742220.30010@beardog.cca.cpqcorp.net>
On Tue, Dec 16 2003, mikem@beardog.cca.cpqcorp.net wrote:
> Under certain conditions if the cciss driver fails to load the pointer to
> the hba may be null when trying to free the I/O memory. This patch fixes
> that problem and removes a no longer valid comment.
> This is #1 of 2 and should be applied first. Please consider this patch
> for inclusion in the 2.4.24 kernel.
>
> Thanks,
> mikem
> mike.miller@hp.com
> ------------------------------------------------------------------------------
> diff -burN lx2424pre1.orig/drivers/block/cciss.c lx2424pre1/drivers/block/cciss.c
> --- lx2424pre1.orig/drivers/block/cciss.c 2003-11-28 12:26:19.000000000 -0600
> +++ lx2424pre1/drivers/block/cciss.c 2003-12-16 17:25:50.000000000 -0600
> @@ -2612,7 +2612,6 @@
>
> /* get the address index number */
> cfg_base_addr = readl(c->vaddr + SA5_CTCFG_OFFSET);
> - /* I am not prepared to deal with a 64 bit address value */
> cfg_base_addr &= (__u32) 0x0000ffff;
> #ifdef CCISS_DEBUG
> printk("cfg base address = %x\n", cfg_base_addr);
> @@ -2624,7 +2623,7 @@
> #endif /* CCISS_DEBUG */
> if (cfg_base_addr_index == -1) {
> printk(KERN_WARNING "cciss: Cannot find cfg_base_addr_index\n");
> - release_io_mem(hba[i]);
> + release_io_mem(c);
> return -1;
> }
Looks fine to apply.
--
Jens Axboe
^ permalink raw reply
* Re: cciss update for 2.4.24-pre1, 2 of 2
From: Jens Axboe @ 2003-12-17 22:50 UTC (permalink / raw)
To: mikem; +Cc: marcelo.tosatti, linux-kernel, mike.miller, scott.benesh
In-Reply-To: <Pine.LNX.4.58.0312161750290.30010@beardog.cca.cpqcorp.net>
On Tue, Dec 16 2003, mikem@beardog.cca.cpqcorp.net wrote:
> Some older cciss controllers may take a long time to become ready after
> hot replacing the controller. This patch addresses that problem by adding
> a check of the scratchpad register. This patch is intended to supplement
> the monitor thread when cciss is used in an md environment. In the event
> of a controller failure the failed board can now be more reliably
> replaced. This is patch #2 of 2.
> Please consider this patch for inclusion in the 2.4.24 kernel.
>
> Thanks,
> mikem
> mike.miller@hp.com
> ------------------------------------------------------------------------------
> diff -burN lx2424pre1-p01/drivers/block/cciss.c lx2424pre1/drivers/block/cciss.c
> --- lx2424pre1-p01/drivers/block/cciss.c 2003-12-16 17:25:50.000000000 -0600
> +++ lx2424pre1/drivers/block/cciss.c 2003-12-16 17:30:41.000000000 -0600
> @@ -2537,8 +2537,8 @@
> static int cciss_pci_init(ctlr_info_t *c, struct pci_dev *pdev)
> {
> ushort subsystem_vendor_id, subsystem_device_id, command;
> - unchar irq = pdev->irq;
> - __u32 board_id;
> + unchar irq = pdev->irq, revision, ready = 0;
> + __u32 board_id, scratchpad;
> __u64 cfg_offset;
> __u32 cfg_base_addr;
> __u64 cfg_base_addr_index;
> @@ -2609,6 +2609,21 @@
> printk("address 0 = %x\n", c->paddr);
> #endif /* CCISS_DEBUG */
> c->vaddr = remap_pci_mem(c->paddr, 200);
> + /* Wait for the board to become ready. (PCI hotplug needs this.)
> + * We poll for up to 120 secs, once per 100ms. */
> + for (i=0; i < 1200; i++) {
> + scratchpad = readl(c->vaddr + SA5_SCRATCHPAD_OFFSET);
> + if (scratchpad == 0xffff0000) {
> + ready = 1;
> + break;
> + }
> + set_current_state(TASK_INTERRUPTIBLE);
> + schedule_timeout(HZ / 10); /* wait 100ms */
> + }
> + if (!ready) {
> + printk(KERN_WARNING "cciss: Board not ready. Timed out.\n");
> + return -1;
> + }
Fine as well, aren't you happy you changed this to schedule_timeout()
instead of busy looping? :)
--
Jens Axboe
^ permalink raw reply
* Re: udev.rules.devfs + symlinks & a question
From: Marco d'Itri @ 2003-12-17 22:51 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <marc-linux-hotplug-107105799027697@msgid-missing>
On Dec 17, Greg KH <greg@kroah.com> wrote:
>We could add "include" support for the config files, but why not just
>generate your "master" config file whenever the config is changed. cpp
>or any other text processing program could easily generate a master
>config from multiple config files.
I considered doing this for the debian package (like I do e.g. for
modprobe.conf), but it has the downside that every distribution would
probably do it a different way.
--
ciao, |
Marco | [3661 trH1jh9pQiypw]
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id\x1278&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* Re: udev.rules.devfs + symlinks & a question
From: Svetoslav Slavtchev @ 2003-12-17 22:55 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <marc-linux-hotplug-107105799027697@msgid-missing>
[-- Attachment #1: Type: text/plain, Size: 1253 bytes --]
> On Wed, Dec 17, 2003 at 09:39:08PM +0100, Svetoslav Slavtchev wrote:
> > > On Sat, Dec 13, 2003 at 10:33:08PM +0100, Svetoslav Slavtchev wrote:
> > > > what are the advantages/ disadvantages
> > > > to compile using klibc ?
> > >
> > > A very tiny static executable is created using klibc. That's
> necessary
> > > for early boot, and people who care about the size of things.
> > >
> >
> > thanks for the explanation :-)
> >
> > could you drop the link to linux source (IIRC ../../gregkh-2.5 )
> > in udev/klibc, and replace it with
> > make KERNEL_DIR=...... USE_KLIBC=true
>
> Hm, the udev/linux symlink points to:
> linux -> ../../../linux/linux-2.5
>
> If you want to build with klibc, adjust it to where your 2.6 kernel tree
> is located at.
>
> > i've a small patch but it's only for udev,
> > and it doesn't work with " make USE_KLIBC=true EXTRAS=..."
> > it's mostly
> > s:$(LINUX_INCLUDE_DIR)/kernel/include:$(KERNEL_DIR)/include:
> > in udev/Makefile & udev/klibc/MCONFIG
>
> Care to send it?
thanks :-)
and attached
together with the sed rule correction
svetljo
--
+++ GMX - die erste Adresse für Mail, Message, More +++
Neu: Preissenkung für MMS und FreeMMS! http://www.gmx.net
[-- Attachment #2: udev-fix_gen-udev.conf.diff --]
[-- Type: application/octet-stream, Size: 347 bytes --]
--- udev-009/Makefile.orig 2003-12-13 17:00:28.004517456 +0100
+++ udev-009/Makefile 2003-12-13 17:01:37.582939928 +0100
@@ -208,7 +208,7 @@
# Rules on how to create the generated config files
udev.conf:
- sed -e "s-@udevdir@-$(udevdir)-" < udev.conf.in > $@
+ sed -e "s:@udevdir@:$(udevdir):" < udev.conf.in > $@
$(OBJS): $(GEN_HEADERS)
[-- Attachment #3: udev-klibc_kheaders_hack.diff --]
[-- Type: application/octet-stream, Size: 1074 bytes --]
--- udev-009/Makefile.orig 2003-12-14 14:09:51.132297432 +0100
+++ udev-009/Makefile 2003-12-14 16:00:18.675757680 +0100
@@ -31,6 +31,10 @@
RELEASE_NAME = $(ROOT)-$(VERSION)
DESTDIR =
+ifndef KERNEL_DIR
+KERNEL_DIR=/usr/src/linux
+endif
+
# override this to make udev look in a different location for it's config files
prefix =
exec_prefix = ${prefix}
@@ -119,7 +123,7 @@
KLIBC_BASE = $(PWD)/klibc
KLIBC_DIR = $(KLIBC_BASE)/klibc
INCLUDE_DIR := $(KLIBC_DIR)/include
- LINUX_INCLUDE_DIR := $(KLIBC_BASE)/linux/include
+ LINUX_INCLUDE_DIR := $(KERNEL_DIR)/include
include $(KLIBC_DIR)/arch/$(ARCH)/MCONFIG
# arch specific objects
ARCH_LIB_OBJS = \
--- udev-009/klibc/MCONFIG.orig 2003-12-14 16:10:37.164733064 +0100
+++ udev-009/klibc/MCONFIG 2003-12-14 16:10:53.728215032 +0100
@@ -12,7 +12,7 @@
-I$(KLIBSRC)/arch/$(ARCH)/include \
-I$(KLIBSRC)/include/bits$(BITSIZE) \
-D__KLIBC__ -DBITSIZE=$(BITSIZE) -I$(KLIBSRC)/include \
- -I$(SRCROOT)/linux/include
+ -I$(KERNEL_DIR)/include
LDFLAGS =
AR = $(CROSS)ar
RANLIB = $(CROSS)ranlib
^ permalink raw reply
* Re: Handling of bounce buffers by rh_call_control
From: bill davidsen @ 2003-12-17 22:47 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <3FE08470.5040801@pacbell.net>
In article <3FE08470.5040801@pacbell.net>,
David Brownell <david-b@pacbell.net> wrote:
| Hi,
|
| Richard Curnow wrote:
| > The following patch
| >
| > ===== drivers/usb/hcd.c 1.10 vs edited =====
| > --- 1.10/drivers/usb/hcd.c Mon Mar 31 14:22:42 2003
| > +++ edited/drivers/usb/hcd.c Wed Dec 17 11:26:53 2003
| > @@ -323,7 +323,7 @@
| > struct usb_ctrlrequest *cmd = (struct usb_ctrlrequest *) urb->setup_packet;
| > u16 typeReq, wValue, wIndex, wLength;
| > const u8 *bufp = 0;
| > - u8 *ubuf = urb->transfer_buffer;
| > + u8 *ubuf = (u8 *) urb->transfer_dma;
| > int len = 0;
| >
| > typeReq = (cmd->bRequestType << 8) | cmd->bRequest;
| >
| > seems to be needed to make the following code later in the function work
| >
| > if (bufp) {
| > if (urb->transfer_buffer_length < len)
| > len = urb->transfer_buffer_length;
| > urb->actual_length = len;
| > // always USB_DIR_IN, toward host
| > memcpy (ubuf, bufp, len);
|
| Which is why that particular patch is wrong: "ubuf" is a dma address,
| not expected to work for memcpy().
But the existing code most certainly does use it with memcpy. I'm
looking at test11-mm1 source, but the last memcpy line he noted is most
definitely in the existing source.
Or did I misunderstand what you meant by "not expected to work for
memcpy()?" It may be that the code around the memcpy is wrong and should
be using ubuf, and that no diddling with fix it, but someone clearly DID
expect it to work ;-)
--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
^ permalink raw reply
* Re: udev.rules.devfs + symlinks & a question
From: Svetoslav Slavtchev @ 2003-12-17 22:59 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <marc-linux-hotplug-107105799027697@msgid-missing>
> On Wed, Dec 17, 2003 at 09:39:08PM +0100, Svetoslav Slavtchev wrote:
> >
> > could you change the sed rule for generating udev.conf
> > to use ":" instead "-" for separater, as it's getting confused
> > if you install to RPM_BUILD_ROOT/udev-$(version)/
>
> What do you mean? The sed rule:
> sed -e "s-@udevdir@-$(udevdir)-" < udev.conf.in > $@
>
> doesn't work for you? If not, patches to fix it are appreciated.
yes, it breaks if $(udevdir) contains "-"
patch attached in previous mail :-)
svetljo
--
+++ GMX - die erste Adresse für Mail, Message, More +++
Neu: Preissenkung für MMS und FreeMMS! http://www.gmx.net
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id\x1278&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* gcc version 2.95.3 20010315 (release/MontaVista) cross compiler
From: David C. Chiu @ 2003-12-17 23:02 UTC (permalink / raw)
To: linuxppc-embedded
We're experiencing some unexpected behavior with binary generated with
the said version of gcc; namely that variables declared to char appear
to be defaulting to unsigned char.
#include <stdio.h>
#include <stdlib.h>
int main( int argc, char** args, char** envs )
{
char sc;
unsigned char uc;
sc = uc = -3;
printf( "signed char: %d unsigned char: %d\n", sc, uc );
if ( sc > (char)0 )
printf( "sc is greater than zero\n" );
else
printf( "sc is less or equal to zero\n" );
return 0;
}
The preceeding code would produce the following unexpected result --
signed char: 253 unsigned char: 253
sc is greater than zero
Making the following change --
signed char sc;
unsigned char uc;
.
.
Would produce the expected result --
signed char: -3 unsigned char: 253
sc is less or equal to zero
Can someone shed some light on this? (As in, is this "normal" and we do
not know only because we've been living under a rock ;-)
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: ext3 file system
From: Mike Fedyk @ 2003-12-17 23:02 UTC (permalink / raw)
To: Richard B. Johnson; +Cc: jshankar, linux-fsdevel, linux-kernel
In-Reply-To: <Pine.LNX.4.53.0312171720020.32724@chaos>
On Wed, Dec 17, 2003 at 05:25:49PM -0500, Richard B. Johnson wrote:
> to the physical media. There are special file-systems (journaling)
> that guarantee that something, enough to recover the data, is
> written at periodic intervals.
Most journaling filesystems make guarantees on the filesystem meta-data, but
not on the data. Some like ext3, and reiserfs (with suse's journaling
patch) can journal the data, or order things so that the data is written
before any pointers (ie meta-data) make it to the disk so it will be harder
to loose data.
^ permalink raw reply
* Re: AFMT_AC3 support
From: James Courtier-Dutton @ 2003-12-17 23:04 UTC (permalink / raw)
To: "C.L. Tien - ???"; +Cc: alsa-devel
In-Reply-To: <92C0412E07F63549B2A2F2345D3DB515F7D31D@cm-msg-02.cmedia.com.tw>
C.L. Tien - ??? wrote:
> Hi,
>
> Can ALSA support AFMT_AC3 to enable xine to play AC3 through S/PDIF interface? I check in core/pcm.c and core/oss/pcm_oss.c, neither of them has keywork AC3.
>
> Sincerely,
> ChenLi Tien
>
It works if you use the ALSA API instead of the OSS emulation in the
ALSA driver.
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
^ permalink raw reply
* Re: udev.rules.devfs + symlinks & a question
From: Svetoslav Slavtchev @ 2003-12-17 23:04 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <marc-linux-hotplug-107105799027697@msgid-missing>
> On Wed, Dec 17, 2003 at 02:25:22PM -0800, Greg KH wrote:
> > On Wed, Dec 17, 2003 at 09:39:08PM +0100, Svetoslav Slavtchev wrote:
> > > and i have a small issue with klibc compiled udev,
> > > at least bk from a 1-2 days ago
> > > most devicefs alike rules are followed, but not all
> > > e.g the rule for loop devices is ignored by dev compailed against
> > > klibc, but is followed by udev compiled against libc
> >
> > See the man page for why this is:
> > If udev was built using klibc or is used before the user
> > database is accessible (e.g. initrd(4)), only numeric owner and
> > group values may be used.
ok, thanks
> bah, wrong answer to the wrong question, sorry...
>
> It's a timing issue mostly. I bet that udev is beating the kernel. The
> klibc version is faster, as the code is much smaller. I'm working on
> the proper fix for this now that we have the needed changes in libsysfs
> for me to do this.
with udev 009 libc all rules are ignored :
and all devices are dumped in /udev (
any ideas ?
svetljo
--
+++ GMX - die erste Adresse für Mail, Message, More +++
Neu: Preissenkung für MMS und FreeMMS! http://www.gmx.net
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id\x1278&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* Re: PCI Express support for 2.4 kernel
From: Alan Cox @ 2003-12-17 23:06 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Jeff Garzik, Linus Torvalds, Vladimir Kondratiev, Gabriel Paubert,
linux-kernel, Alan Cox, Marcelo Tosatti, Martin Mares, zaitcev,
hch
In-Reply-To: <20031217082235.GA24027@devserv.devel.redhat.com>
On Wed, Dec 17, 2003 at 09:22:35AM +0100, Arjan van de Ven wrote:
> > Any PCI-Ex drivers would obviously _know_ they are PCI Ex, and they
> > could communicate that by virtue of simply using new functions. Older
> > drivers for older hardware would use the old API and not care...
> > Further, PCI-Ex operations are already basically readl/writel anyway, so
> > going through the forest of pci_cfg_ops pointers and such would just add
> > needless layering.
>
> BUT powermanagement and co will need to potentially do stuff too with the
> config space...
And X11 will want to access it via /proc interfaces. And someone will eventually
go and design a different way to access PCI-EX for their hardware 8)
The PCI layer is a nice abstraction and config space is slow anyway
^ permalink raw reply
* Re: udev.rules.devfs + symlinks & a question
From: Svetoslav Slavtchev @ 2003-12-17 23:06 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <marc-linux-hotplug-107105799027697@msgid-missing>
> On Wed, Dec 17, 2003 at 09:16:33PM +0100, Svetoslav Slavtchev wrote:
> > > On Sat, Dec 13, 2003 at 01:58:20AM +0100, Svetoslav Slavtchev wrote:
> > > > it would be really great if one could enable devfs like name in
> > > udev.conf
> > > > and then udev checks udev.rules for user defined rules,
> > >
> > > What user? How does the kernel know what user a device is for? :)
> > >
> > > > and additionally chains them to the devfs one's in udev.rules.devfs
> > >
> > > Nah, if you want a devfs like udev config, you will have to specify
> it.
> > > Remember you are not the "normal" user of udev by any means.
> > >
> >
> > let's put it this way:
> > i'm tring to figure out a way to replace devfs by udev
> > in mandrake linux
> > it's next version will ship with both 2.4 & 2.6 kernel,
> > and mandrake has used devfs since it switched to the 2.4 kernel
> > so devfs compatibility is quite needed
> >
> > if we use a single configuration file for creating devfs compatible
> devices
> > and for user defined rules IMHO it's getting a bit messy
> > so i think it would be good to use two separate files
> > one just for user defined rules - e.g. BUS="usb" type="cdrom"
> > NAME="usb-cdrw"
> > and one for devfs compatibilty
>
> We could add "include" support for the config files, but why not just
> generate your "master" config file whenever the config is changed. cpp
> or any other text processing program could easily generate a master
> config from multiple config files.
i was also thinking of an "include"
and i think it's more elegant then some bash scripts
or the like :-)
svetljo
--
+++ GMX - die erste Adresse für Mail, Message, More +++
Neu: Preissenkung für MMS und FreeMMS! http://www.gmx.net
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id\x1278&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* [U-Boot-Users] CFG_CMD_.... configuration space running out!!
From: Robin Gilks @ 2003-12-17 23:08 UTC (permalink / raw)
To: u-boot
Greetings
The number of commands being added to U-Boot seems in danger of
overflowing the selection mechanism. Are there any plans to expand the
process to more than 64 bits/commands that are agregated into
CONFIG_COMMANDS or should there be individual defines to turn commands
on/off.
The reason I ask is that I've just implemented a bash style 'test'
command so I can check the values of memory locations with conditional
code during boot and I note there are only 2 bits left!!
Note:
test syntax as per binary integer comparisons with the option of a unary
indirection operator on either expression.
eg. 'test *40000 -eq 12345678'
checks location 40000 for the value 12345678. I've only implemented 32
bit word indirection - does anyone think it useful to provide half-word
and byte as well - in which case what should the syntax look like?
--
Robin Gilks
Senior Design Engineer Phone: (+64)(3) 357 1569
Tait Electronics Fax : (+64)(3) 359 4632
PO Box 1645 Christchurch Email : robin.gilks at tait.co.nz
New Zealand
^ permalink raw reply
* Re: udev.rules.devfs + symlinks & a question
From: Greg KH @ 2003-12-17 23:08 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <marc-linux-hotplug-107105799027697@msgid-missing>
On Thu, Dec 18, 2003 at 12:04:13AM +0100, Svetoslav Slavtchev wrote:
> >
> > It's a timing issue mostly. I bet that udev is beating the kernel. The
> > klibc version is faster, as the code is much smaller. I'm working on
> > the proper fix for this now that we have the needed changes in libsysfs
> > for me to do this.
>
> with udev 009 libc all rules are ignored :
> and all devices are dumped in /udev (
>
> any ideas ?
Does the udev-test.pl script work? (you need to be root when running
it.)
thanks,
greg k-h
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id\x1278&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* Re: gcc version 2.95.3 20010315 (release/MontaVista) cross compiler
From: Guy Streeter @ 2003-12-17 23:17 UTC (permalink / raw)
To: David C. Chiu; +Cc: linuxppc-embedded
In-Reply-To: <8A098FDFC6EED94B872CA2033711F86F775A6F@orion.ariodata.com>
On Wed, 2003-12-17 at 17:02, David C. Chiu wrote:
> We're experiencing some unexpected behavior with binary generated with
> the said version of gcc; namely that variables declared to char appear
> to be defaulting to unsigned char.
>
> #include <stdio.h>
> #include <stdlib.h>
>
> int main( int argc, char** args, char** envs )
> {
> char sc;
> unsigned char uc;
>
> sc = uc = -3;
>
> printf( "signed char: %d unsigned char: %d\n", sc, uc );
> if ( sc > (char)0 )
> printf( "sc is greater than zero\n" );
> else
> printf( "sc is less or equal to zero\n" );
>
> return 0;
> }
>
> The preceeding code would produce the following unexpected result --
>
> signed char: 253 unsigned char: 253
> sc is greater than zero
>
> Making the following change --
>
> signed char sc;
> unsigned char uc;
> .
> .
>
> Would produce the expected result --
>
> signed char: -3 unsigned char: 253
> sc is less or equal to zero
>
> Can someone shed some light on this? (As in, is this "normal" and we do
> not know only because we've been living under a rock ;-)
This behavior is indeed "normal". For some reason (compatibility with
AIX, I think) the gcc compiler for ppc has always made char unsigned by
default.
Try adding the -fsigned-char option to you gcc command line.
--Guy
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [OT] "unauthorized" mini-pci wlan cards in thinkpads
From: Joel Jaeggli @ 2003-12-17 23:10 UTC (permalink / raw)
To: Jeremy Fitzhardinge; +Cc: Scott Mcdermott, linux-kernel, Bryan O'Sullivan
In-Reply-To: <1071619961.6205.28.camel@localhost.localdomain>
On Tue, 16 Dec 2003, Jeremy Fitzhardinge wrote:
>
> Bryan O'Sullivan just posted saying that he got an Atheros card from IBM
> which works, but only after a BIOS update. I've attached his message.
> I'm hoping to try one of these out myself soon (I've got a Cisco card,
> but the driver is really only just works).
tha seems likely since you can actually order an x31 with this card in it
at the moment.
> J
>
--
--------------------------------------------------------------------------
Joel Jaeggli Unix Consulting joelja@darkwing.uoregon.edu
GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
^ permalink raw reply
* Re: PCI Express support for 2.4 kernel
From: Andi Kleen @ 2003-12-17 23:22 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel
In-Reply-To: <13SY1-35z-19@gated-at.bofh.it>
Alan Cox <alan@redhat.com> writes:
>
> And X11 will want to access it via /proc interfaces. And someone will eventually
> go and design a different way to access PCI-EX for their hardware 8)
It would be nice if it did. Just currently it uses racy port accesses
from user space :-(
-Andi
^ permalink raw reply
* Re: filesystem bug?
From: Tsuchiya Yoshihiro @ 2003-12-17 23:24 UTC (permalink / raw)
To: tsuchiya; +Cc: Bryan Whitehead, Stephen C. Tweedie, linux-kernel
In-Reply-To: <3FDF95EB.2080903@labs.fujitsu.com>
Tsuchiya Yoshihiro wrote:
> Especially with Ext2 reproducing is easy, it happens in a few hours
> with my script.
> With Ext3, in a day if you are lucky.
>
> Now I am trying 2.4.23 from kernel.org with ext3, and 2.6.0-test11
> from kernel.org with ext3.
> So far, it's been a about a day, they are runing nicely. Let's see
> what happens.
>
> Following is the failed combination:
> Redhat9 with 2.4.20-8 ext2 and ext3
> Redhat9 with 2.4.20-19.9 ext2 and ext3
> Redhat9 with 2.4.20-24.9 ext2
I forgot to mention that I had been testing 2.4.20 from kernel.org
also.... And it failed now!
As you see below, /mnt/foo/ad/mozilla was gone. ad/mozilla had been used
to compare
with dir*/mozilla and it is basically read-only and will never be
removed by the script.
/mnt/foo/ae is ok and ae/mozilla is of cource there.
It had been almost 2days scince the test started, and the test was 58-th
turn.
It had run on ext2 filesystem, and the kernel was downloaded from
kernel.org.
I had seen the same problem--I mean read-only mozilla directory going
away--
on ext3 on redhat kernel 2.4.20-19.9.
[root@dell04 tsuchiya]# ls /mnt/foo/ad
dir0 dir14 dir2 dir25 dir30 dir36 dir41 dir47 dir52 dir58
dir1 dir15 dir20 dir26 dir31 dir37 dir42 dir48 dir53 dir6
dir10 dir16 dir21 dir27 dir32 dir38 dir43 dir49 dir54 dir7
dir11 dir17 dir22 dir28 dir33 dir39 dir44 dir5 dir55 dir8
dir12 dir18 dir23 dir29 dir34 dir4 dir45 dir50 dir56 dir9
dir13 dir19 dir24 dir3 dir35 dir40 dir46 dir51 dir57
[root@dell04 tsuchiya]# ls /mnt/foo/ae
dir0 dir14 dir2 dir25 dir30 dir36 dir41 dir47 dir52 dir58
dir1 dir15 dir20 dir26 dir31 dir37 dir42 dir48 dir53 dir6
dir10 dir16 dir21 dir27 dir32 dir38 dir43 dir49 dir54 dir7
dir11 dir17 dir22 dir28 dir33 dir39 dir44 dir5 dir55 dir8
dir12 dir18 dir23 dir29 dir34 dir4 dir45 dir50 dir56 dir9
dir13 dir19 dir24 dir3 dir35 dir40 dir46 dir51 dir57 mozilla
Yoshi
--
Yoshihiro Tsuchiya
^ permalink raw reply
* RE: ext3 file system
From: jshankar @ 2003-12-17 23:25 UTC (permalink / raw)
To: Richard B. Johnson, Mike Fedyk; +Cc: linux-fsdevel, linux-kernel
Hello,
Please provide some more insight.
Suppose a filesystem issues a write command to the disk with around 10 4K
Blocks to be written. SCSI device point of view i don't get what is the
parallel I/O.
It has only 1 write command. If some other sends a write request it needs to
be queued. But the next question arises how the write data would be handled.
Does it mean the SCSI does not give a response for the block of data written.
In otherwords does it mean that the response would be given after all the
block of data is written for a single write request.
Thanks
Jay
>===== Original Message From Mike Fedyk <mfedyk@matchmail.com> =====
>On Wed, Dec 17, 2003 at 05:25:49PM -0500, Richard B. Johnson wrote:
>> to the physical media. There are special file-systems (journaling)
>> that guarantee that something, enough to recover the data, is
>> written at periodic intervals.
>
>Most journaling filesystems make guarantees on the filesystem meta-data, but
>not on the data. Some like ext3, and reiserfs (with suse's journaling
>patch) can journal the data, or order things so that the data is written
>before any pointers (ie meta-data) make it to the disk so it will be harder
>to loose data.
>-
>To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: gcc version 2.95.3 20010315 (release/MontaVista) cross compiler
From: Bret Indrelee @ 2003-12-17 23:27 UTC (permalink / raw)
To: David C. Chiu; +Cc: linuxppc-embedded
In-Reply-To: <8A098FDFC6EED94B872CA2033711F86F775A6F@orion.ariodata.com>
On Wed, 17 Dec 2003, David C. Chiu wrote:
>
> We're experiencing some unexpected behavior with binary generated with
> the said version of gcc; namely that variables declared to char appear
> to be defaulting to unsigned char.
[ snip ]
> Can someone shed some light on this? (As in, is this "normal" and we do
> not know only because we've been living under a rock ;-)
It is allowable by the specification. C89 allowed char to be either
signed or unsigned, it was up to the implementation to decide which.
-Bret
--
Bret Indrelee QLogic Corporation
Bret.Indrelee@qlogic.com 6321 Bury Drive, St 13, Eden Prairie, MN 55346
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: PCI Express support for 2.4 kernel
From: Alan Cox @ 2003-12-17 23:38 UTC (permalink / raw)
To: Andi Kleen; +Cc: Alan Cox, linux-kernel
In-Reply-To: <m3hdzzni79.fsf@averell.firstfloor.org>
On Thu, Dec 18, 2003 at 12:22:02AM +0100, Andi Kleen wrote:
> Alan Cox <alan@redhat.com> writes:
> >
> > And X11 will want to access it via /proc interfaces. And someone will eventually
> > go and design a different way to access PCI-EX for their hardware 8)
>
> It would be nice if it did. Just currently it uses racy port accesses
> from user space :-(
Depends what patches you applied and how you built it 8) However XFree meets
hotplug is so unfunny its not good to consider before dinner, nor XFree meets
irqs or XFree meets SAK and high security models.
Linus had a nice comment that the basic DRI/fb modules should be dealing with
the PCI layer and perhaps exposing the DMA engine for newer cards (to trusted
parties). For older cards there are all sorts of reasons you don't want to do
this on the performance side but even then a driver which refused to free up
the PCI map space until X noticed the file handle was returning errors and
selected EOF would make a lot of the stuff sort out.
Maybe in part the GGI folks were right all those years ago. We had two extreme
views and the middle may be closer
Alan
^ permalink raw reply
* Re: cciss update for 2.4.24-pre1, 2 of 2
From: Andrew Morton @ 2003-12-17 23:49 UTC (permalink / raw)
To: Jens Axboe
Cc: mikem, marcelo.tosatti, linux-kernel, mike.miller, scott.benesh
In-Reply-To: <20031217225007.GN2495@suse.de>
Jens Axboe <axboe@suse.de> wrote:
>
> > + for (i=0; i < 1200; i++) {
> > + scratchpad = readl(c->vaddr + SA5_SCRATCHPAD_OFFSET);
> > + if (scratchpad == 0xffff0000) {
> > + ready = 1;
> > + break;
> > + }
> > + set_current_state(TASK_INTERRUPTIBLE);
> > + schedule_timeout(HZ / 10); /* wait 100ms */
> > + }
> > + if (!ready) {
> > + printk(KERN_WARNING "cciss: Board not ready. Timed out.\n");
> > + return -1;
> > + }
>
> Fine as well, aren't you happy you changed this to schedule_timeout()
> instead of busy looping? :)
It will still be a busy loop if this task has a signal pending.
TASK_UNINTERRUPTIBLE may be more appropriate...
^ permalink raw reply
* adaptec 1210sa, lost interrupt
From: Mickael Marchand @ 2003-12-17 23:49 UTC (permalink / raw)
To: linux-ide
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
anyone has a small idea of what to do to make it work ?
I tried both siimage and sata_sil (libata) with it, all got locked with
interrupt/dma stuff with 2.4/2.6 latest patches, noapic noacpi (dma
enabled/disabled)
I feel pretty curious on the fact that the 2 channels wants to use the same
IRQ and it tries to share it with another device (on my K7 it tried to share
IRQ 5 with my soundcard, so i removed the soundcard but that did not help
either).
Maybe I am wrong, but it looks really strange to me that both channels use the
same IRQ and I wonder if the channels are conflicting with each other.
I tried also to disable the share IDE interrupts in kernel, but it does not
seem to change anything.
So if you have ideas/comments about it, I can try them ...
maybe I will try to disable one of the ports and see if that helps.
Dec 17 14:25:46 moria kernel: Adaptec AAR-1210SA: IDE controller at PCI slot
0000:00:11.0
Dec 17 14:25:46 moria kernel: PCI: Found IRQ 5 for device 0000:00:11.0
Dec 17 14:25:46 moria kernel: PCI: Sharing IRQ 5 with 0000:00:0b.0
Dec 17 14:25:46 moria kernel: Adaptec AAR-1210SA: chipset revision 2
Dec 17 14:25:46 moria kernel: Adaptec AAR-1210SA: 100%% native mode on irq 5
Dec 17 14:25:46 moria kernel: ide2: MMIO-DMA at 0xd09b9e00-0xd09b9e07,
BIOS settings: hde:pio, hdf:pio
Dec 17 14:25:46 moria kernel: ide3: MMIO-DMA at 0xd09b9e08-0xd09b9e0f,
BIOS settings: hdg:pio, hdh:pio
Dec 17 14:25:46 moria kernel: hde: ST3120026AS, ATA DISK drive
please CC me.
cheers,
Mik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/4OtwyOYzc4nQ8j0RAg9tAKCZ/iS0U/RhafUgYwyv6jcZa9DyrACeIKX1
KjYHUaeWsMZvc0yG3y5JBfo=
=swKN
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: ext3 file system
From: Brad Boyer @ 2003-12-17 23:59 UTC (permalink / raw)
To: jshankar; +Cc: Richard B. Johnson, Mike Fedyk, linux-fsdevel, linux-kernel
In-Reply-To: <3FF18FD8@webmail.colostate.edu>
I think the big thing that you're missing is that block device requests
are totally asynchronous. In general, a block gets sent down to the
block layer as needing to be transfered one way or the other. It gets
queued up in the driver for that block device, such as sd.o for SCSI.
That driver will be notified that it has requests to process, and
can handle them however it wants. When it is done with any specific
request, it calls back up and sets that request as done. You could
have multiple requests in the queue at the same time, and a driver
can be working on more than one at a time if it supports that.
In the specific case of SCSI, the host adapter and disk drives may
support various queues along the way, with any number of outstanding
requests in various buffers. The controller may be able to merge
requests on the fly in order to improve performance.
Obviously this is a fairly abstract view of the whole process. For
details you would need to read the code. You can trace the process
down (filesystem -> page buffers -> block devices -> block driver).
In the SCSI case, the block driver is sd.o, and you then can follow
down into the generic SCSI mid-layer and the controller driver.
Brad Boyer
flar@allandria.com
On Wed, Dec 17, 2003 at 04:25:11PM -0700, jshankar wrote:
> Please provide some more insight.
>
> Suppose a filesystem issues a write command to the disk with around 10 4K
> Blocks to be written. SCSI device point of view i don't get what is the
> parallel I/O.
> It has only 1 write command. If some other sends a write request it needs to
> be queued. But the next question arises how the write data would be handled.
> Does it mean the SCSI does not give a response for the block of data written.
> In otherwords does it mean that the response would be given after all the
> block of data is written for a single write request.
^ 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.