Re: make menuconfig versus make xconfig, Kernel 2.4
"Joachim Backes wrote:" > I made an update from Kernel 2.2.19 to 2.4.4, and I made > a copy from the 2.2.19 .config file into the 2.4.4 directory. > > After that, I was wondering about the following fact: > > "make menuconfig" for kernel 2.4.4 showed (what seems to > be correct) for ATA/IDE the same kernel configuration, as it > was shown in 2.2.19, when using the 2.2.19 ".config". > > But: 2.4.4 "make xconfig" using the 2.2.19 .config showed > a disabled ATA/IDE configuration. > > Only after saving the 2.4.4 configuration produced by "make menuconfig", > then the configuration for ATA/IDE was correctly displayed by "make xconfig". The Menuconfig behaviour is probably incorrect. CONFIG_IDE is missing. Try make oldconfig first. -- === Andrzej M. Krzysztofowicz [EMAIL PROTECTED] phone (48)(58) 347 14 61 Faculty of Applied Phys. & Math., Technical University of Gdansk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
make menuconfig versus make xconfig, Kernel 2.4
I made an update from Kernel 2.2.19 to 2.4.4, and I made a copy from the 2.2.19 .config file into the 2.4.4 directory. After that, I was wondering about the following fact: "make menuconfig" for kernel 2.4.4 showed (what seems to be correct) for ATA/IDE the same kernel configuration, as it was shown in 2.2.19, when using the 2.2.19 ".config". But: 2.4.4 "make xconfig" using the 2.2.19 .config showed a disabled ATA/IDE configuration. Only after saving the 2.4.4 configuration produced by "make menuconfig", then the configuration for ATA/IDE was correctly displayed by "make xconfig". Regards Joachim Backes -- Joachim Backes <[EMAIL PROTECTED]> | Univ. of Kaiserslautern Computer Center, High Performance Computing | Phone: +49-631-205-2438 D-67653 Kaiserslautern, PO Box 3049, Germany | Fax: +49-631-205-3056 -+ WWW: http://hlrwm.rhrk.uni-kl.de/home/staff/backes.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB broken in 2.4.4? Serial Ricochet works, USB performance sucks.
On Thu, May 10, 2001 at 08:07:50PM -0700, Drew Bertola wrote:
>
> Joey Hess had a problem similar to what you described, though he noticed
> it while using the pcmcia ricochet modem. He passed along this patch:
Doh! I've only fixed this same kind of problem about 3 different times
in the usb-serial drivers. clameter, could you try the attached patch
against 2.4.4 and see if that fixes the MTU issue for you?
Thanks Drew for reminding me of this.
greg k-h
--- linux-2.4.4/drivers/usb/acm.c Fri Feb 16 16:06:17 2001
+++ linux-2.4/drivers/usb/acm.c Thu May 10 21:29:29 2001
@@ -233,8 +240,14 @@
dbg("nonzero read bulk status received: %d", urb->status);
if (!urb->status & !acm->throttle) {
- for (i = 0; i < urb->actual_length && !acm->throttle; i++)
+ for (i = 0; i < urb->actual_length && !acm->throttle; i++) {
+ /* if we insert more than TTY_FLIPBUF_SIZE characters,
+* we drop them. */
+ if (tty->flip.count >= TTY_FLIPBUF_SIZE) {
+ tty_flip_buffer_push(tty);
+ }
tty_insert_flip_char(tty, data[i], 0);
+ }
tty_flip_buffer_push(tty);
}
Re: Possible README patch
Anuradha Ratnaweera writes: > > On Sat, 5 May 2001, Russell King wrote: > > > gzip -dc linux-2.4.XX.tar.gz | tar zvf - > > gzip -dc patchXX.gz | patch -p0 > > This does _not_ work for international kernel patch. They assume the > directories lin.2.x.x/ (old) and int.2.x.x/ (new) and not linux/. > Therefore it _is_ necessary to `cd linux' and do a `patch -p1'. Yes, but this document is about the official final patches Linus and Alan release for 2.2.x and 2.4.x, not about arbitrary kernel patches that are available. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: page_launder() bug
On Mon, 7 May 2001, J . A . Magallon wrote: > > On 05.07 Helge Hafting wrote: > > > > !0 is 1. !(anything else) is 0. It is zero and one, not > > zero and "non-zero". So a !! construction gives zero if you have > > zero, and one if you had anything else. There's no doubt about it. > > > > > Isn't this asking for trouble with the optimizer ? It could kill both > !!. Using that is like trusting on a certain struct padding-alignment. > It isn't, or rather it can't. Because !!x is not x unless x is one or zero. Anuradha - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux + Compaq Presario Laptop
On Mon, 7 May 2001, Bohdan Vlasyuk wrote: > Hi !! I'm running linux on Compaq Presario 1215 Laptop. Kernel is, > as shipped with RH 7.0, 2.2.16. I am running 2.4.4 on a Presario 1615 (debian 2.2 with updates) without problems. I had to turn on allow interrupts in APM settings, in order to get the machine running after returning from `sleep' mode (Fn + F3). Anuradha -- http://www.bee.lk/people/anuradha/;>home page - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible README patch
On Sat, 5 May 2001, Russell King wrote: > gzip -dc linux-2.4.XX.tar.gz | tar zvf - > gzip -dc patchXX.gz | patch -p0 This does _not_ work for international kernel patch. They assume the directories lin.2.x.x/ (old) and int.2.x.x/ (new) and not linux/. Therefore it _is_ necessary to `cd linux' and do a `patch -p1'. Anuradha -- http://www.bee.lk/people/anuradha/;>home page - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: null pointer dereference in ibmtr
On Thu, 10 May 2001, SodaPop wrote: > When inserting the ibmtr.o module in any of the 2.4 series kernels, I get a > null pointer crash. Latest try was 2.4.4. Ksymoops: Hi, there is a known issue at least I know for the imbtr_cs after a debugging session with a friend last weekend. You might want to try http://www.linuxtr.net/download/ibmtr-all.2.4.2-ac28.patch.gz till there is an official patch for 2.4.4. Due to some changes from 2.4.2 to 2.4.4 patch doesn't apply clean but it's only few lines in rej-file you will have to fix manually. Redhat unfortunately included this patch in their 2.4.2 rh7.1 kernel though it is not in the official kernel confusing people even more. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
usb uhci & 8139too ON 2.4.2
Hello, I recently compiled the 2.4.2 with usb support. I also brought a ethernet card based on the 8139too.o driver. When i insert the module, the following message keeps blurting out: kernel: uhci: host controller halted. very bad kernel: uhci: host controller halted. very bad kernel: uhci: host controller halted. very bad . . . this happens only when i insert the 8139too module. else the usb works fine, and detects the usb devices. Is there anything i am missing or should be doing... Any help or suggestions would be very helpful. Thanks. srimg. __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.4.4, Adaptec 7880 on board controller
>Hi, > >when booting on a machine having an Adaptec 7880 on board >controller (Kernel 2.4.4), then i get the following msg: > >... >... > >SCSI subsystem driver Revision: 1.00 >request_module[scsi_hostadapter]: Root fs not mounted >request_module[scsi_hostadapter]: Root fs not mounted >request_module[scsi_hostadapter]: Root fs not mounted This was fixed post v6.1.5 of the aic7xxx driver. You can obtain patches for the latest version from here: http://people.FreeBSD.org/~gibbs/linux/ -- Justin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.4-ac6 compile error in plip.c
On Thu, 10 May 2001 08:46:43 -0500, Moses McKnight <[EMAIL PROTECTED]> wrote: >Hi, I get the following error trying to compile 2.4.4-ac6 using gcc >2.95.4 (debian package). > >plip.c:1412: __setup_str_plip_setup causes a section type conflict The first __initdata is marked as const, the second is not, a section cannot contain both const and non-const data. Against 2.4.4-ac6. Index: 4.16/drivers/net/plip.c --- 4.16/drivers/net/plip.c Thu, 26 Apr 2001 12:38:49 +1000 kaos (linux-2.4/l/c/23_plip.c 1.2.1.3 644) +++ 4.16(w)/drivers/net/plip.c Fri, 11 May 2001 14:50:39 +1000 kaos +(linux-2.4/l/c/23_plip.c 1.2.1.3 644) @@ -120,7 +120,7 @@ #include -static const char version[] __initdata = +static char version[] __initdata = KERN_INFO "NET3 PLIP version 2.4-parport [EMAIL PROTECTED]\n"; /* Maximum number of devices to support. */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kernel 2.4.4, Adaptec 7880 on board controller
Hi, when booting on a machine having an Adaptec 7880 on board controller (Kernel 2.4.4), then i get the following msg: ... ... SCSI subsystem driver Revision: 1.00 request_module[scsi_hostadapter]: Root fs not mounted request_module[scsi_hostadapter]: Root fs not mounted request_module[scsi_hostadapter]: Root fs not mounted ... ... The aic7xxx scsi driver is not configured as module, but linked to the kernel. 1. Despite of this messages, my kernel is running without any problem. 2. No such msg when using 2.2.x kernels 3. No such msg with kernel 2.4.4, when using an Adaptec 29xxx controler. Any idea? Regards Joachim Backes -- Joachim Backes <[EMAIL PROTECTED]> | Univ. of Kaiserslautern Computer Center, High Performance Computing | Phone: +49-631-205-2438 D-67653 Kaiserslautern, PO Box 3049, Germany | Fax: +49-631-205-3056 -+ WWW: http://hlrwm.rhrk.uni-kl.de/home/staff/backes.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: eepro100/usb interrupts stop with 2.4.x kernels?
Alan Cox <[EMAIL PROTECTED]> writes: > > What seems to happen is that the kernel stops seeing interrupts on the > > IRQ shared by eth0 (my outside interface) and usb-uhci. I can still > > ssh in on eth1, and when I do, syslog contains things like "eth0: > > Interrupt timed out" and usb-uhci griping about devices that failed to > > accept new endpoints. > > Do you see this if you run a -ac kernel or apply the APIC 440BX patch ? I haven't tried either, but I'm about to reboot into 2.4.4-ac4 to see if it helps. If it still happens, I'll get more of the syslog output and try to figure out what got wedged. -- Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB broken in 2.4.4? Serial Ricochet works, USB performance sucks.
On Wed, May 09, 2001 at 11:25:26PM -0700, [EMAIL PROTECTED] wrote:
> On Wed, 9 May 2001, Greg KH wrote:
>
> > On Wed, May 09, 2001 at 11:09:36PM -0700, [EMAIL PROTECTED] wrote:
> > >
> > > Allright then you should first check why the ACM driver is unable to
> > > handle an MTU of 1500. I had to set it to 232 or 500 to make it work at
> > > all. With an MTU of 1500 it does ICMP but not long tcp packets. There is
> > > some issue with long packets that might exceed some buffer size(?).
> >
> > I don't see anything in the ACM driver that would cause a problem for
> > large MTU settings. It is probably a device limitation, not the driver.
>
> The Richochet USB stuff uses generic serial I/O. No special driver. And it
> works fine under Win/ME. Have you run a regular PPP connection over the
> ACM driver with an MTU of 1500?
Joey Hess had a problem similar to what you described, though he noticed
it while using the pcmcia ricochet modem. He passed along this patch:
--- Serial.c.orig Fri Feb 2 12:55:44 2001
+++ serial.cFri Feb 2 12:56:43 2001
@@ -569,10 +569,16 @@
icount = >state->icount;
do {
-
+ /*
+* Check if flip buffer is full -- if it is, try to
flip,
+* and if flipping got queued, return immediately
+*/
+ if (tty->flip.count >= TTY_FLIPBUF_SIZE) {
+ tty->flip.tqueue.routine((void *) tty);
+ if (tty->flip.count >= TTY_FLIPBUF_SIZE)
+ return;
+ }
ch = serial_inp(info, UART_RX);
- if (tty->flip.count >= TTY_FLIPBUF_SIZE)
- goto ignore_char;
*tty->flip.char_buf_ptr = ch;
icount->rx++;
--
Drew Bertola | Send a text message to my pager or cell ...
| http://jpager.com/Drew
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Question: Status of USAGI/FreeSWAN?
On Thu, May 10, 2001 at 01:28:25AM -0600, Dax Kelson wrote: > > FreeSWAN has IPSec for IPv4 on Linux. > > USAGI is better/more conformant IPv6 (with IPSec for IPv6 in development) > for Linux. > > The USAGI goal is to get themselves folded into the official kernel (and > glibc) at some point "in the near future". > > What are the plans to get all this (FreeSWAN,USAGI) folded into the > kernel. Are the "crypto" legal issues resolved enough now to have crypto > in the official kernel? It would nice to not to have to chase down all > these seperate components and eventually manually patch. > > I'm going a bit crazy keeping track of several different kernel patches > (IPSec,IPv6 in particular) while my *BSD friends just laugh at me. :) > > Dax > You'll probably get more response if you don't reply to an anready existing thread. Just create another message with the exact above and try again without replying... Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Riva console frame buffer
> Right now when I bootup it's in 640x480, and I change it to 1024x768 @70Hz > w/ fbset in /etc/rc.local . I would like to give the kernel an arg to > startup in 1024x768; eg video=riva:mode:1024x768-70,ypan,vc:1-8 > > Is there a way to do this w/ the riva frame buffer? Is there a list of > kernel args for the riva frame buffer? Yes. Most fbdev drivers use modedb which provides a standard easy way to select a video resolution. video=riva:x[-][@refresh] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] writepage method changes
On Thu, 10 May 2001, Chris Mason wrote: > > > On Wednesday, May 09, 2001 10:51:17 PM -0300 Marcelo Tosatti > <[EMAIL PROTECTED]> wrote: > > > > > > > On Wed, 9 May 2001, Marcelo Tosatti wrote: > > > >> Locked for the "not wrote out case" (I will fix my patch now, thanks) > > > > I just found out that there are filesystems (eg reiserfs) which write out > > data even if an error ocurred, which means the unlocking must be done by > > the filesystems, always. > > I'm not horribly attached to the way reiserfs is doing it right now. If > reiserfs writepage manages to map any blocks, it writes them to disk, even > if mapping other blocks in the page failed. These are only data blocks, so > there are no special consistency rules. If we need to change this, it is > not a big deal. No need for that. Its saner leaving this control to the filesystems. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ncr53c8xx - DAT detection problem - 2.2.14-5
Any clues as to why /dev/st0 is never initialized for DAT tape? Please cc [EMAIL PROTECTED] if more info is needed. rgds, tim. ... ncr53c8xx: at PCI bus 1, device 9, function 0 ncr53c8xx: 53c876 detected ncr53c8xx: at PCI bus 1, device 9, function 1 ncr53c8xx: 53c876 detected ncr53c876-0: rev=0x14, base=0xc6ffdf00, io_port=0x3000, irq=5 ncr53c876-0: ID 7, Fast-20, Parity Checking ncr53c876-0: on-chip RAM at 0xc6fff000 ncr53c876-0: restart (scsi reset). ncr53c876-0: Downloading SCSI SCRIPTS. ncr53c876-1: rev=0x14, base=0xc6ffde00, io_port=0x3400, irq=9 ncr53c876-1: ID 7, Fast-20, Parity Checking ncr53c876-1: on-chip RAM at 0xc6ffe000 ncr53c876-1: restart (scsi reset). ncr53c876-1: Downloading SCSI SCRIPTS. scsi0 : ncr53c8xx - version 3.2a-2 scsi1 : ncr53c8xx - version 3.2a-2 scsi : 2 hosts. Vendor: COMPAQModel: BD0096349ARev: 3B05 Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sda at scsi0, channel 0, id 0, lun 0 Vendor: COMPAQModel: BD0096349ARev: 3B05 Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sdb at scsi0, channel 0, id 1, lun 0 ncr53c876-0-<0,0>: tagged command queue depth set to 8 ncr53c876-0-<1,0>: tagged command queue depth set to 8 Vendor: SEAGATE Model: DAT04106-XXX Rev: 735B Type: Sequential-Access ANSI SCSI revision: 02 ncr53c876-0-<0,*>: FAST-20 WIDE SCSI 40.0 MB/s (50 ns, offset 16) SCSI device sda: hdwr sector= 512 bytes. Sectors= 17773524 [8678 MB] [8.7 GB] sda: sda1 sda2 < sda5 > ncr53c876-0-<1,*>: FAST-20 WIDE SCSI 40.0 MB/s (50 ns, offset 16) SCSI device sdb: hdwr sector= 512 bytes. Sectors= 17773524 [8678 MB] [8.7 GB] sdb: sdb1 sdb2 < sdb5 sdb6 sdb7 > ... /sbin/lspci -v 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (AGP disa bled) (rev 03) Flags: bus master, medium devsel, latency 64 Memory at (32-bit, prefetchable) 00:0b.0 VGA compatible controller: Cirrus Logic GD 5446 (rev 45) (prog-if 00 [VGA] ) Flags: medium devsel Memory at c400 (32-bit, prefetchable) Memory at c6dff000 (32-bit, non-prefetchable) 00:0d.0 PCI bridge: Digital Equipment Corporation DECchip 21150 (rev 04) (prog-if 00 [Normal decode]) Flags: bus master, medium devsel, latency 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 Capabilities: [dc] Power Management version 1 00:0e.0 System peripheral: Compaq Computer Corporation: Unknown device a0f0 Subsystem: Compaq Computer Corporation: Unknown device b0f3 Flags: medium devsel I/O ports at 1800 Memory at c6dfdf00 (32-bit, non-prefetchable) 00:12.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08) Subsystem: Intel Corporation EtherExpress PRO/100+ Management Adapter Flags: bus master, medium devsel, latency 64, IRQ 10 Memory at c6dfe000 (32-bit, non-prefetchable) I/O ports at 2000 Memory at c6e0 (32-bit, non-prefetchable) Capabilities: [dc] Power Management version 2 00:14.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) Flags: bus master, medium devsel, latency 0 00:14.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) (prog-if 80 [Master]) Flags: bus master, medium devsel, latency 64 I/O ports at f100 00:14.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01)(prog-if 00 [UHCI]) Flags: medium devsel I/O ports at 5800 00:14.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02) Flags: medium devsel 01:07.0 Network controller: Compaq Computer Corporation ProLiant Integrated Netelligent 10/100 (rev 10) Flags: medium devsel I/O ports at 5820 01:09.0 SCSI storage controller: Symbios Logic Inc. (formerly NCR) 53c875 (rev 14) Subsystem: Compaq Computer Corporation Embedded Ultra Wide SCSI Controller Flags: bus master, medium devsel, latency 255, IRQ 5 I/O ports at 3000 Memory at c6ffdf00 (32-bit, non-prefetchable) Memory at c6fff000 (32-bit, non-prefetchable) 01:09.1 SCSI storage controller: Symbios Logic Inc. (formerly NCR) 53c875 (rev 14) Subsystem: Compaq Computer Corporation Embedded Ultra Wide SCSI Controller Flags: bus master, medium devsel, latency 255, IRQ 9 I/O ports at 3400 Memory at c6ffde00 (32-bit, non-prefetchable) Memory at c6ffe000 (32-bit, non-prefetchable) -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Detecting Red Hat builds ?
On Thu, 10 May 2001 17:25:29 +0100 (BST), [EMAIL PROTECTED] wrote: >The problem is I have a driver that includes syncppp.h which in the releases >from kernel.org is in linux/drivers/net/wan/ up to and including 2.4.2 after >which it moves to linux/include/net/. Do it in the Makefile. Untested: ifneq ($(wildcard $(TOPDIR)/include/net/syncppp.h),) CFLAGS_driver_name.o += -I $(TOPDIR)/include/net else CFLAGS_driver_name.o += -I $(TOPDIR)/drivers/net/wan endif and the driver does #include "syncppp.h". - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.4 kernel freeze for unknown reason
Hi Mark, I think you pin-pointed one of the possible reason of the unknown freeze.. which is FB mode. Yes, I am using FB mode.. hm.. I will go back to recompile my kernel without FB mode and see whether this method can fix my problem or not. You are right for the other assumption, I am running the harddisk in UDMA w/32bits mode. Are you suggesting me to turn off both functions? But if I turn them off, the performance will decrease alot. Is there any way I can get any crash information? e.g. any function I can turn on for logging or something? Thanks for your reply.. Best Regards, Jacky Liu "Genius or Wacko? Majority or Minority?" >Date: Thu, 10 May 2001 10:24:30 -0400 (EDT) >From: Mark Hahn <[EMAIL PROTECTED]> >To: Jacky Liu <[EMAIL PROTECTED]> >SUBJECT >> I would like to post a question regarding to a problem of unknown freeze of my >linux firewall/gateway. > >since it's a gateway/firewall, is it safe to assume you're not running >the video in graphics or framebuffer mode? there were plenty of problems >on machines like this the chipset never releasing the PCI bus from >ownership by the video card. the result was a hang, of course. > >is it also safe to assume that you have the disk running in dma/udma mode? >(not just that it's a udma33-capable!) > > >> >> Here is the hardware configuration of my machine: >> >> AMD K-6 233 MHz >> 2theMax P-55 VP3 mobo >> 64Mb RAM in a single module (PC-100) >> Maxtor 6G UDMA-33 harddisk >> Matrox MG-II display card w/8Mb RAM >> 3Com 3C905B-TX NIC >> RealTek 8129 10/100 NIC >> >> It's running 2.4.4 kernel (RedHat 7.1) and acting as a firewall using Netfilter >(gShield and Snort), DNS (Cache-Only DNS) and NAT gateway (ip-masq.) for my home >network. I used 3C905B-TX NIC as my internal NIC and RealTek 8129 as my external NIC. >Here is the problem: >> >> The machine has been randomly lockup (totally freeze) for number of times without >any traceable clue or error message. Usually the time frame between each lockup is >between 24 to 72 hours. The screen just freeze when it's lockup (either in Console or >X) and no "kernel panic" type or any error message prompt up. All services (SSH, DNS, >etc..) are dead when it's lockup and I cannot find any useful information in >/var/log/messages. I cannot reproduce the lockup since it's totally randomly. The >lockup happened either when I was playing online game (A LOT, like getting thousands >of server status in counter-strike in a very short time frame, of NAT traffic), >surfing the web (normal traffic) or the machine was totally in idle (lockup when I >was sleeping). It was lockup this morning when I was playing online game (when my >game machine was trying to establish connection to a game server). >> >> If there is any information you would like to obtain, please let me know. I would >like to receive a copy of your reply, thank you very much for your kindly attention. >> >> Best Regards, >> Jacky Liu >> >> "Genius or Wacko? Majority or Minority?" >> >> >> --== Sent via Deja.com ==-- >> http://www.deja.com/ >> - >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >> the body of a message to [EMAIL PROTECTED] >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> Please read the FAQ at http://www.tux.org/lkml/ >> > >-- >operator may differ from spokesperson. [EMAIL PROTECTED] > http://java.mcmaster.ca/~hahn --== Sent via Deja.com ==-- http://www.deja.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: eepro100/usb interrupts stop with 2.4.x kernels?
> What seems to happen is that the kernel stops seeing interrupts on the > IRQ shared by eth0 (my outside interface) and usb-uhci. I can still > ssh in on eth1, and when I do, syslog contains things like "eth0: > Interrupt timed out" and usb-uhci griping about devices that failed to > accept new endpoints. Do you see this if you run a -ac kernel or apply the APIC 440BX patch ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Not a typewriter
> I disagree. "Not a typewriter" is part of Unix tradition, and ought to be > retained as a historical reference. It's also an opportunity for "the > uninitiated" to learn a little more and move a little closer to becoming "the > initiated." Thats fine. Keep it for the 'Install seriously weird prehistoric stuff' option that most users really don't want Alan [who hacked on a GCOS3 box, used DDT on a DEC10 and VTECO and quite frankly thinks Gnome and KDE are probably the future not them] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lp486e.c for 2.4
> Now that on-board ethernet on the lp486e (also known as > lpe486 and as elp486 and as PWS and as `Reuters') works > out of the box under 2.2.19, people started asking about 2.4. > A patch is found at > ftp.XX.kernel.org/.../kernel/people/aeb/lp486e.c-for-2.4.4 > It works (has gotten all of two minutes testing). > Comments are welcome. Thanks. Unfortunately my lp486e committed suicide today, of the blue smoke escaping bad smell ex powersupply variety [which btw is why folks got mail timeouts] I'll merge that soon Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Not a typewriter
> > If anything it should be "Not a teletype" > > fork it and see which code base the users support! ;) (would support the > one that doesn't mention !#@$%#$ typewriters. that irritated me for months > when i used DYNIX and my terms never worked properly.) You can internationalise the error string in glibc to something else if you wish. Confining 'not a teletyte' to bell-prehistoric language tables wouldnt be that bad a thing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Not a typewriter
At 8:07 PM -0400 2001-05-10, Alexander Viro wrote: >On Thu, 10 May 2001, Jonathan Lundell wrote: > >> ENOTTY is used by several non-serial devices (or file systems) to >> object to an unrecognized ioctl command. There's also ENOIOCTLCMD >> (apparently supposed to be a non-user errno, but i don't see where it >> gets changed to something else) and EINVAL. I'm not sure what the >> rationale is for choosing among them; perhaps someone would elucidate? > >ENOIOCTLCMD is something I've never met in the kernel. Normal reaction >to unrecognized ioctl() is ENOTTY, for a lot of reasons, starting with >the fact that ioctls are last-ditch API to be used when you just can't >think of better one and historically TTY had the earliest (and largest) >infestation. IOW, "not a tty" used to mean "WTF are you using ioctls here?" >OTOH, EINVAL is a catch-all thing for "something is wrong with arguments". That's pretty much what I would have said a couple of hours ago before grepping the kernel. Try it, though. ENOTTY is rarely used. ENOIOCTLCMD is all over the damned place, though its comment in errno.h warns that a user shouldn't see it. And if you browse a bunch of random ioctl handlers, you'll see EINVAL used for a bad command much more often than ENOTTY. FWIW, the comment in errno.h under Solaris 2.6 is "Inappropriate ioctl for device". I believe that's the POSIX interpretation. -- /Jonathan Lundell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel 2.4 doesn't work in Sparc IPX
Rafael Diniz writes: > Why kernel 2.4 doesn't work in Sparcs IPX? > It's a good machine and I want to continue to use Linux on it... So please continue to use 2.2.x kernels until we get someone to maintain the sun4c port in 2.4.x. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Riva console frame buffer
List, Hi... I'm trying to use the riva console frame buffer driver under x86 linux. It works, but not the way I want it to, and I'm having a hard time finding info about kernel args for the riva frame buffer. Right now when I bootup it's in 640x480, and I change it to 1024x768 @70Hz w/ fbset in /etc/rc.local . I would like to give the kernel an arg to startup in 1024x768; eg video=riva:mode:1024x768-70,ypan,vc:1-8 Is there a way to do this w/ the riva frame buffer? Is there a list of kernel args for the riva frame buffer? my hardware: VGA compatible controller: nVidia Corporation Vanta [NV6] (rev 15) mag DX700T kernel 2.4.3ac14 and 2.4.4ac3 thank you, -- Sean J. Swallow pgp (6.5.2) keyfile @ https://nurk.org/keyfile.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][CFT] (updated) ext2 directories in pagecache
On Thursday 10 May 2001 22:53, Andreas Dilger wrote: > OK, here are the patches described above. > > The first one changes the use of the various INDEX flags, so that > they only appear when we have mounted with "-o index" (or > COMPAT_DIR_INDEX) and actually created an indexed directory. > > The second one changes the i_nlink counting on indexed dirs so that > if it overflows the 16-bit i_link_count field it is set to 1 and we > no longer track link counts on this directory. > > Unfortunately, they haven't been tested. I've given them several > eyeballings and they appear OK, but when I try to run the ext2 index > code (even without "-o index" mount option) my system deadlocks > somwhere inside my ext2i module (tight loop, but SysRQ still works). > I doubt it is due to these patches, but possibly because I am also > working on ext3 code in the same kernel. I'm just in the process of > getting kdb installed into that kernel so I can find out just where > it is looping. I'll apply and test them in uml tomorrow (3 am here now). By the way, uml was made in heaven for this sort of filesystem development. Err, actually it was made by Jeff, but I guess that makes him some kind of angel :-) -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][CFT] (updated) ext2 directories in pagecache
On Wednesday 09 May 2001 23:22, you wrote: > Daniel writes [re index directories]: > > This is lightly tested and apparently stable. > > I was looking at the new patch, and I saw something that puzzles me. > Why do you set the EXT2_INDEX_FL on a new (empty) directory, rather > than only setting it when the dx_root index is created? This makes it follow the rule: new directories will be created with an index. (Never mind that the index creation is deferred.) Now, if you think it's ok to add an index to any directory that grows past one block that's fine with me. I was looking for a little more predictable behavriour. A couple of lines of code will go away and the is_dx(dir) tests will get a little faster if we just use 'dir grew past a block' as the rule. > Setting the flag earlier than that makes it mostly useless, since it > will be set on basically every directory. Not setting it would also > make your is_dx() check simply a check for the EXT2_INDEX_FL bit (no > need to also check size). Yep. > Also no need to set EXT2_COMPAT_DIR_INDEX until such a time that we > have a (real) directory with an index, to avoid gratuitous > incompatibility with e2fsck. > > Cheers, Andreas Again yep, you decide, I will fix, or I see a few posts down you have changed the patch, also fine. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] for iso8859-13
Patch for Documentation/Configure.help in 2.4.4-ac6. Adds missing iso8859-13 to CONFIG_NLS_DEFAULT and corrects some texts. --- Configure.helpFri May 11 01:52:15 2001 +++ Configure.help.newFri May 11 02:02:53 2001 @@ -12567,8 +12567,8 @@ cp862, cp863, cp864, cp865, cp866, cp869, cp874, cp932, cp936, cp949, cp950, cp1251, cp1255, euc-jp, euc-kr, gb2312, iso8859-1, iso8859-2, iso8859-3, iso8859-4, iso8859-5, iso8859-6, iso8859-7, - iso8859-8, iso8859-9, iso8859-14, iso8859-15, koi8-r, koi8-ru, - koi8-u, sjis, tis-620, utf8. + iso8859-8, iso8859-9, iso8859-13, iso8859-14, iso8859-15, + koi8-r, koi8-ru, koi8-u, sjis, tis-620, utf8. If you specify a wrong value, it will use the built-in NLS; compatible with iso8859-1. @@ -12605,7 +12605,8 @@ DOS/Windows partitions correctly. This does apply to the filenames only, not to the file contents. You can include several codepages; say Y here if you want to include the DOS codepage that is used - for the Baltic Rim Languages. If unsure, say N. + for the Baltic Rim Languages (Latvian and Lithuanian). If unsure, + say N. Codepage 850 (Europe) CONFIG_NLS_CODEPAGE_850 @@ -12804,7 +12805,7 @@ say Y here if you want to include the DOS codepage for Traditional Chinese(Big5). -NLS ISO 8859-1 (Latin 1; Western European Languages) +NLS ISO 8859-1 (Latin 1; Western European Languages) CONFIG_NLS_ISO8859_1 If you want to display filenames with native language characters from the Microsoft FAT file system family or from JOLIET CDROMs @@ -12815,7 +12816,7 @@ Galician, Irish, Icelandic, Italian, Norwegian, Portuguese, Spanish, and Swedish. It is also the default for the US. If unsure, say Y. -NLS ISO 8859-2 (Latin 2; Slavic/Central European Languages) +NLS ISO 8859-2 (Latin 2; Slavic/Central European Languages) CONFIG_NLS_ISO8859_2 If you want to display filenames with native language characters from the Microsoft FAT file system family or from JOLIET CDROMs @@ -12825,7 +12826,7 @@ languages: Czech, German, Hungarian, Polish, Rumanian, Croatian, Slovak, Slovene. -NLS ISO 8859-3 (Latin 3; Esperanto, Galician, Maltese, Turkish) +NLS ISO 8859-3 (Latin 3; Esperanto, Galician, Maltese, Turkish) CONFIG_NLS_ISO8859_3 If you want to display filenames with native language characters from the Microsoft FAT file system family or from JOLIET CDROMs @@ -12834,16 +12835,16 @@ set, which is popular with authors of Esperanto, Galician, Maltese, and Turkish. -NLS ISO 8859-4 (Latin 4; old Baltic charset) +NLS ISO 8859-4 (Latin 4; old Baltic charset) CONFIG_NLS_ISO8859_4 If you want to display filenames with native language characters from the Microsoft FAT file system family or from JOLIET CDROMs correctly on the screen, you need to include the appropriate input/output character sets. Say Y here for the Latin 4 character set which introduces letters for Estonian, Latvian, and - Lithuanian. It is an incomplete predecessor of Latin 6. + Lithuanian. It is an incomplete predecessor of Latin 7. -NLS ISO 8859-5 (Cyrillic) +NLS ISO 8859-5 (Cyrillic) CONFIG_NLS_ISO8859_5 If you want to display filenames with native language characters from the Microsoft FAT file system family or from JOLIET CDROMs @@ -12853,7 +12854,7 @@ Macedonian, Russian, Serbian, and Ukrainian. Note that the charset KOI8-R is preferred in Russia. -NLS ISO 8859-6 (Arabic) +NLS ISO 8859-6 (Arabic) CONFIG_NLS_ISO8859_6 If you want to display filenames with native language characters from the Microsoft FAT file system family or from JOLIET CDROMs @@ -12861,7 +12862,7 @@ input/output character sets. Say Y here for ISO8859-6, the Arabic character set. -NLS ISO 8859-7 (Modern Greek) +NLS ISO 8859-7 (Modern Greek) CONFIG_NLS_ISO8859_7 If you want to display filenames with native language characters from the Microsoft FAT file system family or from JOLIET CDROMs @@ -12877,7 +12878,7 @@ input/output character sets. Say Y here for ISO8859-8, the Hebrew character set. -NLS ISO 8859-9 (Latin 5; Turkish) +NLS ISO 8859-9 (Latin 5; Turkish) CONFIG_NLS_ISO8859_9 If you want to display filenames with native language characters from the Microsoft FAT file system family or from JOLIET CDROMs @@ -12886,7 +12887,7 @@ set, and it replaces the rarely needed Icelandic letters in Latin 1 with the Turkish ones. Useful in Turkey. -nls iso8859-10 +NLS ISO 8859-10 (Latin 6; Nordic) CONFIG_NLS_ISO8859_10 If you want to display filenames with native language characters from the Microsoft FAT file system family or from JOLIET CDROMs @@ -12902,7 +12903,8 @@ from the Microsoft FAT file system family or from JOLIET CDROMs correctly on the screen, you need to include the appropriate input/output character sets. Say Y here for the Latin 7 character - set, which supports modern Baltic languages including Latvian. + set, which supports modern Baltic languages
eepro100/usb interrupts stop with 2.4.x kernels?
Since about 2.4.2, I have been seeing intermittent hangs on my system; usually once or twice a week, but once just 10 minutes after rebooting. What seems to happen is that the kernel stops seeing interrupts on the IRQ shared by eth0 (my outside interface) and usb-uhci. I can still ssh in on eth1, and when I do, syslog contains things like "eth0: Interrupt timed out" and usb-uhci griping about devices that failed to accept new endpoints. I'm not sure if for some reason my chipset stopped passing these interrupts on to the kernel, or if the kernel got into some funny state and stopped accepting those interrupts. Any hints on where I should look? >From /proc/interrupts now: CPU0 CPU1 0: 243741 233914IO-APIC-edge timer 1: 4 0IO-APIC-edge keyboard 2: 0 0 XT-PIC cascade 8: 0 0IO-APIC-edge rtc 10: 0 0 IO-APIC-level EMU10K1 11: 18775 17937 IO-APIC-level usb-uhci, eth0 12: 1221 1236 IO-APIC-level eth1 14: 84039 68162IO-APIC-edge ide0 15: 18 18 IO-APIC-level BusLogic BT-950 NMI: 0 0 LOC: 477548 477547 ERR: 0 -- Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Not a typewriter
[EMAIL PROTECTED] wrote: > > On 05/10/2001 at 05:38:32 PM [EMAIL PROTECTED] (H. Peter Anvin) wrote: > > >Sounds like someone has just clarified what the heck it means. "tty" > >and "typewriter" aren't exactly the same thing (even though "tty" > >stands for "teletypewriter" it has come to mean something completely > >different in a Unix context)... "not a typewriter" is just a > >completely confusing error message for the uninitiated. > > I disagree. "Not a typewriter" is part of Unix tradition, and ought to be > retained as a historical reference. It's also an opportunity for "the > uninitiated" to learn a little more and move a little closer to becoming "the > initiated." > Nowhere else in Unix is a "tty" referred to as a "typewriter". "Not a tty" is one thing; "Not a typewriter" is just plain misleading. -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kernel 2.4 doesn't work in Sparc IPX
Why kernel 2.4 doesn't work in Sparcs IPX? It's a good machine and I want to continue to use Linux on it... [root@rafael rafael2k]# cat /proc/cpuinfo cpu : Fujitsu or Weitek Power-UP fpu : Fujitsu or Weitek on-chip FPU promlib : Version 2 Revision 2 prom: 2.3 type: sun4c ncpus probed: 1 ncpus active: 1 BogoMips: 39.83 vacsize : 65536 bytes vachwflush : yes vaclinesize : 32 bytes mmuctxs : 8 mmupsegs: 256 kernelpsegs : 41 kfreepsegs : 0 usedpsegs : 54 ufreepsegs : 125 user_taken : 9 max_taken : 147 Thanks Rafael Diniz Brazil - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Not a typewriter
On Thu, 10 May 2001, Jonathan Lundell wrote: > ENOTTY is used by several non-serial devices (or file systems) to > object to an unrecognized ioctl command. There's also ENOIOCTLCMD > (apparently supposed to be a non-user errno, but i don't see where it > gets changed to something else) and EINVAL. I'm not sure what the > rationale is for choosing among them; perhaps someone would elucidate? ENOIOCTLCMD is something I've never met in the kernel. Normal reaction to unrecognized ioctl() is ENOTTY, for a lot of reasons, starting with the fact that ioctls are last-ditch API to be used when you just can't think of better one and historically TTY had the earliest (and largest) infestation. IOW, "not a tty" used to mean "WTF are you using ioctls here?" OTOH, EINVAL is a catch-all thing for "something is wrong with arguments". - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
{ DriveReady SeekComplete }
Hello,
Just got a message:
hda: status error: status=0x50 { DriveReady SeekComplete }
hda: no DRQ after issuing MULTWRITE
hda is: QUANTUM FIREBALL CX10.2A, 9787MB w/418kB Cache, CHS=19885/16/63, UDMA(33)
Promise Ultra100 controller.
# hdparm /dev/hda
/dev/hda:
multcount= 8 (on)
I/O support = 3 (32-bit w/sync)
unmaskirq= 1 (on)
using_dma= 1 (on)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead= 8 (on)
geometry = 1247/255/63, sectors = 20044080, start = 0
# hdparm -i /dev/hda
/dev/hda:
Model=QUANTUM FIREBALL CX10.2A, FwRev=A3F.0B00, SerialNo=133918662657
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=32256, SectSize=21298, ECCbytes=4
BuffType=DualPortCache, BuffSize=418kB, MaxMultSect=16, MultSect=8
CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=20044080
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4
AdvancedPM=no
Drive Supports : ATA/ATAPI-4 T13 1153D revision 15 : ATA-1 ATA-2 ATA-3 ATA-4
2.2.19 with ide.2.2.19.03252001.patch.
Is something wrong with disk?
Regards,
Nerijus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs, xfs, ext2, ext3
On Thu, 10 May 2001, Hans Reiser wrote: > > Hmm... Reiserfs is incompatible with knfsd? That might explain the > > we have a patch on our website. I'm always wondering why the patch hasn't been merged. Is it so dangerous to apply in that it might distract other pieces of the system? Has anyone reported increased problems after applying the patch? -- Matthias Andree - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs, xfs, ext2, ext3
On Thu, 10 May 2001, Tony Hoyle wrote: > Hmm... Reiserfs is incompatible with knfsd? That might explain the > massive data loss I was getting with reiserfs (basically I'd have to > reformat and reinstall every couple of weeks). The machine this was > happening with also exports my apt cache for the rest of the network. You're not getting data loss, but access denied, when hitting incompatibilities, and it looks like it hits 2.2 hard while 2.4 is less of a problem. Please search the reiserfs list archives for details. vs-13048 is a good search term, I believe. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Not a typewriter
At 7:20 PM -0400 2001-05-10, Hacksaw wrote: > >I disagree. "Not a typewriter" is part of Unix tradition, and ought to be >>retained as a historical reference. It's also an opportunity for "the >>uninitiated" to learn a little more and move a little closer to becoming "the >>initiated." > >Heaven help us when tradition is more important than clarity. > >Typewriter has always been wrong. I'd agree that "Not a teletypewriter" would >suffice. > >On the other hand "Inappropriate ioctl for device" is also not very clear. > >I'd like to see "Not a serial or character device" or "Not a serial device" if >that's more appropriate. Something like that... ENOTTY is used by several non-serial devices (or file systems) to object to an unrecognized ioctl command. There's also ENOIOCTLCMD (apparently supposed to be a non-user errno, but i don't see where it gets changed to something else) and EINVAL. I'm not sure what the rationale is for choosing among them; perhaps someone would elucidate? -- /Jonathan Lundell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Not a typewriter
>I disagree. "Not a typewriter" is part of Unix tradition, and ought to be >retained as a historical reference. It's also an opportunity for "the >uninitiated" to learn a little more and move a little closer to becoming "the >initiated." Heaven help us when tradition is more important than clarity. Typewriter has always been wrong. I'd agree that "Not a teletypewriter" would suffice. On the other hand "Inappropriate ioctl for device" is also not very clear. I'd like to see "Not a serial or character device" or "Not a serial device" if that's more appropriate. Something like that... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Not a typewriter
On 05/10/2001 at 05:38:32 PM [EMAIL PROTECTED] (H. Peter Anvin) wrote: >Sounds like someone has just clarified what the heck it means. "tty" >and "typewriter" aren't exactly the same thing (even though "tty" >stands for "teletypewriter" it has come to mean something completely >different in a Unix context)... "not a typewriter" is just a >completely confusing error message for the uninitiated. I disagree. "Not a typewriter" is part of Unix tradition, and ought to be retained as a historical reference. It's also an opportunity for "the uninitiated" to learn a little more and move a little closer to becoming "the initiated." Wayne - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.3 Kernel Freeze with highmem BUG at highmem.c:155 - CRASH
> The symptons were an ever more sluggish machine over time, memory usage > looked pretty standard with the majority of memory assigned to cache... what > would happen is that at terminal it would go into semi-freeze states of about > 5-10 seconds (increasing with time), where no user interaction was possible. > By terminal I mean through a ssh remote terminal The load would also > occasionally just increase for no apparent reason to values of 7,8,9... I reported the same sluggishness problem on Feb 25. Capsule summary is 64GB option does not work. I was easily able to reproduce the sluggishness in 2.4.2, but need to test again for 2.4.4. See if your problem goes away with the 4GB option. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
8GB large memory slowdowns (possible mtrr problem)
Hello, I have been following the mailing list for some time and seen 1 reference to big memory related slowdowns in the 2.4.x series of kernels which seem related. Waiting for the latest version of the kernel to see if it would clear up the issues which I believe are related to mtrr mis-assigning regions has not fixed the issue. I have been experiencing severe performance slowdowns when using the 4GB or 64GB memory options in the stock 2.4.4 kernel. When using the 1GB option performace is ok, but unfortuntly does not allow access to the 8GB which are installed in the machine. The severe memory problems seem to be out of line with the overhead for the three layer memory addressing in the 64GB memory scheme. Simple commands such as 'ls' take half a second instead of the customary .009 seconds in the lower memory configuration. The system is: 4 x 700Mhz Xeon PIII w/2MB cache 8GB ECC RAM Supermicro S2QR6 ServerWorks ServerSet III HE Chipset MB AMI Bios 3-Ware raid controller running raid5 in hardware mtrr is enabled in all situations and /proc/mtrr has always (in "off", "4GB" and "64GB" memory modes) said: borg.corp[root]~# cat /proc/mtrr reg00: base=0x ( 0MB), size=8192MB: write-back, count=1 reg01: base=0xfc00 (4032MB), size= 64MB: uncachable, count=1 There is no problem with the system registering the whole amount of RAM, and we haven't had any problem with crashes in the limited tests we have done. The interesting part is that certain system calls take long periods to complete, this was most evident when stracing the command. The system physical RAM information is as follows: BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e - 0010 (reserved) BIOS-e820: 0010 - fcdf (usable) BIOS-e820: fcdf - fcdff000 (ACPI data) BIOS-e820: fcdff000 - fce0 (ACPI NVS) BIOS-e820: fec0 - fec01000 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: fff8 - 0001 (reserved) BIOS-e820: 0001 - 0002 (usable) In the message to the list on Jan 15, 2001 by Mr. Ingo he recommended another person with slowdown problems to force a memory map on the system. We looked throught the kernel source and found that the mem= commands can only parse and return long words, not long long words. We therefore only looked to use the following memory areas: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0010 - fcdf (usable) for a total of approximently 4GB. This yielded a lilo line that looks like: append="mem=exactmap mem=0x0009fc00@0x mem=0xfccf@0x0010" We had hoped that this would yield faster performance and would allow us to manually add using echo "..." >| /proc/mtrr the final 4GB block: BIOS-e820: 0001 - 0002 (usable) Unfortunently when we ran this configuration the /proc/mtrr looked the same as before. The kernel looked like it knew it was passed the correct lines and I am still at a loss to make my MTRR look like the MTRR settings that was talked of. I have included 2 system boot logs as attachments to this letter. One is with the exactmap lines, the other is the kernel booting normally. I hope that this will cover anything I have not been able to cover. Any help is greatly appreciated. Shay boot: linux-serial Loading linux-serial Linux version 2.4.3TV ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #2 SMP Thu Apr 5 01:13:24 PDT 2001 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e - 0010 (reserved) BIOS-e820: 0010 - fcdf (usable) BIOS-e820: fcdf - fcdff000 (ACPI data) BIOS-e820: fcdff000 - fce0 (ACPI NVS) BIOS-e820: fec0 - fec01000 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: fff8 - 0001 (reserved) BIOS-e820: 0001 - 0002 (usable) Warning only 4GB will be used. Use a PAE enabled kernel. 3200MB HIGHMEM available. Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. found SMP MP-table at 000fb4d0 hm, page 000fb000 reserved twice. hm, page 000fc000 reserved twice. hm, page 000f5000 reserved twice. hm, page 000f6000 reserved twice. On node 0 totalpages: 1048576 zone(0): 4096 pages. zone(1): 225280 pages. zone(2): 819200 pages. Intel MultiProcessor Specification v1.1 Virtual Wire compatibility mode. OEM ID: AMI Product ID: CNB20HE APIC at: 0xFEE0 Processor
Re: Wow! Is memory ever cheap!
Followup to: <[EMAIL PROTECTED]> By author:Edgar Toernig <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > I think you have a wrong idea why the ECC is there. ECC deals with > the inherit shortcommings of DRAM. > > DRAMs are not perfect. They have a probability to lose a bit. > Normally this probability is low enough to live with it. Lets say > you have a system with 1MByte and let's say the probability for a > single bit error is around 1 error in 100 years. Good enough. > Now put 1GByte in the system. You'll get a probability of 10 errors > per year. Maybe good enough for a Windows box but not acceptable > for your server. So you put in ECC to bring this probability back > into reasonable numbers. ECC can correct the single bit errors. > You only have to deal with double bit errors. Chance for them is > much much lower. > Yes, ECC, unlike parity, is a technique for reducing the error rate, with the side benefit of intercepting an error when it happens. I am not disagreeing with Larry that integrity checks are a Good Thing[TM], and in general are a hallmark of good engineering. However, they are not a replacement for ECC for the purpose of driving the failure rate down into an acceptable probability range. It is of course a very nice thing that DRAM prices have come down into the range where buying them in gigabyte quantities are reasonable :) -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Not a typewriter
Followup to: <[EMAIL PROTECTED]> By author:"Richard B. Johnson" <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > I noticed that my favorite "errno" has now gotten trashed by > the newer 'C' runtime libraries. > > ENOTTY has been for ages, "Not a typewriter". > It's now been changed to "Inappropriate ioctl for device". > > Methinks that this means that ../linux/include/asm/errno.h now needs > to be updated: > > > -#define ENOTTY 25 /* Not a typewriter */ > +#define ENOTTY 25 /* Inappropriate ioctl for device > */ > > None of these strings are in the kernel, but the headers probably should > show the "latest standard". > Sounds like someone has just clarified what the heck it means. "tty" and "typewriter" aren't exactly the same thing (even though "tty" stands for "teletypewriter" it has come to mean something completely different in a Unix context)... "not a typewriter" is just a completely confusing error message for the uninitiated. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: ACPI broken in 2.4.4-ac6
ACPI now has more config options. Make sure you enable bus manager and system driver, at the very least. Regards -- Andy > From: Mike Panetta [mailto:[EMAIL PROTECTED]] > ACPI seems to be broken on 2.4.4-ac6 or atleast > poweroff is broken. During bootup all ACPI > prints is that it was enabled, it used to > (in plain jane 2.4.4) print the sleep levels > supported by the bios but does not in ac6. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ACPI broken in 2.4.4-ac6
ACPI seems to be broken on 2.4.4-ac6 or atleast poweroff is broken. During bootup all ACPI prints is that it was enabled, it used to (in plain jane 2.4.4) print the sleep levels supported by the bios but does not in ac6. What could be the cause? Thanks, Mike -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs, xfs, ext2, ext3
On linux-kernel, [EMAIL PROTECTED] (Andi Kleen) wrote: : On one not very scientific test: unpacking and deleting a cache hot 40MB/230MB : gzipped/unzipped tar on ext2 and xfs on a IDE drive on a lowend SMP box. : : XFS (very recent 2.4.4 CVS, filesystem created with mkxfs defaults) : : > time tar xzf ~ak/src.tgz : real1m58.125s : user0m16.410s : sys 0m44.350s : > time rm -rf src/ : real0m50.344s : user0m0.190s : sys 0m13.950s : : ext2 (on same kernel as above) : : > time tar xzf ~ak/src.tgz : : real1m26.126s : user0m16.100s : sys 0m36.080s : : > time rm -rf src/ : : real0m1.085s : user0m0.160s : sys 0m0.930s And another test: ext2: root@witch:/mobile:# time tar xzf /arc/test.tar.gz real5m25.249s user1m33.430s sys 0m31.710s root@witch:/mobile:# time rm -rf test/ real0m8.843s user0m0.000s sys 0m0.420s xfs: root@witch:/mobile:# time tar xzf /arc/test.tar.gz real5m23.744s user1m34.800s sys 0m39.100s root@witch:/mobile:# time rm -rf test/ real0m1.364s user0m0.030s sys 0m0.430s test.tar.gz is tree created by script: #!/bin/bash for lev1 in aa bb cc dd ee ff gg hh ii jj kk ll do mkdir $lev1 cd $lev1 for lev2 in 0 1 2 3 4 5 6 7 do mkdir $lev2 cd $lev2 for fname in a b c d e f g h i do dd if=/dev/urandom of=$fname bs=4k count=1024 done cd .. done cd .. done -- Daniel Podlejski <[EMAIL PROTECTED]> ... When you're talkin to yourself and nobody's home You can fool yourself, you came in this world alone ... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Volunteers needed
> I suspect that the main way to get this thing fixed is to make sure > ECN is enabled on the server side; for example, we have turned on ECN > on kernel.org. If a user is using a broken software stack, it's their > loss, not ours. I agree it's the server side that will eventuelly push it through, but don't expect miracles. I informed the sysadmins at the place where I work that ftp.kernel.org isn't reachable anymore for us, only to get a long reply full of reasons (some better than others) why they wouldn't act. The final statement was: "use one of the many ftp..kernel.org mirrors". MCE -- M. Eyckmans (MCE) Code of the Geeks v3.1 [EMAIL PROTECTED] GCS d+ s+:- a35 C+++$ UHLUASO+++$ P+ L+++ E--- W++ N+++ !o K w--- !O M-- V-- PS+ PE+ Y+ PGP- t--- !5 !X R- tv- b+ DI++ D-- G++ e+++ h+(*) !r y? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs, xfs, ext2, ext3
On Thu, May 10, 2001 at 01:44:53PM +0200, Matthias Andree wrote: [snip] > If you're deploying a cache partition such as /var/squid (possibly > having log files in another /var/log partition on another disk drive), > what's the point about not running (e. g.) mke2fs and squid -z on boot, > as well as mounting the system partitions (/usr) read-only (prevents > fsck on next reboot)? mke2fs is faster than reiserfs recovery probably > ;-) A while ago I configured a few squid boxes which ran off of a read-only system. Mke2fs is actually unacceptably slow on large file systems, faster then fsck, but still time consuming. I found that zeroing out the disk, then formating it and saving the non-zero blocks, replaying them on reboot to be an acceptable solution. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
No Problems At All
I have no problems at all right now. Thank you for making Linux work so well. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Not a typewriter
I noticed that my favorite "errno" has now gotten trashed by the newer 'C' runtime libraries. ENOTTY has been for ages, "Not a typewriter". It's now been changed to "Inappropriate ioctl for device". Methinks that this means that ../linux/include/asm/errno.h now needs to be updated: -#defineENOTTY 25 /* Not a typewriter */ +#defineENOTTY 25 /* Inappropriate ioctl for device */ None of these strings are in the kernel, but the headers probably should show the "latest standard". Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Deadlock in 2.2 sock_alloc_send_skb?
On Thu, May 10, 2001 at 11:17:17PM +0200, Andi Kleen wrote: > On Thu, May 10, 2001 at 11:13:00PM +0200, Andrea Arcangeli wrote: > > On Thu, May 10, 2001 at 07:30:47PM +0200, Andi Kleen wrote: > > > On Thu, May 10, 2001 at 01:57:49PM +0100, Alan Cox wrote: > > > > > If that happens, and the socket uses GFP_ATOMIC allocation, the while (1) > > > > > loop in sock_alloc_send_skb() will endlessly spin, without ever calling > > > > > schedule(), and all the time holding the kernel lock ... > > > > > > > > If the socket is using GFP_ATOMIC allocation it should never loop. That is > > > > -not-allowed-. > > > > > > It is just not clear why any socket should use GFP_ATOMIC. I can understand > > > it using GFP_BUFFER e.g. for nbd, but GFP_ATOMIC seems to be rather radical > > > and fragile. > > > > side note, the only legal use of GFP_ATOMIC in sock_alloc_send_skb is > > with noblock set and fallback zero, remeber GFP_BUFFER will sleep, it > > may not sleep in vanilla 2.2.19 but the necessary lowlatency hooks in > > the memory balancing that for example I have on my 2.2 tree will make it > > to sleep. > > Even with nonblock set the socket code will sleep in some circumstances > (e.g. when aquiring the socket lock) so interrupt operation is out anyways. > > > > The patch self contained looks perfect (I didn't checked that the > > callers are happy with a -ENOMEM errorcode though), if alloc_skb() > > failed that's a plain -ENOMEM. The caller must _not_ try again, they > > must take a recovery fail path instead. > > I think the callers are likely broken. > The patch is still good of course, but not for GFP_ATOMIC. you said interrupt won't call that function so I don't see the GFP_ATOMIC issue. I also don't what's the issue with GFP_ATOMIC regardless somebody uses it or not, the patch itself has nothing to do with GFP_ATOMIC. All gfpmasks can fail, allock_skb can fail regardless of the gfpmask, not only GFP_ATOMIC will fail, of course GFP_ATOMIC can fail even if the machine is not totally out of memory but you never know and you cannot assume anything and when alloc_skb fails you must assume the machine is totally out of memory or you will deadlock, so if alloc_skb fails we must return -ENOMEM and take the fail path and the patch does the right thing in such case as well. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ATAPI Tape Driver Failure in Kernel 2.4.4, More
> > to do is be able to write to the tape, but not read from it. > > Even in 2.2.x, putting the IDE patches in, breaks it. Apparently > > the HP's aren't completely ATAPI compatible scsi0 : SCSI host adapter emulation for IDE ATAPI devices scsi : 1 host. Vendor: HPModel: COLORADO 20GB Rev: 4.01 Type: Sequential-Access ANSI SCSI revision: 02 Detected scsi tape st0 at scsi0, channel 0, id 0, lun 0 The following all work with the above, either ide.2.2.19.04092001.patch or ide.2.2.18.1221.patch: linux-2.2.19pre17-ide linux-2.2.19-intel-hpt-smp linux-2.2.19-amd-via-ide linux-2.2.20p2-amd-via-ide [14:17] abit:/etc/dump > more *.block :: dump0-abit-2.2.19-050401-06:43:36.block :: / 0 dump /usr90113 dump /var3593378 dump /tmp3675075 dump /home 3692644 dump /kits 5237605 dump /big9440550 dump :: dump1-abit-2.2.20-050901-17:10:08.block :: / 14567911dump /usr14574120dump /var14810569dump /tmp14832970dump /home 14833227dump /kits 15199116dump /big15850029dump [14:17] abit:/etc/dump > mt seek 14567911 [14:18] abit:/etc/dump > mt tell At block 14567911. [14:20] abit:/etc/dump > /sbin/restore -t -f /dev/nst0 | head Level 1 dump of / on abit:/dev/hda2 Label: "abit-2.2.20" Dump date: Wed May 9 17:11:53 2001 Dumped from: Fri May 4 06:43:36 2001 2 . 11 ./lost+found 4065 ./lost+found/#4065 4019 ./dev 4030 ./dev/initctl 4083 ./dev/audio 4084 ./dev/audio1 4111 ./dev/console rgds, tim. -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Alpha SMP/Network performance problem with vanilla 2.4.4
I'm working on a problem on alpha SMP on the AS4100 (Rawhide) machine. Under SMP, with heavy network activity. With an inbound and outbound ping flood running, after about 500,000 packets, it just dies. Console dead, no response. For about a minute. Then, sometimes, the machine comes back. Anything I can instrument? to help? Alt-sysrq, though enabled, does not seem to work on these machine's consoles. -- Jay Thorne Manager, Systems & Technology, UserFriendly Media, Inc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Deadlock in 2.2 sock_alloc_send_skb?
On Thu, May 10, 2001 at 11:13:00PM +0200, Andrea Arcangeli wrote: > On Thu, May 10, 2001 at 07:30:47PM +0200, Andi Kleen wrote: > > On Thu, May 10, 2001 at 01:57:49PM +0100, Alan Cox wrote: > > > > If that happens, and the socket uses GFP_ATOMIC allocation, the while (1) > > > > loop in sock_alloc_send_skb() will endlessly spin, without ever calling > > > > schedule(), and all the time holding the kernel lock ... > > > > > > If the socket is using GFP_ATOMIC allocation it should never loop. That is > > > -not-allowed-. > > > > It is just not clear why any socket should use GFP_ATOMIC. I can understand > > it using GFP_BUFFER e.g. for nbd, but GFP_ATOMIC seems to be rather radical > > and fragile. > > side note, the only legal use of GFP_ATOMIC in sock_alloc_send_skb is > with noblock set and fallback zero, remeber GFP_BUFFER will sleep, it > may not sleep in vanilla 2.2.19 but the necessary lowlatency hooks in > the memory balancing that for example I have on my 2.2 tree will make it > to sleep. Even with nonblock set the socket code will sleep in some circumstances (e.g. when aquiring the socket lock) so interrupt operation is out anyways. > The patch self contained looks perfect (I didn't checked that the > callers are happy with a -ENOMEM errorcode though), if alloc_skb() > failed that's a plain -ENOMEM. The caller must _not_ try again, they > must take a recovery fail path instead. I think the callers are likely broken. The patch is still good of course, but not for GFP_ATOMIC. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Deadlock in 2.2 sock_alloc_send_skb?
On Thu, May 10, 2001 at 07:30:47PM +0200, Andi Kleen wrote: > On Thu, May 10, 2001 at 01:57:49PM +0100, Alan Cox wrote: > > > If that happens, and the socket uses GFP_ATOMIC allocation, the while (1) > > > loop in sock_alloc_send_skb() will endlessly spin, without ever calling > > > schedule(), and all the time holding the kernel lock ... > > > > If the socket is using GFP_ATOMIC allocation it should never loop. That is > > -not-allowed-. > > It is just not clear why any socket should use GFP_ATOMIC. I can understand > it using GFP_BUFFER e.g. for nbd, but GFP_ATOMIC seems to be rather radical > and fragile. side note, the only legal use of GFP_ATOMIC in sock_alloc_send_skb is with noblock set and fallback zero, remeber GFP_BUFFER will sleep, it may not sleep in vanilla 2.2.19 but the necessary lowlatency hooks in the memory balancing that for example I have on my 2.2 tree will make it to sleep. The patch self contained looks perfect (I didn't checked that the callers are happy with a -ENOMEM errorcode though), if alloc_skb() failed that's a plain -ENOMEM. The caller must _not_ try again, they must take a recovery fail path instead. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
lp486e.c for 2.4
Now that on-board ethernet on the lp486e (also known as lpe486 and as elp486 and as PWS and as `Reuters') works out of the box under 2.2.19, people started asking about 2.4. A patch is found at ftp.XX.kernel.org/.../kernel/people/aeb/lp486e.c-for-2.4.4 It works (has gotten all of two minutes testing). Comments are welcome. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.4.4ac4] Kernel crash while unmounting CD
[1.] One line summary of the problem:
Kernel panic when trying to unmount a ide-scsi cdrom.
[2.] Full description of the problem/report:
With Kernel 2.4.4 ac4 I got a kernelpanic while trying to unmount an
ide-scsi-device.
What I did:
1. Burning the cdrom (647 MB raw data; medium 700 MB) with cdrecord 1.10,
compiled on this system with this kernel.
2. Burning ended successfully with no errors and no warnings.
3. After burning, the cd was ejected automatically.
4. Closing the tray with the new burned CD and mounting the CD.
5. the mounting takes a lot of time, but finally, the CD has been mounted. A
ls -l on the root of the CD takes a lot of time again. But finally, the
output of ls -l appeared.
6. umount of the CD. This took a lot of time until the Kernel crashed:
<0> Kernel panic. Attempt to kill the idle task. In idle task not syncing.
<1> unable to handle NULL pointer dereference at virtual address ... [I
hoped, the oops had been logged in messages - nope; is there any way to save
the output of this kernel oops?]
Before the oops, you can read the following in /var/log/messages:
May 9 17:24:47 athlon kernel: SCSI subsystem driver Revision: 1.00
May 9 17:24:47 athlon kernel: scsi0 : SCSI host adapter emulation for IDE
ATAPI devices
May 9 17:24:47 athlon kernel: Vendor: Model: ATAPI CDROM.48X
Rev: 120Y
May 9 17:24:47 athlon kernel: Type: CD-ROM
ANSI SCSI revision: 02
May 9 17:24:47 athlon kernel: Vendor: PHILIPS Model: CDD3610 CD-R/RW
Rev: 3.01
May 9 17:24:47 athlon kernel: Type: CD-ROM
ANSI SCSI revision: 02
[...]
May 9 18:09:33 athlon kernel: ISO 9660 Extensions: Microsoft Joliet Level 3
May 9 18:09:33 athlon kernel: ISO 9660 Extensions: RRIP_1991A
May 9 18:10:07 athlon kernel: scsi : aborting command due to timeout : pid
0, scsi0, channel 0, id 1, lun 0 Read (10) 00 00 00 00 26 00 00 01 00
May 9 18:10:07 athlon kernel: hdd: timeout waiting for DMA
May 9 18:10:07 athlon kernel: ide_dmaproc: chipset supported ide_dma_timeout
func only: 14
May 9 18:10:07 athlon kernel: hdd: irq timeout: status=0xd0 { Busy }
May 9 18:10:07 athlon kernel: hdd: DMA disabled
May 9 18:10:09 athlon kernel: hdd: ATAPI reset complete
May 9 18:10:09 athlon kernel: hdd: irq timeout: status=0xd0 { Busy }
May 9 18:10:12 athlon kernel: hdd: ATAPI reset complete
May 9 18:10:12 athlon kernel: hdd: irq timeout: status=0xd0 { Busy }
May 9 18:10:12 athlon kernel: scsi0 channel 0 : resetting for second half of
retries.
May 9 18:10:12 athlon kernel: SCSI bus is being reset for host 0 channel 0.
May 9 18:10:12 athlon kernel: hdd: status timeout: status=0xd0 { Busy }
May 9 18:10:12 athlon kernel: hdd: drive not ready for command
May 9 18:10:20 athlon kernel: hdd: ATAPI reset complete
May 9 18:10:20 athlon kernel: SCSI cdrom error : host 0 channel 0 id 1 lun 0
return code = 2702
May 9 18:10:20 athlon kernel: I/O error: dev 0b:01, sector 152
May 9 18:10:21 athlon kernel: scsi0 : channel 0 target 1 lun 0 request sense
failed, performing reset.
May 9 18:10:21 athlon kernel: SCSI bus is being reset for host 0 channel 0.
May 9 18:10:21 athlon kernel: SCSI cdrom error : host 0 channel 0 id 1 lun 0
return code = 1802
May 9 18:10:21 athlon kernel: sd0b:01: old sense key None
May 9 18:10:21 athlon kernel: Non-extended sense class 0 code 0x0
May 9 18:10:21 athlon kernel: I/O error: dev 0b:01, sector 152
May 9 18:10:41 athlon kernel: scsi0 : channel 0 target 1 lun 0 request sense
failed, performing reset.
May 9 18:10:41 athlon kernel: SCSI bus is being reset for host 0 channel 0.
May 9 18:10:41 athlon kernel: SCSI cdrom error : host 0 channel 0 id 1 lun 0
return code = 1802
May 9 18:10:41 athlon kernel: sd0b:01: old sense key None
May 9 18:10:41 athlon kernel: Non-extended sense class 0 code 0x0
May 9 18:10:41 athlon kernel: I/O error: dev 0b:01, sector 152
May 9 18:10:41 athlon kernel: scsi0 : channel 0 target 1 lun 0 request sense
failed, performing reset.
May 9 18:10:41 athlon kernel: SCSI bus is being reset for host 0 channel 0.
May 9 18:10:41 athlon kernel: SCSI cdrom error : host 0 channel 0 id 1 lun 0
return code = 1802
May 9 18:10:41 athlon kernel: sd0b:01: old sense key None
May 9 18:10:41 athlon kernel: Non-extended sense class 0 code 0x0
May 9 18:10:41 athlon kernel: I/O error: dev 0b:01, sector 152
May 9 18:10:48 athlon kernel: scsi0 : channel 0 target 1 lun 0 request sense
failed, performing reset.
May 9 18:10:48 athlon kernel: SCSI bus is being reset for host 0 channel 0.
May 9 18:10:50 athlon kernel: scsi0 : channel 0 target 1 lun 0 request sense
failed, performing reset.
7. Reboot. I couldn't mount any more this CD with my burning device Philips
CDD 3610 (ATAPI-burner). The following log appears:
May 9 18:18:02 athlon kernel: SCSI subsystem driver Revision: 1.00
May 9 18:18:02 athlon kernel: scsi0 : SCSI host adapter emulation for IDE
ATAPI devices
May
Re: [PATCH][CFT] (updated) ext2 directories in pagecache
I previously wrote:
> I have changed the code to do the following:
> - If the COMPAT_DIR_INDEX flag is set at mount/remount time, set the
> INDEX mount option (the same as "mount -o index"). This removes
> the need to specify the "-o index" option each time for filesystems
> which already have indexed directories.
> - New directories NEVER have the INDEX flag set on them.
> - If the INDEX mount option is set, then when directories grow past 1
> block (and have the index added) they will get the directory INDEX
> flag set and turn on the superblock COMPAT_DIR_INDEX flag (if off).
>
> This means that you can have common code for indexed and non-indexed ext2
> filesystems, and the admin either needs to explicitly set COMPAT_DIR_INDEX
> in the superblock or mount with "-o index" (and create a directory > 1 block).
>
> I have also added some tricks to ext2_inc_count() and ext2_dec_count() so
> that indexed directories are not subject to the EXT2_LINK_MAX. I've done
> the same as reiserfs, and set i_nlink = 1 if we overflow EXT2_LINK_MAX
> (which has been increased to 65500 for indexed directories). Apparently
> i_nlink = 1 is the right think to do w.r.t. find and other user tools.
OK, here are the patches described above.
The first one changes the use of the various INDEX flags, so that they
only appear when we have mounted with "-o index" (or COMPAT_DIR_INDEX)
and actually created an indexed directory.
The second one changes the i_nlink counting on indexed dirs so that if
it overflows the 16-bit i_link_count field it is set to 1 and we no
longer track link counts on this directory.
Unfortunately, they haven't been tested. I've given them several
eyeballings and they appear OK, but when I try to run the ext2 index code
(even without "-o index" mount option) my system deadlocks somwhere
inside my ext2i module (tight loop, but SysRQ still works). I doubt
it is due to these patches, but possibly because I am also working on
ext3 code in the same kernel. I'm just in the process of getting kdb
installed into that kernel so I can find out just where it is looping.
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
diff -u linux/ext2.orig/dir.c linux/ext2/dir.c
--- linux/ext2.orig/dir.c Thu May 10 12:10:22 2001
+++ linux/ext2/dir.cThu May 10 11:09:51 2001
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#ifndef assert
@@ -201,6 +204,21 @@
return hash0;
}
+static void ext2_update_to_indexed(struct inode *dir)
+{
+ struct super_block *sb = dir->i_sb;
+
+ if (test_opt(sb, INDEX) && !EXT2_HAS_COMPAT_FEATURE(sb, DIR_INDEX)) {
+ dxtrace_on(printk("Adding COMPAT_DIR_INDEX feature flag\n"));
+ ext2_update_dynamic_rev(sb);
+ lock_kernel();
+ EXT2_SET_COMPAT_FEATURE(sb, DIR_INDEX);
+ unlock_kernel();
+ ext2_write_super(dir->i_sb);
+ }
+ dir->u.ext2_i.i_flags |= EXT2_INDEX_FL;
+}
+
/*
* Debug
*/
@@ -696,8 +720,7 @@
char *data, *top;
*result = NULL;
if (namelen > EXT2_NAME_LEN) return NULL;
- if (ext2_dx && is_dx(dir))
- {
+ if (is_dx(dir)) {
u32 hash = dx_hash (name, namelen);
struct dx_frame frames[2], *frame;
if (!(frame = dx_probe (dir, hash, frames)))
@@ -818,8 +860,7 @@
char *data1;
if (!namelen) return -EINVAL;
- if (ext2_dx && is_dx(dir))
- {
+ if (is_dx(dir)) {
unsigned count, split, hash2, block2;
struct buffer_head *bh2;
char *data2;
@@ -989,7 +1032,7 @@
if ((de->inode? rlen - nlen: rlen) >= reclen) goto add;
de = (ext2_dirent *) ((char *) de + rlen);
}
- if (ext2_dx && blocks == 1 && dir->u.ext2_i.i_flags & EXT2_INDEX_FL)
+ if (ext2_dx && blocks == 1 && test_opt(dir->i_sb, INDEX))
{
struct dx_root *root;
struct buffer_head *newbh, *rootbh = bh;
@@ -1029,6 +1072,7 @@
dx_set_block (entries, 1);
dx_set_count (entries, 1);
dx_set_limit (entries, dx_root_limit(dir, sizeof(struct
dx_root_info)));
+ ext2_update_to_indexed(dir);
/* Initialize as for dx_probe */
hash = dx_hash (name, namelen);
@@ -1107,26 +1154,11 @@
int ext2_make_empty(struct inode *dir, struct inode *parent)
{
- struct super_block *sb = dir->i_sb;
struct buffer_head *bh;
- int make_dx = test_opt (sb, INDEX);
- dir->i_size = sb->s_blocksize;
+
+ dir->i_size = dir->i_sb->s_blocksize;
Re: [PATCH] allocation looping + kswapd CPU cycles
Hi, On Thu, May 10, 2001 at 03:49:05PM -0300, Marcelo Tosatti wrote: > Back to the main discussion --- I guess we could make __GFP_FAIL (with > __GFP_WAIT set :)) allocations actually fail if "try_to_free_pages()" does > not make any progress (ie returns zero). But maybe thats a bit too > extreme. That would seem to be a reasonable interpretation of __GFP_FAIL + __GFP_WAIT, yes. --Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ATAPI Tape Driver Failure in Kernel 2.4.4, More
Mike Dresser wrote: > Mark Bratcher wrote: > >> >> This all works OK in kernel 2.2.17. But it fails in 2.4.4. >> > hdd: HP COLORADO 20GB, ATAPI TAPE drive > > I did my own playing with 2.4.x on the 14gb model of this tape drive, all i've >managed > to do is be able to write to the tape, but not read from it. Even in 2.2.x, putting >the > IDE patches in, breaks it. Apparently the HP's aren't completely ATAPI compatible I can write my HP 20GB drive with ide-tape. For restores I use ide-scsi. Its a bit of a hack but does work around the problem. Ed Tomlinson <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] allocation looping + kswapd CPU cycles
On Thu, 10 May 2001, Stephen C. Tweedie wrote: > Hi, > > On Thu, May 10, 2001 at 03:22:57PM -0300, Marcelo Tosatti wrote: > > > Initially I thought about __GFP_FAIL to be used by writeout routines which > > want to cluster pages until they can allocate memory without causing any > > pressure to the system. Something like this: > > > > while ((page = alloc_page(GFP_FAIL)) > > add_page_to_cluster(page); > > write_cluster(); > > Isn't that an orthogonal decision? You can use __GFP_FAIL with or > without __GFP_WAIT or __GFP_IO, whichever is appropriate. Correct. Back to the main discussion --- I guess we could make __GFP_FAIL (with __GFP_WAIT set :)) allocations actually fail if "try_to_free_pages()" does not make any progress (ie returns zero). But maybe thats a bit too extreme. What do you think? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] allocation looping + kswapd CPU cycles
Hi, On Thu, May 10, 2001 at 03:22:57PM -0300, Marcelo Tosatti wrote: > Initially I thought about __GFP_FAIL to be used by writeout routines which > want to cluster pages until they can allocate memory without causing any > pressure to the system. Something like this: > > while ((page = alloc_page(GFP_FAIL)) > add_page_to_cluster(page); > write_cluster(); Isn't that an orthogonal decision? You can use __GFP_FAIL with or without __GFP_WAIT or __GFP_IO, whichever is appropriate. Cheers, Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Acenic tigon 1 support fix
On Thu, May 10, 2001 at 08:59:24PM +0200, Jes Sorensen wrote: > Thanks, I'll put that in the next driver release as well. Good. The only bad thing is that even with this fix, the card doesn't work (recieves, but never transmits). I'll have to look into it later, when I find time. OG. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.2 - Locked keyboard
Hi all! I have a squid server box (~150 users) that has been running without problems since 2.4.0-test10. Now with 2.4.2 it has had an uptime of 29 days (power loss). After the reboot, the keyboard was working 5 minutes and then it locked. The console was working. I rebooted the machine again and has been working for 2 days, that the keyboard gets locked again. I changed the keyboard and looked at the keyboard plugs unsucessfully. Could this be related to a kernel bug or an userspace issue??? How can I debug it? -Jorge MB Tyan K7 - K7 800Mhz Kernel 2.4.2 - Compiled for Athlon/K7 (no problems) Modules: via-rhine - sundance - osst - ide-scsi scsi-mod - ip_tables - iptable_mangle - ip_conntrack - iptable_nat - ipt_MARK - ipt_REDIRECT Debian Woody gcc 2.95.2 Libc 2.2.2 == Jorge Boncompte - Técnico de sistemas DTI2 - Desarrollo de la Tecnología de las Comunicaciones -- C/ Abogado Enriquez Barrios, 5 14004 CORDOBA (SPAIN) Tlf: +34 957 761395 / FAX: +34 957 450380 -- [EMAIL PROTECTED] _-_-_-_-_-_-_-_-_-_-_-_-_-_ http://www.dti2.net == - Sin pistachos no hay Rock & Roll... - Without wicker a basket cannot be done. == - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
null pointer dereference in ibmtr
When inserting the ibmtr.o module in any of the 2.4 series kernels, I get a null pointer crash. Latest try was 2.4.4. Ksymoops: Unable to handle kernel paging request at virtual address 7a18 c012861e *pde = Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: 0170 ebx: 0001 ecx: 0170 edx: esi: c1321080 edi: c13210dc ebp: c9ca3800 esp: c0203ee8 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c0203) Stack: c0188efd c1321080 c0188f37 c1321080 c1321080 c0189067 c1321080 c1321080 c1321080 c01905c3 c1321080 c1321080 c9ff8ca0 c01903bb c1321080 c9ca3800 c01ff12c c1321080 c01ff12c c0189067 c1321080 c9ca3800 c01ff12c Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 41 18 85 c0 7c 11 ff 49 14 0f 94 c0 84 c0 74 07 89 c8 e8 >>EIP; c012861e <__free_pages+2/1c> <= Trace; c0188efd Trace; c0188f37 Trace; c0189067 <__kfree_skb+e7/f0> Trace; c01905c3 Trace; c01903bb Trace; c018c219 Trace; c018c3f5 Trace; c0115b7e Trace; c0107ef9 Trace; c0105160 Trace; c0106be0 Trace; c0105160 Trace; c0100018 Trace; c0105183 Trace; c01051de Trace; c0105000 Trace; c0100198 Code; c012861e <__free_pages+2/1c> <_EIP>: Code; c012861e <__free_pages+2/1c> <= 0: 8b 41 18 movl 0x18(%ecx),%eax <= Code; c0128621 <__free_pages+5/1c> 3: 85 c0 testl %eax,%eax Code; c0128623 <__free_pages+7/1c> 5: 7c 11 jl 18 <_EIP+0x18> c0128636 <__free_pages+1a/1c> Code; c0128625 <__free_pages+9/1c> 7: ff 49 14 decl 0x14(%ecx) Code; c0128628 <__free_pages+c/1c> a: 0f 94 c0 sete %al Code; c012862b <__free_pages+f/1c> d: 84 c0 testb %al,%al Code; c012862d <__free_pages+11/1c> f: 74 07 je 18 <_EIP+0x18> c0128636 <__free_pages+1a/1c> Code; c012862f <__free_pages+13/1c> 11: 89 c8 movl %ecx,%eax Code; c0128631 <__free_pages+15/1c> 13: e8 00 00 00 00call 18 <_EIP+0x18> c0128636 <__free_pages+1a/1c> Cpu info: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 3 model name : Pentium II (Klamath) stepping: 4 cpu MHz : 299.946316 cache size : 512 KB fdiv_bug: no hlt_bug : no sep_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov mmx bogomips: 299.01 The token ring card is ISA, not pci. It has worked fine for years under 2.2.* Any ideas? -dennis T - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pci_pool_free from IRQ
How about this (with documentation fixes by David-B): diff -ur -X dontdiff linux-2.4.4/Documentation/DMA-mapping.txt linux-2.4.4-niph/Documentation/DMA-mapping.txt --- linux-2.4.4/Documentation/DMA-mapping.txt Thu Apr 19 08:38:48 2001 +++ linux-2.4.4-niph/Documentation/DMA-mapping.txt Thu May 10 12:29:22 2001 @@ -240,6 +240,7 @@ where dev, size are the same as in the above call and cpu_addr and dma_handle are the values pci_alloc_consistent returned to you. +This function may not be called in interrupt context. If your driver needs lots of smaller memory regions, you can write custom code to subdivide pages returned by pci_alloc_consistent, @@ -262,7 +263,8 @@ sleeping context (f.e. in_interrupt is true or while holding SMP locks), pass SLAB_ATOMIC. If your device has no boundary crossing restrictions, pass 0 for alloc; passing 4096 says memory allocated -from this pool must not cross 4KByte boundaries. +from this pool must not cross 4KByte boundaries (but at that time it +may be better to go for pci_alloc_consistent directly instead). Allocate memory from a pci pool like this: @@ -270,21 +272,23 @@ flags are SLAB_KERNEL if blocking is permitted (not in_interrupt nor holding SMP locks), SLAB_ATOMIC otherwise. Like pci_alloc_consistent, -this returns two values, cpu_addr and dma_handle, +this returns two values, cpu_addr and dma_handle. Free memory that was allocated from a pci_pool like this: pci_pool_free(pool, cpu_addr, dma_handle); where pool is what you passed to pci_pool_alloc, and cpu_addr and -dma_handle are the values pci_pool_alloc returned. +dma_handle are the values pci_pool_alloc returned. This function +may be called in interrupt context. Destroy a pci_pool by calling: pci_pool_destroy(pool); Make sure you've called pci_pool_free for all memory allocated -from a pool before you destroy the pool. +from a pool before you destroy the pool. This function may not +be called in interrupt context. DMA Direction diff -ur -X dontdiff linux-2.4.4/Documentation/pci.txt linux-2.4.4-niph/Documentation/pci.txt --- linux-2.4.4/Documentation/pci.txt Sun Sep 17 09:45:06 2000 +++ linux-2.4.4-niph/Documentation/pci.txt Thu May 10 12:33:03 2001 @@ -60,8 +60,8 @@ remove Pointer to a function which gets called whenever a device being handled by this driver is removed (either during deregistration of the driver or when it's manually pulled - out of a hot-pluggable slot). This function can be called - from interrupt context. + out of a hot-pluggable slot). This function always gets + called from process context, so it can sleep. suspend,Power management hooks -- called when the device goes to resume sleep or is resumed. --- linux-2.4.4/drivers/pci/pci.c Thu Apr 19 08:38:48 2001 +++ linux-2.4.4-niph/drivers/pci/pci.c Thu May 10 12:36:28 2001 @@ -1701,8 +1701,11 @@ set_bit (block, >bitmap [map]); if (waitqueue_active (>waitq)) wake_up (>waitq); - else if (!is_page_busy (pool->blocks_per_page, page->bitmap)) - pool_free_page (pool, page); + /* +* Resist a temptation to do +*if (!is_page_busy(bpp, page->bitmap)) pool_free_page(pool, page); +* it is not interrupt safe. Better have empty pages hang around. +*/ spin_unlock_irqrestore (>lock, flags); } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] allocation looping + kswapd CPU cycles
On Thu, 10 May 2001, Stephen C. Tweedie wrote: > Hi, > > On Thu, May 10, 2001 at 01:43:46PM -0300, Marcelo Tosatti wrote: > > > No. __GFP_FAIL can to try to reclaim pages from inactive clean. > > > > We just want to avoid __GFP_FAIL allocations from going to > > try_to_free_pages(). > > Why? __GFP_FAIL is only useful as an indication that the caller has > some magic mechanism for coping with failure. Hum, not _only_. Initially I thought about __GFP_FAIL to be used by writeout routines which want to cluster pages until they can allocate memory without causing any pressure to the system. Something like this: while ((page = alloc_page(GFP_FAIL)) add_page_to_cluster(page); write_cluster(); See? > There's no other information passed, so a brief call to > try_to_free_pages is quite appropriate. This obviously depends on what we decide __GFP_FAIL will be used for. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] allocation looping + kswapd CPU cycles
Hi, On Thu, May 10, 2001 at 01:43:46PM -0300, Marcelo Tosatti wrote: > No. __GFP_FAIL can to try to reclaim pages from inactive clean. > > We just want to avoid __GFP_FAIL allocations from going to > try_to_free_pages(). Why? __GFP_FAIL is only useful as an indication that the caller has some magic mechanism for coping with failure. There's no other information passed, so a brief call to try_to_free_pages is quite appropriate. --Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Problem with dmfe
Hello, I have installed Linux 2.4.4 on our remotely-administered dedicated Web server (600MHz Celeron), and strange effects occurred with the Davicom DM9102 network card. It was active but apparently VERY slow, 85% packet loss in ping. I could connect to the machine but could not do anything useful. The system had to be rebooted into the previous configuration (2.2.12) which works fine. I then examined the kernel logs for 2.4.4 and found the following: PCI: Using IRQ router PIIX [8086/2420] at 00:1f.0 PCI: Found IRQ 3 for device 00:01.0 eth0: Davicom DM9102 at 0xc000, 00:d0:09:1e:61:51, IRQ 3 Thus, device 00:01.0 (video card) shares IRQ with the net card. Could it be the source of the problem? Under 2.2.12, pciutils show the following info for these devices: 00:01.0 VGA compatible controller: Intel Corporation 82810 CGC [Chipset Graphics Controller] (rev 02) (prog-if 00 [VGA]) Subsystem: Intel Corporation: Unknown device 7121 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fbdev logo (fwd)
On Thu, 10 May 2001, Martin Dalecki wrote:
> > - Political fixes:
> > o There were still some penguins left carrying a glass of beer or wine.
> > This problem is about 2 years old!
>
> Could You please for the sake of political correctness just replace
> the beer with a glass of vodka please... It tastes better anyway!
No. End of discussion.
Gr{oetje,eeting}s,
Geert
P.S. Personally I do prefer vodka too. Can we get some sponsoring from Absolut
please? :-)
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fbdev logo (fwd)
> - Political fixes: > o There were still some penguins left carrying a glass of beer or wine. > This problem is about 2 years old! Could You please for the sake of political correctness just replace the beer with a glass of vodka please... It tastes better anyway! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] /dev/fb* docu fixes
Hi Linus,
This patch brings the documentation for /dev/fb* in sync with the
implementation.
The implementation behaves like this since nearly ca. 1.5 years.
This patch is in Alan's tree since nearly 6 months.
Thanks for applying!
diff -urN linux-2.4.5-pre1/Documentation/devices.txt
fbdev-2.4.4/Documentation/devices.txt
--- linux-2.4.5-pre1/Documentation/devices.txt Sat Dec 30 20:26:10 2000
+++ fbdev-2.4.4/Documentation/devices.txt Mon Feb 26 09:02:13 2001
@@ -660,6 +660,12 @@
29 char Universal frame buffer
0 = /dev/fb0 First frame buffer
+ 1 = /dev/fb1 Second frame buffer
+ ...
+31 = /dev/fb31 32nd frame buffer
+
+ Backward compatibility aliases {2.6}
+
32 = /dev/fb1 Second frame buffer
...
224 = /dev/fb7 Eighth frame buffer
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
another potential security bug
Hi, my name is William Ie and I am currently working under Dawson Engler's
mc project here in the Stanford CS dept. We are currently trying to
develop security related bug-checkers, particularly regarding the
capability checks done in the linux kernel. While going through the
results of our prototype checker, we run into the following anomaly and
thus was wondering if this is merely a false positive. Thank you very much
for your input.
linux/2.4.3/drivers/net/pcmcia/netwave_cs.c
case SIOCGIWENCODE:
/* Get scramble key */
ERROR<-if(wrq->u.encoding.pointer != (caddr_t) 0)
{
charkey[2];
key[1] = scramble_key & 0xff;
key[0] = (scramble_key>>8) & 0xff;
wrq->u.encoding.flags = IW_ENCODE_ENABLED;
wrq->u.encoding.length = 2;
if(copy_to_user(wrq->u.encoding.pointer, key, 2))
ret = -EFAULT;
}
break;
handling the same command with CAP_NET_ADMIN capability checks are done
in:
drivers/net/wavelan.c
drivers/net/pcmcia/orinoco_cs.c
drivers/net/pcmcia/wavelan_cs.c
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fbdev logo (fwd)
FYI...
-- Forwarded message --
Date: Thu, 10 May 2001 21:01:41 +0200 (CEST)
From: Geert Uytterhoeven <[EMAIL PROTECTED]>
To: Linus Torvalds <[EMAIL PROTECTED]>
Cc: Geert Uytterhoeven <[EMAIL PROTECTED]>
Subject: [PATCH] fbdev logo
Hi Linus,
This patch fixes a few bugs in the penguin logo code of the fbdev (frame buffer
device) subsystem:
- Technical fixes:
o The colors of the 16-color penguin logo are wrong. The logo looks like
a psychedelic penguin holding a glass of beer (or LSD?). This is caused
by a bug fix in the console subsystem that no longer allows us to use
an old color palette hack. This problem is ca. 9 months old!
Solution: replace the logo by a new one that uses colors from the
standard console palette only.
o Remove an obsolete #include.
o Remove an obsolete logo file in drivers/char/sgi/ (it was removed from
the Linux/MIPS CVS tree some months ago).
o Use __HAVE_ARCH_LINUX_LOGO* defines to determine logo inclusion in the
include files.
- Political fixes:
o There were still some penguins left carrying a glass of beer or wine.
This problem is about 2 years old!
- Aesthetical fixes:
o Upgrade the logos to an anti-aliased variant with pleasant halo-effect.
Some of these fixes are already in Alan's tree. I'll make sure he gets a copy
of the patch relative to his tree, and will post this message to linux-kernel
(with a link to the patch).
You can find a table showing the old and new logos at my web page:
http://home.tvd.be/cr26864/Linux/fbdev/logo.html
Thanks for applying this patch!
[ patch removed, look at the web page ]
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Acenic tigon 1 support fix
> "Olivier" == Olivier Galibert <[EMAIL PROTECTED]> writes: Olivier> A typo prevents the tigon 1 firmware to be included when Olivier> tigon 1 support is active. Null pointer dereference in Olivier> ace_load_firmware-> ace_copy as a result. Olivier> Patch trivial and even tested (aka, the module loads without Olivier> oopsing with a tigon 1 inside). Thanks, I'll put that in the next driver release as well. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs, xfs, ext2, ext3
On Mié 09 May 2001 21:32, Joel Jaeggli wrote: > I have a proxy server that's been running 2.4.3pre4 with reiserfs for the > partitions on the cache disks. it has an uptime of 43 days at this point. > it wasn't very stable at all (two crashes in one week) with 2.4.2. I'll be > building 2.4.4 something when I get back from ghana to the US, but I don't > want to reboot it onto a fresh kernel while I'm 11,000 miles away, serial > console notwithstanding. > > Overall I'm of the belief that reiserfs is robust enough for mainstream > use, and it's significantly faster than ext2 for the squid box, you do as > usal need to be a bit selective about what kernel you choose to run. Could you give un information on the hardware you're using for that proxy? Saludos... :-) -- El mejor sistema operativo es aquel que te da de comer. Cuida tu dieta. - Martin Marques |[EMAIL PROTECTED] Programador, Administrador | Centro de Telematica Universidad Nacional del Litoral - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Small kernel-api addition
On Thu, 10 May 2001, David Woodhouse wrote: > I'd suggest s/that may be/that are expected to be/ thanks, how about this : --- Documentation/DocBook/kernel-api.tmpl.old Thu May 10 18:02:05 2001 +++ Documentation/DocBook/kernel-api.tmpl Thu May 10 18:02:57 2001 @@ -41,8 +41,9 @@ !Iinclude/linux/init.h - Atomics + Atomic and pointer manipulation !Iinclude/asm-i386/atomic.h +!Iinclude/asm-i386/unaligned.h Delaying, scheduling, and timer routines --- include/asm-i386/unaligned.h.oldThu May 10 17:54:28 2001 +++ include/asm-i386/unaligned.hThu May 10 19:38:55 2001 @@ -9,8 +9,29 @@ * architectures where unaligned accesses aren't as simple. */ +/** + * get_unaligned - get value from possibly mis-aligned location + * @ptr: pointer to value + * + * This macro should be used for accessing values larger in size than + * single bytes at locations that are expected to be improperly aligned, + * e.g. retrieving a u16 value from a location not u16-aligned. + * + * Note that unaligned accesses can be very expensive on some architectures. + */ #define get_unaligned(ptr) (*(ptr)) +/** + * put_unaligned - put value to a possibly mis-aligned location + * @val: value to place + * @ptr: pointer to location + * + * This macro should be used for placing values larger in size than + * single bytes at locations that are expected to be improperly aligned, + * e.g. writing a u16 value to a location not u16-aligned. + * + * Note that unaligned accesses can be very expensive on some architectures. + */ #define put_unaligned(val, ptr) ((void)( *(ptr) = (val) )) #endif - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
mmap2 causes SIGBUS on 2.4.4-ac6
After compiling and installing a 2.4.4-ac6 kernel I noticed that some programs (notably 'grep') started crashing with 'Bus error's and captured some 'strace' output... In all cases the last four lines of output from strace are: mmap2(0x8059000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x8059000 mmap2(0x8059000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xe8) = 0x8059000 --- SIGBUS (Bus error) --- +++ killed by SIGBUS +++ For those who would like to try and reproduce it, this command generates it every time: $ grep foo /usr/src/linux/Documentation/* So there seems to be some mmap related problem with 2.4.4-ac6. I tried running the exact same commands on a 2.2.17 and 2.2.19 and they do not exhibit this behaviour. I can try some more 2.4.x kernels if the information would be valuable? If there is any other relevant information I can gather, then please let me know and I'll be happy to provide it. I tried searching for "mmap2" and "SIGBUS" on http://www.uwsg.indiana.edu/hypermail/linux/kernel/ but could not find any posts related to this, so I thought it would be ok to post this. Best regards, Jesper Juhl - [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Detecting Red Hat builds ?
For a RH7.x, at least, there is the /boot/kernel.h file generated on bootup, and the RH kernel headers include it somewhere. You can see if the corresponding symbols (coming from it) are defined, and assume redhat than. You might consider using passing -dM down to the preprocessor with the standard driver includes preamble, and look in the preprocessed output for a good clue - it may well be that there is some other redhat-specific string somewhere defined. I guess you will find smth if you egrep -i (rh|redhat). HTH, Vassilii -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 10, 2001 12:25 PM To: [EMAIL PROTECTED] Subject: Detecting Red Hat builds ? Hi, How can I determine if the build my device driver is being compiled under is a standard kernel.org one or a Red Hat one ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] allocation looping + kswapd CPU cycles
On Thu, 10 May 2001, Mark Hemment wrote: > > On Wed, 9 May 2001, Marcelo Tosatti wrote: > > On Wed, 9 May 2001, Mark Hemment wrote: > > > Could introduce another allocation flag (__GFP_FAIL?) which is or'ed > > > with a __GFP_WAIT to limit the looping? > > > > __GFP_FAIL is in the -ac tree already and it is being used by the bounce > > buffer allocation code. > > Thanks for the pointer. > > For non-zero order allocations, the test against __GFP_FAIL is a little > too soon; it would be better after we've tried to reclaim pages from the > inactive-clean list. Any nasty side effects to this? No. __GFP_FAIL can to try to reclaim pages from inactive clean. We just want to avoid __GFP_FAIL allocations from going to try_to_free_pages(). > Plus, the code still prevents PF_MEMALLOC processes from using the > inactive-clean list for non-zero order allocations. As the trend seems to > be to make zero and non-zero allocations 'equivalent', shouldn't this > restriction to lifted? I don't see any problem about making non-zero allocations be able to directly reclaim pages. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Small kernel-api addition
[EMAIL PROTECTED] said:
+ * This macro should be used for accessing values larger in size than single
+ * bytes at locations that may be improperly aligned, e.g. retrieving a u16
+ * value from a location not u16-aligned.
I'd suggest s/that may be/that are expected to be/
If it's _expected_, then by all means use {get,put}_unaligned(). If it's
normally going to be aligned, and it _may_ occasionally be otherwise, let
the common case go fast, and let the fixup handle it otherwise.
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Deadlock in 2.2 sock_alloc_send_skb?
On Thu, May 10, 2001 at 01:57:49PM +0100, Alan Cox wrote: > > If that happens, and the socket uses GFP_ATOMIC allocation, the while (1) > > loop in sock_alloc_send_skb() will endlessly spin, without ever calling > > schedule(), and all the time holding the kernel lock ... > > If the socket is using GFP_ATOMIC allocation it should never loop. That is > -not-allowed-. It is just not clear why any socket should use GFP_ATOMIC. I can understand it using GFP_BUFFER e.g. for nbd, but GFP_ATOMIC seems to be rather radical and fragile. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ATAPI Tape Driver Failure in Kernel 2.4.4, More
Mark Bratcher wrote: > > This all works OK in kernel 2.2.17. But it fails in 2.4.4. > > hdd: HP COLORADO 20GB, ATAPI TAPE drive I did my own playing with 2.4.x on the 14gb model of this tape drive, all i've managed to do is be able to write to the tape, but not read from it. Even in 2.2.x, putting the IDE patches in, breaks it. Apparently the HP's aren't completely ATAPI compatible - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Small kernel-api addition
Clean against 2.4.4-ac6 and 2.4.4 thanks john --- Documentation/DocBook/kernel-api.tmpl.old Thu May 10 18:02:05 2001 +++ Documentation/DocBook/kernel-api.tmpl Thu May 10 18:02:57 2001 @@ -41,8 +41,9 @@ !Iinclude/linux/init.h - Atomics + Atomic and pointer manipulation !Iinclude/asm-i386/atomic.h +!Iinclude/asm-i386/unaligned.h Delaying, scheduling, and timer routines --- include/asm-i386/unaligned.h.oldThu May 10 17:54:28 2001 +++ include/asm-i386/unaligned.hThu May 10 18:29:11 2001 @@ -9,8 +9,29 @@ * architectures where unaligned accesses aren't as simple. */ +/** + * get_unaligned - get value from possibly mis-aligned location + * @ptr: pointer to value + * + * This macro should be used for accessing values larger in size than single + * bytes at locations that may be improperly aligned, e.g. retrieving a u16 + * value from a location not u16-aligned. + * + * Note that unaligned accesses can be very expensive on some architectures. + */ #define get_unaligned(ptr) (*(ptr)) +/** + * put_unaligned - put value to a possibly mis-aligned location + * @val: value to place + * @ptr: pointer to location + * + * This macro should be used for placing values larger in size than single + * bytes at locations that may be improperly aligned, e.g. write a u16 + * value to a location not u16-aligned. + * + * Note that unaligned accesses can be very expensive on some architectures. + */ #define put_unaligned(val, ptr) ((void)( *(ptr) = (val) )) #endif - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ip autoconfig with modules, kernel 2.4
On Thu, May 10, 2001 at 09:49:53AM -0700, Brian J. Murrell wrote: > Of course, this elminates the need to build kernels with lots of > statically linked ethernet drivers or building lots of kernels with > specific drivers statically linked in. > > My hope is that this is seen as a good idea (and a good > implementation) and that the patch is accepted into the Linux kernel. Hmm, if you've got userspace up and running, and loaded kernel modules using insmod, then what's wrong about running a dhcp, bootp or rarp client from userspace? You can then drop the kernel space IP autoconfiguration code. -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Linux on ENIAC...
> of the ENIAC Linux machine. We hope that the next-generation EDSAC, Wasn't it EDVAC IIRC? -mirabilos -- EA F0 FF 00 F0 #$@%CARRIER LOST - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Curious boot problem: linux-2.4.4SMP/AsusTek MB
Hi, A friend of mine uses linux-2.4.4 on his nice dual P3-1000 machine (AsusTek Motherboard). The problem is that the kernel gets stuck at the initialization of the APIC during boottime. The real weird thing is that if he boots linux-2.2.18 and afterwards 2.4.4, the kernel boots properly. So it seems that kernel 2.2 does some "initalization" that helps 2.4.4 to boot. Does anyone have a clue? Best Regards, Hermann -- ,_, (O,O) "There is more to life than increasing its speed." ( ) -- Gandhi -"-"-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ip autoconfig with modules, kernel 2.4
Please CC me on any responses as I don't read the kernel-list in my
inbox. Thanx.
I am looking for comments on the attached patch. It's purpose is to
allow IP AutoConfig to happen additionally after the loading of an
initial ramdisk.
This allows one to use a "generic all-purpose" built kernel (i.e. a
fully modular kernel) to retrieve it's IP configuration via BOOTP or
RARP (and DHCP when that is ported into 2.4) as long as the ethernet
driver module for the installed ethernet card is loaded via the
initial ramdisk.
Of course, this elminates the need to build kernels with lots of
statically linked ethernet drivers or building lots of kernels with
specific drivers statically linked in.
My hope is that this is seen as a good idea (and a good
implementation) and that the patch is accepted into the Linux kernel.
All comments welcome.
Thanx,
b.
--- linux-2.2.17.old/init/main.c.orig Tue Mar 27 15:59:08 2001
+++ linux-2.2.17/init/main.cTue Mar 27 16:01:03 2001
@@ -132,6 +132,10 @@
kdev_t real_root_dev;
#endif
+#if CONFIG_IP_PNP
+extern int __init ip_auto_config(void);
+#endif
+
int root_mountflags = MS_RDONLY;
char *execute_command;
@@ -863,6 +863,9 @@
while (pid != wait());
if (MAJOR(real_root_dev) != RAMDISK_MAJOR
|| MINOR(real_root_dev) != 0) {
+#if CONFIG_IP_PNP
+ ip_auto_config();
+#endif
error = change_root(real_root_dev,"/initrd");
if (error)
printk(KERN_ERR "Change root to /initrd: "
--- linux/net/ipv4/ipconfig.c Wed May 9 00:05:43 2001
+++ linux/net/ipv4/ipconfig.c.new Wed May 9 00:05:41 2001
@@ -823,7 +823,7 @@
* IP Autoconfig dispatcher.
*/
-static int __init ip_auto_config(void)
+int __init ip_auto_config(void)
{
if (!ic_enable)
return 0;
Re: 8139too v0.9.17 - w/ 8139B, DFE538TX 10/100 [NOT working]
Adam wrote: > Is the exact message I get, though, with the v0.9.15c version of the > driver, my NIC works perfectly fine, should I revert to using kernel > 2.4.3 w/ v0.9.15c of the 8139too driver until it is fixed? Well, if it doesn't work you pretty much have to revert to the older working version. :( Working on a fix... -- Jeff Garzik | Game called on account of naked chick Building 1024| MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[OT] Linux on ENIAC...
> > > > Tony > > > > Where a calculator on the ENIAC is equipped with 18,000 vaccuum > > tubes and weighs 30 tons, computers in the future may have only > > 1,000 vaccuum tubes and perhaps weigh 1 1\2 tons. > > -- Popular Mechanics, March 1949 > > ANNOUNCEMENT: New Linux port. Announcing the heaviest Linux machine available. The port of Linux to the ENIAC is the next step in open source productivity and may be the most important invention in the world. Since it is so difficult to find a modern operating system for the world class ENIAC system, ENIAC Linux will present you an entirely new world. There were only a few problems with Linux and ENIAC--The smallest Linux kernel is still a hundreds of thousands bytes. In order to work around this small detail, we have stripped Linux of all the unnecessary subsystems. Now, after removing the SCSI, PCI, IDE, Memory, NET, USB, Printing, Processes and Scheduling subsystems, ENIAC Linux is also the world's smallest Linux. Since ENIAC lacks online storage, ENIAC Linux uses a sophisticated paper diagram to to minimize storage requirements and improve wiring speed. With all these improvements, however, Linux ENIAC is still a very buggy system. We are constantly replacing buggy and burnt-out pieces of the ENIAC Linux machine. We hope that the next-generation EDSAC, with a reduction in size by 16,000 tubes and new memory technology, will improve the responsiveness, effectiveness and reliability of the Linux port to the ENIAC architecture. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
8139too v0.9.17 - w/ 8139B, DFE538TX 10/100 [NOT working]
Using DHCP, on Slackware 7.1 w/ GLIBC 2.2, kernel 2.4.4(and 2.4.5pre1 w/ 8139too.patch to v0.9.17) --- media is unconnected, link down, or incompatible connection --- Is the exact message I get, though, with the v0.9.15c version of the driver, my NIC works perfectly fine, should I revert to using kernel 2.4.3 w/ v0.9.15c of the 8139too driver until it is fixed? If there is anymore information needed to help in possibly fixing the problem I'd be more than glad to oblige. -- Adam [EMAIL PROTECTED] Linux user #190288 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Detecting Red Hat builds ?
Hi, How can I determine if the build my device driver is being compiled under is a standard kernel.org one or a Red Hat one ? The problem is I have a driver that includes syncppp.h which in the releases from kernel.org is in linux/drivers/net/wan/ up to and including 2.4.2 after which it moves to linux/include/net/. Can cope with this easily enough with a "#if LINUX_VERSION_CODE > KERNEL_VERSION(2,4,2)" but unfortunatly the kernel source supplied with Red Hat 7.1 reports itself as 2.4.2 but already has the syncppp changes from 2.4.3. I was shown a trick to solve a similar problem under 2.2.x but the symbol defined as a side effect of including one of the standard system headers is no longer present :-( -- Bob Dunlop FarSite Communications [EMAIL PROTECTED] [EMAIL PROTECTED] www.xyzzy.clara.co.uk www.farsite.co.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Deadlock/crash with Quad tulip card in 2.4
Yann Dupont wrote: > Hello. I'm having problem with Quad eth100 tulip (digital 21140) cards. Unfortuantely a recent merge of the latest Becker code fixed these chips (and 2104[01]), and promptly broke support for other, more popular chips. :( I'm working on fixing this right now; until then, the "de4x5" driver should work for you. -- Jeff Garzik | Game called on account of naked chick Building 1024| MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] IDE DMA timeouts and reiserfs stability
On Wed, May 09, 2001 at 11:42:35PM -0400, Ed Tomlinson wrote: > Hi, > > I am using 2.4.5-pre1. Over the course of the last two weeks I have had > DMA timeouts occur twice. Both times corrupted my fs. While this is not > ideal, its not unexpected as things stand now. I have seen at least three > other reports on lkml about errors of this type - suspect that 2.4's ide > is a little fragile in some corner cases... Out of curiousity, can you reproduce the problem in a 2.4 kernel with Andre Hedrick's IDE patch for 2.4 applied? It works for me, but that's just me. (ftp://ftp.kernel.org/pub/linux/kernel/people/hedrick/) -- Chris Dukes The more I administer Solaris the more I believe it deserves the reputation HPUX has and vice versa. -- me. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.xx ? messages related to parport printer ?
Tim, >> May 9 13:14:59 debian-f5ibh kernel: parport0: Unspecified, EPSON Styl >Huh. Does it do the same thing every time you load parport_probe? >Does it always get truncated in the same place? Yes ! :-/ [jean-luc@debian-f5ibh] ~ # modprobe parport_probe parport0: PC-style at 0x378 (0x778), irq 7 [SPP,ECP,ECPEPP,ECPPS2] parport0: Unspecified, EPSON Styl >> With 2.4.4-ac6 and 2.4.xx, I get : >> -- >> May 9 14:19:44 debian-f5ibh kernel: parport0: Printer, EPSON Stylus >> COLOR 500 >Well, at least it seems to work in 2.4.x. >I wonder what deviceid makes of it: >ftp://people.redhat.com/twaugh/parport/deviceid-0.3.tar.gz> [jean-luc@debian-f5ibh] ~ # deviceid --base 0x378 MFG:EPSON;CMD:ESCPL2-00;MDL:Stylus COLOR 500;CLS:PRINTER; There is an other strange thing : escputil expect "Stylus Color" and my printer send "Stylus COLOR" (uppercase)... - Regards Jean-Luc - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Deadlock/crash with Quad tulip card in 2.4
Hello. I'm having problem with Quad eth100 tulip (digital 21140) cards. The machine was acting as a bridge with kernel 2.2 very reliably. Now, when I boot 2.4.4-ac6, the machine hangs - no oops, nothing. Just hang. even CTRL-Scroll lock does nothing. I supected a bridge problem (I know 2.2 & 2.4 bridge are different) But it's not the case as I reproduce the bug on another machine (with another motherboard. kernel 2.4.4-ac6 where the bridge is not configured.) single boot is OK, ifconfig eth0 up is ok (MII negotiation is OK) ifconfig eth1 up crash the machine - on another boot i tried this : ifconfig eth0 up ifconfig eth0 down ifconfig eth1 up is OK ifconfig eth1 down ... etc etc This works as long as only one interface is up. If only 1 interface is up, the machine works reliably. just putting 2 interfaces up hang the machine. Can this be an IRQ sharing / bridge problem ??? (all interface shares the same IRQ and are after a bridge) I don't know if this is ac-series specific. I'll try tomorrow. Any Idea how I can test further ? Without oops it's not easy... Yann Dupont. -- \|/ \|/ Fac. des sciences de Nantes-Linux-Python-IPv6-ATM-BONOM "@'/ ,. \@" Tel :(+33) [0]251125865(AM)[0]251125857(PM)[0]251125868(Fax) /_| \__/ |_\ [EMAIL PROTECTED] \__U_/http://www.unantes.univ-nantes.fr/~dupont - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs, xfs, ext2, ext3
On Thursday 10 May 2001 12:19, Pekka Pietikainen wrote: > Here's some very unscientific numbers I've measured (ancient 4G SCSI > drive on a dual pII/450), XFS 1.0-pre2 and reiserfs is > the version in that kernel. The first bit is from tiobench, the > multiple files one is a simple 30-line program that creates tons of > 1k files and then removes them. > > XFS > > Create 2 files: 116.882449 > Unlink 2 files: 47.449201 > > reiserfs > > Create 2 files: 17.862143 > Unlink 2 files: 9.487520 > > ext2 > > Create 2 files: 248.758925 > Unlink 2 files: 2.287174 Whoops! The create test is exactly the case my index patch accelerates, trying it is highly recommended: http://nl.linux.org/~phillips/htree/dx.testme-2.4.3-3 To apply: cd source/tree zcat ext2-dir-patch-S4.gz | patch -p1 cat dx.pcache-2.4.4 | patch -p0 Or for the all-in-page-cache version (needs Al Viro's patch, see the READ.ME at http://nl.linux.org/~phillips/htree/): http://nl.linux.org/~phillips/htree/dx.pcache-2.4.4-4 The testme version is easier to apply but the pcache version is more like what the final form will be (waiting for Al's patch to get into Linus's tree so I can de-fork this). -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] writepage method changes
On Wednesday, May 09, 2001 10:51:17 PM -0300 Marcelo Tosatti <[EMAIL PROTECTED]> wrote: > > > On Wed, 9 May 2001, Marcelo Tosatti wrote: > >> Locked for the "not wrote out case" (I will fix my patch now, thanks) > > I just found out that there are filesystems (eg reiserfs) which write out > data even if an error ocurred, which means the unlocking must be done by > the filesystems, always. I'm not horribly attached to the way reiserfs is doing it right now. If reiserfs writepage manages to map any blocks, it writes them to disk, even if mapping other blocks in the page failed. These are only data blocks, so there are no special consistency rules. If we need to change this, it is not a big deal. -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs, xfs, ext2, ext3
Tony Hoyle wrote: > Matthias Andree wrote: > > > ext3fs has never given me any problems, but I did not have it in > > production use where I discovered major ReiserFS <-> kNFSd > > incompatibilities. ext3 has a 0.0.x version number which suggests it's > > not meant for production use. > > Hmm... Reiserfs is incompatible with knfsd? That might explain the > massive data loss I was getting with reiserfs (basically I'd have to > reformat and reinstall every couple of weeks). The machine this was > happening with also exports my apt cache for the rest of the network. > > Tony > > -- > Where a calculator on the ENIAC is equpped with 18,000 vaccuum > tubes and weighs 30 tons, computers in the future may have only > 1,000 vaccuum tubes and perhaps weigh 1 1\2 tons. > -- Popular Mechanics, March 1949 > > [EMAIL PROTECTED] > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ we have a patch on our website. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
